Auto de-composition when point is inside a composition

Auto de-composition when point is inside a composition

[Stefan Monnier]

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

Re: Auto de-composition when point is inside a composition

[Eli Zaretskii]

> 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.

Re: Auto de-composition when point is inside a composition

[Stefan Monnier]

>> - 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

Re: Auto de-composition when point is inside a composition

[Stefan Monnier]

>> 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

Re: Auto de-composition when point is inside a composition

[Eli Zaretskii]

> 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.

Re: Auto de-composition when point is inside a composition

[Eli Zaretskii]

> 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.