From: Luc Teirlinck <teirllm@dms.auburn.edu>
Cc: emacs-devel@gnu.org
Subject: Re: invisible text and point
Date: Mon, 26 May 2003 08:07:13 -0500 (CDT) [thread overview]
Message-ID: <200305261307.h4QD7Dk15098@eel.dms.auburn.edu> (raw)
In-Reply-To: <200305260516.h4Q5GpU14793@eel.dms.auburn.edu> (message from Luc Teirlinck on Mon, 26 May 2003 00:16:51 -0500 (CDT))
In this thread I failed to remember what the exact pre-change
behavior was. Here is the change mentioned in the NEWS:
** At the end of a command, point moves out from within invisible
text, in the same way it moves out from within text covered by an
image or composition property.
This makes it generally unnecessary to mark invisible text as
intangible.
This is particularly good because the intangible property often has
unexpected side-effects since 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.
Thus the change was not motivated by problems with stickiness, as I
originally thought. I confused with the next NEWS entry, which I
remembered from something else. I do not copy it entirely, since it
is long:
** 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. (The
`front-sticky' and `rear-sticky' properties control this.)
So there are three solutions:
Really revert to the emacs-21.3 behavior and use intangible properties
in these situations again, leave things as they are now and deal with
the bugs, or (what I really was suggesting yesterday, when I
misinterpreted the actual emacs-21.3 behavior) make the code that runs
after post-command-hook really mimic the old behavior by never placing
point inside an invisible region. (And thus not confusing commands
like m and RETURN in info, C-h f, C-h v, M-x man and countless others
that act upon, or choose a default based on, the position of point.)
At first view, I might prefer the latter solution.
Sincerely,
Luc.
next prev parent reply other threads:[~2003-05-26 13:07 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-26 4:37 invisible text and point Luc Teirlinck
2003-05-26 4:53 ` Luc Teirlinck
2003-05-26 5:03 ` Luc Teirlinck
2003-05-26 5:16 ` Luc Teirlinck
2003-05-26 13:07 ` Luc Teirlinck [this message]
2003-05-26 14:51 ` Stefan Monnier
[not found] ` <200305261721.h4QHLigb001231@rum.cs.yale.edu>
2003-05-26 18:13 ` Luc Teirlinck
2003-05-26 18:26 ` Stefan Monnier
2003-05-27 2:13 ` Luc Teirlinck
2003-05-27 3:07 ` Luc Teirlinck
2003-05-27 7:26 ` David Kastrup
2003-05-27 22:41 ` Richard Stallman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200305261307.h4QD7Dk15098@eel.dms.auburn.edu \
--to=teirllm@dms.auburn.edu \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).