From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Luc Teirlinck Newsgroups: gmane.emacs.devel Subject: Re: invisible text and point Date: Mon, 26 May 2003 13:13:23 -0500 (CDT) Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200305261813.h4QIDN815240@eel.dms.auburn.edu> References: <200305260437.h4Q4bbh14766@eel.dms.auburn.edu> <200305261721.h4QHLigb001231@rum.cs.yale.edu> NNTP-Posting-Host: main.gmane.org X-Trace: main.gmane.org 1053972906 23027 80.91.224.249 (26 May 2003 18:15:06 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 26 May 2003 18:15:06 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Mon May 26 20:15:05 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19KMUz-0005zG-00 for ; Mon, 26 May 2003 20:15:05 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 19KMiI-0006Qh-00 for ; Mon, 26 May 2003 20:28:51 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.20) id 19KMV8-0002qZ-Js for emacs-devel@quimby.gnus.org; Mon, 26 May 2003 14:15:14 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19KMUg-0002ZJ-CC for emacs-devel@gnu.org; Mon, 26 May 2003 14:14:46 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19KMTq-0001PD-6v for emacs-devel@gnu.org; Mon, 26 May 2003 14:13:54 -0400 Original-Received: from manatee.dms.auburn.edu ([131.204.53.104]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19KMTI-0001EN-ON for emacs-devel@gnu.org; Mon, 26 May 2003 14:13:20 -0400 Original-Received: from eel.dms.auburn.edu (eel.dms.auburn.edu [131.204.53.108]) h4QIDJoc021888; Mon, 26 May 2003 13:13:19 -0500 (CDT) Original-Received: (from teirllm@localhost) by eel.dms.auburn.edu (8.11.6+Sun/8.11.6) id h4QIDN815240; Mon, 26 May 2003 13:13:23 -0500 (CDT) X-Authentication-Warning: eel.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: monnier+gnu/emacs@rum.cs.yale.edu In-reply-to: <200305261721.h4QHLigb001231@rum.cs.yale.edu> (monnier+gnu/emacs@rum.cs.yale.edu) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Emacs development discussions. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:14292 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:14292 I posted a follow-up to my original message from yesterday evening this morning. I no longer propose "reverting" to the emacs-21.3 behavior (actually, I only did this because I misinterpreted it yesterday, as I noticed this morning), but "mimicking it better", by making sure that (point) returns the position of a visible character. Since my conjecture that the infinite loops were also related to the problem was apparently a premature conclusion based on the fact that the bugs did not occur in 21.3 and happened at similar places as the other bug, we are left with the m and RETURN bugs in info. Just fixing those individual bugs would not really seem to really address the problem, which is more general. Namely a huge fraction of Emacs commands act based on the return value of (point). Since point is not where the user believes it is, this is bound to confuse the user. I do not know whether it would be feasible to make all interactive commands act based on the "user-visible" displayed position of point instead. That would really eliminate the need for any change. Stefan Monnier wrote: Point is not put inside the invisible text. It's put at one of the two ends. In this case it happens to be "just before" rather than "just after" because the stickiness is the default one so that inserting a char at the end would lead to a hidden char whereas inserting a char at the beginning would lead to a visible char: the choice is to prefer putting point at a position such that inserted text is visible. I believe that the `intangible' change mentioned underneath in the NEWS file did the same for intangible&invisible text. Yes, but semantics aside, if (point) returns the position of an invisible character, we have the kind of problems of which the m and RETURN behaviors in info are symptomatic. Or rather make it "front-sticky" rather than "rear-sticky", such that when the user sees point in front of letter "a", `char-after' will indeed show letter ?a. Right now, it's the opposite: if point is right after letter "a" `char-before' will indeed return ?a. That would work for those buffers. I would guess that there probably are good reasons to keep invisible rear-sticky in general. In that case, we would be left with the problem of making sure that the user would understand in which buffers invisibility is front-sticky and in which it is rear-sticky. Sincerely, Luc.