unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#18340: 24.4.50; Bad UI for `find-file-literally'
@ 2014-08-27 21:37 Drew Adams
  2016-05-04  0:59 ` Lars Ingebrigtsen
  2021-10-10 22:30 ` Stefan Kangas
  0 siblings, 2 replies; 10+ messages in thread
From: Drew Adams @ 2014-08-27 21:37 UTC (permalink / raw)
  To: 18340

Summary: Don't show a multi-line message for prompting `y-or-n-p'
in the echo area and expect users to see it.

The UI for `find-file-literally' depends on `resize-mini-windows' being
non-nil.  Not a good idea.  To see how bad it can be, set
`resize-mini-windows' to nil, then visit a file, then try to visit it
using `M-x find-file-literally'.  You see only this line in the echo
area, which is not even a question:

  The file foo.el is already visited normally.

Huh?  A user who sees that has no clue as to what is going on.

Beyond this design being incredibly ill-advised in general, it breaks
the use of a standalone minibuffer frame, for which
`resize-mini-windows' has no effect.  In my code, for example, I do this,
where `'1on1-fit-minibuffer-frame' resizes the minibuffer frame to fit
its current contents:

  (add-hook 'post-command-hook '1on1-fit-minibuffer-frame)

That of course has no effect during `read-key', which is what is used by
`y-or-n-p' (which is used by `find-file-literally').

`1on1-fit-minibuffer-frame' is also a command that increases the
minibuffer frame height by a line when it is repeated.  It is bound
in the minibuffer to `C-o'.  But of course that is ineffective for
something like `y-or-n-p', which does not use the minibuffer.

Please reimplement the multiple-line message and associated y-or-n
question for `find-file-literally', so that the message part is visible
somewhere outside of the echo area.  Pop up a separate window for it,
show it in a tooltip, or show it any number of other reasonable ways.


In GNU Emacs 24.4.50.1 (i686-pc-mingw32)
 of 2014-08-15 on LEG570
Bzr revision: 117706 rgm@gnu.org-20140815043406-p5hbu97cbm7pulcn
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --enable-checking 'CFLAGS=-O0 -g3' CPPFLAGS=-DGLYPH_DEBUG=1'





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

* bug#18340: 24.4.50; Bad UI for `find-file-literally'
  2014-08-27 21:37 bug#18340: 24.4.50; Bad UI for `find-file-literally' Drew Adams
@ 2016-05-04  0:59 ` Lars Ingebrigtsen
  2016-05-04 14:47   ` Eli Zaretskii
  2021-10-10 22:30 ` Stefan Kangas
  1 sibling, 1 reply; 10+ messages in thread
From: Lars Ingebrigtsen @ 2016-05-04  0:59 UTC (permalink / raw)
  To: Drew Adams; +Cc: 18340

Drew Adams <drew.adams@oracle.com> writes:

> Summary: Don't show a multi-line message for prompting `y-or-n-p'
> in the echo area and expect users to see it.
>
> The UI for `find-file-literally' depends on `resize-mini-windows' being
> non-nil.  Not a good idea.  To see how bad it can be, set
> `resize-mini-windows' to nil, then visit a file, then try to visit it
> using `M-x find-file-literally'.  You see only this line in the echo
> area, which is not even a question:
>
>   The file foo.el is already visited normally.

We should perhaps consider obsoleting `resize-mini-windows'.  Emacs has
many prompts now that don't make sense in a single line.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





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

* bug#18340: 24.4.50; Bad UI for `find-file-literally'
  2016-05-04  0:59 ` Lars Ingebrigtsen
@ 2016-05-04 14:47   ` Eli Zaretskii
  0 siblings, 0 replies; 10+ messages in thread
From: Eli Zaretskii @ 2016-05-04 14:47 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 18340

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Wed, 04 May 2016 02:59:36 +0200
> Cc: 18340@debbugs.gnu.org
> 
> Drew Adams <drew.adams@oracle.com> writes:
> 
> > Summary: Don't show a multi-line message for prompting `y-or-n-p'
> > in the echo area and expect users to see it.
> >
> > The UI for `find-file-literally' depends on `resize-mini-windows' being
> > non-nil.  Not a good idea.  To see how bad it can be, set
> > `resize-mini-windows' to nil, then visit a file, then try to visit it
> > using `M-x find-file-literally'.  You see only this line in the echo
> > area, which is not even a question:
> >
> >   The file foo.el is already visited normally.
> 
> We should perhaps consider obsoleting `resize-mini-windows'.  Emacs has
> many prompts now that don't make sense in a single line.

Those prompts should bind resize-mini-windows non-nil.

I don't understand the rest of the bug report, but the specific part
about find-file-literally will be definitely fixed by that.





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

* bug#18340: 24.4.50; Bad UI for `find-file-literally'
       [not found]   ` <<83futxkhhd.fsf@gnu.org>
@ 2016-05-04 15:05     ` Drew Adams
  2016-05-04 15:23       ` Eli Zaretskii
  0 siblings, 1 reply; 10+ messages in thread
From: Drew Adams @ 2016-05-04 15:05 UTC (permalink / raw)
  To: Eli Zaretskii, Lars Ingebrigtsen; +Cc: 18340

> > We should perhaps consider obsoleting `resize-mini-windows'.  Emacs has
> > many prompts now that don't make sense in a single line.
> 
> Those prompts should bind resize-mini-windows non-nil.
> 
> I don't understand the rest of the bug report, 

What don't you understand about it?  (To quote a famous person.)

> but the specific part about find-file-literally will be
> definitely fixed by that.

I don't think so.  `resize-mini-windows' will do nothing for a
standalone minibuffer.  Again: "Don't show a multi-line message
for prompting `y-or-n-p' in the echo area and expect users to see it."

It is NOT a good idea to depend on `resize-mini-windows' showing
all of a multi-line message.

If the code _really_ needs to interact with the user using a
multi-line message, then `y-or-n-p' is the _wrong_ way to ask
the question.  If users need to read multiple lines then hitting
a single key to choose is probably not appropriate.

This should be rethought, IMO.  If the prompt cannot reasonably
be a single line then some other interaction should be used.
Do not just look for a way to force minibuffer-window resizing.





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

* bug#18340: 24.4.50; Bad UI for `find-file-literally'
  2016-05-04 15:05     ` Drew Adams
@ 2016-05-04 15:23       ` Eli Zaretskii
  0 siblings, 0 replies; 10+ messages in thread
From: Eli Zaretskii @ 2016-05-04 15:23 UTC (permalink / raw)
  To: Drew Adams; +Cc: 18340, larsi

> Date: Wed, 4 May 2016 08:05:04 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 18340@debbugs.gnu.org
> 
> > > We should perhaps consider obsoleting `resize-mini-windows'.  Emacs has
> > > many prompts now that don't make sense in a single line.
> > 
> > Those prompts should bind resize-mini-windows non-nil.
> > 
> > I don't understand the rest of the bug report, 
> 
> What don't you understand about it?

I understood nothing beyond the example with resize-mini-windows and a
normal frame which has a minibuffer.

> > but the specific part about find-file-literally will be
> > definitely fixed by that.
> 
> I don't think so.  `resize-mini-windows' will do nothing for a
> standalone minibuffer.

Please show a recipe, as I didn't understand the problem.  Repeating
what you said the first time doesn't help.

> Again: "Don't show a multi-line message for prompting `y-or-n-p' in
> the echo area and expect users to see it."

Please let us judge what would be the best solution for problems.

> It is NOT a good idea to depend on `resize-mini-windows' showing
> all of a multi-line message.

You contradict yourself: above you said that the value of
resize-mini-windows doesn't necessarily help.

> If the code _really_ needs to interact with the user using a
> multi-line message, then `y-or-n-p' is the _wrong_ way to ask
> the question.  If users need to read multiple lines then hitting
> a single key to choose is probably not appropriate.

I don't think I agree.  I see no reason to treat single-line and
multi-line prompts differently, not without a good reason.  The fact
that there's more than one line doesn't cut it.

> This should be rethought, IMO.  If the prompt cannot reasonably
> be a single line then some other interaction should be used.
> Do not just look for a way to force minibuffer-window resizing.

Once again, please don't dictate solutions for problems.





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

* bug#18340: 24.4.50; Bad UI for `find-file-literally'
  2014-08-27 21:37 bug#18340: 24.4.50; Bad UI for `find-file-literally' Drew Adams
  2016-05-04  0:59 ` Lars Ingebrigtsen
@ 2021-10-10 22:30 ` Stefan Kangas
  2021-10-11  1:06   ` bug#18340: [External] : " Drew Adams
  2021-10-11  6:17   ` Juri Linkov
  1 sibling, 2 replies; 10+ messages in thread
From: Stefan Kangas @ 2021-10-10 22:30 UTC (permalink / raw)
  To: Drew Adams; +Cc: 18340

tags 18340 + moreinfo
thanks

Drew Adams <drew.adams@oracle.com> writes:

> Summary: Don't show a multi-line message for prompting `y-or-n-p'
> in the echo area and expect users to see it.
>
> The UI for `find-file-literally' depends on `resize-mini-windows' being
> non-nil.  Not a good idea.  To see how bad it can be, set
> `resize-mini-windows' to nil, then visit a file, then try to visit it
> using `M-x find-file-literally'.  You see only this line in the echo
> area, which is not even a question:
>
>   The file foo.el is already visited normally.
>
> Huh?  A user who sees that has no clue as to what is going on.

Eli Zaretskii <eliz@gnu.org> writes:

> Please show a recipe, as I didn't understand the problem.

I also don't understand the problem.  I tried doing the above steps with
(setq resize-mini-windows nil) and I don't see anything that is
different from when it is t.

Could we have a recipe to reproduce this issue?





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

* bug#18340: [External] : Re: bug#18340: 24.4.50; Bad UI for `find-file-literally'
  2021-10-10 22:30 ` Stefan Kangas
@ 2021-10-11  1:06   ` Drew Adams
  2021-10-11 11:57     ` Eli Zaretskii
  2021-10-11  6:17   ` Juri Linkov
  1 sibling, 1 reply; 10+ messages in thread
From: Drew Adams @ 2021-10-11  1:06 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: 18340@debbugs.gnu.org

It's hard for me to believe that this bug report
hasn't been understood.  Let me try one last time.

Emacs 27.2, emacs -Q

foo.el is an existing Elisp file (contents not important).
_______

(setq resize-mini-windows nil)

C-x C-f foo.el

M-x find-file-literally RET foo.el RET

  Do you want to revisit the file literally now? (y or n) y

  You can run the command ‘find-file-literally’ with M-x f-f-l RET

  The file foo.el is already visited normally.
_______

That's all you see.  It's not understandable (to
me).  However, if I go look in *Messages* I see
this additional text, which was not visible
because `resize-mini-windows' is nil:
________
 You have asked to visit it literally,
 meaning no coding system decoding, format conversion, or local variables.
 But Emacs can visit a file in only one way at a time.
________

If you still don't understand the problem, drop it.

But if you now understand the problem, and repro it,
then I'll ask you to reread the original bug report
and see if it doesn't make sense on its own.

I think it does, and I'd completely forgotten about
this bug report.  I just read it afresh myself now,
and I just did what it describes, and saw the
reported problem immediately.

Clearly I'm missing something about what's missing
in others trying to understand this.

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

* bug#18340: 24.4.50; Bad UI for `find-file-literally'
  2021-10-10 22:30 ` Stefan Kangas
  2021-10-11  1:06   ` bug#18340: [External] : " Drew Adams
@ 2021-10-11  6:17   ` Juri Linkov
  2021-10-11 11:41     ` Stefan Kangas
  1 sibling, 1 reply; 10+ messages in thread
From: Juri Linkov @ 2021-10-11  6:17 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: 18340

>> Summary: Don't show a multi-line message for prompting `y-or-n-p'
>> in the echo area and expect users to see it.
>...
>
> Could we have a recipe to reproduce this issue?

This is already fixed in Emacs 28 where this prompt is not multi-line
anymore (commit 0a8cd0116204354e95fbb4ebde64c58123502aa2 from bug#5423).





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

* bug#18340: 24.4.50; Bad UI for `find-file-literally'
  2021-10-11  6:17   ` Juri Linkov
@ 2021-10-11 11:41     ` Stefan Kangas
  0 siblings, 0 replies; 10+ messages in thread
From: Stefan Kangas @ 2021-10-11 11:41 UTC (permalink / raw)
  To: Juri Linkov; +Cc: 18340

unarchive 5423
forcemerge 5423 18340
thanks

Juri Linkov <juri@linkov.net> writes:

>>> Summary: Don't show a multi-line message for prompting `y-or-n-p'
>>> in the echo area and expect users to see it.
>>...
>>
>> Could we have a recipe to reproduce this issue?
>
> This is already fixed in Emacs 28 where this prompt is not multi-line
> anymore (commit 0a8cd0116204354e95fbb4ebde64c58123502aa2 from bug#5423).

Right.  I'm merging the bug reports, so that this one is also closed.





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

* bug#18340: [External] : Re: bug#18340: 24.4.50; Bad UI for `find-file-literally'
  2021-10-11  1:06   ` bug#18340: [External] : " Drew Adams
@ 2021-10-11 11:57     ` Eli Zaretskii
  0 siblings, 0 replies; 10+ messages in thread
From: Eli Zaretskii @ 2021-10-11 11:57 UTC (permalink / raw)
  To: Drew Adams; +Cc: 18340, stefan

> From: Drew Adams <drew.adams@oracle.com>
> CC: "18340@debbugs.gnu.org" <18340@debbugs.gnu.org>,
>         Eli Zaretskii
> 	<eliz@gnu.org>
> Date: Mon, 11 Oct 2021 01:06:09 +0000
> 
> (setq resize-mini-windows nil)
> 
> C-x C-f foo.el
> 
> M-x find-file-literally RET foo.el RET
> 
>   Do you want to revisit the file literally now? (y or n) y
> 
>   You can run the command ‘find-file-literally’ with M-x f-f-l RET
> 
>   The file foo.el is already visited normally.
> _______
> 
> That's all you see.  It's not understandable (to
> me).  However, if I go look in *Messages* I see
> this additional text, which was not visible
> because `resize-mini-windows' is nil:

This problem doesn't exist in Emacs 28, so the issue was resolved.





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

end of thread, other threads:[~2021-10-11 11:57 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-08-27 21:37 bug#18340: 24.4.50; Bad UI for `find-file-literally' Drew Adams
2016-05-04  0:59 ` Lars Ingebrigtsen
2016-05-04 14:47   ` Eli Zaretskii
2021-10-10 22:30 ` Stefan Kangas
2021-10-11  1:06   ` bug#18340: [External] : " Drew Adams
2021-10-11 11:57     ` Eli Zaretskii
2021-10-11  6:17   ` Juri Linkov
2021-10-11 11:41     ` Stefan Kangas
     [not found] <<9fd1f4c3-a944-4305-9eb5-9f3a877d1b8b@default>
     [not found] ` <<877ffazlhj.fsf@gnus.org>
     [not found]   ` <<83futxkhhd.fsf@gnu.org>
2016-05-04 15:05     ` Drew Adams
2016-05-04 15:23       ` Eli Zaretskii

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