Visual line movement inconsistency

Visual line movement inconsistency

[Tassilo Horn]

Hi all,

since some time C-n/C-p move by visual/screen lines, not by logical.
Basically, I like that behavior, but I found it very confusing that
C-a/C-e don't work on visual lines.  A quick look into the docs showed
that I have to enable visual-line-mode, and with that turned on I'm
quite satisfied (although I don't like word-wrapping without fringe
indicators, so I added them back).

But is this inconsistent behavior of C-n/C-p and C-a/C-e really the
intended default?  I think it would be better if C-a/C-e respected the
value of `line-move-visual', too.  Then the default would be like
visual-line-mode without word-wrapping.

Bye,
Tassilo

Re: Visual line movement inconsistency

[Miles Bader]

Tassilo Horn <tassilo@member.fsf.org> writes:
> But is this inconsistent behavior of C-n/C-p and C-a/C-e really the
> intended default?  I think it would be better if C-a/C-e respected the
> value of `line-move-visual', too.  Then the default would be like
> visual-line-mode without word-wrapping.

It was discussed and the current behavior seemed to be the consensus
choice.

I agree that it can be confusing, but I think it's much more dangerous
to change the default behavior of C-a/C-e, because people depend a lot
more on their precise behavior (whereas C-n/C-p are more often used in
conjunction with visual feedback).

-Miles

-- 
Alliance, n. In international politics, the union of two thieves who have
their hands so deeply inserted in each other's pockets that they cannot
separately plunder a third.

Re: Visual line movement inconsistency

[Tassilo Horn]

Miles Bader <miles@gnu.org> writes:

Hi Miles,

>> But is this inconsistent behavior of C-n/C-p and C-a/C-e really the
>> intended default?  I think it would be better if C-a/C-e respected
>> the value of `line-move-visual', too.  Then the default would be like
>> visual-line-mode without word-wrapping.
>
> It was discussed and the current behavior seemed to be the consensus
> choice.
>
> I agree that it can be confusing, but I think it's much more dangerous
> to change the default behavior of C-a/C-e, because people depend a lot
> more on their precise behavior

I see.  But at least there should be some way to move to the
beginning/end of a visual line.  Maybe an option or simply some new
binding.

Bye,
Tassilo
-- 
A morning without coffee is like something without something else.

Re: Visual line movement inconsistency

[Lennart Borgman (gmail)]

Tassilo Horn wrote:
> Miles Bader <miles@gnu.org> writes:
> 
> Hi Miles,
> 
>>> But is this inconsistent behavior of C-n/C-p and C-a/C-e really the
>>> intended default?  I think it would be better if C-a/C-e respected
>>> the value of `line-move-visual', too.  Then the default would be like
>>> visual-line-mode without word-wrapping.
>> It was discussed and the current behavior seemed to be the consensus
>> choice.
>>
>> I agree that it can be confusing, but I think it's much more dangerous
>> to change the default behavior of C-a/C-e, because people depend a lot
>> more on their precise behavior
> 
> I see.  But at least there should be some way to move to the
> beginning/end of a visual line.  Maybe an option or simply some new
> binding.


I have been using something like this for a while

(defun ourcomments-move-beginning-of-line(arg)
  "Move point to beginning of line or indentation.
See `beginning-of-line' for ARG.

If `physical-line-mode' is on then the visual line beginning is
first tried."
  (interactive "p")
  (let ((pos (point)))
    (call-interactively 'beginning-of-line arg)
    (when (= pos (point))
      (if (= 0 (current-column))
          (skip-chars-forward " \t")
        (backward-char)
        (beginning-of-line)))))
(put 'ourcomments-move-beginning-of-line 'CUA 'move)

Re: Visual line movement inconsistency

[Kim F. Storm]

Miles Bader <miles@gnu.org> writes:

> Tassilo Horn <tassilo@member.fsf.org> writes:
>> But is this inconsistent behavior of C-n/C-p and C-a/C-e really the
>> intended default?  I think it would be better if C-a/C-e respected the
>> value of `line-move-visual', too.  Then the default would be like
>> visual-line-mode without word-wrapping.
>
> It was discussed and the current behavior seemed to be the consensus
> choice.
>
> I agree that it can be confusing, but I think it's much more dangerous
> to change the default behavior of C-a/C-e, because people depend a lot
> more on their precise behavior (whereas C-n/C-p are more often used in
> conjunction with visual feedback).

I mostly agree, but then it is all the more important that the fringe
indicators are used to show that lines are word wrapped (i.e. continued).
Otherwise, there is no visible clue to what a given line-oriented command
will actually do.

IMO, it would make sense to have a new pair of fringe bitmaps
for word wrapped lines that are a bit less in your face than the
normal continued/continuation bitmaps.

These bitmaps would be used on lines which are word wrapped, in
contrast to lines which are really continued (typically because there
is no suitable space character in the wrap margin, so a word has to be
cut in two).

I previously proposed a new fringe bitmap (showing ...) for continued
lines, but it may be even more appropritate for word wrap.

I know it is feature freeze, but I feel this aspect of word wrap
has not been fully addressed so far.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Visual line movement inconsistency

[Miles Bader]

storm@cua.dk (Kim F. Storm) writes:
>> I agree that it can be confusing, but I think it's much more dangerous
>> to change the default behavior of C-a/C-e, because people depend a lot
>> more on their precise behavior (whereas C-n/C-p are more often used in
>> conjunction with visual feedback).
>
> I mostly agree, but then it is all the more important that the fringe
> indicators are used to show that lines are word wrapped (i.e. continued).

They do (using the normal "wrap" indicators)...

Of course if you have `visual-line-mode' turned on as well, then the
wrap indicators are suppressed -- but then C-a/C-e also operate on
screen lines rather than logical lines.

So far it all seems pretty reasonable to me.

-Miles

-- 
Future, n. That period of time in which our affairs prosper, our friends
are true and our happiness is assured.

Re: Visual line movement inconsistency

[Kim F. Storm]

Miles Bader <miles@gnu.org> writes:

> So far it all seems pretty reasonable to me.

IMO, there should be at least an option to show "word wrap" indicators
in the fringes.  You may disagree...

In any case, if you create a very long word which spans more than one line in
word wrap mode, the "wrap" indicates are not shown to indicate that the
line does indeed continue.  That's a bug that I reported some time ago.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Visual line movement inconsistency

[Miles Bader]

storm@cua.dk (Kim F. Storm) writes:
>> So far it all seems pretty reasonable to me.
>
> IMO, there should be at least an option to show "word wrap" indicators
> in the fringes.  You may disagree...
>
> In any case, if you create a very long word which spans more than one line in
> word wrap mode, the "wrap" indicates are not shown to indicate that the
> line does indeed continue.  That's a bug that I reported some time ago.

I think it might be useful to have distinct indicators for the two types
of wrapping, yes.  If there was such a feature, visual-line-mode (please
distinguish this from "word wrap mode", as they're not the same thing)
could use it to show indicators for non-word wrapping while suppressing
those for normal word-wrapping.  That would probably make most users
happy.

However that's mainly useful for the "very long word" wrapping case you
mention, and that's a pretty rare occurance, so it doesn't seem like a
particularly critical thing.  If someone decides to put in the time to
implement it, great; otherwise, whatever.

-Miles

-- 
Quotation, n. The act of repeating erroneously the words of another. The words
erroneously repeated.

Re: Visual line movement inconsistency

[Kim F. Storm]

Miles Bader <miles@gnu.org> writes:

> However that's mainly useful for the "very long word" wrapping case you
> mention, and that's a pretty rare occurance, so it doesn't seem like a
> particularly critical thing.  If someone decides to put in the time to
> implement it, great; otherwise, whatever.

I haven't had time to check how the latest word wrap works, but if
there is a wrap-margin-min which defines the minimum column where word
wrapping is allowed, long words which start before that margin would
be continued rather than wrapped - and in that case the fringe
indicators would also make sense.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Visual line movement inconsistency

[Chong Yidong]

storm@cua.dk (Kim F. Storm) writes:

> I haven't had time to check how the latest word wrap works, but if
> there is a wrap-margin-min which defines the minimum column where word
> wrapping is allowed, long words which start before that margin would
> be continued rather than wrapped - and in that case the fringe
> indicators would also make sense.

There's currently no wrap-margin variable; we just use the right window
edge.