bug#73206: 28.2; xml comment with blank lines to do not indent correctly, nxml-mode.el

[Robert Pluim]

> On Thu, 12 Sep 2024 13:53:26 -0400, John Ciolfi via "Bug reports for GNU 
> Emacs, the Swiss army knife of text editors"  said:

John> 1. Create foo.xml containing:

John> 
John>  
John> 

John> Notice that we have a blank line in the xml comment.

John> 2. Put the point on 'bar' and press TAB.

John> Notice that the 'bar' line is not indented correctly.

John> Solution
John> 

John> The problem is that in nxml-compute-indent-in-delimited-token, there
John> is a (forward-line -1) which assumes that the prior line is indented. 
In
John> this case the prior line is a blank line and thus doesn't have
John> indentation. After the (forward-line -1), we need to keep going back
John> until we see a non-blank line:

John>  (forward-line -1)
John> +   (while (looking-at "^[:blank:]*$")
John> +  (forward-line -1))
 
John> Attached is a patch for nxml-mode.el that fixes the issue. 

Your patch does the right thing, but for the wrong reasons. Regexp
character classes only have meaning with a bracket expression, so what
youʼre matching here is actually any lines containing zero or more of
':', 'b', 'l', 'a', 'n', or 'k'. IOW, you should use:

 (looking-at "^[[:blank:]]*$")

Robert
-- 

bug#73217: 30.0.91; etc/ORG-NEWS typo

[Robert Pluim]

tags 73217 fixed
close 73217 30.1
quit

> On Thu, 12 Sep 2024 20:51:29 -0700, Mike Kupfer  said:

>> Previously, all the image previews where always left-aligned.
Mike> "where" should be "were".

Mike> mike

Thanks, fixed.

Closing.
Committed as 79f68597aba

Robert
-- 

bug#73205: 30.0.91; Failed test: uniquify-project-transform at lisp/uniquify-tests.el:130

[Mattias Engdegård]

13 sep. 2024 kl. 08.25 skrev Eli Zaretskii :

>> FAILED  uniquify-project-transform

Looks like it fails because there is no current project in a tree that isn't 
under version control.
I added a gate. Spencer, feel free to change if you want something fancier, but 
I don't think we really need full coverage for non-Git trees.

bug#73205: 30.0.91; Failed test: uniquify-project-transform at lisp/uniquify-tests.el:130

[Eli Zaretskii]

> From: "Mattias Engdegård" 
> Date: Fri, 13 Sep 2024 12:20:14 +0200
> Cc: "N. Jackson" ,
>  Spencer Baugh ,
>  73...@debbugs.gnu.org
> 
> 13 sep. 2024 kl. 08.25 skrev Eli Zaretskii :
> 
> >> FAILED  uniquify-project-transform
> 
> Looks like it fails because there is no current project in a tree that isn't 
> under version control.
> I added a gate. Spencer, feel free to change if you want something fancier, 
> but I don't think we really need full coverage for non-Git trees.

>From my POV, skipping this test if not in a Git checkout is fine.

Thanks.

bug#73225: Repeating tags-search from the start doesn't work

[Roger Sewell]

Package: emacs

I'm using emacs 1:27.2-10.el9_4 on Rocky Linux 9.4, which I realise is
not the latest available version of emacs but is the latest package
available for this distro.

If I put two files in a directory, each containing multiple occurrences
of foo-bar, run etags on them, and run tags-search for foo-bar, then the
first time it correctly goes through every occurrence in both files.

If I then repeat the tags-search for foo-bar, this time it only takes me
to the LAST occurrence in each file.

It makes no difference if I run tags-reset-tags-tables before the second
search, nor if I tags-search for some other string that is found in a
third file.

Moreover, if after having done the first search I search for some other
string found in one of the first two files, then instead of taking me to
that other string, it takes me to the last occurrence of foo-bar.

If you need any further information please let me know. 

If there is a workaround available, I'd be grateful to be told that also.

Thanks,
Roger Sewell.

bug#72359: treesit-node-at-point bug on vhdl-ts-mode after update to 0.22.6

[Gonzalo Larumbe]

Thanks a lot! :)

El lun, 2 sept 2024 a las 19:59, Yuan Fu () escribió:

>
>
> > On Aug 29, 2024, at 5:07 AM, Eli Zaretskii  wrote:
> >
> >> Cc: 72...@debbugs.gnu.org
> >> From: Yuan Fu 
> >> Date: Tue, 27 Aug 2024 01:22:42 -0700
> >>
> >> Thank you for your report, Gonzalo! And sorry for the delay. I properly
> looked into this today, and confirmed that this is a tree-sitter bug. I
> raised an issue here:
> https://github.com/tree-sitter/tree-sitter/issues/3555
> >>
> >> Sadly, there’s not much we can do right now. There was another similar
> bug in tree-sitter, which I worked around by using another function. But
> now that “another function” is also broken, oh well :-(
> >
> > Since this is not an Emacs bug, I'm closing it.
>
> FYI tree-sitter devs have fixed the bug:
> https://github.com/tree-sitter/tree-sitter/issues/3555
>
> Yuan

bug#73225: Repeating tags-search from the start doesn't work

[Eli Zaretskii]

> From: Roger Sewell 
> Date: Fri, 13 Sep 2024 10:15:21 +0100
> 
> Package: emacs
> 
> I'm using emacs 1:27.2-10.el9_4 on Rocky Linux 9.4, which I realise is
> not the latest available version of emacs but is the latest package
> available for this distro.
> 
> If I put two files in a directory, each containing multiple occurrences
> of foo-bar, run etags on them, and run tags-search for foo-bar, then the
> first time it correctly goes through every occurrence in both files.
> 
> If I then repeat the tags-search for foo-bar, this time it only takes me
> to the LAST occurrence in each file.

Could you please post the files which can be used to reproduce this
issue?  It is otherwise hard to investigate this problem, since you
didn't even say in what programming language were the source files
written (tags-search and etags support quite a few of them, and each
one might present unique problems).

Thanks.

bug#68914: Windows makes Emacs choke on and swallow the WIN keys

[Raffael Stocker]

Raffael Stocker  writes:

> this is a weird one (and long, apologies).  On MS Windows, it sometimes
> happens that a windows key gets stuck, that is, it remains (logically)
> pressed down, and this behaviour is correlated with Emacs use.  A
> colleague and I are seeing this on two installations with Emacs 28.2 and
> 29.2 on Windows 10 and 11.  Unfortunately, this is somewhat random and
> we have not found a way to trigger it directly.
> [...]
> We have had good results with increasing the ‘LowLevelHooksTimeout’, but
> we had to set it to the maximum value of 1000 ms.  I am not sure about
> the default value; the internet claims it to be 200 ms.

I believe I can now provide an update here.  The last few (2...3) months
we have been running Emacs 30 on two machines, with
‘LowLevelHooksTimeout’ set to 10 (to more easily trigger this bug).  In
this time, we have not seen the bug at all.

To confirm that this is connected to the Emacs version we were running,
my colleague has now used Emacs 29.2 for a couple of days.  And lo and
behold, on the second day, the bug re-surfaced: she pressed the windows
key in Emacs, then changed to some other program and there it was.

So, it seems we can be reasonably confident that something in Emacs 30
fixed this bug.  Perhaps it was the WTS_SESSION fix after all (although
then I don't understand how), or it was something else.

I don't know whether this qualifies as good enough to close this issue,
but I suspect we might not be seeing this bug again.

Regards,
Raffael

bug#68914: Windows makes Emacs choke on and swallow the WIN keys

[Eli Zaretskii]

> From: Raffael Stocker 
> Cc: Eli Zaretskii 
> Date: Fri, 13 Sep 2024 15:26:21 +0200
> 
> Raffael Stocker  writes:
> 
> > this is a weird one (and long, apologies).  On MS Windows, it sometimes
> > happens that a windows key gets stuck, that is, it remains (logically)
> > pressed down, and this behaviour is correlated with Emacs use.  A
> > colleague and I are seeing this on two installations with Emacs 28.2 and
> > 29.2 on Windows 10 and 11.  Unfortunately, this is somewhat random and
> > we have not found a way to trigger it directly.
> > [...]
> > We have had good results with increasing the ‘LowLevelHooksTimeout’, but
> > we had to set it to the maximum value of 1000 ms.  I am not sure about
> > the default value; the internet claims it to be 200 ms.
> 
> I believe I can now provide an update here.  The last few (2...3) months
> we have been running Emacs 30 on two machines, with
> ‘LowLevelHooksTimeout’ set to 10 (to more easily trigger this bug).  In
> this time, we have not seen the bug at all.
> 
> To confirm that this is connected to the Emacs version we were running,
> my colleague has now used Emacs 29.2 for a couple of days.  And lo and
> behold, on the second day, the bug re-surfaced: she pressed the windows
> key in Emacs, then changed to some other program and there it was.
> 
> So, it seems we can be reasonably confident that something in Emacs 30
> fixed this bug.  Perhaps it was the WTS_SESSION fix after all (although
> then I don't understand how), or it was something else.
> 
> I don't know whether this qualifies as good enough to close this issue,
> but I suspect we might not be seeing this bug again.

Thanks, I will soon close this bug if no further comments are posted.

bug#73098: setopt float warning unexpected

[Ship Mints]

Happy for the thoughtful feedback.

Perhaps, some expanded advice in the docstring for setopt?

"Set VARIABLE/VALUE pairs with enforced types, and return the final VALUE.

This is like setq, but is meant for user options instead of
plain variables.  This means that setopt will execute any
custom-set form associated with VARIABLE, and strictly ensure
that VALUE is of the type declared by the user option.

Example: If the user option is declared to accept a `float',
set the option to 2.0, not to 2 which is considered an `integer'.

Note: Many user options accept more complex types than a scalar
float and that may pose a challenge to address when setting them
in elisp using setopt.

If you encounter a discrepancy that cannot be addressed by amending
the type specified by a setopt call, and you can deem the desired
type compatible nonetheless, use setq. If the user option has an
associated \"setter\" you may invoke it manually using ???"

Then there's the twist that some options force content checks, not just
type checks. An example of a user option that is intended to be overridden
with custom entries is tab-bar-format. The setopt type checker will barf on
entries not strictly in the tab-bar-format pre-populated list despite the
type being a normal hook.


On Wed, Sep 11, 2024 at 6:53 PM Stefan Kangas 
wrote:

> Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of
> text editors"  writes:
>
> > I tend to agree.  If the type doesn't accept the value, you can use
> > something lower-level than `setopt`, while you argue with the maintainer
> > to try and get them to change their type.
> >
> > IMO, the whole point of `setopt` is to check the value against the type.
>
> +1
>

bug#73098: setopt float warning unexpected

[Eli Zaretskii]

> From: Ship Mints 
> Date: Fri, 13 Sep 2024 11:11:18 -0400
> Cc: Stefan Monnier , Eli Zaretskii , 
>   Michael Heerdegen , 73...@debbugs.gnu.org
> 
> Perhaps, some expanded advice in the docstring for setopt?
> 
> "Set VARIABLE/VALUE pairs with enforced types, and return the final VALUE.

"Enforce" is inaccurate, since a value that doesn't match :type just
emits a warning (which can be shut up by the users, if they want), it
doesn't signal an error.  And the variable is assigned the value event
if the type doesn't match.

bug#73225: Repeating tags-search from the start doesn't work

[Roger Sewell]

Eli,

> Could you please post the files which can be used to reproduce this
> issue?  It is otherwise hard to investigate this problem, since you
> didn't even say in what programming language were the source files
> written (tags-search and etags support quite a few of them, and each
> one might present unique problems).

These particular files are just text files, created to be as simple as
possible while still demonstrating the bug. But I originally noticed it
using Matlab code, but without any special Matlab mode enabled in emacs,
just text mode.

Thanks,
Roger.



tempdir.tar.gz
Description: tempdir.tar.gz

bug#73231: 30.0.91; image-dired cannot be operated until all thumbnails are created (MS-Windows)

[AKIYAMA Kouhei]

When using image-dired without ImageMagick or GraphicsMagick
available, operations could not be performed until all thumbnails had
been created.

* Steps to reproduce

 1. Open a command prompt (cmd.exe)
 2. wget 
https://alpha.gnu.org/gnu/emacs/pretest/windows/emacs-30/emacs-30.0.91.zip
 3. unzip emacs-30.0.91.zip
 4. set PATH=c:\Windows\system32
(Make sure ImageMagick is not included)
 5. .\bin\emacs -Q --init-directory=%CD%\.emacs.d
(Start with a brand new .emacs.d)
 6. C-x C-f  RET
( contains 247 jpg files)
 7. M-x image-dired RET RET
 8. After 36 seconds, the *image-dired* buffer is open with all
thumbnails converted.

(The aspect ratio of the image will be ignored and it will not be
rotated correctly, but that's a separate issue.)

Let me compare it with my previous setup. I'm using MSYS2's magick.exe.

 9. C-x C-c
(exit emacs)
 10. rmdir /S .emacs.d
 (Remove thumbnails)
 11. .\bin\emacs -Q --init-directory=%CD%\.emacs.d
 12. (setq image-dired-cmd-create-thumbnail-program
   "c:/msys64/ucrt64/bin/magick.exe"
   image-dired-cmd-create-thumbnail-options
   '("convert" "-auto-orient" "-define" "jpeg:size=%wx%h" "-size" "%wx%h"
 "%f[0]" "-resize" "%wx%h>" "-strip" "jpeg:%t"))
 13. C-x C-f  RET
 14. M-x image-dired RET RET
 15. After 5 seconds the *image-dired* buffer is opened. Only the first
 few thumbnails have been converted.
 16. After 19 seconds (from start) all thumbnails have been converted
 and displayed.

* Cause:

The cause is the image-dired-thumb-queue-run function and the
image-dired-create-thumb function that calls it.

The image-dired-create-thumb function executes
image-dired-thumb-queue-run with a delay using (run-at-time 0 nil
#'image-dired-thumb-queue-run). Later, image-dired-thumb-queue-run is
called all at once in succession.

In the latter half of the image-dired-thumb-queue-run function,
image-dired-create-thumb-2 is executed with a delay using
(run-with-timer 0.05 nil #'image-dired-create-thumb-2 orig-file
thumb-file). There is no limit to the number of timers, so a new timer
is added even if one has already been scheduled. Therefore, all
thumbnails are created continuously and without interruption. The
number of seconds, 0.05, is not very meaningful.

(I apologize if these behaviors were intended)

* Solution:

You can achieve a similar behavior by limiting the number of images
when using the image-dired-create-thumb-2 function.

I tried modifying the latter half of the image-dired-thumb-queue-run
function as follows and tested it again.

;; We are on MS-Windows with ImageMagick/GraphicsMagick, and need to
;; generate thumbnails by our lonesome selves.
(while (and image-dired-queue
(< image-dired-queue-active-jobs 1))
  (cl-incf image-dired-queue-active-jobs)
  (let* ((job (pop image-dired-queue))
 (orig-file (car job))
 (thumb-file (cadr job)))
(run-with-timer 0.00 nil
(lambda (a b)
  (cl-decf image-dired-queue-active-jobs)
  (image-dired-create-thumb-2 a b))
orig-file thumb-file)))

As a result, the *image-dired* buffer appeared after 17 seconds, and
all thumbnails were created after 34 seconds.

The performance has dropped, but this is because
image-dired--probe-thumbnail-cmd is slow.  So I set it as follows to
avoid matching "convert", and avoided the slow check process.

  (setq image-dired-cmd-create-thumbnail-program "")

I tested it again, and the *image-dired* buffer appeared after 5
seconds, and all thumbnails were created after 7 seconds. This was
faster than when I used the magick command (despite running it in
multiple processes), and I got very good results.  I think it's better
not to call image-dired--probe-thumbnail-cmd too frequently.


Recently, I have been increasingly using image-dired for organizing my
photos. I look forward to seeing how image-dired continues to
evolve. Thank you.
---
In GNU Emacs 30.0.91 (build 2, x86_64-w64-mingw32) of 2024-09-12 built
 on AVALON
Windowing system distributor 'Microsoft Corp.', version 10.0.19045
System Description: Microsoft Windows 10 Enterprise (v10.0.2009.19045.4894)

Configured using:
 'configure --with-modules --without-dbus --with-native-compilation=aot
 --without-compress-install --with-tree-sitter
 --enable-checking=yes,glyphs 'CFLAGS=-O0 -g3''

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

(NATIVE_COMP present but libgccjit not available)

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

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-nam

bug#73218: [PATCH] Fix Fortran indent below do_not_a_loop=42

[Ken Mankoff]

Hi Eli,

On 2024-09-12 at 23:16 -07, Eli Zaretskii  wrote...
>> --- a/lisp/progmodes/fortran.el
>> +++ b/lisp/progmodes/fortran.el
>> @@ -1631,7 +1631,7 @@ fortran-calculate-indent
>> (setq icol (+ icol fortran-if-indent)))
>>((looking-at "where[ \t]*(.*)[ \t]*\n")
>> (setq icol (+ icol fortran-if-indent)))
>> -  ((looking-at "do\\b")
>> +  ((looking-at "do[\\ |0-9]+.*=[\\ a-z0-9_]*,[\\ a-z0-9_]*")
>
> What do you intend with the likes of "[\\ |0-9]+" ?  Is this a
> character alternative, or is that an alternative of matches?  If the
> former, there's no need to escape a backslash, but then why is '|'
> there?

I agree the '|' is not needed. I'm not sure what 'character alternative' or 
'alternative of matches' means. I meant the '|' as an "OR" (is that an 
alterntative?), but realize now it is not needed. I now suggest

"do[\\ 0-9]+.*=[\\ a-z0-9_]*,[\\ a-z0-9_]*"

The pattern attempts to match "do", then either (space, numbers, or nothing), 
then equal sign, then something that looks like two numbers or valid variable 
names separated by a comma. I used these as tests:

  do42I=1,42 ! match
  do_foo = bar()
  do i = 1,42 ! match
  do i = 1,n ! match
  do i_var = a_var,b_var ! match
  do i_var5 = a_var,b_var ! match
  do42i_var = a_var,b_var ! match
  DO42 = [1,2]
  DO6I=5 7
  DO6I=5,7  ! match
  do_not_loop = [a,b]
  donot_loop = (/4,5/)
  donotloop = 42
  do_notloop = 42

Should I submit an updated patch? Or is the patch applier able to make this 
small change?

Thanks,

  -k.

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

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

Jake Nelson  writes:

Hi Jake,

> I had to revert 652a8a0838b38a6eab85c55fc61cedd1c61ef20f
>
> I could load a remote file with via tramp, but attempting to edit the
> file spiked to 100% cpu usage and I had to C-g to recover.

Could you, pls, reenable 652a8a0838b38a6eab85c55fc61cedd1c61ef20f
temporarily? Then recompile Emacs, and run

--8<---cut here---start->8---
# emacs -Q -l tramp --eval '(setq tramp-verbose 10)' 
/ssh:some-host:/etc/somedir/file.yaml
--8<---cut here---end--->8---

Try to edit the file. When the problem appears, return control by
C-g. Show the resulting *debug tramp/ssh some-host* buffer. Likely, it
is large; you could send it to me directly.

> Thanks,
> Jake

Best regards, Michael.

bug#73232: [PATCH] Allow vc-diff to suggest a default revision in vc-dir

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

Tags: patch


C-u M-x vc-root-diff will prompt for the old revision to use for the
diff.  The prompt will have a default calculated by
vc-diff-build-argument-list-internal.  The default is either the
working revision of the current fileset or the revision before that.

vc-diff-build-argument-list-internal contained a check (added in
c0d66cb21bac57f5ec0378e8a04aac8f35c3eb5c) which explicitly avoided
setting a default if the current fileset was a directory.  This check
was added in 1997 when vc only worked for single files.

This prevents a backend from choosing to return a non-nil value from
'working-revision when passed a directory.  (The vc-hg and vc-git
backends, at least, will do this)

Allow this by moving the file-directory-p check, so that we try
calling 'working-revision when the fileset is a single directory.  The
call is in inside ignore-errors, so if a backend errors when passed a
directory, we'll just get no default, as before.  (Most backends will
just return nil for a directory, rather than erroring)

Also, while we're here, explicitly pass the backend to
vc-working-revision rather than having vc-working-revision recompute
it.

Concretely this has the effect that for the vc-git and vc-hg backends,
running C-u M-x vc-root-diff in vc-dir will have the same behavior as
running C-u M-x vc-root-diff in a clean file: The "Previous revision:"
prompt's default will be the revision before HEAD.

* lisp/vc/vc.el (vc-diff-build-argument-list-internal): Move
file-directory-p check.

In GNU Emacs 29.2.50 (build 17, x86_64-pc-linux-gnu, X toolkit, cairo
 version 1.15.12, Xaw scroll bars) of 2024-09-06 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 e57db4d91cf098d26c8c131d715ef3619466d159 Mon Sep 17 00:00:00 2001
From: Spencer Baugh 
Date: Fri, 13 Sep 2024 11:34:55 -0400
Subject: [PATCH] Allow vc-diff to suggest a default revision in vc-dir

C-u M-x vc-root-diff will prompt for the old revision to use for the
diff.  The prompt will have a default calculated by
vc-diff-build-argument-list-internal.  The default is either the
working revision of the current fileset or the revision before that.

vc-diff-build-argument-list-internal contained a check (added in
c0d66cb21bac57f5ec0378e8a04aac8f35c3eb5c) which explicitly avoided
setting a default if the current fileset was a single directory.  This
check was added in 1997 when vc only worked for single files.

This prevents a backend from choosing to return a non-nil value from
'working-revision when passed a directory.  (The vc-hg and vc-git
backends, at least, will do this)

Allow this by moving the file-directory-p check, so that we try
calling 'working-revision when the fileset is a single directory.  The
call is in inside ignore-errors, so if a backend errors when passed a
directory, we'll just get no default, as before.  (Most backends will
just return nil for a directory, rather than erroring)

Also, while we're here, explicitly pass the backend to
vc-working-revision rather than having vc-working-revision recompute
it.

Concretely this has the effect that for the vc-git and vc-hg backends,
running C-u M-x vc-root-diff in vc-dir will have the same behavior as
running C-u M-x vc-root-diff in a clean file: The "Previous revision:"
prompt's default will be the revision before HEAD.

* lisp/vc/vc.el (vc-diff-build-argument-list-internal): Move
file-directory-p check.
---
 lisp/vc/vc.el | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/lisp/vc/vc.el b/lisp/vc/vc.el
index 597a1622f5a..d88a655dc6b 100644
--- a/lisp/vc/vc.el
+++ b/lisp/vc/vc.el
@@ -2074,17 +2074,14 @@ vc-diff-build-argument-list-internal
  ;; filesets, but not yet.
  ((/= (length files) 1)
   nil)
- ;; if it's a directory, don't supply any revision default
- ((file-directory-p first)
-  nil)
  ;; if the file is not up-to-date, use working revision as older revision
- ((not (vc-up-to-date-p first))
-  (setq rev1-default (vc-working-revision first)))
+ ((not (and (file-directory-p first) (vc-up-to-date-p first)))
+  (setq rev1-default (vc-working-revision first backend)))
  ;; if the file is not locked, use last revision and current source as defaults
  (t
   (setq rev1-default (ignore-errors ;If `previous-revision' doesn't work.
(vc-call-backend backend 'previous-revision first
-(vc-working-revision first
+ 

bug#73231: 30.0.91; image-dired cannot be operated until all thumbnails are created (MS-Windows)

[Eli Zaretskii]

> From: AKIYAMA Kouhei 
> Date: Fri, 13 Sep 2024 22:07:48 +0900
> 
> When using image-dired without ImageMagick or GraphicsMagick
> available, operations could not be performed until all thumbnails had
> been created.

Thank you for your report and the research that went into it.

When you speed up the display of the buffer, don't you see in
*Messages* error messages about missing files that cannot be
displayed?  The default values of delays and timers were chosen so as
to minimize these error messages for some reasonable amounts of images
in a directory (your 274 images is way larger than what I had in
mind).

image-dired--probe-thumbnail-cmd is called frequently because the user
could install ImageMagick at some point, and I didn't feel like adding
complicated logic to allow detection of that that is cheaper.  But if
you have practical suggestions for how to make these tests more seldom
without disabling them completely, that could be a good improvement.

In general, the non-ImageMagick implementation was intended to be a
fallback, for those who cannot or will not install ImageMagick.  It is
deliberately synchronous, but I think it performs well enough to be
usable.

Granted, improvements to the code are welcome, but if they make the
redisplay error messages appear in more cases, I think such a change
would be for the worse, because users can rightfully think Emacs has a
bug.

bug#73232: [PATCH] Allow vc-diff to suggest a default revision in vc-dir

[Eli Zaretskii]

> Cc: Juri Linkov 
> Date: Fri, 13 Sep 2024 11:51:47 -0400
> From:  Spencer Baugh via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" 
> 
> - ;; if it's a directory, don't supply any revision default
> - ((file-directory-p first)
> -  nil)
>   ;; if the file is not up-to-date, use working revision as older revision
> - ((not (vc-up-to-date-p first))
> -  (setq rev1-default (vc-working-revision first)))
> + ((not (and (file-directory-p first) (vc-up-to-date-p first)))
> +  (setq rev1-default (vc-working-revision first backend)))

Doesn't this change the conditions under which we use
vc-working-revision for regular files?  Did you perhaps mean

   ((and (not (file-directory-p first)) (vc-up-to-date-p first))

instead?

bug#73232: [PATCH] Allow vc-diff to suggest a default revision in vc-dir

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

Eli Zaretskii  writes:
>> Cc: Juri Linkov 
>> Date: Fri, 13 Sep 2024 11:51:47 -0400
>> From:  Spencer Baugh via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" 
>> 
>> - ;; if it's a directory, don't supply any revision default
>> - ((file-directory-p first)
>> -  nil)
>>   ;; if the file is not up-to-date, use working revision as older 
>> revision
>> - ((not (vc-up-to-date-p first))
>> -  (setq rev1-default (vc-working-revision first)))
>> + ((not (and (file-directory-p first) (vc-up-to-date-p first)))
>> +  (setq rev1-default (vc-working-revision first backend)))
>
> Doesn't this change the conditions under which we use
> vc-working-revision for regular files?  Did you perhaps mean
>
>((and (not (file-directory-p first)) (vc-up-to-date-p first))
>
> instead?

Oops, yes, fixed.

>From f87b92ce5775d0558b7d9dd502687d1f460bcd2a Mon Sep 17 00:00:00 2001
From: Spencer Baugh 
Date: Fri, 13 Sep 2024 11:34:55 -0400
Subject: [PATCH] Allow vc-diff to suggest a default revision in vc-dir

C-u M-x vc-root-diff will prompt for the old revision to use for the
diff.  The prompt will have a default calculated by
vc-diff-build-argument-list-internal.  The default is either the
working revision of the current fileset or the revision before that.

vc-diff-build-argument-list-internal contained a check (added in
c0d66cb21bac57f5ec0378e8a04aac8f35c3eb5c) which explicitly avoided
setting a default if the current fileset was a single directory.  This
check was added in 1997 when vc only worked for single files.

This prevents a backend from choosing to return a non-nil value from
'working-revision when passed a directory.  (The vc-hg and vc-git
backends, at least, will do this)

Allow this by moving the file-directory-p check, so that we try
calling 'working-revision when the fileset is a single directory.  The
call is in inside ignore-errors, so if a backend errors when passed a
directory, we'll just get no default, as before.  (Most backends will
just return nil for a directory, rather than erroring)

Also, while we're here, explicitly pass the backend to
vc-working-revision rather than having vc-working-revision recompute
it.

Concretely this has the effect that for the vc-git and vc-hg backends,
running C-u M-x vc-root-diff in vc-dir will have the same behavior as
running C-u M-x vc-root-diff in a clean file: The "Previous revision:"
prompt's default will be the revision before HEAD.

* lisp/vc/vc.el (vc-diff-build-argument-list-internal): Move
file-directory-p check. (bug#73232)
---
 lisp/vc/vc.el | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/lisp/vc/vc.el b/lisp/vc/vc.el
index 597a1622f5a..7b1133565f9 100644
--- a/lisp/vc/vc.el
+++ b/lisp/vc/vc.el
@@ -2074,17 +2074,14 @@ vc-diff-build-argument-list-internal
  ;; filesets, but not yet.
  ((/= (length files) 1)
   nil)
- ;; if it's a directory, don't supply any revision default
- ((file-directory-p first)
-  nil)
  ;; if the file is not up-to-date, use working revision as older revision
- ((not (vc-up-to-date-p first))
-  (setq rev1-default (vc-working-revision first)))
+ ((and (not (file-directory-p first)) (not (vc-up-to-date-p first)))
+  (setq rev1-default (vc-working-revision first backend)))
  ;; if the file is not locked, use last revision and current source as defaults
  (t
   (setq rev1-default (ignore-errors ;If `previous-revision' doesn't work.
(vc-call-backend backend 'previous-revision first
-(vc-working-revision first
+(vc-working-revision first backend
   (when (string= rev1-default "") (setq rev1-default nil
 ;; construct argument list
 (let* ((rev1-prompt (format-prompt "Older revision" rev1-default))
-- 
2.39.3

bug#73098: setopt float warning unexpected

[Ship Mints]

Revised language:

"Set VARIABLE/VALUE pairs with type warnings, and return the final VALUE.

This is like setq, but is meant for user options instead of
plain variables.  This means that setopt will execute any
custom-set form associated with VARIABLE, and will emit a
warning if VALUE is not of the type expected by the user option.

Example: If the user option is declared to accept a `float',
set the option to 2.0 rather than 2, which is considered an `integer'.

Despite the warning, the user option will still be set to VALUE."

On Fri, Sep 13, 2024 at 11:28 AM Eli Zaretskii  wrote:

> > From: Ship Mints 
> > Date: Fri, 13 Sep 2024 11:11:18 -0400
> > Cc: Stefan Monnier , Eli Zaretskii <
> e...@gnu.org>,
> >   Michael Heerdegen ,
> 73...@debbugs.gnu.org
> >
> > Perhaps, some expanded advice in the docstring for setopt?
> >
> > "Set VARIABLE/VALUE pairs with enforced types, and return the final
> VALUE.
>
> "Enforce" is inaccurate, since a value that doesn't match :type just
> emits a warning (which can be shut up by the users, if they want), it
> doesn't signal an error.  And the variable is assigned the value event
> if the type doesn't match.
>

bug#73082: 30; Inconsistent Stipple Support

[JD Smith]

> On Sep 7, 2024, at 9:17 AM, JD Smith  wrote:
> 
> On Sep 7, 2024, at 2:51 AM, Po Lu  > wrote:
> I am also interested to know precisely which Cairo builds fail to
> display them, the stipple implementations being virtually identical
> across the PGTK and the X + Cairo builds.

>> The Cairo issue has been harder to track down.  Several users have reported 
>> Cairo builds which fail to display stipples.  I gather Cairo is the default 
>> so this must be a sporadic failure.  Recently a user with identical builds 
>> on two different machines, with the precise same version of GTK3 and Cairo, 
>> found that one system shows stipples correctly, the other omits them 
>> entirely.  On the non-working system, compiling --without-cairo resolves 
>> this.

Po, did any potential causes for intermittent stipple display among identical 
Cairo builds occur to you?  Anything obvious to test?

bug#73098: setopt float warning unexpected

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

> setopt will execute any custom-set form
  ^^^
> associated with VARIABLE

1. "custom-set form" isn't mentioned, let alone
   defined, in the Elisp manual.  Should this
   say "any defcustom :set function" instead?

2. What about what I suppose you would call a
   "custom-init form", in other words, what the
   Elisp manual calls ":initialize function"? 

bug#73098: setopt float warning unexpected

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

> If you encounter a discrepancy that cannot be addressed by amending
> the type specified by a setopt call, and you can deem the desired
> type compatible nonetheless, use setq. If the user option has an
> associated \"setter\" you may invoke it manually using ???"

You're here trying to describe workarounds to use in case of bugs
(either the value you set is wrong, or the type (or type-checker) is
wrong).  We usually don't do that in docstrings.


Stefan

bug#73234: 30.0.91; completion-preview-mode doesn't trigger for case-insensitive capf

[Morgan Willcock]

I believe there is an issue with completion-preview-mode in that it
doesn't seem to find all completions for a case-insensitive completion
at point function.

Evaluating the code below in `emacs -Q` will put the current buffer into
fundamental mode with a case-insensitive completion at point function:

  (defun test-completion-at-point-function ()
"Complete the symbol at point."
(pcase (bounds-of-thing-at-point 'symbol)
  (`(,beg . ,end)
   (list beg end
 (completion-table-case-fold
  (completion-table-dynamic
   (lambda (string)
 (list "TestSymbol"

  (fundamental-mode)
  (remove-hook 'completion-at-point-functions 
#'tags-completion-at-point-function)
  (add-hook 'completion-at-point-functions #'test-completion-at-point-function)
  (completion-preview-mode 1)

Once the code is evaluated:

- Typing "tes" into the buffer will not display the completion preview.

- The default completion mechanism (as initiated with complete-symbol
  via C-M-i) will work with no problems, and replace "tes" with the
  completion "TestSymbol".

- Typing "Tes" into the buffer will display the completion preview.

I would expect that the completion preview should be displayed for both
"tes" and "Tes" since a completion is available to use in both cases.



In GNU Emacs 30.0.91 (build 2, x86_64-pc-linux-gnu, X toolkit, cairo
 version 1.16.0, Xaw3d scroll bars) of 2024-09-12 built on inspiron
Windowing system distributor 'The X.Org Foundation', version 11.0.12101007
System Description: Debian GNU/Linux 12 (bookworm)

Configured using:
 'configure --with-native-compilation=aot --with-xml2
 --with-x-toolkit=lucid'

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

Important settings:
  value of $LANG: en_GB.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: ELisp/d

Minor modes in effect:
  server-mode: t
  global-corfu-mode: t
  corfu-mode: t
  jabber-activity-mode: t
  etags-regen-mode: t
  which-key-mode: t
  global-devil-mode: t
  devil-mode: t
  erc-ring-mode: t
  erc-netsplit-mode: t
  erc-menu-mode: t
  erc-list-mode: t
  erc-irccontrols-mode: t
  erc-move-to-prompt-mode: t
  erc-readonly-mode: t
  erc-imenu-mode: t
  erc-button-mode: t
  erc-fill-mode: t
  erc-stamp-mode: t
  erc-spelling-mode: t
  erc-track-mode: t
  erc-match-mode: t
  erc-autojoin-mode: t
  erc-networks-mode: t
  savehist-mode: t
  minibuffer-electric-default-mode: t
  minibuffer-depth-indicate-mode: t
  ido-everywhere: t
  recentf-mode: t
  global-display-fill-column-indicator-mode: t
  display-fill-column-indicator-mode: t
  global-hl-line-mode: t
  display-time-mode: t
  flyspell-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  minibuffer-regexp-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
/home/mwillcock/.emacs.d/custom/powershell.el/powershell hides 
/home/mwillcock/.emacs.d/custom/powershell
/home/mwillcock/.emacs.d/elpa/which-key-3.6.1/which-key hides 
/usr/local/share/emacs/30.0.91/lisp/which-key
/home/mwillcock/.emacs.d/elpa/modus-themes-4.5.0/theme-loaddefs hides 
/usr/local/share/emacs/30.0.91/lisp/theme-loaddefs

Features:
(shadow sort ecomplete mail-extr emacsbug cursor-sensor server cal-iso
autorevert face-remap init corfu sly sly-completion sly-buttons
sly-messages sly-common apropos etags fileloop arc-mode archive-mode
hyperspec powershell php-mode mode-local consult-imenu consult php-face
php php-project jabber jabber-ourversion hippie-exp hexrgb fsm sgml-mode
facemenu srv dns starttls tls goto-addr yaml-mode markdown-mode lua-mode
advice edmacro kmacro etags-regen kixtart-docstrings cape kixtart-mode
tempo org-msg let-alist color ox-odt rng-loc rng-uri rng-parse rng-match
rng-dt rng-util rng-pttrn nxml-parse nxml-ns nxml-enc xmltok nxml-util
ox-latex ox-icalendar ox-html table ox-ascii ox-publish ox org-attach
htmlize gnus-msg gnus-icalendar icalendar gnus-dired gnus-cite which-key
devil delight comp comp-cstr ags-mode speedbar ezimage dframe shadowfile
eglot jsonrpc xref flymake diff ert ewoc debug backtrace warnings python
project cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align
cc-engine cc-vars cc-defs erc-ring erc-netsplit erc-menu erc-list
erc-goodies erc-imenu imenu erc-pcomplete erc-button erc-fill erc-stamp
erc-sasl erc-sasl-ecdsa-nist256p-challenge erc-sasl-scram-sha-512
erc-sasl-scram-sha-256 erc-sasl-scram-sha-1 erc-sasl-external
erc-sasl-plain sasl-scram-sha256 sasl-scram-rfc sasl-

bug#73098: setopt float warning unexpected

[Ship Mints]

It was removed in a later proposed edit. I read the setopt code more deeply
and ran some tests.

On Fri, Sep 13, 2024 at 3:09 PM Stefan Monnier 
wrote:

> > If you encounter a discrepancy that cannot be addressed by amending
> > the type specified by a setopt call, and you can deem the desired
> > type compatible nonetheless, use setq. If the user option has an
> > associated \"setter\" you may invoke it manually using ???"
>
> You're here trying to describe workarounds to use in case of bugs
> (either the value you set is wrong, or the type (or type-checker) is
> wrong).  We usually don't do that in docstrings.
>
>
> Stefan
>
>

bug#73098: setopt float warning unexpected

[Ship Mints]

The warning messages can be misleading. e.g., when trying to set
tab-bar-format-tabs-groups to include a simple lambda, it complains about
the wrong thing. It does match the hook type, but does not match the
hard-coded list of options.

   (setopt tab-bar-format
   `(
 tab-bar-format-tabs-groups
 (lambda () " ") ; tab-bar-separator
))

 ■  Warning (emacs): Value '(nil tab-bar-format-tabs-groups (lambda nil "
"))' does not match type hook

On Fri, Sep 13, 2024 at 3:26 PM Ship Mints  wrote:

> It was removed in a later proposed edit. I read the setopt code more
> deeply and ran some tests.
>
> On Fri, Sep 13, 2024 at 3:09 PM Stefan Monnier 
> wrote:
>
>> > If you encounter a discrepancy that cannot be addressed by amending
>> > the type specified by a setopt call, and you can deem the desired
>> > type compatible nonetheless, use setq. If the user option has an
>> > associated \"setter\" you may invoke it manually using ???"
>>
>> You're here trying to describe workarounds to use in case of bugs
>> (either the value you set is wrong, or the type (or type-checker) is
>> wrong).  We usually don't do that in docstrings.
>>
>>
>> Stefan
>>
>>