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

The important fact is that in the entire sequence of the initial frame's setup you never experience one of those strange ConfigureNotify events asking to shrink the frame. Why they happen only for subsequent frame creations will probably remain a mystery. A new mystery is that your creation of t

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

Thanks for your persistence, Martin! On Mon, 9 Sept 2024 at 09:58, martin rudalics wrote: > > I forgot whether creating an initial frame without menubar works > reasonably on your system. So please do the same once more but this > time with --eval "(setq default-frame-alist '((menu-bar-lines .

bug#72814: 31.0.50; Add a variable controlling doxygen support in C/C++/Java?

In data martedì 27 agosto 2024 14:22:16 CEST, Eli Zaretskii ha scritto: > > From: Yuan Fu > > Date: Mon, 26 Aug 2024 20:13:52 -0700 > > Cc: e...@gnu.org, > > > > vincenzo.pupi...@unimi.it > > > > Yuan Fu writes: > > > X-Debbugs-CC: e...@gnu.org , > > > vincenzo.pupi...@uni

bug#73129: 31.0.50; buffer-text-pixel-size vs. newlines

> Date: Mon, 9 Sep 2024 00:22:11 +0200 > From: David Ponce via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > Its seems that the function `buffer-text-pixel-size' is not working > as described when there are newlines in the buffer. Here is a quick > illustration (on my

bug#72765: Eglot + Clangd + Company + non-empty suffix = duplicate text

> Date: Mon, 9 Sep 2024 03:20:01 +0300 > Cc: Eli Zaretskii , 72...@debbugs.gnu.org > From: Dmitry Gutov > > > This now aborts (segfault?). At least something different. > > > > So, for the record, before this patch with the latest emacs-30, I get the > > results in failure1.txt and with your la

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

> Date: Mon, 9 Sep 2024 03:29:05 +0300 > Cc: phil...@posteo.net, 43...@debbugs.gnu.org > From: Dmitry Gutov > > On 07/09/2024 09:18, Eli Zaretskii wrote: > > >> Maybe just like this? This makes Xref identifier completion not query > >> for TAGS unless already loaded. In many cases that would be

bug#73131: 28.2; Yielded threads get killed on C-g

> From: Swapneil Singh > Date: Sun, 8 Sep 2024 12:08:00 -0400 > > When using the Emacs cooperative threading system in a new project, I > noticed that calling C-g results in quitting the background thread I > create, even when those threads are yielded. > > Sending this as a bug report per Eli Z

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

> Thanks for your persistence, Martin! Thanks for yours! > (No infinite loop!) Obviously. I modified the PGTK part. Please try again with what I attached now. martindiff --git a/src/gtkutil.c b/src/gtkutil.c index d57627f152f..89061245500 100644 --- a/src/gtkutil.c +++ b/src/gtkutil.c @@ -11

bug#73129: 31.0.50; buffer-text-pixel-size vs. newlines

On 09/09/2024 1:34 PM, Eli Zaretskii wrote: Date: Mon, 9 Sep 2024 00:22:11 +0200 From: David Ponce via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Its seems that the function `buffer-text-pixel-size' is not working as described when there are newlines in the buffer. He

bug#73129: 31.0.50; buffer-text-pixel-size vs. newlines

> Date: Mon, 9 Sep 2024 14:56:22 +0200 > Cc: 73...@debbugs.gnu.org > From: David Ponce > > > May I ask where and for what purpose did you need to measure pixel > > width of a string that included newlines? > > Actually, the current behavior doesn't really impact my current work. I > just noticed

bug#73144: [PATCH] Simple typo in `clean-buffer-list'

Tags: patch Hi, Here is a patch for a simple harmless typo in `clean-buffer-list'. In GNU Emacs 31.0.50 (build 23, x86_64-unknown-openbsd7.6) of 2024-09-07 built on computer Repository revision: 6dcd3d24045113fb0afec0d7f43e322c9baa06ab Repository branch: master Windowing system distributor 'The

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

On Mon, 9 Sept 2024 at 13:33, martin rudalics wrote: > Obviously. I modified the PGTK part. Please try again with what I > attached now. > This makes an obviously visible difference: C-x 5 2 opens a small frame which immediately becomes large. Here's the *frame-size-history* buffer: Frame si

bug#73146: segfaults

journalctl log https://paste.c-net.org/TackledPrepares emacs --debug-init log https://paste.c-net.org/BroodingKindling This happens every time I edit Python files and have an interactive REPL open. In GNU Emacs 29.4 (build 1, x86_64-redhat-linux-gnu, GTK+ Version 3.24.42, cairo version 1.18.

bug#70820: [PATCH] Editable grep buffers

[புதன் ஆகஸ்ட் 14, 2024] Visuwesh wrote: > [...] > If everyone is okay with the current patch, I can get to writing the > NEWS entry and updating the manual. Thanks. Sorry for the long delay. I've now attached a patch with such documentation changes. >From 52e4d82dd3f28065e5e3ea390c4629783bcf13

bug#73146: segfaults

> From: Torstein Sørnes > Date: Mon, 9 Sep 2024 15:56:27 +0200 > > journalctl log https://paste.c-net.org/TackledPrepares > emacs --debug-init log https://paste.c-net.org/BroodingKindling > > This happens every time I edit Python files and have an interactive REPL open. Thanks. I believe this

bug#72829: describe-function NEWS* scraper override

Yep, happy to discuss. The case for removals is that some symbols were actually removed in one Emacs version and then re-added later. My overall technique is to load everything that I can, dump all the symbols I found, and then diff those dumps between Emacs versions. Using my nix-emacs-ci buil

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

Juri Linkov writes: > M-: (buffer-substring (- (point-max) 2) (- (point-max) 1)) > => #("7" 0 1 (fontified nil invisible dired-hide-details-link)) > > M-> ;; (end-of-buffer) > > M-: (buffer-substring (- (point-max) 2) (- (point-max) 1)) > => #("7" 0 1 (face default dired-symlink-filename t fontif

bug#73098: setopt float warning unexpected

Ship Mints writes: > I'm suggesting that there will be noise from people who convert from a > working (setq some-package-option 2) to (setopt some-package-option > 2). This is not a request to change the elisp type system, it is a > request to consider if setopt's / customize internals should be

bug#73150: [PATCH] Human readable last display time of killed buffer

Tags: patch Hi, This patch display a human readable version of `buffer-display-time' when said buffer is selected to be killed. In GNU Emacs 31.0.50 (build 23, x86_64-unknown-openbsd7.6) of 2024-09-07 built on computer Repository revision: 6dcd3d24045113fb0afec0d7f43e322c9baa06ab Repository br

bug#73098: setopt float warning unexpected

> From: Michael Heerdegen > Cc: Eli Zaretskii , 73...@debbugs.gnu.org > Date: Mon, 09 Sep 2024 17:11:40 +0200 > > Ship Mints writes: > > > I'm suggesting that there will be noise from people who convert from a > > working (setq some-package-option 2) to (setopt some-package-option > > 2). This

bug#73098: setopt float warning unexpected

Perhaps an alternative macro `setopt-relaxed"? Documentation should suggest contacting package authors to request improvements (it's a very slow process to get misspecified packages updated and not all authors mean what they say when they themselves don't use the customize system--this group must k

bug#73098: setopt float warning unexpected

Eli Zaretskii writes: > > How about adding an option letting the user disable the type checking of > > some options? > > Like what? Would we accept, for example, a string where the type is > 'symbol'? Or any value where type is 'boolean'? The new option would have as value a list of option nam

bug#73098: setopt float warning unexpected

Ship Mints writes: > Perhaps an alternative macro `setopt-relaxed"? Documentation should > suggest contacting package authors to request improvements (it's a > very slow process to get misspecified packages updated and not all > authors mean what they say when they themselves don't use the > cust

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

> This makes an obviously visible difference: C-x 5 2 opens a small frame > which immediately becomes large. > > Here's the *frame-size-history* buffer: ... > ConfigureNotify, PS=1328x1260, XS=400x374, DS=1328x1260 > xg_frame_resized, rejected, PS=1328x1260, XS=400x374, DS=664x630 > tool-bar-lines

bug#73050: 30.0.90; Empty tool tip when hovering over tab-bar separator

>> >> Maybe this unasked-for default fallback is not needed after all: >> >> >> >> diff --git a/src/xdisp.c b/src/xdisp.c >> >> index f9a10267bad..18834c6b781 100644 >> >> --- a/src/xdisp.c >> >> +++ b/src/xdisp.c >> >> @@ -15155,8 +15155,6 @@ note_tab_bar_highlight (struct frame *f, int x, >> >>

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

> Would something like this be good? > > @@ -3740,8 +3740,12 @@ dired-isearch-search-filenames > - (isearch-search-fun-in-text-property > - (funcall orig-fun) '(dired-filename dired-symlink-filename))) > + (let ((search-fun > + (isearch-search-fun-in-text-property > + (funcall

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

>> Also noticed that doing the first replacement always raises an error: >> >> Debugger entered--Lisp error: (error "Match data clobbered by buffer >> modification hooks") >> replace-match("!" nil nil) >> replace-match-maybe-edit("!" nil nil nil (672 673 #) nil) >> perform-replace("7" "!" t t

bug#73098: setopt float warning unexpected

> From: Michael Heerdegen > Cc: Stefan Monnier , shipmi...@gmail.com, > 73...@debbugs.gnu.org > Date: Mon, 09 Sep 2024 18:38:43 +0200 > > Eli Zaretskii writes: > > > > How about adding an option letting the user disable the type checking of > > > some options? > > > > Like what? Would we ac

bug#73050: 30.0.90; Empty tool tip when hovering over tab-bar separator

> From: Juri Linkov > Cc: m...@daniel-mendler.de, 73...@debbugs.gnu.org > Date: Mon, 09 Sep 2024 20:17:03 +0300 > > > But on the tool bar there are no empty space between buttons. On the > > tab bar, there is. What I don't understand is why those empty spaces > > have tooltips. Because each t

bug#73098: setopt float warning unexpected

Eli Zaretskii writes: > Thanks, but this sounds like overkill to me. Hmm... maybe. And the idea of an extra macro? Michael.

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

I've removed the patch to frame.c, and I'm running with: emacs -Q --eval "(setq default-frame-alist '((menu-bar-lines . 0)))" On Mon, 9 Sept 2024 at 17:52, martin rudalics wrote: > > The result is not yet what I hoped for. We reject two ConfigureNotify > events but the ensuing xg_frame_set_ch

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

Hello Eli, Any comments on v4? I'd like to commit to unblock Philip. Thanks! -- Sean Whitton

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

Juri Linkov writes: > > Would something like this be good? > > > > @@ -3740,8 +3740,12 @@ dired-isearch-search-filenames > > - (isearch-search-fun-in-text-property > > - (funcall orig-fun) '(dired-filename dired-symlink-filename))) > > + (let ((search-fun > > + (isearch-search-fun-in-

bug#73050: 30.0.90; Empty tool tip when hovering over tab-bar separator

close 73050 30.0.60 thanks >> > But on the tool bar there are no empty space between buttons. On the >> > tab bar, there is. What I don't understand is why those empty spaces >> > have tooltips. Because each tab-bar button has a valid, non-nil >> > tooltip, so the problem is with the tooltips p

bug#73098: setopt float warning unexpected

> From: Michael Heerdegen > Cc: monn...@iro.umontreal.ca, shipmi...@gmail.com, 73...@debbugs.gnu.org > Date: Mon, 09 Sep 2024 19:46:56 +0200 > > Eli Zaretskii writes: > > > Thanks, but this sounds like overkill to me. > > Hmm... maybe. And the idea of an extra macro? Likewise. I think we

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

> From: Sean Whitton > Cc: phil...@posteo.net, stefankan...@gmail.com, acora...@gnu.org, > j...@linkov.net, r...@gnu.org, 69...@debbugs.gnu.org > Date: Mon, 09 Sep 2024 18:54:16 +0100 > > Hello Eli, > > Any comments on v4? When I have time. > I'd like to commit to unblock Philip. Sure,

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

Sean Whitton writes: > Hello Eli, > > Any comments on v4? I'd like to commit to unblock Philip. Thanks! Here is my updated patch. If you want to, you can push both at once so that we can close the issue more quickly as soon as Eli has time to take a look: >From 0f19dadb75a01873cb3f40a6addd82

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

Hello, On Mon 09 Sep 2024 at 10:03pm +03, Eli Zaretskii wrote: >> From: Sean Whitton >> Cc: phil...@posteo.net, stefankan...@gmail.com, acora...@gnu.org, >> j...@linkov.net, r...@gnu.org, 69...@debbugs.gnu.org >> Date: Mon, 09 Sep 2024 18:54:16 +0100 >> >> Hello Eli, >> >> Any comments on

bug#73098: setopt float warning unexpected

> Like what? Would we accept, for example, a string where the type is > 'symbol'? Or any value where type is 'boolean'? > > And I'm also not sure we want this: presumably, if the defcustom's > author specified a type, they meant it, no? I tend to agree. If the type doesn't accept the value, you

bug#71893: 27.1; Gnus pop3 download progress goes over 100%

On Sat, Aug 31, 2024 at 4:53 AM Eli Zaretskii wrote: > Any progress there? I've the 29.3 set up and I have not yet managed to reproduce. I've tested it three times already with a set of messages to be downloaded that I would believe it would hit the problem. I'm going to try to change my POP3 s

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

On 09/09/2024 14:54, Eli Zaretskii wrote: Date: Mon, 9 Sep 2024 03:29:05 +0300 Cc: phil...@posteo.net, 43...@debbugs.gnu.org From: Dmitry Gutov On 07/09/2024 09:18, Eli Zaretskii wrote: Maybe just like this? This makes Xref identifier completion not query for TAGS unless already loaded. In ma

bug#72765: Eglot + Clangd + Company + non-empty suffix = duplicate text

On 09/09/2024 14:46, Eli Zaretskii wrote: Date: Mon, 9 Sep 2024 03:20:01 +0300 Cc: Eli Zaretskii , 72...@debbugs.gnu.org From: Dmitry Gutov This now aborts (segfault?). At least something different. So, for the record, before this patch with the latest emacs-30, I get the results in failure1

bug#72765: Eglot + Clangd + Company + non-empty suffix = duplicate text

Hi Joao, On 08/09/2024 18:51, João Távora wrote: So, for the record, before this patch with the latest emacs-30, I get the results in failure1.txt I've taken some more looks at the test output. [eglot-tests] contents of `*EGLOT (cmpl-project/(rust-mode rust-ts-mode)) output*': [eglot-tests]

bug#72862: 29.1; Strange interaction between append-next-kill and kill-whole-line

On Sun, Sep 8, 2024 at 1:56 AM Eli Zaretskii wrote: > Since kill-whole-line kills both backward and forward from point, it > seems we should expect that the first part is prepended to previous > kill, whereas the second part is appended. Which is what the command > already does. > > WDYT? > Sin

bug#73159: 30.0.90; uniscribe / harfbuzz are not initialized on Windows, resulting in fallback to gdi

I recently pulled the latest emacs-30 branch (f47297782bdb5e5a07e02f119c8013d11f7d7fae), and I'm building emacs using MSYS2 mingw64 on Windows. With a build on this branch, certain symbols (from the nerd-icons package) were rendering as boxes and not their actual symbol. I suspected that this was

bug#73161: 29.4; Exporting Org Agenda to PDF with Cyrillic Characters

Hello, Meta: This message was originally posted to the help-gnu-emacs mailing list, but I suspect that it may have gone unanswered because it wasn’t the right place for this kind of query. Please feel free to ignore this message here and reply on the mailing list if that’s more appropriate. I’m

bug#73131: 28.2; Yielded threads get killed on C-g

inhibit-quit works great, thanks for the fix! On Mon, Sep 9, 2024 at 8:22 AM Eli Zaretskii wrote: > > > From: Swapneil Singh > > Date: Sun, 8 Sep 2024 12:08:00 -0400 > > > > When using the Emacs cooperative threading system in a new project, I > > noticed that calling C-g results in quitting the

bug#73159:

This actually seems to be caused by the pdmp failing to load. `make install` installs the pdmp file as `EMACS_PDMP = `./src/emacs${EXEEXT} --fingerprint`.pdmp`. However, this is not the filename that emacs tries to load - it attempts to load it from the wrong directory, which fails. That seems to

bug#73133: 29.2; EWW fails to render some webpages

On 9/8/2024 1:52 PM, Ganimard via Bug reports for GNU Emacs, the Swiss army knife of text editors wrote: I have recently discovered the website gastonle.ru, however it does not render with Emacs Web Wowser.  It appears to be a relatively simple website and I cannot see what would prohibit it from

bug#73161: 29.4; Exporting Org Agenda to PDF with Cyrillic Characters

Serghei Iakovlev via "Bug reports for GNU Emacs, the Swiss army knife of text editors" writes: > --8<---cut here---start->8--- > (require 'ps-print) > (ps-print-buffer-with-faces > (concat (file-name-sans-extension file) ".ps")) > (call-process "ps2pdf" nil n

bug#73027: Fwd: 31.0.50; tab-bar-formal-global erased global-modeline-string's mouse hover/click action menu

>> Also please eval these calls and show their return values. > > 1. (mu4e--modeline-string) : > > #(" 🌀0/0 " 1 2 (help-echo "mu4e favorite bookmark 'Unread messages': Thanks for the reproducible test case. The problem is that the mode-line keymap can't be used without replacing the symbol 'mode-

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

>>> Also noticed that doing the first replacement always raises an error: >>> >>> Debugger entered--Lisp error: (error "Match data clobbered by buffer >>> modification hooks") >>> replace-match("!" nil nil) >>> replace-match-maybe-edit("!" nil nil nil (672 673 #) nil) >>> perform-replace("7"