From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Stefan Monnier" Newsgroups: gmane.emacs.devel Subject: NEWS and invisible text Date: Fri, 11 Apr 2003 15:09:41 -0400 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200304111909.h3BJ9fOv010480@rum.cs.yale.edu> References: <200304111308.h3BD8oW03188@eel.dms.auburn.edu> <844r55f7yr.fsf@lucy.is.informatik.uni-duisburg.de> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1050088400 31115 80.91.224.249 (11 Apr 2003 19:13:20 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 11 Apr 2003 19:13:20 +0000 (UTC) Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Fri Apr 11 21:13:17 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 1943xL-000848-00 for ; Fri, 11 Apr 2003 21:12:59 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 19442v-0007qB-00 for ; Fri, 11 Apr 2003 21:18:45 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 1943wg-0000z6-04 for emacs-devel@quimby.gnus.org; Fri, 11 Apr 2003 15:12:18 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 1943wK-0000jV-00 for emacs-devel@gnu.org; Fri, 11 Apr 2003 15:11:56 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 1943w1-00006x-00 for emacs-devel@gnu.org; Fri, 11 Apr 2003 15:11:38 -0400 Original-Received: from rum.cs.yale.edu ([128.36.229.169]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 1943uA-00078w-00 for emacs-devel@gnu.org; Fri, 11 Apr 2003 15:09:42 -0400 Original-Received: from rum.cs.yale.edu (localhost [127.0.0.1]) by rum.cs.yale.edu (8.12.8/8.12.8) with ESMTP id h3BJ9fx6010482 for ; Fri, 11 Apr 2003 15:09:41 -0400 Original-Received: (from monnier@localhost) by rum.cs.yale.edu (8.12.8/8.12.8/Submit) id h3BJ9fOv010480; Fri, 11 Apr 2003 15:09:41 -0400 X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 Original-To: emacs-devel@gnu.org 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:13164 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:13164 The NEWS file says: ** Only one of the beginning or end of an invisible, intangible region is considered an acceptable value for point; which one is determined by examining how the invisible/intangible properties are inherited when new text is inserted adjacent to them. If text inserted at the beginning would inherit the invisible/intangible properties, then that position is considered unacceptable, and point is forced to the position following the invisible/intangible text. If text inserted at the end would inherit the properties, then the opposite happens. Thus, point can only go to one end of an invisible, intangible region, but not the other one. This prevents C-f and C-b from appearing to stand still on the screen. I'm not sure what it refers to, and I think it should make it more clear in which way it's different from the previous behavior. Also I'd like to add the following (although better working would be appreciated), which is about a different feature (AFAIK). Any idea how to make the two more understandable, especially w.r.t each other ? ** The code that forced point to move out of images and composition has been generalized to apply to overlays as well and to invisible text. This makes it generally unnecessary to mark invisible text as intangible, which is particularly good due to the fact that the intangible property can often have unexpected side-effects because the property applies to everything (including `goto-char', ...) whereas this new code is only run after post-command-hook and thus does not care about intermediate states. -- Stefan