* Re: Proposal for 'package-isolate' command
@ 2023-08-18 7:49 94% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-08-18 7:49 UTC (permalink / raw)
To: Thierry Volpiatto; +Cc: emacs-devel
Thierry Volpiatto <thievol@posteo.net> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>>> Forget it, it is working properly, just forget you had modified
>>> package--dependencies as well.
>>> Sorry for the noise.
>>
>> It was either that or a new function had to be added, not sure which
>> approach is worse. The current implementation seems to have been
>> hastily added by Lars last year, and it is a bit regrettable in
>> retrospect. It would be possible to modify my change, and have the
>> function always return package-desc objects, since the function is only
>> used in one other spot in another part of the file. While there might
>> be others (packages or individuals) that depend on the function behaving
>> the way it does, but on the other hand, convention designates it as
>> being an "internal" function.
>
> The actual version is something like 4 or 5 lines long, so external
> packages can inline this version under another name if really needed,
> but your version is covering the both so it's ok I think.
> OTOH The problem with package.el is inconsistency within its functions,
> sometimes you have to use a pkg-desc as arg, sometimes not, sometimes
> functions return a list of symbols sometimes a list of pkg-desc, what is
> a package name, a string or a symbol? What is a pkg-desc exactly,
> sometimes it is the cdr in other places the cadr is used...
> Also built-in packages don't have the same format unless they are distributed
> in Elpa etc...
Right, there is certainly work to be done.
>>> Some packages seems to require a specific version of a package for their
>>> dependency e.g. seq, by excluding it the package may not work correctly,
>>> this is my understanding but I may be wrong. Also perhaps the package
>>> e.g. seq is selected later when computing dependencies but maybe user
>>> wants to select a particular version manually in the first place?
>>
>> The current algorithm should pick the first package in the package alist
>> that satisfies the necessary dependencies. Perhaps that should be
>> re-thought or the selection should be more clever, e.g. if the user
>> explicitly specifies a dependency with a version, then it should be
>> preferred to whatever other dependency might be determined, at the
>> possible expense of triggering runtime bugs.
>
> I think it is hard to cover all cases, but after all it is more a
> developer tool for debugging a particular package than a end user tool
> to run packages, so perhaps the developer can give directives about
> dependencies to use when needed.
>
> Another thing, you use actually
>
> (expand-file-name invocation-name invocation-directory)
>
> I suggest you use the truename of this instead as emacs can be symlinked
> in some installations. It should work with the symlink name, but it is
> clearer which emacs version is used.
I second Eli's question here, what difference would it make? Clearer to
whom?
> Now your function is working fine and nearly finish, did you think how
> you are going to distribute it? It seems you are going to merge it in
> master, but what about providing it as well as a Elpa package so that
> users of old emacs (at some point of course, say emacs-27) can use it to
> report bugs?
I am not a fan of small ELPA packages, but what I'd like to bring up
again was the proposal to add package.el itself to ELPA. I wrote a
patch in <873559q83j.fsf@posteo.net> that should arrange everything
necessary for this move, there are still a few points that should be
discussed in terms of stability and recovering from a possibly
inconsistent state. I think I'll create a feature branch some day soon
to make the proposal more concrete.
> Thanks.
^ permalink raw reply [relevance 94%]
* Re: Preferred approach to inclusion of data in ELPA package
@ 2023-08-17 21:14 96% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-08-17 21:14 UTC (permalink / raw)
To: Hugo Thunnissen; +Cc: emacs-devel
Hugo Thunnissen <devel@hugot.nl> writes:
> Hi all,
>
> For my package phpinspect.el I am now looking into the creation of an
> index of PHP's built in functions and classes. I'm considering
> different ways of distributing this dataset, but I'm not entirely sure
> what would be the preferred way. Finding out the signatures/properties
> of built in functions and classes is straightforward: I can generate
> valid PHP stubs for them which can then be parsed an indexed by my
> package just like any other PHP code. What I'm not sure about is what
> the best way would be to distribute this data. Options I'm considering
> are:
>
> 1. Distribute the stubs with the package and parse them each time
> **when the package is loaded**.
>
> 2. Parse and index the stubs, then serialize the resulting index into
> a gzipped lisp data file that is checked into version control, and is
> loaded **when the package is loaded**. (BTW, should such a .eld file
> be byte compiled for any reason?)
>
> 3. Parse and index the stubs, then serialize the resulting index
> **during compile time**. Either by generating lisp code using a macro,
> or by serializing the index into a .eld file. This guarantees the
> index staying up to date with the contents of the stub files whenever
> the package is compiled.
>
> Some more info: I expect the initial dataset to be a file with about
> 2000 stub functions and 200something stub classes, but it will grow as
> PHP grows and as phpinspect starts to cover more of PHP's features
> (for example, constant variables may also be included at some point in
> the near future, growing the index by a bit). I guesstimate that it
> would take less than 300ms to parse a set of files like that on most
> modern hardware, but I don't have the benchmarks to back that up yet.
>
> I'm personally leaning towards option 3 and using a macro during
> compile time, but I could be nudged either way. Which approach would
> be preferable and why? Is there a common practice for things like
> this?
Another idea is to have a Makefile generate the file, like the one you
describe in option 2., that is generate whenever the package is built
and bundled into a tarball for distribution. That way you don't have to
store a binary blob in your repository, and you can avoid burdening the
user with additional computations at either compile or runtime.
Does the generation require any special functionality/tools/code to be
provided on the device the index is generated on?
> Thanks,
>
> - Hugo
^ permalink raw reply [relevance 96%]
* Re: Proposal for 'package-isolate' command
@ 2023-08-17 18:17 85% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-08-17 18:17 UTC (permalink / raw)
To: Thierry Volpiatto; +Cc: emacs-devel
Thierry Volpiatto <thievol@posteo.net> writes:
> Thierry Volpiatto <thievol@posteo.net> writes:
>
>> Philip Kaludercic <philipk@posteo.net> writes:
>>
>>> Thierry Volpiatto <thievol@posteo.net> writes:
>>>
>>>> Philip Kaludercic <philipk@posteo.net> writes:
>>>>
>>>>>> No don't worry, helm will work in any cases, thanks.
>>>>>
>>>>> OK, in that case I'd prefer to keep it the way it is.
>>>>
>>>> Ok, fair enough.
>>>>
>>>>>>> Mainly to avoid issues with packages that might place files in the
>>>>>>> configuration directory, which might hinder the reproduction of bugs.
>>>>>>
>>>>>> Hmm, maybe, I don't have an example in mind though.
>>>>>
>>>>> It might not be the best example, but my package autocrypt generates a
>>>>> file in the `user-emacs-directory'. If we don't use --init-directory,
>>>>> the existing file would be re-used.
>>>>
>>>> Ok, for such case it is easy to either rename the file temporarily to
>>>> foo_ori or foo_save or to set the variable handling the file (generally
>>>> it is not harcoded) to something else. But another issue is if your
>>>> isolated package needs the history file or tramp file or whatever file
>>>> ~/.emacs.d is handling; e.g. a package providing completion on history.
>>>> I still think it is more handy to reuse user-emacs-directory and its
>>>> elpa directory where the packages are already installed.
>>>
>>> How about this patch, that will use a temporary directory when
>>> `package-isolate' is invoked with a prefix argument (not sure what the
>>> default should be, I guess reusing `user-emacs-directory' is less
>>> surprising):
>>
>> However it is not working properly:
>>
>> Tried to isolate two packages, osm and w3m, and osm use compat as
>> dependency:
>>
>> Unable to activate package ‘osm’.
>> Required package ‘compat-29.1.4.0’ is unavailable
>
> Forget it, it is working properly, just forget you had modified
> package--dependencies as well.
> Sorry for the noise.
It was either that or a new function had to be added, not sure which
approach is worse. The current implementation seems to have been
hastily added by Lars last year, and it is a bit regrettable in
retrospect. It would be possible to modify my change, and have the
function always return package-desc objects, since the function is only
used in one other spot in another part of the file. While there might
be others (packages or individuals) that depend on the function behaving
the way it does, but on the other hand, convention designates it as
being an "internal" function.
Thierry Volpiatto <thievol@posteo.net> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Thierry Volpiatto <thievol@posteo.net> writes:
>>
>>> Hello Philip,
>>>
>>> Philip Kaludercic <philipk@posteo.net> writes:
>>>
>>>> Thierry Volpiatto <thievol@posteo.net> writes:
>>>>
>>>>> Philip Kaludercic <philipk@posteo.net> writes:
>>>>>
>>>>>>> No don't worry, helm will work in any cases, thanks.
>>>>>>
>>>>>> OK, in that case I'd prefer to keep it the way it is.
>>>>>
>>>>> Ok, fair enough.
>>>>>
>>>>>>>> Mainly to avoid issues with packages that might place files in the
>>>>>>>> configuration directory, which might hinder the reproduction of bugs.
>>>>>>>
>>>>>>> Hmm, maybe, I don't have an example in mind though.
>>>>>>
>>>>>> It might not be the best example, but my package autocrypt generates a
>>>>>> file in the `user-emacs-directory'. If we don't use --init-directory,
>>>>>> the existing file would be re-used.
>>>>>
>>>>> Ok, for such case it is easy to either rename the file temporarily to
>>>>> foo_ori or foo_save or to set the variable handling the file (generally
>>>>> it is not harcoded) to something else. But another issue is if your
>>>>> isolated package needs the history file or tramp file or whatever file
>>>>> ~/.emacs.d is handling; e.g. a package providing completion on history.
>>>>> I still think it is more handy to reuse user-emacs-directory and its
>>>>> elpa directory where the packages are already installed.
>>>>
>>>> How about this patch, that will use a temporary directory when
>>>> `package-isolate' is invoked with a prefix argument (not sure what the
>>>> default should be, I guess reusing `user-emacs-directory' is less
>>>> surprising):
>>>
>>> Yes.
>>>
>>> Isn't these two loop the same? (save one loop)
>>
>> No, because that assumes that we are only interested in the first
>> package descriptor in every package--alist entry, while there might be
>> multiple.
>
> Ah ok.
>
>>> (cl-loop for p in (cl-loop for p in (package--alist) append (cdr p))
>>> unless (package-built-in-p p)
>>
>> Also, do we want this or wouldn't it be useful to be able to force a
>> built-in package being loaded?
>
> Some packages seems to require a specific version of a package for their
> dependency e.g. seq, by excluding it the package may not work correctly,
> this is my understanding but I may be wrong. Also perhaps the package
> e.g. seq is selected later when computing dependencies but maybe user
> wants to select a particular version manually in the first place?
The current algorithm should pick the first package in the package alist
that satisfies the necessary dependencies. Perhaps that should be
re-thought or the selection should be more clever, e.g. if the user
explicitly specifies a dependency with a version, then it should be
preferred to whatever other dependency might be determined, at the
possible expense of triggering runtime bugs.
^ permalink raw reply [relevance 85%]
* Re: Proposal for 'package-isolate' command
@ 2023-08-17 14:19 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-08-17 14:19 UTC (permalink / raw)
To: Eshel Yaron; +Cc: Thierry Volpiatto, emacs-devel
Eshel Yaron <me@eshelyaron.com> writes:
> Hi Philip,
>
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> How about this patch, that will use a temporary directory when
>> `package-isolate' is invoked with a prefix argument (not sure what the
>> default should be, I guess reusing `user-emacs-directory' is less
>> surprising):
>
> I'm again looking forward to trying this out, I think it could be
> helpful for testing the Compat integration I'm working on for a package
> of mine. I also again have a couple of minor suggestions around
> documentation:
>
>> (defun package--dependencies (pkg)
>> - "Return a list of all dependencies PKG has.
>> -This is done recursively."
>> - ;; Can we have circular dependencies? Assume "nope".
>> - (when-let* ((desc (cadr (assq pkg package-archive-contents)))
>> - (deps (mapcar #'car (package-desc-reqs desc))))
>> - (delete-dups (apply #'nconc deps (mapcar #'package--dependencies deps)))))
>> + "Return a list of all recursive dependencies of PKG.
>
> I'd say "transitive" rather than "recursive" dependencies, because I
> think a recursive dependency is more commonly used to refer to a case in
> which a package (or library, etc.) depends on itself.
I wouldn't say recursive but cyclical in that case, but either way I
think transitive is a better word here. Will change it.
>> +If PKG is a package descriptor, the return value will consist of
>> +a list of package descriptors. If PKG is a symbol, designating a
>> +package, the return value will be a list of symbols designating
>> +packages."
>
> Personally, I find the future tense less clear than the present tense
> when describing deterministic software behavior. So usually I prefer it
> when the docs say what the program "does", not what it "will do". In
> this case that be "if PKG is a package descriptor, the return value is a
> list of package descriptors..."
Right, makes sense as well.
> Best,
>
> Eshel
^ permalink raw reply [relevance 99%]
* Re: Proposal for 'package-isolate' command
@ 2023-08-17 14:18 97% ` Philip Kaludercic
1 sibling, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-08-17 14:18 UTC (permalink / raw)
To: Thierry Volpiatto; +Cc: emacs-devel
Thierry Volpiatto <thievol@posteo.net> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Thierry Volpiatto <thievol@posteo.net> writes:
>>
>>> Philip Kaludercic <philipk@posteo.net> writes:
>>>
>>>>> No don't worry, helm will work in any cases, thanks.
>>>>
>>>> OK, in that case I'd prefer to keep it the way it is.
>>>
>>> Ok, fair enough.
>>>
>>>>>> Mainly to avoid issues with packages that might place files in the
>>>>>> configuration directory, which might hinder the reproduction of bugs.
>>>>>
>>>>> Hmm, maybe, I don't have an example in mind though.
>>>>
>>>> It might not be the best example, but my package autocrypt generates a
>>>> file in the `user-emacs-directory'. If we don't use --init-directory,
>>>> the existing file would be re-used.
>>>
>>> Ok, for such case it is easy to either rename the file temporarily to
>>> foo_ori or foo_save or to set the variable handling the file (generally
>>> it is not harcoded) to something else. But another issue is if your
>>> isolated package needs the history file or tramp file or whatever file
>>> ~/.emacs.d is handling; e.g. a package providing completion on history.
>>> I still think it is more handy to reuse user-emacs-directory and its
>>> elpa directory where the packages are already installed.
>>
>> How about this patch, that will use a temporary directory when
>> `package-isolate' is invoked with a prefix argument (not sure what the
>> default should be, I guess reusing `user-emacs-directory' is less
>> surprising):
>
> However it is not working properly:
>
> Tried to isolate two packages, osm and w3m, and osm use compat as
> dependency:
>
> Unable to activate package ‘osm’.
> Required package ‘compat-29.1.4.0’ is unavailable
Sadly I cannot reproduce it, w3m is not in GNU or NonGNU ELPA, so unless
that is causing the issue, something like M-x package-isolate RET
avy-0.5.0,osm-0.13 RET shouldn't make an issue when it comes to
resolving dependencies, as the scratch message indicates:
--8<---------------cut here---------------start------------->8---
;; This is an isolated testing environment, with these packages enabled:
;; - avy-0.5.0
;; - compat-29.1.4.2 (dependency)
;; - osm-0.13
--8<---------------cut here---------------end--------------->8---
And M-x load-library RET compat RET works as well.
> With my simple version of package-isolate I have not this error, both
> osm w3m are installed correctly.
>
> (defun package-isolate (packages)
> "Start an uncustomised Emacs and only load a set of PACKAGES."
> (interactive
> (list (completing-read-multiple
> "Packages: " (mapcar #'car (package--alist)))))
> (let* ((name (concat "package-isolate-" (mapconcat #'identity packages ",")))
> (deps (cl-loop for p in packages
> for sym = (intern p)
> nconc (package--dependencies sym))))
> (apply #'start-process (concat "*" name "*") nil
> (list (file-truename (expand-file-name
> invocation-name invocation-directory))
> "--quick" "--debug-init"
> (format "--eval=%S"
> `(progn
> (require 'package)
> (setq package-load-list
> ',(append (mapcar (lambda (p) (list (intern p) t))
> packages)
> (mapcar (lambda (p) (list p t)) deps)))
> (package-initialize)))))))
>
>> [2. text/x-diff; 0001-Add-command-to-start-Emacs-with-specific-packages.patch]...
^ permalink raw reply [relevance 97%]
* Re: Proposal for 'package-isolate' command
@ 2023-08-17 14:04 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-08-17 14:04 UTC (permalink / raw)
To: Thierry Volpiatto; +Cc: emacs-devel
Thierry Volpiatto <thievol@posteo.net> writes:
> Hello Philip,
>
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Thierry Volpiatto <thievol@posteo.net> writes:
>>
>>> Philip Kaludercic <philipk@posteo.net> writes:
>>>
>>>>> No don't worry, helm will work in any cases, thanks.
>>>>
>>>> OK, in that case I'd prefer to keep it the way it is.
>>>
>>> Ok, fair enough.
>>>
>>>>>> Mainly to avoid issues with packages that might place files in the
>>>>>> configuration directory, which might hinder the reproduction of bugs.
>>>>>
>>>>> Hmm, maybe, I don't have an example in mind though.
>>>>
>>>> It might not be the best example, but my package autocrypt generates a
>>>> file in the `user-emacs-directory'. If we don't use --init-directory,
>>>> the existing file would be re-used.
>>>
>>> Ok, for such case it is easy to either rename the file temporarily to
>>> foo_ori or foo_save or to set the variable handling the file (generally
>>> it is not harcoded) to something else. But another issue is if your
>>> isolated package needs the history file or tramp file or whatever file
>>> ~/.emacs.d is handling; e.g. a package providing completion on history.
>>> I still think it is more handy to reuse user-emacs-directory and its
>>> elpa directory where the packages are already installed.
>>
>> How about this patch, that will use a temporary directory when
>> `package-isolate' is invoked with a prefix argument (not sure what the
>> default should be, I guess reusing `user-emacs-directory' is less
>> surprising):
>
> Yes.
>
> Isn't these two loop the same? (save one loop)
No, because that assumes that we are only interested in the first
package descriptor in every package--alist entry, while there might be
multiple.
> (cl-loop for p in (cl-loop for p in (package--alist) append (cdr p))
> unless (package-built-in-p p)
Also, do we want this or wouldn't it be useful to be able to force a
built-in package being loaded?
> collect (cons (package-desc-full-name p) p) into table
> finally return
> (list (cl-loop for c in (completing-read-multiple
> "Isolate packages: " table
> nil t)
> collect (alist-get c table nil nil #'string=))
> current-prefix-arg))
>
> (cl-loop for p in (package--alist)
> for desc = (cadr p)
> for name = (car p)
> unless (package-built-in-p desc)
> collect (cons (package-desc-full-name desc) p) into table
> finally return
> (list (cl-loop for c in (completing-read-multiple
> "Isolate packages: " table
> nil t)
> append (cdr (alist-get c table nil nil #'string=)))
> current-prefix-arg))
>
>
>> [2. text/x-diff;
>> 0001-Add-command-to-start-Emacs-with-specific-packages.patch]...
^ permalink raw reply [relevance 99%]
* Re: Proposal for 'package-isolate' command
@ 2023-08-17 8:34 49% ` Philip Kaludercic
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Philip Kaludercic @ 2023-08-17 8:34 UTC (permalink / raw)
To: Thierry Volpiatto; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1346 bytes --]
Thierry Volpiatto <thievol@posteo.net> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>>> No don't worry, helm will work in any cases, thanks.
>>
>> OK, in that case I'd prefer to keep it the way it is.
>
> Ok, fair enough.
>
>>>> Mainly to avoid issues with packages that might place files in the
>>>> configuration directory, which might hinder the reproduction of bugs.
>>>
>>> Hmm, maybe, I don't have an example in mind though.
>>
>> It might not be the best example, but my package autocrypt generates a
>> file in the `user-emacs-directory'. If we don't use --init-directory,
>> the existing file would be re-used.
>
> Ok, for such case it is easy to either rename the file temporarily to
> foo_ori or foo_save or to set the variable handling the file (generally
> it is not harcoded) to something else. But another issue is if your
> isolated package needs the history file or tramp file or whatever file
> ~/.emacs.d is handling; e.g. a package providing completion on history.
> I still think it is more handy to reuse user-emacs-directory and its
> elpa directory where the packages are already installed.
How about this patch, that will use a temporary directory when
`package-isolate' is invoked with a prefix argument (not sure what the
default should be, I guess reusing `user-emacs-directory' is less
surprising):
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Add-command-to-start-Emacs-with-specific-packages.patch --]
[-- Type: text/x-diff, Size: 6128 bytes --]
From dd5da3d2f64f89994084012a3b7379aa78ae33f2 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Tue, 15 Aug 2023 18:39:14 +0200
Subject: [PATCH] Add command to start Emacs with specific packages
* lisp/emacs-lisp/package.el (package--dependencies): Extend function
to handle and return package descriptors.
(package-isolate): Add new command.
* etc/NEWS: Announce new command.
---
etc/NEWS | 9 +++++
lisp/emacs-lisp/package.el | 77 +++++++++++++++++++++++++++++++++++---
2 files changed, 80 insertions(+), 6 deletions(-)
diff --git a/etc/NEWS b/etc/NEWS
index 57f04609679..dc213dcee42 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -505,6 +505,15 @@ project, that you can quickly select using 'project-switch-project'
When non-nil, package specifications with side-effects for building
software will be used when building a package.
+---
+*** New command to start an inferior Emacs loading only specific packages.
+The new command 'package-isolate' will start a new Emacs process, as
+a sub-process of Emacs where you invoke the command, in a way that
+causes the new process to load only some of the installed packages.
+The command prompts for the packages to activate in this
+sub-process, and is intended for testing Emacs and/or the packages
+in a clean environment.
+
** Flymake
+++
diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el
index b3062d2608b..169d0d1360d 100644
--- a/lisp/emacs-lisp/package.el
+++ b/lisp/emacs-lisp/package.el
@@ -2330,12 +2330,26 @@ package-upgrade-all
(mapc #'package-upgrade upgradeable))))
(defun package--dependencies (pkg)
- "Return a list of all dependencies PKG has.
-This is done recursively."
- ;; Can we have circular dependencies? Assume "nope".
- (when-let* ((desc (cadr (assq pkg package-archive-contents)))
- (deps (mapcar #'car (package-desc-reqs desc))))
- (delete-dups (apply #'nconc deps (mapcar #'package--dependencies deps)))))
+ "Return a list of all recursive dependencies of PKG.
+If PKG is a package descriptor, the return value will consist of
+a list of package descriptors. If PKG is a symbol, designating a
+package, the return value will be a list of symbols designating
+packages."
+ (when-let* ((desc (if (package-desc-p pkg) pkg
+ (cadr (assq pkg package-archive-contents)))))
+ ;; Can we have circular dependencies? Assume "nope".
+ (let ((all (named-let more ((pkg-desc desc))
+ (let (deps)
+ (dolist (req (package-desc-reqs pkg-desc))
+ (setq deps (nconc
+ (catch 'found
+ (dolist (p (apply #'append (mapcar #'cdr (package--alist))))
+ (when (and (string= (car req) (package-desc-name p))
+ (version-list-<= (cadr req) (package-desc-version p)))
+ (throw 'found (more p)))))
+ deps)))
+ (delete-dups (cons pkg-desc deps))))))
+ (remq pkg (mapcar (if (package-desc-p pkg) #'identity #'package-desc-name) all)))))
(defun package-strip-rcs-id (str)
"Strip RCS version ID from the version string STR.
@@ -2625,6 +2639,57 @@ package-autoremove
removable))
(message "Nothing to autoremove")))))
+(defun package-isolate (packages &optional temp-init)
+ "Start an uncustomised Emacs and only load a set of PACKAGES.
+If TEMP-INIT is non-nil, or when invoked with a prefix argument,
+the Emacs user directory is set to a temporary directory."
+ (interactive
+ (cl-loop for p in (cl-loop for p in (package--alist) append (cdr p))
+ unless (package-built-in-p p)
+ collect (cons (package-desc-full-name p) p) into table
+ finally return
+ (list (cl-loop for c in (completing-read-multiple
+ "Isolate packages: " table
+ nil t)
+ collect (alist-get c table nil nil #'string=))
+ current-prefix-arg)))
+ (let* ((name (concat "package-isolate-"
+ (mapconcat #'package-desc-full-name packages ",")))
+ (all-packages (delete-consecutive-dups
+ (sort (append packages (mapcan #'package--dependencies packages))
+ (lambda (p0 p1)
+ (string< (package-desc-name p0) (package-desc-name p1))))))
+ initial-scratch-message package-load-list)
+ (with-temp-buffer
+ (insert ";; This is an isolated testing environment, with these packages enabled:\n\n")
+ (dolist (package all-packages)
+ (push (list (package-desc-name package)
+ (package-version-join (package-desc-version package)))
+ package-load-list)
+ (insert ";; - " (package-desc-full-name package))
+ (unless (memq package packages)
+ (insert " (dependency)"))
+ (insert "\n"))
+ (insert "\n")
+ (setq initial-scratch-message (buffer-string)))
+ (apply #'start-process (concat "*" name "*") nil
+ (list (expand-file-name invocation-name invocation-directory)
+ "--quick" "--debug-init"
+ "--init-directory" (if temp-init
+ (make-temp-file name t)
+ user-emacs-directory)
+ (format "--eval=%S"
+ `(progn
+ (setq initial-scratch-message ,initial-scratch-message)
+
+ (require 'package)
+ ,@(mapcar
+ (lambda (dir)
+ `(add-to-list 'package-directory-list ,dir))
+ (cons package-user-dir package-directory-list))
+ (setq package-load-list ',package-load-list)
+ (package-initialize)))))))
+
\f
;;;; Package description buffer.
--
2.39.2
^ permalink raw reply related [relevance 49%]
* Re: master 5892b4db8de 2/3: Convert dictionary-mode to define-derived-mode
@ 2023-08-16 22:33 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-08-16 22:33 UTC (permalink / raw)
To: Visuwesh; +Cc: emacs-devel, Stefan Kangas
Visuwesh <visuweshm@gmail.com> writes:
> [சனி ஆகஸ்ட் 12, 2023] Stefan Kangas wrote:
>
>> branch: master
>> commit 5892b4db8de4694904f631dd86438926fb9d7ff1
>> Author: Stefan Kangas <stefankangas@gmail.com>
>> Commit: Stefan Kangas <stefankangas@gmail.com>
>>
>> Convert dictionary-mode to define-derived-mode
>>
>> * lisp/net/dictionary.el (dictionary-instances): Delete.
>> (dictionary-mode): Use define-derived-mode.
>> (dictionary--count-mode-buffers): New function.
>> (dictionary-close): Use above new function.
>
>> +(defun dictionary--count-mode-buffers ()
>> + "Return the number of buffers that "
>
> The docstring is incomplete here. :-(
>
>> + (seq-reduce #'+
>> + (mapcar
>> + (lambda (buf)
>> + (with-current-buffer buf
>> + (if (derived-mode-p 'dictionary-mode) 1 0)))
>> + (buffer-list))
>> + 0))
>> +
>
> I believe the following function should be faster
>
> (defun dictionary--count-mode-buffers ()
> "Return the number of buffers that "
> (seq-reduce (lambda (count buf)
> (if (provided-mode-derived-p (buffer-local-value 'major-mode buf)
> 'dictionary-mode)
> (+ count 1)
> count))
> (buffer-list)
> 0))
Alternatively (length (match-buffers '(derived-mode . dictionary-mode)))
^ permalink raw reply [relevance 99%]
* Re: Proposal for 'package-isolate' command
@ 2023-08-16 19:00 52% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-08-16 19:00 UTC (permalink / raw)
To: Stefan Kangas; +Cc: Thierry Volpiatto, emacs-devel
[-- Attachment #1: Type: text/plain, Size: 339 bytes --]
Stefan Kangas <stefankangas@gmail.com> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> I guess this is too controversial. Perhaps just adjusting
>> `frame-title-format' would be enough.
>
> Would it be controversial to print a message in the scratch buffer?
That is also a good idea, this patch integrates that approach:
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Add-command-to-start-Emacs-with-specific-packages.patch --]
[-- Type: text/x-diff, Size: 5673 bytes --]
From ecc6b37a2a1cb9b3629521fc92b2d9af5c5ea653 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Tue, 15 Aug 2023 18:39:14 +0200
Subject: [PATCH] Add command to start Emacs with specific packages
* lisp/emacs-lisp/package.el (package--dependencies): Extend function
to handle and return package descriptors.
(package-isolate): Add new command.
* etc/NEWS: Announce new command.
---
etc/NEWS | 9 +++++
lisp/emacs-lisp/package.el | 70 ++++++++++++++++++++++++++++++++++----
2 files changed, 73 insertions(+), 6 deletions(-)
diff --git a/etc/NEWS b/etc/NEWS
index 57f04609679..dc213dcee42 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -505,6 +505,15 @@ project, that you can quickly select using 'project-switch-project'
When non-nil, package specifications with side-effects for building
software will be used when building a package.
+---
+*** New command to start an inferior Emacs loading only specific packages.
+The new command 'package-isolate' will start a new Emacs process, as
+a sub-process of Emacs where you invoke the command, in a way that
+causes the new process to load only some of the installed packages.
+The command prompts for the packages to activate in this
+sub-process, and is intended for testing Emacs and/or the packages
+in a clean environment.
+
** Flymake
+++
diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el
index b3062d2608b..76cd39cc263 100644
--- a/lisp/emacs-lisp/package.el
+++ b/lisp/emacs-lisp/package.el
@@ -2330,12 +2330,26 @@ package-upgrade-all
(mapc #'package-upgrade upgradeable))))
(defun package--dependencies (pkg)
- "Return a list of all dependencies PKG has.
-This is done recursively."
- ;; Can we have circular dependencies? Assume "nope".
- (when-let* ((desc (cadr (assq pkg package-archive-contents)))
- (deps (mapcar #'car (package-desc-reqs desc))))
- (delete-dups (apply #'nconc deps (mapcar #'package--dependencies deps)))))
+ "Return a list of all recursive dependencies of PKG.
+If PKG is a package descriptor, the return value will consist of
+a list of package descriptors. If PKG is a symbol, designating a
+package, the return value will be a list of symbols designating
+packages."
+ (when-let* ((desc (if (package-desc-p pkg) pkg
+ (cadr (assq pkg package-archive-contents)))))
+ ;; Can we have circular dependencies? Assume "nope".
+ (let ((all (named-let more ((pkg-desc desc))
+ (let (deps)
+ (dolist (req (package-desc-reqs pkg-desc))
+ (setq deps (nconc
+ (catch 'found
+ (dolist (p (apply #'append (mapcar #'cdr (package--alist))))
+ (when (and (string= (car req) (package-desc-name p))
+ (version-list-<= (cadr req) (package-desc-version p)))
+ (throw 'found (more p)))))
+ deps)))
+ (delete-dups (cons pkg-desc deps))))))
+ (remq pkg (mapcar (if (package-desc-p pkg) #'identity #'package-desc-name) all)))))
(defun package-strip-rcs-id (str)
"Strip RCS version ID from the version string STR.
@@ -2625,6 +2639,50 @@ package-autoremove
removable))
(message "Nothing to autoremove")))))
+(defun package-isolate (packages)
+ "Start an uncustomised Emacs and only load a set of PACKAGES."
+ (interactive
+ (cl-loop for p in (cl-loop for p in (package--alist) append (cdr p))
+ unless (package-built-in-p p)
+ collect (cons (package-desc-full-name p) p) into table
+ finally return
+ (list (cl-loop for c in (completing-read-multiple
+ "Isolate packages: " table
+ nil t)
+ collect (alist-get c table nil nil #'string=)))))
+ (let* ((name (concat "package-isolate-"
+ (mapconcat #'package-desc-full-name packages ",")))
+ initial-scratch-message package-load-list)
+ (with-temp-buffer
+ (insert ";; Emacs has been started by `package-isolate' without any configuration, and\n"
+ ";; only the following packages have been loaded:\n;;\n")
+
+ (dolist (package (append packages (mapcan #'package--dependencies packages)))
+ (push (list (package-desc-name package)
+ (package-version-join (package-desc-version package)))
+ package-load-list)
+ (insert ";; - " (package-desc-full-name package))
+ (unless (memq package packages)
+ (insert " (dependency)"))
+ (insert "\n"))
+ (insert "\n")
+ (setq initial-scratch-message (buffer-string)))
+ (apply #'start-process (concat "*" name "*") nil
+ (list (expand-file-name invocation-name invocation-directory)
+ "--quick" "--debug-init"
+ "--init-directory" (make-temp-file name t)
+ (format "--eval=%S"
+ `(progn
+ (setq initial-scratch-message ,initial-scratch-message)
+
+ (require 'package)
+ ,@(mapcar
+ (lambda (dir)
+ `(add-to-list 'package-directory-list ,dir))
+ (cons package-user-dir package-directory-list))
+ (setq package-load-list ',package-load-list)
+ (package-initialize)))))))
+
\f
;;;; Package description buffer.
--
2.39.2
^ permalink raw reply related [relevance 52%]
* Re: Changes to make in elpa-packages file for nongnu elpa
@ 2023-08-16 18:52 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-08-16 18:52 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: thievol, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: emacs-devel@gnu.org
>> Date: Wed, 16 Aug 2023 10:10:46 +0000
>>
>> +---
>> +*** New command to start Emacs only with specific packages
>> +The command 'package-isolate' is equivalent to starting Emacs with the
>> +-Q flag and loading specific packages (and their dependencies)
>> +manually.
>
> If this is how this feature is going to be implemented, I suggest to
> reword this NEWS entry to make the intent and the feature easier to
> understand:
>
> *** New command to start an inferior Emacs loading only specific packages.
> The new command 'package-isolate' will start a new Emacs process, as
> a sub-process of Emacs where you invoke the command, in a way that
> causes the new process to load only some of the installed packages.
> The command prompts for the packages to activate in this
> sub-process, and is intended for testing Emacs and/or the packages
> in a clean environment.
As usual, I prefer your phrasing. Will update the patch.
^ permalink raw reply [relevance 99%]
* Re: Proposal for 'package-isolate' command
@ 2023-08-16 18:48 90% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-08-16 18:48 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: thievol, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: thievol@posteo.net, emacs-devel@gnu.org
>> Date: Tue, 15 Aug 2023 19:52:32 +0000
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> > Seems strange to me to have a command to start another Emacs. Why not
>> > implement this as a command-line option instead? That would be
>> > consistent with the several options we already have, like -q, -Q, -D,
>> > which already contrl what happens at startup.
>>
>> Mainly because this wouldn't support a completing-read interface, that
>> simplifies prompting the user for a set of packages.
>
> Shells can complete as well, right? And once you typed the command
> once, shells have features to help you invoke commands from history,
> so you won't need to retype it more than once.
Each shell requires individual completion support, and figuring out what
packages are installed outside of Emacs to ensure input like
"magit-3.3.0,corfu-0.37" is well formed, seems too much work to me.
What would be reasonable, might be a function that could be invoked from
batch mode.
emacs -Q --batch -f package-isolate-batch magit corfu
>> But perhaps the bulk of this command could be implemented as a CLI
>> option, that this command could wrap?
>
> Maybe. But again, it's strange to have to launch another process from
> Emacs for such a simple functionality. And if the number of packages
> to load is large, typing them manually would be annoying anyway, so
> people will probably store the list in a file or something? So maybe
> we should allow specifying a file with the list of packages as well?
I don't know how this package would be used, but the way I imagine it is
that a package maintainer asks the user to run
M-x package-isolate RET foo-1.2.3 RET
with only a few packages, to make the reproduction of bugs easier, as
is the case with Helm, which is what prompted this tangent.
>> >> + (make-symbolic-link real link t)
>> >
>> > Using symbolic links makes the program less portable, so it is best to
>> > avoid them.
>>
>> The reason I used them here, instead of just adding the directories
>> under ~/.config/emacs/elpa/ is that startup.el issues a warning along
>> the lines of
>>
>> Your `load-path' seems to contain your `user-emacs-directory' ...
>>
>> My previous patch actually included the code that suppresses all
>> warnings during initialisation, so I've removed this hack.
>
> I don't understand how this is different from a "normal" startup of
> Emacs with all the packages. Here, you just want to load part of the
> packages that are loaded normally, so why does this warning pop up in
> this case, but not when Emacs starts "normally"? I'm probably missing
> something.
The point is moot anyway, since the approach that Thierry proposed
circumvents the issue to begin with.
^ permalink raw reply [relevance 90%]
* Proposal for 'package-isolate' command
@ 2023-08-16 18:34 88% ` Philip Kaludercic
0 siblings, 2 replies; 200+ results
From: Philip Kaludercic @ 2023-08-16 18:34 UTC (permalink / raw)
To: Thierry Volpiatto; +Cc: emacs-devel
Thierry Volpiatto <thievol@posteo.net> writes:
>>>> I don't know much about Helm, but does it not support CRM?
>>>
>>> It does, but this is a much better interface than CRM.
>>
>> I don't think it makes sense to add support like this in the core,
>
> Perhaps yes. However it doesn't requires helm:
>
> (let ((helm-comp-read-use-marked t))
> (if (and (boundp 'helm-mode) helm-mode)
> (completing-read ...)
> (completing-read-multiple ...)
>
>> but is there something we should keep in mind to not hinder
>> integration with Helm?
>
> No don't worry, helm will work in any cases, thanks.
OK, in that case I'd prefer to keep it the way it is.
[...]
>>>>> (let* ((name (concat "package-isolate-" (mapconcat #'identity
>>>>> packages ",")))
>>>>
>>>> This doesn't work, because the above returns a string, not a list of strings.
>>>
>>> No, it works, the above returns a list of strings (the completing-read
>>> allows marking and returns always a list).
>>
>> Not in my case, I got a type error.
>
> Yes, because the let-bounded var had no effect in your case, otherwise
> when helm is installed and helm-mode enabled the completing-read will
> always return a list.
Right, but that is the issue here, because using completing-read,
especially in the core, shouldn't make any assumptions like that. In
the end this boils down to the fact that completing-read and co. are a
over-burned interface...
[...]
>>>> It seems to me, that for a proper isolated environment, we should add
>>>> a --init-directory option.
>>>
>>> Why as long as other directories in elpa are not in load-path?
>>
>> Mainly to avoid issues with packages that might place files in the
>> configuration directory, which might hinder the reproduction of bugs.
>
> Hmm, maybe, I don't have an example in mind though.
It might not be the best example, but my package autocrypt generates a
file in the `user-emacs-directory'. If we don't use --init-directory,
the existing file would be re-used.
>> Upon reflection, my approach might have an issue if the user wishes to
>> install a package, for the sake of testing within the isolated
>> environment.
>
> Yes, one more reason to use the original elpa dir ;-)
No, because in that case the package installed in the temporary
environment would be retained in the original elpa/ directory, which I
think we /don't/ want.
>> Perhaps it would be better to set `package-directory-list' instead?
>
> Don't know yet.
Even better, I have added all directories that
`package-load-all-descriptors' would load to `package-directory-list',
which should be more robust.
>> Also, would it make sense to have some visual/textual indication that
>> this is a testing environment? Perhaps the *scratch* buffer string
>> could be modified or the default background colour could be set to
>> something else.
>
> No particular opinions about this.
I guess this is too controversial. Perhaps just adjusting
`frame-title-format' would be enough.
[...]
^ permalink raw reply [relevance 88%]
* Re: Changes to make in elpa-packages file for nongnu elpa
@ 2023-08-16 11:03 85% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-08-16 11:03 UTC (permalink / raw)
To: Thierry Volpiatto; +Cc: emacs-devel
Thierry Volpiatto <thievol@posteo.net> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Thierry Volpiatto <thievol@posteo.net> writes:
>>
>>> Philip Kaludercic <philipk@posteo.net> writes:
>>>
>>>> Philip Kaludercic <philipk@posteo.net> writes:
>>>>
>>>>>>>> It is used specially for reproducing bugs in a clean environment, see it
>>>>>>>> as emacs -Q for Emacs when reporting bugs. This script starts Emacs -Q
>>>>>>>> with only Helm loaded, this ensure the bug if one comes from Helm and
>>>>>>>> not another package. This is important especially nowaday people are
>>>>>>>> using "Emacs distribution" with the world list of packages installed.
>>>>>>>> Apart that the script is useful to quickly launch Emacs with helm, one
>>>>>>>> can use it from the Helm directory or symlinked to e.g. ~/bin.
>>>>>>>
>>>>>>> I see. In that case is there any reason you implement this as a shell
>>>>>>> script?
>>>>>>
>>>>>> Well when I wrote the script, packages where not existing and from
>>>>>> outside emacs it is actually the only way to run a package isolated.
>>>>>>
>>>>>>> (It might be interesting to provide something like this for
>>>>>>> package.el, to test packages in a generic way.)
>>>>>>
>>>>>> Yes, this would be interesting, it would be something like this:
>>>>>>
>>>>>> Emacs -Q
>>>>>> M-x <A command that run a package alone, isolated from other
>>>>>> packages nuisances>
>>>>>
>>>>> I was actually thinking of a command like
>>>>>
>>>>> M-x package-isolate RET foo,bar,baz RET
>>>>>
>>>>> and a new instance of Emacs using -Q is spun up, with all the packages
>>>>> you have listed loaded, and nothing else... Sounds like a fun little
>>>>> weekend project ;^)
>>>>
>>>> Here is my first attempt at providing this kind of a command. Any
>>>> comments?
>>>
>>> Why not reusing package.el functions?
>>> Why do you want to start in an isolated elpa directory?
>>> Isn't something like this suffice? (just missing to fallback to CRM when
>>> helm is not available)
>>
>> I don't know much about Helm, but does it not support CRM?
>
> It does, but this is a much better interface than CRM.
I don't think it makes sense to add support like this in the core, but
is there something we should keep in mind to not hinder integration with
Helm?
>>> (defun package-isolate (packages)
>>> "Start an uncustomised Emacs and only load a set of PACKAGES."
>>> (interactive
>>> (list (let ((helm-comp-read-use-marked t))
>>> (completing-read "Packages: " (mapcar #'car (package--alist))))))
>>
>> This doesn't allow selecting specific package versions, in case multiple
>> are installed (which might easily happen if you use package-vc). I
>> stole the code in my patch from package-delete, and I guess it would be
>> possible to generalise it into a utility function.
>
> Ok, I don't know much how package-vc works.
I can have a classical tarball package installed next to a VC package,
just like you can have a built-in package or a system package, and it
makes sense to be able to decide which one to isolate.
>>> (let* ((name (concat "package-isolate-" (mapconcat #'identity
>>> packages ",")))
>>
>> This doesn't work, because the above returns a string, not a list of strings.
>
> No, it works, the above returns a list of strings (the completing-read
> allows marking and returns always a list).
Not in my case, I got a type error.
>>> (deps (cl-loop for p in packages
>>> for sym = (intern p)
>>> append (package--dependencies sym))))
>>> (apply #'start-process (concat "*" name "*") nil
>>> (list (file-truename (expand-file-name invocation-name invocation-directory))
>>> "--quick" "--debug-init"
>>> (format "--eval=%S"
>>> `(progn
>>> (require 'warnings)
>>> (add-to-list 'warning-suppress-log-types 'initialization)
>>> (require 'package)
>>> (setq package-load-list
>>> ',(append (mapcar (lambda (p) (list (intern p) t)) packages)
>>> (mapcar (lambda (p) (list p t)) deps)))
>>> (package-initialize)))))))
>>
>> This is actually a good idea, assuming there are no issues with lexical
>> scoping that might arise from --eval. I didn't think of using
>> package-load-list here, but it seems that this only works if we don't
>> add --init-directory, because otherwise the elpa/ directory is not
>> populated.
>
> Yes of course.
>
>> It seems to me, that for a proper isolated environment, we should add
>> a --init-directory option.
>
> Why as long as other directories in elpa are not in load-path?
Mainly to avoid issues with packages that might place files in the
configuration directory, which might hinder the reproduction of bugs.
Upon reflection, my approach might have an issue if the user wishes to
install a package, for the sake of testing within the isolated
environment. Perhaps it would be better to set `package-directory-list'
instead?
Also, would it make sense to have some visual/textual indication that
this is a testing environment? Perhaps the *scratch* buffer string
could be modified or the default background colour could be set to
something else.
>> This is easy to fix though, we just need to specify `package-user-dir'
>> at startup. Here is my updated patch, merging our approaches:
>>
>> [2. text/x-diff;
>> 0001-Add-command-to-start-Emacs-with-specific-packages.patch]...
>>
>>
>>>> [2. text/x-diff;
>>>> 0002-Add-command-to-start-Emacs-with-specific-packages.patch]...
>>>>
>>>> [3. text/x-diff; 0001-Add-a-function-to-query-the-Emacs-executable.patch]...
>>
>> I have slightly modified your version, fixing issues I had, in case
>> anyone else wants to try it out:
>
> Thanks, sorry to not provide the CRM, I quickly wrote this.
np.
>> (defun package-isolate (packages)
>> "Start an uncustomised Emacs and only load a set of PACKAGES."
>> (interactive
>> (list (mapcar #'intern (completing-read-multiple "Packages: " (mapcar #'car (package--alist))))))
>> (let* ((name (concat "package-isolate-" (mapconcat #'symbol-name packages ",")))
>> (deps (mapcan #'package--dependencies packages)))
>> (apply #'start-process (concat "*" name "*") nil
>> (list (file-truename (expand-file-name invocation-name invocation-directory))
>> "--quick" "--debug-init"
>> (format "--eval=%S"
>> `(progn
>> (require 'warnings)
>> (add-to-list 'warning-suppress-log-types 'initialization)
>> (require 'package)
>> (setq package-load-list
>> ',(mapcar (lambda (p) (list p t)) (append packages deps)))
>> (package-initialize)))))))
^ permalink raw reply [relevance 85%]
* Re: Changes to make in elpa-packages file for nongnu elpa
@ 2023-08-16 10:10 46% ` Philip Kaludercic
0 siblings, 2 replies; 200+ results
From: Philip Kaludercic @ 2023-08-16 10:10 UTC (permalink / raw)
To: Thierry Volpiatto; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 4087 bytes --]
Thierry Volpiatto <thievol@posteo.net> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Philip Kaludercic <philipk@posteo.net> writes:
>>
>>>>>> It is used specially for reproducing bugs in a clean environment, see it
>>>>>> as emacs -Q for Emacs when reporting bugs. This script starts Emacs -Q
>>>>>> with only Helm loaded, this ensure the bug if one comes from Helm and
>>>>>> not another package. This is important especially nowaday people are
>>>>>> using "Emacs distribution" with the world list of packages installed.
>>>>>> Apart that the script is useful to quickly launch Emacs with helm, one
>>>>>> can use it from the Helm directory or symlinked to e.g. ~/bin.
>>>>>
>>>>> I see. In that case is there any reason you implement this as a shell
>>>>> script?
>>>>
>>>> Well when I wrote the script, packages where not existing and from
>>>> outside emacs it is actually the only way to run a package isolated.
>>>>
>>>>> (It might be interesting to provide something like this for
>>>>> package.el, to test packages in a generic way.)
>>>>
>>>> Yes, this would be interesting, it would be something like this:
>>>>
>>>> Emacs -Q
>>>> M-x <A command that run a package alone, isolated from other
>>>> packages nuisances>
>>>
>>> I was actually thinking of a command like
>>>
>>> M-x package-isolate RET foo,bar,baz RET
>>>
>>> and a new instance of Emacs using -Q is spun up, with all the packages
>>> you have listed loaded, and nothing else... Sounds like a fun little
>>> weekend project ;^)
>>
>> Here is my first attempt at providing this kind of a command. Any
>> comments?
>
> Why not reusing package.el functions?
> Why do you want to start in an isolated elpa directory?
> Isn't something like this suffice? (just missing to fallback to CRM when
> helm is not available)
I don't know much about Helm, but does it not support CRM?
> (defun package-isolate (packages)
> "Start an uncustomised Emacs and only load a set of PACKAGES."
> (interactive
> (list (let ((helm-comp-read-use-marked t))
> (completing-read "Packages: " (mapcar #'car (package--alist))))))
This doesn't allow selecting specific package versions, in case multiple
are installed (which might easily happen if you use package-vc). I
stole the code in my patch from package-delete, and I guess it would be
possible to generalise it into a utility function.
> (let* ((name (concat "package-isolate-" (mapconcat #'identity
> packages ",")))
This doesn't work, because the above returns a string, not a list of strings.
> (deps (cl-loop for p in packages
> for sym = (intern p)
> append (package--dependencies sym))))
> (apply #'start-process (concat "*" name "*") nil
> (list (file-truename (expand-file-name invocation-name invocation-directory))
> "--quick" "--debug-init"
> (format "--eval=%S"
> `(progn
> (require 'warnings)
> (add-to-list 'warning-suppress-log-types 'initialization)
> (require 'package)
> (setq package-load-list
> ',(append (mapcar (lambda (p) (list (intern p) t)) packages)
> (mapcar (lambda (p) (list p t)) deps)))
> (package-initialize)))))))
This is actually a good idea, assuming there are no issues with lexical
scoping that might arise from --eval. I didn't think of using
package-load-list here, but it seems that this only works if we don't
add --init-directory, because otherwise the elpa/ directory is not
populated. It seems to me, that for a proper isolated environment, we
should add a --init-directory option. This is easy to fix though, we
just need to specify `package-user-dir' at startup. Here is my updated
patch, merging our approaches:
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Add-command-to-start-Emacs-with-specific-packages.patch --]
[-- Type: text/x-diff, Size: 4878 bytes --]
From 6ae48d6d28112d487ea09ca905814da47c2a26cf Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Tue, 15 Aug 2023 18:39:14 +0200
Subject: [PATCH] Add command to start Emacs with specific packages
* lisp/emacs-lisp/package.el (package--dependencies): Extend function
to handle and return package descriptors.
(package-isolate): Add new command.
* etc/NEWS: Announce new command.
---
etc/NEWS | 6 ++++
lisp/emacs-lisp/package.el | 57 ++++++++++++++++++++++++++++++++++----
2 files changed, 57 insertions(+), 6 deletions(-)
diff --git a/etc/NEWS b/etc/NEWS
index 57f04609679..c374695a571 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -505,6 +505,12 @@ project, that you can quickly select using 'project-switch-project'
When non-nil, package specifications with side-effects for building
software will be used when building a package.
+---
+*** New command to start Emacs only with specific packages
+The command 'package-isolate' is equivalent to starting Emacs with the
+-Q flag and loading specific packages (and their dependencies)
+manually.
+
** Flymake
+++
diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el
index b3062d2608b..9e969ce1024 100644
--- a/lisp/emacs-lisp/package.el
+++ b/lisp/emacs-lisp/package.el
@@ -2330,12 +2330,26 @@ package-upgrade-all
(mapc #'package-upgrade upgradeable))))
(defun package--dependencies (pkg)
- "Return a list of all dependencies PKG has.
-This is done recursively."
- ;; Can we have circular dependencies? Assume "nope".
- (when-let* ((desc (cadr (assq pkg package-archive-contents)))
- (deps (mapcar #'car (package-desc-reqs desc))))
- (delete-dups (apply #'nconc deps (mapcar #'package--dependencies deps)))))
+ "Return a list of all recursive dependencies of PKG.
+If PKG is a package descriptor, the return value will consist of
+a list of package descriptors. If PKG is a symbol, designating a
+package, the return value will be a list of symbols designating
+packages."
+ (when-let* ((desc (if (package-desc-p pkg) pkg
+ (cadr (assq pkg package-archive-contents)))))
+ ;; Can we have circular dependencies? Assume "nope".
+ (let ((all (named-let more ((pkg-desc desc))
+ (let (deps)
+ (dolist (req (package-desc-reqs pkg-desc))
+ (setq deps (nconc
+ (catch 'found
+ (dolist (p (apply #'append (mapcar #'cdr (package--alist))))
+ (when (and (string= (car req) (package-desc-name p))
+ (version-list-<= (cadr req) (package-desc-version p)))
+ (throw 'found (more p)))))
+ deps)))
+ (delete-dups (cons pkg-desc deps))))))
+ (remq pkg (mapcar (if (package-desc-p pkg) #'identity #'package-desc-name) all)))))
(defun package-strip-rcs-id (str)
"Strip RCS version ID from the version string STR.
@@ -2625,6 +2639,37 @@ package-autoremove
removable))
(message "Nothing to autoremove")))))
+(defun package-isolate (packages)
+ "Start an uncustomised Emacs and only load a set of PACKAGES."
+ (interactive
+ (cl-loop for p in (cl-loop for p in (package--alist) append (cdr p))
+ unless (package-built-in-p p)
+ collect (cons (package-desc-full-name p) p) into table
+ finally return
+ (list (cl-loop for c in (completing-read-multiple
+ "Isolate packages: " table
+ nil t)
+ collect (alist-get c table nil nil #'string=)))))
+ (let* ((name (concat "package-isolate-"
+ (mapconcat #'package-desc-full-name packages ",")))
+ package-load-list)
+ (dolist (package (append packages (mapcan #'package--dependencies packages)))
+ (push (list (package-desc-name package)
+ (package-version-join (package-desc-version package)))
+ package-load-list))
+ (apply #'start-process (concat "*" name "*") nil
+ (list (expand-file-name invocation-name invocation-directory)
+ "--quick" "--debug-init"
+ "--init-directory" (make-temp-file name t)
+ (format "--eval=%S"
+ `(progn
+ (require 'warnings)
+ (add-to-list 'warning-suppress-log-types 'initialization)
+ (require 'package)
+ (setq package-user-dir ,(expand-file-name package-user-dir)
+ package-load-list ',package-load-list)
+ (package-initialize)))))))
+
\f
;;;; Package description buffer.
--
2.39.2
[-- Attachment #3: Type: text/plain, Size: 1400 bytes --]
>> [2. text/x-diff; 0002-Add-command-to-start-Emacs-with-specific-packages.patch]...
>>
>> [3. text/x-diff; 0001-Add-a-function-to-query-the-Emacs-executable.patch]...
I have slightly modified your version, fixing issues I had, in case
anyone else wants to try it out:
(defun package-isolate (packages)
"Start an uncustomised Emacs and only load a set of PACKAGES."
(interactive
(list (mapcar #'intern (completing-read-multiple "Packages: " (mapcar #'car (package--alist))))))
(let* ((name (concat "package-isolate-" (mapconcat #'symbol-name packages ",")))
(deps (mapcan #'package--dependencies packages)))
(apply #'start-process (concat "*" name "*") nil
(list (file-truename (expand-file-name invocation-name invocation-directory))
"--quick" "--debug-init"
(format "--eval=%S"
`(progn
(require 'warnings)
(add-to-list 'warning-suppress-log-types 'initialization)
(require 'package)
(setq package-load-list
',(mapcar (lambda (p) (list p t)) (append packages deps)))
(package-initialize)))))))
^ permalink raw reply related [relevance 46%]
* Re: [ELPA] New Package: phpinspect.el
@ 2023-08-15 21:56 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-08-15 21:56 UTC (permalink / raw)
To: Hugo Thunnissen; +Cc: Stefan Monnier, emacs-devel
Hugo Thunnissen <devel@hugot.nl> writes:
> On 8/15/23 22:28, Philip Kaludercic wrote:
>>
>> I am not familiar with Cask, what does this provide over a simple
>> Makefile?
>
>
> It locally installs the package's dependencies and starts emacs with a
> clean profile that only has those dependencies available. It doesn't
> do much, but it's easy to use and it seems to help prevent "it works
> with my setup" scenarios. I only started using it recently though so
> I'm not very familiar with it, nor am I very skilled with make for
> that matter ;)
>
> What would a simple Makefile for a typical elisp package look like? Is
> it common practice to create clean environments like cask does?
This article goes into it https://nullprogram.com/blog/2020/01/22/,
though I understand now that it doesn't do the same thing (or at least
you would have to manually implement something like creating a clean
environment or installing dependencies).
^ permalink raw reply [relevance 99%]
* Re: [ELPA] New Package: phpinspect.el
@ 2023-08-15 20:28 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-08-15 20:28 UTC (permalink / raw)
To: Hugo Thunnissen; +Cc: Stefan Monnier, emacs-devel
Hugo Thunnissen <devel@hugot.nl> writes:
> On 8/12/23 06:56, Stefan Monnier wrote:
>>> I would like to propose my package, phpinspect.el, to be added to GNU Elpa.
>> Done.
>>
>> AFAICT the code has currently some significant problems in terms of
>> dependencies which make its compilation fail because variables are used
>> by macros during compilation when the var has not yet been defined, or
>> macros are used before they're defined, etc...
>>
>> The patch below seems to make the compilation go through (and fixes
>> various warnings), but there are a lot of compilation warnings left
>> which you might want to check. It also includes a few FIXMEs.
>>
>>
>> Stefan
>>
>>
>
> And here I was thinking that I had fixed all of the byte compilation
> problems.. Turns out it was only working because I byte compiled
> everything within the same emacs session. I made some changes and
> think things should be in order now. At least, the following shell
> script doesn't seem to result in any errors:
>
> for file in ./*.el; do
> cask emacs -batch -L . --eval '(setq byte-compile-error-on-warn
> t)' -f batch-byte-compile "$file" || break
> done
I am not familiar with Cask, what does this provide over a simple
Makefile?
> I see some warnings in your log that concern files in the "benchmark"
> and "test" directories. These files are not required for the package
> to function. Can these be excluded from the ELPA build somehow? I have
> seen some projects use a "lisp" directory for their source code, is
> that the recommended approach for this?
You can add an .elpaignore file to your package root. You can list all
files in there that you do not with to have added to a package tarball.
The file is passed to GNU tar's -X option (see (info "(tar) exclude")).
> Thanks,
>
> - Hugo
^ permalink raw reply [relevance 99%]
* Proposal for 'package-isolate' command
@ 2023-08-15 19:52 57% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-08-15 19:52 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: thievol, emacs-devel
[-- Attachment #1: Type: text/plain, Size: 2305 bytes --]
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: emacs-devel@gnu.org
>> Date: Tue, 15 Aug 2023 16:55:03 +0000
>>
>> +*** New command to start Emacs only with specific packages
>> +The command 'package-isolate' is equivalent to starting Emacs with the
>> +-Q flag and loading specific packages (and their dependencies)
>> +manually.
>
> Seems strange to me to have a command to start another Emacs. Why not
> implement this as a command-line option instead? That would be
> consistent with the several options we already have, like -q, -Q, -D,
> which already contrl what happens at startup.
Mainly because this wouldn't support a completing-read interface, that
simplifies prompting the user for a set of packages.
But perhaps the bulk of this command could be implemented as a CLI
option, that this command could wrap?
>> + (let* ((real (package-desc-dir package))
>> + (link (expand-file-name (file-name-nondirectory real) elpa)))
>> + (make-symbolic-link real link t)
>
> Using symbolic links makes the program less portable, so it is best to
> avoid them.
The reason I used them here, instead of just adding the directories
under ~/.config/emacs/elpa/ is that startup.el issues a warning along
the lines of
Your `load-path' seems to contain your `user-emacs-directory' ...
My previous patch actually included the code that suppresses all
warnings during initialisation, so I've removed this hack.
>> + (apply #'start-process (concat "*" name "*") nil
>> + (append (list (or (emacs-executable) "emacs")
>
> I don't think it's a good idea to invoke just "emacs", it could be a
> completely different version of Emacs.
>
>> +DEFUN ("emacs-executable", Femacs_executable, Semacs_executable, 0, 0, "",
>> + doc: /* Return a string with the file name of the Emacs executable.
>> +If this is not known, nil will be returned instead. */)
>> + (void)
>
> I don't understand why you need this primitive. What's wrong with the
> usual paradigm we use everywhere else:
>
> (expand-file-name invocation-name invocation-directory)
Because I failed to remember it. This also appears to not have the risk
of returning nil, as my proposed command could have. I've applies these
and related changes below:
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Add-command-to-start-Emacs-with-specific-packages.patch --]
[-- Type: text/x-diff, Size: 3999 bytes --]
From 47dde2be5732ec9dfa153813649e385e0227751e Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Tue, 15 Aug 2023 18:39:14 +0200
Subject: [PATCH] Add command to start Emacs with specific packages
* lisp/emacs-lisp/package.el (package-isolate): Add command.
* etc/NEWS: Announce it.
---
etc/NEWS | 6 +++++
lisp/emacs-lisp/package.el | 47 ++++++++++++++++++++++++++++++++++++++
2 files changed, 53 insertions(+)
diff --git a/etc/NEWS b/etc/NEWS
index 57f04609679..c374695a571 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -505,6 +505,12 @@ project, that you can quickly select using 'project-switch-project'
When non-nil, package specifications with side-effects for building
software will be used when building a package.
+---
+*** New command to start Emacs only with specific packages
+The command 'package-isolate' is equivalent to starting Emacs with the
+-Q flag and loading specific packages (and their dependencies)
+manually.
+
** Flymake
+++
diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el
index b3062d2608b..838b2823466 100644
--- a/lisp/emacs-lisp/package.el
+++ b/lisp/emacs-lisp/package.el
@@ -2625,6 +2625,53 @@ package-autoremove
removable))
(message "Nothing to autoremove")))))
+(defun package-isolate (packages)
+ "Start an uncustomised Emacs and only load a set of PACKAGES."
+ (interactive
+ (cl-loop for p in (cl-loop for p in (package--alist) append (cdr p))
+ unless (package-built-in-p p)
+ collect (cons (package-desc-full-name p) p) into table
+ finally return
+ (list (cl-loop for c in (completing-read-multiple
+ "Isolate packages: " table
+ nil t)
+ collect (alist-get c table nil nil #'string=)))))
+ (cl-assert (cl-every #'package-desc-p packages))
+ (let* ((name (concat "package-isolate-" (mapconcat #'package-desc-full-name
+ packages ",")))
+ (tmp-init (make-temp-file name t))
+ (elpa (expand-file-name "elpa" tmp-init))
+ args)
+ (make-directory elpa)
+ (dolist (package packages)
+ ;; We need to recursively expand all the dependencies of the
+ ;; requested packages and all of them to `load-path'.
+ (dolist (package (named-let loop ((pkg-desc package))
+ (let (deps)
+ (dolist (req (package-desc-reqs pkg-desc))
+ (setq deps (nconc
+ (catch 'found
+ (dolist (p (apply #'append (mapcar #'cdr (package--alist))))
+ (when (and (string= (car req) (package-desc-name p))
+ (version-list-<= (cadr req) (package-desc-version p)))
+ (throw 'found (loop p)))))
+ deps)))
+ (cons pkg-desc deps))))
+ (push (format "--directory=%s" (package-desc-dir package)) args)
+ (let* ((load-suffixes '(".el" ".elc"))
+ (autoload (locate-library (package--autoloads-file-name package))))
+ (push (format "--load=%s" autoload) args))))
+ (apply #'start-process (concat "*" name "*") nil
+ (append (list (expand-file-name invocation-name invocation-directory)
+ "--quick" "--debug-init"
+ (format "--eval=%S"
+ '(progn
+ (require 'warnings)
+ (add-to-list 'warning-suppress-log-types 'initialization)))
+ "--init-directory" tmp-init)
+ args))
+ (message "Started Emacs with the init directory: %s" tmp-init)))
+
\f
;;;; Package description buffer.
--
2.39.2
^ permalink raw reply related [relevance 57%]
* Proposal for 'package-isolate' command
@ 2023-08-15 19:39 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-08-15 19:39 UTC (permalink / raw)
To: Eshel Yaron; +Cc: Thierry Volpiatto, emacs-devel
Eshel Yaron <me@eshelyaron.com> writes:
> Hi Philip,
>
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Here is my first attempt at providing this kind of a command. Any
>> comments?
>
> I haven't followed the thread very closely, but this looks quite useful!
> A few minor suggestions:
This is mostly a tangent, so the previous discussion is not that
relevant. I've changed the subject accordingly.
>> diff --git a/etc/NEWS b/etc/NEWS
>> index 57f04609679..c374695a571 100644
>> --- a/etc/NEWS
>> +++ b/etc/NEWS
>> @@ -505,6 +505,12 @@ project, that you can quickly select using 'project-switch-project'
>> When non-nil, package specifications with side-effects for building
>> software will be used when building a package.
>>
>> +---
>> +*** New command to start Emacs only with specific packages
>
> This should probably end with a period.
>
>> +The command 'package-isolate' is equivalent to starting Emacs with the
>> +-Q flag and loading specific packages (and their dependencies)
>> +manually.
>
> I'd rephrase this as: "The command 'package-isolate' starts a new Emacs
> instance with minimum customizations (similar to 'emacs -Q') and a given
> set of packages (with their dependencies)."
>
>> +(defun package-isolate (packages)
>> + "Start a new instance of Emacs and load only PACKAGES."
>
> I'd clarify that the new instance disregards the user's
> config/customizations, how about "Start a new Emacs instance with
> minimum customizations and load PACKAGES."
>
>> +DEFUN ("emacs-executable", Femacs_executable, Semacs_executable, 0, 0, "",
>> + doc: /* Return a string with the file name of the Emacs executable.
>> +If this is not known, nil will be returned instead. */)
>
> Maybe say "Return the file name of the Emacs executable, or nil if
> unknown." to steer clear of the passive voice.
Thanks, I obviously cannot write documentation. I've addressed the
changes locally, and will send an updated patch in response to Eli's
message.
> Best,
>
> Eshel
^ permalink raw reply [relevance 99%]
* Re: Changes to make in elpa-packages file for nongnu elpa
2023-08-08 5:52 75% ` Philip Kaludercic
@ 2023-08-15 16:55 54% ` Philip Kaludercic
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Philip Kaludercic @ 2023-08-15 16:55 UTC (permalink / raw)
To: Thierry Volpiatto; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1436 bytes --]
Philip Kaludercic <philipk@posteo.net> writes:
>>>> It is used specially for reproducing bugs in a clean environment, see it
>>>> as emacs -Q for Emacs when reporting bugs. This script starts Emacs -Q
>>>> with only Helm loaded, this ensure the bug if one comes from Helm and
>>>> not another package. This is important especially nowaday people are
>>>> using "Emacs distribution" with the world list of packages installed.
>>>> Apart that the script is useful to quickly launch Emacs with helm, one
>>>> can use it from the Helm directory or symlinked to e.g. ~/bin.
>>>
>>> I see. In that case is there any reason you implement this as a shell
>>> script?
>>
>> Well when I wrote the script, packages where not existing and from
>> outside emacs it is actually the only way to run a package isolated.
>>
>>> (It might be interesting to provide something like this for
>>> package.el, to test packages in a generic way.)
>>
>> Yes, this would be interesting, it would be something like this:
>>
>> Emacs -Q
>> M-x <A command that run a package alone, isolated from other
>> packages nuisances>
>
> I was actually thinking of a command like
>
> M-x package-isolate RET foo,bar,baz RET
>
> and a new instance of Emacs using -Q is spun up, with all the packages
> you have listed loaded, and nothing else... Sounds like a fun little
> weekend project ;^)
Here is my first attempt at providing this kind of a command. Any
comments?
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0002-Add-command-to-start-Emacs-with-specific-packages.patch --]
[-- Type: text/x-diff, Size: 4095 bytes --]
From ae254f69f789ab4fa2b83bcf2cdc64291ae8aff6 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Tue, 15 Aug 2023 18:39:14 +0200
Subject: [PATCH 2/2] Add command to start Emacs with specific packages
* lisp/emacs-lisp/package.el (package-isolate): Add command.
* etc/NEWS: Announce it.
---
etc/NEWS | 6 +++++
lisp/emacs-lisp/package.el | 50 ++++++++++++++++++++++++++++++++++++++
2 files changed, 56 insertions(+)
diff --git a/etc/NEWS b/etc/NEWS
index 57f04609679..c374695a571 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -505,6 +505,12 @@ project, that you can quickly select using 'project-switch-project'
When non-nil, package specifications with side-effects for building
software will be used when building a package.
+---
+*** New command to start Emacs only with specific packages
+The command 'package-isolate' is equivalent to starting Emacs with the
+-Q flag and loading specific packages (and their dependencies)
+manually.
+
** Flymake
+++
diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el
index b3062d2608b..c0bbdacec84 100644
--- a/lisp/emacs-lisp/package.el
+++ b/lisp/emacs-lisp/package.el
@@ -2625,6 +2625,56 @@ package-autoremove
removable))
(message "Nothing to autoremove")))))
+(defun package-isolate (packages)
+ "Start a new instance of Emacs and load only PACKAGES."
+ (interactive
+ (cl-loop for p in (cl-loop for p in (package--alist) append (cdr p))
+ unless (package-built-in-p p)
+ collect (cons (package-desc-full-name p) p) into table
+ finally return
+ (list (cl-loop for c in (completing-read-multiple
+ "Isolate packages: " table
+ nil t)
+ collect (alist-get c table nil nil #'string=))
+ current-prefix-arg)))
+ (cl-assert (cl-every #'package-desc-p packages))
+ (let* ((name (concat "package-isolate-" (mapconcat #'package-desc-full-name
+ packages ",")))
+ (tmp-init (make-temp-file name t))
+ (elpa (expand-file-name "elpa" tmp-init))
+ args)
+ (make-directory elpa)
+ (dolist (package packages)
+ ;; We need to recursively expand all the dependencies of the
+ ;; requested packages and all of them to `load-path'.
+ (dolist (package (named-let loop ((pkg-desc package))
+ (let (deps)
+ (dolist (req (package-desc-reqs pkg-desc))
+ (setq deps (nconc
+ (catch 'found
+ (dolist (p (apply #'append (mapcar #'cdr (package--alist))))
+ (when (and (string= (car req) (package-desc-name p))
+ (version-list-<= (cadr req) (package-desc-version p)))
+ (throw 'found (loop p)))))
+ deps)))
+ (cons pkg-desc deps))))
+ (let* ((real (package-desc-dir package))
+ (link (expand-file-name (file-name-nondirectory real) elpa)))
+ (make-symbolic-link real link t)
+ (push (format "--directory=%s" link) args))
+ (let* ((load-suffixes '(".el" ".elc"))
+ (autoload (locate-library (package--autoloads-file-name package))))
+ (push (format "--load=%s" autoload) args))))
+ (apply #'start-process (concat "*" name "*") nil
+ (append (list (or (emacs-executable) "emacs")
+ (format "--eval=%S"
+ '(progn
+ (require 'warnings)
+ (add-to-list 'warning-suppress-log-types 'initialization)))
+ "--quick" "--debug-init"
+ "--init-directory" tmp-init)
+ args))))
+
\f
;;;; Package description buffer.
--
2.39.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0001-Add-a-function-to-query-the-Emacs-executable.patch --]
[-- Type: text/x-diff, Size: 1330 bytes --]
From bc9ee566cb9fee337f94870aa718d9b5e57c007b Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Tue, 15 Aug 2023 18:37:59 +0200
Subject: [PATCH 1/2] Add a function to query the Emacs executable
* src/emacs.c (Femacs_executable): Add new function.
(syms_of_emacs): Announce it.
---
src/emacs.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/src/emacs.c b/src/emacs.c
index 687b8c7f81f..4869093ce09 100644
--- a/src/emacs.c
+++ b/src/emacs.c
@@ -3039,6 +3039,18 @@ DEFUN ("kill-emacs", Fkill_emacs, Skill_emacs, 0, 2, "P",
exit (exit_code);
}
+DEFUN ("emacs-executable", Femacs_executable, Semacs_executable, 0, 0, "",
+ doc: /* Return a string with the file name of the Emacs executable.
+If this is not known, nil will be returned instead. */)
+ (void)
+{
+ static Lisp_Object *string;
+ if (string)
+ return string;
+ if (initial_emacs_executable)
+ return string = build_string(initial_emacs_executable);
+ return Qnil;
+}
/* Perform an orderly shutdown of Emacs. Autosave any modified
buffers, kill any child processes, clean up the terminal modes (if
@@ -3566,6 +3578,7 @@ syms_of_emacs (void)
#endif
defsubr (&Skill_emacs);
+ defsubr (&Semacs_executable);
defsubr (&Sinvocation_name);
defsubr (&Sinvocation_directory);
--
2.39.2
^ permalink raw reply related [relevance 54%]
* Re: New Package for NonGNU-ELPA: clojure-ts-mode
@ 2023-08-13 6:23 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-08-13 6:23 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: danny, emacs-devel, manuel.uberti
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: danny@dfreeman.email, emacs-devel@gnu.org, manuel.uberti@inventati.org
>> Date: Sat, 12 Aug 2023 20:22:32 +0000
>>
>> This was my understanding as well, and while I understand it from a
>> technical perspective, I have a hunch there must be a tolerable
>> alternative with a better user interface.
>>
>> Perhaps this is a point at which the approach at which the major-mode
>> abstraction breaks down and has to be rethought? There have been
>> instances of alternative major modes for different languages in the past
>> (cperl, perl; js, js2, js3) that have found one way or another to
>> co-exist, but seeing how this is becoming more and more common, it would
>> be nice to have some consistent and unified way of expressing these
>> kinds of alternatives.
>
> If someone suggests such an arrangement, and demonstrates its
> viability in at least one example, we could discuss that and perhaps
> decide on migration towards such an approach. So far, no one came
> with any workable ideas, AFAIR.
OK good to know that there is potential interest. I had a few ideas I
wanted to try out. As soon as (or if ever) I have something working,
I'll push the code to a feature/ branch and ping this thread again
>> > The aspects of these modes that are not yet firmly decided are how to
>> > activate/deactivate them in a way that would be convenient and simple.
>> > But I don't think we will be removing the *-ts-modes as major modes,
>> > no.
>>
>> I get that we wouldn't want to remove them, out of backwards
>> compatibility, but is the plan to write more ...-ts-mode major modes?
>
> Yes, I think so. There doesn't seem to be any good alternative in
> existence.
^ permalink raw reply [relevance 99%]
* Re: New Package for NonGNU-ELPA: clojure-ts-mode
@ 2023-08-12 20:31 87% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-08-12 20:31 UTC (permalink / raw)
To: Danny Freeman; +Cc: emacs-devel, Manuel Uberti
Danny Freeman <danny@dfreeman.email> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Is there a reason we wouldn't want to have support in the core? Or at
>> least GNU ELPA?
>
> Not all of the maintainers of clojure-mode and clojure-ts-mode are on
> board with the core development model, particularly copyright
> assignment. Initially I wanted to put this straight in the core but
> after some discussion we decided not to. I have personally done my
> copyright assignment, but for clojure-ts-mode we won't be asking
> contributors for it. Therefore, going into GNU ELPA or core then is out
> of the question.
That is a pity. IIRC there is a SLIME-like environment for Clojure,
right? I don't know if Emacs is also the conventional default
environment for working with the language, but if it is, it seems like
it would be a nice thing to have at least some basic support in the core
:/
Did the discussions on not wanting to contribute anything to the core
take place in some public channel, where one could read up on what the
issues were or clarify some misunderstandings, in case these occurred?
>> If added to GNU ELPA and NonGNU ELPA, this would be the first *-ts-mode
>> package, from what I see. From what I recall, the -ts-mode approach was
>> a compromise to add some basic support for Tree Sitter in Emacs 29, but
>> I am not sure if it was a final decision on the matter, because at least
>> from my perspective of following the tree sitter development from a
>> close distance, but also from user reports I have heard of since the
>> release of Emacs 29, the current approach is slightly confusing. Adding
>> a -ts-mode to ELPA might be misinterpreted as a commitment to the
>> current trajectory, and I am not sure if that is intended.
>
> Yeah it is kind of confusing but I'm not sure what the end game is for
> all the other *-ts-modes. Non tree-sitter Clojure-mode itself has a lot
> of features and is also depended on by some other packages (cider,
> inf-clojure). In that regard, we decided trying to keep clojure-ts-mode
> and clojure-mode in the same repo would be too complex of a task.
> Therefore we put it in it's own repo.
>
> Very long term plans are for clojure-ts-mode to eventually reach feature
> parity with clojure-mode and start making it's consumer packages also
> use it. That will probably take a number of years though.
So you can also confirm Eli's take, that it is unfeasible to merge the
two major modes?
>>> + (clojure-ts-mode :url "https://github.com/clojure-emacs/clojure-ts-mode"
>>> + :ignored-files ("doc" "test")
>>
>> If possible, it is preferable to list ignored files in a .elpaignore
>> file, in the repository root directory.
>
> I have made a commit to the repo including one of those .elpaignores.
> I'm going to wait a while to tag a new release in case there is other
> feedback though. Here is the revised patch
I don't think there is much left that can be changed any more, just keep
in mind that ELPA doesn't use tags to designate package releases, but it
consults Git to detect the latest commit to modify the ";; Version:" tag
in the package header.
^ permalink raw reply [relevance 87%]
* Re: New Package for NonGNU-ELPA: clojure-ts-mode
@ 2023-08-12 20:22 89% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-08-12 20:22 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: danny, emacs-devel, manuel.uberti
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: emacs-devel <emacs-devel@gnu.org>, Manuel Uberti
>> <manuel.uberti@inventati.org>
>> Date: Sat, 12 Aug 2023 19:10:31 +0000
>>
>> If added to GNU ELPA and NonGNU ELPA, this would be the first *-ts-mode
>> package, from what I see. From what I recall, the -ts-mode approach was
>> a compromise to add some basic support for Tree Sitter in Emacs 29, but
>> I am not sure if it was a final decision on the matter, because at least
>> from my perspective of following the tree sitter development from a
>> close distance, but also from user reports I have heard of since the
>> release of Emacs 29, the current approach is slightly confusing. Adding
>> a -ts-mode to ELPA might be misinterpreted as a commitment to the
>> current trajectory, and I am not sure if that is intended.
>
> If you mean that the *-ts-modes could be a minor mode, then I believe
> we found that to be unworkable, except in very rare cases where the
> major mode supporting the same language is very thin and has only a
> couple of simple mode-specific features. Otherwise, the very
> different way of doing font-lock, indentation, imenu, etc. means that
> basically all the features must be reimplemented anew, and in many
> cases make no sense at all. So a minor mode is not TRT here.
This was my understanding as well, and while I understand it from a
technical perspective, I have a hunch there must be a tolerable
alternative with a better user interface.
Perhaps this is a point at which the approach at which the major-mode
abstraction breaks down and has to be rethought? There have been
instances of alternative major modes for different languages in the past
(cperl, perl; js, js2, js3) that have found one way or another to
co-exist, but seeing how this is becoming more and more common, it would
be nice to have some consistent and unified way of expressing these
kinds of alternatives.
> The aspects of these modes that are not yet firmly decided are how to
> activate/deactivate them in a way that would be convenient and simple.
> But I don't think we will be removing the *-ts-modes as major modes,
> no.
I get that we wouldn't want to remove them, out of backwards
compatibility, but is the plan to write more ...-ts-mode major modes?
^ permalink raw reply [relevance 89%]
* Re: New Package for NonGNU-ELPA: clojure-ts-mode
@ 2023-08-12 19:10 86% ` Philip Kaludercic
0 siblings, 2 replies; 200+ results
From: Philip Kaludercic @ 2023-08-12 19:10 UTC (permalink / raw)
To: Danny Freeman; +Cc: emacs-devel, Manuel Uberti
Danny Freeman <danny@dfreeman.email> writes:
> Hello,
>
> Clojure-ts-mode is a tree-sitter based mode for clojure editing. I am
> it's maintainer. It can be found here:
> https://github.com/clojure-emacs/clojure-ts-mode
>
> This package is currently listed only on MELPA, but I would also like it
> to be available on NonGNU-ELPA as well.
>
> Please let me know if you have any questions or concerns.
Is there a reason we wouldn't want to have support in the core? Or at
least GNU ELPA?
If added to GNU ELPA and NonGNU ELPA, this would be the first *-ts-mode
package, from what I see. From what I recall, the -ts-mode approach was
a compromise to add some basic support for Tree Sitter in Emacs 29, but
I am not sure if it was a final decision on the matter, because at least
from my perspective of following the tree sitter development from a
close distance, but also from user reports I have heard of since the
release of Emacs 29, the current approach is slightly confusing. Adding
a -ts-mode to ELPA might be misinterpreted as a commitment to the
current trajectory, and I am not sure if that is intended.
> From 5d92f6f2054b73cf9fb9a0f81d7ac0064715a6d6 Mon Sep 17 00:00:00 2001
> From: dannyfreeman <danny@dfreeman.email>
> Date: Sat, 12 Aug 2023 14:31:44 -0400
> Subject: [PATCH] * elpa-packages (clojure-ts-mode): new package
>
> ---
> elpa-packages | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/elpa-packages b/elpa-packages
> index 9dac0cd..6a90468 100644
> --- a/elpa-packages
> +++ b/elpa-packages
> @@ -87,6 +87,11 @@
> :ignored-files ("clojure-mode-extra-font-locking.el" "doc" "test" "test.clj")
> :news "CHANGELOG.md")
>
> + (clojure-ts-mode :url "https://github.com/clojure-emacs/clojure-ts-mode"
> + :ignored-files ("doc" "test")
If possible, it is preferable to list ignored files in a .elpaignore
file, in the repository root directory.
> + :readme "README.md"
> + :news "CHANGELOG.md")
> +
> (coffee-mode :url "https://github.com/defunkt/coffee-mode")
>
> (corfu-terminal :url "https://codeberg.org/akib/emacs-corfu-terminal")
> --
> 2.40.1
>
>
>
> Thank you,
^ permalink raw reply [relevance 86%]
* Re: [ELPA] Proposing to add express to ELPA
@ 2023-08-11 18:14 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-08-11 18:14 UTC (permalink / raw)
To: Yuan Fu; +Cc: emacs-devel
Yuan Fu <casouri@gmail.com> writes:
>> On Jul 31, 2023, at 11:38 AM, Yuan Fu <casouri@gmail.com> wrote:
>>
>> Hi all,
>>
>> Since Emacs 29 is now released, I’d like to propose adding expreg to
>> ELPA. Expreg can be considered a lite version of expand-region. The
>> notable difference is its use of tree-sitter for language-specific
>> expansions. I also took the liberty to do things differently than
>> expand-region, eg, expreg uses a smaller number of expanders [1]; it
>> is easier to debug when the expansion isn’t what you expected; and
>> it only provides two functions for expansion and contraction, and
>> one variable for adding/removing expanders—no transient maps and
>> other “smart” features, nor different variables to set for each
>> major mode.
>
> What do you think, guys? Should it be added to ELPA?
I think it would be a nice addition, were there any open objections?
> Yuan
^ permalink raw reply [relevance 99%]
* Re: [elpa] externals/compat 6a60af22da: Optimize string-search
@ 2023-08-11 8:17 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-08-11 8:17 UTC (permalink / raw)
To: Daniel Mendler; +Cc: emacs-devel
Daniel Mendler <mail@daniel-mendler.de> writes:
> On 8/11/23 08:07, Philip Kaludercic wrote:
>> ELPA Syncer <elpasync@gnu.org> writes:
>>
>>> branch: externals/compat
>>> commit 6a60af22da1f1a7b08457a4016b9412a475afe4a
>>> Author: Daniel Mendler <mail@daniel-mendler.de>
>>> Commit: Daniel Mendler <mail@daniel-mendler.de>
>>>
>>> Optimize string-search
>>> ---
>>> compat-28.el | 5 ++---
>>> 1 file changed, 2 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/compat-28.el b/compat-28.el
>>> index fe69315522..b305ab2fff 100644
>>> --- a/compat-28.el
>>> +++ b/compat-28.el
>>> @@ -52,9 +52,8 @@ issues are inherited."
>>> (when (and start-pos (or (< (length haystack) start-pos)
>>> (< start-pos 0)))
>>> (signal 'args-out-of-range (list start-pos)))
>>> - (save-match-data
>>> - (let ((case-fold-search nil))
>>> - (string-match (regexp-quote needle) haystack start-pos))))
>>> + (let (case-fold-search)
>>> + (string-match-p (regexp-quote needle) haystack start-pos)))
>>>
>>> (compat-defun length= (sequence length) ;; [[compat-tests:length=]]
>>> "Returns non-nil if SEQUENCE has a length equal to LENGTH."
>>
>> I don't believe this is a legal optimisation, even if the regular
>> expression is quoted. Consider
>
> Hi Philip,
>
> did you notice that I replaced `string-match' with `string-match-p'?
No, I missed that. Never mind then.
> Daniel
^ permalink raw reply [relevance 99%]
* Re: [elpa] externals/compat 6a60af22da: Optimize string-search
@ 2023-08-11 8:15 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-08-11 8:15 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel, mail
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: Daniel Mendler <mail@daniel-mendler.de>
>> Date: Fri, 11 Aug 2023 06:07:32 +0000
>>
>> I don't believe this is a legal optimisation, even if the regular
>> expression is quoted.
>
> It is certainly "legal", in the sense that it breaks no laws.
>
> The GNU Coding Standards frown on using "legal" or "illegal" for
> anything that doesn't involve the laws and jurisprudence; we use
> "valid" and "invalid" instead.
Ok, I did not know that. Thanks.
^ permalink raw reply [relevance 99%]
* Re: [elpa] externals/compat 6a60af22da: Optimize string-search
[not found] ` <20230809135738.457BDC038BF@vcs2.savannah.gnu.org>
@ 2023-08-11 6:07 98% ` Philip Kaludercic
0 siblings, 2 replies; 200+ results
From: Philip Kaludercic @ 2023-08-11 6:07 UTC (permalink / raw)
To: emacs-devel; +Cc: Daniel Mendler
ELPA Syncer <elpasync@gnu.org> writes:
> branch: externals/compat
> commit 6a60af22da1f1a7b08457a4016b9412a475afe4a
> Author: Daniel Mendler <mail@daniel-mendler.de>
> Commit: Daniel Mendler <mail@daniel-mendler.de>
>
> Optimize string-search
> ---
> compat-28.el | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/compat-28.el b/compat-28.el
> index fe69315522..b305ab2fff 100644
> --- a/compat-28.el
> +++ b/compat-28.el
> @@ -52,9 +52,8 @@ issues are inherited."
> (when (and start-pos (or (< (length haystack) start-pos)
> (< start-pos 0)))
> (signal 'args-out-of-range (list start-pos)))
> - (save-match-data
> - (let ((case-fold-search nil))
> - (string-match (regexp-quote needle) haystack start-pos))))
> + (let (case-fold-search)
> + (string-match-p (regexp-quote needle) haystack start-pos)))
>
> (compat-defun length= (sequence length) ;; [[compat-tests:length=]]
> "Returns non-nil if SEQUENCE has a length equal to LENGTH."
I don't believe this is a legal optimisation, even if the regular
expression is quoted. Consider
(progn
(string-match (rx (* "a") (group (* "b")) (* "a")) "abba")
(match-data))
; => (0 4 1 3)
and
(progn
(string-match (rx (* "a") (group (* "b")) (* "a")) "abba")
(string-search "foo" "foobar")
(match-data))
; => (0 4 1 3)
but
(progn
(string-match (rx (* "a") (group (* "b")) (* "a")) "abba")
(let ((case-fold-search nil))
(string-match (regexp-quote "foo") "foobar" 0))
(match-data))
; => (0 3)
^ permalink raw reply [relevance 98%]
* Re: Changes to make in elpa-packages file for nongnu elpa
@ 2023-08-09 15:24 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-08-09 15:24 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: michael.albinus, emacs-devel, monnier
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: michael.albinus@gmx.de, emacs-devel@gnu.org, monnier@iro.umontreal.ca
>> Date: Wed, 09 Aug 2023 14:53:12 +0000
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> >> In that case I'd like to request access to elpa.gnu.org
>> >
>> > You mean you cannot access it now?
>>
>> I can access it as a user, but I cannot access it to fix something.
>
> Maybe I'm misremembering, but AFAIR if you have write access to the
> Emacs Git repository, you also have write access to the ELPA Git
> repository.
No I have access to emacs.git, elpa.git and nongnu.git, what I was
referent to was the server associated with elpa.gnu.org.
>> >> and ideally also the list of users who have signed the CA.
>> >
>> > No can do, for privacy reasons. You can always ask me or Stefan to
>> > check a name for you, though.
>>
>> OK, but most of the time I don't have to check a single user but would
>> like to see check a set of names to see how many have or haven't signed
>> the CA. Is that still a manageable effort on your end?
>
> Yes, feel free.
OK, thank you for the clarification.
^ permalink raw reply [relevance 99%]
* Re: Changes to make in elpa-packages file for nongnu elpa
@ 2023-08-09 14:53 98% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-08-09 14:53 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: michael.albinus, emacs-devel, monnier
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: emacs-devel@gnu.org, "'Eli Zaretskii'" <eliz@gnu.org>, Stefan Monnier
>> <monnier@iro.umontreal.ca>
>> Date: Wed, 09 Aug 2023 07:06:30 +0000
>>
>> >>> Perhaps it is worth to mention this in admin/MAINTAINERS?
>> >>
>> >> There seems to be no information on ELPA in admin/MAINTAINERS.
>> >
>> > Yes, the file is incomplete. So it is time to say something about GNU
>> > ELPA, IMHO.
>>
>> In that case I'd like to request access to elpa.gnu.org
>
> You mean you cannot access it now?
I can access it as a user, but I cannot access it to fix something.
>> and ideally also the list of users who have signed the CA.
>
> No can do, for privacy reasons. You can always ask me or Stefan to
> check a name for you, though.
OK, but most of the time I don't have to check a single user but would
like to see check a set of names to see how many have or haven't signed
the CA. Is that still a manageable effort on your end?
> Thanks.
^ permalink raw reply [relevance 98%]
* Re: Changes to make in elpa-packages file for nongnu elpa
@ 2023-08-09 7:06 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-08-09 7:06 UTC (permalink / raw)
To: Michael Albinus; +Cc: emacs-devel, 'Eli Zaretskii', Stefan Monnier
Michael Albinus <michael.albinus@gmx.de> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
> Hi Philip,
>
>>>> I am sort of an unofficial co-maintainer, without access to any
>>>> server-side infrastructure, but other than that I'm glad to help within
>>>> my possibilities.
>>>
>>> Perhaps it is worth to mention this in admin/MAINTAINERS?
>>
>> There seems to be no information on ELPA in admin/MAINTAINERS.
>
> Yes, the file is incomplete. So it is time to say something about GNU
> ELPA, IMHO.
In that case I'd like to request access to elpa.gnu.org, and ideally
also the list of users who have signed the CA.
I've CC'ed Eli and Stefan.
> Best regards, Michael.
^ permalink raw reply [relevance 99%]
* Re: Changes to make in elpa-packages file for nongnu elpa
@ 2023-08-08 16:37 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-08-08 16:37 UTC (permalink / raw)
To: Michael Albinus; +Cc: Thierry Volpiatto, emacs-devel
Michael Albinus <michael.albinus@gmx.de> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
> Hi Philip,
>
>>>> Sorry about that, you can always feel free to CC me if you have specific
>>>> questions that might get lost on the mailing list. I suppose Stefan
>>>> Monnier wouldn't object to be mentioned either.
>>>
>>> Ok thanks, I will next time now I know you and Stefan are in charge of
>>> this.
>>
>> I am sort of an unofficial co-maintainer, without access to any
>> server-side infrastructure, but other than that I'm glad to help within
>> my possibilities.
>
> Perhaps it is worth to mention this in admin/MAINTAINERS?
There seems to be no information on ELPA in admin/MAINTAINERS.
> Best regards, Michael.
^ permalink raw reply [relevance 99%]
* Re: Changes to make in elpa-packages file for nongnu elpa
@ 2023-08-08 5:52 75% ` Philip Kaludercic
2023-08-15 16:55 54% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-08-08 5:52 UTC (permalink / raw)
To: Thierry Volpiatto; +Cc: emacs-devel
Thierry Volpiatto <thievol@posteo.net> writes:
> Hello Philip,
>
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Thierry Volpiatto <thievol@posteo.net> writes:
>>
>>> Philip Kaludercic <philipk@posteo.net> writes:
>>>
>>>> Thierry Volpiatto <thievol@posteo.net> writes:
>>>>
>>>>> I see that Helm installation from nongnu elpa doesn't include
>>>>> emacs-helm.sh script, would it be possible to modify this?
>>>>>
>>>>> diff --git a/elpa-packages b/elpa-packages
>>>>> index 77d7a5409e..0923724b62 100644
>>>>> --- a/elpa-packages
>>>>> +++ b/elpa-packages
>>>>> @@ -312,11 +312,11 @@
>>>>> :ignored-files "COPYING")
>>>>>
>>>>> (helm :url "https://github.com/emacs-helm/helm"
>>>>> - :ignored-files ("images" "Cask" "Makefile" "emacs-helm.sh" "helm-core.el" "helm.el"
>>>>> + :ignored-files ("images" "Makefile" "helm-core.el" "helm.el"
>>>>> "helm-lib.el" "helm-source.el" "helm-multi-match.el"))
>>>>>
>>>>> (helm-core :url "https://github.com/emacs-helm/helm"
>>>>> - :ignored-files ("images" "Cask" "Makefile" "emacs-helm.sh" "helm-adaptive.el"
>>>>> + :ignored-files ("images" "Makefile" "emacs-helm.sh" "helm-adaptive.el"
>>>>> "helm-bookmark.el" "helm-buffers.el" "helm-color.el" "helm-comint.el"
>>>>> "helm-command.el" "helm-config.el" "helm-dabbrev.el" "helm-easymenu.el"
>>>>> "helm-elisp.el" "helm-elisp-package.el" "helm-epa.el" "helm-eshell.el"
>>>>
>>>> There shouldn't be any issue in applying this patch, but could you
>>>> explain the propose of this script?
>>>
>>> It is used specially for reproducing bugs in a clean environment, see it
>>> as emacs -Q for Emacs when reporting bugs. This script starts Emacs -Q
>>> with only Helm loaded, this ensure the bug if one comes from Helm and
>>> not another package. This is important especially nowaday people are
>>> using "Emacs distribution" with the world list of packages installed.
>>> Apart that the script is useful to quickly launch Emacs with helm, one
>>> can use it from the Helm directory or symlinked to e.g. ~/bin.
>>
>> I see. In that case is there any reason you implement this as a shell
>> script?
>
> Well when I wrote the script, packages where not existing and from
> outside emacs it is actually the only way to run a package isolated.
>
>> (It might be interesting to provide something like this for
>> package.el, to test packages in a generic way.)
>
> Yes, this would be interesting, it would be something like this:
>
> Emacs -Q
> M-x <A command that run a package alone, isolated from other
> packages nuisances>
I was actually thinking of a command like
M-x package-isolate RET foo,bar,baz RET
and a new instance of Emacs using -Q is spun up, with all the packages
you have listed loaded, and nothing else... Sounds like a fun little
weekend project ;^)
>> I am sort of an unofficial co-maintainer, without access to any
>> server-side infrastructure, but other than that I'm glad to help within
>> my possibilities.
>
> Ok thanks.
>
>>> Ok, it's what I thought, so yes it would be nice to install wfnames
>>> package in Nongnu.
>>> Here is the link: https://github.com/thierryvolpiatto/wfnames
>>
>> Sure, but could you first take a look at these comments, suggestions and
>> questions I have made while skimming over the source?
>>
>> diff --git a/wfnames.el b/wfnames.el
>> index e5a83b5..a61a18d 100644
>> --- a/wfnames.el
>> +++ b/wfnames.el
>> @@ -34,20 +34,20 @@
>>
>> ;; Usage:
>> ;; Once in the Wfnames buffer, edit your filenames and hit C-c C-c to
>> -;; save your changes. You have completion on filenames and directories
>> +;; save your changes. You have completion on filenames and directories
>> ;; with TAB but if you are using Iedit package and it is in action use =M-TAB=.
>>
>> ;;; Code:
>>
>> -(require 'cl-lib)
>> +(eval-when-compile (require 'cl-lib)) ;you are only using macros, so this should be OK
>
> Ok done.
>
>> ;; Internal.
>> -(defvar wfnames-buffer "*Wfnames*")
>> -(defvar wfnames--modified nil)
>> +(defvar wfnames-buffer "*Wfnames*") ;perhaps `defconst'
>> +(defvar-local wfnames--modified nil)
>
> Ok done.
>
>> \f
>> (defgroup wfnames nil
>> "A mode to edit filenames."
>> - :group 'wfnames)
>> + :group 'wfnames) ;watch out, this is a recursive group
>
> Good catch, done.
>
>> (defcustom wfnames-create-parent-directories t
>> "Create parent directories when non nil."
>> @@ -57,16 +57,21 @@
>> "Ask confirmation when overwriting."
>> :type 'boolean)
>>
>> -(defvar wfnames-after-commit-hook nil)
>> +(defcustom wfnames-after-commit-hook nil
>> + "Hook to run after `wfnames-commit-buffer'." ;rephrase this
>
> Not sure how to rephrase this:
>
> "Hook that run after `wfnames-commit-buffer'."?
If it is OK the way it is, then you can keep it, I just wasn't sure if
you would have a more descriptive name for it.
>> + :type 'hook)
>
> Othewise defcustom make sense, done.
>
>> (defcustom wfnames-after-commit-function #'kill-buffer
>> "A function to call on `wfnames-buffer' when done."
>> :type 'function)
>>
>> (defcustom wfnames-make-backup nil
>> - "Backup files before overwriting when non nil."
>> + "Non-nil means files are backed up before overwriting."
>
> Ok done.
>
>>
>> :type 'boolean)
>> \f
>> +;; instead of defining new faces and colours, do you think it would be
>> +;; possible to inherit from existing faces?
>
> Apart requiring a package just for the faces no, font-lock family
> doesn't provide :background faces.
I wasn't thinking just of font-lock, you could pick any face,
eg. wfnames-modified could inherit from diff-refine-changed. That way
themes don't have to add extra support, and the package looks more
"native" without any additional effort.
>> (defface wfnames-modified
>> '((t :background "LightBlue" :foreground "black"))
>> "Face used when filename is modified.")
>> @@ -104,27 +109,27 @@
>> "Provide filename completion in wfnames buffer."
>> (let ((beg (line-beginning-position))
>> (end (point)))
>> + ;; Does it make sense to extend beyond END to allow completing
>> + ;; file names mid-string?
>
> This one for now I don't know, I transformed your comment with a FIXME.
That is fine, this is just a general thing I wonder about with CAP
functions.
>>
>> (list beg end #'completion-file-name-table :exit-function (lambda
>> (str _status) (when (and (stringp str) (eq (char-after) ?/))
>> (delete-char -1))))))
>>
>> -(define-derived-mode wfnames-mode
>> - text-mode "wfnames"
>> +(define-derived-mode wfnames-mode text-mode "wfnames"
>> "Major mode to edit filenames.
>
> Ok.
>
>> Special commands:
>> \\{wfnames-mode-map}"
>> (add-hook 'after-change-functions #'wfnames-after-change-hook nil t)
>> - (make-local-variable 'wfnames--modified)
>> - (set (make-local-variable 'completion-at-point-functions) #'wfnames-capf)
>> - (set (make-local-variable 'revert-buffer-function) #'wfnames-revert-changes))
>> + (setq-local completion-at-point-functions #'wfnames-capf)
>> + (setq-local revert-buffer-function #'wfnames-revert-changes))
>
> Yes done.
>
>> (defun wfnames-abort ()
>> "Quit and kill wfnames buffer."
>> (interactive)
>> - (quit-window t))
>> + (quit-window t)) ;isn't this `kill-buffer-and-window'
>
> Yes, but quit-window is fine as well (I am used to it).
>
>> (defun wfnames-after-change-hook (beg end _len)
>> "Put overlay on current line when modified.
>> @@ -137,9 +142,10 @@ Args BEG and END delimit changes on line."
>> (eol (line-end-position))
>> (old (get-text-property bol 'old-name))
>> (new (buffer-substring-no-properties bol eol))
>> - ov face)
>> - (setq face (if (file-exists-p new)
>> - 'wfnames-modified-exists 'wfnames-modified))
>> + (face (if (file-exists-p new)
>> + 'wfnames-modified-exists
>> + 'wfnames-modified))
>> + ov)
>
> Ok.
>
>> (setq-local wfnames--modified
>> (cons old (delete old wfnames--modified)))
>> (cl-loop for o in (overlays-in bol eol)
>> @@ -184,10 +190,10 @@ When APPEND is specified, append FILES to existing `wfnames-buffer'."
>> "* "
>> 'face 'wfnames-prefix))
>> "\n"))
>> - (when append (delete-duplicate-lines (point-min) (point-max))))
>> + (when append (delete-duplicate-lines (point-min) (point-max)))) ;this requires Emacs 24.4
>> (unless append
>> ;; Go to beginning of basename on first line.
>> - (while (re-search-forward "/" (line-end-position) t))
>> + (re-search-forward "\\(?:/[^/]*\\)*/" (line-end-position) t)
>
> Ok.
>
>> (wfnames-mode)
>> (funcall display-fn wfnames-buffer))))
>> \f
>> @@ -202,7 +208,7 @@ When APPEND is specified, append FILES to existing `wfnames-buffer'."
>> "Backup FILE."
>> (when wfnames-make-backup
>> (with-current-buffer (find-file-noselect file)
>> - (let ((backup-by-copying t))
>> + (let ((backup-by-copying t)) ;why is this bound? isn't this
>> a user preference?
>
> Yes removed.
>
>>
>> (backup-buffer)) (kill-buffer))))
>>
>> @@ -252,7 +258,7 @@ When APPEND is specified, append FILES to existing `wfnames-buffer'."
>> (let ((basedir (file-name-directory
>> (directory-file-name new))))
>> (unless (file-directory-p basedir)
>> - (mkdir basedir 'parents))))
>> + (make-directory basedir
>> 'parents))))
>
> Ok, make sense.
>
>> (if (and ow (wfnames-ask-for-overwrite new))
>> ;; Direct overwrite i.e. first loop.
>> (progn
>> @@ -300,21 +306,22 @@ With a numeric prefix ARG, revert the ARG next lines."
>> (wfnames-revert-current-line-1)
>> (when (eobp) (forward-line -1))
>> (goto-char (line-beginning-position))
>> - (while (re-search-forward "/" (line-end-position) t))))
>> + (re-search-forward "\\(?:/[^/]*\\)*/" (line-end-position) t)))
>
> Ok, same as above.
>
>> (defun wfnames-revert-changes (_ignore-auto _no-confirm)
>> "Revert wfnames buffer to its initial state.
>>
>> This is used as `revert-buffer-function' for `wfnames-mode'."
>> (with-current-buffer wfnames-buffer
>> - (cl-loop for o in (overlays-in (point-min) (point-max))
>> - when (overlay-get o 'hff-changed)
>> - do (delete-overlay o))
>> + (dolist (o (overlays-in (point-min) (point-max)))
>> + (when (overlay-get o 'hff-changed)
>> + (delete-overlay o)))
>
> If you want ;-) done.
I am totally indifferent, they expand to almost the same code anyway:
--8<---------------cut here---------------start------------->8---
(disassemble
(byte-compile
'(cl-loop for o in olist
when (foo)
do (bar))))
byte code:
args: nil
0 varref olist
1 constant nil
2:1 stack-ref 1
3 consp
4 goto-if-nil 3
7 discard
8 dup
9 car
10 constant foo
11 call 0
12 goto-if-nil 2
15 constant bar
16 call 0
17 discard
18:2 stack-ref 1
19 cdr
20 stack-set 2
22 goto 1
25:3 constant nil
26 return
(disassemble
(byte-compile
'(dolist (o olist)
(when (foo)
(bar)))))
byte code:
args: nil
0 varref olist
1:1 dup
2 goto-if-nil-else-pop 3
5 dup
6 car
7 discard
8 constant nil
9 constant foo
10 call 0
11 goto-if-nil 2
14 constant bar
15 call 0
16 discard
17:2 discard
18 cdr
19 goto 1
22:3 return
--8<---------------cut here---------------end--------------->8---
>> (goto-char (point-min))
>> (save-excursion
>> (while (not (eobp))
>> (wfnames-revert-current-line-1)))
>> - (while (re-search-forward "/" (line-end-position) t))))
>> + (re-search-forward "\\(?:/[^/]*\\)*/" (line-end-position) t)))
>> +
>
> Ok same as above.
>
>> (provide 'wfnames)
>>
>>
>>
>>> Thanks.
>
> Thanks.
Great, I'll add the package then.
^ permalink raw reply [relevance 75%]
* Re: [NonGNU ELPA] New package: llm
@ 2023-08-08 5:42 91% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-08-08 5:42 UTC (permalink / raw)
To: Andrew Hyatt; +Cc: Emacs-Devel devel
Andrew Hyatt <ahyatt@gmail.com> writes:
> Hi everyone,
>
> I've created a new package called llm, for the purpose of abstracting the
> interface to various large language model providers. There are many LLM
> packages already, but it would be wasteful for all of them to try to be
> compatible with a range of LLM providers API (local LLMs such as Llama 2,
> API providers such as Open AI and Google Cloud's Vertex). This package
> attempts to solve this problem by defining generic functions which can then
> be implemented by different LLM providers. I have started with just two:
> Open AI and Vertex. Llama 2 would be a next choice, but I don't yet have
> it working on my system. In addition, I'm starting with just two core
> functionality: chat and embeddings. Extending to async is probably
> something that I will do next.
Llama was the model that could be executed locally, and the other two
are "real" services, right?
> You can see the code at https://github.com/ahyatt/llm.
>
> I prefer that this is NonGNU, because I suspect people would like to
> contribute interfaces to different LLM, and not all of them will have FSF
> papers.
I cannot estimate how important or not LLM will be in the future, but it
might be worth having something like this in the core, at some point.
Considering the size of a module at around 150-200 lines it seems, and
the relative infrequency of new models (at least to my understanding), I
don't know if the "advantage" of accepting contributions from people who
haven't signed the CA has that much weight, opposed to the general that
all users may enjoy from having the technology integrated into Emacs
itself, in a way that other packages (and perhaps even the core-help
system) could profit from it.
> Your thoughts would be appreciated, thank you!
^ permalink raw reply [relevance 91%]
* Re: Changes to make in elpa-packages file for nongnu elpa
@ 2023-08-07 20:33 45% ` Philip Kaludercic
0 siblings, 2 replies; 200+ results
From: Philip Kaludercic @ 2023-08-07 20:33 UTC (permalink / raw)
To: Thierry Volpiatto; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 3760 bytes --]
Thierry Volpiatto <thievol@posteo.net> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Thierry Volpiatto <thievol@posteo.net> writes:
>>
>>> I see that Helm installation from nongnu elpa doesn't include
>>> emacs-helm.sh script, would it be possible to modify this?
>>>
>>> diff --git a/elpa-packages b/elpa-packages
>>> index 77d7a5409e..0923724b62 100644
>>> --- a/elpa-packages
>>> +++ b/elpa-packages
>>> @@ -312,11 +312,11 @@
>>> :ignored-files "COPYING")
>>>
>>> (helm :url "https://github.com/emacs-helm/helm"
>>> - :ignored-files ("images" "Cask" "Makefile" "emacs-helm.sh" "helm-core.el" "helm.el"
>>> + :ignored-files ("images" "Makefile" "helm-core.el" "helm.el"
>>> "helm-lib.el" "helm-source.el" "helm-multi-match.el"))
>>>
>>> (helm-core :url "https://github.com/emacs-helm/helm"
>>> - :ignored-files ("images" "Cask" "Makefile" "emacs-helm.sh" "helm-adaptive.el"
>>> + :ignored-files ("images" "Makefile" "emacs-helm.sh" "helm-adaptive.el"
>>> "helm-bookmark.el" "helm-buffers.el" "helm-color.el" "helm-comint.el"
>>> "helm-command.el" "helm-config.el" "helm-dabbrev.el" "helm-easymenu.el"
>>> "helm-elisp.el" "helm-elisp-package.el" "helm-epa.el" "helm-eshell.el"
>>
>> There shouldn't be any issue in applying this patch, but could you
>> explain the propose of this script?
>
> It is used specially for reproducing bugs in a clean environment, see it
> as emacs -Q for Emacs when reporting bugs. This script starts Emacs -Q
> with only Helm loaded, this ensure the bug if one comes from Helm and
> not another package. This is important especially nowaday people are
> using "Emacs distribution" with the world list of packages installed.
> Apart that the script is useful to quickly launch Emacs with helm, one
> can use it from the Helm directory or symlinked to e.g. ~/bin.
I see. In that case is there any reason you implement this as a shell
script? (It might be interesting to provide something like this for
package.el, to test packages in a generic way.)
>> I see something involving straight.el, which is a
>> package.el-incompatible package manager, at which point I am confused
>> why this should be distributed along with a "package.el"-package.
>
> The script doesn't need straight, but it ensures the script is usable for
> somebody using straight (to find package directory etc...).
Ah OK my bad.
>>> Also I asked here about a new dependency for Helm called wfnames and had
>>> no answer (2 times),
>>
>> Sorry about that, you can always feel free to CC me if you have specific
>> questions that might get lost on the mailing list. I suppose Stefan
>> Monnier wouldn't object to be mentioned either.
>
> Ok thanks, I will next time now I know you and Stefan are in charge of
> this.
I am sort of an unofficial co-maintainer, without access to any
server-side infrastructure, but other than that I'm glad to help within
my possibilities.
>>> so I ask again differently now:
>>>
>>> When a package is available in Melpa do we have to add it in nongnu as
>>> well to satisfy dependencies for a package already in nongnu?
>>
>> Yes, if the dependency is missing someone only using GNU ELPA and NonGNU
>> ELPA wouldn't be able to install the package due to a missing dependency
>> and that is obviously not intended.
>
> Ok, it's what I thought, so yes it would be nice to install wfnames
> package in Nongnu.
> Here is the link: https://github.com/thierryvolpiatto/wfnames
Sure, but could you first take a look at these comments, suggestions and
questions I have made while skimming over the source?
[-- Attachment #2: Type: text/plain, Size: 6559 bytes --]
diff --git a/wfnames.el b/wfnames.el
index e5a83b5..a61a18d 100644
--- a/wfnames.el
+++ b/wfnames.el
@@ -34,20 +34,20 @@
;; Usage:
;; Once in the Wfnames buffer, edit your filenames and hit C-c C-c to
-;; save your changes. You have completion on filenames and directories
+;; save your changes. You have completion on filenames and directories
;; with TAB but if you are using Iedit package and it is in action use =M-TAB=.
;;; Code:
-(require 'cl-lib)
+(eval-when-compile (require 'cl-lib)) ;you are only using macros, so this should be OK
;; Internal.
-(defvar wfnames-buffer "*Wfnames*")
-(defvar wfnames--modified nil)
+(defvar wfnames-buffer "*Wfnames*") ;perhaps `defconst'
+(defvar-local wfnames--modified nil)
\f
(defgroup wfnames nil
"A mode to edit filenames."
- :group 'wfnames)
+ :group 'wfnames) ;watch out, this is a recursive group
(defcustom wfnames-create-parent-directories t
"Create parent directories when non nil."
@@ -57,16 +57,21 @@
"Ask confirmation when overwriting."
:type 'boolean)
-(defvar wfnames-after-commit-hook nil)
+(defcustom wfnames-after-commit-hook nil
+ "Hook to run after `wfnames-commit-buffer'." ;rephrase this
+ :type 'hook)
(defcustom wfnames-after-commit-function #'kill-buffer
"A function to call on `wfnames-buffer' when done."
:type 'function)
(defcustom wfnames-make-backup nil
- "Backup files before overwriting when non nil."
+ "Non-nil means files are backed up before overwriting."
:type 'boolean)
\f
+;; instead of defining new faces and colours, do you think it would be
+;; possible to inherit from existing faces?
+
(defface wfnames-modified
'((t :background "LightBlue" :foreground "black"))
"Face used when filename is modified.")
@@ -104,27 +109,27 @@
"Provide filename completion in wfnames buffer."
(let ((beg (line-beginning-position))
(end (point)))
+ ;; Does it make sense to extend beyond END to allow completing
+ ;; file names mid-string?
(list beg end #'completion-file-name-table
:exit-function (lambda (str _status)
(when (and (stringp str)
(eq (char-after) ?/))
(delete-char -1))))))
-(define-derived-mode wfnames-mode
- text-mode "wfnames"
+(define-derived-mode wfnames-mode text-mode "wfnames"
"Major mode to edit filenames.
Special commands:
\\{wfnames-mode-map}"
(add-hook 'after-change-functions #'wfnames-after-change-hook nil t)
- (make-local-variable 'wfnames--modified)
- (set (make-local-variable 'completion-at-point-functions) #'wfnames-capf)
- (set (make-local-variable 'revert-buffer-function) #'wfnames-revert-changes))
+ (setq-local completion-at-point-functions #'wfnames-capf)
+ (setq-local revert-buffer-function #'wfnames-revert-changes))
(defun wfnames-abort ()
"Quit and kill wfnames buffer."
(interactive)
- (quit-window t))
+ (quit-window t)) ;isn't this `kill-buffer-and-window'
(defun wfnames-after-change-hook (beg end _len)
"Put overlay on current line when modified.
@@ -137,9 +142,10 @@ Args BEG and END delimit changes on line."
(eol (line-end-position))
(old (get-text-property bol 'old-name))
(new (buffer-substring-no-properties bol eol))
- ov face)
- (setq face (if (file-exists-p new)
- 'wfnames-modified-exists 'wfnames-modified))
+ (face (if (file-exists-p new)
+ 'wfnames-modified-exists
+ 'wfnames-modified))
+ ov)
(setq-local wfnames--modified
(cons old (delete old wfnames--modified)))
(cl-loop for o in (overlays-in bol eol)
@@ -184,10 +190,10 @@ When APPEND is specified, append FILES to existing `wfnames-buffer'."
"* "
'face 'wfnames-prefix))
"\n"))
- (when append (delete-duplicate-lines (point-min) (point-max))))
+ (when append (delete-duplicate-lines (point-min) (point-max)))) ;this requires Emacs 24.4
(unless append
;; Go to beginning of basename on first line.
- (while (re-search-forward "/" (line-end-position) t))
+ (re-search-forward "\\(?:/[^/]*\\)*/" (line-end-position) t)
(wfnames-mode)
(funcall display-fn wfnames-buffer))))
\f
@@ -202,7 +208,7 @@ When APPEND is specified, append FILES to existing `wfnames-buffer'."
"Backup FILE."
(when wfnames-make-backup
(with-current-buffer (find-file-noselect file)
- (let ((backup-by-copying t))
+ (let ((backup-by-copying t)) ;why is this bound? isn't this a user preference?
(backup-buffer))
(kill-buffer))))
@@ -252,7 +258,7 @@ When APPEND is specified, append FILES to existing `wfnames-buffer'."
(let ((basedir (file-name-directory
(directory-file-name new))))
(unless (file-directory-p basedir)
- (mkdir basedir 'parents))))
+ (make-directory basedir 'parents))))
(if (and ow (wfnames-ask-for-overwrite new))
;; Direct overwrite i.e. first loop.
(progn
@@ -300,21 +306,22 @@ With a numeric prefix ARG, revert the ARG next lines."
(wfnames-revert-current-line-1)
(when (eobp) (forward-line -1))
(goto-char (line-beginning-position))
- (while (re-search-forward "/" (line-end-position) t))))
+ (re-search-forward "\\(?:/[^/]*\\)*/" (line-end-position) t)))
(defun wfnames-revert-changes (_ignore-auto _no-confirm)
"Revert wfnames buffer to its initial state.
This is used as `revert-buffer-function' for `wfnames-mode'."
(with-current-buffer wfnames-buffer
- (cl-loop for o in (overlays-in (point-min) (point-max))
- when (overlay-get o 'hff-changed)
- do (delete-overlay o))
+ (dolist (o (overlays-in (point-min) (point-max)))
+ (when (overlay-get o 'hff-changed)
+ (delete-overlay o)))
(goto-char (point-min))
(save-excursion
(while (not (eobp))
(wfnames-revert-current-line-1)))
- (while (re-search-forward "/" (line-end-position) t))))
+ (re-search-forward "\\(?:/[^/]*\\)*/" (line-end-position) t)))
+
(provide 'wfnames)
[-- Attachment #3: Type: text/plain, Size: 11 bytes --]
> Thanks.
^ permalink raw reply related [relevance 45%]
* Re: Changes to make in elpa-packages file for nongnu elpa
@ 2023-08-07 13:30 92% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-08-07 13:30 UTC (permalink / raw)
To: Thierry Volpiatto; +Cc: emacs-devel
Thierry Volpiatto <thievol@posteo.net> writes:
> I see that Helm installation from nongnu elpa doesn't include
> emacs-helm.sh script, would it be possible to modify this?
>
> diff --git a/elpa-packages b/elpa-packages
> index 77d7a5409e..0923724b62 100644
> --- a/elpa-packages
> +++ b/elpa-packages
> @@ -312,11 +312,11 @@
> :ignored-files "COPYING")
>
> (helm :url "https://github.com/emacs-helm/helm"
> - :ignored-files ("images" "Cask" "Makefile" "emacs-helm.sh" "helm-core.el" "helm.el"
> + :ignored-files ("images" "Makefile" "helm-core.el" "helm.el"
> "helm-lib.el" "helm-source.el" "helm-multi-match.el"))
>
> (helm-core :url "https://github.com/emacs-helm/helm"
> - :ignored-files ("images" "Cask" "Makefile" "emacs-helm.sh" "helm-adaptive.el"
> + :ignored-files ("images" "Makefile" "emacs-helm.sh" "helm-adaptive.el"
> "helm-bookmark.el" "helm-buffers.el" "helm-color.el" "helm-comint.el"
> "helm-command.el" "helm-config.el" "helm-dabbrev.el" "helm-easymenu.el"
> "helm-elisp.el" "helm-elisp-package.el" "helm-epa.el" "helm-eshell.el"
There shouldn't be any issue in applying this patch, but could you
explain the propose of this script? I see something involving
straight.el, which is a package.el-incompatible package manager, at
which point I am confused why this should be distributed along with a
"package.el"-package.
> Also I asked here about a new dependency for Helm called wfnames and had
> no answer (2 times),
Sorry about that, you can always feel free to CC me if you have specific
questions that might get lost on the mailing list. I suppose Stefan
Monnier wouldn't object to be mentioned either.
> so I ask again differently now:
>
> When a package is available in Melpa do we have to add it in nongnu as
> well to satisfy dependencies for a package already in nongnu?
Yes, if the dependency is missing someone only using GNU ELPA and NonGNU
ELPA wouldn't be able to install the package due to a missing dependency
and that is obviously not intended.
> Thanks.
^ permalink raw reply [relevance 92%]
* Re: [External] : Re: Question about eval and compile-command
@ 2023-08-04 7:00 92% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-08-04 7:00 UTC (permalink / raw)
To: Andreas Schwab
Cc: Drew Adams, Stefan Monnier, Eli Zaretskii, Eshel Yaron,
emacs-devel@gnu.org
Andreas Schwab <schwab@linux-m68k.org> writes:
> On Aug 03 2023, Drew Adams wrote:
>
>>> > In retrospect, shouldn't the type be be a string or a function?
>>>
>>> Not a function, but a form.
>>
>> A string is a form too...
>
> But a function does not evaluate to a string.
I'll rephrase my comment to avoid confusion: "Instead of any accepting a
string, or any form (both of which are evaluated, which is not an issue
due to the fact that evaluation of strings is idempotent), it seems like
it would have been better if the expected type of `compile-command' were
either a string, that would be interpreted without any further
processing, or a function, that would be funcalled with the expectation
that it would return a string, which would be taken to be the compile
command."
^ permalink raw reply [relevance 92%]
* Re: Question about eval and compile-command
@ 2023-08-03 20:02 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-08-03 20:02 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Eli Zaretskii, Eshel Yaron, emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> It looks like Stefan added the 'eval' calls as a minor cleanup and not
>> as part of the change itself. Stefan, any chance you remember why you
>> added the 'eval' calls?
>
> I added it to allow the `compile-command` to be
> (re)computed dynamically.
In retrospect, shouldn't the type be be a string or a function? For
former for a static command, the latter for a dynamically computed one?
>
> Stefan
^ permalink raw reply [relevance 99%]
* Re: Proposal to include the Ef themes collection into Emacs core
@ 2023-08-03 19:36 91% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-08-03 19:36 UTC (permalink / raw)
To: Protesilaos Stavrou; +Cc: Zoltan Kiraly, emacs-devel
Protesilaos Stavrou <info@protesilaos.com> writes:
> Good day Zoltan and Philip,
>
>> From: Philip Kaludercic <philipk@posteo.net>
>> Date: Tue, 1 Aug 2023 08:22:43 +0000
>>
>> Zoltan Kiraly <zolikydev@gmail.com> writes:
>>
>>> Dear Emacs Development Team,
>>> I'm writing to bring your attention to an exceptional theme collection
>>> named "Ef Themes," created by Protesilaos Stavrou, the same author
>>> behind the Modus themes.
>>>
>>> Considering how well-received the Modus themes were and the positive
>>> response they received from the community, I'm confident that
>>> incorporating the "Ef Themes" collection into Emacs core would be of
>>> benefit to users. These themes offer an excellent choice for
>>> individuals who desire a more colorful Emacs environment while
>>> ensuring good readability.
>>
>> My main concern is that there are a lot of themes, which might be
>> overwhelming if they are all provided by default.
>
> I understand this point. There are lots of Ef themes as well.
>
>> The other question is what the concrete use is of having them bundled
>> in by default.
>
> I don't have a strong opinion about this. I guess the advantage is that
> it is easier for new users to discover more themes. The same argument
> can be made for all the non-essential---but still useful---parts that
> are built into Emacs.
What I had in mind specifically was to not overpopulate the M-x
customize-themes buffer, perhaps only because I can still recall that
this was one of the first things that I discovered when using Emacs.
When it comes to the discover-ability of themes, one could also imagine
adding a command like `package-list-themes' that would pop up a buffer
with packages that are themes.
>> I am not sure what the argumentation was when adding the Modus Themes
>> to the core, but I have to admit that I was not really a fan of adding
>> the new Modus Themes (-tinted, -tritanopia, -deuteranopia) to the core
>> as well, because of the above mentioned point of having too much
>> provided by default, which can cause choice paralysis.
>
> I asked before adding the new Modus variants. From my side, I would
> have added the new variants to the collection regardless. It was just a
> matter of whether core Emacs would have the same version as my Git
> repository which, I believe, is the norm.
>
> Generally though, the feeling of overwhelming options is not going away
> by reducing the number of themes (which is the right number, anyway?).
> Assuming this is the goal, concerted effort is needed across many parts
> of Emacs. For example, icomplete.el defines four minor modes and has to
> explain to new users what Fido is all about. I personally do not mind
> this state of affairs.
Again, I don't think it is necessarily the potential number of different
implementations or variations a component in Emacs provides.
>> Perhaps a compromise could be to limit the number of themes that are
>> added to three or four of the most popular ones.
>
> Maybe this works for other themes. Though when it comes to deuteranopia
> or tritanopia popularity will not be a reliable criterion.
Are you refering to ef-themes or modus-themes here?
> At any rate, we can take a look at the latest Emacs survey where there
> are many entries for the Ef themes that were not consolidated in a
> single bar: <https://emacssurvey.org/results/3425413930>. At the time
> of the survey, the Ef themes were only a few months old.
>
> [ I don't read too much into the survey data, though it is a point about
> "popularity". ]
>
>>> What makes the EF themes stand out is the awesome documentation,
>>> covering everything a user needs to know, and the fact that it is
>>> constantly updated and improved.
>>
>> IIRC EF Themes had fewer customisation options than Modus Themes, right?
>> Is this something that would interest the "average" user who, I would
>> guess usually is not that invested as to read the manual of a theme?
>
> Yes, the Ef themes have fewer options than the Modus themes. They still
> are customisable and the manual explains all the details. On the
> flip-side, the Ef themes may be less confusing to the kind of user you
> allude to here, because they look okay out-of-the-box, plus they cover a
> wide range of preferences.
>
>>> I kindly request you to consider evaluating the "Ef Themes" collection
>>> for potential integration into Emacs core. By embracing this
>>> collection, we can offer users a wider array of visually appealing
>>> options while upholding the high standards of Emacs.
>>
>> On a tangent, what I was planning to work on for Emacs 30 was to add
>> more "semantic" faces (along the lines of highlight, match, success,
>> ...). I had previously discussed the topic with Protesilaos (added in
>> the CC's), and I think his work on various themes is useful in
>> recognising common patterns in faces being defined in third-party faces
>> that make creating themes so cumbersome (because of all the explicit
>> support that has to be added for all the various known packages). I
>> reckon that ideally, a theme shouldn't have to concern itself with
>> specific packages.
>
> I agree and am happy to contribute towards that end. If you already
> have something, I am ready to contribute. Otherwise, we can discuss it
> whenever you want.
I hope to be able to come back to you on this soon, as soon as I have a
prototype.
> All the best,
> Protesilaos (or simply "Prot")
^ permalink raw reply [relevance 91%]
* Re: Adding adoc-mode (a major mode for working with AsciiDoc) to NonGNU ELPA
@ 2023-08-02 12:49 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-08-02 12:49 UTC (permalink / raw)
To: Bozhidar Batsov; +Cc: Emacs Devel
"Bozhidar Batsov" <bozhidar@batsov.net> writes:
> Hey there!
>
> I've taken up the maintenance of adoc-mode
> (https://github.com/bbatsov/adoc-mode) a while ago (see
> https://metaredux.com/posts/2023/03/12/adoc-mode-reborn.html) and I
> was wondering if we can include it in NonGNU ELPA. I think AsciiDoc is
> fairly popular, so it'd be nice if people can get a major mode for
> editing AsciiDoc documents without setting up additional repos. Any
> thoughts on this?
I think it would be nice, do you think there is a chance that it could
be added to GNU ELPA?
^ permalink raw reply [relevance 99%]
* Re: Proposal to include the Ef themes collection into Emacs core
@ 2023-08-01 8:22 76% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-08-01 8:22 UTC (permalink / raw)
To: Zoltan Kiraly; +Cc: emacs-devel, Protesilaos Stavrou
Zoltan Kiraly <zolikydev@gmail.com> writes:
> Dear Emacs Development Team,
> I'm writing to bring your attention to an exceptional theme collection
> named "Ef Themes," created by Protesilaos Stavrou, the same author
> behind the Modus themes.
>
> Considering how well-received the Modus themes were and the positive
> response they received from the community, I'm confident that
> incorporating the "Ef Themes" collection into Emacs core would be of
> benefit to users. These themes offer an excellent choice for
> individuals who desire a more colorful Emacs environment while
> ensuring good readability.
My main concern is that there are a lot of themes, which might be
overwhelming if they are all provided by default. The other question is
what the concrete use is of having them bundled in by default. I am not
sure what the argumentation was when adding the Modus Themes to the
core, but I have to admit that I was not really a fan of adding the new
Modus Themes (-tinted, -tritanopia, -deuteranopia) to the core as well,
because of the above mentioned point of having too much provided by
default, which can cause choice paralysis.
Perhaps a compromise could be to limit the number of themes that are
added to three or four of the most popular ones.
> What makes the EF themes stand out is the awesome documentation,
> covering everything a user needs to know, and the fact that it is
> constantly updated and improved.
IIRC EF Themes had fewer customisation options than Modus Themes, right?
Is this something that would interest the "average" user who, I would
guess usually is not that invested as to read the manual of a theme?
> I kindly request you to consider evaluating the "Ef Themes" collection
> for potential integration into Emacs core. By embracing this
> collection, we can offer users a wider array of visually appealing
> options while upholding the high standards of Emacs.
On a tangent, what I was planning to work on for Emacs 30 was to add
more "semantic" faces (along the lines of highlight, match, success,
...). I had previously discussed the topic with Protesilaos (added in
the CC's), and I think his work on various themes is useful in
recognising common patterns in faces being defined in third-party faces
that make creating themes so cumbersome (because of all the explicit
support that has to be added for all the various known packages). I
reckon that ideally, a theme shouldn't have to concern itself with
specific packages.
> https://github.com/protesilaos/ef-themes
>
>
> Thank you for your time and consideration.
>
> Best regards,
> Zoltan Kiraly
^ permalink raw reply [relevance 76%]
* Re: [ELPA] Proposing to add express to ELPA
@ 2023-08-01 8:07 63% ` Philip Kaludercic
1 sibling, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-08-01 8:07 UTC (permalink / raw)
To: Yuan Fu; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1245 bytes --]
Yuan Fu <casouri@gmail.com> writes:
> Hi all,
Hi,
> Since Emacs 29 is now released, I’d like to propose adding expreg to
> ELPA. Expreg can be considered a lite version of expand-region. The
> notable difference is its use of tree-sitter for language-specific
> expansions. I also took the liberty to do things differently than
> expand-region, eg, expreg uses a smaller number of expanders [1]; it
> is easier to debug when the expansion isn’t what you expected; and it
> only provides two functions for expansion and contraction, and one
> variable for adding/removing expanders—no transient maps and other
> “smart” features, nor different variables to set for each major mode.
>
> The obvious downsides is that, of course, it’s pretty useless on
> anything other than lisp if you don’t have tree-sitter grammars and
> major mode installed. You can use it in a non-tree-sitter major mode,
> as long the tree-sitter grammar exists. You only need to create a
> parser and expreg will automatically use the parser [2].
>
> I’ve been using it for months and ironed out all sorts of edge-cases, and can recommend it for daily usage.
this looks nice! I have a few comments that might be interesting:
[-- Attachment #2: Type: text/plain, Size: 3739 bytes --]
diff --git a/expreg.el b/expreg.el
index 05459af..2147ce8 100644
--- a/expreg.el
+++ b/expreg.el
@@ -1,6 +1,6 @@
;;; expreg.el --- Simple expand region -*- lexical-binding: t; -*-
-;; Copyright (C) 2022 Free Software Foundation, Inc.
+;; Copyright (C) 2022, 2023 Free Software Foundation, Inc.
;;
;; Author: Yuan Fu <casouri@gmail.com>
;; Maintainer: Yuan Fu <casouri@gmail.com>
@@ -79,8 +79,8 @@
(require 'subword)
(require 'treesit)
(eval-when-compile
- (require 'cl-lib)
- (require 'seq))
+ (require 'cl-lib))
+(require 'seq)
;;; Cutom options and variables
@@ -102,9 +102,9 @@ scan-error, like end-of-buffer, or unbalanced parentheses, etc.")
(defun expreg--sort-regions (regions)
"Sort REGIONS by their span."
- (cl-sort regions (lambda (a b)
- (< (- (cddr a) (cadr a))
- (- (cddr b) (cadr b))))))
+ (sort regions (lambda (a b)
+ (< (- (cddr a) (cadr a))
+ (- (cddr b) (cadr b))))))
(defvar expreg--validation-white-list '(list-at-point)
"Regions produced by functions in this list skips filtering.")
@@ -166,12 +166,11 @@ ORIG is the current position. Each region is (BEG . END)."
;; OTOH, if there are regions that ends at ORIG, filter out
;; regions that starts AFTER ORIGN, eg, special cases in
;; ‘expreg--list-at-point’.
- (setq regions (cl-remove-if
- (lambda (region)
- (and orig-at-end-of-something
- (> (cadr region) orig)))
- regions))
- regions))
+ (cl-remove-if
+ (lambda (region)
+ (and orig-at-end-of-something
+ (> (cadr region) orig)))
+ regions)))
;;; Syntax-ppss shorthands
@@ -199,7 +198,7 @@ POS defaults to point."
;;; Expand/contract
(defvar-local expreg--verbose nil
- "If t, print debugging information.")
+ "Non-nil means print debugging information.")
(defvar-local expreg--next-regions nil
"The regions we are going to expand to.
@@ -209,12 +208,13 @@ This should be a list of (BEG . END).")
"The regions we’ve expanded past.
This should be a list of (BEG . END).")
+;;;###autoload
(defun expreg-expand ()
"Expand region."
(interactive)
;; Checking for last-command isn’t strictly necessary, but nice to
;; have.
- (when (not (and (region-active-p)
+ (when (not (and (use-region-p)
(eq (region-beginning)
(cadr (car expreg--prev-regions)))
(eq (region-end)
@@ -236,7 +236,7 @@ This should be a list of (BEG . END).")
;; Go past all the regions that are smaller than the current region,
;; if region is active.
- (when (region-active-p)
+ (when (use-region-p)
(while (and expreg--next-regions
(let ((beg (cadr (car expreg--next-regions)))
(end (cddr (car expreg--next-regions))))
@@ -261,8 +261,8 @@ This should be a list of (BEG . END).")
(defun expreg-contract ()
"Contract region."
(interactive)
- (when (and (region-active-p)
- (> (length expreg--prev-regions) 1))
+ (when (and (use-region-p)
+ (length> expreg--prev-regions 1))
(push (pop expreg--prev-regions) expreg--next-regions)
(set-mark (cddr (car expreg--prev-regions)))
@@ -548,7 +548,7 @@ current string/comment and get lists inside."
(defun expreg--comment ()
"Return a list of regions containing comment."
(let ((orig (point))
- (beg (point))
+ (beg (point)) ;perhaps use narrowing?
(end (point))
result forward-succeeded trailing-comment-p)
[-- Attachment #3: Type: text/plain, Size: 1557 bytes --]
> You can find the repository here: https://github.com/casouri/expreg
> And I attached a patch for ELPA. It’s been awhile since I last made a
> patch for ELPA, I hope I did it right.
Looks OK.
> [1] Default expanders include: expreg--subword expreg--word expreg--list expreg--string expreg--treesit expreg--comment expreg--paragraph
>
> [2] Something like (add-hook 'xxx-mode-hook (lambda () (treesit-parser-create 'xxx)))
>
> PS. I find it amusing that, among the total 632 LOC, only 17 are
> responsible for the tree-sitter support, the main purpose of this
> package; all the rest are code dealing with correctly expanding lists,
> strings and comments with syntax-ppss.
>
> Thanks,
> Yuan
>
> From 7e201deb71f324e22d31331c06cf3999a105668b Mon Sep 17 00:00:00 2001
> From: Yuan Fu <casouri@gmail.com>
> Date: Mon, 31 Jul 2023 11:14:04 -0700
> Subject: [PATCH] * elpa-packages (expreg): New package.
>
> ---
> elpa-packages | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/elpa-packages b/elpa-packages
> index 48a0ada..e1470d5 100644
> --- a/elpa-packages
> +++ b/elpa-packages
> @@ -292,6 +292,7 @@
> :doc "doc/ess.texi")
> (excorporate :url nil)
> (expand-region :url "https://github.com/magnars/expand-region.el")
> + (expreg :url "https://github.com/casouri/expreg.git")
> (external-completion :core "lisp/external-completion.el")
> (exwm :url "https://github.com/ch11ng/exwm.git")
> (f90-interface-browser :url nil) ;; Was "https://github.com/wence-/f90-iface"
^ permalink raw reply related [relevance 63%]
* Re: Suggestion for package.el: atomic package-upgrade
@ 2023-08-01 7:32 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-08-01 7:32 UTC (permalink / raw)
To: Tegar Syahputra; +Cc: emacs-devel
Tegar Syahputra <dqs7cp2e@gmail.com> writes:
>>> The current `package-upgrade' from package.el delete old package
>>> before installing the new one. This can be problematic if the user
>>> interrupt the process or if there is some network problems.
>>>
>>> `package-install' allow the same package to be installed if the
>>> argument is `package-desc' instead symbol representing package name.
>>> This allow package to be upgraded atomically. Is this a bad idea?
>> No, I think this is a good idea, but it would be best if you could write
>> a Git patch and send it to "bug-gnu-emacs@gnu.org" (you can use M-x
>> submit-emacs-patch).
>
> I'm not part of FSF contributor, and wasn't really thinking of contributing
> directly. Just giving a heads up that's all.
So you are not interested in contributing a patch?
>>> diff -u --label \#\<buffer\ package.el.gz\> --label \#\<buffer\ \*scratch\*\> /tmp/buffer-content-4azQGZ /tmp/buffer-content-x8FLpt
>>> --- #<buffer package.el.gz>
>>> +++ #<buffer *scratch*>
>>> @@ -2275,16 +2275,20 @@
>>> package using this command, first upgrade the package to a
>>> newer version from ELPA by using `\\<package-menu-mode-map>\\[package-menu-mark-install]' after `\\[list-packages]'."
>>> (interactive
>>> - (list (completing-read
>>> - "Upgrade package: " (package--upgradeable-packages) nil t)))
>>> - (let* ((package (if (symbolp name)
>>> - name
>>> - (intern name)))
>>> - (pkg-desc (cadr (assq package package-alist))))
>>> - (if (package-vc-p pkg-desc)
>>> - (package-vc-upgrade pkg-desc)
>>> - (package-delete pkg-desc 'force 'dont-unselect)
>>> - (package-install package 'dont-select))))
>>> + (list (intern (completing-read
>>> + "Upgrade package: " (package--upgradeable-packages) nil t))))
>>> + (let* ((name (if (symbolp name)
>>> + name
>>> + (intern name)))
>> If you always intern the package name, you don't need this check
>> anymore. On the other hand, you don't need to intern the name, because
>> of this check, and I think it is better to keep it because that gives
>> the user more flexibility when invoking the function.
>
> I intern the interactive input because the actual type needed is
> symbol type.
> The check was from original, it accept both string and symbol.
Right, you kept the check (which I think is correct), which makes the
conversion unnecessary.
>>> + (old-pkg-desc (cadr (assq name package-alist)))
>>> + (new-pkg-desc (cadr (assq name package-archive-contents))))
>>> + (if (package-vc-p old-pkg-desc)
>>> + (package-vc-upgrade old-pkg-desc)
>>> + (unwind-protect
>> I am wondering if unwind-protect is the best approach here, or even
>> necessary. Wouldn't something like
>>
>> --8<---------------cut here---------------start------------->8---
>> (when (progn (package-install new-pkg-desc 'dont-select) t)
>> (package-delete old-pkg-desc 'force 'dont-unselect))
>> --8<---------------cut here---------------end--------------->8---
>
> No, you must check if the package is installed. That will always delete
> `old-pkg-desc' even if installation error occurs.
>
>> have the same effect? My reasoning is that we are not actually cleaning
>> anything up in the UNWIND-FORMS, but just checking if the
>> `package-install' was not interrupted, right?
>
> Yes, it's to check if the installations was interrupted or if error occur.
> I don't think `package-install' gives meaningful return that indicates
> package was properly installed. The output it gives could be used but,
> I just thought checking the output string may not be reliable or elegant.
Unless I am mistaken, package-install should raise a signal (ie. causing
a non-local exit). The return value of `package-install' is not
reliable, hence the (progn ... t).
>>> + (package-install new-pkg-desc 'dont-select)
>>> + (if (package-installed-p (package-desc-name new-pkg-desc)
>>> + (package-desc-version new-pkg-desc))
>> If you check the definition of `package-installed-p', you will find it
>> does not use MIN-VERSION if the first argument satisfied
>> `package-desc-p', which makes sense because with a concrete descriptor,
>> we can unambiguously check if a specific package version has been
>> installed (the implementation just checks if the expected directory
>> exists).
>
> Yeah, and new-pkg-desc which is a package-desc from package-archive-contents
> is implied to be remote thus doesn't include directory.
Right, my mistake.
> I'm OP, sorry I didn't configure my email name earlier.
^ permalink raw reply [relevance 99%]
* Re: Suggestion for package.el: atomic package-upgrade
@ 2023-07-31 6:45 79% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-07-31 6:45 UTC (permalink / raw)
To: dqs7cp2e; +Cc: emacs-devel
dqs7cp2e <dqs7cp2e@gmail.com> writes:
> The current `package-upgrade' from package.el delete old package
> before installing the new one. This can be problematic if the user
> interrupt the process or if there is some network problems.
>
> `package-install' allow the same package to be installed if the
> argument is `package-desc' instead symbol representing package name.
> This allow package to be upgraded atomically. Is this a bad idea?
No, I think this is a good idea, but it would be best if you could write
a Git patch and send it to "bug-gnu-emacs@gnu.org" (you can use M-x
submit-emacs-patch).
> diff -u --label \#\<buffer\ package.el.gz\> --label \#\<buffer\ \*scratch\*\> /tmp/buffer-content-4azQGZ /tmp/buffer-content-x8FLpt
> --- #<buffer package.el.gz>
> +++ #<buffer *scratch*>
> @@ -2275,16 +2275,20 @@
> package using this command, first upgrade the package to a
> newer version from ELPA by using `\\<package-menu-mode-map>\\[package-menu-mark-install]' after `\\[list-packages]'."
> (interactive
> - (list (completing-read
> - "Upgrade package: " (package--upgradeable-packages) nil t)))
> - (let* ((package (if (symbolp name)
> - name
> - (intern name)))
> - (pkg-desc (cadr (assq package package-alist))))
> - (if (package-vc-p pkg-desc)
> - (package-vc-upgrade pkg-desc)
> - (package-delete pkg-desc 'force 'dont-unselect)
> - (package-install package 'dont-select))))
> + (list (intern (completing-read
> + "Upgrade package: " (package--upgradeable-packages) nil t))))
> + (let* ((name (if (symbolp name)
> + name
> + (intern name)))
If you always intern the package name, you don't need this check
anymore. On the other hand, you don't need to intern the name, because
of this check, and I think it is better to keep it because that gives
the user more flexibility when invoking the function.
> + (old-pkg-desc (cadr (assq name package-alist)))
> + (new-pkg-desc (cadr (assq name package-archive-contents))))
> + (if (package-vc-p old-pkg-desc)
> + (package-vc-upgrade old-pkg-desc)
> + (unwind-protect
I am wondering if unwind-protect is the best approach here, or even
necessary. Wouldn't something like
--8<---------------cut here---------------start------------->8---
(when (progn (package-install new-pkg-desc 'dont-select) t)
(package-delete old-pkg-desc 'force 'dont-unselect))
--8<---------------cut here---------------end--------------->8---
have the same effect? My reasoning is that we are not actually cleaning
anything up in the UNWIND-FORMS, but just checking if the
`package-install' was not interrupted, right?
> + (package-install new-pkg-desc 'dont-select)
> + (if (package-installed-p (package-desc-name new-pkg-desc)
> + (package-desc-version new-pkg-desc))
If you check the definition of `package-installed-p', you will find it
does not use MIN-VERSION if the first argument satisfied
`package-desc-p', which makes sense because with a concrete descriptor,
we can unambiguously check if a specific package version has been
installed (the implementation just checks if the expected directory
exists).
Also, perhaps consider using `when' here. I argue that it looks better
in imperative code where the return-value is not of interest.
> + (package-delete old-pkg-desc 'force 'dont-unselect))))))
>
> (defun package--upgradeable-packages ()
> ;; Initialize the package system to get the list of package
>
> Diff finished. Mon Jul 31 08:22:46 2023
^ permalink raw reply [relevance 79%]
* Re: [elpa] externals/typo 88522ea4c8 1/2: Handle hash-tables with symbols as keys
@ 2023-07-22 14:10 87% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-07-22 14:10 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> Handle hash-tables with symbols as keys
>
> How 'bout
>
> (defun typo-edits (word collection pred)
> "Generate a list of all multi-edit typos of WORD.
> Only words that are in the COLLECTION and satisfy PRED will be
> returned. The variable `typo-level' specifies how many
> single-letter typos are searched."
> (seq-filter pred (all-completions "" collection)))
>
> Instead?
Isn't that the "identity" completion style? If anything, it would have
to be something like
--8<---------------cut here---------------start------------->8---
(defun typo-edits (word collection pred)
"Generate a list of all multi-edit typos of WORD.
Only words that are in the COLLECTION and satisfy PRED will be
returned. The variable `typo-level' specifies how many
single-letter typos are searched."
(let (completions)
(dolist (comp (all-completions "" collection))
(when (and (funcall pred comp) (typo--test word comp))
(push comp completions)))
completions))
--8<---------------cut here---------------end--------------->8---
IIRC I tried something like this at some point, but was not sure if
`all-completions' would re-use `completion-styles'. But looking at the
source code right now, it seems it would be safe, and the code seems to
work.
One potential issue, is PRED always non-nil?
> BTW, this is a good example of the problem with the `predicate` argument
> of `all-completions` (which can't be used here, because it gets called
> differently depending on the type of `collection`).
What would the issue be? I tried it out, and everything still seemed to
do the right thing.
> Stefan
^ permalink raw reply [relevance 87%]
* Re: [ELPA] New package: Peek
@ 2023-07-19 6:31 43% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-07-19 6:31 UTC (permalink / raw)
To: Meow King; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 311 bytes --]
Meow King <mr.meowking@anche.no> writes:
> I have created a new package ~Peek~, which allows users to create a peek
> view below/above cursor point to show things.
> I think it may be useful to others, so I propose it to GNU ELPA.
>
> Package URL: https://git.sr.ht/~meow_king/peek
Here are a few comments:
[-- Attachment #2: Type: text/plain, Size: 7152 bytes --]
diff --git a/peek.el b/peek.el
index 8e8e6f9..23c077c 100644
--- a/peek.el
+++ b/peek.el
@@ -48,6 +48,7 @@
(require 'display-line-numbers)
(require 'cl-lib)
(require 'xref)
+(require 'subr-x) ;for `hash-table-keys'
(defgroup peek nil
"Peek mode."
@@ -56,47 +57,39 @@
(defcustom peek-method 'overlay
"Preferred method to display peek view."
:type '(choice (const :tag "use overlay" overlay)
- (const :tag "use child frame" frame))
- :group 'peek)
+ (const :tag "use child frame" frame)))
(defcustom peek-overlay-position 'above
"Specify whether the overlay should be laid above the point or below the point."
:type '(choice (const :tag "above the point" above)
- (const :tag "below the point" below))
- :group 'peek)
+ (const :tag "below the point" below)))
(defcustom peek-overlay-distance 4
"Number of the lines between the peek overlay window and the point.
0 means directly above/below the current line."
- :type 'natnum
- :group 'peek)
+ :type 'natnum)
(defcustom peek-overlay-border-symbol ?\N{BOX DRAWINGS LIGHT HORIZONTAL}
"Specify symbol for peek overlay window border."
- :type 'character
- :group 'peek)
+ :type 'character)
(defcustom peek-clean-dead-overlays-secs 3600
"Every the given seconds to perform `peek-clean-dead-overlays' function."
- :type 'natnum
- :group 'peek)
+ :type 'natnum)
(defcustom peek-overlay-window-size 11
"Height of the peek overlay window. A value of 0 may cause undefined behavior."
- :type 'natnum
- :group 'peek)
+ :type 'natnum)
(defcustom peek-definition-surrounding-above-lines 1
"Number of Lines above the xref definition to be shown in peek view.
This value should be less than the
`peek-overlay-window-size', otherwise undefined behavior."
- :type 'natnum
- :group 'peek)
+ :type 'natnum)
(defcustom peek-live-update t
"Whether to automatically update content when text in marked region changes."
- :type 'boolean
- :group 'peek)
+ :type 'boolean)
(defcustom peek-mode-keymap
(let ((map (make-sparse-keymap)))
@@ -105,8 +98,7 @@ This value should be less than the
(define-key map (kbd "M-p") 'peek-prev-line)
map)
"Keymap used for peek mode."
- :type 'keymap
- :group 'typst)
+ :type 'keymap)
(defface peek-overlay-border-face
;; '((((background light))
@@ -114,37 +106,32 @@ This value should be less than the
;; (t
;; :inherit font-lock-doc-face :foreground "#ecf0f1"))
'((t (:inherit font-lock-doc-face)))
- "Face for borders of peek overlay window."
- :group 'peek)
+ "Face for borders of peek overlay window.")
(defface peek-overlay-content-face
'((((background light))
:background "#ecf0f1" :extend t)
(t
:background "#95a5a6" :extend t))
- "Additional face for content text of peek overlay window."
- :group 'peek)
+ "Additional face for content text of peek overlay window.")
(defcustom peek-enable-eldoc-message-integration nil
"Show eldoc message on a peek view.
Related function: `eldoc-message-function'."
- :type 'boolean
- :group 'peek)
+ :type 'boolean)
(defcustom peek-enable-eldoc-display-integration nil
"Show eldoc docs inside a peek view.
Note you need Emacs version >= 28.1.
Related function: `eldoc-display-functions'."
- :type 'boolean
- :group 'peek)
+ :type 'boolean)
(defcustom peek-eldoc-message-overlay-position 2
"Number of the lines between the peek eldoc message overlay window and the point.
0 means directly above the current line.
< 0 means above the current line;
> 0 means below the current line."
- :type 'integer
- :group 'peek)
+ :type 'integer)
(defvar-local peek-eldoc-message-overlay nil
"Special overlay for handling eldoc message.
@@ -165,6 +152,9 @@ the `global-peek-mode'.")
;; (make-hash-table :test 'equal) ;; we need to manually set hash table for each buffer, otherwise we always change its global value
"This variable shouldn't be customized by user.
Variable structure: { window: overlay }.")
+;; Shouldn't you document the variable, even if users aren't supposed
+;; to use it. Also, it is conventional to use a -- prefix for
+;; internal variables, e.g. `peek--window-overlay-map'.
(defvar-local peek-live-update-associated-overlays nil
"Associated overlays for this buffer.
@@ -288,6 +278,9 @@ WDW: window body width"
(let* ((window-body-width (if wdw
wdw
(window-body-width)))
+ ;; This approach seems to not work if the frame is resized.
+ ;; Perhaps you could take a similar approach like what
+ ;; `make-separator-line' does?
(total-column-number (if (display-graphic-p)
window-body-width
;; terminal Emacs will pad '\' at the line end
@@ -368,17 +361,15 @@ If WINDOW is nil, then show overlay in the current window."
(let ((ol (peek-get-window-overlay window)))
(peek-overlay--toggle-active ol)))
-(defun peek--regions-overlap (p1 p2 p3 p4)
+(defun peek--regions-overlap (r1s r1e r2s r2e)
"Detect whether the two region are overlapped.
The openness and closeness of the given regions should be the same as marker
region.
-region1: P1, P2; region2: P3, P4
+region1: R1S, R1E; region2: R2S, R2E
Return boolean."
- (if (or (< p2 p1) (< p4 p3))
+ (if (or (< r1e r1s) (< r2e r2s))
(error "P2 should >= p1, p4 should >= p3")
- (if (or (<= p4 p1) (<= p2 p3))
- nil
- t)))
+ (not (or (<= r2e r1s) (<= r1e r2s)))))
;;; =============================================================================
;;; Main Functions
@@ -433,8 +424,7 @@ Return nil if there is no region."
(me (make-marker)))
(set-marker mb rb (current-buffer))
(set-marker me re (current-buffer))
-
- (setq mark-active nil) ; deactivate region mark
+ (deactivate-mark)
(cons mb me))))
(defun peek-overlay--get-supposed-position ()
@@ -511,8 +501,15 @@ Return position."
(forward-line peek-eldoc-message-overlay-position)
(point)))
+(declare-function peek-display-eldoc "peek" (docs interactive))
+
;;;###autoload
(when (>= emacs-major-version 28)
+ ;; Are you sure you want to autoload the `when' expression? Unless
+ ;; I am mistaken, that means that this entire expression will be
+ ;; copied into the autoload file, which can cause warnings due to
+ ;; `eldoc--format-doc-buffer' or `peek-get-or-create-window-overlay'
+ ;; not being defined.
(defun peek-display-eldoc (docs interactive)
"Related function: `eldoc-display-functions'.
DOCS: docs passed by eldoc.
@@ -627,7 +624,7 @@ Only works when overlay is active/visible."
(string
(1- (length (overlay-get ol 'peek-lines))))
(definition
- 1.0e+INF) ; infinity
+ 1.0e+INF) ; infinity (why?)
(t
(error "Invalid peek-type!")))))
(overlay-put ol 'peek-offset (min (1+ offset) bound-max))
[-- Attachment #3: Type: text/plain, Size: 585 bytes --]
> ---
> More information:
>
> Some features of it:
> 1. Peek view follows your cursor.
> 2. Buffer and window local peek views. Also capable for content sharing between different buffer and windows.
> 3. Store text of marked region, and then display it on the peek view.
> 4. Peek the destination of ~xref-find-definitions~.
> 5. ~eldoc-message-function~ and ~eldoc-display-functions~ integration.
> 6. Scroll up or down inside peek view.
> 7. live update
I tried it out briefly, but did not figure out how to disable the
"peek". Perhaps you should rebind keyboard-quit to hide it?
^ permalink raw reply related [relevance 43%]
* Re: New branch feature/named-lambdas.
@ 2023-07-17 19:52 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-07-17 19:52 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: emacs-devel
Alan Mackenzie <acm@muc.de> writes:
> Hello, Emacs.
>
> I've just committed the first version of branch feature/named-lambdas.
>
> This will output the @dfn{defining symbol} of any anonymous functions in
> backtraces.
>
> For example, in
>
> (defun foo ()
> "foo doc string"
> (lambda (bar) "lambda doc string" (car bar)))
>
> M-: (funcall (foo) 'baz) will produce this backtrace:
>
> Debugger entered--Lisp error: (wrong-type-argument listp baz)
> car(baz)
> {foo} #f(compiled-function (bar) "lambda doc string" #<bytecode -0x105933d3d8452e4e>)(baz) <=============================
> funcall({foo} #f(compiled-function (bar) "lambda doc string" #<bytecode -0x105933d3d8452e4e>) baz)
> (progn (funcall (foo) 'baz))
> elisp--eval-last-sexp(nil)
> eval-last-sexp(nil)
> funcall-interactively(eval-last-sexp nil)
> command-execute(eval-last-sexp)
>
> .. Note the {foo} on the third and fourth lines. This is (usually) the
> defun where the lambda was defined, and is helpful in locating its
> source code.
>
> This was achieved by adding an extra defining-symbol field to each of
> the three forms of function (interpreted, byte-compiled,
> native-compiled). It is indended that this version of Emacs will
> continue to handle functions compiled without this enhancement.
I think the idea is nice, but there are a lot of whitespace changes in
your commit that make identifying the real changes a bit difficult.
^ permalink raw reply [relevance 99%]
* Re: Lisp reader syntax and bootstrap
@ 2023-07-15 5:18 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-07-15 5:18 UTC (permalink / raw)
To: Po Lu; +Cc: Richard Stallman, Paul Eggert, ulm, eliz, contovob, emacs-devel
Po Lu <luangruo@yahoo.com> writes:
> Richard Stallman <rms@gnu.org> writes:
>
>> Do you know of a machine where this would really happen?
>
> VAXen, of course, and possibly future machines that haven't been
> designed yet.
Floating point operations are regarded as optional (but conventional)
extensions by RISC-V.
> I think I overheard some of the NetBSD porters talking about this
> problem.
^ permalink raw reply [relevance 99%]
* Re: [elpa] elpa-admin 1d766451f8: Suggest `package-install' to install packages (bug#63800)
@ 2023-07-14 19:33 98% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-07-14 19:33 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Stefan Monnier, emacs-devel
Ihor Radchenko <yantar92@posteo.net> writes:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> Hmm, I don't like this change.
>> IMO, we should make this part of the page *smaller* rather than bigger.
>>...
>> So if we want in general to recommend users use `list-packages` rather
>> than `package-install`, let's just put something like:
>>
>> To install this from Emacs, use `M-x list-packages RET`
At which point I question the point of this advice in the first place.
> This might also work.
>
>> But this should be motivated by a preference, not by a bug (which we
>> should fix instead)
>
> There is no bug in Emacs here. Just on ELPA page providing instructions
> that are not working for :core packages.
I guess that is what is meant by "bug" here, but as the discussion a
while ago demonstrated, it is not obvious if we want to regard switching
from built-in packages to external packages as the same thing as
installing an external package.
>> .... , and not by something that only affects a tiny
>> minority of packages (otherwise, change the above code so it only
>> affects those very few packages).
>
> I could also put the `list-packages' suggestion behind check if the
> package is :core or not.
>
> P.S. Shouldn't this discussion be done in the original bug report thread?
^ permalink raw reply [relevance 98%]
* Re: [External] : Re: [elpa] main 2ec80977e1: * elpa-packages (dired-preview): New package
@ 2023-07-14 19:29 96% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-07-14 19:29 UTC (permalink / raw)
To: Drew Adams
Cc: Mattias Engdegård, Stefan Monnier, Protesilaos Stavrou,
emacs-devel@gnu.org
Drew Adams <drew.adams@oracle.com> writes:
> While on the subject of `dolist' versus `mapc',
> I'd add that code with `dolist' looks more like
> usual imperative programming constructs (e.g.,
> it looks like C or Fortran), and `mapc' looks,
> perhaps misleadingly, more like functional
> programming mapping over streams.
>
> IOW, IMO there's no great use case for `mapc'
> on a list, but I suppose maybe someone might
> find it clearer than `dolist' when used in a
> context where there's already some other
> mapping involved.
I rgrep'ed my own code and found this block I still find convenient,
because I don't have to come up with a name (even though `var' would
probably be a sufficiently good fit here, I guess):
--8<---------------cut here---------------start------------->8---
(mapc #'kill-local-variable
'(enable-local-variables
header-line-format
buffer-read-only))
--8<---------------cut here---------------end--------------->8---
^ permalink raw reply [relevance 96%]
* Re: Distribution statistics for ELPA and EMMS
@ 2023-07-14 7:03 96% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-07-14 7:03 UTC (permalink / raw)
To: Eduardo Ochs; +Cc: Yoni Rabkin, emacs-devel
Eduardo Ochs <eduardoochs@gmail.com> writes:
> On Thu, 13 Jul 2023 at 17:55, Yoni Rabkin <yoni@rabkins.net> wrote:
>>
>> I want to start the talk with the claim that Emms is a popular music and
>> video package for Emacs. However, I have absolutely no numbers or
>> statistics to back that claim. Is there a way to find out? Are any
>> statistics collected by ELPA?
>>
>> Is there a way to answer the question: how many times was Emms installed
>> in 2022?
>
> Hey, thanks for asking that!
>
> I'm the author of an Emacs package that is in ELPA and that I don't
> have any idea how many users it has - I mean, besides the ones that
> I've interacted with - and I was planning to start my talk about it
> in the next EmacsConf by saying that it has "at least 10 users"... =/
Then again, if you go by download counts like MELPA, you will severely
overestimate the number of users, since AFAIK they do not distinguish
between downloads and updates, nor do they know if someone just
installed a package and then immediately removed it.
There was some discussion about updating the protocol that package.el
uses, in which context thinking about some reliable yet privacy
preserving method of estimating the user count would be nice to have.
> Cheers =),
> Eduardo Ochs
> http://anggtwu.net/#eev
^ permalink raw reply [relevance 96%]
* Re: [elpa] main 2ec80977e1: * elpa-packages (dired-preview): New package
@ 2023-07-13 20:29 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-07-13 20:29 UTC (permalink / raw)
To: Protesilaos Stavrou; +Cc: Stefan Monnier, emacs-devel
Protesilaos Stavrou <info@protesilaos.com> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Date: Mon, 10 Jul 2023 18:29:23 +0000
>
>> [... 35 lines elided]
>
>> diff --git a/dired-preview.el b/dired-preview.el
>> index 853131b..b3517bd 100644
>> --- a/dired-preview.el
>> +++ b/dired-preview.el
>
>> [... 206 lines elided]
>
> Hello again Philip,
>
> I believe I pushed all the relevant changes you suggested. The only one
> I have not done yet is the 'dolist' VS 'mapc' that you and Stefan
> commented on. I need to understand the technical differences better, so
> as to know when to use 'mapc'.
Do you have any concrete questions? Semantically they should be
equivalent, it is just a matter of estimating the cost of a funcall and
of closures, which is why I suggest replacing (mapc (lambda (x) ... x
...) xs) with (dolist (x xs) ... x ...).
> All the best,
> Prot
^ permalink raw reply [relevance 99%]
* Re: NonGNU ELPA: add Logview
@ 2023-07-13 18:35 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-07-13 18:35 UTC (permalink / raw)
To: Bozhidar Batsov; +Cc: Paul Pogonyshev, Emacs Devel
"Bozhidar Batsov" <bozhidar@batsov.dev> writes:
> Just bumping this conversation, as we're still looking for someone to help us apply the patch.
I was still waiting for comments from other people, as I haven't had the
time to review the packages myself.
^ permalink raw reply [relevance 99%]
* Re: [elpa] main 2ec80977e1: * elpa-packages (dired-preview): New package
@ 2023-07-11 16:58 92% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-07-11 16:58 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Protesilaos Stavrou, emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> I saw 'rx' a couple of times. I find it harder to use than the strings.
>>> Though this is not a strong argument against it, I know.
>>
>> In this case, it would be
>>
>> --8<---------------cut here---------------start------------->8---
>> (rx "." (or "mkv" "webm" "mp4" "mp3" "ogg" "m4a"
>> "gz" "zst" "tar" "xz" "rar" "zip"
>> "iso" "epub" "pdf"))
>> --8<---------------cut here---------------end--------------->8---
>>
>> which seems fine to me? Fewer escape-sequences.
>>
>>>> "\\(mkv\\|webm\\|mp4\\|mp3\\|ogg\\|m4a"
>>>> "\\|gz\\|zst\\|tar\\|xz\\|rar\\|zip"
>>>> "\\|iso\\|epub\\|pdf\\)")
>>>> "Regular expression of file type extensions to not preview."
>>>> - :group 'dired-preview
>>>> :type 'string)
>
> BTW, you can most of the benefit here by using `regexp-opt` instead:
>
> (concat "\\."
> (regexp-opt "mkv" "webm" "mp4" "mp3" "ogg" "m4a"
> "gz" "zst" "tar" "xz" "rar" "zip"
> "iso" "epub" "pdf"))
Of course, modulo
--8<---------------cut here---------------start------------->8---
Debugger entered--Lisp error: (wrong-number-of-arguments (1 . 2) 15)
regexp-opt("mkv" "webm" "mp4" "mp3" "ogg" "m4a" "gz" "zst" "tar" "xz" "rar" "zip" "iso" "epub" "pdf")
(concat "\\." (regexp-opt "mkv" "webm" "mp4" "mp3" "ogg" "m4a" "gz" "zst" "tar" "xz" "rar" "zip" "iso" "epub" "pdf"))
elisp--eval-last-sexp(nil)
eval-last-sexp(nil)
funcall-interactively(eval-last-sexp nil)
command-execute(eval-last-sexp)
--8<---------------cut here---------------end--------------->8---
Obviously, one would just have to wrap the arguments in the list but
that together with the separate concat makes it less comfortable than
`rx' to me. But worth mentioning!
^ permalink raw reply [relevance 92%]
* Re: [elpa] main 2ec80977e1: * elpa-packages (dired-preview): New package
@ 2023-07-11 7:47 62% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-07-11 7:47 UTC (permalink / raw)
To: Protesilaos Stavrou; +Cc: Stefan Monnier, emacs-devel
Protesilaos Stavrou <info@protesilaos.com> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Date: Mon, 10 Jul 2023 18:29:23 +0000
>
> Hello Philip,
>
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>
>>>> --- a/elpa-packages
>>>> +++ b/elpa-packages
>>>> @@ -211,6 +211,10 @@
>>>> :ignored-files ("LICENSE"))
>>>> (dired-du :url nil)
>>>> (dired-git-info :url "https://github.com/clemera/dired-git-info")
>>>> + (dired-preview :url "https://git.sr.ht/~protesilaos/dired-preview"
>>>> + :doc "README.org"
>>>> + :readme "README.md"
>>>> + :ignored-files ("COPYING" "doclicense.texi"))
>>
>> Also, it would be nice if this list could be maintained in a .elpaignore
>> file.
>
> Yes, such a file make sense.
>
>>>> (disk-usage :url "https://gitlab.com/ambrevar/emacs-disk-usage")
>>>> (dismal :url nil)
>>>> (djvu :url nil)
>>>
>>> Isn't it odd to name your manual `README.org`?
>>> IOW to use the same name as for the "read me" file.
>>>
>>> I mean you avoid a name collision only by accident because the two
>>> happen to use different source formats and hence different extensions.
>>>
>>> Stefan
>>
>> Was there an announcement message regarding the package?
>
> No, sorry! I used to do those in the form of a question, not
> announcement. The answer was always the same about going ahead with the
> package, given that it conformed with the formalities. Plus, the
> maintainers are already too busy.
FWIW I am always glad to comment on packages before they are added, to
resolve low hanging issues before a package is published.
>> I am a bit surprised to see it being added without any discussion on
>> the list, perhaps something like this could have also been added to
>> the core?
>
> It is premature to add this in core. There is more that can be done
> with it and areas that can be greatly improved. Having it as a GNU ELPA
> package is easier at this early stage. Let's give it a minimum of six
> months.
I only bring this up, because I have found that frequently a lot of
features are more easily implemented in-core, where there is less of a
need for administrative boiler-plate code, and more flexibility when it
comes to changing other functions.
>> At the very least, it would be useful to gather some feedback
>> regarding the code:
>
> This is always welcome!
>
>> diff --git a/dired-preview.el b/dired-preview.el
>> index 853131b..b3517bd 100644
>
>> [... 13 lines elided]
>
> Can you please send these as a patch? That way your contribution is
> recorded by Git.
I don't have the changes anymore (beyond the diff), but I also don't
care about attribution. Pick and choose what you want to use.
>> @@ -57,24 +58,23 @@
>> ;;; Code:
>>
>> (require 'dired)
>> +(require 'seq)
>>
>> (defgroup dired-preview nil
>> "Automatically preview file at point in Dired."
>> :group 'dired)
>>
>> (defcustom dired-preview-ignored-extensions-regexp
>> - (concat "\\."
>> + (concat "\\." ;perhaps use `rx'?
>
> I saw 'rx' a couple of times. I find it harder to use than the strings.
> Though this is not a strong argument against it, I know.
In this case, it would be
--8<---------------cut here---------------start------------->8---
(rx "." (or "mkv" "webm" "mp4" "mp3" "ogg" "m4a"
"gz" "zst" "tar" "xz" "rar" "zip"
"iso" "epub" "pdf"))
--8<---------------cut here---------------end--------------->8---
which seems fine to me? Fewer escape-sequences.
>> "\\(mkv\\|webm\\|mp4\\|mp3\\|ogg\\|m4a"
>> "\\|gz\\|zst\\|tar\\|xz\\|rar\\|zip"
>> "\\|iso\\|epub\\|pdf\\)")
>> "Regular expression of file type extensions to not preview."
>> - :group 'dired-preview
>> :type 'string)
>
> I know the group is implicit, but I prefer to specify it. If we have a
> second group, we can then more easily differentiate it.
OK.
>> [... 21 lines elided]
>
>> (defvar dired-preview--buffers nil
>> "List with buffers of previewed files.")
>> @@ -99,9 +97,8 @@ details."
>> "Return buffers that show previews."
>> (seq-filter
>> (lambda (buffer)
>> - (when (and (bufferp buffer)
>> - (buffer-live-p buffer))
>> - buffer))
>> + (and (bufferp buffer)
>> + (buffer-live-p buffer)))
>> dired-preview--buffers))
>
> This is technically correct but more difficult to express intent.
The reason I proposed the change was that returning a value (especially
via `when') was /not/ correctly expressing the intent in my eyes. The
type of the first seq-filter argument is mentally something like "a ->
boolean", and `when' had a void or unit-type in my head.
But as Stephan said, this can be simplified even further to (seq-filter
#'buffer-live-p ...), which I think is even better.
>> (defun dired-preview--window-parameter-p (window)
>> @@ -120,26 +117,22 @@ until it drops below this number.")
>> (defun dired-preview--get-buffer-cumulative-size ()
>> "Return cumulative buffer size of `dired-preview--get-buffers'."
>> (let ((size 0))
>> - (mapc
>> - (lambda (buffer)
>> - (setq size (+ (buffer-size buffer) size)))
>> - (dired-preview--get-buffers))
>> + (dolist (buffer (dired-preview--get-buffers))
>> + (setq size (+ (buffer-size buffer) size)))
>> size))
>
> Since we are here, what is the technical advantage of dolist over mapc?
> I have searched the docs for a clarification, but have not found one. I
> get that it looks tidier, but is there a performance boost or something?
You can also compare the disassembled byte-code:
--8<---------------cut here---------------start------------->8---
(disassemble
(lambda (y f) (mapc (lambda (x) (funcall f x)) y)))
;; byte code:
;; doc: ...
;; args: (arg1 arg2)
;; 0 constant mapc
;; 1 constant make-closure
;; 2 constant <compiled-function>
;; doc: ...
;; args: (arg1)
;; 0 constant V0
;; 1 stack-ref 1
;; 2 call 1
;; 3 return
;; 3 stack-ref 3
;; 4 call 2
;; 5 stack-ref 3
;; 6 call 2
;; 7 return
(disassemble
(lambda (y f) (dolist (x y) (funcall f x))))
;; byte code:
;; doc: ...
;; args: (arg1 arg2)
;; 0 stack-ref 1
;; 1:1 dup
;; 2 goto-if-nil-else-pop 2
;; 5 dup
;; 6 car
;; 7 stack-ref 2
;; 8 stack-ref 1
;; 9 call 1
;; 10 discard
;; 11 stack-ref 1
;; 12 cdr
;; 13 discardN-preserve-tos 2
;; 15 goto 1
;; 18:2 return
(disassemble
(lambda (y f) (mapc f y)))
;; byte code:
;; doc: ...
;; args: (arg1 arg2)
;; 0 constant mapc
;; 1 stack-ref 1
;; 2 stack-ref 3
;; 3 call 2
;; 4 return
--8<---------------cut here---------------end--------------->8---
So unless you can make use of η-reduction, mapc incurs an overhead of
a funcall overhead for each element, but had an advantage in that
iteration happens in-core.
>> [... 42 lines elided]
>
>> @@ -167,8 +158,8 @@ See user option `dired-preview-ignored-extensions-regexp'."
>>
>> (defun dired-preview--file-displayed-p (file)
>> "Return non-nil if FILE is already displayed in a window."
>> - (when-let* ((buffer (get-file-buffer file))
>> - (window (get-buffer-window buffer)))
>> + (when-let ((buffer (get-file-buffer file))
>> + (window (get-buffer-window buffer)))
>> (window-live-p window)))
>
> Why remove the asterisk? I understand that it works, but this makes it
> more difficult to reason about the intent.
Because when-let* is not documented in (elisp) Conditionals, and the
official line is that using it should be avoided. There is no analogy
between when-let and when-let* as there is between let and let*, which
is perhaps more confusing.
>> (defun dired-preview--set-window-parameters (window value)
>> @@ -183,9 +174,9 @@ See user option `dired-preview-ignored-extensions-regexp'."
>> (cond
>> ((window-parameter (selected-window) 'dired-preview-window)
>> (dired-preview--delete-windows))
>> - ((and delay-mode-hooks (current-buffer))
>> + ((and delay-mode-hooks (current-buffer)) ;can `current-buffer' be nil
>
> This is probably the remnant of an earlier debugging session. If I
> recall the scenario, the file could be visited in another buffer, which
> would trigger the delayed-mode-hooks. It does not look good, I know.
>
>> (dired-preview--set-window-parameters (selected-window) nil)
>> - (apply #'run-hooks (delete-dups delayed-mode-hooks))
>> + (apply #'run-hooks (delete-dups delayed-mode-hooks)) ;why `delete-dups', which is destructive
>
> Again, the product of an earlier session. I had cases where a function
> was added twice and it would slow things down. I don't know how it was
> duplicated in the first place though.
>
>> (kill-local-variable 'delayed-mode-hooks)
>> (remove-hook 'post-command-hook #'dired-preview--run-mode-hooks :local))))
>>
>> @@ -206,19 +197,19 @@ See user option `dired-preview-ignored-extensions-regexp'."
>> "Add FILE to `dired-preview--buffers', if not already in a buffer.
>> Always return FILE buffer."
>> (let ((buffer (find-buffer-visiting file)))
>> - (if (buffer-live-p buffer)
>> - buffer
>> + (unless (buffer-live-p buffer)
>
> Technically correct, but more difficult to reason about. You can
> already see this more verbose pattern of mine.
I proposed this change, because otherwise it would seem like you would
be discarding the result of evaluating the if-expression.
>> (setq buffer (dired-preview--find-file-no-select file)))
>> (with-current-buffer buffer
>> (add-hook 'post-command-hook #'dired-preview--run-mode-hooks nil :local))
>> - (add-to-list 'dired-preview--buffers buffer)
>> + (unless (memq buffer dired-preview--buffers) ;or `cl-pushnew'
>> + (push buffer dired-preview--buffers))
>
> The change or cl-pushnew is fine.
>
>> buffer))
>>
>> (defun dired-preview--get-preview-buffer (file)
>> "Return buffer to preview FILE in."
>> (dired-preview--add-to-previews file))
>>
>> -(defvar dired-preview-buffer-name "*dired-preview*"
>> +(defconst dired-preview-buffer-name "*dired-preview*" ;unused?
>> "Name of preview buffer.")
>
> Yes, this should be deleted. It was used in earlier versions when the
> mode line would have a custom format.
>
>> (defun dired-preview-get-window-size (dimension)
>> @@ -235,9 +226,9 @@ checked against `split-width-threshold' or
>>
>> (defun dired-preview-display-action-side ()
>> "Pick a side window that is appropriate for the given frame."
>> - (if-let* ((width (window-body-width))
>> - ((>= width (window-body-height)))
>> - ((>= width split-width-threshold)))
>> + (if-let ((width (window-body-width))
>> + ((>= width (window-body-height)))
>> + ((>= width split-width-threshold)))
>> `(:side right :dimension window-width :size ,(dired-preview-get-window-size :width))
>> `(:side bottom :dimension window-height :size ,(dired-preview-get-window-size :height))))
>
> Same point as above about the asterisk.
Same point as above about the asterisk.
>> [... 18 lines elided]
>
>> @@ -341,7 +332,7 @@ the preview with `dired-preview-delay' of idleness."
>>
>> (defun dired-preview--on ()
>> "Enable `dired-preview-mode' in Dired."
>> - (when (eq major-mode 'dired-mode)
>> + (when (derived-mode-p 'dired-mode)
>> (dired-preview-mode 1)))
>>
>> ;;;###autoload
>
> I generally use this, though I wanted to be explicit in this case to
> avoid potential conflicts elsewhere. Where? I don't know. Just being
> cautious.
That would sound like a bug?
> All the best,
> Protesilaos (or simply "Prot")
^ permalink raw reply [relevance 62%]
* Re: Stability of project.el
@ 2023-07-11 5:26 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-07-11 5:26 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: emacs-devel
Dmitry Gutov <dmitry@gutov.dev> writes:
> Hi Philip,
>
> On 10/07/2023 21:53, Philip Kaludercic wrote:
>> The commentary section for project.el still begins with
>> --8<---------------cut here---------------start------------->8---
>> ;; NOTE: The project API is still experimental and can change in major,
>> ;; backward-incompatible ways. Everyone is encouraged to try it, and
>> ;; report to us any problems or use cases we hadn't anticipated, by
>> ;; sending an email to emacs-devel, or `M-x report-emacs-bug'.
>> --8<---------------cut here---------------end--------------->8---
>> Is this still true, or would it be warranted to remove it just like
>> we
>> did for Xref a few years ago (9a15694a45), perhaps even in time for
>> Emacs 29?
>
> I think that's a good idea. Even if there still some less-than-ideal
> bits, we need to maintain it backward-compatibly, given the age.
Great. Should the major version number also be bumped?
> And documentation-only changes should still be good for Emacs 29.
Eli, what do you say?
^ permalink raw reply [relevance 99%]
* Stability of project.el
@ 2023-07-10 18:53 96% Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-07-10 18:53 UTC (permalink / raw)
To: emacs-devel; +Cc: Dmitry Gutov
The commentary section for project.el still begins with
--8<---------------cut here---------------start------------->8---
;; NOTE: The project API is still experimental and can change in major,
;; backward-incompatible ways. Everyone is encouraged to try it, and
;; report to us any problems or use cases we hadn't anticipated, by
;; sending an email to emacs-devel, or `M-x report-emacs-bug'.
--8<---------------cut here---------------end--------------->8---
Is this still true, or would it be warranted to remove it just like we
did for Xref a few years ago (9a15694a45), perhaps even in time for
Emacs 29?
^ permalink raw reply [relevance 96%]
* Re: [elpa] main 2ec80977e1: * elpa-packages (dired-preview): New package
@ 2023-07-10 18:29 39% ` Philip Kaludercic
0 siblings, 2 replies; 200+ results
From: Philip Kaludercic @ 2023-07-10 18:29 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Protesilaos Stavrou, emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1184 bytes --]
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> --- a/elpa-packages
>> +++ b/elpa-packages
>> @@ -211,6 +211,10 @@
>> :ignored-files ("LICENSE"))
>> (dired-du :url nil)
>> (dired-git-info :url "https://github.com/clemera/dired-git-info")
>> + (dired-preview :url "https://git.sr.ht/~protesilaos/dired-preview"
>> + :doc "README.org"
>> + :readme "README.md"
>> + :ignored-files ("COPYING" "doclicense.texi"))
Also, it would be nice if this list could be maintained in a .elpaignore
file.
>> (disk-usage :url "https://gitlab.com/ambrevar/emacs-disk-usage")
>> (dismal :url nil)
>> (djvu :url nil)
>
> Isn't it odd to name your manual `README.org`?
> IOW to use the same name as for the "read me" file.
>
> I mean you avoid a name collision only by accident because the two
> happen to use different source formats and hence different extensions.
>
> Stefan
Was there an announcement message regarding the package? I am a bit
surprised to see it being added without any discussion on the list,
perhaps something like this could have also been added to the core? At
the very least, it would be useful to gather some feedback regarding the
code:
[-- Attachment #2: Type: text/plain, Size: 8125 bytes --]
diff --git a/dired-preview.el b/dired-preview.el
index 853131b..b3517bd 100644
--- a/dired-preview.el
+++ b/dired-preview.el
@@ -3,8 +3,9 @@
;; Copyright (C) 2023 Free Software Foundation, Inc.
;; Author: Protesilaos Stavrou <info@protesilaos.com>
+;; Maintainer: Protesilaos Stavrou <~protesilaos/general-issues@lists.sr.ht>
;; URL: https://git.sr.ht/~protesilaos/dired-preview
-;; Mailing-List: https://lists.sr.ht/~protesilaos/general-issues
+;; Mailing-List: https://lists.sr.ht/~protesilaos/general-issues
;; Version: 0.1.1
;; Package-Requires: ((emacs "27.1"))
;; Keywords: files, convenience
@@ -57,24 +58,23 @@
;;; Code:
(require 'dired)
+(require 'seq)
(defgroup dired-preview nil
"Automatically preview file at point in Dired."
:group 'dired)
(defcustom dired-preview-ignored-extensions-regexp
- (concat "\\."
+ (concat "\\." ;perhaps use `rx'?
"\\(mkv\\|webm\\|mp4\\|mp3\\|ogg\\|m4a"
"\\|gz\\|zst\\|tar\\|xz\\|rar\\|zip"
"\\|iso\\|epub\\|pdf\\)")
"Regular expression of file type extensions to not preview."
- :group 'dired-preview
:type 'string)
(defcustom dired-preview-max-size (expt 2 20)
"Files larger than this byte limit are not previewed."
- :group 'dired-preview
- :type 'integer)
+ :type 'natnum)
(defcustom dired-preview-display-action-alist-function
#'dired-preview-display-action-alist-dwim
@@ -84,13 +84,11 @@ Read Info node `(elisp) Displaying Buffers'. As such, it is
meant for experienced users. See the reference function
`dired-preview-display-action-alist-dwim' for the implementation
details."
- :group 'dired-preview
:type 'function)
(defcustom dired-preview-delay 0.7
"Time in seconds to wait before previewing."
- :group 'dired-preview
- :type 'float)
+ :type 'number)
(defvar dired-preview--buffers nil
"List with buffers of previewed files.")
@@ -99,9 +97,8 @@ details."
"Return buffers that show previews."
(seq-filter
(lambda (buffer)
- (when (and (bufferp buffer)
- (buffer-live-p buffer))
- buffer))
+ (and (bufferp buffer)
+ (buffer-live-p buffer)))
dired-preview--buffers))
(defun dired-preview--window-parameter-p (window)
@@ -120,26 +117,22 @@ until it drops below this number.")
(defun dired-preview--get-buffer-cumulative-size ()
"Return cumulative buffer size of `dired-preview--get-buffers'."
(let ((size 0))
- (mapc
- (lambda (buffer)
- (setq size (+ (buffer-size buffer) size)))
- (dired-preview--get-buffers))
+ (dolist (buffer (dired-preview--get-buffers))
+ (setq size (+ (buffer-size buffer) size)))
size))
(defun dired-preview--kill-buffers ()
"Kill preview buffers up to `dired-preview--buffers-threshold'."
(let ((buffers (nreverse (dired-preview--get-buffers))))
(catch 'stop
- (mapc
- (lambda (buffer)
- (if (and (>= (dired-preview--get-buffer-cumulative-size)
- dired-preview--buffers-threshold))
- (when (and (buffer-local-value 'delayed-mode-hooks buffer)
- (not (eq buffer (current-buffer))))
- (ignore-errors (kill-buffer-if-not-modified buffer))
- (setq buffers (delq buffer buffers)))
- (throw 'stop t)))
- buffers))
+ (dolist (buffer buffers)
+ (if (and (>= (dired-preview--get-buffer-cumulative-size)
+ dired-preview--buffers-threshold))
+ (when (and (buffer-local-value 'delayed-mode-hooks buffer)
+ (not (eq buffer (current-buffer))))
+ (ignore-errors (kill-buffer-if-not-modified buffer))
+ (setq buffers (delq buffer buffers)))
+ (throw 'stop t))))
(setq dired-preview--buffers (delq nil (nreverse buffers)))))
(defun dired-preview--get-windows ()
@@ -148,12 +141,10 @@ until it drops below this number.")
(defun dired-preview--delete-windows ()
"Delete preview windows."
- (mapc
- (lambda (window)
- (unless (or (one-window-p)
- (eq window (minibuffer-window)))
- (delete-window window)))
- (dired-preview--get-windows)))
+ (dolist (window (dired-preview--get-windows))
+ (unless (or (one-window-p)
+ (eq window (minibuffer-window)))
+ (delete-window window))))
(defun dired-preview--file-ignored-p (file)
"Return non-nil if FILE extension is among the ignored extensions.
@@ -167,8 +158,8 @@ See user option `dired-preview-ignored-extensions-regexp'."
(defun dired-preview--file-displayed-p (file)
"Return non-nil if FILE is already displayed in a window."
- (when-let* ((buffer (get-file-buffer file))
- (window (get-buffer-window buffer)))
+ (when-let ((buffer (get-file-buffer file))
+ (window (get-buffer-window buffer)))
(window-live-p window)))
(defun dired-preview--set-window-parameters (window value)
@@ -183,9 +174,9 @@ See user option `dired-preview-ignored-extensions-regexp'."
(cond
((window-parameter (selected-window) 'dired-preview-window)
(dired-preview--delete-windows))
- ((and delay-mode-hooks (current-buffer))
+ ((and delay-mode-hooks (current-buffer)) ;can `current-buffer' be nil
(dired-preview--set-window-parameters (selected-window) nil)
- (apply #'run-hooks (delete-dups delayed-mode-hooks))
+ (apply #'run-hooks (delete-dups delayed-mode-hooks)) ;why `delete-dups', which is destructive
(kill-local-variable 'delayed-mode-hooks)
(remove-hook 'post-command-hook #'dired-preview--run-mode-hooks :local))))
@@ -206,19 +197,19 @@ See user option `dired-preview-ignored-extensions-regexp'."
"Add FILE to `dired-preview--buffers', if not already in a buffer.
Always return FILE buffer."
(let ((buffer (find-buffer-visiting file)))
- (if (buffer-live-p buffer)
- buffer
+ (unless (buffer-live-p buffer)
(setq buffer (dired-preview--find-file-no-select file)))
(with-current-buffer buffer
(add-hook 'post-command-hook #'dired-preview--run-mode-hooks nil :local))
- (add-to-list 'dired-preview--buffers buffer)
+ (unless (memq buffer dired-preview--buffers) ;or `cl-pushnew'
+ (push buffer dired-preview--buffers))
buffer))
(defun dired-preview--get-preview-buffer (file)
"Return buffer to preview FILE in."
(dired-preview--add-to-previews file))
-(defvar dired-preview-buffer-name "*dired-preview*"
+(defconst dired-preview-buffer-name "*dired-preview*" ;unused?
"Name of preview buffer.")
(defun dired-preview-get-window-size (dimension)
@@ -235,9 +226,9 @@ checked against `split-width-threshold' or
(defun dired-preview-display-action-side ()
"Pick a side window that is appropriate for the given frame."
- (if-let* ((width (window-body-width))
- ((>= width (window-body-height)))
- ((>= width split-width-threshold)))
+ (if-let ((width (window-body-width))
+ ((>= width (window-body-height)))
+ ((>= width split-width-threshold)))
`(:side right :dimension window-width :size ,(dired-preview-get-window-size :width))
`(:side bottom :dimension window-height :size ,(dired-preview-get-window-size :height))))
@@ -320,14 +311,14 @@ the preview with `dired-preview-delay' of idleness."
(defun dired-preview-disable-preview ()
"Disable Dired preview."
(unless (eq major-mode 'dired-mode)
- (error "Can only use `dired-preview' in Dired"))
+ (user-error "Can only use `dired-preview' in Dired"))
(remove-hook 'post-command-hook #'dired-preview-trigger :local)
(dired-preview--close-previews))
(defun dired-preview-enable-preview ()
"Enable Dired preview."
(unless (eq major-mode 'dired-mode)
- (error "Can only use `dired-preview' in Dired"))
+ (user-error "Can only use `dired-preview' in Dired"))
(add-hook 'post-command-hook #'dired-preview-trigger nil :local)
(dired-preview-trigger :no-delay))
@@ -341,7 +332,7 @@ the preview with `dired-preview-delay' of idleness."
(defun dired-preview--on ()
"Enable `dired-preview-mode' in Dired."
- (when (eq major-mode 'dired-mode)
+ (when (derived-mode-p 'dired-mode)
(dired-preview-mode 1)))
;;;###autoload
^ permalink raw reply related [relevance 39%]
* Re: Use radix-tree for string arrays
@ 2023-07-06 18:50 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-07-06 18:50 UTC (permalink / raw)
To: Yuchen Pei; +Cc: Emacs Devel mailing list
Yuchen Pei <id@ypei.org> writes:
> On Wed 2023-07-05 16:47:38 +0000, Philip Kaludercic wrote:
>
>> Yuchen Pei <id@ypei.org> writes:
>>
>>> @@ -1,6 +1,6 @@
>>> ;;; radix-tree.el --- A simple library of radix trees -*-
>>> lexical-binding: t; -*-
>>>
>>> -;; Copyright (C) 2016-2023 Free Software Foundation, Inc.
>>> +;; Copyright (C) 2016-2022 Free Software Foundation, Inc.
>>
>> I suppose this edit was not intentional?
>
> It's not. It's because I modified emacs 28.2, the version I use, and
> diffed against master.
In that case I can recommend using copyright-update. I have this block
in my init.el:
(setopt copyright-names-regexp
(regexp-opt '("Free Software Foundation, Inc."
"<your name here>")))
(add-hook 'before-save-hook #'copyright-update)
> Best,
> Yuchen
^ permalink raw reply [relevance 99%]
* Re: NonGNU ELPA: add Logview
@ 2023-07-06 17:59 85% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-07-06 17:59 UTC (permalink / raw)
To: Paul Pogonyshev; +Cc: Emacs developers, bozhidar
"Bozhidar Batsov" <bozhidar@batsov.dev> writes:
> Thanks for putting the patch together so quickly!
>
> Phillip, can you help us to get it applied?
Applying the patch is not the issue, I am just personally hesitant to
add a bunch of dependencies/packages I have never heard about before,
more so because I don't use CIDER, /especially/ when I lack the time to
properly review them (the argument that a package is "mature on MELPA"
is rather weak from my experience, especially given the number of low
quality packages on the archive).
Without understanding the issue properly, why is there a need for an
external data-time parsing package, if Emacs already comes with
functions for parsing timestamps? It appears to use use this extmap
package, which parses binary data? How is this all related to CIDER?
But perhaps I am in a minority here, and we should just apply the patch.
> On Thu, Jul 6, 2023, at 7:14 PM, Paul Pogonyshev wrote:
>> Hi,
>>
>> Bozhidar Batsov, author and maintainer of CIDER, requested for
>> package Logview to be made available on NonGNU ELPA:
>> https://github.com/clojure-emacs/cider/issues/3365
>>
>> Since Logview has two dependencies itself, which are not available
>> on NonGNU ELPA, and since Bozhidar assured me that it is fine to
>> submit multiple packages in one go, the attached patch adds all
>> three (Logview, datetime, extmap) at once. Local checks suggest that
>> the packages can be built fine.
I am a bit confused, why should adding multiple related packages in a
single patch be an issue?
>> All the packages have been available from MELPA for years and are
>> mature projects. They are under active maintenance: even if I don't
>> often add new features, I respond to reported issues on GitHub and
>> write fixes when needed.
>>
>> I added directory `githooks' to the lists of exclusions even if it
>> doesn't yet exist in the dependencies: I will add it there sooner or
>> later anyway. In Logview itself this directory already exists.
If possible, please add ".elpaignore" files to the repositories
themselves, so that we can void tracking the files in elpa-packages
itself.
>> Please CC me on any replies, I'm not subscribed to the list.
That is a given, don't worry about it.
>> Paul
>>
>> *Attachments:*
>> • 0001-Add-Logview-with-dependencies.patch
^ permalink raw reply [relevance 85%]
* Re: Use radix-tree for string arrays
@ 2023-07-05 16:47 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-07-05 16:47 UTC (permalink / raw)
To: Yuchen Pei; +Cc: Emacs Devel mailing list
Yuchen Pei <id@ypei.org> writes:
> @@ -1,6 +1,6 @@
> ;;; radix-tree.el --- A simple library of radix trees -*- lexical-binding: t; -*-
>
> -;; Copyright (C) 2016-2023 Free Software Foundation, Inc.
> +;; Copyright (C) 2016-2022 Free Software Foundation, Inc.
I suppose this edit was not intentional?
^ permalink raw reply [relevance 99%]
* Setting 'vc-default-patch-addressee' in .dir-locals.el
@ 2023-06-25 11:32 86% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-06-25 11:32 UTC (permalink / raw)
To: Sean Whitton; +Cc: Konstantin Kharlamov, Eli Zaretskii, ams, emacs-devel
[-- Attachment #1: Type: text/plain, Size: 866 bytes --]
Sean Whitton <spwhitton@spwhitton.name> writes:
> Hello,
>
> On Sat 24 Jun 2023 at 03:37PM GMT, Philip Kaludercic wrote:
>
>> Sean Whitton <spwhitton@spwhitton.name> writes:
>>
>>> Hello,
>>>
>>> On Sun 18 Jun 2023 at 10:22AM GMT, Philip Kaludercic wrote:
>>>
>>>> One idea (but I don't know if this is practicable), is to use the
>>>> configure script to set up Git's `sendemail.to' option or to add
>>>> `vc-default-patch-addressee' to .dir-locals.el.
>>>
>>> I thought we were going to do that anyway, just as soon as enough time
>>> had passed that people are not going to get unsafe local variable
>>> popups?
>>
>> That was (is?) the plan, but I guess it was just delayed because people
>> on older versions got irritated by the unsafe variable warnings, and
>> then everyone forgot.
>
> Let's go ahead now?
Does anyone have any objections against applying
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Set-vc-default-patch-addressee-in-.dir-locals.el.patch --]
[-- Type: text/x-diff, Size: 1040 bytes --]
From 08832036be2ed3df0cc4640a74dc11a646d77e7a Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Sun, 25 Jun 2023 13:31:28 +0200
Subject: [PATCH] Set vc-default-patch-addressee in .dir-locals.el
* .dir-locals.el: Set it to "bug-gnu-emacs@gnu.org".
---
.dir-locals.el | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/.dir-locals.el b/.dir-locals.el
index 0bcded4b5d1..7e0fc02dd16 100644
--- a/.dir-locals.el
+++ b/.dir-locals.el
@@ -8,7 +8,8 @@
(vc-git-annotate-switches . "-w")
(bug-reference-url-format . "https://debbugs.gnu.org/%s")
(diff-add-log-use-relative-names . t)
- (vc-prepare-patches-separately . nil)))
+ (vc-prepare-patches-separately . nil)
+ (vc-default-patch-addressee . "bug-gnu-emacs@gnu.org")))
(c-mode . ((c-file-style . "GNU")
(c-noise-macro-names . ("INLINE" "NO_INLINE" "ATTRIBUTE_NO_SANITIZE_UNDEFINED"
"UNINIT" "CALLBACK" "ALIGN_STACK" "ATTRIBUTE_MALLOC"
--
2.39.2
[-- Attachment #3: Type: text/plain, Size: 37 bytes --]
on Emacs 29?
--
Philip Kaludercic
^ permalink raw reply related [relevance 86%]
* Re: contributing to Emacs
@ 2023-06-24 15:37 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-06-24 15:37 UTC (permalink / raw)
To: Sean Whitton; +Cc: Konstantin Kharlamov, Eli Zaretskii, ams, emacs-devel
Sean Whitton <spwhitton@spwhitton.name> writes:
> Hello,
>
> On Sun 18 Jun 2023 at 10:22AM GMT, Philip Kaludercic wrote:
>
>> One idea (but I don't know if this is practicable), is to use the
>> configure script to set up Git's `sendemail.to' option or to add
>> `vc-default-patch-addressee' to .dir-locals.el.
>
> I thought we were going to do that anyway, just as soon as enough time
> had passed that people are not going to get unsafe local variable
> popups?
That was (is?) the plan, but I guess it was just delayed because people
on older versions got irritated by the unsafe variable warnings, and
then everyone forgot.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: contributing to Emacs
@ 2023-06-22 7:47 92% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-06-22 7:47 UTC (permalink / raw)
To: Po Lu; +Cc: Richard Stallman, ams, hi-angel, eliz, arne_bab, emacs-devel
Po Lu <luangruo@yahoo.com> writes:
> Richard Stallman <rms@gnu.org> writes:
>
>> I dom't think that is necessarily so bad.
>
> It is: look at XEmacs, and the waste it led to.
I think we have to distinguish between a diverging fork like XEmacs and
a "parallel" fork, that aims to preserve mutual compatibility. In the
former case, the two projects will find it more and more difficult over
time to share code, while in the latter is just a question of
organisation and administration, that doesn't matter that much to the
user.
>> Could you show me the actual proposal that was made?
>
> I suggest reading the first article in this thread. Namely, this:
>
>> . currently, we have a single developer who understands the
>> specifics of the Android port and works on developing it; it is
>> not good for Emacs to depend on a single individual for a port
>> that should be kept alive and up-to-date for the observable future
>
>> Various messages seem to say that the code that has been written is
>> only partial support for Emacs on Android -- that some important
>> features are not yet implemented.
>
> Would you please show me any of those messages? I've been unequivocally
> clear on this point: the port has already been completed (and was as far
> back as April.)
I recall reading that GNUTLS was not supported on Android, making it
difficult to fetch packages from ELPA. Has this been addressed? I
would have looked it up myself, but I don't know where to begin.
^ permalink raw reply [relevance 92%]
* Re: contributing to Emacs
@ 2023-06-18 10:22 96% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-06-18 10:22 UTC (permalink / raw)
To: Konstantin Kharlamov; +Cc: Eli Zaretskii, ams, emacs-devel
Konstantin Kharlamov <hi-angel@yandex.ru> writes:
> On Sun, 2023-06-18 at 10:00 +0000, Philip Kaludercic wrote:
>> Konstantin Kharlamov <hi-angel@yandex.ru> writes:
>>
>> > On Sun, 2023-06-18 at 08:20 +0300, Eli Zaretskii wrote:
>> > > > From: Konstantin Kharlamov <hi-angel@yandex.ru>
>> > > > Cc: eliz@gnu.org, arne_bab@web.de, luangruo@yahoo.com,
>> > > > emacs-devel@gnu.org
>> > > > Date: Sun, 18 Jun 2023 01:39:17 +0300
>> > > >
>> > > > No. I measured specifically for you: "Sending Patches" alone is 5884
>> > > > characters
>> > > > not counting bullets, and my email was 3491 characters.
>> > >
>> > > When someone posts a patch, he or she is not requested to read that
>> > > section, let alone pass some kind of exam on being familiar with it.
>> > > I'm quite sure 99% of contributors don't even know that section exists
>> > > in the manual, and have never read it. So the size of that node is
>> > > utterly irrelevant to how hard it is to contribute to Emacs.
>> >
>> > You can't send a patch if you don't know how and where to send it 😊 So you
>> > can't avoid reading that section.
>>
>> I think `submit-emacs-patch' is supposed to help here.
>
> You would need to know it exists.
True, but that can be fixed.
>> But I don't get how this is a Emacs/ML specific issue?
>
> We are discussing possible improvement to Emacs-specific contributing workflow.
My point is that this is an issue that all projects have in some sense
or another. You always have to find out how they work, and what you
need to do to submit a patch.
One idea (but I don't know if this is practicable), is to use the
configure script to set up Git's `sendemail.to' option or to add
`vc-default-patch-addressee' to .dir-locals.el.
--
Philip Kaludercic
^ permalink raw reply [relevance 96%]
* Re: contributing to Emacs
@ 2023-06-18 10:00 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-06-18 10:00 UTC (permalink / raw)
To: Konstantin Kharlamov; +Cc: Eli Zaretskii, ams, emacs-devel
Konstantin Kharlamov <hi-angel@yandex.ru> writes:
> On Sun, 2023-06-18 at 08:20 +0300, Eli Zaretskii wrote:
>> > From: Konstantin Kharlamov <hi-angel@yandex.ru>
>> > Cc: eliz@gnu.org, arne_bab@web.de, luangruo@yahoo.com, emacs-devel@gnu.org
>> > Date: Sun, 18 Jun 2023 01:39:17 +0300
>> >
>> > No. I measured specifically for you: "Sending Patches" alone is 5884
>> > characters
>> > not counting bullets, and my email was 3491 characters.
>>
>> When someone posts a patch, he or she is not requested to read that
>> section, let alone pass some kind of exam on being familiar with it.
>> I'm quite sure 99% of contributors don't even know that section exists
>> in the manual, and have never read it. So the size of that node is
>> utterly irrelevant to how hard it is to contribute to Emacs.
>
> You can't send a patch if you don't know how and where to send it 😊 So you
> can't avoid reading that section.
I think `submit-emacs-patch' is supposed to help here. But I don't get
how this is a Emacs/ML specific issue?
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Suggestion: Make cperl-mode.el an ELPA :core package
@ 2023-06-18 8:51 91% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-06-18 8:51 UTC (permalink / raw)
To: Harald Jörg; +Cc: Emacs Developer List
Harald Jörg <haj@posteo.de> writes:
> Hello all,
>
> Within the next weeks we expect the release of Perl 5.38. This version
> includes some changes which should be supported by CPerl mode. Most
> notably, there will be a builtin object system with keywords "class" and
> "method", which are relevant for syntax highlighting, imenu, and
> indentation.
>
> I am currently working on adding these to cperl-mode.el. But these
> will, in the normal course of action, not be released before Emacs 30
> comes out. Therefore I'd like to make cperl-mode.el available via ELPA.
>
> If I understand it correctly, then the file can continue to be developed
> in the Emacs repository, if it is flagged as ":core". cperl-mode.el
> would need a "Version:" header so that it can be released independent of
> Emacs versions.
That and it would have to be added to ELPA, but that is easy.
> So, if the version in cperl-mode.el is changed, ELPA
> will deliver the new version. Are there conventions where to start?
> Historically cperl-mode.el had its own versioning, based on an upstream
> which no longer exists. This ended with version 6.2, the variable
> cperl-version has been obsoleted as an own variable in Emacs 28.1. I
> think it would make sense to start from there and release the first ELPA
> version as 7.0.
> I am regularly running tests for cperl-mode.el in older Emacs versions
> (and have added a few compatibility helpers). Are there any more
> changes to do?
Not that I know of. Though adding a "Package-Requires" header would be
useful, unless you don't depend on any newer feature in Emacs. In this
context, you might find "Compat"[0] to be useful, in case you want/need
some recent feature but don't want implement it yourself.
[0] https://elpa.gnu.org/packages/compat.html
I don't know if there are any specific guidelines/tutorials. A few
months ago I prepared package.el as a :core package, and all I had to go
by were old commits that hinted at what was to be done and the source
code in elpa-admin.el.
--
Philip Kaludercic
^ permalink raw reply [relevance 91%]
* Re: question regarding my emacs package
@ 2023-06-12 10:54 88% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-06-12 10:54 UTC (permalink / raw)
To: João Távora; +Cc: ram via Emacs development discussions., ram
João Távora <joaotavora@gmail.com> writes:
> On Mon, Jun 12, 2023 at 9:45 AM Philip Kaludercic <philipk@posteo.net> wrote:
>>
>> ram via "Emacs development discussions." <emacs-devel@gnu.org> writes:
>>
>> > thanks. did not know this existed. from a quick glance, it looks like
>> > there’s no crossover in prefixes? that seems ok
>>
>> Yes, but it is pretty close and will probably cause confusion. That
>> being said, João is not part of any ELPA so one could argue the name
>> hasn't been reserved...
>
> Just some thoughts:
>
> 1. There is no name clash, as ram observed
Yes, there is only the potential for confusion.
> 2. I'm not aware of a name reservation/parking procedure. As far as I can
> tell, ram's breadcrumbs.el isn't a part of any ELPA yet.
>
> 3. If early manifestation of adding a library is somehow relevant
> then I might point you to this ~8-month old thread where I propose we
> add breadcrumb.el to Emacs [1]. That's where breadcrumb.el was born and
> proposed for Emacs.
Oh, I did not know that. Intuitively, I would argue that you tried to
reserve the name in the "core emacs/ELPA namespace" first.
> I'm still on the fence about whether to propose
> it for a :core package or ELPA package. It takes inspiration on a
> similar-named lsp-mode feature and the "breadcrumb" concept is apparently
> a common name given to the type of feature breadcrumb.el enables.
I think that both options would be fine, and I'd be happy to help with
either.
> 4. There is no name clash, I think this bears repeating.
>
> 5. Above, I wrote "if early manifestation... is relevant". I don't think
> it should be. If avoiding confusion to users is a goal to pursue -- and
> if this confusion is indeed real (see 4 and 1) -- then I think it's more
> important to evaluate the potential consequences of a rename in existing
> users of each package. We don't know that number, but merely as data point,
> breadcrumbs.el has 6 github stars and breadcrumb.el has 116.
Arguing via stars is difficult, because on the one hand you are a well
known Elisp author and your packages are bound to attract more attention
over a longer period of time, but we cannot deduce anything from these
facts. E.g. None of my packages (except for Compat, which is
co-maintained) are on GitHub, so this metric couldn't be used if ram
decided to use SourceHut as well.
> 6. Please let's avoid another "meaning of names/meaning of life" thread.
> There is no name clash.
Ok, in that case I won't argue that that this is one of the issue of
using intuitive names ;)
> João
>
> [1]: https://lists.gnu.org/archive/html/bug-gnu-emacs/2022-10/msg01027.html
--
Philip Kaludercic
^ permalink raw reply [relevance 88%]
* Re: question regarding my emacs package
@ 2023-06-12 8:45 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-06-12 8:45 UTC (permalink / raw)
To: ram via Emacs development discussions.; +Cc: joaotavora, ram
ram via "Emacs development discussions." <emacs-devel@gnu.org> writes:
> thanks. did not know this existed. from a quick glance, it looks like
> there’s no crossover in prefixes? that seems ok
Yes, but it is pretty close and will probably cause confusion. That
being said, João is not part of any ELPA so one could argue the name
hasn't been reserved...
> On Sun, Jun 11, 2023 at 2:49 PM, João Távora <joaotavora@gmail.com> wrote:
>
> Just a FYI, I've recently (about a month ago) created a package called breadcrumb.el, singular. Lives at
> https://github.com/joaotavora/breadcrumb and seems to be fairly popular.
>
> Not saying anyone should consider changing package names, just dropping this note here as a FYI.
>
> João
>
> On Wed, Jun 7, 2023, 13:09 ram <chat@rj95.be> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> hi, i am a professional programmer, but this is my first time submitting an emacs package. i have
> conversed a little with stefan monnier, and i believe the package i have meets the requirements for
> elpa submission, but i am unsure as to the appropriate licensure. i took some inspiration from two
> packages: dogears and gumshoe, neither of which is in elpa. however, i did not use any code from
> here; i just wanted some inspiration regarding the feature set
>
> it is unclear to me whether my package warrants inclusion in gnu or non gnu elpa, if at all, but i
> have certainly found it useful, despite its simplicity
>
> here is the repo: https://github.com/gitrj95/breadcrumbs.el
>
> best,
> ram
> -----BEGIN PGP SIGNATURE-----
> Version: ProtonMail
>
> wnUEARYKACcFgmR/9tMJkLWF/Pp8PQPNFiEExUjWugOWGzBgCQZvtYX8+nw9
> A80AACtMAQDBJcq/+hW8lFC/JkXKSAsIjD5/dFF/jcjYjfRh3o0TMwD9Eb4W
> f0DKtY6/QCgyoPMLsMIBUf1cDZ1c53rQ9xHWCAI=
> =5pUI
> -----END PGP SIGNATURE-----
>
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: package-vc support for :files keyword
@ 2023-06-11 10:24 86% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-06-11 10:24 UTC (permalink / raw)
To: Daniel Fleischer; +Cc: emacs-devel
Daniel Fleischer <danflscr@gmail.com> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> (If possible, try to use a wide reply when responding to these messages,
>> so that I (and anyone else who would want to participate but it not
>> subscribed) get notified directly).
>
> Will do.
Thanks.
>
> I need to learn more about this topic; I learned about `.elpaignore'
> which could be what I need.
Right, package.el parses .elpaignore files to exclude files from byte
compilation, and nothing else.
> So I won't discuss specific features at this
> point.
I am happy to help if there is anything else I can clarify.
> I will leave one point for thought: trying to gap the difference between
> ELPA packages and the "others" (melpa) could benefit everyone; it can
> lower the technical bar for external packages to join ELPA or non-GNU
> ELPA; packages will still be reviewed upon submission but things would
> work more smoothly as there will be only one recipe style.
The thing is, most of the time all a package needs to be added to GNU or
NonGNU ELPA is just a URL. That is why package-vc-install can
frequently handle installing a package by just proving a URL to a
repository. Just check the elpa-packages files for the two archives:
https://git.savannah.gnu.org/cgit/emacs/elpa.git/tree/elpa-packages
https://git.savannah.gnu.org/cgit/emacs/nongnu.git/tree/elpa-packages
I don't think will be possible for ELPA-style package specifications and
MELPA-style package recipes to be merged, nor do I see a urgent need for
that to happen. The two archives don't only differ in superficial
points like here, in the way packages are represented and listed, but in
other fine technical details and philosophical matters.
> Thanks,
--
Philip Kaludercic
^ permalink raw reply [relevance 86%]
* Re: [ELPA] New package: emacs-gc-stats
@ 2023-06-11 9:12 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-06-11 9:12 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Stefan Monnier, Eli Zaretskii, emacs-devel
Ihor Radchenko <yantar92@posteo.net> writes:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>>> Let me know if you need help adding the package (I couldn't find a URL
>>>> for the code, so I have no opinion about it (yet :-))
>>> Oops... https://git.sr.ht/~yantar92/emacs-gc-stats
>>
>> Thanks, added.
>
> For some reason, I am getting build failure:
>
> ======== Building tarball archive/emacs-gc-stats-1.0.tar...
> Problem with copyright notices:
> emacs-gc-stats/emacs-gc-stats.el:;; Copyright (C) 2023 Ihor Radchenko
> Missing copyright notice in emacs-gc-stats/emacs-gc-stats.el
> Build error for archive/emacs-gc-stats-1.0.tar: (error "Abort")
>
> Note that I have
>
> ;; Copyright (C) 2023 Free Software Foundation, Inc.
>
> in <https://git.sr.ht/~yantar92/emacs-gc-stats/tree/main/item/emacs-gc-stats.el>
>
> What am I missing?
ELPA uses the latest commit that bumped the version tag in the package
header. If that commit doesn't have the right copyright data, then that
is cause for the above error.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: package-vc support for :files keyword
@ 2023-06-11 8:55 79% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-06-11 8:55 UTC (permalink / raw)
To: Daniel Fleischer; +Cc: emacs-devel
(If possible, try to use a wide reply when responding to these messages,
so that I (and anyone else who would want to participate but it not
subscribed) get notified directly).
Daniel Fleischer <danflscr@gmail.com> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Right, as the primary technical inspiration for package-vc has been
>> elpa-admin, and therefore we (re-)use GNU ELPA-style package
>> specifications.
>
> Hi, I wasn't aware there's a style guide for ELPA packages.
This is not really a style-guide (which is something I would interpret
as concerning the contents of a package), but just a matter of how it
would be best for packages and the package archive to interact.
>> No, just like `:ignored-files' I do not see a sensible way to implement
>> it without compromising on the primary goal mentioned above.
>
> I don't understand this part: `:ignored-files' is part of the ELPA
> documentation and you are saying it's still not supported?
It is not supported by package-vc. If you check (emacs) Fetching
Package Sources, then you'll see the supported keywords listed under the
"Specifying Package Sources" section. Generally speaking, package-vc
is a subset of the keywords defined by elpa-admin.
>> Generally speaking, this is a style of package development that
>> {GNU,NonGNU} ELPA would like to advise against perusing, in favour of
>> a one-repo-per-package approach. Do you have a specific reason why you
>> think that something like `:{ignored-,}files' are useful in general
>> (i.e. not just because of the contingent fact that MELPA has
>> popularised this form of development).
>
> One example is tests; having test files either in the root folder or in
> a folder called "tests", how do you prevent them from being evaluated?
> They could have additional dev dependencies that you might not want to
> have. What is the ELPA guideline about that?
Test files are not evaluated/loaded, unless the user does so explicitly
or if the package developer were to force it via autoloads. In the
former case, I would say that it is probably intended behaviour, in the
latter case this is a mistake made by the maintainer.
If the file is located under a tests/ directory (or any other name),
then it will not be added to the `load-path' to begin with.
The point here is, that if a user wants to contribute to a package with
tests, the tests shouldn't be hidden or even removed. That is why I'd
even say it would be better to add the tests to the main lisp directory,
so that it is even easier to load them.
--
Philip Kaludercic
^ permalink raw reply [relevance 79%]
* Re: package-vc support for :files keyword
@ 2023-06-10 13:23 79% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-06-10 13:23 UTC (permalink / raw)
To: Daniel Fleischer; +Cc: emacs-devel
Daniel Fleischer <danflscr@gmail.com> writes:
> Hi, I've been testing package-vc support in Emacs 29. It's clear that
> this feature is inspired by 3rd party packages that help users install
> packages from external forges.
I have never used any of the other packages managers, primarily because
they seem to peruse different goals. The primary motivation for
package-vc is to make it easy to hack on packages that are already
available on an ELPA and contribute these changes upstream via commands
like `package-vc-prepare-patch'. The fact that it can be used as the
primary method for package.el to fetch sources is an "unintended"
consequence.
> Also, it makes sense that the Melpa
> recipe specification compatibility is not a goal.
Right, as the primary technical inspiration for package-vc has been
elpa-admin, and therefore we (re-)use GNU ELPA-style package
specifications.
> However, I do think
> the `:files' keyword is very useful to have, and was wondering whether
> it's planned, maybe in master?
No, just like `:ignored-files' I do not see a sensible way to implement
it without compromising on the primary goal mentioned above. Generally
speaking, this is a style of package development that {GNU,NonGNU} ELPA
would like to advise against perusing, in favour of a
one-repo-per-package approach. Do you have a specific reason why you
think that something like `:{ignored-,}files' are useful in general
(i.e. not just because of the contingent fact that MELPA has popularised
this form of development).
But just like :make and :shell-command, or use-package support was not
intended in the beginning, I don't insist on anything as long as a
good compromise can be found. I just have my doubts, since supporting
this would probably run against a number of basic assumptions that
package-vc was written around.
> Thanks,
^ permalink raw reply [relevance 79%]
* Re: Adding some convenience functions to color.el
@ 2023-06-09 6:22 94% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-06-09 6:22 UTC (permalink / raw)
To: Yilkal Argaw; +Cc: Emacs Devel
Yilkal Argaw <yilkalargawworkneh@gmail.com> writes:
> Hi
> Today I was messing around with some theme that made use of color.el and I
> noticed some functions that might be of use could be added to color.el to
> help with the conditionally assigning setting some colors based on
> lightness or darkness of some other color. I wondered if it might be useful
> to other users and if it might be worth adding it to color.el. I
>
> diff --git a/lisp/color.el b/lisp/color.el
> index f68cf5e6b17..3740c3d5a7c 100644
> --- a/lisp/color.el
> +++ b/lisp/color.el
> @@ -119,6 +119,18 @@ inclusive."
> (color-hue-to-rgb m1 m2 H)
> (color-hue-to-rgb m1 m2 (mod (- H (/ 3.0)) 1))))))
>
> +(defun color-name-to-hsl (color)
> + "Convert COLOR to HSL."
I think it would make sense to mention what COLOR is. Or at least call
it COLOR-NAME.
> + (apply #'color-rgb-to-hsl (color-name-to-rgb color)))
> +
> +(defun color-name-light-p (color)
> + "Return non-nil if COLOR is on the lighter side."
> + (when color (>= (caddr (color-name-to-hsl color) 0.5))))
IMO using `and' is better if you are interested the return value of an
expression, while `when' is usually more indicative of a side-effect (on
my first reading of this assumption had me confused to the point of the
function).
But setting that aside, why should someone pass nil to this function?
> +
> +(defun color-name-dark-p (color)
> + "Return non-nil if COLOR is on the darker side."
> + (when color (not (color-name-light-p color))))
> +
> (defun color-complement-hex (color)
> "Return the color that is the complement of COLOR, in hexadecimal
> format."
> (apply 'color-rgb-to-hex (color-complement color)))
This is useful!
Could you prepare a patch and update etc/NEWS? It seems that the other
color functions are not documented in the Emacs Lisp manual.
>
> With Regards
> Yilkal Argaw
^ permalink raw reply [relevance 94%]
* Re: question regarding my emacs package
@ 2023-06-08 7:26 57% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-06-08 7:26 UTC (permalink / raw)
To: ram; +Cc: emacs-devel@gnu.org
[-- Attachment #1: Type: text/plain, Size: 222 bytes --]
ram <chat@rj95.be> writes:
> i believe i've incorporated your suggestions, fixed the bugs, and satisfied check doc. let me know what else i need to do, eg fsf copyright notice, etc
Here are a few more things I noticed:
[-- Attachment #2: Type: text/plain, Size: 4356 bytes --]
diff -u /tmp/breadcrumbs.el.1 /tmp/breadcrumbs.el
--- /tmp/breadcrumbs.el.1 2023-06-08 09:20:18.490560968 +0200
+++ /tmp/breadcrumbs.el 2023-06-08 09:23:13.217684032 +0200
@@ -35,9 +35,9 @@
;; https://github.com/gitrj95/breadcrumbs.el
;;
;; In order to use breadcrumbs, `breadcrumbs-mode' must be enabled.
-;;
-;;; Interface:
-;;
+
+;;;; Interface:
+
;; `breadcrumbs-drop-breadcrumb' adds the current position in the
;; buffer to a ring. If point is at a known breadcrumb, the existing
;; breadcrumb will be moved to the head of the ring. Adding
@@ -103,28 +103,26 @@
"Set up the state required to start using breadcrumbs."
(unless breadcrumbs-ring
(setq breadcrumbs-ring (make-ring breadcrumb-ring-max)))
- (mapcar (lambda (fn)
- (advice-add fn :around #'breadcrumbs--drop-around))
- breadcrumbs-drop-around-fn-list))
+ (dolist (fn breadcrumbs-drop-around-fn-list)
+ (advice-add fn :around #'breadcrumbs--drop-around)))
(defun breadcrumbs--teardown ()
"Tear down the state required for breadcrumbs."
(setq breadcrumbs-ring nil
breadcrumbs--neighbor nil)
- (mapcar (lambda (fn)
- (advice-remove fn #'breadcrumbs--drop-around))
- breadcrumbs-drop-around-fn-list))
+ (dolist (fn breadcrumbs-drop-around-fn-list)
+ (advice-remove fn #'breadcrumbs--drop-around)))
(defun breadcrumbs--switch-to-fileless-buffer (breadcrumb)
- "Switch to BREADCRUMB's `fileless-buffer-name' if it is non-nil and optionally remove dead ones."
+ "Switch to BREADCRUMB's `fileless-buffer-name' if it is non-nil.
+Optionally remove dead ones."
(if-let* ((buffer-name (breadcrumbs--breadcrumb-fileless-buffer-name breadcrumb))
(buffer (get-buffer buffer-name)))
(switch-to-buffer buffer)
(when (yes-or-no-p (format "%s has been killed. Remove from all instances from `breadcrumbs-ring'? " buffer-name))
- (mapcar (lambda (breadcrumb-to-remove)
- (when (equal buffer-name (breadcrumbs--breadcrumb-fileless-buffer-name breadcrumb-to-remove))
- (ring-remove breadcrumbs-ring (ring-member breadcrumbs-ring breadcrumb-to-remove))))
- (ring-elements breadcrumbs-ring))
+ (dolist (breadcrumb-to-remove (ring-elements breadcrumbs-ring))
+ (when (equal buffer-name (breadcrumbs--breadcrumb-fileless-buffer-name breadcrumb-to-remove))
+ (ring-remove breadcrumbs-ring (ring-member breadcrumbs-ring breadcrumb-to-remove))))
(breadcrumbs-list--revert)
nil)))
@@ -170,7 +168,7 @@
((eq direction 'previous) (ring-next breadcrumbs-ring jump-target)))))
(breadcrumbs--neighbor
(when (eq direction 'previous)
- (breadcrumbs--jump breadcrumbs--neighbor))))))
+ (breadcrumbs--jump breadcrumbs--neighbor))))))
;;;###autoload
(define-minor-mode breadcrumbs-mode
@@ -195,9 +193,9 @@
(defun breadcrumbs--format-breadcrumb (breadcrumb)
"Return BREADCRUMB's formatted slots as a vector."
(let* ((buffer-file-name (breadcrumbs--breadcrumb-buffer-file-name breadcrumb))
- (buffer-position (breadcrumbs--breadcrumb-buffer-position breadcrumb))
- (buffer-name (breadcrumbs--breadcrumb-fileless-buffer-name breadcrumb))
- (breadcrumb-name (or buffer-file-name buffer-name)))
+ (buffer-position (breadcrumbs--breadcrumb-buffer-position breadcrumb))
+ (buffer-name (breadcrumbs--breadcrumb-fileless-buffer-name breadcrumb))
+ (breadcrumb-name (or buffer-file-name buffer-name)))
(vector
(breadcrumbs--format-slot breadcrumb-name 64)
(breadcrumbs--format-slot buffer-position 16))))
@@ -207,7 +205,8 @@
(mapcar (lambda (breadcrumb)
(list
breadcrumb
- (breadcrumbs--format-breadcrumb breadcrumb))) (ring-elements breadcrumbs-ring)))
+ (breadcrumbs--format-breadcrumb breadcrumb)))
+ (ring-elements breadcrumbs-ring)))
(defun breadcrumbs-list--revert ()
"Reverts `breadcrumbs-list-buffer'."
@@ -232,7 +231,7 @@
(ring-remove breadcrumbs-ring
(ring-member breadcrumbs-ring (tabulated-list-get-id)))
(when (ring-empty-p breadcrumbs-ring)
- (setq breadcrumbs--neighbor nil))
+ (setq breadcrumbs--neighbor nil))
(breadcrumbs-list--revert))
;;;###autoload
Diff finished. Thu Jun 8 09:24:02 2023
[-- Attachment #3: Type: text/plain, Size: 2267 bytes --]
The main things were inconsistent indentation, using mapcar for
side-effects (if anything mapc should be used in that case, but I think
dolist is the best choice) and there still was one checkdoc complaint.
On the topic of docstrings, I think you should invest some more time to
make them understandable to someone who doesn't already know what the
code is about.
Have you signed the FSF copyright assignment?
> ------- Original Message -------
> On Wednesday, June 7th, 2023 at 6:34 PM, ram <chat@rj95.be> wrote:
>
>
>>
>>
>> just got back to this. calling find-file appears to not open the new
>> file when called through the code. i'm not immediately sure what the
>> problem is. any tips? i'll look more into this tonight
>>
>>
>>
>>
>> ------- Original Message -------
>> On Wednesday, June 7th, 2023 at 3:50 PM, ram chat@rj95.be wrote:
>>
>>
>>
>> > yes i figured; i found other bugs as well, but i don't think this is a typo. i'll dig a bit more and see what i can find
>> >
>> > ------- Original Message -------
>> > On Wednesday, June 7th, 2023 at 3:48 PM, Philip Kaludercic philipk@posteo.net wrote:
>> >
>> > > ram chat@rj95.be writes:
>> > >
>> > > > changing the central type from defclass to cl-defstruct has appeared
>> > > > to cause bugs?
>> > >
>> > > That might have been a typo on my end, I did not evaluate the code and
>> > > was is a hurry to send you the diff. My point is that you don't need
>> > > defclass, unless I am missing something in your code (and I don't think
>> > > the minimal convenience of `with-slots' warrants classes here).
>> > >
>> > > > i am not sure what to make of this, but find-file and
>> > > > its variants do not appear to work when changing only this. the file
>> > > > is not opened; it is not that the file is opened but the active buffer
>> > > > isn't switched
>> > > >
>> > > > ------- Original Message -------
>> > > > On Wednesday, June 7th, 2023 at 2:04 PM, Philip Kaludercic philipk@posteo.net wrote:
>> > > >
>> > > > > Philip Kaludercic philipk@posteo.net writes:
>> > > > >
>> > > > > > > here is the repo: https://github.com/gitrj95/breadcrumbs.el
>> > > > > >
>> > > > > > Here are a few suggestions:
>> > > > >
>> > > > > Oh, and can you address the issue raised by checkdoc?
^ permalink raw reply [relevance 57%]
* Re: Bookmarks in registers
@ 2023-06-08 6:44 94% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-06-08 6:44 UTC (permalink / raw)
To: Christopher Howard; +Cc: emacs-devel
Christopher Howard <christopher@librehacker.com> writes:
> Hi, I explored this idea recently, and was wondering if it could be something easily added to the next release of emacs:
>
> http://gem.librehacker.com/gemlog/starlog/20230607-0.gmi
For those who don't want to open the link:
--8<---------------cut here---------------start------------->8---
(defun bookmark-point-to-register ()
(interactive)
(set-register
(register-read-with-preview "register: ")
(bookmark-make-record)))
(defun bookmark-register-to-point ()
(interactive)
(bookmark--jump-via
(get-register
(register-read-with-preview "register: "))
'pop-to-buffer-same-window))
--8<---------------cut here---------------end--------------->8---
> Maybe some active Emacs developer would want to run with this basic idea and throw together a patch?
Getting other people to write a patch for you is usually not productive.
I'd recommend trying to do so yourself (check out the CONTRIBUTE file in
emacs.git), in which case there is something concrete to discuss.
> I've found in my workflow that it is convenient to be able to put an
> anonymous bookmark into a register. For example, if you are
> temporarily moving around between a few different info manuals.
How is this different from `point-to-register' and `jump-to-register'?
^ permalink raw reply [relevance 94%]
* Re: question regarding my emacs package
@ 2023-06-07 19:48 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-06-07 19:48 UTC (permalink / raw)
To: ram; +Cc: emacs-devel@gnu.org
ram <chat@rj95.be> writes:
> changing the central type from defclass to cl-defstruct has appeared
> to cause bugs?
That might have been a typo on my end, I did not evaluate the code and
was is a hurry to send you the diff. My point is that you don't need
defclass, unless I am missing something in your code (and I don't think
the minimal convenience of `with-slots' warrants classes here).
> i am not sure what to make of this, but find-file and
> its variants do not appear to work when changing only this. the file
> is not opened; it is not that the file is opened but the active buffer
> isn't switched
>
>
>
>
> ------- Original Message -------
> On Wednesday, June 7th, 2023 at 2:04 PM, Philip Kaludercic <philipk@posteo.net> wrote:
>
>
>>
>>
>> Philip Kaludercic philipk@posteo.net writes:
>>
>> > > here is the repo: https://github.com/gitrj95/breadcrumbs.el
>> >
>> > Here are a few suggestions:
>>
>>
>> Oh, and can you address the issue raised by checkdoc?
^ permalink raw reply [relevance 99%]
* Re: question regarding my emacs package
2023-06-07 15:53 48% ` Philip Kaludercic
@ 2023-06-07 18:04 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-06-07 18:04 UTC (permalink / raw)
To: ram; +Cc: emacs-devel@gnu.org
Philip Kaludercic <philipk@posteo.net> writes:
>> here is the repo: https://github.com/gitrj95/breadcrumbs.el
>
> Here are a few suggestions:
Oh, and can you address the issue raised by checkdoc?
^ permalink raw reply [relevance 99%]
* Re: question regarding my emacs package
@ 2023-06-07 15:53 48% ` Philip Kaludercic
2023-06-07 18:04 99% ` Philip Kaludercic
1 sibling, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-06-07 15:53 UTC (permalink / raw)
To: ram; +Cc: emacs-devel@gnu.org
[-- Attachment #1: Type: text/plain, Size: 894 bytes --]
ram <chat@rj95.be> writes:
> hi, i am a professional programmer, but this is my first time
> submitting an emacs package. i have conversed a little with stefan
> monnier, and i believe the package i have meets the requirements for
> elpa submission, but i am unsure as to the appropriate licensure. i
> took some inspiration from two packages: dogears and gumshoe, neither
> of which is in elpa. however, i did not use any code from here; i just
> wanted some inspiration regarding the feature set
That should not be an issue, these packages appear to only be a source
of inspiration?
> it is unclear to me whether my package warrants inclusion in gnu or
> non gnu elpa, if at all, but i have certainly found it useful, despite
> its simplicity
Complexity is not a requirement for being useful :)
> here is the repo: https://github.com/gitrj95/breadcrumbs.el
Here are a few suggestions:
[-- Attachment #2: Type: text/plain, Size: 6620 bytes --]
diff -u /tmp/breadcrumbs.el.1 /tmp/breadcrumbs.el
--- /tmp/breadcrumbs.el.1 2023-06-07 17:32:50.162889593 +0200
+++ /tmp/breadcrumbs.el 2023-06-07 17:52:36.608268297 +0200
@@ -35,9 +35,9 @@
;; https://github.com/gitrj95/breadcrumbs.el
;;
;; In order to use breadcrumbs, `breadcrumbs-mode' must be enabled.
-;;
-;; Interface:
-;;
+
+;;; Interface:
+
;; `breadcrumbs-drop-breadcrumb' adds the current position in the
;; buffer to a ring. If point is at a known breadcrumb, the existing
;; breadcrumb will be moved to the head of the ring. Adding
@@ -59,9 +59,14 @@
;;; Code:
(require 'ring)
-(require 'eieio)
+(require 'cl-lib)
(require 'pulse)
+(defgroup breadcrumbs ()
+ "Track buffer positions."
+ :group 'convenience
+ :prefix "breadcrumbs-")
+
(defvar breadcrumbs-ring nil
"All dropped breadcrumbs, up to `breadcrumb-ring-max' breadcrumbs.")
@@ -81,44 +86,47 @@
(defvar breadcrumbs-list-buffer nil
"The \"*Breadcrumbs List*\" buffer.")
-(defclass breadcrumbs--breadcrumb ()
- ((buffer-name
- :initform (buffer-name)
- :documentation "Name of the buffer.")
- (buffer-position
- :initform (point)
- :documentation "Position in buffer."
- )
- (buffer-file-name
- :initform (buffer-file-name)
- :documentation "The full file path of this breadcrumb."))
- "The breadcrumb definition.")
+(cl-defstruct breadcrumbs
+ "The breadcrumb definition."
+ (buffer-name
+ (buffer-name)
+ :documentation "Name of the buffer.")
+ (buffer-position
+ (point)
+ :documentation "Position in buffer.")
+ (buffer-file-name
+ (buffer-file-name)
+ :documentation "The full file path of this breadcrumb."))
(defun breadcrumbs--setup ()
"Set up the state required to start using breadcrumbs."
(if (not breadcrumbs-ring)
(setq breadcrumbs-ring (make-ring breadcrumb-ring-max)))
(mapcar (lambda (fn)
- (advice-add fn :around #'breadcrumbs--drop-around)) breadcrumbs-drop-around-fn-list))
+ (advice-add fn :around #'breadcrumbs--drop-around))
+ breadcrumbs-drop-around-fn-list))
(defun breadcrumbs--teardown ()
"Tear down the state required for breadcrumbs."
(setq breadcrumbs-ring nil)
(setq breadcrumbs--neighbor nil)
(mapcar (lambda (fn)
- (advice-remove fn #'breadcrumbs--drop-around)) breadcrumbs-drop-around-fn-list))
+ (advice-remove fn #'breadcrumbs--drop-around))
+ breadcrumbs-drop-around-fn-list))
(defun breadcrumbs--jump (breadcrumb)
"Jump to the specified breadcrumb."
(setq breadcrumbs--neighbor breadcrumb)
- (with-slots (buffer-name buffer-position buffer-file-name) breadcrumb
+ (let ((buffer-name (breadcrumbs-buffer-name breadcrumb))
+ (buffer-position (breadcrumbs-buffer-position breadcrumb))
+ (buffer-file-name (breadcrumbs-buffer-file-name breadcrumb)))
(if (get-buffer buffer-name)
(progn
(switch-to-buffer buffer-name)
(goto-char buffer-position))
(find-file buffer-file-name)
(goto-char buffer-position)
- (setf buffer-name (buffer-name)))
+ (rename-buffer (buffer-name)))
(pulse-momentary-highlight-one-line)))
(defun breadcrumbs--drop ()
@@ -138,16 +146,18 @@
(breadcrumbs--drop)
result))
-(defun breadcrumbs--find-and-jump (&key direction)
+(defun breadcrumbs--find-and-jump (&rest args)
"Find some candidate breadcrumb and jump to the next or previous, based on `direction'."
(let ((jump-target
(let ((candidate (make-instance 'breadcrumbs--breadcrumb)))
- (if (ring-member breadcrumbs-ring candidate)
- candidate))))
+ (and (ring-member breadcrumbs-ring candidate) candidate)))
+ (direction (plist-get args :type)))
(cond (jump-target
(breadcrumbs--jump
- (cond ((eq direction 'next) (ring-next breadcrumbs-ring jump-target))
- ((eq direction 'previous) (ring-next breadcrumbs-ring jump-target)))))
+ (ring-next
+ (cond ((eq direction 'next) breadcrumbs-ring)
+ ((eq direction 'previous) breadcrumbs-ring))
+ jump-target)))
(breadcrumbs--neighbor
(if (eq direction 'previous)
(breadcrumbs--jump breadcrumbs--neighbor))))))
@@ -156,14 +166,12 @@
(define-minor-mode breadcrumbs-mode
"Track positions in buffers and files using breadcrumbs."
:global t
- :init-value t
(if breadcrumbs-mode
(breadcrumbs--setup)
(breadcrumbs--teardown)))
(defvar breadcrumbs-list-mode-map
(let ((map (make-sparse-keymap)))
- (set-keymap-parent map tabulated-list-mode-map)
(define-key map (kbd "j") #'breadcrumbs-list-jump)
(define-key map (kbd "<RET>") #'breadcrumbs-list-jump)
(define-key map (kbd "k") #'breadcrumbs-list-delete)
@@ -172,13 +180,14 @@
(defun breadcrumbs--format-slot (slot len)
"Formats a breadcrumbs slot."
- (let ((format-string (format "%%-%ss" len)))
- (format format-string
- (if slot slot ""))))
+ (let ((format-string (format "%%-%ds" len)))
+ (format format-string (or slot ""))))
(defun breadcrumbs--format-breadcrumb (breadcrumb)
"Return a formatted breadcrumb as a vector of formatted slots."
- (with-slots (buffer-name buffer-position buffer-file-name) breadcrumb
+ (let ((buffer-name (breadcrumbs-buffer-name breadcrumb))
+ (buffer-position (breadcrumbs-buffer-position breadcrumb))
+ (buffer-file-name (breadcrumbs-buffer-file-name breadcrumb)))
(vector
(breadcrumbs--format-slot buffer-name 16)
(breadcrumbs--format-slot buffer-position 16)
@@ -199,13 +208,10 @@
(define-derived-mode breadcrumbs-list-mode tabulated-list-mode
"Tabular list mode displaying tracked breadcrumbs."
- (setq-local tabulated-list-format
+ (setq-local tabulated-list-entries #'breadcrumbs-list--entries
+ tabulated-list-format
`[("Buffer" 16) ("Position" 16) ("File" 32)])
- (add-hook 'tabulated-list-revert-hook
- (lambda ()
- (setf tabulated-list-entries (breadcrumbs-list--entries))))
- (tabulated-list-init-header)
- (breadcrumbs-list--revert))
+ (tabulated-list-init-header))
(defun breadcrumbs-list-jump ()
"Jump to breadcrumb from \"*Breadcrumbs List*\"."
@@ -217,8 +223,8 @@
(interactive)
(ring-remove breadcrumbs-ring
(ring-member breadcrumbs-ring (tabulated-list-get-id)))
- (if (ring-empty-p breadcrumbs-ring)
- (setq breadcrumbs--neighbor nil))
+ (when (ring-empty-p breadcrumbs-ring)
+ (setq breadcrumbs--neighbor nil))
(breadcrumbs-list--revert))
;;;###autoload
Diff finished. Wed Jun 7 17:52:43 2023
^ permalink raw reply [relevance 48%]
* Re: [elpa] externals/firefox-javascript-repl 056b687af4 2/3: Work around missing submodule support in GNU ELPA
[not found] ` <20230601213415.21F57C21A9F@vcs2.savannah.gnu.org>
@ 2023-06-05 12:46 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-06-05 12:46 UTC (permalink / raw)
To: emacs-devel; +Cc: Thomas Fitzsimmons
Thomas Fitzsimmons <fitzsim@fitzsim.org> writes:
> branch: externals/firefox-javascript-repl
> commit 056b687af4d70252dee2cdd2323da3990fabd558
> Author: Thomas Fitzsimmons <fitzsim@fitzsim.org>
> Commit: Thomas Fitzsimmons <fitzsim@fitzsim.org>
>
> Work around missing submodule support in GNU ELPA
What do you need to do?
> * wtfjs.README.md: New file.
> * firefox-javascript-repl.el (fjrepl--show-quirk): Load
> quirk-of-the-day from wtfjs.README.md snapshot. Increase quirk
> message timeout to seven seconds.
> (firefox-javascript-repl--mode): Do not ignore quirk errors.
^ permalink raw reply [relevance 99%]
* Re: master a30781399b3: * subr-x (eval-command-interactive-spec): New function.
[not found] ` <20230605073635.19060C00613@vcs2.savannah.gnu.org>
@ 2023-06-05 10:24 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-06-05 10:24 UTC (permalink / raw)
To: emacs-devel; +Cc: Sean Whitton
Sean Whitton <spwhitton@spwhitton.name> writes:
> branch: master
> commit a30781399b3ef48150b9cb13cb0aeba7086c2d9e
> Author: Sean Whitton <spwhitton@spwhitton.name>
> Commit: Sean Whitton <spwhitton@spwhitton.name>
>
> * subr-x (eval-command-interactive-spec): New function.
> ---
> etc/NEWS | 5 +++++
> lisp/emacs-lisp/nadvice.el | 2 ++
> lisp/emacs-lisp/subr-x.el | 7 +++++++
> 3 files changed, 14 insertions(+)
>
> diff --git a/etc/NEWS b/etc/NEWS
> index 9529282f047..910472e5519 100644
> --- a/etc/NEWS
> +++ b/etc/NEWS
> @@ -648,6 +648,11 @@ Since circular alias chains now cannot occur, 'function-alias-p',
> 'indirect-function' and 'indirect-variable' will never signal an error.
> Their 'noerror' arguments have no effect and are therefore obsolete.
>
> +---
> +** New function 'eval-command-interactive-spec' in the subr-x library.
> +This function evaluates a command's interactive form and returns the
> +resultant list.
What is the motivation for this feature?
> > +
> \f
> * Changes in Emacs 30.1 on Non-Free Operating Systems
>
> diff --git a/lisp/emacs-lisp/nadvice.el b/lisp/emacs-lisp/nadvice.el
> index e457387acc9..e6977f2012a 100644
> --- a/lisp/emacs-lisp/nadvice.el
> +++ b/lisp/emacs-lisp/nadvice.el
> @@ -165,6 +165,8 @@ DOC is a string where \"FUNCTION\" and \"OLDFUN\" are expected.")
> (buffer-string))
> usage))))
>
> +;; FIXME: How about renaming this to just `eval-interactive-spec'?
> +;; It's not specific to the advice system.
> (defun advice-eval-interactive-spec (spec)
> "Evaluate the interactive spec SPEC."
> (cond
> diff --git a/lisp/emacs-lisp/subr-x.el b/lisp/emacs-lisp/subr-x.el
> index 9e906930b92..a7d8f785508 100644
> --- a/lisp/emacs-lisp/subr-x.el
> +++ b/lisp/emacs-lisp/subr-x.el
> @@ -504,6 +504,13 @@ Used by `emacs-authors-mode' and `emacs-news-mode'."
> (progn (forward-line -1) (point))
> (point-max)))))
>
> +(defun eval-command-interactive-spec (command)
> + "Evaluate COMMAND's interactive form and return resultant list.
> +If COMMAND has no interactive form, return nil."
> + (advice-eval-interactive-spec
> + (cadr (or (and (symbolp command) (get command 'interactive-form))
> + (interactive-form command)))))
> +
> (provide 'subr-x)
>
> ;;; subr-x.el ends here
^ permalink raw reply [relevance 99%]
* Re: [NonGNU Elpa] New package: electric-french
@ 2023-06-05 8:34 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-06-05 8:34 UTC (permalink / raw)
To: Ruijie Yu via Emacs development discussions.; +Cc: Ruijie Yu
Ruijie Yu via "Emacs development discussions." <emacs-devel@gnu.org>
writes:
> Hello,
>
> I am proposing a new package called electric-french [1]. This stemmed
> from a discussion on emacs-humanities [2], where Jean-Christophe
> ("l@tlo") outlined a few common practices on nonbreak spaces in the
> French language. See near the end of the message for the commentary
> section.
Perhaps just a general point, there is already a package on GNU ELPA
called "ef-themes", and it could be confusing if you use the "ef-"
prefix, since it is might make it appear to be a more
general/super-feature.
^ permalink raw reply [relevance 99%]
* Re: Extending define-derived-mode
@ 2023-06-05 8:30 90% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-06-05 8:30 UTC (permalink / raw)
To: Yuan Fu; +Cc: emacs-devel, Mickey Petersen, Theodor Thornhill, Dmitry Gutov
Yuan Fu <casouri@gmail.com> writes:
> When we were adding tree-sitter modes a couple of month ago, it was
> clear that the current major mode model needs some upgrade, I’d like
> to discuss the things we need and how can we address them.
Perhaps this is a stupid suggestion (since I am permanently behind on
developments wrt. tree-sitter), but might it be that the notions of
"major modes" just aren't strong enough of an abstraction to talk about
languages? Just like we have user options that have a relation to
regular variables, wouldn't it make sense to provide something like
"language modes" that would provide a higher-level and a more
specialised vocabulary.
This might also tie into the issue of inconsistent bindings for
semantically "analogous" operations between major modes (compiling,
opening a REPL, requesting documentation, etc.) or the issues of
duplicate configurations options that all raise the barrier when trying
out a new major mode or switching between languages.
^ permalink raw reply [relevance 90%]
* Re: [elpa] externals/denote 51bd02b95c 1/2: Add initial version of 'denote-rename-buffer' extension
@ 2023-05-28 11:51 97% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-05-28 11:51 UTC (permalink / raw)
To: Protesilaos Stavrou
Cc: Ruijie Yu via Emacs development discussions., Ruijie Yu
Protesilaos Stavrou <info@protesilaos.com> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Date: Sun, 28 May 2023 11:05:50 +0000
>>
>> Ruijie Yu via "Emacs development discussions." <emacs-devel@gnu.org>
>> writes:
>
>> [... 20 lines elided]
>
>>> I'm curious, should GNU elpa packages be considered part of Emacs or
>>> not? I have previously contributed to pyim, a GNU elpa package, whose
>>> maintainer asked me whether I had FSF CA before including my proposed
>>> changes, and whose package header says it is part of Emacs.
>>
>> I believe this is a mistake, the package is part of the GNU ELPA
>> repository, where all packages are regarded to be part of GNU Emacs. It
>> might be that Prot used a template to generate this file, and that the
>> template defaulted to "... is not a part ...".
>
> I didn't know this. To my mind, the modus-themes are "part of Emacs".
> The rest have copyright assigned to the FSF and, as such, "could be part
> of Emacs".
>
> I am happy to change this in all my packages.
I don't think the comment is necessary at all, or at least there are
plenty of packages (both part of GNU ELPA and not) that have neither "is
part" or "is NOT part" comments in the package header. But I think
Ruijie is justified in being confused that a GNU ELPA package claims not
to be part of Emacs.
^ permalink raw reply [relevance 97%]
* Re: [elpa] externals/denote 51bd02b95c 1/2: Add initial version of 'denote-rename-buffer' extension
@ 2023-05-28 11:05 98% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-05-28 11:05 UTC (permalink / raw)
To: Ruijie Yu via Emacs development discussions.
Cc: Protesilaos Stavrou, Ruijie Yu
Ruijie Yu via "Emacs development discussions." <emacs-devel@gnu.org>
writes:
> ELPA Syncer <elpasync@gnu.org> writes:
>
>> diff --git a/denote-rename-buffer.el b/denote-rename-buffer.el
>> new file mode 100644
>> index 0000000000..3582f33e9b
>> --- /dev/null
>> +++ b/denote-rename-buffer.el
>> @@ -0,0 +1,57 @@
>> +;;; denote-rename-buffer.el --- Rename Denote buffers to be shorter and easier to read -*- lexical-binding: t -*-
>> +
>> +;; Copyright (C) 2023 Free Software Foundation, Inc.
>> +
>> +;; Author: Protesilaos Stavrou <info@protesilaos.com>
>> +;; Maintainer: Denote Development <~protesilaos/denote@lists.sr.ht>
>> +;; URL: https://git.sr.ht/~protesilaos/denote
>> +;; Mailing-List: https://lists.sr.ht/~protesilaos/denote
>> +
>> +;; This file is NOT part of GNU Emacs.
>
> I'm curious, should GNU elpa packages be considered part of Emacs or
> not? I have previously contributed to pyim, a GNU elpa package, whose
> maintainer asked me whether I had FSF CA before including my proposed
> changes, and whose package header says it is part of Emacs.
I believe this is a mistake, the package is part of the GNU ELPA
repository, where all packages are regarded to be part of GNU Emacs. It
might be that Prot used a template to generate this file, and that the
template defaulted to "... is not a part ...".
^ permalink raw reply [relevance 98%]
* Re: [ELPA] New package: dict
@ 2023-05-25 19:10 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-05-25 19:10 UTC (permalink / raw)
To: Eshel Yaron; +Cc: emacs-devel, Eli Zaretskii
Eshel Yaron <me@eshelyaron.com> writes:
> Hi,
>
> I'm attaching a slightly updated patch to dictionary.el. The only
> change wrt to my previous patch is that `dictionary-match-word` now uses
> the new `external-completion-table` from Emacs 29 instead of
> `completion-table-dynamic` to allow leveraging arbitrary matching
> strategies that the dictionary server provides.
>
> For example, we can now set `dictionary-default-strategy` to the
> "soundex" matching strategy that dict.org provides to get completion
> candidates that sound similar to the minibuffer input (such as "tail",
> "tale" and "tell").
>
> I've also rebased onto master branch to avoid conflicts in etc/NEWS.
>
>
> From 749743aa703a98352cb12ad84c04c971b22ea44c Mon Sep 17 00:00:00 2001
> From: Eshel Yaron <me@eshelyaron.com>
> Date: Mon, 15 May 2023 21:04:21 +0300
> Subject: [PATCH v4] Add customization options for dictionary-search
>
> Allow users to customize 'dictionary-search' via several new
> customization options.
LGTM.
^ permalink raw reply [relevance 99%]
* Re: Builder, a build system integration for Emacs
@ 2023-05-24 10:26 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-05-24 10:26 UTC (permalink / raw)
To: David Masterson; +Cc: Richard Stallman, BTuin, emacs-devel
David Masterson <dsmasterson@gmail.com> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Richard Stallman <rms@gnu.org> writes:
>>
>>> [[[ To any NSA and FBI agents reading my email: please consider ]]]
>>> [[[ whether defending the US Constitution against all enemies, ]]]
>>> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>>>
>>> > As far as I know, Emacs does not provide a convenient way to use build
>>> > systems,
>>>
>>> Isn't "use build systems" what M-x compile does?
>>> Assuming that each bui;d system provides a shell command to invoke it,
>>> M-x compile can run that command and build the package.
>>
>> The issue is not what M-x compile, but that with a lot of modern
>> programming languages the build systems are complex but automatable, to
>> a point that it would be nice if Emacs could detect the necessary
>> information to invoke the right command or sequence of commands.
>
> Isn't this the province of EDE (Emacs Development Environment)?
I might be wrong, but I am under the impression that EDE is not actively
maintained, and that newer systems like project and Eglot have taken
over.
^ permalink raw reply [relevance 99%]
* Re: [nongnu] main 83410aacf7: * elpa-packages (devil): New package
@ 2023-05-24 6:41 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-05-24 6:41 UTC (permalink / raw)
To: Susam Pal; +Cc: Stefan Monnier, emacs-devel
Susam Pal <susam.pal@gmail.com> writes:
> Philip Kaludercic <philipk@posteo.net> wrote:
>>
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>
>> >>> + (devil :url "https://github.com/susam/devil"
>> >>> + :readme "README.org"
>> >>> + :news "CHANGES.org")
>> >>
>> >> We created a separate MANUAL.org file, is that ready to be used?
>> >
>> > If that works, then please add `:doc "MANUAL.org"`, of course.
>>
>> Susam, what do you say?
>
> Sorry for the delay in responding to this. I was away for a while.
No problem.
> Yes, I think it is good to add `:doc "MANUAL.org"`.
Done.
^ permalink raw reply [relevance 99%]
* Re: Inferred function types in the *Help* buffer
@ 2023-05-23 18:51 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-05-23 18:51 UTC (permalink / raw)
To: Payas Relekar; +Cc: Andrea Corallo, emacs-devel
Payas Relekar <relekarpayas@gmail.com> writes:
> Andrea Corallo <akrl@sdf.org> writes:
>
>> ====
>> foo is a native-compiled Lisp function in
>> ‘~/.emacs.d/eln-cache/30.0.50-e29d76eb/test-a526a80f-5481bc95.eln’.
>>
>> Signature: (foo N)
>>
>> Inferred type: (function (t) (or (member to-small too-big) (integer
>> 100 100)))
>>
>> ...
>> ====
>
> Pretty cool.
>
> Tangentially, there's also Elsa: https://github.com/emacs-elsa/Elsa
>
> How feasible would you say it would be to integrate it within
> Emacs/native-compiler?
Elsa? In a recent discussion[0] the author (Matus Goljer) told me this:
> Elsa is complex and it currently can't run from user session Emacs and
> most likely never will. There is many ways to run Elsa mentioned in
> the Readme. Currently no other ways are supported, but I'm sure it's
> possible. Elsa is not a linter like "checkdoc", it is a full
> evaluation engine for Emacs Lisp, it's a gradual type system, it's a
> language server, it's a refactoring tool. It will be more things in
> the future. You should imagine it being a separate program that you
> run alongside Emacs, not inside Emacs.
[0] https://github.com/emacs-elsa/Elsa/issues/218#issuecomment-1470421487
> Regards,
> Payas
>
> --
^ permalink raw reply [relevance 99%]
* Re: Builder, a build system integration for Emacs
@ 2023-05-23 8:36 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-05-23 8:36 UTC (permalink / raw)
To: Richard Stallman; +Cc: BTuin, emacs-devel
Richard Stallman <rms@gnu.org> writes:
> [[[ To any NSA and FBI agents reading my email: please consider ]]]
> [[[ whether defending the US Constitution against all enemies, ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> > As far as I know, Emacs does not provide a convenient way to use build
> > systems,
>
> Isn't "use build systems" what M-x compile does?
> Assuming that each bui;d system provides a shell command to invoke it,
> M-x compile can run that command and build the package.
The issue is not what M-x compile, but that with a lot of modern
programming languages the build systems are complex but automatable, to
a point that it would be nice if Emacs could detect the necessary
information to invoke the right command or sequence of commands.
^ permalink raw reply [relevance 99%]
* Re: [PROPOSAL] Builder, a build system integration for Emacs
@ 2023-05-21 12:11 99% ` Philip Kaludercic
1 sibling, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-05-21 12:11 UTC (permalink / raw)
To: BTuin; +Cc: emacs-devel
Your proposal sounds interesting, and I think it is worth adding to GNU
or NonGNU ELPA. Do you have a preference? Also, it would be nice if
you could host the files in a Git repository somewhere, so that the ELPA
build-system can mirror your changes.
^ permalink raw reply [relevance 99%]
* Re: [ELPA] New package: dict
@ 2023-05-20 19:11 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-05-20 19:11 UTC (permalink / raw)
To: Eshel Yaron; +Cc: Eli Zaretskii, emacs-devel
Eshel Yaron <me@eshelyaron.com> writes:
>>> +(defcustom dictionary-display-definition-function nil
>>> + "Function to use for displaying dictionary definitions.
>>> +It is called with three string arguments: the word being defined,
>>> +the dictionary name, and the full definition."
>>> + :type '(choice (const :tag "Dictionary buffer" nil)
>>> + (const :tag "Help buffer"
>>> + dictionary-display-definition-in-help-buffer)
>>> + (function :tag "Custom function"))
>>> + :version "30.1")
>>
>> What is the reason for having this option fallback to nil? I couldn't
>> make that out from the patch. If all the other options offer a
>> concrete-default function (that you could also call in your own
>> function), then it seems inconsistent to not provide this here as well.
>
> The reason is that, unlike the other options, the default path that
> `dictionary-search` takes to displaying a definition is highly coupled
> with how it obtains the definition, making it difficult to extract into
> a standalone function. That's a refactor I prefer to avoid at this
> point. So, if you set `dictionary-display-definition-function` to a
> custom function, we use the new function `dictionary-define-word` to
> cleanly obtain the definition and let your custom function display it.
> If you use the default (nil) value, we let `dictionary-search` call the
> "old" function `dictionary-new-search` that both obtains and displays
> the definition.
OK, I am not familiar with the code and I get that it could take too
much effort to refactor this properly right now.
>>> +(defun dictionary-define-word (word dictionary)
>>> + "Return the definition of WORD in DICTIONARY, or nil if not found."
>>> + (dictionary-send-command
>>> + (format "define %s \"%s\"" dictionary word))
>>> + (when (and (= (read (dictionary-read-reply)) 150)
>>> + (= (read (dictionary-read-reply)) 151))
>>
>> I think a memq would be nice here.
>>
>
> No, `memq` would be appropriate if we wanted to check that the
> expression `(read (dictionary-read-reply))` evaluates to either 150 or
> to 151, but here we want to check that it evaluates 150 and then
> afterwards that it evaluates to 151.
Whoops, misread that as and `or' and forgot about side-effects.
>>> +(defun dictionary-display-definition-in-help-buffer (word dictionary definition)
>>> + "Display DEFINITION, the definition of WORD in DICTIONARY."
>>> + (let ((help-buffer-under-preparation t))
>>> + (help-setup-xref (list #'dictionary-search word dictionary)
>>> + (called-interactively-p 'interactive))
>>> + (with-help-window (help-buffer)
>>> + (with-current-buffer (help-buffer)
>>> + (insert definition)
>>> + (goto-char (point-min))
>>> + (while (re-search-forward (rx "{"
>>> + (group-n 1 (* (not (any ?}))))
>>> + "}")
>>> + nil t)
>>
>> Perhaps you could explain what is going on here. Why is this pattern
>> significant?
>
> We want to buttonize references to other definitions in the *Help*
> buffer, which appear enclosed in curly braces. I've added a comment
> explaining this.
So the protocol always wraps other definitions in curly braces?
^ permalink raw reply [relevance 99%]
* Re: Naming guidelines for ELPA packages
@ 2023-05-20 16:51 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-05-20 16:51 UTC (permalink / raw)
To: Akib Azmain Turja
Cc: Jim Porter, rms, eliz, relekarpayas, susam.pal, emacs-devel
Akib Azmain Turja <akib@disroot.org> writes:
> Jim Porter <jporterbugs@gmail.com> writes:
>
>> On 5/14/2023 12:33 PM, Philip Kaludercic wrote:
>>> Jim Porter <jporterbugs@gmail.com> writes:
>>>
>>>> I think I need to adjust the passage a bit to emphasize that the
>>>> Emacs/ELPA maintainers would *prefer* a simple and straightforward
>>>> name like "gobject". ...
>>> That would sound acceptable to me.
>>
>> Ok, how about something like the following? I just expanded it a bit
>> to provide more context and adjusted the wording slightly here and
>> there (for example, these are now "recommendations" instead of
>> "guidelines").
>>
>> ----------------------------------------
>>
>> Naming is hard. However, taking some time to choose a good name for
>> your package will help make your package easier to find and to use. To
>> assist package authors, here are some recommendations for choosing
>> good Emacs package names. Package names should be:
>>
>> * Memorable: Aim for short, distinct names that users can easily recall.
>> * Intuitive: Names don't need to fully describe a package, but they
>> should at least provide a hint about what the package does.
>>
>> For example, suppose I've written a package that provides an interface
>> between GObjects and Emacs Lisp, and named it "goeli". This isn't a
>> very good name, since it's not easy to remember (users may find
>> themselves asking, "Wait... was it 'goli' or 'goeli'?"), and it's
>> nearly impossible to guess what it does from the name.
>>
>> After thinking about it some more, I have a flash of insight: I'll
>> call it "goblin" (for _GOb_ject _L_isp _In_terface)! This is easy
>> enough to remember, but it's still not intuitive.
>>
>> Perhaps the best name for a package like this would simply be
>> "gobject". That's both memorable *and* intuitive, not to mention being
>> as straightforward as you can get. If possible, the ELPA maintainers
>> recommend that you choose a name like this.
>>
>> However, suppose that at this point, I find myself disappointed: while
>> "gobject" is a thoroughly practical name, I just don't want to give up
>> the name "goblin". Instead, I could opt for a compromise: I'll still
>> use "Goblin" when documenting the package and prefix names in my code
>> with "goblin-", but I decide to submit it to GNU ELPA as
>> "goblin-gobject". While this isn't as concise as "gobject", it does
>> let the user know right away that this package has something to do
>> with GObjects.
>>
>
> The example name you suggested, "gobject", is indeed a good name, but
> there's a little problem that if someone ever comes up with a better
> package, it won't find any name for itself.
One could argue this would help preventing NIH and encouraging people to
contribute to existing projects.
^ permalink raw reply [relevance 99%]
* Re: [ELPA] New package: dict
@ 2023-05-20 16:49 91% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-05-20 16:49 UTC (permalink / raw)
To: Eshel Yaron; +Cc: Eli Zaretskii, emacs-devel
Eshel Yaron <me@eshelyaron.com> writes:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> I've added these options in the patch because I want to have minibuffer
>>> completions in `dictionary-search`'s prompts, similarly to
>>> `dict-describe-word`. That's also why I mentioned all three
>>> customizations in my earlier message: to show how to obtain the behavior
>>> of `dict-describe-word` in dictionary.el using the new user options.
>>>
>>> But from the perspective of other dictionary.el users, it may be useful
>>> to customize each of the options but not the necessarily all of them.
>>> That's why I implemented them as separate user options. Makes sense?
>>
>> AFAIR, this started from you proposing a package that would behave as
>> if all 3 options were customized, and saying that you like this
>> alternative behavior much better, so much so that you felt a new
>> package is in order. So I'm asking why not let users who, like you,
>> will like that much better, to get that behavior, with all its bells
>> and whistles, by setting just one option? Wouldn't you personally
>> like such an option and use it all the time?
>
> Yes, I see what you mean. I'm attaching an updated patch that
> implements your suggestion to add another `defcustom` with an
> appropriate :set function. It's now enough to do:
>
> (setopt dictionary-search-interface 'help)
>
> The updated patch also tries to address Philip's recommendation to
> extract the default parts of `dictionary-search` to standalone
> functions.
>
> From 2bbd1767594990357f61d4af467093bf6abb117e Mon Sep 17 00:00:00 2001
> From: Eshel Yaron <me@eshelyaron.com>
> Date: Mon, 15 May 2023 21:04:21 +0300
> Subject: [PATCH v2] Add customization options for dictionary-search
>
> Allow users to customize 'dictionary-search' via several new
> customization options.
>
> * lisp/net/dictionary.el (dictionary-define-word)
> (dictionary-match-word)
> (dictionary-completing-read-word)
> (dictionary-dictionaries)
> (dictionary-completing-read-dictionary)
> (dictionary-display-definition-in-help-buffer): New functions.
> (dictionary-read-word-prompt)
> (dictionary-display-definition-function)
> (dictionary-read-word-function)
> (dictionary-read-dictionary-function)
> (dictionary-search-interface): New user options.
> (dictionary-search): Use them.
> (dictionary-read-dictionary-default)
> (dictionary-read-word-default): New functions, extracted from
> 'dictionary-search'.
Shouldn't these Changelog entries be folded together?
* lisp/net/dictionary.el (dictionary-define-word, dictionary-match-word,
dictionary-completing-read-word, dictionary-dictionaries,
dictionary-completing-read-dictionary,
dictionary-display-definition-in-help-buffer): New functions.
> * etc/NEWS: Announce.
> ---
> etc/NEWS | 44 +++++++++
> lisp/net/dictionary.el | 197 +++++++++++++++++++++++++++++++++++++----
> 2 files changed, 226 insertions(+), 15 deletions(-)
>
> diff --git a/etc/NEWS b/etc/NEWS
> index f1fb70c5fc6..b673ac54ef3 100644
> --- a/etc/NEWS
> +++ b/etc/NEWS
> @@ -333,6 +333,50 @@ instead of:
> *** New ':vc' keyword.
> This keyword enables the user to install packages using 'package-vc'.
>
> +** Dictionary
> +
> +---
> +*** New user option 'dictionary-search-interface'.
> +Controls how the 'dictionary-search' command prompts for and displays
> +dictionary definitions. Customize this user option to 'help' to have
> +'dictionary-search' display definitions in a *Help* buffer and provide
> +dictionary-based minibuffer completion for word selection.
> +
> +---
> +*** New user option 'dictionary-read-word-prompt'.
> +This allows the user to customize the prompt that is used by
> +'dictionary-search' when asking for a word to search in the
> +dictionary.
> +
> +---
> +*** New user option 'dictionary-display-definition-function'.
> +This allows the user to customize the way in which 'dictionary-search'
> +displays word definitions. If non-nil, this user option should be set
> +to a function that displays a word definition obtained from a
> +dictionary server. The new function
> +'dictionary-display-definition-in-help-buffer' can be used to display
> +the definition in a *Help* buffer, instead of the default *Dictionary*
> +buffer.
> +
> +---
> +*** New user option 'dictionary-read-word-function'.
> +This allows the user to customize the way in which 'dictionary-search'
> +prompts for a word to search in the dictionary. This user option
> +should be set to a function that lets the user select a word and
> +returns it as a string. The new function
> +'dictionary-completing-read-word' can be used to prompt with
> +completion based on dictionary matches.
> +
> +---
> +*** New user option 'dictionary-read-dictionary-function'.
> +This allows the user to customize the way in which 'dictionary-search'
> +prompts for a dictionary to search in. This user option should be set
> +to a function that lets the user select a dictionary and returns its
> +name as a string. The new function
> +'dictionary-completing-read-dictionary' can be used to prompt with
> +completion based on dictionaries that the server supports.
> +
> +
> \f
> * New Modes and Packages in Emacs 30.1
>
> diff --git a/lisp/net/dictionary.el b/lisp/net/dictionary.el
> index ba65225692a..fafcd0f2594 100644
> --- a/lisp/net/dictionary.el
> +++ b/lisp/net/dictionary.el
> @@ -38,6 +38,7 @@
> (require 'custom)
> (require 'dictionary-connection)
> (require 'button)
> +(require 'help-mode)
>
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> ;; Stuff for customizing.
> @@ -247,6 +248,64 @@ dictionary-coding-systems-for-dictionaries
> )))
> :version "28.1")
>
> +(defcustom dictionary-read-word-prompt "Search word"
> + "Prompt string to use when prompting for a word."
> + :type 'string
> + :version "30.1")
> +
> +(defcustom dictionary-display-definition-function nil
> + "Function to use for displaying dictionary definitions.
> +It is called with three string arguments: the word being defined,
> +the dictionary name, and the full definition."
> + :type '(choice (const :tag "Dictionary buffer" nil)
> + (const :tag "Help buffer"
> + dictionary-display-definition-in-help-buffer)
> + (function :tag "Custom function"))
> + :version "30.1")
What is the reason for having this option fallback to nil? I couldn't
make that out from the patch. If all the other options offer a
concrete-default function (that you could also call in your own
function), then it seems inconsistent to not provide this here as well.
> +(defcustom dictionary-read-word-function #'dictionary-read-word-default
> + "Function to use for prompting for a word.
> +It is called with one string argument, the name of the dictionary to use, and
> +must return a string."
> + :type '(choice (const :tag "Default" dictionary-read-word-default)
> + (const :tag "Dictionary-based completion"
> + dictionary-completing-read-word)
> + (function :tag "Custom function"))
> + :version "30.1")
> +
> +(defcustom dictionary-read-dictionary-function
> + #'dictionary-read-dictionary-default
> + "Function to use for prompting for a dictionary.
> +It is called with no arguments and must return a string."
> + :type '(choice (const :tag "Default" dictionary-read-dictionary-default)
> + (const :tag "Choose among server-provided dictionaries"
> + dictionary-completing-read-dictionary)
> + (function :tag "Custom function"))
> + :version "30.1")
> +
> +(defcustom dictionary-search-interface nil
> + "Controls how `dictionary-search' prompts for words and displays definitions.
> +
> +When set to `help', `dictionary-search' displays definitions in a *Help* buffer,
> +and provides completion for word selection based on dictionary matches.
> +
> +Otherwise, `dictionary-search' displays definitions in a *Dictionary* buffer."
> + :type '(choice (const :tag "Dictionary buffer" nil)
> + (const :tag "Help buffer" help))
> + :set (lambda (symbol value)
> + (let ((vals (pcase value
> + ('help '(dictionary-display-definition-in-help-buffer
> + dictionary-completing-read-word
> + dictionary-completing-read-dictionary))
> + (_ '(nil
> + dictionary-read-word-default
> + dictionary-read-dictionary-default)))))
> + (setq dictionary-display-definition-function (nth 0 vals)
> + dictionary-read-word-function (nth 1 vals)
> + dictionary-read-dictionary-function (nth 2 vals)))
I think you could also make use of seq-setq here?
> + (set-default-toplevel-value symbol value))
> + :version "30.1")
> +
> (defface dictionary-word-definition-face
> '((((supports (:family "DejaVu Serif")))
> (:family "DejaVu Serif"))
> @@ -366,6 +425,8 @@ dictionary-word-history
> '()
> "History list of searched word.")
>
> +(defvar dictionary--last-match nil)
> +
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> ;; Basic function providing startup actions
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> @@ -1139,6 +1200,20 @@ dictionary-search-default
> ((car (get-char-property (point) 'data)))
> (t (current-word t))))
>
> +(defun dictionary-read-dictionary-default ()
> + "Prompt for a dictionary name."
> + (read-string (if dictionary-default-dictionary
> + (format "Dictionary (%s): "
> + dictionary-default-dictionary)
> + "Dictionary: ")
> + nil nil dictionary-default-dictionary))
> +
> +(defun dictionary-read-word-default (_dictionary)
> + "Prompt for a word to search in the dictionary."
> + (let ((default (dictionary-search-default)))
> + (read-string (format-prompt dictionary-read-word-prompt default)
> + nil 'dictionary-word-history default)))
> +
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> ;; User callable commands
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> @@ -1149,23 +1224,22 @@ dictionary-search
> It presents the selection or word at point as default input and
> allows editing it."
> (interactive
> - (list (let ((default (dictionary-search-default)))
> - (read-string (format-prompt "Search word" default)
> - nil 'dictionary-word-history default))
> - (if current-prefix-arg
> - (read-string (if dictionary-default-dictionary
> - (format "Dictionary (%s): " dictionary-default-dictionary)
> - "Dictionary: ")
> - nil nil dictionary-default-dictionary)
> - dictionary-default-dictionary)))
> -
> - ;; if called by pressing the button
> - (unless word
> - (setq word (read-string "Search word: " nil 'dictionary-word-history)))
> - ;; just in case non-interactively called
> + (let ((dict
> + (if current-prefix-arg
> + (funcall dictionary-read-dictionary-function)
> + dictionary-default-dictionary)))
> + (list (funcall dictionary-read-word-function dict) dict)))
> (unless dictionary
> (setq dictionary dictionary-default-dictionary))
> - (dictionary-new-search (cons word dictionary)))
> + (if dictionary-display-definition-function
> + (if-let ((definition (dictionary-define-word word dictionary)))
> + (funcall dictionary-display-definition-function word dictionary definition)
> + (user-error "No definition found for \"%s\"" word))
> + ;; if called by pressing the button
> + (unless word
> + (setq word (read-string "Search word: " nil 'dictionary-word-history)))
> + ;; just in case non-interactively called
> + (dictionary-new-search (cons word dictionary))))
>
> ;;;###autoload
> (defun dictionary-lookup-definition ()
> @@ -1386,5 +1460,98 @@ dictionary-context-menu
> 'dictionary-separator))
> menu)
>
> +(defun dictionary-define-word (word dictionary)
> + "Return the definition of WORD in DICTIONARY, or nil if not found."
> + (dictionary-send-command
> + (format "define %s \"%s\"" dictionary word))
> + (when (and (= (read (dictionary-read-reply)) 150)
> + (= (read (dictionary-read-reply)) 151))
I think a memq would be nice here.
> + (dictionary-read-answer)))
> +
> +(defun dictionary-match-word (word)
> + "Return dictionary matches for WORD as a list of strings."
> + (unless (string-empty-p word)
> + (if (string= (car dictionary--last-match) word)
> + (cdr dictionary--last-match)
> + (dictionary-send-command
> + (format "match %s %s \"%s\""
> + dictionary-default-dictionary
> + dictionary-default-strategy
> + word))
> + (when (and (= (read (dictionary-read-reply)) 152))
> + (with-temp-buffer
> + (insert (dictionary-read-answer))
> + (goto-char (point-min))
> + (let ((result nil))
> + (while (not (eobp))
> + (search-forward " " nil t)
> + (push (read (current-buffer)) result)
> + (search-forward "\n" nil t))
> + (setq result (reverse result))
> + (setq dictionary--last-match (cons word result))
> + result))))))
> +
> +(defun dictionary-completing-read-word (dictionary)
> + "Prompt for a word with completion based on matches in DICTIONARY."
> + (let* ((completion-ignore-case t)
> + (dictionary-default-dictionary dictionary)
> + (word-at-point (thing-at-point 'word t))
> + (default (dictionary-match-word word-at-point)))
> + (completing-read (format-prompt dictionary-read-word-prompt default)
> + (completion-table-dynamic #'dictionary-match-word)
> + nil t nil 'dictionary-word-history default t)))
> +
> +(defun dictionary-dictionaries ()
> + "Return the list of dictionaries the server supports."
> + (dictionary-send-command "show db")
> + (when (and (= (read (dictionary-read-reply)) 110))
> + (with-temp-buffer
> + (insert (dictionary-read-answer))
> + (goto-char (point-min))
> + (let ((result '(("!" . "First matching dictionary")
> + ("*" . "All dictionaries"))))
> + (while (not (eobp))
> + (push (cons (buffer-substring
> + (search-forward "\n" nil t)
> + (1- (search-forward " " nil t)))
> + (read (current-buffer)))
> + result))
> + (reverse result)))))
> +
> +(defun dictionary-completing-read-dictionary ()
> + "Prompt for a dictionary the server supports."
> + (let* ((dicts (dictionary-dictionaries))
> + (len (apply #'max (mapcar #'length (mapcar #'car dicts))))
> + (completion-extra-properties
> + (list :annotation-function
> + (lambda (key)
> + (concat (make-string (1+ (- len (length key))) ?\s)
> + (alist-get key dicts nil nil #'string=))))))
> + (completing-read (format-prompt "Select dictionary"
> + dictionary-default-dictionary)
> + dicts nil t nil nil dictionary-default-dictionary)))
> +
> +(define-button-type 'help-word
> + :supertype 'help-xref
> + 'help-function 'dictionary-search
> + 'help-echo (purecopy "mouse-2, RET: describe this word"))
Why the purecopy?
> +(defun dictionary-display-definition-in-help-buffer (word dictionary definition)
> + "Display DEFINITION, the definition of WORD in DICTIONARY."
> + (let ((help-buffer-under-preparation t))
> + (help-setup-xref (list #'dictionary-search word dictionary)
> + (called-interactively-p 'interactive))
> + (with-help-window (help-buffer)
> + (with-current-buffer (help-buffer)
> + (insert definition)
> + (goto-char (point-min))
> + (while (re-search-forward (rx "{"
> + (group-n 1 (* (not (any ?}))))
> + "}")
> + nil t)
Perhaps you could explain what is going on here. Why is this pattern
significant?
> + (help-xref-button 1 'help-word
> + (match-string 1)
> + dictionary))))))
> +
> (provide 'dictionary)
> ;;; dictionary.el ends here
> --
> 2.40.1
^ permalink raw reply [relevance 91%]
* Re: [ELPA] New package: dict
@ 2023-05-18 15:58 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-05-18 15:58 UTC (permalink / raw)
To: Eshel Yaron; +Cc: Eli Zaretskii, emacs-devel
Eshel Yaron <me@eshelyaron.com> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Would there be a point in implementing the previous, default
>> implementations as functions here that would be invoked, instead of
>> relying using nil?
>
> I'm not sure, I think these default functions wouldn't be very useful on
> their own, so I don't know if it's worth extracting them. But of course
> we can do it if there's some important benefit I'm missing.
I would imagine that if you wanted to extend the default functionality,
e.g. by binding some variable or whatever one might want, having this
available as a function you can just call, would be useful.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: [GNU ELPA] New package: Urgrep
@ 2023-05-18 13:23 95% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-05-18 13:23 UTC (permalink / raw)
To: Richard Stallman; +Cc: jporterbugs, emacs-devel
Richard Stallman <rms@gnu.org> writes:
> [[[ To any NSA and FBI agents reading my email: please consider ]]]
> [[[ whether defending the US Constitution against all enemies, ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> > Since this is just an brief, internal comment in elpa-admin.el, I
> > wouldn't be that concerned. I believe it is justified to assume that
> > everyone working on the script knows what this means.
>
> It is not unusual for people who don't kow the internals of a program
> to read its code to learn to understand it. So how about changing
> those lines to make that learning easier? Please give future
> maintainers a break!
I started working on ELPA about two years ago, and comments like these
were never an issue. Of course in this individual case it can be
changed, but generally speaking I would consider the ability to
understand what a comment like this means a pre-requisite for being able
to hack on a file like elpa-admin.el, as it "proves" familiarity with
Elisp packaging and conventions around Emacs packages.
Or perhaps I am misunderstanding you, what exactly do you find confusing
about comments like these in general?
--
Philip Kaludercic
^ permalink raw reply [relevance 95%]
* Re: [ELPA] New package: calibre.el
@ 2023-05-18 13:01 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-05-18 13:01 UTC (permalink / raw)
To: Kjartan Óli Águstsson; +Cc: emacs-devel
Kjartan Óli Águstsson <kjartanoli@outlook.com> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> $ git clone https://git.disroot.org/kjartanoli/calibre.el
>> Cloning into 'calibre.el'...
>> fatal: repository 'https://git.disroot.org/kjartanoli/calibre.el/' not found
>>
>> Did something change since your last message. Sorry for the delay, but
>> I just got around to packaging it now.
>
> No worries about the delay. No nothing has changed that I'm aware of,
> and the command succeeds on my end. I can push to some other git host
> if you think that would solve it.
This might have been a temporary issue, I can clone it now. So unless
you have any ideas what the issue was, or if there is reason to suspect
it might occur again, then we can leave it as it is.
> Should I push a commit changing the
> copyright headers to list the FSF as the copyright holder?
Yes, along with a commit that would update the Version header.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: [ELPA] New package: dict
@ 2023-05-18 12:59 99% ` Philip Kaludercic
1 sibling, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-05-18 12:59 UTC (permalink / raw)
To: Eshel Yaron; +Cc: Eli Zaretskii, emacs-devel
Eshel Yaron <me@eshelyaron.com> writes:
> diff --git a/lisp/net/dictionary.el b/lisp/net/dictionary.el
> index ba65225692a..adf1f409f26 100644
> --- a/lisp/net/dictionary.el
> +++ b/lisp/net/dictionary.el
> @@ -38,6 +38,7 @@
> (require 'custom)
> (require 'dictionary-connection)
> (require 'button)
> +(require 'help-mode)
>
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> ;; Stuff for customizing.
> @@ -247,6 +248,39 @@ dictionary-coding-systems-for-dictionaries
> )))
> :version "28.1")
>
> +(defcustom dictionary-read-word-prompt "Search word"
> + "Prompt string to use when prompting for a word."
> + :type 'string
> + :version "30.1")
> +
> +(defcustom dictionary-display-definition-function nil
> + "Function to use for displaying dictionary definitions.
> +It is called with three string arguments: the word being defined,
> +the dictionary name, and the full definition."
> + :type '(choice (const :tag "Dictionary buffer" nil)
> + (const :tag "Help buffer"
> + dictionary-display-definition-in-help-buffer)
> + (function :tag "Custom function"))
> + :version "30.1")
> +
> +(defcustom dictionary-read-word-function nil
> + "Function to use for prompting for a word.
> +It is called with no arguments and must return a string."
> + :type '(choice (const :tag "Default" nil)
> + (const :tag "Dictionary-based completion"
> + dictionary-completing-read-word)
> + (function :tag "Custom function"))
> + :version "30.1")
> +
> +(defcustom dictionary-read-dictionary-function nil
> + "Function to use for prompting for a dictionary.
> +It is called with no arguments and must return a string."
> + :type '(choice (const :tag "Default" nil)
> + (const :tag "Choose among server-provided dictionaries"
> + dictionary-completing-read-dictionary)
> + (function :tag "Custom function"))
> + :version "30.1")
Would there be a point in implementing the previous, default
implementations as functions here that would be invoked, instead of
relying using nil?
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: [NonGNU ELPA] New package: devil
@ 2023-05-17 14:06 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-05-17 14:06 UTC (permalink / raw)
To: João Távora; +Cc: Susam Pal, emacs-devel
João Távora <joaotavora@gmail.com> writes:
> FWIW i agree with you on all points.
>
> It's important for packages to be allowed to keep the names the developers
> baptized them with.
Important in what sense? There have frequently been authors that have
changed the names of their packages when this was suggested to them, so
it doesn't like it was important for them. People are making a bigger
deal out of quirky names than it should be.
^ permalink raw reply [relevance 99%]
* Re: [ELPA] New package: dict
@ 2023-05-16 19:38 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-05-16 19:38 UTC (permalink / raw)
To: Eshel Yaron; +Cc: emacs-devel
Eshel Yaron <me@eshelyaron.com> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Eshel Yaron <me@eshelyaron.com> writes:
>>
>>> Philip Kaludercic <philipk@posteo.net> writes:
>>>
>>>> Eshel Yaron <me@eshelyaron.com> writes:
>>>>
>>>>> + (dict :url "git://git.eshelyaron.com/dict.git"
>>>>
>>>> Do you have any other access method beside git://?
>>>
>>> For anonymous access, currently no. But I can mirror the repo to
>>> Sourcehut from where you can clone it via HTTPS. Would that be more
>>> convenient?
>>
>> That would be good, my understanding is that git:// is not encrypted so
>> we should avoid using it if possible.
>
>>>>> + :doc "README.org")
>>>>
>>>> Should we add a ":readme ignore" to prevent the contents of this file
>>>> from also appearing when the user invokes C-h P dict RET ?
>>>
>>> Sure, in this case would C-h P show the commentary section of dict.el?
>>
>> Right. Feel free to extend that with pointers, I just think we should
>> avoid overwhelming users with the entire documentation if they just want
>> to get the basic gist of a package.
>
> Alright, I'm attaching a new patch that addresses both these points.
>
> From 2466225fd527e3748c266307d6858407011105f5 Mon Sep 17 00:00:00 2001
> From: Eshel Yaron <me@eshelyaron.com>
> Date: Thu, 11 May 2023 14:20:16 +0300
> Subject: [PATCH v2] * elpa-packages (dict): New package
>
> ---
> elpa-packages | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/elpa-packages b/elpa-packages
> index d5603f7803..637d71685e 100644
> --- a/elpa-packages
> +++ b/elpa-packages
> @@ -201,6 +201,9 @@
> :news "CHANGELOG.org"
> :readme "README.md")
> (devdocs :url "https://github.com/astoff/devdocs.el")
> + (dict :url "https://git.sr.ht/~eshel/dict"
> + :doc "README.org"
> + :readme ignore)
> (dict-tree :url "http://www.dr-qubit.org/git/predictive.git"
> :manual-sync t ;; The upstream doesn't exist any more!
> )
> --
> 2.40.1
So what is the resolution here. Are we to add this as an additional
package to GNU ELPA, or is the intention to merge dictionary and dict?
^ permalink raw reply [relevance 99%]
* Re: [ELPA] New package: calibre.el
@ 2023-05-16 19:38 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-05-16 19:38 UTC (permalink / raw)
To: Kjartan Óli Águstsson; +Cc: emacs-devel
Kjartan Óli Águstsson <kjartanoli@outlook.com> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> I don't think so, but I have forgotten the details of the proposal. You
>> have signed your FSF CA, right? Also, could you give me the URL again?
>
> https://git.disroot.org/kjartanoli/calibre.el
$ git clone https://git.disroot.org/kjartanoli/calibre.el
Cloning into 'calibre.el'...
fatal: repository 'https://git.disroot.org/kjartanoli/calibre.el/' not found
Did something change since your last message. Sorry for the delay, but
I just got around to packaging it now.
> The short summary is that calibre.el enables a user to interact with a
> Calibre library from Emacs.
>
> I presume the copyright headers should be updated to list the FSF as the
> copyright holder?
^ permalink raw reply [relevance 99%]
* Re: [nongnu] main 83410aacf7: * elpa-packages (devil): New package
@ 2023-05-16 16:12 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-05-16 16:12 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel, Susam Pal
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> + (devil :url "https://github.com/susam/devil"
>>> + :readme "README.org"
>>> + :news "CHANGES.org")
>>
>> We created a separate MANUAL.org file, is that ready to be used?
>
> If that works, then please add `:doc "MANUAL.org"`, of course.
Susam, what do you say?
^ permalink raw reply [relevance 99%]
* Re: Getting email addresses obfuscated in patch attachments created by "git format-patch"
@ 2023-05-16 6:46 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-05-16 6:46 UTC (permalink / raw)
To: Jens Schmidt; +Cc: emacs-devel
Jens Schmidt <jschmidt4gnu@vodafonemail.de> writes:
> Emacs contribution policy recommends to attach patches created by "git
> format-patch". It seems that the email address contained in such
> patches is *not* automatically stripped by mailman or whatever
> presents the mailing list archives of emacs-devel or bug-gnu-emacs.
>
> Fiddling with "--from" to "git format-patch" does not seem to help, either.
>
> OTOH, I have seen some patches like Paul's in this message:
>
> https://lists.gnu.org/archive/html/emacs-devel/2016-01/msg01807.html
>
> where his email address is "obfuscated" to
>
> Paul Eggert <address@hidden>
>
> What causes this obfuscation? How to configure that? Manual
> post-processing of the patch with sed?
This problem doesn't appear with recent patches, perhaps something was
misconfigured in 2016?
> If it matters, I'd prefer to use Thunderbird to contribute patches ...
I think that should still be possible. I use Gnus or `vc-prepare-patch'
and frequently just attach patches without any issues.
> Thanks
>
> Jens
^ permalink raw reply [relevance 99%]
* Re: [GNU ELPA] New package: Urgrep
@ 2023-05-16 6:29 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-05-16 6:29 UTC (permalink / raw)
To: Richard Stallman; +Cc: Jim Porter, emacs-devel
Richard Stallman <rms@gnu.org> writes:
> [[[ To any NSA and FBI agents reading my email: please consider ]]]
> [[[ whether defending the US Constitution against all enemies, ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> > > > ;; Most README.md files seem to be currently worse than the Commentary:
> > > > ;; section :-( "README.md"
> > >
> > > Could someone please explain what that text is supposed to mean?
> > > I can't tell the intended meaning.
>
> > I think it just means that, for existing packages whose README file is
> > "README.md", the Commentary section of the main PACKAGE.el file usually
> > has more useful information. Therefore, ELPA chooses to ignore README.md
> > by default and show the Commentary section instead for applicable packages.
>
> That makes sense. Can we replace these terse and cryptic words
>
> > ;; Most README.md files seem to be currently worse than the Commentary:
> > ;; section :-( "README.md"
>
> with something clear like the text that you suggested above?
Since this is just an brief, internal comment in elpa-admin.el, I
wouldn't be that concerned. I believe it is justified to assume that
everyone working on the script knows what this means.
^ permalink raw reply [relevance 99%]
* Re: [nongnu] main 83410aacf7: * elpa-packages (devil): New package
[not found] ` <20230515161708.AD134C13919@vcs2.savannah.gnu.org>
@ 2023-05-15 16:21 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-05-15 16:21 UTC (permalink / raw)
To: emacs-devel; +Cc: Stefan Monnier, Susam Pal
Stefan Monnier via <emacs-elpa-diffs@gnu.org> writes:
> branch: main
> commit 83410aacf7dff71fcc3bff37e01269bb02122d9f
> Author: Stefan Monnier <monnier@iro.umontreal.ca>
> Commit: Stefan Monnier <monnier@iro.umontreal.ca>
>
> * elpa-packages (devil): New package
> ---
> elpa-packages | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/elpa-packages b/elpa-packages
> index c333cc8bb3..7d1fc2a797 100644
> --- a/elpa-packages
> +++ b/elpa-packages
> @@ -112,6 +112,10 @@
>
> (devhelp :url "https://codeberg.org/akib/emacs-devhelp")
>
> + (devil :url "https://github.com/susam/devil"
> + :readme "README.org"
> + :news "CHANGES.org")
We created a separate MANUAL.org file, is that ready to be used?
> +
> (diff-ansi :url "https://codeberg.org/ideasman42/emacs-diff-ansi"
> :ignored-files ("LICENSE"))
>
^ permalink raw reply [relevance 99%]
* Re: Naming guidelines for ELPA packages
@ 2023-05-14 19:33 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-05-14 19:33 UTC (permalink / raw)
To: Jim Porter; +Cc: rms, eliz, relekarpayas, susam.pal, emacs-devel
Jim Porter <jporterbugs@gmail.com> writes:
> On 5/14/2023 12:47 AM, Philip Kaludercic wrote:
>> I agree with everything up until the last paragraph, but am not
>> convinced that encouraging a "fun name" should be part of the
>> guidelines.
>
> I think I need to adjust the passage a bit to emphasize that the
> Emacs/ELPA maintainers would *prefer* a simple and straightforward
> name like "gobject". However, I also think it's important to show how
> you can come up with a good compromise if you're a package author who
> just can't let go of your fun package name. In my mind, showing in the
> documentation how to compromise on this would go a long way towards
> making package authors not feel like they're being micromanaged.
That would sound acceptable to me.
^ permalink raw reply [relevance 99%]
* Re: Naming guidelines for ELPA packages
@ 2023-05-14 7:47 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-05-14 7:47 UTC (permalink / raw)
To: Jim Porter; +Cc: rms, eliz, relekarpayas, susam.pal, emacs-devel
Jim Porter <jporterbugs@gmail.com> writes:
> On 5/13/2023 3:30 PM, Richard Stallman wrote:
>> [[[ To any NSA and FBI agents reading my email: please consider ]]]
>> [[[ whether defending the US Constitution against all enemies, ]]]
>> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>> > How about something like "devil-keys"? That should make it
>> clear that
>> > the package has something to do with keys. It doesn't tell exactly what
>> > it *does* with those keys, but I think a more-detailed description
>> > belongs in the package description or the manual.
>> I like this way of serving both goals at once: a clue about what the
>> job is,
>> and a name to distinguish this package from others for thatjob.
>>
>
> Maybe we could turn this into a general guideline, and document it
> somewhere on GNU ELPA (maybe the README). Something like the below? It
> could probably use some editorial work, but I thought an example
> "story" of choosing a package name might help explain things to
> readers.
I've suggested something like this in the past, but I can't find my
message. Either way, I think this is a good idea that could help avoid
a lot of bikeshedding.
> ----------------------------------------
>
> Naming is hard. To assist package authors, here are some guidelines
> for choosing good Emacs package names. Package names should be:
>
> * Memorable: Aim for short, distinct names that users can easily recall.
> * Intuitive: Names don't need to fully describe a package, but they
> should at least provide a hint about what the package does.
>
> For example, suppose I've written a package that provides an interface
> between GObjects and Emacs Lisp, and named it "goeli". This isn't a
> very good name, since it's not easy to remember (users may find
> themselves asking, "Wait... was it 'goli' or 'goeli'?"), and it's
> nearly impossible to guess what it does from the name.
>
> After thinking about it some more, I have a flash of insight: I'll
> call it "goblin" (for _GOb_ject _L_isp _In_terface)! This is easy
> enough to remember, but it's still not intuitive.
>
> Perhaps the best name for a package like this would simply be
> "gobject". That's both memorable *and* intuitive.
>
> However, after thinking about it yet again, I find myself
> disappointed: while "gobject" is a thoroughly practical name, it's
> just not very fun. Instead, I finally opt for a compromise: I'll still
> use "Goblin" when documenting the package and prefix names in my code
> with "goblin-", but I decide to submit it to GNU ELPA as
> "goblin-functions". While this isn't as descriptive as "gobject", it
> does at least provide a hint to the reader that this is a collection
> of functions (intended for other Lisp authors, as opposed to end
> users).
I agree with everything up until the last paragraph, but am not
convinced that encouraging a "fun name" should be part of the
guidelines.
^ permalink raw reply [relevance 99%]
* Re: [NonGNU ELPA] New package: devil
@ 2023-05-13 7:10 99% ` Philip Kaludercic
1 sibling, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-05-13 7:10 UTC (permalink / raw)
To: Jim Porter; +Cc: Eli Zaretskii, Payas Relekar, rms, susam.pal, emacs-devel
Jim Porter <jporterbugs@gmail.com> writes:
> On 5/10/2023 11:33 PM, Eli Zaretskii wrote:
>> Please reconsider, I think this name is very unfortunate, because it
>> gives users no clue whatsoever about the package's purpose.
>
> How about something like "devil-keys"? That should make it clear that
> the package has something to do with keys. It doesn't tell exactly
> what it *does* with those keys, but I think a more-detailed
> description belongs in the package description or the manual.
>
> Within the package itself, I think it would be fine to refer to it as
> "Devil" (without the "-keys"), since once you're looking at the
> package in detail, the "keys" hint isn't needed anymore.
I think this is a nice idea, and a good compromise.
^ permalink raw reply [relevance 99%]
* Re: [GNU ELPA] New package: Urgrep
@ 2023-05-13 7:09 99% ` Philip Kaludercic
1 sibling, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-05-13 7:09 UTC (permalink / raw)
To: Jim Porter; +Cc: rms, emacs-devel
Jim Porter <jporterbugs@gmail.com> writes:
> On 5/12/2023 2:52 PM, Richard Stallman wrote:
>> > ;; Most README.md files seem to be currently worse than the Commentary:
>> > ;; section :-( "README.md"
>> Could someone please explain what that text is supposed to mean?
>> I can't tell the intended meaning.
>
> I think it just means that, for existing packages whose README file is
> "README.md", the Commentary section of the main PACKAGE.el file
> usually has more useful information. Therefore, ELPA chooses to ignore
> README.md by default and show the Commentary section instead for
> applicable packages.
This is correct.
^ permalink raw reply [relevance 99%]
* Re: [NonGNU ELPA] New package: latex-table-wizard
@ 2023-05-12 15:46 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-05-12 15:46 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Enrico Flor, emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> The paperwork for the copyright assignment should be all done now, I
>>> have received confirmation from the FSF.
>
> Yay! and I even see you in the list!
> Thank you, Enrico.
>
>>> Is there anything else for me to do beside changing the copyright
>>> attribution in the source?
>>
>> That and bump the version tag.
>>
>> Your last message doesn't appear to be in my archive anymore, can you
>> send me the URL to your Git repository again?
>
> https://github.com/enricoflor/latex-table-wizard
>
> So, IIUC you're taking care of that?
> Thank you, Philip,
Thanks. Yes, I'll take care of it.
> Stefan
^ permalink raw reply [relevance 99%]
* Re: emacs-29 9b775ddc057 1/2: ; * etc/EGLOT-NEWS: Fix wording of last change.
@ 2023-05-12 6:43 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-05-12 6:43 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: Eli Zaretskii, monnier, emacs-devel
Dmitry Gutov <dmitry@gutov.dev> writes:
> On 11/05/2023 10:26, Philip Kaludercic wrote:
>> Dmitry Gutov<dmitry@gutov.dev> writes:
>>
>>> On 10/05/2023 14:03, Philip Kaludercic wrote:
>>>> I noticed a bug, here is a revised version:
>>> Should package-upgrade-all have a similar adjustment?
>> Why not? Didn't you have a patch that extended
>> `package--upgradeable-packages' by an optional argument, we could use
>> that here an just pass `package-install-upgrade-built-in'.
>
> I'd be happy to see commit 53cc61d60db backported from master.
In that case I guess it is better to leave it alone.
> Not crazy about the idea of adding a prefix argument to
> package-upgrade, though.
^ permalink raw reply [relevance 99%]
* Re: Names are not descriptions; descriptions are not names
@ 2023-05-12 6:42 68% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-05-12 6:42 UTC (permalink / raw)
To: Adam Porter; +Cc: emacs-devel
Adam Porter <adam@alphapapa.net> writes:
> There is no better way to doom software to obscurity than to give it a
> description as its name. Names are not descriptions; descriptions are
> not names.
I agree, but this is a strawman. As you are referring to the thread
about "devil-mode" from earlier this week, I'd argue the position was
not to find a name that perfectly describes the package, but to find a
name that is remotely related to the functionality of the package.
> Rarely, for a simple enough package, a short description may be a
> reasonable choice for a name. For example, "org-sticky-header"
> conveys that it's for Org mode and that it provides a sticky header.
> Assuming, that is, that the user knows what a "sticky header"
> is--otherwise, what should it be called?
> "org-header-line-that-shows-the-outline-path-at-the-top-of-the-window"?
I think that org-sticky-header is a fine name. I think that
"gecko-mode" would be a bad name, even though they are also sticky,
because understanding why the package was given the name is far easier
than inferring the scope of the functionality from the name.
> Now imagine one user trying to share that package with another user:
>
> Alice: "Hey, I found a package that I think you'll find useful:
> org-header-line-that-shows-the-outline-path-at-the-top-of-the-window."
>
> Bob: "Oh, that does sound useful. What's it called?"
>
> Alice: "I just told you."
>
> Bob: "Yes, but what's the name of the package?"
>
> Alice: "That's it."
>
> Bob: "No, I need the name so I can install it and try it."
>
> Alice: "I just told you the name."
>
> Bob: "No, you told me what it does."
>
> Alice: "Yes, but that's the name."
>
> (With apologies to Abbott and Costello.)
This is an argument against long names. The situation I usually have in
mind is when people cannot remember a name, because the name is
arbitrary. There is a reason why GNOME allows for both
application-specific names and generic names. I regularly use the
graphical file manager, but don't ask me what the proper name of the
application is. Something like "nemo" or "nautical"?
> I'm not merely joking, I'm also serious. This is a real problem.
>
> It's doubly a problem for a package that has similar functionality to
> existing packages. For example, with regard to "devil", the package
> recently proposed by Susam Pal, various alternative, ostensibly
> descriptive names have been proposed, like "key-transl",
> "no-modifier-mode", "prefixless-mode", "implicit-ctrl-mode", and
> "comma->control-mode". If one of those names were used, how would a
> user distinguish such a package from other packages that do similar
> things, such as viper, evil, god-mode, meow, boon, and the numerous
> other similar ones that are out there? (Note that, although I use
> none of those packages, I remember them because of their distinctive
> names; had they descriptions as names, I would not remember them, nor
> would I be able to easily find them again.) We're faced with the
> same problem:
>
> "Hey, I found a useful key-translate package. You should try it."
The issue here is that you are using an indefinite article. I think
Hey, I found a useful package called "key-translate". You should try it.
is a lot clearer.
> "Oh, I already use evil-mode."
>
> "No, not that one. This one."
>
> "Well, which one is it? There are a bunch of those, like viper,
> evil, god-mode, meow, boon..."
>
> "key-translate."
>
> "Yes, I understand that it does that, but what is it called?"
>
> "The name itself is key-translate."
>
> And that brings us back to the heart of the issue: "Oh, ok. So how is
> it different than viper, evil, god-mode, meow, or boon?" That is, the
> user must read the description (or even the whole readme) to
> understand what the package does. The name is not enough; the name is
> never enough.
>
> And by burdening the name with a responsibility it cannot bear, the
> name suffers, the package suffers, and ultimately, the user suffers.
> The "descriptive" name is not memorable; the user likely forgets what
> it's called a few weeks after installing and configuring it (who
> hasn't experienced this already: installing a package, configuring it,
> and then forgetting about it, finally being unable to remember the
> name of the package that does the thing that one suddenly needs the
> functionality of again, having to search ELPA or MELPA for such a
> tool, and then discovering that one already has it--well, maybe it's
> just me).
>
> Of course, it's a laudable goal to reduce confusion for users. Yet,
> although Ed is the standard editor, do we not use Emacs? What do
> potential users say about that? "Didn't Apple stop making those a
> long time ago?" Are they not confused? Should we rename Emacs to
> gnu-lisp-machine-with-built-in-editor? Would we not shorten such a
> name to GLiMBiE? And would such a name be descriptive?
There is a counter-tendency to what I mentioned above, and that is that
over time popular names become descriptive in and of itself. Take
"grep", while we might know what it means and where the name came from,
most people have to memorise the name. But this ends up being
acceptable, since the term is so widespread. That being said, I always
remember how when learning how to use a shell, I initially refused to
use "grep", and instead looking for a program like "filter" or "search",
that would have been consistent with the other commands like "mv", "cp",
"cd", etc. "Grep" sounded like some non-standard utility that I would
have to install from somewhere.
> I'd like to share a link to a short essay published earlier this year
> that reminded me of these threads on emacs-devel:
> https://ntietz.com/blog/name-your-projects-cutesy-things/ Although
> it's mainly about service names rather than software packages, its
> points are relevant here:
>
> And then the cherry on top, the final nail in the coffin of
> descriptive names: They're just too hard to say and remember, and
> they're no fun. I don't want my services or projects to sound like
> a law firm ("Ingest, Processing, & Storage LLP"). A descriptive
> name will be wordy, or boring, or both. It won't be memorable, and
> it won't be fun. On the other hand, something that's cute will be
> far more memorable and much easier to say.
>
> The world is boring enough as is. Let's add more whimsy and
> cuteness through our service and project names.
I think of my father, who despite having started using Unix system in
the 1990's and understands how everything works, just cannot remember
names like "apt" when software has to be upgraded. That means I have to
do it instead. One mans joke is another mans arbitrary, opaque
identifier that has to be memorised.
> As an Elisp package author, I can vouch that part of the joy of
> programming is creation, and part of the joy of creation is in naming
> one's creations. Let us not steal this joy from the authors who
> generously contribute their time and work to the public good that is
> Emacs and ELPA.
>
> I'll close with these words from Alan J. Perlis, quoted in Abelson's
> and Sussmans' classic, /Structure and Interpretation of Computer
> Programs/:
>
> I think that it's extraordinarily important that we in computer
> science keep fun in computing. When it started out, it was an
> awful lot of fun. Of course, the paying customers got shafted
> every now and then, and after a while we began to take their
> complaints seriously. We began to feel as if we really were
> responsible for the successful, error-free perfect use of these
> machines. I don't think we are. I think we're responsible for
> stretching them, setting them off in new directions, and keeping
> fun in the house. I hope the field of computer science never loses
> its sense of fun. Above all, I hope we don't become
> missionaries. Don't feel as if you're Bible salesmen. The world
> has too many of those already. What you know about computing other
> people will learn. Don't feel as if the key to successful
> computing is only in your hands. What's in your hands, I think and
> hope, is intelligence: the ability to see the machine as more than
> when you were first led up to it, that you can make it more.
^ permalink raw reply [relevance 68%]
* Re: [ELPA] New package: pdf-view-pagemark
@ 2023-05-12 5:52 98% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-05-12 5:52 UTC (permalink / raw)
To: Jijun Ma; +Cc: Eli Zaretskii, emacs-devel@gnu.org
Jijun Ma <jijun.ma@hotmail.com> writes:
> Thanks!
> Now I've signed the FSF CA.
While this is being proceed, I'd like question why you think that this
your package is better distributed separately? Taking a look at the
code, modulo user options, helper functions and other decoration the
main functionality boils down to a single function. Is it really worth
the maintainer-overhead to distribute this separately? Have you
communicated with the upstream developers on the matter?
> -----Original Message-----
> From: Eli Zaretskii <eliz@gnu.org>
> Sent: Wednesday, May 10, 2023 7:25 PM
> To: Philip Kaludercic <philipk@posteo.net>
> Cc: jijun.ma@hotmail.com; emacs-devel@gnu.org
> Subject: Re: [ELPA] New package: pdf-view-pagemark
>
>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: "emacs-devel@gnu.org" <emacs-devel@gnu.org>, "'Eli Zaretskii'"
>> <eliz@gnu.org>
>> Date: Wed, 10 May 2023 06:42:49 +0000
>>
>> Jijun Ma <jijun.ma@hotmail.com> writes:
>>
>> > That's a feature not strongly part of pdf-tools, better to be an extension.
>> > I've not signed FSF CA yet. How can I sign?
>>
>> I don't have a copy of the form, Eli can send them to you.
>
> Form sent off-list.
^ permalink raw reply [relevance 98%]
* Re: [NonGNU ELPA] New package: latex-table-wizard
@ 2023-05-12 5:46 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-05-12 5:46 UTC (permalink / raw)
To: Enrico Flor; +Cc: Stefan Monnier, emacs-devel
Enrico Flor <enrico@eflor.net> writes:
>> Sounds nice. I see you're the sole author. It'd be great if we could
>> add it to GNU ELPA instead, so we could better integrate it with AUCTeX
>> in the longer run.
>
> The paperwork for the copyright assignment should be all done now, I
> have received confirmation from the FSF. Is there anything else for me
> to do beside changing the copyright attribution in the source?
That and bump the version tag.
Your last message doesn't appear to be in my archive anymore, can you
send me the URL to your Git repository again?
> Thanks a lot
>
> Enrico
^ permalink raw reply [relevance 99%]
* Re: [ELPA] New package: dict
@ 2023-05-11 18:31 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-05-11 18:31 UTC (permalink / raw)
To: Eshel Yaron; +Cc: emacs-devel
Eshel Yaron <me@eshelyaron.com> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Eshel Yaron <me@eshelyaron.com> writes:
>>
>>> From 623c4d3b8be00f180e03480633a24ab61326e5cc Mon Sep 17 00:00:00 2001
>>> From: Eshel Yaron <me@eshelyaron.com>
>>> Date: Thu, 11 May 2023 14:20:16 +0300
>>> Subject: [PATCH] * elpa-packages (dict): New package
>>>
>>> ---
>>> elpa-packages | 2 ++
>>> 1 file changed, 2 insertions(+)
>>>
>>> diff --git a/elpa-packages b/elpa-packages
>>> index d5603f7803..fab548b336 100644
>>> --- a/elpa-packages
>>> +++ b/elpa-packages
>>> @@ -201,6 +201,8 @@
>>> :news "CHANGELOG.org"
>>> :readme "README.md")
>>> (devdocs :url "https://github.com/astoff/devdocs.el")
>>> + (dict :url "git://git.eshelyaron.com/dict.git"
>>
>> Do you have any other access method beside git://?
>
> For anonymous access, currently no. But I can mirror the repo to
> Sourcehut from where you can clone it via HTTPS. Would that be more
> convenient?
That would be good, my understanding is that git:// is not encrypted so
we should avoid using it if possible.
>>> + :doc "README.org")
>>
>> Should we add a ":readme ignore" to prevent the contents of this file
>> from also appearing when the user invokes C-h P dict RET ?
>
> Sure, in this case would C-h P show the commentary section of dict.el?
Right. Feel free to extend that with pointers, I just think we should
avoid overwhelming users with the entire documentation if they just want
to get the basic gist of a package.
> Thanks,
> Eshel
^ permalink raw reply [relevance 99%]
* Re: [ELPA] New package: dict
@ 2023-05-11 18:29 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-05-11 18:29 UTC (permalink / raw)
To: Eshel Yaron; +Cc: Eli Zaretskii, emacs-devel
Eshel Yaron <me@eshelyaron.com> writes:
> Eli, Philip, thanks for looking into it.
>
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>>>> From: Eshel Yaron <me@eshelyaron.com>
>>>> Date: Thu, 11 May 2023 16:22:06 +0300
>>>>
>>>> The main motivation behind this package was to resolve some usability issues
>>>> that I came across with dictionary.el. Namely, I'm not satisfied with the fact
>>>> that dictionary.el unconditionally switches to the *Dictionary* buffer when
>>>> displaying a definition, and I don't appreciate how it tries to remember my
>>>> previous windows configuration and revert back to it when I close the
>>>> *Dictionary* buffer with the q key. Of course, I'm open to the possibility of
>>>> modifying dictionary.el instead of adding this separate package GNU ELPA if
>>>> anyone thinks that's preferable, but I also think it would be nice to let people
>>>> try out Dict and get some feedback beforehand.
>>>
>>> I think if we could augment dictionary.el so as to satisfy your needs,
>>> perhaps as some kind of minor mode or user option, that would be
>>> better than having an entirely separate package.
>
> Alright, I can give augmenting dictionary.el a shot. The way I see it,
> this has the downside that it'll only be available in Emacs 30, and I'm
> not sure how elegant that's gonna be, but I guess I can put a patch
> together for emacs.git and then reassess.
>
>> I don't think that is possible, Eshel writes on his website:
>>
>> Dict’s differentiation comes from its simplicity and
>> extensibility–while dictionary.el defines a bespoke major mode and
>> interface for browsing word definitions, Dict leverages Emacs’s Help
>> mode by default, and let’s you extend and control every aspect of its
>> behavior via customization options.
>>
>> dict.el is also shorter than dictionary.el–just under 300 lines of
>> code!
>>
>> This is a ERC vs rcirc like situation.
>
> I'm afraid I haven't used ERC enough to understand this comparison,
rcirc and ERC are just two different IRC clients, respectively
minimalist and maximalist.
> does
> it imply that you think it'll be hard to keep Dict's simplicity intact
> upon incorporating it with dictionary.el?
Right, you'll either have to remove stuff from dictionary.el that people
have started to depend on, or ignore that fact.
^ permalink raw reply [relevance 99%]
* Re: [ELPA] New package: dict
@ 2023-05-11 14:18 99% ` Philip Kaludercic
1 sibling, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-05-11 14:18 UTC (permalink / raw)
To: Eshel Yaron; +Cc: emacs-devel
Eshel Yaron <me@eshelyaron.com> writes:
> From 623c4d3b8be00f180e03480633a24ab61326e5cc Mon Sep 17 00:00:00 2001
> From: Eshel Yaron <me@eshelyaron.com>
> Date: Thu, 11 May 2023 14:20:16 +0300
> Subject: [PATCH] * elpa-packages (dict): New package
>
> ---
> elpa-packages | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/elpa-packages b/elpa-packages
> index d5603f7803..fab548b336 100644
> --- a/elpa-packages
> +++ b/elpa-packages
> @@ -201,6 +201,8 @@
> :news "CHANGELOG.org"
> :readme "README.md")
> (devdocs :url "https://github.com/astoff/devdocs.el")
> + (dict :url "git://git.eshelyaron.com/dict.git"
Do you have any other access method beside git://?
> + :doc "README.org")
Should we add a ":readme ignore" to prevent the contents of this file
from also appearing when the user invokes C-h P dict RET ?
> (dict-tree :url "http://www.dr-qubit.org/git/predictive.git"
> :manual-sync t ;; The upstream doesn't exist any more!
> )
> --
> 2.40.1
^ permalink raw reply [relevance 99%]
* Re: [ELPA] New package: dict
@ 2023-05-11 14:14 97% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-05-11 14:14 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Eshel Yaron, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Eshel Yaron <me@eshelyaron.com>
>> Date: Thu, 11 May 2023 16:22:06 +0300
>>
>> The main motivation behind this package was to resolve some usability issues
>> that I came across with dictionary.el. Namely, I'm not satisfied with the fact
>> that dictionary.el unconditionally switches to the *Dictionary* buffer when
>> displaying a definition, and I don't appreciate how it tries to remember my
>> previous windows configuration and revert back to it when I close the
>> *Dictionary* buffer with the q key. Of course, I'm open to the possibility of
>> modifying dictionary.el instead of adding this separate package GNU ELPA if
>> anyone thinks that's preferable, but I also think it would be nice to let people
>> try out Dict and get some feedback beforehand.
>
> I think if we could augment dictionary.el so as to satisfy your needs,
> perhaps as some kind of minor mode or user option, that would be
> better than having an entirely separate package.
I don't think that is possible, Eshel writes on his website:
Dict’s differentiation comes from its simplicity and
extensibility–while dictionary.el defines a bespoke major mode and
interface for browsing word definitions, Dict leverages Emacs’s Help
mode by default, and let’s you extend and control every aspect of its
behavior via customization options.
dict.el is also shorter than dictionary.el–just under 300 lines of
code!
This is a ERC vs rcirc like situation.
> Thanks.
^ permalink raw reply [relevance 97%]
* Re: [NonGNU ELPA] New package: devil
@ 2023-05-11 9:12 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-05-11 9:12 UTC (permalink / raw)
To: Susam Pal; +Cc: Eli Zaretskii, relekarpayas, rms, emacs-devel
Susam Pal <susam.pal@gmail.com> writes:
> Eli Zaretskii <eliz@gnu.org> wrote:
>>
>> > From: Philip Kaludercic <philipk@posteo.net>
>> > Cc: Eli Zaretskii <eliz@gnu.org>, Payas Relekar <relekarpayas@gmail.com>,
>> > rms@gnu.org, emacs-devel@gnu.org
>> > Date: Thu, 11 May 2023 08:45:40 +0000
>> >
>> > > I have now updated it to "Minor mode for intercepting and translating
>> > > key sequences."
>> >
>> > That probably as good as it gets for a brief description.
>>
>> Except that I'm not sure "intercepting" is correct here. Is it?
>
> Is the following description better?
>
> "Minor mode for reading and translating key sequences."
^
is this redundant? hard to translate without reading.
That sounds very generic, is the package capable of doing that for any
kind of key translation.
^ permalink raw reply [relevance 99%]
* Re: [NonGNU ELPA] New package: devil
@ 2023-05-11 8:45 78% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-05-11 8:45 UTC (permalink / raw)
To: Susam Pal; +Cc: Eli Zaretskii, Payas Relekar, rms, emacs-devel
Susam Pal <susam.pal@gmail.com> writes:
> Philip Kaludercic <philipk@posteo.net> wrote:
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> >> From: Payas Relekar <relekarpayas@gmail.com>
>> >> Cc: Philip Kaludercic <philipk@posteo.net>, susam.pal@gmail.com,
>> >> emacs-devel@gnu.org
>> >> Date: Thu, 11 May 2023 10:53:15 +0530
>> >>
>> >> Richard Stallman <rms@gnu.org> writes:
>> >>
>> >> > Why use the name "Devil" for this? It doesn't seen to explain anything
>> >> > about the package's purpose. It is likely to put some people off.
>> >>
>> >> Every name is going to put someone or another off, can't really help it.
>> >> OpenBSD has their daemon and there are already funny anecdotes about it,
>> >> but it doesn't hurt anyone.
>>
>> Also, "daemon" is not just an OpenBSD thing.
>>
>> > "daemon" is a term whose meaning in computing context is widely
>> > accepted for many years. "Devil' isn't.
>>
>> I agree.
>>
>> >> > If there is no clear reason why "Devil" is a good name, let's choose
>> >> > a better name now.
>> >>
>> >> As mentioned by Susam in previous mail, as well as the repo README, the
>> >> name refers both to 'eVil' (extensible Vi Layer) as well as 'God-mode'.
>> >
>> > People are extremely unlikely to understand that, even if they know
>> > about Evil in Emacs. And even if they do figure out this is related
>> > to Evil, the truth is that the package is not meant to be used by
>> > users of Evil.
>>
>> I think it is more likely than you assume if you ask enthusiasts, but if
>> we consider the average user who doesn't hang around in Emacs-related
>> forums, chats, etc. then this is very true.
>>
>> >> The name is distinct, and I like it for what it is.
>> >
>> > Please reconsider, I think this name is very unfortunate, because it
>> > gives users no clue whatsoever about the package's purpose.
>>
>> Susam, what do you say? Do you have any ideas? A few names I can think
>> of might be:
>>
>> - no-modifier-mode
>> - prefixless-mode
>> - implicit-ctrl-mode
>> - comma->control-mode
>>
>> but I'm not really convinced by any of these (haven't really used the
>> package yet either). Perhaps this might inspire someone else to come up
>> with a better suggestion?
>
> Although the default translation rules in Devil translates comma to
> ctrl, m to meta, etc., Devil is very configurable and one is free to
> configure Devil in other ways that may or may not involve the comma
> key or the modifier keys.
Right, that was why I said I wasn't convinced by the suggestions with
"comma" in the name. By the way, you should add a custom setter to the
user option that configures the key to update the minor-mode map to
rebind the key.
> For example, I am aware that there are users of Devil who use the
> semicolon as the Devil activation key and translate semicolon to
> control. There are also users who only translate some activation key
> to control key but regular alt modifier key on their keyboard for the
> meta modifier.
>
>> If you really insist, then I think we really have to come up with a
>> better description, because "Minor mode for Devil-like command entering"
>> is really confusing.
>>
>> > Thanks.
>
> While I understand the desire for a more descriptive name, I believe
> that "Devil" is a suitable choice due to its humorous reference to
> both God mode and Evil mode. Some people like the name. Some do not. I
> like this name.
If you insist, I guess we'll go with that (unless anyone wants to veto
it), but I think it is sad to contribute to the further spread of
confusing and opaque names for packages that has been increasing on GNU
and NonGNU ELPA recently.
> If it is essential for the package's name to reflect its purpose, I
> propose "Devil" to stand for "Devil's Extremely Versatile Interception
> Layer".
I think you know that that is not what is being talked about here.
Retroactive acronyms are usually just a joke, and don't help address the
issue that newcomers face when they are given packages names like
"Corfu", "Captain", "Luwak" or "Eglot". They are not indicative of
their functionality and at best have vague links to other terminology
that you can make sense of if someone explains it to you (sort of like
the devil to evil/god mode in your case), but most non-enthusiasts
wouldn't see.
While I get the intended pun, and I think "devil-mode" is a clever idea
knowing the context, I would still like to urge you to reconsider -- not
for your own sake but for that of the users.
> I agree that the current description of the package needs improvement.
> I have now updated it to "Minor mode for intercepting and translating
> key sequences."
That probably as good as it gets for a brief description.
> Regards,
> Susam
^ permalink raw reply [relevance 78%]
* Re: emacs-29 9b775ddc057 1/2: ; * etc/EGLOT-NEWS: Fix wording of last change.
@ 2023-05-11 7:29 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-05-11 7:29 UTC (permalink / raw)
To: Ruijie Yu; +Cc: Eli Zaretskii, dmitry, monnier, emacs-devel
Ruijie Yu <ruijie@netyu.xyz> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Philip Kaludercic <philipk@posteo.net> writes:
>>
>>> OK, then this is my proposal:
>>
>> I noticed a bug, here is a revised version:
>>
>> - (cond ((member status '("installed" "dependency" "unsigned"
>> "external"))
>> + (cond ((member status (append
>> + '("installed" "dependency" "unsigned" "external" "built-in")
>> + (and package-install-upgrade-built-in '("built-in"))))
>
> I'm having a hard time understanding the significance of this portion.
> Why using (and ... '("built-in")) ? AFACT, it adds matching status with
> "built-in", but unconditionally, because of the added element in the
> literal list?
You are right, the `and' was not necessary, I've removed it locally.
Will push the changes soon.
> And since the result of `member' is unused (except for checking its
> boolean value), whether it returns one or two copies of "built-in" would
> make no difference either.
^ permalink raw reply [relevance 99%]
* Re: emacs-29 9b775ddc057 1/2: ; * etc/EGLOT-NEWS: Fix wording of last change.
@ 2023-05-11 7:26 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-05-11 7:26 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: Eli Zaretskii, monnier, emacs-devel
Dmitry Gutov <dmitry@gutov.dev> writes:
> On 10/05/2023 14:03, Philip Kaludercic wrote:
>> I noticed a bug, here is a revised version:
>
> Should package-upgrade-all have a similar adjustment?
Why not? Didn't you have a patch that extended
`package--upgradeable-packages' by an optional argument, we could use
that here an just pass `package-install-upgrade-built-in'.
^ permalink raw reply [relevance 99%]
* Re: [NonGNU ELPA] New package: devil
@ 2023-05-11 6:52 89% ` Philip Kaludercic
1 sibling, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-05-11 6:52 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Payas Relekar, rms, susam.pal, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Payas Relekar <relekarpayas@gmail.com>
>> Cc: Philip Kaludercic <philipk@posteo.net>, susam.pal@gmail.com,
>> emacs-devel@gnu.org
>> Date: Thu, 11 May 2023 10:53:15 +0530
>>
>> Richard Stallman <rms@gnu.org> writes:
>>
>> > Why use the name "Devil" for this? It doesn't seen to explain anything
>> > about the package's purpose. It is likely to put some people off.
>>
>> Every name is going to put someone or another off, can't really help it.
>> OpenBSD has their daemon and there are already funny anecdotes about it,
>> but it doesn't hurt anyone.
Also, "daemon" is not just an OpenBSD thing.
> "daemon" is a term whose meaning in computing context is widely
> accepted for many years. "Devil' isn't.
I agree.
>> > If there is no clear reason why "Devil" is a good name, let's choose
>> > a better name now.
>>
>> As mentioned by Susam in previous mail, as well as the repo README, the
>> name refers both to 'eVil' (extensible Vi Layer) as well as 'God-mode'.
>
> People are extremely unlikely to understand that, even if they know
> about Evil in Emacs. And even if they do figure out this is related
> to Evil, the truth is that the package is not meant to be used by
> users of Evil.
I think it is more likely than you assume if you ask enthusiasts, but if
we consider the average user who doesn't hang around in Emacs-related
forums, chats, etc. then this is very true.
>> The name is distinct, and I like it for what it is.
>
> Please reconsider, I think this name is very unfortunate, because it
> gives users no clue whatsoever about the package's purpose.
Susam, what do you say? Do you have any ideas? A few names I can think
of might be:
- no-modifier-mode
- prefixless-mode
- implicit-ctrl-mode
- comma->control-mode
but I'm not really convinced by any of these (haven't really used the
package yet either). Perhaps this might inspire someone else to come up
with a better suggestion?
If you really insist, then I think we really have to come up with a
better description, because "Minor mode for Devil-like command entering"
is really confusing.
> Thanks.
^ permalink raw reply [relevance 89%]
* Re: [GNU ELPA] New package: Urgrep
@ 2023-05-10 17:30 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-05-10 17:30 UTC (permalink / raw)
To: Jim Porter; +Cc: emacs-devel
Jim Porter <jporterbugs@gmail.com> writes:
> On 5/9/2023 11:22 PM, Philip Kaludercic wrote:
>> elpa-admin.el has a default list of README file names, that include
>> README.md. I can fix that before applying the patch, since there
>> appears to be no opposition to adding the package.
>
> Thanks. I guess we should also update the ELPA README too then:
Nevermind, I was mistaken. elpa-admin.el says
;; Most README.md files seem to be currently worse than the Commentary:
;; section :-( "README.md"
>> By default we try to use README, README.rst, README.org, or the
>> Commentary section in the main file.
^ permalink raw reply [relevance 99%]
* Re: emacs-29 9b775ddc057 1/2: ; * etc/EGLOT-NEWS: Fix wording of last change.
2023-05-10 6:59 76% ` Philip Kaludercic
@ 2023-05-10 11:03 80% ` Philip Kaludercic
0 siblings, 2 replies; 200+ results
From: Philip Kaludercic @ 2023-05-10 11:03 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: dmitry, monnier, emacs-devel
[-- Attachment #1: Type: text/plain, Size: 681 bytes --]
Philip Kaludercic <philipk@posteo.net> writes:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Philip Kaludercic <philipk@posteo.net>
>>> Cc: dmitry@gutov.dev, monnier@iro.umontreal.ca, emacs-devel@gnu.org
>>> Date: Mon, 08 May 2023 13:34:26 +0000
>>>
>>> >> At least nadvice, cl-lib and cl-generic seem to be the odd ones (the
>>> >> built-in versions are higher, and the ELPA packages are supposed to be
>>> >> used as shims or backward compatibility wrappers). That looks like a bug.
>>>
>>> I think you are right, I can extend my previous patch by a version check.
>>
>> Good idea, IMO.
>
> OK, then this is my proposal:
I noticed a bug, here is a revised version:
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Ensure-that-package-menu-respects-package-install-up.patch --]
[-- Type: text/x-diff, Size: 1746 bytes --]
From 8f53ac64620db17a7b163889bb319b621ab97a25 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Wed, 10 May 2023 08:58:34 +0200
Subject: [PATCH] Ensure that package menu respects
'package-install-upgrade-built-in'
* lisp/emacs-lisp/package.el (package-menu--find-upgrades): Check if
built-in packages can be upgraded if
'package-install-upgrade-built-in' is non-nil.
---
lisp/emacs-lisp/package.el | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el
index 9476354ebe0..24ba67cef2f 100644
--- a/lisp/emacs-lisp/package.el
+++ b/lisp/emacs-lisp/package.el
@@ -3731,7 +3731,9 @@ package-menu--find-upgrades
;; ENTRY is (PKG-DESC [NAME VERSION STATUS DOC])
(let ((pkg-desc (car entry))
(status (aref (cadr entry) 2)))
- (cond ((member status '("installed" "dependency" "unsigned" "external"))
+ (cond ((member status (append
+ '("installed" "dependency" "unsigned" "external" "built-in")
+ (and package-install-upgrade-built-in '("built-in"))))
(push pkg-desc installed))
((member status '("available" "new"))
(setq available (package--append-to-alist pkg-desc available))))))
@@ -3742,6 +3744,8 @@ package-menu--find-upgrades
(and avail-pkg
(version-list-< (package-desc-priority-version pkg-desc)
(package-desc-priority-version avail-pkg))
+ (xor (not package-install-upgrade-built-in)
+ (package--active-built-in-p pkg-desc))
(push (cons name avail-pkg) upgrades))))
upgrades))
--
2.39.2
^ permalink raw reply related [relevance 80%]
* Re: emacs-29 9b775ddc057 1/2: ; * etc/EGLOT-NEWS: Fix wording of last change.
@ 2023-05-10 6:59 76% ` Philip Kaludercic
2023-05-10 11:03 80% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-05-10 6:59 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: dmitry, monnier, emacs-devel
[-- Attachment #1: Type: text/plain, Size: 571 bytes --]
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: dmitry@gutov.dev, monnier@iro.umontreal.ca, emacs-devel@gnu.org
>> Date: Mon, 08 May 2023 13:34:26 +0000
>>
>> >> At least nadvice, cl-lib and cl-generic seem to be the odd ones (the
>> >> built-in versions are higher, and the ELPA packages are supposed to be
>> >> used as shims or backward compatibility wrappers). That looks like a bug.
>>
>> I think you are right, I can extend my previous patch by a version check.
>
> Good idea, IMO.
OK, then this is my proposal:
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Ensure-that-package-menu-respects-package-install-up.patch --]
[-- Type: text/x-diff, Size: 2040 bytes --]
From 8d78dc4ab9cb188f62c656d6d55326240816f8c6 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Wed, 10 May 2023 08:58:34 +0200
Subject: [PATCH] Ensure that package menu respects
'package-install-upgrade-built-in'
* lisp/emacs-lisp/package.el (package-menu--find-upgrades): Check if
built-in packages can be upgraded if
'package-install-upgrade-built-in' is non-nil.
---
lisp/emacs-lisp/package.el | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el
index 9476354ebe0..7f94ed2e57b 100644
--- a/lisp/emacs-lisp/package.el
+++ b/lisp/emacs-lisp/package.el
@@ -3731,7 +3731,9 @@ package-menu--find-upgrades
;; ENTRY is (PKG-DESC [NAME VERSION STATUS DOC])
(let ((pkg-desc (car entry))
(status (aref (cadr entry) 2)))
- (cond ((member status '("installed" "dependency" "unsigned" "external"))
+ (cond ((member status (append
+ '("installed" "dependency" "unsigned" "external" "built-in")
+ (and package-install-upgrade-built-in '("built-in"))))
(push pkg-desc installed))
((member status '("available" "new"))
(setq available (package--append-to-alist pkg-desc available))))))
@@ -3740,8 +3742,11 @@ package-menu--find-upgrades
(let* ((name (package-desc-name pkg-desc))
(avail-pkg (cadr (assq name available))))
(and avail-pkg
- (version-list-< (package-desc-priority-version pkg-desc)
- (package-desc-priority-version avail-pkg))
+ (and (version-list-< (package-desc-priority-version pkg-desc)
+ (package-desc-priority-version avail-pkg))
+ (if package-install-upgrade-built-in
+ (package--active-built-in-p pkg-desc)
+ t))
(push (cons name avail-pkg) upgrades))))
upgrades))
--
2.39.2
[-- Attachment #3: Type: text/plain, Size: 101 bytes --]
This also reduced the number of packages that are suggested for an
upgrade to only 5 (on Emacs 29).
^ permalink raw reply related [relevance 76%]
* Re: [ELPA] New package: pdf-view-pagemark
@ 2023-05-10 6:42 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-05-10 6:42 UTC (permalink / raw)
To: Jijun Ma; +Cc: emacs-devel@gnu.org, 'Eli Zaretskii'
Jijun Ma <jijun.ma@hotmail.com> writes:
> That's a feature not strongly part of pdf-tools, better to be an extension.
> I've not signed FSF CA yet. How can I sign?
I don't have a copy of the form, Eli can send them to you.
> -----Original Message-----
> From: Philip Kaludercic <philipk@posteo.net>
> Sent: Tuesday, May 9, 2023 4:47 PM
> To: Jijun Ma <jijun.ma@hotmail.com>
> Cc: emacs-devel@gnu.org
> Subject: Re: [ELPA] New package: pdf-view-pagemark
>
> Jijun Ma <jijun.ma@hotmail.com> writes:
>
>> Hello Philip
>>
>> It is a new package. Could you put it to GNU elpa? Thanks.
>
> i got that, I am just asking if it wouldn't be better to contribute
>> your code upstream? I don't use pdf-tools, so I don't know if there
>> is a reason that all users wouldn't be interested in this code.
>
> Otherwise, we can do so. Have you signed the FSF CA?
>
>> Holen Sie sich Outlook für iOS<https://aka.ms/o0ukef>
>> ________________________________
>> Von: Philip Kaludercic <philipk@posteo.net>
>> Gesendet: Tuesday, May 9, 2023 4:23:40 AM
>> An: Jijun Ma <jijun.ma@hotmail.com>
>> Cc: emacs-devel@gnu.org <emacs-devel@gnu.org>
>> Betreff: Re: [ELPA] New package: pdf-view-pagemark
>>
>> Jijun Ma <jijun.ma@hotmail.com> writes:
>>
>>> Hello,
>>>
>>> Because pdf-tools cannot scroll continuously between two pages. The remaining of a page will be partial.
>>> pdf-view-pagemark is used together with pdf-tools to indicate the remaining of a partial page.
>>
>> Are you proposing this for GNU ELPA or NonGNU ELPA? Also, have
>> attempted to merge this into the actual package, before creating a
>> separate package?
>>
>>> URL of the package: https://github.com/kimim/pdf-view-pagemark
>>>
>>> Thanks.
^ permalink raw reply [relevance 99%]
* Re: [ELPA] New package: calibre.el
@ 2023-05-10 6:36 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-05-10 6:36 UTC (permalink / raw)
To: Kjartan Óli Águstsson; +Cc: emacs-devel
Kjartan Óli Águstsson <kjartanoli@outlook.com> writes:
> Kjartan Óli Águstsson <kjartanoli@outlook.com> writes:
>
>>> This means you should copy the metadata to calibre.el. Especially the
>>> dependency list. (Also, why do you depend on "29.1.0", a version which
>>> is unreleased and has an additional ".0" at the end? I guess you need
>>> Emacs 29 because of SQLite? Have you taken a look at emacsql?)
>>
>> I'll definitely fix the .0 thing. You are correct that the dependency
>> on Emacs 29 is for SQLite. Emacsql would not work, since I am
>> interacting with an existing database maintained by Calibre. If you
>> want to wait until Emacs 29 is released to add it I would definitely
>> agree to that.
>
> I've done some more work on this. The most significant one being the
> addition of a backend/database interface that uses the calibredb
> executable instead of parsing the SQLite database directly. Combined
> with compat this should lower the minimum required Emacs version to 27.
> Are there any other things that would block calibre.el's inclusion in
> GNU ELPA?
I don't think so, but I have forgotten the details of the proposal. You
have signed your FSF CA, right? Also, could you give me the URL again?
^ permalink raw reply [relevance 99%]
* Re: [GNU ELPA] New package: Urgrep
@ 2023-05-10 6:22 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-05-10 6:22 UTC (permalink / raw)
To: Jim Porter; +Cc: emacs-devel
Jim Porter <jporterbugs@gmail.com> writes:
> On 5/9/2023 1:45 AM, Philip Kaludercic wrote:
>> Could you track these files in a .elpaignore file within the repository?
>
> Thanks, I didn't know about that file. Fixed in Urgrep, and here's the
> updated patch for GNU ELPA.
>
> From 83b716918f55737783c2dfe699487f451e9a47f1 Mon Sep 17 00:00:00 2001
> From: Jim Porter <jporterbugs@gmail.com>
> Date: Mon, 8 May 2023 22:07:56 -0700
> Subject: [PATCH] * elpa-packages (urgrep): New package
>
> ---
> elpa-packages | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/elpa-packages b/elpa-packages
> index 93f6ccc..c99708f 100644
> --- a/elpa-packages
> +++ b/elpa-packages
> @@ -696,6 +696,8 @@
> (uni-confusables :url nil
> :readme "README.md")
> (uniquify-files :url nil)
> + (urgrep :url "https://github.com/jimporter/urgrep"
> + :readme "README.md")
elpa-admin.el has a default list of README file names, that include
README.md. I can fix that before applying the patch, since there
appears to be no opposition to adding the package.
> (url-http-ntlm :url nil)
> (url-http-oauth :url "https://git.sr.ht/~fitzsim/url-http-oauth"
> :readme ignore)
^ permalink raw reply [relevance 99%]
* Re: [NonGNU ELPA] New package: devil
@ 2023-05-10 6:09 5% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-05-10 6:09 UTC (permalink / raw)
To: Susam Pal; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1163 bytes --]
Susam Pal <susam.pal@gmail.com> writes:
> Philip Kaludercic <philipk@posteo.net> wrote:
>> Susam Pal <susam.pal@gmail.com> writes:
>>
>> > Hello!
>> >
>> > I am the author and maintainer of a new package named Devil. This package
>> > intercepts keystrokes entered by the user and applies translation rules to
>> > translate the keystrokes into Emacs key sequences. It supports three types
>> > of rules: special keys that map to custom commands that are invoked
>> > immediately prior to any translations, translation rules to translate Devil
>> > key sequences to regular Emacs key sequences, and repeatable keys to allow
>> > a Devil key sequence to be repeated by typing the last keystroke over and
>> > over again using a transient map.
>> >
>> > See the README at https://github.com/susam/devil for more details.
>>
>> Looks interesting, here is a diff with a few comments:
>
> Thanks for the review and the diff! The code looks much better with
> these changes. Like we discussed a little while ago in the #emacs
> channel, if you send me the patches, I'll apply it to the code.
Here are the patches, feel free to modify or leave out whatever you
want:
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-devil.el-Update-header-with-more-information.patch --]
[-- Type: text/x-diff, Size: 769 bytes --]
From e1757d9005f82624a1db435f53f250291e177519 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Wed, 10 May 2023 07:36:54 +0200
Subject: [PATCH 1/8] * devil.el: Update header with more information
---
devil.el | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/devil.el b/devil.el
index 7c5d4ca..5bfb848 100644
--- a/devil.el
+++ b/devil.el
@@ -2,10 +2,11 @@
;; Copyright (c) 2022-2023 Susam Pal
-;; Author: Susam Pal
+;; Author: Susam Pal <susam@susam.net>
+;; Maintainer: Susam Pal <susam@susam.net>
;; Version: 0.2.0
;; Package-Requires: ((emacs "24.4"))
-;; Keywords: convenience
+;; Keywords: convenience, abbrev
;; URL: https://github.com/susam/devil
;; This file is not part of GNU Emacs.
--
2.39.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0002-Remove-custom-version-command.patch --]
[-- Type: text/x-diff, Size: 851 bytes --]
From a2d9b22fe60ec8cdf78c69ea873d3d299c4c42d2 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Wed, 10 May 2023 07:38:34 +0200
Subject: [PATCH 2/8] Remove custom version command.
* devil.el (devil-version, devil-show-version): Remove.
The version of a package can be generically inspected with C-h P devil
RET.
---
devil.el | 6 ------
1 file changed, 6 deletions(-)
diff --git a/devil.el b/devil.el
index 5bfb848..fa08c5f 100644
--- a/devil.el
+++ b/devil.el
@@ -37,13 +37,7 @@
;; key sequences without using modifier keys.
;;; Code:
-(defconst devil-version "0.2.0"
- "Devil version number.")
-(defun devil-show-version ()
- "Show Devil version number in the echo area."
- (interactive)
- (message "Devil %s" devil-version))
(defvar devil-key ","
"The key sequence that begins Devil input.
--
2.39.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #4: 0003-Add-devil-customisation-group.patch --]
[-- Type: text/x-diff, Size: 4120 bytes --]
From 324e6f8655a7cad7ca0c9a15fb1f8a119484b292 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Wed, 10 May 2023 07:49:26 +0200
Subject: [PATCH 3/8] Add 'devil' customisation group
* devil.el (devil-key, devil-translations, devil-repeatable-keys,
devil-prompt): Convert to user options.
(global-devil-mode): Remove unnecessary :group tag.
---
devil.el | 38 ++++++++++++++++++++++++--------------
1 file changed, 24 insertions(+), 14 deletions(-)
diff --git a/devil.el b/devil.el
index fa08c5f..461537e 100644
--- a/devil.el
+++ b/devil.el
@@ -38,20 +38,26 @@
;;; Code:
+(defgroup devil '()
+ "Minor mode for Devil-like command entering." ;is there a clearer description?
+ :prefix "devil-"
+ :group 'editing)
-(defvar devil-key ","
+(defcustom devil-key ","
"The key sequence that begins Devil input.
The key sequence must be specified in the format returned by `C-h
k' (`describe-key'). This variable should be set before enabling
-Devil mode for it to take effect.")
+Devil mode for it to take effect."
+ :type 'key-sequence)
-(defvar devil-lighter " Devil"
- "String displayed on the mode line when Devil mode is enabled.")
+(defcustom devil-lighter " Devil"
+ "String displayed on the mode line when Devil mode is enabled."
+ :type 'string)
(defvar devil-mode-map
(let ((map (make-sparse-keymap)))
- (define-key map (kbd devil-key) #'devil)
+ (define-key map devil-key #'devil)
map)
"Keymap to wake up Devil when `devil-key' is typed.
@@ -69,15 +75,16 @@ be modified before loading Devil for it to take effect.")
;;;###autoload
(define-globalized-minor-mode
- global-devil-mode devil-mode devil--on :group 'devil
+ global-devil-mode devil-mode devil--on
(if global-devil-mode (devil-add-extra-keys) (devil-remove-extra-keys)))
(defun devil--on ()
"Turn Devil mode on."
(devil-mode 1))
-(defvar devil-logging nil
- "Non-nil if and only if Devil should print log messages.")
+(defcustom devil-logging nil
+ "Non-nil if and only if Devil should print log messages."
+ :type 'boolean)
(defvar devil-special-keys
(list (cons "%k %k" (lambda () (interactive) (devil-run-key "%k")))
@@ -91,7 +98,7 @@ this alist, the function or lambda in the corresponding value is
invoked. The format control specifier `%k' may be used to
represent `devil-key' in the keys.")
-(defvar devil-translations
+(defcustom devil-translations
(list (cons "%k z" "C-")
(cons "%k %k" "%k")
(cons "%k m m" "M-")
@@ -106,9 +113,10 @@ The translation rules are applied in the sequence they occur in
the alist. For each rule, if the key occurs anywhere in the Devil
key sequence, it is replaced with the corresponding value in the
translation rule. The format control specifier `%k' may be used
-to represent `devil-key' in the keys.")
+to represent `devil-key' in the keys."
+ :type '(alist :key-type string :value-type string))
-(defvar devil-repeatable-keys
+(defcustom devil-repeatable-keys
(list "%k p"
"%k n"
"%k f"
@@ -124,7 +132,8 @@ to represent `devil-key' in the keys.")
The value of this variable is a list where each item represents a
key sequence that may be repeated merely by typing the last
character in the key sequence. The format control specified `%k'
-may be used to represent `devil-key' in the keys.")
+may be used to represent `devil-key' in the keys."
+ :type '(repeat string))
(defun devil-run-key (key)
"Execute the given key sequence KEY.
@@ -183,14 +192,15 @@ recursively to read yet another key from the user."
(unless (devil--run-command key)
(devil--read-key key)))
-(defvar devil-prompt "Devil: %t"
+(defcustom devil-prompt "Devil: %t"
"A format control string that determines the Devil prompt.
The following format control sequences are supported:
%k - Devil key sequence read by Devil so far.
%t - Emacs key sequence translated from Devil key sequence read so far.
-%% - The percent sign.")
+%% - The percent sign."
+ :type 'string)
(defun devil--make-prompt (key)
"Create Devil prompt based on the given KEY."
--
2.39.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #5: 0004-Fix-spacing-in-documentation-strings.patch --]
[-- Type: text/x-diff, Size: 8487 bytes --]
From 5896bfa8061709e14a6fd3a94f7039a6b0978d26 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Wed, 10 May 2023 08:00:19 +0200
Subject: [PATCH 4/8] Fix spacing in documentation strings
---
devil.el | 54 ++++++++++++++++++++++++++++--------------------------
1 file changed, 28 insertions(+), 26 deletions(-)
diff --git a/devil.el b/devil.el
index 461537e..5f8ecfa 100644
--- a/devil.el
+++ b/devil.el
@@ -47,7 +47,7 @@
"The key sequence that begins Devil input.
The key sequence must be specified in the format returned by `C-h
-k' (`describe-key'). This variable should be set before enabling
+k' (`describe-key'). This variable should be set before enabling
Devil mode for it to take effect."
:type 'key-sequence)
@@ -62,9 +62,9 @@ Devil mode for it to take effect."
"Keymap to wake up Devil when `devil-key' is typed.
By default, only `devil-key' is added to this keymap so that
-Devil can be activated using it. To support multiple activation
+Devil can be activated using it. To support multiple activation
keys, this variable may be modified to a new keymap that defines
-multiple different keys to activate Devil. This variable should
+multiple different keys to activate Devil. This variable should
be modified before loading Devil for it to take effect.")
;;;###autoload
@@ -93,9 +93,9 @@ be modified before loading Devil for it to take effect.")
"Special Devil keys that are executed as soon as they are typed.
The value of this variable is an alist where each key represents
-a Devil key sequence. If a Devil key sequence matches any key in
+a Devil key sequence. If a Devil key sequence matches any key in
this alist, the function or lambda in the corresponding value is
-invoked. The format control specifier `%k' may be used to
+invoked. The format control specifier `%k' may be used to
represent `devil-key' in the keys.")
(defcustom devil-translations
@@ -110,9 +110,9 @@ The value of this variable is an alist where each item represents
a translation rule that is applied on the Devil key sequence read
from the user to obtain the Emacs key sequence to be executed.
The translation rules are applied in the sequence they occur in
-the alist. For each rule, if the key occurs anywhere in the Devil
+the alist. For each rule, if the key occurs anywhere in the Devil
key sequence, it is replaced with the corresponding value in the
-translation rule. The format control specifier `%k' may be used
+translation rule. The format control specifier `%k' may be used
to represent `devil-key' in the keys."
:type '(alist :key-type string :value-type string))
@@ -131,7 +131,7 @@ to represent `devil-key' in the keys."
The value of this variable is a list where each item represents a
key sequence that may be repeated merely by typing the last
-character in the key sequence. The format control specified `%k'
+character in the key sequence. The format control specified `%k'
may be used to represent `devil-key' in the keys."
:type '(repeat string))
@@ -182,11 +182,11 @@ translation to Emacs key sequence, or an undefined key sequence
after translation to Emacs key sequence.
The argument KEY is a vector that represents the key sequence
-read so far. This function reads a new key from the user, appends
+read so far. This function reads a new key from the user, appends
it to KEY, and then checks if the result is a valid key sequence
-or an undefined key sequence. If the result is a valid key
+or an undefined key sequence. If the result is a valid key
sequence for a special key command or an Emacs command, then the
-command is executed. Otherwise, this function calls itself
+command is executed. Otherwise, this function calls itself
recursively to read yet another key from the user."
(setq key (vconcat key (vector (read-key (devil--make-prompt key)))))
(unless (devil--run-command key)
@@ -204,6 +204,8 @@ The following format control sequences are supported:
(defun devil--make-prompt (key)
"Create Devil prompt based on the given KEY."
+ ;; If you are interested in adding Compat as a dependency, you can
+ ;; make use of `format-spec' without raining the minimum version.
(let ((result devil-prompt)
(controls (list (cons "%k" (key-description key))
(cons "%t" (devil-translate key))
@@ -215,16 +217,16 @@ The following format control sequences are supported:
(defun devil--run-command (key)
"Try running the command bound to the key sequence in KEY.
-KEY is a vector that represents a sequence of keystrokes. If KEY
+KEY is a vector that represents a sequence of keystrokes. If KEY
is found to be a special key in `devil-special-keys', the
corresponding special command is executed immediately and t is
returned.
Otherwise, it is translated to an Emacs key sequence using
-`devil-translations'. If the resulting Emacs key sequence is
+`devil-translations'. If the resulting Emacs key sequence is
found to be a complete key sequence, the command it is bound to
-is executed interactively and t is returned. If it is found to be
-an undefined key sequence, then t is returned. If the resulting
+is executed interactively and t is returned. If it is found to be
+an undefined key sequence, then t is returned. If the resulting
Emacs key sequence is found to be an incomplete key sequence,
then nil is returned."
(devil--log "Trying to execute key: %s" (key-description key))
@@ -236,7 +238,7 @@ then nil is returned."
If the given key sequence KEY is found to be a special key in
`devil-special-keys', the corresponding special command is
-executed, and t is returned. Otherwise nil is returned."
+executed, and t is returned. Otherwise nil is returned."
(catch 'break
(dolist (entry devil-special-keys)
(when (string= (key-description key) (devil-format (car entry)))
@@ -250,9 +252,9 @@ executed, and t is returned. Otherwise nil is returned."
After translating KEY to an Emacs key sequence, if the resulting
key sequence turns out to be an incomplete key, then nil is
-returned. If it turns out to be a complete key sequence, the
-corresponding Emacs command is executed, and t is returned. If it
-turns out to be an undefined key sequence, t is returned. The
+returned. If it turns out to be a complete key sequence, the
+corresponding Emacs command is executed, and t is returned. If it
+turns out to be an undefined key sequence, t is returned. The
return value t indicates to the caller that no more Devil key
sequences should be read from the user."
(let* ((described-key (key-description key))
@@ -312,27 +314,27 @@ read so far."
"Update variables that maintain command loop information.
The given KEY and BINDING is used to update variables that
-maintain command loop information. This allows the commands that
+maintain command loop information. This allows the commands that
depend on them behave as if they were being invoked directly with
the original Emacs key sequence."
;;
;; Set `last-command-event' so that `digit-argument' can determine
- ;; the correct digit for key sequences like , 5 (C-5). See M-x
+ ;; the correct digit for key sequences like , 5 (C-5). See M-x
;; find-function RET digit-argument RET for details.
(setq last-command-event (aref key (- (length key) 1)))
;;
;; Set `this-command' to make several commands like , z SPC , z SPC
- ;; (C-SPC C-SPC) and , p (C-p) work correctly. Emacs copies
- ;; `this-command' to `last-command'. Both variables are used by
+ ;; (C-SPC C-SPC) and , p (C-p) work correctly. Emacs copies
+ ;; `this-command' to `last-command'. Both variables are used by
;; `set-mark-command' to decide whether to activate/deactivate the
- ;; current mark. The first variable is used by vertical motion
- ;; commands to keep the cursor at the `temporary-goal-column'. There
+ ;; current mark. The first variable is used by vertical motion
+ ;; commands to keep the cursor at the `temporary-goal-column'. There
;; may be other commands too that depend on this variable.
(setq this-command binding)
;;
;; Set `real-this-command' to make , x z (C-x z) work correctly.
;; Emacs copies it to `last-repeatable-command' which is then used
- ;; by repeat. See the following for more details:
+ ;; by repeat. See the following for more details:
;;
;; - M-x find-function RET repeat RET
;; - C-h v last-repeatable-command RET
--
2.39.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #6: 0005-devil.el-devil-saved-keys-Assign-nil-by-default.patch --]
[-- Type: text/x-diff, Size: 829 bytes --]
From 48510c49d7792915826c9cd5930120b62932b9d6 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Wed, 10 May 2023 08:02:43 +0200
Subject: [PATCH 5/8] * devil.el (devil--saved-keys): Assign nil by default
Otherwise the variable is assigned a string.
---
devil.el | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/devil.el b/devil.el
index 5f8ecfa..d67c9da 100644
--- a/devil.el
+++ b/devil.el
@@ -144,7 +144,7 @@ occurrence `devil-key' is inserted into the buffer."
(dolist (key (split-string key))
(if (string= key "%k") (insert devil-key) (execute-kbd-macro (kbd key)))))
-(defvar devil--saved-keys
+(defvar devil--saved-keys nil ;otherwise `devil--saved-keys' is assigned a string
"Original key bindings saved by Devil.")
(defun devil-add-extra-keys ()
--
2.39.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #7: 0006-devil.el-devil-log-command-loop-info-Use-a-single-fo.patch --]
[-- Type: text/x-diff, Size: 1193 bytes --]
From 303fb740e80348ff6e44dba3c87b49edcd3842ff Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Wed, 10 May 2023 08:03:03 +0200
Subject: [PATCH 6/8] * devil.el (devil--log-command-loop-info): Use a single
'format'
---
devil.el | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/devil.el b/devil.el
index d67c9da..04229aa 100644
--- a/devil.el
+++ b/devil.el
@@ -344,11 +344,12 @@ the original Emacs key sequence."
(defun devil--log-command-loop-info ()
"Log command loop information for debugging purpose."
(devil--log
- (concat "Found "
- (format "current-prefix-arg: %s; " current-prefix-arg)
- (format "this-command: %s; " this-command)
- (format "last-command: %s; " last-command)
- (format "last-repeatable-command: %s" last-repeatable-command))))
+ (format "Found current-prefix-arg: %s; \
+this-command: %s; last-command: %s; last-repeatable-command: %s"
+ current-prefix-arg
+ this-command
+ last-command
+ last-repeatable-command)))
(defun devil--repeatable-key-p (described-key)
"Return t iff DESCRIBED-KEY belongs to `devil-repeatable-keys'."
--
2.39.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #8: 0007-Move-tests-to-separate-file-using-ERT.patch --]
[-- Type: text/x-diff, Size: 3374 bytes --]
From bfbd718aa266244b19c05d98c57d14f1eab41456 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Wed, 10 May 2023 08:05:52 +0200
Subject: [PATCH 7/8] Move tests to separate file using ERT
* devil.el: (devil--assert, devil--tests) Remove.
* devil-tests.el: Create new file.
---
devil-tests.el | 34 ++++++++++++++++++++++++++++++++++
devil.el | 24 ------------------------
2 files changed, 34 insertions(+), 24 deletions(-)
create mode 100644 devil-tests.el
diff --git a/devil-tests.el b/devil-tests.el
new file mode 100644
index 0000000..22e7071
--- /dev/null
+++ b/devil-tests.el
@@ -0,0 +1,34 @@
+;;; devil-tests.el --- Tests for devil -*- lexical-binding: t; -*-
+
+;;; Commentary:
+
+;; Unit tests for the internal devil logic. Run these with M-x ert
+;; RET devil- RET.
+
+;;; Code:
+
+(require 'ert)
+(require 'devil)
+
+(ert-deftest devil-invalid-key-p ()
+ "Test if `devil--invalid-key-p' words as expected."
+ (should (devil--invalid-key-p ""))
+ (should (devil--invalid-key-p "C-x-C-f"))
+ (should (devil--invalid-key-p "C-x CC-f"))
+ (should (not (devil--invalid-key-p "C-x C-f")))
+ (should (not (devil--invalid-key-p "C-M-x"))))
+
+(ert-deftest devil-translate ()
+ "Test if `devil-translate' works as expected."
+ (should (string= (devil-translate (vconcat ",")) "C-"))
+ (should (string= (devil-translate (vconcat ",x")) "C-x"))
+ (should (string= (devil-translate (vconcat ",x,")) "C-x C-"))
+ (should (string= (devil-translate (vconcat ",x,f")) "C-x C-f"))
+ (should (string= (devil-translate (vconcat ",,")) ","))
+ (should (string= (devil-translate (vconcat ",,,,")) ", ,"))
+ (should (string= (devil-translate (vconcat ",mx")) "C-M-x"))
+ (should (string= (devil-translate (vconcat ",mmx")) "M-x"))
+ (should (string= (devil-translate (vconcat ",mmm")) "M-m")))
+
+(provide 'devil-tests)
+;;; devil-tests.el ends here
diff --git a/devil.el b/devil.el
index 04229aa..e037a3c 100644
--- a/devil.el
+++ b/devil.el
@@ -387,29 +387,5 @@ this-command: %s; last-command: %s; last-repeatable-command: %s"
(when devil-logging
(apply #'message (concat "Devil: " format-string) args)))
-(defmacro devil--assert (form)
- "Evaluate FORM and cause error if the result is nil."
- `(unless ,form
- (error "Assertion failed: %s" ',form)))
-
-(defun devil--tests ()
- "Test Devil functions assuming Devil has not been customized."
- (devil--assert (devil--invalid-key-p ""))
- (devil--assert (devil--invalid-key-p "C-x-C-f"))
- (devil--assert (devil--invalid-key-p "C-x CC-f"))
- (devil--assert (not (devil--invalid-key-p "C-x C-f")))
- (devil--assert (not (devil--invalid-key-p "C-M-x")))
- (devil--assert (string= (devil-translate (vconcat ",")) "C-"))
- (devil--assert (string= (devil-translate (vconcat ",x")) "C-x"))
- (devil--assert (string= (devil-translate (vconcat ",x,")) "C-x C-"))
- (devil--assert (string= (devil-translate (vconcat ",x,f")) "C-x C-f"))
- (devil--assert (string= (devil-translate (vconcat ",,")) ","))
- (devil--assert (string= (devil-translate (vconcat ",,,,")) ", ,"))
- (devil--assert (string= (devil-translate (vconcat ",mx")) "C-M-x"))
- (devil--assert (string= (devil-translate (vconcat ",mmx")) "M-x"))
- (devil--assert (string= (devil-translate (vconcat ",mmm")) "M-m"))
- (message "Done"))
-
(provide 'devil)
-
;;; devil.el ends here
--
2.39.2
[-- Attachment #9: 0008-Extract-most-of-the-README-into-a-separate-manual.patch --]
[-- Type: text/x-diff, Size: 50315 bytes --]
From f78844cec4a23abe4ebdf4cab82f17b585f524b8 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Wed, 10 May 2023 08:08:21 +0200
Subject: [PATCH 8/8] Extract most of the README into a separate manual
---
MANUAL.org | 564 ++++++++++++++++++++++++++++++++++++++++++++++++++
README.md | 594 +----------------------------------------------------
2 files changed, 565 insertions(+), 593 deletions(-)
create mode 100644 MANUAL.org
diff --git a/MANUAL.org b/MANUAL.org
new file mode 100644
index 0000000..3cd3ca9
--- /dev/null
+++ b/MANUAL.org
@@ -0,0 +1,564 @@
+#+title: Devil Mode
+#+author: Susam Pal
+#+email: susam@susam.net
+#+language: en
+#+options: ':t toc:nil author:t email:t num:t
+#+texinfo_dir_category: Emacs misc features
+#+texinfo_dir_title: Devil: (devil-mode)
+#+texinfo_dir_desc: Minor mode for Devil-like command entering
+
+#+texinfo: @insertcopying
+
+Devil mode intercepts our keystrokes and translates them to Emacs key
+sequences according to a configurable set of translation rules. For
+example, with the default translation rules, when we type =, x , f=,
+Devil translates it to =C-x C-f=.
+
+The choice of the comma key (=,=) to mean the control modifier key
+(=C-=) may seem outrageous. After all, the comma is a very important
+punctuation both in prose as well as in code. Can we really get away
+with using =,= to mean the =C-= modifier? It turns out, this terrible
+idea can be made to work without too much of a hassle. At least it works
+for me! It might work for you too. If it does not, Devil can be
+configured to use another key instead of =,= to mean the =C-= modifier.
+See the section [[#custom-devil-key][Custom Devil Key]] for an example.
+
+A sceptical reader may rightfully ask: If =,= is translated to =C-=, how
+on earth are we going to insert a literal =,= into the text when we need
+to? The section [[#typing-commas][Typing Commas]] answers this. But
+before we get there, we have some fundamentals to cover. Take the plunge
+and see what unfolds! Maybe you will like this! Maybe you will not! If
+you do not like this, you can always retreat to God mode, Evil mode, the
+vanilla key bindings, or whatever piques your fancy!
+
+* Notation
+:PROPERTIES:
+:CUSTOM_ID: notation
+:END:
+A quick note about the notation used in the document: The previous
+example shows that =, x , f= is translated to =C-x C-f=. What this
+really means is that the key sequence ,x,f is translated to ctrl+x
+ctrl+f. We do not really type any space after the commas. The key , is
+directly followed by the key x. However, the key sequence notation used
+in this document contains spaces between each keystroke. This is
+consistent with how key sequences are represented in Emacs in general
+and how Emacs functions like =key-description=, =describe-key=, etc.
+represent key sequences. When we really need to type a space, it is
+represented as =SPC=.
+
+* Install
+:PROPERTIES:
+:CUSTOM_ID: install
+:END:
+** Install Interactively from MELPA
+:PROPERTIES:
+:CUSTOM_ID: install-interactively-from-melpa
+:END:
+Devil is available via [[https://melpa.org/][MELPA]]. You may already
+have a preferred way of installing packages from MELPA. If so, install
+the package named =devil= to get Devil. For the sake of completeness,
+here is a very basic way of installing Devil from MELPA:
+
+1. Add the following to the Emacs initialization file (i.e., =~/.emacs=
+ or =~/.emacs.d/init.el= or =~/.config/emacs/init.el=):
+
+ #+begin_src sh
+ (require 'package)
+ (add-to-list 'package-archives '("melpa" . "https://melpa.org/packages/") t)
+ (package-initialize)
+ #+end_src
+
+2. Start Emacs with the updated initialization file and then type these
+ commands:
+
+ #+begin_example
+ M-x package-refresh-contents RET
+ M-x package-install RET devil RET
+ #+end_example
+
+3. Confirm that Devil is installed successfully with this command:
+
+ #+begin_example
+ M-x devil-show-version RET
+ #+end_example
+
+4. Enable Devil mode with this command:
+
+ #+begin_example
+ M-x global-devil-mode RET
+ #+end_example
+
+5. Type =, x , f= and watch Devil translate it to =C-x C-f= and invoke
+ the corresponding command.
+
+** Install Automatically from MELPA
+:PROPERTIES:
+:CUSTOM_ID: install-automatically-from-melpa
+:END:
+Here is yet another basic way to install and enable Devil using Elisp:
+
+#+begin_example
+(require 'package)
+(add-to-list 'package-archives '("melpa" . "https://melpa.org/packages/") t)
+(package-initialize)
+(unless package-archive-contents
+ (package-refresh-contents))
+(unless (package-installed-p 'devil)
+ (package-install 'devil))
+(global-devil-mode)
+(global-set-key (kbd "C-,") 'global-devil-mode)
+#+end_example
+
+Now type =, x , f= and watch Devil translate it to =C-x C-f= and invoke
+the corresponding command. Type =C-,= to disable Devil mode. Type =C-,=
+again to enable it.
+
+** Install from Git Source
+:PROPERTIES:
+:CUSTOM_ID: install-from-git-source
+:END:
+If you prefer obtaining Devil from its Git repository, follow these
+steps:
+
+1. Clone Devil to your system:
+
+ #+begin_src sh
+ git clone https://github.com/susam/devil.git
+ #+end_src
+
+2. Add the following to your Emacs initialization:
+
+ #+begin_example
+ (add-to-list 'load-path "/path/to/devil/")
+ (require 'devil)
+ (global-devil-mode)
+ (global-set-key (kbd "C-,") 'global-devil-mode)
+ #+end_example
+
+3. Start the Emacs editor. Devil mode should now be enabled in all
+ buffers. The modeline of each buffer should show the =Devil= lighter.
+
+4. Type =, x , f= and watch Devil translate it to =C-x C-f= and invoke
+ the corresponding command. Type =C-,= to disable Devil mode. Type
+ =C-,= again to enable it.
+
+* Use Devil
+ :PROPERTIES:
+ :CUSTOM_ID: use-devil
+ :END:
+Assuming vanilla Emacs key bindings have not been changed and Devil has
+not been customised, here are some examples that demonstrate how Devil
+may be used:
+
+1. Type =, x , f= and watch Devil translate it to =C-x C-f= and invoke
+ the find file functionality.
+
+2. Type =, p= to move up one line.
+
+3. To move up multiple lines, type =, p p p= and so on. Some Devil key
+ sequences are repeatable keys. The repeatable Devil key sequences can
+ be repeated by typing the last key of the Devil key sequence over and
+ over again.
+
+4. Another example of a repeatable Devil key sequence is =, f f f= which
+ moves the cursor word by multiple characters. A few other examples of
+ repeatable keys are =, k k k= to kill lines, =, / / /= to undo
+ changs, etc. Type =C-h v devil-repeatable-keys RET= to see the
+ complete list of repeatable keys.
+
+5. Type =, s= and watch Devil translate it to =C-s= and invoke
+ incremental search.
+
+6. Type =, m s= and watch Devil translate it to =C-M-s= and invoke
+ regular-expression-based incremental search. Yes, =m= is translated
+ to =M-=.
+
+7. Type =, m m x= and watch Devil translate it to =M-x= and invoke the
+ corresponding command.
+
+8. Type =, u , f= and watch Devil translate it to =C-u C-f= and move the
+ cursor forward by 4 characters.
+
+9. Type =, u u , f= and the cursor moves forward by 16 characters. Devil
+ uses its translation rules and an additional keymap to make the input
+ key sequence behave like =C-u C-u C-f= which moves the cursor forward
+ by 16 characters.
+
+10. Type =, SPC= to type a comma followed by space. This is a special
+ key sequence to make it convenient to type a comma in the text. Note
+ that this sacrifices the use of =, SPC= to mean =C-SPC= which could
+ have been a convenient way to set a mark.
+
+11. Type =, z SPC= and watch Devil translate it to =C-SPC= and set a
+ mark. Yes, =, z= is translated to =C-= too.
+
+12. Similarly, type =, RET= to type a comma followed by the return key.
+ This is another special key.
+
+13. Type =, ,= to type a single comma. This special key is useful for
+ cases when you really need to type a single literal comma.
+
+* Typing Commas
+ :PROPERTIES:
+ :CUSTOM_ID: typing-commas
+ :END:
+Devil makes the questionable choice of using the comma as its activation
+key. As illustrated in the previous section, typing =, x , f= produces
+the same effect as typing =C-x C-f=. One might naturally wonder how then
+we are supposed to type literal commas.
+
+Most often when we edit text, we do not really type a comma in
+isolation. Often we immediately follow the comma with a space or a
+newline. This assumption usually holds good while editing regular text.
+However, this assumption may not hold in some situations, like while
+working with code when we need to add a single comma at the end of an
+existing line.
+
+In scenarios where the above assumption holds good, typing =, SPC=
+inserts a comma and a space. Similarly, typing =, RET= inserts a comma
+and a newline.
+
+In scenarios, when we do need to type a single comma, type =, ,=
+instead.
+
+Also, it is worth mentioning here that if all this fiddling with the
+comma key feels clumsy, we could always customise the Devil key to
+something else that feels better. We could also disable Devil mode
+temporarily and enable it again later with =C-,= as explained in section
+[[#use-devil][Use Devil]].
+
+* Devil Reader
+ :PROPERTIES:
+ :CUSTOM_ID: devil-reader
+ :END:
+The following points briefly describe how Devil reads Devil key
+sequences, translates them to Emacs key sequences, and runs commands
+bound to the key sequences:
+
+1. As soon as the Devil key is typed (which is =,= by default), Devil
+ wakes up and starts reading Devil key sequences. Type
+ =C-h v devil-key RET= to see the current Devil key.
+
+2. After each keystroke is read, Devil checks if the key sequence
+ accumulated is a special key. If it is, then the special command
+ bound to the special key is executed immediately. Note that this step
+ is performed before any translation rules are applied to the input
+ key sequence. This is how the Devil special key sequence =, SPC=
+ inserts a comma and a space. Type =C-h v devil-special-keys RET=
+ to see the list of special keys and the commands bound to them.
+
+3. If the key sequence accumulated so far is not a special key, then
+ Devil translates the Devil key sequence to a regular Emacs key
+ sequence. If the regular Emacs key sequence turns out to be a
+ complete key sequence and some command is found to be bound to it,
+ then that command is executed immediately. This is how the Devil key
+ sequence =, x , f= is translated to =C-x C-f= and the corresponding
+ binding is executed. If the translated key sequence is a complete key
+ sequence but no command is bound to it, then Devil displays a message
+ that the key sequence is undefined. Type
+ =C-h v devil-translations RET= to see the list of translation rules.
+
+4. After successfully translating a Devil key sequence to an Emacs key
+ sequence and executing the command bound to it, Devil checks if the
+ key sequence is a repeatable key sequence. If it is found to be a
+ repeatable key sequence, then Devil sets a transient map so that the
+ command can be repeated merely by typing the last keystroke of the
+ input key sequence. This is how =, p p p= moves the cursor up by
+ three lines. Type =C-h v devil-repeatable-keys RET= to see the
+ list of repeatable Devil key sequences.
+
+The variables =devil-special-keys=, =devil-translations=, and
+=devil-repeatable-keys= may contain keys or values with the string =%k=
+in them. This is a placeholder for =devil-key=. While applying the
+special keys, translation rules, or repeat rules, each =%k= is replaced
+with the actual value of =devil-key= before applying the rules.
+
+* Translation Rules
+ :PROPERTIES:
+ :CUSTOM_ID: translation-rules
+ :END:
+The following points provide an account of the translation rules that
+Devil follows in order to convert a Devil key sequence entered by the
+user to an Emacs key sequence:
+
+1. The input key vector read from the user is converted to a key
+ description (i.e., the string functions like =describe-key=,
+ =key-description=, produce). For example, if the user types ,x,f, it
+ is converted to =, x , f=.
+
+2. Now the resulting key description is translated with simple string
+ replacements. If any part of the string matches a key in
+ =devil-translations=, then it is replaced with the corresponding
+ value. For example, =, x , f= is translated to =C- x C- f=. Then
+ Devil normalises the result to =C-x C-f= by removing superfluous
+ spaces after the modifier keys.
+
+3. However, if the simple string based replacement leads to an invalid
+ Emacs key sequence, it skips the replacement that causes the
+ resulting Emacs key sequence to become invalid. For example
+ =, m ,= results in =C-M-C-= after the simple string replacement
+ because the default translation rules replace =,= with =C-= and =m=
+ with =M-=. However, =C-M-C-= is an invalid key sequence, so the
+ replacement of the second =,= to =C-= is skipped. Therefore, the
+ input =, m ,= is translated to =C-M-,= instead.
+
+* Translation Examples
+ :PROPERTIES:
+ :CUSTOM_ID: translation-examples
+ :END:
+By default, Devil supports a small but peculiar set of translation rules
+that can be used to avoid modifier keys while typing various types of
+key sequences. See =C-h v devil-translations RET= for the translation
+rules. Here are some examples that demonstrate the default translation
+rules. The obvious ones are shown first first. The more peculiar
+translations come later in the table.
+
+| Input | Translated | Remarks |
+|-----------+------------+-----------------------------------|
+| =, s= | =C-s= | =,= is replaced with =C-= |
+| =, m s= | =C-M-s= | =m= is replaced with =M-= |
+| =, z s= | =C-SPC= | =, z= is replaced with =C-= too |
+| =, z z= | =C-z= | ditto |
+| =, m m x= | =M-x= | =, m m= is replaced with =M-= too |
+| =, c , ,= | =C-c ,= | =, ,= is replaced with =,= |
+
+Note how we cannot use =, SPC= to set a mark because that key sequence
+is already reserved as a special key sequence in =devil-special-keys=,
+so Devil translates =, z= to =C-= too, so that we can still type =C-SPC=
+using =, z s= and set a mark.
+
+Also, note how the translation of =, m m= to =M-= allows us to enter a
+key sequence that begins with the =M-= modifier key.
+
+* Bonus Key Bindings
+ :PROPERTIES:
+ :CUSTOM_ID: bonus-key-bindings
+ :END:
+Devil adds the following additional key bindings only when Devil is
+enabled globally with =global-devil-mode=:
+
+- Adds the Devil key to =isearch-mode-map=, so that Devil key sequences
+ work in incremental search too.
+
+- Adds =u= to =universal-argument-more= to allow repeating the universal
+ argument command =C-u= simply by repeating =u=.
+
+As mentioned before these features are available only when Devil is
+enabled globally with =global-devil-mode=. If Devil is enabled locally
+with =devil-mode=, then these features are not available.
+
+* Custom Configuration Examples
+ :PROPERTIES:
+ :CUSTOM_ID: custom-configuration-examples
+ :END:
+In the examples presented below, the =(require 'devil)= calls may be
+omitted if Devil has been installed from MELPA. There are appropriate
+autoloads in place in the Devil package that would ensure that it is
+loaded automatically on enabling Devil mode. However, the =require=
+calls have been included in the examples below for the sake of
+completeness.
+
+** Local Mode
+ :PROPERTIES:
+ :CUSTOM_ID: local-mode
+ :END:
+While the section [[#use-devil][Use Devil]] shows how we enable Devil mode globally,
+this section shows how we can enable it locally. Here is an example
+initialization code that enables Devil locally only in text buffers.
+
+#+begin_example
+(require 'devil)
+(add-hook 'text-mode-hook 'devil-mode)
+(global-set-key (kbd "C-,") 'devil-mode)
+#+end_example
+
+This is not recommended though because this does not provide a seamless
+Devil experience. For example, with Devil enabled locally in a text
+buffer like this, although we can type =, x , f= to launch the find-file
+minibuffer, we cannot use Devil key sequences in the minibuffer. Further
+the special keymaps described in the previous section work only when
+Devil is enabled globally.
+
+** Custom Appearance
+ :PROPERTIES:
+ :CUSTOM_ID: custom-appearance
+ :END:
+The following initialization code shows how we can customise Devil to
+show a Devil smiley (😈) in the modeline and the echo area.
+
+#+begin_example
+(require 'devil)
+(setq devil-lighter " \U0001F608")
+(setq devil-prompt "\U0001F608 %t")
+(global-devil-mode)
+(global-set-key (kbd "C-,") 'global-devil-mode)
+#+end_example
+
+This is how Emacs may look if emojis are rendered correctly:
+
+[[https://i.imgur.com/oYtwnGi.png][[[https://i.imgur.com/oYtwnGi.png]]]]
+
+** Custom Devil Key
+ :PROPERTIES:
+ :CUSTOM_ID: custom-devil-key
+ :END:
+The following initialization code shows how we can customise Devil to
+use a different Devil key.
+
+#+begin_example
+(defvar devil-key "<left>")
+(defvar devil-special-keys '(("%k %k" . (lambda () (interactive) (devil-run-key "%k")))))
+(require 'devil)
+(global-devil-mode)
+(global-set-key (kbd "C-<left>") 'global-devil-mode)
+#+end_example
+
+The above example sets the Devil key to the left arrow key, perhaps
+another dubious choice for the Devil key. With this configuration, we
+can use =<left> x <left> f= and have Devil translate it to =C-x C-f=.
+
+Additionally, the above example defines the =devil-special-keys=
+variable to have a single entry that allows typing =<left> <left>= to
+produce the same effect as the original =<left>=. It removes the other
+entries, so that =<left> SPC= is no longer reserved as a special key.
+Thus =<left> SPC= can now be used to set a mark like one would normally
+expect.
+
+** Multiple Devil Keys
+ :PROPERTIES:
+ :CUSTOM_ID: multiple-devil-keys
+ :END:
+While this package provides the comma (=,=) as the default and the only
+Devil key, nothing stops you from extending the mode map to support
+multiple Devil keys. Say, you decide that in addition to activating
+Devil with =,= which also plays the role of =C-=, you also want to
+activate Devil with =.= which must now play the role of =M-=. To achieve
+such a result, you could use this initialization code as a starting
+point and then customise it further based on your requirements:
+
+#+begin_example
+(defvar devil-mode-map
+ (let ((map (make-sparse-keymap)))
+ (define-key map (kbd ",") #'devil)
+ (define-key map (kbd ".") #'devil)
+ map))
+(defvar devil-special-keys '((", ," . (lambda () (insert ",")))
+ (". ." . (lambda () (insert ".")))))
+(defvar devil-translations '(("," . "C-")
+ ("." . "M-")))
+(require 'devil)
+(global-devil-mode)
+#+end_example
+
+With this configuration, we can type =, x , f= for =C-x C-f= like
+before. But now we can also type =. x= for =M-x=. Similarly, we can type
+=, . s= for =C-M-s= and so on. Further, =, ,= inserts a literal comma
+and =. .= inserts a literal dot.
+
+Note that by default Devil configures only one activation key (=,=)
+because the more activation keys we add, the more intrusive Devil
+becomes during regular editing tasks. Every key that we reserve for
+activating Devil loses its default function and then we need workarounds
+to somehow invoke the default function associated with that key (like
+repeating =.= twice to insert a single =.= in the above example).
+Therefore, it is a good idea to keep the number of Devil keys as small
+as possible.
+
+* Why?
+ :PROPERTIES:
+ :CUSTOM_ID: why
+ :END:
+Why go to the trouble of creating and using something like this? Why not
+just remap caps lock to ctrl like every other sane person does? Or if it
+is so important to avoid modifier keys, why not use something like God
+mode or Evil mode?
+
+Well, for one, both God mode and Evil mode are modal editing modes.
+Devil, on the other hand, provides a modeless editing experience of
+Emacs as possible.
+
+Devil mode began as a fun little tiny experiment. From the outset, it
+was clear that using something as crucial as the comma for specifying
+the modifier key is asking for trouble. However, I still wanted to see
+how far I could go with it. It turned out that in a matter of days, I
+was using it full-time for all of my Emacs usage.
+
+This experiment was partly motivated by Macbook keyboards which do not
+have a right ctrl key. Being a touch-typist myself, I found it
+inconvenient to type key combinations like =C-x=, =C-a=, =C-w=, =C-s=,
+etc. where both the modifier key and the modified key need to be pressed
+with the left hand fingers. I am not particularly fond of remapping caps
+lock to behave like ctrl because that still suffers from the problem
+that key combinations like =C-x=, =C-a= require pressing both the
+modifier key and the modified key with the left hand fingers. I know
+many people remap both their caps lock and enter to behave like ctrl.
+While I think that is a fine solution, I was not willing to put up with
+the work required to make that work seamlessly across all the various
+operating systems I work on.
+
+What began as a tiny whimsical experiment a few years ago turned out to
+be quite effective, at least to me. I like that this solution is
+implemented purely as Elisp and therefore does not have any external
+dependency. I am sharing this solution here in the form of a minor mode,
+just in case, there is someone out there who might find this useful too.
+
+* Comparison with God Mode
+ :PROPERTIES:
+ :CUSTOM_ID: comparison-with-god-mode
+ :END:
+God mode provides a modal editing experience but Devil does not. Devil
+has the same underlying philosophy as that of God mode, i.e., the user
+should not have to learn new key bindings. However, Devil does not have
+a hard separation between insert mode and command mode like God mode
+has. Instead, Devil waits for an activation key (=,= by default) and as
+soon as it is activated, it intercepts and translates keys, runs the
+corresponding command, and then gets out of the way. So Devil tries to
+retain the modeless editing experience of vanilla Emacs as much as
+possible.
+
+Now it is worth mentioning that some of this modeless editing experience
+can be reproduced in god-mode too using its
+=god-execute-with-current-bindings= function. Here is an example:
+
+#+begin_example
+(global-set-key (kbd ",") #'god-execute-with-current-bindings)
+#+end_example
+
+With this configuration, God mode translates =, x f= to =C-x C-f=.
+Similarly =, g x= invokes =M-x= and =, G s= invokes =C-M-x=. This
+provides a modeless editing experience in God mode too. However, this
+experience does not extend seamlessly to minibuffers. Devil does extend
+its Devil key translation to minibuffers.
+
+Further note that in God mode the ctrl modifier has sticky behaviour,
+i.e., the modifier remains active automatically for the entire key
+sequence. Therefore in the above example, we type =,= only once while
+typing =, x f= to invoke =C-x C-f=. However, this sticky behaviour
+implies that we need some way to disambiguate between key sequences like
+=C-x C-o= (delete blank lines) and =C-x o= (other window). God mode
+solves this by introducing =SPC= to deactivate the modifier, e.g.,
+=, x o= translates to =C-x C-o= but =, x SPC o= translates to =C-x o=.
+Devil does not treat the modifier key as sticky which leads to simpler
+key sequences at the cost of a little additional typing, i.e., =, x , o=
+translates to =C-x C-o= and =, x o= translates to =C-x o=.
+
+To summarize, there are primarily three things that Devil does
+differently:
+
+- Provide a modeless editing experience from the outset.
+- Seamlessly extend the same editing experience to minibuffer,
+ incremental search, etc.
+- Translate key sequences using string replacements. This allows for
+ arbitrary and sophisticated key translations for the adventurous.
+- Choose non-sticky behaviour for the modifier keys.
+
+These differences could make Devil easier to use than God mode for some
+people but clumsy for other people. It depends on one's tastes and
+preferences.
+
+* Support
+ :PROPERTIES:
+ :CUSTOM_ID: support
+ :END:
+To report bugs, suggest improvements, or ask questions,
+[[https://github.com/susam/devil/issues][create issues]].
diff --git a/README.md b/README.md
index 749508c..39ef57e 100644
--- a/README.md
+++ b/README.md
@@ -13,599 +13,7 @@ charm the Devil! But beware, for in this sinister domain, you must
relinquish your comma key and embrace an editing experience that
whispers wicked secrets into your fingertips!
-
-Contents
---------
-
-* [Introduction](#introduction)
-* [Notation](#notation)
-* [Install](#install)
- * [Install Interactively from MELPA](#install-interactively-from-melpa)
- * [Install Automatically from MELPA](#install-automatically-from-melpa)
- * [Install from Git Source](#install-from-git-source)
-* [Use Devil](#use-devil)
-* [Typing Commas](#typing-commas)
-* [Devil Reader](#devil-reader)
-* [Translation Rules](#translation-rules)
-* [Translation Examples](#translation-examples)
-* [Bonus Key Bindings](#bonus-key-bindings)
-* [Custom Configuration Examples](#custom-configuration-examples)
- * [Local Mode](#local-mode)
- * [Custom Appearance](#custom-appearance)
- * [Custom Devil Key](#custom-devil-key)
- * [Multiple Devil Keys](#multiple-devil-keys)
-* [Why?](#why)
-* [Comparison with God Mode](#comparison-with-god-mode)
-* [Support](#support)
-* [Channels](#channels)
-* [More](#more)
-
-
-Introduction
-------------
-
-Devil mode intercepts our keystrokes and translates them to Emacs key
-sequences according to a configurable set of translation rules. For
-example, with the default translation rules, when we type `, x , f`,
-Devil translates it to `C-x C-f`.
-
-The choice of the comma key (`,`) to mean the control modifier key
-(`C-`) may seem outrageous. After all, the comma is a very important
-punctuation both in prose as well as in code. Can we really get away
-with using `,` to mean the `C-` modifier? It turns out, this terrible
-idea can be made to work without too much of a hassle. At least it
-works for me! It might work for you too. If it does not, Devil can be
-configured to use another key instead of `,` to mean the `C-`
-modifier. See the section [Custom Devil Key](#custom-devil-key) for an
-example.
-
-A sceptical reader may rightfully ask: If `,` is translated to `C-`,
-how on earth are we going to insert a literal `,` into the text when
-we need to? The section [Typing Commas](#typing-commas) answers this.
-But before we get there, we have some fundamentals to cover. Take the
-plunge and see what unfolds! Maybe you will like this! Maybe you will
-not! If you do not like this, you can always retreat to God mode, Evil
-mode, the vanilla key bindings, or whatever piques your fancy!
-
-
-Notation
---------
-
-A quick note about the notation used in the document: The previous
-example shows that `, x , f` is translated to `C-x C-f`. What this
-really means is that the key sequence
-<kbd>,</kbd><kbd>x</kbd><kbd>,</kbd><kbd>f</kbd> is translated to
-<kbd>ctrl</kbd>+<kbd>x</kbd> <kbd>ctrl</kbd>+<kbd>f</kbd>. We do not
-really type any space after the commas. The key <kbd>,</kbd> is
-directly followed by the key <kbd>x</kbd>. However, the key sequence
-notation used in this document contains spaces between each keystroke.
-This is consistent with how key sequences are represented in Emacs in
-general and how Emacs functions like `key-description`,
-`describe-key`, etc. represent key sequences. When we really need to
-type a space, it is represented as `SPC`.
-
-
-Install
--------
-
-### Install Interactively from MELPA
-
-Devil is available via [MELPA](https://melpa.org/). You may already
-have a preferred way of installing packages from MELPA. If so, install
-the package named `devil` to get Devil. For the sake of completeness,
-here is a very basic way of installing Devil from MELPA:
-
- 1. Add the following to the Emacs initialization file (i.e.,
- `~/.emacs` or `~/.emacs.d/init.el` or `~/.config/emacs/init.el`):
-
- ```sh
- (require 'package)
- (add-to-list 'package-archives '("melpa" . "https://melpa.org/packages/") t)
- (package-initialize)
- ```
-
- 2. Start Emacs with the updated initialization file and then type
- these commands:
-
- ```
- M-x package-refresh-contents RET
- M-x package-install RET devil RET
- ```
-
- 3. Confirm that Devil is installed successfully with this command:
-
- ```
- M-x devil-show-version RET
- ```
-
- 4. Enable Devil mode with this command:
-
- ```
- M-x global-devil-mode RET
- ```
-
- 4. Type `, x , f` and watch Devil translate it to `C-x C-f` and
- invoke the corresponding command.
-
-
-### Install Automatically from MELPA
-
-Here is yet another basic way to install and enable Devil using Elisp:
-
-```elisp
-(require 'package)
-(add-to-list 'package-archives '("melpa" . "https://melpa.org/packages/") t)
-(package-initialize)
-(unless package-archive-contents
- (package-refresh-contents))
-(unless (package-installed-p 'devil)
- (package-install 'devil))
-(global-devil-mode)
-(global-set-key (kbd "C-,") 'global-devil-mode)
-```
-
-Now type `, x , f` and watch Devil translate it to `C-x C-f` and
-invoke the corresponding command. Type `C-,` to disable Devil mode.
-Type `C-,` again to enable it.
-
-
-### Install from Git Source
-
-If you prefer obtaining Devil from its Git repository, follow these
-steps:
-
- 1. Clone Devil to your system:
-
- ```sh
- git clone https://github.com/susam/devil.git
- ```
-
- 2. Add the following to your Emacs initialization:
-
- ```elisp
- (add-to-list 'load-path "/path/to/devil/")
- (require 'devil)
- (global-devil-mode)
- (global-set-key (kbd "C-,") 'global-devil-mode)
- ```
-
- 3. Start the Emacs editor. Devil mode should now be enabled in all
- buffers. The modeline of each buffer should show the `Devil`
- lighter.
-
- 4. Type `, x , f` and watch Devil translate it to `C-x C-f` and
- invoke the corresponding command. Type `C-,` to disable Devil
- mode. Type `C-,` again to enable it.
-
-
-Use Devil
----------
-
-Assuming vanilla Emacs key bindings have not been changed and Devil
-has not been customised, here are some examples that demonstrate how
-Devil may be used:
-
- 1. Type `, x , f` and watch Devil translate it to `C-x C-f` and
- invoke the find file functionality.
-
- 2. Type `, p` to move up one line.
-
- 3. To move up multiple lines, type `, p p p` and so on. Some Devil
- key sequences are repeatable keys. The repeatable Devil key
- sequences can be repeated by typing the last key of the Devil key
- sequence over and over again.
-
- 4. Another example of a repeatable Devil key sequence is `, f f f`
- which moves the cursor word by multiple characters. A few other
- examples of repeatable keys are `, k k k` to kill lines, `, / / /`
- to undo changs, etc. Type `C-h v devil-repeatable-keys RET` to see
- the complete list of repeatable keys.
-
- 5. Type `, s` and watch Devil translate it to `C-s` and invoke
- incremental search.
-
- 6. Type `, m s` and watch Devil translate it to `C-M-s` and invoke
- regular-expression-based incremental search. Yes, `m` is
- translated to `M-`.
-
- 7. Type `, m m x` and watch Devil translate it to `M-x` and invoke
- the corresponding command.
-
- 8. Type `, u , f` and watch Devil translate it to `C-u C-f` and move
- the cursor forward by 4 characters.
-
- 9. Type `, u u , f` and the cursor moves forward by 16 characters.
- Devil uses its translation rules and an additional keymap to make
- the input key sequence behave like `C-u C-u C-f` which moves the
- cursor forward by 16 characters.
-
-10. Type `, SPC` to type a comma followed by space. This is a special
- key sequence to make it convenient to type a comma in the text.
- Note that this sacrifices the use of `, SPC` to mean `C-SPC` which
- could have been a convenient way to set a mark.
-
-11. Type `, z SPC` and watch Devil translate it to `C-SPC` and set a
- mark. Yes, `, z` is translated to `C-` too.
-
-12. Similarly, type `, RET` to type a comma followed by the return
- key. This is another special key.
-
-13. Type `, ,` to type a single comma. This special key is useful for
- cases when you really need to type a single literal comma.
-
-
-Typing Commas
--------------
-
-Devil makes the questionable choice of using the comma as its
-activation key. As illustrated in the previous section, typing
-`, x , f` produces the same effect as typing `C-x C-f`. One might
-naturally wonder how then we are supposed to type literal commas.
-
-Most often when we edit text, we do not really type a comma in
-isolation. Often we immediately follow the comma with a space or a
-newline. This assumption usually holds good while editing regular
-text. However, this assumption may not hold in some situations, like
-while working with code when we need to add a single comma at the end
-of an existing line.
-
-In scenarios where the above assumption holds good, typing `, SPC`
-inserts a comma and a space. Similarly, typing `, RET` inserts a comma
-and a newline.
-
-In scenarios, when we do need to type a single comma, type `, ,` instead.
-
-Also, it is worth mentioning here that if all this fiddling with the
-comma key feels clumsy, we could always customise the Devil key to
-something else that feels better. We could also disable Devil mode
-temporarily and enable it again later with `C-,` as explained in
-section [Get Started](#get-started).
-
-
-Devil Reader
-------------
-
-The following points briefly describe how Devil reads Devil key
-sequences, translates them to Emacs key sequences, and runs commands
-bound to the key sequences:
-
- 1. As soon as the Devil key is typed (which is `,` by default), Devil
- wakes up and starts reading Devil key sequences. Type `C-h v
- devil-key RET` to see the current Devil key.
-
- 2. After each keystroke is read, Devil checks if the key sequence
- accumulated is a special key. If it is, then the special command
- bound to the special key is executed immediately. Note that this
- step is performed before any translation rules are applied to the
- input key sequence. This is how the Devil special key sequence `,
- SPC` inserts a comma and a space. Type `C-h v
- devil-special-keys RET` to see the list of special keys and
- the commands bound to them.
-
- 3. If the key sequence accumulated so far is not a special key, then
- Devil translates the Devil key sequence to a regular Emacs key
- sequence. If the regular Emacs key sequence turns out to be a
- complete key sequence and some command is found to be bound to it,
- then that command is executed immediately. This is how the Devil
- key sequence `, x , f` is translated to `C-x C-f` and the
- corresponding binding is executed. If the translated key sequence
- is a complete key sequence but no command is bound to it, then
- Devil displays a message that the key sequence is undefined. Type
- `C-h v devil-translations RET` to see the list of translation
- rules.
-
- 4. After successfully translating a Devil key sequence to an Emacs
- key sequence and executing the command bound to it, Devil checks
- if the key sequence is a repeatable key sequence. If it is found
- to be a repeatable key sequence, then Devil sets a transient map
- so that the command can be repeated merely by typing the last
- keystroke of the input key sequence. This is how `, p p p` moves
- the cursor up by three lines. Type `C-h v devil-repeatable-keys
- RET` to see the list of repeatable Devil key sequences.
-
-The variables `devil-special-keys`, `devil-translations`, and
-`devil-repeatable-keys` may contain keys or values with the string
-`%k` in them. This is a placeholder for `devil-key`. While applying
-the special keys, translation rules, or repeat rules, each `%k` is
-replaced with the actual value of `devil-key` before applying the
-rules.
-
-
-Translation Rules
------------------
-
-The following points provide an account of the translation rules that
-Devil follows in order to convert a Devil key sequence entered by the
-user to an Emacs key sequence:
-
- 1. The input key vector read from the user is converted to a key
- description (i.e., the string functions like `describe-key`,
- `key-description`, produce). For example, if the user types
- <kbd>,</kbd><kbd>x</kbd><kbd>,</kbd><kbd>f</kbd>, it is converted
- to `, x , f`.
-
- 2. Now the resulting key description is translated with simple string
- replacements. If any part of the string matches a key in
- `devil-translations`, then it is replaced with the corresponding
- value. For example, `, x , f` is translated to `C- x C- f`. Then
- Devil normalises the result to `C-x C-f` by removing superfluous
- spaces after the modifier keys.
-
- 3. However, if the simple string based replacement leads to an
- invalid Emacs key sequence, it skips the replacement that causes
- the resulting Emacs key sequence to become invalid. For example `,
- m ,` results in `C-M-C-` after the simple string replacement
- because the default translation rules replace `,` with `C-` and
- `m` with `M-`. However, `C-M-C-` is an invalid key sequence, so
- the replacement of the second `,` to `C-` is skipped. Therefore,
- the input `, m ,` is translated to `C-M-,` instead.
-
-
-Translation Examples
---------------------
-
-By default, Devil supports a small but peculiar set of translation
-rules that can be used to avoid modifier keys while typing various
-types of key sequences. See `C-h v devil-translations RET` for the
-translation rules. Here are some examples that demonstrate the default
-translation rules. The obvious ones are shown first first. The more
-peculiar translations come later in the table.
-
-| Input | Translated | Remarks |
-|-----------|------------|------------------------------------|
-| `, s` | `C-s` | `,` is replaced with `C-` |
-| `, m s` | `C-M-s` | `m` is replaced with `M-` |
-| `, z s` | `C-SPC` | `, z` is replaced with `C-` too |
-| `, z z` | `C-z` | ditto |
-| `, m m x` | `M-x` | `, m m` is replaced with `M-` too |
-| `, c , ,` | `C-c ,` | `, ,` is replaced with `,` |
-
-Note how we cannot use `, SPC` to set a mark because that key sequence
-is already reserved as a special key sequence in `devil-special-keys`,
-so Devil translates `, z` to `C-` too, so that we can still type
-`C-SPC` using `, z s` and set a mark.
-
-Also, note how the translation of `, m m` to `M-` allows us to enter a
-key sequence that begins with the `M-` modifier key.
-
-
-Bonus Key Bindings
-------------------
-
-Devil adds the following additional key bindings only when Devil is
-enabled globally with `global-devil-mode`:
-
-- Adds the Devil key to `isearch-mode-map`, so that Devil key
- sequences work in incremental search too.
-
-- Adds `u` to `universal-argument-more` to allow repeating the
- universal argument command `C-u` simply by repeating `u`.
-
-As mentioned before these features are available only when Devil is
-enabled globally with `global-devil-mode`. If Devil is enabled locally
-with `devil-mode`, then these features are not available.
-
-
-Custom Configuration Examples
------------------------------
-
-In the examples presented below, the `(require 'devil)` calls may be
-omitted if Devil has been installed from MELPA. There are appropriate
-autoloads in place in the Devil package that would ensure that it is
-loaded automatically on enabling Devil mode. However, the `require`
-calls have been included in the examples below for the sake of
-completeness.
-
-
-### Local Mode
-
-While the section [Get Started](#get-started) shows how we enable
-Devil mode globally, this section shows how we can enable it locally.
-Here is an example initialization code that enables Devil locally only
-in text buffers.
-
-```elisp
-(require 'devil)
-(add-hook 'text-mode-hook 'devil-mode)
-(global-set-key (kbd "C-,") 'devil-mode)
-```
-
-This is not recommended though because this does not provide a
-seamless Devil experience. For example, with Devil enabled locally in
-a text buffer like this, although we can type `, x , f` to launch the
-find-file minibuffer, we cannot use Devil key sequences in the
-minibuffer. Further the special keymaps described in the previous
-section work only when Devil is enabled globally.
-
-
-### Custom Appearance
-
-The following initialization code shows how we can customise Devil to
-show a Devil smiley (😈) in the modeline and the echo area.
-
-```elisp
-(require 'devil)
-(setq devil-lighter " \U0001F608")
-(setq devil-prompt "\U0001F608 %t")
-(global-devil-mode)
-(global-set-key (kbd "C-,") 'global-devil-mode)
-```
-
-This is how Emacs may look if emojis are rendered correctly:
-
-[![Screenshot of Emacs with Devil smiley][smiley-screenshot]][smiley-screenshot]
-
-[smiley-screenshot]: https://i.imgur.com/oYtwnGi.png
-
-
-### Custom Devil Key
-
-The following initialization code shows how we can customise Devil to
-use a different Devil key.
-
-```elisp
-(defvar devil-key "<left>")
-(defvar devil-special-keys '(("%k %k" . (lambda () (interactive) (devil-run-key "%k")))))
-(require 'devil)
-(global-devil-mode)
-(global-set-key (kbd "C-<left>") 'global-devil-mode)
-```
-
-The above example sets the Devil key to the left arrow key, perhaps
-another dubious choice for the Devil key. With this configuration, we
-can use `<left> x <left> f` and have Devil translate it to `C-x C-f`.
-
-Additionally, the above example defines the `devil-special-keys`
-variable to have a single entry that allows typing `<left> <left>` to
-produce the same effect as the original `<left>`. It removes the other
-entries, so that `<left> SPC` is no longer reserved as a special key.
-Thus `<left> SPC` can now be used to set a mark like one would
-normally expect.
-
-
-### Multiple Devil Keys
-
-While this package provides the comma (`,`) as the default and the
-only Devil key, nothing stops you from extending the mode map to
-support multiple Devil keys. Say, you decide that in addition to
-activating Devil with `,` which also plays the role of `C-`, you also
-want to activate Devil with `.` which must now play the role of `M-`.
-To achieve such a result, you could use this initialization code as a
-starting point and then customise it further based on your
-requirements:
-
-```elisp
-(defvar devil-mode-map
- (let ((map (make-sparse-keymap)))
- (define-key map (kbd ",") #'devil)
- (define-key map (kbd ".") #'devil)
- map))
-(defvar devil-special-keys '((", ," . (lambda () (insert ",")))
- (". ." . (lambda () (insert ".")))))
-(defvar devil-translations '(("," . "C-")
- ("." . "M-")))
-(require 'devil)
-(global-devil-mode)
-```
-
-With this configuration, we can type `, x , f` for `C-x C-f` like
-before. But now we can also type `. x` for `M-x`. Similarly, we can
-type `, . s` for `C-M-s` and so on. Further, `, ,` inserts a literal
-comma and `. .` inserts a literal dot.
-
-Note that by default Devil configures only one activation key (`,`)
-because the more activation keys we add, the more intrusive Devil
-becomes during regular editing tasks. Every key that we reserve for
-activating Devil loses its default function and then we need
-workarounds to somehow invoke the default function associated with
-that key (like repeating `.` twice to insert a single `.` in the above
-example). Therefore, it is a good idea to keep the number of Devil
-keys as small as possible.
-
-
-Why?
-----
-
-Why go to the trouble of creating and using something like this? Why
-not just remap <kbd>caps lock</kbd> to <kbd>ctrl</kbd> like every
-other sane person does? Or if it is so important to avoid modifier
-keys, why not use something like God mode or Evil mode?
-
-Well, for one, both God mode and Evil mode are modal editing modes.
-Devil, on the other hand, provides a modeless editing experience of
-Emacs as possible.
-
-Devil mode began as a fun little tiny experiment. From the outset, it
-was clear that using something as crucial as the comma for specifying
-the modifier key is asking for trouble. However, I still wanted to see
-how far I could go with it. It turned out that in a matter of days, I
-was using it full-time for all of my Emacs usage.
-
-This experiment was partly motivated by Macbook keyboards which do not
-have a right <kbd>ctrl</kbd> key. Being a touch-typist myself, I found
-it inconvenient to type key combinations like `C-x`, `C-a`, `C-w`,
-`C-s`, etc. where both the modifier key and the modified key need to
-be pressed with the left hand fingers. I am not particularly fond of
-remapping <kbd>caps lock</kbd> to behave like <kbd>ctrl</kbd> because
-that still suffers from the problem that key combinations like `C-x`,
-`C-a` require pressing both the modifier key and the modified key with
-the left hand fingers. I know many people remap both their <kbd>caps
-lock</kbd> and <kbd>enter</kbd> to behave like <kbd>ctrl</kbd>. While
-I think that is a fine solution, I was not willing to put up with the
-work required to make that work seamlessly across all the various
-operating systems I work on.
-
-What began as a tiny whimsical experiment a few years ago turned out
-to be quite effective, at least to me. I like that this solution is
-implemented purely as Elisp and therefore does not have any external
-dependency. I am sharing this solution here in the form of a minor
-mode, just in case, there is someone out there who might find this
-useful too.
-
-
-Comparison with God Mode
-------------------------
-
-God mode provides a modal editing experience but Devil does not. Devil
-has the same underlying philosophy as that of God mode, i.e., the user
-should not have to learn new key bindings. However, Devil does not
-have a hard separation between insert mode and command mode like God
-mode has. Instead, Devil waits for an activation key (`,` by default)
-and as soon as it is activated, it intercepts and translates keys,
-runs the corresponding command, and then gets out of the way. So Devil
-tries to retain the modeless editing experience of vanilla Emacs as
-much as possible.
-
-Now it is worth mentioning that some of this modeless editing
-experience can be reproduced in god-mode too using its
-`god-execute-with-current-bindings` function. Here is an example:
-
-```elisp
-(global-set-key (kbd ",") #'god-execute-with-current-bindings)
-```
-
-With this configuration, God mode translates `, x f` to `C-x C-f`.
-Similarly `, g x` invokes `M-x` and `, G s` invokes `C-M-x`. This
-provides a modeless editing experience in God mode too. However, this
-experience does not extend seamlessly to minibuffers. Devil does
-extend its Devil key translation to minibuffers.
-
-Further note that in God mode the <kbd>ctrl</kbd> modifier has sticky
-behaviour, i.e., the modifier remains active automatically for the
-entire key sequence. Therefore in the above example, we type `,` only
-once while typing `, x f` to invoke `C-x C-f`. However, this sticky
-behaviour implies that we need some way to disambiguate between key
-sequences like `C-x C-o` (delete blank lines) and `C-x o` (other
-window). God mode solves this by introducing `SPC` to deactivate the
-modifier, e.g., `, x o` translates to `C-x C-o` but `, x SPC o`
-translates to `C-x o`. Devil does not treat the modifier key as sticky
-which leads to simpler key sequences at the cost of a little
-additional typing, i.e., `, x , o` translates to `C-x C-o` and `, x o`
-translates to `C-x o`.
-
-To summarize, there are primarily three things that Devil does
-differently:
-
- - Provide a modeless editing experience from the outset.
- - Seamlessly extend the same editing experience to minibuffer,
- incremental search, etc.
- - Translate key sequences using string replacements. This allows for
- arbitrary and sophisticated key translations for the adventurous.
- - Choose non-sticky behaviour for the modifier keys.
-
-These differences could make Devil easier to use than God mode for
-some people but clumsy for other people. It depends on one's tastes
-and preferences.
-
-
-Support
--------
-
-To report bugs, suggest improvements, or ask questions,
-[create issues][ISSUES].
-
-[ISSUES]: https://github.com/susam/devil/issues
-
+Read the [manual](./MANUAL.org) for more details on how to use Devil.
Channels
--------
--
2.39.2
[-- Attachment #10: Type: text/plain, Size: 80 bytes --]
I'll add the package to NonGNU ELPA in a day, unless there are any objections?
^ permalink raw reply related [relevance 5%]
* Re: [NonGNU ELPA] New package: devil
@ 2023-05-09 8:58 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-05-09 8:58 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: susam.pal, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: emacs-devel@gnu.org
>> Date: Tue, 09 May 2023 08:42:20 +0000
>>
>> > Hello!
>> >
>> > I am the author and maintainer of a new package named Devil. This package
>> > intercepts keystrokes entered by the user and applies translation rules to
>> > translate the keystrokes into Emacs key sequences. It supports three types
>> > of rules: special keys that map to custom commands that are invoked
>> > immediately prior to any translations, translation rules to translate Devil
>> > key sequences to regular Emacs key sequences, and repeatable keys to allow
>> > a Devil key sequence to be repeated by typing the last keystroke over and
>> > over again using a transient map.
>> >
>> > See the README at https://github.com/susam/devil for more details.
>>
>> Looks interesting, here is a diff with a few comments:
>
> Why call this package by such a strange name? It says nothing at all
> about the package's purpose. Would it be possible to rename it,
> please?
I am guessing that this is a pun on "evil-mode", but I am inclined to
agree. At least "evil" stands for "extensible vi layer for Emacs".
> Thanks.
^ permalink raw reply [relevance 99%]
* Re: [ELPA] New package: pdf-view-pagemark
@ 2023-05-09 8:46 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-05-09 8:46 UTC (permalink / raw)
To: Jijun Ma; +Cc: emacs-devel@gnu.org
Jijun Ma <jijun.ma@hotmail.com> writes:
> Hello Philip
>
> It is a new package. Could you put it to GNU elpa? Thanks.
i got that, I am just asking if it wouldn't be better to contribute your
code upstream? I don't use pdf-tools, so I don't know if there is a
reason that all users wouldn't be interested in this code.
Otherwise, we can do so. Have you signed the FSF CA?
> Holen Sie sich Outlook für iOS<https://aka.ms/o0ukef>
> ________________________________
> Von: Philip Kaludercic <philipk@posteo.net>
> Gesendet: Tuesday, May 9, 2023 4:23:40 AM
> An: Jijun Ma <jijun.ma@hotmail.com>
> Cc: emacs-devel@gnu.org <emacs-devel@gnu.org>
> Betreff: Re: [ELPA] New package: pdf-view-pagemark
>
> Jijun Ma <jijun.ma@hotmail.com> writes:
>
>> Hello,
>>
>> Because pdf-tools cannot scroll continuously between two pages. The remaining of a page will be partial.
>> pdf-view-pagemark is used together with pdf-tools to indicate the remaining of a partial page.
>
> Are you proposing this for GNU ELPA or NonGNU ELPA? Also, have
> attempted to merge this into the actual package, before creating a
> separate package?
>
>> URL of the package: https://github.com/kimim/pdf-view-pagemark
>>
>> Thanks.
^ permalink raw reply [relevance 99%]
* Re: [GNU ELPA] New package: Urgrep
@ 2023-05-09 8:45 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-05-09 8:45 UTC (permalink / raw)
To: Jim Porter; +Cc: emacs-devel
Jim Porter <jporterbugs@gmail.com> writes:
> I'd like to add a new package to GNU ELPA: Urgrep[1]. I posted about
> it a while ago[2], but wasn't quite ready to submit it to GNU ELPA at
> the time. Well, now is that time! I'll quote my original message for a
> summary of what it's interesting about Urgrep:
>
>> A brief summary: Urgrep is designed to provide a universal interface on
>> top of all "recursive grep"-like commands, from ripgrep to git grep to
>> the classic find+grep. I made it to solve a frustration I had with other
>> similar packages: they're primarily built to support a *particular*
>> searching tool, and while some can be coaxed into running with other
>> tools, it doesn't always work. Even when it does, it's usually not
>> seamless, especially when you add Tramp to the equation.
>>
>> With Urgrep, you can use *any* rgrep-like command. It will
>> automatically use the best tool on the system in question, so if some
>> remote host doesn't have your favorite tool, it'll still work just fine.
>>
>> I also added some Isearch-like bindings in the main function's prompt
>> (creatively named 'urgrep'). These all start with M-s and let you set
>> common search flags, like number of context lines. Maybe there's a
>> better way to do this; the current method seemed reasonable to me, but
>> I'm certainly open to suggestions.
Looks interesting!
> [1] https://github.com/jimporter/urgrep
> [2] https://lists.gnu.org/archive/html/emacs-devel/2022-09/msg00723.html
>
> From 9745926ef47fe52f0c94287c992637e00e849b38 Mon Sep 17 00:00:00 2001
> From: Jim Porter <jporterbugs@gmail.com>
> Date: Mon, 8 May 2023 22:07:56 -0700
> Subject: [PATCH] * elpa-packages (urgrep): New package
>
> ---
> elpa-packages | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/elpa-packages b/elpa-packages
> index 93f6ccc..93e6e46 100644
> --- a/elpa-packages
> +++ b/elpa-packages
> @@ -696,6 +696,9 @@
> (uni-confusables :url nil
> :readme "README.md")
> (uniquify-files :url nil)
> + (urgrep :url "https://github.com/jimporter/urgrep"
> + :readme "README.md"
> + :ignored-files (".github" "LICENSE" "Makefile" "*-tests.el"))
Could you track these files in a .elpaignore file within the repository?
> (url-http-ntlm :url nil)
> (url-http-oauth :url "https://git.sr.ht/~fitzsim/url-http-oauth"
> :readme ignore)
^ permalink raw reply [relevance 99%]
* Re: [NonGNU ELPA] New package: devil
@ 2023-05-09 8:42 23% ` Philip Kaludercic
0 siblings, 2 replies; 200+ results
From: Philip Kaludercic @ 2023-05-09 8:42 UTC (permalink / raw)
To: Susam Pal; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 747 bytes --]
Susam Pal <susam.pal@gmail.com> writes:
> Hello!
>
> I am the author and maintainer of a new package named Devil. This package
> intercepts keystrokes entered by the user and applies translation rules to
> translate the keystrokes into Emacs key sequences. It supports three types
> of rules: special keys that map to custom commands that are invoked
> immediately prior to any translations, translation rules to translate Devil
> key sequences to regular Emacs key sequences, and repeatable keys to allow
> a Devil key sequence to be repeated by typing the last keystroke over and
> over again using a transient map.
>
> See the README at https://github.com/susam/devil for more details.
Looks interesting, here is a diff with a few comments:
[-- Attachment #2: Type: text/plain, Size: 14413 bytes --]
diff -u /home/philip/devil.el.1 /home/philip/devil.el
--- /home/philip/devil.el.1 2023-05-09 10:37:55.243222106 +0200
+++ /home/philip/devil.el 2023-05-09 10:39:50.110922443 +0200
@@ -36,34 +36,42 @@
;; key sequences without using modifier keys.
;;; Code:
+
+(defgroup devil '()
+ "Minor mode for Devil-like command entering." ;is there a clearer description?
+ :prefix "devil-"
+ :group 'editing)
+
(defconst devil-version "0.2.0"
"Devil version number.")
-(defun devil-show-version ()
+(defun devil-show-version () ;is this really needed?
"Show Devil version number in the echo area."
(interactive)
(message "Devil %s" devil-version))
-(defvar devil-key ","
+(defcustom devil-key ","
"The key sequence that begins Devil input.
The key sequence must be specified in the format returned by `C-h
-k' (`describe-key'). This variable should be set before enabling
-Devil mode for it to take effect.")
-
-(defvar devil-lighter " Devil"
- "String displayed on the mode line when Devil mode is enabled.")
+k' (`describe-key'). This variable should be set before enabling
+Devil mode for it to take effect."
+ :type 'key-sequence)
+
+(defcustom devil-lighter " Devil"
+ "String displayed on the mode line when Devil mode is enabled."
+ :type 'string)
(defvar devil-mode-map
(let ((map (make-sparse-keymap)))
- (define-key map (kbd devil-key) #'devil)
+ (define-key map devil-key #'devil)
map)
"Keymap to wake up Devil when `devil-key' is typed.
By default, only `devil-key' is added to this keymap so that
-Devil can be activated using it. To support multiple activation
+Devil can be activated using it. To support multiple activation
keys, this variable may be modified to a new keymap that defines
-multiple different keys to activate Devil. This variable should
+multiple different keys to activate Devil. This variable should
be modified before loading Devil for it to take effect.")
;;;###autoload
@@ -74,15 +82,16 @@
;;;###autoload
(define-globalized-minor-mode
- global-devil-mode devil-mode devil--on :group 'devil
+ global-devil-mode devil-mode devil--on ;; :group 'devil (not needed with the defgroup above)
(if global-devil-mode (devil-add-extra-keys) (devil-remove-extra-keys)))
(defun devil--on ()
"Turn Devil mode on."
(devil-mode 1))
-(defvar devil-logging nil
- "Non-nil if and only if Devil should print log messages.")
+(defcustom devil-logging nil
+ "Non-nil if and only if Devil should print log messages."
+ :type 'boolean)
(defvar devil-special-keys
(list (cons "%k %k" (lambda () (interactive) (devil-run-key "%k")))
@@ -91,12 +100,12 @@
"Special Devil keys that are executed as soon as they are typed.
The value of this variable is an alist where each key represents
-a Devil key sequence. If a Devil key sequence matches any key in
+a Devil key sequence. If a Devil key sequence matches any key in
this alist, the function or lambda in the corresponding value is
-invoked. The format control specifier `%k' may be used to
+invoked. The format control specifier `%k' may be used to
represent `devil-key' in the keys.")
-(defvar devil-translations
+(defcustom devil-translations
(list (cons "%k z" "C-")
(cons "%k %k" "%k")
(cons "%k m m" "M-")
@@ -108,12 +117,13 @@
a translation rule that is applied on the Devil key sequence read
from the user to obtain the Emacs key sequence to be executed.
The translation rules are applied in the sequence they occur in
-the alist. For each rule, if the key occurs anywhere in the Devil
+the alist. For each rule, if the key occurs anywhere in the Devil
key sequence, it is replaced with the corresponding value in the
-translation rule. The format control specifier `%k' may be used
-to represent `devil-key' in the keys.")
+translation rule. The format control specifier `%k' may be used
+to represent `devil-key' in the keys."
+ :type '(alist :key-type string :value-type string))
-(defvar devil-repeatable-keys
+(defcustom devil-repeatable-keys
(list "%k p"
"%k n"
"%k f"
@@ -128,8 +138,9 @@
The value of this variable is a list where each item represents a
key sequence that may be repeated merely by typing the last
-character in the key sequence. The format control specified `%k'
-may be used to represent `devil-key' in the keys.")
+character in the key sequence. The format control specified `%k'
+may be used to represent `devil-key' in the keys."
+ :type '(repeat string))
(defun devil-run-key (key)
"Execute the given key sequence KEY.
@@ -140,7 +151,7 @@
(dolist (key (split-string key))
(if (string= key "%k") (insert devil-key) (execute-kbd-macro (kbd key)))))
-(defvar devil--saved-keys
+(defvar devil--saved-keys nil ;otherwise `devil--saved-keys' is assigned a string
"Original key bindings saved by Devil.")
(defun devil-add-extra-keys ()
@@ -160,8 +171,9 @@
(defun devil--original-keys-to-be-saved ()
"Return an alist of keys that will be modified by Devil."
- (list (cons 'isearch-comma (lookup-key isearch-mode-map (kbd devil-key)))
- (cons 'universal-u (lookup-key universal-argument-map (kbd "u")))))
+ ;; Weak suggestions
+ `((isearch-comma . ,(lookup-key isearch-mode-map (kbd devil-key)))
+ universal-u . ,(lookup-key universal-argument-map (kbd "u"))))
(defun devil ()
"Wake up Devil to read and translate Devil key sequences."
@@ -178,27 +190,30 @@
after translation to Emacs key sequence.
The argument KEY is a vector that represents the key sequence
-read so far. This function reads a new key from the user, appends
+read so far. This function reads a new key from the user, appends
it to KEY, and then checks if the result is a valid key sequence
-or an undefined key sequence. If the result is a valid key
+or an undefined key sequence. If the result is a valid key
sequence for a special key command or an Emacs command, then the
-command is executed. Otherwise, this function calls itself
+command is executed. Otherwise, this function calls itself
recursively to read yet another key from the user."
(setq key (vconcat key (vector (read-key (devil--make-prompt key)))))
(unless (devil--run-command key)
(devil--read-key key)))
-(defvar devil-prompt "Devil: %t"
+(defcustom devil-prompt "Devil: %t"
"A format control string that determines the Devil prompt.
The following format control sequences are supported:
%k - Devil key sequence read by Devil so far.
%t - Emacs key sequence translated from Devil key sequence read so far.
-%% - The percent sign.")
+%% - The percent sign."
+ :type 'string)
(defun devil--make-prompt (key)
"Create Devil prompt based on the given KEY."
+ ;; If you are interested in adding Compat as a dependency, you can
+ ;; make use of `format-spec' without raining the minimum version.
(let ((result devil-prompt)
(controls (list (cons "%k" (key-description key))
(cons "%t" (devil-translate key))
@@ -210,16 +225,16 @@
(defun devil--run-command (key)
"Try running the command bound to the key sequence in KEY.
-KEY is a vector that represents a sequence of keystrokes. If KEY
+KEY is a vector that represents a sequence of keystrokes. If KEY
is found to be a special key in `devil-special-keys', the
corresponding special command is executed immediately and t is
returned.
Otherwise, it is translated to an Emacs key sequence using
-`devil-translations'. If the resulting Emacs key sequence is
+`devil-translations'. If the resulting Emacs key sequence is
found to be a complete key sequence, the command it is bound to
-is executed interactively and t is returned. If it is found to be
-an undefined key sequence, then t is returned. If the resulting
+is executed interactively and t is returned. If it is found to be
+an undefined key sequence, then t is returned. If the resulting
Emacs key sequence is found to be an incomplete key sequence,
then nil is returned."
(devil--log "Trying to execute key: %s" (key-description key))
@@ -231,7 +246,7 @@
If the given key sequence KEY is found to be a special key in
`devil-special-keys', the corresponding special command is
-executed, and t is returned. Otherwise nil is returned."
+executed, and t is returned. Otherwise nil is returned."
(catch 'break
(dolist (entry devil-special-keys)
(when (string= (key-description key) (devil-format (car entry)))
@@ -245,14 +260,14 @@
After translating KEY to an Emacs key sequence, if the resulting
key sequence turns out to be an incomplete key, then nil is
-returned. If it turns out to be a complete key sequence, the
-corresponding Emacs command is executed, and t is returned. If it
-turns out to be an undefined key sequence, t is returned. The
+returned. If it turns out to be a complete key sequence, the
+corresponding Emacs command is executed, and t is returned. If it
+turns out to be an undefined key sequence, t is returned. The
return value t indicates to the caller that no more Devil key
sequences should be read from the user."
(let* ((described-key (key-description key))
(translated-key (devil-translate key))
- (parsed-key (condition-case nil (kbd translated-key) (error nil)))
+ (parsed-key (condition-case nil (kbd translated-key) (error nil))) ;or `ignore-errors'
(binding (when parsed-key (key-binding parsed-key))))
(cond ((string-match "[ACHMSs]-$" translated-key)
(devil--log "Ignoring incomplete key: %s => %s"
@@ -307,27 +322,27 @@
"Update variables that maintain command loop information.
The given KEY and BINDING is used to update variables that
-maintain command loop information. This allows the commands that
+maintain command loop information. This allows the commands that
depend on them behave as if they were being invoked directly with
the original Emacs key sequence."
;;
;; Set `last-command-event' so that `digit-argument' can determine
- ;; the correct digit for key sequences like , 5 (C-5). See M-x
+ ;; the correct digit for key sequences like , 5 (C-5). See M-x
;; find-function RET digit-argument RET for details.
(setq last-command-event (aref key (- (length key) 1)))
;;
;; Set `this-command' to make several commands like , z SPC , z SPC
- ;; (C-SPC C-SPC) and , p (C-p) work correctly. Emacs copies
- ;; `this-command' to `last-command'. Both variables are used by
+ ;; (C-SPC C-SPC) and , p (C-p) work correctly. Emacs copies
+ ;; `this-command' to `last-command'. Both variables are used by
;; `set-mark-command' to decide whether to activate/deactivate the
- ;; current mark. The first variable is used by vertical motion
- ;; commands to keep the cursor at the `temporary-goal-column'. There
+ ;; current mark. The first variable is used by vertical motion
+ ;; commands to keep the cursor at the `temporary-goal-column'. There
;; may be other commands too that depend on this variable.
(setq this-command binding)
;;
;; Set `real-this-command' to make , x z (C-x z) work correctly.
;; Emacs copies it to `last-repeatable-command' which is then used
- ;; by repeat. See the following for more details:
+ ;; by repeat. See the following for more details:
;;
;; - M-x find-function RET repeat RET
;; - C-h v last-repeatable-command RET
@@ -337,11 +352,12 @@
(defun devil--log-command-loop-info ()
"Log command loop information for debugging purpose."
(devil--log
- (concat "Found "
- (format "current-prefix-arg: %s; " current-prefix-arg)
- (format "this-command: %s; " this-command)
- (format "last-command: %s; " last-command)
- (format "last-repeatable-command: %s" last-repeatable-command))))
+ (format "Found current-prefix-arg: %s; \
+this-command: %s; last-command: %s; last-repeatable-command: %s"
+ current-prefix-arg
+ this-command
+ last-command
+ last-repeatable-command)))
(defun devil--repeatable-key-p (described-key)
"Return t iff DESCRIBED-KEY belongs to `devil-repeatable-keys'."
@@ -379,28 +395,25 @@
(when devil-logging
(apply #'message (concat "Devil: " format-string) args)))
-(defmacro devil--assert (form)
- "Evaluate FORM and cause error if the result is nil."
- `(unless ,form
- (error "Assertion failed: %s" ',form)))
-
-(defun devil--tests ()
- "Test Devil functions assuming Devil has not been customized."
- (devil--assert (devil--invalid-key-p ""))
- (devil--assert (devil--invalid-key-p "C-x-C-f"))
- (devil--assert (devil--invalid-key-p "C-x CC-f"))
- (devil--assert (not (devil--invalid-key-p "C-x C-f")))
- (devil--assert (not (devil--invalid-key-p "C-M-x")))
- (devil--assert (string= (devil-translate (vconcat ",")) "C-"))
- (devil--assert (string= (devil-translate (vconcat ",x")) "C-x"))
- (devil--assert (string= (devil-translate (vconcat ",x,")) "C-x C-"))
- (devil--assert (string= (devil-translate (vconcat ",x,f")) "C-x C-f"))
- (devil--assert (string= (devil-translate (vconcat ",,")) ","))
- (devil--assert (string= (devil-translate (vconcat ",,,,")) ", ,"))
- (devil--assert (string= (devil-translate (vconcat ",mx")) "C-M-x"))
- (devil--assert (string= (devil-translate (vconcat ",mmx")) "M-x"))
- (devil--assert (string= (devil-translate (vconcat ",mmm")) "M-m"))
- (message "Done"))
+(ert-deftest devil-invalid-key-p ()
+ "Test if `devil--invalid-key-p' words as expected."
+ (should (devil--invalid-key-p ""))
+ (should (devil--invalid-key-p "C-x-C-f"))
+ (should (devil--invalid-key-p "C-x CC-f"))
+ (should (not (devil--invalid-key-p "C-x C-f")))
+ (should (not (devil--invalid-key-p "C-M-x"))))
+
+(ert-deftest devil-translate ()
+ "Test if `devil-translate' works as expected."
+ (should (string= (devil-translate (vconcat ",")) "C-"))
+ (should (string= (devil-translate (vconcat ",x")) "C-x"))
+ (should (string= (devil-translate (vconcat ",x,")) "C-x C-"))
+ (should (string= (devil-translate (vconcat ",x,f")) "C-x C-f"))
+ (should (string= (devil-translate (vconcat ",,")) ","))
+ (should (string= (devil-translate (vconcat ",,,,")) ", ,"))
+ (should (string= (devil-translate (vconcat ",mx")) "C-M-x"))
+ (should (string= (devil-translate (vconcat ",mmx")) "M-x"))
+ (should (string= (devil-translate (vconcat ",mmm")) "M-m")))
(provide 'devil)
Diff finished. Tue May 9 10:39:57 2023
[-- Attachment #3: Type: text/plain, Size: 1285 bytes --]
> Also, see https://www.reddit.com/r/emacs/comments/13aj99j/ for some
> discussion on this new package.
>
> Please let me know if this package can be added to NonGNU ELPA. If there
> are any questions or feedback about this, please let me know.
I see no reason why not. Thanks for contributing.
One point I have already mentioned on IRC is that a separate manual and
a shorter README would be nice. We can generate a TeXinfo manual from
either .texi or .org files, would you be interested in setting that up?
> Regards,
> Susam
> From 3499d93502b130b1dcb8a648e73e7a614cd24abd Mon Sep 17 00:00:00 2001
> From: Susam Pal <susam@susam.net>
> Date: Tue, 9 May 2023 02:36:08 +0100
> Subject: [PATCH] * elpa-packages (devil): New package
>
> ---
> elpa-packages | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/elpa-packages b/elpa-packages
> index c333cc8bb3..f6fd68edaf 100644
> --- a/elpa-packages
> +++ b/elpa-packages
> @@ -112,6 +112,8 @@
>
> (devhelp :url "https://codeberg.org/akib/emacs-devhelp")
>
> + (devil :url "https://github.com/susam/devil")
As you have a CHANGES.md file, we can add a :news entry here as well.
> +
> (diff-ansi :url "https://codeberg.org/ideasman42/emacs-diff-ansi"
> :ignored-files ("LICENSE"))
^ permalink raw reply [relevance 23%]
* Re: [ELPA] New package: pdf-view-pagemark
@ 2023-05-08 20:23 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-05-08 20:23 UTC (permalink / raw)
To: Jijun Ma; +Cc: emacs-devel@gnu.org
Jijun Ma <jijun.ma@hotmail.com> writes:
> Hello,
>
> Because pdf-tools cannot scroll continuously between two pages. The remaining of a page will be partial.
> pdf-view-pagemark is used together with pdf-tools to indicate the remaining of a partial page.
Are you proposing this for GNU ELPA or NonGNU ELPA? Also, have
attempted to merge this into the actual package, before creating a
separate package?
> URL of the package: https://github.com/kimim/pdf-view-pagemark
>
> Thanks.
^ permalink raw reply [relevance 99%]
* Re: emacs-29 9b775ddc057 1/2: ; * etc/EGLOT-NEWS: Fix wording of last change.
@ 2023-05-08 13:34 93% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-05-08 13:34 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: dmitry, monnier, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: dmitry@gutov.dev, monnier@iro.umontreal.ca, emacs-devel@gnu.org
>> Date: Sun, 07 May 2023 19:44:01 +0000
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> >> From: Philip Kaludercic <philipk@posteo.net>
>> >> Cc: dmitry@gutov.dev, monnier@iro.umontreal.ca, emacs-devel@gnu.org
>> >> Date: Sun, 07 May 2023 19:24:26 +0000
>> >>
>> >> Eli Zaretskii <eliz@gnu.org> writes:
>> >>
>> >> >> but on my system, it immediately suggests upgrading 24 packages, which
>> >> >> is a lot.
>> >> >
>> >> > Can you show the list of those 24 packages?
>> >>
>> >> I am on a different system now, so the prompt differs slightly and have
>> >> other updates, but this is what it looks like:
>> >>
>> >> Packages to install: 23 (xref-1.6.3
>> >> verilog-mode-2022.12.18.181110314 use-package-2.4.5 tramp-2.6.0.4
>> >> svg-1.1 soap-client-3.2.1 so-long-1.1.2 python-0.28 project-0.9.8
>> >> org-9.6.5 ntlm-2.1.0 nadvice-0.4 map-3.3.1 let-alist-1.0.6
>> >> jsonrpc-1.0.17 flymake-1.3.4 external-completion-0.1 erc-5.5
>> >> eldoc-1.14.0 eglot-1.15 cl-lib-0.7.1 cl-generic-0.3 bind-key-2.4.1).
>> >> Packages to upgrade: 2 (editorconfig-0.9.1 inspector-0.29).
>> >> Proceed? (y or n)
>> >
>> > I see nothing unexpected in this list. And since the feature is
>> > opt-in, what are the dangers of having it?
>>
>> There is no danger, it might just be overwhelming? I was a bit
>> surprised at first. But if you think it is fine, then I have no
>> objections.
>
> One more question: the patch you proposed affects both "U" and "/ u",
> right?
Yes it does, since both of these functions use
`package-menu--find-upgrades'. In the future, we should probably
centralise the upgrade logic in a single function, like
`package--upgradeable-packages'.
Eli Zaretskii <eliz@gnu.org> writes:
>> Date: Sun, 7 May 2023 23:36:24 +0300
>> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
>> From: Dmitry Gutov <dmitry@gutov.dev>
>>
>> On 07/05/2023 22:32, Eli Zaretskii wrote:
>> > Packages to install: 23 (xref-1.6.3
>> > verilog-mode-2022.12.18.181110314 use-package-2.4.5 tramp-2.6.0.4
>> > svg-1.1 soap-client-3.2.1 so-long-1.1.2 python-0.28 project-0.9.8
>> > org-9.6.5 ntlm-2.1.0 nadvice-0.4 map-3.3.1 let-alist-1.0.6
>> > jsonrpc-1.0.17 flymake-1.3.4 external-completion-0.1 erc-5.5
>> > eldoc-1.14.0 eglot-1.15 cl-lib-0.7.1 cl-generic-0.3
>> > bind-key-2.4.1). Packages to upgrade: 2 (editorconfig-0.9.1
>> > inspector-0.29). Proceed? (y or n)
>>
>> At least nadvice, cl-lib and cl-generic seem to be the odd ones (the
>> built-in versions are higher, and the ELPA packages are supposed to be
>> used as shims or backward compatibility wrappers). That looks like a bug.
I think you are right, I can extend my previous patch by a version check.
> Yes, I think it's an unrelated bug. We had already reports about
> strange status values, and there's a new bug#63064 today about similar
> problems. We should try to fix this for Emacs 29, I think.
>
>> Regarding potential downsides in general:
>>
>> - We simply increase the odds of breakage when a built-in package is
>> upgraded because it will reach more people, across different Emacs
>> versions. There is good and bad in that (features will reach them faster
>> too), but it's something to consider.
>>
>> - I very rarely use Tramp or Org. I don't use ERC or bind-key. Or
>> so-long, python, ntlm, use-package, verilog-mode. Unlike other installed
>> packages (which I have hand-picked), these packages are here just by the
>> virtue of being included in Emacs, but flipping the pref will also cause
>> them to be upgraded (downloaded, take time unarchiving, take up space)
>> every time there is a new version out. It's nothing dangerous
>> (probably), but seems unfortunate anyway.
>
> AFAIU, the "U" command is not for everyone. There are alternatives
> which allow selective upgrades, and users who don't want "surprises",
> or want the upgrade to take as little time and disk space as possible,
> should use those alternatives instead of "U". I'll try to make that
> clear in the documentation.
I think that U is pretty standard, but yes, those who cannot use it are
free to select the packages they wish to upgrade manually (that being
said, Emacs was never known for being popular among people who are
struggling for every kilobyte of disk space).
^ permalink raw reply [relevance 93%]
* Re: [GNU ELPA] New package: url-http-oauth
@ 2023-05-08 10:30 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-05-08 10:30 UTC (permalink / raw)
To: João Távora; +Cc: Thomas Fitzsimmons, emacs-devel
João Távora <joaotavora@gmail.com> writes:
> I think packages such as this one are very welcome, and I appreciate the
> UI-agnostic architecture you describe.
>
> Url.el itself, last i looked, seemed a bit outdated and hard to work with.
> Are there other http client libraries for Emacs? Could they also take
> advantage of your new library?
Adam Porter recently wrote a library called "plz" which was added to GNU
ELPA: http://elpa.gnu.org/packages/plz.html
> João
>
> On Sat, May 6, 2023, 06:07 Thomas Fitzsimmons <fitzsim@fitzsim.org> wrote:
>
>> Hi,
>>
>> I would like to add one or two new packages to GNU ELPA.
>>
>> The main one is url-http-oauth, which adds OAuth 2.0 support to the URL
>> library, via "url-auth" hooks, like url-http-basic, url-http-digest and
>> url-http-ntlm. It provides auth-source integration for secrets, using
>> the netrc backend.
>>
>> https://git.sr.ht/~fitzsim/url-http-oauth
>>
>> This package is unrelated to oauth2.el in GNU ELPA, which provides new
>> oauth2-url-retrieve and oauth2-url-retrieve-synchronously functions, and
>> has plstore instead of auth-source integration. For Excorporate, I
>> needed something that would work with the built-in url-retrieve
>> functions and I couldn't see how to do that with oauth2.el. I haven't
>> tested, but I see no reason that the two packages would interfere with
>> one another.
>>
>> For the next release of Excorporate I want to depend on url-http-oauth
>> to fix the longstanding bug#50113, "Excorporate: Communicating with
>> domain that requires SSO?". I have the changes ready; I am using them
>> daily.
>>
>> The OAuth 2.0 standard encodes the use of a user-agent (i.e., web
>> browser) for authorization steps which differ per OAuth 2.0 provider,
>> and are not defined by the specification. I have provided support for
>> package authors and users to write custom functions to automate these
>> web browser interactions in arbitrary ways:
>>
>> AUTHORIZATION-CODE-FUNCTION is an elisp function that takes an
>> authorization URL as a string argument, and returns, as a string, a
>> full URL containing a code value in its query string.
>>
>> By default though, url-http-oauth will prompt the user to copy-n-paste
>> URLs to and from the web browser. This is the most general default I
>> could think of; for example, this allows performing authorization in a
>> local web browser then pasting the result to an Emacs session running
>> three SSH hops away, where `browse-url' may not do the right thing.
>>
>> Users and package authors can design automatic user-agent interactions,
>> but those ways are so varied that I wanted to see how they would evolve.
>> For example, I would like to see someone write an
>> authorization-code-function for Sourcehut that would use EWW inline.
>> For other OAuth 2.0 providers whose authorization steps require
>> JavaScript, EWW would not work.
>>
>> I have published another, tiny package:
>>
>> https://git.sr.ht/~fitzsim/url-http-oauth-demo
>>
>> It demonstrates the use of url-http-oauth against the Emacs-friendliest
>> OAuth 2.0 implementation I've found: Sourcehut. Sourcehut's
>> implementation is entirely Free Software, and it does not require
>> JavaScript in the authorization steps. Its client registration process
>> does not have onerous terms of use. Any Sourcehut user should be able
>> to get url-http-oauth-demo working. Maybe this package makes sense in
>> GNU ELPA, or perhaps it could be part of url-http-oauth's documentation.
>>
>> I wrote these packages myself [1] and I have copyright assignment
>> paperwork on file.
>>
>> Thomas
>>
>> 1. Except url-http-oauth--netrc-delete, which borrows lots of code from
>> auth-source.el.
>>
>>
^ permalink raw reply [relevance 99%]
* Re: emacs-29 9b775ddc057 1/2: ; * etc/EGLOT-NEWS: Fix wording of last change.
@ 2023-05-07 19:44 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-05-07 19:44 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: dmitry, monnier, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: dmitry@gutov.dev, monnier@iro.umontreal.ca, emacs-devel@gnu.org
>> Date: Sun, 07 May 2023 19:24:26 +0000
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> >> but on my system, it immediately suggests upgrading 24 packages, which
>> >> is a lot.
>> >
>> > Can you show the list of those 24 packages?
>>
>> I am on a different system now, so the prompt differs slightly and have
>> other updates, but this is what it looks like:
>>
>> Packages to install: 23 (xref-1.6.3
>> verilog-mode-2022.12.18.181110314 use-package-2.4.5 tramp-2.6.0.4
>> svg-1.1 soap-client-3.2.1 so-long-1.1.2 python-0.28 project-0.9.8
>> org-9.6.5 ntlm-2.1.0 nadvice-0.4 map-3.3.1 let-alist-1.0.6
>> jsonrpc-1.0.17 flymake-1.3.4 external-completion-0.1 erc-5.5
>> eldoc-1.14.0 eglot-1.15 cl-lib-0.7.1 cl-generic-0.3 bind-key-2.4.1).
>> Packages to upgrade: 2 (editorconfig-0.9.1 inspector-0.29).
>> Proceed? (y or n)
>
> I see nothing unexpected in this list. And since the feature is
> opt-in, what are the dangers of having it?
There is no danger, it might just be overwhelming? I was a bit
surprised at first. But if you think it is fine, then I have no
objections.
^ permalink raw reply [relevance 99%]
* Re: emacs-29 9b775ddc057 1/2: ; * etc/EGLOT-NEWS: Fix wording of last change.
@ 2023-05-07 19:24 92% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-05-07 19:24 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: dmitry, monnier, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: dmitry@gutov.dev, monnier@iro.umontreal.ca, emacs-devel@gnu.org
>> Date: Sun, 07 May 2023 17:16:31 +0000
>>
>> > I'd appreciate if you could show a patch that we could then consider.
>> > TIA.
>>
>> This is an initial, quick sketch:
>
> LGTM.
>
>> but on my system, it immediately suggests upgrading 24 packages, which
>> is a lot.
>
> Can you show the list of those 24 packages?
I am on a different system now, so the prompt differs slightly and have
other updates, but this is what it looks like:
Packages to install: 23 (xref-1.6.3 verilog-mode-2022.12.18.181110314 use-package-2.4.5 tramp-2.6.0.4 svg-1.1 soap-client-3.2.1 so-long-1.1.2 python-0.28 project-0.9.8 org-9.6.5 ntlm-2.1.0 nadvice-0.4 map-3.3.1 let-alist-1.0.6 jsonrpc-1.0.17 flymake-1.3.4 external-completion-0.1 erc-5.5 eldoc-1.14.0 eglot-1.15 cl-lib-0.7.1 cl-generic-0.3 bind-key-2.4.1). Packages to upgrade: 2 (editorconfig-0.9.1 inspector-0.29). Proceed? (y or n)
M-x emacs-version
GNU Emacs 29.0.90 (build 3, x86_64-pc-linux-gnu, GTK+ Version 3.24.37, cairo version 1.16.0) of 2023-05-04
^ permalink raw reply [relevance 92%]
* Re: emacs-29 9b775ddc057 1/2: ; * etc/EGLOT-NEWS: Fix wording of last change.
@ 2023-05-07 17:16 83% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-05-07 17:16 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: dmitry, monnier, emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1706 bytes --]
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: Dmitry Gutov <dmitry@gutov.dev>, monnier@iro.umontreal.ca,
>> emacs-devel@gnu.org
>> Date: Sun, 07 May 2023 08:46:53 +0000
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> > I think it better did, because using "U" would upgrade Eglot and
>> > use-package in Emacs 28 and before. So we should give users who want
>> > that the capability of keeping that workflow in Emacs 29, if only as
>> > opt-in behavior.
>>
>> "Workflow" is really to high of a term for the problem being discussed
>> here. Installing packages is not a periodical thing people to on a
>> regular basis.
>
> Since we are talking about an optional feature, it will suit this
> well, I think. The target audience for this are those users who were
> used to upgrade Eglot regularly when it was not a core package.
> Likewise for other packages that would be brought into core in the
> future.
>
>> > Also, "/ u" should ideally show built-in packages as well, when
>> > package-install-upgrade-built-in is non-nil.
>>
>> So the point here would be that a user who enables this option, regards
>> any newer version of a core-package on ELPA as something that should be
>> installed?
>
> Yes.
>
>> Perhaps this is a tangent, but what would happen if a third-party
>> repository like MELPA adds a package with the same name as a core
>> package?
>
> This problem exists today already, with non-core packages. Right?
>
>> > Philip, can these two changes be implemented safely for Emacs 29?
>>
>> It certainly can be done.
>
> I'd appreciate if you could show a patch that we could then consider.
> TIA.
This is an initial, quick sketch:
[-- Attachment #2: Type: text/plain, Size: 1498 bytes --]
diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el
index 2892728ebd9..4c85db1aedb 100644
--- a/lisp/emacs-lisp/package.el
+++ b/lisp/emacs-lisp/package.el
@@ -3740,7 +3740,9 @@ package-menu--find-upgrades
;; ENTRY is (PKG-DESC [NAME VERSION STATUS DOC])
(let ((pkg-desc (car entry))
(status (aref (cadr entry) 2)))
- (cond ((member status '("installed" "dependency" "unsigned" "external"))
+ (cond ((member status (append
+ '("installed" "dependency" "unsigned" "external")
+ (and package-install-upgrade-built-in '("built-in"))))
(push pkg-desc installed))
((member status '("available" "new"))
(setq available (package--append-to-alist pkg-desc available))))))
@@ -3749,8 +3751,10 @@ package-menu--find-upgrades
(let* ((name (package-desc-name pkg-desc))
(avail-pkg (cadr (assq name available))))
(and avail-pkg
- (version-list-< (package-desc-priority-version pkg-desc)
- (package-desc-priority-version avail-pkg))
+ (or (version-list-< (package-desc-priority-version pkg-desc)
+ (package-desc-priority-version avail-pkg))
+ (and package-install-upgrade-built-in
+ (package--active-built-in-p pkg-desc)))
(push (cons name avail-pkg) upgrades))))
upgrades))
[-- Attachment #3: Type: text/plain, Size: 105 bytes --]
but on my system, it immediately suggests upgrading 24 packages, which
is a lot.
--
Philip Kaludercic
^ permalink raw reply related [relevance 83%]
* Re: [GNU ELPA] New package: url-http-oauth
@ 2023-05-07 15:55 99% ` Philip Kaludercic
1 sibling, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-05-07 15:55 UTC (permalink / raw)
To: Thomas Fitzsimmons; +Cc: emacs-devel
Thomas Fitzsimmons <fitzsim@fitzsim.org> writes:
> Hi,
>
> I would like to add one or two new packages to GNU ELPA.
I have no objections to this, but I don't have any comments either.
> The main one is url-http-oauth, which adds OAuth 2.0 support to the URL
> library, via "url-auth" hooks, like url-http-basic, url-http-digest and
> url-http-ntlm. It provides auth-source integration for secrets, using
> the netrc backend.
>
> https://git.sr.ht/~fitzsim/url-http-oauth
>
> This package is unrelated to oauth2.el in GNU ELPA, which provides new
> oauth2-url-retrieve and oauth2-url-retrieve-synchronously functions, and
> has plstore instead of auth-source integration. For Excorporate, I
> needed something that would work with the built-in url-retrieve
> functions and I couldn't see how to do that with oauth2.el. I haven't
> tested, but I see no reason that the two packages would interfere with
> one another.
>
> For the next release of Excorporate I want to depend on url-http-oauth
> to fix the longstanding bug#50113, "Excorporate: Communicating with
> domain that requires SSO?". I have the changes ready; I am using them
> daily.
>
> The OAuth 2.0 standard encodes the use of a user-agent (i.e., web
> browser) for authorization steps which differ per OAuth 2.0 provider,
> and are not defined by the specification. I have provided support for
> package authors and users to write custom functions to automate these
> web browser interactions in arbitrary ways:
>
> AUTHORIZATION-CODE-FUNCTION is an elisp function that takes an
> authorization URL as a string argument, and returns, as a string, a
> full URL containing a code value in its query string.
>
> By default though, url-http-oauth will prompt the user to copy-n-paste
> URLs to and from the web browser. This is the most general default I
> could think of; for example, this allows performing authorization in a
> local web browser then pasting the result to an Emacs session running
> three SSH hops away, where `browse-url' may not do the right thing.
>
> Users and package authors can design automatic user-agent interactions,
> but those ways are so varied that I wanted to see how they would evolve.
> For example, I would like to see someone write an
> authorization-code-function for Sourcehut that would use EWW inline.
> For other OAuth 2.0 providers whose authorization steps require
> JavaScript, EWW would not work.
>
> I have published another, tiny package:
>
> https://git.sr.ht/~fitzsim/url-http-oauth-demo
>
> It demonstrates the use of url-http-oauth against the Emacs-friendliest
> OAuth 2.0 implementation I've found: Sourcehut. Sourcehut's
> implementation is entirely Free Software, and it does not require
> JavaScript in the authorization steps. Its client registration process
> does not have onerous terms of use. Any Sourcehut user should be able
> to get url-http-oauth-demo working. Maybe this package makes sense in
> GNU ELPA, or perhaps it could be part of url-http-oauth's documentation.
>
> I wrote these packages myself [1] and I have copyright assignment
> paperwork on file.
>
> Thomas
>
> 1. Except url-http-oauth--netrc-delete, which borrows lots of code from
> auth-source.el.
>
>
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: emacs-29 9b775ddc057 1/2: ; * etc/EGLOT-NEWS: Fix wording of last change.
@ 2023-05-07 8:46 93% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-05-07 8:46 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Dmitry Gutov, monnier, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> Date: Sat, 6 May 2023 23:31:31 +0300
>> Cc: philipk@posteo.net, monnier@iro.umontreal.ca, emacs-devel@gnu.org
>> From: Dmitry Gutov <dmitry@gutov.dev>
>>
>> On 06/05/2023 22:38, Eli Zaretskii wrote:
>> >> package-menu-mark-upgrades ('U') is not affected by
>> >> package-install-upgrade-built-in. It won't.
>> >
>> > Shouldn't it?
>>
>> Maybe, maybe not.
>
> I think it better did, because using "U" would upgrade Eglot and
> use-package in Emacs 28 and before. So we should give users who want
> that the capability of keeping that workflow in Emacs 29, if only as
> opt-in behavior.
"Workflow" is really to high of a term for the problem being discussed
here. Installing packages is not a periodical thing people to on a
regular basis.
> Also, "/ u" should ideally show built-in packages as well, when
> package-install-upgrade-built-in is non-nil.
So the point here would be that a user who enables this option, regards
any newer version of a core-package on ELPA as something that should be
installed?
Perhaps this is a tangent, but what would happen if a third-party
repository like MELPA adds a package with the same name as a core
package?
> Philip, can these two changes be implemented safely for Emacs 29?
It certainly can be done.
>> A user that customized that option to have (package-install 'eglot)
>> ensure that a version from ELPA is installed might not want or expect
>> for it to affect package-menu-mark-upgrades and/or package-upgrade-all.
>
> That is true, but denying them the possibility of upgrading would be
> worse, I think. And since this is opt-in behavior, the user is less
> likely to be tripped by that without realizing it.
>
>> Or anticipate the full consequences anyway.
>
> Documentation should solve this aspect.
>
>> >>> If package-upgrade was not in Emacs 28, how did users upgrade
>> >>> installed packages in Emacs 28 and before?
>> >>
>> >> Using package-menu-mark-upgrades ('U').
>> >
>> > So we should allow that, at least as an optional behavior in Emacs 29,
>> > right?
>>
>> I don't believe in "optionality" here.
>>
>> If the user has to hunt for the option to toggle, they might as well
>> find the "one little trick" that does the thing they want.
>>
>> Most people will only have to do that once (per config), if at all:
>> after Eglot is upgraded this way, it's smooth sailing from then on.
>
> I think allowing such an optional behavior and documenting it in NEWS
> and in the manual should go a long way towards eliminating at least
> some of your fears.
>
>> >> We should probably focus on getting Emacs 29 out soon
>> >
>> > Why do you think this is not what happens?
>>
>> I'm just saying we've spent enough time on this particular issue. We can
>> improve the docs the best we can and move on.
>
> This is not the only issue that holds the next pretest. So nothing is
> lost by spending some more time on this, especially since it's now
> clear the original longish discussion was at least partially based on
> some kind of Rashomon effect.
--
Philip Kaludercic
^ permalink raw reply [relevance 93%]
* Re: emacs-29 9b775ddc057 1/2: ; * etc/EGLOT-NEWS: Fix wording of last change.
@ 2023-05-07 7:43 90% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-05-07 7:43 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: dmitry, monnier, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: Dmitry Gutov <dmitry@gutov.dev>, Stefan Monnier
>> <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
>> Date: Sat, 06 May 2023 18:44:35 +0000
>>
>> > If package-upgrade was not in Emacs 28, how did users upgrade
>> > installed packages in Emacs 28 and before?
>>
>> They invoked M-x list-packages, waited for the upgrade to appear,
>> selected them with U and then executed the update with x. This is what
>> used to work, and what will continue to work.
>
> But only if package-install-upgrade-built-in is non-nil, right?
No, that is unrelated since that user option has no effect on the
package menu.
Upgrading via U only works if the user has already installed a package
from ELPA. So in this case, a user would have to run M-x list-packages,
select and install Eglot, thereby instructing package.el to load the
local version instead of the version bundled with Emacs. This procedure
is how users would have upgraded from a older version of project.el, for
example.
This works regardless of what package-install-upgrade-built-in has been
set to. That is only related to how the `package-install' command
works.
>> > I don't see a zero-sum game here. We could focus on both. But I
>> > don't use package.el and never will, so if those who use it and
>> > maintain it think otherwise, I won't insist. Although I find this
>> > stance very strange indeed, to say the least.
>>
>> (This explains some of the confusion, I was under the assumption that
>> some of your questions were from a position of Socratic ignorance,
>
> You should know me better.
In that case I admit to plain ignorance. :)
--
Philip Kaludercic
^ permalink raw reply [relevance 90%]
* Re: emacs-29 9b775ddc057 1/2: ; * etc/EGLOT-NEWS: Fix wording of last change.
@ 2023-05-06 18:44 81% ` Philip Kaludercic
1 sibling, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-05-06 18:44 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Dmitry Gutov, Stefan Monnier, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> Date: Sat, 6 May 2023 18:54:47 +0300
>> Cc: joaotavora@gmail.com, emacs-devel@gnu.org
>> From: Dmitry Gutov <dmitry@gutov.dev>
>>
>> >> If some version of it is installed from ELPA (!) already, 'M-x
>> >> package-install' won't upgrade.
>> >
>> > Then I don't understand why you decided to drop the similar change to
>> > package-upgrade. At the time I thought package-install can be used as
>> > an alternative, but if it cannot, I think we should add to
>> > package-upgrade the same optional behavior of upgrading a built-in
>> > package as we have in package-install.
>>
>> We now have a better solution on master: 'M-x package-upgrade' simply
>> upgrades the built-ins, no questions asked.
>
> What we have on master is not relevant to what we discuss here, which
> is Emacs 29.
>
>> If we added the behavior similar to the addition in package-install
>> (with prefix arguments and guarded by an option, possibly even a new
>> optional argument), we'd have to carry over that awkward convention to
>> Emacs 30 in some form. And as you recall, Joao wasn't happy with either
>> solution anyway (of those that you liked enough).
>
> The question is: is it reasonable not to allow package-upgrade in
> Emacs 29 to upgrade a built-in package? Not even as an option?
I think that would be fine. The code looks fine, and considering the
commotion about this functionality and the effort that has been put into
preparing a minimal functional change, I think that it would be warranted
to allow for this change to be applies to emacs-29.
>> > What other methods currently exist to upgrade an already installed
>> > package (or a non-built-in package that is already installed)? I know
>> > about one -- via lisp-packages (a.k.a. package menu); are there
>> > others?
>>
>> Also:
>> M-x package-upgrade
>> M-x package-upgrade-all
>>
>> > Will any of these methods upgrade a built-in package, at least as an
>> > optional behavior?
>>
>> Not in Emacs 29.
>
> So I think we have a problem, and I think we need to solve it.
>
> Philip, Stefan: WDYT about this?
>
> What about installation from the list-packages menu: will it upgrade a
> built-in package if package-install-upgrade-built-in is non-nil?
Yes it will, which is why I find this discussion silly and have not been
following it in detail (also other non-emacs responsibilities have been
intervening).
>> > But if emptying ~/.emacs.d/elpa is not a frequent use case, why should
>> > we care about it so much? It sounds like bug#62720 and the entire
>> > long dispute that followed were focused on this strange use pattern,
>> > instead of talking about more reasonable upgrade scenarios?
>>
>> We focused on it because, apparently, using 'M-x package-install' worked
>> in more cases in Emacs 28 than in Emacs 29. And some think it's
>> important. And because 'package-upgrade' is not in Emacs 28 at all.
>
> If package-upgrade was not in Emacs 28, how did users upgrade
> installed packages in Emacs 28 and before?
They invoked M-x list-packages, waited for the upgrade to appear,
selected them with U and then executed the update with x. This is what
used to work, and what will continue to work. There was some mention
about problems with M-x list-packages, but I haven't heard of any
specific issues that could be addressed (I personally suspect it might
be an issue related to the tracking of the master or close-to-master
branches).
>> Personally, I think it's better to focus on fixing 'package-upgrade'
>> (which I did). But I don't think it's constructive to hide that fix
>> behind a pref.
>
> I don't see a zero-sum game here. We could focus on both. But I
> don't use package.el and never will, so if those who use it and
> maintain it think otherwise, I won't insist. Although I find this
> stance very strange indeed, to say the least.
(This explains some of the confusion, I was under the assumption that
some of your questions were from a position of Socratic ignorance,
but if you don't use it at all, then some of the past confusion makes
more sense to me.)
^ permalink raw reply [relevance 81%]
* Re: Extending timeclock.el
@ 2023-05-06 6:09 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-05-06 6:09 UTC (permalink / raw)
To: John Task; +Cc: emacs-devel
John Task <q01@disroot.org> writes:
> Hello. A little context, first; some days ago, I submitted a request
> for including a package in the NonGNU ELPA repository. The package in
> question was a time tracker named ETT. However, Eli pointed out that
> instead of creating a new package I could, for instance, extend the
> built-in timeclock.el instead. To be honest, I didn't like the idea
> at first, but looking at the code I quickly realized it wouldn't be
> that hard. At least, not as dramatically hard as I thought.
>
> So I started this: https://gitlab.com/q01_code/timeclock-modern
>
> [This wasn't my first name choice, but turns out timeclock-x is
> already taken]
By whom? I couldn't find anything.
> So far, I managed to write a series of parsers for the timelog format,
> as well as a basic API for retrieving information from it. This
> should allow me to port all the relevant code from ETT without issues.
> However, I'm not really familiarized with timeclock, so I can't assert
> my design choices so far have been ideal.
>
> + The letter code at the start of every line was the most difficult
> part. ETT (and a lot of modern time trackers as well) don't
> understand what clock-out means, as the idea is to clock everything;
> the user just clocks-in different activities. So, I dropped 'i' and
> 'o' for my custom tm-clock-in altogether. As for the parser, it
> understands 'o' as the start of a so-named 'Untracked' item/project.
> That way it can read existent timelogs just fine. This is hard
> enough, but turns out there are also other codes ('h', 'b' and '0').
> I interpret '0' as an 'o' and ignore the other ones, but I'm not sure
> if this is correct.
>
> + As I make a lot of decisions such as the last one from ignorance,
> I'm clueless about how well the parser (and the API) works for real
> timelog files. If anybody wants to test that, it would be
> appreciated.
>
> + As the original timeclock-in doesn't support inputting tags (as well
> as other features I need), I wrote a custom tm-clock-in. But I'm not
> sure if this is the right approach. And redefining timeclock-in would
> be even worse, for sure.
>
> I'll eventually contact the original author as well, but I wanted to
> know of any other opinions here first.
>
> Best regards.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: [GNU ELPA] eglot-x.el: Protocol extensions for Eglot
@ 2023-05-05 16:38 94% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-05-05 16:38 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Felician Nemeth, emacs-devel, joaotavora
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Felician Nemeth <felician.nemeth@gmail.com>
>> Cc: João Távora <joaotavora@gmail.com>
>> Date: Fri, 05 May 2023 13:56:21 +0200
>>
>> I'd like to submit a new package called eglot-x to ELPA. Its commentary
>> starts with:
>>
>> ;; Eglot supports (a subset of) the Language Server Protocol. However,
>> ;; there are useful protocol extensions that are not part of the
>> ;; official protocol specification. Eglot-x adds support for some of
>> ;; them. If you find a bug in Eglot, please, try to reproduce it
>> ;; without Eglot-x, because Eglot-x is substantially modifies Eglot's
>> ;; normal behavior as well.
>>
>> João intend to support only the standardized protocol features in
>> eglot.el, but lots of LSP servers extend the protocol in their own way.
>> (It was João who suggested the package name long ago.) I considered
>> eglot-x just an experiment and a learning possibility, but people seem
>> to use it, so I'd like to make their life easier by this submission.
>
> It sounds strange to me to refuse to support LSP extensions in
> eglot.el. At the very least, eglot.el could benefit from offering a
> supported mechanism for adding such extensions; there should be no
> need for using advice for that.
>
> João, why would you not consider supporting these extensions as part
> of eglot.el?
I think that it makes sense to have non-standard and perhaps not even
well specified (?) extensions to LSP as part of a separate package that
is not part of the core, so that it can adjust to changes in the
implementations that provide these extensions more quickly. I don't
know what the working procedure is for LSP, but if they do get added to
the standard, it should be easy to move the code from eglot-x to eglot,
if the package is on GNU ELPA.
^ permalink raw reply [relevance 94%]
* Re: emacs-29 44ebd9cbd56 2/2: Eglot: explain how to update Eglot in manual (bug#62720)
@ 2023-05-05 5:13 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-05-05 5:13 UTC (permalink / raw)
To: Robert Pluim; +Cc: João Távora, Dmitry Gutov, emacs-devel
Robert Pluim <rpluim@gmail.com> writes:
>>>>>> On Mon, 01 May 2023 07:34:12 +0000, Philip Kaludercic <philipk@posteo.net> said:
> >> Robert Pluim reported some breakage. And it's suspiciously slow to
> >> start for me.
>
> Philip> This does not appear to have been described in a bug report? Could you
> Philip> point me to the message where this happens?
>
> I didnʼt report a bug, because
>
> M-x list-packages
> U
> x
> <restart emacs> => lots of errors about wrong package version or
> missing packages
> <frantically reinstall/upgrade packages until errors are gone>
Do you happen to recall what kind of errors these were?
> is not something that can easily be reproduced and fixed.
>
> Although next time I upgrade packages, Iʼll save a before/after
> listing to see if it offers any insight.
That would be nice, thanks!
> Robert
^ permalink raw reply [relevance 99%]
* Re: [NonGNU Elpa] New package: ETT
@ 2023-05-03 16:41 91% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-05-03 16:41 UTC (permalink / raw)
To: John Task; +Cc: emacs-devel
John Task <q01@disroot.org> writes:
>> (defun ett-do-division (num1 num2)
>> - "Divide NUM1 between NUM2."
>> + "Divide NUM1 between NUM2." ;can you explain why this is needed?
>> (if (/= (% num1 num2) 0)
>> (/ (float num1) num2)
>> (/ num1 num2)))
>
> I need the extra precision for various functions. (/ 12 7) gives me
> 1, while (ett-do-division 12 7) gives me 1.7142857142857142.
If that is so, I would explain that in the documentation string, but
what I wonder is why if condition is needed. All you basically do is
avoid converting num1 to a float, and the result remains a integer, in
some cases.
>> (defun ett-prettify-time (time)
>> "Return a prettified string for TIME."
>> (let ((hr 0))
>> - (while (>= time 60)
>> + (while (>= time 60) ;the loop here shouldn't be necessary, you can calculate the same thing using remainder and floor
>> (setq hr (1+ hr)
>> time (- time 60)))
>
> I'll look into that. Is there any reason why I would need to avoid
> that loop? The code just works for now.
While this will calculate the values in constant time,
(list (floor time 60) (% time 60))
a loop will always take more iterations depending on the value of the input:
(let ((hr 0))
(while (>= time 60)
(setq hr (1+ hr)
time (- time 60)))
(list hr time))
>> (save-excursion
>> ;; Sort items
>> ;; We need to do it in two steps because it's somehow complicated
>> - (sort-regexp-fields t "^.*$" "\\(:[0-9]+\\)" (point-min) (point-max))
>> + (sort-regexp-fields t "^.*$" "\\(:[0-9]+\\)" (point-min) (point-max)) ;have you considered using rx?
>> (sort-regexp-fields t "^.*$" "\\([0-9]+:\\)" (point-min) (point-max))
>> ;; We now align
>> (align-regexp
>
> I have considered it, but while my regexps are weird, they are
> still readable for now. Maybe I'll reconsider it.
FWIW i even hesitated in bringing this up, because as you say the
regular expressions are currently modest in complexity.
>> +(defvar ett-view-mode-map
>> + (let ((map (make-sparse-keymap)))
>> + (define-key map (kbd "C-c C-c") #'ett-add-track)
>> + (define-key map (kbd "SPC") #'ett-space-dwim)
>> + map))
>
> I think you mean just ett-mode-map. In that case, OK.
Right, that was a typo. All I provide is faulty static analysis ^^
>> (define-derived-mode ett-mode text-mode "ETT"
>> "Major mode for editing ETT based texts."
>> (setq font-lock-defaults '(ett-font-lock-keywords t))
>> - (setq-local outline-regexp "[0-9]+-[0-9]+-[0-9]+")
>> + (setq-local outline-regexp "[0-9]+-[0-9]+-[0-9]+") ;does this need to start with a ^
>> ;; show-paren-mode can be somehow annoying here
>> (show-paren-local-mode -1))
>
> Documentation of the variable says it isn't necessary, and it worked
> as is on my tests, but I'm not an expert.
OK, I didn't know about that, then this is fine.
^ permalink raw reply [relevance 91%]
* Re: [NonGNU Elpa] New package: ETT
2023-05-03 6:08 42% ` Philip Kaludercic
@ 2023-05-03 6:11 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-05-03 6:11 UTC (permalink / raw)
To: John Task; +Cc: emacs-devel
Philip Kaludercic <philipk@posteo.net> writes:
> John Task <q01@disroot.org> writes:
> and I have prepared a few comments here:
Oh an by the way, it seems possible to reduce the minimum version of
Emacs to at least 26 using Compat
(https://elpa.gnu.org/packages/compat.html). Would you be interested in
that?
^ permalink raw reply [relevance 99%]
* Re: [NonGNU Elpa] New package: ETT
@ 2023-05-03 6:08 42% ` Philip Kaludercic
2023-05-03 6:11 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-05-03 6:08 UTC (permalink / raw)
To: John Task; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 2418 bytes --]
John Task <q01@disroot.org> writes:
> [Disclaimer: A similar message was posted here a couple months ago by
> me. Sorry if that's an annoyance. This one is clearer, though.]
>
> Hello. My name is John Task and I'd like to submit a package to
> NonGNU ELPA. I'm the author of this program and also (at the time of
> writing) the only contributor to the code. As far as I can tell,
> everything is in line with the guidances and I plan to keep it that
> way.
>
> The URL of the repository is: https://gitlab.com/q01_code/ett
>
> The description is as follows:
>
> ----------------------------------------------------------------------
> Emacs Time Tracker (or short ETT) is a simple yet powerful time
> tracker for Emacs. Even though it's based on a minimalist plain
> text file, it can show statistics for current day, week, month or
> year, and even compare tags recording for the same item given any
> of these periods.
>
> Advanced features include percentages, graphs and icons.
>
> Clock-in with M-x ett-add-track, go to file with M-x ett-find-file,
> and get report with M-x ett-report. You probably want to bind these
> functions to easy keys.
> ----------------------------------------------------------------------
>
> The corresponding patch would be:
>
> ---
> From 72c7ba2c1ecd375be52b071d25217088e66e9abb Mon Sep 17 00:00:00 2001
> From: John Task <q01@disroot.org>
> Date: Tue, 2 May 2023 17:40:44 -0300
> Subject: [PATCH] New package
>
> ---
> elpa-packages | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/elpa-packages b/elpa-packages
> index c333cc8bb3..385a76264d 100644
> --- a/elpa-packages
> +++ b/elpa-packages
> @@ -154,6 +154,11 @@
> :readme "README.md"
> :ignored-files ("doc/demo.gif"))
>
> + (ett :url "https://gitlab.com/q01_code/ett"
> + :readme ignore
> + :doc "ett-manual.org"
> + :ignored-files ("ett-manual.org" "COPYING" "ETT.png" "doclicense.texi"))
> +
> (evil :url "https://github.com/emacs-evil/evil"
> :ignored-files ("COPYING" "lib" "scripts")
> :doc "doc/build/texinfo/evil.texi")
I would track the ignored files in a .elpaignore file that would look
something like this
--8<---------------cut here---------------start------------->8---
/ett-pkg.el
/ett-autoloads.el
/ett-manual.org
/COPYING
/ETT.png
/doclicense.texi
--8<---------------cut here---------------end--------------->8---
and I have prepared a few comments here:
[-- Attachment #2: Type: text/plain, Size: 7282 bytes --]
diff --git a/ett.el b/ett.el
index c37d7f15b0..de6a017248 100644
--- a/ett.el
+++ b/ett.el
@@ -89,7 +89,7 @@ Something like '-->' or '====>' would be acceptable."
Unlike `ett-separator', you can safely change this to anything you want."
:type '(string))
-(defcustom ett-file (concat user-emacs-directory "tracks.ett")
+(defcustom ett-file (locate-user-emacs-file "tracks.ett")
"File for storing ETT tracks."
:type '(file))
@@ -125,10 +125,10 @@ size to be displayed.
Only even numbers are allowed. Indeed, it's a weird bug."
:type '(natnum))
-(defcustom ett-graph-icon "│"
+(defcustom ett-graph-icon ?│
"Icon used for building ETT graphs.
It must be a single char string."
- :type '(string))
+ :type 'character)
(defface ett-heading
'((((class color) (min-colors 88) (background light))
@@ -170,7 +170,7 @@ It must be a single char string."
(list "^\\(Less time .*\\): " '(1 'underline))
(list "^\\(Tags report\\):$" '(1 'underline))
(list "^\\(Pending goals\\):$" '(1 'underline))
- (list (concat ett-graph-icon "+") '(0 'ett-separator-face)))
+ (list (concat (string ett-graph-icon) "+") '(0 'ett-separator-face)))
"Keywords for syntax highlighting on ETT report buffer.")
(defvar ett-items-internal nil)
@@ -269,41 +269,36 @@ Here are some translations (*starred* values are current at the time):
3-2 ---> 03-02-*23*
03 ---> 03-*02*-*23*
3 ---> 03-*02*-*23*"
- (pcase (length date)
- ;; DD-MM-YY
- (8 date)
- ;; DD-MM
- (5 (setq date (concat date (format-time-string "-%y"))))
- ;; DD
- (2 (setq date (concat date (format-time-string "-%m-%y"))))
- ;; D
- (1 (setq date (concat "0" date (format-time-string "-%m-%y"))))
- ;; DD-M
- (4
- (setq date
- ;; Or D-MM?
- (pcase (string-search "0" date)
- (2 (concat "0" date (format-time-string "-%y")))
- (_ (concat
+ (setq date
+ (pcase (length date)
+ ;; DD-MM-YY
+ (8 date)
+ ;; DD-MM
+ (5 (concat date (format-time-string "-%y")))
+ ;; DD
+ (2 (concat date (format-time-string "-%m-%y")))
+ ;; D
+ (1 (concat "0" date (format-time-string "-%m-%y")))
+ ;; DD-M
+ (4
+ ;; Or D-MM?
+ (pcase (string-search "0" date)
+ (2 (concat "0" date (format-time-string "-%y")))
+ (_ (concat
(replace-regexp-in-string "-\\(.*\\)" "-0\\1" date)
- (format-time-string "-%y"))))))
- ;; D-M
- (3 (setq date
- (concat "0" (replace-regexp-in-string "-\\(.*\\)" "-0\\1" date)
- (format-time-string "-%y"))))
- ;; D-MM-YY
- (7 (setq date
- ;; Or DD-M-YY?
- (pcase (string-search "0" date)
- (2 (concat "0" date))
- (_ (concat
- (replace-regexp-in-string "-\\(.*\\)-" "-0\\1-" date))))))
- ;; D-M-YY (who writes like that?)
- (6 (setq date
- (concat "0"
- (replace-regexp-in-string "-\\(.*\\)-" "-0\\1-" date)))))
- ;; Return date
- date)
+ (format-time-string "-%y")))))
+ ;; D-M
+ (3 (concat "0" (replace-regexp-in-string "-\\(.*\\)" "-0\\1" date)
+ (format-time-string "-%y")))
+ ;; D-MM-YY
+ (7 ;; Or DD-M-YY?
+ (pcase (string-search "0" date)
+ (2 (concat "0" date))
+ (_ (concat
+ (replace-regexp-in-string "-\\(.*\\)-" "-0\\1-" date)))))
+ ;; D-M-YY (who writes like that?)
+ (6 (concat "0"
+ (replace-regexp-in-string "-\\(.*\\)-" "-0\\1-" date))))))
(defun ett-custom-date (date &optional date2)
"Operate on current buffer so the only date is DATE.
@@ -329,7 +324,7 @@ With optional DATE2, include every date between DATE and DATE2."
(ett-finalize-scope "00:00")))))
(defun ett-do-division (num1 num2)
- "Divide NUM1 between NUM2."
+ "Divide NUM1 between NUM2." ;can you explain why this is needed?
(if (/= (% num1 num2) 0)
(/ (float num1) num2)
(/ num1 num2)))
@@ -511,7 +506,7 @@ Like `insert-rectangle', but doesn't set mark."
(insert
(mapconcat #'concat (make-list (- col (current-column)) " ") "")))
(ett-insert-rectangle
- (make-list graph-f ett-graph-icon)))
+ (make-list graph-f (string ett-graph-icon))))
(setq list (cdr list)
col (current-column)))
(setq beacon (point)
@@ -545,7 +540,7 @@ Like `insert-rectangle', but doesn't set mark."
(defun ett-prettify-time (time)
"Return a prettified string for TIME."
(let ((hr 0))
- (while (>= time 60)
+ (while (>= time 60) ;the loop here shouldn't be necessary, you can calculate the same thing using remainder and floor
(setq hr (1+ hr)
time (- time 60)))
(concat
@@ -789,7 +784,7 @@ When NOTOTAL is non-nil, don't add total indicator."
(save-excursion
;; Sort items
;; We need to do it in two steps because it's somehow complicated
- (sort-regexp-fields t "^.*$" "\\(:[0-9]+\\)" (point-min) (point-max))
+ (sort-regexp-fields t "^.*$" "\\(:[0-9]+\\)" (point-min) (point-max)) ;have you considered using rx?
(sort-regexp-fields t "^.*$" "\\([0-9]+:\\)" (point-min) (point-max))
;; We now align
(align-regexp
@@ -1174,13 +1169,27 @@ Use the command `ett-modeline-mode' to change this variable.")
;; Clock in
(ett-add-track item tag)))
+(defvar ett-view-mode-map
+ (let ((map (make-sparse-keymap)))
+ (define-key map (kbd "C-c C-c") #'ett-add-track)
+ (define-key map (kbd "SPC") #'ett-space-dwim)
+ map))
+
(define-derived-mode ett-mode text-mode "ETT"
"Major mode for editing ETT based texts."
(setq font-lock-defaults '(ett-font-lock-keywords t))
- (setq-local outline-regexp "[0-9]+-[0-9]+-[0-9]+")
+ (setq-local outline-regexp "[0-9]+-[0-9]+-[0-9]+") ;does this need to start with a ^
;; show-paren-mode can be somehow annoying here
(show-paren-local-mode -1))
+(defvar ett-view-mode-map
+ (let ((map (make-sparse-keymap)))
+ (define-key map (kbd "q") #'bury-buffer)
+ (define-key map (kbd "SPC") #'ett-choose-view)
+ (define-key map (kbd "<up>") #'scroll-down-command)
+ (define-key map (kbd "<down>") #'scroll-up-command)
+ map))
+
(define-derived-mode ett-view-mode ett-mode "ETT [report]"
"Major mode for viewing ETT reports."
(setq font-lock-defaults '(ett-view-font-lock-keywords t))
@@ -1188,15 +1197,8 @@ Use the command `ett-modeline-mode' to change this variable.")
(setq-local view-read-only nil)
(setq cursor-type nil))
-(define-key ett-view-mode-map (kbd "q") #'bury-buffer)
-(define-key ett-view-mode-map (kbd "SPC") #'ett-choose-view)
-(define-key ett-view-mode-map (kbd "<up>") #'scroll-down-command)
-(define-key ett-view-mode-map (kbd "<down>") #'scroll-up-command)
-(define-key ett-mode-map (kbd "C-c C-c") #'ett-add-track)
-(define-key ett-mode-map (kbd "SPC") #'ett-space-dwim)
-
;;;###autoload
-(add-to-list 'auto-mode-alist (cons (purecopy "\\.ett\\'") 'ett-mode))
+(add-to-list 'auto-mode-alist '("\\.ett\\'" . ett-mode))
(provide 'ett)
^ permalink raw reply related [relevance 42%]
* Re: emacs-29 44ebd9cbd56 2/2: Eglot: explain how to update Eglot in manual (bug#62720)
@ 2023-05-01 7:34 93% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-05-01 7:34 UTC (permalink / raw)
To: João Távora; +Cc: Dmitry Gutov, emacs-devel
João Távora <joaotavora@gmail.com> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> My point is that I am guessing the average user you interact with is
>> either having issues or is actively interested in Eglot. I suspect (and
>> it is my experience) the average user, just like the average Emacs user,
>> does not really think about the specific version they are running.
>
> Yeah, who knows? And who knows if all the users we don't hear from are
> all three-headed fish from Neptune? Don't think that means I should
> ignore the users that face problems/want features and do make their
> voices heard.
>
> I do agree they don't think about versions, and even less what is :core
> or not. They probably just want things to work.
I agree with you on that, the issue is that we have different ideas of
what that means ^^.
>>> PK> I have in my init.el is a lot:
>>> PK> eldoc-echo-area-use-multiline-p nil
>>> If you upgrade Eglot, you probably won't need this customization ;-)
>> How come, is this not related to eldoc?
>
> It is, but you included it in your Eglot section, did you not?
AFAIR I just did that because I structure my configuration with
outline-minor-mode and did not want to add another section.
> And it
> was, for a long time, a way to avoid "echo area flooding" in Eglot. So
> I figured you'd be interested in knowning that that problem is largely
> fixed.
OK, thanks for the tip, I will take a look if things changed for me.
>> Broken? If that is the case, the issue should be addressed, but the
>> only issue I know of is that the package status is occasionally
>> incorrect, but that does not affect the packages itself.
>
> Robert Pluim reported some breakage. And it's suspiciously slow to
> start for me.
This does not appear to have been described in a bug report? Could you
point me to the message where this happens?
>> [eglot-update] should be deprecated though
>
> Noone disagrees with that. Will do once there is a better alternative,
> which there isn't atm.
The plan is to address this in Emacs 30, and perhaps even earlier if we
manage to add package.el to ELPA.
^ permalink raw reply [relevance 93%]
* Re: emacs-29 44ebd9cbd56 2/2: Eglot: explain how to update Eglot in manual (bug#62720)
@ 2023-04-30 12:12 86% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-04-30 12:12 UTC (permalink / raw)
To: João Távora; +Cc: Dmitry Gutov, emacs-devel
João Távora <joaotavora@gmail.com> writes:
> [ I think everything has already been said in this discussion, so let me
> try to answer two-in-one mails to minimize chatter. ]
>
> PK> experiences. I have a hunch that João as the maintainer of Eglot is
> PK> over-exposed to people who are interested in having the absolutely
> PK> newest version so they can make use of the absolutely newest
> PK> features,
>
> I don't know what that means. I am exposed to the users I am exposed
> to, and there seem to be a lot of them. A lot of reports and
> conversations over here and over at GitHub. I spend my time with them,
> very often having to guess things. If I can at least minimize the time
> wasted agreeing on what Eglot version is being used or how to get the
> newest bugfix/feature, I do want that.
My point is that I am guessing the average user you interact with is
either having issues or is actively interested in Eglot. I suspect (and
it is my experience) the average user, just like the average Emacs user,
does not really think about the specific version they are running.
> PK> I have in my init.el is a lot:
> PK> eldoc-echo-area-use-multiline-p nil
>
> If you upgrade Eglot, you probably won't need this customization ;-)
How come, is this not related to eldoc?
> DG> some of this stuff will definitely get outdated. If we fixed
> DG> package-upgrade, that could be easy enough, but 'M-x eglot-upgrade'
> DG> can be a comparable alternative.
> PK>> Just thinking about introducing a command that we right-now plan to
> PK>> deprecate by the next release is not something I look forward to.
> DG> It would probably be deprecated only several major versions later.
>
> Dmitry is right.
>
> An interesting direction would be to fix package-upgrade in Emacs 29 &
> make package.el a self-updating :core package itself. But the former
> has been ruled out and the latter is also looking murky. Are there
> other more complicated ways to achieve this? Of course, and
> list-packages was the first workaround listed by me when I opened
> bug#62720. But the menu is fraught with its own problems (slow,
> complicated and sometimes downright broken by some accounts).
Broken? If that is the case, the issue should be addressed, but the
only issue I know of is that the package status is occasionally
incorrect, but that does not affect the packages itself.
> eglot-update _not_ the prettiest option, but it's the best _possible_
> option which guarantees consistency across Emacs versions. I've
> exhausted my attempts to steer this discussion in other directions.
In my eyes it is not only not-pretty, but unnecessary (considering that
list-packages does work and does so consistently over versions) and
confuse the average user, when the command is eventually deprecated, but
low-quality web forums recommend using it in their archives.
> So eglot-update it is. I buy the consistency argument, I do, but there
> are plenty of <package>-version and <package>-bug too in the Emacs tree
> There is even tramp-recompile-elpa. None of this is deprecated. Which
> just means maintainters need things to work foremost before wanting them
> to be pretty.
It should be deprecated though, and I don't think that these patterns
should be encouraged or added.
> João
^ permalink raw reply [relevance 86%]
* Re: vc-dir fails if Git upstream branch is local
@ 2023-04-30 9:09 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-04-30 9:09 UTC (permalink / raw)
To: Tobias Bading; +Cc: emacs-devel
Tobias Bading <tbading@web.de> writes:
> Hi.
>
> Is it just me, am I using Git wrong, or does vc-dir fail for everyone in a
> working tree whose upstream branch is a local branch, not a remote-tracking
> branch?
I think you should report this as a bug.
^ permalink raw reply [relevance 99%]
* Re: Stability of core packages
@ 2023-04-30 9:07 86% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-04-30 9:07 UTC (permalink / raw)
To: Mohsen BANAN; +Cc: Eli Zaretskii, emacs-devel, João Távora
Mohsen BANAN <emacs@mohsen.1.banan.byname.net> writes:
[...]
> Eli, if you have not used straight.el, I suggest
> experimenting with it. And again sorry about
> having been overly cryptic.
I have never used straight.el either (mainly because of the need
aggressive incompatibility with package.el and my dislike of having a
big bootstrap-blob at the beginning of my init), but I have been working
on package-vc that a lot of people have apparently been using as a
replacement for package.el. Recently there has been some work on
supporting arbitrary build-commands that could be executed alongside the
package compilation. I have been told that this is a major feature
difference between the current state of package-vc and the
straight/elpaca family of package managers. As you seem to have some
experience with the topic, do you believe this could be helpful to
address your issue? I am uncertain if this is something worth investing
an effort into, as the issues that Emacs lisp packaging struggles with
are not only those of finding a set of compatible revisions.
^ permalink raw reply [relevance 86%]
* Re: emacs-29 44ebd9cbd56 2/2: Eglot: explain how to update Eglot in manual (bug#62720)
@ 2023-04-29 10:15 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-04-29 10:15 UTC (permalink / raw)
To: Dmitry; +Cc: Eli Zaretskii, emacs-devel, joaotavora
Dmitry <dmitry@gutov.dev> writes:
> On Sat, Apr 29, 2023, at 12:40 PM, Eli Zaretskii wrote:
>> > From: Philip Kaludercic <philipk@posteo.net>
>> > Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org, joaotavora@gmail.com
>> > Date: Sat, 29 Apr 2023 09:08:22 +0000
>> >
>> > What do you think about the approach of adding package.el to ELPA, and
>> > then being able to fix the issue of package-upgrade/install that way?
>>
>> We should be careful about that: it could produce bootstrap-type
>> problems, since package.el is itself required for fetching stuff from
>> ELPA.
>
> Right. I mentioned exactly that concern in the other bug thread.
I think it might work, but we will have to see.
(Btw, I don't think there was ever a bug report on this matter, there
was just a discussion here on emacs-devel)
^ permalink raw reply [relevance 99%]
* Re: emacs-29 44ebd9cbd56 2/2: Eglot: explain how to update Eglot in manual (bug#62720)
@ 2023-04-29 10:13 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-04-29 10:13 UTC (permalink / raw)
To: Dmitry; +Cc: Eli Zaretskii, emacs-devel, joaotavora
Dmitry <dmitry@gutov.dev> writes:
> On Sat, Apr 29, 2023, at 9:45 AM, Eli Zaretskii wrote:
>> > Date: Sat, 29 Apr 2023 03:52:48 +0300
>> > Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org, joaotavora@gmail.com
>> > From: Dmitry Gutov <dmitry@gutov.dev>
>> >
>> > But that's the thing: upgrading to a recent version of Eglot is not only
>> > for the more advanced user. Those can easily go the 'M-x list-packages
>> > C-s eglot i x' route.
>> >
>> > It is those who do the minimum customization and/or are just introduced
>> > to Emacs, can miss out with more likelihood the longer the steps to
>> > upgrade Eglot are going to be.
>>
>> At the risk of sounding like a broken record: introducing a new
>> command for upgrading Eglot has the same problem as the original one:
>> users of Emacs 29 will need to use a different procedure for upgrading
>> Eglot than they used before.
> But users of Emacs 28- would be able to use it too. So at least the docs could list just one method.
But they don't need it, because package-install does the right thing to
begin with?
^ permalink raw reply [relevance 99%]
* Re: emacs-29 44ebd9cbd56 2/2: Eglot: explain how to update Eglot in manual (bug#62720)
@ 2023-04-29 9:08 87% ` Philip Kaludercic
2 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-04-29 9:08 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: Eli Zaretskii, emacs-devel, joaotavora
Dmitry Gutov <dmitry@gutov.dev> writes:
> On 28/04/2023 21:12, Philip Kaludercic wrote:
>> Dmitry Gutov <dmitry@gutov.dev> writes:
>>
>>> On 28/04/2023 17:25, Philip Kaludercic wrote:
>>>> Eli Zaretskii<eliz@gnu.org> writes:
>>>>
>>>>>> Date: Fri, 28 Apr 2023 02:52:56 +0300
>>>>>> From: Dmitry Gutov<dmitry@gutov.dev>
>>>>>>
>>>>>> Hi!
>>>>>>
>>>>>> On 28/04/2023 02:39, João Távora wrote:
>>>>>>> * lisp/progmodes/eglot.el (eglot-update): New command.
>>>>>> Should it be called eglot-upgrade now as well?
>>>>> No, it should be removed.
>>>> 1+
>>>
>>> This doesn't sound very constructive at this point.
>> It is difficult to be constructive here. I believe that the
>> long-term
>> complications/confusion of introducing this kind of a command instead of
>> instructing users on Emacs 29 to update a package like Eglot manually is
>> not worth it, while others do. These matters are difficult to quantify,
>> so we cannot reach a consensus by pointing to some objective reality,
>> and instead of have to fall back on personal impressions and
>> experiences. I have a hunch that João as the maintainer of Eglot is
>> over-exposed to people who are interested in having the absolutely
>> newest version so they can make use of the absolutely newest features,
>> while most people I know, personally or online, that make use of Eglot
>> barley bother to configure it at all (I consider that to be one of the
>> major setting points for the package, btw). Comparing other
>> configurations I have seen online, I actually think that what I have in
>> my init.el is a lot:
>> --8<---------------cut here---------------start------------->8---
>> (setup eglot
>> (setopt eglot-autoshutdown t
>> eglot-extend-to-xref t
>> eldoc-echo-area-use-multiline-p nil
>> eldoc-idle-delay 0.1)
>> (:bind "C-c a" #'eglot-code-actions
>> "C-c z" #'eglot-format
>> "C-c r" #'eglot-rename)
>> (:unbind [remap display-local-help]))
>> --8<---------------cut here---------------end--------------->8---
>
> But that's the thing: upgrading to a recent version of Eglot is not
> only for the more advanced user. Those can easily go the 'M-x
> list-packages C-s eglot i x' route.
>
> It is those who do the minimum customization and/or are just
> introduced to Emacs, can miss out with more likelihood the longer the
> steps to upgrade Eglot are going to be.
Perhaps, but I don't think that eglot-update/upgrade is a necessary
improvement from that perspective.
> The newest version of Eglot is not just the latest shiny, it's also
> the most recent mapping of modes to language servers, for example. Or
> mapping of Emacs features to LSP capabilities.
I am afraid I don't get what you mean here? Could you give an example?
> And Emacs 29 will
> continue to be installed and used 3-5-7 years after its release, where
> some of this stuff will definitely get outdated. If we fixed
> package-upgrade, that could be easy enough, but 'M-x eglot-upgrade'
> can be a comparable alternative.
What do you think about the approach of adding package.el to ELPA, and
then being able to fix the issue of package-upgrade/install that way?
On a related-topic: Shouldn't major modes modify `eglot-server-programs'
instead of centralising all the information in eglot.el? If that were
the common practice, then it would be a lot easier to propagate
new information about the best language servers to use.
>> Just thinking about introducing a command that we right-now plan to
>> deprecate by the next release is not something I look forward to.
>
> It would probably be deprecated only several major versions later.
Not to my knowledge?
>> Even
>> just promoting the concept of having a package-specific upgrade command
>> is something I am a afraid of (it took for ages for third-party packages
>> to stop adding pointless `foo-version' commands). And I might have
>> missed something here, but none of this would tackle the "central" issue
>> of use-package not installing the newest version of a package if the
>> package is already built-in, but hasn't yet been installed before.
>
> I don't know if it's "central": according to the docs, (use-package
> eglot :ensure t) is only meant to ensure that Eglot is
> installed. Whether that means the very latest version at the time the
> configuration is first run, or not, seems a matter of opinion.
In that case we agree. I believe João held a different opinion, but as
I was not able to follow the discussion over the last week in detail I
might have missed something.
^ permalink raw reply [relevance 87%]
* Re: emacs-29 44ebd9cbd56 2/2: Eglot: explain how to update Eglot in manual (bug#62720)
@ 2023-04-28 18:12 69% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-04-28 18:12 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: Eli Zaretskii, emacs-devel, joaotavora
Dmitry Gutov <dmitry@gutov.dev> writes:
> On 28/04/2023 17:25, Philip Kaludercic wrote:
>> Eli Zaretskii<eliz@gnu.org> writes:
>>
>>>> Date: Fri, 28 Apr 2023 02:52:56 +0300
>>>> From: Dmitry Gutov<dmitry@gutov.dev>
>>>>
>>>> Hi!
>>>>
>>>> On 28/04/2023 02:39, João Távora wrote:
>>>>> * lisp/progmodes/eglot.el (eglot-update): New command.
>>>> Should it be called eglot-upgrade now as well?
>>> No, it should be removed.
>> 1+
>
> This doesn't sound very constructive at this point.
It is difficult to be constructive here. I believe that the long-term
complications/confusion of introducing this kind of a command instead of
instructing users on Emacs 29 to update a package like Eglot manually is
not worth it, while others do. These matters are difficult to quantify,
so we cannot reach a consensus by pointing to some objective reality,
and instead of have to fall back on personal impressions and
experiences. I have a hunch that João as the maintainer of Eglot is
over-exposed to people who are interested in having the absolutely
newest version so they can make use of the absolutely newest features,
while most people I know, personally or online, that make use of Eglot
barley bother to configure it at all (I consider that to be one of the
major setting points for the package, btw). Comparing other
configurations I have seen online, I actually think that what I have in
my init.el is a lot:
--8<---------------cut here---------------start------------->8---
(setup eglot
(setopt eglot-autoshutdown t
eglot-extend-to-xref t
eldoc-echo-area-use-multiline-p nil
eldoc-idle-delay 0.1)
(:bind "C-c a" #'eglot-code-actions
"C-c z" #'eglot-format
"C-c r" #'eglot-rename)
(:unbind [remap display-local-help]))
--8<---------------cut here---------------end--------------->8---
Just thinking about introducing a command that we right-now plan to
deprecate by the next release is not something I look forward to. Even
just promoting the concept of having a package-specific upgrade command
is something I am a afraid of (it took for ages for third-party packages
to stop adding pointless `foo-version' commands). And I might have
missed something here, but none of this would tackle the "central" issue
of use-package not installing the newest version of a package if the
package is already built-in, but hasn't yet been installed before. As
mentioned above: If we want to tell users to install packages using a
custom command, they might as well use M-x list-packages and select the
package from ELPA that way?
^ permalink raw reply [relevance 69%]
* Re: emacs-29 44ebd9cbd56 2/2: Eglot: explain how to update Eglot in manual (bug#62720)
@ 2023-04-28 14:25 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-04-28 14:25 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Dmitry Gutov, emacs-devel, joaotavora
Eli Zaretskii <eliz@gnu.org> writes:
>> Date: Fri, 28 Apr 2023 02:52:56 +0300
>> From: Dmitry Gutov <dmitry@gutov.dev>
>>
>> Hi!
>>
>> On 28/04/2023 02:39, João Távora wrote:
>> > * lisp/progmodes/eglot.el (eglot-update): New command.
>>
>> Should it be called eglot-upgrade now as well?
>
> No, it should be removed.
1+
^ permalink raw reply [relevance 99%]
* Re: [nongnu] elpa/editorconfig ed3defaad8: Add support for gdscript-mode (#300)
[not found] ` <20230426195944.6BDA0C21715@vcs2.savannah.gnu.org>
@ 2023-04-27 11:54 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-04-27 11:54 UTC (permalink / raw)
To: emacs-devel; +Cc: Jen-Chieh Shen
ELPA Syncer <elpasync@gnu.org> writes:
> branch: elpa/editorconfig
> commit ed3defaad8d83f77cfee581cfaa19aaea016664d
> Author: Jen-Chieh Shen <jcs090218@gmail.com>
> Commit: GitHub <noreply@github.com>
>
> Add support for gdscript-mode (#300)
> ---
> editorconfig.el | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/editorconfig.el b/editorconfig.el
> index 7b224bffbb..d0f5998812 100644
> --- a/editorconfig.el
> +++ b/editorconfig.el
> @@ -217,6 +217,7 @@ This hook will be run even when there are no matching sections in
> (fsharp-mode fsharp-continuation-offset
> fsharp-indent-level
> fsharp-indent-offset)
> + (gdscript-mode gdscript-indent-offset)
Would it be possible to try and guess a variable name from the major mode?
> (groovy-mode groovy-indent-offset)
> (go-ts-mode go-ts-mode-indent-offset)
> (haskell-mode haskell-indent-spaces
^ permalink raw reply [relevance 99%]
* Re: ELPA: New package nano-dialog
@ 2023-04-25 14:13 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-04-25 14:13 UTC (permalink / raw)
To: Nicolas P. Rougier (inria); +Cc: emacs-devel
"Nicolas P. Rougier (inria)" <nicolas.rougier@inria.fr> writes:
> It's actually redundant with minibuffer interaction but it also offers
> more options. I'm mosly using it to display nano-agenda for quick
> interaction without disturbing windows layout.
How would minibuffer interaction disturb the window layout?
> There are probably many
> more use. For example it could serve as a replacement for system
> dialog
Does it work on on the TUI?
^ permalink raw reply [relevance 99%]
* Re: ELPA: New package nano-dialog
@ 2023-04-25 12:42 94% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-04-25 12:42 UTC (permalink / raw)
To: Nicolas P. Rougier (inria); +Cc: emacs-devel
"Nicolas P. Rougier (inria)" <nicolas.rougier@inria.fr> writes:
> Nicolas P. Rougier (inria) [2023-04-19 at 09:19] wrote:
>> Dear all,
>> I would like to submit a new package to ELPA which is a library for
>> creating native dialog popups. Those popups are child frames where:
>> - header line is used to show the (optional) header
>> - mode line is used to show (optional) clickable buttons
>> - buttons can be highlighted with cursor (tooltips hack)
>> - dialog content is a regular buffer
>> Usage example:
>> (nano-dialog nil :title "Dialog title" :buttons '("OK" "CANCEL"))
>> The library is hosted at https://github.com/rougier/nano-dialog and
>> the README displays what it looks like.
>> Best,
>> Nicolas
>
> Hi all,
>
> Any comments on this package for inclusion in ELPA?
One nice thing would be if you could provide an .elpaignore file so that
the screenshot is not included in the tarball.
Your user options all lack types, that should be addressed. You should
probably also run checkdoc and address those issues.
My general question (and the reason I did not respond to the issue the
first time I saw your message), is that I am not sure what this package
provides over built-in functionality like yes-or-no-p or
read-multiple-choice. Is this a library for another package of yours?
> Nicolas
^ permalink raw reply [relevance 94%]
* Re: [ELPA] Add package flymake-rest
@ 2023-04-22 6:51 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-04-22 6:51 UTC (permalink / raw)
To: Mohsin Kaleem; +Cc: Stefan Monnier, emacs-devel
Mohsin Kaleem <mohkale@kisara.moe> writes:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
> Hi all,
>
> Just to give a quick update. I've started work on a new functional
> framework for flymake-collections checkers. Once it's ready I'll
> probably re-approach the matter of ELPA or perhaps even builtin
> flymake support for it.
Is it possible to follow your work somewhere, or are you working on this
privately?
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: [ELPA] New package: calibre.el
@ 2023-04-20 18:26 99% ` Philip Kaludercic
1 sibling, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-04-20 18:26 UTC (permalink / raw)
To: Kjartan Óli Águstsson; +Cc: emacs-devel
Kjartan Óli Águstsson <kjartanoli@outlook.com> writes:
>>> This is my first attempt at writing an Emacs package, so I expect to
>>> have gotten many things wrong. As such I would welcome reviews from
>>> people who know more about Elisp packaging.
>>
>> The first thing to note is that you don't need a -pkg.el file. ELPA
>> will generate one for you using the metadata in the main file and
>> overwrite whatever you have written.
>
> Another good to know. I remember reading that somewhere, but then I
> looked at some other packages that seemed to maintain a -pkg.el file.
It is a common mistake or a MELPA-ism I don't know about ^^.
> As for the usage of eieio, is there a reason not to use it?
If you just need a structure then cl-defstruct should be a less-heavy
solution.
^ permalink raw reply [relevance 99%]
* Re: Stability of core packages
@ 2023-04-20 17:26 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-04-20 17:26 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Dmitry Gutov, joaotavora, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> Date: Thu, 20 Apr 2023 18:30:47 +0300
>> Cc: joaotavora@gmail.com, emacs-devel@gnu.org
>> From: Dmitry Gutov <dmitry@gutov.dev>
>>
>> When you say "keeping core packages only on ELPA", what do you mean exactly?
>
> That core packages will be only in elpa.git, not in emacs.git. Then
> we'd "bundle" them with Emacs when preparing the release tarballs.
>
> I believe this is a long-term plan wrt core packages. It was even
> discussed a couple of times here.
For people building Emacs from source, would this mean that they
would have to manually install core packages? Also, this sounds like it
would make it impossible for package.el to be distributed on ELPA, as
proposed in another thread.
^ permalink raw reply [relevance 99%]
* Re: [ELPA] New package: calibre.el
@ 2023-04-18 6:05 89% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-04-18 6:05 UTC (permalink / raw)
To: Kjartan Óli Águstsson; +Cc: emacs-devel
Kjartan Óli Águstsson <kjartanoli@outlook.com> writes:
> I am currently working on a package to interact with Calibre
> (https://calibre-ebook.com/). The repository can be found here:
> https://git.disroot.org/kjartanoli/calibre.el.
Sounds interesting!
> Would there be any
> interest in adding it to GNU ELPA? And if so, is my copyright assignment
> for Emacs sufficient, or does ELPA require a separate assignment?
No separate assignment is necessary, as GNU ELPA packages are regarded
to be part of Emacs.
> This is my first attempt at writing an Emacs package, so I expect to
> have gotten many things wrong. As such I would welcome reviews from
> people who know more about Elisp packaging.
The first thing to note is that you don't need a -pkg.el file. ELPA
will generate one for you using the metadata in the main file and
overwrite whatever you have written.
This means you should copy the metadata to calibre.el. Especially the
dependency list. (Also, why do you depend on "29.1.0", a version which
is unreleased and has an additional ".0" at the end? I guess you need
Emacs 29 because of SQLite? Have you taken a look at emacsql?)
From a brief skim of the code, it looks more or less fine. There are
minor things I am not sure about (such as the usage of eieio or why you
declare some functions instead of requiring the file).
^ permalink raw reply [relevance 89%]
* Re: [elpa] externals/org 26ef5e3e5b: org-src: Use `sh-mode' for all the shells it can handle
@ 2023-04-17 16:42 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-04-17 16:42 UTC (permalink / raw)
To: Andreas Schwab
Cc: Lynn Winebarger, Stefan Monnier, Matthew Trzcinski, emacs-devel
Andreas Schwab <schwab@linux-m68k.org> writes:
> On Apr 17 2023, Philip Kaludercic wrote:
>
>>> Why is the former more efficient than the latter? It looks like the former
>>> would have to construct the '(1 2) list twice, and the latter only once.
>>> And the '(a b c d) cons cells are only allocated once either way.
>>
>> (I believe) It is more efficient, since there are fewer function calls.
>> I have had issues in the past with ,@ expanding to code that would have
>> exceeded the maximal evaluation depth, until I split it up and manually
>> used `append' that has the advantage of being implemented in C.
>
> cons is a bytecode intrinsic, so it shouldn't make that much of a
> difference.
> (cons 'a (cons 'b (cons 'c (cons 'd (list 1 2 3))))) is translated into
>
> 0 constant a
> 1 constant b
> 2 constant c
> 3 constant d
> 4 constant 1
> 5 constant 2
> 6 constant 3
> 7 listN 7
Would this also affect code in a `eval-when-compile' block (which was my
anecdotal case)? From what I see, that shouldn't be byte-compiled.
^ permalink raw reply [relevance 99%]
* Re: [elpa] externals/org 26ef5e3e5b: org-src: Use `sh-mode' for all the shells it can handle
@ 2023-04-17 16:27 95% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-04-17 16:27 UTC (permalink / raw)
To: Lynn Winebarger; +Cc: Stefan Monnier, Matthew Trzcinski, emacs-devel
Lynn Winebarger <owinebar@gmail.com> writes:
> On Mon, Apr 17, 2023, 12:10 PM Stefan Monnier <monnier@iro.umontreal.ca>
> wrote:
>
>> > (defcustom org-src-lang-modes
>> > - '(("C" . c)
>> > + `(("C" . c)
>> > ("C++" . c++)
>> > ("asymptote" . asy)
>> > - ("bash" . sh)
>> > ("beamer" . latex)
>> > ("calc" . fundamental)
>> > ("cpp" . c++)
>> > @@ -208,9 +215,10 @@ but which mess up the display of a snippet in Org
>> exported files.")
>> > ("elisp" . emacs-lisp)
>> > ("ocaml" . tuareg)
>> > ("screen" . shell-script)
>> > - ("shell" . sh)
>> > ("sqlite" . sql)
>> > - ("toml" . conf-toml))
>> > + ("toml" . conf-toml)
>> > + ("shell" . sh)
>> > + ,@(org-src--get-known-shells))
>> > "Alist mapping languages to their major mode.
>>
>> Side note: while it really doesn't matter here for such trivial
>> top-level code, I prefer to put such ,@ at the beginning rather than the
>> end of lists, when it's an option. Basically because it's more
>> efficient to add to the beginning rather than to the end of a list:
>>
>> ELISP> (macroexpand '`(,@(list 1 2) a b c d))
>> (append (list 1 2) '(a b c d))
>> ELISP> (macroexpand '`(a b c d ,@(list 1 2)))
>> (cons 'a (cons 'b (cons 'c (cons 'd (list 1 2)))))
>> ELISP>
Is this just an implementation detail, or is there a reason that this
could not expand to
(append '(a b c d) (list 1 2))
> Why is the former more efficient than the latter? It looks like the former
> would have to construct the '(1 2) list twice, and the latter only once.
> And the '(a b c d) cons cells are only allocated once either way.
(I believe) It is more efficient, since there are fewer function calls.
I have had issues in the past with ,@ expanding to code that would have
exceeded the maximal evaluation depth, until I split it up and manually
used `append' that has the advantage of being implemented in C.
> Lynn
^ permalink raw reply [relevance 95%]
* Re: Adding package-vc to ELPA
2023-04-05 8:59 71% ` Philip Kaludercic
@ 2023-04-17 16:24 99% ` Philip Kaludercic
1 sibling, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-04-17 16:24 UTC (permalink / raw)
To: Jonas Bernoulli; +Cc: emacs-devel
Philip Kaludercic <philipk@posteo.net> writes:
> Jonas Bernoulli <jonas@bernoul.li> writes:
>
>> Philip Kaludercic <philipk@posteo.net> writes:
>>
>>> Jonas Bernoulli <jonas@bernoul.li> writes:
>>>
>>>> Hello,
>>>
>>> Hi, hope I can add a few useful comments here.
>>>
>>>> I would like to request that "package.el" be added to GNU Elpa as a
>>>> "core" package. This would make new features available to users who are
>>>> stuck on older Emacs releases and it would even bring us one step closer
>>>> to being able to make backward incompatible changes in the future.
>>>>
>>>> Some examples for why that would be desirable:
>>>>
>>>> - A recent addition that could be useful is the new "package-vc.el"
>>>> (which I think should be distributed as part of the `package' package,
>>>> but it could also be distributed as a separate core package).
>>>
>>> This will be difficult, since package-vc depends on the new "vc-clone"
>>> function, which would also have to be provided on ELPA to work.
>>
>> The simplest way to deal with that, while still making the latest
>> Package available to users of older Emacs releases, would be to *not*
>> include package-vc.el in the Package package.
>>
>> Going one step further we could make package-vc available as a separate
>> package. That would not be of much use *now*, but future improvements
>> would then be available to users of Emacs 29.
>
> I would in principle be interested in supporting this.
>
>> I had a look at vc-clone and a few vc-*-clone. They seem trivial
>> enough to backport, either as part of Compat or in package-vc.el.
I have put some more though into this, and I don't think adding the new
VC functionality to Compat or package-vc.el would be a good idea.
Beside vc-clone we would also need `vc-prepare-patch' and the
"last-change" method. What would be imaginable would be to add the
package to ELPA and make it depend on Emacs 29? Would that sound
useful?
^ permalink raw reply [relevance 99%]
* Re: Multithread or multiprocess in emacs??
@ 2023-04-17 13:37 98% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-04-17 13:37 UTC (permalink / raw)
To: Ergus; +Cc: emacs-devel
Ergus <spacibba@aol.com> writes:
> Hi:
>
> Very recently I have seen a code in an elpa package that starts async
> subprocesses; but instead of using make-process the package uses
> make-thread + process-file. This was to reduce the latency and some
> lagging (not evident in my system, but apparently it annoyed the
> package's author).
>
> So, my question is now: Has anyone measured the overhead created by
> make-process in critical parts of the code like flymake checkers, or
> ispell? and compared with creating new threads?
>
> If this is somehow significant maybe we may consider adding a helper
> thread or thread-pool for some purposes as now the C11 standard has the
> threads.h header.
Note that C11 threads are controversial[0], but also optional. Also, I
might be mistaken, but shouldn't Pthreads in some form be available on
platforms that Emacs runs on? Also, see (elisp) C Dialect.
There was an article[1] on the topic last year, which might be helpful.
[0] https://gustedt.wordpress.com/2012/10/14/c11-defects-c-threads-are-not-realizable-with-posix-threads/
[1] https://coredumped.dev/2022/05/19/a-vision-of-a-multi-threaded-emacs/.
> Is there any work already in this direction? How does Elisp handles
> multithreading?
>
> Best,
> Ergus
^ permalink raw reply [relevance 98%]
* Re: Would (Eval-when-compile (require 'treesit)) eliminate the need for (declare-function)s?
@ 2023-04-17 13:29 96% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-04-17 13:29 UTC (permalink / raw)
To: Ruijie Yu via Emacs development discussions.; +Cc: Yuan Fu, Ruijie Yu
Ruijie Yu via "Emacs development discussions." <emacs-devel@gnu.org>
writes:
> Yuan Fu <casouri@gmail.com> writes:
>
>> I’ve made the mistake of forgetting to add (declare-function treesit-xxx) when
>> using functions from treesit.c far too many times (sorry!). Since treesit.el
>> contains declare-function’s for every function in treesit.c, if we use
>> (eval-when-compile (require ’treesit)), would it eliminate the need for adding
>> declare-function’s? Should we do that?
>>
>> Yuan
>
> According to Eli
> (https://lists.gnu.org/archive/html/emacs-devel/2023-03/msg00673.html),
> no, it wouldn't work.
Strictly speaking, he was referring to removing `declare-function',
without replacing it with anything else. Replacing that with
(eval-when-compile (require 'treesit))
^
or "eval-and-compile"?
would be a different matter, since that file contains all the treesit
definitions, which I *believe* should be inherited by the requiring
file.
> [ Also, for some reason I cannot find the message using the msgid,
> 83ilezegs1.fsf@gnu.org? ]
[ I could access the message, but I am accessing the list via NNTP ]
^ permalink raw reply [relevance 96%]
* Re: Flymake backends
@ 2023-04-17 13:21 87% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-04-17 13:21 UTC (permalink / raw)
To: Ergus; +Cc: emacs-devel, mohkalex
Ergus <spacibba@aol.com> writes:
> Hi Philip:
>
>
> On Sun, Apr 16, 2023 at 07:17:08PM +0000, Philip Kaludercic wrote:
>>Ergus <spacibba@aol.com> writes:
>>
>>
>>There has been an attempt at abstracting over the current API in this
>>project: https://github.com/mohkale/flymake-collection
>>
>
> Thanks for replying. I am looking the flymake-collection project and I
> think that this is the kind of api we should offer to the user for
> applications development. Even that one or a simplified version of that.
>
> But sadly the project is not in elpa... so what should we do for that?
The topic was brought up
https://github.com/mohkale/flymake-collection/issues/2, and unless I was
mistaken, the author (Mohsin) has recently requested the CA. I (hope
to) have CC'ed him in this message, so he can comment on the issue.
My personal opinion is that the current macro[0] is too brittle, and it
would make sense to re-think the specific approach. Perhaps it could be
translated into a function, or we could make use of generic
functions/vc-like polymorphism to simplify the code.
[0] https://github.com/mohkale/flymake-collection/blob/release/src/flymake-collection-define.el#L134
>>> Because there are multiple functions the flymake code to simplify common
>>> tasks, but they are intended for private use cases.
>>>
>>> It may simplify integration with other build systems like ninja or
>>> cmake.
>>>
>>> So far something like flymake-quickdef, may help...
>>>
>>> 2) Is it desirable to add built-in backends to flymake for common/simple
>>> tools generally available like cppcheck, flake and so on... to improve
>>> the default experience and minimize configuration?
>>
>>I think that is of interest. In Emacs 29 shellcheck was added for
>>instance, and I don't see why other systems shouldn't be supported
>>either (setting aside legal issues).
>
> Then I think we should first provide a simpler api that we can maintain
> better (i.e. bring functions like flymake-collection-define-rx to
> vanilla)
>
> And then we can make a list of the common backends we can support:
>
> So far we only need to give a look to the backends supported by flycheck.
This might also be a useful starting point:
https://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis.
It conveniently lists the licences each program is distributed under.
I think it would be productive to focus on languages that do not have
LSP support, as Eglot usually does a good job at helping out there.
Things like configuration files might be good candidates.
>>> Best,
>>> Ergus
^ permalink raw reply [relevance 87%]
* Re: Flymake backends
@ 2023-04-16 19:17 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-04-16 19:17 UTC (permalink / raw)
To: Ergus; +Cc: emacs-devel
Ergus <spacibba@aol.com> writes:
> Hi:
>
> I have been using flymake instead of flycheck.
>
> Without any configuration I found that flymake does not show any issue;
> while flycheck shows multiple corrections. That's why flycheck contains
> a simpler interface to implement basic backends and consequently it has
> many buildt-in backends (i.e. cppcheck, gfortran etc).
>
> The question is:
>
> 1) Is there any effort around to improve the flymake api to add
> backends in a simpler way?
There has been an attempt at abstracting over the current API in this
project: https://github.com/mohkale/flymake-collection
> Because there are multiple functions the flymake code to simplify common
> tasks, but they are intended for private use cases.
>
> It may simplify integration with other build systems like ninja or
> cmake.
>
> So far something like flymake-quickdef, may help...
>
> 2) Is it desirable to add built-in backends to flymake for common/simple
> tools generally available like cppcheck, flake and so on... to improve
> the default experience and minimize configuration?
I think that is of interest. In Emacs 29 shellcheck was added for
instance, and I don't see why other systems shouldn't be supported
either (setting aside legal issues).
> Best,
> Ergus
^ permalink raw reply [relevance 99%]
* Re: What to use after #'define-package is now obsolete?
@ 2023-04-12 12:07 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-04-12 12:07 UTC (permalink / raw)
To: Chen Zhaoyang; +Cc: emacs-devel
Chen Zhaoyang <chenzhauyang@gmail.com> writes:
> Dear Friends,
>
> It seems that #'define-package is now obsolete (or has been for a while,
> https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=ade7a212a882540178d9504e7e0bd3be3bf1fd41):
>
> (defun define-package ( _name-string _version-string
> &optional _docstring _requirements
> &rest _extra-properties)
> "[...]"
> (declare (obsolete nil "29.1") (indent defun))
> (error "Don't call me!"))
>
> Does that mean from now on we just use the constructor
> #'package-desc-create in `foobar-pkg.el' files?
What are you trying to do? It might be that there are some
misconceptions to the point of the -pkg.el file. In general, you don't
need to write these files yourself, as they are either generated by a
package archive or a package manager.
^ permalink raw reply [relevance 99%]
* Re: How to install documentation in sub-directory with Package VC?
@ 2023-04-12 7:48 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-04-12 7:48 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: okamsn, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: emacs-devel@gnu.org
>> Date: Wed, 12 Apr 2023 07:27:23 +0000
>>
>> Okamsn <okamsn@protonmail.com> writes:
>>
>> > On 2023-04-10 13:39 UTC, Philip Kaludercic wrote:
>> >> Just pinging to see if you want to finish this or if I should modify the
>> >> patch? Seeing as the Emacs 29 release is coming closer, I'd rather have
>> >> this fixed sooner than later.
>> >
>> > Sorry about that. Please see the attached file, and please modify as
>> > you see fit. I am happy with it, but my only opinion is that all of the
>> > currently supported keys should be given in the manual, which this does.
>>
>> This looks good to me. Eli would you be ok with me pushing this to
>> emacs-29? There are no functional changes.
>
> Documentation changes are always okay on the release branch.
Great, done so.
>> I found a few more passive phrases, which I attempted to reformulate.
>> In case you think this is worth addressing, how does this sound:
>
> LGTM, thanks.
^ permalink raw reply [relevance 99%]
* Re: How to install documentation in sub-directory with Package VC?
@ 2023-04-12 7:27 61% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-04-12 7:27 UTC (permalink / raw)
To: Okamsn; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 751 bytes --]
Okamsn <okamsn@protonmail.com> writes:
> On 2023-04-10 13:39 UTC, Philip Kaludercic wrote:
>> Just pinging to see if you want to finish this or if I should modify the
>> patch? Seeing as the Emacs 29 release is coming closer, I'd rather have
>> this fixed sooner than later.
>
> Sorry about that. Please see the attached file, and please modify as
> you see fit. I am happy with it, but my only opinion is that all of the
> currently supported keys should be given in the manual, which this does.
This looks good to me. Eli would you be ok with me pushing this to
emacs-29? There are no functional changes.
I found a few more passive phrases, which I attempted to reformulate.
In case you think this is worth addressing, how does this sound:
[-- Attachment #2: Type: text/plain, Size: 2758 bytes --]
diff --git a/doc/emacs/package.texi b/doc/emacs/package.texi
index 205a14c6c4d..2b03399b0a7 100644
--- a/doc/emacs/package.texi
+++ b/doc/emacs/package.texi
@@ -586,8 +586,8 @@ Fetching Package Sources
To install a package from source, Emacs must know where to get the
package's source code (such as a code repository) and basic
information about the structure of the code (such as the main file in
-a multi-file package). These properties are described by a package's
-@dfn{specification}.
+a multi-file package). A @dfn{package specification} describes these
+properties.
When supported by a package archive (@pxref{Package
Archives,,,elisp, The Emacs Lisp Reference Manual}), Emacs can
@@ -603,12 +603,12 @@ Fetching Package Sources
@end group
@end example
- A package's specification can also be given manually as the first
-argument to @code{package-vc-install}. This allows you to install
-source packages from locations other than the known archives listed in
-the user option @code{package-archives}. A package specification is a
-list of the form @code{(@var{name} . @var{spec})}, in which @var{spec}
-should be a property list using any of the keys in the table below.
+ The first argument to @code{package-vc-install} may also be a
+package specification. This allows you to install source packages
+from locations other than the known archives listed in the user option
+@code{package-archives}. A package specification is a list of the
+form @code{(@var{name} . @var{spec})}, in which @var{spec} should be a
+property list using any of the keys in the table below.
For definitions of basic terms for working with code repositories and
version control systems, see @ref{VCS Concepts,,,emacs, The GNU Emacs
@@ -620,8 +620,8 @@ Fetching Package Sources
fetch the package's source code.
@item :branch
-A string providing the revision of the code to install. This is not
-to be confused with a package's version number.
+A string providing the revision of the code to install. Do not
+confuse this with a package's version number.
@item :lisp-dir
A string providing the repository-relative name of the directory to
@@ -641,9 +641,9 @@ Fetching Package Sources
@item :vc-backend
A symbol naming the VC backend to use for downloading a copy of the
package's repository (@pxref{Version Control Systems,,,emacs, The GNU
-Emacs Manual}). If omitted, a guess will be made based on the
-provided URL, or, failing that, the process will fall back onto the
-value of @code{package-vc-default-backend}.
+Emacs Manual}). If omitted, Emacs will attempt to make a guess based
+on the provided URL, or, failing that, the process will fall back onto
+the value of @code{package-vc-default-backend}.
@end table
@example
[-- Attachment #3: Type: text/plain, Size: 6424 bytes --]
> From 07c00d430a3b213a0b8a8e4f107b8b6e4d54a9fd Mon Sep 17 00:00:00 2001
> From: Earl Hyatt <okamsn@protonmail.com>
> Date: Mon, 27 Mar 2023 20:57:31 -0400
> Subject: [PATCH] Add more documentation for the keys of
> `package-vc-selected-packages`.
>
> * doc/emacs/package.texi (Specifying Package Sources): List the
> accepted keys in a new subsection of Fetching Package Sources.
>
> * lisp/emacs-lisp/package-vc.el (package-vc-selected-packages):
> - Mention the `:doc` key. Add the `:doc` key to the Customize form.
> - Mention the new Info node.
> - Correct "TexInfo" to "Texinfo".
> - Avoid Git-specific terms for the description of `:branch`.
> - Mention guessing `:vc-backend` based on the URL.
> ---
> doc/emacs/package.texi | 77 +++++++++++++++++++++++++++++++++++
> lisp/emacs-lisp/package-vc.el | 30 ++------------
> 2 files changed, 81 insertions(+), 26 deletions(-)
>
> diff --git a/doc/emacs/package.texi b/doc/emacs/package.texi
> index 7a2bc11d03c..205a14c6c4d 100644
> --- a/doc/emacs/package.texi
> +++ b/doc/emacs/package.texi
> @@ -578,3 +578,80 @@ Fetching Package Sources
> and initializes the code. Note that you might have to use
> @code{package-vc-refresh} to repeat the initialization and update the
> autoloads.
> +
> +@subsection Specifying Package Sources
> +@cindex package specification
> +@cindex specification, for source packages
> +
> + To install a package from source, Emacs must know where to get the
> +package's source code (such as a code repository) and basic
> +information about the structure of the code (such as the main file in
> +a multi-file package). These properties are described by a package's
> +@dfn{specification}.
> +
> + When supported by a package archive (@pxref{Package
> +Archives,,,elisp, The Emacs Lisp Reference Manual}), Emacs can
> +automatically download a package's specification from said archive.
> +If the first argument passed to @code{package-vc-install} is a symbol
> +naming a package, then Emacs will use the specification provided by
> +the archive for that package.
> +
> +@example
> +@group
> +;; Emacs will download BBDB's specification from GNU ELPA:
> +(package-vc-install 'bbdb)
> +@end group
> +@end example
> +
> + A package's specification can also be given manually as the first
> +argument to @code{package-vc-install}. This allows you to install
> +source packages from locations other than the known archives listed in
> +the user option @code{package-archives}. A package specification is a
> +list of the form @code{(@var{name} . @var{spec})}, in which @var{spec}
> +should be a property list using any of the keys in the table below.
> +
> +For definitions of basic terms for working with code repositories and
> +version control systems, see @ref{VCS Concepts,,,emacs, The GNU Emacs
> +Manual}.
> +
> +@table @code
> +@item :url
> +A string providing the URL that specifies the repository from which to
> +fetch the package's source code.
> +
> +@item :branch
> +A string providing the revision of the code to install. This is not
> +to be confused with a package's version number.
> +
> +@item :lisp-dir
> +A string providing the repository-relative name of the directory to
> +use for loading the Lisp sources, which defaults to the root directory
> +of the repository.
> +
> +@item :main-file
> +A string providing the main file of the project, from which to gather
> +package metadata. If not given, the default is the package name with
> +".el" appended to it.
> +
> +@item :doc
> +A string providing the repository-relative name of the documentation
> +file from which to build an Info file. This can be a Texinfo file or
> +an Org file.
> +
> +@item :vc-backend
> +A symbol naming the VC backend to use for downloading a copy of the
> +package's repository (@pxref{Version Control Systems,,,emacs, The GNU
> +Emacs Manual}). If omitted, a guess will be made based on the
> +provided URL, or, failing that, the process will fall back onto the
> +value of @code{package-vc-default-backend}.
> +@end table
> +
> +@example
> +@group
> +;; Specifying information manually:
> +(package-vc-install
> + '(bbdb :url "https://git.savannah.nongnu.org/git/bbdb.git"
> + :lisp-dir "lisp"
> + :doc "doc/bbdb.texi"))
> +@end group
> +@end example
> diff --git a/lisp/emacs-lisp/package-vc.el b/lisp/emacs-lisp/package-vc.el
> index 253b35f1f1a..1d29f8dbbd1 100644
> --- a/lisp/emacs-lisp/package-vc.el
> +++ b/lisp/emacs-lisp/package-vc.el
> @@ -145,32 +145,9 @@ package-vc-selected-packages
>
> - nil, if any package version can be installed;
> - a version string, if that specific revision is to be installed;
> -- a property list, describing a package specification. Valid
> - key/value pairs are
> -
> - `:url' (string)
> - The URL of the repository used to fetch the package source.
> -
> - `:branch' (string)
> - If given, the name of the branch to checkout after cloning the directory.
> -
> - `:lisp-dir' (string)
> - The repository-relative name of the directory to use for loading the Lisp
> - sources. If not given, the value defaults to the root directory
> - of the repository.
> -
> - `:main-file' (string)
> - The main file of the project, relevant to gather package metadata.
> - If not given, the assumed default is the package name with \".el\"
> - appended to it.
> -
> - `:vc-backend' (symbol)
> - A symbol of the VC backend to use for cloning the package. The
> - value ought to be a member of `vc-handled-backends'. If omitted,
> - `vc-clone' will fall back onto the archive default or on
> - `package-vc-default-backend'.
> -
> - All other keys are ignored.
> +- a property list, describing a package specification. For more
> + details, please consult the subsection \"Specifying Package
> + Sources\" in the Info node `(emacs)Fetching Package Sources'.
>
> This user option will be automatically updated to store package
> specifications for packages that are not specified in any
> @@ -184,6 +161,7 @@ package-vc-selected-packages
> (:branch string)
> (:lisp-dir string)
> (:main-file string)
> + (:doc string)
> (:vc-backend symbol)))))
> :version "29.1")
^ permalink raw reply related [relevance 61%]
* Re: How to install documentation in sub-directory with Package VC?
2023-04-06 15:42 67% ` Philip Kaludercic
@ 2023-04-10 13:39 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-04-10 13:39 UTC (permalink / raw)
To: Okamsn; +Cc: emacs-devel
Just pinging to see if you want to finish this or if I should modify the
patch? Seeing as the Emacs 29 release is coming closer, I'd rather have
this fixed sooner than later.
Philip Kaludercic <philipk@posteo.net> writes:
> Okamsn <okamsn@protonmail.com> writes:
>
>> On 2023-04-05 07:30 UTC, Philip Kaludercic wrote:
>>>> + To install a package from source, Emacs must know where to get the
>>>> +package's source code (such as a code repository) and basic
>>>> +information about the structure of the code (such as the main file in
>>>> +a multi-file package). These things are described by a package's
>>> ^
>>> a bit informal? I think you can just
>>> drop the word and still convey the same
>>> information.
>>
>> I acknowledge that "things" is unspecific, but I do think that the
>> paragraph flows better with a noun there. What if "things" was swapped
>> out for "properties"? I think that it would work well with the use of
>> "property list" a few sentences later.
>
> That sounds good!
>
>>
>>>> + When supported by a package archive (@pxref{Package
>>>> +Archives,,,elisp, The Emacs Lisp Reference Manual}), Emacs can
>>>> +automatically download a package's specification from said archive.
>>>
>>> Not sure if this might be confusing. package-vc has heuristics to try
>>> and guess how to install a package, so it is /possible/ but not
>>> /reliable/ to install a package from a third-party archive like MELPA.
>>> Then again, perhaps we don't have to mention that at all in the manual,
>>> so as to not promote an unreliable trick.
>>
>> I wasn't aware of these heuristics. In this paragraph, I was trying to
>> describe where the known specifications come from, as in the
>> "elpa-package.eld" file.
>
> The point here is that you can install a package listed in an archive,
> even though the archive doesn't generate a elpa-package.eld. It works
> most of the time, in the remaining cases the heuristics help but it is
> not ideal. Should this be explained?
>
>>>> +@item :main-file
>>>> +A string containing the main file of the project, from which to gather
>>>> +package metadata. If not given, the default is the package name with
>>>> +".el" appended to it.
>>>
>>> (This is true most of the time, but if you check out what
>>> `package-vc--main-file' does, then you will see that this is not
>>> necessary. Again, I don't think this implementation detail is worth
>>> documenting publicly.)
>>
>> Are you saying that you don't want to describe the heuristic, or that
>> you don't want to describe the default behavior? I would like to keep
>> the mention of the default behavior.
>
> I don't want to document the heuristic, as IMO this is an implementation
> detail. Lets keep this the way it is.
>
>>>> + A package's specification can also be given manually as the first
>>>> +argument to @code{package-vc-install}. This allows you to install
>>>> +source packages from locations other than the known archives listed in
>>>> +the user option @code{package-archives}. A package specification is a
>>>> +list of the form @code{(@var{name} . @var{spec})}, in which @var{spec}
>>>> +should be a property list using any of the following keys.
>>>>
>>>> +For definitions of basic terms for working with code repositories and
>>>> +version control systems, see @xref{VCS Concepts,,,emacs, The GNU Emacs
>>>> +Manual}.
>>>
>>> Should this paragraph be moved down below the table? Otherwise the "any
>>> of the following" reads funnily.
>>
>> I don't think that this paragraph should be moved to after the table. In
>> my opinion, it is better to have the link, which defines the terms,
>> placed before the using of the terms.
>
> Another idea would be to mark the paragraph up using @quotation,
> @cartouche or a Footnote?
>
>> Instead, what if the sentence ended like "using any of the keys in the
>> table below"?
>
> That would also be fine.
>
>>>> diff --git a/lisp/emacs-lisp/package-vc.el b/lisp/emacs-lisp/package-vc.el
>>>> index 253b35f1f1a..cbc9a1ecece 100644
>>>> --- a/lisp/emacs-lisp/package-vc.el
>>>> +++ b/lisp/emacs-lisp/package-vc.el
>>>> @@ -152,25 +152,31 @@ package-vc-selected-packages
>>>
>>> I believe I mentioned this before, but what do you think about just
>>> linking to the manual, and not duplicating the information here and
>>> there? It would make maintenance easier, but might not be nice for
>>> users on systems that do not come installed with documentation like
>>> Debian... Then again, this wouldn't be the only place where this would
>>> affect users.
>>
>> Some of the information in the documentation string is probably not
>> relevant for users wishing to give their own specification. For example,
>> the information about a package archive's default VC backend that Eli
>> Zaretskii pointed out. Would you like to limit the information in the
>> table to what is relevant for giving a manual specification, or should
>> the table be a description of the behavior for all specifications?
>
> What I had in mind was just replace the ad-hoc list in the docstring
> with a reference to the new section in the manual:
>
> diff --git a/lisp/emacs-lisp/package-vc.el b/lisp/emacs-lisp/package-vc.el
> index ddc7ec4679b..6fe30e08830 100644
> --- a/lisp/emacs-lisp/package-vc.el
> +++ b/lisp/emacs-lisp/package-vc.el
> @@ -147,32 +147,9 @@ package-vc-selected-packages
>
> - nil, if any package version can be installed;
> - a version string, if that specific revision is to be installed;
> -- a property list, describing a package specification. Valid
>
> - key/value pairs are
> -
> - `:url' (string)
> - The URL of the repository used to fetch the package source.
> -
> - `:branch' (string)
> - If given, the name of the branch to checkout after cloning the directory.
> -
> - `:lisp-dir' (string)
> - The repository-relative name of the directory to use for loading the Lisp
> - sources. If not given, the value defaults to the root directory
> - of the repository.
> -
> - `:main-file' (string)
> - The main file of the project, relevant to gather package metadata.
> - If not given, the assumed default is the package name with \".el\"
> - appended to it.
> -
> - `:vc-backend' (symbol)
> - A symbol of the VC backend to use for cloning the package. The
> - value ought to be a member of `vc-handled-backends'. If omitted,
> - `vc-clone' will fall back onto the archive default or on
> - `package-vc-default-backend'.
> -
> - All other keys are ignored.
> +- a property list, describing a package specification. For more
> + details please consult the \"Package specification\" subsection
> + under the Info node `(emacs) Fetching Package Sources'.
>
> This user option will be automatically updated to store package
> specifications for packages that are not specified in any
>
>
>> If it is made more general, then I have no strong reason to disagree
>> with keeping the information in only one place. However, I will defer to
>> others on this.
>
> I am just making suggestions here and am interested in what you think.
> My opinion isn't worth more than yours.
^ permalink raw reply [relevance 99%]
* Re: [elpa] main b8d4806d47: * elpa-packages (switchy-window): Ignore LICENSE and Makefile
@ 2023-04-10 9:14 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-04-10 9:14 UTC (permalink / raw)
To: Tassilo Horn; +Cc: emacs-devel
Tassilo Horn <tsdh@gnu.org> writes:
> Hi Philip,
>
> I think I need some ELPA help. The package still hasn't appeared.
>
> Yesterday evening, I got a mail with a build error caused by the
> Copyright notice still mentioning myself and not the FSF. I have fixed
> that but still the package isn't online (and my experience with, e.g.,
> AUCTeX suggests ELPA builds quite frequently nowadays). Even more, I
> cannot build the package locally and don't understand the error:
[...]
> Why can't it find
> /home/horn/Repos/el/elpa/packages/switchy-window/switchy-window.el which
> actually does exist?
>
> And the local build aside, to I need to increment the Version in order
> to trigger another try by ELPA after a failure?
I suspect that this is the issue. IIRC elpa-admin picks the latest
commit that incremented the Version tag for packaging, then checks if
the copyright is OK. That is probably also the reason why on my end the
devel build works (which uses the latest commit), but the release
doesn't.
> Bye,
> Tassilo
>
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: How to install documentation in sub-directory with Package VC?
@ 2023-04-09 21:55 84% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-04-09 21:55 UTC (permalink / raw)
To: Jonas Bernoulli; +Cc: Okamsn, emacs-devel
Jonas Bernoulli <jonas@bernoul.li> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>>> We only provide :url, and where appropriate :branch, :vc-backend and
>>> :maintainer.
>>
>> :maintainer is currently not used
>
> Removed.
>
> Could you please ping me when you add new properties?
I don't see the point of adding support for it to package-vc, that is to
say that I don't know what would want to make use of it.
>> (TBH I am not sure what the point of it is in elpa-admin to begin
>> with),
>
> Sending emails to a package's maintainer. It is used to send every
> pushed commit for example.
Every commit? From what it see being done in elpa-admin.el it is
invoked when a package fails to build and on releases (as is the case
when a maintainer is listed in the package header).
>>> We don't set :doc or :lisp-dir (yet?).
>>
>> Do you think it could be possible to support :doc and :lisp-dir. IIUC
>> the issue is that MELPA only accepts a list of files to include when
>> bundling a package (:files) and the build system would have to infer
>> what what is?
>
> Why is :doc needed? I think package-install simply runs makeinfo on all
> texi files, but of course it can rely on them being at the top-level.
I don't see that package-install attempts anything like that.
> It might end up trying (and failing) to directly process gpl.texi and
> similar. But still, cannot package-vc simply do that too?
Sure, that can be done. There was just no need for that up until now
considering that ELPA added :doc provides the information.
> The value of :doc can also be an org file and we cannot just blindly try
> to transcode *all* org files to texi. But Melpa doesn't support
> exporting ort to texi, so packages distributed there cannot assume that
> that happens. (I wish Melpa supported this and I actually implemented
> it, but the main Melpa maintainers didn't want to merge it for security
> reasons.)
Hmm, understandable. As long as MELPA wouldn't install a manual in
these cases, I think it is tolerable if package-vc doesn't do so either.
> I am not sure determining :lisp-dir from :files on the archive's side,
> is easier and/or more reliable than package-vc doing it itself based
> solely on what it finds in the latest commit. In Borg I use "if lisp/
> exists, then use that, else use ./" and that works for 99% of all
> packages.
What package-vc does is check both "lisp" and "src" checking if they
contain .el files. Good to know that this works well enough.
> I think it would be better to first try to add some heuristics to
> package-vc. If that doesn't work well enough, we can still later
> make package-build generate more elpa-admin-style metadata.
Yeah, it should all work well enough for now, I guess the only way to
improve this is to deal with real-world edge-cases that are discovered
over time.
--
Philip Kaludercic
^ permalink raw reply [relevance 84%]
* Re: [elpa] main b8d4806d47: * elpa-packages (switchy-window): Ignore LICENSE and Makefile
[not found] ` <20230409182153.93887C13A8C@vcs2.savannah.gnu.org>
@ 2023-04-09 18:40 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-04-09 18:40 UTC (permalink / raw)
To: emacs-devel; +Cc: Tassilo Horn
Tassilo Horn <tsdh@gnu.org> writes:
> branch: main
> commit b8d4806d471f8f323254ef58efe39d021d8443d2
> Author: Tassilo Horn <tsdh@gnu.org>
> Commit: Tassilo Horn <tsdh@gnu.org>
>
> * elpa-packages (switchy-window): Ignore LICENSE and Makefile
> ---
> elpa-packages | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/elpa-packages b/elpa-packages
> index a12f009930..86c91734b8 100644
> --- a/elpa-packages
> +++ b/elpa-packages
> @@ -631,7 +631,8 @@
> :manual-sync t
> )
> (switchy-window :url "https://git.sr.ht/~tsdh/switchy-window"
> - :readme "README.md")
> + :readme "README.md"
> + :ignored-files ("LICENSE" "Makefile"))
Shouldn't the .elpaignore handle this?
> (sxhkdrc-mode :url "https://git.sr.ht/~protesilaos/sxhkdrc-mode"
> :readme "README.md"
> :ignored-files ("COPYING"))
>
>
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Request to add Package to GNU ELPA
@ 2023-04-09 17:27 48% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-04-09 17:27 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Jonas Bernoulli, emacs-devel, Eli Zaretskii
[-- Attachment #1: Type: text/plain, Size: 403 bytes --]
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> As mentioned in my other message, we are also missing
>> `loaddefs-generate'. I am not exactly sure what motivated the change,
>> so I don't know if checking the version and doing what was done prior to
>> 29 would be enough:
>
> I'd check (fboundp 'loaddefs-generate) to select between the old and the
> new code.
Ok, I have modified the patch:
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Prepare-package.el-to-be-published-on-GNU-ELPA.patch --]
[-- Type: text/x-diff, Size: 6070 bytes --]
From e63ac132cc8d220e642836f8f246d82147793f57 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Wed, 5 Apr 2023 23:16:39 +0200
Subject: [PATCH] Prepare package.el to be published on GNU ELPA
* lisp/emacs-lisp/package.el: Add Compat as a dependency.
(package--native-compile-async): Check if 'native-comp-available-p' is
bound.
(lm-homepage, lm-website): Use backwards-compatible alias
'lm-homepage'.
(package-buffer-info): Call 'lm-maintainer' if 'lm-maintainers' is not
defined.
(describe-package-1): Avoid using 'make-separator-line' if not bound.
(package-report-bug): Expand 'custom--standard-value' definition.
For the background and motivation behind these changes, please consult
this thread:
https://lists.gnu.org/archive/html/emacs-devel/2023-03/msg00995.html.
---
lisp/emacs-lisp/package.el | 51 ++++++++++++++++++++++++--------------
1 file changed, 32 insertions(+), 19 deletions(-)
diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el
index 0258ed52bee..2657a4f98b4 100644
--- a/lisp/emacs-lisp/package.el
+++ b/lisp/emacs-lisp/package.el
@@ -5,9 +5,12 @@
;; Author: Tom Tromey <tromey@redhat.com>
;; Daniel Hackney <dan@haxney.org>
;; Created: 10 Mar 2007
-;; Version: 1.1.0
+;; Version: 1.1.1
;; Keywords: tools
-;; Package-Requires: ((tabulated-list "1.0"))
+;; Package-Requires: ((emacs "27.1") (compat "29.1.0.0"))
+
+;; This is a GNU ELPA :core package. Avoid functionality that is not
+;; compatible with the version of Emacs recorded above.
;; This file is part of GNU Emacs.
@@ -147,6 +150,7 @@
(eval-when-compile (require 'subr-x))
(eval-when-compile (require 'epg)) ;For setf accessors.
(eval-when-compile (require 'inline)) ;For `define-inline'
+(require 'compat nil 'noerror)
(require 'seq)
(require 'tabulated-list)
@@ -1084,16 +1088,20 @@ package-generate-autoloads
(autoload-timestamps nil)
(backup-inhibited t)
(version-control 'never))
- (loaddefs-generate
- pkg-dir output-file nil
- (prin1-to-string
- '(add-to-list
- 'load-path
- ;; Add the directory that will contain the autoload file to
- ;; the load path. We don't hard-code `pkg-dir', to avoid
- ;; issues if the package directory is moved around.
- (or (and load-file-name (file-name-directory load-file-name))
- (car load-path)))))
+ (if (fboundp 'loaddefs-generate)
+ (loaddefs-generate
+ pkg-dir output-file nil
+ (prin1-to-string
+ '(add-to-list
+ 'load-path
+ ;; Add the directory that will contain the autoload file to
+ ;; the load path. We don't hard-code `pkg-dir', to avoid
+ ;; issues if the package directory is moved around.
+ (or (and load-file-name (file-name-directory load-file-name))
+ (car load-path)))))
+ (with-suppressed-warnings ((obsolete package-autoload-ensure-default-file))
+ (package-autoload-ensure-default-file output-file))
+ (make-directory-autoloads pkg-dir output-file))
(let ((buf (find-buffer-visiting output-file)))
(when buf (kill-buffer buf)))
auto-name))
@@ -1124,7 +1132,8 @@ package--native-compile-async
"Native compile installed package PKG-DESC asynchronously.
This assumes that `pkg-desc' has already been activated with
`package-activate-1'."
- (when (native-comp-available-p)
+ (when (and (fboundp 'native-comp-available-p)
+ (native-comp-available-p))
(let ((warning-minimum-level :error))
(native-compile-async (package-desc-dir pkg-desc) t))))
@@ -1160,9 +1169,10 @@ package--prepare-dependencies
(declare-function lm-header "lisp-mnt" (header))
(declare-function lm-header-multiline "lisp-mnt" (header))
-(declare-function lm-website "lisp-mnt" (&optional file))
+(declare-function lm-homepage "lisp-mnt" (&optional file))
(declare-function lm-keywords-list "lisp-mnt" (&optional file))
(declare-function lm-maintainers "lisp-mnt" (&optional file))
+(declare-function lm-maintainer "lisp-mnt" (&optional file))
(declare-function lm-authors "lisp-mnt" (&optional file))
(defun package-buffer-info ()
@@ -1195,7 +1205,7 @@ package-buffer-info
(or (lm-header "package-version") (lm-header "version")))
(pkg-version (package-strip-rcs-id version-info))
(keywords (lm-keywords-list))
- (website (lm-website)))
+ (website (lm-homepage)))
(unless pkg-version
(if version-info
(error "Unrecognized package version: %s" version-info)
@@ -1211,7 +1221,10 @@ package-buffer-info
:maintainer
;; For backward compatibility, use a single string if there's only
;; one maintainer (the most common case).
- (let ((maints (lm-maintainers))) (if (cdr maints) maints (car maints)))
+ (if (fboundp 'lm-maintainers)
+ (let ((maints (lm-maintainers)))
+ (if (cdr maints) maints (car maints)))
+ (lm-maintainer))
:authors (lm-authors)))))
(defun package--read-pkg-desc (kind)
@@ -2302,8 +2315,6 @@ package-strip-rcs-id
;; to make sure we use a "canonical name"!
(if l (package-version-join l)))))
-(declare-function lm-website "lisp-mnt" (&optional file))
-
;;;###autoload
(defun package-install-from-buffer ()
"Install a package from the current buffer.
@@ -4571,7 +4582,9 @@ package-report-bug
(dolist (ent (get (cdr group) 'custom-group))
(when (and (custom-variable-p (car ent))
(boundp (car ent))
- (not (eq (custom--standard-value (car ent))
+ (not (eq (if (fboundp 'custom--standard-value)
+ (custom--standard-value (car ent))
+ (eval (car (get (car ent) 'standard-value)) t))
(default-toplevel-value (car ent))))
(file-in-directory-p (car group) (package-desc-dir desc)))
(push (car ent) vars))))
--
2.30.2
[-- Attachment #3: Type: text/plain, Size: 62 bytes --]
Eli, are you OK with this being done?
--
Philip Kaludercic
^ permalink raw reply related [relevance 48%]
* Re: [GNU ELPA] I'd like to add switchy.el: a last-recently-used window switcher
@ 2023-04-09 10:30 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-04-09 10:30 UTC (permalink / raw)
To: Tassilo Horn; +Cc: emacs-devel
Tassilo Horn <tsdh@gnu.org> writes:
> Thanks Philip,
>
> I'll address your comments before adding the package.
Great, looking forward to seeing the package on ELPA :)
> Bye,
> Tassilo
>
> 09.04.2023 10:56:28 Philip Kaludercic <philipk@posteo.net>:
>
>> Tassilo Horn <tsdh@gnu.org> writes:
>>
>>> Hi all,
>>>
>>> I've written a small utility called switchy.el which I'd like to add to
>>> GNU ELPA. I can do that on my own but wanted to give you a chance for
>>> commenting first. I'm attaching the file below.
>>>
>>> In essence, the single command provided is `switchy-window' which is
>>> similar to `other-window' except that it switches to other windows in
>>> last-recently-used order instead of top-to-bottom-left-to-right order.
>>> With quick consecutive invocations you can reach any window but if you
>>> have a small delay between invocations (controlled by the single
>>> defcustom `switchy-delay'), you toggle between the two last recently
>>> used windows.
>>>
>>> Bye,
>>> Tassilo
>>>
>>> ;;; switchy.el --- A last-recently-used window switcher -*- lexical-binding: t; -*-
>>> ;;
>>> ;; Copyright (C) 2023 Tassilo Horn
>>> ;;
>>> ;; Author: Tassilo Horn <tsdh@gnu.org>
>>> ;; Version: 1.0
>>> ;; Keywords: windows
>>> ;; Homepage: https://sr.ht/~tsdh/switchy/
>>> ;; Repository: https://git.sr.ht/~tsdh/switchy
>>> ;; Package-Requires: ((emacs "25.1") (compat "29.1.3.4"))
>>
>> If you are to use compat 29.1.0.0 or newer then you also have to require
>> it!
>>
>>> ;; SPDX-License-Identifier: GPL-3.0-or-later
>>> ;;
>>> ;; This file is NOT part of GNU Emacs.
>>
>> If added to GNU ELPA, this should be change to "... is part of GNU
>> Emacs", right?
>>
>>> ;;
>>> ;; This program is free software; you can redistribute it and/or
>>> ;; modify it under the terms of the GNU General Public License
>>> ;; as published by the Free Software Foundation; either version 3
>>> ;; of the License, or (at your option) any later version.
>>> ;;
>>> ;; This program is distributed in the hope that it will be useful,
>>> ;; but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> ;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>>> ;; GNU General Public License for more details.
>>> ;;
>>> ;; You should have received a copy of the GNU General Public License
>>> ;; along with this program. If not, see <http://www.gnu.org/licenses/>.
>>> ;;
>>> ;;; Commentary:
>>> ;;
>>> ;; Switchy is a last-recently-used window switcher. It suits my personal Emacs
>>> ;; layout and workflow where I usually have at most two editing windows but up
>>> ;; to three side-windows which I have to select only seldomly.
>>> ;;
>>> ;; The idea of switchy is simple: when you invoke `switchy-window' in quick
>>> ;; succession, it will switch to one window after the other in
>>> ;; last-recently-used order. Once you stop switching for long enough time
>>> ;; (`switchy-delay', 1.5 seconds by default), the selected window gets locked
>>> ;; in, i.e., its LRU timestamp is updated and this switching sequence is ended.
>>> ;; Thusly, you can toggle between two windows simply by invoking
>>> ;; `switchy-window', waiting at least `switchy-delay', and then invoking
>>> ;; `switchy-window' again to switch back to the original window.
>>> ;;
>>> ;; Activate `switchy-minor-mode' which tracks window changes and bind
>>> ;; `switchy-window' to a key of your liking in `switchy-minor-mode-map' (or
>>> ;; globally, see the variable's docstring for examples).
>>> ;;
>>> ;; Hint: Since the order of window switching is not as obvious as it is with
>>> ;; `other-window', adding a bit visual feedback to window selection changes can
>>> ;; be helpful. That can be done easily with the stock Emacs pulse.el, e.g.:
>>> ;;
>>> ;; (add-hook 'window-selection-change-functions
>>> ;; (lambda (frame)
>>> ;; (when (eq frame (selected-frame))
>>> ;; (pulse-momentary-highlight-one-line))))
>>>
>>>
>>> ;;; Code:
>>>
>>> (defgroup switchy nil
>>> "Switchy is a last-recently-used window-switcher."
>>> :group 'windows)
>>>
>>> (defvar switchy--tick-counter 0
>>> "Values of this counter represent the last-recently-used order of windows.
>>> Only for internal use.")
>>>
>>> (defvar switchy--tick-alist nil
>>> "An alist with entries (WINDOW . TICK).
>>> A higher TICK value means a window has more recently been visited.
>>> Only for internal use.")
>>>
>>> (defcustom switchy-delay 1.5
>>> "Number of seconds before the current window gets locked in.
>>> If more time elapses between consecutive invocations of
>>> `switchy-window', the current window's tick (timestamp) is
>>> updated in `switchy--tick-alist' and the current switching cycle
>>> ends."
>>> :type 'number)
>>>
>>> (defvar switchy--timer nil
>>> "The timer locking in the current window after `switchy-delay' seconds.
>>> Only for internal use.")
>>>
>>> (defvar switchy--visited-windows nil
>>> "The windows having already been visited in the current switching cycle.")
>>>
>>> (defun switchy--on-window-selection-change (&optional frame)
>>> "Record the next `switchy--tick-counter' value for the selected window of FRAME.
>>> Meant to be used in `window-selection-change-functions' which is
>>> arranged by `switchy-minor-mode'."
>>> (when (eq frame (selected-frame))
>>> (when switchy--timer
>>> (cancel-timer switchy--timer))
>>> (setq switchy--timer (run-at-time
>>> switchy-delay nil
>>> (lambda ()
>>> (setf (alist-get (selected-window)
>>> switchy--tick-alist)
>>> (cl-incf switchy--tick-counter))
>>> (setq switchy--visited-windows nil))))))
>>>
>>> (defun switchy-window (&optional arg)
>>> "Switch to other windows in last-recently-used order.
>>> If prefix ARG is given, use least-recently-used order.
>>>
>>> If the time between consecutive invocations is smaller than
>>> `switchy-delay' seconds, selects one after the other window in
>>> LRU order and cycles when all windows have been visited. If
>>> `switchy-delay' has passed, the current switching cycle ends and
>>> the now selected window gets its tick updated (a kind of
>>> timestamp)."
>>> (interactive)
>>>
>>> (unless switchy-minor-mode
>>> (user-error "switchy-window requires `switchy-minor-mode' being active"))
>>>
>>> ;; Remove dead windows.
>>> (setq switchy--tick-alist (seq-filter
>>> (lambda (e)
>>> (window-live-p (car e)))
>>> switchy--tick-alist))
>>> ;; Add windows never selected.
>>> (dolist (win (window-list (selected-frame)))
>>> (unless (assq win switchy--tick-alist)
>>> (setf (alist-get win switchy--tick-alist) 0)))
>>
>> The setf is strictly speaking unnecessary here and causes an accidental
>> O(n^2) slowdown, since you traverse the list once to check if it has an
>> entry and then traverse it again to check if you can set 0 to an
>> existing entry. You could also just push a cons-cell to the beginning.
>> Then again, this is all bounded by the maximal number of windows that
>> someone has open so it doesn't matter in practice.
>>
>>> ;; Ensure the current window is marked as visited.
>>> (setq switchy--visited-windows (cons (selected-window)
>>> switchy--visited-windows))
>>>
>>> (let ((win-entries (seq-filter
>>> (lambda (e)
>>> (let ((win (car e)))
>>> (and (eq (window-frame win) (selected-frame))
>>> (or (minibuffer-window-active-p win)
>>> (not (eq win (minibuffer-window
>>> (selected-frame)))))
>>> (not (memq win switchy--visited-windows)))))
>>> switchy--tick-alist)))
>>> (if win-entries
>>> (when-let ((win (car (seq-reduce (lambda (x e)
>>> (if (and x (funcall (if arg #'< #'>)
>>> (cdr x) (cdr e)))
>>> x
>>> e))
>>> win-entries nil))))
>>>
>>> (progn
>>
>> Why the progn if you are using when-let?
>>
>>> (setq switchy--visited-windows (cons win switchy--visited-windows))
>>> (select-window win)))
>>> ;; Start a new cycle if we're not at the start already, i.e., we visited
>>> ;; just one (the current) window.
>>> (when (> (length switchy--visited-windows) 1)
>>
>> Or (length> switchy--visited-windows 1)?
>>
>>> (setq switchy--visited-windows nil)
>>> (switchy-window)))))
>>>
>>> (defvar switchy-minor-mode-map (make-sparse-keymap)
>>> "The mode map of `switchy-minor-mode'.
>>> No keys are bound by default. Bind the main command
>>> `switchy-window' to a key of your liking, e.g.,
>>>
>>> ;; That\\='s what I use.
>>> (keymap-set switchy-minor-mode-map \"C-<\" #\\='switchy-window)
>>
>> If you are already making use of keymap-set, you might as well define
>> the map itself using defvar-keymap (Compat provides it).
>>
>>> ;; Or as a substitute for `other-window'.
>>> (add-hook \\='switchy-minor-mode-hook
>>> (lambda ()
>>> (if switchy-minor-mode
>>> (keymap-global-set \"<remap> <other-window>\"
>>> #\\='switchy-window)
>>> (keymap-global-unset \"<remap> <other-window>\"))))")
>>>
>>> (define-minor-mode switchy-minor-mode
>>> "Activates recording of window selection ticks.
>>> Those are the timestamps for figuring out the last-recently-used
>>> order of windows.
>>>
>>> The minor-mode provides the keymap `switchy-minor-mode-map',
>>> which see."
>>> :global t
>>> :keymap switchy-minor-mode-map
>>
>> Isn't this the default anyway?
>>
>>> (if switchy-minor-mode
>>> (add-hook 'window-selection-change-functions
>>> #'switchy--on-window-selection-change)
>>> (remove-hook 'window-selection-change-functions
>>> #'switchy--on-window-selection-change)))
>>>
>>> (provide 'switchy)
>>>
>>> (provide 'switchy)
>>
>> Accidentally duplicated?
>>
>>> ;;; switchy.el ends here
>>>
>>
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Grammar checking
@ 2023-04-09 9:02 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-04-09 9:02 UTC (permalink / raw)
To: Richard Stallman; +Cc: Lynn Winebarger, emacs-devel
Richard Stallman <rms@gnu.org> writes:
> > But, would it be
> > acceptable for a GNU software project to depend on such software?
>
> If we have free software to do further training on the neural network,
> we can accept it.
>
> Does LanguageTool use a neural network?
No, according to [0] as of 2010 the approach they were using was
rule-based, as opposed to statistical (neutral network).
[0] https://www.researchgate.net/profile/Marcin-Milkowski/publication/220282022_Developing_an_open-source_rule-based_proofreading_tool/links/5b030f720f7e9be94bdabb60/Developing-an-open-source-rule-based-proofreading-tool.pdf
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: [GNU ELPA] I'd like to add switchy.el: a last-recently-used window switcher
@ 2023-04-09 8:56 86% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-04-09 8:56 UTC (permalink / raw)
To: Tassilo Horn; +Cc: emacs-devel
Tassilo Horn <tsdh@gnu.org> writes:
> Hi all,
>
> I've written a small utility called switchy.el which I'd like to add to
> GNU ELPA. I can do that on my own but wanted to give you a chance for
> commenting first. I'm attaching the file below.
>
> In essence, the single command provided is `switchy-window' which is
> similar to `other-window' except that it switches to other windows in
> last-recently-used order instead of top-to-bottom-left-to-right order.
> With quick consecutive invocations you can reach any window but if you
> have a small delay between invocations (controlled by the single
> defcustom `switchy-delay'), you toggle between the two last recently
> used windows.
>
> Bye,
> Tassilo
>
> ;;; switchy.el --- A last-recently-used window switcher -*- lexical-binding: t; -*-
> ;;
> ;; Copyright (C) 2023 Tassilo Horn
> ;;
> ;; Author: Tassilo Horn <tsdh@gnu.org>
> ;; Version: 1.0
> ;; Keywords: windows
> ;; Homepage: https://sr.ht/~tsdh/switchy/
> ;; Repository: https://git.sr.ht/~tsdh/switchy
> ;; Package-Requires: ((emacs "25.1") (compat "29.1.3.4"))
If you are to use compat 29.1.0.0 or newer then you also have to require
it!
> ;; SPDX-License-Identifier: GPL-3.0-or-later
> ;;
> ;; This file is NOT part of GNU Emacs.
If added to GNU ELPA, this should be change to "... is part of GNU
Emacs", right?
> ;;
> ;; This program is free software; you can redistribute it and/or
> ;; modify it under the terms of the GNU General Public License
> ;; as published by the Free Software Foundation; either version 3
> ;; of the License, or (at your option) any later version.
> ;;
> ;; This program is distributed in the hope that it will be useful,
> ;; but WITHOUT ANY WARRANTY; without even the implied warranty of
> ;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> ;; GNU General Public License for more details.
> ;;
> ;; You should have received a copy of the GNU General Public License
> ;; along with this program. If not, see <http://www.gnu.org/licenses/>.
> ;;
> ;;; Commentary:
> ;;
> ;; Switchy is a last-recently-used window switcher. It suits my personal Emacs
> ;; layout and workflow where I usually have at most two editing windows but up
> ;; to three side-windows which I have to select only seldomly.
> ;;
> ;; The idea of switchy is simple: when you invoke `switchy-window' in quick
> ;; succession, it will switch to one window after the other in
> ;; last-recently-used order. Once you stop switching for long enough time
> ;; (`switchy-delay', 1.5 seconds by default), the selected window gets locked
> ;; in, i.e., its LRU timestamp is updated and this switching sequence is ended.
> ;; Thusly, you can toggle between two windows simply by invoking
> ;; `switchy-window', waiting at least `switchy-delay', and then invoking
> ;; `switchy-window' again to switch back to the original window.
> ;;
> ;; Activate `switchy-minor-mode' which tracks window changes and bind
> ;; `switchy-window' to a key of your liking in `switchy-minor-mode-map' (or
> ;; globally, see the variable's docstring for examples).
> ;;
> ;; Hint: Since the order of window switching is not as obvious as it is with
> ;; `other-window', adding a bit visual feedback to window selection changes can
> ;; be helpful. That can be done easily with the stock Emacs pulse.el, e.g.:
> ;;
> ;; (add-hook 'window-selection-change-functions
> ;; (lambda (frame)
> ;; (when (eq frame (selected-frame))
> ;; (pulse-momentary-highlight-one-line))))
>
>
> ;;; Code:
>
> (defgroup switchy nil
> "Switchy is a last-recently-used window-switcher."
> :group 'windows)
>
> (defvar switchy--tick-counter 0
> "Values of this counter represent the last-recently-used order of windows.
> Only for internal use.")
>
> (defvar switchy--tick-alist nil
> "An alist with entries (WINDOW . TICK).
> A higher TICK value means a window has more recently been visited.
> Only for internal use.")
>
> (defcustom switchy-delay 1.5
> "Number of seconds before the current window gets locked in.
> If more time elapses between consecutive invocations of
> `switchy-window', the current window's tick (timestamp) is
> updated in `switchy--tick-alist' and the current switching cycle
> ends."
> :type 'number)
>
> (defvar switchy--timer nil
> "The timer locking in the current window after `switchy-delay' seconds.
> Only for internal use.")
>
> (defvar switchy--visited-windows nil
> "The windows having already been visited in the current switching cycle.")
>
> (defun switchy--on-window-selection-change (&optional frame)
> "Record the next `switchy--tick-counter' value for the selected window of FRAME.
> Meant to be used in `window-selection-change-functions' which is
> arranged by `switchy-minor-mode'."
> (when (eq frame (selected-frame))
> (when switchy--timer
> (cancel-timer switchy--timer))
> (setq switchy--timer (run-at-time
> switchy-delay nil
> (lambda ()
> (setf (alist-get (selected-window)
> switchy--tick-alist)
> (cl-incf switchy--tick-counter))
> (setq switchy--visited-windows nil))))))
>
> (defun switchy-window (&optional arg)
> "Switch to other windows in last-recently-used order.
> If prefix ARG is given, use least-recently-used order.
>
> If the time between consecutive invocations is smaller than
> `switchy-delay' seconds, selects one after the other window in
> LRU order and cycles when all windows have been visited. If
> `switchy-delay' has passed, the current switching cycle ends and
> the now selected window gets its tick updated (a kind of
> timestamp)."
> (interactive)
>
> (unless switchy-minor-mode
> (user-error "switchy-window requires `switchy-minor-mode' being active"))
>
> ;; Remove dead windows.
> (setq switchy--tick-alist (seq-filter
> (lambda (e)
> (window-live-p (car e)))
> switchy--tick-alist))
> ;; Add windows never selected.
> (dolist (win (window-list (selected-frame)))
> (unless (assq win switchy--tick-alist)
> (setf (alist-get win switchy--tick-alist) 0)))
The setf is strictly speaking unnecessary here and causes an accidental
O(n^2) slowdown, since you traverse the list once to check if it has an
entry and then traverse it again to check if you can set 0 to an
existing entry. You could also just push a cons-cell to the beginning.
Then again, this is all bounded by the maximal number of windows that
someone has open so it doesn't matter in practice.
> ;; Ensure the current window is marked as visited.
> (setq switchy--visited-windows (cons (selected-window)
> switchy--visited-windows))
>
> (let ((win-entries (seq-filter
> (lambda (e)
> (let ((win (car e)))
> (and (eq (window-frame win) (selected-frame))
> (or (minibuffer-window-active-p win)
> (not (eq win (minibuffer-window
> (selected-frame)))))
> (not (memq win switchy--visited-windows)))))
> switchy--tick-alist)))
> (if win-entries
> (when-let ((win (car (seq-reduce (lambda (x e)
> (if (and x (funcall (if arg #'< #'>)
> (cdr x) (cdr e)))
> x
> e))
> win-entries nil))))
>
> (progn
Why the progn if you are using when-let?
> (setq switchy--visited-windows (cons win switchy--visited-windows))
> (select-window win)))
> ;; Start a new cycle if we're not at the start already, i.e., we visited
> ;; just one (the current) window.
> (when (> (length switchy--visited-windows) 1)
Or (length> switchy--visited-windows 1)?
> (setq switchy--visited-windows nil)
> (switchy-window)))))
>
> (defvar switchy-minor-mode-map (make-sparse-keymap)
> "The mode map of `switchy-minor-mode'.
> No keys are bound by default. Bind the main command
> `switchy-window' to a key of your liking, e.g.,
>
> ;; That\\='s what I use.
> (keymap-set switchy-minor-mode-map \"C-<\" #\\='switchy-window)
If you are already making use of keymap-set, you might as well define
the map itself using defvar-keymap (Compat provides it).
> ;; Or as a substitute for `other-window'.
> (add-hook \\='switchy-minor-mode-hook
> (lambda ()
> (if switchy-minor-mode
> (keymap-global-set \"<remap> <other-window>\"
> #\\='switchy-window)
> (keymap-global-unset \"<remap> <other-window>\"))))")
>
> (define-minor-mode switchy-minor-mode
> "Activates recording of window selection ticks.
> Those are the timestamps for figuring out the last-recently-used
> order of windows.
>
> The minor-mode provides the keymap `switchy-minor-mode-map',
> which see."
> :global t
> :keymap switchy-minor-mode-map
Isn't this the default anyway?
> (if switchy-minor-mode
> (add-hook 'window-selection-change-functions
> #'switchy--on-window-selection-change)
> (remove-hook 'window-selection-change-functions
> #'switchy--on-window-selection-change)))
>
> (provide 'switchy)
>
> (provide 'switchy)
Accidentally duplicated?
> ;;; switchy.el ends here
>
--
Philip Kaludercic
^ permalink raw reply [relevance 86%]
* Re: How to install documentation in sub-directory with Package VC?
@ 2023-04-08 8:36 91% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-04-08 8:36 UTC (permalink / raw)
To: Jonas Bernoulli; +Cc: Okamsn, emacs-devel
Jonas Bernoulli <jonas@bernoul.li> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>>> - `:url`
>>> - `:branch`
>>> - `:lisp-dir`
>>> - `:main-file`
>>> - `:doc`
>>> - `:vc-backend`
>>>
>>> I did not see any others. Are there others?
>>
>> Those should be it for now.
>
> For what it's worth, since [1] MELPA generates a "elpa-packages.eld".
That is great! I was planning to look at how this could be done for
MELPA, but as I am not familiar with the build-system I have been
deferring this for a while.
> We only provide :url, and where appropriate :branch, :vc-backend and
> :maintainer.
:maintainer is currently not used (TBH I am not sure what the point of
it is in elpa-admin to begin with), so I guess you don't have to insert
that if you want to reduce the file size.
> :main-file shouldn't be required because we don't accept
> packages for which that would be necessary. We don't set :doc or
> :lisp-dir (yet?).
Do you think it could be possible to support :doc and :lisp-dir. IIUC
the issue is that MELPA only accepts a list of files to include when
bundling a package (:files) and the build system would have to infer
what what is?
> [1] https://github.com/melpa/package-build/commit/0cfcc5ce30186a5d1b92c1d
--
Philip Kaludercic
^ permalink raw reply [relevance 91%]
* Re: Request to add Package to GNU ELPA
@ 2023-04-08 8:24 85% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-04-08 8:24 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Jonas Bernoulli, emacs-devel
[-- Attachment #1: Type: text/plain, Size: 618 bytes --]
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> [ I'm curious which definitions of `compat` this uses. ]
>>
>> Those should be
>>
>> - file-name-concat
>> - length>
>> - with-suppressed-warnings
>> - named-let
>> - length=
>> - ensure-list
>> - macroexp-file-name
>> - dlet
>
> Thanks. Nice.
>
>> Do you think it is worth mentioning them?
>
> No, I don't think so.
>
> The patch LGTM now,
As mentioned in my other message, we are also missing
`loaddefs-generate'. I am not exactly sure what motivated the change,
so I don't know if checking the version and doing what was done prior to
29 would be enough:
[-- Attachment #2: Type: text/plain, Size: 1059 bytes --]
diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el
index b340848a6f9..48551f59b43 100644
--- a/lisp/emacs-lisp/package.el
+++ b/lisp/emacs-lisp/package.el
@@ -1003,6 +1003,7 @@ package-generate-description-file
(defun package-autoload-ensure-default-file (file)
"Make sure that the autoload file FILE exists and if not create it."
+ (declare (obsolete nil "29.1"))
(unless (file-exists-p file)
(require 'autoload)
(let ((coding-system-for-write 'utf-8-emacs-unix))
@@ -1021,8 +1022,11 @@ package-generate-autoloads
(autoload-timestamps nil)
(backup-inhibited t)
(version-control 'never))
- (package-autoload-ensure-default-file output-file)
- (make-directory-autoloads pkg-dir output-file)
+ (loaddefs-generate
+ pkg-dir output-file
+ nil
+ "(add-to-list 'load-path (directory-file-name
+ (or (file-name-directory #$) (car load-path))))")
(let ((buf (find-buffer-visiting output-file)))
(when buf (kill-buffer buf)))
auto-name))
[-- Attachment #3: Type: text/plain, Size: 23 bytes --]
--
Philip Kaludercic
^ permalink raw reply related [relevance 85%]
* Re: Request to add Package to GNU ELPA
2023-04-07 7:23 98% ` Philip Kaludercic
@ 2023-04-07 10:07 34% ` Philip Kaludercic
1 sibling, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-04-07 10:07 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Jonas Bernoulli, emacs-devel
[-- Attachment #1: Type: text/plain, Size: 341 bytes --]
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> Why not just replace (make-separator-line) with
> (if (fboundp 'make-separator-line) (make-separator-line) "")?
> `newline` is a command and I think it's preferable not to use it
> from ELisp.
Turns out that Compat supports this, so we don't need the check.
Here is the revised patch:
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Prepare-package.el-to-be-published-on-GNU-ELPA.patch --]
[-- Type: text/x-diff, Size: 4682 bytes --]
From e778cff125cf48f933256c488adbcd362a31f715 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Wed, 5 Apr 2023 23:16:39 +0200
Subject: [PATCH] Prepare package.el to be published on GNU ELPA
* lisp/emacs-lisp/package.el: Add Compat as a dependency.
(package--native-compile-async): Check if 'native-comp-available-p' is
bound.
(lm-homepage, lm-website): Use backwards-compatible alias
'lm-homepage'.
(package-buffer-info): Call 'lm-maintainer' if 'lm-maintainers' is not
defined.
(describe-package-1): Avoid using 'make-separator-line' if not bound.
(package-report-bug): Expand 'custom--standard-value' definition.
For the background and motivation behind these changes, please consult
this thread:
https://lists.gnu.org/archive/html/emacs-devel/2023-03/msg00995.html.
---
lisp/emacs-lisp/package.el | 27 ++++++++++++++++++---------
1 file changed, 18 insertions(+), 9 deletions(-)
diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el
index 0258ed52bee..8f5da5af1ea 100644
--- a/lisp/emacs-lisp/package.el
+++ b/lisp/emacs-lisp/package.el
@@ -5,9 +5,12 @@
;; Author: Tom Tromey <tromey@redhat.com>
;; Daniel Hackney <dan@haxney.org>
;; Created: 10 Mar 2007
-;; Version: 1.1.0
+;; Version: 1.1.1
;; Keywords: tools
-;; Package-Requires: ((tabulated-list "1.0"))
+;; Package-Requires: ((emacs "27.1") (compat "29.1.0.0"))
+
+;; This is a GNU ELPA :core package. Avoid functionality that is not
+;; compatible with the version of Emacs recorded above.
;; This file is part of GNU Emacs.
@@ -147,6 +150,7 @@
(eval-when-compile (require 'subr-x))
(eval-when-compile (require 'epg)) ;For setf accessors.
(eval-when-compile (require 'inline)) ;For `define-inline'
+(require 'compat nil 'noerror)
(require 'seq)
(require 'tabulated-list)
@@ -1124,7 +1128,8 @@ package--native-compile-async
"Native compile installed package PKG-DESC asynchronously.
This assumes that `pkg-desc' has already been activated with
`package-activate-1'."
- (when (native-comp-available-p)
+ (when (and (fboundp 'native-comp-available-p)
+ (native-comp-available-p))
(let ((warning-minimum-level :error))
(native-compile-async (package-desc-dir pkg-desc) t))))
@@ -1160,9 +1165,10 @@ package--prepare-dependencies
(declare-function lm-header "lisp-mnt" (header))
(declare-function lm-header-multiline "lisp-mnt" (header))
-(declare-function lm-website "lisp-mnt" (&optional file))
+(declare-function lm-homepage "lisp-mnt" (&optional file))
(declare-function lm-keywords-list "lisp-mnt" (&optional file))
(declare-function lm-maintainers "lisp-mnt" (&optional file))
+(declare-function lm-maintainer "lisp-mnt" (&optional file))
(declare-function lm-authors "lisp-mnt" (&optional file))
(defun package-buffer-info ()
@@ -1195,7 +1201,7 @@ package-buffer-info
(or (lm-header "package-version") (lm-header "version")))
(pkg-version (package-strip-rcs-id version-info))
(keywords (lm-keywords-list))
- (website (lm-website)))
+ (website (lm-homepage)))
(unless pkg-version
(if version-info
(error "Unrecognized package version: %s" version-info)
@@ -1211,7 +1217,10 @@ package-buffer-info
:maintainer
;; For backward compatibility, use a single string if there's only
;; one maintainer (the most common case).
- (let ((maints (lm-maintainers))) (if (cdr maints) maints (car maints)))
+ (if (fboundp 'lm-maintainers)
+ (let ((maints (lm-maintainers)))
+ (if (cdr maints) maints (car maints)))
+ (lm-maintainer))
:authors (lm-authors)))))
(defun package--read-pkg-desc (kind)
@@ -2302,8 +2311,6 @@ package-strip-rcs-id
;; to make sure we use a "canonical name"!
(if l (package-version-join l)))))
-(declare-function lm-website "lisp-mnt" (&optional file))
-
;;;###autoload
(defun package-install-from-buffer ()
"Install a package from the current buffer.
@@ -4571,7 +4578,9 @@ package-report-bug
(dolist (ent (get (cdr group) 'custom-group))
(when (and (custom-variable-p (car ent))
(boundp (car ent))
- (not (eq (custom--standard-value (car ent))
+ (not (eq (if (fboundp 'custom--standard-value)
+ (custom--standard-value (car ent))
+ (eval (car (get (car ent) 'standard-value)) t))
(default-toplevel-value (car ent))))
(file-in-directory-p (car group) (package-desc-dir desc)))
(push (car ent) vars))))
--
2.30.2
[-- Attachment #3: Type: text/plain, Size: 5604 bytes --]
And here is the compile-log I got after installing the package on Emacs
27.1:
--8<---------------cut here---------------start------------->8---
Compiling file /home/philip/.config/emacs/elpa/package-1.1.1/package.el at Fri Apr 7 11:58:06 2023
Entering directory ‘/home/philip/.config/emacs/elpa/package-1.1.1/’
In package-tar-file-info:
package.el:1243:8:Warning: ‘(filename (tar-header-name (car tar-parse-info)))’
is a malformed function
package.el:1247:31:Warning: reference to free variable ‘loop’
package.el:1249:58:Warning: reference to free variable ‘filename’
In package-menu-toggle-hiding:
package.el:3208:4:Warning: malformed interactive spec: (interactive nil
package-menu-mode)
In package-menu-hide-package:
package.el:3556:4:Warning: malformed interactive spec: (interactive nil
package-menu-mode)
In package-menu-describe-package:
package.el:3580:4:Warning: malformed interactive spec: (interactive nil
package-menu-mode)
In package-menu-mark-delete:
package.el:3590:4:Warning: malformed interactive spec: (interactive "p"
package-menu-mode)
In package-menu-mark-install:
package.el:3599:4:Warning: malformed interactive spec: (interactive "p"
package-menu-mode)
In package-menu-mark-unmark:
package.el:3607:4:Warning: malformed interactive spec: (interactive "p"
package-menu-mode)
In package-menu-backup-unmark:
package.el:3613:4:Warning: malformed interactive spec: (interactive nil
package-menu-mode)
In package-menu-mark-obsolete-for-deletion:
package.el:3620:4:Warning: malformed interactive spec: (interactive nil
package-menu-mode)
In package-menu-quick-help:
package.el:3652:4:Warning: malformed interactive spec: (interactive nil
package-menu-mode)
In package-menu-mark-upgrades:
package.el:3745:4:Warning: malformed interactive spec: (interactive nil
package-menu-mode)
In package-menu-execute:
package.el:3870:4:Warning: malformed interactive spec: (interactive nil
package-menu-mode)
In package-menu-filter-by-archive:
package.el:4127:4:Warning: malformed interactive spec: (interactive (list
(completing-read-multiple "Filter by archive (comma separated): " (mapcar
#'car package-archives))) package-menu-mode)
In package-menu-filter-by-description:
package.el:4149:4:Warning: malformed interactive spec: (interactive (list
(read-regexp "Filter by description (regexp)")) package-menu-mode)
In package-menu-filter-by-keyword:
package.el:4169:4:Warning: malformed interactive spec: (interactive (list
(completing-read-multiple "Keywords (comma separated): "
(package-all-keywords))) package-menu-mode)
In package-menu-filter-by-name-or-description:
package.el:4194:4:Warning: malformed interactive spec: (interactive (list
(read-regexp "Filter by name or description (regexp)")) package-menu-mode)
In package-menu-filter-by-name:
package.el:4214:4:Warning: malformed interactive spec: (interactive (list
(read-regexp "Filter by name (regexp)")) package-menu-mode)
In package-menu-filter-by-status:
package.el:4234:4:Warning: malformed interactive spec: (interactive (list
(completing-read "Filter by status: " '("avail-obso" "available"
"built-in" "dependency" "disabled" "external" "held" "incompat"
"installed" "source" "new" "unsigned"))) package-menu-mode)
In package-menu-filter-by-version:
package.el:4273:4:Warning: malformed interactive spec: (interactive (let
((choice (intern (char-to-string (read-char-choice "Filter by version?
[Type =, <, > or q] " '(60 62 61 113)))))) (if (eq choice 'q) '(quit nil)
(list (read-from-minibuffer (concat "Filter by version (" (cond ((eq
choice '=) "= equal to") ((eq choice '<) "< less than") ((eq choice '>) ">
greater than") (t nil)) "): ")) choice))) package-menu-mode)
In package-menu-filter-marked:
package.el:4307:4:Warning: malformed interactive spec: (interactive nil
package-menu-mode)
In package-menu-filter-upgradable:
package.el:4335:4:Warning: malformed interactive spec: (interactive nil
package-menu-mode)
In package-menu-clear-filter:
package.el:4344:4:Warning: malformed interactive spec: (interactive nil
package-menu-mode)
In package-browse-url:
package.el:4528:4:Warning: malformed interactive spec: (interactive (list
(package--query-desc) current-prefix-arg) package-menu-mode)
In package-report-bug:
package.el:4571:4:Warning: malformed interactive spec: (interactive (list
(package--query-desc package-alist)) package-menu-mode)
package.el:4571:43:Warning: ‘(reporter-prompt-for-summary-p t)’ is a malformed
function
In end of data:
package.el:4602:1:Warning: the following functions are not known to be defined:
file-name-concat, length>, loaddefs-generate,
native-compile-async, named-let, loop, length=,
comp-clean-up-stale-eln, format-prompt, substitute-quotes,
make-separator-line, defvar-keymap, ensure-list,
macroexp-file-name, dlet
--8<---------------cut here---------------end--------------->8---
The most common issue is that the interactive spec has to be revised to
use only one argument. IIUC this can be replaced by a `declare' form
with a `modes' entry?
This also gives us a better picture of the unknown functions:
- loaddefs-generate (not provided by Compat)
- substitute-quotes (provided by Compat)
- defvar-keymap (provided by Compat)
I will take a look at what is necessary to back-port `loaddefs-generate'
via Compat.
--
Philip Kaludercic
^ permalink raw reply related [relevance 34%]
* Re: Request to add Package to GNU ELPA
@ 2023-04-07 7:23 98% ` Philip Kaludercic
2023-04-07 10:07 34% ` Philip Kaludercic
1 sibling, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-04-07 7:23 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Jonas Bernoulli, emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> +;; Package-Requires: ((emacs "26.1") (compat "29.1.0.0"))
>
> [ I'm curious which definitions of `compat` this uses. ]
Those should be
- file-name-concat
- length>
- with-suppressed-warnings
- named-let
- length=
- ensure-list
- macroexp-file-name
- dlet
Do you think it is worth mentioning them?
>> @@ -1208,10 +1214,13 @@ package-buffer-info
>> :kind 'single
>> :url website
>> :keywords keywords
>> - :maintainer
>> + :maintainer (lm-maintainer)
>> ;; For backward compatibility, use a single string if there's only
>> ;; one maintainer (the most common case).
>> - (let ((maints (lm-maintainers))) (if (cdr maints) maints (car maints)))
>> + (if (fboundp 'lm-maintainers)
>> + (let ((maints (lm-maintainers)))
>> + (if (cdr maints) maints (car maints)))
>> + (lm-maintainer))
>> :authors (lm-authors)))))
>
> Hmm... isn't the `(lm-maintainer)` right after `:maintainer` erroneous?
Yes, that was a typo.
> [ BTW, I think Jonas has another change pending for this code. ]
>
>> (when news
>> - (insert "\n" (make-separator-line) "\n"
>> - (propertize "* News" 'face 'package-help-section-name)
>> + (newline)
>> + (when (fboundp 'make-separator-line)
>> + (insert (make-separator-line))
>> + (newline))
>> + (insert (propertize "* News" 'face 'package-help-section-name)
>> "\n\n")
>> (insert-file-contents news))
>
> Why not just replace (make-separator-line) with
> (if (fboundp 'make-separator-line) (make-separator-line) "")?
I believe what I had in mind was to avoid formatting issues when
`make-separator-line' was not available. I'll check again.
> `newline` is a command and I think it's preferable not to use it
> from ELisp.
Oops, right.
>> @@ -4571,8 +4581,11 @@ package-report-bug
>> (dolist (ent (get (cdr group) 'custom-group))
>> (when (and (custom-variable-p (car ent))
>> (boundp (car ent))
>> - (not (eq (custom--standard-value (car ent))
>> - (default-toplevel-value (car ent))))
>> + (not (eq
>> + ;; We are not using `custom--standard-value'
>> + ;; to retain compatibility for Emacs 27.
>> + (eval (car (get (car ent) 'standard-value)) t)
>> + (default-toplevel-value (car ent))))
>
> I'd use
>
> (if (fboundp 'custom--standard-value) ;; Emacs≥27
> (custom--standard-value (car ent))
> (eval (car (get (car ent) 'standard-value)) t))
>
> so the code "speaks for itself".
Good point.
--
Philip Kaludercic
^ permalink raw reply [relevance 98%]
* Re: Request to add Package to GNU ELPA
2023-04-05 21:08 58% ` Philip Kaludercic
@ 2023-04-06 15:46 50% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-04-06 15:46 UTC (permalink / raw)
To: Jonas Bernoulli; +Cc: emacs-devel, Stefan Monnier
[-- Attachment #1: Type: text/plain, Size: 411 bytes --]
Philip Kaludercic <philipk@posteo.net> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> 1. Update package.el to be published on ELPA
>
> It might be that this would be enough to publish package.el with support
> back to 27.1, with the help of Compat:
Stefan fell out of the CCs, so I've added him again since I am most
interested in what he thinks of these changes, added here again as a
patch:
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Prepare-package.el-to-be-published-on-GNU-ELPA.patch --]
[-- Type: text/x-diff, Size: 5385 bytes --]
From 1fcf56725848984ef6da50ef2b7a130e1ffd3282 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Wed, 5 Apr 2023 23:16:39 +0200
Subject: [PATCH] Prepare package.el to be published on GNU ELPA
* lisp/emacs-lisp/package.el: Add Compat as a dependency.
(package--native-compile-async): Check if 'native-comp-available-p' is
bound.
(lm-homepage, lm-website): Use backwards-compatible alias
'lm-homepage'.
(package-buffer-info): Call 'lm-maintainer' if 'lm-maintainers' is not
defined.
(describe-package-1): Avoid using 'make-separator-line' if not bound.
(package-report-bug): Expand 'custom--standard-value' definition.
Check out these discussions for more context:
https://lists.gnu.org/archive/html/emacs-devel/2023-03/msg00995.html.
---
lisp/emacs-lisp/package.el | 39 +++++++++++++++++++++++++-------------
1 file changed, 26 insertions(+), 13 deletions(-)
diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el
index 0258ed52bee..6b68c84a211 100644
--- a/lisp/emacs-lisp/package.el
+++ b/lisp/emacs-lisp/package.el
@@ -5,9 +5,12 @@
;; Author: Tom Tromey <tromey@redhat.com>
;; Daniel Hackney <dan@haxney.org>
;; Created: 10 Mar 2007
-;; Version: 1.1.0
+;; Version: 1.1.1
;; Keywords: tools
-;; Package-Requires: ((tabulated-list "1.0"))
+;; Package-Requires: ((emacs "26.1") (compat "29.1.0.0"))
+
+;; This is a GNU ELPA :core package. Avoid functionality that is not
+;; compatible with the version of Emacs recorded above.
;; This file is part of GNU Emacs.
@@ -147,6 +150,7 @@
(eval-when-compile (require 'subr-x))
(eval-when-compile (require 'epg)) ;For setf accessors.
(eval-when-compile (require 'inline)) ;For `define-inline'
+(require 'compat nil 'noerror)
(require 'seq)
(require 'tabulated-list)
@@ -1124,7 +1128,8 @@ package--native-compile-async
"Native compile installed package PKG-DESC asynchronously.
This assumes that `pkg-desc' has already been activated with
`package-activate-1'."
- (when (native-comp-available-p)
+ (when (and (fboundp 'native-comp-available-p)
+ (native-comp-available-p))
(let ((warning-minimum-level :error))
(native-compile-async (package-desc-dir pkg-desc) t))))
@@ -1160,9 +1165,10 @@ package--prepare-dependencies
(declare-function lm-header "lisp-mnt" (header))
(declare-function lm-header-multiline "lisp-mnt" (header))
-(declare-function lm-website "lisp-mnt" (&optional file))
+(declare-function lm-homepage "lisp-mnt" (&optional file))
(declare-function lm-keywords-list "lisp-mnt" (&optional file))
(declare-function lm-maintainers "lisp-mnt" (&optional file))
+(declare-function lm-maintainer "lisp-mnt" (&optional file))
(declare-function lm-authors "lisp-mnt" (&optional file))
(defun package-buffer-info ()
@@ -1195,7 +1201,7 @@ package-buffer-info
(or (lm-header "package-version") (lm-header "version")))
(pkg-version (package-strip-rcs-id version-info))
(keywords (lm-keywords-list))
- (website (lm-website)))
+ (website (lm-homepage)))
(unless pkg-version
(if version-info
(error "Unrecognized package version: %s" version-info)
@@ -1208,10 +1214,13 @@ package-buffer-info
:kind 'single
:url website
:keywords keywords
- :maintainer
+ :maintainer (lm-maintainer)
;; For backward compatibility, use a single string if there's only
;; one maintainer (the most common case).
- (let ((maints (lm-maintainers))) (if (cdr maints) maints (car maints)))
+ (if (fboundp 'lm-maintainers)
+ (let ((maints (lm-maintainers)))
+ (if (cdr maints) maints (car maints)))
+ (lm-maintainer))
:authors (lm-authors)))))
(defun package--read-pkg-desc (kind)
@@ -2302,8 +2311,6 @@ package-strip-rcs-id
;; to make sure we use a "canonical name"!
(if l (package-version-join l)))))
-(declare-function lm-website "lisp-mnt" (&optional file))
-
;;;###autoload
(defun package-install-from-buffer ()
"Install a package from the current buffer.
@@ -2902,8 +2909,11 @@ describe-package-1
;; Insert news if available.
(when news
- (insert "\n" (make-separator-line) "\n"
- (propertize "* News" 'face 'package-help-section-name)
+ (newline)
+ (when (fboundp 'make-separator-line)
+ (insert (make-separator-line))
+ (newline))
+ (insert (propertize "* News" 'face 'package-help-section-name)
"\n\n")
(insert-file-contents news))
@@ -4571,8 +4581,11 @@ package-report-bug
(dolist (ent (get (cdr group) 'custom-group))
(when (and (custom-variable-p (car ent))
(boundp (car ent))
- (not (eq (custom--standard-value (car ent))
- (default-toplevel-value (car ent))))
+ (not (eq
+ ;; We are not using `custom--standard-value'
+ ;; to retain compatibility for Emacs 27.
+ (eval (car (get (car ent) 'standard-value)) t)
+ (default-toplevel-value (car ent))))
(file-in-directory-p (car group) (package-desc-dir desc)))
(push (car ent) vars))))
(dlet ((reporter-prompt-for-summary-p t))
--
2.39.2
[-- Attachment #3: Type: text/plain, Size: 152 bytes --]
elpa-admin.el appears to be handling the changes well, I'll still have
to try and install it on an older Emacs to see if everything works as
expected.
^ permalink raw reply related [relevance 50%]
* Re: How to install documentation in sub-directory with Package VC?
@ 2023-04-06 15:42 67% ` Philip Kaludercic
2023-04-10 13:39 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-04-06 15:42 UTC (permalink / raw)
To: Okamsn; +Cc: Eli Zaretskii, emacs-devel
[-- Attachment #1: Type: text/plain, Size: 4893 bytes --]
Okamsn <okamsn@protonmail.com> writes:
> On 2023-04-05 07:30 UTC, Philip Kaludercic wrote:
>>> + To install a package from source, Emacs must know where to get the
>>> +package's source code (such as a code repository) and basic
>>> +information about the structure of the code (such as the main file in
>>> +a multi-file package). These things are described by a package's
>> ^
>> a bit informal? I think you can just
>> drop the word and still convey the same
>> information.
>
> I acknowledge that "things" is unspecific, but I do think that the
> paragraph flows better with a noun there. What if "things" was swapped
> out for "properties"? I think that it would work well with the use of
> "property list" a few sentences later.
That sounds good!
>
>>> + When supported by a package archive (@pxref{Package
>>> +Archives,,,elisp, The Emacs Lisp Reference Manual}), Emacs can
>>> +automatically download a package's specification from said archive.
>>
>> Not sure if this might be confusing. package-vc has heuristics to try
>> and guess how to install a package, so it is /possible/ but not
>> /reliable/ to install a package from a third-party archive like MELPA.
>> Then again, perhaps we don't have to mention that at all in the manual,
>> so as to not promote an unreliable trick.
>
> I wasn't aware of these heuristics. In this paragraph, I was trying to
> describe where the known specifications come from, as in the
> "elpa-package.eld" file.
The point here is that you can install a package listed in an archive,
even though the archive doesn't generate a elpa-package.eld. It works
most of the time, in the remaining cases the heuristics help but it is
not ideal. Should this be explained?
>>> +@item :main-file
>>> +A string containing the main file of the project, from which to gather
>>> +package metadata. If not given, the default is the package name with
>>> +".el" appended to it.
>>
>> (This is true most of the time, but if you check out what
>> `package-vc--main-file' does, then you will see that this is not
>> necessary. Again, I don't think this implementation detail is worth
>> documenting publicly.)
>
> Are you saying that you don't want to describe the heuristic, or that
> you don't want to describe the default behavior? I would like to keep
> the mention of the default behavior.
I don't want to document the heuristic, as IMO this is an implementation
detail. Lets keep this the way it is.
>>> + A package's specification can also be given manually as the first
>>> +argument to @code{package-vc-install}. This allows you to install
>>> +source packages from locations other than the known archives listed in
>>> +the user option @code{package-archives}. A package specification is a
>>> +list of the form @code{(@var{name} . @var{spec})}, in which @var{spec}
>>> +should be a property list using any of the following keys.
>>>
>>> +For definitions of basic terms for working with code repositories and
>>> +version control systems, see @xref{VCS Concepts,,,emacs, The GNU Emacs
>>> +Manual}.
>>
>> Should this paragraph be moved down below the table? Otherwise the "any
>> of the following" reads funnily.
>
> I don't think that this paragraph should be moved to after the table. In
> my opinion, it is better to have the link, which defines the terms,
> placed before the using of the terms.
Another idea would be to mark the paragraph up using @quotation,
@cartouche or a Footnote?
> Instead, what if the sentence ended like "using any of the keys in the
> table below"?
That would also be fine.
>>> diff --git a/lisp/emacs-lisp/package-vc.el b/lisp/emacs-lisp/package-vc.el
>>> index 253b35f1f1a..cbc9a1ecece 100644
>>> --- a/lisp/emacs-lisp/package-vc.el
>>> +++ b/lisp/emacs-lisp/package-vc.el
>>> @@ -152,25 +152,31 @@ package-vc-selected-packages
>>
>> I believe I mentioned this before, but what do you think about just
>> linking to the manual, and not duplicating the information here and
>> there? It would make maintenance easier, but might not be nice for
>> users on systems that do not come installed with documentation like
>> Debian... Then again, this wouldn't be the only place where this would
>> affect users.
>
> Some of the information in the documentation string is probably not
> relevant for users wishing to give their own specification. For example,
> the information about a package archive's default VC backend that Eli
> Zaretskii pointed out. Would you like to limit the information in the
> table to what is relevant for giving a manual specification, or should
> the table be a description of the behavior for all specifications?
What I had in mind was just replace the ad-hoc list in the docstring
with a reference to the new section in the manual:
[-- Attachment #2: Type: text/plain, Size: 1664 bytes --]
diff --git a/lisp/emacs-lisp/package-vc.el b/lisp/emacs-lisp/package-vc.el
index ddc7ec4679b..6fe30e08830 100644
--- a/lisp/emacs-lisp/package-vc.el
+++ b/lisp/emacs-lisp/package-vc.el
@@ -147,32 +147,9 @@ package-vc-selected-packages
- nil, if any package version can be installed;
- a version string, if that specific revision is to be installed;
-- a property list, describing a package specification. Valid
- key/value pairs are
-
- `:url' (string)
- The URL of the repository used to fetch the package source.
-
- `:branch' (string)
- If given, the name of the branch to checkout after cloning the directory.
-
- `:lisp-dir' (string)
- The repository-relative name of the directory to use for loading the Lisp
- sources. If not given, the value defaults to the root directory
- of the repository.
-
- `:main-file' (string)
- The main file of the project, relevant to gather package metadata.
- If not given, the assumed default is the package name with \".el\"
- appended to it.
-
- `:vc-backend' (symbol)
- A symbol of the VC backend to use for cloning the package. The
- value ought to be a member of `vc-handled-backends'. If omitted,
- `vc-clone' will fall back onto the archive default or on
- `package-vc-default-backend'.
-
- All other keys are ignored.
+- a property list, describing a package specification. For more
+ details please consult the \"Package specification\" subsection
+ under the Info node `(emacs) Fetching Package Sources'.
This user option will be automatically updated to store package
specifications for packages that are not specified in any
[-- Attachment #3: Type: text/plain, Size: 277 bytes --]
> If it is made more general, then I have no strong reason to disagree
> with keeping the information in only one place. However, I will defer to
> others on this.
I am just making suggestions here and am interested in what you think.
My opinion isn't worth more than yours.
^ permalink raw reply related [relevance 67%]
* Re: Request to add Package to GNU ELPA
2023-04-05 18:26 79% ` Philip Kaludercic
@ 2023-04-05 21:08 58% ` Philip Kaludercic
2023-04-06 15:46 50% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-04-05 21:08 UTC (permalink / raw)
To: Jonas Bernoulli; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 209 bytes --]
Philip Kaludercic <philipk@posteo.net> writes:
> 1. Update package.el to be published on ELPA
It might be that this would be enough to publish package.el with support
back to 27.1, with the help of Compat:
[-- Attachment #2: Type: text/plain, Size: 4484 bytes --]
diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el
index 0258ed52bee..520e02f4c33 100644
--- a/lisp/emacs-lisp/package.el
+++ b/lisp/emacs-lisp/package.el
@@ -5,9 +5,12 @@
;; Author: Tom Tromey <tromey@redhat.com>
;; Daniel Hackney <dan@haxney.org>
;; Created: 10 Mar 2007
-;; Version: 1.1.0
+;; Version: 1.1.1
;; Keywords: tools
-;; Package-Requires: ((tabulated-list "1.0"))
+;; Package-Requires: ((emacs "27.1") (compat "29.1.0.0"))
+
+;; This is a GNU ELPA :core package. Avoid functionality that is not
+;; compatible with the version of Emacs recorded above.
;; This file is part of GNU Emacs.
@@ -147,6 +150,7 @@
(eval-when-compile (require 'subr-x))
(eval-when-compile (require 'epg)) ;For setf accessors.
(eval-when-compile (require 'inline)) ;For `define-inline'
+(require 'compat nil 'noerror)
(require 'seq)
(require 'tabulated-list)
@@ -1124,7 +1128,8 @@ package--native-compile-async
"Native compile installed package PKG-DESC asynchronously.
This assumes that `pkg-desc' has already been activated with
`package-activate-1'."
- (when (native-comp-available-p)
+ (when (and (fboundp 'native-comp-available-p)
+ (native-comp-available-p))
(let ((warning-minimum-level :error))
(native-compile-async (package-desc-dir pkg-desc) t))))
@@ -1160,9 +1165,9 @@ package--prepare-dependencies
(declare-function lm-header "lisp-mnt" (header))
(declare-function lm-header-multiline "lisp-mnt" (header))
-(declare-function lm-website "lisp-mnt" (&optional file))
+(declare-function lm-homepage "lisp-mnt" (&optional file))
(declare-function lm-keywords-list "lisp-mnt" (&optional file))
-(declare-function lm-maintainers "lisp-mnt" (&optional file))
+(declare-function lm-maintainer "lisp-mnt" (&optional file))
(declare-function lm-authors "lisp-mnt" (&optional file))
(defun package-buffer-info ()
@@ -1195,7 +1200,7 @@ package-buffer-info
(or (lm-header "package-version") (lm-header "version")))
(pkg-version (package-strip-rcs-id version-info))
(keywords (lm-keywords-list))
- (website (lm-website)))
+ (website (lm-homepage)))
(unless pkg-version
(if version-info
(error "Unrecognized package version: %s" version-info)
@@ -1208,10 +1213,13 @@ package-buffer-info
:kind 'single
:url website
:keywords keywords
- :maintainer
+ :maintainer (lm-maintainer)
;; For backward compatibility, use a single string if there's only
;; one maintainer (the most common case).
- (let ((maints (lm-maintainers))) (if (cdr maints) maints (car maints)))
+ (if (fboundp 'lm-maintainers)
+ (let ((maints (lm-maintainers)))
+ (if (cdr maints) maints (car maints)))
+ (lm-maintainer))
:authors (lm-authors)))))
(defun package--read-pkg-desc (kind)
@@ -2302,8 +2310,6 @@ package-strip-rcs-id
;; to make sure we use a "canonical name"!
(if l (package-version-join l)))))
-(declare-function lm-website "lisp-mnt" (&optional file))
-
;;;###autoload
(defun package-install-from-buffer ()
"Install a package from the current buffer.
@@ -2902,8 +2908,11 @@ describe-package-1
;; Insert news if available.
(when news
- (insert "\n" (make-separator-line) "\n"
- (propertize "* News" 'face 'package-help-section-name)
+ (newline)
+ (when (fboundp 'make-separator-line)
+ (insert (make-separator-line))
+ (newline))
+ (insert (propertize "* News" 'face 'package-help-section-name)
"\n\n")
(insert-file-contents news))
@@ -4571,8 +4580,11 @@ package-report-bug
(dolist (ent (get (cdr group) 'custom-group))
(when (and (custom-variable-p (car ent))
(boundp (car ent))
- (not (eq (custom--standard-value (car ent))
- (default-toplevel-value (car ent))))
+ (not (eq
+ ;; We are not using `custom--standard-value'
+ ;; to retain compatibility for Emacs 27.
+ (eval (car (get (car ent) 'standard-value)) t)
+ (default-toplevel-value (car ent))))
(file-in-directory-p (car group) (package-desc-dir desc)))
(push (car ent) vars))))
(dlet ((reporter-prompt-for-summary-p t))
^ permalink raw reply related [relevance 58%]
* Re: jinx
@ 2023-04-05 18:37 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-04-05 18:37 UTC (permalink / raw)
To: Rudolf Adamkovič
Cc: Gregory Heytings, Eli Zaretskii, rms, m.eliachevitch, emacs-devel
Rudolf Adamkovič <salutis@me.com> writes:
> Gregory Heytings <gregory@heytings.org> writes:
>
>> I think that's no longer true, LanguageTool is available (and has been for
>> ~20 years): https://github.com/languagetool-org/languagetool . But it's
>> written in Java...
>
> There is also Vale [1], a program written in Go and released under the
> MIT license. It now even supports the Org mode format (along with
> Markdown, AsciiDoc, reStructuredText, HTML, and XML).
>
> [1] https://github.com/errata-ai/vale
This seems to be on a different level than what LanguageTool does. Vale
and other alternatives are style-checkers that catch mistakes matching
some fixed rules, without any "understanding" (linguistic model) of the
underlying language. IIUC it could be compared to font-locking using
regular expressions or a library like Tree Sitter.
^ permalink raw reply [relevance 99%]
* Re: Request to add Package to GNU ELPA
2023-04-05 18:07 99% ` Philip Kaludercic
@ 2023-04-05 18:26 79% ` Philip Kaludercic
2023-04-05 21:08 58% ` Philip Kaludercic
1 sibling, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-04-05 18:26 UTC (permalink / raw)
To: Jonas Bernoulli; +Cc: emacs-devel
(I apologise for the last message, accidentally sent it out before
writing anything (somehow?))
Jonas Bernoulli <jonas@bernoul.li> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Jonas Bernoulli <jonas@bernoul.li> writes:
>>
>>> Philip Kaludercic <philipk@posteo.net> writes:
>>>
>>>> Jonas Bernoulli <jonas@bernoul.li> writes:
>>>>
>
>>> Going one step further we could make package-vc available as a separate
>>> package. That would not be of much use *now*, but future improvements
>>> would then be available to users of Emacs 29.
>>
>> I would in principle be interested in supporting this.
>
> I am hoping that someone would take charge of Package on Emacs' side,
> and bring some new momentum to its development. You would be a good
> candidate for that. ;D
I am glad to help where I can (e.g. making sure that package.el can be
distributed on ELPA), but I don't know exactly what you have in mind
with the other changes so I would rather let you tackle those issues.
> Your package-vc is welcome addition (I haven't really tried it, since
> my Borg serves me well) and Stefan certainly put a lot of work into his
> elpa-admin, but Package itself has been a bit stagnant.
>
> [I myself contribute to a lot of elisp packaging related projects, and
> do not plan to take on any new responsibilities; in fact I am trying
> to reduce them.]
>>> I had a look at vc-clone and a few vc-*-clone. They seem trivial
>>> enough to backport, either as part of Compat or in package-vc.el.
>>
>> [...]
>
> I assume that means "well it may *seem* that way, but if you are the one
> actually doing the work...". I know the feeling. oO
I am not sure what you are talking about here?
[...]
>>>>> - I should also mention that my main motivation for pushing for this
>>>>> now, is that I would like to improve version handling. That is a
>>>>> whole other can of worms, so I do not wish to discuss it just yet,
>>>>> to avoid distracting from the topic at hand, but I thought I should
>>>>> at least mention it. You might very well end up being against my
>>>>> suggestions regarding versions strings, once I present them, but that
>>>>> should not be cause to oppose the change requested here as well. Even
>>>>> if my suggestions regarding version strings are ultimately rejected, I
>>>>> still think it would be a good idea to add `package' to GNU ELPA, for
>>>>> the other reasons presented here.
>>>>
>>>> This implies that packages might themselves depend on newer versions of
>>>> package.el -- which I think one should put some thought into before
>>>> anything is done.
>>>
>>> How so? (Further down I suggest making some popular packages temporarily
>>> depend on Package from GNU Elpa as a means to get that installed as
>>> widely as possible, but that doesn't mean that those packages actually
>>> *need* a newer Package.)
>>>
>>>> How can you e.g. change the way versions are handled
>>>> in a way that people with older versions of package.el could still
>>>> handle the change without confusion?
>>>
>>> You can't, and that is exactly the point I was trying to make. Certain
>>> things (including, but not limited to how version strings are handled)
>>> are effectively set in stone, unless certain packages/features are made
>>> available to users who, for whatever reason, stick to an old Emacs
>>> release.
>>
>> Other than the version, it seems the other big one is the dependency
>> list. Is there anything else that could cause issues?
>
> I can't think of any right now, but that of course doesn't mean we won't
> discover any later on.
Right, I was just thinking that it would make sense to have some list.
>>>> The upgrading procedure for archive-contents has never appeared to me to
>>>> be very robust. Perhaps it would be better to introduce a second file
>>>> (archive-contents.eld) with a more flexible format?
>>>
>>> An effort was made to provide an upgrade procedure -- the
>>> "archive-contents" were prefixed with a version number. But then
>>> package.el was added to Emacs and we stopped to distribute it
>>> separately. Apparently we didn't realize at the time that this only
>>> allowed us to tell the user "the archive and tool are not compatible,
>>> deal with it".
>>
>> What could be done instead? Should the updated version of package.el
>> try to install a newer version of itself in case the version string is
>> updated?
>
> Yes, that's what I had in mind.
Sounds good.
>>> We could continue to distribute "archive-contents", which continues to
>>> use version 1, and add "archive-contents.eld" which uses version 2.
>>> But that would do nothing to get users to install a forward-compatible
>>> version of Package (in the sense that once it becomes incompatible, it
>>> will provide a smooth upgrade path to the new version).
>>
>> This seems like the better option to me. Most people don't /need/ the
>> newest version right away, and even if they did there would be no
>> straightforward way of making sure all users would have it installed
>> within some fixed time-frame.
>
> We keep "archive-contents" going for as long as possible. For the final
> push to get users to upgrade, all packages except Package and its
> dependencies could be removed from "archive-contents". A pseudo package
> could be added, whose summary (displayed in the list) and commentary
> (displayed by describe-package) could be used to instruct users to
> upgrade Package, and how.
OK, but this is something I don't expect to take place soon.
>>> (We should invest some time to investigate how to make this as smooth
>>> as possible, but basically:)
>>>
>>> - 1. wget https://...package-2.0.0.tar
>>> 2. tar -xf package-2.2.0.tar -C ~/.config/emacs/elpa/
>>> 3. Restart Emacs and run package-refresh-contents again.
>>
>> This is exactly what I would like to avoid.
>
> I am certainly interested in hearing better ideas.
For one thing an Elisp script would be preferable to avoid issues with
people who might not have wget or a specific version of tar installed.
But otherwise I would just try and avoid the need to force users to
upgrade. Upgrading should be incentivized with the advantages of doing
so, not the issues of (perhaps unconsciously) holding back.
>> What happens when the .tar disappears and some user tries to fix this
>> issue in a few years with these outdated instructions?
>
> We should prevent that. The tar file mentioned in the upgrade
> instructions doesn't have to be hosted in the usual location only.
> It could additionally be hosted somewhere else on gnu.org, where it
> is safe from being discarded by elpa-admin or some cleanup script
> that isn't aware of this special case.
>
>> What if they use .emacs.d or some other directory? For while there
>> will be plenty of users that will figure this out, I know many others
>> will be confused
>
> Well, these steps were the executive summary, the instructions actually
> shown to users should of course be more detailed and account for such
> differences.
>
>> (this also makes me think that a v2 should have support for some kind
>> of MOTD system to explain issues like these).
>
> +1
>
>> So again, what would be the issue with an opt-in system to upgrading
>> package.el, that could also be pushed forward by a few popular packages,
>> without the need to break anything.
>
> I am not against a long transitional phase, but I think that eventually
> we will want to make some breaking change.
>
> One example of an incompatible change is a change in how version strings
> are handled. As I said, I would like to advocate that in a separate
> thread. Here, it is just serves as an example, other incompatible
> changes may become desirable. Just the gist of it:
>
> For a while [Non]GNU-devel ELPA used this version string format:
>
> VERSION.0-snapshotTIMESTAMP
>
> "snapshot" has to be used because "archive-contents" contains the
> version string in list format, e.g., (1 2 3 0 -4 20230405 111). All of
> "snapshot", "cvs", "git", "bzr", "svn", "hg", "darcs" and "unknown" are
> encoded as -4 in the list format, but package-version-join maps it to
> "snapshot".
>
> That leads to very long version strings, which I assume is why Stefan
> switched to just
>
> VERSION.0.TIMESTAMP
>
> The ".0" serves as a pseudo separator. Currently "1.0-snapshot" is
> *smaller* than "1.0". If we inject an additional ".0" then it is
> smaller than "N.0", but not smaller than "N".
>
> I would like to use a format that not only supported "pre-releases" but
> also "post-releases". Debian uses "post-releases" to implement
> "debian-revision" [1]; we could use it to separate the "timestamp" part
> from "latest released upstream version" part, in snapshot release
> version strings.
>
> [1]: https://manpages.debian.org/wheezy/dpkg-dev/deb-version.5.en.html
>
> But again, maybe I am the only who feels a need to do something about
> that; in this context it is just an example of a change that would break
> backward compatibility; to demonstrate that some potential changes could
> not be made merely opt-in, but instead would have to be either rolled
> out to everyone or nobody.
I cannot comment on this, but "post-releases" (as opposed to
"pre-releases") sounds like just another entry in `version-regexp-alist'?
> Jonas
So to summarise, I think an approximate plan would be useful:
1. Update package.el to be published on ELPA
2. (Optional) Update package-vc.el to be published on ELPA
3. Specify and implement a new package-archives format
4. Update package archives to generate the new archive format
Anything I am forgetting?
^ permalink raw reply [relevance 79%]
* Re: Request to add Package to GNU ELPA
@ 2023-04-05 18:07 99% ` Philip Kaludercic
2023-04-05 18:26 79% ` Philip Kaludercic
1 sibling, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-04-05 18:07 UTC (permalink / raw)
To: Jonas Bernoulli; +Cc: emacs-devel
Jonas Bernoulli <jonas@bernoul.li> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Jonas Bernoulli <jonas@bernoul.li> writes:
>>
>>> Philip Kaludercic <philipk@posteo.net> writes:
>>>
>>>> Jonas Bernoulli <jonas@bernoul.li> writes:
>>>>
>
>>> Going one step further we could make package-vc available as a separate
>>> package. That would not be of much use *now*, but future improvements
>>> would then be available to users of Emacs 29.
>>
>> I would in principle be interested in supporting this.
>
> I am hoping that someone would take charge of Package on Emacs' side,
> and bring some new momentum to its development. You would be a good
> candidate for that. ;D
>
> Your package-vc is welcome addition (I haven't really tried it, since
> my Borg serves me well) and Stefan certainly put a lot of work into his
> elpa-admin, but Package itself has been a bit stagnant.
>
> [I myself contribute to a lot of elisp packaging related projects, and
> do not plan to take on any new responsibilities; in fact I am trying
> to reduce them.]
>
>>> I had a look at vc-clone and a few vc-*-clone. They seem trivial
>>> enough to backport, either as part of Compat or in package-vc.el.
>>
>> [...]
>
> I assume that means "well it may *seem* that way, but if you are the one
> actually doing the work...". I know the feeling. oO
>
>>> [using a bleeding edge *ELPA]
>>
>> My experience was not that good, especially back before I got into Emacs
>> development (or understood what was going on at all) I constantly ran
>> into issues when updating packages from MELPA. The result was that I'd
>> usually just not update packages at all for long periods of time. The
>> next best thing for me was MELPA stable until NonGNU ELPA came around.
>
> Using MELPA stable comes with its own problems. MELPA's maintainers
> advice users to stick to the bleeding-edge variant and use that
> themselves. And many users take that advice to heart, and many
> developers are aware of that and act accordingly.
>
> I don't think anyone is against moving towards relying more on released,
> stable versions, but there seem to be some chicken and eggs involved.
> We can all do a little bit to get closer to a more stable ecosystem, but
> it will take time.
>
> [I expect that once MELPA starts using sane version strings for snapshot
> packages, that will be a big step in that direction, because that makes
> it much simpler to properly specify the minimal required versions of
> dependencies, that work for both the bleeding-edge and stable channels.
>
> I am in fact working on that right now. I was about to start rebuild
> all packages for testing purposes, but briefly got distracted by your
> reply to this. :P
>
> But there are other areas where improvements are needed, and I would
> like to leave it to others to tackle those.]
>
>>>>> - I should also mention that my main motivation for pushing for this
>>>>> now, is that I would like to improve version handling. That is a
>>>>> whole other can of worms, so I do not wish to discuss it just yet,
>>>>> to avoid distracting from the topic at hand, but I thought I should
>>>>> at least mention it. You might very well end up being against my
>>>>> suggestions regarding versions strings, once I present them, but that
>>>>> should not be cause to oppose the change requested here as well. Even
>>>>> if my suggestions regarding version strings are ultimately rejected, I
>>>>> still think it would be a good idea to add `package' to GNU ELPA, for
>>>>> the other reasons presented here.
>>>>
>>>> This implies that packages might themselves depend on newer versions of
>>>> package.el -- which I think one should put some thought into before
>>>> anything is done.
>>>
>>> How so? (Further down I suggest making some popular packages temporarily
>>> depend on Package from GNU Elpa as a means to get that installed as
>>> widely as possible, but that doesn't mean that those packages actually
>>> *need* a newer Package.)
>>>
>>>> How can you e.g. change the way versions are handled
>>>> in a way that people with older versions of package.el could still
>>>> handle the change without confusion?
>>>
>>> You can't, and that is exactly the point I was trying to make. Certain
>>> things (including, but not limited to how version strings are handled)
>>> are effectively set in stone, unless certain packages/features are made
>>> available to users who, for whatever reason, stick to an old Emacs
>>> release.
>>
>> Other than the version, it seems the other big one is the dependency
>> list. Is there anything else that could cause issues?
>
> I can't think of any right now, but that of course doesn't mean we won't
> discover any later on.
>
>>>> The upgrading procedure for archive-contents has never appeared to me to
>>>> be very robust. Perhaps it would be better to introduce a second file
>>>> (archive-contents.eld) with a more flexible format?
>>>
>>> An effort was made to provide an upgrade procedure -- the
>>> "archive-contents" were prefixed with a version number. But then
>>> package.el was added to Emacs and we stopped to distribute it
>>> separately. Apparently we didn't realize at the time that this only
>>> allowed us to tell the user "the archive and tool are not compatible,
>>> deal with it".
>>
>> What could be done instead? Should the updated version of package.el
>> try to install a newer version of itself in case the version string is
>> updated?
>
> Yes, that's what I had in mind.
>
>>> We could continue to distribute "archive-contents", which continues to
>>> use version 1, and add "archive-contents.eld" which uses version 2.
>>> But that would do nothing to get users to install a forward-compatible
>>> version of Package (in the sense that once it becomes incompatible, it
>>> will provide a smooth upgrade path to the new version).
>>
>> This seems like the better option to me. Most people don't /need/ the
>> newest version right away, and even if they did there would be no
>> straightforward way of making sure all users would have it installed
>> within some fixed time-frame.
>
> We keep "archive-contents" going for as long as possible. For the final
> push to get users to upgrade, all packages except Package and its
> dependencies could be removed from "archive-contents". A pseudo package
> could be added, whose summary (displayed in the list) and commentary
> (displayed by describe-package) could be used to instruct users to
> upgrade Package, and how.
>
>>> (We should invest some time to investigate how to make this as smooth
>>> as possible, but basically:)
>>>
>>> - 1. wget https://...package-2.0.0.tar
>>> 2. tar -xf package-2.2.0.tar -C ~/.config/emacs/elpa/
>>> 3. Restart Emacs and run package-refresh-contents again.
>>
>> This is exactly what I would like to avoid.
>
> I am certainly interested in hearing better ideas.
>
>> What happens when the .tar disappears and some user tries to fix this
>> issue in a few years with these outdated instructions?
>
> We should prevent that. The tar file mentioned in the upgrade
> instructions doesn't have to be hosted in the usual location only.
> It could additionally be hosted somewhere else on gnu.org, where it
> is safe from being discarded by elpa-admin or some cleanup script
> that isn't aware of this special case.
>
>> What if they use .emacs.d or some other directory? For while there
>> will be plenty of users that will figure this out, I know many others
>> will be confused
>
> Well, these steps were the executive summary, the instructions actually
> shown to users should of course be more detailed and account for such
> differences.
>
>> (this also makes me think that a v2 should have support for some kind
>> of MOTD system to explain issues like these).
>
> +1
>
>> So again, what would be the issue with an opt-in system to upgrading
>> package.el, that could also be pushed forward by a few popular packages,
>> without the need to break anything.
>
> I am not against a long transitional phase, but I think that eventually
> we will want to make some breaking change.
>
> One example of an incompatible change is a change in how version strings
> are handled. As I said, I would like to advocate that in a separate
> thread. Here, it is just serves as an example, other incompatible
> changes may become desirable. Just the gist of it:
>
> For a while [Non]GNU-devel ELPA used this version string format:
>
> VERSION.0-snapshotTIMESTAMP
>
> "snapshot" has to be used because "archive-contents" contains the
> version string in list format, e.g., (1 2 3 0 -4 20230405 111). All of
> "snapshot", "cvs", "git", "bzr", "svn", "hg", "darcs" and "unknown" are
> encoded as -4 in the list format, but package-version-join maps it to
> "snapshot".
>
> That leads to very long version strings, which I assume is why Stefan
> switched to just
>
> VERSION.0.TIMESTAMP
>
> The ".0" serves as a pseudo separator. Currently "1.0-snapshot" is
> *smaller* than "1.0". If we inject an additional ".0" then it is
> smaller than "N.0", but not smaller than "N".
>
> I would like to use a format that not only supported "pre-releases" but
> also "post-releases". Debian uses "post-releases" to implement
> "debian-revision" [1]; we could use it to separate the "timestamp" part
> from "latest released upstream version" part, in snapshot release
> version strings.
>
> [1]: https://manpages.debian.org/wheezy/dpkg-dev/deb-version.5.en.html
>
> But again, maybe I am the only who feels a need to do something about
> that; in this context it is just an example of a change that would break
> backward compatibility; to demonstrate that some potential changes could
> not be made merely opt-in, but instead would have to be either rolled
> out to everyone or nobody.
>
> Jonas
^ permalink raw reply [relevance 99%]
* Re: jinx
@ 2023-04-05 9:02 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-04-05 9:02 UTC (permalink / raw)
To: Richard Stallman; +Cc: Michael Heerdegen, emacs-devel
Richard Stallman <rms@gnu.org> writes:
> [[[ To any NSA and FBI agents reading my email: please consider ]]]
> [[[ whether defending the US Constitution against all enemies, ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> > > Is it possible to rename this to a clearer name? Perhaps
> > > program-text-flyspell-mode, or something else? And then make it a
> > > proper major mode?, following all the conventions for major modes?
>
> > A major mode?? I think you misunderstood what it does. It's simply a
> > slightly modified flyspell-mode, conceptually clearly a minor-mode,
>
> I stand corrected.
>
> But the name is still unhelpful. It seems to enable Flyspell mode for
> strings and comments only. But you'd never guess that from its name.
> The name suggests it is a mode function, but I doesn't follow the
> conventions for those.
>
> Can those things be corrected?
It should be possible to add a defalias with a different name, but
personally I don't think the name is that confusing. The docstring is
pretty clear as well. Then again, I know about prog-mode which is
something that newcomers might not?
^ permalink raw reply [relevance 99%]
* Re: Request to add Package to GNU ELPA
@ 2023-04-05 8:59 71% ` Philip Kaludercic
2023-04-17 16:24 99% ` Adding package-vc to ELPA Philip Kaludercic
0 siblings, 2 replies; 200+ results
From: Philip Kaludercic @ 2023-04-05 8:59 UTC (permalink / raw)
To: Jonas Bernoulli; +Cc: emacs-devel
Jonas Bernoulli <jonas@bernoul.li> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Jonas Bernoulli <jonas@bernoul.li> writes:
>>
>>> Hello,
>>
>> Hi, hope I can add a few useful comments here.
>>
>>> I would like to request that "package.el" be added to GNU Elpa as a
>>> "core" package. This would make new features available to users who are
>>> stuck on older Emacs releases and it would even bring us one step closer
>>> to being able to make backward incompatible changes in the future.
>>>
>>> Some examples for why that would be desirable:
>>>
>>> - A recent addition that could be useful is the new "package-vc.el"
>>> (which I think should be distributed as part of the `package' package,
>>> but it could also be distributed as a separate core package).
>>
>> This will be difficult, since package-vc depends on the new "vc-clone"
>> function, which would also have to be provided on ELPA to work.
>
> The simplest way to deal with that, while still making the latest
> Package available to users of older Emacs releases, would be to *not*
> include package-vc.el in the Package package.
>
> Going one step further we could make package-vc available as a separate
> package. That would not be of much use *now*, but future improvements
> would then be available to users of Emacs 29.
I would in principle be interested in supporting this.
> I had a look at vc-clone and a few vc-*-clone. They seem trivial
> enough to backport, either as part of Compat or in package-vc.el.
[...]
>> All of this touches on the general topic of how Emacs should be
>> developed: Small and to be extended, therefore of little use OOTB or big
>> and feature-full, but slow to be updated. IIUC a compromise could be
>> achieved by having two versions of Emacs that would respectively attempt
>> to satisfy the two aspirations.
>
> This doesn't sound like a good idea to me because I doubt that it would
> have the benefits you seem to expect. A sizable portion of an external
> package would choose to use the slow-moving Emacs. So the maintainer of
> the package would have to continue to support that, similar to how they
> now have to support older releases. So even though there would be a
> fast-moving Emacs, they still would not be able to take full advantage
> of the new/improved features it provides. The situation would be
> basically the same as now; but not supporting the slow-moving Emacs
> would be even harder to justify than dropping support for Emacs 25.1.
I am not really advocating for one or the other option, just wanted to
bring it up, if for nobody else then just for people lurking the mailing
list.
>> There was some work in that direction a
>> few years ago[0], but I don't know if anything has happened since.
>> Perhaps pushing for this more general solution would help solve this
>> particular problem?
>>
>> [0] https://git.savannah.gnu.org/cgit/emacs.git/log/?h=elparized-core
>
> I remember that there was some talk about moving in that direction, and
> I am in favor and have been patiently waiting for someone to make
> another push in that direction, but things indeed seem to have fizzled
> out.
>
> Meanwhile making certain packages available on a case by case basis does
> not seem like a bad idea to me. It doesn't mean that we *commit* to
> making "most" packages available like that eventually, so even those you
> are opposed to that idea might be able to agree to doing it selectively.
> Doing it for a select few packages, allows us to gain some experience,
> whether that be bad or good.
True.
>>> That isn't just useful for users who like to live on the edge. For
>>> example, if a package drops support for an old Emacs release, then
>>> a user who is stuck on that release, may wish to keep using the last
>>> release of the package that still supports that Emacs release, and
>>> package-vc would allow them to do just that.
>>>
>>> - I don't use Package myself, so I am not fully aware of all the quality
>>> of live enhancements that surely have accumulated over the years. But
>>> I am aware of some small missing features, that would be beneficial to
>>> users of older Emacs releases.
>>>
>>> - For example, I think it would be nice if the columns displayed by
>>> `list-packages' were customizable. A user might want to increase the
>>> width of the "Version" column, so that not every GNU-devel ELPA version
>>> is truncated,
>>
>> A more general solution to this problem would be if tabulated-list-mode
>> could dynamically resize a column, or at least shrink it possible.
>
> That would indeed be nice ... and would make tabulated-list-mode another
> candidate for GNU ELPA. ;P
It seems like this is possible, or at least I didn't see any difficult
dependencies from a brief skim.
>> Also on another topic, I am still uncertain as to the status of the
>> -devel archives. I see them primarily as a means for developers to
>> check the status of a package pre-release or to make sure that the ELPA
>> build-system is working the way they want it to (e.g. when building
>> manuals, news or README files). They are not advertised anywhere, and I
>> don't think they are made for general consumption -- or rather I don't
>> think they should be, especially with package-vc there is a much better
>> way to track development and make it possible to contribute changes
>> upstream.
>
> Most packages still get installed through Melpa these days and that
> means installing the latest commit from the development branch. (The
> [Non]GNU-devel ELPA variants probably exist in part to satisfy users who
> are used to having access to the development version through "regular"
> package i.e., without using package-vc.)
>
> In my experience that seems to work surprisingly well; I can't really
> remember any regressions that were not fixed almost instantly, but that
> does of course depend on what packages one has installed. I am sure
> little regressions happen all the time, but they get fixed so quickly,
> that any one user usually doesn't notice. In my experience, using the
> development versions of some quality packages, is no different from
> using the development version of Emacs itself.
My experience was not that good, especially back before I got into Emacs
development (or understood what was going on at all) I constantly ran
into issues when updating packages from MELPA. The result was that I'd
usually just not update packages at all for long periods of time. The
next best thing for me was MELPA stable until NonGNU ELPA came around.
> But I agree that it would be better to release more often (and yes, I
> am guilty of not doing that myself), and tend to agree that it would be
> better if, in the long run, the community moved towards relying more on
> released versions.
>
> At the same time I don't think that the fact that we are not there yet
> is due to "mistakes". Emacs/Elisp is different from other "languages",
> in that everything runs in the same process, and that is at least one
> of the causes of the status quo.
>
> We cannot really use multiple versions of the same library in different
> parts of Emacs, in the same way one Python or Rust application could
> use xyz-v1 and another, related but independent, application could use
> xyz-v2. If one package depends on xyz-v2 but there were incompatible
> changes in that release and, another package has not been updated yet to
> support xyz-v2, then those two packages cannot be used at the same time.
>
> Again, that does not seem to happen very often, and I think that is
> partially the case because the hold out package can be quickly updated
> to support v2 on its development branch, *without* also having to do a
> release, which the maintainers might not wish to do due to where in its
> own release-cycle the package happens to be.
>
>>> - I should also mention that my main motivation for pushing for this
>>> now, is that I would like to improve version handling. That is a
>>> whole other can of worms, so I do not wish to discuss it just yet,
>>> to avoid distracting from the topic at hand, but I thought I should
>>> at least mention it. You might very well end up being against my
>>> suggestions regarding versions strings, once I present them, but that
>>> should not be cause to oppose the change requested here as well. Even
>>> if my suggestions regarding version strings are ultimately rejected, I
>>> still think it would be a good idea to add `package' to GNU ELPA, for
>>> the other reasons presented here.
>>
>> This implies that packages might themselves depend on newer versions of
>> package.el -- which I think one should put some thought into before
>> anything is done.
>
> How so? (Further down I suggest making some popular packages temporarily
> depend on Package from GNU Elpa as a means to get that installed as
> widely as possible, but that doesn't mean that those packages actually
> *need* a newer Package.)
>
>> How can you e.g. change the way versions are handled
>> in a way that people with older versions of package.el could still
>> handle the change without confusion?
>
> You can't, and that is exactly the point I was trying to make. Certain
> things (including, but not limited to how version strings are handled)
> are effectively set in stone, unless certain packages/features are made
> available to users who, for whatever reason, stick to an old Emacs
> release.
Other than the version, it seems the other big one is the dependency
list. Is there anything else that could cause issues?
>> (This will be an issue for at
>> least a decade to come, knowing the pace at which users get access to
>> newer versions of Emacs). You mentioned updating the ELPA protocol a
>> few months back, and I believe a few points of interest were collected
>> in that thread. It seems to me these issues are all intertwined.
>
> Yes indeed, they are all intertwined, and I am trying to make the point
> that we have to stop muddling along once in a while, and make a breaking
> change, even if the transition is rough and inconveniences users for a
> while.
>
>> With Emacs 29, `package-refresh-contents' now calls a Hook called
>> `package-refresh-contents-hook'. This was initially introduced so that
>> package-vc can download the "elpa-packages.eld" file, but it could also
>> be of use here as well -- but it wouldn't help anyone with Emacs 28 or
>> older... I could imagine a more hacky approach based on carefully
>> placed advice, but only as a last resort.
>
> We cannot travel back in time to fix past mistakes/omissions that are
> holding us back in the presence. All we can do now is to pay the price
> and try harder to be forward compatible this time around. Or live with
> the limitations forever. Or wait some more until they become unbearable
> and a fix more urgent; but that would increase the odds of messing it up
> again.
2+
>>> Addressing (1) is harder, and I don't think it possible to do so in a
>>> way that guarantees that not a single user would end up seeing an error
>>> due to an incompatible change. On the other hand "archive-contents"
>>> comes with a version field, and if we bump that, we at least get a
>>> meaningful warning: "Package archive version 2 is higher than 1". This
>>> doesn't say that the solution is to install `package' from GNU ELPA, but
>>> it should be enough to feed into a search engine to get to that answer.
>>
>> The upgrading procedure for archive-contents has never appeared to me to
>> be very robust. Perhaps it would be better to introduce a second file
>> (archive-contents.eld) with a more flexible format?
>
> An effort was made to provide an upgrade procedure -- the
> "archive-contents" were prefixed with a version number. But then
> package.el was added to Emacs and we stopped to distribute it
> separately. Apparently we didn't realize at the time that this only
> allowed us to tell the user "the archive and tool are not compatible,
> deal with it".
What could be done instead? Should the updated version of package.el
try to install a newer version of itself in case the version string is
updated?
> We could continue to distribute "archive-contents", which continues to
> use version 1, and add "archive-contents.eld" which uses version 2.
> But that would do nothing to get users to install a forward-compatible
> version of Package (in the sense that once it becomes incompatible, it
> will provide a smooth upgrade path to the new version).
This seems like the better option to me. Most people don't /need/ the
newest version right away, and even if they did there would be no
straightforward way of making sure all users would have it installed
within some fixed time-frame.
>>> Additionally, we could get many users to install `package' from GNU
>>> ELPA, by making a few popular packages explicitly depend on a `package'
>>> version that is available from GNU ELPA for a few months.
>>
>> Again, a few months wouldn't be enough to solve the issue. But again as
>> well, Compat could help by adding package as a noop dependency.
>
> Much like your "archive-contents.eld" suggestion, doing this would not
> *solve* the issue. Unlike that, it would however significantly reduce
> the number of users who would be negatively affected by the upgrade.
> (We could do it for a few years instead of months to further decrease
> the number of affected users.)
You are probably right.
> I love Compat, but I don't think it is the right hammer here (except
> maybe for the part where it could provide vc-clone et al.).
>
> Maybe it helps to make it explicit what is going to happen to users
> if/when all the *ELPA start to expect that package.el support
> "archive-contents" v2.
>
> - The user runs "M-x package-refresh-contents" and is told "Package
> archive version 2 is higher than 1".
>
> - They ask a search engine what that means. We could create a few blog
> and forum posts before hand and give the search engines a few days to
> index them, providing the following instructions:
>
> (We should invest some time to investigate how to make this as smooth
> as possible, but basically:)
>
> - 1. wget https://...package-2.0.0.tar
> 2. tar -xf package-2.2.0.tar -C ~/.config/emacs/elpa/
> 3. Restart Emacs and run package-refresh-contents again.
This is exactly what I would like to avoid. What happens when the .tar
disappears and some user tries to fix this issue in a few years with
these outdated instructions? What if they use .emacs.d or some other
directory? For while there will be plenty of users that will figure
this out, I know many others will be confused (this also makes me think
that a v2 should have support for some kind of MOTD system to explain
issues like these).
So again, what would be the issue with an opt-in system to upgrading
package.el, that could also be pushed forward by a few popular packages,
without the need to break anything.
> Cheers,
> Jonas
^ permalink raw reply [relevance 71%]
* Re: How to install documentation in sub-directory with Package VC?
@ 2023-04-05 7:30 82% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-04-05 7:30 UTC (permalink / raw)
To: Okamsn; +Cc: Eli Zaretskii, emacs-devel
Okamsn <okamsn@protonmail.com> writes:
>>> +@example
>>> +@group
>>> +(package-vc-install 'csv-mode)
>>> +@end group
>>> +@end example
>>> +
>>> +The second way is to specify this information manually in the first
>>> +argument of @code{package-vc-install}, in the form of
>>> +@samp{(@var{name} . @var{spec})}. @var{spec} should be a property
>>> +list using any of the following keys:
>>> +
>>> +@itemize @bullet
>>> +@item @code{:url}
>>> +A URL specifying the repository from which to fetch the package's
>>> +source code.
>>> +
>>> +@item @code{:branch}
>>> +The name of the branch to checkout after cloning the directory.
>>
>> At the risk of being pedantic, we check out the right branch /while/
>> cloning, not /after/ cloning and I don't know if that matters. (I also
>> just now noticed that I used the same phrasing in the documentation
>> string for `package-vc-selected-packages').
>
> I tried to do as Eli Zaretskii asked and changed it to be less Git
> specific. Does it still convey what you want?
I think it is fine now. Thanks.
[...]
> From 0024726c24f16976f1b472afe8e079e5892517b5 Mon Sep 17 00:00:00 2001
> From: Earl Hyatt <okamsn@protonmail.com>
> Date: Mon, 27 Mar 2023 20:57:31 -0400
> Subject: [PATCH] Add more documentation for the keys of
> `package-vc-selected-packages`.
>
> * doc/emacs/package.texi (Specifying Package Sources): List the
> accepted keys in a new subsection of Fetching Package Sources.
>
> * lisp/emacs-lisp/package-vc.el (package-vc-selected-packages):
> - Mention the `:doc` key. Add the `:doc` key to the Customize form.
> - Mention the new Info node.
> - Correct "TexInfo" to "Texinfo".
> - Avoid Git-specific terms for the description of `:branch`.
> - Mention guessing `:vc-backend` based on the URL.
> ---
> doc/emacs/package.texi | 77 +++++++++++++++++++++++++++++++++++
> lisp/emacs-lisp/package-vc.el | 25 ++++++++----
> 2 files changed, 93 insertions(+), 9 deletions(-)
>
> diff --git a/doc/emacs/package.texi b/doc/emacs/package.texi
> index 7a2bc11d03c..7ad4143d3cb 100644
> --- a/doc/emacs/package.texi
> +++ b/doc/emacs/package.texi
> @@ -578,3 +578,80 @@ Fetching Package Sources
> and initializes the code. Note that you might have to use
> @code{package-vc-refresh} to repeat the initialization and update the
> autoloads.
> +
> +@subsection Specifying Package Sources
> +@cindex package specification
> +@cindex specification, for source packages
> +
> + To install a package from source, Emacs must know where to get the
> +package's source code (such as a code repository) and basic
> +information about the structure of the code (such as the main file in
> +a multi-file package). These things are described by a package's
^
a bit informal? I think you can just
drop the word and still convey the same
information.
> +@dfn{specification}.
> +
> + When supported by a package archive (@pxref{Package
> +Archives,,,elisp, The Emacs Lisp Reference Manual}), Emacs can
> +automatically download a package's specification from said archive.
Not sure if this might be confusing. package-vc has heuristics to try
and guess how to install a package, so it is /possible/ but not
/reliable/ to install a package from a third-party archive like MELPA.
Then again, perhaps we don't have to mention that at all in the manual,
so as to not promote an unreliable trick.
> +If the first argument passed to @code{package-vc-install} is a symbol
> +naming a package, then Emacs will use the specification provided by
> +the archive for that package.
> +
> +@example
> +@group
> +;; Emacs will download BBDB's specification from GNU ELPA:
> +(package-vc-install 'bbdb)
> +@end group
> +@end example
> +
> + A package's specification can also be given manually as the first
> +argument to @code{package-vc-install}. This allows you to install
> +source packages from locations other than the known archives listed in
> +the user option @code{package-archives}. A package specification is a
> +list of the form @code{(@var{name} . @var{spec})}, in which @var{spec}
> +should be a property list using any of the following keys.
>
> +For definitions of basic terms for working with code repositories and
> +version control systems, see @xref{VCS Concepts,,,emacs, The GNU Emacs
> +Manual}.
Should this paragraph be moved down below the table? Otherwise the "any
of the following" reads funnily.
> +@table @code
> +@item :url
> +A string containing the URL that specifies the repository from which
> +to fetch the package's source code.
> +
> +@item :branch
> +A string containing the revision of the code to install. This is not
> +to be confused with a package's version number.
> +
> +@item :lisp-dir
> +A string containing the repository-relative name of the directory to
> +use for loading the Lisp sources, which defaults to the root directory
> +of the repository.
> +
> +@item :main-file
> +A string containing the main file of the project, from which to gather
> +package metadata. If not given, the default is the package name with
> +".el" appended to it.
(This is true most of the time, but if you check out what
`package-vc--main-file' does, then you will see that this is not
necessary. Again, I don't think this implementation detail is worth
documenting publicly.)
> +@item :doc
> +A string containing the repository-relative name of the documentation
> +file from which to build an Info file. This can be a Texinfo file or
> +an Org file.
> +
> +@item :vc-backend
> +A symbol naming the VC backend to use for downloading a copy of the
> +package's repository (@pxref{Version Control Systems,,,emacs, The GNU
> +Emacs Manual}). If omitted, a guess will be made based on the
> +provided URL, or, failing that, the process will fall back onto the
> +value of @code{package-vc-default-backend}.
> +@end table
> +
> +@example
> +@group
> +;; Specifying information manually:
> +(package-vc-install
> + '(bbdb :url "https://git.savannah.nongnu.org/git/bbdb.git"
> + :lisp-dir "lisp"
> + :doc "doc/bbdb.texi"))
> +@end group
> +@end example
> diff --git a/lisp/emacs-lisp/package-vc.el b/lisp/emacs-lisp/package-vc.el
> index 253b35f1f1a..cbc9a1ecece 100644
> --- a/lisp/emacs-lisp/package-vc.el
> +++ b/lisp/emacs-lisp/package-vc.el
> @@ -152,25 +152,31 @@ package-vc-selected-packages
> The URL of the repository used to fetch the package source.
>
> `:branch' (string)
> - If given, the name of the branch to checkout after cloning the directory.
> + The repository-specific revision of the code to install.
> + This is not to be confused with a package's version number.
>
> `:lisp-dir' (string)
> The repository-relative name of the directory to use for loading the Lisp
> - sources. If not given, the value defaults to the root directory
> - of the repository.
> + sources, which defaults to the root directory of the repository.
>
> `:main-file' (string)
> The main file of the project, relevant to gather package metadata.
> - If not given, the assumed default is the package name with \".el\"
> + If not given, the default is the package name with \".el\"
> appended to it.
>
> + `:doc' (string)
> + The documentation file from which to build an Info file.
> + This can be a Texinfo file or an Org file.
> +
> `:vc-backend' (symbol)
> - A symbol of the VC backend to use for cloning the package. The
> - value ought to be a member of `vc-handled-backends'. If omitted,
> - `vc-clone' will fall back onto the archive default or on
> - `package-vc-default-backend'.
> + A symbol of the VC backend to use for cloning the package.
> + The value ought to be a member of `vc-handled-backends'.
> + If omitted, a guess will be made based on the provided URL,
> + or, failing that, `vc-clone' will fall back onto the
> + archive default or on `package-vc-default-backend'.
>
> - All other keys are ignored.
> + All other keys are ignored. Package specifications are further
> + described in the Info node `(emacs)Fetching Package Sources'.
I believe I mentioned this before, but what do you think about just
linking to the manual, and not duplicating the information here and
there? It would make maintenance easier, but might not be nice for
users on systems that do not come installed with documentation like
Debian... Then again, this wouldn't be the only place where this would
affect users.
> This user option will be automatically updated to store package
> specifications for packages that are not specified in any
> @@ -184,6 +190,7 @@ package-vc-selected-packages
> (:branch string)
> (:lisp-dir string)
> (:main-file string)
> + (:doc string)
> (:vc-backend symbol)))))
> :version "29.1")
^ permalink raw reply [relevance 82%]
* Re: Grammar checking
@ 2023-03-31 15:29 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-03-31 15:29 UTC (permalink / raw)
To: Peter Oliver; +Cc: Gregory Heytings, Lynn Winebarger, emacs-devel
Peter Oliver <p.d.oliver@mavit.org.uk> writes:
>> The zip file above contains the three versions of the program: GUI,
>> client-server, and command-line.
>
> The command-line tool takes too long to start to be of practical use to us.
Why? If it were to be used asynchronously, it could start up in the
background and the results would be displayed when it finds something?
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Grammar checking
@ 2023-03-31 15:25 95% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-03-31 15:25 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gregory, rms, m.eliachevitch, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: Gregory Heytings <gregory@heytings.org>, rms@gnu.org,
>> m.eliachevitch@posteo.de, emacs-devel@gnu.org
>> Date: Fri, 31 Mar 2023 07:47:15 +0000
>>
>> There is an implementation[0], but I found it to be awkward to work
>> with.
>
> Can you share more details? what is "awkward" about it?
From what I recall, getting the server to run and recognise additional
grammar-rule databases like German wasn't that easy (though I might have
also just messed something up). That if all I had to do was run
$ apt install language-tool language-tool-de
that this part would have been easier. The Emacs package did the job,
but had a ispell instead of a flyspell-like interface. Better than
nothing, but a fly... interface would be nice to have, if it is
technically possible.
> In any case, we don't have to use the Emacs interface as-is, we could
> write our own.
--
Philip Kaludercic
^ permalink raw reply [relevance 95%]
* Re: Grammar checking
@ 2023-03-31 8:38 99% ` Philip Kaludercic
1 sibling, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-03-31 8:38 UTC (permalink / raw)
To: Gregory Heytings; +Cc: Eli Zaretskii, rms, m.eliachevitch, emacs-devel
Gregory Heytings <gregory@heytings.org> writes:
>> One of the main annoyances is that LanguageTool does not appear to
>> be widely packaged[2].
>
> Why would it be necessary to package it? It's a Java app, you can
> download it from here:
>
> https://languagetool.org/download/LanguageTool-stable.zip
>
> and run it everywhere (provided you have a JVM installed, of course).
I am not saying it is necessary, just that it would be more convenient
if I wouldn't have to manually set it up and keep it up to date.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Grammar checking
@ 2023-03-31 7:47 97% ` Philip Kaludercic
1 sibling, 2 replies; 200+ results
From: Philip Kaludercic @ 2023-03-31 7:47 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Gregory Heytings, rms, m.eliachevitch, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> Date: Fri, 31 Mar 2023 07:10:11 +0000
>> From: Gregory Heytings <gregory@heytings.org>
>> cc: rms@gnu.org, m.eliachevitch@posteo.de, emacs-devel@gnu.org
>>
>> > As an aside, a technology I would like to see in Emacs is grammar
>> > checking. Last I looked, there are no free grammar-checking libraries
>> > or services out there, even just for the English language. But if
>> > that's no longer true, then adding such capabilities to Emacs will be
>> > very welcome, I think, since word-based spell-checking is clearly not
>> > enough these days.
>>
>> I think that's no longer true, LanguageTool is available (and has been for
>> ~20 years): https://github.com/languagetool-org/languagetool . But it's
>> written in Java...
>
> Thanks. Maybe someone will figure out how to integrate this with
> Emacs.
There is an implementation[0], but I found it to be awkward to work
with.
Looking around, I found a second implementation[1], but I cannot comment
on how well it works.
One of the main annoyances is that LanguageTool does not appear to be
widely packaged[2].
[0] https://github.com/mhayashi1120/Emacs-langtool/
[1] https://github.com/PillFall/languagetool.el
[2] https://repology.org/project/languagetool/versions
--
Philip Kaludercic
^ permalink raw reply [relevance 97%]
Results 401-600 of ~1772 next (older) | prev (newer) | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2020-08-23 11:46 Disambiguate modeline character for UTF-8? Ulrich Mueller
2023-07-05 13:44 ` Eli Zaretskii
2023-07-05 21:50 ` Ulrich Mueller
2023-07-06 12:31 ` Po Lu
2023-07-06 13:08 ` Ulrich Mueller
2023-07-06 17:37 ` Paul Eggert
2023-07-06 18:44 ` Ulrich Müller
2023-07-06 19:01 ` Eli Zaretskii
2023-07-06 19:31 ` Ulrich Mueller
2023-07-07 5:18 ` Eli Zaretskii
2023-07-07 5:48 ` Ulrich Müller
2023-07-08 8:49 ` Eli Zaretskii
2023-07-08 15:27 ` Basil Contovounesios
2023-07-08 15:38 ` Eli Zaretskii
2023-07-09 9:22 ` Lisp reader syntax and bootstrap (was: Re: Disambiguate modeline character for UTF-8?) Ulrich Mueller
2023-07-09 9:57 ` Lisp reader syntax and bootstrap Po Lu
2023-07-13 2:04 ` Richard Stallman
2023-07-13 4:27 ` Po Lu
2023-07-13 22:07 ` Paul Eggert
2023-07-15 2:10 ` Richard Stallman
2023-07-15 2:38 ` Po Lu
2023-07-15 5:18 99% ` Philip Kaludercic
2022-05-08 8:34 [ELPA] Add package flymake-rest Mohsin Kaleem
2022-05-08 10:06 ` Philip Kaludercic
2022-05-08 10:17 ` Mohsin Kaleem
2022-05-08 19:09 ` Philip Kaludercic
2022-05-08 21:52 ` Stefan Monnier
2023-04-21 14:22 ` Mohsin Kaleem
2023-04-22 6:51 99% ` Philip Kaludercic
2022-12-16 16:32 [NonGNU ELPA] New package: latex-table-wizard Enrico Flor
2022-12-17 3:23 ` Stefan Monnier
2022-12-17 4:46 ` Enrico Flor
[not found] ` <r0ywGaSHflWmTc9TJLc-K93rYs1W2O4jK5F61JPJW2lwnHimIIYovcz4msDjKwS9UtftAaQhImwDuuKWG0l9XQ==@protonmail.internalid>
2022-12-17 9:56 ` Philip Kaludercic
2023-05-11 21:21 ` Enrico Flor
2023-05-12 5:46 99% ` Philip Kaludercic
2023-05-12 12:30 ` Stefan Monnier
2023-05-12 15:46 99% ` Philip Kaludercic
2023-03-14 3:13 How to install documentation in sub-directory with Package VC? Okamsn
2023-03-14 15:56 ` Philip Kaludercic
2023-03-15 9:41 ` Philip Kaludercic
2023-03-16 1:37 ` Okamsn
2023-03-16 8:44 ` Philip Kaludercic
2023-03-28 1:50 ` Okamsn
2023-03-28 7:41 ` Philip Kaludercic
2023-04-02 0:41 ` Okamsn
2023-04-05 7:30 82% ` Philip Kaludercic
2023-04-06 3:52 ` Okamsn
2023-04-06 15:42 67% ` Philip Kaludercic
2023-04-10 13:39 99% ` Philip Kaludercic
2023-04-12 0:04 ` Okamsn
2023-04-12 7:27 61% ` Philip Kaludercic
2023-04-12 7:41 ` Eli Zaretskii
2023-04-12 7:48 99% ` Philip Kaludercic
2023-04-07 21:46 ` Jonas Bernoulli
2023-04-08 8:36 91% ` Philip Kaludercic
2023-04-09 18:39 ` Jonas Bernoulli
2023-04-09 21:55 84% ` Philip Kaludercic
2023-03-29 3:00 jinx Richard Stallman
2023-03-29 22:46 ` jinx Michael Eliachevitch
2023-03-31 4:29 ` jinx Richard Stallman
2023-03-31 6:51 ` jinx Eli Zaretskii
2023-03-31 7:10 ` jinx Gregory Heytings
2023-03-31 7:15 ` Grammar checking (was: jinx) Eli Zaretskii
2023-03-31 7:47 97% ` Grammar checking Philip Kaludercic
2023-03-31 8:09 ` Gregory Heytings
2023-03-31 8:38 99% ` Philip Kaludercic
2023-03-31 11:37 ` Lynn Winebarger
2023-03-31 12:01 ` Gregory Heytings
2023-03-31 12:45 ` Peter Oliver
2023-03-31 15:29 99% ` Philip Kaludercic
2023-03-31 11:23 ` Eli Zaretskii
2023-03-31 15:25 95% ` Philip Kaludercic
2023-03-31 8:40 ` Nasser Alkmim
2023-03-31 8:48 ` Gregory Heytings
2023-04-01 12:59 ` Lynn Winebarger
2023-04-02 3:12 ` Richard Stallman
2023-04-02 15:24 ` Lynn Winebarger
2023-04-03 3:05 ` Richard Stallman
2023-04-06 12:29 ` Lynn Winebarger
2023-04-08 3:28 ` Richard Stallman
2023-04-09 9:02 99% ` Philip Kaludercic
2023-04-05 13:05 ` jinx Rudolf Adamkovič
2023-04-05 18:37 99% ` jinx Philip Kaludercic
2023-03-31 18:33 ` jinx Arash Esbati
2023-03-31 19:11 ` jinx Eli Zaretskii
2023-03-31 19:35 ` jinx Arash Esbati
2023-04-01 7:20 ` jinx Eli Zaretskii
2023-04-01 7:42 ` jinx Arash Esbati
2023-04-01 8:13 ` jinx Eli Zaretskii
2023-04-03 12:32 ` jinx Michael Heerdegen
2023-04-03 14:26 ` jinx Eli Zaretskii
2023-04-03 15:13 ` jinx Michael Eliachevitch
2023-04-04 2:56 ` jinx Richard Stallman
2023-04-04 12:27 ` jinx Michael Heerdegen
2023-04-05 2:35 ` jinx Richard Stallman
2023-04-05 9:02 99% ` jinx Philip Kaludercic
2023-03-30 13:42 Request to add Package to GNU ELPA Jonas Bernoulli
2023-03-30 17:32 ` Philip Kaludercic
2023-03-31 17:15 ` Jonas Bernoulli
2023-04-05 8:59 71% ` Philip Kaludercic
2023-04-05 14:13 ` Jonas Bernoulli
2023-04-05 18:07 99% ` Philip Kaludercic
2023-04-05 18:26 79% ` Philip Kaludercic
2023-04-05 21:08 58% ` Philip Kaludercic
2023-04-06 15:46 50% ` Philip Kaludercic
2023-04-06 21:36 ` Stefan Monnier
2023-04-07 7:23 98% ` Philip Kaludercic
2023-04-07 15:39 ` Stefan Monnier
2023-04-08 8:24 85% ` Philip Kaludercic
2023-04-09 15:29 ` Stefan Monnier
2023-04-09 17:27 48% ` Philip Kaludercic
2023-04-07 10:07 34% ` Philip Kaludercic
2023-04-17 16:24 99% ` Adding package-vc to ELPA Philip Kaludercic
2023-04-09 7:36 [GNU ELPA] I'd like to add switchy.el: a last-recently-used window switcher Tassilo Horn
2023-04-09 8:56 86% ` Philip Kaludercic
2023-04-09 9:33 ` Tassilo Horn
2023-04-09 10:30 99% ` Philip Kaludercic
[not found] <168106451331.17156.9500255897449991646@vcs2.savannah.gnu.org>
[not found] ` <20230409182153.93887C13A8C@vcs2.savannah.gnu.org>
2023-04-09 18:40 99% ` [elpa] main b8d4806d47: * elpa-packages (switchy-window): Ignore LICENSE and Makefile Philip Kaludercic
2023-04-09 21:13 ` Tassilo Horn
2023-04-10 7:30 ` Tassilo Horn
2023-04-10 9:14 99% ` Philip Kaludercic
2023-04-12 9:40 What to use after #'define-package is now obsolete? Chen Zhaoyang
2023-04-12 12:07 99% ` Philip Kaludercic
2023-04-14 17:03 [ELPA] New package: emacs-gc-stats Ihor Radchenko
2023-06-09 9:14 ` Ihor Radchenko
2023-06-09 10:17 ` Eli Zaretskii
2023-06-09 16:19 ` Stefan Monnier
2023-06-10 10:13 ` Ihor Radchenko
2023-06-10 16:33 ` Stefan Monnier
2023-06-11 9:15 ` Ihor Radchenko
2023-06-11 9:12 99% ` Philip Kaludercic
[not found] <hsryxz6ppcdsvv7i2ebdwoimldlg5b7xewgh43vz2jbbjsqe6d.ref@o6naxb3fkymi>
2023-04-16 15:07 ` Flymake backends Ergus
2023-04-16 19:17 99% ` Philip Kaludercic
2023-04-16 20:35 ` Ergus
2023-04-17 13:21 87% ` Philip Kaludercic
2023-04-17 3:12 Would (Eval-when-compile (require 'treesit)) eliminate the need for (declare-function)s? Yuan Fu
2023-04-17 3:31 ` Ruijie Yu via Emacs development discussions.
2023-04-17 13:29 96% ` Philip Kaludercic
[not found] <7w4yjuxtu6rm325oeddtl3fu4oe64fsarru3s4fnh7on5m7udl.ref@wzxqo5pm6es7>
2023-04-16 20:50 ` Multithread or multiprocess in emacs?? Ergus
2023-04-17 13:37 98% ` Philip Kaludercic
[not found] <168174708495.14139.12756054653439048176@vcs2.savannah.gnu.org>
[not found] ` <20230417155805.3E200C1391A@vcs2.savannah.gnu.org>
2023-04-17 16:08 ` [elpa] externals/org 26ef5e3e5b: org-src: Use `sh-mode' for all the shells it can handle Stefan Monnier
2023-04-17 16:16 ` Lynn Winebarger
2023-04-17 16:27 95% ` Philip Kaludercic
2023-04-17 16:37 ` Andreas Schwab
2023-04-17 16:42 99% ` Philip Kaludercic
2023-04-17 23:23 [ELPA] New package: calibre.el Kjartan Óli Águstsson
2023-04-18 6:05 89% ` Philip Kaludercic
2023-04-18 8:19 ` Kjartan Óli Águstsson
2023-04-20 18:26 99% ` Philip Kaludercic
2023-05-09 12:50 ` Kjartan Óli Águstsson
2023-05-10 6:36 99% ` Philip Kaludercic
2023-05-10 12:34 ` Kjartan Óli Águstsson
2023-05-16 19:38 99% ` Philip Kaludercic
2023-05-17 15:01 ` Kjartan Óli Águstsson
2023-05-18 13:01 99% ` Philip Kaludercic
2023-04-19 7:19 ELPA: New package nano-dialog Nicolas P. Rougier (inria)
2023-04-25 6:11 ` Nicolas P. Rougier (inria)
2023-04-25 12:42 94% ` Philip Kaludercic
2023-04-25 12:59 ` Nicolas P. Rougier (inria)
2023-04-25 14:13 99% ` Philip Kaludercic
[not found] <168253918316.13996.1296301764817258828@vcs2.savannah.gnu.org>
[not found] ` <20230426195944.6BDA0C21715@vcs2.savannah.gnu.org>
2023-04-27 11:54 99% ` [nongnu] elpa/editorconfig ed3defaad8: Add support for gdscript-mode (#300) Philip Kaludercic
[not found] <168263878553.23108.4718240877999827191@vcs2.savannah.gnu.org>
[not found] ` <20230427233949.44D31C22A13@vcs2.savannah.gnu.org>
2023-04-27 23:52 ` emacs-29 44ebd9cbd56 2/2: Eglot: explain how to update Eglot in manual (bug#62720) Dmitry Gutov
2023-04-28 4:37 ` Eli Zaretskii
2023-04-28 14:25 99% ` Philip Kaludercic
2023-04-28 15:30 ` Dmitry Gutov
2023-04-28 18:12 69% ` Philip Kaludercic
2023-04-29 0:52 ` Dmitry Gutov
2023-04-29 6:45 ` Eli Zaretskii
2023-04-29 10:01 ` Dmitry
2023-04-29 10:13 99% ` Philip Kaludercic
2023-04-29 9:08 87% ` Philip Kaludercic
2023-04-29 9:40 ` Eli Zaretskii
2023-04-29 9:54 ` Dmitry
2023-04-29 10:15 99% ` Philip Kaludercic
2023-04-29 12:52 ` João Távora
2023-04-30 12:12 86% ` Philip Kaludercic
2023-05-01 2:09 ` João Távora
2023-05-01 7:34 93% ` Philip Kaludercic
2023-05-02 7:56 ` Robert Pluim
2023-05-05 5:13 99% ` Philip Kaludercic
2023-04-30 8:58 vc-dir fails if Git upstream branch is local Tobias Bading
2023-04-30 9:09 99% ` Philip Kaludercic
[not found] <87a5zj2vfo.fsf@gmail.com>
[not found] ` <CALDnm527Avsa-MBTD-bvRqOn52AeBLfPvffxjL-NB3tqM=43ZQ@mail.gmail.com>
[not found] ` <834jpifizy.fsf@gnu.org>
[not found] ` <CALDnm53X5Yyn_EitG+iHJVx=RO2hjNaWkrgPz0+jKVWVM=eEBQ@mail.gmail.com>
[not found] ` <83y1mue1qi.fsf@gnu.org>
[not found] ` <CALDnm51hmRMxstQdZdstA2LrbvYw=zD5=XRVy6uCU=Z+OmONRg@mail.gmail.com>
[not found] ` <83sfd2e01f.fsf@gnu.org>
[not found] ` <1a5e5837-513b-84d8-3260-cdbf42b71267@gutov.dev>
[not found] ` <83sfcz9rf2.fsf@gnu.org>
[not found] ` <09a49ab9-ac72-36a9-3e68-9c633710eba7@gutov.dev>
2023-04-18 12:57 ` Stability of core packages (was: Not easy at all to upgrade :core packages like Eglot) Eli Zaretskii
2023-04-18 18:56 ` Jim Porter
2023-04-19 8:50 ` João Távora
2023-04-19 12:13 ` Dr. Arne Babenhauserheide
2023-04-19 17:03 ` Eli Zaretskii
2023-04-19 19:40 ` Dr. Arne Babenhauserheide
2023-04-20 6:02 ` Eli Zaretskii
2023-04-29 5:21 ` Stability of core packages emacs
2023-04-29 6:26 ` Eli Zaretskii
2023-04-29 21:47 ` Mohsen BANAN
2023-04-30 9:07 86% ` Philip Kaludercic
2023-04-18 22:10 ` Stability of core packages (was: Not easy at all to upgrade :core packages like Eglot) Dmitry Gutov
2023-04-19 12:47 ` Eli Zaretskii
2023-04-19 19:25 ` Dmitry Gutov
2023-04-20 9:47 ` Eli Zaretskii
2023-04-20 13:03 ` Dmitry Gutov
2023-04-20 14:03 ` Eli Zaretskii
2023-04-20 14:22 ` Dmitry Gutov
2023-04-20 14:42 ` Eli Zaretskii
2023-04-20 15:30 ` Dmitry Gutov
2023-04-20 15:49 ` Eli Zaretskii
2023-04-20 17:26 99% ` Stability of core packages Philip Kaludercic
2023-05-02 21:21 [NonGNU Elpa] New package: ETT John Task
2023-05-03 6:08 42% ` Philip Kaludercic
2023-05-03 6:11 99% ` Philip Kaludercic
2023-05-03 15:02 John Task
2023-05-03 16:41 91% ` Philip Kaludercic
2023-05-05 11:56 [GNU ELPA] eglot-x.el: Protocol extensions for Eglot Felician Nemeth
2023-05-05 13:26 ` Eli Zaretskii
2023-05-05 16:38 94% ` Philip Kaludercic
2023-05-05 19:15 Extending timeclock.el John Task
2023-05-06 6:09 99% ` Philip Kaludercic
2023-05-06 5:07 [GNU ELPA] New package: url-http-oauth Thomas Fitzsimmons
2023-05-07 15:55 99% ` Philip Kaludercic
2023-05-08 7:50 ` João Távora
2023-05-08 10:30 99% ` Philip Kaludercic
[not found] <168335548287.8529.4912240840977468283@vcs2.savannah.gnu.org>
[not found] ` <20230506064443.56C75C22F15@vcs2.savannah.gnu.org>
2023-05-06 10:14 ` emacs-29 9b775ddc057 1/2: ; * etc/EGLOT-NEWS: Fix wording of last change Dmitry Gutov
2023-05-06 10:35 ` Eli Zaretskii
2023-05-06 10:46 ` Dmitry Gutov
2023-05-06 10:53 ` Eli Zaretskii
2023-05-06 13:03 ` João Távora
2023-05-06 13:22 ` Eli Zaretskii
2023-05-06 15:26 ` Dmitry Gutov
2023-05-06 15:44 ` Eli Zaretskii
2023-05-06 15:54 ` Dmitry Gutov
2023-05-06 16:40 ` Eli Zaretskii
2023-05-06 18:44 81% ` Philip Kaludercic
2023-05-06 19:08 ` Eli Zaretskii
2023-05-07 7:43 90% ` Philip Kaludercic
2023-05-06 19:14 ` Dmitry Gutov
2023-05-06 19:38 ` Eli Zaretskii
2023-05-06 20:31 ` Dmitry Gutov
2023-05-07 5:51 ` Eli Zaretskii
2023-05-07 8:46 93% ` Philip Kaludercic
2023-05-07 9:32 ` Eli Zaretskii
2023-05-07 17:16 83% ` Philip Kaludercic
2023-05-07 18:32 ` Eli Zaretskii
2023-05-07 19:24 92% ` Philip Kaludercic
2023-05-07 19:32 ` Eli Zaretskii
2023-05-07 19:44 99% ` Philip Kaludercic
2023-05-08 11:20 ` Eli Zaretskii
2023-05-08 13:34 93% ` Philip Kaludercic
2023-05-08 13:44 ` Eli Zaretskii
2023-05-10 6:59 76% ` Philip Kaludercic
2023-05-10 11:03 80% ` Philip Kaludercic
2023-05-10 15:02 ` Ruijie Yu via Emacs development discussions.
2023-05-11 7:29 99% ` Philip Kaludercic
2023-05-10 22:19 ` Dmitry Gutov
2023-05-11 7:26 99% ` Philip Kaludercic
2023-05-11 9:43 ` Dmitry Gutov
2023-05-12 6:43 99% ` Philip Kaludercic
2023-05-08 12:43 [ELPA] New package: pdf-view-pagemark Jijun Ma
2023-05-08 20:23 99% ` Philip Kaludercic
2023-05-08 21:30 ` Jijun Ma
2023-05-09 8:46 99% ` Philip Kaludercic
2023-05-09 8:49 ` Jijun Ma
2023-05-10 6:42 99% ` Philip Kaludercic
2023-05-10 11:25 ` Eli Zaretskii
2023-05-10 22:10 ` Jijun Ma
2023-05-12 5:52 98% ` Philip Kaludercic
2023-05-09 1:57 [NonGNU ELPA] New package: devil Susam Pal
2023-05-09 8:42 23% ` Philip Kaludercic
2023-05-09 8:52 ` Eli Zaretskii
2023-05-09 8:58 99% ` Philip Kaludercic
2023-05-09 20:56 ` Susam Pal
2023-05-10 6:09 5% ` Philip Kaludercic
2023-05-09 5:18 [GNU ELPA] New package: Urgrep Jim Porter
2023-05-09 8:45 99% ` Philip Kaludercic
2023-05-09 20:26 ` Jim Porter
2023-05-10 6:22 99% ` Philip Kaludercic
2023-05-10 16:22 ` Jim Porter
2023-05-10 17:30 99% ` Philip Kaludercic
2023-05-12 21:52 ` Richard Stallman
2023-05-12 21:59 ` Jim Porter
2023-05-13 7:09 99% ` Philip Kaludercic
2023-05-15 22:13 ` Richard Stallman
2023-05-16 6:29 99% ` Philip Kaludercic
2023-05-17 22:27 ` Richard Stallman
2023-05-18 13:23 95% ` Philip Kaludercic
2023-05-11 5:23 [NonGNU ELPA] New package: devil Payas Relekar
2023-05-11 6:33 ` Eli Zaretskii
2023-05-11 6:52 89% ` Philip Kaludercic
2023-05-11 8:09 ` Susam Pal
2023-05-11 8:45 78% ` Philip Kaludercic
2023-05-11 8:58 ` Eli Zaretskii
2023-05-11 9:08 ` Susam Pal
2023-05-11 9:12 99% ` Philip Kaludercic
2023-05-12 16:19 ` Jim Porter
2023-05-13 7:10 99% ` Philip Kaludercic
2023-05-13 9:05 ` Susam Pal
2023-05-17 13:30 ` João Távora
2023-05-17 14:06 99% ` Philip Kaludercic
2023-05-13 22:30 ` Richard Stallman
2023-05-14 4:29 ` Naming guidelines for ELPA packages (was: Re: [NonGNU ELPA] New package: devil) Jim Porter
2023-05-14 7:47 99% ` Naming guidelines for ELPA packages Philip Kaludercic
2023-05-14 19:23 ` Jim Porter
2023-05-14 19:33 99% ` Philip Kaludercic
2023-05-19 3:49 ` Jim Porter
2023-05-19 4:33 ` Akib Azmain Turja
2023-05-20 16:51 99% ` Philip Kaludercic
2023-05-11 13:22 [ELPA] New package: dict Eshel Yaron
2023-05-11 13:59 ` Eli Zaretskii
2023-05-11 14:14 97% ` Philip Kaludercic
2023-05-11 17:56 ` Eshel Yaron
2023-05-11 18:29 99% ` Philip Kaludercic
2023-05-12 13:17 ` Eshel Yaron
2023-05-12 13:44 ` Eli Zaretskii
2023-05-14 6:41 ` Eshel Yaron
2023-05-14 9:14 ` Eli Zaretskii
2023-05-15 18:50 ` Eshel Yaron
2023-05-18 10:59 ` Eli Zaretskii
2023-05-18 12:21 ` Eshel Yaron
2023-05-18 14:09 ` Eli Zaretskii
2023-05-18 15:51 ` Eshel Yaron
2023-05-18 15:58 ` Eli Zaretskii
2023-05-19 8:34 ` Eshel Yaron
2023-05-20 16:49 91% ` Philip Kaludercic
2023-05-20 18:27 ` Eshel Yaron
2023-05-20 19:11 99% ` Philip Kaludercic
2023-05-21 6:52 ` Eshel Yaron
2023-05-25 9:52 ` Eshel Yaron
2023-05-25 19:10 99% ` Philip Kaludercic
2023-05-18 12:59 99% ` Philip Kaludercic
2023-05-18 15:37 ` Eshel Yaron
2023-05-18 15:58 99% ` Philip Kaludercic
2023-05-11 14:18 99% ` Philip Kaludercic
2023-05-11 18:00 ` Eshel Yaron
2023-05-11 18:31 99% ` Philip Kaludercic
2023-05-12 13:32 ` Eshel Yaron
2023-05-16 19:38 99% ` Philip Kaludercic
2023-05-12 4:01 Names are not descriptions; descriptions are not names Adam Porter
2023-05-12 6:42 68% ` Philip Kaludercic
[not found] <168416742839.11327.1066281628551652191@vcs2.savannah.gnu.org>
[not found] ` <20230515161708.AD134C13919@vcs2.savannah.gnu.org>
2023-05-15 16:21 99% ` [nongnu] main 83410aacf7: * elpa-packages (devil): New package Philip Kaludercic
2023-05-15 16:41 ` Stefan Monnier
2023-05-16 16:12 99% ` Philip Kaludercic
2023-05-23 23:37 ` Susam Pal
2023-05-24 6:41 99% ` Philip Kaludercic
2023-05-15 21:43 Getting email addresses obfuscated in patch attachments created by "git format-patch" Jens Schmidt
2023-05-16 6:46 99% ` Philip Kaludercic
2023-05-21 10:21 [PROPOSAL] Builder, a build system integration for Emacs BTuin
2023-05-21 12:11 99% ` Philip Kaludercic
2023-05-22 22:00 ` Richard Stallman
2023-05-23 8:36 99% ` Philip Kaludercic
2023-05-24 3:34 ` David Masterson
2023-05-24 10:26 99% ` Philip Kaludercic
2023-05-23 16:47 Inferred function types in the *Help* buffer Payas Relekar
2023-05-23 18:51 99% ` Philip Kaludercic
[not found] <168526066293.9832.17189979431838421656@vcs2.savannah.gnu.org>
[not found] ` <20230528075743.4D45AC22A3C@vcs2.savannah.gnu.org>
2023-05-28 8:39 ` [elpa] externals/denote 51bd02b95c 1/2: Add initial version of 'denote-rename-buffer' extension Ruijie Yu via Emacs development discussions.
2023-05-28 11:05 98% ` Philip Kaludercic
2023-05-28 11:15 ` Protesilaos Stavrou
2023-05-28 11:51 97% ` Philip Kaludercic
2023-05-30 5:16 Extending define-derived-mode Yuan Fu
2023-06-05 8:30 90% ` Philip Kaludercic
2023-06-04 14:15 [NonGNU Elpa] New package: electric-french Ruijie Yu via Emacs development discussions.
2023-06-05 8:34 99% ` Philip Kaludercic
[not found] <168595059426.2523.2109338263713299231@vcs2.savannah.gnu.org>
[not found] ` <20230605073635.19060C00613@vcs2.savannah.gnu.org>
2023-06-05 10:24 99% ` master a30781399b3: * subr-x (eval-command-interactive-spec): New function Philip Kaludercic
[not found] <168565525463.8048.4344900670894070114@vcs2.savannah.gnu.org>
[not found] ` <20230601213415.21F57C21A9F@vcs2.savannah.gnu.org>
2023-06-05 12:46 99% ` [elpa] externals/firefox-javascript-repl 056b687af4 2/3: Work around missing submodule support in GNU ELPA Philip Kaludercic
2023-06-07 3:18 question regarding my emacs package ram
2023-06-07 15:53 48% ` Philip Kaludercic
2023-06-07 18:04 99% ` Philip Kaludercic
2023-06-07 19:45 ` ram
2023-06-07 19:48 99% ` Philip Kaludercic
2023-06-07 19:50 ` ram
2023-06-07 22:34 ` ram
2023-06-08 7:13 ` ram
2023-06-08 7:26 57% ` Philip Kaludercic
2023-06-11 18:49 ` João Távora
2023-06-11 19:08 ` ram via Emacs development discussions.
2023-06-12 8:45 99% ` Philip Kaludercic
2023-06-12 10:23 ` João Távora
2023-06-12 10:54 88% ` Philip Kaludercic
2023-06-07 21:28 Bookmarks in registers Christopher Howard
2023-06-08 6:44 94% ` Philip Kaludercic
2023-06-08 23:57 Adding some convenience functions to color.el Yilkal Argaw
2023-06-09 6:22 94% ` Philip Kaludercic
2023-06-10 10:53 package-vc support for :files keyword Daniel Fleischer
2023-06-10 13:23 79% ` Philip Kaludercic
2023-06-10 14:20 ` Daniel Fleischer
2023-06-11 8:55 79% ` Philip Kaludercic
2023-06-11 9:30 ` Daniel Fleischer
2023-06-11 10:24 86% ` Philip Kaludercic
2023-06-16 11:20 Android port of Emacs Eli Zaretskii
2023-06-16 15:16 ` Dr. Arne Babenhauserheide
2023-06-16 15:32 ` Eli Zaretskii
2023-06-17 0:49 ` Konstantin Kharlamov
2023-06-17 6:20 ` Eli Zaretskii
2023-06-17 13:34 ` Konstantin Kharlamov
2023-06-17 16:47 ` Alfred M. Szmidt
2023-06-17 18:11 ` contributing to Emacs Konstantin Kharlamov
2023-06-17 18:36 ` Alfred M. Szmidt
2023-06-17 19:39 ` Konstantin Kharlamov
2023-06-17 21:00 ` Alfred M. Szmidt
2023-06-17 21:10 ` Konstantin Kharlamov
2023-06-17 21:19 ` Alfred M. Szmidt
2023-06-17 21:26 ` Konstantin Kharlamov
2023-06-17 22:25 ` Alfred M. Szmidt
2023-06-17 22:39 ` Konstantin Kharlamov
2023-06-18 5:20 ` Eli Zaretskii
2023-06-18 8:53 ` Konstantin Kharlamov
2023-06-18 10:00 99% ` Philip Kaludercic
2023-06-18 10:15 ` Konstantin Kharlamov
2023-06-18 10:22 96% ` Philip Kaludercic
2023-06-23 6:49 ` Sean Whitton
2023-06-24 15:37 99% ` Philip Kaludercic
2023-06-25 7:40 ` Sean Whitton
2023-06-25 11:32 86% ` Setting 'vc-default-patch-addressee' in .dir-locals.el Philip Kaludercic
2023-06-18 0:50 ` contributing to Emacs Po Lu
2023-06-20 2:55 ` Richard Stallman
2023-06-20 3:39 ` Po Lu
2023-06-22 1:56 ` Richard Stallman
2023-06-22 2:23 ` Po Lu
2023-06-22 7:47 92% ` Philip Kaludercic
2023-06-17 20:35 Suggestion: Make cperl-mode.el an ELPA :core package Harald Jörg
2023-06-18 8:51 91% ` Philip Kaludercic
2023-07-05 13:01 Use radix-tree for string arrays Yuchen Pei
2023-07-05 16:47 99% ` Philip Kaludercic
2023-07-05 22:15 ` Yuchen Pei
2023-07-06 18:50 99% ` Philip Kaludercic
2023-07-06 16:14 NonGNU ELPA: add Logview Paul Pogonyshev
2023-07-06 17:59 85% ` Philip Kaludercic
2023-07-06 19:47 ` Paul Pogonyshev
2023-07-07 5:21 ` Bozhidar Batsov
2023-07-13 13:34 ` Bozhidar Batsov
2023-07-13 18:35 99% ` Philip Kaludercic
[not found] <168884609732.27984.6450580686777461843@vcs2.savannah.gnu.org>
[not found] ` <20230708195457.95F1AC11DD8@vcs2.savannah.gnu.org>
2023-07-08 21:47 ` [elpa] main 2ec80977e1: * elpa-packages (dired-preview): New package Stefan Monnier
2023-07-10 18:29 39% ` Philip Kaludercic
2023-07-10 20:20 ` Protesilaos Stavrou
2023-07-11 7:47 62% ` Philip Kaludercic
2023-07-11 13:33 ` Stefan Monnier
2023-07-11 16:58 92% ` Philip Kaludercic
2023-07-13 18:40 ` Protesilaos Stavrou
2023-07-13 20:29 99% ` Philip Kaludercic
2023-07-13 21:36 ` Stefan Monnier
2023-07-14 8:13 ` Mattias Engdegård
2023-07-14 14:18 ` [External] : " Drew Adams
2023-07-14 19:29 96% ` Philip Kaludercic
2023-07-10 18:53 96% Stability of project.el Philip Kaludercic
2023-07-11 1:27 ` Dmitry Gutov
2023-07-11 5:26 99% ` Philip Kaludercic
2023-07-13 20:54 Distribution statistics for ELPA and EMMS Yoni Rabkin
2023-07-13 23:16 ` Eduardo Ochs
2023-07-14 7:03 96% ` Philip Kaludercic
[not found] <168924107008.19431.1227792773208531915@vcs2.savannah.gnu.org>
[not found] ` <20230713093750.A9D48C06C6F@vcs2.savannah.gnu.org>
2023-07-13 12:51 ` [elpa] elpa-admin 1d766451f8: Suggest `package-install' to install packages (bug#63800) Stefan Monnier
2023-07-13 13:12 ` Ihor Radchenko
2023-07-14 19:33 98% ` Philip Kaludercic
2023-07-17 10:14 New branch feature/named-lambdas Alan Mackenzie
2023-07-17 19:52 99% ` Philip Kaludercic
2023-07-19 3:45 [ELPA] New package: Peek Meow King
2023-07-19 6:31 43% ` Philip Kaludercic
[not found] <169001274227.13639.17462635050444662711@vcs2.savannah.gnu.org>
[not found] ` <20230722075902.960A7C138F3@vcs2.savannah.gnu.org>
2023-07-22 13:22 ` [elpa] externals/typo 88522ea4c8 1/2: Handle hash-tables with symbols as keys Stefan Monnier
2023-07-22 14:10 87% ` Philip Kaludercic
2023-07-31 1:58 Suggestion for package.el: atomic package-upgrade dqs7cp2e
2023-07-31 6:45 79% ` Philip Kaludercic
2023-07-31 13:13 ` Tegar Syahputra
2023-08-01 7:32 99% ` Philip Kaludercic
2023-07-31 18:38 [ELPA] Proposing to add express to ELPA Yuan Fu
2023-08-01 8:07 63% ` Philip Kaludercic
2023-08-11 17:14 ` Yuan Fu
2023-08-11 18:14 99% ` Philip Kaludercic
2023-08-01 1:35 Proposal to include the Ef themes collection into Emacs core Zoltan Kiraly
2023-08-01 8:22 76% ` Philip Kaludercic
2023-08-02 4:37 ` Protesilaos Stavrou
2023-08-03 19:36 91% ` Philip Kaludercic
2023-08-02 7:56 Adding adoc-mode (a major mode for working with AsciiDoc) to NonGNU ELPA Bozhidar Batsov
2023-08-02 12:49 99% ` Philip Kaludercic
2023-08-03 9:29 Question about eval and compile-command Eshel Yaron
2023-08-03 9:56 ` Eli Zaretskii
2023-08-03 15:14 ` Stefan Monnier
2023-08-03 20:02 99% ` Philip Kaludercic
2023-08-03 21:14 ` Andreas Schwab
2023-08-03 21:35 ` [External] : " Drew Adams
2023-08-04 6:51 ` Andreas Schwab
2023-08-04 7:00 92% ` Philip Kaludercic
2023-08-07 7:57 Changes to make in elpa-packages file for nongnu elpa Thierry Volpiatto
2023-08-07 13:30 92% ` Philip Kaludercic
2023-08-07 18:19 ` Thierry Volpiatto
2023-08-07 20:33 45% ` Philip Kaludercic
2023-08-08 4:33 ` Thierry Volpiatto
2023-08-08 5:52 75% ` Philip Kaludercic
2023-08-15 16:55 54% ` Philip Kaludercic
2023-08-15 17:34 ` Eshel Yaron
2023-08-15 19:39 99% ` Proposal for 'package-isolate' command Philip Kaludercic
2023-08-15 18:56 ` Changes to make in elpa-packages file for nongnu elpa Eli Zaretskii
2023-08-15 19:52 57% ` Proposal for 'package-isolate' command Philip Kaludercic
2023-08-16 11:25 ` Eli Zaretskii
2023-08-16 18:48 90% ` Philip Kaludercic
2023-08-16 6:51 ` Changes to make in elpa-packages file for nongnu elpa Thierry Volpiatto
2023-08-16 10:10 46% ` Philip Kaludercic
2023-08-16 10:14 ` Thierry Volpiatto
2023-08-16 11:03 85% ` Philip Kaludercic
2023-08-16 11:55 ` Thierry Volpiatto
2023-08-16 18:34 88% ` Proposal for 'package-isolate' command Philip Kaludercic
2023-08-16 18:49 ` Stefan Kangas
2023-08-16 19:00 52% ` Philip Kaludercic
2023-08-17 5:30 ` Thierry Volpiatto
2023-08-17 8:34 49% ` Philip Kaludercic
2023-08-17 9:07 ` Eshel Yaron
2023-08-17 14:19 99% ` Philip Kaludercic
2023-08-17 13:32 ` Thierry Volpiatto
2023-08-17 14:04 99% ` Philip Kaludercic
2023-08-17 13:56 ` Thierry Volpiatto
2023-08-17 14:18 97% ` Philip Kaludercic
2023-08-17 14:28 ` Thierry Volpiatto
2023-08-17 18:17 85% ` Philip Kaludercic
2023-08-18 4:57 ` Thierry Volpiatto
2023-08-18 7:49 94% ` Philip Kaludercic
2023-08-16 14:10 ` Changes to make in elpa-packages file for nongnu elpa Eli Zaretskii
2023-08-16 18:52 99% ` Philip Kaludercic
2023-08-08 6:34 ` Michael Albinus
2023-08-08 16:37 99% ` Philip Kaludercic
2023-08-08 16:41 ` Michael Albinus
2023-08-09 7:06 99% ` Philip Kaludercic
2023-08-09 11:53 ` Eli Zaretskii
2023-08-09 14:53 98% ` Philip Kaludercic
2023-08-09 14:55 ` Eli Zaretskii
2023-08-09 15:24 99% ` Philip Kaludercic
2023-08-07 20:22 [ELPA] New Package: phpinspect.el Hugo Thunnissen
2023-08-12 4:56 ` Stefan Monnier
2023-08-15 17:45 ` Hugo Thunnissen
2023-08-15 20:28 99% ` Philip Kaludercic
2023-08-15 21:33 ` Hugo Thunnissen
2023-08-15 21:56 99% ` Philip Kaludercic
2023-08-07 23:54 [NonGNU ELPA] New package: llm Andrew Hyatt
2023-08-08 5:42 91% ` Philip Kaludercic
[not found] <169158945793.6388.8459711282582712176@vcs2.savannah.gnu.org>
[not found] ` <20230809135738.457BDC038BF@vcs2.savannah.gnu.org>
2023-08-11 6:07 98% ` [elpa] externals/compat 6a60af22da: Optimize string-search Philip Kaludercic
2023-08-11 6:23 ` Eli Zaretskii
2023-08-11 8:15 99% ` Philip Kaludercic
2023-08-11 7:12 ` Daniel Mendler
2023-08-11 8:17 99% ` Philip Kaludercic
2023-08-12 18:35 New Package for NonGNU-ELPA: clojure-ts-mode Danny Freeman
2023-08-12 19:10 86% ` Philip Kaludercic
2023-08-12 19:12 ` Danny Freeman
2023-08-12 20:31 87% ` Philip Kaludercic
2023-08-12 19:26 ` Eli Zaretskii
2023-08-12 20:22 89% ` Philip Kaludercic
2023-08-13 5:16 ` Eli Zaretskii
2023-08-13 6:23 99% ` Philip Kaludercic
[not found] <169185199333.11628.2162615922937919004@vcs2.savannah.gnu.org>
[not found] ` <20230812145313.C853CC038C2@vcs2.savannah.gnu.org>
2023-08-16 12:55 ` master 5892b4db8de 2/3: Convert dictionary-mode to define-derived-mode Visuwesh
2023-08-16 22:33 99% ` Philip Kaludercic
2023-08-17 13:58 Preferred approach to inclusion of data in ELPA package Hugo Thunnissen
2023-08-17 21:14 96% ` Philip Kaludercic
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).