From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Kurochkin Newsgroups: gmane.emacs.devel Subject: Re: `vertical-motion', `goto-line' set point to invisible text Date: Tue, 05 Jul 2011 07:52:09 +0400 Message-ID: <87pqlp5qqe.fsf@gmail.com> References: <87ei28f4re.fsf@gmail.com> <8362njqtv8.fsf@gnu.org> <83y60eoz6w.fsf@gnu.org> <87sjql5uv3.fsf@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1309837997 8884 80.91.229.12 (5 Jul 2011 03:53:17 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 5 Jul 2011 03:53:17 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jul 05 05:53:13 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QdwhE-00049D-ID for ged-emacs-devel@m.gmane.org; Tue, 05 Jul 2011 05:53:12 +0200 Original-Received: from localhost ([::1]:56198 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QdwhD-0004BA-LM for ged-emacs-devel@m.gmane.org; Mon, 04 Jul 2011 23:53:11 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:51667) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QdwgQ-00044Q-Ug for emacs-devel@gnu.org; Mon, 04 Jul 2011 23:52:24 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QdwgP-0002t4-Gc for emacs-devel@gnu.org; Mon, 04 Jul 2011 23:52:22 -0400 Original-Received: from mail-bw0-f41.google.com ([209.85.214.41]:63694) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QdwgM-0002ss-Pg; Mon, 04 Jul 2011 23:52:19 -0400 Original-Received: by bwd14 with SMTP id 14so5729617bwd.0 for ; Mon, 04 Jul 2011 20:52:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:in-reply-to:references:user-agent:date :message-id:mime-version:content-type; bh=MwXzai3WxuhBrdBaNOYIGONhSD9+k4e5TJKsGXQ/sNY=; b=No8qqZNxZqCvY33f8BkGQ6Ezff+MUebVH4Nkdz8Id7L35gb73kW57zIwUy0lajiotP uNQMFlf1vDrs5u/BNeJbqurIcNXzk4Wf73oL72/igazua6DN314hQ9A9iy4olqaqcwql FXF/UviVQyp+KA51ZCm7SzrN03+clFX0CTpvg= Original-Received: by 10.204.103.2 with SMTP id i2mr6214165bko.7.1309837936850; Mon, 04 Jul 2011 20:52:16 -0700 (PDT) Original-Received: from localhost ([91.144.186.21]) by mx.google.com with ESMTPS id e6sm6132551bka.11.2011.07.04.20.52.14 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 04 Jul 2011 20:52:15 -0700 (PDT) In-Reply-To: <87sjql5uv3.fsf@gmail.com> User-Agent: Notmuch/0.5-321-g41686e2 (http://notmuchmail.org) Emacs/23.3.1 (x86_64-pc-linux-gnu) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.214.41 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:141568 Archived-At: On Tue, 05 Jul 2011 06:22:56 +0400, Dmitry Kurochkin wrote: > On Mon, 04 Jul 2011 14:10:11 -0400, Stefan Monnier wrote: > > >> >> AFAIK none of those positions are *inside* invisible text > > >> > Try "M-x describe-text-properties RET", and you will see this isn't > > >> > true. > > >> AFAIK, describe-text-properties describes the properties of the char > > >> *after* point, so if you're at the beginning of invisible text (yet not > > >> inside it), describe-text-properties will show the `invisible' property. > > > > > So how many character positions are invisible after this: > > > (insert "line1\nline2\nline3\n") > > > (goto-line 2) > > > (put-text-property (line-beginning-position) > > > (line-beginning-position 2) > > > 'invisible 'invis1) > > > ? > > > > Without running the code, I'd say 6 ("line2\n"). Why? > > > > > Also, since we show cursor on the character after point, > > > > By default, yes. > > > > > which is invisible, what exactly do we mean to achieve in this case by > > > adjust_point_for_property? > > > > The intention is just to avoid having point in the middle of invisible > > text and have things like C-f and C-b appear to do nothing (because > > they only move within some invisible text chunk). > > Also it's so that inserting text will usually result in this text being > > visible (and hopefully inserted right where the cursor was displayed). > > > > None of those properties are guaranteed by adjust_point_for_property, > > sadly, but it's the motivation behind it. > > > > > Finally, what do you think of this: > > > > > (progn (switch-to-buffer "test") > > > (insert "aline1\nbline2\ncline3\n") > > > (goto-line 2) > > > (put-text-property (line-beginning-position) > > > (line-beginning-position 2) > > > 'invisible 'invis1) > > > (add-to-invisibility-spec 'invis1) > > > (goto-char (point-max))) > > > > > Eval this in *scratch*, then type "C-p C-x =". You will see that > > > Emacs reports that point is position 8 and the character at point is > > > `b', whereas what is shown (correctly) under the cursor is `c' whose > > > buffer position is 15. Do you think this is correct behavior? > > > > In this area, I don't think there's a clear cut definition of what is > > correct and what is not. Depending on what is being done some behavior > > is preferable, and in other cases another behavior is preferable. > > If point is anywhere between "bline2\n" the display will be identical, > > so the fact that the cursor is drawn over the "c" that follows it does > > not necessarily imply that point should be "at the end of "bline2\n", > > since the cursor is also drawn right after the "aline1\n" and by that > > logic point should be at the beginning of "bline2\n". > > > > What tilts the decision one way rather than the other here is the > > stickiness: for all positions other than right before "bline2\n", > > self-insert-command at point will result in an invisible char being > > inserted, which is very rarely the intention of the user. Of course, in > > a read-only buffer this consideration may not matter, but note that this > > stickiness issue also happens to be a way by which Elisp packages can > > control in which part of the invisible text point will end up. > > > > That makes sense. Thank you. > > Perhaps in case of notmuch the best way is to hide the preceding newline > character instead of the trailing one. This way there will always be a > visible newline between different messages and cursor-moving functions > (e.g. `vertical-motion') should not move beyond it. > While trying this, I found another issue with how emacs adjusts the point when it is idle. We have 3 lines and the second one is hidden. But now we hide the newline on line1 instead of line2: (progn (switch-to-buffer "test") (insert "aline1\nbline2\ncline3\n") (put-text-property 7 14 'invisible t) (goto-char (point-min))) Now if you run M-: (progn (end-of-visual-line) (point)), it moves to point 14, which is end of line 2 as expected. But then emacs adjusts the point and moves it to beginning of line3, C-x = says point is 15. Also, global-hl-line-mode does not work correctly for line1. Just go to the start of buffer and move forward to see some weird behavior. Regards, Dmitry > Still looking for an answer to the following question earlier in this > thread: > > I am looking for a function that does something like what you described > below. I.e. moves point to the next suitable character in the given > direction. At the moment I do it with smth like: > > ;; if point is invisible, skip forward to visible text > (while (invisible-p p) > (setq p (next-single-char-property-change p 'invisible))) > > Regards, > Dmitry > > > > > Stefan