From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: moving point and invisible text Date: Wed, 08 Feb 2006 10:23:44 +0100 Message-ID: <43E9B8A0.1000109@gmx.at> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1139390676 28093 80.91.229.2 (8 Feb 2006 09:24:36 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 8 Feb 2006 09:24:36 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 08 10:24:30 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1F6lYi-00078u-8Z for ged-emacs-devel@m.gmane.org; Wed, 08 Feb 2006 10:24:21 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1F6lYh-0003ot-2R for ged-emacs-devel@m.gmane.org; Wed, 08 Feb 2006 04:24:19 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1F6lXz-0003mX-Ky for emacs-devel@gnu.org; Wed, 08 Feb 2006 04:23:35 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1F6lXv-0003jX-EL for emacs-devel@gnu.org; Wed, 08 Feb 2006 04:23:33 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1F6lXv-0003jM-05 for emacs-devel@gnu.org; Wed, 08 Feb 2006 04:23:31 -0500 Original-Received: from [213.165.64.21] (helo=mail.gmx.net) by monty-python.gnu.org with smtp (Exim 4.52) id 1F6lbC-000891-D2 for emacs-devel@gnu.org; Wed, 08 Feb 2006 04:26:54 -0500 Original-Received: (qmail invoked by alias); 08 Feb 2006 09:23:29 -0000 Original-Received: from N875P025.adsl.highway.telekom.at (EHLO [62.47.53.89]) [62.47.53.89] by mail.gmx.net (mp017) with SMTP; 08 Feb 2006 10:23:29 +0100 X-Authenticated: #14592706 User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: de-DE, de, en-us, en Original-To: emacs-devel X-Y-GMX-Trusted: 0 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:50202 Archived-At: The Elisp manual describes the behavior of commands moving point with respect to invisible text as follows: "However, if a command ends with point inside or immediately after invisible text, the main editing loop moves point further forward or further backward (in the same direction that the command already moved it) until that condition is no longer true. ... If the command moved point forward into an invisible range, Emacs moves point forward past the first visible character that follows the invisible text." This description seems archaic. With Emacs -q evaluate (with-current-buffer (get-buffer-create "*test*") (insert "foo\n") (let ((at (point))) (insert "bar\nbar\nbar\n") (overlay-put (make-overlay at (point-max)) 'invisible t)) (insert "baz\n")) move point to position 18 in *test* (between the "b" and "a" of "baz") and do C-b. On my system this moves point to position 17 which is the position immediately after the invisible text, thus contradicting the first sentence of the description. According to that sentence point should move to position 5 here. Now move point to position 4 (the end of the first line) and do C-2 C-f. Another time point moves to position 17. According to the manual point should move to position 18 here. I'm glad it doesn't. Finally, move point to position 4 and execute C-f. Once more point moves to position 17. This behavior is not mentioned in the manual. Moreover, the manual fails to say what happens when the invisible text resides at the end of a buffer. Also, I was not able to detect a consistent behavior with different values of `line-move-ignore-invisible' and with respect to whether an invisibility overlay or an invisibility text-property was used. Would it be difficult to implement this as: "However, if a command moved point backward into or to the end of invisible text, Emacs moves point backward to the beginning of that text. If a command moved point forward into or to the beginning of invisible text, Emacs moves point forward to the end of that text." Otherwise I'd change the text to something like: "However, if a command ends with point inside invisible text, the main editing loop moves point to some position before or after the invisible text."