Better error reporting and stuff on startup

Better error reporting and stuff on startup

[Lars Magne Ingebrigtsen]

Today you get a lot of messages displayed for microseconds on Gnus
startup, and any error messages are just sort of hidden there.

Would it make sense for Gnus to (kind of) collect all the "important"
messages (to be determined somehow), and then display them at the end?
Somehow?

Hm.

We could have a global variable `gnus-important-messages' that
`gnus-message' pushes things onto if the message level is low?  And then
`M-x gnus' could bind that variable, and then display the contents after
startup?  Just with `message'?

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

Re: Better error reporting and stuff on startup

[Didier Verna]

Lars Magne Ingebrigtsen wrote:

> Today you get a lot of messages displayed for microseconds on Gnus
> startup, and any error messages are just sort of hidden there.
>
> Would it make sense for Gnus to (kind of) collect all the "important"
> messages (to be determined somehow), and then display them at the end?
> Somehow?

  Isn't #'warn sufficient for doing so? Warnings are automatically poped
up at the next redisplay (at least in XEmacs).

-- 
Resistance is futile. You will be jazzimilated.

Scientific site:   http://www.lrde.epita.fr/~didier
Music (Jazz) site: http://www.didierverna.com

Re: Better error reporting and stuff on startup

[Lars Magne Ingebrigtsen]

Didier Verna <didier@xemacs.org> writes:

>   Isn't #'warn sufficient for doing so? Warnings are automatically poped
> up at the next redisplay (at least in XEmacs).

warn pops up a new buffer.  That's too intrusive.

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

Re: Better error reporting and stuff on startup

[Didier Verna]

Lars Magne Ingebrigtsen wrote:

> warn pops up a new buffer.  That's too intrusive.

  But you said that you want to "display them at the end... somehow", so
poping a new buffer sounds pretty much like it. Besides, error messages
occurring at startup kind of deserve an intrusion IMHO.

-- 
Resistance is futile. You will be jazzimilated.

Scientific site:   http://www.lrde.epita.fr/~didier
Music (Jazz) site: http://www.didierverna.com

Re: Better error reporting and stuff on startup

[Lars Magne Ingebrigtsen]

Didier Verna <didier@xemacs.org> writes:

>   But you said that you want to "display them at the end... somehow", so
> poping a new buffer sounds pretty much like it. Besides, error messages
> occurring at startup kind of deserve an intrusion IMHO.

No, most of them are just that one of the 13 servers you're connecting
to didn't respond.  It's nice to know that it happened, but it's not an
exceptional situation.

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

Re: Better error reporting and stuff on startup

[Frank Schmitt]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Didier Verna <didier@xemacs.org> writes:
>
>>   But you said that you want to "display them at the end... somehow", so
>> poping a new buffer sounds pretty much like it. Besides, error messages
>> occurring at startup kind of deserve an intrusion IMHO.
>
> No, most of them are just that one of the 13 servers you're connecting
> to didn't respond.  It's nice to know that it happened, but it's not an
> exceptional situation.

Really? I mean, why would I try to connect to a server and not be
surprised if it fails?

-- 
Have you ever considered how much text can fit in eighty columns?  Given that a
signature typically contains up to four lines of text, this space allows you to
attach a tremendous amount of valuable information to your messages.  Seize the
opportunity and don't waste your signature on bullshit that nobody cares about.

Re: Better error reporting and stuff on startup

[Lars Magne Ingebrigtsen]

Frank Schmitt <ich@frank-schmitt.net> writes:

> Really? I mean, why would I try to connect to a server and not be
> surprised if it fails?

Because you're reading from four different nntp servers and three
different imap servers?

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

Re: Better error reporting and stuff on startup

[Didier Verna]

Lars Magne Ingebrigtsen wrote:

> No, most of them are just that one of the 13 servers you're connecting
> to didn't respond. It's nice to know that it happened, but it's not an
> exceptional situation.

  I'm not convinced, but anyway here's another idea: there are other
ways (than messages) to convey information to the user. For instance, I
use a hack that will display every group in the *Group* buffer in red if
the server denied or closed the connection.

Here goes:

;; Highlight group buffer lines according to the server status. With this, you
;; can choose to fontify group lines according the current status of the
;; group's server. Caveat: a server status change will not be immediately
;; visible in the group buffer. It has to be updated, for instance by getting
;; new mail.

;; How it works: the advice below adds a `server-status' local variable that
;; can be used in `gnus-group-highlight'. For instance, you can use forms like
;; (eq server-status 'closed) or (eq server-status 'denied) in conjunction
;; with the two following faces:
(defface gnus-group-server-denied-face '((t ()))
  "Face used for groups belonging to a denied server."
  :group 'gnus-group)

(defface gnus-group-server-closed-face '((t ()))
  "Face used for groups belonging to a denied server."
  :group 'gnus-group)

(defadvice gnus-group-highlight-line (around server-status activate)
  "Add a SERVER-STATUS local variable for use in `gnus-group-highlight'."
  (let (server-status)
    ;; Let's do this outside the let to avoid a load-time warning
    (setq server-status (gnus-server-status
			 (gnus-find-method-for-group
			  (gnus-group-group-name))))
    ad-do-it))


-- 
Resistance is futile. You will be jazzimilated.

Scientific site:   http://www.lrde.epita.fr/~didier
Music (Jazz) site: http://www.didierverna.com

Re: Better error reporting and stuff on startup

[Lars Magne Ingebrigtsen]

Didier Verna <didier@xemacs.org> writes:

>   I'm not convinced, but anyway here's another idea: there are other
> ways (than messages) to convey information to the user. For instance, I
> use a hack that will display every group in the *Group* buffer in red if
> the server denied or closed the connection.

These groups are already displayed with a "*".  I feed that drawing
attention to them more than that isn't normally warranted.

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

Re: Better error reporting and stuff on startup

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 505 bytes --]

On Sun, Sep 26 2010, Lars Magne Ingebrigtsen wrote:

> Today you get a lot of messages displayed for microseconds on Gnus
> startup, and any error messages are just sort of hidden there.
>
> Would it make sense for Gnus to (kind of) collect all the "important"
> messages (to be determined somehow), and then display them at the end?
> Somehow?

Sounds overkill. They are all in *Messages* if I need to re-see them.

-- 
Julien Danjou
// ᐰ <julien@danjou.info>   http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: Better error reporting and stuff on startup

[Tassilo Horn]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

Hi Lars,

> Would it make sense for Gnus to (kind of) collect all the "important"
> messages (to be determined somehow), and then display them at the end?
> Somehow?

That makes sense for any package, but not every package should need to
implement something like it.  So it would be cool to extend the
`message' mechanism in emacs, so that it allows for different severities
(debug, info, warning?) and assign messages to packages, so that I could
restrict *Messages* to show only warning messages from Gnus...

Bye,
Tassilo

Re: Better error reporting and stuff on startup

[Lars Magne Ingebrigtsen]

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

> That makes sense for any package, but not every package should need to
> implement something like it.  So it would be cool to extend the
> `message' mechanism in emacs, so that it allows for different severities
> (debug, info, warning?) and assign messages to packages, so that I could
> restrict *Messages* to show only warning messages from Gnus...

I don't really see how that would work.  Gnus is pretty unique in that
it does a lot of stuff on a single command.  I mean, a *lot*.  

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

Re: Better error reporting and stuff on startup

[Tassilo Horn]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

>> That makes sense for any package, but not every package should need
>> to implement something like it.  So it would be cool to extend the
>> `message' mechanism in emacs, so that it allows for different
>> severities (debug, info, warning?) and assign messages to packages,
>> so that I could restrict *Messages* to show only warning messages
>> from Gnus...
>
> I don't really see how that would work.

Well, maybe something like

  (message 'gnus 'debug "Foo bar %s" (bla))

which also puts text properties for the package and importance to the
entries in *Messages*.  Then some messages-mode could use that to narrow
or widen the buffer...

> Gnus is pretty unique in that it does a lot of stuff on a single
> command.  I mean, a *lot*.

I don't see how that contradicts my suggestion.

Bye,
Tassilo

Re: Better error reporting and stuff on startup

[Ted Zlatanov]

On Sun, 26 Sep 2010 20:11:29 +0200 Tassilo Horn <tassilo@member.fsf.org> wrote: 

TH> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>>> That makes sense for any package, but not every package should need
>>> to implement something like it.  So it would be cool to extend the
>>> `message' mechanism in emacs, so that it allows for different
>>> severities (debug, info, warning?) and assign messages to packages,
>>> so that I could restrict *Messages* to show only warning messages
>>> from Gnus...
>> 
>> I don't really see how that would work.

TH> Well, maybe something like

TH>   (message 'gnus 'debug "Foo bar %s" (bla))

I see xdisp.c:Vmessages_buffer_name but it's not exposed to ELisp code
as a symbol.  If it were, (gnus-message) could let-bind it so Gnus
messages can go to a separate *Gnus Messages* buffer.  It would probably
be helpful for other packages too.  I don't know if there are issues
with that besides the obvious usability problem of multiple log buffers.

Ted

Re: Better error reporting and stuff on startup

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> I see xdisp.c:Vmessages_buffer_name but it's not exposed to ELisp code
> as a symbol.  If it were, (gnus-message) could let-bind it so Gnus
> messages can go to a separate *Gnus Messages* buffer.  It would probably
> be helpful for other packages too.  I don't know if there are issues
> with that besides the obvious usability problem of multiple log buffers.

Having just one single message buffer is convenient for users, I think.

Although the default buffer size should probably be increased...

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

Re: Better error reporting and stuff on startup

[Rupert Swarbrick]

[-- Attachment #1: Type: text/plain, Size: 1515 bytes --]

Tassilo Horn <tassilo@member.fsf.org> writes:
>> Would it make sense for Gnus to (kind of) collect all the "important"
>> messages (to be determined somehow), and then display them at the end?
>> Somehow?
>
> That makes sense for any package, but not every package should need to
> implement something like it.  So it would be cool to extend the
> `message' mechanism in emacs, so that it allows for different severities
> (debug, info, warning?) and assign messages to packages, so that I could
> restrict *Messages* to show only warning messages from Gnus...

Hmm, but how would the user use this? I mean, what presumably happens at
the moment is that Jo Bloggs types M-x gnus, waits a second (while
watching flickering stuff at the bottom of the screen) then sees that
some groups have '*'s rather than numbers. If he[1] knows a reasonable
amount about emacs then, swearing to himself, he goes to *Messages*. If
he's lucky, the messages haven't yet scrolled out of the buffer. Next
time he hits 'g' or types M-x gnus, everything mysteriously works (the
server or net connection is back up).

Now, how would a proposal to allow the user to filter only warning-level
messages help Jo?

I'm not sure whether Lars's idea is perfect, but it seems that whatever
solution chosen, it should be one that the user doesn't have to
configure. Especially since Gnus interacts with the outside world via
the network so is going to be exposed to all sorts of transient faults.


Rupert


[1] Or she. Hence it being Jo not Joe.

[-- Attachment #2: Type: application/pgp-signature, Size: 315 bytes --]

Re: Better error reporting and stuff on startup

[Richard Riley]

Rupert Swarbrick <rswarbrick@gmail.com> writes:

> Tassilo Horn <tassilo@member.fsf.org> writes:
>>> Would it make sense for Gnus to (kind of) collect all the "important"
>>> messages (to be determined somehow), and then display them at the end?
>>> Somehow?
>>
>> That makes sense for any package, but not every package should need to
>> implement something like it.  So it would be cool to extend the
>> `message' mechanism in emacs, so that it allows for different severities
>> (debug, info, warning?) and assign messages to packages, so that I could
>> restrict *Messages* to show only warning messages from Gnus...
>
> Hmm, but how would the user use this? I mean, what presumably happens at
> the moment is that Jo Bloggs types M-x gnus, waits a second (while
> watching flickering stuff at the bottom of the screen) then sees that
> some groups have '*'s rather than numbers. If he[1] knows a reasonable
> amount about emacs then, swearing to himself, he goes to *Messages*. If
> he's lucky, the messages haven't yet scrolled out of the buffer. Next
> time he hits 'g' or types M-x gnus, everything mysteriously works (the
> server or net connection is back up).
>
> Now, how would a proposal to allow the user to filter only warning-level
> messages help Jo?

Assuming the messages contain properties indicating severity and package
its but a hot key away from gnus to  syphon out the relative messages.
>
> I'm not sure whether Lars's idea is perfect, but it seems that whatever
> solution chosen, it should be one that the user doesn't have to
> configure. Especially since Gnus interacts with the outside world via
> the network so is going to be exposed to all sorts of transient faults.

Not all the time no. Often it only deals with local servers : local imap
and possibly a leafnode nntp proxy. In fact I bet gnus is used with
local sources pretty often and other tools do the actual push and pull.

Re: Better error reporting and stuff on startup

[Didier Verna]

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

> That makes sense for any package, but not every package should need to
> implement something like it. So it would be cool to extend the
> `message' mechanism in emacs, so that it allows for different
> severities (debug, info, warning?) and assign messages to packages, so
> that I could restrict *Messages* to show only warning messages from
> Gnus...

  This already exists (at least in XEmacs): see the documentation for
#'display-warning. No, really, Lars, everything's here already :-)

-- 
Resistance is futile. You will be jazzimilated.

Scientific site:   http://www.lrde.epita.fr/~didier
Music (Jazz) site: http://www.didierverna.com

Re: Better error reporting and stuff on startup

[Lars Magne Ingebrigtsen]

Didier Verna <didier@xemacs.org> writes:

>   This already exists (at least in XEmacs): see the documentation for
> #'display-warning. No, really, Lars, everything's here already :-)

Way too intrusive for this kind of thing.

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

Re: Better error reporting and stuff on startup

[Dan Christensen]

There could be a status region at the top of the group buffer which
shows which servers were denied, and any other recent important
messages.  Not sure how useful this would be, though.

Dan

Re: Better error reporting and stuff on startup

[Dan Christensen]

The new startup warnings showed me the message:

  Ignoring disappeared server `nnimap:pi'

I did have a server like this long ago, but I can't find any reference
to it in my .newsrc.eld or in my .gnus.el.  Could it be somewhere else?

Dan

Re: Better error reporting and stuff on startup

[Lars Magne Ingebrigtsen]

Dan Christensen <jdc@uwo.ca> writes:

> The new startup warnings showed me the message:
>
>   Ignoring disappeared server `nnimap:pi'
>
> I did have a server like this long ago, but I can't find any reference
> to it in my .newsrc.eld or in my .gnus.el.  Could it be somewhere else?

It's from the gnus-agent code, so it's probably in one of the agent
files somewhere.

It's not very important, though, so I've now changed its level to 8, and
you'll no longer see the message.

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