all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#10726: 24.0.93; `find-file-noselect': why should it interrogate the user?
@ 2012-02-04 19:25 Drew Adams
  2012-02-06 14:11 ` Stefan Monnier
  0 siblings, 1 reply; 3+ messages in thread
From: Drew Adams @ 2012-02-04 19:25 UTC (permalink / raw)
  To: 10726

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'
 






^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2012-02-06 15:39 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-02-04 19:25 bug#10726: 24.0.93; `find-file-noselect': why should it interrogate the user? Drew Adams
2012-02-06 14:11 ` Stefan Monnier
2012-02-06 15:39   ` Drew Adams

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.