bug#73004: [PATCH] Make `dired-do-open' work on non GNU/Linux systems

Juri Linkov writes: [...] > The current implementation is based on long discussions including bug#18132. > So everyone is welcome to improve it, it's not cast in stone. Thanks for the pointer. I'm proposing the following patch then. >From d8e59996f8a8dccd564cb27e5a2a56f83cb2db6f Mon Sep 17 00:

bug#72986: Disabling menu-bar-mode changes size of new frames

> I checked out git master HEAD (currently df57e44a08f) and reverted commit > 241616831024c9c9fe2b2378b611db0a560b9675 on top of that. Good. > and please first run without the commit under >> gdb with a breakpoint at the line >> >> adjust_frame_size (f, -1, -1, 2, 0, Qmenu_bar_lines); >>

bug#72986: Disabling menu-bar-mode changes size of new frames

On Fri, 6 Sept 2024 at 08:54, martin rudalics wrote: > > Inexplicable to me. Please conduct both runs once more. But rather > than using the debugger simply evaluate > > (setq frame-size-history '(100)) > > in the initial frame, do C-x 5 2, evaluate > > (frame--size-history) > > and post the co

bug#72999: 29.4; fill-paragraph error in latex mode

tags 72999 notabug close 72999 thanks Vadim Zaliva writes: > Removing the following from my .emacs fixed the problem: > > (use-package latex-extra > :ensure t > :hook (LaTeX-mode . latex-extra-mode)) Thanks for reporting back. Maybe you want to report the issue to latex-extra tracker[1].

bug#57627: 29.0.50; [native-compilation] cl-loaddefs.el recompiled on startup

Phil Sainty writes: > https://emacs.stackexchange.com/questions/82010 indicates > that this bug was fixed for *.el files, but remains in effect > for the *.el.gz case. Hi Phil, can you reproduce this? ATM I cannot with my emacs 30 installed. Andrea

bug#69097: [PATCH] Add 'kill-region-or-word' command

> From: Sean Whitton > Cc: Eli Zaretskii , stefankan...@gmail.com, > acora...@gnu.org, j...@linkov.net, r...@gnu.org, 69...@debbugs.gnu.org > Date: Fri, 06 Sep 2024 11:36:25 +0100 > > I think you're right, but I would like to commit my function first, so > that I get attribution (it did tak

bug#69097: [PATCH] Add 'kill-region-or-word' command

Hello, On Thu 05 Sep 2024 at 02:38pm GMT, Philip Kaludercic wrote: > In that case, it would be difficult to use it directly in this > implementation, as kill-region needs a command that just moves the > point. I guess it would be possible to hack something together with > atomic change groups, b

bug#69097: [PATCH] Add 'kill-region-or-word' command

Hello, On Fri 06 Sep 2024 at 11:36am +01, Sean Whitton wrote: > diff --git a/doc/lispref/positions.texi b/doc/lispref/positions.texi > index 37cfe264157..b576df82382 100644 > --- a/doc/lispref/positions.texi > +++ b/doc/lispref/positions.texi > @@ -275,6 +275,19 @@ Word Motion > syntax tables. >

bug#72986: Disabling menu-bar-mode changes size of new frames

> Buffer contents for master HEAD after C-x 5 2: I can't figure out what's going on. We get a ConfigureNotify, PS=400x374, XS=1280x1354 event that tells us to set the frame to some "reasonable" size at least. And the penultimate lines > change_frame_size (5), TS=352x374~>1232x1354, TC=22x10~>

bug#73016: Potential inclusion of kbd-mode, part of kmonad, in Non-GNU ELPA

Hi, thanks to Jeremy for submitting this, and to Philip for reviewing! I'm travelling right now, so I'll keep this short; more to come in a few days I hope. On Thu, Sep 05 2024 09:53, Philip Kaludercic wrote: > [… 12 lines elided …] > >> On behalf of the author, Tony Zorman, I would like to requ

bug#73018: 31.0.50; wdired + replace-regexp only modifies the visible portion of the buffer

Juri Linkov writes: > Maybe this is reproducible only on very long Dired buffers? I tried in a buffer with over 19,000 files. I should have experienced a problem (no matches found, nothing changed) if font-lock would be related. But every function involved always found matches hundreds of scre

bug#72986: Disabling menu-bar-mode changes size of new frames

On Fri, 6 Sept 2024 at 10:50, martin rudalics wrote: > > Buffer contents for master HEAD after C-x 5 2: > > I can't figure out what's going on. I couldn't make sense of the results I sent either, so I re-ran the tests. Buffer contents after C-x 5 2 with commit 24161683102 reverted: Frame siz

bug#72999: 29.4; fill-paragraph error in latex mode

Removing the following from my .emacs fixed the problem: (use-package latex-extra   :ensure t   :hook (LaTeX-mode . latex-extra-mode)) -- "La perfection est atteinte non quand il ne reste rien a ajouter, mais quand il ne reste rien a enlever." (Antoine de Saint-Exupery)

bug#73046: 29.4; Emacs 100% CPU usage for several seconds when opening dired buffer over TRAMP

Eli Zaretskii writes: Hi, >> >> It would also help if being over a slow connection didn't result in >> >> Emacs consuming 100% of the CPU via functions such as >> >> `tramp-wait-for-regexp' (based on profiler-report). Could some of this >> >> be done asynchronously? >> > >> > You could probably

bug#73046: 29.4; Emacs 100% CPU usage for several seconds when opening dired buffer over TRAMP

> From: Michael Albinus > Cc: Suhail Singh , 73...@debbugs.gnu.org > Date: Fri, 06 Sep 2024 15:23:57 +0200 > > > FWIW, I cannot reproduce this: I tried Dired on a remote host with > > which I have connection that is quite slow, and saw neither high CPU > > usage nor a significant delay in displa

bug#69097: [PATCH] Add 'kill-region-or-word' command

Hello, On Fri 06 Sep 2024 at 02:30pm +03, Eli Zaretskii wrote: > Thanks, but I see no reason to document this command in the manual, > certainly not in the ELisp reference (it's a command, not a function). > IMO it's obscure enough to be documented only in NEWS. That's quite fine with me. > Sho

bug#73046: 29.4; Emacs 100% CPU usage for several seconds when opening dired buffer over TRAMP

Eli Zaretskii writes: Hi Eli, >> > FWIW, I cannot reproduce this: I tried Dired on a remote host with >> > which I have connection that is quite slow, and saw neither high CPU >> > usage nor a significant delay in displaying a Dired buffer. >> >> It seems to be related to font-locking, indeed. S

bug#72986: Disabling menu-bar-mode changes size of new frames

> Now the change_frame_size(5) initial and final sizes look correct. OK. In the next step I'd like to isolate the menubar code as the sole culprit for what's going in. Please with master do (setq default-frame-alist '((width . 200))) or some other insanely large value so we can see whether we

bug#72986: Disabling menu-bar-mode changes size of new frames

On Fri, 6 Sept 2024 at 15:16, martin rudalics wrote: > > OK. In the next step I'd like to isolate the menubar code as the sole > culprit for what's going in. Please with master do > > (setq default-frame-alist '((width . 200))) > It takes effect on the initial frame, but doesn't affect the siz

bug#73072: 30.0.90; which-key uses unexpected format of version information

Inspecting the which-key source file shows many of the variable's `:package-version' information is in the form of a string instead of a cons cell with the car of the package name and the cdr of the string (See transient's '(transient . "0.1.0") :package-version for an example). This causes functio

bug#73046: 29.4; Emacs 100% CPU usage for several seconds when opening dired buffer over TRAMP

Eli Zaretskii writes: >> The version of `ls' on this host is: >> >> #+begin_quote >> ls (GNU coreutils) 8.32 >> Copyright (C) 2020 Free Software Foundation, Inc. >> License GPLv3+: GNU GPL version 3 or later >> . >> This is free software: you are free

bug#73046: 29.4; Emacs 100% CPU usage for several seconds when opening dired buffer over TRAMP

Eli Zaretskii writes: >> Based on =profiler-report=, the following function "chains" consume most of >> the >> CPU: >> - `font-lock-fontify-keywords-region' >> - tramp-sh-file-name-handler >> - tramp-sh-handle-file-truename >> - `tramp-wait-for-regexp' >> - tramp-sh-handle-file-e

bug#72597: 30.0.60; Eglot: MarkedString with embedded Carriage Return

Eli Zaretskii writes: > That depends on the reason why the CR character appeared there in the > first place. Are they required for the strings in questions, or are > they simply an artifact of how the server marshaled JSON data on the > wire? I am not convinced, in my mind if the marshaling o

bug#73046: 29.4; Emacs 100% CPU usage for several seconds when opening dired buffer over TRAMP

Michael Albinus writes: >>> Based on =profiler-report=, the following function "chains" consume most of >>> the >>> CPU: >>> - `font-lock-fontify-keywords-region' >>> - tramp-sh-file-name-handler >>> - tramp-sh-handle-file-truename >>> - `tramp-wait-for-regexp' >>> - tramp-sh-han

bug#73072: 30.0.90; which-key uses unexpected format of version information

> From: Constant > Date: Fri, 6 Sep 2024 11:09:41 -0400 > > Inspecting the which-key source file shows many of the variable's > `:package-version' information is in the form of a string instead of a > cons cell with the car of the package name and the cdr of the string Thanks, fixed.

bug#73018: 31.0.50; wdired + replace-regexp only modifies the visible portion of the buffer

Michael Heerdegen writes: > > Maybe this is reproducible only on very long Dired buffers? After following the recipe literally, I could reproduce that thing, too. Maybe this issue occurring depends on what exactly is replaced - symlink targets. In this case, (font-lock-ensure) does make a diff

bug#73046: 29.4; Emacs 100% CPU usage for several seconds when opening dired buffer over TRAMP

> From: Michael Albinus > Cc: suhailsingh...@gmail.com, 73...@debbugs.gnu.org > Date: Fri, 06 Sep 2024 16:09:23 +0200 > > Eli Zaretskii writes: > > >> It seems to be related to font-locking, indeed. See variable > >> `dired-font-lock-keywords'. It specifies face recognition running basic > >>

bug#73044: [PATCH] Add project-find-file-in-root

Version: 31.1 Hi Spencer, On 05/09/2024 17:01, Spencer Baugh via Bug reports for GNU Emacs, the Swiss army knife of text editors wrote: Several users have asked me for a command which is just find-file, but starting from the project root. In large projects, where project-files is expensive, t

bug#69097: [PATCH] Add 'kill-region-or-word' command

Sean Whitton writes: > Hello, > > On Fri 06 Sep 2024 at 02:30pm +03, Eli Zaretskii wrote: > >> Thanks, but I see no reason to document this command in the manual, >> certainly not in the ELisp reference (it's a command, not a function). >> IMO it's obscure enough to be documented only in NEWS. >

bug#73046: 29.4; Emacs 100% CPU usage for several seconds when opening dired buffer over TRAMP

Michael Albinus writes: >>> > FWIW, I cannot reproduce this: I tried Dired on a remote host with >>> > which I have connection that is quite slow, and saw neither high CPU >>> > usage nor a significant delay in displaying a Dired buffer. >>> >>> It seems to be related to font-locking, indeed. See

bug#73044: [PATCH] Add project-find-file-in-root

> Resent-To: bug-gnu-emacs@gnu.org > Date: Fri, 6 Sep 2024 19:20:16 +0300 > From: Dmitry Gutov > > > This command is equivalent to C-x p o C-x C-f, but it's nice to > > be able to bind it to a specific key. > > > > Overall, this is easy enough to provide, so let's just do that. > > Makes sense,

bug#73046: 29.4; Emacs 100% CPU usage for several seconds when opening dired buffer over TRAMP

Eli Zaretskii writes: > I think we should also try to establish how slow is that connection. > How much time does "ping" take? The server doesn't respond to "ping" requests so I cannot test that. There are however more than 14 hops as reported by mtr. How much more I cannot say, unfortunately.

bug#73046: 29.4; Emacs 100% CPU usage for several seconds when opening dired buffer over TRAMP

> From: Suhail Singh > Cc: suhailsingh...@gmail.com, Michael Albinus , > 73...@debbugs.gnu.org > Date: Fri, 06 Sep 2024 13:47:54 -0400 > > > How long does it take to fetch a file of, say 20 KBytes? > > Given a 20kb file generated via: > #+begin_src sh :results verbatim > mkdir -p /tmp/test

bug#72597: 30.0.60; Eglot: MarkedString with embedded Carriage Return

On Fri, Sep 6, 2024 at 6:44 AM Eli Zaretskii wrote: > > > From: Daniel Pettersson > > Cc: Eli Zaretskii , Troy Brown , > > felician.nem...@gmail.com, 72...@debbugs.gnu.org > > Date: Thu, 05 Sep 2024 23:32:08 +0200 > > > > > Anyway, if the solution is to be performed at this lower > > > level

bug#73044: [PATCH] Add project-find-file-in-root

On 06/09/2024 20:44, Eli Zaretskii wrote: Resent-To:bug-gnu-emacs@gnu.org Date: Fri, 6 Sep 2024 19:20:16 +0300 From: Dmitry Gutov This command is equivalent to C-x p o C-x C-f, but it's nice to be able to bind it to a specific key. Overall, this is easy enough to provide, so let's just do that

bug#73082: 30; Inconsistent Stipple Support

The :stipple face attribute is not consistently supported across all Emacs 30 builds, with incorrect or missing stipple display for NS and GTK+Cairo builds. The following test of :stipple should lead to an image similar to the attached. (let* ((w (window-font-width)) (stipple `(,w 1 ,(a

bug#43086: [PATCH] Allow tags backend to not query for TAGS file

On 03/09/2024 19:39, Philip Kaludercic wrote: 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-g

bug#72441: 31.0.50; Auth-source-pass doesn't match password attributes or hosts without user when extra-query-keywords is true

"J.P." writes: > While exploring ways to tackle this feature, I stumbled on a couple > minor bugs related to `auth-source-pass-extra-query-keywords'. > > Because there's no telling when we'll end up with something installable > for this feature, I've gone ahead and isolated the fixes into a separ

bug#73046: 29.4; Emacs 100% CPU usage for several seconds when opening dired buffer over TRAMP

Eli Zaretskii writes: > So if it takes 4 to 5 sec to move a 20KB file, then how much stuff > needs to be moved for the Dired listing? What does the below show, if > you run it on that remote machine? > > $ ls -al | wc Given that the contents of the remote directory can be exactly replicated (

bug#73084: [PATCH] Include the variable name in the `setopt` warning

Hello, The attached patch adds the variable name to the `setopt` warning. I write my Emacs config in an Org file, from which I make the Emacs Lisp file. Currently, if `setopt` detects that the value I wish to make a variable hold does not conform to the variable's Custom.el type, then it repo

bug#73044: [PATCH] Add project-find-file-in-root

> Date: Fri, 6 Sep 2024 23:05:06 +0300 > Cc: 73...@debbugs.gnu.org, sba...@janestreet.com > From: Dmitry Gutov > > On 06/09/2024 20:44, Eli Zaretskii wrote: > >> Resent-To:bug-gnu-emacs@gnu.org > >> Date: Fri, 6 Sep 2024 19:20:16 +0300 > >> From: Dmitry Gutov > >> > >>> This command is equivalent

bug#73082: 30; Inconsistent Stipple Support

Eli Zaretskii writes: >> Cc: Po Lu >> From: JD Smith >> Date: Fri, 6 Sep 2024 17:58:02 -0400 >> >> (let* ((w (window-font-width)) >>(stipple `(,w 1 ,(apply #'unibyte-string (make-list (/ (+ w 7) 8) >> 186) >> (insert "\n" (propertize (concat (make-string 15 ?\s) >>

bug#73082: 30; Inconsistent Stipple Support

> Cc: Po Lu > From: JD Smith > Date: Fri, 6 Sep 2024 17:58:02 -0400 > > (let* ((w (window-font-width)) >(stipple `(,w 1 ,(apply #'unibyte-string (make-list (/ (+ w 7) 8) > 186) > (insert "\n" (propertize (concat (make-string 15 ?\s) > "THIS IS A

bug#73082: 30; Inconsistent Stipple Support

JD Smith writes: > To my knowledge, the current situation for :stipple support in Emacs > 30 is as follows: > > * NS (partially working): Commit ef6ffbdc79 from last May provided a > partial fix, but stipples are black and white only (bug#70712) FWIW, this is what I see on macOS with NS-port: >

bug#43086: [PATCH] Allow tags backend to not query for TAGS file

> Cc: 43...@debbugs.gnu.org > Date: Sat, 7 Sep 2024 01:16:46 +0300 > From: Dmitry Gutov > > On 03/09/2024 19:39, Philip Kaludercic wrote: > >>> 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 > >>

bug#73046: 29.4; Emacs 100% CPU usage for several seconds when opening dired buffer over TRAMP

> From: Suhail Singh > Cc: Suhail Singh , michael.albi...@gmx.de, > 73...@debbugs.gnu.org > Date: Fri, 06 Sep 2024 20:19:34 -0400 > > Eli Zaretskii writes: > > > It needs to show around 40KB to explain 10 sec of delay. > > I don't understand your reasoning. It's simple arithmetics: if fetc