From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Lennart Borgman Newsgroups: gmane.emacs.devel Subject: Re: Hl-line and visual-line Date: Tue, 25 May 2010 01:03:34 +0200 Message-ID: References: <45790724-63FC-4B80-A70D-8CD49A92FEE3@gmail.com> <47101594-5A7C-4FF1-8C58-C77AF33F35F2@gmai0l.com> <83ljbanytd.fsf@gnu.org> <4D3EC595-2FF1-42BC-8DB3-26F3A91501D4@gmail.com> <83fx1hnp1u.fsf@gnu.org> <83aarpndk9.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1274742253 31688 80.91.229.12 (24 May 2010 23:04:13 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 24 May 2010 23:04:13 +0000 (UTC) Cc: Eli Zaretskii , monnier@iro.umontreal.ca, emacs-devel@gnu.org To: David Reitter Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue May 25 01:04:11 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 1OGggs-0006BM-Ol for ged-emacs-devel@m.gmane.org; Tue, 25 May 2010 01:04:11 +0200 Original-Received: from localhost ([127.0.0.1]:35089 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OGggs-0007It-5z for ged-emacs-devel@m.gmane.org; Mon, 24 May 2010 19:04:10 -0400 Original-Received: from [140.186.70.92] (port=39504 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OGggi-0007In-4P for emacs-devel@gnu.org; Mon, 24 May 2010 19:04:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OGggd-0004Vo-5F for emacs-devel@gnu.org; Mon, 24 May 2010 19:03:59 -0400 Original-Received: from mail-gw0-f41.google.com ([74.125.83.41]:41225) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OGggd-0004Vi-0x; Mon, 24 May 2010 19:03:55 -0400 Original-Received: by gwb19 with SMTP id 19so1041714gwb.0 for ; Mon, 24 May 2010 16:03:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=r7/rkofALW9Tt9uSnISKpc6s2i0NZX5ECqmnpgCPlt8=; b=jAAgwrlXIK46tTFJaoNQOsr2YAy0vu+IZZhTJToWCXBZk2tBZnwL3xYbPsfSHhx5g3 9Ojy0lfkpOgUo+0p/hv9aekChf4k9Se+EIzCawWtxG4gxlIjjlUPoMIpQz5wS0YsI+ZW 3oDoxX/TmTWgLw9K8reV4Z8sLNlgNoDKqO2gk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=eWd2eGhqpMpfyUSin39uX7htoIuivkHoZupvHCpr+vI8A3haDx3IMSypbZZEU/XODB VO7Cx3v2KPtBSFjtiuOlFgKhmSD5Q5KiBlEK5+THm3mLoPDGaEEMm7W9/NxRvV7aoTiP n8Sq/9jasIsM8qTK56KYWOLRm/X/kivXuxBuY= Original-Received: by 10.101.10.7 with SMTP id n7mr6830422ani.94.1274742234239; Mon, 24 May 2010 16:03:54 -0700 (PDT) Original-Received: by 10.100.177.20 with HTTP; Mon, 24 May 2010 16:03:34 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) 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:125218 Archived-At: On Tue, May 25, 2010 at 12:47 AM, David Reitter w= rote: > On May 24, 2010, at 6:37 PM, Lennart Borgman wrote: >>> >>> is your definition of `bovl' and `eovl'. >> >> I mean the same difference as between beginning-of-line and >> line-beginning-position (point-at-bol). (I prefer the shorter versions >> here. They are easier to read and easy to understand.) >> >> The first one moves point, but the second does not. > > (save-excursion > =C2=A0 =C2=A0 =C2=A0 =C2=A0(beginning-of-visual-line) > =C2=A0 =C2=A0 =C2=A0 =C2=A0(point)) > > The presence of such functions may reinforce the impression that they cou= ld be used as "beg" and "end" parameters to any other function that will pr= ocess the text between "beg" and "end", in order to make it operate on the = visual line. > > This works for L2R or even R2L text, but as this thread has made clear, n= ot in the bidirectional case. > > So one would want a warning in their DOC strings, if those functions are = needed. Good point of course. Maybe instead functions like min-point-visual-line etc would better? Hm, that would be problematic too because the direction of text might change from min to max on the line. I think I am beginning to understand what the details here have been about. I think then it might be a bad idea to have those functions I suggest, yes. A comment about that the text shown between beginning-of-visual-line and end-... is not necessarily the text between those points when bidirectional text is in the buffer would be good. I did not realize that "bidi" meant bidirectional (i.e. text in both directions) simultaneously before. I can realize Eli had some trouble with this and the display engine. Great work.