gnus faces

gnus faces

[Robert D. Crawford]

Sorry for not getting this in the thread... I can't seem to find it in
the summary buffer.

> Gnus defines a large number of faces for the Group, Summary, and
> Article buffers.  This makes it a pain for those who want impose a
> uniform color scheme on their Emacs, who must chage every one of these
> faces.

Agreed.

> It would be better for the Gnus faces to :inherit from the standard
> Emacs font-lock faces.  After all, font-lock highlighting is not used
> in Gnus.  Thoughts?

I don't agree with this.  Being partially sighted I rely on the faces
(and the change in the voice of my tts engine) to differentiate between
things like the person's name and the title of the post in the summary
buffer and the depth of quoting in the article buffer.  

I do, however, realize I am in a *very* small minority of users and that
must be taken into consideration for the greater good.

rdc
-- 
Robert D. Crawford                                     robdcraw@gmail.com

Re: Gnus faces

[Ted Zlatanov]

On Tue, 11 Jan 2011 11:46:27 -0500 Chong Yidong <cyd@stupidchicken.com> wrote: 

CY> Gnus defines a large number of faces for the Group, Summary, and Article
CY> buffers.  This makes it a pain for those who want impose a uniform color
CY> scheme on their Emacs, who must chage every one of these faces.

CY> It would be better for the Gnus faces to :inherit from the standard
CY> Emacs font-lock faces.  After all, font-lock highlighting is not used in
CY> Gnus.  Thoughts?

I'm in favor if it simplifies things, but don't know how it will work
and if it will break people's setups.

Ted

Re: Gnus faces

[Tassilo Horn]

Philipp Haselwarter <philipp.haselwarter@gmx.de> writes:

> I'd agree that as one tends to run out of groups (or gets to the point
> to just stuff some servers into one group) this is not optimal.  But
> what *do* you recommend instead? (gnus tends to always have *another*
> feature I didn't know)

If I'm not interested in getting new messages from some servers, I mark
them as denied.

,----[ (info "(gnus)Unavailable Servers") ]
| `D'
|      Mark the current server as unreachable (`gnus-server-deny-server').
`----

If a server is not reachable, Gnus does that automatically.

Bye,
Tassilo
-- 
Sent from my Emacs

Re: Gnus faces

[Philipp Haselwarter]

I'd agree that as one tends to run out of groups (or gets to the point
to just stuff some servers into one group) this is not optimal.
But what *do* you recommend instead? (gnus tends to always have
*another* feature I didn't know)

-- 
Philipp Haselwarter

Re: Gnus faces

[Andreas Schwab]

Tassilo Horn <tassilo@member.fsf.org> writes:

> But that implies that you need to assign a unique level to all groups of
> each server.

I don't see that.  As I said, there are many more reasons to use levels
than network issues.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Gnus faces

[Tassilo Horn]

Andreas Schwab <schwab@linux-m68k.org> writes:

>> Well, if a server is not reachable or I'm not interested in getting
>> new messages from it, then I mark it as denied in the *Server*
>> buffer.
>
> It's much easier to just switch the level.

But that implies that you need to assign a unique level to all groups of
each server.  By default, there are only 5 level that count as
subscribed, so with my 6 servers that doesn't suffice.  Additionally, I
don't see how that would do the trick if ever changing servers are
unreachable, for example I can't check the work server from home and the
other way round.

Anyway, I think we can stop here.  I'm fine with any usage of levels
that help people to get their work done. :-)

Bye,
Tassilo

Re: Gnus faces

[Andreas Schwab]

Tassilo Horn <tassilo@member.fsf.org> writes:

> Andreas Schwab <schwab@linux-m68k.org> writes:
>
>>> A slow network connection is the only reason I can think of to
>>> restrict fetching of new messages to a subset of groups.
>>
>> What about reachability?
>
> Well, if a server is not reachable or I'm not interested in getting new
> messages from it, then I mark it as denied in the *Server* buffer.

It's much easier to just switch the level.

>> There are many reasons why you don't want to connect to a server now
>> that have nothing to do with network speed.
>
> Yes, but levels are not the right tool for that purpose.  Especially,
> because levels are somewhat static.

I haven't yet found anything that fits better.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Gnus faces

[Tassilo Horn]

Andreas Schwab <schwab@linux-m68k.org> writes:

>> A slow network connection is the only reason I can think of to
>> restrict fetching of new messages to a subset of groups.
>
> What about reachability?

Well, if a server is not reachable or I'm not interested in getting new
messages from it, then I mark it as denied in the *Server* buffer.

> There are many reasons why you don't want to connect to a server now
> that have nothing to do with network speed.

Yes, but levels are not the right tool for that purpose.  Especially,
because levels are somewhat static.

Bye,
Tassilo

Re: Gnus faces

[Andreas Schwab]

Tassilo Horn <tassilo@member.fsf.org> writes:

> A slow network connection is the only reason I can think of to restrict
> fetching of new messages to a subset of groups.

What about reachability?  There are many reasons why you don't want to
connect to a server now that have nothing to do with network speed.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Gnus faces

[Philipp Haselwarter]

"AS" == Andreas Schwab <schwab@linux-m68k.org> writes:

AS> Tassilo Horn <tassilo@member.fsf.org> writes:

>> Andreas Schwab <schwab@linux-m68k.org> writes:
>> 
>>>> IMHO, I'd have an inheritance hierarchy with a top-level "abstract"
>>>> (i.e., not really used face) gnus-group, that is specialized by
>>>> emptyness, then backend, and finally by levels.  (I think that in
>>>> times of fast internet connections, the levels are the least
>>>> important thing.
>>> 
>>> Why do you think that levels have something to do with network
>>> speed?
>> 
>> Isn't that the intention of levels, like, fetch only my very
>> important mailboxes, e.g., with a level of 1.

AS> But what does this have to do with network speed?

AS> Andreas.

AS> -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA
AS> 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something
AS> completely different."

I think the idea was 'everyone has fast internet nowadays so fetching
only some groups (those with high levels) is obsolete/of little
importance'. So the relevance of levels does have to do with network
speed.
However, I disagree, as I'm *not* always on a fast network and
especially because levels help to address _server side_ network speed
issues. And those are still really bad especially for some news
servers.

-- 
Philipp Haselwarter

Re: Gnus faces

[Tassilo Horn]

Andreas Schwab <schwab@linux-m68k.org> writes:

>> Isn't that the intention of levels, like, fetch only my very
>> important mailboxes, e.g., with a level of 1.
>
> But what does this have to do with network speed?

A slow network connection is the only reason I can think of to restrict
fetching of new messages to a subset of groups.

Bye,
Tassilo

Re: Gnus faces

[Štěpán Němec]

James Cloos <cloos@jhcloos.com> writes:

>>>>>> "TH" == Tassilo Horn <tassilo@member.fsf.org> writes:
>
> TH> (I think that in times of fast internet connections, the levels are
> TH> the least important thing.  I'd even go that far and remove their
> TH> different defaults.  Feel free to disagree.)
>
> Levels make a useful substitute for topics on slow boxen (on my laptop
> topics are entirely unusable).  Also, even when the connection is local
> the remote servers can be slow enough for levels to make sense.

For me levels have nothing to do with speed at all. I simply use them to
distinguish between different "importance levels", i.e. how often I want
to update them. 

> On on the thread’s topic (pun-filled, aren’t we?), if changes are
> made, please make it easy to keep the current colours.

+1

Plus don't lose any customisability currently present. I really don't
see how the myriad Gnus faces could be mapped onto the standard
font-lock faces. Tassilo's proposal to rationalise the Gnus faces to
inherit from each other where appropriate to make them more easily
customisable as a whole seems to make more sense.

  Štěpán

Re: Gnus faces

[Andreas Schwab]

Tassilo Horn <tassilo@member.fsf.org> writes:

> Andreas Schwab <schwab@linux-m68k.org> writes:
>
>>> IMHO, I'd have an inheritance hierarchy with a top-level "abstract"
>>> (i.e., not really used face) gnus-group, that is specialized by
>>> emptyness, then backend, and finally by levels.  (I think that in
>>> times of fast internet connections, the levels are the least
>>> important thing.
>>
>> Why do you think that levels have something to do with network speed?
>
> Isn't that the intention of levels, like, fetch only my very important
> mailboxes, e.g., with a level of 1.

But what does this have to do with network speed?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Gnus faces

[Tassilo Horn]

Andreas Schwab <schwab@linux-m68k.org> writes:

>> IMHO, I'd have an inheritance hierarchy with a top-level "abstract"
>> (i.e., not really used face) gnus-group, that is specialized by
>> emptyness, then backend, and finally by levels.  (I think that in
>> times of fast internet connections, the levels are the least
>> important thing.
>
> Why do you think that levels have something to do with network speed?

Isn't that the intention of levels, like, fetch only my very important
mailboxes, e.g., with a level of 1.

,----[ (info "(gnus)Group Levels") ]
| All groups have a level of "subscribedness".  For instance, if a group
| is on level 2, it is more subscribed than a group on level 5.  You can
| ask Gnus to just list groups on a given level or lower (*note Listing
| Groups::), or to just check for new articles in groups on a given level
| or lower (*note Scanning New Messages::).
| 
|    Remember:  The higher the level of the group, the less important it
| is.
`----

Well, it seems you can also use them to structure your groups to list
only groups on a certain level, so they are somewhat orthogonal to
topics, too.

Bye,
Tassilo

Re: Gnus faces

[Andreas Schwab]

Tassilo Horn <tassilo@member.fsf.org> writes:

> IMHO, I'd have an inheritance hierarchy with a top-level "abstract"
> (i.e., not really used face) gnus-group, that is specialized by
> emptyness, then backend, and finally by levels.  (I think that in times
> of fast internet connections, the levels are the least important thing.

Why do you think that levels have something to do with network speed?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Gnus faces

[James Cloos]

>>>>> "TH" == Tassilo Horn <tassilo@member.fsf.org> writes:

TH> (I think that in times of fast internet connections, the levels are
TH> the least important thing.  I'd even go that far and remove their
TH> different defaults.  Feel free to disagree.)

Levels make a useful substitute for topics on slow boxen (on my laptop
topics are entirely unusable).  Also, even when the connection is local
the remote servers can be slow enough for levels to make sense.

(I got to like my lots-of-levels setup enough that I haven't tried
topics when emacs is running on the phenominally faster Phenom. ☺)

On on the thread’s topic (pun-filled, aren’t we?), if changes are
made, please make it easy to keep the current colours.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: Gnus faces

[Tassilo Horn]

Chong Yidong <cyd@stupidchicken.com> writes:

> Gnus defines a large number of faces for the Group, Summary, and
> Article buffers.  This makes it a pain for those who want impose a
> uniform color scheme on their Emacs, who must chage every one of these
> faces.

True.

> It would be better for the Gnus faces to :inherit from the standard
> Emacs font-lock faces.  After all, font-lock highlighting is not used
> in Gnus.  Thoughts?

Yes, that wouldn't be a bad idea.  Additionally, Gnus has different
faces for e.g. groups with respect to the backend (mail or news), the
level (1-4), and the "emptyness" (has unread or ticked articles or not),
so there are 16 different faces

  gnus-group-{mail,news}-{1,2,3,4}{,-empty}

just for customizing the face of groups in the *Group* buffer.  The
problem is that those faces don't inherit from each other.  So if I'd
like to make all non-empty groups underlined, I have at least to modify
8 faces.

IMHO, I'd have an inheritance hierarchy with a top-level "abstract"
(i.e., not really used face) gnus-group, that is specialized by
emptyness, then backend, and finally by levels.  (I think that in times
of fast internet connections, the levels are the least important thing.
I'd even go that far and remove their different defaults.  Feel free to
disagree.)

Bye,
Tassilo
-- 
Sent from my Emacs

Re: Gnus faces

[Lars Magne Ingebrigtsen]

Chong Yidong <cyd@stupidchicken.com> writes:

> Gnus defines a large number of faces for the Group, Summary, and Article
> buffers.  This makes it a pain for those who want impose a uniform color
> scheme on their Emacs, who must chage every one of these faces.

Yes...  but wouldn't using the new "theme" code fix that?

> It would be better for the Gnus faces to :inherit from the standard
> Emacs font-lock faces.  After all, font-lock highlighting is not used in
> Gnus.  Thoughts?

I'm not quite sure what that would entail.  Would all the faces change?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Gnus faces

[Chong Yidong]

Gnus defines a large number of faces for the Group, Summary, and Article
buffers.  This makes it a pain for those who want impose a uniform color
scheme on their Emacs, who must chage every one of these faces.

It would be better for the Gnus faces to :inherit from the standard
Emacs font-lock faces.  After all, font-lock highlighting is not used in
Gnus.  Thoughts?