bug#73004: [PATCH] Make `dired-do-open' work on non GNU/Linux systems

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

Juri Linkov  writes:

[...]

> The current implementation is based on long discussions including bug#18132.
> So everyone is welcome to improve it, it's not cast in stone.

Thanks for the pointer.  I'm proposing the following patch then.
>From d8e59996f8a8dccd564cb27e5a2a56f83cb2db6f Mon Sep 17 00:00:00 2001
From: Manuel Giraud 
Date: Fri, 6 Sep 2024 09:47:33 +0200
Subject: [PATCH] Make `dired-do-open' work on more *nix systems

* lisp/dired-aux.el (dired-do-open): Make `dired-do-open' work
on more *nix systems.
---
 lisp/dired-aux.el | 29 ++---
 1 file changed, 14 insertions(+), 15 deletions(-)

diff --git a/lisp/dired-aux.el b/lisp/dired-aux.el
index cd948bd7dd9..1d0e29b8782 100644
--- a/lisp/dired-aux.el
+++ b/lisp/dired-aux.el
@@ -1469,21 +1469,20 @@ dired-do-open
 (when (and (memq system-type '(windows-nt))
(equal command "start"))
   (setq command "open"))
-(when command
-  (dolist (file files)
-(cond
- ((memq system-type '(gnu/linux))
-  (call-process command nil 0 nil file))
- ((memq system-type '(ms-dos))
-  (shell-command (concat command " " (shell-quote-argument file
- ((memq system-type '(windows-nt))
-  (w32-shell-execute command (convert-standard-filename file)))
- ((memq system-type '(cygwin))
-  (call-process command nil nil nil file))
- ((memq system-type '(darwin))
-  (start-process (concat command " " file) nil command file))
- (t
-  (error "Open not supported on this system")))
+(if command
+(dolist (file files)
+  (cond
+   ((memq system-type '(ms-dos))
+(shell-command (concat command " " (shell-quote-argument file
+   ((memq system-type '(windows-nt))
+(w32-shell-execute command (convert-standard-filename file)))
+   ((memq system-type '(cygwin))
+(call-process command nil nil nil file))
+   ((memq system-type '(darwin))
+(start-process (concat command " " file) nil command file))
+   (t
+(call-process command nil 0 nil file
+  (error "Open not supported on this system"
 
 
 ;;; Commands that delete or redisplay part of the dired buffer
-- 
2.46.0

-- 
Manuel Giraud

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

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

> I checked out git master HEAD (currently df57e44a08f) and reverted commit
> 241616831024c9c9fe2b2378b611db0a560b9675 on top of that.

Good.

> and please first run without the commit under
>> gdb with a breakpoint at the line
>>
>> adjust_frame_size (f, -1, -1, 2, 0, Qmenu_bar_lines);
>>
>> in xg_update_frame_menubar.  Please note all values you see after doing
>>
>> p req.height
>>
>
> 50 (before initial frame opens)
> 50 (after C-x 5 2, before second frame opens)
>
> And the second frame opens at the expected size, the same size as the first.
>
> Then restore current master and repeat the same steps.  When the values
>> differ, this should tell us something about what happens.
>>
>
> 50 (before initial frame opens)
> 50 (after C-x 5 2, before second frame opens)
>
> But the second frame opens small.

Inexplicable to me.  Please conduct both runs once more.  But rather
than using the debugger simply evaluate

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

in the initial frame, do C-x 5 2, evaluate

(frame--size-history)

and post the contents of the the buffer *frame-size-history* for each
run here.  Maybe we can see some difference then.

martin

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

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

On Fri, 6 Sept 2024 at 08:54, martin rudalics  wrote:

>
> Inexplicable to me.  Please conduct both runs once more.  But rather
> than using the debugger simply evaluate
>
> (setq frame-size-history '(100))
>
> in the initial frame, do C-x 5 2, evaluate
>
> (frame--size-history)
>
> and post the contents of the the buffer *frame-size-history* for each
> run here.  Maybe we can see some difference then.


Buffer contents for master HEAD after C-x 5 2:

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

And again, but with commit 24161683102 reverted:

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

-- 
https://rrt.sc3d.org

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

[Arash Esbati]

tags 72999 notabug
close 72999
thanks

Vadim Zaliva  writes:

> Removing the following from my .emacs fixed the problem:
>
> (use-package latex-extra
>   :ensure t
>   :hook (LaTeX-mode . latex-extra-mode))

Thanks for reporting back.  Maybe you want to report the issue to
latex-extra tracker[1].

I'm closing this report here since it's not an AUCTeX bug.

Best, Arash

Footnotes:
[1]  https://github.com/Malabarba/latex-extra/issues

bug#57627: 29.0.50; [native-compilation] cl-loaddefs.el recompiled on startup

[Andrea Corallo]

Phil Sainty  writes:

> https://emacs.stackexchange.com/questions/82010 indicates
> that this bug was fixed for *.el files, but remains in effect
> for the *.el.gz case.

Hi Phil,

can you reproduce this?  ATM I cannot with my emacs 30 installed.

Andrea

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: Fri, 06 Sep 2024 11:36:25 +0100
> 
> I think you're right, but I would like to commit my function first, so
> that I get attribution (it did take me some time to figure out what was
> useful in this area), and because I think it should be rewritten in
> terms of fields.
> 
> Please take a look at the attached.  unix-word-rubout to follow.

Thanks, but I see no reason to document this command in the manual,
certainly not in the ELisp reference (it's a command, not a function).
IMO it's obscure enough to be documented only in NEWS.

> +(defun forward-unix-word (&optional arg delim)
> +  "Move forward to the end of the next whitespace-delimited word.
> +With argument ARG, do this that many times; the default is once.
> +With negative ARG, go backwards to the beginning of whitespace-delimited
> +words.
> +DELIM is a string specifying what characters are considered whitespace,
> +as might be passed to `skip-chars-forward'.
> +The default is \"[:space:]\\n\".  Do not prefix a `^' character.

Should this be "[:space:]\\n\\r" instead? if not, why not?

Also note that [:space:] depends on mode-specific syntax table, so I
question the wisdom of using it in a command that's supposed to be
mode-agnostic.

> +This command is like `forward-word' except that words are always
> +delimited by whitespace, regardless of the buffer's syntax table.
> +Like `forward-word', this command respects fields.
> +
> +This emulates how C-w at the Unix terminal or shell identifies words.
> +See the `unix-word-rubout' command in Info node `(readline)Commands For
> +Killing'."

This should try to be more explicit about what "word" means for this
command.  Since it's so different from any notion of "word" in Emacs,
I would even seriously consider not to use that word, or maybe quote
it (in addition to explaining what it means).

Also, since this is a command, its doc string should clearly separate
what happens in interactive invocation from what happens when called
from Lisp.  DELIM belongs to the latter.  (Is it even useful to
provide that option for Lisp-only calls? what's the use case for
that?)

And finally, I wonder why we need this command?  AFAIU, the original
intent was to implement something similar to unix-word-rubout, not a
new movement command.  If the plan has changed, I think we need to
discuss the need once again.

Thanks.

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

[Sean Whitton]

Hello,

On Thu 05 Sep 2024 at 02:38pm GMT, Philip Kaludercic wrote:

> In that case, it would be difficult to use it directly in this
> implementation, as kill-region needs a command that just moves the
> point.  I guess it would be possible to hack something together with
> atomic change groups, but the cleanest strategy would probably be to
> have a unix-word-forward command that goes in both directions, and use
> that both in a standalone unix-word-rubout and this patch.  But we can
> do that after merging this patch -- assuming there are no more blocking
> issues with the latest version:

I think you're right, but I would like to commit my function first, so
that I get attribution (it did take me some time to figure out what was
useful in this area), and because I think it should be rewritten in
terms of fields.

Please take a look at the attached.  unix-word-rubout to follow.

-- 
Sean Whitton
>From 4cb701150976cdb91658a1c82edd6e8270fd26c8 Mon Sep 17 00:00:00 2001
From: Sean Whitton 
Date: Fri, 6 Sep 2024 11:35:46 +0100
Subject: [PATCH] New command forward-unix-word

* lisp/simple.el (forward-unix-word): New command.
* doc/lispref/positions.texi (Word Motion):
* etc/NEWS: Document it.
---
 doc/lispref/positions.texi | 13 +
 etc/NEWS   |  5 +
 lisp/simple.el | 30 ++
 3 files changed, 48 insertions(+)

diff --git a/doc/lispref/positions.texi b/doc/lispref/positions.texi
index 37cfe264157..b576df82382 100644
--- a/doc/lispref/positions.texi
+++ b/doc/lispref/positions.texi
@@ -275,6 +275,19 @@ Word Motion
 syntax tables.
 @end defun
 
+@deffn Command forward-unix-word &optional arg delim
+This function is like @code{forward-word}, except that words are always
+delimited by whitespace, regardless of the buffer's syntax table.  This
+emulates how @kbd{C-w} at the Unix terminal or shell identifies words.
+See the @code{unix-word-rubout} command in @xref{(readline)Commands For
+Killing}.
+
+Lisp programs can pass the @var{delim} argument to specify the notion of
+whitespace.  This argument is a string listing the characters considered
+whitespace, as might be passed to @code{skip-chars-forward}.  The
+default is @code{[:space:]\n}.  Do not prefix a `^' character.
+@end deffn
+
 @node Buffer End Motion
 @subsection Motion to an End of the Buffer
 @cindex move to beginning or end of buffer
diff --git a/etc/NEWS b/etc/NEWS
index f3e719a34d3..8037fcfd1af 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -123,6 +123,11 @@ When using 'visual-wrap-prefix-mode' in buffers with variable-pitch
 fonts, the wrapped text will now be lined up correctly so that it's
 exactly below the text after the prefix on the first line.
 

+** New command 'forward-unix-word'.
+This command is like 'forward-word', except it always considers words to
+be delimited by whitespace, regardless of the buffer's syntax table.
+It thus emulates how C-w at the Unix terminal or shell identifies words.
 
 * Changes in Specialized Modes and Packages in Emacs 31.1
 
diff --git a/lisp/simple.el b/lisp/simple.el
index 2453a129d0a..f34eef9ac25 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -8892,6 +8892,36 @@ current-word
   ;; If we found something nonempty, return it as a string.
   (unless (= start end)
 	(buffer-substring-no-properties start end)
+
+(defun forward-unix-word (&optional arg delim)
+  "Move forward to the end of the next whitespace-delimited word.
+With argument ARG, do this that many times; the default is once.
+With negative ARG, go backwards to the beginning of whitespace-delimited
+words.
+DELIM is a string specifying what characters are considered whitespace,
+as might be passed to `skip-chars-forward'.
+The default is \"[:space:]\\n\".  Do not prefix a `^' character.
+
+This command is like `forward-word' except that words are always
+delimited by whitespace, regardless of the buffer's syntax table.
+Like `forward-word', this command respects fields.
+
+This emulates how C-w at the Unix terminal or shell identifies words.
+See the `unix-word-rubout' command in Info node `(readline)Commands For
+Killing'."
+  (interactive "^p")
+  (unless (zerop arg)
+;; We do skip over \n by default because `backward-word' does.
+(let* ((delim (or delim "[:space:]\n"))
+   (ndelim (format "^%s" delim))
+   (start (point))
+   (fun (if (> arg 0)
+#'skip-chars-forward
+  #'skip-chars-backward)))
+  (dotimes (_ (abs arg))
+(funcall fun delim)
+(funcall fun ndelim))
+  (constrain-to-field nil start
 
 (defcustom fill-prefix nil
   "String for filling to insert at front of new line, or nil for none."
-- 
2.39.2

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

[Sean Whitton]

Hello,

On Fri 06 Sep 2024 at 11:36am +01, Sean Whitton wrote:

> diff --git a/doc/lispref/positions.texi b/doc/lispref/positions.texi
> index 37cfe264157..b576df82382 100644
> --- a/doc/lispref/positions.texi
> +++ b/doc/lispref/positions.texi
> @@ -275,6 +275,19 @@ Word Motion
>  syntax tables.
>  @end defun
>
> +@deffn Command forward-unix-word &optional arg delim
> +This function is like @code{forward-word}, except that words are always
> +delimited by whitespace, regardless of the buffer's syntax table.  This
> +emulates how @kbd{C-w} at the Unix terminal or shell identifies words.
> +See the @code{unix-word-rubout} command in @xref{(readline)Commands For
> +Killing}.
> +
> +Lisp programs can pass the @var{delim} argument to specify the notion of
> +whitespace.  This argument is a string listing the characters considered
> +whitespace, as might be passed to @code{skip-chars-forward}.  The
> +default is @code{[:space:]\n}.  Do not prefix a `^' character.
> +@end deffn

The `^' should use @code{}.

> diff --git a/lisp/simple.el b/lisp/simple.el
> index 2453a129d0a..f34eef9ac25 100644
> --- a/lisp/simple.el
> +++ b/lisp/simple.el
> @@ -8892,6 +8892,36 @@ current-word
>;; If we found something nonempty, return it as a string.
>(unless (= start end)
>   (buffer-substring-no-properties start end)
> +
> +(defun forward-unix-word (&optional arg delim)
> +  "Move forward to the end of the next whitespace-delimited word.

ARG is not optional, only DELIM, in fact.  I will fix this.

I thought I should also explain this DELIM thing.  In addition to
Philip's usage and unix-word-rubout, I would like to add
unix-filename-rubout, which I think is generally useful -- it's also in
(info "(readline)Commands For Killing").  DELIM is needed for that.
It also makes the function more generally useful to Lisp programmers --
you might want to drop \n, for example.

-- 
Sean Whitton

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

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

> Buffer contents for master HEAD after C-x 5 2:

I can't figure out what's going on.  We get a

ConfigureNotify, PS=400x374, XS=1280x1354

event that tells us to set the frame to some "reasonable" size at least.
And the penultimate lines

> change_frame_size (5), TS=352x374~>1232x1354, TC=22x10~>77x38,
> NS=400x374~>1280x1354, IS=400x374~>1280x1354, MS=32x70 IH IV

tell, for example, that the text size of the frame should increase from
22x10 columns/lines to 77x38 (38 being obviously too large).  But
apparently nothing changes which is a complete mystery because

- if the WM does give us the indicated new size and we do not react, you
  should at least see an excessive frame border around or a much too
  long title bar above the contents of the new frame,

- if the WM only pretended to give us the indicated new size, you should
  see the new frame clipped at the right and bottom.

Since neither of these apparently happen, I'm clueless.  Could you do
the following: adjust_frame_size (in frame.c) contains the line

  if (new_inner_width != old_inner_width)

Please put a breakpoint there and look what happens when new_inner_width
is 1280.  That is, use

condition B new_inner_width == 1280

where B is the number of the breakpoint you've set.  I'm mostly
interested in whether the breakpoint gets hit at all.  If it does get
hit, we can try to dig further.

martin

bug#73016: Potential inclusion of kbd-mode, part of kmonad, in Non-GNU ELPA

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

Hi,

thanks to Jeremy for submitting this, and to Philip for reviewing! I'm
travelling right now, so I'll keep this short; more to come in a few
days I hope.
 
On Thu, Sep 05 2024 09:53, Philip Kaludercic wrote:
> [… 12 lines elided …]
>
>> On behalf of the author, Tony Zorman, I would like to request
>> consideration to include it in NON-GNU ELPA.
>
> Just for the sake of the protocol, is there a reason against adding the
> package to GNU ELPA?

There has been at least one non-trivial contribution to the package, as
well as several smaller ones. While I have assigned copyright to the FSF
for Emacs and ELPA related things, I don't know whether the same can be
said of the other contributors.

>> The author is conscious that the following snippet should be improved
>> and we are soliciting recommendations on how to improve it.
>>   ;; HACK
>>   (defadvice redisplay (after refresh-font-locking activate)
>> (when (derived-mode-p 'kbd-mode)
>>   (font-lock-fontify-buffer
>
> I agree, we should get rid of that.  But first, what is the intention?
> What breaks if we just remove this advice?

When specifying the keyboard layout, the configuration language accepts
most special symbols verbatim (as in, one can just write @ to have that
symbol bound to a key). This includes " for double quotes, meaning the
highlighting of strings has to be taken care of be the mode—at least, I
think so. This produces inconsistent behaviour that I was never really a
fan of, especially when moving things around. For example, going from 

(f "string")

to 

(f
 "string")

would "unhighlight" the string until one refreshes the syntax
highlighting for the buffer via e.g. font-lock-update, or wait until
this happens by itself. The advice is nothing more but a band-aid such
that the latter happens more often.

It may well be that I overlooked something about Emacs's way of going
about string highlighting back when I wrote the mode, and so far I
haven't had the drive to look back into this.

  Tony

-- 
Tony Zorman | https://tony-zorman.com

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

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

Juri Linkov  writes:

> Maybe this is reproducible only on very long Dired buffers?

I tried in a buffer with over 19,000 files.  I should have experienced a
problem (no matches found, nothing changed) if font-lock would be
related.  But every function involved always found matches hundreds of
screens below the current position.  I reloaded the buffer after each
experiment to be sure only the currently visited area was ever displayed.

OTOH, I did see the match-data issue occur.  Maybe this is the only
reason of our problems.  I would focus on trying to understand that
problem.


> > Second: I'm confused.  Apparently, when `dired-isearch-filenames-mode'
> > is on, why do `search-forward-regexp' and `replace-regexp' behave
> > differently?  `search-forward-regexp' does find matches outside of file
> > names that `replace-regexp' ignores.
>
> `replace-regexp' uses Isearch functions,
> `search-forward-regexp' is a core function that doesn't use Isearch.

It's a not-so-nice inconsistency, but ok...


Michael.

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

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

On Fri, 6 Sept 2024 at 10:50, martin rudalics  wrote:

>  > Buffer contents for master HEAD after C-x 5 2:
>
> I can't figure out what's going on.


I couldn't make sense of the results I sent either, so I re-ran the tests.

Buffer contents after C-x 5 2 with commit 24161683102 reverted:

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

With git master HEAD:

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

Now the change_frame_size(5) initial and final sizes look correct.

-- 
https://rrt.sc3d.org

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

[Vadim Zaliva]

Removing the following from my .emacs fixed the problem:


(use-package latex-extra

  :ensure t

  :hook (LaTeX-mode . latex-extra-mode))


--
"La perfection est atteinte non quand il ne reste rien a ajouter, mais quand il ne 
reste rien a enlever."  (Antoine de Saint-Exupery)

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

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

Eli Zaretskii  writes:

Hi,

>> >> It would also help if being over a slow connection didn't result in
>> >> Emacs consuming 100% of the CPU via functions such as
>> >> `tramp-wait-for-regexp' (based on profiler-report).  Could some of this
>> >> be done asynchronously?
>> >
>> > You could probably tell which parts take the time by profiling Emacs
>> > while it collects the Dired data, using profiler.el.  This could give
>> > clues about the expensive parts.  My guess would be that retrieving
>> > the attributes of the files Dired needs are the reason, but I could be
>> > wrong.
>>
>> Based on =profiler-report=, the following function "chains" consume most of 
>> the
>> CPU:
>> - `font-lock-fontify-keywords-region'
>>   - tramp-sh-file-name-handler
>> - tramp-sh-handle-file-truename
>>   - `tramp-wait-for-regexp'
>> - tramp-sh-handle-file-exists-p
>>   - `tramp-wait-for-regexp'
>> - tramp-sh-handle-file-directory-p
>>   - `tramp-wait-for-regexp'
>> - tramp-sh-handle-file-attributes
>>   - `tramp-wait-for-regexp'
>>
>> As noted previously, disabling global-font-lock-mode helps.
>
> FWIW, I cannot reproduce this: I tried Dired on a remote host with
> which I have connection that is quite slow, and saw neither high CPU
> usage nor a significant delay in displaying a Dired buffer.

It seems to be related to font-locking, indeed. See variable
`dired-font-lock-keywords'. It specifies face recognition running basic
file oprtations. For example, ";; Broken Symbolic link" calls
`file-truename' and `file-exists-p', while "Symbolic link to a directory"
and ";; Symbolic link to a non-directory" invoke `file-truename' and
`file-directory-p'.

I believe it would be helpful to suppress these checks via a user
option. And no, the checks shouldn't be suppressed for remote
directories in general, on a fast connection they are valuable.

In bug#17064, the impact of these calls where discussed. The conclusion was

--8<---cut here---start->8---
> Or could this have any bad side effects?  Is it maybe too heavy to call
> `file-truename'?

Normally, there aren't many symlinks in a buffer, so I think the
performance impact would be negligible.
--8<---cut here---end--->8---

Likely, this was too optimistic ...

Best regards, Michael.

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

[Eli Zaretskii]

> From: Michael Albinus 
> Cc: Suhail Singh ,  73...@debbugs.gnu.org
> Date: Fri, 06 Sep 2024 15:23:57 +0200
> 
> > FWIW, I cannot reproduce this: I tried Dired on a remote host with
> > which I have connection that is quite slow, and saw neither high CPU
> > usage nor a significant delay in displaying a Dired buffer.
> 
> It seems to be related to font-locking, indeed. See variable
> `dired-font-lock-keywords'. It specifies face recognition running basic
> file oprtations. For example, ";; Broken Symbolic link" calls
> `file-truename' and `file-exists-p', while "Symbolic link to a directory"
> and ";; Symbolic link to a non-directory" invoke `file-truename' and
> `file-directory-p'.

But font-lock is ON by default, so what I saw also includes this,
right?

> I believe it would be helpful to suppress these checks via a user
> option.

What's wrong with "M-x font-lock-mode RET"?

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

[Sean Whitton]

Hello,

On Fri 06 Sep 2024 at 02:30pm +03, Eli Zaretskii wrote:

> Thanks, but I see no reason to document this command in the manual,
> certainly not in the ELisp reference (it's a command, not a function).
> IMO it's obscure enough to be documented only in NEWS.

That's quite fine with me.

> Should this be "[:space:]\\n\\r" instead? if not, why not?
>
> Also note that [:space:] depends on mode-specific syntax table, so I
> question the wisdom of using it in a command that's supposed to be
> mode-agnostic.

Both excellent points, thank you.  I looked at the POSIX standard and
came up with a new default value.

>> +This command is like `forward-word' except that words are always
>> +delimited by whitespace, regardless of the buffer's syntax table.
>> +Like `forward-word', this command respects fields.
>> +
>> +This emulates how C-w at the Unix terminal or shell identifies words.
>> +See the `unix-word-rubout' command in Info node `(readline)Commands For
>> +Killing'."
>
> This should try to be more explicit about what "word" means for this
> command.  Since it's so different from any notion of "word" in Emacs,
> I would even seriously consider not to use that word, or maybe quote
> it (in addition to explaining what it means).

This is very helpful.  You're right.  In the attached, I've tried using
"unix-word".  Let me know what you think of that.

> Also, since this is a command, its doc string should clearly separate
> what happens in interactive invocation from what happens when called
> from Lisp.  DELIM belongs to the latter.  (Is it even useful to
> provide that option for Lisp-only calls? what's the use case for
> that?)
>
> And finally, I wonder why we need this command?  AFAIU, the original
> intent was to implement something similar to unix-word-rubout, not a
> new movement command.  If the plan has changed, I think we need to
> discuss the need once again.

I think it was unhelpful of me to send this in without callers.
I'm sorry about that.

The reason for adding this is that it factors out what is in common
between what Philip is doing, and unix-word-rubout.
So in the attached revised patch, I've included unix-word-rubout.

I've also included a second readline command which I have bound in my
own init.  It demonstrates why there is a need for DELIM.

By the way, forward-unix-word could also be a plain function.
I made it a command because, well, why not.  Let me know if you think it
should be switched back to a function.

-- 
Sean Whitton
>From c047e640399bb923728ed9967e8545d53b22ea5c Mon Sep 17 00:00:00 2001
From: Sean Whitton 
Date: Fri, 6 Sep 2024 11:35:46 +0100
Subject: [PATCH] New commands for moving and killing unix-words

* lisp/simple.el (forward-unix-word, unix-word-rubout)
(unix-filename-rubout): New commands.
* etc/NEWS: Document them.
---
 etc/NEWS   |  7 +++
 lisp/simple.el | 57 ++
 2 files changed, 64 insertions(+)

diff --git a/etc/NEWS b/etc/NEWS
index f3e719a34d3..54cf0a3df52 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -123,6 +123,13 @@ When using 'visual-wrap-prefix-mode' in buffers with variable-pitch
 fonts, the wrapped text will now be lined up correctly so that it's
 exactly below the text after the prefix on the first line.
 
+---
+** New commands for moving and killing unix-words.
+Unix-words are words separated by whitespace regardless of the buffer's
+syntax table.  In a Unix terminal or shell, C-w kills by unix-word.
+The new commands 'forward-unix-word', 'unix-word-rubout' and
+'unix-filename-rubout' allow you to bind keys to operate more similarly
+to the terminal.
 
 * Changes in Specialized Modes and Packages in Emacs 31.1
 
diff --git a/lisp/simple.el b/lisp/simple.el
index 2453a129d0a..0322ac0cd8c 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -8892,6 +8892,63 @@ current-word
   ;; If we found something nonempty, return it as a string.
   (unless (= start end)
 	(buffer-substring-no-properties start end)
+
+(defun forward-unix-word (arg &optional delim)
+  "Move forward ARG unix-words.
+A unix-word is whitespace-delimited.
+Interactively, ARG is the numeric prefix argument, defaulting to 1.
+A negative ARG means go backwards to the beginning of unix-words.
+
+Unix-words differ from Emacs words in that they are always delimited by
+whitespace, regardless of the buffer's syntax table.  This command
+emulates how C-w at the Unix terminal or shell identifies words.
+
+When called from Lisp, DELIM specifies what characters are considered
+whitespace.  It is a string as might be passed to `skip-chars-forward'.
+The default is \" \\f\\n\\r\\t\\v\".  Do not prefix a `^' character."
+  (interactive "^p")
+  (unless (zerop arg)
+;; We do skip over newlines by default because `backward-word' does.
+(let* ((delim (or delim " \f\n\r\t\v"))
+   (ndelim (format "^%s" delim))
+   (start (point))
+   (fun (if (> arg 0)
+#'skip-chars-forward
+   

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

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

Eli Zaretskii  writes:

Hi Eli,

>> > FWIW, I cannot reproduce this: I tried Dired on a remote host with
>> > which I have connection that is quite slow, and saw neither high CPU
>> > usage nor a significant delay in displaying a Dired buffer.
>>
>> It seems to be related to font-locking, indeed. See variable
>> `dired-font-lock-keywords'. It specifies face recognition running basic
>> file oprtations. For example, ";; Broken Symbolic link" calls
>> `file-truename' and `file-exists-p', while "Symbolic link to a directory"
>> and ";; Symbolic link to a non-directory" invoke `file-truename' and
>> `file-directory-p'.
>
> But font-lock is ON by default, so what I saw also includes this,
> right?

Sure. But we don't know the exact setting of the OP. The connection
could be extremely slow for him, Tramp's cache might be disabled,
whatever. Perhaps it's worth to rerun the test with "emacs -Q".

>> I believe it would be helpful to suppress these checks via a user
>> option.
>
> What's wrong with "M-x font-lock-mode RET"?

You would deactivate all fontifications, not only the ones related to
symlinks.

And you must do this in a hook of the dired buffer, before fontification
happens.

There exist `dired-hide-details-mode', which I don't know. Perhaps
enabling it in time would do the job?

Best regards, Michael.

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

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

> Now the change_frame_size(5) initial and final sizes look correct.

OK.  In the next step I'd like to isolate the menubar code as the sole
culprit for what's going in.  Please with master do

(setq default-frame-alist '((width . 200)))

or some other insanely large value so we can see whether we can make the
GTK error disappear this way.  And please apply the trivial patch

diff --git a/src/xfns.c b/src/xfns.c
index 3f0d8f3fcd0..c90ac9c0d37 100644
--- a/src/xfns.c
+++ b/src/xfns.c
@@ -5230,7 +5230,7 @@ DEFUN ("x-create-frame", Fx_create_frame, Sx_create_frame,

   gui_default_parameter (f, parms, Qmenu_bar_lines,
  NILP (Vmenu_bar_mode)
- ? make_fixnum (0) : make_fixnum (1),
+ ? make_fixnum (0) : make_fixnum (0),
  NULL, NULL, RES_TYPE_NUMBER);
   gui_default_parameter (f, parms, Qtab_bar_lines,
  NILP (Vtab_bar_mode)
@@ -5342,7 +5342,7 @@ DEFUN ("x-create-frame", Fx_create_frame, Sx_create_frame,

 #if defined (USE_X_TOOLKIT) || defined (USE_GTK)
   /* Create the menu bar.  */
-  if (!minibuffer_only && FRAME_EXTERNAL_MENU_BAR (f))
+  if (0) // !minibuffer_only && FRAME_EXTERNAL_MENU_BAR (f))
 {
   /* If this signals an error, we haven't set size hints for the
 frame and we didn't make it visible.  */

and do C-x 5 2.

martin

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

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

On Fri, 6 Sept 2024 at 15:16, martin rudalics  wrote:

>
> OK.  In the next step I'd like to isolate the menubar code as the sole
> culprit for what's going in.  Please with master do
>
> (setq default-frame-alist '((width . 200)))
>

It takes effect on the initial frame, but doesn't affect the size of the
frame opened with C-x 5 2, or remove the gtk error message:

(emacs:2091071): Gtk-CRITICAL **: 15:57:43.714:
gtk_distribute_natural_allocation: assertion 'extra_space >= 0' failed

(Just to confirm: I put this setting in early-init.el.)

I then applied the trivial patch you gave to git master HEAD, ran 'emacs
-Q' and did C-x 5 2, and got a small window as usual, but with no error
message in the terminal.

-- 
https://rrt.sc3d.org

bug#73072: 30.0.90; which-key uses unexpected format of version information

[Constant]

Inspecting the which-key source file shows many of the variable's
`:package-version' information is in the form of a string instead of a
cons cell with the car of the package name and the cdr of the string
(See transient's '(transient . "0.1.0") :package-version for an
example). This causes functions that expect a cons from the package
version of a symbol to fail, as they try to access the cdr of the
`custom-package-version' property of which-key symbols.

In GNU Emacs 30.0.90 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.41, cairo version 1.18.0) of 2024-09-05 built on localhost
Repository revision: 54071b9cef287ac6826d67534d0c5c935bbca78c
Repository branch: emacs-30
System Description: Gentoo Linux

Configured using:
 'configure --prefix=/usr --build=x86_64-pc-linux-gnu
 --host=x86_64-pc-linux-gnu --mandir=/usr/share/man
 --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc
 --localstatedir=/var/lib --datarootdir=/usr/share
 --disable-silent-rules --docdir=/usr/share/doc/emacs-30.0.-r1
 --htmldir=/usr/share/doc/emacs-30.0.-r1/html --libdir=/usr/lib64
 --program-suffix=-emacs-30-vcs --includedir=/usr/include/emacs-30-vcs
 --infodir=/usr/share/info/emacs-30-vcs --localstatedir=/var
 --enable-locallisppath=/etc/emacs:/usr/share/emacs/site-lisp
 --without-compress-install --without-hesiod --without-pop
 --with-file-notification=inotify --with-pdumper --enable-acl
 --enable-xattr --with-dbus --without-modules --without-gameuser
 --with-libgmp --with-gpm --with-native-compilation=aot
 --without-kerberos --without-kerberos5 --with-lcms2 --with-xml2
 --without-mailutils --without-selinux --with-sqlite3 --with-gnutls
 --without-libsystemd --with-threads --with-tree-sitter
 --without-wide-int --with-sound=alsa --with-zlib --with-pgtk
 --without-x --without-ns --with-toolkit-scroll-bars --without-gconf
 --without-gsettings --with-harfbuzz --with-libotf --with-m17n-flt
 --without-xwidgets --with-gif --with-jpeg --with-png --with-rsvg
 --with-tiff --without-webp --without-imagemagick --with-dumping=pdumper
 'CFLAGS=-mtune=native -O2 -pipe -fno-fast-math -ffp-contract=off'
 CPPFLAGS= 'LDFLAGS=-Wl,-O1 -Wl,--as-needed
 -Wl,-z,pack-relative-relocs''

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM HARFBUZZ JPEG LCMS2
LIBOTF LIBXML2 NATIVE_COMP NOTIFY INOTIFY PDUMPER PGTK PNG RSVG SECCOMP
SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER XIM GTK3 ZLIB

Important settings:
  value of $LANG: C.UTF8
  locale-coding-system: utf-8-unix

Major mode: ELisp/l

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

Load-path shadows:
None found.

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

Memory information:
((conses 16 53793 18495) (symbols 48 5401 0) (strings 32 14397 2591)
 (string-bytes 1 476535) (vectors 16 9403)
 (vector-slots 8 132331 12225) (floats 8 26 789) (intervals 56 900 0)
 (buffers 992 14))

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

[Suhail Singh]

Eli Zaretskii  writes:

>> The version of `ls' on this host is:
>> 
>> #+begin_quote
>>   ls (GNU coreutils) 8.32
>>   Copyright (C) 2020 Free Software Foundation, Inc.
>>   License GPLv3+: GNU GPL version 3 or later 
>> .
>>   This is free software: you are free to change and redistribute it.
>>   There is NO WARRANTY, to the extent permitted by law.
>> 
>>   Written by Richard M. Stallman and David MacKenzie.
>> #+end_quote
>
> This cannot be true: the --dired option was added to 'ls' way earlier.
> I have Coreutils 6.9 from 2007 on one of my systems, and --dired is
> supported there.  To see if it is supported, try this:
>
>   $ ls -al --dired
>
> You should see 2 extra lines of output after the listing, each one
> starting with "//DIRED".

I understand that said version should have had --dired support, but
that's not what I observed.  Regardless, I got the sysadmin to do an
upgrade and now `ls --dired' is giving the expected output.  However,
the performance issues still persist and continue to be reproducible on
my end via emacs -Q.

-- 
Suhail

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

[Suhail Singh]

Eli Zaretskii  writes:

>> Based on =profiler-report=, the following function "chains" consume most of 
>> the
>> CPU:
>> - `font-lock-fontify-keywords-region'
>>   - tramp-sh-file-name-handler
>> - tramp-sh-handle-file-truename
>>   - `tramp-wait-for-regexp'
>> - tramp-sh-handle-file-exists-p
>>   - `tramp-wait-for-regexp'
>> - tramp-sh-handle-file-directory-p
>>   - `tramp-wait-for-regexp'
>> - tramp-sh-handle-file-attributes
>>   - `tramp-wait-for-regexp'
>> 
>> As noted previously, disabling global-font-lock-mode helps.
>
> FWIW, I cannot reproduce this: I tried Dired on a remote host with
> which I have connection that is quite slow, and saw neither high CPU
> usage nor a significant delay in displaying a Dired buffer.

In my case, the directory in question had 22 symlinks.  How many
symlinks did you try with?

-- 
Suhail

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

[Daniel Pettersson]

Eli Zaretskii  writes:

> That depends on the reason why the CR character appeared there in the
> first place.  Are they required for the strings in questions, or are
> they simply an artifact of how the server marshaled JSON data on the
> wire?

I am not convinced, in my mind if the marshaling operation converts \n
to \r\n (or any other character combination) within a string literal,
then the server's JSON conversion is broken.

> In the latter case, the CR characters are the result of
> Windows-style text writing, which adds a CR to each newline, and
> therefore removing that CR should indeed happen where Emacs decodes
> the EOLs of the incoming stuff.

I fail to see how that is not due to an broken json marshaling and not
intentionally chosen line endings by the server.

Of course I might be overlooking something.

/Daniel Pettersson

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

[Suhail Singh]

Michael Albinus  writes:

>>> Based on =profiler-report=, the following function "chains" consume most of 
>>> the
>>> CPU:
>>> - `font-lock-fontify-keywords-region'
>>>   - tramp-sh-file-name-handler
>>> - tramp-sh-handle-file-truename
>>>   - `tramp-wait-for-regexp'
>>> - tramp-sh-handle-file-exists-p
>>>   - `tramp-wait-for-regexp'
>>> - tramp-sh-handle-file-directory-p
>>>   - `tramp-wait-for-regexp'
>>> - tramp-sh-handle-file-attributes
>>>   - `tramp-wait-for-regexp'
>>>
>>> As noted previously, disabling global-font-lock-mode helps.
>>
>> FWIW, I cannot reproduce this: I tried Dired on a remote host with
>> which I have connection that is quite slow, and saw neither high CPU
>> usage nor a significant delay in displaying a Dired buffer.
>
> It seems to be related to font-locking, indeed. See variable
> `dired-font-lock-keywords'. It specifies face recognition running basic
> file oprtations. For example, ";; Broken Symbolic link" calls
> `file-truename' and `file-exists-p', while "Symbolic link to a directory"
> and ";; Symbolic link to a non-directory" invoke `file-truename' and
> `file-directory-p'.
>
> I believe it would be helpful to suppress these checks via a user
> option.

I agree.  Having a user configuration(s) that allows one to selectively
disable some of the possibly more expensive checks would be valuable.
If that were available, user configuration code could determine their
own rules or thresholds as to when those options should be toggled
(without disabling font-locking in its entirety).

If performance degradation could be dynamically checked by Emacs
(something akin to so-long-action and so-long-predicate, but for this
instance of font-locking instead) that would be ideal, but it may not be
easy to implement and it certainly isn't necessary - when things get
unresponsive, it's pretty apparent.

> And no, the checks shouldn't be suppressed for remote directories in
> general, on a fast connection they are valuable.

I agree.

> In bug#17064, the impact of these calls where discussed. The conclusion was
>
>> Or could this have any bad side effects?  Is it maybe too heavy to call
>> `file-truename'?
>
> Normally, there aren't many symlinks in a buffer, so I think the
> performance impact would be negligible.
>
> Likely, this was too optimistic ...

For the host where I noticed this issue, the directory in question had
22 symlinks.

-- 
Suhail

bug#73072: 30.0.90; which-key uses unexpected format of version information

[Eli Zaretskii]

> From: Constant 
> Date: Fri, 6 Sep 2024 11:09:41 -0400
> 
> Inspecting the which-key source file shows many of the variable's
> `:package-version' information is in the form of a string instead of a
> cons cell with the car of the package name and the cdr of the string

Thanks, fixed.

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

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

Michael Heerdegen  writes:

> > Maybe this is reproducible only on very long Dired buffers?

After following the recipe literally, I could reproduce that thing, too.

Maybe this issue occurring depends on what exactly is replaced - symlink
targets.  In this case, (font-lock-ensure) does make a
difference.

Yesterday I had experimented with replacing in symlink names - in that
case, the whole buffer had been considered.


Michael.

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

[Eli Zaretskii]

> From: Michael Albinus 
> Cc: suhailsingh...@gmail.com,  73...@debbugs.gnu.org
> Date: Fri, 06 Sep 2024 16:09:23 +0200
> 
> Eli Zaretskii  writes:
> 
> >> It seems to be related to font-locking, indeed. See variable
> >> `dired-font-lock-keywords'. It specifies face recognition running basic
> >> file oprtations. For example, ";; Broken Symbolic link" calls
> >> `file-truename' and `file-exists-p', while "Symbolic link to a directory"
> >> and ";; Symbolic link to a non-directory" invoke `file-truename' and
> >> `file-directory-p'.
> >
> > But font-lock is ON by default, so what I saw also includes this,
> > right?
> 
> Sure. But we don't know the exact setting of the OP. The connection
> could be extremely slow for him, Tramp's cache might be disabled,
> whatever. Perhaps it's worth to rerun the test with "emacs -Q".

I think we should also try to establish how slow is that connection.
How much time does "ping" take?  How long does it take to fetch a file
of, say 20 KBytes?

Also, if font-lock is disabled, does the problem go away?

bug#73044: [PATCH] Add project-find-file-in-root

[Dmitry Gutov]

Version: 31.1

Hi Spencer,

On 05/09/2024 17:01, Spencer Baugh via Bug reports for GNU Emacs, the 
Swiss army knife of text editors wrote:

Several users have asked me for a command which is just
find-file, but starting from the project root.  In large
projects, where project-files is expensive, this will have
substantially better performance than project-find-file.

Also, it allows opening files which aren't included in
project-files without paying the further cost of running
project--files-in-directory (which is what happens when passing
INCLUDE-ALL=t to project-find-file).

Also, it may help with user confusion about why
project-find-file doesn't behave like find-file.  (which I've
encountered a few times)

This command is equivalent to C-x p o C-x C-f, but it's nice to
be able to bind it to a specific key.

Overall, this is easy enough to provide, so let's just do that.


Makes sense, thanks, pushed to master (adding the 'interactive' form and 
a NEWS entry).


The name is a little verbose - if anybody has a better idea later, 
they're welcome to suggest it, there is some time to do a change.

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

[Philip Kaludercic]

Sean Whitton  writes:

> Hello,
>
> On Fri 06 Sep 2024 at 02:30pm +03, Eli Zaretskii wrote:
>
>> Thanks, but I see no reason to document this command in the manual,
>> certainly not in the ELisp reference (it's a command, not a function).
>> IMO it's obscure enough to be documented only in NEWS.
>
> That's quite fine with me.
>
>> Should this be "[:space:]\\n\\r" instead? if not, why not?
>>
>> Also note that [:space:] depends on mode-specific syntax table, so I
>> question the wisdom of using it in a command that's supposed to be
>> mode-agnostic.
>
> Both excellent points, thank you.  I looked at the POSIX standard and
> came up with a new default value.
>
>>> +This command is like `forward-word' except that words are always
>>> +delimited by whitespace, regardless of the buffer's syntax table.
>>> +Like `forward-word', this command respects fields.
>>> +
>>> +This emulates how C-w at the Unix terminal or shell identifies words.
>>> +See the `unix-word-rubout' command in Info node `(readline)Commands For
>>> +Killing'."
>>
>> This should try to be more explicit about what "word" means for this
>> command.  Since it's so different from any notion of "word" in Emacs,
>> I would even seriously consider not to use that word, or maybe quote
>> it (in addition to explaining what it means).
>
> This is very helpful.  You're right.  In the attached, I've tried using
> "unix-word".  Let me know what you think of that.
>
>> Also, since this is a command, its doc string should clearly separate
>> what happens in interactive invocation from what happens when called
>> from Lisp.  DELIM belongs to the latter.  (Is it even useful to
>> provide that option for Lisp-only calls? what's the use case for
>> that?)
>>
>> And finally, I wonder why we need this command?  AFAIU, the original
>> intent was to implement something similar to unix-word-rubout, not a
>> new movement command.  If the plan has changed, I think we need to
>> discuss the need once again.
>
> I think it was unhelpful of me to send this in without callers.
> I'm sorry about that.
>
> The reason for adding this is that it factors out what is in common
> between what Philip is doing, and unix-word-rubout.
> So in the attached revised patch, I've included unix-word-rubout.

Right, this is the command that we agreed on being necessary to appease
both people who want C-w to kill the region when no transient
region is active or to kill a word.

> I've also included a second readline command which I have bound in my
> own init.  It demonstrates why there is a need for DELIM.
>
> By the way, forward-unix-word could also be a plain function.
> I made it a command because, well, why not.  Let me know if you think it
> should be switched back to a function.
>
> -- 
> Sean Whitton
>
> From c047e640399bb923728ed9967e8545d53b22ea5c Mon Sep 17 00:00:00 2001
> From: Sean Whitton 
> Date: Fri, 6 Sep 2024 11:35:46 +0100
> Subject: [PATCH] New commands for moving and killing unix-words
>
> * lisp/simple.el (forward-unix-word, unix-word-rubout)
> (unix-filename-rubout): New commands.
> * etc/NEWS: Document them.
> ---
>  etc/NEWS   |  7 +++
>  lisp/simple.el | 57 ++
>  2 files changed, 64 insertions(+)
>
> diff --git a/etc/NEWS b/etc/NEWS
> index f3e719a34d3..54cf0a3df52 100644
> --- a/etc/NEWS
> +++ b/etc/NEWS
> @@ -123,6 +123,13 @@ When using 'visual-wrap-prefix-mode' in buffers with 
> variable-pitch
>  fonts, the wrapped text will now be lined up correctly so that it's
>  exactly below the text after the prefix on the first line.
>  
> +---
> +** New commands for moving and killing unix-words.
> +Unix-words are words separated by whitespace regardless of the buffer's
> +syntax table.  In a Unix terminal or shell, C-w kills by unix-word.
> +The new commands 'forward-unix-word', 'unix-word-rubout' and
> +'unix-filename-rubout' allow you to bind keys to operate more similarly
> +to the terminal.
>  
>  * Changes in Specialized Modes and Packages in Emacs 31.1
>  
> diff --git a/lisp/simple.el b/lisp/simple.el
> index 2453a129d0a..0322ac0cd8c 100644
> --- a/lisp/simple.el
> +++ b/lisp/simple.el
> @@ -8892,6 +8892,63 @@ current-word
>;; If we found something nonempty, return it as a string.
>(unless (= start end)
>   (buffer-substring-no-properties start end)
> +
> +(defun forward-unix-word (arg &optional delim)
> +  "Move forward ARG unix-words.
> +A unix-word is whitespace-delimited.
> +Interactively, ARG is the numeric prefix argument, defaulting to 1.
> +A negative ARG means go backwards to the beginning of unix-words.
> +
> +Unix-words differ from Emacs words in that they are always delimited by
> +whitespace, regardless of the buffer's syntax table.  This command
> +emulates how C-w at the Unix terminal or shell identifies words.

Should you mention the ^W notation here as well?

> +
> +When called from Lisp, DELIM specifies what characters are considered
> +whitespace.  It is a string as 

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

[Suhail Singh]

Michael Albinus  writes:

>>> > FWIW, I cannot reproduce this: I tried Dired on a remote host with
>>> > which I have connection that is quite slow, and saw neither high CPU
>>> > usage nor a significant delay in displaying a Dired buffer.
>>>
>>> It seems to be related to font-locking, indeed. See variable
>>> `dired-font-lock-keywords'. It specifies face recognition running basic
>>> file oprtations. For example, ";; Broken Symbolic link" calls
>>> `file-truename' and `file-exists-p', while "Symbolic link to a directory"
>>> and ";; Symbolic link to a non-directory" invoke `file-truename' and
>>> `file-directory-p'.
>>
>> But font-lock is ON by default, so what I saw also includes this,
>> right?
>
> Sure. But we don't know the exact setting of the OP. The connection
> could be extremely slow for him, Tramp's cache might be disabled,
> whatever. Perhaps it's worth to rerun the test with "emacs -Q".

The issue was observed with emacs -Q on a remote directory that had 22
symlinks.  On the affected host, I am able to reliably reproduce the
issue by evaluating the code below and then navigating to
/tmp/test/links in dired via TRAMP.

#+name: perf-fix/tramp/font-lock-on-dired/reproducer
#+begin_src sh
  cd /tmp
  rm -rf /tmp/test
  mkdir /tmp/test
  cd /tmp/test
  for i in `seq -w 0 21`; do
  mkdir -p src/"$i"
  done
  mkdir -p links
  cd links
  for i in `seq -w 0 21`; do
  ln -sf /tmp/test/src/"$i"
  done
#+end_src

Notably, for the affected host, the issue is reproducible using above
even after a new OS install.  However, the above test case doesn't cover
all variables affecting the issue.  Specifically, when I run the above
code on a different host (with faster connection and fewer hops to get
to) and navigate to /tmp/test/links the severity of the issue is much
less.  That being said, the profiler reports (starting from emacs -Q and
after establishing connection with host in question via TRAMP) for both
the affected and not-as-affected host are similar.  I believe the issue
is present on the unaffected host as well, but with much less severity
for some reason.

My guess is that connection speed (in addition to the number of symlinks
in the directory in question) is a determining factor.  I am speculating
here, but perhaps TRAMP is busy-waiting for a response?  That would be
consistent with what I observe, but I am not sure how to verify that.

>>> I believe it would be helpful to suppress these checks via a user
>>> option.
>>
>> What's wrong with "M-x font-lock-mode RET"?
>
> You would deactivate all fontifications, not only the ones related to
> symlinks.
>
> And you must do this in a hook of the dired buffer, before fontification
> happens.

Yes, precisely.  That is my current workaround.  It's far from ideal,
but it at least allows Emacs to be in a semi-workable state.  It would
be much better if there were a way to suppress only the "expensive"
font-locking checks in this case.

> There exist `dired-hide-details-mode', which I don't know. Perhaps
> enabling it in time would do the job?

It, unfortunately, doesn't help.

-- 
Suhail

bug#73044: [PATCH] Add project-find-file-in-root

[Eli Zaretskii]

> Resent-To: bug-gnu-emacs@gnu.org
> Date: Fri, 6 Sep 2024 19:20:16 +0300
> From: Dmitry Gutov 
> 
> > This command is equivalent to C-x p o C-x C-f, but it's nice to
> > be able to bind it to a specific key.
> > 
> > Overall, this is easy enough to provide, so let's just do that.
> 
> Makes sense, thanks, pushed to master (adding the 'interactive' form and 
> a NEWS entry).

Thanks, but why only NEWS?  I think this should be in the user manual
as well.

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

[Suhail Singh]

Eli Zaretskii  writes:

> I think we should also try to establish how slow is that connection.
> How much time does "ping" take?

The server doesn't respond to "ping" requests so I cannot test that.
There are however more than 14 hops as reported by mtr.  How much more I
cannot say, unfortunately.

> How long does it take to fetch a file of, say 20 KBytes?

Given a 20kb file generated via:
#+begin_src sh :results verbatim
  mkdir -p /tmp/test
  cd /tmp/test
  dd if=/dev/urandom of=upload_test bs=10k count=2
  du -sh /tmp/test/upload_test
#+end_src

#+RESULTS:
: 20K   /tmp/test/upload_test

It takes ~4-6s to upload:
#+begin_src sh :results verbatim
  cd /tmp/test
  {
  time scp upload_test scp://${affected-host}//tmp/upload_test
  } 2>&1
#+end_src

#+RESULTS:
: 
: real  0m4.255s
: user  0m0.008s
: sys   0m0.002s

And a similar time to download:
#+begin_src sh :results verbatim
  cd /tmp/test
  {
  time scp scp://${affected-host}//tmp/upload_test ./download_test
  } 2>&1
#+end_src

#+RESULTS:
: 
: real  0m5.638s
: user  0m0.007s
: sys   0m0.000s


> Also, if font-lock is disabled, does the problem go away?

As noted in the original message:

>>> Disabling global-font-lock-mode, makes the situation better.

Things are still sluggish after disabling font-lock, but they are *much*
better (i.e., instead of a ~10s delay for revert-buffer we are down to
less than a second).  The remaining sluggishness seems reasonable given
what I know about the connection speed, but I have not done extensive
quantitative testing.  As such, while I cannot say with certainty if
"the problem" goes away entirely, or only mostly, it does improve
significantly.

-- 
Suhail

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

[Eli Zaretskii]

> From: Suhail Singh 
> Cc: suhailsingh...@gmail.com,  Michael Albinus ,
>   73...@debbugs.gnu.org
> Date: Fri, 06 Sep 2024 13:47:54 -0400
> 
> > How long does it take to fetch a file of, say 20 KBytes?
> 
> Given a 20kb file generated via:
> #+begin_src sh :results verbatim
>   mkdir -p /tmp/test
>   cd /tmp/test
>   dd if=/dev/urandom of=upload_test bs=10k count=2
>   du -sh /tmp/test/upload_test
> #+end_src
> 
> #+RESULTS:
> : 20K /tmp/test/upload_test
> 
> It takes ~4-6s to upload:
> #+begin_src sh :results verbatim
>   cd /tmp/test
>   {
>   time scp upload_test scp://${affected-host}//tmp/upload_test
>   } 2>&1
> #+end_src
> 
> #+RESULTS:
> : 
> : real0m4.255s
> : user0m0.008s
> : sys 0m0.002s
> 
> And a similar time to download:
> #+begin_src sh :results verbatim
>   cd /tmp/test
>   {
>   time scp scp://${affected-host}//tmp/upload_test ./download_test
>   } 2>&1
> #+end_src
> 
> #+RESULTS:
> : 
> : real0m5.638s
> : user0m0.007s
> : sys 0m0.000s
> 
> 
> > Also, if font-lock is disabled, does the problem go away?
> 
> As noted in the original message:
> 
> >>> Disabling global-font-lock-mode, makes the situation better.
> 
> Things are still sluggish after disabling font-lock, but they are *much*
> better (i.e., instead of a ~10s delay for revert-buffer we are down to
> less than a second).  The remaining sluggishness seems reasonable given
> what I know about the connection speed, but I have not done extensive
> quantitative testing.  As such, while I cannot say with certainty if
> "the problem" goes away entirely, or only mostly, it does improve
> significantly.

So if it takes 4 to 5 sec to move a 20KB file, then how much stuff
needs to be moved for the Dired listing?  What does the below show, if
you run it on that remote machine?

  $ ls -al | wc

It needs to show around 40KB to explain 10 sec of delay.

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

[João Távora]

On Fri, Sep 6, 2024 at 6:44 AM Eli Zaretskii  wrote:
>
> > From: Daniel Pettersson 
> > Cc: Eli Zaretskii ,  Troy Brown ,
> >   felician.nem...@gmail.com,  72...@debbugs.gnu.org
> > Date: Thu, 05 Sep 2024 23:32:08 +0200
> >
> > > Anyway, if the solution is to be performed at this lower
> > > level (which I think it should), then Daniel Petterson
> > > jsonrpc.el maintainer should be added.
> >
> > I might be missing something, but jsonrpc should not in my mind
> > convert/format/encode any json data.  Any assumptions on line endings
> > can only be made on header and content separators, not on the json
> > payload itself.
>
> That depends on the reason why the CR character appeared there in the
> first place.  Are they required for the strings in questions, or are
> they simply an artifact of how the server marshaled JSON data on the
> wire?

Indeed this is the question.  And it is not necessarily easy to asnwer.
For example most LSP servers may be used to edit CRLF terminated
files, and when doing so they will possibly exchange file snippets with
intentional CR chars in them (however odd that may be for most
people, it can happen).  But that is theoretically completely independent
of the decision to terminate documentation snippets with CRLF or just
LF or just CR.  Both these kinds of snippets are transmitted as JSON
strings over the wire.  jsonrpc.el makes them Elisp strings and (afair)
doesn't do any newline conversion.

Even if Eglot is most well positioned to answer this question in
the LSP case, i don't think it can: there's no interface for doing so.
If it could, then it could theoretically ask jsonrpc.el to do that
conversion. But it can't.

So perhaps something like Troys patch for the "doc view" layer
is best if inefficient/hacky.  Even fixing it in gfm-view-mode isn't a bad
idea. But also, I don't think this is a very urgent matter: the server
that does this is clearly in the minority.  I would just ask this server's
devs if they wouldn't mind not sending these odd doc snippets.

João

bug#73044: [PATCH] Add project-find-file-in-root

[Dmitry Gutov]

On 06/09/2024 20:44, Eli Zaretskii wrote:

Resent-To:bug-gnu-emacs@gnu.org
Date: Fri, 6 Sep 2024 19:20:16 +0300
From: Dmitry Gutov


This command is equivalent to C-x p o C-x C-f, but it's nice to
be able to bind it to a specific key.

Overall, this is easy enough to provide, so let's just do that.

Makes sense, thanks, pushed to master (adding the 'interactive' form and
a NEWS entry).

Thanks, but why only NEWS?  I think this should be in the user manual
as well.


I don't know, to me it seems like a niche enough feature, having lived 
without this addition for a number of major releases.


Spencer seems to agree, having submitted the patch without a default 
binding.


But if someone wants to describe it in the manual, I of course wouldn't 
mind. They can mention the situations described in this report.

bug#73082: 30; Inconsistent Stipple Support

[JD Smith]

The :stipple face attribute is not consistently supported across all Emacs 30 
builds, with incorrect or missing stipple display for NS and GTK+Cairo builds.  

The following test of :stipple should lead to an image similar to the attached.

(let* ((w (window-font-width))
   (stipple `(,w 1 ,(apply #'unibyte-string (make-list (/ (+ w 7) 8) 
186)
  (insert "\n" (propertize (concat  (make-string 15 ?\s)
"THIS IS A TEST"
(make-string 15 ?\s))
   'face `(:background "red" :foreground "blue" 
:stipple ,stipple

Only some Emacs 30 builds correctly render this simple stipple.  There has been 
some progress on :stipple support recently, but it remains incomplete.  To my 
knowledge, the current situation for :stipple support in Emacs 30 is as follows:
NS (partially working): Commit ef6ffbdc79 from last May provided a partial fix, 
but stipples are black and white only (bug#70712)
Windows (working?): patched in June (bug#71159)
PGTK (working): incorrect stipple display patched July, 2023 (bug#64969)
GTK, non-Cairo (working): appears to be working correctly
GTK + Cairo (not working uniformly): Stipples are reported to be missing with 
some Cairo builds of Emacs 30
Other X11 builds (?): Unsure if these are supported (but suspect they are given 
the legacy of stipple)



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

[Dmitry Gutov]

On 03/09/2024 19:39, Philip Kaludercic wrote:

I could imagine this might be extended to allow an auto-generate option,
but that feature seems out of scope of this patch, and probably would
require some interoperation with project.el.

Indeed. Actually, I have an old, WIP patch for tag file
auto-generation which, yes, uses project.el. I can post it again if
you're curious.

Hasn't this issue been resolved by `etags-regen-mode'?


The part quoted above was, I think.

What might still be missing, is functioning better without having a tags 
table generated - after all etags-regen-mode is off by default, and it 
might not work for certain projects anyway.


Maybe just like this? This makes Xref identifier completion not query 
for TAGS unless already loaded. In many cases that would be TRT, 
although `C-u M-.` seems to regress (seems like we *would* want to query 
eagerly there).


Adding a user option is still... an option.

diff --git a/lisp/progmodes/etags.el b/lisp/progmodes/etags.el
index d3eb0d46e9b..a4e9abe9b7a 100644
--- a/lisp/progmodes/etags.el
+++ b/lisp/progmodes/etags.el
@@ -2102,7 +2102,9 @@ xref-backend-identifier-at-point

 (cl-defmethod xref-backend-identifier-completion-table ((_backend
  (eql 'etags)))
-  (tags-lazy-completion-table))
+  (and (or tags-file-name
+   tags-table-list)
+   (tags-lazy-completion-table)))

 (cl-defmethod xref-backend-identifier-completion-ignore-case ((_backend
(eql 
'etags)))

bug#72441: 31.0.50; Auth-source-pass doesn't match password attributes or hosts without user when extra-query-keywords is true

[J.P.]

"J.P."  writes:

> While exploring ways to tackle this feature, I stumbled on a couple
> minor bugs related to `auth-source-pass-extra-query-keywords'.
>
> Because there's no telling when we'll end up with something installable
> for this feature, I've gone ahead and isolated the fixes into a separate
> patch (0001 in the attached). It's probably safe enough for Emacs 30,
> but since the option was introduced back in 29, I'll just install it on
> master (unless I hear otherwise in the coming days). Thanks.

Installed on master as

  https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=80228d1f

As previously mentioned, the above commit only addresses an ancillary
issue, so the bug should remain open.

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

[Suhail Singh]

Eli Zaretskii  writes:

> So if it takes 4 to 5 sec to move a 20KB file, then how much stuff
> needs to be moved for the Dired listing?  What does the below show, if
> you run it on that remote machine?
>
>   $ ls -al | wc

Given that the contents of the remote directory can be exactly
replicated (apart from metadata such as mtime etc) by the below code
(that I shared in another response), you should be able to answer the
question trivially:

#+name: perf-fix/tramp/font-lock-on-dired/reproducer
#+begin_src sh
  cd /tmp
  rm -rf /tmp/test
  mkdir /tmp/test
  cd /tmp/test
  for i in `seq -w 0 21`; do
  mkdir -p src/"$i"
  done
  mkdir -p links
  cd links
  for i in `seq -w 0 21`; do
  ln -sf /tmp/test/src/"$i"
  done
#+end_src

For the record, the output is as follows:

#+begin_src sh :dir /ssh:${affected-host}:/tmp
  cd /tmp/test/links
  ls -al | wc
#+end_src

#+RESULTS:
: 25 2621599


> It needs to show around 40KB to explain 10 sec of delay.

I don't understand your reasoning.  In fact if the output of ls -al was
indeed around 40kb I would have been very surprised.  The time taken for
transferring the 20KB file included initial connection costs whereas
TRAMP would presumably be reusing the same connection, but would be
sending multiple small requests.  I don't see how one can be compared to
the other, other than to say (generally) that when connection is slow
both workflows would take greater time (which is what we observe).

Note that disabling font-lock improved response delay considerably.
That means the delay is not due to transferring information contained in
`ls --dired', which is considerably fast (relatively speaking), but in
doing the additional checks that Michael mentioned:

>>> It seems to be related to font-locking, indeed. See variable
>>> `dired-font-lock-keywords'. It specifies face recognition running basic
>>> file oprtations. For example, ";; Broken Symbolic link" calls
>>> `file-truename' and `file-exists-p', while "Symbolic link to a directory"
>>> and ";; Symbolic link to a non-directory" invoke `file-truename' and
>>> `file-directory-p'.

I did some further investigation; summarizing findings below:

A. On Host-A, the network connection is fairly slow s.t. transferring a
   20KB file takes ~5s.  On Host-B, the network connection is fairly
   fast.

B. On Host-A, the time taken to refresh dired buffer containing 22
   Subdirectories (/tmp/test/src as in above code snippet) is 0.70-0.75s
   with font-lock enabled, and about the same with font-lock disabled.
   These times exclude the time taken to establish the intiial
   connection over TRAMP.

C. On Host-A, the time taken to refresh dired buffer containing 22
   symlinks (each symlink pointing to a directory, i.e., /tmp/test/links
   in the above code snippet) is 0.70-0.75s with font-lock disabled.
   With font-lock enabled the time taken is ~13-14s and the CPU is at
   100%.  These times exclude the time taken to establish the intiial
   connection over TRAMP.

D. On Host-B, the time taken to display dired buffer for /tmp/test/links
   with font-lock enabled is ~2s greater than when font-lock is
   disabled.  When /tmp/test/links contains 100 symlinks to directories
   (instead of 22), the time taken when font-lock is enabled is ~6s
   greater than when font-lock is disabled.

Given above, I conclude:

1. The issue is present when there are symlinks to directories.

2. The issue is worse when there are greater number of symlinks to
   directories.

2. The issue is worse when the connection is slower.  However, it is
   still observable when the connection is faster - if you're having
   difficulty reproducing, increase the number of symlinks to
   directories in /tmp/test/links above.

3. Given that when connection is slower, not only is the time taken for
   font-locking greater, but the CPU is at 100%, I suspect that the
   relevant code is doing some kind of busy-waiting.

The above observations seem consistent with Michael's comments above
regd. font-lock checks for "Broken Symbolink link" and "Symbolic link to
a directory".  As such, if Michael's proposal below is implemented I
believe it would be an adequate fix to the issue:

>>> I believe it would be helpful to suppress these checks via a user
>>> option. And no, the checks shouldn't be suppressed for remote
>>> directories in general, on a fast connection they are valuable.

I hope that clarifies things, and gives you sufficient information to be
able to reproduce

-- 
Suhail

bug#73084: [PATCH] Include the variable name in the `setopt` warning

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

Hello,

The attached patch adds the variable name to the `setopt` warning.

I write my Emacs config in an Org file, from which I make the Emacs Lisp 
file.  Currently, if `setopt` detects that the value I wish to make a 
variable hold does not conform to the variable's Custom.el type, then it 
reports the type and the problematic value, but not the variable itself, 
when I open Emacs.  This adds extra steps to editing the code in the Org 
file to fix the warning, especially when the value is created 
programmatically.  It would be faster to search for the variable name 
directly in the Org file and to then re-tangle the Org file.

Thank you.From 7cc7134b1b751428b7c14a0b54f55193a59363b1 Mon Sep 17 00:00:00 2001
From: Earl Hyatt 
Date: Fri, 6 Sep 2024 20:04:24 -0400
Subject: [PATCH] Include the variable name in the warning in `setopt--set'.

Including the variable name makes it easier to find the location of the
error.

* lisp/cus-edit.el (setopt--set): Include the variable name in the
warning.
---
 lisp/cus-edit.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/cus-edit.el b/lisp/cus-edit.el
index 9f5ac47490c..035499deb71 100644
--- a/lisp/cus-edit.el
+++ b/lisp/cus-edit.el
@@ -1072,7 +1072,7 @@ setopt--set
   ;; Check that the type is correct.
   (when-let ((type (get variable 'custom-type)))
 (unless (widget-apply (widget-convert type) :match value)
-  (warn "Value `%S' does not match type %s" value type)))
+  (warn "`%s': Value `%S' does not match type %s" variable value type)))
   (put variable 'custom-check-value (list value))
   (funcall (or (get variable 'custom-set) #'set-default) variable value))
 
-- 
2.34.1

bug#73044: [PATCH] Add project-find-file-in-root

[Eli Zaretskii]

> Date: Fri, 6 Sep 2024 23:05:06 +0300
> Cc: 73...@debbugs.gnu.org, sba...@janestreet.com
> From: Dmitry Gutov 
> 
> On 06/09/2024 20:44, Eli Zaretskii wrote:
> >> Resent-To:bug-gnu-emacs@gnu.org
> >> Date: Fri, 6 Sep 2024 19:20:16 +0300
> >> From: Dmitry Gutov
> >>
> >>> This command is equivalent to C-x p o C-x C-f, but it's nice to
> >>> be able to bind it to a specific key.
> >>>
> >>> Overall, this is easy enough to provide, so let's just do that.
> >> Makes sense, thanks, pushed to master (adding the 'interactive' form and
> >> a NEWS entry).
> > Thanks, but why only NEWS?  I think this should be in the user manual
> > as well.
> 
> I don't know, to me it seems like a niche enough feature, having lived 
> without this addition for a number of major releases.
> 
> Spencer seems to agree, having submitted the patch without a default 
> binding.
> 
> But if someone wants to describe it in the manual, I of course wouldn't 
> mind. They can mention the situations described in this report.

If you consider this not important enough to be in the manual, please
mark the NEWS entry with "---", to convey your opinion.

bug#73082: 30; Inconsistent Stipple Support

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

Eli Zaretskii  writes:

>> Cc: Po Lu 
>> From: JD Smith 
>> Date: Fri, 6 Sep 2024 17:58:02 -0400
>> 
>> (let* ((w (window-font-width))
>>(stipple `(,w 1 ,(apply #'unibyte-string (make-list (/ (+ w 7) 8) 
>> 186)
>>   (insert "\n" (propertize (concat  (make-string 15 ?\s)
>>  "THIS IS A TEST"
>>  (make-string 15 ?\s))
>>'face `(:background "red" :foreground "blue" 
>> :stipple ,stipple
>> 
>> Only some Emacs 30 builds correctly render this simple stipple.  There has 
>> been some progress on :stipple support recently, but it remains incomplete.  
>> To my knowledge, the current situation for :stipple support in Emacs 30 is 
>> as follows:
>> NS (partially working): Commit ef6ffbdc79 from last May provided a partial 
>> fix, but stipples are black and white only (bug#70712)
>> Windows (working?): patched in June (bug#71159)
>> PGTK (working): incorrect stipple display patched July, 2023 (bug#64969)
>> GTK, non-Cairo (working): appears to be working correctly
>> GTK + Cairo (not working uniformly): Stipples are reported to be missing 
>> with some Cairo builds of Emacs 30
>> Other X11 builds (?): Unsure if these are supported (but suspect they are 
>> given the legacy of stipple)
>
> The MS-Windows build of the emacs-30 branch here shows the display you
> expected.

You should add Haiku and Android to your list, as Emacs supports
stipples on both of these window systems.  (And on the latter they were
in fact implemented for your package.)

I am also interested to know precisely which Cairo builds fail to
display them, the stipple implementations being virtually identical
across the PGTK and the X + Cairo builds.

bug#73082: 30; Inconsistent Stipple Support

[Eli Zaretskii]

> Cc: Po Lu 
> From: JD Smith 
> Date: Fri, 6 Sep 2024 17:58:02 -0400
> 
> (let* ((w (window-font-width))
>(stipple `(,w 1 ,(apply #'unibyte-string (make-list (/ (+ w 7) 8) 
> 186)
>   (insert "\n" (propertize (concat  (make-string 15 ?\s)
>   "THIS IS A TEST"
>   (make-string 15 ?\s))
>'face `(:background "red" :foreground "blue" 
> :stipple ,stipple
> 
> Only some Emacs 30 builds correctly render this simple stipple.  There has 
> been some progress on :stipple support recently, but it remains incomplete.  
> To my knowledge, the current situation for :stipple support in Emacs 30 is as 
> follows:
> NS (partially working): Commit ef6ffbdc79 from last May provided a partial 
> fix, but stipples are black and white only (bug#70712)
> Windows (working?): patched in June (bug#71159)
> PGTK (working): incorrect stipple display patched July, 2023 (bug#64969)
> GTK, non-Cairo (working): appears to be working correctly
> GTK + Cairo (not working uniformly): Stipples are reported to be missing with 
> some Cairo builds of Emacs 30
> Other X11 builds (?): Unsure if these are supported (but suspect they are 
> given the legacy of stipple)

The MS-Windows build of the emacs-30 branch here shows the display you
expected.

bug#73082: 30; Inconsistent Stipple Support

[Arash Esbati]

JD Smith  writes:

> To my knowledge, the current situation for :stipple support in Emacs
> 30 is as follows:
>
> * NS (partially working): Commit ef6ffbdc79 from last May provided a
> partial fix, but stipples are black and white only (bug#70712)

FWIW, this is what I see on macOS with NS-port:

> * Windows (working?): patched in June (bug#71159)

And this is on Windows:

Both with "emacs -Q" incl. the value of `emacs-repository-version'.

Best, Arash

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

[Eli Zaretskii]

> Cc: 43...@debbugs.gnu.org
> Date: Sat, 7 Sep 2024 01:16:46 +0300
> From: Dmitry Gutov 
> 
> On 03/09/2024 19:39, Philip Kaludercic wrote:
> >>> I could imagine this might be extended to allow an auto-generate option,
> >>> but that feature seems out of scope of this patch, and probably would
> >>> require some interoperation with project.el.
> >> Indeed. Actually, I have an old, WIP patch for tag file
> >> auto-generation which, yes, uses project.el. I can post it again if
> >> you're curious.
> > Hasn't this issue been resolved by `etags-regen-mode'?
> 
> The part quoted above was, I think.
> 
> What might still be missing, is functioning better without having a tags 
> table generated - after all etags-regen-mode is off by default, and it 
> might not work for certain projects anyway.
> 
> Maybe just like this? This makes Xref identifier completion not query 
> for TAGS unless already loaded. In many cases that would be TRT, 
> although `C-u M-.` seems to regress (seems like we *would* want to query 
> eagerly there).

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

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

[Eli Zaretskii]

> From: Suhail Singh 
> Cc: Suhail Singh ,  michael.albi...@gmx.de,
>   73...@debbugs.gnu.org
> Date: Fri, 06 Sep 2024 20:19:34 -0400
> 
> Eli Zaretskii  writes:
> 
> > It needs to show around 40KB to explain 10 sec of delay.
> 
> I don't understand your reasoning.

It's simple arithmetics: if fetching a 20KB file takes 4 to 5 sec,
then the 10-sec delay you reported for Dired should mean we are
fetching about 40KB of data.

> In fact if the output of ls -al was indeed around 40kb I would have
> been very surprised.

In my home directory I get:

 $ ls -al ~ | wc
 7086371   43324

So a large enough (but not outlandishly large: just 700 files)
directory can indeed mean Emacs needs to fetch 40KB of data for
refreshing a Dired buffer.  Which led me to believe this is not an
impossible situation.

> The time taken for transferring the 20KB file included initial
> connection costs whereas TRAMP would presumably be reusing the same
> connection, but would be sending multiple small requests.

This just makes my argument stronger: it would mean that even 40KB
data moved for Dired would not quite explain the 10-sec delay.

> I did some further investigation; summarizing findings below:
> 
> A. On Host-A, the network connection is fairly slow s.t. transferring a
>20KB file takes ~5s.  On Host-B, the network connection is fairly
>fast.
> 
> B. On Host-A, the time taken to refresh dired buffer containing 22
>Subdirectories (/tmp/test/src as in above code snippet) is 0.70-0.75s
>with font-lock enabled, and about the same with font-lock disabled.
>These times exclude the time taken to establish the intiial
>connection over TRAMP.
> 
> C. On Host-A, the time taken to refresh dired buffer containing 22
>symlinks (each symlink pointing to a directory, i.e., /tmp/test/links
>in the above code snippet) is 0.70-0.75s with font-lock disabled.
>With font-lock enabled the time taken is ~13-14s and the CPU is at
>100%.  These times exclude the time taken to establish the intiial
>connection over TRAMP.
> 
> D. On Host-B, the time taken to display dired buffer for /tmp/test/links
>with font-lock enabled is ~2s greater than when font-lock is
>disabled.  When /tmp/test/links contains 100 symlinks to directories
>(instead of 22), the time taken when font-lock is enabled is ~6s
>greater than when font-lock is disabled.
> 
> Given above, I conclude:
> 
> 1. The issue is present when there are symlinks to directories.
> 
> 2. The issue is worse when there are greater number of symlinks to
>directories.
> 
> 2. The issue is worse when the connection is slower.  However, it is
>still observable when the connection is faster - if you're having
>difficulty reproducing, increase the number of symlinks to
>directories in /tmp/test/links above.
> 
> 3. Given that when connection is slower, not only is the time taken for
>font-locking greater, but the CPU is at 100%, I suspect that the
>relevant code is doing some kind of busy-waiting.

Thanks you.  So the problem seems to be symlinks, and specifically
symlinks to directories.  Michael, what does Tramp do specially in
these cases that could explain the slowdown?

> The above observations seem consistent with Michael's comments above
> regd. font-lock checks for "Broken Symbolink link" and "Symbolic link to
> a directory".

Michael, what do these checks entail, and why are they so
CPU-expensive and take a lot of time with slow connections?