bug#72999: 29.4; fill-paragraph error in latex mode
--text follows this line--
If I have buffer like this:
Foo \cite{bar} bar.
And press `M-q` I get error:
LaTeX-indent-calculate-last: Wrong type argument: stringp, nil
In GNU Emacs 29.4 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.20,
cairo version 1.16.0) of 2024-06-23 built on lcy02-amd64-050
Repository revision: 176061eb965cf945e7627ce87bb16ec5a03f8a4d
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101007
System Description: Ubuntu 23.10
Configured using:
'configure --prefix=/snap/emacs/current/usr --with-x-toolkit=gtk3
--without-xaw3d --with-modules --with-cairo
--with-native-compilation=aot --without-pgtk --with-xinput2
--with-tree-sitter --with-json
'CFLAGS=-isystem/build/emacs/parts/emacs/install/usr/include
-isystem/build/emacs/parts/emacs/install/usr/include/x86_64-linux-gnu
-isystem/build/emacs/stage/usr/include -O2'
'CPPFLAGS=-isystem/build/emacs/parts/emacs/install/usr/include
-isystem/build/emacs/parts/emacs/install/usr/include/x86_64-linux-gnu
-isystem/build/emacs/stage/usr/include'
'LDFLAGS=-L/build/emacs/parts/emacs/install/lib
-L/build/emacs/parts/emacs/install/usr/lib
-L/build/emacs/parts/emacs/install/lib/x86_64-linux-gnu
-L/build/emacs/parts/emacs/install/usr/lib/x86_64-linux-gnu
-L/build/emacs/stage/usr/lib''
Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES
NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3
THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER X11 XDBE XIM XINPUT2 XPM
GTK3 ZLIB
Important settings:
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
Major mode: LaTeX
Minor modes in effect:
helm-mode: t
helm-minibuffer-history-mode: t
TeX-PDF-mode: t
lsp-diagnostics-mode: t
lsp-modeline-workspace-status-mode: t
lsp-modeline-diagnostics-mode: t
lsp-modeline-code-actions-mode: t
savehist-mode: t
lsp-ui-mode: t
lsp-ui-sideline-mode: t
flycheck-mode: t
lsp-managed-mode: t
lsp-mode: t
doom-modeline-mode: t
helm-file-preview-mode: t
delete-selection-mode: t
global-git-commit-mode: t
magit-auto-revert-mode: t
auto-revert-mode: t
server-mode: t
shell-dirtrack-mode: t
async-bytecomp-package-mode: t
override-global-mode: t
tooltip-mode: t
global-eldoc-mode: t
eldoc-mode: t
show-paren-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
line-number-mode: t
transient-mark-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
Load-path shadows:
/home/lord/.emacs.d/elpa/transient-20240831.2233/transient hides
/snap/emacs/current/usr/share/emacs/29.4/lisp/transient
Features:
(mailalias mailclient textsec uni-scripts idna-mapping ucs-normalize
uni-confusable textsec-check shadow sort mail-extr emacsbug mm-archive
url-cache url-http url-auth url-gw shortdoc help-fns radix-tree python
sh-script treesit executable conf-mode vc-hg vc-bzr vc-src vc-sccs
vc-svn vc-cvs vc-rcs log-view bug-reference magit-extras chatgpt-shell
shell-maker ielm eshell esh-mode esh-cmd esh-ext esh-opt esh-proc esh-io
esh-arg esh-module esh-groups esh-util helm-command helm-elisp helm-eval
edebug debug backtrace helm-info helm-mode helm-misc misearch
multi-isearch preview tex-mode font-latex latex latex-flymake tex-ispell
tex-style tex texmathp latexenc image-file image-converter winner
helm-external helm-net tramp-archive tramp-gvfs tramp-cache time-stamp
zeroconf ffap lsp-diagnostics lsp-modeline lsp-lens mule-util
display-line-numbers lsp-zig lsp-yang lsp-yaml lsp-xml lsp-wgsl
lsp-volar lsp-vimscript lsp-vhdl lsp-vetur lsp-html lsp-verilog lsp-vala
lsp-v lsp-typeprof lsp-ttcn3 lsp-trunk lsp-toml lsp-tilt lsp-tex
lsp-terraform lsp-svelte lsp-steep lsp-sqls lsp-sql lsp-sorbet
lsp-solidity lsp-solargraph lsp-semgrep lsp-rust lsp-ruff-lsp
lsp-ruby-syntax-tree lsp-ruby-lsp lsp-rubocop lsp-roslyn lsp-rf
lsp-remark lsp-racket lsp-r lsp-qml lsp-pylsp lsp-pyls lsp-pwsh
lsp-purescript lsp-pls lsp-php lsp-perlnavigator lsp-perl lsp-openscad
lsp-ocaml lsp-nushell lsp-nix lsp-nim lsp-nginx lsp-move lsp-mojo
lsp-mint lsp-meson lsp-mdx lsp-marksman lsp-markdown lsp-magik lsp-lua
lsp-lisp lsp-kotlin lsp-json lsp-jq lsp-javascript lsp-idris lsp-haxe
lsp-hack lsp-groovy lsp-graphql lsp-golangci-lint lsp-glsl lsp-gleam
lsp-gdscript lsp-fsharp lsp-fortran lsp-eslint lsp-erlang lsp-emmet
lsp-elm lsp-elixir lsp-earthly lsp-dockerfile lsp-dhall lsp-d lsp-cypher
lsp-cucumber lsp-css lsp-csharp lsp-crystal lsp-credo lsp-cobol
lsp-cmake lsp-clojure lsp-clangd lsp-bufls lsp-go lsp-completion
lsp-beancount lsp-bash lsp-awk lsp-autotools lsp-astro lsp-asm
lsp-ansible lsp-angular lsp-ada lsp-semantic-tokens lsp-actionscript
oc-basic ol-eww eww url-queue mm-url ol-rmail ol-mhe ol-irc ol-info
ol-gnus nnselect gnus-art mm-uu mml20
bug#72995: 31.0.50; widget-move fails when widget starts at the second character in the buffer
On Mon, 2 Sep 2024 23:36:35 -0500 Dale wrote: > I think changes in commit 94dec95 (bug#69943) broke `widget-move' in a > customize buffer when trying to move to the first widget in a buffer when that > first widget starts at the second character in the buffer. Here's some code > to reproduce (tested in IELM): > > (let* ((first-wid (progn (widget-forward 1) (point > (print (format "First widget at %S" first-wid)) > (cl-assert (and (numberp first-wid) (>= first-wid 1))) > (with-current-buffer (customize-group 'editing) > (narrow-to-region (1- first-wid) (point-max)) > (goto-char (point-min)) > (widget-forward 1) > (print (format "Expected to be at %S, point=%S" first-wid (point) > > On my Emacs I get: > > "First widget at 33" > > "Expected to be at 33, point=32" > > I think this happens because of this code near the end of `widget-move' (which > is called by `widget-forward'): > > (let ((new (widget-tabable-at))) > (while (and (eq (widget-tabable-at) new) (not (bobp))) > (backward-char))) > (unless (bobp) (forward-char))) > > In my test case, as we enter the while loop point is at the start of the first > widget (AKA "new"). We are not yet at beginning of buffer, so it moves point > back one character. Now we are at beginning of buffer, but that doesn't > matter: the `eq' test fails first, and the loop ends. > > However, the `forward-char' never runs because we are indeed at beginning of > buffer now. I think this `forward-char' should have been run to put point > back on the start of the widget. > > Bug#70594 also recently modified code around here, but I don't *think* that's > relevant. > > In case you're wondering, this comes up because I use link-hint[1], which > narrows a customize buffer in exactly the way shown above. > > [1]: https://github.com/noctuid/link-hint.el > > Please let me know if I can provide any more information! Thanks for the bug report, which indeed shows a use case that the change in commit 94dec95 fails to account for. The reason that commit conditionalized the call to forward-char was to ensure that tabbing puts point at the start of the widget, but your case shows using just (bobp) as the condition is insufficient (I used that because the existing unit test for widget-move has the first widget starting at BOB). I think the following patch closes this gap: diff --git a/lisp/wid-edit.el b/lisp/wid-edit.el index e7e6351fcab..7eec06297ce 100644 --- a/lisp/wid-edit.el +++ b/lisp/wid-edit.el @@ -1336,7 +1336,7 @@ widget-move (let ((new (widget-tabable-at))) (while (and (eq (widget-tabable-at) new) (not (bobp))) (backward-char))) -(unless (bobp) (forward-char))) +(unless (and (widget-tabable-at) (bobp)) (forward-char))) (unless suppress-echo (widget-echo-help (point))) (run-hooks 'widget-move-hook)) Can you confirm that this fixes your use case? If so, I think it should go into emacs-30, since that's where the faulty commit first appeared. I'll also add a unit test for this case. Steve Berman
bug#72999: 29.4; fill-paragraph error in latex mode
Vadim Zaliva writes:
> If I have buffer like this:
>
> Foo \cite{bar} bar.
>
> And press `M-q` I get error:
>
> LaTeX-indent-calculate-last: Wrong type argument: stringp, nil
> [...]
> Major mode: LaTeX
It seems you're running AUCTeX as major-mode and not the builtin one.
Which version of AUCTeX are you using and how did you install it?
At any rate, I can't reproduce what you describe with this small file:
--8<---cut here---start->8---
\documentclass{article}
\begin{document}
Foo \cite{bar} bar.! Point here hitting M-q
\end{document}
%%% Local Variables:
%%% mode: LaTeX
%%% TeX-master: t
%%% End:
--8<---cut here---end--->8---
Can you come up with a recipe to reproduce with:
• Start Emacs with 'emacs -Q'
• Activate AUCTeX by eval'ing this in scratch (presuming you've
installed AUCTeX from ELPA):
(progn
(setq debug-on-error t)
(package-initialize t)
(package-activate 'auctex))
• In the file above (or any other example), tell us exactly where to put
the cursor before hitting 'M-q'
• Show what the debugger says in your case.
Best, Arash
bug#72986: Disabling menu-bar-mode changes size of new frames
> Date: Mon, 2 Sep 2024 19:48:57 +0100 > From: Reuben Thomas via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > Reproduction with Emacs 29.3 (also with git master HEAD, see below). > > Run: emacs -Q > C-x 5 2 ; window opens the same size as the initial window > M-x menu-bar-mode RET ; disable menu-bar-mode > C-x 52 ; window opens much smaller than initial window > > With master HEAD (commit 92ea393a16e), the situation is slightly different: > > Run: emacs -Q > C-x 52 ; window opens much smaller than initial window I cannot reproduce this, but I'm not on X. Here on MS-Windows, disabling menu-bar-mode makes the frames one line smaller, and thereafter "C-x 5 2" creates frames whose dimensions are exactly identical to the existing frames. As expected. I see the above both in Emacs 29, on the current emacs-30 release branch, and on master. > I'm running on Ubuntu 24.04, under GNOME 46 with X11. I don't have any Emacs > X resources set. You didn't say which toolkit did you build with. It might be important. Adding Martin and Po Lu in the hope that they will have comments and/or suggestions.
bug#72986: Disabling menu-bar-mode changes size of new frames
On Tue, 3 Sept 2024 at 13:07, Eli Zaretskii wrote: > > You didn't say which toolkit did you build with. It might be > important. > gtk-3 in both cases. -- https://rrt.sc3d.org
bug#69097: [PATCH] Add 'kill-region-or-word' command
> From: Philip Kaludercic > Cc: Eli Zaretskii , Stefan Kangas , > Andrea Corallo , j...@linkov.net, r...@gnu.org, > 69...@debbugs.gnu.org > Date: Mon, 02 Sep 2024 21:12:01 + > > I had misremembered the last state of this patch. It is easier to just > have a tristate option. Here is the updated proposal: Thanks. > +(defcustom kill-word-if-no-region nil I would call this 'kill-region-dwim' instead. > + "Behaviour when `kill-region' is invoked without an active region. > +If set to nil (default), then an error occurs and nothing is killed. If > +set to `emacs-word', then kill a the last word as defined by the current > +major mode. If set to `unix-word', then kill the last word in the style > +of a shell like Bash, disregarding the major mode." > + :type '(choice (const :tag "Kill a word like `backward-kill-word'" > emacs-word) > + (const :tag "Kill a word like Bash would" unix-word) > + (const :tag "Do not kill anything" nil)) > + :group 'killing) :version tag is missing. > -Lisp programs should use this function for killing text. > - (To delete text, use `delete-region'.) > -Supply two arguments, character positions BEG and END indicating the > - stretch of text to be killed. If the optional argument REGION is > - non-nil, the function ignores BEG and END, and kills the current > - region instead. Interactively, REGION is always non-nil, and so > - this command always kills the current region." > +Lisp programs should use this function for killing text. (To delete > +text, use `delete-region'.) Supply two arguments, character positions > +BEG and END indicating the stretch of text to be killed. If the > +optional argument REGION is non-nil, the function ignores BEG and END, > +and kills the current region instead. If REGION has the special value Not sure why you decided to reformat this part. Its formatting was not random. This also needs a NEWS entry.
bug#72995: 31.0.50; widget-move fails when widget starts at the second character in the buffer
> From: Dale > Date: Mon, 2 Sep 2024 23:36:35 -0500 > > I think changes in commit 94dec95 (bug#69943) broke `widget-move' in a > customize buffer when trying to move to the first widget in a buffer when > that first widget starts at the second character in the buffer. Here's some > code to reproduce (tested in IELM): > > (let* ((first-wid (progn (widget-forward 1) (point > (print (format "First widget at %S" first-wid)) > (cl-assert (and (numberp first-wid) (>= first-wid 1))) > (with-current-buffer (customize-group 'editing) > (narrow-to-region (1- first-wid) (point-max)) > (goto-char (point-min)) > (widget-forward 1) > (print (format "Expected to be at %S, point=%S" first-wid (point) > > On my Emacs I get: > > "First widget at 33" > > "Expected to be at 33, point=32" > > I think this happens because of this code near the end of `widget-move' > (which is called by `widget-forward'): > > (let ((new (widget-tabable-at))) > (while (and (eq (widget-tabable-at) new) (not (bobp))) > (backward-char))) > (unless (bobp) (forward-char))) > > In my test case, as we enter the while loop point is at the start of the > first widget (AKA "new"). We are not yet at beginning of buffer, so it moves > point back one character. Now we are at beginning of buffer, but that > doesn't matter: the `eq' test fails first, and the loop ends. > > However, the `forward-char' never runs because we are indeed at beginning of > buffer now. I think this `forward-char' should have been run to put point > back on the start of the widget. > > Bug#70594 also recently modified code around here, but I don't *think* that's > relevant. > > In case you're wondering, this comes up because I use link-hint[1], which > narrows a customize buffer in exactly the way shown above. > > [1]: https://github.com/noctuid/link-hint.el > > Please let me know if I can provide any more information! > > Best regards, > Dale Stephen, could you please look into this?
bug#72993: 31.0.50; 4f521fa14c18f57e5207bffd68e9f79454dccc79 breaks binding mode hooks in use-package
> From: John Wiegley > Cc: Steven Allen , 72...@debbugs.gnu.org > Date: Mon, 02 Sep 2024 21:37:54 -0700 > > > Eli Zaretskii writes: > > >> To reproduce: > >> > >> (use-package foo > >> :hook (eshell-mode . some-function)) > >> > >> Previously, `use-package' always appended `-hook' to the hook variable > >> name. > >> After 4f521fa14c18f57e5207bffd68e9f79454dccc79, `use-package' only does > >> so if the passed variable name isn't bound. Unfortunately, this breaks > >> binding mode hooks, e.g.: > >> > >> :hook (some-mode . some-function) > >> > >> Because `some-mode' is usually bound. > > > John, any comments or suggestions? > > Sigh, I should have thought of this. There will be many such collisions, in > fact. > > Perhaps we should avoid auto -hook’ifying the variable name only if the name > does not already end in ‘-functions’? Either that, or maybe exempt FOO-mode from the boundp test.
bug#72999: 29.4; fill-paragraph error in latex mode
> Date: Tue, 3 Sep 2024 08:46:10 +0200
> From: Vadim Zaliva
>
> If I have buffer like this:
>
> Foo \cite{bar} bar.
>
> And press `M-q` I get error:
>
> LaTeX-indent-calculate-last: Wrong type argument: stringp, nil
I cannot reproduce this in "emacs -Q", and I see no function named
LaTeX-indent-calculate-last anywhere in Emacs. I suspect this comes
from some add-on package you have installed.
bug#72960: 31.0.50; PGTK Wayland exhibits more lag than X11 version
> Date: Tue, 03 Sep 2024 12:27:09 +0100 > From: "Stephane Travostino" > Cc: 72...@debbugs.gnu.org > > On Mon, 2 Sep 2024, at 13:12, Stephane Travostino wrote: > > On Mon, 2 Sep 2024, at 13:05, Eli Zaretskii wrote: > >>> Date: Mon, 02 Sep 2024 10:18:03 +0100 > >>> From: "Stephane Travostino" > >>> > >>> Heavy operations, such as scrolling back and forth in a buffer, are > >>> noticeably laggier, for lack of better word, in the PGTK/Wayland version > >>> than the X11, both tested on KDE in Wayland mode. > >>> > >>> Affects both 29.2 and the latest HEAD compiled a few days ago. > >>> > >>> I am unsure whether it is a KDE or Emacs problem. > >>> > >>> Running on an AMD RX 6800 XT graphics card on a HiDPI 4k screen at 2x > >>> scaling. > >> > >> AFAIU, this is a problem with GTK input methods. From PROBLEMS: > >> > >> *** Emacs built with GTK lags in its response to keyboard input. > >> This can happen when input methods are used. It happens because Emacs > >> behaves in an unconventional way with respect to GTK input methods: it > >> registers to receive keyboard input as unprocessed key events with > >> metadata (as opposed to receiving them as text strings). Most GTK > >> programs use the latter approach, so some modern input methods have > >> bugs and misbehave when faced with the way Emacs does it. > >> > >> A workaround is to set GTK_IM_MODULE=none in the environment, or maybe > >> find a different input method without these problems. > > > > Thank you, though without more scientific methods of measuring latency > > I can't tell if that helps or not. > > > > I noticed I had pixel precision scrolling mode on and that contributed > > a large part to that feeling of lag compared to other programs. If > > Firefox is able to smooth scroll at 60 Hz, I would say empirically > > Emacs PGTK would scroll at 15 Hz, making navigation in the buffer a > > choppy affair. > > Update: GTK_IM_MODULE=none does not make it any less laggier. It is mostly > felt in typing and editing source code, and switching to the X11 build makes > it immensely snappier and doesn't feel like I'm working through a remote > connection. Please try profiling the lagging cases with "M-x profiler", and post the profile here. Po Lu, any other ideas or suggestions? > FYI there are other reports online of people noticing major latency in HiDPI > mode with the PGTK version, especially when the frame is fullscreen (so > there's more pixels to update): > > https://old.reddit.com/r/emacs/comments/ucv0at/awful_performance_with_pgtk_on_wayland/ > > https://old.reddit.com/r/emacs/comments/1acdieh/pgtk_emacs_high_input_lag_at_large_frame_sizes_on/ I don't doubt what you report is real.
bug#72960: 31.0.50; PGTK Wayland exhibits more lag than X11 version
On Mon, 2 Sep 2024, at 13:12, Stephane Travostino wrote: > On Mon, 2 Sep 2024, at 13:05, Eli Zaretskii wrote: >>> Date: Mon, 02 Sep 2024 10:18:03 +0100 >>> From: "Stephane Travostino" >>> >>> Heavy operations, such as scrolling back and forth in a buffer, are >>> noticeably laggier, for lack of better word, in the PGTK/Wayland version >>> than the X11, both tested on KDE in Wayland mode. >>> >>> Affects both 29.2 and the latest HEAD compiled a few days ago. >>> >>> I am unsure whether it is a KDE or Emacs problem. >>> >>> Running on an AMD RX 6800 XT graphics card on a HiDPI 4k screen at 2x >>> scaling. >> >> AFAIU, this is a problem with GTK input methods. From PROBLEMS: >> >> *** Emacs built with GTK lags in its response to keyboard input. >> This can happen when input methods are used. It happens because Emacs >> behaves in an unconventional way with respect to GTK input methods: it >> registers to receive keyboard input as unprocessed key events with >> metadata (as opposed to receiving them as text strings). Most GTK >> programs use the latter approach, so some modern input methods have >> bugs and misbehave when faced with the way Emacs does it. >> >> A workaround is to set GTK_IM_MODULE=none in the environment, or maybe >> find a different input method without these problems. > > Thank you, though without more scientific methods of measuring latency > I can't tell if that helps or not. > > I noticed I had pixel precision scrolling mode on and that contributed > a large part to that feeling of lag compared to other programs. If > Firefox is able to smooth scroll at 60 Hz, I would say empirically > Emacs PGTK would scroll at 15 Hz, making navigation in the buffer a > choppy affair. Update: GTK_IM_MODULE=none does not make it any less laggier. It is mostly felt in typing and editing source code, and switching to the X11 build makes it immensely snappier and doesn't feel like I'm working through a remote connection. FYI there are other reports online of people noticing major latency in HiDPI mode with the PGTK version, especially when the frame is fullscreen (so there's more pixels to update): https://old.reddit.com/r/emacs/comments/ucv0at/awful_performance_with_pgtk_on_wayland/ https://old.reddit.com/r/emacs/comments/1acdieh/pgtk_emacs_high_input_lag_at_large_frame_sizes_on/
bug#72765: Eglot + Clangd + Company + non-empty suffix = duplicate text
On 01/09/2024 17:28, Dmitry Gutov wrote: * the rust-analyzer test you added recently -- and which you said was very brittle -- is indeed very brittle: I cannot get it to pass. We should fix it, or just delete it and do those rust-analyzer tests manually each time we touch this area. Could you give more details? It is indeed more brittle in theory, but on my machine it's passing every time. Yeah, I see it now - it succeeds in an interactive session and fails in batch mode. Not sure it was the same when the patch was committed (hopefully not). Might be due to window configuration being different...
bug#73004: [PATCH] Make `dired-do-open' work on non GNU/Linux systems
Tags: patch Hi, Here is a patch to make `dired-do-open' work on some non GNU/Linux systems. I have tested it on OpenBSD with "xdg-open" installed. Thanks, In GNU Emacs 31.0.50 (build 19, x86_64-unknown-openbsd7.6) of 2024-09-02 built on computer Repository revision: 92ea393a16e5c99a8860dab368c6ca3ca6abc3c5 Repository branch: master Windowing system distributor 'The X.Org Foundation', version 11.0.12101013 System Description: OpenBSD computer 7.6 GENERIC.MP#294 amd64 Configured using: 'configure CC=egcc CPPFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib MAKEINFO=gmakeinfo --prefix=/home/manuel/emacs --bindir=/home/manuel/bin --with-x-toolkit=no --without-cairo --without-compress-install' >From ab26a89395b5745c8e3d87a8907344ba774a5ca1 Mon Sep 17 00:00:00 2001 From: Manuel Giraud Date: Tue, 3 Sep 2024 15:13:51 +0200 Subject: [PATCH] Make `dired-do-open' work on non GNU/Linux systems * lisp/dired-aux.el (dired-do-open): Permit this function to work on some non GNU/Linux systems. --- lisp/dired-aux.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lisp/dired-aux.el b/lisp/dired-aux.el index cd948bd7dd9..97b1e28a4ff 100644 --- a/lisp/dired-aux.el +++ b/lisp/dired-aux.el @@ -1472,7 +1472,7 @@ dired-do-open (when command (dolist (file files) (cond - ((memq system-type '(gnu/linux)) + ((memq system-type '(gnu/linux berkeley-unix)) (call-process command nil 0 nil file)) ((memq system-type '(ms-dos)) (shell-command (concat command " " (shell-quote-argument file -- 2.46.0 -- Manuel Giraud
bug#72765: Eglot + Clangd + Company + non-empty suffix = duplicate text
On Tue, Sep 3, 2024 at 2:20 PM Dmitry Gutov wrote: > > On 01/09/2024 17:28, Dmitry Gutov wrote: > >> * the rust-analyzer test you added recently -- and which you said was > >>very brittle -- is indeed very brittle: I cannot get it to pass. We > >>should fix it, or just delete it and do those rust-analyzer tests > >>manually each time we touch this area. > > > > Could you give more details? It is indeed more brittle in theory, but on > > my machine it's passing every time. > > Yeah, I see it now - it succeeds in an interactive session and fails in > batch mode. Not sure it was the same when the patch was committed > (hopefully not). > > Might be due to window configuration being different... Yes, I was trying batch mode. make -C test eglot-tests or something similar. Please fix it or delete it (or disable it).
bug#69097: [PATCH] Add 'kill-region-or-word' command
> On Tue, 03 Sep 2024 15:21:54 +0300, Eli Zaretskii said: >> From: Philip Kaludercic >> Cc: Eli Zaretskii , Stefan Kangas , >> Andrea Corallo , j...@linkov.net, r...@gnu.org, >> 69...@debbugs.gnu.org >> Date: Mon, 02 Sep 2024 21:12:01 + >> >> I had misremembered the last state of this patch. It is easier to just >> have a tristate option. Here is the updated proposal: Eli> Thanks. >> +(defcustom kill-word-if-no-region nil Eli> I would call this 'kill-region-dwim' instead. >> + "Behaviour when `kill-region' is invoked without an active region. >> +If set to nil (default), then an error occurs and nothing is killed. If >> +set to `emacs-word', then kill a the last word as defined by the current >> +major mode. If set to `unix-word', then kill the last word in the style >> +of a shell like Bash, disregarding the major mode." >> + :type '(choice (const :tag "Kill a word like `backward-kill-word'" emacs-word) >> + (const :tag "Kill a word like Bash would" unix-word) >> + (const :tag "Do not kill anything" nil)) >> + :group 'killing) Eli> :version tag is missing. Is it worth allowing a user-specified function? Robert --
bug#69097: [PATCH] Add 'kill-region-or-word' command
> From: Robert Pluim > Cc: Philip Kaludercic , r...@gnu.org, > 69...@debbugs.gnu.org, j...@linkov.net, stefankan...@gmail.com, > acora...@gnu.org, spwhit...@spwhitton.name > Date: Tue, 03 Sep 2024 15:53:39 +0200 > > > On Tue, 03 Sep 2024 15:21:54 +0300, Eli Zaretskii said: > > >> From: Philip Kaludercic > >> Cc: Eli Zaretskii , Stefan Kangas > , > >> Andrea Corallo , j...@linkov.net, r...@gnu.org, > >> 69...@debbugs.gnu.org > >> Date: Mon, 02 Sep 2024 21:12:01 + > >> > >> I had misremembered the last state of this patch. It is easier to just > >> have a tristate option. Here is the updated proposal: > > Eli> Thanks. > > >> +(defcustom kill-word-if-no-region nil > > Eli> I would call this 'kill-region-dwim' instead. > > >> + "Behaviour when `kill-region' is invoked without an active region. > >> +If set to nil (default), then an error occurs and nothing is killed. > If > >> +set to `emacs-word', then kill a the last word as defined by the > current > >> +major mode. If set to `unix-word', then kill the last word in the > style > >> +of a shell like Bash, disregarding the major mode." > >> + :type '(choice (const :tag "Kill a word like `backward-kill-word'" > emacs-word) > >> + (const :tag "Kill a word like Bash would" unix-word) > >> + (const :tag "Do not kill anything" nil)) > >> + :group 'killing) > > Eli> :version tag is missing. > > Is it worth allowing a user-specified function? I don't understand what you are asking, sorry. Allow a function where and to do what?
bug#73005: [REGRESSION, BISECTED]: line numbers disappear when pressing `df` in evil-mode
CCing the commit author. Sorry for using external plugin, but master has two separate unrelated critical regressions (the other one is going via link in *Help* buffer and getting Emacs locked up with 100% CPU and quickly increasing memory usage, which complicates reducing the steps), and since there's a clear commit that introduced the problem I decided to report it as is. # Steps to reproduce 1. Make sure you're in the Emacs repository and `./build/src/emacs` is the built binary 2. Execute `git clone --depth 1 https://github.com/emacs-evil/evil /tmp/evil` 3. Execute `PATH="$(pwd)/build/src/:$PATH" make -C /tmp/evil emacs` (Emacs with Evil loaded will start) 4. Press `n` to refuse running tests 5. Turn line numbers on by evaluating: (setq-default display-line- numbers 'visual) 6. Press `df` ## Expected Line numbers are still shown ## Actual Line numbers disappear # Additional information The commit that introduced the problem: commit dffdbc1f1fd6569c518e2e3b5e771a54e9e9483f (HEAD) Author: David Ponce Date: Thu Aug 22 16:56:11 2024 +0200 Use 'with-work-macro' in 'string-pixel-width' Tweak the implementation of 'string-pixel-width' to run faster and use less memory. Also cater for the case where this function is called in parallel (bug#72689). * lisp/emacs-lisp/subr-x.el (string-pixel-width): Use `with-work-macro'. Prefer `remove-text-properties' to `propertize' to avoid creating a new string on each call. lisp/emacs-lisp/subr-x.el | 22 +- 1 file changed, 13 insertions(+), 9 deletions(-) [03.09.2024-17:13:32] constantine@dell-g15 ~/Projects/builds/emacs- git/src/emacs-git ‹node-› ‹› (dffdbc1f1fd*)
bug#69097: [PATCH] Add 'kill-region-or-word' command
> On Tue, 03 Sep 2024 17:27:59 +0300, Eli Zaretskii said: >> >> + "Behaviour when `kill-region' is invoked without an active region. >> >> +If set to nil (default), then an error occurs and nothing is killed. If >> >> +set to `emacs-word', then kill a the last word as defined by the current >> >> +major mode. If set to `unix-word', then kill the last word in the style >> >> +of a shell like Bash, disregarding the major mode." >> >> + :type '(choice (const :tag "Kill a word like `backward-kill-word'" emacs-word) >> >> + (const :tag "Kill a word like Bash would" unix-word) >> >> + (const :tag "Do not kill anything" nil)) >> >> + :group 'killing) >> Eli> :version tag is missing. >> >> Is it worth allowing a user-specified function? Eli> I don't understand what you are asking, sorry. Allow a function where Eli> and to do what? The current proposal offers three fixed behaviours. Iʼm wondering if it makes sense for the user option to be allowed to be a user-defined function, in case someone wants a different behaviour, ie +(defcustom kill-word-if-no-region nil + "Behaviour when `kill-region' is invoked without an active region. +If set to nil (default), then an error occurs and nothing is killed. If +set to `emacs-word', then kill a the last word as defined by the current +major mode. If set to `unix-word', then kill the last word in the style +of a shell like Bash, disregarding the major mode. If set to a +function, call that function." + :type '(choice (const :tag "Kill a word like `backward-kill-word'" emacs-word) + (const :tag "Kill a word like Bash would" unix-word) + (const :tag "Do not kill anything" nil) + (symbol :tag "User function") + :group 'killing) Robert --
bug#73005: [REGRESSION, BISECTED]: line numbers disappear when pressing `df` in evil-mode
> Cc: da_...@orange.fr > From: Konstantin Kharlamov > Date: Tue, 03 Sep 2024 17:46:09 +0300 > > CCing the commit author. > > Sorry for using external plugin, but master has two separate unrelated > critical regressions (the other one is going via link in *Help* buffer > and getting Emacs locked up with 100% CPU and quickly increasing memory > usage, which complicates reducing the steps), and since there's a clear > commit that introduced the problem I decided to report it as is. > > # Steps to reproduce > > 1. Make sure you're in the Emacs repository and `./build/src/emacs` is > the built binary > 2. Execute `git clone --depth 1 https://github.com/emacs-evil/evil > /tmp/evil` > 3. Execute `PATH="$(pwd)/build/src/:$PATH" make -C /tmp/evil emacs` > (Emacs with Evil loaded will start) > 4. Press `n` to refuse running tests > 5. Turn line numbers on by evaluating: (setq-default display-line- > numbers 'visual) > 6. Press `df` What does "df" do? Does it somehow end up calling string-pixel-width? IOW, please show how string-pixel-width is related to the above. > ## Expected > > Line numbers are still shown > > ## Actual > > Line numbers disappear > > # Additional information > > The commit that introduced the problem: > >commit dffdbc1f1fd6569c518e2e3b5e771a54e9e9483f (HEAD) >Author: David Ponce >Date: Thu Aug 22 16:56:11 2024 +0200 > >Use 'with-work-macro' in 'string-pixel-width' Does it help to replace (setq display-line-numbers nil with (setq-local display-line-numbers nil in string-pixel-width?
bug#69097: [PATCH] Add 'kill-region-or-word' command
> From: Robert Pluim > Cc: phil...@posteo.net, r...@gnu.org, 69...@debbugs.gnu.org, > j...@linkov.net, stefankan...@gmail.com, acora...@gnu.org, > spwhit...@spwhitton.name > Date: Tue, 03 Sep 2024 16:55:29 +0200 > > +(defcustom kill-word-if-no-region nil > + "Behaviour when `kill-region' is invoked without an active region. > +If set to nil (default), then an error occurs and nothing is killed. If > +set to `emacs-word', then kill a the last word as defined by the current > +major mode. If set to `unix-word', then kill the last word in the style > +of a shell like Bash, disregarding the major mode. If set to a > +function, call that function." > + :type '(choice (const :tag "Kill a word like `backward-kill-word'" > emacs-word) > + (const :tag "Kill a word like Bash would" unix-word) > + (const :tag "Do not kill anything" nil) > + (symbol :tag "User function") > + :group 'killing) When and why would this be useful? Since kill-region cannot be customized in this way, I wonder why this new functionality should. If someone wants to replace kill-region with their own function, they can always redefine it or advise it, no?
bug#72986: Disabling menu-bar-mode changes size of new frames
>> Reproduction with Emacs 29.3 (also with git master HEAD, see below). >> >> Run: emacs -Q >> C-x 5 2 ; window opens the same size as the initial window >> M-x menu-bar-mode RET ; disable menu-bar-mode Here with a GTK-3 build on XFCE disabling menu-bar-mode makes both frames smaller by the menu bar height. Does this happen on your system? >> C-x 52 ; window opens much smaller than initial window >> >> With master HEAD (commit 92ea393a16e), the situation is slightly different: >> >> Run: emacs -Q >> C-x 52 ; window opens much smaller than initial window In all these cases after every single step please evaluate (frame-geometry) and post the results here. The window manager is mutter, I suppose? Thanks, martin
bug#72986: Disabling menu-bar-mode changes size of new frames
On Tue, 3 Sept 2024 at 16:52, martin rudalics wrote: > >> Reproduction with Emacs 29.3 (also with git master HEAD, see below). > >> > >> Run: emacs -Q > >> C-x 5 2 ; window opens the same size as the initial window > >> M-x menu-bar-mode RET ; disable menu-bar-mode > > Here with a GTK-3 build on XFCE disabling menu-bar-mode makes both > frames smaller by the menu bar height. Does this happen on your system? > Yes it does. >> C-x 52 ; window opens much smaller than initial window > >> > >> With master HEAD (commit 92ea393a16e), the situation is slightly > different: > >> > >> Run: emacs -Q > >> C-x 52 ; window opens much smaller than initial window > > In all these cases after every single step please evaluate > > (frame-geometry) > > and post the results here. Sure thing: Emacs 29: emacs -Q (frame-geometry): ((outer-position 1127 . 81) (outer-size 1384 . 1504) (external-border-size 28 . 34) (outer-border-width . 0) (title-bar-size 0 . 46) (menu-bar-external . t) (menu-bar-size 1328 . 50) (tab-bar-size 0 . 0) (tool-bar-external . t) (tool-bar-position . top) (tool-bar-size 1328 . 82) (internal-border-width . 0)) C-x 5 2 menu-bar-mode RET (frame-geometry): ((outer-position 1127 . 81) (outer-size 1384 . 1454) (external-border-size 28 . 34) (outer-border-width . 0) (title-bar-size 0 . 46) (menu-bar-external . t) (menu-bar-size 0 . 0) (tab-bar-size 0 . 0) (tool-bar-external . t) (tool-bar-position . top) (tool-bar-size 1328 . 82) (internal-border-width . 0)) C-x 5 2 (frame-geometry): ((outer-position 28 . 90) (outer-size 456 . 570) (external-border-size 28 . 34) (outer-border-width . 0) (title-bar-size 0 . 46) (menu-bar-external . t) (menu-bar-size 0 . 0) (tab-bar-size 0 . 0) (tool-bar-external . t) (tool-bar-position . top) (tool-bar-size 400 . 82) (internal-border-width . 0)) Emacs git master (commit 92ea393a16e): emacs -Q (frame-geometry): ((outer-position 28 . 90) (outer-size 1384 . 1504) (external-border-size 28 . 34) (outer-border-width . 0) (title-bar-size 0 . 46) (menu-bar-external . t) (menu-bar-size 1328 . 50) (tab-bar-size 0 . 0) (tool-bar-external . t) (tool-bar-position . top) (tool-bar-size 1328 . 82) (internal-border-width . 0)) C-x 5 2 (frame-geometry): ((outer-position 108 . 170) (outer-size 456 . 620) (external-border-size 28 . 34) (outer-border-width . 0) (title-bar-size 0 . 46) (menu-bar-external . t) (menu-bar-size 400 . 50) (tab-bar-size 0 . 0) (tool-bar-external . t) (tool-bar-position . top) (tool-bar-size 400 . 82) (internal-border-width . 0)) The window manager is mutter, I suppose? > Indeed, yes. -- https://rrt.sc3d.org
bug#72960: 31.0.50; PGTK Wayland exhibits more lag than X11 version
> Date: Tue, 03 Sep 2024 16:36:44 +0100 > From: "Stephane Travostino" > Cc: 72...@debbugs.gnu.org > > > Please try profiling the lagging cases with "M-x profiler", and post > > the profile here. > > I don't know how to make a consistent test case. I have tried here to profile > opening Emacs (same commit with and without PGTK) on the same 547-line Elixir > file, and holding the Down key until it reaches the bottom and then back to > the top of the buffer. I have (setopt scroll-conservatively 101) so after the > first page the contents are continuously redrawn for every new line. > > The PGTK version feels like it's skipping frames while it's relatively smooth > on X11: > > X11: > 8795 86% + redisplay_internal (C function) > 1141 11% + command-execute > 54 0% + direnv--maybe-update-environment > 49 0% + gcmh-register-idle-gc > 42 0% + winner-save-old-configurations > 20 0% + timer-event-handler > 18 0% + ... > 18 0% + jit-lock--antiblink-post-command > > > PGTK: > 9387 91% + redisplay_internal (C function) > 698 6% + command-execute > 19 0% + ... > 19 0% + timer-event-handler > 12 0% + direnv--maybe-update-environment > 11 0% + winner-save-old-configurations > > I have run this a few times and in Wayland `redisplay_internal` takes always > a few percent more time than on X11, though I am not sure these numbers can > prove anything as they are quite close. Thanks. Maybe Po Lu will have some ideas. > Is there some kind of consistent UI benchmark I can run? The frame skipping > reminds me of missed vsync deadlines one might experience in games. Try this: (defun scroll-up-benchmark () (interactive) (let ((oldgc gcs-done) (oldtime (float-time))) (condition-case nil (while t (scroll-up) (redisplay)) (error (message "GCs: %d Elapsed time: %f seconds" (- gcs-done oldgc) (- (float-time) oldtime)) Evaluate this function, then visit a large file, like src/xdisp.c from the Emacs sources, and invoke "M-x scroll-up-benchmark RET". It will show the time it took at the end. Record the results and compare with the other configuration.
bug#73005: [REGRESSION, BISECTED]: line numbers disappear when pressing `df` in evil-mode
On Tue, 2024-09-03 at 18:30 +0300, Eli Zaretskii wrote: > > Cc: da_...@orange.fr > > From: Konstantin Kharlamov > > Date: Tue, 03 Sep 2024 17:46:09 +0300 > > > > CCing the commit author. > > > > Sorry for using external plugin, but master has two separate > > unrelated > > critical regressions (the other one is going via link in *Help* > > buffer > > and getting Emacs locked up with 100% CPU and quickly increasing > > memory > > usage, which complicates reducing the steps), and since there's a > > clear > > commit that introduced the problem I decided to report it as is. > > > > # Steps to reproduce > > > > 1. Make sure you're in the Emacs repository and `./build/src/emacs` > > is > > the built binary > > 2. Execute `git clone --depth 1 https://github.com/emacs-evil/evil > > /tmp/evil` > > 3. Execute `PATH="$(pwd)/build/src/:$PATH" make -C /tmp/evil emacs` > > (Emacs with Evil loaded will start) > > 4. Press `n` to refuse running tests > > 5. Turn line numbers on by evaluating: (setq-default display-line- > > numbers 'visual) > > 6. Press `df` > > What does "df" do? "df" is triggering the action "delete text up to" and it will wait for the third key, the symbol to "delete text up to". But for the problem to appear pressing the third key is not required. As a matter of fact, sometimes it gets reproduced by just pressing "f" which stands for "go to next symbol" (and it would similarly wait a keypress to define a symbol to go to), but for some reason it happens much less compared to pressing "df". > Does it somehow end up calling string-pixel-width? It seems it doesn't. I used a `M-x debug-on-entry string-pixel-width` and then pressed "df" which made line numbers disappear, but debugger wasn't triggered. > IOW, please show how string-pixel-width is related to the above. Offhand I don't know. I would reduce steps, but I can't use *Help* for reasons mentioned in my 1st email, and I still didn't find a commit which does not hang upon following *Help* buffer, because 1000 commits before dffdbc1f1fd6 Emacs fails to compile with some native-compilation errors and `make clean` doesn't help. I presume finding the culprit for this problem will take some time. I don't know if it's of any help, but upon pressing "df" the caret turns from a rectangle to a square (half the rectangle size). This is indicating that Emacs is waiting for the next keypress, perhaps this indication somehow triggers the problem…
bug#73005: [REGRESSION, BISECTED]: line numbers disappear when pressing `df` in evil-mode
On Tue, 2024-09-03 at 18:30 +0300, Eli Zaretskii wrote: > > The commit that introduced the problem: > > > > commit dffdbc1f1fd6569c518e2e3b5e771a54e9e9483f (HEAD) > > Author: David Ponce > > Date: Thu Aug 22 16:56:11 2024 +0200 > > > > Use 'with-work-macro' in 'string-pixel-width' > > Does it help to replace > > (setq display-line-numbers nil > > with > > (setq-local display-line-numbers nil > > in string-pixel-width? Sorry, I forgot to reply here. No, it doesn't change anything.
bug#69097: [PATCH] Add 'kill-region-or-word' command
Eli Zaretskii writes: >> From: Philip Kaludercic >> Cc: Eli Zaretskii , Stefan Kangas , >> Andrea Corallo , j...@linkov.net, r...@gnu.org, >> 69...@debbugs.gnu.org >> Date: Mon, 02 Sep 2024 21:12:01 + >> >> I had misremembered the last state of this patch. It is easier to just >> have a tristate option. Here is the updated proposal: > > Thanks. > >> +(defcustom kill-word-if-no-region nil > > I would call this 'kill-region-dwim' instead. Can do. >> + "Behaviour when `kill-region' is invoked without an active region. >> +If set to nil (default), then an error occurs and nothing is killed. If >> +set to `emacs-word', then kill a the last word as defined by the current >> +major mode. If set to `unix-word', then kill the last word in the style >> +of a shell like Bash, disregarding the major mode." >> + :type '(choice (const :tag "Kill a word like `backward-kill-word'" >> emacs-word) >> + (const :tag "Kill a word like Bash would" unix-word) >> + (const :tag "Do not kill anything" nil)) >> + :group 'killing) > > :version tag is missing. Whoops, added it. >> -Lisp programs should use this function for killing text. >> - (To delete text, use `delete-region'.) >> -Supply two arguments, character positions BEG and END indicating the >> - stretch of text to be killed. If the optional argument REGION is >> - non-nil, the function ignores BEG and END, and kills the current >> - region instead. Interactively, REGION is always non-nil, and so >> - this command always kills the current region." >> +Lisp programs should use this function for killing text. (To delete >> +text, use `delete-region'.) Supply two arguments, character positions >> +BEG and END indicating the stretch of text to be killed. If the >> +optional argument REGION is non-nil, the function ignores BEG and END, >> +and kills the current region instead. If REGION has the special value > > Not sure why you decided to reformat this part. Its formatting was > not random. I think this was just an accidental M-q. > This also needs a NEWS entry. I've added the NEWS entry from the last iteration of the patch (now actually as a patch, not just a diff): >From 981331cfe0757b21f529be02d848a3ef7bcc4295 Mon Sep 17 00:00:00 2001 From: Philip Kaludercic Date: Tue, 3 Sep 2024 18:29:56 +0200 Subject: [PATCH] Allow 'kill-region' kill the last word when there is no region * etc/NEWS: Document the new user option. * lisp/simple.el (kill-region-dwim): Add new option. (kill-region): Respect 'kill-region-dwim'. (Bug#69097) --- etc/NEWS | 6 ++ lisp/simple.el | 50 ++ 2 files changed, 48 insertions(+), 8 deletions(-) diff --git a/etc/NEWS b/etc/NEWS index 1e66f084117..7fadf52a6cf 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -123,6 +123,12 @@ When using 'visual-wrap-prefix-mode' in buffers with variable-pitch fonts, the wrapped text will now be lined up correctly so that it's exactly below the text after the prefix on the first line. +--- +** New user option 'kill-word-if-no-region'. +This option will modify the fall-back behaviour of 'kill-region' if no +region is active, and will kill the last word instead of raising an +error. + * Changes in Specialized Modes and Packages in Emacs 31.1 diff --git a/lisp/simple.el b/lisp/simple.el index eedc5768fe2..3b4453c7a8f 100644 --- a/lisp/simple.el +++ b/lisp/simple.el @@ -5817,6 +5817,17 @@ kill-read-only-ok :type 'boolean :group 'killing) +(defcustom kill-region-dwim nil + "Behaviour when `kill-region' is invoked without an active region. +If set to nil (default), then an error occurs and nothing is killed. If +set to `emacs-word', then kill a the last word as defined by the current +major mode. If set to `unix-word', then kill the last word in the style +of a shell like Bash, disregarding the major mode." + :type '(choice (const :tag "Kill a word like `backward-kill-word'" emacs-word) + (const :tag "Kill a word like Bash would" unix-word) + (const :tag "Do not kill anything" nil)) + :group 'killing) + (defun kill-region (beg end &optional region) "Kill (\"cut\") text between point and mark. This deletes the text from the buffer and saves it in the kill ring. @@ -5843,21 +5854,44 @@ kill-region (To delete text, use `delete-region'.) Supply two arguments, character positions BEG and END indicating the stretch of text to be killed. If the optional argument REGION is - non-nil, the function ignores BEG and END, and kills the current + `region', the function ignores BEG and END, and kills the current region instead. Interactively, REGION is always non-nil, and so - this command always kills the current region." + this command always kills the current region. It is possible to + override this behaviour by customising the user option + `kill-region-dwim'." ;; Pass mark first, then point, because the order matters when ;; calling `kill-appe
bug#43086: [PATCH] Allow tags backend to not query for TAGS file
Dmitry Gutov writes: > Hi! > > On 28.08.2020 15:50, Philip K. wrote: > >> the xref backend for etags can be annoying at times, especially in >> combination with other backends. This patch should improve the >> situation, by allowing the user to configure how and when the etags >> backend is activated. The new user option etags-query-file would allow >> the backend to never query a TAGS file, or conditionally, depending on >> the existence of a TAGS file (in which case it can also be automatically >> loaded). > > This is a interesting patch, but it calls for some discussion: > > - The possible values all look pretty clever, but there are a lot of > them! Do we expect them all to be in demand? Ideally, I'd only leave > 2-3 of them, to reduce the number of workflows we need to care > about. The rest could probably be set up in individual user > configurations in find-file-hook (like Projectile does). > > - The variable name implies it affects how etags.el works globally, > but the actual effect seems limited to the xref backend function. We > should either rename it to something like etags-xref-query-file, or > consider having it affect tags-completion-at-point-function as > well. Maybe find-tag too. But given that > tags-completion-at-point-function has for a long time behaved in the > "never query" fashion, perhaps the easiest and most > backward-compatible option is the former. > > - One current persistent annoyance is that currently > xref-find-references doesn't work well in many files where the xref > backend is the default one (etags) when ido-mode or icomplete-mode > are enabled because it prompts for the tags file to do identifier > completion. I wonder if the "no query" option will help with this, > too. > >> I could imagine this might be extended to allow an auto-generate option, >> but that feature seems out of scope of this patch, and probably would >> require some interoperation with project.el. > > Indeed. Actually, I have an old, WIP patch for tag file > auto-generation which, yes, uses project.el. I can post it again if > you're curious. Hasn't this issue been resolved by `etags-regen-mode'? -- Philip Kaludercic on peregrine
bug#69097: [PATCH] Add 'kill-region-or-word' command
> On Tue, 03 Sep 2024 16:32:46 +, Philip Kaludercic > said: >> >> Is it worth allowing a user-specified function? Philip> That would be possible as well, but to make it manageable with the Philip> current approach the function would have to be one that moves the point. Philip> So we could rewrite the patch with two default options `backward-word' Philip> and `unix-backward-word' (which we would have to add), but I am not sure Philip> it would have much use. Perhaps killing the current word, instead of Philip> just killing to the beginning? You mean having all the option values be functions? That would work as well, but was not what I was suggesting. In any case, I canʼt find a strong justification for such configurability. We can always add it in later if people ask for it. Robert --
bug#72986: Disabling menu-bar-mode changes size of new frames
> Sure thing: Thanks. The geometry values are consistent with what you described. This seems to be Bug#67654 and Bug#68463 and possibly Bug#65559. When you run Emacs from a console or under gdb can you observe whether it triggers a gtk_distribute_natural_allocation: assertion 'extra_space >= 0' failed which typically means that the menubar cannot be accommodated. The one really notable difference to the above bugs is that the 29 version makes a shrunk frame only after you've removed the menubar while master makes a shrunk frame immediately. Are the GTK versions of the Emacs 29 build and the master build the same? > The window manager is mutter, I suppose? >> > > Indeed, yes. mutter doesn't like us. Just to make sure one thing: Would setting 'frame-resize-pixelwise' to t change anything? Otherwise I would try to build Emacs with gtk2, lucid or motif. martin
bug#72986: Disabling menu-bar-mode changes size of new frames
On Tue, 3 Sept 2024 at 18:03, martin rudalics wrote: > > Sure thing: > > Thanks. The geometry values are consistent with what you described. > This seems to be Bug#67654 and Bug#68463 and possibly Bug#65559. When > you run Emacs from a console or under gdb can you observe whether it > triggers a > > gtk_distribute_natural_allocation: assertion 'extra_space >= 0' failed > Yes, both with Emacs 29 and git master produce this message when menu-bar-mode is non-nil, and the menu bar is drawn, in both window sizes (the normal sized window, and the strangely small one). The one really notable difference to the above bugs is that the 29 > version makes a shrunk frame only after you've removed the menubar while > master makes a shrunk frame immediately. Are the GTK versions of the > Emacs 29 build and the master build the same? > Yes, they are identical: gtk 3.24.41, Ubuntu build. Just to make sure one thing: Would setting > 'frame-resize-pixelwise' to t change anything? > So, I did (setq frame-resize-pixelwise t), then disabled menu-bar-mode (in Emacs 29), then C-x 5 2 (in both Emacs 29 & git master), and the new window was small, just as before. It seems therefore to make no difference. Otherwise I would try to build Emacs with gtk2, lucid or motif. I tried building Emacs git master with gtk2, and it doesn't fix the problem: the second window opened is slightly smaller than before (i.e. very small indeed). Building with lucid does fix the problem (both with menu-bar-mode enabled, and disabled). -- https://rrt.sc3d.org
bug#72986: Disabling menu-bar-mode changes size of new frames
On Tue, 3 Sept 2024 at 18:29, Reuben Thomas wrote: > > Otherwise I would try to build Emacs with gtk2, lucid or motif. > > > I can confirm that building with no toolkit (as recommended in the issues you mentioned) also fixes the problem. -- https://rrt.sc3d.org
bug#72986: Disabling menu-bar-mode changes size of new frames
> Date: Tue, 3 Sep 2024 19:03:05 +0200 > Cc: Eli Zaretskii , Po Lu , > 72...@debbugs.gnu.org > From: martin rudalics > > mutter doesn't like us. Just to make sure one thing: Would setting > 'frame-resize-pixelwise' to t change anything? > > Otherwise I would try to build Emacs with gtk2, lucid or motif. Isn't it true that disabling menu-bar-mode from the init file avoids these problems? Reuben, is running with menu-bar-mode disabled at all a goal of yours, or you reported this issue simply because it looks like incorrect behavior, and you don't really care about running without the menu bar?
bug#67604: Motion problems with inline images
> On Dec 11, 2023, at 2:44 PM, Eli Zaretskii wrote: > > I've eventually succeeded in reproducing it. I will get to it when I > have time; however, with the current tempest on emacs-devel and other > urgent issues, I don't know when will that be. Following up on this vertical-motion with inline images bug. My earlier recipe still seems to find special image sizes where (vertical-motion 1) skips the 3rd line. As a reminder this is occurring only for certain window widths, near and below those where the green bar has just wrapped to line 2.
bug#72358: 29.4; oauth2.el improvements
In case anyone is interested, I have filed bug#72992[1] where I posted my code to enable xoauth2 support for nnimap and smtpmail as I promised. I am also trying to gather feedback on how it can be improved. Comments welcome! [1] https://lists.gnu.org/archive/html/bug-gnu-emacs/2024-09/msg00089.html -- Xiyue Deng
bug#72986: Disabling menu-bar-mode changes size of new frames
On Tue, 3 Sept 2024 at 18:44, Eli Zaretskii wrote: > Isn't it true that disabling menu-bar-mode from the init file avoids > these problems? > I don't think so: I had it customized off and had to bisect my customizations in order to find what was causing the problem. Reuben, is running with menu-bar-mode disabled at all a goal of yours, > Yes! -- https://rrt.sc3d.org
bug#72960: 31.0.50; PGTK Wayland exhibits more lag than X11 version
On Tue, 3 Sep 2024, at 13:52, Eli Zaretskii wrote: >> Date: Tue, 03 Sep 2024 12:27:09 +0100 >> From: "Stephane Travostino" >> Cc: 72...@debbugs.gnu.org >> >> On Mon, 2 Sep 2024, at 13:12, Stephane Travostino wrote: >> > On Mon, 2 Sep 2024, at 13:05, Eli Zaretskii wrote: >> >>> Date: Mon, 02 Sep 2024 10:18:03 +0100 >> >>> From: "Stephane Travostino" >> >>> >> >>> Heavy operations, such as scrolling back and forth in a buffer, are >> >>> noticeably laggier, for lack of better word, in the PGTK/Wayland version >> >>> than the X11, both tested on KDE in Wayland mode. >> >>> >> >>> Affects both 29.2 and the latest HEAD compiled a few days ago. >> >>> >> >>> I am unsure whether it is a KDE or Emacs problem. >> >>> >> >>> Running on an AMD RX 6800 XT graphics card on a HiDPI 4k screen at 2x >> >>> scaling. >> >> >> >> AFAIU, this is a problem with GTK input methods. From PROBLEMS: >> >> >> >> *** Emacs built with GTK lags in its response to keyboard input. >> >> This can happen when input methods are used. It happens because Emacs >> >> behaves in an unconventional way with respect to GTK input methods: it >> >> registers to receive keyboard input as unprocessed key events with >> >> metadata (as opposed to receiving them as text strings). Most GTK >> >> programs use the latter approach, so some modern input methods have >> >> bugs and misbehave when faced with the way Emacs does it. >> >> >> >> A workaround is to set GTK_IM_MODULE=none in the environment, or maybe >> >> find a different input method without these problems. >> > >> > Thank you, though without more scientific methods of measuring latency >> > I can't tell if that helps or not. >> > >> > I noticed I had pixel precision scrolling mode on and that contributed >> > a large part to that feeling of lag compared to other programs. If >> > Firefox is able to smooth scroll at 60 Hz, I would say empirically >> > Emacs PGTK would scroll at 15 Hz, making navigation in the buffer a >> > choppy affair. >> >> Update: GTK_IM_MODULE=none does not make it any less laggier. It is mostly >> felt in typing and editing source code, and switching to the X11 build makes >> it immensely snappier and doesn't feel like I'm working through a remote >> connection. > > Please try profiling the lagging cases with "M-x profiler", and post > the profile here. I don't know how to make a consistent test case. I have tried here to profile opening Emacs (same commit with and without PGTK) on the same 547-line Elixir file, and holding the Down key until it reaches the bottom and then back to the top of the buffer. I have (setopt scroll-conservatively 101) so after the first page the contents are continuously redrawn for every new line. The PGTK version feels like it's skipping frames while it's relatively smooth on X11: X11: 8795 86% + redisplay_internal (C function) 1141 11% + command-execute 54 0% + direnv--maybe-update-environment 49 0% + gcmh-register-idle-gc 42 0% + winner-save-old-configurations 20 0% + timer-event-handler 18 0% + ... 18 0% + jit-lock--antiblink-post-command PGTK: 9387 91% + redisplay_internal (C function) 698 6% + command-execute 19 0% + ... 19 0% + timer-event-handler 12 0% + direnv--maybe-update-environment 11 0% + winner-save-old-configurations I have run this a few times and in Wayland `redisplay_internal` takes always a few percent more time than on X11, though I am not sure these numbers can prove anything as they are quite close. Is there some kind of consistent UI benchmark I can run? The frame skipping reminds me of missed vsync deadlines one might experience in games.
bug#73016: Potential inclusion of kbd-mode, part of kmonad, in Non-GNU ELPA
Hi, kmonad is a keyboard configuration tool under MIT license. https://github.com/kmonad/kmonad There is an Emacs major mode to edit the configuration file, based on s-expressions. The mode is under GPLv3. https://github.com/kmonad/kbd-mode On behalf of the author, Tony Zorman, I would like to request consideration to include it in NON-GNU ELPA. The author is conscious that the following snippet should be improved and we are soliciting recommendations on how to improve it. ;; HACK (defadvice redisplay (after refresh-font-locking activate) (when (derived-mode-p 'kbd-mode) (font-lock-fontify-buffer Furthermore if there are any code reviews or recommendations, I attach the current version. I can volunteer some time for some of the changes. kbd-mode.el Description: application/emacs-lisp
bug#72993: 31.0.50; 4f521fa14c18f57e5207bffd68e9f79454dccc79 breaks binding mode hooks in use-package
> Eli Zaretskii writes: >> Perhaps we should avoid auto -hook’ifying the variable name only if the name >> does not already end in ‘-functions’? > Either that, or maybe exempt FOO-mode from the boundp test. This sounds likely to be even better. -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2
bug#72960: 31.0.50; PGTK Wayland exhibits more lag than X11 version
Eli Zaretskii writes: > Po Lu, any other ideas or suggestions? > >> FYI there are other reports online of people noticing major latency in HiDPI >> mode with the PGTK version, especially when the frame is fullscreen (so >> there's more pixels to update): >> >> https://old.reddit.com/r/emacs/comments/ucv0at/awful_performance_with_pgtk_on_wayland/ >> >> https://old.reddit.com/r/emacs/comments/1acdieh/pgtk_emacs_high_input_lag_at_large_frame_sizes_on/ > > I don't doubt what you report is real. I proposed a theory in a number of other tickets concerning this lag, specifically that the GTK 3 toolkit cannot take advantage of hardware accelerated graphics on Wayland, which produces perceptible delays on large displays.
bug#72960: 31.0.50; PGTK Wayland exhibits more lag than X11 version
Eli Zaretskii writes: > Thanks. Maybe Po Lu will have some ideas. I mentioned one. I think a C profiler (e.g. gprof) would provide more insightful data.
bug#73018: 31.0.50; wdired + replace-regexp only modifies the visible portion of the buffer
In GNU Emacs 31.0.50 (build 2, x86_64-pc-linux-gnu, X toolkit, cairo version 1.18.0, Xaw3d scroll bars) Repository revision: f1e29506822739208e5706b733cfd713c5f37cfd Ref: https://lists.gnu.org/archive/html/emacs-devel/2024-09/msg00071.html On carrying out the following steps ``` mkdir /dev/shm/test-foo -pv for i in $(seq 1 40); do ln -sv /foo/$i /dev/shm/test-foo; done (dired "/dev/shm/test-foo") (wdired-change-to-wdired-mode) (replace-regexp "foo" "bar") ``` It is seen that only the files in the visible portion of the buffer are affeceted by the replace-regexp. The attached patch implements the suggestion in https://lists.gnu.org/archive/html/emacs-devel/2024-09/msg00079.html and appears to fix the problem. (However there still seems to be a boostrap related problem with "Match data clobbered by buffer modification hooks" when wdired is first loaded) >From 05c8405a30a36098c55e4f31a1ec339719ccbcb3 Mon Sep 17 00:00:00 2001 From: Madhu Date: Wed, 4 Sep 2024 06:55:44 +0530 Subject: [PATCH] * lisp/wdired.el: (wdired-change-to-wdired-mode): call font-lock-ensure so replace-regexp with wdired-search-replace-filenames t works on the whole buffer. --- lisp/wdired.el | 1 + 1 file changed, 1 insertion(+) diff --git a/lisp/wdired.el b/lisp/wdired.el index 4b6a9c14b20..dd8b8640a89 100644 --- a/lisp/wdired.el +++ b/lisp/wdired.el @@ -264,6 +264,7 @@ wdired-change-to-wdired-mode ;; hidden partly, so we remove filename invisibility spec ;; temporarily to ensure filenames are visible for editing. (dired-filename-update-invisibility-spec) + (font-lock-ensure) (run-mode-hooks 'wdired-mode-hook) (message "%s" (substitute-command-keys "Press \\[wdired-finish-edit] when finished \ -- 2.46.0.27.gfa3b914457
bug#73018: 31.0.50; wdired + replace-regexp only modifies the visible portion of the buffer
Madhu writes: > (dired "/dev/shm/test-foo") > (wdired-change-to-wdired-mode) > (replace-regexp "foo" "bar") > ``` > > It is seen that only the files in the visible portion of the buffer > are affeceted by the replace-regexp. The attached patch implements the > suggestion in > https://lists.gnu.org/archive/html/emacs-devel/2024-09/msg00079.html > and appears to fix the problem. Thanks for reporting this here. I CC Juri Linkov. > (However there still seems to be a boostrap related problem with > "Match data clobbered by buffer modification hooks" when wdired is > first loaded) Could you please post a recipe and a backtrace for this second problem? > --- > lisp/wdired.el | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/lisp/wdired.el b/lisp/wdired.el > index 4b6a9c14b20..dd8b8640a89 100644 > --- a/lisp/wdired.el > +++ b/lisp/wdired.el > @@ -264,6 +264,7 @@ wdired-change-to-wdired-mode >;; hidden partly, so we remove filename invisibility spec >;; temporarily to ensure filenames are visible for editing. >(dired-filename-update-invisibility-spec) > + (font-lock-ensure) >(run-mode-hooks 'wdired-mode-hook) >(message "%s" (substitute-command-keys >"Press \\[wdired-finish-edit] when finished \ Yip. When we do this (guess we don't have a choice), my preferred solution would be to hook this into the corresponding isearch function. Because calling `font-lock-ensure' can be really slow in large dired buffers (several seconds). Or we manage to rewrite things so that the work is done on the fly in some way. Michael.
bug#73022: 31.0.50; Crash in build_frame_matrix_from_leaf_window after C-x 2 and reducing terminal size
Continuing from this comment at https://debbugs.gnu.org/cgi/bugreport.cgi?bug=71289: > That's another problem. There seems to be some disconnect, time-wise, > in reallocating frame matrices and sub-allocating window matrices from > the frame matrices, and the crash happens when the check is done > in-between those two. In particular, I found a case in which an assert fails because the window row glyph memory is not contained in the frame row glyph memory. It happens in a recent build (99a03ddb2d4) built without X support. I'm running it in a urxvt terminal but it happens in xterm too. It crashes both with and without glyph debug. This is not related to garbage collection like bug 71289. To reproduce: 1. Open emacs -Q 2. Press C-x 2 to split the frame (top/bottom) 3. Make the terminal very small (I slowly resize the X window that's running urxvt, to the minimum size, 1 row and 2 columns in my case). This shrinking process alone can produce the crash when the window is around 5 lines high 4. It always crashes in my case. If it doesn't, make the terminal larger again, and repeat the resizing for some seconds until it crashes Note that the C-x 2 is required. The problem doesn't happen with a left/right split (C-x 3). But it happens after a C-x 3 C-x 2. Manually resizing is enough to trigger the problem. But it's also possible to automate the resizing with something like this (change the first part to find the window ID): EC=$(xdotool search --name '^\gdb src/emacs') && echo $EC && while :; do for height_px in `seq 275 -25 10`; do xdotool windowsize $EC $((height_px+5)) $height_px; sleep 0.001; done; for height_px in `seq 1 25 400`; do xdotool windowsize $EC $((height_px+5)) $height_px; sleep 0.1; done; sleep 0.3 && done (gdb) bt #0 __pthread_kill_implementation (threadid=, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44 #1 0x7554ae8f in __pthread_kill_internal (signo=6, threadid=) at ./nptl/pthread_kill.c:78 #2 0x754fbfb2 in __GI_raise (sig=6) at ../sysdeps/posix/raise.c:26 #3 0x5568d0c2 in terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:469 #4 0x5573de15 in die ( msg=0x55856798 "frame_size_change_delayed (XFRAME (w->frame)) || glyph_row_slice_p (window_row, frame_row)", file=0x55856231 "dispnew.c", line=2647) at alloc.c:8058 #5 0x5558b697 in build_frame_matrix_from_leaf_window (frame_matrix=0x560fed00, w=0x5603cca8) at dispnew.c:2647 #6 0x5558b154 in build_frame_matrix_from_window_tree (matrix=0x560fed00, w=0x5603cca8) at dispnew.c:2536 #7 0x5558b13f in build_frame_matrix_from_window_tree (matrix=0x560fed00, w=0x56260390) at dispnew.c:2534 #8 0x5558b0e3 in build_frame_matrix (f=0x5603ca88) at dispnew.c:2520 #9 0x5558d0e3 in update_frame (f=0x5603ca88, force_p=true, inhibit_hairy_id_p=false) at dispnew.c:3336 #10 0x555d0904 in redisplay_internal () at xdisp.c:17518 #11 0x555d1244 in redisplay_preserve_echo_area (from_where=11) at xdisp.c:17801 #12 0x557f5893 in wait_reading_process_output (time_limit=97, nsecs=0, read_kbd=-1, do_display=true, wait_for_cell=0x0, wait_proc=0x0, just_wait_proc=0) at process.c:5584 #13 0x555951d3 in sit_for (timeout=0x186, reading=true, display_option=1) at dispnew.c:6335 This is the failing assertion in frame 5, dispnew.c: (gdb) list 2642} 2643 2644#ifdef GLYPH_DEBUG 2645 /* Window row window_y must be a slice of frame row 2646 frame_y. */ 2647 eassert (frame_size_change_delayed (XFRAME (w->frame)) 2648 || glyph_row_slice_p (window_row, frame_row)); 2649 2650 /* If rows are in sync, we don't have to copy glyphs because 2651 frame and window share glyphs. */ Both conditions: frame_size_change_delayed (XFRAME (w->frame) glyph_row_slice_p (window_row, frame_row) are false. I don't know which one should be true in this case. This is the part about being delayed. (gdb) p delayed_size_change $15 = false glyph_row_slice_p contains this code: struct glyph *window_glyph_start = window_row->glyphs[0]; struct glyph *frame_glyph_start = frame_row->glyphs[0]; struct glyph *frame_glyph_end = frame_row->glyphs[LAST_AREA]; return (frame_glyph_start <= window_glyph_start && window_glyph_start < frame_glyph_end); The first part of the condition is false: (gdb) p frame_row->glyphs[0] $24 = (struct glyph *) 0x70f414c0 (gdb) p window_row->glyphs[0] $25 = (struct glyph *) 0x7088b430 (gdb) p frame_row->glyphs[0] <= window_row->glyphs[0] $26 = 0 (gdb) The second part is true: (gdb) p window_row->glyphs[0] $29 = (struct glyph *) 0x7088b430 (gdb) p frame_row->glyphs[LAST_AREA] $30 = (struct glyph *) 0x70f41970 (gdb) p window_row->glyphs[0] < frame_row->glyphs[LAST_AREA] $31 = 1 (gdb) Since the second part is true, I'm guessing that the first part shoul
bug#71289: 30.0.50; cmcheckmagic aborts when tty_write_glyphs writes "Garbage collecting..." in some cases
> > The build_frame_matrix_from_leaf_window crash still happens. > > That's another problem. There seems to be some disconnect, time-wise, > in reallocating frame matrices and sub-allocating window matrices from > the frame matrices, and the crash happens when the check is done > in-between those two. > > This will need more work. Patches and relevant data are welcome. I reported the build_frame_matrix_from_leaf_window problem separately to provide simpler instructions. (Can you mention the new bug number once it's approved?). The original problem mentioned here is about GC messages and it was fixed, so I think it can be closed. The build_frame_matrix_from_leaf_window error is easier to reproduce in comparison.
bug#71289: 30.0.50; cmcheckmagic aborts when tty_write_glyphs writes "Garbage collecting..." in some cases
> I reported the build_frame_matrix_from_leaf_window problem separately to > provide simpler instructions It's at https://debbugs.gnu.org/cgi/bugreport.cgi?bug=73022
bug#73022: Acknowledgement (31.0.50; Crash in build_frame_matrix_from_leaf_window after C-x 2 and reducing terminal size)
> Configured using: > […] > --without-x 'CFLAGS=-g3 -O3'' I sent another build's information by mistake. The backtraces are actually from a -O0 build, with this information: In GNU Emacs 31.0.50 (build 3, x86_64-pc-linux-gnu) of 2024-09-01 built on sonn Repository revision: 99a03ddb2d43d67577814b96e40ec069739b6421 Repository branch: master System Description: Devuan GNU/Linux 5 (daedalus) Configured using: 'configure --prefix=/opt/dc/emacs-dev/ --with-tiff=no --without-tiff --without-libsystemd --without-dbus --with-mailutils --without-modules --with-native-compilation --with-x-toolkit=no --without-imagemagick --without-xft --without-harfbuzz --without-freetype --without-libotf --without-xwidgets --without-xpm --without-jpeg --without-gif --without-png --without-webp --without-rsvg --without-cairo --without-x --without-sound --enable-checking=yes,glyphs --enable-profiling 'CFLAGS=-g3 -O0 ''
bug#72863: 30.0.50; tree-sitter elixir-ts-mode hangs and memory leak on some elixir and heex code
On Thu, Aug 29, 2024 at 8:14 AM Yuan Fu wrote:
>
>
> > On Aug 28, 2024, at 10:09 PM, Eli Zaretskii wrote:
> >
> >> From: m...@ssbb.me
> >> Date: Thu, 29 Aug 2024 06:57:38 +0400
> >>
> >> Code in attached file cause Emacs to hang and memory leak infinitely
> >> while editing. Try to open this code in elixir-ts-mode and move cursor
> >> on line 6 (between <:loading> ) and type char by char:
> >>
> >> <.some_component a={
> >>
> >> (for some reason it does not happen with electric-pair-mode when {}
> >> inserted automatically).
> >>
> >> I am able to reproduce this with -Q on few different machines (Linux and
> >> MacOS) and Emacs 29, 30.0.5 and current HEAD.
> >>
> >> C-g does nothing (including with debug-on-quit and sending SIGUSR2)
> >>
> >> At the same time I can't reproduce this in other tree-sitter based
> editors.
> >>
> >> I got this sample code sample from elixir-ts-mode repo but now it's
> moved
> >> to the Emacs core so seems to be out of scope of Github repo issues.
> >>
> >> Attaching samle code and LLDB backtrace.
> >> Also attaching report from built-in MacOS crash reporting tool just in
> case.
> >
> > Thanks.
> >
> > Wilhelm and Yuan, could you please look into this soon?
>
> That’s bizarre, might have some bug around ranges. I’m looking into this.
> Hopefully I can figure it out in a few days :-(
>
> Yuan
I can reproduce the issue by following the above instructions, but need to
do some digging. It only seems to be the case with embedded heex and not
with heex-ts-mode by itself.
WIlhelm
