unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Ihor Radchenko <yantar92@gmail.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: Eli Zaretskii <eliz@gnu.org>, 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, 17 Jun 2022 18:05:36 +0800	[thread overview]
Message-ID: <87y1xv7ggf.fsf@localhost> (raw)
In-Reply-To: <jwvpmj86mba.fsf-monnier+emacs@gnu.org>

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> (let ((inhibit-modification-hooks t))
>>   (insert "Insertion that will never trigger before/after-change-functions"))
>
> This is a severely broken piece of code.  I don't think anyone should
> try and handle this in any other way than by screaming bloody murder
> when it detects the consequences.

>> (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.
>>  ))
>
> So this `unless` is intended to detect the case where we should scream
> bloody murder, right?
>
> Why do you need it?  AFAICT it should only be needed for debugging
> purposes until the offender is found and shamed publicly.
> [ I have a weird feeling that I might be one of the offenders.  ]
>
>> Ideally, a way to track _all_ buffer modifications regardless of
>> inhibit-modification-hooks would be useful.

Well. This was also my assumption. I initially implemented the checking
code to detect internal errors in Org.

Then we received 12 bug reports on this. The offenders were identified
in some cases. They were:
- polymode, valign, and ox-hugo
- Doom (unrelated to this particular issue, but Doom is let-binding major-mode...)
- Emacs quail and also replace-match in some cases (because of
  false-positives caused by changing buffer-chars-modified-tick)

ox-hugo and polymode fixed the issue.

valign relies on disabling modification hooks because it is otherwise
difficult to figure out pixel width of a string in current buffer:
https://github.com/casouri/valign/issues/30

In other cases, the offenders were hard to identify because of remote
debugging difficulty.

What I want to say is that the problem is more widespread than you may
think. And the consequences of missed modifications can cause very real
data corruption in Org files (some editing Org commands are relying on
cache being valid; if syntax boundaries are incorrect, the editing can
mess up the text). It must be avoided at all costs, regardless of the
recommended Elisp programming practices.

On top of the misbehaving third-party code, there is an issue described
in bug#46982. This discussion reminded me about
clone-indirect-buffer-hook, but it is only executed by
`clone-indirect-buffer', not by `make-indirect-buffer'. The latter is
used ubiquitously. See
https://github.com/search?q=make-indirect-buffer&type=code
Again, some unsuspecting users can experience data corruption just
because someone carelessly uses `make-indirect-buffer' in the code.

> I don't think this *can* exist: if we add a mechanism which ignores
> `inhibit-modification-hooks` it will still need some way to ignore some
> changes so we'll need another `inhibit-<foo>` variable to "silence"
> those changes and we'll be back at square one.
>
> 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.

See the above. There is real-world code doing things that make
Emacs ignore after-change-functions.

Combined with the issue revealed in this bug report, I am left with no
Emacs tools to handle the problematic buffer modifications.

Best,
Ihor






  parent reply	other threads:[~2022-06-17 10:05 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
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 [this message]
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=87y1xv7ggf.fsf@localhost \
    --to=yantar92@gmail.com \
    --cc=51766@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /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).