RE: Losing minibuffer input

[Drew Adams <drew.adams@oracle.com>]

> when editing multi-line text in the minibuffer: it's too easy to lose
> edited text by pressing an up-down arrow key with the intention to go
> to the next/previous line like in a normal buffer.  The changes are
> lost because the up-down key has a special meaning in the minibuffer
> to go to the next/previous history item.

So just don't do that.  Use `C-n' & `C-p' to move to a different line.

And you can always use `undo' to undo any such boo-boo and get back
what (you think) you lost.  You can _edit_ text in the minibuffer.
In particular, `undo' works fine.

But if the vanilla Emacs behavior really bothers you, then customize
bindings in your `minibuffer-local-map' - for your own use.  Trivial
to do.

> The fix is simple:

It ain't broke; don't fix it.

> allow up-down arrow keys to have their usual behavior and only on
> hitting the beginning/end of the minibuffer move to the next
> or previous history item, thus making navigation more smooth and
> continuous.

So now users will need to move point to the beginning or end of the
minibuffer, just to get `up' and `down' to navigate the history list?

No thanks.

>(define-key map [down]  'next-line-or-history-element)
>(define-key map [up]    'previous-line-or-history-element)
> 
> (defun next-line-or-history-element (&optional arg)
>   "Move cursor vertically down ARG lines, or to the next history element.
> When point is at the bottom line of multi-line minibuffer, puts ARGth
> next element of the minibuffer history in the minibuffer."

The language here even underlines how much of a mishmash this is.
Move _the cursor_ to the next history element?  I don't think so.

This behavior is not only not handy; it is also confusing.