GNU bug report logs - #51766
29.0.50; Return value of buffer-chars-modified-tick changes when buffer text is not yet changed before inserting a character for non-latin input methods

Previous Next

Full log

Message #65 received at 51766 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 51766 <at> debbugs.gnu.org, yantar92 <at> gmail.com
Subject: Re: bug#51766: 29.0.50; Return value of buffer-chars-modified-tick
 changes when buffer text is not yet changed before inserting a character
 for non-latin input methods
Date: Fri, 17 Jun 2022 09:16:34 -0400

Eli Zaretskii [2022-06-17 08:36:37] wrote:
>> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>,  51766 <at> debbugs.gnu.org
>> Date: Thu, 16 Jun 2022 22:54:22 -0400
>> 
>> I think the better way to proceed is to figure out why/when
>> significant changes are made while `inhibit-modification-hooks` is
>> non-nil, since that's the origin of your problems, AFAICT.
>
> I thought that was clear from the rest of the discussion: it's quail's
> input methods that cause the issue, because quail tries to pretend
> that just one character was inserted, when in fact the user could type
> several characters.

AFAIK in the case of Quail the char-modified-ticks changes (so there's
some insertions/deletions going on) while `inhibit-modification-hooks`
is set, but the state of the buffer at the next
`before-change-functions` is correct, e.g. the buffer-hash is unchanged.

IOW in the cse of Quail the Org mode code doesn't need to flush the
whole parser's state, which means that the code that flushes the parser
state when char-modified-ticks is modified silently was written to
defend against *other* problems.


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.