unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: David Reitter <david.reitter@gmail.com>
Cc: emacs-devel@gnu.org
Subject: Re: Hl-line and visual-line
Date: Fri, 21 May 2010 09:36:19 +0300	[thread overview]
Message-ID: <83y6fdpxr0.fsf@gnu.org> (raw)
In-Reply-To: <94F28B33-A04E-4511-B93D-E5471EE4D0DE@gmail.com>

> From: David Reitter <david.reitter@gmail.com>
> Date: Thu, 20 May 2010 22:35:44 -0400
> Cc: emacs-devel@gnu.org
> 
> > 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.



      parent reply	other threads:[~2010-05-21  6:36 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-20 20:30 Hl-line and visual-line David Reitter
2010-05-20 21:02 ` Eli Zaretskii
2010-05-21  2:35   ` David Reitter
2010-05-21  6:34     ` Tassilo Horn
2010-05-21  8:17       ` Eli Zaretskii
2010-05-21 10:16         ` Tassilo Horn
2010-05-21 14:22         ` David Reitter
2010-05-21 14:57           ` Eli Zaretskii
2010-05-23 17:26           ` Eli Zaretskii
2010-05-23 19:13             ` David Reitter
2010-05-23 20:33               ` Eli Zaretskii
2010-05-23 23:04                 ` David Reitter
2010-05-24 18:16                   ` Eli Zaretskii
2010-05-24 18:46                     ` Stefan Monnier
2010-05-24 19:06                       ` Lennart Borgman
2010-05-24 22:24                         ` Eli Zaretskii
2010-05-24 22:37                           ` Lennart Borgman
2010-05-24 22:47                             ` David Reitter
2010-05-24 23:03                               ` Lennart Borgman
2010-05-21 16:54         ` Lennart Borgman
2010-05-21 17:39           ` Eli Zaretskii
2010-05-21 20:24           ` Stefan Monnier
2010-05-21 22:31             ` Lennart Borgman
2010-05-22  0:18               ` Stefan Monnier
2010-05-22  2:35                 ` Lennart Borgman
2010-05-22 13:10                   ` Lennart Borgman
2010-05-22 17:04                   ` Lennart Borgman
2010-05-21  6:36     ` Eli Zaretskii [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83y6fdpxr0.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=david.reitter@gmail.com \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).