unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Ihor Radchenko <yantar92@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 51766@debbugs.gnu.org
Subject: 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, 12 Nov 2021 20:06:41 +0800	[thread overview]
Message-ID: <8735o1r31q.fsf@localhost> (raw)
In-Reply-To: <831r3m1tpk.fsf@gnu.org>

Eli Zaretskii <eliz@gnu.org> writes:

> That's exactly what happens: quail.el deletes the inserted character
> and then reinserts it (for reasons unrelated to this issue).  So the
> count of the changes is not equal to the number of characters actually
> inserted.  I see no problem here, since the documentation never
> promises that the difference between the values returned by successive
> calls to buffer-chars-modified-tick will be exactly equal to the
> number of inserted or deleted characters.

I agree that Emacs does not break any promises here. Though it is
unfortunate. Feel free to close this bug report.

> So if Org relies on such an equality, it's a bug in Org (but I didn't
> look at the relevant Org code, and don't have a clear idea of how
> exactly it uses the above function for whatever it is caching).

Let me explain a little (hoping that you might have some idea about
alternative solutions without using buffer-chars-modified-tick).

Org has a caching mechanism (org-element-cache) that keeps parsed buffer
representation in memory and updates it on the fly as the buffer
changes. To make the mechanism work, Org must keep track of all the
changes in buffer and update the affected Org elements in memory.
Naturally, this is done using before/after-change-functions.

However, some third-party code carelessly uses
inhibit-modification-hooks and some edits may be missed by element
cache. If we just ignore the possibility of such edits, cache can be
broken badly. So, there is currently a control code that detects if
buffer has been changed outside the Org's change functions. The control
code uses buffer-chars-modified-tick.

The behaviour of quail.el makes the control code useless -
buffer-chars-modified-tick can no longer be reliably used to detect
unfavourable "stealthy" changes. AFAIK, the only alternative way to
detect the changes is buffer-hash/secure-hash. But calculating hash is
very too slow when I try to put it into before/after-change-functions. I
do not know any fast (as fast as buffer-chars-modified-tick) way to
detect buffer changes.

> quail.el inhibit buffer modifications in places, since otherwise you'd
> have too many of them.  It wants to pretend that just one character
> was inserted.

I understand the idea behind suppressing the modification hooks by
quail. Though it would be helpful if before-change-functions were called
before inserting+deleting a character by quail is done.

Best,
Ihor






  reply	other threads:[~2021-11-12 12:06 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-11 13:56 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 Ihor Radchenko
2021-11-11 15:19 ` Eli Zaretskii
2021-11-11 15:50   ` Ihor Radchenko
2021-11-11 17:35     ` Eli Zaretskii
2021-11-12 12:06       ` Ihor Radchenko [this message]
2021-11-12 12:15         ` Eli Zaretskii
2021-11-12 12:53           ` Ihor Radchenko
2021-11-12 13:09             ` Eli Zaretskii
2021-11-12 13:39               ` Ihor Radchenko
2021-11-12 15:17                 ` Eli Zaretskii
2021-11-13  9:10                   ` Ihor Radchenko
2021-11-13 10:11                     ` Eli Zaretskii
2021-11-13 11:29                       ` Ihor Radchenko
2021-11-13 13:38                         ` Eli Zaretskii
2021-11-13 14:43                           ` Ihor Radchenko
2021-11-13 15:24                             ` Eli Zaretskii
2022-06-17  2:54                     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-06-17  5:36                       ` Eli Zaretskii
2022-06-17 13:16                         ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-06-17 10:05                       ` Ihor Radchenko
2022-06-17 10:50                         ` Eli Zaretskii
2022-06-21  4:13                           ` bug#51766: string-pixel-width limitations (was: 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) Ihor Radchenko
2022-06-21 10:16                             ` Eli Zaretskii
2022-06-21 11:00                               ` Ihor Radchenko
2022-06-21 12:17                                 ` Eli Zaretskii
2022-06-21 12:39                                   ` Ihor Radchenko
2022-06-21 12:47                                     ` Eli Zaretskii
2022-06-21 13:03                                       ` Ihor Radchenko
2022-06-22 23:49                                         ` bug#51766: string-pixel-width limitations Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-06-17 13:28                         ` 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 Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-06-21  4:14                           ` Ihor Radchenko

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=8735o1r31q.fsf@localhost \
    --to=yantar92@gmail.com \
    --cc=51766@debbugs.gnu.org \
    --cc=eliz@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).