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

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

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

That's expected.  But (window-min-size (minibuffer-window)) should now
always evaluate to 1 and (frame-windows-min-size) should now give 5
instead of 8.  As for 'window-min-size' you can

- either (setq window-min-height 0) and then (window-min-size)

- or directly (window-min-size nil nil t)

which should both yield 2.  BTW, neither of the min size changes should
have any effect on the bug per se.  But it might cause it to occur
earlier or later and also in the one window case you mention below.

> Emacs feels a bit "stronger" in the C-x 2 scenario, meaning that it
> survives shrinking+enlarging the terminal, but it still crashes
> sometimes.

Without the patch I could make it crash reliably.  I can't with it.

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

Maybe because the frame can now get smaller after resize_frame_windows.
IIUC it all depends on where the cursor within the frame is.  In the
split window case you probably get crashes sooner if the cursor is in
the lower window.  Maybe still sooner if you resize the frame while the
minibuffer is active.  I didn't try such scenarios.

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

Indeed.  The GUI code doesn't have the cursor problem.  There an
arbitrarily large Emacs frame may continue to live within a tiny WM
window with an invisible cursor.

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

Right.  This should probably be

  if (FRAME_TERMCAP_P (f) && vpos >= FrameRows (FRAME_TTY (f)))
return;

And it's not about resizing frames "quickly".  Here I can crash it in a
very slow fashion too.

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

Right.  But I can get cmcheckmagic crash here with a 20 lines frame too.

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

The 5/2 checks cannot handle split windows.  These are artifacts from
the past.

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

bug#72831: [PATCH] gnus-icalendar: Allow comments in event replies

[Robert Pluim]

tags 72831 fixed
close 72831 31.1
quit

> On Sat, 07 Sep 2024 17:05:34 +0200, Ferdinand Pieper  
> said:

Ferdinand> Eli Zaretskii  writes:
>> Thanks, I'd like to wait for a few days, to let people comment if they
>> want.

Ferdinand> Sounds good, thanks for handling it.

I wrote a NEWS entry for this and made a few minor style and typo edits.

Sorry about the delay.

Closing.
Committed as 8332b4dd07a

Robert
-- 

bug#72866: [PATCH] Add ediff-copy-all-X-to-Y functions

[Robert Pluim]

tags 72866 fixed
close 72866 31.1
quit

> On Wed, 4 Sep 2024 15:20:46 +0200, Paul Nelson  said:

Paul> Thanks Robert, I've implemented your suggestions.
Paul> I hope someone will check that I've used "+++" correctly in NEWS,
Paul> affirming that I updated the documentation -- hopefully I didn't miss
Paul> anything.

Looks fine to me. I slightly adjusted your commit message and added
the bug number to it.

Closing.
Committed as 833158c0b78

Robert
-- 

bug#72487: calculator-electric-mode causes freeze on subsequent use of minibuffer

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

> Attached find a patch that should guarantee that only minibuffers are
> recorded in a minibuffer window's list of previous buffers.  A ChangeLog
> appears below.  If there are no objections, I'll install this on master
> in two weeks.

Installed on master.  If there are no further complaints, I'll close
this bug in a couple of days.

Belated and overdue thanks for the report.  I was clearly annoyed by the
fact that such stupid behavior could have crept into the code base.

martin

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

[Vincenzo Pupillo]

In data mercoledì 11 settembre 2024 06:53:32 CEST, Yuan Fu ha scritto:
> 
> > 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.

Okay, fine. But Eli said something different...
What do we do?

Vincenzo
> 
> Yuan
> 

bug#73175: 30.0.60; toggling emacs-news-view-mode doesn't remove buttons

[Robert Pluim]

src/emacs -Q etc/NEWS
C-x C-q ; buttons appear
C-x C-q ; buttons donʼt disappear

(personally I donʼt mind the buttons, but the intent of faf1f037987c
was to make them disappear).

I came up with the following, but I can never remember all the details
of text property removal (maybe we need a `button-debuttonize-region'?)

diff --git a/lisp/textmodes/emacs-news-mode.el 
b/lisp/textmodes/emacs-news-mode.el
index edeb1540feb..2cca63071b5 100644
--- a/lisp/textmodes/emacs-news-mode.el
+++ b/lisp/textmodes/emacs-news-mode.el
@@ -112,10 +112,17 @@ emacs-news--mode-common
 (define-derived-mode emacs-news-mode text-mode "NEWS"
   "Major mode for editing the Emacs NEWS file."
   ;; Disable buttons.
-  (button-mode nil)
+  (button-mode -1)
   ;; And make the buffer writable.  This is used when toggling
   ;; emacs-news-mode.
   (setq buffer-read-only nil)
+  (save-excursion
+(with-silent-modifications
+  (widen)
+  (remove-text-properties (point-min) (point-max)
+(button--properties nil nil nil))
+  (add-face-text-property (point-min) (point-max)
+  'button nil)))
   (setq-local fill-paragraph-function #'emacs-news--fill-paragraph)
   (emacs-news--mode-common))
 



In GNU Emacs 30.0.60 (build 4, x86_64-pc-linux-gnu, GTK+ Version
 3.24.38, cairo version 1.16.0) of 2024-09-05 built on rltb
Repository revision: fc7581ae2ee9db1e3189b76c66be9cd13f72f004
Repository branch: emacs-30
System Description: Debian GNU/Linux 12 (bookworm)

Robert
-- 

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

[Eli Zaretskii]

> From: Suhail Singh 
> Cc: Eli Zaretskii ,  suhailsingh...@gmail.com,
>   73...@debbugs.gnu.org
> Date: Tue, 10 Sep 2024 21:05:29 -0400
> 
> 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 think Michael just did (see below).

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

When we call sit-for, we yield the CPU for whatever other jobs are
waiting, so we don't hog the processor.

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

How would that help?  Tramp must still wait for the response to
proceed with what it does.

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

Every Lisp program runs in a single thread, so how can that be done in
parallel?

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

Emacs doesn't support parallel processing, because introducing this
into the original single-threaded design is very hard at best, due to
a huge global state.  We have Lisp threads, but only one thread can
run at any given time.

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

Thanks.

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

[Eli Zaretskii]

> From: Vincenzo Pupillo 
> Cc: Bug Report Emacs , 72...@debbugs.gnu.org
> Date: Wed, 11 Sep 2024 11:40:17 +0200
> 
> > 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.
> 
> Okay, fine. But Eli said something different...

Not necessarily.  All I said was "issue a user-friendly diagnostic".
We could output the message into *Messages*, and do it only once per
Emacs session.

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

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

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

I agree with you.  Things would have been a bit simpler, and perhaps
even friendlier, if I had stumbled upon this information right away.
I'd like to take this opportunity to address Ihor and kindly ask him
to consider reviewing and enhancing the documentation related to this
matter.

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

Looks like it works something like this:

--8<---cut here---start->8---
% ./configure --prefix=~/.local
creating cache ./config.cache
checking for a BSD compatible install... /opt/homebrew/bin/ginstall -c
checking where fonts should go... ~/.local/share/emacs/fonts
checking whether to compress fonts or not... no
checking installing font types...  pcf bdf
updating cache ./config.cache
creating ./config.status
creating Makefile
--8<---cut here---end--->8---

and then just:

--8<---cut here---start->8---
% make bdf
% ls -1 ~/.local/share/emacs/fonts/bdf | wc -l
 137
--8<---cut here---end--->8---


> And finally: the situation with ps-print wrt non-ASCII text is not a
> good one.  Even if BDF fonts still work, they are somewhat ugly, and
> are nowadays almost unsupported by systems, so it is hard to find nice
> BDF fonts.  And ps-mule doesn't support anything else.  There were
> plans to write ps-type1 to support Type1 fonts, but it never happened.

Oh my, they are indeed hideous! I suspected you were being quite
diplomatic by calling them "somewhat ugly," but I had no idea just
how bad they actually were!  It’s honestly so awful that my manager
would rather not know my weekly status than read it with these fonts

Jokes aside, the second thing I’d like to propose is to start a
discussion about reviving the Type1 font support project.  This seems
like an important and mature step forward, considering we’re in the
21st century, and the era of display resolutions reminiscent of a
microwave OLED screen is long behind us.

> Unfortunately, this basically means that any Lisp program that builds
> on ps-print will only reasonably support ASCII and Latin-1 text, the
> rest of scripts will need to use BDF fonts, and will probably not look
> very nice.  IMO, Org should document this limitation as well.

I'm curious how feasible it would be to extend Org to rework the PDF
generation flow, for example, to something like Org -> TeX -> PDF,
similar to how pandoc handles it.  This is my second question
addressed to Ihor.

> HTH, and sorry for your journey down this rabbit hole.

Thank you for your explanations and kind words of support—I really
appreciate it.

-- 
Serghei Iakovlev

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

[Eli Zaretskii]

> From: Yuan Fu 
> Date: Tue, 10 Sep 2024 22:09:04 -0700
> Cc: stefankan...@gmail.com,
>  a...@muc.de,
>  64...@debbugs.gnu.org
> 
> Done. Please take a look at the latest patch, thanks!

LGTM, but...

> +struct treesit_loaded_lang
> +{
> +  /* The language object.  */
> +  TSLanguage *lang;
> +  /* The path to the shared library.  */
> +  const char *filename;
> +};
> +

..."path" again.

> +DEFUN ("treesit-grammar-location", Ftreesit_grammar_location,
> +   Streesit_grammar_location,
> +   1, 1, 0,
> +   doc: /* Return the absolute file name of the grammar file for 
> LANGUAGE.
> +
> +If LANGUAGE isn't loaded yet, load it first.  If the langauge can't be

A typo.

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

[Eli Zaretskii]

> Date: Wed, 11 Sep 2024 10:07:21 +0200
> Cc: Eli Zaretskii , 73...@debbugs.gnu.org
> From: martin rudalics 
> 
>  > 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*.
> 
> Right.  This should probably be
> 
>if (FRAME_TERMCAP_P (f) && vpos >= FrameRows (FRAME_TTY (f)))
>  return;

That code is in update_frame_line, which is used only for TTY frames
and uses frame glyph matrices.  IOW, it updates the entire frame as a
single large window.  In addition, on a TTY terminal there's only one
frame visible at any given time, and only that one frame is being
redrawn, ever.

Given the above, why is that code incorrect?

> And it's not about resizing frames "quickly".  Here I can crash it in a
> very slow fashion too.

Good for you, but my comment describes the situation in which I saw
that particular problem.  As I already said, I can never crash Emacs
if I resize the terminal emulator window slowly.

> The cmcheckmagic code is about a very peculiar situation that is hardly
> relevant for today's terminals I think.  Here I can never crash a build
> that doesn't check assertions.

Most probably because the terminal driver simply ignores such writes.
AFAIU, the assertion there is not because of the terminal, it is there
to catch Emacs bugs.

bug#73177: 29.4; Unable to retrieve Exif data from some JPEG files

[AKIYAMA Kouhei]

exif.el does not correctly read the Exif data from some JPEG files,
which means that for example image rotation does not work properly in
image-mode.

* Issue 1: Unable to retrieve values such as orientation from Exif data
   written in Big-endian format.

Reproduction steps 1:
(The following command line creates test images using exiftool)

wget https://www.gnu.org/graphics/gnu-head.jpg
exiftool -Orientation#=6 -ExifByteOrder=Little-endian gnu-head.jpg -o 
gnu-head-le.jpg
exiftool -Orientation#=6 -ExifByteOrder=Big-endian gnu-head.jpg -o 
gnu-head-be.jpg
emacs --batch --eval "(progn (require 'exif) (princ (exif-orientation 
(exif-parse-file \"gnu-head-le.jpg\"" # => 90
emacs --batch --eval "(progn (require 'exif) (princ (exif-orientation 
(exif-parse-file \"gnu-head-be.jpg\"" # => nil (expected: 90)

Alternatively, the following expressions can be evaluated within Emacs:

  (exif-orientation (exif-parse-file "gnu-head-le.jpg")) ;; => 90
  (exif-orientation (exif-parse-file "gnu-head-be.jpg")) ;; => nil (expected: 
90)

If you view gnu-head-be.jpg in image-mode, the image will not be
rotated. If you view it in an image viewer app or web browser,
it will be rotated correctly.

Related source code location 1: (In exif.el)

  (defun exif--parse-directory (le)
  ...
for value = (exif--read-number 4 le)

For small field types, 4 bytes is too large.

(This is unrelated to the current issue, but if this part could read
triplet rational numbers such as latitude and longitude information,
the range of applications would be expanded. Currently, it can read
rational numbers, but it cannot read multiple values.)


* Issue 2: An error may occur depending on the order when non-Exif APP1
   segments exist in the file.
Reproduction steps 2-1: (When there is no Exif data and only XMP is embedded)

exiftool -xmp:creator="Etienne Suvasa" gnu-head.jpg -o gnu-head-xmp.jpg
emacs --batch --eval "(progn (require 'exif) (princ (exif-orientation 
(exif-parse-file \"gnu-head-xmp.jpg\"" # => Invalid Exif data (expected: 0)

Reproduction steps 2-2: (When XMP appears before Exif)

wget https://misohena.jp/work/emacs-exif-test/20220629_072635771_cw.jpg
emacs --batch --eval "(progn (require 'exif) (princ (exif-orientation 
(exif-parse-file \"20220629_072635771_cw.jpg\"" # => Invalid Exif data 
(expected: 90)

I'm not sure if JPEG files with XMP preceding Exif data conform to the
standard, but such files do exist in practice.

Currently, I have not found a way to generate such a JPEG file in my
environment. It may be a problem with the image conversion software I
used in the past.

Related source code location 2: (In exif.el)

  (defun exif-parse-buffer (&optional buffer)
  ...
(when-let ((app1 (cdr (assq #xffe1 (exif--parse-jpeg)
  (exif--parse-exif-chunk app1))

Only the first APP1 segment found will be used, any subsequent APP1
segments (including Exif) will be ignored.


--
In GNU Emacs 29.4 (build 2, x86_64-w64-mingw32) of 2024-07-05 built on
 AVALON
Windowing system distributor 'Microsoft Corp.', version 10.0.19045
System Description: Microsoft Windows 10 Enterprise (v10.0.2009.19045.4780)

Configured using:
 'configure --with-modules --without-dbus --with-native-compilation=aot
 --without-compress-install --with-sqlite3 --with-tree-sitter
 CFLAGS=-O2'

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

Important settings:
  value of $LANG: ja_JP.CP932
  locale-coding-system: cp932

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  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
  font-lock-mode: t
  blink-cursor-mode: 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 mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
comp comp-cstr warnings icons subr-x rx cl-seq cl-macs gv cl-extra
help-mode cl-loaddefs cl-lib bytecomp byte-compile rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils japan-util rmc iso-transl
tooltip cconv eldoc paren electric uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode mwheel 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-lo

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

[Dan Christensen]

On Sep 11, 2024, James Thomas via "Bug reports for GNU Emacs, the Swiss army 
knife of text editors"  wrote:

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

I've noticed a long-standing bug, and tried this patch.  Here's the bug:
If I use `B m' or `B c' to move or copy a message from an nnimap group
to a non-existent nnimap group, Gnus asks if I want to create the group.
I say yes, and then it gets created with some faulty parameters that
make the *Group* buffer show odd numbers:

  ("nnimap+rocky:testmove1" 3
   ((1 . 1))
   ((unexist 0) (seen 1)) "nnimap:rocky"
   ((modseq . "3") (uidvalidity . "1549221829") (active 0 . 1) (permanent-flags 
%Answered %Flagged %Deleted %Seen %Draft %*)

Note that article 0 is mentioned twice there.  If I close Gnus, get
rid of the "(unexist 0)", and change the active range to 1 . 1, then
things are good again.

I can consistently reproduce this.

I wondered if the patch in this thread would help, but after applying
it, I'm unable to create the new group in this way.  After hitting `y'
to agree to creating a new group, I get:

Debugger entered--Lisp error: (error "Couldn’t create group 
nnimap+rocky:testmove4")
  signal(error ("Couldn’t create group nnimap+rocky:testmove4"))
  error("Couldn't create group %s" "nnimap+rocky:testmove4")
  gnus-read-move-group-name("Copy" "nnimap+rocky:testmove1" (50086) "nn:")
  gnus-summary-move-article(nil nil nil copy)
  gnus-summary-copy-article(nil)
  funcall-interactively(gnus-summary-copy-article nil)
  call-interactively(gnus-summary-copy-article nil nil)
  command-execute(gnus-summary-copy-article)

So this patch makes Gnus worse for me, rather than better.  I hope this
reproducible strategy helps pin down a solution.

Dan

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]

Suhail Singh  writes:

Hi Suhail,

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

tramp-accept-process-output has seen several changes over the last 19
years. Some of them with collateral damages in edge cases, which needed
another fix then.

I'm happy it works stable now, and I'm reluctant to touch it w/o urgent
need. That's why I have used the (sit-for 0.005) solution proposed by
Eli, outside tramp-accept-process-output.

Best regards, Michael.

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]

Michael Albinus  writes:

Hi Eli,

> I made a test. In a remote directory I have created a cyclic symlink
> "zzz", in order to see what Tramp does when running dired on the
> directory. The additional actions are

[...]

> 15 times the "test -h" command - I guess, Tramp shall do cyclic link
> detection better.

I've analyzed the case in detail. Tracing file-truename and
tramp-sh-handle-file-truename.

--8<---cut here---start->8---
==
1 -> (file-truename "/ssh:gandalf:~/tmp/zzz")
| 2 -> (tramp-sh-handle-file-truename "/ssh:gandalf:~/tmp/zzz")
| 2 <- tramp-sh-handle-file-truename: !non-local\ exit!
1 <- file-truename: !non-local\ exit!
==
1 -> (file-truename "/ssh:gandalf:~/tmp/zzz")
| 2 -> (tramp-sh-handle-file-truename "/ssh:gandalf:~/tmp/zzz")
| 2 <- tramp-sh-handle-file-truename: !non-local\ exit!
1 <- file-truename: !non-local\ exit!
==
1 -> (file-truename "/ssh:gandalf:~/tmp/zzz")
| 2 -> (tramp-sh-handle-file-truename "/ssh:gandalf:~/tmp/zzz")
| 2 <- tramp-sh-handle-file-truename: !non-local\ exit!
1 <- file-truename: !non-local\ exit!
==
1 -> (file-truename "/ssh:gandalf:~/tmp/zzz")
| 2 -> (tramp-sh-handle-file-truename "/ssh:gandalf:~/tmp/zzz")
| 2 <- tramp-sh-handle-file-truename: !non-local\ exit!
1 <- file-truename: !non-local\ exit!
==
1 -> (file-truename "/ssh:gandalf:~/tmp/zzz")
| 2 -> (tramp-sh-handle-file-truename "/ssh:gandalf:~/tmp/zzz")
| 2 <- tramp-sh-handle-file-truename: !non-local\ exit!
1 <- file-truename: !non-local\ exit!
==
1 -> (file-truename "/ssh:gandalf:~/tmp/zzz")
| 2 -> (tramp-sh-handle-file-truename "/ssh:gandalf:~/tmp/zzz")
| 2 <- tramp-sh-handle-file-truename: !non-local\ exit!
1 <- file-truename: !non-local\ exit!
==
1 -> (file-truename "/ssh:gandalf:~/tmp/zzz")
| 2 -> (tramp-sh-handle-file-truename "/ssh:gandalf:~/tmp/zzz")
| 2 <- tramp-sh-handle-file-truename: !non-local\ exit!
1 <- file-truename: !non-local\ exit!
==
1 -> (file-truename "/ssh:gandalf:~/tmp/zzz")
| 2 -> (tramp-sh-handle-file-truename "/ssh:gandalf:~/tmp/zzz")
| 2 <- tramp-sh-handle-file-truename: !non-local\ exit!
1 <- file-truename: !non-local\ exit!
==
1 -> (file-truename "/ssh:gandalf:~/tmp/zzz")
| 2 -> (tramp-sh-handle-file-truename "/ssh:gandalf:~/tmp/zzz")
| 2 <- tramp-sh-handle-file-truename: !non-local\ exit!
1 <- file-truename: !non-local\ exit!
==
1 -> (file-truename "/ssh:gandalf:~/tmp/zzz")
| 2 -> (tramp-sh-handle-file-truename "/ssh:gandalf:~/tmp/zzz")
| 2 <- tramp-sh-handle-file-truename: !non-local\ exit!
1 <- file-truename: !non-local\ exit!
==
1 -> (file-truename "/ssh:gandalf:~/tmp/zzz")
| 2 -> (tramp-sh-handle-file-truename "/ssh:gandalf:~/tmp/zzz")
| 2 <- tramp-sh-handle-file-truename: !non-local\ exit!
1 <- file-truename: !non-local\ exit!
==
1 -> (file-truename "/ssh:gandalf:~/tmp/zzz")
| 2 -> (tramp-sh-handle-file-truename "/ssh:gandalf:~/tmp/zzz")
| 2 <- tramp-sh-handle-file-truename: !non-local\ exit!
1 <- file-truename: !non-local\ exit!
==
1 -> (file-truename "/ssh:gandalf:~/tmp/zzz")
| 2 -> (tramp-sh-handle-file-truename "/ssh:gandalf:~/tmp/zzz")
| 2 <- tramp-sh-handle-file-truename: !non-local\ exit!
1 <- file-truename: !non-local\ exit!
==
1 -> (file-truename "/ssh:gandalf:~/tmp/zzz")
| 2 -> (tramp-sh-handle-file-truename "/ssh:gandalf:~/tmp/zzz")
| 2 <- tramp-sh-handle-file-truename: !non-local\ exit!
1 <- file-truename: !non-local\ exit!
==
1 -> (file-truename "/ssh:gandalf:~/tmp/zzz")
| 2 -> (tramp-sh-handle-file-truename "/ssh:gandalf:~/tmp/zzz")
| 2 <- tramp-sh-handle-file-truename: !non-local\ exit!
1 <- file-truename: !non-local\ exit!
--8<---cut here---end--->8---

15 calls of file-truename (dired fontification), with 1 call of
tramp-sh-handle-file-truename each time. That sounds proper.

Tramp doesn't cache erroneous results, so it doesn't remember the
truename of "/ssh:gandalf:~/tmp/zzz". That's it, we can live with it I
guess.

Best regards, Michael.

bug#73178: 31.0.50; [PATCH] Improve the widget to customize icon

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

Hello,

Whenever I try to use Emacs' built-in icons, I have some difficulty
understanding the user interface for customizing an icon. For example,
regardless of the type of icon element, all the fields have similar
labels, which makes the interface difficult to understand and use.
For instance, for Images, it is not clear that the String field is
intended to enter the image file name:

Choice: Value Menu [Images|Colorful Emojis|Monochrome Symbols|Text only]
Repeat:
INS DEL String:
INS
Plist:
INS DEL :
Key:
Value:
INS

Also, nothing guides you regarding usage of this complex widget.

I propose the attached patch that improves the widget used to
customize an icon. Possible ChangeLog:

2024-09-11  David Ponce  

Improve usability of the widget used to customize icon.

* lisp/cus-edit.el (custom-icon--images-sub-type)
(custom-icon--emojis-sub-type, custom-icon--symbols-sub-type)
(custom-icon--texts-sub-type): New constant.
(custom-icon--type): New constant.
(custom-icon-value-create): Use it.

With this patch, a quick help summarizes usage, and the different
fields are named according to the kind of icon element.

Here is a view of the new UI when customizing the default `button' icon:

---
Hide Button:
Icon elements:
- Only the first occurrence of a same element counts.
- Missing elements will take their default value.:
- At least one element should be provided with a valid value.

INS DEL Choice: Value Menu Images:
 
 Values:

 INS DEL Image filename:
 INS
 Image attributes:
 INS DEL :
 Key: :face
 Value: icon-button
 INS

INS DEL Choice: Value Menu Colorful Emojis:
 
 Values:

 INS DEL Emoji text: 🔵
 INS
 Emoji text properties:
 INS DEL :
 Key: :face
 Value: icon
 INS

INS DEL Choice: Value Menu Monochrome Symbols:
 
 Values:

 INS DEL Symbol text: ●
 INS
 Symbol text properties:
 INS DEL :
 Key: :face
 Value: icon-button
 INS

INS DEL Choice: Value Menu Texts Only:
 
 Values:

 INS DEL Text: button
 INS
 Text properties:
 INS DEL :
 Key: :face
 Value: icon-button
 INS

INS
---

WDYT?

Thanks!


In GNU Emacs 31.0.50 (build 3, x86_64-pc-linux-gnu, GTK+ Version
 3.24.43, cairo version 1.18.0) of 2024-09-11
Repository revision: 69e1aca041c57ba425425d31471e1c8f86d3bf04
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12014000
System Description: Fedora Linux 40 (KDE Plasma)

Configured using:
 'configure --with-x-toolkit=gtk3 --with-cairo-xcb
 --with-native-compilation=no
 PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:/usr/lib/pkgconfig'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XDBE XIM XINPUT2 XPM GTK3 ZLIB

Important settings:
  value of $LC_TIME: fr_FR.utf8
  value of $LANG: fr_FR.UTF-8
  locale-coding-system: utf-8-unix
diff --git a/lisp/cus-edit.el b/lisp/cus-edit.el
index 3ab5f11532e..fd790b18630 100644
--- a/lisp/cus-edit.el
+++ b/lisp/cus-edit.el
@@ -5525,6 +5525,53 @@ custom-icon-extended-menu
   "A menu for `custom-icon' widgets.
 Used in `custom-icon-action' to show a menu to the user.")
 
+(defconst custom-icon--images-sub-type
+  '(list :format "%{%t%}:\n%v\n"
+ :tag "Images"
+ (const  :tag "" image)
+ (repeat :tag "Values"
+ (string :tag "Image filename"))
+ (plist  :tag "Image attributes")))
+
+(defconst custom-icon--emojis-sub-type
+  '(list :format "%{%t%}:\n%v\n"
+ :tag "Colorful Emojis"
+ (const  :tag "" emoji)
+ (repeat :tag "Values"
+ (string :tag "Emoji text"))
+ (plist  :tag "Emoji text properties")))
+
+(defconst custom-icon--symbols-sub-type
+  '(list :format "%{%t%}:\n%v\n"
+ :tag "Monochrome Symbols"
+ (const  :tag "" symbol)
+ (repeat :tag "Values"
+ (string :tag "Symbol text"))
+ (plist  :tag "Symbol text properties")))
+
+(defconst custom-icon--texts-sub-type
+  '(list :format "%{%t%}:\n%v\n"
+ :tag "Texts Only"
+ (const  :tag "" text)
+ (repeat :tag "Values"
+ (string :tag "Text"))
+ (plist  :tag "Text properties")))
+
+(defconst custom-icon--type
+  `(repeat :format ,(concat "%{%t%}"
+(propertize ":" 'display "")
+"\

bug#20481: 24.5; , Newlines in message-box output don't work on Windows

[Cecilio Pardo]

On 19/08/2024 19:44, Eli Zaretskii wrote:

Date: Mon, 19 Aug 2024 18:13:31 +0200
From: Cecilio Pardo 

This patch adds support on Windows Vista an later for dialog boxes using
TaskDialog.

Thanks.

First, to accept a contribution of this size we'll need a
copyright-assignment paperwork from you.  Should I send you the form
to fill with instructions to go with it, so you could start the
paperwork rolling?

A few comments about the patch:


Hello,

The copyright assignment is ready. Here is the patch with your

comments addressed. I also attach a couple of manual tests.


--

Cecilio Pardo



diff --git a/src/menu.c b/src/menu.c
index de4d0964e9c..6b4aaef1715 100644
--- a/src/menu.c
+++ b/src/menu.c
@@ -1594,9 +1594,10 @@ DEFUN ("x-popup-dialog", Fx_popup_dialog, 
Sx_popup_dialog, 2, 3, 0,
   Lisp_Object selection
= FRAME_TERMINAL (f)->popup_dialog_hook (f, header, contents);
 #ifdef HAVE_NTGUI
-  /* NTGUI supports only simple dialogs with Yes/No choices.  For
-other dialogs, it returns the symbol 'unsupported--w32-dialog',
-as a signal for the caller to fall back to the emulation code.  */
+  /* NTGUI on Windows versions before Vista supports only simple
+dialogs with Yes/No choices.  For other dialogs, it returns the
+symbol 'unsupported--w32-dialog', as a signal for the caller to
+fall back to the emulation code.  */
   if (!EQ (selection, Qunsupported__w32_dialog))
 #endif
return selection;
diff --git a/src/w32menu.c b/src/w32menu.c
index cea4f4892a4..3c7ebf64abe 100644
--- a/src/w32menu.c
+++ b/src/w32menu.c
@@ -52,6 +52,9 @@
 
 #include "w32common.h" /* for osinfo_cache */
 
+#include "commctrl.h"
+
+/* This only applies to OS versions prior to Vista.  */
 #undef HAVE_DIALOGS /* TODO: Implement native dialogs.  */
 
 #ifndef TRUE
@@ -76,6 +79,11 @@ #define FALSE 0
 IN const WCHAR *text,
 IN const WCHAR *caption,
 IN UINT type);
+typedef HRESULT (WINAPI *TaskDialogIndirect_Proc) (
+IN const TASKDIALOGCONFIG *pTaskConfig,
+OUT int *pnButton,
+OUT int *pnRadioButton,
+OUT BOOL *pfVerificationFlagChecked);
 
 #ifdef NTGUI_UNICODE
 GetMenuItemInfoA_Proc get_menu_item_info = GetMenuItemInfoA;
@@ -89,6 +97,8 @@ #define FALSE 0
 MessageBoxW_Proc unicode_message_box = NULL;
 #endif /* NTGUI_UNICODE */
 
+TaskDialogIndirect_Proc task_dialog_indirect;
+
 #ifdef HAVE_DIALOGS
 static Lisp_Object w32_dialog_show (struct frame *, Lisp_Object, Lisp_Object, 
char **);
 #else
@@ -101,14 +111,155 @@ #define FALSE 0
 
 void w32_free_menu_strings (HWND);
 
+#define TASK_DIALOG_MAX_BUTTONS 10
+
+static HRESULT
+task_dialog_callback (HWND hwnd, UINT msg, WPARAM wParam,
+ LPARAM lParam, LONG_PTR callback_data)
+{
+  switch (msg)
+{
+case TDN_CREATED:
+  /* Disable all buttons with ID >= 2000  */
+  for (int i = 0; i < TASK_DIALOG_MAX_BUTTONS; i++)
+SendMessage (hwnd, TDM_ENABLE_BUTTON, 2000 + i, FALSE);
+  break;
+}
+  return S_OK;
+}
+
 Lisp_Object
 w32_popup_dialog (struct frame *f, Lisp_Object header, Lisp_Object contents)
 {
-
   check_window_system (f);
 
-#ifndef HAVE_DIALOGS
+  if (task_dialog_indirect)
+{
+  int wide_len;
+
+  CHECK_CONS (contents);
 
+  /* Get the title as an UTF-16 string.  */
+  char *title = SSDATA (ENCODE_UTF_8 (XCAR (contents)));
+  wide_len = sizeof (WCHAR) *
+   pMultiByteToWideChar (CP_UTF8, 0, title, -1, NULL, 0);
+  WCHAR *title_w = alloca (wide_len);
+  pMultiByteToWideChar (CP_UTF8, 0, title, -1, title_w, wide_len);
+
+  /* Prepare the arrays with the dialog's buttons and return values.  */
+  TASKDIALOG_BUTTON buttons[TASK_DIALOG_MAX_BUTTONS];
+  Lisp_Object button_values[TASK_DIALOG_MAX_BUTTONS];
+  int button_count = 0;
+  Lisp_Object b = XCDR (contents);
+
+  while (!NILP (b)) {
+   if (button_count >= TASK_DIALOG_MAX_BUTTONS)
+ {
+   /* We have too many buttons. We ignore the rest.  */
+   break;
+ }
+
+   Lisp_Object item = XCAR (b);
+
+   if (Fconsp (item))
+ {
+   /* A normal item (text . value)  */
+   Lisp_Object item_name = XCAR (item);
+   Lisp_Object item_value = XCDR (item);
+
+   CHECK_STRING (item_name);
+
+   item_name = ENCODE_UTF_8 (item_name);
+   wide_len = sizeof (WCHAR) *
+ pMultiByteToWideChar (CP_UTF8, 0, SSDATA (item_name),
+   -1, NULL, 0);
+   buttons[button_count].pszButtonText = alloca (wide_len);
+   pMultiByteToWideChar (CP_UTF8, 0, SSDATA (item_name), -1,
+ (LPWSTR)
+ buttons[button_count].pszButtonText,
+ wide_len);
+   buttons[button_count].nButtonID = 1000 + button_count;
+   button_values[button_count++] = item_value;
+ }
+   else if (NILP (item))
+ {
+

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

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

>>   > 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*.
>>
>> Right.  This should probably be
>>
>> if (FRAME_TERMCAP_P (f) && vpos >= FrameRows (FRAME_TTY (f)))
>>   return;
>
> That code is in update_frame_line, which is used only for TTY frames
> and uses frame glyph matrices.  IOW, it updates the entire frame as a
> single large window.  In addition, on a TTY terminal there's only one
> frame visible at any given time, and only that one frame is being
> redrawn, ever.
>
> Given the above, why is that code incorrect?

It _might_ be incorrect when we allow FRAME_TOTAL_LINES (f) to exceed
FrameRows (FRAME_TTY (f)) because we refuse to shrink a frame below some
height.  That's why I used the term "probably".  If I knew what that
code does in all consequences, I could tell you more.  But I don't know.

>> And it's not about resizing frames "quickly".  Here I can crash it in a
>> very slow fashion too.
>
> Good for you, but my comment describes the situation in which I saw
> that particular problem.  As I already said, I can never crash Emacs
> if I resize the terminal emulator window slowly.

And as I already said I can crash Emacs reliably if I slowly shrink the
window, slowly expand it again, precisely at the moment it should reshow
the minibuffer window.  You can ask me any question about the state of
the frame and its windows at the time of the crash.

> Most probably because the terminal driver simply ignores such writes.
> AFAIU, the assertion there is not because of the terminal, it is there
> to catch Emacs bugs.

Then tell us how to catch it.  I'm already out of ideas.

martin

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

[Eli Zaretskii]

> Date: Wed, 11 Sep 2024 16:37:58 +0200
> Cc: n142...@gmail.com, 73...@debbugs.gnu.org
> From: martin rudalics 
> 
>  >>   > 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*.
>  >>
>  >> Right.  This should probably be
>  >>
>  >> if (FRAME_TERMCAP_P (f) && vpos >= FrameRows (FRAME_TTY (f)))
>  >>   return;
>  >
>  > That code is in update_frame_line, which is used only for TTY frames
>  > and uses frame glyph matrices.  IOW, it updates the entire frame as a
>  > single large window.  In addition, on a TTY terminal there's only one
>  > frame visible at any given time, and only that one frame is being
>  > redrawn, ever.
>  >
>  > Given the above, why is that code incorrect?
> 
> It _might_ be incorrect when we allow FRAME_TOTAL_LINES (f) to exceed
> FrameRows (FRAME_TTY (f)) because we refuse to shrink a frame below some
> height.  That's why I used the term "probably".  If I knew what that
> code does in all consequences, I could tell you more.  But I don't know.

If FRAME_TOTAL_LINES is different from FrameRows at that spot, it's a
bug, isn't it?

The reason I didn't want to depend on FrameRows is that it might be
modified by a signal handler, and I couldn't convince myself that they
will always be in sync when we get to that spot.  FRAME_TOTAL_LINES is
the result of us adjusting the frame size when it's safe to do so, and
it sounded like a better idea to me.

>  >> And it's not about resizing frames "quickly".  Here I can crash it in a
>  >> very slow fashion too.
>  >
>  > Good for you, but my comment describes the situation in which I saw
>  > that particular problem.  As I already said, I can never crash Emacs
>  > if I resize the terminal emulator window slowly.
> 
> And as I already said I can crash Emacs reliably if I slowly shrink the
> window, slowly expand it again, precisely at the moment it should reshow
> the minibuffer window.  You can ask me any question about the state of
> the frame and its windows at the time of the crash.

I still don't understand what is supposed to happen when we shrink the
frame to less lines/columns than the minimum window dimensions we
allow.  Also, I'd be happier if you could describe the sequence of
events that lead to frame and window resizing following a SIGWINCH.

>  > Most probably because the terminal driver simply ignores such writes.
>  > AFAIU, the assertion there is not because of the terminal, it is there
>  > to catch Emacs bugs.
> 
> Then tell us how to catch it.  I'm already out of ideas.

Maybe later, when I have more time to think about this.

bug#73178: 31.0.50; [PATCH] Improve the widget to customize icon

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

Attached the correct patch.
Sorrydiff --git a/lisp/cus-edit.el b/lisp/cus-edit.el
index 3ab5f11532e..fd790b18630 100644
--- a/lisp/cus-edit.el
+++ b/lisp/cus-edit.el
@@ -5525,6 +5525,53 @@ custom-icon-extended-menu
   "A menu for `custom-icon' widgets.
 Used in `custom-icon-action' to show a menu to the user.")
 
+(defconst custom-icon--images-sub-type
+  '(list :format "%{%t%}:\n%v\n"
+ :tag "Images"
+ (const  :tag "" image)
+ (repeat :tag "Values"
+ (string :tag "Image filename"))
+ (plist  :tag "Image attributes")))
+
+(defconst custom-icon--emojis-sub-type
+  '(list :format "%{%t%}:\n%v\n"
+ :tag "Colorful Emojis"
+ (const  :tag "" emoji)
+ (repeat :tag "Values"
+ (string :tag "Emoji text"))
+ (plist  :tag "Emoji text properties")))
+
+(defconst custom-icon--symbols-sub-type
+  '(list :format "%{%t%}:\n%v\n"
+ :tag "Monochrome Symbols"
+ (const  :tag "" symbol)
+ (repeat :tag "Values"
+ (string :tag "Symbol text"))
+ (plist  :tag "Symbol text properties")))
+
+(defconst custom-icon--texts-sub-type
+  '(list :format "%{%t%}:\n%v\n"
+ :tag "Texts Only"
+ (const  :tag "" text)
+ (repeat :tag "Values"
+ (string :tag "Text"))
+ (plist  :tag "Text properties")))
+
+(defconst custom-icon--type
+  `(repeat :format ,(concat "%{%t%}"
+(propertize ":" 'display "")
+"\n\n%v%i\n")
+   :tag "Icon elements:
+- Only the first occurrence of a same element counts.
+- Missing elements will take their default value.
+- At least one element should be provided with a valid value."
+(choice :void ,custom-icon--texts-widget
+:extra-offset -3
+,custom-icon--images-sub-type
+,custom-icon--emojis-sub-type
+,custom-icon--symbols-sub-type
+,custom-icon--texts-sub-type)))
+
 (defun custom-icon-value-create (widget)
   "Here is where you edit the icon's specification."
   (custom-load-widget widget)
@@ -5535,13 +5582,7 @@ custom-icon-value-create
 	 (form (widget-get widget :custom-form))
 	 (symbol (widget-get widget :value))
 	 (tag (widget-get widget :tag))
-	 (type '(repeat
- (list (choice (const :tag "Images" image)
-   (const :tag "Colorful Emojis" emoji)
-   (const :tag "Monochrome Symbols" symbol)
-   (const :tag "Text Only" text))
-   (repeat string)
-   plist)))
+	 (type custom-icon--type)
 	 (prefix (widget-get widget :custom-prefix))
 	 (last (widget-get widget :custom-last))
 	 (style (widget-get widget :custom-style))

bug#73178: 31.0.50; [PATCH] Improve the widget to customize icon

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

On 11/09/2024 5:19 PM, David Ponce wrote:

Attached the correct patch.
Sorry

Should be the good one this time.
Sorry again.diff --git a/lisp/cus-edit.el b/lisp/cus-edit.el
index 3ab5f11532e..fd790b18630 100644
--- a/lisp/cus-edit.el
+++ b/lisp/cus-edit.el
@@ -5525,6 +5525,53 @@ custom-icon-extended-menu
   "A menu for `custom-icon' widgets.
 Used in `custom-icon-action' to show a menu to the user.")
 
+(defconst custom-icon--images-sub-type
+  '(list :format "%{%t%}:\n%v\n"
+ :tag "Images"
+ (const  :tag "" image)
+ (repeat :tag "Values"
+ (string :tag "Image filename"))
+ (plist  :tag "Image attributes")))
+
+(defconst custom-icon--emojis-sub-type
+  '(list :format "%{%t%}:\n%v\n"
+ :tag "Colorful Emojis"
+ (const  :tag "" emoji)
+ (repeat :tag "Values"
+ (string :tag "Emoji text"))
+ (plist  :tag "Emoji text properties")))
+
+(defconst custom-icon--symbols-sub-type
+  '(list :format "%{%t%}:\n%v\n"
+ :tag "Monochrome Symbols"
+ (const  :tag "" symbol)
+ (repeat :tag "Values"
+ (string :tag "Symbol text"))
+ (plist  :tag "Symbol text properties")))
+
+(defconst custom-icon--texts-sub-type
+  '(list :format "%{%t%}:\n%v\n"
+ :tag "Texts Only"
+ (const  :tag "" text)
+ (repeat :tag "Values"
+ (string :tag "Text"))
+ (plist  :tag "Text properties")))
+
+(defconst custom-icon--type
+  `(repeat :format ,(concat "%{%t%}"
+(propertize ":" 'display "")
+"\n\n%v%i\n")
+   :tag "Icon elements:
+- Only the first occurrence of a same element counts.
+- Missing elements will take their default value.
+- At least one element should be provided with a valid value."
+(choice :void ,custom-icon--texts-sub-type
+:extra-offset -3
+,custom-icon--images-sub-type
+,custom-icon--emojis-sub-type
+,custom-icon--symbols-sub-type
+,custom-icon--texts-sub-type)))
+
 (defun custom-icon-value-create (widget)
   "Here is where you edit the icon's specification."
   (custom-load-widget widget)
@@ -5535,13 +5582,7 @@ custom-icon-value-create
 	 (form (widget-get widget :custom-form))
 	 (symbol (widget-get widget :value))
 	 (tag (widget-get widget :tag))
-	 (type '(repeat
- (list (choice (const :tag "Images" image)
-   (const :tag "Colorful Emojis" emoji)
-   (const :tag "Monochrome Symbols" symbol)
-   (const :tag "Text Only" text))
-   (repeat string)
-   plist)))
+	 (type custom-icon--type)
 	 (prefix (widget-get widget :custom-prefix))
 	 (last (widget-get widget :custom-last))
 	 (style (widget-get widget :custom-style))

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

[Suhail Singh]

Michael Albinus  writes:

> I'm happy it works stable now, and I'm reluctant to touch it w/o urgent
> need. That's why I have used the (sit-for 0.005) solution proposed by
> Eli, outside tramp-accept-process-output.

Understood; thanks for elaborating.

-- 
Suhail

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]

Michael Albinus  writes:

Hi,

>> I should be able to test out the patch later this coming week.  In case
>> that would be helpful, please let me know.  Thank you for adding this.
>
> Yes, please do. I will also wait for Eli's OK, and then I will push it
> to the master branch. Plus little bit of doc in the Emacs and Tramp
> manuals.

Oops, I've been over-eager. Pushed already everything to master.

Pls send further comments, if any. Otherwise, I'll close the bug in a
couple of days.

Best regards, Michael.

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

[Suhail Singh]

Eli Zaretskii  writes:

>> 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.
>
> How would that help?  Tramp must still wait for the response to
> proceed with what it does.
>
>> 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)?
>
> Every Lisp program runs in a single thread, so how can that be done in
> parallel?
>
>> 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)?
>
> Emacs doesn't support parallel processing, because introducing this
> into the original single-threaded design is very hard at best, due to
> a huge global state.  We have Lisp threads, but only one thread can
> run at any given time.

I was imagining a version of TRAMP that was asynchronous.  I understand
now that it isn't.

-- 
Suhail

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]

Suhail Singh  writes:

Hi Suhail,

> I was imagining a version of TRAMP that was asynchronous.  I understand
> now that it isn't.

FTR, some years ago (2018?) I tried to use Lisp threads with Tramp. This
experiment failed.

Best regards, Michael.

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

[Suhail Singh]

Michael Albinus  writes:

> FTR, some years ago (2018?) I tried to use Lisp threads with Tramp. This
> experiment failed.

OOC, the failure was from hard-to-debug edge cases while trying to get
to feature-parity or something else?

-- 
Suhail

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

[mail]

Wow, thank you so much for diving into this issue! I'll keep track of it in 
tree-sitter repo from now on.

It seems like other integrations somehow manage to avoid hanging or crashing 
the main process, so it doesn't affect them?

I just checked in the Zed editor again to confirm. When I type a={, it fails to 
highlight the rest of the embedded HEEX (but only within the current function) 
though.


> On Sep 11, 2024, at 7:45 AM, Yuan Fu  wrote:
> 
> 
> 
>> 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#73098: setopt float warning unexpected

[Stefan Kangas]

Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of
text editors"  writes:

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

+1

bug#72254: 29.4; Cannot yank media when image come from Gnome-shell screenshot

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

Andrea Corallo  writes:

> Eli Zaretskii  writes:
>
>>> From: Po Lu 
>>> Cc: rpl...@gmail.com,  72...@debbugs.gnu.org,  s...@k-7.ch,  
>>> visuwe...@gmail.com
>>> Date: Wed, 21 Aug 2024 10:37:50 +0800
>>> 
>>> I was preparing to install this patch when I noticed that commits for
>>> the pretest had been created but that the pretest had yet to be
>>> released.  Perhaps this should be postponed till Andrea puts the tarball
>>> out, am I correct?
>>
>> That's up to Andrea (CC'ed), it depends on where did he pause the
>> make-tarball procedure.
>
> I suggest bugfixing on the branch happens indipendently of the release
> process, I'm not bothered if commits are installed (worst case they will
> not be included in the pretest).
>
>   Andrea

Now installed (most belatedly, because I lost this e-mail).

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]

Dan Christensen wrote:

> On Sep 11, 2024, James Thomas via "Bug reports for GNU Emacs, the
> Swiss army knife of text editors"  wrote:
>
>> 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?
>
> I've noticed a long-standing bug, and tried this patch.  Here's the bug:
> If I use `B m' or `B c' to move or copy a message from an nnimap group
> to a non-existent nnimap group, Gnus asks if I want to create the group.
> I say yes, and then it gets created with some faulty parameters that
> make the *Group* buffer show odd numbers:
>
>   ("nnimap+rocky:testmove1" 3
>((1 . 1))
>((unexist 0) (seen 1)) "nnimap:rocky"
>((modseq . "3") (uidvalidity . "1549221829") (active 0 . 1) 
> (permanent-flags %Answered %Flagged %Deleted %Seen %Draft %*)
>
> Note that article 0 is mentioned twice there.  If I close Gnus, get
> rid of the "(unexist 0)", and change the active range to 1 . 1, then
> things are good again.
>
> I can consistently reproduce this.
>
> I wondered if the patch in this thread would help, but after applying
> it, I'm unable to create the new group in this way.  After hitting `y'
> to agree to creating a new group, I get:
>
> Debugger entered--Lisp error: (error "Couldn’t create group 
> nnimap+rocky:testmove4")
>   signal(error ("Couldn’t create group nnimap+rocky:testmove4"))
>   error("Couldn't create group %s" "nnimap+rocky:testmove4")
>   gnus-read-move-group-name("Copy" "nnimap+rocky:testmove1" (50086) "nn:")
>   gnus-summary-move-article(nil nil nil copy)
>   gnus-summary-copy-article(nil)
>   funcall-interactively(gnus-summary-copy-article nil)
>   call-interactively(gnus-summary-copy-article nil nil)
>   command-execute(gnus-summary-copy-article)
>
> So this patch makes Gnus worse for me, rather than better.  I hope this
> reproducible strategy helps pin down a solution.

Sorry! I got confused again... Please try the other patch in that bug
report (the one that swaps the car and cdr). I find that it works with
your use case!

--

bug#20481: 24.5; , Newlines in message-box output don't work on Windows

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

Cecilio Pardo  writes:

> On 19/08/2024 19:44, Eli Zaretskii wrote:
>>> Date: Mon, 19 Aug 2024 18:13:31 +0200
>>> From: Cecilio Pardo 
>>>
>>> This patch adds support on Windows Vista an later for dialog boxes using
>>> TaskDialog.
>> Thanks.
>>
>> First, to accept a contribution of this size we'll need a
>> copyright-assignment paperwork from you.  Should I send you the form
>> to fill with instructions to go with it, so you could start the
>> paperwork rolling?
>>
>> A few comments about the patch:
>
> Hello,
>
> The copyright assignment is ready. Here is the patch with your
>
> comments addressed. I also attach a couple of manual tests.
>

Thanks.  Following are a number of minor stylistic comments.

> +  while (!NILP (b)) {

Please insert a newline before this opening brace and indent the same by
one column.

> + if (Fconsp (item))

  "if (CONSP (item))"

> + wide_len = sizeof (WCHAR) *
> +   pMultiByteToWideChar (CP_UTF8, 0, SSDATA (item_name),
> + -1, NULL, 0);

Please enclose this expression in parens and break it before the
operator, thus:

  (sizeof (WCHAR)
   * pMultiByteToWideChar (CP_UTF8, 0, SSDATA (...), ...))

> +   {
> + /* A nil item means to put all following items on the
> +right. We ignore this.  */
> +   }

[...]

> + else if (STRINGP (item))
> +   {
> + /* A string item means an unselectable button. We add a
> +button, an then need to disable it on the callback.
> +We use ids based on 2000 to mark these buttons.  */

Please insert two spaces after sentence stops.

> + Lisp_Object item_name = ENCODE_UTF_8 (item);
> + wide_len = sizeof (WCHAR) *
> +   pMultiByteToWideChar (CP_UTF8, 0, SSDATA (item_name),
> + -1, NULL, 0);

What I said about wrapping long expressions also applies here.

> +  TASKDIALOGCONFIG config = { };

  TASKDIALOGCONFIG config = { 0 };

> +  if (!SUCCEEDED (task_dialog_indirect (&config, &pressed_button,
> + NULL, NULL)))
> + return quit ();

This return statement is redundant.

Lastly, I observe that you have implemented a bespoke dialog parser for
Windows, the likes of which have been a source of difficulties in the
past.  Is there any particular reason that you decided against
implementing the w32_dialog_show function called in the "#ifdef
HAVE_DIALOGS" version of w32_popup_dialog?

bug#73191: 30.0.91; missing some keywords in c++-ts-mode

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

Some keywords are missing in `c++-ts-mode`, compared to `c++-mode` (defined
in `cc-langs.el`), notably: "virtual," "thread_local," and maybe others.


Regargs
yang

bug#73191: Acknowledgement (30.0.91; missing some keywords in c++-ts-mode)

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

On Thu, Sep 12 2024, GNU bug Tracking System wrote:

Update: `virtual` works fine, only `thread_local` is not highlighted...

> Thank you for filing a new bug report with debbugs.gnu.org.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  bug-gnu-emacs@gnu.org
>
> If you wish to submit further information on this problem, please
> send it to 73...@debbugs.gnu.org.
>
> Please do not send mail to help-debb...@gnu.org unless you wish
> to report a problem with the Bug-tracking system.