* Auto de-composition when point is inside a composition
@ 2019-10-21 14:15 Stefan Monnier
2019-10-21 16:07 ` Eli Zaretskii
2019-10-22 14:54 ` Eli Zaretskii
0 siblings, 2 replies; 6+ messages in thread
From: Stefan Monnier @ 2019-10-21 14:15 UTC (permalink / raw
To: emacs-devel
I was recently looking at the following code in keyboard.c:
if (last_point_position > BEGV
&& last_point_position < ZV
&& (composition_adjust_point (last_point_position,
last_point_position)
!= last_point_position))
/* The last point was temporarily set within a grapheme
cluster to prevent automatic composition. To recover
the automatic composition, we must update the
display. */
windows_or_buffers_changed = 21;
and wondered:
- why do we need to set windows_or_buffers_changed at all here?
after all, this code is only run in some circumstances, definitely not
all the circumstances where we might need to redraw the grapheme
cluster after point moved out of it, so it seems it's not the right
place to handle this case (it seems either redundant or insufficient).
- more importantly, does the inhibition of composition when point is in
the middle of it still work? I don't use languages which rely on
composition so I'm not completely sure how this feature is/was
supposed to work, but I do remember searching for "lam" in Elisp
buffers in which I had "lambda" prettified to "λ" and having those "λ"
temporarily be expanded back to "lambda" to show the cursor in the
middle of it. Yet, I can't seem to reproduce this de-composition
behavior any more. Is it still working? How can I trigger it?
-- Stefan
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Auto de-composition when point is inside a composition
2019-10-21 14:15 Auto de-composition when point is inside a composition Stefan Monnier
@ 2019-10-21 16:07 ` Eli Zaretskii
2019-10-21 18:43 ` Stefan Monnier
2019-10-22 14:54 ` Eli Zaretskii
1 sibling, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2019-10-21 16:07 UTC (permalink / raw
To: Stefan Monnier, Kenichi Handa; +Cc: emacs-devel
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Mon, 21 Oct 2019 10:15:43 -0400
>
> I was recently looking at the following code in keyboard.c:
>
> if (last_point_position > BEGV
> && last_point_position < ZV
> && (composition_adjust_point (last_point_position,
> last_point_position)
> != last_point_position))
> /* The last point was temporarily set within a grapheme
> cluster to prevent automatic composition. To recover
> the automatic composition, we must update the
> display. */
> windows_or_buffers_changed = 21;
>
> and wondered:
>
> - why do we need to set windows_or_buffers_changed at all here?
> after all, this code is only run in some circumstances, definitely not
> all the circumstances where we might need to redraw the grapheme
> cluster after point moved out of it, so it seems it's not the right
> place to handle this case (it seems either redundant or insufficient).
Maybe because otherwise the redisplay optimizations taken in case only
point moved could fail to redisplay (they might only redraw the
character at point, and fail to include the rest of the composition)?
> - more importantly, does the inhibition of composition when point is in
> the middle of it still work? I don't use languages which rely on
> composition so I'm not completely sure how this feature is/was
> supposed to work, but I do remember searching for "lam" in Elisp
> buffers in which I had "lambda" prettified to "λ" and having those "λ"
> temporarily be expanded back to "lambda" to show the cursor in the
> middle of it. Yet, I can't seem to reproduce this de-composition
> behavior any more. Is it still working? How can I trigger it?
Could be related to Backspace deleting just part of the grapheme
cluster? Or searching for a codepoint that is part of a composition?
But that's guessing, I don't really know the answer to this. Perhaps
Handa-san (CC'ed) does.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Auto de-composition when point is inside a composition
2019-10-21 16:07 ` Eli Zaretskii
@ 2019-10-21 18:43 ` Stefan Monnier
2019-10-21 19:08 ` Stefan Monnier
2019-10-22 14:52 ` Eli Zaretskii
0 siblings, 2 replies; 6+ messages in thread
From: Stefan Monnier @ 2019-10-21 18:43 UTC (permalink / raw
To: Eli Zaretskii; +Cc: Kenichi Handa, emacs-devel
>> - why do we need to set windows_or_buffers_changed at all here?
>> after all, this code is only run in some circumstances, definitely not
>> all the circumstances where we might need to redraw the grapheme
>> cluster after point moved out of it, so it seems it's not the right
>> place to handle this case (it seems either redundant or insufficient).
>
> Maybe because otherwise the redisplay optimizations taken in case only
> point moved could fail to redisplay (they might only redraw the
> character at point, and fail to include the rest of the composition)?
But in that case, if the command that moved point set
disable-point-adjustment to non-nil, we'd have a redisplay error, no
(since we'd then skip this chunk of code).
Stefan
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Auto de-composition when point is inside a composition
2019-10-21 18:43 ` Stefan Monnier
@ 2019-10-21 19:08 ` Stefan Monnier
2019-10-22 14:52 ` Eli Zaretskii
1 sibling, 0 replies; 6+ messages in thread
From: Stefan Monnier @ 2019-10-21 19:08 UTC (permalink / raw
To: Eli Zaretskii; +Cc: Kenichi Handa, emacs-devel
>> Maybe because otherwise the redisplay optimizations taken in case only
>> point moved could fail to redisplay (they might only redraw the
>> character at point, and fail to include the rest of the composition)?
>
> But in that case, if the command that moved point set
> disable-point-adjustment to non-nil, we'd have a redisplay error, no
> (since we'd then skip this chunk of code).
^
That should have been a question mark
Stefan
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Auto de-composition when point is inside a composition
2019-10-21 18:43 ` Stefan Monnier
2019-10-21 19:08 ` Stefan Monnier
@ 2019-10-22 14:52 ` Eli Zaretskii
1 sibling, 0 replies; 6+ messages in thread
From: Eli Zaretskii @ 2019-10-22 14:52 UTC (permalink / raw
To: Stefan Monnier; +Cc: handa, emacs-devel
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Kenichi Handa <handa@gnu.org>, emacs-devel@gnu.org
> Date: Mon, 21 Oct 2019 14:43:32 -0400
>
> >> - why do we need to set windows_or_buffers_changed at all here?
> >> after all, this code is only run in some circumstances, definitely not
> >> all the circumstances where we might need to redraw the grapheme
> >> cluster after point moved out of it, so it seems it's not the right
> >> place to handle this case (it seems either redundant or insufficient).
> >
> > Maybe because otherwise the redisplay optimizations taken in case only
> > point moved could fail to redisplay (they might only redraw the
> > character at point, and fail to include the rest of the composition)?
>
> But in that case, if the command that moved point set
> disable-point-adjustment to non-nil, we'd have a redisplay error, no
> (since we'd then skip this chunk of code).
I think this is about commands that add or remove codepoints from a
potentially composable sequence of characters, and those commands
aren't supposed to play games with this variable. And we reset the
variable before reading a command anyway.
Btw, I don't have a proof (and doing so would be neigh impossible),
but I suspect we don't need to set windows_or_buffers_changed here,
because it was needed when we had direct insertion and deletion of
characters as part of redisplay. But given how much surrounding text
HarfBuzzz wants to see to do what its developers consider a good job,
I wouldn't touch this even so.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Auto de-composition when point is inside a composition
2019-10-21 14:15 Auto de-composition when point is inside a composition Stefan Monnier
2019-10-21 16:07 ` Eli Zaretskii
@ 2019-10-22 14:54 ` Eli Zaretskii
1 sibling, 0 replies; 6+ messages in thread
From: Eli Zaretskii @ 2019-10-22 14:54 UTC (permalink / raw
To: Stefan Monnier; +Cc: emacs-devel
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Mon, 21 Oct 2019 10:15:43 -0400
>
> - more importantly, does the inhibition of composition when point is in
> the middle of it still work?
The "inhibition" in this case is in adjust_point_for_property, see the
commentary there. It talks about situations when you add or delete
codepoints to a sequence of composable characters.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-10-22 14:54 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-10-21 14:15 Auto de-composition when point is inside a composition Stefan Monnier
2019-10-21 16:07 ` Eli Zaretskii
2019-10-21 18:43 ` Stefan Monnier
2019-10-21 19:08 ` Stefan Monnier
2019-10-22 14:52 ` Eli Zaretskii
2019-10-22 14:54 ` Eli Zaretskii
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.