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

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

> My bisection suggests the problematic commit is
> 241616831024c9c9fe2b2378b611db0a560b9675

Thanks.  Please try first setting 'frame-inhibit-implied-resize' to t
which should avoid that a frame gets resized when the menu bar is
enabled or disabled (this time I have slightly more hope that it fixes
your problem).

If this does not help, please proceed as follows: Try to undo that
commit (I cite it below) 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

whenever you hit that breakpoint (here the value is 27 all the time) -
that is when you create the initial frame and after C-x 5 2.  Then
restore current master and repeat the same steps.  When the values
differ, this should tell us something about what happens.

martin

--- a/src/gtkutil.c
+++ b/src/gtkutil.c
@@ -4141,7 +4141,7 @@ xg_update_frame_menubar (struct frame *f)
   g_signal_connect (x->menubar_widget, "map", G_CALLBACK (menubar_map_cb), f);
   gtk_widget_show_all (x->menubar_widget);
   gtk_widget_get_preferred_size (x->menubar_widget, NULL, &req);
-  req.height *= xg_get_scale (f);
+  req.height *= scale;

 #if !defined HAVE_PGTK && defined HAVE_GTK3
   if (FRAME_DISPLAY_INFO (f)->n_planes == 32)
@@ -4154,9 +4154,9 @@ xg_update_frame_menubar (struct frame *f)
 }
 #endif

-  if (FRAME_MENUBAR_HEIGHT (f) != (req.height * scale))
+  if (FRAME_MENUBAR_HEIGHT (f) != req.height)
 {
-  FRAME_MENUBAR_HEIGHT (f) = req.height * scale;
+  FRAME_MENUBAR_HEIGHT (f) = req.height;
   adjust_frame_size (f, -1, -1, 2, 0, Qmenu_bar_lines);
 }
   unblock_input ();

bug#73032: 31.0.50; vtable header is not aligned

[Eli Zaretskii]

> Date: Thu, 05 Sep 2024 01:45:14 +0300
> From:  Aleksandr Vityazev via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" 
> 
> There is a problem in vtable.el when an emoji is specified as a delimiter; the
> header and row delimiters are not aligned.
> 
> Minimal reproducer for emacs -Q:
> 
> (require 'vtable)
> (with-current-buffer (get-buffer-create "*test*")
>   (make-vtable
>:columns '((:name "Name" :width 20) "Size" "File")
>:objects (buffer-list)
>:actions '("k" kill-buffer
>   "RET" display-buffer)
>:divider " 🍉 "
>:getter (lambda (object column vtable)
>  (pcase (vtable-column vtable column)
>("Name" (buffer-name object))
>("Size" (buffer-size object))
>("File" (or (buffer-file-name object) "")
>   (switch-to-buffer "*test*"))
> 
> Screenshot is attached.

I cannot get them aligned even if I replace the Emoji character with
an ASCII character, like 'x'.  Can you?

AFAICT, there's inconsistency in whitespace calculation between the
header line and the body of the table, due to the desire to display
the sorting indicator not quite right-aligned.  The patch below
attempts to fix that; does it give good results?

diff --git a/lisp/emacs-lisp/vtable.el b/lisp/emacs-lisp/vtable.el
index cb7ea39..dd26ccd 100644
--- a/lisp/emacs-lisp/vtable.el
+++ b/lisp/emacs-lisp/vtable.el
@@ -722,15 +722,17 @@ vtable--insert-header-line
(vtable--limit-string
 name (- (elt widths index) indicator-width))
  name))
- (let ((fill-width
-(+ (- (elt widths index)
-  (string-pixel-width displayed)
-  indicator-width
-  (vtable-separator-width table)
-  ;; We want the indicator to not be quite flush
-  ;; right.
-  (/ (vtable--char-width table) 2.0))
-   (if last 0 spacer
+ (let* ((indicator-lead-width
+ ;; We want the indicator to not be quite flush right.
+ (/ (vtable--char-width table) 2.0))
+(indicator-pad-width (- (vtable--char-width table)
+indicator-lead-width))
+(fill-width
+ (+ (- (elt widths index)
+   (string-pixel-width displayed)
+   indicator-width
+   indicator-lead-width)
+(if last 0 spacer
(if (or (not last)
(zerop indicator-width)
(< (seq-reduce #'+ widths 0) (window-width nil t)))
@@ -739,7 +741,9 @@ vtable--insert-header-line
 displayed
 (propertize " " 'display
 (list 'space :width (list fill-width)))
-indicator)
+indicator
+(propertize " " 'display
+(list 'space :width (list indicator-pad-width
  ;; This is the final column, and we have a sorting
  ;; indicator, and the table is too wide for the window.
  (let* ((pre-indicator (string-pixel-width

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

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

> Thanks, but could you tell how that change could have affected this
> assertion violation?

I attach the patch now, sorry for not doing it earlier.

IIUC we are talking about this assertion

  eassert (frame_size_change_delayed (XFRAME (w->frame))
   || glyph_row_slice_p (window_row, frame_row));

Right?  If so, then this violation might be caused by the fact that we
(1) did resize windows according to the new sizes but (2) did not update
the frame sizes accordingly.  Which seems to match one observation that
the assertion gets violated when we increase the terminal height after
making it very small and not before.

> AFAICT, adjust_frame_glyphs is not in the
> backtrace, so how could moving code inside of it affect what happens
> here?

I don't understand what you mean here.

martin

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

[Eval EXEC]

Juri Linkov  writes:

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

 However, in `global-mode-string`, I have `mu4e`.  The tab-bar seems to
 remove the hover and mouse click actions from `global-mode-string`.
>>>
>>> Please show your `global-mode-string` with `mu4e` in it.
>>
>> I execute describe-variable global-mode-string, it's:
>>
>> global-mode-string is a variable defined in xdisp.c.
>>
>> Value
>> ((:eval (mu4e--modeline-string)) (t (:eval (lsp--progress-status)))
>>  ((t lsp-java-progress-string)) (:eval (exec/git-mode-string))
>>  (:eval (exec/gc-mode-string)) flycheck-mode-line)
>
> Also please eval these calls and show their return values.

1. (mu4e--modeline-string) :

#(" 🌀0/0 " 1 2 (help-echo "mu4e favorite bookmark 'Unread messages':
flag:unread

number of matches: 0
unread messages: 0
changes since baseline: +0
" mouse-face mode-line-highlight keymap (mode-line keymap (mouse-1 . 
mu4e-jump-to-favorite) (mouse-2 . mu4e-jump-to-favorite) (mouse-3 . 
mu4e-jump-to-favorite))) 2 3 (mouse-face mode-line-highlight keymap (mode-line 
keymap (mouse-1 . mu4e-jump-to-favorite) (mouse-2 . mu4e-jump-to-favorite) 
(mouse-3 . mu4e-jump-to-favorite)) face mu4e-header-key-face help-echo "mu4e 
favorite bookmark 'Unread messages':
flag:unread

number of matches: 0
unread messages: 0
changes since baseline: +0
") 3 4 (help-echo "mu4e favorite bookmark 'Unread messages':
flag:unread

number of matches: 0
unread messages: 0
changes since baseline: +0
" mouse-face mode-line-highlight keymap (mode-line keymap (mouse-1 . 
mu4e-jump-to-favorite) (mouse-2 . mu4e-jump-to-favorite) (mouse-3 . 
mu4e-jump-to-favorite))) 4 5 (mouse-face mode-line-highlight keymap (mode-line 
keymap (mouse-1 . mu4e-jump-to-favorite) (mouse-2 . mu4e-jump-to-favorite) 
(mouse-3 . mu4e-jump-to-favorite)) help-echo "mu4e favorite bookmark 'Unread 
messages':
flag:unread

number of matches: 0
unread messages: 0
changes since baseline: +0
") 5 6 (help-echo "mu4e favorite bookmark 'Unread messages':
flag:unread

number of matches: 0
unread messages: 0
changes since baseline: +0
" mouse-face mode-line-highlight keymap (mode-line keymap (mouse-1 . 
mu4e-jump-to-favorite) (mouse-2 . mu4e-jump-to-favorite) (mouse-3 . 
mu4e-jump-to-favorite
2. (lsp--progress-status)
;; it's empty string
3. lsp-java-progress-string
;; it's empty string too
4: (exec/git-mode-string)
it's nil
5:  (exec/gc-mode-string)
It's empty string
5. flycheck-mode-line
it's `(:eval (flycheck-status-emoji-mode-line-text))`

Addition, I eval (flycheck-status-emoji-mode-line-text) got:
(" " "😐")
-- 

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

[Krystian Samp]

Thanks,

imho it'd be also useful to add there that Emacs will make the installed
packages available automatically at startup. Now it reads that Emacs will
add them to `load-path` but I wouldn't infer from this that Emacs will also
make these packages available. And right after that we say that "... making
the above manual customizations unnecessary for such packages" which
specifically refers to loading, not only adding to `load-path`. Just two
cents,

K

On Thu, 5 Sept 2024 at 08:25, Eli Zaretskii  wrote:

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

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

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

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

Following the OP's recipe I now get

#0  terminate_due_to_signal (sig=6, backtrace_limit=40) at ../../src/emacs.c:432
#1  0x0061b51b in emacs_abort () at ../../src/sysdep.c:2391
#2  0x00541fc2 in cmcheckmagic (tty=0x1ebe0d0) at ../../src/cm.c:122
#3  0x00546564 in tty_write_glyphs (f=0x1e7bb30, string=0x1e9afe0, 
len=80) at ../../src/term.c:819
#4  0x005508c9 in write_glyphs (f=0x1e7bb30, string=0x1e9a0e0, len=80) 
at ../../src/terminal.c:164
#5  0x0042a6d7 in update_frame_line (f=0x1e7bb30, vpos=4, 
updating_menu_p=false) at ../../src/dispnew.c:5326
#6  0x004298c5 in update_frame_1 (f=0x1e7bb30, force_p=true, 
inhibit_id_p=false, set_cursor_p=true, updating_menu_p=false) at 
../../src/dispnew.c:5008
#7  0x0042514e in update_frame (f=0x1e7bb30, force_p=true, 
inhibit_hairy_id_p=false) at ../../src/dispnew.c:3346
#8  0x0047f556 in redisplay_internal () at ../../src/xdisp.c:17566
#9  0x004800c7 in redisplay_preserve_echo_area (from_where=11) at 
../../src/xdisp.c:17849
#10 0x00740b5a in wait_reading_process_output (time_limit=30, nsecs=0, 
read_kbd=-1, do_display=true, wait_for_cell=XIL(0), wait_proc=0x0, 
just_wait_proc=0) at ../../src/process.c:5583
#11 0x0042df55 in sit_for (timeout=make_fixnum(30), reading=true, 
display_option=1) at ../../src/dispnew.c:6335
#12 0x005f1523 in read_char (commandflag=1, map=XIL(0x7f59e8999aa3), 
prev_event=XIL(0), used_mouse_menu=0x7ffe2d75980f, end_time=0x0) at 
../../src/keyboard.c:2926
#13 0x00604743 in read_key_sequence (keybuf=0x7ffe2d7599c0, 
prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true, 
fix_current_buffer=true, prevent_redisplay=false, 
disable_text_conversion_p=false) at ../../src/keyboard.c:10747
#14 0x005ecddb in command_loop_1 () at ../../src/keyboard.c:1424
#15 0x006cb57b in internal_condition_case (bfun=0x5ec9ac , 
handlers=XIL(0x90), hfun=0x5ebe2e ) at ../../src/eval.c:1598
#16 0x005ec573 in command_loop_2 (handlers=XIL(0x90)) at 
../../src/keyboard.c:1163
#17 0x006ca9d1 in internal_catch (tag=XIL(0x12360), func=0x5ec549 
, arg=XIL(0x90)) at ../../src/eval.c:1277
#18 0x005ec505 in command_loop () at ../../src/keyboard.c:1141
#19 0x005eb8d0 in recursive_edit_1 () at ../../src/keyboard.c:749
#20 0x005ebafc in Frecursive_edit () at ../../src/keyboard.c:832
#21 0x005e7382 in main (argc=3, argv=0x7ffe2d759ff8) at 
../../src/emacs.c:2624

Lisp Backtrace:
"redisplay_internal (C function)" (0x0)

so the original assertion violation is gone here.

martin

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

[Eli Zaretskii]

> Date: Wed, 4 Sep 2024 12:23:28 +0100 (BST)
> From: Peter Oliver 
> 
> If my understanding of this bug is correct, newer versions of WebKitGTK 
> reliably crash Emacs, and no-one has been in touch with the WebKitGTK 
> developers, so there are no plans to fix that.
> 
> If that’s the case, how about this attached patch to disable this feature 
> with problematic versions of the library?

> * configure.ac: Accept only webkit2gtk-4.* versions less than 2.41.92.
> ---
>  configure.ac | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index 28361be4211..1d0ea314f6a 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -4511,10 +4511,11 @@ AC_DEFUN
>  if test "$with_xwidgets" != "no"; then
>if test "$USE_GTK_TOOLKIT" = "GTK3" && test "$window_system" != "none"; 
> then
>  WEBKIT_REQUIRED=2.12
> -WEBKIT_MODULES="webkit2gtk-4.1 >= $WEBKIT_REQUIRED"
> +WEBKIT_BROKEN=2.41.92
> +WEBKIT_MODULES="webkit2gtk-4.1 >= $WEBKIT_REQUIRED webkit2gtk-4.1 < 
> $WEBKIT_BROKEN"
>  EMACS_CHECK_MODULES([WEBKIT], [$WEBKIT_MODULES])
>  if test "$HAVE_WEBKIT" = "no"; then
> -  WEBKIT_MODULES="webkit2gtk-4.0 >= $WEBKIT_REQUIRED"
> +  WEBKIT_MODULES="webkit2gtk-4.0 >= $WEBKIT_REQUIRED webkit2gtk-4.0 < 
> $WEBKIT_BROKEN"
>EMACS_CHECK_MODULES([WEBKIT], [$WEBKIT_MODULES])
>  fi
>  HAVE_XWIDGETS=$HAVE_WEBKIT
> -- 
> 2.46.0
> 

Po Lu, any comments to the patch?

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

[Eli Zaretskii]

> From: "J.P." 
> Cc: 73...@debbugs.gnu.org, emacs-...@gnu.org, Eli Zaretskii 
> Date: Wed, 04 Sep 2024 23:44:02 -0700
> 
> Hi Ulrich,
> 
> Author of shoddy test here. Apologies for the annoyance.
> 
> Ulrich Mueller  writes:
> 
> > Looking at the code, the test creates three buffers, then sorts them by
> > time. Clock resolution on HPPA appears to be 4 milliseconds, so it is
> > not unlikely that the buffers end up with exactly the same timestamp and
> > sorting fails.
> 
> Makes sense to me.
> 
> > Attached patch fixes the problem. Is it OK to install it on the emacs-30
> > branch?
> 
> I guess that's up to the Emacs maintainers (Eli Cc'd).

It's okay to install these test fixes on the emacs-30 release branch.

Thanks.

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

[Eli Zaretskii]

> From: Krystian Samp 
> Date: Thu, 5 Sep 2024 09:44:14 +0200
> Cc: phil...@posteo.net, 72...@debbugs.gnu.org
> 
> Thanks,
> 
> imho it'd be also useful to add there that Emacs will make the installed 
> packages available automatically at
> startup. Now it reads that Emacs will add them to `load-path` but I wouldn't 
> infer from this that Emacs will also
> make these packages available. And right after that we say that "... making 
> the above manual customizations
> unnecessary for such packages" which specifically refers to loading, not only 
> adding to `load-path`. Just two
> cents,

All of this is already described in the node "Package Installation",
to which this node points.  Cross-references in the manual are there
for a reason: interested readers are expected to follow them and to
read what the referenced nodes say.  We don't have the same
information in more than one place in the manual because that would
make it a maintenance burden: all of those places have to be found and
updated when something changes.  Our conventions are to describe each
feature in full in a single place, and then have cross-references to
that one place in other related places.

So I decided not to expand on this more in the sections which is only
tangentially related to package installation.  This text is there so
as to avoid creating an impression that what this node describes must
be done for packages installed via package.el.  It doesn't (and should
not) pretend to describe installation via package.el.

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

[Krystian Samp]

This makes sense, thanks for taking the time to explain this in detail.

On Thu, 5 Sept 2024 at 11:10, Eli Zaretskii  wrote:

> > From: Krystian Samp 
> > Date: Thu, 5 Sep 2024 09:44:14 +0200
> > Cc: phil...@posteo.net, 72...@debbugs.gnu.org
> >
> > Thanks,
> >
> > imho it'd be also useful to add there that Emacs will make the installed
> packages available automatically at
> > startup. Now it reads that Emacs will add them to `load-path` but I
> wouldn't infer from this that Emacs will also
> > make these packages available. And right after that we say that "...
> making the above manual customizations
> > unnecessary for such packages" which specifically refers to loading, not
> only adding to `load-path`. Just two
> > cents,
>
> All of this is already described in the node "Package Installation",
> to which this node points.  Cross-references in the manual are there
> for a reason: interested readers are expected to follow them and to
> read what the referenced nodes say.  We don't have the same
> information in more than one place in the manual because that would
> make it a maintenance burden: all of those places have to be found and
> updated when something changes.  Our conventions are to describe each
> feature in full in a single place, and then have cross-references to
> that one place in other related places.
>
> So I decided not to expand on this more in the sections which is only
> tangentially related to package installation.  This text is there so
> as to avoid creating an impression that what this node describes must
> be done for packages installed via package.el.  It doesn't (and should
> not) pretend to describe installation via package.el.
>

bug#73037: 31.0.50; fullscreen tooltips break after loading pdf-tools on MacOS

[Paul Nelson]

I've tested the following setups:

(1) Emacs master, pdf-tools 1.1.0
(2) Emacs 29.4, pdf-tools 1.1.0

The issue appears with (1) but not (2), so I figured I'd report it as
a bug with Emacs rather than pdf-tools, but would welcome other
suggestions.

Steps to reproduce:

1. Install pdf-tools (e.g., via list-packages)

2. Emacs -Q

3. Evaluate the following:

(package-initialize)
(use-package pdf-tools
  :config
  (pdf-tools-install :no-query))

4. Visit any pdf file.

These steps put Emacs in a state where tooltips behave badly: when the
current frame is fullscreen (via (toggle-frame-fullscreen)), tooltips
display in a separate fullscreen frame rather than as a child frame.

All tooltips are affected, not just those produced by pdf-tools.  For
example, (x-show-tip "This is a tooltip." (selected-frame) nil 5)
triggers the issue, as does mousing over any link in *Help*.



In GNU Emacs 31.0.50 (build 4, aarch64-apple-darwin23.6.0, NS
 appkit-2487.70 Version 14.6.1 (Build 23G93)) of 2024-09-05 built on
 d51735
Repository revision: df57e44a08fd5c7dc159254a40f5d2e4d008e8df
Repository branch: master
Windowing system distributor 'Apple', version 10.3.2487
System Description:  macOS 14.6.1

Configured using:
 'configure --with-ns --with-native-compilation --with-tree-sitter
 --with-gif --with-png --with-jpeg --with-rsvg --with-tiff
 --with-imagemagick --with-x-toolkit=gtk3 --with-xwidgets'

Configured features:
ACL DBUS GLIB GNUTLS IMAGEMAGICK LCMS2 LIBXML2 MODULES NATIVE_COMP
NOTIFY KQUEUE NS PDUMPER PNG RSVG SQLITE3 THREADS TOOLKIT_SCROLL_BARS
TREE_SITTER WEBP XIM XWIDGETS ZLIB

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

Major mode: Text

Minor modes in effect:
  pdf-occur-global-minor-mode: t
  repeat-mode: t
  override-global-mode: t
  recentf-mode: t
  display-time-mode: t
  save-place-mode: t
  global-auto-revert-mode: t
  minibuffer-depth-indicate-mode: t
  electric-pair-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  tab-bar-history-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
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
/Users/au710211/.emacs.d/elpa/lispy-20230314.1738/elpa hides
/Users/au710211/.emacs.d/elpa/ivy-20240405.2019/elpa
/Users/au710211/.emacs.d/elpa/editorconfig-20240318.2049/editorconfig
hides 
/Users/au710211/gnu-emacs/nextstep/Emacs.app/Contents/Resources/lisp/editorconfig
/Users/au710211/.emacs.d/elpa/which-key-20240423.1320/which-key hides
/Users/au710211/gnu-emacs/nextstep/Emacs.app/Contents/Resources/lisp/which-key
/Users/au710211/.emacs.d/elpa/editorconfig-20240318.2049/editorconfig-core
hides 
/Users/au710211/gnu-emacs/nextstep/Emacs.app/Contents/Resources/lisp/editorconfig-core
/Users/au710211/.emacs.d/elpa/editorconfig-20240318.2049/editorconfig-conf-mode
hides 
/Users/au710211/gnu-emacs/nextstep/Emacs.app/Contents/Resources/lisp/editorconfig-conf-mode
/Users/au710211/.emacs.d/elpa/ef-themes-1.7.0/theme-loaddefs hides
/Users/au710211/gnu-emacs/nextstep/Emacs.app/Contents/Resources/lisp/theme-loaddefs
/Users/au710211/.emacs.d/elpa/transient-20240421.1737/transient hides
/Users/au710211/gnu-emacs/nextstep/Emacs.app/Contents/Resources/lisp/transient
/Users/au710211/.emacs.d/elpa/editorconfig-20240318.2049/editorconfig-core-handle
hides 
/Users/au710211/gnu-emacs/nextstep/Emacs.app/Contents/Resources/lisp/editorconfig-core-handle
/Users/au710211/.emacs.d/elpa/editorconfig-20240318.2049/editorconfig-fnmatch
hides 
/Users/au710211/gnu-emacs/nextstep/Emacs.app/Contents/Resources/lisp/editorconfig-fnmatch

Features:
(shadow sort mail-extr emacsbug magit-base magit-section cursor-sensor
crm dash compat etags fileloop generator xref shortdoc help-fns
radix-tree mm-archive misearch multi-isearch package-vc lisp-mnt
network-stream url-cache url-http url-auth url-gw nsm
display-line-numbers add-log vc-hg vc-git diff-mode track-changes vc-bzr
vc-src vc-sccs vc-svn vc-cvs vc-rcs log-view pcvs-util vc vc-dispatcher
dired-aux ol-eww eww xdg url-queue mm-url ol-rmail ol-mhe ol-irc ol-info
ol-gnus nnselect gnus-art mm-uu mml2015 mm-view mml-smime smime gnutls
dig gnus-sum shr pixel-fill kinsoku url-file svg dom gnus-group
gnus-undo gnus-start gnus-dbus dbus xml gnus-cloud nnimap nnmail
mail-source utf7 nnoo parse-time gnus-spec gnus-int gnus-range message
sendmail yank-media puny rfc822 mml mml-sec epa derived epg rfc6068
epg-config mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047
rfc2045 ietf-drums mailabbrev gmm-utils mailheader gnus-win gnus
nnheader gnus-util mail-utils range mm-util mail-prsvr ol-docview
ol-bibtex bibtex iso8601 ol-bbdb ol-w3m ol-doi org-link-doi org-capture
org-refile pdf-sync pdf-ann

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

[Philip Kaludercic]

Sean Whitton  writes:

> Hello,
>
> On Tue 03 Sep 2024 at 04:32pm GMT, Philip Kaludercic wrote:
>
>>
>> +(defcustom kill-region-dwim nil
>> +  "Behaviour when `kill-region' is invoked without an active region.
>> +If set to nil (default), then an error occurs and nothing is killed.  If
>> +set to `emacs-word', then kill a the last word as defined by the current
>> +major mode.  If set to `unix-word', then kill the last word in the style
>> +of a shell like Bash, disregarding the major mode."
>> +  :type '(choice (const :tag "Kill a word like `backward-kill-word'" 
>> emacs-word)
>> + (const :tag "Kill a word like Bash would" unix-word)
>> + (const :tag "Do not kill anything" nil))
>> +  :group 'killing)
>
> I think I'm missing something here.  When it's nil and there is no
> *active* region, but there is a region, it should kill that, surely?
> With or without TMM.
> I very regularly kill inactive regions (e.g. after M->).

That is not an inherent problem, we can adjust the patch by

diff --git a/lisp/simple.el b/lisp/simple.el
index 3b4453c7a8f..9d4d5bcd10c 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -5865,11 +5865,11 @@ kill-region
  (let ((beg (mark))
(end (point)))
(cond
-((and beg end (use-region-p))
- (list beg end 'region))
-(kill-region-dwim
+((and kill-region-dwim (not (use-region-p)))
  (list beg end kill-region-dwim))
-((user-error "The mark is not set now, so there is no 
region"))
+((not (or beg end))
+ (user-error "The mark is not set now, so there is no 
region"))
+((list beg end 'region))
 
   (condition-case nil
   (let ((string (cond

to fix that issue.

>> + ((eq region 'unix-word)
>> +  (let ((end (point)))
>> +(save-excursion
>> +  (skip-chars-backward "[:space:]")
>> +  (skip-chars-backward "^[:space:]")
>> +  (filter-buffer-substring
>> +   (if (get-char-property (point) 'read-only)
>> +   (next-single-char-property-change
>> +(point) 'read-only nil end)
>> + (point))
>> +   end 'delete
>> + (region
>> +  (funcall region-extract-function 'delete))
>> + ((filter-buffer-substring beg end 'delete)
>
> Shall I rather commit this as an independent unix-word-rubout?
>
> Improves attribution, and it's independently useful.

As a standalone command?

Eli Zaretskii  writes:

>> From: Sean Whitton 
>> Cc: Eli Zaretskii ,  stefankan...@gmail.com,
>>   acora...@gnu.org,  j...@linkov.net,  r...@gnu.org,  69...@debbugs.gnu.org
>> Date: Wed, 04 Sep 2024 15:07:08 +0100
>> 
>> > +(defcustom kill-region-dwim nil
>> > +  "Behaviour when `kill-region' is invoked without an active region.
>> > +If set to nil (default), then an error occurs and nothing is killed.  If
>> > +set to `emacs-word', then kill a the last word as defined by the current
>> > +major mode.  If set to `unix-word', then kill the last word in the style
>> > +of a shell like Bash, disregarding the major mode."
>> > +  :type '(choice (const :tag "Kill a word like `backward-kill-word'" 
>> > emacs-word)
>> > + (const :tag "Kill a word like Bash would" unix-word)
>> > + (const :tag "Do not kill anything" nil))
>> > +  :group 'killing)
>> 
>> I think I'm missing something here.  When it's nil and there is no
>> *active* region, but there is a region, it should kill that, surely?
>> With or without TMM.
>
> Yes, you are right.  It sounds like we made wrong assumptions about
> what happens in that case, and should rethink this.
>
> C-w signals an error only if there's no mark in the buffer.
>
> So I guess we need a new command after all.

Not necessarily (unless I am mistaken above), but I am not opposed to it either.

-- 
Philip Kaludercic on siskin

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

[Philip Kaludercic]

Jeremy Bryant  writes:

> Hi,
>
> kmonad is a keyboard configuration tool under MIT license.
> https://github.com/kmonad/kmonad
>
> There is an Emacs major mode to edit the configuration file, based on
> s-expressions.  The mode is under GPLv3.
> https://github.com/kmonad/kbd-mode

I don't see a reason to add the package in principle.

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

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

> Furthermore if there are any code reviews or recommendations, I attach
> the current version.
>
> I can volunteer some time for some of the changes.
>
> ;;; kbd-mode.el --- Font locking for kmonad's .kbd files -*- lexical-binding: 
> t -*-
>
> ;; Copyright 2020–2022  slotThe
> ;; URL: https://github.com/kmonad/kbd-mode
> ;; Version: 0.0.1
> ;; Package-Requires: ((emacs "24.3"))
>
> ;; This file is free software; you can redistribute it and/or modify
> ;; it under the terms of the GNU General Public License as published by
> ;; the Free Software Foundation; either version 3, or (at your option)
> ;; any later version.
> ;;
> ;; This file is distributed in the hope that it will be useful,
> ;; but WITHOUT ANY WARRANTY; without even the implied warranty of
> ;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> ;; GNU General Public License for more details.
> ;;
> ;; You should have received a copy of the GNU General Public License
> ;; along with this program.  If not, see .
>
> ;;; Commentary:
>
> ;; This file adds basic font locking support for `.kbd' configuration
> ;; files.
> ;;
> ;; To use this file, move it to a directory within your `load-path' and
> ;; require it.  For example --- assuming that this file was placed
> ;; within the `~/.config/emacs/elisp' directory:
> ;;
> ;; (add-to-list 'load-path "~/.config/emacs/elisp/")
> ;; (require 'kbd-mode)
> ;;
> ;; If you use `use-package', you can express the above as
> ;;
> ;; (use-package kbd-mode
> ;;   :load-path "~/.config/emacs/elisp/")

Installation instructions are usually out-of-place in the commentary
section.  Perhaps add a `;;; Installation:` section instead, so that we
keep it apart from the documentation that describe-package displays?

> ;;
> ;; By default we highlight all keywords; you can change this by
> ;; customizing the `kbd-mode-' variables.  For example, to disable the
> ;; highlighting of already defined macros (i.e. of "@macro-name"), you
> ;; can set `kbd-mode-show-macros' to `nil'.
> ;;
> ;; For keybindings, as well as commentary on the `kbd-mode-demo-mode'
> ;; minor mode, see the associated README.md file.
>
> ;;; Code:
>
> (require 'compile)
>
> (defgroup kbd nil
>   "Major mode for editing `.kbd' files."
>   :group 'languages)
>
> (defgroup kbd-demo nil
>   "A minor mode to test your configuration."
>   :group 'kbd)
>
>  Custom variables
>
> (defgroup kbd-highlight nil
>   "Syntax highlighting for `kbd-mode'."
>   :group 'kbd)
>
> (defcustom kbd-mode-kexpr
>   '("defcfg" "defsrc" "defalias")
>   "A K-Expression."

This documentation should be expanded on.

>   :type '(repeat string)
>   :group 'kbd-highlight)

Where is this group defined?  The applies below.
>
> ;; HACK
> (defcustom kbd-mode-function-one
>   '("deflayer")
>   "Tokens that are treated as functions with one argument."
>   :type '(repeat string)
>   :group 'kbd-highlight)
>
> (defcustom kbd-mode-tokens
>   '(;; input tokens
> "uinput-sink" "send-event-sink" "kext"
> ;; output tokens
> "device-file" "low-level-hook" "iokit-name")
>   "Input and output tokens."
>   :type '(repeat string)
>   :group 'kbd-highlight)
>
> (defcustom kbd-mode-defcfg-options
>   '("input" "output" "cmp-seq-delay" "cmp-seq" "init" "fallthrough" 
> "allow-cmd")
>   "Options to give to `defcfg'."
>   :type '(repeat string)
>   :group 'kbd-highlight)
>
> (defcustom kbd-mode-button-modifiers
>   '("around-next-timeout" "around-next-single" "around-next" "around"
> "tap-hold-next-release" "tap-hold-next" "tap-next-release" "tap-hold"
> "tap-macro-release" "tap-macro" "multi-tap" "tap-next" "layer-toggle"
> "layer-switch" "layer-add" "layer-rem" "layer-delay" "layer-next" 
> "cmd-button")
>   "Button modifiers."
>   :type '(repeat string)
>   :group 'kbd-highlight)
>
> (defcustom kbd-mode-show-string
>   '("uinput-sink" "device-file" "cmd-button")
>   "Syntax highlight strings in S-expressions.
> When an S-expression begins with any of these keywords, highlight
> strings (deli

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

[Eli Zaretskii]

> From: Philip Kaludercic 
> Cc: Eli Zaretskii ,  stefankan...@gmail.com,
>   acora...@gnu.org,  j...@linkov.net,  r...@gnu.org,  69...@debbugs.gnu.org
> Date: Thu, 05 Sep 2024 09:39:32 +
> 
> >> I think I'm missing something here.  When it's nil and there is no
> >> *active* region, but there is a region, it should kill that, surely?
> >> With or without TMM.
> >
> > Yes, you are right.  It sounds like we made wrong assumptions about
> > what happens in that case, and should rethink this.
> >
> > C-w signals an error only if there's no mark in the buffer.
> >
> > So I guess we need a new command after all.
> 
> Not necessarily (unless I am mistaken above), but I am not opposed to it 
> either.

If we don't introduce a new command, then what will be the modified
behavior of kill-region?  Specifically, when will it delete the last
word?  In Emacs buffers, it is very rare not to have the mark, so it
sounds like the Bash-like behavior will very rarely if ever available,
no?

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

[Eli Zaretskii]

> Date: Thu, 5 Sep 2024 10:18:35 +0200
> Cc: n142...@gmail.com, 73...@debbugs.gnu.org
> From: martin rudalics 
> 
>  > Thanks, but could you tell how that change could have affected this
>  > assertion violation?
> 
> I attach the patch now, sorry for not doing it earlier.

You didn't attach it, but I think I understood what you wanted to
change, and did that by hand.

> IIUC we are talking about this assertion
> 
> eassert (frame_size_change_delayed (XFRAME (w->frame))
>  || glyph_row_slice_p (window_row, frame_row));
> 
> Right?

Yes.

> If so, then this violation might be caused by the fact that we
> (1) did resize windows according to the new sizes but (2) did not update
> the frame sizes accordingly.

Can you elaborate on how this could be possible?  I always thought we
first allocate the frame matrices, and then the window matrices (by
suballocating them from the frame matrices).  Am I mistaken?

>  > AFAICT, adjust_frame_glyphs is not in the
>  > backtrace, so how could moving code inside of it affect what happens
>  > here?
> 
> I don't understand what you mean here.

Moving code in adjust_frame_glyphs could affect the assertion if the
assertion was being hit while adjust_frame_glyphs is still being
executed.  But that is not the case, so I don't understand how moving
some code in adjust_frame_glyphs without changing it could affect the
assertion violation.  I'm probably missing something.

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

[Eli Zaretskii]

> Date: Thu, 5 Sep 2024 10:18:52 +0200
> Cc: n142...@gmail.com, 73...@debbugs.gnu.org
> From: martin rudalics 
> 
>  > In any case, I can cause the assertion violation even after making the
>  > change you suggested above.
> 
> Following the OP's recipe I now get
> 
> #0  terminate_due_to_signal (sig=6, backtrace_limit=40) at 
> ../../src/emacs.c:432
> #1  0x0061b51b in emacs_abort () at ../../src/sysdep.c:2391
> #2  0x00541fc2 in cmcheckmagic (tty=0x1ebe0d0) at ../../src/cm.c:122
> #3  0x00546564 in tty_write_glyphs (f=0x1e7bb30, string=0x1e9afe0, 
> len=80) at ../../src/term.c:819
> #4  0x005508c9 in write_glyphs (f=0x1e7bb30, string=0x1e9a0e0, 
> len=80) at ../../src/terminal.c:164

Are you running the latest codebase?  The assertions in cmcheckmagic
are supposed to be fixed there.

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

[Philip Kaludercic]

Eli Zaretskii  writes:

>> From: Philip Kaludercic 
>> Cc: Eli Zaretskii ,  stefankan...@gmail.com,
>>   acora...@gnu.org,  j...@linkov.net,  r...@gnu.org,  69...@debbugs.gnu.org
>> Date: Thu, 05 Sep 2024 09:39:32 +
>> 
>> >> I think I'm missing something here.  When it's nil and there is no
>> >> *active* region, but there is a region, it should kill that, surely?
>> >> With or without TMM.
>> >
>> > Yes, you are right.  It sounds like we made wrong assumptions about
>> > what happens in that case, and should rethink this.
>> >
>> > C-w signals an error only if there's no mark in the buffer.
>> >
>> > So I guess we need a new command after all.
>> 
>> Not necessarily (unless I am mistaken above), but I am not opposed to it 
>> either.
>
> If we don't introduce a new command, then what will be the modified
> behavior of kill-region?  Specifically, when will it delete the last
> word?  

If the new user option is non-nil /and/ there is no region.  If
`kill-region-dwim' is nil (default), then nothing should change.

>
>In Emacs buffers, it is very rare not to have the mark, so it
> sounds like the Bash-like behavior will very rarely if ever available,
> no?

It will kick-in whenever `use-region-p' returns a non-nil value.  I
recognise that this isn't useful for people who don't rely on transient
mark mode, but in that case we'll need to commands anyway, as I don't
want to use the behaviour that Sean describes.

-- 
Philip Kaludercic on siskin

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

[Eli Zaretskii]

> From: Philip Kaludercic 
> Cc: spwhit...@spwhitton.name,  stefankan...@gmail.com,  acora...@gnu.org,
>   j...@linkov.net,  r...@gnu.org,  69...@debbugs.gnu.org
> Date: Thu, 05 Sep 2024 10:02:45 +
> 
> Eli Zaretskii  writes:
> 
> > If we don't introduce a new command, then what will be the modified
> > behavior of kill-region?  Specifically, when will it delete the last
> > word?  
> 
> If the new user option is non-nil /and/ there is no region.  If
> `kill-region-dwim' is nil (default), then nothing should change.
> 
> >
> >In Emacs buffers, it is very rare not to have the mark, so it
> > sounds like the Bash-like behavior will very rarely if ever available,
> > no?
> 
> It will kick-in whenever `use-region-p' returns a non-nil value.

Non-nil or nil?  Above you say "there's no region", which AFAIU means
use-region-p returns nil.

> I recognise that this isn't useful for people who don't rely on
> transient mark mode, but in that case we'll need to commands anyway,
> as I don't want to use the behaviour that Sean describes.

Which is why I think we will need a separate command after all.

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

[Philip Kaludercic]

Eli Zaretskii  writes:

>> From: Philip Kaludercic 
>> Cc: spwhit...@spwhitton.name,  stefankan...@gmail.com,  acora...@gnu.org,
>>   j...@linkov.net,  r...@gnu.org,  69...@debbugs.gnu.org
>> Date: Thu, 05 Sep 2024 10:02:45 +
>> 
>> Eli Zaretskii  writes:
>> 
>> > If we don't introduce a new command, then what will be the modified
>> > behavior of kill-region?  Specifically, when will it delete the last
>> > word?  
>> 
>> If the new user option is non-nil /and/ there is no region.  If
>> `kill-region-dwim' is nil (default), then nothing should change.
>> 
>> >
>> >In Emacs buffers, it is very rare not to have the mark, so it
>> > sounds like the Bash-like behavior will very rarely if ever available,
>> > no?
>> 
>> It will kick-in whenever `use-region-p' returns a non-nil value.
>
> Non-nil or nil?  Above you say "there's no region", which AFAIU means
> use-region-p returns nil.

Right, my bad.

>> I recognise that this isn't useful for people who don't rely on
>> transient mark mode, but in that case we'll need to commands anyway,
>> as I don't want to use the behaviour that Sean describes.
>
> Which is why I think we will need a separate command after all.

OK, but we can add that independently of this patch.

-- 
Philip Kaludercic on siskin

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

[Philip Kaludercic]

Manuel Giraud  writes:

> Tags: patch
>
> Hi,
>
> Here is a patch to make `dired-do-open' work on some non GNU/Linux
> systems.  I have tested it on OpenBSD with "xdg-open" installed.
>
> Thanks,
>
> In GNU Emacs 31.0.50 (build 19, x86_64-unknown-openbsd7.6) of 2024-09-02
>  built on computer
> Repository revision: 92ea393a16e5c99a8860dab368c6ca3ca6abc3c5
> Repository branch: master
> Windowing system distributor 'The X.Org Foundation', version 11.0.12101013
> System Description: OpenBSD computer 7.6 GENERIC.MP#294 amd64
>
> Configured using:
>  'configure CC=egcc CPPFLAGS=-I/usr/local/include
>  LDFLAGS=-L/usr/local/lib MAKEINFO=gmakeinfo --prefix=/home/manuel/emacs
>  --bindir=/home/manuel/bin --with-x-toolkit=no --without-cairo
>  --without-compress-install'
>
>>From ab26a89395b5745c8e3d87a8907344ba774a5ca1 Mon Sep 17 00:00:00 2001
> From: Manuel Giraud 
> Date: Tue, 3 Sep 2024 15:13:51 +0200
> Subject: [PATCH] Make `dired-do-open' work on non GNU/Linux systems
>
> * lisp/dired-aux.el (dired-do-open): Permit this function to
> work on some non GNU/Linux systems.
> ---
>  lisp/dired-aux.el | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lisp/dired-aux.el b/lisp/dired-aux.el
> index cd948bd7dd9..97b1e28a4ff 100644
> --- a/lisp/dired-aux.el
> +++ b/lisp/dired-aux.el
> @@ -1472,7 +1472,7 @@ dired-do-open
>  (when command
>(dolist (file files)
>  (cond
> - ((memq system-type '(gnu/linux))
> + ((memq system-type '(gnu/linux berkeley-unix))

Are these the only systems with xdg-open?  And is xdg-open reliably
available on BSD systems, so that we don't generate an opaque error
message if that is not the case?

>(call-process command nil 0 nil file))
>   ((memq system-type '(ms-dos))
>(shell-command (concat command " " (shell-quote-argument file
> -- 
> 2.46.0

-- 
Philip Kaludercic on siskin

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:

> So you prefer to slow down only when the user types C-s?
> This is possible by adding a local hook in
> wdired-change-to-wdired-mode:
>
>   (add-hook 'isearch-mode-hook #'font-lock-ensure nil t)

A step back: I now tried to reproduce the recipe, but I only see the
clobbered match data error (randomly) - I don't see only the visible
buffer portion operated on.  With other words: I can't reproduce the
issue, at least not with the "visible buffer portion" interpretation,
and I don't see that we would need to call `font-lock-ensure' at all.

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.


Michael.

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

[Sean Whitton]

Hello,

On Thu 05 Sep 2024 at 09:39am GMT, Philip Kaludercic wrote:

>>> + ((eq region 'unix-word)
>>> +  (let ((end (point)))
>>> +(save-excursion
>>> +  (skip-chars-backward "[:space:]")
>>> +  (skip-chars-backward "^[:space:]")
>>> +  (filter-buffer-substring
>>> +   (if (get-char-property (point) 'read-only)
>>> +   (next-single-char-property-change
>>> +(point) 'read-only nil end)
>>> + (point))
>>> +   end 'delete
>>> + (region
>>> +  (funcall region-extract-function 'delete))
>>> + ((filter-buffer-substring beg end 'delete)
>>
>> Shall I rather commit this as an independent unix-word-rubout?
>>
>> Improves attribution, and it's independently useful.
>
> As a standalone command?

I mean, yeah, I have had it on my C-w for years.  Probably some other
people have implementations too.

-- 
Sean Whitton

bug#73041: 30.0.90; track-changes-mode logs warnings (#70541 regression? not actually fixed?)

[epg]

I wish I could describe exactly what happened.  I found
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=70541 which sounds
very much like what I'm seeing, but I don't use any input method.

What I can say:

- I use rust-mode (not rust-ts-mode)
- I use eglot (config below)
- I use rust-analyzer 1.80.1 (3f5fd8d 2024-08-06)
- The problem seems to happen deep into a work day, after many
  commits, reverts, etc.

My eglot configuration:

#+begin_src elisp
  (setq
   eglot-extend-to-xref t
   eglot-ignored-server-capabilities
   '(
 :inlayHintProvider
 :documentOnTypeFormattingProvider
 )
   )
#+end_src

Eventually, this pops into *Messages*:

#+begin_quote
cl--assertion-failed: Assertion failed: (or track-changes--before-no (<= 
track-changes--before-beg (track-changes--state-beg track-changes--state) beg 
end (track-changes--state-end track-changes--state) track-changes--before-end))
#+end_quote

And this in *Warnings*:

#+begin_quote
⛔ Warning (emacs): Missing/incorrect calls to ‘before/after-change-functions’!!
Details logged to ‘track-changes--error-log’
#+end_quote

Over time, they just keep repeating, although I think killing the
buffer and reopening the file makes it stop.

If I have inspected ‘track-changes--error-log’ correctly, this is
what it contains (looks like some binary, hope it comes through
in some useful fashion or another):

#+begin_quote
(("lib.rs" (buffer-size 5254 5218) ((t track-changes--recover-from-error ... 
nil) (t track-changes-fetch ... nil) (t eglot--track-changes-fetch ... nil) (t 
eglot--signal-textDocument/didChange nil nil) (t 
eglot--signal-textDocument/didSave nil nil) (t run-hooks ... nil) (t 
basic-save-buffer ... nil) (t save-buffer ... nil) (t funcall-interactively ... 
nil) (t call-interactively ... nil) (t command-execute ... nil)) [111 (nil . 
other-window) 103 (nil . recompile) 121 (nil . undefined) 24 96 (nil . 
next-error) 1 (nil . move-beginning-of-line) 11 ...]) ("lib.rs" (buffer-size 
5256 5254) ((t track-changes--recover-from-error ... nil) (t 
track-changes-fetch ... nil) (t eglot--track-changes-fetch ... nil) (t 
eglot--signal-textDocument/didChange nil nil) (t 
eglot--signal-textDocument/didSave nil nil) (t run-hooks ... nil) (t 
basic-save-buffer ... nil) (t save-buffer nil nil) (t #[257 "r\211q\210\300 
)\207" [save-buffer] 2 ...] ... nil) (t map-y-or-n-p ... nil) (t 
save-some-buffers ... nil) (t recompile ... nil) ...) [19 (nil . save-buffer) 
24 24 (nil . exchange-point-and-mark) 23 (nil . kill-region) 24 19 (nil . 
save-buffer) backspace (nil . delete-backward-char) ...]) ("lib.rs" 
(buffer-size 5278 5256) ((t track-changes--recover-from-error ... nil) (t 
track-changes-fetch ... nil) (t eglot--track-changes-fetch ... nil) (t 
eglot--signal-textDocument/didChange nil nil) (t 
eglot--signal-textDocument/didSave nil nil) (t run-hooks ... nil) (t 
basic-save-buffer ... nil) (t save-buffer ... nil) (t funcall-interactively ... 
nil) (t call-interactively ... nil) (t command-execute ... nil)) [(nil . 
backward-word) 2 (nil . backward-char) 67108896 (nil . set-mark-command) 
134217734 (nil . forward-sexp) 23 (nil . kill-region) 24 19 (nil . save-buffer) 
...]) ("lib.rs" (buffer-size 5324 5278) ((t track-changes--recover-from-error 
... nil) (t track-changes-fetch ... nil) (t eglot--track-changes-fetch ... nil) 
(t eglot--track-changes-signal ... nil) (t #[771 "\211^BZ\211^HG^E]
#+end_quote

I wish I could reliably repeat it.  Given that it occurs after
many hours of work, `emacs -Q` isn't an option.

Thanks!




In GNU Emacs 30.0.90 (build 9, x86_64-pc-linux-gnu, cairo version
 1.18.0) of 2024-09-03 built on dogato
Repository revision: ae2463796f236b8ee2cef3b5e38bffa13abd2233
Repository branch: emacs-30
Windowing system distributor 'The X.Org Foundation', version 11.0.12101012
System Description: openSUSE Tumbleweed

Configured using:
 'configure -C --prefix=/opt/emacs-30.0.90.5.ae2463796f2
 --disable-silent-rules --with-x-toolkit=no --without-gsettings
 --with-native-compilation=no'

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

Important settings:
  value of $LC_CTYPE: en_US.UTF-8
  value of $XMODIFIERS: @im=local
  locale-coding-system: utf-8-unix

Major mode: ELisp/d

Minor modes in effect:
  server-mode: t
  editorconfig-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  minibuffer-regexp-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr tabify cus-edit cus-start cus-load
cl-print help-fns radix-tree mh-utils emacsbug conf-mode
smerge-mode whitespace time-stamp perl-mode bu

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]

Philip Kaludercic  writes:

[...]

>> diff --git a/lisp/dired-aux.el b/lisp/dired-aux.el
>> index cd948bd7dd9..97b1e28a4ff 100644
>> --- a/lisp/dired-aux.el
>> +++ b/lisp/dired-aux.el
>> @@ -1472,7 +1472,7 @@ dired-do-open
>>  (when command
>>(dolist (file files)
>>  (cond
>> - ((memq system-type '(gnu/linux))
>> + ((memq system-type '(gnu/linux berkeley-unix))
>
> Are these the only systems with xdg-open?

I don't really know.  I guess that FreeBSD and NetBSD also have ports of
xdg-open.  But I don't know for others "berkeley-unix".  Anyway, this is
less restrictive than just "gnu/linux".

> And is xdg-open reliably available on BSD systems, so that we don't
> generate an opaque error message if that is not the case?

I think it would work whether xdg-open is install or not because
`shell-command-guess-open' is defined by testing the presence of
xdg-open.  So if xdg-open is not installed, `command' in the code above
will be nil and nothing will happen.
-- 
Manuel Giraud

bug#73042: 29.1; Regression: negation missing in ediff-nonempty-string-p

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

Hi,
In emacs 29.1-29.4 the negation is missing in function
ediff-nonempty-string-p, see ediff-init.el:

  (defsubst ediff-nonempty-string-p (string)
(and (stringp string) (string-empty-p string)))

should be

  (defsubst ediff-nonempty-string-p (string)
(and (stringp string) (not (string-empty-p string



In GNU Emacs 29.1 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.22.30,
 cairo version 1.15.12) of 2024-08-04 built on dhdevd15
Windowing system distributor 'TigerVNC', version 11.0.12013000
System Description: Red Hat Enterprise Linux 8.8 (Ootpa)

Configured using:
 'configure
 --prefix=/cm/ot/TOOL/GNU!28.0.0.97/build_G!30.IP.L8/generated
 
--exec-prefix=/cm/ot/TOOL/GNU!28.0.0.97/build_G!30.IP.L8/generated/libexec/emacs-29.1
 --mandir=/cm/ot/TOOL/GNU!28.0.0.97/build_G!30.IP.L8/generated/man
 --with-x-toolkit=gtk3 --with-modules --without-gconf
 --without-gsettings --without-dbus --with-xft --with-gif=yes
 --with-gnutls=no --enable-link-time-optimization
 'CFLAGS=-I/cm/ot/TOOL/GNU!28.0.0.97/build_G!30.IP.L8/generated/include
 ' LDFLAGS=-L/cm/ot/TOOL/GNU!28.0.0.97/build_G!30.IP.L8/generated/lib'

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

Important settings:
  value of $EMACSDATA: 
/cm/ot/TOOL/GNU.28.0.0.97/build_G.30.IP.L8/generated/share/emacs/29.1/etc
  value of $EMACSDOC: 
/cm/ot/TOOL/GNU.28.0.0.97/build_G.30.IP.L8/generated/share/emacs/29.1/etc
  value of $EMACSLOADPATH: 
/cm/ot/TOOL/GNU.28.0.0.97/build_G.30.IP.L8/generated/share/emacs/29.1/site-lisp:/cm/ot/TOOL/GNU.28.0.0.97/build_G.30.IP.L8/generated/share/emacs/site-lisp:/cm/ot/TOOL/GNU.28.0.0.97/build_G.30.IP.L8/generated/share/emacs/29.1/lisp
  value of $EMACSPATH: 
/cm/ot/TOOL/GNU.28.0.0.97/build_G.30.IP.L8/generated/libexec/emacs-29.1/libexec/emacs/29.1/x86_64-pc-linux-gnu:
  value of $LANG: C
  locale-coding-system: nil

Major mode: ELisp/l

Minor modes in effect:
  hi-lock-mode: t
  shell-dirtrack-mode: t
  global-display-line-numbers-mode: t
  display-line-numbers-mode: t
  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
  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

Load-path shadows:
/cm/ot/TOOL/GNU.28.0.0.97/build_G.30.IP.L8/generated/share/emacs/29.1/site-lisp/sh-script
 hides 
/cm/ot/TOOL/GNU.28.0.0.97/build_G.30.IP.L8/generated/share/emacs/29.1/lisp/progmodes/sh-script
/cm/ot/TOOL/GNU.28.0.0.97/build_G.30.IP.L8/generated/share/emacs/29.1/site-lisp/org-9.3.1/ob-scheme
 hides 
/cm/ot/TOOL/GNU.28.0.0.97/build_G.30.IP.L8/generated/share/emacs/29.1/lisp/org/ob-scheme
/cm/ot/TOOL/GNU.28.0.0.97/build_G.30.IP.L8/generated/share/emacs/29.1/site-lisp/org-9.3.1/org-clock
 hides 
/cm/ot/TOOL/GNU.28.0.0.97/build_G.30.IP.L8/generated/share/emacs/29.1/lisp/org/org-clock
/cm/ot/TOOL/GNU.28.0.0.97/build_G.30.IP.L8/generated/share/emacs/29.1/site-lisp/org-9.3.1/org-macro
 hides 
/cm/ot/TOOL/GNU.28.0.0.97/build_G.30.IP.L8/generated/share/emacs/29.1/lisp/org/org-macro
/cm/ot/TOOL/GNU.28.0.0.97/build_G.30.IP.L8/generated/share/emacs/29.1/site-lisp/org-9.3.1/ob-lilypond
 hides 
/cm/ot/TOOL/GNU.28.0.0.97/build_G.30.IP.L8/generated/share/emacs/29.1/lisp/org/ob-lilypond
/cm/ot/TOOL/GNU.28.0.0.97/build_G.30.IP.L8/generated/share/emacs/29.1/site-lisp/org-9.3.1/ol-bbdb
 hides 
/cm/ot/TOOL/GNU.28.0.0.97/build_G.30.IP.L8/generated/share/emacs/29.1/lisp/org/ol-bbdb
/cm/ot/TOOL/GNU.28.0.0.97/build_G.30.IP.L8/generated/share/emacs/29.1/site-lisp/org-9.3.1/ol-irc
 hides 
/cm/ot/TOOL/GNU.28.0.0.97/build_G.30.IP.L8/generated/share/emacs/29.1/lisp/org/ol-irc
/cm/ot/TOOL/GNU.28.0.0.97/build_G.30.IP.L8/generated/share/emacs/29.1/site-lisp/org-9.3.1/ob-ocaml
 hides 
/cm/ot/TOOL/GNU.28.0.0.97/build_G.30.IP.L8/generated/share/emacs/29.1/lisp/org/ob-ocaml
/cm/ot/TOOL/GNU.28.0.0.97/build_G.30.IP.L8/generated/share/emacs/29.1/site-lisp/org-9.3.1/ob-C
 hides 
/cm/ot/TOOL/GNU.28.0.0.97/build_G.30.IP.L8/generated/share/emacs/29.1/lisp/org/ob-C
/cm/ot/TOOL/GNU.28.0.0.97/build_G.30.IP.L8/generated/share/emacs/29.1/site-lisp/org-9.3.1/org-footnote
 hides 
/cm/ot/TOOL/GNU.28.0.0.97/build_G.30.IP.L8/generated/share/emacs/29.1/lisp/org/org-footnote
/cm/ot/TOOL/GNU.28.0.0.97/build_G.30.IP.L8/generated/share/emacs/29.1/site-lisp/org-9.3.1/ob-groovy
 hides 
/cm/ot/TOOL/GNU.28.0.0.97/build_G.30.IP.L8/generated/share/emacs/29.1/lisp/org/ob-groovy
/cm/ot/TOOL/GNU.28.0.0.97/build_G.30.IP.L8/generated/share/emacs/29.1/site-lisp/org-9.3.1/ob-calc
 hides 
/cm/ot/TOOL/GNU.28.0.0.97/build_G.30.IP.L8/generated/share/emacs/29.1/lisp/org/ob-calc
/cm/ot/TOOL/GNU.28.0.0.97/build_G.30.IP.L8/generated/sha

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

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

Tags: patch


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.

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

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

>From 960e5fc3486aa56d42c8c90fae025fe51c4cd7ad Mon Sep 17 00:00:00 2001
From: Spencer Baugh 
Date: Thu, 5 Sep 2024 09:56:50 -0400
Subject: [PATCH] Add project-find-file-in-root

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.

* lisp/progmodes/project.el (project-find-file-in-root): Add.
---
 lisp/progmodes/project.el | 12 
 1 file changed, 12 insertions(+)

diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
index 983242628f0..cfb81e5425c 100644
--- a/lisp/progmodes/project.el
+++ b/lisp/progmodes/project.el
@@ -1069,6 +1069,18 @@ project--find-default-from
   (file-relative-name filename (project-root filename-proj)))
 filename))
 
+;;;###autoload
+(defun project-find-file-in-root ()
+  "Call `find-file' in the current project root.
+
+Unlike `project-find-file', this doesn't provide completion over the
+entire file tree.
+
+This is equivalent to running `project-any-command' with `find-file'."
+  (let* ((pr (project-current t))
+ (default-directory (project-root pr)))
+(call-interactively #'find-file)))
+
 ;;;###autoload
 (defun project-find-file (&optional include-all)
   "Visit a file (with completion) in the current project.
-- 
2.39.3

bug#73041: 30.0.90; track-changes-mode logs warnings (#70541 regression? not actually fixed?)

[Eli Zaretskii]

> From: e...@pretzelnet.org
> Date: Thu, 05 Sep 2024 08:28:53 -0500
> 
> I wish I could describe exactly what happened.  I found
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=70541 which sounds
> very much like what I'm seeing, but I don't use any input method.
> 
> What I can say:
> 
> - I use rust-mode (not rust-ts-mode)
> - I use eglot (config below)
> - I use rust-analyzer 1.80.1 (3f5fd8d 2024-08-06)
> - The problem seems to happen deep into a work day, after many
>   commits, reverts, etc.
> 
> My eglot configuration:
> 
> #+begin_src elisp
>   (setq
>eglot-extend-to-xref t
>eglot-ignored-server-capabilities
>'(
>  :inlayHintProvider
>  :documentOnTypeFormattingProvider
>  )
>)
> #+end_src
> 
> Eventually, this pops into *Messages*:
> 
> #+begin_quote
> cl--assertion-failed: Assertion failed: (or track-changes--before-no (<= 
> track-changes--before-beg (track-changes--state-beg track-changes--state) beg 
> end (track-changes--state-end track-changes--state) 
> track-changes--before-end))
> #+end_quote
> 
> And this in *Warnings*:
> 
> #+begin_quote
> ⛔ Warning (emacs): Missing/incorrect calls to 
> ‘before/after-change-functions’!!
> Details logged to ‘track-changes--error-log’
> #+end_quote
> 
> Over time, they just keep repeating, although I think killing the
> buffer and reopening the file makes it stop.
> 
> If I have inspected ‘track-changes--error-log’ correctly, this is
> what it contains (looks like some binary, hope it comes through
> in some useful fashion or another):
> 
> #+begin_quote
> (("lib.rs" (buffer-size 5254 5218) ((t track-changes--recover-from-error ... 
> nil) (t track-changes-fetch ... nil) (t eglot--track-changes-fetch ... nil) 
> (t eglot--signal-textDocument/didChange nil nil) (t 
> eglot--signal-textDocument/didSave nil nil) (t run-hooks ... nil) (t 
> basic-save-buffer ... nil) (t save-buffer ... nil) (t funcall-interactively 
> ... nil) (t call-interactively ... nil) (t command-execute ... nil)) [111 
> (nil . other-window) 103 (nil . recompile) 121 (nil . undefined) 24 96 (nil . 
> next-error) 1 (nil . move-beginning-of-line) 11 ...]) ("lib.rs" (buffer-size 
> 5256 5254) ((t track-changes--recover-from-error ... nil) (t 
> track-changes-fetch ... nil) (t eglot--track-changes-fetch ... nil) (t 
> eglot--signal-textDocument/didChange nil nil) (t 
> eglot--signal-textDocument/didSave nil nil) (t run-hooks ... nil) (t 
> basic-save-buffer ... nil) (t save-buffer nil nil) (t #[257 "r\211q\210\300 
> )\207" [save-buffer] 2 ...] ... nil) (t map-y-or-n-p ... nil) (t 
> save-some-buffers ... nil) (t recompile ... nil) ...) [19 (nil . save-buffer) 
> 24 24 (nil . exchange-point-and-mark) 23 (nil . kill-region) 24 19 (nil . 
> save-buffer) backspace (nil . delete-backward-char) ...]) ("lib.rs" 
> (buffer-size 5278 5256) ((t track-changes--recover-from-error ... nil) (t 
> track-changes-fetch ... nil) (t eglot--track-changes-fetch ... nil) (t 
> eglot--signal-textDocument/didChange nil nil) (t 
> eglot--signal-textDocument/didSave nil nil) (t run-hooks ... nil) (t 
> basic-save-buffer ... nil) (t save-buffer ... nil) (t funcall-interactively 
> ... nil) (t call-interactively ... nil) (t command-execute ... nil)) [(nil . 
> backward-word) 2 (nil . backward-char) 67108896 (nil . set-mark-command) 
> 134217734 (nil . forward-sexp) 23 (nil . kill-region) 24 19 (nil . 
> save-buffer) ...]) ("lib.rs" (buffer-size 5324 5278) ((t 
> track-changes--recover-from-error ... nil) (t track-changes-fetch ... nil) (t 
> eglot--track-changes-fetch ... nil) (t eglot--track-changes-signal ... nil) 
> (t #[771 "\211^BZ\211^HG^E]  
> #+end_quote
> 
> I wish I could reliably repeat it.  Given that it occurs after
> many hours of work, `emacs -Q` isn't an option.

Adding Stefan.

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

[Eli Zaretskii]

> Cc: 73...@debbugs.gnu.org
> Date: Thu, 05 Sep 2024 15:48:12 +0200
> From:  Manuel Giraud via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" 
> 
> > And is xdg-open reliably available on BSD systems, so that we don't
> > generate an opaque error message if that is not the case?
> 
> I think it would work whether xdg-open is install or not because
> `shell-command-guess-open' is defined by testing the presence of
> xdg-open.  So if xdg-open is not installed, `command' in the code above
> will be nil and nothing will happen.

Then why do we need to condition this by system-type at all?

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

[Philip Kaludercic]

Eli Zaretskii  writes:

>> Cc: 73...@debbugs.gnu.org
>> Date: Thu, 05 Sep 2024 15:48:12 +0200
>> From:  Manuel Giraud via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" 
>> 
>> > And is xdg-open reliably available on BSD systems, so that we don't
>> > generate an opaque error message if that is not the case?
>> 
>> I think it would work whether xdg-open is install or not because
>> `shell-command-guess-open' is defined by testing the presence of
>> xdg-open.  So if xdg-open is not installed, `command' in the code above
>> will be nil and nothing will happen.
>
> Then why do we need to condition this by system-type at all?

Juri implemented the command, so perhaps he could explain.  I don't
understand why one doesn't just use `shell-command-guess-open' directly?

-- 
Philip Kaludercic on siskin

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]

Eli Zaretskii  writes:

>> Cc: 73...@debbugs.gnu.org
>> Date: Thu, 05 Sep 2024 15:48:12 +0200
>> From:  Manuel Giraud via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" 
>> 
>> > And is xdg-open reliably available on BSD systems, so that we don't
>> > generate an opaque error message if that is not the case?
>> 
>> I think it would work whether xdg-open is install or not because
>> `shell-command-guess-open' is defined by testing the presence of
>> xdg-open.  So if xdg-open is not installed, `command' in the code above
>> will be nil and nothing will happen.
>
> Then why do we need to condition this by system-type at all?

Yes I wondered this too.  The current "otherwise" clause is an error
message but it could be this `call-process' instead.
-- 
Manuel Giraud

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

[Philip Kaludercic]

Sean Whitton  writes:

> Hello,
>
> On Thu 05 Sep 2024 at 09:39am GMT, Philip Kaludercic wrote:
>
 + ((eq region 'unix-word)
 +  (let ((end (point)))
 +(save-excursion
 +  (skip-chars-backward "[:space:]")
 +  (skip-chars-backward "^[:space:]")
 +  (filter-buffer-substring
 +   (if (get-char-property (point) 'read-only)
 +   (next-single-char-property-change
 +(point) 'read-only nil end)
 + (point))
 +   end 'delete
 + (region
 +  (funcall region-extract-function 'delete))
 + ((filter-buffer-substring beg end 'delete)
>>>
>>> Shall I rather commit this as an independent unix-word-rubout?
>>>
>>> Improves attribution, and it's independently useful.
>>
>> As a standalone command?
>
> I mean, yeah, I have had it on my C-w for years.  Probably some other
> people have implementations too.

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:

>From fa7b5158fb1507db32a7b537137418afa024cfad Mon Sep 17 00:00:00 2001
From: Philip Kaludercic 
Date: Tue, 3 Sep 2024 18:29:56 +0200
Subject: [PATCH] Allow 'kill-region' kill the last word when there is no
 region

* etc/NEWS: Document the new user option.
* lisp/simple.el (kill-region-dwim): Add new option.
(kill-region): Respect 'kill-region-dwim'.  (Bug#69097)
---
 etc/NEWS   |  8 +++-
 lisp/simple.el | 49 ++---
 2 files changed, 49 insertions(+), 8 deletions(-)

diff --git a/etc/NEWS b/etc/NEWS
index 1e66f084117..60efbfb43d8 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -123,6 +123,12 @@ 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 user option 'kill-word-if-no-region'.
+This option will modify the fall-back behaviour of 'kill-region' if no
+region is active, and will kill the last word instead of raising an
+error.
+
 
 * Changes in Specialized Modes and Packages in Emacs 31.1
 
@@ -268,7 +274,7 @@ any.
 ** Diff
 
 ---
-*** New command 'diff-kill-ring-save'.
+*** New command 'diff-kill-dwim'.
 This command copies to the 'kill-ring' a region of text modified
 according to diffs in the current buffer, but without applying the diffs
 to the original text.  If the selected range extends a hunk, the
diff --git a/lisp/simple.el b/lisp/simple.el
index eedc5768fe2..efa338f0b0d 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -5817,6 +5817,18 @@ kill-read-only-ok
   :type 'boolean
   :group 'killing)
 
+(defcustom kill-region-dwim nil
+  "Behaviour when `kill-region' is invoked without an active region.
+If set to nil (default), the behaviour of `kill-region' stays the same.
+If set to `emacs-word', then kill the last word as defined by the
+current major mode.  If set to `unix-word', then kill the last word in
+the style of a shell like Bash, disregarding the major mode."
+  :type '(choice (const :tag "Kill a word like `backward-kill-word'" emacs-word)
+ (const :tag "Kill a word like Bash would" unix-word)
+ (const :tag "Do not kill anything" nil))
+  :group 'killing
+  :version "31.1")
+
 (defun kill-region (beg end &optional region)
   "Kill (\"cut\") text between point and mark.
 This deletes the text from the buffer and saves it in the kill ring.
@@ -5843,21 +5855,44 @@ kill-region
  (To delete text, use `delete-region'.)
 Supply two arguments, character positions BEG and END indicating the
  stretch of text to be killed.  If the optional argument REGION is
- non-nil, the function ignores BEG and END, and kills the current
+ `region', the function ignores BEG and END, and kills the current
  region instead.  Interactively, REGION is always non-nil, and so
- this command always kills the current region."
+ this command always kills the current region.  It is possible to
+ override this behaviour by customising the user option
+ `kill-region-dwim'."
   ;; Pass mark first, then point, because the order matters when
   ;; calling `kill-append'.
   (interactive (progn
  (let ((beg (mark))
(end (point)))
-   (unless (and beg end)
+  

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

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

>> If so, then this violation might be caused by the fact that we
>> (1) did resize windows according to the new sizes but (2) did not update
>> the frame sizes accordingly.
>
> Can you elaborate on how this could be possible?  I always thought we
> first allocate the frame matrices, and then the window matrices (by
> suballocating them from the frame matrices).  Am I mistaken?

But if glyph_row_slice_p (window_row, frame_row) fails, something else
must have invalidated that.  I made that change here more than three
years ago and I can neither remember whether an assertion violation made
me do it or a crash nor why I did chose a term like "congruent" in the
comment.

One possibility I cannot exclude is that adjust_frame_size tries to
resize windows, that step (silently) fails in window_resize_check, the
old values stay in place but the new frame sizes are applied by
adjust_frame_size.  But precisely this scenario cannot be healed by my
patch so it's unlikely that it was the cause for the problem I
experienced back then.

> Moving code in adjust_frame_glyphs could affect the assertion if the
> assertion was being hit while adjust_frame_glyphs is still being
> executed.  But that is not the case, so I don't understand how moving
> some code in adjust_frame_glyphs without changing it could affect the
> assertion violation.  I'm probably missing something.

I'm still too dense to understand what "Moving code" and "moving some
code" could mean in this context.  If you have enough patience left,
please elaborate.

Thanks, martin

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

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

> Are you running the latest codebase?  The assertions in cmcheckmagic
> are supposed to be fixed there.

I suppose you mean the changes related to Bug#71289.  They should be
here with the last one as

commit 6fbb699bee2f54d65fbe6074735d42bbc0868c2c
Author: Eli Zaretskii 
Date:   Wed Jun 5 19:32:17 2024 +0300

; Fix last change.

Anyway, I pulled master again today, built with gtk3 and without-x and
both exhibit the same behavior with

MagicWrap (tty) == true
curY (tty) == 4
FrameRows (tty) == 5

in cmcheckmagic after shrinking the TTY window with the mouse to less
than two lines, slowly re-expanding it, at the time the split windows
would have to be redisplayed because the frame apparently became large
enough again.

martin

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

[Suhail Singh]

I observe 100% CPU usage for several seconds when invoking dired for a
directory on one of the remote machines I connect to.  This doesn't seem
to happen for another host.  The connection to the affected host is
slower, and on that host the issue is worse when the directory has
several symlinks.

To reproduce via =emacs -Q=:
- Invoke `find-file' and connect to problematic host over ssh.
- Once connection is established, open dired pointing to a directory on
  the affected host.
- Observe bug: it takes _several_ seconds for the dired buffer to show.
  During that time, Emacs CPU usage is 100%.
- Once dired buffer is open, invoke `revert-buffer' and observe issue
  again.

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

Given that rudimentary font-locking should be possible via, simply, the
output of `ls --dired', it is unclear why enabling font-locking makes
things so much worse.  If there are some aspects of font-locking that
perform much worse over a slower connection, it would help if there were
a user configuration to disable them.

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?


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: Dired by name

Minor modes in effect:
  shell-dirtrack-mode: t
  tooltip-mode: t
  global-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
  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 rfc822
mml mml-sec 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 dired-aux dired dired-loaddefs tramp-sh
tramp-cache time-stamp tramp tramp-loaddefs trampver tramp-integration
files-x tramp-compat rx shell pcomplete comint ansi-osc ring parse-time
iso8601 time-date format-spec auth-source cl-seq eieio eieio-core
cl-macs cl-loaddefs cl-lib password-cache json subr-x map byte-opt gv
bytecomp byte-compile ansi-color rmc delsel lpr easy-mmode pcase
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 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-v

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

[Eli Zaretskii]

> Date: Thu, 5 Sep 2024 16:46:15 +0200
> Cc: n142...@gmail.com, 73...@debbugs.gnu.org
> From: martin rudalics 
> 
> Anyway, I pulled master again today, built with gtk3 and without-x and
> both exhibit the same behavior with
> 
> MagicWrap (tty) == true
> curY (tty) == 4
> FrameRows (tty) == 5
> 
> in cmcheckmagic after shrinking the TTY window with the mouse to less
> than two lines, slowly re-expanding it, at the time the split windows
> would have to be redisplayed because the frame apparently became large
> enough again.

Please describe the recipe in more detail, starting from "emacs -Q -nw".

bug#73047: 30.0.90; feature request - add recency column to ibuffer

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

Dear Emacs maintainers,

I want to propose the addition of an optional recency column to Ibuffer,
which shows the last buffer display time. Sorting by recency is already
supported by Ibuffer (ibuffer-do-sort-by-recency). I use the following
code in my configuration:

(defvar-keymap ibuffer-recency-header-map
  "" #'ibuffer-do-sort-by-recency)
  
(define-ibuffer-column recency
  (:inline t :summarizer ignore :header-mouse-map ibuffer-recency-header-map)
  (if-let ((time (buffer-local-value 'buffer-display-time buffer)))
  (progn
(require 'marginalia)
(marginalia--time (buffer-local-value 'buffer-display-time buffer)))
"never"))

The time string is formatted in a human readable form, relative to to
the current time, e.g., "2 mins ago", "30 secs ago" or "never". I use
the function from the Marginalia package from GNU ELPA for formatting
right now. As far as I know Emacs does not yet provide a relative time
formatting function? Maybe there is interest in adding marginalia--time
to Emacs, e.g., with the name format-time-relative? As far as I know,
multiple packages define a similar formatting function, such that we
could potentially get some code reuse. The function could be ported
back via Compat to make it available to ELPA packages.

Thank you!

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

[Eli Zaretskii]

> Date: Thu, 5 Sep 2024 16:45:52 +0200
> Cc: n142...@gmail.com, 73...@debbugs.gnu.org
> From: martin rudalics 
> 
>  >> If so, then this violation might be caused by the fact that we
>  >> (1) did resize windows according to the new sizes but (2) did not update
>  >> the frame sizes accordingly.
>  >
>  > Can you elaborate on how this could be possible?  I always thought we
>  > first allocate the frame matrices, and then the window matrices (by
>  > suballocating them from the frame matrices).  Am I mistaken?
> 
> But if glyph_row_slice_p (window_row, frame_row) fails, something else
> must have invalidated that.  I made that change here more than three
> years ago and I can neither remember whether an assertion violation made
> me do it or a crash nor why I did chose a term like "congruent" in the
> comment.

I agree with the theory that the frame matrices were reallocated
whereas the window matrices weren't, or the other way around.  I just
don't understand how it could have happened, given the code we have.

I noticed that causing this assertion to fail is not very easy.  For
example, if I drag the terminal emulator window one line at a time, I
can never cause it, even if I get to frame sizes that are much smaller
than the minimum we need for 2 windows.  Somehow, I need to drag the
frame so it resizes by several lines and/or columns.  Not sure why.

> One possibility I cannot exclude is that adjust_frame_size tries to
> resize windows, that step (silently) fails in window_resize_check, the
> old values stay in place but the new frame sizes are applied by
> adjust_frame_size.  But precisely this scenario cannot be healed by my
> patch so it's unlikely that it was the cause for the problem I
> experienced back then.

What is supposed to happen, with the current code, when the frame is
resized to less than the minimum dimensions we allow?  Shouldn't we
disallow/refuse such resizes?  And if we don't refuse, what will
happen to the windows?  E.g., if the frame is not tall enough to show
the menu bar, the two mode lines, the mini-window, and at least one
line for each of the two windows, what should I expect to see on
display?

>  > Moving code in adjust_frame_glyphs could affect the assertion if the
>  > assertion was being hit while adjust_frame_glyphs is still being
>  > executed.  But that is not the case, so I don't understand how moving
>  > some code in adjust_frame_glyphs without changing it could affect the
>  > assertion violation.  I'm probably missing something.
> 
> I'm still too dense to understand what "Moving code" and "moving some
> code" could mean in this context.  If you have enough patience left,
> please elaborate.

Taking some code and moving it to another place in the same function
can only affect what's going on in that function and the functions it
calls.  For example, if you had

   foo ();
   bar ();
   baz ();

and then you move the call to baz to be before the call to bar, like
this:

   foo ();
   baz ();
   bar ();

then I can understand why bar and its subroutines are affected.  But
once we are done with this code, all the 3 calls have been made, and
the order in which they were made can hardly matter for the code which
runs after that, right?

So if the crash was inside the call to bar, then I could understand
how moving the call to baz before it could affect the crash.  But the
backtrace from the assertion violation didn't show adjust_frame_glyphs
anywhere on the call-stack, so I don't understand how simply
rearranging code inside adjust_frame_glyphs could change something
_outside_ it.

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

[Eli Zaretskii]

> Date: Thu, 5 Sep 2024 17:48:51 +0200
> Cc: n142...@gmail.com, 73...@debbugs.gnu.org
> From: martin rudalics 
> 
> I attach four screenshots to illustrate what I'm doing.
> 
> First I split the window via C-x 2 (tty_1.png).  Now, using the mouse,
> I drag the lower edge of the terminal window up in order to shrink that
> window (tty_2.png).  At some moment the edge can't be dragged any more
> (tty_3.png).  Now I drag the edge down to enlarge the window again
> (tty_4.png).  When at this moment I drag the edge once more down Emacs
> crashes.  Which IIUC means that Emacs crashes at the time it wants to
> show the minibuffer window again.

It doesn't crash for me when I repeat these steps, but I'm doing this
in PuTTY logged into a remote GNU/Linux system, so maybe that's the
reason.

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

[Eli Zaretskii]

> From: "Suhail Singh" 
> Date: Thu, 05 Sep 2024 10:24:54 -0400
> 
> 
> I observe 100% CPU usage for several seconds when invoking dired for a
> directory on one of the remote machines I connect to.  This doesn't seem
> to happen for another host.  The connection to the affected host is
> slower, and on that host the issue is worse when the directory has
> several symlinks.
> 
> To reproduce via =emacs -Q=:
> - Invoke `find-file' and connect to problematic host over ssh.
> - Once connection is established, open dired pointing to a directory on
>   the affected host.
> - Observe bug: it takes _several_ seconds for the dired buffer to show.
>   During that time, Emacs CPU usage is 100%.
> - Once dired buffer is open, invoke `revert-buffer' and observe issue
>   again.
> 
> Disabling global-font-lock-mode, makes the situation better.
> 
> Given that rudimentary font-locking should be possible via, simply, the
> output of `ls --dired', it is unclear why enabling font-locking makes
> things so much worse.  If there are some aspects of font-locking that
> perform much worse over a slower connection, it would help if there were
> a user configuration to disable them.
> 
> 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.

bug#72861: 30.0.90; remote tramp (30.0.90): Couldn't find a proper `ls' command

[Christopher Howard]

Michael Albinus  writes:
>
> And here we are. Just /bin:/usr/bin is in the PATH.
> What's needed is, that you expand tramp-remote-path by the directories
> guis keeps the system programs. See the Tramp manual (info "(tramp) Remote 
> programs")
>
> See also bug#64534. This is a Guix bug, that's why I haven't seen it
> until now. But IIUC, Guix offers some Tramp config in its own version of
> Emacs.
>

I'll try to follow up on the guix bug report. I added the appropriate directory 
to tramp-remote-path but that did not work. Perhaps the code for that is broken 
for Emacs 30.

-- 
Christopher Howard

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

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

> What is supposed to happen, with the current code, when the frame is
> resized to less than the minimum dimensions we allow?  Shouldn't we
> disallow/refuse such resizes?  And if we don't refuse, what will
> happen to the windows?  E.g., if the frame is not tall enough to show
> the menu bar, the two mode lines, the mini-window, and at least one
> line for each of the two windows, what should I expect to see on
> display?

As for GUI frames I wrote some code to handle that but you didn't like
it back then.  Basically, we should do the following:

- Add min-size-hints so the window manage never tries to make the frame
  to small.  These have to correspond to the current window layout and
  the window decorations - a frame with split windows has a larger
  minimum size than one with one window only as we can see in the
  present thread.

- When the window manager doesn't comply, simple ignore the shrink
  request.  Portions of our frame that don't fit will be clipped by the
  window manager.  I wrote some code to always keep the minibuffer
  window visible in such case but cannot remember whether it works well.
  My WM (and Windows too) never tried to make a GUI frame smaller than I
  wanted.

On terminal emulators we should (or even do) conceptually the same as
with a non-compliant WM.  The terminal emulator has to do the clipping
just like the WM.

> Taking some code and moving it to another place in the same function
> can only affect what's going on in that function and the functions it
> calls.  For example, if you had
>
> foo ();
> bar ();
> baz ();
>
> and then you move the call to baz to be before the call to bar, like
> this:
>
> foo ();
> baz ();
> bar ();
>
> then I can understand why bar and its subroutines are affected.  But
> once we are done with this code, all the 3 calls have been made, and
> the order in which they were made can hardly matter for the code which
> runs after that, right?

So I moved the assignments within adjust_frame_size (baz) in front of
the resize_frame_windows (bar) calls.  Is it that what you mean?

> So if the crash was inside the call to bar, then I could understand
> how moving the call to baz before it could affect the crash.  But the
> backtrace from the assertion violation didn't show adjust_frame_glyphs
> anywhere on the call-stack, so I don't understand how simply
> rearranging code inside adjust_frame_glyphs could change something
> _outside_ it.

Do you mean adjust_frame_size instead of adjust_frame_glyphs here so the
fact that makes you wonder is that adjust_frame_size never shows up in
the backtraces?

I could imagine that resize_frame_windows (or even
'window--pixel-to-total') mess up things in a way that confuses frame
based redisplay later.  In adjust_frame_glyphs_for_frame_redisplay we do

  eassert (matrix_dim.width == FRAME_TOTAL_COLS (f)
   && matrix_dim.height == FRAME_TOTAL_LINES (f));

and I wonder whether there's an execution path that could bypass that
assertion.

martin

bug#72861: 30.0.90; remote tramp (30.0.90): Couldn't find a proper `ls' command

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

Christopher Howard  writes:

Hi Christopher,

>> And here we are. Just /bin:/usr/bin is in the PATH.
>> What's needed is, that you expand tramp-remote-path by the directories
>> guis keeps the system programs. See the Tramp manual (info "(tramp) Remote 
>> programs")
>>
>> See also bug#64534. This is a Guix bug, that's why I haven't seen it
>> until now. But IIUC, Guix offers some Tramp config in its own version of
>> Emacs.
>
> I'll try to follow up on the guix bug report. I added the appropriate
> directory to tramp-remote-path but that did not work. Perhaps the code
> for that is broken for Emacs 30.

OK. Feel free to ask if you need further help from the Tramp camp.

I'll keep this bug open. Pls inform us, when (if!) it can be closed.

Best regards, Michael.

bug#73047: 30.0.90; feature request - add recency column to ibuffer

[JD Smith]

> On Sep 5, 2024, at 11:28 AM, Daniel Mendler via Bug reports for GNU Emacs, 
> the Swiss army knife of text editors  wrote:
> 
> As far as I know, multiple packages define a similar formatting function, 
> such that we
> could potentially get some code reuse. 

Definitely agree.  See bug#71572 
, which includes such a 
formatting function, heavily discussed, but not yet merged.

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

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

> It doesn't crash for me when I repeat these steps, but I'm doing this
> in PuTTY logged into a remote GNU/Linux system, so maybe that's the
> reason.

Can you get the window as small as in my third screenshot?  In which
order does it re-show windows when you re-enlarge the window?  From top
to bottom with the minibuffer window last?

martin

bug#73032: 31.0.50; vtable header is not aligned

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

On 2024-09-05 10:36, Eli Zaretskii wrote:

>> Date: Thu, 05 Sep 2024 01:45:14 +0300
>> From:  Aleksandr Vityazev via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" 
>> 
>> There is a problem in vtable.el when an emoji is specified as a delimiter; 
>> the
>> header and row delimiters are not aligned.
>> 
>> Minimal reproducer for emacs -Q:
>> 
>> (require 'vtable)
>> (with-current-buffer (get-buffer-create "*test*")
>>   (make-vtable
>>:columns '((:name "Name" :width 20) "Size" "File")
>>:objects (buffer-list)
>>:actions '("k" kill-buffer
>>   "RET" display-buffer)
>>:divider " 🍉 "
>>:getter (lambda (object column vtable)
>>  (pcase (vtable-column vtable column)
>>("Name" (buffer-name object))
>>("Size" (buffer-size object))
>>("File" (or (buffer-file-name object) "")
>>   (switch-to-buffer "*test*"))
>> 
>> Screenshot is attached.
>
> I cannot get them aligned even if I replace the Emoji character with
> an ASCII character, like 'x'.  Can you?
No, I can't.

> AFAICT, there's inconsistency in whitespace calculation between the
> header line and the body of the table, due to the desire to display
> the sorting indicator not quite right-aligned.  The patch below
> attempts to fix that; does it give good results?

The patch helped, but there are still some issues. I was able to achieve
alignment with the following settings:
(set-face-attribute 'default nil :family "monospace" :height 210)

With: (set-face-attribute 'default nil :family "monospace" :height 220)
the header separators are also misaligned. My patch is based on the one
that was sent; I just commented out the insertion of an extra space
after the column name.

diff --git a/lisp/emacs-lisp/vtable.el b/lisp/emacs-lisp/vtable.el
index cb7ea397314..e5bcb54f28e 100644
--- a/lisp/emacs-lisp/vtable.el
+++ b/lisp/emacs-lisp/vtable.el
@@ -722,15 +722,17 @@ vtable--insert-header-line
(vtable--limit-string
 name (- (elt widths index) indicator-width))
  name))
- (let ((fill-width
-(+ (- (elt widths index)
-  (string-pixel-width displayed)
-  indicator-width
-  (vtable-separator-width table)
-  ;; We want the indicator to not be quite flush
-  ;; right.
-  (/ (vtable--char-width table) 2.0))
-   (if last 0 spacer
+ (let* ((indicator-lead-width
+ ;; We want the indicator to not be quite flush right.
+ (/ (vtable--char-width table) 2.0))
+(indicator-pad-width (- (vtable--char-width table)
+indicator-lead-width))
+(fill-width
+ (+ (- (elt widths index)
+   (string-pixel-width displayed)
+   indicator-width
+   indicator-lead-width)
+(if last 0 spacer
(if (or (not last)
(zerop indicator-width)
(< (seq-reduce #'+ widths 0) (window-width nil t)))
@@ -739,7 +741,9 @@ vtable--insert-header-line
 displayed
 (propertize " " 'display
 (list 'space :width (list fill-width)))
-indicator)
+indicator
+(propertize " " 'display
+(list 'space :width (list indicator-pad-width
  ;; This is the final column, and we have a sorting
  ;; indicator, and the table is too wide for the window.
  (let* ((pre-indicator (string-pixel-width
@@ -758,10 +762,10 @@ vtable--insert-header-line
   (list (- fill-width pre-fill
  (when (and divider (not last))
(insert (propertize divider 'keymap dmap)))
- (insert (propertize
-  " " 'display
-  (list 'space :width (list
-   (/ (vtable--char-width table) 2.0)
+ ;; (insert (propertize
+ ;;  " " 'display
+ ;;  (list 'space :width (list
+ ;;   (/ (vtable--char-width table) 
2.0)
  (put-text-property start (point) 'vtable-column index)))
  (vtable-columns table))
 (insert "\n")


-- 
Best regards,
Aleksandr Vityazev

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

[Madhu]

*  Michael Heerdegen  <874j6uz4d8@web.de>
Wrote on Thu, 05 Sep 2024 14:12:19 +0200

apparently the autoload cookie fix that i suggested to wdired.el
wdired--before-change-fn (and recompiling) only gets rid of the match
data clobbered error when I have already applied the earlier
font-lock-ensure patch.

also the recipe is flawed, I apologize. [i didn't (require 'cl-lib)
which is required for emacs -Q]

But if you are in a dired buffer looking at /tmp/test-foo with 40
entries of symlinks of the form n -> foo/n This is the behaviour I get
on emacs -q:

1. C-x C-q
2. M-x rep-reg "foo" "bar" RET
;; get a  match data clobbered  error (q), C-c C-k to revert dired
3. M-x load-library "dired" RET  ;;makes the match-data clobbered error go away
4. C-x C-q
5. M-x rep-reg "foo" "bar" RET

I get "Replaced 19 occurrences" and the point ends up on the last
entry, the remaining entries have not been replaced.

I confirmed this twice before posting

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

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

One detail: If looking at the fourth, final screenshot I sent earlier,
then I notice that the last character of the lower mode line is black
which seems to correspond to curX (tty) == FrameCols (tty).  Does this
mean that the cursor is on the mode line of the lower normal window?

martin

bug#73050: 30.0.90; Empty tool tip when hovering over tab-bar separator

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

This is only a minor issue. After enabling `tab-bar-mode' when hovering
with the mouse over the `tab-bar-separator' space, an empty tool tip
will be shown after a short delay.

To reproduce:

1. Start emacs -Q
2. M-x tab-bar-mode
3. Move the mouse pointer over the space right after the "*scratch*" tab

Would it make sense to somehow prevent displaying blank tool tips, e.g.,
via the following advice? Or maybe blank tool tips could be prevented on
the tab-bar level?

(defun x-show-tip-adv (str &rest _) (string-blank-p str))
(advice-add #'x-show-tip :before-until #'x-show-tip-adv)

Thank you!

In GNU Emacs 30.0.90 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo
 version 1.18.0, Xaw scroll bars) of 2024-09-01
Windowing system distributor 'The X.Org Foundation', version 11.0.12101013
System Description: Debian GNU/Linux trixie/sid

Configured using:
 'configure --prefix=... --with-tree-sitter
 --with-native-compilation --with-x-toolkit=athena --with-dbus
 --without-selinux --without-threads --without-gsettings --without-gpm
 --with-cairo --with-cairo-xcb'

Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS HARFBUZZ JPEG LIBOTF LIBXML2
MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND
SQLITE3 TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XDBE XIM XPM LUCID
ZLIB

bug#73051: 31.0.50; json-parse-string truncated docstring

[German Pacenza]

json-parse-string docstring seems to be truncated at 'which see':

Parse the JSON STRING into a Lisp value.
This is essentially the reverse operation of ‘json-serialize’, which
see. The returned ...

bug#73049: 29.4; tab-line-mode unuseful docstring

[Thierry Volpiatto]

What tab-line-mode is supposed to do?

"Toggle display of tab line in the windows displaying the current buffer."

I couldn't figure what is a "tab line".

Could it be explained in docstring?

Thanks.


In GNU Emacs 29.4 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.33,
 cairo version 1.16.0) of 2024-08-24 built on IPad-S340
Windowing system distributor 'The X.Org Foundation', version 11.0.12101004
System Description: Linux Mint 21.3

Configured using:
 'configure CFLAGS=-O8 --bindir=/usr/local/sbin/emacs-29.4 --with-cairo
 --with-modules --without-tree-sitter --without-native-compilation'

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

Important settings:
  value of $LANG: fr_FR.UTF-8
  locale-coding-system: utf-8-unix

Major mode: 

Minor modes in effect:
  emms-mode-line-mode: t
  emms-playing-time-display-mode: t
  emms-playing-time-mode: t
  server-mode: t
  psession-mode: t
  psession-savehist-mode: t
  register-preview-mode: t
  global-git-gutter-mode: t
  display-time-mode: t
  winner-mode: t
  tv-save-place-mode: t
  helm-epa-mode: t
  helm-descbinds-mode: t
  helm-top-poll-mode: t
  helm-adaptive-mode: t
  helm-mode: t
  helm-minibuffer-history-mode: t
  helm-ff-icon-mode: t
  shell-dirtrack-mode: t
  helm-popup-tip-mode: t
  async-bytecomp-package-mode: t
  dired-async-mode: t
  minibuffer-depth-indicate-mode: t
  gcmh-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: 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

Load-path shadows:
None found.

Features:
(shadow emacsbug gnus-async gnus-ml disp-table nndraft nnmh nnfolder
gnus-agent gnus-srvr gnus-score score-mode nnvirtual nntp gnus-cache
epa-file network-stream nsm mailalias wttr-weather epa-mail face-remap
helm-x-files helm-for-files helm-bookmark shortdoc helm-command
helm-elisp helm-eval edebug debug backtrace helm-info w3m-form
w3m-symbol config-w3m w3m timezone w3m-hist bookmark-w3m w3m-ems
w3m-favicon w3m-image w3m-fb tab-line w3m-proc w3m-util smiley gnus-cite
qp mm-archive mail-extr textsec uni-scripts idna-mapping ucs-normalize
uni-confusable textsec-check addressbook-bookmark tv-mu4e-config
gnus-and-mu4e mu4e-patch mu4e-contrib eshell esh-cmd esh-ext esh-opt
esh-proc esh-io esh-arg esh-module esh-groups esh-util mu4e mu4e-org
mu4e-notification notifications mu4e-main smtpmail mu4e-view
mu4e-mime-parts mu4e-headers mu4e-thread mu4e-actions mu4e-compose
mu4e-draft gnus-msg mu4e-search mu4e-lists mu4e-bookmarks mu4e-mark
mu4e-message flow-fill hl-line mu4e-contacts mu4e-update mu4e-folders
mu4e-context mu4e-query-items mu4e-server mu4e-modeline mu4e-vars
mu4e-helpers mu4e-config mu4e-window bookmark ido mu4e-obsolete
image-file image-converter char-fold emms-config emms-idapi-browser
emms-idapi emms-idapi-musicbrainz emms-mpris emms-librefm-stream
emms-librefm-scrobbler emms-playlist-limit emms-i18n emms-history
emms-score emms-stream-info emms-metaplaylist-mode emms-bookmarks
emms-cue emms-mode-line-icon emms-browser sort emms-volume
emms-volume-sndioctl emms-volume-mixerctl emms-volume-pulse
emms-volume-amixer emms-playlist-sort emms-last-played emms-player-xine
emms-player-mpd tq emms-lyrics emms-url emms-streams emms-show-all
emms-tag-editor emms-tag-tracktag emms-mark emms-mode-line emms-cache
emms-info-native emms-info-native-spc emms-info-native-mp3
emms-info-native-ogg emms-info-native-opus emms-info-native-flac
emms-info-native-vorbis bindat emms-info-exiftool emms-info-tinytag
emms-info-metaflac emms-info-opusinfo emms-info-ogginfo
emms-info-mp3info emms-playlist-mode emms-player-vlc emms-player-mpv
emms-playing-time emms-info emms-later-do emms-player-mplayer
emms-player-simple emms-source-playlist emms-source-file locate
emms-setup emms emms-compat emms-auto helm-external helm-net
tramp-archive tramp-gvfs tramp-cache time-stamp zeroconf ffap
helm-ls-git vc-git diff-mode vc vc-dispatcher make-mode conf-mode
org-element org-persist org-id org-refile avl-tree generator oc-basic
cl-extra ol-eww eww url-queue mm-url ol-rmail ol-mhe ol-irc ol-info
ol-gnus nnselect gnus-art mm-uu mml2015 mm-view mml-smime smime gnutls
dig gnus-sum shr pixel-fill kinsoku url-file svg dom gnus-group
gnus-undo gnus-start gnus-dbus dbus xml gnus-cloud nnimap nnmail
mail-source utf7 nnoo gnus-spec gnus-int gnus-range message sendmail
puny rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
rfc2047 rfc2045 ietf-drums mailabbrev gmm-utils mailheader gnus-win gnus
nnheader gnus-util mail-utils range mm-util mail-prsvr ol-docview
doc-view jka-compr ol-bibtex bibtex ol-bbdb

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

[Juri Linkov]

>> So you prefer to slow down only when the user types C-s?
>> This is possible by adding a local hook in
>> wdired-change-to-wdired-mode:
>>
>>   (add-hook 'isearch-mode-hook #'font-lock-ensure nil t)
>
> A step back: I now tried to reproduce the recipe, but I only see the
> clobbered match data error (randomly) - I don't see only the visible
> buffer portion operated on.  With other words: I can't reproduce the
> issue, at least not with the "visible buffer portion" interpretation,
> and I don't see that we would need to call `font-lock-ensure' at all.

Maybe this is reproducible only on very long Dired buffers?

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

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

[Juri Linkov]

>>> global-mode-string is a variable defined in xdisp.c.
>>> Value
>>> ((:eval (mu4e--modeline-string)) (t (:eval (lsp--progress-status)))
>>>  ((t lsp-java-progress-string)) (:eval (exec/git-mode-string))
>>>  (:eval (exec/gc-mode-string)) flycheck-mode-line)
>
> 1. (mu4e--modeline-string) :
>
> #(" 🌀0/0 "
>   1 2 (help-echo "mu4e favorite bookmark"
>mouse-face mode-line-highlight
>keymap (mode-line keymap (mouse-1 . mu4e-jump-to-favorite)
> (mouse-2 . mu4e-jump-to-favorite)
> (mouse-3 . mu4e-jump-to-favorite)))
>   2 3 (mouse-face mode-line-highlight
>keymap (mode-line keymap (mouse-1 . mu4e-jump-to-favorite)
> (mouse-2 . mu4e-jump-to-favorite)
> (mouse-3 . mu4e-jump-to-favorite))
>face mu4e-header-key-face
>help-echo "mu4e favorite bookmark")
>   3 4 (help-echo "mu4e favorite bookmark"
>mouse-face mode-line-highlight
>keymap (mode-line keymap (mouse-1 . mu4e-jump-to-favorite)
> (mouse-2 . mu4e-jump-to-favorite)
> (mouse-3 . mu4e-jump-to-favorite)))
>   4 5 (mouse-face mode-line-highlight
>keymap (mode-line keymap (mouse-1 . mu4e-jump-to-favorite)
> (mouse-2 . mu4e-jump-to-favorite)
> (mouse-3 . mu4e-jump-to-favorite))
>help-echo "mu4e favorite bookmark")
>   5 6 (help-echo "mu4e favorite bookmark"
>mouse-face mode-line-highlight
>keymap (mode-line keymap (mouse-1 . mu4e-jump-to-favorite)
> (mouse-2 . mu4e-jump-to-favorite)
> (mouse-3 . mu4e-jump-to-favorite
>
> Addition, I eval (flycheck-status-emoji-mode-line-text) got:
> (" " "😐")
> -- 
> Addition: my emacs tab-bar looks like this:
> https://imgur.com/a/IyXki2P

Thanks, looks nice 😉

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

[Juri Linkov]

>>> > And is xdg-open reliably available on BSD systems, so that we don't
>>> > generate an opaque error message if that is not the case?
>>>
>>> I think it would work whether xdg-open is install or not because
>>> `shell-command-guess-open' is defined by testing the presence of
>>> xdg-open.  So if xdg-open is not installed, `command' in the code above
>>> will be nil and nothing will happen.
>>
>> Then why do we need to condition this by system-type at all?
>
> Juri implemented the command, so perhaps he could explain.  I don't
> understand why one doesn't just use `shell-command-guess-open' directly?

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

bug#73047: 30.0.90; feature request - add recency column to ibuffer

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

JD Smith  writes:

>> On Sep 5, 2024, at 11:28 AM, Daniel Mendler via Bug reports for GNU Emacs, 
>> the Swiss army knife of text editors  wrote:
>> 
>> As far as I know, multiple packages define a similar formatting function, 
>> such that we
>> could potentially get some code reuse. 
>
> Definitely agree.  See bug#71572 
> , which includes such 
> a formatting function, heavily discussed, but not yet merged.

That's great! Thank you for working on this function.

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

[Eli Zaretskii]

> Date: Thu, 5 Sep 2024 18:58:47 +0200
> From: martin rudalics 
> Cc: n142...@gmail.com, 73...@debbugs.gnu.org
> 
> One detail: If looking at the fourth, final screenshot I sent earlier,
> then I notice that the last character of the lower mode line is black
> which seems to correspond to curX (tty) == FrameCols (tty).  Does this
> mean that the cursor is on the mode line of the lower normal window?

Probably.  But the best way of figuring this out is to look at the
cursor coordinates in the debugger.

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

[Eli Zaretskii]

> Date: Thu, 5 Sep 2024 18:30:29 +0200
> Cc: n142...@gmail.com, 73...@debbugs.gnu.org
> From: martin rudalics 
> 
>  > It doesn't crash for me when I repeat these steps, but I'm doing this
>  > in PuTTY logged into a remote GNU/Linux system, so maybe that's the
>  > reason.
> 
> Can you get the window as small as in my third screenshot?

Yes.

> In which order does it re-show windows when you re-enlarge the
> window?  From top to bottom with the minibuffer window last?

First I see just empty frame, even when I enlarge the frame to 4
lines.  Then I see both windows, including the menu bar and the
mini-window.

Sometimes I see different behavior: first just a mode line of the
upper window with one text line, and 1 or 2 empty lines below the mode
line; then menu bar, and finally the bottom window with its mode line
and the mini-window.

bug#73051: 31.0.50; json-parse-string truncated docstring

[Eli Zaretskii]

> From: German Pacenza 
> Date: Thu, 05 Sep 2024 13:27:42 -0300
> 
> json-parse-string docstring seems to be truncated at 'which see':
> 
> Parse the JSON STRING into a Lisp value.
> This is essentially the reverse operation of ‘json-serialize’, which
> see. The returned ...

This is not truncation.  "Which see" is a widely-used phrase, a
translation of "quod vide" or "q.v." in Latin.  The Emacs manual says
in "Glossary":

  q.v.
   Short for "quod vide" in Latin, which means "which see".

We use this a lot in our doc strings.

I'm therefore closing this non-bug.

bug#73049: 29.4; tab-line-mode unuseful docstring

[Eli Zaretskii]

> From: Thierry Volpiatto 
> Date: Thu, 05 Sep 2024 16:40:43 +
> 
> 
> What tab-line-mode is supposed to do?
> 
> "Toggle display of tab line in the windows displaying the current buffer."
> 
> I couldn't figure what is a "tab line".
> 
> Could it be explained in docstring?

Thanks, done.

bug#72966: 30.0.90; [PATCH] php-ts-mode: custom php.ini config for the built-in php webserver

[Vincenzo Pupillo]

Hi Eli, I followed your suggestion and moved the CONFIG argument. I also added 
a new entry to the NEWS file.

Thanks.
Vincenzo

In data lunedì 2 settembre 2024 16:23:53 CEST, Eli Zaretskii ha scritto:
> > From: Vincenzo Pupillo 
> > Date: Mon, 02 Sep 2024 15:29:23 +0200
> > 
> > Ciao,
> > this patch adds a new CONFIG attribute to 'php-ts-mode-run-php-webserver'
> > that allows you to specify an alternative php.ini file to the default (or
> > whatever is specified in 'php-ts-mode-php-config').
> 
> Thanks.
> 
> > -(defun php-ts-mode-run-php-webserver (&optional port hostname
> > document-root -   
> > router-script num-of-workers) +(defun php-ts-mode-run-php-webserver
> > (&optional port
> > +hostname
> > +document-root
> > +router-script
> > +config
> > +num-of-workers)
> > 
> >"Run PHP built-in web server.
> 
> This changes a public API in backward-incompatible way, something we
> don't do, because it could break someone's code out there.  (It is
> true that php-ts-mode was introduced in Emacs 30, but that version is
> already in pretest and will be released soon, so I don't think we can
> change this there, either.)
> 
> So please find a backward-compatible way of adding this feature,
> perhaps add the new CONFIG argument as the last one?
> 
> Also, I think this needs a NEWS entry describing the change in
> behavior.

>From ae9182be63bfa8625c8c8486c1856dced4fb9152 Mon Sep 17 00:00:00 2001
From: Vincenzo Pupillo 
Date: Mon, 2 Sep 2024 14:11:01 +0200
Subject: [PATCH] Support for custom php.ini for the built-in PHP web server.

A new CONFIG attribute, which defaults to 'php-ts-mode-php-config',
allows an alternative php.ini file to be specified for the built-in web
server. The 'php-ts-mode-run-php-webserver' function, when called
interactively with a prefix argument, also requires this new attribute.

* etc/NEWS: Described the new CONFIG attribute and the different
behavior of 'php-ts-mode-run-php-webserver'.
* lisp/progmodes/php-ts-mode.el (php-ts-mode--parent-html-bol):
Fix docstring.
* lisp/progmodes/php-ts-mode.el (php-ts-mode-run-php-webserver):
New CONFIG attribute. Update docstring.
* lisp/progmodes/php-ts-mode.el (php-ts-mode--webserver-read-args):
Support the new TYPE. Update docstring.
---
 etc/NEWS  | 10 +
 lisp/progmodes/php-ts-mode.el | 75 +++
 2 files changed, 69 insertions(+), 16 deletions(-)

diff --git a/etc/NEWS b/etc/NEWS
index f2c999a3955..0539bf47479 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -1965,6 +1965,16 @@ the 'widget-inactive' face).
 If non-nil, moving point forward or backward between widgets by typing
 'TAB' or 'S-TAB' skips over inactive widgets.  The default value is nil.
 
+**  PHP-ts mode
+
+---
+*** 'php-ts-mode-run-php-webserver' now accepts a custom php.ini.
+A new attribute, CONFIG, allows you to specify an custom php.ini.
+By default it retains the previous behavior: prompt for HOSTNAME
+and PORT only if their respective values are nil.
+Interactively, when invoked with prefix argument, always prompt for
+PORT, HOSTNAME, DOCUMENT-ROOT, ROUTER-SCRIPT, NUM-OF-WORKERS and CONFIG.
+
 ** Ruby mode
 
 ---
diff --git a/lisp/progmodes/php-ts-mode.el b/lisp/progmodes/php-ts-mode.el
index 3f89de14075..f8d240b746b 100644
--- a/lisp/progmodes/php-ts-mode.el
+++ b/lisp/progmodes/php-ts-mode.el
@@ -490,7 +490,7 @@ php-ts-mode--parent-html-bol
 (treesit-node-start parent)
 
 (defun php-ts-mode--parent-html-heuristic (node parent _bol &rest _)
-  "Returns position based on html indentation.
+  "Return position based on html indentation.
 
 Returns 0 if the NODE is after the , otherwise returns the
 indentation point of the last word before the NODE, plus the
@@ -1469,8 +1469,12 @@ php-ts-mode
 
 
 ;;;###autoload
-(defun php-ts-mode-run-php-webserver (&optional port hostname document-root
-router-script num-of-workers)
+(defun php-ts-mode-run-php-webserver (&optional port
+hostname
+document-root
+router-script
+num-of-workers
+config)
   "Run PHP built-in web server.
 
 PORT: Port number of built-in web server, default `php-ts-mode-ws-port'.
@@ -1484,10 +1488,12 @@ php-ts-mode-run-php-webserver
 see `https://www.php.net/manual/en/features.commandline.webserver.php'
 NUM-OF-WORKERS: Before run the web server set the
 PHP_CLI_SERVER_WORKERS env variable useful for testing code against
-multiple simultaneous requests.
+multiple simultaneous requests
+CONFI

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

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

On Thu, 5 Sept 2024 at 08:49, martin rudalics  wrote:

>  > My bisection suggests the problematic commit is
>  > 241616831024c9c9fe2b2378b611db0a560b9675
>
> Thanks.  Please try first setting 'frame-inhibit-implied-resize' to t
> which should avoid that a frame gets resized when the menu bar is
> enabled or disabled


Setting the variable to t does indeed prevent the frame being resized when
menu-bar-mode is toggled, but has no effect on the size of the subsequent
windows created.

If this does not help, please proceed as follows: Try to undo that
> commit (I cite it below)


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

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.

bug#72941: jsonrpc: Check if parameters are in line with the spec

[Daniel Pettersson]

>> Would it be possible to extend jsonrpc.el to check the params argument
>> of jsonrpc-request, jsonrpc-notify, and jsonrpc-async-request whether it
>> is a structured value?  And if it is not, then guide the programmer to
>> the above URL with a warning.

The use case makes sense to me, but I would go with updating the docs
rather then the API.  The current wording could use some love as it's
refereed to as JSON object or plist (at different functions).  When it
should be plist or vector, where we could throw in a link to the
specification.

I am not for signaling an error or similar as it's a breaking change in
my book, which does not seam called for in this case.

/Daniel Pettersson

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

[Suhail Singh]

Eli Zaretskii  writes:

>> From: "Suhail Singh" 
>> Date: Thu, 05 Sep 2024 10:24:54 -0400
>> 
>> 
>> I observe 100% CPU usage for several seconds when invoking dired for a
>> directory on one of the remote machines I connect to.  This doesn't seem
>> to happen for another host.  The connection to the affected host is
>> slower, and on that host the issue is worse when the directory has
>> several symlinks.
>> 
>> To reproduce via =emacs -Q=:
>> - Invoke `find-file' and connect to problematic host over ssh.
>> - Once connection is established, open dired pointing to a directory on
>>   the affected host.
>> - Observe bug: it takes _several_ seconds for the dired buffer to show.
>>   During that time, Emacs CPU usage is 100%.
>> - Once dired buffer is open, invoke `revert-buffer' and observe issue
>>   again.
>> 
>> Disabling global-font-lock-mode, makes the situation better.
>> 
>> Given that rudimentary font-locking should be possible via, simply, the
>> output of `ls --dired', it is unclear why enabling font-locking makes
>> things so much worse.  If there are some aspects of font-locking that
>> perform much worse over a slower connection, it would help if there were
>> a user configuration to disable them.
>> 
>> 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.

In related news, one thing I've observed on the affected host is that
the version of `ls' doesn't seem to yield expected output for
`ls --dired'.  Specifically, the output of `ls --dired' is the same as
the output of `ls' (i.e., `--dired' gets treated as a no-op).  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

-- 
Suhail

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

[Daniel Pettersson]

João Távora  writes:

> On Mon, Sep 2, 2024 at 12:24 PM Eli Zaretskii  wrote:
>> Thanks, but isn't the above the same as setting the car of
>> process-coding-system for the Eglot subprocesses to 'dos'?

I would think that a better place for encoding the displayed string at
the place where we are displaying the string rather then before parsing
the json.

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

/Daniel Pettersson

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

[João Távora]

On Thu, Sep 5, 2024 at 10:32 PM Daniel Pettersson
 wrote:

> 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's also a reasonable position, I guess. The line ending
convention is somewhat of a grey zone. jsonrpc.el produces
Elisp strings from JSON strings.  It could apply Emasc's
line-ending conventions.  Or maybe not, maybe you're right
and Eglot the jsonrpc.el client should do it.  Or really this
quirky server should just use \n like everyone else.

João

bug#72736: 31.0.50; ERC 5.6.1: Keep ban lists in sync

[J.P.]

v2. Only update `erc-channel-banlist' if initialized. Redo shared hook
mechanism for buffer truncation.

"J.P."  writes:

> Both for clarity and compatibility with the current behavior, I think we
> should instead keep `erc-channel-banlist' empty (and locally unbound)
> until formally initialized for a given channel within an ERC session. An
> easy way to do that would be to guard the above like so:
>
>   (when erc--channel-banlist-synchronized-p
> (erc--banlist-update state arg))

I've done this in the latest set of patches (attached).

I've also tacked on a reworking of the rather awkward hook mechanism by
which modules can run code prior to a buffer's truncation. This was
previously handled by the abnormal hook `erc--pre-clear-functions',
which was run by both the `truncate' module and the `erc-cmd-CLEAR'
slash command. Part of this overhaul involved deferring most of the code
that formerly ran on `erc-insert-done-hook' to a per-response, ephemeral
`erc-timing-hook' member.

The main reason for this move is to escape the insertion related context
imposed on such hooks by response-handling code further back in the call
stack. We're not inserting anything, so it makes little sense to abuse
such hooks for their side effects, which is a design flaw and a common
antipattern (though an excusable one, seeing as there's no real sensible
alternative). Regardless, deferring to a known call site over a limited
extent via `erc-timer-hook' seems far more predictable and manageable
than relying on `run-at-time' or similar.

>From 5297613ac24bfbee5ed43f01875c08c147b7f618 Mon Sep 17 00:00:00 2001
From: "F. Jason Park" 
Date: Thu, 5 Sep 2024 14:22:11 -0700
Subject: [PATCH 0/6] *** NOT A PATCH ***

*** BLURB HERE ***

F. Jason Park (6):
  [5.6.1] ; Rename internal variable in erc-fill
  [5.6.1] Store one string per user in erc--spkr msg prop
  [5.6.1] Bind current erc-response around all handlers
  [5.6.1] Fix inconsistent handling of ban lists in ERC
  [5.6.1] Fix overlooked case in erc--get-inserted-msg-beg-at
  [5.6.1] Redo ERC truncation and /CLEAR hook mechanism

 etc/ERC-NEWS  |   9 +
 lisp/erc/erc-backend.el   |  10 +-
 lisp/erc/erc-fill.el  |  14 +-
 lisp/erc/erc-log.el   |  10 +-
 lisp/erc/erc-pcomplete.el |   8 +
 lisp/erc/erc-stamp.el | 101 --
 lisp/erc/erc-truncate.el  | 103 +++---
 lisp/erc/erc.el   | 299 ++
 test/lisp/erc/erc-fill-tests.el   |   2 +-
 test/lisp/erc/erc-goodies-tests.el|   5 +
 test/lisp/erc/erc-scenarios-log.el|  22 +-
 test/lisp/erc/erc-tests.el|  94 +-
 .../erc/resources/erc-scenarios-common.el |   2 +-
 test/lisp/erc/resources/erc-tests-common.el   |  16 +-
 14 files changed, 474 insertions(+), 221 deletions(-)

Interdiff:
diff --git a/etc/ERC-NEWS b/etc/ERC-NEWS
index 5dd72e6f1b3..0b5385f0589 100644
--- a/etc/ERC-NEWS
+++ b/etc/ERC-NEWS
@@ -17,7 +17,7 @@ GNU Emacs since Emacs version 22.1.
 ** Reliable library access for ban lists.
 Say goodbye to continually running "/BANLIST" for programmatic
 purposes.  Modules can instead use the function 'erc-sync-banlist' to
-guarantee that the variable 'erc-channel-banlist' remain synced for
+guarantee that the variable 'erc-channel-banlist' remains synced for
 the remainder of an IRC session.
 
 
diff --git a/lisp/erc/erc-fill.el b/lisp/erc/erc-fill.el
index fa9d2071ccd..6f3d51f6937 100644
--- a/lisp/erc/erc-fill.el
+++ b/lisp/erc/erc-fill.el
@@ -547,6 +547,8 @@ fill-wrap
(when erc-fill-wrap-merge
  (add-hook 'erc-button--prev-next-predicate-functions
#'erc-fill--wrap-merged-button-p nil t))
+   (add-function :after (local 'erc--clear-function)
+ #'erc-stamp--redo-right-stamp-post-clear '((depth . 50)))
(erc-stamp--display-margin-mode +1)
(visual-line-mode +1))
   ((visual-line-mode -1)
@@ -557,6 +559,8 @@ fill-wrap
(kill-local-variable 'erc-fill--wrap-last-msg)
(kill-local-variable 'erc--inhibit-prompt-display-property-p)
(kill-local-variable 'erc-fill--wrap-merge-indicator-pre)
+   (remove-function (local 'erc--clear-function)
+#'erc-stamp--redo-right-stamp-post-clear)
(remove-hook 'erc--refresh-prompt-hook
 #'erc-fill--wrap-indent-prompt t)
(remove-hook 'erc-button--prev-next-predicate-functions
diff --git a/lisp/erc/erc-log.el b/lisp/erc/erc-log.el
index 66420662c23..6bb240f56d7 100644
--- a/lisp/erc/erc-log.el
+++ b/lisp/erc/erc-log.el
@@ -231,7 +231,7 @@ log
(add-hook 'erc-part-hook #'erc-conditional-save-buffer)
;; append, so that 'erc-initialize-log-marker runs first
(add-hook 'erc-connect-pre-hook #'erc-log-setup-logging 'append)
-   (add-hook 'erc--pre-clear-functions #'erc-save-buffer-in-logs 50)
+   ;; FIXME use proper local "setup" function an

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" ,  73...@debbugs.gnu.org
> Date: Thu, 05 Sep 2024 17:04:23 -0400
> 
> Eli Zaretskii  writes:
> 
> >> 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.

> In related news, one thing I've observed on the affected host is that
> the version of `ls' doesn't seem to yield expected output for
> `ls --dired'.  Specifically, the output of `ls --dired' is the same as
> the output of `ls' (i.e., `--dired' gets treated as a no-op).

This could indeed explain the problem.  However, ...

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

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

[Eli Zaretskii]

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

bug#73049: 29.4; tab-line-mode unuseful docstring

[Thierry Volpiatto]

Eli Zaretskii  writes:

>> From: Thierry Volpiatto 
>> Date: Thu, 05 Sep 2024 16:40:43 +
>> 
>> 
>> What tab-line-mode is supposed to do?
>> 
>> "Toggle display of tab line in the windows displaying the current buffer."
>> 
>> I couldn't figure what is a "tab line".
>> 
>> Could it be explained in docstring?
>
> Thanks, done.

Thanks.

-- 
Thierry


signature.asc
Description: PGP signature