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

[João Távora]

Dmitry Gutov  writes:

> On 31/08/2024 15:03, João Távora wrote:
>
>> Eglot aims primarily at that, since it's what's in Emacs proper. But
>> Eglot also aims at supporting Company in particular as fully
>> as possible.
>> 
>> Anyway, I don't have time to investigate this. The :exit-function in
>> eglot.el should be stepped through to understand exactly who's at
>> fault. And I don't think differences between servers matter:
>> clangd is likely following the spec correctly here.
>
> It seems the difference comes from bug#70968 as well (which came up 
> recently).

Okay, but that presumed bug has nothing to do with Eglot, AFAICT.

> When the completion style emacs22 is used, Company doesn't delete the 
> suffix text before inserting completion. Which is an improvement for 
> some other completion sources, but not Eglot, so far.
>
> To to fix this here, we can avoid a fail-over to emacs22 by only 
> matching the prefix in eglot--dumb-allc like this:
>
> diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el
> index 59d9c346424..20c15584d2d 100644
> --- a/lisp/progmodes/eglot.el
> +++ b/lisp/progmodes/eglot.el
> @@ -3138,7 +3138,9 @@ eglot--dumb-flex
> nil comp)
>  finally (cl-return comp)))
>
> -(defun eglot--dumb-allc (pat table pred _point) (funcall table pat pred t))
> +(defun eglot--dumb-allc (pat table pred point)
> +  (funcall table (substring pat 0 point) pred t))
> +
>   (defun eglot--dumb-tryc (pat table pred point)
> (let ((probe (funcall table pat pred nil)))
>   (cond ((eq probe t) t)
>
> That fixes the scenario in Company, with seemingly no change with 
> completion-at-point.

Like in that other recent bug, if you can add some Eglot test that
demonstrates the bug and then apply this fix and verify that it passes
the new tests and all the other tests you added recently, I'm fine with
the change.

> Or if we want 100% compatibility, we can use 'or':
>
>(or
> (funcall table pat pred t)
> (funcall table (substring pat 0 point) pred t))

I don't understand what 100% compatibility this refers to, but if it is
a better change that also passes the aforementioned tests, I'm also fine
with it.

> But in any case this doesn't help with the completion-at-point behavior 
> described at the end of the report (where foo_|bar_2 turns into 
> foo_bar_2bar_2|). If we consider it okay - then the above patch fixes 
> the discrepancy with Company completion, and done. But if we think it a 
> problem, then the fix might be required somewhere in the area of
>
>   (cond (textEdit
>  ;; Revert buffer back to state when the edit
>  ;; was obtained from server. If a `proxy'
>
> After (and if) that is done, we might not need to change the completion 
> style in the end.

Same criteria as above.  What's currently working shall continue
working.  I would advise generally to be conservative here: the bugs
you're fixing seem to be somewhat academic edge cases and not reports by
actual Eglot users.  But same idea: make tests that demonstrate the
bugs, fix those bugs and verify all the existing tests still pass.

The only thing I'd like to add is the following two notes:

* before any of this, you showed earlier a way to completely forbid
  partial completions in Eglot.  That's a good change for reasons we've
  already discussed and it prevents a number of bugs.  I'd like that
  change to be commited first (presuming it does what you expect it to).

* the rust-analyzer test you added recently -- and which you said was
  very brittle -- is indeed very brittle: I cannot get it to pass.  We
  should fix it, or just delete it and do those rust-analyzer tests
  manually each time we touch this area.

João

bug#72453: 29.4; "use-package" macro does not load all expected related files

[Stefan Kangas]

Mattias Engdegård  writes:

> It seems that 644d2a83 and 8f4ad4d7 cause failures in use-package-tests on 
> master (log attached); the tests pass after reverting those commits.

Thanks, this should now be fixed.

bug#72949: [PATCH] Wrong unread count in the Group buffer in nnimap

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

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:

From 6676798c2a60094ddb8a7476bbbf611d9e7d644c Mon Sep 17 00:00:00 2001
From: James Thomas 
Date: Mon, 2 Sep 2024 11:23:11 +0530
Subject: [PATCH] Correct empty mailbox active count

* lisp/gnus/nnimap.el (nnimap-request-group): Make the change.
---
 lisp/gnus/nnimap.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/gnus/nnimap.el b/lisp/gnus/nnimap.el
index 7b0e42ff89d..8e4ad45c62c 100644
--- a/lisp/gnus/nnimap.el
+++ b/lisp/gnus/nnimap.el
@@ -918,7 +918,7 @@ nnimap-request-group
 	(nnimap-finish-retrieve-group-infos server info sequences
 		t)
 	(setq active (nth 2 (assoc group nnimap-current-infos)
-	(setq active (or active '(0 . 1)))
+	(setq active (or active '(1 . 0)))
 	(erase-buffer)
 	(insert (format "211 %d %d %d %S\n"
 			(- (cdr active) (car active))
--
2.43.0


Regards,
James

bug#60321: 29.0.60; ruby-mode indentation of hash or array as first arg in multiline method call

[Aaron Jensen]

Hi Dmitry,

Here's a corrected patch for that particular example. Thank you for finding
that. I think I missed it because as long as you type the code in, it
indents fine. I still have a lot to understand about SMIE, so if anything
looks off in my patch, please let me know.

I didn't change the default. I wasn't sure if you wanted to change the
defaults of all of the variables you added in the last round or just this
one, so I'll let you handle that the way you want to.

Thanks,


Aaron


On Sun, Sep 01, 2024 at 12:36 PM, Dmitry Gutov  wrote:

> Hi Aaron!
>
> On 01/09/2024 03:54, Aaron Jensen wrote:
>
> Updated patch with more precise variables in the new test.
>
> Thanks for taking the initiative.
>
> Here's an example which seems to get worse with the new variable set to
> nil:
>
> def foo
> foo.update(
> {
> key => value,
> other_key: foo
> }
> )
> end
>
> I'd like to flip the default value (now or in Emacs 31), so it would be
> great to deal with examples like this.
>


0001-Add-ruby-bracketed-argument-indentation-option.patch
Description: Binary data

bug#72929: [Norbert Koch] Error building emacs after 73277a4097b

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

"Stefan Kangas"  writes:

> Forwarding the below to the bug tracker in case anyone sees a quick fix.
> I'll be AFK in the next couple of hours or so.

I can reproduce this with --with-x-toolkit=no.  An explicit

#include 

seems to be all that's required, so I've boldly pushed it.

Pip

bug#72915: Docstrings of add-hook and remove-hook improvement?

[Stefan Kangas]

Eli Zaretskii  writes:

>> From: Tomas Nordin 
>> Date: Sat, 31 Aug 2024 12:36:22 +
>>
>> The following on top of emacs-30.
>>
>> diff --git a/lisp/subr.el b/lisp/subr.el
>> index 28ba30f584e..e60c4119c60 100644
>> --- a/lisp/subr.el
>> +++ b/lisp/subr.el
>> @@ -2090,6 +2090,10 @@ add-hook
>>"Add to the value of HOOK the function FUNCTION.
>>  FUNCTION is not added if already present.
>>
>> +HOOK should be a symbol.  If HOOK is void, or if HOOK's value is a
>> +single function, it is changed to a list of functions (containing only
>> +FUNCTION in the void case).
>> +
>>  The place where the function is added depends on the DEPTH
>>  parameter.  DEPTH defaults to 0.  By convention, it should be
>>  a number between -100 and 100 where 100 means that the function
>> @@ -2108,10 +2112,6 @@ add-hook
>>  buffer-local value.  That acts as a flag to run the hook
>>  functions of the global value as well as in the local value.
>>
>> -HOOK should be a symbol.  If HOOK is void, it is first set to
>> -nil.  If HOOK's value is a single function, it is changed to a
>> -list of functions.
>> -
>
> Is the bit about setting HOOK to nil incorrect?  Because the new text
> drops that part.

It makes no difference if HOOK is "first" set to nil from the POV of the
end user, I think.  The end result is that HOOK will be a list of
functions.

IOW, the point here is that `add-hook` will work even if HOOK is void,
and that aspect is preserved in the above change.

>
>>"Remove from the value of HOOK the function FUNCTION.
>>  HOOK should be a symbol, and FUNCTION may be any valid function.  If
>>  FUNCTION isn't the value of HOOK, or, if FUNCTION doesn't appear in the
>> -list of hooks to run in HOOK, then nothing is done.  See `add-hook'.
>> +list of functions to run in HOOK, then nothing is done.  See `add-hook'.
>
> "list of functions to run in HOOK" is ambiguous wrt what "in HOOK"
> refers to.  I would rephrase:
>
>   If FUNCTION is not the value of HOOK and is not a member of the list
>   that is the value of HOOK, do nothing.

While the original is not ideal, I don't find this to be an improvement.
Sorry.  I'd suggest trying to reformulate it again, to make it more
direct and avoid repeating the phrase "the value of".

The wording in the manual is probably all that is needed here:

This function removes FUNCTION from the hook variable HOOK.

In other words, we either get to assume that the user knows what a hook
is, or we can point the user to the relevant manual section to read
about it.

bug#72919: Fwd: bug#72919: 29.1; chart-space-usage in chart.el does not work correctly on windows

[Harm Van der Vegt]

-- Forwarded message -
Van: Harm Van der Vegt 
Date: zo 1 sep 2024 om 20:11
Subject: Re: bug#72919: 29.1; chart-space-usage in chart.el does not work
correctly on windows
To: Eli Zaretskii 


>Thanks.  However, I think your changes are not entirely correct: they
>fail to account for space usage of files inside subdirectories of the
>directory which the user types at the prompt, whereas the
>implementation with "du" does account for that.

That is indeed a pretty major difference, my bad!

>In addition, I think if someone has 'du' on Windows, it should be used.

Is there a preference for using system binaries above elisp for cases like
these?

>So I came up with the following changes instead.  Could you please try
>them, both with and without du.exe on PATH?  If these changes give
>good results, I will install them.

Thanks.

I've tried your changes with and without du. This uncovered something in the
original implementation, namely that the original implementation did not
count
hidden files and directories. du * skips dotfiles for me.

With du present chart-space-usage shows the lisp directory as the largest
in the
emacs repository root. Without du it shows .git as the largest.

I'm not sure which output is the wanted output.

I've attempted to find a shell independent way to have du show dotfiles,
but it
appears to be rather tricky.

I've made a new patch that makes the elisp implementation recursive, uses
the
rounding function provided by you and shows dotfiles.

Op zo 1 sep 2024 om 10:13 schreef Eli Zaretskii :

> > From: Harm Van der Vegt 
> > Date: Sat, 31 Aug 2024 20:52:41 +0200
> >
> > Load the builtin chart package. When chart-space-usage is run, targeting
> > any directory, chart fails to find any files and therefore can't create
> > the chart. The expected behavior is that a bar chart is shown, ranking
> > the files of the directory by size.
> >
> > This only fails on my Windows machine, it works on my Ubuntu
> > installation.
> >
> > The output as shown in *Messages* is as follows:
> >
> > Collecting statistics...
> > Running ‘cd g:/Shakespeare/;du -sk *’...
> > Scanning output ...
> > chart-space-usage: No files found!
>
> Yes, the current implementation is not portable.
>
> > chart-space-usage makes use of the du (disk usage) utility, which might
> > not be present on all machines. In my case I have du installed, but
> > chart-space-usage still failed to find any files.
> >
> > I have patched chart-space-usage to remove the dependency on du and make
> > it OS agnostic and attached the patch to this email.
>
> Thanks.  However, I think your changes are not entirely correct: they
> fail to account for space usage of files inside subdirectories of the
> directory which the user types at the prompt, whereas the
> implementation with "du" does account for that.  In addition, I think
> if someone has 'du' on Windows, it should be used.
>
> So I came up with the following changes instead.  Could you please try
> them, both with and without du.exe on PATH?  If these changes give
> good results, I will install them.
>
> diff --git a/lisp/emacs-lisp/chart.el b/lisp/emacs-lisp/chart.el
> index da61e45..03dbe33 100644
> --- a/lisp/emacs-lisp/chart.el
> +++ b/lisp/emacs-lisp/chart.el
> @@ -641,27 +641,63 @@ chart-file-count
>(lambda (a b) (> (cdr a) (cdr b
>  ))
>
> +;; This assumes 4KB blocks
> +(defun chart--file-size (size)
> +  (* (/ (+ size 4095) 4096) 4096))
> +
> +(defun chart--directory-size (dir)
> +  "Compute total size of files in directory DIR and its subdirectories.
> +DIR is assumed to be a directory, verified by the caller."
> +  (let ((size 0))
> +(dolist (file (directory-files-recursively dir "." t))
> +  (let ((fsize (nth 7 (file-attributes file
> +(if (> fsize 0)
> +(setq size
> +  (+ size (chart--file-size fsize))
> +size))
> +
>  (defun chart-space-usage (d)
>"Display a top usage chart for directory D."
>(interactive "DDirectory: ")
>(message "Collecting statistics...")
>(let ((nmlst nil)
> (cntlst nil)
> -   (b (get-buffer-create " *du-tmp*")))
> -(set-buffer b)
> -(erase-buffer)
> -(insert "cd " d ";du -sk * \n")
> -(message "Running `cd %s;du -sk *'..." d)
> -(call-process-region (point-min) (point-max) shell-file-name t
> -(current-buffer) nil)
> -(goto-char (point-min))
> -(message "Scanning output ...")
> -(while (re-search-forward "^\\([0-9]+\\)[ \t]+\\([^ \n]+\\)$" nil t)
> -  (let* ((nam (buffer-substring (match-beginning 2) (match-end 2)))
> -(num (buffer-substring (match-beginning 1) (match-end 1
> -   (setq nmlst (cons nam nmlst)
> - ;; * 1000 to put it into bytes
> - cntlst (cons (* (string-to-number num) 1000) cntlst
> +b)
> +(if (executable-find "du")
> +(progn
> + (setq b (get-buffer-create " *du-tmp*"))
> 

bug#72787: 31.0.50; Invalid describe-function completion candidates

[Eli Zaretskii]

reopen 72787
thanks

> From: Eshel Yaron 
> Cc: Stefan Monnier ,  michael_heerde...@web.de,
>   72787-d...@debbugs.gnu.org,  pip...@protonmail.com
> Date: Sun, 01 Sep 2024 19:41:47 +0200
> 
> Thanks, but the issue remains, so shouldn't the bug remain open as well?

I reopened it.

bug#72945: 29.4; Org: ox-html: attr_html not supported in source code and fixed-width blocks during HTML export

[Suhail Singh]

Since more than a month has gone by, I am creating this issue to ease
tracking.  This issue was first mentioned in this post:
.  Details
cross-posted below.

Unlike example blocks, source code and fixed-width blocks don't support
the attr_html keyword.  Contrast these outputs:

#+begin_src emacs-lisp :results value replace :wrap src html
  (require 'org)
  (require 'ox-html)

  (org-export-string-as
   "#+attr_html: :class foo
  ,#+begin_src sh :exports code
pwd
  ,#+end_src"
   'html t)
#+end_src

#+RESULTS:
#+begin_src html

pwd


#+end_src


#+begin_src emacs-lisp :results value replace :wrap src html
  (require 'org)
  (require 'ox-html)

  (org-export-string-as
   "#+attr_html: :class foo
  ,#+RESULTS:
  : blah"
   'html t)
#+end_src

#+RESULTS:
#+begin_src html

blah

#+end_src


With the output for example blocks:

#+begin_src emacs-lisp :results value replace :wrap src html
  (require 'org)
  (require 'ox-html)

  (org-export-string-as
   "#+attr_html: :class foo
  ,#+begin_example
hello world!
  ,#+end_example"
   'html t)
#+end_src

#+RESULTS:
#+begin_src html

hello world!

#+end_src



In GNU Emacs 29.4 (build 2, x86_64-suse-linux-gnu, GTK+ Version 3.24.43,
cairo version 1.18.0)
System Description: openSUSE Tumbleweed

Configured using:
 'configure --disable-build-details --without-pop --with-mailutils
 --with-native-compilation --without-hesiod --with-gameuser=:games
 --with-kerberos --with-kerberos5 --with-file-notification=inotify
 --with-modules --enable-autodepend --prefix=/usr
 --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share
 --localstatedir=/var --sharedstatedir=/var/lib
 --libexecdir=/usr/libexec --with-file-notification=yes
 --libdir=/usr/lib64
 
--enable-locallisppath=/usr/share/emacs/29.4/site-lisp:/usr/share/emacs/site-lisp
 --with-x --with-xim --with-sound --with-xpm --with-jpeg --with-tiff
 --with-gif --with-png --with-rsvg --with-dbus --with-webp --with-xft
 --with-imagemagick --without-gpm --with-x-toolkit=gtk3 --with-pgtk
 --with-toolkit-scroll-bars --x-includes=/usr/include
 --x-libraries=/usr/lib64 --with-libotf --with-m17n-flt --with-cairo
 --with-xwidgets --build=x86_64-suse-linux --with-dumping=pdumper
 'CFLAGS=-O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3
 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables
 -fstack-clash-protection -Werror=return-type -flto=auto -g
 -D_GNU_SOURCE -DGDK_DISABLE_DEPRECATION_WARNINGS
 -DGLIB_DISABLE_DEPRECATION_WARNINGS -pipe -Wno-pointer-sign
 -Wno-unused-variable -Wno-unused-label -fno-optimize-sibling-calls
 -DPDMP_BASE='\''"emacs-wayland"'\''' LDFLAGS=-Wl,-O2'

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

Important settings:
  value of $LC_NUMERIC: POSIX
  value of $LC_TIME: en_US.UTF-8
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  eros-mode: t
  yas-global-mode: t
  yas-minor-mode: t
  global-orglink-mode: t
  TeX-PDF-mode: t
  abridge-diff-mode: t
  global-git-commit-mode: t
  magit-auto-revert-mode: t
  envrc-global-mode: t
  envrc-mode: t
  which-key-mode: t
  flycheck-status-emoji-mode: t
  global-flycheck-mode: t
  coterm-mode: t
  shell-dirtrack-mode: t
  selected-global-mode: t
  selected-minor-mode: t
  async-bytecomp-package-mode: t
  marginalia-mode: t
  pixel-scroll-precision-mode: t
  which-function-mode: t
  save-place-mode: t
  repeat-mode: t
  minibuffer-depth-indicate-mode: t
  electric-pair-mode: t
  my/keys-minor-mode: t
  override-global-mode: t
  el-patch-use-package-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  buffer-read-only: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  view-mode: t

Load-path shadows:
/home/user/.emacs.d/elpa/helm-4.0/helm-packages hides 
/home/user/.emacs.d/elpa/helm-core-4.0/helm-packages
/home/user/.emacs.d/elpa/magit-4.0.0/magit hides 
/home/user/.emacs.d/elpa/git-commit-4.1.0/magit
/home/user/.emacs.d/elpa/magit-4.0.0/magit-worktree hides 
/home/user/.emacs.d/elpa/git-commit-4.1.0/magit-worktree
/home/user/.emacs.d/elpa/magit-4.0.0/magit-wip hides 
/home/user/.emacs.d/elpa/git-commit-4.1.0/magit-wip
/home/user/.emacs.d/elpa/magit-4.0.0/magit-transient hides 
/home/user/.emacs.d/elpa/git-commit-4.1.0/magit-transient
/home/user/.emacs.d/elpa/magit-4.0.0/magit-tag hides 
/home/user/.emacs.d/elpa/git-commit-4.1.0/magit-tag
/home/user/.emacs.d/elpa/magit-4.0.0/magit-subtree hides 
/home/u

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

[Dmitry Gutov]

On 01/09/2024 12:43, João Távora wrote:


It seems the difference comes from bug#70968 as well (which came up
recently).


Okay, but that presumed bug has nothing to do with Eglot, AFAICT.


One could argue that the current definition of the style (in Eglot) 
relies on buggy (or suboptimal) behavior in completion-at-point.



-(defun eglot--dumb-allc (pat table pred _point) (funcall table pat pred t))
+(defun eglot--dumb-allc (pat table pred point)
+  (funcall table (substring pat 0 point) pred t))
+
   (defun eglot--dumb-tryc (pat table pred point)
 (let ((probe (funcall table pat pred nil)))
   (cond ((eq probe t) t)

That fixes the scenario in Company, with seemingly no change with
completion-at-point.


Like in that other recent bug, if you can add some Eglot test that
demonstrates the bug and then apply this fix and verify that it passes
the new tests and all the other tests you added recently, I'm fine with
the change.


Sure.


Or if we want 100% compatibility, we can use 'or':

(or
 (funcall table pat pred t)
 (funcall table (substring pat 0 point) pred t))


I don't understand what 100% compatibility this refers to, but if it is
a better change that also passes the aforementioned tests, I'm also fine
with it.


One patch simply doesn't filter by the suffix, and another first tries 
filtering by prefix+suffix and if nothing matches falls back to 
filtering by prefix only.



But in any case this doesn't help with the completion-at-point behavior
described at the end of the report (where foo_|bar_2 turns into
foo_bar_2bar_2|). If we consider it okay - then the above patch fixes
the discrepancy with Company completion, and done. But if we think it a
problem, then the fix might be required somewhere in the area of

   (cond (textEdit
  ;; Revert buffer back to state when the edit
  ;; was obtained from server. If a `proxy'

After (and if) that is done, we might not need to change the completion
style in the end.


Same criteria as above.


Alas, I have a fix which works for Company but not so well for 
completion-at-point:


diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el
index 59d9c346424..197e7d9869d 100644
--- a/lisp/progmodes/eglot.el
+++ b/lisp/progmodes/eglot.el
@@ -3353,7 +3353,6 @@ eglot-completion-at-point
 ;; "foo.b", the LSP edit applies to that
 ;; state, _not_ the current "foo.bar".
 (delete-region orig-pos (point))
-(insert (substring bounds-string (- orig-pos 
(car bounds

 (eglot--dbind ((TextEdit) range newText) textEdit
   (pcase-let ((`(,beg . ,end)
(eglot-range-region range)))

It fixes the main scenario with both UIs - but when the suffix is not 
matching, exit-function can delete too much text.


E.g. v.count|123.123456789 turns into v.count_ones()3456789

That's the example from the recently added test.


What's currently working shall continue
working.  I would advise generally to be conservative here: the bugs
you're fixing seem to be somewhat academic edge cases and not reports by
actual Eglot users.


I agree that this report is not very critical (and so can wait), but I 
don't think I'll be the only person to trigger it. Just hopefully it 
won't happen too often.



The only thing I'd like to add is the following two notes:

* before any of this, you showed earlier a way to completely forbid
   partial completions in Eglot.  That's a good change for reasons we've
   already discussed and it prevents a number of bugs.  I'd like that
   change to be commited first (presuming it does what you expect it to).


Said reasons were also more of "academic" nature, right?

That change would be removing a certain bit of functionality from the 
completion UIs, so I'd rather only do that in the face of hard evidence.



* the rust-analyzer test you added recently -- and which you said was
   very brittle -- is indeed very brittle: I cannot get it to pass.  We
   should fix it, or just delete it and do those rust-analyzer tests
   manually each time we touch this area.


Could you give more details? It is indeed more brittle in theory, but on 
my machine it's passing every time.


No failures from our CIs have been reported either, although that might 
not be saying much.

bug#72919: 29.1; chart-space-usage in chart.el does not work correctly on windows

[Harm Van der Vegt]

Clear, thanks for the response!

Op zo 1 sep 2024 om 20:35 schreef Eli Zaretskii :

> [Please use Reply All to reply, so that the bug tracker is CC'ed.]
>
> > From: Harm Van der Vegt 
> > Date: Sun, 1 Sep 2024 20:11:39 +0200
> >
> > >Thanks.  However, I think your changes are not entirely correct: they
> > >fail to account for space usage of files inside subdirectories of the
> > >directory which the user types at the prompt, whereas the
> > >implementation with "du" does account for that.
> >
> > That is indeed a pretty major difference, my bad!
> >
> > >In addition, I think if someone has 'du' on Windows, it should be used.
> >
> > Is there a preference for using system binaries above elisp for cases
> like these?
>
> I think 'du' has some tricks up its sleeve (like accounting correctly
> for block size), which a Lisp implementation can only approximate.  I
> don't think minor differences matter here, since this command is just
> an illustration of what chart.el can be used for, but I do want to use
> 'du' if it's available.
>
> > >So I came up with the following changes instead.  Could you please try
> > >them, both with and without du.exe on PATH?  If these changes give
> > >good results, I will install them.
> >
> > Thanks.
> >
> > I've tried your changes with and without du. This uncovered something in
> the
> > original implementation, namely that the original implementation did not
> count
> > hidden files and directories. du * skips dotfiles for me.
> >
> > With du present chart-space-usage shows the lisp directory as the
> largest in the
> > emacs repository root. Without du it shows .git as the largest.
>
> This just means minor adjustments in the code I posted: we need to use
> a different regexp in the call to directory-files-recursively, and
> also ignore files that start with a dot in the command itself.  I will
> make those changes, thanks for pointing them out
>
> > I'm not sure which output is the wanted output.
>
> I think we want to be as close to 'du' as possible.
>
> > I've attempted to find a shell independent way to have du show dotfiles,
> but it
> > appears to be rather tricky.
>
> I don't think we want that.
>
> > I've made a new patch that makes the elisp implementation recursive,
> uses the
> > rounding function provided by you and shows dotfiles.
>
> I'd prefer to avoid recursion (in addition to what
> directory-files-recursively already does), because that could overflow
> the stack.
>
> I will post a version that ignores dotfiles.
>
> Here's the version you sent, repeated for the bug tracker:
>
> >From 6f53d65f9ae5e1c61a2ca2650b149c895ce9794c Mon Sep 17 00:00:00 2001
> >From: Harm van der Vegt 
> Date: Sun, 1 Sep 2024 20:03:34 +0200
> Subject: [PATCH] Make chart-space-usage OS and shell independent
>
> ---
>  lisp/emacs-lisp/chart.el | 41 +
>  1 file changed, 29 insertions(+), 12 deletions(-)
>
> diff --git a/lisp/emacs-lisp/chart.el b/lisp/emacs-lisp/chart.el
> index c195ccb7165..b0302b55278 100644
> --- a/lisp/emacs-lisp/chart.el
> +++ b/lisp/emacs-lisp/chart.el
> @@ -641,27 +641,44 @@ SORT-PRED if desired."
>(lambda (a b) (> (cdr a) (cdr b
>  ))
>
> +;; This assumes 4KB blocks
> +(defun chart--file-size (size)
> +  (* (/ (+ size 4095) 4096) 4096))
> +
> +(defun chart--directory-size (dir)
> +  "Compute total size of files in directory DIR and its subdirectories.
> +DIR is assumed to be a directory, verified by the caller."
> +  (let ((total-size 0))
> +(dolist (file (directory-files dir t
> directory-files-no-dot-files-regexp))
> +  (cond
> +   ((file-regular-p file)
> +(setq total-size (+ total-size (chart--file-size (nth 7
> (file-attributes file))
> +   ((file-directory-p file)
> +(setq total-size (+ total-size (chart--directory-size file))
> +total-size))
> +
>  (defun chart-space-usage (d)
>"Display a top usage chart for directory D."
>(interactive "DDirectory: ")
>(message "Collecting statistics...")
>(let ((nmlst nil)
> -(cntlst nil))
> -(dolist (file (directory-files d t))
> -  (when (file-regular-p file)
> -(let ((size (nth 7 (file-attributes file
> +   (cntlst nil))
> +
> +(dolist (file (directory-files d t
> directory-files-no-dot-files-regexp))
> +(let ((size (if (file-regular-p file)
> +(nth 7 (file-attributes file))
> +  (chart--directory-size file
>(setq nmlst (cons (file-name-nondirectory file) nmlst))
> -  (setq cntlst (cons size cntlst)
> +  (setq cntlst (cons (chart--file-size size) cntlst
>
>  (if (not nmlst)
> -(error "No files found!"))
> -
> -;; Display the chart if files are found
> +   (error "No files found!"))
>  (chart-bar-quickie 'vertical (format "Largest files in %s" d)
> -   nmlst "File Name"
> -   cntlst "File Size"
> -  

bug#60321: 29.0.60; ruby-mode indentation of hash or array as first arg in multiline method call

[Dmitry Gutov]

On 01/09/2024 22:28, Aaron Jensen wrote:

Here's a corrected patch for that particular example. Thank you for 
finding that. I think I missed it because as long as you type the code 
in, it indents fine. I still have a lot to understand about SMIE, so if 
anything looks off in my patch, please let me know.


Thanks! Just being thorough. We can add this example to the args-indent 
test file, too.


Here's a bonus example which looks off but would be more difficult to 
fix (and it's not urgent, given the expression is in mixed styles):


foo([{
  a: 2
},
 {
   b: 3
 },
 4
])


It would be nice to at least handle the last arg correctly - maybe we'll 
just get that supported in the ts mode at some later date.


I didn't change the default. I wasn't sure if you wanted to change the 
defaults of all of the variables you added in the last round or just 
this one, so I'll let you handle that the way you want to.


Sure. I think we can add this into Emacs 30 too, while the change is off 
by default.


A few other things:

* I think the docstring should say "Set it to nil to align to the line 
with the open bracket" - it doesn't necessarily align to the beginning 
of the statement (seems like a good thing).


* Let's change the first example to this, for less ambiguity?

  foo
.update({
  key => value,
  other_key:
}, {
  key => value,
  other_key:
})


* Support for the new option in ruby-ts-mode (it's good to have parity). 
Could you take the attached patch for a spin? Seems to work here, but 
I'd like to have an extra confirmation.diff --git a/lisp/progmodes/ruby-ts-mode.el b/lisp/progmodes/ruby-ts-mode.el
index 5f4e11e0b4c..adcdf15c7ad 100644
--- a/lisp/progmodes/ruby-ts-mode.el
+++ b/lisp/progmodes/ruby-ts-mode.el
@@ -842,6 +842,16 @@ ruby-ts--parent-call-or-bol
  ;; No paren/curly/brace found on the same line.
  ((< (treesit-node-start found) parent-bol)
   parent-bol)
+ ;; Nesting of brackets args.
+ ((and
+   (not (eq ruby-bracketed-args-indent t))
+   (string-match-p "\\`array\\|hash\\'" (treesit-node-type parent))
+   (equal (treesit-node-parent parent) found)
+   ;; Grandparent is not a parenless call.
+   (or (not (equal (treesit-node-type found) "argument_list"))
+   (equal (treesit-node-type (treesit-node-child found 0))
+  "(")))
+  parent-bol)
  ;; Hash or array opener on the same line.
  ((string-match-p "\\`array\\|hash\\'" (treesit-node-type found))
   (save-excursion
diff --git a/test/lisp/progmodes/ruby-ts-mode-tests.el b/test/lisp/progmodes/ruby-ts-mode-tests.el
index 61ef80eb610..05d98974acf 100644
--- a/test/lisp/progmodes/ruby-ts-mode-tests.el
+++ b/test/lisp/progmodes/ruby-ts-mode-tests.el
@@ -326,6 +326,7 @@ "ruby-block-indent.rb"
 (ruby-ts-deftest-indent "ruby-method-call-indent.rb")
 (ruby-ts-deftest-indent "ruby-method-params-indent.rb")
 (ruby-ts-deftest-indent "ruby-parenless-call-arguments-indent.rb")
+(ruby-ts-deftest-indent "ruby-bracketed-args-indent.rb")
 
 (provide 'ruby-ts-mode-tests)
 

bug#72787: 31.0.50; Invalid describe-function completion candidates

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

Eli Zaretskii  writes:

>> Cc: 72...@debbugs.gnu.org, m...@eshelyaron.com, Pip Cet 
>> 
>> Date: Sun, 25 Aug 2024 22:37:01 -0400
>> From:  Stefan Monnier via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" 
>> 
>> >> This appears to be caused by commit
>> >> 45ae4de0e7ce99c88c62f940f605bca693b8e33f:
>> >>
>> >> * lisp/help-fns.el (help-definition-prefixes): Don't delete the hashtable
>> > Stefan's commit indeed seems related.  Stefan, could you maybe
>> > have a look please?
>> 
>> I think this report makes it clear that
>> 45ae4de0e7ce99c88c62f940f605bca693b8e33f should not have gone to
>> `emacs-30` but to `master`.  AFAIK it did not fix a regression or even
>> a user-visible bug.
>
> Thanks, I've therefore reverted the above commit from the emacs-30
> release branch, and I'm closing this bug.

Thanks, but the issue remains, so shouldn't the bug remain open as well?


Best,

Eshel

bug#72949: [PATCH] Wrong unread count in the Group buffer in nnimap

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

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:

Sorry, that was an earlier attempt. This is the one I'm using now:

From a2c19066746d49f5ed1f61d6da670ab0b72c7341 Mon Sep 17 00:00:00 2001
From: James Thomas 
Date: Mon, 2 Sep 2024 11:35:38 +0530
Subject: [PATCH] Correct empty mailbox active count

* lisp/gnus/nnimap.el (nnimap-request-group): Make the change.
---
 lisp/gnus/nnimap.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/gnus/nnimap.el b/lisp/gnus/nnimap.el
index 7b0e42ff89d..9de5b14d21b 100644
--- a/lisp/gnus/nnimap.el
+++ b/lisp/gnus/nnimap.el
@@ -922,8 +922,8 @@ nnimap-request-group
 	(erase-buffer)
 	(insert (format "211 %d %d %d %S\n"
 			(- (cdr active) (car active))
-			(car active)
 			(cdr active)
+			(car active)
 			group))
 	t

--
2.43.0


Regards,
James

bug#71646: 29.3; pixel-scroll-precision-mode overrides paging behaviour even when pixel-scroll-precision-interpolate-page is off

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

Stefan Kangas  writes:

> Eli Zaretskii  writes:
>
>> Ping! Should I close this?
>
> Shouldn't we rather fix the bug described by Mike?  I.e. this:
>
>> Setting `pixel-scroll-precision-interpolate-page’ is supposed to
>> turn off the paging animation (which it does) however even when it’s
>> off,  and  invoke `cua-scroll-up’ & `cua-scroll-down’
>> rather than allowing another keymap to handle it.

This isn't a bug.  If ever there was a time to object to these
semantics, it was two years ago, at which time all I heard was
enthusiastic support.

bug#72929: [Norbert Koch] Error building emacs after 73277a4097b

[Stefan Kangas]

Hi Norbert,

Thanks for reporting this.

Forwarding the below to the bug tracker in case anyone sees a quick fix.
I'll be AFK in the next couple of hours or so.

FWIW, I can't reproduce the below on macOS 15 or Ubuntu 22.04 LTS.

Did you try `make bootstrap`?  Could you include your build details as
per `M-x report-emacs-bug`?

 Start of forwarded message 
From: Norbert Koch
To: Stefan Kangas
Subject: Error building emacs after 73277a4097b
Date: Sun, 01 Sep 2024 16:14:22 +0200

Hello Stefan,

sorry to disturb you, but I get an error when building emacs on my
Debian sid:

--8<---cut here---start->8---
image.c: In function ‘xpm_str_to_int’:
image.c:6254:17: error: implicit declaration of function ‘strtol’; did
you mean ‘strtok’? [-Wimplicit-function-declaration]
 6254 |   long result = strtol (*buf, &p, 10);
  | ^~
  | strtok
image.c:6254:17: warning: nested extern declaration of ‘strtol’
[-Wnested-externs]
In file included from ../lib/stdlib.h:49,
 from /usr/include/glib-2.0/glib/gutils.h:426,
 from /usr/include/glib-2.0/glib/gthread.h:36,
 from /usr/include/glib-2.0/glib/gasyncqueue.h:34,
 from /usr/include/glib-2.0/glib.h:34,
 from /usr/include/glib-2.0/gobject/gbinding.h:30,
 from /usr/include/glib-2.0/glib-object.h:24,
 from /usr/include/librsvg-2.0/librsvg/rsvg.h:30,
 from image.c:11649:
/usr/include/stdlib.h: At top level:
/usr/include/stdlib.h:177:17: error: conflicting types for ‘strtol’;
have ‘long int(const char * restrict,  char ** restrict,  int)’
  177 | extern long int strtol (const char *__restrict __nptr,
  | ^~
image.c:6254:17: note: previous implicit declaration of ‘strtol’ with
type ‘int()’
 6254 |   long result = strtol (*buf, &p, 10);
  | ^~
--8<---cut here---end--->8---


Regards,
Norbert
-- 
 End of forwarded message 

bug#72573: 29.4; js-mode/JSX: forward-sexp behavior at end of string in JSX fragments

[Juri Linkov]

>> @@ -3929,7 +3929,8 @@ js-ts-mode
>> (sexp ,(js--regexp-opt-symbol js--treesit-sexp-nodes))
>> (sentence ,(js--regexp-opt-symbol 
>> js--treesit-sentence-nodes))
>> (text ,(js--regexp-opt-symbol '("comment"
>> -   "template_string"))
>> +   "template_string"
>> +   "string_fragment"))
>> 
>> But since this bug report about the default non-ts behavior,
>> I have no idea why the default forward-sexp-function moves to
>> the beginning of the next string.  Maybe this was implemented
>> because the default ad-hoc syntax parsing is not reliable and might
>> mix up string beginnings and endings.  tree-sitter has no such problem.
>
> So what is our way forward with this?  Should we install the above
> patch, or should we close this bug ans wontfix?

I pushed the above patch with small changes to master.

Since the report was about non-ts modes, and it's not easy to change
the default behavior, probably this can be closed as wontfix.

bug#72597: 30.0.60; Eglot: MarkedString with embedded Carriage Return

[Troy Brown]

On Sat, Aug 31, 2024 at 3:55 AM Eli Zaretskii  wrote:
>
> Ping! How can we make progress with this issue?
>

Just FYI, for the time being I've been using this "return filter"
advice on eglot--format-markup which splits all lines irregardless of
the EOL marker and rejoins them with a newline.  It's a bit
heavy-handed, but it gets the job done.

(defun init.el/fix-eol/eglot--format-markup (value)
  (let ((strings (list value)))
(dolist (eol '("\r\n" "\n" "\r"))
  (setq strings
(flatten-list (mapcar (lambda (value)
(split-string value eol))
  strings
(string-join strings "\n")))

(advice-add 'eglot--format-markup :filter-return
#'init.el/fix-eol/eglot--format-markup)

bug#72945: [PATCH 2/2] ox-html: Add support for attr_html in fixed-width blocks

[Suhail Singh]

* lisp/ox-html.el (org-html-fixed-width): Handle attr_html in a manner
similar to example blocks.

TINYCHANGE
---
 lisp/ox-html.el | 20 +++-
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index 3e83f02e2..a85b1e6ac 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -2728,13 +2728,23 @@ (defun org-html-export-block
 
  Fixed Width
 
-(defun org-html-fixed-width (fixed-width _contents _info)
+(defun org-html-fixed-width (fixed-width _contents info)
   "Transcode a FIXED-WIDTH element from Org to HTML.
 CONTENTS is nil.  INFO is a plist holding contextual information."
-  (format "\n%s"
- (org-html-do-format-code
-  (org-remove-indentation
-   (org-element-property :value fixed-width)
+  (let ((attributes (org-export-read-attribute :attr_html fixed-width)))
+(if-let ((class-val (plist-get attributes :class)))
+(setq attributes (plist-put attributes :class (concat "example " 
class-val)))
+  (setq attributes (plist-put attributes :class "example")))
+(format "\n%s"
+(let* ((reference (org-html--reference fixed-width info))
+  (a (org-html--make-attribute-string
+  (if (or (not reference) (plist-member attributes :id))
+  attributes
+(plist-put attributes :id reference)
+ (if (org-string-nw-p a) (concat " " a) ""))
+   (org-html-do-format-code
+(org-remove-indentation
+ (org-element-property :value fixed-width))
 
  Footnote Reference
 
-- 
2.46.0

bug#72915: Docstrings of add-hook and remove-hook improvement?

[Stefan Kangas]

Stefan Kangas  writes:

> The wording in the manual is probably all that is needed here:
>
> This function removes FUNCTION from the hook variable HOOK.

BTW.  Here's another idea:

If HOOK is a list of functions, remove FUNCTION from that list.

If HOOK is equal to FUNCTION, set HOOK to nil.

Otherwise do nothing.

bug#71646: 29.3; pixel-scroll-precision-mode overrides paging behaviour even when pixel-scroll-precision-interpolate-page is off

[Eli Zaretskii]

> From: Stefan Kangas 
> Date: Sun, 1 Sep 2024 02:48:57 -0700
> Cc: m...@bulsara.com, 71...@debbugs.gnu.org
> 
> Eli Zaretskii  writes:
> 
> > Ping! Should I close this?
> 
> Shouldn't we rather fix the bug described by Mike?  I.e. this:
> 
> > Setting `pixel-scroll-precision-interpolate-page’ is supposed to
> > turn off the paging animation (which it does) however even when it’s
> > off,  and  invoke `cua-scroll-up’ & `cua-scroll-down’
> > rather than allowing another keymap to handle it.

I don't mind to fixing this, if possible, but (a) I don't think I
understand what is being suggested by the text you quote above, and
(b) given Po Lu's response, it doesn't seem like the proposed changes
will be accepted, or did I miss something?

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

[Philip Kaludercic]

Eli Zaretskii  writes:

>> From: Sean Whitton 
>> Date: Mon, 06 May 2024 17:51:48 +0100
>> 
>> On Mon 06 May 2024 at 05:46pm +01, Sean Whitton wrote:
>> >
>> > In bash on Linux [...]
>> 
>> I specifically called out Linux because while GNU readline has a
>> unix-word-rubout command, C-w in the Linux tty is actually implemented
>> in the Linux-specific tty layer, below readline.
>
> Evidently, the above is inaccurate, because I see the same behavior in
> Bash on MS-Windows.

Ping.  I am not sure how to proceed on this patch.  IIRC the issue was
that the notion of a word differs in Emacs and in Bash.  I am still in
favour of utilising Emacs's definition, as it remains more useful
for some given major mode and the fact that it is easier to implement.

-- 
Philip Kaludercic on peregrine

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

[Sean Whitton]

Hello,

On Sun 01 Sep 2024 at 08:06pm GMT, Philip Kaludercic wrote:

> Ping.  I am not sure how to proceed on this patch.  IIRC the issue was
> that the notion of a word differs in Emacs and in Bash.  I am still in
> favour of utilising Emacs's definition, as it remains more useful
> for some given major mode and the fact that it is easier to implement.

Please take a look at my longer message.  I don't think it has been
addressed.

-- 
Sean Whitton

bug#72757: No symbols in etc/NEWS

[Juri Linkov]

close 72757 30.0.60
thanks

>> > M-: (modify-syntax-entry ?' "\"") RET
>> >
>> > in the NEWS buffer and C-h o seems to work everywhere.  I am not sure if
>> > we want ' to be "string quote" or punctuation like " already is, or
>> > something else.
>> 
>> Thanks, this looks like the right thing to do.
>
> I made that change, but please note that it is not enough to show each
> symbol in NEWS as the default when you type "C-h o".  This is because
> "C-h o" tests symbol-at-point for being bound, either as a function or
> a variable or a face etc., and if the corresponding library is not yet
> loaded, those tests will fail.

The problem was that 'describe-symbol' uses 'function-called-at-point',
but not anything to get a variable at point.  But now this is fixed,
and when a library is not loaded this is not a problem.

> If this is deemed okay, we can close this bug.

So I'm closing this bug.  The fix helped me to check
documentation while rereading some parts of etc/NEWS,
so small doc fixes are pushed now as well.

bug#60321: 29.0.60; ruby-mode indentation of hash or array as first arg in multiline method call

[Aaron Jensen]

On Sun, Sep 1, 2024 at 8:19 PM Dmitry Gutov  wrote:
>
> On 01/09/2024 22:28, Aaron Jensen wrote:
>
> > Here's a corrected patch for that particular example. Thank you for
> > finding that. I think I missed it because as long as you type the code
> > in, it indents fine. I still have a lot to understand about SMIE, so if
> > anything looks off in my patch, please let me know.
>
> Thanks! Just being thorough. We can add this example to the args-indent
> test file, too.
>
> Here's a bonus example which looks off but would be more difficult to
> fix (and it's not urgent, given the expression is in mixed styles):
>
> foo([{
>a: 2
> },
>   {
> b: 3
>   },
>   4
>  ])

Yes, that's connected to the case I mentioned... how do you think it
should be indented? I wonder if it should just be 2 spaces in (rather
than aligned with the opening bracket)

> It would be nice to at least handle the last arg correctly - maybe we'll
> just get that supported in the ts mode at some later date.
>
> > I didn't change the default. I wasn't sure if you wanted to change the
> > defaults of all of the variables you added in the last round or just
> > this one, so I'll let you handle that the way you want to.
>
> Sure. I think we can add this into Emacs 30 too, while the change is off
> by default.

Sounds good.

> A few other things:
>
> * I think the docstring should say "Set it to nil to align to the line
> with the open bracket" - it doesn't necessarily align to the beginning
> of the statement (seems like a good thing).

Good call.

> * Let's change the first example to this, for less ambiguity?
>
>foo
>  .update({
>key => value,
>other_key:
>  }, {
>key => value,
>other_key:
>  })
>

Done

> * Support for the new option in ruby-ts-mode (it's good to have parity).
> Could you take the attached patch for a spin? Seems to work here, but
> I'd like to have an extra confirmation.

I don't have the treesitter stuff installed at the moment, will try
this out shortly.

Thanks,

Aaron


0001-Add-ruby-bracketed-argument-indentation-option.patch
Description: Binary data

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

[Paul Nelson]

> > This patch binds functions in Ediff that copy all changes from one
> > buffer to another, without having to manually go through each
> > difference.  Any feedback welcome.
>
> Can you describe situation(s) where these commands will be useful?

I use Ediff to merge documents outside of git, like when
working with someone over email or using a computer program to
refactor code.  Sometimes all changes go one way, say from B to A.
The standard workflow then involves pressing "n" to review and "b" to
apply each change.  When the changes turn out to be mundane, this
leads to repetitive "n b" keystrokes.  The proposed patch allows a
more efficient process: rapidly review with "n", then apply all at
once using "C-c C-b".

>
> I think all we need to install this is a suitable NEWS entry.
>
> Thanks.

I've updated the patch with a NEWS entry (formatted to the best of my
ability), together with updates to the Ediff manual and the internal
help system.  Happy to revise further if I missed anything.

Thanks, best,

Paul
From 70cb106941e10fee1e0946928b4ade7f599dfd41 Mon Sep 17 00:00:00 2001
From: Paul Nelson 
Date: Thu, 29 Aug 2024 07:50:27 +0200
Subject: [PATCH] Add ediff-copy-all-X-to-Y functions

* lisp/vc/ediff-util.el (ediff--copy-all):
(ediff-copy-all-A-to-B):
(ediff-copy-all-B-to-A):
(ediff-copy-all-A-to-C):
(ediff-copy-all-B-to-C):
(ediff-copy-all-C-to-A):
(ediff-copy-all-C-to-B): New functions.
(ediff-setup-keymap): Bind them.

* doc/misc/ediff.texi (Quick Help Commands): Document them.

* lisp/vc/ediff-help.el (ediff-long-help-message-compare3):
(ediff-long-help-message-compare2):
(ediff-long-help-message-narrow2):
(ediff-long-help-message-word-mode):
(ediff-long-help-message-merge): Mention them.

* etc/NEWS (Lisp Changes in Emacs 31.1): Mention them.
---
 doc/misc/ediff.texi   | 21 ++
 etc/NEWS  | 17 +++
 lisp/vc/ediff-help.el | 66 +--
 lisp/vc/ediff-util.el | 64 +
 4 files changed, 135 insertions(+), 33 deletions(-)

diff --git a/doc/misc/ediff.texi b/doc/misc/ediff.texi
index 749025c870b..5cdd4e8388f 100644
--- a/doc/misc/ediff.texi
+++ b/doc/misc/ediff.texi
@@ -539,6 +539,27 @@ Quick Help Commands
 Copies the difference region from buffer C to buffer B@.
 The command @kbd{rb} undoes this.
 
+@item C-c C-a
+@itemx C-c C-b
+@itemx C-c C-a C-b
+@itemx C-c C-a C-c
+@itemx C-c C-b C-a
+@itemx C-c C-b C-c
+@itemx C-c C-c C-a
+@itemx C-c C-c C-b
+@kindex C-c C-a
+@kindex C-c C-b
+@kindex C-c C-a C-b
+@kindex C-c C-a C-c
+@kindex C-c C-b C-a
+@kindex C-c C-b C-c
+@kindex C-c C-c C-a
+@kindex C-c C-c C-b
+Behaves like the above commands, but copies @emph{all} difference
+regions from one buffer to another.  For instance, @kbd{C-c C-a} copies
+all changes from buffer A to buffer B (in a 2-way diff) or to buffer C
+(in a merge).
+
 @item p
 @itemx @key{DEL}
 @kindex p
diff --git a/etc/NEWS b/etc/NEWS
index f10f9ae4d65..dbee66ea978 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -121,6 +121,23 @@ A new ':authorizable t' parameter has been added to 'dbus-call-method'
 and 'dbus-call-method-asynchronously' to allow the user to interactively
 authorize the invoked D-Bus method (e.g., via polkit).
 

+** Ediff now supports copying all changes between buffers at once.
+New commands have been added to Ediff to copy all changes from one buffer
+to another in a single operation:
+
+- 'C-c C-a' copies all changes from buffer A to buffer B (in 2-way diff)
+  or to buffer C (in 3-way diff or merge).
+- 'C-c C-b' copies all changes from buffer B to buffer A (in 2-way diff)
+  or to buffer C (in 3-way diff or merge).
+- 'C-c C-a C-b' copies all changes from buffer A to buffer B.
+- 'C-c C-b C-a' copies all changes from buffer B to buffer A.
+- 'C-c C-a C-c' copies all changes from buffer A to buffer C.
+- 'C-c C-b C-c' copies all changes from buffer B to buffer C.
+- 'C-c C-c C-a' copies all changes from buffer C to buffer A.
+- 'C-c C-c C-b' copies all changes from buffer C to buffer B.
+
+
 
 * Changes in Emacs 31.1 on Non-Free Operating Systems
 
diff --git a/lisp/vc/ediff-help.el b/lisp/vc/ediff-help.el
index 56e1ec80c5c..1078322a816 100644
--- a/lisp/vc/ediff-help.el
+++ b/lisp/vc/ediff-help.el
@@ -46,13 +46,13 @@ ediff-long-help-message-tail
 (defconst ediff-long-help-message-compare3
   "
 p,DEL -previous diff | | -vert/horiz split   | xy -copy buf X's region to Y
-n,SPC -next diff | h -highlighting   | rx -restore buf X's old diff
-j -jump to diff  | @ -auto-refinement|  * -refine current region
-   gx -goto X's point|## -ignore whitespace  |  ! -update diff regions
-  C-l -recenter  |#c -ignore case|
-  v/V -scroll up/dn  | #f/#h -focus/hide regions | wx -save buf X
-   -scroll lt/rt  | X -read-only in buf X | wd -save diff output
-~ -rotate buffers| m -wide display   |
+n,SPC -next diff | h -highlighting   | C-c C-x C-y: copy all X->Y

bug#72945: [PATCH 1/2] ox-html: Add support for attr_html for source code blocks

[Suhail Singh]

* lisp/ox-html.el (org-html-src-block): Add org-src-container class to
any class attributes specified via the attr_html keyword.

TINYCHANGE
---
 lisp/ox-html.el | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index 446698758..3e83f02e2 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -3667,14 +3667,24 @@ (defun org-html-src-block
 contextual information."
   (if (org-export-read-attribute :attr_html src-block :textarea)
   (org-html--textarea-block src-block)
-(let* ((lang (org-element-property :language src-block))
+(let* ((attributes (org-export-read-attribute :attr_html src-block))
+   (lang (org-element-property :language src-block))
   (code (org-html-format-code src-block info))
   (label (let ((lbl (org-html--reference src-block info t)))
(if lbl (format " id=\"%s\"" lbl) "")))
   (klipsify  (and  (plist-get info :html-klipsify-src)
 (member lang '("javascript" "js"
   "ruby" "scheme" "clojure" "php" 
"html")
-  (format "\n%s%s\n"
+  (if-let ((class-val (plist-get attributes :class)))
+  (setq attributes (plist-put attributes :class (concat 
"org-src-container " class-val)))
+(setq attributes (plist-put attributes :class "org-src-container")))
+  (format "\n%s%s\n"
+  (let* ((reference (org-html--reference src-block info))
+(a (org-html--make-attribute-string
+(if (or (not reference) (plist-member attributes :id))
+attributes
+  (plist-put attributes :id reference)
+   (if (org-string-nw-p a) (concat " " a) ""))
  ;; Build caption.
  (let ((caption (org-export-get-caption src-block)))
(if (not caption) ""

base-commit: 3428b522fb83c793d0915d63a30601eb993e2b30
-- 
2.46.0

bug#60321: 29.0.60; ruby-mode indentation of hash or array as first arg in multiline method call

[Aaron Jensen]

> It seems to me that anything other than 0 spaces would look inconsistent
> with the first element (the hash), and its closing brace in particular.

Yeah, that's my sense as well, even if it looks awful, but you get what you get.

> >> * Support for the new option in ruby-ts-mode (it's good to have parity).
> >> Could you take the attached patch for a spin? Seems to work here, but
> >> I'd like to have an extra confirmation.
> >
> > I don't have the treesitter stuff installed at the moment, will try
> > this out shortly.
>
> Thanks in advance.

I installed it and gave it a run on a few things. I didn't observe any
issues with it.

Aaron

bug#72210: 31.0.50; Feature request: multi-category support in `icomplete-fido-kill'.

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

> `icomplete-fido-kill' works very well, but cannot handle the deletion of
> files or killing buffers when they are behind a multi-category
> ``situation''.  Add this would be useful for those of us that combine
> `icomplete' with, e.g., `consult-buffer'.

Can you provide a recipe?  I'm not sufficiently familiar with that code
to really understand the problem you're facing.

> What follows is just the ``hacky'' approach that's currently being used
> in my init:

Any chance you can make it a patch against `icomplete.el`?


Stefan

bug#72929: [Norbert Koch] Error building emacs after 73277a4097b

[Stefan Kangas]

Norbert Koch  writes:

> Thanks, this does the trick for me as well.

Thanks, closing.

bug#71646: 29.3; pixel-scroll-precision-mode overrides paging behaviour even when pixel-scroll-precision-interpolate-page is off

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

Eli Zaretskii  writes:

>> From: Stefan Kangas 
>> Date: Sun, 1 Sep 2024 02:48:57 -0700
>> Cc: m...@bulsara.com, 71...@debbugs.gnu.org
>> 
>> Eli Zaretskii  writes:
>> 
>> > Ping! Should I close this?
>> 
>> Shouldn't we rather fix the bug described by Mike?  I.e. this:
>> 
>> > Setting `pixel-scroll-precision-interpolate-page’ is supposed to
>> > turn off the paging animation (which it does) however even when it’s
>> > off,  and  invoke `cua-scroll-up’ & `cua-scroll-down’
>> > rather than allowing another keymap to handle it.
>
> I don't mind to fixing this, if possible, but (a) I don't think I
> understand what is being suggested by the text you quote above, and
> (b) given Po Lu's response, it doesn't seem like the proposed changes
> will be accepted, or did I miss something?

My problem is that two years ago I stated quite clearly why it was
inappropriate to engineer paging interpolation into p-s-p-m (in a
Telegram group), to the deaf ears of the mob requesting it, but since it
is only now that we have received a lone complaint, it's safe to
conclude that most users are satisfied with its established behavior,
which should at least give us pause before any decision to tamper with
it some more, and which behavior, mind you, had already been revised
once in response to user feedback before 29.1.  The optimal solution is
simply not to bind p-s-p-i-p in pixel-scroll-precision-mode, but users
disagreed then, and now it's far too late to tamper with these bindings.

bug#72919: 29.1; chart-space-usage in chart.el does not work correctly on windows

[Eli Zaretskii]

> From: Harm Van der Vegt 
> Date: Sat, 31 Aug 2024 20:52:41 +0200
> 
> Load the builtin chart package. When chart-space-usage is run, targeting
> any directory, chart fails to find any files and therefore can't create
> the chart. The expected behavior is that a bar chart is shown, ranking
> the files of the directory by size.
> 
> This only fails on my Windows machine, it works on my Ubuntu
> installation.
> 
> The output as shown in *Messages* is as follows:
> 
> Collecting statistics...
> Running ‘cd g:/Shakespeare/;du -sk *’...
> Scanning output ...
> chart-space-usage: No files found!

Yes, the current implementation is not portable.

> chart-space-usage makes use of the du (disk usage) utility, which might
> not be present on all machines. In my case I have du installed, but
> chart-space-usage still failed to find any files.
> 
> I have patched chart-space-usage to remove the dependency on du and make
> it OS agnostic and attached the patch to this email.

Thanks.  However, I think your changes are not entirely correct: they
fail to account for space usage of files inside subdirectories of the
directory which the user types at the prompt, whereas the
implementation with "du" does account for that.  In addition, I think
if someone has 'du' on Windows, it should be used.

So I came up with the following changes instead.  Could you please try
them, both with and without du.exe on PATH?  If these changes give
good results, I will install them.

diff --git a/lisp/emacs-lisp/chart.el b/lisp/emacs-lisp/chart.el
index da61e45..03dbe33 100644
--- a/lisp/emacs-lisp/chart.el
+++ b/lisp/emacs-lisp/chart.el
@@ -641,27 +641,63 @@ chart-file-count
   (lambda (a b) (> (cdr a) (cdr b
 ))
 
+;; This assumes 4KB blocks
+(defun chart--file-size (size)
+  (* (/ (+ size 4095) 4096) 4096))
+
+(defun chart--directory-size (dir)
+  "Compute total size of files in directory DIR and its subdirectories.
+DIR is assumed to be a directory, verified by the caller."
+  (let ((size 0))
+(dolist (file (directory-files-recursively dir "." t))
+  (let ((fsize (nth 7 (file-attributes file
+(if (> fsize 0)
+(setq size
+  (+ size (chart--file-size fsize))
+size))
+
 (defun chart-space-usage (d)
   "Display a top usage chart for directory D."
   (interactive "DDirectory: ")
   (message "Collecting statistics...")
   (let ((nmlst nil)
(cntlst nil)
-   (b (get-buffer-create " *du-tmp*")))
-(set-buffer b)
-(erase-buffer)
-(insert "cd " d ";du -sk * \n")
-(message "Running `cd %s;du -sk *'..." d)
-(call-process-region (point-min) (point-max) shell-file-name t
-(current-buffer) nil)
-(goto-char (point-min))
-(message "Scanning output ...")
-(while (re-search-forward "^\\([0-9]+\\)[ \t]+\\([^ \n]+\\)$" nil t)
-  (let* ((nam (buffer-substring (match-beginning 2) (match-end 2)))
-(num (buffer-substring (match-beginning 1) (match-end 1
-   (setq nmlst (cons nam nmlst)
- ;; * 1000 to put it into bytes
- cntlst (cons (* (string-to-number num) 1000) cntlst
+b)
+(if (executable-find "du")
+(progn
+ (setq b (get-buffer-create " *du-tmp*"))
+  (set-buffer b)
+  (erase-buffer)
+  (if (and (memq system-type '(windows-nt ms-dos))
+   (fboundp 'w32-shell-dos-semantics)
+   (w32-shell-dos-semantics))
+  (progn
+;; With Windows shells, 'cd' does not change the drive,
+;; and ';' is not reliable for running multiple
+;; commands, so use alternatives.  We quote the
+;; directory because otherwise pushd will barf on a
+;; directory with forward slashes.
+(insert "pushd \"" d "\" && du -sk * \n")
+(message "Running `pushd \"%s\" && du -sk *'..." d))
+(insert "cd " d ";du -sk * \n")
+(message "Running `cd %s;du -sk *'..." d))
+  (call-process-region (point-min) (point-max) shell-file-name t
+  (current-buffer) nil)
+  (goto-char (point-min))
+  (message "Scanning output ...")
+  (while (re-search-forward "^\\([0-9]+\\)[ \t]+\\([^ \n]+\\)$" nil t)
+(let* ((nam (buffer-substring (match-beginning 2) (match-end 2)))
+  (num (buffer-substring (match-beginning 1) (match-end 1
+ (setq nmlst (cons nam nmlst)
+   ;; * 1000 to put it into bytes
+   cntlst (cons (* (string-to-number num) 1000) cntlst)
+  (dolist (file (directory-files d t directory-files-no-dot-files-regexp))
+(setq nmlst (cons (file-name-nondirectory file) nmlst))
+(if (file-regular-p file)
+(setq cntlst (cons (chart--file-size
+(nth 7 (file-attributes file)))
+ 

bug#60321: 29.0.60; ruby-mode indentation of hash or array as first arg in multiline method call

[Dmitry Gutov]

On 02/09/2024 03:49, Aaron Jensen wrote:


Here's a bonus example which looks off but would be more difficult to
fix (and it's not urgent, given the expression is in mixed styles):

foo([{
a: 2
},
   {
 b: 3
   },
   4
  ])


Yes, that's connected to the case I mentioned... how do you think it
should be indented? I wonder if it should just be 2 spaces in (rather
than aligned with the opening bracket)


It seems to me that anything other than 0 spaces would look inconsistent 
with the first element (the hash), and its closing brace in particular.


Anyway, it's not urgent and like you said in the first message, people 
formatting code this way might have other unusual requirements as well.



* Support for the new option in ruby-ts-mode (it's good to have parity).
Could you take the attached patch for a spin? Seems to work here, but
I'd like to have an extra confirmation.


I don't have the treesitter stuff installed at the moment, will try
this out shortly.


Thanks in advance.

bug#72915: Docstrings of add-hook and remove-hook improvement?

[Tomas Nordin]

Stefan Kangas  writes:

> Stefan Kangas  writes:
>
>> The wording in the manual is probably all that is needed here:
>>
>> This function removes FUNCTION from the hook variable HOOK.
>
> BTW.  Here's another idea:
>
> If HOOK is a list of functions, remove FUNCTION from that list.
>
> If HOOK is equal to FUNCTION, set HOOK to nil.
>
> Otherwise do nothing.

I like that, adjusted maybe to respect Stefan M's nitpick:

If HOOK's value is a list of functions, remove FUNCTION from that list.
If HOOK's value is FUNCTION, set HOOK to nil.
Otherwise do nothing.

bug#72951: Hideshow support for treesitter

[Pranshu Sharma]

Hello all

Are there any plans to add treesitter support for hideshow, it seems easy
enough to do and also very helpful, especially for langs that don't
excessively use parens, such as python

bug#72245: [PATCH] Fix integer overflow when reading XPM

[Stefan Kangas]

Version: 31.1

Stefan Kangas  writes:

> Since we don't have an alternative patch, I will install the one I
> proposed in the next couple of days.  Thanks.

Pushed to master as commit 73277a4097b.  Closing.

bug#60321: 29.0.60; ruby-mode indentation of hash or array as first arg in multiline method call

[Dmitry Gutov]

Hi Aaron!

On 01/09/2024 03:54, Aaron Jensen wrote:

Updated patch with more precise variables in the new test.


Thanks for taking the initiative.

Here's an example which seems to get worse with the new variable set to nil:

def foo
  foo.update(
{
  key => value,
  other_key: foo
}
  )
end

I'd like to flip the default value (now or in Emacs 31), so it would be 
great to deal with examples like this.

bug#72929: [Norbert Koch] Error building emacs after 73277a4097b

[Norbert Koch]

Stefan Kangas  writes:

Hello Stefan,

> Thanks for reporting this.
>
> Forwarding the below to the bug tracker in case anyone sees a quick fix.
> I'll be AFK in the next couple of hours or so.
>
> FWIW, I can't reproduce the below on macOS 15 or Ubuntu 22.04 LTS.

> Did you try `make bootstrap`?  Could you include your build details as
> per `M-x report-emacs-bug`?

Yes, I see the same problem with a make bootstrap.

Here's the build information

In GNU Emacs 31.0.50 (build 8, x86_64-pc-linux-gnu, X toolkit, cairo
 version 1.18.0, Xaw scroll bars) of 2024-09-01 built on dest-ltnok-02
Repository revision: 59e0b82776ade72680e7c369f6089eab4a74dc4a
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101013
System Description: Debian GNU/Linux trixie/sid

Configured using:
 'configure --prefix=/home/nok/local'

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

Important settings:
  value of $LC_ALL: en_US.utf8
  value of $LANG: en_US.utf8
  locale-coding-system: utf-8-unix

Major mode: Message

Minor modes in effect:
  gnus-message-citation-mode: t
  footnote-mode: t
  flyspell-mode: t
  rcirc-track-minor-mode: t
  gnus-desktop-notify-mode: t
  global-origami-mode: t
  origami-mode: t
  global-company-mode: t
  company-mode: t
  fortune-cookie-mode: t
  electric-pair-mode: t
  display-battery-mode: t
  desktop-save-mode: t
  global-tree-sitter-mode: t
  flycheck-posframe-mode: t
  yas-global-mode: t
  yas-minor-mode: t
  global-git-commit-mode: t
  mml-mode: t
  magit-auto-revert-mode: t
  server-mode: t
  marginalia-mode: t
  vertico-prescient-mode: t
  which-key-mode: t
  global-flycheck-mode: t
  flycheck-mode: t
  override-global-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  minibuffer-regexp-mode: t
  column-number-mode: t
  line-number-mode: t
  auto-fill-function: #[128 \304\300\301.#\207 [yas--auto-fill 
message-do-auto-fill :around nil apply] 5 advice]
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  abbrev-mode: t

Load-path shadows:
/home/nok/.emacs.d/elpa/transient-20240831.2233/transient hides 
/home/nok/local/share/emacs/31.0.50/lisp/transient
/home/nok/.emacs.d/elpa/bind-key-20230203.2004/bind-key hides 
/home/nok/local/share/emacs/31.0.50/lisp/bind-key
/home/nok/.emacs.d/elpa/which-key-20240620.2145/which-key hides 
/home/nok/local/share/emacs/31.0.50/lisp/which-key
/home/nok/.emacs.d/elpa/dictionary-20201001.1727/dictionary hides 
/home/nok/local/share/emacs/31.0.50/lisp/net/dictionary
/home/nok/.emacs.d/elpa/flim-20240221.1353/sasl hides 
/home/nok/local/share/emacs/31.0.50/lisp/net/sasl

Features:
(shadow tramp-cache time-stamp tramp-sh shortdoc help-fns radix-tree
emacsbug url-http url-gw url-auth gnus-gravatar gravatar dns url-cache
smiley mm-archive gnus-async gnus-bcklg gnus-ml disp-table view
sh-script smie treesit executable ffap tramp trampver tramp-integration
files-x tramp-message tramp-compat tramp-loaddefs mailalias smtpmail
textsec uni-scripts idna-mapping ucs-normalize uni-confusable
textsec-check qp sort gnus-cite footnote fortune mail-extr goto-addr
bug-reference magit-extras face-remap gnus-demon gnus-topic nndraft nnmh
nnml utf-7 epa-file network-stream nsm nnfolder nnnil gnus-agent
gnus-srvr gnus-score score-mode nnvirtual nntp gnus-cache nok-gnus
ebdb-message ebdb-gnus gnus-msg gnus-art mm-uu mml2015 mm-view mml-smime
smime gnutls dig gnus-sum ebdb-mua ebdb-com ebdb-format ebdb eieio-opt
speedbar ezimage dframe eieio-base timezone eww url-queue thingatpt shr
pixel-fill kinsoku url-file svg dom mm-url mule-util jka-compr vc-dir
ewoc vc display-line-numbers diary-lib diary-loaddefs cal-menu calendar
cal-loaddefs k8s-mode vc-git vc-dispatcher ansible-doc flyspell ispell
yaml-mode company-oddmuse company-keywords company-etags etags fileloop
generator company-gtags company-dabbrev-code company-dabbrev
company-files company-clang company-capf company-cmake company-semantic
company-template company-bbdb rcirc gnus-desktop-notify alert log4e
notifications gntp gnus-group gnus-undo gnus-start gnus-dbus gnus-cloud
nnimap nnmail mail-source utf7 nnoo parse-time iso8601 gnus-spec
gnus-int gnus-range gnus-win gnus nnheader range wid-edit origami
origami-parsers cl company fortune-cookie elec-pair battery dbus xml
desktop frameset cus-load tree-sitter-langs tree-sitter-langs-build
tar-mode arc-mode archive-mode pp tree-sitter-hl tree-sitter
tree-sitter-load tree-sitter-cli tsc tsc-dyn tsc-dyn-get dired-aux
tsc-obsolete xterm-color flycheck-posframe posframe java-snippe

bug#72929: [Norbert Koch] Error building emacs after 73277a4097b

[Eli Zaretskii]

> Cc: Norbert Koch 
> From: Stefan Kangas 
> Date: Sun, 1 Sep 2024 07:45:35 -0700
> 
> Thanks for reporting this.
> 
> Forwarding the below to the bug tracker in case anyone sees a quick fix.

I think image.c needs to include  to avoid this.

bug#71646: 29.3; pixel-scroll-precision-mode overrides paging behaviour even when pixel-scroll-precision-interpolate-page is off

[Stefan Kangas]

Eli Zaretskii  writes:

> Ping! Should I close this?

Shouldn't we rather fix the bug described by Mike?  I.e. this:

> Setting `pixel-scroll-precision-interpolate-page’ is supposed to
> turn off the paging animation (which it does) however even when it’s
> off,  and  invoke `cua-scroll-up’ & `cua-scroll-down’
> rather than allowing another keymap to handle it.

bug#72929: [Norbert Koch] Error building emacs after 73277a4097b

[Norbert Koch]

Pip Cet  writes:

> "Stefan Kangas"  writes:
>
>> Forwarding the below to the bug tracker in case anyone sees a quick fix.
>> I'll be AFK in the next couple of hours or so.
>
> I can reproduce this with --with-x-toolkit=no.  An explicit
>
> #include 
>
> seems to be all that's required, so I've boldly pushed it.

Thanks, this does the trick for me as well.

Regards,
Norbert
-- 

bug#72915: Docstrings of add-hook and remove-hook improvement?

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

>> The wording in the manual is probably all that is needed here:
>>
>> This function removes FUNCTION from the hook variable HOOK.
>
> BTW.  Here's another idea:
>
> If HOOK is a list of functions, remove FUNCTION from that list.
>
> If HOOK is equal to FUNCTION, set HOOK to nil.
>
> Otherwise do nothing.

Nit pick: a hook *is* not a function or a list of functions.
It only *holds* such things.


Stefan

bug#72915: Docstrings of add-hook and remove-hook improvement?

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

>> -HOOK should be a symbol.  If HOOK is void, it is first set to
>> -nil.  If HOOK's value is a single function, it is changed to a
>> -list of functions.
> Is the bit about setting HOOK to nil incorrect?  Because the new text
> drops that part.

That's an internal detail that's not observable to the caller anyway.

>>"Remove from the value of HOOK the function FUNCTION.
>>  HOOK should be a symbol, and FUNCTION may be any valid function.  If
>>  FUNCTION isn't the value of HOOK, or, if FUNCTION doesn't appear in the
>> -list of hooks to run in HOOK, then nothing is done.  See `add-hook'.
>> +list of functions to run in HOOK, then nothing is done.  See `add-hook'.
>
> "list of functions to run in HOOK" is ambiguous wrt what "in HOOK"
> refers to.  I would rephrase:
>
>   If FUNCTION is not the value of HOOK and is not a member of the list
>   that is the value of HOOK, do nothing.

Maybe we can simplify the wording a bit by focusing less about whether
the hook's value is a function or a list of functions, and talking about
the "sequence" or "set" of functions (which can be represented by
a list of functions or a function)?

Something like:

  "Remove FUNCTION from HOOK's functions.
HOOK should be a symbol, and FUNCTION may be any valid function.
Does nothing if HOOK does not currently contain FUNCTION.
Compares functions with `equal`, which means that it can be
slow if FUNCTION is not a symbol.  See `add-hook'.



- Stefan

bug#72919: 29.1; chart-space-usage in chart.el does not work correctly on windows

[Eli Zaretskii]

[Please use Reply All to reply, so that the bug tracker is CC'ed.]

> From: Harm Van der Vegt 
> Date: Sun, 1 Sep 2024 20:11:39 +0200
> 
> >Thanks.  However, I think your changes are not entirely correct: they
> >fail to account for space usage of files inside subdirectories of the
> >directory which the user types at the prompt, whereas the
> >implementation with "du" does account for that.
> 
> That is indeed a pretty major difference, my bad!
> 
> >In addition, I think if someone has 'du' on Windows, it should be used.
> 
> Is there a preference for using system binaries above elisp for cases like 
> these?

I think 'du' has some tricks up its sleeve (like accounting correctly
for block size), which a Lisp implementation can only approximate.  I
don't think minor differences matter here, since this command is just
an illustration of what chart.el can be used for, but I do want to use
'du' if it's available.

> >So I came up with the following changes instead.  Could you please try
> >them, both with and without du.exe on PATH?  If these changes give
> >good results, I will install them.
> 
> Thanks.
> 
> I've tried your changes with and without du. This uncovered something in the
> original implementation, namely that the original implementation did not count
> hidden files and directories. du * skips dotfiles for me.
>
> With du present chart-space-usage shows the lisp directory as the largest in 
> the 
> emacs repository root. Without du it shows .git as the largest.

This just means minor adjustments in the code I posted: we need to use
a different regexp in the call to directory-files-recursively, and
also ignore files that start with a dot in the command itself.  I will
make those changes, thanks for pointing them out

> I'm not sure which output is the wanted output.

I think we want to be as close to 'du' as possible.

> I've attempted to find a shell independent way to have du show dotfiles, but 
> it 
> appears to be rather tricky.

I don't think we want that.

> I've made a new patch that makes the elisp implementation recursive, uses the
> rounding function provided by you and shows dotfiles.

I'd prefer to avoid recursion (in addition to what
directory-files-recursively already does), because that could overflow
the stack.

I will post a version that ignores dotfiles.

Here's the version you sent, repeated for the bug tracker:

>From 6f53d65f9ae5e1c61a2ca2650b149c895ce9794c Mon Sep 17 00:00:00 2001
>From: Harm van der Vegt 
Date: Sun, 1 Sep 2024 20:03:34 +0200
Subject: [PATCH] Make chart-space-usage OS and shell independent

---
 lisp/emacs-lisp/chart.el | 41 +
 1 file changed, 29 insertions(+), 12 deletions(-)

diff --git a/lisp/emacs-lisp/chart.el b/lisp/emacs-lisp/chart.el
index c195ccb7165..b0302b55278 100644
--- a/lisp/emacs-lisp/chart.el
+++ b/lisp/emacs-lisp/chart.el
@@ -641,27 +641,44 @@ SORT-PRED if desired."
   (lambda (a b) (> (cdr a) (cdr b
 ))
 
+;; This assumes 4KB blocks
+(defun chart--file-size (size)
+  (* (/ (+ size 4095) 4096) 4096))
+
+(defun chart--directory-size (dir)
+  "Compute total size of files in directory DIR and its subdirectories.
+DIR is assumed to be a directory, verified by the caller."
+  (let ((total-size 0))
+(dolist (file (directory-files dir t directory-files-no-dot-files-regexp))
+  (cond
+   ((file-regular-p file)
+(setq total-size (+ total-size (chart--file-size (nth 7 
(file-attributes file))
+   ((file-directory-p file)
+(setq total-size (+ total-size (chart--directory-size file))
+total-size))
+
 (defun chart-space-usage (d)
   "Display a top usage chart for directory D."
   (interactive "DDirectory: ")
   (message "Collecting statistics...")
   (let ((nmlst nil)
-(cntlst nil))
-(dolist (file (directory-files d t))
-  (when (file-regular-p file)
-(let ((size (nth 7 (file-attributes file
+   (cntlst nil))
+
+(dolist (file (directory-files d t directory-files-no-dot-files-regexp))
+(let ((size (if (file-regular-p file)
+(nth 7 (file-attributes file))
+  (chart--directory-size file
   (setq nmlst (cons (file-name-nondirectory file) nmlst))
-  (setq cntlst (cons size cntlst)
+  (setq cntlst (cons (chart--file-size size) cntlst
 
 (if (not nmlst)
-(error "No files found!"))
-
-;; Display the chart if files are found
+   (error "No files found!"))
 (chart-bar-quickie 'vertical (format "Largest files in %s" d)
-   nmlst "File Name"
-   cntlst "File Size"
-   10
-   (lambda (a b) (> (cdr a) (cdr b))
+  nmlst "File Name"
+  cntlst "File Size"
+  10
+  (lambda (a b) (> (cdr a) (cdr b
+))
 
 (defun chart-emacs-storage ()
   "Chart th

bug#72829: describe-function NEWS* scraper override

[Mattias Engdegård]

1 sep. 2024 kl. 00.26 skrev Stefan Kangas :

> For symbols that are in symbol-releases.eld, which means we are actually
> sure about the addition, shouldn't the help text be changed from
> 
>Probably introduced at or before Emacs version XX.Y.
> 
> to something more like
> 
>Added in Emacs version XX.Y.

That's how I did it first but then dropped it for simplicity, but it can 
certainly be added back in.
The file also contains information about some symbols whose first appearance is 
not exactly known but it hardly matters for non-historians.