bug#18340: 24.4.50; Bad UI for `find-file-literally'

[Drew Adams]

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'