bug#73023: Obsolete documentation on insert-in-front-hooks (GNU Emacs 29.4)

[Rodrigo Morales]

Rodrigo Morales  writes:

> I believe that the part "these functions receive two arguments, the
> beginning and end of the inserted text." is obsolete because functions
> in insert-in-front-hooks are passed 4 parameters. In the code block
> below, you can see a correct function definition for
> insert-in-front-hooks. The two code block shown below were retrieved
> from the file ./lisp/progmodes/cpp.el

When I wrote this bug report, I wasn't aware about the difference
between text properties and overlay properties. I thought that all
properties that can be used on text can also be used on overlays, now I
know that I'm wrong. Please omit this bug report.

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]

Sorry, my last mail went at the wrong address.  Reposting.

> In particular, I found a case in which an assert fails because the
> window row glyph memory is not contained in the frame row glyph
> memory.
>
> It happens in a recent build (99a03ddb2d4) built without X support.
> I'm running it in a urxvt terminal but it happens in xterm too. It
> crashes both with and without glyph debug. This is not related to
> garbage collection like bug 71289.
>
> To reproduce:
> 1. Open emacs -Q
> 2. Press C-x 2 to split the frame (top/bottom)
> 3. Make the terminal very small (I slowly resize the X window that's
> running urxvt, to the minimum size, 1 row and 2 columns in my case).
> This shrinking process alone can produce the crash when the window is
> around 5 lines high
> 4. It always crashes in my case. If it doesn't, make the terminal
> larger again, and repeat the resizing for some seconds until it
> crashes
>
> Note that the C-x 2 is required. The problem doesn't happen with a
> left/right split (C-x 3). But it happens after a C-x 3 C-x 2.

Kindly have a look at the fix I proposed here:

https://lists.gnu.org/archive/html/emacs-devel/2024-09/msg00054.html

If necessary, I can send you a patch.

Thanks, martin

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

[Paul Nelson]

Hi Robert,

> The functionality seems useful. I wonder if it makes more sense to
> have them triggered by the prefix arg, eg "C-u b", "C-u a b",
> etc. rather than having to keep Ctrl pressed.
>
> Robert
> --

Many thanks for your suggestion.  I agree that this is a more elegant
approach, which also admits a simpler implementation.  I've attached
my revised patch.  Any further feedback welcome.

Thanks, best,

Paul


0001-Add-Ediff-feature-for-copying-all-differences.patch
Description: Binary data

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

[mail]

I can confirm that I never had such problems in heex-ts-mode but only with 
inline heex in elixir-ts-mode.

> On Sep 4, 2024, at 10:39 AM, Wilhelm Kirschbaum  wrote:
> 
> 
> 
> On Thu, Aug 29, 2024 at 8:14 AM Yuan Fu  > wrote:
>> 
>> 
>> > On Aug 28, 2024, at 10:09 PM, Eli Zaretskii > > > wrote:
>> > 
>> >> From: m...@ssbb.me 
>> >> Date: Thu, 29 Aug 2024 06:57:38 +0400
>> >> 
>> >> Code in attached file cause Emacs to hang and memory leak infinitely
>> >> while editing. Try to open this code in elixir-ts-mode and move cursor
>> >> on line 6 (between <:loading>  ) and type char by char:
>> >> 
>> >> <.some_component a={
>> >> 
>> >> (for some reason it does not happen with electric-pair-mode when {}
>> >> inserted automatically).
>> >> 
>> >> I am able to reproduce this with -Q on few different machines (Linux and
>> >> MacOS) and Emacs 29, 30.0.5 and current HEAD.
>> >> 
>> >> C-g does nothing (including with debug-on-quit and sending SIGUSR2)
>> >> 
>> >> At the same time I can't reproduce this in other tree-sitter based 
>> >> editors.
>> >> 
>> >> I got this sample code sample from elixir-ts-mode repo but now it's moved
>> >> to the Emacs core so seems to be out of scope of Github repo issues.
>> >> 
>> >> Attaching samle code and LLDB backtrace. 
>> >> Also attaching report from built-in MacOS crash reporting tool just in 
>> >> case.
>> > 
>> > Thanks.
>> > 
>> > Wilhelm and Yuan, could you please look into this soon?
>> 
>> That’s bizarre, might have some bug around ranges. I’m looking into this. 
>> Hopefully I can figure it out in a few days :-(
>> 
>> Yuan
> 
> I can reproduce the issue by following the above instructions, but need to do 
> some digging. It only seems to be the case with embedded heex and not with 
> heex-ts-mode by itself.
> 
> WIlhelm
> 
> 
> 

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

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

>> Thanks.  The geometry values are consistent with what you described.
>> This seems to be Bug#67654 and Bug#68463 and possibly Bug#65559.  When
>> you run Emacs from a console or under gdb can you observe whether it
>> triggers a
>>
>> gtk_distribute_natural_allocation: assertion 'extra_space >= 0' failed
>>
>
> Yes, both with Emacs 29 and git master produce this message when
> menu-bar-mode is non-nil, and the menu bar is drawn, in both window sizes
> (the normal sized window, and the strangely small one).

But you can't see this message when building with gtk-2 I presume.

> The one really notable difference to the above bugs is that the 29
>> version makes a shrunk frame only after you've removed the menubar while
>> master makes a shrunk frame immediately.  Are the GTK versions of the
>> Emacs 29 build and the master build the same?
>>
>
> Yes, they are identical: gtk 3.24.41, Ubuntu build.

This strongly hints that there was an Emacs change affecting gtk-2 _and_
gtk-3 builds in between 29 and master.  I could imagine that commit

e087c89b1e243bbd941a4a50b4bf99613e13d016

is involved but if you could try to bisect, it would be of great help.

> Just to make sure one thing: Would setting
>> 'frame-resize-pixelwise' to t change anything?
>>
>
> So, I did (setq frame-resize-pixelwise t), then disabled menu-bar-mode (in
> Emacs 29), then C-x 5 2 (in both Emacs 29 & git master), and the new window
> was small, just as before. It seems therefore to make no difference.

Which should eliminate the possibility that our size hints are
responsible.  IIRC mutter is very severe when size hints are not set up
correctly.

> Otherwise I would try to build Emacs with gtk2, lucid or motif.
>
>
> I tried building Emacs git master with gtk2, and it doesn't fix the
> problem: the second window opened is slightly smaller than before (i.e.
> very small indeed).

This would eliminate earlier conjectures that changes from one gtk-3
version to another would be responsible.  And it would exclude
emacsgtkfixed.c as possible culprit.

> Building with lucid does fix the problem (both with menu-bar-mode enabled,
> and disabled).

I suppose that all these problems happen when requests travel from GTK
to mutter and back.  Basically, mutter is not obliged to fulfill any
size or position request for any top-level (non-child frame).  BTW,
could you try adding a (user-size . t) member to 'default-frame-alist'?
And could you try doing that from an 'early-init.el' file?

martin

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

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

> Isn't it true that disabling menu-bar-mode from the init file avoids
> these problems?

In Reuben's second scenario 'menu-bar-mode' is not disabled.  The second
frame is smaller with the menu bar enabled.

martin

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

[Madhu]

No problem,
*  Michael Heerdegen  <87seug85hh@web.de>
Wrote on Wed, 04 Sep 2024 05:25:46 +0200
> Could you please post a recipe and a backtrace for this second problem?

```
emacs -Q -l f.el
```

produces the backtrace in the file backtrace.txt with the match-data
clobbered error. At this point (i.e. after the error occurs) if I do
"M-x load-library wdired", then a subsequent replace-regexp operation
succeeds.  However in a long running emacs I believe I still see the
match-data clobbered error crops up again, I'm keeping a lookout on
what might be triggering that.


Debugger entered--Lisp error: (error "Match data clobbered by buffer 
modification hooks")
  replace-match("bar" nil nil)
  replace-match-maybe-edit("bar" nil nil nil (170 173 #) nil)
  perform-replace("foo" "bar" nil t nil nil nil nil nil nil nil)
  replace-regexp("foo" "bar")
  eval-buffer(# nil "/dev/shm/f.el" nil t)  ; Reading at buffer 
position 359
  load-with-code-conversion("/dev/shm/f.el" "/dev/shm/f.el" nil t)
  load("/dev/shm/f.el" nil t)
  command-line-1(("-l" "/dev/shm/f.el"))
  command-line()
  normal-top-level()
(setq $test-foo-dir "/tmp/test-foo/")
(ignore-errors (make-directory $test-foo-dir))
(ignore-errors
  (loop for i below 40
for target = (format "/foo/%d" i)
for link-name = (format "%s%d" $test-foo-dir i)
do (make-symbolic-link target link-name)))
(dired $test-foo-dir)
(wdired-change-to-wdired-mode)
(load-library "wdired")
(toggle-debug-on-error t)
(replace-regexp "foo" "bar")

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

[Madhu]

*  Madhu  
<20240904.142831.1583368143272051709.enom...@meer.net>
Wrote on Wed, 04 Sep 2024 14:28:31 +0530 (IST)
> produces the backtrace in the file backtrace.txt with the match-data
> clobbered error. At this point (i.e. after the error occurs) if I do
> "M-x load-library wdired", then a subsequent replace-regexp operation
> succeeds.  However in a long running emacs I believe I still see the
> match-data clobbered error crops up again, I'm keeping a lookout on
> what might be triggering that.

I think this error goes away with an ;;;###autoload cookie for
wdired--before-change-fn in wdired.el

(The actual sequence of events is obscure)

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

[Eli Zaretskii]

> From: Philip Kaludercic 
> Cc: spwhit...@spwhitton.name,  stefankan...@gmail.com,  acora...@gnu.org,
>   j...@linkov.net,  r...@gnu.org,  69...@debbugs.gnu.org
> Date: Tue, 03 Sep 2024 16:32:46 +
> 
> I've added the NEWS entry from the last iteration of the patch (now
> actually as a patch, not just a diff):

Thanks.

> +---
> +** New user option 'kill-word-if-no-region'.
   ^^
This is not the right name...

> +(defcustom kill-region-dwim nil
> +  "Behaviour when `kill-region' is invoked without an active region.
> +If set to nil (default), then an error occurs and nothing is killed.  If
> +set to `emacs-word', then kill a the last word as defined by the current
 ^^
The "a" part should be removed.

> +major mode.  If set to `unix-word', then kill the last word in the style
> +of a shell like Bash, disregarding the major mode."
> +  :type '(choice (const :tag "Kill a word like `backward-kill-word'" 
> emacs-word)
> + (const :tag "Kill a word like Bash would" unix-word)
> + (const :tag "Do not kill anything" nil))
> +  :group 'killing)

:version still missing.

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

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

On Wed, 4 Sept 2024 at 09:02, martin rudalics  wrote:

>  >>
>  >> gtk_distribute_natural_allocation: assertion 'extra_space >= 0' failed
>  >>
>  >
>  > Yes, both with Emacs 29 and git master produce this message when
>  > menu-bar-mode is non-nil, and the menu bar is drawn, in both window
> sizes
>  > (the normal sized window, and the strangely small one).
>
> But you can't see this message when building with gtk-2 I presume.
>

That's correct, no message with gtk-2.

This strongly hints that there was an Emacs change affecting gtk-2 _and_
> gtk-3 builds in between 29 and master.  I could imagine that commit
>
> e087c89b1e243bbd941a4a50b4bf99613e13d016
>
> is involved but if you could try to bisect, it would be of great help.
>

Just to check, you're suggesting that I bisect from emacs-29.3 (I use that
tag because it's what the version of 29 I'm using is built from) to master
HEAD, to find at which commit C-x 5 2 opens a small window immediately
(without disabling menu-bar-mode)?

BTW, could you try adding a (user-size . t) member to 'default-frame-alist'?
> And could you try doing that from an 'early-init.el' file?
>

This made no difference. I added just:

(add-to-list 'default-frame-alist '(user-size . t))

to ~/.config/emacs/early-init.el

Then I ran each Emacs with just "emacs", confirmed that default-frame-alist
was set, then disabled menu-bar-mode (Emacs 29 only), then C-x 5 2. In each
case a small window was opened as before.

-- 
https://rrt.sc3d.org

bug#66068: 30.0.50; xwidget-webkit-browse-url makes Emacs abort

[Peter Oliver]

If my understanding of this bug is correct, newer versions of WebKitGTK 
reliably crash Emacs, and no-one has been in touch with the WebKitGTK 
developers, so there are no plans to fix that.

If that’s the case, how about this attached patch to disable this feature with 
problematic versions of the library?

--
Peter OliverFrom 262ea1bb8c47f703819f2df4d920a1f15f2c35b9 Mon Sep 17 00:00:00 2001
From: Peter Oliver 
Date: Wed, 4 Sep 2024 12:12:50 +0100
Subject: [PATCH] Disable xwidgets with recent webkitgtk versions (Bug#66068)

* configure.ac: Accept only webkit2gtk-4.* versions less than 2.41.92.
---
 configure.ac | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index 28361be4211..1d0ea314f6a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -4511,10 +4511,11 @@ AC_DEFUN
 if test "$with_xwidgets" != "no"; then
   if test "$USE_GTK_TOOLKIT" = "GTK3" && test "$window_system" != "none"; then
 WEBKIT_REQUIRED=2.12
-WEBKIT_MODULES="webkit2gtk-4.1 >= $WEBKIT_REQUIRED"
+WEBKIT_BROKEN=2.41.92
+WEBKIT_MODULES="webkit2gtk-4.1 >= $WEBKIT_REQUIRED webkit2gtk-4.1 < 
$WEBKIT_BROKEN"
 EMACS_CHECK_MODULES([WEBKIT], [$WEBKIT_MODULES])
 if test "$HAVE_WEBKIT" = "no"; then
-  WEBKIT_MODULES="webkit2gtk-4.0 >= $WEBKIT_REQUIRED"
+  WEBKIT_MODULES="webkit2gtk-4.0 >= $WEBKIT_REQUIRED webkit2gtk-4.0 < 
$WEBKIT_BROKEN"
   EMACS_CHECK_MODULES([WEBKIT], [$WEBKIT_MODULES])
 fi
 HAVE_XWIDGETS=$HAVE_WEBKIT
-- 
2.46.0

bug#72993: 31.0.50; 4f521fa14c18f57e5207bffd68e9f79454dccc79 breaks binding mode hooks in use-package

[Eli Zaretskii]

> From: John Wiegley 
> Cc: ste...@stebalien.com,  72...@debbugs.gnu.org
> Date: Tue, 03 Sep 2024 15:35:48 -0700
> 
> > Eli Zaretskii  writes:
> 
> >> Perhaps we should avoid auto -hook’ifying the variable name only if the 
> >> name
> >> does not already end in ‘-functions’?
> 
> > Either that, or maybe exempt FOO-mode from the boundp test.
> 
> This sounds likely to be even better.

Like the below?

diff --git a/lisp/use-package/use-package-core.el 
b/lisp/use-package/use-package-core.el
index 2c5fc56..6c3d350 100644
--- a/lisp/use-package/use-package-core.el
+++ b/lisp/use-package/use-package-core.el
@@ -1376,13 +1376,16 @@ use-package-handler/:hook
   (when fun
 (mapcar
  #'(lambda (sym)
- (if (boundp sym)
- `(add-hook (quote ,sym) (function ,fun))
-   `(add-hook
- (quote ,(intern
-  (concat (symbol-name sym)
-  use-package-hook-name-suffix)))
- (function ,fun
+ (let ((symname (symbol-name sym)))
+   (if (and (boundp sym)
+;; Mode variables are usually bound, but
+;; their hooks are named FOO-mode-hook.
+(not (string-suffix-p "-mode" symname)))
+   `(add-hook (quote ,sym) (function ,fun))
+ `(add-hook
+   (quote ,(intern
+(concat symname use-package-hook-name-suffix)))
+   (function ,fun)
  (use-package-hook-handler-normalize-mode-symbols syms)
 (use-package-normalize-commands args
 

bug#72951: Hideshow support for treesitter

[Eli Zaretskii]

Closing.

bug#71289: 30.0.50; cmcheckmagic aborts when tty_write_glyphs writes "Garbage collecting..." in some cases

[Eli Zaretskii]

> From: Daniel Clemente 
> Date: Wed, 4 Sep 2024 06:09:50 +
> Cc: 71...@debbugs.gnu.org
> 
> > > The build_frame_matrix_from_leaf_window crash still happens.
> >
> > That's another problem.  There seems to be some disconnect, time-wise,
> > in reallocating frame matrices and sub-allocating window matrices from
> > the frame matrices, and the crash happens when the check is done
> > in-between those two.
> >
> > This will need more work.  Patches and relevant data are welcome.
> 
> I reported the build_frame_matrix_from_leaf_window problem separately
> to provide simpler instructions. (Can you mention the new bug number
> once it's approved?). The original problem mentioned here is about GC
> messages and it was fixed, so I think it can be closed.

Thanks, done.

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

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

Reuben Thomas  writes:

> On Wed, 4 Sept 2024 at 09:02, martin rudalics  wrote:
>
>   >>
>   >> gtk_distribute_natural_allocation: assertion 'extra_space >= 0' failed
>   >>
>   >
>   > Yes, both with Emacs 29 and git master produce this message when
>   > menu-bar-mode is non-nil, and the menu bar is drawn, in both window sizes
>   > (the normal sized window, and the strangely small one).
>
>  But you can't see this message when building with gtk-2 I presume.
>
> That's correct, no message with gtk-2.
>
>  This strongly hints that there was an Emacs change affecting gtk-2 _and_
>  gtk-3 builds in between 29 and master.  I could imagine that commit
>
>  e087c89b1e243bbd941a4a50b4bf99613e13d016
>
>  is involved but if you could try to bisect, it would be of great help.
>
> Just to check, you're suggesting that I bisect from emacs-29.3 (I use
> that tag because it's what the version of 29 I'm using is built from)
> to master HEAD, to find at which commit C-x 5 2 opens a small window
> immediately (without disabling menu-bar-mode)?

If it is this bug that you are trying to isolate, we have already heard
reports of its being reproducible all the way to Emacs 26.1, and
concluded that it is a product of a change in the Mutter window manager.

Too bad I'm only personally interested in the no toolkit and Motif
builds and cannot set aside the time to investigate these GTK issues at
this time.

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, 4 Sep 2024 09:28:47 +0200
> From:  martin rudalics via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" 
> 
>  > To reproduce:
>  > 1. Open emacs -Q
>  > 2. Press C-x 2 to split the frame (top/bottom)
>  > 3. Make the terminal very small (I slowly resize the X window that's
>  > running urxvt, to the minimum size, 1 row and 2 columns in my case).
>  > This shrinking process alone can produce the crash when the window is
>  > around 5 lines high
>  > 4. It always crashes in my case. If it doesn't, make the terminal
>  > larger again, and repeat the resizing for some seconds until it
>  > crashes
>  >
>  > Note that the C-x 2 is required. The problem doesn't happen with a
>  > left/right split (C-x 3). But it happens after a C-x 3 C-x 2.
> 
> Kindly have a look at the fix I proposed here:
> 
> https://lists.gnu.org/archive/html/emacs-devel/2024-09/msg00054.html

Thanks, but could you tell how that change could have affected this
assertion violation?  AFAICT, adjust_frame_glyphs is not in the
backtrace, so how could moving code inside of it affect what happens
here?

bug#73023: Obsolete documentation on insert-in-front-hooks (GNU Emacs 29.4)

[Eli Zaretskii]

> From: Rodrigo Morales 
> Date: Wed, 4 Sep 2024 00:18:05 -0500
> 
> Rodrigo Morales  writes:
> 
> > I believe that the part "these functions receive two arguments, the
> > beginning and end of the inserted text." is obsolete because functions
> > in insert-in-front-hooks are passed 4 parameters. In the code block
> > below, you can see a correct function definition for
> > insert-in-front-hooks. The two code block shown below were retrieved
> > from the file ./lisp/progmodes/cpp.el
> 
> When I wrote this bug report, I wasn't aware about the difference
> between text properties and overlay properties. I thought that all
> properties that can be used on text can also be used on overlays, now I
> know that I'm wrong. Please omit this bug report.

Thanks, closing.

bug#72977: 28.2; DOS in Shell-script mode

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

>> echo in in in in in in in in in in in in in in in in in in in in in in in in 
>> in in in in in in
>> 
>> After about 20 'in's, things slow down noticeably, and I can't get to 30 
>> without it hanging.
>
> The profile is below.  Maybe Stefan (CC'ed) has some comments or
> suggestions.
>
>36361  58% - timer-event-handler
>36361  58%  - apply
>36361  58%   - show-paren-function
>36361  58%- #
>36361  58% - apply
>36361  58%  - smie--matching-block-data
>36359  58%   - smie--opener/closer-at-point
>36068  57%- sh-smie-sh-forward-token
>23841  38% - sh-smie--sh-keyword-p
>23841  38%  - sh-smie--sh-keyword-in/do-p
>23841  38%   - sh-smie-sh-backward-token
>23837  38%- sh-smie--sh-keyword-p
>23837  38% - sh-smie--sh-keyword-in/do-p
>23837  38%  - sh-smie-sh-backward-token
>23805  38%   - sh-smie--sh-keyword-p
>23801  38%- sh-smie--sh-keyword-in/do-p
>23793  38% - sh-smie-sh-backward-token
>23685  38%  - sh-smie--sh-keyword-p
[...]

Hmm... indeed, in order to decide whether a given `in` is a keyword
rather than just some command's argument, we need to look back, so we
probably have an O(N²) situation here, where we walk backward over all
the `in`s in order to decide whether the last one is a keyword.  Then we
do the same starting from the "last but one" (because the check for
keyword-p was only made to decide how to skip that last token), etc...

In theory we could do it more efficiently by integrating better the
keyword-p check and the navigation to the beginning of a command, but it
requires a different structure than the one we're using.

Another solution is to use a cache (which could simply memoize the
output of `sh-smie--sh-keyword-p`) which we could flush from
`after-change-functions`.

Yet another (more ad-hoc) approach might be to try and keep track of the
nesting, and let `sh-smie--sh-keyword-p` return nil when we reach
a nesting of say 2 (at least for `in` I can't think of a piece of code
where the 3rd (or subsequent) `in` can be a keyword).


Stefan

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

[Robert Pluim]

> On Wed, 4 Sep 2024 09:30:58 +0200, Paul Nelson  said:

Paul> Many thanks for your suggestion.  I agree that this is a more elegant
Paul> approach, which also admits a simpler implementation.  I've attached
Paul> my revised patch.  Any further feedback welcome.

Minor comments below

Paul> Thanks, best,

Paul> Paul

Paul> From 91ade3effdbf19b7d8793020a1c31a4ff791a58d Mon Sep 17 00:00:00 2001
Paul> From: Paul Nelson 
Paul> Date: Wed, 4 Sep 2024 09:24:25 +0200
Paul> Subject: [PATCH] Add Ediff feature for copying all differences

Paul> * lisp/vc/ediff-util.el (ediff-diff-to-diff): With universal
Paul> prefix, copy all differences.

Paul> * doc/misc/ediff.texi (Quick Help Commands):
Paul> * etc/NEWS: (Lisp Changes in Emacs 31.1): Document the new
Paul> feature.
Paul> ---
Paul>  doc/misc/ediff.texi   | 26 ++
Paul>  etc/NEWS  | 16 
Paul>  lisp/vc/ediff-util.el | 29 +
Paul>  3 files changed, 47 insertions(+), 24 deletions(-)

Paul> diff --git a/doc/misc/ediff.texi b/doc/misc/ediff.texi
Paul> index 749025c870b..6afb38e3fae 100644
Paul> --- a/doc/misc/ediff.texi
Paul> +++ b/doc/misc/ediff.texi
Paul> @@ -489,15 +489,16 @@ Quick Help Commands
Paul>  @item a
Paul>  @kindex a
Paul>  @emph{In comparison sessions:}
Paul> -Copies the current difference region (or the region specified as the 
prefix
Paul> -to this command) from buffer A to buffer B@.
Paul> -Ediff saves the old contents of buffer B's region; it can
Paul> -be restored via the command @kbd{rb}, which see.
Paul> +Copies the current difference region (or the region specified as the
Paul> +prefix to this command, or @emph{all} regions with @kbd{C-u} prefix)
Paul> +from buffer A to buffer B@.  Ediff saves the old contents of buffer 
B's
Paul> +region; it can be restored via the command @kbd{rb}, which see.

'numerical prefix' maybe? Although that part of the text is not new.

Paul>  @emph{In merge sessions:}
Paul> -Copies the current difference region (or the region specified as the 
prefix
Paul> -to this command) from buffer A to the merge buffer.  The old 
contents of
Paul> -this region in buffer C can be restored via the command @kbd{r}.
Paul> +Copies the current difference region (or the region specified as the
Paul> +prefix to this command, or @emph{all} regions with @kbd{C-u} prefix)
Paul> +from buffer A to the merge buffer.  The old contents of this region 
in
Paul> +buffer C can be restored via the command @kbd{r}.

Similarly here

Paul>  @item b
Paul>  @kindex b
Paul> @@ -511,11 +512,12 @@ Quick Help Commands
 
Paul>  @item ab
Paul>  @kindex ab
Paul> -Copies the current difference region (or the region specified as the 
prefix
Paul> -to this command) from buffer A to buffer B@.  This (and the next 
five)
Paul> -command is enabled only in sessions that compare three files
Paul> -simultaneously.  The old region in buffer B is saved and can be 
restored
Paul> -via the command @kbd{rb}.
Paul> +Copies the current difference region (or the region specified as the
Paul> +prefix to this command, or @emph{all} regions with @kbd{C-u} prefix)
Paul> +from buffer A to buffer B@.  This (and the next five) command is 
enabled
Paul> +only in sessions that compare three files simultaneously.  The old
Paul> +region in buffer B is saved and can be restored via the command
Paul> +@kbd{rb}.

and here.

Paul>  @item ac
Paul>  @kindex ac
Paul>  Copies the difference region from buffer A to buffer C@.
Paul> diff --git a/etc/NEWS b/etc/NEWS
Paul> index f10f9ae4d65..a6db0c96288 100644
Paul> --- a/etc/NEWS
Paul> +++ b/etc/NEWS
Paul> @@ -121,6 +121,22 @@ A new ':authorizable t' parameter has been added 
to 'dbus-call-method'
Paul>  and 'dbus-call-method-asynchronously' to allow the user to 
interactively
Paul>  authorize the invoked D-Bus method (e.g., via polkit).
 
Paul> 
Paul> +** Ediff's copy commands now apply to all changes with 'C-u' prefix.
Paul> +The Ediff copy commands, bound to 'a', 'b', 'ab', etc., now copy all
Paul> +changes when supplied with a universal prefix argument via 'C-u':
Paul> +
Paul> +- 'C-u a' copies all changes from buffer A to buffer B (in 2-way 
diff)
Paul> +  or to buffer C (in 3-way diff or merge).
Paul> +- 'C-u b' copies all changes from buffer B to buffer A (in 2-way 
diff)
Paul> +  or to buffer C (in 3-way diff or merge).
Paul> +- 'C-u a b' copies all changes from buffer A to buffer B.
Paul> +- 'C-u b a' copies all changes from buffer B to buffer A.
Paul> +- 'C-u a c' copies all changes from buffer A to buffer C.
Paul> +- 'C-u b c' copies all changes from buffer B to buffer C.
Paul> +- 'C-u c a' copies all changes from buffer C to buff

bug#73005: [REGRESSION, BISECTED]: line numbers disappear when pressing `df` in evil-mode

[Konstantin Kharlamov]

On Tue, 2024-09-03 at 19:18 +0300, Konstantin Kharlamov wrote:
> On Tue, 2024-09-03 at 18:30 +0300, Eli Zaretskii wrote:
> > > Cc: da_...@orange.fr
> > > From: Konstantin Kharlamov 
> > > Date: Tue, 03 Sep 2024 17:46:09 +0300
> > > 
> > > CCing the commit author.
> > > 
> > > Sorry for using external plugin, but master has two separate
> > > unrelated
> > > critical regressions (the other one is going via link in *Help*
> > > buffer
> > > and getting Emacs locked up with 100% CPU and quickly increasing
> > > memory
> > > usage, which complicates reducing the steps), and since there's a
> > > clear
> > > commit that introduced the problem I decided to report it as is.
> > > 
> > > # Steps to reproduce
> > > 
> > > 1. Make sure you're in the Emacs repository and
> > > `./build/src/emacs`
> > > is
> > > the built binary
> > > 2. Execute `git clone --depth 1
> > > https://github.com/emacs-evil/evil
> > > /tmp/evil`
> > > 3. Execute `PATH="$(pwd)/build/src/:$PATH" make -C /tmp/evil
> > > emacs`
> > > (Emacs with Evil loaded will start)
> > > 4. Press `n` to refuse running tests
> > > 5. Turn line numbers on by evaluating: (setq-default display-
> > > line-
> > > numbers 'visual)
> > > 6. Press `df`
> > 
> > What does "df" do?
> 
> "df" is triggering the action "delete text up to" and it will wait
> for
> the third key, the symbol to "delete text up to". But for the problem
> to appear pressing the third key is not required.
> 
> As a matter of fact, sometimes it gets reproduced by just pressing
> "f"
> which stands for "go to next symbol" (and it would similarly wait a
> keypress to define a symbol to go to), but for some reason it happens
> much less compared to pressing "df".
> 
> >   Does it somehow end up calling string-pixel-width?
> 
> It seems it doesn't. I used a `M-x debug-on-entry string-pixel-width`
> and then pressed "df" which made line numbers disappear, but debugger
> wasn't triggered.
> 
> > IOW, please show how string-pixel-width is related to the above.
> 
> Offhand I don't know. I would reduce steps, but I can't use *Help*
> for
> reasons mentioned in my 1st email, and I still didn't find a commit
> which does not hang upon following *Help* buffer, because 1000
> commits
> before dffdbc1f1fd6 Emacs fails to compile with some native-
> compilation
> errors and `make clean` doesn't help. I presume finding the culprit
> for
> this problem will take some time.
> 
> I don't know if it's of any help, but upon pressing "df" the caret
> turns from a rectangle to a square (half the rectangle size). This is
> indicating that Emacs is waiting for the next keypress, perhaps this
> indication somehow triggers the problem…

So FWIW, I'm not really clear how to debug it further. The problem
seems to only reproduce interactively. I tried calling manually various
functions like `(evil-find-char 1 ?f)`, `(evil-operator-range)`,
`(evil-delete 1 3)` but it didn't trigger the problem. In particular,
`(evil-operator-range)` is the one that makes caret turn to a square
waiting for input, but problem doesn't reproduce like this.

However, I found an alternative way to reproduce it, unfortunately
still requiring Evil:

1. Press f (it will wait for next character)
2. Press C-g to cancel the action
3. Press M-:

Result: line numbers disappear along with minibuffer popping up.

Another interesting point: after line numbers disappeared, if I
evaluate `display-line-numbers` (i.e. just to see its value), line
numbers immediately appear back.

--

Regarding the unrelated hang, I more or less figured that out. It
turned out to be in another plugin, but it didn't look like a plugin
bug because usually when ELisp hangs you can stop a loop with C-g or
even just quit emacs with ^C or killall, but for some reason
occasionally only SIGKILL worked, which made me think it's a hang in C
code. But it wasn't.

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

[Robert Pluim]

> On Wed, 04 Sep 2024 20:12:28 +0800, Po Lu via "Bug reports for GNU Emacs, 
> the Swiss army knife of text editors"  said:

Po Lu> If it is this bug that you are trying to isolate, we have already 
heard
Po Lu> reports of its being reproducible all the way to Emacs 26.1, and
Po Lu> concluded that it is a product of a change in the Mutter window 
manager.

As a reference point: I donʼt see this issue here with mutter 43.8

Robert
-- 

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

[Eli Zaretskii]

> From: Robert Pluim 
> Cc: Eli Zaretskii ,  72...@debbugs.gnu.org
> Date: Wed, 04 Sep 2024 15:01:23 +0200
> 
> Eli, does this change need a copyright assigment? I donʼt see
> 'ultr...@gmail.com' in the git logs anywhere.

Paul's assignment is on file, so we are okay in that department.

bug#73005: [REGRESSION, BISECTED]: line numbers disappear when pressing `df` in evil-mode

[Eli Zaretskii]

> From: Konstantin Kharlamov 
> Cc: 73...@debbugs.gnu.org, da_...@orange.fr
> Date: Wed, 04 Sep 2024 16:02:27 +0300
> 
> 1. Press f (it will wait for next character)
> 2. Press C-g to cancel the action
> 3. Press M-:
> 
> Result: line numbers disappear along with minibuffer popping up.
> 
> Another interesting point: after line numbers disappeared, if I
> evaluate `display-line-numbers` (i.e. just to see its value), line
> numbers immediately appear back.

Sounds like Evil does the above with current buffer set to the work
buffer where we calculate string-pixel-width, and where we therefore
disabled display-line-numbers?

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

[Paul Nelson]

Thanks Robert, I've implemented your suggestions.

I hope someone will check that I've used "+++" correctly in NEWS,
affirming that I updated the documentation -- hopefully I didn't miss
anything.

Any other comments welcome.

Paul


0001-Add-Ediff-feature-for-copying-all-differences.patch
Description: Binary data

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

[Eli Zaretskii]

> Cc: n142...@gmail.com, 73...@debbugs.gnu.org
> Date: Wed, 04 Sep 2024 15:21:16 +0300
> From: Eli Zaretskii 
> 
> > Date: Wed, 4 Sep 2024 09:28:47 +0200
> > From:  martin rudalics via "Bug reports for GNU Emacs,
> >  the Swiss army knife of text editors" 
> > 
> >  > To reproduce:
> >  > 1. Open emacs -Q
> >  > 2. Press C-x 2 to split the frame (top/bottom)
> >  > 3. Make the terminal very small (I slowly resize the X window that's
> >  > running urxvt, to the minimum size, 1 row and 2 columns in my case).
> >  > This shrinking process alone can produce the crash when the window is
> >  > around 5 lines high
> >  > 4. It always crashes in my case. If it doesn't, make the terminal
> >  > larger again, and repeat the resizing for some seconds until it
> >  > crashes
> >  >
> >  > Note that the C-x 2 is required. The problem doesn't happen with a
> >  > left/right split (C-x 3). But it happens after a C-x 3 C-x 2.
> > 
> > Kindly have a look at the fix I proposed here:
> > 
> > https://lists.gnu.org/archive/html/emacs-devel/2024-09/msg00054.html
> 
> Thanks, but could you tell how that change could have affected this
> assertion violation?  AFAICT, adjust_frame_glyphs is not in the
> backtrace, so how could moving code inside of it affect what happens
> here?

In any case, I can cause the assertion violation even after making the
change you suggested above.

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

[Sean Whitton]

Hello,

On Tue 03 Sep 2024 at 04:32pm GMT, Philip Kaludercic wrote:

>
> +(defcustom kill-region-dwim nil
> +  "Behaviour when `kill-region' is invoked without an active region.
> +If set to nil (default), then an error occurs and nothing is killed.  If
> +set to `emacs-word', then kill a the last word as defined by the current
> +major mode.  If set to `unix-word', then kill the last word in the style
> +of a shell like Bash, disregarding the major mode."
> +  :type '(choice (const :tag "Kill a word like `backward-kill-word'" 
> emacs-word)
> + (const :tag "Kill a word like Bash would" unix-word)
> + (const :tag "Do not kill anything" nil))
> +  :group 'killing)

I think I'm missing something here.  When it's nil and there is no
*active* region, but there is a region, it should kill that, surely?
With or without TMM.
I very regularly kill inactive regions (e.g. after M->).

> + ((eq region 'unix-word)
> +  (let ((end (point)))
> +(save-excursion
> +  (skip-chars-backward "[:space:]")
> +  (skip-chars-backward "^[:space:]")
> +  (filter-buffer-substring
> +   (if (get-char-property (point) 'read-only)
> +   (next-single-char-property-change
> +(point) 'read-only nil end)
> + (point))
> +   end 'delete
> + (region
> +  (funcall region-extract-function 'delete))
> + ((filter-buffer-substring beg end 'delete)

Shall I rather commit this as an independent unix-word-rubout?

Improves attribution, and it's independently useful.

-- 
Sean Whitton

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

[Eli Zaretskii]

> From: Sean Whitton 
> Cc: Eli Zaretskii ,  stefankan...@gmail.com,
>   acora...@gnu.org,  j...@linkov.net,  r...@gnu.org,  69...@debbugs.gnu.org
> Date: Wed, 04 Sep 2024 15:07:08 +0100
> 
> > +(defcustom kill-region-dwim nil
> > +  "Behaviour when `kill-region' is invoked without an active region.
> > +If set to nil (default), then an error occurs and nothing is killed.  If
> > +set to `emacs-word', then kill a the last word as defined by the current
> > +major mode.  If set to `unix-word', then kill the last word in the style
> > +of a shell like Bash, disregarding the major mode."
> > +  :type '(choice (const :tag "Kill a word like `backward-kill-word'" 
> > emacs-word)
> > + (const :tag "Kill a word like Bash would" unix-word)
> > + (const :tag "Do not kill anything" nil))
> > +  :group 'killing)
> 
> I think I'm missing something here.  When it's nil and there is no
> *active* region, but there is a region, it should kill that, surely?
> With or without TMM.

Yes, you are right.  It sounds like we made wrong assumptions about
what happens in that case, and should rethink this.

C-w signals an error only if there's no mark in the buffer.

So I guess we need a new command after all.

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

[Eval EXEC]

 Start of forwarded message 
From: Eval EXEC 
To: emacs-devel 
Subject: 31.0.50; tab-bar-formal-global erased global-modeline-string's
 mouse hover/click action menu

Hello,

I'm using tab-bar-mode, and I've included `tab-bar-format-global` in 
`tab-bar-format`. This displays `global-mode-string` on the tab-bar.

```elisp
(setq-default tab-bar-format
  tab-bar-format-menu-bar
  tab-bar-format-history
  tab-bar-format-tabs
  tab-bar-separator
  tab-bar-format-add-tab
  tab-bar-separator
  tab-bar-format-align-right
  tab-bar-format-global)
```

However, in `global-mode-string`, I have `mu4e`. The tab-bar seems to remove 
the hover and mouse click actions from `global-mode-string`.

It appears that the issue is related to the use of "ignore":
```elisp
(defun tab-bar-format-global ()
  "Produce display of `global-mode-string' in the tab bar.
When `tab-bar-format-global' is added to `tab-bar-format'
\(possibly appended after `tab-bar-format-align-right'),
then modes that display information on the mode line
using `global-mode-string' will display the same text
on the tab bar instead."
  (mapcar (lambda (string)
`(global menu-item ,(format-mode-line string) ignore))
  global-mode-string))
```

If I remove `tab-bar-format-global` from `tab-bar-format`, the 
`global-mode-string` displays on the mode-line, and the `mu4e` indicator in 
`global-mode-string` works with mouse hover and click. I believe that if 
`global-mode-string` is displayed on the tab-bar, its items should also support 
mouse hover and click.

What do you think? How can I quickly hack the tab-bar to enable mouse
hover and click for `global-mode-string` in `tab-bar`?

Thank you.


In GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.42, cairo version 1.18.0) of 2024-09-03 built on Mufasa
Repository revision: 6682d0e6c96b0279929e3f47ae0820dd8a513d4b
Repository branch: scratch/igc
Windowing system distributor 'The X.Org Foundation', version 11.0.12401000
System Description: NixOS 24.05 (Uakari)

Configured using:
 'configure 'CFLAGS=-O3 -mtune=native -march=native'
 --prefix=/home/exec/Projects/git.savannah.gnu.org/git/emacs-build/scratch_igc
 --with-mps=yes --with-imagemagick --with-modules --with-x-toolkit=gtk3
 --without-compress-install --without-toolkit-scroll-bars
 --with-native-compilation --with-mailutils
 --enable-link-time-optimization --with-tree-sitter --with-xinput2
 --with-dbus --with-native-compilation=aot
 --with-file-notification=inotify'

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

Important settings:
  value of $EMACSLOADPATH: 
/nix/store/r6awdsxz4r0zbj5a58c8a93asy5ciqqx-emacs-mu4e-1.12.5/share/emacs/site-lisp/elpa/mu4e-1.12.5:/nix/store/r6awdsxz4r0zbj5a58c8a93asy5ciqqx-emacs-mu4e-1.12.5/share/emacs/site-lisp:
  value of $LC_COLLATE: C
  value of $LC_MONETARY: en_US.UTF-8
  value of $LC_NUMERIC: en_US.UTF-8
  value of $LC_TIME: en_US.UTF-8
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=fcitx
  locale-coding-system: utf-8-unix

Major mode: ELisp/l

Minor modes in effect:
  savehist-mode: t
  marginalia-mode: t
  keycast-tab-bar-mode: t
  global-treesit-auto-mode: t
  restore-point-mode: t
  global-atomic-chrome-edit-mode: t
  dogears-mode: t
  elisp-autofmt-mode: t
  highlight-defined-mode: t
  copilot-mode: t
  flycheck-status-emoji-mode: t
  flycheck-pos-tip-mode: t
  tab-line-nerd-icons-global-mode: t
  global-tab-line-mode: t
  tab-line-mode: t
  project-x-mode: t
  org-roam-db-autosync-mode: t
  global-org-modern-mode: t
  mu4e-marker-icons-mode: t
  treemacs-project-follow-mode: t
  treemacs-filewatch-mode: t
  treemacs-follow-mode: t
  treemacs-git-mode: t
  treemacs-fringe-indicator-mode: t
  mu4e-modeline-mode: t
  pangu-spacing-mode: t
  breadcrumb-local-mode: t
  flycheck-mode: t
  engine-mode: t
  corfu-popupinfo-mode: t
  global-corfu-mode: t
  corfu-mode: t
  editorconfig-mode: t
  activities-tabs-mode: t
  activities-mode: t
  burly-tabs-mode: t
  global-form-feed-st-mode: t
  form-feed-st-mode: t
  eat-eshell-mode: t
  global-wakatime-mode: t
  wakatime-mode: t
  sly-symbol-completion-mode: t
  minions-mode: t
  highlight-numbers-mode: t
  hes-mode: t
  rainbow-delimiters-mode: t
  global-hungry-delete-mode: t
  hungry-delete-mode: t
  super-save-mode: t
  windmove-mode: t
  save-place-mode: t
  recentf-mode: t
  winner-mode: t
  pdf-occur-global-minor-mode: t
  persistent-scratch-autosave-mode: t
  yas-global-mode: t
  yas-minor-mode: t
  hl-line-mode: t
  nerd-icons-completion-mode: t
  global-diff-hl-show-hunk-mouse-mode: t
  diff-hl-show-hunk-mouse-mode: t
  diff-hl-flydiff-mode: t
  diff-hl-margin-local-mode: t
  diff-

bug#73005: [REGRESSION, BISECTED]: line numbers disappear when pressing `df` in evil-mode

[Konstantin Kharlamov]

On Wed, 2024-09-04 at 16:15 +0300, Eli Zaretskii wrote:
> > From: Konstantin Kharlamov 
> > Cc: 73...@debbugs.gnu.org, da_...@orange.fr
> > Date: Wed, 04 Sep 2024 16:02:27 +0300
> > 
> > 1. Press f (it will wait for next character)
> > 2. Press C-g to cancel the action
> > 3. Press M-:
> > 
> > Result: line numbers disappear along with minibuffer popping up.
> > 
> > Another interesting point: after line numbers disappeared, if I
> > evaluate `display-line-numbers` (i.e. just to see its value), line
> > numbers immediately appear back.
> 
> Sounds like Evil does the above with current buffer set to the work
> buffer where we calculate string-pixel-width, and where we therefore
> disabled display-line-numbers?

I git-grepped over Evil the word `work-buffer` and there is no matches.
So there isn't direct call to `with-work-buffer`. Then I tried to `M-x
debug-on-entry with-work-buffer` and reproduced the issue, but debugger
wasn't triggered either.

So doesn't seem like it.

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

[Juri Linkov]

>> +  (font-lock-ensure)
>>(run-mode-hooks 'wdired-mode-hook)
>>(message "%s" (substitute-command-keys
>>   "Press \\[wdired-finish-edit] when finished \
>
> Yip.  When we do this (guess we don't have a choice), my preferred
> solution would be to hook this into the corresponding isearch function.
> Because calling `font-lock-ensure' can be really slow in large dired
> buffers (several seconds).  Or we manage to rewrite things so that the
> work is done on the fly in some way.

So you prefer to slow down only when the user types C-s?
This is possible by adding a local hook in
wdired-change-to-wdired-mode:

  (add-hook 'isearch-mode-hook #'font-lock-ensure nil t)

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

[Juri Linkov]

> I'm using tab-bar-mode, and I've included `tab-bar-format-global` in
> `tab-bar-format`.  This displays `global-mode-string` on the tab-bar.
>
> However, in `global-mode-string`, I have `mu4e`.  The tab-bar seems to
> remove the hover and mouse click actions from `global-mode-string`.

Please show your `global-mode-string` with `mu4e` in it.

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

[Eval EXEC]

Juri Linkov  writes:

>> I'm using tab-bar-mode, and I've included `tab-bar-format-global` in
>> `tab-bar-format`.  This displays `global-mode-string` on the tab-bar.
>>
>> However, in `global-mode-string`, I have `mu4e`.  The tab-bar seems to
>> remove the hover and mouse click actions from `global-mode-string`.
>
> Please show your `global-mode-string` with `mu4e` in it.

-- 

I execute describe-variable global-mode-string, it's:

global-mode-string is a variable defined in xdisp.c.

Value
((:eval (mu4e--modeline-string)) (t (:eval (lsp--progress-status)))
 ((t lsp-java-progress-string)) (:eval (exec/git-mode-string))
 (:eval (exec/gc-mode-string)) flycheck-mode-line)

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

[Vadim Zaliva]

Arash, thanks for response. I do have auctex 14.0.6 installed via ELPA. 
I tried to reproce the problem starting from `emacs -Q` and it did not 
reproduce. With my default setup it's still happening with the following 
debug trace:


Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  LaTeX-indent-level-count()
  LaTeX-indent-calculate-last(outer)
  LaTeX-indent-calculate(outer)
  LaTeX-indent-line()
  indent-according-to-mode()
  LaTeX-fill-region-as-para-do(3960 # nil)
  LaTeX-fill-region-as-paragraph(3960 4117 nil)
  LaTeX-fill-paragraph(nil)
  fill-paragraph(nil t)
  funcall-interactively(fill-paragraph nil t)
  command-execute(fill-paragraph)

LaTeX-indent-level-count is defined `latex.el` from acutex package. Any 
thoughts what could be causing it and what I can try to diagnose it further?


Thanks!

Vadim

bug#72762: 30.0.60; Incorrect rendering of the completion-preview mode

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

Eshel Yaron writes:

[...]
> An arguably nicer solution is to give the completion preview overlay
> higher priority, so it is displayed before the "[Incomplete Command]"
> message.  However, we don't always want to give the completion preview
> overlay a positive priority, since that may lead to incorrect results in
> other scenarios.  What we can do is to add a variable that specifies the
> overlay priority, so you can set it just where appropriate.
>
> Eli, is the following alright for Emacs 30, or should this go on the
> master branch?

Pushed to master for now, with some additional commentary, in commit 
a13eef1fae0.


Best,

Eshel

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

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

> Just to check, you're suggesting that I bisect from emacs-29.3 (I use that
> tag because it's what the version of 29 I'm using is built from) to master
> HEAD, to find at which commit C-x 5 2 opens a small window immediately
> (without disabling menu-bar-mode)?

That's the idea, yes.

> This made no difference. I added just:
>
> (add-to-list 'default-frame-alist '(user-size . t))
>
> to ~/.config/emacs/early-init.el
>
> Then I ran each Emacs with just "emacs", confirmed that default-frame-alist
> was set, then disabled menu-bar-mode (Emacs 29 only), then C-x 5 2. In each
> case a small window was opened as before.

I had no hope that this would help.

martin

bug#72993: 31.0.50; 4f521fa14c18f57e5207bffd68e9f79454dccc79 breaks binding mode hooks in use-package

[John Wiegley]

> Eli Zaretskii  writes:

> Like the below?

Yes, looks good! Thank you, Eli.

-- 
John Wiegley  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com  60E1 46C4 BD1A 7AC1 4BA2

bug#72993: 31.0.50; 4f521fa14c18f57e5207bffd68e9f79454dccc79 breaks binding mode hooks in use-package

[Eli Zaretskii]

> From: John Wiegley 
> Cc: ste...@stebalien.com,  72...@debbugs.gnu.org
> Date: Wed, 04 Sep 2024 10:30:21 -0700
> 
> > Eli Zaretskii  writes:
> 
> > Like the below?
> 
> Yes, looks good! Thank you, Eli.

Thanks, installed on the emacs-30 branch, and closing the bug.

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

[Arash Esbati]

Vadim Zaliva  writes:

> Arash, thanks for response. I do have auctex 14.0.6 installed via
> ELPA. I tried to reproce the problem starting from `emacs -Q` and it
> did not reproduce.

You're welcome.  The above essentially says that AUCTeX isn't the
culprit per se since it works with the standard setup.

> With my default setup it's still happening with the following debug
> trace:
>
> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
>   LaTeX-indent-level-count()
>   LaTeX-indent-calculate-last(outer)
>   LaTeX-indent-calculate(outer)
>   LaTeX-indent-line()
>   indent-according-to-mode()
>   LaTeX-fill-region-as-para-do(3960 # nil)
>   LaTeX-fill-region-as-paragraph(3960 4117 nil)
>   LaTeX-fill-paragraph(nil)
>   fill-paragraph(nil t)
>   funcall-interactively(fill-paragraph nil t)
>   command-execute(fill-paragraph)
>
> LaTeX-indent-level-count is defined `latex.el` from acutex
> package. Any thoughts what could be causing it and what I can try to
> diagnose it further?

Thanks for the debug info, I have no idea why this happens in your
setup, so you have to dig further.  Some general ideas are:

• With your setup and your .tex file opened, do 'M-x
  list-load-path-shadows RET' and see if you have a stale AUCTeX
  installation on your HD; maybe you search also your HD yourself
• With your setup, load your .tex file, instrument[1] the function
  `LaTeX-indent-level-count' and trigger the issue.  Watch the function
  running[2] and where it chokes, maybe that helps
• Bisect your packages you load with AUCTeX and see which one breaks
  with your .tex file
• Just be on the safe side, uninstall AUCTeX via package manager
  interface, restart Emacs, and install AUCTeX again via the package
  manager interface.

HTH.  Best, Arash

Footnotes:
[1]  
https://www.gnu.org/software/emacs/manual/html_node/elisp/Instrumenting.html
[2]  
https://www.gnu.org/software/emacs/manual/html_node/elisp/Edebug-Execution-Modes.html

bug#73005: [REGRESSION, BISECTED]: line numbers disappear when pressing `df` in evil-mode

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

On 04/09/2024 6:00 PM, Konstantin Kharlamov wrote:

On Wed, 2024-09-04 at 16:15 +0300, Eli Zaretskii wrote:

From: Konstantin Kharlamov 
Cc: 73...@debbugs.gnu.org, da_...@orange.fr
Date: Wed, 04 Sep 2024 16:02:27 +0300

1. Press f (it will wait for next character)
2. Press C-g to cancel the action
3. Press M-:

Result: line numbers disappear along with minibuffer popping up.

Another interesting point: after line numbers disappeared, if I
evaluate `display-line-numbers` (i.e. just to see its value), line
numbers immediately appear back.


Sounds like Evil does the above with current buffer set to the work
buffer where we calculate string-pixel-width, and where we therefore
disabled display-line-numbers?


I git-grepped over Evil the word `work-buffer` and there is no matches.
So there isn't direct call to `with-work-buffer`. Then I tried to `M-x
debug-on-entry with-work-buffer` and reproduced the issue, but debugger
wasn't triggered either.

So doesn't seem like it.


Could it be that a temporary buffer named " *work*" is being used somewhere?
In which case there could be nasty side effects with the same buffer being
used by `with-work-buffer'?

Just a wild guess.

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

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

On Wed, 4 Sept 2024 at 18:11, martin rudalics  wrote:

>  > Just to check, you're suggesting that I bisect from emacs-29.3 (I use
> that
>  > tag because it's what the version of 29 I'm using is built from) to
> master
>  > HEAD, to find at which commit C-x 5 2 opens a small window immediately
>  > (without disabling menu-bar-mode)?
>
> That's the idea, yes.
>

Thanks for confirming.

My bisection suggests the problematic commit is
241616831024c9c9fe2b2378b611db0a560b9675

-- 
https://rrt.sc3d.org

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

[Yuan Fu]

> On Sep 4, 2024, at 12:42 AM, m...@ssbb.me wrote:
> 
> I can confirm that I never had such problems in heex-ts-mode but only with 
> inline heex in elixir-ts-mode.
> 
>> On Sep 4, 2024, at 10:39 AM, Wilhelm Kirschbaum  
>> wrote:
>> 
>> 
>> 
>> On Thu, Aug 29, 2024 at 8:14 AM Yuan Fu  wrote:
>> 
>> 
>> > On Aug 28, 2024, at 10:09 PM, Eli Zaretskii  wrote:
>> > 
>> >> From: m...@ssbb.me
>> >> Date: Thu, 29 Aug 2024 06:57:38 +0400
>> >> 
>> >> Code in attached file cause Emacs to hang and memory leak infinitely
>> >> while editing. Try to open this code in elixir-ts-mode and move cursor
>> >> on line 6 (between <:loading>  ) and type char by char:
>> >> 
>> >> <.some_component a={
>> >> 
>> >> (for some reason it does not happen with electric-pair-mode when {}
>> >> inserted automatically).
>> >> 
>> >> I am able to reproduce this with -Q on few different machines (Linux and
>> >> MacOS) and Emacs 29, 30.0.5 and current HEAD.
>> >> 
>> >> C-g does nothing (including with debug-on-quit and sending SIGUSR2)
>> >> 
>> >> At the same time I can't reproduce this in other tree-sitter based 
>> >> editors.
>> >> 
>> >> I got this sample code sample from elixir-ts-mode repo but now it's moved
>> >> to the Emacs core so seems to be out of scope of Github repo issues.
>> >> 
>> >> Attaching samle code and LLDB backtrace. 
>> >> Also attaching report from built-in MacOS crash reporting tool just in 
>> >> case.
>> > 
>> > Thanks.
>> > 
>> > Wilhelm and Yuan, could you please look into this soon?
>> 
>> That’s bizarre, might have some bug around ranges. I’m looking into this. 
>> Hopefully I can figure it out in a few days :-(
>> 
>> Yuan
>> 
>> I can reproduce the issue by following the above instructions, but need to 
>> do some digging. It only seems to be the case with embedded heex and not 
>> with heex-ts-mode by itself. 
>> 
>> WIlhelm
>> 

At the moment I’m still not able to pinpoint the culprit, but here’s what I 
found: I can reproduce the issue by simply creating a heex parser, set the 
ranges to [108,240], [300,572], [820,1346] (these are byte position, aka one 
less than character position), then make it parse the buffer (with the 
"<.some_component a={" part already typed in. I instrumented the buffer reader 
and the program hangs after reading the character at byte position 908 (end of 
"phx-click={“). Also the hang appears in ts_parser_parse.

I wrote a C program that does exactly that, but the program runs fine without 
hanging. I haven’t found what Emacs does differently that causes the hang to 
happen.

Also I found some other range bug, but fixing those didn’t help this issue.

Yuan

bug#72961: Possible documentation improvement: Clarification for package installation

[Krystian Samp]

Also note that the preceding paragraph in 28.8 talks about the need to
'load' or 'require' libraries that you want to make available at startup.
So reading in the very next paragraph: "[...] and also writes the necessary
initialization code into your init files" sets the expectation that
package-install will write 'load' or 'require' into the init file.

On the other hand in another part of the manual (49.3): "Installed packages
are automatically made available by Emacs in all subsequent sessions". This
is simpler and more accurate imho, and doesn't suggest the init files are
altered in any way.

I'd propose to make a simple change in 28.8 that is consistent with 49.3:

Original:
"Note that installing a package using package-install (see Package
Installation) takes care of placing the package's Lisp files in a directory
where Emacs will find it, and also writes the necessary initialization code
into your init files, making the above manual customizations unnecessary"

Proposed:

“Note that installing a package using package-install (see Package
Installation) takes care of placing the package’s Lisp files in a directory
where Emacs will find it. Installed packages are automatically made
available by Emacs in all subsequent sessions, making the above manual
customizations unnecessary.”

Does this make sense?

Thanks,
Krystian


On Mon, 2 Sept 2024 at 20:49, Philip Kaludercic  wrote:

> Eli Zaretskii  writes:
>
> >> From: Krystian Samp 
> >> Date: Mon, 2 Sep 2024 12:41:11 +0200
> >>
> >> I was reading the section on "Libraries of Lisp Code for Emacs"
> (section 28.8) in the Emacs manual, and I
> >> encountered a passage that seems a bit unclear. The text suggests that
> when using package-install, Emacs
> >> might automatically add initialization code to the init.el file, which
> doesn’t seem to match my experience.
> >>
> >> Specifically, the manual states: "Installing a package using
> package-install takes care of placing the package’s
> >> Lisp files in a directory where Emacs will find it, and also writes the
> necessary initialization code into your init
> >> files [...]"
> >>
> >> From my understanding, package-install does not modify init.el
> directly, which is how I interpret the
> >> documentation above. Instead, Emacs calls package-initialize which
> makes the installed packages available,
> >> automatically.
> >>
> >> I want to check if this is a valid concern / interpretation that
> warrants a documentation change. If so, I'll be
> >> happy to create a patch.
> >
> > Is package-quickstart.el considered "init file" or not?
> >
> > And I add Philip to this discussion, as he knows the package.el code
> > better than I do.
>
> I believe the documentation here is just outdated.  From NEWS.27:
>
>   ** Installed packages are now activated *before* loading the init file.
>   As a result of this change, it is no longer necessary to call
>   'package-initialize' in your init file.
>
>   Previously, a call to 'package-initialize' was automatically inserted
>   into the init file when Emacs was started.  This call can now safely
>   be removed.
>
> Otherwise it might also refer to the fact that user option
> `package-selected-packages' is saved, which by default will be stored in
> the default Emacs configuration file.
>
> --
> Philip Kaludercic on peregrine
>


0001-Fix-package-install-documentation-on-initialization-.patch
Description: Binary data

bug#73005: [REGRESSION, BISECTED]: line numbers disappear when pressing `df` in evil-mode

[Eli Zaretskii]

> Date: Thu, 5 Sep 2024 00:07:35 +0200
> Cc: 73...@debbugs.gnu.org
> From: David Ponce 
> 
> Could it be that a temporary buffer named " *work*" is being used somewhere?
> In which case there could be nasty side effects with the same buffer being
> used by `with-work-buffer'?

In that case, modifying the name used by with-work-buffer should solve
the problem, I think.

If that doesn't help, either, I guess we do need a reproducer without
Evil, if such a beast exists, because the problem might be in Evil
itself.  If the problem is not in Evil, coming up with a reproducer
will go a long way towards the solution, and might even point out to
the culprit.

bug#73036: 29.4; Test failure in erc-networks--id-sort-buffers

[Ulrich Mueller]

Forwarding Gentoo bug 920696 .

We see the following test failure on an hppa2.0-unknown-linux-gnu
(Linux-6.9.8-gentoo-parisc64-parisc64-PA8900_-Shortfin-with-glibc2.39)
system:

Test erc-networks--id-sort-buffers condition:
(ert-test-failed
 ((should
   (equal
(erc-networks--id-sort-buffers ...)
(list newest middle oldest)))
  :form
  (equal
   (# # #)
   (# # #))
  :value nil :explanation
  (list-elt 0
(different-atoms # #
   FAILED   6/41  erc-networks--id-sort-buffers (0.00 sec) at 
lisp/erc/erc-networks-tests.el:133

[...]

Ran 41 tests, 40 results as expected, 1 unexpected (2024-09-03 20:09:01+, 14
.712021 sec)

1 unexpected results:
   FAILED  erc-networks--id-sort-buffers  ((should (equal (erc-networks--id-sort
-buffers (list oldest newest middle)) (list newest middle oldest))) :form (equal
 (# # #) (# 
# #)) :value nil :explanation (list-elt 0 
(different-atoms # #)))

[...]

SUMMARY OF TEST RESULTS
---
Files examined: 465
Ran 6939 tests, 6675 results as expected, 1 unexpected, 263 skipped
1 files contained unexpected results:
  lisp/erc/erc-networks-tests.log


Looking at the code, the test creates three buffers, then sorts them by
time. Clock resolution on HPPA appears to be 4 milliseconds, so it is
not unlikely that the buffers end up with exactly the same timestamp and
sorting fails.

Attached patch fixes the problem. Is it OK to install it on the emacs-30
branch?

>From bf42248be8e795d591ce97c1d161d73d98038db6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ulrich=20M=C3=BCller?= 
Date: Wed, 4 Sep 2024 13:35:51 +0200
Subject: [PATCH] Fix test failure in erc-networks-tests

* test/lisp/erc/erc-networks-tests.el
(erc-networks--id-sort-buffers): Make sure that buffers have
different timestamps.
---
 test/lisp/erc/erc-networks-tests.el | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/test/lisp/erc/erc-networks-tests.el 
b/test/lisp/erc/erc-networks-tests.el
index f0a7c37ddf2..e84cca68cdd 100644
--- a/test/lisp/erc/erc-networks-tests.el
+++ b/test/lisp/erc/erc-networks-tests.el
@@ -133,10 +133,12 @@ erc-networks--id-sort-buffers
 (with-temp-buffer
   (setq erc-networks--id (erc-networks--id-fixed-create 'oldest)
 oldest (current-buffer))
+  (sleep-for 0.02)
 
   (with-temp-buffer
 (setq erc-networks--id (erc-networks--id-fixed-create 'middle)
   middle (current-buffer))
+(sleep-for 0.02)
 
 (with-temp-buffer
   (setq erc-networks--id (erc-networks--id-fixed-create 'newest)
-- 
2.46.0

bug#72961: Possible documentation improvement: Clarification for package installation

[Eli Zaretskii]

> From: Philip Kaludercic 
> Cc: Krystian Samp ,  72...@debbugs.gnu.org
> Date: Mon, 02 Sep 2024 18:49:40 +
> 
> I believe the documentation here is just outdated.  From NEWS.27:
> 
>   ** Installed packages are now activated *before* loading the init file.
>   As a result of this change, it is no longer necessary to call
>   'package-initialize' in your init file.
> 
>   Previously, a call to 'package-initialize' was automatically inserted
>   into the init file when Emacs was started.  This call can now safely
>   be removed.
> 
> Otherwise it might also refer to the fact that user option
> `package-selected-packages' is saved, which by default will be stored in
> the default Emacs configuration file. 

Thanks, I've updated the text accordingly on the emacs-30 release
branch, and I'm therefore closing this bug.

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

[Juri Linkov]

>>> I'm using tab-bar-mode, and I've included `tab-bar-format-global` in
>>> `tab-bar-format`.  This displays `global-mode-string` on the tab-bar.
>>>
>>> However, in `global-mode-string`, I have `mu4e`.  The tab-bar seems to
>>> remove the hover and mouse click actions from `global-mode-string`.
>>
>> Please show your `global-mode-string` with `mu4e` in it.
>
> I execute describe-variable global-mode-string, it's:
>
> global-mode-string is a variable defined in xdisp.c.
>
> Value
> ((:eval (mu4e--modeline-string)) (t (:eval (lsp--progress-status)))
>  ((t lsp-java-progress-string)) (:eval (exec/git-mode-string))
>  (:eval (exec/gc-mode-string)) flycheck-mode-line)

Also please eval these calls and show their return values.

bug#72961: Possible documentation improvement: Clarification for package installation

[Eli Zaretskii]

> From: Krystian Samp 
> Date: Wed, 4 Sep 2024 23:52:15 +0200
> Cc: Eli Zaretskii , 72...@debbugs.gnu.org
> 
> I'd propose to make a simple change in 28.8 that is consistent with 49.3:
> 
> Original:
> "Note that installing a package using package-install (see Package 
> Installation) takes care of placing the
> package's Lisp files in a directory where Emacs will find it, and also writes 
> the necessary initialization code into
> your init files, making the above manual customizations unnecessary"
> 
> Proposed:
> 
> “Note that installing a package using package-install (see Package 
> Installation) takes care of placing the
> package’s Lisp files in a directory where Emacs will find it. Installed 
> packages are automatically made available
> by Emacs in all subsequent sessions, making the above manual customizations 
> unnecessary.”

Thanks, I modified the text slightly differently.

bug#73036: 29.4; Test failure in erc-networks--id-sort-buffers

[J.P.]

Hi Ulrich,

Author of shoddy test here. Apologies for the annoyance.

Ulrich Mueller  writes:

> Looking at the code, the test creates three buffers, then sorts them by
> time. Clock resolution on HPPA appears to be 4 milliseconds, so it is
> not unlikely that the buffers end up with exactly the same timestamp and
> sorting fails.

Makes sense to me.

> Attached patch fixes the problem. Is it OK to install it on the emacs-30
> branch?

I guess that's up to the Emacs maintainers (Eli Cc'd).

Thanks,
J.P.