bug#71965: 30.0.60; '*nntpd** has no process' after left idle for a long time

[Gijs Hillenius]

Hi,

A little late, as the bug was closed.

I think this bug also applies to my set-up. My Gnus has these time-outs,
all the time, and, I agree with Eric it started with Emacs 29 (Debian).

I can perhaps contribute logs, if needed.

bug#71965: 30.0.60; '*nntpd** has no process' after left idle for a long time

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

On Tue, 10 Sep 2024 09:37:11 +0200 Gijs Hillenius  wrote:

> Hi,
>
> A little late, as the bug was closed.
>
> I think this bug also applies to my set-up. My Gnus has these time-outs,
> all the time, and, I agree with Eric it started with Emacs 29 (Debian).

Possibly bug#52735 (which I continue to experience) is also related.

Steve Berman

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

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

Eli Zaretskii  writes:

Hi Eli,

>> The umbrella function is tramp-send-command. It sends the command to
>> remote via tramp-send-string, and waits then for a proper shell prompt
>> via tramp-wait-for-output. The latter function calls
>> tramp-wait-for-regexp, which loops using tramp-accept-process-output.
>
> Did you try either calling accept-process-output with a non-zero
> timeout of, say, 5 msec, or inserting a (sit-for 0.005) into the loop
> which calls tramp-accept-process-output?

Tramp used a non-zero timeout in the past. This was removed some years
ago, I don't remember the reason.

I've added (sit-for 0.005) in the loop calling
tramp-accept-process-output. It decreases the CPU load from 100% to
something between 45..50%, when waiting for a response from
remote. Pushed to master, and thanks for the explanation!

Best regards, Michael.

bug#73098: setopt float warning unexpected

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

Stefan Monnier  writes:

> I tend to agree.  If the type doesn't accept the value, you can use
> something lower-level than `setopt` [...]

What would that be in case the option has a custom setter function?


Michael.

bug#72818: 29.4; Cannot hook with use-package if variable is not `-hook'$

[Marc Fargas]

Thank you all for the fix.

Emacs is Awesome

bug#73159:

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

Casey Banner  writes:

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

This version number shouldn't appear in any binaries built for
MS-Windows (or otherwise than for Android in general), and its value is
not really significant even there.

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

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

>> What does (frame-text-height) return for the first and the
>> second frame?
>
> 1260 for both.

Relieving.

>>Also I hope you didn't get the GTK assertion failure.
>>
>
> Indeed, I do not.

So the sequence definitely is: For some inexplicable reason we receive a
ConfigureNotify event that tells us that the frame has become very
small.  We accept the new size, adjust our frame accordingly and use the
new size as base for the next resize request.  When we issue that
request, GTK complains that it cannot fit the menubar and issues the
assertion failure.

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

Since you run with

emacs -Q  --eval "(setq default-frame-alist '((menu-bar-lines . 0)))"

Emacs considers menu bars to be currently enabled "globally" and
disabling them globally has no effect on that frame.  Do you agree with
this explanation?

> OK, running with just this patch (which applies fine), and doing the
> history test, the history of the second frame is:
...
> ConfigureNotify, PS=1328x1260, XS=400x376, DS=1328x1260
> xg_frame_resized, rejected, PS=1328x1260, XS=400x376, DS=664x630

The 400x376 are as before so other size hints won't fix anything (but we
inherently checked that when running with 'frame-resize-pixelwise'
before).

> 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

But this one ...

> 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

... and this one are obviously fishy.  The sizes apparently match, so
why reject them?  The reason is that I recorded scaled sizes in what
appear after DS.  Since you have a scaling factor of 2 and (* 2 664)
gives 1328 this explains the width value.  The height value is likely as
(- (* 2 696) 132) giving 1260 where 132 is the height of your tool bar
(I extracted that from your previous call of 'frame-geometry').  If
there were a menu bar, we would have to subtract another 50 pixels.

So please try again with the attached patch which records the original
unscaled sizes.  And please tell me what

(frame-char-width)
(frame-char-height)

evaluate to.  I'm still trying to explain the 400x376 values.

martindiff --git a/src/gtkutil.c b/src/gtkutil.c
index d57627f152f..f5022411dab 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 = height;
+  last_resize_width = 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#73098: setopt float warning unexpected

[Eli Zaretskii]

> From: Stefan Monnier 
> Cc: Michael Heerdegen ,  shipmi...@gmail.com,
>   73...@debbugs.gnu.org
> Date: Mon, 09 Sep 2024 18:41:46 -0400
> 
> IMO, the whole point of `setopt` is to check the value against the type.

I agree, but some users expect setopt to be a variant of setq,
especially since we advertise such use of setopt for modifying user
options.

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

[Eli Zaretskii]

> Date: Tue, 10 Sep 2024 02:32:46 +0300
> Cc: phil...@posteo.net, 43...@debbugs.gnu.org
> From: Dmitry Gutov 
> 
> >>> 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.

Completion is also important, IMO.

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

We could in this particular case enable it once, then disable it after
regenerating TAGS.

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

The query should allow the user to tell us his/her preference, no?

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

As long as there's a way of turning it off, I don't think I will mind
too much.

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

[Eli Zaretskii]

> Date: Tue, 10 Sep 2024 03:58:58 +0300
> Cc: joaotav...@gmail.com, 72...@debbugs.gnu.org
> From: Dmitry Gutov 
> 
> >> 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.

I installed the patch on the emacs-30 branch.

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

You mean, playing with fire?  Yes, but you need to be aware of that.
This variable was introduced relatively recently for use by
test/src/xdisp-tests.el; anywhere else you are on your own ;-)

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

[Eli Zaretskii]

> From: Sean McAfee 
> Date: Mon, 9 Sep 2024 22:13:06 -0500
> Cc: 72...@debbugs.gnu.org
> 
>  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.

I think this behavior must stay because in at least one case it's what
users will expect: C-u 5 C-d C-M-w C-S-.  If this is invoked in
the middle of a line, it kills 5 characters, then kills the whole of
the remaining line under "append-next-kill".

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

OK, thanks.  I will wait for a few days to let people comment, before
closing this bug.

bug#73098: setopt float warning unexpected

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

>> I tend to agree.  If the type doesn't accept the value, you can use
>> something lower-level than `setopt` [...]
> What would that be in case the option has a custom setter function?

AFAIK people used `setq` before `setopt`.  For vars that come with
setter functions, this usually doesn't work quite the same, but in 99%
it's good enough if the `setq` is performed early during startup.

You can also

(put ' 'custom-type t)

if you want to disable type-checking for a specific variable.


Stefan

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

[Eli Zaretskii]

> From: Casey Banner 
> Date: Tue, 10 Sep 2024 00:15:24 -0400
> 
> 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).

Where did you get the libharfbuzz-0.dll file you have installed?
Is libharfbuzz-0.dll in a directory that is on Path or in the same
directory as emacs.exe you are running?
And what does the commend below print?

  objdump -x /path/to/libharfbuzz-0.dll | grep "DLL Name":

The main problem you have is that Emacs is somehow unable to use
HarfBuzz.  All the rest is less important (the fact that Emacs on the
emacs-30 branch was unable to load Uniscribe is indeed a bug, which I
fixed just now).  So let's focus on that one problem: you should be
able to use HarfBuzz if it is installed correctly; it works for me.

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

This is due tho the following, I think:

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

How come your LANG is set to en_US.UTF-8?  Did you set this in the
environment or something.  Using UTF-8 as the default encoding on
Windows is not a good idea.

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

[Eli Zaretskii]

> From: Casey Banner 
> Date: Tue, 10 Sep 2024 01:50:43 -0400
> 
> 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/])

exec/configure.ac is not used in the MinGW build (but the above is a
bug nonetheless, so I will fix it shortly).

I cannot reproduce this result:

> strings emacs.exe | grep 30.0
> %emacs_dir%/libexec/emacs/30.0.50/x86_64-w64-mingw32

Please look at src/epaths.h and see how PATH_EXEC is defined there.

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

As expected: the MinGW build doesn't use that file.  You should
regenerate or update src/epaths.h.  Perhaps touch src/epaths.in and
then re-run "make" in the top-level directory of the source tree.

bug#73159: exec/configure.ac

[Eli Zaretskii]

> Cc: 73...@debbugs.gnu.org
> Date: Tue, 10 Sep 2024 17:29:27 +0800
> From:  Po Lu via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" 
> 
> Casey Banner  writes:
> 
> > AC_INIT([libexec], [30.0.50], [bug-gnu-emacs@gnu.org], [],
> >   [https://www.gnu.org/software/emacs/])
> 
> This version number shouldn't appear in any binaries built for
> MS-Windows (or otherwise than for Android in general), and its value is
> not really significant even there.

Unrelated to the problem of the MinGW build, the fact that
exec/configure.ac is not modified by admin/admin.el:set-version is a
bug, don't you agree?  We should have 30.0.90 in that file, not
30.0.50, right?

bug#73159: exec/configure.ac

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

Eli Zaretskii  writes:

> Unrelated to the problem of the MinGW build, the fact that
> exec/configure.ac is not modified by admin/admin.el:set-version is a
> bug, don't you agree?  We should have 30.0.90 in that file, not
> 30.0.50, right?

Yes I do.  I think I'll make this so tomorrow.

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

[Dmitry Gutov]

On 10/09/2024 14:47, Eli Zaretskii wrote:

Date: Tue, 10 Sep 2024 03:58:58 +0300
Cc:joaotav...@gmail.com,72...@debbugs.gnu.org
From: Dmitry Gutov


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.

I installed the patch on the emacs-30 branch.


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?

You mean, playing with fire?  Yes, but you need to be aware of that.
This variable was introduced relatively recently for use by
test/src/xdisp-tests.el; anywhere else you are on your own 😉


Thanks!

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]

> This is caused by commit 63588775fcb, so Cc-ing Stefan.
>
> But probably this commit just exposed the problem
> that existed before?

I think you're on to something.

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

This comes from

if (search_regs.num_regs != num_regs)
  error ("Match data clobbered by buffer modification hooks");

But this test is not doing what it is intended to do: it doesn't check
whether the match data has changed.  It just checks whether the size of
the arrays we have allocated to hold the match data has changed.

I got to that conclusion after narrowing down the origin of the error
and finding out that the problem is that `search_regs.num_regs` is set
to 13 before the first call to `wdired--restore-properties` but to
23 afterwards.

We should probably use something like

ptrdiff_t
search_regs_last_reg (void)
{
  ptrdiff_t i = search_regs.num_regs - 1;
  while (i >= 0 && search_regs.start[i] < 0)
i--;
  return i;
}

instead of `search_regs.num_regs`.


Stefan

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]

> We should probably use something like
>
> ptrdiff_t
> search_regs_last_reg (void)
> {
>   ptrdiff_t i = search_regs.num_regs - 1;
>   while (i >= 0 && search_regs.start[i] < 0)
> i--;
>   return i;
> }
>
> instead of `search_regs.num_regs`.

And maybe we should consider changing `struct re_search` to keep track
of the last non-nil subgroup.  Currently, things like `match-data` loop
through all the elements of `search_regs` whose size depends on the
size (in number of subgroups) of the largest regexp we have ever matched
so far, rather than the actual number of subgroups currently in use, so
there's some wasted work there.  Maybe the cost of maintaining the "last
reg" would pay off.


Stefan

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

[Dmitry Gutov]

On 10/09/2024 14:41, Eli Zaretskii wrote:


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.


Completion is also important, IMO.


Just not always worth the extra query or wait time.


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.


We could in this particular case enable it once, then disable it after
regenerating TAGS.


I'm not sure I'd want a one-time generation of tags which never gets 
updated afterward. Not for me, nor for an inexperienced user who would 
likely get puzzled at some point about why the index not updating.



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.


The query should allow the user to tell us his/her preference, no?


For that we need to decide on the options and the possible lifetimes of 
the answer in advance. That's all I'm saying: it's not an obvious "just 
ask the user".



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.


As long as there's a way of turning it off, I don't think I will mind
too much.


Great! As long as nobody objects in the coming days I'll switch the 
default value.

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

[Dmitry Gutov]

On 10/09/2024 15:45, Eli Zaretskii wrote:

Cc: phil...@posteo.net, 43...@debbugs.gnu.org
Date: Tue, 10 Sep 2024 14:41:43 +0300
From: Eli Zaretskii 


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.


As long as there's a way of turning it off, I don't think I will mind
too much.


Come to think about this: this mode runs 'etags' without any special
switches, right?  Then what will turning this mode ON do in the Emacs
repository, where our 'etags' command is very heavily customized (see
src/Makefile.in)?


etags-regen-mode doesn't know how to parse Makefile.in, and it doesn't 
seem feasible, so it needs the user to customize 
`etags-regen-regexp-alist` for any special rules.


That's already done in the Emacs repo, see our .dir-locals.el.

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

[Eli Zaretskii]

> Cc: phil...@posteo.net, 43...@debbugs.gnu.org
> Date: Tue, 10 Sep 2024 14:41:43 +0300
> From: Eli Zaretskii 
> 
> > 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.
> 
> As long as there's a way of turning it off, I don't think I will mind
> too much.

Come to think about this: this mode runs 'etags' without any special
switches, right?  Then what will turning this mode ON do in the Emacs
repository, where our 'etags' command is very heavily customized (see
src/Makefile.in)?

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

[Eli Zaretskii]

> Date: Mon, 09 Sep 2024 22:38:13 +
> From:  Serghei Iakovlev via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" 
> 
> 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---

IMO, Org should document that org-agenda-write uses ps-print and
ps2pdf, so that users could know where to look for cause of trouble
and which parts to customize to work around these problems.

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

I don't know about ps2pdf, but I did at one time, years ago, have a
working setup that was capable of using ps-print to print Cyrillic
text from Emacs to a PostScript printer.  I will try to describe what
I think I did back then, using my old files and archives to recollect
stuff I've long forgotten, in the hope it will help you.

> As far as I can tell, `ps-mule' expects me to install BDF fonts and set
> the path to them in `bdf-directory-list'.

Yes.  Here's what I had back when I printed Cyrillic text using
ps-print:

  (setq ps-multibyte-buffer 'bdf-font-except-latin)
  (setq bdf-directory-list (list (concat invocation-directory "../fonts/bdf")))

(The value of bdf-directory-list is just my personal choice back then:
you can have any directory there, just make sure the BDF fonts arfe
really in that directory.  But it must be a list, even if you just
have a single directory.)

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

The BDF fonts I used are from the GNU Intlfonts.  I think they are the
only ones that are guaranteed to work with ps-mule and ps-bdf, or at
least worked in the past (see below).  AFAICT, you can still download
them from here:

  https://ftp.gnu.org/gnu/intlfonts/intlfonts-1.2.1.tar.gz

When you unpack the tarball, chdir to the intlfonts-1.2.1 created by
unpacking, and type:

  $ make bdf INSTALLDIR=/path/to/where/to/install

This should install the BDF fonts in the specified directory, and you
should point bdf-directory-list to it.  (You can delete the
intlfonts-1.2.1 tree after you do the above.)

AFAIR, this was all I needed back then; I hope I don't misremember.

However: I last used this with Emacs 21, which is before Emacs was
converted to Unicode-based treatment of non-ASCII cha

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

[Eli Zaretskii]

> Cc: 73...@debbugs.gnu.org
> From: Ihor Radchenko 
> Date: Tue, 10 Sep 2024 06:19:41 +
> 
> 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.

It isn't an Org bug, but IMO Org should prominently document that the
above is only going to work for ASCII and maybe also Latin-1 text; any
other scripts, if they at all work, need ps-mule setup and BDF fonts.

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

[Eli Zaretskii]

> Cc: 73...@debbugs.gnu.org
> Date: Tue, 10 Sep 2024 16:51:28 +0300
> From: Eli Zaretskii 
> 
> However: I last used this with Emacs 21, which is before Emacs was
> converted to Unicode-based treatment of non-ASCII characters.  So it
> is possible that the above will not work with the current codebase,
> because ps-mule needs to decide which of the BDF fonts to use for each
> script (in your case Cyrillic), and I just don't remember if this code
> was adjusted to the changes we made in Emacs 23 (I think it was, but I
> am not sure).

Bad news: I tried that, and it doesn't seem to work.  I guess
something is missing in ps-mule.el to do the job in the current Emacs,
sigh...

bug#73102: 29.4; `package-recompile-all' should skip packages installed by distro package manager

[Philip Kaludercic]

Zhengyi Fu  writes:

> Philip Kaludercic  writes:
>
>> Zhengyi Fu  writes:
>>
>>> When I try recompiling all packages installed by package.el with `M-x
>>> package-recompile-all', I got the following error:
>>>
>>> Debugger entered--Lisp error: (permission-denied "Removing old name"
>>> "Permission denied"
>>> "/usr/share/emacs/site-lisp/elpa/mu4e-1.10.8/mu4e-a...")
>>>   package-recompile(#s(package-desc :name mu4e :version (1 10 8)
>>> :summary "the mu mail user agent" :reqs nil :kind nil :archive nil
>>> :dir "/usr/share/emacs/site-lisp/elpa/mu4e-1.10.8" :extras nil
>>> :signed nil))
>>>   package-recompile-all()
>>>   funcall-interactively(package-recompile-all)
>>>   command-execute(package-recompile-all record)
>>>   execute-extended-command(nil "package-recompile-all" "recom all")
>>>   funcall-interactively(execute-extended-command nil 
>>> "package-recompile-all" "recom all")
>>>   command-execute(execute-extended-command)
>>>
>>> This is possibly because the package `mu4e' was installed by the distro
>>> package manager in a path where normal users don't have write access.
>>>
>>> I think `package-recompile-all' should either skip those packages that
>>> are not installed by package.el or ignore such errors and continue to
>>> recompile other packages.
>>
>> We have installed a patch in Bug#68678 on master (the commit is from
>> last February, so you wouldn't see it yet on 29.4) that wraps the
>> `package-recompile' call in a `with-demoted-errors' block.  That would
>> still emit a error message, but it wouldn't break the recompilation
>> procedure.  Do you think that is enough, or should be explicitly and
>> additionally avoid re-compiling external packages?
>
> Yes.  That patch is enough for me.  Thanks!!

Great, I'll close this report then.  If you haven't fixed the issue
locally yet: Until you upgrade, a simple fix would be to add some advice
around package-recompile that wraps it in a `with-demoted-errors' block.

-- 
Philip Kaludercic on siskin

bug#73102: 29.4; `package-recompile-all' should skip packages installed by distro package manager

[Zhengyi Fu]

Philip Kaludercic  writes:

> Zhengyi Fu  writes:
>
>> When I try recompiling all packages installed by package.el with `M-x
>> package-recompile-all', I got the following error:
>>
>> Debugger entered--Lisp error: (permission-denied "Removing old name"
>> "Permission denied"
>> "/usr/share/emacs/site-lisp/elpa/mu4e-1.10.8/mu4e-a...")
>>   package-recompile(#s(package-desc :name mu4e :version (1 10 8)
>> :summary "the mu mail user agent" :reqs nil :kind nil :archive nil
>> :dir "/usr/share/emacs/site-lisp/elpa/mu4e-1.10.8" :extras nil
>> :signed nil))
>>   package-recompile-all()
>>   funcall-interactively(package-recompile-all)
>>   command-execute(package-recompile-all record)
>>   execute-extended-command(nil "package-recompile-all" "recom all")
>>   funcall-interactively(execute-extended-command nil "package-recompile-all" 
>> "recom all")
>>   command-execute(execute-extended-command)
>>
>> This is possibly because the package `mu4e' was installed by the distro
>> package manager in a path where normal users don't have write access.
>>
>> I think `package-recompile-all' should either skip those packages that
>> are not installed by package.el or ignore such errors and continue to
>> recompile other packages.
>
> We have installed a patch in Bug#68678 on master (the commit is from
> last February, so you wouldn't see it yet on 29.4) that wraps the
> `package-recompile' call in a `with-demoted-errors' block.  That would
> still emit a error message, but it wouldn't break the recompilation
> procedure.  Do you think that is enough, or should be explicitly and
> additionally avoid re-compiling external packages?

Yes.  That patch is enough for me.  Thanks!!

-- 
Zhengyi Fu

bug#72819: [PATCH] Correctly include fixed strings before a prefix wildcard in PCM

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

Eli Zaretskii  writes:
>> Cc: monn...@iro.umontreal.ca
>> From: Spencer Baugh 
>> Date: Mon, 26 Aug 2024 10:17:05 -0400
>> 
>> In 63a48252306a631dc07d62d19311433c7877bd27 I fixed a bug with
>
> Git tells me "bad object 63a48252306a631dc07d62d19311433c7877bd27", so
> I couldn't figure out which commit are you referring to.

Oops, here's the patch again with a corrected commit message:

>From 1c9df731bacadd4ef762675af9903ccb0897a3ae Mon Sep 17 00:00:00 2001
From: Spencer Baugh 
Date: Mon, 26 Aug 2024 10:12:51 -0400
Subject: [PATCH] Correctly include fixed strings before a prefix wildcard in
 PCM

In 03ac16ece40ba3e3ba805d6a61cc457d84bf3792 I fixed a bug with the PCM
implementation of substring completion, relating to the handling of
PCM wildcards.

However, this fix was incomplete.  This change completes the fix by
also including a fixed string if it appears before a `prefix'
wildcard, even if try-completion doesn't discover that fixed string
grows to a unique completion.

I discovered this bug while working on enhancements to PCM completion
related to completion-pcm-leading-wildcard.

* lisp/minibuffer.el (completion-pcm--merge-completions): Include
fixed strings before 'prefix wildcard. (bug#72819)
* test/lisp/minibuffer-tests.el (completion-substring-test-5): Add a
test for this behavior.
---
 lisp/minibuffer.el| 15 +--
 test/lisp/minibuffer-tests.el | 17 -
 2 files changed, 21 insertions(+), 11 deletions(-)

diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 6fae62b3904..1efe71f10e3 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -4418,18 +4418,21 @@ completion-pcm--merge-completions
  (unique (or (and (eq prefix t) (setq prefix fixed))
  (and (stringp prefix)
   (eq t (try-completion prefix comps))
-;; if the common prefix is unique, it also is a common
-;; suffix, so we should add it for `prefix' elements
-(unless (or (and (eq elem 'prefix) (not unique))
-(equal prefix ""))
-  (push prefix res))
 ;; If there's only one completion, `elem' is not useful
 ;; any more: it can only match the empty string.
 ;; FIXME: in some cases, it may be necessary to turn an
 ;; `any' into a `star' because the surrounding context has
 ;; changed such that string->pattern wouldn't add an `any'
 ;; here any more.
-(unless unique
+(if unique
+;; if the common prefix is unique, it also is a common
+;; suffix, so we should add it for `prefix' elements
+(push prefix res)
+  ;; `prefix' only wants to include the fixed part before the
+  ;; wildcard, not the result of growing that fixed part.
+  (when (eq elem 'prefix)
+(setq prefix fixed))
+  (push prefix res)
   (push elem res)
   ;; Extract common suffix additionally to common prefix.
   ;; Don't do it for `any' since it could lead to a merged
diff --git a/test/lisp/minibuffer-tests.el b/test/lisp/minibuffer-tests.el
index df36bce4634..38c2b8c4552 100644
--- a/test/lisp/minibuffer-tests.el
+++ b/test/lisp/minibuffer-tests.el
@@ -306,13 +306,20 @@ completion-substring-test-4
6)))
 
 (ert-deftest completion-substring-test-5 ()
-  ;; merge-completions needs to work correctly when
+  ;; Normally a `prefix' wildcard ignores the common prefix to its
+  ;; left, since it only grows the common suffix; but if that common
+  ;; prefix is also a common suffix, it should be included.
   (should (equal
-   (completion-pcm--merge-completions '("ab" "sab") '(prefix "b"))
-   '("b" "a" prefix)))
+   (completion-pcm--merge-try '(prefix "b") '("ab" "sab") "" "")
+   '("ab" . 2)))
   (should (equal
-   (completion-pcm--merge-completions '("ab" "ab") '(prefix "b"))
-   '("b" "a")))
+   (completion-pcm--merge-try '(prefix "b") '("ab" "ab") "" "")
+   '("ab" . 2)))
+  ;; When there's a fixed string before `prefix', that fixed string
+  ;; should always be included.
+  (should (equal
+   (completion-pcm--merge-try '("a" prefix "b") '("axb" "ayb") "" "")
+   '("ab" . 2)))
   ;; substring completion should successfully complete the entire string
   (should (equal
(completion-substring-try-completion "b" '("ab" "ab") nil 0)
-- 
2.39.3

bug#70968: 29.2.50; choose-completion on an emacs22-style completion deletes text after point

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

Stefan Monnier  writes:
>> Ping!  How should we proceed with this bug report?
>
> I don't quite understand the question.
>
> After:
>
> Eli wrote:
>> Stefan wrote:
>> > I'm not sure it's terribly important to preserve this detail of the
>> > behavior of `Emacs-22`.  The `emacs22` style does not aim to provide the
>> > illusion you're running an old Emacs.  I named it that way because
>> > I couldn't come up with a good descriptive name for it.  If it
>> > misbehaves, I don't see a need to be bug-compatible, especially since
>> > this doesn't affect ELisp code but users.
>>
>> I think it does, sorry.  Suchj old behavior is a de-facto standard.
>> If we change that, we should at least have a knob to get back the old
>> behavior.
>
> I thought you had decided that the current behavior is not a bug.
> I'm fine with this choice and we can close it as such.
> Tho maybe we'd want to deprecate that `emacs22` style because of
> those odd cases.

I definitely don't want to just close this bug.  I often get user
complaints about this behavior.  In my experience, for novice users,
it's a fairly significant inconsistency in the default Emacs completion
experience.

I see a few good ways to fix this in a backwards-compatible way:

A. Fix it in emacs22 with a defcustom to get back the old behavior.

B. Deprecate the emacs22 style and replace it with a new style called
   `ignore-suffix` which has this bug fixed, and which replaces emacs22
   in the default value of completion-styles.

C. Follow this idea I suggested earlier:

   Currently emacs22 is the only style that ignores the text after point
   when completing.  But, this is often useful behavior, and I'd like to
   support it in other completion styles.  Specifically, I think it
   would be nice if completion always:
   
   1. First, run the completion styles on the literal text in the
   completion region or minibuffer.
   
   2. If that returned nil, run the completion styles again, but without
   the text after point in the region or minibuffer.
   
   Step 2 when run with the basic style is equivalent to the emacs22
   style.  So, emacs22 could be removed from the default
   completion-styles, since a completion-styles of '(basic) would be
   equivalent to '(basic emacs22).

   I think this would make it straightforward to then fix
   choose-completion to behave correctly when the completion was
   generated through step 2.
   
I personally like the option C best, because I already want to do this
generalization, so that the ignore-suffix behavior also works for other
completion styles (e.g. partial-completion or substring).

But I would like to get some feedback on this idea from others first.

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

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

On Tue, 10 Sept 2024 at 10:32, martin rudalics  wrote:

>
> Since you run with
>
> emacs -Q  --eval "(setq default-frame-alist '((menu-bar-lines . 0)))"
>
> Emacs considers menu bars to be currently enabled "globally" and
> disabling them globally has no effect on that frame.  Do you agree with
> this explanation?
>

I would be more cautious, since I do not know the code, and simply say that
disabling menu-bar-mode has no effect on the current frame, where there is
already no menu bar.

So please try again with the attached patch which records the original
> unscaled sizes.  And please tell me what
>
> (frame-char-width)
> (frame-char-height)
>
> evaluate to.
>

Can I just check: do you want me to apply your latest gtkutil-reject.diff
on top of your previous size_hints.diff, or instead of it?

-- 
https://rrt.sc3d.org

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

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

Can I just check: do you want me to apply your latest gtkutil-reject.diff
on top of your previous size_hints.diff, or instead of it?


Instead of it.

martin

bug#73022: 31.0.50; Crash in build_frame_matrix_from_leaf_window after C-x 2 and reducing terminal size

[Daniel Clemente]

> Please try the attached diff (from my heavily edited copy of master, if
> it doesn't apply cleanly, complain immediately rather than messing up
> your Emacs).  It should fix two silly bugs in window.el that make a
> frame's safe minimum size much too large and includes the fix I proposed
> earlier here.

It applies well; thanks.
By the way, (window-min-size) still answers 4 (with and without your patch).

Emacs feels a bit "stronger" in the C-x 2 scenario, meaning that it
survives shrinking+enlarging the terminal, but it still crashes
sometimes.
But it also crashes in a new situation: just by shrinking the
normal/initial/unsplit frame, i.e. without needing to do C-x 2. It
didn't crash before, so the patch doesn't make the whole Emacs more
stable yet.


Without doing C-x 2:

#4  0x556c3016 in emacs_abort () at sysdep.c:2391
#5  0x5566d36f in cmcheckmagic (tty=0x5608fa80) at cm.c:122
#6  0x55671b1b in tty_write_glyphs (f=0x56012ff0,
string=0x70f4ec10, len=80) at term.c:831
#7  0x5567c11d in write_glyphs (f=0x56012ff0,
string=0x70f4dd10, len=80) at terminal.c:164
#8  0x55591b60 in update_frame_line (f=0x56012ff0, vpos=3,
updating_menu_p=false) at dispnew.c:5326

126  if (tty->termscript)
(gdb) p curY (tty)
$1 = 3
(gdb) p FrameRows (tty) - 1
$2 = 3
(gdb)


This one still happens (this is after C-x 2):
#5  0x5558b697 in build_frame_matrix_from_leaf_window
(frame_matrix=0x56050420,
w=0x56013210) at dispnew.c:2647

>
> And it moves the assignment of FrameRows to handle_window_change_signal
> in dispnew.c.  Doing it in adjust_frame_size was silly (as Gerd Möllmann
> noticed earlier).  FrameRows should be the height of the tty which can
> be smaller than the height of our frame.  Emacs is supposed to store it
> but not to modify it according to our capabilities.
>

I don't have the expert opinion of how it should be. But I agree that
a source of the problem is that the tty can be smaller than the frame.
Frame and terminal may have different sizes and this creates
inconsistencies.

For instance, Eli recently added this code (dispnew.c):

  /* This should never happen, but evidently sometimes does if one
 resizes the frame quickly enough.  Prevent aborts in cmcheckmagic.  */
  if (vpos >= FRAME_TOTAL_LINES (f))
return;

But this is checking the *frame*.  Later, the assertion in
cmcheckmagic will be made about the *terminal*.
I think the frame never gets smaller than 2 lines (there's code in
handle_window_change_signal to prevent it), but the tty can. So if
we're in a 1-line terminal, and updating the 2nd line, the above code
sees nothing wrong (the frame still has 2 lines) but cmcheckmagick
won't like it (the terminal doesn't have a 2nd line).
(Usual disclaimer: I don't know very well how this works. I'm often
brainstorming).

> And it moves the assignment of FrameRows to handle_window_change_signal
> in dispnew.c.

In practice, that code (in the new place you put it) is still inside an if: the
  if (width > 5 && height > 2)
in handle_window_change_signal. This means that in e.g. a 1-line
terminal, you won't be setting FrameRows to the actual number of lines
of terminal (1), as you wanted. It will still be the old value, e.g.
2, and it may make cmcheckmagic crash by trying to do things in line 2
(which exists in the frame, which has 2 lines) but not in the terminal
(which doesn't have a 2nd line).


One option seems to have FrameRows always match the amount of terminal
lines. Can we remove the "if (… height >2)" limitation, and allow
1-line, 2-line frames etc.? (To really match the terminal size). Other
changes may be needed in other places, to avoid working with very
small frames..

Otherwise, if we let FrameRows be larger than the amount of terminal
lines, another option could be:
At the beginning of tty_write_glyphs, check whether we've been asked
to write glyphs in a line which is higher than the amount of lines in
the terminal. If so, return without writing anything. (Because the
line would be invisible).
Or maybe in some of the callers of tty_write_glyphs. Don't call
tty_write_glyphs to write glyphs in a line which is not visible (it
exists in the frame, but doesn't exist in the terminal).


By the way, I saw that the cmcheckmagic code checks curY (tty) >=
FrameRows (tty) - 1, note the -1, whereas the dispnew.c code I quote
above doesn't use the -1. I hope this is ok. As mentioned they're
checking different things so it may be ok, though I don't understand
why the -1.

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

[Casey Banner]

> How come your LANG is set to en_US.UTF-8?  Did you set this in the
> environment or something.  Using UTF-8 as the default encoding on
> Windows is not a good idea.

It seems that the msys2 .profile has `export LANG=$(locale -uU)`, and that
returns en_US.UTF-8 for me.

> Please look at src/epaths.h and see how PATH_EXEC is defined there.

It is indeed  #define PATH_EXEC
"%emacs_dir%/libexec/emacs/30.0.50/x86_64-w64-mingw32"

src/epaths.in has #define PATH_EXEC "/usr/local/libexec/emacs"

I had been running configure and make in a subdirectory. If I run them in
the top-level directory,
then it does update PATH_EXEC to the correct version. I think I made the
wrong assumption that
 running configure in a subdirectory would leave the main source clean.

Thank you for your help debugging this!

- Casey

On Tue, Sep 10, 2024 at 8:33 AM Eli Zaretskii  wrote:

> > From: Casey Banner 
> > Date: Tue, 10 Sep 2024 01:50:43 -0400
> >
> > 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/])
>
> exec/configure.ac is not used in the MinGW build (but the above is a
> bug nonetheless, so I will fix it shortly).
>
> I cannot reproduce this result:
>
> > strings emacs.exe | grep 30.0
> > %emacs_dir%/libexec/emacs/30.0.50/x86_64-w64-mingw32
>
> Please look at src/epaths.h and see how PATH_EXEC is defined there.
>
> > 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.
>
> As expected: the MinGW build doesn't use that file.  You should
> regenerate or update src/epaths.h.  Perhaps touch src/epaths.in and
> then re-run "make" in the top-level directory of the source tree.
>
>

bug#73172: [PATCH] Move to start of current header in diff-{file, hunk}-prev

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

Tags: patch


(The following change is split across two patches; the first one, "move
easy-mmode", fixes an unrelated FIXME, which makes the diff in the
second patch simpler)

If point was after a file or hunk header, the diff-file-prev and
diff-hunk-prev commands would move to the start of that header.
But if point was *within* the header, they would not move, and
would report "No previous file" or "No previous hunk".  This
differs from the behavior of most other movement commands,
e.g. backward-sexp or backward-sentence.

This commit fixes diff-file-prev and diff-hunk-prev, as well as
other easy-mmode-define-navigation BASE-prev commands.  Now
these commands move to the start of the containing "thing" just
like other movement commands.

* lisp/emacs-lisp/easy-mmode.el (easy-mmode--prev): Move to
start of current match first.

Also discussed here:
https://lists.gnu.org/archive/html/help-gnu-emacs/2024-08/msg00367.html

In GNU Emacs 29.2.50 (build 17, x86_64-pc-linux-gnu, X toolkit, cairo
 version 1.15.12, Xaw scroll bars) of 2024-09-06 built on
 igm-qws-u22796a
Repository revision: e6d04c06a7eb6ce932b52a346368d02b7a811a00
Repository branch: emacs-29
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Rocky Linux 8.10 (Green Obsidian)

Configured using:
 'configure --with-x-toolkit=lucid --without-gpm --without-gconf
 --without-selinux --without-imagemagick --with-modules --with-gif=no
 --with-cairo --with-rsvg --without-compress-install
 --with-native-compilation=aot --with-tree-sitter
 PKG_CONFIG_PATH=/usr/local/home/garnish/libtree-sitter/0.22.6-1/lib/pkgconfig/'

>From 93f50388bda9f986a5aa8e51378793031cfdce05 Mon Sep 17 00:00:00 2001
From: Spencer Baugh 
Date: Tue, 10 Sep 2024 13:46:18 -0400
Subject: [PATCH] Move easy-mmode-define-navigation logic to helper functions

The functions defined by easy-mmode-define-navigation are useful
even if the easy-mmode-define-navigation macro is not used.
Let's take a step towards exposing them by moving them out as
helpers.

This also makes the macro much easier to modify and work on.

* lisp/emacs-lisp/easy-mmode.el (easy-mmode--prev)
(easy-mmode--next): Add.
(easy-mmode-define-navigation): Use easy-mmode--prev and
easy-mmode--next.
---
 lisp/emacs-lisp/easy-mmode.el | 86 ---
 1 file changed, 49 insertions(+), 37 deletions(-)

diff --git a/lisp/emacs-lisp/easy-mmode.el b/lisp/emacs-lisp/easy-mmode.el
index a140027839e..d3dcab899d6 100644
--- a/lisp/emacs-lisp/easy-mmode.el
+++ b/lisp/emacs-lisp/easy-mmode.el
@@ -763,6 +763,48 @@ easy-mmode-defsyntax
 ;;; easy-mmode-define-navigation
 ;;;
 
+(defun easy-mmode--prev (re name count &optional endfun narrowfun)
+  "Go to the previous COUNT'th occurence of RE.
+
+If none, error with NAME.
+
+ENDFUN and NARROWFUN are treated like in `easy-mmode-define-navigation'."
+  (unless count (setq count 1))
+  (if (< count 0) (easy-mmode--next re name (- count) endfun narrowfun)
+(let ((re-narrow (and narrowfun (prog1 (buffer-narrowed-p) (widen)
+  (unless (re-search-backward re nil t count)
+(user-error "No previous %s" name))
+  (when re-narrow (funcall narrowfun)
+
+(defun easy-mmode--next (re name count &optional endfun narrowfun)
+  "Go to the next COUNT'th occurence of RE.
+
+If none, error with NAME.
+
+ENDFUN and NARROWFUN are treated like in `easy-mmode-define-navigation'."
+  (unless count (setq count 1))
+  (if (< count 0) (easy-mmode--prev re name (- count) endfun narrowfun)
+(if (looking-at re) (setq count (1+ count)))
+(let ((re-narrow (and narrowfun (prog1 (buffer-narrowed-p) (widen)
+  (if (not (re-search-forward re nil t count))
+  (if (looking-at re)
+  (goto-char (or (if endfun (funcall endfun)) (point-max)))
+(user-error "No next %s" name))
+(goto-char (match-beginning 0))
+(when (and (eq (current-buffer) (window-buffer))
+   (called-interactively-p 'interactive))
+  (let ((endpt (or (save-excursion
+ (if endfun (funcall endfun)
+   (re-search-forward re nil t 2)))
+   (point-max
+(unless (pos-visible-in-window-p endpt nil t)
+  (let ((ws (window-start)))
+(recenter '(0))
+(if (< (window-start) ws)
+;; recenter scrolled in the wrong direction!
+(set-window-start nil ws)))
+  (when re-narrow (funcall narrowfun)
+
 (defmacro easy-mmode-define-navigation (base re &optional name endfun narrowfun
  &rest body)
   "Define BASE-next and BASE-prev to navigate in the buffer.
@@ -780,53 +822,23 @@ easy-mmode-define-navigation
   (let* ((base-name (symbol-name base))
 	 (prev-sym (intern (concat base-name "-prev")))
 	 (next-sym (intern (concat base-name "-next")))
- (when-narrowed
-  (la

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

[Eli Zaretskii]

> From: Casey Banner 
> Date: Tue, 10 Sep 2024 14:31:07 -0400
> Cc: 73...@debbugs.gnu.org
> 
> > How come your LANG is set to en_US.UTF-8?  Did you set this in the
> > environment or something.  Using UTF-8 as the default encoding on
> > Windows is not a good idea.
> 
> It seems that the msys2 .profile has `export LANG=$(locale -uU)`, and that 
> returns en_US.UTF-8 for me.

I don't recommend running Emacs from the MSYS2 Bash prompt.  Instead,
run it from a desktop shortcut or pin it to the task bar and run from
there.

> > Please look at src/epaths.h and see how PATH_EXEC is defined there. 
> 
> It is indeed  #define PATH_EXEC 
> "%emacs_dir%/libexec/emacs/30.0.50/x86_64-w64-mingw32"
> 
> src/epaths.in has #define PATH_EXEC "/usr/local/libexec/emacs" 
> 
> I had been running configure and make in a subdirectory. If I run them in the 
> top-level directory, 
> then it does update PATH_EXEC to the correct version. I think I made the 
> wrong assumption that
>  running configure in a subdirectory would leave the main source clean.
> 
> Thank you for your help debugging this!

OK, so that's one mystery down.  We are left with the HarfBuzz issue;
please answer the questions I asked about that.

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

[Casey Banner]

> OK, so that's one mystery down.  We are left with the HarfBuzz issue;
> please answer the questions I asked about that.

Ah, yes sorry -  I acquired the DLLs from the
mingw64/mingw-w64-x86_64-harfbuzz package.

$ objdump -x /mingw64/bin/libharfbuzz-0.dll | grep "DLL Name":
DLL Name: libgcc_s_seh-1.dll
DLL Name: GDI32.dll
DLL Name: KERNEL32.dll
DLL Name: msvcrt.dll
DLL Name: RPCRT4.dll
DLL Name: libstdc++-6.dll
DLL Name: USER32.dll
DLL Name: USP10.dll
DLL Name: libfreetype-6.dll
DLL Name: libglib-2.0-0.dll
DLL Name: libgraphite2.dll
DLL Name: libintl-8.dll

harfbuzz does load correctly now that the pdmp is being loaded correctly -
I believe because now it passes the `intialized` check and so actually
attempts to load them.

describe-char shows me: harfbuzz:-outline-Iosevka Fixed
SS02-regular-normal-normal-mono-14-*-*-*-c-*-iso8859-1 (#x56)

On Tue, Sep 10, 2024 at 2:47 PM Eli Zaretskii  wrote:

> > From: Casey Banner 
> > Date: Tue, 10 Sep 2024 14:31:07 -0400
> > Cc: 73...@debbugs.gnu.org
> >
> > > How come your LANG is set to en_US.UTF-8?  Did you set this in the
> > > environment or something.  Using UTF-8 as the default encoding on
> > > Windows is not a good idea.
> >
> > It seems that the msys2 .profile has `export LANG=$(locale -uU)`, and
> that returns en_US.UTF-8 for me.
>
> I don't recommend running Emacs from the MSYS2 Bash prompt.  Instead,
> run it from a desktop shortcut or pin it to the task bar and run from
> there.
>
> > > Please look at src/epaths.h and see how PATH_EXEC is defined there.
> >
> > It is indeed  #define PATH_EXEC
> "%emacs_dir%/libexec/emacs/30.0.50/x86_64-w64-mingw32"
> >
> > src/epaths.in has #define PATH_EXEC "/usr/local/libexec/emacs"
> >
> > I had been running configure and make in a subdirectory. If I run them
> in the top-level directory,
> > then it does update PATH_EXEC to the correct version. I think I made the
> wrong assumption that
> >  running configure in a subdirectory would leave the main source clean.
> >
> > Thank you for your help debugging this!
>
> OK, so that's one mystery down.  We are left with the HarfBuzz issue;
> please answer the questions I asked about that.
>

bug#66509: 29.1.50; let-alist should support numeric indexing

[Stefan Kangas]

Artur, do you have any thoughts on the below patch?

Spencer Baugh  writes:

> From 28e52a343f72991cafd23fea910cc5f64ac5 Mon Sep 17 00:00:00 2001
> From: Spencer Baugh 
> Date: Thu, 12 Oct 2023 18:01:46 -0400
> Subject: [PATCH] Support numeric indexing in let-alist
>
> let-alist is very useful.  But sometimes an alist contains a list in
> the middle, which contains yet more alists.  Previously, this was
> somewhat painful to deal with, and required something like:
>
> (let-alist alist
>   (let-alist (nth 0 .a)
> (let-alist (nth 3 .b)
>.c)))
>
> Now, the following works:
>
> (let-alist alist
>   .a.0.b.3.c)
>
> * lisp/emacs-lisp/let-alist.el (let-alist--access-sexp): Properly
> parse numbers.
> (let-alist--list-to-sexp): Use nth to handle numbers.
> (let-alist): Update docs.
> ---
>  lisp/emacs-lisp/let-alist.el | 25 +++--
>  1 file changed, 15 insertions(+), 10 deletions(-)
>
> diff --git a/lisp/emacs-lisp/let-alist.el b/lisp/emacs-lisp/let-alist.el
> index d9ad46b2af7..de7c087bf2a 100644
> --- a/lisp/emacs-lisp/let-alist.el
> +++ b/lisp/emacs-lisp/let-alist.el
> @@ -36,22 +36,23 @@
>  ;; symbol inside body is let-bound to their cdrs in the alist.  Dotted
>  ;; symbol is any symbol starting with a `.'.  Only those present in
>  ;; the body are let-bound and this search is done at compile time.
> +;; A number will result in a list index.
>  ;;
>  ;; For instance, the following code
>  ;;
>  ;;   (let-alist alist
> -;; (if (and .title .body)
> +;; (if (and .title.0 .body)
>  ;; .body
>  ;;   .site
>  ;;   .site.contents))
>  ;;
>  ;; essentially expands to
>  ;;
> -;;   (let ((.title (cdr (assq 'title alist)))
> +;;   (let ((.title.0 (nth 0 (cdr (assq 'title alist
>  ;; (.body  (cdr (assq 'body alist)))
>  ;; (.site  (cdr (assq 'site alist)))
>  ;; (.site.contents (cdr (assq 'contents (cdr (assq 'site alist))
> -;; (if (and .title .body)
> +;; (if (and .title.0 .body)
>  ;; .body
>  ;;   .site
>  ;;   .site.contents))
> @@ -93,14 +94,17 @@ let-alist--access-sexp
>  (if (string-match "\\`\\." name)
>  clean
>(let-alist--list-to-sexp
> -   (mapcar #'intern (nreverse (split-string name "\\.")))
> +   (mapcar #'read (nreverse (split-string name "\\.")))
> variable
>
>  (defun let-alist--list-to-sexp (list var)
>"Turn symbols LIST into recursive calls to `cdr' `assq' on VAR."
> -  `(cdr (assq ',(car list)
> -  ,(if (cdr list) (let-alist--list-to-sexp (cdr list) var)
> - var
> +  (let ((sym (car list))
> +(rest (if (cdr list) (let-alist--list-to-sexp (cdr list) var)
> + var)))
> +(cond
> + ((numberp sym) `(nth ,sym ,rest))
> + (t `(cdr (assq ',sym ,rest))
>
>  (defun let-alist--remove-dot (symbol)
>"Return SYMBOL, sans an initial dot."
> @@ -116,22 +120,23 @@ let-alist
>"Let-bind dotted symbols to their cdrs in ALIST and execute BODY.
>  Dotted symbol is any symbol starting with a `.'.  Only those present
>  in BODY are let-bound and this search is done at compile time.
> +A number will result in a list index.
>
>  For instance, the following code
>
>(let-alist alist
> -(if (and .title .body)
> +(if (and .title.0 .body)
>  .body
>.site
>.site.contents))
>
>  essentially expands to
>
> -  (let ((.title (cdr (assq \\='title alist)))
> +  (let ((.title (nth 0 (cdr (assq \\='title alist
>  (.body  (cdr (assq \\='body alist)))
>  (.site  (cdr (assq \\='site alist)))
>  (.site.contents (cdr (assq \\='contents (cdr (assq \\='site 
> alist))
> -(if (and .title .body)
> +(if (and .title.0 .body)
>  .body
>.site
>.site.contents))

bug#72992: 29.4; towards xoauth2 support in Emacs

[Xiyue Deng]

Friendly ping for feedback.
-- 
Xiyue Deng

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

[Suhail Singh]

Michael Albinus  writes:

> Tramp used a non-zero timeout in the past. This was removed some years
> ago, I don't remember the reason.

The timeout in tramp-accept-process-output was disabled in commit
54ef338ba3670415cf47fabc33a92d4904707c7e .  The commit mentions
bug#61350 , however, it's not clear (based on briefly skimming the
discussion there) that this change was ever necessary.  If not, should
the timeout be reintroduced?

> I've added (sit-for 0.005) in the loop calling
> tramp-accept-process-output. It decreases the CPU load from 100% to
> something between 45..50%, when waiting for a response from remote.

I am trying to better understand what's going on, so the following is
simply for my understanding.  Use your discretion when responding.

IIUC, we're still actively waiting for the output from the remote host,
but simple not _exclusively_ doing so thanks to the `sit-for'.  Is my
understanding correct?  If so, isn't there some mechanism to specify a
continuation that's run once the TRAMP process produces output?  Such a
mechanism shouldn't require a `sit-for' to yield control.

In other words, isn't it possible to do both font-locking and getting
the response over ssh concurrently (of the main thread, as well wrt each
other)?  If not, are there technical challenges in doing so, or simply
that it's not been implemented (and thus, possibly, we may not know what
the challenges are)?

> Pushed to master

Thank you.  I can test this (applied onto 29.4) later in the week along
with the `dired-font-lock-keywords' patch and report back.

-- 
Suhail

bug#72949: Gnus sometimes reports new messages but not showing them on IMAP server

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

Hi,

Xiyue Deng wrote:

> Hi,
>
> i'm having some issues that Gnus sometimes reports that there are new
> messages on an IMAP server but it doesn't show them.  In my case it's
> using Gmail IMAP, and if I check using other mail clients
> (e.g. Thunderbird) or directly check on Gmail website I can seem them.
> I'm not sure whether this issue is specific to IMAP either.  As I'm not
> sure how to get more info, I didn't use report bug yet, but would like
> to ask around and see whether this is a known issue, or otherwise I can
> get some suggestions to get more debug info before I formally file a
> bug.
>
> Any suggestions are welcome!  TIA!

James Thomas wrote:

> I haven't tested this patch (don't really know how to), but this could
> very well be the cause of this long-standing bug:

Could you check if this patch (the 1st one, which swaps the 0 and 1),
makes any difference?

Regards,
James

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

[Eli Zaretskii]

> From: Casey Banner 
> Date: Tue, 10 Sep 2024 14:56:28 -0400
> 
> > OK, so that's one mystery down.  We are left with the HarfBuzz issue;
> > please answer the questions I asked about that. 
> 
> Ah, yes sorry -  I acquired the DLLs from the 
> mingw64/mingw-w64-x86_64-harfbuzz package.
> 
> $ objdump -x /mingw64/bin/libharfbuzz-0.dll | grep "DLL Name":
> DLL Name: libgcc_s_seh-1.dll
> DLL Name: GDI32.dll
> DLL Name: KERNEL32.dll
> DLL Name: msvcrt.dll
> DLL Name: RPCRT4.dll
> DLL Name: libstdc++-6.dll
> DLL Name: USER32.dll
> DLL Name: USP10.dll
> DLL Name: libfreetype-6.dll
> DLL Name: libglib-2.0-0.dll
> DLL Name: libgraphite2.dll
> DLL Name: libintl-8.dll
> 
> harfbuzz does load correctly now that the pdmp is being loaded correctly - I 
> believe because now it passes the
> `intialized` check and so actually attempts to load them.
> 
> describe-char shows me: harfbuzz:-outline-Iosevka Fixed
> SS02-regular-normal-normal-mono-14-*-*-*-c-*-iso8859-1 (#x56)

OK, so I'm now closing this bug.

bug#72863: 30.0.50; tree-sitter elixir-ts-mode hangs and memory leak on some elixir and heex code

[Yuan Fu]

> On Sep 8, 2024, at 12:48 AM, Yuan Fu  wrote:
> 
> 
> 
>> On Sep 8, 2024, at 12:02 AM, Eli Zaretskii  wrote:
>> 
>>> From: Yuan Fu 
>>> Date: Sat, 7 Sep 2024 22:57:29 -0700
>>> Cc: m...@ssbb.me,
>>> wkirschb...@gmail.com,
>>> 72...@debbugs.gnu.org
>>> 
>>> 
>>> 
 On Sep 7, 2024, at 10:54 PM, Eli Zaretskii  wrote:
 
> From: Yuan Fu 
> Date: Sat, 7 Sep 2024 22:44:53 -0700
> Cc: Wilhelm Kirschbaum ,
> Eli Zaretskii ,
> 72...@debbugs.gnu.org
> 
> Meanwhile, I want to push the fix for the other bug I discovered to 
> emacs-30. Eli, I wrote a debugging function that prints parser states, 
> naturally this function isn’t called anywhere so there’ll be a compiler 
> warning, what should I do in this case?
 
 Why would there be a compiler warning?  What kind of warning?
>>> 
>>> A function-not-used warning. Maybe it’s an lldb thing?
>> 
>> If the function is not static, there should be no such warning.
> 
> Ah, you’re right, I marked it static. Thanks!
> 
> Yuan

Good news: not an Emacs bug. Bad news: a tree-sitter bug. Turns out I made an 
error in my test program, which is the reason why Emacs hangs but the test 
program doesn’t. Once I fixed the error, the test program hangs too. I 
submitted a bug report to tree-sitter: 
https://github.com/tree-sitter/tree-sitter/issues/3620

I can finally sleep soundly at night now; and I guess tree-sitter dev will 
start having sleepless nights :-)

Yuan

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

[Yuan Fu]

> On Sep 9, 2024, at 2:50 AM, Vincenzo Pupillo  wrote:
> 
> 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
> <0001-Add-a-user-option-to-disable-Doxygen-syntax-highligh.patch>

Thanks for taking this up! I won’t signal a warning if doxygen grammar isn’t 
found. Imagine a user without doxygen grammar, and din’t change 
c-ts-mode-enable-doxygen: they’ll get a warning whenever they open a C file. We 
should either set c-ts-mode-enable-doxygen to nil by default, or not warn when 
doxygen grammar doesn’t exist. Otherwise, the patch looks good to me.

Yuan

bug#64830: 30.0.50 C++ treesitter mode no coloration

[Yuan Fu]

Finally able to address this again.

> On Aug 28, 2024, at 11:01 PM, Eli Zaretskii  wrote:
> 
>> From: Yuan Fu 
>> Date: Wed, 28 Aug 2024 21:54:26 -0700
>> Cc: Stefan Kangas ,
>> Alan Mackenzie ,
>> 64...@debbugs.gnu.org
>> 
>> Ah, thanks for the review! TIL. Here’s the revised patch.
> 
> A few more nits:
> 
>> +  const char *sym;
>> +  dynlib_addr((void (*) (void)) langfn, &loaded_lang.filename, &sym);
>   ^^
> We leave one space between the function name and the opening paren.
> Also, do you really need the type-cast for langfn?  Do you get
> compiler warnings if you remove the cast?

Oops. And yeah, I actually get an error:

treesit.c:702:16: error: incompatible function pointer types passing 
'TSLanguage *(*)(void)' (aka 'struct TSLanguage *(*)(void)') to parameter of 
type 'void (*)(void)' [-Wincompatible-function-pointer-types]
  702 |   dynlib_addr (langfn, &loaded_lang.filename, &sym);
  |^~
./dynlib.h:39:26: note: passing argument to parameter 'ptr' here
   39 | void dynlib_addr (void (*ptr) (void), const char **file, const char 
**sym);
  |  ^

The error seems reasonable to me, I just don’t know other way to suppress it.

>> +DEFUN ("treesit-grammar-location", Ftreesit_grammar_location,
>> +   Streesit_grammar_location,
>> +   1, 1, 0,
>> +   doc: /* Return the path to the grammar file for LANGUAGE.
> 
> "Path" again.  I suggest "absolute file name" instead.
> 
>> +If LANGUAGE isn't loaded yet, load it first.  If the langauge can't be
>> +loaded or the path couldn't be found, return nil.  */)
>  ^
> I suggest "or the file name couldn't be determined”.

Done. Please take a look at the latest patch, thanks!

Yuan



grammar-location.patch
Description: Binary data