unofficial mirror of bug-gnu-emacs@gnu.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

* bug#10726: 24.0.93; `find-file-noselect': why should it interrogate the user?
  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
  0 siblings, 1 reply; 3+ messages in thread
From: Stefan Monnier @ 2012-02-06 14:11 UTC (permalink / raw)
  To: Drew Adams; +Cc: 10726

severity 10726 wishlist
thanks

> 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

FWIW, I largely agree on the principle.  But I think that requires
non-trivial changes, including maybe adding a new "really
non-interactive" version of find-file-noselect.


        Stefan





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

* bug#10726: 24.0.93; `find-file-noselect': why should it interrogate the user?
  2012-02-06 14:11 ` Stefan Monnier
@ 2012-02-06 15:39   ` Drew Adams
  0 siblings, 0 replies; 3+ messages in thread
From: Drew Adams @ 2012-02-06 15:39 UTC (permalink / raw)
  To: 'Stefan Monnier'; +Cc: 10726

> > 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.  
> 
> FWIW, I largely agree on the principle.  But I think that requires
> non-trivial changes, including maybe adding a new "really
> non-interactive" version of find-file-noselect.

Yes.  That's the point of the bug report.  It would mean factoring out the truly
non-interactive part as the real `find-file-noselect' and using the
interrogation part as a wrapper that is called by commands when used
interactively.






^ 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 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).