* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
@ 2025-01-17 7:42 Tassilo Horn
2025-01-17 8:32 ` Eli Zaretskii
0 siblings, 1 reply; 99+ messages in thread
From: Tassilo Horn @ 2025-01-17 7:42 UTC (permalink / raw)
To: 75626
I have a directory test/ with files foobar.N for N in 0 to 99 and do:
emacs -Q test
M-x auto-revert-mode RET
% m .* RET ; mark all files
Z ; compress them all
Z ; uncompress them all again
Z ; again and again...
...
I always wait until the (un)compress operations are all done before
pressing Z again. But even though, at some Z you will notice that your
directory doesn't contain only gz or only non-gz files but a mix of
both!
It seems the reason is that auto-revert-mode at some point reverts the
buffer at random points in time while dired is still (un)compressing and
that changes the order of files so that it either misses files or
processes some files twice.
It also seems it is more likely to catch the error when the files take
some time to (un)compress, so I filled them with
head -c 1000000 /dev/urandom | strings
i.e., random but long enough content.
I've had that issue just half an hour ago with a directory containing
similar gzipped large logfiles. There, the error hit me so hard that I
basically had an infloop where the same files seemed to be uncompressed
and then compressed over and over again, with just a single "mark all"
and dired-do-compress operation.
In GNU Emacs 31.0.50 (build 79, x86_64-pc-linux-gnu, GTK+ Version
3.24.43, cairo version 1.18.2) of 2025-01-17 built on thinkpad-t440p
Repository revision: 37b5b3ea91a4ed005664540091e5150d2454d8d6
Repository branch: master
System Description: Arch Linux
Configured using:
'configure --with-tree-sitter --with-pgtk --with-modules'
Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
LCMS2 LIBOTF LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY
PDUMPER PGTK PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XIM GTK3 ZLIB
Important settings:
value of $LC_MONETARY: de_DE.utf8
value of $LC_NUMERIC: de_DE.utf8
value of $LC_TIME: de_DE.utf8
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
Major mode: mu4e:main
Minor modes in effect:
breadcrumb-mode: t
editorconfig-mode: t
global-aggressive-indent-mode: t
pdf-occur-global-minor-mode: t
diredfl-global-mode: t
mu4e-search-minor-mode: t
mu4e-update-minor-mode: t
mu4e-context-minor-mode: t
mu4e-modeline-mode: t
which-key-mode: t
highlight-parentheses-mode: t
global-git-commit-mode: t
magit-auto-revert-mode: t
server-mode: t
corfu-popupinfo-mode: t
corfu-history-mode: t
global-corfu-mode: t
corfu-mode: t
vertico-mode: t
marginalia-mode: t
minibuffer-depth-indicate-mode: t
global-eldoc-diffstat-mode: t
switchy-window-minor-mode: t
electric-pair-mode: t
recentf-mode: t
override-global-mode: t
repeat-mode: t
global-so-long-mode: t
save-place-mode: t
savehist-mode: t
puni-global-mode: t
puni-mode: t
tooltip-mode: t
global-eldoc-mode: t
show-paren-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
minibuffer-regexp-mode: t
buffer-read-only: t
column-number-mode: t
transient-mark-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
overwrite-mode: overwrite-mode-binary
Load-path shadows:
~/Repos/el/mu/mu4e/mu4e hides ~/Repos/el/mu/build/mu4e/mu4e
~/Repos/el/mu/mu4e/mu4e-modeline hides ~/Repos/el/mu/build/mu4e/mu4e-modeline
~/Repos/el/mu/mu4e/mu4e-context hides ~/Repos/el/mu/build/mu4e/mu4e-context
~/Repos/el/mu/mu4e/mu4e-main hides ~/Repos/el/mu/build/mu4e/mu4e-main
~/Repos/el/mu/mu4e/mu4e-vars hides ~/Repos/el/mu/build/mu4e/mu4e-vars
~/Repos/el/mu/mu4e/mu4e-window hides ~/Repos/el/mu/build/mu4e/mu4e-window
~/Repos/el/mu/mu4e/mu4e-speedbar hides ~/Repos/el/mu/build/mu4e/mu4e-speedbar
~/Repos/el/mu/mu4e/mu4e-view hides ~/Repos/el/mu/build/mu4e/mu4e-view
~/Repos/el/mu/mu4e/mu4e-thread hides ~/Repos/el/mu/build/mu4e/mu4e-thread
~/Repos/el/mu/mu4e/mu4e-bookmarks hides ~/Repos/el/mu/build/mu4e/mu4e-bookmarks
~/Repos/el/mu/mu4e/mu4e-org hides ~/Repos/el/mu/build/mu4e/mu4e-org
~/Repos/el/mu/mu4e/mu4e-lists hides ~/Repos/el/mu/build/mu4e/mu4e-lists
~/Repos/el/mu/mu4e/mu4e-actions hides ~/Repos/el/mu/build/mu4e/mu4e-actions
~/Repos/el/mu/mu4e/mu4e-helpers hides ~/Repos/el/mu/build/mu4e/mu4e-helpers
~/Repos/el/mu/mu4e/mu4e-search hides ~/Repos/el/mu/build/mu4e/mu4e-search
~/Repos/el/mu/mu4e/mu4e-server hides ~/Repos/el/mu/build/mu4e/mu4e-server
~/Repos/el/mu/mu4e/mu4e-obsolete hides ~/Repos/el/mu/build/mu4e/mu4e-obsolete
~/Repos/el/mu/mu4e/mu4e-update hides ~/Repos/el/mu/build/mu4e/mu4e-update
~/Repos/el/mu/mu4e/mu4e-draft hides ~/Repos/el/mu/build/mu4e/mu4e-draft
~/Repos/el/mu/mu4e/mu4e-message hides ~/Repos/el/mu/build/mu4e/mu4e-message
~/Repos/el/mu/mu4e/mu4e-compose hides ~/Repos/el/mu/build/mu4e/mu4e-compose
~/Repos/el/mu/mu4e/mu4e-headers hides ~/Repos/el/mu/build/mu4e/mu4e-headers
~/Repos/el/mu/mu4e/mu4e-query-items hides ~/Repos/el/mu/build/mu4e/mu4e-query-items
~/Repos/el/mu/mu4e/mu4e-notification hides ~/Repos/el/mu/build/mu4e/mu4e-notification
~/Repos/el/mu/mu4e/mu4e-contacts hides ~/Repos/el/mu/build/mu4e/mu4e-contacts
~/Repos/el/mu/mu4e/mu4e-transient hides ~/Repos/el/mu/build/mu4e/mu4e-transient
~/Repos/el/mu/mu4e/mu4e-icalendar hides ~/Repos/el/mu/build/mu4e/mu4e-icalendar
~/Repos/el/mu/mu4e/mu4e-mark hides ~/Repos/el/mu/build/mu4e/mu4e-mark
~/Repos/el/mu/mu4e/mu4e-contrib hides ~/Repos/el/mu/build/mu4e/mu4e-contrib
~/Repos/el/mu/mu4e/mu4e-folders hides ~/Repos/el/mu/build/mu4e/mu4e-folders
~/Repos/el/mu/mu4e/mu4e-mime-parts hides ~/Repos/el/mu/build/mu4e/mu4e-mime-parts
/home/horn/.emacs.d/elpa/ef-themes-1.9.0/theme-loaddefs hides /home/horn/Repos/el/emacs/lisp/theme-loaddefs
Features:
(etags fileloop shortdoc dired-aux dabbrev cape-keyword cape shadow sort
expreg cap-words superword subword face-remap mail-extr emacsbug
misearch multi-isearch eglot external-completion jsonrpc flymake ert
debug backtrace cus-start view help-fns radix-tree tramp-cmds puni
display-fill-column-indicator display-line-numbers tsdh-light-theme
generic yaml-mode fish-mode cargo xref cargo-process rust-utils
rust-mode-treesitter rust-ts-mode rust-mode rust-playpen rust-cargo
rust-common rust-rustfmt rust-compile web-mode disp-table
auctex-autoloads tex-site breadcrumb pulse project editorconfig
editorconfig-core editorconfig-core-handle editorconfig-fnmatch
elfeed-show elfeed-search vc-hg vc-bzr vc-src vc-sccs vc-svn vc-cvs
vc-rcs log-view debbugs-browse elfeed-csv elfeed elfeed-curl elfeed-log
elfeed-db elfeed-lib avl-tree url-queue xml-query hl-todo
aggressive-indent rainbow-mode pdf-occur tablist tablist-filter
semantic/wisent/comp semantic/wisent semantic/wisent/wisent
semantic/util-modes semantic/util semantic semantic/tag semantic/lex
semantic/fw mode-local cedet pdf-isearch pdf-misc pdf-tools pdf-view
jka-compr pdf-cache pdf-info tq pdf-util pdf-macs image-mode exif vc-git
vc-dir ewoc epa-file trashed diredfl dired-x eshell esh-cmd generator
esh-ext esh-proc esh-opt esh-io esh-arg esh-module esh-module-loaddefs
esh-util mu4e-icalendar gnus-icalendar icalendar diary-lib
diary-loaddefs mu4e mu4e-org mu4e-notification notifications mu4e-main
smtpmail mu4e-view mu4e-mime-parts mu4e-headers mu4e-thread mu4e-actions
org-capture org-refile org ob ob-tangle ob-ref ob-lob ob-table ob-exp
org-macro org-src sh-script smie executable ob-comint org-pcomplete
org-list org-footnote org-faces org-entities ob-emacs-lisp ob-core
ob-eval org-cycle org-table ol org-fold org-fold-core org-keys oc
org-loaddefs cal-menu calendar cal-loaddefs org-compat org-version
org-macs mu4e-compose mu4e-draft gnus-msg mu4e-search mu4e-lists
mu4e-bookmarks mu4e-mark mu4e-message flow-fill mule-util mu4e-contacts
mu4e-update mu4e-folders mu4e-context mu4e-query-items mu4e-server
mu4e-modeline mu4e-vars mu4e-helpers mu4e-config mu4e-window
magit-bookmark bookmark ido mu4e-obsolete hippie-exp auto-dictionary
flyspell ispell tramp-smb which-key highlight-parentheses restclient
advice forge-repos forge-tablist hl-line forge-topics forge-commands
forge-semi forge-bitbucket buck forge-gogs gogs forge-gitea gtea
forge-gitlab glab forge-github ghub-graphql treepy gsexp ghub let-alist
forge-forgejo forge-notify forge-revnote forge-pullreq forge-issue
forge-topic yaml eieio-custom forge-post markdown-mode noutline outline
forge-repo forge forge-core forge-db closql emacsql-sqlite emacsql
emacsql-compiler eieio-base magit-submodule magit-blame magit-stash
magit-reflog magit-bisect magit-push magit-pull magit-fetch magit-clone
magit-remote magit-commit magit-sequence magit-notes magit-worktree
magit-tag magit-merge magit-branch magit-reset magit-files magit-refs
magit-status magit magit-repos magit-apply magit-wip magit-log
which-func imenu magit-diff smerge-mode diff diff-mode track-changes
git-commit log-edit pcvs-util add-log magit-core magit-autorevert
autorevert filenotify magit-margin magit-transient magit-process
with-editor comp comp-cstr server magit-mode benchmark magit-git
magit-base magit-section cursor-sensor crm dash visual-filename-abbrev
rg vc vc-dispatcher rg-info-hack rg-menu transient rg-ibuffer rg-result
wgrep-rg wgrep rg-history rg-header ibuf-ext ibuffer ibuffer-loaddefs
grep debbugs soap-client url-http url-auth url-gw nsm warnings rng-xsd
rng-dt rng-util xsd-regexp debbugs-compat bug-reference thingatpt
kind-icon svg-lib color corfu-popupinfo corfu-history corfu vertico
marginalia icomplete mb-depth eldoc-diffstat use-package-diminish
switchy-window compat elec-pair recentf tree-widget edmacro kmacro
use-package-bind-key bind-key diminish repeat toml-ts-mode json-ts-mode
c++-ts-mode c-ts-mode java-ts-mode c-ts-common find-func treesit so-long
saveplace tramp-cache time-stamp tramp-sh tramp trampver
tramp-integration files-x tramp-message tramp-compat shell pcomplete
format-spec tramp-loaddefs savehist smiley gnus-art mm-uu mml2015
mm-view mml-smime smime gnutls dig gnus-sum shr pixel-fill kinsoku
url-file svg dom gnus-group gnus-undo gnus-start gnus-dbus dbus compile
comint ansi-osc ansi-color ring comp-run comp-common rx xml gnus-cloud
nnimap nnmail mail-source utf7 nnoo parse-time iso8601 gnus-spec
gnus-int gnus-range message sendmail yank-media puny dired
dired-loaddefs rfc822 mml mml-sec epa derived epg rfc6068 epg-config
mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045
ietf-drums mailabbrev gmm-utils mailheader gnus-win gnus nnheader
gnus-util text-property-search time-date mm-util mail-prsvr mail-utils
range ef-themes cl-extra help-mode use-package-ensure use-package-core
finder-inf cus-edit pp cus-load wid-edit aggressive-indent-autoloads
auto-dictionary-autoloads breadcrumb-autoloads cape-autoloads
cargo-autoloads clojure-mode-autoloads corfu-autoloads
csv-mode-autoloads debbugs-autoloads diminish-autoloads
diredfl-autoloads eat-autoloads ef-themes-autoloads
eldoc-diffstat-autoloads elfeed-autoloads ement-autoloads
expreg-autoloads fish-mode-autoloads forge-autoloads closql-autoloads
emacsql-autoloads ghub-autoloads highlight-parentheses-autoloads
hl-todo-autoloads kind-icon-autoloads magit-autoloads pcase
marginalia-autoloads markdown-mode-autoloads mastodon-autoloads
pdf-tools-autoloads persist-autoloads plz-autoloads puni-autoloads
easy-mmode rainbow-mode-autoloads rcirc-color-autoloads
request-autoloads restclient-autoloads rg-autoloads rust-mode-autoloads
svg-lib-autoloads symbol-overlay-autoloads tablist-autoloads
taxy-magit-section-autoloads taxy-autoloads magit-section-autoloads
dash-autoloads tp-autoloads trashed-autoloads treepy-autoloads
vertico-autoloads visual-filename-abbrev-autoloads web-mode-autoloads
wgrep-autoloads info with-editor-autoloads yaml-autoloads
yaml-mode-autoloads package browse-url xdg url url-proxy url-privacy
url-expand url-methods url-history url-cookie generate-lisp-file
url-domsuf url-util mailcap url-handlers url-parse auth-source cl-seq
eieio eieio-core cl-macs icons password-cache json subr-x map byte-opt
gv bytecomp byte-compile url-vars cl-loaddefs cl-lib rmc iso-transl
tooltip cconv eldoc paren electric uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode mwheel term/pgtk-win pgtk-win term/common-win
touch-screen pgtk-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode lisp-mode prog-mode register
page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer nadvice seq simple cl-generic indonesian philippine
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads dbusbind inotify dynamic-setting system-font-setting
font-render-setting cairo gtk pgtk lcms2 multi-tty move-toolbar
make-network-process tty-child-frames native-compile emacs)
Memory information:
((conses 16 1064655 204213) (symbols 48 58002 17) (strings 32 291793 11325)
(string-bytes 1 8415463) (vectors 16 109237) (vector-slots 8 1246508 142280)
(floats 8 918 970) (intervals 56 29636 1707) (buffers 992 35))
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-17 7:42 bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled Tassilo Horn
@ 2025-01-17 8:32 ` Eli Zaretskii
2025-01-17 9:04 ` Tassilo Horn
0 siblings, 1 reply; 99+ messages in thread
From: Eli Zaretskii @ 2025-01-17 8:32 UTC (permalink / raw)
To: Tassilo Horn; +Cc: 75626
> From: Tassilo Horn <tsdh@gnu.org>
> Date: Fri, 17 Jan 2025 08:42:42 +0100
>
>
> I have a directory test/ with files foobar.N for N in 0 to 99 and do:
>
> emacs -Q test
> M-x auto-revert-mode RET
> % m .* RET ; mark all files
> Z ; compress them all
> Z ; uncompress them all again
> Z ; again and again...
> ...
>
> I always wait until the (un)compress operations are all done before
> pressing Z again. But even though, at some Z you will notice that your
> directory doesn't contain only gz or only non-gz files but a mix of
> both!
>
> It seems the reason is that auto-revert-mode at some point reverts the
> buffer at random points in time while dired is still (un)compressing and
> that changes the order of files so that it either misses files or
> processes some files twice.
What happens if you set auto-revert-use-notify to the nil value?
In any case, if you stop pressing 'Z', doesn't the list of files
eventually become up-to-date? And if it does, why is this considered
a bug? The fact that auto-revert-mode catching the directory in some
intermediate state from time, when files in the directory are being
created and deleted, to time should not come as a surprise, I think.
Or what am I missing?
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-17 8:32 ` Eli Zaretskii
@ 2025-01-17 9:04 ` Tassilo Horn
2025-01-17 12:17 ` Eli Zaretskii
2025-01-17 23:36 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 2 replies; 99+ messages in thread
From: Tassilo Horn @ 2025-01-17 9:04 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 75626
Eli Zaretskii <eliz@gnu.org> writes:
Hi Eli,
>> emacs -Q test
>> M-x auto-revert-mode RET
>> % m .* RET ; mark all files
>> Z ; compress them all
>> Z ; uncompress them all again
>> Z ; again and again...
>> ...
>>
>> I always wait until the (un)compress operations are all done before
>> pressing Z again. But even though, at some Z you will notice that
>> your directory doesn't contain only gz or only non-gz files but a mix
>> of both!
>>
>> It seems the reason is that auto-revert-mode at some point reverts
>> the buffer at random points in time while dired is still
>> (un)compressing and that changes the order of files so that it either
>> misses files or processes some files twice.
>
> What happens if you set auto-revert-use-notify to the nil value?
It seems that makes the bug even more likely to trigger. Out ouf 3
tests with my 100 files, even after just one Z operation, I had mixed gz
and uncompressed files (starting from 100 uncompressed files).
> In any case, if you stop pressing 'Z', doesn't the list of files
> eventually become up-to-date?
No, as said, after pressing Z, I always wait until the operation is
done. And I get final dired messages like
Compress or uncompress: 162 files.
Well, there are exactly 100 files. So it processed 62 files twice,
compressing them first and then uncompressing them again (or skipped
some and processed other even more).
> And if it does, why is this considered a bug? The fact that
> auto-revert-mode catching the directory in some intermediate state
> from time, when files in the directory are being created and deleted,
> to time should not come as a surprise, I think. Or what am I missing?
Yes, that's no surprise. But it should not cause files to be missed or
double-processed, i.e., I would expect that dired initially captures all
marked files and then processes them one by one. But it looks like
dired navigates the dired buffer marked file by marked file and when the
sorting changes in between due to a refresh, it misses or
double-processes files.
Maybe Z is special in that the files are renamed (.gz suffix gone or
added) but keep their mark. I wonder what would happen if Z would not
just rename but add another file that also would be marked so that the
set of marked files grows with each operation. In that case, I assume
it would never finish.
Bye,
Tassilo
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-17 9:04 ` Tassilo Horn
@ 2025-01-17 12:17 ` Eli Zaretskii
2025-01-17 13:03 ` Tassilo Horn
2025-01-17 23:36 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 1 reply; 99+ messages in thread
From: Eli Zaretskii @ 2025-01-17 12:17 UTC (permalink / raw)
To: Tassilo Horn; +Cc: 75626
> From: Tassilo Horn <tsdh@gnu.org>
> Cc: 75626@debbugs.gnu.org
> Date: Fri, 17 Jan 2025 10:04:25 +0100
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> Hi Eli,
>
> >> emacs -Q test
> >> M-x auto-revert-mode RET
> >> % m .* RET ; mark all files
> >> Z ; compress them all
> >> Z ; uncompress them all again
> >> Z ; again and again...
> >> ...
> >>
> >> I always wait until the (un)compress operations are all done before
> >> pressing Z again. But even though, at some Z you will notice that
> >> your directory doesn't contain only gz or only non-gz files but a mix
> >> of both!
> >>
> >> It seems the reason is that auto-revert-mode at some point reverts
> >> the buffer at random points in time while dired is still
> >> (un)compressing and that changes the order of files so that it either
> >> misses files or processes some files twice.
> >
> > What happens if you set auto-revert-use-notify to the nil value?
>
> It seems that makes the bug even more likely to trigger. Out ouf 3
> tests with my 100 files, even after just one Z operation, I had mixed gz
> and uncompressed files (starting from 100 uncompressed files).
>
> > In any case, if you stop pressing 'Z', doesn't the list of files
> > eventually become up-to-date?
>
> No, as said, after pressing Z, I always wait until the operation is
> done. And I get final dired messages like
>
> Compress or uncompress: 162 files.
>
> Well, there are exactly 100 files. So it processed 62 files twice,
> compressing them first and then uncompressing them again (or skipped
> some and processed other even more).
>
> > And if it does, why is this considered a bug? The fact that
> > auto-revert-mode catching the directory in some intermediate state
> > from time, when files in the directory are being created and deleted,
> > to time should not come as a surprise, I think. Or what am I missing?
>
> Yes, that's no surprise. But it should not cause files to be missed or
> double-processed, i.e., I would expect that dired initially captures all
> marked files and then processes them one by one. But it looks like
> dired navigates the dired buffer marked file by marked file and when the
> sorting changes in between due to a refresh, it misses or
> double-processes files.
That's not how dired-do-* commands work, though. So I think an easier
solution would be to temporarily disable auto-revert-mode while the
command runs.
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-17 12:17 ` Eli Zaretskii
@ 2025-01-17 13:03 ` Tassilo Horn
2025-01-17 13:26 ` Eli Zaretskii
0 siblings, 1 reply; 99+ messages in thread
From: Tassilo Horn @ 2025-01-17 13:03 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 75626
Eli Zaretskii <eliz@gnu.org> writes:
>> I would expect that dired initially captures all marked files and
>> then processes them one by one. But it looks like dired navigates
>> the dired buffer marked file by marked file and when the sorting
>> changes in between due to a refresh, it misses or double-processes
>> files.
>
> That's not how dired-do-* commands work, though.
Too bad. :-(
> So I think an easier solution would be to temporarily disable
> auto-revert-mode while the command runs.
First, I wanted to say that this wouldn't help because nobody hinders
the user to refresh himself. But apparently no matter how hard I try to
hit g after starting the Z operation on all files, I can't reproduce the
issue. I even ramped up to 1000 instead of 100 files.
What is the difference between auto-revert and manually reverting? It
seems that with just manual reverting (repeatedly hitting g during the
(un)compress operation on many files), I only get one refresh initially
which doesn't change the sorting order (or possibly only with very exact
timing) and then Emacs is blocked until all files are (un)compressed.
With auto-revert-mode, I get many intermediate refreshes during the
operation.
Bye,
Tassilo
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-17 13:03 ` Tassilo Horn
@ 2025-01-17 13:26 ` Eli Zaretskii
2025-01-17 14:13 ` Tassilo Horn
0 siblings, 1 reply; 99+ messages in thread
From: Eli Zaretskii @ 2025-01-17 13:26 UTC (permalink / raw)
To: Tassilo Horn; +Cc: 75626
> From: Tassilo Horn <tsdh@gnu.org>
> Cc: 75626@debbugs.gnu.org
> Date: Fri, 17 Jan 2025 14:03:18 +0100
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > So I think an easier solution would be to temporarily disable
> > auto-revert-mode while the command runs.
>
> First, I wanted to say that this wouldn't help because nobody hinders
> the user to refresh himself.
Sure, but is this a reasonable solution? Users who turn on
auto-revert-mode don't expect to need to revert manually, I think.
> But apparently no matter how hard I try to
> hit g after starting the Z operation on all files, I can't reproduce the
> issue. I even ramped up to 1000 instead of 100 files.
>
> What is the difference between auto-revert and manually reverting? It
> seems that with just manual reverting (repeatedly hitting g during the
> (un)compress operation on many files), I only get one refresh initially
> which doesn't change the sorting order (or possibly only with very exact
> timing) and then Emacs is blocked until all files are (un)compressed.
> With auto-revert-mode, I get many intermediate refreshes during the
> operation.
Yes, because auto-revert-mode works as part of the Emacs's main loop,
whereas user input is processed only when Emacs is idle.
Does let-binding inhibit-redisplay in the auto-revert function help in
any way?
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-17 13:26 ` Eli Zaretskii
@ 2025-01-17 14:13 ` Tassilo Horn
2025-01-17 19:38 ` Eli Zaretskii
0 siblings, 1 reply; 99+ messages in thread
From: Tassilo Horn @ 2025-01-17 14:13 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 75626
Eli Zaretskii <eliz@gnu.org> writes:
>> First, I wanted to say that this wouldn't help because nobody hinders
>> the user to refresh himself.
>
> Sure, but is this a reasonable solution? Users who turn on
> auto-revert-mode don't expect to need to revert manually, I think.
Of course. What I mean is that I expected to be able to trigger the bug
also by reverting manually by hitting g, i.e., without having
auto-revert-mode turned on. But that seems to be at least much harder.
>> But apparently no matter how hard I try to hit g after starting the Z
>> operation on all files, I can't reproduce the issue. I even ramped
>> up to 1000 instead of 100 files.
>>
>> What is the difference between auto-revert and manually reverting?
>> It seems that with just manual reverting (repeatedly hitting g during
>> the (un)compress operation on many files), I only get one refresh
>> initially which doesn't change the sorting order (or possibly only
>> with very exact timing) and then Emacs is blocked until all files are
>> (un)compressed. With auto-revert-mode, I get many intermediate
>> refreshes during the operation.
>
> Yes, because auto-revert-mode works as part of the Emacs's main loop,
> whereas user input is processed only when Emacs is idle.
I see. Can emacs become idle when waiting for a process to finish (like
gunzip)? If so, the problem could also happen with manual reverts
instead of auto-revert-mode.
> Does let-binding inhibit-redisplay in the auto-revert function help in
> any way?
Not at all. (I've bound it to t in the top let in dired-revert which is
the revert-buffer-function in dired buffers. That's what you meant,
right?)
Bye,
Tassilo
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-17 14:13 ` Tassilo Horn
@ 2025-01-17 19:38 ` Eli Zaretskii
2025-01-17 21:38 ` Tassilo Horn
0 siblings, 1 reply; 99+ messages in thread
From: Eli Zaretskii @ 2025-01-17 19:38 UTC (permalink / raw)
To: Tassilo Horn; +Cc: 75626
> From: Tassilo Horn <tsdh@gnu.org>
> Cc: 75626@debbugs.gnu.org
> Date: Fri, 17 Jan 2025 15:13:24 +0100
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > Yes, because auto-revert-mode works as part of the Emacs's main loop,
> > whereas user input is processed only when Emacs is idle.
>
> I see. Can emacs become idle when waiting for a process to finish (like
> gunzip)?
Not if the process was started with call-process.
> > Does let-binding inhibit-redisplay in the auto-revert function help in
> > any way?
>
> Not at all. (I've bound it to t in the top let in dired-revert which is
> the revert-buffer-function in dired buffers. That's what you meant,
> right?)
No, I meant in auto-revert-buffers. But maybe what you did has the
same effect.
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-17 19:38 ` Eli Zaretskii
@ 2025-01-17 21:38 ` Tassilo Horn
0 siblings, 0 replies; 99+ messages in thread
From: Tassilo Horn @ 2025-01-17 21:38 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 75626
Eli Zaretskii <eliz@gnu.org> writes:
>> > Yes, because auto-revert-mode works as part of the Emacs's main
>> > loop, whereas user input is processed only when Emacs is idle.
>>
>> I see. Can emacs become idle when waiting for a process to finish
>> (like gunzip)?
>
> Not if the process was started with call-process.
I see.
>> > Does let-binding inhibit-redisplay in the auto-revert function help
>> > in any way?
>>
>> Not at all. (I've bound it to t in the top let in dired-revert which
>> is the revert-buffer-function in dired buffers. That's what you
>> meant, right?)
>
> No, I meant in auto-revert-buffers. But maybe what you did has the
> same effect.
I've also tried to bind it in auto-revert-buffers with the same effect.
Bye,
Tassilo
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-17 9:04 ` Tassilo Horn
2025-01-17 12:17 ` Eli Zaretskii
@ 2025-01-17 23:36 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-18 8:42 ` Tassilo Horn
1 sibling, 1 reply; 99+ messages in thread
From: Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-01-17 23:36 UTC (permalink / raw)
To: Tassilo Horn; +Cc: 75626, Eli Zaretskii
Tassilo Horn <tsdh@gnu.org> writes:
> Well, there are exactly 100 files. So it processed 62 files twice,
> compressing them first and then uncompressing them again (or skipped
> some and processed other even more).
It could be that the order of the marked files changed after reverting.
But even if not: if you look at the use of the variable `next-position'
in `dired-map-over-marks', it is also possible to get such an effect if
the line lengths change.
So the command `dired-do-compress' is not robust against this effect.
Other commands calculate the complete list of marked files first,
`dired-do-chxxx' and `dired-do-chmod' for example. So I think it is not
unavoidable that it is like that.
Michael.
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-17 23:36 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-01-18 8:42 ` Tassilo Horn
2025-01-18 11:17 ` Ship Mints
` (2 more replies)
0 siblings, 3 replies; 99+ messages in thread
From: Tassilo Horn @ 2025-01-18 8:42 UTC (permalink / raw)
To: Michael Heerdegen; +Cc: 75626, Eli Zaretskii
Michael Heerdegen <michael_heerdegen@web.de> writes:
>> Well, there are exactly 100 files. So it processed 62 files twice,
>> compressing them first and then uncompressing them again (or skipped
>> some and processed other even more).
>
> It could be that the order of the marked files changed after
> reverting.
>
> But even if not: if you look at the use of the variable
> `next-position' in `dired-map-over-marks', it is also possible to get
> such an effect if the line lengths change.
>
> So the command `dired-do-compress' is not robust against this effect.
> Other commands calculate the complete list of marked files first,
> `dired-do-chxxx' and `dired-do-chmod' for example. So I think it is
> not unavoidable that it is like that.
What is the reason that there are two different approaches to process
all marked files, i.e., dired-map-over-marks vs. dired-get-marked-files?
Bye,
Tassilo
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-18 8:42 ` Tassilo Horn
@ 2025-01-18 11:17 ` Ship Mints
2025-01-18 23:19 ` Tassilo Horn
2025-01-18 21:17 ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-19 2:05 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2 siblings, 1 reply; 99+ messages in thread
From: Ship Mints @ 2025-01-18 11:17 UTC (permalink / raw)
To: Tassilo Horn; +Cc: Michael Heerdegen, 75626, Eli Zaretskii
[-- Attachment #1: Type: text/plain, Size: 1240 bytes --]
I'm sure you know this...you could add dired-mode to the
global-auto-revert-ignore-modes list if you
have global-auto-revert-non-file-buffers bound to t, which I'm guessing you
do.
On Sat, Jan 18, 2025 at 3:43 AM Tassilo Horn <tsdh@gnu.org> wrote:
> Michael Heerdegen <michael_heerdegen@web.de> writes:
>
> >> Well, there are exactly 100 files. So it processed 62 files twice,
> >> compressing them first and then uncompressing them again (or skipped
> >> some and processed other even more).
> >
> > It could be that the order of the marked files changed after
> > reverting.
> >
> > But even if not: if you look at the use of the variable
> > `next-position' in `dired-map-over-marks', it is also possible to get
> > such an effect if the line lengths change.
> >
> > So the command `dired-do-compress' is not robust against this effect.
> > Other commands calculate the complete list of marked files first,
> > `dired-do-chxxx' and `dired-do-chmod' for example. So I think it is
> > not unavoidable that it is like that.
>
> What is the reason that there are two different approaches to process
> all marked files, i.e., dired-map-over-marks vs. dired-get-marked-files?
>
> Bye,
> Tassilo
>
>
>
>
[-- Attachment #2: Type: text/html, Size: 1798 bytes --]
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-18 8:42 ` Tassilo Horn
2025-01-18 11:17 ` Ship Mints
@ 2025-01-18 21:17 ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-18 23:43 ` Tassilo Horn
2025-01-19 2:05 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2 siblings, 1 reply; 99+ messages in thread
From: Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-01-18 21:17 UTC (permalink / raw)
To: Tassilo Horn, Michael Heerdegen; +Cc: 75626@debbugs.gnu.org, Eli Zaretskii
> What is the reason that there are two different approaches to process
> all marked files, i.e., dired-map-over-marks vs. dired-get-marked-files?
(Caveat: I'm not following this thread.)
The doc string, and how those two are used in
the code, tell you the answer.
`dired-get-marked-files' just gives you a list
of the marked files. `dired-map-over-marks'
is a macro, not a function, and it _processes_
the files.
More precisely, `dired-map-over-marks' evals
some code with point on each marked line:
"Eval BODY with point on each marked line.
Return a list of BODY's results."
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-18 11:17 ` Ship Mints
@ 2025-01-18 23:19 ` Tassilo Horn
0 siblings, 0 replies; 99+ messages in thread
From: Tassilo Horn @ 2025-01-18 23:19 UTC (permalink / raw)
To: Ship Mints; +Cc: Michael Heerdegen, 75626, Eli Zaretskii
Ship Mints <shipmints@gmail.com> writes:
> I'm sure you know this...you could add dired-mode to the
> global-auto-revert-ignore-modes list if you have
> global-auto-revert-non-file-buffers bound to t, which I'm guessing you
> do.
Yes, indeed. That's what I'm doing now.
Bye,
Tassilo
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-18 21:17 ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-01-18 23:43 ` Tassilo Horn
2025-01-20 0:24 ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 99+ messages in thread
From: Tassilo Horn @ 2025-01-18 23:43 UTC (permalink / raw)
To: Drew Adams; +Cc: Michael Heerdegen, 75626@debbugs.gnu.org, Eli Zaretskii
Drew Adams <drew.adams@oracle.com> writes:
>> What is the reason that there are two different approaches to process
>> all marked files, i.e., dired-map-over-marks
>> vs. dired-get-marked-files?
>
> (Caveat: I'm not following this thread.)
The context is that commands like dired-do-compress which use
dired-map-over-marks can skip or double-process marked files in case the
dired buffer is reverted during the operation by auto-revert-mode (most
likely because the sorting order changes due to the suffix .gz being
removed or added).
> The doc string, and how those two are used in
> the code, tell you the answer.
>
> `dired-get-marked-files' just gives you a list
> of the marked files. `dired-map-over-marks'
> is a macro, not a function, and it _processes_
> the files.
Ok, I should have said: why do some dired commands use
dired-get-marked-files together with some loop, and a processing
function while others use dired-map-over-marks with the processing code
as body? I mean, both approaches do essentially the same but only the
latter is subject of the issue I've reported.
Is there some example dired command that can only work with
dired-map-over-marks and not by collecting all marked files at the
beginning? It would need to be something where the processing code
marks files that haven't been marked before. But I can't think of an
example where that would be desired.
Bye,
Tassilo
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-18 8:42 ` Tassilo Horn
2025-01-18 11:17 ` Ship Mints
2025-01-18 21:17 ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-01-19 2:05 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-19 10:33 ` Tassilo Horn
2 siblings, 1 reply; 99+ messages in thread
From: Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-01-19 2:05 UTC (permalink / raw)
To: Tassilo Horn; +Cc: 75626, Eli Zaretskii
Tassilo Horn <tsdh@gnu.org> writes:
> What is the reason that there are two different approaches to process
> all marked files, i.e., dired-map-over-marks vs. dired-get-marked-files?
It could be that it is just a historical coincidence.
The question than would be if we want to reimplement the command, or if
we try to make it (more) robust.
We could, for example, remember the current position as a marker instead
of a number, and/or try to prevent auto revert while the command is
processed. AFAIU, `dired-buffer-stale-p' could be changed to return nil
in this case to prevent reverting. Or would binding
dired-auto-revert-buffer -> nil already be enough?
Michael.
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-19 2:05 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-01-19 10:33 ` Tassilo Horn
2025-01-20 1:51 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 99+ messages in thread
From: Tassilo Horn @ 2025-01-19 10:33 UTC (permalink / raw)
To: Michael Heerdegen; +Cc: 75626, Eli Zaretskii
Michael Heerdegen <michael_heerdegen@web.de> writes:
Hi Michael,
> The question than would be if we want to reimplement the command, or
> if we try to make it (more) robust.
>
> We could, for example, remember the current position as a marker
> instead of a number,
Oh, just remembering point as a numeric value is certainly wrong given
that (un)compressing will certainly change the length of filenames. But
sorting order is also a problem where even a marker won't help. For
example, with just 21 files named 0 to 20 the initial sorting order is:
--8<---------------cut here---------------start------------->8---
❯ ls -l
total 84
-rw-r--r-- 1 horn horn 70 19. Jan 11:11 0
-rw-r--r-- 1 horn horn 69 19. Jan 11:11 1
-rw-r--r-- 1 horn horn 65 19. Jan 11:11 10
-rw-r--r-- 1 horn horn 26 19. Jan 11:11 11
-rw-r--r-- 1 horn horn 60 19. Jan 11:11 12
-rw-r--r-- 1 horn horn 43 19. Jan 11:11 13
-rw-r--r-- 1 horn horn 79 19. Jan 11:11 14
-rw-r--r-- 1 horn horn 72 19. Jan 11:11 15
-rw-r--r-- 1 horn horn 40 19. Jan 11:11 16
-rw-r--r-- 1 horn horn 91 19. Jan 11:11 17
-rw-r--r-- 1 horn horn 37 19. Jan 11:11 18
-rw-r--r-- 1 horn horn 65 19. Jan 11:11 19
-rw-r--r-- 1 horn horn 104 19. Jan 11:11 2
-rw-r--r-- 1 horn horn 44 19. Jan 11:11 20
-rw-r--r-- 1 horn horn 46 19. Jan 11:11 3
-rw-r--r-- 1 horn horn 82 19. Jan 11:11 4
-rw-r--r-- 1 horn horn 66 19. Jan 11:11 5
-rw-r--r-- 1 horn horn 67 19. Jan 11:11 6
-rw-r--r-- 1 horn horn 82 19. Jan 11:11 7
-rw-r--r-- 1 horn horn 70 19. Jan 11:11 8
-rw-r--r-- 1 horn horn 68 19. Jan 11:11 9
--8<---------------cut here---------------end--------------->8---
After compressing the first 5 files 0, 1, 10, 11, and 12 it becomes:
--8<---------------cut here---------------start------------->8---
~/tmp/test
❯ ls -l
total 84
-rw-r--r-- 1 horn horn 92 19. Jan 11:11 0.gz
-rw-r--r-- 1 horn horn 88 19. Jan 11:11 10.gz
-rw-r--r-- 1 horn horn 49 19. Jan 11:11 11.gz
-rw-r--r-- 1 horn horn 83 19. Jan 11:11 12.gz
-rw-r--r-- 1 horn horn 43 19. Jan 11:11 13
-rw-r--r-- 1 horn horn 79 19. Jan 11:11 14
-rw-r--r-- 1 horn horn 72 19. Jan 11:11 15
-rw-r--r-- 1 horn horn 40 19. Jan 11:11 16
-rw-r--r-- 1 horn horn 91 19. Jan 11:11 17
-rw-r--r-- 1 horn horn 37 19. Jan 11:11 18
-rw-r--r-- 1 horn horn 65 19. Jan 11:11 19
-rw-r--r-- 1 horn horn 91 19. Jan 11:11 1.gz
-rw-r--r-- 1 horn horn 104 19. Jan 11:11 2
-rw-r--r-- 1 horn horn 44 19. Jan 11:11 20
-rw-r--r-- 1 horn horn 46 19. Jan 11:11 3
-rw-r--r-- 1 horn horn 82 19. Jan 11:11 4
-rw-r--r-- 1 horn horn 66 19. Jan 11:11 5
-rw-r--r-- 1 horn horn 67 19. Jan 11:11 6
-rw-r--r-- 1 horn horn 82 19. Jan 11:11 7
-rw-r--r-- 1 horn horn 70 19. Jan 11:11 8
-rw-r--r-- 1 horn horn 68 19. Jan 11:11 9
--8<---------------cut here---------------end--------------->8---
So here the 1.gz will be uncompressed again if auto-revert-mode decided
to revert in that moment. Just ramp up the number of files to 1000 and
you'll surely get a (un)compression infloop in dired.
> and/or try to prevent auto revert while the command is processed.
That seems to be advisable as a first aid. Not sure if there are other
ways to trigger the issue, too.
> AFAIU, `dired-buffer-stale-p' could be changed to return nil in this
> case to prevent reverting.
Good idea. I've tried this simple patch and it fixes the issue for me.
--8<---------------cut here---------------start------------->8---
diff --git a/lisp/dired.el b/lisp/dired.el
index bab5e833a76..1152d85f149 100644
--- a/lisp/dired.el
+++ b/lisp/dired.el
@@ -1289,6 +1289,10 @@ dired-buffer-stale-p
;; Do not auto-revert when the dired buffer can be currently
;; written by the user as in `wdired-mode'.
buffer-read-only
+ ;; When a dired operation using dired-map-over-marks is in
+ ;; progress, inhibit-read-only is set and we must not
+ ;; auto-revert.
+ (null inhibit-read-only)
(dired-directory-changed-p dirname))))
(defcustom dired-auto-revert-buffer nil
--8<---------------cut here---------------end--------------->8---
Probably testing inhibit-read-only is not TRT but the expansion of
dired-map-over-marks should explicitly let-bind some new
dired--map-over-marks-in-progress variable to make it more explicit...
> Or would binding dired-auto-revert-buffer -> nil already be enough?
No. That's only for reverting on re-visiting a dired buffer and has no
influence on auto-revert-mode.
Bye,
Tassilo
^ permalink raw reply related [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-18 23:43 ` Tassilo Horn
@ 2025-01-20 0:24 ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-20 1:13 ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 99+ messages in thread
From: Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-01-20 0:24 UTC (permalink / raw)
To: Tassilo Horn; +Cc: Michael Heerdegen, 75626@debbugs.gnu.org, Eli Zaretskii
> The context is that commands like dired-do-compress which use
> dired-map-over-marks can skip or double-process marked files in case the
> dired buffer is reverted during the operation by auto-revert-mode (most
> likely because the sorting order changes due to the suffix .gz being
> removed or added).
As the doctor says, when the patient says it hurts
if he bangs his head on the wall: "Don't do that." ;-)
> > The doc string, and how those two are used in
> > the code, tell you the answer.
> >
> > `dired-get-marked-files' just gives you a list
> > of the marked files. `dired-map-over-marks'
> > is a macro, not a function, and it _processes_
> > the files.
>
> Ok, I should have said: why do some dired commands use
> dired-get-marked-files together with some loop, and a processing
> function while others use dired-map-over-marks with the processing code
> as body? I mean, both approaches do essentially the same but only the
> latter is subject of the issue I've reported.
`dired-get-marked-files' is defined using
`dired-map-over-marks'. The latter is more general
and more basic.
You use the former to get a list of file names -
the files marked in the buffer.
The latter isn't just about file names. It's about
the markings, and even the state of the Dired
buffer. You can do anything you want, as you map
over the marked _lines_.
(But it seems from this bug report that one
shouldn't try to revert the buffer etc. To me, that
makes sense, since the macro is explicitly about the
current state of the buffer - its markings etc.
Depending on the revert function/behavior that could
change that state.)
> Is there some example dired command that can only work with
> dired-map-over-marks and not by collecting all marked files at the
> beginning?
See below, for general info. One example is command
`dired-do-flagged-delete'.
> It would need to be something where the processing code
> marks files that haven't been marked before.
Not at all. It could depend on the sort order
of the listing, etc., since it _processes_ the
marked lines _in order_. More generally, it
could depend other ways on the current Dired
display. It's about going to the marked _lines_,
in order, and doing something on each line. It
need not do anything with the files listed on
those lines. It could report on how the buffer
displays their mod time or size...
Function `dired-get-marked-files' just gives
you a list of file names, which you can process
in any order.
> But I can't think of an example where that would be desired.
Did you look at the functions that are defined
using macro `dired-map-over-marks'? Functions
such as `dired-do-redisplay' explicitly have to
do with the buffer display. (I don't claim that
each such function needs to be defined using
that macro, but its not a bad bet that it does.)
`image-dired-dired-insert-marked-thumbs' inserts
thumbnails before the file names on the marked
lines. Again, it's about the displayed Dired
buffer.
Function `dired-map-over-marks-check' processes
the marked lines, in order, reporting on errors
from invoking a function on each of them. The
function need not act on the file that's marked
at all; it can take any arguments and do anything.
Similarly for other functions that use the macro.
Another use is in commands that you want to act
on the marked files - OR, if none are marked, on
the file of the current line. Yes, sometimes
you could use `dired-get-marked-files' for that.
But there's difference between a currently marked
file name in a listing (let alone a marked line,
which is really what it's about) and a file.
The listing might not even correspond currently
with the state of the file system. You could
use the macro to do something for files that no
longer exist, provided they're still listed -
so yeah, you might not want the command to
allow reversion. (I don't know how to prevent
reversion, but I suppose you could make and
restore a copy of the buffer. ;-))
Yet another use case is wanting to do something
on the lines marked with a char other than `*'.
That's used, for instance, in the definition of
`dired-do-flagged-delete'. It couldn't use
`dired-get-marked-files' to do what it does.
E.g., try using this command to get you a list
of the files marked for deletion (i.e., `D'):
(defun foo ()
(interactive)
(let ((dired-marker-char 42))
(message "%S" (dired-get-marked-files))))
Doesn't work - it always gives you the files
marked `*' (or the file of the current line,
if none are marked `*').
___
You could ask the same question about using
function `dired-map-over-marks-check' versus
using `dired-get-marked-files'. And pretty
much the same answer is relevant, I think:
processing marked lines, in the current sort
order, versus just getting a list of files.
(In Dired+ I use `dired-map-over-marks-check'
often. I use `dired-map-over-marks' much
less often.)
___
BTW, `dired-do-compress' uses function
`dired-map-over-marks-check', not macro
`dired-map-over-marks'. Indirectly, it
uses the latter, of course.
___
The point is that if you need only a list
of the files marked `*' then you can use
`dired-get-marked-files'. If you need only
what `dired-map-over-marks-check' does,
then you can use that. If you need what
macro `dired-map-over-marks' does, then use
that.
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-20 0:24 ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-01-20 1:13 ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 0 replies; 99+ messages in thread
From: Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-01-20 1:13 UTC (permalink / raw)
To: Drew Adams, Tassilo Horn
Cc: Michael Heerdegen, 75626@debbugs.gnu.org, Eli Zaretskii
I wrote:
> (I don't know how to prevent
> reversion, but I suppose you could make and
> restore a copy of the buffer. ;-))
One could just bind `revert-buffer-function'
locally to #'ignore.
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-19 10:33 ` Tassilo Horn
@ 2025-01-20 1:51 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-20 3:48 ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors
[not found] ` <86ikq97ip0.fsf@gnu.org>
0 siblings, 2 replies; 99+ messages in thread
From: Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-01-20 1:51 UTC (permalink / raw)
To: Tassilo Horn; +Cc: 75626, Eli Zaretskii
Tassilo Horn <tsdh@gnu.org> writes:
> Good idea. I've tried this simple patch and it fixes the issue for me.
>
> diff --git a/lisp/dired.el b/lisp/dired.el
> index bab5e833a76..1152d85f149 100644
> --- a/lisp/dired.el
> +++ b/lisp/dired.el
> @@ -1289,6 +1289,10 @@ dired-buffer-stale-p
> ;; Do not auto-revert when the dired buffer can be currently
> ;; written by the user as in `wdired-mode'.
> buffer-read-only
> + ;; When a dired operation using dired-map-over-marks is in
> + ;; progress, inhibit-read-only is set and we must not
Better say "bound" please.
> + ;; auto-revert.
> + (null inhibit-read-only)
And use `not' here, since we are testing a boolean valued flag.
> (dired-directory-changed-p dirname))))
>
> (defcustom dired-auto-revert-buffer nil
>
> Probably testing inhibit-read-only is not TRT but the expansion of
> dired-map-over-marks should explicitly let-bind some new
> dired--map-over-marks-in-progress variable to make it more explicit...
Yes. OTOH it's not bad either. `inhibit-read-only' bound (together
with buffer-read-only which we already have) is a good indicator for
that some operation is running and we should not auto revert.
Unless I'm missing something I would prefer this solution.
Michael.
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-20 1:51 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-01-20 3:48 ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors
[not found] ` <87ldv6j9lv.fsf@gnu.org>
[not found] ` <86ikq97ip0.fsf@gnu.org>
1 sibling, 1 reply; 99+ messages in thread
From: Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-01-20 3:48 UTC (permalink / raw)
To: Michael Heerdegen, Tassilo Horn; +Cc: 75626@debbugs.gnu.org, Eli Zaretskii
Still not following this thread. But if the plan
is to make `dired-map-over-marks' prevent things
such as reverting, then a priori I'm not in favor
of that. A priori, I think that macro should
implement no such control, and make _few or no
assumptions_ about the context in which it's used
or the purposes to which it might be put to use.
Such control is not its role.
If some particular _use_ of the macro should
provide some such control, e.g., should not let
XYZ happen, then fix that function instead (even
if that might mean not using the macro there).
The macro itself should stay general & unassuming.
Yeah, what I'm saying is vague. And I'm not
following the bug thread. But it smells/feels
kinda like preparation to throw out the baby
with the bathwater. Especially when I see
questions about the difference between the
macro and `dired-get-marked-files'.
If you need some different behavior in a more
_general_ way, i.e., at the level of a building
block and not just a fix to some particular
function, then consider adding a _new_ general
function/macro, instead of changing
`dired-map-over-marks.
Please be sure you change/fix only something
that's specifically broken, without redefining
this longstanding building block based on
unnecessary assumptions.
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
[not found] ` <87wmepfuxp.fsf@web.de>
@ 2025-01-20 16:49 ` Eli Zaretskii
2025-01-20 16:55 ` Tassilo Horn
2025-01-20 17:08 ` Eli Zaretskii
0 siblings, 2 replies; 99+ messages in thread
From: Eli Zaretskii @ 2025-01-20 16:49 UTC (permalink / raw)
To: Michael Heerdegen; +Cc: 75626, tsdh
> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: tsdh@gnu.org, 75626@debbugs.gnu.org
> Date: Mon, 20 Jan 2025 14:58:58 +0100
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > > > Introducing `dired--map-over-marks-in-progress' sounds cleaner to me
> > > > than that.
> > >
> > > But it probably needs to be buffer local [...]
> >
> > Yes, of course.
>
> Then, finally, I would name it `dired--prevent-auto-revert' because this
> might be useful in other places as well.
Let's use dired--inhibit-auto-revert instead.
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-20 16:49 ` Eli Zaretskii
@ 2025-01-20 16:55 ` Tassilo Horn
2025-01-20 17:08 ` Eli Zaretskii
1 sibling, 0 replies; 99+ messages in thread
From: Tassilo Horn @ 2025-01-20 16:55 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Michael Heerdegen, 75626-done
Eli Zaretskii <eliz@gnu.org> writes:
>> Then, finally, I would name it `dired--prevent-auto-revert' because
>> this might be useful in other places as well.
>
> Let's use dired--inhibit-auto-revert instead.
Alright, pushed to master as 40d5ff01e51.
Thanks,
Tassilo
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-20 16:49 ` Eli Zaretskii
2025-01-20 16:55 ` Tassilo Horn
@ 2025-01-20 17:08 ` Eli Zaretskii
2025-01-20 17:19 ` Tassilo Horn
1 sibling, 1 reply; 99+ messages in thread
From: Eli Zaretskii @ 2025-01-20 17:08 UTC (permalink / raw)
To: michael_heerdegen; +Cc: 75626, tsdh
> Cc: 75626@debbugs.gnu.org, tsdh@gnu.org
> Date: Mon, 20 Jan 2025 18:49:23 +0200
> From: Eli Zaretskii <eliz@gnu.org>
>
> > From: Michael Heerdegen <michael_heerdegen@web.de>
> > Cc: tsdh@gnu.org, 75626@debbugs.gnu.org
> > Date: Mon, 20 Jan 2025 14:58:58 +0100
> >
> > Eli Zaretskii <eliz@gnu.org> writes:
> >
> > > > > Introducing `dired--map-over-marks-in-progress' sounds cleaner to me
> > > > > than that.
> > > >
> > > > But it probably needs to be buffer local [...]
> > >
> > > Yes, of course.
> >
> > Then, finally, I would name it `dired--prevent-auto-revert' because this
> > might be useful in other places as well.
>
> Let's use dired--inhibit-auto-revert instead.
And, btw, if we want this to be useful outside of Dired, we need to
make this variable public, not internal. That is, call it
dired-inhibit-auto-revert.
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-20 17:08 ` Eli Zaretskii
@ 2025-01-20 17:19 ` Tassilo Horn
2025-01-20 19:07 ` Eli Zaretskii
0 siblings, 1 reply; 99+ messages in thread
From: Tassilo Horn @ 2025-01-20 17:19 UTC (permalink / raw)
To: Eli Zaretskii, michael_heerdegen; +Cc: 75626
Am Mo, 20. Jan 2025, um 18:08, schrieb Eli Zaretskii:
>> Let's use dired--inhibit-auto-revert instead.
>
> And, btw, if we want this to be useful outside of Dired, we need to
> make this variable public, not internal. That is, call it
> dired-inhibit-auto-revert.
Sorry, I can't follow. Why should a variable named dired-* be used outside of dired?
Bye,
Tassilo
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
[not found] ` <87ldv6j9lv.fsf@gnu.org>
@ 2025-01-20 17:32 ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-20 19:13 ` Eli Zaretskii
[not found] ` <87frlej8ad.fsf@gnu.org>
1 sibling, 1 reply; 99+ messages in thread
From: Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-01-20 17:32 UTC (permalink / raw)
To: Tassilo Horn; +Cc: Michael Heerdegen, 75626@debbugs.gnu.org, Eli Zaretskii
> > The macro itself should stay general & unassuming.
>
> The plan is to change dired-buffer-stale-p so that it returns nil when
> inhibit-read-only is bound to a non-nil value which is the case during
> the execution of the code generated by dired-map-over-marks and might
> catch other cases, too.
Doesn't sound right, to me.
> The macro itself stays as-is.
Doesn't sound like its behavior stays the same,
whether from `dired-buffer-stale-p' or otherwise.
Let's not split hairs. If you're changing its
behavior in a _general_ way, instead of just
changing the behavior realized in some function
that invokes it (e.g. by binding some vars around
its call), then you are, in effect, changing the
macro "itself".
Is that necessary? I can't see why it would be.
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
[not found] ` <87frlej8ad.fsf@gnu.org>
@ 2025-01-20 17:32 ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-20 18:01 ` Tassilo Horn
2025-01-20 19:15 ` Eli Zaretskii
0 siblings, 2 replies; 99+ messages in thread
From: Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-01-20 17:32 UTC (permalink / raw)
To: Tassilo Horn; +Cc: Michael Heerdegen, 75626@debbugs.gnu.org, Eli Zaretskii
> >> The macro itself should stay general & unassuming.
> >
> > The plan is to change dired-buffer-stale-p so that it returns nil when
> > inhibit-read-only is bound to a non-nil value which is the case during
> > the execution of the code generated by dired-map-over-marks and might
> > catch other cases, too. The macro itself stays as-is.
>
> The missing part: this change hinders auto-revert-mode from reverting
> the dired buffer during an operation on marked files.
That shouldn't happen, IMO. Too general,
and I doubt it's needed.
One might very well want to allow reversion
during some particular operation on marked
files. Let's not assume otherwise.
An operation on marked files - which really
means, for this macro, an operation on marked
_lines_, CAN DO ANYTHING. Whatever you might
want to do to, or with, the Dired buffer
display/listing you can do. That is, you
could until now, it sounds like.
We should not be making _any_ assumptions
about what use of the macro can be allowed
to do or should do. The macro and whatever
affects its use generally should not control
behavior of the function that it invokes.
Instead, code that _invokes the macro_ can,
and should, do whatever it needs, to get
the control behavior _it_ needs.
I'm repeating myself, and yes, I'm still
being vague. But it really smells/feels
like we're now going against the generality
(and utility) of this macro, and doing so
just to be able to fix some _particular_
uses of it. That should be a no-no.
Can you not fix those uses in their own
contexts, instead of ____ing the macro and
limiting its uses?
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-20 17:32 ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-01-20 18:01 ` Tassilo Horn
2025-01-20 18:28 ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-20 19:15 ` Eli Zaretskii
1 sibling, 1 reply; 99+ messages in thread
From: Tassilo Horn @ 2025-01-20 18:01 UTC (permalink / raw)
To: Drew Adams; +Cc: Michael Heerdegen, 75626@debbugs.gnu.org, Eli Zaretskii
Drew Adams <drew.adams@oracle.com> writes:
>> >> The macro itself should stay general & unassuming.
>> >
>> > The plan is to change dired-buffer-stale-p so that it returns nil
>> > when inhibit-read-only is bound to a non-nil value which is the
>> > case during the execution of the code generated by
>> > dired-map-over-marks and might catch other cases, too. The macro
>> > itself stays as-is.
>>
>> The missing part: this change hinders auto-revert-mode from reverting
>> the dired buffer during an operation on marked files.
>
> That shouldn't happen, IMO. Too general,
> and I doubt it's needed.
This bug contains a recipe showing at least one ocassion where it is
needed.
> One might very well want to allow reversion
> during some particular operation on marked
> files. Let's not assume otherwise.
Sure, and that's still allowed, e.g., the code given as BODY of
dired-map-over-marks could explicitly call revert-buffer if it can
handle the result.
The point is that auto-revert-mode reverts at _unpredictable_ moments
where chances are high that the dired buffer contents change in a way
that the processing logic goes wrong, e.g., a marked and not yet
processed file is now before point and will be skipped, or the other way
round, an already processed file is now after point and will be
processed again.
> An operation on marked files - which really
> means, for this macro, an operation on marked
> _lines_, CAN DO ANYTHING. Whatever you might
> want to do to, or with, the Dired buffer
> display/listing you can do. That is, you
> could until now, it sounds like.
I don't see what feature you think I have stolen from you. We just
prevent auto-revert-mode from reverting the dired buffer as long as an
operation on marked files is in progress. Progress is still visible
(SHOW-PROGRESS arg of dired-map-over-marks), i.e., the dired buffer is
periodically redisplayed showing the changes so far because that has
nothing to do with auto-revert-mode.
Bye,
Tassilo
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-20 18:01 ` Tassilo Horn
@ 2025-01-20 18:28 ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-20 19:39 ` Tassilo Horn
0 siblings, 1 reply; 99+ messages in thread
From: Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-01-20 18:28 UTC (permalink / raw)
To: Tassilo Horn; +Cc: Michael Heerdegen, 75626@debbugs.gnu.org, Eli Zaretskii
> >> >> The macro itself should stay general & unassuming.
> >> >
> >> > The plan is to change dired-buffer-stale-p so that it returns nil
> >> > when inhibit-read-only is bound to a non-nil value which is the
> >> > case during the execution of the code generated by
> >> > dired-map-over-marks and might catch other cases, too. The macro
> >> > itself stays as-is.
> >>
> >> The missing part: this change hinders auto-revert-mode from reverting
> >> the dired buffer during an operation on marked files.
> >
> > That shouldn't happen, IMO. Too general,
> > and I doubt it's needed.
>
> This bug contains a recipe showing at least one ocassion where it is
> needed.
It's needed for the _macro_ to do? I don't see
that demonstrated.
An occasion where the macro is used and you want
to prevent XYZ should be handled by the _code
that invokes the macro_, not by the macro itself,
i.e., not by expanding the macro.
> > One might very well want to allow reversion
> > during some particular operation on marked
> > files. Let's not assume otherwise.
>
> Sure, and that's still allowed, e.g., the code given as BODY of
> dired-map-over-marks could explicitly call revert-buffer if it can
> handle the result.
When you say BODY, do you mean the _function_
passed to the macro as its ARG, or the BODY
argument?
In any case, how is an invocation of the macro
supposed to override the denial of reversion?
Can it simply let-bind a variable around the
macro call? I was guessing that, with your
change the macro code itself would override
that, e.g., with its own such binding, making
it impossible to control the behavior from
_around_ the macro call.
> The point is that auto-revert-mode reverts at _unpredictable_ moments
> where chances are high that the dired buffer contents change in a way
> that the processing logic goes wrong, e.g., a marked and not yet
> processed file is now before point and will be skipped, or the other way
> round, an already processed file is now after point and will be
> processed again.
Yes, I made clear that I understand that.
And I explicitly agreed that that's a no-no.
My point was that, until now, it was up to
a _user_ to just _not do that_, i.e., not
to shoot herself in the foot. IIUC, Emacs is
now preventing her from reverting the buffer,
including, but not limited to, via
`auto-revert-mode'.
If so, I'd prefer the original, more general
behavior: leave it up to the _calling_ code to
decide whether to limit the behavior in that
way (or in any other way). If it's important
for the particular use case to prevent doing
XYZ then the _calling code_ can, and should,
prevent doing XYZ. The macro shouldn't try to
guess what should be prevented - even in the
case of buffer reversion, which, I agree, is
usually something to be prevented.
> > An operation on marked files - which really
> > means, for this macro, an operation on marked
> > _lines_, CAN DO ANYTHING. Whatever you might
> > want to do to, or with, the Dired buffer
> > display/listing you can do. That is, you
> > could until now, it sounds like.
>
> I don't see what feature you think I have stolen from you. We just
> prevent auto-revert-mode from reverting the dired buffer as long as an
> operation on marked files is in progress.
Why? Because usually that's a good thing to
prevent? Not good/general enough. Leave it up
to calling code to prevent that. Add a note
about this to the doc string, if you like. But
why have the _macro_ prevent it?
> Progress is still visible
> (SHOW-PROGRESS arg of dired-map-over-marks), i.e., the dired buffer is
> periodically redisplayed showing the changes so far because that has
> nothing to do with auto-revert-mode.
No one questioned visibility of progress.
Dunno why you mention that.
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-20 17:19 ` Tassilo Horn
@ 2025-01-20 19:07 ` Eli Zaretskii
2025-01-20 20:05 ` Tassilo Horn
0 siblings, 1 reply; 99+ messages in thread
From: Eli Zaretskii @ 2025-01-20 19:07 UTC (permalink / raw)
To: Tassilo Horn; +Cc: michael_heerdegen, 75626
> Date: Mon, 20 Jan 2025 18:19:00 +0100
> From: "Tassilo Horn" <tsdh@gnu.org>
> Cc: 75626@debbugs.gnu.org
>
>
>
> Am Mo, 20. Jan 2025, um 18:08, schrieb Eli Zaretskii:
> >> Let's use dired--inhibit-auto-revert instead.
> >
> > And, btw, if we want this to be useful outside of Dired, we need to
> > make this variable public, not internal. That is, call it
> > dired-inhibit-auto-revert.
>
> Sorry, I can't follow. Why should a variable named dired-* be used outside of dired?
Not outside of dired, outside of dired.el. There are two other
dired-*.el files which might want to do that for some reason.
Anyway, that other places could want to use this was not my
suggestion, it was yours, AFAIR.
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-20 17:32 ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-01-20 19:13 ` Eli Zaretskii
2025-01-20 19:20 ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 99+ messages in thread
From: Eli Zaretskii @ 2025-01-20 19:13 UTC (permalink / raw)
To: Drew Adams; +Cc: michael_heerdegen, 75626, tsdh
> From: Drew Adams <drew.adams@oracle.com>
> CC: Michael Heerdegen <michael_heerdegen@web.de>,
> "75626@debbugs.gnu.org"
> <75626@debbugs.gnu.org>,
> Eli Zaretskii <eliz@gnu.org>
> Date: Mon, 20 Jan 2025 17:32:35 +0000
>
> Is that necessary? I can't see why it would be.
It is necessary because the macro must "freeze" the marked file while
it maps over them. Otherwise, the macro doesn't work on a snapshot,
it works on a list that could change under its feet, which is not a
good way of writing programs that must give predictable results.
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-20 17:32 ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-20 18:01 ` Tassilo Horn
@ 2025-01-20 19:15 ` Eli Zaretskii
2025-01-20 19:31 ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 1 reply; 99+ messages in thread
From: Eli Zaretskii @ 2025-01-20 19:15 UTC (permalink / raw)
To: Drew Adams; +Cc: michael_heerdegen, 75626, tsdh
> From: Drew Adams <drew.adams@oracle.com>
> CC: Michael Heerdegen <michael_heerdegen@web.de>,
> "75626@debbugs.gnu.org"
> <75626@debbugs.gnu.org>,
> Eli Zaretskii <eliz@gnu.org>
> Date: Mon, 20 Jan 2025 17:32:37 +0000
>
> An operation on marked files - which really
> means, for this macro, an operation on marked
> _lines_, CAN DO ANYTHING.
Auto-reverting is not something the operation on files does, it is
something that happens behind the operation's back. It affects the
list of files that the operation wants to map over, and could easily
cause the operation to never terminate.
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-20 19:13 ` Eli Zaretskii
@ 2025-01-20 19:20 ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 0 replies; 99+ messages in thread
From: Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-01-20 19:20 UTC (permalink / raw)
To: Eli Zaretskii
Cc: michael_heerdegen@web.de, 75626@debbugs.gnu.org, tsdh@gnu.org
> > Is that necessary? I can't see why it would be.
>
> It is necessary because the macro must "freeze" the marked file while
> it maps over them. Otherwise, the macro doesn't work on a snapshot,
> it works on a list that could change under its feet, which is not a
> good way of writing programs that must give predictable results.
The macro _doesn't_ map over files. It maps
over the marked _lines_. The macro is all
about the displayed Dired buffer (listing(s)).
It need not do anything with or to any of the
files listed on the marked lines.
I do agree that normally, usually, most of
the time a _use_ of the macro will not want
to allow the display to change while it's
processing a particular marked line.
What I don't (yet) agree with (or see) is
the constraint that the macro should, itself,
prevent things while it's iterating over the
marked lines and invoking a function when on
each one, in turn.
I don't understand why we wouldn't, as always
till now, leave any such "prevention", or
other control, up to the code that invokes
the macro.
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-20 19:15 ` Eli Zaretskii
@ 2025-01-20 19:31 ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-20 19:44 ` bug#75626: " Eli Zaretskii
0 siblings, 1 reply; 99+ messages in thread
From: Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-01-20 19:31 UTC (permalink / raw)
To: Eli Zaretskii
Cc: michael_heerdegen@web.de, 75626@debbugs.gnu.org, tsdh@gnu.org
> > An operation on marked files - which really
> > means, for this macro, an operation on marked
> > _lines_, CAN DO ANYTHING.
>
> Auto-reverting is not something the operation on files does, it is
> something that happens behind the operation's back.
Yes (though the macro doesn't necessarily invoke
any operation on files).
And auto-reverting could occur while the macro is
iterating over the marked lines, and while it's
invoking its ARG function with point on a given
line.
And yes, that can be a bother, and it's usually
_not_ what you want or expect. Agreed on all of
that. Is it _always_ not what you want/expect?
> It affects the list of files that the operation
> wants to map over, and could easily cause the
> operation to never terminate.
Yes, I can see that. I'd suggest letting that
happen, by default, and add a note in the doc
telling you how you can prevent that when/where
you _call_ the macro.
That's my only disagreement. I don't see that
fixing the bug requires changing the macro's
behavior in a general way.
OTOH, if you make that change, is there some
way for a user to modify the behavior for a
given macro call, to _allow_ what would now be
prevented in a general way?
If so, that would be OK too. Just how can a
user do that? I haven't followed the patch
etc., but I'm guessing that it's not sufficient
just to turn off `auto-revert-mode', or just
bind some variable, around the macro call.
If there's no way for a user to override the
behavior to be newly imposed then that seems
a shame, to me. Is there no reasonable
alternative that would allow prevention by
default but would let users override that
prevention in a given case?
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-20 18:28 ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-01-20 19:39 ` Tassilo Horn
2025-01-20 22:32 ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 99+ messages in thread
From: Tassilo Horn @ 2025-01-20 19:39 UTC (permalink / raw)
To: Drew Adams; +Cc: Michael Heerdegen, 75626@debbugs.gnu.org, Eli Zaretskii
Drew Adams <drew.adams@oracle.com> writes:
>> > That shouldn't happen, IMO. Too general, and I doubt it's needed.
>>
>> This bug contains a recipe showing at least one ocassion where it is
>> needed.
>
> It's needed for the _macro_ to do? I don't see
> that demonstrated.
>
> An occasion where the macro is used and you want
> to prevent XYZ should be handled by the _code
> that invokes the macro_, not by the macro itself,
> i.e., not by expanding the macro.
That would be possible, too. The difference is just one change to the
macro vs. N changes to different functions like dired-do-compress.
>> > One might very well want to allow reversion
>> > during some particular operation on marked
>> > files. Let's not assume otherwise.
>>
>> Sure, and that's still allowed, e.g., the code given as BODY of
>> dired-map-over-marks could explicitly call revert-buffer if it can
>> handle the result.
>
> When you say BODY, do you mean the _function_
> passed to the macro as its ARG, or the BODY
> argument?
It doesn't get a function, it gets a form like (funcall
#'dired-compress) in the case of dired-do-compress. You could give it
somithing like (progn (funcall #'whatever) (revert-buffer)) when you are
certain that reverting after the operation is safe.
> In any case, how is an invocation of the macro
> supposed to override the denial of reversion?
> Can it simply let-bind a variable around the
> macro call? I was guessing that, with your
> change the macro code itself would override
> that, e.g., with its own such binding, making
> it impossible to control the behavior from
> _around_ the macro call.
That's true.
>> The point is that auto-revert-mode reverts at _unpredictable_ moments
>> where chances are high that the dired buffer contents change in a way
>> that the processing logic goes wrong, e.g., a marked and not yet
>> processed file is now before point and will be skipped, or the other
>> way round, an already processed file is now after point and will be
>> processed again.
>
> Yes, I made clear that I understand that.
> And I explicitly agreed that that's a no-no.
>
> My point was that, until now, it was up to
> a _user_ to just _not do that_, i.e., not
> to shoot herself in the foot. IIUC, Emacs is
> now preventing her from reverting the buffer,
> including, but not limited to, via
> `auto-revert-mode'.
That's not true. The user could not manually revert before because as
Eli explained, Emacs isn't processing key events during the long-running
operation on marked files through dired-map-over-marks. In contrast,
auto-revert-mode reverts from the Emacs main loop.
> If so, I'd prefer the original, more general
> behavior: leave it up to the _calling_ code to
> decide whether to limit the behavior in that
> way (or in any other way). If it's important
> for the particular use case to prevent doing
> XYZ then the _calling code_ can, and should,
> prevent doing XYZ. The macro shouldn't try to
> guess what should be prevented - even in the
> case of buffer reversion, which, I agree, is
> usually something to be prevented.
>>
>> I don't see what feature you think I have stolen from you. We just
>> prevent auto-revert-mode from reverting the dired buffer as long as
>> an operation on marked files is in progress.
>
> Why? Because usually that's a good thing to
> prevent? Not good/general enough. Leave it up
> to calling code to prevent that. Add a note
> about this to the doc string, if you like. But
> why have the _macro_ prevent it?
Because it catches a category of (potential) errors at a central
location. It's not unthinkable that users wrote their own processing
functions which are also vulnerable to misbehave if auto-revert-mode is
activated.
And keep in mind that the changes that make auto-revert-mode revert
don't need to be "our" changes. For example, assume you have a dired
buffer for /tmp, do some operation on marked files, and some other
process creates files in /tmp causing auto-reverts. That will produce
new lines at random locations in your dired buffer which is currently
processed marked line by marked line with code that relies on the
position of point in that buffer. How should processing code handle
that? I'd argue it can't and we should make sure the buffer stays
stable during the operation.
>> Progress is still visible
>> (SHOW-PROGRESS arg of dired-map-over-marks), i.e., the dired buffer is
>> periodically redisplayed showing the changes so far because that has
>> nothing to do with auto-revert-mode.
>
> No one questioned visibility of progress.
> Dunno why you mention that.
I had the impression that this could be the reason for you vehement
disagreement with the change.
Anyway, can you come up with some concrete scenario where inhibiting
auto-revert-mode for a dired marked files operation could do harm or
have any negative effect? That's the thing I don't get.
Bye,
Tassilo
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: Re: bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-20 19:31 ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-01-20 19:44 ` Eli Zaretskii
2025-01-20 22:32 ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 99+ messages in thread
From: Eli Zaretskii @ 2025-01-20 19:44 UTC (permalink / raw)
To: Drew Adams; +Cc: michael_heerdegen, 75626, tsdh
> From: Drew Adams <drew.adams@oracle.com>
> CC: "tsdh@gnu.org" <tsdh@gnu.org>,
> "michael_heerdegen@web.de"
> <michael_heerdegen@web.de>,
> "75626@debbugs.gnu.org" <75626@debbugs.gnu.org>
> Date: Mon, 20 Jan 2025 19:31:34 +0000
>
> > > An operation on marked files - which really
> > > means, for this macro, an operation on marked
> > > _lines_, CAN DO ANYTHING.
> >
> > Auto-reverting is not something the operation on files does, it is
> > something that happens behind the operation's back.
>
> Yes (though the macro doesn't necessarily invoke
> any operation on files).
>
> And auto-reverting could occur while the macro is
> iterating over the marked lines, and while it's
> invoking its ARG function with point on a given
> line.
>
> And yes, that can be a bother, and it's usually
> _not_ what you want or expect. Agreed on all of
> that. Is it _always_ not what you want/expect?
Yes. Because the only way this macro can work predictably and
reliably is if it works on a snapshot of the directory's state. It
cannot allow changed in the files that its body did not cause and does
not know about.
> > It affects the list of files that the operation
> > wants to map over, and could easily cause the
> > operation to never terminate.
>
> Yes, I can see that. I'd suggest letting that
> happen, by default, and add a note in the doc
> telling you how you can prevent that when/where
> you _call_ the macro.
If features like auto-revert are allowed to run during the macro's
operation, there's _nothing_ you can do to prevent these problems.
That's what the discussion of this bug reveals.
> That's my only disagreement. I don't see that
> fixing the bug requires changing the macro's
> behavior in a general way.
Because otherwise the macro itself has a bug that cannot be possibly
fixed in the body.
> OTOH, if you make that change, is there some
> way for a user to modify the behavior for a
> given macro call, to _allow_ what would now be
> prevented in a general way?
No, and neither should there be such a way. That way is a way of
introducing bugs into a program, and we don't write code that produces
buggy behavior.
> If there's no way for a user to override the
> behavior to be newly imposed then that seems
> a shame, to me.
I challenge you to come up with a problem whose solution requires to
allow auto-revert to modify the list of files while the macro runs.
If you can come up with such a problem, we could then discuss this and
see what followup changes might be needed. Otherwise, I see no reason
to continue this discussion, since we are talking about problems that
don't exist in practice, AFAIK.
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-20 19:07 ` Eli Zaretskii
@ 2025-01-20 20:05 ` Tassilo Horn
2025-01-21 0:36 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-21 12:34 ` Eli Zaretskii
0 siblings, 2 replies; 99+ messages in thread
From: Tassilo Horn @ 2025-01-20 20:05 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: michael_heerdegen, 75626
Eli Zaretskii <eliz@gnu.org> writes:
>> > And, btw, if we want this to be useful outside of Dired, we need to
>> > make this variable public, not internal. That is, call it
>> > dired-inhibit-auto-revert.
>>
>> Sorry, I can't follow. Why should a variable named dired-* be used
>> outside of dired?
>
> Not outside of dired, outside of dired.el. There are two other
> dired-*.el files which might want to do that for some reason.
Would you get a warning when dired--inhibit-auto-revert defined in
dired.el was used in dired-aux.el or what is the problem? I've though
"--" variables are only private by convention, and usually not private
to a file but to a package.
> Anyway, that other places could want to use this was not my
> suggestion, it was yours, AFAIR.
No, Michael's.
Anyway, after thinking a bit more about it: we could also have an even
more general inhibit-auto-revert in autorevert.el and bind that in the
expansion of dired-map-over-marks. Then auto-revert-handler would test
inhibit-auto-revert even before consulting the buffer-stale-function.
WDYT?
Bye,
Tassilo
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-20 19:39 ` Tassilo Horn
@ 2025-01-20 22:32 ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 0 replies; 99+ messages in thread
From: Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-01-20 22:32 UTC (permalink / raw)
To: Tassilo Horn; +Cc: Michael Heerdegen, 75626@debbugs.gnu.org, Eli Zaretskii
> >> > That shouldn't happen, IMO. Too general, and I doubt it's needed.
> >>
> >> This bug contains a recipe showing at least one ocassion where it is
> >> needed.
> >
> > It's needed for the _macro_ to do? I don't see
> > that demonstrated.
> >
> > An occasion where the macro is used and you want
> > to prevent XYZ should be handled by the _code
> > that invokes the macro_, not by the macro itself,
> > i.e., not by expanding the macro.
>
> That would be possible, too. The difference is just one change to the
> macro vs. N changes to different functions like dired-do-compress.
Requiring a user to change the macro is not what
I'd call "the code that invokes the macro"
preventing XYZ. You seem to be saying that a
user can always redefine the macro. That excuse
could be offered for _any_ change to the Emacs
code: don't like it, just change the code.
> >> > One might very well want to allow reversion
> >> > during some particular operation on marked
> >> > files. Let's not assume otherwise.
> >>
> >> Sure, and that's still allowed, e.g., the code given as BODY of
> >> dired-map-over-marks could explicitly call revert-buffer if it can
> >> handle the result.
> >
> > When you say BODY, do you mean the _function_
> > passed to the macro as its ARG, or the BODY
> > argument?
>
> It doesn't get a function, it gets a form like (funcall
> #'dired-compress) in the case of dired-do-compress. You could give it
> somithing like (progn (funcall #'whatever) (revert-buffer)) when you are
> certain that reverting after the operation is safe.
No. It gets two (possibly 3 or 4) arguments:
BODY, ARG, and possibly SHOW-PROGRESS and
DISTINGUISH-ONE-MARKED. `C-h f'-it, or check
its definition in the code.
> > In any case, how is an invocation of the macro
> > supposed to override the denial of reversion?
> > Can it simply let-bind a variable around the
> > macro call? I was guessing that, with your
> > change the macro code itself would override
> > that, e.g., with its own such binding, making
> > it impossible to control the behavior from
> > _around_ the macro call.
>
> That's true.
So you admit that a code invoking the macro can't
override the behavior you're now hard-coding in it.
> >> The point is that auto-revert-mode reverts at _unpredictable_ moments
> >> where chances are high that the dired buffer contents change in a way
> >> that the processing logic goes wrong, e.g., a marked and not yet
> >> processed file is now before point and will be skipped, or the other
> >> way round, an already processed file is now after point and will be
> >> processed again.
> >
> > Yes, I made clear that I understand that.
> > And I explicitly agreed that that's a no-no.
> >
> > My point was that, until now, it was up to
> > a _user_ to just _not do that_, i.e., not
> > to shoot herself in the foot. IIUC, Emacs is
> > now preventing her from reverting the buffer,
> > including, but not limited to, via
> > `auto-revert-mode'.
>
> That's not true. The user could not manually revert before because as
> Eli explained, Emacs isn't processing key events during the long-running
> operation on marked files through dired-map-over-marks.
We're (I'm) talking about user code, not user
altering the behavior interactively. It's
not about "manually revert"ing. It's about
letting `auto-revert-mode' revert during
`dired-map-over-marks'.
And to _disallow_ reversion (auto or other)
during `d-m-o-m' user code can, now, just
bind `revert-buffer-function' to `ignore',
around the call to `dired-map-over-marks'.
If you change `dired-map-over-marks' then
user code can't have any such effect - you're
hard-coding prevention of reversion during
`d-m-o-m'.
> > If so, I'd prefer the original, more general
> > behavior: leave it up to the _calling_ code to
> > decide whether to limit the behavior in that
> > way (or in any other way). If it's important
> > for the particular use case to prevent doing
> > XYZ then the _calling code_ can, and should,
> > prevent doing XYZ. The macro shouldn't try to
> > guess what should be prevented - even in the
> > case of buffer reversion, which, I agree, is
> > usually something to be prevented.
> >>
> >> I don't see what feature you think I have stolen from you. We just
> >> prevent auto-revert-mode from reverting the dired buffer as long as
> >> an operation on marked files is in progress.
> >
> > Why? Because usually that's a good thing to
> > prevent? Not good/general enough. Leave it up
> > to calling code to prevent that. Add a note
> > about this to the doc string, if you like. But
> > why have the _macro_ prevent it?
>
> Because it catches a category of (potential) errors at a central
> location. It's not unthinkable that users wrote their own processing
> functions which are also vulnerable to misbehave if auto-revert-mode is
> activated.
That might sound reasonable, IF you also provided
a way for user code to override that prohibition
of reverting during `d-m-o-m'.
> And keep in mind that the changes that make auto-revert-mode revert
> don't need to be "our" changes. For example, assume you have a dired
> buffer for /tmp, do some operation on marked files, and some other
> process creates files in /tmp causing auto-reverts. That will produce
> new lines at random locations in your dired buffer which is currently
> processed marked line by marked line with code that relies on the
> position of point in that buffer. How should processing code handle
> that? I'd argue it can't and we should make sure the buffer stays
> stable during the operation.
That's why I agreed that usually users will want
to prohibit reversion during `d-m-o-m'. That's
not the same thing as hard-coding that prohibition
and not giving user code an easy way to override
it.
> >> Progress is still visible
> >> (SHOW-PROGRESS arg of dired-map-over-marks), i.e., the dired buffer is
> >> periodically redisplayed showing the changes so far because that has
> >> nothing to do with auto-revert-mode.
> >
> > No one questioned visibility of progress.
> > Dunno why you mention that.
>
> I had the impression that this could be the reason for you vehement
> disagreement with the change.
No. And I don't have a vehement disagreement.
I'm not convinced that the solution being
implemented is required. Seems like overkill,
to me. At least provide a variable that the
`d-m-o-m' will respect whose value you can
change to not prohibit <whatever>, including
reversion. That costs nothing, and you can
even tell users why they generally won't want
to change the variable value.
> Anyway, can you come up with some concrete scenario where inhibiting
> auto-revert-mode for a dired marked files operation could do harm or
> have any negative effect? That's the thing I don't get.
The negative effect is in removing the possibility
of allowing reversion during `d-m-o-m'. What's
the argument for hard-coding disallowing it, not
letting code allow it, conditionally or otherwise?
I haven't seen an argument for that. I've seen
only an argument (of which I'm convinced, and have
said so several times) that most of the time it's
better to disallow it. Disallowing it always is
too rigid - not the same as disallowing it by
default but allowing user code to do whatever it
wants.
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: Re: bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-20 19:44 ` bug#75626: " Eli Zaretskii
@ 2025-01-20 22:32 ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-21 7:26 ` Tassilo Horn
0 siblings, 1 reply; 99+ messages in thread
From: Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-01-20 22:32 UTC (permalink / raw)
To: Eli Zaretskii
Cc: michael_heerdegen@web.de, 75626@debbugs.gnu.org, tsdh@gnu.org
> > > > An operation on marked files - which really
> > > > means, for this macro, an operation on marked
> > > > _lines_, CAN DO ANYTHING.
> > >
> > > Auto-reverting is not something the operation on files does, it is
> > > something that happens behind the operation's back.
> >
> > Yes (though the macro doesn't necessarily invoke
> > any operation on files).
> >
> > And auto-reverting could occur while the macro is
> > iterating over the marked lines, and while it's
> > invoking its ARG function with point on a given
> > line.
> >
> > And yes, that can be a bother, and it's usually
> > _not_ what you want or expect. Agreed on all of
> > that. Is it _always_ not what you want/expect?
>
> Yes. Because the only way this macro can work predictably and
> reliably is if it works on a snapshot of the directory's state. It
> cannot allow changed in the files that its body did not cause and does
> not know about.
Again, it's not about changes in the files. The
macro carries out an action on the marked _lines_.
Not the same thing as acting on the files marked
on those lines.
Sorry, but I'm not convinced that you can make
such an "always" statement, logically. You can
make a "usually" statement, to which I've agreed.
> > > It affects the list of files that the operation
> > > wants to map over, and could easily cause the
> > > operation to never terminate.
> >
> > Yes, I can see that. I'd suggest letting that
> > happen, by default, and add a note in the doc
> > telling you how you can prevent that when/where
> > you _call_ the macro.
>
> If features like auto-revert are allowed to run during the macro's
> operation, there's _nothing_ you can do to prevent these problems.
> That's what the discussion of this bug reveals.
You can bind `revert-buffer-function' to `ignore'
around the call to `dired-map-over-marks'.
Yes, that can't prevent some other code that
somehow gets run during `d-m-o-m' from, itself,
binding `revert-function' to `dired-revert' (or
to `foobar', which sparks nuclear war), but I
don't think that needs to be worried about.
It's not what this bug report points to, I'm
guessing. Isn't the bug about preventing
auto-reversion (or other-provoked reversion)
during `dired-map-over-marks'?
Have you tried that: in `dired-do-compress' or
whatever other place you feel there's a problem,
just bind `revert-buffer-function' to `ignore'
around the call to `d-m-o-m'. Doesn't that fix
the reported problem? Or am I just being naïve?
> > That's my only disagreement. I don't see that
> > fixing the bug requires changing the macro's
> > behavior in a general way.
>
> Because otherwise the macro itself has a bug that cannot be possibly
> fixed in the body.
Not in the body, no. But outside the `d-m-o-m'
call: wrap it with a let-binding - a common
idiom to affect the behavior of code within the
let scope. (Likewise for `flet' and `labels',
and even advice, if you really need to get into
the nitty gritty of the function.)
> > OTOH, if you make that change, is there some
> > way for a user to modify the behavior for a
> > given macro call, to _allow_ what would now be
> > prevented in a general way?
>
> No, and neither should there be such a way.
You haven't given a reason why not. You've only
give a reason why it's _usually_ bad to allow
reversion during `dired-map-over-marks'.
> That way is a way of introducing bugs into a
> program, and we don't write code that produces
> buggy behavior.
Sorry, but that's hyperbole. As Eli Z. is wont
to say, Elisp provides lots of rope for coders
to hang themselves with. Intentionally. To
give coders more flexibility.
> > If there's no way for a user to override the
> > behavior to be newly imposed then that seems
> > a shame, to me.
>
> I challenge you to come up with a problem whose solution requires to
> allow auto-revert to modify the list of files while the macro runs.
I challenge you to prove it's necessary to
_always_ prevent reversion. Not just argue that
it's usually helpful to prevent it, to which I
agree wholeheartedly.
> If you can come up with such a problem, we could then discuss this and
> see what followup changes might be needed. Otherwise, I see no reason
> to continue this discussion, since we are talking about problems that
> don't exist in practice, AFAIK.
Today the possibility exists. Tomorrow it
won't, even should someone want to take
advantage of it for <whatever> reason.
(OK, they will of course still be able to
redefine `d-m-o-m'. That's not the kind of
control by code users have today, which is
what I have in mind.)
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-20 20:05 ` Tassilo Horn
@ 2025-01-21 0:36 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-21 12:38 ` Eli Zaretskii
2025-01-21 12:34 ` Eli Zaretskii
1 sibling, 1 reply; 99+ messages in thread
From: Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-01-21 0:36 UTC (permalink / raw)
To: Tassilo Horn; +Cc: 75626, Eli Zaretskii
Tassilo Horn <tsdh@gnu.org> writes:
> > Anyway, that other places could want to use this was not my
> > suggestion, it was yours, AFAIR.
>
> No, Michael's.
Yes, I wanted to bring that up. Though I don't understand the naming
convention thing, too.
But I also have a question: can it happen that we prevent an
auto-revert, and it is then not happening delayed, but completely
canceled? Or will auto-revert-mode always try again later even without
a new notification (or however that works)?
Michael.
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: Re: bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-20 22:32 ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-01-21 7:26 ` Tassilo Horn
0 siblings, 0 replies; 99+ messages in thread
From: Tassilo Horn @ 2025-01-21 7:26 UTC (permalink / raw)
To: Drew Adams; +Cc: michael_heerdegen@web.de, 75626@debbugs.gnu.org, Eli Zaretskii
Drew Adams <drew.adams@oracle.com> writes:
>> Yes. Because the only way this macro can work predictably and
>> reliably is if it works on a snapshot of the directory's state. It
>> cannot allow changed in the files that its body did not cause and
>> does not know about.
>
> Again, it's not about changes in the files. The
> macro carries out an action on the marked _lines_.
> Not the same thing as acting on the files marked
> on those lines.
But the marked _lines_ can also jump around/change their order due to
auto-revert. And the changes causing it might be made by other
processes, not our dired operation. Please give one concrete example
where that would be desired? It's like arguing that a inhibiting a
periodic shuffle-lines during keyboard macro execution would constrain
the generality of keyboard macros.
Bye,
Tassilo
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-20 20:05 ` Tassilo Horn
2025-01-21 0:36 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-01-21 12:34 ` Eli Zaretskii
1 sibling, 0 replies; 99+ messages in thread
From: Eli Zaretskii @ 2025-01-21 12:34 UTC (permalink / raw)
To: Tassilo Horn, Michael Albinus; +Cc: michael_heerdegen, 75626
> From: Tassilo Horn <tsdh@gnu.org>
> Cc: michael_heerdegen@web.de, 75626@debbugs.gnu.org
> Date: Mon, 20 Jan 2025 21:05:20 +0100
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> > And, btw, if we want this to be useful outside of Dired, we need to
> >> > make this variable public, not internal. That is, call it
> >> > dired-inhibit-auto-revert.
> >>
> >> Sorry, I can't follow. Why should a variable named dired-* be used
> >> outside of dired?
> >
> > Not outside of dired, outside of dired.el. There are two other
> > dired-*.el files which might want to do that for some reason.
>
> Would you get a warning when dired--inhibit-auto-revert defined in
> dired.el was used in dired-aux.el or what is the problem? I've though
> "--" variables are only private by convention, and usually not private
> to a file but to a package.
>
> > Anyway, that other places could want to use this was not my
> > suggestion, it was yours, AFAIR.
>
> No, Michael's.
>
> Anyway, after thinking a bit more about it: we could also have an even
> more general inhibit-auto-revert in autorevert.el and bind that in the
> expansion of dired-map-over-marks. Then auto-revert-handler would test
> inhibit-auto-revert even before consulting the buffer-stale-function.
Yes, I think this is even better, thanks.
But let's first wait for Michael Albinus (CC'ed) to chime in, in case
he has comments or objections.
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-21 0:36 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-01-21 12:38 ` Eli Zaretskii
2025-01-21 14:13 ` Eli Zaretskii
0 siblings, 1 reply; 99+ messages in thread
From: Eli Zaretskii @ 2025-01-21 12:38 UTC (permalink / raw)
To: Michael Heerdegen, Michael Albinus; +Cc: 75626, tsdh
> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: Eli Zaretskii <eliz@gnu.org>, 75626@debbugs.gnu.org
> Date: Tue, 21 Jan 2025 01:36:37 +0100
>
> Tassilo Horn <tsdh@gnu.org> writes:
>
> > > Anyway, that other places could want to use this was not my
> > > suggestion, it was yours, AFAIR.
> >
> > No, Michael's.
>
> Yes, I wanted to bring that up. Though I don't understand the naming
> convention thing, too.
>
> But I also have a question: can it happen that we prevent an
> auto-revert, and it is then not happening delayed, but completely
> canceled? Or will auto-revert-mode always try again later even without
> a new notification (or however that works)?
You mean, if this buffer's file or directory never changes again after
this one time? Let's ask Michael Albinus (CC'ed).
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-21 12:38 ` Eli Zaretskii
@ 2025-01-21 14:13 ` Eli Zaretskii
2025-01-21 14:36 ` Tassilo Horn
0 siblings, 1 reply; 99+ messages in thread
From: Eli Zaretskii @ 2025-01-21 14:13 UTC (permalink / raw)
To: michael_heerdegen, michael.albinus; +Cc: 75626, tsdh
> Cc: 75626@debbugs.gnu.org, tsdh@gnu.org
> Date: Tue, 21 Jan 2025 14:38:16 +0200
> From: Eli Zaretskii <eliz@gnu.org>
>
> > From: Michael Heerdegen <michael_heerdegen@web.de>
> > Cc: Eli Zaretskii <eliz@gnu.org>, 75626@debbugs.gnu.org
> > Date: Tue, 21 Jan 2025 01:36:37 +0100
> >
> > Tassilo Horn <tsdh@gnu.org> writes:
> >
> > > > Anyway, that other places could want to use this was not my
> > > > suggestion, it was yours, AFAIR.
> > >
> > > No, Michael's.
> >
> > Yes, I wanted to bring that up. Though I don't understand the naming
> > convention thing, too.
> >
> > But I also have a question: can it happen that we prevent an
> > auto-revert, and it is then not happening delayed, but completely
> > canceled? Or will auto-revert-mode always try again later even without
> > a new notification (or however that works)?
>
> You mean, if this buffer's file or directory never changes again after
> this one time? Let's ask Michael Albinus (CC'ed).
Michael informed me off-list that he will be able to respond only
later. So we could either make this change now and wait for his
comments, or do it the other way around. I don't think it matters
much which way we do it.
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-21 14:13 ` Eli Zaretskii
@ 2025-01-21 14:36 ` Tassilo Horn
2025-01-21 15:13 ` Rudolf Schlatte
2025-01-21 20:18 ` Tassilo Horn
0 siblings, 2 replies; 99+ messages in thread
From: Tassilo Horn @ 2025-01-21 14:36 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: michael_heerdegen, 75626, michael.albinus
Eli Zaretskii <eliz@gnu.org> writes:
>> > But I also have a question: can it happen that we prevent an
>> > auto-revert, and it is then not happening delayed, but completely
>> > canceled? Or will auto-revert-mode always try again later even
>> > without a new notification (or however that works)?
>>
>> You mean, if this buffer's file or directory never changes again
>> after this one time? Let's ask Michael Albinus (CC'ed).
>
> Michael informed me off-list that he will be able to respond only
> later. So we could either make this change now and wait for his
> comments, or do it the other way around. I don't think it matters
> much which way we do it.
Yeah, missing an auto-revert possibility could happen for ages, for
example if wdired-mode was active, so if it's a problem, it's at least
no new problem.
I'll make the change to the new more general inhibit-auto-revert when
time permits.
Bye,
Tassilo
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-21 14:36 ` Tassilo Horn
@ 2025-01-21 15:13 ` Rudolf Schlatte
2025-01-21 20:18 ` Tassilo Horn
1 sibling, 0 replies; 99+ messages in thread
From: Rudolf Schlatte @ 2025-01-21 15:13 UTC (permalink / raw)
To: 75626
Tassilo Horn <tsdh@gnu.org> writes:
> I'll make the change to the new more general inhibit-auto-revert when
> time permits.
How about (with-deferred-auto-revert BODY), and apply all pending
auto-reverts after BODY finished?
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-21 14:36 ` Tassilo Horn
2025-01-21 15:13 ` Rudolf Schlatte
@ 2025-01-21 20:18 ` Tassilo Horn
2025-01-21 20:26 ` Ship Mints
2025-01-22 0:21 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 2 replies; 99+ messages in thread
From: Tassilo Horn @ 2025-01-21 20:18 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: michael_heerdegen, 75626, michael.albinus
Tassilo Horn <tsdh@gnu.org> writes:
> I'll make the change to the new more general inhibit-auto-revert when
> time permits.
I have to declare emacs programming bankruptcy. The current version
with dired--inhibit-auto-revert works fine. Now I wanted to change that
into a more general inhibit-auto-revert. Here's the patch (with -b to
make it easier to grasp):
--8<---------------cut here---------------start------------->8---
diff --git a/lisp/autorevert.el b/lisp/autorevert.el
index 1dcfe8e911f..0cd0623c59b 100644
--- a/lisp/autorevert.el
+++ b/lisp/autorevert.el
@@ -778,6 +778,11 @@ auto-revert-active-p
auto-revert-tail-mode
auto-revert--global-mode))
+(defvar-local inhibit-auto-revert nil
+ "A non-nil value prevents `auto-revert-mode' from reverting the buffer.
+Should be used in let-bindings to temporarily disable auto-reverts in a
+buffer.")
+
(defun auto-revert-handler ()
"Revert current buffer, if appropriate.
This is an internal function used by Auto-Revert Mode."
@@ -787,6 +792,8 @@ auto-revert-handler
;; the values.
(remote-file-name-inhibit-cache t)
(revert
+ (and
+ (not inhibit-auto-revert)
(if buffer-file-name
(and (or auto-revert-remote-files
(not (file-remote-p buffer-file-name)))
@@ -805,7 +812,7 @@ auto-revert-handler
global-auto-revert-non-file-buffers)
(funcall (or buffer-stale-function
#'buffer-stale--default-function)
- t))))
+ t)))))
eob eoblist)
(setq auto-revert-notify-modified-p nil
auto-revert--last-time (current-time))
diff --git a/lisp/dired.el b/lisp/dired.el
index d2071d80bf3..7c9d7310efb 100644
--- a/lisp/dired.el
+++ b/lisp/dired.el
@@ -944,9 +944,6 @@ dired-mark-if
""))))
(and (> count 0) count)))
-(defvar-local dired--inhibit-auto-revert nil
- "A non-nil value prevents `auto-revert-mode' from reverting the buffer.")
-
(defmacro dired-map-over-marks (body arg &optional show-progress
distinguish-one-marked)
"Eval BODY with point on each marked line. Return a list of BODY's results.
@@ -983,8 +980,8 @@ dired-map-over-marks
;;endless loop.
;;This warning should not apply any longer, sk 2-Sep-1991 14:10.
`(prog1
- (let ((dired--inhibit-auto-revert t)
- (inhibit-read-only t)
+ (let ((inhibit-read-only t)
+ (inhibit-auto-revert t)
case-fold-search found results)
(if (and ,arg (not (eq ,arg 'marked)))
(if (integerp ,arg)
@@ -1294,12 +1291,6 @@ dired-buffer-stale-p
;; Do not auto-revert when the dired buffer can be currently
;; written by the user as in `wdired-mode'.
buffer-read-only
- ;; When a dired operation using dired-map-over-marks is in
- ;; progress, dired--inhibit-auto-revert is bound to some
- ;; non-nil value and we must not auto-revert because that could
- ;; change the order of files leading to skipping or
- ;; double-processing (see bug#75626).
- (not dired--inhibit-auto-revert)
(dired-directory-changed-p dirname))))
(defcustom dired-auto-revert-buffer nil
@@ -4089,13 +4080,12 @@ dired-internal-do-deletions
(while l
(goto-char (marker-position (cdr (car l))))
(dired-move-to-filename)
- (let ((inhibit-read-only t))
+ (let ((inhibit-read-only t)
+ ;; Temporarily prevent auto-revert while deleting
+ ;; entry in the dired buffer (bug#71264).
+ (inhibit-auto-revert t))
(condition-case err
- (let ((fn (car (car l)))
- ;; Temporarily prevent auto-revert while
- ;; deleting entry in the dired buffer
- ;; (bug#71264).
- (auto-revert-mode nil))
+ (let ((fn (car (car l))))
(dired-delete-file fn dired-recursive-deletes trash)
;; if we get here, removing worked
(setq succ (1+ succ))
--8<---------------cut here---------------end--------------->8---
That last hunk in dired-internal-do-deletions is due to a wrong fix for
the bug#71264. When auto-revert-mode itself is bound to nil when
auto-revert kicks in, the buffer will be removed from
auto-revert-buffer-list causing auto-revert to be disabled forever in
that buffer. (At least that's my reading of the code...)
Anyway, the above solution with the new inhibit-auto-revert does not
work. auto-revert-buffers is called from a timer and eventually
auto-revert-handler is called for my dired buffer where the compression
of 1000 is still ongoing but inhibit-auto-revert is nil there and
revert-buffer is called causing the issue of this bug again.
I can't understand why it doesn't see the non-nil inhibit-auto-revert
binding in the expansion of dired-map-over-marks. Where is the
difference to the current working solution with
dired--inhibit-auto-revert? It's bound the same way and accessed from
auto-revert-handler via the funcall to the dired buffer's
buffer-stale-function, i.e., dired-buffer-stale-p.
Bye,
Tassilo
^ permalink raw reply related [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-21 20:18 ` Tassilo Horn
@ 2025-01-21 20:26 ` Ship Mints
2025-01-22 7:31 ` Tassilo Horn
2025-01-22 0:21 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 1 reply; 99+ messages in thread
From: Ship Mints @ 2025-01-21 20:26 UTC (permalink / raw)
To: Tassilo Horn; +Cc: michael_heerdegen, 75626, Eli Zaretskii, michael.albinus
[-- Attachment #1: Type: text/plain, Size: 6074 bytes --]
If mode changes take place during processing, you may need to "brand"
inhibit-auto-revert
(put 'inhibit-auto-revert 'permanent-local t)
as mode changes clear impermanent locals.
On Tue, Jan 21, 2025 at 3:19 PM Tassilo Horn <tsdh@gnu.org> wrote:
> Tassilo Horn <tsdh@gnu.org> writes:
>
> > I'll make the change to the new more general inhibit-auto-revert when
> > time permits.
>
> I have to declare emacs programming bankruptcy. The current version
> with dired--inhibit-auto-revert works fine. Now I wanted to change that
> into a more general inhibit-auto-revert. Here's the patch (with -b to
> make it easier to grasp):
>
> --8<---------------cut here---------------start------------->8---
> diff --git a/lisp/autorevert.el b/lisp/autorevert.el
> index 1dcfe8e911f..0cd0623c59b 100644
> --- a/lisp/autorevert.el
> +++ b/lisp/autorevert.el
> @@ -778,6 +778,11 @@ auto-revert-active-p
> auto-revert-tail-mode
> auto-revert--global-mode))
>
> +(defvar-local inhibit-auto-revert nil
> + "A non-nil value prevents `auto-revert-mode' from reverting the buffer.
> +Should be used in let-bindings to temporarily disable auto-reverts in a
> +buffer.")
> +
> (defun auto-revert-handler ()
> "Revert current buffer, if appropriate.
> This is an internal function used by Auto-Revert Mode."
> @@ -787,6 +792,8 @@ auto-revert-handler
> ;; the values.
> (remote-file-name-inhibit-cache t)
> (revert
> + (and
> + (not inhibit-auto-revert)
> (if buffer-file-name
> (and (or auto-revert-remote-files
> (not (file-remote-p buffer-file-name)))
> @@ -805,7 +812,7 @@ auto-revert-handler
> global-auto-revert-non-file-buffers)
> (funcall (or buffer-stale-function
> #'buffer-stale--default-function)
> - t))))
> + t)))))
> eob eoblist)
> (setq auto-revert-notify-modified-p nil
> auto-revert--last-time (current-time))
> diff --git a/lisp/dired.el b/lisp/dired.el
> index d2071d80bf3..7c9d7310efb 100644
> --- a/lisp/dired.el
> +++ b/lisp/dired.el
> @@ -944,9 +944,6 @@ dired-mark-if
> ""))))
> (and (> count 0) count)))
>
> -(defvar-local dired--inhibit-auto-revert nil
> - "A non-nil value prevents `auto-revert-mode' from reverting the
> buffer.")
> -
> (defmacro dired-map-over-marks (body arg &optional show-progress
> distinguish-one-marked)
> "Eval BODY with point on each marked line. Return a list of BODY's
> results.
> @@ -983,8 +980,8 @@ dired-map-over-marks
> ;;endless loop.
> ;;This warning should not apply any longer, sk 2-Sep-1991 14:10.
> `(prog1
> - (let ((dired--inhibit-auto-revert t)
> - (inhibit-read-only t)
> + (let ((inhibit-read-only t)
> + (inhibit-auto-revert t)
> case-fold-search found results)
> (if (and ,arg (not (eq ,arg 'marked)))
> (if (integerp ,arg)
> @@ -1294,12 +1291,6 @@ dired-buffer-stale-p
> ;; Do not auto-revert when the dired buffer can be currently
> ;; written by the user as in `wdired-mode'.
> buffer-read-only
> - ;; When a dired operation using dired-map-over-marks is in
> - ;; progress, dired--inhibit-auto-revert is bound to some
> - ;; non-nil value and we must not auto-revert because that could
> - ;; change the order of files leading to skipping or
> - ;; double-processing (see bug#75626).
> - (not dired--inhibit-auto-revert)
> (dired-directory-changed-p dirname))))
>
> (defcustom dired-auto-revert-buffer nil
> @@ -4089,13 +4080,12 @@ dired-internal-do-deletions
> (while l
> (goto-char (marker-position (cdr (car l))))
> (dired-move-to-filename)
> - (let ((inhibit-read-only t))
> + (let ((inhibit-read-only t)
> + ;; Temporarily prevent auto-revert while deleting
> + ;; entry in the dired buffer (bug#71264).
> + (inhibit-auto-revert t))
> (condition-case err
> - (let ((fn (car (car l)))
> - ;; Temporarily prevent auto-revert while
> - ;; deleting entry in the dired buffer
> - ;; (bug#71264).
> - (auto-revert-mode nil))
> + (let ((fn (car (car l))))
> (dired-delete-file fn dired-recursive-deletes trash)
> ;; if we get here, removing worked
> (setq succ (1+ succ))
> --8<---------------cut here---------------end--------------->8---
>
> That last hunk in dired-internal-do-deletions is due to a wrong fix for
> the bug#71264. When auto-revert-mode itself is bound to nil when
> auto-revert kicks in, the buffer will be removed from
> auto-revert-buffer-list causing auto-revert to be disabled forever in
> that buffer. (At least that's my reading of the code...)
>
> Anyway, the above solution with the new inhibit-auto-revert does not
> work. auto-revert-buffers is called from a timer and eventually
> auto-revert-handler is called for my dired buffer where the compression
> of 1000 is still ongoing but inhibit-auto-revert is nil there and
> revert-buffer is called causing the issue of this bug again.
>
> I can't understand why it doesn't see the non-nil inhibit-auto-revert
> binding in the expansion of dired-map-over-marks. Where is the
> difference to the current working solution with
> dired--inhibit-auto-revert? It's bound the same way and accessed from
> auto-revert-handler via the funcall to the dired buffer's
> buffer-stale-function, i.e., dired-buffer-stale-p.
>
> Bye,
> Tassilo
>
>
>
>
[-- Attachment #2: Type: text/html, Size: 7653 bytes --]
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-21 20:18 ` Tassilo Horn
2025-01-21 20:26 ` Ship Mints
@ 2025-01-22 0:21 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-22 8:05 ` Tassilo Horn
1 sibling, 1 reply; 99+ messages in thread
From: Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-01-22 0:21 UTC (permalink / raw)
To: Tassilo Horn; +Cc: 75626, Eli Zaretskii, michael.albinus
Tassilo Horn <tsdh@gnu.org> writes:
> I have to declare emacs programming bankruptcy. The current version
> with dired--inhibit-auto-revert works fine. Now I wanted to change that
> into a more general inhibit-auto-revert. Here's the patch (with -b to
> make it easier to grasp):
Unfortunately it doesn't apply here.
> That last hunk in dired-internal-do-deletions is due to a wrong fix for
> the bug#71264. When auto-revert-mode itself is bound to nil when
> auto-revert kicks in, the buffer will be removed from
> auto-revert-buffer-list causing auto-revert to be disabled forever in
> that buffer. (At least that's my reading of the code...)
I think your reading is correct.
> Anyway, the above solution with the new inhibit-auto-revert does not
> work. auto-revert-buffers is called from a timer and eventually
> auto-revert-handler is called for my dired buffer where the compression
> of 1000 is still ongoing but inhibit-auto-revert is nil there and
> revert-buffer is called causing the issue of this bug again.
>
> I can't understand why it doesn't see the non-nil inhibit-auto-revert
> binding in the expansion of dired-map-over-marks. Where is the
> difference to the current working solution with
> dired--inhibit-auto-revert? It's bound the same way and accessed from
> auto-revert-handler via the funcall to the dired buffer's
> buffer-stale-function, i.e., dired-buffer-stale-p.
I hope it's not related to the auto-revert-mode -> nil binding?
Anyway, as Ship Mints already mentioned, you never created a buffer
local binding. A `let' binds the visible binding which is in your case
the global one - since there was no local variable binding yet.
So you bind the global variable - which is not what we want but that
binding should be visible nonetheless. I'm not sure why it does not
work as expected.
In some situations it can help to use a variable watcher to log
variable binding changes:
(info "(elisp) Watching Variables")
Michael.
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-21 20:26 ` Ship Mints
@ 2025-01-22 7:31 ` Tassilo Horn
0 siblings, 0 replies; 99+ messages in thread
From: Tassilo Horn @ 2025-01-22 7:31 UTC (permalink / raw)
To: Ship Mints; +Cc: michael_heerdegen, 75626, Eli Zaretskii, michael.albinus
Ship Mints <shipmints@gmail.com> writes:
> If mode changes take place during processing, you may need to "brand"
> inhibit-auto-revert
>
> (put 'inhibit-auto-revert 'permanent-local t)
>
> as mode changes clear impermanent locals.
No, that should not be needed. The mode stays dired-mode all the time.
(Not sure if it would be a good idea anyway...)
Bye,
Tassilo
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-22 0:21 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-01-22 8:05 ` Tassilo Horn
2025-01-23 3:25 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 99+ messages in thread
From: Tassilo Horn @ 2025-01-22 8:05 UTC (permalink / raw)
To: Michael Heerdegen; +Cc: 75626, Eli Zaretskii, michael.albinus
[-- Attachment #1: Type: text/plain, Size: 4772 bytes --]
Michael Heerdegen <michael_heerdegen@web.de> writes:
> Tassilo Horn <tsdh@gnu.org> writes:
>
>> I have to declare emacs programming bankruptcy. The current version
>> with dired--inhibit-auto-revert works fine. Now I wanted to change
>> that into a more general inhibit-auto-revert. Here's the patch (with
>> -b to make it easier to grasp):
>
> Unfortunately it doesn't apply here.
Yeah, because of the "git diff -b" flag omitting whitespace changes.
>> That last hunk in dired-internal-do-deletions is due to a wrong fix
>> for the bug#71264. When auto-revert-mode itself is bound to nil when
>> auto-revert kicks in, the buffer will be removed from
>> auto-revert-buffer-list causing auto-revert to be disabled forever in
>> that buffer. (At least that's my reading of the code...)
>
> I think your reading is correct.
Thanks for validating.
>> Anyway, the above solution with the new inhibit-auto-revert does not
>> work. auto-revert-buffers is called from a timer and eventually
>> auto-revert-handler is called for my dired buffer where the
>> compression of 1000 is still ongoing but inhibit-auto-revert is nil
>> there and revert-buffer is called causing the issue of this bug
>> again.
>>
>> I can't understand why it doesn't see the non-nil inhibit-auto-revert
>> binding in the expansion of dired-map-over-marks. Where is the
>> difference to the current working solution with
>> dired--inhibit-auto-revert? It's bound the same way and accessed
>> from auto-revert-handler via the funcall to the dired buffer's
>> buffer-stale-function, i.e., dired-buffer-stale-p.
>
> I hope it's not related to the auto-revert-mode -> nil binding?
Nope, that's what I reverted first to check if that was the culprit.
> Anyway, as Ship Mints already mentioned, you never created a buffer
> local binding. A `let' binds the visible binding which is in your
> case the global one - since there was no local variable binding yet.
Ah, indeed. So now I (setq inhibit-auto-revert nil) in dired-mode to
create a local variable in the buffer.
> So you bind the global variable - which is not what we want but that
> binding should be visible nonetheless. I'm not sure why it does not
> work as expected.
Me neither.
> In some situations it can help to use a variable watcher to log
> variable binding changes:
>
> (info "(elisp) Watching Variables")
Oh, that's a great hint! I've tried with this watch:
--8<---------------cut here---------------start------------->8---
(add-variable-watcher 'inhibit-auto-revert
(lambda (sym new-val op where)
(message "(%S %S %S) in %S"
op sym new-val where)))
--8<---------------cut here---------------end--------------->8---
And what should I say, it still didn't work in the beginning, i.e., the
previous version of my last mail + (setq inhibit-auto-revert nil) in
dired-mode to create a local variable. The watcher showed that after
confirming the compression of my 1000 test files, a set with value nil
was done but I have no clue from where.
Then I edited a bit back and forth and recompiled and tested (with emacs
-Q) after each edit without actually changing any significant part,
e.g., I tried to also let-bind inhibit-auto-revert to t in the function
dired-map-over-marks-check which uses the macro dired-map-over-marks.
Still not working. So reverting that again. And now I have the patch
at the end of this mail AND IT SUDDENLY WORKS.
The output including the watcher is this (commented by me):
;; That's for the confirmation query
(let inhibit-auto-revert t) in #<buffer test>
(unlet inhibit-auto-revert nil) in #<buffer test>
Compress or uncompress * [1000 files]? (y or n) y
;; That's the actual compression of the 1000 files
(let inhibit-auto-revert t) in #<buffer test>
(unlet inhibit-auto-revert nil) in #<buffer test>
Compress or uncompress: 1000 files.
Reverting buffer ‘test’
So exactly as one might expect. And the last line suggests that
inhibiting some auto-reverts is not bad either, it'll be reverted in the
next round.
But I really wonder what could have caused that it didn't work
initially. Yesterday, I've rebuilt emacs without native compiler in
order to rule that out as the culprit. Could it be that a
non-native-comp emacs still picks up outdated eln files? Well, then the
question would be why it doesn't anymore...
Anyway, below the current patch. It would be great if someone else
could test it, too.
Obviously, the new inhibit-auto-revert should be mentioned in NEWS and
the elisp info docs which I'll do and post the final patch for review
before committing.
Bye,
Tassilo
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: inhibit-auto-revert.patch --]
[-- Type: text/x-patch, Size: 5629 bytes --]
diff --git a/lisp/autorevert.el b/lisp/autorevert.el
index 1dcfe8e911f..0cd0623c59b 100644
--- a/lisp/autorevert.el
+++ b/lisp/autorevert.el
@@ -778,6 +778,11 @@ auto-revert-active-p
auto-revert-tail-mode
auto-revert--global-mode))
+(defvar-local inhibit-auto-revert nil
+ "A non-nil value prevents `auto-revert-mode' from reverting the buffer.
+Should be used in let-bindings to temporarily disable auto-reverts in a
+buffer.")
+
(defun auto-revert-handler ()
"Revert current buffer, if appropriate.
This is an internal function used by Auto-Revert Mode."
@@ -787,25 +792,27 @@ auto-revert-handler
;; the values.
(remote-file-name-inhibit-cache t)
(revert
- (if buffer-file-name
- (and (or auto-revert-remote-files
- (not (file-remote-p buffer-file-name)))
- (or (not auto-revert-notify-watch-descriptor)
- auto-revert-notify-modified-p)
- (if auto-revert-tail-mode
- (and (file-readable-p buffer-file-name)
- (/= auto-revert-tail-pos
- (setq size
- (file-attribute-size
- (file-attributes buffer-file-name)))))
- (funcall (or buffer-stale-function
- #'buffer-stale--default-function)
- t)))
- (and (or auto-revert-mode
- global-auto-revert-non-file-buffers)
- (funcall (or buffer-stale-function
- #'buffer-stale--default-function)
- t))))
+ (and
+ (not inhibit-auto-revert)
+ (if buffer-file-name
+ (and (or auto-revert-remote-files
+ (not (file-remote-p buffer-file-name)))
+ (or (not auto-revert-notify-watch-descriptor)
+ auto-revert-notify-modified-p)
+ (if auto-revert-tail-mode
+ (and (file-readable-p buffer-file-name)
+ (/= auto-revert-tail-pos
+ (setq size
+ (file-attribute-size
+ (file-attributes buffer-file-name)))))
+ (funcall (or buffer-stale-function
+ #'buffer-stale--default-function)
+ t)))
+ (and (or auto-revert-mode
+ global-auto-revert-non-file-buffers)
+ (funcall (or buffer-stale-function
+ #'buffer-stale--default-function)
+ t)))))
eob eoblist)
(setq auto-revert-notify-modified-p nil
auto-revert--last-time (current-time))
diff --git a/lisp/dired.el b/lisp/dired.el
index d2071d80bf3..eef1fdd50dc 100644
--- a/lisp/dired.el
+++ b/lisp/dired.el
@@ -944,9 +944,6 @@ dired-mark-if
""))))
(and (> count 0) count)))
-(defvar-local dired--inhibit-auto-revert nil
- "A non-nil value prevents `auto-revert-mode' from reverting the buffer.")
-
(defmacro dired-map-over-marks (body arg &optional show-progress
distinguish-one-marked)
"Eval BODY with point on each marked line. Return a list of BODY's results.
@@ -983,8 +980,8 @@ dired-map-over-marks
;;endless loop.
;;This warning should not apply any longer, sk 2-Sep-1991 14:10.
`(prog1
- (let ((dired--inhibit-auto-revert t)
- (inhibit-read-only t)
+ (let ((inhibit-read-only t)
+ (inhibit-auto-revert t)
case-fold-search found results)
(if (and ,arg (not (eq ,arg 'marked)))
(if (integerp ,arg)
@@ -1294,12 +1291,6 @@ dired-buffer-stale-p
;; Do not auto-revert when the dired buffer can be currently
;; written by the user as in `wdired-mode'.
buffer-read-only
- ;; When a dired operation using dired-map-over-marks is in
- ;; progress, dired--inhibit-auto-revert is bound to some
- ;; non-nil value and we must not auto-revert because that could
- ;; change the order of files leading to skipping or
- ;; double-processing (see bug#75626).
- (not dired--inhibit-auto-revert)
(dired-directory-changed-p dirname))))
(defcustom dired-auto-revert-buffer nil
@@ -2796,6 +2787,7 @@ dired-mode
mode-name "Dired"
;; case-fold-search nil
buffer-read-only t
+ inhibit-auto-revert nil
mode-line-buffer-identification
(propertized-buffer-identification "%17b"))
(add-to-invisibility-spec '(dired . t))
@@ -4089,13 +4081,12 @@ dired-internal-do-deletions
(while l
(goto-char (marker-position (cdr (car l))))
(dired-move-to-filename)
- (let ((inhibit-read-only t))
+ (let ((inhibit-read-only t)
+ ;; Temporarily prevent auto-revert while deleting
+ ;; entry in the dired buffer (bug#71264).
+ (inhibit-auto-revert t))
(condition-case err
- (let ((fn (car (car l)))
- ;; Temporarily prevent auto-revert while
- ;; deleting entry in the dired buffer
- ;; (bug#71264).
- (auto-revert-mode nil))
+ (let ((fn (car (car l))))
(dired-delete-file fn dired-recursive-deletes trash)
;; if we get here, removing worked
(setq succ (1+ succ))
^ permalink raw reply related [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-22 8:05 ` Tassilo Horn
@ 2025-01-23 3:25 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-23 6:26 ` Tassilo Horn
0 siblings, 1 reply; 99+ messages in thread
From: Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-01-23 3:25 UTC (permalink / raw)
To: Tassilo Horn; +Cc: 75626, Eli Zaretskii, michael.albinus
Tassilo Horn <tsdh@gnu.org> writes:
> Could it be that a non-native-comp emacs still picks up outdated eln
> files? Well, then the question would be why it doesn't anymore...
Don't recall, but it could be.
> Anyway, below the current patch. It would be great if someone else
> could test it, too.
>
> Obviously, the new inhibit-auto-revert should be mentioned in NEWS and
> the elisp info docs which I'll do and post the final patch for review
> before committing.
I'm a bit late, and very sorry for that, but: doesn't this just
introduce a restricted twin of `buffer-stale-function'? This variable
is already buffer local in dired buffers and can be used for the same
purpose - or do I miss something?
Michael.
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-23 3:25 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-01-23 6:26 ` Tassilo Horn
2025-01-23 9:13 ` Eli Zaretskii
0 siblings, 1 reply; 99+ messages in thread
From: Tassilo Horn @ 2025-01-23 6:26 UTC (permalink / raw)
To: Michael Heerdegen; +Cc: 75626, Eli Zaretskii, michael.albinus
Michael Heerdegen <michael_heerdegen@web.de> writes:
>> Anyway, below the current patch. It would be great if someone else
>> could test it, too.
>>
>> Obviously, the new inhibit-auto-revert should be mentioned in NEWS and
>> the elisp info docs which I'll do and post the final patch for review
>> before committing.
>
> I'm a bit late, and very sorry for that,
I'm not in a hurry.
> but: doesn't this just introduce a restricted twin of
> `buffer-stale-function'? This variable is already buffer local in
> dired buffers and can be used for the same purpose - or do I miss
> something?
You are essentially right. If some code wants to inhibit auto-revert it
could also do (let ((buffer-stale-function #'ignore)) ...) although, I
think, that auto-revert-tail-mode could still tail-revert for
file-visiting buffers.
That said, I think the new inhibit-auto-revert is much clearer in what
it does. We already have a lot of inhibit-* variables, so that's where
I would look first when my aim is to inhibit some action. FWIW, until a
week ago, I had no clue that there is a buffer-stale-function and that
it has something to do with auto-revert. (It probably also has other
uses, so maybe let-binding it to #'ignore could have side-effects.)
Bye,
Tassilo
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-23 6:26 ` Tassilo Horn
@ 2025-01-23 9:13 ` Eli Zaretskii
2025-01-23 23:33 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 99+ messages in thread
From: Eli Zaretskii @ 2025-01-23 9:13 UTC (permalink / raw)
To: Tassilo Horn; +Cc: michael_heerdegen, 75626, michael.albinus
> From: Tassilo Horn <tsdh@gnu.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, michael.albinus@gmx.de,
> 75626@debbugs.gnu.org
> Date: Thu, 23 Jan 2025 07:26:50 +0100
>
> Michael Heerdegen <michael_heerdegen@web.de> writes:
>
> >> Anyway, below the current patch. It would be great if someone else
> >> could test it, too.
> >>
> >> Obviously, the new inhibit-auto-revert should be mentioned in NEWS and
> >> the elisp info docs which I'll do and post the final patch for review
> >> before committing.
> >
> > I'm a bit late, and very sorry for that,
>
> I'm not in a hurry.
>
> > but: doesn't this just introduce a restricted twin of
> > `buffer-stale-function'? This variable is already buffer local in
> > dired buffers and can be used for the same purpose - or do I miss
> > something?
>
> You are essentially right. If some code wants to inhibit auto-revert it
> could also do (let ((buffer-stale-function #'ignore)) ...) although, I
> think, that auto-revert-tail-mode could still tail-revert for
> file-visiting buffers.
>
> That said, I think the new inhibit-auto-revert is much clearer in what
> it does.
I tend to agree. A boolean variable with "inhibit" in its name is
much easier discovered than buffer-stale-function.
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-23 9:13 ` Eli Zaretskii
@ 2025-01-23 23:33 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-24 0:59 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-24 8:02 ` Eli Zaretskii
0 siblings, 2 replies; 99+ messages in thread
From: Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-01-23 23:33 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 75626, michael.albinus, Tassilo Horn
Eli Zaretskii <eliz@gnu.org> writes:
> I tend to agree. A boolean variable with "inhibit" in its name is
> much easier discovered than buffer-stale-function.
Sure - but discoverability is not the only point to consider. If I
think this thought further:
In case of dired, the decision about whether the buffer should be
auto-reverted is made by evaluating a (not trivial) condition and thus
we use a function value. This is hardly avoidable.
When we introduce a redundant new boolean variable, we would have to
decide what happens when the two disagree - the result could be
surprising. And when one would need to debug auto revert, one would
have to keep an eye on two variables instead of one. A complication
without any practical benefit IMO. As we saw, finding a fix for a
simple related bug was already not easy.
So i would rather consider to rename the variable
`buffer-stale-function' for the discoverability - or just leave things
as they are.
Michael.
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-23 23:33 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-01-24 0:59 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-24 6:24 ` Tassilo Horn
2025-01-24 8:02 ` Eli Zaretskii
1 sibling, 1 reply; 99+ messages in thread
From: Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-01-24 0:59 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 75626, michael.albinus, Tassilo Horn
I <michael_heerdegen@web.de> wrote:
> So i would rather consider to rename the variable
> `buffer-stale-function' for the discoverability - or just leave things
> as they are.
We could also rename the variable and pretend it is normally boolean -
but a function value is possible in addition and has a special meaning.
A not uncommon solution. Maybe this is what you had in mind?
There are caveats, though:
- People could be tempted to set `inhibit-auto-revert' to t and later
to nil, erasing the former non-nil function value by accident.
- People could try to inhibit auto revert globally (which would not be
possible once buffer local bindings exits), or may overlook the fact
that binding this variable may affect a global or a local binding.
I think this is something to consider: catchy names increase the risk
that such details are overlooked.
Michael.
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-24 0:59 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-01-24 6:24 ` Tassilo Horn
2025-01-24 23:26 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 99+ messages in thread
From: Tassilo Horn @ 2025-01-24 6:24 UTC (permalink / raw)
To: Michael Heerdegen; +Cc: 75626, Eli Zaretskii, michael.albinus
Michael Heerdegen <michael_heerdegen@web.de> writes:
> I <michael_heerdegen@web.de> wrote:
>
>> So i would rather consider to rename the variable
>> `buffer-stale-function' for the discoverability
To what? Especially with the "boolean or function" semantics below I
can hardly come up with a suitable yet discoverable name.
That aside, I think it's hard to rename and give new semantics to a
variable which is as old as Emacs 22.1 and might be used by external
packages.
>> - or just leave things as they are.
That would also be fine by me given the actual bug is fixed. (I'd add
another commit using dired--inhibit-auto-revert for properly fixing
bug#71264 without accidentially deactivating auto-revert-mode
altogether.)
> We could also rename the variable and pretend it is normally boolean -
> but a function value is possible in addition and has a special
> meaning. A not uncommon solution. Maybe this is what you had in
> mind?
At least not me. One difference between buffer-stale-function and
inhibit-auto-revert is that the latter inhibits all auto-reverts while
buffer-stale-function is not consulted at all for file-visiting buffers
when auto-revert-tail-mode is active.
> There are caveats, though:
>
> - People could be tempted to set `inhibit-auto-revert' to t and later
> to nil, erasing the former non-nil function value by accident.
>
> - People could try to inhibit auto revert globally (which would not be
> possible once buffer local bindings exits), or may overlook the fact
> that binding this variable may affect a global or a local binding.
>
> I think this is something to consider: catchy names increase the risk
> that such details are overlooked.
Probably right.
I don't have a strong preference for either way. Maybe we should just
keep it as-is until some other use-case besides dired pops up which
might never happen.
Bye,
Tassilo
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-23 23:33 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-24 0:59 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-01-24 8:02 ` Eli Zaretskii
2025-01-24 23:44 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 1 reply; 99+ messages in thread
From: Eli Zaretskii @ 2025-01-24 8:02 UTC (permalink / raw)
To: Michael Heerdegen; +Cc: 75626, michael.albinus, tsdh
> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: Tassilo Horn <tsdh@gnu.org>, michael.albinus@gmx.de,
> 75626@debbugs.gnu.org
> Date: Fri, 24 Jan 2025 00:33:38 +0100
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > I tend to agree. A boolean variable with "inhibit" in its name is
> > much easier discovered than buffer-stale-function.
>
> Sure - but discoverability is not the only point to consider. If I
> think this thought further:
>
> In case of dired, the decision about whether the buffer should be
> auto-reverted is made by evaluating a (not trivial) condition and thus
> we use a function value. This is hardly avoidable.
>
> When we introduce a redundant new boolean variable, we would have to
> decide what happens when the two disagree - the result could be
> surprising. And when one would need to debug auto revert, one would
> have to keep an eye on two variables instead of one.
We have quite a few of similar inhibit-SOMETHING variables in Emacs.
We use a simple rule for them: such a variable, when non-nil,
unconditionally overrides everything else. I've never had any
problems with that, and I debug Emacs quite a lot. It's actually the
other way around in many cases: being able to inhibit some
functionality by flipping a single variable is very easy and
convenient.
> A complication without any practical benefit IMO.
I think this opinion of yours is at least in part because you don't
appreciate the simplicity and convenience of a variable as opposed to
redefining or binding a function.
> As we saw, finding a fix for a simple related bug was already not
> easy.
For completely unrelated reasons, right?
> So i would rather consider to rename the variable
> `buffer-stale-function' for the discoverability - or just leave things
> as they are.
We cannot rename it.
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-24 6:24 ` Tassilo Horn
@ 2025-01-24 23:26 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 0 replies; 99+ messages in thread
From: Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-01-24 23:26 UTC (permalink / raw)
To: Tassilo Horn; +Cc: 75626, Eli Zaretskii, michael.albinus
Tassilo Horn <tsdh@gnu.org> writes:
> >> So i would rather consider to rename the variable
> >> `buffer-stale-function' for the discoverability
>
> To what?
buffer-inhibit-auto-revert-function or buffer-inhibit-auto-revert.
> That aside, I think it's hard to rename and give new semantics to a
> variable which is as old as Emacs 22.1 and might be used by external
> packages.
Since we would only extend semantics and non-function values currently
raise an error - what would be the problem?
> > We could also rename the variable and pretend it is normally boolean -
> > but a function value is possible in addition and has a special
> > meaning. A not uncommon solution. Maybe this is what you had in
> > mind?
>
> At least not me. One difference between buffer-stale-function and
> inhibit-auto-revert is that the latter inhibits all auto-reverts while
> buffer-stale-function is not consulted at all for file-visiting buffers
> when auto-revert-tail-mode is active.
Oh... I didn't notice that fact up to now. Should we maybe document
that in the docstring of `buffer-stale-function'?
Anyway, if your goal is a switch that influences both modes, then my
approach would not be sufficient, obviously.
But did anybody think about typical use cases and what would be useful -
before we cut in stone a new mechanism with no use cases at all in mind?
> I don't have a strong preference for either way. Maybe we should just
> keep it as-is until some other use-case besides dired pops up which
> might never happen.
A good summary - I would really prefer that to be honest.
Michael.
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-24 8:02 ` Eli Zaretskii
@ 2025-01-24 23:44 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-25 9:04 ` Tassilo Horn
0 siblings, 1 reply; 99+ messages in thread
From: Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-01-24 23:44 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 75626, michael.albinus, tsdh
Eli Zaretskii <eliz@gnu.org> writes:
> We have quite a few of similar inhibit-SOMETHING variables in Emacs.
> We use a simple rule for them: such a variable, when non-nil,
> unconditionally overrides everything else. I've never had any
> problems with that, and I debug Emacs quite a lot. It's actually the
> other way around in many cases: being able to inhibit some
> functionality by flipping a single variable is very easy and
> convenient.
100% agree, but my problem is not that at all, but the duplication we
introduce.
> > A complication without any practical benefit IMO.
>
> I think this opinion of yours is at least in part because you don't
> appreciate the simplicity and convenience of a variable as opposed to
> redefining or binding a function.
I would need more use cases to be able to decide that. Which of the two
variables would be used/bound more in practice?
In the long run, code is longer maintained that created. And the design
of autorevert.el is already not that trivial. So when I in the future
would have to follow the binding of two variables instead of one to
understand what is going on, this is not an improvement, because the
existing variable is still there and hardly discoverable, and at least
potentially involved.
So you seem to look at this more from the perspective of use cases. For
that perspective I even agree but I dunno how much it matters since I
don't know how useful this feature is. And even then - as said, all
those use cases will be easier to implement but harder to debug.
> > So i would rather consider to rename the variable
> > `buffer-stale-function' for the discoverability - or just leave
> > things as they are.
>
> We cannot rename it.
Then I would prefer to keep the fix we have.
Michael.
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-24 23:44 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-01-25 9:04 ` Tassilo Horn
2025-01-25 13:04 ` Eli Zaretskii
0 siblings, 1 reply; 99+ messages in thread
From: Tassilo Horn @ 2025-01-25 9:04 UTC (permalink / raw)
To: Michael Heerdegen; +Cc: 75626, Eli Zaretskii, michael.albinus
Michael Heerdegen <michael_heerdegen@web.de> writes:
>> > So i would rather consider to rename the variable
>> > `buffer-stale-function' for the discoverability - or just leave
>> > things as they are.
>>
>> We cannot rename it.
>
> Then I would prefer to keep the fix we have.
Ok, let's make a decision then. The two options on the table are:
1. Just keep the dired-specific dired--inhibit-auto-revert as it's
committed now (+ use that to fix bug#71264 properly, too).
2. Use the more general inhibit-auto-revert patch I've posted here.
I lean towards option 1 simply because my gut feeling says that the
dired issue is probably a historical accident, i.e., its workings have
been implemented long before auto-revert was a thing. If one were to
implement something similar today (like ops on processes in proced), one
would not use an approach navigating lines in the buffer. Even most
dired commands don't or just do to collect the list of files to act on
initially.
Bye,
Tassilo
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-25 9:04 ` Tassilo Horn
@ 2025-01-25 13:04 ` Eli Zaretskii
2025-01-26 8:50 ` Tassilo Horn
0 siblings, 1 reply; 99+ messages in thread
From: Eli Zaretskii @ 2025-01-25 13:04 UTC (permalink / raw)
To: Tassilo Horn; +Cc: michael_heerdegen, 75626, michael.albinus
> From: Tassilo Horn <tsdh@gnu.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, michael.albinus@gmx.de,
> 75626@debbugs.gnu.org
> Date: Sat, 25 Jan 2025 10:04:03 +0100
>
> Michael Heerdegen <michael_heerdegen@web.de> writes:
>
> >> > So i would rather consider to rename the variable
> >> > `buffer-stale-function' for the discoverability - or just leave
> >> > things as they are.
> >>
> >> We cannot rename it.
> >
> > Then I would prefer to keep the fix we have.
>
> Ok, let's make a decision then. The two options on the table are:
>
> 1. Just keep the dired-specific dired--inhibit-auto-revert as it's
> committed now (+ use that to fix bug#71264 properly, too).
>
> 2. Use the more general inhibit-auto-revert patch I've posted here.
>
> I lean towards option 1 simply because my gut feeling says that the
> dired issue is probably a historical accident, i.e., its workings have
> been implemented long before auto-revert was a thing. If one were to
> implement something similar today (like ops on processes in proced), one
> would not use an approach navigating lines in the buffer. Even most
> dired commands don't or just do to collect the list of files to act on
> initially.
Sounds like option 1 is preferred by several people, so let's keep it.
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-25 13:04 ` Eli Zaretskii
@ 2025-01-26 8:50 ` Tassilo Horn
2025-01-27 0:53 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 99+ messages in thread
From: Tassilo Horn @ 2025-01-26 8:50 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: michael_heerdegen, 75626-done, michael.albinus
Eli Zaretskii <eliz@gnu.org> writes:
>> Ok, let's make a decision then. The two options on the table are:
>>
>> 1. Just keep the dired-specific dired--inhibit-auto-revert as it's
>> committed now (+ use that to fix bug#71264 properly, too).
>>
>> 2. Use the more general inhibit-auto-revert patch I've posted here.
>>
>> I lean towards option 1 simply because my gut feeling says that the
>> dired issue is probably a historical accident, i.e., its workings have
>> been implemented long before auto-revert was a thing. If one were to
>> implement something similar today (like ops on processes in proced), one
>> would not use an approach navigating lines in the buffer. Even most
>> dired commands don't or just do to collect the list of files to act on
>> initially.
>
> Sounds like option 1 is preferred by several people, so let's keep it.
Alright, I've just pushed the addon change for fixing bug#71264 using
dired--inhibit-auto-revert.
Thanks,
Tassilo
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-26 8:50 ` Tassilo Horn
@ 2025-01-27 0:53 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-27 6:10 ` Tassilo Horn
0 siblings, 1 reply; 99+ messages in thread
From: Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-01-27 0:53 UTC (permalink / raw)
To: Tassilo Horn; +Cc: Eli Zaretskii, 75626-done, michael.albinus
Tassilo Horn <tsdh@gnu.org> writes:
> Alright, I've just pushed the addon change for fixing bug#71264 using
> dired--inhibit-auto-revert.
Thanks.
Can the issue from Bug#71264 as well happen for file operations other
than deletion?
Michael.
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-27 0:53 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-01-27 6:10 ` Tassilo Horn
2025-01-27 8:27 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-28 1:07 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 2 replies; 99+ messages in thread
From: Tassilo Horn @ 2025-01-27 6:10 UTC (permalink / raw)
To: Michael Heerdegen; +Cc: Eli Zaretskii, 75626-done, michael.albinus
Michael Heerdegen <michael_heerdegen@web.de> writes:
>> Alright, I've just pushed the addon change for fixing bug#71264 using
>> dired--inhibit-auto-revert.
>
> Thanks.
>
> Can the issue from Bug#71264 as well happen for file operations other
> than deletion?
Could be. One would need to look at each command. Basically, the issue
of the two bugs can occur when auto-revert may happen which is when
Emacs is waiting for a process to finish (like in this bug) or when
waiting for user-input (like the confirmation prompt in bug#71264).
Bye,
Tassilo
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-27 6:10 ` Tassilo Horn
@ 2025-01-27 8:27 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-27 13:17 ` Tassilo Horn
2025-01-28 1:07 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 1 reply; 99+ messages in thread
From: Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-01-27 8:27 UTC (permalink / raw)
To: Tassilo Horn; +Cc: Michael Heerdegen, 75626, Eli Zaretskii
Tassilo Horn <tsdh@gnu.org> writes:
Hi everybody,
Sorry for being late to the party, but last week I wasn't in the mood
for any party. And honestly, it isn't much better now. But so what.
> Could be. One would need to look at each command. Basically, the issue
> of the two bugs can occur when auto-revert may happen which is when
> Emacs is waiting for a process to finish (like in this bug) or when
> waiting for user-input (like the confirmation prompt in bug#71264).
Auto-revert is triggered either by timers (polling) or by events (file
notification). So yes, it is applied when either timers or event reading
is in place.
I believe it is good to have a mechanism like inhibit-auto-revert or
dired--inhibit-auto-revert, in order to suppress auto-reverting
temporarily. The problem is, that as now they have a nil-or-t value,
which means that other auto-reverts are blocked also during this time,
although they are not related. No problem in case of polling (the next
poll will do the auto-revert), but in case of file notifications the
information is lost.
My proposal is, that we give the variable a list of buffers instead,
which are excluded from auto-revert. Then the autorevert for this buffer
can be suppressed in auto-revert-buffer by a simple check. And
auto-revert clients need only to add/remove the buffer in question to
*inhibit-auto-revert, without thinking about filtering.
With this approach, it is preferred to have a global variable
inhibit-auto-revert. The mechanism wouldn't be restricted to dired buffers.
> Bye,
> Tassilo
Best regards, Michael.
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-27 8:27 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-01-27 13:17 ` Tassilo Horn
0 siblings, 0 replies; 99+ messages in thread
From: Tassilo Horn @ 2025-01-27 13:17 UTC (permalink / raw)
To: Michael Albinus; +Cc: Michael Heerdegen, 75626, Eli Zaretskii
Michael Albinus <michael.albinus@gmx.de> writes:
Hi Michael,
> Sorry for being late to the party, but last week I wasn't in the mood
> for any party. And honestly, it isn't much better now. But so what.
I'm sorry to hear. I hope it gets better soon.
>> Could be. One would need to look at each command. Basically, the
>> issue of the two bugs can occur when auto-revert may happen which is
>> when Emacs is waiting for a process to finish (like in this bug) or
>> when waiting for user-input (like the confirmation prompt in
>> bug#71264).
>
> Auto-revert is triggered either by timers (polling) or by events (file
> notification). So yes, it is applied when either timers or event
> reading is in place.
>
> I believe it is good to have a mechanism like inhibit-auto-revert or
> dired--inhibit-auto-revert, in order to suppress auto-reverting
> temporarily. The problem is, that as now they have a nil-or-t value,
> which means that other auto-reverts are blocked also during this time,
> although they are not related.
That's not completely true in this case. dired--inhibit-auto-revert is
buffer-local and won't disable other auto-reverts (even not of other
dired buffers).
(The idea with a inhibit-auto-revert variable has been canceled for the
time being.)
> No problem in case of polling (the next poll will do the auto-revert),
> but in case of file notifications the information is lost.
That's true. But I think this is not a new issue. I mean, that has
always happened when a buffer's buffer-stale-function returned nil for
whatever reason, e.g., in dired when wdired was active and thus
buffer-read-only was nil.
And is there a way to set up auto-revert in such a way that it *only*
uses file notifications and no polling at all? Looking at the code, it
seems to me that file notifications just produce a quicker auto-revert
than polling (auto-revert-interval). I'd assume that
auto-revert-interval seconds after inhibition (buffer-stale-function
saying "no" due to whatever reasons), the next auto-revert chance from
polling comes.
Bye,
Tassilo
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-27 6:10 ` Tassilo Horn
2025-01-27 8:27 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-01-28 1:07 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-28 19:39 ` Tassilo Horn
1 sibling, 1 reply; 99+ messages in thread
From: Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-01-28 1:07 UTC (permalink / raw)
To: Tassilo Horn; +Cc: Eli Zaretskii, 75626-done, michael.albinus
Tassilo Horn <tsdh@gnu.org> writes:
> > Can the issue from Bug#71264 as well happen for file operations other
> > than deletion?
>
> Could be. One would need to look at each command. Basically, the issue
> of the two bugs can occur when auto-revert may happen which is when
> Emacs is waiting for a process to finish (like in this bug) or when
> waiting for user-input (like the confirmation prompt in bug#71264).
We could try to catch more of these situations programmatically. We
could, for example, change `dired-buffer-stale-p' to return non-nil
when the selected window is an active minibuffer window and
`minibuffer-selected-window' is a window displaying the buffer which is
queried to be auto-reverted. With other words: avoid auto revert
whenever the user is currently in a prompt from a command started in a
dired buffer.
Would something like that make sense?
Michael.
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-28 1:07 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-01-28 19:39 ` Tassilo Horn
2025-01-28 23:58 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 99+ messages in thread
From: Tassilo Horn @ 2025-01-28 19:39 UTC (permalink / raw)
To: Michael Heerdegen; +Cc: Eli Zaretskii, 75626-done, michael.albinus
Michael Heerdegen <michael_heerdegen@web.de> writes:
>> > Can the issue from Bug#71264 as well happen for file operations other
>> > than deletion?
>>
>> Could be. One would need to look at each command. Basically, the issue
>> of the two bugs can occur when auto-revert may happen which is when
>> Emacs is waiting for a process to finish (like in this bug) or when
>> waiting for user-input (like the confirmation prompt in bug#71264).
>
> We could try to catch more of these situations programmatically. We
> could, for example, change `dired-buffer-stale-p' to return non-nil
> when the selected window is an active minibuffer window and
> `minibuffer-selected-window' is a window displaying the buffer which
> is queried to be auto-reverted. With other words: avoid auto revert
> whenever the user is currently in a prompt from a command started in a
> dired buffer.
>
> Would something like that make sense?
Maybe make sense but it doesn't work. I tried with dired-do-compress
and many marked files. That will first create a *Marked Files* buffer,
show that as a new bottom window, and then invoke the prompting function
like yes-or-no-p. I.e., (minibuffer-selected-window) is the window
showing the *Marked Files* buffer, not the original dired buffer.
Bye,
Tassilo
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-28 19:39 ` Tassilo Horn
@ 2025-01-28 23:58 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-31 6:39 ` Tassilo Horn
0 siblings, 1 reply; 99+ messages in thread
From: Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-01-28 23:58 UTC (permalink / raw)
To: Tassilo Horn; +Cc: Eli Zaretskii, 75626-done, michael.albinus
Tassilo Horn <tsdh@gnu.org> writes:
> > We could try to catch more of these situations programmatically. We
> > could, for example, change `dired-buffer-stale-p' to return non-nil
> > when the selected window is an active minibuffer window and
> > `minibuffer-selected-window' is a window displaying the buffer which
> > is queried to be auto-reverted. With other words: avoid auto revert
> > whenever the user is currently in a prompt from a command started in a
> > dired buffer.
> Maybe make sense but it doesn't work. I tried with dired-do-compress
> and many marked files. That will first create a *Marked Files* buffer,
> show that as a new bottom window, and then invoke the prompting function
> like yes-or-no-p. I.e., (minibuffer-selected-window) is the window
> showing the *Marked Files* buffer, not the original dired buffer.
I see. There are other implementation options: we could try to use the
buffer local bindings of `pre-command-hook' and `post-command-hook' to
set `dired--inhibit-auto-revert' non-nil whenever a command is processed
that had been started from a dired buffer. Or just check `this-command'
for whether its name matches "\\`dired". But of all these solutions are
probably not really optimal. Is there a clean solution?
OTOH, going through the command definitions in dired.el will not solve
the problem for third party packages and user written commands.
Michael.
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-28 23:58 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-01-31 6:39 ` Tassilo Horn
2025-02-01 0:18 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 99+ messages in thread
From: Tassilo Horn @ 2025-01-31 6:39 UTC (permalink / raw)
To: Michael Heerdegen; +Cc: Eli Zaretskii, 75626-done, michael.albinus
Michael Heerdegen <michael_heerdegen@web.de> writes:
> I see. There are other implementation options: we could try to use
> the buffer local bindings of `pre-command-hook' and
> `post-command-hook' to set `dired--inhibit-auto-revert' non-nil
> whenever a command is processed that had been started from a dired
> buffer.
That doesn't work when the command switches to some other buffer. Then
that other buffer's post-command-hook is run meaning the dired buffer
stays in dired--inhibit-auto-revert state forever. :-|
Bye,
Tassilo
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-01-31 6:39 ` Tassilo Horn
@ 2025-02-01 0:18 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-01 9:40 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 99+ messages in thread
From: Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-02-01 0:18 UTC (permalink / raw)
To: Tassilo Horn; +Cc: Eli Zaretskii, 75626-done, michael.albinus
Tassilo Horn <tsdh@gnu.org> writes:
> That doesn't work when the command switches to some other buffer. Then
> that other buffer's post-command-hook is run meaning the dired buffer
> stays in dired--inhibit-auto-revert state forever. :-|
Hmm.
If the approach makes sense in general we will find a way. How about
checking `this-command' and `current-minibuffer-command'? When any of
these is non-nil, we may want to prevent autorevert.
But this alone is too general - we should know if the are processing a
dired command. If the current buffer is a dired mode buffer, this is
ok. But the case with the popups is tricky, it seems we can't know in
which buffer a command had really been envoked. Also
`minibuffer--original-buffer' is not usable - it's only bound by
`completing-read'. Hmm.
How about saving the result of (buffer-chars-modified-tick) in the local
pre-command-hook and post-command-hook, into a local variable? If
`dired-buffer-stale-p' finds a different current value we know that the
current command has modified the buffer, and we should not auto-revert.
Though, this will still fail if a command first changes the buffer
contents and then the current buffer...
Maybe it is really easier to go through the commands...or use a
heuristic, like looking whether `this-command',
`current-minibuffer-command' match "dired". Using the global binding of
`pre-command-hook' and `post-command-hook' would probably also work
reliably but I would not want to clutter those with a function only for
the sake of this detail.
Michael.
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-02-01 0:18 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-02-01 9:40 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-01 21:50 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 99+ messages in thread
From: Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-02-01 9:40 UTC (permalink / raw)
To: Michael Heerdegen; +Cc: Eli Zaretskii, 75626-done, Tassilo Horn
Michael Heerdegen <michael_heerdegen@web.de> writes:
Hi,
> Hmm.
It will be more and more complex. Not desirable.
I know, that the variant with 'inhibit-auto-revert' has been
refused. However, I repeat this proposal. The difference is, that I
propose not to use t and nil as values, but a list of buffers or nil. By
this, a buffer could be suppressed temporarily from auto-revert by
adding it to this list, for example in a let-bind.
> Michael.
Best regards, Michael.
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-02-01 9:40 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-02-01 21:50 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-02 9:31 ` Tassilo Horn
2025-02-02 10:05 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 2 replies; 99+ messages in thread
From: Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-02-01 21:50 UTC (permalink / raw)
To: Michael Albinus; +Cc: Eli Zaretskii, 75626-done, Tassilo Horn
Michael Albinus <michael.albinus@gmx.de> writes:
> Michael Heerdegen <michael_heerdegen@web.de> writes:
>
> Hi,
>
> > Hmm.
>
> It will be more and more complex. Not desirable.
>
> I know, that the variant with 'inhibit-auto-revert' has been
> refused. However, I repeat this proposal. The difference is, that I
> propose not to use t and nil as values, but a list of buffers or nil. By
> this, a buffer could be suppressed temporarily from auto-revert by
> adding it to this list, for example in a let-bind.
But this will come with the same problems - or we need to change each
command individually and third party packages can still be affected by
the same issue - which is something I rather would prefer to avoid.
What advantage would your approach have? A global variable bound to a
list of buffers has its advantages, but also its disadvantages, it still
has to be kept up to date explicitly, dead buffers have to be removed,
etc. What you say seems a bit unrelated to what I outlined.
I haven't thought about any other cases than dired at all, though.
Thx,
Michael.
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-02-01 21:50 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-02-02 9:31 ` Tassilo Horn
2025-02-02 10:10 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-02 10:05 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 1 reply; 99+ messages in thread
From: Tassilo Horn @ 2025-02-02 9:31 UTC (permalink / raw)
To: Michael Heerdegen; +Cc: Eli Zaretskii, 75626-done, Michael Albinus
Michael Heerdegen <michael_heerdegen@web.de> writes:
>> I know, that the variant with 'inhibit-auto-revert' has been
>> refused. However, I repeat this proposal. The difference is, that I
>> propose not to use t and nil as values, but a list of buffers or
>> nil. By this, a buffer could be suppressed temporarily from
>> auto-revert by adding it to this list, for example in a let-bind.
>
> But this will come with the same problems - or we need to change each
> command individually and third party packages can still be affected by
> the same issue - which is something I rather would prefer to avoid.
>
> What advantage would your approach have? A global variable bound to a
> list of buffers has its advantages, but also its disadvantages, it
> still has to be kept up to date explicitly, dead buffers have to be
> removed, etc. What you say seems a bit unrelated to what I outlined.
Yes, I have the basically the same questions. IIRC, the problem you,
Michael A., wanted to address in your proposal was that if a buffer has
been skipped during auto-revert and the trigger for auto-revert was a
filesystem notification, the auto-revert should be retried later.
But isn't that the case anyway because auto-revert-buffers is run from a
timer every auto-revert-interval seconds, so unless one sets
auto-revert-interval to some very high value, no harm is done?
Even if we would like to cater for this case, I don't understand how
your approach addresses the retries for buffers that skipped/inhibited
auto-revert. I mean, I can envision that auto-revert maintains a list
of buffers it skipped but how would that be worked through? Another
timer that runs more often that auto-revert-interval?
One fact in favour for some inhibit-auto-revert variable is that
currently we abuse buffer-stale-function whose docs state "Function to
check wether a buffer _needs_ reverting" with functions that actually
check if we need and _allow_ reverting. If we had inhibit-auto-revert,
the allowance part could and should be removed from
buffer-stale-function.
Bye,
Tassilo
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-02-01 21:50 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-02 9:31 ` Tassilo Horn
@ 2025-02-02 10:05 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-02 11:10 ` Tassilo Horn
1 sibling, 1 reply; 99+ messages in thread
From: Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-02-02 10:05 UTC (permalink / raw)
To: Michael Heerdegen; +Cc: Eli Zaretskii, 75626-done, Tassilo Horn
[-- Attachment #1: Type: text/plain, Size: 1653 bytes --]
Michael Heerdegen <michael_heerdegen@web.de> writes:
Hi Michael,
>> I know, that the variant with 'inhibit-auto-revert' has been
>> refused. However, I repeat this proposal. The difference is, that I
>> propose not to use t and nil as values, but a list of buffers or nil. By
>> this, a buffer could be suppressed temporarily from auto-revert by
>> adding it to this list, for example in a let-bind.
>
> But this will come with the same problems - or we need to change each
> command individually and third party packages can still be affected by
> the same issue - which is something I rather would prefer to avoid.
You must change any package, like you did already with
dired.el. auto-revert-mode needs an indication that it should pause for
the current buffer temporarily.
> What advantage would your approach have? A global variable bound to a
> list of buffers has its advantages, but also its disadvantages, it still
> has to be kept up to date explicitly, dead buffers have to be removed,
> etc. What you say seems a bit unrelated to what I outlined.
I have added a patch as proof-of-concept. It adresses your concerns.
It adds the global variable inhibit-auto-revert-buffers and the macro
inhibit-auto-revert. I ran the recipe given in the original posting of
this bug many times, even pressing 'Z' while the previous dired
operation didn't finish, and it works as expected.
Could you and Thassilo check this?
> I haven't thought about any other cases than dired at all, though.
They should apply a similar change as I have shown in dired.el. Of
course, this must be documented properly.
> Thx,
>
> Michael.
Best regards, Michael.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 5372 bytes --]
diff --git a/lisp/autorevert.el b/lisp/autorevert.el
index 1dcfe8e911f..135c09fc274 100644
--- a/lisp/autorevert.el
+++ b/lisp/autorevert.el
@@ -897,6 +897,31 @@ auto-revert--buffer-candidates
(push buf new)))
(nreverse (nconc new remaining))))
+;;;###autoload
+(defvar inhibit-auto-revert-buffers nil
+ "A list of buffers with suppressed auto-revert.")
+
+;;;###autoload
+(progn (defmacro inhibit-auto-revert (&rest body)
+ "Deactivate auto-reverting of current buffer temporarily.
+Run BODY."
+ (declare (indent 0) (debug ((form body) body)))
+ `(progn
+ ;; Cleanup.
+ (dolist (buf inhibit-auto-revert-buffers)
+ (unless (buffer-live-p buf)
+ (setq inhibit-auto-revert-buffers
+ (delq buf inhibit-auto-revert-buffers))))
+ (let ((buf (and (not (memq (current-buffer) inhibit-auto-revert-buffers))
+ (current-buffer))))
+ (unwind-protect
+ (progn
+ (when buf (add-to-list 'inhibit-auto-revert-buffers buf))
+ ,@body)
+ (when buf
+ (setq inhibit-auto-revert-buffers
+ (delq buf inhibit-auto-revert-buffers))))))))
+
(defun auto-revert-buffer (buf)
"Revert a single buffer BUF.
@@ -905,11 +930,12 @@ auto-revert-buffer
(if (not (buffer-live-p buf))
(auto-revert-remove-current-buffer buf)
(with-current-buffer buf
- ;; Test if someone has turned off Auto-Revert Mode
- ;; in a non-standard way, for example by changing
- ;; major mode.
- (when (and (not auto-revert-mode)
- (not auto-revert-tail-mode))
+ ;; Test if someone has turned off Auto-Revert Mode in a
+ ;; non-standard way, for example by changing
+ ;; `inhibit-auto-revert-buffers' or major mode.
+ (when (or (and (not auto-revert-mode)
+ (not auto-revert-tail-mode))
+ (memq (current-buffer) inhibit-auto-revert-buffers))
(auto-revert-remove-current-buffer))
(when (auto-revert-active-p)
;; Enable file notification.
diff --git a/lisp/dired.el b/lisp/dired.el
index 2eb6546107a..f967b00147f 100644
--- a/lisp/dired.el
+++ b/lisp/dired.el
@@ -944,9 +944,6 @@ dired-mark-if
""))))
(and (> count 0) count)))
-(defvar-local dired--inhibit-auto-revert nil
- "A non-nil value prevents `auto-revert-mode' from reverting the buffer.")
-
(defmacro dired-map-over-marks (body arg &optional show-progress
distinguish-one-marked)
"Eval BODY with point on each marked line. Return a list of BODY's results.
@@ -983,8 +980,8 @@ dired-map-over-marks
;;endless loop.
;;This warning should not apply any longer, sk 2-Sep-1991 14:10.
`(prog1
- (let ((dired--inhibit-auto-revert t)
- (inhibit-read-only t)
+ (inhibit-auto-revert
+ (let ((inhibit-read-only t)
case-fold-search found results)
(if (and ,arg (not (eq ,arg 'marked)))
(if (integerp ,arg)
@@ -1024,7 +1021,7 @@ dired-map-over-marks
(if found
results
(unless (eq ,arg 'marked)
- (list ,body))))))
+ (list ,body)))))))
;; save-excursion loses, again
(dired-move-to-filename)))
@@ -1295,11 +1292,11 @@ dired-buffer-stale-p
;; written by the user as in `wdired-mode'.
buffer-read-only
;; When a dired operation using dired-map-over-marks is in
- ;; progress, dired--inhibit-auto-revert is bound to some
- ;; non-nil value and we must not auto-revert because that could
- ;; change the order of files leading to skipping or
- ;; double-processing (see bug#75626).
- (not dired--inhibit-auto-revert)
+ ;; progress, inhibit-auto-revert-buffers is modified and we
+ ;; must not auto-revert because that could change the order of
+ ;; files leading to skipping or double-processing (see
+ ;; bug#75626).
+ (not (memq (current-buffer) inhibit-auto-revert-buffers))
(dired-directory-changed-p dirname))))
(defcustom dired-auto-revert-buffer nil
@@ -4089,10 +4086,10 @@ dired-internal-do-deletions
(while l
(goto-char (marker-position (cdr (car l))))
(dired-move-to-filename)
- (let ((inhibit-read-only t)
- ;; Temporarily prevent auto-revert while deleting
- ;; entry in the dired buffer (bug#71264).
- (dired--inhibit-auto-revert t))
+ ;; Temporarily prevent auto-revert while deleting entry in
+ ;; the dired buffer (bug#71264).
+ (inhibit-auto-revert
+ (let ((inhibit-read-only t))
(condition-case err
(let ((fn (car (car l))))
(dired-delete-file fn dired-recursive-deletes trash)
@@ -4108,7 +4105,7 @@ dired-internal-do-deletions
(quit (throw '--delete-cancel (message "OK, canceled")))
(error ;; catch errors from failed deletions
(dired-log "%s: %s\n" (car err) (error-message-string err))
- (setq failures (cons (car (car l)) failures)))))
+ (setq failures (cons (car (car l)) failures))))))
(setq l (cdr l)))
(if (not failures)
(progress-reporter-done progress-reporter)
^ permalink raw reply related [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-02-02 9:31 ` Tassilo Horn
@ 2025-02-02 10:10 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-02 10:35 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-02 11:15 ` Tassilo Horn
0 siblings, 2 replies; 99+ messages in thread
From: Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-02-02 10:10 UTC (permalink / raw)
To: Tassilo Horn; +Cc: Michael Heerdegen, Eli Zaretskii, 75626-done
Tassilo Horn <tsdh@gnu.org> writes:
Hi Tassilo,
> Yes, I have the basically the same questions. IIRC, the problem you,
> Michael A., wanted to address in your proposal was that if a buffer has
> been skipped during auto-revert and the trigger for auto-revert was a
> filesystem notification, the auto-revert should be retried later.
>
> But isn't that the case anyway because auto-revert-buffers is run from a
> timer every auto-revert-interval seconds, so unless one sets
> auto-revert-interval to some very high value, no harm is done?
>
> Even if we would like to cater for this case, I don't understand how
> your approach addresses the retries for buffers that skipped/inhibited
> auto-revert. I mean, I can envision that auto-revert maintains a list
> of buffers it skipped but how would that be worked through? Another
> timer that runs more often that auto-revert-interval?
I haven't investigated this yet. Perhaps you are right, and a later
polling does the job. But this problem is recent anyway (if it is a
problem); my proposal doesn't make it worse.
> One fact in favour for some inhibit-auto-revert variable is that
> currently we abuse buffer-stale-function whose docs state "Function to
> check wether a buffer _needs_ reverting" with functions that actually
> check if we need and _allow_ reverting. If we had inhibit-auto-revert,
> the allowance part could and should be removed from
> buffer-stale-function.
See my patch, it does exactly this.
> Bye,
> Tassilo
Best regards, Michael.
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-02-02 10:10 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-02-02 10:35 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-02 11:14 ` Tassilo Horn
2025-02-02 11:15 ` Tassilo Horn
1 sibling, 1 reply; 99+ messages in thread
From: Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-02-02 10:35 UTC (permalink / raw)
To: Tassilo Horn; +Cc: Michael Heerdegen, 75626, Eli Zaretskii
Michael Albinus <michael.albinus@gmx.de> writes:
> Tassilo Horn <tsdh@gnu.org> writes:
>
> Hi Tassilo,
>
>> Even if we would like to cater for this case, I don't understand how
>> your approach addresses the retries for buffers that skipped/inhibited
>> auto-revert. I mean, I can envision that auto-revert maintains a list
>> of buffers it skipped but how would that be worked through? Another
>> timer that runs more often that auto-revert-interval?
>
> I haven't investigated this yet. Perhaps you are right, and a later
> polling does the job. But this problem is recent anyway (if it is a
> problem); my proposal doesn't make it worse.
Well, there is the user option auto-revert-avoid-polling. Per default it
is set to nil; meaning that if a buffer misses an auto-revert triggered
by file notification, the next poll will do. This is what we want.
If a user changes this option, it is his/her decision.
>> Bye,
>> Tassilo
Best regards, Michael.
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-02-02 10:05 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-02-02 11:10 ` Tassilo Horn
2025-02-02 11:39 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 99+ messages in thread
From: Tassilo Horn @ 2025-02-02 11:10 UTC (permalink / raw)
To: Michael Albinus; +Cc: Michael Heerdegen, Eli Zaretskii, 75626-done
Michael Albinus <michael.albinus@gmx.de> writes:
> It adds the global variable inhibit-auto-revert-buffers and the macro
> inhibit-auto-revert. I ran the recipe given in the original posting of
> this bug many times, even pressing 'Z' while the previous dired
> operation didn't finish, and it works as expected.
>
> Could you and Thassilo check this?
It works for me and my original problem, too. Some questions, though.
Why is the macro inhibit-auto-revert defined in a progn? I think, I've
never seen that before.
And why does dired-buffer-stale-p check if the current dired buffer is
member of inhibit-auto-revert-buffers? Isn't the point to move the
allowance check from packages' buffer-stale-function to auto-revert
itself? In that case, the buffer-read-only check (set by wdired-mode)
should probably also be rewritten to add the currently edited dired
buffer to inhibit-auto-revert-buffers and to remove it when wdired-mode
is deactivated (wdired-finish-edit).
Furthermore, the member check in auto-revert-buffer causes this buffer
to be removed from auto-revert-buffer-list meaning it will never ever be
reverted in the future, at least not by polling.
Bye,
Tassilo
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-02-02 10:35 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-02-02 11:14 ` Tassilo Horn
2025-02-02 11:41 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 99+ messages in thread
From: Tassilo Horn @ 2025-02-02 11:14 UTC (permalink / raw)
To: Michael Albinus; +Cc: Michael Heerdegen, 75626, Eli Zaretskii
Michael Albinus <michael.albinus@gmx.de> writes:
> Well, there is the user option auto-revert-avoid-polling.
Ah, I've missed that.
> Per default it is set to nil; meaning that if a buffer misses an
> auto-revert triggered by file notification, the next poll will
> do. This is what we want.
>
> If a user changes this option, it is his/her decision.
Maybe the caveat that notifications might not result in a revert when a
buffer's major mode doesn't allow a revert at that time should be
documented.
Bye,
Tassilo
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-02-02 10:10 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-02 10:35 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-02-02 11:15 ` Tassilo Horn
2025-02-02 11:43 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 1 reply; 99+ messages in thread
From: Tassilo Horn @ 2025-02-02 11:15 UTC (permalink / raw)
To: Michael Albinus; +Cc: Michael Heerdegen, Eli Zaretskii, 75626-done
Michael Albinus <michael.albinus@gmx.de> writes:
>> Even if we would like to cater for this case, I don't understand how
>> your approach addresses the retries for buffers that skipped/inhibited
>> auto-revert. I mean, I can envision that auto-revert maintains a list
>> of buffers it skipped but how would that be worked through? Another
>> timer that runs more often that auto-revert-interval?
>
> I haven't investigated this yet. Perhaps you are right, and a later
> polling does the job. But this problem is recent anyway (if it is a
> problem); my proposal doesn't make it worse.
Yes, that's for sure.
>> One fact in favour for some inhibit-auto-revert variable is that
>> currently we abuse buffer-stale-function whose docs state "Function
>> to check wether a buffer _needs_ reverting" with functions that
>> actually check if we need and _allow_ reverting. If we had
>> inhibit-auto-revert, the allowance part could and should be removed
>> from buffer-stale-function.
>
> See my patch, it does exactly this.
I don't agree, see my other mail. In your patch, it's still
dired-buffer-stale-p who does the allowance check.
Bye,
Tassilo
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-02-02 11:10 ` Tassilo Horn
@ 2025-02-02 11:39 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-02 12:55 ` Tassilo Horn
0 siblings, 1 reply; 99+ messages in thread
From: Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-02-02 11:39 UTC (permalink / raw)
To: Tassilo Horn; +Cc: Michael Heerdegen, Eli Zaretskii, 75626-done
[-- Attachment #1: Type: text/plain, Size: 1317 bytes --]
Tassilo Horn <tsdh@gnu.org> writes:
Hi Tassilo,
> It works for me and my original problem, too. Some questions, though.
Thanks.
> Why is the macro inhibit-auto-revert defined in a progn? I think, I've
> never seen that before.
This is a trick to bring the defmacro body into loaddefs.el. See also
the declaration of define-short-documentation-group, for example.
> And why does dired-buffer-stale-p check if the current dired buffer is
> member of inhibit-auto-revert-buffers? Isn't the point to move the
> allowance check from packages' buffer-stale-function to auto-revert
> itself? In that case, the buffer-read-only check (set by wdired-mode)
> should probably also be rewritten to add the currently edited dired
> buffer to inhibit-auto-revert-buffers and to remove it when wdired-mode
> is deactivated (wdired-finish-edit).
Yes, I've moved the check of a buffer being member of
inhibit-auto-revert-buffers to autorevert.el, see patch below. Thanks
for the heads-up.
> Furthermore, the member check in auto-revert-buffer causes this buffer
> to be removed from auto-revert-buffer-list meaning it will never ever be
> reverted in the future, at least not by polling.
Yes, and this is intended. We disable auto-reverting for a given
time. With consequences.
> Bye,
> Tassilo
Best regards, Michael.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 6482 bytes --]
diff --git a/lisp/autorevert.el b/lisp/autorevert.el
index 1dcfe8e911f..8352c75344e 100644
--- a/lisp/autorevert.el
+++ b/lisp/autorevert.el
@@ -798,14 +798,17 @@ auto-revert-handler
(setq size
(file-attribute-size
(file-attributes buffer-file-name)))))
- (funcall (or buffer-stale-function
- #'buffer-stale--default-function)
- t)))
+ (and (not (memq (current-buffer)
+ inhibit-auto-revert-buffers))
+ (funcall (or buffer-stale-function
+ #'buffer-stale--default-function)
+ t))))
(and (or auto-revert-mode
global-auto-revert-non-file-buffers)
- (funcall (or buffer-stale-function
- #'buffer-stale--default-function)
- t))))
+ (and (not (memq (current-buffer) inhibit-auto-revert-buffers))
+ (funcall (or buffer-stale-function
+ #'buffer-stale--default-function)
+ t)))))
eob eoblist)
(setq auto-revert-notify-modified-p nil
auto-revert--last-time (current-time))
@@ -897,6 +900,31 @@ auto-revert--buffer-candidates
(push buf new)))
(nreverse (nconc new remaining))))
+;;;###autoload
+(progn
+ (defvar inhibit-auto-revert-buffers nil
+ "A list of buffers with suppressed auto-revert.")
+
+ (defmacro inhibit-auto-revert (&rest body)
+ "Deactivate auto-reverting of current buffer temporarily.
+Run BODY."
+ (declare (indent 0) (debug ((form body) body)))
+ `(progn
+ ;; Cleanup.
+ (dolist (buf inhibit-auto-revert-buffers)
+ (unless (buffer-live-p buf)
+ (setq inhibit-auto-revert-buffers
+ (delq buf inhibit-auto-revert-buffers))))
+ (let ((buf (and (not (memq (current-buffer) inhibit-auto-revert-buffers))
+ (current-buffer))))
+ (unwind-protect
+ (progn
+ (when buf (add-to-list 'inhibit-auto-revert-buffers buf))
+ ,@body)
+ (when buf
+ (setq inhibit-auto-revert-buffers
+ (delq buf inhibit-auto-revert-buffers))))))))
+
(defun auto-revert-buffer (buf)
"Revert a single buffer BUF.
@@ -905,11 +933,12 @@ auto-revert-buffer
(if (not (buffer-live-p buf))
(auto-revert-remove-current-buffer buf)
(with-current-buffer buf
- ;; Test if someone has turned off Auto-Revert Mode
- ;; in a non-standard way, for example by changing
- ;; major mode.
- (when (and (not auto-revert-mode)
- (not auto-revert-tail-mode))
+ ;; Test if someone has turned off Auto-Revert Mode in a
+ ;; non-standard way, for example by changing
+ ;; `inhibit-auto-revert-buffers' or major mode.
+ (when (or (and (not auto-revert-mode)
+ (not auto-revert-tail-mode))
+ (memq (current-buffer) inhibit-auto-revert-buffers))
(auto-revert-remove-current-buffer))
(when (auto-revert-active-p)
;; Enable file notification.
diff --git a/lisp/dired.el b/lisp/dired.el
index 2eb6546107a..01621c9ea4e 100644
--- a/lisp/dired.el
+++ b/lisp/dired.el
@@ -944,9 +944,6 @@ dired-mark-if
""))))
(and (> count 0) count)))
-(defvar-local dired--inhibit-auto-revert nil
- "A non-nil value prevents `auto-revert-mode' from reverting the buffer.")
-
(defmacro dired-map-over-marks (body arg &optional show-progress
distinguish-one-marked)
"Eval BODY with point on each marked line. Return a list of BODY's results.
@@ -983,8 +980,8 @@ dired-map-over-marks
;;endless loop.
;;This warning should not apply any longer, sk 2-Sep-1991 14:10.
`(prog1
- (let ((dired--inhibit-auto-revert t)
- (inhibit-read-only t)
+ (inhibit-auto-revert
+ (let ((inhibit-read-only t)
case-fold-search found results)
(if (and ,arg (not (eq ,arg 'marked)))
(if (integerp ,arg)
@@ -1024,7 +1021,7 @@ dired-map-over-marks
(if found
results
(unless (eq ,arg 'marked)
- (list ,body))))))
+ (list ,body)))))))
;; save-excursion loses, again
(dired-move-to-filename)))
@@ -1294,12 +1291,6 @@ dired-buffer-stale-p
;; Do not auto-revert when the dired buffer can be currently
;; written by the user as in `wdired-mode'.
buffer-read-only
- ;; When a dired operation using dired-map-over-marks is in
- ;; progress, dired--inhibit-auto-revert is bound to some
- ;; non-nil value and we must not auto-revert because that could
- ;; change the order of files leading to skipping or
- ;; double-processing (see bug#75626).
- (not dired--inhibit-auto-revert)
(dired-directory-changed-p dirname))))
(defcustom dired-auto-revert-buffer nil
@@ -4089,10 +4080,10 @@ dired-internal-do-deletions
(while l
(goto-char (marker-position (cdr (car l))))
(dired-move-to-filename)
- (let ((inhibit-read-only t)
- ;; Temporarily prevent auto-revert while deleting
- ;; entry in the dired buffer (bug#71264).
- (dired--inhibit-auto-revert t))
+ ;; Temporarily prevent auto-revert while deleting entry in
+ ;; the dired buffer (bug#71264).
+ (inhibit-auto-revert
+ (let ((inhibit-read-only t))
(condition-case err
(let ((fn (car (car l))))
(dired-delete-file fn dired-recursive-deletes trash)
@@ -4108,7 +4099,7 @@ dired-internal-do-deletions
(quit (throw '--delete-cancel (message "OK, canceled")))
(error ;; catch errors from failed deletions
(dired-log "%s: %s\n" (car err) (error-message-string err))
- (setq failures (cons (car (car l)) failures)))))
+ (setq failures (cons (car (car l)) failures))))))
(setq l (cdr l)))
(if (not failures)
(progress-reporter-done progress-reporter)
^ permalink raw reply related [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-02-02 11:14 ` Tassilo Horn
@ 2025-02-02 11:41 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-02 12:30 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 99+ messages in thread
From: Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-02-02 11:41 UTC (permalink / raw)
To: Tassilo Horn; +Cc: Michael Heerdegen, 75626, Eli Zaretskii
Tassilo Horn <tsdh@gnu.org> writes:
Hi Tassilo,
>> Per default it is set to nil; meaning that if a buffer misses an
>> auto-revert triggered by file notification, the next poll will
>> do. This is what we want.
>>
>> If a user changes this option, it is his/her decision.
>
> Maybe the caveat that notifications might not result in a revert when a
> buffer's major mode doesn't allow a revert at that time should be
> documented.
Agreed. I'm just working on the Elisp manual; will mention it there.
> Bye,
> Tassilo
Best regards, Michael.
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-02-02 11:15 ` Tassilo Horn
@ 2025-02-02 11:43 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 0 replies; 99+ messages in thread
From: Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-02-02 11:43 UTC (permalink / raw)
To: Tassilo Horn; +Cc: Michael Heerdegen, 75626, Eli Zaretskii
Tassilo Horn <tsdh@gnu.org> writes:
>>> One fact in favour for some inhibit-auto-revert variable is that
>>> currently we abuse buffer-stale-function whose docs state "Function
>>> to check wether a buffer _needs_ reverting" with functions that
>>> actually check if we need and _allow_ reverting. If we had
>>> inhibit-auto-revert, the allowance part could and should be removed
>>> from buffer-stale-function.
>>
>> See my patch, it does exactly this.
>
> I don't agree, see my other mail. In your patch, it's still
> dired-buffer-stale-p who does the allowance check.
And I agree your opposition. Changed in the new version of the patch,
see the other message.
> Bye,
> Tassilo
Best regards, Michael.
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-02-02 11:41 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-02-02 12:30 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 0 replies; 99+ messages in thread
From: Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-02-02 12:30 UTC (permalink / raw)
To: Tassilo Horn; +Cc: Michael Heerdegen, 75626, Eli Zaretskii
[-- Attachment #1: Type: text/plain, Size: 391 bytes --]
Michael Albinus <michael.albinus@gmx.de> writes:
Hi Tassilo,
>> Maybe the caveat that notifications might not result in a revert when a
>> buffer's major mode doesn't allow a revert at that time should be
>> documented.
>
> Agreed. I'm just working on the Elisp manual; will mention it there.
Appended is the doc change I propose. For review.
>> Bye,
>> Tassilo
Best regards, Michael.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 1641 bytes --]
diff --git a/doc/lispref/backups.texi b/doc/lispref/backups.texi
index 50c7ace253c..f3f0902f364 100644
--- a/doc/lispref/backups.texi
+++ b/doc/lispref/backups.texi
@@ -852,6 +852,30 @@ Reverting
as a consequence of auto-reverting. Of course, moving point might be
inevitable if the buffer radically changes.
+@defvar inhibit-auto-revert-buffers
+When the current buffer is member of this variable (a list of buffers),
+auto-reverting is suppressed for that buffer. This is useful if serious
+changes are applied to that buffer which would be poisoned by an
+unexpected auto-revert. After the change is finished, the buffer shall
+be removed from @code{inhibit-auto-revert-buffers}.
+
+The check of membership in @code{inhibit-auto-revert-buffers} is applied
+prior to the call of @code{buffer-stale-function}; any heavy check in
+that function is avoided, therefore.
+
+If auto-reverting is triggered by file notification while
+@code{inhibit-auto-revert-buffers} prevents this, auto-revert will
+happen next time the buffer is polled for changes, unless
+@code{auto-revert-avoid-polling} is non-@code{nil}. @pxref{(emacs) Auto
+Revert}.
+@end defvar
+
+@defmac inhibit-auto-revert &rest body
+This macro adds the current buffer to
+@code{inhibit-auto-revert-buffers}, runs @var{body}, and removes the
+current buffer from @code{inhibit-auto-revert-buffers} afterwards.
+@end defmac
+
You should make sure that the @code{revert-buffer-function} does not
print messages that unnecessarily duplicate Auto Revert's own messages,
displayed if @code{auto-revert-verbose} is @code{t}, and effectively
^ permalink raw reply related [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-02-02 11:39 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-02-02 12:55 ` Tassilo Horn
2025-02-02 17:22 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 99+ messages in thread
From: Tassilo Horn @ 2025-02-02 12:55 UTC (permalink / raw)
To: Michael Albinus; +Cc: Michael Heerdegen, Eli Zaretskii, 75626-done
Michael Albinus <michael.albinus@gmx.de> writes:
>> Why is the macro inhibit-auto-revert defined in a progn? I think,
>> I've never seen that before.
>
> This is a trick to bring the defmacro body into loaddefs.el. See also
> the declaration of define-short-documentation-group, for example.
Interesting, I didn't know. Thanks!
>> And why does dired-buffer-stale-p check if the current dired buffer
>> is member of inhibit-auto-revert-buffers? Isn't the point to move
>> the allowance check from packages' buffer-stale-function to
>> auto-revert itself? In that case, the buffer-read-only check (set by
>> wdired-mode) should probably also be rewritten to add the currently
>> edited dired buffer to inhibit-auto-revert-buffers and to remove it
>> when wdired-mode is deactivated (wdired-finish-edit).
>
> Yes, I've moved the check of a buffer being member of
> inhibit-auto-revert-buffers to autorevert.el, see patch below. Thanks
> for the heads-up.
You're welcome.
>> Furthermore, the member check in auto-revert-buffer causes this
>> buffer to be removed from auto-revert-buffer-list meaning it will
>> never ever be reverted in the future, at least not by polling.
>
> Yes, and this is intended. We disable auto-reverting for a given
> time. With consequences.
That's the part I don't understand, yet. Auto-reverts are skipped by
auto-revert-handler now for buffers in inhibit-auto-revert-buffers.
That's what I had expected and did in my previous inhibit-auto-revert
patch, too.
But my reading of the code is that the polling timer calls
auto-revert-buffers -> auto-revert-buffer -> auto-revert-handler
where auto-revert-buffer now removes the inhibited buffer from
auto-revert-buffer-list. So in addition to skipping it in
auto-revert-handler this time, the future polling rounds won't see it
anymore, too, because auto-revert--buffer-candidates uses
auto-revert--polled-buffers which is basically auto-revert-buffer-list +
auto-revert-remaining-buffers, at least if global-auto-revert-mode isn't
used.
So when you say "we disable auto-reverting for a given time" where I
assume "given time" is not "forever", what am I missing? If anything, I
would expect that auto-revert-buffer pushes the inhibited buffer onto
auto-revert-remaining-buffers to prioritize it for next time.
Bye,
Tassilo
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-02-02 12:55 ` Tassilo Horn
@ 2025-02-02 17:22 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-02 19:10 ` Tassilo Horn
0 siblings, 1 reply; 99+ messages in thread
From: Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-02-02 17:22 UTC (permalink / raw)
To: Tassilo Horn; +Cc: Michael Heerdegen, Eli Zaretskii, 75626-done
[-- Attachment #1: Type: text/plain, Size: 1319 bytes --]
Tassilo Horn <tsdh@gnu.org> writes:
Hi Tassilo,
> That's the part I don't understand, yet. Auto-reverts are skipped by
> auto-revert-handler now for buffers in inhibit-auto-revert-buffers.
> That's what I had expected and did in my previous inhibit-auto-revert
> patch, too.
>
> But my reading of the code is that the polling timer calls
>
> auto-revert-buffers -> auto-revert-buffer -> auto-revert-handler
>
> where auto-revert-buffer now removes the inhibited buffer from
> auto-revert-buffer-list. So in addition to skipping it in
> auto-revert-handler this time, the future polling rounds won't see it
> anymore, too, because auto-revert--buffer-candidates uses
> auto-revert--polled-buffers which is basically auto-revert-buffer-list +
> auto-revert-remaining-buffers, at least if global-auto-revert-mode isn't
> used.
>
> So when you say "we disable auto-reverting for a given time" where I
> assume "given time" is not "forever", what am I missing? If anything, I
> would expect that auto-revert-buffer pushes the inhibited buffer onto
> auto-revert-remaining-buffers to prioritize it for next time.
Below is an updated patch for autorevert.el. I control this now via
auto-revert-active-p; no further need to check in auto-revert-buffer.
Could you, pls, test?
> Bye,
> Tassilo
Best regards, Michael.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 3102 bytes --]
diff --git a/lisp/autorevert.el b/lisp/autorevert.el
index 1dcfe8e911f..5acb1220471 100644
--- a/lisp/autorevert.el
+++ b/lisp/autorevert.el
@@ -774,9 +774,10 @@ auto-revert--end-lockout
(defun auto-revert-active-p ()
"Check if auto-revert is active in current buffer."
- (or auto-revert-mode
- auto-revert-tail-mode
- auto-revert--global-mode))
+ (and (or auto-revert-mode
+ auto-revert-tail-mode
+ auto-revert--global-mode)
+ (not (memq (current-buffer) inhibit-auto-revert-buffers))))
(defun auto-revert-handler ()
"Revert current buffer, if appropriate.
@@ -798,14 +799,17 @@ auto-revert-handler
(setq size
(file-attribute-size
(file-attributes buffer-file-name)))))
- (funcall (or buffer-stale-function
- #'buffer-stale--default-function)
- t)))
+ (and (not (memq (current-buffer)
+ inhibit-auto-revert-buffers))
+ (funcall (or buffer-stale-function
+ #'buffer-stale--default-function)
+ t))))
(and (or auto-revert-mode
global-auto-revert-non-file-buffers)
- (funcall (or buffer-stale-function
- #'buffer-stale--default-function)
- t))))
+ (and (not (memq (current-buffer) inhibit-auto-revert-buffers))
+ (funcall (or buffer-stale-function
+ #'buffer-stale--default-function)
+ t)))))
eob eoblist)
(setq auto-revert-notify-modified-p nil
auto-revert--last-time (current-time))
@@ -897,6 +901,31 @@ auto-revert--buffer-candidates
(push buf new)))
(nreverse (nconc new remaining))))
+;;;###autoload
+(progn
+ (defvar inhibit-auto-revert-buffers nil
+ "A list of buffers with suppressed auto-revert.")
+
+ (defmacro inhibit-auto-revert (&rest body)
+ "Deactivate auto-reverting of current buffer temporarily.
+Run BODY."
+ (declare (indent 0) (debug ((form body) body)))
+ `(progn
+ ;; Cleanup.
+ (dolist (buf inhibit-auto-revert-buffers)
+ (unless (buffer-live-p buf)
+ (setq inhibit-auto-revert-buffers
+ (delq buf inhibit-auto-revert-buffers))))
+ (let ((buf (and (not (memq (current-buffer) inhibit-auto-revert-buffers))
+ (current-buffer))))
+ (unwind-protect
+ (progn
+ (when buf (add-to-list 'inhibit-auto-revert-buffers buf))
+ ,@body)
+ (when buf
+ (setq inhibit-auto-revert-buffers
+ (delq buf inhibit-auto-revert-buffers))))))))
+
(defun auto-revert-buffer (buf)
"Revert a single buffer BUF.
^ permalink raw reply related [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-02-02 17:22 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-02-02 19:10 ` Tassilo Horn
2025-02-02 20:17 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 99+ messages in thread
From: Tassilo Horn @ 2025-02-02 19:10 UTC (permalink / raw)
To: Michael Albinus; +Cc: Michael Heerdegen, Eli Zaretskii, 75626-done
[-- Attachment #1: Type: text/plain, Size: 365 bytes --]
Michael Albinus <michael.albinus@gmx.de> writes:
Hi Michael,
> Below is an updated patch for autorevert.el. I control this now via
> auto-revert-active-p; no further need to check in auto-revert-buffer.
>
> Could you, pls, test?
Of course. It does not contain any changes to dired, so I've applied
the changes of your previous patch giving this complete patch:
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: auto-revert-and-dired.patch --]
[-- Type: text/x-patch, Size: 5973 bytes --]
diff --git a/lisp/autorevert.el b/lisp/autorevert.el
index 1dcfe8e911f..5acb1220471 100644
--- a/lisp/autorevert.el
+++ b/lisp/autorevert.el
@@ -774,9 +774,10 @@ auto-revert--end-lockout
(defun auto-revert-active-p ()
"Check if auto-revert is active in current buffer."
- (or auto-revert-mode
- auto-revert-tail-mode
- auto-revert--global-mode))
+ (and (or auto-revert-mode
+ auto-revert-tail-mode
+ auto-revert--global-mode)
+ (not (memq (current-buffer) inhibit-auto-revert-buffers))))
(defun auto-revert-handler ()
"Revert current buffer, if appropriate.
@@ -798,14 +799,17 @@ auto-revert-handler
(setq size
(file-attribute-size
(file-attributes buffer-file-name)))))
- (funcall (or buffer-stale-function
- #'buffer-stale--default-function)
- t)))
+ (and (not (memq (current-buffer)
+ inhibit-auto-revert-buffers))
+ (funcall (or buffer-stale-function
+ #'buffer-stale--default-function)
+ t))))
(and (or auto-revert-mode
global-auto-revert-non-file-buffers)
- (funcall (or buffer-stale-function
- #'buffer-stale--default-function)
- t))))
+ (and (not (memq (current-buffer) inhibit-auto-revert-buffers))
+ (funcall (or buffer-stale-function
+ #'buffer-stale--default-function)
+ t)))))
eob eoblist)
(setq auto-revert-notify-modified-p nil
auto-revert--last-time (current-time))
@@ -897,6 +901,31 @@ auto-revert--buffer-candidates
(push buf new)))
(nreverse (nconc new remaining))))
+;;;###autoload
+(progn
+ (defvar inhibit-auto-revert-buffers nil
+ "A list of buffers with suppressed auto-revert.")
+
+ (defmacro inhibit-auto-revert (&rest body)
+ "Deactivate auto-reverting of current buffer temporarily.
+Run BODY."
+ (declare (indent 0) (debug ((form body) body)))
+ `(progn
+ ;; Cleanup.
+ (dolist (buf inhibit-auto-revert-buffers)
+ (unless (buffer-live-p buf)
+ (setq inhibit-auto-revert-buffers
+ (delq buf inhibit-auto-revert-buffers))))
+ (let ((buf (and (not (memq (current-buffer) inhibit-auto-revert-buffers))
+ (current-buffer))))
+ (unwind-protect
+ (progn
+ (when buf (add-to-list 'inhibit-auto-revert-buffers buf))
+ ,@body)
+ (when buf
+ (setq inhibit-auto-revert-buffers
+ (delq buf inhibit-auto-revert-buffers))))))))
+
(defun auto-revert-buffer (buf)
"Revert a single buffer BUF.
diff --git a/lisp/dired.el b/lisp/dired.el
index 2eb6546107a..01621c9ea4e 100644
--- a/lisp/dired.el
+++ b/lisp/dired.el
@@ -944,9 +944,6 @@ dired-mark-if
""))))
(and (> count 0) count)))
-(defvar-local dired--inhibit-auto-revert nil
- "A non-nil value prevents `auto-revert-mode' from reverting the buffer.")
-
(defmacro dired-map-over-marks (body arg &optional show-progress
distinguish-one-marked)
"Eval BODY with point on each marked line. Return a list of BODY's results.
@@ -983,8 +980,8 @@ dired-map-over-marks
;;endless loop.
;;This warning should not apply any longer, sk 2-Sep-1991 14:10.
`(prog1
- (let ((dired--inhibit-auto-revert t)
- (inhibit-read-only t)
+ (inhibit-auto-revert
+ (let ((inhibit-read-only t)
case-fold-search found results)
(if (and ,arg (not (eq ,arg 'marked)))
(if (integerp ,arg)
@@ -1024,7 +1021,7 @@ dired-map-over-marks
(if found
results
(unless (eq ,arg 'marked)
- (list ,body))))))
+ (list ,body)))))))
;; save-excursion loses, again
(dired-move-to-filename)))
@@ -1294,12 +1291,6 @@ dired-buffer-stale-p
;; Do not auto-revert when the dired buffer can be currently
;; written by the user as in `wdired-mode'.
buffer-read-only
- ;; When a dired operation using dired-map-over-marks is in
- ;; progress, dired--inhibit-auto-revert is bound to some
- ;; non-nil value and we must not auto-revert because that could
- ;; change the order of files leading to skipping or
- ;; double-processing (see bug#75626).
- (not dired--inhibit-auto-revert)
(dired-directory-changed-p dirname))))
(defcustom dired-auto-revert-buffer nil
@@ -4089,10 +4080,10 @@ dired-internal-do-deletions
(while l
(goto-char (marker-position (cdr (car l))))
(dired-move-to-filename)
- (let ((inhibit-read-only t)
- ;; Temporarily prevent auto-revert while deleting
- ;; entry in the dired buffer (bug#71264).
- (dired--inhibit-auto-revert t))
+ ;; Temporarily prevent auto-revert while deleting entry in
+ ;; the dired buffer (bug#71264).
+ (inhibit-auto-revert
+ (let ((inhibit-read-only t))
(condition-case err
(let ((fn (car (car l))))
(dired-delete-file fn dired-recursive-deletes trash)
@@ -4108,7 +4099,7 @@ dired-internal-do-deletions
(quit (throw '--delete-cancel (message "OK, canceled")))
(error ;; catch errors from failed deletions
(dired-log "%s: %s\n" (car err) (error-message-string err))
- (setq failures (cons (car (car l)) failures)))))
+ (setq failures (cons (car (car l)) failures))))))
(setq l (cdr l)))
(if (not failures)
(progress-reporter-done progress-reporter)
[-- Attachment #3: Type: text/plain, Size: 659 bytes --]
And yes, it works. :-)
Side-note: at first, it did not work after applying the patch and
running "make" in the emacs directory (reproducibly!), a problem I've
had before somewhere up the thread. The original bug was there again.
I placed a watch on inhibit-auto-revert-buffers which revealed that it
was set by the computation for all marked files in order to present them
at the yes-or-no-p prompt. But it was not set during the actual
processing! I had to manually delete the dired and autorevert ELC files
and "make" again.
Does anyone have a clue why? Does a recompile of a changed file with
existing ELC not produce it from scratch?
Bye,
Tassilo
^ permalink raw reply related [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-02-02 19:10 ` Tassilo Horn
@ 2025-02-02 20:17 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-03 6:12 ` Tassilo Horn
2025-02-04 14:56 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 2 replies; 99+ messages in thread
From: Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-02-02 20:17 UTC (permalink / raw)
To: Tassilo Horn; +Cc: Michael Heerdegen, 75626, Eli Zaretskii
Tassilo Horn <tsdh@gnu.org> writes:
> Hi Michael,
Hi Tassilo,
>> Below is an updated patch for autorevert.el. I control this now via
>> auto-revert-active-p; no further need to check in auto-revert-buffer.
>>
>> Could you, pls, test?
>
> Of course. It does not contain any changes to dired, so I've applied
> the changes of your previous patch giving this complete patch:
>
> And yes, it works. :-)
Thanks. I'll polish the patch, and if nobody objects, I'll push it to
master in a couple of days.
> Side-note: at first, it did not work after applying the patch and
> running "make" in the emacs directory (reproducibly!), a problem I've
> had before somewhere up the thread. The original bug was there again.
> I placed a watch on inhibit-auto-revert-buffers which revealed that it
> was set by the computation for all marked files in order to present them
> at the yes-or-no-p prompt. But it was not set during the actual
> processing! I had to manually delete the dired and autorevert ELC files
> and "make" again.
>
> Does anyone have a clue why? Does a recompile of a changed file with
> existing ELC not produce it from scratch?
Usually, this is due to macro-expansion. If you change a macro, you must
also recompile the file(s) using the macro. IOW, removing dired.elc
prior compiling would have been sufficient.
> Bye,
> Tassilo
Best regrds, Michael.
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-02-02 20:17 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-02-03 6:12 ` Tassilo Horn
2025-02-03 7:07 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-04 14:56 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 1 reply; 99+ messages in thread
From: Tassilo Horn @ 2025-02-03 6:12 UTC (permalink / raw)
To: Michael Albinus; +Cc: Michael Heerdegen, 75626, Eli Zaretskii
Michael Albinus <michael.albinus@gmx.de> writes:
> Thanks. I'll polish the patch, and if nobody objects, I'll push it to
> master in a couple of days.
No objections from me. You are the master of auto-revert. ;-)
I'd argue that we also remove the buffer-read-only check from
dired-buffer-stale-p and use the new inhibit-auto-revert-buffers for
activating and deactivating wdired-mode but that can come afterwards.
>> Side-note: at first, it did not work after applying the patch and
>> running "make" in the emacs directory (reproducibly!), a problem I've
>> had before somewhere up the thread. The original bug was there
>> again. I placed a watch on inhibit-auto-revert-buffers which
>> revealed that it was set by the computation for all marked files in
>> order to present them at the yes-or-no-p prompt. But it was not set
>> during the actual processing! I had to manually delete the dired and
>> autorevert ELC files and "make" again.
>>
>> Does anyone have a clue why? Does a recompile of a changed file with
>> existing ELC not produce it from scratch?
>
> Usually, this is due to macro-expansion. If you change a macro, you
> must also recompile the file(s) using the macro. IOW, removing
> dired.elc prior compiling would have been sufficient.
Ah, now I understand. dired.el was changed and recompiled but
dired-do-compress lives in dired-aux.el which hasn't been changed but
needed recompiling because it uses the dired macro dired-map-over-marks.
So in fact, deleting dired-aux.elc was what has been needed.
Thanks,
Tassilo
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-02-03 6:12 ` Tassilo Horn
@ 2025-02-03 7:07 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 0 replies; 99+ messages in thread
From: Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-02-03 7:07 UTC (permalink / raw)
To: Tassilo Horn; +Cc: Michael Heerdegen, 75626, Eli Zaretskii
Tassilo Horn <tsdh@gnu.org> writes:
Hi Tassilo,
> I'd argue that we also remove the buffer-read-only check from
> dired-buffer-stale-p and use the new inhibit-auto-revert-buffers for
> activating and deactivating wdired-mode but that can come afterwards.
Sound reasonable.
> Thanks,
> Tassilo
Best regards, Michael.
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-02-02 20:17 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-03 6:12 ` Tassilo Horn
@ 2025-02-04 14:56 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-05 2:25 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 1 reply; 99+ messages in thread
From: Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-02-04 14:56 UTC (permalink / raw)
To: Tassilo Horn; +Cc: Michael Heerdegen, 75626, Eli Zaretskii
Michael Albinus <michael.albinus@gmx.de> writes:
Hi Tassilo,
> Thanks. I'll polish the patch, and if nobody objects, I'll push it to
> master in a couple of days.
Pushed to master.
Best regards, Michael.
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-02-04 14:56 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-02-05 2:25 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-05 8:51 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 99+ messages in thread
From: Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-02-05 2:25 UTC (permalink / raw)
To: Michael Albinus; +Cc: 75626, Eli Zaretskii, Tassilo Horn
Hello Michael,
> Michael Albinus <michael.albinus@gmx.de> writes:
>
> Hi Tassilo,
>
> > Thanks. I'll polish the patch, and if nobody objects, I'll push it to
> > master in a couple of days.
>
> Pushed to master.
Sorry for being late, have been a bit distracted. Allow only one
question please:
| + (defmacro inhibit-auto-revert (&rest body)
| + "Deactivate auto-reverting of current buffer temporarily.
| +Run BODY."
| + (declare (indent 0) (debug ((form body) body)))
What's the purpose of this debug spec - why not just "body"?
| + (let ((buf (and (not (memq (current-buffer) inhibit-auto-revert-buffers))
| + (current-buffer))))
| + (unwind-protect
| + (progn
| + (when buf (add-to-list 'inhibit-auto-revert-buffers buf))
| + ,@body)
I think at least in this part where body is inserted the variable BUF
should be uninterned for the obvious reason. Or at least have a more
obscure name.
Michael.
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-02-05 2:25 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-02-05 8:51 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-05 14:44 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 99+ messages in thread
From: Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-02-05 8:51 UTC (permalink / raw)
To: Michael Heerdegen; +Cc: 75626, Eli Zaretskii, Tassilo Horn
Michael Heerdegen <michael_heerdegen@web.de> writes:
> Hello Michael,
Hi Michael.
> Sorry for being late, have been a bit distracted. Allow only one
> question please:
>
> | + (defmacro inhibit-auto-revert (&rest body)
> | + "Deactivate auto-reverting of current buffer temporarily.
> | +Run BODY."
> | + (declare (indent 0) (debug ((form body) body)))
>
> What's the purpose of this debug spec - why not just "body"?
Cut'n'waste error. Thanks for the heads-up, I've fixed it.
> | + (let ((buf (and (not (memq (current-buffer) inhibit-auto-revert-buffers))
> | + (current-buffer))))
> | + (unwind-protect
> | + (progn
> | + (when buf (add-to-list 'inhibit-auto-revert-buffers buf))
> | + ,@body)
>
> I think at least in this part where body is inserted the variable BUF
> should be uninterned for the obvious reason. Or at least have a more
> obscure name.
Yes, I've seen such constructs somewhere else in Emacs' code. I don't
understand why a simple (lexical) let-binding of buf isn't
sufficient. The problem would exist for any macro. Could you pls show me
an example how it could go wrong?
(If you believe it is needed, you can just patch autorevert.el yourself,
with a comment in the code.)
> Michael.
Best regards, Michael.
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-02-05 8:51 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-02-05 14:44 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-05 16:22 ` Thierry Volpiatto
2025-02-06 16:00 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 2 replies; 99+ messages in thread
From: Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-02-05 14:44 UTC (permalink / raw)
To: Michael Albinus; +Cc: 75626, Eli Zaretskii, Tassilo Horn
Michael Albinus <michael.albinus@gmx.de> writes:
> Cut'n'waste error. Thanks for the heads-up, I've fixed it.
Thanks.
> > | + (let ((buf (and (not (memq (current-buffer)
> > | inhibit-auto-revert-buffers))
> > | + (current-buffer))))
> > | + (unwind-protect
> > | + (progn
> > | + (when buf (add-to-list 'inhibit-auto-revert-buffers buf))
> > | + ,@body)
> >
> > I think at least in this part where body is inserted the variable BUF
> > should be uninterned for the obvious reason. Or at least have a more
> > obscure name.
>
> Yes, I've seen such constructs somewhere else in Emacs' code. I don't
> understand why a simple (lexical) let-binding of buf isn't
> sufficient. The problem would exist for any macro. Could you pls show me
> an example how it could go wrong?
Have you ever read (info "(elisp) Surprising Local Vars") - and the whole
(info "(elisp) Problems with Macros") chapter? (If not, you should do...)
Short version: Lisp macro expansion is dumb ("unhygienic"): if your
macro uses a variable that accidentally has the same name as a variable
in the "inserted" code (like a BODY), when expanding the macro these
unrelated variables will become one and the same variable in the code
("variable" or "name clash") causing a variety of funny and unexpected
surprises that are weird and nasty to debug.
In case of `inhibit-auto-revert', the macro could interfere with a
variable named `buf' that may occur in BODY. A variable named `buf' may
already be introduced in the surrounding code, e.g.
#+begin_src emacs-lisp
(let ((buf (get-buffer "*scratch*")))
(inhibit-auto-revert
(setq-local this-buffers-friend buf)
(do-this-and-that...)))
#+end_src
The expansion would look like:
#+begin_src emacs-lisp
(let ((buf (get-buffer "*scratch*")))
...
(let ((buf (and (not (memq (current-buffer) inhibit-auto-revert-buffers))
(current-buffer))))
(unwind-protect
(progn
(if buf
(add-to-list 'inhibit-auto-revert-buffers buf))
(setq this-buffers-friend buf) ;; Ouch!! Refers to the wrong `buf'!
(do-this-and-that...))
...)))
#+end_src
> (If you believe it is needed, you can just patch autorevert.el yourself,
> with a comment in the code.)
If I didn't misunderstand and this was new to you - am I allowed to
suggest this as an exercise?
The idea for fixing is that the macro instead introduces a new
uninterned symbol instead of an interned one, and uses that in the
expansion (see manual): a new uninterned symbol can't clash with any
existing variable. `macroexpand' and `macroexpand-all' are your friend:
use these to see what you get. Later you can do that in your mind only.
If you don't do that _all_the_time_, you'll get crazy with this stuff.
Ok - was that understandable?
Thx,
Michael.
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-02-05 14:44 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-02-05 16:22 ` Thierry Volpiatto
2025-02-05 17:40 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-06 16:00 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 1 reply; 99+ messages in thread
From: Thierry Volpiatto @ 2025-02-05 16:22 UTC (permalink / raw)
To: 75626; +Cc: michael_heerdegen, eliz, michael.albinus, tsdh
Michael Heerdegen via "Bug reports for GNU Emacs, the Swiss army knife
of text editors" <bug-gnu-emacs@gnu.org> writes:
> Michael Albinus <michael.albinus@gmx.de> writes:
>
>> Cut'n'waste error. Thanks for the heads-up, I've fixed it.
>
> Thanks.
>
>
>> > | + (let ((buf (and (not (memq (current-buffer)
>> > | inhibit-auto-revert-buffers))
>> > | + (current-buffer))))
>> > | + (unwind-protect
>> > | + (progn
>> > | + (when buf (add-to-list 'inhibit-auto-revert-buffers buf))
>> > | + ,@body)
>> >
>> > I think at least in this part where body is inserted the variable BUF
>> > should be uninterned for the obvious reason. Or at least have a more
>> > obscure name.
>>
>> Yes, I've seen such constructs somewhere else in Emacs' code. I don't
>> understand why a simple (lexical) let-binding of buf isn't
>> sufficient. The problem would exist for any macro. Could you pls show me
>> an example how it could go wrong?
>
> Have you ever read (info "(elisp) Surprising Local Vars") - and the whole
> (info "(elisp) Problems with Macros") chapter? (If not, you should do...)
>
> Short version: Lisp macro expansion is dumb ("unhygienic"): if your
> macro uses a variable that accidentally has the same name as a variable
> in the "inserted" code (like a BODY), when expanding the macro these
> unrelated variables will become one and the same variable in the code
> ("variable" or "name clash") causing a variety of funny and unexpected
> surprises that are weird and nasty to debug.
>
> In case of `inhibit-auto-revert', the macro could interfere with a
> variable named `buf' that may occur in BODY. A variable named `buf' may
> already be introduced in the surrounding code, e.g.
>
> #+begin_src emacs-lisp
> (let ((buf (get-buffer "*scratch*")))
> (inhibit-auto-revert
> (setq-local this-buffers-friend buf)
> (do-this-and-that...)))
> #+end_src
>
>
> The expansion would look like:
>
> #+begin_src emacs-lisp
> (let ((buf (get-buffer "*scratch*")))
> ...
> (let ((buf (and (not (memq (current-buffer) inhibit-auto-revert-buffers))
> (current-buffer))))
> (unwind-protect
> (progn
> (if buf
> (add-to-list 'inhibit-auto-revert-buffers buf))
> (setq this-buffers-friend buf) ;; Ouch!! Refers to the wrong `buf'!
> (do-this-and-that...))
> ...)))
> #+end_src
>
>> (If you believe it is needed, you can just patch autorevert.el yourself,
>> with a comment in the code.)
>
> If I didn't misunderstand and this was new to you - am I allowed to
> suggest this as an exercise?
>
> The idea for fixing is that the macro instead introduces a new
> uninterned symbol instead of an interned one, and uses that in the
> expansion (see manual): a new uninterned symbol can't clash with any
> existing variable. `macroexpand' and `macroexpand-all' are your friend:
> use these to see what you get. Later you can do that in your mind only.
> If you don't do that _all_the_time_, you'll get crazy with this stuff.
AFAIU you can't do that all the time though, like if you want to
introduce a local var in your macro that may be used in body e.g. `it`
in cl-loop. Correct me if I am wrong.
--
Thierry
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-02-05 16:22 ` Thierry Volpiatto
@ 2025-02-05 17:40 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-05 19:48 ` Thierry Volpiatto
0 siblings, 1 reply; 99+ messages in thread
From: Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-02-05 17:40 UTC (permalink / raw)
To: Thierry Volpiatto; +Cc: 75626, michael.albinus, eliz, tsdh
Thierry Volpiatto <thievol@posteo.net> writes:
> > The idea for fixing is that the macro instead introduces a new
> > uninterned symbol instead of an interned one, and uses that in the
> > expansion (see manual): a new uninterned symbol can't clash with any
> > existing variable. `macroexpand' and `macroexpand-all' are your friend:
> > use these to see what you get. Later you can do that in your mind only.
> > If you don't do that _all_the_time_, you'll get crazy with this stuff.
>
> AFAIU you can't do that all the time though, like if you want to
> introduce a local var in your macro that may be used in body e.g. `it`
> in cl-loop. Correct me if I am wrong.
With "all the time" I meant "macroexpand little examples in your mind
all the time".
About what you hint at: yes of course, variables that are not just
additional helper variables but something that the macro officially
provides, or special variables the macro code intents to manipulate, are
"really meant" and no accidental clashes.
So nothing special here, no rocket science involved. But thanks for
preventing a possible misunderstanding.
Michael.
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-02-05 17:40 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-02-05 19:48 ` Thierry Volpiatto
0 siblings, 0 replies; 99+ messages in thread
From: Thierry Volpiatto @ 2025-02-05 19:48 UTC (permalink / raw)
To: Michael Heerdegen; +Cc: 75626, michael.albinus, tsdh, thievol, eliz
[-- Attachment #1: Type: text/plain, Size: 986 bytes --]
Michael Heerdegen <michael_heerdegen@web.de> writes:
> Thierry Volpiatto <thievol@posteo.net> writes:
>
>> > The idea for fixing is that the macro instead introduces a new
>> > uninterned symbol instead of an interned one, and uses that in the
>> > expansion (see manual): a new uninterned symbol can't clash with any
>> > existing variable. `macroexpand' and `macroexpand-all' are your friend:
>> > use these to see what you get. Later you can do that in your mind only.
>> > If you don't do that _all_the_time_, you'll get crazy with this stuff.
>>
>> AFAIU you can't do that all the time though, like if you want to
>> introduce a local var in your macro that may be used in body e.g. `it`
>> in cl-loop. Correct me if I am wrong.
>
> With "all the time" I meant "macroexpand little examples in your mind
> all the time".
Ah yes, I agree with this, sorry for my misunderstanding, I thought you
meant "always bind vars to uninterned symbols".
--
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]
^ permalink raw reply [flat|nested] 99+ messages in thread
* bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
2025-02-05 14:44 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-05 16:22 ` Thierry Volpiatto
@ 2025-02-06 16:00 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 0 replies; 99+ messages in thread
From: Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-02-06 16:00 UTC (permalink / raw)
To: Michael Heerdegen; +Cc: 75626, Eli Zaretskii, Tassilo Horn
Michael Heerdegen <michael_heerdegen@web.de> writes:
Hi Michael,
>> > I think at least in this part where body is inserted the variable BUF
>> > should be uninterned for the obvious reason. Or at least have a more
>> > obscure name.
>>
>> Yes, I've seen such constructs somewhere else in Emacs' code. I don't
>> understand why a simple (lexical) let-binding of buf isn't
>> sufficient. The problem would exist for any macro. Could you pls show me
>> an example how it could go wrong?
>
> Have you ever read (info "(elisp) Surprising Local Vars") - and the whole
> (info "(elisp) Problems with Macros") chapter? (If not, you should do...)
I did. But I've never thought about consequences for macro
expansion. Finally, I've decided for "a more obscure name".
> Thx,
>
> Michael.
Best regards, Michael.
^ permalink raw reply [flat|nested] 99+ messages in thread
end of thread, other threads:[~2025-02-06 16:00 UTC | newest]
Thread overview: 99+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-01-17 7:42 bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled Tassilo Horn
2025-01-17 8:32 ` Eli Zaretskii
2025-01-17 9:04 ` Tassilo Horn
2025-01-17 12:17 ` Eli Zaretskii
2025-01-17 13:03 ` Tassilo Horn
2025-01-17 13:26 ` Eli Zaretskii
2025-01-17 14:13 ` Tassilo Horn
2025-01-17 19:38 ` Eli Zaretskii
2025-01-17 21:38 ` Tassilo Horn
2025-01-17 23:36 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-18 8:42 ` Tassilo Horn
2025-01-18 11:17 ` Ship Mints
2025-01-18 23:19 ` Tassilo Horn
2025-01-18 21:17 ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-18 23:43 ` Tassilo Horn
2025-01-20 0:24 ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-20 1:13 ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-19 2:05 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-19 10:33 ` Tassilo Horn
2025-01-20 1:51 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-20 3:48 ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors
[not found] ` <87ldv6j9lv.fsf@gnu.org>
2025-01-20 17:32 ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-20 19:13 ` Eli Zaretskii
2025-01-20 19:20 ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors
[not found] ` <87frlej8ad.fsf@gnu.org>
2025-01-20 17:32 ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-20 18:01 ` Tassilo Horn
2025-01-20 18:28 ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-20 19:39 ` Tassilo Horn
2025-01-20 22:32 ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-20 19:15 ` Eli Zaretskii
2025-01-20 19:31 ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-20 19:44 ` bug#75626: " Eli Zaretskii
2025-01-20 22:32 ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-21 7:26 ` Tassilo Horn
[not found] ` <86ikq97ip0.fsf@gnu.org>
[not found] ` <87a5blhb24.fsf@web.de>
[not found] ` <875xm9havc.fsf@web.de>
[not found] ` <864j1t7gth.fsf@gnu.org>
[not found] ` <87wmepfuxp.fsf@web.de>
2025-01-20 16:49 ` Eli Zaretskii
2025-01-20 16:55 ` Tassilo Horn
2025-01-20 17:08 ` Eli Zaretskii
2025-01-20 17:19 ` Tassilo Horn
2025-01-20 19:07 ` Eli Zaretskii
2025-01-20 20:05 ` Tassilo Horn
2025-01-21 0:36 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-21 12:38 ` Eli Zaretskii
2025-01-21 14:13 ` Eli Zaretskii
2025-01-21 14:36 ` Tassilo Horn
2025-01-21 15:13 ` Rudolf Schlatte
2025-01-21 20:18 ` Tassilo Horn
2025-01-21 20:26 ` Ship Mints
2025-01-22 7:31 ` Tassilo Horn
2025-01-22 0:21 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-22 8:05 ` Tassilo Horn
2025-01-23 3:25 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-23 6:26 ` Tassilo Horn
2025-01-23 9:13 ` Eli Zaretskii
2025-01-23 23:33 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-24 0:59 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-24 6:24 ` Tassilo Horn
2025-01-24 23:26 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-24 8:02 ` Eli Zaretskii
2025-01-24 23:44 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-25 9:04 ` Tassilo Horn
2025-01-25 13:04 ` Eli Zaretskii
2025-01-26 8:50 ` Tassilo Horn
2025-01-27 0:53 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-27 6:10 ` Tassilo Horn
2025-01-27 8:27 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-27 13:17 ` Tassilo Horn
2025-01-28 1:07 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-28 19:39 ` Tassilo Horn
2025-01-28 23:58 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-31 6:39 ` Tassilo Horn
2025-02-01 0:18 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-01 9:40 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-01 21:50 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-02 9:31 ` Tassilo Horn
2025-02-02 10:10 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-02 10:35 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-02 11:14 ` Tassilo Horn
2025-02-02 11:41 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-02 12:30 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-02 11:15 ` Tassilo Horn
2025-02-02 11:43 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-02 10:05 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-02 11:10 ` Tassilo Horn
2025-02-02 11:39 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-02 12:55 ` Tassilo Horn
2025-02-02 17:22 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-02 19:10 ` Tassilo Horn
2025-02-02 20:17 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-03 6:12 ` Tassilo Horn
2025-02-03 7:07 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-04 14:56 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-05 2:25 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-05 8:51 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-05 14:44 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-05 16:22 ` Thierry Volpiatto
2025-02-05 17:40 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-05 19:48 ` Thierry Volpiatto
2025-02-06 16:00 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-21 12:34 ` Eli Zaretskii
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.