unofficial mirror of notmuch@notmuchmail.org
 help / color / mirror / code / Atom feed
From: Mark Walters <markwalters1009@gmail.com>
To: Austin Clements <amdragon@MIT.EDU>
Cc: Tomi Ollila <tomi.ollila@iki.fi>, notmuch@notmuchmail.org
Subject: Re: [PATCH] emacs: tweak error buffer handling
Date: Fri, 28 Dec 2012 09:03:08 +0000	[thread overview]
Message-ID: <87ip7my2er.fsf@qmul.ac.uk> (raw)
In-Reply-To: <20121227230402.GY6187@mit.edu>


Austin Clements <amdragon@MIT.EDU> writes:

> Quoth Mark Walters on Dec 26 at 10:27 pm:
>> 
>> On Tue, 25 Dec 2012, Tomi Ollila <tomi.ollila@iki.fi> wrote:
>> > On Sat, Dec 22 2012, Mark Walters <markwalters1009@gmail.com> wrote:
>> >
>> >> view-mode-enter changed between emacs 23 and emacs 24: the current
>> >> code makes the error buffer disappear in emacs 24 on quitting it (ie
>> >> pressing q) but this just kills the buffer without closing the split
>> >> window in emacs 23.
>> >>
>> >> This patch makes the error buffer window disappear in emacs 23
>> >> too. Since the view-mode-enter function changed we have to test for
>> >> version and do the correct thing in each case.
>> >> ---
>> >>
>> >> This seems to work but I have only tested on 23.4 and 24.2
>> >
>> > I run emacs 23.1.1 to get the documentation of view-mode-enter
>> > there. So, this patch instructs to delete WINDOW when exiting
>> > view mode...
>> >
>> > Documentation of pop-to-buffer says:
>> >
>> > "Select buffer BUFFER-OR-NAME in some window, preferably a different one."
>> >
>> > What if pop-up-windows's value is nil -- the content of current window
>> > is replaced with this view stuff -- and when exiting view mode, the
>> > window will be deleted ? What happens with emacs 24 in this case ?
>> 
>> Hi 
>> 
>> You are quite right there are problems here under emacs 23: if you
>> already have a split window when the error occurs in one part the error
>> is displayed in the other window and then on exit that (previously
>> existing) window is closed.
>> 
>> What do people think should happen on an error? I, personally, don't
>> like taking over an existing window, and Jamie liked some of the errors
>> (eg non-fatal `locked database' tagging errors) to be shown in the
>> mini-buffer.
>> 
>> I also think it is going to be difficult to get this right: emacs 23 and
>> 24 are different and there are also some user configuration variable
>> that affect what happens.
>
> How about showing all errors in the minibuffer (which could simply
> mean calling (error ...) and letting the Emacs top-level show it in
> the mini-buffer)?  We could log the verbose error details (like
> stdout) to some other buffer that we don't automatically show, but
> instead simply reference from the minibuffer message.  This would be
> more in line with how Emacs typically handles errors, and would make
> the details available to the user without flooding them with the
> details.

Hi 

That sounds great. In an ideal world we could behave slightly
differently for fatal errors but the common errors are likely to be
transient (locked database errors) so getting these right (which this
would do) seems the important step.

My view is that we should push a fix like the above for 0.15. What do
other people think?


Best wishes

Mark

  reply	other threads:[~2012-12-28  9:03 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-22 20:49 [PATCH] emacs: tweak error buffer handling Mark Walters
2012-12-25 21:05 ` Tomi Ollila
2012-12-26 22:27   ` Mark Walters
2012-12-27 23:04     ` Austin Clements
2012-12-28  9:03       ` Mark Walters [this message]
2012-12-28 12:44         ` David Bremner
2012-12-28 19:48           ` [PATCH] emacs: Use the minibuffer for CLI error reporting Austin Clements
2012-12-29 18:00             ` Mark Walters
2013-01-03  0:44               ` Austin Clements
2013-01-03 23:21                 ` David Bremner
2013-01-03  0:50             ` [PATCH v2] " Austin Clements
2013-01-03 21:47               ` [PATCH v3] " Austin Clements
2013-01-03 22:48                 ` Mark Walters
2013-01-06 21:12                   ` Austin Clements
2013-01-05 21:33                 ` Tomi Ollila
2013-01-07  2:54                 ` David Bremner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://notmuchmail.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ip7my2er.fsf@qmul.ac.uk \
    --to=markwalters1009@gmail.com \
    --cc=amdragon@MIT.EDU \
    --cc=notmuch@notmuchmail.org \
    --cc=tomi.ollila@iki.fi \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://yhetil.org/notmuch.git/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).