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:53:33 +0800	[thread overview]
Message-ID: <87zgq9pmb6.fsf@localhost> (raw)
In-Reply-To: <834k8hzi10.fsf@gnu.org>

Eli Zaretskii <eliz@gnu.org> writes:

> This last part I don't think I understand: why does quail's behavior
> make the control code useless?  The value returned by
> buffer-chars-modified-tick still increases in your recipe, so what
> exactly is the aspect of that behavior that makes the control code
> useless?  I think some additional details here are missing from your
> description which could explain the issue.

The control code makes sure that all the changes made in buffer are
processed by org-element-cache. It means that
org-element--after-change-function saves the buffer-chars-modified-tick
and the next org-element--before-change-function checks if the saved
value is unchanged. If the saved value is changed, the buffer has been
changed after org-element--after-change-function, but before next
org-element--before-change-function. Such change may be arbitrary and
the whole cache is potentially obsolete.

In code, the described roughly looks like:

(defun org-element--after-change-function (...)
 (setq org-element-chars-modified-tick (buffer-chars-modified-tick))
 (org-element-cache-submit-request ...))

(defun org-element--before-change-function (...)
 (unless (eq org-element-chars-modified-tick (buffer-chars-modified-tick))
     ;; Buffer has been changed without calling after-change-function
     ;; and we have no way to determine which part of buffer has been changed.
 ))

quail changes the buffer after org-element--after-change-function call,
but before org-element--before-change-function. So, all Org can see is
that something has been changed in buffer, but there is no way to tell
what it was. Org cannot distinguish between harmless buffer edits by
quail (they do not change buffer text) and other kinds of "silent"
changes.

> I don't understand this, either.  Are you saying that inserting a
> character via an input method doesn't call buffer-modification hooks
> even once?  If the hooks are called, then what exactly is the problem
> with the hooks in this scenario?

The hooks are called, but after quail already triggered
buffer-chars-modified-tick increase. If quail called
before-change-functions before buffer-chars-modified-tick increases, it
would be useful for my scenario. Though I am not sure how feasible it
is. Just an idea.

Best,
Ihor





  reply	other threads:[~2021-11-12 12:53 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
2021-11-12 12:15         ` Eli Zaretskii
2021-11-12 12:53           ` Ihor Radchenko [this message]
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=87zgq9pmb6.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).