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 06:22:56 +0400 Message-ID: <87sjql5uv3.fsf@gmail.com> References: <87ei28f4re.fsf@gmail.com> <8362njqtv8.fsf@gnu.org> <83y60eoz6w.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1309832607 15491 80.91.229.12 (5 Jul 2011 02:23:27 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 5 Jul 2011 02:23:27 +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 04:23:22 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 1QdvIG-0007Kp-Kk for ged-emacs-devel@m.gmane.org; Tue, 05 Jul 2011 04:23:20 +0200 Original-Received: from localhost ([::1]:56919 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QdvIF-00048d-Dx for ged-emacs-devel@m.gmane.org; Mon, 04 Jul 2011 22:23:19 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:56233) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QdvI2-00048W-9G for emacs-devel@gnu.org; Mon, 04 Jul 2011 22:23:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QdvI1-0006xs-BB for emacs-devel@gnu.org; Mon, 04 Jul 2011 22:23:06 -0400 Original-Received: from mail-bw0-f41.google.com ([209.85.214.41]:41583) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QdvHz-0006xO-PM; Mon, 04 Jul 2011 22:23:03 -0400 Original-Received: by bwd14 with SMTP id 14so5693851bwd.0 for ; Mon, 04 Jul 2011 19:23:02 -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=iw3IN3Fp9SvMmqm4TGCVblPVr4py/d/9sgONqyKQ38c=; b=Ua0pYX2I14NoBFVRnE+V3KcGq8vmtckVY87Qd4GXovX7F1KDIUamaJJOH4ip44iswV C+iHfVI0foBgznP8rMuRylv6GVzWMy4jZKOUxyMfDipILEW07fm0e+nYEdPkO3vmw+X7 /fmz+T/7bFyCiSm0ecDJvJzsYN+CovNvTJNhg= Original-Received: by 10.204.134.207 with SMTP id k15mr6373502bkt.135.1309832582745; Mon, 04 Jul 2011 19:23:02 -0700 (PDT) Original-Received: from localhost ([91.144.186.21]) by mx.google.com with ESMTPS id g13sm6074729bkd.22.2011.07.04.19.23.00 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 04 Jul 2011 19:23:01 -0700 (PDT) In-Reply-To: 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:141562 Archived-At: 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. 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