* bug#66393: [PATCH] Make package-vc-install-from-checkout NAME argument optional
@ 2023-10-08 20:50 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 0 replies; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-10-08 20:50 UTC (permalink / raw)
To: Philip Kaludercic; +Cc: 66393
Philip Kaludercic <philipk@posteo.net> writes:
> Joseph Turner <joseph@breatheoutbreathe.in> writes:
>
>> Tags: patch
>>
>> The purpose of this change is to simplify the noninteractive usage of package-vc-install-from-checkout.
>>
>> From cfdd990c6e00decff370e5f224d60862c13be309 Mon Sep 17 00:00:00 2001
>> From: Joseph Turner <joseph@breatheoutbreathe.in>
>> Date: Sat, 7 Oct 2023 11:38:43 -0700
>> Subject: [PATCH] Make package-vc-install-from-checkout NAME argument optional
>>
>> * lisp/emacs-lisp/package-vc.el (package-vc-install-from-checkout):
>> Allow nil NAME; update documentation.
>> ---
>> lisp/emacs-lisp/package-vc.el | 12 +++++-------
>> 1 file changed, 5 insertions(+), 7 deletions(-)
>>
>> diff --git a/lisp/emacs-lisp/package-vc.el b/lisp/emacs-lisp/package-vc.el
>> index c7a30736e32..e47deca6d7a 100644
>> --- a/lisp/emacs-lisp/package-vc.el
>> +++ b/lisp/emacs-lisp/package-vc.el
>> @@ -841,18 +841,16 @@ for the last released version of the package."
>> (find-file directory)))
>>
>> ;;;###autoload
>> -(defun package-vc-install-from-checkout (dir name)
>> +(defun package-vc-install-from-checkout (dir &optional name)
>> "Set up the package NAME in DIR by linking it into the ELPA directory.
>> +NAME defaults to the base name of DIR.
>> Interactively, prompt the user for DIR, which should be a directory
>> under version control, typically one created by `package-vc-checkout'.
>> If invoked interactively with a prefix argument, prompt the user
>> -for the NAME of the package to set up. Otherwise infer the package
>> -name from the base name of DIR."
>> +for the NAME of the package to set up."
>> (interactive (let ((dir (read-directory-name "Directory: ")))
>> - (list dir
>> - (if current-prefix-arg
>> - (read-string "Package name: ")
>> - (file-name-base (directory-file-name dir))))))
>> + (list dir (when current-prefix-arg
>
> This looks fine, I'm just going to replace the `when' with a `and', ok?
Sure!
>> + (read-string "Package name: ")))))
>> (unless (vc-responsible-backend dir)
>> (user-error "Directory %S is not under version control" dir))
>> (package-vc--archives-initialize)
^ permalink raw reply [relevance 5%]
* bug#66404: [PATCH] Use delete-all-overlays in clean-mode
@ 2023-10-08 20:54 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 0 replies; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-10-08 20:54 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 66404-done, Stefan Kangas
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Joseph Turner <joseph@breatheoutbreathe.in>
>>
>> (Is there a way for me to close my own issues?)
>
> Yes, see admin/notes/bugtracker.
Thank you!! I was not aware of this.
Stefan: Please consider mentioning admin/notes/bugtracker in your talk.
Joseph
^ permalink raw reply [relevance 5%]
* bug#66403: [PATCH] Use delete-all-overlays in clean-mode
@ 2023-10-08 21:21 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 0 replies; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-10-08 21:21 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 66403
Eli Zaretskii <eliz@gnu.org> writes:
>> Date: Sun, 08 Oct 2023 02:57:25 -0700
>> From: Joseph Turner via "Bug reports for GNU Emacs,
>> the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>>
>> Is there a reason to use dolist instead of delete-all-overlays?
>
> Can the buffer be narrowed?
Ah, good catch. The following snippet only deletes ov1, whereas if you
replace the dolist with delete-all-overlays, both are deleted.
(with-current-buffer (generate-new-buffer "test-overlay-deletion")
(insert "hello\n\nworld")
(let ((ov1 (make-overlay 0 6))
(ov2 (make-overlay 8 13)))
(overlay-put ov1 'display "aaaaa")
(overlay-put ov2 'display "bbbbb"))
(narrow-to-region 1 6)
;; (delete-all-overlays)
(dolist (overlay (overlays-in (point-min) (point-max)))
(delete-overlay overlay))
(widen)
(pop-to-buffer (current-buffer)))
Joseph
^ permalink raw reply [relevance 5%]
* bug#66403: [PATCH] Use delete-all-overlays in clean-mode
@ 2023-10-08 21:24 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 0 replies; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-10-08 21:24 UTC (permalink / raw)
To: 66403-done
delete-all-overlays deletes all overlays regardless of narrowing.
^ permalink raw reply [relevance 5%]
* bug#66393: [PATCH] Make package-vc-install-from-checkout NAME argument optional
@ 2023-10-08 21:35 5% ` Philip Kaludercic
1 sibling, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-10-08 21:35 UTC (permalink / raw)
To: Joseph Turner; +Cc: 66393-done
Joseph Turner <joseph@breatheoutbreathe.in> writes:
> Tags: patch
>
> The purpose of this change is to simplify the noninteractive usage of
> package-vc-install-from-checkout.
Thanks, pushed with slight modifications.
^ permalink raw reply [relevance 5%]
* bug#65797: `buffer-match-p` should not use `func-arity`
@ 2023-10-12 4:53 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 0 replies; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-10-12 4:53 UTC (permalink / raw)
To: Stefan Monnier
Cc: Dmitry Gutov, Philip Kaludercic, Eli Zaretskii,
Mattias Engdegård, 65797
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> I am in favor of this solution as well.
>
> Then how 'bout something like the patch below which changes the
> `&optional` into an `&rest` but tries to preserve compatibility with the
> old calling convention.
>
>
> Stefan
>
>
> diff --git a/lisp/subr.el b/lisp/subr.el
> index e88815fa58c..06c9923b525 100644
> --- a/lisp/subr.el
> +++ b/lisp/subr.el
> @@ -7295,13 +7292,13 @@ string-lines
> (setq start (length string)))))
> (nreverse lines))))
>
> -(defun buffer-match-p (condition buffer-or-name &optional arg)
> +(defun buffer-match-p (condition buffer-or-name &rest args)
> "Return non-nil if BUFFER-OR-NAME matches CONDITION.
> CONDITION is either:
> - the symbol t, to always match,
> - the symbol nil, which never matches,
> - a regular expression, to match a buffer name,
> -- a predicate function that takes BUFFER-OR-NAME and ARG as
> +- a predicate function that takes BUFFER-OR-NAME plus ARGS as
> arguments, and returns non-nil if the buffer matches,
> - a cons-cell, where the car describes how to interpret the cdr.
> The car can be one of the following:
> @@ -7326,9 +7323,18 @@ buffer-match-p
> ((pred stringp)
> (string-match-p condition (buffer-name buffer)))
> ((pred functionp)
> - (if (eq 1 (cdr (func-arity condition)))
> - (funcall condition buffer-or-name)
> - (funcall condition buffer-or-name arg)))
> + (if (cdr args)
> + ;; More than 1 argument: no need for
> + ;; Emacs-29 backward compatibility!
> + (apply condition buffer-or-name args)
> + (condition-case err
> + (apply condition buffer-or-name args)
> + (wrong-number-of-arguments
> + ;; Backward compatibility with Emacs-29 semantics.
> + (message "Trying obsolete calling convention for: %S"
> + Condition)
> + (apply condition buffer-or-name
> + (if args '(nil) nil))))))
> (`(major-mode . ,mode)
> (eq
> (buffer-local-value 'major-mode buffer)
> @@ -7350,17 +7356,17 @@ buffer-match-p
> (throw 'match t)))))))
> (funcall match (list condition))))
At first, I was concerned that the condition-case would mess up error
handling in user code, but all 9 permutations give the expected results:
(let ((condition
(lambda (buf) t)
;; (lambda (buf arg1) t)
;; (lambda (buf arg1 arg2) t)
))
(condition-case err
(buffer-match-p condition (current-buffer)
;; 'arg1
;; 'arg2
)
(wrong-number-of-arguments
"Caught")))
> -(defun match-buffers (condition &optional buffers arg)
> +(defun match-buffers (condition &optional buffers &rest args)
> "Return a list of buffers that match CONDITION, or nil if none match.
> See `buffer-match-p' for various supported CONDITIONs.
> By default all buffers are checked, but the optional
> argument BUFFERS can restrict that: its value should be
> an explicit list of buffers to check.
> -Optional argument ARG is passed to `buffer-match-p', for
> +Optional arguments ARGS are passed to `buffer-match-p', for
> predicate conditions in CONDITION."
> (let (bufs)
> (dolist (buf (or buffers (buffer-list)))
> - (when (buffer-match-p condition (get-buffer buf) arg)
> + (when (apply #'buffer-match-p condition (get-buffer buf) args)
> (push buf bufs)))
> bufs))
>
^ permalink raw reply [relevance 5%]
* bug#65797: `buffer-match-p` should not use `func-arity`
@ 2023-10-14 6:13 0% ` Eli Zaretskii
0 siblings, 1 reply; 200+ results
From: Eli Zaretskii @ 2023-10-14 6:13 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 65797, dmitry, philipk, mattias.engdegard, joseph
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Joseph Turner <joseph@breatheoutbreathe.in>, Philip Kaludercic
> <philipk@posteo.net>, Mattias Engdegård
> <mattias.engdegard@gmail.com>,
> Eli Zaretskii <eliz@gnu.org>, 65797@debbugs.gnu.org
> Date: Fri, 13 Oct 2023 11:57:59 -0400
>
> >> Then how 'bout something like the patch below which changes the
> >> `&optional` into an `&rest` but tries to preserve compatibility with the
> >> old calling convention.
> > Personally, I figured that using &rest would already help with backward
> > compatibility to an extent.
>
> I don't have a good intuition for how important backward compatibility
> is here, so I went for the "safe" choice. But maybe we don't need to go
> that far. The patch below keeps the same compatibility hack as we
> currently have but doesn't add any new compatibility, so it will break
> those uses where `buffer-match-p` is called without additional args but
> the predicate function still expects 2 args (where the second is always
> nil). Indeed, that case seemes extremely unlikely.
>
> Eli, Stefan, WDYT?
TBH, I have no way of assessing the risks in such a change.
Do we have to make this change on the release branch? What bad things
will happen if we leave emacs-29 with no changes? The discussion
thread is quite long, but my personal take from it is that the
arguments for making any changes in the current code are largely
theoretical and aesthetic. Am I wrong?
^ permalink raw reply [relevance 0%]
* bug#65797: `buffer-match-p` should not use `func-arity`
@ 2023-10-16 20:16 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 0 replies; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-10-16 20:16 UTC (permalink / raw)
To: Stefan Monnier; +Cc: dmitry, Eli Zaretskii, mattias.engdegard, philipk, 65797
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> Sigh. I guess we can install this on emacs-29 and cross the
>> fingers...
>
> I'm not insisting on it.
> If you think it's risky, let's just have it on `master`.
>
> BTW, see below the actual patch, including changes to etc/NEWS, manual,
> as well as the addition of a runtime warning (without which I can't see
> how we'll ever be able to get rid of the ugly backward compatibility
> hack).
Minor nit: There's a typo in the NEWS file. "tho" should be "though".
> Stefan
>
> [2. text/x-diff; buffer-match.patch]
> diff --git a/doc/lispref/buffers.texi b/doc/lispref/buffers.texi
> index 86c47ae7310..a2d0f5687ba 100644
> --- a/doc/lispref/buffers.texi
> +++ b/doc/lispref/buffers.texi
> @@ -957,10 +957,10 @@ Buffer List
> infinite recursion.
> @end defvar
>
> -@defun buffer-match-p condition buffer-or-name &optional arg
> +@defun buffer-match-p condition buffer-or-name &rest args
> This function checks if a buffer designated by @code{buffer-or-name}
> -satisfies the specified @code{condition}. Optional third argument
> -@var{arg} is passed to the predicate function in @var{condition}. A
> +satisfies the specified @code{condition}. Optional arguments
> +@var{args} are passed to the predicate function in @var{condition}. A
> valid @var{condition} can be one of the following:
> @itemize @bullet{}
> @item
> @@ -969,23 +969,21 @@ Buffer List
> name.
> @item
> A predicate function, which should return non-@code{nil} if the buffer
> -matches. If the function expects one argument, it is called with
> -@var{buffer-or-name} as the argument; if it expects 2 arguments, the
> -first argument is @var{buffer-or-name} and the second is @var{arg}
> -(or @code{nil} if @var{arg} is omitted).
> +matches. It is called with
> +@var{buffer-or-name} as the first argument followed by @var{args}.
> @item
> A cons-cell @code{(@var{oper} . @var{expr})} where @var{oper} is one
> of
> @table @code
> @item (not @var{cond})
> Satisfied if @var{cond} doesn't satisfy @code{buffer-match-p} with
> -the same buffer and @code{arg}.
> +the same buffer and @code{args}.
> @item (or @var{conds}@dots{})
> Satisfied if @emph{any} condition in @var{conds} satisfies
> -@code{buffer-match-p}, with the same buffer and @code{arg}.
> +@code{buffer-match-p}, with the same buffer and @code{args}.
> @item (and @var{conds}@dots{})
> Satisfied if @emph{all} the conditions in @var{conds} satisfy
> -@code{buffer-match-p}, with the same buffer and @code{arg}.
> +@code{buffer-match-p}, with the same buffer and @code{args}.
> @item derived-mode
> Satisfied if the buffer's major mode derives from @var{expr}.
> @item major-mode
> @@ -998,14 +996,14 @@ Buffer List
> @end itemize
> @end defun
>
> -@defun match-buffers condition &optional buffer-list arg
> +@defun match-buffers condition &optional buffer-list &rest args
> This function returns a list of all buffers that satisfy the
> @code{condition}. If no buffers match, the function returns
> @code{nil}. The argument @var{condition} is as defined in
> @code{buffer-match-p} above. By default, all the buffers are
> considered, but this can be restricted via the optional argument
> @code{buffer-list}, which should be a list of buffers to consider.
> -Optional third argument @var{arg} will be passed to @var{condition} in
> +Remaining arguments @var{args} will be passed to @var{condition} in
> the same way as @code{buffer-match-p} does.
> @end defun
>
> diff --git a/etc/NEWS b/etc/NEWS
> index 3bd47a0112b..c74b4978afe 100644
> --- a/etc/NEWS
> +++ b/etc/NEWS
> @@ -945,6 +945,13 @@ the file listing's performance is still optimized.
> \f
> * Incompatible Lisp Changes in Emacs 30.1
>
> +** `buffer-match-p and `match-buffers` take `&rest args`
> +They used to take a single `&optional arg` and were documented to use
> +an unreliable hack to try and accommodate condition predicates that
> +don't accept this optional arg.
> +The new semantics makes no such affordances, tho the code still
> +supports it (with a warning) for backward compatibility.
> +
> ** 'post-gc-hook' runs after updating 'gcs-done' and 'gcs-elapsed'.
>
> ---
> diff --git a/lisp/subr.el b/lisp/subr.el
> index 58274987d71..0732319ccd0 100644
> --- a/lisp/subr.el
> +++ b/lisp/subr.el
> @@ -7277,13 +7277,15 @@ string-lines
> (setq start (length string)))))
> (nreverse lines))))
>
> -(defun buffer-match-p (condition buffer-or-name &optional arg)
> +(defvar buffer-match-p--past-warnings nil)
> +
> +(defun buffer-match-p (condition buffer-or-name &rest args)
> "Return non-nil if BUFFER-OR-NAME matches CONDITION.
> CONDITION is either:
> - the symbol t, to always match,
> - the symbol nil, which never matches,
> - a regular expression, to match a buffer name,
> -- a predicate function that takes BUFFER-OR-NAME and ARG as
> +- a predicate function that takes BUFFER-OR-NAME plus ARGS as
> arguments, and returns non-nil if the buffer matches,
> - a cons-cell, where the car describes how to interpret the cdr.
> The car can be one of the following:
> @@ -7308,9 +7310,18 @@ buffer-match-p
> ((pred stringp)
> (string-match-p condition (buffer-name buffer)))
> ((pred functionp)
> - (if (eq 1 (cdr (func-arity condition)))
> - (funcall condition buffer-or-name)
> - (funcall condition buffer-or-name arg)))
> + (if (cdr args)
> + ;; New in Emacs>29.1. no need for compatibility hack.
> + (apply condition buffer-or-name args)
> + (condition-case-unless-debug err
> + (apply condition buffer-or-name args)
> + (wrong-number-of-arguments
> + (unless (member condition
> + buffer-match-p--past-warnings)
> + (message "%s" (error-message-string err))
> + (push condition buffer-match-p--past-warnings))
> + (apply condition buffer-or-name
> + (if args nil '(nil)))))))
> (`(major-mode . ,mode)
> (eq
> (buffer-local-value 'major-mode buffer)
> @@ -7332,17 +7343,17 @@ buffer-match-p
> (throw 'match t)))))))
> (funcall match (list condition))))
>
> -(defun match-buffers (condition &optional buffers arg)
> +(defun match-buffers (condition &optional buffers &rest args)
> "Return a list of buffers that match CONDITION, or nil if none match.
> See `buffer-match-p' for various supported CONDITIONs.
> By default all buffers are checked, but the optional
> argument BUFFERS can restrict that: its value should be
> an explicit list of buffers to check.
> -Optional argument ARG is passed to `buffer-match-p', for
> +Optional arguments ARGS are passed to `buffer-match-p', for
> predicate conditions in CONDITION."
> (let (bufs)
> (dolist (buf (or buffers (buffer-list)))
> - (when (buffer-match-p condition (get-buffer buf) arg)
> + (when (apply #'buffer-match-p condition (get-buffer buf) args)
> (push buf bufs)))
> bufs))
>
> diff --git a/lisp/window.el b/lisp/window.el
> index 2f9b46ebb0a..12d3fb1dfe7 100644
> --- a/lisp/window.el
> +++ b/lisp/window.el
> @@ -7535,10 +7535,8 @@ display-buffer-alist
> arguments: a buffer to display and an alist of the same form as
> ALIST. See `display-buffer' for details.
>
> -`display-buffer' scans this alist until it either finds a
> -matching regular expression or the function specified by a
> -condition returns non-nil. In any of these cases, it adds the
> -associated action to the list of actions it will try."
> +`display-buffer' scans this alist until the CONDITION is satisfied
> +and adds the associated ACTION to the list of actions it will try."
> :type `(alist :key-type
> (choice :tag "Condition"
> regexp
^ permalink raw reply [relevance 5%]
* bug#66626: [PATCH] elpa-packages (hyperdrive): Update ':doc' property
@ 2023-10-19 5:45 11% Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-20 20:04 5% ` Stefan Kangas
0 siblings, 1 reply; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-10-19 5:45 UTC (permalink / raw)
To: 66626
[-- Attachment #1: Type: text/plain, Size: 70 bytes --]
Tags: patch
We shortened the info manual name.
Thank you!!
Joseph
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-elpa-packages-hyperdrive-Update-doc-property.patch --]
[-- Type: text/patch, Size: 738 bytes --]
From d3b91bcb42703b940551b2e0e084e423d82211b3 Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Wed, 18 Oct 2023 22:43:29 -0700
Subject: [PATCH] * * elpa-packages (hyperdrive): Update ':doc' property
---
elpa-packages | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/elpa-packages b/elpa-packages
index da7efbf6b6..0f722f7fd5 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -362,7 +362,7 @@
(hyperdrive :url "https://git.sr.ht/~ushin/hyperdrive.el"
:readme "README.md"
- :doc "doc/hyperdrive-manual.org")
+ :doc "doc/hyperdrive.org")
(idle-highlight-mode :url "https://codeberg.org/ideasman42/emacs-idle-highlight-mode"
:ignored-files (".elisp-autofmt"))
--
2.41.0
^ permalink raw reply related [relevance 11%]
* bug#66626: [PATCH] elpa-packages (hyperdrive): Update ':doc' property
2023-10-19 5:45 11% bug#66626: [PATCH] elpa-packages (hyperdrive): Update ':doc' property Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-10-20 20:04 5% ` Stefan Kangas
0 siblings, 0 replies; 200+ results
From: Stefan Kangas @ 2023-10-20 20:04 UTC (permalink / raw)
To: Joseph Turner, 66626-done
Joseph Turner via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs@gnu.org> writes:
> Tags: patch
>
> We shortened the info manual name.
Thanks, installed.
[1: e5adab3409]: 2023-10-20 22:01:55 +0200
* elpa-packages (hyperdrive): Update ':doc' property.
https://git.savannah.gnu.org/cgit/emacs/nongnu.git/commit/?id=e5adab3409abfa69ecbaeb07bb88d48f78e03d3f
^ permalink raw reply [relevance 5%]
* bug#66716: Reconcile display-fill-column-indicator-character behavior and customization description
@ 2023-10-23 21:23 10% Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-24 12:31 0% ` Eli Zaretskii
0 siblings, 1 reply; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-10-23 21:23 UTC (permalink / raw)
To: 66716
[-- Attachment #1: Type: text/plain, Size: 520 bytes --]
Tags: patch
Tags: patch
Tags: patch
AFAICT, setting display-fill-column-indicator-character to nil means
that no fill indicator is displayed. This patch changes the
customization description to match the current behavior.
However, I like the behavior that's currently described in the
customization option:
"If possible, use U+2502 to indicate fill column, otherwise use |"
What do folks think about changing the behavior of
display-fill-column-indicator-character to match this description?
Thank you!!
Joseph
[-- Attachment #2: 0001-Fix-customization-description-display-fill-column-in.patch --]
[-- Type: text/patch, Size: 1089 bytes --]
From 846252d0c3912623ba2d8ff9832e00dfa00fc091 Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Mon, 23 Oct 2023 14:20:09 -0700
Subject: [PATCH] Fix customization description:
display-fill-column-indicator-character
* lisp/cus-start.el (standard): Change the description of the nil
value to its current behavior: to not display a fill indicator.
---
lisp/cus-start.el | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lisp/cus-start.el b/lisp/cus-start.el
index 054683d7cf6..2fc5d3d727c 100644
--- a/lisp/cus-start.el
+++ b/lisp/cus-start.el
@@ -806,7 +806,7 @@ since it could result in memory overflow and make Emacs crash."
:value ?│)
(character :tag "Use | to indicate fill column"
:value ?|)
- (const :tag "If possible, use U+2502 to indicate fill column, otherwise use |"
+ (const :tag "Do not indicate fill column"
:value nil)
character)
"27.1"
--
2.41.0
^ permalink raw reply related [relevance 10%]
* bug#66716: Reconcile display-fill-column-indicator-character behavior and customization description
2023-10-23 21:23 10% bug#66716: Reconcile display-fill-column-indicator-character behavior and customization description Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-10-24 12:31 0% ` Eli Zaretskii
2023-10-24 19:46 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 200+ results
From: Eli Zaretskii @ 2023-10-24 12:31 UTC (permalink / raw)
To: Joseph Turner; +Cc: 66716
> Date: Mon, 23 Oct 2023 14:23:06 -0700
> From: Joseph Turner via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>
> AFAICT, setting display-fill-column-indicator-character to nil means
> that no fill indicator is displayed.
That's not true, AFAICT. The default value is nil, but when you turn
on the mode, it modifies the value of the character to be either
U+2502 or '|'.
> This patch changes the customization description to match the
> current behavior.
I don't think the patch is correct.
> However, I like the behavior that's currently described in the
> customization option:
>
> "If possible, use U+2502 to indicate fill column, otherwise use |"
>
> What do folks think about changing the behavior of
> display-fill-column-indicator-character to match this description?
I don't understand the proposal. We don't use U+2502 by default
because not all terminals support it.
^ permalink raw reply [relevance 0%]
* bug#66716: Reconcile display-fill-column-indicator-character behavior and customization description
2023-10-24 12:31 0% ` Eli Zaretskii
@ 2023-10-24 19:46 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-25 2:29 0% ` Eli Zaretskii
0 siblings, 1 reply; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-10-24 19:46 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 66716
Eli Zaretskii <eliz@gnu.org> writes:
>> Date: Mon, 23 Oct 2023 14:23:06 -0700
>> From: Joseph Turner via "Bug reports for GNU Emacs,
>> the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>>
>> AFAICT, setting display-fill-column-indicator-character to nil means
>> that no fill indicator is displayed.
>
> That's not true, AFAICT. The default value is nil, but when you turn
> on the mode, it modifies the value of the character to be either
> U+2502 or '|'.
>
>> This patch changes the customization description to match the
>> current behavior.
>
> I don't think the patch is correct.
Indeed, the patch is incorrect. I misunderstood the behavior of
display-fill-column-indicator-mode when
display-fill-column-indicator-character is nil.
>> However, I like the behavior that's currently described in the
>> customization option:
>>
>> "If possible, use U+2502 to indicate fill column, otherwise use |"
>>
>> What do folks think about changing the behavior of
>> display-fill-column-indicator-character to match this description?
>
> I don't understand the proposal. We don't use U+2502 by default
> because not all terminals support it.
When enabling display-fill-column-indicator in .dir-locals.el, is it
possible to dynamically set display-fill-column-indicator-character
according to what characters are displayable without using eval?
Currently in my project, I have:
((emacs-lisp-mode . ((display-fill-column-indicator . t)
;; This won't work on some terminals
(display-fill-column-indicator-character . ?\u2502)
(fill-column . 80))))
Please let me know if you have suggestions for improvement!
Thank you!!!
Joseph
^ permalink raw reply [relevance 5%]
* bug#66716: Reconcile display-fill-column-indicator-character behavior and customization description
2023-10-24 19:46 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-10-25 2:29 0% ` Eli Zaretskii
2023-10-25 3:11 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 200+ results
From: Eli Zaretskii @ 2023-10-25 2:29 UTC (permalink / raw)
To: Joseph Turner; +Cc: 66716
> From: Joseph Turner <joseph@breatheoutbreathe.in>
> Cc: 66716@debbugs.gnu.org
> Date: Tue, 24 Oct 2023 12:46:11 -0700
>
> >> What do folks think about changing the behavior of
> >> display-fill-column-indicator-character to match this description?
> >
> > I don't understand the proposal. We don't use U+2502 by default
> > because not all terminals support it.
>
> When enabling display-fill-column-indicator in .dir-locals.el, is it
> possible to dynamically set display-fill-column-indicator-character
> according to what characters are displayable without using eval?
I don't think so.
^ permalink raw reply [relevance 0%]
* bug#66716: Reconcile display-fill-column-indicator-character behavior and customization description
2023-10-25 2:29 0% ` Eli Zaretskii
@ 2023-10-25 3:11 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 0 replies; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-10-25 3:11 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 66716-done
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Joseph Turner <joseph@breatheoutbreathe.in>
>> Cc: 66716@debbugs.gnu.org
>> Date: Tue, 24 Oct 2023 12:46:11 -0700
>>
>> >> What do folks think about changing the behavior of
>> >> display-fill-column-indicator-character to match this description?
>> >
>> > I don't understand the proposal. We don't use U+2502 by default
>> > because not all terminals support it.
>>
>> When enabling display-fill-column-indicator in .dir-locals.el, is it
>> possible to dynamically set display-fill-column-indicator-character
>> according to what characters are displayable without using eval?
>
> I don't think so.
Thank you!!
^ permalink raw reply [relevance 5%]
* bug#65768: Bump persist.el version
@ 2023-10-30 20:54 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-31 12:07 5% ` phillip.lord
0 siblings, 1 reply; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-10-30 20:54 UTC (permalink / raw)
To: Stefan Kangas; +Cc: Phillip Lord, 65768
Ping :)
Stefan Kangas <stefankangas@gmail.com> writes:
> Joseph Turner <joseph@breatheoutbreathe.in> writes:
>
>> Please bump the version now that we've fixed that hash
>> table issue in persist.
>>
>> See patch.
>
> Phillip, what do you think?
>
>> From 8b5ec447c3ac0c6f5efa15737f22e984bba99992 Mon Sep 17 00:00:00 2001
>> From: Joseph Turner <joseph@breatheoutbreathe.in>
>> Date: Tue, 5 Sep 2023 19:13:06 -0700
>> Subject: [PATCH] Bump version
>>
>> ---
>> persist.el | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/persist.el b/persist.el
>> index e43171459e..8a1f746ddd 100644
>> --- a/persist.el
>> +++ b/persist.el
>> @@ -5,7 +5,7 @@
>> ;; Author: Phillip Lord <phillip.lord@russet.org.uk>
>> ;; Maintainer: Phillip Lord <phillip.lord@russet.org.uk>
>> ;; Package-Type: multi
>> -;; Version: 0.5
>> +;; Version: 0.6
>>
>> ;; The contents of this file are subject to the GPL License, Version 3.0.
^ permalink raw reply [relevance 5%]
* bug#65768: Bump persist.el version
2023-10-30 20:54 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-10-31 12:07 5% ` phillip.lord
2023-10-31 15:41 7% ` Joseph Turner
0 siblings, 1 reply; 200+ results
From: phillip.lord @ 2023-10-31 12:07 UTC (permalink / raw)
To: Joseph Turner; +Cc: Stefan Kangas, 65768
Oh dear, you have had to ping on this many times.
Would you be interested in taking over maintainership of persist? I am
very short of Emacs time these days.
Phil
On 2023-10-30 20:54, Joseph Turner wrote:
> Ping :)
>
> Stefan Kangas <stefankangas@gmail.com> writes:
>
>> Joseph Turner <joseph@breatheoutbreathe.in> writes:
>>
>>> Please bump the version now that we've fixed that hash
>>> table issue in persist.
>>>
>>> See patch.
>>
>> Phillip, what do you think?
>>
>>> From 8b5ec447c3ac0c6f5efa15737f22e984bba99992 Mon Sep 17 00:00:00
>>> 2001
>>> From: Joseph Turner <joseph@breatheoutbreathe.in>
>>> Date: Tue, 5 Sep 2023 19:13:06 -0700
>>> Subject: [PATCH] Bump version
>>>
>>> ---
>>> persist.el | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/persist.el b/persist.el
>>> index e43171459e..8a1f746ddd 100644
>>> --- a/persist.el
>>> +++ b/persist.el
>>> @@ -5,7 +5,7 @@
>>> ;; Author: Phillip Lord <phillip.lord@russet.org.uk>
>>> ;; Maintainer: Phillip Lord <phillip.lord@russet.org.uk>
>>> ;; Package-Type: multi
>>> -;; Version: 0.5
>>> +;; Version: 0.6
>>>
>>> ;; The contents of this file are subject to the GPL License, Version
>>> 3.0.
^ permalink raw reply [relevance 5%]
* bug#65768: Bump persist.el version
2023-10-31 12:07 5% ` phillip.lord
@ 2023-10-31 15:41 7% ` Joseph Turner
2023-10-31 16:43 0% ` Eli Zaretskii
0 siblings, 1 reply; 200+ results
From: Joseph Turner @ 2023-10-31 15:41 UTC (permalink / raw)
To: phillip.lord; +Cc: Eli Zaretskii, Stefan Kangas, 65768
Hi Phillip!
phillip.lord@russet.org.uk writes:
> Oh dear, you have had to ping on this many times.
No worries :)
> Would you be interested in taking over maintainership of persist? I am
> very short of Emacs time these days.
Yes, I am interested! Stefan, Eli, what do you think?
Stefan, before I commit to maintainership of persist, please let me know
of any maintainer guidelines I should be aware of. I have read
emacs/CONTRIBUTE and elpa/README. Would persist.el maintainership
require subscribing to the mailing list?
Thank you!
Joseph
^ permalink raw reply [relevance 7%]
* bug#65768: Bump persist.el version
2023-10-31 15:41 7% ` Joseph Turner
@ 2023-10-31 16:43 0% ` Eli Zaretskii
2023-10-31 17:05 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 200+ results
From: Eli Zaretskii @ 2023-10-31 16:43 UTC (permalink / raw)
To: Joseph Turner; +Cc: 65768, stefankangas, phillip.lord
> From: Joseph Turner <joseph@breatheoutbreathe.in>
> From: Joseph Turner <joseph@breatheoutbreathe.in>
> Cc: Stefan Kangas <stefankangas@gmail.com>, Eli Zaretskii <eliz@gnu.org>,
> 65768@debbugs.gnu.org
> Date: Tue, 31 Oct 2023 08:41:55 -0700
>
> phillip.lord@russet.org.uk writes:
>
> > Would you be interested in taking over maintainership of persist? I am
> > very short of Emacs time these days.
>
> Yes, I am interested! Stefan, Eli, what do you think?
I can only welcome you. Thanks for volunteering!
> Stefan, before I commit to maintainership of persist, please let me know
> of any maintainer guidelines I should be aware of. I have read
> emacs/CONTRIBUTE and elpa/README. Would persist.el maintainership
> require subscribing to the mailing list?
From my POV, the only request is to subscribe to
bug-gnu-emacs@gnu.org, so that you see any bug reports about
persist.el. Otherwise, we will have to forward the reports to you.
^ permalink raw reply [relevance 0%]
* bug#65768: Bump persist.el version
2023-10-31 16:43 0% ` Eli Zaretskii
@ 2023-10-31 17:05 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-01 0:34 5% ` Stefan Kangas
2023-11-06 20:38 5% ` phillip.lord
0 siblings, 2 replies; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-10-31 17:05 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 65768, stefankangas, phillip.lord
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Joseph Turner <joseph@breatheoutbreathe.in>
>> From: Joseph Turner <joseph@breatheoutbreathe.in>
>> Cc: Stefan Kangas <stefankangas@gmail.com>, Eli Zaretskii <eliz@gnu.org>,
>> 65768@debbugs.gnu.org
>> Date: Tue, 31 Oct 2023 08:41:55 -0700
>>
>> phillip.lord@russet.org.uk writes:
>>
>> > Would you be interested in taking over maintainership of persist? I am
>> > very short of Emacs time these days.
>>
>> Yes, I am interested! Stefan, Eli, what do you think?
>
> I can only welcome you. Thanks for volunteering!
Thank you :)
>> Stefan, before I commit to maintainership of persist, please let me know
>> of any maintainer guidelines I should be aware of. I have read
>> emacs/CONTRIBUTE and elpa/README. Would persist.el maintainership
>> require subscribing to the mailing list?
>
> From my POV, the only request is to subscribe to
> bug-gnu-emacs@gnu.org, so that you see any bug reports about
> persist.el. Otherwise, we will have to forward the reports to you.
Sounds good. I am subscribed to bug-gnu-emacs@gnu.org.
Joseph
^ permalink raw reply [relevance 5%]
* bug#65768: Bump persist.el version
2023-10-31 17:05 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-11-01 0:34 5% ` Stefan Kangas
2023-11-12 4:26 28% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-06 20:38 5% ` phillip.lord
1 sibling, 1 reply; 200+ results
From: Stefan Kangas @ 2023-11-01 0:34 UTC (permalink / raw)
To: Joseph Turner, Eli Zaretskii; +Cc: 65768, phillip.lord
Joseph Turner <joseph@breatheoutbreathe.in> writes:
>>> Yes, I am interested! Stefan, Eli, what do you think?
>>
>> I can only welcome you. Thanks for volunteering!
>
> Thank you :)
Indeed, welcome and thanks.
Perhaps before releasing v0.6, it would make sense to update the
Maintainer header comment to reflect that you're now the maintainer?
If you agree, feel free to send a patch.
^ permalink raw reply [relevance 5%]
* bug#65768: Bump persist.el version
2023-10-31 17:05 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-01 0:34 5% ` Stefan Kangas
@ 2023-11-06 20:38 5% ` phillip.lord
2023-11-12 4:27 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 1 reply; 200+ results
From: phillip.lord @ 2023-11-06 20:38 UTC (permalink / raw)
To: Joseph Turner; +Cc: Eli Zaretskii, stefankangas, 65768
On 2023-10-31 17:05, Joseph Turner wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Joseph Turner <joseph@breatheoutbreathe.in>
>>> From: Joseph Turner <joseph@breatheoutbreathe.in>
>>> Cc: Stefan Kangas <stefankangas@gmail.com>, Eli Zaretskii
>>> <eliz@gnu.org>,
>>> 65768@debbugs.gnu.org
>>> Date: Tue, 31 Oct 2023 08:41:55 -0700
>>>
>>> phillip.lord@russet.org.uk writes:
>>>
>>> > Would you be interested in taking over maintainership of persist? I am
>>> > very short of Emacs time these days.
>>>
>>> Yes, I am interested! Stefan, Eli, what do you think?
>>
>> I can only welcome you. Thanks for volunteering!
>
> Thank you :)
And thank you indeed! I will be very interested to see where you take
persist.
Phil
^ permalink raw reply [relevance 5%]
* bug#65768: Bump persist.el version
2023-11-01 0:34 5% ` Stefan Kangas
@ 2023-11-12 4:26 28% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-10 21:39 5% ` Stefan Kangas
0 siblings, 1 reply; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-11-12 4:26 UTC (permalink / raw)
To: Stefan Kangas; +Cc: Eli Zaretskii, 65768, phillip.lord
[-- Attachment #1: Type: text/plain, Size: 294 bytes --]
Stefan Kangas <stefankangas@gmail.com> writes:
> Perhaps before releasing v0.6, it would make sense to update the
> Maintainer header comment to reflect that you're now the maintainer?
> If you agree, feel free to send a patch.
Sounds good! Please see attached patches.
Thank you!
Joseph
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Update-Maintainer-header.patch --]
[-- Type: text/x-diff, Size: 687 bytes --]
From ada801226c3a64d02e5178280614f513eab0f911 Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Sat, 11 Nov 2023 20:24:54 -0800
Subject: [PATCH 1/2] Update Maintainer header
---
persist.el | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/persist.el b/persist.el
index e43171459e..26b8b84e2e 100644
--- a/persist.el
+++ b/persist.el
@@ -3,7 +3,7 @@
;; Copyright (C) 2019 Free Software Foundation, Inc.
;; Author: Phillip Lord <phillip.lord@russet.org.uk>
-;; Maintainer: Phillip Lord <phillip.lord@russet.org.uk>
+;; Maintainer: Joseph Turner <persist-el@breatheoutbreathe.in>
;; Package-Type: multi
;; Version: 0.5
--
2.41.0
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0002-Bump-version.patch --]
[-- Type: text/x-diff, Size: 654 bytes --]
From ff168c39915f1dd3ce475ce33dfea5280746148d Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Tue, 5 Sep 2023 19:13:06 -0700
Subject: [PATCH 2/2] Bump version
---
persist.el | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/persist.el b/persist.el
index 26b8b84e2e..19ad8bd871 100644
--- a/persist.el
+++ b/persist.el
@@ -5,7 +5,7 @@
;; Author: Phillip Lord <phillip.lord@russet.org.uk>
;; Maintainer: Joseph Turner <persist-el@breatheoutbreathe.in>
;; Package-Type: multi
-;; Version: 0.5
+;; Version: 0.6
;; The contents of this file are subject to the GPL License, Version 3.0.
--
2.41.0
^ permalink raw reply related [relevance 28%]
* bug#65768: Bump persist.el version
2023-11-06 20:38 5% ` phillip.lord
@ 2023-11-12 4:27 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 0 replies; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-11-12 4:27 UTC (permalink / raw)
To: phillip.lord; +Cc: Eli Zaretskii, stefankangas, 65768
phillip.lord@russet.org.uk writes:
> On 2023-10-31 17:05, Joseph Turner wrote:
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>>>> From: Joseph Turner <joseph@breatheoutbreathe.in>
>>>> From: Joseph Turner <joseph@breatheoutbreathe.in>
>>>> Cc: Stefan Kangas <stefankangas@gmail.com>, Eli Zaretskii
>>>> <eliz@gnu.org>,
>>>> 65768@debbugs.gnu.org
>>>> Date: Tue, 31 Oct 2023 08:41:55 -0700
>>>> phillip.lord@russet.org.uk writes:
>>>> > Would you be interested in taking over maintainership of
>>>> persist? I am
>>>> > very short of Emacs time these days.
>>>> Yes, I am interested! Stefan, Eli, what do you think?
>>> I can only welcome you. Thanks for volunteering!
>> Thank you :)
>
>
> And thank you indeed! I will be very interested to see where you take
> persist.
Thank you, Phil!!
^ permalink raw reply [relevance 5%]
* bug#66224: [PATCH] Add optional PREDICATE argument to read-directory-name
@ 2023-11-12 20:42 11% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-13 10:53 5% ` Stefan Kangas
0 siblings, 1 reply; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-11-12 20:42 UTC (permalink / raw)
To: michael_heerdegen, 66224, philipk
Joseph Turner <joseph@breatheoutbreathe.in> writes:
> Michael Heerdegen <michael_heerdegen@web.de> writes:
>
>> Joseph Turner via "Bug reports for GNU Emacs, the Swiss army knife of
>> text editors" <bug-gnu-emacs@gnu.org> writes:
>>
>>> I'm not sure what you mean. In both of the following examples, PREDICATE
>>> is used to narrow the completion candidates to only empty directories:
>>>
>>> (read-directory-name "Prompt: " "~/" nil t nil #'directory-empty-p)
>>> (read-directory-name "Prompt: " "~/" nil nil nil #'directory-empty-p)
>>
>> In the second version also non-empty directories will be accepted.
>
> Yes, PREDICATE narrows the completion candidates but doesn't determine a
> valid return value.
Ping! I'm happy to keep discussing this patch if others are interested.
^ permalink raw reply [relevance 11%]
* bug#66187: read-file-name unexpected behavior when MUSTMATCH is a function
@ 2023-11-12 21:26 10% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-26 6:49 11% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 2 replies; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-11-12 21:26 UTC (permalink / raw)
To: Stefan Monnier; +Cc: michael_heerdegen, Eli Zaretskii, philipk, 66187
[-- Attachment #1: Type: text/plain, Size: 530 bytes --]
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> Then I think we should install your patch on the emacs-29 branch,
>> thanks.
>
> Thanks for the vote of confidence, but as Joseph points out, the patch
> isn't actually doing what it says on the tin, so we first have to fix
> it :-)
Here's another potential solution. While the attached patch seems to
work, I'm not sure that minibuffer-completion-confirm should be checked
in completion--do-completion instead of completion--complete-and-exit.
Thoughts?
Thanks!
Joseph
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Fix-completing-read-functional-REQUIRE-MATCH-behavio.patch --]
[-- Type: text/x-diff, Size: 1407 bytes --]
From 609bf4964f88b01f4843e29b2cf71ee1cd2f6125 Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Sun, 12 Nov 2023 13:21:50 -0800
Subject: [PATCH] Fix completing-read functional REQUIRE-MATCH behavior
* lisp/minibuffer.el (completion--complete-and-exit): If
minibuffer-completion-confirm is a function which returns nil,
immediately fail to complete.
See bug#66187.
---
lisp/minibuffer.el | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 3e30b68d5e9..9fad3e71fad 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -1847,10 +1847,13 @@ appear to be a match."
;; Allow user to specify null string
((= beg end) (funcall exit-function))
;; The CONFIRM argument is a predicate.
- ((and (functionp minibuffer-completion-confirm)
- (funcall minibuffer-completion-confirm
- (buffer-substring beg end)))
- (funcall exit-function))
+ ((functionp minibuffer-completion-confirm)
+ (if (funcall minibuffer-completion-confirm
+ (buffer-substring beg end))
+ (funcall exit-function)
+ (unless completion-fail-discreetly
+ (ding)
+ (completion--message "No match"))))
;; See if we have a completion from the table.
((test-completion (buffer-substring beg end)
minibuffer-completion-table
--
2.41.0
^ permalink raw reply related [relevance 10%]
* bug#66115: [PATCH] Ensure that directory is expanded in package-vc-checkout
[not found] ` <87msviogui.fsf@breatheoutbreathe.in>
@ 2023-11-16 6:44 5% ` Philip Kaludercic
2023-11-19 22:16 11% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-11-16 6:44 UTC (permalink / raw)
To: Joseph Turner; +Cc: 66115, Eli Zaretskii
Joseph Turner <joseph@breatheoutbreathe.in> writes:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> Cc: 66115-done@debbugs.gnu.org
>>> Date: Sat, 23 Sep 2023 22:34:24 -0700
>>> From: Joseph Turner via "Bug reports for GNU Emacs,
>>> the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>>>
>>> It appears that the fix was applied to master. Would it make sense to
>>> apply it to emacs-29?
>>
>> The installed change affects much more than the original issue, so I'd
>> prefer for it to stay on master.
>>
>> I'm okay with installing the original patch on emacs-29, but be sure
>> to say "do not merge to master" in the commit log message if you do.
>
> Philip, shall we merge the original patch on emacs-29 with "do not merge
> to master"?
I don't object.
> Thank you!!
>
> Joseph
^ permalink raw reply [relevance 5%]
* bug#66115: [PATCH] Ensure that directory is expanded in package-vc-checkout
2023-11-16 6:44 5% ` Philip Kaludercic
@ 2023-11-19 22:16 11% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-25 10:17 0% ` Eli Zaretskii
0 siblings, 1 reply; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-11-19 22:16 UTC (permalink / raw)
To: Philip Kaludercic; +Cc: 66115, Eli Zaretskii
[-- Attachment #1: Type: text/plain, Size: 913 bytes --]
Philip Kaludercic <philipk@posteo.net> writes:
> Joseph Turner <joseph@breatheoutbreathe.in> writes:
>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>>>> Cc: 66115-done@debbugs.gnu.org
>>>> Date: Sat, 23 Sep 2023 22:34:24 -0700
>>>> From: Joseph Turner via "Bug reports for GNU Emacs,
>>>> the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>>>>
>>>> It appears that the fix was applied to master. Would it make sense to
>>>> apply it to emacs-29?
>>>
>>> The installed change affects much more than the original issue, so I'd
>>> prefer for it to stay on master.
>>>
>>> I'm okay with installing the original patch on emacs-29, but be sure
>>> to say "do not merge to master" in the commit log message if you do.
>>
>> Philip, shall we merge the original patch on emacs-29 with "do not merge
>> to master"?
>
> I don't object.
Would you be willing to merge the attached patch?
Thank you!!
Joseph
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Ensure-that-directory-is-expanded-in-package-vc-chec.patch --]
[-- Type: text/x-diff, Size: 1015 bytes --]
From 75a6ec74ff5e31edc7592b68e7ad9d1ec26f515c Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Wed, 20 Sep 2023 00:12:10 -0700
Subject: [PATCH] Ensure that directory is expanded in package-vc-checkout
* lisp/emacs-lisp/package-vc.el (package-vc-checkout)
---
lisp/emacs-lisp/package-vc.el | 1 +
1 file changed, 1 insertion(+)
diff --git a/lisp/emacs-lisp/package-vc.el b/lisp/emacs-lisp/package-vc.el
index 29b540d86b8..47d8c996ff0 100644
--- a/lisp/emacs-lisp/package-vc.el
+++ b/lisp/emacs-lisp/package-vc.el
@@ -834,6 +834,7 @@ for the last released version of the package."
(setf dir subdir)
(user-error "Directory not empty: %S" (expand-file-name dir)))))
(list desc dir (and current-prefix-arg :last-release))))
+ (setf directory (expand-file-name directory))
(package-vc--archives-initialize)
(let ((pkg-spec (or (package-vc--desc->spec pkg-desc)
(and-let* ((extras (package-desc-extras pkg-desc))
--
2.41.0
^ permalink raw reply related [relevance 11%]
* bug#67325: shorthands: Incorrect autoloaded register-definition-prefixes
@ 2023-11-20 19:50 5% Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-24 8:06 0% ` Eli Zaretskii
0 siblings, 1 reply; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-11-20 19:50 UTC (permalink / raw)
To: 67325; +Cc: Protesilaos Stavrou, Jonas Bernoulli, João Távora
When using shorthands.el, autoload generation inserts a call to
register-definition-prefixes with the shorthand prefix, instead of the
translated print name prefix. For example, breadcrumb-autoloads.el
contains the line:
(register-definition-prefixes "breadcrumb" '("bc-"))
instead of
(register-definition-prefixes "breadcrumb" '("breadcrumb-"))
This PR attempts to resolve this issue in breadcrumb.el by adding the
correct autoload line at the bottom of the file:
https://github.com/joaotavora/breadcrumb/pull/24
What needs to be done in core Emacs to fix autoload generation with
shorthands.el?
Also see bug#63480.
Thanks!
Joseph
^ permalink raw reply [relevance 5%]
* bug#63480: 30.0.50; [BUG] unimplemented logic regarding read-symbol-shorthands
@ 2023-11-23 21:38 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 0 replies; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-11-23 21:38 UTC (permalink / raw)
To: stefankangas; +Cc: 63480, ruijie, joaotavora
Also see https://lists.gnu.org/archive/html/bug-gnu-emacs/2023-11/msg01151.html
^ permalink raw reply [relevance 5%]
* bug#67325: shorthands: Incorrect autoloaded register-definition-prefixes
2023-11-20 19:50 5% bug#67325: shorthands: Incorrect autoloaded register-definition-prefixes Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-11-24 8:06 0% ` Eli Zaretskii
2023-11-24 9:24 0% ` João Távora
0 siblings, 1 reply; 200+ results
From: Eli Zaretskii @ 2023-11-24 8:06 UTC (permalink / raw)
To: Joseph Turner, joaotavora; +Cc: 67325, jonas, public
> Cc: Protesilaos Stavrou <public@protesilaos.com>,
> Jonas Bernoulli <jonas@bernoul.li>,
> João Távora <joaotavora@gmail.com>
> Date: Mon, 20 Nov 2023 11:50:50 -0800
> From: Joseph Turner via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>
> When using shorthands.el, autoload generation inserts a call to
> register-definition-prefixes with the shorthand prefix, instead of the
> translated print name prefix. For example, breadcrumb-autoloads.el
> contains the line:
>
> (register-definition-prefixes "breadcrumb" '("bc-"))
>
> instead of
>
> (register-definition-prefixes "breadcrumb" '("breadcrumb-"))
>
> This PR attempts to resolve this issue in breadcrumb.el by adding the
> correct autoload line at the bottom of the file:
>
> https://github.com/joaotavora/breadcrumb/pull/24
>
> What needs to be done in core Emacs to fix autoload generation with
> shorthands.el?
>
> Also see bug#63480.
João, any comments?
^ permalink raw reply [relevance 0%]
* bug#67325: shorthands: Incorrect autoloaded register-definition-prefixes
2023-11-24 8:06 0% ` Eli Zaretskii
@ 2023-11-24 9:24 0% ` João Távora
2023-11-25 4:18 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 200+ results
From: João Távora @ 2023-11-24 9:24 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Joseph Turner, 67325, jonas, public
On Fri, Nov 24, 2023 at 8:06 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > Cc: Protesilaos Stavrou <public@protesilaos.com>,
> > Jonas Bernoulli <jonas@bernoul.li>,
> > João Távora <joaotavora@gmail.com>
> > Date: Mon, 20 Nov 2023 11:50:50 -0800
> > From: Joseph Turner via "Bug reports for GNU Emacs,
> > the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> >
> > When using shorthands.el, autoload generation inserts a call to
> > register-definition-prefixes with the shorthand prefix, instead of the
> > translated print name prefix. For example, breadcrumb-autoloads.el
> > contains the line:
> >
> > (register-definition-prefixes "breadcrumb" '("bc-"))
> >
> > instead of
> >
> > (register-definition-prefixes "breadcrumb" '("breadcrumb-"))
> >
> > This PR attempts to resolve this issue in breadcrumb.el by adding the
> > correct autoload line at the bottom of the file:
> >
> > https://github.com/joaotavora/breadcrumb/pull/24
> >
> > What needs to be done in core Emacs to fix autoload generation with
> > shorthands.el?
> >
> > Also see bug#63480.
>
> João, any comments?
Yes. Well first, we are talking about an imperfect heuristic here
which lives in lisp/emacs-lisp/loaddefs-gen.el. That's where
the definition prefixes for a given file are collected and the
common prefix is guessed, leading to the generation of the
register-definition-prefixes form.
The logic seems to have a number of exceptions and corner cases
baked into it already, and there seems to be even a specific
kill-switch for this particular register-definition-prefixes form:
;; Local Variables:
;; autoload-compute-prefixes: nil
;; End:
This form should probably be added to breadcrumb.el so that
the autoload mechanism would stop trying to guess the prefix
using its current flawed methods. I've already asked the
submitters of the pull request to do so at the Breadcrumb
upstream.
BTW. Grepping for autoload-compute-prefixes seems to indicate
it is totally undocumented. It's not even a defvar,
just an autoload-specific cookies. This is fine, but I guess
it should still be documented somewhere.
OK so that solves the problem for breadcrumb.el and other
such shorthand-using packages such as beardbolt.el and others
I see popping up.
But maybe this issue can still be kept open. It shouldn't be
terribly hard to add a fix to loaddefs-generate--compute-prefixes
or loaddefs-generate--make-prefixes that takes shorthands in
consideration. In fact, the presence of a shorthand might
be a more reliable indicator of the package's intended "external"
prefix than any of the current heuristics.
> > Also see bug#63480.
What about it? What's the relation to this bug?
João
^ permalink raw reply [relevance 0%]
* bug#67390: 28; shorthands-font-lock-shorthands assumes shorthand uses same separator
@ 2023-11-25 3:26 9% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-25 16:01 5% ` Jonas Bernoulli via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-11-25 3:26 UTC (permalink / raw)
To: João Távora; +Cc: 67390, Adam Porter, Jonas Bernoulli
[-- Attachment #1: Type: text/plain, Size: 1120 bytes --]
João Távora <joaotavora@gmail.com> writes:
> On Fri, Nov 24, 2023 at 9:51 PM Jonas Bernoulli <jonas@bernoul.li> wrote:
>
>> Also, have you considered throwing in a
>> (not (string-equal (match-string 1) sname))
>>
>> to avoid having to call `shorthands--mismatch-from-end' at all?
>
> Where and how this be thrown in? How would you know what to highlight
> in the shorthand printed form? There can be many shorthand prefixes
> in a given file. But do show some code.
Please see the attached patch, inspired by Jonas's comment.
>> Maybe you have, but concluded it is cheaper to do a bit too much work
>> for non-shorthands, than to effectively repeat some work for shorthands.
>
> Maybe. Not sure this is more work (string-equal must still compare
> every character right?), but, in summary, I'm not married to this
> implementation. I somewhat appreciate that I could still read it
> after not having looked at it for a couple years, but feel free to
> change it.
I haven't done any benchmarking - I'm curious to learn how to benchmark
font lock though!
Thanks!!
Joseph
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Support-shorthand-prefixes-besides.patch --]
[-- Type: text/x-diff, Size: 2991 bytes --]
From e469c9d621116857bd1d84720eb2eb43d4560074 Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Fri, 24 Nov 2023 19:17:13 -0800
Subject: [PATCH] Support shorthand prefixes besides "-"
Previously, shorthands-font-lock-shorthands added font locking to the
shorthand prefix by checking for a mismatch between the shorthand and
longhand symbols. This broke font-locking when the shorthand prefix
separator was not "-" (bug#67390).
Now, shorthands-font-lock-shorthands adds font locking to the
shorthand prefix by checking if any of the shorthand prefixes in
read-symbol-shorthands are a prefix for the current symbol name.
Thanks to Jonas Bernoulli for the idea to use
(not (string-equal (match-string 1) sname))
---
lisp/emacs-lisp/shorthands.el | 27 +++++++++++++++++----------
1 file changed, 17 insertions(+), 10 deletions(-)
diff --git a/lisp/emacs-lisp/shorthands.el b/lisp/emacs-lisp/shorthands.el
index 82200ab88e9..141b6115a3d 100644
--- a/lisp/emacs-lisp/shorthands.el
+++ b/lisp/emacs-lisp/shorthands.el
@@ -52,12 +52,14 @@
:version "28.1"
:group 'font-lock-faces)
-(defun shorthands--mismatch-from-end (str1 str2)
- (cl-loop with l1 = (length str1) with l2 = (length str2)
- for i from 1
- for i1 = (- l1 i) for i2 = (- l2 i)
- while (and (>= i1 0) (>= i2 0) (eq (aref str1 i1) (aref str2 i2)))
- finally (return (1- i))))
+(defun shorthands--find-if (predicate seq &optional key)
+ "Find the first item satisfying PREDICATE in SEQ.
+Return the matching item, or nil if not found. Optional argument
+KEY is used to filter SEQ, as in `cl-find-if'."
+ (catch 'found
+ (dolist (el seq)
+ (when (funcall predicate (funcall (or key #'identity) el))
+ (throw 'found el)))))
(defun shorthands-font-lock-shorthands (limit)
(when read-symbol-shorthands
@@ -69,10 +71,15 @@
font-lock-string-face)))
(intern-soft (match-string 1))))
(sname (and probe (symbol-name probe)))
- (mm (and sname (shorthands--mismatch-from-end
- (match-string 1) sname))))
- (unless (or (null mm) (= mm (length sname)))
- (add-face-text-property (match-beginning 1) (1+ (- (match-end 1) mm))
+ (prefix (and sname
+ (not (string-equal (match-string 1) sname))
+ (car (shorthands--find-if
+ (lambda (short)
+ (string-prefix-p short (match-string 1)))
+ read-symbol-shorthands #'car)))))
+ (when prefix
+ (add-face-text-property (match-beginning 1)
+ (+ (match-beginning 1) (length prefix))
'elisp-shorthand-font-lock-face))))))
(font-lock-add-keywords 'emacs-lisp-mode '((shorthands-font-lock-shorthands)) t)
--
2.41.0
^ permalink raw reply related [relevance 9%]
* bug#67325: shorthands: Incorrect autoloaded register-definition-prefixes
2023-11-24 9:24 0% ` João Távora
@ 2023-11-25 4:18 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-25 12:44 5% ` João Távora
0 siblings, 1 reply; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-11-25 4:18 UTC (permalink / raw)
To: João Távora; +Cc: 67325, Eli Zaretskii, public, jonas
João Távora <joaotavora@gmail.com> writes:
>> From: Joseph Turner
>> > Also see bug#63480.
>
> What about it? What's the relation to this bug?
bug#63480 is also related to incorrect autoload generation with
shorthands. I don't know if these two bugs will have related solutions.
Joseph
^ permalink raw reply [relevance 5%]
* bug#66115: [PATCH] Ensure that directory is expanded in package-vc-checkout
2023-11-19 22:16 11% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-11-25 10:17 0% ` Eli Zaretskii
2023-11-25 22:59 11% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 200+ results
From: Eli Zaretskii @ 2023-11-25 10:17 UTC (permalink / raw)
To: Joseph Turner; +Cc: 66115, philipk
> From: Joseph Turner <joseph@breatheoutbreathe.in>
> Cc: Eli Zaretskii <eliz@gnu.org>, 66115@debbugs.gnu.org
> Date: Sun, 19 Nov 2023 14:16:39 -0800
>
> Philip Kaludercic <philipk@posteo.net> writes:
>
> > Joseph Turner <joseph@breatheoutbreathe.in> writes:
> >
> >> Eli Zaretskii <eliz@gnu.org> writes:
> >>
> >>>> Cc: 66115-done@debbugs.gnu.org
> >>>> Date: Sat, 23 Sep 2023 22:34:24 -0700
> >>>> From: Joseph Turner via "Bug reports for GNU Emacs,
> >>>> the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> >>>>
> >>>> It appears that the fix was applied to master. Would it make sense to
> >>>> apply it to emacs-29?
> >>>
> >>> The installed change affects much more than the original issue, so I'd
> >>> prefer for it to stay on master.
> >>>
> >>> I'm okay with installing the original patch on emacs-29, but be sure
> >>> to say "do not merge to master" in the commit log message if you do.
> >>
> >> Philip, shall we merge the original patch on emacs-29 with "do not merge
> >> to master"?
> >
> > I don't object.
>
> Would you be willing to merge the attached patch?
I tried, but it doesn't apply to emacs-29. Would you please submit a
change relative to the emacs-29 branch?
TIA
^ permalink raw reply [relevance 0%]
* bug#67325: shorthands: Incorrect autoloaded register-definition-prefixes
2023-11-25 4:18 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-11-25 12:44 5% ` João Távora
0 siblings, 0 replies; 200+ results
From: João Távora @ 2023-11-25 12:44 UTC (permalink / raw)
To: Joseph Turner; +Cc: 67325, Eli Zaretskii, public, Jonas Bernoulli
[-- Attachment #1: Type: text/plain, Size: 611 bytes --]
On Sat, Nov 25, 2023, 04:21 Joseph Turner <joseph@ushin.org> wrote:
> João Távora <joaotavora@gmail.com> writes:
> >> From: Joseph Turner
> >> > Also see bug#63480.
> >
> > What about it? What's the relation to this bug?
>
> bug#63480 is also related to incorrect autoload generation with
> shorthands.
Hmmm. The two bugs are not related anymore than two Emacs bugs are related.
That bug has a (very decent IMO) workaround. If you want something to be
done there additionally, request it there
> I don't know if these two bugs will have related solutions.
I don't think so.
João
[-- Attachment #2: Type: text/html, Size: 1182 bytes --]
^ permalink raw reply [relevance 5%]
* bug#67390: 28; shorthands-font-lock-shorthands assumes shorthand uses same separator
2023-11-25 3:26 9% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-11-25 16:01 5% ` Jonas Bernoulli via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-25 22:42 9% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-29 13:30 0% ` João Távora
0 siblings, 2 replies; 200+ results
From: Jonas Bernoulli via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-11-25 16:01 UTC (permalink / raw)
To: Joseph Turner, João Távora; +Cc: 67390, Adam Porter
Joseph Turner <joseph@ushin.org> writes:
> + (car (shorthands--find-if
> + (lambda (short)
> + (string-prefix-p short (match-string 1)))
> + read-symbol-shorthands #'car)))))
Or simply:
(car (assoc (match-string 1)
read-symbol-shorthands
#'string-prefix-p))
^ permalink raw reply [relevance 5%]
* bug#67390: 28; shorthands-font-lock-shorthands assumes shorthand uses same separator
2023-11-25 16:01 5% ` Jonas Bernoulli via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-11-25 22:42 9% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-26 13:52 4% ` João Távora
2023-11-29 13:30 0% ` João Távora
1 sibling, 1 reply; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-11-25 22:42 UTC (permalink / raw)
To: Jonas Bernoulli; +Cc: 67390, Adam Porter, João Távora
[-- Attachment #1: Type: text/plain, Size: 512 bytes --]
Jonas Bernoulli <jonas@bernoul.li> writes:
> Joseph Turner <joseph@ushin.org> writes:
>
>> + (car (shorthands--find-if
>> + (lambda (short)
>> + (string-prefix-p short (match-string 1)))
>> + read-symbol-shorthands #'car)))))
>
> Or simply:
> (car (assoc (match-string 1)
> read-symbol-shorthands
> #'string-prefix-p))
Much nicer - see patch. Thanks, Jonas!
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Support-shorthand-prefixes-besides.patch --]
[-- Type: text/x-diff, Size: 2341 bytes --]
From 5033a0e14950ed1622db78df1828c40de4b5a23a Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Fri, 24 Nov 2023 19:17:13 -0800
Subject: [PATCH] Support shorthand prefixes besides "-"
* lisp/emacs-lisp/shorthands.el (shorthands-font-lock-shorthands):
Add font locking to the shorthand prefix by checking if any of the
shorthand prefixes in read-symbol-shorthands are a prefix for the
current symbol name (bug#67390).
Co-authored-by: Jonas Bernoulli <jonas@bernoul.li>
---
lisp/emacs-lisp/shorthands.el | 19 ++++++++-----------
1 file changed, 8 insertions(+), 11 deletions(-)
diff --git a/lisp/emacs-lisp/shorthands.el b/lisp/emacs-lisp/shorthands.el
index 82200ab88e9..6ce9984a353 100644
--- a/lisp/emacs-lisp/shorthands.el
+++ b/lisp/emacs-lisp/shorthands.el
@@ -52,13 +52,6 @@
:version "28.1"
:group 'font-lock-faces)
-(defun shorthands--mismatch-from-end (str1 str2)
- (cl-loop with l1 = (length str1) with l2 = (length str2)
- for i from 1
- for i1 = (- l1 i) for i2 = (- l2 i)
- while (and (>= i1 0) (>= i2 0) (eq (aref str1 i1) (aref str2 i2)))
- finally (return (1- i))))
-
(defun shorthands-font-lock-shorthands (limit)
(when read-symbol-shorthands
(while (re-search-forward
@@ -69,10 +62,14 @@
font-lock-string-face)))
(intern-soft (match-string 1))))
(sname (and probe (symbol-name probe)))
- (mm (and sname (shorthands--mismatch-from-end
- (match-string 1) sname))))
- (unless (or (null mm) (= mm (length sname)))
- (add-face-text-property (match-beginning 1) (1+ (- (match-end 1) mm))
+ (prefix (and sname
+ (not (string-equal (match-string 1) sname))
+ (car (assoc (match-string 1)
+ read-symbol-shorthands
+ #'string-prefix-p)))))
+ (when prefix
+ (add-face-text-property (match-beginning 1)
+ (+ (match-beginning 1) (length prefix))
'elisp-shorthand-font-lock-face))))))
(font-lock-add-keywords 'emacs-lisp-mode '((shorthands-font-lock-shorthands)) t)
--
2.41.0
^ permalink raw reply related [relevance 9%]
* bug#66115: [PATCH] Ensure that directory is expanded in package-vc-checkout
2023-11-25 10:17 0% ` Eli Zaretskii
@ 2023-11-25 22:59 11% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-26 10:41 0% ` Eli Zaretskii
0 siblings, 1 reply; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-11-25 22:59 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 66115, philipk
[-- Attachment #1: Type: text/plain, Size: 310 bytes --]
Eli Zaretskii <eliz@gnu.org> writes:
> From: Joseph Turner <joseph@breatheoutbreathe.in>
>> Would you be willing to merge the attached patch?
>
> I tried, but it doesn't apply to emacs-29. Would you please submit a
> change relative to the emacs-29 branch?
Sorry about that! Here you go!
Thanks,
Joseph
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Ensure-that-directory-is-expanded-in-package-vc-chec.patch --]
[-- Type: text/x-diff, Size: 1053 bytes --]
From 49a94115d7f6bde1618f754265ec3ea8154dd922 Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Sat, 25 Nov 2023 14:57:45 -0800
Subject: [PATCH] Ensure that directory is expanded in package-vc-checkout
* lisp/emacs-lisp/package-vc.el (package-vc-checkout)
bug#66115
---
lisp/emacs-lisp/package-vc.el | 1 +
1 file changed, 1 insertion(+)
diff --git a/lisp/emacs-lisp/package-vc.el b/lisp/emacs-lisp/package-vc.el
index c7a30736e32..2a5f14b3ee3 100644
--- a/lisp/emacs-lisp/package-vc.el
+++ b/lisp/emacs-lisp/package-vc.el
@@ -829,6 +829,7 @@ for the last released version of the package."
(lambda (dir) (or (not (file-exists-p dir))
(directory-empty-p dir))))
(and current-prefix-arg :last-release))))
+ (setf directory (expand-file-name directory))
(package-vc--archives-initialize)
(let ((pkg-spec (or (package-vc--desc->spec pkg-desc)
(and-let* ((extras (package-desc-extras pkg-desc))
--
2.41.0
^ permalink raw reply related [relevance 11%]
* bug#66187: read-file-name unexpected behavior when MUSTMATCH is a function
2023-11-12 21:26 10% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-11-26 6:49 11% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 0 replies; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-11-26 6:49 UTC (permalink / raw)
To: Stefan Monnier, Eli Zaretskii, michael_heerdegen, philipk, 66187
Joseph Turner <joseph@breatheoutbreathe.in> writes:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>> Then I think we should install your patch on the emacs-29 branch,
>>> thanks.
>>
>> Thanks for the vote of confidence, but as Joseph points out, the patch
>> isn't actually doing what it says on the tin, so we first have to fix
>> it :-)
>
> Here's another potential solution. While the attached patch seems to
> work, I'm not sure that minibuffer-completion-confirm should be checked
> in completion--do-completion instead of completion--complete-and-exit.
>
> Thoughts?
I just ran the tests in /test/lisp/minibuffer-tests.el with this patch,
and they all still pass.
> Thanks!
>
> Joseph
>
> [2. text/x-diff; 0001-Fix-completing-read-functional-REQUIRE-MATCH-behavio.patch]...
^ permalink raw reply [relevance 11%]
* bug#66115: [PATCH] Ensure that directory is expanded in package-vc-checkout
2023-11-25 22:59 11% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-11-26 10:41 0% ` Eli Zaretskii
2023-11-26 20:39 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 200+ results
From: Eli Zaretskii @ 2023-11-26 10:41 UTC (permalink / raw)
To: Joseph Turner; +Cc: 66115-done, philipk
> From: Joseph Turner <joseph@breatheoutbreathe.in>
> Cc: philipk@posteo.net, 66115@debbugs.gnu.org
> Date: Sat, 25 Nov 2023 14:59:46 -0800
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > From: Joseph Turner <joseph@breatheoutbreathe.in>
> >> Would you be willing to merge the attached patch?
> >
> > I tried, but it doesn't apply to emacs-29. Would you please submit a
> > change relative to the emacs-29 branch?
>
> Sorry about that! Here you go!
Thanks, installed on the emacs-29 branch, and closing the bug.
^ permalink raw reply [relevance 0%]
* bug#67390: 28; shorthands-font-lock-shorthands assumes shorthand uses same separator
2023-11-25 22:42 9% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-11-26 13:52 4% ` João Távora
2023-11-26 20:35 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 200+ results
From: João Távora @ 2023-11-26 13:52 UTC (permalink / raw)
To: Joseph Turner; +Cc: 67390, Adam Porter, Jonas Bernoulli
On Sat, Nov 25, 2023 at 10:43 PM Joseph Turner <joseph@ushin.org> wrote:
>
> Jonas Bernoulli <jonas@bernoul.li> writes:
>
> > Joseph Turner <joseph@ushin.org> writes:
> >
> >> + (car (shorthands--find-if
> >> + (lambda (short)
> >> + (string-prefix-p short (match-string 1)))
> >> + read-symbol-shorthands #'car)))))
> >
> > Or simply:
> > (car (assoc (match-string 1)
> > read-symbol-shorthands
> > #'string-prefix-p))
>
> Much nicer - see patch. Thanks, Jonas!
So, I had a look at this patch and I think we should compare it
with the patch after my sig, which keeps 'shorthands--mismatch-from-end'
and also fixes this bug.
The main difference I see is that my patch keeps doing one string
comparison, via the mismatch function (which btw is now perfectly
analogous to CL mismatch and thus correctly named). In the worst case,
Josheph's patch does 1 + N where N is the number of shorthands. So
this is a fundamental complexity change.
Normally, that would be the end of the story, but here, it isn't.
For two reasons.
My version keeps a behaviour that can be considered buggy.
If a shorthand prefix has a common suffix with the longhand prefix
then that suffix will not be highlighted. Like:
;; Local Variables:
;; read-symbol-shorthands: (("bcrumb-" . "breadcrumb-")
;; End:
Here only "b" would be highlighted, effectively showing the user
how much typing was saved. Is this wrong? Does it makes sense
to use shorthands like this?
The other reason why this isn't the end of the story is that even
if we take that bug for granted, the string comparison functions in
Joshep's patch delegate to built-in C comparison operators, which are
often much, much faster than Elisp. At least before the advent of native
compilation, it used to be like this. Of course for a large enough N
number of shorthands, my version wins, but that is probably not very
common either (or is it? Not very hard to imagine a file making use
of many libraries and shorthanding each of them?)
So, benchmarking it will have to be, I'm afraid, because AFAIK
font-locking is a very performance sensitive area of Emacs.
In the meantime I will push my patch, but keep the bug open to see
if it is worth pushing Joseph's version.
João
diff --git a/lisp/emacs-lisp/shorthands.el b/lisp/emacs-lisp/shorthands.el
index 82200ab88e9..b0665a55695 100644
--- a/lisp/emacs-lisp/shorthands.el
+++ b/lisp/emacs-lisp/shorthands.el
@@ -53,11 +53,16 @@ elisp-shorthand-font-lock-face
:group 'font-lock-faces)
(defun shorthands--mismatch-from-end (str1 str2)
+ "Tell index of first mismatch in STR1 and STR2, from end.
+The index is a valid 0-based index on STR1. Returns nil if STR1
+equals STR2. Return 0 if STR1 is a suffix of STR2."
(cl-loop with l1 = (length str1) with l2 = (length str2)
for i from 1
for i1 = (- l1 i) for i2 = (- l2 i)
- while (and (>= i1 0) (>= i2 0) (eq (aref str1 i1) (aref str2 i2)))
- finally (return (1- i))))
+ while (eq (aref str1 i1) (aref str2 i2))
+ if (zerop i2) return (if (zerop i1) nil i1)
+ if (zerop i1) return 0
+ finally (return i1)))
(defun shorthands-font-lock-shorthands (limit)
(when read-symbol-shorthands
@@ -69,10 +74,16 @@ shorthands-font-lock-shorthands
font-lock-string-face)))
(intern-soft (match-string 1))))
(sname (and probe (symbol-name probe)))
- (mm (and sname (shorthands--mismatch-from-end
- (match-string 1) sname))))
- (unless (or (null mm) (= mm (length sname)))
- (add-face-text-property (match-beginning 1) (1+ (- (match-end 1) mm))
+ (mismatch (and sname (shorthands--mismatch-from-end
+ (match-string 1) sname)))
+ (guess (and mismatch (1+ mismatch))))
+ (when guess
+ (when (and (< guess (1- (length (match-string 1))))
+ ;; In bug#67390 we allow other separators
+ (eq (char-syntax (aref (match-string 1) guess)) ?_))
+ (setq guess (1+ guess)))
+ (add-face-text-property (match-beginning 1)
+ (+ (match-beginning 1) guess)
'elisp-shorthand-font-lock-face))))))
(font-lock-add-keywords 'emacs-lisp-mode
'((shorthands-font-lock-shorthands)) t)
^ permalink raw reply related [relevance 4%]
* bug#67390: 28; shorthands-font-lock-shorthands assumes shorthand uses same separator
2023-11-26 13:52 4% ` João Távora
@ 2023-11-26 20:35 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-26 22:02 5% ` João Távora
0 siblings, 1 reply; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-11-26 20:35 UTC (permalink / raw)
To: João Távora; +Cc: 67390, Adam Porter, Jonas Bernoulli
João Távora <joaotavora@gmail.com> writes:
> On Sat, Nov 25, 2023 at 10:43 PM Joseph Turner <joseph@ushin.org> wrote:
>>
>> Jonas Bernoulli <jonas@bernoul.li> writes:
>>
>> > Joseph Turner <joseph@ushin.org> writes:
>> >
>> >> + (car (shorthands--find-if
>> >> + (lambda (short)
>> >> + (string-prefix-p short (match-string 1)))
>> >> + read-symbol-shorthands #'car)))))
>> >
>> > Or simply:
>> > (car (assoc (match-string 1)
>> > read-symbol-shorthands
>> > #'string-prefix-p))
>>
>> Much nicer - see patch. Thanks, Jonas!
>
> So, I had a look at this patch and I think we should compare it
> with the patch after my sig, which keeps 'shorthands--mismatch-from-end'
> and also fixes this bug.
>
> The main difference I see is that my patch keeps doing one string
> comparison, via the mismatch function (which btw is now perfectly
> analogous to CL mismatch and thus correctly named). In the worst case,
> Josheph's patch does 1 + N where N is the number of shorthands. So
> this is a fundamental complexity change.
>
> Normally, that would be the end of the story, but here, it isn't.
> For two reasons.
>
> My version keeps a behaviour that can be considered buggy.
> If a shorthand prefix has a common suffix with the longhand prefix
> then that suffix will not be highlighted. Like:
>
> ;; Local Variables:
> ;; read-symbol-shorthands: (("bcrumb-" . "breadcrumb-")
> ;; End:
>
> Here only "b" would be highlighted, effectively showing the user
> how much typing was saved. Is this wrong? Does it makes sense
> to use shorthands like this?
I would expect the entire the shorthand to be highlit, I don't feeling
strongly about this.
> The other reason why this isn't the end of the story is that even
> if we take that bug for granted, the string comparison functions in
> Joshep's patch delegate to built-in C comparison operators, which are
> often much, much faster than Elisp. At least before the advent of native
> compilation, it used to be like this. Of course for a large enough N
> number of shorthands, my version wins, but that is probably not very
> common either (or is it? Not very hard to imagine a file making use
> of many libraries and shorthanding each of them?)
>
> So, benchmarking it will have to be, I'm afraid, because AFAIK
> font-locking is a very performance sensitive area of Emacs.
Yes. I would like to learn how to do this!
> In the meantime I will push my patch, but keep the bug open to see
> if it is worth pushing Joseph's version.
Thank you!! I'm happy to discuss this further if others are interested.
Joseph
^ permalink raw reply [relevance 5%]
* bug#66115: [PATCH] Ensure that directory is expanded in package-vc-checkout
2023-11-26 10:41 0% ` Eli Zaretskii
@ 2023-11-26 20:39 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-27 12:01 0% ` Eli Zaretskii
0 siblings, 1 reply; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-11-26 20:39 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 66115-done, philipk
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Joseph Turner <joseph@breatheoutbreathe.in>
>> Cc: philipk@posteo.net, 66115@debbugs.gnu.org
>> Date: Sat, 25 Nov 2023 14:59:46 -0800
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> > From: Joseph Turner <joseph@breatheoutbreathe.in>
>> >> Would you be willing to merge the attached patch?
>> >
>> > I tried, but it doesn't apply to emacs-29. Would you please submit a
>> > change relative to the emacs-29 branch?
>>
>> Sorry about that! Here you go!
>
> Thanks, installed on the emacs-29 branch, and closing the bug.
Thank you, Eli! I made a mistake - I forgot to add "Do not merge into
master" in the commit message. Do we need to add a commit on the master
branch which reverts this one?
Joseph
^ permalink raw reply [relevance 5%]
* bug#67390: 28; shorthands-font-lock-shorthands assumes shorthand uses same separator
2023-11-26 20:35 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-11-26 22:02 5% ` João Távora
2023-11-27 3:48 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-27 12:10 0% ` Eli Zaretskii
0 siblings, 2 replies; 200+ results
From: João Távora @ 2023-11-26 22:02 UTC (permalink / raw)
To: Joseph Turner, Eli Zaretskii; +Cc: 67390, Adam Porter, Jonas Bernoulli
On Sun, Nov 26, 2023 at 8:38 PM Joseph Turner <joseph@ushin.org> wrote:
>
> João Távora <joaotavora@gmail.com> writes:
>
> > On Sat, Nov 25, 2023 at 10:43 PM Joseph Turner <joseph@ushin.org> wrote:
> > So, benchmarking it will have to be, I'm afraid, because AFAIK
> > font-locking is a very performance sensitive area of Emacs.
>
> Yes. I would like to learn how to do this!
I'm CCing Eli.
In the past, ISTR, Eli suggested to benchmark such things by visiting a
very large file in its beginning, then scrolling down by holding
the down arrow or PgDn for some fixed time period, like 30 seconds.
The Emacs that scrolls the farthest is the most performant. Not
entirely fail-proof (other processes may interfere, etc), but not
bad either.
So here you could create very large fictitious Elisp file with 0, 1, 3 and
10 shorthands each and then run your version vs my version and record
the final line numbers. Then show the files and the numbers.
> > In the meantime I will push my patch, but keep the bug open to see
> > if it is worth pushing Joseph's version.
>
> Thank you!!
Now done in 36941e9e6a (master).
> I'm happy to discuss this further if others are interested.
I'm keeping this open.
João
^ permalink raw reply [relevance 5%]
* bug#67390: 28; shorthands-font-lock-shorthands assumes shorthand uses same separator
2023-11-26 22:02 5% ` João Távora
@ 2023-11-27 3:48 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-27 12:10 0% ` Eli Zaretskii
1 sibling, 0 replies; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-11-27 3:48 UTC (permalink / raw)
To: João Távora; +Cc: 67390, Adam Porter, Eli Zaretskii, Jonas Bernoulli
João Távora <joaotavora@gmail.com> writes:
> In the past, ISTR, Eli suggested to benchmark such things by visiting a
> very large file in its beginning, then scrolling down by holding
> the down arrow or PgDn for some fixed time period, like 30 seconds.
> The Emacs that scrolls the farthest is the most performant. Not
> entirely fail-proof (other processes may interfere, etc), but not
> bad either.
>
> So here you could create very large fictitious Elisp file with 0, 1, 3 and
> 10 shorthands each and then run your version vs my version and record
> the final line numbers. Then show the files and the numbers.
In a 2.5M Elisp file with 0 shorthand prefixes, after 30s of pressing
C-v (scroll-up-command), point was on line 19238.
I then tried the same file with 1 and 4 shorthands, and I got basically
the same result:
| With 1 shorthand prefix | |
|-------------------------+-------|
| No patch | 19447 |
| mismatch | 19238 |
| compare all prefixes | 19024 |
| With 4 shorthand prefixes | |
|---------------------------+-------|
| No patch | 19211 |
| mismatch | 19521 |
| compare all prefixes | 19339 |
There is a big margin of error (probably around 500-1000 lines) since my
method wasn't at all exact. I stopped holding C-v when the stopwatch on
another device hit 30s, and I might have held for ±1s.
If this approach to benchmarking is valid, I think it indicates that
shorthands has no significant effect on performance in either case,
though there may be a greater difference with more shorthand prefixes.
> My version keeps a behaviour that can be considered buggy.
> If a shorthand prefix has a common suffix with the longhand prefix
> then that suffix will not be highlighted. Like:
> ;; Local Variables:
> ;; read-symbol-shorthands: (("bcrumb-" . "breadcrumb-")
> ;; End:
> Here only "b" would be highlighted, effectively showing the user
> how much typing was saved. Is this wrong? Does it makes sense
> to use shorthands like this?
Another example case:
;; Local Variables:
;; read-symbol-shorthands: (("aw-" . "ace-window-")
;; End:
Here only "a" would be highlighted.
Thanks,
Joseph
^ permalink raw reply [relevance 5%]
* bug#66115: [PATCH] Ensure that directory is expanded in package-vc-checkout
2023-11-26 20:39 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-11-27 12:01 0% ` Eli Zaretskii
2023-12-08 10:25 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 200+ results
From: Eli Zaretskii @ 2023-11-27 12:01 UTC (permalink / raw)
To: Joseph Turner; +Cc: 66115-done, philipk
> From: Joseph Turner <joseph@breatheoutbreathe.in>
> Cc: philipk@posteo.net, 66115-done@debbugs.gnu.org
> Date: Sun, 26 Nov 2023 12:39:34 -0800
>
> > Thanks, installed on the emacs-29 branch, and closing the bug.
>
> Thank you, Eli! I made a mistake - I forgot to add "Do not merge into
> master" in the commit message. Do we need to add a commit on the master
> branch which reverts this one?
Yes, after the next merge from emacs-29 to master.
^ permalink raw reply [relevance 0%]
* bug#67390: 28; shorthands-font-lock-shorthands assumes shorthand uses same separator
2023-11-26 22:02 5% ` João Távora
2023-11-27 3:48 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-11-27 12:10 0% ` Eli Zaretskii
2023-11-29 8:21 0% ` João Távora
1 sibling, 1 reply; 200+ results
From: Eli Zaretskii @ 2023-11-27 12:10 UTC (permalink / raw)
To: João Távora; +Cc: joseph, 67390, jonas, adam
> From: João Távora <joaotavora@gmail.com>
> Date: Sun, 26 Nov 2023 22:02:01 +0000
> Cc: Jonas Bernoulli <jonas@bernoul.li>, 67390@debbugs.gnu.org,
> Adam Porter <adam@alphapapa.net>
>
> On Sun, Nov 26, 2023 at 8:38 PM Joseph Turner <joseph@ushin.org> wrote:
> >
> > João Távora <joaotavora@gmail.com> writes:
> >
> > > On Sat, Nov 25, 2023 at 10:43 PM Joseph Turner <joseph@ushin.org> wrote:
>
> > > So, benchmarking it will have to be, I'm afraid, because AFAIK
> > > font-locking is a very performance sensitive area of Emacs.
> >
> > Yes. I would like to learn how to do this!
>
> I'm CCing Eli.
>
> In the past, ISTR, Eli suggested to benchmark such things by visiting a
> very large file in its beginning, then scrolling down by holding
> the down arrow or PgDn for some fixed time period, like 30 seconds.
> The Emacs that scrolls the farthest is the most performant. Not
> entirely fail-proof (other processes may interfere, etc), but not
> bad either.
I still recommend this method. Something like the below:
(defun scroll-up-benchmark ()
(interactive)
(let ((oldgc gcs-done)
(oldtime (float-time)))
(condition-case nil (while t (scroll-up) (redisplay))
(error (message "GCs: %d Elapsed time: %f seconds"
(- gcs-done oldgc) (- (float-time) oldtime))))))
Evaluate the above, and the invoke it at the beginning of a large
file. Then compare the timings with different font-lock arrangements.
A variant is to scroll by N lines, not by pages. Just change the
above to call scroll-up with the argument of N, for example 1 (or any
other number, if you want).
^ permalink raw reply [relevance 0%]
* bug#63480: 30.0.50; [BUG] unimplemented logic regarding read-symbol-shorthands
@ 2023-11-29 7:45 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-29 8:12 5% ` João Távora
0 siblings, 1 reply; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-11-29 7:45 UTC (permalink / raw)
To: stefankangas; +Cc: 63480, ruijie, Jonas Bernoulli, joaotavora, Adam Porter
From: Stefan Kangas <stefankangas@gmail.com>
> João Távora <joaotavora@gmail.com> writes:
> > This is a duplicate of
> >
> > https://github.com/joaotavora/breadcrumb/issues/3
> >
> > which has already been solved. I updated the autoloads to use
> > longhand versions already a couple of months ago.
> OK, thanks.
> > I'll leave it to you if this issue can be closed or not.
> I guess the issue here is what you describe below? If so, I guess it
> should remain open until it is fixed.
> > Anyway, the problem with shorthands and autoloads remains.
> > The GitHub user 'dickmao' proposed a patch there, which I
> > didn't test, but I attach here.
> >
> > My idea for an alternative patch would be for the "autoload
> > extractor" (which I'm not familiar with) to see the shorthand
> > autoload but place it in longhand form in the generated
> > autoloads file. I don't have a patch for that idea,
> > unfortunately.
This bug affects not only autoloaded function definitions, but any
autoloaded form. For example, the following will not generate the
correct autoloads:
;;;###autoload
(with-eval-after-load 'optional-dependency
(cl-pushnew 'sns-var optional-dependency-var))
Instead, you must expand the shorthand symbol into its full form:
;;;###autoload
(with-eval-after-load 'optional-dependency
(cl-pushnew 'some-nice-string-utils-var optional-dependency-var))
For a real-world example, see
https://git.sr.ht/~ushin/hyperdrive.el/commit/48afc51ac22713f2c54f75a7ea3b5c6b0e12b53d
Thank you!
Joseph
^ permalink raw reply [relevance 5%]
* bug#67523: check-declare doesn't account for shorthands
@ 2023-11-29 8:03 4% Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-29 9:56 5% ` João Távora
0 siblings, 1 reply; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-11-29 8:03 UTC (permalink / raw)
To: 67523; +Cc: Adam Porter, Jonas Bernoulli, João Távora
On Emacs 29.1, when running `check-declare-file' on a file with
`declare-function' forms, I get
Warning (check-declare): said ‘some-nice-string-utils-foobar’ was defined in
some-nice-string-utils.el: function not found
The problem is that `check-declare-verify' attempts to search for the
full symbol name using this regular expression:
(setq re (format (if cflag
"^[ \t]*\\(DEFUN\\)[ \t]*([ \t]*\"%s\""
"^[ \t]*(\\(fset[ \t]+'\\|\
cl-def\\(?:generic\\|method\\|un\\)\\|\
def\\(?:un\\|subst\\|foo\\|method\\|class\\|\
ine-\\(?:derived\\|generic\\|\\(?:global\\(?:ized\\)?-\\)?minor\\)-mode\\|\
\\(?:ine-obsolete-function-\\)?alias[ \t]+'\\|\
ine-overloadable-function\\)\\)\
[ \t]*%s\\([ \t;]+\\|$\\)")
(regexp-opt (mapcar 'cadr fnlist) t)))
(while (re-search-forward re nil t)
...
)
where (mapcar 'cadr fnlist) is the full symbol name.
Since the full symbol name never appears in the file in which it was
defined, re-search-forward never finds it, and so "function not found".
A potential solution could be to convert the longhand symbol into its
shorthand form and pass that into re-search-forward. This is tricky
since there may be multiple different shorthands which could yield the
same longhand form. It might be more feasible to run re-search-forward
on a known common suffix portion of the symbol name, then with point on
the suspected definition, run `intern-soft' to get the full symbol name.
A workaround is to not use shorthands in function definitions.
Thoughts?
Joseph
^ permalink raw reply [relevance 4%]
* bug#63480: 30.0.50; [BUG] unimplemented logic regarding read-symbol-shorthands
2023-11-29 7:45 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-11-29 8:12 5% ` João Távora
2024-04-18 20:01 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 200+ results
From: João Távora @ 2023-11-29 8:12 UTC (permalink / raw)
To: Joseph Turner
Cc: 63480, Ruijie Yu, Jonas Bernoulli, Stefan Kangas, Adam Porter
[-- Attachment #1: Type: text/plain, Size: 712 bytes --]
On Wed, Nov 29, 2023, 07:45 Joseph Turner <joseph@breatheoutbreathe.in>
wrote:
> :
>
> ;;;###autoload
> (with-eval-after-load 'optional-dependency
> (cl-pushnew 'sns-var optional-dependency-var))
>
> Instead, you must expand the shorthand symbol into its full form:
>
> ;;;###autoload
> (with-eval-after-load 'optional-dependency
> (cl-pushnew 'some-nice-string-utils-var optional-dependency-var))
>
> For a real-world example, see
>
>
> https://git.sr.ht/~ushin/hyperdrive.el/commit/48afc51ac22713f2c54f75a7ea3b5c6b0e12b53d
Thanks for the extra case. I think this merits a fix in the autoload
extractor, watch should become autoload aware. I'll try to look at it.
João
>
>
[-- Attachment #2: Type: text/html, Size: 1435 bytes --]
^ permalink raw reply [relevance 5%]
* bug#67390: 28; shorthands-font-lock-shorthands assumes shorthand uses same separator
2023-11-27 12:10 0% ` Eli Zaretskii
@ 2023-11-29 8:21 0% ` João Távora
2023-11-29 9:12 4% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 200+ results
From: João Távora @ 2023-11-29 8:21 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Joseph Turner, 67390, Jonas Bernoulli, Adam Porter
[-- Attachment #1: Type: text/plain, Size: 2083 bytes --]
On Mon, Nov 27, 2023, 12:12 Eli Zaretskii <eliz@gnu.org> wrote:
> > From: João Távora <joaotavora@gmail.com>
> > Date: Sun, 26 Nov 2023 22:02:01 +0000
> > Cc: Jonas Bernoulli <jonas@bernoul.li>, 67390@debbugs.gnu.org,
> > Adam Porter <adam@alphapapa.net>
> >
> > On Sun, Nov 26, 2023 at 8:38 PM Joseph Turner <joseph@ushin.org> wrote:
> > >
> > > João Távora <joaotavora@gmail.com> writes:
> > >
> > > > On Sat, Nov 25, 2023 at 10:43 PM Joseph Turner <joseph@ushin.org>
> wrote:
> >
> > > > So, benchmarking it will have to be, I'm afraid, because AFAIK
> > > > font-locking is a very performance sensitive area of Emacs.
> > >
> > > Yes. I would like to learn how to do this!
> >
> > I'm CCing Eli.
> >
> > In the past, ISTR, Eli suggested to benchmark such things by visiting a
> > very large file in its beginning, then scrolling down by holding
> > the down arrow or PgDn for some fixed time period, like 30 seconds.
> > The Emacs that scrolls the farthest is the most performant. Not
> > entirely fail-proof (other processes may interfere, etc), but not
> > bad either.
>
> I still recommend this method. Something like the below:
>
> (defun scroll-up-benchmark ()
> (interactive)
> (let ((oldgc gcs-done)
> (oldtime (float-time)))
> (condition-case nil (while t (scroll-up) (redisplay))
> (error (message "GCs: %d Elapsed time: %f seconds"
> (- gcs-done oldgc) (- (float-time) oldtime))))))
>
> Evaluate the above, and the invoke it at the beginning of a large
> file. Then compare the timings with different font-lock arrangements.
>
> A variant is to scroll by N lines, not by pages. Just change the
> above to call scroll-up with the argument of N, for example 1 (or any
> other number, if you want).
>
Joseph can you try these variations? They're slightly more exact. Also show
at least one of the large lisp files or tell me how to generate one. If you
still don't find any significant slowdown, I think we can merge your patch.
João
>
[-- Attachment #2: Type: text/html, Size: 3396 bytes --]
^ permalink raw reply [relevance 0%]
* bug#67390: 28; shorthands-font-lock-shorthands assumes shorthand uses same separator
2023-11-29 8:21 0% ` João Távora
@ 2023-11-29 9:12 4% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-29 13:56 5% ` João Távora
0 siblings, 1 reply; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-11-29 9:12 UTC (permalink / raw)
To: João Távora; +Cc: 67390, Adam Porter, Eli Zaretskii, Jonas Bernoulli
João Távora <joaotavora@gmail.com> writes:
> On Mon, Nov 27, 2023, 12:12 Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: João Távora <joaotavora@gmail.com>
> > Date: Sun, 26 Nov 2023 22:02:01 +0000
> > Cc: Jonas Bernoulli <jonas@bernoul.li>, 67390@debbugs.gnu.org,
> > Adam Porter <adam@alphapapa.net>
> >
> > On Sun, Nov 26, 2023 at 8:38 PM Joseph Turner <joseph@ushin.org> wrote:
> > >
> > > João Távora <joaotavora@gmail.com> writes:
> > >
> > > > On Sat, Nov 25, 2023 at 10:43 PM Joseph Turner <joseph@ushin.org> wrote:
> >
> > > > So, benchmarking it will have to be, I'm afraid, because AFAIK
> > > > font-locking is a very performance sensitive area of Emacs.
> > >
> > > Yes. I would like to learn how to do this!
> >
> > I'm CCing Eli.
> >
> > In the past, ISTR, Eli suggested to benchmark such things by visiting a
> > very large file in its beginning, then scrolling down by holding
> > the down arrow or PgDn for some fixed time period, like 30 seconds.
> > The Emacs that scrolls the farthest is the most performant. Not
> > entirely fail-proof (other processes may interfere, etc), but not
> > bad either.
>
> I still recommend this method. Something like the below:
>
> (defun scroll-up-benchmark ()
> (interactive)
> (let ((oldgc gcs-done)
> (oldtime (float-time)))
> (condition-case nil (while t (scroll-up) (redisplay))
> (error (message "GCs: %d Elapsed time: %f seconds"
> (- gcs-done oldgc) (- (float-time) oldtime))))))
>
> Evaluate the above, and the invoke it at the beginning of a large
> file. Then compare the timings with different font-lock arrangements.
>
> A variant is to scroll by N lines, not by pages. Just change the
> above to call scroll-up with the argument of N, for example 1 (or any
> other number, if you want).
>
> Joseph can you try these variations? They're slightly more exact. Also show at least one of the large lisp files or tell me how to generate
> one. If you still don't find any significant slowdown, I think we can merge your patch.
I'm happy to try Eli's variation if you don't beat me to it ;)
My large lisp file consisted of copy-pasting with a kbd macro the body of
https://git.sr.ht/~ushin/hyperdrive.el/tree/master/item/hyperdrive-lib.el
until the file reached ~50K lines -- well over the limit I expected to
reach on my machine.
One potential issue with the patch is that multiple shorthand prefixes
might match, while assoc will return the first matching cons pair
read-symbol-shorthand.
For example in hyperdrive-lib.el, we use the following shorthands in
order to display "//" instead of "/-" as the prefix separator for
private symbols, like "h//format-entry" instead of "h/-format-entry":
;; read-symbol-shorthands: (
;; ("he//" . "hyperdrive-entry--")
;; ("he/" . "hyperdrive-entry-")
;; ("h//" . "hyperdrive--")
;; ("h/" . "hyperdrive-"))
However, if we rearrange the values like:
;; read-symbol-shorthands: (
;; ("he/" . "hyperdrive-entry-")
;; ("he//" . "hyperdrive-entry--")
;; ("h/" . "hyperdrive-")
;; ("h//" . "hyperdrive--"))
then shorthands doesn't add fontification for either "h//" or "he//".
(This surprised me - I was expecting to see just the "h/" and "he/"
highlit)
However, I'm starting to wonder whether this is a case of user error.
Should we avoid overlapping shorthand prefixes?
Thank you!!
Joseph
^ permalink raw reply [relevance 4%]
* bug#67523: check-declare doesn't account for shorthands
2023-11-29 8:03 4% bug#67523: check-declare doesn't account for shorthands Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-11-29 9:56 5% ` João Távora
2023-11-29 10:35 0% ` João Távora
0 siblings, 1 reply; 200+ results
From: João Távora @ 2023-11-29 9:56 UTC (permalink / raw)
To: Joseph Turner; +Cc: 67523, Adam Porter, Jonas Bernoulli
On Wed, Nov 29, 2023 at 9:12 AM Joseph Turner <joseph@ushin.org> wrote:
> A potential solution could be to convert the longhand symbol into its
> shorthand form and pass that into re-search-forward. This is tricky
> since there may be multiple different shorthands which could yield the
> same longhand form. It might be more feasible to run re-search-forward
> on a known common suffix portion of the symbol name, then with point on
> the suspected definition, run `intern-soft' to get the full symbol name.
No, this is brittle. Check-declare, if it's to be useful (is it?)
is probably meant to be as precise as possible.
> A workaround is to not use shorthands in function definitions.
That's letting the bad guys win :-)
> Thoughts?
As usual, my thoughts are that tools that read Lisp code
should use the Lisp reader, not regular expressions.
Here, check-declare should just walk the whole file.
When it finds a a symbol atom that matches a definition
form, look in the next atom and check if it matches the probe.
If you don't want to intern all the symbols in the you can read
to a separate obarray I think.
João
^ permalink raw reply [relevance 5%]
* bug#67523: check-declare doesn't account for shorthands
2023-11-29 9:56 5% ` João Távora
@ 2023-11-29 10:35 0% ` João Távora
2023-11-29 11:12 0% ` João Távora
0 siblings, 1 reply; 200+ results
From: João Távora @ 2023-11-29 10:35 UTC (permalink / raw)
To: Joseph Turner; +Cc: 67523, Adam Porter, Jonas Bernoulli
On Wed, Nov 29, 2023 at 9:56 AM João Távora <joaotavora@gmail.com> wrote:
>
> On Wed, Nov 29, 2023 at 9:12 AM Joseph Turner <joseph@ushin.org> wrote:
>
> > A potential solution could be to convert the longhand symbol into its
> > shorthand form and pass that into re-search-forward. This is tricky
> > since there may be multiple different shorthands which could yield the
> > same longhand form. It might be more feasible to run re-search-forward
> > on a known common suffix portion of the symbol name, then with point on
> > the suspected definition, run `intern-soft' to get the full symbol name.
>
> No, this is brittle. Check-declare, if it's to be useful (is it?)
> is probably meant to be as precise as possible.
>
> > A workaround is to not use shorthands in function definitions.
>
> That's letting the bad guys win :-)
>
> > Thoughts?
>
> As usual, my thoughts are that tools that read Lisp code
> should use the Lisp reader, not regular expressions.
>
> Here, check-declare should just walk the whole file.
Or maybe just this 100% guaranteed untested patch would work:
diff --git a/lisp/emacs-lisp/check-declare.el b/lisp/emacs-lisp/check-declare.el
index c887d95210c..00440276643 100644
--- a/lisp/emacs-lisp/check-declare.el
+++ b/lisp/emacs-lisp/check-declare.el
@@ -145,6 +145,7 @@ check-declare-verify
(if (file-regular-p fnfile)
(with-temp-buffer
(insert-file-contents fnfile)
+ (hack-local-variables) ;; for shorthands
;; defsubst's don't _have_ to be known at compile time.
(setq re (format (if cflag
"^[ \t]*\\(DEFUN\\)[ \t]*([ \t]*\"%s\""
@@ -158,7 +159,7 @@ check-declare-verify
(regexp-opt (mapcar 'cadr fnlist) t)))
(while (re-search-forward re nil t)
(skip-chars-forward " \t\n")
- (setq fn (match-string 2)
+ (setq fn (symbol-name (car (read-from-string (match-string 2))))
type (match-string 1)
;; (min . max) for a fixed number of arguments, or
;; arglists with optional elements.
^ permalink raw reply related [relevance 0%]
* bug#67523: check-declare doesn't account for shorthands
2023-11-29 10:35 0% ` João Távora
@ 2023-11-29 11:12 0% ` João Távora
2023-12-10 10:57 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 200+ results
From: João Távora @ 2023-11-29 11:12 UTC (permalink / raw)
To: Joseph Turner; +Cc: 67523, Adam Porter, Jonas Bernoulli
On Wed, Nov 29, 2023 at 10:35 AM João Távora <joaotavora@gmail.com> wrote:
>
> On Wed, Nov 29, 2023 at 9:56 AM João Távora <joaotavora@gmail.com> wrote:
> >
> > On Wed, Nov 29, 2023 at 9:12 AM Joseph Turner <joseph@ushin.org> wrote:
> >
> > > A potential solution could be to convert the longhand symbol into its
> > > shorthand form and pass that into re-search-forward. This is tricky
> > > since there may be multiple different shorthands which could yield the
> > > same longhand form. It might be more feasible to run re-search-forward
> > > on a known common suffix portion of the symbol name, then with point on
> > > the suspected definition, run `intern-soft' to get the full symbol name.
> >
> > No, this is brittle. Check-declare, if it's to be useful (is it?)
> > is probably meant to be as precise as possible.
> >
> > > A workaround is to not use shorthands in function definitions.
> >
> > That's letting the bad guys win :-)
> >
> > > Thoughts?
> >
> > As usual, my thoughts are that tools that read Lisp code
> > should use the Lisp reader, not regular expressions.
> >
> > Here, check-declare should just walk the whole file.
>
> Or maybe just this 100% guaranteed untested patch would work:
Sorry, that was 100% untested indeed. This patch seems to work:
diff --git a/lisp/emacs-lisp/check-declare.el b/lisp/emacs-lisp/check-declare.el
index c887d95210c..bc3844ca9be 100644
--- a/lisp/emacs-lisp/check-declare.el
+++ b/lisp/emacs-lisp/check-declare.el
@@ -145,21 +145,26 @@ check-declare-verify
(if (file-regular-p fnfile)
(with-temp-buffer
(insert-file-contents fnfile)
+ (unless cflag
+ ;; for syntax and shorthands
+ (lisp-data-mode)
+ (hack-local-variables))
;; defsubst's don't _have_ to be known at compile time.
- (setq re (format (if cflag
- "^[ \t]*\\(DEFUN\\)[ \t]*([ \t]*\"%s\""
- "^[ \t]*(\\(fset[ \t]+'\\|\
+ (setq re (if cflag
+ (format "^[ \t]*\\(DEFUN\\)[ \t]*([ \t]*\"%s\""
+ (regexp-opt (mapcar 'cadr fnlist) t))
+ "^[ \t]*(\\(fset[ \t]+'\\|\
cl-def\\(?:generic\\|method\\|un\\)\\|\
def\\(?:un\\|subst\\|foo\\|method\\|class\\|\
ine-\\(?:derived\\|generic\\|\\(?:global\\(?:ized\\)?-\\)?minor\\)-mode\\|\
\\(?:ine-obsolete-function-\\)?alias[ \t]+'\\|\
ine-overloadable-function\\)\\)\
-[ \t]*%s\\([ \t;]+\\|$\\)")
- (regexp-opt (mapcar 'cadr fnlist) t)))
+[ \t]*\\(\\(?:\\sw\\|\\s_\\)+\\)\\([ \t;]+\\|$\\)"))
(while (re-search-forward re nil t)
(skip-chars-forward " \t\n")
- (setq fn (match-string 2)
- type (match-string 1)
+ (setq fn (symbol-name (car (read-from-string (match-string 2)))))
+ (when (member fn (mapcar 'cadr fnlist))
+ (setq type (match-string 1)
;; (min . max) for a fixed number of arguments, or
;; arglists with optional elements.
;; (min) for arglists with &rest.
@@ -202,7 +207,7 @@ check-declare-verify
(t
'err))
;; alist of functions and arglist signatures.
- siglist (cons (cons fn sig) siglist)))))
+ siglist (cons (cons fn sig) siglist))))))
(dolist (e fnlist)
(setq arglist (nth 2 e)
type
^ permalink raw reply related [relevance 0%]
* bug#67390: 28; shorthands-font-lock-shorthands assumes shorthand uses same separator
2023-11-25 16:01 5% ` Jonas Bernoulli via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-25 22:42 9% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-11-29 13:30 0% ` João Távora
2023-11-29 23:27 0% ` João Távora
1 sibling, 1 reply; 200+ results
From: João Távora @ 2023-11-29 13:30 UTC (permalink / raw)
To: Jonas Bernoulli; +Cc: Joseph Turner, 67390, Adam Porter
On Sat, Nov 25, 2023 at 4:03 PM Jonas Bernoulli via Bug reports for
GNU Emacs, the Swiss army knife of text editors
<bug-gnu-emacs@gnu.org> wrote:
>
> Joseph Turner <joseph@ushin.org> writes:
>
> > + (car (shorthands--find-if
> > + (lambda (short)
> > + (string-prefix-p short (match-string 1)))
> > + read-symbol-shorthands #'car)))))
>
> Or simply:
> (car (assoc (match-string 1)
> read-symbol-shorthands
> #'string-prefix-p))
I don't think it works, at least in my 'assoc', the order
of string-prefix-p arguments must be switched. Pity
assoc or string-prefix-p decs didn't coordinate this.
(assoc probe read-symbol-shorthands (lambda (a b) (string-prefix-p b a)))
works
^ permalink raw reply [relevance 0%]
* bug#67390: 28; shorthands-font-lock-shorthands assumes shorthand uses same separator
2023-11-29 9:12 4% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-11-29 13:56 5% ` João Távora
0 siblings, 0 replies; 200+ results
From: João Távora @ 2023-11-29 13:56 UTC (permalink / raw)
To: Joseph Turner; +Cc: 67390, Adam Porter, Eli Zaretskii, Jonas Bernoulli
On Wed, Nov 29, 2023 at 9:29 AM Joseph Turner <joseph@ushin.org> wrote:
> > Joseph can you try these variations? They're slightly more exact. Also show at least one of the large lisp files or tell me how to generate
> > one. If you still don't find any significant slowdown, I think we can merge your patch.
>
> I'm happy to try Eli's variation if you don't beat me to it ;)
Great. No I don't think I will beat you to it :-), you have the
machinery setup already.
> However, if we rearrange the values like:
>
> ;; read-symbol-shorthands: (
> ;; ("he/" . "hyperdrive-entry-")
> ;; ("he//" . "hyperdrive-entry--")
> ;; ("h/" . "hyperdrive-")
> ;; ("h//" . "hyperdrive--"))
>
> then shorthands doesn't add fontification for either "h//" or "he//".
> (This surprised me - I was expecting to see just the "h/" and "he/"
> highlit)
>
> However, I'm starting to wonder whether this is a case of user error.
> Should we avoid overlapping shorthand prefixes?
No, but you should make sure the longer prefixes appear before.
It's not only a font-locking issue, if the shorter shorthand
appears before it could read to an unintended symbol. If shorthands
are
(("h/" . "hello-") ("h//" . "hyperdrive--"))
and you type
"h//warp"
, I'm fairly sure this will be read to
"hello-/warp"
, which is probably not what you intended
The documentation doesn't mention this, but it should, so patches
welcome for that.
In theory, lread.c could do this sorting for you. I don't think
this would affect performance, so patches welcome for that,
too.
Anyway, here's another patch that more or less bridges our two patches
and seems to do the right thing every time, even making you aware of
that ordering pitfall.
It could be more performant (or less, or about the same), so if
you can, please include it in your benchmarks. It does less
work when presented with a "/"-ending shorthand for a "-"-separated
symbol, so I'm starting to think that this "/" idea is a good
convention for shorthands (useful for distinguishing them in
github code, for example).
I've tested it briefly with those 'he/', 'he//', etc cases.
diff --git a/lisp/emacs-lisp/shorthands.el b/lisp/emacs-lisp/shorthands.el
index b0665a55695..69e9e252aee 100644
--- a/lisp/emacs-lisp/shorthands.el
+++ b/lisp/emacs-lisp/shorthands.el
@@ -76,14 +76,19 @@ shorthands-font-lock-shorthands
(sname (and probe (symbol-name probe)))
(mismatch (and sname (shorthands--mismatch-from-end
(match-string 1) sname)))
- (guess (and mismatch (1+ mismatch))))
- (when guess
- (when (and (< guess (1- (length (match-string 1))))
- ;; In bug#67390 we allow other separators
- (eq (char-syntax (aref (match-string 1) guess)) ?_))
- (setq guess (1+ guess)))
+ probe2)
+ (when mismatch
+ (unless (eq (char-syntax (aref (match-string 1) mismatch)) ?_)
+ (or probe2
+ (setq probe2
+ (buffer-substring (match-beginning 1)
+ (+ (match-beginning 1) mismatch))))
+ (setq mismatch (1- (length
+ (car (assoc probe2
+ read-symbol-shorthands
+ (lambda (a b)
(string-prefix-p b a))))))))
(add-face-text-property (match-beginning 1)
- (+ (match-beginning 1) guess)
+ (+ (match-beginning 1) (1+ mismatch))
'elisp-shorthand-font-lock-face))))))
(font-lock-add-keywords 'emacs-lisp-mode
'((shorthands-font-lock-shorthands)) t)
^ permalink raw reply related [relevance 5%]
* bug#67390: 28; shorthands-font-lock-shorthands assumes shorthand uses same separator
2023-11-29 13:30 0% ` João Távora
@ 2023-11-29 23:27 0% ` João Távora
0 siblings, 1 reply; 200+ results
From: João Távora @ 2023-11-29 23:27 UTC (permalink / raw)
To: Jonas Bernoulli; +Cc: Joseph Turner, 67390, Adam Porter
On Wed, Nov 29, 2023 at 1:30 PM João Távora <joaotavora@gmail.com> wrote:
>
> On Sat, Nov 25, 2023 at 4:03 PM Jonas Bernoulli via Bug reports for
> GNU Emacs, the Swiss army knife of text editors
> <bug-gnu-emacs@gnu.org> wrote:
> >
> > Joseph Turner <joseph@ushin.org> writes:
> >
> > > + (car (shorthands--find-if
> > > + (lambda (short)
> > > + (string-prefix-p short (match-string 1)))
> > > + read-symbol-shorthands #'car)))))
> >
> > Or simply:
> > (car (assoc (match-string 1)
> > read-symbol-shorthands
> > #'string-prefix-p))
>
> I don't think it works, at least in my 'assoc', the order
> of string-prefix-p arguments must be switched. Pity
> assoc or string-prefix-p decs didn't coordinate this.
nevermind, it does work if what you want is to see if the cars
of the alist are prefixes to the key, which is probably your
intention in this snippet.
^ permalink raw reply [relevance 0%]
* bug#67390: 28; shorthands-font-lock-shorthands assumes shorthand uses same separator
@ 2023-11-30 15:23 0% ` Eli Zaretskii
2023-12-09 18:50 8% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 0 replies; 200+ results
From: Eli Zaretskii @ 2023-11-30 15:23 UTC (permalink / raw)
To: João Távora; +Cc: joseph, 67390, jonas, adam
> From: João Távora <joaotavora@gmail.com>
> Date: Thu, 30 Nov 2023 14:16:51 +0000
> Cc: Joseph Turner <joseph@ushin.org>, 67390@debbugs.gnu.org,
> Adam Porter <adam@alphapapa.net>
>
> Hi all,
>
> I've been working on all these shorthand-related issues over the last
> two days and I have reasonably short fixes for all of them.
>
> For this particular issue (bug#67309), I've opted to
> use Joseph's patch with very slight adjustments, as it's the
> only one that guarantees correct behaviour and doesn't seem
> to impact performance.
>
> The other issues are:
>
> bug#63480 (loaddefs-gen.el doesn't know about shorthands)
> bug#67325 (prefix discovery i.e. register-definition-prefixes)
> bug#67523 (check-declare.el doesn't know about shorthands)
>
> I have all this in 6 commits in the bugfix/shorthand-fixes branch.
Thanks.
> Here's the full patch minus whitespace changes. If there are
> no comments I'll push in a few days' time.
The plan is to merge these to the master branch, right?
^ permalink raw reply [relevance 0%]
* bug#66115: [PATCH] Ensure that directory is expanded in package-vc-checkout
2023-11-27 12:01 0% ` Eli Zaretskii
@ 2023-12-08 10:25 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 0 replies; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-12-08 10:25 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 66115-done, philipk
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Joseph Turner <joseph@breatheoutbreathe.in>
>> Cc: philipk@posteo.net, 66115-done@debbugs.gnu.org
>> Date: Sun, 26 Nov 2023 12:39:34 -0800
>>
>> > Thanks, installed on the emacs-29 branch, and closing the bug.
>>
>> Thank you, Eli! I made a mistake - I forgot to add "Do not merge into
>> master" in the commit message. Do we need to add a commit on the master
>> branch which reverts this one?
>
> Yes, after the next merge from emacs-29 to master.
I see that you've done this already. Thank you!
^ permalink raw reply [relevance 5%]
* bug#67390: 28; shorthands-font-lock-shorthands assumes shorthand uses same separator
2023-11-30 15:23 0% ` Eli Zaretskii
@ 2023-12-09 18:50 8% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-03 7:10 11% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 1 reply; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-12-09 18:50 UTC (permalink / raw)
To: João Távora; +Cc: 67390, Adam Porter, Eli Zaretskii, Jonas Bernoulli
Hi João! Thanks for your patience - preparing for EmacsConf was a blast,
and now I'm on a plane to go visit my grandmother!
João Távora <joaotavora@gmail.com> writes:
> Hi all,
>
> I've been working on all these shorthand-related issues over the last
> two days and I have reasonably short fixes for all of them.
>
> For this particular issue (bug#67309), I've opted to
> use Joseph's patch with very slight adjustments, as it's the
> only one that guarantees correct behaviour and doesn't seem
> to impact performance.
>
> The other issues are:
>
> bug#63480 (loaddefs-gen.el doesn't know about shorthands)
> bug#67325 (prefix discovery i.e. register-definition-prefixes)
> bug#67523 (check-declare.el doesn't know about shorthands)
>
> I have all this in 6 commits in the bugfix/shorthand-fixes branch.
>
> Here's the full patch minus whitespace changes. If there are
> no comments I'll push in a few days' time.
>
> João
>
> diff --git a/doc/lispref/symbols.texi b/doc/lispref/symbols.texi
> index 1f3b677d7fb..18e80311177 100644
> --- a/doc/lispref/symbols.texi
> +++ b/doc/lispref/symbols.texi
> @@ -761,6 +761,23 @@ Shorthands
> ;; End:
> @end example
>
> +Note that if you have two shorthands in the same file where one is the
> +prefix of the other, the longer shorthand will be attempted first.
> +This happens regardless of the order you specify shorthands in the
> +local variables section of your file.
> +
> +@example
> +'(
> + t//foo ; reads to 'my-tricks--foo', not 'my-tricks-/foo'
> + t/foo ; reads to 'my-tricks-foo'
> + )
> +
> +;; Local Variables:
> +;; read-symbol-shorthands: (("t/" . "my-tricks-")
> +;; ("t//" . "my-tricks--")
> +;; End:
> +@end example
> +
> @subsection Exceptions
Clear and concise.
> There are two exceptions to rules governing Shorthand transformations:
> diff --git a/lisp/emacs-lisp/check-declare.el b/lisp/emacs-lisp/check-declare.el
> index c887d95210c..b19aedf314d 100644
> --- a/lisp/emacs-lisp/check-declare.el
> +++ b/lisp/emacs-lisp/check-declare.el
> @@ -145,21 +145,26 @@ check-declare-verify
> (if (file-regular-p fnfile)
> (with-temp-buffer
> (insert-file-contents fnfile)
> + (unless cflag
> + ;; If in Elisp, ensure syntax and shorthands available
> + (set-syntax-table emacs-lisp-mode-syntax-table)
> + (let (enable-local-variables) (hack-local-variables)))
> ;; defsubst's don't _have_ to be known at compile time.
> - (setq re (format (if cflag
> - "^[ \t]*\\(DEFUN\\)[ \t]*([ \t]*\"%s\""
> + (setq re (if cflag
> + (format "^[ \t]*\\(DEFUN\\)[ \t]*([ \t]*\"%s\""
> + (regexp-opt (mapcar 'cadr fnlist) t))
> "^[ \t]*(\\(fset[ \t]+'\\|\
> cl-def\\(?:generic\\|method\\|un\\)\\|\
> def\\(?:un\\|subst\\|foo\\|method\\|class\\|\
> ine-\\(?:derived\\|generic\\|\\(?:global\\(?:ized\\)?-\\)?minor\\)-mode\\|\
> \\(?:ine-obsolete-function-\\)?alias[ \t]+'\\|\
> ine-overloadable-function\\)\\)\
> -[ \t]*%s\\([ \t;]+\\|$\\)")
> - (regexp-opt (mapcar 'cadr fnlist) t)))
> +[ \t]*\\(\\(?:\\sw\\|\\s_\\)+\\)\\([ \t;]+\\|$\\)"))
Would you explain what this regexp is intended to match?
> (while (re-search-forward re nil t)
> (skip-chars-forward " \t\n")
> - (setq fn (match-string 2)
> - type (match-string 1)
> + (setq fn (symbol-name (car (read-from-string (match-string 2)))))
> + (when (member fn (mapcar 'cadr fnlist))
> + (setq type (match-string 1)
> ;; (min . max) for a fixed number of arguments, or
> ;; arglists with optional elements.
> ;; (min) for arglists with &rest.
> @@ -202,7 +207,7 @@ check-declare-verify
> (t
> 'err))
> ;; alist of functions and arglist signatures.
> - siglist (cons (cons fn sig) siglist)))))
> + siglist (cons (cons fn sig) siglist))))))
> (dolist (e fnlist)
> (setq arglist (nth 2 e)
> type
On my machine, this patch removes some of the check-declare "function
not found" errors, but not all. For example, with hyperdrive-lib.el:
(check-declare-file "~/.local/src/hyperdrive.el/hyperdrive-lib.el")
Before this patch, the "*Check Declarations Warnings*" buffer shows:
--8<---------------cut here---------------start------------->8---
■ hyperdrive-lib.el:44:Warning (check-declare): said ‘h/mode’ was defined in
../../../.emacs.d/elpa/hyperdrive/hyperdrive.el: function not found
■ hyperdrive-lib.el:508:Warning (check-declare): said ‘h/history’ was defined
in ../../../.emacs.d/elpa/hyperdrive/hyperdrive-history.el: function not
found
■ hyperdrive-lib.el:1283:Warning (check-declare): said ‘h/org--link-goto’ was
defined in ../../../.emacs.d/elpa/hyperdrive/hyperdrive-org.el: function
not found
■ hyperdrive-lib.el:45:Warning (check-declare): said ‘h/dir-mode’ was defined
in ../../../.emacs.d/elpa/hyperdrive/hyperdrive-dir.el: function not found
■ hyperdrive-lib.el:1069:Warning (check-declare): said
‘h/dir--entry-at-point’ was defined in
../../../.emacs.d/elpa/hyperdrive/hyperdrive-dir.el: function not found
■ hyperdrive-lib.el:1332:Warning (check-declare): said ‘h/dir-handler’ was
defined in ../../../.emacs.d/elpa/hyperdrive/hyperdrive-dir.el: function
not found
--8<---------------cut here---------------end--------------->8---
and after your patch:
--8<---------------cut here---------------start------------->8---
■ hyperdrive-lib.el:44:Warning (check-declare): said ‘h/mode’ was defined in
../../../.emacs.d/elpa/hyperdrive/hyperdrive.el: function not found
■ hyperdrive-lib.el:508:Warning (check-declare): said ‘h/history’ was defined
in ../../../.emacs.d/elpa/hyperdrive/hyperdrive-history.el: function not
found
■ hyperdrive-lib.el:1332:Warning (check-declare): said ‘h/dir-handler’ was
defined in ../../../.emacs.d/elpa/hyperdrive/hyperdrive-dir.el: function
not found
--8<---------------cut here---------------end--------------->8---
Are you able to reproduce this on your machine?
> diff --git a/lisp/emacs-lisp/loaddefs-gen.el b/lisp/emacs-lisp/loaddefs-gen.el
> index 04bea4723a2..e8093200bec 100644
> --- a/lisp/emacs-lisp/loaddefs-gen.el
> +++ b/lisp/emacs-lisp/loaddefs-gen.el
> @@ -378,6 +378,7 @@ loaddefs-generate--parse-file
> (let ((defs nil)
> (load-name (loaddefs-generate--file-load-name file main-outfile))
> (compute-prefixes t)
> + read-symbol-shorthands
> local-outfile inhibit-autoloads)
> (with-temp-buffer
> (insert-file-contents file)
> @@ -399,7 +400,19 @@ loaddefs-generate--parse-file
> (setq inhibit-autoloads (read (current-buffer)))))
> (save-excursion
> (when (re-search-forward "autoload-compute-prefixes: *" nil t)
> - (setq compute-prefixes (read (current-buffer))))))
> + (setq compute-prefixes (read (current-buffer)))))
> + (save-excursion
> + ;; since we're "open-coding" we have to repeat more
> + ;; complicated logic in `hack-local-variables'.
> + (when (re-search-forward "read-symbol-shorthands: *" nil t)
> + (let* ((commentless (replace-regexp-in-string
> + "\n\\s-*;+" ""
> + (buffer-substring (point) (point-max))))
> + (unsorted-shorthands (car (read-from-string commentless))))
> + (setq read-symbol-shorthands
> + (sort unsorted-shorthands
> + (lambda (sh1 sh2)
> + (> (length (car sh1)) (length (car sh2))))))))))
IIUC, the intention here is to jump to a final "Local Variables"
declaration at the end of the file, then remove ";;", then read in the
uncommented value of `read-symbol-shorthands'.
Since `read-from-string' just reads one expression, the above hunk works
when there are more local variables after read-symbol-shorthands:
;; Local Variables:
;; read-symbol-shorthands: (("bc-" . "breadcrumb-"))
;; autoload-compute-prefixes: nil
;; End:
But if the read-symbol-shorthands declaration comes at the top, as in...
-*- read-symbol-shorthands: (("bc-" . "breadcrumb-")); -*-
...then this form will allocate two strings almost as long as the file.
Here's an alternative hack attempting to uncomment and read the minimum:
diff --git a/lisp/emacs-lisp/loaddefs-gen.el b/lisp/emacs-lisp/loaddefs-gen.el
index e8093200bec..406e4b28f1f 100644
--- a/lisp/emacs-lisp/loaddefs-gen.el
+++ b/lisp/emacs-lisp/loaddefs-gen.el
@@ -404,10 +404,13 @@ don't include."
(save-excursion
;; since we're "open-coding" we have to repeat more
;; complicated logic in `hack-local-variables'.
- (when (re-search-forward "read-symbol-shorthands: *" nil t)
- (let* ((commentless (replace-regexp-in-string
+ (when-let ((beg
+ (re-search-forward "read-symbol-shorthands: *" nil t)))
+ ;; `read-symbol-shorthands' alist ends with two parens.
+ (let* ((end (re-search-forward ")[;\n\s]*)"))
+ (commentless (replace-regexp-in-string
"\n\\s-*;+" ""
- (buffer-substring (point) (point-max))))
+ (buffer-substring beg end)))
(unsorted-shorthands (car (read-from-string commentless))))
(setq read-symbol-shorthands
(sort unsorted-shorthands
> ;; We always return the package version (even for pre-dumped
> ;; files).
> @@ -486,7 +499,11 @@ loaddefs-generate--compute-prefixes
> (while (re-search-forward
> "^(\\(def[^ \t\n]+\\)[ \t\n]+['(]*\\([^' ()\"\n]+\\)[\n \t]" nil t)
> (unless (member (match-string 1) autoload-ignored-definitions)
> - (let ((name (match-string-no-properties 2)))
> + (let* ((name (match-string-no-properties 2))
> + ;; Consider `read-symbol-shorthands'.
> + (probe (let ((obarray (obarray-make)))
> + (car (read-from-string name)))))
> + (setq name (symbol-name probe))
> (when (save-excursion
> (goto-char (match-beginning 0))
> (or (bobp)
> diff --git a/lisp/emacs-lisp/shorthands.el b/lisp/emacs-lisp/shorthands.el
> index b0665a55695..69b562e3c7e 100644
> --- a/lisp/emacs-lisp/shorthands.el
> +++ b/lisp/emacs-lisp/shorthands.el
> @@ -52,38 +52,26 @@ elisp-shorthand-font-lock-face
> :version "28.1"
> :group 'font-lock-faces)
>
> -(defun shorthands--mismatch-from-end (str1 str2)
> - "Tell index of first mismatch in STR1 and STR2, from end.
> -The index is a valid 0-based index on STR1. Returns nil if STR1
> -equals STR2. Return 0 if STR1 is a suffix of STR2."
> - (cl-loop with l1 = (length str1) with l2 = (length str2)
> - for i from 1
> - for i1 = (- l1 i) for i2 = (- l2 i)
> - while (eq (aref str1 i1) (aref str2 i2))
> - if (zerop i2) return (if (zerop i1) nil i1)
> - if (zerop i1) return 0
> - finally (return i1)))
> -
> (defun shorthands-font-lock-shorthands (limit)
> + "Font lock until LIMIT considering `read-symbol-shorthands'."
> (when read-symbol-shorthands
> (while (re-search-forward
> (concat "\\_<\\(" (rx lisp-mode-symbol) "\\)\\_>")
> limit t)
> (let* ((existing (get-text-property (match-beginning 1) 'face))
> + (print-name (match-string 1))
> (probe (and (not (memq existing '(font-lock-comment-face
> font-lock-string-face)))
> - (intern-soft (match-string 1))))
> - (sname (and probe (symbol-name probe)))
> - (mismatch (and sname (shorthands--mismatch-from-end
> - (match-string 1) sname)))
> - (guess (and mismatch (1+ mismatch))))
> - (when guess
> - (when (and (< guess (1- (length (match-string 1))))
> - ;; In bug#67390 we allow other separators
> - (eq (char-syntax (aref (match-string 1) guess)) ?_))
> - (setq guess (1+ guess)))
> + (intern-soft print-name)))
> + (symbol-name (and probe (symbol-name probe)))
> + (prefix (and symbol-name
> + (not (string-equal print-name symbol-name))
> + (car (assoc print-name
> + read-symbol-shorthands
> + #'string-prefix-p)))))
> + (when prefix
> (add-face-text-property (match-beginning 1)
> - (+ (match-beginning 1) guess)
> + (+ (match-beginning 1) (length prefix))
> 'elisp-shorthand-font-lock-face))))))
Works well. let-binding `symbol-name' and `print-name' is good improvement.
> (font-lock-add-keywords 'emacs-lisp-mode
> '((shorthands-font-lock-shorthands)) t)
> diff --git a/lisp/files.el b/lisp/files.el
> index 1cdcec23b11..b266d0727ec 100644
> --- a/lisp/files.el
> +++ b/lisp/files.el
> @@ -3735,7 +3735,8 @@ before-hack-local-variables-hook
> This hook is called only if there is at least one file-local
> variable to set.")
>
> -(defvar permanently-enabled-local-variables '(lexical-binding)
> +(defvar permanently-enabled-local-variables
> + '(lexical-binding read-symbol-shorthands)
> "A list of file-local variables that are always enabled.
> This overrides any `enable-local-variables' setting.")
>
> @@ -4171,6 +4172,13 @@ hack-local-variables--find-variables
> ;; to use 'thisbuf's name in the
> ;; warning message.
> (or (buffer-file-name thisbuf) ""))))))
> + ((eq var 'read-symbol-shorthands)
> + ;; Sort automatically by shorthand length
> + ;; descending
> + (setq val (sort val
> + (lambda (sh1 sh2) (>
> (length (car sh1))
> +
> (length (car sh2))))))
> + (push (cons 'read-symbol-shorthands val) result))
> ((and (eq var 'mode) handle-mode))
> (t
> (ignore-errors
Good catch. I agree that longer shorthands should be applied first.
-----
A couple typo nits on the commit message of "Improve
shorthands-font-lock-shorthands (bug#67390)":
- h//thingy ; hilits "//" reads to 'hyperdrive--thingy'
+ h//thingy ; hilits "h//" reads to 'hyperdrive--thingy'
- Co-authored-by: João Távora <joaotavora@gmail.com>
+ Co-authored-by: Joseph Turner <joseph@breatheoutbreathe.in>
Thank you!
Joseph
^ permalink raw reply related [relevance 8%]
* bug#67523: check-declare doesn't account for shorthands
2023-11-29 11:12 0% ` João Távora
@ 2023-12-10 10:57 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 0 replies; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-12-10 10:57 UTC (permalink / raw)
To: João Távora; +Cc: 67523, Adam Porter, Jonas Bernoulli
João Távora <joaotavora@gmail.com> writes:
> On Wed, Nov 29, 2023 at 10:35 AM João Távora <joaotavora@gmail.com> wrote:
>>
>> On Wed, Nov 29, 2023 at 9:56 AM João Távora <joaotavora@gmail.com> wrote:
>> >
>> > On Wed, Nov 29, 2023 at 9:12 AM Joseph Turner <joseph@ushin.org> wrote:
>> >
>> > > A potential solution could be to convert the longhand symbol into its
>> > > shorthand form and pass that into re-search-forward. This is tricky
>> > > since there may be multiple different shorthands which could yield the
>> > > same longhand form. It might be more feasible to run re-search-forward
>> > > on a known common suffix portion of the symbol name, then with point on
>> > > the suspected definition, run `intern-soft' to get the full symbol name.
>> >
>> > No, this is brittle. Check-declare, if it's to be useful (is it?)
>> > is probably meant to be as precise as possible.
>> >
>> > > A workaround is to not use shorthands in function definitions.
>> >
>> > That's letting the bad guys win :-)
>> >
>> > > Thoughts?
>> >
>> > As usual, my thoughts are that tools that read Lisp code
>> > should use the Lisp reader, not regular expressions.
>> >
>> > Here, check-declare should just walk the whole file.
>>
>> Or maybe just this 100% guaranteed untested patch would work:
>
> Sorry, that was 100% untested indeed. This patch seems to work:
>
> diff --git a/lisp/emacs-lisp/check-declare.el b/lisp/emacs-lisp/check-declare.el
> index c887d95210c..bc3844ca9be 100644
> --- a/lisp/emacs-lisp/check-declare.el
> +++ b/lisp/emacs-lisp/check-declare.el
> @@ -145,21 +145,26 @@ check-declare-verify
> (if (file-regular-p fnfile)
> (with-temp-buffer
> (insert-file-contents fnfile)
> + (unless cflag
> + ;; for syntax and shorthands
> + (lisp-data-mode)
> + (hack-local-variables))
> ;; defsubst's don't _have_ to be known at compile time.
> - (setq re (format (if cflag
> - "^[ \t]*\\(DEFUN\\)[ \t]*([ \t]*\"%s\""
> - "^[ \t]*(\\(fset[ \t]+'\\|\
> + (setq re (if cflag
> + (format "^[ \t]*\\(DEFUN\\)[ \t]*([ \t]*\"%s\""
> + (regexp-opt (mapcar 'cadr fnlist) t))
> + "^[ \t]*(\\(fset[ \t]+'\\|\
> cl-def\\(?:generic\\|method\\|un\\)\\|\
> def\\(?:un\\|subst\\|foo\\|method\\|class\\|\
> ine-\\(?:derived\\|generic\\|\\(?:global\\(?:ized\\)?-\\)?minor\\)-mode\\|\
> \\(?:ine-obsolete-function-\\)?alias[ \t]+'\\|\
> ine-overloadable-function\\)\\)\
> -[ \t]*%s\\([ \t;]+\\|$\\)")
> - (regexp-opt (mapcar 'cadr fnlist) t)))
> +[ \t]*\\(\\(?:\\sw\\|\\s_\\)+\\)\\([ \t;]+\\|$\\)"))
> (while (re-search-forward re nil t)
> (skip-chars-forward " \t\n")
> - (setq fn (match-string 2)
> - type (match-string 1)
> + (setq fn (symbol-name (car (read-from-string (match-string 2)))))
> + (when (member fn (mapcar 'cadr fnlist))
> + (setq type (match-string 1)
> ;; (min . max) for a fixed number of arguments, or
> ;; arglists with optional elements.
> ;; (min) for arglists with &rest.
> @@ -202,7 +207,7 @@ check-declare-verify
> (t
> 'err))
> ;; alist of functions and arglist signatures.
> - siglist (cons (cons fn sig) siglist)))))
> + siglist (cons (cons fn sig) siglist))))))
> (dolist (e fnlist)
> (setq arglist (nth 2 e)
> type
IIUC, this patch is being merged in response to bug#67390.
^ permalink raw reply [relevance 5%]
* bug#66187: read-file-name unexpected behavior when MUSTMATCH is a function
@ 2023-12-19 2:52 9% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-09 8:06 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-12-19 2:52 UTC (permalink / raw)
To: Stefan Monnier; +Cc: michael_heerdegen, Eli Zaretskii, philipk, 66187
[-- Attachment #1: Type: text/plain, Size: 1733 bytes --]
Hello!
For reference, here's the little snippet I'm testing with:
(completing-read "Prompt: " '("a" "b") nil
(lambda (input)
(string= "a" input)))
where the only expected valid input is "a".
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> Here's another potential solution. While the attached patch seems to
>> work, I'm not sure that minibuffer-completion-confirm should be checked
>> in completion--do-completion instead of completion--complete-and-exit.
>
> It's definitely better to check it in `completion--complete-and-exit`
> (which is about exiting and thus related to whether the content is
> acceptable) than in `completion--do-completion` (which is just about
> completion).
I'm still not sure `completion--complete-and-exit' is the best place to
check that input is valid before exiting.
`completion--do-completion' contains the following cond clause, which
prevents the user from exiting with, e.g., "c".
((null comp)
(minibuffer-hide-completions)
(unless completion-fail-discreetly
(ding)
(completion--message "No match"))
(minibuffer--bitset nil nil nil))
Perhaps we should also run that same body when REQUIRE-MATCH is a
function which returns nil?
> The patch looks OK, thanks. We could make it call `completion-function`
> instead of saying "no match" (after all, it has "complete" in its name),
> but it comes with its own set of problems.
If I understand correctly, the attached patch does this.
I think this works inside of `completion-complete-and-exit', but maybe
not inside of `minibuffer-force-complete-and-exit' since the former
calls `completion--do-completion' internally but the latter does not.
Still exploring ideas... Thanks!
Joseph
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Fix-completing-read-functional-REQUIRE-MATCH-behavio-2.patch --]
[-- Type: text/x-diff, Size: 1803 bytes --]
From 7b779782504a7b94f64f100a1f8bb71c483873e5 Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Mon, 18 Dec 2023 22:41:24 -0500
Subject: [PATCH] Fix completing-read functional REQUIRE-MATCH behavior
* lisp/minibuffer.el (completion--do-completion): Refuse to exit
minibuffer when REQUIRE-MATCH is a function which returns nil.
(completion--complete-and-exit): Delegate handling of functional
REQUIRE-MATCH to completion-function.
See bug#66187.
---
lisp/minibuffer.el | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 5c12d9fc914..5d26ff2423e 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -1408,7 +1408,11 @@ when the buffer's text is already an exact match."
(- (point) beg)
md)))
(cond
- ((null comp)
+ ((or (null comp)
+ (and (eq t comp)
+ (functionp minibuffer-completion-confirm)
+ (not (funcall minibuffer-completion-confirm
+ (buffer-substring beg end)))))
(minibuffer-hide-completions)
(unless completion-fail-discreetly
(ding)
@@ -1849,10 +1853,8 @@ appear to be a match."
;; Allow user to specify null string
((= beg end) (funcall exit-function))
;; The CONFIRM argument is a predicate.
- ((and (functionp minibuffer-completion-confirm)
- (funcall minibuffer-completion-confirm
- (buffer-substring beg end)))
- (funcall exit-function))
+ ((functionp minibuffer-completion-confirm)
+ (funcall completion-function))
;; See if we have a completion from the table.
((test-completion (buffer-substring beg end)
minibuffer-completion-table
--
2.41.0
^ permalink raw reply related [relevance 9%]
* bug#68158: isearch-wrap-pause 'no or 'no-ding breaks isearch-delete-char
@ 2023-12-30 22:56 5% Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-04 11:10 0% ` Eli Zaretskii
0 siblings, 1 reply; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-12-30 22:56 UTC (permalink / raw)
To: 68158
With emacs -Q, in the buffer which pops open after...
(progn
(setopt isearch-wrap-pause 'no)
;; (setopt isearch-wrap-pause 'no-ding) ; this causes the same problem
(with-current-buffer (generate-new-buffer "isearch-wrap-pause-test")
(insert "bar")
(goto-char (point-min))
(pop-to-buffer (current-buffer))))
...run isearch for "baz" with...
C-s b a z
...then attempt to delete the non-matching "z" character with DEL.
Expected contents of minibuffer:
"Isearch: ba"
Actual contents of minibuffer:
"Failing overwrapped I-search: baz"
Pressing DEL a second time actually deletes the "z".
Thanks for your help!!
Joseph
GNU Emacs 29.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.37,
cairo version 1.16.0)
^ permalink raw reply [relevance 5%]
* bug#68158: isearch-wrap-pause 'no or 'no-ding breaks isearch-delete-char
2023-12-30 22:56 5% bug#68158: isearch-wrap-pause 'no or 'no-ding breaks isearch-delete-char Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-01-04 11:10 0% ` Eli Zaretskii
0 siblings, 1 reply; 200+ results
From: Eli Zaretskii @ 2024-01-04 11:10 UTC (permalink / raw)
To: Joseph Turner, Juri Linkov; +Cc: 68158
> Date: Sat, 30 Dec 2023 14:56:13 -0800
> From: Joseph Turner via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>
> With emacs -Q, in the buffer which pops open after...
>
> (progn
> (setopt isearch-wrap-pause 'no)
> ;; (setopt isearch-wrap-pause 'no-ding) ; this causes the same problem
> (with-current-buffer (generate-new-buffer "isearch-wrap-pause-test")
> (insert "bar")
> (goto-char (point-min))
> (pop-to-buffer (current-buffer))))
>
> ...run isearch for "baz" with...
>
> C-s b a z
>
> ...then attempt to delete the non-matching "z" character with DEL.
>
> Expected contents of minibuffer:
>
> "Isearch: ba"
>
> Actual contents of minibuffer:
>
> "Failing overwrapped I-search: baz"
>
> Pressing DEL a second time actually deletes the "z".
>
> Thanks for your help!!
>
> Joseph
>
> GNU Emacs 29.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.37,
> cairo version 1.16.0)
Juri, could you please look into this? It seems to be a regression in
Emacs 29.1 due to your changes in commit 7320a812e, to solve
bug#56535. I guess we need to distinguish between self-inserting
characters and DEL?
^ permalink raw reply [relevance 0%]
* bug#68158: isearch-wrap-pause 'no or 'no-ding breaks isearch-delete-char
@ 2024-01-04 17:49 0% ` Eli Zaretskii
2024-01-04 18:58 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 0 replies; 200+ results
From: Eli Zaretskii @ 2024-01-04 17:49 UTC (permalink / raw)
To: Juri Linkov; +Cc: 68158, joseph
> From: Juri Linkov <juri@linkov.net>
> Cc: Joseph Turner <joseph@breatheoutbreathe.in>, 68158@debbugs.gnu.org
> Date: Thu, 04 Jan 2024 19:02:52 +0200
>
> >> C-s b a z
> >>
> >> ...then attempt to delete the non-matching "z" character with DEL.
> >>
> >> GNU Emacs 29.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.37,
> >> cairo version 1.16.0)
> >
> > Juri, could you please look into this? It seems to be a regression in
> > Emacs 29.1 due to your changes in commit 7320a812e, to solve
> > bug#56535. I guess we need to distinguish between self-inserting
> > characters and DEL?
>
> This means that we need to preclude 'isearch-push-state' in 'isearch-repeat'
> from updating 'isearch-cmds'.
>
> Should I push this patch to the emacs-29 branch? It looks safe.
Yes, please.
Thanks.
^ permalink raw reply [relevance 0%]
* bug#68158: isearch-wrap-pause 'no or 'no-ding breaks isearch-delete-char
2024-01-04 17:49 0% ` Eli Zaretskii
@ 2024-01-04 18:58 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 0 replies; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-01-04 18:58 UTC (permalink / raw)
To: Juri Linkov; +Cc: Eli Zaretskii, 68158
Juri Linkov <juri@linkov.net> writes:
[...]
> This means that we need to preclude 'isearch-push-state' in 'isearch-repeat'
> from updating 'isearch-cmds'.
>
> Should I push this patch to the emacs-29 branch? It looks safe.
Thank you! This solves the problem on my machine.
Joseph
^ permalink raw reply [relevance 5%]
* bug#68251: message-yank-buffer insert many copies of image
@ 2024-01-05 5:09 5% Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-05 12:09 0% ` Eli Zaretskii
0 siblings, 1 reply; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-01-05 5:09 UTC (permalink / raw)
To: 68251
To reproduce:
- ~emacs -Q~
- Open an image in a buffer
- Create another buffer, call ~M-x message-mode~
- Run ~message-yank-buffer~, select the buffer with the image
Expected:
One image is inserted into the buffer.
Actual:
Many images are inserted into the buffer.
GNU Emacs 29.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.37, cairo version 1.16.0)
^ permalink raw reply [relevance 5%]
* bug#68251: message-yank-buffer insert many copies of image
2024-01-05 5:09 5% bug#68251: message-yank-buffer insert many copies of image Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-01-05 12:09 0% ` Eli Zaretskii
2024-01-05 15:58 0% ` Eli Zaretskii
2024-01-05 16:22 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 2 replies; 200+ results
From: Eli Zaretskii @ 2024-01-05 12:09 UTC (permalink / raw)
To: Joseph Turner; +Cc: 68251
> Date: Thu, 04 Jan 2024 21:09:23 -0800
> From: Joseph Turner via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>
> To reproduce:
> - ~emacs -Q~
> - Open an image in a buffer
> - Create another buffer, call ~M-x message-mode~
> - Run ~message-yank-buffer~, select the buffer with the image
>
> Expected:
>
> One image is inserted into the buffer.
>
> Actual:
>
> Many images are inserted into the buffer.
It isn't specific to images: it happens with any 'display' property
that spans more than one text line. message-yank-buffer looks at
buffer text and ignores the 'display' properties, so it inserts every
line after quoting it, and this you get as many copies of the
'display' property as there are newlines in the text covered by the
'display' property.
^ permalink raw reply [relevance 0%]
* bug#68251: message-yank-buffer insert many copies of image
2024-01-05 12:09 0% ` Eli Zaretskii
@ 2024-01-05 15:58 0% ` Eli Zaretskii
2024-01-05 16:24 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-05 16:22 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 1 reply; 200+ results
From: Eli Zaretskii @ 2024-01-05 15:58 UTC (permalink / raw)
To: joseph; +Cc: 68251
> Cc: 68251@debbugs.gnu.org
> Date: Fri, 05 Jan 2024 14:09:37 +0200
> From: Eli Zaretskii <eliz@gnu.org>
>
> > Date: Thu, 04 Jan 2024 21:09:23 -0800
> > From: Joseph Turner via "Bug reports for GNU Emacs,
> > the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> >
> > To reproduce:
> > - ~emacs -Q~
> > - Open an image in a buffer
> > - Create another buffer, call ~M-x message-mode~
> > - Run ~message-yank-buffer~, select the buffer with the image
> >
> > Expected:
> >
> > One image is inserted into the buffer.
> >
> > Actual:
> >
> > Many images are inserted into the buffer.
>
> It isn't specific to images: it happens with any 'display' property
> that spans more than one text line. message-yank-buffer looks at
> buffer text and ignores the 'display' properties, so it inserts every
> line after quoting it, and this you get as many copies of the
> 'display' property as there are newlines in the text covered by the
> 'display' property.
Btw: how is it useful to yank images into an email message? What do
you expect Emacs to send when the email with these citations is sent?
To DTRT here Emacs would need to produce a MIME attachment with the
image, won't it?
^ permalink raw reply [relevance 0%]
* bug#68251: message-yank-buffer insert many copies of image
2024-01-05 12:09 0% ` Eli Zaretskii
2024-01-05 15:58 0% ` Eli Zaretskii
@ 2024-01-05 16:22 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 0 replies; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-01-05 16:22 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 68251-done
Happy New Year, Eli!
Eli Zaretskii <eliz@gnu.org> writes:
>> Date: Thu, 04 Jan 2024 21:09:23 -0800
>> From: Joseph Turner via "Bug reports for GNU Emacs,
>> the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>>
>> To reproduce:
>> - ~emacs -Q~
>> - Open an image in a buffer
>> - Create another buffer, call ~M-x message-mode~
>> - Run ~message-yank-buffer~, select the buffer with the image
>>
>> Expected:
>>
>> One image is inserted into the buffer.
>>
>> Actual:
>>
>> Many images are inserted into the buffer.
>
> It isn't specific to images: it happens with any 'display' property
> that spans more than one text line. message-yank-buffer looks at
> buffer text and ignores the 'display' properties, so it inserts every
> line after quoting it, and this you get as many copies of the
> 'display' property as there are newlines in the text covered by the
> 'display' property.
Thank you for explaining what's going on! Closing now.
^ permalink raw reply [relevance 5%]
* bug#68251: message-yank-buffer insert many copies of image
2024-01-05 15:58 0% ` Eli Zaretskii
@ 2024-01-05 16:24 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-05 16:35 0% ` Eli Zaretskii
0 siblings, 1 reply; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-01-05 16:24 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 68251
Eli Zaretskii <eliz@gnu.org> writes:
>> Cc: 68251@debbugs.gnu.org
>> Date: Fri, 05 Jan 2024 14:09:37 +0200
>> From: Eli Zaretskii <eliz@gnu.org>
>>
>> > Date: Thu, 04 Jan 2024 21:09:23 -0800
>> > From: Joseph Turner via "Bug reports for GNU Emacs,
>> > the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>> >
>> > To reproduce:
>> > - ~emacs -Q~
>> > - Open an image in a buffer
>> > - Create another buffer, call ~M-x message-mode~
>> > - Run ~message-yank-buffer~, select the buffer with the image
>> >
>> > Expected:
>> >
>> > One image is inserted into the buffer.
>> >
>> > Actual:
>> >
>> > Many images are inserted into the buffer.
>>
>> It isn't specific to images: it happens with any 'display' property
>> that spans more than one text line. message-yank-buffer looks at
>> buffer text and ignores the 'display' properties, so it inserts every
>> line after quoting it, and this you get as many copies of the
>> 'display' property as there are newlines in the text covered by the
>> 'display' property.
>
> Btw: how is it useful to yank images into an email message? What do
> you expect Emacs to send when the email with these citations is sent?
>
> To DTRT here Emacs would need to produce a MIME attachment with the
> image, won't it?
Yes, you're right. I had wishful thinking for a WYSIWYG flow where
message-yank-buffer would insert an inline MIME attachment, and
message-mode would display it inline.
^ permalink raw reply [relevance 5%]
* bug#68251: message-yank-buffer insert many copies of image
2024-01-05 16:24 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-01-05 16:35 0% ` Eli Zaretskii
0 siblings, 0 replies; 200+ results
From: Eli Zaretskii @ 2024-01-05 16:35 UTC (permalink / raw)
To: Joseph Turner; +Cc: 68251
> From: Joseph Turner <joseph@breatheoutbreathe.in>
> Cc: 68251@debbugs.gnu.org
> Date: Fri, 05 Jan 2024 08:24:18 -0800
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > Btw: how is it useful to yank images into an email message? What do
> > you expect Emacs to send when the email with these citations is sent?
> >
> > To DTRT here Emacs would need to produce a MIME attachment with the
> > image, won't it?
>
> Yes, you're right. I had wishful thinking for a WYSIWYG flow where
> message-yank-buffer would insert an inline MIME attachment, and
> message-mode would display it inline.
That'd probably be a valid feature request.
^ permalink raw reply [relevance 0%]
* bug#68317: Can't sort *Packages* buffer by version after installing with package-vc
@ 2024-01-08 8:59 5% Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-08 13:03 0% ` Eli Zaretskii
0 siblings, 1 reply; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-01-08 8:59 UTC (permalink / raw)
To: 68317
To reproduce:
1. Install some package using package-vc.
2. Open the *Packages* buffer: M-x list-packages. The version column
for the newly installed package should display a git hash.
3. Click on the Version column header. If the package's hash starts with
a letter, then instead of sorting the results, Emacs signals an error:
version-to-list: Invalid version syntax: ‘c99367ebc2f0afe0baaf2f5e5ca1ad9d62ba6e21’ (must start with a number)
Thank you!!
Joseph
^ permalink raw reply [relevance 5%]
* bug#68317: Can't sort *Packages* buffer by version after installing with package-vc
2024-01-08 8:59 5% bug#68317: Can't sort *Packages* buffer by version after installing with package-vc Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-01-08 13:03 0% ` Eli Zaretskii
2024-01-09 19:25 0% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Eli Zaretskii @ 2024-01-08 13:03 UTC (permalink / raw)
To: Joseph Turner, Philip Kaludercic; +Cc: 68317
> Date: Mon, 08 Jan 2024 00:59:38 -0800
> From: Joseph Turner via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>
> To reproduce:
>
> 1. Install some package using package-vc.
>
> 2. Open the *Packages* buffer: M-x list-packages. The version column
> for the newly installed package should display a git hash.
>
> 3. Click on the Version column header. If the package's hash starts with
> a letter, then instead of sorting the results, Emacs signals an error:
>
> version-to-list: Invalid version syntax: ‘c99367ebc2f0afe0baaf2f5e5ca1ad9d62ba6e21’ (must start with a number)
Sounds like package-vc-commit should be modified to produce a valid
version string (which SHA1 is not)? Philip?
^ permalink raw reply [relevance 0%]
* bug#66187: read-file-name unexpected behavior when MUSTMATCH is a function
2023-12-19 2:52 9% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-01-09 8:06 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-25 20:53 10% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-01-09 8:06 UTC (permalink / raw)
To: Stefan Monnier, michael_heerdegen, Eli Zaretskii, philipk, 66187
Friendly ping. Happy New Year!
^ permalink raw reply [relevance 5%]
* bug#68317: Can't sort *Packages* buffer by version after installing with package-vc
2024-01-08 13:03 0% ` Eli Zaretskii
@ 2024-01-09 19:25 0% ` Philip Kaludercic
2024-01-09 19:53 0% ` Eli Zaretskii
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-01-09 19:25 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 68317, Joseph Turner
Eli Zaretskii <eliz@gnu.org> writes:
>> Date: Mon, 08 Jan 2024 00:59:38 -0800
>> From: Joseph Turner via "Bug reports for GNU Emacs,
>> the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>>
>> To reproduce:
>>
>> 1. Install some package using package-vc.
>>
>> 2. Open the *Packages* buffer: M-x list-packages. The version column
>> for the newly installed package should display a git hash.
>>
>> 3. Click on the Version column header. If the package's hash starts with
>> a letter, then instead of sorting the results, Emacs signals an error:
>>
>> version-to-list: Invalid version syntax: ‘c99367ebc2f0afe0baaf2f5e5ca1ad9d62ba6e21’ (must start with a number)
>
> Sounds like package-vc-commit should be modified to produce a valid
> version string (which SHA1 is not)? Philip?
We can also adjust `package-menu--version-predicate' to handle
non-version numbers, which I think would be more robust.
^ permalink raw reply [relevance 0%]
* bug#68317: Can't sort *Packages* buffer by version after installing with package-vc
2024-01-09 19:25 0% ` Philip Kaludercic
@ 2024-01-09 19:53 0% ` Eli Zaretskii
2024-01-09 20:19 0% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Eli Zaretskii @ 2024-01-09 19:53 UTC (permalink / raw)
To: Philip Kaludercic; +Cc: 68317, joseph
> From: Philip Kaludercic <philipk@posteo.net>
> Cc: Joseph Turner <joseph@breatheoutbreathe.in>, 68317@debbugs.gnu.org
> Date: Tue, 09 Jan 2024 19:25:44 +0000
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> version-to-list: Invalid version syntax: ‘c99367ebc2f0afe0baaf2f5e5ca1ad9d62ba6e21’ (must start with a number)
> >
> > Sounds like package-vc-commit should be modified to produce a valid
> > version string (which SHA1 is not)? Philip?
>
> We can also adjust `package-menu--version-predicate' to handle
> non-version numbers, which I think would be more robust.
Fine by me, but can this be done safely enough for emacs-29?
^ permalink raw reply [relevance 0%]
* bug#68317: Can't sort *Packages* buffer by version after installing with package-vc
2024-01-09 19:53 0% ` Eli Zaretskii
@ 2024-01-09 20:19 0% ` Philip Kaludercic
2024-01-10 3:27 0% ` Eli Zaretskii
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-01-09 20:19 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 68317, joseph
[-- Attachment #1: Type: text/plain, Size: 799 bytes --]
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: Joseph Turner <joseph@breatheoutbreathe.in>, 68317@debbugs.gnu.org
>> Date: Tue, 09 Jan 2024 19:25:44 +0000
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> >> version-to-list: Invalid version syntax: ‘c99367ebc2f0afe0baaf2f5e5ca1ad9d62ba6e21’ (must start with a number)
>> >
>> > Sounds like package-vc-commit should be modified to produce a valid
>> > version string (which SHA1 is not)? Philip?
>>
>> We can also adjust `package-menu--version-predicate' to handle
>> non-version numbers, which I think would be more robust.
>
> Fine by me, but can this be done safely enough for emacs-29?
This would be a simple implementation, I don't know if it is safe enough
for you:
[-- Attachment #2: Type: text/plain, Size: 789 bytes --]
diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el
index fa9903e13e3..f97c2cff783 100644
--- a/lisp/emacs-lisp/package.el
+++ b/lisp/emacs-lisp/package.el
@@ -4070,8 +4070,8 @@ package-menu-execute
(defun package-menu--version-predicate (A B)
"Predicate to sort \"*Packages*\" buffer by the version column.
This is used for `tabulated-list-format' in `package-menu-mode'."
- (let ((vA (or (version-to-list (aref (cadr A) 1)) '(0)))
- (vB (or (version-to-list (aref (cadr B) 1)) '(0))))
+ (let ((vA (or (ignore-error error (version-to-list (aref (cadr A) 1))) '(0)))
+ (vB (or (ignore-error error (version-to-list (aref (cadr B) 1))) '(0))))
(if (version-list-= vA vB)
(package-menu--name-predicate A B)
(version-list-< vA vB))))
^ permalink raw reply related [relevance 0%]
* bug#68317: Can't sort *Packages* buffer by version after installing with package-vc
2024-01-09 20:19 0% ` Philip Kaludercic
@ 2024-01-10 3:27 0% ` Eli Zaretskii
2024-01-10 5:16 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 200+ results
From: Eli Zaretskii @ 2024-01-10 3:27 UTC (permalink / raw)
To: Philip Kaludercic; +Cc: 68317, joseph
> From: Philip Kaludercic <philipk@posteo.net>
> Cc: joseph@breatheoutbreathe.in, 68317@debbugs.gnu.org
> Date: Tue, 09 Jan 2024 20:19:15 +0000
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> From: Philip Kaludercic <philipk@posteo.net>
> >> Cc: Joseph Turner <joseph@breatheoutbreathe.in>, 68317@debbugs.gnu.org
> >> Date: Tue, 09 Jan 2024 19:25:44 +0000
> >>
> >> Eli Zaretskii <eliz@gnu.org> writes:
> >>
> >> >> version-to-list: Invalid version syntax: ‘c99367ebc2f0afe0baaf2f5e5ca1ad9d62ba6e21’ (must start with a number)
> >> >
> >> > Sounds like package-vc-commit should be modified to produce a valid
> >> > version string (which SHA1 is not)? Philip?
> >>
> >> We can also adjust `package-menu--version-predicate' to handle
> >> non-version numbers, which I think would be more robust.
> >
> > Fine by me, but can this be done safely enough for emacs-29?
>
> This would be a simple implementation, I don't know if it is safe enough
> for you:
Looks safe enough, thanks.
^ permalink raw reply [relevance 0%]
* bug#68317: Can't sort *Packages* buffer by version after installing with package-vc
2024-01-10 3:27 0% ` Eli Zaretskii
@ 2024-01-10 5:16 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-10 8:28 5% ` Philip Kaludercic
2024-01-10 13:13 0% ` Eli Zaretskii
0 siblings, 2 replies; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-01-10 5:16 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Philip Kaludercic, 68317
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: joseph@breatheoutbreathe.in, 68317@debbugs.gnu.org
>> Date: Tue, 09 Jan 2024 20:19:15 +0000
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> >> From: Philip Kaludercic <philipk@posteo.net>
>> >> Cc: Joseph Turner <joseph@breatheoutbreathe.in>, 68317@debbugs.gnu.org
>> >> Date: Tue, 09 Jan 2024 19:25:44 +0000
>> >>
>> >> Eli Zaretskii <eliz@gnu.org> writes:
>> >>
>> >> >> version-to-list: Invalid version syntax: ‘c99367ebc2f0afe0baaf2f5e5ca1ad9d62ba6e21’ (must start with a number)
>> >> >
>> >> > Sounds like package-vc-commit should be modified to produce a valid
>> >> > version string (which SHA1 is not)? Philip?
>> >>
>> >> We can also adjust `package-menu--version-predicate' to handle
>> >> non-version numbers, which I think would be more robust.
>> >
>> > Fine by me, but can this be done safely enough for emacs-29?
>>
>> This would be a simple implementation, I don't know if it is safe enough
>> for you:
>
> Looks safe enough, thanks.
With this solution, when sorting by version, packages at version 0.0.0
are interleaved with packages whose version string is a hash, such as:
breadcrumb c99367ebc2f0afe0baaf2f5e5ca1ad9d62ba6e21 source No description available.
chordpro-mode a63fc0b7181299befc4496cba04e0f84d5953000 source No description available.
consult-emms 407edec0f2a997e32cb1bbeff811f73b6fac42ac source No description available.
denote 5e9b6b3bf0a81e00b0db0071f0c06a889f7e4a71 source No description available.
disable-mouse 0.0.0 external Disable mouse commands globally
emacsql 0.0.0 external High-level SQL database front-end
hl-todo 0.0.0 external Highlight TODO and similar keywords
hyperdrive 2930992446f508a7716b1e52a6aaf824d3f152d9 source No description available.
jabber 6900d9e085bbb2ef35b731c661fe54fa88422d6a source No description available.
ledger-mode 0.0.0 external Helper code for use with the "ledger" command-line tool
lisp unknown source No description available.
macrostep 0.0.0 external Interactive macro expander
While this is a little bit awkward, it's certainly better than an error.
Thank you for the quick fix!
Joseph
^ permalink raw reply [relevance 5%]
* bug#68317: Can't sort *Packages* buffer by version after installing with package-vc
2024-01-10 5:16 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-01-10 8:28 5% ` Philip Kaludercic
2024-01-10 13:13 0% ` Eli Zaretskii
1 sibling, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-01-10 8:28 UTC (permalink / raw)
To: Joseph Turner; +Cc: Eli Zaretskii, 68317-done
Joseph Turner <joseph@breatheoutbreathe.in> writes:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Philip Kaludercic <philipk@posteo.net>
>>> Cc: joseph@breatheoutbreathe.in, 68317@debbugs.gnu.org
>>> Date: Tue, 09 Jan 2024 20:19:15 +0000
>>>
>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>
>>> >> From: Philip Kaludercic <philipk@posteo.net>
>>> >> Cc: Joseph Turner <joseph@breatheoutbreathe.in>, 68317@debbugs.gnu.org
>>> >> Date: Tue, 09 Jan 2024 19:25:44 +0000
>>> >>
>>> >> Eli Zaretskii <eliz@gnu.org> writes:
>>> >>
>>> >> >> version-to-list: Invalid version syntax: ‘c99367ebc2f0afe0baaf2f5e5ca1ad9d62ba6e21’ (must start with a number)
>>> >> >
>>> >> > Sounds like package-vc-commit should be modified to produce a valid
>>> >> > version string (which SHA1 is not)? Philip?
>>> >>
>>> >> We can also adjust `package-menu--version-predicate' to handle
>>> >> non-version numbers, which I think would be more robust.
>>> >
>>> > Fine by me, but can this be done safely enough for emacs-29?
>>>
>>> This would be a simple implementation, I don't know if it is safe enough
>>> for you:
>>
>> Looks safe enough, thanks.
>
> With this solution, when sorting by version, packages at version 0.0.0
> are interleaved with packages whose version string is a hash, such as:
>
> breadcrumb c99367ebc2f0afe0baaf2f5e5ca1ad9d62ba6e21 source No description available.
> chordpro-mode a63fc0b7181299befc4496cba04e0f84d5953000 source No description available.
> consult-emms 407edec0f2a997e32cb1bbeff811f73b6fac42ac source No description available.
> denote 5e9b6b3bf0a81e00b0db0071f0c06a889f7e4a71 source No description available.
> disable-mouse 0.0.0 external Disable mouse commands globally
> emacsql 0.0.0 external High-level SQL database front-end
> hl-todo 0.0.0 external Highlight TODO and similar keywords
> hyperdrive 2930992446f508a7716b1e52a6aaf824d3f152d9 source No description available.
> jabber 6900d9e085bbb2ef35b731c661fe54fa88422d6a source No description available.
> ledger-mode 0.0.0 external Helper code for use with the "ledger" command-line tool
> lisp unknown source No description available.
> macrostep 0.0.0 external Interactive macro expander
>
> While this is a little bit awkward, it's certainly better than an error.
>
> Thank you for the quick fix!
I agree it is not ideal, I can take a look at it again after emacs-29 is
cut. But for now I'll mark the bug report as resolved.
> Joseph
^ permalink raw reply [relevance 5%]
* bug#68317: Can't sort *Packages* buffer by version after installing with package-vc
2024-01-10 5:16 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-10 8:28 5% ` Philip Kaludercic
@ 2024-01-10 13:13 0% ` Eli Zaretskii
1 sibling, 0 replies; 200+ results
From: Eli Zaretskii @ 2024-01-10 13:13 UTC (permalink / raw)
To: Joseph Turner; +Cc: philipk, 68317
> From: Joseph Turner <joseph@breatheoutbreathe.in>
> Cc: Philip Kaludercic <philipk@posteo.net>, 68317@debbugs.gnu.org
> Date: Tue, 09 Jan 2024 21:16:06 -0800
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> With this solution, when sorting by version, packages at version 0.0.0
> are interleaved with packages whose version string is a hash, such as:
We could produce a version of 0.0-git, in which case all those
packages that have a hash as the version will be sorted together.
^ permalink raw reply [relevance 0%]
* bug#65768: Bump persist.el version
2023-11-12 4:26 28% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-01-10 21:39 5% ` Stefan Kangas
2024-01-12 8:51 0% ` phillip.lord
0 siblings, 1 reply; 200+ results
From: Stefan Kangas @ 2024-01-10 21:39 UTC (permalink / raw)
To: Joseph Turner; +Cc: Eli Zaretskii, phillip.lord, 65768
Joseph Turner <joseph@breatheoutbreathe.in> writes:
> Stefan Kangas <stefankangas@gmail.com> writes:
>
>> Perhaps before releasing v0.6, it would make sense to update the
>> Maintainer header comment to reflect that you're now the maintainer?
>> If you agree, feel free to send a patch.
>
> Sounds good! Please see attached patches.
>
> Thank you!
>
> Joseph
Sorry for the belayed reply here.
I was about to install this, when I noticed that this package is
actually maintained as an external package at:
https://gitlab.com/phillord/persist
So I guess the easiest option is to continue running it externally,
unless you want to move its maintenance to elpa.git, in which case we
can arrange that.
If you want to maintain it externally, I guess Philip would either hand
over that repository to you, or you would have to create a new one.
Thoughts?
^ permalink raw reply [relevance 5%]
* bug#65768: Bump persist.el version
2024-01-10 21:39 5% ` Stefan Kangas
@ 2024-01-12 8:51 0% ` phillip.lord
2024-01-12 9:15 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 200+ results
From: phillip.lord @ 2024-01-12 8:51 UTC (permalink / raw)
To: Stefan Kangas; +Cc: Eli Zaretskii, 65768, Joseph Turner
On 2024-01-10 21:39, Stefan Kangas wrote:
> Joseph Turner <joseph@breatheoutbreathe.in> writes:
>
>> Stefan Kangas <stefankangas@gmail.com> writes:
>>
>>> Perhaps before releasing v0.6, it would make sense to update the
>>> Maintainer header comment to reflect that you're now the maintainer?
>>> If you agree, feel free to send a patch.
>>
>> Sounds good! Please see attached patches.
>>
>> Thank you!
>>
>> Joseph
>
> Sorry for the belayed reply here.
>
> I was about to install this, when I noticed that this package is
> actually maintained as an external package at:
>
> https://gitlab.com/phillord/persist
>
> So I guess the easiest option is to continue running it externally,
> unless you want to move its maintenance to elpa.git, in which case we
> can arrange that.
>
> If you want to maintain it externally, I guess Philip would either hand
> over that repository to you, or you would have to create a new one.
>
I am very easy any way. If you want me to give full maintainer control
to someone on the gitlab repo, just let me know. Or if you want to move
the repo elsewhere or just use ELPA, then I will archive the gitlab
repo.
Phil
^ permalink raw reply [relevance 0%]
* bug#65768: Bump persist.el version
2024-01-12 8:51 0% ` phillip.lord
@ 2024-01-12 9:15 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-12 13:10 5% ` phillip.lord
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-01-12 9:15 UTC (permalink / raw)
To: phillip.lord; +Cc: Eli Zaretskii, Stefan Kangas, 65768
phillip.lord@russet.org.uk writes:
> On 2024-01-10 21:39, Stefan Kangas wrote:
>> Joseph Turner <joseph@breatheoutbreathe.in> writes:
>>
>>> Stefan Kangas <stefankangas@gmail.com> writes:
>>>
>>>> Perhaps before releasing v0.6, it would make sense to update the
>>>> Maintainer header comment to reflect that you're now the maintainer?
>>>> If you agree, feel free to send a patch.
>>> Sounds good! Please see attached patches.
>>> Thank you!
>>> Joseph
>> Sorry for the belayed reply here.
>> I was about to install this, when I noticed that this package is
>> actually maintained as an external package at:
>> https://gitlab.com/phillord/persist
>> So I guess the easiest option is to continue running it externally,
>> unless you want to move its maintenance to elpa.git, in which case we
>> can arrange that.
>> If you want to maintain it externally, I guess Philip would either
>> hand
>> over that repository to you, or you would have to create a new one.
>>
>
>
> I am very easy any way. If you want me to give full maintainer control
> to someone on the gitlab repo, just let me know. Or if you want to
> move the repo elsewhere or just use ELPA, then I will archive the
> gitlab repo.
>
> Phil
I would prefer to move over to elpa.git.
Thank you for your flexibility!
Joseph
^ permalink raw reply [relevance 5%]
* bug#65768: Bump persist.el version
2024-01-12 9:15 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-01-12 13:10 5% ` phillip.lord
2024-01-13 9:41 5% ` Stefan Kangas
2024-01-13 9:45 8% ` Stefan Kangas
2 siblings, 0 replies; 200+ results
From: phillip.lord @ 2024-01-12 13:10 UTC (permalink / raw)
To: Joseph Turner; +Cc: Eli Zaretskii, Stefan Kangas, 65768
On 2024-01-12 09:15, Joseph Turner wrote:
> phillip.lord@russet.org.uk writes:
>
>> On 2024-01-10 21:39, Stefan Kangas wrote:
>>> Joseph Turner <joseph@breatheoutbreathe.in> writes:
>>>
>>>> Stefan Kangas <stefankangas@gmail.com> writes:
>>>>
>>>>> Perhaps before releasing v0.6, it would make sense to update the
>>>>> Maintainer header comment to reflect that you're now the
>>>>> maintainer?
>>>>> If you agree, feel free to send a patch.
>>>> Sounds good! Please see attached patches.
>>>> Thank you!
>>>> Joseph
>>> Sorry for the belayed reply here.
>>> I was about to install this, when I noticed that this package is
>>> actually maintained as an external package at:
>>> https://gitlab.com/phillord/persist
>>> So I guess the easiest option is to continue running it externally,
>>> unless you want to move its maintenance to elpa.git, in which case we
>>> can arrange that.
>>> If you want to maintain it externally, I guess Philip would either
>>> hand
>>> over that repository to you, or you would have to create a new one.
>>>
>>
>>
>> I am very easy any way. If you want me to give full maintainer control
>> to someone on the gitlab repo, just let me know. Or if you want to
>> move the repo elsewhere or just use ELPA, then I will archive the
>> gitlab repo.
>>
>> Phil
>
> I would prefer to move over to elpa.git.
>
> Thank you for your flexibility!
That's fine. Let me know when you are ready and I will archive gitlab!
Phil
^ permalink raw reply [relevance 5%]
* bug#65768: Bump persist.el version
2024-01-12 9:15 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-12 13:10 5% ` phillip.lord
@ 2024-01-13 9:41 5% ` Stefan Kangas
2024-01-13 19:14 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-13 9:45 8% ` Stefan Kangas
2 siblings, 1 reply; 200+ results
From: Stefan Kangas @ 2024-01-13 9:41 UTC (permalink / raw)
To: Joseph Turner, phillip.lord; +Cc: 65768-done, Eli Zaretskii, Stefan Monnier
Joseph Turner <joseph@breatheoutbreathe.in> writes:
>> I am very easy any way. If you want me to give full maintainer control
>> to someone on the gitlab repo, just let me know. Or if you want to
>> move the repo elsewhere or just use ELPA, then I will archive the
>> gitlab repo.
>
> I would prefer to move over to elpa.git.
Thanks, so I changed it to be maintained in elpa.git, and installed your
patches there.
Phil, I think you can archive the old repository at your convenience.
I'm therefore closing this bug report.
^ permalink raw reply [relevance 5%]
* bug#65768: Bump persist.el version
2024-01-12 9:15 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-12 13:10 5% ` phillip.lord
2024-01-13 9:41 5% ` Stefan Kangas
@ 2024-01-13 9:45 8% ` Stefan Kangas
2024-01-13 19:15 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2 siblings, 1 reply; 200+ results
From: Stefan Kangas @ 2024-01-13 9:45 UTC (permalink / raw)
To: Joseph Turner, phillip.lord
Cc: Eli Zaretskii, Philip Kaludercic, Stefan Monnier, 65768
BTW, I see the following warnings from package-lint:
1:64: warning: You should depend on (emacs "24.1") if you need lexical-binding.
228:51: error: You should depend on (emacs "26.1") if you need `recordp'.
233:64: error: You should depend on (emacs "26.1") if you need `recordp'.
236:53: error: You should depend on (emacs "26.1") if you need `recordp'.
Would the below patch be appropriate?
diff --git a/persist.el b/persist.el
index 2b96b2b7f0..6cc94b4db3 100644
--- a/persist.el
+++ b/persist.el
@@ -5,6 +5,7 @@
;; Author: Phillip Lord <phillip.lord@russet.org.uk>
;; Maintainer: Joseph Turner <persist-el@breatheoutbreathe.in>
;; Package-Type: multi
+;; Package-Requires: ((emacs "26.1"))
;; Version: 0.6
;; The contents of this file are subject to the GPL License, Version 3.0.
^ permalink raw reply related [relevance 8%]
* bug#66224: [PATCH] Add optional PREDICATE argument to read-directory-name
2023-11-12 20:42 11% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-01-13 10:53 5% ` Stefan Kangas
2024-01-13 19:26 8% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 200+ results
From: Stefan Kangas @ 2024-01-13 10:53 UTC (permalink / raw)
To: Joseph Turner; +Cc: michael_heerdegen, philipk, 66224
Joseph Turner <joseph@breatheoutbreathe.in> writes:
> Joseph Turner <joseph@breatheoutbreathe.in> writes:
>
>> Michael Heerdegen <michael_heerdegen@web.de> writes:
>>
>>> Joseph Turner via "Bug reports for GNU Emacs, the Swiss army knife of
>>> text editors" <bug-gnu-emacs@gnu.org> writes:
>>>
>>>> I'm not sure what you mean. In both of the following examples, PREDICATE
>>>> is used to narrow the completion candidates to only empty directories:
>>>>
>>>> (read-directory-name "Prompt: " "~/" nil t nil #'directory-empty-p)
>>>> (read-directory-name "Prompt: " "~/" nil nil nil #'directory-empty-p)
>>>
>>> In the second version also non-empty directories will be accepted.
>>
>> Yes, PREDICATE narrows the completion candidates but doesn't determine a
>> valid return value.
>
> Ping! I'm happy to keep discussing this patch if others are interested.
Could you please send the latest version of your patch?
^ permalink raw reply [relevance 5%]
* bug#65768: Bump persist.el version
2024-01-13 9:41 5% ` Stefan Kangas
@ 2024-01-13 19:14 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 0 replies; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-01-13 19:14 UTC (permalink / raw)
To: Stefan Kangas; +Cc: 65768-done, Eli Zaretskii, Stefan Monnier, phillip.lord
Stefan Kangas <stefankangas@gmail.com> writes:
> Joseph Turner <joseph@breatheoutbreathe.in> writes:
>
>>> I am very easy any way. If you want me to give full maintainer control
>>> to someone on the gitlab repo, just let me know. Or if you want to
>>> move the repo elsewhere or just use ELPA, then I will archive the
>>> gitlab repo.
>>
>> I would prefer to move over to elpa.git.
>
> Thanks, so I changed it to be maintained in elpa.git, and installed your
> patches there.
Thank you!!
> Phil, I think you can archive the old repository at your convenience.
>
> I'm therefore closing this bug report.
^ permalink raw reply [relevance 5%]
* bug#65768: Bump persist.el version
2024-01-13 9:45 8% ` Stefan Kangas
@ 2024-01-13 19:15 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 0 replies; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-01-13 19:15 UTC (permalink / raw)
To: Stefan Kangas
Cc: Eli Zaretskii, 65768, Philip Kaludercic, Stefan Monnier,
phillip.lord
Stefan Kangas <stefankangas@gmail.com> writes:
> BTW, I see the following warnings from package-lint:
>
> 1:64: warning: You should depend on (emacs "24.1") if you need lexical-binding.
> 228:51: error: You should depend on (emacs "26.1") if you need `recordp'.
> 233:64: error: You should depend on (emacs "26.1") if you need `recordp'.
> 236:53: error: You should depend on (emacs "26.1") if you need `recordp'.
>
> Would the below patch be appropriate?
>
> diff --git a/persist.el b/persist.el
> index 2b96b2b7f0..6cc94b4db3 100644
> --- a/persist.el
> +++ b/persist.el
> @@ -5,6 +5,7 @@
> ;; Author: Phillip Lord <phillip.lord@russet.org.uk>
> ;; Maintainer: Joseph Turner <persist-el@breatheoutbreathe.in>
> ;; Package-Type: multi
> +;; Package-Requires: ((emacs "26.1"))
> ;; Version: 0.6
>
> ;; The contents of this file are subject to the GPL License, Version 3.0.
LGTM. Thank you!
Joseph
^ permalink raw reply [relevance 5%]
* bug#66224: [PATCH] Add optional PREDICATE argument to read-directory-name
2024-01-13 10:53 5% ` Stefan Kangas
@ 2024-01-13 19:26 8% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 0 replies; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-01-13 19:26 UTC (permalink / raw)
To: Stefan Kangas; +Cc: michael_heerdegen, philipk, 66224
[-- Attachment #1: Type: text/plain, Size: 1002 bytes --]
Stefan Kangas <stefankangas@gmail.com> writes:
> Joseph Turner <joseph@breatheoutbreathe.in> writes:
>
>> Joseph Turner <joseph@breatheoutbreathe.in> writes:
>>
>>> Michael Heerdegen <michael_heerdegen@web.de> writes:
>>>
>>>> Joseph Turner via "Bug reports for GNU Emacs, the Swiss army knife of
>>>> text editors" <bug-gnu-emacs@gnu.org> writes:
>>>>
>>>>> I'm not sure what you mean. In both of the following examples, PREDICATE
>>>>> is used to narrow the completion candidates to only empty directories:
>>>>>
>>>>> (read-directory-name "Prompt: " "~/" nil t nil #'directory-empty-p)
>>>>> (read-directory-name "Prompt: " "~/" nil nil nil #'directory-empty-p)
>>>>
>>>> In the second version also non-empty directories will be accepted.
>>>
>>> Yes, PREDICATE narrows the completion candidates but doesn't determine a
>>> valid return value.
>>
>> Ping! I'm happy to keep discussing this patch if others are interested.
>
> Could you please send the latest version of your patch?
Here you go!
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Add-optional-PREDICATE-argument-to-read-directory-na.patch --]
[-- Type: text/x-diff, Size: 4110 bytes --]
From 894e44bce60cf30c9e8bc8c5323eaed91d135bbb Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Thu, 28 Sep 2023 20:27:47 -0700
Subject: [PATCH] Add optional PREDICATE argument to read-directory-name
* lisp/files.el (read-directory-name): Add optional PREDICATE arg.
* doc/lispref/minibuf.texi (Reading File Names): Document change.
* etc/NEWS: Note change.
---
doc/lispref/minibuf.texi | 7 +++++--
etc/NEWS | 5 +++++
lisp/files.el | 13 ++++++++++---
3 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/doc/lispref/minibuf.texi b/doc/lispref/minibuf.texi
index 620c58ec6e9..bf4d6e13d3a 100644
--- a/doc/lispref/minibuf.texi
+++ b/doc/lispref/minibuf.texi
@@ -1709,7 +1709,7 @@ If this variable is non-@code{nil}, @code{read-file-name} ignores case
when performing completion.
@end defopt
-@defun read-directory-name prompt &optional directory default require-match initial
+@defun read-directory-name prompt &optional directory default require-match initial predicate
This function is like @code{read-file-name} but allows only directory
names as completion alternatives.
@@ -1719,7 +1719,10 @@ combining @var{directory} (or the current buffer's default directory
if @var{directory} is @code{nil}) and @var{initial}. If both
@var{default} and @var{initial} are @code{nil}, this function uses
@var{directory} as substitute default, or the current buffer's default
-directory if @var{directory} is @code{nil}.
+directory if @var{directory} is @code{nil}. When optional sixth
+argument @code{predicate} is non-nil, the union of @code{predicate}
+and @code{file-directory-p} is passed as the @code{predicate} argument
+to @code{read-file-name}.
@end defun
@defopt insert-default-directory
diff --git a/etc/NEWS b/etc/NEWS
index 1b3532b5657..fb9f6a0b43f 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -3541,6 +3541,11 @@ This function is called to see whether what the user has typed is a
match. This is also available from functions that call
'completing-read', like 'read-file-name'.
+** 'read-directory-name' now accepts an optional PREDICATE argument.
+When optional sixth argument PREDICATE is non-nil, the union of
+PREDICATE and 'file-directory-p' is passed as the PREDICATE argument
+to 'read-file-name'.
+
** 'posn-col-row' can now give position data based on windows.
Previously, it reported data only based on the frame.
diff --git a/lisp/files.el b/lisp/files.el
index b72f141c0ee..68855cd1c6d 100644
--- a/lisp/files.el
+++ b/lisp/files.el
@@ -807,7 +807,7 @@ See Info node `(elisp)Standard File Names' for more details."
(dos-convert-standard-filename filename))
(t filename)))
-(defun read-directory-name (prompt &optional dir default-dirname mustmatch initial)
+(defun read-directory-name (prompt &optional dir default-dirname mustmatch initial predicate)
"Read directory name, prompting with PROMPT and completing in directory DIR.
Value is not expanded---you must call `expand-file-name' yourself.
Default name to DEFAULT-DIRNAME if user exits with the same
@@ -821,14 +821,21 @@ Fourth arg MUSTMATCH non-nil means require existing directory's name.
Non-nil and non-t means also require confirmation after completion.
Fifth arg INITIAL specifies text to start with.
DIR should be an absolute directory name. It defaults to
-the value of `default-directory'."
+the value of `default-directory'.
+When sixth arg PREDICATE is non-nil, the union of PREDICATE and
+`file-directory-p' is passed as the PREDICATE argument to
+`read-file-name'. Otherwise, only `file-directory-p' is passed."
(unless dir
(setq dir default-directory))
(read-file-name prompt dir (or default-dirname
(if initial (expand-file-name initial dir)
dir))
mustmatch initial
- 'file-directory-p))
+ (if predicate
+ (lambda (filename)
+ (and (file-directory-p filename)
+ (funcall predicate filename)))
+ #'file-directory-p)))
\f
(defun pwd (&optional insert)
--
2.41.0
^ permalink raw reply related [relevance 8%]
* bug#66187: read-file-name unexpected behavior when MUSTMATCH is a function
2024-01-09 8:06 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-01-25 20:53 10% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-28 19:20 0% ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-01-25 20:53 UTC (permalink / raw)
To: Stefan Monnier, michael_heerdegen, Eli Zaretskii, philipk, 66187
[-- Attachment #1: Type: text/plain, Size: 68 bytes --]
Ping! I hope a fix like this can be merged into Emacs 29 still :)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Fix-completing-read-functional-REQUIRE-MATCH-behavio.patch --]
[-- Type: text/x-diff, Size: 1407 bytes --]
From 609bf4964f88b01f4843e29b2cf71ee1cd2f6125 Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Sun, 12 Nov 2023 13:21:50 -0800
Subject: [PATCH] Fix completing-read functional REQUIRE-MATCH behavior
* lisp/minibuffer.el (completion--complete-and-exit): If
minibuffer-completion-confirm is a function which returns nil,
immediately fail to complete.
See bug#66187.
---
lisp/minibuffer.el | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 3e30b68d5e9..9fad3e71fad 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -1847,10 +1847,13 @@ appear to be a match."
;; Allow user to specify null string
((= beg end) (funcall exit-function))
;; The CONFIRM argument is a predicate.
- ((and (functionp minibuffer-completion-confirm)
- (funcall minibuffer-completion-confirm
- (buffer-substring beg end)))
- (funcall exit-function))
+ ((functionp minibuffer-completion-confirm)
+ (if (funcall minibuffer-completion-confirm
+ (buffer-substring beg end))
+ (funcall exit-function)
+ (unless completion-fail-discreetly
+ (ding)
+ (completion--message "No match"))))
;; See if we have a completion from the table.
((test-completion (buffer-substring beg end)
minibuffer-completion-table
--
2.41.0
[-- Attachment #3: Type: text/plain, Size: 20 bytes --]
Thank you!
Joseph
^ permalink raw reply related [relevance 10%]
* bug#66187: read-file-name unexpected behavior when MUSTMATCH is a function
2024-01-25 20:53 10% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-01-28 19:20 0% ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-28 19:28 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 200+ results
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-01-28 19:20 UTC (permalink / raw)
To: Joseph Turner; +Cc: michael_heerdegen, Eli Zaretskii, philipk, 66187
> Ping! I hope a fix like this can be merged into Emacs 29 still :)
Duh, I can't believe I left you waiting for so long, this is awful.
I just pushed this to `emacs-29`, thank you.
I hope there might still be a next time, so I get a chance to do better.
Stefan
> From 609bf4964f88b01f4843e29b2cf71ee1cd2f6125 Mon Sep 17 00:00:00 2001
> From: Joseph Turner <joseph@breatheoutbreathe.in>
> Date: Sun, 12 Nov 2023 13:21:50 -0800
> Subject: [PATCH] Fix completing-read functional REQUIRE-MATCH behavior
>
> * lisp/minibuffer.el (completion--complete-and-exit): If
> minibuffer-completion-confirm is a function which returns nil,
> immediately fail to complete.
>
> See bug#66187.
> ---
> lisp/minibuffer.el | 11 +++++++----
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
> index 3e30b68d5e9..9fad3e71fad 100644
> --- a/lisp/minibuffer.el
> +++ b/lisp/minibuffer.el
> @@ -1847,10 +1847,13 @@ appear to be a match."
> ;; Allow user to specify null string
> ((= beg end) (funcall exit-function))
> ;; The CONFIRM argument is a predicate.
> - ((and (functionp minibuffer-completion-confirm)
> - (funcall minibuffer-completion-confirm
> - (buffer-substring beg end)))
> - (funcall exit-function))
> + ((functionp minibuffer-completion-confirm)
> + (if (funcall minibuffer-completion-confirm
> + (buffer-substring beg end))
> + (funcall exit-function)
> + (unless completion-fail-discreetly
> + (ding)
> + (completion--message "No match"))))
> ;; See if we have a completion from the table.
> ((test-completion (buffer-substring beg end)
> minibuffer-completion-table
^ permalink raw reply [relevance 0%]
* bug#66187: read-file-name unexpected behavior when MUSTMATCH is a function
2024-01-28 19:20 0% ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-01-28 19:28 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 0 replies; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-01-28 19:28 UTC (permalink / raw)
To: Stefan Monnier; +Cc: michael_heerdegen, Eli Zaretskii, philipk, 66187-done
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> Ping! I hope a fix like this can be merged into Emacs 29 still :)
>
> Duh, I can't believe I left you waiting for so long, this is awful.
> I just pushed this to `emacs-29`, thank you.
> I hope there might still be a next time, so I get a chance to do better.
It's all good!! Life is happening :)
Thank you!!
Joseph
>
> Stefan
>
>
>> From 609bf4964f88b01f4843e29b2cf71ee1cd2f6125 Mon Sep 17 00:00:00 2001
>> From: Joseph Turner <joseph@breatheoutbreathe.in>
>> Date: Sun, 12 Nov 2023 13:21:50 -0800
>> Subject: [PATCH] Fix completing-read functional REQUIRE-MATCH behavior
>>
>> * lisp/minibuffer.el (completion--complete-and-exit): If
>> minibuffer-completion-confirm is a function which returns nil,
>> immediately fail to complete.
>>
>> See bug#66187.
>> ---
>> lisp/minibuffer.el | 11 +++++++----
>> 1 file changed, 7 insertions(+), 4 deletions(-)
>>
>> diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
>> index 3e30b68d5e9..9fad3e71fad 100644
>> --- a/lisp/minibuffer.el
>> +++ b/lisp/minibuffer.el
>> @@ -1847,10 +1847,13 @@ appear to be a match."
>> ;; Allow user to specify null string
>> ((= beg end) (funcall exit-function))
>> ;; The CONFIRM argument is a predicate.
>> - ((and (functionp minibuffer-completion-confirm)
>> - (funcall minibuffer-completion-confirm
>> - (buffer-substring beg end)))
>> - (funcall exit-function))
>> + ((functionp minibuffer-completion-confirm)
>> + (if (funcall minibuffer-completion-confirm
>> + (buffer-substring beg end))
>> + (funcall exit-function)
>> + (unless completion-fail-discreetly
>> + (ding)
>> + (completion--message "No match"))))
>> ;; See if we have a completion from the table.
>> ((test-completion (buffer-substring beg end)
>> minibuffer-completion-table
^ permalink raw reply [relevance 5%]
* bug#66114: [PATCH] Fix interactive prompt for selecting checkout directory
@ 2024-01-30 8:42 11% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-14 16:54 5% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-01-30 8:42 UTC (permalink / raw)
To: Philip Kaludercic, 66114
[-- Attachment #1: Type: text/plain, Size: 1384 bytes --]
Joseph Turner <joseph@breatheoutbreathe.in> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Joseph Turner <joseph@breatheoutbreathe.in> writes:
>>
>>> However, the behavior of
>>> read-file-name is unspecified when a MUSTMATCH function returns nil:
>>>
>>> - a function, which will be called with the input as the
>>> argument. If the function returns a non-nil value, the
>>> minibuffer is exited with that argument as the value.
>>>
>>> Is this a bug, a case of under-documentation, or do I misunderstand something?
>>>
>>> I'm happy to post this in a separate bug thread if you think it's worth it.
>>
>> Perhaps that would be worth doing, that way the people who know more
>> about completion than I do would be more likely to see it and help
>> out.
>
> Okay, thanks! I'll do that.
Now that #66187
(<https://yhetil.org/emacs-bugs/87cytlqmqh.fsf@breatheoutbreathe.in/>)
and bug#68815
(<https://yhetil.org/emacs-bugs/8734ufyxoy.fsf@breatheoutbreathe.in/>)
are fixed on emacs-29, I'm revisiting this issue.
With the following patch, the interactive prompt in package-vc-checkout
now offers all directory for completion (empty or not), but only exits
when the minibuffer contains an empty directory or nonexistent filename.
Testing this patch requires checking out emacs-29 after e6c82fe35e3.
Thanks!
Joseph
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Improve-package-vc-checkout-interactive-prompt-bug-6.patch --]
[-- Type: text/x-diff, Size: 1326 bytes --]
From e6c82fe35e3f5de107020ee206043bd80cbfff27 Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Tue, 30 Jan 2024 00:52:39 -0800
Subject: [PATCH] Improve package-vc-checkout interactive prompt (bug#66114)
* lisp/emacs-lisp/package-vc.el (package-vc--read-package-name): Use
read-directory-name instead of read-file-name.
---
lisp/emacs-lisp/package-vc.el | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lisp/emacs-lisp/package-vc.el b/lisp/emacs-lisp/package-vc.el
index e89ead89d4b..5c5486de290 100644
--- a/lisp/emacs-lisp/package-vc.el
+++ b/lisp/emacs-lisp/package-vc.el
@@ -825,8 +825,8 @@ package-vc-checkout
(interactive
(let* ((name (package-vc--read-package-name "Fetch package source: ")))
(list (cadr (assoc name package-archive-contents #'string=))
- (read-file-name "Clone into new or empty directory: " nil nil t nil
- (lambda (dir) (or (not (file-exists-p dir))
+ (read-directory-name "Clone into new or empty directory: " nil nil
+ (lambda (dir) (or (not (file-exists-p dir))
(directory-empty-p dir))))
(and current-prefix-arg :last-release))))
(setf directory (expand-file-name directory))
--
2.41.0
^ permalink raw reply related [relevance 11%]
* bug#68815: Unexpected behavior with read-file-name and functional REQUIRE-MATCH argument
@ 2024-01-30 9:00 4% Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-01-30 9:00 UTC (permalink / raw)
To: 68815; +Cc: Philip Kaludercic, Stefan Monnier, michael_heerdegen,
Eli Zaretskii
Hello!
With #66187 resolved (<https://yhetil.org/emacs-bugs/87cytlqmqh.fsf@breatheoutbreathe.in/>),
I reexamined #66114 (<https://yhetil.org/emacs-bugs/87v8bzi7iz.fsf@breatheoutbreathe.in/>),
only to discover that filename completion with a functional
REQUIRE-MATCH argument doesn't work as expected.
To reproduce:
emacs -Q on the tip of the emacs-29 branch (after commit 77f5d4d523a), run...
(let ((default-directory "~/"))
(read-directory-name "Clone into new or empty directory: " nil nil
(lambda (dir) (or (not (file-exists-p dir))
(directory-empty-p dir)))))
...then type "/tmp/" (the whole minibuffer now reads "~//tmp") then RET.
Expected: Completion does not exit, instead saying "[No match]".
Actual: Completion exits, returning "/tmp/".
If I delete the leading "~/" before typing "/tmp/", I get the expected result.
The issue appears to be inside completion--complete-and-exit:
((functionp minibuffer-completion-confirm)
(if (funcall minibuffer-completion-confirm
(buffer-substring beg end)) ; Here, buffer-substring returns "~//tmp/"
(funcall exit-function)
(unless completion-fail-discreetly
(ding)
(completion--message "No match"))))
Since (file-exists-p "~//tmp/") returns nil, the whole predicate returns
t and the minibuffer completes "/tmp/".
In completion--complete-and-exit, should (buffer-substring beg end)
return only "/tmp/"?
Or maybe (file-exists-p "~//tmp/") should return t?
Thank you!!
Joseph
^ permalink raw reply [relevance 4%]
* bug#68815: Unexpected behavior with read-file-name and functional REQUIRE-MATCH argument
@ 2024-01-31 6:11 10% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-01-31 6:11 UTC (permalink / raw)
To: Stefan Monnier; +Cc: michael_heerdegen, Philip Kaludercic, 68815, Eli Zaretskii
[-- Attachment #1: Type: text/plain, Size: 1268 bytes --]
Hi Stefan!
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> emacs -Q on the tip of the emacs-29 branch (after commit 77f5d4d523a), run...
>>
>> (let ((default-directory "~/"))
>> (read-directory-name "Clone into new or empty directory: " nil nil
>> (lambda (dir) (or (not (file-exists-p dir))
>> (directory-empty-p dir)))))
>>
>> ...then type "/tmp/" (the whole minibuffer now reads "~//tmp") then RET.
>>
>> Expected: Completion does not exit, instead saying "[No match]".
>
> Ah, that good old problem about whether PRED should apply to the
> quoted
> or to the unquoted string 🙁
>
> I think here the bug is in `read-directory-name` (and
> `read-file-name`)
> since their PRED arg is expected to apply to the (unquoted) file name
> itself (i.e. the thing that would be returned by the function), rather
> than to the quoted representation used in the minibuffer.
>
> They should wrap PRED so as to pass the arg through
> `substitute-in-file-name` (or otherwise arrange to make sure PRED is
> called with an unquoted file name).
Thank you for the clear instructions! Does the attached patch do the
right thing?
If so, may it be applied to emacs-29?
Joseph
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Pass-unquoted-filename-to-user-supplied-MUSTMATCH-pr.patch --]
[-- Type: text/x-diff, Size: 1872 bytes --]
From 78c7232593cc12bdf3e772df602d75a31bc4fd2a Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Tue, 30 Jan 2024 22:08:50 -0800
Subject: [PATCH] Pass unquoted filename to user-supplied MUSTMATCH predicate
* lisp/minibuffer.el (read-file-name-default):
Resolves bug#68815.
---
lisp/minibuffer.el | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index faa7f543ece..1f0f3bdade3 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -3353,7 +3353,13 @@ See `read-file-name' for the meaning of the arguments."
(let ((ignore-case read-file-name-completion-ignore-case)
(minibuffer-completing-file-name t)
(pred (or predicate 'file-exists-p))
- (add-to-history nil))
+ (add-to-history nil)
+ (require-match (if (functionp mustmatch)
+ (lambda (input)
+ (funcall mustmatch
+ ;; User-supplied MUSTMATCH expects an unquoted filename
+ (substitute-in-file-name input)))
+ mustmatch)))
(let* ((val
(if (or (not (next-read-file-uses-dialog-p))
@@ -3389,7 +3395,7 @@ See `read-file-name' for the meaning of the arguments."
(read-file-name--defaults dir initial))))
(set-syntax-table minibuffer-local-filename-syntax))
(completing-read prompt 'read-file-name-internal
- pred mustmatch insdef
+ pred require-match insdef
'file-name-history default-filename)))
;; If DEFAULT-FILENAME not supplied and DIR contains
;; a file name, split it.
--
2.41.0
^ permalink raw reply related [relevance 10%]
* bug#68815: Unexpected behavior with read-file-name and functional REQUIRE-MATCH argument
@ 2024-01-31 19:33 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-01-31 19:33 UTC (permalink / raw)
To: Stefan Monnier; +Cc: michael_heerdegen, Philip Kaludercic, 68815, Eli Zaretskii
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> They should wrap PRED so as to pass the arg through
>>> `substitute-in-file-name` (or otherwise arrange to make sure PRED is
>>> called with an unquoted file name).
>> Thank you for the clear instructions! Does the attached patch do the
>> right thing?
>
> I theory, I think it's correct, yes.
>
> Whether the rest of the code handles it correctly OTOH is a different
> question. E.g. I have the impression that currently the
> `read-file-name-internal` completion table presumes the PRED argument
> takes an already-unquoted file name.
What other code would this patch affect?
I see that `completion--file-name-table' uses `substitute-in-file-name',
but I don't understand how this patch would affect completion table.
> Also, performance can be a concern (in many cases it makes more sense
> to make the caller pass the unquoted name rather than force it to quote
> the name only for PRED to unquote it).
The REQUIRE-MATCH function is only called once when the user attempts to
exit the minibuffer. Would you please explain the performance concern?
Thank you!
Joseph
^ permalink raw reply [relevance 5%]
* bug#68815: Unexpected behavior with read-file-name and functional REQUIRE-MATCH argument
@ 2024-01-31 22:34 9% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 0 replies; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-01-31 22:34 UTC (permalink / raw)
To: Stefan Monnier
Cc: michael_heerdegen, Philip Kaludercic, 68815, Eli Zaretskii,
stefankangas
[-- Attachment #1: Type: text/plain, Size: 1107 bytes --]
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> Also, performance can be a concern (in many cases it makes more sense
>>> to make the caller pass the unquoted name rather than force it to quote
>>> the name only for PRED to unquote it).
>>
>> The REQUIRE-MATCH function is only called once when the user attempts to
>> exit the minibuffer. Would you please explain the performance concern?
>
> Oh, sorry, I got confused. Indeed, you're wrapping the REQUIRE-MATCH
> arg, not the PRED arg I was ranting about. Duh!
>
> It would be OK for `emacs-29`, indeed. Eli? Stefan? Any objection?
Great! I've CC'd Stefan as well in this email.
> In the mean time, could you update the docs to clarify the behavior.
> E.g. currently the docstring of `read-file-name` says:
>
> - a function, which will be called with the input as the
> argument. [...]
>
> which could be understood to suggest it really receives the contents of
> the minibuffer (i.e. the quoted file name) rather than the value we'd
> extract from it (the unquoted file name).
Please see the attached patch.
Thanks!
Joseph
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Pass-unquoted-filename-to-user-supplied-MUSTMATCH-pr.patch --]
[-- Type: text/x-diff, Size: 2753 bytes --]
From 208c7abff97f842057540fa2dfacd99808f17015 Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Tue, 30 Jan 2024 22:08:50 -0800
Subject: [PATCH] Pass unquoted filename to user-supplied MUSTMATCH predicate
* lisp/minibuffer.el (read-file-name-default): Pass REQUIRE-MATCH
argument through substitute-in-file-name.
* lisp/minibuffer.el (read-file-name): Update docstring.
Resolves bug#68815.
---
lisp/minibuffer.el | 17 ++++++++++++-----
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index faa7f543ece..a9e3ec937f9 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -3262,9 +3262,10 @@ Fourth arg MUSTMATCH can take the following values:
input, but she needs to confirm her choice if she called
`minibuffer-complete' right before `minibuffer-complete-and-exit'
and the input is not an existing file.
-- a function, which will be called with the input as the
- argument. If the function returns a non-nil value, the
- minibuffer is exited with that argument as the value.
+- a function, which will be called with a single argument, the
+ input unquoted by `substitute-in-file-name', which see. If the
+ function returns a non-nil value, the minibuffer is exited with
+ that argument as the value.
- anything else behaves like t except that typing RET does not exit if it
does non-null completion.
@@ -3353,7 +3354,13 @@ See `read-file-name' for the meaning of the arguments."
(let ((ignore-case read-file-name-completion-ignore-case)
(minibuffer-completing-file-name t)
(pred (or predicate 'file-exists-p))
- (add-to-history nil))
+ (add-to-history nil)
+ (require-match (if (functionp mustmatch)
+ (lambda (input)
+ (funcall mustmatch
+ ;; User-supplied MUSTMATCH expects an unquoted filename
+ (substitute-in-file-name input)))
+ mustmatch)))
(let* ((val
(if (or (not (next-read-file-uses-dialog-p))
@@ -3389,7 +3396,7 @@ See `read-file-name' for the meaning of the arguments."
(read-file-name--defaults dir initial))))
(set-syntax-table minibuffer-local-filename-syntax))
(completing-read prompt 'read-file-name-internal
- pred mustmatch insdef
+ pred require-match insdef
'file-name-history default-filename)))
;; If DEFAULT-FILENAME not supplied and DIR contains
;; a file name, split it.
--
2.41.0
^ permalink raw reply related [relevance 9%]
* bug#68815: Unexpected behavior with read-file-name and functional REQUIRE-MATCH argument
@ 2024-02-01 7:04 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-01 7:39 5% ` Stefan Kangas
2024-02-01 7:59 0% ` Eli Zaretskii
0 siblings, 2 replies; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-02-01 7:04 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: michael_heerdegen, philipk, 68815, Stefan Monnier
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Cc: 68815@debbugs.gnu.org, Philip Kaludercic <philipk@posteo.net>,
>> michael_heerdegen@web.de, Eli Zaretskii <eliz@gnu.org>
>> Date: Wed, 31 Jan 2024 17:05:30 -0500
>>
>> >> Also, performance can be a concern (in many cases it makes more sense
>> >> to make the caller pass the unquoted name rather than force it to quote
>> >> the name only for PRED to unquote it).
>> >
>> > The REQUIRE-MATCH function is only called once when the user attempts to
>> > exit the minibuffer. Would you please explain the performance concern?
>>
>> Oh, sorry, I got confused. Indeed, you're wrapping the REQUIRE-MATCH
>> arg, not the PRED arg I was ranting about. Duh!
>>
>> It would be OK for `emacs-29`, indeed. Eli? Stefan? Any objection?
>
> I don't mind, but please note that I'm not sure there will be any
> further 29.x releases.
Good to know. What is the purpose of keeping the emacs-29 branch, then?
>> In the mean time, could you update the docs to clarify the behavior.
>
> Yes, please.
^ permalink raw reply [relevance 5%]
* bug#68815: Unexpected behavior with read-file-name and functional REQUIRE-MATCH argument
2024-02-01 7:04 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-02-01 7:39 5% ` Stefan Kangas
2024-02-01 7:59 0% ` Eli Zaretskii
1 sibling, 0 replies; 200+ results
From: Stefan Kangas @ 2024-02-01 7:39 UTC (permalink / raw)
To: Joseph Turner, Eli Zaretskii
Cc: michael_heerdegen, philipk, 68815, Stefan Monnier
Joseph Turner via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs@gnu.org> writes:
> What is the purpose of keeping the emacs-29 branch, then?
It'll be useful in case we do decide to release 29.3.
^ permalink raw reply [relevance 5%]
* bug#68815: Unexpected behavior with read-file-name and functional REQUIRE-MATCH argument
2024-02-01 7:04 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-01 7:39 5% ` Stefan Kangas
@ 2024-02-01 7:59 0% ` Eli Zaretskii
2024-02-01 22:26 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 1 reply; 200+ results
From: Eli Zaretskii @ 2024-02-01 7:59 UTC (permalink / raw)
To: Joseph Turner; +Cc: michael_heerdegen, philipk, 68815, monnier
> From: Joseph Turner <joseph@breatheoutbreathe.in>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, 68815@debbugs.gnu.org,
> philipk@posteo.net, michael_heerdegen@web.de
> Date: Wed, 31 Jan 2024 23:04:59 -0800
>
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> From: Stefan Monnier <monnier@iro.umontreal.ca>
> >> Cc: 68815@debbugs.gnu.org, Philip Kaludercic <philipk@posteo.net>,
> >> michael_heerdegen@web.de, Eli Zaretskii <eliz@gnu.org>
> >> Date: Wed, 31 Jan 2024 17:05:30 -0500
> >>
> >> >> Also, performance can be a concern (in many cases it makes more sense
> >> >> to make the caller pass the unquoted name rather than force it to quote
> >> >> the name only for PRED to unquote it).
> >> >
> >> > The REQUIRE-MATCH function is only called once when the user attempts to
> >> > exit the minibuffer. Would you please explain the performance concern?
> >>
> >> Oh, sorry, I got confused. Indeed, you're wrapping the REQUIRE-MATCH
> >> arg, not the PRED arg I was ranting about. Duh!
> >>
> >> It would be OK for `emacs-29`, indeed. Eli? Stefan? Any objection?
> >
> > I don't mind, but please note that I'm not sure there will be any
> > further 29.x releases.
>
> Good to know. What is the purpose of keeping the emacs-29 branch, then?
I'm not sure we will NOT release further 29.x versions, either. There
could be some urgent issue that justifies another release, for
example.
My point is that the motivation for backporting improvements and fixes
from master and for installing non-essential fixes on the release
branch is supposed to go down, since we keep the branch active only
for some unanticipated contingencies.
^ permalink raw reply [relevance 0%]
* bug#68815: Unexpected behavior with read-file-name and functional REQUIRE-MATCH argument
2024-02-01 7:59 0% ` Eli Zaretskii
@ 2024-02-01 22:26 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 0 replies; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-02-01 22:26 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: michael_heerdegen, philipk, 68815, monnier
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Joseph Turner <joseph@breatheoutbreathe.in>
>> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, 68815@debbugs.gnu.org,
>> philipk@posteo.net, michael_heerdegen@web.de
>> Date: Wed, 31 Jan 2024 23:04:59 -0800
>>
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> >> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> >> Cc: 68815@debbugs.gnu.org, Philip Kaludercic <philipk@posteo.net>,
>> >> michael_heerdegen@web.de, Eli Zaretskii <eliz@gnu.org>
>> >> Date: Wed, 31 Jan 2024 17:05:30 -0500
>> >>
>> >> >> Also, performance can be a concern (in many cases it makes more sense
>> >> >> to make the caller pass the unquoted name rather than force it to quote
>> >> >> the name only for PRED to unquote it).
>> >> >
>> >> > The REQUIRE-MATCH function is only called once when the user attempts to
>> >> > exit the minibuffer. Would you please explain the performance concern?
>> >>
>> >> Oh, sorry, I got confused. Indeed, you're wrapping the REQUIRE-MATCH
>> >> arg, not the PRED arg I was ranting about. Duh!
>> >>
>> >> It would be OK for `emacs-29`, indeed. Eli? Stefan? Any objection?
>> >
>> > I don't mind, but please note that I'm not sure there will be any
>> > further 29.x releases.
>>
>> Good to know. What is the purpose of keeping the emacs-29 branch, then?
>
> I'm not sure we will NOT release further 29.x versions, either. There
> could be some urgent issue that justifies another release, for
> example.
>
> My point is that the motivation for backporting improvements and fixes
> from master and for installing non-essential fixes on the release
> branch is supposed to go down, since we keep the branch active only
> for some unanticipated contingencies.
Thank you for explaining.
^ permalink raw reply [relevance 5%]
* bug#67390: 28; shorthands-font-lock-shorthands assumes shorthand uses same separator
2023-12-09 18:50 8% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-02-03 7:10 11% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-03 14:50 5% ` João Távora
0 siblings, 1 reply; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-02-03 7:10 UTC (permalink / raw)
To: João Távora, Jonas Bernoulli, Eli Zaretskii, 67390,
Adam Porter
Joseph Turner <joseph@ushin.org> writes:
> Hi João! Thanks for your patience - preparing for EmacsConf was a blast,
> and now I'm on a plane to go visit my grandmother!
>
> João Távora <joaotavora@gmail.com> writes:
>
>> Hi all,
>>
>> I've been working on all these shorthand-related issues over the last
>> two days and I have reasonably short fixes for all of them.
>>
>> For this particular issue (bug#67309), I've opted to
>> use Joseph's patch with very slight adjustments, as it's the
>> only one that guarantees correct behaviour and doesn't seem
>> to impact performance.
>>
>> The other issues are:
>>
>> bug#63480 (loaddefs-gen.el doesn't know about shorthands)
>> bug#67325 (prefix discovery i.e. register-definition-prefixes)
>> bug#67523 (check-declare.el doesn't know about shorthands)
>>
>> I have all this in 6 commits in the bugfix/shorthand-fixes branch.
>>
>> Here's the full patch minus whitespace changes. If there are
>> no comments I'll push in a few days' time.
>>
>> João
>>
>> diff --git a/doc/lispref/symbols.texi b/doc/lispref/symbols.texi
>> index 1f3b677d7fb..18e80311177 100644
>> --- a/doc/lispref/symbols.texi
>> +++ b/doc/lispref/symbols.texi
>> @@ -761,6 +761,23 @@ Shorthands
>> ;; End:
>> @end example
>>
>> +Note that if you have two shorthands in the same file where one is the
>> +prefix of the other, the longer shorthand will be attempted first.
>> +This happens regardless of the order you specify shorthands in the
>> +local variables section of your file.
>> +
>> +@example
>> +'(
>> + t//foo ; reads to 'my-tricks--foo', not 'my-tricks-/foo'
>> + t/foo ; reads to 'my-tricks-foo'
>> + )
>> +
>> +;; Local Variables:
>> +;; read-symbol-shorthands: (("t/" . "my-tricks-")
>> +;; ("t//" . "my-tricks--")
>> +;; End:
>> +@end example
>> +
>> @subsection Exceptions
>
> Clear and concise.
>
>> There are two exceptions to rules governing Shorthand transformations:
>> diff --git a/lisp/emacs-lisp/check-declare.el b/lisp/emacs-lisp/check-declare.el
>> index c887d95210c..b19aedf314d 100644
>> --- a/lisp/emacs-lisp/check-declare.el
>> +++ b/lisp/emacs-lisp/check-declare.el
>> @@ -145,21 +145,26 @@ check-declare-verify
>> (if (file-regular-p fnfile)
>> (with-temp-buffer
>> (insert-file-contents fnfile)
>> + (unless cflag
>> + ;; If in Elisp, ensure syntax and shorthands available
>> + (set-syntax-table emacs-lisp-mode-syntax-table)
>> + (let (enable-local-variables) (hack-local-variables)))
>> ;; defsubst's don't _have_ to be known at compile time.
>> - (setq re (format (if cflag
>> - "^[ \t]*\\(DEFUN\\)[ \t]*([ \t]*\"%s\""
>> + (setq re (if cflag
>> + (format "^[ \t]*\\(DEFUN\\)[ \t]*([ \t]*\"%s\""
>> + (regexp-opt (mapcar 'cadr fnlist) t))
>> "^[ \t]*(\\(fset[ \t]+'\\|\
>> cl-def\\(?:generic\\|method\\|un\\)\\|\
>> def\\(?:un\\|subst\\|foo\\|method\\|class\\|\
>> ine-\\(?:derived\\|generic\\|\\(?:global\\(?:ized\\)?-\\)?minor\\)-mode\\|\
>> \\(?:ine-obsolete-function-\\)?alias[ \t]+'\\|\
>> ine-overloadable-function\\)\\)\
>> -[ \t]*%s\\([ \t;]+\\|$\\)")
>> - (regexp-opt (mapcar 'cadr fnlist) t)))
>> +[ \t]*\\(\\(?:\\sw\\|\\s_\\)+\\)\\([ \t;]+\\|$\\)"))
>
> Would you explain what this regexp is intended to match?
>
>> (while (re-search-forward re nil t)
>> (skip-chars-forward " \t\n")
>> - (setq fn (match-string 2)
>> - type (match-string 1)
>> + (setq fn (symbol-name (car (read-from-string (match-string 2)))))
>> + (when (member fn (mapcar 'cadr fnlist))
>> + (setq type (match-string 1)
>> ;; (min . max) for a fixed number of arguments, or
>> ;; arglists with optional elements.
>> ;; (min) for arglists with &rest.
>> @@ -202,7 +207,7 @@ check-declare-verify
>> (t
>> 'err))
>> ;; alist of functions and arglist signatures.
>> - siglist (cons (cons fn sig) siglist)))))
>> + siglist (cons (cons fn sig) siglist))))))
>> (dolist (e fnlist)
>> (setq arglist (nth 2 e)
>> type
>
> On my machine, this patch removes some of the check-declare "function
> not found" errors, but not all. For example, with hyperdrive-lib.el:
>
> (check-declare-file "~/.local/src/hyperdrive.el/hyperdrive-lib.el")
>
> Before this patch, the "*Check Declarations Warnings*" buffer shows:
>
> --8<---------------cut here---------------start------------->8---
> ■ hyperdrive-lib.el:44:Warning (check-declare): said ‘h/mode’ was defined in
> ../../../.emacs.d/elpa/hyperdrive/hyperdrive.el: function not found
> ■ hyperdrive-lib.el:508:Warning (check-declare): said ‘h/history’ was defined
> in ../../../.emacs.d/elpa/hyperdrive/hyperdrive-history.el: function not
> found
> ■ hyperdrive-lib.el:1283:Warning (check-declare): said ‘h/org--link-goto’ was
> defined in ../../../.emacs.d/elpa/hyperdrive/hyperdrive-org.el: function
> not found
> ■ hyperdrive-lib.el:45:Warning (check-declare): said ‘h/dir-mode’ was defined
> in ../../../.emacs.d/elpa/hyperdrive/hyperdrive-dir.el: function not found
> ■ hyperdrive-lib.el:1069:Warning (check-declare): said
> ‘h/dir--entry-at-point’ was defined in
> ../../../.emacs.d/elpa/hyperdrive/hyperdrive-dir.el: function not found
> ■ hyperdrive-lib.el:1332:Warning (check-declare): said ‘h/dir-handler’ was
> defined in ../../../.emacs.d/elpa/hyperdrive/hyperdrive-dir.el: function
> not found
> --8<---------------cut here---------------end--------------->8---
>
>
> and after your patch:
>
> --8<---------------cut here---------------start------------->8---
> ■ hyperdrive-lib.el:44:Warning (check-declare): said ‘h/mode’ was defined in
> ../../../.emacs.d/elpa/hyperdrive/hyperdrive.el: function not found
> ■ hyperdrive-lib.el:508:Warning (check-declare): said ‘h/history’ was defined
> in ../../../.emacs.d/elpa/hyperdrive/hyperdrive-history.el: function not
> found
> ■ hyperdrive-lib.el:1332:Warning (check-declare): said ‘h/dir-handler’ was
> defined in ../../../.emacs.d/elpa/hyperdrive/hyperdrive-dir.el: function
> not found
> --8<---------------cut here---------------end--------------->8---
>
> Are you able to reproduce this on your machine?
>
>> diff --git a/lisp/emacs-lisp/loaddefs-gen.el b/lisp/emacs-lisp/loaddefs-gen.el
>> index 04bea4723a2..e8093200bec 100644
>> --- a/lisp/emacs-lisp/loaddefs-gen.el
>> +++ b/lisp/emacs-lisp/loaddefs-gen.el
>> @@ -378,6 +378,7 @@ loaddefs-generate--parse-file
>> (let ((defs nil)
>> (load-name (loaddefs-generate--file-load-name file main-outfile))
>> (compute-prefixes t)
>> + read-symbol-shorthands
>> local-outfile inhibit-autoloads)
>> (with-temp-buffer
>> (insert-file-contents file)
>> @@ -399,7 +400,19 @@ loaddefs-generate--parse-file
>> (setq inhibit-autoloads (read (current-buffer)))))
>> (save-excursion
>> (when (re-search-forward "autoload-compute-prefixes: *" nil t)
>> - (setq compute-prefixes (read (current-buffer))))))
>> + (setq compute-prefixes (read (current-buffer)))))
>> + (save-excursion
>> + ;; since we're "open-coding" we have to repeat more
>> + ;; complicated logic in `hack-local-variables'.
>> + (when (re-search-forward "read-symbol-shorthands: *" nil t)
>> + (let* ((commentless (replace-regexp-in-string
>> + "\n\\s-*;+" ""
>> + (buffer-substring (point) (point-max))))
>> + (unsorted-shorthands (car (read-from-string commentless))))
>> + (setq read-symbol-shorthands
>> + (sort unsorted-shorthands
>> + (lambda (sh1 sh2)
>> + (> (length (car sh1)) (length (car sh2))))))))))
>
> IIUC, the intention here is to jump to a final "Local Variables"
> declaration at the end of the file, then remove ";;", then read in the
> uncommented value of `read-symbol-shorthands'.
>
> Since `read-from-string' just reads one expression, the above hunk works
> when there are more local variables after read-symbol-shorthands:
>
> ;; Local Variables:
> ;; read-symbol-shorthands: (("bc-" . "breadcrumb-"))
> ;; autoload-compute-prefixes: nil
> ;; End:
>
> But if the read-symbol-shorthands declaration comes at the top, as in...
>
> -*- read-symbol-shorthands: (("bc-" . "breadcrumb-")); -*-
>
> ...then this form will allocate two strings almost as long as the file.
>
> Here's an alternative hack attempting to uncomment and read the minimum:
>
> diff --git a/lisp/emacs-lisp/loaddefs-gen.el b/lisp/emacs-lisp/loaddefs-gen.el
> index e8093200bec..406e4b28f1f 100644
> --- a/lisp/emacs-lisp/loaddefs-gen.el
> +++ b/lisp/emacs-lisp/loaddefs-gen.el
> @@ -404,10 +404,13 @@ don't include."
> (save-excursion
> ;; since we're "open-coding" we have to repeat more
> ;; complicated logic in `hack-local-variables'.
> - (when (re-search-forward "read-symbol-shorthands: *" nil t)
> - (let* ((commentless (replace-regexp-in-string
> + (when-let ((beg
> + (re-search-forward "read-symbol-shorthands: *" nil t)))
> + ;; `read-symbol-shorthands' alist ends with two parens.
> + (let* ((end (re-search-forward ")[;\n\s]*)"))
> + (commentless (replace-regexp-in-string
> "\n\\s-*;+" ""
> - (buffer-substring (point) (point-max))))
> + (buffer-substring beg end)))
> (unsorted-shorthands (car (read-from-string commentless))))
> (setq read-symbol-shorthands
> (sort unsorted-shorthands
>
>> ;; We always return the package version (even for pre-dumped
>> ;; files).
>> @@ -486,7 +499,11 @@ loaddefs-generate--compute-prefixes
>> (while (re-search-forward
>> "^(\\(def[^ \t\n]+\\)[ \t\n]+['(]*\\([^' ()\"\n]+\\)[\n \t]" nil t)
>> (unless (member (match-string 1) autoload-ignored-definitions)
>> - (let ((name (match-string-no-properties 2)))
>> + (let* ((name (match-string-no-properties 2))
>> + ;; Consider `read-symbol-shorthands'.
>> + (probe (let ((obarray (obarray-make)))
>> + (car (read-from-string name)))))
>> + (setq name (symbol-name probe))
>> (when (save-excursion
>> (goto-char (match-beginning 0))
>> (or (bobp)
>> diff --git a/lisp/emacs-lisp/shorthands.el b/lisp/emacs-lisp/shorthands.el
>> index b0665a55695..69b562e3c7e 100644
>> --- a/lisp/emacs-lisp/shorthands.el
>> +++ b/lisp/emacs-lisp/shorthands.el
>> @@ -52,38 +52,26 @@ elisp-shorthand-font-lock-face
>> :version "28.1"
>> :group 'font-lock-faces)
>>
>> -(defun shorthands--mismatch-from-end (str1 str2)
>> - "Tell index of first mismatch in STR1 and STR2, from end.
>> -The index is a valid 0-based index on STR1. Returns nil if STR1
>> -equals STR2. Return 0 if STR1 is a suffix of STR2."
>> - (cl-loop with l1 = (length str1) with l2 = (length str2)
>> - for i from 1
>> - for i1 = (- l1 i) for i2 = (- l2 i)
>> - while (eq (aref str1 i1) (aref str2 i2))
>> - if (zerop i2) return (if (zerop i1) nil i1)
>> - if (zerop i1) return 0
>> - finally (return i1)))
>> -
>> (defun shorthands-font-lock-shorthands (limit)
>> + "Font lock until LIMIT considering `read-symbol-shorthands'."
>> (when read-symbol-shorthands
>> (while (re-search-forward
>> (concat "\\_<\\(" (rx lisp-mode-symbol) "\\)\\_>")
>> limit t)
>> (let* ((existing (get-text-property (match-beginning 1) 'face))
>> + (print-name (match-string 1))
>> (probe (and (not (memq existing '(font-lock-comment-face
>> font-lock-string-face)))
>> - (intern-soft (match-string 1))))
>> - (sname (and probe (symbol-name probe)))
>> - (mismatch (and sname (shorthands--mismatch-from-end
>> - (match-string 1) sname)))
>> - (guess (and mismatch (1+ mismatch))))
>> - (when guess
>> - (when (and (< guess (1- (length (match-string 1))))
>> - ;; In bug#67390 we allow other separators
>> - (eq (char-syntax (aref (match-string 1) guess)) ?_))
>> - (setq guess (1+ guess)))
>> + (intern-soft print-name)))
>> + (symbol-name (and probe (symbol-name probe)))
>> + (prefix (and symbol-name
>> + (not (string-equal print-name symbol-name))
>> + (car (assoc print-name
>> + read-symbol-shorthands
>> + #'string-prefix-p)))))
>> + (when prefix
>> (add-face-text-property (match-beginning 1)
>> - (+ (match-beginning 1) guess)
>> + (+ (match-beginning 1) (length prefix))
>> 'elisp-shorthand-font-lock-face))))))
>
> Works well. let-binding `symbol-name' and `print-name' is good improvement.
>
>> (font-lock-add-keywords 'emacs-lisp-mode
>> '((shorthands-font-lock-shorthands)) t)
>> diff --git a/lisp/files.el b/lisp/files.el
>> index 1cdcec23b11..b266d0727ec 100644
>> --- a/lisp/files.el
>> +++ b/lisp/files.el
>> @@ -3735,7 +3735,8 @@ before-hack-local-variables-hook
>> This hook is called only if there is at least one file-local
>> variable to set.")
>>
>> -(defvar permanently-enabled-local-variables '(lexical-binding)
>> +(defvar permanently-enabled-local-variables
>> + '(lexical-binding read-symbol-shorthands)
>> "A list of file-local variables that are always enabled.
>> This overrides any `enable-local-variables' setting.")
>>
>> @@ -4171,6 +4172,13 @@ hack-local-variables--find-variables
>> ;; to use 'thisbuf's name in the
>> ;; warning message.
>> (or (buffer-file-name thisbuf) ""))))))
>> + ((eq var 'read-symbol-shorthands)
>> + ;; Sort automatically by shorthand length
>> + ;; descending
>> + (setq val (sort val
>> + (lambda (sh1 sh2) (>
>> (length (car sh1))
>> +
>> (length (car sh2))))))
>> + (push (cons 'read-symbol-shorthands val) result))
>> ((and (eq var 'mode) handle-mode))
>> (t
>> (ignore-errors
>
> Good catch. I agree that longer shorthands should be applied first.
>
> -----
>
> A couple typo nits on the commit message of "Improve
> shorthands-font-lock-shorthands (bug#67390)":
>
> - h//thingy ; hilits "//" reads to 'hyperdrive--thingy'
> + h//thingy ; hilits "h//" reads to 'hyperdrive--thingy'
>
> - Co-authored-by: João Távora <joaotavora@gmail.com>
> + Co-authored-by: Joseph Turner <joseph@breatheoutbreathe.in>
>
>
> Thank you!
>
> Joseph
Ping!
^ permalink raw reply [relevance 11%]
* bug#67390: 28; shorthands-font-lock-shorthands assumes shorthand uses same separator
2024-02-03 7:10 11% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-02-03 14:50 5% ` João Távora
2024-02-03 19:43 10% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 200+ results
From: João Távora @ 2024-02-03 14:50 UTC (permalink / raw)
To: Joseph Turner; +Cc: 67390, Adam Porter, Eli Zaretskii, Jonas Bernoulli
Sorry, this flew under the radar. I thought I had already pushed to master
but didn't. So I went through the commits again, addressed your concerns, and
applied your suggestions. Pushed to master now.
On Sat, Feb 3, 2024 at 7:10 AM Joseph Turner <joseph@ushin.org> wrote:
>> -[ \t]*%s\\([ \t;]+\\|$\\)")
>> - (regexp-opt (mapcar 'cadr fnlist) t)))
>> +[ \t]*\\(\\(?:\\sw\\|\\s_\\)+\\)\\([ \t;]+\\|$\\)"))
>
> Would you explain what this regexp is intended to match?
A very complicated one, right? Well ask the author, but I think it's intended
to find many definition-like forms. No idea why this is done with regexps and
not with 'read' as it is a classical parsing pitfall in the long run.
Maybe there
was a reason.
Anyway, I just added a bit of logic so that it considers
read-symbol-shorthands if
there are any.
> Are you able to reproduce this on your machine?
Yes, and I fixed it.
> ...then this form will allocate two strings almost as long as the file.
>
> Here's an alternative hack attempting to uncomment and read the minimum:
Thanks, I think that's a good idea and I added a commit in your name.
> A couple typo nits on the commit message of "Improve
> shorthands-font-lock-shorthands (bug#67390)":
>
> - h//thingy ; hilits "//" reads to 'hyperdrive--thingy'
> + h//thingy ; hilits "h//" reads to 'hyperdrive--thingy'
>
> - Co-authored-by: João Távora <joaotavora@gmail.com>
> + Co-authored-by: Joseph Turner <joseph@breatheoutbreathe.in>
I fixed these, too. If you succesfully test this, I think we can close this bug
(and the other ones, too).
João
^ permalink raw reply [relevance 5%]
* bug#67390: 28; shorthands-font-lock-shorthands assumes shorthand uses same separator
2024-02-03 14:50 5% ` João Távora
@ 2024-02-03 19:43 10% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-03 22:25 5% ` João Távora
0 siblings, 1 reply; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-02-03 19:43 UTC (permalink / raw)
To: João Távora; +Cc: 67390, adam, eliz, jonas
[-- Attachment #1: Type: text/plain, Size: 2539 bytes --]
João Távora <joaotavora@gmail.com> writes:
> Sorry, this flew under the radar. I thought I had already pushed to master
> but didn't. So I went through the commits again, addressed your concerns, and
> applied your suggestions. Pushed to master now.
Thank you!
> On Sat, Feb 3, 2024 at 7:10 AM Joseph Turner <joseph@ushin.org> wrote:
>
>
>>> -[ \t]*%s\\([ \t;]+\\|$\\)")
>>> - (regexp-opt (mapcar 'cadr fnlist) t)))
>>> +[ \t]*\\(\\(?:\\sw\\|\\s_\\)+\\)\\([ \t;]+\\|$\\)"))
>>
>> Would you explain what this regexp is intended to match?
>
> A very complicated one, right? Well ask the author, but I think it's intended
> to find many definition-like forms. No idea why this is done with regexps and
> not with 'read' as it is a classical parsing pitfall in the long run.
> Maybe there
> was a reason.
>
> Anyway, I just added a bit of logic so that it considers
> read-symbol-shorthands if
> there are any.
That makes sense.
>> Are you able to reproduce this on your machine?
>
> Yes, and I fixed it.
>
>> ...then this form will allocate two strings almost as long as the file.
>>
>> Here's an alternative hack attempting to uncomment and read the minimum:
>
> Thanks, I think that's a good idea and I added a commit in your name.
Thanks!
>> A couple typo nits on the commit message of "Improve
>> shorthands-font-lock-shorthands (bug#67390)":
>>
>> - h//thingy ; hilits "//" reads to 'hyperdrive--thingy'
>> + h//thingy ; hilits "h//" reads to 'hyperdrive--thingy'
>>
>> - Co-authored-by: João Távora <joaotavora@gmail.com>
>> + Co-authored-by: Joseph Turner <joseph@breatheoutbreathe.in>
>
> I fixed these, too. If you succesfully test this, I think we can close this bug
> (and the other ones, too).
I'm still reproducing the check-declare bug on my machine. It appears
that binding `enable-local-variables' to nil around the call to
`hack-local-variables' means that `read-symbol-shorthands' is not set.
Can we bind `enable-local-variables' to `:safe' instead?
(let (
;; (enable-local-variables t) ; works
;; (enable-local-variables) ; doesn't work
(enable-local-variables :safe) ; works
)
(with-temp-buffer
(insert-file-contents "~/.local/src/hyperdrive.el/hyperdrive-lib.el")
(hack-local-variables)
read-symbol-shorthands))
See attached patch.
There's no way to hack just a single file- or dir-local variable, right?
Thank you!
Joseph
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Bind-enable-local-variables-to-safe-for-shorthands-b.patch --]
[-- Type: text/x-diff, Size: 1667 bytes --]
From f301d839031f78b303d698d7bca1f0b27264d2d8 Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Sat, 3 Feb 2024 11:56:31 -0800
Subject: [PATCH] ; Bind enable-local-variables to :safe for shorthands
(bug#67523)
* lisp/emacs-lisp/check-declare.el (check-declare-scan):
(check-declare-verify):
---
lisp/emacs-lisp/check-declare.el | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lisp/emacs-lisp/check-declare.el b/lisp/emacs-lisp/check-declare.el
index a6d1a330d90..eff37828f65 100644
--- a/lisp/emacs-lisp/check-declare.el
+++ b/lisp/emacs-lisp/check-declare.el
@@ -87,7 +87,7 @@ don't know how to recognize (e.g. some macros)."
(insert-file-contents file)
;; Ensure shorthands available, as we will be `read'ing Elisp
;; (bug#67523)
- (let (enable-local-variables) (hack-local-variables))
+ (let ((enable-local-variables :safe)) (hack-local-variables))
;; FIXME we could theoretically be inside a string.
(while (re-search-forward "^[ \t]*\\((declare-function\\)[ \t\n]" nil t)
(let ((pos (match-beginning 1)))
@@ -152,7 +152,7 @@ is a string giving details of the error."
;; If in Elisp, ensure syntax and shorthands available
;; (bug#67523)
(set-syntax-table emacs-lisp-mode-syntax-table)
- (let (enable-local-variables) (hack-local-variables)))
+ (let ((enable-local-variables :safe)) (hack-local-variables)))
;; defsubst's don't _have_ to be known at compile time.
(setq re (if cflag
(format "^[ \t]*\\(DEFUN\\)[ \t]*([ \t]*\"%s\""
--
2.41.0
^ permalink raw reply related [relevance 10%]
* bug#67390: 28; shorthands-font-lock-shorthands assumes shorthand uses same separator
2024-02-03 19:43 10% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-02-03 22:25 5% ` João Távora
2024-02-03 23:48 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 200+ results
From: João Távora @ 2024-02-03 22:25 UTC (permalink / raw)
To: Joseph Turner; +Cc: 67390, adam, eliz, jonas
On Sat, Feb 3, 2024 at 8:01 PM Joseph Turner
<joseph@breatheoutbreathe.in> wrote:
> I'm still reproducing the check-declare bug on my machine. It appears
> that binding `enable-local-variables' to nil around the call to
> `hack-local-variables' means that `read-symbol-shorthands' is not set.
> Can we bind `enable-local-variables' to `:safe' instead?
It could be some bootstrapping issue, since the safe spec of that particular
variable itself needs to be autoloaded. I vaguely remember something like
this and I _think_ it was fixed.
Anyway, I can't reproduce this with this test:
src/emacs -Q --batch --eval '(check-declare-file
"~/tmp/hyperdrive.el/hyperdrive-lib.el")'
where ~/tmp/hyperdrive.el is a checkout of your hyperdrive library.
This doesn't output anything, which I think is the expected result.
How are you testing?
João
^ permalink raw reply [relevance 5%]
* bug#67390: 28; shorthands-font-lock-shorthands assumes shorthand uses same separator
2024-02-03 22:25 5% ` João Távora
@ 2024-02-03 23:48 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-05-21 22:05 10% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-02-03 23:48 UTC (permalink / raw)
To: João Távora; +Cc: 67390, adam, eliz, jonas
João Távora <joaotavora@gmail.com> writes:
> On Sat, Feb 3, 2024 at 8:01 PM Joseph Turner
> <joseph@breatheoutbreathe.in> wrote:
>
>> I'm still reproducing the check-declare bug on my machine. It appears
>> that binding `enable-local-variables' to nil around the call to
>> `hack-local-variables' means that `read-symbol-shorthands' is not set.
>> Can we bind `enable-local-variables' to `:safe' instead?
>
> It could be some bootstrapping issue, since the safe spec of that particular
> variable itself needs to be autoloaded. I vaguely remember something like
> this and I _think_ it was fixed.
>
> Anyway, I can't reproduce this with this test:
>
> src/emacs -Q --batch --eval '(check-declare-file
> "~/tmp/hyperdrive.el/hyperdrive-lib.el")'
>
> where ~/tmp/hyperdrive.el is a checkout of your hyperdrive library.
>
> This doesn't output anything, which I think is the expected result.
>
> How are you testing?
Hmm... I just compiled from master with
./configure --with-x-toolkit=no --with-xpm=ifavailable --with-jpeg=ifavailable --with-gif=ifavailable --with-tiff=ifavailable --with-gnutls=ifavailable && make
then I ran
src/emacs -Q --batch --eval '(check-declare-file "~/.local/src/hyperdrive.el/hyperdrive-lib.el")'
which produced
uncompressing textsec-check.el.gz...
uncompressing textsec-check.el.gz...done
../hyperdrive.el/hyperdrive-lib.el:44:Warning (check-declare): said ‘h/mode’ was defined in ../hyperdrive.el/hyperdrive.el: function not found
../hyperdrive.el/hyperdrive-lib.el:508:Warning (check-declare): said ‘h/history’ was defined in ../hyperdrive.el/hyperdrive-history.el: function not found
../hyperdrive.el/hyperdrive-lib.el:1332:Warning (check-declare): said ‘h/dir-handler’ was defined in ../hyperdrive.el/hyperdrive-dir.el: function not found
Would someone else kindly attempt to reproduce the issue?
Thanks!
Joseph
^ permalink raw reply [relevance 5%]
* bug#66114: [PATCH] Fix interactive prompt for selecting checkout directory
2024-01-30 8:42 11% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-02-14 16:54 5% ` Philip Kaludercic
2024-02-15 17:27 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-02-14 16:54 UTC (permalink / raw)
To: Joseph Turner; +Cc: 66114-done
Joseph Turner <joseph@breatheoutbreathe.in> writes:
> Joseph Turner <joseph@breatheoutbreathe.in> writes:
>
>> Philip Kaludercic <philipk@posteo.net> writes:
>>
>>> Joseph Turner <joseph@breatheoutbreathe.in> writes:
>>>
>>>> However, the behavior of
>>>> read-file-name is unspecified when a MUSTMATCH function returns nil:
>>>>
>>>> - a function, which will be called with the input as the
>>>> argument. If the function returns a non-nil value, the
>>>> minibuffer is exited with that argument as the value.
>>>>
>>>> Is this a bug, a case of under-documentation, or do I misunderstand something?
>>>>
>>>> I'm happy to post this in a separate bug thread if you think it's worth it.
>>>
>>> Perhaps that would be worth doing, that way the people who know more
>>> about completion than I do would be more likely to see it and help
>>> out.
>>
>> Okay, thanks! I'll do that.
>
> Now that #66187
> (<https://yhetil.org/emacs-bugs/87cytlqmqh.fsf@breatheoutbreathe.in/>)
> and bug#68815
> (<https://yhetil.org/emacs-bugs/8734ufyxoy.fsf@breatheoutbreathe.in/>)
> are fixed on emacs-29, I'm revisiting this issue.
>
> With the following patch, the interactive prompt in package-vc-checkout
> now offers all directory for completion (empty or not), but only exits
> when the minibuffer contains an empty directory or nonexistent filename.
>
> Testing this patch requires checking out emacs-29 after e6c82fe35e3.
LGTM, I've pushed it to emacs-29. Thanks!
> Thanks!
>
> Joseph
^ permalink raw reply [relevance 5%]
* bug#66114: [PATCH] Fix interactive prompt for selecting checkout directory
2024-02-14 16:54 5% ` Philip Kaludercic
@ 2024-02-15 17:27 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 0 replies; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-02-15 17:27 UTC (permalink / raw)
To: Philip Kaludercic; +Cc: 66114-done
Philip Kaludercic <philipk@posteo.net> writes:
> Joseph Turner <joseph@breatheoutbreathe.in> writes:
>
>> Joseph Turner <joseph@breatheoutbreathe.in> writes:
>>
>>> Philip Kaludercic <philipk@posteo.net> writes:
>>>
>>>> Joseph Turner <joseph@breatheoutbreathe.in> writes:
>>>>
>>>>> However, the behavior of
>>>>> read-file-name is unspecified when a MUSTMATCH function returns nil:
>>>>>
>>>>> - a function, which will be called with the input as the
>>>>> argument. If the function returns a non-nil value, the
>>>>> minibuffer is exited with that argument as the value.
>>>>>
>>>>> Is this a bug, a case of under-documentation, or do I misunderstand something?
>>>>>
>>>>> I'm happy to post this in a separate bug thread if you think it's worth it.
>>>>
>>>> Perhaps that would be worth doing, that way the people who know more
>>>> about completion than I do would be more likely to see it and help
>>>> out.
>>>
>>> Okay, thanks! I'll do that.
>>
>> Now that #66187
>> (<https://yhetil.org/emacs-bugs/87cytlqmqh.fsf@breatheoutbreathe.in/>)
>> and bug#68815
>> (<https://yhetil.org/emacs-bugs/8734ufyxoy.fsf@breatheoutbreathe.in/>)
>> are fixed on emacs-29, I'm revisiting this issue.
>>
>> With the following patch, the interactive prompt in package-vc-checkout
>> now offers all directory for completion (empty or not), but only exits
>> when the minibuffer contains an empty directory or nonexistent filename.
>>
>> Testing this patch requires checking out emacs-29 after e6c82fe35e3.
>
> LGTM, I've pushed it to emacs-29. Thanks!
Thanks!!
Joseph
^ permalink raw reply [relevance 5%]
* bug#69528: 30.0.50; [BUG] transient.el is not a member of package--builtin-versions
@ 2024-03-05 6:17 11% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-05-09 6:53 11% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-05-25 8:04 7% ` Philip Kaludercic
0 siblings, 2 replies; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-03-05 6:17 UTC (permalink / raw)
To: Philip Kaludercic; +Cc: 69528, iarchivedmywholelife
[-- Attachment #1: Type: text/plain, Size: 943 bytes --]
Philip Kaludercic <philipk@posteo.net> writes:
> So in general, this patch might be appropriate?
>
> diff --git a/lisp/emacs-lisp/loaddefs-gen.el b/lisp/emacs-lisp/loaddefs-gen.el
> index 581053f6304..42f386933dc 100644
> --- a/lisp/emacs-lisp/loaddefs-gen.el
> +++ b/lisp/emacs-lisp/loaddefs-gen.el
> @@ -433,7 +433,8 @@ loaddefs-generate--parse-file
> ;; loaddefs for packages so that `syntax-ppss' later gives
> ;; correct results.
> (emacs-lisp-mode)
> - (let ((version (lm-header "version"))
> + (let ((version (or (lm-header "package-version")
> + (lm-header "version")))
> package)
> (when (and version
> (setq version (ignore-errors (version-to-list version)))
>
>
What about making `lm-version' handle the "package-version" header then
using `lm-version' in loaddefs-generate--parse-file? See patches.
Joseph
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0002-Use-lm-version-instead-of-lm-header-version.patch --]
[-- Type: text/x-diff, Size: 998 bytes --]
From e83ee369ae90e5e15b3adca9eab1ded4db864427 Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Mon, 4 Mar 2024 22:15:50 -0800
Subject: [PATCH 2/2] Use lm-version instead of lm-header "version"
bug#69528
* lisp/emacs-lisp/loaddefs-gen.el (loaddefs-generate--parse-file)
---
lisp/emacs-lisp/loaddefs-gen.el | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lisp/emacs-lisp/loaddefs-gen.el b/lisp/emacs-lisp/loaddefs-gen.el
index 581053f6304..6b24f7dc8c7 100644
--- a/lisp/emacs-lisp/loaddefs-gen.el
+++ b/lisp/emacs-lisp/loaddefs-gen.el
@@ -433,7 +433,7 @@ loaddefs-generate--parse-file
;; loaddefs for packages so that `syntax-ppss' later gives
;; correct results.
(emacs-lisp-mode)
- (let ((version (lm-header "version"))
+ (let ((version (lm-version))
package)
(when (and version
(setq version (ignore-errors (version-to-list version)))
--
2.41.0
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0001-Check-Package-Version-header-in-lm-version-also.patch --]
[-- Type: text/x-diff, Size: 785 bytes --]
From 20db8c9afcb03d8a5acb750fa738c5066e204401 Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Mon, 4 Mar 2024 22:14:26 -0800
Subject: [PATCH 1/2] Check Package-Version: header in lm-version also
* lisp/emacs-lisp/lisp-mnt.el (lm-version)
---
lisp/emacs-lisp/lisp-mnt.el | 1 +
1 file changed, 1 insertion(+)
diff --git a/lisp/emacs-lisp/lisp-mnt.el b/lisp/emacs-lisp/lisp-mnt.el
index f111a77663c..12b23853801 100644
--- a/lisp/emacs-lisp/lisp-mnt.el
+++ b/lisp/emacs-lisp/lisp-mnt.el
@@ -416,6 +416,7 @@ lm-version
This can be found in an RCS or SCCS header."
(lm-with-file file
(or (lm-header "version")
+ (lm-header "package-version")
(let ((header-max (lm-code-start)))
(goto-char (point-min))
(cond
--
2.41.0
^ permalink raw reply related [relevance 11%]
* bug#69602: 29.1; Image :map should adjust with :scale and :rotation
@ 2024-03-07 5:37 3% Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-07 7:04 0% ` Eli Zaretskii
0 siblings, 1 reply; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-03-07 5:37 UTC (permalink / raw)
To: 69602; +Cc: Stephen Berman, Juri Linkov
Currently, when running `image-increase-size' or `image-decrease-size'
on an image with a :map property, the image scales but the image map
does not. For example, run the following snippet:
(with-current-buffer (get-buffer-create "*image-properties-test*")
(let ((svg "<?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"no\"?>\n<!DOCTYPE svg PUBLIC \"-//W3C//DTD SVG 1.1//EN\"\n \"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd\">\n<!-- Generated by graphviz version 2.43.0 (0)\n -->\n<!-- Title: orggraphview Pages: 1 -->\n<svg width=\"128pt\" height=\"128pt\"\n viewBox=\"0.00 0.00 127.59 127.59\" xmlns=\"http://www.w3.org/2000/svg\" xmlns:xlink=\"http://www.w3.org/1999/xlink\">\n<g id=\"graph0\" class=\"graph\" transform=\"scale(1 1) rotate(0) translate(4 123.59)\">\n<title>orggraphview</title>\n<polygon fill=\"white\" stroke=\"transparent\" points=\"-4,4 -4,-123.59 123.59,-123.59 123.59,4 -4,4\"/>\n<!-- a -->\n<g id=\"node1\" class=\"node\">\n<title>a</title>\n<g id=\"a_node1\"><a xlink:href=\"1\" xlink:title=\"Hover me!\">\n<ellipse fill=\"none\" stroke=\"black\" cx=\"59.79\" cy=\"-59.79\" rx=\"59.59\" ry=\"59.59\"/>\n<text text-anchor=\"middle\" x=\"59.79\" y=\"-56.09\" font-family=\"Times,serif\" font-size=\"14.00\" fill=\"#000000\">Hover me!</text>\n</a>\n</g>\n</g>\n</g>\n</svg>\n")
(map '(((circle (85 . 85) . 80) "1" (help-echo "Surprise!"))))
(inhibit-read-only t))
(erase-buffer)
(insert-image (create-image svg 'svg t :map map))
(goto-char (point-min))
(pop-to-buffer (current-buffer))))
Hovering the circle alters the pointer style and displays the tooltip.
Now run `M-x image-increase-size' or press "i +". While the image
becomes larger, the area which activates the tooltip remains the same.
See earlier discussion here:
https://yhetil.org/emacs-devel/87r0gng41l.fsf@ushin.org/T/#t
While a proper solution perhaps belongs on the C side, the following
workaround adds an :unscaled-map property to images and sets :map
according to :unscaled-map and :scale whenever :scale changes.
This workaround does not (yet) handle :rotation.
--8<---------------cut here---------------start------------->8---
(defun image--scale-map (map factor)
"Scale MAP by FACTOR, destructively modifying it."
(unless (= 1 factor)
(pcase-dolist (`(,`(,type . ,coords) ,_id ,_plist) map)
(pcase-exhaustive type
('rect
(setf (caar coords) (round (* (caar coords) factor)))
(setf (cdar coords) (round (* (cdar coords) factor)))
(setf (cadr coords) (round (* (cadr coords) factor)))
(setf (cddr coords) (round (* (cddr coords) factor))))
('circle
(setf (caar coords) (round (* (caar coords) factor)))
(setf (cdar coords) (round (* (cdar coords) factor)))
(setf (cdr coords) (round (* (cdr coords) factor))))
('poly
(dotimes (i (length coords))
(aset coords i
(round (* (aref coords i) factor))))))))
map)
(defun image--create-image-add-unscaled-map
(orig-fun file-or-data &optional type data-p &rest props)
"Add :unscaled-map property to image returned by ORIG-FUN and return it.
Intended to be used as :around advice for `create-image'."
(let ((image (apply orig-fun file-or-data type data-p props)))
(when-let ((map (image-property image :map)))
(setq image (nconc image
(list :unscaled-map (copy-tree map t))))
(when-let* ((props-scale (plist-get props :scale))
((numberp props-scale)))
(setf (image-property image :unscaled-map)
(image--scale-map (image-property image :unscaled-map)
(/ 1.0 props-scale)))))
image))
(advice-add #'create-image :around #'image--create-image-add-unscaled-map)
(defun image--change-size-scale-map (_factor &optional position)
"Scale :map property of image at point to fit its :scale.
Intended to be used as :after advice for `image--change-size'."
(when-let* ((image (image--get-imagemagick-and-warn position))
(map (image-property image :map))
(unscaled-map (image-property image :unscaled-map))
(scale (image-property image :scale)))
(setf (image-property image :map)
;; TODO: Instead of copying `:unscaled-map', reuse the :map vector?
(image--scale-map (copy-tree unscaled-map t) scale))))
(advice-add #'image--change-size :after #'image--change-size-scale-map)
--8<---------------cut here---------------end--------------->8---
Thank you!
Joseph
In GNU Emacs 29.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.37,
cairo version 1.16.0)
Windowing system distributor 'The X.Org Foundation', version 11.0.12101007
System Description: Debian GNU/Linux 12 (bookworm)
^ permalink raw reply [relevance 3%]
* bug#69602: 29.1; Image :map should adjust with :scale and :rotation
2024-03-07 5:37 3% bug#69602: 29.1; Image :map should adjust with :scale and :rotation Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-03-07 7:04 0% ` Eli Zaretskii
2024-03-07 7:14 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 200+ results
From: Eli Zaretskii @ 2024-03-07 7:04 UTC (permalink / raw)
To: Joseph Turner; +Cc: 69602, stephen.berman, juri
> Cc: Stephen Berman <stephen.berman@gmx.net>, Juri Linkov <juri@linkov.net>
> Date: Wed, 06 Mar 2024 21:37:50 -0800
> From: Joseph Turner via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>
> Currently, when running `image-increase-size' or `image-decrease-size'
> on an image with a :map property, the image scales but the image map
> does not. For example, run the following snippet:
>
> (with-current-buffer (get-buffer-create "*image-properties-test*")
> (let ((svg "<?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"no\"?>\n<!DOCTYPE svg PUBLIC \"-//W3C//DTD SVG 1.1//EN\"\n \"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd\">\n<!-- Generated by graphviz version 2.43.0 (0)\n -->\n<!-- Title: orggraphview Pages: 1 -->\n<svg width=\"128pt\" height=\"128pt\"\n viewBox=\"0.00 0.00 127.59 127.59\" xmlns=\"http://www.w3.org/2000/svg\" xmlns:xlink=\"http://www.w3.org/1999/xlink\">\n<g id=\"graph0\" class=\"graph\" transform=\"scale(1 1) rotate(0) translate(4 123.59)\">\n<title>orggraphview</title>\n<polygon fill=\"white\" stroke=\"transparent\" points=\"-4,4 -4,-123.59 123.59,-123.59 123.59,4 -4,4\"/>\n<!-- a -->\n<g id=\"node1\" class=\"node\">\n<title>a</title>\n<g id=\"a_node1\"><a xlink:href=\"1\" xlink:title=\"Hover me!\">\n<ellipse fill=\"none\" stroke=\"black\" cx=\"59.79\" cy=\"-59.79\" rx=\"59.59\" ry=\"59.59\"/>\n<text text-anchor=\"middle\" x=\"59.79\" y=\"-56.09\" font-family=\"Times,serif\" font-size=\"14.00\" fill=\"#000000\">Hover me!</text>\n</a>\n</g>\n</g>\n</g>\n</svg>\n")
> (map '(((circle (85 . 85) . 80) "1" (help-echo "Surprise!"))))
> (inhibit-read-only t))
> (erase-buffer)
> (insert-image (create-image svg 'svg t :map map))
> (goto-char (point-min))
> (pop-to-buffer (current-buffer))))
>
> Hovering the circle alters the pointer style and displays the tooltip.
>
> Now run `M-x image-increase-size' or press "i +". While the image
> becomes larger, the area which activates the tooltip remains the same.
>
> See earlier discussion here:
>
> https://yhetil.org/emacs-devel/87r0gng41l.fsf@ushin.org/T/#t
>
> While a proper solution perhaps belongs on the C side, the following
> workaround adds an :unscaled-map property to images and sets :map
> according to :unscaled-map and :scale whenever :scale changes.
The ELisp manual says about :map:
Note that the map's coordinates should reflect the displayed image
after all transforms have been done (rotation, scaling and so on),
and also note that Emacs (by default) performs auto-scaling of
images, so to make things match up, you should either specify
‘:scale 1.0’ when creating the image, or use the result of
‘image-compute-scaling-factor’ to compute the elements of the map.
Can this technique help?
^ permalink raw reply [relevance 0%]
* bug#69602: 29.1; Image :map should adjust with :scale and :rotation
2024-03-07 7:04 0% ` Eli Zaretskii
@ 2024-03-07 7:14 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-07 7:55 0% ` Eli Zaretskii
0 siblings, 1 reply; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-03-07 7:14 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 69602, stephen.berman, juri
Eli Zaretskii <eliz@gnu.org> writes:
> The ELisp manual says about :map:
>
> Note that the map's coordinates should reflect the displayed image
> after all transforms have been done (rotation, scaling and so on),
> and also note that Emacs (by default) performs auto-scaling of
> images, so to make things match up, you should either specify
> ‘:scale 1.0’ when creating the image, or use the result of
> ‘image-compute-scaling-factor’ to compute the elements of the map.
>
> Can this technique help?
Thank you for your help!
When the user runs `image-increase-size', where should third-party code
recompute :map to fit the new image scale?
There's no `image-after-change-size-hook' nor `image-after-rotate-hook'.
Joseph
^ permalink raw reply [relevance 5%]
* bug#69602: 29.1; Image :map should adjust with :scale and :rotation
2024-03-07 7:14 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-03-07 7:55 0% ` Eli Zaretskii
2024-03-07 8:08 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 200+ results
From: Eli Zaretskii @ 2024-03-07 7:55 UTC (permalink / raw)
To: Joseph Turner; +Cc: 69602, stephen.berman, juri
> From: Joseph Turner <joseph@breatheoutbreathe.in>
> Cc: 69602@debbugs.gnu.org, stephen.berman@gmx.net, juri@linkov.net
> Date: Wed, 06 Mar 2024 23:14:21 -0800
>
> Eli Zaretskii <eliz@gnu.org> writes:
> > The ELisp manual says about :map:
> >
> > Note that the map's coordinates should reflect the displayed image
> > after all transforms have been done (rotation, scaling and so on),
> > and also note that Emacs (by default) performs auto-scaling of
> > images, so to make things match up, you should either specify
> > ‘:scale 1.0’ when creating the image, or use the result of
> > ‘image-compute-scaling-factor’ to compute the elements of the map.
> >
> > Can this technique help?
>
> Thank you for your help!
>
> When the user runs `image-increase-size', where should third-party code
> recompute :map to fit the new image scale?
>
> There's no `image-after-change-size-hook' nor `image-after-rotate-hook'.
I think the idea is to define the value of :map such that it runs
image-compute-scaling-factor as part of computing the coordinates of
the map.
^ permalink raw reply [relevance 0%]
* bug#69602: 29.1; Image :map should adjust with :scale and :rotation
2024-03-07 7:55 0% ` Eli Zaretskii
@ 2024-03-07 8:08 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-07 9:27 0% ` Eli Zaretskii
0 siblings, 1 reply; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-03-07 8:08 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 69602, stephen.berman, juri
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Joseph Turner <joseph@breatheoutbreathe.in>
>> Cc: 69602@debbugs.gnu.org, stephen.berman@gmx.net, juri@linkov.net
>> Date: Wed, 06 Mar 2024 23:14:21 -0800
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>> > The ELisp manual says about :map:
>> >
>> > Note that the map's coordinates should reflect the displayed image
>> > after all transforms have been done (rotation, scaling and so on),
>> > and also note that Emacs (by default) performs auto-scaling of
>> > images, so to make things match up, you should either specify
>> > ‘:scale 1.0’ when creating the image, or use the result of
>> > ‘image-compute-scaling-factor’ to compute the elements of the map.
>> >
>> > Can this technique help?
>>
>> Thank you for your help!
>>
>> When the user runs `image-increase-size', where should third-party code
>> recompute :map to fit the new image scale?
>>
>> There's no `image-after-change-size-hook' nor `image-after-rotate-hook'.
>
> I think the idea is to define the value of :map such that it runs
> image-compute-scaling-factor as part of computing the coordinates of
> the map.
Sorry, I don't understand.
When creating an image, we set its :map property according to the return
value of `image-compute-scaling-factor'. Once the image is inserted into
the buffer, the user may run `image-increase-size' or `image-rotate',
which changes how the image is displayed but not its :map.
Now, we need to rerun `image-compute-scaling-factor' and recompute :map.
However, there is no hook which runs after the user runs those commands,
so AFAICT there's no way for our code to know when to recompute :map.
Thanks!
Joseph
^ permalink raw reply [relevance 5%]
* bug#69602: 29.1; Image :map should adjust with :scale and :rotation
2024-03-07 8:08 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-03-07 9:27 0% ` Eli Zaretskii
2024-03-07 13:53 7% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 200+ results
From: Eli Zaretskii @ 2024-03-07 9:27 UTC (permalink / raw)
To: Joseph Turner; +Cc: 69602, stephen.berman, juri
> From: Joseph Turner <joseph@breatheoutbreathe.in>
> Cc: 69602@debbugs.gnu.org, stephen.berman@gmx.net, juri@linkov.net
> Date: Thu, 07 Mar 2024 00:08:57 -0800
>
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> > Note that the map's coordinates should reflect the displayed image
> >> > after all transforms have been done (rotation, scaling and so on),
> >> > and also note that Emacs (by default) performs auto-scaling of
> >> > images, so to make things match up, you should either specify
> >> > ‘:scale 1.0’ when creating the image, or use the result of
> >> > ‘image-compute-scaling-factor’ to compute the elements of the map.
> >> >
> >> > Can this technique help?
> >>
> >> Thank you for your help!
> >>
> >> When the user runs `image-increase-size', where should third-party code
> >> recompute :map to fit the new image scale?
> >>
> >> There's no `image-after-change-size-hook' nor `image-after-rotate-hook'.
> >
> > I think the idea is to define the value of :map such that it runs
> > image-compute-scaling-factor as part of computing the coordinates of
> > the map.
>
> Sorry, I don't understand.
I hoped :map allows its value to be a form that is evaluated when the
image is being processed, in which case that form could call
image-compute-scaling-factor when it produces the coordinates.
If that doesn't work, then...
> When creating an image, we set its :map property according to the return
> value of `image-compute-scaling-factor'. Once the image is inserted into
> the buffer, the user may run `image-increase-size' or `image-rotate',
> which changes how the image is displayed but not its :map.
>
> Now, we need to rerun `image-compute-scaling-factor' and recompute :map.
> However, there is no hook which runs after the user runs those commands,
> so AFAICT there's no way for our code to know when to recompute :map.
...AFAIU, when an image is rescaled, we call
image-transform-properties to produce the updated image properties.
So I guess you'd like that function to recompute the coordinates in
:map according to the transform?
IOW, I don't understand why you think the problem can only be solved
in C: AFAIK almost all of the machinery that performs image transforms
is implemented in Lisp, and each time an image is rescaled, we
basically re-process the image descriptor anew.
^ permalink raw reply [relevance 0%]
* bug#69602: 29.1; Image :map should adjust with :scale and :rotation
2024-03-07 9:27 0% ` Eli Zaretskii
@ 2024-03-07 13:53 7% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-08 7:02 9% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-08 7:24 0% ` Eli Zaretskii
0 siblings, 2 replies; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-03-07 13:53 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 69602, stephen.berman, juri
[-- Attachment #1: Type: text/plain, Size: 5474 bytes --]
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Joseph Turner <joseph@breatheoutbreathe.in>
>> Cc: 69602@debbugs.gnu.org, stephen.berman@gmx.net, juri@linkov.net
>> Date: Thu, 07 Mar 2024 00:08:57 -0800
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
> I hoped :map allows its value to be a form that is evaluated when the
> image is being processed, in which case that form could call
> image-compute-scaling-factor when it produces the coordinates.
Thanks! Would this require a change in C?
> If that doesn't work, then...
>
>> When creating an image, we set its :map property according to the return
>> value of `image-compute-scaling-factor'. Once the image is inserted into
>> the buffer, the user may run `image-increase-size' or `image-rotate',
>> which changes how the image is displayed but not its :map.
>>
>> Now, we need to rerun `image-compute-scaling-factor' and recompute :map.
What I said here is wrong. `image-compute-scaling-factor' is not
useful for recomputing :map, but `image--current-scaling' is.
>> However, there is no hook which runs after the user runs those commands,
>> so AFAICT there's no way for our code to know when to recompute :map.
>
> ...AFAIU, when an image is rescaled, we call
> image-transform-properties to produce the updated image properties.
There are two ways to rescale an image, `image-transform-properties'
(defined in image-mode.el; works only on file-backed images in
image-mode) and `image--change-size' (defined in image.el; works
on any image object in any mode).
For now, I'd like to focus on improving `image.el'.
> So I guess you'd like that function to recompute the coordinates in
> :map according to the transform?
>
> IOW, I don't understand why you think the problem can only be solved
> in C: AFAIK almost all of the machinery that performs image transforms
> is implemented in Lisp, and each time an image is rescaled, we
> basically re-process the image descriptor anew.
The attached patch adds two hooks in `image.el' which allow packages to
recompute an image's map after it's rescaled or rotated.
The following demonstrates `image-after-change-size-hooks':
(progn
(defun image--scale-map (map factor)
"Scale MAP by FACTOR, destructively modifying it."
(when (and factor (/= 1 factor))
(pcase-dolist (`(,`(,type . ,coords) ,_id ,_plist) map)
(pcase-exhaustive type
('rect
(setf (caar coords) (round (* (caar coords) factor)))
(setf (cdar coords) (round (* (cdar coords) factor)))
(setf (cadr coords) (round (* (cadr coords) factor)))
(setf (cddr coords) (round (* (cddr coords) factor))))
('circle
(setf (caar coords) (round (* (caar coords) factor)))
(setf (cdar coords) (round (* (cdar coords) factor)))
(setf (cdr coords) (round (* (cdr coords) factor))))
('poly
(dotimes (i (length coords))
(aset coords i
(round (* (aref coords i) factor))))))))
map)
(defun image-rescale-image-map ()
"Recalculate and set :map property of image at point.
Assumes that image has an :unscaled-map property."
(when-let* ((image (image--get-imagemagick-and-warn))
(unscaled-image (image--image-without-parameters image))
(unscaled-map (image-property image :unscaled-map))
(scale (image--current-scaling image unscaled-image)))
(setf (image-property image :map)
(image--scale-map (copy-tree unscaled-map t) scale))))
(with-current-buffer (get-buffer-create "*image-properties-test*")
(let* ((svg-string "<?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"no\"?>\n<!DOCTYPE svg PUBLIC \"-//W3C//DTD SVG 1.1//EN\"\n \"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd\">\n<!-- Generated by graphviz version 2.43.0 (0)\n -->\n<!-- Title: orggraphview Pages: 1 -->\n<svg width=\"128pt\" height=\"128pt\"\n viewBox=\"0.00 0.00 127.59 127.59\" xmlns=\"http://www.w3.org/2000/svg\" xmlns:xlink=\"http://www.w3.org/1999/xlink\">\n<g id=\"graph0\" class=\"graph\" transform=\"scale(1 1) rotate(0) translate(4 123.59)\">\n<title>orggraphview</title>\n<polygon fill=\"white\" stroke=\"transparent\" points=\"-4,4 -4,-123.59 123.59,-123.59 123.59,4 -4,4\"/>\n<!-- a -->\n<g id=\"node1\" class=\"node\">\n<title>a</title>\n<g id=\"a_node1\"><a xlink:href=\"1\" xlink:title=\"Hover me!\">\n<ellipse fill=\"none\" stroke=\"black\" cx=\"59.79\" cy=\"-59.79\" rx=\"59.59\" ry=\"59.59\"/>\n<text text-anchor=\"middle\" x=\"59.79\" y=\"-56.09\" font-family=\"Times,serif\" font-size=\"14.00\" fill=\"#000000\">Hover me!</text>\n</a>\n</g>\n</g>\n</g>\n</svg>\n")
(scale 0.75) ; Adjust initial image scale
(unscaled-map '(((circle (85 . 85) . 80) "1" (help-echo "Surprise!"))))
(map (image--scale-map (copy-tree unscaled-map t) scale))
(image
(create-image svg-string 'svg t
:scale scale :map map :unscaled-map unscaled-map)))
(add-hook 'image-after-change-size-hooks #'image-rescale-image-map nil t)
(erase-buffer)
(insert-image image)
(goto-char (point-min))
(pop-to-buffer (current-buffer)))))
After applying the attached patch, evaluate the above form, press "i +"
and "i -" repeatedly to see the image and its map scale together.
Thanks!
Joseph
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Add-image-after-change-size-hooks-image-after-rotate.patch --]
[-- Type: text/x-diff, Size: 1876 bytes --]
From ace6449374eb92f820388c5d111daaa2dbd89835 Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Thu, 7 Mar 2024 15:24:49 -0800
Subject: [PATCH] Add image-after-change-size-hooks, image-after-rotate-hooks
With these hooks, image properties, notably :map, may now be
recalculated and set when an image is rotated or rescaled. See #69602.
* lisp/image.el (image-after-change-size-hooks): Add hooks variable.
(image--change-size): Run hooks at end of function.
(image-after-rotate-hooks): Add hooks variable.
(image-rotate): Run hooks at end of function.
---
lisp/image.el | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/lisp/image.el b/lisp/image.el
index d2f8868b60e..053fb436cd5 100644
--- a/lisp/image.el
+++ b/lisp/image.el
@@ -1286,7 +1286,11 @@ image--change-size
(new-image (image--image-without-parameters image))
(scale (image--current-scaling image new-image)))
(setcdr image (cdr new-image))
- (plist-put (cdr image) :scale (* scale factor))))
+ (plist-put (cdr image) :scale (* scale factor))
+ (run-hooks 'image-after-change-size-hooks)))
+
+(defvar image-after-change-size-hooks nil
+ "Hooks run after image is rescaled.")
(advice-add #'image--change-size :after #'image--change-size-scale-map)
@@ -1355,9 +1359,13 @@ image-rotate
;; We don't want to exceed 360 degrees rotation,
;; because it's not seen as valid in Exif data.
360))))
+ (run-hooks 'image-after-rotate-hooks)
(set-transient-map image--repeat-map nil nil
"Use %k for further adjustments"))
+(defvar image-after-rotate-hooks nil
+ "Hooks run after image is rotated.")
+
(defun image-save ()
"Save the image under point.
This writes the original image data to a file. Rotating or
--
2.41.0
^ permalink raw reply related [relevance 7%]
* bug#69602: 29.1; Image :map should adjust with :scale and :rotation
2024-03-07 13:53 7% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-03-08 7:02 9% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-08 8:31 0% ` Eli Zaretskii
2024-03-08 7:24 0% ` Eli Zaretskii
1 sibling, 1 reply; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-03-08 7:02 UTC (permalink / raw)
To: Eli Zaretskii, 69602, stephen.berman, juri
[-- Attachment #1: Type: text/plain, Size: 1967 bytes --]
Joseph Turner <joseph@breatheoutbreathe.in> writes:
> The attached patch adds two hooks in `image.el' which allow packages to
> recompute an image's map after it's rescaled or rotated.
In this new attached patch, rescaling image maps is handled within
image.el. No new hooks are added. This change should be backwards
compatible, except that :unscaled-map is now a reserved image property.
If we decide to install this patch, I'll work on modifying image maps
inside of `image-rotate', as well as update the manual and NEWS.
Test it out!
(with-current-buffer (get-buffer-create "*image-properties-test*")
(let* ((svg-string "<?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"no\"?>\n<!DOCTYPE svg PUBLIC \"-//W3C//DTD SVG 1.1//EN\"\n \"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd\">\n<!-- Generated by graphviz version 2.43.0 (0)\n -->\n<!-- Title: orggraphview Pages: 1 -->\n<svg width=\"128pt\" height=\"128pt\"\n viewBox=\"0.00 0.00 127.59 127.59\" xmlns=\"http://www.w3.org/2000/svg\" xmlns:xlink=\"http://www.w3.org/1999/xlink\">\n<g id=\"graph0\" class=\"graph\" transform=\"scale(1 1) rotate(0) translate(4 123.59)\">\n<title>orggraphview</title>\n<polygon fill=\"white\" stroke=\"transparent\" points=\"-4,4 -4,-123.59 123.59,-123.59 123.59,4 -4,4\"/>\n<!-- a -->\n<g id=\"node1\" class=\"node\">\n<title>a</title>\n<g id=\"a_node1\"><a xlink:href=\"1\" xlink:title=\"Hover me!\">\n<ellipse fill=\"none\" stroke=\"black\" cx=\"59.79\" cy=\"-59.79\" rx=\"59.59\" ry=\"59.59\"/>\n<text text-anchor=\"middle\" x=\"59.79\" y=\"-56.09\" font-family=\"Times,serif\" font-size=\"14.00\" fill=\"#000000\">Hover me!</text>\n</a>\n</g>\n</g>\n</g>\n</svg>\n")
(map '(((circle (85 . 85) . 80) "1" (help-echo "Surprise!"))))
(image (create-image svg-string 'svg t :map map)))
(erase-buffer)
(insert-image image)
(goto-char (point-min))
(pop-to-buffer (current-buffer))))
Thank you!
Joseph
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Recalculate-map-when-image-scale-changes.patch --]
[-- Type: text/x-diff, Size: 3937 bytes --]
From 7a3d9fa5cc08c40696ad65101d62cb4babb4dc76 Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Thu, 7 Mar 2024 21:55:00 -0800
Subject: [PATCH] Recalculate :map when image :scale changes
Now, when rescaling an image with a :map using `image-increase-size' or
`image-decrease-size', the image map scales along with the image.
Image map coordinates are integers, so when scaling :map, coordinates
must be rounded. To prevent an image from drifting from its map after
repeatedly scaling up and down, `create-image' now stores the original
:unscaled-map, which is combined with the image's scale after resizing
to recalculate :map.
* lisp/image.el (create-image): Add :unscaled-map image property
(image--delayed-change-size): Fix comment
(image--change-size): Also scale image map
(image--scale-map): Add function to scale an image map
---
lisp/image.el | 38 +++++++++++++++++++++++++++++++++++---
1 file changed, 35 insertions(+), 3 deletions(-)
diff --git a/lisp/image.el b/lisp/image.el
index 2ebce59a98c..c72332172f0 100644
--- a/lisp/image.el
+++ b/lisp/image.el
@@ -533,6 +533,13 @@ create-image
('t t)
('nil nil)
(func (funcall func image)))))))
+ ;; Add unscaled map.
+ (when-let ((map (plist-get props :map)))
+ (setq image (nconc image
+ (list :unscaled-map
+ (image--scale-map
+ (copy-tree map t)
+ (/ 1.0 (image-property image :scale)))))))
image)))
(defun image--default-smoothing (image)
@@ -1185,7 +1192,7 @@ image-increase-size
(defun image--delayed-change-size (size position)
;; Wait for a bit of idle-time before actually performing the change,
;; so as to batch together sequences of closely consecutive size changes.
- ;; `image--change-size' just changes one value in a plist. The actual
+ ;; `image--change-size' just changes :scale and :map. The actual
;; image resizing happens later during redisplay. So if those
;; consecutive calls happen without any redisplay between them,
;; the costly operation of image resizing should happen only once.
@@ -1267,9 +1274,34 @@ image--get-imagemagick-and-warn
(defun image--change-size (factor &optional position)
(let* ((image (image--get-imagemagick-and-warn position))
(new-image (image--image-without-parameters image))
- (scale (image--current-scaling image new-image)))
+ (unscaled-map (image-property image :unscaled-map))
+ (scale (image--current-scaling image new-image))
+ (new-scale (* scale factor)))
(setcdr image (cdr new-image))
- (plist-put (cdr image) :scale (* scale factor))))
+ (plist-put (cdr image) :scale new-scale)
+ (when unscaled-map
+ (setf (image-property image :map)
+ (image--scale-map (copy-tree unscaled-map t) new-scale)))))
+
+(defun image--scale-map (map factor)
+ "Scale MAP by FACTOR, destructively modifying it."
+ (unless (= 1 factor)
+ (pcase-dolist (`(,`(,type . ,coords) ,_id ,_plist) map)
+ (pcase-exhaustive type
+ ('rect
+ (setf (caar coords) (round (* (caar coords) factor)))
+ (setf (cdar coords) (round (* (cdar coords) factor)))
+ (setf (cadr coords) (round (* (cadr coords) factor)))
+ (setf (cddr coords) (round (* (cddr coords) factor))))
+ ('circle
+ (setf (caar coords) (round (* (caar coords) factor)))
+ (setf (cdar coords) (round (* (cdar coords) factor)))
+ (setf (cdr coords) (round (* (cdr coords) factor))))
+ ('poly
+ (dotimes (i (length coords))
+ (aset coords i
+ (round (* (aref coords i) factor))))))))
+ map)
(defun image--image-without-parameters (image)
(cons (pop image)
--
2.41.0
^ permalink raw reply related [relevance 9%]
* bug#69602: 29.1; Image :map should adjust with :scale and :rotation
2024-03-07 13:53 7% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-08 7:02 9% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-03-08 7:24 0% ` Eli Zaretskii
1 sibling, 0 replies; 200+ results
From: Eli Zaretskii @ 2024-03-08 7:24 UTC (permalink / raw)
To: Joseph Turner; +Cc: 69602, stephen.berman, juri
> From: Joseph Turner <joseph@breatheoutbreathe.in>
> Cc: 69602@debbugs.gnu.org, stephen.berman@gmx.net, juri@linkov.net
> Date: Thu, 07 Mar 2024 05:53:11 -0800
>
> > IOW, I don't understand why you think the problem can only be solved
> > in C: AFAIK almost all of the machinery that performs image transforms
> > is implemented in Lisp, and each time an image is rescaled, we
> > basically re-process the image descriptor anew.
>
> The attached patch adds two hooks in `image.el' which allow packages to
> recompute an image's map after it's rescaled or rotated.
Thanks, but please accompany the code change with suitable changes for
NEWS and the ELisp manual. Bonus points for adding tests for this to
our test suite.
Also, I think we don't need the "after" part in the names of these two
hooks: their doc strings explicitly document that they are run after
the transformation, and image-change-size-hook is easier to remember,
since the name basically says "a hook run when image is resized".
And finally, please mention the hooks in the doc strings of public
functions that perform size-changes and rotations of images, as we
usually do with other hooks.
^ permalink raw reply [relevance 0%]
* bug#69602: 29.1; Image :map should adjust with :scale and :rotation
2024-03-08 7:02 9% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-03-08 8:31 0% ` Eli Zaretskii
2024-03-08 8:39 9% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 200+ results
From: Eli Zaretskii @ 2024-03-08 8:31 UTC (permalink / raw)
To: Joseph Turner; +Cc: 69602, stephen.berman, juri
> From: Joseph Turner <joseph@breatheoutbreathe.in>
> Date: Thu, 07 Mar 2024 23:02:24 -0800
>
> Joseph Turner <joseph@breatheoutbreathe.in> writes:
>
> > The attached patch adds two hooks in `image.el' which allow packages to
> > recompute an image's map after it's rescaled or rotated.
>
> In this new attached patch, rescaling image maps is handled within
> image.el. No new hooks are added. This change should be backwards
> compatible, except that :unscaled-map is now a reserved image property.
Are we sure no Lisp program out there would want the coordinates in
:map to remain unchanged under these transformation? Maybe we should
add a variable to control this, so that the change could be truly
backward-compatible?
> If we decide to install this patch, I'll work on modifying image maps
> inside of `image-rotate', as well as update the manual and NEWS.
Thanks.
^ permalink raw reply [relevance 0%]
* bug#69602: 29.1; Image :map should adjust with :scale and :rotation
2024-03-08 8:31 0% ` Eli Zaretskii
@ 2024-03-08 8:39 9% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-08 11:50 0% ` Eli Zaretskii
0 siblings, 1 reply; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-03-08 8:39 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 69602, stephen.berman, juri
[-- Attachment #1: Type: text/plain, Size: 1078 bytes --]
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Joseph Turner <joseph@breatheoutbreathe.in>
>> Date: Thu, 07 Mar 2024 23:02:24 -0800
>>
>> Joseph Turner <joseph@breatheoutbreathe.in> writes:
>>
>> > The attached patch adds two hooks in `image.el' which allow packages to
>> > recompute an image's map after it's rescaled or rotated.
>>
>> In this new attached patch, rescaling image maps is handled within
>> image.el. No new hooks are added. This change should be backwards
>> compatible, except that :unscaled-map is now a reserved image property.
>
> Are we sure no Lisp program out there would want the coordinates in
> :map to remain unchanged under these transformation? Maybe we should
> add a variable to control this, so that the change could be truly
> backward-compatible?
Good point. Thanks!
What if explicitly passing :unscaled-map 'no-recalculate in
`create-image' prevented :map from being recalculated later?
If not, what kind of variable did you have in mind? A special variable
let-bound the call? Or another argument to `create-image'?
See patches.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0002-Allow-map-to-not-be-recalculated-after-image-rescali.patch --]
[-- Type: text/x-diff, Size: 1472 bytes --]
From feafa5a4e967254fc58c2ad223cd7033d4c4be02 Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Fri, 8 Mar 2024 00:53:44 -0800
Subject: [PATCH 2/2] Allow :map to not be recalculated after image rescaling
* lisp/image.el (create-image): Don't append :unscaled-map if passed in.
(image--image-without-parameters): Don't rescale :map when :unscaled-map
is 'no-recalculate.
---
lisp/image.el | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/lisp/image.el b/lisp/image.el
index c72332172f0..b7de9817009 100644
--- a/lisp/image.el
+++ b/lisp/image.el
@@ -534,7 +534,8 @@ create-image
('nil nil)
(func (funcall func image)))))))
;; Add unscaled map.
- (when-let ((map (plist-get props :map)))
+ (when-let ((map (plist-get props :map))
+ ((not (plist-member props :unscaled-map))))
(setq image (nconc image
(list :unscaled-map
(image--scale-map
@@ -1279,7 +1280,8 @@ image--change-size
(new-scale (* scale factor)))
(setcdr image (cdr new-image))
(plist-put (cdr image) :scale new-scale)
- (when unscaled-map
+ (when (and unscaled-map
+ (not (eq 'no-recalculate unscaled-map)))
(setf (image-property image :map)
(image--scale-map (copy-tree unscaled-map t) new-scale)))))
--
2.41.0
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0001-Recalculate-map-when-image-scale-changes.patch --]
[-- Type: text/x-diff, Size: 3941 bytes --]
From 7a3d9fa5cc08c40696ad65101d62cb4babb4dc76 Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Thu, 7 Mar 2024 21:55:00 -0800
Subject: [PATCH 1/2] Recalculate :map when image :scale changes
Now, when rescaling an image with a :map using `image-increase-size' or
`image-decrease-size', the image map scales along with the image.
Image map coordinates are integers, so when scaling :map, coordinates
must be rounded. To prevent an image from drifting from its map after
repeatedly scaling up and down, `create-image' now stores the original
:unscaled-map, which is combined with the image's scale after resizing
to recalculate :map.
* lisp/image.el (create-image): Add :unscaled-map image property
(image--delayed-change-size): Fix comment
(image--change-size): Also scale image map
(image--scale-map): Add function to scale an image map
---
lisp/image.el | 38 +++++++++++++++++++++++++++++++++++---
1 file changed, 35 insertions(+), 3 deletions(-)
diff --git a/lisp/image.el b/lisp/image.el
index 2ebce59a98c..c72332172f0 100644
--- a/lisp/image.el
+++ b/lisp/image.el
@@ -533,6 +533,13 @@ create-image
('t t)
('nil nil)
(func (funcall func image)))))))
+ ;; Add unscaled map.
+ (when-let ((map (plist-get props :map)))
+ (setq image (nconc image
+ (list :unscaled-map
+ (image--scale-map
+ (copy-tree map t)
+ (/ 1.0 (image-property image :scale)))))))
image)))
(defun image--default-smoothing (image)
@@ -1185,7 +1192,7 @@ image-increase-size
(defun image--delayed-change-size (size position)
;; Wait for a bit of idle-time before actually performing the change,
;; so as to batch together sequences of closely consecutive size changes.
- ;; `image--change-size' just changes one value in a plist. The actual
+ ;; `image--change-size' just changes :scale and :map. The actual
;; image resizing happens later during redisplay. So if those
;; consecutive calls happen without any redisplay between them,
;; the costly operation of image resizing should happen only once.
@@ -1267,9 +1274,34 @@ image--get-imagemagick-and-warn
(defun image--change-size (factor &optional position)
(let* ((image (image--get-imagemagick-and-warn position))
(new-image (image--image-without-parameters image))
- (scale (image--current-scaling image new-image)))
+ (unscaled-map (image-property image :unscaled-map))
+ (scale (image--current-scaling image new-image))
+ (new-scale (* scale factor)))
(setcdr image (cdr new-image))
- (plist-put (cdr image) :scale (* scale factor))))
+ (plist-put (cdr image) :scale new-scale)
+ (when unscaled-map
+ (setf (image-property image :map)
+ (image--scale-map (copy-tree unscaled-map t) new-scale)))))
+
+(defun image--scale-map (map factor)
+ "Scale MAP by FACTOR, destructively modifying it."
+ (unless (= 1 factor)
+ (pcase-dolist (`(,`(,type . ,coords) ,_id ,_plist) map)
+ (pcase-exhaustive type
+ ('rect
+ (setf (caar coords) (round (* (caar coords) factor)))
+ (setf (cdar coords) (round (* (cdar coords) factor)))
+ (setf (cadr coords) (round (* (cadr coords) factor)))
+ (setf (cddr coords) (round (* (cddr coords) factor))))
+ ('circle
+ (setf (caar coords) (round (* (caar coords) factor)))
+ (setf (cdar coords) (round (* (cdar coords) factor)))
+ (setf (cdr coords) (round (* (cdr coords) factor))))
+ ('poly
+ (dotimes (i (length coords))
+ (aset coords i
+ (round (* (aref coords i) factor))))))))
+ map)
(defun image--image-without-parameters (image)
(cons (pop image)
--
2.41.0
^ permalink raw reply related [relevance 9%]
* bug#69602: 29.1; Image :map should adjust with :scale and :rotation
2024-03-08 8:39 9% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-03-08 11:50 0% ` Eli Zaretskii
2024-03-21 6:45 3% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 200+ results
From: Eli Zaretskii @ 2024-03-08 11:50 UTC (permalink / raw)
To: Joseph Turner; +Cc: 69602, stephen.berman, juri
> From: Joseph Turner <joseph@breatheoutbreathe.in>
> Cc: 69602@debbugs.gnu.org, stephen.berman@gmx.net, juri@linkov.net
> Date: Fri, 08 Mar 2024 00:39:16 -0800
>
> > Are we sure no Lisp program out there would want the coordinates in
> > :map to remain unchanged under these transformation? Maybe we should
> > add a variable to control this, so that the change could be truly
> > backward-compatible?
>
> Good point. Thanks!
>
> What if explicitly passing :unscaled-map 'no-recalculate in
> `create-image' prevented :map from being recalculated later?
I think that's less desirable, since some images could be created
outside of control of a Lisp program that wants to control the
coordinates.
> If not, what kind of variable did you have in mind? A special variable
> let-bound the call? Or another argument to `create-image'?
I had in mind a special variable (we'd need to mention it in NEWS and
in the doc string of the relevant functions). Adding an argument is a
heavier change, and I think it is not justified in this case, because
I do agree with you that most, if not all, applications would want the
coordinates to scale together with the image.
Thanks.
^ permalink raw reply [relevance 0%]
* bug#69602: 29.1; Image :map should adjust with :scale and :rotation
2024-03-08 11:50 0% ` Eli Zaretskii
@ 2024-03-21 6:45 3% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-21 11:59 0% ` Eli Zaretskii
0 siblings, 1 reply; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-03-21 6:45 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 69602, stephen.berman, juri
[-- Attachment #1: Type: text/plain, Size: 1319 bytes --]
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Joseph Turner <joseph@breatheoutbreathe.in>
>> Cc: 69602@debbugs.gnu.org, stephen.berman@gmx.net, juri@linkov.net
>> Date: Fri, 08 Mar 2024 00:39:16 -0800
>>
>> > Are we sure no Lisp program out there would want the coordinates in
>> > :map to remain unchanged under these transformation? Maybe we should
>> > add a variable to control this, so that the change could be truly
>> > backward-compatible?
>>
>> Good point. Thanks!
>>
>> What if explicitly passing :unscaled-map 'no-recalculate in
>> `create-image' prevented :map from being recalculated later?
>
> I think that's less desirable, since some images could be created
> outside of control of a Lisp program that wants to control the
> coordinates.
>
>> If not, what kind of variable did you have in mind? A special variable
>> let-bound the call? Or another argument to `create-image'?
>
> I had in mind a special variable (we'd need to mention it in NEWS and
> in the doc string of the relevant functions). Adding an argument is a
> heavier change, and I think it is not justified in this case, because
> I do agree with you that most, if not all, applications would want the
> coordinates to scale together with the image.
Thanks for your feedback and your patience!
Please see attached patch.
Joseph
[-- Attachment #2: 0001-Recompute-map-when-image-scale-rotation-or-flip-chan.patch --]
[-- Type: text/x-diff, Size: 26184 bytes --]
From 7b454df8f7335751c96c946ca09711b16c1de193 Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Thu, 7 Mar 2024 21:55:00 -0800
Subject: [PATCH] Recompute :map when image :scale, :rotation, or :flip changes
Now, when transforming an image, its :map is recomputed to fit.
Image map coordinates are integers, so when computing :map, coordinates
are rounded. To prevent an image from drifting from its map after
repeated transformations, `create-image' now adds a new image property
:original-map, which is combined with the image's transformation
parameters to recompute :map.
* lisp/image.el (image-recompute-map-p): Add user option to control
whether :map is recomputed when an image is transformed.
(create-image): Create :map from :original-map and vice versa.
(image--delayed-change-size): Fix comment.
(image--change-size, image-rotate, image-flip-horizontally,
image-flip-vertically): Recompute image map after transformation and
mention image-recompute-map-p in docstring.
(image--compute-map): Add function to compute a map from original map.
(image--compute-map): Add function to compute an original map from map.
(image--scale-map): Add function to scale a map based on :scale.
(image--rotate-map): Add function to rotate a map based on :rotation.
(image--rotate-coord): Add function to rotate a map coordinate pair.
(image--flip-map): Add function to flip a map based on :flip.
(image-increase-size, image-decrease-size, image-mouse-increase-size,
image-mouse-decrease-size): Mention image-recompute-map-p in docstring.
* etc/NEWS: Add NEWS entry.
* doc/lispref/display.texi (Image Descriptors): Document :original-map
and new user option image-recompute-map-p.
* test/lisp/image-tests.el (image--compute-map-and-original-map): Test
`image--compute-map' and `image--compute-original-map'.
(image-create-image-with-map): Test that `create-image' adds :map and/or
:original-map as appropriate.
(image-transform-map): Test functions related to transforming maps.
---
doc/lispref/display.texi | 24 +++++
etc/NEWS | 12 +++
lisp/image.el | 221 ++++++++++++++++++++++++++++++++++++---
test/lisp/image-tests.el | 111 ++++++++++++++++++++
4 files changed, 356 insertions(+), 12 deletions(-)
diff --git a/doc/lispref/display.texi b/doc/lispref/display.texi
index 10cf5ce89e2..8335a02b5c5 100644
--- a/doc/lispref/display.texi
+++ b/doc/lispref/display.texi
@@ -6055,6 +6055,30 @@ Image Descriptors
when creating the image, or use the result of
@code{image-compute-scaling-factor} to compute the elements of the
map.
+
+When an image's @code{:scale}, @code{:rotation}, or @code{:flip} is
+changed, @code{:map} will be recomputed based on the value of
+@code{:original-map} and the values of those transformation.
+
+@item :original-map @var{original-map}
+@cindex original image map
+This specifies the untransformed image map which will be used to
+recompute @code{:map} after the image's @code{:scale}, @code{:rotation},
+or @code{:flip} is changed.
+
+If @code{:original-map} is not specified when creating an image with
+@code{create-image}, it will be computed based on the supplied
+@code{:map}, as well as any of @code{:scale}, @code{:rotation}, or
+@code{:flip} which are non-nil.
+
+Conversely, if @code{:original-map} is specified but @code{:map} is not,
+@code{:map} will be computed based on @code{:original-map},
+@code{:scale}, @code{:rotation}, and @code{:flip}.
+
+@defopt image-recompute-map-p
+Set this user option to nil to prevent Emacs from automatically
+recomputing an image @code{:map} based on its @code{:original-map}.
+@end defopt
@end table
@defun image-mask-p spec &optional frame
diff --git a/etc/NEWS b/etc/NEWS
index 06856602ea8..cbd97b495b2 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -1292,6 +1292,18 @@ without specifying a file, like this:
(notifications-notify
:title "I am playing music" :app-icon 'multimedia-player)
+** Image
+
++++
+*** Image :map property is now recomputed when image is transformed.
+Now images with clickable maps work as expected after you run commands
+such as `image-increase-size', `image-decrease-size', `image-rotate',
+`image-flip-horizontally', and `image-flip-vertically'.
+
++++
+*** New user option 'image-recompute-map-p'
+Set this option to nil to prevent Emacs from recomputing image maps.
+
** Image Dired
*** New user option 'image-dired-thumb-naming'.
diff --git a/lisp/image.el b/lisp/image.el
index 2ebce59a98c..ed94b9eb621 100644
--- a/lisp/image.el
+++ b/lisp/image.el
@@ -533,6 +533,16 @@ create-image
('t t)
('nil nil)
(func (funcall func image)))))))
+ ;; Add original map from map.
+ (when (and (plist-get props :map)
+ (not (plist-get props :original-map)))
+ (setq image (nconc image (list :original-map
+ (image--compute-original-map image)))))
+ ;; Add map from original map.
+ (when (and (plist-get props :original-map)
+ (not (plist-get props :map)))
+ (setq image (nconc image (list :map
+ (image--compute-map image)))))
image)))
(defun image--default-smoothing (image)
@@ -1173,7 +1183,10 @@ image-increase-size
If N is 3, then the image size will be increased by 30%. More
generally, the image size is multiplied by 1 plus N divided by 10.
N defaults to 2, which increases the image size by 20%.
-POSITION can be a buffer position or a marker, and defaults to point."
+POSITION can be a buffer position or a marker, and defaults to point.
+
+When user option `image-recompute-map-p' is non-nil, the image's `:map'
+is recomputed to fit the newly transformed image."
(interactive "P")
(image--delayed-change-size (if n
(1+ (/ (prefix-numeric-value n) 10.0))
@@ -1185,7 +1198,7 @@ image-increase-size
(defun image--delayed-change-size (size position)
;; Wait for a bit of idle-time before actually performing the change,
;; so as to batch together sequences of closely consecutive size changes.
- ;; `image--change-size' just changes one value in a plist. The actual
+ ;; `image--change-size' just changes two values in a plist. The actual
;; image resizing happens later during redisplay. So if those
;; consecutive calls happen without any redisplay between them,
;; the costly operation of image resizing should happen only once.
@@ -1196,7 +1209,10 @@ image-decrease-size
If N is 3, then the image size will be decreased by 30%. More
generally, the image size is multiplied by 1 minus N divided by 10.
N defaults to 2, which decreases the image size by 20%.
-POSITION can be a buffer position or a marker, and defaults to point."
+POSITION can be a buffer position or a marker, and defaults to point.
+
+When user option `image-recompute-map-p' is non-nil, the image's `:map'
+is recomputed to fit the newly transformed image."
(interactive "P")
(image--delayed-change-size (if n
(- 1 (/ (prefix-numeric-value n) 10.0))
@@ -1208,7 +1224,10 @@ image-decrease-size
(defun image-mouse-increase-size (&optional event)
"Increase the image size using the mouse-gesture EVENT.
This increases the size of the image at the position specified by
-EVENT, if any, by the default factor used by `image-increase-size'."
+EVENT, if any, by the default factor used by `image-increase-size'.
+
+When user option `image-recompute-map-p' is non-nil, the image's `:map'
+is recomputed to fit the newly transformed image."
(interactive "e")
(when (listp event)
(save-window-excursion
@@ -1218,7 +1237,10 @@ image-mouse-increase-size
(defun image-mouse-decrease-size (&optional event)
"Decrease the image size using the mouse-gesture EVENT.
This decreases the size of the image at the position specified by
-EVENT, if any, by the default factor used by `image-decrease-size'."
+EVENT, if any, by the default factor used by `image-decrease-size'.
+
+When user option `image-recompute-map-p' is non-nil, the image's `:map'
+is recomputed to fit the newly transformed image."
(interactive "e")
(when (listp event)
(save-window-excursion
@@ -1269,7 +1291,9 @@ image--change-size
(new-image (image--image-without-parameters image))
(scale (image--current-scaling image new-image)))
(setcdr image (cdr new-image))
- (plist-put (cdr image) :scale (* scale factor))))
+ (plist-put (cdr image) :scale (* scale factor))
+ (when (and (image-property image :original-map) image-recompute-map-p)
+ (setf (image-property image :map) (image--compute-map image)))))
(defun image--image-without-parameters (image)
(cons (pop image)
@@ -1296,7 +1320,10 @@ image-rotate
If nil, ANGLE defaults to 90. Interactively, rotate the image 90
degrees clockwise with no prefix argument, and counter-clockwise
with a prefix argument. Note that most image types support
-rotations by only multiples of 90 degrees."
+rotations by only multiples of 90 degrees.
+
+When user option `image-recompute-map-p' is non-nil, the image's `:map'
+is recomputed to fit the newly transformed image."
(interactive (and current-prefix-arg '(-90)))
(let ((image (image--get-imagemagick-and-warn)))
(setf (image-property image :rotation)
@@ -1304,7 +1331,9 @@ image-rotate
(or angle 90))
;; We don't want to exceed 360 degrees rotation,
;; because it's not seen as valid in Exif data.
- 360))))
+ 360)))
+ (when (and (image-property image :original-map) image-recompute-map-p)
+ (setf (image-property image :map) (image--compute-map image))))
(set-transient-map image--repeat-map nil nil
"Use %k for further adjustments"))
@@ -1325,23 +1354,191 @@ image-save
(read-file-name "Write image to file: ")))))
(defun image-flip-horizontally ()
- "Horizontally flip the image under point."
+ "Horizontally flip the image under point.
+
+When user option `image-recompute-map-p' is non-nil, the image's `:map'
+is recomputed to fit the newly transformed image."
(interactive)
(let ((image (image--get-image)))
(image-flush image)
(setf (image-property image :flip)
- (not (image-property image :flip)))))
+ (not (image-property image :flip)))
+ (when (and (image-property image :original-map) image-recompute-map-p)
+ (setf (image-property image :map) (image--compute-map image)))))
(defun image-flip-vertically ()
- "Vertically flip the image under point."
+ "Vertically flip the image under point.
+
+When user option `image-recompute-map-p' is non-nil, the image's `:map'
+is recomputed to fit the newly transformed image."
(interactive)
(let ((image (image--get-image)))
(image-rotate 180)
(setf (image-property image :flip)
- (not (image-property image :flip)))))
+ (not (image-property image :flip)))
+ (when (and (image-property image :original-map) image-recompute-map-p)
+ (setf (image-property image :map) (image--compute-map image)))))
(define-obsolete-function-alias 'image-refresh #'image-flush "29.1")
+;;; Map transformation
+
+(defcustom image-recompute-map-p t
+ "Recompute image map when scaling, rotating, or flipping an image."
+ :type 'boolean
+ :version "30.1")
+
+(defun image--compute-map (image)
+ "Compute map for IMAGE suitable to be used as its :map property.
+Return a copy of :original-image transformed based on IMAGE's :scale,
+:rotation, and :flip. When IMAGE's :original-map is nil, return nil.
+When :rotation is not a multiple of 90, return copy of :original-map."
+ (pcase-let* ((original-map (image-property image :original-map))
+ (map (copy-tree original-map t))
+ (scale (or (image-property image :scale) 1))
+ (rotation (or (image-property image :rotation) 0))
+ (flip (image-property image :flip))
+ ((and size `(,width . ,height)) (image-size image t)))
+ (when (and ; Handle only 90-degree rotations
+ (zerop (mod rotation 1))
+ (zerop (% (truncate rotation) 90)))
+ ;; SIZE fits MAP after transformations. Scale MAP before
+ ;; flip and rotate operations, since both need MAP to fit SIZE.
+ (image--scale-map map scale)
+ ;; In rendered images, rotation is always applied before flip.
+ (image--rotate-map
+ map rotation (if (or (= 90 rotation) (= 270 rotation))
+ ;; If rotated ±90°, swap width and height.
+ (cons height width)
+ size))
+ ;; After rotation, there's no need to swap width and height.
+ (image--flip-map map flip size))
+ map))
+
+(defun image--compute-original-map (image)
+ "Return original map for IMAGE.
+If IMAGE lacks :map property, return nil.
+When :rotation is not a multiple of 90, return copy of :map."
+ (when (image-property image :map)
+ (let* ((image-copy (copy-tree image t))
+ (map (image-property image-copy :map))
+ (scale (or (image-property image-copy :scale) 1))
+ (rotation (or (image-property image-copy :rotation) 0))
+ (flip (image-property image-copy :flip))
+ (size (image-size image-copy t)))
+ (when (and ; Handle only 90-degree rotations
+ (zerop (mod rotation 1))
+ (zerop (% (truncate rotation) 90)))
+ ;; In rendered images, rotation is always applied before flip.
+ ;; To undo the transformation, flip before rotating.
+ ;; SIZE fits MAP before it is transformed back to ORIGINAL-MAP.
+ ;; Therefore, scale MAP after flip and rotate operations, since
+ ;; both need MAP to fit SIZE.
+ (image--flip-map map flip size)
+ (image--rotate-map map (- rotation) size)
+ (image--scale-map map (/ 1.0 scale)))
+ map)))
+
+(defun image--scale-map (map scale)
+ "Scale MAP according to SCALE.
+Destructively modifies and returns MAP."
+ (unless (= 1 scale)
+ (pcase-dolist (`(,`(,type . ,coords) ,_id ,_plist) map)
+ (pcase-exhaustive type
+ ('rect
+ (setf (caar coords) (round (* (caar coords) scale)))
+ (setf (cdar coords) (round (* (cdar coords) scale)))
+ (setf (cadr coords) (round (* (cadr coords) scale)))
+ (setf (cddr coords) (round (* (cddr coords) scale))))
+ ('circle
+ (setf (caar coords) (round (* (caar coords) scale)))
+ (setf (cdar coords) (round (* (cdar coords) scale)))
+ (setcdr coords (round (* (cdr coords) scale))))
+ ('poly
+ (dotimes (i (length coords))
+ (aset coords i
+ (round (* (aref coords i) scale))))))))
+ map)
+
+(defun image--rotate-map (map rotation size)
+ "Rotate MAP according to ROTATION and SIZE.
+Destructively modifies and returns MAP."
+ (unless (zerop rotation)
+ (pcase-dolist (`(,`(,type . ,coords) ,_id ,_plist) map)
+ (pcase-exhaustive type
+ ('rect
+ (let ( x0 y0 ; New upper left corner
+ x1 y1) ; New bottom right corner
+ (pcase (truncate (mod rotation 360)) ; Set new corners to...
+ (90 ; ...old bottom left and upper right
+ (setq x0 (caar coords) y0 (cddr coords)
+ x1 (cadr coords) y1 (cdar coords)))
+ (180 ; ...old bottom right and upper left
+ (setq x0 (cadr coords) y0 (cddr coords)
+ x1 (caar coords) y1 (cdar coords)))
+ (270 ; ...old upper right and bottom left
+ (setq x0 (cadr coords) y0 (cdar coords)
+ x1 (caar coords) y1 (cddr coords))))
+ (setcar coords (image--rotate-coord x0 y0 rotation size))
+ (setcdr coords (image--rotate-coord x1 y1 rotation size))))
+ ('circle
+ (setcar coords (image--rotate-coord
+ (caar coords) (cdar coords) rotation size)))
+ ('poly
+ (dotimes (i (length coords))
+ (when (= 0 (% i 2))
+ (pcase-let ((`(,x . ,y)
+ (image--rotate-coord
+ (aref coords i) (aref coords (1+ i)) rotation size)))
+ (aset coords i x)
+ (aset coords (1+ i) y))))))))
+ map)
+
+(defun image--rotate-coord (x y angle size)
+ "Rotate coordinates X and Y by ANGLE in image of SIZE.
+ANGLE must be a multiple of 90. Returns a cons cell of rounded
+coordinates (X1 Y1)."
+ (pcase-let* ((radian (thread-first angle (* float-pi) (/ 180.0)))
+ (`(,width . ,height) size)
+ ;; y is positive, but we are in the bottom-right quadrant
+ (y (- y))
+ ;; Rotate clockwise
+ (x1 (+ (* (sin radian) y) (* (cos radian) x)))
+ (y1 (- (* (cos radian) y) (* (sin radian) x)))
+ ;; Translate image back into bottom-right quadrant
+ (`(,x1 . ,y1)
+ (pcase (truncate (mod angle 360))
+ (90 ; Translate right by height
+ (cons (+ x1 height) y1))
+ (180 ; Translate right by width and down by height
+ (cons (+ x1 width) (- y1 height)))
+ (270 ; Translate down by width
+ (cons x1 (- y1 width)))))
+ ;; Invert y1 to make both x1 and y1 positive
+ (y1 (- y1)))
+ (cons (round x1) (round y1))))
+
+(defun image--flip-map (map flip size)
+ "Horizontally flip MAP according to FLIP and SIZE.
+Destructively modifies and returns MAP."
+ (when flip
+ (pcase-dolist (`(,`(,type . ,coords) ,_id ,_plist) map)
+ (pcase-exhaustive type
+ ('rect
+ (let ((x0 (- (car size) (cadr coords)))
+ (y0 (cdar coords))
+ (x1 (- (car size) (caar coords)))
+ (y1 (cddr coords)))
+ (setcar coords (cons x0 y0))
+ (setcdr coords (cons x1 y1))))
+ ('circle
+ (setf (caar coords) (- (car size) (caar coords))))
+ ('poly
+ (dotimes (i (length coords))
+ (when (= 0 (% i 2))
+ (aset coords i (- (car size) (aref coords i)))))))))
+ map)
+
(provide 'image)
;;; image.el ends here
diff --git a/test/lisp/image-tests.el b/test/lisp/image-tests.el
index 80142d6d6de..1e409190865 100644
--- a/test/lisp/image-tests.el
+++ b/test/lisp/image-tests.el
@@ -153,4 +153,115 @@ image-rotate
(image-rotate -154.5)
(should (equal image '(image :rotation 91.0)))))
+;;;; Transforming maps
+
+(ert-deftest image-create-image-with-map ()
+ "Test that `create-image' correctly adds :map and/or :original-map."
+ (let ((data "foo")
+ (map '(((circle (1 . 1) . 1) a)))
+ (original-map '(((circle (2 . 2) . 2) a)))
+ (original-map-other '(((circle (3 . 3) . 3) a))))
+ ;; Generate :original-map from :map.
+ (let* ((image (create-image data 'svg t :map map :scale 0.5))
+ (got-original-map (image-property image :original-map)))
+ (should (equal got-original-map original-map)))
+ ;; Generate :map from :original-map.
+ (let* ((image (create-image
+ data 'svg t :original-map original-map :scale 0.5))
+ (got-map (image-property image :map)))
+ (should (equal got-map map)))
+ ;; Use :original-map if both it and :map are specified.
+ (let* ((image (create-image
+ data 'svg t :map map
+ :original-map original-map-other :scale 0.5))
+ (got-original-map (image-property image :original-map)))
+ (should (equal got-original-map original-map-other)))))
+
+(ert-deftest image--compute-map-and-original-map ()
+ "Test `image--compute-map' and `image--compute-original-map'."
+ (let* ((svg-string "<?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"no\"?><svg width=\"125pt\" height=\"116pt\" viewBox=\"0.00 0.00 125.00 116.00\" xmlns=\"http://www.w3.org/2000/svg\" xmlns:xlink=\"http://www.w3.org/1999/xlink\"><g transform=\"scale(1 1) rotate(0) translate(4 112)\"><polygon fill=\"white\" stroke=\"transparent\" points=\"-4,4 -4,-112 121,-112 121,4 -4,4\"/><a xlink:href=\"a\"><ellipse fill=\"none\" stroke=\"black\" cx=\"27\" cy=\"-90\" rx=\"18\" ry=\"18\"/><text text-anchor=\"middle\" x=\"27\" y=\"-86.3\" fill=\"#000000\">A</text></a><a xlink:href=\"b\"><polygon fill=\"none\" stroke=\"black\" points=\"54,-36 0,-36 0,0 54,0 54,-36\"/><text text-anchor=\"middle\" x=\"27\" y=\"-14.3\" fill=\"#000000\">B</text></a><a xlink:href=\"c\"><ellipse fill=\"none\" stroke=\"black\" cx=\"90\" cy=\"-90\" rx=\"27\" ry=\"18\"/><text text-anchor=\"middle\" x=\"90\" y=\"-86.3\" fill=\"#000000\">C</text></a></g></svg>")
+ (original-map
+ '(((circle (41 . 29) . 24) "a" (help-echo "A"))
+ ((rect (5 . 101) 77 . 149) "b" (help-echo "B"))
+ ((poly . [161 29 160 22 154 15 146 10 136 7 125 5 114 7 104 10 96 15 91 22 89 29 91 37 96 43 104 49 114 52 125 53 136 52 146 49 154 43 160 37]) "c" (help-echo "C"))))
+ (scaled-map
+ '(((circle (82 . 58) . 48) "a" (help-echo "A"))
+ ((rect (10 . 202) 154 . 298) "b" (help-echo "B"))
+ ((poly . [322 58 320 44 308 30 292 20 272 14 250 10 228 14 208 20 192 30 182 44 178 58 182 74 192 86 208 98 228 104 250 106 272 104 292 98 308 86 320 74]) "c" (help-echo "C"))))
+ (flipped-map
+ '(((circle (125 . 29) . 24) "a" (help-echo "A"))
+ ((rect (89 . 101) 161 . 149) "b" (help-echo "B"))
+ ((poly . [5 29 6 22 12 15 20 10 30 7 41 5 52 7 62 10 70 15 75 22 77 29 75 37 70 43 62 49 52 52 41 53 30 52 20 49 12 43 6 37]) "c" (help-echo "C"))))
+ (rotated-map
+ '(((circle (126 . 41) . 24) "a" (help-echo "A"))
+ ((rect (6 . 5) 54 . 77) "b" (help-echo "B"))
+ ((poly . [126 161 133 160 140 154 145 146 148 136 150 125 148 114 145 104 140 96 133 91 126 89 118 91 112 96 106 104 103 114 102 125 103 136 106 146 112 154 118 160]) "c" (help-echo "C"))))
+ (scaled-rotated-flipped-map
+ '(((circle (58 . 82) . 48) "a" (help-echo "A"))
+ ((rect (202 . 10) 298 . 154) "b" (help-echo "B"))
+ ((poly . [58 322 44 320 30 308 20 292 14 272 10 250 14 228 20 208 30 192 44 182 58 178 74 182 86 192 98 208 104 228 106 250 104 272 98 292 86 308 74 320]) "c" (help-echo "C"))))
+ (image (create-image svg-string 'svg t :map scaled-rotated-flipped-map
+ :scale 2 :rotation 90 :flip t)))
+ ;; Test that `image--compute-original-map' correctly generates
+ ;; original-map when creating an already transformed image.
+ (should (equal (image-property image :original-map)
+ original-map))
+ (setf (image-property image :flip) nil)
+ (setf (image-property image :rotation) 0)
+ (setf (image-property image :scale) 2)
+ (should (equal (image--compute-map image)
+ scaled-map))
+ (setf (image-property image :scale) 1)
+ (setf (image-property image :rotation) 90)
+ (should (equal (image--compute-map image)
+ rotated-map))
+ (setf (image-property image :rotation) 0)
+ (setf (image-property image :flip) t)
+ (should (equal (image--compute-map image)
+ flipped-map))
+ (setf (image-property image :scale) 2)
+ (setf (image-property image :rotation) 90)
+ (should (equal (image--compute-map image)
+ scaled-rotated-flipped-map))
+
+ ;; Uncomment to test manually by interactively transforming the
+ ;; image and checking the map boundaries by hovering them.
+
+ ;; (with-current-buffer (get-buffer-create "*test image map*")
+ ;; (erase-buffer)
+ ;; (insert-image image)
+ ;; (goto-char (point-min))
+ ;; (pop-to-buffer (current-buffer)))
+ ))
+
+(ert-deftest image-transform-map ()
+ "Test functions related to transforming image maps."
+ (let ((map '(((circle (4 . 3) . 2) "circle")
+ ((rect (3 . 6) 8 . 8) "rect")
+ ((poly . [6 11 7 13 2 14]) "poly")))
+ (width 10)
+ (height 15))
+ (should (equal (image--scale-map (copy-tree map t) 2)
+ '(((circle (8 . 6) . 4) "circle")
+ ((rect (6 . 12) 16 . 16) "rect")
+ ((poly . [12 22 14 26 4 28]) "poly"))))
+ (should (equal (image--rotate-map (copy-tree map t) 90 `(,width . ,height))
+ '(((circle (12 . 4) . 2) "circle")
+ ((rect (7 . 3) 9 . 8) "rect")
+ ((poly . [4 6 2 7 1 2]) "poly"))))
+ (should (equal (image--flip-map (copy-tree map t) t `(,width . ,height))
+ '(((circle (6 . 3) . 2) "circle")
+ ((rect (2 . 6) 7 . 8) "rect")
+ ((poly . [4 11 3 13 8 14]) "poly"))))
+ (let ((copy (copy-tree map t)))
+ (image--scale-map copy 2)
+ ;; Scale size because the map has been scaled.
+ (image--rotate-map copy 90 `(,(* 2 width) . ,(* 2 height)))
+ ;; Swap width and height because the map has been flipped.
+ (image--flip-map copy t `(,(* 2 height) . ,(* 2 width)))
+ (should (equal copy
+ '(((circle (6 . 8) . 4) "circle")
+ ((rect (12 . 6) 16 . 16) "rect")
+ ((poly . [22 12 26 14 28 4]) "poly")))))))
+
;;; image-tests.el ends here
--
2.41.0
^ permalink raw reply related [relevance 3%]
* bug#69602: 29.1; Image :map should adjust with :scale and :rotation
2024-03-21 6:45 3% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-03-21 11:59 0% ` Eli Zaretskii
2024-03-23 0:11 3% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 200+ results
From: Eli Zaretskii @ 2024-03-21 11:59 UTC (permalink / raw)
To: Joseph Turner; +Cc: 69602, stephen.berman, juri
> From: Joseph Turner <joseph@breatheoutbreathe.in>
> Cc: 69602@debbugs.gnu.org, stephen.berman@gmx.net, juri@linkov.net
> Date: Wed, 20 Mar 2024 23:45:34 -0700
>
> > I had in mind a special variable (we'd need to mention it in NEWS and
> > in the doc string of the relevant functions). Adding an argument is a
> > heavier change, and I think it is not justified in this case, because
> > I do agree with you that most, if not all, applications would want the
> > coordinates to scale together with the image.
>
> Thanks for your feedback and your patience!
>
> Please see attached patch.
Thanks. The tests you added have some problems:
. you use thread-first, but don't require subr-x when compiling
. the tests fail when run in batch mode
. when invoked interactively in a GUI session, one test fails:
F image--compute-map-and-original-map
Test ‘image--compute-map’ and ‘image--compute-original-map’.
(ert-test-failed
((should (equal (image--compute-map image) flipped-map)) :form
(equal
(((circle ... . 24) "a" (help-echo "A"))
((rect ... 162 . 149) "b" (help-echo "B"))
((poly . [6 29 7 22 13 15 21 10 31 7 ...]) "c" (help-echo "C")))
(((circle ... . 24) "a" (help-echo "A"))
((rect ... 161 . 149) "b" (help-echo "B"))
((poly . [5 29 6 22 12 15 20 10 30 7 ...]) "c" (help-echo "C"))))
:value nil :explanation (list-elt 0 (list-elt 0 (cdr (car ...))))))
It looks like some pixels do not match exactly? Perhaps some
tolerances need to be allowed?
^ permalink raw reply [relevance 0%]
* bug#69602: 29.1; Image :map should adjust with :scale and :rotation
2024-03-21 11:59 0% ` Eli Zaretskii
@ 2024-03-23 0:11 3% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-23 7:58 0% ` Eli Zaretskii
0 siblings, 1 reply; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-03-23 0:11 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 69602, stephen.berman, juri
[-- Attachment #1: Type: text/plain, Size: 2009 bytes --]
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Joseph Turner <joseph@breatheoutbreathe.in>
>> Cc: 69602@debbugs.gnu.org, stephen.berman@gmx.net, juri@linkov.net
>> Date: Wed, 20 Mar 2024 23:45:34 -0700
>>
>> > I had in mind a special variable (we'd need to mention it in NEWS and
>> > in the doc string of the relevant functions). Adding an argument is a
>> > heavier change, and I think it is not justified in this case, because
>> > I do agree with you that most, if not all, applications would want the
>> > coordinates to scale together with the image.
>>
>> Thanks for your feedback and your patience!
>>
>> Please see attached patch.
>
> Thanks. The tests you added have some problems:
>
> . you use thread-first, but don't require subr-x when compiling
I removed thread-first.
> . the tests fail when run in batch mode
I added (skip-unless (display-images-p)) to the two problematic tests,
and it solved the issue on my machine.
> . when invoked interactively in a GUI session, one test fails:
>
> F image--compute-map-and-original-map
> Test ‘image--compute-map’ and ‘image--compute-original-map’.
> (ert-test-failed
> ((should (equal (image--compute-map image) flipped-map)) :form
> (equal
> (((circle ... . 24) "a" (help-echo "A"))
> ((rect ... 162 . 149) "b" (help-echo "B"))
> ((poly . [6 29 7 22 13 15 21 10 31 7 ...]) "c" (help-echo "C")))
> (((circle ... . 24) "a" (help-echo "A"))
> ((rect ... 161 . 149) "b" (help-echo "B"))
> ((poly . [5 29 6 22 12 15 20 10 30 7 ...]) "c" (help-echo "C"))))
> :value nil :explanation (list-elt 0 (list-elt 0 (cdr (car ...))))))
>
> It looks like some pixels do not match exactly? Perhaps some
> tolerances need to be allowed?
Interesting - does the result of `image-size` vary per machine?
In any case, I added `image-tests--map-equal' to compare image maps with
some tolerance. Do the tests pass on your machine now?
Thank you!
Joseph
[-- Attachment #2: 0001-Recompute-map-when-image-scale-rotation-or-flip-chan.patch --]
[-- Type: text/x-diff, Size: 28039 bytes --]
From 4a0c7fc0d0354f60ee856cc50e743ee3034ac2a7 Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Thu, 7 Mar 2024 21:55:00 -0800
Subject: [PATCH] Recompute :map when image :scale, :rotation, or :flip changes
Now, when transforming an image, its :map is recomputed to fit.
Image map coordinates are integers, so when computing :map, coordinates
are rounded. To prevent an image from drifting from its map after
repeated transformations, `create-image' now adds a new image property
:original-map, which is combined with the image's transformation
parameters to recompute :map.
* lisp/image.el (image-recompute-map-p): Add user option to control
whether :map is recomputed when an image is transformed.
(create-image): Create :map from :original-map and vice versa.
(image--delayed-change-size): Fix comment.
(image--change-size, image-rotate, image-flip-horizontally,
image-flip-vertically): Recompute image map after transformation and
mention image-recompute-map-p in docstring.
(image--compute-map): Add function to compute a map from original map.
(image--compute-map): Add function to compute an original map from map.
(image--scale-map): Add function to scale a map based on :scale.
(image--rotate-map): Add function to rotate a map based on :rotation.
(image--rotate-coord): Add function to rotate a map coordinate pair.
(image--flip-map): Add function to flip a map based on :flip.
(image-increase-size, image-decrease-size, image-mouse-increase-size,
image-mouse-decrease-size): Mention image-recompute-map-p in docstring.
* etc/NEWS: Add NEWS entry.
* doc/lispref/display.texi (Image Descriptors): Document :original-map
and new user option image-recompute-map-p.
* test/lisp/image-tests.el (image--compute-map-and-original-map): Test
`image--compute-map' and `image--compute-original-map'.
(image-tests--map-equal): Add equality predicate to compare image maps.
(image-create-image-with-map): Test that `create-image' adds :map and/or
:original-map as appropriate.
(image-transform-map): Test functions related to transforming maps.
---
doc/lispref/display.texi | 24 +++++
etc/NEWS | 12 +++
lisp/image.el | 221 ++++++++++++++++++++++++++++++++++++---
test/lisp/image-tests.el | 143 +++++++++++++++++++++++++
4 files changed, 388 insertions(+), 12 deletions(-)
diff --git a/doc/lispref/display.texi b/doc/lispref/display.texi
index 10cf5ce89e2..8335a02b5c5 100644
--- a/doc/lispref/display.texi
+++ b/doc/lispref/display.texi
@@ -6055,6 +6055,30 @@ Image Descriptors
when creating the image, or use the result of
@code{image-compute-scaling-factor} to compute the elements of the
map.
+
+When an image's @code{:scale}, @code{:rotation}, or @code{:flip} is
+changed, @code{:map} will be recomputed based on the value of
+@code{:original-map} and the values of those transformation.
+
+@item :original-map @var{original-map}
+@cindex original image map
+This specifies the untransformed image map which will be used to
+recompute @code{:map} after the image's @code{:scale}, @code{:rotation},
+or @code{:flip} is changed.
+
+If @code{:original-map} is not specified when creating an image with
+@code{create-image}, it will be computed based on the supplied
+@code{:map}, as well as any of @code{:scale}, @code{:rotation}, or
+@code{:flip} which are non-nil.
+
+Conversely, if @code{:original-map} is specified but @code{:map} is not,
+@code{:map} will be computed based on @code{:original-map},
+@code{:scale}, @code{:rotation}, and @code{:flip}.
+
+@defopt image-recompute-map-p
+Set this user option to nil to prevent Emacs from automatically
+recomputing an image @code{:map} based on its @code{:original-map}.
+@end defopt
@end table
@defun image-mask-p spec &optional frame
diff --git a/etc/NEWS b/etc/NEWS
index 06856602ea8..cbd97b495b2 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -1292,6 +1292,18 @@ without specifying a file, like this:
(notifications-notify
:title "I am playing music" :app-icon 'multimedia-player)
+** Image
+
++++
+*** Image :map property is now recomputed when image is transformed.
+Now images with clickable maps work as expected after you run commands
+such as `image-increase-size', `image-decrease-size', `image-rotate',
+`image-flip-horizontally', and `image-flip-vertically'.
+
++++
+*** New user option 'image-recompute-map-p'
+Set this option to nil to prevent Emacs from recomputing image maps.
+
** Image Dired
*** New user option 'image-dired-thumb-naming'.
diff --git a/lisp/image.el b/lisp/image.el
index 2ebce59a98c..c5082c78b75 100644
--- a/lisp/image.el
+++ b/lisp/image.el
@@ -533,6 +533,16 @@ create-image
('t t)
('nil nil)
(func (funcall func image)))))))
+ ;; Add original map from map.
+ (when (and (plist-get props :map)
+ (not (plist-get props :original-map)))
+ (setq image (nconc image (list :original-map
+ (image--compute-original-map image)))))
+ ;; Add map from original map.
+ (when (and (plist-get props :original-map)
+ (not (plist-get props :map)))
+ (setq image (nconc image (list :map
+ (image--compute-map image)))))
image)))
(defun image--default-smoothing (image)
@@ -1173,7 +1183,10 @@ image-increase-size
If N is 3, then the image size will be increased by 30%. More
generally, the image size is multiplied by 1 plus N divided by 10.
N defaults to 2, which increases the image size by 20%.
-POSITION can be a buffer position or a marker, and defaults to point."
+POSITION can be a buffer position or a marker, and defaults to point.
+
+When user option `image-recompute-map-p' is non-nil, the image's `:map'
+is recomputed to fit the newly transformed image."
(interactive "P")
(image--delayed-change-size (if n
(1+ (/ (prefix-numeric-value n) 10.0))
@@ -1185,7 +1198,7 @@ image-increase-size
(defun image--delayed-change-size (size position)
;; Wait for a bit of idle-time before actually performing the change,
;; so as to batch together sequences of closely consecutive size changes.
- ;; `image--change-size' just changes one value in a plist. The actual
+ ;; `image--change-size' just changes two values in a plist. The actual
;; image resizing happens later during redisplay. So if those
;; consecutive calls happen without any redisplay between them,
;; the costly operation of image resizing should happen only once.
@@ -1196,7 +1209,10 @@ image-decrease-size
If N is 3, then the image size will be decreased by 30%. More
generally, the image size is multiplied by 1 minus N divided by 10.
N defaults to 2, which decreases the image size by 20%.
-POSITION can be a buffer position or a marker, and defaults to point."
+POSITION can be a buffer position or a marker, and defaults to point.
+
+When user option `image-recompute-map-p' is non-nil, the image's `:map'
+is recomputed to fit the newly transformed image."
(interactive "P")
(image--delayed-change-size (if n
(- 1 (/ (prefix-numeric-value n) 10.0))
@@ -1208,7 +1224,10 @@ image-decrease-size
(defun image-mouse-increase-size (&optional event)
"Increase the image size using the mouse-gesture EVENT.
This increases the size of the image at the position specified by
-EVENT, if any, by the default factor used by `image-increase-size'."
+EVENT, if any, by the default factor used by `image-increase-size'.
+
+When user option `image-recompute-map-p' is non-nil, the image's `:map'
+is recomputed to fit the newly transformed image."
(interactive "e")
(when (listp event)
(save-window-excursion
@@ -1218,7 +1237,10 @@ image-mouse-increase-size
(defun image-mouse-decrease-size (&optional event)
"Decrease the image size using the mouse-gesture EVENT.
This decreases the size of the image at the position specified by
-EVENT, if any, by the default factor used by `image-decrease-size'."
+EVENT, if any, by the default factor used by `image-decrease-size'.
+
+When user option `image-recompute-map-p' is non-nil, the image's `:map'
+is recomputed to fit the newly transformed image."
(interactive "e")
(when (listp event)
(save-window-excursion
@@ -1269,7 +1291,9 @@ image--change-size
(new-image (image--image-without-parameters image))
(scale (image--current-scaling image new-image)))
(setcdr image (cdr new-image))
- (plist-put (cdr image) :scale (* scale factor))))
+ (plist-put (cdr image) :scale (* scale factor))
+ (when (and (image-property image :original-map) image-recompute-map-p)
+ (setf (image-property image :map) (image--compute-map image)))))
(defun image--image-without-parameters (image)
(cons (pop image)
@@ -1296,7 +1320,10 @@ image-rotate
If nil, ANGLE defaults to 90. Interactively, rotate the image 90
degrees clockwise with no prefix argument, and counter-clockwise
with a prefix argument. Note that most image types support
-rotations by only multiples of 90 degrees."
+rotations by only multiples of 90 degrees.
+
+When user option `image-recompute-map-p' is non-nil, the image's `:map'
+is recomputed to fit the newly transformed image."
(interactive (and current-prefix-arg '(-90)))
(let ((image (image--get-imagemagick-and-warn)))
(setf (image-property image :rotation)
@@ -1304,7 +1331,9 @@ image-rotate
(or angle 90))
;; We don't want to exceed 360 degrees rotation,
;; because it's not seen as valid in Exif data.
- 360))))
+ 360)))
+ (when (and (image-property image :original-map) image-recompute-map-p)
+ (setf (image-property image :map) (image--compute-map image))))
(set-transient-map image--repeat-map nil nil
"Use %k for further adjustments"))
@@ -1325,23 +1354,191 @@ image-save
(read-file-name "Write image to file: ")))))
(defun image-flip-horizontally ()
- "Horizontally flip the image under point."
+ "Horizontally flip the image under point.
+
+When user option `image-recompute-map-p' is non-nil, the image's `:map'
+is recomputed to fit the newly transformed image."
(interactive)
(let ((image (image--get-image)))
(image-flush image)
(setf (image-property image :flip)
- (not (image-property image :flip)))))
+ (not (image-property image :flip)))
+ (when (and (image-property image :original-map) image-recompute-map-p)
+ (setf (image-property image :map) (image--compute-map image)))))
(defun image-flip-vertically ()
- "Vertically flip the image under point."
+ "Vertically flip the image under point.
+
+When user option `image-recompute-map-p' is non-nil, the image's `:map'
+is recomputed to fit the newly transformed image."
(interactive)
(let ((image (image--get-image)))
(image-rotate 180)
(setf (image-property image :flip)
- (not (image-property image :flip)))))
+ (not (image-property image :flip)))
+ (when (and (image-property image :original-map) image-recompute-map-p)
+ (setf (image-property image :map) (image--compute-map image)))))
(define-obsolete-function-alias 'image-refresh #'image-flush "29.1")
+;;; Map transformation
+
+(defcustom image-recompute-map-p t
+ "Recompute image map when scaling, rotating, or flipping an image."
+ :type 'boolean
+ :version "30.1")
+
+(defun image--compute-map (image)
+ "Compute map for IMAGE suitable to be used as its :map property.
+Return a copy of :original-image transformed based on IMAGE's :scale,
+:rotation, and :flip. When IMAGE's :original-map is nil, return nil.
+When :rotation is not a multiple of 90, return copy of :original-map."
+ (pcase-let* ((original-map (image-property image :original-map))
+ (map (copy-tree original-map t))
+ (scale (or (image-property image :scale) 1))
+ (rotation (or (image-property image :rotation) 0))
+ (flip (image-property image :flip))
+ ((and size `(,width . ,height)) (image-size image t)))
+ (when (and ; Handle only 90-degree rotations
+ (zerop (mod rotation 1))
+ (zerop (% (truncate rotation) 90)))
+ ;; SIZE fits MAP after transformations. Scale MAP before
+ ;; flip and rotate operations, since both need MAP to fit SIZE.
+ (image--scale-map map scale)
+ ;; In rendered images, rotation is always applied before flip.
+ (image--rotate-map
+ map rotation (if (or (= 90 rotation) (= 270 rotation))
+ ;; If rotated ±90°, swap width and height.
+ (cons height width)
+ size))
+ ;; After rotation, there's no need to swap width and height.
+ (image--flip-map map flip size))
+ map))
+
+(defun image--compute-original-map (image)
+ "Return original map for IMAGE.
+If IMAGE lacks :map property, return nil.
+When :rotation is not a multiple of 90, return copy of :map."
+ (when (image-property image :map)
+ (let* ((image-copy (copy-tree image t))
+ (map (image-property image-copy :map))
+ (scale (or (image-property image-copy :scale) 1))
+ (rotation (or (image-property image-copy :rotation) 0))
+ (flip (image-property image-copy :flip))
+ (size (image-size image-copy t)))
+ (when (and ; Handle only 90-degree rotations
+ (zerop (mod rotation 1))
+ (zerop (% (truncate rotation) 90)))
+ ;; In rendered images, rotation is always applied before flip.
+ ;; To undo the transformation, flip before rotating.
+ ;; SIZE fits MAP before it is transformed back to ORIGINAL-MAP.
+ ;; Therefore, scale MAP after flip and rotate operations, since
+ ;; both need MAP to fit SIZE.
+ (image--flip-map map flip size)
+ (image--rotate-map map (- rotation) size)
+ (image--scale-map map (/ 1.0 scale)))
+ map)))
+
+(defun image--scale-map (map scale)
+ "Scale MAP according to SCALE.
+Destructively modifies and returns MAP."
+ (unless (= 1 scale)
+ (pcase-dolist (`(,`(,type . ,coords) ,_id ,_plist) map)
+ (pcase-exhaustive type
+ ('rect
+ (setf (caar coords) (round (* (caar coords) scale)))
+ (setf (cdar coords) (round (* (cdar coords) scale)))
+ (setf (cadr coords) (round (* (cadr coords) scale)))
+ (setf (cddr coords) (round (* (cddr coords) scale))))
+ ('circle
+ (setf (caar coords) (round (* (caar coords) scale)))
+ (setf (cdar coords) (round (* (cdar coords) scale)))
+ (setcdr coords (round (* (cdr coords) scale))))
+ ('poly
+ (dotimes (i (length coords))
+ (aset coords i
+ (round (* (aref coords i) scale))))))))
+ map)
+
+(defun image--rotate-map (map rotation size)
+ "Rotate MAP according to ROTATION and SIZE.
+Destructively modifies and returns MAP."
+ (unless (zerop rotation)
+ (pcase-dolist (`(,`(,type . ,coords) ,_id ,_plist) map)
+ (pcase-exhaustive type
+ ('rect
+ (let ( x0 y0 ; New upper left corner
+ x1 y1) ; New bottom right corner
+ (pcase (truncate (mod rotation 360)) ; Set new corners to...
+ (90 ; ...old bottom left and upper right
+ (setq x0 (caar coords) y0 (cddr coords)
+ x1 (cadr coords) y1 (cdar coords)))
+ (180 ; ...old bottom right and upper left
+ (setq x0 (cadr coords) y0 (cddr coords)
+ x1 (caar coords) y1 (cdar coords)))
+ (270 ; ...old upper right and bottom left
+ (setq x0 (cadr coords) y0 (cdar coords)
+ x1 (caar coords) y1 (cddr coords))))
+ (setcar coords (image--rotate-coord x0 y0 rotation size))
+ (setcdr coords (image--rotate-coord x1 y1 rotation size))))
+ ('circle
+ (setcar coords (image--rotate-coord
+ (caar coords) (cdar coords) rotation size)))
+ ('poly
+ (dotimes (i (length coords))
+ (when (= 0 (% i 2))
+ (pcase-let ((`(,x . ,y)
+ (image--rotate-coord
+ (aref coords i) (aref coords (1+ i)) rotation size)))
+ (aset coords i x)
+ (aset coords (1+ i) y))))))))
+ map)
+
+(defun image--rotate-coord (x y angle size)
+ "Rotate coordinates X and Y by ANGLE in image of SIZE.
+ANGLE must be a multiple of 90. Returns a cons cell of rounded
+coordinates (X1 Y1)."
+ (pcase-let* ((radian (* (/ angle 180.0) float-pi))
+ (`(,width . ,height) size)
+ ;; y is positive, but we are in the bottom-right quadrant
+ (y (- y))
+ ;; Rotate clockwise
+ (x1 (+ (* (sin radian) y) (* (cos radian) x)))
+ (y1 (- (* (cos radian) y) (* (sin radian) x)))
+ ;; Translate image back into bottom-right quadrant
+ (`(,x1 . ,y1)
+ (pcase (truncate (mod angle 360))
+ (90 ; Translate right by height
+ (cons (+ x1 height) y1))
+ (180 ; Translate right by width and down by height
+ (cons (+ x1 width) (- y1 height)))
+ (270 ; Translate down by width
+ (cons x1 (- y1 width)))))
+ ;; Invert y1 to make both x1 and y1 positive
+ (y1 (- y1)))
+ (cons (round x1) (round y1))))
+
+(defun image--flip-map (map flip size)
+ "Horizontally flip MAP according to FLIP and SIZE.
+Destructively modifies and returns MAP."
+ (when flip
+ (pcase-dolist (`(,`(,type . ,coords) ,_id ,_plist) map)
+ (pcase-exhaustive type
+ ('rect
+ (let ((x0 (- (car size) (cadr coords)))
+ (y0 (cdar coords))
+ (x1 (- (car size) (caar coords)))
+ (y1 (cddr coords)))
+ (setcar coords (cons x0 y0))
+ (setcdr coords (cons x1 y1))))
+ ('circle
+ (setf (caar coords) (- (car size) (caar coords))))
+ ('poly
+ (dotimes (i (length coords))
+ (when (= 0 (% i 2))
+ (aset coords i (- (car size) (aref coords i)))))))))
+ map)
+
(provide 'image)
;;; image.el ends here
diff --git a/test/lisp/image-tests.el b/test/lisp/image-tests.el
index 80142d6d6de..46b1704f25a 100644
--- a/test/lisp/image-tests.el
+++ b/test/lisp/image-tests.el
@@ -153,4 +153,147 @@ image-rotate
(image-rotate -154.5)
(should (equal image '(image :rotation 91.0)))))
+;;;; Transforming maps
+
+(ert-deftest image-create-image-with-map ()
+ "Test that `create-image' correctly adds :map and/or :original-map."
+ (skip-unless (display-images-p))
+ (let ((data "foo")
+ (map '(((circle (1 . 1) . 1) a)))
+ (original-map '(((circle (2 . 2) . 2) a)))
+ (original-map-other '(((circle (3 . 3) . 3) a))))
+ ;; Generate :original-map from :map.
+ (let* ((image (create-image data 'svg t :map map :scale 0.5))
+ (got-original-map (image-property image :original-map)))
+ (should (equal got-original-map original-map)))
+ ;; Generate :map from :original-map.
+ (let* ((image (create-image
+ data 'svg t :original-map original-map :scale 0.5))
+ (got-map (image-property image :map)))
+ (should (equal got-map map)))
+ ;; Use :original-map if both it and :map are specified.
+ (let* ((image (create-image
+ data 'svg t :map map
+ :original-map original-map-other :scale 0.5))
+ (got-original-map (image-property image :original-map)))
+ (should (equal got-original-map original-map-other)))))
+
+(defun image-tests--map-equal (a b &optional tolerance)
+ "Return t if maps A and B have the same coordinates within TOLERANCE.
+Since image sizes calculations vary on different machines, this function
+allows for each image map coordinate in A to be within TOLERANCE to the
+corresponding coordinate in B. When nil, TOLERANCE defaults to 5."
+ (unless tolerance (setq tolerance 5))
+ (catch 'different
+ (cl-labels ((check-tolerance
+ (coord-a coord-b)
+ (unless (>= tolerance (abs (- coord-a coord-b)))
+ (throw 'different nil))))
+ (dotimes (i (length a) t)
+ (pcase-let ((`((,type-a . ,coords-a) ,_id ,_plist) (nth i a))
+ (`((,type-b . ,coords-b) ,_id ,_plist) (nth i b)))
+ (unless (eq type-a type-b)
+ (throw 'different nil))
+ (pcase-exhaustive type-a
+ ('rect
+ (check-tolerance (caar coords-a) (caar coords-b))
+ (check-tolerance (cdar coords-a) (cdar coords-b))
+ (check-tolerance (cadr coords-a) (cadr coords-b))
+ (check-tolerance (cddr coords-a) (cddr coords-b)))
+ ('circle
+ (check-tolerance (caar coords-a) (caar coords-b))
+ (check-tolerance (cdar coords-a) (cdar coords-b))
+ (check-tolerance (cdar coords-a) (cdar coords-b)))
+ ('poly
+ (dotimes (i (length coords-a))
+ (check-tolerance (aref coords-a i) (aref coords-b i))))))))))
+
+(ert-deftest image--compute-map-and-original-map ()
+ "Test `image--compute-map' and `image--compute-original-map'."
+ (skip-unless (display-images-p))
+ (let* ((svg-string "<?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"no\"?><svg width=\"125pt\" height=\"116pt\" viewBox=\"0.00 0.00 125.00 116.00\" xmlns=\"http://www.w3.org/2000/svg\" xmlns:xlink=\"http://www.w3.org/1999/xlink\"><g transform=\"scale(1 1) rotate(0) translate(4 112)\"><polygon fill=\"white\" stroke=\"transparent\" points=\"-4,4 -4,-112 121,-112 121,4 -4,4\"/><a xlink:href=\"a\"><ellipse fill=\"none\" stroke=\"black\" cx=\"27\" cy=\"-90\" rx=\"18\" ry=\"18\"/><text text-anchor=\"middle\" x=\"27\" y=\"-86.3\" fill=\"#000000\">A</text></a><a xlink:href=\"b\"><polygon fill=\"none\" stroke=\"black\" points=\"54,-36 0,-36 0,0 54,0 54,-36\"/><text text-anchor=\"middle\" x=\"27\" y=\"-14.3\" fill=\"#000000\">B</text></a><a xlink:href=\"c\"><ellipse fill=\"none\" stroke=\"black\" cx=\"90\" cy=\"-90\" rx=\"27\" ry=\"18\"/><text text-anchor=\"middle\" x=\"90\" y=\"-86.3\" fill=\"#000000\">C</text></a></g></svg>")
+ (original-map
+ '(((circle (41 . 29) . 24) "a" (help-echo "A"))
+ ((rect (5 . 101) 77 . 149) "b" (help-echo "B"))
+ ((poly . [161 29 160 22 154 15 146 10 136 7 125 5 114 7 104 10 96 15 91 22 89 29 91 37 96 43 104 49 114 52 125 53 136 52 146 49 154 43 160 37]) "c" (help-echo "C"))))
+ (scaled-map
+ '(((circle (82 . 58) . 48) "a" (help-echo "A"))
+ ((rect (10 . 202) 154 . 298) "b" (help-echo "B"))
+ ((poly . [322 58 320 44 308 30 292 20 272 14 250 10 228 14 208 20 192 30 182 44 178 58 182 74 192 86 208 98 228 104 250 106 272 104 292 98 308 86 320 74]) "c" (help-echo "C"))))
+ (flipped-map
+ '(((circle (125 . 29) . 24) "a" (help-echo "A"))
+ ((rect (89 . 101) 161 . 149) "b" (help-echo "B"))
+ ((poly . [5 29 6 22 12 15 20 10 30 7 41 5 52 7 62 10 70 15 75 22 77 29 75 37 70 43 62 49 52 52 41 53 30 52 20 49 12 43 6 37]) "c" (help-echo "C"))))
+ (rotated-map
+ '(((circle (126 . 41) . 24) "a" (help-echo "A"))
+ ((rect (6 . 5) 54 . 77) "b" (help-echo "B"))
+ ((poly . [126 161 133 160 140 154 145 146 148 136 150 125 148 114 145 104 140 96 133 91 126 89 118 91 112 96 106 104 103 114 102 125 103 136 106 146 112 154 118 160]) "c" (help-echo "C"))))
+ (scaled-rotated-flipped-map
+ '(((circle (58 . 82) . 48) "a" (help-echo "A"))
+ ((rect (202 . 10) 298 . 154) "b" (help-echo "B"))
+ ((poly . [58 322 44 320 30 308 20 292 14 272 10 250 14 228 20 208 30 192 44 182 58 178 74 182 86 192 98 208 104 228 106 250 104 272 98 292 86 308 74 320]) "c" (help-echo "C"))))
+ (image (create-image svg-string 'svg t :map scaled-rotated-flipped-map
+ :scale 2 :rotation 90 :flip t)))
+ ;; Test that `image--compute-original-map' correctly generates
+ ;; original-map when creating an already transformed image.
+ (should (image-tests--map-equal (image-property image :original-map)
+ original-map))
+ (setf (image-property image :flip) nil)
+ (setf (image-property image :rotation) 0)
+ (setf (image-property image :scale) 2)
+ (should (image-tests--map-equal (image--compute-map image)
+ scaled-map))
+ (setf (image-property image :scale) 1)
+ (setf (image-property image :rotation) 90)
+ (should (image-tests--map-equal (image--compute-map image)
+ rotated-map))
+ (setf (image-property image :rotation) 0)
+ (setf (image-property image :flip) t)
+ (should (image-tests--map-equal (image--compute-map image)
+ flipped-map))
+ (setf (image-property image :scale) 2)
+ (setf (image-property image :rotation) 90)
+ (should (image-tests--map-equal (image--compute-map image)
+ scaled-rotated-flipped-map))
+
+ ;; Uncomment to test manually by interactively transforming the
+ ;; image and checking the map boundaries by hovering them.
+
+ ;; (with-current-buffer (get-buffer-create "*test image map*")
+ ;; (erase-buffer)
+ ;; (insert-image image)
+ ;; (goto-char (point-min))
+ ;; (pop-to-buffer (current-buffer)))
+ ))
+
+(ert-deftest image-transform-map ()
+ "Test functions related to transforming image maps."
+ (let ((map '(((circle (4 . 3) . 2) "circle")
+ ((rect (3 . 6) 8 . 8) "rect")
+ ((poly . [6 11 7 13 2 14]) "poly")))
+ (width 10)
+ (height 15))
+ (should (equal (image--scale-map (copy-tree map t) 2)
+ '(((circle (8 . 6) . 4) "circle")
+ ((rect (6 . 12) 16 . 16) "rect")
+ ((poly . [12 22 14 26 4 28]) "poly"))))
+ (should (equal (image--rotate-map (copy-tree map t) 90 `(,width . ,height))
+ '(((circle (12 . 4) . 2) "circle")
+ ((rect (7 . 3) 9 . 8) "rect")
+ ((poly . [4 6 2 7 1 2]) "poly"))))
+ (should (equal (image--flip-map (copy-tree map t) t `(,width . ,height))
+ '(((circle (6 . 3) . 2) "circle")
+ ((rect (2 . 6) 7 . 8) "rect")
+ ((poly . [4 11 3 13 8 14]) "poly"))))
+ (let ((copy (copy-tree map t)))
+ (image--scale-map copy 2)
+ ;; Scale size because the map has been scaled.
+ (image--rotate-map copy 90 `(,(* 2 width) . ,(* 2 height)))
+ ;; Swap width and height because the map has been flipped.
+ (image--flip-map copy t `(,(* 2 height) . ,(* 2 width)))
+ (should (equal copy
+ '(((circle (6 . 8) . 4) "circle")
+ ((rect (12 . 6) 16 . 16) "rect")
+ ((poly . [22 12 26 14 28 4]) "poly")))))))
+
;;; image-tests.el ends here
--
2.41.0
^ permalink raw reply related [relevance 3%]
* bug#69602: 29.1; Image :map should adjust with :scale and :rotation
2024-03-23 0:11 3% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-03-23 7:58 0% ` Eli Zaretskii
2024-03-23 17:41 3% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 200+ results
From: Eli Zaretskii @ 2024-03-23 7:58 UTC (permalink / raw)
To: Joseph Turner; +Cc: 69602, stephen.berman, juri
> From: Joseph Turner <joseph@breatheoutbreathe.in>
> Cc: 69602@debbugs.gnu.org, stephen.berman@gmx.net, juri@linkov.net
> Date: Fri, 22 Mar 2024 17:11:17 -0700
>
> > Thanks. The tests you added have some problems:
> >
> > . you use thread-first, but don't require subr-x when compiling
>
> I removed thread-first.
>
> > . the tests fail when run in batch mode
>
> I added (skip-unless (display-images-p)) to the two problematic tests,
> and it solved the issue on my machine.
Solves it here as well.
> > . when invoked interactively in a GUI session, one test fails:
> >
> > F image--compute-map-and-original-map
> > Test ‘image--compute-map’ and ‘image--compute-original-map’.
> > (ert-test-failed
> > ((should (equal (image--compute-map image) flipped-map)) :form
> > (equal
> > (((circle ... . 24) "a" (help-echo "A"))
> > ((rect ... 162 . 149) "b" (help-echo "B"))
> > ((poly . [6 29 7 22 13 15 21 10 31 7 ...]) "c" (help-echo "C")))
> > (((circle ... . 24) "a" (help-echo "A"))
> > ((rect ... 161 . 149) "b" (help-echo "B"))
> > ((poly . [5 29 6 22 12 15 20 10 30 7 ...]) "c" (help-echo "C"))))
> > :value nil :explanation (list-elt 0 (list-elt 0 (cdr (car ...))))))
> >
> > It looks like some pixels do not match exactly? Perhaps some
> > tolerances need to be allowed?
>
> Interesting - does the result of `image-size` vary per machine?
I guess so. The transformations are AFAIK done in floating-point
arithmetics, so some minor inaccuracies are possible.
> In any case, I added `image-tests--map-equal' to compare image maps with
> some tolerance. Do the tests pass on your machine now?
Yes, they do now, thanks. However, there's a warning when compiling
the tests:
In image-tests--map-equal:
lisp/image-tests.el:192:17: Warning: Unused lexical variable `i'
Can you fix this, please?
^ permalink raw reply [relevance 0%]
* bug#69602: 29.1; Image :map should adjust with :scale and :rotation
2024-03-23 7:58 0% ` Eli Zaretskii
@ 2024-03-23 17:41 3% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-23 17:58 0% ` Eli Zaretskii
0 siblings, 1 reply; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-03-23 17:41 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 69602, stephen.berman, juri
[-- Attachment #1: Type: text/plain, Size: 2138 bytes --]
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Joseph Turner <joseph@breatheoutbreathe.in>
>> Cc: 69602@debbugs.gnu.org, stephen.berman@gmx.net, juri@linkov.net
>> Date: Fri, 22 Mar 2024 17:11:17 -0700
>>
>> > Thanks. The tests you added have some problems:
>> >
>> > . you use thread-first, but don't require subr-x when compiling
>>
>> I removed thread-first.
>>
>> > . the tests fail when run in batch mode
>>
>> I added (skip-unless (display-images-p)) to the two problematic tests,
>> and it solved the issue on my machine.
>
> Solves it here as well.
>
>> > . when invoked interactively in a GUI session, one test fails:
>> >
>> > F image--compute-map-and-original-map
>> > Test ‘image--compute-map’ and ‘image--compute-original-map’.
>> > (ert-test-failed
>> > ((should (equal (image--compute-map image) flipped-map)) :form
>> > (equal
>> > (((circle ... . 24) "a" (help-echo "A"))
>> > ((rect ... 162 . 149) "b" (help-echo "B"))
>> > ((poly . [6 29 7 22 13 15 21 10 31 7 ...]) "c" (help-echo "C")))
>> > (((circle ... . 24) "a" (help-echo "A"))
>> > ((rect ... 161 . 149) "b" (help-echo "B"))
>> > ((poly . [5 29 6 22 12 15 20 10 30 7 ...]) "c" (help-echo "C"))))
>> > :value nil :explanation (list-elt 0 (list-elt 0 (cdr (car ...))))))
>> >
>> > It looks like some pixels do not match exactly? Perhaps some
>> > tolerances need to be allowed?
>>
>> Interesting - does the result of `image-size` vary per machine?
>
> I guess so. The transformations are AFAIK done in floating-point
> arithmetics, so some minor inaccuracies are possible.
>
>> In any case, I added `image-tests--map-equal' to compare image maps with
>> some tolerance. Do the tests pass on your machine now?
>
> Yes, they do now, thanks. However, there's a warning when compiling
> the tests:
>
> In image-tests--map-equal:
> lisp/image-tests.el:192:17: Warning: Unused lexical variable `i'
>
> Can you fix this, please?
Oops! I just re-read the dotimes docstring to discover that the RESULT
arg is deprecated. Fixed. Thank you!
Joseph
[-- Attachment #2: 0001-Recompute-map-when-image-scale-rotation-or-flip-chan.patch --]
[-- Type: text/x-diff, Size: 28045 bytes --]
From 0b6f90a1ba757426ff429693914828ce0d93d839 Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Thu, 7 Mar 2024 21:55:00 -0800
Subject: [PATCH] Recompute :map when image :scale, :rotation, or :flip changes
Now, when transforming an image, its :map is recomputed to fit.
Image map coordinates are integers, so when computing :map, coordinates
are rounded. To prevent an image from drifting from its map after
repeated transformations, `create-image' now adds a new image property
:original-map, which is combined with the image's transformation
parameters to recompute :map.
* lisp/image.el (image-recompute-map-p): Add user option to control
whether :map is recomputed when an image is transformed.
(create-image): Create :map from :original-map and vice versa.
(image--delayed-change-size): Fix comment.
(image--change-size, image-rotate, image-flip-horizontally,
image-flip-vertically): Recompute image map after transformation and
mention image-recompute-map-p in docstring.
(image--compute-map): Add function to compute a map from original map.
(image--compute-map): Add function to compute an original map from map.
(image--scale-map): Add function to scale a map based on :scale.
(image--rotate-map): Add function to rotate a map based on :rotation.
(image--rotate-coord): Add function to rotate a map coordinate pair.
(image--flip-map): Add function to flip a map based on :flip.
(image-increase-size, image-decrease-size, image-mouse-increase-size,
image-mouse-decrease-size): Mention image-recompute-map-p in docstring.
* etc/NEWS: Add NEWS entry.
* doc/lispref/display.texi (Image Descriptors): Document :original-map
and new user option image-recompute-map-p.
* test/lisp/image-tests.el (image--compute-map-and-original-map): Test
`image--compute-map' and `image--compute-original-map'.
(image-tests--map-equal): Add equality predicate to compare image maps.
(image-create-image-with-map): Test that `create-image' adds :map and/or
:original-map as appropriate.
(image-transform-map): Test functions related to transforming maps.
---
doc/lispref/display.texi | 24 +++++
etc/NEWS | 12 +++
lisp/image.el | 221 ++++++++++++++++++++++++++++++++++++---
test/lisp/image-tests.el | 144 +++++++++++++++++++++++++
4 files changed, 389 insertions(+), 12 deletions(-)
diff --git a/doc/lispref/display.texi b/doc/lispref/display.texi
index 10cf5ce89e2..8335a02b5c5 100644
--- a/doc/lispref/display.texi
+++ b/doc/lispref/display.texi
@@ -6055,6 +6055,30 @@ Image Descriptors
when creating the image, or use the result of
@code{image-compute-scaling-factor} to compute the elements of the
map.
+
+When an image's @code{:scale}, @code{:rotation}, or @code{:flip} is
+changed, @code{:map} will be recomputed based on the value of
+@code{:original-map} and the values of those transformation.
+
+@item :original-map @var{original-map}
+@cindex original image map
+This specifies the untransformed image map which will be used to
+recompute @code{:map} after the image's @code{:scale}, @code{:rotation},
+or @code{:flip} is changed.
+
+If @code{:original-map} is not specified when creating an image with
+@code{create-image}, it will be computed based on the supplied
+@code{:map}, as well as any of @code{:scale}, @code{:rotation}, or
+@code{:flip} which are non-nil.
+
+Conversely, if @code{:original-map} is specified but @code{:map} is not,
+@code{:map} will be computed based on @code{:original-map},
+@code{:scale}, @code{:rotation}, and @code{:flip}.
+
+@defopt image-recompute-map-p
+Set this user option to nil to prevent Emacs from automatically
+recomputing an image @code{:map} based on its @code{:original-map}.
+@end defopt
@end table
@defun image-mask-p spec &optional frame
diff --git a/etc/NEWS b/etc/NEWS
index 06856602ea8..cbd97b495b2 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -1292,6 +1292,18 @@ without specifying a file, like this:
(notifications-notify
:title "I am playing music" :app-icon 'multimedia-player)
+** Image
+
++++
+*** Image :map property is now recomputed when image is transformed.
+Now images with clickable maps work as expected after you run commands
+such as `image-increase-size', `image-decrease-size', `image-rotate',
+`image-flip-horizontally', and `image-flip-vertically'.
+
++++
+*** New user option 'image-recompute-map-p'
+Set this option to nil to prevent Emacs from recomputing image maps.
+
** Image Dired
*** New user option 'image-dired-thumb-naming'.
diff --git a/lisp/image.el b/lisp/image.el
index 2ebce59a98c..c5082c78b75 100644
--- a/lisp/image.el
+++ b/lisp/image.el
@@ -533,6 +533,16 @@ create-image
('t t)
('nil nil)
(func (funcall func image)))))))
+ ;; Add original map from map.
+ (when (and (plist-get props :map)
+ (not (plist-get props :original-map)))
+ (setq image (nconc image (list :original-map
+ (image--compute-original-map image)))))
+ ;; Add map from original map.
+ (when (and (plist-get props :original-map)
+ (not (plist-get props :map)))
+ (setq image (nconc image (list :map
+ (image--compute-map image)))))
image)))
(defun image--default-smoothing (image)
@@ -1173,7 +1183,10 @@ image-increase-size
If N is 3, then the image size will be increased by 30%. More
generally, the image size is multiplied by 1 plus N divided by 10.
N defaults to 2, which increases the image size by 20%.
-POSITION can be a buffer position or a marker, and defaults to point."
+POSITION can be a buffer position or a marker, and defaults to point.
+
+When user option `image-recompute-map-p' is non-nil, the image's `:map'
+is recomputed to fit the newly transformed image."
(interactive "P")
(image--delayed-change-size (if n
(1+ (/ (prefix-numeric-value n) 10.0))
@@ -1185,7 +1198,7 @@ image-increase-size
(defun image--delayed-change-size (size position)
;; Wait for a bit of idle-time before actually performing the change,
;; so as to batch together sequences of closely consecutive size changes.
- ;; `image--change-size' just changes one value in a plist. The actual
+ ;; `image--change-size' just changes two values in a plist. The actual
;; image resizing happens later during redisplay. So if those
;; consecutive calls happen without any redisplay between them,
;; the costly operation of image resizing should happen only once.
@@ -1196,7 +1209,10 @@ image-decrease-size
If N is 3, then the image size will be decreased by 30%. More
generally, the image size is multiplied by 1 minus N divided by 10.
N defaults to 2, which decreases the image size by 20%.
-POSITION can be a buffer position or a marker, and defaults to point."
+POSITION can be a buffer position or a marker, and defaults to point.
+
+When user option `image-recompute-map-p' is non-nil, the image's `:map'
+is recomputed to fit the newly transformed image."
(interactive "P")
(image--delayed-change-size (if n
(- 1 (/ (prefix-numeric-value n) 10.0))
@@ -1208,7 +1224,10 @@ image-decrease-size
(defun image-mouse-increase-size (&optional event)
"Increase the image size using the mouse-gesture EVENT.
This increases the size of the image at the position specified by
-EVENT, if any, by the default factor used by `image-increase-size'."
+EVENT, if any, by the default factor used by `image-increase-size'.
+
+When user option `image-recompute-map-p' is non-nil, the image's `:map'
+is recomputed to fit the newly transformed image."
(interactive "e")
(when (listp event)
(save-window-excursion
@@ -1218,7 +1237,10 @@ image-mouse-increase-size
(defun image-mouse-decrease-size (&optional event)
"Decrease the image size using the mouse-gesture EVENT.
This decreases the size of the image at the position specified by
-EVENT, if any, by the default factor used by `image-decrease-size'."
+EVENT, if any, by the default factor used by `image-decrease-size'.
+
+When user option `image-recompute-map-p' is non-nil, the image's `:map'
+is recomputed to fit the newly transformed image."
(interactive "e")
(when (listp event)
(save-window-excursion
@@ -1269,7 +1291,9 @@ image--change-size
(new-image (image--image-without-parameters image))
(scale (image--current-scaling image new-image)))
(setcdr image (cdr new-image))
- (plist-put (cdr image) :scale (* scale factor))))
+ (plist-put (cdr image) :scale (* scale factor))
+ (when (and (image-property image :original-map) image-recompute-map-p)
+ (setf (image-property image :map) (image--compute-map image)))))
(defun image--image-without-parameters (image)
(cons (pop image)
@@ -1296,7 +1320,10 @@ image-rotate
If nil, ANGLE defaults to 90. Interactively, rotate the image 90
degrees clockwise with no prefix argument, and counter-clockwise
with a prefix argument. Note that most image types support
-rotations by only multiples of 90 degrees."
+rotations by only multiples of 90 degrees.
+
+When user option `image-recompute-map-p' is non-nil, the image's `:map'
+is recomputed to fit the newly transformed image."
(interactive (and current-prefix-arg '(-90)))
(let ((image (image--get-imagemagick-and-warn)))
(setf (image-property image :rotation)
@@ -1304,7 +1331,9 @@ image-rotate
(or angle 90))
;; We don't want to exceed 360 degrees rotation,
;; because it's not seen as valid in Exif data.
- 360))))
+ 360)))
+ (when (and (image-property image :original-map) image-recompute-map-p)
+ (setf (image-property image :map) (image--compute-map image))))
(set-transient-map image--repeat-map nil nil
"Use %k for further adjustments"))
@@ -1325,23 +1354,191 @@ image-save
(read-file-name "Write image to file: ")))))
(defun image-flip-horizontally ()
- "Horizontally flip the image under point."
+ "Horizontally flip the image under point.
+
+When user option `image-recompute-map-p' is non-nil, the image's `:map'
+is recomputed to fit the newly transformed image."
(interactive)
(let ((image (image--get-image)))
(image-flush image)
(setf (image-property image :flip)
- (not (image-property image :flip)))))
+ (not (image-property image :flip)))
+ (when (and (image-property image :original-map) image-recompute-map-p)
+ (setf (image-property image :map) (image--compute-map image)))))
(defun image-flip-vertically ()
- "Vertically flip the image under point."
+ "Vertically flip the image under point.
+
+When user option `image-recompute-map-p' is non-nil, the image's `:map'
+is recomputed to fit the newly transformed image."
(interactive)
(let ((image (image--get-image)))
(image-rotate 180)
(setf (image-property image :flip)
- (not (image-property image :flip)))))
+ (not (image-property image :flip)))
+ (when (and (image-property image :original-map) image-recompute-map-p)
+ (setf (image-property image :map) (image--compute-map image)))))
(define-obsolete-function-alias 'image-refresh #'image-flush "29.1")
+;;; Map transformation
+
+(defcustom image-recompute-map-p t
+ "Recompute image map when scaling, rotating, or flipping an image."
+ :type 'boolean
+ :version "30.1")
+
+(defun image--compute-map (image)
+ "Compute map for IMAGE suitable to be used as its :map property.
+Return a copy of :original-image transformed based on IMAGE's :scale,
+:rotation, and :flip. When IMAGE's :original-map is nil, return nil.
+When :rotation is not a multiple of 90, return copy of :original-map."
+ (pcase-let* ((original-map (image-property image :original-map))
+ (map (copy-tree original-map t))
+ (scale (or (image-property image :scale) 1))
+ (rotation (or (image-property image :rotation) 0))
+ (flip (image-property image :flip))
+ ((and size `(,width . ,height)) (image-size image t)))
+ (when (and ; Handle only 90-degree rotations
+ (zerop (mod rotation 1))
+ (zerop (% (truncate rotation) 90)))
+ ;; SIZE fits MAP after transformations. Scale MAP before
+ ;; flip and rotate operations, since both need MAP to fit SIZE.
+ (image--scale-map map scale)
+ ;; In rendered images, rotation is always applied before flip.
+ (image--rotate-map
+ map rotation (if (or (= 90 rotation) (= 270 rotation))
+ ;; If rotated ±90°, swap width and height.
+ (cons height width)
+ size))
+ ;; After rotation, there's no need to swap width and height.
+ (image--flip-map map flip size))
+ map))
+
+(defun image--compute-original-map (image)
+ "Return original map for IMAGE.
+If IMAGE lacks :map property, return nil.
+When :rotation is not a multiple of 90, return copy of :map."
+ (when (image-property image :map)
+ (let* ((image-copy (copy-tree image t))
+ (map (image-property image-copy :map))
+ (scale (or (image-property image-copy :scale) 1))
+ (rotation (or (image-property image-copy :rotation) 0))
+ (flip (image-property image-copy :flip))
+ (size (image-size image-copy t)))
+ (when (and ; Handle only 90-degree rotations
+ (zerop (mod rotation 1))
+ (zerop (% (truncate rotation) 90)))
+ ;; In rendered images, rotation is always applied before flip.
+ ;; To undo the transformation, flip before rotating.
+ ;; SIZE fits MAP before it is transformed back to ORIGINAL-MAP.
+ ;; Therefore, scale MAP after flip and rotate operations, since
+ ;; both need MAP to fit SIZE.
+ (image--flip-map map flip size)
+ (image--rotate-map map (- rotation) size)
+ (image--scale-map map (/ 1.0 scale)))
+ map)))
+
+(defun image--scale-map (map scale)
+ "Scale MAP according to SCALE.
+Destructively modifies and returns MAP."
+ (unless (= 1 scale)
+ (pcase-dolist (`(,`(,type . ,coords) ,_id ,_plist) map)
+ (pcase-exhaustive type
+ ('rect
+ (setf (caar coords) (round (* (caar coords) scale)))
+ (setf (cdar coords) (round (* (cdar coords) scale)))
+ (setf (cadr coords) (round (* (cadr coords) scale)))
+ (setf (cddr coords) (round (* (cddr coords) scale))))
+ ('circle
+ (setf (caar coords) (round (* (caar coords) scale)))
+ (setf (cdar coords) (round (* (cdar coords) scale)))
+ (setcdr coords (round (* (cdr coords) scale))))
+ ('poly
+ (dotimes (i (length coords))
+ (aset coords i
+ (round (* (aref coords i) scale))))))))
+ map)
+
+(defun image--rotate-map (map rotation size)
+ "Rotate MAP according to ROTATION and SIZE.
+Destructively modifies and returns MAP."
+ (unless (zerop rotation)
+ (pcase-dolist (`(,`(,type . ,coords) ,_id ,_plist) map)
+ (pcase-exhaustive type
+ ('rect
+ (let ( x0 y0 ; New upper left corner
+ x1 y1) ; New bottom right corner
+ (pcase (truncate (mod rotation 360)) ; Set new corners to...
+ (90 ; ...old bottom left and upper right
+ (setq x0 (caar coords) y0 (cddr coords)
+ x1 (cadr coords) y1 (cdar coords)))
+ (180 ; ...old bottom right and upper left
+ (setq x0 (cadr coords) y0 (cddr coords)
+ x1 (caar coords) y1 (cdar coords)))
+ (270 ; ...old upper right and bottom left
+ (setq x0 (cadr coords) y0 (cdar coords)
+ x1 (caar coords) y1 (cddr coords))))
+ (setcar coords (image--rotate-coord x0 y0 rotation size))
+ (setcdr coords (image--rotate-coord x1 y1 rotation size))))
+ ('circle
+ (setcar coords (image--rotate-coord
+ (caar coords) (cdar coords) rotation size)))
+ ('poly
+ (dotimes (i (length coords))
+ (when (= 0 (% i 2))
+ (pcase-let ((`(,x . ,y)
+ (image--rotate-coord
+ (aref coords i) (aref coords (1+ i)) rotation size)))
+ (aset coords i x)
+ (aset coords (1+ i) y))))))))
+ map)
+
+(defun image--rotate-coord (x y angle size)
+ "Rotate coordinates X and Y by ANGLE in image of SIZE.
+ANGLE must be a multiple of 90. Returns a cons cell of rounded
+coordinates (X1 Y1)."
+ (pcase-let* ((radian (* (/ angle 180.0) float-pi))
+ (`(,width . ,height) size)
+ ;; y is positive, but we are in the bottom-right quadrant
+ (y (- y))
+ ;; Rotate clockwise
+ (x1 (+ (* (sin radian) y) (* (cos radian) x)))
+ (y1 (- (* (cos radian) y) (* (sin radian) x)))
+ ;; Translate image back into bottom-right quadrant
+ (`(,x1 . ,y1)
+ (pcase (truncate (mod angle 360))
+ (90 ; Translate right by height
+ (cons (+ x1 height) y1))
+ (180 ; Translate right by width and down by height
+ (cons (+ x1 width) (- y1 height)))
+ (270 ; Translate down by width
+ (cons x1 (- y1 width)))))
+ ;; Invert y1 to make both x1 and y1 positive
+ (y1 (- y1)))
+ (cons (round x1) (round y1))))
+
+(defun image--flip-map (map flip size)
+ "Horizontally flip MAP according to FLIP and SIZE.
+Destructively modifies and returns MAP."
+ (when flip
+ (pcase-dolist (`(,`(,type . ,coords) ,_id ,_plist) map)
+ (pcase-exhaustive type
+ ('rect
+ (let ((x0 (- (car size) (cadr coords)))
+ (y0 (cdar coords))
+ (x1 (- (car size) (caar coords)))
+ (y1 (cddr coords)))
+ (setcar coords (cons x0 y0))
+ (setcdr coords (cons x1 y1))))
+ ('circle
+ (setf (caar coords) (- (car size) (caar coords))))
+ ('poly
+ (dotimes (i (length coords))
+ (when (= 0 (% i 2))
+ (aset coords i (- (car size) (aref coords i)))))))))
+ map)
+
(provide 'image)
;;; image.el ends here
diff --git a/test/lisp/image-tests.el b/test/lisp/image-tests.el
index 80142d6d6de..6a5f03e38a0 100644
--- a/test/lisp/image-tests.el
+++ b/test/lisp/image-tests.el
@@ -153,4 +153,148 @@ image-rotate
(image-rotate -154.5)
(should (equal image '(image :rotation 91.0)))))
+;;;; Transforming maps
+
+(ert-deftest image-create-image-with-map ()
+ "Test that `create-image' correctly adds :map and/or :original-map."
+ (skip-unless (display-images-p))
+ (let ((data "foo")
+ (map '(((circle (1 . 1) . 1) a)))
+ (original-map '(((circle (2 . 2) . 2) a)))
+ (original-map-other '(((circle (3 . 3) . 3) a))))
+ ;; Generate :original-map from :map.
+ (let* ((image (create-image data 'svg t :map map :scale 0.5))
+ (got-original-map (image-property image :original-map)))
+ (should (equal got-original-map original-map)))
+ ;; Generate :map from :original-map.
+ (let* ((image (create-image
+ data 'svg t :original-map original-map :scale 0.5))
+ (got-map (image-property image :map)))
+ (should (equal got-map map)))
+ ;; Use :original-map if both it and :map are specified.
+ (let* ((image (create-image
+ data 'svg t :map map
+ :original-map original-map-other :scale 0.5))
+ (got-original-map (image-property image :original-map)))
+ (should (equal got-original-map original-map-other)))))
+
+(defun image-tests--map-equal (a b &optional tolerance)
+ "Return t if maps A and B have the same coordinates within TOLERANCE.
+Since image sizes calculations vary on different machines, this function
+allows for each image map coordinate in A to be within TOLERANCE to the
+corresponding coordinate in B. When nil, TOLERANCE defaults to 5."
+ (unless tolerance (setq tolerance 5))
+ (catch 'different
+ (cl-labels ((check-tolerance
+ (coord-a coord-b)
+ (unless (>= tolerance (abs (- coord-a coord-b)))
+ (throw 'different nil))))
+ (dotimes (i (length a))
+ (pcase-let ((`((,type-a . ,coords-a) ,_id ,_plist) (nth i a))
+ (`((,type-b . ,coords-b) ,_id ,_plist) (nth i b)))
+ (unless (eq type-a type-b)
+ (throw 'different nil))
+ (pcase-exhaustive type-a
+ ('rect
+ (check-tolerance (caar coords-a) (caar coords-b))
+ (check-tolerance (cdar coords-a) (cdar coords-b))
+ (check-tolerance (cadr coords-a) (cadr coords-b))
+ (check-tolerance (cddr coords-a) (cddr coords-b)))
+ ('circle
+ (check-tolerance (caar coords-a) (caar coords-b))
+ (check-tolerance (cdar coords-a) (cdar coords-b))
+ (check-tolerance (cdar coords-a) (cdar coords-b)))
+ ('poly
+ (dotimes (i (length coords-a))
+ (check-tolerance (aref coords-a i) (aref coords-b i))))))))
+ t))
+
+(ert-deftest image--compute-map-and-original-map ()
+ "Test `image--compute-map' and `image--compute-original-map'."
+ (skip-unless (display-images-p))
+ (let* ((svg-string "<?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"no\"?><svg width=\"125pt\" height=\"116pt\" viewBox=\"0.00 0.00 125.00 116.00\" xmlns=\"http://www.w3.org/2000/svg\" xmlns:xlink=\"http://www.w3.org/1999/xlink\"><g transform=\"scale(1 1) rotate(0) translate(4 112)\"><polygon fill=\"white\" stroke=\"transparent\" points=\"-4,4 -4,-112 121,-112 121,4 -4,4\"/><a xlink:href=\"a\"><ellipse fill=\"none\" stroke=\"black\" cx=\"27\" cy=\"-90\" rx=\"18\" ry=\"18\"/><text text-anchor=\"middle\" x=\"27\" y=\"-86.3\" fill=\"#000000\">A</text></a><a xlink:href=\"b\"><polygon fill=\"none\" stroke=\"black\" points=\"54,-36 0,-36 0,0 54,0 54,-36\"/><text text-anchor=\"middle\" x=\"27\" y=\"-14.3\" fill=\"#000000\">B</text></a><a xlink:href=\"c\"><ellipse fill=\"none\" stroke=\"black\" cx=\"90\" cy=\"-90\" rx=\"27\" ry=\"18\"/><text text-anchor=\"middle\" x=\"90\" y=\"-86.3\" fill=\"#000000\">C</text></a></g></svg>")
+ (original-map
+ '(((circle (41 . 29) . 24) "a" (help-echo "A"))
+ ((rect (5 . 101) 77 . 149) "b" (help-echo "B"))
+ ((poly . [161 29 160 22 154 15 146 10 136 7 125 5 114 7 104 10 96 15 91 22 89 29 91 37 96 43 104 49 114 52 125 53 136 52 146 49 154 43 160 37]) "c" (help-echo "C"))))
+ (scaled-map
+ '(((circle (82 . 58) . 48) "a" (help-echo "A"))
+ ((rect (10 . 202) 154 . 298) "b" (help-echo "B"))
+ ((poly . [322 58 320 44 308 30 292 20 272 14 250 10 228 14 208 20 192 30 182 44 178 58 182 74 192 86 208 98 228 104 250 106 272 104 292 98 308 86 320 74]) "c" (help-echo "C"))))
+ (flipped-map
+ '(((circle (125 . 29) . 24) "a" (help-echo "A"))
+ ((rect (89 . 101) 161 . 149) "b" (help-echo "B"))
+ ((poly . [5 29 6 22 12 15 20 10 30 7 41 5 52 7 62 10 70 15 75 22 77 29 75 37 70 43 62 49 52 52 41 53 30 52 20 49 12 43 6 37]) "c" (help-echo "C"))))
+ (rotated-map
+ '(((circle (126 . 41) . 24) "a" (help-echo "A"))
+ ((rect (6 . 5) 54 . 77) "b" (help-echo "B"))
+ ((poly . [126 161 133 160 140 154 145 146 148 136 150 125 148 114 145 104 140 96 133 91 126 89 118 91 112 96 106 104 103 114 102 125 103 136 106 146 112 154 118 160]) "c" (help-echo "C"))))
+ (scaled-rotated-flipped-map
+ '(((circle (58 . 82) . 48) "a" (help-echo "A"))
+ ((rect (202 . 10) 298 . 154) "b" (help-echo "B"))
+ ((poly . [58 322 44 320 30 308 20 292 14 272 10 250 14 228 20 208 30 192 44 182 58 178 74 182 86 192 98 208 104 228 106 250 104 272 98 292 86 308 74 320]) "c" (help-echo "C"))))
+ (image (create-image svg-string 'svg t :map scaled-rotated-flipped-map
+ :scale 2 :rotation 90 :flip t)))
+ ;; Test that `image--compute-original-map' correctly generates
+ ;; original-map when creating an already transformed image.
+ (should (image-tests--map-equal (image-property image :original-map)
+ original-map))
+ (setf (image-property image :flip) nil)
+ (setf (image-property image :rotation) 0)
+ (setf (image-property image :scale) 2)
+ (should (image-tests--map-equal (image--compute-map image)
+ scaled-map))
+ (setf (image-property image :scale) 1)
+ (setf (image-property image :rotation) 90)
+ (should (image-tests--map-equal (image--compute-map image)
+ rotated-map))
+ (setf (image-property image :rotation) 0)
+ (setf (image-property image :flip) t)
+ (should (image-tests--map-equal (image--compute-map image)
+ flipped-map))
+ (setf (image-property image :scale) 2)
+ (setf (image-property image :rotation) 90)
+ (should (image-tests--map-equal (image--compute-map image)
+ scaled-rotated-flipped-map))
+
+ ;; Uncomment to test manually by interactively transforming the
+ ;; image and checking the map boundaries by hovering them.
+
+ ;; (with-current-buffer (get-buffer-create "*test image map*")
+ ;; (erase-buffer)
+ ;; (insert-image image)
+ ;; (goto-char (point-min))
+ ;; (pop-to-buffer (current-buffer)))
+ ))
+
+(ert-deftest image-transform-map ()
+ "Test functions related to transforming image maps."
+ (let ((map '(((circle (4 . 3) . 2) "circle")
+ ((rect (3 . 6) 8 . 8) "rect")
+ ((poly . [6 11 7 13 2 14]) "poly")))
+ (width 10)
+ (height 15))
+ (should (equal (image--scale-map (copy-tree map t) 2)
+ '(((circle (8 . 6) . 4) "circle")
+ ((rect (6 . 12) 16 . 16) "rect")
+ ((poly . [12 22 14 26 4 28]) "poly"))))
+ (should (equal (image--rotate-map (copy-tree map t) 90 `(,width . ,height))
+ '(((circle (12 . 4) . 2) "circle")
+ ((rect (7 . 3) 9 . 8) "rect")
+ ((poly . [4 6 2 7 1 2]) "poly"))))
+ (should (equal (image--flip-map (copy-tree map t) t `(,width . ,height))
+ '(((circle (6 . 3) . 2) "circle")
+ ((rect (2 . 6) 7 . 8) "rect")
+ ((poly . [4 11 3 13 8 14]) "poly"))))
+ (let ((copy (copy-tree map t)))
+ (image--scale-map copy 2)
+ ;; Scale size because the map has been scaled.
+ (image--rotate-map copy 90 `(,(* 2 width) . ,(* 2 height)))
+ ;; Swap width and height because the map has been flipped.
+ (image--flip-map copy t `(,(* 2 height) . ,(* 2 width)))
+ (should (equal copy
+ '(((circle (6 . 8) . 4) "circle")
+ ((rect (12 . 6) 16 . 16) "rect")
+ ((poly . [22 12 26 14 28 4]) "poly")))))))
+
;;; image-tests.el ends here
--
2.41.0
^ permalink raw reply related [relevance 3%]
* bug#69602: 29.1; Image :map should adjust with :scale and :rotation
2024-03-23 17:41 3% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-03-23 17:58 0% ` Eli Zaretskii
2024-03-23 18:18 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-23 20:32 10% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 2 replies; 200+ results
From: Eli Zaretskii @ 2024-03-23 17:58 UTC (permalink / raw)
To: Joseph Turner; +Cc: 69602-done, stephen.berman, juri
> From: Joseph Turner <joseph@breatheoutbreathe.in>
> Cc: 69602@debbugs.gnu.org, stephen.berman@gmx.net, juri@linkov.net
> Date: Sat, 23 Mar 2024 10:41:59 -0700
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > In image-tests--map-equal:
> > lisp/image-tests.el:192:17: Warning: Unused lexical variable `i'
> >
> > Can you fix this, please?
>
> Oops! I just re-read the dotimes docstring to discover that the RESULT
> arg is deprecated. Fixed. Thank you!
Thanks, installed on master, and closing the bug.
^ permalink raw reply [relevance 0%]
* bug#69602: 29.1; Image :map should adjust with :scale and :rotation
2024-03-23 17:58 0% ` Eli Zaretskii
@ 2024-03-23 18:18 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-23 20:32 10% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 0 replies; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-03-23 18:18 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 69602-done, stephen.berman, juri
Thank you!
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Joseph Turner <joseph@breatheoutbreathe.in>
>> Cc: 69602@debbugs.gnu.org, stephen.berman@gmx.net, juri@linkov.net
>> Date: Sat, 23 Mar 2024 10:41:59 -0700
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> > In image-tests--map-equal:
>> > lisp/image-tests.el:192:17: Warning: Unused lexical variable `i'
>> >
>> > Can you fix this, please?
>>
>> Oops! I just re-read the dotimes docstring to discover that the RESULT
>> arg is deprecated. Fixed. Thank you!
>
> Thanks, installed on master, and closing the bug.
^ permalink raw reply [relevance 5%]
* bug#69602: 29.1; Image :map should adjust with :scale and :rotation
2024-03-23 17:58 0% ` Eli Zaretskii
2024-03-23 18:18 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-03-23 20:32 10% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-28 10:13 0% ` Eli Zaretskii
1 sibling, 1 reply; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-03-23 20:32 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 69602-done, stephen.berman, juri
[-- Attachment #1: Type: text/plain, Size: 620 bytes --]
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Joseph Turner <joseph@breatheoutbreathe.in>
>> Cc: 69602@debbugs.gnu.org, stephen.berman@gmx.net, juri@linkov.net
>> Date: Sat, 23 Mar 2024 10:41:59 -0700
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> > In image-tests--map-equal:
>> > lisp/image-tests.el:192:17: Warning: Unused lexical variable `i'
>> >
>> > Can you fix this, please?
>>
>> Oops! I just re-read the dotimes docstring to discover that the RESULT
>> arg is deprecated. Fixed. Thank you!
>
> Thanks, installed on master, and closing the bug.
Another minor improvement. Please see patch.
Joseph
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-copy-tree-just-image-map-not-entire-image.patch --]
[-- Type: text/x-diff, Size: 2443 bytes --]
From 359f9f889c2cad5e2f49aa4efd16bb18fe98e0a1 Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Sat, 23 Mar 2024 13:29:17 -0700
Subject: [PATCH] copy-tree just image map, not entire image.
* lisp/image.el (image--compute-original-map):
---
lisp/image.el | 27 +++++++++++++--------------
1 file changed, 13 insertions(+), 14 deletions(-)
diff --git a/lisp/image.el b/lisp/image.el
index 55340ea03dc..d7496485aca 100644
--- a/lisp/image.el
+++ b/lisp/image.el
@@ -1455,24 +1455,23 @@ image--compute-original-map
If IMAGE lacks :map property, return nil.
When :rotation is not a multiple of 90, return copy of :map."
(when (image-property image :map)
- (let* ((image-copy (copy-tree image t))
- (map (image-property image-copy :map))
- (scale (or (image-property image-copy :scale) 1))
- (rotation (or (image-property image-copy :rotation) 0))
- (flip (image-property image-copy :flip))
- (size (image-size image-copy t)))
+ (let* ((original-map (copy-tree (image-property image :map) t))
+ (scale (or (image-property image :scale) 1))
+ (rotation (or (image-property image :rotation) 0))
+ (flip (image-property image :flip))
+ (size (image-size image t)))
(when (and ; Handle only 90-degree rotations
(zerop (mod rotation 1))
(zerop (% (truncate rotation) 90)))
;; In rendered images, rotation is always applied before flip.
- ;; To undo the transformation, flip before rotating.
- ;; SIZE fits MAP before it is transformed back to ORIGINAL-MAP.
- ;; Therefore, scale MAP after flip and rotate operations, since
- ;; both need MAP to fit SIZE.
- (image--flip-map map flip size)
- (image--rotate-map map (- rotation) size)
- (image--scale-map map (/ 1.0 scale)))
- map)))
+ ;; To undo the transformation, flip before rotating. SIZE fits
+ ;; ORIGINAL-MAP before transformations are applied. Therefore,
+ ;; scale ORIGINAL-MAP after flip and rotate operations, since
+ ;; both need ORIGINAL-MAP to fit SIZE.
+ (image--flip-map original-map flip size)
+ (image--rotate-map original-map (- rotation) size)
+ (image--scale-map original-map (/ 1.0 scale)))
+ original-map)))
(defun image--scale-map (map scale)
"Scale MAP according to SCALE.
--
2.41.0
^ permalink raw reply related [relevance 10%]
* bug#69972: 29.1; Unexpected behavior when scrolling images
@ 2024-03-24 9:07 4% Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-24 9:42 0% ` Eli Zaretskii
0 siblings, 1 reply; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-03-24 9:07 UTC (permalink / raw)
To: 69972
When the image at point is larger than the current window and there is
no content after the image, interactively scrolling down (with the
scroll-up command) unexpectedly scrolls past the image to blankness.
Test this by evaluating the following snippet then interactively running
`scroll-up' repeatedly:
(with-current-buffer (get-buffer-create "*test-scroll-image*")
(erase-buffer)
(insert-image (create-image "splash.png" nil nil
;; Scale the image more if it doesn't take up the whole window.
:scale 5))
(goto-char (point-max))
(pop-to-buffer (current-buffer)))
Even more unexpectedly, when point is before the image, running
`scroll-up' repeatedly eventually scrolls back to the top of the image:
(with-current-buffer (get-buffer-create "*test-scroll-image*")
(erase-buffer)
(insert-image (create-image "splash.png" nil nil :scale 5))
(goto-char (point-min))
(pop-to-buffer (current-buffer)))
Non-interactively, scroll-up scrolls the page down to the very bottom of
the image. IMO this is the expected behavior:
(with-current-buffer (get-buffer-create "*test-scroll-image*")
(erase-buffer)
(insert-image (create-image "splash.png" nil nil :scale 5))
(pop-to-buffer (current-buffer))
(scroll-up 999))
Thank you for your help!!
Joseph
Tested on emacs -Q:
In GNU Emacs 29.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.37,
cairo version 1.16.0)
Windowing system distributor 'The X.Org Foundation', version 11.0.12101007
System Description: Debian GNU/Linux 12 (bookworm)
Configured using:
'configure
CONFIG_SHELL=/gnu/store/v9p25q9l5nnaixkhpap5rnymmwbhf9rp-bash-minimal-5.1.16/bin/bash
SHELL=/gnu/store/v9p25q9l5nnaixkhpap5rnymmwbhf9rp-bash-minimal-5.1.16/bin/bash
--prefix=/gnu/store/f4gxh8n3libmywq8d5jvxxkyqblgilxy-emacs-29.1
--enable-fast-install --with-cairo --with-modules
--with-native-compilation=aot --disable-build-details'
Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES
NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3
THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER X11 XDBE XIM XINPUT2 XPM
GTK3 ZLIB
^ permalink raw reply [relevance 4%]
* bug#69972: 29.1; Unexpected behavior when scrolling images
2024-03-24 9:07 4% bug#69972: 29.1; Unexpected behavior when scrolling images Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-03-24 9:42 0% ` Eli Zaretskii
2024-03-25 1:06 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 200+ results
From: Eli Zaretskii @ 2024-03-24 9:42 UTC (permalink / raw)
To: Joseph Turner; +Cc: 69972
> Date: Sun, 24 Mar 2024 02:07:16 -0700
> From: Joseph Turner via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>
> When the image at point is larger than the current window and there is
> no content after the image, interactively scrolling down (with the
> scroll-up command) unexpectedly scrolls past the image to blankness.
I cannot reproduce this, I think.
> Test this by evaluating the following snippet then interactively running
> `scroll-up' repeatedly:
>
> (with-current-buffer (get-buffer-create "*test-scroll-image*")
> (erase-buffer)
> (insert-image (create-image "splash.png" nil nil
> ;; Scale the image more if it doesn't take up the whole window.
> :scale 5))
> (goto-char (point-max))
> (pop-to-buffer (current-buffer)))
This recipe doesn't include the call to scroll-up, so I'm unsure how
you did that and what you saw. When I try "M-: (scroll-up) RET" or
"M-x scroll-up RET", I get several scrolls by window-size, and then
"End of buffer" error when I hit the end of the buffer. If this is
unexpected, please tell why.
> Even more unexpectedly, when point is before the image, running
> `scroll-up' repeatedly eventually scrolls back to the top of the image:
>
> (with-current-buffer (get-buffer-create "*test-scroll-image*")
> (erase-buffer)
> (insert-image (create-image "splash.png" nil nil :scale 5))
> (goto-char (point-min))
> (pop-to-buffer (current-buffer)))
I do see this, but why is that a problem? You supposed to use
scroll-up-command instead, which handles these marginal cases much
better. scroll-up itself is not smart enough to avoid the perceived
"scroll back to top", which is actually caused by the fact that we
zero out window-vscroll (which is how we handle scrolling past large
images).
^ permalink raw reply [relevance 0%]
* bug#69992: Minor improvement to image map transformation logic
@ 2024-03-25 1:00 10% Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-03-25 1:00 UTC (permalink / raw)
To: 69992
[-- Attachment #1: Type: text/plain, Size: 67 bytes --]
Hello,
This patch is slight simplification/optimization.
Joseph
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-copy-tree-just-image-map-not-entire-image.patch --]
[-- Type: text/x-diff, Size: 2443 bytes --]
From 96a30a0450384eaeda21f234911f947952c4dcde Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Sat, 23 Mar 2024 13:29:17 -0700
Subject: [PATCH] copy-tree just image map, not entire image.
* lisp/image.el (image--compute-original-map):
---
lisp/image.el | 27 +++++++++++++--------------
1 file changed, 13 insertions(+), 14 deletions(-)
diff --git a/lisp/image.el b/lisp/image.el
index 55340ea03dc..d7496485aca 100644
--- a/lisp/image.el
+++ b/lisp/image.el
@@ -1455,24 +1455,23 @@ image--compute-original-map
If IMAGE lacks :map property, return nil.
When :rotation is not a multiple of 90, return copy of :map."
(when (image-property image :map)
- (let* ((image-copy (copy-tree image t))
- (map (image-property image-copy :map))
- (scale (or (image-property image-copy :scale) 1))
- (rotation (or (image-property image-copy :rotation) 0))
- (flip (image-property image-copy :flip))
- (size (image-size image-copy t)))
+ (let* ((original-map (copy-tree (image-property image :map) t))
+ (scale (or (image-property image :scale) 1))
+ (rotation (or (image-property image :rotation) 0))
+ (flip (image-property image :flip))
+ (size (image-size image t)))
(when (and ; Handle only 90-degree rotations
(zerop (mod rotation 1))
(zerop (% (truncate rotation) 90)))
;; In rendered images, rotation is always applied before flip.
- ;; To undo the transformation, flip before rotating.
- ;; SIZE fits MAP before it is transformed back to ORIGINAL-MAP.
- ;; Therefore, scale MAP after flip and rotate operations, since
- ;; both need MAP to fit SIZE.
- (image--flip-map map flip size)
- (image--rotate-map map (- rotation) size)
- (image--scale-map map (/ 1.0 scale)))
- map)))
+ ;; To undo the transformation, flip before rotating. SIZE fits
+ ;; ORIGINAL-MAP before transformations are applied. Therefore,
+ ;; scale ORIGINAL-MAP after flip and rotate operations, since
+ ;; both need ORIGINAL-MAP to fit SIZE.
+ (image--flip-map original-map flip size)
+ (image--rotate-map original-map (- rotation) size)
+ (image--scale-map original-map (/ 1.0 scale)))
+ original-map)))
(defun image--scale-map (map scale)
"Scale MAP according to SCALE.
--
2.41.0
^ permalink raw reply related [relevance 10%]
* bug#69972: 29.1; Unexpected behavior when scrolling images
2024-03-24 9:42 0% ` Eli Zaretskii
@ 2024-03-25 1:06 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-25 8:34 11% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-25 12:23 0% ` Eli Zaretskii
0 siblings, 2 replies; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-03-25 1:06 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 69972
Eli Zaretskii <eliz@gnu.org> writes:
>> Date: Sun, 24 Mar 2024 02:07:16 -0700
>> From: Joseph Turner via "Bug reports for GNU Emacs,
>> the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>>
>> When the image at point is larger than the current window and there is
>> no content after the image, interactively scrolling down (with the
>> scroll-up command) unexpectedly scrolls past the image to blankness.
>
> I cannot reproduce this, I think.
>
>> Test this by evaluating the following snippet then interactively running
>> `scroll-up' repeatedly:
>>
>> (with-current-buffer (get-buffer-create "*test-scroll-image*")
>> (erase-buffer)
>> (insert-image (create-image "splash.png" nil nil
>> ;; Scale the image more if it doesn't take up the whole window.
>> :scale 5))
>> (goto-char (point-max))
>> (pop-to-buffer (current-buffer)))
>
> This recipe doesn't include the call to scroll-up, so I'm unsure how
> you did that and what you saw. When I try "M-: (scroll-up) RET" or
> "M-x scroll-up RET", I get several scrolls by window-size, and then
> "End of buffer" error when I hit the end of the buffer. If this is
> unexpected, please tell why.
On my machine, I don't get "End of buffer" error. I tested three
different ways in the following snippet
(with-current-buffer (get-buffer-create "*test-scroll-image*")
(erase-buffer)
(insert-image (create-image "splash.png" nil nil
;; Scale the image more if it doesn't take up the whole window.
:scale 5))
(goto-char (point-max))
(pixel-scroll-precision-mode -1) ; Ensure mouse wheel scroll up and down works
(pop-to-buffer (current-buffer)))
1. "M-: (scroll-up) RET" (repeatedly)
2. C-v (repeatedly)
3. <wheel-down> (repeatedly)
With all three methods, at first Emacs gradually scrolls the image, but
then when I reach the bottom of the image, the image disappears entirely
as Emacs scrolls past it all at once.
>> Even more unexpectedly, when point is before the image, running
>> `scroll-up' repeatedly eventually scrolls back to the top of the image:
>>
>> (with-current-buffer (get-buffer-create "*test-scroll-image*")
>> (erase-buffer)
>> (insert-image (create-image "splash.png" nil nil :scale 5))
>> (goto-char (point-min))
>> (pop-to-buffer (current-buffer)))
>
> I do see this, but why is that a problem? You supposed to use
> scroll-up-command instead, which handles these marginal cases much
> better. scroll-up itself is not smart enough to avoid the perceived
> "scroll back to top", which is actually caused by the fact that we
> zero out window-vscroll (which is how we handle scrolling past large
> images).
You're right. This is not a problem in practice. When point is before
the image, both C-v and <wheel-down> produce the same behavior as above.
Joseph
^ permalink raw reply [relevance 5%]
* bug#69972: 29.1; Unexpected behavior when scrolling images
2024-03-25 1:06 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-03-25 8:34 11% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-25 12:23 0% ` Eli Zaretskii
1 sibling, 0 replies; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-03-25 8:34 UTC (permalink / raw)
To: Eli Zaretskii, 69972
Joseph Turner <joseph@ushin.org> writes:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> Date: Sun, 24 Mar 2024 02:07:16 -0700
>>> From: Joseph Turner via "Bug reports for GNU Emacs,
>>> the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>>>
>>> When the image at point is larger than the current window and there is
>>> no content after the image, interactively scrolling down (with the
>>> scroll-up command) unexpectedly scrolls past the image to blankness.
>>
>> I cannot reproduce this, I think.
>>
>>> Test this by evaluating the following snippet then interactively running
>>> `scroll-up' repeatedly:
>>>
>>> (with-current-buffer (get-buffer-create "*test-scroll-image*")
>>> (erase-buffer)
>>> (insert-image (create-image "splash.png" nil nil
>>> ;; Scale the image more if it doesn't take up the whole window.
>>> :scale 5))
>>> (goto-char (point-max))
>>> (pop-to-buffer (current-buffer)))
>>
>> This recipe doesn't include the call to scroll-up, so I'm unsure how
>> you did that and what you saw. When I try "M-: (scroll-up) RET" or
>> "M-x scroll-up RET", I get several scrolls by window-size, and then
>> "End of buffer" error when I hit the end of the buffer. If this is
>> unexpected, please tell why.
>
> On my machine, I don't get "End of buffer" error.
Correction - I *do* get "End of buffer" error, but only after fully
scrolling past the image (which IMO is unexpected).
> I tested three different ways in the following snippet
>
> (with-current-buffer (get-buffer-create "*test-scroll-image*")
> (erase-buffer)
> (insert-image (create-image "splash.png" nil nil
> ;; Scale the image more if it doesn't take up the whole window.
> :scale 5))
> (goto-char (point-max))
> (pixel-scroll-precision-mode -1) ; Ensure mouse wheel scroll up and down works
> (pop-to-buffer (current-buffer)))
>
> 1. "M-: (scroll-up) RET" (repeatedly)
> 2. C-v (repeatedly)
> 3. <wheel-down> (repeatedly)
>
> With all three methods, at first Emacs gradually scrolls the image, but
> then when I reach the bottom of the image, the image disappears entirely
> as Emacs scrolls past it all at once.
>
>>> Even more unexpectedly, when point is before the image, running
>>> `scroll-up' repeatedly eventually scrolls back to the top of the image:
>>>
>>> (with-current-buffer (get-buffer-create "*test-scroll-image*")
>>> (erase-buffer)
>>> (insert-image (create-image "splash.png" nil nil :scale 5))
>>> (goto-char (point-min))
>>> (pop-to-buffer (current-buffer)))
>>
>> I do see this, but why is that a problem? You supposed to use
>> scroll-up-command instead, which handles these marginal cases much
>> better. scroll-up itself is not smart enough to avoid the perceived
>> "scroll back to top", which is actually caused by the fact that we
>> zero out window-vscroll (which is how we handle scrolling past large
>> images).
>
> You're right. This is not a problem in practice. When point is before
> the image, both C-v and <wheel-down> produce the same behavior as above.
>
> Joseph
^ permalink raw reply [relevance 11%]
* bug#69972: 29.1; Unexpected behavior when scrolling images
2024-03-25 1:06 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-25 8:34 11% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-03-25 12:23 0% ` Eli Zaretskii
2024-03-25 19:43 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 1 reply; 200+ results
From: Eli Zaretskii @ 2024-03-25 12:23 UTC (permalink / raw)
To: Joseph Turner; +Cc: 69972
> From: Joseph Turner <joseph@ushin.org>
> Cc: 69972@debbugs.gnu.org
> Date: Sun, 24 Mar 2024 18:06:44 -0700
>
> (with-current-buffer (get-buffer-create "*test-scroll-image*")
> (erase-buffer)
> (insert-image (create-image "splash.png" nil nil
> ;; Scale the image more if it doesn't take up the whole window.
> :scale 5))
> (goto-char (point-max))
> (pixel-scroll-precision-mode -1) ; Ensure mouse wheel scroll up and down works
> (pop-to-buffer (current-buffer)))
>
> 1. "M-: (scroll-up) RET" (repeatedly)
> 2. C-v (repeatedly)
> 3. <wheel-down> (repeatedly)
>
> With all three methods, at first Emacs gradually scrolls the image, but
> then when I reach the bottom of the image, the image disappears entirely
> as Emacs scrolls past it all at once.
Why is that a problem? The default Emacs scrolling commands don't
guarantee smooth constant-rate scrolling, they guarantee only that you
get to see all the portions of the image, without missing any. So
when you get to the end of the image, there's a heuristic that decides
whether we can scroll past the image, and that is what you see.
I see no bug here.
^ permalink raw reply [relevance 0%]
* bug#69972: 29.1; Unexpected behavior when scrolling images
2024-03-25 12:23 0% ` Eli Zaretskii
@ 2024-03-25 19:43 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-28 6:24 0% ` Eli Zaretskii
0 siblings, 1 reply; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-03-25 19:43 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 69972
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Joseph Turner <joseph@ushin.org>
>> Cc: 69972@debbugs.gnu.org
>> Date: Sun, 24 Mar 2024 18:06:44 -0700
>>
>> 1. "M-: (scroll-up) RET" (repeatedly)
>> 2. C-v (repeatedly)
>> 3. <wheel-down> (repeatedly)
>>
>> With all three methods, at first Emacs gradually scrolls the image, but
>> then when I reach the bottom of the image, the image disappears entirely
>> as Emacs scrolls past it all at once.
>
> Why is that a problem? The default Emacs scrolling commands don't
> guarantee smooth constant-rate scrolling, they guarantee only that you
> get to see all the portions of the image, without missing any. So
> when you get to the end of the image, there's a heuristic that decides
> whether we can scroll past the image, and that is what you see.
>
> I see no bug here.
With pixel-scroll-precision-mode enabled and at least one character after
the image, I am able to smoothly scroll around the image.
(with-current-buffer (get-buffer-create "*test-scroll-image*")
(erase-buffer)
(insert-image (create-image "splash.png" nil nil :scale 10))
(insert " ") ;; There must be some text after the image
(goto-char (point-min))
(pixel-scroll-precision-mode 1)
(pop-to-buffer (current-buffer)))
However, if the window is scrolled to the right, then it is impossible
to scroll down:
(with-current-buffer (get-buffer-create "*test-scroll-image*")
(erase-buffer)
(insert-image (create-image "splash.png" nil nil :scale 10))
(insert-char 8203)
(goto-char (point-min))
(pixel-scroll-precision-mode 1)
(pop-to-buffer (current-buffer))
(set-window-hscroll (get-buffer-window) 1)) ;; Image scrolled to right
In this buffer, if I attempt to scroll down with the mouse wheel, I
immediately get "End of buffer" error and the image does not move.
Thank you!
Joseph
^ permalink raw reply [relevance 5%]
* bug#70003: 29.2; persist on elpa is missing EDDSA public key
@ 2024-03-25 22:15 1% Xiyue Deng
2024-03-25 22:44 0% ` Xiyue Deng
0 siblings, 1 reply; 200+ results
From: Xiyue Deng @ 2024-03-25 22:15 UTC (permalink / raw)
To: 70003
When preparing the latest persist for Debian packaging, we notice that
one of the EDDSA signing key is missing. The output of the command
Debian uses the check and import the latest version is as follow:
,----
| $ gbp import-orig --uscan
| gbp:info: Launching uscan...
| Newest version of persist-el on remote site is 0.6, local version is 0.5
| (mangled local version is 0.5)
| => Newer package available from:
| => https://elpa.gnu.org/packages/persist-0.6.tar
| gpgv: Signature made Sat 13 Jan 2024 02:05:03 AM PST
| gpgv: using RSA key C433554766D3DDC64221BFAA066DAFCB81E42C40
| gpgv: Good signature from "GNU ELPA Signing Agent (2019) <elpasign@elpa.gnu.org>"
| gpgv: Signature made Sat 13 Jan 2024 02:05:03 AM PST
| gpgv: using EDDSA key 0327BE68D64D9A1A66859F15645357D2883A0966
| gpgv: Can't check signature: No public key
| uscan die: OpenPGP signature did not verify. at /usr/share/perl5/Devscripts/Uscan/Output.pm line 77.
| gbp:error: Uscan failed: OpenPGP signature did not verify.
`----
As the error message shows, the public key of EDDSA key
0327BE68D64D9A1A66859F15645357D2883A0966 is missing.
I have checked with the current persist maintainer Joseph Turner and he
suggested that he was also not aware of the EDDSA key, and suggested
that I should file a bug instead, so here I am :)
Also, as the existing RSA key can successfully verify the file with a
valid signature, I wonder whether the EDDSA is still needed as a
redundant checking.
In GNU Emacs 29.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.38,
cairo version 1.16.0) of 2024-03-18, modified by Debian built on
debian-hx90
System Description: Debian GNU/Linux 12 (bookworm)
Configured using:
'configure --build x86_64-linux-gnu --prefix=/usr
--sharedstatedir=/var/lib --libexecdir=/usr/libexec
--localstatedir=/var/lib --infodir=/usr/share/info
--mandir=/usr/share/man --with-libsystemd --with-pop=yes
--enable-locallisppath=/etc/emacs:/usr/local/share/emacs/29.2/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/29.2/site-lisp:/usr/share/emacs/site-lisp
--with-sound=alsa --without-gconf --with-mailutils
--with-native-compilation --build x86_64-linux-gnu --prefix=/usr
--sharedstatedir=/var/lib --libexecdir=/usr/libexec
--localstatedir=/var/lib --infodir=/usr/share/info
--mandir=/usr/share/man --with-libsystemd --with-pop=yes
--enable-locallisppath=/etc/emacs:/usr/local/share/emacs/29.2/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/29.2/site-lisp:/usr/share/emacs/site-lisp
--with-sound=alsa --without-gconf --with-mailutils
--with-native-compilation --with-cairo --with-x=yes
--with-x-toolkit=gtk3 --with-toolkit-scroll-bars 'CFLAGS=-g -O2
-ffile-prefix-map=/build/emacs-tideTd/emacs-29.2+1=. -fstack-protector-strong
-Wformat -Werror=format-security -Wall' 'CPPFLAGS=-Wdate-time
-D_FORTIFY_SOURCE=2' LDFLAGS=-Wl,-z,relro'
Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES
NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3
THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XDBE XIM XINPUT2
XPM GTK3 ZLIB
Important settings:
value of $LANG: en_US.UTF-8
value of $XMODIFIERS: @im=ibus
locale-coding-system: utf-8-unix
Major mode: Lisp Interaction
Minor modes in effect:
TeX-PDF-mode: t
windmove-mode: t
global-git-commit-mode: t
magit-auto-revert-mode: t
shell-dirtrack-mode: t
rcirc-track-minor-mode: t
server-mode: t
subword-mode: t
bug-reference-prog-mode: t
whitespace-mode: t
yas-minor-mode: t
global-company-mode: t
company-mode: t
global-treesit-auto-mode: t
activities-tabs-mode: t
activities-mode: t
icomplete-mode: t
fido-mode: t
override-global-mode: t
global-display-line-numbers-mode: t
display-line-numbers-mode: t
global-auto-revert-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
tab-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-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:
/usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-section hides /usr/share/emacs/site-lisp/elpa/magit-section-3.3.0/magit-section
/usr/share/emacs/site-lisp/elpa/apache-mode-2.2.0/apache-mode-autoloads hides /usr/share/emacs/site-lisp/elpa-src/apache-mode-2.2.0/apache-mode-autoloads
/usr/share/emacs/site-lisp/elpa/apache-mode-2.2.0/apache-mode-pkg hides /usr/share/emacs/site-lisp/elpa-src/apache-mode-2.2.0/apache-mode-pkg
/usr/share/emacs/site-lisp/elpa/apache-mode-2.2.0/apache-mode hides /usr/share/emacs/site-lisp/elpa-src/apache-mode-2.2.0/apache-mode
/usr/share/emacs/site-lisp/elpa/bison-mode-0.3/bison-mode-pkg hides /usr/share/emacs/site-lisp/elpa-src/bison-mode-0.3/bison-mode-pkg
/usr/share/emacs/site-lisp/elpa/bison-mode-0.3/bison-mode-autoloads hides /usr/share/emacs/site-lisp/elpa-src/bison-mode-0.3/bison-mode-autoloads
/usr/share/emacs/site-lisp/elpa/bison-mode-0.3/bison-mode hides /usr/share/emacs/site-lisp/elpa-src/bison-mode-0.3/bison-mode
/usr/share/emacs/site-lisp/elpa/boxquote-2.3/boxquote hides /usr/share/emacs/site-lisp/elpa-src/boxquote-2.3/boxquote
/usr/share/emacs/site-lisp/elpa/boxquote-2.3/boxquote-autoloads hides /usr/share/emacs/site-lisp/elpa-src/boxquote-2.3/boxquote-autoloads
/usr/share/emacs/site-lisp/elpa/boxquote-2.3/boxquote-pkg hides /usr/share/emacs/site-lisp/elpa-src/boxquote-2.3/boxquote-pkg
/usr/share/emacs/site-lisp/elpa/clojure-mode-5.18.1/clojure-mode-pkg hides /usr/share/emacs/site-lisp/elpa-src/clojure-mode-5.18.1/clojure-mode-pkg
/usr/share/emacs/site-lisp/elpa/clojure-mode-5.18.1/clojure-mode hides /usr/share/emacs/site-lisp/elpa-src/clojure-mode-5.18.1/clojure-mode
/usr/share/emacs/site-lisp/elpa/clojure-mode-5.18.1/clojure-mode-autoloads hides /usr/share/emacs/site-lisp/elpa-src/clojure-mode-5.18.1/clojure-mode-autoloads
/usr/share/emacs/site-lisp/elpa/clojure-mode-extra-font-locking-3.0.0/clojure-mode-extra-font-locking-pkg hides /usr/share/emacs/site-lisp/elpa-src/clojure-mode-extra-font-locking-3.0.0/clojure-mode-extra-font-locking-pkg
/usr/share/emacs/site-lisp/elpa/clojure-mode-extra-font-locking-3.0.0/clojure-mode-extra-font-locking-autoloads hides /usr/share/emacs/site-lisp/elpa-src/clojure-mode-extra-font-locking-3.0.0/clojure-mode-extra-font-locking-autoloads
/usr/share/emacs/site-lisp/elpa/clojure-mode-extra-font-locking-3.0.0/clojure-mode-extra-font-locking hides /usr/share/emacs/site-lisp/elpa-src/clojure-mode-extra-font-locking-3.0.0/clojure-mode-extra-font-locking
/usr/share/emacs/site-lisp/elpa/csv-mode-1.23/csv-mode-autoloads hides /usr/share/emacs/site-lisp/elpa-src/csv-mode-1.23/csv-mode-autoloads
/usr/share/emacs/site-lisp/elpa/csv-mode-1.23/csv-mode hides /usr/share/emacs/site-lisp/elpa-src/csv-mode-1.23/csv-mode
/usr/share/emacs/site-lisp/elpa/csv-mode-1.23/csv-mode-tests hides /usr/share/emacs/site-lisp/elpa-src/csv-mode-1.23/csv-mode-tests
/usr/share/emacs/site-lisp/elpa/csv-mode-1.23/csv-mode-pkg hides /usr/share/emacs/site-lisp/elpa-src/csv-mode-1.23/csv-mode-pkg
/usr/share/emacs/site-lisp/elpa/dash-2.19.1/dash hides /usr/share/emacs/site-lisp/elpa-src/dash-2.19.1/dash
/usr/share/emacs/site-lisp/elpa/dash-2.19.1/dash-pkg hides /usr/share/emacs/site-lisp/elpa-src/dash-2.19.1/dash-pkg
/usr/share/emacs/site-lisp/elpa/dash-2.19.1/dash-autoloads hides /usr/share/emacs/site-lisp/elpa-src/dash-2.19.1/dash-autoloads
/usr/share/emacs/site-lisp/elpa/debian-el-37.11/debian-el-autoloads hides /usr/share/emacs/site-lisp/elpa-src/debian-el-37.11/debian-el-autoloads
/usr/share/emacs/site-lisp/elpa/debian-el-37.11/apt-sources hides /usr/share/emacs/site-lisp/elpa-src/debian-el-37.11/apt-sources
/usr/share/emacs/site-lisp/elpa/debian-el-37.11/debian-bug hides /usr/share/emacs/site-lisp/elpa-src/debian-el-37.11/debian-bug
/usr/share/emacs/site-lisp/elpa/debian-el-37.11/apt-utils hides /usr/share/emacs/site-lisp/elpa-src/debian-el-37.11/apt-utils
/usr/share/emacs/site-lisp/elpa/debian-el-37.11/debian-el-pkg hides /usr/share/emacs/site-lisp/elpa-src/debian-el-37.11/debian-el-pkg
/usr/share/emacs/site-lisp/elpa/debian-el-37.11/gnus-BTS hides /usr/share/emacs/site-lisp/elpa-src/debian-el-37.11/gnus-BTS
/usr/share/emacs/site-lisp/elpa/debian-el-37.11/deb-view hides /usr/share/emacs/site-lisp/elpa-src/debian-el-37.11/deb-view
/usr/share/emacs/site-lisp/elpa/debian-el-37.11/debian-el hides /usr/share/emacs/site-lisp/elpa-src/debian-el-37.11/debian-el
/usr/share/emacs/site-lisp/elpa/debian-el-37.11/preseed hides /usr/share/emacs/site-lisp/elpa-src/debian-el-37.11/preseed
/usr/share/emacs/site-lisp/elpa/debpaste-0.1.5/debpaste hides /usr/share/emacs/site-lisp/elpa-src/debpaste-0.1.5/debpaste
/usr/share/emacs/site-lisp/elpa/debpaste-0.1.5/debpaste-pkg hides /usr/share/emacs/site-lisp/elpa-src/debpaste-0.1.5/debpaste-pkg
/usr/share/emacs/site-lisp/elpa/debpaste-0.1.5/debpaste-autoloads hides /usr/share/emacs/site-lisp/elpa-src/debpaste-0.1.5/debpaste-autoloads
/usr/share/emacs/site-lisp/elpa/devscripts-40/devscripts hides /usr/share/emacs/site-lisp/elpa-src/devscripts-40/devscripts
/usr/share/emacs/site-lisp/elpa/devscripts-40/devscripts-autoloads hides /usr/share/emacs/site-lisp/elpa-src/devscripts-40/devscripts-autoloads
/usr/share/emacs/site-lisp/elpa/devscripts-40/pbuilder-mode hides /usr/share/emacs/site-lisp/elpa-src/devscripts-40/pbuilder-mode
/usr/share/emacs/site-lisp/elpa/devscripts-40/devscripts-pkg hides /usr/share/emacs/site-lisp/elpa-src/devscripts-40/devscripts-pkg
/usr/share/emacs/site-lisp/elpa/devscripts-40/pbuilder-log-view-mode hides /usr/share/emacs/site-lisp/elpa-src/devscripts-40/pbuilder-log-view-mode
/usr/share/emacs/site-lisp/elpa/dockerfile-mode-1.7/dockerfile-mode hides /usr/share/emacs/site-lisp/elpa-src/dockerfile-mode-1.7/dockerfile-mode
/usr/share/emacs/site-lisp/elpa/dockerfile-mode-1.7/dockerfile-mode-autoloads hides /usr/share/emacs/site-lisp/elpa-src/dockerfile-mode-1.7/dockerfile-mode-autoloads
/usr/share/emacs/site-lisp/elpa/dockerfile-mode-1.7/dockerfile-mode-pkg hides /usr/share/emacs/site-lisp/elpa-src/dockerfile-mode-1.7/dockerfile-mode-pkg
/usr/share/emacs/site-lisp/elpa/dpkg-dev-el-37.10/debian-bts-control hides /usr/share/emacs/site-lisp/elpa-src/dpkg-dev-el-37.10/debian-bts-control
/usr/share/emacs/site-lisp/elpa/dpkg-dev-el-37.10/debian-changelog-mode hides /usr/share/emacs/site-lisp/elpa-src/dpkg-dev-el-37.10/debian-changelog-mode
/usr/share/emacs/site-lisp/elpa/dpkg-dev-el-37.10/dpkg-dev-el-autoloads hides /usr/share/emacs/site-lisp/elpa-src/dpkg-dev-el-37.10/dpkg-dev-el-autoloads
/usr/share/emacs/site-lisp/elpa/dpkg-dev-el-37.10/dpkg-dev-el-pkg hides /usr/share/emacs/site-lisp/elpa-src/dpkg-dev-el-37.10/dpkg-dev-el-pkg
/usr/share/emacs/site-lisp/elpa/dpkg-dev-el-37.10/dpkg-dev-el hides /usr/share/emacs/site-lisp/elpa-src/dpkg-dev-el-37.10/dpkg-dev-el
/usr/share/emacs/site-lisp/elpa/dpkg-dev-el-37.10/debian-control-mode hides /usr/share/emacs/site-lisp/elpa-src/dpkg-dev-el-37.10/debian-control-mode
/usr/share/emacs/site-lisp/elpa/dpkg-dev-el-37.10/debian-copyright hides /usr/share/emacs/site-lisp/elpa-src/dpkg-dev-el-37.10/debian-copyright
/usr/share/emacs/site-lisp/elpa/dpkg-dev-el-37.10/readme-debian hides /usr/share/emacs/site-lisp/elpa-src/dpkg-dev-el-37.10/readme-debian
/usr/share/emacs/site-lisp/elpa/git-commit-3.3.0/git-commit hides /usr/share/emacs/site-lisp/elpa-src/git-commit-3.3.0/git-commit
/usr/share/emacs/site-lisp/elpa/git-commit-3.3.0/git-commit-autoloads hides /usr/share/emacs/site-lisp/elpa-src/git-commit-3.3.0/git-commit-autoloads
/usr/share/emacs/site-lisp/elpa/git-commit-3.3.0/git-commit-pkg hides /usr/share/emacs/site-lisp/elpa-src/git-commit-3.3.0/git-commit-pkg
/usr/share/emacs/site-lisp/elpa/gnuplot-0.8.1/gnuplot hides /usr/share/emacs/site-lisp/elpa-src/gnuplot-0.8.1/gnuplot
/usr/share/emacs/site-lisp/elpa/gnuplot-0.8.1/gnuplot-autoloads hides /usr/share/emacs/site-lisp/elpa-src/gnuplot-0.8.1/gnuplot-autoloads
/usr/share/emacs/site-lisp/elpa/gnuplot-0.8.1/debian-autoloads hides /usr/share/emacs/site-lisp/elpa-src/gnuplot-0.8.1/debian-autoloads
/usr/share/emacs/site-lisp/elpa/gnuplot-0.8.1/gnuplot-pkg hides /usr/share/emacs/site-lisp/elpa-src/gnuplot-0.8.1/gnuplot-pkg
/usr/share/emacs/site-lisp/elpa/gnuplot-0.8.1/gnuplot-context hides /usr/share/emacs/site-lisp/elpa-src/gnuplot-0.8.1/gnuplot-context
/usr/share/emacs/site-lisp/elpa/gnuplot-0.8.1/gnuplot-gui hides /usr/share/emacs/site-lisp/elpa-src/gnuplot-0.8.1/gnuplot-gui
/usr/share/emacs/site-lisp/elpa/go-mode-1.6.0/go-mode hides /usr/share/emacs/site-lisp/elpa-src/go-mode-1.6.0/go-mode
/usr/share/emacs/site-lisp/elpa/go-mode-1.6.0/go-guru hides /usr/share/emacs/site-lisp/elpa-src/go-mode-1.6.0/go-guru
/usr/share/emacs/site-lisp/elpa/go-mode-1.6.0/go-mode-pkg hides /usr/share/emacs/site-lisp/elpa-src/go-mode-1.6.0/go-mode-pkg
/usr/share/emacs/site-lisp/elpa/go-mode-1.6.0/go-mode-autoloads hides /usr/share/emacs/site-lisp/elpa-src/go-mode-1.6.0/go-mode-autoloads
/usr/share/emacs/site-lisp/elpa/go-mode-1.6.0/go-rename hides /usr/share/emacs/site-lisp/elpa-src/go-mode-1.6.0/go-rename
/usr/share/emacs/site-lisp/elpa/graphviz-dot-mode-0.4.2/graphviz-dot-mode-autoloads hides /usr/share/emacs/site-lisp/elpa-src/graphviz-dot-mode-0.4.2/graphviz-dot-mode-autoloads
/usr/share/emacs/site-lisp/elpa/graphviz-dot-mode-0.4.2/company-graphviz-dot hides /usr/share/emacs/site-lisp/elpa-src/graphviz-dot-mode-0.4.2/company-graphviz-dot
/usr/share/emacs/site-lisp/elpa/graphviz-dot-mode-0.4.2/graphviz-dot-mode-pkg hides /usr/share/emacs/site-lisp/elpa-src/graphviz-dot-mode-0.4.2/graphviz-dot-mode-pkg
/usr/share/emacs/site-lisp/elpa/graphviz-dot-mode-0.4.2/graphviz-dot-mode hides /usr/share/emacs/site-lisp/elpa-src/graphviz-dot-mode-0.4.2/graphviz-dot-mode
/usr/share/emacs/site-lisp/elpa/lintian-0.1/lintian-pkg hides /usr/share/emacs/site-lisp/elpa-src/lintian-0.1/lintian-pkg
/usr/share/emacs/site-lisp/elpa/lintian-0.1/lintian-autoloads hides /usr/share/emacs/site-lisp/elpa-src/lintian-0.1/lintian-autoloads
/usr/share/emacs/site-lisp/elpa/lintian-0.1/lintian hides /usr/share/emacs/site-lisp/elpa-src/lintian-0.1/lintian
/usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-remote hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-remote
/usr/share/emacs/site-lisp/elpa/magit-3.3.0/git-rebase hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/git-rebase
/usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-bisect hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-bisect
/usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-margin hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-margin
/usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-merge hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-merge
/usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-section hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-section
/usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-patch hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-patch
/usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-commit hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-commit
/usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-autoloads hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-autoloads
/usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-files hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-files
/usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-stash hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-stash
/usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-bookmark hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-bookmark
/usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-submodule hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-submodule
/usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-apply hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-apply
/usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-repos hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-repos
/usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-core hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-core
/usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-subtree hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-subtree
/usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-autorevert hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-autorevert
/usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-gitignore hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-gitignore
/usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-transient hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-transient
/usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-extras hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-extras
/usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-git hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-git
/usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-notes hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-notes
/usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-reflog hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-reflog
/usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-mode hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-mode
/usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-push hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-push
/usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-tag hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-tag
/usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-process hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-process
/usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-ediff hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-ediff
/usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit
/usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-imenu hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-imenu
/usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-diff hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-diff
/usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-clone hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-clone
/usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-log hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-log
/usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-utils hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-utils
/usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-wip hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-wip
/usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-branch hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-branch
/usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-pull hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-pull
/usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-reset hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-reset
/usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-sequence hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-sequence
/usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-status hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-status
/usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-refs hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-refs
/usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-obsolete hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-obsolete
/usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-fetch hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-fetch
/usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-worktree hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-worktree
/usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-blame hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-blame
/usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-pkg hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-pkg
/usr/share/emacs/site-lisp/elpa/magit-section-3.3.0/magit-section-autoloads hides /usr/share/emacs/site-lisp/elpa-src/magit-section-3.3.0/magit-section-autoloads
/usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-section hides /usr/share/emacs/site-lisp/elpa-src/magit-section-3.3.0/magit-section
/usr/share/emacs/site-lisp/elpa/magit-section-3.3.0/magit-section-pkg hides /usr/share/emacs/site-lisp/elpa-src/magit-section-3.3.0/magit-section-pkg
/usr/share/emacs/site-lisp/elpa/matlab-mode-4.0/matlab-cgen hides /usr/share/emacs/site-lisp/elpa-src/matlab-mode-4.0/matlab-cgen
/usr/share/emacs/site-lisp/elpa/matlab-mode-4.0/matlab-scan hides /usr/share/emacs/site-lisp/elpa-src/matlab-mode-4.0/matlab-scan
/usr/share/emacs/site-lisp/elpa/matlab-mode-4.0/matlab-publish hides /usr/share/emacs/site-lisp/elpa-src/matlab-mode-4.0/matlab-publish
/usr/share/emacs/site-lisp/elpa/matlab-mode-4.0/matlab hides /usr/share/emacs/site-lisp/elpa-src/matlab-mode-4.0/matlab
/usr/share/emacs/site-lisp/elpa/matlab-mode-4.0/matlab-complete hides /usr/share/emacs/site-lisp/elpa-src/matlab-mode-4.0/matlab-complete
/usr/share/emacs/site-lisp/elpa/matlab-mode-4.0/matlab-syntax hides /usr/share/emacs/site-lisp/elpa-src/matlab-mode-4.0/matlab-syntax
/usr/share/emacs/site-lisp/elpa/matlab-mode-4.0/tlc hides /usr/share/emacs/site-lisp/elpa-src/matlab-mode-4.0/tlc
/usr/share/emacs/site-lisp/elpa/matlab-mode-4.0/matlab-netshell hides /usr/share/emacs/site-lisp/elpa-src/matlab-mode-4.0/matlab-netshell
/usr/share/emacs/site-lisp/elpa/matlab-mode-4.0/semantic-matlab hides /usr/share/emacs/site-lisp/elpa-src/matlab-mode-4.0/semantic-matlab
/usr/share/emacs/site-lisp/elpa/matlab-mode-4.0/mlint hides /usr/share/emacs/site-lisp/elpa-src/matlab-mode-4.0/mlint
/usr/share/emacs/site-lisp/elpa/matlab-mode-4.0/company-matlab-shell hides /usr/share/emacs/site-lisp/elpa-src/matlab-mode-4.0/company-matlab-shell
/usr/share/emacs/site-lisp/elpa/matlab-mode-4.0/matlab-shell-gud hides /usr/share/emacs/site-lisp/elpa-src/matlab-mode-4.0/matlab-shell-gud
/usr/share/emacs/site-lisp/elpa/matlab-mode-4.0/mlgud hides /usr/share/emacs/site-lisp/elpa-src/matlab-mode-4.0/mlgud
/usr/share/emacs/site-lisp/elpa/matlab-mode-4.0/srecode-matlab hides /usr/share/emacs/site-lisp/elpa-src/matlab-mode-4.0/srecode-matlab
/usr/share/emacs/site-lisp/elpa/matlab-mode-4.0/matlab-compat hides /usr/share/emacs/site-lisp/elpa-src/matlab-mode-4.0/matlab-compat
/usr/share/emacs/site-lisp/elpa/matlab-mode-4.0/matlab-mode-pkg hides /usr/share/emacs/site-lisp/elpa-src/matlab-mode-4.0/matlab-mode-pkg
/usr/share/emacs/site-lisp/elpa/matlab-mode-4.0/matlab-maint hides /usr/share/emacs/site-lisp/elpa-src/matlab-mode-4.0/matlab-maint
/usr/share/emacs/site-lisp/elpa/matlab-mode-4.0/cedet-matlab hides /usr/share/emacs/site-lisp/elpa-src/matlab-mode-4.0/cedet-matlab
/usr/share/emacs/site-lisp/elpa/matlab-mode-4.0/matlab-topic hides /usr/share/emacs/site-lisp/elpa-src/matlab-mode-4.0/matlab-topic
/usr/share/emacs/site-lisp/elpa/matlab-mode-4.0/linemark hides /usr/share/emacs/site-lisp/elpa-src/matlab-mode-4.0/linemark
/usr/share/emacs/site-lisp/elpa/matlab-mode-4.0/matlab-shell hides /usr/share/emacs/site-lisp/elpa-src/matlab-mode-4.0/matlab-shell
/usr/share/emacs/site-lisp/elpa/matlab-mode-4.0/semanticdb-matlab hides /usr/share/emacs/site-lisp/elpa-src/matlab-mode-4.0/semanticdb-matlab
/usr/share/emacs/site-lisp/elpa/matlab-mode-4.0/matlab-load hides /usr/share/emacs/site-lisp/elpa-src/matlab-mode-4.0/matlab-load
/usr/share/emacs/site-lisp/elpa/matlab-mode-4.0/matlab-mode-autoloads hides /usr/share/emacs/site-lisp/elpa-src/matlab-mode-4.0/matlab-mode-autoloads
/usr/share/emacs/site-lisp/elpa/meson-mode-0.2/meson-mode hides /usr/share/emacs/site-lisp/elpa-src/meson-mode-0.2/meson-mode
/usr/share/emacs/site-lisp/elpa/meson-mode-0.2/utils hides /usr/share/emacs/site-lisp/elpa-src/meson-mode-0.2/utils
/usr/share/emacs/site-lisp/elpa/meson-mode-0.2/meson-mode-autoloads hides /usr/share/emacs/site-lisp/elpa-src/meson-mode-0.2/meson-mode-autoloads
/usr/share/emacs/site-lisp/elpa/meson-mode-0.2/meson-mode-pkg hides /usr/share/emacs/site-lisp/elpa-src/meson-mode-0.2/meson-mode-pkg
/usr/share/emacs/site-lisp/elpa/nginx-mode-1.1.9/nginx-mode-autoloads hides /usr/share/emacs/site-lisp/elpa-src/nginx-mode-1.1.9/nginx-mode-autoloads
/usr/share/emacs/site-lisp/elpa/nginx-mode-1.1.9/nginx-mode-pkg hides /usr/share/emacs/site-lisp/elpa-src/nginx-mode-1.1.9/nginx-mode-pkg
/usr/share/emacs/site-lisp/elpa/nginx-mode-1.1.9/nginx-mode hides /usr/share/emacs/site-lisp/elpa-src/nginx-mode-1.1.9/nginx-mode
/usr/share/emacs/site-lisp/elpa/paredit-26/paredit-autoloads hides /usr/share/emacs/site-lisp/elpa-src/paredit-26/paredit-autoloads
/usr/share/emacs/site-lisp/elpa/paredit-26/paredit-pkg hides /usr/share/emacs/site-lisp/elpa-src/paredit-26/paredit-pkg
/usr/share/emacs/site-lisp/elpa/paredit-26/paredit hides /usr/share/emacs/site-lisp/elpa-src/paredit-26/paredit
/usr/share/emacs/site-lisp/elpa/po-mode-0.21/po-mode-pkg hides /usr/share/emacs/site-lisp/elpa-src/po-mode-0.21/po-mode-pkg
/usr/share/emacs/site-lisp/elpa/po-mode-0.21/po-mode-autoloads hides /usr/share/emacs/site-lisp/elpa-src/po-mode-0.21/po-mode-autoloads
/usr/share/emacs/site-lisp/elpa/po-mode-0.21/po-mode hides /usr/share/emacs/site-lisp/elpa-src/po-mode-0.21/po-mode
/usr/share/emacs/site-lisp/elpa/py-isort-2016.1/py-isort hides /usr/share/emacs/site-lisp/elpa-src/py-isort-2016.1/py-isort
/usr/share/emacs/site-lisp/elpa/py-isort-2016.1/py-isort-autoloads hides /usr/share/emacs/site-lisp/elpa-src/py-isort-2016.1/py-isort-autoloads
/usr/share/emacs/site-lisp/elpa/py-isort-2016.1/py-isort-pkg hides /usr/share/emacs/site-lisp/elpa-src/py-isort-2016.1/py-isort-pkg
/usr/share/emacs/site-lisp/elpa/pyvenv-1.21/pyvenv hides /usr/share/emacs/site-lisp/elpa-src/pyvenv-1.21/pyvenv
/usr/share/emacs/site-lisp/elpa/pyvenv-1.21/pyvenv-pkg hides /usr/share/emacs/site-lisp/elpa-src/pyvenv-1.21/pyvenv-pkg
/usr/share/emacs/site-lisp/elpa/pyvenv-1.21/pyvenv-autoloads hides /usr/share/emacs/site-lisp/elpa-src/pyvenv-1.21/pyvenv-autoloads
/usr/share/emacs/site-lisp/elpa/rust-mode-1.0.5/rust-common hides /usr/share/emacs/site-lisp/elpa-src/rust-mode-1.0.5/rust-common
/usr/share/emacs/site-lisp/elpa/rust-mode-1.0.5/rust-mode-tests hides /usr/share/emacs/site-lisp/elpa-src/rust-mode-1.0.5/rust-mode-tests
/usr/share/emacs/site-lisp/elpa/rust-mode-1.0.5/rust-mode-treesitter hides /usr/share/emacs/site-lisp/elpa-src/rust-mode-1.0.5/rust-mode-treesitter
/usr/share/emacs/site-lisp/elpa/rust-mode-1.0.5/rust-cargo hides /usr/share/emacs/site-lisp/elpa-src/rust-mode-1.0.5/rust-cargo
/usr/share/emacs/site-lisp/elpa/rust-mode-1.0.5/rust-mode-autoloads hides /usr/share/emacs/site-lisp/elpa-src/rust-mode-1.0.5/rust-mode-autoloads
/usr/share/emacs/site-lisp/elpa/rust-mode-1.0.5/rust-utils hides /usr/share/emacs/site-lisp/elpa-src/rust-mode-1.0.5/rust-utils
/usr/share/emacs/site-lisp/elpa/rust-mode-1.0.5/rust-rustfmt hides /usr/share/emacs/site-lisp/elpa-src/rust-mode-1.0.5/rust-rustfmt
/usr/share/emacs/site-lisp/elpa/rust-mode-1.0.5/rust-mode hides /usr/share/emacs/site-lisp/elpa-src/rust-mode-1.0.5/rust-mode
/usr/share/emacs/site-lisp/elpa/rust-mode-1.0.5/rust-playpen hides /usr/share/emacs/site-lisp/elpa-src/rust-mode-1.0.5/rust-playpen
/usr/share/emacs/site-lisp/elpa/rust-mode-1.0.5/rust-prog-mode hides /usr/share/emacs/site-lisp/elpa-src/rust-mode-1.0.5/rust-prog-mode
/usr/share/emacs/site-lisp/elpa/rust-mode-1.0.5/rust-mode-pkg hides /usr/share/emacs/site-lisp/elpa-src/rust-mode-1.0.5/rust-mode-pkg
/usr/share/emacs/site-lisp/elpa/rust-mode-1.0.5/rust-compile hides /usr/share/emacs/site-lisp/elpa-src/rust-mode-1.0.5/rust-compile
/usr/share/emacs/site-lisp/elpa/scala-mode-1.1.0/scala-mode-map hides /usr/share/emacs/site-lisp/elpa-src/scala-mode-1.1.0/scala-mode-map
/usr/share/emacs/site-lisp/elpa/scala-mode-1.1.0/scala-mode-indent hides /usr/share/emacs/site-lisp/elpa-src/scala-mode-1.1.0/scala-mode-indent
/usr/share/emacs/site-lisp/elpa/scala-mode-1.1.0/scala-mode-syntax hides /usr/share/emacs/site-lisp/elpa-src/scala-mode-1.1.0/scala-mode-syntax
/usr/share/emacs/site-lisp/elpa/scala-mode-1.1.0/scala-mode-lib hides /usr/share/emacs/site-lisp/elpa-src/scala-mode-1.1.0/scala-mode-lib
/usr/share/emacs/site-lisp/elpa/scala-mode-1.1.0/scala-mode-pkg hides /usr/share/emacs/site-lisp/elpa-src/scala-mode-1.1.0/scala-mode-pkg
/usr/share/emacs/site-lisp/elpa/scala-mode-1.1.0/scala-mode-prettify-symbols hides /usr/share/emacs/site-lisp/elpa-src/scala-mode-1.1.0/scala-mode-prettify-symbols
/usr/share/emacs/site-lisp/elpa/scala-mode-1.1.0/scala-compile hides /usr/share/emacs/site-lisp/elpa-src/scala-mode-1.1.0/scala-compile
/usr/share/emacs/site-lisp/elpa/scala-mode-1.1.0/scala-mode hides /usr/share/emacs/site-lisp/elpa-src/scala-mode-1.1.0/scala-mode
/usr/share/emacs/site-lisp/elpa/scala-mode-1.1.0/scala-organise hides /usr/share/emacs/site-lisp/elpa-src/scala-mode-1.1.0/scala-organise
/usr/share/emacs/site-lisp/elpa/scala-mode-1.1.0/scala-mode-autoloads hides /usr/share/emacs/site-lisp/elpa-src/scala-mode-1.1.0/scala-mode-autoloads
/usr/share/emacs/site-lisp/elpa/scala-mode-1.1.0/scala-mode-paragraph hides /usr/share/emacs/site-lisp/elpa-src/scala-mode-1.1.0/scala-mode-paragraph
/usr/share/emacs/site-lisp/elpa/scala-mode-1.1.0/scala-mode-imenu hides /usr/share/emacs/site-lisp/elpa-src/scala-mode-1.1.0/scala-mode-imenu
/usr/share/emacs/site-lisp/elpa/scala-mode-1.1.0/scala-mode-fontlock hides /usr/share/emacs/site-lisp/elpa-src/scala-mode-1.1.0/scala-mode-fontlock
/usr/share/emacs/site-lisp/elpa/vterm-0.0.2/vterm-load-path hides /usr/share/emacs/site-lisp/elpa-src/vterm-0.0.2/vterm-load-path
/usr/share/emacs/site-lisp/elpa/vterm-0.0.2/vterm hides /usr/share/emacs/site-lisp/elpa-src/vterm-0.0.2/vterm
/usr/share/emacs/site-lisp/elpa/vterm-0.0.2/vterm-pkg hides /usr/share/emacs/site-lisp/elpa-src/vterm-0.0.2/vterm-pkg
/usr/share/emacs/site-lisp/elpa/vterm-0.0.2/vterm-autoloads hides /usr/share/emacs/site-lisp/elpa-src/vterm-0.0.2/vterm-autoloads
/usr/share/emacs/site-lisp/elpa/with-editor-3.0.5/with-editor-pkg hides /usr/share/emacs/site-lisp/elpa-src/with-editor-3.0.5/with-editor-pkg
/usr/share/emacs/site-lisp/elpa/with-editor-3.0.5/with-editor-autoloads hides /usr/share/emacs/site-lisp/elpa-src/with-editor-3.0.5/with-editor-autoloads
/usr/share/emacs/site-lisp/elpa/with-editor-3.0.5/with-editor hides /usr/share/emacs/site-lisp/elpa-src/with-editor-3.0.5/with-editor
/usr/share/emacs/site-lisp/elpa/xml-rpc-1.6.17/xml-rpc hides /usr/share/emacs/site-lisp/elpa-src/xml-rpc-1.6.17/xml-rpc
/usr/share/emacs/site-lisp/elpa/xml-rpc-1.6.17/xml-rpc-pkg hides /usr/share/emacs/site-lisp/elpa-src/xml-rpc-1.6.17/xml-rpc-pkg
/usr/share/emacs/site-lisp/elpa/xml-rpc-1.6.17/xml-rpc-autoloads hides /usr/share/emacs/site-lisp/elpa-src/xml-rpc-1.6.17/xml-rpc-autoloads
/usr/share/emacs/site-lisp/elpa/yaml-mode-0.0.16/yaml-mode-pkg hides /usr/share/emacs/site-lisp/elpa-src/yaml-mode-0.0.16/yaml-mode-pkg
/usr/share/emacs/site-lisp/elpa/yaml-mode-0.0.16/yaml-mode hides /usr/share/emacs/site-lisp/elpa-src/yaml-mode-0.0.16/yaml-mode
/usr/share/emacs/site-lisp/elpa/yaml-mode-0.0.16/yaml-mode-autoloads hides /usr/share/emacs/site-lisp/elpa-src/yaml-mode-0.0.16/yaml-mode-autoloads
/usr/share/emacs/site-lisp/elpa/yasnippet-0.14.1/yasnippet-autoloads hides /usr/share/emacs/site-lisp/elpa-src/yasnippet-0.14.1/yasnippet-autoloads
/usr/share/emacs/site-lisp/elpa/yasnippet-0.14.1/yasnippet-pkg hides /usr/share/emacs/site-lisp/elpa-src/yasnippet-0.14.1/yasnippet-pkg
/usr/share/emacs/site-lisp/elpa/yasnippet-0.14.1/yasnippet hides /usr/share/emacs/site-lisp/elpa-src/yasnippet-0.14.1/yasnippet
/usr/share/emacs/site-lisp/elpa/yasnippet-snippets-20220713/yasnippet-snippets hides /usr/share/emacs/site-lisp/elpa-src/yasnippet-snippets-20220713/yasnippet-snippets
/usr/share/emacs/site-lisp/elpa/yasnippet-snippets-20220713/yasnippet-snippets-pkg hides /usr/share/emacs/site-lisp/elpa-src/yasnippet-snippets-20220713/yasnippet-snippets-pkg
/usr/share/emacs/site-lisp/elpa/yasnippet-snippets-20220713/yasnippet-snippets-autoloads hides /usr/share/emacs/site-lisp/elpa-src/yasnippet-snippets-20220713/yasnippet-snippets-autoloads
/usr/share/emacs/site-lisp/elpa/zenburn-theme-2.8.0/zenburn-theme hides /usr/share/emacs/site-lisp/elpa-src/zenburn-theme-2.8.0/zenburn-theme
/usr/share/emacs/site-lisp/elpa/zenburn-theme-2.8.0/zenburn-theme-pkg hides /usr/share/emacs/site-lisp/elpa-src/zenburn-theme-2.8.0/zenburn-theme-pkg
/usr/share/emacs/site-lisp/elpa/zenburn-theme-2.8.0/zenburn-theme-autoloads hides /usr/share/emacs/site-lisp/elpa-src/zenburn-theme-2.8.0/zenburn-theme-autoloads
Features:
(shadow emacsbug org-element org-persist org-id org-refile avl-tree
oc-basic ol-eww ol-rmail ol-mhe ol-irc ol-info ol-gnus nnselect
ol-docview doc-view image-mode exif ol-bibtex bibtex ol-bbdb ol-w3m
ol-doi org-link-doi org ob ob-tangle ob-ref ob-lob ob-table ob-exp
org-macro org-src ob-comint org-pcomplete org-list org-footnote
org-faces org-entities ob-emacs-lisp ob-core ob-eval org-cycle org-table
ol org-fold org-fold-core org-keys oc org-loaddefs cal-menu calendar
cal-loaddefs org-version org-compat org-macs clojure-mode align noutline
outline checkdoc lisp-mnt debpaste xml-rpc boxquote reporter mhtml-mode
css-mode eww xdg mm-url js c-ts-common cc-mode cc-fonts cc-guess
cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs sgml-mode
facemenu sh-script smie executable make-mode view deb-view tar-mode
arc-mode archive-mode magit-patch magit-subtree magit-ediff ediff
ediff-merg ediff-mult ediff-wind ediff-diff ediff-help ediff-init
ediff-util rect tex-info texinfo texinfo-loaddefs tex texmathp
git-rebase perl-mode find-dired ffap grep debian-control-mode debian-bug
mailalias macros vterm tramp tramp-loaddefs trampver tramp-integration
files-x tramp-compat term ehelp vterm-module magit-gitignore shortdoc
help-fns radix-tree misearch multi-isearch eglot external-completion
array jsonrpc ert ewoc debug backtrace find-func shr-color url-http
url-gw url-auth url-queue url-cache debian-copyright
debian-changelog-mode qp flow-fill conf-mode matlab matlab-scan
matlab-syntax matlab-compat pulse color windmove goto-addr magit-extras
face-remap magit-bookmark magit-submodule magit-obsolete magit-blame
magit-stash magit-reflog magit-bisect magit-push magit-pull magit-fetch
magit-clone magit-remote magit-commit magit-sequence magit-notes
magit-worktree magit-tag magit-merge magit-branch magit-reset
magit-files magit-refs magit-status magit magit-repos magit-apply
magit-wip magit-log which-func imenu magit-diff smerge-mode diff
git-commit log-edit add-log magit-core magit-autorevert magit-margin
magit-transient magit-process with-editor shell pcomplete magit-mode
transient format-spec magit-git magit-section magit-utils crm dash
dired-aux sort gnus-cite mm-archive mail-extr textsec uni-scripts
idna-mapping ucs-normalize uni-confusable textsec-check gnus-async
gnus-bcklg gnus-ml mule-util jka-compr gnus-topic cursor-sensor utf-7
nnfolder gnus-demon nnml ezgnus gnus-delay gnus-draft gnus-agent
gnus-srvr gnus-score score-mode nnvirtual nntp gnus-cache gnus-msg
gnus-art mm-uu mml2015 mm-view mml-smime smime dig gnus-sum shr
pixel-fill kinsoku url-file svg dom nndraft nnmh gnus-group gnus-undo
smtpmail gnus-start gnus-dbus dbus xml gnus-cloud nnimap nnmail
mail-source utf7 nnoo gnus-spec gnus-int gnus-range message sendmail
yank-media dired dired-loaddefs 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 flyspell ispell gnutls network-stream puny nsm
epa-file epa derived epg rfc6068 epg-config rcirc parse-time iso8601
time-date term/xterm xterm comp comp-cstr rx server cap-words superword
subword vc-hg vc-git diff-mode vc-bzr vc-src vc-sccs vc-svn vc-cvs
vc-rcs log-view pcvs-util vc vc-dispatcher bug-reference disp-table
whitespace yasnippet-snippets yasnippet cus-edit cus-start wid-edit
company-oddmuse company-keywords company-etags etags fileloop generator
xref company-gtags company-dabbrev-code company-dabbrev company-files
company-clang company-capf company-cmake company-semantic
company-template company-bbdb company pcase init zenburn-theme
treesit-auto treesit keychain-environment exec-path-from-shell
activities-tabs activities persist bookmark pp edmacro kmacro advice
icomplete cus-load flymake-proc flymake project compile
text-property-search comint ansi-osc ansi-color ring warnings icons
thingatpt cl-extra help-mode use-package use-package-ensure
use-package-delight use-package-diminish use-package-bind-key bind-key
easy-mmode use-package-core display-line-numbers autorevert filenotify
activities-autoloads auctex-autoloads tex-site cargo-autoloads
company-autoloads dart-mode-autoloads exec-path-from-shell-autoloads
format-all-autoloads git-modes-autoloads compat-autoloads
inheritenv-autoloads keychain-environment-autoloads
language-id-autoloads persist-autoloads treesit-auto-autoloads
xclip-autoloads info finder-inf package browse-url url url-proxy
url-privacy url-expand url-methods url-history url-cookie
generate-lisp-file url-domsuf url-util mailcap url-handlers url-parse
auth-source cl-seq eieio eieio-core cl-macs password-cache json subr-x
map byte-opt gv bytecomp byte-compile url-vars cl-loaddefs cl-lib rmc
iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook
vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode lisp-mode prog-mode register
page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer nadvice seq simple cl-generic indonesian philippine
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads dbusbind inotify lcms2 dynamic-setting system-font-setting
font-render-setting cairo move-toolbar gtk x-toolkit xinput2 x multi-tty
make-network-process native-compile emacs)
Memory information:
((conses 16 3624587 210142)
(symbols 48 51570 65)
(strings 32 295699 33738)
(string-bytes 1 9403400)
(vectors 16 192036)
(vector-slots 8 4207835 141052)
(floats 8 1294 9458)
(intervals 56 179453 3660)
(buffers 984 210))
^ permalink raw reply [relevance 1%]
* bug#70003: 29.2; persist on elpa is missing EDDSA public key
2024-03-25 22:15 1% bug#70003: 29.2; persist on elpa is missing EDDSA public key Xiyue Deng
@ 2024-03-25 22:44 0% ` Xiyue Deng
0 siblings, 0 replies; 200+ results
From: Xiyue Deng @ 2024-03-25 22:44 UTC (permalink / raw)
To: 70003; +Cc: Joseph Turner
Xiyue Deng <manphiz@gmail.com> writes:
> When preparing the latest persist for Debian packaging, we notice that
> one of the EDDSA signing key is missing. The output of the command
> Debian uses the check and import the latest version is as follow:
>
> ,----
> | $ gbp import-orig --uscan
> | gbp:info: Launching uscan...
> | Newest version of persist-el on remote site is 0.6, local version is 0.5
> | (mangled local version is 0.5)
> | => Newer package available from:
> | => https://elpa.gnu.org/packages/persist-0.6.tar
> | gpgv: Signature made Sat 13 Jan 2024 02:05:03 AM PST
> | gpgv: using RSA key C433554766D3DDC64221BFAA066DAFCB81E42C40
> | gpgv: Good signature from "GNU ELPA Signing Agent (2019) <elpasign@elpa.gnu.org>"
> | gpgv: Signature made Sat 13 Jan 2024 02:05:03 AM PST
> | gpgv: using EDDSA key 0327BE68D64D9A1A66859F15645357D2883A0966
> | gpgv: Can't check signature: No public key
> | uscan die: OpenPGP signature did not verify. at /usr/share/perl5/Devscripts/Uscan/Output.pm line 77.
> | gbp:error: Uscan failed: OpenPGP signature did not verify.
> `----
>
> As the error message shows, the public key of EDDSA key
> 0327BE68D64D9A1A66859F15645357D2883A0966 is missing.
>
> I have checked with the current persist maintainer Joseph Turner and he
> suggested that he was also not aware of the EDDSA key, and suggested
> that I should file a bug instead, so here I am :)
>
> Also, as the existing RSA key can successfully verify the file with a
> valid signature, I wonder whether the EDDSA is still needed as a
> redundant checking.
>
CCing Joseph as per his request.
>
>
> In GNU Emacs 29.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.38,
> cairo version 1.16.0) of 2024-03-18, modified by Debian built on
> debian-hx90
> System Description: Debian GNU/Linux 12 (bookworm)
>
> Configured using:
> 'configure --build x86_64-linux-gnu --prefix=/usr
> --sharedstatedir=/var/lib --libexecdir=/usr/libexec
> --localstatedir=/var/lib --infodir=/usr/share/info
> --mandir=/usr/share/man --with-libsystemd --with-pop=yes
> --enable-locallisppath=/etc/emacs:/usr/local/share/emacs/29.2/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/29.2/site-lisp:/usr/share/emacs/site-lisp
> --with-sound=alsa --without-gconf --with-mailutils
> --with-native-compilation --build x86_64-linux-gnu --prefix=/usr
> --sharedstatedir=/var/lib --libexecdir=/usr/libexec
> --localstatedir=/var/lib --infodir=/usr/share/info
> --mandir=/usr/share/man --with-libsystemd --with-pop=yes
> --enable-locallisppath=/etc/emacs:/usr/local/share/emacs/29.2/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/29.2/site-lisp:/usr/share/emacs/site-lisp
> --with-sound=alsa --without-gconf --with-mailutils
> --with-native-compilation --with-cairo --with-x=yes
> --with-x-toolkit=gtk3 --with-toolkit-scroll-bars 'CFLAGS=-g -O2
> -ffile-prefix-map=/build/emacs-tideTd/emacs-29.2+1=. -fstack-protector-strong
> -Wformat -Werror=format-security -Wall' 'CPPFLAGS=-Wdate-time
> -D_FORTIFY_SOURCE=2' LDFLAGS=-Wl,-z,relro'
>
> Configured features:
> ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
> JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES
> NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3
> THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XDBE XIM XINPUT2
> XPM GTK3 ZLIB
>
> Important settings:
> value of $LANG: en_US.UTF-8
> value of $XMODIFIERS: @im=ibus
> locale-coding-system: utf-8-unix
>
> Major mode: Lisp Interaction
>
> Minor modes in effect:
> TeX-PDF-mode: t
> windmove-mode: t
> global-git-commit-mode: t
> magit-auto-revert-mode: t
> shell-dirtrack-mode: t
> rcirc-track-minor-mode: t
> server-mode: t
> subword-mode: t
> bug-reference-prog-mode: t
> whitespace-mode: t
> yas-minor-mode: t
> global-company-mode: t
> company-mode: t
> global-treesit-auto-mode: t
> activities-tabs-mode: t
> activities-mode: t
> icomplete-mode: t
> fido-mode: t
> override-global-mode: t
> global-display-line-numbers-mode: t
> display-line-numbers-mode: t
> global-auto-revert-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
> tab-bar-mode: t
> file-name-shadow-mode: t
> global-font-lock-mode: t
> font-lock-mode: t
> blink-cursor-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:
> /usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-section hides /usr/share/emacs/site-lisp/elpa/magit-section-3.3.0/magit-section
> /usr/share/emacs/site-lisp/elpa/apache-mode-2.2.0/apache-mode-autoloads hides /usr/share/emacs/site-lisp/elpa-src/apache-mode-2.2.0/apache-mode-autoloads
> /usr/share/emacs/site-lisp/elpa/apache-mode-2.2.0/apache-mode-pkg hides /usr/share/emacs/site-lisp/elpa-src/apache-mode-2.2.0/apache-mode-pkg
> /usr/share/emacs/site-lisp/elpa/apache-mode-2.2.0/apache-mode hides /usr/share/emacs/site-lisp/elpa-src/apache-mode-2.2.0/apache-mode
> /usr/share/emacs/site-lisp/elpa/bison-mode-0.3/bison-mode-pkg hides /usr/share/emacs/site-lisp/elpa-src/bison-mode-0.3/bison-mode-pkg
> /usr/share/emacs/site-lisp/elpa/bison-mode-0.3/bison-mode-autoloads hides /usr/share/emacs/site-lisp/elpa-src/bison-mode-0.3/bison-mode-autoloads
> /usr/share/emacs/site-lisp/elpa/bison-mode-0.3/bison-mode hides /usr/share/emacs/site-lisp/elpa-src/bison-mode-0.3/bison-mode
> /usr/share/emacs/site-lisp/elpa/boxquote-2.3/boxquote hides /usr/share/emacs/site-lisp/elpa-src/boxquote-2.3/boxquote
> /usr/share/emacs/site-lisp/elpa/boxquote-2.3/boxquote-autoloads hides /usr/share/emacs/site-lisp/elpa-src/boxquote-2.3/boxquote-autoloads
> /usr/share/emacs/site-lisp/elpa/boxquote-2.3/boxquote-pkg hides /usr/share/emacs/site-lisp/elpa-src/boxquote-2.3/boxquote-pkg
> /usr/share/emacs/site-lisp/elpa/clojure-mode-5.18.1/clojure-mode-pkg hides /usr/share/emacs/site-lisp/elpa-src/clojure-mode-5.18.1/clojure-mode-pkg
> /usr/share/emacs/site-lisp/elpa/clojure-mode-5.18.1/clojure-mode hides /usr/share/emacs/site-lisp/elpa-src/clojure-mode-5.18.1/clojure-mode
> /usr/share/emacs/site-lisp/elpa/clojure-mode-5.18.1/clojure-mode-autoloads hides /usr/share/emacs/site-lisp/elpa-src/clojure-mode-5.18.1/clojure-mode-autoloads
> /usr/share/emacs/site-lisp/elpa/clojure-mode-extra-font-locking-3.0.0/clojure-mode-extra-font-locking-pkg hides /usr/share/emacs/site-lisp/elpa-src/clojure-mode-extra-font-locking-3.0.0/clojure-mode-extra-font-locking-pkg
> /usr/share/emacs/site-lisp/elpa/clojure-mode-extra-font-locking-3.0.0/clojure-mode-extra-font-locking-autoloads hides /usr/share/emacs/site-lisp/elpa-src/clojure-mode-extra-font-locking-3.0.0/clojure-mode-extra-font-locking-autoloads
> /usr/share/emacs/site-lisp/elpa/clojure-mode-extra-font-locking-3.0.0/clojure-mode-extra-font-locking hides /usr/share/emacs/site-lisp/elpa-src/clojure-mode-extra-font-locking-3.0.0/clojure-mode-extra-font-locking
> /usr/share/emacs/site-lisp/elpa/csv-mode-1.23/csv-mode-autoloads hides /usr/share/emacs/site-lisp/elpa-src/csv-mode-1.23/csv-mode-autoloads
> /usr/share/emacs/site-lisp/elpa/csv-mode-1.23/csv-mode hides /usr/share/emacs/site-lisp/elpa-src/csv-mode-1.23/csv-mode
> /usr/share/emacs/site-lisp/elpa/csv-mode-1.23/csv-mode-tests hides /usr/share/emacs/site-lisp/elpa-src/csv-mode-1.23/csv-mode-tests
> /usr/share/emacs/site-lisp/elpa/csv-mode-1.23/csv-mode-pkg hides /usr/share/emacs/site-lisp/elpa-src/csv-mode-1.23/csv-mode-pkg
> /usr/share/emacs/site-lisp/elpa/dash-2.19.1/dash hides /usr/share/emacs/site-lisp/elpa-src/dash-2.19.1/dash
> /usr/share/emacs/site-lisp/elpa/dash-2.19.1/dash-pkg hides /usr/share/emacs/site-lisp/elpa-src/dash-2.19.1/dash-pkg
> /usr/share/emacs/site-lisp/elpa/dash-2.19.1/dash-autoloads hides /usr/share/emacs/site-lisp/elpa-src/dash-2.19.1/dash-autoloads
> /usr/share/emacs/site-lisp/elpa/debian-el-37.11/debian-el-autoloads hides /usr/share/emacs/site-lisp/elpa-src/debian-el-37.11/debian-el-autoloads
> /usr/share/emacs/site-lisp/elpa/debian-el-37.11/apt-sources hides /usr/share/emacs/site-lisp/elpa-src/debian-el-37.11/apt-sources
> /usr/share/emacs/site-lisp/elpa/debian-el-37.11/debian-bug hides /usr/share/emacs/site-lisp/elpa-src/debian-el-37.11/debian-bug
> /usr/share/emacs/site-lisp/elpa/debian-el-37.11/apt-utils hides /usr/share/emacs/site-lisp/elpa-src/debian-el-37.11/apt-utils
> /usr/share/emacs/site-lisp/elpa/debian-el-37.11/debian-el-pkg hides /usr/share/emacs/site-lisp/elpa-src/debian-el-37.11/debian-el-pkg
> /usr/share/emacs/site-lisp/elpa/debian-el-37.11/gnus-BTS hides /usr/share/emacs/site-lisp/elpa-src/debian-el-37.11/gnus-BTS
> /usr/share/emacs/site-lisp/elpa/debian-el-37.11/deb-view hides /usr/share/emacs/site-lisp/elpa-src/debian-el-37.11/deb-view
> /usr/share/emacs/site-lisp/elpa/debian-el-37.11/debian-el hides /usr/share/emacs/site-lisp/elpa-src/debian-el-37.11/debian-el
> /usr/share/emacs/site-lisp/elpa/debian-el-37.11/preseed hides /usr/share/emacs/site-lisp/elpa-src/debian-el-37.11/preseed
> /usr/share/emacs/site-lisp/elpa/debpaste-0.1.5/debpaste hides /usr/share/emacs/site-lisp/elpa-src/debpaste-0.1.5/debpaste
> /usr/share/emacs/site-lisp/elpa/debpaste-0.1.5/debpaste-pkg hides /usr/share/emacs/site-lisp/elpa-src/debpaste-0.1.5/debpaste-pkg
> /usr/share/emacs/site-lisp/elpa/debpaste-0.1.5/debpaste-autoloads hides /usr/share/emacs/site-lisp/elpa-src/debpaste-0.1.5/debpaste-autoloads
> /usr/share/emacs/site-lisp/elpa/devscripts-40/devscripts hides /usr/share/emacs/site-lisp/elpa-src/devscripts-40/devscripts
> /usr/share/emacs/site-lisp/elpa/devscripts-40/devscripts-autoloads hides /usr/share/emacs/site-lisp/elpa-src/devscripts-40/devscripts-autoloads
> /usr/share/emacs/site-lisp/elpa/devscripts-40/pbuilder-mode hides /usr/share/emacs/site-lisp/elpa-src/devscripts-40/pbuilder-mode
> /usr/share/emacs/site-lisp/elpa/devscripts-40/devscripts-pkg hides /usr/share/emacs/site-lisp/elpa-src/devscripts-40/devscripts-pkg
> /usr/share/emacs/site-lisp/elpa/devscripts-40/pbuilder-log-view-mode hides /usr/share/emacs/site-lisp/elpa-src/devscripts-40/pbuilder-log-view-mode
> /usr/share/emacs/site-lisp/elpa/dockerfile-mode-1.7/dockerfile-mode hides /usr/share/emacs/site-lisp/elpa-src/dockerfile-mode-1.7/dockerfile-mode
> /usr/share/emacs/site-lisp/elpa/dockerfile-mode-1.7/dockerfile-mode-autoloads hides /usr/share/emacs/site-lisp/elpa-src/dockerfile-mode-1.7/dockerfile-mode-autoloads
> /usr/share/emacs/site-lisp/elpa/dockerfile-mode-1.7/dockerfile-mode-pkg hides /usr/share/emacs/site-lisp/elpa-src/dockerfile-mode-1.7/dockerfile-mode-pkg
> /usr/share/emacs/site-lisp/elpa/dpkg-dev-el-37.10/debian-bts-control hides /usr/share/emacs/site-lisp/elpa-src/dpkg-dev-el-37.10/debian-bts-control
> /usr/share/emacs/site-lisp/elpa/dpkg-dev-el-37.10/debian-changelog-mode hides /usr/share/emacs/site-lisp/elpa-src/dpkg-dev-el-37.10/debian-changelog-mode
> /usr/share/emacs/site-lisp/elpa/dpkg-dev-el-37.10/dpkg-dev-el-autoloads hides /usr/share/emacs/site-lisp/elpa-src/dpkg-dev-el-37.10/dpkg-dev-el-autoloads
> /usr/share/emacs/site-lisp/elpa/dpkg-dev-el-37.10/dpkg-dev-el-pkg hides /usr/share/emacs/site-lisp/elpa-src/dpkg-dev-el-37.10/dpkg-dev-el-pkg
> /usr/share/emacs/site-lisp/elpa/dpkg-dev-el-37.10/dpkg-dev-el hides /usr/share/emacs/site-lisp/elpa-src/dpkg-dev-el-37.10/dpkg-dev-el
> /usr/share/emacs/site-lisp/elpa/dpkg-dev-el-37.10/debian-control-mode hides /usr/share/emacs/site-lisp/elpa-src/dpkg-dev-el-37.10/debian-control-mode
> /usr/share/emacs/site-lisp/elpa/dpkg-dev-el-37.10/debian-copyright hides /usr/share/emacs/site-lisp/elpa-src/dpkg-dev-el-37.10/debian-copyright
> /usr/share/emacs/site-lisp/elpa/dpkg-dev-el-37.10/readme-debian hides /usr/share/emacs/site-lisp/elpa-src/dpkg-dev-el-37.10/readme-debian
> /usr/share/emacs/site-lisp/elpa/git-commit-3.3.0/git-commit hides /usr/share/emacs/site-lisp/elpa-src/git-commit-3.3.0/git-commit
> /usr/share/emacs/site-lisp/elpa/git-commit-3.3.0/git-commit-autoloads hides /usr/share/emacs/site-lisp/elpa-src/git-commit-3.3.0/git-commit-autoloads
> /usr/share/emacs/site-lisp/elpa/git-commit-3.3.0/git-commit-pkg hides /usr/share/emacs/site-lisp/elpa-src/git-commit-3.3.0/git-commit-pkg
> /usr/share/emacs/site-lisp/elpa/gnuplot-0.8.1/gnuplot hides /usr/share/emacs/site-lisp/elpa-src/gnuplot-0.8.1/gnuplot
> /usr/share/emacs/site-lisp/elpa/gnuplot-0.8.1/gnuplot-autoloads hides /usr/share/emacs/site-lisp/elpa-src/gnuplot-0.8.1/gnuplot-autoloads
> /usr/share/emacs/site-lisp/elpa/gnuplot-0.8.1/debian-autoloads hides /usr/share/emacs/site-lisp/elpa-src/gnuplot-0.8.1/debian-autoloads
> /usr/share/emacs/site-lisp/elpa/gnuplot-0.8.1/gnuplot-pkg hides /usr/share/emacs/site-lisp/elpa-src/gnuplot-0.8.1/gnuplot-pkg
> /usr/share/emacs/site-lisp/elpa/gnuplot-0.8.1/gnuplot-context hides /usr/share/emacs/site-lisp/elpa-src/gnuplot-0.8.1/gnuplot-context
> /usr/share/emacs/site-lisp/elpa/gnuplot-0.8.1/gnuplot-gui hides /usr/share/emacs/site-lisp/elpa-src/gnuplot-0.8.1/gnuplot-gui
> /usr/share/emacs/site-lisp/elpa/go-mode-1.6.0/go-mode hides /usr/share/emacs/site-lisp/elpa-src/go-mode-1.6.0/go-mode
> /usr/share/emacs/site-lisp/elpa/go-mode-1.6.0/go-guru hides /usr/share/emacs/site-lisp/elpa-src/go-mode-1.6.0/go-guru
> /usr/share/emacs/site-lisp/elpa/go-mode-1.6.0/go-mode-pkg hides /usr/share/emacs/site-lisp/elpa-src/go-mode-1.6.0/go-mode-pkg
> /usr/share/emacs/site-lisp/elpa/go-mode-1.6.0/go-mode-autoloads hides /usr/share/emacs/site-lisp/elpa-src/go-mode-1.6.0/go-mode-autoloads
> /usr/share/emacs/site-lisp/elpa/go-mode-1.6.0/go-rename hides /usr/share/emacs/site-lisp/elpa-src/go-mode-1.6.0/go-rename
> /usr/share/emacs/site-lisp/elpa/graphviz-dot-mode-0.4.2/graphviz-dot-mode-autoloads hides /usr/share/emacs/site-lisp/elpa-src/graphviz-dot-mode-0.4.2/graphviz-dot-mode-autoloads
> /usr/share/emacs/site-lisp/elpa/graphviz-dot-mode-0.4.2/company-graphviz-dot hides /usr/share/emacs/site-lisp/elpa-src/graphviz-dot-mode-0.4.2/company-graphviz-dot
> /usr/share/emacs/site-lisp/elpa/graphviz-dot-mode-0.4.2/graphviz-dot-mode-pkg hides /usr/share/emacs/site-lisp/elpa-src/graphviz-dot-mode-0.4.2/graphviz-dot-mode-pkg
> /usr/share/emacs/site-lisp/elpa/graphviz-dot-mode-0.4.2/graphviz-dot-mode hides /usr/share/emacs/site-lisp/elpa-src/graphviz-dot-mode-0.4.2/graphviz-dot-mode
> /usr/share/emacs/site-lisp/elpa/lintian-0.1/lintian-pkg hides /usr/share/emacs/site-lisp/elpa-src/lintian-0.1/lintian-pkg
> /usr/share/emacs/site-lisp/elpa/lintian-0.1/lintian-autoloads hides /usr/share/emacs/site-lisp/elpa-src/lintian-0.1/lintian-autoloads
> /usr/share/emacs/site-lisp/elpa/lintian-0.1/lintian hides /usr/share/emacs/site-lisp/elpa-src/lintian-0.1/lintian
> /usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-remote hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-remote
> /usr/share/emacs/site-lisp/elpa/magit-3.3.0/git-rebase hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/git-rebase
> /usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-bisect hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-bisect
> /usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-margin hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-margin
> /usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-merge hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-merge
> /usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-section hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-section
> /usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-patch hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-patch
> /usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-commit hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-commit
> /usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-autoloads hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-autoloads
> /usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-files hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-files
> /usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-stash hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-stash
> /usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-bookmark hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-bookmark
> /usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-submodule hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-submodule
> /usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-apply hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-apply
> /usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-repos hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-repos
> /usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-core hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-core
> /usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-subtree hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-subtree
> /usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-autorevert hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-autorevert
> /usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-gitignore hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-gitignore
> /usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-transient hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-transient
> /usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-extras hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-extras
> /usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-git hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-git
> /usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-notes hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-notes
> /usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-reflog hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-reflog
> /usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-mode hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-mode
> /usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-push hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-push
> /usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-tag hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-tag
> /usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-process hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-process
> /usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-ediff hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-ediff
> /usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit
> /usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-imenu hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-imenu
> /usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-diff hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-diff
> /usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-clone hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-clone
> /usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-log hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-log
> /usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-utils hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-utils
> /usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-wip hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-wip
> /usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-branch hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-branch
> /usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-pull hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-pull
> /usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-reset hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-reset
> /usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-sequence hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-sequence
> /usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-status hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-status
> /usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-refs hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-refs
> /usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-obsolete hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-obsolete
> /usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-fetch hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-fetch
> /usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-worktree hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-worktree
> /usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-blame hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-blame
> /usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-pkg hides /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-pkg
> /usr/share/emacs/site-lisp/elpa/magit-section-3.3.0/magit-section-autoloads hides /usr/share/emacs/site-lisp/elpa-src/magit-section-3.3.0/magit-section-autoloads
> /usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-section hides /usr/share/emacs/site-lisp/elpa-src/magit-section-3.3.0/magit-section
> /usr/share/emacs/site-lisp/elpa/magit-section-3.3.0/magit-section-pkg hides /usr/share/emacs/site-lisp/elpa-src/magit-section-3.3.0/magit-section-pkg
> /usr/share/emacs/site-lisp/elpa/matlab-mode-4.0/matlab-cgen hides /usr/share/emacs/site-lisp/elpa-src/matlab-mode-4.0/matlab-cgen
> /usr/share/emacs/site-lisp/elpa/matlab-mode-4.0/matlab-scan hides /usr/share/emacs/site-lisp/elpa-src/matlab-mode-4.0/matlab-scan
> /usr/share/emacs/site-lisp/elpa/matlab-mode-4.0/matlab-publish hides /usr/share/emacs/site-lisp/elpa-src/matlab-mode-4.0/matlab-publish
> /usr/share/emacs/site-lisp/elpa/matlab-mode-4.0/matlab hides /usr/share/emacs/site-lisp/elpa-src/matlab-mode-4.0/matlab
> /usr/share/emacs/site-lisp/elpa/matlab-mode-4.0/matlab-complete hides /usr/share/emacs/site-lisp/elpa-src/matlab-mode-4.0/matlab-complete
> /usr/share/emacs/site-lisp/elpa/matlab-mode-4.0/matlab-syntax hides /usr/share/emacs/site-lisp/elpa-src/matlab-mode-4.0/matlab-syntax
> /usr/share/emacs/site-lisp/elpa/matlab-mode-4.0/tlc hides /usr/share/emacs/site-lisp/elpa-src/matlab-mode-4.0/tlc
> /usr/share/emacs/site-lisp/elpa/matlab-mode-4.0/matlab-netshell hides /usr/share/emacs/site-lisp/elpa-src/matlab-mode-4.0/matlab-netshell
> /usr/share/emacs/site-lisp/elpa/matlab-mode-4.0/semantic-matlab hides /usr/share/emacs/site-lisp/elpa-src/matlab-mode-4.0/semantic-matlab
> /usr/share/emacs/site-lisp/elpa/matlab-mode-4.0/mlint hides /usr/share/emacs/site-lisp/elpa-src/matlab-mode-4.0/mlint
> /usr/share/emacs/site-lisp/elpa/matlab-mode-4.0/company-matlab-shell hides /usr/share/emacs/site-lisp/elpa-src/matlab-mode-4.0/company-matlab-shell
> /usr/share/emacs/site-lisp/elpa/matlab-mode-4.0/matlab-shell-gud hides /usr/share/emacs/site-lisp/elpa-src/matlab-mode-4.0/matlab-shell-gud
> /usr/share/emacs/site-lisp/elpa/matlab-mode-4.0/mlgud hides /usr/share/emacs/site-lisp/elpa-src/matlab-mode-4.0/mlgud
> /usr/share/emacs/site-lisp/elpa/matlab-mode-4.0/srecode-matlab hides /usr/share/emacs/site-lisp/elpa-src/matlab-mode-4.0/srecode-matlab
> /usr/share/emacs/site-lisp/elpa/matlab-mode-4.0/matlab-compat hides /usr/share/emacs/site-lisp/elpa-src/matlab-mode-4.0/matlab-compat
> /usr/share/emacs/site-lisp/elpa/matlab-mode-4.0/matlab-mode-pkg hides /usr/share/emacs/site-lisp/elpa-src/matlab-mode-4.0/matlab-mode-pkg
> /usr/share/emacs/site-lisp/elpa/matlab-mode-4.0/matlab-maint hides /usr/share/emacs/site-lisp/elpa-src/matlab-mode-4.0/matlab-maint
> /usr/share/emacs/site-lisp/elpa/matlab-mode-4.0/cedet-matlab hides /usr/share/emacs/site-lisp/elpa-src/matlab-mode-4.0/cedet-matlab
> /usr/share/emacs/site-lisp/elpa/matlab-mode-4.0/matlab-topic hides /usr/share/emacs/site-lisp/elpa-src/matlab-mode-4.0/matlab-topic
> /usr/share/emacs/site-lisp/elpa/matlab-mode-4.0/linemark hides /usr/share/emacs/site-lisp/elpa-src/matlab-mode-4.0/linemark
> /usr/share/emacs/site-lisp/elpa/matlab-mode-4.0/matlab-shell hides /usr/share/emacs/site-lisp/elpa-src/matlab-mode-4.0/matlab-shell
> /usr/share/emacs/site-lisp/elpa/matlab-mode-4.0/semanticdb-matlab hides /usr/share/emacs/site-lisp/elpa-src/matlab-mode-4.0/semanticdb-matlab
> /usr/share/emacs/site-lisp/elpa/matlab-mode-4.0/matlab-load hides /usr/share/emacs/site-lisp/elpa-src/matlab-mode-4.0/matlab-load
> /usr/share/emacs/site-lisp/elpa/matlab-mode-4.0/matlab-mode-autoloads hides /usr/share/emacs/site-lisp/elpa-src/matlab-mode-4.0/matlab-mode-autoloads
> /usr/share/emacs/site-lisp/elpa/meson-mode-0.2/meson-mode hides /usr/share/emacs/site-lisp/elpa-src/meson-mode-0.2/meson-mode
> /usr/share/emacs/site-lisp/elpa/meson-mode-0.2/utils hides /usr/share/emacs/site-lisp/elpa-src/meson-mode-0.2/utils
> /usr/share/emacs/site-lisp/elpa/meson-mode-0.2/meson-mode-autoloads hides /usr/share/emacs/site-lisp/elpa-src/meson-mode-0.2/meson-mode-autoloads
> /usr/share/emacs/site-lisp/elpa/meson-mode-0.2/meson-mode-pkg hides /usr/share/emacs/site-lisp/elpa-src/meson-mode-0.2/meson-mode-pkg
> /usr/share/emacs/site-lisp/elpa/nginx-mode-1.1.9/nginx-mode-autoloads hides /usr/share/emacs/site-lisp/elpa-src/nginx-mode-1.1.9/nginx-mode-autoloads
> /usr/share/emacs/site-lisp/elpa/nginx-mode-1.1.9/nginx-mode-pkg hides /usr/share/emacs/site-lisp/elpa-src/nginx-mode-1.1.9/nginx-mode-pkg
> /usr/share/emacs/site-lisp/elpa/nginx-mode-1.1.9/nginx-mode hides /usr/share/emacs/site-lisp/elpa-src/nginx-mode-1.1.9/nginx-mode
> /usr/share/emacs/site-lisp/elpa/paredit-26/paredit-autoloads hides /usr/share/emacs/site-lisp/elpa-src/paredit-26/paredit-autoloads
> /usr/share/emacs/site-lisp/elpa/paredit-26/paredit-pkg hides /usr/share/emacs/site-lisp/elpa-src/paredit-26/paredit-pkg
> /usr/share/emacs/site-lisp/elpa/paredit-26/paredit hides /usr/share/emacs/site-lisp/elpa-src/paredit-26/paredit
> /usr/share/emacs/site-lisp/elpa/po-mode-0.21/po-mode-pkg hides /usr/share/emacs/site-lisp/elpa-src/po-mode-0.21/po-mode-pkg
> /usr/share/emacs/site-lisp/elpa/po-mode-0.21/po-mode-autoloads hides /usr/share/emacs/site-lisp/elpa-src/po-mode-0.21/po-mode-autoloads
> /usr/share/emacs/site-lisp/elpa/po-mode-0.21/po-mode hides /usr/share/emacs/site-lisp/elpa-src/po-mode-0.21/po-mode
> /usr/share/emacs/site-lisp/elpa/py-isort-2016.1/py-isort hides /usr/share/emacs/site-lisp/elpa-src/py-isort-2016.1/py-isort
> /usr/share/emacs/site-lisp/elpa/py-isort-2016.1/py-isort-autoloads hides /usr/share/emacs/site-lisp/elpa-src/py-isort-2016.1/py-isort-autoloads
> /usr/share/emacs/site-lisp/elpa/py-isort-2016.1/py-isort-pkg hides /usr/share/emacs/site-lisp/elpa-src/py-isort-2016.1/py-isort-pkg
> /usr/share/emacs/site-lisp/elpa/pyvenv-1.21/pyvenv hides /usr/share/emacs/site-lisp/elpa-src/pyvenv-1.21/pyvenv
> /usr/share/emacs/site-lisp/elpa/pyvenv-1.21/pyvenv-pkg hides /usr/share/emacs/site-lisp/elpa-src/pyvenv-1.21/pyvenv-pkg
> /usr/share/emacs/site-lisp/elpa/pyvenv-1.21/pyvenv-autoloads hides /usr/share/emacs/site-lisp/elpa-src/pyvenv-1.21/pyvenv-autoloads
> /usr/share/emacs/site-lisp/elpa/rust-mode-1.0.5/rust-common hides /usr/share/emacs/site-lisp/elpa-src/rust-mode-1.0.5/rust-common
> /usr/share/emacs/site-lisp/elpa/rust-mode-1.0.5/rust-mode-tests hides /usr/share/emacs/site-lisp/elpa-src/rust-mode-1.0.5/rust-mode-tests
> /usr/share/emacs/site-lisp/elpa/rust-mode-1.0.5/rust-mode-treesitter hides /usr/share/emacs/site-lisp/elpa-src/rust-mode-1.0.5/rust-mode-treesitter
> /usr/share/emacs/site-lisp/elpa/rust-mode-1.0.5/rust-cargo hides /usr/share/emacs/site-lisp/elpa-src/rust-mode-1.0.5/rust-cargo
> /usr/share/emacs/site-lisp/elpa/rust-mode-1.0.5/rust-mode-autoloads hides /usr/share/emacs/site-lisp/elpa-src/rust-mode-1.0.5/rust-mode-autoloads
> /usr/share/emacs/site-lisp/elpa/rust-mode-1.0.5/rust-utils hides /usr/share/emacs/site-lisp/elpa-src/rust-mode-1.0.5/rust-utils
> /usr/share/emacs/site-lisp/elpa/rust-mode-1.0.5/rust-rustfmt hides /usr/share/emacs/site-lisp/elpa-src/rust-mode-1.0.5/rust-rustfmt
> /usr/share/emacs/site-lisp/elpa/rust-mode-1.0.5/rust-mode hides /usr/share/emacs/site-lisp/elpa-src/rust-mode-1.0.5/rust-mode
> /usr/share/emacs/site-lisp/elpa/rust-mode-1.0.5/rust-playpen hides /usr/share/emacs/site-lisp/elpa-src/rust-mode-1.0.5/rust-playpen
> /usr/share/emacs/site-lisp/elpa/rust-mode-1.0.5/rust-prog-mode hides /usr/share/emacs/site-lisp/elpa-src/rust-mode-1.0.5/rust-prog-mode
> /usr/share/emacs/site-lisp/elpa/rust-mode-1.0.5/rust-mode-pkg hides /usr/share/emacs/site-lisp/elpa-src/rust-mode-1.0.5/rust-mode-pkg
> /usr/share/emacs/site-lisp/elpa/rust-mode-1.0.5/rust-compile hides /usr/share/emacs/site-lisp/elpa-src/rust-mode-1.0.5/rust-compile
> /usr/share/emacs/site-lisp/elpa/scala-mode-1.1.0/scala-mode-map hides /usr/share/emacs/site-lisp/elpa-src/scala-mode-1.1.0/scala-mode-map
> /usr/share/emacs/site-lisp/elpa/scala-mode-1.1.0/scala-mode-indent hides /usr/share/emacs/site-lisp/elpa-src/scala-mode-1.1.0/scala-mode-indent
> /usr/share/emacs/site-lisp/elpa/scala-mode-1.1.0/scala-mode-syntax hides /usr/share/emacs/site-lisp/elpa-src/scala-mode-1.1.0/scala-mode-syntax
> /usr/share/emacs/site-lisp/elpa/scala-mode-1.1.0/scala-mode-lib hides /usr/share/emacs/site-lisp/elpa-src/scala-mode-1.1.0/scala-mode-lib
> /usr/share/emacs/site-lisp/elpa/scala-mode-1.1.0/scala-mode-pkg hides /usr/share/emacs/site-lisp/elpa-src/scala-mode-1.1.0/scala-mode-pkg
> /usr/share/emacs/site-lisp/elpa/scala-mode-1.1.0/scala-mode-prettify-symbols hides /usr/share/emacs/site-lisp/elpa-src/scala-mode-1.1.0/scala-mode-prettify-symbols
> /usr/share/emacs/site-lisp/elpa/scala-mode-1.1.0/scala-compile hides /usr/share/emacs/site-lisp/elpa-src/scala-mode-1.1.0/scala-compile
> /usr/share/emacs/site-lisp/elpa/scala-mode-1.1.0/scala-mode hides /usr/share/emacs/site-lisp/elpa-src/scala-mode-1.1.0/scala-mode
> /usr/share/emacs/site-lisp/elpa/scala-mode-1.1.0/scala-organise hides /usr/share/emacs/site-lisp/elpa-src/scala-mode-1.1.0/scala-organise
> /usr/share/emacs/site-lisp/elpa/scala-mode-1.1.0/scala-mode-autoloads hides /usr/share/emacs/site-lisp/elpa-src/scala-mode-1.1.0/scala-mode-autoloads
> /usr/share/emacs/site-lisp/elpa/scala-mode-1.1.0/scala-mode-paragraph hides /usr/share/emacs/site-lisp/elpa-src/scala-mode-1.1.0/scala-mode-paragraph
> /usr/share/emacs/site-lisp/elpa/scala-mode-1.1.0/scala-mode-imenu hides /usr/share/emacs/site-lisp/elpa-src/scala-mode-1.1.0/scala-mode-imenu
> /usr/share/emacs/site-lisp/elpa/scala-mode-1.1.0/scala-mode-fontlock hides /usr/share/emacs/site-lisp/elpa-src/scala-mode-1.1.0/scala-mode-fontlock
> /usr/share/emacs/site-lisp/elpa/vterm-0.0.2/vterm-load-path hides /usr/share/emacs/site-lisp/elpa-src/vterm-0.0.2/vterm-load-path
> /usr/share/emacs/site-lisp/elpa/vterm-0.0.2/vterm hides /usr/share/emacs/site-lisp/elpa-src/vterm-0.0.2/vterm
> /usr/share/emacs/site-lisp/elpa/vterm-0.0.2/vterm-pkg hides /usr/share/emacs/site-lisp/elpa-src/vterm-0.0.2/vterm-pkg
> /usr/share/emacs/site-lisp/elpa/vterm-0.0.2/vterm-autoloads hides /usr/share/emacs/site-lisp/elpa-src/vterm-0.0.2/vterm-autoloads
> /usr/share/emacs/site-lisp/elpa/with-editor-3.0.5/with-editor-pkg hides /usr/share/emacs/site-lisp/elpa-src/with-editor-3.0.5/with-editor-pkg
> /usr/share/emacs/site-lisp/elpa/with-editor-3.0.5/with-editor-autoloads hides /usr/share/emacs/site-lisp/elpa-src/with-editor-3.0.5/with-editor-autoloads
> /usr/share/emacs/site-lisp/elpa/with-editor-3.0.5/with-editor hides /usr/share/emacs/site-lisp/elpa-src/with-editor-3.0.5/with-editor
> /usr/share/emacs/site-lisp/elpa/xml-rpc-1.6.17/xml-rpc hides /usr/share/emacs/site-lisp/elpa-src/xml-rpc-1.6.17/xml-rpc
> /usr/share/emacs/site-lisp/elpa/xml-rpc-1.6.17/xml-rpc-pkg hides /usr/share/emacs/site-lisp/elpa-src/xml-rpc-1.6.17/xml-rpc-pkg
> /usr/share/emacs/site-lisp/elpa/xml-rpc-1.6.17/xml-rpc-autoloads hides /usr/share/emacs/site-lisp/elpa-src/xml-rpc-1.6.17/xml-rpc-autoloads
> /usr/share/emacs/site-lisp/elpa/yaml-mode-0.0.16/yaml-mode-pkg hides /usr/share/emacs/site-lisp/elpa-src/yaml-mode-0.0.16/yaml-mode-pkg
> /usr/share/emacs/site-lisp/elpa/yaml-mode-0.0.16/yaml-mode hides /usr/share/emacs/site-lisp/elpa-src/yaml-mode-0.0.16/yaml-mode
> /usr/share/emacs/site-lisp/elpa/yaml-mode-0.0.16/yaml-mode-autoloads hides /usr/share/emacs/site-lisp/elpa-src/yaml-mode-0.0.16/yaml-mode-autoloads
> /usr/share/emacs/site-lisp/elpa/yasnippet-0.14.1/yasnippet-autoloads hides /usr/share/emacs/site-lisp/elpa-src/yasnippet-0.14.1/yasnippet-autoloads
> /usr/share/emacs/site-lisp/elpa/yasnippet-0.14.1/yasnippet-pkg hides /usr/share/emacs/site-lisp/elpa-src/yasnippet-0.14.1/yasnippet-pkg
> /usr/share/emacs/site-lisp/elpa/yasnippet-0.14.1/yasnippet hides /usr/share/emacs/site-lisp/elpa-src/yasnippet-0.14.1/yasnippet
> /usr/share/emacs/site-lisp/elpa/yasnippet-snippets-20220713/yasnippet-snippets hides /usr/share/emacs/site-lisp/elpa-src/yasnippet-snippets-20220713/yasnippet-snippets
> /usr/share/emacs/site-lisp/elpa/yasnippet-snippets-20220713/yasnippet-snippets-pkg hides /usr/share/emacs/site-lisp/elpa-src/yasnippet-snippets-20220713/yasnippet-snippets-pkg
> /usr/share/emacs/site-lisp/elpa/yasnippet-snippets-20220713/yasnippet-snippets-autoloads hides /usr/share/emacs/site-lisp/elpa-src/yasnippet-snippets-20220713/yasnippet-snippets-autoloads
> /usr/share/emacs/site-lisp/elpa/zenburn-theme-2.8.0/zenburn-theme hides /usr/share/emacs/site-lisp/elpa-src/zenburn-theme-2.8.0/zenburn-theme
> /usr/share/emacs/site-lisp/elpa/zenburn-theme-2.8.0/zenburn-theme-pkg hides /usr/share/emacs/site-lisp/elpa-src/zenburn-theme-2.8.0/zenburn-theme-pkg
> /usr/share/emacs/site-lisp/elpa/zenburn-theme-2.8.0/zenburn-theme-autoloads hides /usr/share/emacs/site-lisp/elpa-src/zenburn-theme-2.8.0/zenburn-theme-autoloads
>
> Features:
> (shadow emacsbug org-element org-persist org-id org-refile avl-tree
> oc-basic ol-eww ol-rmail ol-mhe ol-irc ol-info ol-gnus nnselect
> ol-docview doc-view image-mode exif ol-bibtex bibtex ol-bbdb ol-w3m
> ol-doi org-link-doi org ob ob-tangle ob-ref ob-lob ob-table ob-exp
> org-macro org-src ob-comint org-pcomplete org-list org-footnote
> org-faces org-entities ob-emacs-lisp ob-core ob-eval org-cycle org-table
> ol org-fold org-fold-core org-keys oc org-loaddefs cal-menu calendar
> cal-loaddefs org-version org-compat org-macs clojure-mode align noutline
> outline checkdoc lisp-mnt debpaste xml-rpc boxquote reporter mhtml-mode
> css-mode eww xdg mm-url js c-ts-common cc-mode cc-fonts cc-guess
> cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs sgml-mode
> facemenu sh-script smie executable make-mode view deb-view tar-mode
> arc-mode archive-mode magit-patch magit-subtree magit-ediff ediff
> ediff-merg ediff-mult ediff-wind ediff-diff ediff-help ediff-init
> ediff-util rect tex-info texinfo texinfo-loaddefs tex texmathp
> git-rebase perl-mode find-dired ffap grep debian-control-mode debian-bug
> mailalias macros vterm tramp tramp-loaddefs trampver tramp-integration
> files-x tramp-compat term ehelp vterm-module magit-gitignore shortdoc
> help-fns radix-tree misearch multi-isearch eglot external-completion
> array jsonrpc ert ewoc debug backtrace find-func shr-color url-http
> url-gw url-auth url-queue url-cache debian-copyright
> debian-changelog-mode qp flow-fill conf-mode matlab matlab-scan
> matlab-syntax matlab-compat pulse color windmove goto-addr magit-extras
> face-remap magit-bookmark magit-submodule magit-obsolete magit-blame
> magit-stash magit-reflog magit-bisect magit-push magit-pull magit-fetch
> magit-clone magit-remote magit-commit magit-sequence magit-notes
> magit-worktree magit-tag magit-merge magit-branch magit-reset
> magit-files magit-refs magit-status magit magit-repos magit-apply
> magit-wip magit-log which-func imenu magit-diff smerge-mode diff
> git-commit log-edit add-log magit-core magit-autorevert magit-margin
> magit-transient magit-process with-editor shell pcomplete magit-mode
> transient format-spec magit-git magit-section magit-utils crm dash
> dired-aux sort gnus-cite mm-archive mail-extr textsec uni-scripts
> idna-mapping ucs-normalize uni-confusable textsec-check gnus-async
> gnus-bcklg gnus-ml mule-util jka-compr gnus-topic cursor-sensor utf-7
> nnfolder gnus-demon nnml ezgnus gnus-delay gnus-draft gnus-agent
> gnus-srvr gnus-score score-mode nnvirtual nntp gnus-cache gnus-msg
> gnus-art mm-uu mml2015 mm-view mml-smime smime dig gnus-sum shr
> pixel-fill kinsoku url-file svg dom nndraft nnmh gnus-group gnus-undo
> smtpmail gnus-start gnus-dbus dbus xml gnus-cloud nnimap nnmail
> mail-source utf7 nnoo gnus-spec gnus-int gnus-range message sendmail
> yank-media dired dired-loaddefs 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 flyspell ispell gnutls network-stream puny nsm
> epa-file epa derived epg rfc6068 epg-config rcirc parse-time iso8601
> time-date term/xterm xterm comp comp-cstr rx server cap-words superword
> subword vc-hg vc-git diff-mode vc-bzr vc-src vc-sccs vc-svn vc-cvs
> vc-rcs log-view pcvs-util vc vc-dispatcher bug-reference disp-table
> whitespace yasnippet-snippets yasnippet cus-edit cus-start wid-edit
> company-oddmuse company-keywords company-etags etags fileloop generator
> xref company-gtags company-dabbrev-code company-dabbrev company-files
> company-clang company-capf company-cmake company-semantic
> company-template company-bbdb company pcase init zenburn-theme
> treesit-auto treesit keychain-environment exec-path-from-shell
> activities-tabs activities persist bookmark pp edmacro kmacro advice
> icomplete cus-load flymake-proc flymake project compile
> text-property-search comint ansi-osc ansi-color ring warnings icons
> thingatpt cl-extra help-mode use-package use-package-ensure
> use-package-delight use-package-diminish use-package-bind-key bind-key
> easy-mmode use-package-core display-line-numbers autorevert filenotify
> activities-autoloads auctex-autoloads tex-site cargo-autoloads
> company-autoloads dart-mode-autoloads exec-path-from-shell-autoloads
> format-all-autoloads git-modes-autoloads compat-autoloads
> inheritenv-autoloads keychain-environment-autoloads
> language-id-autoloads persist-autoloads treesit-auto-autoloads
> xclip-autoloads info finder-inf package browse-url url url-proxy
> url-privacy url-expand url-methods url-history url-cookie
> generate-lisp-file url-domsuf url-util mailcap url-handlers url-parse
> auth-source cl-seq eieio eieio-core cl-macs password-cache json subr-x
> map byte-opt gv bytecomp byte-compile url-vars cl-loaddefs cl-lib rmc
> iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook
> vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win
> term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
> tabulated-list replace newcomment text-mode lisp-mode prog-mode register
> page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
> scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
> frame minibuffer nadvice seq simple cl-generic indonesian philippine
> cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
> korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
> european ethiopic indian cyrillic chinese composite emoji-zwj charscript
> charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
> cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
> files window text-properties overlay sha1 md5 base64 format env
> code-pages mule custom widget keymap hashtable-print-readable backquote
> threads dbusbind inotify lcms2 dynamic-setting system-font-setting
> font-render-setting cairo move-toolbar gtk x-toolkit xinput2 x multi-tty
> make-network-process native-compile emacs)
>
> Memory information:
> ((conses 16 3624587 210142)
> (symbols 48 51570 65)
> (strings 32 295699 33738)
> (string-bytes 1 9403400)
> (vectors 16 192036)
> (vector-slots 8 4207835 141052)
> (floats 8 1294 9458)
> (intervals 56 179453 3660)
> (buffers 984 210))
>
>
>
>
--
Xiyue Deng
^ permalink raw reply [relevance 0%]
* bug#69992: Minor improvement to image map transformation logic
@ 2024-03-27 22:17 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-27 23:53 5% ` David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-28 22:22 1% ` David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 2 replies; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-03-27 22:17 UTC (permalink / raw)
To: David Ponce; +Cc: Eli Zaretskii, 69992
David Ponce <da_vid@orange.fr> writes:
> On 27/03/2024 13:50, Eli Zaretskii wrote:
>>> Date: Wed, 27 Mar 2024 12:16:11 +0100
>>> From: David Ponce via "Bug reports for GNU Emacs,
>>> the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>>>
>>> Many thanks for this feature, which is particularly useful to
>>> automatically recalculate the map of computed images like SVG.
You're welcome!
>>> To make the code faster, by avoiding multiple scans of the map for
>>> copy and parsing, I propose the following patch which factors most of
>>> the code into the functions `image--compute-map' and `image--compute
>>> -original-map'. I have done some tests on my side which are
>>> conclusive.
Thanks for reviewing and optimizing this feature. Please share the
tests/benchmarks that you've performed.
>>> Furthermore, I wonder if the term :base-map would not be more
>>> descriptive than :original-map?
I am fine with changing :original-map to :base-map. If you want to do
this, I suggest making this change in its own commit which also updates
the relevant docstrings and manual pages.
>> Thanks.
>> Joseph, any comments or suggestions?
On my machine, not all tests pass with the patch. Please be sure that
these three new tests pass:
image-create-image-with-map
image--compute-map-and-original-map
image-transform-map
Personally, I find it easier to understand image map transformation when
the logic is split into multiple functions. However, the benefit of
readability could certainly be outweighed by a noticeable improvement to
user experience. Please share some benchmarks.
Please keep in mind that `image--delayed-change-size' already debounces
image transformation, so this code may not be so performance-critical.
Thank you,
Joseph
> Attached the same patch slightly cleaned up.
>
> [2. text/x-patch; image.el-compute-map-V1.patch]...
^ permalink raw reply [relevance 5%]
* bug#69992: Minor improvement to image map transformation logic
2024-03-27 22:17 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-03-27 23:53 5% ` David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-28 22:22 1% ` David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 0 replies; 200+ results
From: David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-03-27 23:53 UTC (permalink / raw)
To: Joseph Turner; +Cc: Eli Zaretskii, 69992
On 27/03/2024 23:17, Joseph Turner wrote:
>
> David Ponce <da_vid@orange.fr> writes:
>
>> On 27/03/2024 13:50, Eli Zaretskii wrote:
>>>> Date: Wed, 27 Mar 2024 12:16:11 +0100
>>>> From: David Ponce via "Bug reports for GNU Emacs,
>>>> the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>>>>
>>>> Many thanks for this feature, which is particularly useful to
>>>> automatically recalculate the map of computed images like SVG.
>
> You're welcome!
>
>>>> To make the code faster, by avoiding multiple scans of the map for
>>>> copy and parsing, I propose the following patch which factors most of
>>>> the code into the functions `image--compute-map' and `image--compute
>>>> -original-map'. I have done some tests on my side which are
>>>> conclusive.
>
> Thanks for reviewing and optimizing this feature. Please share the
> tests/benchmarks that you've performed.
OK
>>>> Furthermore, I wonder if the term :base-map would not be more
>>>> descriptive than :original-map?
>
> I am fine with changing :original-map to :base-map. If you want to do
> this, I suggest making this change in its own commit which also updates
> the relevant docstrings and manual pages.
I was just wondering. If everyone is happy with :original-map, I'm fine
with it.
>>> Thanks.
>>> Joseph, any comments or suggestions?
>
> On my machine, not all tests pass with the patch. Please be sure that
> these three new tests pass:
>
> image-create-image-with-map
> image--compute-map-and-original-map
> image-transform-map
Maybe some tests didn't pass because with my patch the computed hot spots
are pushed in a new map in reverse order?
I will have a look at this as soon as possible.
> Personally, I find it easier to understand image map transformation when
> the logic is split into multiple functions. However, the benefit of
> readability could certainly be outweighed by a noticeable improvement to
> user experience. Please share some benchmarks.
In this case, I have the opposite feeling ;-)
I find harder to read the logic splits into multiple functions that operate
by side effect on hot spots coords. But it could be just me :-)
> Please keep in mind that `image--delayed-change-size' already debounces
> image transformation, so this code may not be so performance-critical.
Related to `image--delayed-change-size', you are probably right.
My concern is more about computed images and associated maps (I use such
kind of images+maps in computed SVG buttons grids). In this case it could
be interesting to keep `create-image' as efficient as possible.
> Thank you,
You are welcome! Thank you for your feedback!
>
> Joseph
>
>> Attached the same patch slightly cleaned up.
>>
>> [2. text/x-patch; image.el-compute-map-V1.patch]...
>
^ permalink raw reply [relevance 5%]
* bug#69972: 29.1; Unexpected behavior when scrolling images
2024-03-25 19:43 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-03-28 6:24 0% ` Eli Zaretskii
0 siblings, 0 replies; 200+ results
From: Eli Zaretskii @ 2024-03-28 6:24 UTC (permalink / raw)
To: Joseph Turner, Po Lu; +Cc: 69972
> From: Joseph Turner <joseph@ushin.org>
> Cc: 69972@debbugs.gnu.org
> Date: Mon, 25 Mar 2024 12:43:39 -0700
>
> >> With all three methods, at first Emacs gradually scrolls the image, but
> >> then when I reach the bottom of the image, the image disappears entirely
> >> as Emacs scrolls past it all at once.
> >
> > Why is that a problem? The default Emacs scrolling commands don't
> > guarantee smooth constant-rate scrolling, they guarantee only that you
> > get to see all the portions of the image, without missing any. So
> > when you get to the end of the image, there's a heuristic that decides
> > whether we can scroll past the image, and that is what you see.
> >
> > I see no bug here.
>
> With pixel-scroll-precision-mode enabled and at least one character after
> the image, I am able to smoothly scroll around the image.
pixel-scroll-precision-mode indeed attempts to make the scrolling much
more smooth than the default scrolling in these cases.
> However, if the window is scrolled to the right, then it is impossible
> to scroll down:
>
> (with-current-buffer (get-buffer-create "*test-scroll-image*")
> (erase-buffer)
> (insert-image (create-image "splash.png" nil nil :scale 10))
> (insert-char 8203)
> (goto-char (point-min))
> (pixel-scroll-precision-mode 1)
> (pop-to-buffer (current-buffer))
> (set-window-hscroll (get-buffer-window) 1)) ;; Image scrolled to right
>
> In this buffer, if I attempt to scroll down with the mouse wheel, I
> immediately get "End of buffer" error and the image does not move.
Then maybe Po Lu (CC'ed) could look into this and see if
pixel-scroll-precision-mode could do better in this case.
^ permalink raw reply [relevance 0%]
* bug#69602: 29.1; Image :map should adjust with :scale and :rotation
2024-03-23 20:32 10% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-03-28 10:13 0% ` Eli Zaretskii
0 siblings, 0 replies; 200+ results
From: Eli Zaretskii @ 2024-03-28 10:13 UTC (permalink / raw)
To: Joseph Turner; +Cc: 69602-done, stephen.berman, juri
> From: Joseph Turner <joseph@breatheoutbreathe.in>
> Cc: 69602-done@debbugs.gnu.org, stephen.berman@gmx.net, juri@linkov.net
> Date: Sat, 23 Mar 2024 13:32:05 -0700
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> From: Joseph Turner <joseph@breatheoutbreathe.in>
> >> Cc: 69602@debbugs.gnu.org, stephen.berman@gmx.net, juri@linkov.net
> >> Date: Sat, 23 Mar 2024 10:41:59 -0700
> >>
> >> Eli Zaretskii <eliz@gnu.org> writes:
> >>
> >> > In image-tests--map-equal:
> >> > lisp/image-tests.el:192:17: Warning: Unused lexical variable `i'
> >> >
> >> > Can you fix this, please?
> >>
> >> Oops! I just re-read the dotimes docstring to discover that the RESULT
> >> arg is deprecated. Fixed. Thank you!
> >
> > Thanks, installed on master, and closing the bug.
>
> Another minor improvement. Please see patch.
Thanks, installed.
^ permalink raw reply [relevance 0%]
* bug#69992: Minor improvement to image map transformation logic
2024-03-27 22:17 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-27 23:53 5% ` David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-03-28 22:22 1% ` David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 1 reply; 200+ results
From: David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-03-28 22:22 UTC (permalink / raw)
To: 69992; +Cc: Eli Zaretskii, Joseph Turner
[-- Attachment #1: Type: text/plain, Size: 3435 bytes --]
Re-sent to all (sorry)
On 27/03/2024 23:17, Joseph Turner wrote:
[...]
> On my machine, not all tests pass with the patch. Please be sure that
> these three new tests pass:
>
> image-create-image-with-map
> image--compute-map-and-original-map
> image-transform-map
>
> Personally, I find it easier to understand image map transformation when
> the logic is split into multiple functions. However, the benefit of
> readability could certainly be outweighed by a noticeable improvement to
> user experience. Please share some benchmarks.
>
> Please keep in mind that `image--delayed-change-size' already debounces
> image transformation, so this code may not be so performance-critical.
Hello,
After more work, testing and benchmarks, I can finally confirm that my
proposed version of `image--compute-*map' without the logic splits
into multiple functions is not significantly faster than the current
version with the logic splits into multiple functions :-)
What I found interesting after profiling both current and proposed
functions is that most of the time is consumed by the call to
`image-size'!
I also found that the current implementation is not correct when
rotation is not a multiple of 90 degrees. In this case, Emacs still
scales the image if specified, but ignores rotation and flipping.
However, in this case, the `image--compute-*map' functions do not
recompute map.
The attached new patch fixes the logic to be consistent with Emacs
internal implementation, plus some other tweaks to check if a
transformation apply before to call the transformation function.
I also updated some tests according to functions changes.
Here is a possible change log:
2024-03-28 David Ponce <da_vid@orange.fr>
* lisp/image.el (image--compute-scaling)
(image--compute-rotation): New functions.
(image--compute-map, image--compute-original-map): Use them.
Ensure all transformations are applied or undone according to what
Emacs does internally. Call a transformation function only when
needed. Fix doc string.
(image--scale-map): Assume effective scale argument.
(image--rotate-map): Assume effective rotation argument.
(image--rotate-coord): Improve doc string.
(image--flip-map): Remove no more used flip argument.
* test/lisp/image-tests.el (image-create-image-with-map): Use a
valid SVG image otherwise `image-size' will not return a valid
value and calculation of scale could fail.
(image-transform-map): Update according to changed signature of
image--flip-map.
This new version passes the `image-create-image-with-map' and
`image-transform-map' tests. But on my laptop, the
`image--compute-map-and-original-map' fails the same for both the
current and proposed version of the functions:
F image--compute-map-and-original-map
Test ‘image--compute-map’ and ‘image--compute-original-map’.
(ert-test-failed
((should
(image-tests--map-equal (image--compute-map image) rotated-map))
:form
(image-tests--map-equal
(((circle ... . 24) "a" (help-echo "A"))
((rect ... 127 . 77) "b" (help-echo "B"))
((poly . [199 161 206 160 213 154 218 146 221 136 ...]) "c"
(help-echo "C")))
(((circle ... . 24) "a" (help-echo "A"))
((rect ... 54 . 77) "b" (help-echo "B"))
((poly . [126 161 133 160 140 154 145 146 148 136 ...]) "c"
(help-echo "C"))))
:value nil))
Thanks!
[-- Attachment #2: image-compute-map-V0.patch --]
[-- Type: text/x-patch, Size: 13928 bytes --]
diff --git a/lisp/image.el b/lisp/image.el
index d7496485aca..b609f0fc34c 100644
--- a/lisp/image.el
+++ b/lisp/image.el
@@ -1423,115 +1423,139 @@ image-recompute-map-p
:type 'boolean
:version "30.1")
+(defsubst image--compute-scaling (image)
+ "Return the current scaling of IMAGE, or 1 if no scaling."
+ ;; The image may be scaled due to many reasons (:scale, :max-width,
+ ;; etc), so using `image--current-scaling' to get ratio between the
+ ;; original image size and the displayed size) is better than just
+ ;; using the :scale value. Unfortunately each call to `image_size' is
+ ;; very resource consuming!
+ ;; (image--current-scaling
+ ;; image (image--image-without-parameters image))
+ (or (image-property image :scale) 1))
+
+(defsubst image--compute-rotation (image)
+ "Return the current rotation of IMAGE, or 0 if no rotation.
+Also return nil if rotation is not a multiples of 90 degrees (0, 90,
+180[-180] and 270[-90])."
+ (let ((degrees (image-property image :rotation)))
+ (and degrees (= 0 (mod degrees 1))
+ (car (memql (truncate (mod degrees 360)) '(0 90 180 270))))))
+
(defun image--compute-map (image)
"Compute map for IMAGE suitable to be used as its :map property.
-Return a copy of :original-image transformed based on IMAGE's :scale,
+Return a copy of :original-map transformed based on IMAGE's :scale,
:rotation, and :flip. When IMAGE's :original-map is nil, return nil.
When :rotation is not a multiple of 90, return copy of :original-map."
- (pcase-let* ((original-map (image-property image :original-map))
- (map (copy-tree original-map t))
- (scale (or (image-property image :scale) 1))
- (rotation (or (image-property image :rotation) 0))
- (flip (image-property image :flip))
- ((and size `(,width . ,height)) (image-size image t)))
- (when (and ; Handle only 90-degree rotations
- (zerop (mod rotation 1))
- (zerop (% (truncate rotation) 90)))
- ;; SIZE fits MAP after transformations. Scale MAP before
- ;; flip and rotate operations, since both need MAP to fit SIZE.
- (image--scale-map map scale)
+ (when-let ((map (image-property image :original-map)))
+ (setq map (copy-tree map t))
+ (let* ((scale (image--compute-scaling image))
+ (rotation (image--compute-rotation image))
+ ;; Image is flipped only if rotation is a multiple of 90,
+ ;; including 0.
+ (flip (and rotation (image-property image :flip)))
+ (size (image-size image t)))
+ ;; SIZE fits MAP after transformations. Scale MAP before flip and
+ ;; rotate operations, since both need MAP to fit SIZE.
+ (unless (= scale 1)
+ (image--scale-map map scale))
;; In rendered images, rotation is always applied before flip.
- (image--rotate-map
- map rotation (if (or (= 90 rotation) (= 270 rotation))
+ (when (memql rotation '(90 180 270))
+ (image--rotate-map
+ map rotation (if (= rotation 180)
+ size
;; If rotated ±90°, swap width and height.
- (cons height width)
- size))
+ (cons (cdr size) (car size)))))
;; After rotation, there's no need to swap width and height.
- (image--flip-map map flip size))
+ (when flip
+ (image--flip-map map size)))
map))
(defun image--compute-original-map (image)
"Return original map for IMAGE.
If IMAGE lacks :map property, return nil.
-When :rotation is not a multiple of 90, return copy of :map."
- (when (image-property image :map)
- (let* ((original-map (copy-tree (image-property image :map) t))
- (scale (or (image-property image :scale) 1))
- (rotation (or (image-property image :rotation) 0))
- (flip (image-property image :flip))
+When there is no transformation, return copy of :map."
+ (when-let ((original-map (image-property image :map)))
+ (setq original-map (copy-tree original-map t))
+ (let* ((scale (image--compute-scaling image))
+ (rotation (image--compute-rotation image))
+ ;; Image is flipped only if rotation is a multiple of 90
+ ;; including 0.
+ (flip (and rotation (image-property image :flip)))
(size (image-size image t)))
- (when (and ; Handle only 90-degree rotations
- (zerop (mod rotation 1))
- (zerop (% (truncate rotation) 90)))
- ;; In rendered images, rotation is always applied before flip.
- ;; To undo the transformation, flip before rotating. SIZE fits
- ;; ORIGINAL-MAP before transformations are applied. Therefore,
- ;; scale ORIGINAL-MAP after flip and rotate operations, since
- ;; both need ORIGINAL-MAP to fit SIZE.
- (image--flip-map original-map flip size)
- (image--rotate-map original-map (- rotation) size)
- (image--scale-map original-map (/ 1.0 scale)))
- original-map)))
+ ;; In rendered images, rotation is always applied before flip.
+ ;; To undo the transformation, flip before rotating. SIZE fits
+ ;; ORIGINAL-MAP before transformations are applied. Therefore,
+ ;; scale ORIGINAL-MAP after flip and rotate operations, since
+ ;; both need ORIGINAL-MAP to fit SIZE.
+ ;; In rendered images, rotation is always applied before flip.
+ (when flip
+ (image--flip-map original-map size))
+ (when (memql rotation '(90 180 270))
+ (image--rotate-map original-map (- rotation) size))
+ (unless (= scale 1)
+ (image--scale-map original-map (/ 1.0 scale))))
+ original-map))
(defun image--scale-map (map scale)
"Scale MAP according to SCALE.
Destructively modifies and returns MAP."
- (unless (= 1 scale)
- (pcase-dolist (`(,`(,type . ,coords) ,_id ,_plist) map)
- (pcase-exhaustive type
- ('rect
- (setf (caar coords) (round (* (caar coords) scale)))
- (setf (cdar coords) (round (* (cdar coords) scale)))
- (setf (cadr coords) (round (* (cadr coords) scale)))
- (setf (cddr coords) (round (* (cddr coords) scale))))
- ('circle
- (setf (caar coords) (round (* (caar coords) scale)))
- (setf (cdar coords) (round (* (cdar coords) scale)))
- (setcdr coords (round (* (cdr coords) scale))))
- ('poly
- (dotimes (i (length coords))
- (aset coords i
- (round (* (aref coords i) scale))))))))
+ (pcase-dolist (`(,`(,type . ,coords) ,_id ,_plist) map)
+ (pcase-exhaustive type
+ ('rect
+ (setf (caar coords) (round (* (caar coords) scale)))
+ (setf (cdar coords) (round (* (cdar coords) scale)))
+ (setf (cadr coords) (round (* (cadr coords) scale)))
+ (setf (cddr coords) (round (* (cddr coords) scale))))
+ ('circle
+ (setf (caar coords) (round (* (caar coords) scale)))
+ (setf (cdar coords) (round (* (cdar coords) scale)))
+ (setcdr coords (round (* (cdr coords) scale))))
+ ('poly
+ (dotimes (i (length coords))
+ (aset coords i
+ (round (* (aref coords i) scale)))))))
map)
(defun image--rotate-map (map rotation size)
"Rotate MAP according to ROTATION and SIZE.
+ROTATION must be a non-zero multiple of 90.
Destructively modifies and returns MAP."
- (unless (zerop rotation)
- (pcase-dolist (`(,`(,type . ,coords) ,_id ,_plist) map)
- (pcase-exhaustive type
- ('rect
- (let ( x0 y0 ; New upper left corner
- x1 y1) ; New bottom right corner
- (pcase (truncate (mod rotation 360)) ; Set new corners to...
- (90 ; ...old bottom left and upper right
- (setq x0 (caar coords) y0 (cddr coords)
- x1 (cadr coords) y1 (cdar coords)))
- (180 ; ...old bottom right and upper left
- (setq x0 (cadr coords) y0 (cddr coords)
- x1 (caar coords) y1 (cdar coords)))
- (270 ; ...old upper right and bottom left
- (setq x0 (cadr coords) y0 (cdar coords)
- x1 (caar coords) y1 (cddr coords))))
- (setcar coords (image--rotate-coord x0 y0 rotation size))
- (setcdr coords (image--rotate-coord x1 y1 rotation size))))
- ('circle
- (setcar coords (image--rotate-coord
- (caar coords) (cdar coords) rotation size)))
- ('poly
- (dotimes (i (length coords))
- (when (= 0 (% i 2))
- (pcase-let ((`(,x . ,y)
- (image--rotate-coord
- (aref coords i) (aref coords (1+ i)) rotation size)))
- (aset coords i x)
- (aset coords (1+ i) y))))))))
+ (setq rotation (mod rotation 360))
+ (pcase-dolist (`(,`(,type . ,coords) ,_id ,_plist) map)
+ (pcase-exhaustive type
+ ('rect
+ (let ( x0 y0 ; New upper left corner
+ x1 y1) ; New bottom right corner
+ (pcase rotation ; Set new corners to...
+ (90 ; ...old bottom left and upper right
+ (setq x0 (caar coords) y0 (cddr coords)
+ x1 (cadr coords) y1 (cdar coords)))
+ (180 ; ...old bottom right and upper left
+ (setq x0 (cadr coords) y0 (cddr coords)
+ x1 (caar coords) y1 (cdar coords)))
+ (270 ; ...old upper right and bottom left
+ (setq x0 (cadr coords) y0 (cdar coords)
+ x1 (caar coords) y1 (cddr coords))))
+ (setcar coords (image--rotate-coord x0 y0 rotation size))
+ (setcdr coords (image--rotate-coord x1 y1 rotation size))))
+ ('circle
+ (setcar coords (image--rotate-coord
+ (caar coords) (cdar coords) rotation size)))
+ ('poly
+ (dotimes (i (length coords))
+ (when (= 0 (% i 2))
+ (pcase-let ((`(,x . ,y)
+ (image--rotate-coord
+ (aref coords i) (aref coords (1+ i)) rotation size)))
+ (aset coords i x)
+ (aset coords (1+ i) y)))))))
map)
(defun image--rotate-coord (x y angle size)
"Rotate coordinates X and Y by ANGLE in image of SIZE.
-ANGLE must be a multiple of 90. Returns a cons cell of rounded
-coordinates (X1 Y1)."
+ANGLE must be a multiple of 90 in [90 180 270]. Returns a cons cell of
+rounded coordinates (X1 Y1)."
(pcase-let* ((radian (* (/ angle 180.0) float-pi))
(`(,width . ,height) size)
;; y is positive, but we are in the bottom-right quadrant
@@ -1552,25 +1576,24 @@ image--rotate-coord
(y1 (- y1)))
(cons (round x1) (round y1))))
-(defun image--flip-map (map flip size)
- "Horizontally flip MAP according to FLIP and SIZE.
+(defun image--flip-map (map size)
+ "Horizontally flip MAP according to SIZE.
Destructively modifies and returns MAP."
- (when flip
- (pcase-dolist (`(,`(,type . ,coords) ,_id ,_plist) map)
- (pcase-exhaustive type
- ('rect
- (let ((x0 (- (car size) (cadr coords)))
- (y0 (cdar coords))
- (x1 (- (car size) (caar coords)))
- (y1 (cddr coords)))
- (setcar coords (cons x0 y0))
- (setcdr coords (cons x1 y1))))
- ('circle
- (setf (caar coords) (- (car size) (caar coords))))
- ('poly
- (dotimes (i (length coords))
- (when (= 0 (% i 2))
- (aset coords i (- (car size) (aref coords i)))))))))
+ (pcase-dolist (`(,`(,type . ,coords) ,_id ,_plist) map)
+ (pcase-exhaustive type
+ ('rect
+ (let ((x0 (- (car size) (cadr coords)))
+ (y0 (cdar coords))
+ (x1 (- (car size) (caar coords)))
+ (y1 (cddr coords)))
+ (setcar coords (cons x0 y0))
+ (setcdr coords (cons x1 y1))))
+ ('circle
+ (setf (caar coords) (- (car size) (caar coords))))
+ ('poly
+ (dotimes (i (length coords))
+ (when (= 0 (% i 2))
+ (aset coords i (- (car size) (aref coords i))))))))
map)
(provide 'image)
diff --git a/test/lisp/image-tests.el b/test/lisp/image-tests.el
index 6a5f03e38a0..020781eff50 100644
--- a/test/lisp/image-tests.el
+++ b/test/lisp/image-tests.el
@@ -158,7 +158,7 @@ image-rotate
(ert-deftest image-create-image-with-map ()
"Test that `create-image' correctly adds :map and/or :original-map."
(skip-unless (display-images-p))
- (let ((data "foo")
+ (let ((data "<svg width=\"30\" height=\"30\" version=\"1.1\" xmlns=\"http://www.w3.org/2000/svg\" xmlns:xlink=\"http://www.w3.org/1999/xlink\"></svg>")
(map '(((circle (1 . 1) . 1) a)))
(original-map '(((circle (2 . 2) . 2) a)))
(original-map-other '(((circle (3 . 3) . 3) a))))
@@ -282,7 +282,7 @@ image-transform-map
'(((circle (12 . 4) . 2) "circle")
((rect (7 . 3) 9 . 8) "rect")
((poly . [4 6 2 7 1 2]) "poly"))))
- (should (equal (image--flip-map (copy-tree map t) t `(,width . ,height))
+ (should (equal (image--flip-map (copy-tree map t) `(,width . ,height))
'(((circle (6 . 3) . 2) "circle")
((rect (2 . 6) 7 . 8) "rect")
((poly . [4 11 3 13 8 14]) "poly"))))
@@ -291,7 +291,7 @@ image-transform-map
;; Scale size because the map has been scaled.
(image--rotate-map copy 90 `(,(* 2 width) . ,(* 2 height)))
;; Swap width and height because the map has been flipped.
- (image--flip-map copy t `(,(* 2 height) . ,(* 2 width)))
+ (image--flip-map copy `(,(* 2 height) . ,(* 2 width)))
(should (equal copy
'(((circle (6 . 8) . 4) "circle")
((rect (12 . 6) 16 . 16) "rect")
^ permalink raw reply related [relevance 1%]
* bug#69992: Minor improvement to image map transformation logic
@ 2024-03-30 8:10 0% ` Eli Zaretskii
2024-03-30 8:55 0% ` David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 200+ results
From: Eli Zaretskii @ 2024-03-30 8:10 UTC (permalink / raw)
To: David Ponce; +Cc: 69992, joseph
> Date: Fri, 29 Mar 2024 11:19:11 +0100
> From: David Ponce <da_vid@orange.fr>
> Cc: Eli Zaretskii <eliz@gnu.org>, Joseph Turner <joseph@breatheoutbreathe.in>
>
> > The attached new patch fixes the logic to be consistent with Emacs
> > internal implementation, plus some other tweaks to check if a
> > transformation apply before to call the transformation function.
> > I also updated some tests according to functions changes.
> > Here is a possible change log:
> >
> > 2024-03-28 David Ponce <da_vid@orange.fr>
> >
> > * lisp/image.el (image--compute-scaling)
> > (image--compute-rotation): New functions.
> > (image--compute-map, image--compute-original-map): Use them.
> > Ensure all transformations are applied or undone according to what
> > Emacs does internally. Call a transformation function only when
> > needed. Fix doc string.
> > (image--scale-map): Assume effective scale argument.
> > (image--rotate-map): Assume effective rotation argument.
> > (image--rotate-coord): Improve doc string.
> > (image--flip-map): Remove no more used flip argument.
> >
> > * test/lisp/image-tests.el (image-create-image-with-map): Use a
> > valid SVG image otherwise `image-size' will not return a valid
> > value and calculation of scale could fail.
> > (image-transform-map): Update according to changed signature of
> > image--flip-map.
> [...]
>
> Hello,
>
> Please find attached a new patch with an additional small fix I forgot to
> include. Sorry.
Thanks. Please resend with the updated commit log message, and I will
install it.
^ permalink raw reply [relevance 0%]
* bug#69992: Minor improvement to image map transformation logic
2024-03-30 8:10 0% ` Eli Zaretskii
@ 2024-03-30 8:55 0% ` David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-30 12:59 0% ` David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 200+ results
From: David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-03-30 8:55 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 69992, joseph
On 30/03/2024 09:10, Eli Zaretskii wrote:
>> Date: Fri, 29 Mar 2024 11:19:11 +0100
>> From: David Ponce <da_vid@orange.fr>
>> Cc: Eli Zaretskii <eliz@gnu.org>, Joseph Turner <joseph@breatheoutbreathe.in>
>>
>>> The attached new patch fixes the logic to be consistent with Emacs
>>> internal implementation, plus some other tweaks to check if a
>>> transformation apply before to call the transformation function.
>>> I also updated some tests according to functions changes.
>>> Here is a possible change log:
>>>
>>> 2024-03-28 David Ponce <da_vid@orange.fr>
>>>
>>> * lisp/image.el (image--compute-scaling)
>>> (image--compute-rotation): New functions.
>>> (image--compute-map, image--compute-original-map): Use them.
>>> Ensure all transformations are applied or undone according to what
>>> Emacs does internally. Call a transformation function only when
>>> needed. Fix doc string.
>>> (image--scale-map): Assume effective scale argument.
>>> (image--rotate-map): Assume effective rotation argument.
>>> (image--rotate-coord): Improve doc string.
>>> (image--flip-map): Remove no more used flip argument.
>>>
>>> * test/lisp/image-tests.el (image-create-image-with-map): Use a
>>> valid SVG image otherwise `image-size' will not return a valid
>>> value and calculation of scale could fail.
>>> (image-transform-map): Update according to changed signature of
>>> image--flip-map.
>> [...]
>>
>> Hello,
>>
>> Please find attached a new patch with an additional small fix I forgot to
>> include. Sorry.
>
> Thanks. Please resend with the updated commit log message, and I will
> install it.
Hello Eli,
The change log is the same. The last patch include a slightly modified
version of the new function `image--compute-rotation' to return 0 by default
when no rotation is specified, instead of nil.
Please let me know if you need anything else.
Thanks!
^ permalink raw reply [relevance 0%]
* bug#69992: Minor improvement to image map transformation logic
2024-03-30 8:55 0% ` David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-03-30 12:59 0% ` David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-30 19:07 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 200+ results
From: David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-03-30 12:59 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 69992, joseph
[-- Attachment #1: Type: text/plain, Size: 3426 bytes --]
On 30/03/2024 09:55, David Ponce wrote:
> On 30/03/2024 09:10, Eli Zaretskii wrote:
>>> Date: Fri, 29 Mar 2024 11:19:11 +0100
>>> From: David Ponce <da_vid@orange.fr>
>>> Cc: Eli Zaretskii <eliz@gnu.org>, Joseph Turner <joseph@breatheoutbreathe.in>
>>>
>>>> The attached new patch fixes the logic to be consistent with Emacs
>>>> internal implementation, plus some other tweaks to check if a
>>>> transformation apply before to call the transformation function.
>>>> I also updated some tests according to functions changes.
>>>> Here is a possible change log:
>>>>
>>>> 2024-03-28 David Ponce <da_vid@orange.fr>
>>>>
>>>> * lisp/image.el (image--compute-scaling)
>>>> (image--compute-rotation): New functions.
>>>> (image--compute-map, image--compute-original-map): Use them.
>>>> Ensure all transformations are applied or undone according to what
>>>> Emacs does internally. Call a transformation function only when
>>>> needed. Fix doc string.
>>>> (image--scale-map): Assume effective scale argument.
>>>> (image--rotate-map): Assume effective rotation argument.
>>>> (image--rotate-coord): Improve doc string.
>>>> (image--flip-map): Remove no more used flip argument.
>>>>
>>>> * test/lisp/image-tests.el (image-create-image-with-map): Use a
>>>> valid SVG image otherwise `image-size' will not return a valid
>>>> value and calculation of scale could fail.
>>>> (image-transform-map): Update according to changed signature of
>>>> image--flip-map.
>>> [...]
>>>
>>> Hello,
>>>
>>> Please find attached a new patch with an additional small fix I forgot to
>>> include. Sorry.
>>
>> Thanks. Please resend with the updated commit log message, and I will
>> install it.
>
> Hello Eli,
>
> The change log is the same. The last patch include a slightly modified
> version of the new function `image--compute-rotation' to return 0 by default
> when no rotation is specified, instead of nil.
>
> Please let me know if you need anything else.
> Thanks!
Hello,
Here is my last patch. The only change compared to the previous patch is that
now the scale factor is correctly calculated based on the size of the image and
the displayed size. To minimize the performance impact, I saved a call to
`image-size' by doing the calculation directly in the `image--compute-map' and
`image--compute-original-map' functions. I did some benchmarks and the
difference is not significant. The tests still give the same results :-)
Here is the new change log:
2024-03-30 David Ponce <da_vid@orange.fr>
* lisp/image.el (image--compute-rotation): New function.
(image--compute-map, image--compute-original-map): Use it.
Ensure all transformations are applied or undone according to what
Emacs does internally. Call a transformation function only when
needed. Fix doc string.
(image--scale-map): Assume effective scale argument.
(image--rotate-map): Assume effective rotation argument.
(image--rotate-coord): Improve doc string.
(image--flip-map): Remove no more used flip argument.
* test/lisp/image-tests.el (image-create-image-with-map): Use a
valid SVG image otherwise `image-size' will not return a valid
value and calculation of scale could fail.
(image-transform-map): Update according to changed signature of
image--flip-map.
Thanks!
[-- Attachment #2: image-compute-map-V2.patch --]
[-- Type: text/x-patch, Size: 14325 bytes --]
diff --git a/lisp/image.el b/lisp/image.el
index d7496485aca..e973dff32c7 100644
--- a/lisp/image.el
+++ b/lisp/image.el
@@ -1423,115 +1423,142 @@ image-recompute-map-p
:type 'boolean
:version "30.1")
+(defsubst image--compute-rotation (image)
+ "Return the current rotation of IMAGE, or 0 if no rotation.
+Also return nil if rotation is not a multiples of 90 degrees (0, 90,
+180[-180] and 270[-90])."
+ (let ((degrees (or (image-property image :rotation) 0)))
+ (and (= 0 (mod degrees 1))
+ (car (memql (truncate (mod degrees 360)) '(0 90 180 270))))))
+
(defun image--compute-map (image)
"Compute map for IMAGE suitable to be used as its :map property.
-Return a copy of :original-image transformed based on IMAGE's :scale,
+Return a copy of :original-map transformed based on IMAGE's :scale,
:rotation, and :flip. When IMAGE's :original-map is nil, return nil.
When :rotation is not a multiple of 90, return copy of :original-map."
- (pcase-let* ((original-map (image-property image :original-map))
- (map (copy-tree original-map t))
- (scale (or (image-property image :scale) 1))
- (rotation (or (image-property image :rotation) 0))
- (flip (image-property image :flip))
- ((and size `(,width . ,height)) (image-size image t)))
- (when (and ; Handle only 90-degree rotations
- (zerop (mod rotation 1))
- (zerop (% (truncate rotation) 90)))
- ;; SIZE fits MAP after transformations. Scale MAP before
- ;; flip and rotate operations, since both need MAP to fit SIZE.
- (image--scale-map map scale)
+ (when-let ((map (image-property image :original-map)))
+ (setq map (copy-tree map t))
+ (let* ((size (image-size image t))
+ ;; The image can be scaled for many reasons (:scale,
+ ;; :max-width, etc), so using `image--current-scaling' to
+ ;; calculate the current scaling is the correct method. But,
+ ;; since each call to `image_size' is expensive, the code is
+ ;; duplicated here to save the a call to `image-size'.
+ (scale (/ (float (car size))
+ (car (image-size
+ (image--image-without-parameters image) t))))
+ (rotation (image--compute-rotation image))
+ ;; Image is flipped only if rotation is a multiple of 90,
+ ;; including 0.
+ (flip (and rotation (image-property image :flip))))
+ ;; SIZE fits MAP after transformations. Scale MAP before flip and
+ ;; rotate operations, since both need MAP to fit SIZE.
+ (unless (= scale 1)
+ (image--scale-map map scale))
;; In rendered images, rotation is always applied before flip.
- (image--rotate-map
- map rotation (if (or (= 90 rotation) (= 270 rotation))
+ (when (memql rotation '(90 180 270))
+ (image--rotate-map
+ map rotation (if (= rotation 180)
+ size
;; If rotated ±90°, swap width and height.
- (cons height width)
- size))
+ (cons (cdr size) (car size)))))
;; After rotation, there's no need to swap width and height.
- (image--flip-map map flip size))
+ (when flip
+ (image--flip-map map size)))
map))
(defun image--compute-original-map (image)
"Return original map for IMAGE.
If IMAGE lacks :map property, return nil.
-When :rotation is not a multiple of 90, return copy of :map."
- (when (image-property image :map)
- (let* ((original-map (copy-tree (image-property image :map) t))
- (scale (or (image-property image :scale) 1))
- (rotation (or (image-property image :rotation) 0))
- (flip (image-property image :flip))
- (size (image-size image t)))
- (when (and ; Handle only 90-degree rotations
- (zerop (mod rotation 1))
- (zerop (% (truncate rotation) 90)))
- ;; In rendered images, rotation is always applied before flip.
- ;; To undo the transformation, flip before rotating. SIZE fits
- ;; ORIGINAL-MAP before transformations are applied. Therefore,
- ;; scale ORIGINAL-MAP after flip and rotate operations, since
- ;; both need ORIGINAL-MAP to fit SIZE.
- (image--flip-map original-map flip size)
- (image--rotate-map original-map (- rotation) size)
- (image--scale-map original-map (/ 1.0 scale)))
- original-map)))
+When there is no transformation, return copy of :map."
+ (when-let ((original-map (image-property image :map)))
+ (setq original-map (copy-tree original-map t))
+ (let* ((size (image-size image t))
+ ;; The image can be scaled for many reasons (:scale,
+ ;; :max-width, etc), so using `image--current-scaling' to
+ ;; calculate the current scaling is the correct method. But,
+ ;; since each call to `image_size' is expensive, the code is
+ ;; duplicated here to save the a call to `image-size'.
+ (scale (/ (float (car size))
+ (car (image-size
+ (image--image-without-parameters image) t))))
+ (rotation (image--compute-rotation image))
+ ;; Image is flipped only if rotation is a multiple of 90
+ ;; including 0.
+ (flip (and rotation (image-property image :flip))))
+ ;; In rendered images, rotation is always applied before flip.
+ ;; To undo the transformation, flip before rotating. SIZE fits
+ ;; ORIGINAL-MAP before transformations are applied. Therefore,
+ ;; scale ORIGINAL-MAP after flip and rotate operations, since
+ ;; both need ORIGINAL-MAP to fit SIZE.
+ ;; In rendered images, rotation is always applied before flip.
+ (when flip
+ (image--flip-map original-map size))
+ (when (memql rotation '(90 180 270))
+ (image--rotate-map original-map (- rotation) size))
+ (unless (= scale 1)
+ (image--scale-map original-map (/ 1.0 scale))))
+ original-map))
(defun image--scale-map (map scale)
"Scale MAP according to SCALE.
Destructively modifies and returns MAP."
- (unless (= 1 scale)
- (pcase-dolist (`(,`(,type . ,coords) ,_id ,_plist) map)
- (pcase-exhaustive type
- ('rect
- (setf (caar coords) (round (* (caar coords) scale)))
- (setf (cdar coords) (round (* (cdar coords) scale)))
- (setf (cadr coords) (round (* (cadr coords) scale)))
- (setf (cddr coords) (round (* (cddr coords) scale))))
- ('circle
- (setf (caar coords) (round (* (caar coords) scale)))
- (setf (cdar coords) (round (* (cdar coords) scale)))
- (setcdr coords (round (* (cdr coords) scale))))
- ('poly
- (dotimes (i (length coords))
- (aset coords i
- (round (* (aref coords i) scale))))))))
+ (pcase-dolist (`(,`(,type . ,coords) ,_id ,_plist) map)
+ (pcase-exhaustive type
+ ('rect
+ (setf (caar coords) (round (* (caar coords) scale)))
+ (setf (cdar coords) (round (* (cdar coords) scale)))
+ (setf (cadr coords) (round (* (cadr coords) scale)))
+ (setf (cddr coords) (round (* (cddr coords) scale))))
+ ('circle
+ (setf (caar coords) (round (* (caar coords) scale)))
+ (setf (cdar coords) (round (* (cdar coords) scale)))
+ (setcdr coords (round (* (cdr coords) scale))))
+ ('poly
+ (dotimes (i (length coords))
+ (aset coords i
+ (round (* (aref coords i) scale)))))))
map)
(defun image--rotate-map (map rotation size)
"Rotate MAP according to ROTATION and SIZE.
+ROTATION must be a non-zero multiple of 90.
Destructively modifies and returns MAP."
- (unless (zerop rotation)
- (pcase-dolist (`(,`(,type . ,coords) ,_id ,_plist) map)
- (pcase-exhaustive type
- ('rect
- (let ( x0 y0 ; New upper left corner
- x1 y1) ; New bottom right corner
- (pcase (truncate (mod rotation 360)) ; Set new corners to...
- (90 ; ...old bottom left and upper right
- (setq x0 (caar coords) y0 (cddr coords)
- x1 (cadr coords) y1 (cdar coords)))
- (180 ; ...old bottom right and upper left
- (setq x0 (cadr coords) y0 (cddr coords)
- x1 (caar coords) y1 (cdar coords)))
- (270 ; ...old upper right and bottom left
- (setq x0 (cadr coords) y0 (cdar coords)
- x1 (caar coords) y1 (cddr coords))))
- (setcar coords (image--rotate-coord x0 y0 rotation size))
- (setcdr coords (image--rotate-coord x1 y1 rotation size))))
- ('circle
- (setcar coords (image--rotate-coord
- (caar coords) (cdar coords) rotation size)))
- ('poly
- (dotimes (i (length coords))
- (when (= 0 (% i 2))
- (pcase-let ((`(,x . ,y)
- (image--rotate-coord
- (aref coords i) (aref coords (1+ i)) rotation size)))
- (aset coords i x)
- (aset coords (1+ i) y))))))))
+ (setq rotation (mod rotation 360))
+ (pcase-dolist (`(,`(,type . ,coords) ,_id ,_plist) map)
+ (pcase-exhaustive type
+ ('rect
+ (let ( x0 y0 ; New upper left corner
+ x1 y1) ; New bottom right corner
+ (pcase rotation ; Set new corners to...
+ (90 ; ...old bottom left and upper right
+ (setq x0 (caar coords) y0 (cddr coords)
+ x1 (cadr coords) y1 (cdar coords)))
+ (180 ; ...old bottom right and upper left
+ (setq x0 (cadr coords) y0 (cddr coords)
+ x1 (caar coords) y1 (cdar coords)))
+ (270 ; ...old upper right and bottom left
+ (setq x0 (cadr coords) y0 (cdar coords)
+ x1 (caar coords) y1 (cddr coords))))
+ (setcar coords (image--rotate-coord x0 y0 rotation size))
+ (setcdr coords (image--rotate-coord x1 y1 rotation size))))
+ ('circle
+ (setcar coords (image--rotate-coord
+ (caar coords) (cdar coords) rotation size)))
+ ('poly
+ (dotimes (i (length coords))
+ (when (= 0 (% i 2))
+ (pcase-let ((`(,x . ,y)
+ (image--rotate-coord
+ (aref coords i) (aref coords (1+ i)) rotation size)))
+ (aset coords i x)
+ (aset coords (1+ i) y)))))))
map)
(defun image--rotate-coord (x y angle size)
"Rotate coordinates X and Y by ANGLE in image of SIZE.
-ANGLE must be a multiple of 90. Returns a cons cell of rounded
-coordinates (X1 Y1)."
+ANGLE must be a multiple of 90 in [90 180 270]. Returns a cons cell of
+rounded coordinates (X1 Y1)."
(pcase-let* ((radian (* (/ angle 180.0) float-pi))
(`(,width . ,height) size)
;; y is positive, but we are in the bottom-right quadrant
@@ -1552,25 +1579,24 @@ image--rotate-coord
(y1 (- y1)))
(cons (round x1) (round y1))))
-(defun image--flip-map (map flip size)
- "Horizontally flip MAP according to FLIP and SIZE.
+(defun image--flip-map (map size)
+ "Horizontally flip MAP according to SIZE.
Destructively modifies and returns MAP."
- (when flip
- (pcase-dolist (`(,`(,type . ,coords) ,_id ,_plist) map)
- (pcase-exhaustive type
- ('rect
- (let ((x0 (- (car size) (cadr coords)))
- (y0 (cdar coords))
- (x1 (- (car size) (caar coords)))
- (y1 (cddr coords)))
- (setcar coords (cons x0 y0))
- (setcdr coords (cons x1 y1))))
- ('circle
- (setf (caar coords) (- (car size) (caar coords))))
- ('poly
- (dotimes (i (length coords))
- (when (= 0 (% i 2))
- (aset coords i (- (car size) (aref coords i)))))))))
+ (pcase-dolist (`(,`(,type . ,coords) ,_id ,_plist) map)
+ (pcase-exhaustive type
+ ('rect
+ (let ((x0 (- (car size) (cadr coords)))
+ (y0 (cdar coords))
+ (x1 (- (car size) (caar coords)))
+ (y1 (cddr coords)))
+ (setcar coords (cons x0 y0))
+ (setcdr coords (cons x1 y1))))
+ ('circle
+ (setf (caar coords) (- (car size) (caar coords))))
+ ('poly
+ (dotimes (i (length coords))
+ (when (= 0 (% i 2))
+ (aset coords i (- (car size) (aref coords i))))))))
map)
(provide 'image)
diff --git a/test/lisp/image-tests.el b/test/lisp/image-tests.el
index 6a5f03e38a0..020781eff50 100644
--- a/test/lisp/image-tests.el
+++ b/test/lisp/image-tests.el
@@ -158,7 +158,7 @@ image-rotate
(ert-deftest image-create-image-with-map ()
"Test that `create-image' correctly adds :map and/or :original-map."
(skip-unless (display-images-p))
- (let ((data "foo")
+ (let ((data "<svg width=\"30\" height=\"30\" version=\"1.1\" xmlns=\"http://www.w3.org/2000/svg\" xmlns:xlink=\"http://www.w3.org/1999/xlink\"></svg>")
(map '(((circle (1 . 1) . 1) a)))
(original-map '(((circle (2 . 2) . 2) a)))
(original-map-other '(((circle (3 . 3) . 3) a))))
@@ -282,7 +282,7 @@ image-transform-map
'(((circle (12 . 4) . 2) "circle")
((rect (7 . 3) 9 . 8) "rect")
((poly . [4 6 2 7 1 2]) "poly"))))
- (should (equal (image--flip-map (copy-tree map t) t `(,width . ,height))
+ (should (equal (image--flip-map (copy-tree map t) `(,width . ,height))
'(((circle (6 . 3) . 2) "circle")
((rect (2 . 6) 7 . 8) "rect")
((poly . [4 11 3 13 8 14]) "poly"))))
@@ -291,7 +291,7 @@ image-transform-map
;; Scale size because the map has been scaled.
(image--rotate-map copy 90 `(,(* 2 width) . ,(* 2 height)))
;; Swap width and height because the map has been flipped.
- (image--flip-map copy t `(,(* 2 height) . ,(* 2 width)))
+ (image--flip-map copy `(,(* 2 height) . ,(* 2 width)))
(should (equal copy
'(((circle (6 . 8) . 4) "circle")
((rect (12 . 6) 16 . 16) "rect")
^ permalink raw reply related [relevance 0%]
* bug#69992: Minor improvement to image map transformation logic
2024-03-30 12:59 0% ` David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-03-30 19:07 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 0 replies; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-03-30 19:07 UTC (permalink / raw)
To: David Ponce; +Cc: Eli Zaretskii, 69992
David Ponce <da_vid@orange.fr> writes:
> Here is my last patch. The only change compared to the previous patch is that
> now the scale factor is correctly calculated based on the size of the image and
> the displayed size. To minimize the performance impact, I saved a call to
> `image-size' by doing the calculation directly in the `image--compute-map' and
> `image--compute-original-map' functions. I did some benchmarks and the
> difference is not significant. The tests still give the same results :-)
Thank you for these fixes and optimizations!!! The tests pass for me.
> Here is the new change log:
>
> 2024-03-30 David Ponce <da_vid@orange.fr>
>
> * lisp/image.el (image--compute-rotation): New function.
> (image--compute-map, image--compute-original-map): Use it.
> Ensure all transformations are applied or undone according to what
> Emacs does internally. Call a transformation function only when
> needed. Fix doc string.
With this fix, I think we can remove `image-tests--map-equal'. I'll
submit a new bug.
> (image--scale-map): Assume effective scale argument.
> (image--rotate-map): Assume effective rotation argument.
> (image--rotate-coord): Improve doc string.
> (image--flip-map): Remove no more used flip argument.
>
> * test/lisp/image-tests.el (image-create-image-with-map): Use a
> valid SVG image otherwise `image-size' will not return a valid
> value and calculation of scale could fail.
> (image-transform-map): Update according to changed signature of
> image--flip-map.
>
> Thanks!
>
> [2. text/x-patch; image-compute-map-V2.patch]...
^ permalink raw reply [relevance 5%]
* bug#70093: Remove unnecessary `image-tests--map-equal'
@ 2024-03-30 19:44 5% Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-30 22:04 5% ` bug#70093: *** SPAM *** " David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-31 5:10 0% ` Eli Zaretskii
0 siblings, 2 replies; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-03-30 19:44 UTC (permalink / raw)
To: 70093; +Cc: Eli Zaretskii, David Ponce
With the resolution of bug#69992, it may be possible to remove the
`image-tests--map-equal' equality predicate from lisp/image-tests.el.
Eli and David, would you please apply the attached patch and then run
the tests to see if we still need to allow for tolerances in
`image--compute-map-and-original-map'?
The tests pass for me, but then again, they never failed on my machine...
Thank you!! I'm grateful for this fun collaboration. :)
Joseph
^ permalink raw reply [relevance 5%]
* bug#70093: *** SPAM *** bug#70093: Remove unnecessary `image-tests--map-equal'
2024-03-30 19:44 5% bug#70093: Remove unnecessary `image-tests--map-equal' Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-03-30 22:04 5% ` David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-31 7:37 8% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-31 5:10 0% ` Eli Zaretskii
1 sibling, 1 reply; 200+ results
From: David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-03-30 22:04 UTC (permalink / raw)
To: Joseph Turner, 70093; +Cc: Eli Zaretskii
On 30/03/2024 20:44, Joseph Turner wrote:
> With the resolution of bug#69992, it may be possible to remove the
> `image-tests--map-equal' equality predicate from lisp/image-tests.el.
>
> Eli and David, would you please apply the attached patch and then run
> the tests to see if we still need to allow for tolerances in
> `image--compute-map-and-original-map'?
>
> The tests pass for me, but then again, they never failed on my machine...
>
> Thank you!! I'm grateful for this fun collaboration. :)
>
> Joseph
>
>
Hi Joseph,
Did you forget to attach the patch? I cannot find it.
Anyway, I don't think the resolution of bug#69992 changed anything
regarding the test `image--compute-map-and-original-map'. And to
be honest I don't understand why it gives a different result on our
configurations.
To test, I also eval the following simple code in *scratch* buffer,
which gives me consistent results on my laptop:
(let* ((svg (svg-create 200 100))
(omap `(((rect . ((0 . 0) . (50 . 50)))
rect-test (help-echo "rect-test"))
((circle . ((85 . 55) . 25))
circle-test (help-echo "circle-test"))
((poly . [100 0 125 0 170 50 125 50])
poly-test (help-echo "poly-test")))))
(svg-rectangle svg 0 0 50 50
:stroke-width 0 :fill "red")
(svg-circle svg 85 55 25
:stroke-width 0 :fill "green")
(svg-polyline svg '((100 . 0) (125 . 0) (170 . 50) (125 . 50))
:stroke-width 0 :fill "blue")
(let ((image (svg-image svg
:original-map omap
:scale nil ;; vary scale test
:rotation nil ;; vary rotation test
:flip nil ;; vary flip test
)))
;; Must see the pointer and help-echo change when mouse hovers the
;; rect, circle and poly hot spots.
(insert-image image)
(insert ?\n)
;; Must see the same original map.
(image--compute-original-map image)))
Thanks!
^ permalink raw reply [relevance 5%]
* bug#70093: Remove unnecessary `image-tests--map-equal'
2024-03-30 19:44 5% bug#70093: Remove unnecessary `image-tests--map-equal' Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-30 22:04 5% ` bug#70093: *** SPAM *** " David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-03-31 5:10 0% ` Eli Zaretskii
2024-03-31 5:32 8% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 1 reply; 200+ results
From: Eli Zaretskii @ 2024-03-31 5:10 UTC (permalink / raw)
To: Joseph Turner; +Cc: 70093, da_vid
> Cc: Eli Zaretskii <eliz@gnu.org>, David Ponce <da_vid@orange.fr>
> From: Joseph Turner <joseph@breatheoutbreathe.in>
> Date: Sat, 30 Mar 2024 12:44:14 -0700
>
> With the resolution of bug#69992, it may be possible to remove the
> `image-tests--map-equal' equality predicate from lisp/image-tests.el.
Why is it a good idea to remove tests? If the test tests some of our
code which should work as the test assumes, we should not remove it.
> Eli and David, would you please apply the attached patch and then run
> the tests to see if we still need to allow for tolerances in
> `image--compute-map-and-original-map'?
ENOPATCH
^ permalink raw reply [relevance 0%]
* bug#70093: Remove unnecessary `image-tests--map-equal'
2024-03-31 5:10 0% ` Eli Zaretskii
@ 2024-03-31 5:32 8% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-31 7:33 0% ` Eli Zaretskii
0 siblings, 1 reply; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-03-31 5:32 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 70093, da_vid
[-- Attachment #1: Type: text/plain, Size: 878 bytes --]
Eli Zaretskii <eliz@gnu.org> writes:
>> Cc: Eli Zaretskii <eliz@gnu.org>, David Ponce <da_vid@orange.fr>
>> From: Joseph Turner <joseph@breatheoutbreathe.in>
>> Date: Sat, 30 Mar 2024 12:44:14 -0700
>>
>> With the resolution of bug#69992, it may be possible to remove the
>> `image-tests--map-equal' equality predicate from lisp/image-tests.el.
>
> Why is it a good idea to remove tests? If the test tests some of our
> code which should work as the test assumes, we should not remove it.
Not removing tests, but rather making the tests more strict (if possible).
>> Eli and David, would you please apply the attached patch and then run
>> the tests to see if we still need to allow for tolerances in
>> `image--compute-map-and-original-map'?
>
> ENOPATCH
Sorry about that. Please check if the tests still pass on your machine
when we use `equal' to compare image maps.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Compare-image-maps-with-equal-in-tests.patch --]
[-- Type: text/x-diff, Size: 4386 bytes --]
From e85fd88a2943fa95d2d7eea3a542308adaa81582 Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Sat, 30 Mar 2024 12:38:52 -0700
Subject: [PATCH] Compare image maps with `equal' in tests
With the fixes to image map transformation introduced in cc212ea314d,
the tests should now exactly predict calculated image maps.
* test/lisp/image-tests.el (image-tests--map-equal): Remove function.
(image--compute-map-and-original-map): Use equal to compare image maps.
---
test/lisp/image-tests.el | 46 +++++-----------------------------------
1 file changed, 5 insertions(+), 41 deletions(-)
diff --git a/test/lisp/image-tests.el b/test/lisp/image-tests.el
index 020781eff50..41b87b8d337 100644
--- a/test/lisp/image-tests.el
+++ b/test/lisp/image-tests.el
@@ -178,37 +178,6 @@ image-create-image-with-map
(got-original-map (image-property image :original-map)))
(should (equal got-original-map original-map-other)))))
-(defun image-tests--map-equal (a b &optional tolerance)
- "Return t if maps A and B have the same coordinates within TOLERANCE.
-Since image sizes calculations vary on different machines, this function
-allows for each image map coordinate in A to be within TOLERANCE to the
-corresponding coordinate in B. When nil, TOLERANCE defaults to 5."
- (unless tolerance (setq tolerance 5))
- (catch 'different
- (cl-labels ((check-tolerance
- (coord-a coord-b)
- (unless (>= tolerance (abs (- coord-a coord-b)))
- (throw 'different nil))))
- (dotimes (i (length a))
- (pcase-let ((`((,type-a . ,coords-a) ,_id ,_plist) (nth i a))
- (`((,type-b . ,coords-b) ,_id ,_plist) (nth i b)))
- (unless (eq type-a type-b)
- (throw 'different nil))
- (pcase-exhaustive type-a
- ('rect
- (check-tolerance (caar coords-a) (caar coords-b))
- (check-tolerance (cdar coords-a) (cdar coords-b))
- (check-tolerance (cadr coords-a) (cadr coords-b))
- (check-tolerance (cddr coords-a) (cddr coords-b)))
- ('circle
- (check-tolerance (caar coords-a) (caar coords-b))
- (check-tolerance (cdar coords-a) (cdar coords-b))
- (check-tolerance (cdar coords-a) (cdar coords-b)))
- ('poly
- (dotimes (i (length coords-a))
- (check-tolerance (aref coords-a i) (aref coords-b i))))))))
- t))
-
(ert-deftest image--compute-map-and-original-map ()
"Test `image--compute-map' and `image--compute-original-map'."
(skip-unless (display-images-p))
@@ -237,25 +206,20 @@ image--compute-map-and-original-map
:scale 2 :rotation 90 :flip t)))
;; Test that `image--compute-original-map' correctly generates
;; original-map when creating an already transformed image.
- (should (image-tests--map-equal (image-property image :original-map)
- original-map))
+ (should (equal (image-property image :original-map) original-map))
(setf (image-property image :flip) nil)
(setf (image-property image :rotation) 0)
(setf (image-property image :scale) 2)
- (should (image-tests--map-equal (image--compute-map image)
- scaled-map))
+ (should (equal (image--compute-map image) scaled-map))
(setf (image-property image :scale) 1)
(setf (image-property image :rotation) 90)
- (should (image-tests--map-equal (image--compute-map image)
- rotated-map))
+ (should (equal (image--compute-map image) rotated-map))
(setf (image-property image :rotation) 0)
(setf (image-property image :flip) t)
- (should (image-tests--map-equal (image--compute-map image)
- flipped-map))
+ (should (equal (image--compute-map image) flipped-map))
(setf (image-property image :scale) 2)
(setf (image-property image :rotation) 90)
- (should (image-tests--map-equal (image--compute-map image)
- scaled-rotated-flipped-map))
+ (should (equal (image--compute-map image) scaled-rotated-flipped-map))
;; Uncomment to test manually by interactively transforming the
;; image and checking the map boundaries by hovering them.
--
2.41.0
^ permalink raw reply related [relevance 8%]
* bug#70093: Remove unnecessary `image-tests--map-equal'
2024-03-31 5:32 8% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-03-31 7:33 0% ` Eli Zaretskii
0 siblings, 0 replies; 200+ results
From: Eli Zaretskii @ 2024-03-31 7:33 UTC (permalink / raw)
To: Joseph Turner; +Cc: 70093, da_vid
> From: Joseph Turner <joseph@breatheoutbreathe.in>
> Cc: 70093@debbugs.gnu.org, da_vid@orange.fr
> Date: Sat, 30 Mar 2024 22:32:26 -0700
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> Cc: Eli Zaretskii <eliz@gnu.org>, David Ponce <da_vid@orange.fr>
> >> From: Joseph Turner <joseph@breatheoutbreathe.in>
> >> Date: Sat, 30 Mar 2024 12:44:14 -0700
> >>
> >> With the resolution of bug#69992, it may be possible to remove the
> >> `image-tests--map-equal' equality predicate from lisp/image-tests.el.
> >
> > Why is it a good idea to remove tests? If the test tests some of our
> > code which should work as the test assumes, we should not remove it.
>
> Not removing tests, but rather making the tests more strict (if possible).
>
> >> Eli and David, would you please apply the attached patch and then run
> >> the tests to see if we still need to allow for tolerances in
> >> `image--compute-map-and-original-map'?
> >
> > ENOPATCH
>
> Sorry about that. Please check if the tests still pass on your machine
> when we use `equal' to compare image maps.
They pass, thanks.
^ permalink raw reply [relevance 0%]
* bug#70093: *** SPAM *** bug#70093: Remove unnecessary `image-tests--map-equal'
2024-03-30 22:04 5% ` bug#70093: *** SPAM *** " David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-03-31 7:37 8% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-31 10:08 4% ` David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-03-31 7:37 UTC (permalink / raw)
To: David Ponce; +Cc: 70093, Eli Zaretskii
[-- Attachment #1: Type: text/plain, Size: 2698 bytes --]
David Ponce <da_vid@orange.fr> writes:
> On 30/03/2024 20:44, Joseph Turner wrote:
>> With the resolution of bug#69992, it may be possible to remove the
>> `image-tests--map-equal' equality predicate from lisp/image-tests.el.
>> Eli and David, would you please apply the attached patch and then
>> run
>> the tests to see if we still need to allow for tolerances in
>> `image--compute-map-and-original-map'?
>> The tests pass for me, but then again, they never failed on my
>> machine...
>> Thank you!! I'm grateful for this fun collaboration. :)
>> Joseph
>>
>
> Hi Joseph,
>
> Did you forget to attach the patch? I cannot find it.
Apologies. Here it is. (This is the same patch as in my response to Eli)
> Anyway, I don't think the resolution of bug#69992 changed anything
> regarding the test `image--compute-map-and-original-map'. And to
> be honest I don't understand why it gives a different result on our
> configurations.
I thought perhaps calculating scale with
(/ (float (car size))
(car (image-size
(image--image-without-parameters image) t)))
instead of
(or (image-property image :scale) 1)
would fix the variations on our machines.
> To test, I also eval the following simple code in *scratch* buffer,
> which gives me consistent results on my laptop:
>
> (let* ((svg (svg-create 200 100))
> (omap `(((rect . ((0 . 0) . (50 . 50)))
> rect-test (help-echo "rect-test"))
> ((circle . ((85 . 55) . 25))
> circle-test (help-echo "circle-test"))
> ((poly . [100 0 125 0 170 50 125 50])
> poly-test (help-echo "poly-test")))))
> (svg-rectangle svg 0 0 50 50
> :stroke-width 0 :fill "red")
> (svg-circle svg 85 55 25
> :stroke-width 0 :fill "green")
> (svg-polyline svg '((100 . 0) (125 . 0) (170 . 50) (125 . 50))
> :stroke-width 0 :fill "blue")
> (let ((image (svg-image svg
> :original-map omap
> :scale nil ;; vary scale test
> :rotation nil ;; vary rotation test
> :flip nil ;; vary flip test
> )))
> ;; Must see the pointer and help-echo change when mouse hovers the
> ;; rect, circle and poly hot spots.
> (insert-image image)
> (insert ?\n)
> ;; Must see the same original map.
> (image--compute-original-map image)))
This manual test also works on my machine. I had been doing something
similar; I like your use of svg-create :)
Let me know if the unit tests pass with this patch applied.
Thank you!
Joseph
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Compare-image-maps-with-equal-in-tests.patch --]
[-- Type: text/x-diff, Size: 4386 bytes --]
From e85fd88a2943fa95d2d7eea3a542308adaa81582 Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Sat, 30 Mar 2024 12:38:52 -0700
Subject: [PATCH] Compare image maps with `equal' in tests
With the fixes to image map transformation introduced in cc212ea314d,
the tests should now exactly predict calculated image maps.
* test/lisp/image-tests.el (image-tests--map-equal): Remove function.
(image--compute-map-and-original-map): Use equal to compare image maps.
---
test/lisp/image-tests.el | 46 +++++-----------------------------------
1 file changed, 5 insertions(+), 41 deletions(-)
diff --git a/test/lisp/image-tests.el b/test/lisp/image-tests.el
index 020781eff50..41b87b8d337 100644
--- a/test/lisp/image-tests.el
+++ b/test/lisp/image-tests.el
@@ -178,37 +178,6 @@ image-create-image-with-map
(got-original-map (image-property image :original-map)))
(should (equal got-original-map original-map-other)))))
-(defun image-tests--map-equal (a b &optional tolerance)
- "Return t if maps A and B have the same coordinates within TOLERANCE.
-Since image sizes calculations vary on different machines, this function
-allows for each image map coordinate in A to be within TOLERANCE to the
-corresponding coordinate in B. When nil, TOLERANCE defaults to 5."
- (unless tolerance (setq tolerance 5))
- (catch 'different
- (cl-labels ((check-tolerance
- (coord-a coord-b)
- (unless (>= tolerance (abs (- coord-a coord-b)))
- (throw 'different nil))))
- (dotimes (i (length a))
- (pcase-let ((`((,type-a . ,coords-a) ,_id ,_plist) (nth i a))
- (`((,type-b . ,coords-b) ,_id ,_plist) (nth i b)))
- (unless (eq type-a type-b)
- (throw 'different nil))
- (pcase-exhaustive type-a
- ('rect
- (check-tolerance (caar coords-a) (caar coords-b))
- (check-tolerance (cdar coords-a) (cdar coords-b))
- (check-tolerance (cadr coords-a) (cadr coords-b))
- (check-tolerance (cddr coords-a) (cddr coords-b)))
- ('circle
- (check-tolerance (caar coords-a) (caar coords-b))
- (check-tolerance (cdar coords-a) (cdar coords-b))
- (check-tolerance (cdar coords-a) (cdar coords-b)))
- ('poly
- (dotimes (i (length coords-a))
- (check-tolerance (aref coords-a i) (aref coords-b i))))))))
- t))
-
(ert-deftest image--compute-map-and-original-map ()
"Test `image--compute-map' and `image--compute-original-map'."
(skip-unless (display-images-p))
@@ -237,25 +206,20 @@ image--compute-map-and-original-map
:scale 2 :rotation 90 :flip t)))
;; Test that `image--compute-original-map' correctly generates
;; original-map when creating an already transformed image.
- (should (image-tests--map-equal (image-property image :original-map)
- original-map))
+ (should (equal (image-property image :original-map) original-map))
(setf (image-property image :flip) nil)
(setf (image-property image :rotation) 0)
(setf (image-property image :scale) 2)
- (should (image-tests--map-equal (image--compute-map image)
- scaled-map))
+ (should (equal (image--compute-map image) scaled-map))
(setf (image-property image :scale) 1)
(setf (image-property image :rotation) 90)
- (should (image-tests--map-equal (image--compute-map image)
- rotated-map))
+ (should (equal (image--compute-map image) rotated-map))
(setf (image-property image :rotation) 0)
(setf (image-property image :flip) t)
- (should (image-tests--map-equal (image--compute-map image)
- flipped-map))
+ (should (equal (image--compute-map image) flipped-map))
(setf (image-property image :scale) 2)
(setf (image-property image :rotation) 90)
- (should (image-tests--map-equal (image--compute-map image)
- scaled-rotated-flipped-map))
+ (should (equal (image--compute-map image) scaled-rotated-flipped-map))
;; Uncomment to test manually by interactively transforming the
;; image and checking the map boundaries by hovering them.
--
2.41.0
^ permalink raw reply related [relevance 8%]
* bug#70093: *** SPAM *** bug#70093: Remove unnecessary `image-tests--map-equal'
2024-03-31 7:37 8% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-03-31 10:08 4% ` David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 200+ results
From: David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-03-31 10:08 UTC (permalink / raw)
To: Joseph Turner; +Cc: 70093, Eli Zaretskii
On 31/03/2024 09:37, Joseph Turner wrote:
>
> David Ponce <da_vid@orange.fr> writes:
>
>> On 30/03/2024 20:44, Joseph Turner wrote:
>>> With the resolution of bug#69992, it may be possible to remove the
>>> `image-tests--map-equal' equality predicate from lisp/image-tests.el.
>>> Eli and David, would you please apply the attached patch and then
>>> run
>>> the tests to see if we still need to allow for tolerances in
>>> `image--compute-map-and-original-map'?
>>> The tests pass for me, but then again, they never failed on my
>>> machine...
>>> Thank you!! I'm grateful for this fun collaboration. :)
>>> Joseph
>>>
>>
>> Hi Joseph,
>>
>> Did you forget to attach the patch? I cannot find it.
>
> Apologies. Here it is. (This is the same patch as in my response to Eli)
>
>> Anyway, I don't think the resolution of bug#69992 changed anything
>> regarding the test `image--compute-map-and-original-map'. And to
>> be honest I don't understand why it gives a different result on our
>> configurations.
>
> I thought perhaps calculating scale with
>
> (/ (float (car size))
> (car (image-size
> (image--image-without-parameters image) t)))
>
> instead of
>
> (or (image-property image :scale) 1)
>
> would fix the variations on our machines.
>
>> To test, I also eval the following simple code in *scratch* buffer,
>> which gives me consistent results on my laptop:
>>
>> (let* ((svg (svg-create 200 100))
>> (omap `(((rect . ((0 . 0) . (50 . 50)))
>> rect-test (help-echo "rect-test"))
>> ((circle . ((85 . 55) . 25))
>> circle-test (help-echo "circle-test"))
>> ((poly . [100 0 125 0 170 50 125 50])
>> poly-test (help-echo "poly-test")))))
>> (svg-rectangle svg 0 0 50 50
>> :stroke-width 0 :fill "red")
>> (svg-circle svg 85 55 25
>> :stroke-width 0 :fill "green")
>> (svg-polyline svg '((100 . 0) (125 . 0) (170 . 50) (125 . 50))
>> :stroke-width 0 :fill "blue")
>> (let ((image (svg-image svg
>> :original-map omap
>> :scale nil ;; vary scale test
>> :rotation nil ;; vary rotation test
>> :flip nil ;; vary flip test
>> )))
>> ;; Must see the pointer and help-echo change when mouse hovers the
>> ;; rect, circle and poly hot spots.
>> (insert-image image)
>> (insert ?\n)
>> ;; Must see the same original map.
>> (image--compute-original-map image)))
>
> This manual test also works on my machine. I had been doing something
> similar; I like your use of svg-create :)
>
> Let me know if the unit tests pass with this patch applied.
>
> Thank you!
>
> Joseph
>
Hello,
With the patch applied the test fails the same for me:
_______________________________________________________________
Selector: image--compute-map-and-original-map
Passed: 0
Failed: 1 (1 unexpected)
Skipped: 0
Total: 1/1
Started at: 2024-03-31 11:17:56+0200
Finished.
Finished at: 2024-03-31 11:17:56+0200
F
F image--compute-map-and-original-map
Test ‘image--compute-map’ and ‘image--compute-original-map’.
(ert-test-failed
((should (equal (image--compute-map image) rotated-map)) :form
(equal
(((circle ... . 24) "a" (help-echo "A"))
((rect ... 127 . 77) "b" (help-echo "B"))
((poly . [199 161 206 160 213 154 218 146 221 136 ...]) "c"
(help-echo "C")))
(((circle ... . 24) "a" (help-echo "A"))
((rect ... 54 . 77) "b" (help-echo "B"))
((poly . [126 161 133 160 140 154 145 146 148 136 ...]) "c"
(help-echo "C"))))
:value nil :explanation (list-elt 0 (list-elt 0 (cdr (car ...))))))
_______________________________________________________________
More in detail, these 3 tests pass:
1.
(should (equal (image-property image :original-map)
original-map))
2.
(setf (image-property image :flip) nil)
(setf (image-property image :rotation) 0)
(setf (image-property image :scale) 2)
(should (equal (image--compute-map image)
scaled-map))
3.
(setf (image-property image :scale) 2)
(setf (image-property image :rotation) 90)
(should (equal (image--compute-map image)
scaled-rotated-flipped-map))
But these 2 tests fails:
1.
(setf (image-property image :scale) 1)
(setf (image-property image :rotation) 90)
(should (equal (image--compute-map image)
rotated-map))
;; Return
((((circle (199 . 41) . 24) "a" (help-echo "A"))
((rect (79 . 5) 127 . 77) "b" (help-echo "B"))
((poly . [199 161 206 160 213 154 218 146 221 136 223 125 221 114 218 104 213 96 206 91 199 89 191 91 185 96 179 104 176 114 175 125 176 136 179 146 185 154 191 160]) "c" (help-echo "C")))
;; Instead of
(((circle (126 . 41) . 24) "a" (help-echo "A"))
((rect (6 . 5) 54 . 77) "b" (help-echo "B"))
((poly . [126 161 133 160 140 154 145 146 148 136 150 125 148 114 145 104 140 96 133 91 126 89 118 91 112 96 106 104 103 114 102 125 103 136 106 146 112 154 118 160]) "c" (help-echo "C"))))
;; All the result X coords are different, but Y coords are expected.
2.
(setf (image-property image :rotation) 0)
(setf (image-property image :flip) t)
(should (equal (image--compute-map image)
flipped-map))
;; Return
((((circle (205 . 29) . 24) "a" (help-echo "A"))
((rect (169 . 101) 241 . 149) "b" (help-echo "B"))
((poly . [85 29 86 22 92 15 100 10 110 7 121 5 132 7 142 10 150 15 155 22 157 29 155 37 150 43 142 49 132 52 121 53 110 52 100 49 92 43 86 37]) "c" (help-echo "C")))
;; Instead of
(((circle (125 . 29) . 24) "a" (help-echo "A"))
((rect (89 . 101) 161 . 149) "b" (help-echo "B"))
((poly . [5 29 6 22 12 15 20 10 30 7 41 5 52 7 62 10 70 15 75 22 77 29 75 37 70 43 62 49 52 52 41 53 30 52 20 49 12 43 6 37]) "c" (help-echo "C"))))
;; All the result X coords are different, but Y coords are expected.
On my laptop:
(image-size (image--image-without-parameters image) t) => (228 . 246)
Hope it will help to understand the reason.
Thanks!
^ permalink raw reply [relevance 4%]
* bug#70213: Info-mode side window fit-window-to-buffer issue
@ 2024-04-05 8:57 5% Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-05 12:30 0% ` Eli Zaretskii
0 siblings, 2 replies; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-04-05 8:57 UTC (permalink / raw)
To: 70213
With emacs -Q on 29, evaluate:
(setq display-buffer-alist
'(((derived-mode . Info-mode)
display-buffer-in-side-window
(side . right)
(window-width . fit-window-to-buffer))))
Then press C-h i
Expected: Info-mode buffer pops up in right side window.
Actual: Info-mode buffer pops up in full frame.
At this point, pressing C-h i once more does open a right side window.
I haven't been able to reproduce this this issue with any other mode.
Thanks!
Joseph
^ permalink raw reply [relevance 5%]
* bug#70213: Info-mode side window fit-window-to-buffer issue
2024-04-05 8:57 5% bug#70213: Info-mode side window fit-window-to-buffer issue Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-04-05 12:30 0% ` Eli Zaretskii
2024-04-05 15:04 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 1 reply; 200+ results
From: Eli Zaretskii @ 2024-04-05 12:30 UTC (permalink / raw)
To: Joseph Turner; +Cc: 70213
tags 70213 notabug
thanks
> Date: Fri, 05 Apr 2024 01:57:13 -0700
> From: Joseph Turner via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>
> With emacs -Q on 29, evaluate:
>
> (setq display-buffer-alist
> '(((derived-mode . Info-mode)
> display-buffer-in-side-window
> (side . right)
> (window-width . fit-window-to-buffer))))
>
> Then press C-h i
>
> Expected: Info-mode buffer pops up in right side window.
>
> Actual: Info-mode buffer pops up in full frame.
>
> At this point, pressing C-h i once more does open a right side window.
>
> I haven't been able to reproduce this this issue with any other mode.
I'm not interested in fixing this: Info is not intended to be run in a
side window. For starters, the text of an Info file is not meant to
be displayed in narrow windows, and will look ugly at best.
Don't do that!
^ permalink raw reply [relevance 0%]
* bug#70213: Info-mode side window fit-window-to-buffer issue
2024-04-05 12:30 0% ` Eli Zaretskii
@ 2024-04-05 15:04 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-05 15:33 5% ` Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-04-05 15:04 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 70213-done
Eli Zaretskii <eliz@gnu.org> writes:
> tags 70213 notabug
> thanks
>
>> Date: Fri, 05 Apr 2024 01:57:13 -0700
>> From: Joseph Turner via "Bug reports for GNU Emacs,
>> the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>>
>> With emacs -Q on 29, evaluate:
>>
>> (setq display-buffer-alist
>> '(((derived-mode . Info-mode)
>> display-buffer-in-side-window
>> (side . right)
>> (window-width . fit-window-to-buffer))))
>>
>> Then press C-h i
>>
>> Expected: Info-mode buffer pops up in right side window.
>>
>> Actual: Info-mode buffer pops up in full frame.
>>
>> At this point, pressing C-h i once more does open a right side window.
>>
>> I haven't been able to reproduce this this issue with any other mode.
>
> I'm not interested in fixing this: Info is not intended to be run in a
> side window. For starters, the text of an Info file is not meant to
> be displayed in narrow windows, and will look ugly at best.
>
> Don't do that!
Okay, closing now. What I had been doing is setting the side window with
to 80 columns, which is plenty of space for most Info files.
^ permalink raw reply [relevance 5%]
* bug#70213: Info-mode side window fit-window-to-buffer issue
2024-04-05 15:04 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-04-05 15:33 5% ` Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-05 21:58 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 200+ results
From: Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-04-05 15:33 UTC (permalink / raw)
To: 70213; +Cc: joseph
On Fri, 05 Apr 2024 08:04:28 -0700 Joseph Turner via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org> wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>> tags 70213 notabug
>> thanks
>>
>>> Date: Fri, 05 Apr 2024 01:57:13 -0700
>>> From: Joseph Turner via "Bug reports for GNU Emacs,
>>> the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>>>
>>> With emacs -Q on 29, evaluate:
>>>
>>> (setq display-buffer-alist
>>> '(((derived-mode . Info-mode)
>>> display-buffer-in-side-window
>>> (side . right)
>>> (window-width . fit-window-to-buffer))))
>>>
>>> Then press C-h i
>>>
>>> Expected: Info-mode buffer pops up in right side window.
>>>
>>> Actual: Info-mode buffer pops up in full frame.
>>>
>>> At this point, pressing C-h i once more does open a right side window.
>>>
>>> I haven't been able to reproduce this this issue with any other mode.
>>
>> I'm not interested in fixing this: Info is not intended to be run in a
>> side window. For starters, the text of an Info file is not meant to
>> be displayed in narrow windows, and will look ugly at best.
>>
>> Don't do that!
>
> Okay, closing now. What I had been doing is setting the side window with
> to 80 columns, which is plenty of space for most Info files.
FWIW, I get the expected result with your recipe on master (GNU/Linux,
Gtk3; I don't have emacs-29 at hand to test).
Steve Berman
^ permalink raw reply [relevance 5%]
* bug#70213: Info-mode side window fit-window-to-buffer issue
@ 2024-04-05 21:57 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 0 replies; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-04-05 21:57 UTC (permalink / raw)
To: Juri Linkov; +Cc: 70213
Juri Linkov <juri@linkov.net> writes:
>> With emacs -Q on 29, evaluate:
>>
>> (setq display-buffer-alist
>> '(((derived-mode . Info-mode)
>> display-buffer-in-side-window
>> (side . right)
>> (window-width . fit-window-to-buffer))))
>
> This is already fixed in Emacs 30 via bug#68081.
Thank you very much for this reference!!
Joseph
^ permalink raw reply [relevance 5%]
* bug#70213: Info-mode side window fit-window-to-buffer issue
2024-04-05 15:33 5% ` Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-04-05 21:58 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-05 22:21 5% ` Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-04-05 21:58 UTC (permalink / raw)
To: Stephen Berman; +Cc: 70213
Stephen Berman <stephen.berman@gmx.net> writes:
> On Fri, 05 Apr 2024 08:04:28 -0700 Joseph Turner via "Bug reports for
> GNU Emacs, the Swiss army knife of text editors"
> <bug-gnu-emacs@gnu.org> wrote:
>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>>> tags 70213 notabug
>>> thanks
>>>
>>>> Date: Fri, 05 Apr 2024 01:57:13 -0700
>>>> From: Joseph Turner via "Bug reports for GNU Emacs,
>>>> the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>>>>
>>>> With emacs -Q on 29, evaluate:
>>>>
>>>> (setq display-buffer-alist
>>>> '(((derived-mode . Info-mode)
>>>> display-buffer-in-side-window
>>>> (side . right)
>>>> (window-width . fit-window-to-buffer))))
>>>>
>>>> Then press C-h i
>>>>
>>>> Expected: Info-mode buffer pops up in right side window.
>>>>
>>>> Actual: Info-mode buffer pops up in full frame.
>>>>
>>>> At this point, pressing C-h i once more does open a right side window.
>>>>
>>>> I haven't been able to reproduce this this issue with any other mode.
>>>
>>> I'm not interested in fixing this: Info is not intended to be run in a
>>> side window. For starters, the text of an Info file is not meant to
>>> be displayed in narrow windows, and will look ugly at best.
>>>
>>> Don't do that!
>>
>> Okay, closing now. What I had been doing is setting the side window with
>> to 80 columns, which is plenty of space for most Info files.
>
> FWIW, I get the expected result with your recipe on master (GNU/Linux,
> Gtk3; I don't have emacs-29 at hand to test).
According to the issue that Juri linked to (bug#68081), this issue was
resolved on master. Was your Emacs build since January 6 (since
d3a4fe5694f7bd1a09546d67d2cddc0f444d41ca )?
Thank you!
Joseph
^ permalink raw reply [relevance 5%]
* bug#70213: Info-mode side window fit-window-to-buffer issue
2024-04-05 21:58 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-04-05 22:21 5% ` Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-06 1:34 9% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 200+ results
From: Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-04-05 22:21 UTC (permalink / raw)
To: Joseph Turner; +Cc: 70213
On Fri, 05 Apr 2024 14:58:27 -0700 Joseph Turner <joseph@breatheoutbreathe.in> wrote:
> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> On Fri, 05 Apr 2024 08:04:28 -0700 Joseph Turner via "Bug reports for
>> GNU Emacs, the Swiss army knife of text editors"
>> <bug-gnu-emacs@gnu.org> wrote:
>>
>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>
>>>> tags 70213 notabug
>>>> thanks
>>>>
>>>>> Date: Fri, 05 Apr 2024 01:57:13 -0700
>>>>> From: Joseph Turner via "Bug reports for GNU Emacs,
>>>>> the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>>>>>
>>>>> With emacs -Q on 29, evaluate:
>>>>>
>>>>> (setq display-buffer-alist
>>>>> '(((derived-mode . Info-mode)
>>>>> display-buffer-in-side-window
>>>>> (side . right)
>>>>> (window-width . fit-window-to-buffer))))
>>>>>
>>>>> Then press C-h i
>>>>>
>>>>> Expected: Info-mode buffer pops up in right side window.
>>>>>
>>>>> Actual: Info-mode buffer pops up in full frame.
>>>>>
>>>>> At this point, pressing C-h i once more does open a right side window.
>>>>>
>>>>> I haven't been able to reproduce this this issue with any other mode.
>>>>
>>>> I'm not interested in fixing this: Info is not intended to be run in a
>>>> side window. For starters, the text of an Info file is not meant to
>>>> be displayed in narrow windows, and will look ugly at best.
>>>>
>>>> Don't do that!
>>>
>>> Okay, closing now. What I had been doing is setting the side window with
>>> to 80 columns, which is plenty of space for most Info files.
>>
>> FWIW, I get the expected result with your recipe on master (GNU/Linux,
>> Gtk3; I don't have emacs-29 at hand to test).
>
> According to the issue that Juri linked to (bug#68081), this issue was
> resolved on master.
Yes, I saw Juri's post after I sent mine; I had missed that bug report.
> Was your Emacs build since January 6 (since
> d3a4fe5694f7bd1a09546d67d2cddc0f444d41ca )?
Yep, I'm currently at
09f381d70d8..: Michael Albinus 2024-03-31 Fix wildcard signals in dbusbind.c
Steve Berman
^ permalink raw reply [relevance 5%]
* bug#70213: Info-mode side window fit-window-to-buffer issue
2024-04-05 22:21 5% ` Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-04-06 1:34 9% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-06 11:39 5% ` Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 2 replies; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-04-06 1:34 UTC (permalink / raw)
To: Stephen Berman; +Cc: 70213
[-- Attachment #1: Type: text/plain, Size: 930 bytes --]
Stephen Berman <stephen.berman@gmx.net> writes:
> On Fri, 05 Apr 2024 14:58:27 -0700 Joseph Turner <joseph@breatheoutbreathe.in> wrote:
>
>> Stephen Berman <stephen.berman@gmx.net> writes:
>>> FWIW, I get the expected result with your recipe on master (GNU/Linux,
>>> Gtk3; I don't have emacs-29 at hand to test).
>>
>> According to the issue that Juri linked to (bug#68081), this issue was
>> resolved on master.
>
> Yes, I saw Juri's post after I sent mine; I had missed that bug report.
>
>> Was your Emacs build since January 6 (since
>> d3a4fe5694f7bd1a09546d67d2cddc0f444d41ca )?
>
> Yep, I'm currently at
> 09f381d70d8..: Michael Albinus 2024-03-31 Fix wildcard signals in dbusbind.c
The attached patch fixes this issue, but more would need to be done for
fit-window-to-buffer to be a meaningful value in display-buffer-alist,
since navigating between info nodes doesn't cause the window to resize.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Display-buffer-after-ensuring-it-contains-text.patch --]
[-- Type: text/x-diff, Size: 2436 bytes --]
From f8a2584e3927c149eb2b008de5cb27fb148f08e1 Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Fri, 5 Apr 2024 18:32:36 -0700
Subject: [PATCH] Display buffer after ensuring it contains text
* lisp/info.el (info-pop-to-buffer):
bug#70213
---
lisp/info.el | 44 +++++++++++++++++++++-----------------------
1 file changed, 21 insertions(+), 23 deletions(-)
diff --git a/lisp/info.el b/lisp/info.el
index 1e478cdbee9..fe134161af4 100644
--- a/lisp/info.el
+++ b/lisp/info.el
@@ -807,30 +807,28 @@ info-pop-to-buffer
(get-buffer-create "*info*")))))
(with-current-buffer buffer
(unless (derived-mode-p 'Info-mode)
- (Info-mode)))
+ (Info-mode))
+
+ (if file-or-node
+ ;; If argument already contains parentheses, don't add another set
+ ;; since the argument will then be parsed improperly. This also
+ ;; has the added benefit of allowing node names to be included
+ ;; following the parenthesized filename.
+ (Info-goto-node
+ (if (and (stringp file-or-node) (string-match "(.*)" file-or-node))
+ file-or-node
+ (concat "(" file-or-node ")")))
+ (if (and (zerop (buffer-size))
+ (null Info-history))
+ ;; If we just created the Info buffer, go to the directory.
+ (Info-directory))))
+
+ (when-let ((window (display-buffer buffer
+ (if other-window
+ '(nil (inhibit-same-window . t))
+ '(display-buffer-same-window)))))
+ (select-window window))))
- (let* ((window
- (display-buffer buffer
- (if other-window
- '(nil (inhibit-same-window . t))
- '(display-buffer-same-window)))))
- (with-current-buffer buffer
- (if file-or-node
- ;; If argument already contains parentheses, don't add another set
- ;; since the argument will then be parsed improperly. This also
- ;; has the added benefit of allowing node names to be included
- ;; following the parenthesized filename.
- (Info-goto-node
- (if (and (stringp file-or-node) (string-match "(.*)" file-or-node))
- file-or-node
- (concat "(" file-or-node ")")))
- (if (and (zerop (buffer-size))
- (null Info-history))
- ;; If we just created the Info buffer, go to the directory.
- (Info-directory))))
-
- (when window
- (select-window window)))))
;;;###autoload (put 'info 'info-file (purecopy "emacs"))
;;;###autoload
--
2.41.0
^ permalink raw reply related [relevance 9%]
* bug#70093: *** SPAM *** bug#70093: Remove unnecessary `image-tests--map-equal'
@ 2024-04-06 1:50 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-07 16:01 4% ` David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-04-06 1:50 UTC (permalink / raw)
To: David Ponce; +Cc: 70093, Eli Zaretskii
David Ponce <da_vid@orange.fr> writes:
> [...]> But these 2 tests fails:
>> 1.
>> (setf (image-property image :scale) 1)
>> (setf (image-property image :rotation) 90)
>> (should (equal (image--compute-map image)
>> rotated-map))
>> ;; Return
>> ((((circle (199 . 41) . 24) "a" (help-echo "A"))
>> ((rect (79 . 5) 127 . 77) "b" (help-echo "B"))
>> ((poly . [199 161 206 160 213 154 218 146 221 136 223 125 221
>> 114 218 104 213 96 206 91 199 89 191 91 185 96 179 104 176 114 175
>> 125 176 136 179 146 185 154 191 160]) "c" (help-echo "C")))
>> ;; Instead of
>> (((circle (126 . 41) . 24) "a" (help-echo "A"))
>> ((rect (6 . 5) 54 . 77) "b" (help-echo "B"))
>> ((poly . [126 161 133 160 140 154 145 146 148 136 150 125 148
>> 114 145 104 140 96 133 91 126 89 118 91 112 96 106 104 103 114 102
>> 125 103 136 106 146 112 154 118 160]) "c" (help-echo "C"))))
>> ;; All the result X coords are different, but Y coords are expected.
>> 2.
>> (setf (image-property image :rotation) 0)
>> (setf (image-property image :flip) t)
>> (should (equal (image--compute-map image)
>> flipped-map))
>> ;; Return
>> ((((circle (205 . 29) . 24) "a" (help-echo "A"))
>> ((rect (169 . 101) 241 . 149) "b" (help-echo "B"))
>> ((poly . [85 29 86 22 92 15 100 10 110 7 121 5 132 7 142 10
>> 150 15 155 22 157 29 155 37 150 43 142 49 132 52 121 53 110 52 100
>> 49 92 43 86 37]) "c" (help-echo "C")))
>> ;; Instead of
>> (((circle (125 . 29) . 24) "a" (help-echo "A"))
>> ((rect (89 . 101) 161 . 149) "b" (help-echo "B"))
>> ((poly . [5 29 6 22 12 15 20 10 30 7 41 5 52 7 62 10 70 15 75
>> 22 77 29 75 37 70 43 62 49 52 52 41 53 30 52 20 49 12 43 6 37]) "c"
>> (help-echo "C"))))
>> ;; All the result X coords are different, but Y coords are expected.
>> On my laptop:
>> (image-size (image--image-without-parameters image) t) => (228 .
>> 246)
>> Hope it will help to understand the reason.
> [...]
>
> Hello,
>
> I am still trying to understand why the 2 tests above fails with my configuration.
> From the test `image--compute-map-and-original-map' I wrote the below equivalent
> code to be evaled in the *scratch* buffer, in order to observe and analyze the
> results interactively. The shapes are derived from the hot spots coordinates to
> ensure a strict visual correspondance between a shape and its hot spot.
>
> On my configuration, all the computed map from the different image variations are
> correct. You can test it by hovering the different produced colored shapes with
> the mouse, and observe the mouse pointer and help-echo changes.
>
> My conclusion at this point is that the values of `flipped-map' and `rotated-map'
> are not correct for my configuration, but I don't know why.
>
> If you can try the below code and observe the result on your configuration, maybe
> could we get a better understanding of what is happening for the 2 tests that fail?
>
> Thanks!
>
> ______________________________________________________________________________
>
> (let* ((svg (svg-create "125pt" "116pt")) ;; 246px X 228px on my conf.
> (original-map
> '(((circle (41 . 29) . 24) "a" (help-echo "A"))
> ((rect (5 . 101) 77 . 149) "b" (help-echo "B"))
> ((poly . [ 161 29 160 22 154 15 146 10 136 7 125 5 114 7
> 104 10 96 15 91 22 89 29 91 37 96 43 104 49
> 114 52 125 53 136 52 146 49 154 43 160 37])
> "c" (help-echo "C"))))
> (scaled-map
> '(((circle (82 . 58) . 48) "a" (help-echo "A"))
> ((rect (10 . 202) 154 . 298) "b" (help-echo "B"))
> ((poly . [ 322 58 320 44 308 30 292 20 272 14 250 10 228 14
> 208 20 192 30 182 44 178 58 182 74 192 86 208 98
> 228 104 250 106 272 104 292 98 308 86 320 74])
> "c" (help-echo "C"))))
> (flipped-map
> '(((circle (125 . 29) . 24) "a" (help-echo "A"))
> ((rect (89 . 101) 161 . 149) "b" (help-echo "B"))
> ((poly . [ 5 29 6 22 12 15 20 10 30 7 41 5 52 7 62 10 70 15
> 75 22 77 29 75 37 70 43 62 49 52 52 41 53 30 52
> 20 49 12 43 6 37])
> "c" (help-echo "C"))))
> (rotated-map
> '(((circle (126 . 41) . 24) "a" (help-echo "A"))
> ((rect (6 . 5) 54 . 77) "b" (help-echo "B"))
> ((poly . [ 126 161 133 160 140 154 145 146 148 136 150 125
> 148 114 145 104 140 96 133 91 126 89 118 91
> 112 96 106 104 103 114 102 125 103 136 106 146
> 112 154 118 160])
> "c" (help-echo "C"))))
> (scaled-rotated-flipped-map
> '(((circle (58 . 82) . 48) "a" (help-echo "A"))
> ((rect (202 . 10) 298 . 154) "b" (help-echo "B"))
> ((poly . [ 58 322 44 320 30 308 20 292 14 272 10 250 14 228
> 20 208 30 192 44 182 58 178 74 182 86 192 98 208
> 104 228 106 250 104 272 98 292 86 308 74 320])
> "c" (help-echo "C"))))
> )
> (svg-rectangle svg 5 101 (- 77 5) (- 149 101)
> :stroke-width 0 :fill "red")
> (svg-circle svg 41 29 24
> :stroke-width 0 :fill "green")
> (svg-polyline svg '((161 . 29) (160 . 22) (154 . 15) (146 . 10)
> (136 . 7) (125 . 5) (114 . 7) (104 . 10)
> (96 . 15) (91 . 22) (89 . 29) (91 . 37)
> (96 . 43) (104 . 49) (114 . 52) (125 . 53)
> (136 . 52) (146 . 49) (154 . 43) (160 . 37))
> :stroke-width 0 :fill "blue")
> (let ((image (svg-image svg :map scaled-rotated-flipped-map
> :scale 2 :rotation 90 :flip t)))
> ;; Test that `image--compute-original-map' correctly generates
> ;; original-map when creating an already transformed image.
> (insert
> (format
> "\n:flip %s :rotation %s :scale %s (equal :original-map original-map)=>%s"
> (image-property image :flip)
> (image-property image :rotation)
> (image-property image :scale)
> (equal (image-property image :original-map)
> original-map)))
> (print image)
> (insert-image image)
> (setf (image-property image :flip) nil)
> (setf (image-property image :rotation) 0)
> (setf (image-property image :scale) 2)
> (let ((map (image--compute-map image)))
> (insert
> (format
> "\n:flip %s :rotation %s :scale %s (equal map scaled-map)=>%s"
> (image-property image :flip)
> (image-property image :rotation)
> (image-property image :scale)
> (equal map scaled-map)))
> (setf (image-property image :map) map)
> (print image)
> ;; insert a new image in current buffer.
> (insert-image (copy-tree image t))
> )
>
> (setf (image-property image :scale) 1)
> (setf (image-property image :rotation) 90)
> (let ((map (image--compute-map image)))
> (insert
> (format
> "\n:flip %s :rotation %s :scale %s (equal map rotated-map)=>%s"
> (image-property image :flip)
> (image-property image :rotation)
> (image-property image :scale)
> (equal map rotated-map)))
> (setf (image-property image :map) map)
> (print image)
> ;; insert a new image in current buffer.
> (insert-image (copy-tree image t))
> )
>
> (setf (image-property image :rotation) 0)
> (setf (image-property image :flip) t)
> (let ((map (image--compute-map image)))
> (insert
> (format
> "\n:flip %s :rotation %s :scale %s (equal map flipped-map)=>%s"
> (image-property image :flip)
> (image-property image :rotation)
> (image-property image :scale)
> (equal map flipped-map)))
> (setf (image-property image :map) map)
> (print image)
> ;; insert a new image in current buffer.
> (insert-image (copy-tree image t))
> )
>
> (setf (image-property image :scale) 2)
> (setf (image-property image :rotation) 90)
> (let ((map (image--compute-map image)))
> (insert
> (format
> "\n:flip %s :rotation %s :scale %s (equal map scaled-rotated-flipped-map)=>%s"
> (image-property image :flip)
> (image-property image :rotation)
> (image-property image :scale)
> (equal map scaled-rotated-flipped-map)))
> (setf (image-property image :map) map)
> (print image)
> ;; insert a new image in current buffer.
> (insert-image (copy-tree image t))
> )
> ))
When I evaluate this block and hover over the various shapes, the
help-echo pop-ups appear at the correct boundaries.
Are you able to reproduce this issue with my patch with emacs -Q?
Without the patch?
Thank you!
Joseph
^ permalink raw reply [relevance 5%]
* bug#70213: Info-mode side window fit-window-to-buffer issue
@ 2024-04-06 2:36 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 0 replies; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-04-06 2:36 UTC (permalink / raw)
To: Drew Adams; +Cc: Stephen Berman, 70213@debbugs.gnu.org
Drew Adams <drew.adams@oracle.com> writes:
>> more would need to be done for
>> fit-window-to-buffer to be a meaningful value
>> in display-buffer-alist, since navigating between
>> info nodes doesn't cause the window to resize.
>
> (Caveat: I'm not following this thread.)
>
> In case it helps, in info+.el I fit the
> frame to the Info buffer when user option
> `Info-fit-frame-flag' is non-nil and the
> frame has only the Info window.
>
> I do that in my versions of `Info-search'
> and `Info-find-node-2'. That's all that's
> needed.
>
> Likely the same two places would suffice
> for what you're doing. (But again, I'm
> not following the thread - just guessing
> what you're doing.)
>
> (Dunno why something as general as
> `display-buffer-alist' would need to be
> involved, just to resize Info nodes.)
>
> Hopefully you too will make the behavior
> conditional on a user option.
>
> HTH.
Thanks! Good to know.
I'm willing to leave the current behavior as-is.
^ permalink raw reply [relevance 5%]
* bug#70213: Info-mode side window fit-window-to-buffer issue
2024-04-06 1:34 9% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-04-06 11:39 5% ` Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-06 17:19 4% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 1 reply; 200+ results
From: Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-04-06 11:39 UTC (permalink / raw)
To: Joseph Turner; +Cc: 70213
On Fri, 05 Apr 2024 18:34:11 -0700 Joseph Turner <joseph@breatheoutbreathe.in> wrote:
> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> On Fri, 05 Apr 2024 14:58:27 -0700 Joseph Turner
>> <joseph@breatheoutbreathe.in> wrote:
>>
>>> Stephen Berman <stephen.berman@gmx.net> writes:
>>>> FWIW, I get the expected result with your recipe on master (GNU/Linux,
>>>> Gtk3; I don't have emacs-29 at hand to test).
>>>
>>> According to the issue that Juri linked to (bug#68081), this issue was
>>> resolved on master.
>>
>> Yes, I saw Juri's post after I sent mine; I had missed that bug report.
>>
>>> Was your Emacs build since January 6 (since
>>> d3a4fe5694f7bd1a09546d67d2cddc0f444d41ca )?
>>
>> Yep, I'm currently at
>> 09f381d70d8..: Michael Albinus 2024-03-31 Fix wildcard signals in dbusbind.c
>
> The attached patch fixes this issue, but more would need to be done for
> fit-window-to-buffer to be a meaningful value in display-buffer-alist,
> since navigating between info nodes doesn't cause the window to resize.
I'm confused: by "I get the expected result with your recipe on master"
I meant the Info buffer appears in the window on the right after one
`C-h i', and I confirmed that my build contains the January 6 fix. Are
you saying that does not work for you and you need the patch you posted
instead? (I haven't tried that patch.)
Steve Berman
^ permalink raw reply [relevance 5%]
* bug#70213: Info-mode side window fit-window-to-buffer issue
2024-04-06 11:39 5% ` Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-04-06 17:19 4% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-06 19:19 5% ` Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 2 replies; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-04-06 17:19 UTC (permalink / raw)
To: Stephen Berman; +Cc: 70213
Stephen Berman <stephen.berman@gmx.net> writes:
> On Fri, 05 Apr 2024 18:34:11 -0700 Joseph Turner <joseph@breatheoutbreathe.in> wrote:
>
>> Stephen Berman <stephen.berman@gmx.net> writes:
>>
>>> On Fri, 05 Apr 2024 14:58:27 -0700 Joseph Turner
>>> <joseph@breatheoutbreathe.in> wrote:
>>>
>>>> Stephen Berman <stephen.berman@gmx.net> writes:
>>>>> FWIW, I get the expected result with your recipe on master (GNU/Linux,
>>>>> Gtk3; I don't have emacs-29 at hand to test).
>>>>
>>>> According to the issue that Juri linked to (bug#68081), this issue was
>>>> resolved on master.
>>>
>>> Yes, I saw Juri's post after I sent mine; I had missed that bug report.
>>>
>>>> Was your Emacs build since January 6 (since
>>>> d3a4fe5694f7bd1a09546d67d2cddc0f444d41ca )?
>>>
>>> Yep, I'm currently at
>>> 09f381d70d8..: Michael Albinus 2024-03-31 Fix wildcard signals in dbusbind.c
>>
>> The attached patch fixes this issue, but more would need to be done for
>> fit-window-to-buffer to be a meaningful value in display-buffer-alist,
>> since navigating between info nodes doesn't cause the window to resize.
>
> I'm confused: by "I get the expected result with your recipe on master"
> I meant the Info buffer appears in the window on the right after one
> `C-h i', and I confirmed that my build contains the January 6 fix. Are
> you saying that does not work for you and you need the patch you posted
> instead? (I haven't tried that patch.)
Sorry. In my attempt to simplify the issue, I confused myself.
In emacs -Q on master after Jan 6 patch, eval this:
(progn
(setq fit-window-to-buffer-horizontally t)
(setq display-buffer-alist
'(((derived-mode . Info-mode)
display-buffer-in-side-window
(side . right)
(window-width . fit-window-to-buffer))
((derived-mode . messages-buffer-mode)
display-buffer-in-side-window
(side . right)
(window-width . fit-window-to-buffer)))))
First, to show the expected behavior with *Messages* buffer:
Press C-h e to open the *Messages* buffer. It appears in a side
window on the right fit to the width of the buffer content.
Second, to show the unexpected behavior with *info* buffer:
Ensure no side window state is lying around:
(dolist (buf (list "*Messages*" "*info*"))
(when (get-buffer buf)
(kill-buffer buf)))
Press C-h i to open the *info* buffer. It appears in a side
window on the right with `window-min-width' (default 10), but the
content of the *info* buffer is much wider than its window.
Press C-h i again for the *info* buffer to resize itself.
I would expect the *info* window to fit to the buffer contents
when it first appears. The patch I sent earlier fixes this.
Thanks,
Joseph
^ permalink raw reply [relevance 4%]
* bug#70213: Info-mode side window fit-window-to-buffer issue
2024-04-06 17:19 4% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-04-06 19:19 5% ` Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-07 1:59 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 1 reply; 200+ results
From: Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-04-06 19:19 UTC (permalink / raw)
To: Joseph Turner; +Cc: 70213
On Sat, 06 Apr 2024 10:19:20 -0700 Joseph Turner <joseph@breatheoutbreathe.in> wrote:
> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> On Fri, 05 Apr 2024 18:34:11 -0700 Joseph Turner
>> <joseph@breatheoutbreathe.in> wrote:
>>
>>> Stephen Berman <stephen.berman@gmx.net> writes:
>>>
>>>> On Fri, 05 Apr 2024 14:58:27 -0700 Joseph Turner
>>>> <joseph@breatheoutbreathe.in> wrote:
>>>>
>>>>> Stephen Berman <stephen.berman@gmx.net> writes:
>>>>>> FWIW, I get the expected result with your recipe on master (GNU/Linux,
>>>>>> Gtk3; I don't have emacs-29 at hand to test).
>>>>>
>>>>> According to the issue that Juri linked to (bug#68081), this issue was
>>>>> resolved on master.
>>>>
>>>> Yes, I saw Juri's post after I sent mine; I had missed that bug report.
>>>>
>>>>> Was your Emacs build since January 6 (since
>>>>> d3a4fe5694f7bd1a09546d67d2cddc0f444d41ca )?
>>>>
>>>> Yep, I'm currently at
>>>> 09f381d70d8..: Michael Albinus 2024-03-31 Fix wildcard signals in dbusbind.c
>>>
>>> The attached patch fixes this issue, but more would need to be done for
>>> fit-window-to-buffer to be a meaningful value in display-buffer-alist,
>>> since navigating between info nodes doesn't cause the window to resize.
>>
>> I'm confused: by "I get the expected result with your recipe on master"
>> I meant the Info buffer appears in the window on the right after one
>> `C-h i', and I confirmed that my build contains the January 6 fix. Are
>> you saying that does not work for you and you need the patch you posted
>> instead? (I haven't tried that patch.)
>
> Sorry. In my attempt to simplify the issue, I confused myself.
>
> In emacs -Q on master after Jan 6 patch, eval this:
>
> (progn
> (setq fit-window-to-buffer-horizontally t)
>
> (setq display-buffer-alist
> '(((derived-mode . Info-mode)
> display-buffer-in-side-window
> (side . right)
> (window-width . fit-window-to-buffer))
> ((derived-mode . messages-buffer-mode)
> display-buffer-in-side-window
> (side . right)
> (window-width . fit-window-to-buffer)))))
>
> First, to show the expected behavior with *Messages* buffer:
>
> Press C-h e to open the *Messages* buffer. It appears in a side
> window on the right fit to the width of the buffer content.
>
> Second, to show the unexpected behavior with *info* buffer:
>
> Ensure no side window state is lying around:
>
> (dolist (buf (list "*Messages*" "*info*"))
> (when (get-buffer buf)
> (kill-buffer buf)))
>
> Press C-h i to open the *info* buffer. It appears in a side
> window on the right with `window-min-width' (default 10), but the
> content of the *info* buffer is much wider than its window.
>
> Press C-h i again for the *info* buffer to resize itself.
>
> I would expect the *info* window to fit to the buffer contents
> when it first appears. The patch I sent earlier fixes this.
Ah, ok. I somehow overlooked the fit-window-to-buffer part in your OP,
although it is in the bug Subject line -- though with my post-Jan 6
build from master, that's only problematic with
fit-window-to-buffer-horizontally set to t, as in your above recipe.
But with fit-window-to-buffer-horizontally set to t, I see that the
window displaying *info* is not quite fitted to the buffer (e.g. in the
initial dir node the line "In Emacs, you can click mouse button 2 on a
menu item or cross reference" wraps after the third "e" in "reference"
(column 70)), even if the frame is wide enough to display the entire
buffer. I see this both with and without your patch; but with
fit-window-to-buffer-horizontally set to nil, then there is no line
wrapping (as long as the frame is wide enough). This seems to be a bug
in the use of fit-window-to-buffer-horizontally.
Steve Berman
^ permalink raw reply [relevance 5%]
* bug#70213: Info-mode side window fit-window-to-buffer issue
2024-04-06 19:19 5% ` Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-04-07 1:59 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-07 9:30 5% ` Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-04-07 1:59 UTC (permalink / raw)
To: Stephen Berman; +Cc: 70213
Stephen Berman <stephen.berman@gmx.net> writes:
> Ah, ok. I somehow overlooked the fit-window-to-buffer part in your OP,
> although it is in the bug Subject line -- though with my post-Jan 6
> build from master, that's only problematic with
> fit-window-to-buffer-horizontally set to t, as in your above recipe.
> But with fit-window-to-buffer-horizontally set to t, I see that the
> window displaying *info* is not quite fitted to the buffer (e.g. in the
> initial dir node the line "In Emacs, you can click mouse button 2 on a
> menu item or cross reference" wraps after the third "e" in "reference"
> (column 70)), even if the frame is wide enough to display the entire
> buffer. I see this both with and without your patch; but with
> fit-window-to-buffer-horizontally set to nil, then there is no line
> wrapping (as long as the frame is wide enough). This seems to be a bug
> in the use of fit-window-to-buffer-horizontally.
Thank you for being gracious about my confusing report :)
On my machine, the following snippet:
(progn
(setq fit-window-to-buffer-horizontally t)
(setq display-buffer-alist
'(((derived-mode . Info-mode)
display-buffer-in-side-window
(side . right)
(window-width . fit-window-to-buffer))))
(info)
(window-width))
without the patch evaluates to 6
with the patch evaluates to 71
What happens on your machine?
Joseph
^ permalink raw reply [relevance 5%]
* bug#70213: Info-mode side window fit-window-to-buffer issue
2024-04-07 1:59 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-04-07 9:30 5% ` Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-07 17:47 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 200+ results
From: Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-04-07 9:30 UTC (permalink / raw)
To: Joseph Turner; +Cc: 70213
On Sat, 06 Apr 2024 18:59:45 -0700 Joseph Turner <joseph@breatheoutbreathe.in> wrote:
> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> Ah, ok. I somehow overlooked the fit-window-to-buffer part in your OP,
>> although it is in the bug Subject line -- though with my post-Jan 6
>> build from master, that's only problematic with
>> fit-window-to-buffer-horizontally set to t, as in your above recipe.
>> But with fit-window-to-buffer-horizontally set to t, I see that the
>> window displaying *info* is not quite fitted to the buffer (e.g. in the
>> initial dir node the line "In Emacs, you can click mouse button 2 on a
>> menu item or cross reference" wraps after the third "e" in "reference"
>> (column 70)), even if the frame is wide enough to display the entire
>> buffer. I see this both with and without your patch; but with
>> fit-window-to-buffer-horizontally set to nil, then there is no line
>> wrapping (as long as the frame is wide enough). This seems to be a bug
>> in the use of fit-window-to-buffer-horizontally.
>
> Thank you for being gracious about my confusing report :)
>
> On my machine, the following snippet:
>
> (progn
> (setq fit-window-to-buffer-horizontally t)
>
> (setq display-buffer-alist
> '(((derived-mode . Info-mode)
> display-buffer-in-side-window
> (side . right)
> (window-width . fit-window-to-buffer))))
>
> (info)
> (window-width))
>
> without the patch evaluates to 6
>
> with the patch evaluates to 71
>
> What happens on your machine?
without the patch: 6
with the patch: 70
For an unsplit window, (window-width) returns 80 (with emacs -Q); does
it also for you? I'm building on GNU/Linux with Gtk3.
Steve Berman
^ permalink raw reply [relevance 5%]
* bug#70093: *** SPAM *** bug#70093: Remove unnecessary `image-tests--map-equal'
2024-04-06 1:50 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-04-07 16:01 4% ` David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 0 replies; 200+ results
From: David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-04-07 16:01 UTC (permalink / raw)
To: Joseph Turner; +Cc: 70093, Eli Zaretskii
On 06/04/2024 03:50, Joseph Turner wrote:
>
> David Ponce <da_vid@orange.fr> writes:
>
>> [...]> But these 2 tests fails:
>>> 1.
>>> (setf (image-property image :scale) 1)
>>> (setf (image-property image :rotation) 90)
>>> (should (equal (image--compute-map image)
>>> rotated-map))
>>> ;; Return
>>> ((((circle (199 . 41) . 24) "a" (help-echo "A"))
>>> ((rect (79 . 5) 127 . 77) "b" (help-echo "B"))
>>> ((poly . [199 161 206 160 213 154 218 146 221 136 223 125 221
>>> 114 218 104 213 96 206 91 199 89 191 91 185 96 179 104 176 114 175
>>> 125 176 136 179 146 185 154 191 160]) "c" (help-echo "C")))
>>> ;; Instead of
>>> (((circle (126 . 41) . 24) "a" (help-echo "A"))
>>> ((rect (6 . 5) 54 . 77) "b" (help-echo "B"))
>>> ((poly . [126 161 133 160 140 154 145 146 148 136 150 125 148
>>> 114 145 104 140 96 133 91 126 89 118 91 112 96 106 104 103 114 102
>>> 125 103 136 106 146 112 154 118 160]) "c" (help-echo "C"))))
>>> ;; All the result X coords are different, but Y coords are expected.
>>> 2.
>>> (setf (image-property image :rotation) 0)
>>> (setf (image-property image :flip) t)
>>> (should (equal (image--compute-map image)
>>> flipped-map))
>>> ;; Return
>>> ((((circle (205 . 29) . 24) "a" (help-echo "A"))
>>> ((rect (169 . 101) 241 . 149) "b" (help-echo "B"))
>>> ((poly . [85 29 86 22 92 15 100 10 110 7 121 5 132 7 142 10
>>> 150 15 155 22 157 29 155 37 150 43 142 49 132 52 121 53 110 52 100
>>> 49 92 43 86 37]) "c" (help-echo "C")))
>>> ;; Instead of
>>> (((circle (125 . 29) . 24) "a" (help-echo "A"))
>>> ((rect (89 . 101) 161 . 149) "b" (help-echo "B"))
>>> ((poly . [5 29 6 22 12 15 20 10 30 7 41 5 52 7 62 10 70 15 75
>>> 22 77 29 75 37 70 43 62 49 52 52 41 53 30 52 20 49 12 43 6 37]) "c"
>>> (help-echo "C"))))
>>> ;; All the result X coords are different, but Y coords are expected.
>>> On my laptop:
>>> (image-size (image--image-without-parameters image) t) => (228 .
>>> 246)
>>> Hope it will help to understand the reason.
>> [...]
>>
>> Hello,
>>
>> I am still trying to understand why the 2 tests above fails with my configuration.
>> From the test `image--compute-map-and-original-map' I wrote the below equivalent
>> code to be evaled in the *scratch* buffer, in order to observe and analyze the
>> results interactively. The shapes are derived from the hot spots coordinates to
>> ensure a strict visual correspondance between a shape and its hot spot.
>>
>> On my configuration, all the computed map from the different image variations are
>> correct. You can test it by hovering the different produced colored shapes with
>> the mouse, and observe the mouse pointer and help-echo changes.
>>
>> My conclusion at this point is that the values of `flipped-map' and `rotated-map'
>> are not correct for my configuration, but I don't know why.
>>
>> If you can try the below code and observe the result on your configuration, maybe
>> could we get a better understanding of what is happening for the 2 tests that fail?
>>
>> Thanks!
>>
>> ______________________________________________________________________________
>>
>> (let* ((svg (svg-create "125pt" "116pt")) ;; 246px X 228px on my conf.
>> (original-map
>> '(((circle (41 . 29) . 24) "a" (help-echo "A"))
>> ((rect (5 . 101) 77 . 149) "b" (help-echo "B"))
>> ((poly . [ 161 29 160 22 154 15 146 10 136 7 125 5 114 7
>> 104 10 96 15 91 22 89 29 91 37 96 43 104 49
>> 114 52 125 53 136 52 146 49 154 43 160 37])
>> "c" (help-echo "C"))))
>> (scaled-map
>> '(((circle (82 . 58) . 48) "a" (help-echo "A"))
>> ((rect (10 . 202) 154 . 298) "b" (help-echo "B"))
>> ((poly . [ 322 58 320 44 308 30 292 20 272 14 250 10 228 14
>> 208 20 192 30 182 44 178 58 182 74 192 86 208 98
>> 228 104 250 106 272 104 292 98 308 86 320 74])
>> "c" (help-echo "C"))))
>> (flipped-map
>> '(((circle (125 . 29) . 24) "a" (help-echo "A"))
>> ((rect (89 . 101) 161 . 149) "b" (help-echo "B"))
>> ((poly . [ 5 29 6 22 12 15 20 10 30 7 41 5 52 7 62 10 70 15
>> 75 22 77 29 75 37 70 43 62 49 52 52 41 53 30 52
>> 20 49 12 43 6 37])
>> "c" (help-echo "C"))))
>> (rotated-map
>> '(((circle (126 . 41) . 24) "a" (help-echo "A"))
>> ((rect (6 . 5) 54 . 77) "b" (help-echo "B"))
>> ((poly . [ 126 161 133 160 140 154 145 146 148 136 150 125
>> 148 114 145 104 140 96 133 91 126 89 118 91
>> 112 96 106 104 103 114 102 125 103 136 106 146
>> 112 154 118 160])
>> "c" (help-echo "C"))))
>> (scaled-rotated-flipped-map
>> '(((circle (58 . 82) . 48) "a" (help-echo "A"))
>> ((rect (202 . 10) 298 . 154) "b" (help-echo "B"))
>> ((poly . [ 58 322 44 320 30 308 20 292 14 272 10 250 14 228
>> 20 208 30 192 44 182 58 178 74 182 86 192 98 208
>> 104 228 106 250 104 272 98 292 86 308 74 320])
>> "c" (help-echo "C"))))
>> )
>> (svg-rectangle svg 5 101 (- 77 5) (- 149 101)
>> :stroke-width 0 :fill "red")
>> (svg-circle svg 41 29 24
>> :stroke-width 0 :fill "green")
>> (svg-polyline svg '((161 . 29) (160 . 22) (154 . 15) (146 . 10)
>> (136 . 7) (125 . 5) (114 . 7) (104 . 10)
>> (96 . 15) (91 . 22) (89 . 29) (91 . 37)
>> (96 . 43) (104 . 49) (114 . 52) (125 . 53)
>> (136 . 52) (146 . 49) (154 . 43) (160 . 37))
>> :stroke-width 0 :fill "blue")
>> (let ((image (svg-image svg :map scaled-rotated-flipped-map
>> :scale 2 :rotation 90 :flip t)))
>> ;; Test that `image--compute-original-map' correctly generates
>> ;; original-map when creating an already transformed image.
>> (insert
>> (format
>> "\n:flip %s :rotation %s :scale %s (equal :original-map original-map)=>%s"
>> (image-property image :flip)
>> (image-property image :rotation)
>> (image-property image :scale)
>> (equal (image-property image :original-map)
>> original-map)))
>> (print image)
>> (insert-image image)
>> (setf (image-property image :flip) nil)
>> (setf (image-property image :rotation) 0)
>> (setf (image-property image :scale) 2)
>> (let ((map (image--compute-map image)))
>> (insert
>> (format
>> "\n:flip %s :rotation %s :scale %s (equal map scaled-map)=>%s"
>> (image-property image :flip)
>> (image-property image :rotation)
>> (image-property image :scale)
>> (equal map scaled-map)))
>> (setf (image-property image :map) map)
>> (print image)
>> ;; insert a new image in current buffer.
>> (insert-image (copy-tree image t))
>> )
>>
>> (setf (image-property image :scale) 1)
>> (setf (image-property image :rotation) 90)
>> (let ((map (image--compute-map image)))
>> (insert
>> (format
>> "\n:flip %s :rotation %s :scale %s (equal map rotated-map)=>%s"
>> (image-property image :flip)
>> (image-property image :rotation)
>> (image-property image :scale)
>> (equal map rotated-map)))
>> (setf (image-property image :map) map)
>> (print image)
>> ;; insert a new image in current buffer.
>> (insert-image (copy-tree image t))
>> )
>>
>> (setf (image-property image :rotation) 0)
>> (setf (image-property image :flip) t)
>> (let ((map (image--compute-map image)))
>> (insert
>> (format
>> "\n:flip %s :rotation %s :scale %s (equal map flipped-map)=>%s"
>> (image-property image :flip)
>> (image-property image :rotation)
>> (image-property image :scale)
>> (equal map flipped-map)))
>> (setf (image-property image :map) map)
>> (print image)
>> ;; insert a new image in current buffer.
>> (insert-image (copy-tree image t))
>> )
>>
>> (setf (image-property image :scale) 2)
>> (setf (image-property image :rotation) 90)
>> (let ((map (image--compute-map image)))
>> (insert
>> (format
>> "\n:flip %s :rotation %s :scale %s (equal map scaled-rotated-flipped-map)=>%s"
>> (image-property image :flip)
>> (image-property image :rotation)
>> (image-property image :scale)
>> (equal map scaled-rotated-flipped-map)))
>> (setf (image-property image :map) map)
>> (print image)
>> ;; insert a new image in current buffer.
>> (insert-image (copy-tree image t))
>> )
>> ))
>
> When I evaluate this block and hover over the various shapes, the
> help-echo pop-ups appear at the correct boundaries.
>
> Are you able to reproduce this issue with my patch with emacs -Q?
>
> Without the patch?
>
> Thank you!
>
> Joseph
Hello,
On my laptop, running emacs -Q, the tests give the same results with
and without the patch:
Test with patch without patch
-------------------------------------------------------------
image-create-image-with-map OK OK
image-transform-map OK OK
image--compute-map-and-original-map Fail (1) Fail (2)
(1) Test ‘image--compute-map’ and ‘image--compute-original-map’.
(ert-test-failed
((should (equal (image--compute-map image) rotated-map)) :form
(equal
(((circle ... . 24) "a" (help-echo "A"))
((rect ... 127 . 77) "b" (help-echo "B"))
((poly . [199 161 206 160 213 154 218 146 221 136 ...]) "c"
(help-echo "C")))
(((circle ... . 24) "a" (help-echo "A"))
((rect ... 54 . 77) "b" (help-echo "B"))
((poly . [126 161 133 160 140 154 145 146 148 136 ...]) "c"
(help-echo "C"))))
:value nil :explanation (list-elt 0 (list-elt 0 (cdr (car ...))))))
(2) Test ‘image--compute-map’ and ‘image--compute-original-map’.
(ert-test-failed
((should
(image-tests--map-equal (image--compute-map image) rotated-map))
:form
(image-tests--map-equal
(((circle ... . 24) "a" (help-echo "A"))
((rect ... 127 . 77) "b" (help-echo "B"))
((poly . [199 161 206 160 213 154 218 146 221 136 ...]) "c"
(help-echo "C")))
(((circle ... . 24) "a" (help-echo "A"))
((rect ... 54 . 77) "b" (help-echo "B"))
((poly . [126 161 133 160 140 154 145 146 148 136 ...]) "c"
(help-echo "C"))))
:value nil))
Thanks!
^ permalink raw reply [relevance 4%]
* bug#70213: Info-mode side window fit-window-to-buffer issue
2024-04-07 9:30 5% ` Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-04-07 17:47 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-07 19:29 5% ` Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-04-07 17:47 UTC (permalink / raw)
To: Stephen Berman; +Cc: 70213
Stephen Berman <stephen.berman@gmx.net> writes:
> On Sat, 06 Apr 2024 18:59:45 -0700 Joseph Turner <joseph@breatheoutbreathe.in> wrote:
>
>> On my machine, the following snippet:
>>
>> (progn
>> (setq fit-window-to-buffer-horizontally t)
>>
>> (setq display-buffer-alist
>> '(((derived-mode . Info-mode)
>> display-buffer-in-side-window
>> (side . right)
>> (window-width . fit-window-to-buffer))))
>>
>> (info)
>> (window-width))
>>
>> without the patch evaluates to 6
>>
>> with the patch evaluates to 71
>>
>> What happens on your machine?
>
> without the patch: 6
> with the patch: 70
This indicates that the patch fixes the bug on your machine also. Right?
> For an unsplit window, (window-width) returns 80 (with emacs -Q); does
> it also for you? I'm building on GNU/Linux with Gtk3.
Sorry, an unsplit window where? Please clarify the instructions :)
Thanks!
Joseph
^ permalink raw reply [relevance 5%]
* bug#70213: Info-mode side window fit-window-to-buffer issue
@ 2024-04-07 17:53 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-07 19:29 5% ` Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-08 11:04 0% ` Eli Zaretskii
0 siblings, 2 replies; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-04-07 17:53 UTC (permalink / raw)
To: martin rudalics; +Cc: Eli Zaretskii, Stephen Berman, 70213, Juri Linkov
martin rudalics <rudalics@gmx.at> writes:
>>> In emacs -Q on master after Jan 6 patch, eval this:
>>
>> Maybe Martin could help to solve this problem (Cc-ed).
>>
>>> (progn
>>> (setq fit-window-to-buffer-horizontally t)
>>>
>>> (setq display-buffer-alist
>>> '(((derived-mode . Info-mode)
>>> display-buffer-in-side-window
>>> (side . right)
>>> (window-width . fit-window-to-buffer))
>>> ((derived-mode . messages-buffer-mode)
>>> display-buffer-in-side-window
>>> (side . right)
>>> (window-width . fit-window-to-buffer)))))
>
> At the time we call 'fit-window-to-buffer' the buffer is empty so we
> show only 'window-min-width' columns. Don't we have 'body-function' for
> that?
Thanks for the review! We have the same understanding of the issue.
What do you mean by 'body-function'?
>>> I would expect the *info* window to fit to the buffer contents
>>> when it first appears. The patch I sent earlier fixes this.
>
> That patch is
>
> Display-buffer-after-ensuring-it-contains-text.patch
> IIUC. It already explains the problem in its name and does look good to
> me.
Thanks for the review! Stephen, Juri, Eli, WDYT?
Joseph
^ permalink raw reply [relevance 5%]
* bug#70213: Info-mode side window fit-window-to-buffer issue
2024-04-07 17:47 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-04-07 19:29 5% ` Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-07 20:07 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 200+ results
From: Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-04-07 19:29 UTC (permalink / raw)
To: Joseph Turner; +Cc: 70213
On Sun, 07 Apr 2024 10:47:58 -0700 Joseph Turner <joseph@breatheoutbreathe.in> wrote:
> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> On Sat, 06 Apr 2024 18:59:45 -0700 Joseph Turner
>> <joseph@breatheoutbreathe.in> wrote:
>>
>>> On my machine, the following snippet:
>>>
>>> (progn
>>> (setq fit-window-to-buffer-horizontally t)
>>>
>>> (setq display-buffer-alist
>>> '(((derived-mode . Info-mode)
>>> display-buffer-in-side-window
>>> (side . right)
>>> (window-width . fit-window-to-buffer))))
>>>
>>> (info)
>>> (window-width))
>>>
>>> without the patch evaluates to 6
>>>
>>> with the patch evaluates to 71
>>>
>>> What happens on your machine?
>>
>> without the patch: 6
>> with the patch: 70
>
> This indicates that the patch fixes the bug on your machine also. Right?
>
>> For an unsplit window, (window-width) returns 80 (with emacs -Q); does
>> it also for you? I'm building on GNU/Linux with Gtk3.
>
> Sorry, an unsplit window where? Please clarify the instructions :)
>
> Thanks!
Sorry for being unclear; what I meant is the return value of
(window-width) evaluated immediately after starting emacs -Q, so the
frame consists of a single window.
Steve Berman
^ permalink raw reply [relevance 5%]
* bug#70213: Info-mode side window fit-window-to-buffer issue
2024-04-07 17:53 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-04-07 19:29 5% ` Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-07 23:11 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-08 11:04 0% ` Eli Zaretskii
1 sibling, 1 reply; 200+ results
From: Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-04-07 19:29 UTC (permalink / raw)
To: Joseph Turner; +Cc: martin rudalics, Eli Zaretskii, 70213, Juri Linkov
On Sun, 07 Apr 2024 10:53:00 -0700 Joseph Turner <joseph@breatheoutbreathe.in> wrote:
> martin rudalics <rudalics@gmx.at> writes:
>
>>>> In emacs -Q on master after Jan 6 patch, eval this:
>>>
>>> Maybe Martin could help to solve this problem (Cc-ed).
>>>
>>>> (progn
>>>> (setq fit-window-to-buffer-horizontally t)
>>>>
>>>> (setq display-buffer-alist
>>>> '(((derived-mode . Info-mode)
>>>> display-buffer-in-side-window
>>>> (side . right)
>>>> (window-width . fit-window-to-buffer))
>>>> ((derived-mode . messages-buffer-mode)
>>>> display-buffer-in-side-window
>>>> (side . right)
>>>> (window-width . fit-window-to-buffer)))))
>>
>> At the time we call 'fit-window-to-buffer' the buffer is empty so we
>> show only 'window-min-width' columns. Don't we have 'body-function' for
>> that?
>
> Thanks for the review! We have the same understanding of the issue.
>
> What do you mean by 'body-function'?
>
>>>> I would expect the *info* window to fit to the buffer contents
>>>> when it first appears. The patch I sent earlier fixes this.
>>
>> That patch is
>>
>> Display-buffer-after-ensuring-it-contains-text.patch
>
>> IIUC. It already explains the problem in its name and does look good to
>> me.
>
> Thanks for the review! Stephen, Juri, Eli, WDYT?
I agree that your patch is an improvement when
fit-window-to-buffer-horizontally is set to t. However, as I noted
upthread, the resulting width of the right-side window is too small,
unlike when using the same setting of display-buffer-alist with
fit-window-to-buffer-horizontally set to nil, with which the setting of
display-buffer-alist works just as well without your patch. So even
with your patch, there remains a problem.
Steve Berman
^ permalink raw reply [relevance 5%]
* bug#70213: Info-mode side window fit-window-to-buffer issue
2024-04-07 19:29 5% ` Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-04-07 20:07 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-07 20:51 5% ` Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-04-07 20:07 UTC (permalink / raw)
To: Stephen Berman; +Cc: 70213
Stephen Berman <stephen.berman@gmx.net> writes:
> On Sun, 07 Apr 2024 10:47:58 -0700 Joseph Turner <joseph@breatheoutbreathe.in> wrote:
>
>> Stephen Berman <stephen.berman@gmx.net> writes:
>>
>>> On Sat, 06 Apr 2024 18:59:45 -0700 Joseph Turner
>>> <joseph@breatheoutbreathe.in> wrote:
>>>
>>>> On my machine, the following snippet:
>>>>
>>>> (progn
>>>> (setq fit-window-to-buffer-horizontally t)
>>>>
>>>> (setq display-buffer-alist
>>>> '(((derived-mode . Info-mode)
>>>> display-buffer-in-side-window
>>>> (side . right)
>>>> (window-width . fit-window-to-buffer))))
>>>>
>>>> (info)
>>>> (window-width))
>>>>
>>>> without the patch evaluates to 6
>>>>
>>>> with the patch evaluates to 71
>>>>
>>>> What happens on your machine?
>>>
>>> without the patch: 6
>>> with the patch: 70
>>
>> This indicates that the patch fixes the bug on your machine also. Right?
>>
>>> For an unsplit window, (window-width) returns 80 (with emacs -Q); does
>>> it also for you? I'm building on GNU/Linux with Gtk3.
>>
>> Sorry, an unsplit window where? Please clarify the instructions :)
>>
>> Thanks!
>
> Sorry for being unclear; what I meant is the return value of
> (window-width) evaluated immediately after starting emacs -Q, so the
> frame consists of a single window.
138 on my machine.
^ permalink raw reply [relevance 5%]
* bug#70213: Info-mode side window fit-window-to-buffer issue
2024-04-07 20:07 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-04-07 20:51 5% ` Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-07 22:13 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 200+ results
From: Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-04-07 20:51 UTC (permalink / raw)
To: Joseph Turner; +Cc: 70213
On Sun, 07 Apr 2024 13:07:06 -0700 Joseph Turner <joseph@breatheoutbreathe.in> wrote:
> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> On Sun, 07 Apr 2024 10:47:58 -0700 Joseph Turner
>> <joseph@breatheoutbreathe.in> wrote:
>>
>>> Stephen Berman <stephen.berman@gmx.net> writes:
>>>
>>>> On Sat, 06 Apr 2024 18:59:45 -0700 Joseph Turner
>>>> <joseph@breatheoutbreathe.in> wrote:
>>>>
>>>>> On my machine, the following snippet:
>>>>>
>>>>> (progn
>>>>> (setq fit-window-to-buffer-horizontally t)
>>>>>
>>>>> (setq display-buffer-alist
>>>>> '(((derived-mode . Info-mode)
>>>>> display-buffer-in-side-window
>>>>> (side . right)
>>>>> (window-width . fit-window-to-buffer))))
>>>>>
>>>>> (info)
>>>>> (window-width))
>>>>>
>>>>> without the patch evaluates to 6
>>>>>
>>>>> with the patch evaluates to 71
>>>>>
>>>>> What happens on your machine?
>>>>
>>>> without the patch: 6
>>>> with the patch: 70
>>>
>>> This indicates that the patch fixes the bug on your machine also. Right?
>>>
>>>> For an unsplit window, (window-width) returns 80 (with emacs -Q); does
>>>> it also for you? I'm building on GNU/Linux with Gtk3.
>>>
>>> Sorry, an unsplit window where? Please clarify the instructions :)
>>>
>>> Thanks!
>>
>> Sorry for being unclear; what I meant is the return value of
>> (window-width) evaluated immediately after starting emacs -Q, so the
>> frame consists of a single window.
>
> 138 on my machine.
I've never heard of that for -Q. I though 80, which is what I get, was
standard, at least under X, and that's what the Emacs user manual says
(info "(emacs) Window Size X"): "The default frame width is 80
characters and the default height is between 35 and 40 lines, depending
on the OS and the window manager." What graphical display system are
you using?
Steve Berman
^ permalink raw reply [relevance 5%]
* bug#70213: Info-mode side window fit-window-to-buffer issue
2024-04-07 20:51 5% ` Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-04-07 22:13 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-07 22:35 5% ` Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-04-07 22:13 UTC (permalink / raw)
To: Stephen Berman; +Cc: 70213
Stephen Berman <stephen.berman@gmx.net> writes:
> On Sun, 07 Apr 2024 13:07:06 -0700 Joseph Turner <joseph@breatheoutbreathe.in> wrote:
>
>> Stephen Berman <stephen.berman@gmx.net> writes:
>>
>>> On Sun, 07 Apr 2024 10:47:58 -0700 Joseph Turner
>>> <joseph@breatheoutbreathe.in> wrote:
>>>
>>>> Stephen Berman <stephen.berman@gmx.net> writes:
>>>>
>>>>> On Sat, 06 Apr 2024 18:59:45 -0700 Joseph Turner
>>>>> <joseph@breatheoutbreathe.in> wrote:
>>>>>
>>>>>> On my machine, the following snippet:
>>>>>>
>>>>>> (progn
>>>>>> (setq fit-window-to-buffer-horizontally t)
>>>>>>
>>>>>> (setq display-buffer-alist
>>>>>> '(((derived-mode . Info-mode)
>>>>>> display-buffer-in-side-window
>>>>>> (side . right)
>>>>>> (window-width . fit-window-to-buffer))))
>>>>>>
>>>>>> (info)
>>>>>> (window-width))
>>>>>>
>>>>>> without the patch evaluates to 6
>>>>>>
>>>>>> with the patch evaluates to 71
>>>>>>
>>>>>> What happens on your machine?
>>>>>
>>>>> without the patch: 6
>>>>> with the patch: 70
>>>>
>>>> This indicates that the patch fixes the bug on your machine also. Right?
>>>>
>>>>> For an unsplit window, (window-width) returns 80 (with emacs -Q); does
>>>>> it also for you? I'm building on GNU/Linux with Gtk3.
>>>>
>>>> Sorry, an unsplit window where? Please clarify the instructions :)
>>>>
>>>> Thanks!
>>>
>>> Sorry for being unclear; what I meant is the return value of
>>> (window-width) evaluated immediately after starting emacs -Q, so the
>>> frame consists of a single window.
>>
>> 138 on my machine.
>
> I've never heard of that for -Q. I though 80, which is what I get, was
> standard, at least under X, and that's what the Emacs user manual says
> (info "(emacs) Window Size X"): "The default frame width is 80
> characters and the default height is between 35 and 40 lines, depending
> on the OS and the window manager." What graphical display system are
> you using?
I am using EXWM, and I ran emacs -Q as a subprocess inside of the main
Emacs process. The emacs -Q instance ended up being full screen.
Joseph
^ permalink raw reply [relevance 5%]
* bug#70213: Info-mode side window fit-window-to-buffer issue
2024-04-07 22:13 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-04-07 22:35 5% ` Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-07 23:06 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 200+ results
From: Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-04-07 22:35 UTC (permalink / raw)
To: Joseph Turner; +Cc: 70213
On Sun, 07 Apr 2024 15:13:07 -0700 Joseph Turner <joseph@breatheoutbreathe.in> wrote:
> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> On Sun, 07 Apr 2024 13:07:06 -0700 Joseph Turner
>> <joseph@breatheoutbreathe.in> wrote:
>>
>>> Stephen Berman <stephen.berman@gmx.net> writes:
>>>
>>>> On Sun, 07 Apr 2024 10:47:58 -0700 Joseph Turner
>>>> <joseph@breatheoutbreathe.in> wrote:
>>>>
>>>>> Stephen Berman <stephen.berman@gmx.net> writes:
>>>>>
>>>>>> On Sat, 06 Apr 2024 18:59:45 -0700 Joseph Turner
>>>>>> <joseph@breatheoutbreathe.in> wrote:
>>>>>>
>>>>>>> On my machine, the following snippet:
>>>>>>>
>>>>>>> (progn
>>>>>>> (setq fit-window-to-buffer-horizontally t)
>>>>>>>
>>>>>>> (setq display-buffer-alist
>>>>>>> '(((derived-mode . Info-mode)
>>>>>>> display-buffer-in-side-window
>>>>>>> (side . right)
>>>>>>> (window-width . fit-window-to-buffer))))
>>>>>>>
>>>>>>> (info)
>>>>>>> (window-width))
>>>>>>>
>>>>>>> without the patch evaluates to 6
>>>>>>>
>>>>>>> with the patch evaluates to 71
>>>>>>>
>>>>>>> What happens on your machine?
>>>>>>
>>>>>> without the patch: 6
>>>>>> with the patch: 70
>>>>>
>>>>> This indicates that the patch fixes the bug on your machine also. Right?
>>>>>
>>>>>> For an unsplit window, (window-width) returns 80 (with emacs -Q); does
>>>>>> it also for you? I'm building on GNU/Linux with Gtk3.
>>>>>
>>>>> Sorry, an unsplit window where? Please clarify the instructions :)
>>>>>
>>>>> Thanks!
>>>>
>>>> Sorry for being unclear; what I meant is the return value of
>>>> (window-width) evaluated immediately after starting emacs -Q, so the
>>>> frame consists of a single window.
>>>
>>> 138 on my machine.
>>
>> I've never heard of that for -Q. I though 80, which is what I get, was
>> standard, at least under X, and that's what the Emacs user manual says
>> (info "(emacs) Window Size X"): "The default frame width is 80
>> characters and the default height is between 35 and 40 lines, depending
>> on the OS and the window manager." What graphical display system are
>> you using?
>
> I am using EXWM, and I ran emacs -Q as a subprocess inside of the main
> Emacs process. The emacs -Q instance ended up being full screen.
Ah, ok, so that overrides the Emacs default frame parameters for X. So
I guess that's why you get different results with
fit-window-to-buffer-horizontally set to t than I do.
Steve Berman
^ permalink raw reply [relevance 5%]
* bug#70213: Info-mode side window fit-window-to-buffer issue
2024-04-07 22:35 5% ` Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-04-07 23:06 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 0 replies; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-04-07 23:06 UTC (permalink / raw)
To: Stephen Berman; +Cc: 70213
Stephen Berman <stephen.berman@gmx.net> writes:
> On Sun, 07 Apr 2024 15:13:07 -0700 Joseph Turner <joseph@breatheoutbreathe.in> wrote:
>
>> Stephen Berman <stephen.berman@gmx.net> writes:
>>
>>> On Sun, 07 Apr 2024 13:07:06 -0700 Joseph Turner
>>> <joseph@breatheoutbreathe.in> wrote:
>>>
>>>> Stephen Berman <stephen.berman@gmx.net> writes:
>>>>
>>>>> On Sun, 07 Apr 2024 10:47:58 -0700 Joseph Turner
>>>>> <joseph@breatheoutbreathe.in> wrote:
>>>>>
>>>>>> Stephen Berman <stephen.berman@gmx.net> writes:
>>>>>>
>>>>>>> On Sat, 06 Apr 2024 18:59:45 -0700 Joseph Turner
>>>>>>> <joseph@breatheoutbreathe.in> wrote:
>>>>>>>
>>>>>>>> On my machine, the following snippet:
>>>>>>>>
>>>>>>>> (progn
>>>>>>>> (setq fit-window-to-buffer-horizontally t)
>>>>>>>>
>>>>>>>> (setq display-buffer-alist
>>>>>>>> '(((derived-mode . Info-mode)
>>>>>>>> display-buffer-in-side-window
>>>>>>>> (side . right)
>>>>>>>> (window-width . fit-window-to-buffer))))
>>>>>>>>
>>>>>>>> (info)
>>>>>>>> (window-width))
>>>>>>>>
>>>>>>>> without the patch evaluates to 6
>>>>>>>>
>>>>>>>> with the patch evaluates to 71
>>>>>>>>
>>>>>>>> What happens on your machine?
>>>>>>>
>>>>>>> without the patch: 6
>>>>>>> with the patch: 70
>>>>>>
>>>>>> This indicates that the patch fixes the bug on your machine also. Right?
>>>>>>
>>>>>>> For an unsplit window, (window-width) returns 80 (with emacs -Q); does
>>>>>>> it also for you? I'm building on GNU/Linux with Gtk3.
>>>>>>
>>>>>> Sorry, an unsplit window where? Please clarify the instructions :)
>>>>>>
>>>>>> Thanks!
>>>>>
>>>>> Sorry for being unclear; what I meant is the return value of
>>>>> (window-width) evaluated immediately after starting emacs -Q, so the
>>>>> frame consists of a single window.
>>>>
>>>> 138 on my machine.
>>>
>>> I've never heard of that for -Q. I though 80, which is what I get, was
>>> standard, at least under X, and that's what the Emacs user manual says
>>> (info "(emacs) Window Size X"): "The default frame width is 80
>>> characters and the default height is between 35 and 40 lines, depending
>>> on the OS and the window manager." What graphical display system are
>>> you using?
>>
>> I am using EXWM, and I ran emacs -Q as a subprocess inside of the main
>> Emacs process. The emacs -Q instance ended up being full screen.
>
> Ah, ok, so that overrides the Emacs default frame parameters for X. So
> I guess that's why you get different results with
> fit-window-to-buffer-horizontally set to t than I do.
👍
^ permalink raw reply [relevance 5%]
* bug#70213: Info-mode side window fit-window-to-buffer issue
2024-04-07 19:29 5% ` Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-04-07 23:11 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-08 7:56 5% ` Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-04-07 23:11 UTC (permalink / raw)
To: Stephen Berman; +Cc: martin rudalics, Eli Zaretskii, 70213, Juri Linkov
Stephen Berman <stephen.berman@gmx.net> writes:
> On Sun, 07 Apr 2024 10:53:00 -0700 Joseph Turner <joseph@breatheoutbreathe.in> wrote:
>
>> martin rudalics <rudalics@gmx.at> writes:
>>
>>>>> In emacs -Q on master after Jan 6 patch, eval this:
>>>>
>>>> Maybe Martin could help to solve this problem (Cc-ed).
>>>>
>>>>> (progn
>>>>> (setq fit-window-to-buffer-horizontally t)
>>>>>
>>>>> (setq display-buffer-alist
>>>>> '(((derived-mode . Info-mode)
>>>>> display-buffer-in-side-window
>>>>> (side . right)
>>>>> (window-width . fit-window-to-buffer))
>>>>> ((derived-mode . messages-buffer-mode)
>>>>> display-buffer-in-side-window
>>>>> (side . right)
>>>>> (window-width . fit-window-to-buffer)))))
>>>
>>> At the time we call 'fit-window-to-buffer' the buffer is empty so we
>>> show only 'window-min-width' columns. Don't we have 'body-function' for
>>> that?
>>
>> Thanks for the review! We have the same understanding of the issue.
>>
>> What do you mean by 'body-function'?
>>
>>>>> I would expect the *info* window to fit to the buffer contents
>>>>> when it first appears. The patch I sent earlier fixes this.
>>>
>>> That patch is
>>>
>>> Display-buffer-after-ensuring-it-contains-text.patch
>>
>>> IIUC. It already explains the problem in its name and does look good to
>>> me.
>>
>> Thanks for the review! Stephen, Juri, Eli, WDYT?
>
> I agree that your patch is an improvement when
> fit-window-to-buffer-horizontally is set to t. However, as I noted
> upthread, the resulting width of the right-side window is too small,
> unlike when using the same setting of display-buffer-alist with
> fit-window-to-buffer-horizontally set to nil, with which the setting of
> display-buffer-alist works just as well without your patch. So even
> with your patch, there remains a problem.
It turns out that it's necessary to set window-resize-pixelwise also, as
noted in (info "(elisp)Frame Layouts with Side Windows") .
In emacs -Q with the patch, the following snippet should the width of
the largest line, which on my machine is 74, the width of this line:
In Emacs, you can click mouse button 2 on a menu item or cross reference
(progn
(setq fit-window-to-buffer-horizontally t)
(setq window-resize-pixelwise t)
(setq display-buffer-alist
'(((derived-mode . Info-mode)
display-buffer-in-side-window
(side . right)
(window-width . fit-window-to-buffer))))
(info)
(window-width))
Joseph
^ permalink raw reply [relevance 5%]
* bug#70213: Info-mode side window fit-window-to-buffer issue
2024-04-07 23:11 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-04-08 7:56 5% ` Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 0 replies; 200+ results
From: Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-04-08 7:56 UTC (permalink / raw)
To: Joseph Turner; +Cc: martin rudalics, Eli Zaretskii, 70213, Juri Linkov
On Sun, 07 Apr 2024 16:11:07 -0700 Joseph Turner <joseph@breatheoutbreathe.in> wrote:
> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> On Sun, 07 Apr 2024 10:53:00 -0700 Joseph Turner
>> <joseph@breatheoutbreathe.in> wrote:
>>
>>> martin rudalics <rudalics@gmx.at> writes:
>>>
>>>>>> In emacs -Q on master after Jan 6 patch, eval this:
>>>>>
>>>>> Maybe Martin could help to solve this problem (Cc-ed).
>>>>>
>>>>>> (progn
>>>>>> (setq fit-window-to-buffer-horizontally t)
>>>>>>
>>>>>> (setq display-buffer-alist
>>>>>> '(((derived-mode . Info-mode)
>>>>>> display-buffer-in-side-window
>>>>>> (side . right)
>>>>>> (window-width . fit-window-to-buffer))
>>>>>> ((derived-mode . messages-buffer-mode)
>>>>>> display-buffer-in-side-window
>>>>>> (side . right)
>>>>>> (window-width . fit-window-to-buffer)))))
>>>>
>>>> At the time we call 'fit-window-to-buffer' the buffer is empty so we
>>>> show only 'window-min-width' columns. Don't we have 'body-function' for
>>>> that?
>>>
>>> Thanks for the review! We have the same understanding of the issue.
>>>
>>> What do you mean by 'body-function'?
>>>
>>>>>> I would expect the *info* window to fit to the buffer contents
>>>>>> when it first appears. The patch I sent earlier fixes this.
>>>>
>>>> That patch is
>>>>
>>>> Display-buffer-after-ensuring-it-contains-text.patch
>>>
>>>> IIUC. It already explains the problem in its name and does look good to
>>>> me.
>>>
>>> Thanks for the review! Stephen, Juri, Eli, WDYT?
>>
>> I agree that your patch is an improvement when
>> fit-window-to-buffer-horizontally is set to t. However, as I noted
>> upthread, the resulting width of the right-side window is too small,
>> unlike when using the same setting of display-buffer-alist with
>> fit-window-to-buffer-horizontally set to nil, with which the setting of
>> display-buffer-alist works just as well without your patch. So even
>> with your patch, there remains a problem.
>
> It turns out that it's necessary to set window-resize-pixelwise also, as
> noted in (info "(elisp)Frame Layouts with Side Windows") .
>
> In emacs -Q with the patch, the following snippet should the width of
> the largest line, which on my machine is 74, the width of this line:
Yep, now I get that too (after widening the frame sufficiently, since
the standard default of 80 columns (which I have) is too narrow to fit
both windows with widths 6 and 74 plus the added scroll bar and
fringes). So window-resize-pixelwise was the missing link, there's no
problem after all and your patch is good to go, as far as I'm concerned.
Thanks.
Steve Berman
> In Emacs, you can click mouse button 2 on a menu item or cross reference
>
> (progn
> (setq fit-window-to-buffer-horizontally t)
> (setq window-resize-pixelwise t)
>
> (setq display-buffer-alist
> '(((derived-mode . Info-mode)
> display-buffer-in-side-window
> (side . right)
> (window-width . fit-window-to-buffer))))
>
> (info)
> (window-width))
^ permalink raw reply [relevance 5%]
* bug#70213: Info-mode side window fit-window-to-buffer issue
2024-04-07 17:53 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-07 19:29 5% ` Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-04-08 11:04 0% ` Eli Zaretskii
[not found] ` <87ttkaij8v.fsf@breatheoutbreathe.in>
1 sibling, 1 reply; 200+ results
From: Eli Zaretskii @ 2024-04-08 11:04 UTC (permalink / raw)
To: Joseph Turner; +Cc: rudalics, stephen.berman, 70213, juri
> From: Joseph Turner <joseph@breatheoutbreathe.in>
> Cc: Juri Linkov <juri@linkov.net>, Stephen Berman <stephen.berman@gmx.net>,
> 70213@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>
> Date: Sun, 07 Apr 2024 10:53:00 -0700
>
> Stephen, Juri, Eli, WDYT?
WDIT about what?
^ permalink raw reply [relevance 0%]
* bug#70213: Info-mode side window fit-window-to-buffer issue
[not found] ` <87ttkaij8v.fsf@breatheoutbreathe.in>
@ 2024-04-09 18:24 0% ` Eli Zaretskii
2024-04-10 5:12 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 2 replies; 200+ results
From: Eli Zaretskii @ 2024-04-09 18:24 UTC (permalink / raw)
To: Joseph Turner; +Cc: martin rudalics, 70213
> From: Joseph Turner <joseph@breatheoutbreathe.in>
> Date: Tue, 09 Apr 2024 09:38:40 -0700
>
> >> From: Joseph Turner <joseph@breatheoutbreathe.in>
> >> Cc: Juri Linkov <juri@linkov.net>, Stephen Berman <stephen.berman@gmx.net>,
> >> 70213@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>
> >> Date: Sun, 07 Apr 2024 10:53:00 -0700
> >>
> >> Stephen, Juri, Eli, WDYT?
> >
> > WDIT about what?
>
> IIUC, Juri, Martin, and Stephen all support installing this patch.
I'd like to hear from Martin that he agrees with this patch. AFAIU,
the agreement about what is the problem and how best to fix it was
just one message ago, quite a few messages after your question.
(And why personal email just to me? I assume it was a mistake.)
^ permalink raw reply [relevance 0%]
* bug#70213: Info-mode side window fit-window-to-buffer issue
2024-04-09 18:24 0% ` Eli Zaretskii
@ 2024-04-10 5:12 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 0 replies; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-04-10 5:12 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: martin rudalics, 70213
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Joseph Turner <joseph@breatheoutbreathe.in>
>> Date: Tue, 09 Apr 2024 09:38:40 -0700
>>
>> >> From: Joseph Turner <joseph@breatheoutbreathe.in>
>> >> Cc: Juri Linkov <juri@linkov.net>, Stephen Berman <stephen.berman@gmx.net>,
>> >> 70213@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>
>> >> Date: Sun, 07 Apr 2024 10:53:00 -0700
>> >>
>> >> Stephen, Juri, Eli, WDYT?
>> >
>> > WDIT about what?
>>
>> IIUC, Juri, Martin, and Stephen all support installing this patch.
>
> I'd like to hear from Martin that he agrees with this patch. AFAIU,
> the agreement about what is the problem and how best to fix it was
> just one message ago, quite a few messages after your question.
>
> (And why personal email just to me? I assume it was a mistake.)
Yes, that was a mistake. The mu4e keybinding for wide-reply changed in
the last update, and I hadn't adjusted yet.
Thanks!
Joseph
^ permalink raw reply [relevance 5%]
* bug#70213: Info-mode side window fit-window-to-buffer issue
@ 2024-04-12 7:12 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 0 replies; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-04-12 7:12 UTC (permalink / raw)
To: Juri Linkov; +Cc: martin rudalics, Eli Zaretskii, Stephen Berman, 70213
Juri Linkov <juri@linkov.net> writes:
> close 70213 30.0.50
> thanks
[...]
> Ok, so now pushed Joseph's patch, and closed.
Thank you all for your careful review :)
Joseph
^ permalink raw reply [relevance 5%]
* bug#63480: 30.0.50; [BUG] unimplemented logic regarding read-symbol-shorthands
2023-11-29 8:12 5% ` João Távora
@ 2024-04-18 20:01 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-18 20:24 5% ` João Távora
0 siblings, 1 reply; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-04-18 20:01 UTC (permalink / raw)
To: João Távora
Cc: 63480, Ruijie Yu, Jonas Bernoulli, Stefan Kangas, Adam Porter
João Távora <joaotavora@gmail.com> writes:
> On Wed, Nov 29, 2023, 07:45 Joseph Turner <joseph@breatheoutbreathe.in> wrote:
>
> :
>
> ;;;###autoload
> (with-eval-after-load 'optional-dependency
> (cl-pushnew 'sns-var optional-dependency-var))
>
> Instead, you must expand the shorthand symbol into its full form:
>
> ;;;###autoload
> (with-eval-after-load 'optional-dependency
> (cl-pushnew 'some-nice-string-utils-var optional-dependency-var))
>
> For a real-world example, see
>
> https://git.sr.ht/~ushin/hyperdrive.el/commit/48afc51ac22713f2c54f75a7ea3b5c6b0e12b53d
>
> Thanks for the extra case. I think this merits a fix in the autoload extractor, watch should become autoload aware. I'll try to look at it.
I believe this bug was fixed in c52d17d91ad
Can we close this bug?
Thanks,
Joseph
^ permalink raw reply [relevance 5%]
* bug#63480: 30.0.50; [BUG] unimplemented logic regarding read-symbol-shorthands
2024-04-18 20:01 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-04-18 20:24 5% ` João Távora
2024-04-18 20:52 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 200+ results
From: João Távora @ 2024-04-18 20:24 UTC (permalink / raw)
To: Joseph Turner
Cc: 63480, Ruijie Yu, Jonas Bernoulli, Stefan Kangas, Adam Porter
On Thu, Apr 18, 2024 at 9:01 PM Joseph Turner
<joseph@breatheoutbreathe.in> wrote:
>
> João Távora <joaotavora@gmail.com> writes:
>
> > Thanks for the extra case. I think this merits a fix in the autoload extractor, watch should become autoload aware. I'll try to look at it.
>
> I believe this bug was fixed in c52d17d91ad
>
> Can we close this bug?
Fine by me, you're the one originally requesting all these bug fixes,
so if you confirm that everything's working correctly with your
extensive use of shorthands, we should close.
But I've been away from Emacs development for the last months (and
hope to be disconnecting myself more progressively) so I might not be
the best person to ask.
João
^ permalink raw reply [relevance 5%]
* bug#63480: 30.0.50; [BUG] unimplemented logic regarding read-symbol-shorthands
2024-04-18 20:24 5% ` João Távora
@ 2024-04-18 20:52 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 0 replies; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-04-18 20:52 UTC (permalink / raw)
To: João Távora
Cc: 63480-done, Ruijie Yu, Jonas Bernoulli, Stefan Kangas,
Adam Porter
João Távora <joaotavora@gmail.com> writes:
> On Thu, Apr 18, 2024 at 9:01 PM Joseph Turner
> <joseph@breatheoutbreathe.in> wrote:
>>
>> João Távora <joaotavora@gmail.com> writes:
>>
>> > Thanks for the extra case. I think this merits a fix in the
>> > autoload extractor, watch should become autoload aware. I'll try
>> > to look at it.
>>
>> I believe this bug was fixed in c52d17d91ad
>>
>> Can we close this bug?
>
> Fine by me, you're the one originally requesting all these bug fixes,
> so if you confirm that everything's working correctly with your
> extensive use of shorthands, we should close.
>
> But I've been away from Emacs development for the last months (and
> hope to be disconnecting myself more progressively) so I might not be
> the best person to ask.
Thank you, João!
Warmly,
Joseph
^ permalink raw reply [relevance 5%]
* bug#69528: 30.0.50; [BUG] transient.el is not a member of package--builtin-versions
2024-03-05 6:17 11% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-05-09 6:53 11% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-05-25 7:39 0% ` Eli Zaretskii
2024-05-25 8:04 7% ` Philip Kaludercic
1 sibling, 1 reply; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-05-09 6:53 UTC (permalink / raw)
To: Philip Kaludercic; +Cc: 69528, iarchivedmywholelife
Joseph Turner <joseph@breatheoutbreathe.in> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>> So in general, this patch might be appropriate?
>>
>> diff --git a/lisp/emacs-lisp/loaddefs-gen.el b/lisp/emacs-lisp/loaddefs-gen.el
>> index 581053f6304..42f386933dc 100644
>> --- a/lisp/emacs-lisp/loaddefs-gen.el
>> +++ b/lisp/emacs-lisp/loaddefs-gen.el
>> @@ -433,7 +433,8 @@ loaddefs-generate--parse-file
>> ;; loaddefs for packages so that `syntax-ppss' later gives
>> ;; correct results.
>> (emacs-lisp-mode)
>> - (let ((version (lm-header "version"))
>> + (let ((version (or (lm-header "package-version")
>> + (lm-header "version")))
>> package)
>> (when (and version
>> (setq version (ignore-errors (version-to-list version)))
>>
>>
>
> What about making `lm-version' handle the "package-version" header then
> using `lm-version' in loaddefs-generate--parse-file? See patches.
>
> Joseph
>
> [2. text/x-diff; 0002-Use-lm-version-instead-of-lm-header-version.patch]...
>
> [3. text/x-diff; 0001-Check-Package-Version-header-in-lm-version-also.patch]...
Ping!
^ permalink raw reply [relevance 11%]
* bug#67390: 28; shorthands-font-lock-shorthands assumes shorthand uses same separator
2024-02-03 23:48 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-05-21 22:05 10% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 0 replies; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-05-21 22:05 UTC (permalink / raw)
To: 67390; +Cc: adam, eliz, jonas, joaotavora
Joseph Turner via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org> writes:
> João Távora <joaotavora@gmail.com> writes:
>
>> On Sat, Feb 3, 2024 at 8:01 PM Joseph Turner
>> <joseph@breatheoutbreathe.in> wrote:
>>
>>> I'm still reproducing the check-declare bug on my machine. It appears
>>> that binding `enable-local-variables' to nil around the call to
>>> `hack-local-variables' means that `read-symbol-shorthands' is not set.
>>> Can we bind `enable-local-variables' to `:safe' instead?
>>
>> It could be some bootstrapping issue, since the safe spec of that particular
>> variable itself needs to be autoloaded. I vaguely remember something like
>> this and I _think_ it was fixed.
>>
>> Anyway, I can't reproduce this with this test:
>>
>> src/emacs -Q --batch --eval '(check-declare-file
>> "~/tmp/hyperdrive.el/hyperdrive-lib.el")'
>>
>> where ~/tmp/hyperdrive.el is a checkout of your hyperdrive library.
>>
>> This doesn't output anything, which I think is the expected result.
>>
>> How are you testing?
>
> Hmm... I just compiled from master with
>
> ./configure --with-x-toolkit=no --with-xpm=ifavailable
> --with-jpeg=ifavailable --with-gif=ifavailable --with-tiff=ifavailable
> --with-gnutls=ifavailable && make
>
> then I ran
>
> src/emacs -Q --batch --eval '(check-declare-file "~/.local/src/hyperdrive.el/hyperdrive-lib.el")'
>
> which produced
>
> uncompressing textsec-check.el.gz...
> uncompressing textsec-check.el.gz...done
> ../hyperdrive.el/hyperdrive-lib.el:44:Warning (check-declare): said
> ‘h/mode’ was defined in ../hyperdrive.el/hyperdrive.el: function not
> found
> ../hyperdrive.el/hyperdrive-lib.el:508:Warning (check-declare): said
> ‘h/history’ was defined in ../hyperdrive.el/hyperdrive-history.el:
> function not found
> ../hyperdrive.el/hyperdrive-lib.el:1332:Warning (check-declare): said
> ‘h/dir-handler’ was defined in ../hyperdrive.el/hyperdrive-dir.el:
> function not found
>
> Would someone else kindly attempt to reproduce the issue?
I just rebuilt from master ce8e292bca84f29cea540e3e23e88ec7a5d1674e
with the following settings
./configure --with-x-toolkit=no --with-xpm=ifavailable
--with-jpeg=ifavailable --with-gif=ifavailable --with-tiff=ifavailable
--with-gnutls=ifavailable && make
src/emacs -Q --batch --eval '(check-declare-file "~/.local/src/hyperdrive.el/hyperdrive-lib.el")'
returns the following:
uncompressing textsec-check.el.gz...
uncompressing textsec-check.el.gz...done
../hyperdrive.el/hyperdrive-lib.el:535:Warning (check-declare): said ‘h/history’
was defined in ../hyperdrive.el/hyperdrive-history.el: function not found
../hyperdrive.el/hyperdrive-lib.el:44:Warning (check-declare): said ‘h/mode’ was
defined in ../hyperdrive.el/hyperdrive.el: function not found
../hyperdrive.el/hyperdrive-lib.el:1333:Warning (check-declare): said ‘h/blob-mo
de’ was defined in ../hyperdrive.el/hyperdrive.el: function not found
../hyperdrive.el/hyperdrive-lib.el:1383:Warning (check-declare): said ‘h/dir-han
dler’ was defined in ../hyperdrive.el/hyperdrive-dir.el: function not found
Can anyone else reproduce this error?
Thank you!
Joseph
^ permalink raw reply [relevance 10%]
* bug#69528: 30.0.50; [BUG] transient.el is not a member of package--builtin-versions
2024-05-09 6:53 11% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-05-25 7:39 0% ` Eli Zaretskii
0 siblings, 0 replies; 200+ results
From: Eli Zaretskii @ 2024-05-25 7:39 UTC (permalink / raw)
To: Joseph Turner; +Cc: philipk, 69528, iarchivedmywholelife
Ping! Ping! Philip, can you please chime in?
> Cc: 69528@debbugs.gnu.org, iarchivedmywholelife@gmail.com
> Date: Wed, 08 May 2024 23:53:38 -0700
> From: Joseph Turner via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>
> Joseph Turner <joseph@breatheoutbreathe.in> writes:
>
> > Philip Kaludercic <philipk@posteo.net> writes:
> >> So in general, this patch might be appropriate?
> >>
> >> diff --git a/lisp/emacs-lisp/loaddefs-gen.el b/lisp/emacs-lisp/loaddefs-gen.el
> >> index 581053f6304..42f386933dc 100644
> >> --- a/lisp/emacs-lisp/loaddefs-gen.el
> >> +++ b/lisp/emacs-lisp/loaddefs-gen.el
> >> @@ -433,7 +433,8 @@ loaddefs-generate--parse-file
> >> ;; loaddefs for packages so that `syntax-ppss' later gives
> >> ;; correct results.
> >> (emacs-lisp-mode)
> >> - (let ((version (lm-header "version"))
> >> + (let ((version (or (lm-header "package-version")
> >> + (lm-header "version")))
> >> package)
> >> (when (and version
> >> (setq version (ignore-errors (version-to-list version)))
> >>
> >>
> >
> > What about making `lm-version' handle the "package-version" header then
> > using `lm-version' in loaddefs-generate--parse-file? See patches.
> >
> > Joseph
^ permalink raw reply [relevance 0%]
* bug#69528: 30.0.50; [BUG] transient.el is not a member of package--builtin-versions
2024-03-05 6:17 11% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-05-09 6:53 11% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-05-25 8:04 7% ` Philip Kaludercic
2024-05-25 8:08 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-05-25 10:49 0% ` Eli Zaretskii
1 sibling, 2 replies; 200+ results
From: Philip Kaludercic @ 2024-05-25 8:04 UTC (permalink / raw)
To: Joseph Turner; +Cc: 69528, iarchivedmywholelife
Joseph Turner <joseph@breatheoutbreathe.in> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>> So in general, this patch might be appropriate?
>>
>> diff --git a/lisp/emacs-lisp/loaddefs-gen.el b/lisp/emacs-lisp/loaddefs-gen.el
>> index 581053f6304..42f386933dc 100644
>> --- a/lisp/emacs-lisp/loaddefs-gen.el
>> +++ b/lisp/emacs-lisp/loaddefs-gen.el
>> @@ -433,7 +433,8 @@ loaddefs-generate--parse-file
>> ;; loaddefs for packages so that `syntax-ppss' later gives
>> ;; correct results.
>> (emacs-lisp-mode)
>> - (let ((version (lm-header "version"))
>> + (let ((version (or (lm-header "package-version")
>> + (lm-header "version")))
>> package)
>> (when (and version
>> (setq version (ignore-errors (version-to-list version)))
>>
>>
>
> What about making `lm-version' handle the "package-version" header then
> using `lm-version' in loaddefs-generate--parse-file? See patches.
My main concern was if we want to have Package-Version always override
Version, but if my patch modified loaddefs-gen, then I don't think there
is much of a difference if we change lisp-mnt instead (in terms of the
generality of the change).
So I am fine with the change, and think we can merge it. Eli: Is master
still fine for these kinds of changes?
> Joseph
>
>>From e83ee369ae90e5e15b3adca9eab1ded4db864427 Mon Sep 17 00:00:00 2001
> From: Joseph Turner <joseph@breatheoutbreathe.in>
> Date: Mon, 4 Mar 2024 22:15:50 -0800
> Subject: [PATCH 2/2] Use lm-version instead of lm-header "version"
>
> bug#69528
>
> * lisp/emacs-lisp/loaddefs-gen.el (loaddefs-generate--parse-file)
> ---
> lisp/emacs-lisp/loaddefs-gen.el | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lisp/emacs-lisp/loaddefs-gen.el b/lisp/emacs-lisp/loaddefs-gen.el
> index 581053f6304..6b24f7dc8c7 100644
> --- a/lisp/emacs-lisp/loaddefs-gen.el
> +++ b/lisp/emacs-lisp/loaddefs-gen.el
> @@ -433,7 +433,7 @@ loaddefs-generate--parse-file
> ;; loaddefs for packages so that `syntax-ppss' later gives
> ;; correct results.
> (emacs-lisp-mode)
> - (let ((version (lm-header "version"))
> + (let ((version (lm-version))
> package)
> (when (and version
> (setq version (ignore-errors (version-to-list version)))
> --
> 2.41.0
>
>
>>From 20db8c9afcb03d8a5acb750fa738c5066e204401 Mon Sep 17 00:00:00 2001
> From: Joseph Turner <joseph@breatheoutbreathe.in>
> Date: Mon, 4 Mar 2024 22:14:26 -0800
> Subject: [PATCH 1/2] Check Package-Version: header in lm-version also
>
> * lisp/emacs-lisp/lisp-mnt.el (lm-version)
> ---
> lisp/emacs-lisp/lisp-mnt.el | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/lisp/emacs-lisp/lisp-mnt.el b/lisp/emacs-lisp/lisp-mnt.el
> index f111a77663c..12b23853801 100644
> --- a/lisp/emacs-lisp/lisp-mnt.el
> +++ b/lisp/emacs-lisp/lisp-mnt.el
> @@ -416,6 +416,7 @@ lm-version
> This can be found in an RCS or SCCS header."
> (lm-with-file file
> (or (lm-header "version")
> + (lm-header "package-version")
> (let ((header-max (lm-code-start)))
> (goto-char (point-min))
> (cond
Joseph Turner <joseph@breatheoutbreathe.in> writes:
> Joseph Turner <joseph@breatheoutbreathe.in> writes:
>
>> Philip Kaludercic <philipk@posteo.net> writes:
>>> So in general, this patch might be appropriate?
>>>
>>> diff --git a/lisp/emacs-lisp/loaddefs-gen.el b/lisp/emacs-lisp/loaddefs-gen.el
>>> index 581053f6304..42f386933dc 100644
>>> --- a/lisp/emacs-lisp/loaddefs-gen.el
>>> +++ b/lisp/emacs-lisp/loaddefs-gen.el
>>> @@ -433,7 +433,8 @@ loaddefs-generate--parse-file
>>> ;; loaddefs for packages so that `syntax-ppss' later gives
>>> ;; correct results.
>>> (emacs-lisp-mode)
>>> - (let ((version (lm-header "version"))
>>> + (let ((version (or (lm-header "package-version")
>>> + (lm-header "version")))
>>> package)
>>> (when (and version
>>> (setq version (ignore-errors (version-to-list version)))
>>>
>>>
>>
>> What about making `lm-version' handle the "package-version" header then
>> using `lm-version' in loaddefs-generate--parse-file? See patches.
>>
>> Joseph
>>
>> [2. text/x-diff; 0002-Use-lm-version-instead-of-lm-header-version.patch]...
>>
>> [3. text/x-diff; 0001-Check-Package-Version-header-in-lm-version-also.patch]...
>
> Ping!
>
>
>
>
Eli Zaretskii <eliz@gnu.org> writes:
> Ping! Ping! Philip, can you please chime in?
>
>> Cc: 69528@debbugs.gnu.org, iarchivedmywholelife@gmail.com
>> Date: Wed, 08 May 2024 23:53:38 -0700
>> From: Joseph Turner via "Bug reports for GNU Emacs,
>> the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>>
>> Joseph Turner <joseph@breatheoutbreathe.in> writes:
>>
>> > Philip Kaludercic <philipk@posteo.net> writes:
>> >> So in general, this patch might be appropriate?
>> >>
>> >> diff --git a/lisp/emacs-lisp/loaddefs-gen.el b/lisp/emacs-lisp/loaddefs-gen.el
>> >> index 581053f6304..42f386933dc 100644
>> >> --- a/lisp/emacs-lisp/loaddefs-gen.el
>> >> +++ b/lisp/emacs-lisp/loaddefs-gen.el
>> >> @@ -433,7 +433,8 @@ loaddefs-generate--parse-file
>> >> ;; loaddefs for packages so that `syntax-ppss' later gives
>> >> ;; correct results.
>> >> (emacs-lisp-mode)
>> >> - (let ((version (lm-header "version"))
>> >> + (let ((version (or (lm-header "package-version")
>> >> + (lm-header "version")))
>> >> package)
>> >> (when (and version
>> >> (setq version (ignore-errors (version-to-list version)))
>> >>
>> >>
>> >
>> > What about making `lm-version' handle the "package-version" header then
>> > using `lm-version' in loaddefs-generate--parse-file? See patches.
>> >
>> > Joseph
>
>
>
>
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 7%]
* bug#69528: 30.0.50; [BUG] transient.el is not a member of package--builtin-versions
2024-05-25 8:04 7% ` Philip Kaludercic
@ 2024-05-25 8:08 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-05-25 8:47 5% ` Philip Kaludercic
2024-05-25 10:49 0% ` Eli Zaretskii
1 sibling, 1 reply; 200+ results
From: Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-05-25 8:08 UTC (permalink / raw)
To: Philip Kaludercic; +Cc: eliz, 69528, iarchivedmywholelife
Philip Kaludercic <philipk@posteo.net> writes:
> Joseph Turner <joseph@breatheoutbreathe.in> writes:
>
>> Philip Kaludercic <philipk@posteo.net> writes:
>>> So in general, this patch might be appropriate?
>>>
>>> diff --git a/lisp/emacs-lisp/loaddefs-gen.el b/lisp/emacs-lisp/loaddefs-gen.el
>>> index 581053f6304..42f386933dc 100644
>>> --- a/lisp/emacs-lisp/loaddefs-gen.el
>>> +++ b/lisp/emacs-lisp/loaddefs-gen.el
>>> @@ -433,7 +433,8 @@ loaddefs-generate--parse-file
>>> ;; loaddefs for packages so that `syntax-ppss' later gives
>>> ;; correct results.
>>> (emacs-lisp-mode)
>>> - (let ((version (lm-header "version"))
>>> + (let ((version (or (lm-header "package-version")
>>> + (lm-header "version")))
>>> package)
>>> (when (and version
>>> (setq version (ignore-errors (version-to-list version)))
>>>
>>>
>>
>> What about making `lm-version' handle the "package-version" header then
>> using `lm-version' in loaddefs-generate--parse-file? See patches.
>
> My main concern was if we want to have Package-Version always override
> Version, but if my patch modified loaddefs-gen, then I don't think there
> is much of a difference if we change lisp-mnt instead (in terms of the
> generality of the change).
If it would be more appropriate, I can resubmit another patch with
"Version" used preferentially over "Package-Version".
> So I am fine with the change, and think we can merge it. Eli: Is master
> still fine for these kinds of changes?
>
>> Joseph
>>
>>>From e83ee369ae90e5e15b3adca9eab1ded4db864427 Mon Sep 17 00:00:00 2001
>> From: Joseph Turner <joseph@breatheoutbreathe.in>
>> Date: Mon, 4 Mar 2024 22:15:50 -0800
>> Subject: [PATCH 2/2] Use lm-version instead of lm-header "version"
>>
>> bug#69528
>>
>> * lisp/emacs-lisp/loaddefs-gen.el (loaddefs-generate--parse-file)
>> ---
>> lisp/emacs-lisp/loaddefs-gen.el | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/lisp/emacs-lisp/loaddefs-gen.el b/lisp/emacs-lisp/loaddefs-gen.el
>> index 581053f6304..6b24f7dc8c7 100644
>> --- a/lisp/emacs-lisp/loaddefs-gen.el
>> +++ b/lisp/emacs-lisp/loaddefs-gen.el
>> @@ -433,7 +433,7 @@ loaddefs-generate--parse-file
>> ;; loaddefs for packages so that `syntax-ppss' later gives
>> ;; correct results.
>> (emacs-lisp-mode)
>> - (let ((version (lm-header "version"))
>> + (let ((version (lm-version))
>> package)
>> (when (and version
>> (setq version (ignore-errors (version-to-list version)))
>> --
>> 2.41.0
>>
>>
>>>From 20db8c9afcb03d8a5acb750fa738c5066e204401 Mon Sep 17 00:00:00 2001
>> From: Joseph Turner <joseph@breatheoutbreathe.in>
>> Date: Mon, 4 Mar 2024 22:14:26 -0800
>> Subject: [PATCH 1/2] Check Package-Version: header in lm-version also
>>
>> * lisp/emacs-lisp/lisp-mnt.el (lm-version)
>> ---
>> lisp/emacs-lisp/lisp-mnt.el | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/lisp/emacs-lisp/lisp-mnt.el b/lisp/emacs-lisp/lisp-mnt.el
>> index f111a77663c..12b23853801 100644
>> --- a/lisp/emacs-lisp/lisp-mnt.el
>> +++ b/lisp/emacs-lisp/lisp-mnt.el
>> @@ -416,6 +416,7 @@ lm-version
>> This can be found in an RCS or SCCS header."
>> (lm-with-file file
>> (or (lm-header "version")
>> + (lm-header "package-version")
>> (let ((header-max (lm-code-start)))
>> (goto-char (point-min))
>> (cond
>
> Joseph Turner <joseph@breatheoutbreathe.in> writes:
>
>> Joseph Turner <joseph@breatheoutbreathe.in> writes:
>>
>>> Philip Kaludercic <philipk@posteo.net> writes:
>>>> So in general, this patch might be appropriate?
>>>>
>>>> diff --git a/lisp/emacs-lisp/loaddefs-gen.el b/lisp/emacs-lisp/loaddefs-gen.el
>>>> index 581053f6304..42f386933dc 100644
>>>> --- a/lisp/emacs-lisp/loaddefs-gen.el
>>>> +++ b/lisp/emacs-lisp/loaddefs-gen.el
>>>> @@ -433,7 +433,8 @@ loaddefs-generate--parse-file
>>>> ;; loaddefs for packages so that `syntax-ppss' later gives
>>>> ;; correct results.
>>>> (emacs-lisp-mode)
>>>> - (let ((version (lm-header "version"))
>>>> + (let ((version (or (lm-header "package-version")
>>>> + (lm-header "version")))
>>>> package)
>>>> (when (and version
>>>> (setq version (ignore-errors (version-to-list version)))
>>>>
>>>>
>>>
>>> What about making `lm-version' handle the "package-version" header then
>>> using `lm-version' in loaddefs-generate--parse-file? See patches.
>>>
>>> Joseph
>>>
>>> [2. text/x-diff; 0002-Use-lm-version-instead-of-lm-header-version.patch]...
>>>
>>> [3. text/x-diff; 0001-Check-Package-Version-header-in-lm-version-also.patch]...
>>
>> Ping!
>>
>>
>>
>>
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
>> Ping! Ping! Philip, can you please chime in?
>>
>>> Cc: 69528@debbugs.gnu.org, iarchivedmywholelife@gmail.com
>>> Date: Wed, 08 May 2024 23:53:38 -0700
>>> From: Joseph Turner via "Bug reports for GNU Emacs,
>>> the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>>>
>>> Joseph Turner <joseph@breatheoutbreathe.in> writes:
>>>
>>> > Philip Kaludercic <philipk@posteo.net> writes:
>>> >> So in general, this patch might be appropriate?
>>> >>
>>> >> diff --git a/lisp/emacs-lisp/loaddefs-gen.el b/lisp/emacs-lisp/loaddefs-gen.el
>>> >> index 581053f6304..42f386933dc 100644
>>> >> --- a/lisp/emacs-lisp/loaddefs-gen.el
>>> >> +++ b/lisp/emacs-lisp/loaddefs-gen.el
>>> >> @@ -433,7 +433,8 @@ loaddefs-generate--parse-file
>>> >> ;; loaddefs for packages so that `syntax-ppss' later gives
>>> >> ;; correct results.
>>> >> (emacs-lisp-mode)
>>> >> - (let ((version (lm-header "version"))
>>> >> + (let ((version (or (lm-header "package-version")
>>> >> + (lm-header "version")))
>>> >> package)
>>> >> (when (and version
>>> >> (setq version (ignore-errors (version-to-list version)))
>>> >>
>>> >>
>>> >
>>> > What about making `lm-version' handle the "package-version" header then
>>> > using `lm-version' in loaddefs-generate--parse-file? See patches.
>>> >
>>> > Joseph
>>
>>
>>
>>
^ permalink raw reply [relevance 5%]
* bug#69528: 30.0.50; [BUG] transient.el is not a member of package--builtin-versions
2024-05-25 8:08 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-05-25 8:47 5% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-05-25 8:47 UTC (permalink / raw)
To: Joseph Turner; +Cc: eliz, 69528, iarchivedmywholelife
Joseph Turner <joseph@breatheoutbreathe.in> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Joseph Turner <joseph@breatheoutbreathe.in> writes:
>>
>>> Philip Kaludercic <philipk@posteo.net> writes:
>>>> So in general, this patch might be appropriate?
>>>>
>>>> diff --git a/lisp/emacs-lisp/loaddefs-gen.el b/lisp/emacs-lisp/loaddefs-gen.el
>>>> index 581053f6304..42f386933dc 100644
>>>> --- a/lisp/emacs-lisp/loaddefs-gen.el
>>>> +++ b/lisp/emacs-lisp/loaddefs-gen.el
>>>> @@ -433,7 +433,8 @@ loaddefs-generate--parse-file
>>>> ;; loaddefs for packages so that `syntax-ppss' later gives
>>>> ;; correct results.
>>>> (emacs-lisp-mode)
>>>> - (let ((version (lm-header "version"))
>>>> + (let ((version (or (lm-header "package-version")
>>>> + (lm-header "version")))
>>>> package)
>>>> (when (and version
>>>> (setq version (ignore-errors (version-to-list version)))
>>>>
>>>>
>>>
>>> What about making `lm-version' handle the "package-version" header then
>>> using `lm-version' in loaddefs-generate--parse-file? See patches.
>>
>> My main concern was if we want to have Package-Version always override
>> Version, but if my patch modified loaddefs-gen, then I don't think there
>> is much of a difference if we change lisp-mnt instead (in terms of the
>> generality of the change).
>
> If it would be more appropriate, I can resubmit another patch with
> "Version" used preferentially over "Package-Version".
No, I believe that would be wrong, at least going by these quotes from
the manual:
(elisp) Simple Packages:
The version number comes from the ‘Package-Version’ header, if it
exists, or from the ‘Version’ header otherwise. One or the other _must_
be present. Here, the version number is 1.3.
(elisp) Library Headers:
‘Package-Version’
If ‘Version’ is not suitable for use by the package manager, then a
package can define ‘Package-Version’; it will be used instead.
This is handy if ‘Version’ is an RCS id or something else that
cannot be parsed by ‘version-to-list’.
So the patch is fine as it is.
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 5%]
* bug#69528: 30.0.50; [BUG] transient.el is not a member of package--builtin-versions
2024-05-25 8:04 7% ` Philip Kaludercic
2024-05-25 8:08 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-05-25 10:49 0% ` Eli Zaretskii
1 sibling, 0 replies; 200+ results
From: Eli Zaretskii @ 2024-05-25 10:49 UTC (permalink / raw)
To: Philip Kaludercic, Stefan Monnier, Stefan Kangas, Andrea Corallo
Cc: iarchivedmywholelife, 69528, joseph
> Cc: 69528@debbugs.gnu.org, iarchivedmywholelife@gmail.com
> From: Philip Kaludercic <philipk@posteo.net>
> Date: Sat, 25 May 2024 08:04:24 +0000
>
> Joseph Turner <joseph@breatheoutbreathe.in> writes:
>
> > What about making `lm-version' handle the "package-version" header then
> > using `lm-version' in loaddefs-generate--parse-file? See patches.
>
> My main concern was if we want to have Package-Version always override
> Version, but if my patch modified loaddefs-gen, then I don't think there
> is much of a difference if we change lisp-mnt instead (in terms of the
> generality of the change).
>
> So I am fine with the change, and think we can merge it. Eli: Is master
> still fine for these kinds of changes?
I think so, yes. But maybe I don't fully understand the effect of
this change? Can you describe it?
I also added the other maintainers, in case they have opinions on
this.
Thanks.
^ permalink raw reply [relevance 0%]
Results 201-400 of ~500 next (newer) | prev (older) | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2023-05-13 5:27 bug#63480: 30.0.50; [BUG] unimplemented logic regarding read-symbol-shorthands Ruijie Yu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-06 20:17 ` Stefan Kangas
2023-11-29 7:45 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-29 8:12 5% ` João Távora
2024-04-18 20:01 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-18 20:24 5% ` João Távora
2024-04-18 20:52 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-23 21:38 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-06 2:13 bug#65768: Bump persist.el version Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-06 16:39 ` Stefan Kangas
2023-10-30 20:54 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-31 12:07 5% ` phillip.lord
2023-10-31 15:41 7% ` Joseph Turner
2023-10-31 16:43 0% ` Eli Zaretskii
2023-10-31 17:05 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-01 0:34 5% ` Stefan Kangas
2023-11-12 4:26 28% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-10 21:39 5% ` Stefan Kangas
2024-01-12 8:51 0% ` phillip.lord
2024-01-12 9:15 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-12 13:10 5% ` phillip.lord
2024-01-13 9:41 5% ` Stefan Kangas
2024-01-13 19:14 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-13 9:45 8% ` Stefan Kangas
2024-01-13 19:15 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-06 20:38 5% ` phillip.lord
2023-11-12 4:27 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-07 7:53 bug#65797: 29.0.92; func-arity should not return (0 . many) with apply-partially Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-07 15:50 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-08 17:01 ` bug#65797: `buffer-match-p` should not use `func-arity` Philip Kaludercic
2023-09-12 18:28 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-13 21:50 ` Philip Kaludercic
2023-09-14 13:47 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-18 9:12 ` Philip Kaludercic
2023-09-18 11:55 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-18 17:23 ` Philip Kaludercic
2023-09-18 18:05 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-19 8:34 ` Philip Kaludercic
2023-09-19 10:06 ` Dmitry Gutov
2023-09-19 13:56 ` Philip Kaludercic
2023-09-19 16:13 ` Dmitry Gutov
2023-10-08 9:10 ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-09 21:40 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-12 4:53 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-12 11:34 ` Dmitry Gutov
2023-10-13 15:57 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-14 6:13 0% ` Eli Zaretskii
2023-10-14 14:31 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-15 6:13 ` Eli Zaretskii
2023-10-16 16:33 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-16 20:16 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-20 7:02 bug#66114: [PATCH] Fix interactive prompt for selecting checkout directory Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-22 8:21 ` Philip Kaludercic
2023-09-24 5:06 ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-24 14:37 ` Philip Kaludercic
2023-09-24 21:27 ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-30 8:42 11% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-14 16:54 5% ` Philip Kaludercic
2024-02-15 17:27 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-20 7:14 bug#66115: [PATCH] Ensure that directory is expanded in package-vc-checkout Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-22 8:17 ` Philip Kaludercic
2023-09-22 8:33 ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-22 10:51 ` Philip Kaludercic
2023-09-24 5:34 ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-24 6:54 ` Eli Zaretskii
[not found] ` <87msviogui.fsf@breatheoutbreathe.in>
2023-11-16 6:44 5% ` Philip Kaludercic
2023-11-19 22:16 11% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-25 10:17 0% ` Eli Zaretskii
2023-11-25 22:59 11% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-26 10:41 0% ` Eli Zaretskii
2023-11-26 20:39 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-27 12:01 0% ` Eli Zaretskii
2023-12-08 10:25 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-24 21:31 bug#66187: read-file-name unexpected behavior when MUSTMATCH is a function Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-25 3:58 ` Michael Heerdegen
2023-09-25 5:12 ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-25 21:33 ` Michael Heerdegen
2023-09-26 8:37 ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-27 0:26 ` Michael Heerdegen
2023-09-27 0:55 ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-27 1:43 ` Michael Heerdegen
2023-10-03 21:18 ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-04 7:03 ` Eli Zaretskii
2023-10-05 19:34 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-06 4:45 ` Eli Zaretskii
2023-10-06 13:01 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-06 13:46 ` Eli Zaretskii
2023-10-06 16:43 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-07 5:23 ` Eli Zaretskii
2023-10-07 14:25 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-07 15:09 ` Eli Zaretskii
2023-10-07 15:12 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-12 21:26 10% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-26 6:49 11% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-18 0:24 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-19 2:52 9% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-09 8:06 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-25 20:53 10% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-28 19:20 0% ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-28 19:28 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-27 1:16 bug#66224: [PATCH] Add optional PREDICATE argument to read-directory-name Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-28 9:05 ` Philip Kaludercic
2023-09-29 3:28 ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-29 3:54 ` Michael Heerdegen
2023-09-29 4:19 ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-03 3:30 ` Michael Heerdegen
2023-10-03 23:20 ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-05 1:23 ` Michael Heerdegen
2023-10-05 1:34 ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-12 20:42 11% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-13 10:53 5% ` Stefan Kangas
2024-01-13 19:26 8% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-07 18:40 bug#66393: [PATCH] Make package-vc-install-from-checkout NAME argument optional Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-08 15:43 ` Philip Kaludercic
2023-10-08 20:50 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-08 21:35 5% ` Philip Kaludercic
2023-10-08 9:57 bug#66403: [PATCH] Use delete-all-overlays in clean-mode Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-08 10:25 ` Eli Zaretskii
2023-10-08 21:21 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-08 21:24 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-08 9:58 bug#66404: " Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-08 10:26 ` Eli Zaretskii
2023-10-08 10:32 ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-08 11:40 ` Eli Zaretskii
2023-10-08 20:54 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-19 5:45 11% bug#66626: [PATCH] elpa-packages (hyperdrive): Update ':doc' property Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-20 20:04 5% ` Stefan Kangas
2023-10-23 21:23 10% bug#66716: Reconcile display-fill-column-indicator-character behavior and customization description Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-24 12:31 0% ` Eli Zaretskii
2023-10-24 19:46 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-25 2:29 0% ` Eli Zaretskii
2023-10-25 3:11 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-20 19:50 5% bug#67325: shorthands: Incorrect autoloaded register-definition-prefixes Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-24 8:06 0% ` Eli Zaretskii
2023-11-24 9:24 0% ` João Távora
2023-11-25 4:18 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-25 12:44 5% ` João Távora
2023-11-22 22:18 bug#67390: 28; shorthands-font-lock-shorthands assumes shorthand uses same separator Jonas Bernoulli via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-23 12:57 ` João Távora
2023-11-24 21:51 ` Jonas Bernoulli via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-25 0:03 ` João Távora
2023-11-25 3:26 9% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-25 16:01 5% ` Jonas Bernoulli via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-25 22:42 9% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-26 13:52 4% ` João Távora
2023-11-26 20:35 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-26 22:02 5% ` João Távora
2023-11-27 3:48 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-27 12:10 0% ` Eli Zaretskii
2023-11-29 8:21 0% ` João Távora
2023-11-29 9:12 4% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-29 13:56 5% ` João Távora
2023-11-29 13:30 0% ` João Távora
2023-11-29 23:27 0% ` João Távora
2023-11-30 14:16 ` João Távora
2023-11-30 15:23 0% ` Eli Zaretskii
2023-12-09 18:50 8% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-03 7:10 11% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-03 14:50 5% ` João Távora
2024-02-03 19:43 10% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-03 22:25 5% ` João Távora
2024-02-03 23:48 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-05-21 22:05 10% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-29 8:03 4% bug#67523: check-declare doesn't account for shorthands Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-29 9:56 5% ` João Távora
2023-11-29 10:35 0% ` João Távora
2023-11-29 11:12 0% ` João Távora
2023-12-10 10:57 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-30 22:56 5% bug#68158: isearch-wrap-pause 'no or 'no-ding breaks isearch-delete-char Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-04 11:10 0% ` Eli Zaretskii
2024-01-04 17:02 ` Juri Linkov
2024-01-04 17:49 0% ` Eli Zaretskii
2024-01-04 18:58 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-05 5:09 5% bug#68251: message-yank-buffer insert many copies of image Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-05 12:09 0% ` Eli Zaretskii
2024-01-05 15:58 0% ` Eli Zaretskii
2024-01-05 16:24 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-05 16:35 0% ` Eli Zaretskii
2024-01-05 16:22 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-08 8:59 5% bug#68317: Can't sort *Packages* buffer by version after installing with package-vc Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-08 13:03 0% ` Eli Zaretskii
2024-01-09 19:25 0% ` Philip Kaludercic
2024-01-09 19:53 0% ` Eli Zaretskii
2024-01-09 20:19 0% ` Philip Kaludercic
2024-01-10 3:27 0% ` Eli Zaretskii
2024-01-10 5:16 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-10 8:28 5% ` Philip Kaludercic
2024-01-10 13:13 0% ` Eli Zaretskii
2024-01-30 9:00 4% bug#68815: Unexpected behavior with read-file-name and functional REQUIRE-MATCH argument Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-30 13:08 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-31 6:11 10% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-31 13:28 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-31 19:33 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-31 22:05 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-31 22:34 9% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-01 6:59 ` Eli Zaretskii
2024-02-01 7:04 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-01 7:39 5% ` Stefan Kangas
2024-02-01 7:59 0% ` Eli Zaretskii
2024-02-01 22:26 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-03 17:25 bug#69528: 30.0.50; [BUG] transient.el is not a member of package--builtin-versions No Wayman
2024-03-04 17:22 ` No Wayman
2024-03-04 18:41 ` Philip Kaludercic
2024-03-05 6:17 11% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-05-09 6:53 11% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-05-25 7:39 0% ` Eli Zaretskii
2024-05-25 8:04 7% ` Philip Kaludercic
2024-05-25 8:08 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-05-25 8:47 5% ` Philip Kaludercic
2024-05-25 10:49 0% ` Eli Zaretskii
2024-03-07 5:37 3% bug#69602: 29.1; Image :map should adjust with :scale and :rotation Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-07 7:04 0% ` Eli Zaretskii
2024-03-07 7:14 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-07 7:55 0% ` Eli Zaretskii
2024-03-07 8:08 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-07 9:27 0% ` Eli Zaretskii
2024-03-07 13:53 7% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-08 7:02 9% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-08 8:31 0% ` Eli Zaretskii
2024-03-08 8:39 9% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-08 11:50 0% ` Eli Zaretskii
2024-03-21 6:45 3% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-21 11:59 0% ` Eli Zaretskii
2024-03-23 0:11 3% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-23 7:58 0% ` Eli Zaretskii
2024-03-23 17:41 3% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-23 17:58 0% ` Eli Zaretskii
2024-03-23 18:18 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-23 20:32 10% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-28 10:13 0% ` Eli Zaretskii
2024-03-08 7:24 0% ` Eli Zaretskii
2024-03-24 9:07 4% bug#69972: 29.1; Unexpected behavior when scrolling images Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-24 9:42 0% ` Eli Zaretskii
2024-03-25 1:06 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-25 8:34 11% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-25 12:23 0% ` Eli Zaretskii
2024-03-25 19:43 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-28 6:24 0% ` Eli Zaretskii
2024-03-25 1:00 10% bug#69992: Minor improvement to image map transformation logic Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-27 11:16 ` David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-27 12:50 ` Eli Zaretskii
2024-03-27 14:21 ` David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-27 22:17 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-27 23:53 5% ` David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-28 22:22 1% ` David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-29 10:19 ` David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-30 8:10 0% ` Eli Zaretskii
2024-03-30 8:55 0% ` David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-30 12:59 0% ` David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-30 19:07 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-25 22:15 1% bug#70003: 29.2; persist on elpa is missing EDDSA public key Xiyue Deng
2024-03-25 22:44 0% ` Xiyue Deng
2024-03-30 19:44 5% bug#70093: Remove unnecessary `image-tests--map-equal' Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-30 22:04 5% ` bug#70093: *** SPAM *** " David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-31 7:37 8% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-31 10:08 4% ` David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-02 10:36 ` David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-06 1:50 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-07 16:01 4% ` David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-31 5:10 0% ` Eli Zaretskii
2024-03-31 5:32 8% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-31 7:33 0% ` Eli Zaretskii
2024-04-05 8:57 5% bug#70213: Info-mode side window fit-window-to-buffer issue Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-05 12:30 0% ` Eli Zaretskii
2024-04-05 15:04 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-05 15:33 5% ` Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-05 21:58 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-05 22:21 5% ` Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-06 1:34 9% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-06 1:55 ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-06 2:36 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-06 11:39 5% ` Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-06 17:19 4% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-06 18:39 ` Juri Linkov
2024-04-07 8:52 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-07 17:53 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-07 19:29 5% ` Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-07 23:11 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-08 7:56 5% ` Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-08 11:04 0% ` Eli Zaretskii
[not found] ` <87ttkaij8v.fsf@breatheoutbreathe.in>
2024-04-09 18:24 0% ` Eli Zaretskii
2024-04-10 5:12 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-10 8:47 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-10 17:40 ` Juri Linkov
2024-04-11 9:17 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-12 6:45 ` Juri Linkov
2024-04-12 7:12 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-06 19:19 5% ` Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-07 1:59 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-07 9:30 5% ` Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-07 17:47 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-07 19:29 5% ` Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-07 20:07 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-07 20:51 5% ` Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-07 22:13 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-07 22:35 5% ` Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-07 23:06 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-05 16:09 ` Juri Linkov
2024-04-05 21:57 5% ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).