Re: Hl-line and visual-line

[Eli Zaretskii]

> From: David Reitter <address@hidden>
> Date: Thu, 20 May 2010 22:35:44 -0400
> Cc: address@hidden
> 
> > I just yesterday fixed a similar problem in move-end-of-line (see
> > revno 100369).  You need to proactively get to the line's first
> > character, with either skip-chars-backward or (per Stefan's
> > suggestion) `(forward-line 0)'.
> 
> These two seem applicable to buffer lines; I'm not sure how I would do it 
> with word-wrap without `vertical-motion'.

You can't, at least not in general; see below.  But at the very least,
this change shouldn't break highlighting buffer lines, which currently
works well with bidirectional text.

> Should I just use `beginning-of-visual-line' and `end-of-visual-line'?

You could, if we decide that these two should have the semantics of
moving to the first/last character in the logical order.  If we do
decide this, I could try fixing these to DTRT, because currently they
work well only for physical (buffer) lines, not in Visual Line mode
and not in continued lines.

This calls for a more general discussion about the meaning of columns
and related primitives, which I have been postponing for too long.  I
will start a separate thread on that soon.

But the graver problem is that, with bidirectional text, you in
general need more than a single overlay to cover a single visual line.
An example will explain why.  Imagine a buffer whose text is

  abcdefg ABCDEFG XYZ xyz

where upper-case letters represent right-to-left text.  This text will
be reordered for display to produce the following visual line:

  abcdefg ZYX GFEDCBA xyz

In a narrow enough window and under Visual Line mode, it will be
displayed as

  abcdefg ZYX
  GFEDCBA xyz

Since overlays and text properties cover characters in their buffer
order (and that really cannot be changed without terrible user-level
misfeatures), I hope it is clear now that to highlight the second
visual line, you need 2 overlays, covering the characters as shown by
underlining below:

  abcdefg ABCDEFG XYZ xyz
          -------     ---

> On another note, I first thought of just implementing hl-line in the 
> redisplay code, or perhaps as an option to the cursor display.  When the 
> cursor is drawn, we just highlight the line.  No moving around overlays in 
> Lisp...

I think moving features from Lisp to C is currently being frowned
upon.  And in any case, doing this is not as simple as it sounds,
because highlighting must be noted and acted upon when the characters
are examined for their display in each line, which is well before the
cursor is placed.  That's because faces and overlays can in principle
change character dimensions and affect the display in the more global
sense.  So the display engine examines overlays and text properties
when it lays out the characters, and only after a line is laid out, it
considers whether the cursor should be placed on the line, and where.