Re: line-move-visual

[Tassilo Horn]

Uday S Reddy <uDOTsDOTreddy@cs.bham.ac.uk> writes:

>> With line-move-visual set to t (the default), only vertical motion
>> commands use visual lines, but for example C-a / C-e still use
>> logical lines.  From my point of view, that's a silly compromise.
>
> Agreed.  That means that line-move-visual is not doing what it says on
> the box.  I don't see a compelling reason why C-n and C-p should move
> by "visual lines" outside of visual-line-mode.  Perhaps it was a bad
> idea.

I remember that people (including RMS) tested line-move-visual and
concluded that this is ok, but full visual-line-mode would be too
radical.

> In the emacs-developers list, I see that line-move-visual came first
> and visual-line-mode was invented later.

I'm not completely sure about that.

>> But all visual line behavior break keyboard macros.  Define a macro,
>> then change your window size (so that lines are differently visually
>> wrapped), and *bang* your macro messes up your text.  It's semantics
>> change with the frame/window size.  That's silly.
>
> If these macros are dealing with visual-line-mode then I wonder what
> yo do that is sensitive to the line length.
>
> If they are dealing with normal text with line breaks, then perhaps
> all that you need to do is to use forward-line instead of next-line?

Well, the save solution is to enable `truncate-lines' (M-x
toggle-truncate-lines) before defining and executing a keyboard macro.
Then lines aren't wrapped, and there's no difference between logical and
visual lines anymore.

IMO, that should be done automatically.  But others argue, that a
keyboard macro should act exactly as doing the same stuff manually. Then
it's correct that a macro executed with VLM on or line-move-visual set
to t behaves differently depending on how text is visualized, which
includes window width, font size and other pitfalls you haven' thought
about...

Bye,
Tassilo