On 9/20/11 6:52 AM, gregrwm wrote:
>> The code has been this way for over 20 years, so this is a
>> very-infrequently-encountered problem. I will have to look at the startup
>> hook the command uses to see if I can fix it up there.
I fixed the problem, and the fix will be in the next version.
> fwiw you might also note the behaviour of ^O operating on a multiline
> command is inconsistent between whether the multiline command was
> entered in the current session or was found in the history file. if
> from current session the entire multiline command re-enters the
> command buffer, if from the history file it reenters the command
> buffer one line at a time. i don't consider this a problem, but it
> may or may not be related to what you've found.
That's not exactly the case, but it ends up seeming that way. The command
is saved in the history list as a single entry, because the `cmdhist'
(command-oriented history) option is enabled by default. Since it's a
quoted string, it's stored in the history list with literal newlines
embedded. When that command is written to the history file, which is a
sequence of lines terminated by newlines, the multi-line quoted string is
indistinguishable from separate history entries.
The code that reads the history from the history file doesn't (and, in
general, can't) distinguish between the two cases, so all lines end up
as separate history entries.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
