* bug#10072: 23.3; invisible text
@ 2011-11-18 19:14 Andrew Kurn
2011-11-20 4:57 ` Stefan Monnier
0 siblings, 1 reply; 9+ messages in thread
From: Andrew Kurn @ 2011-11-18 19:14 UTC (permalink / raw)
To: 10072
I'm seeing a collection of funny behavior around invisible text. Here are some examples.
emacs -Q -nw
(setq s "XXX,")
(put-text-property 0 3 'invisible t s)
(setq s (concat s s s))
(insert s)
If I move the cursor around, it will stop before an invisible X. This is
not the advertised behavior. (I discover its position by using Ctl-X =)
From sec. 38.6 of E-Lisp:
---
However, if a command ends with point inside or immediately before
invisible text, the main editing loop moves point further forward or
further backward (in the same direction that the command already moved
it) until that condition is no longer true. Thus, if the command moved
point back into an invisible range, Emacs moves point back to the
beginning of that range, and then back one more character. If the
command moved point forward into an invisible range, Emacs moves point
forward up to the first visible character that follows the invisible
text.
---
Also, this:
(let ()
(with-current-buffer (get-buffer-create "B")
(goto-char 1)
(insert s)
(goto-char 1)
(re-search-forward ",X")
)
)
will leave point at an invisible position, where it stays if
you pop up a window on B.
---
I have one more bug, which I'm having trouble reproducing, where an
/after-string/ of blanks attached to an overlay on invisible text displays fewer
than requested. If you know what this one is already you can save me
some trouble.
---
Best regards,
Andrew
In GNU Emacs 23.3.1 (powerpc-apple-darwin8.11.0, NS apple-appkit-824.48)
of 2011-11-14 on d142-058-206-239.surrey.sfu.ca
Windowing system distributor `Apple', version 10.3.824
configured using `configure '--with-ns''
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: nil
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: nil
value of $XMODIFIERS: nil
locale-coding-system: nil
default enable-multibyte-characters: t
Major mode: Fundamental
Minor modes in effect:
tooltip-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Recent input:
n g SPC r M-! t r o u b l e SPC r e p r o d u c i n
g , SPC w h e r e SPC a n SPC / a f t e r - s t r i
n g / RET o f SPC b l a n k s SPC d i s p l a y s SPC
f e w e r SPC t h a n SPC r e q u e s t e d . SPC SPC
I f SPC y o u SPC k n o w SPC w h a t SPC t h i s SPC
o n e SPC i s SPC a l r e a d y RET y o u SPC c a n
SPC s a v e SPC m e SPC s o m e SPC t r o u b l e .
ESC O D ESC O A ESC ] h L ESC ] h L ESC ] h L a t t
a c h e d SPC t o SPC i n v i s i b l e SPC t e x t
SPC ESC O A ESC O A ESC ] f E ESC x f i l l - r e g
TAB RET RET RET ESC O A ESC O A ESC O A ESC ] h L ESC
] h L ESC ] h L ESC ] h L a n SPC o v e r l a y s SPC
o n SPC ESC O D ESC O D ESC O D ESC O D M-! ESC O A
ESC O A ESC ] f E ESC x r e p o r t TAB RET
Recent messages:
Char: " (34, #o42, #x22) point=13 of 27056 (0%) column=7
Char: " (34, #o42, #x22) point=7 of 27056 (0%) column=6
Char: " (34, #o42, #x22) point=5 of 27056 (0%) column=4
Char: , (44, #o54, #x2c) point=6 of 27056 (0%) column=5
Char: " (34, #o42, #x22) point=7 of 27056 (0%) column=6 [2 times]
Auto-saving...done
(New file)
Mark set [6 times]
Auto-saving...done
Mark set [2 times]
Load-path shadows:
None found.
Features:
(shadow sort mail-extr message sendmail regexp-opt ecomplete rfc822 mml
mml-sec password-cache mm-decode mm-bodies mm-encode mailcap mail-parse
rfc2231 rfc2047 rfc2045 qp ietf-drums mailabbrev nnheader gnus-util
netrc time-date mm-util mail-prsvr gmm-utils wid-edit mailheader canlock
sha1 hex-util hashcash mail-utils emacsbug help-fns help-mode view
apropos info tooltip ediff-hook vc-hooks lisp-float-type mwheel ns-win
easymenu tool-bar dnd fontset image fringe lisp-mode register page
menu-bar rfn-eshadow timer select scroll-bar mldrag mouse jit-lock
font-lock syntax facemenu font-core frame cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew
greek romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev loaddefs button
minibuffer faces cus-face files text-properties overlay md5 base64
format env code-pages mule custom widget hashtable-print-readable
backquote make-network-process ns multi-tty emacs)
^ permalink raw reply [flat|nested] 9+ messages in thread* bug#10072: 23.3; invisible text
2011-11-18 19:14 bug#10072: 23.3; invisible text Andrew Kurn
@ 2011-11-20 4:57 ` Stefan Monnier
2011-11-20 10:24 ` Andrew Kurn
0 siblings, 1 reply; 9+ messages in thread
From: Stefan Monnier @ 2011-11-20 4:57 UTC (permalink / raw)
To: Andrew Kurn; +Cc: 10072
> I'm seeing a collection of funny behavior around invisible text.
> Here are some examples.
> emacs -Q -nw
> (setq s "XXX,")
> (put-text-property 0 3 'invisible t s)
> (setq s (concat s s s))
> (insert s)
> If I move the cursor around, it will stop before an invisible X.
I'm not sure what you mean by "stop".
> This is not the advertised behavior. (I discover its position by
> using Ctl-X =)
>> From sec. 38.6 of E-Lisp:
> ---
> However, if a command ends with point inside or immediately before
> invisible text, the main editing loop moves point further forward or
Oh, you mean that point stays "immediately before" the "X"?
You're right: the Elisp manual is wrong (because incomplete) here.
Does the patch below clears things up?
> Also, this:
> (let ()
> (with-current-buffer (get-buffer-create "B")
> (goto-char 1)
> (insert s)
> (goto-char 1)
> (re-search-forward ",X")
> )
> )
> will leave point at an invisible position, where it stays if
> you pop up a window on B.
The code that moves point out of invisible chunks of text does not
always work, indeed, because it is only applied to the current
buffer (or maybe the selected-window?) after a command.
> I have one more bug, which I'm having trouble reproducing, where an
> /after-string/ of blanks attached to an overlay on invisible text
> displays fewer than requested. If you know what this one is already
> you can save me some trouble.
That doesn't ring a bell, sorry.
Stefan
=== modified file 'doc/lispref/display.texi'
--- doc/lispref/display.texi 2011-11-20 02:29:42 +0000
+++ doc/lispref/display.texi 2011-11-20 04:45:57 +0000
@@ -870,15 +870,16 @@
non-@code{nil} (the default), but only because they are explicitly
programmed to do so.
- However, if a command ends with point inside or immediately before
-invisible text, the main editing loop moves point further forward or
-further backward (in the same direction that the command already moved
-it) until that condition is no longer true. Thus, if the command
-moved point back into an invisible range, Emacs moves point back to
-the beginning of that range, and then back one more character. If the
-command moved point forward into an invisible range, Emacs moves point
-forward up to the first visible character that follows the invisible
-text.
+ However, if a command ends with point inside invisible text, the main editing
+loop moves point further forward or further backward (in the same direction
+that the command already moved it) until that condition is no longer true.
+Thus, if the command moved point back into an invisible range, Emacs moves
+point back to the beginning of that range, and then back one more character.
+If the command moved point forward into an invisible range, Emacs moves point
+forward up to the first visible character that follows the invisible text.
+The positions immediately before and immediately after invisible text are
+considered inside the invisible text if a char inserted at that position would
+inherit the @code{invisible} property.
Incremental search can make invisible overlays visible temporarily
and/or permanently when a match includes invisible text. To enable
^ permalink raw reply [flat|nested] 9+ messages in thread* bug#10072: 23.3; invisible text
2011-11-20 4:57 ` Stefan Monnier
@ 2011-11-20 10:24 ` Andrew Kurn
2011-11-20 20:30 ` Stefan Monnier
0 siblings, 1 reply; 9+ messages in thread
From: Andrew Kurn @ 2011-11-20 10:24 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 10072
On Sat 19 Nov 2011 23:57 -0500, Stefan Monnier wrote:
>
> > I'm seeing a collection of funny behavior around invisible text.
> > Here are some examples.
>
> > emacs -Q -nw
> > (setq s "XXX,")
> > (put-text-property 0 3 'invisible t s)
> > (setq s (concat s s s))
> > (insert s)
>
> > If I move the cursor around, it will stop before an invisible X.
>
> I'm not sure what you mean by "stop".
>
> > This is not the advertised behavior. (I discover its position by
> > using Ctl-X =)
>
> >> From sec. 38.6 of E-Lisp:
> > ---
> > However, if a command ends with point inside or immediately before
> > invisible text, the main editing loop moves point further forward or
>
> Oh, you mean that point stays "immediately before" the "X"?
> You're right: the Elisp manual is wrong (because incomplete) here.
> Does the patch below clears things up?
>
Actually, no. The new text contradicts itself. The example
included contradicts the definition, which is hard to read
because the definition is interrupted by the example.
Let me propose this wording:
-----------
However, if a command ends with point inside invisible text, the main editing
loop moves point further forward or further backward (in the same direction
that the command already moved it) until that condition is no longer true.
The positions immediately before and immediately after invisible text are
considered inside the invisible text if a char inserted at that position would
inherit the @code{invisible} property.
Thus, if the command moved point back into an invisible range
(with the usual stickiness), Emacs moves
point back to the beginning of that range.
If the command moved point forward into an invisible range, Emacs moves point
forward to the first visible character that follows the invisible text
and then forward one more character.
---------
That is indeed the behavior I see.
As an opinion, I add that it would be more intuitive if it worked
differently -- the way described in the original example -- but
I can live with this once it is clearly explained. (The problem
is, of course, that ^X= should always name a visible character,
and the one that the cursor is over.)
[. . .]
>
> The code that moves point out of invisible chunks of text does not
> always work, indeed, because it is only applied to the current
> buffer (or maybe the selected-window?) after a command.
>
>
Yes, I see. This might need clarification in the text also.
>
> === modified file 'doc/lispref/display.texi'
> --- doc/lispref/display.texi 2011-11-20 02:29:42 +0000
> +++ doc/lispref/display.texi 2011-11-20 04:45:57 +0000
> @@ -870,15 +870,16 @@
[. . .]
So, now one must choose: the intuitive behavior or the "sticky"
kind. Please let me know your thoughts on this.
Andrew
^ permalink raw reply [flat|nested] 9+ messages in thread* bug#10072: 23.3; invisible text
2011-11-20 10:24 ` Andrew Kurn
@ 2011-11-20 20:30 ` Stefan Monnier
2011-11-21 0:03 ` Andrew Kurn
0 siblings, 1 reply; 9+ messages in thread
From: Stefan Monnier @ 2011-11-20 20:30 UTC (permalink / raw)
To: Andrew Kurn; +Cc: 10072
> Let me propose this wording:
> -----------
> However, if a command ends with point inside invisible text, the main editing
> loop moves point further forward or further backward (in the same direction
> that the command already moved it) until that condition is no longer true.
> The positions immediately before and immediately after invisible text are
> considered inside the invisible text if a char inserted at that position would
> inherit the @code{invisible} property.
> Thus, if the command moved point back into an invisible range
> (with the usual stickiness), Emacs moves
> point back to the beginning of that range.
> If the command moved point forward into an invisible range, Emacs moves point
> forward to the first visible character that follows the invisible text
> and then forward one more character.
> ---------
Thanks. I installed the text below instead (which is closer to what
really happens).
> As an opinion, I add that it would be more intuitive if it worked
> differently -- the way described in the original example -- but
> I can live with this once it is clearly explained. (The problem
> is, of course, that ^X= should always name a visible character,
> and the one that the cursor is over.)
The use of a block cursor that covers the "next visible char" indeed
tends to make people assume that point is right before that visible
char, but if you use a different cursor this is much less true.
In any case the driving factor is to try and avoid the case where
self-insert-command inserts invisible text, which is also
very confusing. Another advantage of the current behavior is that it
lets the author choose where to place point, by setting
stickiness appropriately, so you can get Emacs to indeed place the
cursor right in front of the next visible char.
>> The code that moves point out of invisible chunks of text does not
>> always work, indeed, because it is only applied to the current
>> buffer (or maybe the selected-window?) after a command.
> Yes, I see. This might need clarification in the text also.
Fundamentally it's a bug, and I generally don't like to document bugs.
Stefan
^ permalink raw reply [flat|nested] 9+ messages in thread* bug#10072: 23.3; invisible text
2011-11-20 20:30 ` Stefan Monnier
@ 2011-11-21 0:03 ` Andrew Kurn
2011-11-21 0:27 ` Drew Adams
2011-11-21 2:27 ` Stefan Monnier
0 siblings, 2 replies; 9+ messages in thread
From: Andrew Kurn @ 2011-11-21 0:03 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 10072
On Sun 20 Nov 2011 15:30 -0500, Stefan Monnier wrote:
>
> > Let me propose this wording:
> > -----------
[. . .]
> > ---------
>
> Thanks. I installed the text below instead (which is closer to what
> really happens).
>
Sorry, but I didn't receive this latest version. Could you re-send
it?
> > As an opinion, I add that it would be more intuitive if it worked
> > differently -- the way described in the original example -- but
> > I can live with this once it is clearly explained. (The problem
> > is, of course, that ^X= should always name a visible character,
> > and the one that the cursor is over.)
>
> The use of a block cursor that covers the "next visible char" indeed
> tends to make people assume that point is right before that visible
> char, but if you use a different cursor this is much less true.
>
Agreed.
> In any case the driving factor is to try and avoid the case where
> self-insert-command inserts invisible text, which is also
> very confusing. Another advantage of the current behavior is that it
> lets the author choose where to place point, by setting
> stickiness appropriately, so you can get Emacs to indeed place the
> cursor right in front of the next visible char.
Yes, I understand your thinking.
Right this moment, I don't have access to the latest version
of Emacs, so I am not sure of the relevance of this remark:
However, I was experimenting with invisibility in overlays
and I found it was possible to insert invisible text.
I suspect that the philosophy of the command-loop-move-point
thingy is to move point so that invisible text will not be
inserted in /any/ case. So there's another possible bug.
>
> >> The code that moves point out of invisible chunks of text does not
> >> always work, indeed, because it is only applied to the current
> >> buffer (or maybe the selected-window?) after a command.
> > Yes, I see. This might need clarification in the text also.
>
> Fundamentally it's a bug, and I generally don't like to document bugs.
On this point I disagree with you very strongly. It's much /more/
important to document bugs than any other aspect of the code. I have
told several students this from time to time, and, like you, they
tend to resist the idea.
I gather that there is no great push on to remedy this behavior,
so this bug may hang around for some time . . .
Anyhow, I'm pretty happy with my improved understanding, so I'm
grateful for your help. Are you a volunteer? I guess that FSF
doesn't have enough money to employ a staff of programmers to
deal with this sort of correspondence.
Andrew
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#10072: 23.3; invisible text
2011-11-21 0:03 ` Andrew Kurn
@ 2011-11-21 0:27 ` Drew Adams
2011-11-21 11:12 ` Andrew Kurn
2011-11-21 2:27 ` Stefan Monnier
1 sibling, 1 reply; 9+ messages in thread
From: Drew Adams @ 2011-11-21 0:27 UTC (permalink / raw)
To: 'Andrew Kurn', 'Stefan Monnier'; +Cc: 10072
> > Fundamentally it's a bug, and I generally don't like to
> > document bugs.
>
> On this point I disagree with you very strongly. It's much /more/
> important to document bugs than any other aspect of the code. I have
> told several students this from time to time, and, like you, they
> tend to resist the idea.
>
> I gather that there is no great push on to remedy this behavior,
> so this bug may hang around for some time . . .
FWIW - Bugs, other known problems, and workarounds are typically *not*
documented as part of the technical doc itself. One reason for this is that the
doc is meant to describe what the product does, or rather, what it should do,
what it is supposed to do. In a way, the doc is like a spec that the product is
meant to reflect.
Selected bugs and workarounds are, however, often documented in accessory,
release-specific documents such as release notes and readmes. One of the main
purposes of release notes and such is to let users know about certain known
problems and limitations, and how they might work around them.
And of course bugs are also often documented (after a fashion) in a bug tracking
system. For user-visible bugs, that gives users a sense of the history and fix
progress.
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#10072: 23.3; invisible text
2011-11-21 0:27 ` Drew Adams
@ 2011-11-21 11:12 ` Andrew Kurn
0 siblings, 0 replies; 9+ messages in thread
From: Andrew Kurn @ 2011-11-21 11:12 UTC (permalink / raw)
To: Drew Adams; +Cc: 10072
On Sun 20 Nov 2011 16:27 -0800, Drew Adams wrote:
>
> > > Fundamentally it's a bug, and I generally don't like to
> > > document bugs.
> >
> > On this point I disagree with you very strongly. It's much /more/
> > important to document bugs than any other aspect of the code. I have
> > told several students this from time to time, and, like you, they
> > tend to resist the idea.
> >
> > I gather that there is no great push on to remedy this behavior,
> > so this bug may hang around for some time . . .
>
> FWIW - Bugs, other known problems, and workarounds are typically *not*
> documented as part of the technical doc itself. One reason for this is that the
> doc is meant to describe what the product does, or rather, what it should do,
> what it is supposed to do. In a way, the doc is like a spec that the product is
> meant to reflect.
>
Ah, another voice, and also an intelligent one. It's gratifying to
meet the interesting community of Emacs-developers. I do so much
of my coding on my own . . .
Anyhow, I'd say I'm still in disagreement about this with you. However,
I'm pleased with the way the proposed wording is written (as you'll see
in the next message), so I'd say the issue is resolved.
Andrew
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#10072: 23.3; invisible text
2011-11-21 0:03 ` Andrew Kurn
2011-11-21 0:27 ` Drew Adams
@ 2011-11-21 2:27 ` Stefan Monnier
2011-11-21 11:37 ` Andrew Kurn
1 sibling, 1 reply; 9+ messages in thread
From: Stefan Monnier @ 2011-11-21 2:27 UTC (permalink / raw)
To: Andrew Kurn; +Cc: 10072
> Sorry, but I didn't receive this latest version. Could you re-send it?
Sorry, it's appended this time.
> Right this moment, I don't have access to the latest version
> of Emacs, so I am not sure of the relevance of this remark:
> However, I was experimenting with invisibility in overlays
> and I found it was possible to insert invisible text.
> I suspect that the philosophy of the command-loop-move-point
> thingy is to move point so that invisible text will not be
> inserted in /any/ case.
No: doing it reliably is fiendishly difficult and in general cannot be
done without breaking some code somewhere. So instead the code does
a best effort which covers 99% of the cases. It's fundamentally
very DWIMish.
> So there's another possible bug.
Probably, but maybe it's one of those cases where we can't win.
>> Fundamentally it's a bug, and I generally don't like to document bugs.
> On this point I disagree with you very strongly. It's much /more/
> important to document bugs than any other aspect of the code. I have
> told several students this from time to time, and, like you, they
> tend to resist the idea.
I tend to consider Emacs as a great big pile of bugs. It very much
follows a pragmatic "don't worry too much about corner cases" (some
people might call it "worse is better"), so documenting all bugs would
be a daunting task. You can see the bug-tracker as a way to document
the known bugs.
> I gather that there is no great push on to remedy this behavior,
> so this bug may hang around for some time . . .
Yes, I don't know of any effort to solve it, because the inconvenients
tend to be rather minor compared to the effort it would take to make it
work more reliably (some of those efforts would be spent figuring out
what the hell Emacs should do in various corner cases).
I'd like to see a pre-redisplay-functions hook added to Emacs for
various reasons (e.g., for reveal-mode, as well as to move the
region-highlighting code to Elisp), and such a hook might possibly allow
a more reliable implementation of this feature, but don't hold
your breath.
> Anyhow, I'm pretty happy with my improved understanding, so I'm
> grateful for your help. Are you a volunteer?
Yes, like all the other Emacs developers.
> I guess that FSF doesn't have enough money to employ a staff of
> programmers to deal with this sort of correspondence.
Indeed.
Stefan
=== modified file 'doc/lispref/display.texi'
--- a/doc/lispref/display.texi 2011-11-20 02:29:42 +0000
+++ b/doc/lispref/display.texi 2011-11-20 20:21:22 +0000
@@ -870,15 +870,21 @@
non-@code{nil} (the default), but only because they are explicitly
programmed to do so.
- However, if a command ends with point inside or immediately before
-invisible text, the main editing loop moves point further forward or
-further backward (in the same direction that the command already moved
-it) until that condition is no longer true. Thus, if the command
-moved point back into an invisible range, Emacs moves point back to
-the beginning of that range, and then back one more character. If the
-command moved point forward into an invisible range, Emacs moves point
-forward up to the first visible character that follows the invisible
-text.
+ However, if a command ends with point inside or at the boundary of invisible
+text, the main editing loop moves point to one of the two ends of the invisible
+text. Which end to move to is chosen based on the following factors: make sure
+that the overall movement of the command is still in the same direction, and
+prefer a position where an inserted char would not inherit the @code{invisible}
+property. Additionally, if the text is not replaced by an ellipsis and the
+command only moved within the invisible text, then point is moved one extra
+character so as to try and reflect the command's movement by a visible movement
+of the cursor.
+
+ Thus, if the command moved point back to an invisible range (with the usual
+stickiness), Emacs moves point back to the beginning of that range. If the
+command moved point forward into an invisible range, Emacs moves point forward
+to the first visible character that follows the invisible text and then forward
+one more character.
Incremental search can make invisible overlays visible temporarily
and/or permanently when a match includes invisible text. To enable
^ permalink raw reply [flat|nested] 9+ messages in thread* bug#10072: 23.3; invisible text
2011-11-21 2:27 ` Stefan Monnier
@ 2011-11-21 11:37 ` Andrew Kurn
0 siblings, 0 replies; 9+ messages in thread
From: Andrew Kurn @ 2011-11-21 11:37 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 10072
On Sun 20 Nov 2011 21:27 -0500, Stefan Monnier wrote:
>
> > Sorry, but I didn't receive this latest version. Could you re-send it?
>
> Sorry, it's appended this time.
>
[. . .]
>
> > I suspect that the philosophy of the command-loop-move-point
> > thingy is to move point so that invisible text will not be
> > inserted in /any/ case.
>
> No: doing it reliably is fiendishly difficult and in general cannot be
> done without breaking some code somewhere. So instead the code does
> a best effort which covers 99% of the cases. It's fundamentally
> very DWIMish.
>
Ah. I didn't know that. I'd thought that the next-insert-must-not-
inherit-invisible test could be applied until it returned true.
[. . .]
> I tend to consider Emacs as a great big pile of bugs. It very much
> follows a pragmatic "don't worry too much about corner cases" (some
> people might call it "worse is better"), so documenting all bugs would
> be a daunting task. You can see the bug-tracker as a way to document
> the known bugs.
This is where I have a benefit from not being a regular reader of
this mailing list: I consider Emacs to be very well debugged and
the documentation to be astonishingly literate and complete -- perhaps
the best of any program ever written.
[. . .]
>
> I'd like to see a pre-redisplay-functions hook added to Emacs for
> various reasons (e.g., for reveal-mode, as well as to move the
> region-highlighting code to Elisp), and such a hook might possibly allow
> a more reliable implementation of this feature, but don't hold
> your breath.
>
Interesting.
> > Anyhow, I'm pretty happy with my improved understanding, so I'm
> > grateful for your help. Are you a volunteer?
>
> Yes, like all the other Emacs developers.
[. . .]
Regarding the text below, I think it serves to express the situation
well. It makes it clear that the situation is not precisely described
but is a compromise of sereral factors and, therefore, not to
be strictly relied upon.
And, of course, it describes things in more detail than the previous
version, so an improvement.
My thanks for all your work.
Andrew
----------
>
>
> === modified file 'doc/lispref/display.texi'
> --- a/doc/lispref/display.texi 2011-11-20 02:29:42 +0000
> +++ b/doc/lispref/display.texi 2011-11-20 20:21:22 +0000
> @@ -870,15 +870,21 @@
> non-@code{nil} (the default), but only because they are explicitly
> programmed to do so.
>
> - However, if a command ends with point inside or immediately before
> -invisible text, the main editing loop moves point further forward or
> -further backward (in the same direction that the command already moved
> -it) until that condition is no longer true. Thus, if the command
> -moved point back into an invisible range, Emacs moves point back to
> -the beginning of that range, and then back one more character. If the
> -command moved point forward into an invisible range, Emacs moves point
> -forward up to the first visible character that follows the invisible
> -text.
> + However, if a command ends with point inside or at the boundary of invisible
> +text, the main editing loop moves point to one of the two ends of the invisible
> +text. Which end to move to is chosen based on the following factors: make sure
> +that the overall movement of the command is still in the same direction, and
> +prefer a position where an inserted char would not inherit the @code{invisible}
> +property. Additionally, if the text is not replaced by an ellipsis and the
> +command only moved within the invisible text, then point is moved one extra
> +character so as to try and reflect the command's movement by a visible movement
> +of the cursor.
> +
> + Thus, if the command moved point back to an invisible range (with the usual
> +stickiness), Emacs moves point back to the beginning of that range. If the
> +command moved point forward into an invisible range, Emacs moves point forward
> +to the first visible character that follows the invisible text and then forward
> +one more character.
>
> Incremental search can make invisible overlays visible temporarily
> and/or permanently when a match includes invisible text. To enable
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2011-11-21 11:37 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-11-18 19:14 bug#10072: 23.3; invisible text Andrew Kurn
2011-11-20 4:57 ` Stefan Monnier
2011-11-20 10:24 ` Andrew Kurn
2011-11-20 20:30 ` Stefan Monnier
2011-11-21 0:03 ` Andrew Kurn
2011-11-21 0:27 ` Drew Adams
2011-11-21 11:12 ` Andrew Kurn
2011-11-21 2:27 ` Stefan Monnier
2011-11-21 11:37 ` Andrew Kurn
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).