GNU bug report logs -
#34765
26.1; with-temp-buffer should not run buffer-list-update-hook
Previous Next
Reported by: Alexander Miller <alexanderm <at> web.de>
Date: Tue, 5 Mar 2019 22:58:02 UTC
Severity: normal
Tags: fixed
Found in version 26.1
Fixed in version 28.1
Done: "Basil L. Contovounesios" <contovob <at> tcd.ie>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 34765 in the body.
You can then email your comments to 34765 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Tue, 05 Mar 2019 22:58:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Alexander Miller <alexanderm <at> web.de>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Tue, 05 Mar 2019 22:58:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
To quote from the documentation of select-window:
Selections that "really count" are those
causing a visible change in the next redisplay of WINDOW’s frame and
should be always recorded. So if you think of running a function each
time a window gets selected put it on ‘buffer-list-update-hook’.
A temporary buffer hardly fits these criteria. The problem is not just
theoretical either. I have now run multiple times into situations where
use of a temp buffer caused a feedback loop that makes
buffer-list-update-hook fire permanently. For example a function called
by buffer-list-update-hook uses with-selected-window, this causes a
recalculation of the frame title, that calls format-spec, which uses a
temp-buffer and we are back to step one. Granted this case is very
specific to spacemacs and I am unable to reproduce it from emacs -q
(with-selected-window does not recalculate the frame title here), but
this is already the second time I've run into this (first time it was
magit).
So yeah, with-temp-buffer correction aside, if you have any advice how
to avoid the issue on my end without going back to advising
select-window that'd be great.
In GNU Emacs 26.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.30)
of 2018-07-05 built on juergen
Windowing system distributor 'The X.Org Foundation', version 11.0.12003000
Recent messages:
eval((spacemacs/title-prepare "%I@%SXXX"))
redisplay_internal\ \(C\ function\)()
spacemacs/title-prepare
Mark set
Mark saved where search started
Quit [2 times]
Mark saved where search started
uncompressing format-spec.el.gz...done
Note: file is write protected
Configured using:
'configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
--localstatedir=/var --with-x-toolkit=gtk3 --with-xft --with-modules
'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong
-fno-plt' CPPFLAGS=-D_FORTIFY_SOURCE=2
LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now'
Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS NOTIFY
ACL GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS
GTK3 X11 MODULES THREADS LIBSYSTEMD LCMS2
Important settings:
value of $LC_COLLATE: en_GB.UTF-8
value of $LANG: en_GB.UTF-8
locale-coding-system: utf-8-unix
Major mode: Emacs-Lisp
Minor modes in effect:
global-mu4e-conversation-mode: t
mu4e-conversation-mode: t
global-magit-file-mode: t
magit-file-mode: t
global-git-commit-mode: t
async-bytecomp-package-mode: t
framey-mode: t
helm-descbinds-mode: t
helm-mode: t
helm-flx-mode: t
global-evil-surround-mode: t
evil-surround-mode: t
recentf-mode: t
diff-auto-refine-mode: t
treemacs-filewatch-mode: t
treemacs-git-mode: deferred
treemacs-fringe-indicator-mode: t
evil-escape-mode: t
global-display-line-numbers-mode: t
display-line-numbers-mode: t
global-git-gutter-mode: t
git-gutter-mode: t
company-flx-mode: t
global-company-mode: t
company-mode: t
auto-compile-mode: t
elisp-slime-nav-mode: t
rainbow-mode: t
goto-address-prog-mode: t
bug-reference-prog-mode: t
flycheck-pos-tip-mode: t
global-flycheck-mode: t
flycheck-mode: t
yas-global-mode: t
yas-minor-mode: t
rainbow-delimiters-mode: t
eros-mode: t
global-subword-mode: t
subword-mode: t
eldoc-in-minibuffer-mode: t
show-smartparens-global-mode: t
show-smartparens-mode: t
smartparens-mode: t
winum-mode: t
shackle-mode: t
eyebrowse-mode: t
evil-goggles-mode: t
winner-mode: t
save-place-mode: t
savehist-mode: t
which-key-mode: t
override-global-mode: t
global-undo-tree-mode: t
undo-tree-mode: t
shell-dirtrack-mode: t
evil-mode: t
evil-local-mode: t
spacemacs-leader-override-mode: t
global-spacemacs-leader-override-mode: t
xterm-mouse-mode: t
global-auto-revert-mode: t
ido-vertical-mode: t
global-page-break-lines-mode: t
page-break-lines-mode: t
global-eldoc-mode: t
eldoc-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
prettify-symbols-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
column-number-mode: t
line-number-mode: t
transient-mark-mode: t
hs-minor-mode: t
Load-path shadows:
/home/a/.emacs.d/elpa/26.1/develop/lv-20181110.1740/lv hides
/home/a/.emacs.d/elpa/26.1/develop/hydra-20181128.1716/lv
/home/a/.emacs.d/elpa/26.1/develop/ht-20181216.1137/ht hides
/home/a/.emacs.d/core/libs/ht
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ob-screen
hides /usr/share/emacs/26.1/lisp/org/ob-screen
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/org-id
hides /usr/share/emacs/26.1/lisp/org/org-id
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ob-sass
hides /usr/share/emacs/26.1/lisp/org/ob-sass
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ob-R hides
/usr/share/emacs/26.1/lisp/org/ob-R
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/org-inlinetask
hides /usr/share/emacs/26.1/lisp/org/org-inlinetask
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ob-dot
hides /usr/share/emacs/26.1/lisp/org/ob-dot
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ox-texinfo
hides /usr/share/emacs/26.1/lisp/org/ox-texinfo
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ob-asymptote
hides /usr/share/emacs/26.1/lisp/org/ob-asymptote
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/org-indent
hides /usr/share/emacs/26.1/lisp/org/org-indent
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ob-shell
hides /usr/share/emacs/26.1/lisp/org/ob-shell
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ob-C hides
/usr/share/emacs/26.1/lisp/org/ob-C
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ob-lilypond
hides /usr/share/emacs/26.1/lisp/org/ob-lilypond
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ob-eval
hides /usr/share/emacs/26.1/lisp/org/ob-eval
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ob-comint
hides /usr/share/emacs/26.1/lisp/org/ob-comint
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ob-perl
hides /usr/share/emacs/26.1/lisp/org/ob-perl
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/org-capture
hides /usr/share/emacs/26.1/lisp/org/org-capture
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ob-clojure
hides /usr/share/emacs/26.1/lisp/org/ob-clojure
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ob-ebnf
hides /usr/share/emacs/26.1/lisp/org/ob-ebnf
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/org-clock
hides /usr/share/emacs/26.1/lisp/org/org-clock
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ob-latex
hides /usr/share/emacs/26.1/lisp/org/ob-latex
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ob-calc
hides /usr/share/emacs/26.1/lisp/org/ob-calc
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/org-pcomplete
hides /usr/share/emacs/26.1/lisp/org/org-pcomplete
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/org-macro
hides /usr/share/emacs/26.1/lisp/org/org-macro
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/org-footnote
hides /usr/share/emacs/26.1/lisp/org/org-footnote
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/org-datetree
hides /usr/share/emacs/26.1/lisp/org/org-datetree
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ob hides
/usr/share/emacs/26.1/lisp/org/ob
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ox-org
hides /usr/share/emacs/26.1/lisp/org/ox-org
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ox-beamer
hides /usr/share/emacs/26.1/lisp/org/ox-beamer
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/org-plot
hides /usr/share/emacs/26.1/lisp/org/org-plot
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ox-md hides
/usr/share/emacs/26.1/lisp/org/ox-md
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/org-timer
hides /usr/share/emacs/26.1/lisp/org/org-timer
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ob-picolisp
hides /usr/share/emacs/26.1/lisp/org/ob-picolisp
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ob-ditaa
hides /usr/share/emacs/26.1/lisp/org/ob-ditaa
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/org-eshell
hides /usr/share/emacs/26.1/lisp/org/org-eshell
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ob-tangle
hides /usr/share/emacs/26.1/lisp/org/ob-tangle
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/org-gnus
hides /usr/share/emacs/26.1/lisp/org/org-gnus
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ox-icalendar
hides /usr/share/emacs/26.1/lisp/org/ox-icalendar
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ob-forth
hides /usr/share/emacs/26.1/lisp/org/ob-forth
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ob-css
hides /usr/share/emacs/26.1/lisp/org/ob-css
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ob-ref
hides /usr/share/emacs/26.1/lisp/org/ob-ref
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ob-sed
hides /usr/share/emacs/26.1/lisp/org/ob-sed
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ob-J hides
/usr/share/emacs/26.1/lisp/org/ob-J
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/org-table
hides /usr/share/emacs/26.1/lisp/org/org-table
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ob-plantuml
hides /usr/share/emacs/26.1/lisp/org/ob-plantuml
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/org-compat
hides /usr/share/emacs/26.1/lisp/org/org-compat
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/org hides
/usr/share/emacs/26.1/lisp/org/org
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/org-element
hides /usr/share/emacs/26.1/lisp/org/org-element
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/org-bibtex
hides /usr/share/emacs/26.1/lisp/org/org-bibtex
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ob-lisp
hides /usr/share/emacs/26.1/lisp/org/ob-lisp
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ob-python
hides /usr/share/emacs/26.1/lisp/org/ob-python
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/org-protocol
hides /usr/share/emacs/26.1/lisp/org/org-protocol
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ob-java
hides /usr/share/emacs/26.1/lisp/org/ob-java
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ox hides
/usr/share/emacs/26.1/lisp/org/ox
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/org-entities
hides /usr/share/emacs/26.1/lisp/org/org-entities
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ob-hledger
hides /usr/share/emacs/26.1/lisp/org/ob-hledger
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/org-macs
hides /usr/share/emacs/26.1/lisp/org/org-macs
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ob-sql
hides /usr/share/emacs/26.1/lisp/org/ob-sql
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/org-irc
hides /usr/share/emacs/26.1/lisp/org/org-irc
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/org-mouse
hides /usr/share/emacs/26.1/lisp/org/org-mouse
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ob-core
hides /usr/share/emacs/26.1/lisp/org/ob-core
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ob-matlab
hides /usr/share/emacs/26.1/lisp/org/ob-matlab
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/org-crypt
hides /usr/share/emacs/26.1/lisp/org/org-crypt
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ob-table
hides /usr/share/emacs/26.1/lisp/org/ob-table
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ob-scheme
hides /usr/share/emacs/26.1/lisp/org/ob-scheme
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/org-bbdb
hides /usr/share/emacs/26.1/lisp/org/org-bbdb
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/org-habit
hides /usr/share/emacs/26.1/lisp/org/org-habit
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/org-mhe
hides /usr/share/emacs/26.1/lisp/org/org-mhe
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ob-octave
hides /usr/share/emacs/26.1/lisp/org/ob-octave
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ob-org
hides /usr/share/emacs/26.1/lisp/org/ob-org
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/org-rmail
hides /usr/share/emacs/26.1/lisp/org/org-rmail
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ob-maxima
hides /usr/share/emacs/26.1/lisp/org/ob-maxima
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ox-ascii
hides /usr/share/emacs/26.1/lisp/org/ox-ascii
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ob-exp
hides /usr/share/emacs/26.1/lisp/org/ob-exp
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/org-version
hides /usr/share/emacs/26.1/lisp/org/org-version
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ob-io hides
/usr/share/emacs/26.1/lisp/org/ob-io
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/org-agenda
hides /usr/share/emacs/26.1/lisp/org/org-agenda
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ob-abc
hides /usr/share/emacs/26.1/lisp/org/ob-abc
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ob-makefile
hides /usr/share/emacs/26.1/lisp/org/ob-makefile
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/org-lint
hides /usr/share/emacs/26.1/lisp/org/org-lint
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ob-js hides
/usr/share/emacs/26.1/lisp/org/ob-js
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/org-loaddefs
hides /usr/share/emacs/26.1/lisp/org/org-loaddefs
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ox-man
hides /usr/share/emacs/26.1/lisp/org/ox-man
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ob-ruby
hides /usr/share/emacs/26.1/lisp/org/ob-ruby
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ob-awk
hides /usr/share/emacs/26.1/lisp/org/ob-awk
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/org-duration
hides /usr/share/emacs/26.1/lisp/org/org-duration
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ox-odt
hides /usr/share/emacs/26.1/lisp/org/ox-odt
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ob-mscgen
hides /usr/share/emacs/26.1/lisp/org/ob-mscgen
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ob-keys
hides /usr/share/emacs/26.1/lisp/org/ob-keys
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/org-archive
hides /usr/share/emacs/26.1/lisp/org/org-archive
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ob-gnuplot
hides /usr/share/emacs/26.1/lisp/org/ob-gnuplot
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ob-stan
hides /usr/share/emacs/26.1/lisp/org/ob-stan
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/org-w3m
hides /usr/share/emacs/26.1/lisp/org/org-w3m
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/org-colview
hides /usr/share/emacs/26.1/lisp/org/org-colview
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ox-html
hides /usr/share/emacs/26.1/lisp/org/ox-html
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ob-fortran
hides /usr/share/emacs/26.1/lisp/org/ob-fortran
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ob-groovy
hides /usr/share/emacs/26.1/lisp/org/ob-groovy
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/org-list
hides /usr/share/emacs/26.1/lisp/org/org-list
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/org-faces
hides /usr/share/emacs/26.1/lisp/org/org-faces
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ob-lob
hides /usr/share/emacs/26.1/lisp/org/ob-lob
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/org-eww
hides /usr/share/emacs/26.1/lisp/org/org-eww
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ob-lua
hides /usr/share/emacs/26.1/lisp/org/ob-lua
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/org-feed
hides /usr/share/emacs/26.1/lisp/org/org-feed
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ob-sqlite
hides /usr/share/emacs/26.1/lisp/org/ob-sqlite
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ob-haskell
hides /usr/share/emacs/26.1/lisp/org/ob-haskell
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/org-src
hides /usr/share/emacs/26.1/lisp/org/org-src
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/org-install
hides /usr/share/emacs/26.1/lisp/org/org-install
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ob-emacs-lisp
hides /usr/share/emacs/26.1/lisp/org/ob-emacs-lisp
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ob-shen
hides /usr/share/emacs/26.1/lisp/org/ob-shen
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ox-latex
hides /usr/share/emacs/26.1/lisp/org/ox-latex
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/org-mobile
hides /usr/share/emacs/26.1/lisp/org/org-mobile
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ob-processing
hides /usr/share/emacs/26.1/lisp/org/ob-processing
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/org-attach
hides /usr/share/emacs/26.1/lisp/org/org-attach
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ob-ledger
hides /usr/share/emacs/26.1/lisp/org/ob-ledger
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/org-ctags
hides /usr/share/emacs/26.1/lisp/org/org-ctags
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ox-publish
hides /usr/share/emacs/26.1/lisp/org/ox-publish
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ob-ocaml
hides /usr/share/emacs/26.1/lisp/org/ob-ocaml
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ob-vala
hides /usr/share/emacs/26.1/lisp/org/ob-vala
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/org-info
hides /usr/share/emacs/26.1/lisp/org/org-info
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/org-docview
hides /usr/share/emacs/26.1/lisp/org/org-docview
/home/a/.emacs.d/elpa/26.1/develop/org-plus-contrib-20181230/ob-coq
hides /usr/share/emacs/26.1/lisp/org/ob-coq
Features:
(shadow sort mail-extr emacsbug helm-command evil-nerd-commenter
evil-nerd-commenter-operator evil-nerd-commenter-sdk smartparens-html
sgml-mode helm-xref semantic/symref/grep grep semantic/symref helm-ag
helm-elisp helm-eval org-indent org-table company-shell fish-mode
org-clock diary-lib diary-loaddefs cal-iso vc-mtn vc-hg org-eldoc
ob-python ob-shell org-bullets org-download toc-org org-eww org-rmail
org-mhe org-irc org-info org-gnus nnir gnus-sum gnus-group gnus-undo
gnus-start gnus-cloud nnimap nnmail mail-source utf7 netrc nnoo
gnus-spec gnus-int gnus-range gnus-win gnus nnheader org-docview
org-bibtex bibtex org-bbdb org-w3m smartparens-org org-habit
german-holidays org-agenda org-mu4e mu4e-conversation shr svg dom
gnus-dired mu4e desktop frameset mu4e-speedbar mu4e-main mu4e-view
mu4e-headers mu4e-compose mu4e-context mu4e-draft mu4e-actions rfc2368
smtpmail sendmail mu4e-mark mu4e-message flow-fill html2text mu4e-proc
mu4e-utils doc-view jka-compr image-mode mu4e-lists mu4e-vars mu4e-meta
orgit org-element avl-tree generator org ob ob-tangle ob-ref ob-lob
ob-table ob-exp org-macro org-footnote org-src ob-comint ob-keys
org-pcomplete org-list org-faces org-entities org-version ob-emacs-lisp
ob-core ob-eval org-compat org-macs org-loaddefs cal-menu calendar
cal-loaddefs swiper ivy delsel colir ivy-overlay tabify debug macrostep
semantic/find helm-semantic helm-imenu semantic/util-modes semantic/util
semantic semantic/tag semantic/lex semantic/fw mode-local cedet mwim
eieio-opt speedbar sb-image ezimage dframe face-remap gravatar url-cache
ffap magit-gitflow treemacs-magit evil-magit git-rebase forge-list
forge-commands forge-semi forge-bitbucket buck forge-gogs gogs
forge-gitea gtea forge-gitlab glab forge-github ghub-graphql treepy
graphql ghub let-alist forge-notify forge-revnote forge-pullreq
forge-issue forge-topic forge-post forge-repo forge forge-core forge-db
closql emacsql-sqlite emacsql emacsql-compiler magit-bookmark
magit-submodule magit-obsolete magit-popup magit-blame magit-stash
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 magit-diff
smerge-mode magit-core magit-autorevert magit-margin magit-transient
magit-process magit-mode transient git-commit magit-git magit-section
magit-utils crm log-edit message rfc822 mml mml-sec epa gnus-util rmail
rmail-loaddefs mailabbrev mail-utils gmm-utils mailheader pcvs-util
add-log with-editor async-bytecomp flx dired dired-loaddefs helm-x-files
helm-for-files helm-bookmark helm-adaptive helm-info helm-external
helm-net browse-url xml framey helm-descbinds helm-mode helm-files
helm-buffers helm-tags helm-locate helm-grep helm-regexp helm-utils
helm-help helm-types helm-flx helm helm-source helm-multi-match helm-lib
async cl-print evil-surround edebug lsp-treemacs recentf vc-bzr vc-src
vc-sccs vc-svn vc-cvs vc-rcs vc vc-dispatcher company-lsp importmagic
epc ctable concurrent deferred flycheck-rust lsp-ui-flycheck lsp-ui
lsp-ui-doc smartparens-markdown markdown-mode lsp-ui-imenu lsp-ui-peek
lsp-ui-sideline view lsp-clients dash-functional lsp lsp-mode
tree-widget spinner network-stream starttls em-glob esh-util
flymake-proc flymake hi-lock evil-matchit evil-matchit-sdk
smartparens-python python tramp-sh tramp tramp-compat tramp-loaddefs
trampver ucs-normalize parse-time vc-git diff-mode treemacs-evil
treemacs treemacs-compatibility treemacs-mode treemacs-interface
treemacs-extensions treemacs-persistence treemacs-mouse-interface
treemacs-tag-follow-mode treemacs-filewatch-mode treemacs-tags imenu
treemacs-follow-mode treemacs-rendering treemacs-async treemacs-faces
treemacs-icons treemacs-workspaces treemacs-dom treemacs-visuals
treemacs-fringe-indicator treemacs-impl treemacs-macros pfuture
ace-window avy treemacs-customization bookmark pp evil-escape
display-line-numbers git-gutter-fringe fringe-helper git-gutter
company-flx company-files company-keywords company-etags company-gtags
company-template company-dabbrev-code company-dabbrev company-yasnippet
company-capf company-quickhelp company overseer pkg-info url-http tls
gnutls url url-proxy url-privacy url-expand url-methods url-history
mailcap url-auth url-cookie url-domsuf url-util url-gw nsm rmc puny epl
compile auto-compile packed elisp-slime-nav etags xref rainbow-mode
goto-addr bug-reference flycheck-pos-tip pos-tip flycheck-ledger
flycheck json map find-func hideshow yasnippet-snippets yasnippet
rainbow-delimiters elec-pair evil-cleverparens
evil-cleverparens-text-objects evil-cleverparens-util paredit eros
cap-words superword subword doom-modeline doom-modeline-segments
doom-modeline-env doom-modeline-core project shrink-path eldoc-eval
all-the-icons all-the-icons-faces data-material data-weathericons
data-octicons data-fileicons data-faicons data-alltheicons memoize
inline powerline powerline-separators color powerline-themes
smartparens-config smartparens-text smartparens winum shackle trace
eyebrowse evil-goggles pulse f s dash server winner xterm-color
saveplace savehist noutline outline gh-common marshal hybrid-mode
evil-evilified-state which-key use-package use-package-ensure
use-package-delight use-package-diminish use-package-bind-key bind-key
use-package-core hydra lv cus-edit cus-start cus-load evil
evil-integration undo-tree diff evil-maps evil-commands reveal flyspell
ispell evil-jumps evil-command-window evil-types evil-search evil-ex
shell pcomplete comint ansi-color evil-macros evil-repeat evil-states
evil-core evil-common windmove thingatpt rect evil-digraphs evil-vars
ring bind-map quelpa mm-decode mm-bodies mm-encode mail-parse rfc2231
rfc2047 rfc2045%
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Wed, 06 Mar 2019 09:40:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 34765 <at> debbugs.gnu.org (full text, mbox):
> To quote from the documentation of select-window:
>
> Selections that "really count" are those
> causing a visible change in the next redisplay of WINDOW’s frame and
> should be always recorded. So if you think of running a function each
> time a window gets selected put it on ‘buffer-list-update-hook’.
>
> A temporary buffer hardly fits these criteria.
You're probably right but there's not much we can do in this regard.
When you show a temporary buffer and temporarily show another buffer
in the same window, there must be a way to show the temporary buffer
again. That's why we have to run 'buffer-list-update-hook' for them.
> The problem is not just
> theoretical either. I have now run multiple times into situations where
> use of a temp buffer caused a feedback loop that makes
> buffer-list-update-hook fire permanently. For example a function called
> by buffer-list-update-hook uses with-selected-window, this causes a
> recalculation of the frame title, that calls format-spec, which uses a
> temp-buffer and we are back to step one. Granted this case is very
> specific to spacemacs and I am unable to reproduce it from emacs -q
> (with-selected-window does not recalculate the frame title here), but
> this is already the second time I've run into this
'with-selected-window' calls 'select-window' with NORECORD non-nil, so
this should not be the culprit. I'm afraid you have to dig further to
find out how 'buffer-list-update-hook' precisely gets called here.
> (first time it was
> magit).
What was the issue there?
> So yeah, with-temp-buffer correction aside, if you have any advice how
> to avoid the issue on my end without going back to advising
> select-window that'd be great.
Emacs 27 now has 'window-selection-change-functions', strongly tied to
redisplay and triggering only when the window selection has changed
since last redisplay. Maybe you could try that.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Wed, 06 Mar 2019 11:30:03 GMT)
Full text and
rfc822 format available.
Message #11 received at 34765 <at> debbugs.gnu.org (full text, mbox):
> When you show a temporary buffer and temporarily show another
> buffer in the same window, there must be a way to show the temporary
> buffer again.
I do no understand the use-case you have in mind here. with-temp-buffer
serves to create a short-lived temporary buffer that is quickly disposed
of again. When would such a buffer be shown anywhere?
> I'm afraid you have to dig further to find out how
> 'buffer-list-update-hook' precisely gets called here.
Did that, turns out it's down to mode-line packages, both powerline and
doom-modeline are advising select-window. I'll create PRs for both.
> What was the issue there?
Same feedback loop as described above, except it would only happen
when a region was active in magit's status buffer. I had tracked
the cause to a temp buffer deep inside magit's internals. Here's the
github link:
https://github.com/magit/magit/issues/3738#issuecomment-464520582
> Emacs 27 now has 'window-selection-change-functions', strongly
> tied to redisplay and triggering only when the window selection has
> changed since last redisplay. Maybe you could try that.
This problem occurs in my treemacs package, so I cannot use a solution
provided by a bleeding edge release, my modus operandi is to support the
last 2 versions of emacs, so 25 and 26 (since stable distros like debian
still use emacs 25). At any rate I have found the culprit in those modeline
packages, so that point is solved.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Wed, 06 Mar 2019 14:14:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 34765 <at> debbugs.gnu.org (full text, mbox):
> I do no understand the use-case you have in mind here. with-temp-buffer
> serves to create a short-lived temporary buffer that is quickly disposed
> of again. When would such a buffer be shown anywhere?
I confused this 'with-output-to-temp-buffer'. Maybe we should indeed
rebind 'buffer-list-update-hook' around the 'generate-new-buffer' and
'kill-buffer' calls of 'with-temp-buffer'.
> > I'm afraid you have to dig further to find out how
> > 'buffer-list-update-hook' precisely gets called here.
>
> Did that, turns out it's down to mode-line packages, both powerline and
> doom-modeline are advising select-window.
And do not preserve NORECORD?
> I'll create PRs for both.
>
> > What was the issue there?
>
> Same feedback loop as described above, except it would only happen
> when a region was active in magit's status buffer. I had tracked
> the cause to a temp buffer deep inside magit's internals. Here's the
> github link:
> https://github.com/magit/magit/issues/3738#issuecomment-464520582
Maybe magit should simply try to reuse the same temporary buffer
instead of recreating it excessively. Creating/killing temporary
buffers does not come without some overhead.
> > Emacs 27 now has 'window-selection-change-functions', strongly
> > tied to redisplay and triggering only when the window selection has
> > changed since last redisplay. Maybe you could try that.
>
> This problem occurs in my treemacs package, so I cannot use a solution
> provided by a bleeding edge release, my modus operandi is to support the
> last 2 versions of emacs, so 25 and 26 (since stable distros like debian
> still use emacs 25). At any rate I have found the culprit in those modeline
> packages, so that point is solved.
I see. But please try 'window-selection-change-functions' sooner or
later so we know whether it fixes these problems.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Wed, 06 Mar 2019 15:42:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 34765 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 06 Mar 2019 15:13:37 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> Cc: 34765 <at> debbugs.gnu.org
>
> Maybe we should indeed rebind 'buffer-list-update-hook' around the
> 'generate-new-buffer' and 'kill-buffer' calls of 'with-temp-buffer'.
Wouldn't that be a backward-incompatible change? How long did we call
that hook for temporary buffers? Also, can generate-new-buffer and/or
kill-buffer run some hooks which might modify other, non-temporary
buffers?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Wed, 06 Mar 2019 17:58:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 34765 <at> debbugs.gnu.org (full text, mbox):
>> Maybe we should indeed rebind 'buffer-list-update-hook' around the
>> 'generate-new-buffer' and 'kill-buffer' calls of 'with-temp-buffer'.
>
> Wouldn't that be a backward-incompatible change?
It would be a backward-incompatible change.
> How long did we call
> that hook for temporary buffers?
Ever since that hook existed.
> Also, can generate-new-buffer and/or
> kill-buffer run some hooks which might modify other, non-temporary
> buffers?
'generate-new-buffer' calls 'get-buffer-create' and that one runs only
'buffer-list-update-hook'. 'kill-buffer' runs its usual hooks and if
one of them runs 'kill-buffer' for another buffer we'd have a problem.
An even more radical solution would be to never run
'buffer-list-update-hook' for buffers whose name starts with a space.
Backward-incompatible as well but cleaner from a designer's POV.
In either case it wouldn't help the OP since he probably (hopefully)
won't need a solution for Emacs 27 (where he should be able to use
'window-selection-change-functions' instead) and we are certainly not
going to change this for Emacs 26.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Thu, 07 Mar 2019 06:20:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 34765 <at> debbugs.gnu.org (full text, mbox):
> And do not preserve NORECORD?
They did.
> Maybe magit should simply try to reuse the same temporary buffer
> instead of recreating it excessively. Creating/killing temporary
> buffers does not come without some overhead.
It didn't. IIRC a temp buffer was created 2 or 3 times every time
I would move point. The problem is that this *somehow* triggered a
feedback loop with treemacs and magit feeding off each other. I
haven't really understood what happened there as that would require
some very deep digging inside magit's internals. There's a recipe for
emacs -q in the github issue if you want to see this for yourself.
> I see. But please try 'window-selection-change-functions'
> sooner or later so we know whether it fixes these problems.
Way ahead of you ;)
https://github.com/Alexander-Miller/treemacs/issues/321
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Thu, 07 Mar 2019 08:30:03 GMT)
Full text and
rfc822 format available.
Message #26 received at 34765 <at> debbugs.gnu.org (full text, mbox):
> > And do not preserve NORECORD?
>
> They did.
So what was the problem there? How did 'buffer-list-update-hook' get
invoked in such a wild manner?
> It didn't. IIRC a temp buffer was created 2 or 3 times every time
> I would move point.
This alone qualifies as a bug IMHO.
> The problem is that this *somehow* triggered a
> feedback loop with treemacs and magit feeding off each other. I
> haven't really understood what happened there as that would require
> some very deep digging inside magit's internals.
I think that creating a new temporary buffer should always be the
exception and never the rule. Does the point moving happen in the
treemacs buffer or in that of a plain (probably git-controlled)
buffer?
> There's a recipe for
> emacs -q in the github issue if you want to see this for yourself.
Can you pass me a corresponding URL?
> > I see. But please try 'window-selection-change-functions'
> > sooner or later so we know whether it fixes these problems.
>
> Way ahead of you ;)
> https://github.com/Alexander-Miller/treemacs/issues/321
Aha.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Thu, 07 Mar 2019 09:45:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 34765 <at> debbugs.gnu.org (full text, mbox):
> So what was the problem there? How did 'buffer-list-update-hook' get
> invoked in such a wild manner
As I understand it: advising select-window served the purpose of
remembering the
current window so the modeline can be highlighted in tune with the
selection. The
advising code would also call force-mode-line-update, that in turn lead
to a re-calculation
of the frame title, in spacemacs this could in turn call format-spec,
that would use a
temp-buffer, that triggers buffer-list-update-hook, that triggers
treemacs' follow-mode
callback, that calls with-selected-window, that leads back to the
modeline's select-window
advice. That's more or less what the feedback loop looked like.
Come to think of it, maybe just suppressing the hook during my own
window-selection
will do the trick.
> This alone qualifies as a bug IMHO.
You'll have to take that up with Jonas. I linked this discussion in
github, so he'll probably
read this.
> I think that creating a new temporary buffer should always be the
> exception and never the rule. Does the point moving happen in the
> treemacs buffer or in that of a plain (probably git-controlled)
> buffer?
You misunderstood. The issue only happened when the treemacs window was
visible,
but point was in magit's status buffer and a region was active (e.g.
when you want to
select single lines for staging or reverting). Non-magit buffers had no
issues.
> Can you pass me a corresponding URL?
Did that already, Here it is again:
https://github.com/magit/magit/issues/3738#issuecomment-464520582
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Thu, 07 Mar 2019 13:47:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 34765 <at> debbugs.gnu.org (full text, mbox):
> As I understand it: advising select-window served the purpose of
> remembering the
> current window so the modeline can be highlighted in tune with the
> selection. The
> advising code would also call force-mode-line-update, that in turn lead
> to a re-calculation
> of the frame title, in spacemacs this could in turn call format-spec,
> that would use a
> temp-buffer, that triggers buffer-list-update-hook, that triggers
> treemacs' follow-mode
> callback, that calls with-selected-window, that leads back to the
> modeline's select-window
> advice. That's more or less what the feedback loop looked like.
Thanks. IIUC this means that we'll have to put an extra warning in
the doc-string of 'buffer-list-update-hook' to not kill, rename or
create buffers or select another window with NORECORD nil in its
functions. I listed all functions calling that hook in the hope that
people would then avoid that but your example shows that such endless
recursions can be quite tricky to detect.
One major design goal of the new window change functions was to simply
not invoke them recursively so such scenarios should not happen there
(and was immediately proven wrong by the redisplay mechanism itself).
> > Can you pass me a corresponding URL?
>
> Did that already, Here it is again:
> https://github.com/magit/magit/issues/3738#issuecomment-464520582
I thought you had another one (with more insight into how that problem
triggered). But the scenario above is sufficient to imagine what can
happen ...
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Tue, 23 Apr 2019 09:22:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 34765 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> >> Maybe we should indeed rebind 'buffer-list-update-hook' around the
> >> 'generate-new-buffer' and 'kill-buffer' calls of 'with-temp-buffer'.
> >
> > Wouldn't that be a backward-incompatible change?
>
> It would be a backward-incompatible change.
>
> > How long did we call
> > that hook for temporary buffers?
>
> Ever since that hook existed.
>
> > Also, can generate-new-buffer and/or
> > kill-buffer run some hooks which might modify other, non-temporary
> > buffers?
>
> 'generate-new-buffer' calls 'get-buffer-create' and that one runs only
> 'buffer-list-update-hook'. 'kill-buffer' runs its usual hooks and if
> one of them runs 'kill-buffer' for another buffer we'd have a problem.
>
> An even more radical solution would be to never run
> 'buffer-list-update-hook' for buffers whose name starts with a space.
> Backward-incompatible as well but cleaner from a designer's POV.
>
> In either case it wouldn't help the OP since he probably (hopefully)
> won't need a solution for Emacs 27 (where he should be able to use
> 'window-selection-change-functions' instead) and we are certainly not
> going to change this for Emacs 26.
Stefan asked me to add a variable 'inhibit-buffer-list-update-hook'
and I came up with the attached. WDYT?
martin
[inhibit-buffer-list-update-hook.diff (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Tue, 23 Apr 2019 10:37:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 34765 <at> debbugs.gnu.org (full text, mbox):
> From: martin rudalics <rudalics <at> gmx.at>
> Cc: 34765 <at> debbugs.gnu.org, alexanderm <at> web.de,
> Stefan Monnier <monnier <at> IRO.UMontreal.CA>
> Date: Tue, 23 Apr 2019 11:21:45 +0200
>
> Stefan asked me to add a variable 'inhibit-buffer-list-update-hook'
> and I came up with the attached. WDYT?
Did he also ask you to remove the inhibit_buffer_hooks flag of the
buffer object? I'd rather prefer that you set that flag for temporary
buffers. In any case, removing the flag will get back the problem
with hidden buffers used by coding.c, right? I don't want to lose
that.
More generally, I don't understand the need for this variable. If we
just want to inhibit the hooks for temporary buffers, we don't need to
provide a variable, we can do that internally and unconditionally.
The variable assumes there are other legitimate use cases where a Lisp
program would want to inhibit the hooks, and that we agree to let Lisp
programs do that. What are those use cases?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Wed, 24 Apr 2019 07:29:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 34765 <at> debbugs.gnu.org (full text, mbox):
>> Stefan asked me to add a variable 'inhibit-buffer-list-update-hook'
>> and I came up with the attached. WDYT?
>
> Did he also ask you to remove the inhibit_buffer_hooks flag of the
> buffer object? I'd rather prefer that you set that flag for temporary
> buffers. In any case, removing the flag will get back the problem
> with hidden buffers used by coding.c, right? I don't want to lose
> that.
FWIW handling of the the inhibit_buffer_hooks flag is unaffected by my
patch. Note that I special cased the call from 'make-indirect-buffer'
which is the only one that doesn't check that flag.
> More generally, I don't understand the need for this variable. If we
> just want to inhibit the hooks for temporary buffers, we don't need to
> provide a variable, we can do that internally and unconditionally.
> The variable assumes there are other legitimate use cases where a Lisp
> program would want to inhibit the hooks, and that we agree to let Lisp
> programs do that. What are those use cases?
I don't know. The one we care about in the case at hand is that of
'with-temp-buffer' which seems innocuous enough for being used in the
body of a function run by 'buffer-list-update-hook'. Since that macro
is in subr.el and as such cannnot easily set the inhibit_buffer_hooks
flag, the 'inhibit-buffer-list-update-hook' variable provides a simple
workaround. But maybe Stefan himself can explain the rationale for
such a variable. IIUC his main motivation was that by rebinding
'inhibit-buffer-list-update-hook' to nil one can from Lisp relax the
restrictions provided by my patch.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Wed, 24 Apr 2019 11:14:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 34765 <at> debbugs.gnu.org (full text, mbox):
> Cc: 34765 <at> debbugs.gnu.org, alexanderm <at> web.de, monnier <at> IRO.UMontreal.CA
> From: martin rudalics <rudalics <at> gmx.at>
> Date: Wed, 24 Apr 2019 09:27:59 +0200
>
> >> Stefan asked me to add a variable 'inhibit-buffer-list-update-hook'
> >> and I came up with the attached. WDYT?
> >
> > Did he also ask you to remove the inhibit_buffer_hooks flag of the
> > buffer object? I'd rather prefer that you set that flag for temporary
> > buffers. In any case, removing the flag will get back the problem
> > with hidden buffers used by coding.c, right? I don't want to lose
> > that.
>
> FWIW handling of the the inhibit_buffer_hooks flag is unaffected by my
> patch.
You are right, sorry.
> > More generally, I don't understand the need for this variable. If we
> > just want to inhibit the hooks for temporary buffers, we don't need to
> > provide a variable, we can do that internally and unconditionally.
> > The variable assumes there are other legitimate use cases where a Lisp
> > program would want to inhibit the hooks, and that we agree to let Lisp
> > programs do that. What are those use cases?
>
> I don't know. The one we care about in the case at hand is that of
> 'with-temp-buffer' which seems innocuous enough for being used in the
> body of a function run by 'buffer-list-update-hook'. Since that macro
> is in subr.el and as such cannnot easily set the inhibit_buffer_hooks
> flag, the 'inhibit-buffer-list-update-hook' variable provides a simple
> workaround.
I meant to suggest that get-buffer-create sets this flag when the name
of the buffer fits the template of temporary buffers. Exactly like it
does for code-conversion buffers now.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Wed, 24 Apr 2019 12:56:03 GMT)
Full text and
rfc822 format available.
Message #47 received at 34765 <at> debbugs.gnu.org (full text, mbox):
> I meant to suggest that get-buffer-create sets this flag when the name
> of the buffer fits the template of temporary buffers.
That's a more drastic change, but it might be worth a try.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Thu, 25 Apr 2019 08:07:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 34765 <at> debbugs.gnu.org (full text, mbox):
> I meant to suggest that get-buffer-create sets this flag when the name
> of the buffer fits the template of temporary buffers. Exactly like it
> does for code-conversion buffers now.
We don't have a "template of temporary buffers". For example, a
buffer specified by the BUFNAME arg of 'with-output-to-temp-buffer'
should not match such a template. But I'd favor a solution that skips
all buffers whose name starts with a space as we do for 'other-buffer'
or 'unbury-buffer'. We'd just have to document it, maybe provide an
additional argument for 'buffer-list' to not return such buffers,
decide what to do when we rename them, when they visit a file, get
killed ...
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Thu, 25 Apr 2019 08:52:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 34765 <at> debbugs.gnu.org (full text, mbox):
> Cc: 34765 <at> debbugs.gnu.org, alexanderm <at> web.de, monnier <at> IRO.UMontreal.CA
> From: martin rudalics <rudalics <at> gmx.at>
> Date: Thu, 25 Apr 2019 10:06:18 +0200
>
> > I meant to suggest that get-buffer-create sets this flag when the name
> > of the buffer fits the template of temporary buffers. Exactly like it
> > does for code-conversion buffers now.
>
> We don't have a "template of temporary buffers".
Of course we do: with-temp-buffer produces buffer names that follow
such a template.
> For example, a buffer specified by the BUFNAME arg of
> 'with-output-to-temp-buffer' should not match such a template.
Such buffers should not necessarily be exempt from running the hooks,
AFAIU. In any case, one can always bind the hook locally to nil in
the body of the macro, right?
> But I'd favor a solution that skips all buffers whose name starts
> with a space as we do for 'other-buffer' or 'unbury-buffer'.
I think this is too drastic a measure. We should only disable the
hooks in buffers where no one in their right minds will ever want to
run them.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Thu, 25 Apr 2019 10:32:01 GMT)
Full text and
rfc822 format available.
Message #56 received at 34765 <at> debbugs.gnu.org (full text, mbox):
>> > I meant to suggest that get-buffer-create sets this flag when the name
>> > of the buffer fits the template of temporary buffers. Exactly like it
>> > does for code-conversion buffers now.
>>
>> We don't have a "template of temporary buffers".
>
> Of course we do: with-temp-buffer produces buffer names that follow
> such a template.
IIUC we'd need an expression similar to Vcode_conversion_workbuf_name
to use in 'get-buffer-create'
b->inhibit_buffer_hooks
= (STRINGP (Vcode_conversion_workbuf_name)
&& strncmp (SSDATA (name), SSDATA (Vcode_conversion_workbuf_name),
SBYTES (Vcode_conversion_workbuf_name)) == 0);
So we could specify, for example,
staticpro (&Vtemp_buffer_name);
Vtemp_buffer_name = build_pure_c_string (" *temp*");
and rewrite the above assignment as
b->inhibit_buffer_hooks
= ((STRINGP (Vcode_conversion_workbuf_name)
&& strncmp (SSDATA (name), SSDATA (Vcode_conversion_workbuf_name),
SBYTES (Vcode_conversion_workbuf_name)) == 0)
|| (STRINGP (Vtemp_buffer_name)
&& strncmp (SSDATA (name), SSDATA (Vtemp_buffer_name),
SBYTES (Vtemp_buffer_name)) == 0));
>> For example, a buffer specified by the BUFNAME arg of
>> 'with-output-to-temp-buffer' should not match such a template.
>
> Such buffers should not necessarily be exempt from running the hooks,
> AFAIU. In any case, one can always bind the hook locally to nil in
> the body of the macro, right?
Unless the body changes the buffer list in some signifcant way, for
example, by creating or deleting another buffer.
>> But I'd favor a solution that skips all buffers whose name starts
>> with a space as we do for 'other-buffer' or 'unbury-buffer'.
>
> I think this is too drastic a measure. We should only disable the
> hooks in buffers where no one in their right minds will ever want to
> run them.
Then what about the buffers created by 'with-temp-file' or
'with-output-to-string'?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Thu, 25 Apr 2019 10:50:01 GMT)
Full text and
rfc822 format available.
Message #59 received at 34765 <at> debbugs.gnu.org (full text, mbox):
> Cc: 34765 <at> debbugs.gnu.org, alexanderm <at> web.de, monnier <at> IRO.UMontreal.CA
> From: martin rudalics <rudalics <at> gmx.at>
> Date: Thu, 25 Apr 2019 12:31:20 +0200
>
> >> > I meant to suggest that get-buffer-create sets this flag when the name
> >> > of the buffer fits the template of temporary buffers. Exactly like it
> >> > does for code-conversion buffers now.
> >>
> >> We don't have a "template of temporary buffers".
> >
> > Of course we do: with-temp-buffer produces buffer names that follow
> > such a template.
>
> IIUC we'd need an expression similar to Vcode_conversion_workbuf_name
> to use in 'get-buffer-create'
That's what I meant, yes.
> >> For example, a buffer specified by the BUFNAME arg of
> >> 'with-output-to-temp-buffer' should not match such a template.
> >
> > Such buffers should not necessarily be exempt from running the hooks,
> > AFAIU. In any case, one can always bind the hook locally to nil in
> > the body of the macro, right?
>
> Unless the body changes the buffer list in some signifcant way, for
> example, by creating or deleting another buffer.
Sure, but that's why this should not be done unconditionally.
> Then what about the buffers created by 'with-temp-file' or
> 'with-output-to-string'?
Fine with me. But the former already uses with-temp-buffer, so I
don't think we need anything special for it.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Thu, 25 Apr 2019 13:02:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 34765 <at> debbugs.gnu.org (full text, mbox):
> - `(let ((,temp-buffer (generate-new-buffer " *temp*")))
> + `(let ((,temp-buffer
> + (let ((inhibit-buffer-list-update-hook t))
> + (generate-new-buffer " *temp*"))))
> ;; FIXME: kill-buffer can change current-buffer in some odd cases.
> (with-current-buffer ,temp-buffer
> (unwind-protect
> (progn ,@body)
> (and (buffer-name ,temp-buffer)
> - (kill-buffer ,temp-buffer)))))))
> + (let ((inhibit-buffer-list-update-hook t))
> + (kill-buffer ,temp-buffer))))))))
Hmm... I was thinking we could expose `inhibit_buffer_hooks` as a Lisp
variable (so we can set it without having to match names, which I find
ugly and brittle), but we'd want to `setq` it rather than let-bind it.
But while it's easy to set it before running kill-buffer, we can't set
it before calling generate-new-buffer :-(
How 'bout adding an optional argument to `generate-new-buffer` to set
`inhibit_buffer_hooks`?
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Thu, 25 Apr 2019 14:36:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 34765 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 34765 <at> debbugs.gnu.org, alexanderm <at> web.de
> Date: Thu, 25 Apr 2019 09:01:01 -0400
>
> How 'bout adding an optional argument to `generate-new-buffer` to set
> `inhibit_buffer_hooks`?
Fine with me, but aren't you afraid people will start abusing this?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Fri, 26 Apr 2019 07:42:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 34765 <at> debbugs.gnu.org (full text, mbox):
>> Then what about the buffers created by 'with-temp-file' or
>> 'with-output-to-string'?
>
> Fine with me. But the former already uses with-temp-buffer, so I
> don't think we need anything special for it.
Here 'with-temp-file' uses
(get-buffer-create (generate-new-buffer-name " *temp file*"))
and 'with-output-to-string'
(get-buffer-create (generate-new-buffer-name " *string-output*"))
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Fri, 26 Apr 2019 07:42:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 34765 <at> debbugs.gnu.org (full text, mbox):
> How 'bout adding an optional argument to `generate-new-buffer` to set
> `inhibit_buffer_hooks`?
How about moving 'generate-new-buffer' to C to set that flag without
exposing it to Lisp (and to avoid things like
;; We can't use `generate-new-buffer' because files.el
;; is not yet loaded.
in 'load-with-code-conversion')?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Fri, 26 Apr 2019 07:42:03 GMT)
Full text and
rfc822 format available.
Message #74 received at 34765 <at> debbugs.gnu.org (full text, mbox):
>> How 'bout adding an optional argument to `generate-new-buffer` to set
>> `inhibit_buffer_hooks`?
>
> Fine with me, but aren't you afraid people will start abusing this?
I wouldn't pass an argument but rather set the flag unconditionally
when NAME starts with a space ...
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Fri, 26 Apr 2019 08:10:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 34765 <at> debbugs.gnu.org (full text, mbox):
> Cc: 34765 <at> debbugs.gnu.org, alexanderm <at> web.de, monnier <at> IRO.UMontreal.CA
> From: martin rudalics <rudalics <at> gmx.at>
> Date: Fri, 26 Apr 2019 09:40:48 +0200
>
> >> Then what about the buffers created by 'with-temp-file' or
> >> 'with-output-to-string'?
> >
> > Fine with me. But the former already uses with-temp-buffer, so I
> > don't think we need anything special for it.
>
> Here 'with-temp-file' uses
>
> (get-buffer-create (generate-new-buffer-name " *temp file*"))
>
> and 'with-output-to-string'
>
> (get-buffer-create (generate-new-buffer-name " *string-output*"))
Oops.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Fri, 26 Apr 2019 08:11:01 GMT)
Full text and
rfc822 format available.
Message #80 received at 34765 <at> debbugs.gnu.org (full text, mbox):
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 34765 <at> debbugs.gnu.org, alexanderm <at> web.de
> From: martin rudalics <rudalics <at> gmx.at>
> Date: Fri, 26 Apr 2019 09:41:02 +0200
>
> > How 'bout adding an optional argument to `generate-new-buffer` to set
> > `inhibit_buffer_hooks`?
>
> How about moving 'generate-new-buffer' to C to set that flag without
> exposing it to Lisp (and to avoid things like
>
> ;; We can't use `generate-new-buffer' because files.el
> ;; is not yet loaded.
>
> in 'load-with-code-conversion')?
Fine with me.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Fri, 26 Apr 2019 08:12:02 GMT)
Full text and
rfc822 format available.
Message #83 received at 34765 <at> debbugs.gnu.org (full text, mbox):
> Cc: 34765 <at> debbugs.gnu.org, alexanderm <at> web.de
> From: martin rudalics <rudalics <at> gmx.at>
> Date: Fri, 26 Apr 2019 09:41:11 +0200
>
> >> How 'bout adding an optional argument to `generate-new-buffer` to set
> >> `inhibit_buffer_hooks`?
> >
> > Fine with me, but aren't you afraid people will start abusing this?
>
> I wouldn't pass an argument but rather set the flag unconditionally
> when NAME starts with a space ...
Too radical, IMO.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Fri, 26 Apr 2019 11:01:02 GMT)
Full text and
rfc822 format available.
Message #86 received at 34765 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>> > How 'bout adding an optional argument to `generate-new-buffer` to set
>> > `inhibit_buffer_hooks`?
>>
>> How about moving 'generate-new-buffer' to C to set that flag without
>> exposing it to Lisp (and to avoid things like
>>
>> ;; We can't use `generate-new-buffer' because files.el
>> ;; is not yet loaded.
>>
>> in 'load-with-code-conversion')?
>
> Fine with me.
I attach a preliminary patch.
martin
[inhibit-buffer-hooks.diff (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Fri, 26 Apr 2019 11:27:02 GMT)
Full text and
rfc822 format available.
Message #89 received at 34765 <at> debbugs.gnu.org (full text, mbox):
> Cc: monnier <at> IRO.UMontreal.CA, 34765 <at> debbugs.gnu.org, alexanderm <at> web.de
> From: martin rudalics <rudalics <at> gmx.at>
> Date: Fri, 26 Apr 2019 13:00:06 +0200
>
>
> I attach a preliminary patch.
Thanks. This will need documentation changes when pushed.
> +/**
> + * run_buffer_list_update_hook:
> + *
> + * Run any functions on 'buffer-list-update-hook'. Do not run the
> + * functions when BUFFER is a buffer and its inhibit_buffer_hooks
> + * structure element is set. Do not run any functions either when we
> + * are not allowed to run hooks.
> + */
Can we please use our style in commentary? We don't use bock comments
in Emacs, so I'd like not to proliferate them.
> + if (!inhibit_buffer_hooks)
> + /* Run buffer-list-update-hook. */
> + run_buffer_list_update_hook (buffer);
It is somewhat strange that part of the reasons for not running hooks
are tested inside run_buffer_list_update_hook, and others explicitly
here. Any special reasons for this inconsistency?
> +DEFUN ("get-buffer-create", Fget_buffer_create, Sget_buffer_create, 1, 1, 0,
> + doc: /* Return the buffer specified by BUFFER-OR-NAME, creating a new one if needed.
> +If BUFFER-OR-NAME is a string and a live buffer with that name exists,
> +return that buffer. If no such buffer exists, create a new buffer with
> +that name and return it. If BUFFER-OR-NAME starts with a space, the new
> +buffer does not keep undo information.
> +
> +If BUFFER-OR-NAME is a buffer instead of a string, return it as given,
> +even if it is dead. The return value is never nil. */)
> + (Lisp_Object buffer_or_name)
> +{
> + return get_buffer_create (buffer_or_name, false);
> +}
Should this function also acquire an additional optional argument? If
not, why not?
> +Optional second argument INHIBIT-BUFFER-HOOKS non-nil means to not run
> +any buffer hooks ('kill-buffer-hook', 'buffer-list-update-hook' or
> +'kill-buffer-query-functions') for this buffer. This argument should
The hooks should be quoted `like this', right? We do want them to
become hyperlinks.
> +be set only for internal buffers that are never presented to users or
> +passed on to other applications. */)
> + (Lisp_Object name, Lisp_Object inhibit_buffer_hooks)
> +{
> + Lisp_Object buffer_name = Fgenerate_new_buffer_name (name, Qnil);
> + Lisp_Object buffer = get_buffer_create (buffer_name,
> + !NILP (inhibit_buffer_hooks));
> +
> + if (!NILP (inhibit_buffer_hooks))
> + {
> + struct buffer *b = XBUFFER (buffer);
> +
> + b->inhibit_buffer_hooks = true;
> + }
Should this flag be set inside get_buffer_create?
> +Neither 'kill-buffer-query-functions' nor 'kill-buffer-hook' are run
> +for buffers created by 'generate-new-buffer' with the second argument
> +'inhibit-buffer-hooks' non-nil.
Quoting again.
> @@ -6268,9 +6334,9 @@ The function `kill-all-local-variables' runs this before doing anything else. *
> doc: /* Hook run when the buffer list changes.
> Functions (implicitly) running this hook are `get-buffer-create',
> `make-indirect-buffer', `rename-buffer', `kill-buffer', `bury-buffer'
> -and `select-window'. Functions run by this hook should avoid calling
> -`select-window' with a nil NORECORD argument or `with-temp-buffer'
> -since either may lead to infinite recursion. */);
> +and `select-window'. This hook is not run for buffers created by
> +'generate-new-buffer' with the second argument 'inhibit-buffer-hooks'
> +non-nil. */);
And here.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Fri, 26 Apr 2019 17:15:01 GMT)
Full text and
rfc822 format available.
Message #92 received at 34765 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
martin rudalics <rudalics <at> gmx.at> writes:
> I attach a preliminary patch.
Your patch allows the following additional change, right?
[coding.diff (text/x-diff, inline)]
diff --git a/src/coding.c b/src/coding.c
index 2c6b2c4d05..3dd5f3b1c1 100644
--- a/src/coding.c
+++ b/src/coding.c
@@ -7820,9 +7820,7 @@ code_conversion_save (bool with_work_buf, bool multibyte)
{
if (reused_workbuf_in_use)
{
- Lisp_Object name
- = Fgenerate_new_buffer_name (Vcode_conversion_workbuf_name, Qnil);
- workbuf = Fget_buffer_create (name);
+ workbuf = Fgenerate_new_buffer (Vcode_conversion_workbuf_name, Qt);
}
else
{
[Message part 3 (text/plain, inline)]
Thanks,
--
Basil
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Sat, 27 Apr 2019 08:31:02 GMT)
Full text and
rfc822 format available.
Message #95 received at 34765 <at> debbugs.gnu.org (full text, mbox):
> Can we please use our style in commentary? We don't use bock comments
> in Emacs, so I'd like not to proliferate them.
Actually it's not a comment but a doc-string and if you customize
'font-lock-doc-face' you will notice. These were part of a project of
mine to improve handling and readability of Emacs primitives'
doc-strings (including font locking, Lisp syntax with completion and
eldoc support, correct filling, exporting/importing from C to Lisp to
texinfo and the like). But since I never managed to write some of
these components, the project has stalled. I'll stop proliferating
that style now.
>> + if (!inhibit_buffer_hooks)
>> + /* Run buffer-list-update-hook. */
>> + run_buffer_list_update_hook (buffer);
>
> It is somewhat strange that part of the reasons for not running hooks
> are tested inside run_buffer_list_update_hook, and others explicitly
> here. Any special reasons for this inconsistency?
See below.
>> +DEFUN ("get-buffer-create", Fget_buffer_create, Sget_buffer_create, 1, 1, 0,
>> + doc: /* Return the buffer specified by BUFFER-OR-NAME, creating a new one if needed.
>> +If BUFFER-OR-NAME is a string and a live buffer with that name exists,
>> +return that buffer. If no such buffer exists, create a new buffer with
>> +that name and return it. If BUFFER-OR-NAME starts with a space, the new
>> +buffer does not keep undo information.
>> +
>> +If BUFFER-OR-NAME is a buffer instead of a string, return it as given,
>> +even if it is dead. The return value is never nil. */)
>> + (Lisp_Object buffer_or_name)
>> +{
>> + return get_buffer_create (buffer_or_name, false);
>> +}
>
> Should this function also acquire an additional optional argument? If
> not, why not?
You mean 'get-buffer-create'? I had that in a first version. But
since you earlier expressed concerns about people abusing the extra
argument of 'generate-new-buffer' I thought 'get-buffer-create' would
be even more critical in this regard. In either case I'll do what you
(or others) consider best.
>> +Optional second argument INHIBIT-BUFFER-HOOKS non-nil means to not run
>> +any buffer hooks ('kill-buffer-hook', 'buffer-list-update-hook' or
>> +'kill-buffer-query-functions') for this buffer. This argument should
>
> The hooks should be quoted `like this', right? We do want them to
> become hyperlinks.
Right.
>> +be set only for internal buffers that are never presented to users or
>> +passed on to other applications. */)
>> + (Lisp_Object name, Lisp_Object inhibit_buffer_hooks)
>> +{
>> + Lisp_Object buffer_name = Fgenerate_new_buffer_name (name, Qnil);
>> + Lisp_Object buffer = get_buffer_create (buffer_name,
>> + !NILP (inhibit_buffer_hooks));
>> +
>> + if (!NILP (inhibit_buffer_hooks))
>> + {
>> + struct buffer *b = XBUFFER (buffer);
>> +
>> + b->inhibit_buffer_hooks = true;
>> + }
>
> Should this flag be set inside get_buffer_create?
If we do that, it would also resolve the "inconsistency" you bemoan
above. So the answer is probably yes.
> Quoting again.
[...]
> And here.
Right. At least I show signs of consistency when adopting silly
style.
Thanks, martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Sat, 27 Apr 2019 08:32:02 GMT)
Full text and
rfc822 format available.
Message #98 received at 34765 <at> debbugs.gnu.org (full text, mbox):
> Your patch allows the following additional change, right?
I suppose so. I'm not sure about the Fget_buffer_create in the else
branch of that if, though. It would be nice to get rid of the entire
b->inhibit_buffer_hooks
= (STRINGP (Vcode_conversion_workbuf_name)
&& strncmp (SSDATA (name), SSDATA (Vcode_conversion_workbuf_name),
SBYTES (Vcode_conversion_workbuf_name)) == 0);
form in 'get-buffer-create'. Any ideas?
Thanks, martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Mon, 20 May 2019 13:43:02 GMT)
Full text and
rfc822 format available.
Message #101 received at 34765 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>> Your patch allows the following additional change, right?
>
> I suppose so. I'm not sure about the Fget_buffer_create in the else
> branch of that if, though.
WDYM?
> It would be nice to get rid of the entire
>
> b->inhibit_buffer_hooks
> = (STRINGP (Vcode_conversion_workbuf_name)
> && strncmp (SSDATA (name), SSDATA (Vcode_conversion_workbuf_name),
> SBYTES (Vcode_conversion_workbuf_name)) == 0);
>
> form in 'get-buffer-create'. Any ideas?
Doesn't your patch in https://debbugs.gnu.org/34765#86 already eliminate
the need for it?
Thanks,
--
Basil
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Tue, 21 May 2019 07:33:01 GMT)
Full text and
rfc822 format available.
Message #104 received at 34765 <at> debbugs.gnu.org (full text, mbox):
>> It would be nice to get rid of the entire
>>
>> b->inhibit_buffer_hooks
>> = (STRINGP (Vcode_conversion_workbuf_name)
>> && strncmp (SSDATA (name), SSDATA (Vcode_conversion_workbuf_name),
>> SBYTES (Vcode_conversion_workbuf_name)) == 0);
>>
>> form in 'get-buffer-create'. Any ideas?
>
> Doesn't your patch in https://debbugs.gnu.org/34765#86 already eliminate
> the need for it?
FWIW no, it leaves that form in place. And 'get-buffer-create' should
not have to worry about delving any deeper into the name than down to
its first character to check for ' ' or '*'.
But I'm not happy with my patch anyway. Something more elegant is
needed.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Tue, 21 May 2019 07:59:01 GMT)
Full text and
rfc822 format available.
Message #107 received at 34765 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>>> It would be nice to get rid of the entire
>>>
>>> b->inhibit_buffer_hooks
>>> = (STRINGP (Vcode_conversion_workbuf_name)
>>> && strncmp (SSDATA (name), SSDATA (Vcode_conversion_workbuf_name),
>>> SBYTES (Vcode_conversion_workbuf_name)) == 0);
>>>
>>> form in 'get-buffer-create'. Any ideas?
>>
>> Doesn't your patch in https://debbugs.gnu.org/34765#86 already eliminate
>> the need for it?
>
> FWIW no, it leaves that form in place.
I know, my emphasis was on eliminating the *need* for it.
> And 'get-buffer-create' should not have to worry about delving any
> deeper into the name than down to its first character to check for ' '
> or '*'.
>
> But I'm not happy with my patch anyway. Something more elegant is
> needed.
The possibilities for the buffer creation subroutine are either to act
specially on certain buffer name prefixes, or to accept an extra
argument indicating what to do, no? Are there any others? There was
mention of exposing a buffer-local variable to Elisp, but IIRC setting
that after creating the buffer would already be too late.
Buffer names starting with spaces are already special in some contexts,
so extending that idea for inhibiting buffer hooks doesn't sound too
bad, but the extra flag seems equally elegant and more
backward-compatible. Am I missing something?
Thanks,
--
Basil
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Tue, 21 May 2019 10:05:02 GMT)
Full text and
rfc822 format available.
Message #110 received at 34765 <at> debbugs.gnu.org (full text, mbox):
>>>> It would be nice to get rid of the entire
>>>>
>>>> b->inhibit_buffer_hooks
>>>> = (STRINGP (Vcode_conversion_workbuf_name)
>>>> && strncmp (SSDATA (name), SSDATA (Vcode_conversion_workbuf_name),
>>>> SBYTES (Vcode_conversion_workbuf_name)) == 0);
>>>>
>>>> form in 'get-buffer-create'. Any ideas?
>>>
>>> Doesn't your patch in https://debbugs.gnu.org/34765#86 already eliminate
>>> the need for it?
>>
>> FWIW no, it leaves that form in place.
>
> I know, my emphasis was on eliminating the *need* for it.
That's what I meant with the above. In code_conversion_save we should
get rid of _both_ Fget_buffer_create instances but but I have not
managed to understand the Vcode_conversion_workbuf_name vs
Vcode_conversion_reused_workbuf rigmarole yet.
> The possibilities for the buffer creation subroutine are either to act
> specially on certain buffer name prefixes, or to accept an extra
> argument indicating what to do, no? Are there any others? There was
> mention of exposing a buffer-local variable to Elisp, but IIRC setting
> that after creating the buffer would already be too late.
So far there is no extra argument, the entire analysis is based on
examining the proposed name argument.
> Buffer names starting with spaces are already special in some contexts,
> so extending that idea for inhibiting buffer hooks doesn't sound too
> bad,
Eli thinks that "this is too drastic a measure".
> but the extra flag seems equally elegant and more
> backward-compatible. Am I missing something?
The piece we are discussing here namely how to get rid of the stuff at
the top of this mail. And issues Eli raised earlier - whether
'get-buffer-create' should accept an extra argument or whether it
should set b->inhibit_buffer_hooks = true.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Wed, 22 May 2019 07:22:01 GMT)
Full text and
rfc822 format available.
Message #113 received at 34765 <at> debbugs.gnu.org (full text, mbox):
> From: "Basil L. Contovounesios" <contovob <at> tcd.ie>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 34765 <at> debbugs.gnu.org, alexanderm <at> web.de, monnier <at> IRO.UMontreal.CA
> Date: Tue, 21 May 2019 08:58:17 +0100
>
> The possibilities for the buffer creation subroutine are either to act
> specially on certain buffer name prefixes, or to accept an extra
> argument indicating what to do, no? Are there any others? There was
> mention of exposing a buffer-local variable to Elisp, but IIRC setting
> that after creating the buffer would already be too late.
>
> Buffer names starting with spaces are already special in some contexts,
> so extending that idea for inhibiting buffer hooks doesn't sound too
> bad, but the extra flag seems equally elegant and more
> backward-compatible. Am I missing something?
The flag in the C structure has the advantage that it can be easily
set and reset from C without the need to temporarily bind Lisp
variables, which then involves unwind-protect forms etc., and as a
side effect makes the entire operation slower. Also, a flag can be
set/reset regardless of whether the buffer already finished being
created, whereas buffer-local variables must have a live buffer.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Wed, 22 May 2019 07:30:02 GMT)
Full text and
rfc822 format available.
Message #116 received at 34765 <at> debbugs.gnu.org (full text, mbox):
> From: martin rudalics <rudalics <at> gmx.at>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 34765 <at> debbugs.gnu.org, alexanderm <at> web.de,
> monnier <at> IRO.UMontreal.CA
> Date: Tue, 21 May 2019 12:04:46 +0200
>
> I have not managed to understand the Vcode_conversion_workbuf_name
> vs Vcode_conversion_reused_workbuf rigmarole yet.
The latter is a fixed buffer, created once and never killed. So the
buffer hooks never run for it, and never affect Emacs. By contrast,
the former is a buffer created when the reused buffer is busy and
cannot be reused. We then kill Vcode_conversion_workbuf_name when we
no longer need it. Thus, buffer hooks run for these work buffers all
the time, and for a code-conversion intensive code they could slow
down Emacs, specially if the list of buffer hooks is long.
> > The possibilities for the buffer creation subroutine are either to act
> > specially on certain buffer name prefixes, or to accept an extra
> > argument indicating what to do, no? Are there any others? There was
> > mention of exposing a buffer-local variable to Elisp, but IIRC setting
> > that after creating the buffer would already be too late.
>
> So far there is no extra argument, the entire analysis is based on
> examining the proposed name argument.
Since we currently keep this special treatment limited to a small
number of buffer names, I'm not sure there's a need to expose this
facility to Lisp.
> > Buffer names starting with spaces are already special in some contexts,
> > so extending that idea for inhibiting buffer hooks doesn't sound too
> > bad,
>
> Eli thinks that "this is too drastic a measure".
Yes. No one said buffer hooks must _never_ run for temporary buffers.
There could be legitimate Lisp programs which want those hooks to run
in that case.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Wed, 22 May 2019 08:33:02 GMT)
Full text and
rfc822 format available.
Message #119 received at 34765 <at> debbugs.gnu.org (full text, mbox):
>> I have not managed to understand the Vcode_conversion_workbuf_name
>> vs Vcode_conversion_reused_workbuf rigmarole yet.
>
> The latter is a fixed buffer, created once and never killed. So the
> buffer hooks never run for it, and never affect Emacs. By contrast,
> the former is a buffer created when the reused buffer is busy and
> cannot be reused. We then kill Vcode_conversion_workbuf_name when we
> no longer need it. Thus, buffer hooks run for these work buffers all
> the time, and for a code-conversion intensive code they could slow
> down Emacs, specially if the list of buffer hooks is long.
Thanks, I hope I understand it now. Could you pretty please add the
(instructive for me) "a buffer created when the reused buffer is busy
and cannot be reused" somewhere to the comments maybe together with a
reference to reused_workbuf_in_use.
Hopefully this also means that we can use _something like_
Fgenerate_new_buffer to replace both instances of Fget_buffer_create
in code_conversion_restore.
> Since we currently keep this special treatment limited to a small
> number of buffer names, I'm not sure there's a need to expose this
> facility to Lisp.
I'm not sure either.
>>> Buffer names starting with spaces are already special in some contexts,
>>> so extending that idea for inhibiting buffer hooks doesn't sound too
>>> bad,
>>
>> Eli thinks that "this is too drastic a measure".
>
> Yes. No one said buffer hooks must _never_ run for temporary buffers.
> There could be legitimate Lisp programs which want those hooks to run
> in that case.
I have to agree.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Wed, 22 May 2019 10:07:01 GMT)
Full text and
rfc822 format available.
Message #122 received at 34765 <at> debbugs.gnu.org (full text, mbox):
> Cc: contovob <at> tcd.ie, 34765 <at> debbugs.gnu.org, alexanderm <at> web.de,
> monnier <at> IRO.UMontreal.CA
> From: martin rudalics <rudalics <at> gmx.at>
> Date: Wed, 22 May 2019 10:32:39 +0200
>
> >> I have not managed to understand the Vcode_conversion_workbuf_name
> >> vs Vcode_conversion_reused_workbuf rigmarole yet.
> >
> > The latter is a fixed buffer, created once and never killed. So the
> > buffer hooks never run for it, and never affect Emacs. By contrast,
> > the former is a buffer created when the reused buffer is busy and
> > cannot be reused. We then kill Vcode_conversion_workbuf_name when we
> > no longer need it. Thus, buffer hooks run for these work buffers all
> > the time, and for a code-conversion intensive code they could slow
> > down Emacs, specially if the list of buffer hooks is long.
>
> Thanks, I hope I understand it now. Could you pretty please add the
> (instructive for me) "a buffer created when the reused buffer is busy
> and cannot be reused" somewhere to the comments maybe together with a
> reference to reused_workbuf_in_use.
Not sure where you want to add this. coding.c already says:
/* Name (or base name) of work buffer for code conversion. */
Lisp_Object Vcode_conversion_workbuf_name;
/* A working buffer used by the top level conversion. Once it is
created, it is never destroyed. It has the name
Vcode_conversion_workbuf_name. The other working buffers are
destroyed after the use is finished, and their names are modified
versions of Vcode_conversion_workbuf_name. */
static Lisp_Object Vcode_conversion_reused_workbuf;
/* True iff Vcode_conversion_reused_workbuf is already in use. */
static bool reused_workbuf_in_use;
is that what you wanted to see?
> Hopefully this also means that we can use _something like_
> Fgenerate_new_buffer to replace both instances of Fget_buffer_create
> in code_conversion_restore.
You mean code_conversion_save, I presume.
One of those calls to Fget_buffer_create shouldn't generate a new
name, though. It should always use a fixed name.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Wed, 22 May 2019 14:13:01 GMT)
Full text and
rfc822 format available.
Message #125 received at 34765 <at> debbugs.gnu.org (full text, mbox):
>> Since we currently keep this special treatment limited to a small
>> number of buffer names, I'm not sure there's a need to expose this
>> facility to Lisp.
> I'm not sure either.
How 'bout this: additionally to "hidden buffers" which start with a SPC
character, we introduce the notion of "internal buffers" whose name
starts with another special first char or with two SPC chars and disable
those buffers's hooks.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Wed, 22 May 2019 15:51:02 GMT)
Full text and
rfc822 format available.
Message #128 received at 34765 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, contovob <at> tcd.ie, 34765 <at> debbugs.gnu.org, alexanderm <at> web.de
> Date: Wed, 22 May 2019 10:12:36 -0400
>
> How 'bout this: additionally to "hidden buffers" which start with a SPC
> character, we introduce the notion of "internal buffers" whose name
> starts with another special first char or with two SPC chars and disable
> those buffers's hooks.
It's possible, if there's a frequent enough use case for such
automatic disabling. Is there?
In general, since the hook can be disabled in each buffer
individually, we'd need a very good reason to provide another
facility.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Thu, 23 May 2019 08:40:02 GMT)
Full text and
rfc822 format available.
Message #131 received at 34765 <at> debbugs.gnu.org (full text, mbox):
>> Thanks, I hope I understand it now. Could you pretty please add the
>> (instructive for me) "a buffer created when the reused buffer is busy
>> and cannot be reused" somewhere to the comments maybe together with a
>> reference to reused_workbuf_in_use.
>
> Not sure where you want to add this. coding.c already says:
That's what I've read and did not understand. It's a bit too concise.
> /* Name (or base name) of work buffer for code conversion. */
> Lisp_Object Vcode_conversion_workbuf_name;
This comment insinuates that there is only one such buffer.
> /* A working buffer used by the top level conversion.
What is the "top level conversion"?
> Once it is
> created, it is never destroyed. It has the name
> Vcode_conversion_workbuf_name. The other working buffers are
> destroyed after the use is finished, and their names are modified
> versions of Vcode_conversion_workbuf_name. */
> static Lisp_Object Vcode_conversion_reused_workbuf;
>
> /* True iff Vcode_conversion_reused_workbuf is already in use. */
> static bool reused_workbuf_in_use;
>
> is that what you wanted to see?
I'd prefer something like a common comment for all these variables
going as
/* The internal work buffers for code conversion are created lazily on
demand. The name of the first buffer created that way is specified
by Vcode_conversion_workbuf_name. Once created, this buffer is no
more deleted in the current Emacs session. While this buffer is in
use, the boolean variable reused_workbuf_in_use is true. This
buffer is reused for new conversions whenever reused_workbuf_in_use
is false.
When reused_workbuf_in_use is true and more code conversion work
has to be done, a new buffer is created. The name of that new
buffer is generated by Fgenerate_new_buffer_name, using
Vcode_conversion_workbuf_name as base name. Any such buffer is
destroyed immediately as soon as it is no more used. */
>> Hopefully this also means that we can use _something like_
>> Fgenerate_new_buffer to replace both instances of Fget_buffer_create
>> in code_conversion_restore.
>
> You mean code_conversion_save, I presume.
You presume correctly.
> One of those calls to Fget_buffer_create shouldn't generate a new
> name, though. It should always use a fixed name.
Fgenerate_new_buffer_name should do that: "If there is no live buffer
named NAME, then return NAME.".
Concludingly, what we need in the present context is a function
- to create a buffer whose name is generated from a base name
argument,
- to set the new buffer's inhibit_buffer_hooks flag according to a
corresponding argument and to not run any hooks when that flag
should be set and the buffer is created,
- that is as internal as possible to avoid that applications misuse it
(it can't be entirely internal since macros like 'with-temp-buffer'
will need it).
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Thu, 23 May 2019 14:38:02 GMT)
Full text and
rfc822 format available.
Message #134 received at 34765 <at> debbugs.gnu.org (full text, mbox):
> Cc: contovob <at> tcd.ie, 34765 <at> debbugs.gnu.org, alexanderm <at> web.de,
> monnier <at> IRO.UMontreal.CA
> From: martin rudalics <rudalics <at> gmx.at>
> Date: Thu, 23 May 2019 10:38:38 +0200
>
> I'd prefer something like a common comment for all these variables
> going as
Your wish is my command. Done.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Fri, 24 May 2019 08:02:02 GMT)
Full text and
rfc822 format available.
Message #137 received at 34765 <at> debbugs.gnu.org (full text, mbox):
> Your wish is my command. Done.
Perfect!
Many thanks, martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Wed, 26 Aug 2020 11:07:01 GMT)
Full text and
rfc822 format available.
Message #140 received at 34765 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
> I attach a preliminary patch.
[...]
> +DEFUN ("generate-new-buffer", Fgenerate_new_buffer, Sgenerate_new_buffer,
> + 1, 2, 0,
> + doc: /* Create and return a buffer with a name based on NAME.
> +Choose the buffer's name using `generate-new-buffer-name'.
> +
> +Optional second argument INHIBIT-BUFFER-HOOKS non-nil means to not run
> +any buffer hooks ('kill-buffer-hook', 'buffer-list-update-hook' or
> +'kill-buffer-query-functions') for this buffer. This argument should
> +be set only for internal buffers that are never presented to users or
> +passed on to other applications. */)
Reading this thread, it seemed like everybody agreed that this patch (in
itself) was a good change, and then the discussion turned to other ways
of specifying "internal" Emacs buffers (that shouldn't have the hooks
run as well, as double-spacing " *temp*", etc).
The latter may be a nice addition, but the patch here is pretty much
necessary for implementing something like that, so was there any reason
the patch wasn't applied?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Sat, 05 Sep 2020 07:07:01 GMT)
Full text and
rfc822 format available.
Message #143 received at 34765 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 34765 <at> debbugs.gnu.org,
> alexanderm <at> web.de, monnier <at> IRO.UMontreal.CA
> Date: Wed, 26 Aug 2020 13:06:13 +0200
>
> martin rudalics <rudalics <at> gmx.at> writes:
>
> > I attach a preliminary patch.
>
> [...]
>
> > +DEFUN ("generate-new-buffer", Fgenerate_new_buffer, Sgenerate_new_buffer,
> > + 1, 2, 0,
> > + doc: /* Create and return a buffer with a name based on NAME.
> > +Choose the buffer's name using `generate-new-buffer-name'.
> > +
> > +Optional second argument INHIBIT-BUFFER-HOOKS non-nil means to not run
> > +any buffer hooks ('kill-buffer-hook', 'buffer-list-update-hook' or
> > +'kill-buffer-query-functions') for this buffer. This argument should
> > +be set only for internal buffers that are never presented to users or
> > +passed on to other applications. */)
>
> Reading this thread, it seemed like everybody agreed that this patch (in
> itself) was a good change, and then the discussion turned to other ways
> of specifying "internal" Emacs buffers (that shouldn't have the hooks
> run as well, as double-spacing " *temp*", etc).
>
> The latter may be a nice addition, but the patch here is pretty much
> necessary for implementing something like that, so was there any reason
> the patch wasn't applied?
AFAIU, the patch was never finalized after the review comments.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Wed, 07 Oct 2020 03:29:01 GMT)
Full text and
rfc822 format available.
Message #146 received at 34765 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> The latter may be a nice addition, but the patch here is pretty much
>> necessary for implementing something like that, so was there any reason
>> the patch wasn't applied?
>
> AFAIU, the patch was never finalized after the review comments.
Right. Martin, did you finish up this patch?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Wed, 07 Oct 2020 08:00:02 GMT)
Full text and
rfc822 format available.
Message #149 received at 34765 <at> debbugs.gnu.org (full text, mbox):
>>> The latter may be a nice addition, but the patch here is pretty much
>>> necessary for implementing something like that, so was there any reason
>>> the patch wasn't applied?
>>
>> AFAIU, the patch was never finalized after the review comments.
>
> Right. Martin, did you finish up this patch?
No. IIRC some issues were never resolved and Basil also wanted to add
something. If you can make heads or tails of it ...
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Sun, 29 Nov 2020 21:04:02 GMT)
Full text and
rfc822 format available.
Message #152 received at 34765 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>>>> The latter may be a nice addition, but the patch here is pretty much
>>>> necessary for implementing something like that, so was there any reason
>>>> the patch wasn't applied?
>>>
>>> AFAIU, the patch was never finalized after the review comments.
>>
>> Right. Martin, did you finish up this patch?
>
> No. IIRC some issues were never resolved and Basil also wanted to add
> something.
Did I? AFAICT I was only pointing out the trivial simplification of
Fgenerate_new_buffer_name + Fget_buffer_create = Fgenerate_new_buffer
once Fgenerate_new_buffer can be called from C.
I was otherwise happy with the patch and either of the proposed
approaches to setting inhibit_buffer_hooks.
> If you can make heads or tails of it ...
Depends: is it an animal or a coin?
--
Basil
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Mon, 30 Nov 2020 09:07:01 GMT)
Full text and
rfc822 format available.
Message #155 received at 34765 <at> debbugs.gnu.org (full text, mbox):
>>>>> The latter may be a nice addition, but the patch here is pretty much
>>>>> necessary for implementing something like that, so was there any reason
>>>>> the patch wasn't applied?
>>>>
>>>> AFAIU, the patch was never finalized after the review comments.
>>>
>>> Right. Martin, did you finish up this patch?
>>
>> No. IIRC some issues were never resolved and Basil also wanted to add
>> something.
>
> Did I? AFAICT I was only pointing out the trivial simplification of
> Fgenerate_new_buffer_name + Fget_buffer_create = Fgenerate_new_buffer
> once Fgenerate_new_buffer can be called from C.
>
> I was otherwise happy with the patch and either of the proposed
> approaches to setting inhibit_buffer_hooks.
>
>> If you can make heads or tails of it ...
>
> Depends: is it an animal or a coin?
Both, probably. If you think that patch is of some use, please try to
polish it up and push it. Honestly, I've forgotten all about it.
And also tell us why 'buffer-list-update-hook' would be still needed now
that we have 'window-selection-change-functions'.
Thanks, martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Mon, 30 Nov 2020 18:08:02 GMT)
Full text and
rfc822 format available.
Message #158 received at 34765 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
> If you think that patch is of some use, please try to
> polish it up and push it. Honestly, I've forgotten all about it.
Sure, I'll give it a go.
I'm slightly confused about the conclusion of this thread, though.
You and Eli said it was too radical to set inhibit_buffer_hooks based
on whether a buffer name starts with a space, as there may be legitimate
cases where those hooks should run in a temporary buffer.
I accept this, but I don't see how setting inhibit_buffer_hooks based on
a new optional argument to Fgenerate_new_buffer (and/or
Fget_buffer_create) solves the problem entirely.
If I create a temporary buffer with the proposed
(generate-new-buffer "foo" t)
then how do I later tell Emacs that this buffer's hooks should run?
In other words, can we be sure that the buffers we choose to create with
inhibit_buffer_hooks set will *never* need to later unset it?
Should we expose a getter or setter for this buffer member, or is that
opening ourselves up to abuse?
I suppose if someone *really* wanted to un-temporarify a buffer with
inhibit_buffer_hooks set, they could create a new, non-temporary buffer
and swap buffer contents, or something to that effect?
Am I wildly misunderstanding something here?
> And also tell us why 'buffer-list-update-hook' would be still needed now
> that we have 'window-selection-change-functions'.
I've yet to look into these hooks and their precise semantics, but are
you suggesting that one might obsolete the other, in which case we
should deprecate the old one?
Thanks,
--
Basil
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Mon, 30 Nov 2020 19:03:01 GMT)
Full text and
rfc822 format available.
Message #161 received at 34765 <at> debbugs.gnu.org (full text, mbox):
> I'm slightly confused about the conclusion of this thread, though.
> You and Eli said it was too radical to set inhibit_buffer_hooks based
> on whether a buffer name starts with a space, as there may be legitimate
> cases where those hooks should run in a temporary buffer.
Yes.
> I accept this, but I don't see how setting inhibit_buffer_hooks based on
> a new optional argument to Fgenerate_new_buffer (and/or
> Fget_buffer_create) solves the problem entirely.
>
> If I create a temporary buffer with the proposed
>
> (generate-new-buffer "foo" t)
>
> then how do I later tell Emacs that this buffer's hooks should run?
>
> In other words, can we be sure that the buffers we choose to create with
> inhibit_buffer_hooks set will *never* need to later unset it?
>
> Should we expose a getter or setter for this buffer member, or is that
> opening ourselves up to abuse?
I'm not sure. But if we do that, we can get rid of the rest: We'd just
generate the new buffer and set/reset its hook inhibitor afterwards.
> I suppose if someone *really* wanted to un-temporarify a buffer with
> inhibit_buffer_hooks set, they could create a new, non-temporary buffer
> and swap buffer contents, or something to that effect?
Admittedly clumsy.
> Am I wildly misunderstanding something here?
I don't think so.
>> And also tell us why 'buffer-list-update-hook' would be still needed now
>> that we have 'window-selection-change-functions'.
>
> I've yet to look into these hooks and their precise semantics, but are
> you suggesting that one might obsolete the other, in which case we
> should deprecate the old one?
People usually don't care about the buffer lists, they always wanted to
run a hook when a window got selected in a more permanent fashion. At
the time of adding 'buffer-list-update-hook', I thought that it
fulfilled some of the criteria wanted for a 'select-window-hook' and
added text in that sense to the manual. So if you care about the buffer
lists, 'buffer-list-update-hook' is the one to use. If you care about
window selection, 'window-selection-change-functions' is the one.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Mon, 30 Nov 2020 19:44:02 GMT)
Full text and
rfc822 format available.
Message #164 received at 34765 <at> debbugs.gnu.org (full text, mbox):
> From: "Basil L. Contovounesios" <contovob <at> tcd.ie>
> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, Eli Zaretskii <eliz <at> gnu.org>,
> 34765 <at> debbugs.gnu.org, alexanderm <at> web.de, monnier <at> IRO.UMontreal.CA
> Date: Mon, 30 Nov 2020 18:07:12 +0000
>
> I'm slightly confused about the conclusion of this thread, though.
> You and Eli said it was too radical to set inhibit_buffer_hooks based
> on whether a buffer name starts with a space, as there may be legitimate
> cases where those hooks should run in a temporary buffer.
>
> I accept this, but I don't see how setting inhibit_buffer_hooks based on
> a new optional argument to Fgenerate_new_buffer (and/or
> Fget_buffer_create) solves the problem entirely.
>
> If I create a temporary buffer with the proposed
>
> (generate-new-buffer "foo" t)
>
> then how do I later tell Emacs that this buffer's hooks should run?
The assumption is that you don't want to. Recall that the original
idea was to turn the hooks off unconditionally based on the buffer's
name. The above is a less drastic measure: it allows the code which
creates the buffer to request that regardless of the name. But the
original motivation, that there are buffers where we want to never run
the hooks, is still valid.
> In other words, can we be sure that the buffers we choose to create with
> inhibit_buffer_hooks set will *never* need to later unset it?
We didn't see examples of such buffers, so we pretend they don't
exist.
> Should we expose a getter or setter for this buffer member
Not until someone comes up crying that this is needed, and presents a
convincing use case, IMO.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Mon, 30 Nov 2020 20:34:02 GMT)
Full text and
rfc822 format available.
Message #167 received at 34765 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>> Should we expose a getter or setter for this buffer member, or is that
>> opening ourselves up to abuse?
>
> I'm not sure. But if we do that, we can get rid of the rest: We'd just
> generate the new buffer and set/reset its hook inhibitor afterwards.
Not necessarily, because Fget_buffer_create still has to run the hook
before returning the buffer.
>>> And also tell us why 'buffer-list-update-hook' would be still needed now
>>> that we have 'window-selection-change-functions'.
>>
>> I've yet to look into these hooks and their precise semantics, but are
>> you suggesting that one might obsolete the other, in which case we
>> should deprecate the old one?
>
> People usually don't care about the buffer lists, they always wanted to
> run a hook when a window got selected in a more permanent fashion. At
> the time of adding 'buffer-list-update-hook', I thought that it
> fulfilled some of the criteria wanted for a 'select-window-hook' and
> added text in that sense to the manual. So if you care about the buffer
> lists, 'buffer-list-update-hook' is the one to use. If you care about
> window selection, 'window-selection-change-functions' is the one.
Thanks, then it sounds to me like there's nothing to be done, other than
recommend the right hook for the right job. Right?
--
Basil
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Mon, 30 Nov 2020 20:36:01 GMT)
Full text and
rfc822 format available.
Message #170 received at 34765 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: "Basil L. Contovounesios" <contovob <at> tcd.ie>
>> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, Eli Zaretskii <eliz <at> gnu.org>,
>> 34765 <at> debbugs.gnu.org, alexanderm <at> web.de, monnier <at> IRO.UMontreal.CA
>> Date: Mon, 30 Nov 2020 18:07:12 +0000
>>
>> If I create a temporary buffer with the proposed
>>
>> (generate-new-buffer "foo" t)
>>
>> then how do I later tell Emacs that this buffer's hooks should run?
>
> The assumption is that you don't want to. Recall that the original
> idea was to turn the hooks off unconditionally based on the buffer's
> name. The above is a less drastic measure: it allows the code which
> creates the buffer to request that regardless of the name. But the
> original motivation, that there are buffers where we want to never run
> the hooks, is still valid.
>
>> In other words, can we be sure that the buffers we choose to create with
>> inhibit_buffer_hooks set will *never* need to later unset it?
>
> We didn't see examples of such buffers, so we pretend they don't
> exist.
>
>> Should we expose a getter or setter for this buffer member
>
> Not until someone comes up crying that this is needed, and presents a
> convincing use case, IMO.
WFM. I'll finish up Martin's patch with some docs then.
Thanks,
--
Basil
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Tue, 01 Dec 2020 09:35:02 GMT)
Full text and
rfc822 format available.
Message #173 received at 34765 <at> debbugs.gnu.org (full text, mbox):
> Thanks, then it sounds to me like there's nothing to be done, other than
> recommend the right hook for the right job. Right?
Right.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Mon, 07 Dec 2020 22:17:02 GMT)
Full text and
rfc822 format available.
Message #176 received at 34765 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
"Basil L. Contovounesios" <contovob <at> tcd.ie> writes:
> I'll finish up Martin's patch with some docs then.
How's the attached? The gist of it is that get-buffer-create and
generate-new-buffer gain a new argument for inhibiting buffer hooks,
which is set in with-temp-buffer, with-temp-file, with-output-to-string,
insert-file-contents, Vprin1_to_string_buffer, and code_conversion_save.
Arising questions:
0. Why isn't kill-buffer-hook defined as a DEFVAR_LISP?
Is it because it has to be defined in init_buffer_once?
If so, why is that the case?
1. Is it okay for with-temp-buffer, with-temp-file, and
with-output-to-string to unconditionally inhibit buffer hooks,
or should this be controlled by e.g. a global variable?
Thanks,
--
Basil
[0001-Inhibit-buffer-hooks-in-temporary-buffers.patch (text/x-diff, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Mon, 07 Dec 2020 22:38:01 GMT)
Full text and
rfc822 format available.
Message #179 received at 34765 <at> debbugs.gnu.org (full text, mbox):
"Basil L. Contovounesios" <contovob <at> tcd.ie> writes:
> +/* Run 'buffer-list-update-hook' if Vrun_hooks is non-nil, and BUF is
> + either NULL or does not have buffer hooks inhibited. */
> +
> +static void
> +run_buffer_list_update_hook (struct buffer *buf) {
^^
Oops, will fix style locally.
> + if (! (NILP (Vrun_hooks) || (buf && buf->inhibit_buffer_hooks)))
> + call1 (Vrun_hooks, Qbuffer_list_update_hook);
> +}
--
Basil
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Tue, 08 Dec 2020 08:10:01 GMT)
Full text and
rfc822 format available.
Message #182 received at 34765 <at> debbugs.gnu.org (full text, mbox):
>> +run_buffer_list_update_hook (struct buffer *buf) {
> ^^
> Oops, will fix style locally.
Incidentally, that was the only thing I found. The rest looks good to
me.
Thank you, martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Mon, 14 Dec 2020 21:04:02 GMT)
Full text and
rfc822 format available.
Message #185 received at 34765 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>>> +run_buffer_list_update_hook (struct buffer *buf) {
>> ^^
>> Oops, will fix style locally.
>
> Incidentally, that was the only thing I found. The rest looks good to
> me.
Thanks. I'll give it a few more days in case Eli, Lars, or anyone else
has any comments/objections before pushing.
--
Basil
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Tue, 15 Dec 2020 16:05:02 GMT)
Full text and
rfc822 format available.
Message #188 received at 34765 <at> debbugs.gnu.org (full text, mbox):
> From: "Basil L. Contovounesios" <contovob <at> tcd.ie>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, larsi <at> gnus.org, 34765 <at> debbugs.gnu.org,
> alexanderm <at> web.de, monnier <at> IRO.UMontreal.CA
> Date: Mon, 14 Dec 2020 21:03:16 +0000
>
> martin rudalics <rudalics <at> gmx.at> writes:
>
> >>> +run_buffer_list_update_hook (struct buffer *buf) {
> >> ^^
> >> Oops, will fix style locally.
> >
> > Incidentally, that was the only thing I found. The rest looks good to
> > me.
>
> Thanks. I'll give it a few more days in case Eli, Lars, or anyone else
> has any comments/objections before pushing.
I will review it soon. Sorry for the delay.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Tue, 15 Dec 2020 16:25:01 GMT)
Full text and
rfc822 format available.
Message #191 received at 34765 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> I will review it soon. Sorry for the delay.
No need to apologise, there's no rush on my end.
Thanks,
--
Basil
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Fri, 18 Dec 2020 14:58:02 GMT)
Full text and
rfc822 format available.
Message #194 received at 34765 <at> debbugs.gnu.org (full text, mbox):
"Basil L. Contovounesios" <contovob <at> tcd.ie> writes:
> (defmacro with-temp-file (file &rest body)
> "Create a new buffer, evaluate BODY there, and write the buffer to FILE.
> The value returned is the value of the last form in BODY.
> -See also `with-temp-buffer'."
> +The buffer is created using `with-temp-buffer', which see."
> (declare (indent 1) (debug t))
> - (let ((temp-file (make-symbol "temp-file"))
> - (temp-buffer (make-symbol "temp-buffer")))
> - `(let ((,temp-file ,file)
> - (,temp-buffer (generate-new-buffer " *temp file*")))
> - (unwind-protect
> - (prog1
> - (with-current-buffer ,temp-buffer
> - ,@body)
> - (with-current-buffer ,temp-buffer
> - (write-region nil nil ,temp-file nil 0)))
> - (and (buffer-name ,temp-buffer)
> - (kill-buffer ,temp-buffer))))))
> + `(with-temp-buffer
> + (prog1 (progn ,@body)
> + (write-region nil nil ,file nil 0))))
Reading another thread made me realise that this changes the argument
evaluation order, so I'll fix that too.
--
Basil
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Fri, 18 Dec 2020 15:37:02 GMT)
Full text and
rfc822 format available.
Message #197 received at 34765 <at> debbugs.gnu.org (full text, mbox):
> (defmacro with-temp-file (file &rest body)
> "Create a new buffer, evaluate BODY there, and write the buffer to FILE.
> The value returned is the value of the last form in BODY.
> -See also `with-temp-buffer'."
> +The buffer is created using `with-temp-buffer', which see."
> (declare (indent 1) (debug t))
> - (let ((temp-file (make-symbol "temp-file"))
> - (temp-buffer (make-symbol "temp-buffer")))
> - `(let ((,temp-file ,file)
> - (,temp-buffer (generate-new-buffer " *temp file*")))
> - (unwind-protect
> - (prog1
> - (with-current-buffer ,temp-buffer
> - ,@body)
> - (with-current-buffer ,temp-buffer
> - (write-region nil nil ,temp-file nil 0)))
> - (and (buffer-name ,temp-buffer)
> - (kill-buffer ,temp-buffer))))))
> + `(with-temp-buffer
> + (prog1 (progn ,@body)
> + (write-region nil nil ,file nil 0))))
You lost the `(with-current-buffer ,temp-buffer` around `write-region`
so your new code will break if `body` doesn't preserve current-buffer.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Fri, 18 Dec 2020 18:51:02 GMT)
Full text and
rfc822 format available.
Message #200 received at 34765 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> You lost the `(with-current-buffer ,temp-buffer` around `write-region`
> so your new code will break if `body` doesn't preserve current-buffer.
Ugh, I thought the caller couldn't kill the buffer because it's later
written, but I didn't think of excursions. I've now attached an updated
patch.
Thanks,
--
Basil
[0001-Inhibit-buffer-hooks-in-temporary-buffers.patch (text/x-diff, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Sat, 19 Dec 2020 10:35:01 GMT)
Full text and
rfc822 format available.
Message #203 received at 34765 <at> debbugs.gnu.org (full text, mbox):
> From: "Basil L. Contovounesios" <contovob <at> tcd.ie>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, rudalics <at> gmx.at, larsi <at> gnus.org,
> 34765 <at> debbugs.gnu.org, alexanderm <at> web.de
> Date: Fri, 18 Dec 2020 18:49:52 +0000
>
> * .dir-locals.el (c-mode): Enforce existing indent-tabs-mode policy.
This should be in a separate commit, IMO.
> +By default, undo information (@pxref{Undo}) is not recorded in the
> +buffer created by this macro (but @var{body} can enable that, if
> +needed). The temporary buffer also does not run the hooks
> +@code{kill-buffer-hook}, @code{kill-buffer-query-functions}
> +(@pxref{Killing Buffers}), and @code{buffer-list-update-hook}
> +(@pxref{Buffer List}).
It would be good to have here index entries about undo and those hooks
not being used by default in temporary buffers.
> +Like @code{with-temp-buffer} (@pxref{Definition of with-temp-buffer,,
^^^^^^^^^^
I think this word will look better if not capitalized.
> +static void
> +run_buffer_list_update_hook (struct buffer *buf)
> +{
> + if (! (NILP (Vrun_hooks) || (buf && buf->inhibit_buffer_hooks)))
^^^
Why this test? is it possible for this function to be called with buf
a NULL pointer?
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Sat, 19 Dec 2020 14:16:01 GMT)
Full text and
rfc822 format available.
Message #206 received at 34765 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: "Basil L. Contovounesios" <contovob <at> tcd.ie>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>, rudalics <at> gmx.at, larsi <at> gnus.org,
>> 34765 <at> debbugs.gnu.org, alexanderm <at> web.de
>> Date: Fri, 18 Dec 2020 18:49:52 +0000
>>
>> * .dir-locals.el (c-mode): Enforce existing indent-tabs-mode policy.
>
> This should be in a separate commit, IMO.
Okay, I pushed it separately.
>> +By default, undo information (@pxref{Undo}) is not recorded in the
>> +buffer created by this macro (but @var{body} can enable that, if
>> +needed). The temporary buffer also does not run the hooks
>> +@code{kill-buffer-hook}, @code{kill-buffer-query-functions}
>> +(@pxref{Killing Buffers}), and @code{buffer-list-update-hook}
>> +(@pxref{Buffer List}).
>
> It would be good to have here index entries about undo and those hooks
> not being used by default in temporary buffers.
Something like this?
@cindex undo in temporary buffers
@cindex @code{kill-buffer-hook} in temporary buffers
@cindex @code{kill-buffer-query-functions} in temporary buffers
@cindex @code{buffer-list-update-hook} in temporary buffers
>> +Like @code{with-temp-buffer} (@pxref{Definition of with-temp-buffer,,
> ^^^^^^^^^^
> I think this word will look better if not capitalized.
The printed label "see Current Buffer" should be displayed instead of
this word, which is part of the anchor. Is that okay?
>> +static void
>> +run_buffer_list_update_hook (struct buffer *buf)
>> +{
>> + if (! (NILP (Vrun_hooks) || (buf && buf->inhibit_buffer_hooks)))
> ^^^
> Why this test? is it possible for this function to be called with buf
> a NULL pointer?
Yes, in Fmake_indirect_buffer, which doesn't check inhibit_buffer_hooks.
The alternatives would be for Fmake_indirect_buffer to not call
run_buffer_list_update_hook, or to not bother adding
run_buffer_list_update_hook at all. Do you have a preference?
Thanks,
--
Basil
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Sat, 19 Dec 2020 16:07:01 GMT)
Full text and
rfc822 format available.
Message #209 received at 34765 <at> debbugs.gnu.org (full text, mbox):
> From: "Basil L. Contovounesios" <contovob <at> tcd.ie>
> Cc: monnier <at> iro.umontreal.ca, rudalics <at> gmx.at, larsi <at> gnus.org,
> 34765 <at> debbugs.gnu.org, alexanderm <at> web.de
> Date: Sat, 19 Dec 2020 14:15:30 +0000
>
> >> +By default, undo information (@pxref{Undo}) is not recorded in the
> >> +buffer created by this macro (but @var{body} can enable that, if
> >> +needed). The temporary buffer also does not run the hooks
> >> +@code{kill-buffer-hook}, @code{kill-buffer-query-functions}
> >> +(@pxref{Killing Buffers}), and @code{buffer-list-update-hook}
> >> +(@pxref{Buffer List}).
> >
> > It would be good to have here index entries about undo and those hooks
> > not being used by default in temporary buffers.
>
> Something like this?
>
> @cindex undo in temporary buffers
> @cindex @code{kill-buffer-hook} in temporary buffers
> @cindex @code{kill-buffer-query-functions} in temporary buffers
> @cindex @code{buffer-list-update-hook} in temporary buffers
Yes.
> >> +Like @code{with-temp-buffer} (@pxref{Definition of with-temp-buffer,,
> > ^^^^^^^^^^
> > I think this word will look better if not capitalized.
>
> The printed label "see Current Buffer" should be displayed instead of
> this word, which is part of the anchor. Is that okay?
Sorry, I didn't see that this is an anchor. So I think the anchor
should not start with a capital letter, as it reads more naturally
that way, I think. And then the name should be used without
capitalization in the cross-references. Obviously, this is a minor
nit.
> >> +static void
> >> +run_buffer_list_update_hook (struct buffer *buf)
> >> +{
> >> + if (! (NILP (Vrun_hooks) || (buf && buf->inhibit_buffer_hooks)))
> > ^^^
> > Why this test? is it possible for this function to be called with buf
> > a NULL pointer?
>
> Yes, in Fmake_indirect_buffer, which doesn't check inhibit_buffer_hooks.
>
> The alternatives would be for Fmake_indirect_buffer to not call
> run_buffer_list_update_hook, or to not bother adding
> run_buffer_list_update_hook at all. Do you have a preference?
I think just having a comment there saying that make-indirect-buffer
calls this with NULL argument should be okay.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Sat, 19 Dec 2020 21:11:01 GMT)
Full text and
rfc822 format available.
Message #212 received at 34765 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Something like this?
>>
>> @cindex undo in temporary buffers
>> @cindex @code{kill-buffer-hook} in temporary buffers
>> @cindex @code{kill-buffer-query-functions} in temporary buffers
>> @cindex @code{buffer-list-update-hook} in temporary buffers
>
> Yes.
Done.
>> >> +Like @code{with-temp-buffer} (@pxref{Definition of with-temp-buffer,,
>> > ^^^^^^^^^^
>> > I think this word will look better if not capitalized.
>>
>> The printed label "see Current Buffer" should be displayed instead of
>> this word, which is part of the anchor. Is that okay?
>
> Sorry, I didn't see that this is an anchor. So I think the anchor
> should not start with a capital letter, as it reads more naturally
> that way, I think. And then the name should be used without
> capitalization in the cross-references. Obviously, this is a minor
> nit.
I'm hesitant to change the anchor because all 37 such "Definition of..."
anchors in the tree are capitalised, as are the printed labels of all
their refs.
I'm happy to downcase them, but maybe this should be done wholesale in a
separate commit?
>> >> +static void
>> >> +run_buffer_list_update_hook (struct buffer *buf)
>> >> +{
>> >> + if (! (NILP (Vrun_hooks) || (buf && buf->inhibit_buffer_hooks)))
>> > ^^^
>> > Why this test? is it possible for this function to be called with buf
>> > a NULL pointer?
>>
>> Yes, in Fmake_indirect_buffer, which doesn't check inhibit_buffer_hooks.
>>
>> The alternatives would be for Fmake_indirect_buffer to not call
>> run_buffer_list_update_hook, or to not bother adding
>> run_buffer_list_update_hook at all. Do you have a preference?
>
> I think just having a comment there saying that make-indirect-buffer
> calls this with NULL argument should be okay.
How's the attached?
Thanks,
--
Basil
[0001-Inhibit-buffer-hooks-in-temporary-buffers.patch (text/x-diff, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Sun, 20 Dec 2020 15:06:01 GMT)
Full text and
rfc822 format available.
Message #215 received at 34765 <at> debbugs.gnu.org (full text, mbox):
> From: "Basil L. Contovounesios" <contovob <at> tcd.ie>
> Cc: monnier <at> iro.umontreal.ca, rudalics <at> gmx.at, larsi <at> gnus.org,
> 34765 <at> debbugs.gnu.org, alexanderm <at> web.de
> Date: Sat, 19 Dec 2020 21:10:13 +0000
>
> >> The printed label "see Current Buffer" should be displayed instead of
> >> this word, which is part of the anchor. Is that okay?
> >
> > Sorry, I didn't see that this is an anchor. So I think the anchor
> > should not start with a capital letter, as it reads more naturally
> > that way, I think. And then the name should be used without
> > capitalization in the cross-references. Obviously, this is a minor
> > nit.
>
> I'm hesitant to change the anchor because all 37 such "Definition of..."
> anchors in the tree are capitalised, as are the printed labels of all
> their refs.
>
> I'm happy to downcase them, but maybe this should be done wholesale in a
> separate commit?
That's okay, let's leave the anchor capitalization alone for now.
> >> The alternatives would be for Fmake_indirect_buffer to not call
> >> run_buffer_list_update_hook, or to not bother adding
> >> run_buffer_list_update_hook at all. Do you have a preference?
> >
> > I think just having a comment there saying that make-indirect-buffer
> > calls this with NULL argument should be okay.
>
> How's the attached?
LGTM, thanks.
Added tag(s) fixed.
Request was from
"Basil L. Contovounesios" <contovob <at> tcd.ie>
to
control <at> debbugs.gnu.org.
(Sun, 20 Dec 2020 17:58:02 GMT)
Full text and
rfc822 format available.
bug marked as fixed in version 28.1, send any further explanations to
34765 <at> debbugs.gnu.org and Alexander Miller <alexanderm <at> web.de>
Request was from
"Basil L. Contovounesios" <contovob <at> tcd.ie>
to
control <at> debbugs.gnu.org.
(Sun, 20 Dec 2020 17:58:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34765; Package
emacs.
(Sun, 20 Dec 2020 17:58:03 GMT)
Full text and
rfc822 format available.
Message #222 received at 34765-done <at> debbugs.gnu.org (full text, mbox):
tags 34765 fixed
close 34765 28.1
quit
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: "Basil L. Contovounesios" <contovob <at> tcd.ie>
>> Cc: monnier <at> iro.umontreal.ca, rudalics <at> gmx.at, larsi <at> gnus.org,
>> 34765 <at> debbugs.gnu.org, alexanderm <at> web.de
>> Date: Sat, 19 Dec 2020 21:10:13 +0000
>>
>> How's the attached?
>
> LGTM, thanks.
Thanks. Pushed to master, and closing.
Inhibit buffer hooks in temporary buffers
1a0a11f7d2 2020-12-20 17:32:24 +0000
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=1a0a11f7d2d1dbecb9f754b1e129d50e489058e6
--
Basil
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Mon, 18 Jan 2021 12:24:07 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 91 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.