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

[Bug reports for GNU Emacs, the Swiss army knife of text editors]

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 the initial frame has one
xg_frame_set_char_size call followed by two ConfigureNotify events where
the first event asks for 1328x1260 and the second one for 1328x1258
pixels.  The same happens again after setting up the tool bar only that
there the first event has 1328x1258 (which matches the previous) and the
second one asks for 1280x1354 pixels.  In the first event
xg_frame_resized concludes that nothing changed, in the second event it
notices a change.

When I do the same thing on my system I get

Frame size history of #
x_create_frame_1 (5), TS=80x25~>720x550, NS=80x25~>736x550, IS=80x25~>736x550, 
MS=18x44 IH IV
gui_figure_window_size (5), TS=720x550~>720x792, TC=80x25~>80x36, 
NS=736x550~>736x792, IS=736x550~>736x792, MS=18x44 IH IV
scroll-bar-width (3), NS=736x792~>752x792, IS=736x792~>752x792, MS=90x110
scroll-bar-height (3), MS=90x110
x_create_frame_2 (0), MS=90x110
xg_frame_set_char_size, invisible, PS=752x792, XS=752x792, DS=752x792
xg_frame_set_char_size (5), MS=18x44 IH IV
MapNotify, not hidden & not iconified, PS=752x792, DS=752x792
ConfigureNotify, PS=752x792, XS=752x792, DS=752x792
xg_frame_resized, unchanged, PS=752x792, XS=752x792
menu-bar-lines (2), MS=90x110
xg_frame_set_char_size, visible, PS=752x792, XS=752x792, DS=752x792
ConfigureNotify, PS=752x792, XS=752x792, DS=752x792
xg_frame_resized, unchanged, PS=752x792, XS=752x792
tool-bar-lines (2), MS=90x110
xg_frame_set_char_size, visible, PS=752x792, XS=752x792, DS=752x792
ConfigureNotify, PS=752x792, XS=752x792, DS=752x792
xg_frame_resized, unchanged, PS=752x792, XS=752x792

and the sizes requested by xg_frame_set_char_size and the ones received
by ConfigureNotify remain the same throughout - 752x792.

I have no hope that anyone will tell us what's going on here.  Hence
this new mystery will remain unsolved too, I presume.  But maybe I'm
missing an important detail here.

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 . 0)))"
appended to your emacs call.  This will conclude our experiments with
the history of the initial frame.

Next let's try the following: Upon receiving a ConfigureNotify event we
don't call change_frame_size when _we_ conclude that nothing has
changed.  This conclusion might be wrong so let's _always_ process a
ConfigureNotify event via change_frame_size with the trivial patch I
attached as gtkutil-change.diff.

If this doesn't accomplish anything (as I'd expect), let's try to be
stubborn.  For this purpose apply the less trivial patch attached as
gtkutil-reject.diff, do

(setq frame-size-history '(100))

C-x 5 2

(frame--size-history)

and tell me what *frame-size-history* says in the new frame (if we're
unlucky and I did something wrong, this might get your Emacs run into an
infinite loop and you have to kill it by external means).

martindiff --git a/src/gtkutil.c b/src/gtkutil.c
index d57627f152f..c5c99d6f1bd 100644
--- a/src/gtkutil.c
+++ b/src/gtkutil.c
@@ -1129,11 +1129,49 @@ xg_set_geometry (struct frame *f)
 }
 }
 
+static struct frame *last_resize_frame = NULL;
+static int last_resize_height = -1;
+static int last_resize_width = -1;
+static int last_resize_count = 0;
+
 /** Function to handle resize of native frame F to WIDTH and HEIGHT
 pixels after we got a ConfigureNotify event.  */
 void
 xg_frame_resized (struct frame *f, int width, int height)
 {
+#ifndef HAVE_PGTK
+  if (f == last_resize_frame
+  && width != last_resize_width
+  && height != last_resize_height
+  && last_resize_count <= 3)
+/* We did not get what we wanted, retry.  */
+{
+  if (CONSP (frame_size_history))
+	frame_size_history_extra
+	  (f, build_string ("xg_frame_resized, rejected"),
+	   FRAME_PIXEL_WIDTH (f), FRAME_PIXEL_HEIGHT (f), width, height,
+	   last_resize_width, last_resize_height);
+
+  if (FRAME_GTK_OUTER_WIDGET (f))
+	gtk_window_resize (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)),
+			   last_resize_width, last_resize_height);
+  else
+	gtk_widget_set_size_request (FRAME_GTK_WIDGET (f),
+ last_resize_width, last_resize_height);
+
+  last_resize_count++;
+
+  return;
+}
+  else
+/* We either got what we asked for or lost the battle.  */
+{
+  last_resize_frame = NULL;
+  last_resize_height = -1;
+  last_resize_width = -1;
+  last_resize_count = 0;
+}
+#endif
   /* Ignore case where size of native rectangle didn't change.  */
   if (width != FRAME_PIXEL_WIDTH (f)
   || height != FRAME_PIXEL_HEIGHT (f)
@@ -1300,16 +1338,17 @@ xg_frame_set_char_size (struct frame *f, int width, int height)
   g

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

[Bug reports for GNU Emacs, the Swiss army knife of text editors]

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 . 0)))"
> appended to your emacs call.  This will conclude our experiments with
> the history of the initial frame.
>

So, I'm doing this with git master HEAD still with the patch that changes
frame.c to initialize frame_size_history thus:

  frame_size_history = Fcons (make_fixnum (100), Qnil);

And here is the contents of *frame-size-history*:

Frame size history of #
x_create_frame_1 (5), TS=80x25~>1280x875, NS=80x25~>1296x875,
IS=80x25~>1296x875, MS=32x70 IH IV
gui_figure_window_size (5), TS=1280x875~>1280x1260, TC=80x25~>80x36,
NS=1296x875~>1296x1260, IS=1296x875~>1296x1260, MS=32x70 IH IV
scroll-bar-width (3), NS=1296x1260~>1328x1260, IS=1296x1260~>1328x1260,
MS=160x175
scroll-bar-height (3), MS=160x175
menu-bar-lines (2), MS=160x175
x_create_frame_2 (0), MS=160x175
xg_frame_set_char_size, invisible, PS=1328x1260, XS=1328x1260, DS=1328x1260
xg_frame_set_char_size (5), MS=32x70 IH IV
x_make_frame_visible
MapNotify, not hidden & not iconified, PS=1328x1260, DS=1328x1260
ConfigureNotify, PS=1328x1260, XS=1328x1260, DS=1328x1260
xg_frame_resized, unchanged, PS=1328x1260, XS=1328x1260
ConfigureNotify, PS=1328x1260, XS=1328x1258, DS=1328x1260
xg_frame_resized, changed, PS=1328x1260, XS=1328x1258
change_frame_size_1, delayed, PS=1328x1260, XS=1328x1258, DS=1328x1260
change_frame_size (5), TS=1280x1260~>1280x1258, TC=80x36~>80x35,
NS=1328x1260~>1328x1258, IS=1328x1260~>1328x1258, MS=32x70 IH IV
menu-bar-lines (2), MS=160x175
xg_frame_set_char_size, visible, PS=1328x1258, XS=1328x1258
ConfigureNotify, PS=1328x1258, XS=1328x1258
xg_frame_resized, unchanged, PS=1328x1258, XS=1328x1258
tool-bar-lines (2), MS=160x175
xg_frame_set_char_size, visible, PS=1328x1258, XS=1328x1258
ConfigureNotify, PS=1328x1258, XS=1328x1258
xg_frame_resized, unchanged, PS=1328x1258, XS=1328x1258
set_window_configuration (4), MS=160x175 IH IV

(I observe that this seems to behave just like the "vanilla" version of the
test, only there's no menu bar in the initial frame.)


> Next let's try the following: Upon receiving a ConfigureNotify event we
> don't call change_frame_size when _we_ conclude that nothing has
> changed.  This conclusion might be wrong so let's _always_ process a
> ConfigureNotify event via change_frame_size with the trivial patch I
> attached as gtkutil-change.diff.
>

OK, so with just gtkutil-change.diff applied to git master HEAD, I get the
same behaviour as ever when starting 'emacs -Q' and then typing C-x 5 2.

If this doesn't accomplish anything (as I'd expect), let's try to be
> stubborn.  For this purpose apply the less trivial patch attached as
> gtkutil-reject.diff, do
>
> (setq frame-size-history '(100))
>
> C-x 5 2
>
> (frame--size-history)
>
> and tell me what *frame-size-history* says in the new frame


Frame size history of #
x_create_frame_1 (5), TS=80x25~>1280x875, NS=80x25~>1296x875,
IS=80x25~>1296x875, MS=32x70 IH IV
gui_figure_window_size (5), TS=1280x875~>1280x1260, TC=80x25~>80x36,
NS=1296x875~>1296x1260, IS=1296x875~>1296x1260, MS=32x70 IH IV
scroll-bar-width (3), NS=1296x1260~>1328x1260, IS=1296x1260~>1328x1260,
MS=160x175
scroll-bar-height (3), MS=160x175
menu-bar-lines (2), MS=160x175
x_create_frame_2 (0), MS=160x175
xg_frame_set_char_size, invisible, PS=1328x1260, XS=1328x1260, DS=1328x1260
xg_frame_set_char_size (5), MS=32x70 IH IV
x_make_frame_visible
MapNotify, not hidden & not iconified, PS=1328x1260, DS=1328x1260
ConfigureNotify, PS=1328x1260, XS=400x340, DS=1328x1260
xg_frame_resized, changed, PS=1328x1260, XS=400x340
change_frame_size_1, delayed, PS=1328x1260, XS=400x340, DS=1328x1260
tool-bar-lines (2), NS=1328x1260~>400x340, MS=160x175
xg_frame_set_char_size, visible, PS=1328x1260, XS=400x340, DS=400x340
ConfigureNotify, PS=1328x1260, XS=400x374, DS=400x340
xg_frame_resized, changed, PS=1328x1260, XS=400x374, DS=400x340
change_frame_size_1, delayed, PS=1328x1260, XS=400x374, DS=400x340
change_frame_size (5), TS=1280x1260~>352x374, TC=80x36~>22x10,
NS=1328x1260~>400x374, IS=1328x1260~>400x374, MS=32x70 IH IV
set_window_configuration (4), MS=160x175 IH IV
set_window_configuration (4), MS=160x175 IH IV

(No infinite loop!)

-- 
https://rrt.sc3d.org

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

[Vincenzo Pupillo]

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...@unimi.it
> > > 
> > > Should we add a custom option that controls whether to enable doxygen
> > > support in c-ts-mode/c++-ts-mode/java-ts-mode?
> > > 
> > > Technically this isn’t a problem, since the doxygen support is only
> > > enabled if there’s doxygen grammar on the system. But many people
> > > (me) might install a grammar bundle that includes dozens of
> > > grammars for convenience. Then the doxygen support would turn on when
> > > the user doesn’t really intend to use it.
> > > 
> > > I propose we add custom options like c-ts-mode-enable-doxygen and set it
> > > to t by default, so the default behavior is still to enable doxygen
> > > support when the grammar for it exists, but people who don’t want to pay
> > > for it can turn it off by setting the option to nil.
> > > 
> > > Yuan
> > 
> > Eli, WDYT?
> 
> I'm okay with such an option, but it should be careful to check
> whether the corresponding grammar library is available, and offer a
> user-friendly diagnostic if not.

Try to take a look at this patch. Is it okay?

Vincenzo
>From 0a6d90f25dfddc1da88b5e47a97bc09fe50a6d34 Mon Sep 17 00:00:00 2001
From: Vincenzo Pupillo 
Date: Mon, 9 Sep 2024 09:20:42 +0200
Subject: [PATCH] Add a user option to disable Doxygen syntax highlighting
 (bug#72814).

Both 'c-ts-mode' and 'java-ts-mode' have a new user option,
'c-ts-mode-enable-doxygen' and 'java-ts-mode-enable-doxygen'
(defaults to t) which allow to disable syntax highlighting of comment
blocks based on the Doxygen grammar.

* lisp/progmodes/c-ts-mode.el: Add the 'c-ts-mode-enable-doxygen' user
option variable to disable doxygen grammar. (bug#72814)

* lisp/progmodes/c-ts-mode.el (c-ts-mode, c++-ts-mode): Use the new
'c-ts-mode-enable-dodygen' option.

* lisp/progmodes/java-ts-mode.el: Add the 'java-ts-mode-enable-doxygen'
user option variable to disable doxygen grammar. (bug#72814)

* lisp/progmodes/java-ts-mode.el (java-ts-mode): Use the new
'java-ts-mode-enable-dodygen' option.

* etc/NEWS: Document the change.
---
 etc/NEWS   | 16 
 lisp/progmodes/c-ts-mode.el| 71 --
 lisp/progmodes/java-ts-mode.el | 35 +++--
 3 files changed, 83 insertions(+), 39 deletions(-)

diff --git a/etc/NEWS b/etc/NEWS
index c6f8b0062e4..5762bc22c54 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -224,6 +224,22 @@ package of the current buffer.  It is bound to 'C-c C-t p' in 'go-ts-mode'.
 The 'go-ts-mode-build-tags' user option is available to set a list of
 build tags for the test commands.
 
+** C-ts mode
+

+*** New user option 'c-ts-mode-enable-doxygen'.
+By default, 'c-ts-mode-enable-doxygen' is t, and doxygen comment blocks
+are syntax-highlighted if the doxygen grammar is available.  If Non-nil,
+the comment blocks are highlighted like other comments.
+
+** Java-ts mode
+

+*** New user option 'java-ts-mode-enable-doxygen'.
+By default, 'java-ts-mode-enable-doxygen' is t, and doxygen comment blocks
+are syntax-highlighted if the doxygen grammar is available.  If Non-nil,
+the comment blocks are highlighted like other comments.
+
 ** Emacs Lisp mode
 
 ---
diff --git a/lisp/progmodes/c-ts-mode.el b/lisp/progmodes/c-ts-mode.el
index 7f23b30a88a..3adf5673e67 100644
--- a/lisp/progmodes/c-ts-mode.el
+++ b/lisp/progmodes/c-ts-mode.el
@@ -216,6 +216,17 @@ c-ts-mode-emacs-sources-support
   :safe 'booleanp
   :group 'c)
 
+(defcustom c-ts-mode-enable-doxygen t
+  "Enable doxygen syntax highlighting.
+If nil, disable doxygen based font lock for comment.
+This needs to be set before enabling `c-ts-mode'; if you change
+the value after enabling `c-ts-mode', toggle the mode off and on
+again."
+  :version "31.1"
+  :type 'boolean
+  :safe 'booleanp
+  :group 'c)
+
 ;;; Syntax table
 
 (defvar c-ts-mode--syntax-table
@@ -1354,20 +1365,22 @@ c-ts-mode
 (treesit-font-lock-recompute-features '(emacs-devel)))
 
   ;; Inject doxygen parser for comment.
-  (when (treesit-ready-p 'doxygen t)
-(setq-local treesit-primary-parser primary-parser)
-(setq-local treesit-font-lock-settings
-(append
- treesit-font-lock-settings
- c-ts-mode-doxygen-comment-font-lock-settings))
-(setq-local treesit-range-settings
-(treesit-range-rules
- :embed 'doxygen
- :host 'c
- :local t
- `(((comment) @cap
-(:match
- ,c-ts-mode--doxygen-comment-regex @cap)
+  (when c-ts-mode-enable-doxygen
+(if (not (treesit-ready-p 'doxygen t))
+(warn "Doxygen language grammar is un

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

[Eli Zaretskii]

> 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 laptop (frame-char-width) returns 12 pixels):
> 
> ;; As expected.
> (with-temp-buffer
>(insert "abcdef")
>(car (buffer-text-pixel-size nil nil t)))
> 72
> 
> ;; I suppose it is as expected because newline is not displayed.
> (with-temp-buffer
>(insert "\n")
>(car (buffer-text-pixel-size nil nil t)))
> 0
> 
> ;; ?
> (with-temp-buffer
>(insert "abcd\nef")
>(car (buffer-text-pixel-size nil nil t)))
> 48

The above is the intended behavior, assuming that the default width of
the frame's characters is 12 in your case.  The maximum width of the
text "abcd\nef" is 4 characters ("abcd"), which are 12*4 = 48 pixels.
The part after the newline is only 2 characters, so it is narrower,
and does not affect the result.

IOW, buffer-text-pixel-size measures the 2D _dimensions_ of the text,
not is total width.

> The doc string of `buffer-text-pixel-size' mentions:
> 
> "Return size of whole text of BUFFER-OR-NAME in WINDOW."

It also says:

  The return value is a cons of the maximum pixel-width of any text
  line and the pixel-height of all the text lines of the buffer
  specified by BUFFER-OR-NAME.

Does the above explain the behavior you see?

This is not a bug.

> So ,I expect that the last example will return 72px (6 x 12px) + 0px
> for the newline.  But the result is 48px, which means that all the
> text after the first newline is not counted.

Your expectations are incorrect, see above.

> This also impacts "string-pixel-width" which is supposed to return
> the pixel size of the passed string, not part of it:
> 
> (string-pixel-width "abcdef") => 72
> (string-pixel-width "\n") => 0
> (string-pixel-width "abcd\nef") => 48
> (string-pixel-width "abcd\nef\ngh") => 48

Yes.  If you want the _total_ width of a string, remove the newlines
from it.

I think I understand the source of your confusion, so I have now
clarified these subtle points in the doc strings of
window-text-pixel-size, buffer-text-pixel-size, and
string-pixel-width.

> At least this limitation should be mentioned in the doc string?

I've now done so (and they are not limitations, but conscious design
decisions which have good reasons).

> A possible fix for `string-pixel-width' could be to remove all
> the newlines from the passed string before to call
> `buffer-text-pixel-size'?  Something like this:

Thanks, but that would be the wrong thing.  If the caller wants a
total width, the caller should remover the newlines or measure each
substring separately and add the results.

May I ask where and for what purpose did you need to measure pixel
width of a string that included newlines?

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

[Eli Zaretskii]

> 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 last redisplay-skip-initial-frame 
> > patch
> > I get failure2.txt.
> > 
> > I've produced these files with
> > 
> > make -C test eglot-tests SELECTOR=\"rust-completion\" 2>&1 | tee 
> > failure1.txt
> 
> So it's reproducible. Great!
> 
> Could someone look into the segfault? The repro steps are simple:
> 
> 1) apply the patch above,
> 2) run 'make -C test eglot-tests' or the longer command above which 
> executes just one test from that file.
> 
> The backtrace that I managed to generate is attached.

Thanks.  Please try the patch below.

P.S. I'm not at all sure this is the last segfault you will see
because you are playing with fire: you are not supposed to reset
redisplay-skip-initial-frame to nil in batch-mode tests that test
redisplay-related features!

diff --git a/src/xdisp.c b/src/xdisp.c
index bf7d84c..a1319e7 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -22089,7 +22089,8 @@ #define GIVE_UP(X) return 0
 
   /* Window must either use window-based redisplay or be full width.  */
   if (!FRAME_WINDOW_P (f)
-  && (!FRAME_LINE_INS_DEL_OK (f)
+  && (FRAME_INITIAL_P (f)
+ || !FRAME_LINE_INS_DEL_OK (f)
  || !WINDOW_FULL_WIDTH_P (w)))
 GIVE_UP (4);
 

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

[Eli Zaretskii]

> 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 TRT,
> >> although `C-u M-.` seems to regress (seems like we *would* want to query
> >> eagerly there).
> > 
> > I don't understand why the obvious way of asking the user whether they
> > would like to generate the tags table is not the solution here.  What
> > did I miss?
> 
> I don't know if it's obvious, given that the optimal scenario at the 
> beginning of the report describes
> 
>... allow the backend to never query a TAGS file

But what do you expect from a backend that depends on TAGS to do when
TAGS is not there?  You yourself just noticed the regression.  Why
would we want that?

AFAIU, the problem here is that the backend can avoid querying when
the TAGS file exists.  But what do you expect it to do when it does
_not_ exist?  We have the regeneration feature now, so I suggested to
ask the user whether to regenerate the file, after which it could be
read without any further prompts.

IOW, the query I suggested was not the query the OP suggested to
avoid, it's a different query due to different kind of trouble.

> Adding a query to avoid querying might not be ideal. And if we did 
> query, that would raise a question of where to store the answer (should 
> it be global, or per-project, or temporary somehow?).

Sorry, you lost me here.

> As it is, we already have a hint of the user preference from the fact 
> that they have visited a TAGS file already (or not), or enabled 
> etags-regen-mode (or not). It's not ironclad, but we could rely on these 
> indicators to decide.

Then regenerate TAGS without asking, if you think it's reasonable.
But letting the backend continue without TAGS is not a reasonable
solution, IMO.

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

[Eli Zaretskii]

> 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 Zaretskii's mention that it may not
> be expected behavior
> (https://www.reddit.com/r/emacs/comments/1fbkkii/comment/lm3boja/).
> 
> Repro recipe:
> - emacs -Q
> - `C-x 3` and run `list-threads` in the new window, then return to the
> older window
> - `M-:` `(make-thread (lambda () (cl-loop while t do (progn
> (thread-yield) (sleep-for 30)` and wait for the new thread to yield to
> the main thread.
> - `C-g`. The new thread disappears from the `list-threads` window.
> 
> 
> Note: While I am admittedly on Windows, given this behavior is within the
> cooperative threads of the Emacs runtime (rather than actual Windows
> threads) I *really* doubt that has anything to do with it.

Actually, your being on MS-Windows does explain what you see, because
the way C-g is processed is system-dependent.  When I said "this is
not supposed to happen", I assumed you were doing this on GNU/Linux or
another Posix platform.

Indeed, on MS-Windows this is expected behavior: pressing C-g in the
above scenario will set the quit-flag, and the loop will then quit.
To prevent that, you need to use this simple technique:

  (make-thread
   (lambda ()
 (let ((inhibit-quit t))  ;; 
   (cl-loop
while t do
(progn
  (thread-yield)
  (sleep-for 30))

Btw, my recommendation is to bind inhibit-quit non-nil around the
thread functions in all cases, if you want background thread to never
be interrupted by C-g and the like.

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

[Bug reports for GNU Emacs, the Swiss army knife of text editors]

> 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
@@ -1129,11 +1129,45 @@ xg_set_geometry (struct frame *f)
 }
 }
 
+static struct frame *last_resize_frame = NULL;
+static int last_resize_height = -1;
+static int last_resize_width = -1;
+static int last_resize_count = 0;
+
 /** Function to handle resize of native frame F to WIDTH and HEIGHT
 pixels after we got a ConfigureNotify event.  */
 void
 xg_frame_resized (struct frame *f, int width, int height)
 {
+#ifndef HAVE_PGTK
+  if (f == last_resize_frame
+  && (width != last_resize_width
+	  || height != last_resize_height)
+  && last_resize_count <= 3)
+/* We did not get what we wanted, retry.  */
+{
+  if (CONSP (frame_size_history))
+	frame_size_history_extra
+	  (f, build_string ("xg_frame_resized, rejected"),
+	   FRAME_PIXEL_WIDTH (f), FRAME_PIXEL_HEIGHT (f), width, height,
+	   last_resize_width, last_resize_height);
+
+  gtk_window_resize (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)),
+			 last_resize_width, last_resize_height);
+
+  last_resize_count++;
+
+  return;
+}
+  else
+/* We either got what we asked for or lost the battle.  */
+{
+  last_resize_frame = NULL;
+  last_resize_height = -1;
+  last_resize_width = -1;
+  last_resize_count = 0;
+}
+#endif
   /* Ignore case where size of native rectangle didn't change.  */
   if (width != FRAME_PIXEL_WIDTH (f)
   || height != FRAME_PIXEL_HEIGHT (f)
@@ -1297,19 +1331,20 @@ xg_frame_set_char_size (struct frame *f, int width, int height)
   else
 {
 #ifndef HAVE_PGTK
+  last_resize_frame = f;
+  last_resize_height = outer_height;
+  last_resize_width = outer_width;
+  last_resize_count = 0;
+
   gtk_window_resize (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)),
 			 outer_width, outer_height);
 #else
   if (FRAME_GTK_OUTER_WIDGET (f))
-	{
-	  gtk_window_resize (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)),
-			 outer_width, outer_height);
-	}
+	gtk_window_resize (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)),
+			   outer_width, outer_height);
   else
-	{
-	  gtk_widget_set_size_request (FRAME_GTK_WIDGET (f),
-   outer_width, outer_height);
-	}
+	gtk_widget_set_size_request (FRAME_GTK_WIDGET (f),
+ outer_width, outer_height);
 #endif
   fullscreen = Qnil;
 }

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

[Bug reports for GNU Emacs, the Swiss army knife of text editors]

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.  Here is a quick
illustration (on my laptop (frame-char-width) returns 12 pixels):

;; As expected.
(with-temp-buffer
(insert "abcdef")
(car (buffer-text-pixel-size nil nil t)))
72

;; I suppose it is as expected because newline is not displayed.
(with-temp-buffer
(insert "\n")
(car (buffer-text-pixel-size nil nil t)))
0

;; ?
(with-temp-buffer
(insert "abcd\nef")
(car (buffer-text-pixel-size nil nil t)))
48


The above is the intended behavior, assuming that the default width of
the frame's characters is 12 in your case.  The maximum width of the
text "abcd\nef" is 4 characters ("abcd"), which are 12*4 = 48 pixels.
The part after the newline is only 2 characters, so it is narrower,
and does not affect the result.

IOW, buffer-text-pixel-size measures the 2D _dimensions_ of the text,
not is total width.


Thanks for clarifying.




The doc string of `buffer-text-pixel-size' mentions:

"Return size of whole text of BUFFER-OR-NAME in WINDOW."


It also says:

   The return value is a cons of the maximum pixel-width of any text
   line and the pixel-height of all the text lines of the buffer
   specified by BUFFER-OR-NAME.

Does the above explain the behavior you see?


Yes



This is not a bug.


So ,I expect that the last example will return 72px (6 x 12px) + 0px
for the newline.  But the result is 48px, which means that all the
text after the first newline is not counted.


Your expectations are incorrect, see above.


This also impacts "string-pixel-width" which is supposed to return
the pixel size of the passed string, not part of it:

(string-pixel-width "abcdef") => 72
(string-pixel-width "\n") => 0
(string-pixel-width "abcd\nef") => 48
(string-pixel-width "abcd\nef\ngh") => 48


Yes.  If you want the _total_ width of a string, remove the newlines
from it.

I think I understand the source of your confusion, so I have now
clarified these subtle points in the doc strings of
window-text-pixel-size, buffer-text-pixel-size, and
string-pixel-width.


Thanks you very much!




At least this limitation should be mentioned in the doc string?


I've now done so (and they are not limitations, but conscious design
decisions which have good reasons).


A possible fix for `string-pixel-width' could be to remove all
the newlines from the passed string before to call
`buffer-text-pixel-size'?  Something like this:


Thanks, but that would be the wrong thing.  If the caller wants a
total width, the caller should remover the newlines or measure each
substring separately and add the results.


I agree now that you clarified the behavior of `string-pixel-width' when
it is passed a string with embedded newlines.


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 it while experimenting, having passed to `string-pixel-width'
a buffer substring that spanned multiple lines.  And I thought it would be
good to, at least, clarify the behavior I observed ;-)

You can close this bug.

Many thanks again for your time and assistance!

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

[Eli Zaretskii]

> 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 it while experimenting, having passed to `string-pixel-width'
> a buffer substring that spanned multiple lines.  And I thought it would be
> good to, at least, clarify the behavior I observed ;-)
> 
> You can close this bug.

Thanks, closing.

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

[Bug reports for GNU Emacs, the Swiss army knife of text editors]

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 X.Org Foundation', version 11.0.12101013
System Description: OpenBSD computer 7.6 GENERIC.MP#311 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 e145eb83d5021b4bff36eae42a70f2ca3716fda2 Mon Sep 17 00:00:00 2001
From: Manuel Giraud 
Date: Mon, 9 Sep 2024 15:42:56 +0200
Subject: [PATCH] Simple typo in `clean-buffer-list'

* lisp/midnight.el (clean-buffer-list): `delay' is always an
integer here.
---
 lisp/midnight.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/midnight.el b/lisp/midnight.el
index bfa99d6a7a8..18a4e437f91 100644
--- a/lisp/midnight.el
+++ b/lisp/midnight.el
@@ -167,7 +167,7 @@ clean-buffer-list
   bn (buffer-name buf)
   delay (if bts (round (float-time (time-subtract tm bts))) 0)
   cbld (clean-buffer-list-delay bn))
-(message "[%s] `%s' [%s %d]" ts bn delay cbld)
+(message "[%s] `%s' [%d %d]" ts bn delay cbld)
 (unless (or (cl-find bn clean-buffer-list-kill-never-regexps
  :test (lambda (bn re)
  (if (functionp re)
-- 
2.46.0

-- 
Manuel Giraud

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

[Bug reports for GNU Emacs, the Swiss army knife of text editors]

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 size history of #
x_create_frame_1 (5), TS=80x25~>1280x875, NS=80x25~>1296x875,
IS=80x25~>1296x875, MS=32x70 IH IV
gui_figure_window_size (5), TS=1280x875~>1280x1260, TC=80x25~>80x36,
NS=1296x875~>1296x1260, IS=1296x875~>1296x1260, MS=32x70 IH IV
scroll-bar-width (3), NS=1296x1260~>1328x1260, IS=1296x1260~>1328x1260,
MS=160x175
scroll-bar-height (3), MS=160x175
x_create_frame_2 (0), MS=160x175
xg_frame_set_char_size, invisible, PS=1328x1260, XS=1328x1260, DS=1328x1260
xg_frame_set_char_size (5), MS=32x70 IH IV
x_make_frame_visible
MapNotify, not hidden & not iconified, PS=1328x1260, DS=1328x1260
ConfigureNotify, PS=1328x1260, XS=400x374, DS=1328x1260
xg_frame_resized, rejected, PS=1328x1260, XS=400x374, DS=664x630
tool-bar-lines (2), MS=160x175
xg_frame_set_char_size, visible, PS=1328x1260, XS=1328x1260, DS=1328x1260
ConfigureNotify, PS=1328x1260, XS=1328x1258, DS=1328x1260
xg_frame_resized, rejected, PS=1328x1260, XS=1328x1258, DS=664x671
set_window_configuration (4), MS=160x175 IH IV

Note that once more I retained the simple patch to frame.c to set
frame-size-history to (100).

-- 
https://rrt.sc3d.org

bug#73146: segfaults

[Torstein Sørnes]

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.0) of 2024-07-16 built on
 27527c2e06f843c0962737354e0b3cf7
System Description: Fedora Linux 40 (KDE Plasma)

Configured using:
 'configure --build=x86_64-redhat-linux-gnu
 --host=x86_64-redhat-linux-gnu --program-prefix=
 --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr
 --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc
 --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64
 --libexecdir=/usr/libexec --localstatedir=/var --runstatedir=/run
 --sharedstatedir=/var/lib --mandir=/usr/share/man
 --infodir=/usr/share/info --with-cairo --with-dbus --with-gif
 --with-gpm=no --with-harfbuzz --with-jpeg --with-json --with-modules
 --with-native-compilation=aot --with-pgtk --with-png --with-rsvg
 --with-sqlite3 --with-tiff --with-tree-sitter --with-webp --with-xpm
 --with-xwidgets build_alias=x86_64-redhat-linux-gnu
 host_alias=x86_64-redhat-linux-gnu CC=gcc 'CFLAGS=-DMAIL_USE_LOCKF -O2
 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches
 -pipe -Wall -Werror=format-security
 -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS
 -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64
 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
 -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer '
 LDFLAGS=-Wl,-z,relro
 PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig CXX=g++
 'CXXFLAGS=-O2 -flto=auto -ffat-lto-objects -fexceptions -g
 -grecord-gcc-switches -pipe -Wall -Werror=format-security
 -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS
 -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64
 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
 -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer ''

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY
PDUMPER PGTK PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XIM XWIDGETS GTK3 ZLIB

Important settings:
  value of $LC_TIME: nb_NO.UTF-8
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=none
  locale-coding-system: utf-8-unix

Major mode: DOOM v3.0.0-pre

Minor modes in effect:
  which-key-mode: t
  savehist-mode: t
  better-jumper-mode: t
  better-jumper-local-mode: t
  vertico-multiform-mode: t
  vertico-mode: t
  marginalia-mode: t
  evil-goggles-mode: t
  evil-escape-mode: t
  evil-snipe-override-mode: t
  evil-snipe-mode: t
  evil-snipe-override-local-mode: t
  evil-snipe-local-mode: t
  server-mode: t
  global-company-mode: t
  company-mode: t
  gcmh-mode: t
  global-hl-line-mode: t
  hl-line-mode: t
  winner-mode: t
  smartparens-global-mode: t
  ws-butler-global-mode: t
  undo-fu-session-global-mode: t
  undo-fu-mode: t
  global-flycheck-mode: t
  persp-mode: t
  doom-modeline-mode: t
  override-global-mode: t
  winum-mode: t
  evil-mode: t
  evil-local-mode: t
  +popup-mode: t
  general-override-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  window-divider-mode: t
  buffer-read-only: t
  size-indication-mode: t
  column-number-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/torstein/.config/emacs/.local/straight/build-29.4/straight/straight
hides
/home/torstein/.config/emacs/.local/straight/repos/straight.el/straight
/home/torstein/.config/emacs/.local/straight/build-29.4/straight/straight-x
hides
/home/torstein/.config/emacs/.local/straight/repos/straight.el/straight-x
/home/torstein/.config/emacs/.local/straight/build-29.4/straight/straight-ert-print-hack
hides
/home/torstein/.config/emacs/.local/straight/repos/straight.el/straight-ert-print-hack
/home/torstein/.config/emacs/.local/straight/build-29.4/transient/transient
hides /usr/share/emacs/29.4/lisp/transient
/home/torstein/.config/emacs/.local/straight/repos/straight.el/indent hides
/usr/share/emacs/29.4/lisp/indent
/home/torstein/.config/emacs/.local/straight/build-29.4/use-package/use-package
hides /usr/share/emacs/29.4/lisp/use-package/use-package
/home/torstein/.config/emacs/.local/straight/build-29.4/use-package/use-package-lint
hides /usr/share/emacs/29.4/lisp/use-package/use-package-lint
/home/torstein/.config/emacs/.local/straight/build-29.4/use-package/use-package-jump
hides /usr/share/emacs/29.

bug#70820: [PATCH] Editable grep buffers

[Visuwesh]

[புதன் ஆகஸ்ட் 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 52e4d82dd3f28065e5e3ea390c4629783bcf139d Mon Sep 17 00:00:00 2001
From: Visuwesh 
Date: Mon, 9 Sep 2024 20:08:04 +0530
Subject: [PATCH] Make the *grep* buffer editable

* lisp/progmodes/compile.el (compilation--update-markers):
Factor out function...
(compilation-next-error-function): from here.  Adjust to use
above.
* lisp/progmodes/grep.el (grep-edit--prepare-buffer)
(grep-edit-mode-map, grep-edit-mode-hook, grep-edit-mode)
(grep-change-to-grep-edit-mode, grep-edit-save-changes): Add new
grep-edit-mode to make the grep results editable like in
'occur-edit-mode' by using the 'occur' framework.
(grep-mode-map): Bind 'e' to the new command
'grep-change-to-grep-edit-mode'.
* doc/emacs/building.texi (Grep Searching): Update Info manual
to include the above command.
* etc/NEWS: Announce the change.  (bug#70820)
---
 doc/emacs/building.texi   | 10 +
 etc/NEWS  |  9 
 lisp/progmodes/compile.el | 95 +--
 lisp/progmodes/grep.el| 86 +++
 4 files changed, 156 insertions(+), 44 deletions(-)

diff --git a/doc/emacs/building.texi b/doc/emacs/building.texi
index bb03d8cf325..4b2f1ed0649 100644
--- a/doc/emacs/building.texi
+++ b/doc/emacs/building.texi
@@ -528,6 +528,16 @@ Grep Searching
 shell commands, customize the option @code{grep-find-abbreviate} to a
 @code{nil} value.
 
+@findex grep-change-to-grep-edit-mode
+@cindex Grep Edit mode
+@cindex mode, Grep Edit
+  Typing @kbd{e} in the @file{*grep*} buffer makes the buffer writiable
+and enters the Grep Edit mode.  Similar to Occur Edit mode (@pxref{Other
+Repeating Search}), you can edit the matching lines reported by
+@code{grep} and have those changes reflected in the buffer visiting the
+originating file.  Type @kbd{C-c C-c} to leave the Grep Edit mode and
+return to the Grep mode.
+
 @node Flymake
 @section Finding Syntax Errors On The Fly
 @cindex checking syntax
diff --git a/etc/NEWS b/etc/NEWS
index c6f8b0062e4..24b43108ecb 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -290,6 +290,15 @@ the built-in Web server.  Interactively, when invoked with a prefix
 argument, 'php-ts-mode-run-php-webserver' prompts for the config file as
 well as for other connection parameters.
 
+** Grep
+

+*** Grep results can be edited to reflect changes in the originating file.
+Like Occur Edit mode, typing 'e' in the '*grep*' buffer will now make
+the 'grep' results editable.  The edits will be reflected in the buffer
+visiting the originating file.  Typing 'C-c C-c' will leave the Grep
+Edit mode.
+
 
 * New Modes and Packages in Emacs 31.1
 
diff --git a/lisp/progmodes/compile.el b/lisp/progmodes/compile.el
index d2e74aa44a6..a78ac1b6462 100644
--- a/lisp/progmodes/compile.el
+++ b/lisp/progmodes/compile.el
@@ -2855,6 +2855,53 @@ compilation-find-buffer
   (current-buffer)
 (next-error-find-buffer avoid-current 'compilation-buffer-internal-p)))
 
+(defun compilation--update-markers (loc marker screen-columns first-column)
+  "Update markers in LOC, and set MARKER to location pointed by LOC.
+SCREEN-COLUMNS and FIRST-COLUMN are the value of
+`compilation-error-screen-columns' and `compilation-first-column' to use
+if they are not set buffer-locally in the target buffer."
+  (with-current-buffer
+  (if (bufferp (caar (compilation--loc->file-struct loc)))
+  (caar (compilation--loc->file-struct loc))
+(apply #'compilation-find-file
+   marker
+   (caar (compilation--loc->file-struct loc))
+   (cadr (car (compilation--loc->file-struct loc)))
+   (compilation--file-struct->formats
+(compilation--loc->file-struct loc
+(let ((screen-columns
+   ;; Obey the compilation-error-screen-columns of the target
+   ;; buffer if its major mode set it buffer-locally.
+   (if (local-variable-p 'compilation-error-screen-columns)
+   compilation-error-screen-columns screen-columns))
+  (compilation-first-column
+   (if (local-variable-p 'compilation-first-column)
+   compilation-first-column first-column))
+  (last 1))
+  (save-restriction
+(widen)
+(goto-char (point-min))
+;; Treat file's found lines in forward order, 1 by 1.
+(dolist (line (reverse (cddr (compilation--loc->file-struct loc
+  (when (car line) ; else this is a filename without a line#
+(compilation-beginning-of-line (- (car line) last -1))
+(setq last (car line)))
+  ;; Treat line's found columns and store/update a marker for each.
+  (dolist (col (cdr line))
+(if (compilation--loc->col col)
+(if 

bug#73146: segfaults

[Eli Zaretskii]

> 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 is bug#71744, which is already fixed for what
will become Emacs 30.1.

bug#72829: describe-function NEWS* scraper override

[Steve Purcell]

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 
builds makes this straightforward to automate.

Not all features shipped with an Emacs build can be loaded in that build, 
though, because some rely on native or optional features, e.g. Windows or 
Treesitter. As such, it’s hard to get an authoritative list of all the known 
symbols.

In practice, the lists I’ve generated have been good enough for package-lint, 
and I often use the `package-lint-describe-symbol-history` command when I’m 
curious about a given symbol.

-Steve

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

[Bug reports for GNU Emacs, the Swiss army knife of text editors]

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 fontified t
> invisible dired-hide-details-link))
>
> And indeed, after going to the end of the Dired buffer
> the last file gets an additional property `dired-symlink-filename'
> used by Isearch/Replace.

So, the properties we use are of different types: some are already
attached by `dired-insert-set-properties', others later by font-lock
(see `dired-font-lock-keywords').  AFAIR this is because some tests are
more expensive than others (e.g. the test whether a link is broken) and
are intentionally delayed.

Would something like this be good?

From c5ef8c8db7d8b2ab03998a0f3f2a1b820ff24e2a Mon Sep 17 00:00:00 2001
From: Michael Heerdegen 
Date: Mon, 9 Sep 2024 16:46:13 +0200
Subject: [PATCH] WIP: Bug#73018

---
 lisp/dired-aux.el | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/lisp/dired-aux.el b/lisp/dired-aux.el
index d79ec342435..77dde7147bc 100644
--- a/lisp/dired-aux.el
+++ b/lisp/dired-aux.el
@@ -3740,8 +3740,12 @@ dired-isearch-search-filenames
 The returned function narrows the search to match the search string
 only as part of a file name enclosed by the text property `dired-filename'.
 It's intended to override the default search function."
-  (isearch-search-fun-in-text-property
-   (funcall orig-fun) '(dired-filename dired-symlink-filename)))
+  (let ((search-fun
+ (isearch-search-fun-in-text-property
+  (funcall orig-fun) '(dired-filename dired-symlink-filename
+(lambda (&rest args)
+  (font-lock-ensure)
+  (apply search-fun args

 ;;;###autoload
 (defun dired-isearch-filenames ()
--
2.39.2


A related question is whether everybody always wants to search in
symlink targets when isearching file names in dired... I don't.  Would
it be worth to add an option for that?  Currently the properties are
just hardcoded.

Then, in the above patch we could make the `font-lock-ensure' call
depend on the value of that option.


> 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 nil nil nil nil nil nil nil)
>   query-replace-regexp("7" "!" nil nil nil nil nil)
>   funcall-interactively(query-replace-regexp "7" "!" nil nil nil nil nil)
>   command-execute(query-replace-regexp)

Do I interpret the code in replace_match correctly: this error doesn't
even mean the match data has been clobbered - only that modification
hooks called searching functions?  I don't know what the referenced
search_regs.num_regs exactly contains.  But we already seem to ensure
not to clobber match data.


Michael.

bug#73098: setopt float warning unexpected

[Bug reports for GNU Emacs, the Swiss army knife of text editors]

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
> relaxed to the equivalent of #'= for these simple cases.

How about adding an option letting the user disable the type checking of
some options?


Michael.

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

[Bug reports for GNU Emacs, the Swiss army knife of text editors]

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 branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101013
System Description: OpenBSD computer 7.6 GENERIC.MP#311 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 8f3f61105817a05218e0fde05e1dd0748579b17a Mon Sep 17 00:00:00 2001
From: Manuel Giraud 
Date: Mon, 9 Sep 2024 17:16:32 +0200
Subject: [PATCH] Human readable last display time of killed buffer

* lisp/midnight.el (clean-buffer-list): Upon killing a buffer,
add a human readable last displayed information.
---
 lisp/midnight.el | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lisp/midnight.el b/lisp/midnight.el
index bfa99d6a7a8..fc1e08f2189 100644
--- a/lisp/midnight.el
+++ b/lisp/midnight.el
@@ -179,7 +179,8 @@ clean-buffer-list
 (and (buffer-file-name buf) (buffer-modified-p buf))
 (get-buffer-window buf 'visible)
 (< delay cbld))
-  (message "[%s] killing `%s'" ts bn)
+  (message "[%s] killing `%s' (last displayed %s ago)" ts bn
+   (format-seconds "%Y, %D, %H, %M, %z%S" delay))
   (kill-buffer buf))
 
 ;;; midnight hook
-- 
2.46.0

-- 
Manuel Giraud

bug#73098: setopt float warning unexpected

[Eli Zaretskii]

> 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 is not a request to change the elisp type system, it is a
> > request to consider if setopt's / customize internals should be
> > relaxed to the equivalent of #'= for these simple cases.
> 
> 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'?

And I'm also not sure we want this: presumably, if the defcustom's
author specified a type, they meant it, no?

Which is why I asked for opinions (but for now got only yours).

Stefan, WDYT?

bug#73098: setopt float warning unexpected

[Ship Mints]

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 know this all too well).

On Mon, Sep 9, 2024 at 11:28 AM Eli Zaretskii  wrote:

> > 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 is not a request to change the elisp type system, it is a
> > > request to consider if setopt's / customize internals should be
> > > relaxed to the equivalent of #'= for these simple cases.
> >
> > 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'?
>
> And I'm also not sure we want this: presumably, if the defcustom's
> author specified a type, they meant it, no?
>
> Which is why I asked for opinions (but for now got only yours).
>
> Stefan, WDYT?
>

bug#73098: setopt float warning unexpected

[Bug reports for GNU Emacs, the Swiss army knife of text editors]

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 names.  The user
could then add those options with incorrect type specs.  And for those
specified options Emacs would skip type checking entirely.

I _don't_ think melting types in either way would be a good idea.


Michael.

bug#73098: setopt float warning unexpected

[Bug reports for GNU Emacs, the Swiss army knife of text editors]

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
> customize system--this group must know this all too well).

Dunno 'bout the name, but the idea sounds ok to me.


Michael.

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

[Bug reports for GNU Emacs, the Swiss army knife of text editors]

> 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 (2), MS=160x175
> xg_frame_set_char_size, visible, PS=1328x1260, XS=1328x1260, DS=1328x1260
> ConfigureNotify, PS=1328x1260, XS=1328x1258, DS=1328x1260
> xg_frame_resized, rejected, PS=1328x1260, XS=1328x1258, DS=664x671
> set_window_configuration (4), MS=160x175 IH IV
>
> Note that once more I retained the simple patch to frame.c to set
> frame-size-history to (100).

Setting 'frame-size-history' to '(100), doing C-x 5 2 and evaluating
'frame--size-history' should be enough.  The frame.c change is needed
only for the initial frame because at that time no Lisp was evaluated.

The result is not yet what I hoped for.  We reject two ConfigureNotify
events but the ensuing xg_frame_set_char_size calls do not get us a
ConfigureNotify we'd accept.  IIUC the final height may be off by two
pixels.  What does (frame-text-height) return for the first and the
second frame?  Also I hope you didn't get the GTK assertion failure.
And how does removing the menubar behave?

Now something completely different.  A couple of years ago I noticed
that our size hints calculations are fundamentally wrong.  I tried to
fix them and I attach some parts of that fix together with the previous
changes I proposed.  Attached as size_hints.diff.  If the patch does not
apply, complain.  I edited it by hand to exclude other changes I made
and I might have made mistakes.  Again I'm interested in the history of
the second frame.

martindiff --git a/src/gtkutil.c b/src/gtkutil.c
index d57627f152f..7a5cf8e32e1 100644
--- a/src/gtkutil.c
+++ b/src/gtkutil.c
@@ -1129,11 +1129,45 @@ xg_set_geometry (struct frame *f)
 }
 }
 
+static struct frame *last_resize_frame = NULL;
+static int last_resize_height = -1;
+static int last_resize_width = -1;
+static int last_resize_count = 0;
+
 /** Function to handle resize of native frame F to WIDTH and HEIGHT
 pixels after we got a ConfigureNotify event.  */
 void
 xg_frame_resized (struct frame *f, int width, int height)
 {
+#ifndef HAVE_PGTK
+  if (f == last_resize_frame
+  && (width != last_resize_width
+	  || height != last_resize_height)
+  && last_resize_count <= 3)
+/* We did not get what we wanted, retry.  */
+{
+  if (CONSP (frame_size_history))
+	frame_size_history_extra
+	  (f, build_string ("xg_frame_resized, rejected"),
+	   FRAME_PIXEL_WIDTH (f), FRAME_PIXEL_HEIGHT (f), width, height,
+	   last_resize_width, last_resize_height);
+
+  gtk_window_resize (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)),
+			 last_resize_width, last_resize_height);
+
+  last_resize_count++;
+
+  return;
+}
+  else
+/* We either got what we asked for or lost the battle.  */
+{
+  last_resize_frame = NULL;
+  last_resize_height = -1;
+  last_resize_width = -1;
+  last_resize_count = 0;
+}
+#endif
   /* Ignore case where size of native rectangle didn't change.  */
   if (width != FRAME_PIXEL_WIDTH (f)
   || height != FRAME_PIXEL_HEIGHT (f)
@@ -1199,7 +1233,7 @@ xg_frame_set_char_size (struct frame *f, int width, int height)
   outer_height /= xg_get_scale (f);
   outer_width /= xg_get_scale (f);
 
-  xg_wm_set_size_hint (f, 0, 0);
+  xg_wm_set_size_hint (f, 0, 0, width, height);
 
   /* Resize the top level widget so rows and columns remain constant.
 
@@ -1297,19 +1331,20 @@ xg_frame_set_char_size (struct frame *f, int width, int height)
   else
 {
 #ifndef HAVE_PGTK
+  last_resize_frame = f;
+  last_resize_height = outer_height;
+  last_resize_width = outer_width;
+  last_resize_count = 0;
+
   gtk_window_resize (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)),
 			 outer_width, outer_height);
 #else
   if (FRAME_GTK_OUTER_WIDGET (f))
-	{
-	  gtk_window_resize (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)),
-			 outer_width, outer_height);
-	}
+	gtk_window_resize (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)),
+			   outer_width, outer_height);
   else
-	{
-	  gtk_widget_set_size_request (FRAME_GTK_WIDGET (f),
-   outer_width, outer_height);
-	}
+	gtk_widget_set_size_request (FRAME_GTK_WIDGET (f),
+ outer_width, outer_height);
 #endif
   fullscreen = Qnil;
 }
@@ -1910,14 +1945,16 @@ xg_free_frame_widgets (struct frame *f)
 }
 }
 
-/* Set the normal size hints for the window manager, for frame F.
-   FLAGS is the flags word to use--or 0 meaning preserve the flags
-   that the window now has.
-   If USER_POSITION, set the User Position
-   flag (this is useful when FLAGS is 0).  */
+/** Set the normal size hints for the window manager, for frame F.
+FLAGS is the flags word to use--or 0 meaning preserve the flags
+that the window now has.
+If USER_POSITION, set the User Position
+flag (this is useful 

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

[Juri Linkov]

>> >> 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, 
>> >> int y)
>> >>help_echo_object = help_echo_window = Qnil;
>> >>help_echo_pos = -1;
>> >>help_echo_string = AREF (f->tab_bar_items, prop_idx + 
>> >> TAB_BAR_ITEM_HELP);
>> >> -  if (NILP (help_echo_string))
>> >> -help_echo_string = AREF (f->tab_bar_items, prop_idx + 
>> >> TAB_BAR_ITEM_CAPTION);
>> >>  }
>> >>
>> >>  #endif /* HAVE_WINDOW_SYSTEM */
>> >
>> > Do you remember why was this introduced?
>> 
>> It was copy-pasted from tool-bar code.
>
> 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 popped up when the mouse
> is between buttons.  Do you understand why this happens?

When there is no TAB_BAR_ITEM_HELP, then it falls back to TAB_BAR_ITEM_CAPTION.
But the tab bar doesn't need tooltips on spaces.  So this patch is needed.

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

[Juri Linkov]

> 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 orig-fun) '(dired-filename dired-symlink-filename
> +(lambda (&rest args)
> +  (font-lock-ensure)
> +  (apply search-fun args

This will call 'font-lock-ensure' for every search hit?
Wouldn't it be better to call 'font-lock-ensure' only once
at the beginning of the search?

> A related question is whether everybody always wants to search in
> symlink targets when isearching file names in dired... I don't.  Would
> it be worth to add an option for that?  Currently the properties are
> just hardcoded.
>
> Then, in the above patch we could make the `font-lock-ensure' call
> depend on the value of that option.

Maybe not an option, but just a simple variable?

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

[Juri Linkov]

>> 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 nil nil nil nil nil nil nil)
>>   query-replace-regexp("7" "!" nil nil nil nil nil)
>>   funcall-interactively(query-replace-regexp "7" "!" nil nil nil nil nil)
>>   command-execute(query-replace-regexp)
>
> Do I interpret the code in replace_match correctly: this error doesn't
> even mean the match data has been clobbered - only that modification
> hooks called searching functions?  I don't know what the referenced
> search_regs.num_regs exactly contains.  But we already seem to ensure
> not to clobber match data.

It fails in emacs-30, but not in emacs-29.
So this is a regression.

bug#73098: setopt float warning unexpected

[Eli Zaretskii]

> 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 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 names.  The user
> could then add those options with incorrect type specs.  And for those
> specified options Emacs would skip type checking entirely.

Thanks, but this sounds like overkill to me.

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

[Eli Zaretskii]

> 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 tab-bar button has a valid, non-nil
> > tooltip, so the problem is with the tooltips popped up when the mouse
> > is between buttons.  Do you understand why this happens?
> 
> When there is no TAB_BAR_ITEM_HELP, then it falls back to 
> TAB_BAR_ITEM_CAPTION.
> But the tab bar doesn't need tooltips on spaces.  So this patch is needed.

Fine, then let's install it, and thanks.

bug#73098: setopt float warning unexpected

[Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

[Bug reports for GNU Emacs, the Swiss army knife of text editors]

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_char_size calls do not get us a
> ConfigureNotify we'd accept.  IIUC the final height may be off by two
> pixels.  What does (frame-text-height) return for the first and the
> second frame?

1260 for both.


>   Also I hope you didn't get the GTK assertion failure.
>

Indeed, I do not.


> And how does removing the menubar behave?
>

When I do M-x menu-bar-mode the first time it has no effect, as Emacs
considers the menu bar to be currently enabled, so it disables it.

After that, toggling the menu bar works as expected, and the window gets
taller each time it is enabled, and shorter (by the same amount) each time
it is disabled.

Now something completely different.  A couple of years ago I noticed
> that our size hints calculations are fundamentally wrong.  I tried to
> fix them and I attach some parts of that fix together with the previous
> changes I proposed.  Attached as size_hints.diff.  If the patch does not
> apply, complain.  I edited it by hand to exclude other changes I made
> and I might have made mistakes.  Again I'm interested in the history of
> the second frame.
>

OK, running with just this patch (which applies fine), and doing the
history test, the history of the second frame is:

Frame size history of #
x_create_frame_1 (5), TS=80x25~>1280x875, NS=80x25~>1296x875,
IS=80x25~>1296x875, MS=32x70 IH IV
gui_figure_window_size (5), TS=1280x875~>1280x1260, TC=80x25~>80x36,
NS=1296x875~>1296x1260, IS=1296x875~>1296x1260, MS=32x70 IH IV
scroll-bar-width (3), NS=1296x1260~>1328x1260, IS=1296x1260~>1328x1260,
MS=160x175
scroll-bar-height (3), MS=160x175
x_create_frame_2 (0), MS=160x175
xg_frame_set_char_size, invisible, PS=1328x1260, XS=1328x1260, DS=1328x1260
xg_frame_set_char_size (5), MS=32x70 IH IV
x_make_frame_visible
MapNotify, not hidden & not iconified, PS=1328x1260, DS=1328x1260
ConfigureNotify, PS=1328x1260, XS=400x376, DS=1328x1260
xg_frame_resized, rejected, PS=1328x1260, XS=400x376, DS=664x630
menu-bar-lines (2), MS=160x175
xg_frame_set_char_size, visible, PS=1328x1260, XS=1328x1260, DS=1328x1260
ConfigureNotify, PS=1328x1260, XS=1328x1260, DS=1328x1260
xg_frame_resized, rejected, PS=1328x1260, XS=1328x1260, DS=664x655
tool-bar-lines (2), MS=160x175
xg_frame_set_char_size, visible, PS=1328x1260, XS=1328x1260, DS=1328x1260
ConfigureNotify, PS=1328x1260, XS=1328x1260, DS=1328x1260
xg_frame_resized, rejected, PS=1328x1260, XS=1328x1260, DS=664x696
set_window_configuration (4), MS=160x175 IH IV

The second window is the same size as the first.

-- 
https://rrt.sc3d.org

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

[Sean Whitton]

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

[Bug reports for GNU Emacs, the Swiss army knife of text editors]

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-text-property
> > +  (funcall orig-fun) '(dired-filename dired-symlink-filename
> > +(lambda (&rest args)
> > +  (font-lock-ensure)
> > +  (apply search-fun args
>
> This will call 'font-lock-ensure' for every search hit?

Right - this is the wrong place to add it.

The idea was to make the search function itself know that it has to care
about font-locking.  We could still save the information in the function
by using an oclosure, though.

Michael.

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

[Juri Linkov]

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 popped up when the mouse
>> > is between buttons.  Do you understand why this happens?
>> 
>> When there is no TAB_BAR_ITEM_HELP, then it falls back to 
>> TAB_BAR_ITEM_CAPTION.
>> But the tab bar doesn't need tooltips on spaces.  So this patch is needed.
>
> Fine, then let's install it, and thanks.

So now installed on master.

bug#73098: setopt float warning unexpected

[Eli Zaretskii]

> 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 should make up our minds: either we enforce :type in setopt
or we don't.

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

[Eli Zaretskii]

> 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, but there's no rush.

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

[Philip Kaludercic]

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 0f19dadb75a01873cb3f40a6addd825e63c266ce 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   |  7 +++
 lisp/simple.el | 41 ++---
 2 files changed, 41 insertions(+), 7 deletions(-)

diff --git a/etc/NEWS b/etc/NEWS
index add438e8b6a..8cde2c294a9 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -129,6 +129,13 @@ Unix-words are words separated by whitespace regardless of the buffer's
 syntax table.  In a Unix terminal or shell, C-w kills by Unix-word.
 The new commands 'unix-word-rubout' and 'unix-filename-rubout' allow
 you to bind keys to operate more similarly to the terminal.
+
+---
+** New user option 'kill-word-dwim'.
+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 bbb13c1b471..d1be33ce87d 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -5817,6 +5817,19 @@ 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), the behaviour of `kill-region' stays the same.
+If set to `emacs-word', then kill 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 like with
+`unix-word-rubout'."
+  :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 "31.1")
+
 (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 +5856,35 @@ 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-append'.
   (interactive (progn
  (let ((beg (mark))
(end (point)))
-   (unless (and beg end)
+   (cond
+((and kill-region-dwim (not (use-region-p)))
+ (list beg end kill-region-dwim))
+((not (or beg end))
  (user-error "The mark is not set now, so there is no region"))
-   (list beg end 'region
+((list beg end 'region))
+
   (condition-case nil
-  (let ((string (if region
-(funcall region-extract-function 'delete)
-  (filter-buffer-substring beg end 'delete
+  (let ((string (cond
+ ((memq region '(unix-word emacs-word))
+  (let ((end (point)))
+(save-excursion
+  (if (eq region 'emacs-word)
+  (forward-word -1)
+(forward-unix-word -1))
+  (filter-buffer-substring (point) end 'delete
+ (region
+  (funcall region-extract-function 'delete))
+ ((filter-buffer-substring beg end 'delete)
 	(when string			;STRING is nil if BEG = END
 	  ;; Add that string to the kill ring, one way or another.
 	  (if (eq last-command 'kill-region)
-- 
2.45.2



-- 
Philip Kaludercic on siskin

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

[Sean Whitton]

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 v4?
>
> When I have time.

Sorry, thought you might have missed it.

-- 
Sean Whitton

bug#73098: setopt float warning unexpected

[Bug reports for GNU Emacs, the Swiss army knife of text editors]

> 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 can use
something lower-level than `setopt`, while you argue with the maintainer
to try and get them to change their type.

IMO, the whole point of `setopt` is to check the value against the type.


Stefan

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

[Daniel Bastos]

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 settings so that I can download the set of messages
from both versions 27.1 e 29.3 to see if I can compare.  What I'm very
puzzled with is that I would not have thought that this is a Gnus
problem.  It seemed clear to me that the POP3 server was reporting
incorrect results.  Since I know very little about POP3 servers,
perhaps there's more to the story than I can see.  If 29.3 solves the
problem, I'm going to upgrade.  Sorry about the delay and thanks for
your assistance!  I'll write again soon.

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

[Dmitry Gutov]

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 many cases that would be TRT,
although `C-u M-.` seems to regress (seems like we *would* want to query
eagerly there).


I don't understand why the obvious way of asking the user whether they
would like to generate the tags table is not the solution here.  What
did I miss?


I don't know if it's obvious, given that the optimal scenario at the
beginning of the report describes

... allow the backend to never query a TAGS file


But what do you expect from a backend that depends on TAGS to do when
TAGS is not there?  You yourself just noticed the regression.  Why
would we want that?


I'm thinking of the xref-find-references case - where the scanner 
doesn't depend on the tags table being available. Just the identifier 
completion step.


Perhaps Philip had other some situations in mind, too.


AFAIU, the problem here is that the backend can avoid querying when
the TAGS file exists.  But what do you expect it to do when it does
_not_ exist? > We have the regeneration feature now, so I suggested to
ask the user whether to regenerate the file, after which it could be
read without any further prompts.


We have an existing way to enable etags-regen-mode. And it's a global 
mode, so it's not just an issue of using it that one time - the naive 
solution will make stay on until the end of the session.


Also, if the tags file is not loaded, we're not quite sure whether the 
user wants an auto-generated file, or an existing one.



As it is, we already have a hint of the user preference from the fact
that they have visited a TAGS file already (or not), or enabled
etags-regen-mode (or not). It's not ironclad, but we could rely on these
indicators to decide.


Then regenerate TAGS without asking, if you think it's reasonable.
But letting the backend continue without TAGS is not a reasonable
solution, IMO.


How do you feel about etags-regen-mode being on by default in some next 
Emacs release? It shouldn't conflict with the manual invocations of 'M-x 
visit-tags-file' - and of course if any cases come up we'll work on 
fixing those.

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

[Dmitry Gutov]

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.txt and with your last redisplay-skip-initial-frame patch
I get failure2.txt.

I've produced these files with

make -C test eglot-tests SELECTOR=\"rust-completion\" 2>&1 | tee failure1.txt


So it's reproducible. Great!

Could someone look into the segfault? The repro steps are simple:

1) apply the patch above,
2) run 'make -C test eglot-tests' or the longer command above which
executes just one test from that file.

The backtrace that I managed to generate is attached.


Thanks.  Please try the patch below.


Thanks! The patch takes care of the crash AFAICS (no core dump now), but 
alas not of the original test failure.



P.S. I'm not at all sure this is the last segfault you will see
because you are playing with fire: you are not supposed to reset
redisplay-skip-initial-frame to nil in batch-mode tests that test
redisplay-related features!


Isn't that the main/only purpose of this variable?

That's how the docstring reads to me, and it's also seems why 
minibuffer-test.el uses it.


In any case, this var is neither necessary nor sufficient (see my next 
email), so sorry if that wasted you time. The fix might still be worth 
installing, though.



diff --git a/src/xdisp.c b/src/xdisp.c
index bf7d84c..a1319e7 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -22089,7 +22089,8 @@ #define GIVE_UP(X) return 0
  
/* Window must either use window-based redisplay or be full width.  */

if (!FRAME_WINDOW_P (f)
-  && (!FRAME_LINE_INS_DEL_OK (f)
+  && (FRAME_INITIAL_P (f)
+ || !FRAME_LINE_INS_DEL_OK (f)
  || !WINDOW_FULL_WIDTH_P (w)))
  GIVE_UP (4);
  

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

[Dmitry Gutov]

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] contents of `nil':
[eglot-tests] Killing (main.rs), wiping /tmp/eglot--fixture-XCmCqo
Test eglot-test-rust-completion-exit-function backtrace:
   set-buffer(#)  eglot--call-with-fixture((("cmpl-project" ("main.rs" . 
"fn test() ->Test eglot-test-rust-completion-exit-function condition:
 (error "Selecting deleted buffer")


This error comes from eglot--call-with-fixture, where one of the last

  (with-current-buffer buffer (buffer-string))

calls results in "Selecting deleted buffer" error. I'm not sure where 
that comes from (for the duration of the log the contents of stdout 
buffer are printed twice, and stderr and events just once -- somehow 
there are two elements inside the 'new-servers' var).


That hid the original problem, which was just that in the bare session 
yasnippet is not available. Not sure what to do about it - 
monkeypatching a replacements does not seem wise - but if we adjust the 
"expected" at the end not to have parens, then the test finally passes. 
It will fail interactively, though, when yasnippet is installed.


I've pushed that fix as 
https://git.savannah.gnu.org/cgit/emacs.git/commit/?h=emacs-30&id=818c0cc9a51a1d678749404cdacdf640d6f32d6e 
now.


It makes that test more similar to 
'eglot-test-try-completion-inside-symbol', but testing rust-analyzer 
separately still seems like a plus.

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

[Sean McAfee]

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?
>

Since the current behavior is explicitly documented in the code, I suppose
that settles it.  I really can't imagine a good use case for it, though.
But then again, until I filed this ticket, I didn't know that
append-next-kill could sometimes prepend instead of append.  It seems a
small miracle that I've never stumbled across the prepending function by
accident.

Perhaps kill-whole-line does technically kill both forwards and backwards,
but to me it's always been just a welcome shortcut for the classic Emacs
idiom C-a C-k C-k.  And the name kill-whole-line certainly implies to me
that the line is killed as a single unit, not killed in two steps in
opposite directions.  If the current behavior is to stay, then I think it
could stand to be called out explicitly in the documentation for
kill-whole-line.

Anyway!  Although I'd prefer to see what I'd consider to be the more
sensible behavior built into Emacs, I can achieve it on my own by just
rebinding C-S-backspace to a command that moves to the beginning of the
line before calling kill-whole-line.

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

[Casey Banner]

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 because gdi was being used, and indeed using
describe-char on any character shows me a font starting with
`gdi:`, indicating the uniscribe or harfbuzz are not being used.

This is not the case on the emacs-29 branch, where I see `uniscribe:`
instead (and the symbols render correctly). I was not able to get
harfbuzz to load on that branch, which is why I was trying emacs-30
to see if something was different there.

To investigate this, I first used procmon to look at the syscalls to
see if anything was trying to load libharfbuzz-0.dll, and I did see it
in the trace I took, however the callstack was an OS callstack, and not
from where I expected (src\w32uniscribe.c:syms_of_w32uniscribe_for_pdumber).

I rebuilt with debug symbols, and set a breakpoint in that function - it
was called once, but `initialized` was false so the LoadLibrary calls
never ran. I'm not too familiar with how pdumper works, or the emacs
source in general, so I'm not sure what the actual root cause is here.

I did a bit more debugging to see when `initialized` was set to true,
and it does get set later during initialization. I noted that I do not have
a .pdmp file
in my installation direction, which it seems to be trying to load during
startup.

One more piece of information: attempting to yank any text results in the
error:

`Coding system is invalid or doesn't have an eol variant for dos line ends:
nil`

This error occurs when starting with -Q and attempting to yank any text. If
I
call `(set-selection-coding-system 'utf-16-le)`, it resolves the issue.

However, I didn't have to do this in emacs-29, so this makes me think
something has possibly broken with init on Windows, since I believe this
is not supposed to be nil by default?

I'm happy to assist by providing any additional info if needed!

Thanks,
Casey

In GNU Emacs 30.0.90 (build 1, x86_64-w64-mingw32) of 2024-09-09 built
 on DESKTOP-EK25TL1
Windowing system distributor 'Microsoft Corp.', version 10.0.19045
System Description: Microsoft Windows 10 Pro (v10.0.2009.19045.4780)

Configured using:
 'configure -prefix=/e/dev/emacs-src --without-dbus --without-pop
 --with-native-compilation --with-wide-int --without-compress-install
 --with-json --with-tree-sitter --without-imagemagick 'CFLAGS=-O2
 -mtune=native -march=native -fomit-frame-pointer -ftree-vectorize
 -Wno-error=implicit-function-declaration -pipe -g'
 PKG_CONFIG_PATH=/mingw64/lib/pkgconfig:/mingw64/share/pkgconfig'

Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG LCMS2 LIBXML2 MODULES NATIVE_COMP
NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XPM ZLIB

(NATIVE_COMP present but libgccjit not available)

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: cp1252

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  minibuffer-regexp-mode: t
  buffer-read-only: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search time-date subr-x mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils rmc iso-transl tooltip cus-start cconv eldoc paren
electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
touch-screen dos-w32 ls-lisp disp-table term/w32-win w32-win w32-vars
term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode lisp-mode prog-mode register
page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer nadvice seq simple cl-generic indonesian philippine
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads w32notify w32 lcm

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

[Bug reports for GNU Emacs, the Swiss army knife of text editors]

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 reaching out because I’ve hit a wall after spending many hours
debugging what seemed like a straightforward issue but turned out to
be a rabbit hole.  I’ve been working on customizing `org-agenda'
export to PDF and initially thought my problem was related to
`ox-texinfo'.  I spent half the night tweaking my Emacs
configuration, digging through documentation, and adjusting settings
in hopes of resolving the issue.  I went down a lot of wrong paths
before realizing that `org-store-agenda-views' doesn't actually call
`ox-texinfo'.  That was my first mistake - not diving into the source
code earlier.

Turns out, the function calls `org-agenda-write', which in turn
executes something entirely different.  Relevant part of
org-agenda.el:

--8<---cut here---start->8---
(require 'ps-print)
(ps-print-buffer-with-faces
  (concat (file-name-sans-extension file) ".ps"))
(call-process "ps2pdf" nil nil nil
  (expand-file-name
(concat (file-name-sans-extension file) ".ps"))
  (expand-file-name file))
(delete-file (concat (file-name-sans-extension file) ".ps"))
(message "PDF written to %s" file)
--8<---cut here---end--->8---

So, after realizing this, I thought I could fix the issue by tweaking
`ps-print' and `ps2pdf' settings.  I’ve tried adjusting my
`org-agenda-exporter-settings' multiple times, setting various font
families and print headers, and I’ve seen some changes reflected in
the output.  For instance, I can see that the header is removed, and
the font face in the PDF actually changes when I tweak
`ps-font-family'.  But no matter what I try, Cyrillic characters
still show up as question marks or garbled symbols.

Here’s a snippet of my best try:

--8<---cut here---start->8---
(setq org-agenda-exporter-settings
  '((ps-multibyte-buffer 'bdf-font-except-latin)
(ps-print-header nil)
(ps-print-color-p 'black-white)
(ps-font-family 'Helvetica)
(htmlize-output-type 'css)))
--8<---cut here---end--->8---

I’ve tried changing `ps-multibyte-buffer' to `bdf-font-except-latin',
thinking it would handle non-Latin characters, but that hasn’t
worked.  I’ve messed around with various `ps-font-family' values, tried
specifying paths to BDF fonts, and set up `bdf-directory-list', but
still no dice.  I’ve also been battling with `ps2pdf', which seems to
completely ignore the fonts I’m trying to set up, reverting to
something that just doesn’t support Cyrillic.

As far as I can tell, `ps-mule' expects me to install BDF fonts and set
the path to them in `bdf-directory-list'.  If this is indeed the reason
why I’m seeing garbled text instead of proper characters, then my
situation might be even worse.  The workstation I’m working on is
running macOS, and as far as I know, there's no native support for
pcf/bdf fonts in macOS.  At least, I've never heard of anyone using
these on macOS.  So, what started as a simple task to add a weekly
report generation function is turning into a bottomless rabbit hole,
and I can’t help but feel like I’m missing something fundamental
here.

Running pdffonts (a part of the poppler package on macOS) on the
generated document gives me the following output:

--8<---cut here---start->8---

nametype   encoding   emb sub uni object ID
--- -- -- --- --- --- -
YJXYOF+HelveticaType 1CWinAnsiyes yes no   7  0

--8<---cut here---end--->8---

>From what I understand, WinAnsi is essentially cp1252.  I have
absolutely nothing related to cp1252 in my Emacs config.  Could this
be ghostscript that's involved in the conversion process messing
things up?  I’m really lost at this point.  Why is cp1252 even showing
up here when I’m not on Windows?

Many hours of debugging and trying different approaches, I’m still
stuck.  It feels like I’m missing something obvious, but at this
point, I’m exhausted and just need fresh eyes on this.  If anyone has
insights or suggestions on how to get ps-print to correctly handle
Cyrillic characters or ensure that `ps2pdf' doesn’t mess up the
fonts, I’d really appreciate your help.  This has been a frustrating
journey, and I’d love to hear how others have tackled similar issues.


Serghei

--

In GNU Emacs 29.4 (build 1, aarch64-apple-darwin21.6.0, NS
 appkit-2113.60 Version 12.6.6 (Build 21G646)) of 2024-08-02 built on
 armbob.lan
Windowing system distributor 'Apple', version 10.3.2487
System Description:  macOS 14.6.1

Configured using:
 'configure --with-ns '--enable-local

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

[Swapneil Singh]

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 background thread I
> > create, even when those threads are yielded.
> >
> > Sending this as a bug report per Eli Zaretskii's mention that it may not
> > be expected behavior
> > (https://www.reddit.com/r/emacs/comments/1fbkkii/comment/lm3boja/).
> >
> > Repro recipe:
> > - emacs -Q
> > - `C-x 3` and run `list-threads` in the new window, then return to the
> > older window
> > - `M-:` `(make-thread (lambda () (cl-loop while t do (progn
> > (thread-yield) (sleep-for 30)` and wait for the new thread to yield to
> > the main thread.
> > - `C-g`. The new thread disappears from the `list-threads` window.
> >
> >
> > Note: While I am admittedly on Windows, given this behavior is within the
> > cooperative threads of the Emacs runtime (rather than actual Windows
> > threads) I *really* doubt that has anything to do with it.
>
> Actually, your being on MS-Windows does explain what you see, because
> the way C-g is processed is system-dependent.  When I said "this is
> not supposed to happen", I assumed you were doing this on GNU/Linux or
> another Posix platform.
>
> Indeed, on MS-Windows this is expected behavior: pressing C-g in the
> above scenario will set the quit-flag, and the loop will then quit.
> To prevent that, you need to use this simple technique:
>
>   (make-thread
>(lambda ()
>  (let ((inhibit-quit t))  ;; 
>(cl-loop
> while t do
> (progn
>   (thread-yield)
>   (sleep-for 30))
>
> Btw, my recommendation is to bind inhibit-quit non-nil around the
> thread functions in all cases, if you want background thread to never
> be interrupted by C-g and the like.

bug#73159:

[Casey Banner]

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 be why `initialized` is false, and why uniscribe / harfbuzz
is not loaded. If I rename the emacs-.pdmp file to emacs.pdmp,
and place it next to emacs.exe everything works as expected (and emacs
loads a lot faster!).

I did a procmon dump to see what .pdmp files emacs.exe is trying to load,
and it attempts these locations:

- E:\dev\emacs-src\bin\emacs.pdmp
-
E:\dev\emacs-src\libexec\emacs\30.0.50\x86_64-w64-mingw32\emacs-ef314e5e05618ae9e98f90769b2adce721d1b3bac00e305e61b4d457b0a4.pdmp
- E:\dev\emacs-src\libexec\emacs\30.0.50\x86_64-w64-mingw32\emacs.pdmp

The thing is, the emacs version is 30.0.90, not 30.0.50.

A strings dump of emacs.exe:

strings emacs.exe | grep 30.0
%emacs_dir%/libexec/emacs/30.0.50/x86_64-w64-mingw32
$Id: GNU Emacs 30.0.90 (x86_64-w64-mingw32 ACL GIF GMP GNUTLS HARFBUZZ JPEG
LCMS2 LIBXML2 MODULES NATIVE_COMP NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND
SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XPM ZLIB) $
30.0.90
%emacs_dir%/share/emacs/30.0.90/lisp
%emacs_dir%/share/emacs/30.0.90/site-lisp;%emacs_dir%/share/emacs/site-lisp
/30.0.90/lisp/
%emacs_dir%/share/emacs/30.0.90/etc
%emacs_dir%/libexec/emacs/30.0.90/x86_64-w64-mingw32
%emacs_dir%/libexec/emacs/30.0.50/x86_64-w64-mingw32

So it seems something is going wrong with setting the path. I noticed that
exec/configure.ac has:

AC_INIT([libexec], [30.0.50], [bug-gnu-emacs@gnu.org], [],
  [https://www.gnu.org/software/emacs/])

I tried changing this to 30.0.90 and re-building (using make bootstrap),
but the resulting binary still has 30.0.50 in it.

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

[Jim Porter]

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 rendering.


Checking that page via curl, it appears that it doesn't return a 
Content-Type header. In the absence of that header, EWW assumes that the 
page is plain text.



I have also tried it on an Ubuntu 22.04.4 LTS distro running Emacs 28.1
but it also fails to render.  This therefore appears to be a bug in EWW.


From my reading of RFC9110[1], this is *technically* a bug (we should 
assume application/octet-stream, not text/plain), but that wouldn't fix 
the rendering here; it would probably make things worse. However, per 
the RFC, EWW would be within its rights to guess that the page is HTML, 
e.g. by checking for "". It also recommends having that 
be an option that can be disabled, which is reasonable (and in keeping 
with Emacs's design principles anyway).


[1] https://www.rfc-editor.org/rfc/rfc9110#section-8.3-5

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

[Ihor Radchenko]

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 nil nil
>   (expand-file-name
> (concat (file-name-sans-extension file) ".ps"))
>   (expand-file-name file))
> (delete-file (concat (file-name-sans-extension file) ".ps"))
> (message "PDF written to %s" file)
> --8<---cut here---end--->8---

(A comment to Eli and other Emacs maintainers)

I believe that what we observe here is a problem in `ps-print-buffer',
not in Org mode. In other words, it looks like Emacs bug, not Org mode
bug.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

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

[Juri Linkov]

>> 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-line' with 'tab-bar'.  This means that
this recipe doesn't work:

```elisp
(defun mu4e--modeline-string ()
  #(" 🌀0/0 "
  0 5 (help-echo "mu4e favorite bookmark"
   mouse-face mode-line-highlight
   keymap (mode-line . (keymap (mouse-1 . mu4e-jump-to-favorite)
   (mouse-2 . mu4e-jump-to-favorite)
   (mouse-3 . mu4e-jump-to-favorite))

(add-to-list 'global-mode-string '(:eval (mu4e--modeline-string)) t)

(defun mu4e-jump-to-favorite ()
  (interactive)
  (message "DONE"))

(setopt tab-bar-format (append tab-bar-format '(tab-bar-format-align-right
tab-bar-format-global)))
(tab-bar-mode)
```

But after remapping the symbol 'mode-line' with 'tab-bar',
it works nicely:

```elisp
(defun mu4e--modeline-string ()
  #(" 🌀0/0 "
  0 5 (help-echo "mu4e favorite bookmark"
   mouse-face mode-line-highlight
   keymap (keymap (tab-bar . (keymap (mouse-1 . mu4e-jump-to-favorite)
 (mouse-2 . mu4e-jump-to-favorite)
 (mouse-3 . mu4e-jump-to-favorite)))
```

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

[Juri Linkov]

>>> 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 nil nil nil nil nil nil nil)
>>>   query-replace-regexp("7" "!" nil nil nil nil nil)
>>>   funcall-interactively(query-replace-regexp "7" "!" nil nil nil nil nil)
>>>   command-execute(query-replace-regexp)
>>
>> Do I interpret the code in replace_match correctly: this error doesn't
>> even mean the match data has been clobbered - only that modification
>> hooks called searching functions?  I don't know what the referenced
>> search_regs.num_regs exactly contains.  But we already seem to ensure
>> not to clobber match data.
>
> It fails in emacs-30, but not in emacs-29.
> So this is a regression.

This is caused by commit 63588775fcb, so Cc-ing Stefan.

But probably this commit just exposed the problem
that existed before?

Anyway here is 100% reproducible recipe:

0. emacs -Q
1. 'C-x C-q' in a Dired with symlinks
2. 'C-M-% some_part_of_symlink RET anything RET'
3. 'y'

=> (error "Match data clobbered by buffer modification hooks")

This happens only for the first replacement after `emacs -Q`.