all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: 10726@debbugs.gnu.org
Subject: bug#10726: 24.0.93; `find-file-noselect': why should it interrogate the user?
Date: Sat, 4 Feb 2012 11:25:15 -0800	[thread overview]
Message-ID: <012A5E800AD44CC090696172BAD6F5A3@us.oracle.com> (raw)

I'm evaluating some Lisp code I'm testing.  It is non-interactive code.
I invoke it using `M-:', which I've bound to `pp-eval-expression'.
 
I first visit a read-only file.  Then I change the file (using
`dired-do-chmod') to writable.  Then I use `M-:' to eval a sexp that
does `find-file-noselect'.
 
Even though the code was not invoked interactively (`M-:' should not be
counted as interactive here), I got this interactive dialog from
`find-file-noselect':
 
"File foobar.toto is writable on disk.  Change buffer mode? "
 
When this happened I was quite surprised, and I had almost no idea what
was going on.  I did not know how to answer the question posed.  The
question did not even tell me which buffer it proposed changing the mode
of.
 
This interrogation does not seem right.  When evaluating code this way
(and for other non-interacive evaluations) the user might have no idea
even that a file is being visited by the code.  After all, this is
`find-file-noselect', not `find-file'.
 
Why should `find-file-noselect' interact with the user directly using
_any_ dialog?  I can see why some particular code that _invokes_
`find-file-noselect' might choose to ask the user a question.  And I can
see why `find-file-noselect' itself might raise an error in some
situations.  But I do not see why `find-file-noselect' should ever
interrogate the user.
 
I do see that `find-file-noselect' has been posing questions to the user
since Day One.  But I do not see why that is appropriate.  I would think
that this function should be only for Lisp code to work on a file in a
buffer.
 
We could conceivably pass `find-file-noselect' a new optional argument
that would indicate whether `find-file-noselect' should question the
user to find out more information that might help the function do its
job, and if not just punt (e.g. raise an error) if it cannot proceed
normally.  But why should it systematically do such interactive stuff?
 
When a user gets such a question in the context of `find-file-noselect'
being invoked by `find-file' or some other _command_, the questioning is
understandable - I've never been shocked by it in such a context.  But
in this case I was surprised and perplexed.
 
In GNU Emacs 24.0.93.1 (i386-mingw-nt5.1.2600)
 of 2012-01-29 on MARVIN
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (4.6) --no-opt --cflags
 -ID:/devel/emacs/libs/libXpm-3.5.8/include
 -ID:/devel/emacs/libs/libXpm-3.5.8/src
 -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
 -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
 -ID:/devel/emacs/libs/giflib-4.1.4-1/include
 -ID:/devel/emacs/libs/jpeg-6b-4/include
 -ID:/devel/emacs/libs/tiff-3.8.2-1/include
 -ID:/devel/emacs/libs/gnutls-3.0.9/include --ldflags
 -LD:/devel/emacs/libs/gnutls-3.0.9/lib'
 






             reply	other threads:[~2012-02-04 19:25 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-04 19:25 Drew Adams [this message]
2012-02-06 14:11 ` bug#10726: 24.0.93; `find-file-noselect': why should it interrogate the user? Stefan Monnier
2012-02-06 15:39   ` Drew Adams

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

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

  git send-email \
    --in-reply-to=012A5E800AD44CC090696172BAD6F5A3@us.oracle.com \
    --to=drew.adams@oracle.com \
    --cc=10726@debbugs.gnu.org \
    /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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.