From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Hl-line and visual-line Date: Fri, 21 May 2010 09:36:19 +0300 Message-ID: <83y6fdpxr0.fsf@gnu.org> References: <45790724-63FC-4B80-A70D-8CD49A92FEE3@gmail.com> <8339xmqob9.fsf@gnu.org> <94F28B33-A04E-4511-B93D-E5471EE4D0DE@gmail.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1274423856 27934 80.91.229.12 (21 May 2010 06:37:36 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 21 May 2010 06:37:36 +0000 (UTC) Cc: emacs-devel@gnu.org To: David Reitter Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri May 21 08:37:24 2010 connect(): No such file or directory Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OFLrE-0008Ug-Vc for ged-emacs-devel@m.gmane.org; Fri, 21 May 2010 08:37:21 +0200 Original-Received: from localhost ([127.0.0.1]:44863 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OFLrE-0003Pe-CW for ged-emacs-devel@m.gmane.org; Fri, 21 May 2010 02:37:20 -0400 Original-Received: from [140.186.70.92] (port=32995 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OFLr4-0003My-8p for emacs-devel@gnu.org; Fri, 21 May 2010 02:37:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OFLr2-0007mo-FD for emacs-devel@gnu.org; Fri, 21 May 2010 02:37:10 -0400 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:57679) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OFLr2-0007mZ-8J for emacs-devel@gnu.org; Fri, 21 May 2010 02:37:08 -0400 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0L2R00F00BI61900@a-mtaout21.012.net.il> for emacs-devel@gnu.org; Fri, 21 May 2010 09:36:14 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([77.127.33.125]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0L2R00CL2BOBVQ70@a-mtaout21.012.net.il>; Fri, 21 May 2010 09:36:12 +0300 (IDT) In-reply-to: <94F28B33-A04E-4511-B93D-E5471EE4D0DE@gmail.com> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:124979 Archived-At: > From: David Reitter > 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.