unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Eric Abrahamsen <eric@ericabrahamsen.net>
Cc: emacs-devel@gnu.org
Subject: Re: [Emacs-diffs] emacs-26 03bb7a8: Avoid clearing echo-area message by auto-save-visited-file-name
Date: Tue, 27 Nov 2018 07:44:19 +0200	[thread overview]
Message-ID: <83pnurgjm4.fsf@gnu.org> (raw)
In-Reply-To: <87bm6bblfp.fsf@ericabrahamsen.net> (message from Eric Abrahamsen on Mon, 26 Nov 2018 13:03:54 -0800)

> From: Eric Abrahamsen <eric@ericabrahamsen.net>
> Date: Mon, 26 Nov 2018 13:03:54 -0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Eric Abrahamsen <eric@ericabrahamsen.net>
> >> Date: Mon, 26 Nov 2018 12:11:46 -0800
> >> 
> >> Well... I highly doubt I've seen something you haven't, but the
> >> following seems to work correctly, doesn't it?
> >
> > How can I tell?
> 
> The "Hi!" message remains visible after the `map-y-or-n-p' call returns.

That's not what I meant.  My problem is that this change was done on
the release branch, and is part of both auto-save-visited-file-name
and of save-some-buffers, the latter is an important frequently used
command.  I need to be absolutely sure using with-temp-message doesn't
change these use cases in any significant way, to be able to use it on
the release branch.  And neither the non-trivial code of
with-temp-message nor its doc string allow me to convince myself that
this is the case.

So if you think my change is equivalent to using with-temp-message,
I'm okay with doing that on master, but on emacs-26 I would need a
much stronger evidence than just its working in a single simple use
case.

Thanks.

P.S. May I please request that people who watch the emacs-diffs list
and respond to changes please subscribe to the bug list, where the
changes are normally discussed for several days before they are
pushed?  It is very inefficient, to say the least, to have a change
discussed, only to hear comments on it after it's already pushed.  The
discussions on the bug list, and the few days we usually wait for more
comments, are precisely to allow more people to chime in.

TIA



  reply	other threads:[~2018-11-27  5:44 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20181126172847.31607.25553@vcs0.savannah.gnu.org>
     [not found] ` <20181126172848.D835220427@vcs0.savannah.gnu.org>
2018-11-26 17:43   ` [Emacs-diffs] emacs-26 03bb7a8: Avoid clearing echo-area message by auto-save-visited-file-name Stefan Monnier
2018-11-26 18:11     ` Eli Zaretskii
2018-11-26 19:20       ` Eric Abrahamsen
2018-11-26 19:31         ` Eli Zaretskii
2018-11-26 20:11           ` Eric Abrahamsen
2018-11-26 20:45             ` Eli Zaretskii
2018-11-26 21:03               ` Eric Abrahamsen
2018-11-27  5:44                 ` Eli Zaretskii [this message]
2018-11-27 17:30                   ` Eric Abrahamsen

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://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=83pnurgjm4.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=eric@ericabrahamsen.net \
    /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://git.savannah.gnu.org/cgit/emacs.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).