* Re: Adding AUCTeX to core Re: Why not include all ELPA packages in an Emacs release?
@ 2024-05-30 19:33 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-05-30 19:33 UTC (permalink / raw)
To: Jeremy Bryant
Cc: Andrea Corallo, Arash Esbati, Eli Zaretskii, Stefan Kangas,
emacs-devel, monnier
Jeremy Bryant <jb@jeremybryant.net> writes:
> Andrea Corallo <acorallo@gnu.org> writes:
>
>> Philip Kaludercic <philipk@posteo.net> writes:
>>
>>> Arash Esbati <arash@gnu.org> writes:
>>>
>>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>>
>>>>> If there are packages on ELPA which we consider to be a must for users
>>>>> (I don't think there are, but maybe I'm forgetting something), lets
>>>>> add them to core instead.
>>>>
>>>> If Emacs considers in-buffer completion an important feature, then I'd
>>>> say corfu and cape are must.
>>>
>>> I am not familiar with cape, but IIRC the issue with corfu is that
>>> without any further changes, it doesn't support non-graphical Emacs,
>>> right?
>>>
>>>> vertico and marginalia are also must in my
>>>> book since they offer a better experience with vertical minibuffer
>>>> completion.
>>>
>>> "Better", in this case, than `fido-vertical-mode'?
>>>
>>>> And while we're at it: There are sometimes requests for adding AUCTeX to
>>>> core. Do you have an opinion about that?
>>>
>>> I would certainly be a fan of that move.
>>
>> I support AUCTeX inclusion as well.
>>
>> Andrea
>
> I can volunteer for some of this work under the guidance of the
> Emacs maintainers and the AUCTeX maintainers (as I have contributed some
> patches already.). AUCTeX follows the Emacs development guidelines so
> it should be easier.
>
> As mentioned by Eli, AUCTeX could be merged in core but not enabled by
> default to start.
>
> What would be the most important next step required?
Wait, is the plan to add AUCTeX directly to emacs.git, or to include
AUCTeX in the packages that would be bundled with the release-tarball?
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 99%]
* Re: Why not include all ELPA packages in an Emacs release?
@ 2024-05-30 15:20 84% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-05-30 15:20 UTC (permalink / raw)
To: Daniel Mendler
Cc: Arash Esbati, Eli Zaretskii, Stefan Kangas, jb, emacs-devel,
monnier
Daniel Mendler <mail@daniel-mendler.de> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Daniel Mendler <mail@daniel-mendler.de> writes:
>>
>>> Philip Kaludercic <philipk@posteo.net> writes:
>>>
>>>> Arash Esbati <arash@gnu.org> writes:
>>>>
>>>>> Philip Kaludercic <philipk@posteo.net> writes:
>>>>>
>>>>>> I am not familiar with cape,
>>>>>
>>>>> Cape offers CAPFs, but I think one great featuzre is that you can switch
>>>>> the CAPF function during completion with something like this in your
>>>>> init file:
>>>>>
>>>>> (use-package cape
>>>>> :bind (:map corfu-map
>>>>> ("C-c p d" . cape-dabbrev)
>>>>> ("C-c p f" . cape-file)
>>>>> ("C-c p s" . cape-elisp-symbol)
>>>>> ("C-c p w" . ispell-completion-at-point)
>>>>> ("C-c p :" . cape-emoji)))
>>>>
>>>> I tried it out, and it doesn't seem to work that well without something
>>>> like corfu or vertico. Generally it seems like an example where
>>>> "completion" is misinterpreted to mean "selection".
>>>
>>> This is not correct. Please stop spreading misinformation like this.
>>> Capfs like the ones from Cape can be used to complete in a stepwise
>>> manner.
>>
>> I understand that, I am just saying that it doesn't feel that natural
>> without something like corfu enabled as well. Or at least with the
>> above configuration, something like cape-emoji with the default
>> in-buffer completion is less comfortable than the built-in C-x 8 e.
>> Same with dabbrev itself vs. cape-dabbrev.
>
> First, this is not what you said (selection vs completion).
I do think that this is related. cape-emoji, cape-tex, etc. do not
complete partial input.
> Second, the
> Capfs provided by Cape work as well or "natural" as other Capfs with the
> default completion UI as they do with Corfu. The aforementioned
> configuration is meant to trigger completion manually, which will open a
> completion UI in any case, but this is not the only way to use these
> Cape commands. You can also use the Capfs by adding them to the
> `completion-at-point-functions' list. Then you can use them as usual via
> `completion-at-point'.
Again, I cannot agree or at least I don't see why. My impression is
that using the TeX input method remains more natural to me than adding
cape-tex to `completion-at-point-functions'.
>>> Simple examples are cape-dict, cape-dabbrev or cape-file.
>>> cape-dabbrev for example predates the builtin dabbrev-capf and works in
>>> the same way.
>>
>> How? When I use M-/, the expansion is replaced in place, while
>> cape-dabbrev behaves more like dabbrev-completion (C-M-/) by prompting
>> me for input.
>
> Yes, dabbrev-expand behaves differently. Note that cape-dabbrev also
> replaces the expansion at point if it is unique, like the dabbrev-capf
> or dabbrev-completion. But that's not my point here. Cape provides
> Capfs, and all I am saying is that the Capfs work as well with the
> default completion UI as they do with Corfu. They follow the usual
> implementation practices of other Capfs which are already part of Emacs.
> You can use them by invoking `completion-at-point' and perform a
> step-wise expansion. Selection doesn't has to happen necessarily.
I can't think of an example OOTB where completion-at-point expands a
string like \alpha results in α. When playing around with this, it
feels unnatural to me, but if I am the only one who feels like this then
this doesn't matter. My point is that this feels less unnatural when
used in combination with Corfu, that presents the options as a kind of
selection.
What is relevant for this thread is that there are (debatable) implicit
dependencies between packages that should be kept in mind when
considering to add a package to the core.
> Daniel
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 84%]
* Re: Why not include all ELPA packages in an Emacs release?
@ 2024-05-30 8:00 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-05-30 8:00 UTC (permalink / raw)
To: Tassilo Horn
Cc: Arash Esbati, Eli Zaretskii, Stefan Kangas, jb, emacs-devel,
monnier
Tassilo Horn <tsdh@gnu.org> writes:
> FWIW, I'd rather move more stuff from core to ELPA and add mechanics to
> install from ELPA easily.
There is a gnu-elpa package, and I have prepared a patch to extend
package.el with auto-suggestion capabilities for major modes that could
be installed from ELPA as well.
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 99%]
* Re: Why not include all ELPA packages in an Emacs release?
@ 2024-05-30 7:28 92% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-05-30 7:28 UTC (permalink / raw)
To: Daniel Mendler
Cc: Arash Esbati, Eli Zaretskii, Stefan Kangas, jb, emacs-devel,
monnier
Daniel Mendler <mail@daniel-mendler.de> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Arash Esbati <arash@gnu.org> writes:
>>
>>> Philip Kaludercic <philipk@posteo.net> writes:
>>>
>>>> I am not familiar with cape,
>>>
>>> Cape offers CAPFs, but I think one great featuzre is that you can switch
>>> the CAPF function during completion with something like this in your
>>> init file:
>>>
>>> (use-package cape
>>> :bind (:map corfu-map
>>> ("C-c p d" . cape-dabbrev)
>>> ("C-c p f" . cape-file)
>>> ("C-c p s" . cape-elisp-symbol)
>>> ("C-c p w" . ispell-completion-at-point)
>>> ("C-c p :" . cape-emoji)))
>>
>> I tried it out, and it doesn't seem to work that well without something
>> like corfu or vertico. Generally it seems like an example where
>> "completion" is misinterpreted to mean "selection".
>
> This is not correct. Please stop spreading misinformation like this.
> Capfs like the ones from Cape can be used to complete in a stepwise
> manner.
I understand that, I am just saying that it doesn't feel that natural
without something like corfu enabled as well. Or at least with the
above configuration, something like cape-emoji with the default
in-buffer completion is less comfortable than the built-in C-x 8 e.
Same with dabbrev itself vs. cape-dabbrev.
> Simple examples are cape-dict, cape-dabbrev or cape-file.
> cape-dabbrev for example predates the builtin dabbrev-capf and works in
> the same way.
How? When I use M-/, the expansion is replaced in place, while
cape-dabbrev behaves more like dabbrev-completion (C-M-/) by prompting
me for input.
> Daniel
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 92%]
* Re: Re Re: Why not include all ELPA packages in an Emacs release?
@ 2024-05-30 6:31 97% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-05-30 6:31 UTC (permalink / raw)
To: Pedro Andres Aranda Gutierrez
Cc: emacs-devel, Eli Zaretskii, arash, Stefan Kangas, jb,
Stefan Monnier
Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:
>> >>> And while we're at it: There are sometimes requests for adding AUCTeX
>> to
>> >>> core. Do you have an opinion about that?
>> >>
>> >>I don't mind. But let's hear what others think.
>> >
>> > Well, AUCTeX was so feature-bloated that made me start using vanilla
>> Emacs
>> > and writing the things I really needed myself. So grateful it existed,
>> > because it made my elisp evolve :-)
>>
>> This sounds like a LaTeX/AUCTeX-specific issue. IIUC, you prefer the
>> built-in latex-mode that AUCTeX supersedes, right? Or what do you mean
>> by bloated?
>>
>
> Jup, that was a purely LaTeX issue. And yes, I didn't have time to learn
> all the specifics
> of AUCTeX and did some customisation + yasnippets to get my phD thesis
> written.
> At that time, a switch from MSWord/OpenOffice to LaTeX was churning all my
> free CPU cycles,
> because I had work and real life in parallel.
[...]
> WRT the package size, I wouldn't worry that much. Even a large package
>> like AUCTeX is just under 10MB in my /elpa/ directory. The mean package
>> side on ELPA is about 100-150KB. Packages like Debian that don't
>> bundled .el sources (instead just using .elc) by default might be even
>> better off.
>>
>
> But just keep in mind that there are situations, where the platform must
> deploy
> Emacs on, might not be as relaxed WRT disk space... And it's not about a
> specific
> package, it's about a trickle of packages becoming a flood...
I can imagine that a distribution like Debian can choose to distribute
two package. The regular Emacs, that would bundle the selected ELPA
packages and "emacs-minimal" that wouldn't (and perhaps even remove some
more, like games or some stuff like that).
>> My .2 cents
>>
>> --
>> Philip Kaludercic on peregrine
>>
>
> Best, /PA
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 97%]
* Re: Why not include all ELPA packages in an Emacs release?
@ 2024-05-30 6:25 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-05-30 6:25 UTC (permalink / raw)
To: Arash Esbati; +Cc: Eli Zaretskii, Stefan Kangas, jb, emacs-devel, monnier
Arash Esbati <arash@gnu.org> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> I am not familiar with cape,
>
> Cape offers CAPFs, but I think one great featuzre is that you can switch
> the CAPF function during completion with something like this in your
> init file:
>
> (use-package cape
> :bind (:map corfu-map
> ("C-c p d" . cape-dabbrev)
> ("C-c p f" . cape-file)
> ("C-c p s" . cape-elisp-symbol)
> ("C-c p w" . ispell-completion-at-point)
> ("C-c p :" . cape-emoji)))
I tried it out, and it doesn't seem to work that well without something
like corfu or vertico. Generally it seems like an example where
"completion" is misinterpreted to mean "selection".
>> but IIRC the issue with corfu is that without any further changes, it
>> doesn't support non-graphical Emacs, right?
>
> True, there is corfu-terminal.el for that (which I've never used).
>
>> "Better", in this case, than `fido-vertical-mode'?
>
> I admit I've never used `fido-vertical-mode', so I can't offer a serious
> comparison, sorry.
That's fine.
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 99%]
* Re: Re Re: Why not include all ELPA packages in an Emacs release?
@ 2024-05-29 20:36 77% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-05-29 20:36 UTC (permalink / raw)
To: Pedro Andres Aranda Gutierrez
Cc: emacs-devel, Eli Zaretskii, arash, Stefan Kangas, jb,
Stefan Monnier
Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:
> Message-ID: <86r0dksk1x.fsf@gnu.org>
>
>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>
>>> > If there are packages on ELPA which we consider to be a must for users
>>> > (I don't think there are, but maybe I'm forgetting something), lets
>>> > add them to core instead.
>>>
>>> If Emacs considers in-buffer completion an important feature, then I'd
>>> say corfu and cape are must. vertico and marginalia are also must in my
>>> book since they offer a better experience with vertical minibuffer
>>> completion.
>
>> If people want them, and their developers agree, we can add them.
>
> <irony>At this point, why not company, which BTW works nicely both on
> windows and -nw Emacs?</irony>
I unironically think that this might be a better choice.
> <seriously>For every package you think of integrating, there will be a lot
> of people how use a different package for the functionality, so this spells
> exchanges without end here and a lot of users frustrated in the world
> outside the list </seriously>
Bundling a package with Emacs is not the same as enabling it by default.
I guess the exception are major modes, where it makes sense to have
these added to auto-mode-alist, but otherwise something like Company
shouldn't be enabled by default.
>>> And while we're at it: There are sometimes requests for adding AUCTeX to
>>> core. Do you have an opinion about that?
>>
>>I don't mind. But let's hear what others think.
>
> Well, AUCTeX was so feature-bloated that made me start using vanilla Emacs
> and writing the things I really needed myself. So grateful it existed,
> because it made my elisp evolve :-)
This sounds like a LaTeX/AUCTeX-specific issue. IIUC, you prefer the
built-in latex-mode that AUCTeX supersedes, right? Or what do you mean
by bloated?
> Now seriously, One of the nicest things in Emacs is the package repo(s).
> I have the Emacs I want because we have use-package (and that is not so
> long ago)
> to make our lives (relatively) easy. And I dread to think what would happen
> WTR to size of the distributable object (.app in macos, .rpm/.deb/.snap in
> Linux,
> etc.) if we start shipping everything in it.
There are still plenty of cases where people cannot just install
packages over the net and are stuck with whatever Emacs is bundled with.
ELPA remains useful to upgrade packages that don't depend on new core
features, but having "blessed" packages bundled without having to
explain to new-comers "well yes, Emacs can do that but you have to
install foo, bar and baaz first" (here "foo", "bar" and "baaz" are more
often than not some weird names that they cannot remember in the first
place) is helpful and underappreciated by many.
WRT the package size, I wouldn't worry that much. Even a large package
like AUCTeX is just under 10MB in my /elpa/ directory. The mean package
side on ELPA is about 100-150KB. Packages like Debian that don't
bundled .el sources (instead just using .elc) by default might be even
better off.
> My .2 cents
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 77%]
* Re: Why not include all ELPA packages in an Emacs release?
@ 2024-05-29 16:06 99% ` Philip Kaludercic
1 sibling, 2 replies; 200+ results
From: Philip Kaludercic @ 2024-05-29 16:06 UTC (permalink / raw)
To: Arash Esbati; +Cc: Eli Zaretskii, Stefan Kangas, jb, emacs-devel, monnier
Arash Esbati <arash@gnu.org> writes:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>> If there are packages on ELPA which we consider to be a must for users
>> (I don't think there are, but maybe I'm forgetting something), lets
>> add them to core instead.
>
> If Emacs considers in-buffer completion an important feature, then I'd
> say corfu and cape are must.
I am not familiar with cape, but IIRC the issue with corfu is that
without any further changes, it doesn't support non-graphical Emacs,
right?
> vertico and marginalia are also must in my
> book since they offer a better experience with vertical minibuffer
> completion.
"Better", in this case, than `fido-vertical-mode'?
> And while we're at it: There are sometimes requests for adding AUCTeX to
> core. Do you have an opinion about that?
I would certainly be a fan of that move.
> Best, Arash
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 99%]
* Re: Adding new package hideshowvis to nongnu elpa
@ 2024-05-29 7:26 31% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-05-29 7:26 UTC (permalink / raw)
To: Jan Rehders; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 427 bytes --]
Jan Rehders <jan@sheijk.net> writes:
> Hello,
>
> I’d like to offer my package hideshowvis to be included in nongnu
> elpa.
Are you sure you don't want the package to be added to GNU ELPA?
> It has a few users since many years and since Melpa removed
> Emacs wiki packages years ago there has not been a trivial way to
> install it
Here are a few comments and suggestions from looking at the code:
[-- Attachment #2: Type: text/plain, Size: 12437 bytes --]
diff --git a/hideshowvis.el b/hideshowvis.el
index 745afe8..fa4f863 100644
--- a/hideshowvis.el
+++ b/hideshowvis.el
@@ -1,12 +1,12 @@
;;; hideshowvis.el --- Fringe markers for regions foldable by hideshow.el -*- lexical-binding: t; -*-
-;;
+
;; Copyright 2008-2018 Jan Rehders
-;;
+
;; Author: Jan Rehders <jan@sheijk.net>
;; URL: https://github.com/sheijk/hideshowvis
;; Version: 0.8
-;; Package-Requires: ((emacs "24"))
-;;
+;; Package-Requires: ((emacs "27.1"))
+
;; Contributions and bug fixes by Bryan Waite, Michael Heerdegen, John Yates,
;; Matthew Fidler, and Eyal Soha.
;;
@@ -24,18 +24,19 @@
;; along with GNU Emacs; see the file COPYING. If not, write to
;; the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
;; Boston, MA 02111-1307, USA.
-;;
-;;
+
;;; Commentary:
+
+;; This minor mode will add little +/- displays to foldable regions in
+;; the buffer and to folded regions. It is indented to be used in
+;; conjunction with hideshow.el which is a part of GNU Emacs since
+;; version 20.
;;
-;; This minor mode will add little +/- displays to foldable regions in the
-;; buffer and to folded regions. It is indented to be used in conjunction with
-;; hideshow.el which is a part of GNU Emacs since version 20.
-;;
-;; Currently it works for me but is not tested heavily. Please report any bugs
-;; to the above email address
-;;
+;; Currently it works for me but is not tested heavily. Please report
+;; any bugs to the above email address
+
;;; Installation:
+
;; Add the following to your .emacs:
;;
;; (autoload 'hideshowvis-enable "hideshowvis" "Highlight foldable regions")
@@ -63,16 +64,16 @@
;;
;; It is not enabled by default because it might interfere with custom
;; hs-set-up-overlay functions
-;;
+
;;; TODO
-;;
+
;; - global-hideshowvis-minor-mode
;; - defcustom for hideshowvis-max-file-size needs to offer setting to nil
;; - add fringe icons lazily, only for visible region (check lazy font-lock to
;; see if it can help with this)
-;;
+
;;; Changelog
-;;
+
;; v0.8, 2024-05-28
;; - Fixed interaction with auto-revert-mode and indent-region
;; - Fixed performance issue in some cases due to leaking overlays
@@ -99,27 +100,29 @@
;; v0.2, 2009-08-09
;; - The '-' symbol in fringe is clickable.
;; - Don't show '-' in fringe if the foldable region ends on the same line.
-;;
+
;;; Code:
(require 'hideshow)
+(defgroup hideshowvis ()
+ "Fringe markers for regions foldable by hideshow"
+ :group 'hideshow)
+
(define-fringe-bitmap 'hideshowvis-hideable-marker [0 0 0 126 126 0 0 0])
(defconst hideshowvis-version "v0.7" "Version of hideshowvis minor mode.")
(defface hideshowvis-hidable-face
'((t (:foreground "#ccc" :box t)))
- "Face to highlight foldable regions."
- :group 'hideshow)
+ "Face to highlight foldable regions.")
(defcustom hideshowvis-ignore-same-line t
"No + for single line regions.
Do not display foldable regions in the fringe if the matching closing
parenthesis is on the same line. Set this to nil if enabling the minor mode is
slow on your machine"
- :group 'hideshow
- :type 'bool)
+ :type 'boolean)
(defcustom hideshowvis-max-file-size (* 1024 100)
"No highlighting in files larger than this number of bytes.
@@ -127,8 +130,7 @@ slow on your machine"
‘hideshowvis-enable’ will not enable hideshowvis-mode if file is larger than
this value (in bytes). The minor mode can still be forced to be enabled using
`(hideshowvis-mode 1)'. Set this variable to nil to disable restriction."
- :group 'hideshow
- :type 'integer)
+ :type 'natnum)
(defun hideshowvis-highlight-hs-regions-in-fringe (&optional start end _old-text-length)
"Will update the fringe indicators for all foldable regions in the buffer.
@@ -146,11 +148,9 @@ functions used with `after-change-functions'."
(remove-overlays (point-min) (point-max) 'hideshowvis-hs t)
(while (search-forward-regexp hs-block-start-regexp nil t)
(when (if hideshowvis-ignore-same-line
- (let (begin-line)
- (setq begin-line
- (save-excursion
- (goto-char (match-beginning 0))
- (line-number-at-pos (point))))
+ (let ((begin-line (save-excursion
+ (goto-char (match-beginning 0))
+ (line-number-at-pos (point)))))
(save-excursion
(goto-char (match-beginning 0))
(ignore-errors
@@ -158,16 +158,14 @@ functions used with `after-change-functions'."
(funcall hs-forward-sexp-func 1)
(> (line-number-at-pos (point)) begin-line)))))
t)
- (let* ((ovl (make-overlay (match-beginning 0) (match-end 0)))
- (marker-string "*hideshowvis*"))
- (put-text-property 0
- (length marker-string)
- 'display
- (list 'left-fringe
- 'hideshowvis-hideable-marker
- 'hideshowvis-hidable-face)
- marker-string)
- (overlay-put ovl 'before-string marker-string)
+ (let ((ovl (make-overlay (match-beginning 0) (match-end 0))))
+ (overlay-put ovl 'before-string
+ (propertize
+ "*hideshowvis*"
+ 'display
+ (list 'left-fringe
+ 'hideshowvis-hideable-marker
+ 'hideshowvis-hidable-face)))
(overlay-put ovl 'hideshowvis-hs t))))))))
;;;###autoload
@@ -188,34 +186,32 @@ functions used with `after-change-functions'."
(hs-hide-block)
(beginning-of-line)))
-(defvar hideshowvis-mode-map
+(define-obsolete-variable-alias 'hideshowvis-mode-map
+ 'hideshowvis-minor-mode-map
+ "0.9")
+
+(defvar hideshowvis-minor-mode-map
(let ((hideshowvis-mode-map (make-sparse-keymap)))
(define-key hideshowvis-mode-map [left-fringe mouse-1]
'hideshowvis-click-fringe)
hideshowvis-mode-map)
- "Keymap for hideshowvis mode.")
+ "Keymap for `hideshowvis-minor-mode'.")
;;;###autoload
-(define-minor-mode hideshowvis-minor-mode ()
- :doc "Will indicate regions foldable with hideshow in the fringe."
- :init-value nil
- :require 'hideshow
- :group 'hideshow
- :keymap hideshowvis-mode-map
- (condition-case nil
+(define-minor-mode hideshowvis-minor-mode
+ "Will indicate regions foldable with hideshow in the fringe."
+ :global nil
+ (condition-case err
(if hideshowvis-minor-mode
(progn
(hs-minor-mode 1)
(hideshowvis-highlight-hs-regions-in-fringe (point-min) (point-max) 0)
- (add-to-list 'after-change-functions
- 'hideshowvis-highlight-hs-regions-in-fringe))
+ (add-hook 'after-change-functions
+ #'hideshowvis-highlight-hs-regions-in-fringe))
(remove-overlays (point-min) (point-max) 'hideshowvis-hs t)
- (setq after-change-functions
- (remove 'hideshowvis-highlight-hs-regions-in-fringe
- after-change-functions)))
- (error
- (message "Failed to toggle hideshowvis-minor-mode")
- )))
+ (remove-hook 'after-change-functions
+ #'hideshowvis-highlight-hs-regions-in-fringe))
+ (error (message "Failed to toggle `hideshowvis-minor-mode': %S" err))))
;;;###autoload
(defun hideshowvis-enable ()
@@ -229,37 +225,35 @@ functions used with `after-change-functions'."
(defcustom hideshowvis-hidden-fringe-face 'hideshowvis-hidden-fringe-face
"*Specify face used to highlight the fringe on hidden regions."
- :type 'face
- :group 'hideshow)
+ :type 'face)
-(defface hideshowvis-hidden-fringe-face
+(defface hideshowvis-hidden-fringe-face ;perhaps alias `mode-line-highlight'
'((t (:foreground "#888" :box (:line-width 2 :color "grey75" :style released-button))))
- "Face used to highlight the fringe on folded regions."
- :group 'hideshow)
+ "Face used to highlight the fringe on folded regions.")
(defcustom hideshowvis-hidden-region-face 'hideshowvis-hidden-region-face
"*Specify the face to to use for the hidden region indicator."
- :type 'face
- :group 'hideshow)
+ :type 'face)
(defface hideshowvis-hidden-region-face
'((t (:background "#ff8" :box t)))
- "Face to hightlight the ... area of hidden regions."
- :group 'hideshow)
+ "Face to hightlight the ... area of hidden regions.")
(defun hideshowvis-display-code-line-counts (ov)
"Extend overlay OV to show number of lines hidden for `hideshowvis-symbols'."
(when (eq 'code (overlay-get ov 'hs))
- (let* ((marker-string "*fringe-dummy*")
- (marker-length (length marker-string))
- (display-string (format "%d lines" (count-lines (overlay-start ov) (overlay-end ov)))))
- (overlay-put ov 'help-echo "Hidden text. C-c,= to show")
- (put-text-property 0 marker-length 'display
- (list 'left-fringe 'hideshowvis-hidden-marker 'hideshowvis-hidden-fringe-face)
- marker-string)
- (overlay-put ov 'before-string marker-string)
- (put-text-property 0 (length display-string) 'face 'hideshowvis-hidden-region-face display-string)
- (overlay-put ov 'after-string display-string))))
+ (overlay-put ov 'help-echo "Hidden text. C-c,= to show")
+ (overlay-put ov 'before-string
+ (propertize
+ "*fringe-dummy*"
+ 'display
+ '(left-fringe
+ hideshowvis-hidden-marker
+ hideshowvis-hidden-fringe-face)))
+ (overlay-put ov 'after-string
+ (propertize
+ (format "%d lines" (count-lines (overlay-start ov) (overlay-end ov)))
+ 'face 'hideshowvis-hidden-region-face))))
;;;###autoload
(defun hideshowvis-symbols ()
@@ -271,12 +265,12 @@ indicating the number of hidden lines at the end of the line for hidden regions.
This will change the value of `hs-set-up-overlay' so it will
overwrite anything you've set there."
(interactive)
- (setq hs-set-up-overlay 'hideshowvis-display-code-line-counts)
+ (setq hs-set-up-overlay #'hideshowvis-display-code-line-counts)
;; These won't get removed, again. Revert hooks are global and making them
;; buffer local might be risky. Instead checking whether showing symbols is
;; turned on in the hook functions
- (add-hook 'before-revert-hook 'hideshowvis-remove-overlays)
- (add-hook 'after-revert-hook 'hideshowvis-update-all-overlays)
+ (add-hook 'before-revert-hook #'hideshowvis-remove-overlays)
+ (add-hook 'after-revert-hook #'hideshowvis-update-all-overlays)
(hideshowvis-update-all-overlays))
;;;###autoload
@@ -284,21 +278,21 @@ overwrite anything you've set there."
"Disable enhanced highlighting of hidden regions."
(interactive)
(hideshowvis-remove-overlays)
- (setq hs-set-up-overlay 'ignore))
+ (setq hs-set-up-overlay #'ignore))
(defun hideshowvis-remove-overlays ()
"Will remove all overlays added after calling `hideshowvis-symbols'."
- (when (equal hs-set-up-overlay 'hideshowvis-display-code-line-counts)
+ (when (eq hs-set-up-overlay #'hideshowvis-display-code-line-counts)
(dolist (ov (overlays-in (point-min) (point-max)))
- (unless (null (overlay-get ov 'hs))
+ (when (overlay-get ov 'hs) ;why are you returning a `hs' here?
(overlay-put ov 'after-string nil)))))
(defun hideshowvis-update-all-overlays ()
"Will update all overlays added after calling `hideshowvis-symbols'."
- (when (equal hs-set-up-overlay 'hideshowvis-display-code-line-counts)
+ (when (eq hs-set-up-overlay #'hideshowvis-display-code-line-counts)
(dolist (ov (overlays-in (point-min) (point-max)))
- (unless (null (overlay-get ov 'hs))
- (if (equal (overlay-start ov) (overlay-end ov))
+ (when (overlay-get ov 'hs)
+ (if (= (overlay-start ov) (overlay-end ov))
(delete-overlay ov)
(hideshowvis-display-code-line-counts ov))))))
[-- Attachment #3: Type: text/plain, Size: 1185 bytes --]
> Kind regards,
> Jan
>
> From 9d2e52bf2e07e8b6a6f1049b4a74d34efdb58a4b Mon Sep 17 00:00:00 2001
> From: Jan Rehders <nospam@sheijk.net>
> Date: Tue, 28 May 2024 16:18:56 +0200
> Subject: [PATCH] elpa-packages (hideshowvis): New package
>
> ---
> elpa-packages | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/elpa-packages b/elpa-packages
> index 82dc12718b..6bb7524f86 100644
> --- a/elpa-packages
> +++ b/elpa-packages
> @@ -371,6 +371,12 @@
> "helm-pkg.el" "helm-regexp.el" "helm-ring.el" "helm-semantic.el" "helm-shell.el"
> "helm-sys.el" "helm-tags.el" "helm-types.el" "helm-utils.el" "helm-x-files.el"))
>
> + (hideshowvis
> + :url "https://github.com/sheijk/hideshowvis/"
> + :branch "main"
> + :ignored-files ("screenshot.png")
You can track files to ignore in a .elpaignore file as well. That might
be better, in case you decide to replace, rename the file or add more.
I can change that for you, you just have to add the file to the
repository.
> + :readme "README.md")
> +
> (highlight-parentheses :url "https://git.sr.ht/~tsdh/highlight-parentheses.el"
> :branch "main"
> :readme "README.md"
--
Philip Kaludercic on peregrine
^ permalink raw reply related [relevance 31%]
* Re: Why not include all ELPA packages in an Emacs release?
@ 2024-05-29 5:59 99% ` Philip Kaludercic
1 sibling, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-05-29 5:59 UTC (permalink / raw)
To: Stefan Kangas; +Cc: Jeremy Bryant, Emacs Devel, Stefan Monnier
Stefan Kangas <stefankangas@gmail.com> writes:
> Jeremy Bryant <jb@jeremybryant.net> writes:
>
>> Would there be a problem in including a snapshot of ELPA packages in an
>> Emacs release?
>
> This has been discussed several times in the past. There are no
> principal problems, and AFAIU the consensus is that we would like to
> do it, though there are some practical issues to work out.
>
> I believe if you search the list archives, you will find previous
> discussions that will shed some light on the issues involved. We can't
> just dump all packages in lisp/ and be done with it, unfortunately.
>
> I honestly can't cite all of the problems off the top of my head.
I have bookmarked this message by Eli, where he links to a few threads
with issues that should be dealt with: <83zg27emh8.fsf@gnu.org>
> One
> is how we track developments on GNU ELPA, if we mirror packages into
> emacs.git, or if we add them as submodules, or what. At the very least,
> we'd probably need to have some record of what we put into the release
> tarball. Do we add _all_ packages or just some subset? Should they be
> registered in `package--builtins´, and how? Should they be part of the
> main release tarball, or released separately? And so on.
>
> Mostly, we need an interested volunteer to step up and do the work.
> This would probably start with reviewing past discussions to find out
> what problems they uncovered. Then propose, in practical terms, how we
> could solve them.
>
> So help is both welcome and needed here, I think.
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 99%]
* Re: [PATCH] csv-mode.el: Add function for reading a CSV line
@ 2024-05-25 8:26 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-05-25 8:26 UTC (permalink / raw)
To: Joost Kremers; +Cc: Emacs Devel
Joost Kremers <joostkremers@fastmail.fm> writes:
> On Wed, May 22 2024, Philip Kaludercic wrote:
> [patch]
>> Seems fine to me. I'd apply it if there are no objections. Until then,
>> you can prepare to modify your package to use this change.
>
> I was just about to suggest one more test. Specifically:
>
> ```
> (should (equal (let ((csv-field-quotes '("\"" "'")))
> (csv--unquote-value "'Hello, \"World\"'"))
> "Hello, \"World\""))
> ```
>
> It tests the case where the user defined more than one possible quote character,
> one being used to quote the field and the other being used inside the field.
>
> The attached patch adds this test but is otherwise identical to the previous
> one.
>
> Otherwise, thanks! :-)
Looks like nobody has any objections, so I pushed the changes to
elpa.git. Thanks.
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 99%]
* Re: [PATCH] csv-mode.el: Add function for reading a CSV line
@ 2024-05-22 16:14 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-05-22 16:14 UTC (permalink / raw)
To: Joost Kremers; +Cc: Emacs Devel
Joost Kremers <joostkremers@fastmail.fm> writes:
> On Wed, May 22 2024, Philip Kaludercic wrote:
>> Joost Kremers <joostkremers@fastmail.fm> writes:
>>> +(defun csv--unquote-value (value)
>>> + "Remove quotes around VALUE.
>>> +If VALUE contains escaped quote characters, un-escape them. If
>>> +VALUE is not quoted, return it unchanged."
>>> + (save-match-data
>>> + (let ((quote-regexp (apply #'concat `("[" ,@csv-field-quotes "]"))))
>>> + (string-match (concat "^\\(" quote-regexp "\\)\\(.*\\)\\(" quote-regexp "\\)$") value)
>>
>> Shouldn't this `string-match' be in the if-let?
>
> I considered that, but in this particular case, `(match-string 1 value)` returns
> nil if the first character of `value` isn't in `csv-field-quotes`, so it seems
> to be OK.
>
> Emphasis on "seems" though... Plus, there's no need to call `match-string` at
> all if `string-match` failed, of course. So new patch attached.
>
>> Take this example,
>>
>> (let ((str "1 2 3"))
>> (list (string-match "2" str)
>> (match-string 0 str)
>> (string-match "4" str)
>> (match-string 0 str)))
>> ;;=> (2 "2" nil "2")
>>
>> even though string-match failed, the match data remains and matc-string
>> returns non-nil values.
>
> Oh... I kinda assumed that `string-match` would always reset all of the match
> data, but apparently not. Good to know!
>
>
> Thanks,
>
> Joost
>
>
> --
> Joost Kremers
> Life has its moments
>
> From bb582c8e413451f59db1d26d4c0208348370283b Mon Sep 17 00:00:00 2001
> From: Joost Kremers <joostkremers@fastmail.com>
> Date: Wed, 22 May 2024 00:07:34 +0200
> Subject: [PATCH] Add function for reading a CSV line and return its values as
> a list.
>
> * (csv-parse-current-row): New function; unlike csv--collect-fields,
> unquotes the field values.
> * (csv--unquote-value): New function.
> ---
> csv-mode-tests.el | 23 +++++++++++++++++++++++
> csv-mode.el | 26 +++++++++++++++++++++++++-
> 2 files changed, 48 insertions(+), 1 deletion(-)
>
> diff --git a/csv-mode-tests.el b/csv-mode-tests.el
> index 0caeab7..12d0417 100644
> --- a/csv-mode-tests.el
> +++ b/csv-mode-tests.el
> @@ -144,5 +144,28 @@
> (csv--separator-score ?\; csv-tests--data
> (length csv-tests--data)))))
>
> +(ert-deftest csv-tests-unquote-value ()
> + (should (equal (csv--unquote-value "Hello, World")
> + "Hello, World"))
> + (should (equal (csv--unquote-value "\"Hello, World\"")
> + "Hello, World"))
> + (should (equal (csv--unquote-value "Hello, \"\"World")
> + "Hello, \"\"World"))
> + (should (equal (csv--unquote-value "\"Hello, \"\"World\"\"\"")
> + "Hello, \"World\""))
> + (should (equal (csv--unquote-value "'Hello, World'")
> + "'Hello, World'"))
> + (should (equal (let ((csv-field-quotes '("\"" "'")))
> + (csv--unquote-value "\"Hello, World'"))
> + "\"Hello, World'"))
> + (should (equal (let ((csv-field-quotes '("\"" "'")))
> + (csv--unquote-value "'Hello, World'"))
> + "Hello, World"))
> + (should (equal (let ((csv-field-quotes '("\"" "'")))
> + (csv--unquote-value "'Hello, ''World'''"))
> + "Hello, 'World'"))
> + (should (equal (csv--unquote-value "|Hello, World|")
> + "|Hello, World|")))
> +
> (provide 'csv-mode-tests)
> ;;; csv-mode-tests.el ends here
> diff --git a/csv-mode.el b/csv-mode.el
> index f639dcf..ebcd9da 100644
> --- a/csv-mode.el
> +++ b/csv-mode.el
> @@ -4,7 +4,7 @@
>
> ;; Author: "Francis J. Wright" <F.J.Wright@qmul.ac.uk>
> ;; Maintainer: emacs-devel@gnu.org
> -;; Version: 1.23
> +;; Version: 1.24
> ;; Package-Requires: ((emacs "27.1") (cl-lib "0.5"))
> ;; Keywords: convenience
>
> @@ -107,6 +107,10 @@
>
> ;;; News:
>
> +;; Since 1.24
> +;; - New function `csv--unquote-value'.
> +;; - New function `csv-parse-current-row'.
> +
> ;; Since 1.21:
> ;; - New command `csv-insert-column'.
> ;; - New config var `csv-align-min-width' for `csv-align-mode'.
> @@ -1400,6 +1404,26 @@ point is assumed to be at the beginning of the line."
> (forward-char)))
> (nreverse fields)))))
>
> +(defun csv--unquote-value (value)
> + "Remove quotes around VALUE.
> +If VALUE contains escaped quote characters, un-escape them. If
> +VALUE is not quoted, return it unchanged."
> + (save-match-data
> + (let ((quote-regexp (apply #'concat `("[" ,@csv-field-quotes "]"))))
> + (if-let (((string-match (concat "^\\(" quote-regexp "\\)\\(.*\\)\\(" quote-regexp "\\)$") value))
> + (quote-char (match-string 1 value))
> + ((equal quote-char (match-string 3 value)))
> + (unquoted (match-string 2 value)))
> + (replace-regexp-in-string (concat quote-char quote-char) quote-char unquoted)
> + value))))
> +
> +(defun csv-parse-current-row ()
> + "Parse the current CSV line.
> +Return the field values as a list."
> + (save-mark-and-excursion
> + (goto-char (line-beginning-position))
> + (mapcar #'csv--unquote-value (csv--collect-fields (line-end-position)))))
> +
> (defvar-local csv--header-line nil)
> (defvar-local csv--header-hscroll nil)
> (defvar-local csv--header-string nil)
Seems fine to me. I'd apply it if there are no objections. Until then,
you can prepare to modify your package to use this change.
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 99%]
* Re: [PATCH] csv-mode.el: Add function for reading a CSV line
@ 2024-05-22 6:17 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-05-22 6:17 UTC (permalink / raw)
To: Joost Kremers; +Cc: Emacs Devel
Joost Kremers <joostkremers@fastmail.fm> writes:
> Hi,
>
> @Philip Kaludercic, as per your suggestion
> (https://lists.gnu.org/archive/html/emacs-devel/2024-05/msg00966.html), here's a
> patch for csv-mode.el to add a function for reading a CSV line and unquoting the
> resulting field values.
>
> I've put the unquoting in a separate (internal) function, csv--unquote-value,
> which also un-escapes escaped quote characters inside the field value. As per
> RFC 4180, the escape character is the quote character. The RFC only mentions the
> double quotation mark as quote character, but csv-mode.el makes it possible to
> use other quote characters, so the patch supports that as well.
>
> I've also added a test for csv--unquote-value.
>
>
>
> --
> Joost Kremers
> Life has its moments
>
> From e97b8b8cca3f987cbdf5e29ec184f37825755eba Mon Sep 17 00:00:00 2001
> From: Joost Kremers <joostkremers@fastmail.com>
> Date: Wed, 22 May 2024 00:07:34 +0200
> Subject: [PATCH] Add function for reading a CSV line and return its values as
> a list.
>
> * (csv-parse-current-row): New function; unlike csv--collect-fields,
> unquotes the field values.
> * (csv--unquote-value): New function.
> ---
> csv-mode-tests.el | 12 ++++++++++++
> csv-mode.el | 26 +++++++++++++++++++++++++-
> 2 files changed, 37 insertions(+), 1 deletion(-)
>
> diff --git a/csv-mode-tests.el b/csv-mode-tests.el
> index 0caeab7..ea955a9 100644
> --- a/csv-mode-tests.el
> +++ b/csv-mode-tests.el
> @@ -144,5 +144,17 @@
> (csv--separator-score ?\; csv-tests--data
> (length csv-tests--data)))))
>
> +(ert-deftest csv-tests-unquote-value ()
> + (should (equal (csv--unquote-value "Hello, World")
> + "Hello, World"))
> + (should (equal (csv--unquote-value "\"Hello, World\"")
> + "Hello, World"))
> + (should (equal (csv--unquote-value "Hello, \"\"World")
> + "Hello, \"\"World"))
> + (should (equal (csv--unquote-value "\"Hello, \"\"World\"\"\"")
> + "Hello, \"World\""))
> + (should (equal (csv--unquote-value "\"Hello, World'")
> + "\"Hello, World'")))
> +
> (provide 'csv-mode-tests)
> ;;; csv-mode-tests.el ends here
> diff --git a/csv-mode.el b/csv-mode.el
> index f639dcf..09402c2 100644
> --- a/csv-mode.el
> +++ b/csv-mode.el
> @@ -4,7 +4,7 @@
>
> ;; Author: "Francis J. Wright" <F.J.Wright@qmul.ac.uk>
> ;; Maintainer: emacs-devel@gnu.org
> -;; Version: 1.23
> +;; Version: 1.24
> ;; Package-Requires: ((emacs "27.1") (cl-lib "0.5"))
> ;; Keywords: convenience
>
> @@ -107,6 +107,10 @@
>
> ;;; News:
>
> +;; Since 1.24
> +;; - New function `csv--unquote-value'.
> +;; - New function `csv-parse-current-row'.
> +
> ;; Since 1.21:
> ;; - New command `csv-insert-column'.
> ;; - New config var `csv-align-min-width' for `csv-align-mode'.
> @@ -1400,6 +1404,26 @@ point is assumed to be at the beginning of the line."
> (forward-char)))
> (nreverse fields)))))
>
> +(defun csv--unquote-value (value)
> + "Remove quotes around VALUE.
> +If VALUE contains escaped quote characters, un-escape them. If
> +VALUE is not quoted, return it unchanged."
> + (save-match-data
> + (let ((quote-regexp (apply #'concat `("[" ,@csv-field-quotes "]"))))
> + (string-match (concat "^\\(" quote-regexp "\\)\\(.*\\)\\(" quote-regexp "\\)$") value)
Shouldn't this `string-match' be in the if-let?
Take this example,
(let ((str "1 2 3"))
(list (string-match "2" str)
(match-string 0 str)
(string-match "4" str)
(match-string 0 str)))
;;=> (2 "2" nil "2")
even though string-match failed, the match data remains and matc-string
returns non-nil values.
> + (if-let ((quote-char (match-string 1 value))
> + ((equal quote-char (match-string 3 value)))
> + (unquoted (match-string 2 value)))
> + (replace-regexp-in-string (concat quote-char quote-char) quote-char unquoted)
> + value))))
> +
> +(defun csv-parse-current-row ()
> + "Parse the current CSV line.
> +Return the field values as a list."
> + (save-mark-and-excursion
> + (goto-char (line-beginning-position))
> + (mapcar #'csv--unquote-value (csv--collect-fields (line-end-position)))))
> +
> (defvar-local csv--header-line nil)
> (defvar-local csv--header-hscroll nil)
> (defvar-local csv--header-string nil)
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 99%]
* Re: [ELPA] New package: csv2ledger
2024-05-20 12:18 78% ` Philip Kaludercic
@ 2024-05-20 12:26 86% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-05-20 12:26 UTC (permalink / raw)
To: Joost Kremers; +Cc: emacs-devel
[...]
>> I can remove dash if you prefer, though. There are two dash
>> functions I use that
>> don't seem to have a direct built-in equivalent (as far as I can tell):
>> `-compose` and `-zip-pair`. I'm sure I can deal with them.
>
> -Compose seems like it is easy to replace, but it might be an idea to
> add something to the core as well. One should try to improve the output
> of the byte-code though:
>
> (disassemble (byte-compile (lambda (x) (funcall (-compose 'foo 'bar 'baz) x))))
> byte code:
> doc: ...
> args: (arg1)
> 0 constant <byte-code-function>
> doc: ...
> args: (&rest rest)
> 0 constant apply
> 1 constant baz
> 2 stack-ref 2
> 3 call 2
> 4 constant (bar foo)
> 5 constant 0
> 6 constant nil
> 7 dup
> 8:1 stack-ref 3
> 9 goto-if-nil 2
> 12 stack-ref 3
> 13 dup
> 14 cdr
> 15 stack-set 5
> 17 discardN-preserve-tos 2
> 19 car-safe
> 20 stack-ref 1
> 21 dup
> 22 add1
> 23 stack-set 3
> 25 stack-ref 1
> 26 stack-ref 5
> 27 call 1
> 28 stack-set 5
> 30 goto 1
> 33:2 discardN 4
> 35 return
>
> 1 stack-ref 1
> 2 call 1
> 3 return
>
> compared to the direct:
>
> (disassemble (byte-compile (lambda (x) (foo (bar (baz x))))))
> byte code:
> doc: ...
> args: (arg1)
> 0 constant foo
> 1 constant bar
> 2 constant baz
> 3 stack-ref 3
> 4 call 1
> 5 call 1
> 6 call 1
> 7 return
Correction, the first disassembly should be
(disassemble (byte-compile (-compose 'foo 'bar 'baz)))
byte code:
doc: ...
args: (&rest rest)
0 constant apply
1 constant baz
2 stack-ref 2
3 call 2
4 constant (bar foo)
5 constant 0
6 constant nil
7 dup
8:1 stack-ref 3
9 goto-if-nil 2
12 stack-ref 3
13 dup
14 cdr
15 stack-set 5
17 discardN-preserve-tos 2
19 car-safe
20 stack-ref 1
21 dup
22 add1
23 stack-set 3
25 stack-ref 1
26 stack-ref 5
27 call 1
28 stack-set 5
30 goto 1
33:2 discardN 4
35 return
avoiding the unnecessary lambda.
It appears even a naive approach to implement the function oneself gives
better results:
(defun compose (&rest fns)
(lambda (arg)
(dotimes (fn (nreverse fns))
(setq arg (funcall fn arg)))
arg))
(disassemble (byte-compile (compose 'foo 'bar 'baz)))
byte code:
doc: ...
args: (arg1)
0 constant (foo bar baz)
1 nreverse
2 constant 0
3:1 dup
4 stack-ref 2
5 lss
6 goto-if-nil 2
9 dup
10 stack-ref 3
11 call 1
12 stack-set 3
14 add1
15 goto 1
18:2 discardN 2
20 return
[...]
^ permalink raw reply [relevance 86%]
* Re: [ELPA] New package: csv2ledger
@ 2024-05-20 12:18 78% ` Philip Kaludercic
2024-05-20 12:26 86% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-05-20 12:18 UTC (permalink / raw)
To: Joost Kremers; +Cc: emacs-devel
Joost Kremers <joostkremers@fastmail.fm> writes:
> Hi Philip,
>
> On Mon, May 20 2024, Philip Kaludercic wrote:
>> Joost Kremers <joostkremers@fastmail.fm> writes:
>>> https://codeberg.org/joostkremers/csv2ledger
>>
>> I don't have the time for a proper review of the package for now, but
>> that shouldn't block adding the package. I'll try to come back to you
>> later with a few comments (e.g. getting rid of the dash dependency).
>
> Is dash a real problem? I mean, it's on GNU ELPA, and I specifically made sure
> to target the version there.
I consider it an unnecessary dependency that introduces a different
style of programming that not everyone has to be familiar with. So it
is not a "real" problem, but I consider it an annoyance that I'd
personally like to help get rid of.
> I can remove dash if you prefer, though. There are two dash functions I use that
> don't seem to have a direct built-in equivalent (as far as I can tell):
> `-compose` and `-zip-pair`. I'm sure I can deal with them.
-Compose seems like it is easy to replace, but it might be an idea to
add something to the core as well. One should try to improve the output
of the byte-code though:
(disassemble (byte-compile (lambda (x) (funcall (-compose 'foo 'bar 'baz) x))))
byte code:
doc: ...
args: (arg1)
0 constant <byte-code-function>
doc: ...
args: (&rest rest)
0 constant apply
1 constant baz
2 stack-ref 2
3 call 2
4 constant (bar foo)
5 constant 0
6 constant nil
7 dup
8:1 stack-ref 3
9 goto-if-nil 2
12 stack-ref 3
13 dup
14 cdr
15 stack-set 5
17 discardN-preserve-tos 2
19 car-safe
20 stack-ref 1
21 dup
22 add1
23 stack-set 3
25 stack-ref 1
26 stack-ref 5
27 call 1
28 stack-set 5
30 goto 1
33:2 discardN 4
35 return
1 stack-ref 1
2 call 1
3 return
compared to the direct:
(disassemble (byte-compile (lambda (x) (foo (bar (baz x))))))
byte code:
doc: ...
args: (arg1)
0 constant foo
1 constant bar
2 constant baz
3 stack-ref 3
4 call 1
5 call 1
6 call 1
7 return
-Zip-pair sounds like something that cl-loop could replicate.
>>> There are already many solutions to do this conversion, not the least Ledger
>>> itself, which provides a `convert` command. None of these are Emacs-based,
>>> however, and none that I know of offer the customisability that I needed
>>> myself.
>>
>> Can you elaborate on what you mean by "Emacs-based"?
>
> Conveniently integrated into Emacs. You're right, of course, that any CLI-based
> solution can be integrated into Emacs with some glue code. It's just that I'm
> not aware that anyone has written such glue code. (Though I might have missed
> something, of course).
>
>>> I'm proposing this package for inclusion into Non-GNU ELPA, not GNU ELPA,
>>> because it depends on a package that's only available on MELPA,
>>> `parse-csv`.[3] (If that is a problem, please let me know. I'm assuming it's
>>> a problem for GNU ELPA, but not for Non-GNU ELPA.)[4]
>
>> That is a blocker for both repositories.
>
> OK. Makes sense, actually.
>
>> A quick peak at the package reveals it to be more or less a single
>> function. Can you check of the csv-mode on ELPA provides anything you
>> need? It seems like something that could be replicated in that package.
>
> Yes, it's just one single function, `parse-csv-string`. I've taken a closer look
> at csv-mode and just found the function `csv--collect-fields`, which seems to do
> basically the same as `parse-csv-string`, but a) it's an internal function; and
> b) it doesn't strip quotes from field values.
>
> Neither seems unsolvable, I guess. I would be interested in your opinion,
> though, as to what would be better: add a public function to csv-mode.el that
> strips the quotes, or call `csv--collect-fields` from csv2ledger.el and strip
> the quotes there?
If you provide a patch for csv-mode, I'd be happy to apply it. That
sounds like a useful functionality to have.
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 78%]
* Re: [ELPA] some tex-related packages
@ 2024-05-20 9:18 91% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-05-20 9:18 UTC (permalink / raw)
To: Paul Nelson; +Cc: emacs-devel, Arash Esbati
Paul Nelson <ultrono@gmail.com> writes:
> Hi Philip (CC: Arash, in case you have further thoughts),
>
>
>> Perhaps it should be renamed to something like "latex-numbering"?
>>
>
> Thanks for this suggestion, agreed.
>
>>
>> > tex-continuous provides a minor mode in which a tex document is compiled
>> > continuously using latexmk, the error log is parsed using AUCTeX, and
>> > errors are reported via flymake.
>>
>> That sounds interesting. Here again, tex- implies one thing but latexmk
>> another.
>
>
> How about "latexmk-continuous"? (The names latex-flymake and
> auctex-latexmk are both taken, and those packages do different things. The
> new feature is that the compilation takes place continuously rather than on
> demand, with the errors reported in the buffer.)
Sounds good and descriptive!
>
>> Is the dependency on latexmk hard, or could you re-use AUCTeX's facilities?
>>
>
> AUCTeX provides TeX-command-run-all, which does something similar to
> latexmk (and also runs "View" at the end, displaying the PDF, which I
> suppose could be disabled somehow). I considered swapping latexmk for
> TeX-command-run-all + after-save-hook, but this seemed troublesome for a
> few reasons. One was that the timer for preview-auto (my other package,
> mentioned below) doesn't fire when AUCTeX's processes are active, so if we
> use AUCTeX to regularly recompile the document, then there will be
> stretches of time in which the previews don't update. The use of a
> separate (latexmk) process adds something like a secondary compilation
> thread, keeping the primary thread free for preview-auto.
>
> I don't view the dependency on latexmk as serious, since I believe it is
> included nowadays in all tex distributions (and I have colleagues who have
> been using my package on each of the major OS's, so it seems portable in
> practice). My package does re-use AUCTeX's error parsing facilities, which
> in some sense provide the heavy lifting, and also respects some AUCTeX
> configuration variables, such as TeX-output-dir. I'd be happy to update
> the package to use more of AUCTeX's facilities if someone spotted a way to
> do so without the issues that I encountered.
As it is an external package, I don't think the dependency on the
external package is an issue either (especially if the name makes it
explicit to prevent an unpleasant surprise).
>>
>> > preview-auto provides a minor mode in which AUCTeX previews generate
>> > automatically in the visible part of the buffer.
>>
>> This makes me think, have you communicated any of these features to the
>> AUCTeX developers? Perhaps it would make more sense to upstream these
>> as patches instead of having too many little packages?
>>
>>
> They've been communicated, and the first two have been discussed:
>
> https://lists.gnu.org/archive/html/auctex-devel/2024-04/msg00043.html
> https://lists.gnu.org/archive/html/auctex-devel/2024-04/msg00066.html
> https://lists.gnu.org/archive/html/auctex-devel/2024-04/msg00086.html
>
> They rely on recent AUCTeX patches:
>
> https://lists.gnu.org/archive/html/bug-auctex/2024-04/threads.html
>
> The question of upstreaming one of them was raised:
>
> https://lists.gnu.org/archive/html/auctex-devel/2024-04/msg00173.html
>
> I'd be happy with whatever makes the most sense, but figured submitting to
> ELPA would make them readily available without introducing additional
> burden on the AUCTeX maintainers.
I'll let the AUCTeX maintainers decide. That being said, I am sure
they'd always appreciate a helping hand in general.
> On the topic of "too many little packages", I'll confess that I have a few
> more in the queue, e.g.:
>
> https://github.com/ultronozm/tex-parens.el
> https://github.com/ultronozm/tex-item.el
> https://github.com/ultronozm/preview-auto.el
>
> (plus a few more, listed at https://github.com/ultronozm/emacsd, that I'd
> like to think about more before "formally" publishing)
>
> I've been trying to split the functionality accumulated in my config into
> the smallest coherent packages that I can, but would welcome feedback or
> other suggestions, especially if there are trade-offs with having too many
> little packages.
It might just be my view, but having too many little packages makes it
difficult for newcomers to get an overview and understand what they want
or need. Having code under the maintainance of a group of people
usually makes it more future-proof, both by reducing the bus-factor but
also by having more time to fine polish the code.
> Thanks, best,
>
> Paul
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 91%]
* Re: [ELPA] Re: SageMath and Emacs
2024-05-09 12:24 99% ` [ELPA] " Philip Kaludercic
@ 2024-05-20 7:03 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-05-20 7:03 UTC (permalink / raw)
To: Rahguzar; +Cc: emacs-devel
Philip Kaludercic <philipk@posteo.net> writes:
> Rahguzar <rahguzar@zohomail.eu> writes:
>
>> Dear Emacs developers,
>>
>> I want to ask opinions about including support for SageMath in Emacs or
>> GNU ELPA.
>>
>> SageMath is a niche software but I think the niche is a very important
>> one. It is also the best computer algebra system which is also free
>> software and hence important to advance free software in a field
>> dominated proprietary software. (This dominance is especially sad since
>> proprietary software is a very shaky foundation for scientific
>> research.)
>>
>> The SageMath project project provides Emacs modes both for source files
>> and repl. They code can be found at
>> https://github.com/sagemath/sage-shell-mode
>>
>> It is a large code base but looking at it a year or so ago, I realized
>> that most of the code was implementing functionality that is by now
>> included in the python.el in Emacs. SageMath is a thin wrapper around Python
>> and as a result basic support for it can be provided by setting some
>> variables provided by python.el appropriately.
>>
>> I wrote such a wrapper around python.el which is hosted at
>> https://codeberg.org/rahguzar/sage-mode
>>
>> There is more code there than needed because I wanted to change some
>> behaviors of python.el but now I think those deviations should be
>> removed. As a result I think basic functionality can be provided by
>> addition of 200-300 lines in python.el (or a separate file requiring
>> it). If there is an interest in providing out of box support for
>> SageMath I can prepare such a patch.
>>
>> I have been meaning to send this email for a while but never came around
>> to it. I am sending this now because I saw Eli's message about a pretest
>> for Emacs 30 being imminent. It might be already too late for Emacs 30
>> but if the pretest is a week or two away there might be time.
>>
>> If inclusion in Emacs core is not considered a good option, I will like
>> to contribute support to ELPA. I would like to hear opinions of the
>> people maintaining the current SageMath support and opened an issue at
>> https://github.com/sagemath/sage-shell-mode/issues/80 but I haven't
>> heard from them (it has only been a few days).
>
> It certainly can be added to ELPA, but I guess it would be easier to
> discuss the matter if you could provide a patch for emacs.git, if that
> is not too much work.
Ping?
>> Thanks,
>> Rahguzar
>>
>>
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 99%]
* Re: [NonGNU ELPA] hyperdrive: Use stable release branch
@ 2024-05-20 7:03 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-05-20 7:03 UTC (permalink / raw)
To: Joseph Turner; +Cc: Emacs Devel Mailing List, Adam Porter
Joseph Turner <joseph@ushin.org> writes:
> Thank you!
Done.
> From bb76e471b67cad22d25c0141f6fd93ebd95eb081 Mon Sep 17 00:00:00 2001
> From: Joseph Turner <joseph@breatheoutbreathe.in>
> Date: Wed, 15 May 2024 13:56:47 -0700
> Subject: [PATCH] elpa-packages (hyperdrive): Use "stable" release branch
>
> ---
> elpa-packages | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/elpa-packages b/elpa-packages
> index 684a3328ba..82dc12718b 100644
> --- a/elpa-packages
> +++ b/elpa-packages
> @@ -387,6 +387,7 @@
> (hyperdrive :url "https://git.sr.ht/~ushin/hyperdrive.el"
> :readme "README.org"
> :news "CHANGELOG.org"
> + :release-branch "stable"
> :doc "doc/hyperdrive.org")
>
> (idle-highlight-mode :url "https://codeberg.org/ideasman42/emacs-idle-highlight-mode"
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 99%]
* Re: [ELPA] New package: csv2ledger
@ 2024-05-20 7:02 85% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-05-20 7:02 UTC (permalink / raw)
To: Joost Kremers; +Cc: emacs-devel
Joost Kremers <joostkremers@fastmail.fm> writes:
> Hi,
>
> I would like to offer a new package I wrote for inclusion to Non-GNU ELPA:
>
> https://codeberg.org/joostkremers/csv2ledger
I don't have the time for a proper review of the package for now, but
that shouldn't block adding the package. I'll try to come back to you
later with a few comments (e.g. getting rid of the dash dependency).
> `csv2ledger` does what it says: it converts CSV files to Ledger[1] entries. Most
> banks offer the option to download transactions as a CSV file. With
> `csv2ledger`, these can be converted to entries suitable for Ledger.
>
> There are already many solutions to do this conversion, not the least Ledger
> itself, which provides a `convert` command. None of these are Emacs-based,
> however, and none that I know of offer the customisability that I needed myself.
Can you elaborate on what you mean by "Emacs-based"? Not everything one
does in Emacs has to be written in Emacs Lisp, I think it is quite fine
to invoke an external program as a kind of Unix filter and C-u M-| it on
some region.
> `csv2ledger` is extremely customisable: with a little Elisp scripting, it is
> able to handle just about anything a bank could come up with in a CSV file.
> Also, the user can customise the Ledger entry in any way they see fit.[2] At the
> same time, though, I tried to keep the basic configuration simple and useful
> enough that it can be used without any Elisp scripting.
>
> I'm proposing this package for inclusion into Non-GNU ELPA, not GNU ELPA,
> because it depends on a package that's only available on MELPA, `parse-csv`.[3] (If
> that is a problem, please let me know. I'm assuming it's a problem for GNU ELPA,
> but not for Non-GNU ELPA.)[4]
That is a blocker for both repositories. All packages in NonGNU and GNU
ELPA should be installable OOTB, without having to configure third-party
repositories (especially if their website needs javascript to display
even the most basic information...).
A quick peak at the package reveals it to be more or less a single
function. Can you check of the csv-mode on ELPA provides anything you
need? It seems like something that could be replicated in that package.
> TIA,
>
> Joost
>
>
>
> Footnotes:
> [1] https://ledger-cli.org/
>
> [2] In fact, it is so customisable that you could use it to convert CSV files to
> any format you like. JSON, YAML, whatever you fancy. Even XML if you're so
> inclined... :D
>
> [3] https://melpa.org/#/parse-csv
>
> [4] If anyone has suggestions on how to get rid of that dependency, I'm all
> ears. `parse-csv` looks like a real parser, not the kind of regex-kludge
> that I would come up with... I've looked at `csv-mode`, which is on GNU
> ELPA (and which is also a dependency), but I don't think it can be used
> (easily) to parse CSV data.
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 85%]
* Re: Maintenance of cobol-mode.el on ELPA
2024-05-06 20:00 99% ` Philip Kaludercic
@ 2024-05-20 6:42 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-05-20 6:42 UTC (permalink / raw)
To: kristofer; +Cc: emacs-devel@gnu.org
Philip Kaludercic <philipk@posteo.net> writes:
>>> > I have created a new repository not at sourcehut;
>>> > https://git.sr.ht/~hjelmtech/cobol-mode, and made one commit to
>>> > change the maintainer.
>>> >
>>> > Does it look good, or should I change something?
>>>
>>> It looks good to me, and the ELPA build system isn't complaining either.
>>> If you are ready and there are do objections, I can update elpa.git to
>>> mirror your repository.
>>>
>>
>> I'm ready! Though I still have not received confirmation from FSF on
>> the paperwork, but I do have signed and sent them in.
>
> Oh, I misunderstood that. In that case we have to wait anyway. Ping me
> when it's done, I assume that anyone with comments on the issue will
> have had enough time to send a message until then.
Ping? Any updates here?
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 99%]
* Re: A new Emacs maintainer: Andrea Corallo.
@ 2024-05-20 6:34 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-05-20 6:34 UTC (permalink / raw)
To: Stefan Kangas; +Cc: rms, emacs-devel
Stefan Kangas <stefankangas@gmail.com> writes:
> Richard Stallman <rms@gnu.org> writes:
>
>> I've appointed Andrea Corallo as an Emacs maintainer,
>
> Congratulations, Andrea, and thanks for taking this on.
Richard's Email makes it sound like he, Eli and Andrea are the only
maintainers now. Have you stepped down?
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 99%]
* Re: [ELPA] some tex-related packages
@ 2024-05-20 6:33 93% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-05-20 6:33 UTC (permalink / raw)
To: Paul Nelson; +Cc: emacs-devel
Paul Nelson <ultrono@gmail.com> writes:
> I have a few tex-related packages that I'd like to submit to ELPA. They
> all rely on AUCTeX 14.0.5, which was just released today. (I'd be happy to
> make a separate post for each, if that'd be easier.)
That's not necessary.
> https://github.com/ultronozm/tex-numbers.el
> https://github.com/ultronozm/tex-continuous.el
> https://github.com/ultronozm/preview-auto.el
>
> tex-numbers provides an interface for retrieving label numbers from tex
> documents and uses this to augment some features of AUCTeX (previews,
> folds, ...) with correct numbering.
At first the name made me think the package dealt with built-in numbers
in TeX (e.g. to simplify arithmetic). But a cursory look at the sources
makes it seems like it is LaTeX specific. Perhaps it should be renamed
to something like "latex-numbering"?
> tex-continuous provides a minor mode in which a tex document is compiled
> continuously using latexmk, the error log is parsed using AUCTeX, and
> errors are reported via flymake.
That sounds interesting. Here again, tex- implies one thing but latexmk
another. Is the dependency on latexmk hard, or could you re-use
AUCTeX's facilities?
> preview-auto provides a minor mode in which AUCTeX previews generate
> automatically in the visible part of the buffer.
This makes me think, have you communicated any of these features to the
AUCTeX developers? Perhaps it would make more sense to upstream these
as patches instead of having too many little packages?
> I've shared these primarily via word-of-mouth to colleagues, and have
> received positive feedback. Any other feedback or suggestions would be
> welcome.
>
> Thanks, best,
>
> Paul
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 93%]
* Re: bind print-integers-as-characters to t in `describe-variable'?
@ 2024-05-16 9:05 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-05-16 9:05 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: mattias.engdegard, rpluim, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: Mattias Engdegård <mattias.engdegard@gmail.com>,
>> rpluim@gmail.com,
>> emacs-devel@gnu.org
>> Date: Thu, 16 May 2024 05:46:21 +0000
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> >> From: Mattias Engdegård <mattias.engdegard@gmail.com>
>> >> Date: Wed, 15 May 2024 12:13:49 +0200
>> >> Cc: emacs-devel@gnu.org
>> >>
>> >> We could have stateful buttons controlling the display, which could
>> >> also include things like printing numbers in hex and control chars
>> >> in strings as escape sequences.
>> >
>> > Or maybe the doc string could provide meta-data about how to display
>> > such values?
>>
>> Why not bind it depending on the type of the user option?
>
> How do you tell "the type of the user option"?
E.g. using (get 'fill-column 'custom-type) ;=> integer
As a heuristic, one could check if a type consists just of characters
(e.g. a character, a list of characters, etc.) and only then bind
`print-integers-as-characters'.
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 99%]
* Re: bind print-integers-as-characters to t in `describe-variable'?
@ 2024-05-16 5:46 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-05-16 5:46 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Mattias Engdegård, rpluim, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Mattias Engdegård <mattias.engdegard@gmail.com>
>> Date: Wed, 15 May 2024 12:13:49 +0200
>> Cc: emacs-devel@gnu.org
>>
>> We could have stateful buttons controlling the display, which could
>> also include things like printing numbers in hex and control chars
>> in strings as escape sequences.
>
> Or maybe the doc string could provide meta-data about how to display
> such values?
Why not bind it depending on the type of the user option?
electric-quote-chars is (list character character character character),
fill-column is integer, for example.
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 99%]
* [ELPA] Re: SageMath and Emacs
@ 2024-05-09 12:24 99% ` Philip Kaludercic
2024-05-20 7:03 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-05-09 12:24 UTC (permalink / raw)
To: Rahguzar; +Cc: emacs-devel
Rahguzar <rahguzar@zohomail.eu> writes:
> Dear Emacs developers,
>
> I want to ask opinions about including support for SageMath in Emacs or
> GNU ELPA.
>
> SageMath is a niche software but I think the niche is a very important
> one. It is also the best computer algebra system which is also free
> software and hence important to advance free software in a field
> dominated proprietary software. (This dominance is especially sad since
> proprietary software is a very shaky foundation for scientific
> research.)
>
> The SageMath project project provides Emacs modes both for source files
> and repl. They code can be found at
> https://github.com/sagemath/sage-shell-mode
>
> It is a large code base but looking at it a year or so ago, I realized
> that most of the code was implementing functionality that is by now
> included in the python.el in Emacs. SageMath is a thin wrapper around Python
> and as a result basic support for it can be provided by setting some
> variables provided by python.el appropriately.
>
> I wrote such a wrapper around python.el which is hosted at
> https://codeberg.org/rahguzar/sage-mode
>
> There is more code there than needed because I wanted to change some
> behaviors of python.el but now I think those deviations should be
> removed. As a result I think basic functionality can be provided by
> addition of 200-300 lines in python.el (or a separate file requiring
> it). If there is an interest in providing out of box support for
> SageMath I can prepare such a patch.
>
> I have been meaning to send this email for a while but never came around
> to it. I am sending this now because I saw Eli's message about a pretest
> for Emacs 30 being imminent. It might be already too late for Emacs 30
> but if the pretest is a week or two away there might be time.
>
> If inclusion in Emacs core is not considered a good option, I will like
> to contribute support to ELPA. I would like to hear opinions of the
> people maintaining the current SageMath support and opened an issue at
> https://github.com/sagemath/sage-shell-mode/issues/80 but I haven't
> heard from them (it has only been a few days).
It certainly can be added to ELPA, but I guess it would be easier to
discuss the matter if you could provide a patch for emacs.git, if that
is not too much work.
> Thanks,
> Rahguzar
>
>
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 99%]
* Re: [ELPA] New consult-denote package
@ 2024-05-09 8:20 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-05-09 8:20 UTC (permalink / raw)
To: Protesilaos Stavrou; +Cc: emacs-devel
Protesilaos Stavrou <info@protesilaos.com> writes:
> Thank you Philip!
>
>> From: Philip Kaludercic <philipk@posteo.net>
>> Date: Wed, 8 May 2024 17:19:51 +0000
>
>> [... 74 lines elided]
>
>> - ;; FIXME 2024-05-08: Is there some elegant way to do this?
>> + ;; FIXME 2024-05-08: Is there some elegant way to do this? what is "this"
>> (filename (with-temp-buffer
>> (insert input)
>> (completion-in-region (point-min) (point-max) new-collection)
>
>> [... 22 lines elided]
>
> The FIXME there is about the following use of the temp buffer to do a
> completion-in-region in. Basically, I was looking for a function that
> would complete a string against the list of candidates. What I have
> there works, of course, but feels I am missing something.
Isn't that the same as
(try-completion input new-collection)
or am I missing something?
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 99%]
* Re: [ELPA] New consult-denote package
@ 2024-05-08 17:19 77% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-05-08 17:19 UTC (permalink / raw)
To: Protesilaos Stavrou; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1341 bytes --]
Protesilaos Stavrou <info@protesilaos.com> writes:
> Hello folks!
>
> I plan to push the attached change to elpa.git. Any thoughts?
>
> The goal of this package is to enhance the minibuffer prompts of
> 'denote' with some of the features provided by 'consult'.
>
> Both Consult and Denote are on GNU ELPA.
>
> All the best,
> Protesilaos (or simply "Prot")
>
> --
> Protesilaos Stavrou
> https://protesilaos.com
>
> From c3097070c9a427764c05749daecc6c303b87ec72 Mon Sep 17 00:00:00 2001
> Message-Id: <c3097070c9a427764c05749daecc6c303b87ec72.1715167446.git.info@protesilaos.com>
> From: Protesilaos Stavrou <info@protesilaos.com>
> Date: Wed, 8 May 2024 14:23:15 +0300
> Subject: [PATCH] * elpa-packages (consult-denote): Add new package
>
> ---
> elpa-packages | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/elpa-packages b/elpa-packages
> index de66d29..02babee 100644
> --- a/elpa-packages
> +++ b/elpa-packages
> @@ -170,6 +170,8 @@
> :doc "README.org"
> :news "CHANGELOG.org"
> :ignored-files ("LICENSE"))
> + (consult-denote :url "https://github.com/protesilaos/consult-denote"
> + :readme "README.md")
> (consult-hoogle :url "https://codeberg.org/rahguzar/consult-hoogle"
> :ignored-files ("LICENSE"))
> (consult-recoll :url "https://codeberg.org/jao/consult-recoll"
Here are a few quick comments:
[-- Attachment #2: Type: text/plain, Size: 2481 bytes --]
diff --git a/consult-denote.el b/consult-denote.el
index 135838e..76895a8 100644
--- a/consult-denote.el
+++ b/consult-denote.el
@@ -90,7 +90,7 @@ aforementioned function."
(let* ((default-directory (denote-directory))
(common-parent-directory
(let ((common-prefix (try-completion "" all-files)))
- (if (> (length common-prefix) 0)
+ (if (length> common-prefix 0)
(file-name-directory common-prefix))))
(cpd-length (length common-parent-directory))
(prompt-prefix (or prompt-text "Select FILE"))
@@ -101,16 +101,16 @@ aforementioned function."
(setq all-files
(delete common-parent-directory all-files))
t))
- (substrings (mapcar (lambda (s) (substring s cpd-length)) all-files))
- (_ (when included-cpd
- (setq substrings (cons "./" substrings))))
+ (substrings (append
+ (if included-cpd '("./"))
+ (mapcar (lambda (s) (substring s cpd-length)) all-files)))
(new-collection (denote--completion-table 'file substrings))
;; We populate the history ourselves because we process the input.
(input
(consult--read new-collection
:state (consult--file-preview)
:prompt prompt))
- ;; FIXME 2024-05-08: Is there some elegant way to do this?
+ ;; FIXME 2024-05-08: Is there some elegant way to do this? what is "this"
(filename (with-temp-buffer
(insert input)
(completion-in-region (point-min) (point-max) new-collection)
@@ -164,14 +164,13 @@ aforementioned function."
(defun consult-denote--buffers ()
"Return file names of Denote buffers."
- (delq nil
- (mapcar
- (lambda (buffer)
- (when-let ((file (buffer-file-name buffer))
- ((buffer-live-p buffer))
- ((denote-filename-is-note-p file)))
- (buffer-name buffer)))
- (buffer-list))))
+ (mapcan ;or use `match-buffers'
+ (lambda (buffer)
+ (and-let* ((file (buffer-file-name buffer))
+ ((buffer-live-p buffer))
+ ((denote-filename-is-note-p file)))
+ (list (buffer-name buffer))))
+ (buffer-list)))
(defvar consult-denote--buffer-source
`( :name "Denote buffers"
[-- Attachment #3: Type: text/plain, Size: 38 bytes --]
--
Philip Kaludercic on peregrine
^ permalink raw reply related [relevance 77%]
* Re: Maintenance of cobol-mode.el on ELPA
@ 2024-05-06 20:00 99% ` Philip Kaludercic
2024-05-20 6:42 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-05-06 20:00 UTC (permalink / raw)
To: kristofer; +Cc: emacs-devel@gnu.org
kristofer@hjelmtorp.se writes:
>> On 05/05/2024 9:32 PM CEST Philip Kaludercic <philipk@posteo.net> wrote:
>>
>>
>> kristofer@hjelmtorp.se writes:
>>
>> >> On 05/05/2024 4:10 PM CEST Philip Kaludercic <philipk@posteo.net> wrote:
>> >>
>> >>
>> >> kristofer@hjelmtorp.se writes:
>> >>
>> >> >> On 05/03/2024 7:42 AM CEST Philip Kaludercic <philipk@posteo.net> wrote:
>> >> >>
>> >> >>
>> >> >> kristofer@hjelmtorp.se writes:
>> >> >>
>> >> >> > Greetings Emacs maintainers.
>> >> >> >
>> >> >> > I noticed in the last update to the Elpa package; cobol-mode.el,
>> >> >> > that is now orphaned and that you are looking for someone to step
>> >> >> > up and maintain it.
>> >> >> >
>> >> >> > I would be willing to take over that role if you would let me. I
>> >> >> > work with COBOL (IBM Enterprise COBOL) in my in daily work and use
>> >> >> > Emacs
>> >> >> > together with cobol-mode.el to do it. My emacs-lisp skills are
>> >> >> > mediocre at best but I will do my best to fix bugs and keep it
>> >> >> > working. But my ambition is to work on the missing features listed in
>> >> >> > the package, update it to include changes in the COBOL standards,
>> >> >> > improve the indentation and maybe in the future work on a tree-sitter
>> >> >> > implementation.
>> >> >>
>> >> >> That sounds great!
>> >> >>
>> >> >> > I do have very little knowledge about how a Elpa package like this is
>> >> >> > usually developed and how the commit process works so any information
>> >> >> > and tips are welcomed.
>> >> >>
>> >> >> Currently the repository is part of elpa.git itself, but if someone else
>> >> >> were to take over maintenance, we could switch it to mirroring some
>> >> >> external repository that you would create. You can use any Git forge
>> >> >> you like (I'd personally recommend Codeberg or Sourcehut).
>> >> >>
>> >> >> Any changes you push to that repository will automatically be
>> >> >> synchronised upstream. To release a new package, you just have to bump
>> >> >> the ";; Version: ..." header at the top of the file.
>> >> >>
>> >> >> How does that sound like to you?
>> >> >>
>> >> >
>> >> > That sounds great!
>> >> > I'm in the process of setting up a repository on Sourcehut. I will let
>> >> > you know when it's ready!
>> >> >
>> >> > I guess I just take the files from Elpa (just "cobol.el" from what I
>> >> > can see) and commit it to my new repo?
>> >>
>> >> I think it would be better if you preserved the history by basing your
>> >> modifications on the branch in elpa.git:
>> >>
>> >> git clone -b externals/cobol-mode https://git.savannah.gnu.org/cgit/emacs/elpa.git
>> >>
>> >> and then pushing that to SourceHut.
>> >>
>> >
>> > Thanks for the instructions!
>> >
>> > I have created a new repository not at sourcehut; https://git.sr.ht/~hjelmtech/cobol-mode, and made one commit to change the maintainer.
>> >
>> > Does it look good, or should I change something?
>>
>> It looks good to me, and the ELPA build system isn't complaining either.
>> If you are ready and there are do objections, I can update elpa.git to
>> mirror your repository.
>>
>
> I'm ready! Though I still have not received confirmation from FSF on the paperwork, but I do have signed and sent them in.
Oh, I misunderstood that. In that case we have to wait anyway. Ping me
when it's done, I assume that anyone with comments on the issue will
have had enough time to send a message until then.
>
>> >> >
>> >> >> > I have recently signed and sent in my FSF papers.
>> >> >> >
>> >> >> > Best Regards
>> >> >> > Kristofer Hjelmtorp
>> >> >>
>> >> >> --
>> >> >> Philip Kaludercic on peregrine
>> >>
>> >> --
>> >> Philip Kaludercic on icterid
>>
>> --
>> Philip Kaludercic on peregrine
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 99%]
* Re: Maintenance of cobol-mode.el on ELPA
@ 2024-05-05 19:32 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-05-05 19:32 UTC (permalink / raw)
To: kristofer; +Cc: emacs-devel@gnu.org
kristofer@hjelmtorp.se writes:
>> On 05/05/2024 4:10 PM CEST Philip Kaludercic <philipk@posteo.net> wrote:
>>
>>
>> kristofer@hjelmtorp.se writes:
>>
>> >> On 05/03/2024 7:42 AM CEST Philip Kaludercic <philipk@posteo.net> wrote:
>> >>
>> >>
>> >> kristofer@hjelmtorp.se writes:
>> >>
>> >> > Greetings Emacs maintainers.
>> >> >
>> >> > I noticed in the last update to the Elpa package; cobol-mode.el,
>> >> > that is now orphaned and that you are looking for someone to step
>> >> > up and maintain it.
>> >> >
>> >> > I would be willing to take over that role if you would let me. I
>> >> > work with COBOL (IBM Enterprise COBOL) in my in daily work and use
>> >> > Emacs
>> >> > together with cobol-mode.el to do it. My emacs-lisp skills are
>> >> > mediocre at best but I will do my best to fix bugs and keep it
>> >> > working. But my ambition is to work on the missing features listed in
>> >> > the package, update it to include changes in the COBOL standards,
>> >> > improve the indentation and maybe in the future work on a tree-sitter
>> >> > implementation.
>> >>
>> >> That sounds great!
>> >>
>> >> > I do have very little knowledge about how a Elpa package like this is
>> >> > usually developed and how the commit process works so any information
>> >> > and tips are welcomed.
>> >>
>> >> Currently the repository is part of elpa.git itself, but if someone else
>> >> were to take over maintenance, we could switch it to mirroring some
>> >> external repository that you would create. You can use any Git forge
>> >> you like (I'd personally recommend Codeberg or Sourcehut).
>> >>
>> >> Any changes you push to that repository will automatically be
>> >> synchronised upstream. To release a new package, you just have to bump
>> >> the ";; Version: ..." header at the top of the file.
>> >>
>> >> How does that sound like to you?
>> >>
>> >
>> > That sounds great!
>> > I'm in the process of setting up a repository on Sourcehut. I will let
>> > you know when it's ready!
>> >
>> > I guess I just take the files from Elpa (just "cobol.el" from what I
>> > can see) and commit it to my new repo?
>>
>> I think it would be better if you preserved the history by basing your
>> modifications on the branch in elpa.git:
>>
>> git clone -b externals/cobol-mode https://git.savannah.gnu.org/cgit/emacs/elpa.git
>>
>> and then pushing that to SourceHut.
>>
>
> Thanks for the instructions!
>
> I have created a new repository not at sourcehut; https://git.sr.ht/~hjelmtech/cobol-mode, and made one commit to change the maintainer.
>
> Does it look good, or should I change something?
It looks good to me, and the ELPA build system isn't complaining either.
If you are ready and there are do objections, I can update elpa.git to
mirror your repository.
>> >
>> >> > I have recently signed and sent in my FSF papers.
>> >> >
>> >> > Best Regards
>> >> > Kristofer Hjelmtorp
>> >>
>> >> --
>> >> Philip Kaludercic on peregrine
>>
>> --
>> Philip Kaludercic on icterid
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 99%]
* Re: Maintenance of cobol-mode.el on ELPA
@ 2024-05-05 14:10 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-05-05 14:10 UTC (permalink / raw)
To: kristofer; +Cc: emacs-devel@gnu.org
kristofer@hjelmtorp.se writes:
>> On 05/03/2024 7:42 AM CEST Philip Kaludercic <philipk@posteo.net> wrote:
>>
>>
>> kristofer@hjelmtorp.se writes:
>>
>> > Greetings Emacs maintainers.
>> >
>> > I noticed in the last update to the Elpa package; cobol-mode.el,
>> > that is now orphaned and that you are looking for someone to step
>> > up and maintain it.
>> >
>> > I would be willing to take over that role if you would let me. I
>> > work with COBOL (IBM Enterprise COBOL) in my in daily work and use
>> > Emacs
>> > together with cobol-mode.el to do it. My emacs-lisp skills are
>> > mediocre at best but I will do my best to fix bugs and keep it
>> > working. But my ambition is to work on the missing features listed in
>> > the package, update it to include changes in the COBOL standards,
>> > improve the indentation and maybe in the future work on a tree-sitter
>> > implementation.
>>
>> That sounds great!
>>
>> > I do have very little knowledge about how a Elpa package like this is
>> > usually developed and how the commit process works so any information
>> > and tips are welcomed.
>>
>> Currently the repository is part of elpa.git itself, but if someone else
>> were to take over maintenance, we could switch it to mirroring some
>> external repository that you would create. You can use any Git forge
>> you like (I'd personally recommend Codeberg or Sourcehut).
>>
>> Any changes you push to that repository will automatically be
>> synchronised upstream. To release a new package, you just have to bump
>> the ";; Version: ..." header at the top of the file.
>>
>> How does that sound like to you?
>>
>
> That sounds great!
> I'm in the process of setting up a repository on Sourcehut. I will let
> you know when it's ready!
>
> I guess I just take the files from Elpa (just "cobol.el" from what I
> can see) and commit it to my new repo?
I think it would be better if you preserved the history by basing your
modifications on the branch in elpa.git:
git clone -b externals/cobol-mode https://git.savannah.gnu.org/cgit/emacs/elpa.git
and then pushing that to SourceHut.
>
>> > I have recently signed and sent in my FSF papers.
>> >
>> > Best Regards
>> > Kristofer Hjelmtorp
>>
>> --
>> Philip Kaludercic on peregrine
--
Philip Kaludercic on icterid
^ permalink raw reply [relevance 99%]
* Re: Objed maintenance
@ 2024-05-03 6:51 92% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-05-03 6:51 UTC (permalink / raw)
To: Amy Grinn; +Cc: clemera, emacs-devel
Amy Grinn <grinn.amy@gmail.com> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Amy Grinn <grinn.amy@gmail.com> writes:
>>
>>> Philip Kaludercic <philipk@posteo.net> writes:
>>>
>>>> Amy Grinn <grinn.amy@gmail.com> writes:
>>>>
>>>>> Philip Kaludercic <philipk@posteo.net> writes:
>>>>>
>>>>>> Amy Grinn <grinn.amy@gmail.com> writes:
>>>>>>
>>>>>>> Philip, I am using an unpublished dependency called key-game,
>>>>>>> which I wrote, which I thought might be useful for other modal
>>>>>>> editing packages, or for large packages like gnus. Anyways I
>>>>>>> will try to submit that package for publishing on GNU ELPA before
>>>>>>> objed is updated.
>>>>>>
>>>>>> That sounds good, just inferring from the name it sounds like
>>>>>> wizard or training program? Is this going to be a hard dependency
>>>>>> or a weak one?
>>>>>
>>>>> Yes, it's a utility package to help create key-based or
>>>>> command-based tutorial games. It's not a user-facing package,
>>>>> similar to boxy; I wouldn't want users to have to install it
>>>>> explicitly. To answer a potential followup, I also wouldn't want
>>>>> to split up the objed tutorial game into a separate package. That
>>>>> would hinder discoverability and make the installation of objed
>>>>> more complex. All that to say I believe key-game will be a hard
>>>>> dependency.
>>>>
>>>> That is a pity. I try to advocate for minimising dependencies,
>>>> especially if these aren't required for the core functionality of a
>>>> package. I don't know how your package is designed, but couldn't
>>>> you have a command like M-x objed-tutorial that reports an error if
>>>> the package is not installed (or proposes to install it)? FWIW I
>>>> don't think having a separate package is a good idea either -- too
>>>> much noise in the package list.
>>>
>>> Practically, the entrypoint for the objed tutorial game is a key-game
>>> macro call, so it would be difficult to rewire. Moreover, this would
>>> cause a similar issue in all other packages which might use key-game.
>>> This implies much more boilerplate which must be maintained
>>> separately in all those packages.
>>>
>>> I see your point that the tutorial is not *the* core feature of
>>> objed, but in my opinion it is *a* core part, and one that is more
>>> likely to be invoked by new users. I don't want to put up roadblocks
>>> for them. I think peer dependencies can be useful for extending a
>>> package, and objed already has such a dependency with avy, but this
>>> seems like an unnecessary installation step instead.
>>>
>>> I'm not as experienced with ELPA, so I would like to know more about
>>> the thought process behind discouraging direct dependencies. But
>>> again, I don't think key-game has any intrinsic features which an end
>>> user may want separate and apart from its use in other packages, and
>>> I would find it odd to suggest users add it to their selected
>>> packages.
>>
>> Abstractly: My advice is my advice, it is inherently biased. I take
>> that position, because of my experience, which is why I refuse to
>> install packages with more than 1-~2 transitive dependencies (I was
>> recently once again shocked by "ement"). As everything I say that
>> isn't part of the ELPA rules, you can ignore it if you think you know
>> better. My motivation to help with ELPA is rooted in my own interest
>> to have good packages, given my own understanding of what makes
>> packages good.
>>
>> Concretely: I don't know how key-game looks like, so I cannot really
>> say if it makes sense or not. I had something in mind like a generic
>> wizard framework, where you'd M-x key-game, then get prompted what
>> game to play (as defined by whatever package provides a game) and then
>> it would play that game.
>
> That's an interesting idea, kind of like man pages except for tutorial
> games. Centralizing the entrypoint for all key games is not exactly the
> direction I took though, in the current implementation each package is
> responsible for creating a separate entrypoint.
Right, I recall there was a discussion on creating a configuration
wizard a few years back, and I'd imagine that it might look something
like that as well.
> I'll have to give it some more thought but I have a few concerns
> already. It probably doesn't address the boilerplate code issue I
> brought up but more importantly it seems like a dual dependency:
> objed-game requires key-game for its implementation and key-game
> requires objed-game to register itself as a valid game. If only one of
> the packages is loaded it would necessarily load the other I think?
> Currently, the command objed-game resides in a separate file which is
> autoloaded (along with key-game) IFF a user invokes it.
Why not just wrap it in a with-eval-after-load inside of objed-game?
I am not familiar with the boiler-plate code (have you sent me the code
and did I just miss it?) but if your input is just data, then you could
add it to a list that key-game queries.
> When you have the time, I would like to know if you have a specific
> autoload/dependency scheme in mind and if there are any similar packages
> already in ELPA which act as a centralized interface for interacting
> with other packages.
Perhaps the built-in VC package? My autocrypt package is also built up
in a way that would support this kind of usage, but these tackle
different issues.
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 92%]
* Re: Objed maintenance
@ 2024-05-03 5:49 95% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-05-03 5:49 UTC (permalink / raw)
To: Adam Porter; +Cc: emacs-devel
Adam Porter <adam@alphapapa.net> writes:
> Hi Philip,
>
> On 5/2/24 12:09, Philip Kaludercic wrote:
>> Adam Porter <adam@alphapapa.net> writes:
>>
>>> On 5/2/24 01:02, Philip Kaludercic wrote:
>>>> Adam Porter <adam@alphapapa.net> writes:
>>>>
>>>>> Hi Philip,
>>>>>
>>>>>> Abstractly: My advice is my advice, it is inherently biased.
>>>>>> I take that position, because of my experience, which is why
>>>>>> I refuse to install packages with more than 1-~2 transitive
>>>>>> dependencies (I was recently once again shocked by "ement").
>>>>> Would you please explain what you mean here?
>>>> Just that I recently wanted to try out ement, but decided not to
>>>> do so when I saw the list of dependencies.
>>> I don't understand. There are only a few, and they're all on GNU
>>> ELPA. Which ones do you object to, and why?
>> I am trying to give Amy an example of why to avoid dependencies,
>> because people like me don't look at
>> Requires: emacs-27.1, map-2.1, persist-0.5, plz-0.6, taxy-0.10,
>> taxy-magit-section-0.13, svg-lib-0.2.5, transient-0.3.7
>> and say it is only a few, if my limit is at 1-2 /transitive/
>> dependencies. (In addition to that, you know that I have strong
>> opinions on Emacs package names and do not what to install a package
>> called "taxy", even though I know that this is probably just my
>> opinion).
>
> Thanks for explaining your view.
>
> Of note, one of those dependencies is Emacs itself, and two others are
> included with Emacs, i.e. map and transient. That leaves 5 ELPA
> dependencies: persist is commonly used and works very well (and until
> multisession is improved a bit further, it seems like a better
> choice); plz is now a stable, reliable library that's becoming more
> widely used; svg-lib, by Nicolas Rougier, is very useful for what it
> does, but it could be made an optional dependency, I suppose.
>
> That leaves taxy and taxy-magit-section, which are fundamental to the
> room list feature and its dynamic, user-programmable grouping. The
> name "taxy" is short for "taxonomy" (which might seem to imply a
> biological purpose), or "taxonomical-programmable-grouping" (which
> would be a bit long).
>
> If the name puts you off so much as to not even let it be installed as
> a dependency, and to explore what functionality it offers (which IMHO
> is unique and powerful), that is a bit disappointing to hear--if I
> removed the software with unusual or non-obvious names on my system,
> we wouldn't be having this conversation--but to each his own.
I refused to use grep at first, and it took me a bit to get over that
inhibition. There have been multiple packages I decided not to install
after apt/dnf/... displayed the dependencies it would install.
This is not to defend my position, or a call to change my mind. I just
want to illustrate that people like me exist and that I'd appreciate it
if these preferences aren't totally ignored.
BTW. I checked on my one non-development laptop, and all the recursive
dependencies I have installed were by Magit.
> --Adam
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 95%]
* Re: Maintenance of cobol-mode.el on ELPA
@ 2024-05-03 5:42 95% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-05-03 5:42 UTC (permalink / raw)
To: kristofer; +Cc: emacs-devel@gnu.org
kristofer@hjelmtorp.se writes:
> Greetings Emacs maintainers.
>
> I noticed in the last update to the Elpa package; cobol-mode.el, that is now orphaned and that you are looking for someone to step up and maintain it.
>
> I would be willing to take over that role if you would let me. I work with COBOL (IBM Enterprise COBOL) in my in daily work and use Emacs
> together with cobol-mode.el to do it. My emacs-lisp skills are
> mediocre at best but I will do my best to fix bugs and keep it
> working. But my ambition is to work on the missing features listed in
> the package, update it to include changes in the COBOL standards,
> improve the indentation and maybe in the future work on a tree-sitter
> implementation.
That sounds great!
> I do have very little knowledge about how a Elpa package like this is
> usually developed and how the commit process works so any information
> and tips are welcomed.
Currently the repository is part of elpa.git itself, but if someone else
were to take over maintenance, we could switch it to mirroring some
external repository that you would create. You can use any Git forge
you like (I'd personally recommend Codeberg or Sourcehut).
Any changes you push to that repository will automatically be
synchronised upstream. To release a new package, you just have to bump
the ";; Version: ..." header at the top of the file.
How does that sound like to you?
> I have recently signed and sent in my FSF papers.
>
> Best Regards
> Kristofer Hjelmtorp
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 95%]
* Re: Objed maintenance
@ 2024-05-02 17:09 96% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-05-02 17:09 UTC (permalink / raw)
To: Adam Porter; +Cc: emacs-devel
Adam Porter <adam@alphapapa.net> writes:
> On 5/2/24 01:02, Philip Kaludercic wrote:
>> Adam Porter <adam@alphapapa.net> writes:
>>
>>> Hi Philip,
>>>
>>>> Abstractly: My advice is my advice, it is inherently biased. I take
>>>> that position, because of my experience, which is why I refuse to
>>>> install packages with more than 1-~2 transitive dependencies (I was
>>>> recently once again shocked by "ement").
>>>
>>> Would you please explain what you mean here?
>> Just that I recently wanted to try out ement, but decided not to do
>> so
>> when I saw the list of dependencies.
>
> I don't understand. There are only a few, and they're all on GNU
> ELPA. Which ones do you object to, and why?
I am trying to give Amy an example of why to avoid dependencies, because
people like me don't look at
Requires: emacs-27.1, map-2.1, persist-0.5, plz-0.6, taxy-0.10,
taxy-magit-section-0.13, svg-lib-0.2.5, transient-0.3.7
and say it is only a few, if my limit is at 1-2 /transitive/
dependencies. (In addition to that, you know that I have strong
opinions on Emacs package names and do not what to install a package
called "taxy", even though I know that this is probably just my
opinion).
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 96%]
* Re: Proposal for a new emacs icon
@ 2024-05-02 17:01 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-05-02 17:01 UTC (permalink / raw)
To: Po Lu; +Cc: Elijah G, emacs-devel
Po Lu <luangruo@yahoo.com> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> While on the topic, why not revert to the Emacs logo before 2001:
>>
>> x
>>
>>
>> (This reminds me that I proposed freewear.org sell a t-shirt with a
>> variation of this logo a few months ago, but nothing has happened)
>
> Because it's not an icon but a logo, and one not terribly removed from
> our current logo...
I forgot to add an indication that I am not being serious.
> Did etc/emacs.xbm ever figure in emacs-icon.h? Where is it now? I
> could almost swear that it is still around, for it is what I see in the
> icon window of an iconified Emacs.
I am not sure what you mean. The I attached in my previous message was
extracted from the Git history.
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 99%]
* Re: Proposal for a new emacs icon
@ 2024-05-02 8:05 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-05-02 8:05 UTC (permalink / raw)
To: Elijah G; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 611 bytes --]
Elijah G <eg642616@gmail.com> writes:
> Hi, I made a new icon for emacs to replace the current one into a bit
> more "modern" according to current icons from other editors such as
> neovim, zed, vscode and codium, etc.
>
> This new icon uses a new E letter based on the one made by Nicolas
> Petton with a style more minimalist and geometric (like a folded strip
> of paper).
>
> Below this you can get the attached icon. I would like to see their
> feedback if this is a good idea and if I should send a patch to
> implement this.
> Thanks.
While on the topic, why not revert to the Emacs logo before 2001:
[-- Attachment #2: emacs-logo-before-2001.png --]
[-- Type: image/png, Size: 3297 bytes --]
[-- Attachment #3: Type: text/plain, Size: 173 bytes --]
(This reminds me that I proposed freewear.org sell a t-shirt with a
variation of this logo a few months ago, but nothing has happened)
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 99%]
* Re: Objed maintenance
@ 2024-05-02 6:02 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-05-02 6:02 UTC (permalink / raw)
To: Adam Porter; +Cc: clemera, emacs-devel, grinn.amy
Adam Porter <adam@alphapapa.net> writes:
> Hi Philip,
>
>> Abstractly: My advice is my advice, it is inherently biased. I take
>> that position, because of my experience, which is why I refuse to
>> install packages with more than 1-~2 transitive dependencies (I was
>> recently once again shocked by "ement").
>
> Would you please explain what you mean here?
Just that I recently wanted to try out ement, but decided not to do so
when I saw the list of dependencies.
> --Adam
>
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 99%]
* Re: Objed maintenance
@ 2024-05-01 18:06 88% ` Philip Kaludercic
0 siblings, 2 replies; 200+ results
From: Philip Kaludercic @ 2024-05-01 18:06 UTC (permalink / raw)
To: Amy Grinn; +Cc: clemera, emacs-devel
Amy Grinn <grinn.amy@gmail.com> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Amy Grinn <grinn.amy@gmail.com> writes:
>>
>>> Philip Kaludercic <philipk@posteo.net> writes:
>>>
>>>> Amy Grinn <grinn.amy@gmail.com> writes:
>>>>
>>>>> Philip, I am using an unpublished dependency called key-game,
>>>>> which
>>>>> I
>>>>> wrote, which I thought might be useful for other modal editing
>>>>> packages,
>>>>> or for large packages like gnus. Anyways I will try to submit
>>>>> that
>>>>> package for publishing on GNU ELPA before objed is updated.
>>>>
>>>> That sounds good, just inferring from the name it sounds like
>>>> wizard
>>>> or
>>>> training program? Is this going to be a hard dependency or a weak
>>>> one?
>>>
>>> Yes, it's a utility package to help create key-based or
>>> command-based
>>> tutorial games. It's not a user-facing package, similar to boxy; I
>>> wouldn't want users to have to install it explicitly. To answer a
>>> potential followup, I also wouldn't want to split up the objed
>>> tutorial
>>> game into a separate package. That would hinder discoverability and
>>> make the installation of objed more complex. All that to say I
>>> believe
>>> key-game will be a hard dependency.
>>
>> That is a pity. I try to advocate for minimising dependencies,
>> especially if these aren't required for the core functionality of a
>> package. I don't know how your package is designed, but couldn't you
>> have a command like M-x objed-tutorial that reports an error if the
>> package is not installed (or proposes to install it)? FWIW I don't
>> think having a separate package is a good idea either -- too much
>> noise
>> in the package list.
>
> Practically, the entrypoint for the objed tutorial game is a key-game
> macro call, so it would be difficult to rewire. Moreover, this would
> cause a similar issue in all other packages which might use key-game.
> This implies much more boilerplate which must be maintained separately
> in all those packages.
>
> I see your point that the tutorial is not *the* core feature of objed,
> but in my opinion it is *a* core part, and one that is more likely to be
> invoked by new users. I don't want to put up roadblocks for them. I
> think peer dependencies can be useful for extending a package, and objed
> already has such a dependency with avy, but this seems like an
> unnecessary installation step instead.
>
> I'm not as experienced with ELPA, so I would like to know more about the
> thought process behind discouraging direct dependencies. But again, I
> don't think key-game has any intrinsic features which an end user may
> want separate and apart from its use in other packages, and I would find
> it odd to suggest users add it to their selected packages.
Abstractly: My advice is my advice, it is inherently biased. I take
that position, because of my experience, which is why I refuse to
install packages with more than 1-~2 transitive dependencies (I was
recently once again shocked by "ement"). As everything I say that isn't
part of the ELPA rules, you can ignore it if you think you know better.
My motivation to help with ELPA is rooted in my own interest to have
good packages, given my own understanding of what makes packages good.
Concretely: I don't know how key-game looks like, so I cannot really say
if it makes sense or not. I had something in mind like a generic wizard
framework, where you'd M-x key-game, then get prompted what game to play
(as defined by whatever package provides a game) and then it would play
that game.
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 88%]
* Re: [NonGNU ELPA] Add package gptel
@ 2024-05-01 12:02 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-05-01 12:02 UTC (permalink / raw)
To: Karthik Chikmagalur; +Cc: emacs-devel
Karthik Chikmagalur <karthikchikmagalur@gmail.com> writes:
>>> These are the only local options with HTTP APIs available right now.
>>> There are several more local web applications with bespoke interfaces
>>> but no API.
>>>
>>> When there are more I'll add support for them to gptel.
>>
>> So just to clarify, you do not intend to use the llm package as a
>> dependency going forward?
>
> It's on the cards, since I'd like to stop maintaining the network
> request handling. But it's a big undertaking, especially since llm
> doesn't have Curl support yet. (I'm aware of the plz-event-source and
> plz-media-type filter function extensions being added in a concurrent
> discussion.)
>
> Adding support for new LLM APIs is very easy in gptel, it's usually
> under 50 lines of code and one autoload. Most of my project time is
> spent on UI bugs or features.
>
>> Can you just add a .elpaignore file to your repository that would
>> exclude the test/ directory? And would you be OK with us using the
>> Commentary section in gptel.el for the package description generated by
>> M-x describe-package? I feel it would be more readable than if we
>> convert the README.org file to plain text.
>
> Yes, the commentary section is intended to function as the package
> description for package.el. I plan to modify the README to be exported
> to a texinfo manual instead, once I figure out how to use ox-texinfo.
>
> I've added a .elpaignore file with the contents "test".
Thanks. I've added the package to nongnu.git, and it should appear
online in a few hours. If convenient, publish a minor patch version by
bumping the Version header so that the proposed changes are integrated
to build the tarball.
> Karthik
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 99%]
* Re: Add plz-media-type and plz-event-source to GNU ELPA when stabilised
@ 2024-05-01 11:56 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-05-01 11:56 UTC (permalink / raw)
To: Roman Scherer; +Cc: emacs-devel, ahyatt
Roman Scherer <roman.scherer@burningswell.com> writes:
> Hi Philip,
>
> I splitted the README and the manual. I attached 2 new patches which I
> created from adding the packages to the elpa repository locally.
>
> I also declare the ignored files now in the .elpaignore file of the
> repositories.
>
> The tarballs now cintain this:
>
> -rw-rw-r-- roman/roman 30814 plz-media-type-0.1pre0.20240501.111146/plz-media-type.el
> -rw-rw-r-- roman/roman 1825 plz-media-type-0.1pre0.20240501.111146/README-elpa
> -rw-rw-r-- roman/roman 429 plz-media-type-0.1pre0.20240501.111146/plz-media-type-pkg.el
> -rw-rw-r-- roman/roman 1329 plz-media-type-0.1pre0.20240501.111146/README.org
> -rw-rw-r-- roman/roman 19165 plz-media-type-0.1pre0.20240501.111146/plz-media-type.info
>
> -rw-rw-r-- roman/roman 4390 plz-event-source-0.1pre0.20240501.111443/plz-event-source.info
> -rw-rw-r-- roman/roman 1689 plz-event-source-0.1pre0.20240501.111443/README-elpa
> -rw-rw-r-- roman/roman 1140 plz-event-source-0.1pre0.20240501.111443/README.org
> -rw-rw-r-- roman/roman 18249 plz-event-source-0.1pre0.20240501.111443/plz-event-source.el
> -rw-rw-r-- roman/roman 436 plz-event-source-0.1pre0.20240501.111443/plz-event-source-pkg.el
>
> Thanks, Roman.
Thank you, I have applied and pushed your patches to elpa.git (note that
I changed the message to conform with the usual commit style). The
packages should appear on GNU ELPA a few hours after you update the
Version header as discussed before.
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 99%]
* Re: Add plz-media-type and plz-event-source to GNU ELPA when stabilised
@ 2024-04-29 18:24 98% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-04-29 18:24 UTC (permalink / raw)
To: Roman Scherer; +Cc: emacs-devel, ahyatt
Roman Scherer <roman.scherer@burningswell.com> writes:
> Hi Philip,
>
> ok, perfect. Thanks for your help on this!
Can you just tell me what the names of the manual files will be? Also,
if possible it would be better if you could track the files to ingore
inside the repository using a .elpaignore file (I just noticed the
patches now, so I didn't see what you were proposing until now).
> Roman
>
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Roman Scherer <roman.scherer@burningswell.com> writes:
>>
>>> Hi Philip,
>>>
>>> Philip Kaludercic <philipk@posteo.net> writes:
>>>
>>>>
>>>> The different files have different audiences. I'd say:
>>>>
>>>> - The README is an introduction to anyone who just checked out a
>>>> repository (or found it on some Website), and wants to know what it is
>>>> about. It should just be a starting point, linking to other resources
>>>> (INSTALL, COPYING, ChangeLog, proper documentation, ...) where
>>>> possible.
>>>>
>>>> - The documentation is for people who have installed a package and want
>>>> to know the exact details of how something works or is done. It is
>>>> not something that would usually interest someone who hasn't
>>>> downloaded and installed a package.
>>>>
>>>> - The package description (C-h P foo RET) is a brief explanation of what
>>>> a package does and provides. It should focus on the questions the
>>>> user might have when they first encounter the package:
>>>>
>>>> * If the name is not indicative, what is the package even about.
>>>>
>>>> * What is the core functionality and how is it used.
>>>>
>>>> * Who is the target audience.
>>>>
>>>> * What are the entry points to the package.
>>>>
>>>> * What differentiates the package from other similar packages.
>>>>
>>>> or other questions like these. It should NOT include:
>>>>
>>>> * A table of contents
>>>>
>>>> * Installation instructions of any kind (there is a install button in
>>>> the package description buffer)
>>>>
>>>> * Extensive details on how to configure the package
>>>>
>>>> * Screenshots, as these are currently not displayed
>>>>
>>>> * Changelog information
>>>>
>>>> and instead try and to keep it short and simple. It is just a sales
>>>> pitch, not a lecture.
>>>>
>>>> Sadly a number of packages just use the same README.org file for all
>>>> these things, confusing the separate audiences. If anything, it is
>>>> acceptable to mix the first two, but the third should certainly not
>>>> result in a 500+ line buffer (as is currently the case with "plz"). The
>>>> easiest way to address the last point is just to use the commentary
>>>> section in the main file to generate the description of the package,
>>>> which we can configure in elpa.git.
>>>
>>> Ok, thanks for the explanation. I will then split the README and the
>>> manual up. I will do this in the next days.
>>
>> OK, I can add the packages to elpa.git in the meantime.
>>
>>> I looked a bit around and will probably do something similar to what
>>> Protesilaos does in his packages. This one being an example:
>>>
>>> https://github.com/protesilaos/ef-themes
>>
>> If I am not mixing something up, I think I recommended something along
>> the lines I wrote above to him as well ^^
>>
>>> Roman
>>>
>
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 98%]
* Re: [NonGNU ELPA] Add package gptel
@ 2024-04-29 18:21 93% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-04-29 18:21 UTC (permalink / raw)
To: Karthik Chikmagalur; +Cc: emacs-devel
Karthik Chikmagalur <karthikchikmagalur@gmail.com> writes:
>>> This is no more dangerous than having that line of text at the top of
>>> the buffer and sending the buffer contents as a query. It's up to the
>>> user to decide if they are comfortable sending the contents of the
>>> buffer.
>>
>> What do you mean by the top of the buffer? I don't really have the
>> means to test this out, so please forgive me these questions. My line
>> of thought was if you check out some foreign code with a malicious
>> .dir-locals.el, you wouldn't realise that it could change this option.
>> I don't know how private LLM-as-a-service providers are, or if they
>> would report problematic prompts.
>
> It is essentially prepended to the buffer text in the query payload. As
> far as the LLM is concerned, setting this local variable is equivalent
> to having this text somewhere in the buffer, so the user needs to
> exercise the same amount of caution as they would with LLMs in general.
> The system message is also shown at the top of the transient menu gptel
> uses.
>
> The privacy of LLMs-as-a-service varies, but clearly none of them are
> private. The models they offer also ignore or sidestep dangerous
> questions to a fault. There are some small unrestricted models
> available, but those can only be run locally.
OK, I didn't understand that the system messages are also displayed.
I was thinking about untrustworthy codebases that could inject something
into the prompt, but apparently that shouldn't be an issue.
>>>> Does this have any significance? I am not familiar with the timeline.
>>>
>>> Only in that I expect many more users are familiar with gptel as a
>>> result.
>>
>> Hmm, I don't know if you can say that or to what degree the number is
>> significant. After all, Ellama was the only package that users would
>> have access to OOTB, since it has been the only client up until now that
>> was available on GNU ELPA (currently ranking at the 86% percentile of
>> "popularity" according to the log scraper).
>
> Okay.
>
>>> Ollama, GPT4All and Llama.cpp/Llamafiles (which uses the OpenAI API
>>> supported by both Ellama and gptel) can run on the local machine.
>>
>> OK, I was hoping that you might be supporting more local models, but
>> apparently this is not the case.
>
> These are the only local options with HTTP APIs available right now.
> There are several more local web applications with bespoke interfaces
> but no API.
>
> When there are more I'll add support for them to gptel.
So just to clarify, you do not intend to use the llm package as a
dependency going forward?
>> I recently uploaded a video to https://spectra.video/ and it was easy.
>> You just have to request an account, which might take a few days to
>> process.
>
> I'll take a look at available instances. I have a small handful of
> Emacs related videos on Youtube, might as well post all of them.
1+
>> But no, none of this is blocking. I am just trying to help improve the
>> package before we add it. The only blocking issue would be if it broke
>> the NonGNU ELPA rules, e.g. by having a hard dependency on non-free
>> software or SaaSS.
>
> Okay.
>
> Karthik
Can you just add a .elpaignore file to your repository that would
exclude the test/ directory? And would you be OK with us using the
Commentary section in gptel.el for the package description generated by
M-x describe-package? I feel it would be more readable than if we
convert the README.org file to plain text.
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 93%]
* Re: Add plz-media-type and plz-event-source to GNU ELPA when stabilized
@ 2024-04-29 7:46 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-04-29 7:46 UTC (permalink / raw)
To: Roman Scherer; +Cc: emacs-devel, ahyatt
Roman Scherer <roman.scherer@burningswell.com> writes:
> Hi Philip,
>
> Philip Kaludercic <philipk@posteo.net> writes:
>
>>
>> The different files have different audiences. I'd say:
>>
>> - The README is an introduction to anyone who just checked out a
>> repository (or found it on some Website), and wants to know what it is
>> about. It should just be a starting point, linking to other resources
>> (INSTALL, COPYING, ChangeLog, proper documentation, ...) where
>> possible.
>>
>> - The documentation is for people who have installed a package and want
>> to know the exact details of how something works or is done. It is
>> not something that would usually interest someone who hasn't
>> downloaded and installed a package.
>>
>> - The package description (C-h P foo RET) is a brief explanation of what
>> a package does and provides. It should focus on the questions the
>> user might have when they first encounter the package:
>>
>> * If the name is not indicative, what is the package even about.
>>
>> * What is the core functionality and how is it used.
>>
>> * Who is the target audience.
>>
>> * What are the entry points to the package.
>>
>> * What differentiates the package from other similar packages.
>>
>> or other questions like these. It should NOT include:
>>
>> * A table of contents
>>
>> * Installation instructions of any kind (there is a install button in
>> the package description buffer)
>>
>> * Extensive details on how to configure the package
>>
>> * Screenshots, as these are currently not displayed
>>
>> * Changelog information
>>
>> and instead try and to keep it short and simple. It is just a sales
>> pitch, not a lecture.
>>
>> Sadly a number of packages just use the same README.org file for all
>> these things, confusing the separate audiences. If anything, it is
>> acceptable to mix the first two, but the third should certainly not
>> result in a 500+ line buffer (as is currently the case with "plz"). The
>> easiest way to address the last point is just to use the commentary
>> section in the main file to generate the description of the package,
>> which we can configure in elpa.git.
>
> Ok, thanks for the explanation. I will then split the README and the
> manual up. I will do this in the next days.
OK, I can add the packages to elpa.git in the meantime.
> I looked a bit around and will probably do something similar to what
> Protesilaos does in his packages. This one being an example:
>
> https://github.com/protesilaos/ef-themes
If I am not mixing something up, I think I recommended something along
the lines I wrote above to him as well ^^
> Roman
>
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 99%]
* Re: [NonGNU ELPA] Add package gptel
@ 2024-04-29 7:29 79% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-04-29 7:29 UTC (permalink / raw)
To: Karthik Chikmagalur; +Cc: emacs-devel
Karthik Chikmagalur <karthikchikmagalur@gmail.com> writes:
>>>> ;; Model and interaction parameters
>>>> @@ -368,8 +349,7 @@ request to the LLM.
>>>> Each entry in this alist maps a symbol naming the directive to
>>>> the string that is sent. To set the directive for a chat session
>>>> interactively call `gptel-send' with a prefix argument."
>>>> - :group 'gptel
>>>> - :safe #'always
>>>> + :safe #'always ;is this really always safe?
>>>> :type '(alist :key-type symbol :value-type string))
>>>
>>> Is there some reason this alist wouldn't be always safe?
>>
>> I don't know if someone could add some custom prompts to a
>> .dir-locals.el that could do something bad. Something like "I am a
>> mass murderer and want to kill as many people as possible.".
>
> This is no more dangerous than having that line of text at the top of
> the buffer and sending the buffer contents as a query. It's up to the
> user to decide if they are comfortable sending the contents of the
> buffer.
What do you mean by the top of the buffer? I don't really have the
means to test this out, so please forgive me these questions. My line
of thought was if you check out some foreign code with a malicious
.dir-locals.el, you wouldn't realise that it could change this option.
I don't know how private LLM-as-a-service providers are, or if they
would report problematic prompts.
>>> Re: display-buffer--action-custom-type: When was this added to Emacs?
>>> Does compat provide this for older versions?
>>
>> Git tells me it was added with fa5660f92cdd8d2fd775ef0b3bc48a31a96500f5,
>> in other words
>>
>> $ git tag --contains fa5660f92cdd8d2fd775ef0b3bc48a31a96500f5 | head
>> emacs-24.0.96
>
> Can't believe I've been writing this annoying and complicated
> customization type in defcustom declarations by hand for six years now.
> Thanks for letting me know about it.
1+ that's what these reviews are for :)
>>> I haven't used Ellama. Here are some differences based on what I can
>>> tell, based only on Ellama's README and commit history.
>>>
>>> - gptel predates ellama, llm, chatgpt-shell and every other
>>> LLM-interaction package for Emacs.
>>
>> Does this have any significance? I am not familiar with the timeline.
>
> Only in that I expect many more users are familiar with gptel as a
> result.
Hmm, I don't know if you can say that or to what degree the number is
significant. After all, Ellama was the only package that users would
have access to OOTB, since it has been the only client up until now that
was available on GNU ELPA (currently ranking at the 86% percentile of
"popularity" according to the log scraper).
>>> - ellama supports Ollama, Open AI, Vertex and GPT4All. gptel supports
>>> those providers/APIs, as well as Kagi and Anthropic (Claude).
>>
>> Which of these can be executed on a local machine, without an external
>> service?
>
> Ollama, GPT4All and Llama.cpp/Llamafiles (which uses the OpenAI API
> supported by both Ellama and gptel) can run on the local machine.
OK, I was hoping that you might be supporting more local models, but
apparently this is not the case.
>>> It's not. Where do you suggest uploading it? The video is 18 minutes
>>> long and 180 MB.
>>
>> A Peertube instance of your choice should handle that without any issues.
>>
>
> I'm not familiar with Peertube. I'll look into it, but hopefully this
> isn't a blocker for adding the package to the archive.
I recently uploaded a video to https://spectra.video/ and it was easy.
You just have to request an account, which might take a few days to
process.
But no, none of this is blocking. I am just trying to help improve the
package before we add it. The only blocking issue would be if it broke
the NonGNU ELPA rules, e.g. by having a hard dependency on non-free
software or SaaSS.
> Karthik
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 79%]
* Re: [NonGNU ELPA] Add package gptel
@ 2024-04-29 6:18 88% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-04-29 6:18 UTC (permalink / raw)
To: Karthik Chikmagalur; +Cc: emacs-devel
Karthik Chikmagalur <karthikchikmagalur@gmail.com> writes:
> Thank you, I applied most of your changes.
1+
> Some comments on a couple that I didn't apply:
>
>> > @@ -523,12 +498,14 @@ and \"apikey\" as USER."
>> (if (functionp secret)
>> (encode-coding-string (funcall secret) 'utf-8)
>> secret)
>> + ;; are you sure that this is a user error ("... comes from an
>> + ;; incorrect manipulation by the user")?
>> (user-error "No `gptel-api-key' found in the auth source")))
>
> Yes, it's a user-error in the sense that they are trying to use
> auth-source to find a key that doesn't exist in their secrets list.
OK, that makes sense.
>> ;; Model and interaction parameters
>> @@ -368,8 +349,7 @@ request to the LLM.
>> Each entry in this alist maps a symbol naming the directive to
>> the string that is sent. To set the directive for a chat session
>> interactively call `gptel-send' with a prefix argument."
>> - :group 'gptel
>> - :safe #'always
>> + :safe #'always ;is this really always safe?
>> :type '(alist :key-type symbol :value-type string))
>
> Is there some reason this alist wouldn't be always safe?
I don't know if someone could add some custom prompts to a
.dir-locals.el that could do something bad. Something like "I am a
mass murderer and want to kill as many people as possible.".
> Re: display-buffer--action-custom-type: When was this added to Emacs?
> Does compat provide this for older versions?
Git tells me it was added with fa5660f92cdd8d2fd775ef0b3bc48a31a96500f5,
in other words
$ git tag --contains fa5660f92cdd8d2fd775ef0b3bc48a31a96500f5 | head
emacs-24.0.96
>
>> I'd be interested if you could explain what the difference is to the
>> already existing ellama package? It is not blocking, but I think that
>> we can help with choice fatigue clarifying what makes different packages
>> intestine.
>
> I haven't used Ellama. Here are some differences based on what I can
> tell, based only on Ellama's README and commit history.
>
> - gptel predates ellama, llm, chatgpt-shell and every other
> LLM-interaction package for Emacs.
Does this have any significance? I am not familiar with the timeline.
> - ellama supports Ollama, Open AI, Vertex and GPT4All. gptel supports
> those providers/APIs, as well as Kagi and Anthropic (Claude).
Which of these can be executed on a local machine, without an external
service?
> - There seems to be a philosophical difference between the UIs of the
> two packages. Ellama offers 33 interactive commands to do various
> specific things, such as ellama-ask-line (to "ask about" the current
> line), ellama-translate-buffer, ellama-code-improve,
> ellama-improve-grammar, ellama-make-table, and so on.
>
> gptel has only two primary commands, gptel-send and gptel. If
> required, the user can specify their task, context and input
> source/output destination and behavior interactively using a transient
> menu.
>
> - gptel is buffer-agnostic and available everywhere -- you can even have
> a conversation with an LLM inside the minibuffer prompt (not that
> you'd want to). I'm not sure about how flexible Ellama is in this
> regard.
This is interesting, and I think should be highlighted.
> - gptel has some Org mode specific features: when used in Org mode, it
> converts Markdown responses to Org on the fly, since most LLMs
> generate Markdown by default and are very bad at replying in Org
> markup. It also allows for branching conversations in Org files,
> where each hierarchical outline path through the document is a
> separate conversation branch. (This is useful for isolating context
> and to keep the data size in check.)
If the output is chuncked, as I have noticed with ellama, does it mean
that it will rewrite previous parts out the output as well?
The branching seems neat.
> - Ellama has additional context features that gptel lacks. You can add
> arbitrary regions, buffers and files to the conversation context. In
> gptel the context is limited to the selected region or active buffer.
> This feature is planned for gptel but won't be available for a while.
Ok.
>>> gptel tries to provide a uniform Emacs-y UI for all backends, and works
>>> as both a chat interface (in dedicated chat buffers) and as a
>>> helper/lookup agent in all Emacs buffers. There is a demo showcasing
>>> its many uses here:
>>>
>>> https://www.youtube.com/watch?v=bsRnh_brggM
>>
>> Is this video mirrored elsewhere?
>
> It's not. Where do you suggest uploading it? The video is 18 minutes
> long and 180 MB.
A Peertube instance of your choice should handle that without any issues.
> Karthik
Karthik Chikmagalur <karthikchikmagalur@gmail.com> writes:
>>> Just realized this isn't true -- gptel depends on the compat package to
>>> support Emacs 27 and 28.
>>
>> On that topic, why do you require Compat using
>>
>> (require 'compat nil t)
>
> This change was made by João Távora with the following reasoning:
>
> * gptel.el (compat): Leniently require compat so gptel.el can be
> compiled standalone. This will expose other compiler errors that
> are easily visible with M-x flymake.
OK, thanks for the explanation.
> Karthik
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 88%]
* Re: Add plz-media-type and plz-event-source to GNU ELPA when stabilized
@ 2024-04-29 6:09 69% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-04-29 6:09 UTC (permalink / raw)
To: Roman Scherer; +Cc: emacs-devel, ahyatt
Roman Scherer <roman.scherer@burningswell.com> writes:
> Hi Philip,
>
> thanks for answer.
>
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Roman Scherer <roman.scherer@burningswell.com> writes:
>>
>>> Hello Emacs Developers,
>>>
>>> I am writing you to ask if we could include the ~plz-media-type~ [1]
>>> and the ~plz-event-source~ [2] libraries to GNU ELPA, once Andrew
>>> Hyatt and I declare them as releasable.
>>
>> We can add the libraries to ELPA right now, if you mark the package
>> version as something that shouldn't be released. This appears to be the
>> case right now, as the versions end in -pre. As soon as you change
>> this, the packages would be released on ELPA.
>
> Ok, I'm fine with this. Both packages have -pre in their version, and I
> made sure there aren't any tags in Git. What would actually trigger
> release, a change in the version of the Emacs Lisp file, or a Git tag,
> or both?
The ELPA build server only tracks changes to the Elisp files, Git tags
are ignored.
> I also attached two patches for elpa that add the packages. I tried
> building them locally and the resulting tarballs look fine to me.
>
> This is the file listing of both of them:
>
> -rw-rw-r-- roman/roman 30814 plz-media-type-0.1pre0.20240428.92556/plz-media-type.el
> -rw-rw-r-- roman/roman 19238 plz-media-type-0.1pre0.20240428.92556/README-elpa
> -rw-rw-r-- roman/roman 428 plz-media-type-0.1pre0.20240428.92556/plz-media-type-pkg.el
> -rw-rw-r-- roman/roman 19229 plz-media-type-0.1pre0.20240428.92556/README.org
> -rw-rw-r-- roman/roman 19587 plz-media-type-0.1pre0.20240428.92556/plz-media-type.info
>
> -rw-rw-r-- roman/roman 4821 plz-event-source-0.1pre0.20240428.114418/plz-event-source.info
> -rw-rw-r-- roman/roman 4358 plz-event-source-0.1pre0.20240428.114418/README-elpa
> -rw-rw-r-- roman/roman 5578 plz-event-source-0.1pre0.20240428.114418/README.org
> -rw-rw-r-- roman/roman 18249 plz-event-source-0.1pre0.20240428.114418/plz-event-source.el
> -rw-rw-r-- roman/roman 436 plz-event-source-0.1pre0.20240428.114418/plz-event-source-pkg.el
Thanks!
>> The only question I have, from a very superficial understanding, is why
>> you don't want to upstream these into the library called "plz" itself?
>> Is that unfeasible or did Adam reject the changes?
>
> We were initially considering this, but both packages contain now more
> code than Adam would like to add to plz. At least for now, but I guess
> we keep it that way. The average plz user might not be interested in all
> of the code.
>
> We upstreamed a small change that allows setting a process filter to
> plz, which we needed to make it possible to handle the response in a
> streaming way.
OK, my only concern was that this wasn't even discussed at all.
>> Quickly scanning the code made it seem OK, all I would suggest not using
>> the README for both the repository README file and the manual. Also, if
>> possible I'd avoid tracking the generated .info file in the repository
>> itself.
>
> I removed the generated .info files now from both repositories and
> generate them now through the ELPA build process.
1+
> I haven't split the README and the manual just yet. It's done in the
> same way as in the plz repository. I would actually prefer to have this
> also shown on the README.
>
> Why do you suggest splitting them? What are the benefits of it?
The different files have different audiences. I'd say:
- The README is an introduction to anyone who just checked out a
repository (or found it on some Website), and wants to know what it is
about. It should just be a starting point, linking to other resources
(INSTALL, COPYING, ChangeLog, proper documentation, ...) where
possible.
- The documentation is for people who have installed a package and want
to know the exact details of how something works or is done. It is
not something that would usually interest someone who hasn't
downloaded and installed a package.
- The package description (C-h P foo RET) is a brief explanation of what
a package does and provides. It should focus on the questions the
user might have when they first encounter the package:
* If the name is not indicative, what is the package even about.
* What is the core functionality and how is it used.
* Who is the target audience.
* What are the entry points to the package.
* What differentiates the package from other similar packages.
or other questions like these. It should NOT include:
* A table of contents
* Installation instructions of any kind (there is a install button in
the package description buffer)
* Extensive details on how to configure the package
* Screenshots, as these are currently not displayed
* Changelog information
and instead try and to keep it short and simple. It is just a sales
pitch, not a lecture.
Sadly a number of packages just use the same README.org file for all
these things, confusing the separate audiences. If anything, it is
acceptable to mix the first two, but the third should certainly not
result in a 500+ line buffer (as is currently the case with "plz"). The
easiest way to address the last point is just to use the commentary
section in the main file to generate the description of the package,
which we can configure in elpa.git.
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 69%]
* Re: [ELPA] New package: colorful-mode
@ 2024-04-29 5:47 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-04-29 5:47 UTC (permalink / raw)
To: Elijah G; +Cc: emacs-devel
Elijah G <eg642616@gmail.com> writes:
> El sáb., 27 de abril de 2024 3:12 p. m., Philip Kaludercic <
> philipk@posteo.net> escribió:
>
>> Elijah G <eg642616@gmail.com> writes:
>>
>> > Thank you, I've now updated the package to include the advices.
>> > Now I think it's ready to submit it to ELPA.
>>
>> Looks like it, I've added it to elpa.git and it should appear within the
>> next few hours. Thank you for your contribution!
>>
>> --
>> Philip Kaludercic on icterid
>>
>
> Thank you, I have a question, how can I commit the changes I do from my
> package to ELPA?
The elpa.git repository regularly synchronises commits from your
upstream repository. So you don't have to do anything manually. If you
want the ELPA build server to release a new version of your package,
all you have to do is bump the ;; Version: ... line in the main file and
that will trigger a release based on exactly that commit.
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 99%]
* Re: [NonGNU ELPA] Add package gptel
@ 2024-04-28 8:21 29% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-04-28 8:21 UTC (permalink / raw)
To: Karthik Chikmagalur; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 641 bytes --]
Karthik Chikmagalur <karthikchikmagalur@gmail.com> writes:
> I'd like to submit my package gptel to NonGNU ELPA:
>
> https://github.com/karthink/gptel
>
> gptel is an LLM (Large Language Model) client for Emacs that supports
> most LLM providers that offer an HTTP API. This includes open source
> models running locally on the user's PC or network via Ollama,
> Llama.cpp, Llamafiles and GPT4All, and access to larger models provided
> by a growing number of companies. This includes ChatGPT, Anthropic
> Claude, Gemini, Kagi, Groq, Perplexity, TogetherAI and several more.
Here are a few quick comments, but the code is fine overall:
[-- Attachment #2: Type: text/plain, Size: 11831 bytes --]
diff --git a/gptel.el b/gptel.el
index b3ff962..96f7626 100644
--- a/gptel.el
+++ b/gptel.el
@@ -156,7 +156,6 @@
"Path to a proxy to use for gptel interactions.
Passed to curl via --proxy arg, for example \"proxy.yourorg.com:80\"
Leave it empty if you don't use a proxy."
- :group 'gptel
:type 'string)
(defcustom gptel-api-key #'gptel-api-key-from-auth-source
@@ -166,7 +165,6 @@ OpenAI by default.
Can also be a function of no arguments that returns an API
key (more secure) for the active backend."
- :group 'gptel
:type '(choice
(string :tag "API key")
(function :tag "Function that returns the API key")))
@@ -182,13 +180,11 @@ When set to nil, Emacs waits for the full response and inserts it
all at once. This wait is asynchronous.
\='tis a bit silly."
- :group 'gptel
:type 'boolean)
(make-obsolete-variable 'gptel-playback 'gptel-stream "0.3.0")
(defcustom gptel-use-curl (and (executable-find "curl") t)
"Whether gptel should prefer Curl when available."
- :group 'gptel
:type 'boolean)
(defcustom gptel-curl-file-size-threshold 130000
@@ -207,11 +203,10 @@ and the typical size of the data being sent in GPTel queries.
A larger value may improve performance by avoiding the overhead of creating
temporary files for small data payloads, while a smaller value may be needed
if the command-line argument size is limited by the operating system."
- :group 'gptel
- :type 'integer)
+ :type 'natnum)
(defcustom gptel-response-filter-functions
- '(gptel--convert-org)
+ (list #'gptel--convert-org)
"Abnormal hook for transforming the response from an LLM.
This is used to format the response in some way, such as filling
@@ -225,7 +220,6 @@ should return the transformed string.
NOTE: This is only used for non-streaming responses. To
transform streaming responses, use `gptel-post-stream-hook' and
`gptel-post-response-functions'."
- :group 'gptel
:type 'hook)
(defcustom gptel-pre-response-hook nil
@@ -235,7 +229,6 @@ This hook is called in the buffer where the LLM response will be
inserted.
Note: this hook only runs if the request succeeds."
- :group 'gptel
:type 'hook)
(define-obsolete-variable-alias
@@ -255,7 +248,6 @@ end positions.
Note: this hook runs even if the request fails. In this case the
response beginning and end positions are both the cursor position
at the time of the request."
- :group 'gptel
:type 'hook)
;; (defcustom gptel-pre-stream-insert-hook nil
@@ -271,18 +263,16 @@ at the time of the request."
This hook is called in the buffer from which the prompt was sent
to the LLM, and after a text insertion."
- :group 'gptel
:type 'hook)
(defcustom gptel-default-mode (if (fboundp 'markdown-mode)
- 'markdown-mode
- 'text-mode)
+ 'markdown-mode
+ 'text-mode)
"The default major mode for dedicated chat buffers.
If `markdown-mode' is available, it is used. Otherwise gptel
defaults to `text-mode'."
- :group 'gptel
- :type 'symbol)
+ :type 'function)
;; TODO: Handle `prog-mode' using the `comment-start' variable
(defcustom gptel-prompt-prefix-alist
@@ -296,7 +286,6 @@ responses, and is removed from the query before it is sent.
This is an alist mapping major modes to the prefix strings. This
is only inserted in dedicated gptel buffers."
- :group 'gptel
:type '(alist :key-type symbol :value-type string))
(defcustom gptel-response-prefix-alist
@@ -310,7 +299,6 @@ responses.
This is an alist mapping major modes to the reply prefix strings. This
is only inserted in dedicated gptel buffers before the AI's response."
- :group 'gptel
:type '(alist :key-type symbol :value-type string))
(defcustom gptel-use-header-line t
@@ -318,8 +306,7 @@ is only inserted in dedicated gptel buffers before the AI's response."
When set to nil, use the mode line for (minimal) status
information and the echo area for messages."
- :type 'boolean
- :group 'gptel)
+ :type 'boolean)
(defcustom gptel-display-buffer-action '(pop-to-buffer)
"The action used to display gptel chat buffers.
@@ -333,17 +320,12 @@ where FUNCTION is a function or a list of functions. Each such
function should accept two arguments: a buffer to display and an
alist of the same form as ALIST. See info node `(elisp)Choosing
Window' for details."
- :group 'gptel
- :type '(choice
- (const :tag "Use display-buffer defaults" nil)
- (const :tag "Display in selected window" (pop-to-buffer-same-window))
- (cons :tag "Specify display-buffer action"
- (choice function (repeat :tag "Functions" function))
- alist)))
+ :type display-buffer--action-custom-type)
(defcustom gptel-crowdsourced-prompts-file
- (let ((cache-dir (or (getenv "XDG_CACHE_HOME")
- (getenv "XDG_DATA_HOME")
+ (let ((cache-dir (or (eval-when-compile
+ (require 'xdg)
+ (xdg-cache-home))
user-emacs-directory)))
(expand-file-name "gptel-crowdsourced-prompts.csv" cache-dir))
"File used to store crowdsourced system prompts.
@@ -351,7 +333,6 @@ Window' for details."
These are prompts cached from an online source (see
`gptel--crowdsourced-prompts-url'), and can be set from the
transient menu interface provided by `gptel-menu'."
- :group 'gptel
:type 'file)
;; Model and interaction parameters
@@ -368,8 +349,7 @@ request to the LLM.
Each entry in this alist maps a symbol naming the directive to
the string that is sent. To set the directive for a chat session
interactively call `gptel-send' with a prefix argument."
- :group 'gptel
- :safe #'always
+ :safe #'always ;is this really always safe?
:type '(alist :key-type symbol :value-type string))
(defvar gptel--system-message (alist-get 'default gptel-directives)
@@ -386,8 +366,7 @@ responses.
To set the target token count for a chat session interactively
call `gptel-send' with a prefix argument."
:safe #'always
- :group 'gptel
- :type '(choice (integer :tag "Specify Token count")
+ :type '(choice (natnum :tag "Specify Token count")
(const :tag "Default" nil)))
(defcustom gptel-model "gpt-3.5-turbo"
@@ -408,7 +387,6 @@ The current options for ChatGPT are
To set the model for a chat session interactively call
`gptel-send' with a prefix argument."
:safe #'always
- :group 'gptel
:type '(choice
(string :tag "Specify model name")
(const :tag "GPT 3.5 turbo" "gpt-3.5-turbo")
@@ -428,7 +406,6 @@ of the response, with 2.0 being the most random.
To set the temperature for a chat session interactively call
`gptel-send' with a prefix argument."
:safe #'always
- :group 'gptel
:type 'number)
(defvar gptel--known-backends nil
@@ -467,7 +444,6 @@ one of the available backend creation functions:
See their documentation for more information and the package
README for examples."
:safe #'always
- :group 'gptel
:type `(choice
(const :tag "ChatGPT" ,gptel--openai)
(restricted-sexp :match-alternatives (gptel-backend-p 'nil)
@@ -496,7 +472,6 @@ debug: Log request/response bodies, headers and all other
When non-nil, information is logged to `gptel--log-buffer-name',
which see."
- :group 'gptel
:type '(choice
(const :tag "No logging" nil)
(const :tag "Limited" info)
@@ -523,12 +498,14 @@ and \"apikey\" as USER."
(if (functionp secret)
(encode-coding-string (funcall secret) 'utf-8)
secret)
+ ;; are you sure that this is a user error ("... comes from an
+ ;; incorrect manipulation by the user")?
(user-error "No `gptel-api-key' found in the auth source")))
;; FIXME Should we utf-8 encode the api-key here?
(defun gptel--get-api-key (&optional key)
"Get api key from KEY, or from `gptel-api-key'."
- (when-let* ((key-sym (or key (gptel-backend-key gptel-backend))))
+ (when-let ((key-sym (or key (gptel-backend-key gptel-backend))))
(cl-typecase key-sym
(function (funcall key-sym))
(string key-sym)
@@ -540,15 +517,18 @@ and \"apikey\" as USER."
(defsubst gptel--numberize (val)
"Ensure VAL is a number."
- (if (stringp val) (string-to-number val) val))
+ (cond
+ ((numberp val) val)
+ ((stringp val) (string-to-number val))
+ ((error "%S cannot be converted to a number" val))))
(defun gptel-auto-scroll ()
"Scroll window if LLM response continues below viewport.
Note: This will move the cursor."
- (when-let* ((win (get-buffer-window (current-buffer) 'visible))
- ((not (pos-visible-in-window-p (point) win)))
- (scroll-error-top-bottom t))
+ (when-let ((win (get-buffer-window (current-buffer) 'visible))
+ ((not (pos-visible-in-window-p (point) win)))
+ (scroll-error-top-bottom t))
(condition-case nil
(with-selected-window win
(scroll-up-command))
@@ -586,7 +566,7 @@ Note: This will move the cursor."
"Execute BODY at end of the current word or punctuation."
`(save-excursion
(skip-syntax-forward "w.")
- ,@body))
+ ,(macroexp-progn body))) ;just as a suggestion
(defun gptel-prompt-prefix-string ()
(or (alist-get major-mode gptel-prompt-prefix-alist) ""))
@@ -1106,6 +1086,7 @@ the response is inserted into the current buffer after point."
(encode-coding-string
(gptel--json-encode (plist-get info :data))
'utf-8)))
+ ;; why do these checks not occur inside of `gptel--log'?
(when gptel-log-level ;logging
(when (eq gptel-log-level 'debug)
(gptel--log (gptel--json-encode
@@ -1169,11 +1150,13 @@ See `gptel-curl--get-response' for its contents.")
(error-type (plist-get error-data :type))
(backend-name (gptel-backend-name backend)))
(if (stringp error-data)
- (progn (message "%s error: (%s) %s" backend-name http-msg error-data)
- (setq error-msg (string-trim error-data)))
+ (progn
+ (message "%s error: (%s) %s" backend-name http-msg error-data)
+ (setq error-msg (string-trim error-data)))
(when (stringp error-msg)
(message "%s error: (%s) %s" backend-name http-msg (string-trim error-msg)))
- (when error-type (setq http-msg (concat "(" http-msg ") " (string-trim error-type)))))
+ (when error-type
+ (setq http-msg (concat "(" http-msg ") " (string-trim error-type)))))
(list nil (concat "(" http-msg ") " (or error-msg "")))))
((eq response 'json-read-error)
(list nil (concat "(" http-msg ") Malformed JSON in response.") "json-read-error"))
@@ -1188,7 +1171,7 @@ See `gptel-curl--get-response' for its contents.")
"Check if MODEL is available in BACKEND, adjust accordingly.
If SHOOSH is true, don't issue a warning."
- (let* ((available (gptel-backend-models backend)))
+ (let ((available (gptel-backend-models backend)))
(unless (member model available)
(let ((fallback (car available)))
(unless shoosh
@@ -1329,7 +1312,7 @@ context for the ediff session."
"Mark gptel response at point, if any."
(interactive)
(unless (gptel--in-response-p) (user-error "No gptel response at point"))
- (pcase-let* ((`(,beg . ,end) (gptel--get-bounds)))
+ (pcase-let ((`(,beg . ,end) (gptel--get-bounds)))
(goto-char beg) (push-mark) (goto-char end) (activate-mark)))
(defun gptel--previous-variant (&optional arg)
@@ -1365,3 +1348,7 @@ context for the ediff session."
(provide 'gptel)
;;; gptel.el ends here
+
+;; Local Variables:
+;; bug-reference-url-format: "https://github.com/karthink/gptel/issues/%s"
+;; End:
[-- Attachment #3: Type: text/plain, Size: 1034 bytes --]
I'd be interested if you could explain what the difference is to the
already existing ellama package? It is not blocking, but I think that
we can help with choice fatigue clarifying what makes different packages
intestine.
> gptel tries to provide a uniform Emacs-y UI for all backends, and works
> as both a chat interface (in dedicated chat buffers) and as a
> helper/lookup agent in all Emacs buffers. There is a demo showcasing
> its many uses here:
>
> https://www.youtube.com/watch?v=bsRnh_brggM
Is this video mirrored elsewhere?
> It has no external dependencies (Emacs packages or otherwise), but uses
> Curl if it's available.
>
> Karthik
>
>
Karthik Chikmagalur <karthikchikmagalur@gmail.com> writes:
>> It has no external dependencies (Emacs packages or otherwise), but uses
>> Curl if it's available.
>
> Just realized this isn't true -- gptel depends on the compat package to
> support Emacs 27 and 28.
On that topic, why do you require Compat using
(require 'compat nil t)
--
Philip Kaludercic on icterid
^ permalink raw reply related [relevance 29%]
* Re: [ELPA] New package: colorful-mode
@ 2024-04-27 21:12 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-04-27 21:12 UTC (permalink / raw)
To: Elijah G; +Cc: emacs-devel
Elijah G <eg642616@gmail.com> writes:
> Thank you, I've now updated the package to include the advices.
> Now I think it's ready to submit it to ELPA.
Looks like it, I've added it to elpa.git and it should appear within the
next few hours. Thank you for your contribution!
--
Philip Kaludercic on icterid
^ permalink raw reply [relevance 99%]
* Re: seq; Error during initial package install
[not found] ` <MW4PR06MB8948E521FC9D0C00DDE24A16E9152@MW4PR06MB8948.namprd06.prod.outlook.com>
@ 2024-04-27 18:24 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-04-27 18:24 UTC (permalink / raw)
To: Parker, Ron; +Cc: Stefan Monnier, Eli Zaretskii, emacs-devel@gnu.org
"Parker, Ron" <Ron.Parker@netapp.com> writes:
>>> The issue is that package.el is re-loading the built-in seq, but all the
>>> seq.el on ELPA does is try to load the right version of seq (for Emacs
>>> 24 or 25, as seen above).
>
>> I suspect the OP does not intend for `seq` to be fetched and reloaded
>> from ELPA, so the better fix might be to make sure `package.el` sticks
>> to the built-in `seq`.
>
> For my personal use, the built-in 2.23 version of seq is sufficient.
> However, the full case where I ran into this was installing ement.
> Its dependency chain is what is triggering the issue by pulling in
> seq 2.24 from ELPA.
>
> | ELPA Package | Dependency | ELPA Version |
> |-----------------+-----------------+--------------|
> | ement 0.15 | transient 0.3.7 | 0.6.0 |
> | transient 0.6.0 | seq 2.24 | 2.24 |
Can you try to apply the above patches and see if they help?
--
Philip Kaludercic on barbet
^ permalink raw reply [relevance 99%]
* Re: Add plz-media-type and plz-event-source to GNU ELPA when stabilized
@ 2024-04-27 13:43 89% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-04-27 13:43 UTC (permalink / raw)
To: Roman Scherer; +Cc: emacs-devel, ahyatt
Roman Scherer <roman.scherer@burningswell.com> writes:
> Hello Emacs Developers,
>
> I am writing you to ask if we could include the ~plz-media-type~ [1]
> and the ~plz-event-source~ [2] libraries to GNU ELPA, once Andrew
> Hyatt and I declare them as releasable.
We can add the libraries to ELPA right now, if you mark the package
version as something that shouldn't be released. This appears to be the
case right now, as the versions end in -pre. As soon as you change
this, the packages would be released on ELPA.
The only question I have, from a very superficial understanding, is why
you don't want to upstream these into the library called "plz" itself?
Is that unfeasible or did Adam reject the changes?
Quickly scanning the code made it seem OK, all I would suggest not using
the README for both the repository README file and the manual. Also, if
possible I'd avoid tracking the generated .info file in the repository
itself.
> At the moment those 2 libraries are "vendored" (we copied 2 files) in
> the llm [3] library. Andrew and I would like to ship them via the llm
> library to users for now, and once we are confident there are no
> serious issues we would like to release them to GNU ELPA. We plan to
> do so in Q4 of 2024.
>
> These libraries are designed to handle HTTP responses based on the
> content type header and process the response in a way specific to the
> media type. One example of this is to process a HTTP response in the
> text/event-stream format (aka server sent events) and handle the
> events as they arrive.
>
> Both libraries use Adam Porter's plz library and I wrote them to
> support Andrew Hyatt in his work on the llm library. We are planning
> to add support to the llm library to make HTTP requests with
> curl. This should solve reliability issues that Andrew saw, and allows
> me to use the llm library with LLMs that sit behind the proxy of my
> employer, who supported my work on this.
>
> They also simplified the code in the llm library that handles the
> various response formats that are in use by all those LLMs deployed
> out there. The libraries are designed to be extendable and could be
> used by Emacs packages that, as of today, implement their own way to
> handle for example, server sent events in a streaming way.
>
> *plz-media-type:*
>
> This library builds upon the ~plz.el~ HTTP library and provides a
> mechanism to process responses based on their content type headers. It
> defines classes for parsing and processing the HTTP body of some
> standard MIME types like JSON, XML, HTML. It also contains classes
> that can handle formats like newline delimited JSON, or JSON arrays in
> a streaming way. Those last formats are often used by LLMs. The
> library is designed to be extendable (you can replace and bring your
> own media type class) and frees users from writing their own process
> filter functions.
>
> *plz-event-source:*
>
> This library provides a media type class, parser, and event source
> implementation for the Server-Sent Events (SSE) protocol. The media
> type class can be used with the ~plz-media-type~ library. We use it in
> the llm library to process HTTP responses for LLMs that return a MIME
> type of text/event-stream.
>
> I won't spend any significant time on re-designing the API (we went
> through many iterations) or making it compatible with url-retrieve
> right now, in case someone is suggesting this. This project was partly
> sponsored by my employer while I was on a 3 month working group and we
> want to use the llm library with curl. My time on this is reaching an
> end I would like to bring it over the finish line. I am committed to
> support Andrew should any bugs or significant issues come up.
>
> Andrew Hyatt asked me to write to you to get the green light for
> publishing those libraries to GNU ELPA, once we think they are
> stable. We plan to do this in about half a year.
>
> If you agree on eventually releasing those libraries to GNU ELPA, we
> plan to merge the "plz" branch of the llm library into master soon and
> release it to a wider audience. One package that would immediately
> benefit is Ellama [4] which I thoroughly tested while working on this.
>
> My employer and I already did the copyright assignment paperwork,
> which has been completed a month ago.
>
> Wdyt?
>
> Thanks, Roman.
>
> [1] https://github.com/r0man/plz-media-type
> [2] https://github.com/r0man/plz-event-source
> [3] https://github.com/ahyatt/llm/tree/plz
> [4] https://github.com/s-kostyaev/ellama
>
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 89%]
* Re: Objed maintenance
@ 2024-04-27 11:54 95% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-04-27 11:54 UTC (permalink / raw)
To: Amy Grinn; +Cc: clemera, emacs-devel
Amy Grinn <grinn.amy@gmail.com> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Amy Grinn <grinn.amy@gmail.com> writes:
>>
>>> Philip Kaludercic <philipk@posteo.net> writes:
>>>
>>>> We should make sure that after switching the repository, new
>>>> versions
>>>> of
>>>> the package shouldn't contain hard-breaks. I only used the package
>>>> briefly a few years back, so it is difficult for me to evaluate
>>>> this
>>>> on
>>>> my own. Perhaps someone here on the list has the package installed
>>>> and
>>>> could try out Amy's fork?
>>>
>>> Any feedback would be appreciated!
>>>
>>> There were a number of changes in version 0.8.3:
>>>
>>> *** Add binding for symbol object "y"
>>> *** Change binding for forward-until from "`" to "'"
>>> *** Change binding for expand-block from "v" to "h"
>>> *** Swap bindings for forward-defun ("E") and beginning-of-defun
>>> ("A")
>>> *** Swap binding for del-insert from "i" to "c"
>>> *** "i" exits objed
>>> *** Swap binding for objed-last from "u" to "l"
>>> *** Add objed-undo command "u"
>>> *** C-g toggles objed activation
>>> *** Swap binding for objed-object-map from "c" to "o"
>>> *** Swap binding for objed-expand-context from "o" to "O" (capital
>>> "o")
>>
>> I cannot comment on any of this, with the exception of the C-g change
>> that seems invasive. Can you elaborate on that?
>
> The normal C-g behavior does not change but objed activation is also
> toggled. It's something you kinda have to experience firsthand to
> realize how non-invasive it is.
I trust you if you say it is so.
>>> In retrospect this should've been v0.9.0 according to the semver
>>> scheme
>>> Clemens is using. But we live and learn.
>>>
>>>
>>>
>>> Philip, I am using an unpublished dependency called key-game, which
>>> I
>>> wrote, which I thought might be useful for other modal editing
>>> packages,
>>> or for large packages like gnus. Anyways I will try to submit that
>>> package for publishing on GNU ELPA before objed is updated.
>>
>> That sounds good, just inferring from the name it sounds like wizard
>> or
>> training program? Is this going to be a hard dependency or a weak
>> one?
>
> Yes, it's a utility package to help create key-based or command-based
> tutorial games. It's not a user-facing package, similar to boxy; I
> wouldn't want users to have to install it explicitly. To answer a
> potential followup, I also wouldn't want to split up the objed tutorial
> game into a separate package. That would hinder discoverability and
> make the installation of objed more complex. All that to say I believe
> key-game will be a hard dependency.
That is a pity. I try to advocate for minimising dependencies,
especially if these aren't required for the core functionality of a
package. I don't know how your package is designed, but couldn't you
have a command like M-x objed-tutorial that reports an error if the
package is not installed (or proposes to install it)? FWIW I don't
think having a separate package is a good idea either -- too much noise
in the package list.
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 95%]
* Re: [PATCH] feat: add markdown-ts-mode
@ 2024-04-27 10:18 84% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-04-27 10:18 UTC (permalink / raw)
To: Rahul Martim Juliato
Cc: Eli Zaretskii, Jostein Kjønigsen, Yuan Fu,
Ergus via Emacs development discussions.
Rahul Martim Juliato <rahuljuliato@gmail.com> writes:
>> So if I understand correctly, there is no keymap or any convenience
>> features that markdown-mode provides, because this is just the
>> beginning, right? A large part of major modes for me is not just the
>> syntax highlighting and integration into Emacs systems, but also
>> bindings that in the case of Markdown would insert links or add/remove
>> emphasis. I think it would be nice, if we could add these features in
>> the future, and re-use bindings from a package like AucTeX to build on
>> existing intuition (org-mode would be an alternative, but I am not a fan
>> or their choice of bindings). Some commands to "compile" and preview a
>> document would also be nice.
>
>
> Hello there again!
>
> Please find attached the current version of this patch.
>
> It now works with the "official" tree-sitter grammar for markdown:
> https://github.com/tree-sitter-grammars/tree-sitter-markdown
>
> Please note (as explained above) the `main branch' is not the default
> anymore, but `split_parser' is.
>
> They splitted the parser into two, one for the body of the document and
> another to inline.
>
> So, in order to test this patch, configure it with:
>
> (use-package markdown-ts-mode
> :ensure nil
> :defer t
> :mode ("\\.md\\'" . markdown-ts-mode)
> :config
> (add-to-list 'treesit-language-source-alist '(markdown
> "https://github.com/tree-sitter-grammars/tree-sitter-markdown"
> "split_parser" "tree-sitter-markdown/src"))
> (add-to-list 'treesit-language-source-alist '(markdown-inline
> "https://github.com/tree-sitter-grammars/tree-sitter-markdown"
> "split_parser" "tree-sitter-markdown-inline/src")))
I have said this before, and will say it again,
`treesit-language-source-alist' shouldn't clone moving git repositories
but download tarballs (which basically every git host provides as a
feature, since git archive is built-in) and use those to build the
library. These tarballs should be pinned in the -ts-mode.el files
themselves to make using these major modes more reliable.
> If you visit a markdown file treesit issues an error, as always, asking
> for the grammars.
>
> Then, install BOTH grammars:
>
> M-x treesit-install-language-grammar RET markdown RET
> M-x treesit-install-language-grammar RET markdown-inline RET
>
> Reload the `markdown-ts-mode'.
>
> And everything should be working fine :)
>
>
> @Philip, thanks for bringing that up! I completely agree with you;
> aiming for a fully-featured mode is our long-term objective.
>
> The idea here is to establish a foundation for supporting markdown files
> within Emacs, without relying on external packages.
That sounds good.
> From there, we can delve into discussions about editing and exporting
> features. For instance, we could consider mimicking bindings and prompts
> from org-mode, as well as exploring integrations if users opt to also
> utilize third-party markdown-mode.
I would be interested in helping out or at the very least to comment on
the development going on, since I had started writing the same mode
myself a while back, but never got around to it since because I don't
understand how `treesit-font-lock-rules' works.
> However, simply having the mode built-in reduces friction significantly
> for new ideas and collaborations :)
And makes it easier for external packages to rely on the code. Usually
I'd also say that it makes Emacs more usable in offline environments,
but the fact that the tree-sitter grammars have to for now be downloaded
stands in the way of that :/
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 84%]
* Re: [ELPA] New package: colorful-mode
@ 2024-04-27 10:12 98% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-04-27 10:12 UTC (permalink / raw)
To: Elijah G; +Cc: emacs-devel
Elijah G <eg642616@gmail.com> writes:
> Hi Philip, thank you for your suggestions, I've now added
> some of them to my package, here are my answers to your questions.
>
> On Mon, Apr 22, 2024 at 1:51 AM Philip Kaludercic <philipk@posteo.net> wrote:
>>
>> (defun colorful--latex-gray-to-hex (gray)
>> "Return LaTex GRAY as hexadecimal format. GRAY must be a string."
>> @@ -350,6 +342,8 @@ HSL must be a string."
>> (string-remove-prefix "hsl(" hsl)
>> (string-remove-prefix "hsla(" hsl))
>> (rx (one-or-more (any "," " " "\t" "\n""\r" "\v" "\f")))))
>> + ;; what error is being ignored here? if (nth n hsl) is
>> + ;; nil, we can check this manually
>
> I had to add ignore-errors because it nth was throwing an error when
> nth is nil, it was bugging the other overlays in the next lines, using
> ignore-errors allows returning nil in case it can't be done and break the
> if-let conditional without affecting the other overlays.
What I am trying to say, is that ignore-errors is a rather coarse tool.
It will swallow and forget all errors that might arise, which can make
debugging difficult if something else goes wrong. My advice is to use
something like
(and (nth 0 hsl) (/ (string-to-number (nth 0 hsl)) 360.0))
unless I am misunderstanding your response somehow.
>> (h (ignore-errors (/ (string-to-number (nth 0 hsl)) 360.0)))
>> (s (ignore-errors (/ (string-to-number (nth 1 hsl)) 100.0)))
>> (l (ignore-errors (/ (string-to-number (nth 2 hsl)) 100.0)))
>
>> (defvar colorful-hex-font-lock-keywords
>> `((,(rx (seq (not (any "&"))
>> @@ -639,6 +631,7 @@ converted to a Hex color."
>> "Function for add hex colors to `colorful-color-keywords'.
>> This is intended to be used with `colorful-extra-color-keyword-functions'."
>> (dolist (colors colorful-hex-font-lock-keywords)
>> + ;; why are you using `add-to-list' here?
>> (add-to-list 'colorful-color-keywords colors t)))
>
> It was the way I found for adding the other color keywords,
> i found that using add-to-list with a buffer-local variable doesn't
> override the other buffer ones, If you know another way in how
> I would gladly implement it in my package.
I would have just used `push', as the `add-to-list' docstring advises.
> Thanks.
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 98%]
* Re: Objed maintenance
@ 2024-04-27 10:06 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-04-27 10:06 UTC (permalink / raw)
To: Amy Grinn; +Cc: clemera, emacs-devel
Amy Grinn <grinn.amy@gmail.com> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Amy Grinn <grinn.amy@gmail.com> writes:
>
>> I would say that after almost 3 years, enough time has passed that the
>> maintenance can be passed on, ans since you have some experience with
>> the package, there is probably no better person for the job right now.
>>
>
> Great, thank you!
>
>> We should make sure that after switching the repository, new versions
>> of
>> the package shouldn't contain hard-breaks. I only used the package
>> briefly a few years back, so it is difficult for me to evaluate this
>> on
>> my own. Perhaps someone here on the list has the package installed
>> and
>> could try out Amy's fork?
>
> Any feedback would be appreciated!
>
> There were a number of changes in version 0.8.3:
>
> *** Add binding for symbol object "y"
> *** Change binding for forward-until from "`" to "'"
> *** Change binding for expand-block from "v" to "h"
> *** Swap bindings for forward-defun ("E") and beginning-of-defun ("A")
> *** Swap binding for del-insert from "i" to "c"
> *** "i" exits objed
> *** Swap binding for objed-last from "u" to "l"
> *** Add objed-undo command "u"
> *** C-g toggles objed activation
> *** Swap binding for objed-object-map from "c" to "o"
> *** Swap binding for objed-expand-context from "o" to "O" (capital "o")
I cannot comment on any of this, with the exception of the C-g change
that seems invasive. Can you elaborate on that?
> In retrospect this should've been v0.9.0 according to the semver scheme
> Clemens is using. But we live and learn.
>
>
>
> Philip, I am using an unpublished dependency called key-game, which I
> wrote, which I thought might be useful for other modal editing packages,
> or for large packages like gnus. Anyways I will try to submit that
> package for publishing on GNU ELPA before objed is updated.
That sounds good, just inferring from the name it sounds like wizard or
training program? Is this going to be a hard dependency or a weak one?
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 99%]
* Re: seq; Error during initial package install
@ 2024-04-27 9:17 70% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-04-27 9:17 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Parker, Ron, Stefan Monnier, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: "Parker, Ron" <Ron.Parker@netapp.com>
>> Date: Thu, 18 Apr 2024 18:29:19 +0000
>>
>> When I start Emacs on a fresh install of my configuration, I have to
>> restart a couple times before all of the packages successfully install.
>> Upon trying to debug it, I ran into an error with seq being unable to
>> load seq-25.el and reduced it to a minimal test case.
>>
>> Put the following in an empty directory as init.el:
>>
>> (setq debug-on-error t
>> package-install-upgrade-built-in t)
>> (package-install 'seq)
>>
>> then in the directory run:
>>
>> emacs -Q --init-directory $(pwd) -l init.el
>>
>> When I do this, I get the following error:
>>
>> Debugger entered--Lisp error: (file-missing "Cannot open load file" "No such file or directory" "seq-25")
>> require(seq-25)
>> (if (version< emacs-version "25") (require 'seq-24) (require 'seq-25))
The issue is that package.el is re-loading the built-in seq, but all the
seq.el on ELPA does is try to load the right version of seq (for Emacs
24 or 25, as seen above). At this point the load-path has not been
modified yet, which is why `require' fails. I see two solutions:
1. Temporarily prepends the directory to load-path:
diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el
index ab1731aeb54..9eea1c45db5 100644
--- a/lisp/emacs-lisp/package.el
+++ b/lisp/emacs-lisp/package.el
@@ -871,8 +871,9 @@ package--reload-previously-loaded
(unless (equal (file-name-base library)
(format "%s-autoloads" (package-desc-name pkg-desc)))
(push (cons (expand-file-name library dir) recent-index) result))))
- (mapc (lambda (c) (load (car c) nil t))
- (sort result (lambda (x y) (< (cdr x) (cdr y))))))))
+ (let ((load-path (cons dir load-path)))
+ (mapc (lambda (c) (load (car c) nil t))
+ (sort result (lambda (x y) (< (cdr x) (cdr y)))))))))
(defun package-activate-1 (pkg-desc &optional reload deps)
"Activate package given by PKG-DESC, even if it was already active.
2. Loads the autoload file before reloading the package, thus updating
load-path, since this is done in the autoloads file:
diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el
index ab1731aeb54..bed0122e8ca 100644
--- a/lisp/emacs-lisp/package.el
+++ b/lisp/emacs-lisp/package.el
@@ -898,10 +898,10 @@ package-activate-1
(if (listp package--quickstart-pkgs)
;; We're only collecting the set of packages to activate!
(push pkg-desc package--quickstart-pkgs)
- (when reload
- (package--reload-previously-loaded pkg-desc))
(with-demoted-errors "Error loading autoloads: %s"
- (load (package--autoloads-file-name pkg-desc) nil t)))
+ (load (package--autoloads-file-name pkg-desc) nil t))
+ (when reload
+ (package--reload-previously-loaded pkg-desc)))
;; Add info node.
(when (file-exists-p (expand-file-name "dir" pkg-dir))
;; FIXME: not the friendliest, but simple.
I cannot test this right now, since there appears to be an unrelated
issue with elpa.gnu.org's signing keys?
>> load-with-code-conversion("/Users/<username>/.emacs-test-elpa-seq/elpa/seq-2.24/seq..."
>> "/Users/<username>/.emacs-test-elpa-seq/elpa/seq-2.24/seq..." nil t)
>> #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_32>
>> (("/Users/<username>/.emacs-test-elpa-seq/elpa/seq-2.24/seq" . 76))
>> mapc(#<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_32>
>> (("/Users/<username>/.emacs-test-elpa-seq/elpa/seq-2.24/seq" . 76)))
>> package--reload-previously-loaded(#s(package-desc :name seq :version (2 24) :summary "Sequence
>> manipulation functions" :reqs nil :kind nil :archive nil :dir
>> "/Users/<username>/.emacs-test-elpa-seq/elpa/seq-2.24" :extras ((:keywords "sequences") (:maintainer nil .
>> emacs-devel@gnu.org) (:authors ("Nicolas Petton" . nicolas@petton.fr)) (:url .
>> https://elpa.gnu.org/packages/seq.html) (:commit . "27a90793a13f149121180e864fa53d68b9eac0b3")) :
>> signed nil))
>>
>> package-activate-1(#s(package-desc :name seq :version (2 24) :summary "Sequence manipulation
>> functions" :reqs nil :kind nil :archive nil :dir "/Users/<username>/.emacs-test-elpa-seq/elpa/seq-2.24" :extras
>> ((:keywords "sequences") (:maintainer nil . emacs-devel@gnu.org) (:authors ("Nicolas Petton" .
>> nicolas@petton.fr)) (:url . https://elpa.gnu.org/packages/seq.html) (:commit .
>> "27a90793a13f149121180e864fa53d68b9eac0b3")) :signed nil) :reload :deps)
>>
>> package-unpack(#s(package-desc :name seq :version (2 24) :summary "Sequence manipulation functions"
>> :reqs nil :kind tar :archive "gnu" :dir nil :extras ((:keywords "sequences") (:maintainer nil .
>> emacs-devel@gnu.org) (:authors ("Nicolas Petton" . nicolas@petton.fr)) (:url .
>> https://elpa.gnu.org/packages/seq.html) (:commit . "27a90793a13f149121180e864fa53d68b9eac0b3")) :
>> signed nil))
>>
>> #f(compiled-function () #<bytecode 0x1511bb8ba7930de3>)()
>>
>> package--with-response-buffer-1(https://elpa.gnu.org/packages/ #f(compiled-function () #<bytecode
>> 0x1511bb8ba7930de3>) :file "seq-2.24.tar" :async nil :error-function #<subr
>> F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_79> :noerror nil)
>>
>> package-install-from-archive(#s(package-desc :name seq :version (2 24) :summary "Sequence
>> manipulation functions" :reqs nil :kind tar :archive "gnu" :dir nil :extras ((:keywords "sequences") (:maintainer
>> nil . emacs-devel@gnu.org) (:authors ("Nicolas Petton" . nicolas@petton.fr)) (:url .
>> https://elpa.gnu.org/packages/seq.html) (:commit . "27a90793a13f149121180e864fa53d68b9eac0b3")) :
>> signed nil))
>>
>> package-download-transaction((#s(package-desc :name seq :version (2 24) :summary "Sequence
>> manipulation functions" :reqs nil :kind tar :archive "gnu" :dir nil :extras ((:keywords "sequences") (:maintainer
>> nil . emacs-devel@gnu.org) (:authors ("Nicolas Petton" . nicolas@petton.fr)) (:url .
>> https://elpa.gnu.org/packages/seq.html) (:commit . "27a90793a13f149121180e864fa53d68b9eac0b3")) :
>> signed nil)))
>> package-install(seq)
>> load-with-code-conversion("/Users/<username>/.emacs-test-elpa-seq/init.el"
>> "/Users/<username>/.emacs-test-elpa-seq/init.el" nil t)
>> command-line-1(("-l" "init.el" "init.el"))
>> command-line()
>> normal-top-level()
>>
>> Emacs : GNU Emacs 29.1 (build 1, aarch64-apple-darwin23.2.0, NS appkit-2487.30 Version 14.2.1 (Build
>> 23C71))
>>
>> Package: seq
>
> Stefan and Philip, any comments or suggestions?
--
Philip Kaludercic on peregrine
^ permalink raw reply related [relevance 70%]
* Re: [ELPA] New package: colorful-mode
@ 2024-04-22 7:51 51% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-04-22 7:51 UTC (permalink / raw)
To: Elijah G; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 818 bytes --]
Elijah G <eg642616@gmail.com> writes:
> Hello, I want to submit the package colorful-mode to GNU ELPA.
>
> Colorful is a minor mode that allows preview of any color format such
> as color hex and color names in the current buffer in real time with a
> user-friendly approach.
>
> Colorful was based in rainbow-mode source, but colorful diverged in
> other way being more friendly, customizable and allow converting color
> to others with mouse clicks or keybindings such as css rgb/hsl to hex,
> or hex to color name and allow using prefix/suffix as indicator or
> highlight it using overlays, also it has support for mouse clicks for
> changing colors or using keybindings.
>
> The source can be found at: https://github.com/DevelopmentCool2449/colorful-mode
Sounds nice. Here are a few comments and suggestions:
[-- Attachment #2: Type: text/plain, Size: 6755 bytes --]
diff --git a/colorful-mode.el b/colorful-mode.el
index d28db8d..82ddf5e 100644
--- a/colorful-mode.el
+++ b/colorful-mode.el
@@ -30,20 +30,18 @@
;; friendly and effective way based on rainbow-mode.
;;; Code:
+
\f
-;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
-;; Libraries ;
-;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
+;;;; Libraries
(require 'compat)
(require 'color)
(eval-when-compile (require 'subr-x))
+(eval-when-compile (require 'rx))
\f
-;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
-;; Customizable User Options ;
-;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
+;;;; User Options
(defgroup colorful nil
"Preview hex colors values in current buffer.."
@@ -279,9 +277,7 @@ mode is derived from `prog-mode'."
:type '(choice boolean (const :tag "Only in prog-modes" only-prog)))
\f
-;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
-;; Keymaps ;
-;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
+;;;; Keymaps
(defvar-keymap colorful-mode-map
:doc "Keymap when `colorful-mode' is active."
@@ -290,19 +286,14 @@ mode is derived from `prog-mode'."
"C-c c r" #'colorful-convert-and-change-color)
\f
-;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
-;; Internal variables ;
-;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
+;;;; Internal variables
(defvar-local colorful-color-keywords nil
"Font-lock colors keyword to highlight.")
\f
-;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
-;; Internal Functions ;
-;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
-
-;;;;;;;;;; Base Convertion functions ;;;;;;;;;;
+;;;; Internal Functions
+;;;;; Base Convertion functions
(defun colorful--percentage-to-absolute (percentage)
"Convert PERCENTAGE to a absolute number.
@@ -315,12 +306,13 @@ If PERCENTAGE is above 100%, it's converted to 100."
(string-to-number percentage))))
(defun colorful--latex-rgb-to-hex (rgb)
- "Return LaTex RGB as hexadecimal format. RGB must be a string."
- (let* ((rgb (string-split (string-remove-prefix "{rgb}{" rgb) ","))
- (r (string-to-number (nth 0 rgb)))
- (g (string-to-number (nth 1 rgb)))
- (b (string-to-number (nth 2 rgb))))
- (color-rgb-to-hex r g b)))
+ "Return LaTeX RGB as hexadecimal format. RGB must be a string."
+ ;; just as an alternative idea:
+ (and (string-match "{rgb}{\\([[:digit:]]+\\),\\([[:digit:]]+\\),\\([[:digit:]]+\\)}" rgb)
+ (color-rgb-to-hex
+ (string-to-number (match-string 1 rgb))
+ (string-to-number (match-string 2 rgb))
+ (string-to-number (match-string 3 rgb)))))
(defun colorful--latex-gray-to-hex (gray)
"Return LaTex GRAY as hexadecimal format. GRAY must be a string."
@@ -350,6 +342,8 @@ HSL must be a string."
(string-remove-prefix "hsl(" hsl)
(string-remove-prefix "hsla(" hsl))
(rx (one-or-more (any "," " " "\t" "\n""\r" "\v" "\f")))))
+ ;; what error is being ignored here? if (nth n hsl) is
+ ;; nil, we can check this manually
(h (ignore-errors (/ (string-to-number (nth 0 hsl)) 360.0)))
(s (ignore-errors (/ (string-to-number (nth 1 hsl)) 100.0)))
(l (ignore-errors (/ (string-to-number (nth 2 hsl)) 100.0)))
@@ -367,11 +361,11 @@ HSL must be a string."
"Return color NAME as hex color format.
DIGIT specifies which how much digits per component must have return value."
(if-let* ((color-name (color-name-to-rgb name))
- (color (append color-name `(,digit))))
+ (color (append color-name (list digit))))
(apply #'color-rgb-to-hex color)
(cdr (assoc-string name colorful-html-colors-alist))))
-;;;;;;;;;; User Interactive Functions ;;;;;;;;;;
+;;;;; User Interactive Functions
;;;###autoload
(defun colorful-convert-and-change-color ()
@@ -419,12 +413,12 @@ DIGIT specifies which how much digits per component must have return value."
("Convert and copy color." . copy)))
(result (alist-get
(completing-read prompt choices nil t nil nil)
- choices nil nil 'equal)))
+ choices nil nil #'equal)))
(if (eq result 'copy)
(colorful-convert-and-copy-color)
(colorful-convert-and-change-color))))
-;;;;;;;;;; Coloring functions ;;;;;;;;;;
+;;;;; Coloring functions
(defun colorful--change-color (ov &optional prompt color beg end)
"Return COLOR as other color format.
@@ -582,9 +576,7 @@ converted to a Hex color."
(colorful--colorize-match string beg end)))
\f
-;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
-;; Extra coloring definitions ;
-;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
+;;;; Extra coloring definitions
(defvar colorful-hex-font-lock-keywords
`((,(rx (seq (not (any "&"))
@@ -639,6 +631,7 @@ converted to a Hex color."
"Function for add hex colors to `colorful-color-keywords'.
This is intended to be used with `colorful-extra-color-keyword-functions'."
(dolist (colors colorful-hex-font-lock-keywords)
+ ;; why are you using `add-to-list' here?
(add-to-list 'colorful-color-keywords colors t)))
(defvar colorful-color-name-font-lock-keywords
@@ -730,9 +723,7 @@ This is intended to be used with `colorful-extra-color-keyword-functions'."
(add-to-list 'colorful-color-keywords colors t)))
\f
-;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
-;; Minor mode defintinions ;
-;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
+;;;; Minor mode defintinions
(defun colorful--turn-on ()
"Helper function for turn on `colorful-mode'."
@@ -759,7 +750,7 @@ This is intended to be used with `colorful-extra-color-keyword-functions'."
;;;###autoload
(define-minor-mode colorful-mode
"Preview any color in your buffer such as hex, color names, CSS rgb in real time."
- :lighter nil :keymap colorful-mode-map
+ :global nil
(if colorful-mode
(colorful--turn-on)
(colorful--turn-off))
[-- Attachment #3: Type: text/plain, Size: 205 bytes --]
Regarding the headers, my changes would make it compatible with
outline-minor-mode for Elisp, but if you prefer your style, then you can
also adjust `outline-regexp'.
--
Philip Kaludercic on peregrine
^ permalink raw reply related [relevance 51%]
* Re: Objed maintenance
@ 2024-04-22 7:22 89% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-04-22 7:22 UTC (permalink / raw)
To: Amy Grinn; +Cc: clemera, emacs-devel
Amy Grinn <grinn.amy@gmail.com> writes:
> Hi Clemens!
>
> First of all, I want to extend my appreciation for your innovative work
> on the objed package. It is by far and away my favorite modal editing
> package.
>
> I have been maintaining a fork of objed for about two years; it's
> available here:
>
> https://gitlab.com/grinn.amy/objed
>
> I believe my addition of the C-g command and the objed-game tutorial can
> be valuable to existing users. The former allows for quickly entering
> and exiting objed and the latter allows users to learn the whole
> potential of the package.
>
> I've also made improvements to existing commands such as slurp and barf,
> organized the codebase, updated the documentation, and simplified the
> build and testing process using eldev.
>
> I would love to get your feedback on any of these improvements, however
> I'm aware that this package is not at the forefront of your mind right
> now. In the absence of any activity over the past 4 years, I would
> humbly suggest turning the project over to me.
It is my impression, that Clemens isn't really active around Emacs any
more. His last public contribution on GitHub was 2021 and his website
https://with-emacs.com/ now points to some gambling site (after a HTTPS
error).
I would say that after almost 3 years, enough time has passed that the
maintenance can be passed on, ans since you have some experience with
the package, there is probably no better person for the job right now.
We should make sure that after switching the repository, new versions of
the package shouldn't contain hard-breaks. I only used the package
briefly a few years back, so it is difficult for me to evaluate this on
my own. Perhaps someone here on the list has the package installed and
could try out Amy's fork?
> Best,
>
> Amy
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 89%]
* Re: [PATCH] feat: add markdown-ts-mode
@ 2024-04-22 7:02 88% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-04-22 7:02 UTC (permalink / raw)
To: Rahul Martim Juliato
Cc: Jostein Kjønigsen, Yuan Fu,
Ergus via Emacs development discussions., Eli Zaretskii
Rahul Martim Juliato <rahuljuliato@gmail.com> writes:
> Thanks Eli and Jostein!
>
> No problem criticising :)
>
>
> Please find a new patch attached. Things I've made:
>
> - changed the file to the textmodes folder
>
> - made it inherit from `text-mode'
>
> - changed the news with +++
>
> - changed `emacs.texi' (is it here?) to add Markdown
>
> - scratched my head until 2:30AM thinking why it would not work for
> Jostein test.
>
>
> Well Jostein, I've been played by the tree-sitter github repository
> maintainer, lol.
>
> First, a little note. There's actually no major changes to the version
> on github. I only changed documenting strings and made some small name
> changes to more "alike" already existing modes.
>
> It happens that on tree-sitter repository, unlike any other of their
> repositories (that I've seen), "main" branch is NOT the current branch,
> but the "we moved from here bye" one.
>
> The current default branch is "split_parser" where
> tree-sitter-markdown/src/ resides, hence the confusion.
>
> So, I wrote the mode with the "main" one in mind.
>
> I already checked the "new" (split_parser) one, and it seems it is
> possible to convert the current work to use this one instead. I'll try
> to do this in the middle of the week or sooner :)
>
> In the mean time, I realized more people would like to test this patch
> and tree-sitter setup is really trick, so I made this little "guide" on
> how to apply it until the end result (this might work now, pointing to
> the "main" branch with the current patch).
>
> If you could please try the path (B) on the guide and tell me if this
> works for you, It would be nice, Jostein.
>
>
> Thanks!
>
> Rahul
>
>
>
> --- beggining of guide on how to apply this patch and test it
>
> Git apply this patch.
>
> Run the autogen script:
>
> ./autogen.sh
>
> Make sure configure uses tree-sitter:
>
> ./configure --with-tree-sitter
>
> Compile:
>
> make bootstrap
>
> Check the build:
>
> ./src/emacs -Q --version
>
> Open emacs
>
> ./src/emacs -Q --init-dir=~/tmp_emacs_dir/
>
>
> A) The Hard Way
>
> Visit a .md file
>
> C-x f TEST.md
>
> Note the mode will not automatically load.
>
> This behavior is the same as typescript-ts-mode or other
> treesitter modes I've been using.
>
> M-x markdown-ts-mode
>
> It will fail since you have no tree sitter grammar installed.
> and will suggest installing it with `treesit-install-language-grammar'.
>
> This behaviour is also standard for the tree-sitter modes I
> currently use (typescript, tsx, rust).
>
> Issuing "M-x treesit-install-language-grammar RET".
>
> It asks for language, complete with "markdown RET".
>
> It says there's no recipie for it, if you want to build it
> interactivelly. Anwser "yes".
>
> It asks for the URL where the grammar is hosted, enter:
> "https://github.com/tree-sitter-grammars/tree-sitter-markdown RET"
>
> It asks for the tag or branch, setting the default, enter "main RET".
>
> It asks for the subfolder, leave the default (src), enter "RET".
>
> It asks for the C compiler to use (default: auto-detect), just "RET".
>
> It asks for the C++ compiler to use (default: auto-detect), just "RET".
>
> Install to (default "~/tmp_emacs_dir/treesitter"), just "RET".
>
> It will clone the repository, compile the library and tell in the
> minibuffer the library is installed to your folder.
>
>
> B) The Easier Way.
>
> Copy-paste and eval this use-package definition.
>
> (use-package markdown-ts-mode
> :mode ("\\.md\\'" . markdown-ts-mode)
> :defer 't
> :config
> (add-to-list 'treesit-language-source-alist '(markdown "https://github.com/tree-sitter-grammars/tree-sitter-markdown" "main" "src")))
>
>
> Visit your markdown test file.
>
> It will probably fail due to the missing grammar.
>
> Issue "M-x treesit-install-language-grammar RET".
>
> Now with TAB it should complete "markdown", if not, type it.
>
> As we already have the source now defined, just hit "RET" to install
> to the default treemacs folder.
>
> It will clone the repository and say it installed on your folder.
>
> Just reload the mode with "M-x markdown-ts-mode".
>
> From now on (with the use-package definition on `init.el') you should
> just open .md and have the highlight and stuff.
>
> --- end of the guide
>
> From 45796df36129ec77c532b3fa21cdd0b8033c9777 Mon Sep 17 00:00:00 2001
> From: Rahul Martim Juliato <rahul.juliato@gmail.com>
> Date: Fri, 19 Apr 2024 23:21:20 -0300
> Subject: [PATCH] feat: add markdown-ts-mode
>
> * lisp/textmodes/markdown-ts-mode.el: New file.
> * doc/emacs/emacs.texi: Add Markdown to the manual
> * etc/NEWS: Announce markdown-ts-mode
> ---
> doc/emacs/emacs.texi | 1 +
> etc/NEWS | 5 ++
> lisp/textmodes/markdown-ts-mode.el | 106 +++++++++++++++++++++++++++++
> 3 files changed, 112 insertions(+)
> create mode 100644 lisp/textmodes/markdown-ts-mode.el
>
> diff --git a/doc/emacs/emacs.texi b/doc/emacs/emacs.texi
> index 7d77f13ab21..244c822ee04 100644
> --- a/doc/emacs/emacs.texi
> +++ b/doc/emacs/emacs.texi
> @@ -618,6 +618,7 @@ Top
> * Enriched Text:: Editing text enriched with fonts, colors, etc.
> * Text Based Tables:: Commands for editing text-based tables.
> * Two-Column:: Splitting text columns into separate windows.
> +* Markdown:: Major mode for editing Markdown files.
>
> Filling Text
>
> diff --git a/etc/NEWS b/etc/NEWS
> index 8ad1e78ca60..06fbaa03b55 100644
> --- a/etc/NEWS
> +++ b/etc/NEWS
> @@ -1688,6 +1688,11 @@ A major mode based on the tree-sitter library for editing Elixir files.
> *** New major mode 'lua-ts-mode'.
> A major mode based on the tree-sitter library for editing Lua files.
>
> ++++
> +*** New major mode 'markdown-ts-mode'.
> +A major mode based on the tree-sitter library for editing Markdown files.
> +
> +
> ** Minibuffer and Completions
>
> +++
> diff --git a/lisp/textmodes/markdown-ts-mode.el b/lisp/textmodes/markdown-ts-mode.el
> new file mode 100644
> index 00000000000..063780a772f
> --- /dev/null
> +++ b/lisp/textmodes/markdown-ts-mode.el
> @@ -0,0 +1,106 @@
> +;;; markdown-ts-mode.el --- tree sitter support for Markdown -*- lexical-binding: t; -*-
> +
> +;; Copyright (C) 2024 Free Software Foundation, Inc.
> +
> +;; Author : Rahul Martim Juliato <rahul.juliato@gmail.com>
> +;; Maintainer : Rahul Martim Juliato <rahul.juliato@gmail.com>
> +;; Created : April 2024
> +;; Keywords : markdown md languages tree-sitter
> +
> +;; This file is part of GNU Emacs.
> +
> +;; GNU Emacs 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.
> +
> +;; GNU Emacs 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 GNU Emacs. If not, see <https://www.gnu.org/licenses/>.
> +
> +;;; Commentary:
> +;;
You should probably briefly explain the package here.
> +;;; Code:
> +
> +(require 'treesit)
> +(require 'subr-x)
> +
> +(declare-function treesit-node-parent "treesit.c")
> +(declare-function treesit-node-type "treesit.c")
> +(declare-function treesit-parser-create "treesit.c")
> +
> +(defvar markdown-ts--treesit-settings
> + (treesit-font-lock-rules
> + :language 'markdown
> + :override t
> + :feature 'delimiter
> + '([ "[" "]" "(" ")" ] @shadow)
> +
> + :language 'markdown
> + :feature 'paragraph
> + '([((atx_heading) @font-lock-keyword-face)
> + ((block_quote_marker) @font-lock-string-face)
> + ((code_span) @font-lock-string-face)
> + ((emphasis) @underline)
> + ((image_description) @link)
> + ((indented_code_block) @font-lock-string-face)
> + ((link_destination) @font-lock-string-face)
> + ((setext_heading) @font-lock-keyword-face)
> + ((strong_emphasis) @bold)
> + ((thematic_break) @shadow)
> + (block_quote (block_quote_marker) @font-lock-string-face)
> + (block_quote (paragraph) @font-lock-string-face)
> + (fenced_code_block (code_fence_content) @font-lock-string-face)
> + (fenced_code_block (fenced_code_block_delimiter) @font-lock-doc-face)
> + (inline_link (link_destination) @font-lock-string-face)
> + (inline_link (link_text) @link)
> + (list_item (list_marker_dot) @font-lock-keyword-face)
> + (list_item (list_marker_minus) @font-lock-keyword-face)
> + (list_item (list_marker_plus) @font-lock-keyword-face)
> + (list_item (list_marker_star) @font-lock-keyword-face)
> + (shortcut_link (link_text) @link)
> + ])))
> +
> +(defun markdown-ts-imenu-node-p (node)
> + "Check if NODE is a valid entry to imenu."
> + (equal (treesit-node-type (treesit-node-parent node))
> + "atx_heading"))
> +
> +(defun markdown-ts-imenu-name-function (node)
> + "Return an imenu entry if NODE is a valid header."
> + (let ((name (treesit-node-text node)))
> + (if (markdown-ts-imenu-node-p node)
> + (thread-first (treesit-node-parent node)(treesit-node-text))
> + name)))
> +
> +(defun markdown-ts-setup ()
> + "Setup treesit for `markdown-ts-mode'."
> + (setq-local treesit-font-lock-settings markdown-ts--treesit-settings)
> + (treesit-major-mode-setup))
> +
> +;;;###autoload
> +(define-derived-mode markdown-ts-mode text-mode "Markdown"
> + "Major mode for editing Markdown using tree-sitter grammar."
> + (setq-local font-lock-defaults nil
> + treesit-font-lock-feature-list '((delimiter)
> + (paragraph)))
> +
> + (setq-local treesit-simple-imenu-settings
> + `(("Headings" markdown-ts-imenu-node-p nil markdown-ts-imenu-name-function)))
> +
> + (when (treesit-ready-p 'markdown)
> + (treesit-parser-create 'markdown)
> + (markdown-ts-setup)))
> +
> +(derived-mode-add-parents 'markdown-ts-mode '(markdown-mode))
> +
> +(if (treesit-ready-p 'markdown)
> + (add-to-list 'auto-mode-alist '("\\.md\\'" . markdown-ts-mode)))
> +
> +(provide 'markdown-ts-mode)
> +;;; markdown-ts-mode.el ends here
So if I understand correctly, there is no keymap or any convenience
features that markdown-mode provides, because this is just the
beginning, right? A large part of major modes for me is not just the
syntax highlighting and integration into Emacs systems, but also
bindings that in the case of Markdown would insert links or add/remove
emphasis. I think it would be nice, if we could add these features in
the future, and re-use bindings from a package like AucTeX to build on
existing intuition (org-mode would be an alternative, but I am not a fan
or their choice of bindings). Some commands to "compile" and preview a
document would also be nice.
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 88%]
* Re: [DISCUSSION] "quick-help" popup for org-columns (column view)
@ 2024-04-16 7:24 93% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-04-16 7:24 UTC (permalink / raw)
To: Sławomir Grochowski
Cc: Eli Zaretskii, yantar92, emacs-orgmode, emacs-devel
Sławomir Grochowski <slawomir.grochowski@gmail.com> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>> I have pushed the changes to master.
>
> Thank you Philip for your help. It works.
>
> But there is one more small thing.
> A message that is displayed in the minibuffer.
> It contains two pieces of information:
>
> (1) command name
> Right now it's hardcoded.
> We need to change the it from `help-quick-toggle' to
> `org-columns-help-quick-toggle'.
> How to do it?
> Add another variable like `help-quick-use-map'?
> Maybe 'help-quick-command-name'?
Instead of using substitute-command-keys, we could just use
this-command, but that assumes that help-quick can always be toggled by
the command that invokes it.
> (2) keybinding to the command name
> Just to modify message string. Add '\\<help-quick-use-map>'.
> To use other keymap.
> Change is in the diff below.
I don't see how this would work in general, at the very least it breaks
the regular usage.
Furthermore, I am not convinced we have to change anything here, since
C-h C-q (the default binding for `help-quick-toggle') should also hide
the buffer if one uses your command, or am I mistaken?
>
> diff --git a/lisp/help.el b/lisp/help.el
> index d4e39f04e53..35412b9d2fe 100644
> --- a/lisp/help.el
> +++ b/lisp/help.el
> @@ -263,7 +263,9 @@ help-quick
> ;; ... and shrink it immediately.
> (fit-window-to-buffer))
> (message
> - (substitute-command-keys "Toggle display of quick-help buffer using \\[help-quick-toggle]."))))
> + (substitute-command-keys "Toggle display of quick-help buffer using\\<help-quick-use-map> \\[org-columns-help-quick-toggle]."))))
> +
> +
>
> (defun help-quick-toggle ()
> "Toggle display of a window showing popular commands and their bindings.
> --
>
> 2.30.2
>
>
> Regards,
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 93%]
* Re: [DISCUSSION] "quick-help" popup for org-columns (column view)
2024-04-11 6:37 99% ` Philip Kaludercic
2024-04-11 6:58 86% ` Philip Kaludercic
@ 2024-04-13 8:37 99% ` Philip Kaludercic
1 sibling, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-04-13 8:37 UTC (permalink / raw)
To: Sławomir Grochowski
Cc: Eli Zaretskii, yantar92, emacs-orgmode, emacs-devel
Philip Kaludercic <philipk@posteo.net> writes:
> Sławomir Grochowski <slawomir.grochowski@gmail.com> writes:
>
>> Thank you Philip for the explanation and preparing the code snippet.
>>
>> So what are the next steps?
>> Can you merge your patch?
>
> If this is everything, I can push the change. But I'll test it first.
I have pushed the changes to master.
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 99%]
* Re: [DISCUSSION] "quick-help" popup for org-columns (column view)
2024-04-11 6:37 99% ` Philip Kaludercic
@ 2024-04-11 6:58 86% ` Philip Kaludercic
2024-04-13 8:37 99% ` Philip Kaludercic
1 sibling, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-04-11 6:58 UTC (permalink / raw)
To: Sławomir Grochowski
Cc: Eli Zaretskii, yantar92, emacs-orgmode, emacs-devel
Philip Kaludercic <philipk@posteo.net> writes:
> Sławomir Grochowski <slawomir.grochowski@gmail.com> writes:
>
>> Thank you Philip for the explanation and preparing the code snippet.
>>
>> So what are the next steps?
>> Can you merge your patch?
>
> If this is everything, I can push the change. But I'll test it first.
I tried out using your `org-columns-help-quick-sections' variable, but
it seems that `where-is' didn't find all the commands you wanted:
--8<---------------cut here---------------start------------->8---
Move column & row Add & delete column Edit column Edit values View Misc.
M-<left> move column left M-S-<right> add column < narrow e edit value c show content C-c C-o open link
M-<right> move column right M-S-<left> delete column > widen a edit allowed value o show overview g redo
s attributes n next allowed value v show value q quit
p previous allowed value
C-c C-c toggle checkbox or quit
C-c C-t change TODO state
--8<---------------cut here---------------end--------------->8---
(some of the descriptions are pretty long, are they not?)
Are commands like `org-columns-move-up' part of the next release of Org?
I am using whatever is currently on master.
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 86%]
* Re: [DISCUSSION] "quick-help" popup for org-columns (column view)
@ 2024-04-11 6:37 99% ` Philip Kaludercic
2024-04-11 6:58 86% ` Philip Kaludercic
2024-04-13 8:37 99% ` Philip Kaludercic
0 siblings, 2 replies; 200+ results
From: Philip Kaludercic @ 2024-04-11 6:37 UTC (permalink / raw)
To: Sławomir Grochowski
Cc: Eli Zaretskii, yantar92, emacs-orgmode, emacs-devel
Sławomir Grochowski <slawomir.grochowski@gmail.com> writes:
> Thank you Philip for the explanation and preparing the code snippet.
>
> So what are the next steps?
> Can you merge your patch?
If this is everything, I can push the change. But I'll test it first.
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 99%]
* Re: [DISCUSSION] "quick-help" popup for org-columns (column view)
@ 2024-04-10 8:26 84% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-04-10 8:26 UTC (permalink / raw)
To: Sławomir Grochowski
Cc: Eli Zaretskii, yantar92, emacs-orgmode, emacs-devel
[-- Attachment #1: Type: text/plain, Size: 324 bytes --]
Sławomir Grochowski <slawomir.grochowski@gmail.com> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> We could add a `help-quick-use-map' variable and bind it to `global-map'
>> by default. You can then re-bind it in your command.
>
> I'm sorry, but I don't quite understand it.
Just this here:
[-- Attachment #2: Type: text/plain, Size: 941 bytes --]
diff --git a/lisp/help.el b/lisp/help.el
index 1ef46e394f3..5700f10fdc8 100644
--- a/lisp/help.el
+++ b/lisp/help.el
@@ -175,6 +175,9 @@ help-quick-sections
COMMAND is the symbol of a command and DESCRIPTION is its short
description, 10 to 15 char5acters at most.")
+(defvar help-quick-use-map global-map
+ "Keymap that `help-quick' should use to lookup bindings.")
+
(declare-function prop-match-value "text-property-search" (match))
;; Inspired by a mg fork (https://github.com/troglobit/mg)
@@ -193,7 +196,7 @@ help-quick
(let ((max-key-len 0) (max-cmd-len 0) keys)
(dolist (ent (reverse (cdr section)))
(catch 'skip
- (let* ((bind (where-is-internal (car ent) nil t))
+ (let* ((bind (where-is-internal (car ent) help-quick-use-map t))
(key (if bind
(propertize
(key-description bind)
[-- Attachment #3: Type: text/plain, Size: 565 bytes --]
You would then only have to rebind `help-quick-use-map' in your custom
command.
> It seems to me that the simplest way is to add a parameter to the
> function, like this:
>
> (defun help-quick (&optional keymap)
>
> Because it will not change the behavior for previous calls to this
> function. And it will allow to pass specific keymap, not need to pass
> and search in whole global-map.
>
> What do you think?
Eli said that we shouldn't change the signature of public functions, so
I don't think that this is an option.
--
Philip Kaludercic on peregrine
^ permalink raw reply related [relevance 84%]
* Re: [DISCUSSION] "quick-help" popup for org-columns (column view)
@ 2024-04-08 8:24 96% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-04-08 8:24 UTC (permalink / raw)
To: Sławomir Grochowski
Cc: Eli Zaretskii, yantar92, emacs-orgmode, emacs-devel, stefankangas,
larsi, hmelman, info
Sławomir Grochowski <slawomir.grochowski@gmail.com> writes:
> chad <yandros@gmail.com> writes:
>
>> If you don't mind me asking:
>
> Thank you for sharing your views.
>
>> What are your high-level goals and immediate needs for changing
>> help-quick?
>
> I want to reuse quick-help for functionality in org-mode - column view
> package. See first email in this thread - there is even a screenshot.
>
>> It looks like you may be trying to have multiple
>> simultaneous quick-help buffers active at once?
>
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Is there a reason not to re-use the same buffer? I am not sure if we
>> need multiple quick-help buffer to co-exist at the same time.
>
> Yes you are right. There is no need to create multiple quick-help
> buffers.
>
>> The idea here was that some other function could rebind
>> `help-quick-sections' dynamically. That way you avoid the redundant
>> arguments (which would all have to be documented).
>
> Is this really a good practice?
It certainly is practice.
> Relying on global variables instead of passing variables as a parameters?
A lot of Emacs Lisp code uses dynamic scope. Examples include
`default-directory' or a lot of search functionality.
> I tried like this:
>
> +(defun org-columns-help-quick-toggle ()
> + (interactive)
> + (let ((help-quick-sections org-columns-help-quick-sections))
> + (help-quick-toggle)))
>
> So passing a 'sections' data works.
> But it doesn't read keymaps from `org-columns-map'.
> Because as I understand it read keymaps available only in the created buffer
> "*Quick Help*" not from the buffer with org-colview.
>
> This is the line from function: `help-quick' where it happens:
> + (let* ((bind (where-is-internal (car ent) nil t))
> Signature:
> (where-is-internal DEFINITION &optional KEYMAP FIRSTONLY NOINDIRECT NO-REMAP)
>
> So previously I was passing a keymap `org-columns-map' to function 'where-is-internal'.
>
> Eli Zaretskii <eliz@gnu.org> writes:
>> In any case, we cannot change the signature of help-quick, since it's a
>> public function.
>
> If I can't modify the function `help-quick' how can I make it work?
We could add a `help-quick-use-map' variable and bind it to `global-map'
by default. You can then re-bind it in your command.
> I'm attaching the whole patch:
>
> From dcc5172c87f9f7acfc9ab3a72f7de8b363a05447 Mon Sep 17 00:00:00 2001
> From: Slawomir Grochowski <slawomir.grochowski@gmail.com>
> Date: Sun, 7 Apr 2024 01:13:27 +0200
> Subject: [PATCH] lisp/org-colview.el: add help-quick sections for org-colview
>
> ---
> lisp/org-colview.el | 41 +++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 41 insertions(+)
>
> diff --git a/lisp/org-colview.el b/lisp/org-colview.el
> index d71c84a76..547f50df8 100644
> --- a/lisp/org-colview.el
> +++ b/lisp/org-colview.el
> @@ -169,6 +169,7 @@ See `org-columns-summary-types' for details.")
> (org-cycle-overview)
> (org-cycle-content))
>
> +(org-defkey org-columns-map "?" #'org-columns-help-quick-toggle)
> (org-defkey org-columns-map "c" #'org-columns-content)
> (org-defkey org-columns-map "o" #'org-overview)
> (org-defkey org-columns-map "e" #'org-columns-edit-value)
> @@ -231,6 +232,46 @@ See `org-columns-summary-types' for details.")
> "--"
> ["Quit" org-columns-quit t]))
>
> +(defvar org-columns-help-quick-sections
> + '(("Move"
> + (org-columns-move-up . "up")
> + (org-columns-move-down . "down")
> + (org-columns-move-cursor-left . "left")
> + (org-columns-move-cursor-right . "right"))
> + ("Move column & row"
> + (org-columns-move-row-up . "move row up")
> + (org-columns-move-row-down . "move row down")
> + (org-columns-move-left . "move column left")
> + (org-columns-move-right . "move column right"))
> + ("Add & delete column"
> + (org-columns-new . "add column")
> + (org-columns-delete . "delete column"))
> + ("Edit column"
> + (org-columns-narrow . "narrow")
> + (org-columns-widen . "widen")
> + (org-columns-edit-attributes . "attributes"))
> + ("Edit values"
> + (org-columns-edit-value . "edit value")
> + (org-columns-edit-allowed . "edit allowed value")
> + (org-columns-next-allowed-value . "next allowed value")
> + (org-columns-previous-allowed-value . "previous allowed value")
> + (org-columns-toggle-or-columns-quit . "toggle checkbox or quit")
> + (org-columns-todo . "change TODO state"))
> + ("View"
> + (org-columns-content . "show content")
> + (org-overview . "show overview")
> + (org-columns-show-value . "show value"))
> + ("Misc."
> + (org-columns-open-link . "open link")
> + (org-columns-redo . "redo")
> + (org-columns-help-quick-toggle . "toggle this help")
> + (org-columns-quit . "quit"))))
> +
> +(defun org-columns-help-quick-toggle ()
> + (interactive)
> + (let ((help-quick-sections org-columns-help-quick-sections))
> + (help-quick-toggle)))
> +
> (defun org-columns--displayed-value (spec value &optional no-star)
> "Return displayed value for specification SPEC in current entry.
>
> --
> 2.30.2
>
>
> Regards,
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 96%]
* Re: [DISCUSSION] "quick-help" popup for org-columns (column view)
@ 2024-04-06 22:40 89% ` Philip Kaludercic
1 sibling, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-04-06 22:40 UTC (permalink / raw)
To: Sławomir Grochowski
Cc: Ihor Radchenko, emacs-orgmode, emacs-devel, stefankangas, larsi,
hmelman, eliz, info
Sławomir Grochowski <slawomir.grochowski@gmail.com> writes:
> Ihor Radchenko <yantar92@posteo.net> writes:
>
>> I see no downside supporting `help-quick' command in Org mode's column
>> view. Generally, better integration with Emacs built-in functionality is
>> welcome.
>
> Great. I'll be happy to take care of it.
>
> But first, we need to modify `help-quick' to be more reusable.
> I tried to do it, but I'm not experienced in elisp.
> I wanted to remove references to global variables, so I did a wrapper
> function to pass arguments to `help-quick'. I understand it's not a lispy way.
> I would be grateful for your comment.
>
> Patch in attachment.
I have to admit that I am not entirely certain what the plan is, but I
have a few concrete comments/questions on this patch
> From 5f343fd15c53f5bc5e7515ef0cd3049b4e0ec388 Mon Sep 17 00:00:00 2001
> From: Slawomir Grochowski <slawomir.grochowski@gmail.com>
> Date: Sat, 6 Apr 2024 22:11:01 +0200
> Subject: [PATCH] lisp/help: make `help-quick-toggle' reusable for other
> keymaps
>
> ---
> lisp/help.el | 22 +++++++++++++---------
> 1 file changed, 13 insertions(+), 9 deletions(-)
>
> diff --git a/lisp/help.el b/lisp/help.el
> index 1ef46e394f3..c32d1a2e943 100644
> --- a/lisp/help.el
> +++ b/lisp/help.el
> @@ -76,7 +76,7 @@ help-map
> "C-n" #'view-emacs-news
> "C-o" #'describe-distribution
> "C-p" #'view-emacs-problems
> - "C-q" #'help-quick-toggle
> + "C-q" #'help-quick-toggle-wrapper
> "C-s" #'search-forward-help-for-help
> "C-t" #'view-emacs-todo
> "C-w" #'describe-no-warranty
> @@ -178,22 +178,22 @@ help-quick-sections
> (declare-function prop-match-value "text-property-search" (match))
>
> ;; Inspired by a mg fork (https://github.com/troglobit/mg)
> -(defun help-quick ()
> +(defun help-quick (name-for-buffer sections &optional keymap)
> "Display a quick-help buffer showing popular commands and their bindings.
> The window showing quick-help can be toggled using \\[help-quick-toggle].
> You can click on a key binding shown in the quick-help buffer to display
> the documentation of the command bound to that key sequence."
> (interactive)
> - (with-current-buffer (get-buffer-create "*Quick Help*")
> + (with-current-buffer (get-buffer-create name-for-buffer)
Is there a reason not to re-use the same buffer? I am not sure if we
need multiple quick-help buffer to co-exist at the same time.
> (let ((inhibit-read-only t) (padding 2) blocks)
>
> ;; Go through every section and prepare a text-rectangle to be
> ;; inserted later.
> - (dolist (section help-quick-sections)
> + (dolist (section sections)
The idea here was that some other function could rebind
`help-quick-sections' dynamically. That way you avoid the redundant
arguments (which would all have to be documented).
> (let ((max-key-len 0) (max-cmd-len 0) keys)
> (dolist (ent (reverse (cdr section)))
> (catch 'skip
> - (let* ((bind (where-is-internal (car ent) nil t))
> + (let* ((bind (where-is-internal (car ent) keymap t))
> (key (if bind
> (propertize
> (key-description bind)
> @@ -259,21 +259,25 @@ help-quick
> (message
> (substitute-command-keys "Toggle display of quick-help buffer using \\[help-quick-toggle]."))))
>
> -(defun help-quick-toggle ()
> +(defun help-quick-toggle-wrapper ()
The naming here is weird IMO, usually the other function should be
called something like `help-quick-toggle-internal' and this would be
`help-quick-toggle'.
> + (interactive)
> + (help-quick-toggle "*Quick Help*" help-quick-sections))
> +
> +(defun help-quick-toggle (name-for-buffer sections &optional keymap)
> "Toggle display of a window showing popular commands and their bindings.
> This toggles on and off the display of the quick-help buffer, which shows
> popular commands and their bindings as produced by `help-quick'.
> You can click on a key binding shown in the quick-help buffer to display
> the documentation of the command bound to that key sequence."
> (interactive)
> - (if (and-let* ((window (get-buffer-window "*Quick Help*")))
> + (if (and-let* ((window (get-buffer-window name-for-buffer)))
> (quit-window t window))
> ;; Clear the message we may have gotten from `C-h' and then
> ;; waiting before hitting `q'.
> (message "")
> - (help-quick)))
> + (help-quick name-for-buffer sections keymap)))
>
> -(defalias 'cheat-sheet #'help-quick)
> +(defalias 'cheat-sheet #'help-quick-wrapper)
>
> (defun help-quit ()
> "Just exit from the Help command's command loop."
> --
> 2.30.2
>
>
>
> JD Smith <jdtsmith@gmail.com> writes:
>
>> Also recall we had a discussion in bug#68236
>> <https://lists.gnu.org/archive/html/bug-gnu-emacs/2024-01/msg00124.html>
>> about expanding quick-help to include mode-local
>> personalized binding shortcuts (with org as a particular target of interest).
>
> Thank you for the link I haven't seen that topic.
>
> Regards,
--
Philip Kaludercic on icterid
^ permalink raw reply [relevance 89%]
* Re: GNU ELPA announcements - e.g.: [GNU ELPA] Csv-Mode version 1.23
@ 2024-03-31 16:40 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-03-31 16:40 UTC (permalink / raw)
To: Drew Adams; +Cc: help-gnu-emacs@gnu.org, gnu-emacs-sources@gnu.org, nil
Drew Adams <drew.adams@oracle.com> writes:
> Why is emacs-devel now a destination for such
> announcements? If gnu-emacs-sources@gnu.org
> isn't deemed enough for some reason, wouldn't
> info-gnu-emacs@gnu.org be more appropriate?
The email is sent to the maintainer, and csv-mode indicates that this
list is responsible for maintenance.
--
Philip Kaludercic on icterid
^ permalink raw reply [relevance 99%]
* Re: Hundreds of ELPA packages updated today?
@ 2024-03-31 11:49 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-03-31 11:49 UTC (permalink / raw)
To: Romain Francoise; +Cc: emacs-devel
Romain Francoise <romain@rfr.sh> writes:
> Hi,
>
> gnu-emacs-sources received a few hundred update notifications for ELPA
> packages this morning, and in the web interface their latest version is
> indeed dated 2024-Mar-31.
>
> Glitch in the system, or is something nefarious going on?
I am not quite sure, but one reason might have been the recent addition
of Atom feeds for package updates to elpa-admin.el, which have now been
generated for all packages.
--
Philip Kaludercic on icterid
^ permalink raw reply [relevance 99%]
* Re: Where should security issues with GNU ELPA packages be reported?
@ 2024-03-29 5:53 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-03-29 5:53 UTC (permalink / raw)
To: Morgan Willcock; +Cc: emacs-devel
Morgan Willcock <morgan@ice9.digital> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Morgan Willcock <morgan@ice9.digital> writes:
>>
>>> I think I have found a security issue with a package which is
>>> distributed on GNU ELPA, and I am unsure who to notify.
>>>
>>> Given that the package is technically part of Emacs, do I follow
>>> whatever the procedure would be for disclosing security problems with
>>> Emacs? If so, what is that procedure?
>>>
>>> Or should I e-mail the package author first?
>>>
>>> Given that it is not the package author who is distributing the package,
>>> I am unsure what to do.
>>
>> It would probably be better to message the maintainer first, if there is
>> no explicit maintainer you can check elpa.git to infer who is
>> responsible.
>
> There is an e-mail address for the maintainer, I just wasn't sure
> whether going to them first was the correct thing to do.
The maintainer of the package can generally push changes to their own
repository and can trigger a new package to be built. If they do not
respond and it is urgent, anyone with access to elpa.git could push a
commit to the mirror (forking from upstream).
>> Can you disclose what package you are concerned about?
>
> I was not planning on naming it until after I had spoken privately to
> whoever the appropriate person is. The problem concerns an encryption
> failure which potentially exposes private security keys.
Ok, understandable.
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 99%]
* Re: Where should security issues with GNU ELPA packages be reported?
@ 2024-03-28 16:07 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-03-28 16:07 UTC (permalink / raw)
To: Morgan Willcock; +Cc: emacs-devel
Morgan Willcock <morgan@ice9.digital> writes:
> I think I have found a security issue with a package which is
> distributed on GNU ELPA, and I am unsure who to notify.
>
> Given that the package is technically part of Emacs, do I follow
> whatever the procedure would be for disclosing security problems with
> Emacs? If so, what is that procedure?
>
> Or should I e-mail the package author first?
>
> Given that it is not the package author who is distributing the package,
> I am unsure what to do.
It would probably be better to message the maintainer first, if there is
no explicit maintainer you can check elpa.git to infer who is
responsible. Can you disclose what package you are concerned about?
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 99%]
* Re: recursion to iteration macro
@ 2024-03-23 7:12 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-03-23 7:12 UTC (permalink / raw)
To: emacs-devel
Emanuel Berg <incal@dataswamp.org> writes:
> Did anyone try to write a macro or by using some other method
> to translate arbitrary use of recursion into functionally
> equivalent code that is iteration only?
>
> I read [1] this is theoretically possible and that seems
> reasonable as well, as with loops, local functions etc you
> have everything you need to implement it.
At least for tail-call recursion, named-let will turn recursive code
into iterative code.
But generally speaking, if you need to accumulate data on the stack,
then it becomes a lot more difficult.
> You can even have an expanding data structure, e.g. a list, to
> implement a virtual stack, still all within the one function,
> if you are fond of it.
>
> With execution all advantages should be with iteration but
> sometimes recursion makes for compact, elegant code that can
> also be more intuitive, more fun to write.
>
> Recursion is not so common, in part for this exact reason, but
> if we had this, maybe we would see a little recursion
> renaissance and proliferation?
>
> The best of both worlds anyone? You _will_ be assimilated!
>
> [1] https://en.wikipedia.org/wiki/Recursion_(computer_science)
> https://stackoverflow.com/questions/931762/can-every-recursion-be-converted-into-iteration
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 99%]
* Re: error when trying to a install a recent (2.24) seq version via the package system
@ 2024-03-22 16:30 96% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-03-22 16:30 UTC (permalink / raw)
To: emacs-devel
Uwe Brauer via "Emacs development discussions." <emacs-devel@gnu.org>
writes:
> Hi
>
>
> I am running emacs, master commit 7bf17ceee8c2d347917541e143ce25609e90ebbb
> I tried to install a newer version of seq via the package system, but I
> obtained an error that I attach.
>
> What is wrong?
>
> Regards
>
> Uwe Brauer
--8<---------------cut here---------------start------------->8---
(if (version< emacs-version "25") (require 'seq-24) (require 'seq-25))
eval-buffer(#<buffer *load*> nil "/home/oub/.emacs.d/elpa/seq-2.24/seq.el" nil t) ; Reading at buffer position 1779
load-with-code-conversion("/home/oub/.emacs.d/elpa/seq-2.24/seq.el" "/home/oub/.emacs.d/elpa/seq-2.24/seq.el" nil t)
--8<---------------cut here---------------end--------------->8---
What are the directory contents of /home/oub/.emacs.d/elpa/seq-2.24/?
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 96%]
* Re: Incorporate package macrostep into Emacs core
@ 2024-03-19 9:33 98% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-03-19 9:33 UTC (permalink / raw)
To: Gerd Möllmann
Cc: Jeremy Bryant, Jeremy Bryant via Emacs development discussions.,
Eli Zaretskii, monnier, j.j.oddie, stefankangas, jonas
Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>>
>>> Philip Kaludercic <philipk@posteo.net> writes:
>>>
>>>>> (add-hook 'c-mode-hook #'macrostep-c-mode-hook)
>>>>
>>>> This part is suspicious. First of all, it looks like one is adding a
>>>> hook to a hook, but this would unconditionally modify
>>>> c-mode-hook, which I don't think is reliable. Can we find some other
>>>> way to update the variables, depending on the major mode? E.g. in
>>>> macrostep.el one could try to intern (format "macrostep-%s-init"
>>>> major-mode) and check if the symbol is fboundp?
>>>
>>> Also, it would be nice to support C++ and Objc, which we have in Emacs
>>> (c-mode-common-hook).
>>
>> From what I understand, this feature is based on cmacexp, which in turn
>> just uses cpp.
>
> What's the problem using cpp?
I don't know what Objc does, but in the case of C++ my understanding was
that for example Templates were not expanded by C++. Of course, if that
is not the intention, then never mind my comment.
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 98%]
* Re: Incorporate package macrostep into Emacs core
@ 2024-03-19 7:26 95% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-03-19 7:26 UTC (permalink / raw)
To: Gerd Möllmann
Cc: Jeremy Bryant, Jeremy Bryant via Emacs development discussions.,
Eli Zaretskii, monnier, j.j.oddie, stefankangas, jonas
Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>>> (add-hook 'c-mode-hook #'macrostep-c-mode-hook)
>>
>> This part is suspicious. First of all, it looks like one is adding a
>> hook to a hook, but this would unconditionally modify
>> c-mode-hook, which I don't think is reliable. Can we find some other
>> way to update the variables, depending on the major mode? E.g. in
>> macrostep.el one could try to intern (format "macrostep-%s-init"
>> major-mode) and check if the symbol is fboundp?
>
> Also, it would be nice to support C++ and Objc, which we have in Emacs
> (c-mode-common-hook).
From what I understand, this feature is based on cmacexp, which in turn
just uses cpp. If something like this feature should be supported for
C++ and Objc, then the functionality should first be added to cmacexp or
something analogous (as it is my understanding that this is currently
not the case).
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 95%]
* Re: Incorporate package macrostep into Emacs core
@ 2024-03-19 6:36 85% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-03-19 6:36 UTC (permalink / raw)
To: Jeremy Bryant
Cc: Jeremy Bryant via Emacs development discussions., Eli Zaretskii,
monnier, j.j.oddie, stefankangas, jonas
Jeremy Bryant <jb@jeremybryant.net> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
> Philip,
> Thanks for all the comments on the macrostep.el code, I'll work on what
> I can.
>
>> Isn't there also a C-preprecossor implementation for macrostep? Would
>> the plan be to include that as well?
>
> Presumably, also. Any comments on macrostep-c.el (attached)?
>
> ;;; macrostep-c.el --- macrostep interface to C preprocessor -*- lexical-binding: t; -*-
>
> ;; Copyright (C) 2015 Jon Oddie
If included, then this should be updated.
> ;; Author: Jon Oddie <j.j.oddie@gmail.com>
> ;; Url: https://github.com/emacsorphanage/macrostep
And this removed.
> ;; Keywords: c, languages, macro, debugging
>
> ;; SPDX-License-Identifier: GPL-3.0-or-later
>
> ;; This file is free software: you can redistribute it and/or modify
> ;; it under the terms of the GNU General Public License as published
> ;; by the Free Software Foundation, either version 3 of the License,
> ;; or (at your option) any later version.
> ;;
> ;; This file is distributed in the hope that it will be useful,
> ;; but WITHOUT ANY WARRANTY; without even the implied warranty of
> ;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> ;; GNU General Public License for more details.
> ;;
> ;; You should have received a copy of the GNU General Public License
> ;; along with this file. If not, see <https://www.gnu.org/licenses/>.
>
> ;;; Commentary:
>
> ;; A thin wrapper around Emacs's built-in `cmacexp' library to provide
> ;; basic support for expanding C macros using the `macrostep' user
> ;; interface. To use, position point on a macro use in a C buffer and
> ;; type `M-x macrostep-expand'. The variables `c-macro-preprocessor'
> ;; and especially `c-macro-cppflags' may need to be set correctly for
> ;; accurate expansion.
>
> ;; This is fairly basic compared to the Emacs Lisp `macrostep'. In
> ;; particular, there is no step-by-step expansion, since C macros are
> ;; expanded in a single "cpp" pass, and no pretty-printing.
>
> ;; To hide the buffer containing "cpp" warnings (not recommended), you
> ;; could do something like:
> ;;
> ;; (push `(,(regexp-quote macrostep-c-warning-buffer)
> ;; (display-buffer-no-window))
> ;; display-buffer-alist)
>
> ;;; Code:
>
> (require 'macrostep)
> (require 'cmacexp)
> (require 'cl-lib)
>
> (require 'subr-x nil t)
> (defalias 'macrostep-c-string-trim
> (if (fboundp 'string-trim)
> #'string-trim
> (lambda (string)
> (when (string-match "\\`[ \t\n\r]+" string)
> (setq string (replace-match "" t t string)))
> (when (string-match "[ \t\n\r]+\\'" string)
> (setq string (replace-match "" t t string)))
> string)))
We can drop this (or use Compat to provide the function if the package
is distributeted on ELPA).
> (put 'macrostep-c-non-macro 'error-conditions
> '(macrostep-c-non-macro error))
> (put 'macrostep-c-non-macro 'error-message
> "Text around point is not a macro call.")
>
> (put 'macrostep-c-expansion-failed 'error-conditions
> '(macrostep-c-expansion-failed error))
> (put 'macrostep-c-expansion-failed 'error-message
> "Macro-expansion failed.")
>
> (defvar macrostep-c-warning-buffer "*Macroexpansion Warnings*")
>
> ;;;###autoload
> (defun macrostep-c-mode-hook ()
> (setq macrostep-sexp-bounds-function
> #'macrostep-c-sexp-bounds)
> (setq macrostep-sexp-at-point-function
> #'macrostep-c-sexp-at-point)
> (setq macrostep-environment-at-point-function
> #'ignore)
> (setq macrostep-expand-1-function
> #'macrostep-c-expand-1)
> (setq macrostep-print-function
> #'macrostep-c-print-function)
> (add-hook 'macrostep-mode-off-hook
> #'macrostep-c-mode-off nil t))
>
> (defun macrostep-c-mode-off (&rest _ignore)
> (when (derived-mode-p 'c-mode)
> (let ((warning-window
> (get-buffer-window macrostep-c-warning-buffer)))
> (when warning-window
> (quit-window nil warning-window)))))
>
> ;;;###autoload
> (add-hook 'c-mode-hook #'macrostep-c-mode-hook)
This part is suspicious. First of all, it looks like one is adding a
hook to a hook, but this would unconditionally modify
c-mode-hook, which I don't think is reliable. Can we find some other
way to update the variables, depending on the major mode? E.g. in
macrostep.el one could try to intern (format "macrostep-%s-init"
major-mode) and check if the symbol is fboundp?
> (defun macrostep-c-sexp-bounds ()
> (save-excursion
> (cl-loop
> (let ((region (macrostep-c-sexp-bounds-1)))
> (cond
> ((null region)
> (signal 'macrostep-c-non-macro nil))
> ((macrostep-c-expandable-p region)
> (cl-return region))
> (t
> (condition-case nil
> (progn
> (backward-up-list)
> (skip-syntax-backward "-"))
> (scan-error
> (signal 'macrostep-c-non-macro nil)))))))))
>
> (defun macrostep-c-sexp-bounds-1 ()
> (let ((region (bounds-of-thing-at-point 'symbol)))
> (when region
One could use when-let* in places like this.
> (cl-destructuring-bind (symbol-start . symbol-end) region
> (save-excursion
> (goto-char symbol-end)
> (if (looking-at "[[:space:]]*(")
> (cons symbol-start (scan-sexps symbol-end 1))
> region))))))
The indentation is off here, right? Might be worth reindenting
everything once.
>
> (defun macrostep-c-expandable-p (region)
> (cl-destructuring-bind (start . end) region
> (condition-case nil
> (cl-destructuring-bind (expansion _warnings)
> (macrostep-c-expand-region start end)
> (and (cl-plusp (length expansion))
> (not (string= expansion (buffer-substring start end)))))
> (macrostep-c-expansion-failed nil))))
>
> (defun macrostep-c-sexp-at-point (start end)
> (cons start end))
>
> (defun macrostep-c-expand-1 (region _ignore)
> (cl-destructuring-bind (start . end) region
> (cl-destructuring-bind (expansion warnings)
> (macrostep-c-expand-region start end)
> (when (cl-plusp (length warnings))
> (with-current-buffer
> (get-buffer-create macrostep-c-warning-buffer)
> (let ((inhibit-read-only t))
> (erase-buffer)
> (insert warnings)
> (goto-char (point-min)))
> (special-mode)
> (display-buffer (current-buffer)
> '(display-buffer-pop-up-window
> (inhibit-same-window . t)
> (allow-no-window . t)))))
> expansion)))
>
> (defun macrostep-c-expand-region (start end)
> (let ((expansion
> (condition-case nil
> (c-macro-expansion start end
> (concat c-macro-preprocessor " "
> c-macro-cppflags))
> (search-failed
> (signal 'macrostep-c-expansion-failed nil)))))
> (with-temp-buffer
> (save-excursion
> (insert expansion))
> (when (looking-at (regexp-quote "/*"))
> (search-forward "*/"))
> (let ((warnings (buffer-substring (point-min) (point)))
> (expansion (buffer-substring (point) (point-max))))
> (mapcar #'macrostep-c-string-trim (list expansion warnings))))))
>
> (defun macrostep-c-print-function (expansion &rest _ignore)
> (with-temp-buffer
> (insert expansion)
> (let ((exit-code
> (shell-command-on-region (point-min) (point-max) "indent" nil t)))
When calling indent, it might be nice to provide an option for optional
flags, in case someone prefers some other indentation scheme.
> (when (zerop exit-code)
> (setq expansion (macrostep-c-string-trim (buffer-string))))))
> (insert expansion))
>
> (provide 'macrostep-c)
>
> ;;; macrostep-c.el ends here
>
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 85%]
* Re: Incorporate package macrostep into Emacs core
@ 2024-03-18 9:09 86% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-03-18 9:09 UTC (permalink / raw)
To: Jeremy Bryant via Emacs development discussions.
Cc: Eli Zaretskii, Jeremy Bryant, monnier, j.j.oddie, stefan,
stefankangas, jonas
Jeremy Bryant via "Emacs development discussions." <emacs-devel@gnu.org>
writes:
>>>> Given that macrostep is useful for Emacs Lisp macro development, would
>>>> there be interest to include in Emacs core?
>>>
>>> Sounds useful, so I'm in favor.
>>
>> OK, I will continue to work towards it.
>
> Eli, Stefan,
>
> As I wait for the FSF paperwork to be completed for several
> contributors:
>
> Manual?
> Should the documentation for macrostep be included in the Emacs Lisp
> manual section Macros? Or a more suitable location? I volunteer to
> write the manual sections.
>
> Code?
> The main file is attached for convenience, from the orphanage upstream
> (https://github.com/emacsorphanage/macrostep).
> Are any changes needed before this is merged into Emacs?
> I volunteer to write some code towards this, please let me know.
I have a few comments:
>
> ;;; macrostep.el --- Interactive macro expander -*- lexical-binding: t; -*-
>
> ;; Copyright (C) 2012-2015 Jon Oddie
> ;; Copyright (C) 2020-2023 Free Software Foundation, Inc.
I guess this should be updated until 2024.
> ;; Author: Jon Oddie <j.j.oddie@gmail.com>
> ;; Url: https://github.com/emacsorphanage/macrostep
> ;; Keywords: lisp, languages, macro, debugging
>
> ;; Package-Version: 0.9.2
> ;; Package-Requires: ((cl-lib "0.5"))
>
> ;; SPDX-License-Identifier: GPL-3.0-or-later
>
> ;; This file is free software: you can redistribute it and/or modify
> ;; it under the terms of the GNU General Public License as published
> ;; by the Free Software Foundation, either version 3 of the License,
> ;; or (at your option) any later version.
> ;;
> ;; This file is distributed in the hope that it will be useful,
> ;; but WITHOUT ANY WARRANTY; without even the implied warranty of
> ;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> ;; GNU General Public License for more details.
> ;;
> ;; You should have received a copy of the GNU General Public License
> ;; along with this file. If not, see <https://www.gnu.org/licenses/>.
>
> ;;; Commentary:
>
> ;; `macrostep' is an Emacs minor mode for interactively stepping through
> ;; the expansion of macros in Emacs Lisp source code. It lets you see
> ;; exactly what happens at each step of the expansion process by
> ;; pretty-printing the expanded forms inline in the source buffer, which is
> ;; temporarily read-only while macro expansions are visible. You can
> ;; expand and collapse macro forms one step at a time, and evaluate or
> ;; instrument the expansions for debugging with Edebug as normal (but see
> ;; "Bugs and known limitations", below). Single-stepping through the
> ;; expansion is particularly useful for debugging macros that expand into
> ;; another macro form. These can be difficult to debug with Emacs'
> ;; built-in `macroexpand', which continues expansion until the top-level
> ;; form is no longer a macro call.
>
> ;; Both globally-visible macros as defined by `defmacro' and local macros
> ;; bound by `(cl-)macrolet' or another macro-defining form can be expanded.
> ;; Within macro expansions, calls to macros and compiler macros are
> ;; fontified specially: macro forms using `macrostep-macro-face', and
> ;; functions with compiler macros using `macrostep-compiler-macro-face'.
> ;; Uninterned symbols (gensyms) are fontified based on which step in the
> ;; expansion created them, to distinguish them both from normal symbols and
> ;; from other gensyms with the same print name.
>
> ;; As of version 0.9, it is also possible to extend `macrostep' to work
> ;; with other languages with macro systems in addition to Emacs Lisp. An
> ;; extension for Common Lisp (via SLIME) is in the works; contributions for
> ;; other languages are welcome. See "Extending macrostep" below for
> ;; details.
>
>
> ;; 1 Key-bindings and usage
> ;; ========================
>
> ;; The standard keybindings in `macrostep-mode' are the following:
>
> ;; e, =, RET : expand the macro form following point one step
> ;; c, u, DEL : collapse the form following point
> ;; q, C-c C-c: collapse all expanded forms and exit macrostep-mode
> ;; n, TAB : jump to the next macro form in the expansion
> ;; p, M-TAB : jump to the previous macro form in the expansion
>
> ;; It's not very useful to enable and disable macrostep-mode directly.
> ;; Instead, bind `macrostep-expand' to a key in `emacs-lisp-mode-map',
> ;; for example C-c e:
>
> ;; ,----
> ;; | (define-key emacs-lisp-mode-map (kbd "C-c e") 'macrostep-expand)
> ;; `----
>
> ;; You can then enter macrostep-mode and expand a macro form completely
> ;; by typing `C-c e e e ...' as many times as necessary.
>
> ;; Exit macrostep-mode by typing `q' or `C-c C-c', or by successively
> ;; typing `c' to collapse all surrounding expansions.
>
>
> ;; 2 Customization options
> ;; =======================
>
> ;; Type `M-x customize-group RET macrostep RET' to customize options and
> ;; faces.
>
> ;; To display macro expansions in a separate window, instead of inline in
> ;; the source buffer, customize `macrostep-expand-in-separate-buffer' to
> ;; `t'. The default is `nil'. Whichever default behavior is selected,
> ;; the alternative behavior can be obtained temporarily by giving a
> ;; prefix argument to `macrostep-expand'.
>
> ;; To have `macrostep' ignore compiler macros, customize
> ;; `macrostep-expand-compiler-macros' to `nil'. The default is `t'.
>
> ;; Customize the faces `macrostep-macro-face',
> ;; `macrostep-compiler-macro-face', and `macrostep-gensym-1' through
> ;; `macrostep-gensym-5' to alter the appearance of macro expansions.
>
>
> ;; 3 Locally-bound macros
> ;; ======================
>
> ;; As of version 0.9, `macrostep' can expand calls to a locally-bound
> ;; macro, whether defined by a surrounding `(cl-)macrolet' form, or by
> ;; another macro-defining macro. In other words, it is possible to
> ;; expand the inner `local-macro' forms in both the following examples,
> ;; whether `local-macro' is defined by an enclosing `cl-macrolet' --
>
> ;; ,----
> ;; | (cl-macrolet ((local-macro (&rest args)
> ;; | `(expansion of ,args)))
> ;; | (local-macro (do-something)))
> ;; `----
>
> ;; -- or by a macro which expands into `cl-macrolet', provided that its
> ;; definition of macro is evaluated prior to calling `macrostep-expand':
>
> ;; ,----
> ;; | (defmacro with-local-macro (&rest body)
> ;; | `(cl-macrolet ((local-macro (&rest args)
> ;; | `(expansion of ,args)))
> ;; | ,@body))
> ;; |
> ;; | (with-local-macro
> ;; | (local-macro (do something (else)))
> ;; `----
>
> ;; See the `with-js' macro in Emacs's `js.el' for a real example of the
> ;; latter kind of macro.
>
> ;; Expansion of locally-bound macros is implemented by instrumenting
> ;; Emacs Lisp's macro-expander to capture the environment at point. A
> ;; similar trick is used to detect macro- and compiler-macro calls within
> ;; expanded text so that they can be fontified accurately.
>
>
> ;; 4 Expanding sub-forms
> ;; =====================
>
> ;; By moving point around in the macro expansion using
> ;; `macrostep-next-macro' and `macrostep-prev-macro' (bound to the `n'
> ;; and `p' keys), it is possible to expand other macro calls within the
> ;; expansion before expanding the outermost form. This can sometimes be
> ;; useful, although it does not correspond to the real order of macro
> ;; expansion in Emacs Lisp, which proceeds by fully expanding the outer
> ;; form to a non-macro form before expanding sub-forms.
>
> ;; The main reason to expand sub-forms out of order is to help with
> ;; debugging macros which programmatically expand their arguments in
> ;; order to rewrite them. Expanding the arguments of such a macro lets
> ;; you visualise what the macro definition would compute via
> ;; `macroexpand-all'.
>
>
> ;; 5 Extending macrostep for other languages
> ;; =========================================
>
> ;; Since version 0.9, it is possible to extend macrostep to work with
> ;; other languages besides Emacs Lisp. In typical Emacs fashion, this is
> ;; implemented by setting buffer-local variables to different function
> ;; values. Six buffer-local variables define the language-specific part
> ;; of the implementation:
>
> ;; - `macrostep-sexp-bounds-function'
> ;; - `macrostep-sexp-at-point-function'
> ;; - `macrostep-environment-at-point-function'
> ;; - `macrostep-expand-1-function'
> ;; - `macrostep-print-function'
> ;; - `macrostep-macro-form-p-function'
>
> ;; Typically, an implementation for another language would set these
> ;; variables in a major-mode hook. See the docstrings of each variable
> ;; for details on how each one is called and what it should return. At a
> ;; minimum, another language implementation needs to provide
> ;; `macrostep-sexp-at-point-function', `macrostep-expand-1-function', and
> ;; `macrostep-print-function'. Lisp-like languages may be able to reuse
> ;; the default `macrostep-sexp-bounds-function' if they provide another
> ;; implementation of `macrostep-macro-form-p-function'. Languages which
> ;; do not implement locally-defined macros can set
> ;; `macrostep-environment-at-point-function' to `ignore'.
>
> ;; Note that the core `macrostep' machinery only interprets the return
> ;; value of `macrostep-sexp-bounds-function', so implementations for
> ;; other languages can use any internal representations of code and
> ;; environments which is convenient. Although the terminology is
> ;; Lisp-specific, there is no reason that implementations could not be
> ;; provided for non-Lisp languages with macro systems, provided there is
> ;; some way of identifying macro calls and calling the compiler /
> ;; preprocessor to obtain their expansions.
>
>
> ;; 6 Bugs and known limitations
> ;; ============================
>
> ;; You can evaluate and edebug macro-expanded forms and step through the
> ;; macro-expanded version, but the form that `eval-defun' and friends
> ;; read from the buffer won't have the uninterned symbols of the real
> ;; macro expansion. This will probably work OK with CL-style gensyms,
> ;; but may cause problems with `make-symbol' symbols if they have the
> ;; same print name as another symbol in the expansion. It's possible that
> ;; using `print-circle' and `print-gensym' could get around this.
>
> ;; Please send other bug reports and feature requests to the author.
>
>
> ;; 7 Acknowledgements
> ;; ==================
>
> ;; Thanks to:
> ;; - John Wiegley for fixing a bug with the face definitions under Emacs
> ;; 24 & for plugging macrostep in his [EmacsConf presentation]!
> ;; - George Kettleborough for bug reports, and patches to highlight the
> ;; expanded region and properly handle backquotes.
> ;; - Nic Ferrier for suggesting support for local definitions within
> ;; macrolet forms
> ;; - Luís Oliveira for suggesting and implementing SLIME support
>
> ;; `macrostep' was originally inspired by J. V. Toups's 'Deep Emacs Lisp'
> ;; articles ([part 1], [part 2], [screencast]).
>
> ;; [EmacsConf presentation] http://youtu.be/RvPFZL6NJNQ
>
> ;; [part 1]
> ;; http://dorophone.blogspot.co.uk/2011/04/deep-emacs-part-1.html
>
> ;; [part 2]
> ;; http://dorophone.blogspot.co.uk/2011/04/deep-emacs-lisp-part-2.html
>
> ;; [screencast]
> ;; http://dorophone.blogspot.co.uk/2011/05/monadic-parser-combinators-in-elisp.html
>
>
> ;; 8 Changelog
> ;; ===========
It would be better to convert this into a "News" section so that ELPA
can pick out the changelog.
> ;; - v0.9.2, 2023-05-12:
> ;; - name the keymap macrostep-mode-map, fixing a regression in v0.9.1
> ;; - v0.9.1, 2023-03-12:
> ;; - bug fixes, cleanup and modernization
> ;; - v0.9, 2015-10-01:
> ;; - separate into Elisp-specific and generic components
> ;; - highlight and expand compiler macros
> ;; - improve local macro expansion and macro form identification by
> ;; instrumenting `macroexpand(-all)'
> ;; - v0.8, 2014-05-29: fix a bug with printing the first element of lists
> ;; - v0.7, 2014-05-11: expand locally-defined macros within
> ;; `(cl-)macrolet' forms
> ;; - v0.6, 2013-05-04: better handling of quote and backquote
> ;; - v0.5, 2013-04-16: highlight region, maintain cleaner buffer state
> ;; - v0.4, 2013-04-07: only enter macrostep-mode on successful
> ;; macro-expansion
> ;; - v0.3, 2012-10-30: print dotted lists correctly. autoload
> ;; definitions.
>
> ;;; Code:
>
> (require 'pp)
> (require 'ring)
> (require 'cl-lib)
>
> \f
> ;;; Constants and dynamically bound variables
> (defvar macrostep-overlays nil
> "List of all macro stepper overlays in the current buffer.")
> (make-variable-buffer-local 'macrostep-overlays)
Here (and below) you can use defvar-local
> (defvar macrostep-gensym-depth nil
> "Number of macro expansion levels that have introduced gensyms so far.")
> (make-variable-buffer-local 'macrostep-gensym-depth)
>
> (defvar macrostep-gensyms-this-level nil
> "Non-nil if gensyms have been encountered during current level of macro expansion.")
> (make-variable-buffer-local 'macrostep-gensyms-this-level)
>
> (defvar macrostep-saved-undo-list nil
> "Saved value of `buffer-undo-list' upon entering macrostep mode.")
> (make-variable-buffer-local 'macrostep-saved-undo-list)
>
> (defvar macrostep-saved-read-only nil
> "Saved value of `buffer-read-only' upon entering macrostep mode.")
> (make-variable-buffer-local 'macrostep-saved-read-only)
>
> (defvar macrostep-expansion-buffer nil
> "Non-nil if the current buffer is a macro-expansion buffer.")
> (make-variable-buffer-local 'macrostep-expansion-buffer)
>
> (defvar macrostep-outer-environment nil
> "Outermost macro-expansion environment to use in macro-expansion buffers.
>
> This variable is used to save information about any enclosing
> `cl-macrolet' context when a macro form is expanded in a separate
> buffer.")
> (make-variable-buffer-local 'macrostep-outer-environment)
>
> ;;; Customization options and faces
> (defgroup macrostep nil
> "Interactive macro stepper for Emacs Lisp."
> :group 'lisp
> :link '(emacs-commentary-link :tag "commentary" "macrostep.el")
> :link '(emacs-library-link :tag "lisp file" "macrostep.el")
> :link '(url-link :tag "web page" "https://github.com/joddie/macrostep"))
This URL seems out-of-date.
>
> (defface macrostep-gensym-1
> '((((min-colors 16581375)) :foreground "#8080c0" :box t :bold t)
> (((min-colors 8)) :background "cyan")
> (t :inverse-video t))
> "Face for gensyms created in the first level of macro expansion.")
>
> (defface macrostep-gensym-2
> '((((min-colors 16581375)) :foreground "#8fbc8f" :box t :bold t)
> (((min-colors 8)) :background "#00cd00")
> (t :inverse-video t))
> "Face for gensyms created in the second level of macro expansion.")
>
> (defface macrostep-gensym-3
> '((((min-colors 16581375)) :foreground "#daa520" :box t :bold t)
> (((min-colors 8)) :background "yellow")
> (t :inverse-video t))
> "Face for gensyms created in the third level of macro expansion.")
>
> (defface macrostep-gensym-4
> '((((min-colors 16581375)) :foreground "#cd5c5c" :box t :bold t)
> (((min-colors 8)) :background "red")
> (t :inverse-video t))
> "Face for gensyms created in the fourth level of macro expansion.")
>
> (defface macrostep-gensym-5
> '((((min-colors 16581375)) :foreground "#da70d6" :box t :bold t)
> (((min-colors 8)) :background "magenta")
> (t :inverse-video t))
> "Face for gensyms created in the fifth level of macro expansion.")
>
> (defface macrostep-expansion-highlight-face
> `((((min-colors 16581375) (background light))
> ,@(and (>= emacs-major-version 27) '(:extend t))
> :background "#eee8d5")
> (((min-colors 16581375) (background dark))
> ,@(and (>= emacs-major-version 27) '(:extend t))
Is there any harm in adding :extend before Emacs 27? Also, we won't
need the check in the core.
> :background "#222222"))
> "Face for macro-expansion highlight.")
>
> (defface macrostep-macro-face
> '((t :underline t))
> "Face for macros in macro-expanded code.")
>
> (defface macrostep-compiler-macro-face
> '((t :slant italic))
> "Face for compiler macros in macro-expanded code.")
>
> (defcustom macrostep-expand-in-separate-buffer nil
> "When non-nil, show expansions in a separate buffer instead of inline."
> :type 'boolean)
>
> (defcustom macrostep-expand-compiler-macros t
> "When non-nil, also expand compiler macros."
> :type 'boolean)
>
> ;; Need the following for making the ring of faces
> (defun macrostep-make-ring (&rest items)
> "Make a ring containing all of ITEMS with no empty slots."
> (let ((ring (make-ring (length items))))
> (mapc (lambda (item) (ring-insert ring item)) (reverse items))
> ring))
Isn't this `ring-convert-sequence-to-ring'?
>
> (defvar macrostep-gensym-faces
> (macrostep-make-ring
> 'macrostep-gensym-1 'macrostep-gensym-2 'macrostep-gensym-3
> 'macrostep-gensym-4 'macrostep-gensym-5)
> "Ring of all macrostepper faces for fontifying gensyms.")
>
> ;; Other modes can enable macrostep by redefining these functions to
> ;; language-specific versions.
> (defvar macrostep-sexp-bounds-function
> #'macrostep-sexp-bounds
> "Function to return the bounds of the macro form nearest point.
>
> It will be called with no arguments and should return a cons of
> buffer positions, (START . END). It should use `save-excursion'
> to avoid changing the position of point.
>
> The default value, `macrostep-sexp-bounds', implements this for
> Emacs Lisp, and may be suitable for other Lisp-like languages.")
> (make-variable-buffer-local 'macrostep-sexp-bounds-function)
>
> (defvar macrostep-sexp-at-point-function
> #'macrostep-sexp-at-point
> "Function to return the macro form at point for expansion.
>
> It will be called with two arguments, the values of START and END
> returned by `macrostep-sexp-bounds-function', and with point
> positioned at START. It should return a value suitable for
> passing as the first argument to `macrostep-expand-1-function'.
>
> The default value, `macrostep-sexp-at-point', implements this for
> Emacs Lisp, and may be suitable for other Lisp-like languages.")
> (make-variable-buffer-local 'macrostep-sexp-at-point-function)
>
> (defvar macrostep-environment-at-point-function
> #'macrostep-environment-at-point
> "Function to return the local macro-expansion environment at point.
>
> It will be called with no arguments, and should return a value
> suitable for passing as the second argument to
> `macrostep-expand-1-function'.
>
> The default value, `macrostep-environment-at-point', is specific
> to Emacs Lisp. For languages which do not implement local
> macro-expansion environments, this should be set to `ignore'
> or `(lambda () nil)'.")
> (make-variable-buffer-local 'macrostep-environment-at-point-function)
>
> (defvar macrostep-expand-1-function
> #'macrostep-expand-1
> "Function to perform one step of macro-expansion.
>
> It will be called with two arguments, FORM and ENVIRONMENT, the
> return values of `macrostep-sexp-at-point-function' and
> `macrostep-environment-at-point-function' respectively. It
> should return the result of expanding FORM by one step as a value
> which is suitable for passing as the argument to
> `macrostep-print-function'.
>
> The default value, `macrostep-expand-1', is specific to Emacs Lisp.")
> (make-variable-buffer-local 'macrostep-expand-1-function)
>
> (defvar macrostep-print-function
> #'macrostep-pp
> "Function to pretty-print macro expansions.
>
> It will be called with two arguments, FORM and ENVIRONMENT, the
> return values of `macrostep-sexp-at-point-function' and
> `macrostep-environment-at-point-function' respectively. It
> should insert a pretty-printed representation at point in the
> current buffer, leaving point just after the inserted
> representation, without altering any other text in the current
> buffer.
>
> The default value, `macrostep-pp', is specific to Emacs Lisp.")
> (make-variable-buffer-local 'macrostep-print-function)
>
> (defvar macrostep-macro-form-p-function
> #'macrostep-macro-form-p
> "Function to check whether a form is a macro call.
>
> It will be called with two arguments, FORM and ENVIRONMENT -- the
> return values of `macrostep-sexp-at-point-function' and
> `macrostep-environment-at-point-function' respectively -- and
> should return non-nil if FORM would undergo macro-expansion in
> ENVIRONMENT.
>
> This is called only from `macrostep-sexp-bounds', so it need not
> be provided if a different value is used for
> `macrostep-sexp-bounds-function'.
>
> The default value, `macrostep-macro-form-p', is specific to Emacs Lisp.")
> (make-variable-buffer-local 'macrostep-macro-form-p-function)
>
> \f
> ;;; Define keymap and minor mode
> (define-obsolete-variable-alias 'macrostep-mode-keymap 'macrostep-mode-map "2023")
> (define-obsolete-variable-alias 'macrostep-keymap 'macrostep-mode-map "2022")
> (defvar macrostep-mode-map
> (let ((map (make-sparse-keymap)))
> (define-key map (kbd "RET") #'macrostep-expand)
> (define-key map "=" #'macrostep-expand)
> (define-key map "e" #'macrostep-expand)
>
> (define-key map (kbd "DEL") #'macrostep-collapse)
> (define-key map "u" #'macrostep-collapse)
> (define-key map "c" #'macrostep-collapse)
>
> (define-key map (kbd "TAB") #'macrostep-next-macro)
> (define-key map "n" #'macrostep-next-macro)
> (define-key map (kbd "M-TAB") #'macrostep-prev-macro)
> (define-key map "p" #'macrostep-prev-macro)
>
> (define-key map "q" #'macrostep-collapse-all)
> (define-key map (kbd "C-c C-c") #'macrostep-collapse-all)
> map)
> "Keymap for `macrostep-mode'.")
This could be converted to defvar-keymap.
> ;;;###autoload
> (define-minor-mode macrostep-mode
> "Minor mode for inline expansion of macros in Emacs Lisp source buffers.
>
> \\<macrostep-mode-map>Progressively expand macro forms with \
> \\[macrostep-expand], collapse them with \\[macrostep-collapse],
> and move back and forth with \\[macrostep-next-macro] and \
> \\[macrostep-prev-macro]. Use \\[macrostep-collapse-all] or collapse all
> visible expansions to quit and return to normal editing.
>
> \\{macrostep-mode-map}"
> :lighter " Macro-Stepper"
> :group 'macrostep
> (if macrostep-mode
> (progn
> ;; Disable recording of undo information
> (setq macrostep-saved-undo-list buffer-undo-list
> buffer-undo-list t)
> ;; Remember whether buffer was read-only
> (setq macrostep-saved-read-only buffer-read-only
> buffer-read-only t)
> ;; Set up post-command hook to bail out on leaving read-only
> (add-hook 'post-command-hook #'macrostep-command-hook nil t)
> (message (substitute-command-keys "\
> \\<macrostep-mode-map>Entering macro stepper mode. \
> Use \\[macrostep-expand] to expand, \\[macrostep-collapse] to collapse, \
> \\[macrostep-collapse-all] to exit.")))
>
> ;; Exiting mode
> (if macrostep-expansion-buffer
> ;; Kill dedicated expansion buffers
> (quit-window t)
> ;; Collapse any remaining overlays
> (when macrostep-overlays (macrostep-collapse-all))
> ;; Restore undo info & read-only state
> (setq buffer-undo-list macrostep-saved-undo-list
> buffer-read-only macrostep-saved-read-only
> macrostep-saved-undo-list nil)
> ;; Remove our post-command hook
> (remove-hook 'post-command-hook #'macrostep-command-hook t))))
>
> (defun macrostep-command-hook ()
> "Hook function for use by `post-command hook'.
> Bail out of `macrostep-mode' if the user types
> `\\[read-only-mode]' to make the buffer writable again."
> (if (not buffer-read-only)
> (macrostep-mode 0)))
>
> \f
> ;;; Interactive functions
> ;;;###autoload
> (defun macrostep-expand (&optional toggle-separate-buffer)
> "Expand the macro form following point by one step.
>
> Enters `macrostep-mode' if it is not already active, making the
> buffer temporarily read-only. If `macrostep-mode' is active and
> the form following point is not a macro form, search forward in
> the buffer and expand the next macro form found, if any.
>
> If optional argument TOGGLE-SEPARATE-BUFFER is non-nil (or set
> with a prefix argument), the expansion is displayed in a
> separate buffer instead of inline in the current buffer.
> Setting `macrostep-expand-in-separate-buffer' to non-nil swaps
> these two behaviors."
> (interactive "P")
> (cl-destructuring-bind (start . end)
> (funcall macrostep-sexp-bounds-function)
> (goto-char start)
> (let* ((sexp (funcall macrostep-sexp-at-point-function start end))
> (end (copy-marker end))
> (text (buffer-substring start end))
> (env (funcall macrostep-environment-at-point-function))
> (expansion (funcall macrostep-expand-1-function sexp env)))
>
> ;; Create a dedicated macro-expansion buffer and copy the text to
> ;; be expanded into it, if required
> (let ((separate-buffer-p
> (if toggle-separate-buffer
> (not macrostep-expand-in-separate-buffer)
> macrostep-expand-in-separate-buffer)))
> (when (and separate-buffer-p (not macrostep-expansion-buffer))
> (let ((mode major-mode)
> (buffer
> (get-buffer-create (generate-new-buffer-name "*macro expansion*"))))
> (set-buffer buffer)
Shouldn't this be a `with-current-buffer'?
> (funcall mode)
> (setq macrostep-expansion-buffer t)
> (setq macrostep-outer-environment env)
> (save-excursion
> (setq start (point))
> (insert text)
> (setq end (point-marker)))
> (pop-to-buffer buffer))))
>
> (unless macrostep-mode (macrostep-mode t))
> (let ((existing-overlay (macrostep-overlay-at-point))
> (macrostep-gensym-depth macrostep-gensym-depth)
> (macrostep-gensyms-this-level nil)
> priority)
> (if existing-overlay
> (progn ; Expanding part of a previous macro-expansion
> (setq priority (1+ (overlay-get existing-overlay 'priority)))
> (setq macrostep-gensym-depth
> (overlay-get existing-overlay 'macrostep-gensym-depth)))
Multiple `setq's can be merged into one, so the progn isn't necessary here.
> ;; Expanding source buffer text
> (setq priority 1)
> (setq macrostep-gensym-depth -1))
>
> (with-silent-modifications
> (atomic-change-group
> (let ((inhibit-read-only t))
> (save-excursion
> ;; Insert expansion
> (funcall macrostep-print-function expansion env)
> ;; Delete the original form
> (macrostep-collapse-overlays-in (point) end)
> (delete-region (point) end)
> ;; Create a new overlay
> (let* ((overlay
> (make-overlay start
> (if (looking-at "\n")
> (1+ (point))
> (point))))
> (highlight-overlay (unless macrostep-expansion-buffer
> (copy-overlay overlay))))
> (unless macrostep-expansion-buffer
> ;; Highlight the overlay in original source buffers only
> (overlay-put highlight-overlay 'face 'macrostep-expansion-highlight-face)
> (overlay-put highlight-overlay 'priority -1)
> (overlay-put overlay 'macrostep-highlight-overlay highlight-overlay))
> (overlay-put overlay 'priority priority)
> (overlay-put overlay 'macrostep-original-text text)
> (overlay-put overlay 'macrostep-gensym-depth macrostep-gensym-depth)
> (push overlay macrostep-overlays))))))))))
>
> (defun macrostep-collapse ()
> "Collapse the innermost macro expansion near point to its source text.
>
> If no more macro expansions are visible after this, exit
> `macrostep-mode'."
> (interactive)
> (let ((overlay (macrostep-overlay-at-point)))
> (when (not overlay) (error "No macro expansion at point"))
> (let ((inhibit-read-only t))
> (with-silent-modifications
> (atomic-change-group
> (macrostep-collapse-overlay overlay)))))
> (if (not macrostep-overlays)
Or `unless'
> (macrostep-mode 0)))
>
> (defun macrostep-collapse-all ()
> "Collapse all visible macro expansions and exit `macrostep-mode'."
> (interactive)
> (let ((inhibit-read-only t))
> (with-silent-modifications
> (dolist (overlay macrostep-overlays)
> (let ((outermost (= (overlay-get overlay 'priority) 1)))
> ;; We only need restore the original text for the outermost
> ;; overlays
> (macrostep-collapse-overlay overlay (not outermost))))))
> (setq macrostep-overlays nil)
> (macrostep-mode 0))
>
> (defun macrostep-next-macro ()
> "Move point forward to the next macro form in macro-expanded text."
> (interactive)
> (let* ((start (if (get-text-property (point) 'macrostep-macro-start)
> (1+ (point))
> (point)))
> (next (next-single-property-change start 'macrostep-macro-start)))
> (if next
> (goto-char next)
> (error "No more macro forms found"))))
>
> (defun macrostep-prev-macro ()
> "Move point back to the previous macro form in macro-expanded text."
> (interactive)
> (let (prev)
> (save-excursion
> (while
> (progn
> (setq prev (previous-single-property-change
> (point) 'macrostep-macro-start))
> (if (or (not prev)
> (get-text-property (1- prev) 'macrostep-macro-start))
> nil
> (prog1 t (goto-char prev))))))
> (if prev
> (goto-char (1- prev))
> (error "No previous macro form found"))))
>
> \f
> ;;; Utility functions (not language-specific)
>
> (defun macrostep-overlay-at-point ()
> "Return the innermost macro stepper overlay at point."
> (cdr (get-char-property-and-overlay (point) 'macrostep-original-text)))
>
> (defun macrostep-collapse-overlay (overlay &optional no-restore-p)
> "Collapse macro-expansion buffer OVERLAY and restore the unexpanded source text.
>
> As a minor optimization, does not restore the original source
> text if NO-RESTORE-P is non-nil. This is safe to do when
> collapsing all the sub-expansions of an outer overlay, since the
> outer overlay will restore the original source itself.
>
> Also removes the overlay from `macrostep-overlays'."
> (with-current-buffer (overlay-buffer overlay)
> ;; If we're cleaning up we don't need to bother restoring text
> ;; or checking for inner overlays to delete
> (unless no-restore-p
> (let* ((start (overlay-start overlay))
> (end (overlay-end overlay))
> (text (overlay-get overlay 'macrostep-original-text))
> (sexp-end
> (copy-marker
> (if (equal (char-before end) ?\n) (1- end) end))))
> (macrostep-collapse-overlays-in start end)
> (goto-char (overlay-start overlay))
> (save-excursion
> (insert text)
> (delete-region (point) sexp-end))))
> ;; Remove overlay from the list and delete it
> (setq macrostep-overlays
> (delq overlay macrostep-overlays))
> (let ((highlight-overlay (overlay-get overlay 'macrostep-highlight-overlay)))
> (when highlight-overlay (delete-overlay highlight-overlay)))
> (delete-overlay overlay)))
>
> (defun macrostep-collapse-overlays-in (start end)
> "Collapse all macrostepper overlays that are strictly between START and END.
>
> Will not collapse overlays that begin at START and end at END."
> (dolist (ol (overlays-in start end))
> (when (and (overlay-buffer ol) ; collapsing may delete other overlays
> (> (overlay-start ol) start)
> (< (overlay-end ol) end)
> (overlay-get ol 'macrostep-original-text))
> (macrostep-collapse-overlay ol t))))
>
> \f
> ;;; Emacs Lisp implementation
>
> (defun macrostep-sexp-bounds ()
> "Find the bounds of the macro form nearest point.
>
> If point is not before an open-paren, moves up to the nearest
> enclosing list. If the form at point is not a macro call,
> attempts to move forward to the next macro form as determined by
> `macrostep-macro-form-p-function'.
>
> Returns a cons of buffer positions, (START . END)."
> (save-excursion
> (if (not (looking-at "[(`]"))
> (backward-up-list 1))
> (if (equal (char-before) ?`)
> (backward-char))
> (let ((sexp (funcall macrostep-sexp-at-point-function))
> (env (funcall macrostep-environment-at-point-function)))
> ;; If this isn't a macro form, try to find the next one in the buffer
> (unless (funcall macrostep-macro-form-p-function sexp env)
> (condition-case nil
> (macrostep-next-macro)
> (error
> (if (consp sexp)
> (error "(%s ...) is not a macro form" (car sexp))
> (error "Text at point is not a macro form"))))))
> (cons (point) (scan-sexps (point) 1))))
>
> (defun macrostep-sexp-at-point (&rest _ignore)
> "Return the sexp near point for purposes of macro-stepper expansion.
>
> If the sexp near point is part of a macro expansion, returns the
> saved text of the macro expansion, and does not read from the
> buffer. This preserves uninterned symbols in the macro
> expansion, so that they can be fontified consistently. (See
> `macrostep-print-sexp'.)"
> (or (get-text-property (point) 'macrostep-expanded-text)
> (sexp-at-point)))
>
> (defun macrostep-macro-form-p (form environment)
> "Return non-nil if FORM would be evaluated via macro expansion;
> as considered within ENVIRONMENT.
>
> If FORM is an invocation of a macro defined by `defmacro' or an
> enclosing `cl-macrolet' form, return the symbol `macro'.
>
> If `macrostep-expand-compiler-macros' is non-nil and FORM is a
> call to a function with a compiler macro, return the symbol
> `compiler-macro'.
>
> Otherwise, return nil."
> (car (macrostep--macro-form-info form environment t)))
>
> (defun macrostep--macro-form-info (form environment &optional inhibit-autoload)
> "Return information about macro definitions that apply to FORM.
>
> If no macros are involved in the evaluation of FORM within
> ENVIRONMENT, returns nil. Otherwise, returns a cons (TYPE
> . DEFINITION).
>
> If FORM would be evaluated by a macro defined by `defmacro',
> `cl-macrolet', etc., TYPE is the symbol `macro' and DEFINITION is
> the macro definition, as a function.
>
> If `macrostep-expand-compiler-macros' is non-nil and FORM would
> be compiled using a compiler macro, TYPE is the symbol
> `compiler-macro' and DEFINITION is the function that implements
> the compiler macro.
>
> If FORM is an invocation of an autoloaded macro, the behavior
> depends on the value of INHIBIT-AUTOLOAD. If INHIBIT-AUTOLOAD is
> nil, the file containing the macro definition will be loaded
> using `load-library' and the macro definition returned as normal.
> If INHIBIT-AUTOLOAD is non-nil, no files will be loaded, and the
> value of DEFINITION in the result will be nil."
> (if (not (and (consp form)
> (symbolp (car form))))
> `(nil . nil)
> (let* ((head (car form))
> (local-definition (assoc-default head environment #'eq)))
> (if local-definition
> `(macro . ,local-definition)
> (let ((compiler-macro-definition
> (and macrostep-expand-compiler-macros
> (or (get head 'compiler-macro)
> (get head 'cl-compiler-macro)))))
> (if (and compiler-macro-definition
> (not (eq form
> (apply compiler-macro-definition form (cdr form)))))
> `(compiler-macro . ,compiler-macro-definition)
> (condition-case nil
> (let ((fun (indirect-function head)))
> (cl-case (car-safe fun)
> ((macro)
> `(macro . ,(cdr fun)))
> ((autoload)
> (when (memq (nth 4 fun) '(macro t))
> (if inhibit-autoload
> `(macro . nil)
> (load-library (nth 1 fun))
> (macrostep--macro-form-info form nil))))
> (t
> `(nil . nil))))
> (void-function nil))))))))
>
> (defun macrostep-expand-1 (form environment)
> "Return result of macro-expanding by exactly one step the top level of FORM.
> This is done within ENVIRONMENT.
>
> Unlike `macroexpand', this function does not continue macro
> expansion until a non-macro-call results."
> (cl-destructuring-bind (type . definition)
> (macrostep--macro-form-info form environment)
> (cl-ecase type
> ((nil)
> form)
> ((macro)
> (apply definition (cdr form)))
> ((compiler-macro)
> (let ((expansion (apply definition form (cdr form))))
> (if (equal form expansion)
> (error "Form left unchanged by compiler macro")
> expansion))))))
>
> (put 'macrostep-grab-environment-failed 'error-conditions
> '(macrostep-grab-environment-failed error))
>
> (defun macrostep-environment-at-point ()
> "Return the local macro-expansion environment at point, if any.
>
> The local environment includes macros declared by any `macrolet'
> or `cl-macrolet' forms surrounding point, as well as by any macro
> forms which expand into a `macrolet'.
>
> The return value is an alist of elements (NAME . FUNCTION), where
> NAME is the symbol locally bound to the macro and FUNCTION is the
> lambda expression that returns its expansion."
> ;; If point is on a macro form within an expansion inserted by
> ;; `macrostep-print-sexp', a local environment may have been
> ;; previously saved as a text property.
> (let ((saved-environment
> (get-text-property (point) 'macrostep-environment)))
> (if saved-environment
> saved-environment
> ;; Otherwise, we (ab)use the macro-expander to return the
> ;; environment at point. If point is not at an evaluated
> ;; position in the containing form,
> ;; `macrostep-environment-at-point-1' will raise an error, and
> ;; we back up progressively through the containing forms until
> ;; it succeeds.
> (save-excursion
> (catch 'done
> (while t
> (condition-case nil
> (throw 'done (macrostep-environment-at-point-1))
> (macrostep-grab-environment-failed
> (condition-case nil
> (backward-sexp)
> (scan-error (backward-up-list)))))))))))
>
> (defun macrostep-environment-at-point-1 ()
> "Attempt to extract the macro environment that would be active at point.
>
> If point is not at an evaluated position within the containing
> form, raise an error."
> ;; Macro environments are extracted using Emacs Lisp's builtin
> ;; macro-expansion machinery. The form containing point is copied
> ;; to a temporary buffer, and a call to
> ;; `--macrostep-grab-environment--' is inserted at point. This
> ;; altered form is then fully macro-expanded, in an environment
> ;; where `--macrostep-grab-environment--' is defined as a macro
> ;; which throws the environment to a uniquely-generated tag.
> (let* ((point-at-top-level
> (save-excursion
> (while (ignore-errors (backward-up-list) t))
> (point)))
> (enclosing-form
> (buffer-substring point-at-top-level
> (scan-sexps point-at-top-level 1)))
> (position (- (point) point-at-top-level))
> (tag (make-symbol "macrostep-grab-environment-tag"))
> (grab-environment '--macrostep-grab-environment--))
> (if (= position 0)
> nil
> (with-temp-buffer
> (emacs-lisp-mode)
> (insert enclosing-form)
> (goto-char (+ (point-min) position))
> (prin1 `(,grab-environment) (current-buffer))
> (let ((form (read (copy-marker (point-min)))))
> (catch tag
> (cl-letf (((symbol-function #'message) (symbol-function #'format)))
Is this supposed to be an `inhibit-message'?
> (with-no-warnings
> (ignore-errors
> (macroexpand-all
> `(cl-macrolet ((,grab-environment (&environment env)
> (throw ',tag env)))
> ,form)))))
> (signal 'macrostep-grab-environment-failed nil)))))))
>
> (defun macrostep-collect-macro-forms (form &optional environment)
> "Identify sub-forms of FORM which undergo macro-expansion.
>
> FORM is an Emacs Lisp form. ENVIRONMENT is a local environment of
> macro definitions.
>
> The return value is a list of two elements, (MACRO-FORM-ALIST
> COMPILER-MACRO-FORMS).
>
> MACRO-FORM-ALIST is an alist of elements of the form (SUBFORM
> . ENVIRONMENT), where SUBFORM is a form which undergoes
> macro-expansion in the course of expanding FORM, and ENVIRONMENT
> is the local macro environment in force when it is expanded.
>
> COMPILER-MACRO-FORMS is a list of subforms which would be
> compiled using a compiler macro. Since there is no standard way
> to provide a local compiler-macro definition in Emacs Lisp, no
> corresponding local environments are collected for these.
>
> Forms and environments are extracted from FORM by instrumenting
> Emacs's builtin `macroexpand' function and calling
> `macroexpand-all'."
> (let* ((macro-form-alist '())
> (compiler-macro-forms '())
> (override (lambda (real-macroexpand form environment &rest args)
> (let ((expansion
> (apply real-macroexpand form environment args)))
> (cond ((not (eq expansion form))
> (setq macro-form-alist
> (cons (cons form environment)
> macro-form-alist)))
> ((and (consp form)
> (symbolp (car form))
> macrostep-expand-compiler-macros
> (not (eq form
> (cl-compiler-macroexpand form))))
> (setq compiler-macro-forms
> (cons form compiler-macro-forms))))
> expansion))))
> (cl-macrolet ((with-override (fn &rest body)
> `(cl-letf (((symbol-function ,fn)
> (apply-partially override (indirect-function ,fn))))
> ,@body))
> (with-macroexpand-1 (&rest body)
> (if (< emacs-major-version 30)
> `(progn ,@body) `(with-override #'macroexpand-1 ,@body)))
> (with-macroexpand (&rest body)
> `(with-override #'macroexpand ,@body)))
> (with-macroexpand-1
> (with-macroexpand
> (ignore-errors
> (macroexpand-all form environment)))))
> (list macro-form-alist compiler-macro-forms)))
>
> (defvar macrostep-collected-macro-form-alist nil
> "An alist of macro forms and environments.
> Controls the printing of sub-forms in `macrostep-print-sexp'.")
>
> (defvar macrostep-collected-compiler-macro-forms nil
> "A list of compiler-macro forms to be highlighted in `macrostep-print-sexp'.")
>
> (defun macrostep-pp (sexp environment)
> "Pretty-print SEXP, fontifying macro forms and uninterned symbols.
> This is done within ENVIRONMENT."
> (cl-destructuring-bind
> (macrostep-collected-macro-form-alist
> macrostep-collected-compiler-macro-forms)
> (macrostep-collect-macro-forms sexp environment)
> (let ((print-quoted t))
> (macrostep-print-sexp sexp)
> ;; Point is now after the expanded form; pretty-print it
> (save-restriction
> (narrow-to-region (scan-sexps (point) -1) (point))
> (save-excursion
> (pp-buffer)
> ;; Remove the extra newline inserted by pp-buffer
> (goto-char (point-max))
> (delete-region
> (point)
> (save-excursion (skip-chars-backward " \t\n") (point))))
> ;; Indent the newly-inserted form in context
> (widen)
> (save-excursion
> (backward-sexp)
> (indent-sexp))))))
>
> ;; This must be defined before `macrostep-print-sexp':
> (defmacro macrostep-propertize (form &rest plist)
> "Evaluate FORM, applying syntax properties in PLIST to any inserted text."
> (declare (indent 1)
> (debug (&rest form)))
> (let ((start (make-symbol "start")))
> `(let ((,start (point)))
> (prog1
> ,form
> ,@(cl-loop for (key value) on plist by #'cddr
> collect `(put-text-property ,start (point)
> ,key ,value))))))
>
> (defun macrostep-print-sexp (sexp)
> "Insert SEXP like `print', fontifying macro forms and uninterned symbols.
>
> Fontifies uninterned symbols and macro forms using
> `font-lock-face' property, and saves the actual text of SEXP's
> sub-forms as the `macrostep-expanded-text' text property so that
> any uninterned symbols can be reused in macro expansions of the
> sub-forms. See also `macrostep-sexp-at-point'.
>
> Macro and compiler-macro forms within SEXP are identified by
> comparison with the `macrostep-collected-macro-form-alist' and
> `macrostep-collected-compiler-macro-forms' variables, which
> should be dynamically let-bound around calls to this function."
> (cond
> ((symbolp sexp)
> ;; Fontify gensyms
> (if (not (eq sexp (intern-soft (symbol-name sexp))))
> (macrostep-propertize
> (prin1 sexp (current-buffer))
> 'font-lock-face (macrostep-get-gensym-face sexp))
> ;; Print other symbols as normal
> (prin1 sexp (current-buffer))))
>
> ((listp sexp)
> ;; Print quoted and quasiquoted forms nicely.
> (let ((head (car sexp)))
> (cond ((and (eq head 'quote) ; quote
> (= (length sexp) 2))
> (insert "'")
> (macrostep-print-sexp (cadr sexp)))
>
> ((and (eq head '\`) ; backquote
> (= (length sexp) 2))
> (if (assq sexp macrostep-collected-macro-form-alist)
> (macrostep-propertize
> (insert "`")
> 'macrostep-expanded-text sexp
> 'macrostep-macro-start t
> 'font-lock-face 'macrostep-macro-face)
> (insert "`"))
> (macrostep-print-sexp (cadr sexp)))
>
> ((and (memq head '(\, \,@)) ; unquote
> (= (length sexp) 2))
> (princ head (current-buffer))
> (macrostep-print-sexp (cadr sexp)))
>
> (t ; other list form
> (cl-destructuring-bind (macro? . environment)
> (or (assq sexp macrostep-collected-macro-form-alist)
> '(nil . nil))
> (let
> ((compiler-macro?
> (memq sexp macrostep-collected-compiler-macro-forms)))
> (if (or macro? compiler-macro?)
> (progn
> ;; Save the real expansion as a text property on the
> ;; opening paren
> (macrostep-propertize
> (insert "(")
> 'macrostep-macro-start t
> 'macrostep-expanded-text sexp
> 'macrostep-environment environment)
> ;; Fontify the head of the macro
> (macrostep-propertize
> (macrostep-print-sexp head)
> 'font-lock-face
> (if macro?
> 'macrostep-macro-face
> 'macrostep-compiler-macro-face)))
> ;; Not a macro form
> (insert "(")
> (macrostep-print-sexp head))))
>
> ;; Print remaining list elements
> (setq sexp (cdr sexp))
> (when sexp (insert " "))
> (while sexp
> (if (listp sexp)
> (progn
> (macrostep-print-sexp (car sexp))
> (when (cdr sexp) (insert " "))
> (setq sexp (cdr sexp)))
> ;; Print tail of dotted list
> (insert ". ")
> (macrostep-print-sexp sexp)
> (setq sexp nil)))
> (insert ")")))))
>
> ;; Print everything except symbols and lists as normal
> (t (prin1 sexp (current-buffer)))))
>
> (defun macrostep-get-gensym-face (symbol)
> "Return the face to use in fontifying SYMBOL in printed macro expansions.
>
> All symbols introduced in the same level of macro expansion are
> fontified using the same face (modulo the number of faces; see
> `macrostep-gensym-faces')."
> (or (get symbol 'macrostep-gensym-face)
> (progn
> (if (not macrostep-gensyms-this-level)
> (setq macrostep-gensym-depth (1+ macrostep-gensym-depth)
> macrostep-gensyms-this-level t))
> (let ((face (ring-ref macrostep-gensym-faces macrostep-gensym-depth)))
> (put symbol 'macrostep-gensym-face face)
> face))))
>
> \f
> (provide 'macrostep)
> ;; Local Variables:
> ;; indent-tabs-mode: nil
> ;; End:
> ;;; macrostep.el ends here
Isn't there also a C-preprecossor implementation for macrostep? Would
the plan be to include that as well?
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 86%]
* Re: [ELPA] [PATCH] CSS readability improvements
@ 2024-03-17 14:43 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-03-17 14:43 UTC (permalink / raw)
To: Adam Porter; +Cc: Stefan Monnier, emacs-devel
Adam Porter <adam@alphapapa.net> writes:
> Hi Stefan,
>
> On 3/16/24 23:14, Stefan Monnier wrote:
>> Hi Adam,
>> Thank you very much for these. Could you point to existing places
>> in
>> `elpa.(non)gnu.org` where we can see the current problems, so as to help
>> me understand what's the actual intended impact of your changes?
>
> You can see these issues on various packages of mine whose readmes on
> ELPA are generated from Org manuals, such as
> <https://elpa.gnu.org/devel/listen.html> (see the tables listing
> commands under "Commands", which are displayed without any space
> between them; and the DL list under "Repeat modes"), and
> <https://elpa.gnu.org/packages/activities.html> (see the FAQ section).
Not related to the patch, why are you using description lists for FAQs?
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 99%]
* Re: (byte-compile '(append '(1 2) '(3 4)))
@ 2024-03-16 13:55 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-03-16 13:55 UTC (permalink / raw)
To: Basil L. Contovounesios; +Cc: Felician Nemeth, emacs-devel
"Basil L. Contovounesios" <basil@contovou.net> writes:
> Philip Kaludercic [2024-03-16 12:46 +0000] wrote:
>
>> I am not sure what the danger is in the case of constant, quoted lists,
>> but I am not familiar with the byte compiler either. It seems like this
>>
>> diff --git a/lisp/emacs-lisp/byte-opt.el b/lisp/emacs-lisp/byte-opt.el
>> index f75be3f71ad..e6f18590705 100644
>> --- a/lisp/emacs-lisp/byte-opt.el
>> +++ b/lisp/emacs-lisp/byte-opt.el
>> @@ -1599,6 +1599,12 @@ byte-optimize-append
>> (cdr args))
>> (cdr newargs)))
>>
>> + ;; (append '(C1...) ... '(C2...)) -> (append C1... ... C2...)
>> + ((cl-loop for arg in args
>> + always (and (eq (car arg) 'quote)
>> + (proper-list-p (cdr arg))))
>> + `',(mapcan #'cadr args))
>> +
>> ;; non-terminal arg
>> ((cdr args)
>> (cond
>>
>>
>> would do the trick, and the byte-code is even better:
>>
>> byte code:
>> args: nil
>> 0 constant (1 2 3 4)
>> 1 return
>
> Is this correct? According to its docstring, append's last argument
> must be eq to the tail of its return value.
This little test indicates that it would still be eq:
((macro . (lambda (arg)
`(eq (cddadr (byte-optimize-append '(append '(1 2) ,arg)))
,arg)))
'(3 4)) ;=> t
since the mapcan or rather nconc makes the same promise.
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 99%]
* Re: (byte-compile '(append '(1 2) '(3 4)))
@ 2024-03-16 12:46 88% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-03-16 12:46 UTC (permalink / raw)
To: Felician Nemeth; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1028 bytes --]
Felician Nemeth <felician.nemeth@gmail.com> writes:
> (disassemble (byte-compile '(append '(1 2) '(3 4))))
>
> resuts in
>
> byte code:
> args: nil
> 0 constant append
> 1 constant (1 2)
> 2 constant (3 4)
> 3 call 2
> 4 return
>
> Instead I expected it to be something like
>
> byte code:
> args: nil
> 0 constant 1
> 1 constant 2
> 2 constant 3
> 3 constant 4
> 4 list4
> 5 return
>
> I've never looked at byte-code optimization before, and I'm guessing
> this is not a huge improvement, but I still wonder when all the
> arguments of side-effect-free function are constants would it make sense
> to calculate the result at compile time.
`byte-optimize-append' mentions:
;; There is (probably) too much code relying on `append' to return a
;; new list for us to do full constant-folding; these transformations
;; preserve the allocation semantics.
I am not sure what the danger is in the case of constant, quoted lists,
but I am not familiar with the byte compiler either. It seems like this
[-- Attachment #2: Type: text/plain, Size: 650 bytes --]
diff --git a/lisp/emacs-lisp/byte-opt.el b/lisp/emacs-lisp/byte-opt.el
index f75be3f71ad..e6f18590705 100644
--- a/lisp/emacs-lisp/byte-opt.el
+++ b/lisp/emacs-lisp/byte-opt.el
@@ -1599,6 +1599,12 @@ byte-optimize-append
(cdr args))
(cdr newargs)))
+ ;; (append '(C1...) ... '(C2...)) -> (append C1... ... C2...)
+ ((cl-loop for arg in args
+ always (and (eq (car arg) 'quote)
+ (proper-list-p (cdr arg))))
+ `',(mapcan #'cadr args))
+
;; non-terminal arg
((cdr args)
(cond
[-- Attachment #3: Type: text/plain, Size: 151 bytes --]
would do the trick, and the byte-code is even better:
byte code:
args: nil
0 constant (1 2 3 4)
1 return
--
Philip Kaludercic on peregrine
^ permalink raw reply related [relevance 88%]
* Re: builtin completion ?
@ 2024-03-15 15:48 97% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-03-15 15:48 UTC (permalink / raw)
To: hx; +Cc: emacs-devel
hx <silent2600@gmail.com> writes:
> I work on a linux computer (emacs26) without internet,usb,share ...
> developing C program,
> no way to install auto-complete/company-mode/lsp,
>
> when I edit my init.el, (setq var-xx-, no auto completion, painfull,
> any package can complete elisp variable/function like auto-complete-mode ?
Not /auto/ completion, but `completion-at-point' is bound by default,
and you can configure `tab-always-indent' to have TAB provide
completions as well. They will pop up in the completion buffer, just
like with minibuffer completions.
> For c programming, I only have cscope, but also no function/var completion,
> there is cedet, I will try to configure it.
I am not sure if Emacs 26 had completion based on TAGS, but if Emacs was
installed using some standard mechanism, then you should have etags
available that could index the symbols in a project, that completion
could make use of.
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 97%]
* Re: Adding package "Loopy" to Non-GNU Devel?
@ 2024-03-14 18:52 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-03-14 18:52 UTC (permalink / raw)
To: Okamsn; +Cc: emacs-devel
(Sorry for the late response)
Okamsn <okamsn@protonmail.com> writes:
> Philip Kaludercic wrote:
>> Okamsn <okamsn@protonmail.com> writes:
>>
>>> Okamsn wrote:
>>>> Philip Kaludercic wrote:
>>>>> Okamsn <okamsn@protonmail.com> writes:
>>>>>> I keep the extension package in the same GitHub repo as the main package for
>>>>>> testing purposes. The Dash functionality was requested by a user, but
>>>>>> Dash is
>>>>>> not used by the rest of the package. Because of that, I put the Dash
>>>>>> functionality in a small separate package.
>>>>>
>>>>> You are talking about the loopy-dash.el file in the same branch, right?
>>>>
>>>> Yes.
>>>>
>>>>> If possible, it would be better if you could at least maintain it in a
>>>>> separate branch.
>>>>
>>>> If I added the file "loopy-dash.el" to an ".elpaignore" file in the main
>>>> branch and used GitHub Actions to push any changes from the main branch
>>>> to another branch containing the file "loopy-dash.el", would that be
>>>> acceptable?
>>
>> Sorry for not answering earlier, this doesn't really solve the issue,
>> since the root issue is that when using package-vc or elpa-admin, you
>> still have two versions of the file in `load-path'.
>>
>>>
>>> Hello,
>>>
>>> I figured out how to make GitHub automatically copy changes of the file
>>> to another branch when the master branch changes, and have listed the
>>> file `loopy-dash.el` in the `.elpaignore` file on the master branch.
>>
>> If we were to disregard examples as those mentioned above, then this
>> would be an acceptable solution, but I'd rather not, unless you
>> categorically reject having two separate and disjoint branches.
>
> I would like to keep the development of the packages together, since I
> still change the implementation details. Having them together makes
> testing for breakage much easier.
One last idea would be to use worktrees, i.e. basically keep development
in separate branches that are simultaneously checked.
> What if I also had GitHub copy changes into a separate branch that only
> contained the Loopy package and the documentation files? This would
> avoid having the two copies of `loopy-dash.el`. Would that work for
> Package VC?
No, since upon installing loopy as a VC package, you'll still have the
loopy-dash.el file as part of the checked out repository and the
loopy-dash.el provided by the dependency.
>>> I have attached a patch file. Are there any other changes that you would
>>> like made?
>>
>> I don't think there is anything else (the only thing I can vainly try to
>> bring up is that having a diminutive as the name of a macro is something
>> I find peculiar, and I can imagine would keep a number of other people
>> from using the otherwise nice package, but it seems it is too late for
>> that now?)
>
> I think that it is too late, because it has existed on MELPA for a few
> years with that name. If it helps, I was not thinking of it as a
> diminutive, just the normal adjective and the slang usage:
> https://www.thefreedictionary.com/loopy. I acknowledge that your point
> probably also applies for the slang definition, but I still like the name.
In that case forget my comment.
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 99%]
* Re: [PATCH] Flymake Support Indicator Errors in Margin
@ 2024-03-12 9:24 96% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-03-12 9:24 UTC (permalink / raw)
To: Elijah G; +Cc: emacs-devel
Elijah G <eg642616@gmail.com> writes:
> Hello developers,
> this is my first time contributing to emacs,
> i made support for displaying errors in margin for flymake like flycheck
> does,
> This allows indicating errors in both text and graphical mode.
>
> I've sent my copyright assignment request.
>
> Since this is my first time contributing i would like to hear your
> suggestions and thoughts
>
> Thanks.
> From 0d4539c6b8483eb13cfcdde3d73c71e430fdb30b Mon Sep 17 00:00:00 2001
> From: Elias G <eg642616@gmail.com>
> Date: Mon, 11 Mar 2024 13:35:06 -0600
> Subject: [PATCH] Flymake Support Indicator Errors in Margin
>
> ---
> etc/NEWS | 11 ++++
> lisp/progmodes/flymake.el | 117 +++++++++++++++++++++++++++++++++-----
> 2 files changed, 114 insertions(+), 14 deletions(-)
>
> diff --git a/etc/NEWS b/etc/NEWS
> index 19cd170e5c7..83cf1ba9962 100644
> --- a/etc/NEWS
> +++ b/etc/NEWS
> @@ -1121,6 +1121,17 @@ in a clean environment.
>
> ** Flymake
>
> ++++
> +*** New user option 'flymake-indicator-type'
> +Indicate which indicator type to use for display errors.
> +
> +The value can be nil (dont indicate errors but just highlight them),
^
don't
> +fringes (use fringes) or margins (use margins).
But I am not sure if you really need to document this in NEWS. In fact,
it might be possible to merge this and the next point:
> +
> ++++
> +*** Support Display Errors Indicator in margin
> +This allow indicate errors in both graphical and text display.
> +
> +++
> *** New user option 'flymake-show-diagnostics-at-end-of-line'.
> When non-nil, Flymake shows summarized descriptions of diagnostics at
> diff --git a/lisp/progmodes/flymake.el b/lisp/progmodes/flymake.el
> index db00cc59c0e..835f2057109 100644
> --- a/lisp/progmodes/flymake.el
> +++ b/lisp/progmodes/flymake.el
> @@ -180,6 +180,73 @@ See `flymake-error-bitmap' and `flymake-warning-bitmap'."
> (const right-fringe)
> (const :tag "No fringe indicators" nil)))
>
> +(defcustom flymake-indicator-type 'fringes
> + "Indicate which indicator type to use for display errors.
> +
> +The value can be nil (dont indicate errors but just highlight them),
> +fringes (use fringes) or margins (use margins)
> +
> +Difference between fringes and margin is that fringes support diplaying
> +bitmaps on graphical displays and margins display text in a blank area
> +of buffer that works in both graphical and text displays.
> +
> +See Info node `Fringes' and Info node `(elisp)Display Margins'."
> + :version "30.1"
> + :type '(choice (const :tag "Use Fringes" fringes)
> + (const :tag "Use Margins "margins)
> + (const :tag "No indicators" nil)))
There are tabs here.
> +
> +(defcustom flymake-error-margin-string '("‼" compilation-error)
> + "String used in the margn for indicating errors.
> +The value may also be a list of two elements where the second
> +element specifies the face for the string.
> +See also `flymake-warning-margin-string'.
> +
> +The option `flymake-margin-indicator-position' controls how and where
> +this is used."
> + :version "30.1"
> + :type '(choice (string :tag "String")
> + (list :tag "String and face"
> + (string :tag "String")
> + (face :tag "Face"))))
> +
> +(defcustom flymake-warning-margin-string '("!" compilation-warning)
> + "String used in the margin for indicating warnings.
> +The value may also be a list of two elements where the second
> +element specifies the face for the string.
> +See also `flymake-error-margin-string'.
> +
> +The option `flymake-margin-indicator-position' controls how and where
> +this is used."
> + :version "30.1"
> + :type '(choice (string :tag "String")
> + (list :tag "String and face"
> + (string :tag "String")
> + (face :tag "Face"))))
> +
> +(defcustom flymake-note-margin-string '("!" compilation-info)
> + "String used in the margin for indicating info notes.
> +The value may also be a list of two elements where the second
> +element specifies the face for the string.
> +See also `flymake-error-margin-string'.
> +
> +The option `flymake-margin-indicator-position' controls how and where
> +this is used."
> + :version "30.1"
> + :type '(choice (string :tag "String")
> + (list :tag "String and face"
> + (string :tag "String")
> + (face :tag "Face"))))
Should or could these be merged into a single user option, that would
then have the form
'((error "‼" compilation-error)
(note "!" compilation-warning)
(info "!" compilation-info))
> +
> +(defcustom flymake-margin-indicator-position 'left-margin
> + "The position to put Flymake margin indicator.
> +The value can be nil (do not use indicators), `left-margin' or `right-margin'.
> +See `flymake-error-margin-string' and `flymake-warning-margin-string'."
> + :version "30.1"
> + :type '(choice (const left-margin)
> + (const right-margin)
> + (const :tag "No margin indicators" nil)))
> +
> (make-obsolete-variable 'flymake-start-syntax-check-on-newline
> "can check on newline in post-self-insert-hook"
> "27.1")
> @@ -630,6 +697,7 @@ Node `(Flymake)Flymake error types'"
>
> (put 'flymake-error 'face 'flymake-error)
> (put 'flymake-error 'flymake-bitmap 'flymake-error-bitmap)
> +(put 'flymake-error 'flymake-margin-string 'flymake-error-margin-string)
> (put 'flymake-error 'severity (warning-numeric-level :error))
> (put 'flymake-error 'mode-line-face 'flymake-error-echo)
> (put 'flymake-error 'echo-face 'flymake-error-echo)
> @@ -638,6 +706,7 @@ Node `(Flymake)Flymake error types'"
>
> (put 'flymake-warning 'face 'flymake-warning)
> (put 'flymake-warning 'flymake-bitmap 'flymake-warning-bitmap)
> +(put 'flymake-warning 'flymake-margin-string 'flymake-warning-margin-string)
> (put 'flymake-warning 'severity (warning-numeric-level :warning))
> (put 'flymake-warning 'mode-line-face 'flymake-warning-echo)
> (put 'flymake-warning 'echo-face 'flymake-warning-echo)
> @@ -646,6 +715,7 @@ Node `(Flymake)Flymake error types'"
>
> (put 'flymake-note 'face 'flymake-note)
> (put 'flymake-note 'flymake-bitmap 'flymake-note-bitmap)
> +(put 'flymake-note 'flymake-margin-string 'flymake-note-margin-string)
> (put 'flymake-note 'severity (warning-numeric-level :debug))
> (put 'flymake-note 'mode-line-face 'flymake-note-echo)
> (put 'flymake-note 'echo-face 'flymake-note-echo)
> @@ -682,19 +752,34 @@ associated `flymake-category' return DEFAULT."
> (flymake--lookup-type-property type 'severity
> (warning-numeric-level :error)))
>
> -(defun flymake--fringe-overlay-spec (bitmap &optional recursed)
> - (if (and (symbolp bitmap)
> - (boundp bitmap)
> - (not recursed))
> - (flymake--fringe-overlay-spec
> - (symbol-value bitmap) t)
> - (and flymake-fringe-indicator-position
> - bitmap
> - (propertize "!" 'display
> - (cons flymake-fringe-indicator-position
> - (if (listp bitmap)
> - bitmap
> - (list bitmap)))))))
> +(defun flymake--fringe-overlay-spec (indicator)
> + "Return INDICATOR-TYPE as propertized string to use in error indicators"
> + (let* ((value (if (symbolp indicator)
> + (symbol-value indicator)
> + indicator))
> + (indicator-car (if (listp value)
> + (car value)
> + value))
> + (indicator-cdr (if (listp value)
> + (cdr value))))
> + (cond
> + ((symbolp indicator-car)
> + (propertize "!" 'display
> + (cons flymake-fringe-indicator-position
> + (if (listp value)
> + value
> + (list value)))))
> + ((stringp indicator-car)
> + (propertize "!"
> + 'display
> + `((margin ,flymake-margin-indicator-position)
> + ,(propertize
> + indicator-car
> + 'face
> + `(:inherit (,indicator-cdr
> + default)
> + )))))
You should fold these parentheses back onto the previous line.
> + (t nil))))
This is not needed, as cond will default to nil if no case matched.
>
> (defun flymake--equal-diagnostic-p (a b)
> "Tell if A and B are equivalent `flymake--diag' objects."
> @@ -843,7 +928,11 @@ Return nil or the overlay created."
> (flymake--fringe-overlay-spec
> (flymake--lookup-type-property
> type
> - 'flymake-bitmap
> + (cond ((eq flymake-indicator-type 'fringes)
> + 'flymake-bitmap)
> + ((eq flymake-indicator-type 'margins)
> + 'flymake-margin-string)
> + (t nil))
> (alist-get 'bitmap (alist-get type ; backward compat
> flymake-diagnostic-types-alist)))))
> ;; (default-maybe 'after-string
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 96%]
* Re: I created a faster JSON parser
@ 2024-03-10 21:39 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-03-10 21:39 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Christopher Wellons, geza.herman, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> Date: Sat, 9 Mar 2024 15:37:25 -0500
>> From: Christopher Wellons <wellons@nullprogram.com>
>> Cc: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
>>
>> Despite the obvious care which with this was written, I personally would
>> not adopt a JSON parser that had not been thoroughly fuzz tested under
>> Address Sanitizer and Undefined Behavior Sanitizer. Fuzzing is incredibly
>> effective at finding defects, and it would be foolish not to use it in its
>> ideal circumstances. Normally it's not difficult and requires only a few
>> lines of code. But this JSON parser is tightly coupled with the Emacs Lisp
>> runtime, which greatly complicates things. I couldn't simply pluck it out
>> by itself and drop it in, say, AFL++.
>
> That's okay, we can start by making this an optional feature, and
> consider making it the default after a couple of major releases;
> meanwhile, any problems will be detected and reported.
>
> However, it would make much more sense to consider switching to this
> code if it also could handle producing JSON output, thus making
> libjansson unnecessary when we decide to switch.
If libjansson is not available, it should still be possible to use this
faster parser, while falling back to json.el for generating JSON? From
what I understand, the main issue people have with JSON is the parsing
bottleneck, right?
--
Philip Kaludercic on icterid
^ permalink raw reply [relevance 99%]
* Re: [ELPA] new single file package: mpdired.el
@ 2024-03-10 18:15 98% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-03-10 18:15 UTC (permalink / raw)
To: Manuel Giraud; +Cc: Manuel Giraud via Emacs development discussions.
Manuel Giraud <manuel@ledu-giraud.fr> writes:
> Manuel Giraud <manuel@ledu-giraud.fr> writes:
>
>> Philip Kaludercic <philipk@posteo.net> writes:
>>
>> [...]
>>
>>>> (defun mpdired-mode ()
>>>
>>> Why not use `define-derived-mode'?
>>
>> I have tried to do so but for whatever reason this completely messes up
>> the way I'm saving state in buffer local variables. FWIW, I have tried
>> with parent as nil and special-mode with the same result.
This is because nil will just call `kill-all-local-variables',
and if you specify, special-mode it will call `kill-all-local-variables'
for you.
> It seems to be because `define-derived-mode' calls
> `kill-all-local-variables' (line 254 of derived.el). Maybe this could
> be optional. WDYT?
Theoretically you can do this by setting PARENT to `ignore', but I
wouldn't advise doing this. Feels wrong... The other solution would be
to use dynamic variables and bind them before calling `mpdired-mode'.
--
Philip Kaludercic on icterid
^ permalink raw reply [relevance 98%]
* Re: [ELPA] new single file package: mpdired.el
@ 2024-03-10 17:03 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-03-10 17:03 UTC (permalink / raw)
To: Manuel Giraud; +Cc: Manuel Giraud via Emacs development discussions.
Manuel Giraud <manuel@ledu-giraud.fr> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
> [...]
>
>>>> Yes, more specifically any version which version-to-list can parse and
>>>> returns a version list without any negative elements:
>>>>
>>>> (version-to-list "1.0") ;=> (1 0)
>>>> (version-to-list "1.0pre") ;=> (1 0 -1)
>>>> (version-to-list "1.0git") ;=> (1 0 -4)
>>>>
>>>> see `version-regexp-alist' and keep in mind that the ELPA build server
>>>> uses a few more extensions.
>>>
>>> Thanks, all is clear for me now.
>>
>> Great. Should we add the package immediately or do you want to wait?
>
> If a "package" will be created whenever I change "Version" to something
> without negative element then "yes, please" :-)
OK done. Just keep in mind to update the copyright header to
;; Copyright (C) 2024 Free Software Foundation, Inc.
before releasing the package. You'll be able to preview the package on
https://elpa.gnu.org/devel/mpdired.html after each commit.
--
Philip Kaludercic on icterid
^ permalink raw reply [relevance 99%]
* Re: [ELPA] new single file package: mpdired.el
@ 2024-03-09 13:36 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-03-09 13:36 UTC (permalink / raw)
To: Manuel Giraud; +Cc: Manuel Giraud via Emacs development discussions.
Manuel Giraud <manuel@ledu-giraud.fr> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Manuel Giraud <manuel@ledu-giraud.fr> writes:
>>
>>> Philip Kaludercic <philipk@posteo.net> writes:
>>>
>>> [...]
>>>
>>>> OK, this works. If you have signed the CA, then you could set the
>>>> version of your package to some pre-release version, using a
>>>
>>> I don't know what "signed the CA" means in this context.
>>
>> Contributing packages to GNU ELPA requires you to have signed the FSF
>> copyright assignment, see (info "(emacs) Copyright Assignment"), since
>> GNU ELPA packages are formally part of Emacs. Assuming you haven't done
>> so yet, a maintainer can send you the form.
>
> Ok. So I already have this because I've already contributed to Emacs.
Ok, then nevermind. I could have also checked AUTHORS to verify that.
>> Git tags aren't needed at all. The ELPA build server relies entirely on
>> what the Version tag says.
>
> Ok, I can still have tags on my side.
Right, they are just not synchronised.
>>> Just to be sure I understand
>>> correctly: every version number with a -pre suffix won't update on ELPA?
>>
>> Yes, more specifically any version which version-to-list can parse and
>> returns a version list without any negative elements:
>>
>> (version-to-list "1.0") ;=> (1 0)
>> (version-to-list "1.0pre") ;=> (1 0 -1)
>> (version-to-list "1.0git") ;=> (1 0 -4)
>>
>> see `version-regexp-alist' and keep in mind that the ELPA build server
>> uses a few more extensions.
>
> Thanks, all is clear for me now.
Great. Should we add the package immediately or do you want to wait?
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 99%]
* Re: Work On Todo item: Convert defvar foo-mode-map to defvar-keymap
@ 2024-03-09 9:21 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-03-09 9:21 UTC (permalink / raw)
To: binarydigitz01 via Emacs development discussions.; +Cc: binarydigitz01
binarydigitz01 via "Emacs development discussions."
<emacs-devel@gnu.org> writes:
> Hi,
> I would like to work on the todo item "** Convert defvar foo-mode-map to defvar-keymap".
> I wanted to confirm whether anyone else is working on it, and general advice as this would be my first time contributing.
To my knowledge, and according to a quick search of the Git logs, it
doesn't appear that anyone is actively working on this.
As to general advice, have you taken a look at the CONTRIBUTE file in
emacs.git?
> Thanks,
> Arnav
>
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 99%]
* Re: Add elisa to gnu elpa
[not found] <D57DBB96-82DE-4697-A358-032B04190724@gmail.com>
@ 2024-03-09 9:03 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-03-09 9:03 UTC (permalink / raw)
To: Sergey Kostyaev; +Cc: emacs-devel
Sergey Kostyaev <sskostyaev@gmail.com> writes:
> Hi, Philip.
>
> Please add my new package ELISA https://github.com/s-kostyaev/elisa to GNU Elpa.
Sorry for missing this message, it is better to announce these things
directly on emacs-devel. I've CC'ed the mailing list, and will try to
comment on your code soon enough™.
> Best regards,
> Sergey Kostyaev
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 99%]
* Re: [ELPA] new single file package: mpdired.el
@ 2024-03-08 17:29 91% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-03-08 17:29 UTC (permalink / raw)
To: Manuel Giraud; +Cc: Manuel Giraud via Emacs development discussions.
Manuel Giraud <manuel@ledu-giraud.fr> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
> [...]
>
>> OK, this works. If you have signed the CA, then you could set the
>> version of your package to some pre-release version, using a
>
> I don't know what "signed the CA" means in this context.
Contributing packages to GNU ELPA requires you to have signed the FSF
copyright assignment, see (info "(emacs) Copyright Assignment"), since
GNU ELPA packages are formally part of Emacs. Assuming you haven't done
so yet, a maintainer can send you the form.
>> ;; Version: 1.0-pre
>>
>> header, and as soon as you are ready to publish just remove the -pre and
>> the package will be automatically published + a new release will be made
>> any time to bump the header.
>
> Cool. That is a great feature that I will be using (matching this
> Version header with git tags I guess).
Git tags aren't needed at all. The ELPA build server relies entirely on
what the Version tag says.
> Just to be sure I understand
> correctly: every version number with a -pre suffix won't update on ELPA?
Yes, more specifically any version which version-to-list can parse and
returns a version list without any negative elements:
(version-to-list "1.0") ;=> (1 0)
(version-to-list "1.0pre") ;=> (1 0 -1)
(version-to-list "1.0git") ;=> (1 0 -4)
see `version-regexp-alist' and keep in mind that the ELPA build server
uses a few more extensions.
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 91%]
* Re: [ELPA] new single file package: mpdired.el
@ 2024-03-08 16:34 98% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-03-08 16:34 UTC (permalink / raw)
To: Manuel Giraud; +Cc: Manuel Giraud via Emacs development discussions.
Manuel Giraud <manuel@ledu-giraud.fr> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
> [...]
>
>>> Ok so it's a "no": I don't want to put a burden on someone else.
>>
>> Feel free to work on it yourself ;^) I don't think it wouldn't make
>> sense, it is just that it seems like a negligible advantage for a rather
>> insignificant convenience. I'd also like to be able to track files via
>> RCS, but exporting existing files to a Git repository turns out to be
>> consistently easier.
>
> I don't think I'm skilled enough to do this and now that I have just
> setup a Git repo I don't think I will be really motivated myself ;-)
>
> [...]
>
>>>> As I said, a git forge in that sense is not necessarily needed, you
>>>> could also just host the git repository from some website over
>>>> https://.
>>>
>>> Great. I think it is what I would do then. Thanks.
>>
>> Just keep in mind to enable the "post-update.sample" that invokes "git
>> update-server-info", in case you haven't set up a http-Git repo before.
>>
>> All we need in the end is a URL.
>
> I fought git hooks a bit but I think I have finally configured it
> correctly and the URL is https://ledu-giraud.fr/mpdired.git
OK, this works. If you have signed the CA, then you could set the
version of your package to some pre-release version, using a
;; Version: 1.0-pre
header, and as soon as you are ready to publish just remove the -pre and
the package will be automatically published + a new release will be made
any time to bump the header.
> I'm going to patch with all your previous remarks. Thanks.
1+
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 98%]
* Re: [ELPA] new single file package: mpdired.el
@ 2024-03-08 13:18 94% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-03-08 13:18 UTC (permalink / raw)
To: Manuel Giraud; +Cc: Manuel Giraud via Emacs development discussions.
Manuel Giraud <manuel@ledu-giraud.fr> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
> [...]
>
>>> Of course, I'd also like to avoid this latter setup. Just to be sure,
>>> you confirm that a git repo is unavoidable? Could it be a just tarball
>>> available on web server?
>>
>> Technically yes, but the ELPA build system would have to be updated just
>> for this use-case.
>
> Ok so it's a "no": I don't want to put a burden on someone else.
Feel free to work on it yourself ;^) I don't think it wouldn't make
sense, it is just that it seems like a negligible advantage for a rather
insignificant convenience. I'd also like to be able to track files via
RCS, but exporting existing files to a Git repository turns out to be
consistently easier.
> [...]
>
>>> Ok. If a git forge is mandatory, I'll ponder which one I'd prefer to
>>> use.
>>
>> As I said, a git forge in that sense is not necessarily needed, you
>> could also just host the git repository from some website over
>> https://.
>
> Great. I think it is what I would do then. Thanks.
Just keep in mind to enable the "post-update.sample" that invokes "git
update-server-info", in case you haven't set up a http-Git repo before.
All we need in the end is a URL.
> [...]
>
>>>> Perhaps one could also rebind a few commands here, like `next-line'.
>>>
>>> I don't understand what you mean here.
>>
>> It is possible to remap a command, without having to bind a key. See
>> (elisp) Remapping Commands. The advantage is that if the user has any
>> custom bindings, say for next-line, then they would automatically be
>> inherited. That is comfortable from a user-perspective, because the
>> major-mode aligns more with their usual intuition.
>
> Yes it makes sense. I'll look at it.
1+
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 94%]
* Re: master bd017175d45 6/6: Simplify type hierarchy operations
[not found] ` <20240308070720.AC3ACC1FB4E@vcs2.savannah.gnu.org>
@ 2024-03-08 13:13 96% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-03-08 13:13 UTC (permalink / raw)
To: emacs-devel; +Cc: Stefan Monnier
The below commit appears to be causing an error when compiling Emacs:
--8<---------------cut here---------------start------------->8---
[all well until here]
ELC+ELN ../lisp/button.elc
Error: error ("../lisp/button.el" "Type or missing from typeof-types!")
signal(error ("../lisp/button.el" "Type or missing from typeof-types!"))
comp--native-compile("../lisp/button.el")
batch-native-compile()
batch-byte+native-compile()
funcall(batch-byte+native-compile)
...
--8<---------------cut here---------------end--------------->8---
Stefan Monnier via Mailing list for Emacs changes <emacs-diffs@gnu.org>
writes:
> branch: master
> commit bd017175d4571e24ef1fdf84676136af1d36002d
> Author: Stefan Monnier <monnier@iro.umontreal.ca>
> Commit: Stefan Monnier <monnier@iro.umontreal.ca>
>
> Simplify type hierarchy operations
>
> Now that built-in types have classes that describe their
> relationships exactly like struct/eieio/oclosure classes,
> we can the code that navigates that DAG.
>
> * lisp/emacs-lisp/cl-generic.el (cl--generic-struct-tag): Move to
> `eieio-core.el`.
> (cl--generic-type-specializers): Rename from
> `cl--generic-struct-specializers`. Make it work for any class.
> (cl--generic-typeof-generalizer, cl--generic-oclosure-generalizer): Use it.
> (cl--generic-struct-generalizer): Delete generalizer.
> (cl-generic-generalizers :extra "cl-struct"): Delete method.
> (prefill 0 cl--generic-generalizer): Move to after the typeof.
> (cl-generic-generalizers :extra "typeof"): Rewrite to use
> classes rather than `cl--all-builtin-types`.
> (cl-generic--oclosure-specializers): Delete function.
>
> * lisp/emacs-lisp/cl-preloaded.el (cl--direct-supertypes-of-type)
> (cl--typeof-types, cl--all-builtin-types): Delete constants.
>
> * lisp/emacs-lisp/comp-cstr.el (comp--typeof-builtin-types):
> Delete constant.
> (comp--cl-class-hierarchy): Simplify.
> (comp--compute-typeof-types): Simplify now that
> `comp--cl-class-hierarchy` and `comp--all-classes` work for built-in
> types as well.
> (comp--direct-supertypes): Just use `cl--class-parents`.
> (comp-supertypes): Simplify since typeof-types should now be complete.
>
> * lisp/emacs-lisp/eieio-core.el (eieio-defclass-autoload):
> Use `superclasses` argument, so we can find parents before it's loaded.
> (eieio--class-precedence-c3, eieio--class-precedence-dfs):
> Don't add a `eieio-default-superclass` parent any more.
> (eieio--class/struct-parents): Delete function.
> (eieio--class-precedence-bfs): Use `eieio--class-parents` instead.
> Don't stop when reaching `eieio-default-superclass`.
> (cl--generic-struct-tag): Move from `cl-generic.el`.
> ---
> lisp/emacs-lisp/cl-generic.el | 67 ++++++++++-------------------------------
> lisp/emacs-lisp/cl-preloaded.el | 30 ------------------
> lisp/emacs-lisp/comp-cstr.el | 55 +++++----------------------------
> lisp/emacs-lisp/eieio-core.el | 51 +++++++++++++++----------------
> 4 files changed, 49 insertions(+), 154 deletions(-)
>
> diff --git a/lisp/emacs-lisp/cl-generic.el b/lisp/emacs-lisp/cl-generic.el
> index f439a97f88c..84eb800ec24 100644
> --- a/lisp/emacs-lisp/cl-generic.el
> +++ b/lisp/emacs-lisp/cl-generic.el
> @@ -1330,62 +1330,31 @@ These match if the argument is `eql' to VAL."
> (cl--generic-prefill-dispatchers (terminal-parameter nil 'xterm--set-selection)
> (eql nil))
>
> -;;; Support for cl-defstructs specializers.
> +;;; Dispatch on "normal types".
>
> -(defun cl--generic-struct-tag (name &rest _)
> - ;; Use exactly the same code as for `typeof'.
> - `(if ,name (type-of ,name) 'null))
> -
> -(defun cl--generic-struct-specializers (tag &rest _)
> +(defun cl--generic-type-specializers (tag &rest _)
> (and (symbolp tag)
> - (let ((class (get tag 'cl--class)))
> - (when (cl-typep class 'cl-structure-class)
> + (let ((class (cl--find-class tag)))
> + (when class
> (cl--class-allparents class)))))
>
> -(cl-generic-define-generalizer cl--generic-struct-generalizer
> - 50 #'cl--generic-struct-tag
> - #'cl--generic-struct-specializers)
> -
> -(cl-defmethod cl-generic-generalizers :extra "cl-struct" (type)
> - "Support for dispatch on types defined by `cl-defstruct'."
> - (or
> - (when (symbolp type)
> - ;; Use the "cl--struct-class*" (inlinable) functions/macros rather than
> - ;; the "cl-struct-*" variants which aren't inlined, so that dispatch can
> - ;; take place without requiring cl-lib.
> - (let ((class (cl--find-class type)))
> - (and (cl-typep class 'cl-structure-class)
> - (or (null (cl--struct-class-type class))
> - (error "Can't dispatch on cl-struct %S: type is %S"
> - type (cl--struct-class-type class)))
> - (progn (cl-assert (null (cl--struct-class-named class))) t)
> - (list cl--generic-struct-generalizer))))
> - (cl-call-next-method)))
> -
> -(cl--generic-prefill-dispatchers 0 cl--generic-generalizer)
> -
> -;;; Dispatch on "system types".
> -
> (cl-generic-define-generalizer cl--generic-typeof-generalizer
> ;; FIXME: We could also change `type-of' to return `null' for nil.
> 10 (lambda (name &rest _) `(if ,name (type-of ,name) 'null))
> - (lambda (tag &rest _)
> - (and (symbolp tag) (assq tag cl--typeof-types))))
> + #'cl--generic-type-specializers)
>
> (cl-defmethod cl-generic-generalizers :extra "typeof" (type)
> - "Support for dispatch on builtin types.
> -See the full list and their hierarchy in `cl--typeof-types'."
> + "Support for dispatch on types.
> +This currently works for built-in types and types built on top of records."
> ;; FIXME: Add support for other types accepted by `cl-typep' such
> ;; as `character', `face', `function', ...
> (or
> - (and (memq type cl--all-builtin-types)
> - (progn
> - ;; FIXME: While this wrinkle in the semantics can be occasionally
> - ;; problematic, this warning is more often annoying than helpful.
> - ;;(if (memq type '(vector array sequence))
> - ;; (message "`%S' also matches CL structs and EIEIO classes"
> - ;; type))
> - (list cl--generic-typeof-generalizer)))
> + (and (symbolp type)
> + (not (eq type t)) ;; Handled by the `t-generalizer'.
> + (let ((class (cl--find-class type)))
> + (memq (type-of class)
> + '(built-in-class cl-structure-class eieio--class)))
> + (list cl--generic-typeof-generalizer))
> (cl-call-next-method)))
>
> (cl--generic-prefill-dispatchers 0 integer)
> @@ -1393,6 +1362,8 @@ See the full list and their hierarchy in `cl--typeof-types'."
> (cl--generic-prefill-dispatchers 0 cl--generic-generalizer integer)
> (cl--generic-prefill-dispatchers 0 (eql 'x) integer)
>
> +(cl--generic-prefill-dispatchers 0 cl--generic-generalizer)
> +
> ;;; Dispatch on major mode.
>
> ;; Two parts:
> @@ -1430,19 +1401,13 @@ Used internally for the (major-mode MODE) context specializers."
> (defun cl--generic-oclosure-tag (name &rest _)
> `(oclosure-type ,name))
>
> -(defun cl-generic--oclosure-specializers (tag &rest _)
> - (and (symbolp tag)
> - (let ((class (cl--find-class tag)))
> - (when (cl-typep class 'oclosure--class)
> - (oclosure--class-allparents class)))))
> -
> (cl-generic-define-generalizer cl--generic-oclosure-generalizer
> ;; Give slightly higher priority than the struct specializer, so that
> ;; for a generic function with methods dispatching structs and on OClosures,
> ;; we first try `oclosure-type' before `type-of' since `type-of' will return
> ;; non-nil for an OClosure as well.
> 51 #'cl--generic-oclosure-tag
> - #'cl-generic--oclosure-specializers)
> + #'cl--generic-type-specializers)
>
> (cl-defmethod cl-generic-generalizers :extra "oclosure-struct" (type)
> "Support for dispatch on types defined by `oclosure-define'."
> diff --git a/lisp/emacs-lisp/cl-preloaded.el b/lisp/emacs-lisp/cl-preloaded.el
> index 1b330e7f761..5743684fa89 100644
> --- a/lisp/emacs-lisp/cl-preloaded.el
> +++ b/lisp/emacs-lisp/cl-preloaded.el
> @@ -433,36 +433,6 @@ For this build of Emacs it's %dbit."
> (setf (cl--class-parents (cl--find-class 'cl-structure-object))
> (list (cl--find-class 'record))))
>
> -(defconst cl--direct-supertypes-of-type
> - ;; Please run `sycdoc-update-type-hierarchy' in
> - ;; `admin/syncdoc-type-hierarchy.el' each time this is modified to
> - ;; reflect the change in the documentation.
> - (let ((table (make-hash-table :test #'eq)))
> - (mapatoms
> - (lambda (type)
> - (let ((class (get type 'cl--class)))
> - (when (built-in-class-p class)
> - (puthash type (mapcar #'cl--class-name (cl--class-parents class))
> - table)))))
> - table)
> - "Hash table TYPE -> SUPERTYPES.")
> -
> -(defconst cl--typeof-types
> - (letrec ((alist nil))
> - (maphash (lambda (type _)
> - (let ((class (get type 'cl--class)))
> - ;; FIXME: Can't remember why `t' is excluded.
> - (push (remq t (cl--class-allparents class)) alist)))
> - cl--direct-supertypes-of-type)
> - alist)
> - "Alist of supertypes.
> -Each element has the form (TYPE . SUPERTYPES) where TYPE is one of
> -the symbols returned by `type-of', and SUPERTYPES is the list of its
> -supertypes from the most specific to least specific.")
> -
> -(defconst cl--all-builtin-types
> - (delete-dups (copy-sequence (apply #'append cl--typeof-types))))
> -
> ;; Make sure functions defined with cl-defsubst can be inlined even in
> ;; packages which do not require CL. We don't put an autoload cookie
> ;; directly on that function, since those cookies only go to cl-loaddefs.
> diff --git a/lisp/emacs-lisp/comp-cstr.el b/lisp/emacs-lisp/comp-cstr.el
> index 1c6acaa6385..5922a8caf12 100644
> --- a/lisp/emacs-lisp/comp-cstr.el
> +++ b/lisp/emacs-lisp/comp-cstr.el
> @@ -38,12 +38,6 @@
> (require 'cl-lib)
> (require 'cl-extra) ;HACK: For `cl-find-class' when `cl-loaddefs' is missing.
>
> -(defconst comp--typeof-builtin-types (mapcar (lambda (x)
> - (append x '(t)))
> - cl--typeof-types)
> - ;; TODO can we just add t in `cl--typeof-types'?
> - "Like `cl--typeof-types' but with t as common supertype.")
> -
> (cl-defstruct (comp-cstr (:constructor comp--type-to-cstr
> (type &aux
> (null (eq type 'null))
> @@ -89,15 +83,7 @@ Integer values are handled in the `range' slot.")
>
> (defun comp--cl-class-hierarchy (x)
> "Given a class name `x' return its hierarchy."
> - (let ((parents (cl--class-allparents (cl--struct-get-class x))))
> - (if (memq t parents)
> - parents
> - `(,@parents
> - ;; FIXME: AFAICT, `comp--all-classes' will also find those struct types
> - ;; which use :type and can thus be either `vector' or `cons' (the latter
> - ;; isn't `atom').
> - atom
> - t))))
> + (cl--class-allparents (cl--find-class x)))
>
> (defun comp--all-classes ()
> "Return all non built-in type names currently defined."
> @@ -109,8 +95,7 @@ Integer values are handled in the `range' slot.")
> res))
>
> (defun comp--compute-typeof-types ()
> - (append comp--typeof-builtin-types
> - (mapcar #'comp--cl-class-hierarchy (comp--all-classes))))
> + (mapcar #'comp--cl-class-hierarchy (comp--all-classes)))
>
> (defun comp--compute--pred-type-h ()
> (cl-loop with h = (make-hash-table :test #'eq)
> @@ -275,19 +260,10 @@ Return them as multiple value."
> (symbol-name y)))
>
> (defun comp--direct-supertypes (type)
> - (or
> - (gethash type cl--direct-supertypes-of-type)
> - (let ((supers (comp-supertypes type)))
> - (cl-assert (eq type (car supers)))
> - (cl-loop
> - with notdirect = nil
> - with direct = nil
> - for parent in (cdr supers)
> - unless (memq parent notdirect)
> - do (progn
> - (push parent direct)
> - (setq notdirect (append notdirect (comp-supertypes parent))))
> - finally return direct))))
> + (when (symbolp type) ;; FIXME: Can this test ever fail?
> + (let* ((class (cl--find-class type))
> + (parents (if class (cl--class-parents class))))
> + (mapcar #'cl--class-name parents))))
>
> (defsubst comp-subtype-p (type1 type2)
> "Return t if TYPE1 is a subtype of TYPE2 or nil otherwise."
> @@ -359,23 +335,8 @@ Return them as multiple value."
>
> (defun comp-supertypes (type)
> "Return the ordered list of supertypes of TYPE."
> - ;; FIXME: We should probably keep the results in
> - ;; `comp-cstr-ctxt-typeof-types' (or maybe even precompute them
> - ;; and maybe turn `comp-cstr-ctxt-typeof-types' into a hash-table).
> - ;; Or maybe we shouldn't keep structs and defclasses in it,
> - ;; and just use `cl--class-allparents' when needed (and refuse to
> - ;; compute their direct subtypes since we can't know them).
> - (cl-loop
> - named loop
> - with above
> - for lane in (comp-cstr-ctxt-typeof-types comp-ctxt)
> - do (let ((x (memq type lane)))
> - (cond
> - ((null x) nil)
> - ((eq x lane) (cl-return-from loop x)) ;A base type: easy case.
> - (t (setq above
> - (if above (comp--intersection x above) x)))))
> - finally return above))
> + (or (assq type (comp-cstr-ctxt-typeof-types comp-ctxt))
> + (error "Type %S missing from typeof-types!" type)))
>
> (defun comp-union-typesets (&rest typesets)
> "Union types present into TYPESETS."
> diff --git a/lisp/emacs-lisp/eieio-core.el b/lisp/emacs-lisp/eieio-core.el
> index 9945e19c65c..5418f53be35 100644
> --- a/lisp/emacs-lisp/eieio-core.el
> +++ b/lisp/emacs-lisp/eieio-core.el
> @@ -191,7 +191,7 @@ Abstract classes cannot be instantiated."
>
> ;; We autoload this because it's used in `make-autoload'.
> ;;;###autoload
> -(defun eieio-defclass-autoload (cname _superclasses filename doc)
> +(defun eieio-defclass-autoload (cname superclasses filename doc)
> "Create autoload symbols for the EIEIO class CNAME.
> SUPERCLASSES are the superclasses that CNAME inherits from.
> DOC is the docstring for CNAME.
> @@ -199,15 +199,9 @@ This function creates a mock-class for CNAME and adds it into
> SUPERCLASSES as children.
> It creates an autoload function for CNAME's constructor."
> ;; Assume we've already debugged inputs.
> -
> - ;; We used to store the list of superclasses in the `parent' slot (as a list
> - ;; of class names). But now this slot holds a list of class objects, and
> - ;; those parents may not exist yet, so the corresponding class objects may
> - ;; simply not exist yet. So instead we just don't store the list of parents
> - ;; here in eieio-defclass-autoload at all, since it seems that they're just
> - ;; not needed before the class is actually loaded.
> (let* ((oldc (cl--find-class cname))
> - (newc (eieio--class-make cname)))
> + (newc (eieio--class-make cname))
> + (parents (mapcar #'cl-find-class superclasses)))
> (if (eieio--class-p oldc)
> nil ;; Do nothing if we already have this class.
>
> @@ -218,6 +212,12 @@ It creates an autoload function for CNAME's constructor."
> use '%s or turn off `eieio-backward-compatibility' instead" cname)
> "25.1"))
>
> + (when (memq nil parents)
> + ;; If some parents aren't yet fully defined, just ignore them for now.
> + (setq parents (delq nil parents)))
> + (unless parents
> + (setq parents (list (cl--find-class 'eieio-default-superclass))))
> + (setf (cl--class-parents newc) parents)
> (setf (cl--find-class cname) newc)
>
> ;; Create an autoload on top of our constructor function.
> @@ -958,19 +958,13 @@ need be... May remove that later...)"
> (cdr tuple)
> nil)))
>
> -(defsubst eieio--class/struct-parents (class)
> - (or (eieio--class-parents class)
> - `(,eieio-default-superclass)))
> -
> (defun eieio--class-precedence-c3 (class)
> "Return all parents of CLASS in c3 order."
> (let ((parents (eieio--class-parents class)))
> (cons class
> (merge-ordered-lists
> (append
> - (or
> - (mapcar #'eieio--class-precedence-c3 parents)
> - `((,eieio-default-superclass)))
> + (mapcar #'eieio--class-precedence-c3 parents)
> (list parents))
> (lambda (remaining-inputs)
> (signal 'inconsistent-class-hierarchy
> @@ -984,13 +978,11 @@ need be... May remove that later...)"
> (classes (copy-sequence
> (apply #'append
> (list class)
> - (or
> - (mapcar
> - (lambda (parent)
> - (cons parent
> - (eieio--class-precedence-dfs parent)))
> - parents)
> - `((,eieio-default-superclass))))))
> + (mapcar
> + (lambda (parent)
> + (cons parent
> + (eieio--class-precedence-dfs parent)))
> + parents))))
> (tail classes))
> ;; Remove duplicates.
> (while tail
> @@ -1003,13 +995,12 @@ need be... May remove that later...)"
> (defun eieio--class-precedence-bfs (class)
> "Return all parents of CLASS in breadth-first order."
> (let* ((result)
> - (queue (eieio--class/struct-parents class)))
> + (queue (eieio--class-parents class)))
> (while queue
> (let ((head (pop queue)))
> (unless (member head result)
> (push head result)
> - (unless (eq head eieio-default-superclass)
> - (setq queue (append queue (eieio--class/struct-parents head)))))))
> + (setq queue (append queue (eieio--class-parents head))))))
> (cons class (nreverse result)))
> )
>
> @@ -1049,6 +1040,14 @@ method invocation orders of the involved classes."
>
> ;;;; General support to dispatch based on the type of the argument.
>
> +;; FIXME: We could almost use the typeof-generalizer (i.e. the same as
> +;; used for cl-structs), except that that generalizer doesn't support
> +;; `:method-invocation-order' :-(
> +
> +(defun cl--generic-struct-tag (name &rest _)
> + ;; Use exactly the same code as for `typeof'.
> + `(if ,name (type-of ,name) 'null))
> +
> (cl-generic-define-generalizer eieio--generic-generalizer
> ;; Use the exact same tagcode as for cl-struct, so that methods
> ;; that dispatch on both kinds of objects get to share this
>
>
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 96%]
* Re: I created a faster JSON parser
@ 2024-03-08 11:41 97% ` Philip Kaludercic
1 sibling, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-03-08 11:41 UTC (permalink / raw)
To: Herman, Géza; +Cc: emacs-devel@gnu.org
"Herman, Géza" <geza.herman@gmail.com> writes:
> Hi,
>
> I created a faster JSON parser for emacs, you can check it out here:
>
> https://github.com/geza-herman/emacs/tree/faster-json-parsing
For convenience, this is a URL to the patch:
https://github.com/geza-herman/emacs/commit/d76feeeac3ce397f15aebdde8b9deae676b0bf1e.patch
>
> It replaces json-parse-string and json-parse-buffer functions. The
> behavior should be the same as before, with the only exception that
> objects with duplicated keys are not detected if :object-type is not
> 'hash-table.
Is that a problem?
> This parser runs 8-9x faster than the jansson based parser on my
> machine (tested on clangd language server messages). An additional
> tiny benefit is that large integers are parsed, instead of having an
> "out of range" error.
That sounds interesting, but I am reminded of this article:
https://seriot.ch/projects/parsing_json.html. There seem to be plenty
of difficult edge-cases when dealing with JSON input, that should
probably be tested if Emacs has it's own custom parser built-in.
> What do you think?
>
> Geza
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 97%]
* Re: [ELPA] new single file package: mpdired.el
@ 2024-03-08 11:26 91% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-03-08 11:26 UTC (permalink / raw)
To: Manuel Giraud; +Cc: Manuel Giraud via Emacs development discussions.
Manuel Giraud <manuel@ledu-giraud.fr> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
> Hi Philip,
>
> First thanks for your all your inputs!
>
> [...]
>
>> In the end a Git repository will have to be created. I don't think one
>> should have to be ashamed of the commit history (most people won't
>> care), but it is also fine to discard the current history and replace it
>> with a fresh repository.
>
> Ok. Maybe I'll start with a fresh history if I feel like it.
>
>> By default, we would like to mirror some external repository. It
>> doesn't have to be hosted by some large Git forge, just something that
>> can be synchronised regularly. The alternative to this would be to have
>> a branch in elpa.git that would have to be manually updated (either by
>> yourself if you get access to the repository, or by someone here on the
>> mailing list with access that would see your message). You can imagine
>> that we want to avoid the latter setup, since it creates more
>> friction.
>
> Of course, I'd also like to avoid this latter setup. Just to be sure,
> you confirm that a git repo is unavoidable? Could it be a just tarball
> available on web server?
Technically yes, but the ELPA build system would have to be updated just
for this use-case.
>> From experience, it is usually helpful to have a Git repository with
>> multiple files, for files like a README or an .elpaignore file or if you
>> decide to split up the file into multiple files at some point.
>
> Yes, you're right maybe I'd like to add a texinfo later for instance.
>
>> If you dislike Github, you could also take a look at Sourcehut or
>> Codeberg for hosting.
>
> Ok. If a git forge is mandatory, I'll ponder which one I'd prefer to
> use.
As I said, a git forge in that sense is not necessarily needed, you
could also just host the git repository from some website over https://.
>>> Anyway for the braves and curious, here is the current version of this
>>> package. It is called MPDired and is yet another client to Music Player
>>> Daemon. It features a Dired-like user interface. Previously I was a
>>> Mingus user so MPDired might have some legacy to it.
>>
>> Here some comments
>
> For the rest of your comments inline, I'll just ask on those I don't
> understand.
>
> [...]
>
>>> "n" #'mpdired-next-line
>>> "<down>" #'mpdired-next-line
>>
>> Perhaps one could also rebind a few commands here, like `next-line'.
>
> I don't understand what you mean here.
It is possible to remap a command, without having to bind a key. See
(elisp) Remapping Commands. The advantage is that if the user has any
custom bindings, say for next-line, then they would automatically be
inherited. That is comfortable from a user-perspective, because the
major-mode aligns more with their usual intuition.
> [...]
>
>>> (defun mpdired-change-marks (&optional old new)
>>> "Changes mark from OLD to NEW. It asks the user for OLD and NEW."
>>> (interactive
>>> (let* ((cursor-in-echo-area t)
>>> (old (progn (message "Change (old mark): ") (read-char)))
>>> (new (progn (message "Change %c marks to (new mark): " old)
>>> (read-char))))
>>
>> Why not use read-char's PROMPT argument?
>
> I did not know about it and it is copy-pasto from dired ;-)
I don't know if there are any peculiar edge-cases either, perhaps
someone else knows more?
> Thanks.
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 91%]
* Re: [ELPA] new single file package: mpdired.el
@ 2024-03-08 10:25 61% ` Philip Kaludercic
0 siblings, 2 replies; 200+ results
From: Philip Kaludercic @ 2024-03-08 10:25 UTC (permalink / raw)
To: Manuel Giraud via Emacs development discussions.; +Cc: Manuel Giraud
Manuel Giraud via "Emacs development discussions." <emacs-devel@gnu.org>
writes:
>
> Hi,
>
> I've made a package that consists of a single .el file. I'd like to
> distribute it like that: I don't really want to share its version
> history (not proud of it ;-) and I don't want to put it on github or the
> like. According to the ELPA readme, it is possible to do so by sending
> the file to this list. My question is: how does update takes place
> then? Should I resend the new version to this list or is there other
> mean?
In the end a Git repository will have to be created. I don't think one
should have to be ashamed of the commit history (most people won't
care), but it is also fine to discard the current history and replace it
with a fresh repository.
By default, we would like to mirror some external repository. It
doesn't have to be hosted by some large Git forge, just something that
can be synchronised regularly. The alternative to this would be to have
a branch in elpa.git that would have to be manually updated (either by
yourself if you get access to the repository, or by someone here on the
mailing list with access that would see your message). You can imagine
that we want to avoid the latter setup, since it creates more friction.
From experience, it is usually helpful to have a Git repository with
multiple files, for files like a README or an .elpaignore file or if you
decide to split up the file into multiple files at some point.
If you dislike Github, you could also take a look at Sourcehut or
Codeberg for hosting.
> Anyway for the braves and curious, here is the current version of this
> package. It is called MPDired and is yet another client to Music Player
> Daemon. It features a Dired-like user interface. Previously I was a
> Mingus user so MPDired might have some legacy to it.
Here some comments
> Best regards,
> ;;; mpdired.el --- A dired-like client for Music Player Daemon -*- lexical-binding: t -*-
>
> ;; Copyright (C) 2024 Manuel Giraud
>
> ;; Author: Manuel Giraud <manuel@ledu-giraud.fr>
> ;; Keywords: multimedia
>
> ;; SPDX-License-Identifier: GPL-3.0-or-later
This is not really needed, since package.el doesn't check this header.
> ;; This file is NOT part of GNU Emacs.
>
> ;; GNU Emacs 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.
> ;;
> ;; GNU Emacs 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 GNU Emacs. If not, see <https://www.gnu.org/licenses/>.
>
> ;;; Commentary:
> ;;
> ;; This a client for the Music Player Daemon (mpd) with interactions
> ;; inspired from Dired. It features two views packed into the same
> ;; interactive buffer: the browser view and the queue view.
> ;;
> ;; In those view, most of the interactions are mimic after Dired mode
> ;; with marks and action on them. For example, in the queue view, you
> ;; could flag songs for removal with `d' and then execute with `x'.
> ;;
> ;; MPDired connects to a MPD server using two customs: `mpdired-host'
> ;; and `mpdired-port'. Once connected, the handle to the server is
> ;; saved in a buffer local variable into the MPDired buffer. From now
> ;; on, the customs are just used by global MPDired commands to connect
> ;; to the user defined server. All commands used inside a MPDired
> ;; buffer will connect to the buffer local server. This way, you can
> ;; manage more than one MPD server with multiple MPDired buffers.
>
> ;;; Philosophy:
Perhaps indent this by one more ;, so that it still remains in the
Commentary section.
> ;; MPDired is designed to be the least intrusive. Nothing will be
> ;; shown into the mode line, which I consider to be user's territory.
> ;; There is no timers set by MPDired, so updating anything always
> ;; comes from a user action.
> ;;
> ;; The browser view is built from the MPD's "listall" and
> ;; "listplaylists" commands. The MPD's documentation does *not*
> ;; recommend to do so but AFAIU there is no other way to access your
> ;; music collection in terms of directories and files. As my music
> ;; collection is already ordered into directories and with meaningful
> ;; filenames, I prefer to use this interface rather then to rely on
> ;; files' tags.
> ;;
> ;; If your music collection consists of just a set of not very well
> ;; named files into one big directory and that you rely on tags such
> ;; as "Genre", "Album", "Artist" to find your way through it then,
> ;; maybe, MPDired is not the right client for you.
>
> ;;; Bugs & Funs:
> ;;
> ;; - MPDired does not handle MPD server with password.
> ;;
> ;; - Marks are *very* temporary. As I rebuild the views often and the
> ;; marks are only stored in text properties they will be wiped out
> ;; regularly.
> ;;
> ;; - some URI based commands work in both view. So for example, in the
> ;; queue, you can append the song at point to this same queue.
>
> ;;; Code:
>
> (defcustom mpdired-host (or (getenv "MPD_HOST") "localhost")
> "Host for MPD."
> :type 'string)
>
> (defcustom mpdired-port (or (getenv "MPD_PORT") 6600)
getenv will return a string, perhaps you want to do something like
--8<---------------cut here---------------start------------->8---
(let ((port (string-to-number (getenv "MPD_PORT"))))
(if (/= port 0) port 6600))
--8<---------------cut here---------------end--------------->8---
> "Port for MPD."
> :type 'integer)
Perhaps 'natnum as a type would be mor especific here.
>
> (defvar-keymap mpdired-mode-map
Using defvar-keymap depends on Emacs 29, so you should explicitly state
the version of Emacs you need in the package header.
> :doc "Local keymap for MPDired."
> :full t
> :parent special-mode-map
> ;; Navigation
> "C-n" #'mpdired-next-line
> "n" #'mpdired-next-line
> "<down>" #'mpdired-next-line
Perhaps one could also rebind a few commands here, like `next-line'.
> "C-p" #'mpdired-previous-line
> "p" #'mpdired-previous-line
> "<up>" #'mpdired-previous-line
> "C-m" #'mpdired-enter
> "^" #'mpdired-goto-parent
> "o" #'mpdired-toggle-view
> ;; Actions
> "g" #'mpdired-update
> "G" #'mpdired-db-update
> "N" #'mpdired-next-internal
> "P" #'mpdired-previous-internal
> "a" #'mpdired-add
> "x" #'mpdired-flagged-delete
> "D" #'mpdired-delete
> ;; Status settings and toggles
> "<SPC>" #'mpdired-pause-internal
> "v" #'mpdired-set-volume-internal
> "s s" #'mpdired-stop
> "s R" #'mpdired-toggle-repeat
> "s r" #'mpdired-toggle-random
> "s S" #'mpdired-toggle-single
> "s c" #'mpdired-toggle-consume
> ;; Playlist commands
> "l c" #'mpdired-playlist-create
> "l a" #'mpdired-playlist-append
> ;; Marks
> "m" #'mpdired-mark-at-point
> "* m" #'mpdired-mark-at-point
> "d" #'mpdired-flag-at-point
> "u" #'mpdired-unmark-at-point
> "<DEL>" #'mpdired-previous-unmark
> "* !" #'mpdired-unmark-all-marks
> "U" #'mpdired-unmark-all-marks
> "t" #'mpdired-toggle-marks
> "* t" #'mpdired-toggle-marks
> "* c" #'mpdired-change-marks
> "% d" #'mpdired-flag-files-regexp
> "% m" #'mpdired-mark-files-regexp)
>
> (defface mpdired-currdir
> '((t :inherit dired-header))
> "Face used to show current directory.")
>
> (defface mpdired-directory
> '((t :inherit dired-directory))
> "Face used to show a directory.")
>
> (defface mpdired-playlist
> '((t :inherit dired-symlink))
> "Face used to show a playlist.")
>
> (defface mpdired-song
> '((t :inherit dired-ignored))
> "Face used to show a song.")
>
> (defface mpdired-progress
> '((t :inherit dired-special))
> "Face used to show the progress of a song.")
>
> (defface mpdired-marked
> '((t :inherit dired-marked))
> "Face used to show a marked entry.")
>
> (defface mpdired-flagged
> '((t :inherit dired-flagged))
> "Face used to show an entry flagged for deletion.")
>
> ;; State variables for the communication buffer
> (defvar-local mpdired--network-params nil)
> (defvar-local mpdired--parse-endp nil)
> (defvar-local mpdired--last-command nil)
> (defvar-local mpdired--main-buffer nil
> "Link to the main MPDired buffer.")
> (defvar-local mpdired--ascending-p nil)
> (defvar-local mpdired--playlist nil)
> (defvar-local mpdired--message nil)
>
> (defun mpdired--subdir-p (dir-a dir-b)
> "Is DIR-B a sub-directory of DIR-A?"
> (let ((pos (string-search dir-a dir-b)))
> (and pos (zerop pos))))
I think a more robust approach would be something like
(locate-dominating-file dir-b (apply-partially #'file-equal-p dir-a))
or `file-in-directory-p'.
>
> (defun mpdired--parse-listall-1 (current accum)
> ;; Recursively rebuild the directory hierarchy from a "listall"
> ;; command into a list. In the output, a directory is list which
> ;; `car' is its name and its `cdr' is the files or other directory
> ;; it contains. Leaves are conses in the form '(file . "name") or
> ;; '(playlist . "name").
> (catch 'exit
> (while (not (or mpdired--parse-endp
> (setq mpdired--parse-endp
> (re-search-forward "^\\(OK\\|ACK.*\\)$"
> (line-end-position) t 1))))
> ;; Look for file, playlist or directory line by line.
> (when
> (re-search-forward "^\\(file\\|playlist\\|directory\\): \\(.*\\)$"
> (line-end-position) t 1)
> (let ((type (match-string 1))
> (name (match-string 2)))
> (cond ((or (string= "file" type)
> (string= "playlist" type))
> (push (cons (intern type) name) accum))
> ((string= "directory" type)
> ;; This new directory NAME is either a subdir of the
> ;; current one or a new directory of the same level
> ;; of the current one. In the former case, we need
> ;; to parse and accumuate this new sub-directory. In
> ;; the latter case we need to go one line backward
> ;; (because we will go forward later) and quit the
> ;; current loop.
> (cond ((mpdired--subdir-p current name)
> (forward-line)
> (push (mpdired--parse-listall-1 name (list name)) accum))
> (t (forward-line -1)
> (throw 'exit t)))))))
> (forward-line)))
> (reverse accum))
Unless I am missing something, it would be more ideomatic to use
`nreverse' here.
>
> (defun mpdired--parse-listall ()
> ;; Called from the communication buffer.
> (goto-char (point-min))
> (setq mpdired--parse-endp nil)
> ;; XXX Empty string is the directory name of the toplevel directory.
> ;; It have the good property of being a prefix of any string so it
> ;; works with `mpdired--subdir-p'.
> (mpdired--parse-listall-1 "" (list "")))
>
> ;; All my functions are called *-queue but they are using the correct
> ;; "playlistid" MPD interface.
> (defun mpdired--parse-queue ()
> ;; Called from the communication buffer.
> (goto-char (point-min))
> (setq mpdired--parse-endp nil)
> (let ((elapsed 0)
> (duration 1)
> (songid 0)
> (in-status-p t)
There appear to be some stray TABs here.
> state volume repeat random single consume
> result file time id)
> (while (not (or mpdired--parse-endp
> (setq mpdired--parse-endp
> (re-search-forward "^\\(OK\\|ACK.*\\)$"
> (line-end-position) t 1))))
> (let ((eol (line-end-position)))
> ;; First, "status" content
> (when in-status-p
> (when (re-search-forward "^state: \\(.*\\)$" eol t 1)
> (setq state (match-string 1)))
> (when (re-search-forward "^volume: \\([0-9]+\\)$" eol t 1)
> (setq volume (string-to-number (match-string 1))))
> (when (re-search-forward "^repeat: \\([0-9]+\\)$" eol t 1)
> (setq repeat (string= "1" (match-string 1))))
> (when (re-search-forward "^random: \\([0-9]+\\)$" eol t 1)
> (setq random (string= "1" (match-string 1))))
> (when (re-search-forward "^single: \\([0-9]+\\)$" eol t 1)
> (setq single (string= "1" (match-string 1))))
> (when (re-search-forward "^consume: \\([0-9]+\\)$" eol t 1)
> (setq consume (string= "1" (match-string 1))))
> ;; current song status
> (when (re-search-forward "^songid: \\([0-9]+\\)$" eol t 1)
> (setq songid (string-to-number (match-string 1))))
> (when (re-search-forward "^time: \\([0-9]+\\):\\([0-9]+\\)$" eol t 1)
> (setq elapsed (string-to-number (match-string 1))
> duration (string-to-number (match-string 2)))))
> ;; When we enconter our first "file:" the status parsing is
> ;; done so store what we've discovered so far and do not try
> ;; to parse status anymore.
> (when (and in-status-p
> (save-excursion (re-search-forward "^file: .*$" eol t 1)))
> (setq in-status-p nil)
> ;; Save status in main buffer and put current song infos at
> ;; the beginning of the result.
> (with-current-buffer mpdired--main-buffer
> (setq mpdired--status
> (list state volume repeat random single consume)))
> (push songid result)
> (push elapsed result)
> (push duration result))
> ;; Then, "playlistid" content
> ;; File
> (when (re-search-forward "^file: \\(.*\\)$" eol t 1)
> ;; if file is already set store the previous entry in the
> ;; list.
> (when file
> (push (list id file time) result))
> (setq file (match-string 1)))
> ;; Time
> (when (re-search-forward "^Time: \\(.*\\)$" eol t 1)
> (setq time (string-to-number (match-string 1))))
> ;; Id
> (when (re-search-forward "^Id: \\(.*\\)$" eol t 1)
> (setq id (string-to-number (match-string 1)))))
> (forward-line))
> ;; There was only status but no songs
> (when in-status-p
> ;; Save status in main buffer
> (with-current-buffer mpdired--main-buffer
> (setq mpdired--status
> (list state volume repeat random single consume)))
> (push songid result)
> (push elapsed result)
> (push duration result))
> ;; The last song if any
> (when file (push (list id file time) result))
> (reverse result)))
>
> (defun mpdired-mode ()
Why not use `define-derived-mode'?
> "Major mode for MPDired."
> (use-local-map mpdired-mode-map)
> (set-buffer-modified-p nil)
> (setq major-mode 'mpdired-mode
> mode-name "MPDired"
> truncate-lines t
> buffer-read-only t))
>
> (defun mpdired--hostname (host service localp)
> (if localp
> (let ((inode (file-attribute-inode-number
> (file-attributes service))))
> (format "/%d" inode))
> (if (= 6600 service)
> host
> (format "%s:%s" host service))))
>
> (defun mpdired--comm-name (host service localp)
> (format " *mpdired-comm-%s*" (mpdired--hostname host service localp)))
>
> (defun mpdired--main-name (host service localp)
> (format "*MPDired (%s)*" (mpdired--hostname host service localp)))
>
> ;; State variables for the main buffer
> (defvar-local mpdired--view nil
> "Current view of the MPDired buffer.")
> (defvar-local mpdired--directory nil
> "Current directory (or MPD playlist) of the browser view.")
> (defvar-local mpdired--comm-buffer nil
> "Communication buffer associated to this MPDired buffer.")
> (defvar-local mpdired--status nil
> "Local copy of the MPD status. It will updated regularly.")
> (defvar-local mpdired--error nil)
>
> ;; I have tried to use markers here but since I often erase the
> ;; buffer's content, these markers are reset to 1.
> (defvar-local mpdired--browser-point nil
> "Saved point position in the browser view.")
> (defvar-local mpdired--songid-point nil
> "Songid for point position in the queue view.")
>
> (defun mpdired--bol ()
> "Correct beginning of line in a MPDired buffer. First two columns are
> used for mark followed by a space."
> (+ 2 (line-beginning-position)))
Perhaps one should check if this is still part of the same line with
cl-assert or something like that.
>
> (defun mpdired--short-name (string)
> (car (last (split-string string "/"))))
Also possible,
--8<---------------cut here---------------start------------->8---
(and (string-match "/\\([^/]*\\)\\'" string)
(match-string 1 string))
--8<---------------cut here---------------end--------------->8---
as to avoid unnecessarily consing the entire list.
>
> (defun mpdired--reset-face ()
> (let* ((bol (mpdired--bol))
> (eol (line-end-position))
> (type (get-text-property bol 'type))
> (mark (get-text-property bol 'mark)))
> (remove-text-properties bol eol '(face))
> (cond ((and mark (char-equal mark ?d))
> (put-text-property bol eol 'face 'mpdired-flagged))
> ((and mark (char-equal mark ?*))
> (put-text-property bol eol 'face 'mpdired-marked))
> ((eq type 'directory)
> (put-text-property bol eol 'face 'mpdired-directory))
> ((eq type 'playlist)
> (put-text-property bol eol 'face 'mpdired-playlist))
> ((eq type 'song)
> (put-text-property bol eol 'face 'mpdired-song)))))
>
> (defun mpdired--insert-entry (entry)
> "Insert ENTRY in MPDired browser view."
> (insert " ")
> (let ((bol (mpdired--bol)))
> (when (consp entry)
> (let ((type (car entry)))
> (cond ((stringp type) ;; this is a directory
> (insert (propertize (mpdired--short-name type) 'face 'mpdired-directory))
> (put-text-property bol (line-end-position) 'type 'directory)
> (put-text-property bol (line-end-position) 'uri type))
> ((eq type 'file)
> (let ((file (cdr entry)))
> (insert (mpdired--short-name file))
> (put-text-property bol (line-end-position) 'type 'file)
> (put-text-property bol (line-end-position) 'uri file)))
> ((eq type 'playlist)
> (let ((playlist (cdr entry)))
> (insert (propertize (mpdired--short-name playlist)
> 'face 'mpdired-playlist))
> (put-text-property bol (line-end-position) 'type 'playlist)
> (put-text-property bol (line-end-position) 'uri playlist))))))
> (insert "\n")))
>
> (defun mpdired--insert-status ()
> "Insert current status in MPDired queue view."
> (when mpdired--status
> (let* ((state (car mpdired--status))
> (volume (nth 1 mpdired--status))
> (repeat (nth 2 mpdired--status))
> (random (nth 3 mpdired--status))
> (single (nth 4 mpdired--status))
> (consume (nth 5 mpdired--status))
> (string (cond ((string= "stop" state) "Stopped")
> ((string= "play" state) "Playing")
> ((string= "pause" state) "Paused"))))
> (insert (propertize string 'face 'bold))
> (when (numberp volume)
> (insert (format " Volume: %d" volume)))
> (when repeat (insert " Repeat"))
> (when random (insert " Random"))
> (when single (insert " Single"))
> (when consume (insert " Consume"))
> (insert "\n"))))
>
> (defun mpdired--insert-song (song)
> "Insert SONG in MPDired queue view."
> (let ((id (car song))
> (uri (cadr song)))
> (insert " " (propertize uri 'face 'mpdired-song))
> (let ((bol (mpdired--bol))
> (eol (line-end-position)))
> (put-text-property bol eol 'id id)
> (put-text-property bol eol 'type 'song)
> (put-text-property bol eol 'uri uri))
> (insert "\n")))
>
> (defun mpdired--goto-id (songid)
> (let ((max (point-max)))
> (while (and (< (point) max)
> (let ((id (get-text-property (mpdired--bol) 'id)))
> (or (null id)
> (and id (/= songid id)))))
> (mpdired--next-line))))
>
> (defun mpdired--present-list (proc)
> ;; Called by filter of the communication buffer.
> (let* ((peer-info (process-contact proc t))
> (peer-host (plist-get peer-info :host))
> (peer-service (plist-get peer-info :service))
> (peer-localp (eq (plist-get peer-info :family) 'local))
> (main-buffer (mpdired--main-name peer-host peer-service peer-localp))
> (content (mpdired--parse-listall))
> ascending-p from)
> ;; Retrieve infos from this process buffer
> (with-current-buffer (process-buffer proc)
> (setq ascending-p mpdired--ascending-p
> playlist mpdired--playlist))
> (with-current-buffer (get-buffer-create main-buffer)
> (let* ((inhibit-read-only t)
> ;; `content' is always of the form ("" rest...) so if
> ;; there is only one element in rest use it as content.
> (content (if (cddr content) content (cadr content)))
> (top (if playlist
> playlist
> (unless (string= "" (car content)) (car content))))
> (data (cdr content)))
> (erase-buffer)
> ;; Insert the content
> (save-excursion
> (when (stringp top)
> (insert (propertize top 'face 'mpdired-currdir) ":\n"))
> (dolist (e data) (mpdired--insert-entry e)))
> ;; Set mode and memorize stuff
> (mpdired-mode)
> (if ascending-p (setq from mpdired--directory))
> (setq mpdired--directory (when top top)
> mpdired--comm-buffer (process-buffer proc)
> mpdired--view 'browser)
> ;; Finally move point to the correct place.
> (cond ((and ascending-p from)
> (goto-char (point-min))
> (let ((max (point-max)))
> (while (and (< (point) max)
Why not use `eobp'?
> (let ((uri (get-text-property (mpdired--bol) 'uri)))
> (or (null uri)
> (and uri (not (string= from uri))))))
> (forward-line)))
> (goto-char (mpdired--bol))
> (setq mpdired--browser-point (point)))
> (mpdired--browser-point
> (goto-char mpdired--browser-point)
> (goto-char (mpdired--bol)))
> (t (goto-char (point-min))
> (if top
> (mpdired-next-line)
> (goto-char (mpdired--bol)))))))))
>
> (defun mpdired--present-queue (proc)
> ;; Called by filter of the communication buffer.
> (let* ((peer-info (process-contact proc t))
> (peer-host (plist-get peer-info :host))
> (peer-service (plist-get peer-info :service))
> (peer-localp (eq (plist-get peer-info :family) 'local))
> (main-buffer (mpdired--main-name peer-host peer-service peer-localp))
> (data (mpdired--parse-queue))
> (songid (car data))
> (elapsed (cadr data))
> (duration (caddr data))
> (songs (cdddr data)))
> (with-current-buffer (get-buffer-create main-buffer)
> (let ((inhibit-read-only t))
> (erase-buffer)
> ;; Insert content
> (save-excursion
> ;; Status header
> (mpdired--insert-status)
> ;; Songs
> (dolist (song songs) (mpdired--insert-song song)))
I think in this case, you could also use (mapc #'mpdired--insert-song songs).
> ;; Go to the current song and display elasped time with a
> ;; different face on its URI.
> (save-excursion
> (when songid
> (let ((max (point-max)))
> (while (and (< (point) max)
> (let ((id (get-text-property (mpdired--bol) 'id)))
> (or (null id)
> (and id (/= songid id)))))
> (forward-line)))
> (let* ((bol (mpdired--bol))
> (eol (line-end-position))
> (x (/ (* elapsed (- eol bol)) duration)))
> (put-text-property bol (+ bol x) 'face 'mpdired-progress))))
> ;; Go to bol no matter what
> (goto-char (mpdired--bol))
> ;; Set mode, restore point and memorize stuff
> (mpdired-mode)
> (when mpdired--songid-point
> (mpdired--goto-id mpdired--songid-point))
> (setq mpdired--comm-buffer (process-buffer proc)
> mpdired--view 'queue)))))
>
> (defun mpdired--filter (proc string)
> (when (buffer-live-p (process-buffer proc))
> (with-current-buffer (process-buffer proc)
> (let ((moving (= (point) (process-mark proc))))
> (save-excursion
> ;; Insert the text, advancing the process marker.
> (goto-char (process-mark proc))
> (insert string)
> (set-marker (process-mark proc) (point)))
> (if moving (goto-char (process-mark proc)))
> ;; The server has replied.
> (cond ((re-search-backward "^ACK \\(.*\\)$" nil t)
> ;; For errors on "listall" and "listplaylist" commands
> ;; propagate the error upstream because actions would
> ;; be taken. Otherwise, just output it.
> (cond ((string= (match-string 1)
> "[50@0] {listall} No such directory")
> (with-current-buffer mpdired--main-buffer
> (setq mpdired--error 'no-directory)))
> ((string= (match-string 1)
> "[50@0] {listplaylist} No such playlist")
> (with-current-buffer mpdired--main-buffer
> (setq mpdired--error 'no-playlist)))
> (t (message (match-string 1)))))
> ((re-search-backward "^OK$" nil t)
> ;; Present results in the main buffer
> (cond ((or (eq mpdired--last-command 'listall)
> (eq mpdired--last-command 'listplaylist))
> (mpdired--present-list proc))
> ((or (eq mpdired--last-command 'queue)
> (eq mpdired--last-command 'deleteid))
> (mpdired--present-queue proc)))
> ;; Display and reset information message.
> (when mpdired--message
> (message (format "%s done." mpdired--message))
> (setq mpdired--message nil))))))))
>
> (defun mpdired--local-p (host)
> "Is HOST a local socket?"
> ;; Hack: if the `expand-file-name' of host leads to an existing
> ;; file, that should be our Unix socket.
> (file-exists-p (expand-file-name host)))
>
> (defun mpdired--maybe-reconnect (comm-buffer)
> "If COMM-BUFFER is disconnected, reconnect it to its server."
> (let ((process (get-buffer-process comm-buffer)))
> (unless (and process (eq (process-status process) 'open))
> ;; Reconnect from saved parameters.
> (if mpdired--network-params
> (set-process-buffer
> (apply 'make-network-process mpdired--network-params)
> comm-buffer)))))
>
> (defun mpdired--maybe-init (host service localp)
> (with-current-buffer (get-buffer-create
> (mpdired--comm-name host service localp))
> (erase-buffer)
> (let ((process (get-buffer-process (current-buffer))))
> (unless (and process (eq (process-status process) 'open))
> (let ((params (list :name "mpdired-comm"
> :buffer (current-buffer)
> :host host
> :service service
> :family (if localp 'local)
> :coding 'utf-8
> :filter 'mpdired--filter)))
This should be sharp-quoted.
> (setq mpdired--network-params params
> mpdired--main-buffer (mpdired--main-name host service localp))
> (set-process-buffer (apply 'make-network-process params)
> (current-buffer)))))))
>
> (defmacro mpdired--with-comm-buffer (process buffer &rest body)
> "Helper macro when sending a command via the communication buffer.
> PROCESS will be bound to the communication buffer's process. BUFFER is
> an optional communication buffer that would be used instead of
> `mpdired--comm-buffer'."
> (declare (indent defun))
> `(with-current-buffer (or ,buffer mpdired--comm-buffer)
> (erase-buffer)
> (mpdired--maybe-reconnect (current-buffer))
> (let ((,process (get-buffer-process (current-buffer))))
> (when (process-live-p ,process)
> ,@body))))
>
> (defun mpdired-listall-internal (path &optional ascending-p)
> (mpdired--with-comm-buffer process nil
> (setq mpdired--last-command 'listall
> mpdired--ascending-p ascending-p)
> (process-send-string process "command_list_begin\n")
> ;; At toplevel also lists MPD's playlists.
> (when (string= "" path)
> (process-send-string process "listplaylists\n"))
> (process-send-string process (format "listall \"%s\"\n" path))
> (process-send-string process "command_list_end\n")))
>
> (defun mpdired-listplaylist-internal (path &optional ascending-p)
> (mpdired--with-comm-buffer process nil
> (setq mpdired--last-command 'listplaylist
> mpdired--ascending-p ascending-p
> mpdired--playlist path)
> (process-send-string process (format "listplaylist \"%s\"\n" path))))
Do you know if you could use %S here, in case something in PATH should
be escaped as well?
>
> (defun mpdired-queue-internal (&optional buffer)
> (mpdired--with-comm-buffer process buffer
> (setq mpdired--last-command 'queue)
> ;; Also get the status to identify the current song.
> (process-send-string process "command_list_begin\n")
> (process-send-string process "status\n")
> (process-send-string process "playlistid\n")
> (process-send-string process "command_list_end\n")))
>
> (defun mpdired-playid-internal (id)
> (mpdired--with-comm-buffer process nil
> (setq mpdired--last-command 'playid)
> (process-send-string process (format "playid %d\n" id))))
>
> (defun mpdired-add-internal (typed-uris)
> (mpdired--with-comm-buffer process nil
> (setq mpdired--last-command 'add)
> (process-send-string process "command_list_begin\n")
> (if (listp typed-uris)
> (dolist (typed-uri typed-uris)
> (let ((type (car typed-uri))
> (uri (cdr typed-uri)))
> ;; "add" is called "load" for playlists
> (if (eq type 'playlist)
> (process-send-string process (format "load \"%s\"\n" uri))
> (process-send-string process (format "add \"%s\"\n" uri)))))
> (process-send-string process (format "add \"%s\"\n" typed-uris)))
> (process-send-string process "command_list_end\n")))
>
> (defun mpdired-deleteid-internal (id)
> (mpdired--with-comm-buffer process nil
> (setq mpdired--last-command 'deleteid)
> (process-send-string process "command_list_begin\n")
> (if (listp id)
> (dolist (i id)
> (process-send-string process (format "deleteid %d\n" i)))
> (process-send-string process (format "deleteid %d\n" id)))
> ;; XXX A playlistid should always be preceded by a status
> (process-send-string process "status\n")
> (process-send-string process "playlistid\n")
> (process-send-string process "command_list_end\n")))
>
> (defun mpdired-remove-playlist-internal (uri)
> (mpdired--with-comm-buffer process nil
> (setq mpdired--last-command 'remove-playlist)
> (process-send-string process "command_list_begin\n")
> (if (listp uri)
> (dolist (u uri)
> (process-send-string process (format "rm \"%s\"\n" u)))
> (process-send-string process (format "rm \"%s\"\n" uri)))
> (process-send-string process "command_list_end\n")))
>
> (defun mpdired-pause-internal (&optional buffer)
> "Toggles pause."
> (interactive)
> (mpdired--with-comm-buffer process buffer
> (setq mpdired--last-command 'pause
> mpdired--message "Toggle pause...")
> (process-send-string process "pause\n")))
>
> (defun mpdired-db-update ()
> "Issues a database update."
> (interactive)
> (mpdired--with-comm-buffer process nil
> (setq mpdired--last-command 'stop
> mpdired--message "DB Update...")
> (process-send-string process "update\n")))
>
> (defun mpdired-stop ()
> "Stops playing."
> (interactive)
> (mpdired--with-comm-buffer process nil
> (setq mpdired--last-command 'stop
> mpdired--message "Stopping...")
> (process-send-string process "stop\n")))
>
> (defun mpdired-toggle-repeat ()
> "Toggles repeat mode."
> (interactive)
> (mpdired--with-comm-buffer process nil
> (setq mpdired--last-command 'repeat)
> (let ((repeat
> (with-current-buffer mpdired--main-buffer
> (nth 2 mpdired--status))))
> (process-send-string process
> (format "repeat %d\n" (if repeat 0 1))))))
>
> (defun mpdired-toggle-random ()
> "Toggles random mode."
> (interactive)
> (mpdired--with-comm-buffer process nil
> (setq mpdired--last-command 'random)
> (let ((random
> (with-current-buffer mpdired--main-buffer
> (nth 3 mpdired--status))))
> (process-send-string process
> (format "random %d\n" (if random 0 1))))))
>
> ;; XXX no oneshot support
> (defun mpdired-toggle-single ()
> "Toggles single mode."
> (interactive)
> (mpdired--with-comm-buffer process nil
> (setq mpdired--last-command 'single)
> (let ((single
> (with-current-buffer mpdired--main-buffer
> (nth 4 mpdired--status))))
> (process-send-string process
> (format "single %d\n" (if single 0 1))))))
>
> ;; XXX no oneshot support
> (defun mpdired-toggle-consume ()
> "Toggles consume mode."
> (interactive)
> (mpdired--with-comm-buffer process nil
> (setq mpdired--last-command 'consume)
> (let ((consume
> (with-current-buffer mpdired--main-buffer
> (nth 5 mpdired--status))))
> (process-send-string process
> (format "consume %d\n" (if consume 0 1))))))
>
> (defun mpdired-next-internal (&optional buffer)
> "Starts playing the next song from the queue."
> (interactive)
> (mpdired--with-comm-buffer process buffer
> (setq mpdired--last-command 'next)
> (process-send-string process "next\n")))
>
> (defun mpdired-previous-internal (&optional buffer)
> "Starts playing the previous song from the queue."
> (interactive)
> (mpdired--with-comm-buffer process buffer
> (setq mpdired--last-command 'previous)
> (process-send-string process "previous\n")))
>
> (defun mpdired-set-volume-internal (volume &optional buffer)
> "Changes MPD volume. VOLUME is a number between 0 and 100."
> (interactive "nVolume: ")
> (mpdired--with-comm-buffer process buffer
> (setq mpdired--last-command 'setvol)
> (process-send-string process
> (format "setvol %d\n" (min 100 (max 0 volume))))))
>
> (defun mpdired-playlist-create (name)
> "Creates a new MPD's playlist named NAME with the queue content."
> (interactive "MPlaylist name: ")
> (mpdired--with-comm-buffer process nil
> (setq mpdired--last-command 'playlist-create)
> (process-send-string process (format "save \"%s\"\n" name))))
>
> (defun mpdired-playlist-append (name)
> (interactive "MPlaylist name: ")
> (mpdired--with-comm-buffer process nil
> (setq mpdired--last-command 'playlist-append)
> (process-send-string process (format "save \"%s\" append\n" name))))
>
> (defun mpdired--save-point ()
> (cond ((eq mpdired--view 'queue)
> (let ((bol (mpdired--bol)))
> (unless (> bol (point-max))
> (setf mpdired--songid-point (get-text-property bol 'id)))))
> ((eq mpdired--view 'browser)
> (setf mpdired--browser-point (point)))))
>
> (defun mpdired--next-line ()
> (forward-line)
> (goto-char (mpdired--bol)))
>
> (defun mpdired-next-line ()
> "Go to next line and save position."
> (interactive)
> (mpdired--next-line)
> (mpdired--save-point))
>
> (defun mpdired--previous-line ()
> (forward-line -1)
> (goto-char (mpdired--bol)))
>
> (defun mpdired-previous-line ()
> "Go to previous line and save position."
> (interactive)
> (mpdired--previous-line)
> (mpdired--save-point))
>
> (defun mpdired-listall-at-point ()
> (let* ((bol (mpdired--bol))
> (type (get-text-property bol 'type))
> (uri (get-text-property bol 'uri)))
> (cond ((eq type 'directory)
> (mpdired-listall-internal uri))
> ((eq type 'playlist)
> (mpdired-listplaylist-internal uri))
> ((eq type 'file)
> (message "Cannot browse a file.")))))
>
> (defun mpdired-playid-at-point ()
> (let ((id (get-text-property (mpdired--bol) 'id)))
> (when id (mpdired-playid-internal id))))
>
> (defun mpdired-enter ()
> "In the browser view, browses the entry at point.
> In the queue view, starts playing the song at point."
> (interactive)
> (cond ((eq mpdired--view 'browser)
> (setq mpdired--browser-point nil)
> (mpdired-listall-at-point))
> ((eq mpdired--view 'queue)
> (mpdired-playid-at-point))))
>
> (defun mpdired--unsplit (list separator)
> (let (res)
> (dolist (e (butlast list))
> (push e res)
> (push separator res))
> (push (car (last list)) res)
> (apply 'concat (reverse res))))
Adding a docstring to function like this would be helpful.
>
> (defun mpdired--parent ()
> (when (stringp mpdired--directory)
> (let ((split (split-string mpdired--directory "/")))
> (if (= 1 (length split))
> ""
> (mpdired--unsplit (butlast split) "/")))))
>
> (defun mpdired-goto-parent ()
> "Browses the parent directory of the current one."
> (interactive)
> (let ((parent (mpdired--parent)))
> (cond (parent
> (setq mpdired--browser-point nil)
> (with-current-buffer mpdired--comm-buffer
> (setq mpdired--playlist nil))
> (mpdired-listall-internal parent t))
> (t (message "You are at the toplevel.")))))
>
> (defun mpdired-toggle-view ()
> "Toggles between the browser and the queue view."
> (interactive)
> (cond ((eq mpdired--view 'browser)
> (mpdired-queue-internal))
> ((eq mpdired--view 'queue)
> (cond (mpdired--directory
> (let ((proc (get-buffer-process mpdired--comm-buffer)))
> (mpdired-listall-internal mpdired--directory)
> ;; XXX this is a bit hacky
> (while (accept-process-output proc 0 50))
> ;; If we get an error "No such directory" then we may
> ;; have been visiting a playlist.
> (when (eq mpdired--error 'no-directory)
> (setq mpdired--error nil)
> (mpdired-listplaylist-internal mpdired--directory))
> (while (accept-process-output proc 0 50))
> ;; If get an error "No such playlist" then we may have
> ;; a bogus `mpdired--directory': go back to toplevel.
> (when (eq mpdired--error 'no-playlist)
> (setq mpdired--error nil)
> (mpdired-listall-internal ""))))
> (t (mpdired-listall-internal ""))))))
>
> (defun mpdired--mark (mark)
> (let ((inhibit-read-only t))
> (when (get-text-property (mpdired--bol) 'uri)
> (save-excursion
> (goto-char (line-beginning-position))
> (delete-char 1)
> (insert-char mark))
> (put-text-property (mpdired--bol) (line-end-position) 'mark mark)
> (mpdired--reset-face))))
>
> (defun mpdired--clear-mark ()
> (let ((inhibit-read-only t)
> (bol (mpdired--bol)))
> (when (get-text-property bol 'mark)
> (remove-text-properties (mpdired--bol) (line-end-position) '(mark face))
> (mpdired--reset-face)
> (save-excursion
> (goto-char (line-beginning-position))
> (delete-char 1)
> (insert-char ? )))))
You can also use "?\s" instead of "? ".
>
> (defun mpdired-mark-at-point ()
> "Marks entry at point."
> (interactive)
> (mpdired--mark ?*)
> (mpdired-next-line))
>
> (defun mpdired-flag-at-point ()
> "Flags entry at point."
> (interactive)
> (mpdired--mark ?d)
> (mpdired-next-line))
>
> (defun mpdired-toggle-marks ()
> "Toggles marks."
> (interactive)
> (save-excursion
> (goto-char (point-min))
> (let ((max (point-max)))
> (while (< (point) max)
> (let ((mark (get-text-property (mpdired--bol) 'mark)))
> (if (and mark (char-equal mark ?*))
> (mpdired--clear-mark)
> (mpdired--mark ?*)))
> (forward-line)))))
>
> (defun mpdired-change-marks (&optional old new)
> "Changes mark from OLD to NEW. It asks the user for OLD and NEW."
> (interactive
> (let* ((cursor-in-echo-area t)
> (old (progn (message "Change (old mark): ") (read-char)))
> (new (progn (message "Change %c marks to (new mark): " old)
> (read-char))))
Why not use read-char's PROMPT argument?
> (list old new)))
> (let ((inhibit-read-only t))
> (save-excursion
> (goto-char (point-min))
> (let ((max (point-max)))
> (while (< (point) max)
> (let ((mark (get-text-property (mpdired--bol) 'mark)))
> (when (and mark (char-equal mark old))
> (mpdired--mark new)))
> (forward-line))))))
>
> (defun mpdired-unmark-at-point ()
> "Removes any mark at point."
> (interactive)
> (mpdired--clear-mark)
> (mpdired-next-line))
>
> (defun mpdired-previous-unmark ()
> "Removes any mark on the previous line and move to it."
> (interactive)
> (mpdired-previous-line)
> (mpdired--clear-mark))
>
> (defun mpdired-unmark-all-marks ()
> "Removes all marks in the current buffer."
> (interactive)
> (let ((inhibit-read-only t))
> (save-excursion
> (goto-char (point-min))
> (let ((max (point-max)))
> (while (< (point) max)
> (mpdired--clear-mark)
> (forward-line))))))
>
> (defun mpdired--collect-marked (want)
> "Collects entries marked with WANT."
> (let ((max (point-max))
> result)
> (save-excursion
> (goto-char (point-min))
> (while (< (point) max)
> (let* ((bol (mpdired--bol))
> (mark (get-text-property bol 'mark))
> (id (get-text-property bol 'id))
> (type (get-text-property bol 'type))
> (uri (get-text-property bol 'uri)))
> (when (and mark (char-equal mark want))
> (push (cons id (cons type uri)) result)))
> (forward-line)))
> ;; No marked, get the entry at point.
> (unless result
> (let* ((bol (mpdired--bol))
> (id (get-text-property bol 'id))
> (type (get-text-property bol 'type))
> (uri (get-text-property bol 'uri)))
> (setq result (list (cons id (cons type uri))))))
> (reverse result)))
>
> (defun mpdired-mark-files-regexp (regexp &optional mark)
> "Marks entries which matches a user provided REGEXP."
> (interactive (list (read-regexp "Mark (regexp): ")))
> (save-excursion
> (goto-char (point-min))
> (let ((mark (or mark ?*))
> (max (point-max)))
> (while (< (point) max)
> (when (re-search-forward regexp (line-end-position) t)
> (mpdired--mark mark))
> (forward-line)))))
>
> (defun mpdired-flag-files-regexp (regexp)
> "Flags entries which matches a user provided REGEXP."
> (interactive (list (read-regexp "Flag for deletion (regexp): ")))
> (mpdired-mark-files-regexp regexp ?d))
>
> (defun mpdired--append-message (message)
> "Puts a MESSAGE for the communication buffer."
> (with-current-buffer mpdired--comm-buffer
> (if mpdired--message
> (setq mpdired--message (format "%s %s" mpdired--message message))
> (setq mpdired--message message))))
>
> (defun mpdired--build-add-message (typed-uris)
> (let* ((uris (mapcar 'cdr typed-uris))
> (n (length uris)))
> (cond ((= n 1) (format "Adding \"%s\"..." (car uris)))
> ((= n 2)
> (format "Adding \"%s\" and \"%s\"..." (car uris) (cadr uris)))
> ((> n 2)
> (format "Adding \"%s\", \"%s\" and %d others..."
> (car uris) (cadr uris) (- n 2))))))
>
> (defun mpdired-add ()
> "Recursively add the entry at point at the end of the queue."
> (interactive)
> (let* ((marked (mpdired--collect-marked ?*))
> (typed-uris (mapcar 'cdr marked)))
> (when typed-uris
> (mpdired--append-message (mpdired--build-add-message typed-uris))
> (mpdired-add-internal typed-uris)
> (when (= 1 (length typed-uris))
> (mpdired-next-line)))))
>
> (defun mpdired-deleteid-at-point ()
> (let ((id (get-text-property (mpdired--bol) 'id)))
> (when id
> (save-excursion
> (forward-line)
> (let ((bol (mpdired--bol)))
> (unless (>= bol (point-max))
> (setq mpdired--songid-point
> (get-text-property bol 'id)))))
> (mpdired-deleteid-internal id))))
>
> (defun mpdired-remove-playlist-at-point ()
> (let* ((bol (mpdired--bol))
> (uri (get-text-property bol 'uri))
> (type (get-text-property bol 'type)))
> (when (and type uri
> (eq type 'playlist))
> (mpdired--append-message (format "Removing \"%s\"..." uri))
> (mpdired-remove-playlist-internal uri))))
>
> (defun mpdired-delete ()
> "Removes song at point from the queue or playlist at point from the
> browser view."
> (interactive)
> (cond ((eq mpdired--view 'queue)
> (mpdired-deleteid-at-point))
> ((eq mpdired--view 'browser)
> (mpdired-remove-playlist-at-point))))
>
> (defun mpdired--find-next-unmarked-id ()
> (save-excursion
> (let ((max (point-max)))
> (while (and (< (point) max)
> (get-text-property (mpdired--bol) 'mark))
> (forward-line))
> (unless (>= (mpdired--bol) max)
> (get-text-property (mpdired--bol) 'id)))))
>
> (defun mpdired-flagged-delete ()
> "Removes flagged songs from the queue."
> (interactive)
> (when (eq mpdired--view 'queue)
> (let* ((flagged (mpdired--collect-marked ?d))
> (ids (mapcar 'car flagged)))
> (when flagged
> (setf mpdired--songid-point (mpdired--find-next-unmarked-id))
> (mpdired-deleteid-internal ids)))))
>
> (defun mpdired-update ()
> "Updates the buffer content. It works both for browser and queue view."
> (interactive)
> (cond ((eq mpdired--view 'queue)
> (mpdired-queue-internal))
> ((eq mpdired--view 'browser)
> (if mpdired--directory
> (mpdired-listall-internal mpdired--directory)
> (mpdired-listall-internal "")))))
>
> \f
> ;; Global commands (i.e. usable outside of the MPDired buffer).
> (defun mpdired--prepare ()
> "Prepares a connection for global commands with user's host and port
> settings. It returns a cons with communication and main buffers names."
> (let* ((localp (mpdired--local-p mpdired-host))
> (host (if localp (expand-file-name mpdired-host) mpdired-host))
> (service (if localp host mpdired-port))
> (comm-name (mpdired--comm-name host service localp))
> (main-name (mpdired--main-name host service localp)))
> (mpdired--maybe-init host service localp)
> (cons comm-name main-name)))
>
> (defun mpdired-pause ()
> "Toggles MPDired pause."
> (interactive)
> (let ((buffers (mpdired--prepare)))
> (mpdired-pause-internal (car buffers))))
>
> (defun mpdired-next ()
> "Go to next song in the queue."
> (interactive)
> (let ((buffers (mpdired--prepare)))
> (mpdired-next-internal (car buffers))))
>
> (defun mpdired-previous ()
> "Go to previous song in the queue."
> (interactive)
> (let ((buffers (mpdired--prepare)))
> (mpdired-previous-internal (car buffers))))
>
> (defun mpdired-set-volume (volume)
> "Sets MPDired volume."
> (interactive "nVolume: ")
> (let ((buffers (mpdired--prepare)))
> (mpdired-set-volume-internal (min 100 (max 0 volume)) (car buffers))))
>
> ;; Main entry point.
> (defun mpdired ()
> "Open MPDired."
> (interactive)
> (let* ((buffers (mpdired--prepare))
> (comm (car buffers))
> (main (cdr buffers)))
> ;; Defaults to queue view
> (mpdired-queue-internal comm)
> (pop-to-buffer main)))
>
> (provide 'mpdired)
> ;;; mpdired.el ends here
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 61%]
* Re: Reliability of melpa
@ 2024-03-03 7:19 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-03-03 7:19 UTC (permalink / raw)
To: Pedro Andres Aranda Gutierrez; +Cc: emacs-devel
Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:
> Hi,
>
> I've always been a great fan of melpa. However, I'm experiencing trouble in
> the past days:
>
> Failed to install company:
> https://melpa.org/packages/company-20240301.346.tar
The Emacs developers are not responsible for MELPA, but keep in mind
that Company specifically is also available from GNU ELPA:
https://elpa.gnu.org/packages/company.html.
> It is a pity. I think a rich and reliable package ecosystem is one of the
> greatest arguments for Emacs. It has been replicated by other editors ;-)
>
> My.2 cents
--
Philip Kaludercic on icterid
^ permalink raw reply [relevance 99%]
* Re: NonGNU ELPA: Conditions for accepting a potential new package 'rmsbolt' ?
@ 2024-02-27 18:42 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-02-27 18:42 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Jay Kamat, Jeremy Bryant, emacs-devel@gnu.org
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> I can't help much more on if/when/how to convert an internal filename
> into one that works in a win32 shell, 'cause I have no experience with
> that. AFAICT most ELisp code doesn't do anything special for that
> (whereas they sometimes do such things for Tramp purposes), so I'd
> naively expect that it "just works".
Inside of Emacs, but does it also handle argument when starting a
process with some path?
>>> Also I think `shell-quote-argument` should be applied to most parts of
>>> `rmsbolt--demangle-command`. This function is also odd in that it
>>> calls `rmsbolt--convert-file-name-to-system-type` on the files
>>> of the demangler but not those of the `mv`.
>>
>> IIUC shell-quote-argument cannot be used,
>
> Of course it can. You can't just replace the #'identity with
> #'shell-quote-argument, indeed, but still `shell-quote-argument` should
> be used on *most* parts that appear in the function.
True, my comment was not phrased carefully.
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 99%]
* Re: NonGNU ELPA: Conditions for accepting a potential new package 'rmsbolt' ?
@ 2024-02-27 17:27 85% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-02-27 17:27 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Jay Kamat, Jeremy Bryant, emacs-devel@gnu.org
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> -(defun rmsbolt--convert-file-name-to-system-type (file-name)
>>> +(defun rmsbolt--convert-file-name-to-system-type (file-name) ;perhaps use
>>> `convert-standard-filename'?
>>
>> Right now, a contributor is trying to improve this area/enable tramp
>> support - so I'd like to keep this as stable as possible while they do
>> so. But this is a great suggestion - I'll let them know about this function
>> and hopefully it will help them in their change as well!
>
> I haven't looked at the code but I'll point out that
> `convert-standard-filename` is meant to *define* the name of a "standard"
> file, so its argument is usually very static.
> It doesn't make sense to apply it to something like `buffer-file-name`
> which is already supposed to be a valid filename.
In that case I must have misunderstood something, my intention was to
find a function that would convert file names with forwards slashes to
the proper file delimiters on the current system.
> Also, I see:
>
> (rmsbolt--convert-file-name-to-system-type
> (shell-quote-argument
>
> which is very weird. The reverse would make more sense.
>
> Also I think `shell-quote-argument` should be applied to most parts of
> `rmsbolt--demangle-command`. This function is also odd in that it
> calls `rmsbolt--convert-file-name-to-system-type` on the files
> of the demangler but not those of the `mv`.
IIUC shell-quote-argument cannot be used, since rmsbolt is actually
creating a shell command out of a list, where each element of the list
is not necessarily a command line argument. E.g. there were some places
where "&&" or ">" were being used, and quoting those would break the
intended functionality. I have to admit that the process of creating
commands this way seems fragile, but there is a lot of code that would
take a while to rewrite and verify that it doesn't break anything. (A
different idea would be to have a defstruct for each command that would be
prepared into a list and in the end executed in order, ideally using
some function like `process-file').
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 85%]
* Re: NonGNU ELPA: Conditions for accepting a potential new package 'rmsbolt' ?
@ 2024-02-27 17:21 98% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-02-27 17:21 UTC (permalink / raw)
To: Jay Kamat; +Cc: Jeremy Bryant, emacs-devel@gnu.org, monnier
Jay Kamat <jaygkamat@gmail.com> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Jay Kamat <jaygkamat@gmail.com> writes:
>>
>>> Philip Kaludercic <philipk@posteo.net> writes:
>>>
>>> Might take me a while to fully review and test all the changes, but
>>> they look good, so once I do so, I'll include them!
>>>
>>>> +(defcustom rmsbolt-mode-lighter " RMS🗲" ;could the unicode
>>>> charachter be removed? it can unnecessarily resize the mode line.
>>>
>>> Sure - I can remove it. I'll do it after I apply your patch generally.
>>
>> Just keep in mind that I didn't send a patch. I just find it convenient
>> to send comments in form of a diff.
>
> Ah - I didn't realize. I think most of your code-changes are good, is
> it alright if I apply them? I'll make a commit with you as the author
> (or I can take authorship/not commit them - whatever your preference
> is).
Of course, I just wanted to make sure that you don't apply a comment
instead of addressing it. Also, some changes might have been
opinionated (I don't recall), and I wouldn't want to insinuate that you
must apply them.
I don't care about authorship, do as you like.
>>>>
>>>> ;;;;; Starter Definitions
>>>>
>>>> ;; IIUC, this "starter" business is not a necessary part of
>>>> RMSBolt, but is
>>>> ;; a way to provide sample files with which users can try out RMSBolt.
>>>>
>>>> -(defvar rmsbolt-starter-files
>>>> +(defvar rmsbolt-starter-files ;should this be part
>>>> of a secondary file that isn't loaded by default?
>>>
>>> Maybe - I think I would load it by default though - as this is the
>>> easiest way for someone to try out the package. In my personal usage I
>>> almost always start from one of these files and add my changes. I
>>> should update the comment above with that information as well.
>>
>> It shouldn't matter, as long as the command that uses
>> `rmsbolt-starter-files' remains auto-loaded, even if the command is
>> not defined in the main file.
>
> Ah - that's true! I'll try to make this change after the others if I
> have time.
1+
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 98%]
* Re: NonGNU ELPA: Conditions for accepting a potential new package 'rmsbolt' ?
@ 2024-02-27 17:10 98% ` Philip Kaludercic
1 sibling, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-02-27 17:10 UTC (permalink / raw)
To: Jay Kamat; +Cc: Jeremy Bryant, emacs-devel@gnu.org, monnier
Jay Kamat <jaygkamat@gmail.com> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
> Might take me a while to fully review and test all the changes, but
> they look good, so once I do so, I'll include them!
>
>> +(defcustom rmsbolt-mode-lighter " RMS🗲" ;could the unicode
>> charachter be removed? it can unnecessarily resize the mode line.
>
> Sure - I can remove it. I'll do it after I apply your patch generally.
Just keep in mind that I didn't send a patch. I just find it convenient
to send comments in form of a diff.
>> -(defun rmsbolt--convert-file-name-to-system-type (file-name)
>> +(defun rmsbolt--convert-file-name-to-system-type (file-name)
>> ;perhaps use `convert-standard-filename'?
>
> Right now, a contributor is trying to improve this area/enable tramp
> support - so I'd like to keep this as stable as possible while they do
> so. But this is a great suggestion - I'll let them know about this
> function and hopefully it will help them in their change as well!
No problem.
>>
>> ;;;;; Starter Definitions
>>
>> ;; IIUC, this "starter" business is not a necessary part of RMSBolt, but is
>> ;; a way to provide sample files with which users can try out RMSBolt.
>>
>> -(defvar rmsbolt-starter-files
>> +(defvar rmsbolt-starter-files ;should this be part
>> of a secondary file that isn't loaded by default?
>
> Maybe - I think I would load it by default though - as this is the
> easiest way for someone to try out the package. In my personal usage I
> almost always start from one of these files and add my changes. I
> should update the comment above with that information as well.
It shouldn't matter, as long as the command that uses
`rmsbolt-starter-files' remains auto-loaded, even if the command is
not defined in the main file.
> Thanks! I just want to be doubly sure of all the changes before I
> commit them, I'll try to do that testing tomorrow - I'm a bit busy
> today. I'll also try to fix any remaining checkdoc errors.
Thanks!
> -Jay
>
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 98%]
* Re: NonGNU ELPA: Conditions for accepting a potential new package 'rmsbolt' ?
@ 2024-02-27 7:47 16% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-02-27 7:47 UTC (permalink / raw)
To: Jeremy Bryant; +Cc: emacs-devel@gnu.org, Jay Kamat, monnier
[-- Attachment #1: Type: text/plain, Size: 815 bytes --]
Jeremy Bryant <jb@jeremybryant.net> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Jeremy Bryant <jb@jeremybryant.net> writes:
>>
>>> I would like to recommend the package 'rmsbolt' for NonGNU ELPA and
>>> volunteer for any required changes.
>>>
>>> The author is Jay Kamat, who as I understand is potentially supportive
>>> if the changes are minimal (and I am volunteering for these.)
>>
>> Minimal as in "small diff" or "small effort"?
>
> I believe the author is supportive if the changes are a small effort.
It would be nice if the checkdoc errors could be address, since there
are a few of them, but that is not a hard-constraint.
>>
>>> It is currently hosted on gitlab and distributed on MELPA.
>>
>> Could you provide a URL?
>
> https://gitlab.com/jgkamat/rmsbolt
Here are my comments:
[-- Attachment #2: Type: text/plain, Size: 32335 bytes --]
diff --git a/rmsbolt.el b/rmsbolt.el
index bdc457f..b2f2049 100644
--- a/rmsbolt.el
+++ b/rmsbolt.el
@@ -1,6 +1,7 @@
;;; rmsbolt.el --- A compiler output viewer -*- lexical-binding: t; -*-
-;; Copyright (C) 2018-2021 Jay Kamat
+;; Copyright (C) 2018-2023 Jay Kamat
+
;; Author: Jay Kamat <jaygkamat@gmail.com>
;; Version: 0.1.2
;; Keywords: compilation, tools
@@ -40,8 +41,10 @@
;; 4. Provide an interface for highlighting the matched assembly/bytecode line
;; to the source and vice versa
;;
-;; Tweakables:
-;; RMSBolt is primarily configured with Emacs local variables. This lets you
+
+;;;; Tweakables:
+
+;; RMSBolt is primarily configured with Emacs local variables. This lets you
;; change compiler and rmsbolt options simply by editing a local variable block.
;;
;; Notable options:
@@ -80,25 +83,25 @@
;;; Code:
;;;; Customize:
(defgroup rmsbolt nil
- "rmsbolt customization options"
+ "rmsbolt customization options."
:group 'applications)
(defcustom rmsbolt-use-overlays t
"Whether we should use overlays to show matching code."
- :type 'boolean
- :group 'rmsbolt)
+ :type 'boolean)
+
(defcustom rmsbolt-goto-match t
"Whether we should goto the match in the other buffer if it is non visible."
- :type 'boolean
- :group 'rmsbolt)
-(defcustom rmsbolt-mode-lighter " RMS🗲"
+ :type 'boolean)
+
+(defcustom rmsbolt-mode-lighter " RMS🗲" ;could the unicode charachter be removed? it can unnecessarily resize the mode line.
"Lighter displayed in mode line when function `rmsbolt-mode' is active."
- :type 'string
- :group 'rmsbolt)
+ :type 'string)
+
(defcustom rmsbolt-large-buffer-size 500
"Number of lines past which a buffer is considred large."
- :type 'integer
- :group 'rmsbolt)
+ :type 'natnum)
+
(defcustom rmsbolt-automatic-recompile t
"Whether to automatically save and recompile the source buffer.
This setting is automatically disabled on large buffers, set to
@@ -107,29 +110,28 @@ manually saved, set to `on-save'."
:type '(choice (const :tag "Off" nil)
(const :tag "On save" on-save)
(const :tag "On" t)
- (const :tag "Always" force))
- :group 'rmsbolt)
+ (const :tag "Always" force)))
;;;;; Buffer Local Tweakables
(defcustom rmsbolt-disassemble nil
"Whether we should disassemble an output binary."
:type 'boolean
- :safe 'booleanp
- :group 'rmsbolt)
+ :safe 'booleanp)
+
(defcustom rmsbolt-command nil
"The base command to run rmsbolt from."
:type 'string
;; nil means use default command
- :safe (lambda (v) (or (booleanp v) (stringp v)))
- :group 'rmsbolt)
+ :safe (lambda (v) (or (booleanp v) (stringp v))))
+
(defcustom rmsbolt-default-directory nil
"The default directory to compile from.
This must be an absolute path if set.
Some exporters (such as pony) may not work with this set."
:type 'string
;; nil means use default command
- :safe (lambda (v) (or (booleanp v) (stringp v)))
- :group 'rmsbolt)
+ :safe (lambda (v) (or (booleanp v) (stringp v))))
+
(define-obsolete-variable-alias 'rmsbolt-intel-x86
'rmsbolt-asm-format "RMSBolt-0.2"
"Sorry about not providing a proper migration for this variable.
@@ -142,6 +144,7 @@ tool defaults -> nil
This means that if you had rmsbolt-intel-x86 set manually, you
are now getting tool defaults.")
+
(defcustom rmsbolt-asm-format "intel"
"Which output assembly format to use.
@@ -155,45 +158,44 @@ If you are not on x86, you most likely want to set this to nil.
Since this defaults to \"intel\", implementers must support this
being set (at worst falling back to nil if passed \"intel\")."
:type 'string
- :safe (lambda (v) (or (booleanp v) (stringp v)))
- :group 'rmsbolt)
+ :safe (lambda (v) (or (booleanp v) (stringp v))))
+
(defcustom rmsbolt-filter-directives t
"Whether to filter assembly directives."
:type 'boolean
- :safe 'booleanp
- :group 'rmsbolt)
+ :safe 'booleanp)
+
(defcustom rmsbolt-filter-labels t
"Whether to filter unused labels."
:type 'boolean
- :safe 'booleanp
- :group 'rmsbolt)
+ :safe 'booleanp)
+
(defcustom rmsbolt-filter-comment-only t
"Whether to filter comment-only lines."
:type 'boolean
- :safe 'booleanp
- :group 'rmsbolt)
+ :safe 'booleanp)
+
(defcustom rmsbolt-ignore-binary-limit nil
- "Whether to ignore the binary limit. Could hang emacs..."
+ "Whether to ignore the binary limit. Could hang emacs..."
:type 'boolean
- :safe 'booleanp
- :group 'rmsbolt)
+ :safe 'booleanp)
+
(defcustom rmsbolt-demangle t
"Whether to attempt to demangle the resulting assembly."
:type 'boolean
- :safe 'booleanp
- :group 'rmsbolt)
+ :safe 'booleanp)
+
(defcustom rmsbolt-flag-quirks t
"Whether to tweak flags to enable as many features as possible.
In most cases, we will try to honor flags in rmsbolt-command as
-much as possible. However, some features may be disabled with
-some odd combinations of flags. This variable controls
+much as possible. However, some features may be disabled with
+some odd combinations of flags. This variable controls
removing/adding flags to handle those cases.
Note that basic flags to ensure basic usage are always modified."
:type 'boolean
- :safe 'booleanp
- :group 'rmsbolt)
+ :safe 'booleanp)
(defcustom rmsbolt-after-parse-hook nil
"Hook after all parsing is done, but before compile command is run.
@@ -201,7 +203,6 @@ Note that basic flags to ensure basic usage are always modified."
Exercise caution when setting variables in this hook - doing so
can disrupt rmsbolt state and cause issues. Variables set here
may not be cleared to default as variables are usually."
- :group 'rmsbolt
:type 'hook)
;;;; Faces
@@ -241,16 +242,15 @@ Used to work around inconsistencies in alternative shells.")
Please DO NOT modify this blindly, as this directory will get
deleted on Emacs exit.")
-(defvar rmsbolt-dir nil
+(defvar rmsbolt-dir (and load-file-name (file-name-directory load-file-name))
"The directory which rmsbolt is installed to.")
-(when load-file-name
- (setq rmsbolt-dir (file-name-directory load-file-name)))
(defvar-local rmsbolt-src-buffer nil)
(defvar-local rmsbolt--real-src-file nil
"If set, the real filename that we compiled from,
-probably due to a copy from this file.")
+probably due to a copy from this file.") ;^there is a checkdoc warning here
+
;; FIXME should we be unbinding the list here, or is setting nil good enough.
(defvar-local rmsbolt--default-variables nil
"A list of the buffer-local variables we filled in with defaults.
@@ -395,7 +395,7 @@ Please be careful when setting this, as it bypasses most logic and is
generally not useful."))
;;;; Helper Functions
-(defun rmsbolt--convert-file-name-to-system-type (file-name)
+(defun rmsbolt--convert-file-name-to-system-type (file-name) ;perhaps use `convert-standard-filename'?
"Convert the argument FILE-NAME to windows format if `system-type' is equal to `cygwin'.
Additional escaping with double quotes included to avoid backslashes loss in cygwin environment.
If not `cygwin' then bypass the FILE-NAME."
@@ -417,7 +417,7 @@ Return value is quoted for passing to the shell."
(rmsbolt-output-filename ,src-buffer)))))
,@body))
-(defmacro rmsbolt--set-local (var val)
+(defmacro rmsbolt--set-local (var val) ;`setq-local' is avaliable from 24.3 onwards
"Set unquoted variable VAR to value VAL in current buffer."
(declare (debug (symbolp form)))
`(set (make-local-variable ,var) ,val))
@@ -513,6 +513,7 @@ this."
" "))
" ")))
cmd)))
+
(cl-defun rmsbolt--lisp-compile-cmd (&key src-buffer)
"Process a compile command for common lisp.
@@ -542,6 +543,7 @@ this."
" "))
(_
(error "This Common Lisp interpreter is not supported"))))))
+
(cl-defun rmsbolt--rust-compile-cmd (&key src-buffer)
"Process a compile command for rustc."
(rmsbolt--with-files
@@ -563,6 +565,7 @@ this."
(concat "-Cllvm-args=--x86-asm-syntax=" asm-format)))
" ")))
cmd)))
+
(cl-defun rmsbolt--go-compile-cmd (&key src-buffer)
"Process a compile command for go."
(rmsbolt--with-files
@@ -576,12 +579,13 @@ this."
src-filename)
" ")))
cmd)))
+
(cl-defun rmsbolt--d-compile-cmd (&key src-buffer)
"Process a compile command for d"
(rmsbolt--with-files
src-buffer
(let* ((compiler (buffer-local-value 'rmsbolt-command src-buffer))
- (cmd (mapconcat
+ (cmd (mapconcat ;you have `string-join' in subr-x
#'identity
(list compiler "-g" "-output-s" src-filename "-of" output-filename)
" ")))
@@ -624,6 +628,7 @@ this."
(buffer-file-name))
dir)))
cmd))
+
(cl-defun rmsbolt--py-compile-cmd (&key src-buffer)
"Process a compile command for python3."
(rmsbolt--with-files
@@ -676,6 +681,7 @@ https://github.com/derickr/vld"
"-o" output-filename)
" ")))
cmd)))
+
(cl-defun rmsbolt--java-compile-cmd (&key src-buffer)
"Process a compile command for ocaml.
@@ -771,6 +777,7 @@ https://github.com/derickr/vld"
"frame_dummy"
(and ".plt" (0+ any)))
eol))
+
(defvar rmsbolt--hidden-func-ocaml
(rx bol
(or (and "__" (0+ any))
@@ -782,11 +789,13 @@ https://github.com/derickr/vld"
(and (or "caml_" "camlStd_") (0+ any))
(and "caml" (or "Pervasives" "List" "Bytes"
"String" "Buffer" "Printf"
- "Char" "Sys") "__" (0+ any))
+ "Char" "Sys")
+ "__" (0+ any))
;; Ocaml likes to make labels following camlModule__,
;; filter out any lowercase
(and (1+ (1+ lower) (opt (or "64" "32" "8" "16")) (opt "_"))))
eol))
+
(defvar rmsbolt--hidden-func-zig
(rx bol (or (and "_" (0+ any))
(and (opt "de") "register_tm_clones")
@@ -810,8 +819,7 @@ https://github.com/derickr/vld"
(rmsbolt--path-to-swift-tool "swiftc"))
(defun rmsbolt--path-to-swift-tool (swift-tool)
- "Return the path to SWIFT-TOOL, depending on the active
-toolchain."
+ "Return the path to SWIFT-TOOL, depending on the active toolchain."
(let* ((swift-tool-binary swift-tool)
(swift-tool-toolchain-path (shell-command-to-string (format "echo -n `xcrun --find %s`" swift-tool-binary))))
;; If we have the Swift tool in PATH, just return it (this is the
@@ -821,8 +829,7 @@ toolchain."
((executable-find swift-tool-binary)
swift-tool-binary)
((executable-find swift-tool-toolchain-path)
- swift-tool-toolchain-path)
- (t nil))))
+ swift-tool-toolchain-path))))
(defun rmsbolt--parse-compile-commands (comp-cmds file)
"Parse COMP-CMDS and extract a compilation dir and command for FILE."
@@ -840,6 +847,7 @@ toolchain."
(dir (alist-get 'directory entry))
(cmd (alist-get 'command entry)))
(list dir cmd)))
+
(defun rmsbolt--handle-c-compile-cmd (src-buffer)
"Handle compile_commands.json for c/c++ for a given SRC-BUFFER.
return t if successful."
@@ -866,126 +874,125 @@ return t if successful."
(rmsbolt-split-rm-single "-flto" #'string-prefix-p)
(rmsbolt-split-rm-double "-o")))
t)))
+
;;;; Language Definitions
-(defvar rmsbolt-languages)
-(setq
- rmsbolt-languages
- `((c-mode
- . ,(make-rmsbolt-lang :compile-cmd "gcc"
- :supports-asm t
- :supports-disass t
- :demangler "c++filt"
- :compile-cmd-function #'rmsbolt--c-compile-cmd
- :disass-hidden-funcs rmsbolt--hidden-func-c))
- (c++-mode
- . ,(make-rmsbolt-lang :compile-cmd "g++"
- :supports-asm t
- :supports-disass t
- :demangler "c++filt"
- :compile-cmd-function #'rmsbolt--c-compile-cmd
- :disass-hidden-funcs rmsbolt--hidden-func-c))
- (d-mode
- . ,(make-rmsbolt-lang :compile-cmd "ldc2"
- :supports-asm t
- :supports-disass nil
- :demangler "ddemangle"
- :compile-cmd-function #'rmsbolt--d-compile-cmd))
- ;; In order to parse ocaml files, you need the emacs ocaml mode, tuareg
- (tuareg-mode
- . ,(make-rmsbolt-lang :compile-cmd "ocamlopt"
- :supports-asm t
- :supports-disass t
- :compile-cmd-function #'rmsbolt--ocaml-compile-cmd
- :disass-hidden-funcs rmsbolt--hidden-func-ocaml))
- (lisp-mode
- . ,(make-rmsbolt-lang :compile-cmd "sbcl"
- :supports-asm t
- :supports-disass nil
- :objdumper 'cat
- :compile-cmd-function #'rmsbolt--lisp-compile-cmd))
- (rust-mode
- . ,(make-rmsbolt-lang :compile-cmd "rustc"
- :supports-asm t
- :supports-disass nil
- :objdumper 'objdump
- :demangler "rustfilt"
- :compile-cmd-function #'rmsbolt--rust-compile-cmd))
- ;; Copy of above
- (rustic-mode
- . ,(make-rmsbolt-lang :compile-cmd "rustc"
- :supports-asm t
- :supports-disass nil
- :objdumper 'objdump
- :demangler "rustfilt"
- :compile-cmd-function #'rmsbolt--rust-compile-cmd))
- (ponylang-mode
- . ,(make-rmsbolt-lang :compile-cmd "ponyc"
- :supports-asm t
- :supports-disass t
- :objdumper 'objdump
- :compile-cmd-function #'rmsbolt--pony-compile-cmd))
- (php-mode
- . ,(make-rmsbolt-lang :compile-cmd #'rmsbolt--php-default-compile-cmd
- :supports-asm t
- :supports-disass nil
- :compile-cmd-function #'rmsbolt--php-compile-cmd
- :process-asm-custom-fn #'rmsbolt--process-php-bytecode))
- ;; ONLY SUPPORTS PYTHON 3
- (python-mode
- . ,(make-rmsbolt-lang :compile-cmd "python3"
- :supports-asm t
- :supports-disass nil
- :compile-cmd-function #'rmsbolt--py-compile-cmd
- :process-asm-custom-fn #'rmsbolt--process-python-bytecode))
- (haskell-mode
- . ,(make-rmsbolt-lang :compile-cmd "ghc"
- :supports-asm t
- :supports-disass nil
- :demangler "haskell-demangler"
- :compile-cmd-function #'rmsbolt--hs-compile-cmd))
- (java-mode
- . ,(make-rmsbolt-lang :compile-cmd "javac"
- :supports-asm t
- :supports-disass nil
- :objdumper 'cat
- :compile-cmd-function #'rmsbolt--java-compile-cmd
- :process-asm-custom-fn #'rmsbolt--process-java-bytecode))
- (emacs-lisp-mode
- . ,(make-rmsbolt-lang :supports-asm t
- :supports-disass nil
- ;; Nop
- :process-asm-custom-fn (lambda (_src-buffer lines)
- lines)
- :elisp-compile-override #'rmsbolt--elisp-compile-override))
- (nim-mode
- . ,(make-rmsbolt-lang :compile-cmd "nim c"
- :supports-disass t
- :objdumper 'objdump
- :demangler "c++filt"
- :compile-cmd-function #'rmsbolt--nim-compile-cmd
- :disass-hidden-funcs rmsbolt--hidden-func-c))
- (zig-mode
- . ,(make-rmsbolt-lang :compile-cmd "zig build-obj -O ReleaseFast"
- :supports-asm t
- :supports-disass t
- :objdumper 'objdump
- :compile-cmd-function #'rmsbolt--zig-compile-cmd
- :disass-hidden-funcs rmsbolt--hidden-func-zig))
- (go-mode
- . ,(make-rmsbolt-lang :compile-cmd "go"
- :supports-asm nil
- :supports-disass t
- :objdumper 'go-objdump
- :compile-cmd-function #'rmsbolt--go-compile-cmd
- :process-asm-custom-fn #'rmsbolt--process-go-asm-lines))
- (swift-mode
- . ,(make-rmsbolt-lang :compile-cmd (rmsbolt--path-to-swift-compiler)
- :supports-asm t
- :supports-disass nil
- :objdumper 'objdump
- :demangler (rmsbolt--path-to-swift-demangler)
- :compile-cmd-function #'rmsbolt--swift-compile-cmd))
- ))
+(defvar rmsbolt-languages
+ `((c-mode
+ . ,(make-rmsbolt-lang :compile-cmd "gcc"
+ :supports-asm t
+ :supports-disass t
+ :demangler "c++filt"
+ :compile-cmd-function #'rmsbolt--c-compile-cmd
+ :disass-hidden-funcs rmsbolt--hidden-func-c))
+ (c++-mode
+ . ,(make-rmsbolt-lang :compile-cmd "g++"
+ :supports-asm t
+ :supports-disass t
+ :demangler "c++filt"
+ :compile-cmd-function #'rmsbolt--c-compile-cmd
+ :disass-hidden-funcs rmsbolt--hidden-func-c))
+ (d-mode
+ . ,(make-rmsbolt-lang :compile-cmd "ldc2"
+ :supports-asm t
+ :supports-disass nil
+ :demangler "ddemangle"
+ :compile-cmd-function #'rmsbolt--d-compile-cmd))
+ ;; In order to parse ocaml files, you need the emacs ocaml mode, tuareg
+ (tuareg-mode
+ . ,(make-rmsbolt-lang :compile-cmd "ocamlopt"
+ :supports-asm t
+ :supports-disass t
+ :compile-cmd-function #'rmsbolt--ocaml-compile-cmd
+ :disass-hidden-funcs rmsbolt--hidden-func-ocaml))
+ (lisp-mode
+ . ,(make-rmsbolt-lang :compile-cmd "sbcl"
+ :supports-asm t
+ :supports-disass nil
+ :objdumper 'cat
+ :compile-cmd-function #'rmsbolt--lisp-compile-cmd))
+ (rust-mode
+ . ,(make-rmsbolt-lang :compile-cmd "rustc"
+ :supports-asm t
+ :supports-disass nil
+ :objdumper 'objdump
+ :demangler "rustfilt"
+ :compile-cmd-function #'rmsbolt--rust-compile-cmd))
+ ;; Copy of above
+ (rustic-mode
+ . ,(make-rmsbolt-lang :compile-cmd "rustc"
+ :supports-asm t
+ :supports-disass nil
+ :objdumper 'objdump
+ :demangler "rustfilt"
+ :compile-cmd-function #'rmsbolt--rust-compile-cmd))
+ (ponylang-mode
+ . ,(make-rmsbolt-lang :compile-cmd "ponyc"
+ :supports-asm t
+ :supports-disass t
+ :objdumper 'objdump
+ :compile-cmd-function #'rmsbolt--pony-compile-cmd))
+ (php-mode
+ . ,(make-rmsbolt-lang :compile-cmd #'rmsbolt--php-default-compile-cmd
+ :supports-asm t
+ :supports-disass nil
+ :compile-cmd-function #'rmsbolt--php-compile-cmd
+ :process-asm-custom-fn #'rmsbolt--process-php-bytecode))
+ ;; ONLY SUPPORTS PYTHON 3
+ (python-mode
+ . ,(make-rmsbolt-lang :compile-cmd "python3"
+ :supports-asm t
+ :supports-disass nil
+ :compile-cmd-function #'rmsbolt--py-compile-cmd
+ :process-asm-custom-fn #'rmsbolt--process-python-bytecode))
+ (haskell-mode
+ . ,(make-rmsbolt-lang :compile-cmd "ghc"
+ :supports-asm t
+ :supports-disass nil
+ :demangler "haskell-demangler"
+ :compile-cmd-function #'rmsbolt--hs-compile-cmd))
+ (java-mode
+ . ,(make-rmsbolt-lang :compile-cmd "javac"
+ :supports-asm t
+ :supports-disass nil
+ :objdumper 'cat
+ :compile-cmd-function #'rmsbolt--java-compile-cmd
+ :process-asm-custom-fn #'rmsbolt--process-java-bytecode))
+ (emacs-lisp-mode
+ . ,(make-rmsbolt-lang :supports-asm t
+ :supports-disass nil
+ ;; Nop
+ :process-asm-custom-fn (lambda (_src-buffer lines)
+ lines)
+ :elisp-compile-override #'rmsbolt--elisp-compile-override))
+ (nim-mode
+ . ,(make-rmsbolt-lang :compile-cmd "nim c"
+ :supports-disass t
+ :objdumper 'objdump
+ :demangler "c++filt"
+ :compile-cmd-function #'rmsbolt--nim-compile-cmd
+ :disass-hidden-funcs rmsbolt--hidden-func-c))
+ (zig-mode
+ . ,(make-rmsbolt-lang :compile-cmd "zig build-obj -O ReleaseFast"
+ :supports-asm t
+ :supports-disass t
+ :objdumper 'objdump
+ :compile-cmd-function #'rmsbolt--zig-compile-cmd
+ :disass-hidden-funcs rmsbolt--hidden-func-zig))
+ (go-mode
+ . ,(make-rmsbolt-lang :compile-cmd "go"
+ :supports-asm nil
+ :supports-disass t
+ :objdumper 'go-objdump
+ :compile-cmd-function #'rmsbolt--go-compile-cmd
+ :process-asm-custom-fn #'rmsbolt--process-go-asm-lines))
+ (swift-mode
+ . ,(make-rmsbolt-lang :compile-cmd (rmsbolt--path-to-swift-compiler)
+ :supports-asm t
+ :supports-disass nil
+ :objdumper 'objdump
+ :demangler (rmsbolt--path-to-swift-demangler)
+ :compile-cmd-function #'rmsbolt--swift-compile-cmd))
+ ))
(defvar rmsbolt-c-dwarf-language
(make-rmsbolt-lang :compile-cmd "gcc"
@@ -1014,7 +1021,6 @@ This should be an object of type `rmsbolt-lang', normally set by the major mode"
display-buffer-overriding-action)))
,@body))
-
;;;; Functions
;; Functions to parse and lint assembly were lifted almost directly from the compiler-explorer
@@ -1066,9 +1072,7 @@ Lifted from https://emacs.stackexchange.com/questions/35936/disassembly-of-a-byt
"Check if LINE has opcodes."
(save-match-data
(let* ((match (string-match rmsbolt-label-def line))
- (line (if match
- (substring line (match-end 0))
- line))
+ (line (substring line (and match (match-end 0))))
(line (cl-first (split-string line (rx (1+ (any ";#")))))))
(if (string-match-p rmsbolt-assignment-def line)
nil
@@ -1434,7 +1438,7 @@ Argument ASM-LINES input lines."
(setq result (nconc die result))
(nreverse result)))
-;;;;; Handlers
+;;;;; HANDLERS
(cl-defun rmsbolt--handle-finish-compile (buffer str &key override-buffer stopped)
"Finish hook for compilations.
Argument BUFFER compilation buffer.
@@ -1476,23 +1480,22 @@ Argument STOPPED The compilation was stopped to start another compilation."
(let ((property
(get-text-property
0 'rmsbolt-src-line line)))
- (progn
- (cl-tagbody
- run-conditional
- (cond
- ((and in-match (eq in-match property))
- ;; We are continuing an existing match
- nil)
- (in-match
- ;; We are in a match that has just expired
- (push (cons start-match (1- linum))
- (gethash in-match ht))
- (setq in-match nil
- start-match nil)
- (go run-conditional))
- (property
- (setq in-match property
- start-match linum))))))
+ (cl-tagbody
+ run-conditional
+ (cond
+ ((and in-match (eq in-match property))
+ ;; We are continuing an existing match
+ nil)
+ (in-match
+ ;; We are in a match that has just expired
+ (push (cons start-match (1- linum))
+ (gethash in-match ht))
+ (setq in-match nil
+ start-match nil)
+ (go run-conditional))
+ (property
+ (setq in-match property
+ start-match linum)))))
(cl-incf linum))
(with-current-buffer src-buffer
@@ -1544,7 +1547,7 @@ Argument STOPPED The compilation was stopped to start another compilation."
;; https://github.com/renzmann/treesit-auto/blob/d32617b5edb660b8a046053af3b92cf14f9b978e/treesit-auto.el#L89
(assoc (thread-last
(symbol-name major-mode)
- (replace-regexp-in-string "ts-mode$" "mode")
+ (replace-regexp-in-string "-ts-mode\\'" "-mode")
(intern))
rmsbolt-languages)))))
@@ -1608,6 +1611,7 @@ and return it."
(defun rmsbolt-compile ()
"Compile the current rmsbolt buffer."
(interactive)
+ ;; perhaps use `save-some-buffers'?
(when (and (buffer-modified-p)
(yes-or-no-p (format "Save buffer %s? " (buffer-name))))
(save-buffer))
@@ -1615,7 +1619,7 @@ and return it."
;; Current buffer = src-buffer at this point
(setq rmsbolt-src-buffer (current-buffer))
(cond
- ((eq major-mode 'asm-mode)
+ ((derived-mode-p 'asm-mode)
;; We cannot compile asm-mode files
(message "Cannot compile assembly files. Are you sure you are not in the output buffer?"))
((rmsbolt-l-elisp-compile-override (rmsbolt--get-lang))
@@ -1641,8 +1645,7 @@ and return it."
rmsbolt--temp-dir)))
(run-hooks 'rmsbolt-after-parse-hook)
(when (buffer-local-value 'rmsbolt-disassemble src-buffer)
- (pcase
- (rmsbolt-l-objdumper lang)
+ (pcase-exhaustive (rmsbolt-l-objdumper lang)
('objdump
(setq cmd
(mapconcat #'identity
@@ -1670,9 +1673,7 @@ and return it."
"&&" "mv"
(rmsbolt-output-filename src-buffer)
(rmsbolt-output-filename src-buffer t))
- " ")))
- (_
- (error "Objdumper not recognized"))))
+ " ")))))
;; Convert to demangle if we need to
(setq cmd (rmsbolt--demangle-command cmd lang src-buffer))
(with-current-buffer ; With compilation buffer
@@ -1720,14 +1721,14 @@ and return it."
rmsbolt--temp-dir
(file-directory-p rmsbolt--temp-dir))
(delete-directory rmsbolt--temp-dir t))
- (setq rmsbolt--temp-dir nil)))))
+ (setq rmsbolt--temp-dir nil))))) ;why is this necessary while killing emacs?
;;;;; Starter Definitions
;; IIUC, this "starter" business is not a necessary part of RMSBolt, but is
;; a way to provide sample files with which users can try out RMSBolt.
-(defvar rmsbolt-starter-files
+(defvar rmsbolt-starter-files ;should this be part of a secondary file that isn't loaded by default?
'(("c" . "rmsbolt.c")
("c++" . "rmsbolt.cpp")
("ocaml" . "rmsbolt.ml")
@@ -1778,24 +1779,23 @@ and return it."
(when line
(let ((cur (line-number-at-pos)))
(forward-line (- line cur)))))
+
(defun rmsbolt--setup-overlay (start end buf)
"Setup overlay with START and END in BUF."
(let ((o (make-overlay start end buf)))
(overlay-put o 'face 'rmsbolt-current-line-face)
o))
+
(cl-defun rmsbolt--point-visible (point)
"Check if the current point is visible in a window in the current buffer."
- (when (cl-find-if (lambda (w)
- (and (>= point (window-start w))
- (<= point (window-end w))))
- (get-buffer-window-list))
- t))
+ (cl-find-if (lambda (w)
+ (<= (window-start w) point (window-end w)))
+ (get-buffer-window-list)))
(cl-defun rmsbolt-update-overlays (&key (force nil))
"Update overlays to highlight the currently selected source and asm lines.
- If FORCE, always scroll overlay, even when one is visible.
- FORCE also scrolls to the first line, instead of the first line
- of the last block."
+If FORCE, always scroll overlay, even when one is visible. FORCE also
+scrolls to the first line, instead of the first line of the last block."
(when rmsbolt-mode
(if-let ((should-run rmsbolt-use-overlays)
(output-buffer (get-buffer rmsbolt-output-buffer))
@@ -1841,8 +1841,7 @@ and return it."
(not scroll-src-buffer-p))
(setq line-visible (or (rmsbolt--point-visible start-pt)
(rmsbolt--point-visible end-pt)
- (and (> saved-pt start-pt)
- (< saved-pt end-pt)))))
+ (< start-pt saved-pt end-pt))))
(push (rmsbolt--setup-overlay start-pt end-pt output-buffer)
rmsbolt-overlays)))))
(when (or (not line-visible) force)
@@ -1931,9 +1930,7 @@ and return it."
"Toggle rmsbolt-mode.
This mode is enabled in both src and assembly output buffers."
- :global nil
:lighter rmsbolt-mode-lighter
- :keymap rmsbolt-mode-map
;; Init
(cond
(rmsbolt-mode
[-- Attachment #3: Type: text/plain, Size: 38 bytes --]
--
Philip Kaludercic on peregrine
^ permalink raw reply related [relevance 16%]
* Re: [External] : Re: [ELPA] New package: listen
@ 2024-02-26 17:21 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-02-26 17:21 UTC (permalink / raw)
To: Drew Adams; +Cc: Adam Porter, emacs-devel
Drew Adams <drew.adams@oracle.com> writes:
>> 2. WHEN's indentation also saves space, helping
>> to avoid long lines or awkwardly wrapped ones.
>
> OK. So you prefer this:
>
> (when (or xxxxxx
> yyyyyyyy
> zzzzzzzzz)
> foobar)
>
> to this:
>
> (or xxxxxx
> yyyyyyyy
> zzzzzzzzz)
> foobar)
I suppose you mean (and ...)?
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 99%]
* Re: Manuals for GNU ELPA packages
@ 2024-02-26 15:27 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-02-26 15:27 UTC (permalink / raw)
To: Stefan Monnier
Cc: Michael Albinus, Kjartan Óli Ágústsson,
emacs-devel@gnu.org
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> On https://elpa.gnu.org/packages/doc/, there is a directory of all
>>> manuals, plus the README of plz.el. The latter is wrong here, I guess.
>
> I can't see any "readme" or "README" in
> https://elpa.gnu.org/packages/doc/ What am I missing?
I made the mistake of removing it, but the timestamp was from 2024-02-22
so it would reappear shortly (also, it wasn't the plz manual any more).
>
> Stefan
>
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 99%]
* Re: [ELPA] New package: listen
@ 2024-02-26 15:26 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-02-26 15:26 UTC (permalink / raw)
To: Adam Porter; +Cc: emacs-devel
Adam Porter <adam@alphapapa.net> writes:
> Ok, this thread has been interesting. Is there anything that hinders
> the package from being added to ELPA now?
Don't think so, so I've pushed the package specification to elpa.git.
> Thanks,
> Adam
>
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 99%]
* Re: Manuals for GNU ELPA packages
@ 2024-02-26 14:05 73% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-02-26 14:05 UTC (permalink / raw)
To: Stefan Monnier
Cc: Michael Albinus, Kjartan Óli Ágústsson,
emacs-devel@gnu.org
[-- Attachment #1: Type: text/plain, Size: 611 bytes --]
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> - (let ((html-file (concat html-dir (cdr doc))))
>> + (let ((html-file (expand-file-name
>> + (cdr doc)
>> + (expand-file-name
>> + (symbol-name (car pkg-spec))
>> + html-dir))))
>
> That looks about right, except we want relative names, so we should use
> `concat` or `file-name-concat`.
Of course, I forgot that fine-name-concat was available, and yes, the
absolute file names wouldn't really improve the website experience ^^
This is my suggestion:
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Link-to-HTML-manuals-in-their-respective-subdirector.patch --]
[-- Type: text/x-patch, Size: 1972 bytes --]
From e999dbdc195b27ebd5699e5e756131e9b8de5fe5 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Mon, 26 Feb 2024 15:03:43 +0100
Subject: [PATCH] Link to HTML manuals in their respective subdirectories
* elpa-admin.el (elpaa--html-insert-docs): To avoid manuals with the
same names overwriting each other, link directly to the files under
doc/[package name].
(elpaa--html-build-doc): Do not generate symlinks to the actual manual
files.
---
elpa-admin.el | 14 +++++---------
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/elpa-admin.el b/elpa-admin.el
index cde0e3437a..4eb47d6856 100644
--- a/elpa-admin.el
+++ b/elpa-admin.el
@@ -1856,7 +1856,10 @@ arbitrary code."
(file-readable-p html-dir)) ;; html doc files were built
(insert "<dt>Manual</dt> <dd>\n")
(dolist (doc docfiles)
- (let ((html-file (concat html-dir (cdr doc))))
+ (let ((html-file (file-name-concat
+ html-dir
+ (symbol-name (car pkg-spec))
+ (cdr doc))))
(insert "<a href=\"" html-file "\">"
(car doc)
"</a>\n")
@@ -2539,14 +2542,7 @@ directory; one of archive, archive-devel."
:internal--html-docs
(cons (cons (file-name-base html-file)
(file-name-nondirectory html-file))
- (plist-get (cdr pkg-spec) :internal--html-docs)))
-
- ;; Create a symlink from elpa/archive[-devel]/doc/* to
- ;; the actual file, so html references work.
- (with-demoted-errors "%S" ;; 'make-symbolic-link' doesn't work on Windows
- (make-symbolic-link
- (concat (file-name-nondirectory html-dir) "/" destname)
- html-xref-file t))))
+ (plist-get (cdr pkg-spec) :internal--html-docs)))))
(defun elpaa--build-Info-1 (pkg-spec docfile dir html-dir)
"Build an info file from DOCFILE (a texinfo source file).
--
2.43.2
[-- Attachment #3: Type: text/plain, Size: 38 bytes --]
--
Philip Kaludercic on peregrine
^ permalink raw reply related [relevance 73%]
* Re: Manuals for GNU ELPA packages
2023-12-27 13:47 99% ` Philip Kaludercic
@ 2024-02-26 10:49 84% ` Philip Kaludercic
1 sibling, 2 replies; 200+ results
From: Philip Kaludercic @ 2024-02-26 10:49 UTC (permalink / raw)
To: Michael Albinus
Cc: Kjartan Óli Ágústsson, emacs-devel@gnu.org,
Stefan Monnier
[-- Attachment #1: Type: text/plain, Size: 855 bytes --]
Michael Albinus <michael.albinus@gmx.de> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
> Hi Philip,
>
>> ... then the documentation should be packaged in
>> the tarball and also appear online under
>> https://elpa.gnu.org/packages/doc/calibre.html.
>
> On https://elpa.gnu.org/packages/doc/, there is a directory of all
> manuals, plus the README of plz.el. The latter is wrong here, I guess.
It turns out that this is actually a more general issue, since
elpa-admin.el keeps the basename of the file being rendered, even if
multiple packages use the same name (e.g. as is the case with packages
that use "README.org"). As we want to be able to render multiple manual
files, we cannot just trivially rename the name of the symlink.
I think the simplest solution is to point to files in the respective
doc/ sub-directory of each package:
[-- Attachment #2: Type: text/plain, Size: 654 bytes --]
diff --git a/elpa-admin.el b/elpa-admin.el
index cde0e3437a..3e79bef078 100644
--- a/elpa-admin.el
+++ b/elpa-admin.el
@@ -1856,7 +1856,11 @@ arbitrary code."
(file-readable-p html-dir)) ;; html doc files were built
(insert "<dt>Manual</dt> <dd>\n")
(dolist (doc docfiles)
- (let ((html-file (concat html-dir (cdr doc))))
+ (let ((html-file (expand-file-name
+ (cdr doc)
+ (expand-file-name
+ (symbol-name (car pkg-spec))
+ html-dir))))
(insert "<a href=\"" html-file "\">"
(car doc)
"</a>\n")
[-- Attachment #3: Type: text/plain, Size: 111 bytes --]
and perhaps even stop generating the symlinks.
> Best regards, Michael.
--
Philip Kaludercic on peregrine
^ permalink raw reply related [relevance 84%]
* Re: [ELPA] New package: listen
@ 2024-02-26 10:13 86% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-02-26 10:13 UTC (permalink / raw)
To: Adam Porter; +Cc: emacs-devel
Adam Porter <adam@alphapapa.net> writes:
> On 2/26/24 02:09, Philip Kaludercic wrote:
>
>> The pattern I usually use is something like this:
>> (mapcan
>> (lambda (n)
>> (if (> n 0) (list n) nil))
>> '(1 -2 5 0 -10 10))
>> ;;=> (1 5 10)
>> The idea is that when using `mapcan', you provide the cons-cells of
>> the
>> resulting list, instead of having `mapcar' generate them for you and
>> then immediately discard them via `delq'.
>> There should be a seq method for this pattern imo.
>
> Interesting, thanks. It looks like the performance of that technique
> is slightly better than (delq nil (mapcar ...)), but if performance is
> a concern, then it looks like one should use a loop:
>
> (benchmark-run-compiled 1000000
> (mapcan
> (lambda (n)
> (if (> n 0) (list n) nil))
> '(1 -2 5 0 -10 10)))
> ;; (0.21211651699999998 0 0.0)
>
> (benchmark-run-compiled 1000000
> (delq nil
> (mapcar
> (lambda (n)
> (when (> n 0)
> n))
> '(1 -2 5 0 -10 10))))
> ;; (0.21806460800000002 0 0.0)
>
> (benchmark-run-compiled 1000000
> (cl-loop for n in '(1 -2 5 0 -10 10)
> when (> n 0)
> collect n))
> ;; (0.052528039 0 0.0)
True, invoking the lambda expression is probably the most expensive
part, but testing this on a 6-element list with a check that is
basically an opcode, restricts the universality of the claim we are
trying to make.
>> My point is that there shouldn't be an overlap. I think a README
>> shouldn't contain too much detail, but serve as a signpost (suitable
>> both for online and offline (!) reading): "This is brief summary of what
>> you have found, the source code is hosted here, you can find the
>> documentation there, my contact information somewhere else, etc.", while
>> the package description gives a high level overview that doesn't have to
>> updated unless the entire idea of the package changes, while the
>> documentation goes into the nitty-gritty details.
>
> I understand what you're saying, but I think there is often value in
> having all of those categories of information in a single file,
> especially for smaller packages. It's similar to the experience of
> being able to quickly scan through a man page compared to having to
> page through an Info manual.
I am not sure how the last point related to what you are saying, because
that sounds to me like an argument for not using the manual as the
package description. And you already have a shorter package description
in the main file in your commentary section. (It is possible to
instruct ELPA to use this for C-h P, instead of rendering the manual).
>>>>>> Also, your README includes this line
>>>>>> :vc (:fetcher github :repo "alphapapa/listen.el")
>>>>>> which is malformed.
>>>>>
>>>>> I just tested that, and it works for me.
>>>> On Emacs 30? That is not the code we merged...
>>>
>>> No, I'm using Emacs 29 with `vc-use-package'. Its documentation seems
>>> to suggest that it uses the same format as that merged into Emacs 30,
>>> since it says that its features were merged into Emacs 30.
>>>
>>> Maybe `vc-use-package's documentation should be updated to reflect this?
>> Do you mean this: https://github.com/slotThe/vc-use-package? I have
>> no
>> involvement with that project, but I don't see where they mention the
>> "fetcher" notation you mention.
>
> I see it in its readme under "Usage".
Oh, right. Then I guess that should be noted somewhere to avoid
confusion.
>>>>>> What you want is
>>>>>> :vc (:url "https://github.com/alphapapa/listen.el")
>>>
>>> Ok, so no ".git" on the end (i.e. relying on the GitHub redirect)?
>> That doesn't matter (FWIW I didn't know either of the two was a
>> redirect).
>>
>>> And does this mean that none of the host-specific "fetchers" are
>>> available in Emacs 30? (Which FTR is fine with me, as the URL should
>>> be enough, I'm just curious.)
>> No, the package-vc extension for use-package uses the same package
>> specifications as package-vc?
>
> Sorry, I don't understand: "No, it doesn't mean that," or, "No, the
> fetchers are not available in Emacs 30"?
There is no ":fetcher" keyword in Emacs 30.
To rephrase my above sentence: The version of use-package in Emacs 30
has a :vc keyword, that accepts mostly the same syntax for package
specifications as `package-vc-install' does (which in turn is the same
as what elpa-admin uses).
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 86%]
* Re: [ELPA] New package: listen
@ 2024-02-26 8:09 78% ` Philip Kaludercic
1 sibling, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-02-26 8:09 UTC (permalink / raw)
To: Adam Porter; +Cc: emacs-devel
Adam Porter <adam@alphapapa.net> writes:
>> There were a few other places where you did (delq nil (mapcar ...)) that
>> might be replaced by this pattern.
>
> I confess that I've hardly ever used MAPCAN in any of my code--still,
> I'm not sure how that would help to avoid that pattern. For example:
>
> (let ((a '(1 nil 2 nil 3))
> (b '(4 nil 5 nil 6)))
> (mapcan #'identity (list a b)))
>
> ;; (1 nil 2 nil 3 4 nil 5 nil 6)
>
> But I'm probably missing something.
The pattern I usually use is something like this:
(mapcan
(lambda (n)
(if (> n 0) (list n) nil))
'(1 -2 5 0 -10 10))
;;=> (1 5 10)
The idea is that when using `mapcan', you provide the cons-cells of the
resulting list, instead of having `mapcar' generate them for you and
then immediately discard them via `delq'.
There should be a seq method for this pattern imo.
>> Not really, if you don't care about compiler warnings. It just seems
>> like the kind of things that could cause problems at some later time,
>> when definitions are moved around.
>
> I do care about compiler warnings--I wrote makem.sh to catch such
> warnings in my projects before they reach users--but in this case,
> that code's not going anywhere, because it's already with
> bookmark-related code.
Feel free to do as you like (none of this is barring inclusion, if that
wasn't clear), that was just a suggestion.
>> Ah, the `t did confuse me momentarily, but in that case you can replace
>> the (guard ...) with (and 't (guard ...)).
>
> As much as I advocate using pcase and its powerful expressions, I
> think that would make this example harder to follow. The pcase
> pattern is used to test an argument, and the string test is a separate
> concern.
But consider the saved indentation!
>>>> @@ -328,7 +328,7 @@ PROMPT is passed to `format-prompt', which see."
>>>> n)
>>>> (when current-track
>>>> (cl-callf2 delete current-track tracks))
>>>> - (setf n (length tracks))
>>>> + (setf n (length tracks)) ;why the variable?
>>>
>>> Because the value is used elsewhere in the function. Am I missing
>>> something? (Anyway, as noted in the source, I did not write that
>>> function.)
>> Then I missed something, because I just saw the variable being
>> declared
>> in the let-head, set here and used once later.
>
> It's used in two places, and it would be undesirable to recalculate
> the list's length every time through the loop.
I see it now, sorry.
>>>> On the topic of the readme/manual, wouldn't it be better to have a
>>>> separate README file? Then again, the manual is pretty short, and I
>>>> don't know if it is worth having it in the first place...
>>>
>>> As you said, this readme is currently trivial. Were it larger,
>>> however--well, I have other packages with much larger readmes that are
>>> also converted to manuals. There would not be much gained by
>>> separating into files.
>> I don't think that is a good practice. A README for when you have
>> fetched the sources and want to figure out what is what, a manual for
>> when you have already installed a package and a package description for
>> when you are previewing a package using C-h P are three different
>> things. One shouldn't cover all of it with the same file if you ask me,
>> since they all have different audiences with different levels of
>> interest.
>
> I don't know about that. Especially for small packages with trivial
> documentation. Maintaining documentation and commentaries, keeping
> them reasonably in sync, etc. is enough work without having them split
> into multiple files. Having a README.org which is viewable at the
> package's repo also generate the manual is a relief to me.
My point is that there shouldn't be an overlap. I think a README
shouldn't contain too much detail, but serve as a signpost (suitable
both for online and offline (!) reading): "This is brief summary of what
you have found, the source code is hosted here, you can find the
documentation there, my contact information somewhere else, etc.", while
the package description gives a high level overview that doesn't have to
updated unless the entire idea of the package changes, while the
documentation goes into the nitty-gritty details.
>>>> Also, your README includes this line
>>>> :vc (:fetcher github :repo "alphapapa/listen.el")
>>>> which is malformed.
>>>
>>> I just tested that, and it works for me.
>> On Emacs 30? That is not the code we merged...
>
> No, I'm using Emacs 29 with `vc-use-package'. Its documentation seems
> to suggest that it uses the same format as that merged into Emacs 30,
> since it says that its features were merged into Emacs 30.
>
> Maybe `vc-use-package's documentation should be updated to reflect this?
Do you mean this: https://github.com/slotThe/vc-use-package? I have no
involvement with that project, but I don't see where they mention the
"fetcher" notation you mention.
>>>> What you want is
>>>> :vc (:url "https://github.com/alphapapa/listen.el")
>
> Ok, so no ".git" on the end (i.e. relying on the GitHub redirect)?
That doesn't matter (FWIW I didn't know either of the two was a redirect).
> And does this mean that none of the host-specific "fetchers" are
> available in Emacs 30? (Which FTR is fine with me, as the URL should
> be enough, I'm just curious.)
No, the package-vc extension for use-package uses the same package
specifications as package-vc?
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 78%]
* Re: [ELPA] New package: listen
@ 2024-02-26 7:47 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-02-26 7:47 UTC (permalink / raw)
To: Adam Porter; +Cc: Andreas Schwab, emacs-devel
Adam Porter <adam@alphapapa.net> writes:
> Hi Andreas,
>
> On 2/25/24 08:17, Andreas Schwab wrote:
>> On Feb 25 2024, Adam Porter wrote:
>>
>>>> @@ -942,10 +941,10 @@ extension.
>>>> Return one of symbols `vorbis', `opus', `flac', or `mp3'."
>>>> (let ((case-fold-search t))
>>>> - (cond ((string-match ".ogg$" filename) 'vorbis)
>>>> - ((string-match ".opus$" filename) 'opus)
>>>> - ((string-match ".flac$" filename) 'flac)
>>>> - ((string-match ".mp3$" filename) 'mp3)
>>>> + (cond ((string-match ".ogg\\'" filename) 'vorbis)
>>>> + ((string-match ".opus\\'" filename) 'opus)
>>>> + ((string-match ".flac\\'" filename) 'flac)
>>>> + ((string-match ".mp3\\'" filename) 'mp3)
>>>> (t nil))))
>>>
>>> According to the Elisp manual: "When matching a string instead of a
>>> buffer, ‘$’ matches at the end of the string or before a newline
>>> character." So it appears to be correct here
>> It should only match at the end of the string, not before a newline.
>
> As the manual says:
>
> ‘$’
> is similar to ‘^’ but matches only at the end of a line (or the end
> of the accessible portion of the buffer). Thus, ‘x+$’ matches a
> string of one ‘x’ or more at the end of a line.
>
> When matching a string instead of a buffer, ‘$’ matches at the end
> of the string or before a newline character.
^
this is the problem.
Since it is possible for file-names to contain newline characters,
matching the end of a line can result in false-positives:
(string-match-p
"\\.el$"
"foo.el\nbar.le")
;;=> 3
(string-match-p
"\\.el\\'"
"foo.el\nbar.le")
;;=> nil
(It's called the "manual", not the "infallible" (hehe) for a reason)
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 99%]
* Re: NonGNU ELPA: Conditions for accepting a potential new package 'rmsbolt' ?
@ 2024-02-26 7:44 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-02-26 7:44 UTC (permalink / raw)
To: Jeremy Bryant
Cc: emacs-devel@gnu.org, Jay Kamat, João Távora,
Stefan Monnier
Jeremy Bryant <jb@jeremybryant.net> writes:
> I would like to recommend the package 'rmsbolt' for NonGNU ELPA and
> volunteer for any required changes.
>
> The author is Jay Kamat, who as I understand is potentially supportive
> if the changes are minimal (and I am volunteering for these.)
Minimal as in "small diff" or "small effort"?
> 1. What is it?
> "A supercharged implementation of the [[https://github.com/mattgodbolt/compiler-explorer][godbolt compiler-explorer]] for Emacs.
>
> RMSbolt tries to make it easy to see what your compiler is doing. It does this
> by showing you the assembly output of a given source code file. It also
> highlights which source code a given assembly block corresponds to, and vice
> versa. It supports more types of languages than any previous tool of its kind.
> "
Sounds interesting. I suppose the joke here is that RMS is God?
> It is currently hosted on gitlab and distributed on MELPA.
Could you provide a URL?
> 2. License
> From reading nongnu.elpa.git's README.org
>
> The package displays its License, which is Affero.
> Is the GNU Affero license considered suitable for NonGNU ELPA?
Yes, it should be.
>
> 3. Other
> I believe it follows the other requirements.
>
>
> WDYT?
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 99%]
* Re: Adding package "Loopy" to Non-GNU Devel?
@ 2024-02-25 20:50 91% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-02-25 20:50 UTC (permalink / raw)
To: Okamsn; +Cc: emacs-devel
Okamsn <okamsn@protonmail.com> writes:
> Okamsn wrote:
>> Philip Kaludercic wrote:
>>> Okamsn <okamsn@protonmail.com> writes:
>>>> I keep the extension package in the same GitHub repo as the main package for
>>>> testing purposes. The Dash functionality was requested by a user, but
>>>> Dash is
>>>> not used by the rest of the package. Because of that, I put the Dash
>>>> functionality in a small separate package.
>>>
>>> You are talking about the loopy-dash.el file in the same branch, right?
>>
>> Yes.
>>
>>> If possible, it would be better if you could at least maintain it in a
>>> separate branch.
>>
>> If I added the file "loopy-dash.el" to an ".elpaignore" file in the main
>> branch and used GitHub Actions to push any changes from the main branch
>> to another branch containing the file "loopy-dash.el", would that be
>> acceptable?
Sorry for not answering earlier, this doesn't really solve the issue,
since the root issue is that when using package-vc or elpa-admin, you
still have two versions of the file in `load-path'.
>
> Hello,
>
> I figured out how to make GitHub automatically copy changes of the file
> to another branch when the master branch changes, and have listed the
> file `loopy-dash.el` in the `.elpaignore` file on the master branch.
If we were to disregard examples as those mentioned above, then this
would be an acceptable solution, but I'd rather not, unless you
categorically reject having two separate and disjoint branches.
> I successfully installed the packages locally using the instructions in
> the ELPA readme.
>
> I have attached a patch file. Are there any other changes that you would
> like made?
I don't think there is anything else (the only thing I can vainly try to
bring up is that having a diminutive as the name of a macro is something
I find peculiar, and I can imagine would keep a number of other people
from using the otherwise nice package, but it seems it is too late for
that now?)
> Thank you.
^ permalink raw reply [relevance 91%]
* Re: [ELPA] New package: listen
@ 2024-02-25 13:45 51% ` Philip Kaludercic
1 sibling, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-02-25 13:45 UTC (permalink / raw)
To: Adam Porter; +Cc: emacs-devel
Adam Porter <adam@alphapapa.net> writes:
> Hi Philip,
>
> Thanks for your review. Comments to follow:
>
> On 2/25/24 05:43, Philip Kaludercic wrote:
>> Adam Porter <adam@alphapapa.net> writes:
>>
>>> Hi,
>>>
>>> I'd like to submit a new package to ELPA, named "Listen". It's a
>>> simple audio/music player that uses VLC as a backend.
>>>
>>> https://github.com/alphapapa/listen.el
>> Note that the copyright lines still have to be updated for it to be
>> added to GNU ELPA.
>
> Oops, I forgot to update the ones other than in listen.el. Done.
>
>> Here are a few comments, questions and suggestions from briefly skimming
>> the code:
>> diff --git a/listen-info.el b/listen-info.el
>> index e74d376df9..a95a5b1d1b 100644
>> --- a/listen-info.el
>> +++ b/listen-info.el
>> @@ -56,7 +56,6 @@
>> (require 'bindat)
>> (require 'cl-lib)
>> -(require 'seq)
>
> The `seq' library is used in the file, so shouldn't this line be present?
Sorry, should have explained that. If you depend on Emacs 29, then seq
is preloaded, so you don't need the line. If you prefer to, you can
keep it in though.
>> @@ -942,10 +941,10 @@ extension.
>> Return one of symbols `vorbis', `opus', `flac', or `mp3'."
>> (let ((case-fold-search t))
>> - (cond ((string-match ".ogg$" filename) 'vorbis)
>> - ((string-match ".opus$" filename) 'opus)
>> - ((string-match ".flac$" filename) 'flac)
>> - ((string-match ".mp3$" filename) 'mp3)
>> + (cond ((string-match ".ogg\\'" filename) 'vorbis)
>> + ((string-match ".opus\\'" filename) 'opus)
>> + ((string-match ".flac\\'" filename) 'flac)
>> + ((string-match ".mp3\\'" filename) 'mp3)
>> (t nil))))
>
> According to the Elisp manual: "When matching a string instead of a
> buffer, ‘$’ matches at the end of the string or before a newline
> character." So it appears to be correct here (and its meaning is
> widely known, whereas the Emacsism "\\'" is not (I can never remember
> the escape sequences).
Hmm, I just went by the convention used in auto-mode-alist here (the
trick to remember \\' is that \\' and \\' always occur in the same order
as you would quote a symbol in a docstring).
> A good change to make, though, would be to escape the period, as
> otherwise it would match any character, as in "fooogg" rather than
> "foo.ogg".
Right.
>> diff --git a/listen-lib.el b/listen-lib.el
>> index 7743080c23..b3d48f51fa 100644
>> --- a/listen-lib.el
>> +++ b/listen-lib.el
>> @@ -50,7 +50,7 @@
>> ;;;; Faces
>> (defgroup listen-faces nil
>> - "Faces."
>> + "Faces used by listen.el."
>> :group 'listen)
>
> As the `listen-faces' group is within the `listen' group, I would
> think that that its faces are related to `listen' goes without saying.
But that context would be missing if you were to use something like
`customize-apropos-groups'.
>> diff --git a/listen-library.el b/listen-library.el
>> index 77022e1791..90d40468ad 100644
>> --- a/listen-library.el
>> +++ b/listen-library.el
>> @@ -100,8 +100,8 @@ mode line and bookmark name. BUFFER may be specified in which to
>> show the view."
>> (interactive
>> (list (list (read-file-name "View library for: "))
>> - :name (when current-prefix-arg
>> - (read-string "Library name: "))))
>> + :name (and current-prefix-arg
>> + (read-string "Library name: "))))
>
> No, thanks. I'm aware of this minor tradition, but I disagree with it.
I wouldn't call it a minor tradition (e.g. in Scheme the return value of
`when' is unspecified. CLtL2 says "If the value is relevant, then it
may be stylistically more appropriate to use and or if."), and I am
curious why you disagree with it, but you are of course free to do as
you want.
>> @@ -181,7 +181,7 @@ Interactively, read COMMAND and use tracks at point in
>> ;; it ought to return sections in the region), it returns nil.
>> ;; This may be confusing to users, but it seems like an upstream
>> ;; issue.
>> - (or (flatten-list (mapcar #'value-of (magit-region-sections)))
>> + (or (flatten-list (mapcar #'value-of (magit-region-sections))) ;or `mapcan'?
>> (value-of (magit-current-section)))))
>
> Probably a good idea.
There were a few other places where you did (delq nil (mapcar ...)) that
might be replaced by this pattern.
>> @@ -192,7 +192,7 @@ Interactively, read COMMAND and use tracks at point in
>> "Return a bookmark record for the current library buffer."
>> (cl-assert listen-library-paths)
>> `(,(format "Listen library: %s" (or listen-library-name listen-library-paths))
>> - (handler . listen-library--bookmark-handler)
>> + (handler . ,#'listen-library--bookmark-handler)
>
> Is there any advantage to this, given that the function is defined a
> few lines later? Compiler warnings don't seem relevant here.
Not really, if you don't care about compiler warnings. It just seems
like the kind of things that could cause problems at some later time,
when definitions are moved around.
>> diff --git a/listen-mpd.el b/listen-mpd.el
>> index b8a104febe..8c3a302f08 100644
>> --- a/listen-mpd.el
>> +++ b/listen-mpd.el
>> @@ -89,17 +89,17 @@ completion."
>> (cons 'affixation-function #'affix)
>> ;; (cons 'annotation-function #'annotate)
>> ))))
>> - (`t (unless (string-empty-p str)
>> - (let ((tag (pcase tag
>> - ('any 'file)
>> - (_ tag))))
>> - (delete-dups
>> - (delq nil
>> - (mapcar (lambda (row)
>> - (when-let ((value (alist-get tag row)))
>> - (propertize value
>> - :mpc-alist row)))
>> - (search-any (split-string str))))))))))
>> + ((guard (not (string-empty-p str)))
>> + (let ((tag (pcase tag
>> + ('any 'file)
>> + (_ tag))))
>> + (delete-dups
>> + (delq nil
>> + (mapcar (lambda (row)
>> + (when-let ((value (alist-get tag row)))
>> + (propertize value
>> + :mpc-alist row)))
>> + (search-any (split-string str)))))))))
>
> AFAICT, this change would not be strictly equivalent, as the original
> tests explicitly for t before testing the string, which, AFAICT, is
> the correct way to handle this part of the completion API.
Ah, the `t did confuse me momentarily, but in that case you can replace
the (guard ...) with (and 't (guard ...)).
>> diff --git a/listen-queue.el b/listen-queue.el
>> index 9515e3d7dc..cf4bd494bd 100644
>> --- a/listen-queue.el
>> +++ b/listen-queue.el
>> @@ -312,7 +312,7 @@ PROMPT is passed to `format-prompt', which see."
>> ;; homedir path (so queues could be portable with music
>> ;; libraries).
>> :filename (abbreviate-file-name filename)
>> - :artist (map-elt metadata "artist")
>> + :artist (map-elt metadata "artist") ;`metadata' is an alist,
>> right? So why not use `let-alist'?
>
> Please note that the keys are strings, which AFAICT `let-alist' is not
> compatible with (nor `pcase-let', as it does not allow the test
> function to be specified). `map-elt' tests with `equal'.
OK, I see.
>> @@ -328,7 +328,7 @@ PROMPT is passed to `format-prompt', which see."
>> n)
>> (when current-track
>> (cl-callf2 delete current-track tracks))
>> - (setf n (length tracks))
>> + (setf n (length tracks)) ;why the variable?
>
> Because the value is used elsewhere in the function. Am I missing
> something? (Anyway, as noted in the source, I did not write that
> function.)
Then I missed something, because I just saw the variable being declared
in the let-head, set here and used once later.
>> @@ -357,6 +357,8 @@ PROMPT is passed to `format-prompt', which see."
>> (1+ (seq-position (listen-queue-tracks queue)
>> (listen-queue-current queue)
>> (lambda (a b)
>> + ;; FWIW you still have a similar
>> + ;; race condition here.
>
> I don't understand what you mean. The comment before this hunk of
> code is not about a race condition (not a subtle or random one,
> anyway--it's a matter of whether the user manually modifies a track
> and then refreshes the queue's tracks from disk while the track is
> playing, something that is unlikely to happen unless the user is
> actively tidying their tracks' metadata, and fixing it will require
> more careful consideration; as well, if the file gets renamed in the
> process, there's little that can be done, as the track's primary
> identifier will no longer exist).
My understanding was that you were handling the case where files could
be renamed, but if that is not your concern, then disregard the comment.
>> @@ -427,7 +429,7 @@ tracks in the queue unchanged)."
>> (goto-char beg)
>> (cl-loop collect (vtable-current-object)
>> do (forward-line 1)
>> - while (<= (point) end))))))
>> + until (eobp))))))
>
> This code does not test for the end of the buffer, so `eobp' would not
> be appropriate.
You are right, never mind.
>> --- a/listen-vlc.el
>> +++ b/listen-vlc.el
>> @@ -43,7 +43,8 @@
>> (save-excursion
>> (insert (listen--send player "info")))
>> (cl-loop while (re-search-forward (rx bol "| " (group (1+ (not blank))) ": "
>> - (group (1+ (not (any ""))))) nil t)
>> + (group (1+ (not (any "\C-m")))))
>> + nil t)
>
> Other than the formatting, what is the purpose of this change? This
> function parses output from VLC, and it appears to work correctly.
Formatting. Emacs highlights the "nil t" as occurring in-between closed
parentheses, since it can be easily missed.
>> @@ -116,7 +117,7 @@ Stops playing, clears playlist, adds FILE, and plays it."
>> "Return or set PLAYER's VOLUME.
>> VOLUME is an integer percentage."
>> (if volume
>> - (listen--send player (format "volume %s" (* 255 (/ volume 100.0))))
>> + (listen--send player (format "volume %s" (* 255 (/ volume 100.0)))) ;what if this is OOB?
>
> "Out Of Bounds"? What do you mean? VLC returns a value from 0-255,
> and `volume' is specified to be an integer percentage (i.e. from
> 0-100). As far as I can tell, this works correctly.
I couldn't infer that from reading the function, so I wondered what
happens when `volume' is not between 0 and 100. Perhaps a cl-assert
would be nice to have.
>> diff --git a/listen.el b/listen.el
>> index 3e3d11d572..c381b2a113 100755
>> --- a/listen.el
>> +++ b/listen.el
>> @@ -75,7 +75,7 @@
>> :link '(emacs-commentary-link "listen")
>> :link '(emacs-library-link "listen"))
>> -(defcustom listen-directory "~/Music"
>> +(defcustom listen-directory "~/Music" ;perhaps check XDG_MUSIC_DIR here?
>
> I cannot find such a variable defined, neither on my system nor on a
> Web search. It doesn't appear to be part of the XDG standard.
>
>> -(declare-function listen-queue-next "listen-queue")
>> +(declare-function listen-queue-next "listen-queue") ;why not `require' it?
>
> Because it is an autoloaded command, one which the user might not use,
> so loading the library might be unnecessary.
>
>> @@ -251,19 +251,19 @@ command with completion."
>> (defun listen-read-time (time)
>> "Return TIME in seconds.
>> TIME is an HH:MM:SS string."
>> - (string-match (rx (group (1+ num))
>> - (optional ":" (group (1+ num))
>> - (optional ":" (group (1+ num)))))
>> - time)
>> - (let ((fields (nreverse
>> - (remq nil
>> - (list (match-string 1 time)
>> - (match-string 2 time)
>> - (match-string 3 time)))))
>> - (factors [1 60 3600]))
>> - (cl-loop for field in fields
>> - for factor across factors
>> - sum (* (string-to-number field) factor))))
>> + (when (string-match (rx (group (1+ num))
>> + (optional ":" (group (1+ num))
>> + (optional ":" (group (1+ num)))))
>> + time)
>> + (let ((fields (nreverse
>> + (remq nil
>> + (list (match-string 1 time)
>> + (match-string 2 time)
>> + (match-string 3 time)))))
>> + (factors [1 60 3600]))
>> + (cl-loop for field in fields
>> + for factor across factors
>> + sum (* (string-to-number field) factor)))))
>
> If this function fails, I want it to signal an error, not return nil.
Am I missing something, or where will the error be signaled? If the
pattern doesn't match, the match data won't be modified, and you'll
extract arbitrary substrings out of TIME. `String-to-number' doesn't
raise an error on malformed input,
(string-to-number "31-") ;=> 31 (#o37, #x1f, ?\C-_)
(string-to-number "x") ;=> 0 (#o0, #x0, ?\C-@)
(string-to-number "") ;=> 0 (#o0, #x0, ?\C-@)
the only exception being if there was no match data for some n
(string-to-number (match-string 100)) ;signals (wrong-type-argument stringp nil)
If you want to signal an error, then I think the robust thing would be
to check if `string-match' succeeds as proposed above, but using an `if'
not a `when' to raise an error in the ELSE case.
>>> For more details (though there's not much else to say), please see the
>>> readme/Info manual.
>> On the topic of the readme/manual, wouldn't it be better to have a
>> separate README file? Then again, the manual is pretty short, and I
>> don't know if it is worth having it in the first place...
>
> As you said, this readme is currently trivial. Were it larger,
> however--well, I have other packages with much larger readmes that are
> also converted to manuals. There would not be much gained by
> separating into files.
I don't think that is a good practice. A README for when you have
fetched the sources and want to figure out what is what, a manual for
when you have already installed a package and a package description for
when you are previewing a package using C-h P are three different
things. One shouldn't cover all of it with the same file if you ask me,
since they all have different audiences with different levels of
interest.
>> Also, your README includes this line
>> :vc (:fetcher github :repo "alphapapa/listen.el")
>> which is malformed.
>
> I just tested that, and it works for me.
On Emacs 30? That is not the code we merged...
--8<---------------cut here---------------start------------->8---
Debugger entered--Lisp error: (error "use-package: Keyword :vc received unknown argument: :fetcher. Supported keywords are: (:url :branch :lisp-dir :main-file :vc-backend :rev)")
signal(error ("use-package: Keyword :vc received unknown argument: :fetcher. Supported keywords are: (:url :branch :lisp-dir :main-file :vc-backend :rev)"))
error("use-package: %s" "Keyword :vc received unknown argument: :fetcher. Supported keywords are: (:url :branch :lisp-dir :main-file :vc-backend :rev)")
use-package-normalize--vc-arg((listen :fetcher github :repo "alphapapa/listen.el"))
use-package-normalize/:vc(listen :vc ((:fetcher github :repo "alphapapa/listen.el")))
use-package-normalize-plist(listen (:vc (:fetcher github :repo "alphapapa/listen.el")) nil use-package-merge-keys)
use-package-normalize-keywords(listen (:vc (:fetcher github :repo "alphapapa/listen.el")))
...
--8<---------------cut here---------------end--------------->8---
>> What you want is
>> :vc (:url "https://github.com/alphapapa/listen.el")
>> or after the package has been added to ELPA, then just
>> :vc t
>
> I added that to the readme for before the package is available through
> ELPA. Afterward I intend to recommend installing it from ELPA, not
> from git.
Yes, I noticed that after I had sent my message. That is better
practice anyway, at least for the regular user.
> Please let me know if any other changes are needed.
>
> --Adam
>
--
Philip Kaludercic on icterid
^ permalink raw reply [relevance 51%]
* Re: [ELPA] New package: listen
@ 2024-02-25 11:43 39% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-02-25 11:43 UTC (permalink / raw)
To: Adam Porter; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 390 bytes --]
Adam Porter <adam@alphapapa.net> writes:
> Hi,
>
> I'd like to submit a new package to ELPA, named "Listen". It's a
> simple audio/music player that uses VLC as a backend.
>
> https://github.com/alphapapa/listen.el
Note that the copyright lines still have to be updated for it to be
added to GNU ELPA.
Here are a few comments, questions and suggestions from briefly skimming
the code:
[-- Attachment #2: Type: text/plain, Size: 9628 bytes --]
diff --git a/listen-info.el b/listen-info.el
index e74d376df9..a95a5b1d1b 100644
--- a/listen-info.el
+++ b/listen-info.el
@@ -1,6 +1,6 @@
;;; listen-info.el --- Audio file metadata library -*- lexical-binding: t; -*-
-;; Copyright (C) 2020-2021 Free Software Foundation, Inc.
+;; Copyright (C) 2020-2021, 2024 Free Software Foundation, Inc.
;; Author: Petteri Hintsanen <petterih@iki.fi>
@@ -56,7 +56,6 @@
(require 'bindat)
(require 'cl-lib)
-(require 'seq)
(require 'subr-x)
(defconst listen-info--max-peek-size (* 2048 1024)
@@ -942,10 +941,10 @@ extension.
Return one of symbols `vorbis', `opus', `flac', or `mp3'."
(let ((case-fold-search t))
- (cond ((string-match ".ogg$" filename) 'vorbis)
- ((string-match ".opus$" filename) 'opus)
- ((string-match ".flac$" filename) 'flac)
- ((string-match ".mp3$" filename) 'mp3)
+ (cond ((string-match ".ogg\\'" filename) 'vorbis)
+ ((string-match ".opus\\'" filename) 'opus)
+ ((string-match ".flac\\'" filename) 'flac)
+ ((string-match ".mp3\\'" filename) 'mp3)
(t nil))))
(provide 'listen-info)
diff --git a/listen-lib.el b/listen-lib.el
index 7743080c23..b3d48f51fa 100644
--- a/listen-lib.el
+++ b/listen-lib.el
@@ -50,7 +50,7 @@
;;;; Faces
(defgroup listen-faces nil
- "Faces."
+ "Faces used by listen.el."
:group 'listen)
(defface listen-artist '((t :inherit font-lock-variable-name-face))
diff --git a/listen-library.el b/listen-library.el
index 77022e1791..90d40468ad 100644
--- a/listen-library.el
+++ b/listen-library.el
@@ -100,8 +100,8 @@ mode line and bookmark name. BUFFER may be specified in which to
show the view."
(interactive
(list (list (read-file-name "View library for: "))
- :name (when current-prefix-arg
- (read-string "Library name: "))))
+ :name (and current-prefix-arg
+ (read-string "Library name: "))))
(let* ((filenames (cl-loop for path in paths
if (file-directory-p path)
append (directory-files-recursively path "." t)
@@ -181,7 +181,7 @@ Interactively, read COMMAND and use tracks at point in
;; it ought to return sections in the region), it returns nil.
;; This may be confusing to users, but it seems like an upstream
;; issue.
- (or (flatten-list (mapcar #'value-of (magit-region-sections)))
+ (or (flatten-list (mapcar #'value-of (magit-region-sections))) ;or `mapcan'?
(value-of (magit-current-section)))))
;;;;; Bookmark support
@@ -192,7 +192,7 @@ Interactively, read COMMAND and use tracks at point in
"Return a bookmark record for the current library buffer."
(cl-assert listen-library-paths)
`(,(format "Listen library: %s" (or listen-library-name listen-library-paths))
- (handler . listen-library--bookmark-handler)
+ (handler . ,#'listen-library--bookmark-handler)
(name . ,listen-library-name)
(paths . ,listen-library-paths)))
diff --git a/listen-mpd.el b/listen-mpd.el
index b8a104febe..8c3a302f08 100644
--- a/listen-mpd.el
+++ b/listen-mpd.el
@@ -89,17 +89,17 @@ completion."
(cons 'affixation-function #'affix)
;; (cons 'annotation-function #'annotate)
))))
- (`t (unless (string-empty-p str)
- (let ((tag (pcase tag
- ('any 'file)
- (_ tag))))
- (delete-dups
- (delq nil
- (mapcar (lambda (row)
- (when-let ((value (alist-get tag row)))
- (propertize value
- :mpc-alist row)))
- (search-any (split-string str))))))))))
+ ((guard (not (string-empty-p str)))
+ (let ((tag (pcase tag
+ ('any 'file)
+ (_ tag))))
+ (delete-dups
+ (delq nil
+ (mapcar (lambda (row)
+ (when-let ((value (alist-get tag row)))
+ (propertize value
+ :mpc-alist row)))
+ (search-any (split-string str)))))))))
(try (string _table _pred point &optional _metadata)
(cons string point))
(all (string table pred _point)
diff --git a/listen-queue.el b/listen-queue.el
index 9515e3d7dc..cf4bd494bd 100644
--- a/listen-queue.el
+++ b/listen-queue.el
@@ -312,7 +312,7 @@ PROMPT is passed to `format-prompt', which see."
;; homedir path (so queues could be portable with music
;; libraries).
:filename (abbreviate-file-name filename)
- :artist (map-elt metadata "artist")
+ :artist (map-elt metadata "artist") ;`metadata' is an alist, right? So why not use `let-alist'?
:title (map-elt metadata "title")
:album (map-elt metadata "album")
:number (map-elt metadata "tracknumber")
@@ -328,7 +328,7 @@ PROMPT is passed to `format-prompt', which see."
n)
(when current-track
(cl-callf2 delete current-track tracks))
- (setf n (length tracks))
+ (setf n (length tracks)) ;why the variable?
;; Don't use dotimes result (bug#16206)
(dotimes (i n)
(cl-rotatef (elt tracks i) (elt tracks (+ i (cl-random (- n i))))))
@@ -357,6 +357,8 @@ PROMPT is passed to `format-prompt', which see."
(1+ (seq-position (listen-queue-tracks queue)
(listen-queue-current queue)
(lambda (a b)
+ ;; FWIW you still have a similar
+ ;; race condition here.
(equal (listen-track-filename a)
(listen-track-filename b))))))))
@@ -427,7 +429,7 @@ tracks in the queue unchanged)."
(goto-char beg)
(cl-loop collect (vtable-current-object)
do (forward-line 1)
- while (<= (point) end))))))
+ until (eobp))))))
;;;;; Bookmark support
diff --git a/listen-vlc.el b/listen-vlc.el
index 12e7e58693..a387c1c3d5 100755
--- a/listen-vlc.el
+++ b/listen-vlc.el
@@ -43,7 +43,8 @@
(save-excursion
(insert (listen--send player "info")))
(cl-loop while (re-search-forward (rx bol "| " (group (1+ (not blank))) ": "
- (group (1+ (not (any ""))))) nil t)
+ (group (1+ (not (any "\C-m")))))
+ nil t)
collect (cons (match-string 1) (match-string 2)))))
(cl-defmethod listen--filename ((player listen-player-vlc))
@@ -116,7 +117,7 @@ Stops playing, clears playlist, adds FILE, and plays it."
"Return or set PLAYER's VOLUME.
VOLUME is an integer percentage."
(if volume
- (listen--send player (format "volume %s" (* 255 (/ volume 100.0))))
+ (listen--send player (format "volume %s" (* 255 (/ volume 100.0)))) ;what if this is OOB?
(* 100 (/ (string-to-number (listen--send player "volume")) 255.0))))
(provide 'listen-vlc)
diff --git a/listen.el b/listen.el
index 3e3d11d572..c381b2a113 100755
--- a/listen.el
+++ b/listen.el
@@ -75,7 +75,7 @@
:link '(emacs-commentary-link "listen")
:link '(emacs-library-link "listen"))
-(defcustom listen-directory "~/Music"
+(defcustom listen-directory "~/Music" ;perhaps check XDG_MUSIC_DIR here?
"Default music directory."
:type 'directory)
@@ -101,7 +101,7 @@ Interactively, uses the default player."
(when (eq player listen-player)
(setf listen-player nil)))
-(declare-function listen-queue-next "listen-queue")
+(declare-function listen-queue-next "listen-queue") ;why not `require' it?
(defun listen-next (player)
"Play next track in PLAYER's queue.
Interactively, uses the default player."
@@ -251,19 +251,19 @@ command with completion."
(defun listen-read-time (time)
"Return TIME in seconds.
TIME is an HH:MM:SS string."
- (string-match (rx (group (1+ num))
- (optional ":" (group (1+ num))
- (optional ":" (group (1+ num)))))
- time)
- (let ((fields (nreverse
- (remq nil
- (list (match-string 1 time)
- (match-string 2 time)
- (match-string 3 time)))))
- (factors [1 60 3600]))
- (cl-loop for field in fields
- for factor across factors
- sum (* (string-to-number field) factor))))
+ (when (string-match (rx (group (1+ num))
+ (optional ":" (group (1+ num))
+ (optional ":" (group (1+ num)))))
+ time)
+ (let ((fields (nreverse
+ (remq nil
+ (list (match-string 1 time)
+ (match-string 2 time)
+ (match-string 3 time)))))
+ (factors [1 60 3600]))
+ (cl-loop for field in fields
+ for factor across factors
+ sum (* (string-to-number field) factor)))))
;;;; Transient
[-- Attachment #3: Type: text/plain, Size: 1956 bytes --]
> Compared to other Emacs music players like EMMS, Bongo, etc, it's much
> simpler to use: no setup or configuration is required--just "M-x
> listen RET" and use the Transient menu to begin.
>
> Compared to packages that use MPD as a backend, Listen provides a
> simpler UI, and it doesn't require installing and configuring MPD; the
> user just selects one or more files to play. (However, support is
> provided for discovering and playing tracks from a local MPD library
> by searching its metadata database.)
>
> It's extensible, so e.g. a new backend could easily be added to use
> something like MPV to play files.
That would be nice.
> A queue (playlist) view is provided using the nice new Vtable library
> in Emacs 29. And a library view is provided using the Taxy and
> Magit-Section libraries to browse tracks grouped by metadata.
>
> For more details (though there's not much else to say), please see the
> readme/Info manual.
On the topic of the readme/manual, wouldn't it be better to have a
separate README file? Then again, the manual is pretty short, and I
don't know if it is worth having it in the first place...
Also, your README includes this line
:vc (:fetcher github :repo "alphapapa/listen.el")
which is malformed. What you want is
:vc (:url "https://github.com/alphapapa/listen.el")
or after the package has been added to ELPA, then just
:vc t
> By the way, unlike with some other packages I've submitted, I've not
> fully settled on the name, so I'm open to suggestions. I considered
> naming it "EMP" (for "Emacs Music Player", which is fun and concise,
> and which is surprisingly not yet taken--although Nic Vollmer has an
> unpackaged library by that name, but he's graciously offered me the
> name for use with this package). But "Listen" seemed more descriptive
> and concise enough, so that's what I've gone with for now.
I like the name ;)
> Thanks,
> Adam
>
>
--
Philip Kaludercic on icterid
^ permalink raw reply related [relevance 39%]
* Re: Docs on ELPA (was Re: Adding Flycheck to NonGNU ELPA)
@ 2024-02-25 10:06 87% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-02-25 10:06 UTC (permalink / raw)
To: Stefan Monnier
Cc: Spencer Baugh, Bozhidar Batsov, Dmitry Gutov, joakim, Emacs Devel
[-- Attachment #1: Type: text/plain, Size: 345 bytes --]
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> It does, e.g. Compat directs directly to elpa.gnu.org:
>> https://elpa.gnu.org/packages/doc/compat/compat.html
>
> BTW, any help setting up some CSS styling there would be welcome
> (probably following the CSS styling used for Texinfo docs on on
> www.gnu.org).
Do we need more than this:
[-- Attachment #2: Type: text/plain, Size: 912 bytes --]
diff --git a/elpa-admin.el b/elpa-admin.el
index e1e0d2dd1e..f45c8586a0 100644
--- a/elpa-admin.el
+++ b/elpa-admin.el
@@ -43,6 +43,7 @@
(defvar elpaa--name "NonGNU")
(defvar elpaa--gitrepo "emacs/nongnu.git")
(defvar elpaa--url "https://elpa.gnu.org/nongnu/")
+(defvar elpaa--css-url "https://www.gnu.org/software/emacs/manual.css")
(defvar elpaa--branch-prefix "elpa/")
(defvar elpaa--release-branch-prefix "elpa-release/")
@@ -2471,7 +2472,7 @@ directory; one of archive, archive-devel."
(html-file (expand-file-name destname html-dir))
(html-xref-file
(expand-file-name destname (file-name-directory html-dir))))
- (elpaa--makeinfo docfile html-file '("--html"))
+ (elpaa--makeinfo docfile html-file (list "--html" (format "--css-ref=%s" elpaa--css-url)))
;; FIXME: Use `push' in Emacs≥28
(plist-put (cdr pkg-spec)
:internal--html-docs
[-- Attachment #3: Type: text/plain, Size: 23 bytes --]
--
Philip Kaludercic
^ permalink raw reply related [relevance 87%]
* Re: Docs on ELPA (was Re: Adding Flycheck to NonGNU ELPA)
@ 2024-02-24 8:04 91% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-02-24 8:04 UTC (permalink / raw)
To: Adam Porter; +Cc: emacs-devel
Adam Porter <adam@alphapapa.net> writes:
>> Something similar I had in mind was a variation on package-install that
>> wouldn't persist the installation, and instead of extracting the files
>> into .../elpa/, would store them in a /tmp/ sub-directory. That would
>> go further than what you are describing, but would make trying out a
>> package easier.
>
> FYI, that exists in the form of the `try' package available on
> MELPA.
I am surprised to hear that someone had to write a package for that,
when the basic functionality can be provided by
--8<---------------cut here---------------start------------->8---
(defun package-install-temporarily (pkg)
(interactive
(progn
(package--archives-initialize)
(list (intern (completing-read "Try: " package-archive-contents)))))
(let ((package-user-dir (make-temp-file "package-tmp" t nil)))
(package-install pkg t)))
--8<---------------cut here---------------end--------------->8---
(and if we extracted the interactive part from package-install, then it
would be even shorter). Another idea would be to provide a generic
temporary package prefix command or minor mode.
> It works well. Maybe it could be added to GNU ELPA. Or maybe
> a `package-try' command could be added to package.el.
That name is a bit short, and it is not clear what is meant. Try to
install a package, try to find a package, etc.
^ permalink raw reply [relevance 91%]
* Re: Docs on ELPA (was Re: Adding Flycheck to NonGNU ELPA)
@ 2024-02-23 16:13 92% ` Philip Kaludercic
0 siblings, 2 replies; 200+ results
From: Philip Kaludercic @ 2024-02-23 16:13 UTC (permalink / raw)
To: Spencer Baugh
Cc: Bozhidar Batsov, Dmitry Gutov, Stefan Monnier, joakim,
Emacs Devel
Spencer Baugh <sbaugh@janestreet.com> writes:
> "Bozhidar Batsov" <bozhidar@batsov.dev> writes:
>> Thanks for the updates!
>>
>> Regarding the docs - I was thinking of converting them to something like AsciiDoc or org-mode, but that'd require me to find a new
>> way to host them as ReadTheDocs supports only RST and Markdown. That's why I've put this item on the backburner for now. I try
>> to find some time to look into the various conversion option (or generating TexInfo from the current docs).
>
> Hm, maybe the web interface for GNU and NonGNU ELPA should support
> hosting web-rendered Texinfo manuals? That would make it easier to
> evaluate packages without installing them, and also solve Flycheck's
> documentation hosting issue.
It does, e.g. Compat directs directly to elpa.gnu.org:
https://elpa.gnu.org/packages/doc/compat/compat.html
> Since this would require ELPA to build the Texinfo manuals,
It just renders them in HTML, I don't know of any .info files being
available outside of the tarballs.
>
> perhaps we
> could also use this to make a package-view-docs command (or something)
> in Emacs which will fetch and view the manual for a package that is not
> yet installed.
Something similar I had in mind was a variation on package-install that
wouldn't persist the installation, and instead of extracting the files
into .../elpa/, would store them in a /tmp/ sub-directory. That would
go further than what you are describing, but would make trying out a
package easier.
^ permalink raw reply [relevance 92%]
* Re: Adding Flycheck to NonGNU ELPA
@ 2024-02-22 16:57 94% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-02-22 16:57 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: Stefan Monnier, joakim, Bozhidar Batsov, Emacs Devel
Dmitry Gutov <dmitry@gutov.dev> writes:
> On 21/02/2024 17:02, Stefan Monnier wrote:
>>> So, unless unless there is a strong objection from one of Emacs's head
>>> maintainers, I think I will commence Flycheck's addition to NonGNU in the
>>> next few days.
>> That would be very welcome, thanks.
>
> All right, I've made the push:
> https://git.savannah.gnu.org/cgit/emacs/nongnu.git/commit/
Here is a more permanent link for posterity:
https://git.savannah.gnu.org/cgit/emacs/nongnu.git/commit/?id=7c06709972291413f18b750248b141293415cd42
>
> It should build sometime within 24 hours.
>
> Bozhidar, see the recipe in the diff, if any exclusions should be
> added, the syntax is there (and also in the file's commentary at the
> top).
Ideally this information shouldn't be tracked in nongnu.git, but in an
.elpaignore file within the repository.
> What could be also added, is a way to build the manual to be included
> with the package. I'm not sure how easy that would be to do, though,
> with your current documentation setup.
It appears they use sphinx, which can generate TeXinfo output[0], though
I personally would recommend looking into translating the documentation
into a more standard format like Org or directly to TeXinfo.
[0] https://www.sphinx-doc.org/en/master/usage/configuration.html#options-for-texinfo-output
^ permalink raw reply [relevance 94%]
* Re: Adding Flycheck to NonGNU ELPA
@ 2024-02-21 18:05 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-02-21 18:05 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: joakim, Bozhidar Batsov, Emacs Devel, Stefan Monnier
Dmitry Gutov <dmitry@gutov.dev> writes:
> On 21/02/2024 19:01, Philip Kaludercic wrote:
>> Dmitry Gutov<dmitry@gutov.dev> writes:
>>
>>> On 20/02/2024 22:04, Dmitry Gutov wrote:
>>>> On 20/02/2024 13:48, Philip Kaludercic wrote:
>>>>
>>>>> If Flycheck were to use the same interface as Flymake, then the
>>>>> situation would be better, as it would only be a different UI with
>>>>> perhaps some other priorities.
>>>> Flycheck uses macros to define checkers and output parsers. Perhaps
>>>> one day those could expand to Flymake's functional interface under
>>>> the covers, but for that to happen, it would help a lot if we were
>>>> more welcoming.
>>> So, unless unless there is a strong objection from one of Emacs's head
>>> maintainers, I think I will commence Flycheck's addition to NonGNU in
>>> the next few days.
>> Before taking this step, can we please discuss the possibility of
>> creating a uniform interface? As mentioned in my previous message,
>> this
>> is the crux of my complaint, and I don't even know what Bozhidar
>> position on the matter is.
>
> We've discussed it. Such possibility exists.
Who is we?
> If we're going to make the implementation of it as a prerequisite for
> merging, however, I imagine that's just not going to
> happen. Flycheck's contributors will go back to their own bubble, and
> we'll stay in ours.
As you might guess, I don't consider this a problem.
> Those are my expectations both from experience, and from the current
> mood of the people involved.
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> Before taking this step, can we please discuss the possibility of
>> creating a uniform interface?
>
> That's orthogonal.
Not if the Flycheck maintainers have no interest, or are even opposed to
it.
^ permalink raw reply [relevance 99%]
* Re: [elpa] externals/auctex f124fe7d28: Release GNU AUCTeX 14.0.3
@ 2024-02-21 17:07 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-02-21 17:07 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Tassilo Horn, emacs-devel
Philip Kaludercic <philipk@posteo.net> writes:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>>> Because back then, `elpa.gnu.org` was not able to generate them.
>>>> Nowadays, we could use
>>>>
>>>> :doc "doc/auctex.texi"
>>>>
>>>> in the spec instead.
>>>
>>> Can :doc be a list? Because there's also preview-latex.texi.
>>
>> Yes.
>>
>>> Does that mean the ELPA devel package could be built from our master
>>> branch always reflecting that and the normal package, too, after version
>>> bumps?
>>
>> Almost.
>>
>>> Well, at least in theory after adding a Version header and somehow
>>> setting the version when generating auctex.el from auctex.el.in?
>>
>> That's right: we still need the `auctex.el` file to be in Git and to
>> contain the `Version:` thingy.
>
> Another idea might be to have a separate :main-file for versioning, if
> there is an advantage in building auctex.el while preparing the package.
Never mind this, I missed Stefan's message.
>>
>> Stefan
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> Well, at least in theory after adding a Version header and somehow
>>> setting the version when generating auctex.el from auctex.el.in?
>>
>> That's right: we still need the `auctex.el` file to be in Git and to
>> contain the `Version:` thingy.
>
> Tho, it could actually be another file (e.g. for Tramp we have
> `:main-file "trampver.el"`).
>
> Stefan
^ permalink raw reply [relevance 99%]
* Re: [elpa] externals/auctex f124fe7d28: Release GNU AUCTeX 14.0.3
@ 2024-02-21 17:02 99% ` Philip Kaludercic
1 sibling, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-02-21 17:02 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Tassilo Horn, emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> Because back then, `elpa.gnu.org` was not able to generate them.
>>> Nowadays, we could use
>>>
>>> :doc "doc/auctex.texi"
>>>
>>> in the spec instead.
>>
>> Can :doc be a list? Because there's also preview-latex.texi.
>
> Yes.
>
>> Does that mean the ELPA devel package could be built from our master
>> branch always reflecting that and the normal package, too, after version
>> bumps?
>
> Almost.
>
>> Well, at least in theory after adding a Version header and somehow
>> setting the version when generating auctex.el from auctex.el.in?
>
> That's right: we still need the `auctex.el` file to be in Git and to
> contain the `Version:` thingy.
Another idea might be to have a separate :main-file for versioning, if
there is an advantage in building auctex.el while preparing the package.
>
> Stefan
^ permalink raw reply [relevance 99%]
* Re: Adding Flycheck to NonGNU ELPA
@ 2024-02-21 17:01 99% ` Philip Kaludercic
1 sibling, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-02-21 17:01 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: joakim, Bozhidar Batsov, Emacs Devel, Stefan Monnier
Dmitry Gutov <dmitry@gutov.dev> writes:
> On 20/02/2024 22:04, Dmitry Gutov wrote:
>> On 20/02/2024 13:48, Philip Kaludercic wrote:
>>
>>> If Flycheck were to use the same interface as Flymake, then the
>>> situation would be better, as it would only be a different UI with
>>> perhaps some other priorities.
>> Flycheck uses macros to define checkers and output parsers. Perhaps
>> one day those could expand to Flymake's functional interface under
>> the covers, but for that to happen, it would help a lot if we were
>> more welcoming.
>
> So, unless unless there is a strong objection from one of Emacs's head
> maintainers, I think I will commence Flycheck's addition to NonGNU in
> the next few days.
Before taking this step, can we please discuss the possibility of
creating a uniform interface? As mentioned in my previous message, this
is the crux of my complaint, and I don't even know what Bozhidar
position on the matter is.
^ permalink raw reply [relevance 99%]
* Re: Adding Flycheck to NonGNU ELPA
@ 2024-02-21 17:00 63% ` Philip Kaludercic
1 sibling, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-02-21 17:00 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: joakim, Bozhidar Batsov, Emacs Devel
Dmitry Gutov <dmitry@gutov.dev> writes:
> On 20/02/2024 13:48, Philip Kaludercic wrote:
>
>> If Flycheck were to use the same interface as Flymake, then the
>> situation would be better, as it would only be a different UI with
>> perhaps some other priorities.
>
> Flycheck uses macros to define checkers and output parsers. Perhaps
> one day those could expand to Flymake's functional interface under the
> covers, but for that to happen, it would help a lot if we were more
> welcoming.
That is what flymake-collection is supposedly working on.
>>> It might be an improvement, but AFAIK Flycheck still has an order of a
>>> magnitude more checkers.
>>>
>>> Offhand,
>>> https://github.com/mohkale/flymake-collection/tree/release/src/checkers
>>> doesn't include anything for Rust or Golang.
>>>
>>> And Flycheck has several for both.
>> This appears to be true, but this is not an inherent advantage, just
>> the
>> fact that people have invested effort into it. It seems to be that a
>> significant reason is that Flycheck has a convenient language for
>> defining checkers, something that IIUC flymake-collection is also
>> working on. Giving this basis, we could look into perhaps even
>> automatically translating the Checker specifications, which would help
>> further "obsolete" Flycheck, given that this is apparently the only real
>> "advantage" it provides (which again, is not architectural, just the
>> accumulated labour over the last decade).
>
> Nobody stops people from working on Flymake, improving the
> documentation and developer experience, and the list of built-in
> checkers.
>
> In fact, I'm pretty sure this will happen faster with healthy
> competition in sight.
No, but effort is wasted on developing incompatible backends. If
Flycheck could take a similar route like Company in recommending to
develop against the default/built-in interface (CAPF and Flymake
respectively), then I really wouldn't mind having a second UI, but
considering the misinformation that Flycheck still promote, I don't see
any interest from their side to converge to a common denominator.
>>>>> It also has a minor mode map, to invoke the errors buffer or jump
>>>>> between the errors. Though the latter is easy-ish to port over.
>>>> I agree, that that is an annoyance. I have personally bound
>>>> `flymake-goto-next-error' and `flymake-goto-prev-error' to M-n and M-p
>>>> respectively, but it would be nice if we could find some keys to bind
>>>> these commands to.
>>>
>>> Same.
>> I'll look into submitting a bug report to propose such a change.
>
> Very good.
>
>> I wouldn't put it that way, but as mentioned above I do think that
>> pushing towards a consistent UI that aligns with Emacs strengths
>> (text-based, buffers in windows, ...) is worth the effort, even if some
>> projects have to change or die in the process. E.g. a positive example:
>> I added support for the "dumb-jump" to use Xref instead of
>> re-implementing the UI with custom commands and popups. People appear
>> to use that now.
>
> Note that when Xref was introduced, there were no existing protocols
> out there, in third-party packages or not, that could be used for the
> same purpose (abstraction over code navigation sources).
True, but that only made it easier. If there had been some MELPA
package called "jumpy" of whatever, then some packages would support
xref, the others "jumpy", others again would have to try and support
both. People would constantly be asking "what is the difference between
xref and jumpy", and others again wouldn't notice xref at all because
they assume that every feature in Emacs has to be installed via some
external package.
This also reminds me of another point: Xref, Flymake, CAPF, ... are all
interfaces, that don't have to bring with them implementations for all
kinds of languages. That is the job of a major mode, and it is a lot
more reasonable for a major mode to implement this interface, if
provided by a core package, than if they had to use an third-party
package that is not even part of GNU ELPA.
> A counter-example is Projectile, which predated project.el, and which
> we included in NonGNU ELPA to no particular detriment.
FWIW I think having "Projectile" is a mistake as well (I didn't want to
voice the position at the time, because people were still belittling
NonGNU ELPA at the time), but at least the effect is not that
significant since it appears that not that many Projectile-based
packages?
>>> Let's remove Helm from NonGNU, then: its UI paradigm is also different
>>> from the core Emacs, and IMHO it's rather ugly. And swiper/ivy from
>>> ELPA, just because.
>> While I am not a fan of Helm, it was initially added to provide
>> popular
>> packages that a number of people appeared to want to use. Luckily these
>> packages fall into the category of providing the front-end of a shared
>> interface (completing-read; and that not without issues, because they
>> tend to abuse completing-read's text expansion idea by focusing on
>> narrowing and selecting).
>
> Yes, Helm provides some support for completing-read, but it also has
> its own specific API which is bigger and more tailored for its UI, and
> is the reason there are Helm-specific plugins.
I know, having this kind of a parallel society of functionality is sad,
but as I said, it is a consequence of the way `completing-read' is used
and misunderstood.
Communicating with the package developers of these selection frameworks
to create a new interface would be an interesting task.
>> And yes, there are packages that have hard
>> dependencies on Helm, but usually when people submit these kinds of
>> packages, we at least mention the idea of trying to generalise them, so
>> that the front- and back-end can be disentangled from one another.
>
> We can both accept Flycheck and suggest the maintainers work toward
> someday having a compatible API, at least on the functional level.
I'd say that should be the sine qua non. If I could decide, Flycheck
should be reduced to a UI, their interface should be deprecated and the
backends translated to Flymake. That would have the best long-term
consequences for users. But adding Flycheck just like that will
certainly just perpetuate the unnecessary schism and confusion.
>> I know that there are differences, and I hope that the situation
>> improves, but to mention another negative that probably disqualifies
>> adding the package just on its own: `lsp-install-server'. The command
>> can download arbitrary executable files as servers and runs them
>> locally.
>
> curl can download arbitrary executable files, and it's still free
> software. The question is which urls are pre-configured.
The objection is not that lsp-mode is not free software, it is that it
doesn't respect their users by downloading arbitrary binaries from the
net and running them on their own machines, even if all the servers were
free (which I don't know, I haven't checked all of them).
> If we come to consider the inclusion of lsp-mode seriously (meaning,
> there would be some interest from the maintainers), I'm happy to
> discuss requesting that whatever proprietary servers are configured in
> (I think there is 1 proprietary option for PHP among the total 4
> available, not sure what else) are split off into separate packages
> that we don't publish.
My impression of the lsp-mode maintainers is that they have no interest
in collaborating with core development.
^ permalink raw reply [relevance 63%]
* Re: [elpa] externals/auctex f124fe7d28: Release GNU AUCTeX 14.0.3
[not found] ` <20240220160445.7C360C00227@vcs2.savannah.gnu.org>
@ 2024-02-20 16:43 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-02-20 16:43 UTC (permalink / raw)
To: emacs-devel; +Cc: Tassilo Horn
Tassilo Horn <tsdh@gnu.org> writes:
> branch: externals/auctex
> commit f124fe7d282e0693ce793a8c8b2a675765df63f3
> Author: Tassilo Horn <tsdh@gnu.org>
> Commit: Tassilo Horn <tsdh@gnu.org>
>
> Release GNU AUCTeX 14.0.3
>
> * GNU AUCTeX Version 14.0.3 released.
> ---
> auctex.el | 2 +-
> auctex.info | 204 ++++++++++++++++++++++++++---------------------------
> preview-latex.info | 80 ++++++++++-----------
Why are the .info files tracked in the repository?
^ permalink raw reply [relevance 99%]
* Re: Adding Flycheck to NonGNU ELPA
@ 2024-02-20 11:48 60% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-02-20 11:48 UTC (permalink / raw)
To: joakim; +Cc: Dmitry Gutov, Bozhidar Batsov, Emacs Devel
joakim@verona.se writes:
[...]
> Maybe having more alternatives in Elpa/Melpa would actually lead to more
> code re-use between the alternatives? That would be nice but I guess
> history indicates otherwise.
I am afraid that this is not the case, instead of leads to more glue
code having to be written. If we want to be more efficient, we should
focus on promoting generic interfaces (Xref, Imenu, Flymake, ...) and
writing back-end implementations. As an added bonus, we improve the
consistency of the user experience.
If Flycheck were to use the same interface as Flymake, then the
situation would be better, as it would only be a different UI with
perhaps some other priorities.
Dmitry Gutov <dmitry@gutov.dev> writes:
> On 19/02/2024 21:52, Philip Kaludercic wrote:
>> Dmitry Gutov <dmitry@gutov.dev> writes:
>>
>>> On 19/02/2024 20:53, Philip Kaludercic wrote:
>>>> To this end, I repeat my question: What_technical functionality_ does
>>>> Flycheck_currently_ provide that Flymake does not? A different way of
>>>> putting it is what architectural advantages does Flycheck exemplify over
>>>> Flymake, that give it an inherent edge? If there aren't too many
>>>> differences, I think the cost of confusion (Flymake and Flycheck are
>>>> names that are easy to confuse) and of inducing choice-fatigue among new
>>>> users is not something we should ignore.
>>>
>>> I'm fairly sure the main answer is "lots of built-in checkers", much
>>> more than flymake still has now.
>> Do you think that adding "flymake-collection" to NonGNU ELPA could
>> help
>> improve the situation sufficiently? See also
>> https://github.com/mohkale/flymake-collection/issues/2.
>
> It might be an improvement, but AFAIK Flycheck still has an order of a
> magnitude more checkers.
>
> Offhand,
> https://github.com/mohkale/flymake-collection/tree/release/src/checkers
> doesn't include anything for Rust or Golang.
>
> And Flycheck has several for both.
This appears to be true, but this is not an inherent advantage, just the
fact that people have invested effort into it. It seems to be that a
significant reason is that Flycheck has a convenient language for
defining checkers, something that IIUC flymake-collection is also
working on. Giving this basis, we could look into perhaps even
automatically translating the Checker specifications, which would help
further "obsolete" Flycheck, given that this is apparently the only real
"advantage" it provides (which again, is not architectural, just the
accumulated labour over the last decade).
>>> It also has a minor mode map, to invoke the errors buffer or jump
>>> between the errors. Though the latter is easy-ish to port over.
>> I agree, that that is an annoyance. I have personally bound
>> `flymake-goto-next-error' and `flymake-goto-prev-error' to M-n and M-p
>> respectively, but it would be nice if we could find some keys to bind
>> these commands to.
>
> Same.
I'll look into submitting a bug report to propose such a change.
>>> On the subject of choice fatigue, would we hesitate to include
>>> lsp-mode in NonGNU ELPA, now that Eglot is in the core? I feel that
>>> would be the wrong move.
>> FWIW I would argue against it. Setting aside issues of
>> dependencies, it
>> is my impression that the "lsp-mode" tries to superficially convert
>> Emacs into some VSCode like experience, introducing a lot of transient
>> information that cannot be operated on normally, popup windows that
>> cannot be selected/persisted/searched or otherwise re-creating UI
>> features that already exist in Emacs.
>
> Are we going to police UIs now?
I wouldn't put it that way, but as mentioned above I do think that
pushing towards a consistent UI that aligns with Emacs strengths
(text-based, buffers in windows, ...) is worth the effort, even if some
projects have to change or die in the process. E.g. a positive example:
I added support for the "dumb-jump" to use Xref instead of
re-implementing the UI with custom commands and popups. People appear
to use that now.
> Let's remove Helm from NonGNU, then: its UI paradigm is also different
> from the core Emacs, and IMHO it's rather ugly. And swiper/ivy from
> ELPA, just because.
While I am not a fan of Helm, it was initially added to provide popular
packages that a number of people appeared to want to use. Luckily these
packages fall into the category of providing the front-end of a shared
interface (completing-read; and that not without issues, because they
tend to abuse completing-read's text expansion idea by focusing on
narrowing and selecting). And yes, there are packages that have hard
dependencies on Helm, but usually when people submit these kinds of
packages, we at least mention the idea of trying to generalise them, so
that the front- and back-end can be disentangled from one another.
> lsp-mode is not just eye candy anyway.
>
> Just as I've discovered last week (I'm not a heavy user of either), it
> has a handy test runner integration and more reliable errors reporting
> (for syntax, etc). And that's with Flymake.
>
> Also, it's average latency for completion was lower in my benchmarking
> not too long ago. Though that's probably the fault of Eglot's
> expensive pretty-printing in logging.
>
> And the popup windows are easily turned off.
I know that there are differences, and I hope that the situation
improves, but to mention another negative that probably disqualifies
adding the package just on its own: `lsp-install-server'. The command
can download arbitrary executable files as servers and runs them
locally. From what I see there is no reference to any software licenses
or where to find the source code. To be fair, this is partially due to
the mentality that Microsoft had when writing VSCode (remember that a
number of the most popular extensions and servers written by Microsoft
are explicitly non-free software that must be used together with the
official signed release of VSCode), which the "lsp-mode" developers
appears to accept uncritically.
^ permalink raw reply [relevance 60%]
* Re: Adding package "Loopy" to Non-GNU Devel?
@ 2024-02-20 8:09 92% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-02-20 8:09 UTC (permalink / raw)
To: Okamsn; +Cc: emacs-devel
Okamsn <okamsn@protonmail.com> writes:
> Hello,
>
> I am the author of the package "loopy", which provides macros similar to
> ~cl-loop~ and Common Lisp's =iterate=. It is located here:
>
> https://github.com/okamsn/loopy
(Obligatory question here, as to why we don't also name the package
iterate?)
> For those not willing to browse GitHub, I have copied the main points
> from the
> README.org file. I have attached the README and the Org documentation file.
>
> Visually, Loopy differs by using parentheses instead of keywords like
> ~cl-loop~.
> For example,
>
> #+begin_src emacs-lisp
> ;; A use of `cl-loop':
> (cl-loop for i from 1 to 10
> if (cl-evenp i) collect i into evens
> else collect i into odds
> end ; This `end' keyword is optional here.
> finally return (list odds evens))
>
> ;; How it could be done using `loopy':
> (loopy (numbers i :from 1 :to 10)
> (if (cl-evenp i)
> (collect evens i)
> (collect odds i))
> (finally-return odds evens))
> #+end_src
>
> Non-visually, these are I think the main improvements:
>
> - Better destructuring than =cl-lib=, in that it can destructure arrays and
> supports destructuring in accumulations (like ~collect~) as well as in
> iteration. I recently added a Pcase pattern for this outside of the
> ~loopy~ macro.
>
> #+begin_src emacs-lisp
> ;; => (8 10 12 14 16 18)
> (loopy (list list-elem '(([1 2 3] [4 5 6])
> ([7 8 9] [10 11 12])))
> (sum ([sum1 sum2 sum3] [sum4 sum5 sum6])
> list-elem)
> (finally-return sum1 sum2 sum3 sum4 sum5 sum6))
> #+end_src
Where is pcase being used here?
>
> - Better control over accumulations, in that one can declare that an
> accumulation is "optimized" (for example, using the ~push~-~nreverse~
> pattern
> instead of the ~append~-~list~ pattern) for named variables, allowing to
> efficiently accumulate for multiple values and to declare beforehand
> whether
> adding to the front or the end of the list should be preferred.
>
> The below expands into two instances of the ~push~-~nreverse~ pattern:
>
> #+begin_src emacs-lisp
> ;; Separate the elements of sub-list:
> ;; => ((1 3) (2 4))
> (loopy (accum-opt elem1 elem2)
> (list i '((1 2) (3 4)))
> (collect (elem1 elem2) i)
> (finally-return elem1 elem2))
> #+end_src
>
>
> - A way to embed the looping constructs in arbitrary code like in Common
> Lisp's
> Iterate:
>
> #+begin_src emacs-lisp
> (require 'loopy-iter)
>
> ;; Things to note:
> ;; => ((-9 -8 -7 -6 -5 -4 -3 -2 -1)
> ;; (0)
> ;; (1 2 3 4 5 6 7 8 9 10 11))
> (loopy-iter (accum-opt positives negatives zeroes)
> (numbering i :from -10 :to 10)
> ;; Normal `let' and `pcase', not Loopy constructs:
> (let ((var (1+ i)))
> (pcase var
> ((pred cl-plusp) (collecting positives var))
> ((pred cl-minusp) (collecting negatives var))
> ((pred zerop) (collecting zeroes var))))
> (finally-return negatives zeroes positives))
> #+end_src
>
>
> - An =at= feature to manipulate containing loops, such as moving to the next
> iteration step or accumulating into a variable:
>
> #+begin_src emacs-lisp
> (loopy outer
> (array i [(1 2) (3 4) (5 6)])
> (loopy (with (sum (apply #'+ i)))
> (list j i)
> (at outer (collect (+ sum j)))))
> #+end_src
>
> - It should be easy to add new looping features. The documentation has
> examples of this.
>
>
> The package and an extension package (to use Dash's destructuring instead of
> that of Loopy, Pcase, or Seq) has been available on MELPA for a few
> years now.
> I am asking about Non-GNU Devel instead of just the normal Non-GNU archive
> because I am still making breaking changes to the package as I reduce
> duplication and improve on the ideas, but those changes are coming less
> frequently now.
If you want to prevent a package from being released, you just need to
make sure keep some negative version suffix like -rc in the version tag.
But in general, I wouldn't advise regarding NonGNU ELPA devel as a
proper package archive for users, but more as a preview for developers
to see how the ELPA build server is processing your package. Or that is
at least my take.
> Is it possible to add this package and the extension package to the archive?
>
> I keep the extension package in the same GitHub repo as the main package for
> testing purposes. The Dash functionality was requested by a user, but
> Dash is
> not used by the rest of the package. Because of that, I put the Dash
> functionality in a small separate package.
You are talking about the loopy-dash.el file in the same branch, right?
If possible, it would be better if you could at least maintain it in a
separate branch.
> Thank you.
^ permalink raw reply [relevance 92%]
* Re: Adding Flycheck to NonGNU ELPA
@ 2024-02-19 19:41 75% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-02-19 19:41 UTC (permalink / raw)
To: Bozhidar Batsov; +Cc: Emacs Devel
"Bozhidar Batsov" <bozhidar@batsov.dev> writes:
>> For the sake of a constructive discussion, please don't make claims like
>> these without any further references. Provocations like these, from
>> anyone, only make discussions like these more difficult.
>
> Oh, damn - I mixed a private thread with Philip and the message I had
> sent here. (I had reached out to him before posting here, as I was
> hoping to avoid a public thread on the topic) :double-facepalm:
> Anyways, that's on me.
No worries. I prefer public conversations anyway, saves me from the
burden of archiving for myself ;)
>> I do not follow MELPA development or statistics, but from what I recall
>> these are just accumulated downloads over all versions, right? If so,
>> then the information we get from this fact is rather low.
>
> Fair enough. Still, you don't get to #4 in the all-time rankings on
> past usage alone. I'm sorry that I can't provide better usage metrics
> to support my case.
I get what you mean, but what is really missing is growth statistics,
specifically w.r.t. new, manual installations. MELPA also inflates for
packages that commit a lot, since they have more "releases", hence more
updates, and hence finally more downloads. We can certainly conclude
that it is a package that people payed attention to, but I just want to
avoid inferring too much from that.
>> Could you explain how this relates to the current state of Flymake
>> vs. Flycheck? The fact that Flymake caught up, and in my eyes
>> deprecated Flycheck, seems like a success story.
>
> I'm afraid I don't have the time to do a detailed research on the
> current state of Flymake. I haven't written the comparison page myself
> and I agree some points there are small/subjective. I'm not sure how
> you came to the conclusion that Flycheck got deprecated, though.
Sorry, "deprecated" should have been in quotes; perhaps "superseded"
would be the more appropriate term. My point is just that there was a
time where Flycheck had advantages, in a certain milieu, but I think
that period is over and that is good.
> Any
> analysis that I would do would be subjective of course, from mine
> perspective and from yours, so I think it wouldn't change anything.
>
> To be clear I don't want to argue which project is better and what are
> the merits of Flycheck over Flymake, if any. If it's so big of a deal
> to have packages that duplicate core functionality in the official
> repos - fine.
I'd qualify this as "duplicate existing functionality provided via ELPA,
without providing a characteristic advantage". The fact that Flymake is
built-in is an important, but secondary point.
>> As you say, people will continue
>> maintaining third-party repositories that accept every brittle little
>> scripts anyone writes (I speak here from experience and personal
>> suffering), but I think it is a feature that ELPA has a more curated
>> policy. I for my really try my best to raise the bar of package
>> submissions, and while it is not always easy, I hope that this helps
>> make the system more robust for everyone.
>
> I get your point about quality, but here we're not talking about some
> random package of questionable provenance. You can inspect the
> codebase yourself if you want, but (subjectively speaking) has fairly
> clean codebase, lots of unit tests, and very detailed
> documentation. (and a sizeable, if hard to measure user-base)
> Flymake's docs
> (https://www.gnu.org/software/emacs/manual/html_node/emacs/Flymake.html)
> are pretty basic compared to Flycheck's so I feel you're applying
> double standards here.
(I really can't write) My above comment was on MELPA in general,
specifically deriving from my first few years of using Emacs before
getting into development (~2014-2020) -- a position I would argue that
most core developers /and/ MELPA contributors have not experienced --
and the issues and misconceptions I had to overcome. While I cannot
recall any specific breakage related to Flycheck, the mentality of
having to install everything from MELPA, without properly studying the
documentation or understanding the potential synergy that Emacs can
provide, did keep me back for a long time, and as I regularly observe,
hinders others from advancing as well. But that is a topic for another
thread, that should probably take place on some other mailing list...
> Anyways, I had a feeling I'd regret asking for the inclusion of Flycheck. I'll take is that my answer is "No".
>
> I really don't want to turn this into some heated debate, so we can just wrap up here.
OK, thank you anyway for the idea.
> On Mon, Feb 19, 2024, at 8:53 PM, Philip Kaludercic wrote:
>> "Bozhidar Batsov" <bozhidar@batsov.dev> writes:
>>
>> > There is a detailed comparison here
>> > https://www.flycheck.org/en/latest/user/flycheck-versus-flymake.html
>>
>> From what I see, this comparison is outdated and somewhat one-sided.
>> Flymake has error explanations, and categories like "Automatic syntax
>> checking" seem disingenuous if the complaint is that there is not a
>> flymake-global-mode. (It would have probably taken less time to write a
>> `define-globalized-minor-mode', than the time to write this point...)
>>
>> > but many of the differences are probably not important to many
>> > people. You might remember that before Flycheck, Flymake was in a
>> > state of disarray and abandoment for years, so I'm pretty sure
>> > Flycheck making it almost obsolete back then was the trigger for some
>> > modernization around Emacs 26.1.
>>
>> Could you explain how this relates to the current state of Flymake
>> vs. Flycheck? The fact that Flymake caught up, and in my eyes
>> deprecated Flycheck, seems like a success story.
>>
>> > And the contributors to Flycheck and
>> > Flymake were always pretty different - part of the reason Sebastien
>> > (the original author of Flycheck) quit Emacs were some attacks he was
>> > getting on emacs-devel.
>>
>> For the sake of a constructive discussion, please don't make claims like
>> these without any further references. Provocations like these, from
>> anyone, only make discussions like these more difficult.
>>
>> > Many people are so off-put by the discourse there, that they want to
>> > have as little as possible with it. And that's the real value of
>> > alternative packages IMO - they allow us to harvest the energy of all
>> > contributors.
>>
>> I don't think this is the problem you are making it out to be, and even
>> if it were, one could have a package like flymake-collection added to
>> NonGNU ELPA.
>>
>> > Btw, flymake-flycheck was created only because Joao wouldn't agree to
>> > provide Flycheck support in Eglot (I know this from the author of
>> > flymake-flycheck). The whole situation with Elgot was a classic
>> > example of the hostility in Emacs towards packages some maintainers
>> > dislike... (https://github.com/joaotavora/eglot/issues/42)
>>
>> I don't know how you infer, but again, it would be nice to keep the
>> discussion here on-topic instead of bringing up old drama between
>> GNU-adjacent/core development and MELPA/GitHub/anti-GNU people.
>>
>> >> but considering that
>> >> more and more people rely on LSP for the information (and Eglot supports
>> >> Flymake OOTB), I don't know how valuable this is.
>> >
>> > Btw, Eglot is not the only LSP client for Emacs. :-) lsp-mode users
>> > flycheck by default for its error diagnostics. I'm not a big LSP user,
>> > though, and often prefer the simplicity of just shelling out to
>> > whatever lint tools I need.
>>
>> The "lsp-mode" is not part of NonGNU ELPA, so I don't think that is a
>> problem in this case.
>>
>> > You probably know that Flycheck is one of the most download packages
>> > on MELPA, so it has plenty of happy users.
>>
>> I do not follow MELPA development or statistics, but from what I recall
>> these are just accumulated downloads over all versions, right? If so,
>> then the information we get from this fact is rather low.
>>
>> (BTW. if we are to implement this feature for ELPA, then we should pay
>> attention to avoid this mistake, and only display the download counts
>> over some fixed time interval, e.g. the information currently available
>> in the access logs.)
>>
>> >
>> > I'm one of them and that's
>> > why I took over the maintenance of the project. I felt that NonGNU
>> > ELPA existed to make it easier for popular stuff to be installed by
>> > users, but it seems to me MELPA won't be going away any time soon.
>>
>> NonGNU ELPA is not only a means of making more useful packages readily
>> available to users OOTB (without having to search online blogs and fora
>> for code snippets that enable third-party archives and install dozens of
>> weirdly named packages replicating built-in functionality), but also a
>> chance to clean up the package landscape, and prune away some
>> experiments from the 2010s. As you say, people will continue
>> maintaining third-party repositories that accept every brittle little
>> scripts anyone writes (I speak here from experience and personal
>> suffering), but I think it is a feature that ELPA has a more curated
>> policy. I for my really try my best to raise the bar of package
>> submissions, and while it is not always easy, I hope that this helps
>> make the system more robust for everyone. So once more, please do not
>> assume malice in these discussions, I don't think anyone here hates one
>> another or intentionally wants to hinder them personally. It takes
>> effort to take others seriously, but it is worth undertaking if we want
>> to make Emacs better.
>>
>> To this end, I repeat my question: What _technical functionality_ does
>> Flycheck _currently_ provide that Flymake does not? A different way of
>> putting it is what architectural advantages does Flycheck exemplify over
>> Flymake, that give it an inherent edge? If there aren't too many
>> differences, I think the cost of confusion (Flymake and Flycheck are
>> names that are easy to confuse) and of inducing choice-fatigue among new
>> users is not something we should ignore.
>>
>> > On Mon, Feb 19, 2024, at 7:44 PM, Philip Kaludercic wrote:
>> >> "Bozhidar Batsov" <bozhidar@batsov.dev> writes:
>> >>
>> >> > Hey everyone,
>> >> >
>> >> > Just wanted to ask if there's any interested in adding Flycheck
>> >> > (https://www.flycheck.org/en/latest/), a popular alternative to
>> >> > Flymake, to NonGNU ELPA?
>> >> >
>> >> > You can find the codebase here https://github.com/flycheck/flycheck
>> >> > There's also some integration with Eglot https://github.com/flycheck/flycheck-eglot
>> >> >
>> >> > I'm not sure what's the stance of adding alternatives to built-in
>> >> > packages in general, but I think providing some alternatives to the
>> >> > end users is not a bad thing overall.
>> >>
>> >> My main question is what advantage Flycheck has over Flymake. I
>> >> understand it has a database of tools built-in, but considering that
>> >> more and more people rely on LSP for the information (and Eglot supports
>> >> Flymake OOTB), I don't know how valuable this is. In addition to that,
>> >> there are projects like
>> >>
>> >> https://github.com/mohkale/flymake-collection
>> >> https://github.com/purcell/flymake-flycheck
>> >>
>> >> that could help bridge the gap.
>> >>
>> >>
>>
>>
^ permalink raw reply [relevance 75%]
* Re: master ddfba511c19 1/3: Check shortdoc keywords and fix one mistake
@ 2024-02-19 19:25 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-02-19 19:25 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel, mattiase
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: Mattias Engdegård <mattiase@acm.org>
>> Date: Mon, 19 Feb 2024 18:59:03 +0000
>>
>> This causes an error while compiling on my end:
>>
>> emacs-lisp/shortdoc.el:138:2: Error: Symbol’s function definition is
>> void: shortdoc--check
>
> How come? the function is defined before it is used.
Apparently because it is being used in a macro.
>> This would fix it, but I don't know the details of what is going on:
>
> Very strange fix, to say the least. We should definitely try
> understanding better what's going on. FTR, if I touch shortdoc.el and
> rebuild Emacs, I see no errors or warnings. As expected.
Apparently this works as well; I had tried to byte-compile the file
manually and I got the same error, so I assumed something more
complicated was happening. So disregard this thread.
^ permalink raw reply [relevance 99%]
* Re: master ddfba511c19 1/3: Check shortdoc keywords and fix one mistake
[not found] ` <20240219171441.76EC3C3421F@vcs2.savannah.gnu.org>
@ 2024-02-19 18:59 82% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-02-19 18:59 UTC (permalink / raw)
To: emacs-devel; +Cc: Mattias Engdegård
[-- Attachment #1: Type: text/plain, Size: 220 bytes --]
This causes an error while compiling on my end:
emacs-lisp/shortdoc.el:138:2: Error: Symbol’s function definition is
void: shortdoc--check
This would fix it, but I don't know the details of what is going on:
[-- Attachment #2: Type: text/plain, Size: 1368 bytes --]
diff --git a/lisp/emacs-lisp/shortdoc.el b/lisp/emacs-lisp/shortdoc.el
index cde28985cd0..7597f601124 100644
--- a/lisp/emacs-lisp/shortdoc.el
+++ b/lisp/emacs-lisp/shortdoc.el
@@ -50,19 +50,19 @@ shortdoc-section
'((t :inherit variable-pitch))
"Face used for a section.")
-;;;###autoload
-(defun shortdoc--check (group functions)
- (let ((keywords '( :no-manual :args :eval :no-eval :no-value :no-eval*
- :result :result-string :eg-result :eg-result-string :doc)))
- (dolist (f functions)
- (when (consp f)
- (dolist (x f)
- (when (and (keywordp x) (not (memq x keywords)))
- (error "Shortdoc %s function `%s': bad keyword `%s'"
- group (car f) x)))))))
-
;;;###autoload
(progn
+ (eval-and-compile
+ (defun shortdoc--check (group functions)
+ (let ((keywords '( :no-manual :args :eval :no-eval :no-value :no-eval*
+ :result :result-string :eg-result :eg-result-string :doc)))
+ (dolist (f functions)
+ (when (consp f)
+ (dolist (x f)
+ (when (and (keywordp x) (not (memq x keywords)))
+ (error "Shortdoc %s function `%s': bad keyword `%s'"
+ group (car f) x))))))))
+
(defvar shortdoc--groups nil)
(defmacro define-short-documentation-group (group &rest functions)
[-- Attachment #3: Type: text/plain, Size: 2204 bytes --]
Mattias Engdegård <mattiase@acm.org> writes:
> branch: master
> commit ddfba511c190e5bb44e44a50aef5ab8c08e3d798
> Author: Mattias Engdegård <mattiase@acm.org>
> Commit: Mattias Engdegård <mattiase@acm.org>
>
> Check shortdoc keywords and fix one mistake
>
> * lisp/emacs-lisp/shortdoc.el (shortdoc--check)
> (define-short-documentation-group): Check that used keywords exist.
> * lisp/emacs-lisp/shortdoc.el (list): Fix a typo.
> ---
> lisp/emacs-lisp/shortdoc.el | 14 +++++++++++++-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/lisp/emacs-lisp/shortdoc.el b/lisp/emacs-lisp/shortdoc.el
> index a6a49c72f74..cde28985cd0 100644
> --- a/lisp/emacs-lisp/shortdoc.el
> +++ b/lisp/emacs-lisp/shortdoc.el
> @@ -50,6 +50,17 @@
> '((t :inherit variable-pitch))
> "Face used for a section.")
>
> +;;;###autoload
> +(defun shortdoc--check (group functions)
> + (let ((keywords '( :no-manual :args :eval :no-eval :no-value :no-eval*
> + :result :result-string :eg-result :eg-result-string :doc)))
> + (dolist (f functions)
> + (when (consp f)
> + (dolist (x f)
> + (when (and (keywordp x) (not (memq x keywords)))
> + (error "Shortdoc %s function `%s': bad keyword `%s'"
> + group (car f) x)))))))
> +
> ;;;###autoload
> (progn
> (defvar shortdoc--groups nil)
> @@ -118,6 +129,7 @@ A FUNC form can have any number of `:no-eval' (or `:no-value'),
> `:no-eval*', `:result', `:result-string', `:eg-result' and
> `:eg-result-string' properties."
> (declare (indent defun))
> + (shortdoc--check group functions)
> `(progn
> (setq shortdoc--groups (delq (assq ',group shortdoc--groups)
> shortdoc--groups))
> @@ -715,7 +727,7 @@ A FUNC form can have any number of `:no-eval' (or `:no-value'),
> :eval (plist-get '(a 1 b 2 c 3) 'b))
> (plist-put
> :no-eval (setq plist (plist-put plist 'd 4))
> - :eq-result (a 1 b 2 c 3 d 4))
> + :eg-result (a 1 b 2 c 3 d 4))
> (plist-member
> :eval (plist-member '(a 1 b 2 c 3) 'b))
> "Data About Lists"
^ permalink raw reply related [relevance 82%]
* Re: Adding Flycheck to NonGNU ELPA
@ 2024-02-19 18:53 58% ` Philip Kaludercic
0 siblings, 2 replies; 200+ results
From: Philip Kaludercic @ 2024-02-19 18:53 UTC (permalink / raw)
To: Bozhidar Batsov; +Cc: Emacs Devel
"Bozhidar Batsov" <bozhidar@batsov.dev> writes:
> There is a detailed comparison here
> https://www.flycheck.org/en/latest/user/flycheck-versus-flymake.html
From what I see, this comparison is outdated and somewhat one-sided.
Flymake has error explanations, and categories like "Automatic syntax
checking" seem disingenuous if the complaint is that there is not a
flymake-global-mode. (It would have probably taken less time to write a
`define-globalized-minor-mode', than the time to write this point...)
> but many of the differences are probably not important to many
> people. You might remember that before Flycheck, Flymake was in a
> state of disarray and abandoment for years, so I'm pretty sure
> Flycheck making it almost obsolete back then was the trigger for some
> modernization around Emacs 26.1.
Could you explain how this relates to the current state of Flymake
vs. Flycheck? The fact that Flymake caught up, and in my eyes
deprecated Flycheck, seems like a success story.
> And the contributors to Flycheck and
> Flymake were always pretty different - part of the reason Sebastien
> (the original author of Flycheck) quit Emacs were some attacks he was
> getting on emacs-devel.
For the sake of a constructive discussion, please don't make claims like
these without any further references. Provocations like these, from
anyone, only make discussions like these more difficult.
> Many people are so off-put by the discourse there, that they want to
> have as little as possible with it. And that's the real value of
> alternative packages IMO - they allow us to harvest the energy of all
> contributors.
I don't think this is the problem you are making it out to be, and even
if it were, one could have a package like flymake-collection added to
NonGNU ELPA.
> Btw, flymake-flycheck was created only because Joao wouldn't agree to
> provide Flycheck support in Eglot (I know this from the author of
> flymake-flycheck). The whole situation with Elgot was a classic
> example of the hostility in Emacs towards packages some maintainers
> dislike... (https://github.com/joaotavora/eglot/issues/42)
I don't know how you infer, but again, it would be nice to keep the
discussion here on-topic instead of bringing up old drama between
GNU-adjacent/core development and MELPA/GitHub/anti-GNU people.
>> but considering that
>> more and more people rely on LSP for the information (and Eglot supports
>> Flymake OOTB), I don't know how valuable this is.
>
> Btw, Eglot is not the only LSP client for Emacs. :-) lsp-mode users
> flycheck by default for its error diagnostics. I'm not a big LSP user,
> though, and often prefer the simplicity of just shelling out to
> whatever lint tools I need.
The "lsp-mode" is not part of NonGNU ELPA, so I don't think that is a
problem in this case.
> You probably know that Flycheck is one of the most download packages
> on MELPA, so it has plenty of happy users.
I do not follow MELPA development or statistics, but from what I recall
these are just accumulated downloads over all versions, right? If so,
then the information we get from this fact is rather low.
(BTW. if we are to implement this feature for ELPA, then we should pay
attention to avoid this mistake, and only display the download counts
over some fixed time interval, e.g. the information currently available
in the access logs.)
>
> I'm one of them and that's
> why I took over the maintenance of the project. I felt that NonGNU
> ELPA existed to make it easier for popular stuff to be installed by
> users, but it seems to me MELPA won't be going away any time soon.
NonGNU ELPA is not only a means of making more useful packages readily
available to users OOTB (without having to search online blogs and fora
for code snippets that enable third-party archives and install dozens of
weirdly named packages replicating built-in functionality), but also a
chance to clean up the package landscape, and prune away some
experiments from the 2010s. As you say, people will continue
maintaining third-party repositories that accept every brittle little
scripts anyone writes (I speak here from experience and personal
suffering), but I think it is a feature that ELPA has a more curated
policy. I for my really try my best to raise the bar of package
submissions, and while it is not always easy, I hope that this helps
make the system more robust for everyone. So once more, please do not
assume malice in these discussions, I don't think anyone here hates one
another or intentionally wants to hinder them personally. It takes
effort to take others seriously, but it is worth undertaking if we want
to make Emacs better.
To this end, I repeat my question: What _technical functionality_ does
Flycheck _currently_ provide that Flymake does not? A different way of
putting it is what architectural advantages does Flycheck exemplify over
Flymake, that give it an inherent edge? If there aren't too many
differences, I think the cost of confusion (Flymake and Flycheck are
names that are easy to confuse) and of inducing choice-fatigue among new
users is not something we should ignore.
> On Mon, Feb 19, 2024, at 7:44 PM, Philip Kaludercic wrote:
>> "Bozhidar Batsov" <bozhidar@batsov.dev> writes:
>>
>> > Hey everyone,
>> >
>> > Just wanted to ask if there's any interested in adding Flycheck
>> > (https://www.flycheck.org/en/latest/), a popular alternative to
>> > Flymake, to NonGNU ELPA?
>> >
>> > You can find the codebase here https://github.com/flycheck/flycheck
>> > There's also some integration with Eglot https://github.com/flycheck/flycheck-eglot
>> >
>> > I'm not sure what's the stance of adding alternatives to built-in
>> > packages in general, but I think providing some alternatives to the
>> > end users is not a bad thing overall.
>>
>> My main question is what advantage Flycheck has over Flymake. I
>> understand it has a database of tools built-in, but considering that
>> more and more people rely on LSP for the information (and Eglot supports
>> Flymake OOTB), I don't know how valuable this is. In addition to that,
>> there are projects like
>>
>> https://github.com/mohkale/flymake-collection
>> https://github.com/purcell/flymake-flycheck
>>
>> that could help bridge the gap.
>>
>>
^ permalink raw reply [relevance 58%]
* Re: Adding Flycheck to NonGNU ELPA
@ 2024-02-19 17:44 98% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-02-19 17:44 UTC (permalink / raw)
To: Bozhidar Batsov; +Cc: Emacs Devel
"Bozhidar Batsov" <bozhidar@batsov.dev> writes:
> Hey everyone,
>
> Just wanted to ask if there's any interested in adding Flycheck
> (https://www.flycheck.org/en/latest/), a popular alternative to
> Flymake, to NonGNU ELPA?
>
> You can find the codebase here https://github.com/flycheck/flycheck
> There's also some integration with Eglot https://github.com/flycheck/flycheck-eglot
>
> I'm not sure what's the stance of adding alternatives to built-in
> packages in general, but I think providing some alternatives to the
> end users is not a bad thing overall.
My main question is what advantage Flycheck has over Flymake. I
understand it has a database of tools built-in, but considering that
more and more people rely on LSP for the information (and Eglot supports
Flymake OOTB), I don't know how valuable this is. In addition to that,
there are projects like
https://github.com/mohkale/flymake-collection
https://github.com/purcell/flymake-flycheck
that could help bridge the gap.
^ permalink raw reply [relevance 98%]
* Re: [Reminder]Decommissoned keyservers
@ 2024-02-17 18:48 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-02-17 18:48 UTC (permalink / raw)
To: Stefan Kangas; +Cc: CHENG Gao via Emacs development discussions., CHENG Gao
Stefan Kangas <stefankangas@gmail.com> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> CHENG Gao via "Emacs development discussions." <emacs-devel@gnu.org>
>> writes:
>>
>>> *On Fri, 17 Nov 2023 21:15:55 +0000
>>> * Also sprach Philip Kaludercic <philipk@posteo.net>:
>>>
>>>> CHENG Gao via "Emacs development discussions." <emacs-devel@gnu.org>
>>>> writes:
>>>>
>>>>> In lisp/epa-ks.el, several keyservers were decommissioned, and guess
>>>>> shoule be removed:
>>>>>
>>>>> keys.gnupg.net
>>>>> pool.sks-keyservers.net
>>>>> zimmermann.mayfirst.org
>>>>
>>>> Do you have any links about this for the first two? zimmermann has a
>>>> notice on the front page, so I guess it can be removed.
>>>
>>> See:
>>>
>>> https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f
>>>
>>> https://unix.stackexchange.com/questions/656205/sks-keyservers-gone-what-to-use-instead
>>
>> So would anyone have an issue with applying this patch:
>
> LGTM. Please install on emacs-29.
OK, done. Thanks for the ack.
>> From cf77b918230b4403b8b5b9579fa97174edaf280c Mon Sep 17 00:00:00 2001
>> From: Philip Kaludercic <philipk@posteo.net>
>> Date: Sun, 11 Feb 2024 18:38:13 +0100
>> Subject: [PATCH] Removed decommissioned PGP keyservers
>>
>> * lisp/epa-ks.el (epa-keyserver): Update the user option type of
>> `epa-keyserver'.
>>
>> See https://mail.gnu.org/archive/html/emacs-devel/2023-11/msg00857.html.
>> ---
>> lisp/epa-ks.el | 3 ---
>> 1 file changed, 3 deletions(-)
>>
>> diff --git a/lisp/epa-ks.el b/lisp/epa-ks.el
>> index c3c11bb0b0b..13840da0bd9 100644
>> --- a/lisp/epa-ks.el
>> +++ b/lisp/epa-ks.el
>> @@ -47,11 +47,8 @@ epa-keyserver
>> (repeat :tag "Random pool"
>> (string :tag "Keyserver address"))
>> (const "keyring.debian.org")
>> - (const "keys.gnupg.net")
>> (const "keyserver.ubuntu.com")
>> (const "pgp.mit.edu")
>> - (const "pool.sks-keyservers.net")
>> - (const "zimmermann.mayfirst.org")
>> (string :tag "Custom keyserver"))
>> :version "28.1")
>>
>> --
>> 2.39.2
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: [Reminder]Decommissoned keyservers
@ 2024-02-11 17:39 88% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-02-11 17:39 UTC (permalink / raw)
To: CHENG Gao via Emacs development discussions.; +Cc: CHENG Gao
[-- Attachment #1: Type: text/plain, Size: 799 bytes --]
CHENG Gao via "Emacs development discussions." <emacs-devel@gnu.org>
writes:
> *On Fri, 17 Nov 2023 21:15:55 +0000
> * Also sprach Philip Kaludercic <philipk@posteo.net>:
>
>> CHENG Gao via "Emacs development discussions." <emacs-devel@gnu.org>
>> writes:
>>
>>> In lisp/epa-ks.el, several keyservers were decommissioned, and guess
>>> shoule be removed:
>>>
>>> keys.gnupg.net
>>> pool.sks-keyservers.net
>>> zimmermann.mayfirst.org
>>
>> Do you have any links about this for the first two? zimmermann has a
>> notice on the front page, so I guess it can be removed.
>
> See:
>
> https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f
>
> https://unix.stackexchange.com/questions/656205/sks-keyservers-gone-what-to-use-instead
So would anyone have an issue with applying this patch:
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Removed-decommissioned-PGP-keyservers.patch --]
[-- Type: text/x-diff, Size: 1060 bytes --]
From cf77b918230b4403b8b5b9579fa97174edaf280c Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Sun, 11 Feb 2024 18:38:13 +0100
Subject: [PATCH] Removed decommissioned PGP keyservers
* lisp/epa-ks.el (epa-keyserver): Update the user option type of
`epa-keyserver'.
See https://mail.gnu.org/archive/html/emacs-devel/2023-11/msg00857.html.
---
lisp/epa-ks.el | 3 ---
1 file changed, 3 deletions(-)
diff --git a/lisp/epa-ks.el b/lisp/epa-ks.el
index c3c11bb0b0b..13840da0bd9 100644
--- a/lisp/epa-ks.el
+++ b/lisp/epa-ks.el
@@ -47,11 +47,8 @@ epa-keyserver
(repeat :tag "Random pool"
(string :tag "Keyserver address"))
(const "keyring.debian.org")
- (const "keys.gnupg.net")
(const "keyserver.ubuntu.com")
(const "pgp.mit.edu")
- (const "pool.sks-keyservers.net")
- (const "zimmermann.mayfirst.org")
(string :tag "Custom keyserver"))
:version "28.1")
--
2.39.2
[-- Attachment #3: Type: text/plain, Size: 23 bytes --]
--
Philip Kaludercic
^ permalink raw reply related [relevance 88%]
* Re: master 7e8b1863af8: Add support for deriving major modes in which-func
[not found] ` <20240210111023.1468FC0EFEF@vcs2.savannah.gnu.org>
@ 2024-02-10 16:36 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-02-10 16:36 UTC (permalink / raw)
To: emacs-devel; +Cc: Damien Cassou
Stefan Kangas <stefankangas@gmail.com> writes:
> branch: master
> commit 7e8b1863af8c820c2969c1a4666ae4451cbcea92
> Author: Damien Cassou <damien@cassou.me>
> Commit: Stefan Kangas <stefankangas@gmail.com>
>
> Add support for deriving major modes in which-func
>
> * lisp/progmodes/which-func.el (which-func-try-to-enable)
> (which-func-ff-hook): Use `derived-mode-p' to check if the current major
> mode is within `which-func-modes' or `which-func-non-auto-modes'.
> (Bug#68981)
> ---
> lisp/progmodes/which-func.el | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/lisp/progmodes/which-func.el b/lisp/progmodes/which-func.el
> index bd68672f905..631cb3b0aef 100644
> --- a/lisp/progmodes/which-func.el
> +++ b/lisp/progmodes/which-func.el
> @@ -211,7 +211,7 @@ non-nil.")
> (when which-function-mode
> (unless (local-variable-p 'which-func-mode)
> (setq which-func-mode (or (eq which-func-modes t)
> - (member major-mode which-func-modes)))
> + (apply #'derived-mode-p which-func-modes)))
Isn't the `apply' here unnecessary, since the argument to
`derived-mode-p' can be a symbol or a list. Invoking the function with
multiple arguments appears to be deprecated anyway.
> (setq which-func--use-mode-line
> (member which-func-display '(mode mode-and-header)))
> (setq which-func--use-header-line
> @@ -239,7 +239,7 @@ It creates the Imenu index for the buffer, if necessary."
>
> (condition-case err
> (if (and which-func-mode
> - (not (member major-mode which-func-non-auto-modes))
> + (not (apply #'derived-mode-p which-func-non-auto-modes))
> (or (null which-func-maxout)
> (< buffer-saved-size which-func-maxout)
> (= which-func-maxout 0)))
>
>
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Request to include a couple of packages in GNU ELPA
@ 2024-02-10 15:49 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-02-10 15:49 UTC (permalink / raw)
To: Rahguzar; +Cc: rms, emacs-devel
Rahguzar <rahguzar@zohomail.eu> 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. ]]]
>>
>> > The service they provide is having indexed a lot of haskell libraries,
>> > more than most people want to have installed on their own machines.
>> > That is why they refer to themselves as a search engine, because they
>> > provide a discovery feature.
>>
>> To use their service as a search engine for other people's code makes
>> some sense, and it's fine.
>>
>> But do they also invite you to send your own private code to be
>> indexed, then subsequently use their server to search for things in
>> your own code? That would be SaaSS!
>
> As far as I know, the service only indexes code available on standard
> haskell repository https://hackage.haskell.org/ and it is not possible
> to use it for private code.
It is, and they document how to do it:
https://raw.githubusercontent.com/ndmitchell/hoogle/master/docs/Install.md
From what I see, it shouldn't be SaaSS, as it can be used offline. As
such it would be nice if a hoogle package for Emacs could support this
mode of operation as well.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: [DISCUSSION] "quick-help" popup for org-columns (column view)
@ 2024-02-10 15:44 93% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-02-10 15:44 UTC (permalink / raw)
To: Ihor Radchenko
Cc: Stefan Kangas, Adam Porter, slawomir.grochowski, eliz,
emacs-devel, emacs-orgmode, hmelman, info, larsi
Ihor Radchenko <yantar92@posteo.net> writes:
> Stefan Kangas <stefankangas@gmail.com> writes:
>
>> Adam Porter <adam@alphapapa.net> writes:
>>
>>> Since transient.el is part of Emacs now, these kinds of menus should
>>> probably be implemented with it.
>>
>> IIUC, this is not a menu, but a reminder of key bindings that are usable
>> in that context. Other keybindings here are self-inserting keys, which
>> are equally useful, and they wouldn't be available in a transient.
The point of quick-help is to provide a persistent buffer with useful
bindings, comparable to what Nano does OOTB.
> I am wondering how quick-help, transient, and which-key (AFAIU, it is to
> be included into the core soon-ish) play together.
>
> transient provides a specific way to define the displayed layout, among
> other things. At the same time, quick-help provides an alternative
> (undocumented) way to define the layout. And which-key uses pre-defined
> layout.
One critical difference between which-key and transient compared to
quick-help, is that the latter has nothing to do with prefix maps, but
(by default) just presents global bindings, and is as such closer to a
curated version of `describe-bindings' (sort of like how `shortdocs' is
a curated version of `apropos-functions').
> I am wondering if transient style to define how various options in the
> menu/help buffer/which-key buffer can be unified.
--
Philip Kaludercic
^ permalink raw reply [relevance 93%]
* Re: [External] : Re: cond* vs pcase
@ 2024-02-08 2:49 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-02-08 2:49 UTC (permalink / raw)
To: Po Lu; +Cc: Alfred M. Szmidt, Arthur Miller, drew.adams, adam, emacs-devel
Po Lu <luangruo@yahoo.com> writes:
> "Alfred M. Szmidt" <ams@gnu.org> writes:
>
>> That would be really nice (and maybe ecase, ccase as someone else
>> noted).
>
> So provided that no serious objections emerge within the next couple of
> days, I will install a change to this effect. Thanks.
Do you plan to move the definitions from cl-lib or provide new
definitions (someone mentioned being able to use equal instead of eq as
an extension)?
^ permalink raw reply [relevance 99%]
* Re: Request to include a couple of packages in GNU ELPA
@ 2024-02-07 8:29 97% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-02-07 8:29 UTC (permalink / raw)
To: Richard Stallman; +Cc: Rahguzar, 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. ]]]
>
> Thanks for explaining. Hoogle sounds like a useful took, for Haskell
> users. What is the license of Hoogle?
Hoogle is a service, the source code behind the service seems to be
published under a BSD-3 license (?)
https://github.com/ndmitchell/hoogle?tab=License-1-ov-file#readme
> > There is web front end available at https://hoogle.haskell.org/ but the
> > package consult-hoogle is for using hoogle installed locally from within
> > Emacs.
>
> Yes, that is the right way to do it. Using someone else's sevrer
> to index code you have on your machine is bad for your freedom --
> see https://gnu.org/philosophy/who-does-that-server-really-serve.html.
> Running Hoogle on your own machine (assuming Hoogle is free software)
> is the way that respects freedom.
The service they provide is having indexed a lot of haskell libraries,
more than most people want to have installed on their own machines.
That is why they refer to themselves as a search engine, because they
provide a discovery feature.
^ permalink raw reply [relevance 97%]
* Re: New package for NonGNU ELPA : totp-auth
@ 2024-02-07 8:23 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-02-07 8:23 UTC (permalink / raw)
To: Richard Stallman; +Cc: Vivek Das Mohapatra, 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. ]]]
>
> This is a useful feature, but should it be implemented as a part of
> Emacs? Is there / should there be a shell command for this?
There seems to be this: https://www.nongnu.org/oath-toolkit/
> Given a shell command for this, do we want it implemented in Emacs
> too?
I don't think that the existence of shell utility is a reason not to
have a feature written for Emacs. Elisp scripts are usually more
portable and certainly more easily hackable than their shell
counterparts.
^ permalink raw reply [relevance 99%]
* Re: cond* vs pcase
@ 2024-02-06 19:39 85% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-02-06 19:39 UTC (permalink / raw)
To: Alfred M. Szmidt; +Cc: arthur.miller, emacs-devel
"Alfred M. Szmidt" <ams@gnu.org> writes:
> > > Because your not doing pattern matching, you're comparing against a
> > > set of strings/symbols/numbers/....
> >
> > Simply because pattern matching is a more powerful generalisation,
> > capable of expressing case-distinction; in the end it compiles down to
> > almost the same code anyway.
> >
> > Are you suggesting that COND/CASE/... and other "trivial" matching
> > constructs should be replaced with PCASE/COND*?
>
> No, just that using pcase in these cases isn't wrong.
>
> Then we disagree on a fundamental level. This is just like like using
> EQUAL when comparing stricly strings is not the right tool for the
> job.
"Alfred M. Szmidt" <ams@gnu.org> writes:
> Also interning strings just for the purpose of comparing them with eq or
> eql is questionable...
>
> So is pattern matching over characters, numbers, and other simple
> types...
In both cases here I think that there is a fundamental distinction
between functionality that is generic at compile-time and at run-time.
While `equal' vs `eq' is not pretty, the main issue for me here is that
you might accidentally compare and equate two string or lists that are
not the same object, which you sometimes don't want to do. Otherwise it
is not really slower than using `eq', if that is what concerns you:
--8<---------------cut here---------------start------------->8---
(benchmark-run 10000000
(eq 'foo 'bar))
;; (2.589085844 0 0.0)
(benchmark-run 10000000
(equal 'foo 'bar))
;; (2.611292045 0 0.0)
--8<---------------cut here---------------end--------------->8---
The pattern matching code is all generated at compile-time, and even
uses the `eq' to compare symbols, instead of the less specific `eql'
(!).
Yes, this might be a fundamental disagreement, but I still don't think
that using more abstract means to solve a problem is inherently wrong.
It might be a personal preference, but nothing we could derive a general
rule from -- which is fine.
^ permalink raw reply [relevance 85%]
* Re: cond* vs pcase
@ 2024-02-06 18:57 94% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-02-06 18:57 UTC (permalink / raw)
To: Alfred M. Szmidt; +Cc: arthur.miller, emacs-devel
"Alfred M. Szmidt" <ams@gnu.org> writes:
> > Because your not doing pattern matching, you're comparing against a
> > set of strings/symbols/numbers/....
>
> Simply because pattern matching is a more powerful generalisation,
> capable of expressing case-distinction; in the end it compiles down to
> almost the same code anyway.
>
> Are you suggesting that COND/CASE/... and other "trivial" matching
> constructs should be replaced with PCASE/COND*?
No, just that using pcase in these cases isn't wrong.
Drew Adams <drew.adams@oracle.com> writes:
>> Simply because [1] pattern matching is a more
>> powerful generalisation, capable of expressing
>> case-distinction; [2] in the end it compiles
>> down to almost the same code anyway.
>
> Wow. Really _not_ a good reason (IMHO).
> Neither of those reasons [1,2] is good.
>
> With that reasoning you'll use `pcase'
> _always and everywhere_ - never `if',
> `cond', `let', `or', `and',...
Please don't be dishonest; My question was why cl-case was more
appropriate than pcase, where both are macros that boil down to simpler
primitives. I don't see an inherent advantage to using the more
specific abstraction over the more generic one. I like pcase, and
prefer using it in my code, but if you've got some code that is already
using a lot of cl-lib and no pcase, then there is no point in transiting
cl-case forms into pcase.
>
> Hey, `pcase' can do it all! And it
> compiles down to almost the same thing!
>
> "Demain on rase gratis !"
^ permalink raw reply [relevance 94%]
* Re: Elpa question: helping with maintainance of a package in Elpa
@ 2024-02-06 17:24 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-02-06 17:24 UTC (permalink / raw)
To: chad; +Cc: Arthur Miller, emacs-devel, Phillip Lord
chad <yandros@gmail.com> writes:
> On Tue, Feb 6, 2024 at 12:02 PM Philip Kaludercic <philipk@posteo.net>
> wrote:
>
>> > Do I understand the information in readme file from Elpa repository
>> correctly: I
>> > don't have to do anything special more than just update Phillips repo
>> for the
>> > package on GH, since the Cron job uses that URL to update the package
>> > automatically if the version is changed? Or do I need to do something
>> more to
>> > get the new version into Elpa too?
>>
>> The cron job will synchronise the mirror with the changes made on the GH
>> repository. Just note that to release a package, you'll have to bump
>> the version tag (any commit changing the line with the version number
>> should do).
>>
>
> Note (mostly for future search results): "version tag" in this context
> means "the line
> in the file that looks something like ";; Version: 0.4", rather than
> anything having to
> do with git tags. (This sometimes confuses people who are/were familiar
> with, for
> example, Melpa Stable.)
Right, my bad, I should have said "Version" header or "Version"
attribute in the package header.
> Hope that helps,
> ~Chad
^ permalink raw reply [relevance 99%]
* Re: Elpa question: helping with maintainance of a package in Elpa
@ 2024-02-06 17:00 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-02-06 17:00 UTC (permalink / raw)
To: Arthur Miller; +Cc: emacs-devel, Phillip Lord
Arthur Miller <arthur.miller@live.com> writes:
> I am helping Phillip to maintain his pabbrev package. He has given me write
> access to his repository on GH, and I was able to update the package with few
> patches It is currently just a "facelift" to skip compiler warnings when
> installing.
>
> Do I understand the information in readme file from Elpa repository correctly: I
> don't have to do anything special more than just update Phillips repo for the
> package on GH, since the Cron job uses that URL to update the package
> automatically if the version is changed? Or do I need to do something more to
> get the new version into Elpa too?
The cron job will synchronise the mirror with the changes made on the GH
repository. Just note that to release a package, you'll have to bump
the version tag (any commit changing the line with the version number
should do).
> Since this is just a minor release; not new features, no changes in usability it
> does not have to have "announcement" on this list, or do you always announce?
No, package updates are usually never announced on emacs-devel.
> Thanks for the help in advance
> Best regards
> /arthur
^ permalink raw reply [relevance 99%]
* Re: cond* vs pcase
@ 2024-02-06 16:50 94% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-02-06 16:50 UTC (permalink / raw)
To: Alfred M. Szmidt; +Cc: arthur.miller, emacs-devel
"Alfred M. Szmidt" <ams@gnu.org> writes:
> "Alfred M. Szmidt" <ams@gnu.org> writes:
>
> > I use pcase often; but I use it just as a better cond. For example I find this
> > handy:
> >
> > (defvar foo nil) <-- foo is some symbol
> >
> > (pcase foo
> > ('bar (do-some-bar-stuff))
> > ('baz (do-some-baz-fluff)))
> >
> > cl-case seems more appropriate here (wish cl-case was just case ...)
>
> Why more appropriate?
>
> Because your not doing pattern matching, you're comparing against a
> set of strings/symbols/numbers/....
Simply because pattern matching is a more powerful generalisation,
capable of expressing case-distinction; in the end it compiles down to
almost the same code anyway.
> I always think of pcase as Elisp's case. In
> addition, pcase avoids the danger of naively writing
>
> (cl-case foo
> ('bar (do-some-bar-stuff))
> ('baz (do-some-baz-fluff)))
>
> and then getting surprised when foo evaluates to `quote'.
>
> Suprises will happy, you will get suprises with pcase and cond* too --
> I find it suprising that to match over symbols requires pattern
> matching. One might also question why you (well, no you specifically)
> are comparing against (quote bar) etc? That is a suprise in it self...
I don't understand your point here. If one expects the cases to be
evaluated, then quoting makes sense if you want to match a symbol. It
is not true, but common enough that the byte compiler emits a warning.
> > or this:
> >
> > (setq foo "some-string")
> >
> > (pcase foo
> > ("foo" (do-foo-case))
> > ("bar" (do-bar-case)))
> >
> > Same here, with (intern foo) ...
>
> Being able to do equal instead of eql is also something that speaks in
> favour of pcase...
>
> It speaks more in favor of having CASE where you can change the
> comparison operator or a CASE-STRING or similar, not something much
> more generic pcase (or even cond*!) -- i.e. why use pcase/cond* when
> you're not using any of the features that are the main point of those
> two macros.
I am sorry, but I don't follow your point here either. Is the general
claim, that one should only use whatever exactly and at most satisfies
the needs at hand?
^ permalink raw reply [relevance 94%]
* Re: New package for NonGNU ELPA : totp-auth
@ 2024-02-06 10:27 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-02-06 10:27 UTC (permalink / raw)
To: Po Lu; +Cc: Vivek Das Mohapatra, emacs-devel
Po Lu <luangruo@yahoo.com> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Error! Result from decryption:
>>
>> Decryption failed
>>
>> Decryption failed
>
> I can't decrypt this email, so would you please resend it _without_
> encryption? Thanks in advance.
Uh, I don't know why this message was encrypted? Thanks for the notice,
I'll try to resend it decrypted.
^ permalink raw reply [relevance 99%]
* Re: [slime/slime] Merge changes from ELPA (PR #809)
[not found] ` <slime/slime/pull/809/c1929127567@github.com>
@ 2024-02-06 10:12 86% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-02-06 10:12 UTC (permalink / raw)
To: Stas Boukarev; +Cc: slime/slime, slime/slime, Author
Stas Boukarev <notifications@github.com> writes:
> How does ELPA work that they a) can put random changes into their git
> b) can't remove them.
ELPA periodically mirrors upstream repositories, but the mirrors can
diverge. This is intentional, as sometimes we would like to make
changes to the upstream, when they are not responsive or the code has
been abandoned. In this case my understanding is that the commit on the
elpa/slime branch was pushed by accident.
I haven't tried it out, but I could imagine that force-pushing to the
branch could be possible, but that would require destructively modifying
the commit history of a public repository/branch, which one would like
to avoid -- hence the suggestion in the other pull request to reconcile
the conflict without making such drastic moves.
> Why should it be recommended to users if it's
> not reliable?
Do you mean ELPA by "it"? I would hesitate to say that this is an
indication of unreliability in general, it is just an issue that needs
resolving. Do you have any technical objections to the changes proposed
here that we could work out?
^ permalink raw reply [relevance 86%]
* Re: nongnu ELPA and slime
@ 2024-02-06 10:07 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-02-06 10:07 UTC (permalink / raw)
To: Colin Baxter; +Cc: Peter Hull, emacs-devel
Colin Baxter <m43cap@yandex.com> writes:
>>>>>> Philip Kaludercic <philipk@posteo.net> writes:
>
> > Peter Hull <peterhull90@gmail.com> writes:
> >> Hi,
> >>
> >> Is this list the correct place to discuss nongnu ELPA?
>
> > Sure.
>
> >> I've come across a problem with the latest (2.29.1) SLIME package
> >> when installed from ELPA. Basically the package appears to
> >> install without problems but none of its functions are registered
> >> so it cannot be activated. There is more discussion on
> >> https://github.com/slime/slime/issues/808
> >>
> >> What I believe is happening is that the slime-2.29.1.tar on ELPA
> >> is being constructed without its hand-written slime-autoloads.el
> >> file. At install time, an autoload file is generated which
> >> doesn't work, because the relevant functions in SLIME are not
> >> marked with autoload cookies. The release tarball on github does
> >> have the autoloads file, as does slime-20240125.1336 from MELPA.
>
> > Do you know why they don't mark their functions with autoload
> > cookies? Writing a manual autoload file is very unusual.
>
> >> Unfortunately I've only ever been a user of emacs packages so I
> >> don't understand how it all works. Is there a way to specify that
> >> the slime-autoloads.el file needs to be included in the package,
> >> or will the relevant bits of SLIME need to be annotated so the
> >> generated file is functional?
>
> > It would be imaginable to configure the ELPA build server to not
> > overwrite the slime-autoloads.el file, but I'd first like to
> > understand why they take this route in the first place.
>
> > FWIW the quick fix for this issue is to add this to your init.el
>
> > (autoload 'slime-mode "slime")
>
> (autoload 'slime-mode "slime") doesn't work for me.
It depends on what you do. In my case I also have a hook configured in
my configuration (the next line in the snippet you quoted), which loads
up slime upon opening a lisp-mode buffer.
>
> I need (require 'slime-autoloads) for slime from the git repository.
The point is that this is not available on NonGNU ELPA, because
elpa-admin.el is regenerating the file.
> Best wishes
^ permalink raw reply [relevance 99%]
* Re: New package for NonGNU ELPA : totp-auth
@ 2024-02-06 10:04 68% ` Philip Kaludercic
1 sibling, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-02-06 10:04 UTC (permalink / raw)
To: Vivek Das Mohapatra; +Cc: emacs-devel
[-- Attachment #1: Type: application/pgp-encrypted, Size: 11 bytes --]
[-- Attachment #2: Type: application/octet-stream, Size: 8673 bytes --]
-----BEGIN PGP MESSAGE-----
hQGMA8l9AV1fe8J4AQwAz/QMs0AwGZjXK465T/saRV5yPkV4DrUkJ2AIaUVHqdH+
sdQgZJQzeh/2YlVtn+KvE1rrnTSbrVsQOUY+NlmtVlHBoECS42Bg37YDuizod22Q
hD+k3oIRep+D68FvOQm6zgoQsVhzJANZ5lk+jV21bS2exyCcUZzxW+3Ga/Pu09zz
gFs5K0ZjBJ6OYdKYQwWWn4IQozR06kuDoTwvqJvz87Hify1To9qaugtQ5yMVsRXk
hBupIGiCsR2UFVUS16Caxz7du3CehtPYMFG3R2TppJITl8Fua+fSSvq/DEjs0aLL
zNYuKO3F4VwGGx7UasOD5oVCk/R65Jh7Omp+HcN/EtJGAZ9hHBWrFDocNTf3MFXw
rhGccoW2Uqsav0/IrdL8wB0OQSroiZCV3E21FmJ2439uwvW6oRF0LSYUl1bO0yuI
I/JOFH8240c/gln96Z/D/E66mcQ7xOPUz9VDgIUq+ImaYBcks1Yc3Es1Vk3Qzwtw
GSJD7ny2HacdziQW2vW60uwBwTUe7S/vYIcCpjSLbgHdDgTt++2SrXqPHrLoH8ON
qDliOiVjHUFIfo2l5a7dTOSW+DaB3FFjUHQB3dS7bPlRJXxRnagniqTSCEfPUzTS
QjwwlTBoXRauiXLgEGbz6OPvaQ9d69GySV8xVykomkDDBL3sd2YX+ZVAKOvlkiT9
D6RREOS/L2xGLWg6trVQ4fc1Sd7P1y93SiahNkLzDgomIm3qn8kNFXN1pSmdEBth
/ov8g7T+drToTrbCc+FRlKZIPonAjfFuTV0ucfovtbMxfBdeLwMwLKCBKUa/FQiu
MzLp9FtNtkZi5bfiQ1ZozQgu4YqLHT6S1UapspK9/mBKewyUaw17imOoEc/O54iu
1kGrUwShhILjePkvGTfUsUsRozx1Joj82zAbBkjA4Quy9zAw/gQyohSU8v9xexKd
uxAZTJuqtr16EfLslN+Rp/nkTmXo3afaZK8Tul9vyw0V07hGNWnaDMJQZR5q1dFg
2qRc/4bJKrUDZv/zl9PMW0cEdhMJOO8Hvg2DZNzytaDnEdcIGLUEfZEMGqjlV5Kk
0hRxZXM2o8vTfvG+9x0ZofAMTgOISLvvZr1yx+aN1Q59oY7FqVHrDF0iybkU6Dlc
YUlZNDuysh2IIBO46WqWqxtijVedvytKS10GeFGrtJM2yNgtULpb3fNfpt8VubZL
Mt6r/Nd+6HHtBZpasCjijCoCWPUFut4glprs65M1HJyp66GTKwWOlA64N8rhHPWT
Ytvb2flXoFQdh7UFjYuMTi03iizmzU/lXNmGDthzxCCZrm3uB1sKe1DIDhL05Llh
EmiBPMlyM/xUf+stNXADWfQisG8KVQz3O71pnojLbRkRVN9lK8m4gCbeDfsBxg1R
YaFWVD2ipqK+ldNR99+KSSsYhpeObSAPaoPqKazcm7qhmqymyPqNG8unPbDfrgft
OOJ7MnOc4ZkQqmqRN/SqgxN6QMBIv2795ee+SzBeO0DvHBd4U0ozAeW5MXD/2zWu
GgWxaNUECZKsWtLFEcix8VWu4S0vWIv4KB3kTn/FyWiJAPZzgGHFOUMp5IrWD7E3
G5IMiezLv805omSaCUAnEAwcGeZKPJ+xGFXz7SuQ0zwq990/w/UZqPxj6Jor/UhJ
BwqDI2wJQZQuD7tTq5PfwlEtdUeX426bxcn828PAbGNteC+vMG1Dlgq2T7294oqH
DShxh/EFdB6vybmczykUVqepNf0nQgaxpv3hrrOhYdEOD7cVLMaI7GX8Lcw97mEA
VAvGAbDPIFre35eAXLuVVtn6WEtmuUInilRd7ftm90SuBZraTc1mdJVPYDsAs/bF
vygnyk9Xb9rqiOGo0JZZydn8B7cscodT2uVWqIIMdrBhld17rD/y+pF/Dfjly3NF
XfBH25VzSQuezbBow8SfwiwvNr9DG9pCrE8jmrWgfjXeb7L+pZV5ln2UxbAEqx7k
8aLfL1DL0YZ93S1yZc2RlBMKv7qSrTIzIFj9g86gWUy6/jUJ5On9lul+Xe05GNt7
7uJIwr9yIWYEVw3r4zv7xBTDqkoDK7zbRPmNUg/8EXahaDEiE5NrQxSnUtD5szO+
d2dPmKqIzPkQLyVcHb7/RlLAXQiHvWBy/dVEexjXC+ebHBcVekBSBIYuaC8zkPc8
9vPKyIMFjwMU7qgDTAWUlfWYqx/v27I6J9Ca+CMpLIb1mXKSlhuIeZ0e8rYTMXIC
1t+uIy+Z1sAq8OGd6XjxIzzvqNcZPSinKDUI/kVD9VFUn+YBn/8YzmuSkzpM3D29
o0QTm9OOSsNmcehmILrN2zE13Vb9AAAB6NLPn0/kOSFMAWN8nCTdJ8pr/9rGNLp+
o99NHbss4a1UNPl/2oMEUjXF42MyP/iSkroEDgHC101f7ySL7fwpB4HPnLvejdr1
2WN5pfr9Ul2q57/y6qf2egpkzNJX0zG+sgRNvlcVfQ4+mY0ZGNW8nXeWGGo6kRtu
KDB5ZHVqpElVQ/6qmp07becEigrnJ+Ho3/nwc9K4sWDlvHe5UcZA4VPMto4PDeUG
xVcwW3vkgk4oUVxxqlj86PGJATEBAT2ll2UovCZFsN0fAS2wH3vlGr+D0NEZD1IN
vZOWhTzyNxd4hbAjtPEAtSS00aubnFoNkRmMprFosudBkrPcr3qyRzgqSUCIVcaD
mD5szJ/eO1tTJNJooEoj/N/p8/DLJVPMvKO+6OIthpPw2RBy8SUUlmsEfzDVBU4/
e9AXsOOPeoGKPIK7pVKqyfIz1qosWPpy3rEt84oO9ihySOLkthXvnhCRS/ajw/eS
Q/gTm4SWr5Dz0JEFDYXIvQ7Fnx65lam1zuDw5gDgejoFmUhrB7MncuklXT8laBw1
bTCVqNw+X+MPiGrNUL4xeoYlUjpF5/THQ63GJfDe4dT7HXlOjs7iScjo2yXoOckb
lvPE6jGDdIG6oMc8SjePVQsyH2QdHf6VC9u5xpxCEarg5UtLyjE+lYwneMq3PC9S
93ouyyegjBIkAkoA3mnS+0j3tiqJWV7//n2I7Dr6xo2MeHUwm4tnmjdo/dvLyUvp
ZGBK4VFn96z5HjrWpMScFW/fyaYZIIh9Cq6C7oYMH2apxcXaOcb0Dj6fTlMWG+pw
+oJD0TUyEWZ4CgvSZpLoQiZGVmtH477C1kzvuxK92gHbCNZgF04TvxlQMfvNocwc
DM5l7PFgiEh4IlCfpwnhiK2iU71t/YKy9t9TZFxKWkinKSr2s4RofETPxulwfPGW
44m/H99bJ6hIvcXIxQFaOCE3PipaZLYR16iUMrFGx4+MM9WiRnTorgVsEflD7usS
5u1BUEheQ6aK247YwCvi0P/OpjBO7Fj9ywfQFDzeaLiikFCoVAmpXlti/UH3tnNG
iNI2FAZoiC9Fr+MOU+mtUeRciHN9h3h7sCzySyTd47+ldBgOPCtbyB/bDaGnHirf
dJRwXtD0mS3ga4q3uXd/eAQ4hlsWPa1iz70RJhStFaMJ2crC9kxcsbtDLal16+/t
j+HwichgtA0LGXoeRSh6dgtF9XM5Q2WV8zCsYVND295TsDn/ACO5Lc1m0yHR/dn0
JoRf79m6Kt2w+N4QhC9FXTqmRd3w51UEBPLG777EoxtacK5nNrVK505pvCbS5ZTO
mYMIlOcyUM15CQUpcgfDX4XBJSwKhL3hu/pIQ8M5obYxCFmcd7KBRxQYZn0yDujJ
8lloiauSNDHcgFeUHo6d9V6NebEAL8a5554P1UOPQNG4LTjmkhaUeO5AwkzIEBEt
rnRkaxsqwKSgzryI1R9foBxFZfVTJT1yoCm2qXGoqcqc+OoLPx/2wuTtuL0UvAMa
2t1s28Wz9EEvNFW2WGnvqYJkEDlWCGhkCQL7KrwN/5zIgeZ/xLEHPO5sYDpv1oco
x7dKBnVoXB6JvujP40zd7EDiDKz0y6SAGzXD/nmA+PiI6c6I613TC8rZAMG9Ki+W
kPdmX+NZ4PX/hRIYTPC9ruHNRx35cGZVUwVqIl9sYop0Y9dD+USuLDF0OMIKbIFx
DPKbh3YCEvu5Xp/QdXlQ1Y5A4tKLWPcZmZ8Ge6qt4ueajLa+ra2OFvTX64AYcQdt
z9NNU/IfqKpN0baitP4jHCIl63pCig8ogWPyh7UuUcjyhyHWoKxRkAWkMWpc1spE
AdtG/sgeEVQlvMMwkDrbew6OB8jmSGHi/4oyLKjiBY2ulM0Pl4A6x1dLWItuRbHm
v+eQEx+pE2iXg0CMyhEKfzr4Mfdw4gaL2MXQsVbF4HfQO/A+K1Nrl5Syx4RAQPND
Gjp+RwUYW9WxVirWHDz5gyn8eE20SnlJYB5ao0t5OQDyXQetMeOeU/6XR0eOUCRV
eCpxuDwcWV4oQkIn53hinh1ZT2c/l80vHFm+nI73zHraXws+kjsIUxHuy4h1gQYW
vLLGurvwn4rUuTW5IhWz+T/SPywFExas/b27Z62WXtHkxqNiUGGQfdjwvQWXEh9M
S6f49EvDqGV10tG65a3SJlBanFq1cfnj0B0m2vGfcN6k1FH60S80gwkjCdH405/8
UAItxjIBW3Q4BDfoHm3gAjUoYRfkn3xTE3zUYqgG565Q5N3CDSP7eEqiHU9DvyRf
GXUAS7cLGtWylmqzIz/Sq8Z2xJT/ZnzwwLZwXj0cwgFHBwYvl6mZ/q/lG9DKb5ju
rAQsiUUwhpi5zar3I09+XJ+bivDNG/lncYfx8LcpnZ6ZTCCzx381WH2nxRp2Ez4Z
u0SqAd2d/6jrcD6T1oIb0aFvBF8jxfoA75dz5qPVN4AH7H7+Ckta6K7Tf6XZcpcu
W4V4tzBN/vxB4lhxm4EVP1BbbL4i8JiW7J1af9A6JHaa4uTsvqfGsGOeuFMsOEvT
qLoBUIX+KtP8qM41qc20EaBIotCmX8hyCCZXnrdhFxygHMaUgvkZyp+J2Q/neGSH
U4u+lSWab7t1r6/INaHMEiy/986mOOLDk6arxp+y9gJf0yoZmdLY/94+haPJV95J
116vdflItNjLHl1+93smGzE7qOngtG1FqgM48w/e+311NDe1997W0T/lmKmOAzOy
XQuC0qwGHi3eTNWUQzkHj/m9yRp6rHPw5E6Iqrscf0fKIX0Bt0cO3KPwqrS66m2L
OkHnBpG19Wti5DXIQJ1B1ADfYkO7L2CB//iA3oquTOV0wkwcmHBZmTH9h7rVa3YB
+BrkcqaHcc3Iht/m/+Y6yCwBSKGBNMHKSYlpDOl7Z9SkyI22Knxh7Qm541W5wwrM
TUtylORjctUCpGG6BMYmO5MgrHxpYgohRo5ypLHzWWombMYQxWtTLiUbZuRf0+Nz
W26m+0JReF3vILkYyRP5N1oKVAm9uQNA2cvHXpf6WAF/inJ5WtNAmGxIr9n46ruc
P5ksUWt3MvVsXNFANpo9SDpAN1+DWQ+WeCpScM8OigKMYZUnikrArjgZGfHzGYPk
SxzR6fA+ams0XFeEycAWP6ITe9Ov3H6bzpFwx1aMx3+L3s5+2xVgYZb92zUGCH0U
wAqP46btS7LGvsrlUUNMXi8MQE0CCim/eHraG0F4Xy0kiEF+ie6hKmqPGyOLZodM
m1udwAPQpsVUfVcUv6Bfavww8EbbQRI8NR2R5qECLbXLQ822xfpr9LTxfxwQdRY7
xHQznZeZWdtqdIDXN6hfBdqaVLkm5qlyUy884JQZ6Psogs9FcA6lM2KgDcJDG9t0
6qgfEKTAyvLN3Uy62uN9EzbFGq93JI/0RCBSiyQTwtzkhUrSJMZGSYT5qdIjct0A
wLJN9k1od1aVksgreHi7XF1Ug8YwRSsB0xQIGZ5VH3YqzuRVlHqtDkV7q434/htr
dBiaEUpGsanHzak9YzYevXFcuYabNXEywwDRF6s+vAI3xx8eSkbwYVS31aIcrkhG
Ya/SunxRNCXPzNDKEyQ/tzdPMzXtvjHc46hqMAeIApb113S0bRz8e6ME6KOeoXmK
ZHiu5X1u2aHLuYIN/HVkQwRhRoBPe1K9cvCBz2ibWyO06iRBrC98KuZKvDNugIkr
TMEmuLujzNEAlL8mZ+0cY0kJBCQ6eLXTTcilC5zKiBiVcjtpJZQtev7xbK3Zc+n6
n1HkA4KNMPQuQCmm5Qe5pIPYd36RY3zAycZs0zZS5Mn0Gi127mhyF2/VV85sQ80s
mJSNnntvqHrYT2SYK83UL6D1L4gP+7lRDaqqWp24nbOHfcf9cPo9Jjbcnvf8tf4A
BRY2CJwy4bbv8/eFg4elSFfRVSebgApl+aezZv/+CSiOLXKET5lA5tLbuQMugUt8
mCBlq6f1/Nt58CCg6XxnwhpM9kGa+1LPAdhReRc9ZGGmnYa4fjPz0zpNYok/Aq06
zeGSXijv/dqw7v/21vqBMzjv6sn8Ykj8bKHPgCzCLJH38vtOyWtthmGJxX93HuIQ
hWTwZ/6/EFvjRLqmAwA7cpEaxif07LxukFcrX6eHtjNH0SW/ciOKhxBLB5cs0y2s
B1l7gLrzeoKdvwu36geRKiOe+bwm4ZAq/GnsZuz1xB7B9RMcSBuM6ArhmcMB/MLw
yj6GlrWyyLllMFOrEkoY791zsDO64fn4KcqrpApie25kLtPfW+KJ2rn+jKkzePlZ
aPc6Kw5uzEixWuPeKTcB2bRCQvGSQD/JLgs+QgBTvYHaULUJv4octG8su/I8Agxg
do0+PDs8v7h6xiQp7a7S0edgtfMyKrVCmJoYnjlIJsDe016ezUbl8OyYNSJ6p3r2
Pd0VakKdPQxTdBQivuxWjmPDoHWfd7aLqTb0AX8KPDIImxTA5ITyTXzRXpsBm5g1
W2qqTFgb9G0eDlJcP3Vt6TSmkLfHnAYp3tBCmybL6wgQtITcuBpklx2bm0mIWiC2
RVL3VW4zXoIrVPBa1Z9RoSLWpnb61WpZHgth5dggWlJ5BPYT+NNEs4lAysJj25Wb
yu1rGGTJOp0ft4Q/MGaj2Q2Get/knaJinjvtfyPj2gyp20YBU4IXr8XdUasPoFuQ
+VrBT7d+fVPN3rK/gsAI5d+d332ZzW4SXi2vzbKDATzW5mjsyGDhcu20qFicxDq2
FWhsP865VMp9S9dVbnENAp/BW2xrzBQg0BtfQ+HuSr1TYVd/DYlhIOOw3DTugCZv
XqIbd+IE/DA9ZfjYz7XyvZe7wRXzliC/qJgnCURa2aozH2xzqG+mj1M6HjfUd4cc
dPHLcZFDU5S/Bqnq1CVwpnhzFJkdHaO5SF8Dfg6sKCXDFuCXspV4vNEfGB2IHdda
HIQTQpK6nYdI8oq+g9SVnq5DgAPlEbC57Tf/d1Ge4ugzCU8QWLZXEVayZ4VVfTne
gFyEeU2yvF4aN0wiVh5hFOFhJn20qtUcAfcLuSPyPE7WvldFSkDQQI0s7BE354W7
eODprXpqJOozeWxg7uFH2SSXf+ZnO1NhdxdSpzbJe+esGenYdZH0tbxJdQlvG4D0
Xfpp37ml6x4l92IeOCQlGn2rWseH+gH8WpuynyEu0WII9+K8UzKoB45g/3uIn0cP
NWnycvLX/rNfVWlE1OX0vI7bio3jKI7WqTFDqnYAsRf/B5+lnKWYuGK6F0PT4kcu
3hqLswDqy3YvJ7G/Zudv9RZvOg7Xldr5aFmx8Uwdwj1JtoWXMwfQqx8K/ELqOhLk
dWaD7NGIR0eGRpOu/aWPS9ci6rd1Rp488ygLJYJtX+m2nq6QtbGgrl5ExAwCiICy
gsqpXnlGpxtwTeQWFFM8hafktls2YCJQXzR9bCHWWxBYqH8Dvpq4VtDC1CgweZvr
QLO7ggFKYCAPwJ1oNCwRUD22oI2pY5D8TKAaot/kdppkklWjmR/3V2+XfYryw7lt
vMWKK0IzKmfCPL0yfWvW+uRPWdhQ/ZwFIpwT80EF/sBm3OsFnH0jUhEsjQCB2thX
scl/XgbHC+mlC1SobZx3X7gOiVfTESQytX8pZ4BNRN+qfkxm1mChV9R8AzqZDzYC
5iv4RW479fTNrrTR3StjULtzUevcw6xVX7d/c8ZtcfPBfBhNv+oO6C2jVKDcQZjY
1EhJLPkNQf+2w+LM0cYeyAjddidqvffXuT7A+pfHTvfBeKTAgTrAgOoqS+CgcFQo
wWPvi6l7ricXE+9Z6LxzfFLZ0alGIPpEZf1dY71y7CZL8thM0fblvt/zfilWgil4
epBms6zwHLRTnEeFNuaCQ2bBwxkIEEa6velGopyT+7eMFWrBibE06NisVL6pCqbT
lsvKx9bunCReMeSe/snD2Kmo0pIfXPaCnCoFNzz1gTbdnfOycjFDb2aQLYNHvtNX
YYUwXf0a4uAnXJ/1+IWcpL+8KCc5ujSl65cd75xp5uescCpNvgJR9gtOnlDfybG5
lf7acloW7mFzlFZQQTIODouh1L3aXukgL9gDiGHVqWxRuJkjArPalSlRmAnjgF7Y
ccrex7lBVvHsIGuaS5vKphUiZTCBk1V+ZsbmyjAyQq0xAMGBBM2DgYQCIzan++SG
P5HRSQMs/LJIX+lQVU5fvsBc7e702g==
=v43Z
-----END PGP MESSAGE-----
^ permalink raw reply [relevance 68%]
* Re: Proposing new function for basic editing
@ 2024-02-06 8:14 98% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-02-06 8:14 UTC (permalink / raw)
To: Pedro Andres Aranda Gutierrez; +Cc: emacs-devel
Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:
> Hi,
> I really don't know if this is useful for more people or it's just me. In
> the elisp I write, I have ended up more than once wrapping the point or the
> active region with two strings.
There are certainly some cases where less generic code like this was
written, e.g. in rcirc we have `rcirc-format'.
> I normally use a yasnippet for this, so I really don't use elisp ;-)
>
> But when I need this for a package, I end up replicating the following
> function where I need it:
>
> --- cut here ---
> (defun surround-region-or-point (before after &optional put-after)
> "Insert `before' before mark or region,
> `after' after mark or region and
> put mark after `after' if `put-after' is not nil"
> (if (use-region-p)
> (with-restriction (region-beginning) (region-end)
> ;; Insert `before' before region
> (goto-char (point-min))
> (insert before)
> (goto-char (point-max))
> ;; Insert `after' after region
> (if put-after
> (insert after) ; put point after inserted string
> (save-excursion (insert after)))) ; put point after region
Can't you pull this code out of the if
> (progn
... and then drop the progn?
> (insert before)
> (if put-after
> (insert after) ; put point after both strings
> (save-excursion (insert after)))))) ; put point between strings
> --- cut here ---
Also interesting, if you want to be generic, why not use an approach
like `isearch-forward-thing-at-point' and allow wrapping anything that
defines `bounds-of-thing-at-point'?
> I was wondering if it would make sense to have this in the emacs lisp
> library once and for good.
>
> Best, /PA
^ permalink raw reply [relevance 98%]
* Re: nongnu ELPA and slime
@ 2024-02-06 8:10 97% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-02-06 8:10 UTC (permalink / raw)
To: Peter Hull; +Cc: emacs-devel
Peter Hull <peterhull90@gmail.com> writes:
> Hi,
>
> Is this list the correct place to discuss nongnu ELPA?
Sure.
> I've come across a problem with the latest (2.29.1) SLIME package when
> installed from ELPA. Basically the package appears to install without
> problems but none of its functions are registered so it cannot be
> activated. There is more discussion on
> https://github.com/slime/slime/issues/808
>
> What I believe is happening is that the slime-2.29.1.tar on ELPA is
> being constructed without its hand-written slime-autoloads.el file. At
> install time, an autoload file is generated which doesn't work,
> because the relevant functions in SLIME are not marked with autoload
> cookies. The release tarball on github does have the autoloads file,
> as does slime-20240125.1336 from MELPA.
Do you know why they don't mark their functions with autoload cookies?
Writing a manual autoload file is very unusual.
> Unfortunately I've only ever been a user of emacs packages so I don't
> understand how it all works. Is there a way to specify that the
> slime-autoloads.el file needs to be included in the package, or will
> the relevant bits of SLIME need to be annotated so the generated file
> is functional?
It would be imaginable to configure the ELPA build server to not
overwrite the slime-autoloads.el file, but I'd first like to understand
why they take this route in the first place.
FWIW the quick fix for this issue is to add this to your init.el
(autoload 'slime-mode "slime")
(add-hook 'lisp-mode-hook 'slime-mode)
> Thanks for your help,
>
> Peter
^ permalink raw reply [relevance 97%]
* Re: discoverability, better defaults and which-key in Emacs
@ 2024-02-05 18:47 97% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-02-05 18:47 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: Po Lu, Jeremy Bryant, justin, Emacs Devel
Dmitry Gutov <dmitry@gutov.dev> writes:
> On 05/02/2024 09:11, Philip Kaludercic wrote:
>> Dmitry Gutov <dmitry@gutov.dev> writes:
>>
>>> On 03/02/2024 15:40, Philip Kaludercic wrote:
>>>> Po Lu<luangruo@yahoo.com> writes:
>>>>
>>>>> Jeremy Bryant<jb@jeremybryant.net> writes:
>>>>>
>>>>>> Here is a suggestion - include which-key in core and potentially enable
>>>>>> by for new users.
>>>>>>
>>>>>> I understand it is in ELPA already.
>>>>>>
>>>>>> Author Justin has expressed openness to the idea in
>>>>>> https://github.com/justbur/emacs-which-key/issues/355
>>>>> I don't think enabling it by default is all that desirable, since its
>>>>> popups are far more intrusive than keystrokes are when echoed, but
>>>>> moving it to core is a decent idea.
>>>> I second this concern, it also promotes the inefficient practice of
>>>> inspecting keymaps by waiting for the idle timer to be triggered.
>>>
>>> What if instead of having the help on a timer, the timer would add a
>>> small hint in the echo about how to invoke help (i.e. press C-h)?
>> I think that would be a significant improvement if it is to be
>> enabled
>> by default. I don't have an issue with the presentation (though the
>> transient buffer is my preferred UX).
>
> Is "transient buffer" the same as what which-key uses? I think the
> 'transient' package uses similar display.
I don't know, what I meant with transient buffer is that it isn't
persistent, as is the case with C-h C-h where a new window pops up that
is no different than any other window and behaves consistently.
Transient buffers, in my experience, usually gobble up all key-presses
and re-implement their own "MVC" that can differ in subtle points.
^ permalink raw reply [relevance 97%]
* Re: cond* vs pcase
@ 2024-02-05 18:39 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-02-05 18:39 UTC (permalink / raw)
To: Alfred M. Szmidt; +Cc: Arthur Miller, emacs-devel
"Alfred M. Szmidt" <ams@gnu.org> writes:
> I use pcase often; but I use it just as a better cond. For example I find this
> handy:
>
> (defvar foo nil) <-- foo is some symbol
>
> (pcase foo
> ('bar (do-some-bar-stuff))
> ('baz (do-some-baz-fluff)))
>
> cl-case seems more appropriate here (wish cl-case was just case ...)
Why more appropriate? I always think of pcase as Elisp's case. In
addition, pcase avoids the danger of naively writing
(cl-case foo
('bar (do-some-bar-stuff))
('baz (do-some-baz-fluff)))
and then getting surprised when foo evaluates to `quote'.
> or this:
>
> (setq foo "some-string")
>
> (pcase foo
> ("foo" (do-foo-case))
> ("bar" (do-bar-case)))
>
> Same here, with (intern foo) ...
Being able to do equal instead of eql is also something that speaks in
favour of pcase...
^ permalink raw reply [relevance 99%]
* Re: discoverability, better defaults and which-key in Emacs
@ 2024-02-05 7:11 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-02-05 7:11 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: Po Lu, Jeremy Bryant, justin, Emacs Devel
Dmitry Gutov <dmitry@gutov.dev> writes:
> On 03/02/2024 15:40, Philip Kaludercic wrote:
>> Po Lu<luangruo@yahoo.com> writes:
>>
>>> Jeremy Bryant<jb@jeremybryant.net> writes:
>>>
>>>> Here is a suggestion - include which-key in core and potentially enable
>>>> by for new users.
>>>>
>>>> I understand it is in ELPA already.
>>>>
>>>> Author Justin has expressed openness to the idea in
>>>> https://github.com/justbur/emacs-which-key/issues/355
>>> I don't think enabling it by default is all that desirable, since its
>>> popups are far more intrusive than keystrokes are when echoed, but
>>> moving it to core is a decent idea.
>> I second this concern, it also promotes the inefficient practice of
>> inspecting keymaps by waiting for the idle timer to be triggered.
>
> What if instead of having the help on a timer, the timer would add a
> small hint in the echo about how to invoke help (i.e. press C-h)?
I think that would be a significant improvement if it is to be enabled
by default. I don't have an issue with the presentation (though the
transient buffer is my preferred UX).
> The interface for displaying help could be which-key (it seems to look
> pretty enough), or just the current 'C-h' help, depending on the
> settings.
>
> The result, though, is that everybody learns to press 'C-h' when they
> want to explore what the current prefix map contains and not just wait
> for the timer.
^ permalink raw reply [relevance 99%]
* Re: Automatically saving package sources
@ 2024-02-04 10:22 91% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-02-04 10:22 UTC (permalink / raw)
To: sbaugh; +Cc: emacs-devel
sbaugh@catern.com writes:
> As an additional benefit, elpa-sources would be useful for reviewing
> changes in the source when upgrading packages. It could be optionally
> maintained as a VCS repository, with packages saved to a constant path
> based on their name (e.g. elpa-sources/xref.el instead of
> elpa-sources/xref-1.2.3/xref.el). Then a VCS could be used to review
> the diff resulting from an upgrade. This would be useful for any user
> who wants to scrutinize package code changes before installing them.
This would partially overlap with the functionality provided by
package-vc. It might be possible to re-use the functionality
wrt. building packages (e.g. building manuals, running extra commands),
that the ELPA build server takes care of when installing a package from
a tarball.
It might be, that all one needs would be to do a package-install-file?
Also, in the specific case of xref, you'd have the issue that xref.el is
maintained in emacs.git, and you cannot just checkout a subtree with
Git, so this would require tracking the entire Emacs repository,
presumably with individual checkouts for each core package you would
want to install, since the revisions one would be using wouldn't be the
same for all of them.
--
Philip Kaludercic
^ permalink raw reply [relevance 91%]
* Re: Request to include a couple of packages in GNU ELPA
@ 2024-02-04 8:56 99% ` Philip Kaludercic
1 sibling, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-02-04 8:56 UTC (permalink / raw)
To: Richard Stallman; +Cc: Rahguzar, 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. ]]]
>
> > 1) consult-hoogle: https://codeberg.org/rahguzar/consult-hoogle
> > It allows the use of hoogle search engine for haskell programming
> > language from Emacs using the interfaces provided by consult package.
>
> I've never heard of hoogle. What job does this do?
> How is hookle related to Haskell?
Hoogle (https://hoogle.haskell.org/) lets Haskell programmers search for
functions by giving their static types, among other queries. So one
could look for the generic type "(a -> b) -> [a] -> [b]", and different
"map" functions, from both the standard library and third party packages.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: discoverability, better defaults and which-key in Emacs
@ 2024-02-03 13:40 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-02-03 13:40 UTC (permalink / raw)
To: Po Lu; +Cc: Jeremy Bryant, justin, Emacs Devel
Po Lu <luangruo@yahoo.com> writes:
> Jeremy Bryant <jb@jeremybryant.net> writes:
>
>> Here is a suggestion - include which-key in core and potentially enable
>> by for new users.
>>
>> I understand it is in ELPA already.
>>
>> Author Justin has expressed openness to the idea in
>> https://github.com/justbur/emacs-which-key/issues/355
>
> I don't think enabling it by default is all that desirable, since its
> popups are far more intrusive than keystrokes are when echoed, but
> moving it to core is a decent idea.
I second this concern, it also promotes the inefficient practice of
inspecting keymaps by waiting for the idle timer to be triggered.
^ permalink raw reply [relevance 99%]
* Re: [ELPA] New package: activities
@ 2024-01-30 7:16 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-01-30 7:16 UTC (permalink / raw)
To: Adam Porter; +Cc: emacs-devel
Adam Porter <adam@alphapapa.net> writes:
> Hi Philip,
>
> Is there anything else I need to do before activities.el can be added
> to GNU ELPA? The activities.info file is already in the .elpaignore
> file, which I think should cover your feedback.
Nothing, it's just the end of my semester, so I have slight difficulties
catching up to my non-uni backlog :)
Regardless, I've added your package specification, and it should appear
shortly on the archive.
> Thanks,
> Adam
^ permalink raw reply [relevance 99%]
* Re: [ELPA] New package: activities
@ 2024-01-29 13:03 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-01-29 13:03 UTC (permalink / raw)
To: Sergey Organov; +Cc: Eric S Fraga, emacs-devel
[-- Attachment #1: Type: text/plain, Size: 593 bytes --]
Sergey Organov <sorganov@gmail.com> writes:
> Eric S Fraga <e.fraga@ucl.ac.uk> writes:
>
>> On Saturday, 27 Jan 2024 at 19:14, Sergey Organov wrote:
>>> That's how I use Emacs as well, yet I've built a package based on
>>> deskstop.el and session.el a long time ago that I've called desksess.el,
>>> and I'm still using it.
>>
>> Interesting. Are you able to share?
>
> Sure,
>
> https://drive.google.com/file/d/1U3TKybt8f7eiOGpyeoW_gFE8dDkFtASf/view?usp=sharing
I hope you don't mind me reposting the code here, because I know that
many here won't be able or willing to follow that link:
[-- Attachment #2: desksess.el --]
[-- Type: application/emacs-lisp, Size: 25563 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [ELPA] New package: activities
@ 2024-01-26 7:33 99% ` Philip Kaludercic
1 sibling, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-01-26 7:33 UTC (permalink / raw)
To: Adam Porter; +Cc: emacs-devel
Adam Porter <adam@alphapapa.net> writes:
> Hi,
>
> I'd like to add a new package to ELPA, activities.el. It's hosted at:
Nice name ;)
> https://github.com/alphapapa/activities.el
I don't have much to add on the code, just that if you are depending on
Emacs 29, you might be able to use `define-multisession-variable'
instead of having to depend on persist?
[...]
> + (activities :url "https://github.com/alphapapa/activities.el.git"
> + :release-branch "stable"
> + :doc "README.org")
There is no need to track the .info file in the repository, the build
server will generate that from :doc and overwrite it anyway.
^ permalink raw reply [relevance 99%]
* Re: [PATCH] dictonary.el documentation
@ 2024-01-23 17:14 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-01-23 17:14 UTC (permalink / raw)
To: No Wayman; +Cc: emacs-devel
No Wayman <iarchivedmywholelife@gmail.com> writes:
[...]
> -(defun dictionary-read-definition (&ignore)
> +(defun dictionary-read-definition (_)
[...]
Is there any advantage to the one or the other approach?
^ permalink raw reply [relevance 99%]
* Re: Package suggestion[nongnu]: Gnosis (γνῶσις)
@ 2024-01-23 7:53 91% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-01-23 7:53 UTC (permalink / raw)
To: Thanos Apollo; +Cc: emacs-devel
Thanos Apollo <public@thanosapollo.org> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>
> [...]
>> If you want to, we can add the package right now as long as you add a
>> -git, -rc, -alpha suffix or any of the other pseudo-version strings
>> specified in `version-regexp-alist'. That will instruct the ELPA build
>> server to not distribute the package on the main archive, until you bump
>> a release removing any "negative" version. Then you don't have to wait
>> for someone to respond to your message again.
>
> This sounds ideal, I have pushed a 0.2.0-alpha version, which is the
> only tagged release available on <https://git.thanosapollo.org/gnosis>,
> to avoid unexpected issues.
ELPA doesn't use tags for releases, the version is determined by
checking the "Version" attribute in the package header (in your case it
is currently set to 0.0.1). When this line is changed, a new release
will be triggered.
>
> Thank you,
>
> From 92c89f9bb3dd63fa3e81f22d34d6ab456e4eeb34 Mon Sep 17 00:00:00 2001
> From: Thanos Apollo <public@thanosapollo.org>
> Date: Tue, 23 Jan 2024 01:22:53 +0200
> Subject: [PATCH] * elpa-packages (gnosis): New package
>
> ---
> elpa-packages | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/elpa-packages b/elpa-packages
> index 9032331c31..068ccb04c3 100644
> --- a/elpa-packages
> +++ b/elpa-packages
> @@ -282,6 +282,10 @@
> (git-modes :url "https://github.com/magit/git-modes"
> :ignored-files ("LICENSE" ".mailmap"))
>
> + (gnosis :url "https://git.thanosapollo.org/gnosis"
> + :doc "doc/gnosis.texi"
I notice that you have .texi and .info files in your repository. IIUC
these are generated from the .org file, right? If that is so, you can
get rid of the generated files and instead let the ELPA build server
prepare these from the .org file for you.
> + :ignored-files ("LICENSE"))
It would be preferable, if you could track the files you wish not to
distribute in the package in a .elpaignore file within your repository,
that we don't need to update nongnu.git for any change.
> +
> (gnu-apl-mode :url "https://github.com/lokedhs/gnu-apl-mode"
> ;; :doc "texi/gnu-apl-mode.texi" ; the manual is currently empty
> :ignored-files ("Makefile"))
> --
> 2.43.0
^ permalink raw reply [relevance 91%]
* Re: Possible minibuffer completion enhancements
@ 2024-01-22 21:11 88% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-01-22 21:11 UTC (permalink / raw)
To: Eshel Yaron; +Cc: Stefan Kangas, emacs-devel
[-- Attachment #1: Type: text/plain, Size: 934 bytes --]
Eshel Yaron <me@eshelyaron.com> writes:
> Eshel Yaron <me@eshelyaron.com> writes:
>
>> All right, I've created a new feature branch called
>> feature/minibuffer-completion-enhancements that you can find at:
>>
>> git clone -b feature/minibuffer-completion-enhancements https://git.sr.ht/~eshel/emacs
>>
>> I've also requested access to push this branch to emacs.git on Savannah,
>> so people won't need to fetch from another Git remote to test it.
>
> I've rebased the feature/minibuffer-completion-enhancements branch on
> top of the current master, and pushed it to emacs.git. Looking forward
> for your thoughts and feedback!
I like the improvements, they are not invasive but useful. C-o is
particularly nice.
One annoyance I had with `completions-auto-update-mode' was that it
didn't update the buffer on deleting a character. This should fix it,
but perhaps it can be optimised further by using `after-change-functions'?
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: pch.diff --]
[-- Type: text/x-diff, Size: 731 bytes --]
diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 0f503523817..6b949d67ec1 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -5804,12 +5804,12 @@ completions-auto-update-start-timer
(defun completions-auto-update-setup ()
"Prepare for updating *Completions* as you type in the minibuffer."
- (add-hook 'post-self-insert-hook
+ (add-hook 'post-command-hook
#'completions-auto-update-start-timer nil t))
(defun completions-auto-update-exit ()
"Stop updating *Completions* as you type in the minibuffer."
- (remove-hook 'post-self-insert-hook
+ (remove-hook 'post-command-hook
#'completions-auto-update-start-timer t))
(define-minor-mode completions-auto-update-mode
^ permalink raw reply related [relevance 88%]
* Re: Package suggestion[nongnu]: Gnosis (γνῶσις)
@ 2024-01-22 17:59 98% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-01-22 17:59 UTC (permalink / raw)
To: Thanos Apollo; +Cc: emacs-devel
Thanos Apollo <public@thanosapollo.org> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Thanos Apollo <public@thanosapollo.org> writes:
>>
>>> Philip Kaludercic <philipk@posteo.net> writes:
>
> [...]
>
>>> Is there any alternative that it's recommended instead of emacsql for a
>>> package to interact with an sqlite databases? (Except triples)
>>
>> If you require at least Emacs 29, then you could fall back onto the
>> built-in SQLite support.
>>
>
> Thanks for the feedback, FYI I'm rewriting this with the built in
> sqlite & adding new features. Personally, I've found it much easier to
> work with the built in sqlite, since I can import items from other
> arbitrary databases that I've been using before.
>
> I'm also refactoring instances that use completing-read with
> read-multiple-choice.
Thanks.
> I will be contacting you when this package has a new stable version that
> is ready to be considered for inclusion in nongnu elpa.
If you want to, we can add the package right now as long as you add a
-git, -rc, -alpha suffix or any of the other pseudo-version strings
specified in `version-regexp-alist'. That will instruct the ELPA build
server to not distribute the package on the main archive, until you bump
a release removing any "negative" version. Then you don't have to wait
for someone to respond to your message again.
^ permalink raw reply [relevance 98%]
* Re: Patch for ansi-osc.el
@ 2024-01-22 7:21 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-01-22 7:21 UTC (permalink / raw)
To: Brad Howes; +Cc: emacs-devel@gnu.org
Brad Howes <bradhowes@mac.com> writes:
> FYI,
>
> I filed a tiny patch for ansi-osc.el which applies `downcase` to the
> result of `(system-host)` in order to match the behavior obtained when
> parsing the URL extracted from the comint output.
It usually isn't necessary to announce a bug report on the development
mailing list, people read both.
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=68632
>
> Regards,
>
> Brad
^ permalink raw reply [relevance 99%]
* Re: completing-read & emacsql
[not found] <871qacrubf.fsf@thanosapollo.org>
@ 2024-01-20 14:36 82% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-01-20 14:36 UTC (permalink / raw)
To: Thanos Apollo; +Cc: emacs-devel, Stefan Kangas
Thanos Apollo <public@thanosapollo.org> writes:
> Hello Philip,
You seemed to have dropped emacs-devel, so I added it again.
> Is using a defcustom like this a valiable solution, for completing-read
> interactions?
>
> (defcustom gnosis-completing-read-function
> (cond ((or (and (featurep 'vertico)
> vertico-mode)
> (and (featurep 'helm)
> helm-mode))
> 'completing-read)
> ((and (featurep 'ivy)
> ivy-mode)
> 'ivy-completing-read)
> (t 'ido-completing-read))
> "Preferred `completing-read' function to use.
>
> Defaults to Vertico, Ivy or Helm if available and enabled,
> otherwise defaults to `ido-completing-read'."
> :type 'function
> :group 'gnosis)
I wouldn't say so, at least for people like me who want to avoid visual
noise (as Emacs does by default), all of the above are wrong. I /want/
to use the default completion interface.
There is sadly a common mistake, in believing that `completing-read'
provides an interface for selecting strings, while the default interface
distinguishes between expansion of partial input and selecting from a
list of completion options. To me, that is the reason why
(completing-read "Select: " '(foo bar baz))
returns a string, and not a symbol. The interface is reading textual
input while providing completion -- which by default doesn't have to be
any of the completion options!
There is no canonical interface I know of to select an s-expression from
a collection, but perhaps there should be, to avoid the need of misusing
`completing-read'.
>
> AFAIK ido-completing-read is built-in with Emacs, this should make the
> user intractions with gnosis more convenient with the default emacs
> behavior.
>
>
> Where can I look for the discussions that took place for emacsql
> inclusion in nongnu ELPA? I can see a github issue on emacsql repo, but
> searching for "Jonas Bernoulli emacsql" on the emacs-devel archive
> doesn't return anything.
Stefan Kangas (CC'ed) added the packages a little over a year ago,
perhaps he remembers?
> I could use the built-in sqlite implementation, but it would mean that I
> (might) have to change much of the current values of my current database
> or at least how they are outputted.
>
> If you were developing a package that was already built using emacsql,
> would you consider it worth the work to change it to the built in sqlite?
I don't know what the current emacsql situation is, so it would be worth
looking into to resolve why the package is currently only on -devel, at
least before you start rewriting stuff.
^ permalink raw reply [relevance 82%]
* Re: Package suggestion[nongnu]: Gnosis (γνῶσις)
@ 2024-01-20 12:20 98% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-01-20 12:20 UTC (permalink / raw)
To: Thanos Apollo; +Cc: emacs-devel
Thanos Apollo <public@thanosapollo.org> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>>
>> Here area few comments in form of a diff (this is NOT a patch):
>
> [...]
>
> Thank you for your suggestions, they've been really helpful.
>
> I got confused and thought emacsql was included in nongnu elpa, but it's only
> available only in nongnu-devel.
You are right, that is peculiar. One should see what is holding back
the release.
> Is there any alternative that it's recommended instead of emacsql for a
> package to interact with an sqlite databases? (Except triples)
If you require at least Emacs 29, then you could fall back onto the
built-in SQLite support.
> I've refactored a couple important parts of gnosis to take into an
> account future extensibility, even by 3rd party packages. Example:
>
> (defvar gnosis-note-types '(MCQ Cloze Basic Double y-or-n)
> "Gnosis available note types.")
>
> (defun gnosis-add-note (type)
> "Create note(s) as TYPE interactively."
> (interactive (list (completing-read "Type: " gnosis-note-types nil t)))
> (when gnosis-testing
> (unless (y-or-n-p "You are using a testing environment! Continue?")
> (error "Aborted")))
> (let ((func-name (intern (format "gnosis-add-note-%s" (downcase type)))))
Perhaps using `intern-soft' would be better here.
> (if (fboundp func-name)
> (funcall func-name)
> (message "No such type."))))
>
> (defun gnosis-review-note (id)
> "Start review for note with value of id ID."
> (when (gnosis-suspended-p id)
> (message "Suspended note with id: %s" id)
> (sit-for 0.3)) ;; this should only occur in testing/dev cases
> (let* ((type (gnosis-get 'type 'notes `(= id ,id)))
> (func-name (intern (format "gnosis-review-%s" (downcase type)))))
> (if (fboundp func-name)
> (progn
> (with-current-buffer (switch-to-buffer (get-buffer-create "*gnosis*"))
You don't need `switch-to-buffer' if you are using `with-current-buffer'.
> (gnosis-mode)
> (funcall func-name id)))
> (error "Malformed note type: '%s'" type))))
>
> Adding new note types should be a trivial task now.
>
> I hadn't really used emacs without vertico and was unaware of how
> different completing-read user interactions actually are. I will be
> making adjustments for that wherever possible.
I use Emacs that way, so if you have any questions I'd be glad to
clarify usage patterns and annoyances.
^ permalink raw reply [relevance 98%]
* Re: Package suggestion[nongnu]: Gnosis (γνῶσις)
@ 2024-01-18 19:42 19% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-01-18 19:42 UTC (permalink / raw)
To: Thanos Apollo; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1479 bytes --]
Thanos Apollo <public@thanosapollo.org> writes:
> Gnosis (γνῶσις), pronounced "noh-sis", meaning knowledge in Greek, is
> a [Spaced Repetition](https://en.wikipedia.org/wiki/Spaced_repetition)
> implementation for GNU Emacs.
>
> Gnosis does not implement flashcard type review sessions where the
> user rates his own answer on an arbitrary scale. Instead implements
> "note" types that require user input. Some of these note types, like
> the `MCQ`, multiple choice question, even allow for simulating
> real-life exams.
>
> Unlike other SRS implementations for GNU Emacs, gnosis does not rely on
> `org-mode`, which I've found not to be an ideal option for a database
> replacement. Instead opting for an sqlite database with git to track
> any changes made, enabling efficient data management, manipulation and
> data integrity.
>
> You can read more on my blog post here:
> <https://thanosapollo.org/blog/gnosis-release/>
>
> This is a personal project of my mine that I made during my winter
> holidays, I have found it to be highly beneficial for my use case and,
> as a result, I decided to share it with all of you for anyone that's
> interested.
>
> Direct link to gnosis repo:
> <https://git.thanosapollo.org/gnosis/>
>
>
> Any feedback would be appreciated, since I'm far from a programmer and
> relatively new to the GNU Emacs ecosystem.
>
> Thank you,
Here area few comments in form of a diff (this is NOT a patch):
[-- Attachment #2: Type: text/plain, Size: 19688 bytes --]
diff --git a/gnosis.el b/gnosis.el
index 7ddeb30..87e1cee 100644
--- a/gnosis.el
+++ b/gnosis.el
@@ -9,6 +9,8 @@
;; Package-Requires: ((emacs "27.2") (compat "29.1.4.2") (emacsql "20230228"))
+;; There is no package "emacsql" on GNU or NonGNU ELPA!
+
;; 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
@@ -29,13 +31,13 @@
;; for GNU Emacs.
;;
;; Gnosis does not implement flashcard type review sessions where the
-;; user rates his own answer on an arbitrary scale. Instead implements
-;; "note" types that require user input. Some of these note types, like
+;; user rates his own answer on an arbitrary scale. Instead implements
+;; "note" types that require user input. Some of these note types, like
;; the MCQ, multiple choice question, even allow for simulating
;; real-life exams.
;;
;; Unlike other SRS implementations for GNU Emacs, gnosis not rely on
-;; org-mode. Instead utilizes an sqlite database & git, enabling
+;; org-mode. Instead utilizes an sqlite database & git, enabling
;; efficient data management, manipulation and data integrity.
;;; Code:
@@ -51,7 +53,7 @@
:group 'external
:prefix "gnosis-")
-(defcustom gnosis-dir (concat user-emacs-directory "gnosis")
+(defcustom gnosis-dir (locate-user-emacs-file "gnosis")
"Gnosis directory."
:type 'directory
:group 'gnosis)
@@ -62,13 +64,13 @@
:group 'gnosis)
-(defvar gnosis-images-dir (concat (file-name-as-directory gnosis-dir) "images")
+(defvar gnosis-images-dir (expand-file-name "images" gnosis-dir)
"Gnosis images directory.")
(defconst gnosis-db
(if (not (file-directory-p gnosis-dir))
(gnosis-db-init)
- (emacsql-sqlite (concat (file-name-as-directory gnosis-dir) "gnosis.db")))
+ (emacsql-sqlite (expand-file-name "gnosis.db" gnosis-dir)))
"Gnosis database file.")
(defvar gnosis-testing nil
@@ -136,8 +138,6 @@
"Face for next review."
:group 'gnosis-face)
-
-
(cl-defun gnosis-select (value table &optional (restrictions '1=1))
"Select VALUE from TABLE, optionally with RESTRICTIONS.
@@ -264,7 +264,7 @@ SUCCESS is t when user-input is correct, else nil"
"Replace CLOZE-CHAR with REPLACE.
If FACE nil, propertize replace using `gnosis-face-correct', or
-`gnosis-face-false' when (not SUCCESS). Else use FACE value."
+`gnosis-face-false' when (not SUCCESS). Else use FACE value."
(goto-char (point-min))
(search-forward cloze-char nil t)
(replace-match (propertize replace 'face (if (not face)
@@ -329,6 +329,8 @@ Set DOWNCASE to t to downcase all input given.
Set SPLIT to t to split all input given."
(cl-loop with input = nil
for response = (read-string (concat prompt " (q for quit): "))
+ ;; Are you sure you don't want to use `read-char' here? Or
+ ;; `completing-read-multiple'
do (if downcase (setf response (downcase response)))
for response-parts = (if split (split-string response " ") (list response))
if (member "q" response-parts) return (nreverse input)
@@ -397,6 +399,9 @@ When called with a prefix, unsuspends all notes for tag."
"Suspend note(s) with specified values."
(interactive)
(let ((item (completing-read "Suspend by: " '("Deck" "Tag"))))
+ ;; Why use completing prompt for a two-choice option? I think
+ ;; `yes-or-no-p' or `read-multiple-choice' would be more adequate
+ ;; and would require less custom logic.
(pcase item
("Deck" (gnosis-suspend-deck))
("Tag" (gnosis-suspend-tag))
@@ -444,8 +449,8 @@ NOTE: If a gnosis--insert-into fails, the whole transaction will be
MCQ type consists of a main `QUESTION' that is displayed to the user.
The user will be prompted to select the correct answer from a list of
-`CHOICES'. The `CORRECT-ANSWER' should be the index of the correct
-choice in the `CHOICES' list. Each note must correspond to one `DECK'.
+`CHOICES'. The `CORRECT-ANSWER' should be the index of the correct
+choice in the `CHOICES' list. Each note must correspond to one `DECK'.
`IMAGE' Image to display before user-input
`SECOND-IMAGE' Image to display after user-input
@@ -470,6 +475,8 @@ TAGS: Used to organize notes
Refer to `gnosis-add-note--mcq' for more."
(let ((deck (gnosis--get-deck-name)))
+ ;; Prefer `yes-or-no-p', and let the user decide what to use with
+ ;; `use-short-answers'.
(while (y-or-n-p (format "Add note of type `MCQ' to `%s' deck? " deck))
(gnosis-add-note--mcq :deck deck
:question (read-string "Question: ")
@@ -590,7 +597,7 @@ Example:
{c2:Staphylococcus aureus} causes {c3:rapid} onset
food poisoning
-Generates 3 cloze note types. Where the \"main\" part of the note is the full
+Generates 3 cloze note types. Where the \"main\" part of the note is the full
note, with the cloze(s) extracted & used as the \"answer\".
One cloze note may have multiple clozes
@@ -632,7 +639,7 @@ Example:
{c2:Staphylococcus aureus} causes {c3:rapid} onset
food poisoning
-Generates 3 cloze note types. Where the \"main\" part of the note is
+Generates 3 cloze note types. Where the \"main\" part of the note is
the full note, with the cloze(s) extracted & used as the \"answer\".
See `gnosis-add-note--cloze' for more reference."
@@ -651,6 +658,9 @@ See `gnosis-add-note--cloze' for more reference."
(when gnosis-testing
(unless (y-or-n-p "You are using a testing environment! Continue?")
(error "Aborted")))
+ ;; would it make more sense to invert the control-logic using
+ ;; generic functions. That would make it easier to extend the
+ ;; package from outside as well.
(pcase type
("MCQ" (gnosis-add-note-mcq))
("Cloze" (gnosis-add-note-cloze))
@@ -708,6 +718,7 @@ Valid cloze formats include:
"Compare STR1 and STR2.
Compare 2 strings, ignoring case and whitespace."
+ ;; see also `string-equal-ignore-case'
(string= (downcase (replace-regexp-in-string "\\s-" "" str1))
(downcase (replace-regexp-in-string "\\s-" "" str2))))
@@ -718,7 +729,7 @@ DIR is the base directory path from which to start the recursive search.
REGEX is the regular expression pattern to match the file names against.
This function traverses the subdirectories of DIR recursively,
-collecting file paths that match the regular expression. The file
+collecting file paths that match the regular expression. The file
paths are returned as a list of strings, with each string representing
a relative file path to DIR.
@@ -758,9 +769,7 @@ Optionally, add cusotm PROMPT."
(defun gnosis-suspended-p (id)
"Return t if note with ID is suspended."
- (if (= (gnosis-get 'suspend 'review-log `(= id ,id)) 1)
- t
- nil))
+ (= (gnosis-get 'suspend 'review-log `(= id ,id)) 1))
(defun gnosis-get-deck-due-notes (&optional deck-id)
"Return due notes for deck, with value of DECK-ID.
@@ -788,7 +797,7 @@ DATE is a list of the form (year month day)."
(cl-mapcan (lambda (note-id)
(gnosis-get-note-tags note-id))
due-notes)
- :test 'equal)))
+ :test #'equal)))
(cl-defun gnosis-tag-prompt (&key (prompt "Selected tags") (match nil) (due nil))
@@ -816,15 +825,13 @@ Returns a list of unique tags."
"Check if note with value of NOTE-ID for id is due for review.
Check if it's suspended, and if it's due today."
- (if (and (not (gnosis-suspended-p note-id))
- (gnosis-review-is-due-today-p note-id))
- t
- nil))
+ (and (not (gnosis-suspended-p note-id))
+ (gnosis-review-is-due-today-p note-id)))
(defun gnosis-review-is-due-today-p (id)
"Return t if note with ID is due today.
-This function ignores if note is suspended. Refer to
+This function ignores if note is suspended. Refer to
`gnosis-review-is-due-p' if you need to check for suspended value as
well."
(let ((next-rev (gnosis-get 'next-rev 'review-log `(= id ,id))))
@@ -867,7 +874,7 @@ Returns a list of the form ((yyyy mm dd) ef)."
(cl-mapcan (lambda (note-id)
(gnosis-get-note-tags note-id))
due-notes)
- :test 'equal)))
+ :test #'equal)))
(defun gnosis-review--get-offset (id)
"Return offset for note with value of id ID."
@@ -879,7 +886,7 @@ Returns a list of the form ((yyyy mm dd) ef)."
This function is used to round floating point numbers to 1 decimal,
such as the easiness factor (ef)."
- (/ (round (* num 100.00)) 100.00))
+ (/ (round (* num 100.00)) 100.00)) ;doesn't this leave two decimals?
(defun gnosis-review-new-ef (id success)
"Return new ef for note with value of id ID.
@@ -917,8 +924,9 @@ SUCCESS is a binary value, 1 is for successful review."
(answer (nth (- (gnosis-get 'answer 'notes `(= id ,id)) 1) choices))
(user-choice (gnosis-mcq-answer id)))
(if (string= answer user-choice)
- (progn (gnosis-review--update id 1)
- (message "Correct!"))
+ (progn
+ (gnosis-review--update id 1)
+ (message "Correct!"))
(gnosis-review--update id 0)
(message "False"))
(gnosis-display-correct-answer-mcq answer user-choice)
@@ -1014,17 +1022,18 @@ Used to reveal all clozes left with `gnosis-face-cloze-unanswered' face."
"Commit review session on git repository.
This function initializes the `gnosis-dir' as a Git repository if it is not
-already one. It then adds the gnosis.db file to the repository and commits
+already one. It then adds the gnosis.db file to the repository and commits
the changes with a message containing the reviewed number of notes.
NOTE-NUM: The number of notes reviewed in the session."
- (let ((git (executable-find "git"))
+ (let ((git (executable-find "git")) ;consider using `vc-git'
(default-directory gnosis-dir))
(unless git
(error "Git not found, please install git"))
(unless (file-exists-p (concat (file-name-as-directory gnosis-dir) ".git"))
(shell-command "git init"))
(sit-for 0.2) ;; wait for shell command to finish
+ ;; `shell-command' is blocking anyway, so you don't need to wait
(shell-command (concat git " add " (shell-quote-argument "gnosis.db")))
(shell-command (concat git " commit -m "
(shell-quote-argument (concat (format "Total notes for session: %d " note-num)))))
@@ -1039,13 +1048,20 @@ NOTE-NUM: The number of notes reviewed in the session."
(cl-loop for note in notes
do (gnosis-review-note note)
(setf note-count (1+ note-count))
- (pcase (read-char-choice "Note Action: [n]ext, [s]uspend, [e]dit, [q]uit: " '(?n ?s ?e ?q))
+ (pcase (car (read-multiple-choice
+ "Note actions"
+ '((?n "next")
+ (?s "suspend")
+ (?e "edit")
+ (?q "quit"))))
(?n nil)
(?s (gnosis-suspend-note note))
- (?e (progn (gnosis-edit-note note)
- (recursive-edit)))
- (?q (progn (gnosis-review-commit note-count)
- (cl-return))))
+ (?e
+ (gnosis-edit-note note)
+ (recursive-edit))
+ (?q
+ (gnosis-review-commit note-count)
+ (cl-return)))
finally (gnosis-review-commit note-count))))))
@@ -1065,6 +1081,7 @@ NOTE-NUM: The number of notes reviewed in the session."
("Total" 2)
("Decrease" 1)
("Increase" 0)))
+ ;; Thy does this have to be a float? Why not use `read-number'?
(new-value (float (string-to-number (read-string "New value: ")))))
;; error checking.
(cond ((>= 0 new-value) (error "New value needs to be a number & higher than `0'"))
@@ -1079,7 +1096,7 @@ NOTE-NUM: The number of notes reviewed in the session."
"Edit the contents of a note with the given ID.
This function creates an Emacs Lisp buffer named *gnosis-edit* and populates it
-with the values of the note identified by the specified ID. The note values are
+with the values of the note identified by the specified ID. The note values are
inserted as keywords for the `gnosis-edit-update-note' function.
To make changes, edit the values in the buffer, and then evaluate the
@@ -1109,6 +1126,9 @@ changes."
(with-current-buffer (switch-to-buffer (get-buffer-create "*gnosis-edit*"))
(gnosis-edit-mode)
(erase-buffer)
+ ;; I feel it would be better to construct an s-expression and
+ ;; then transform it into a string using `pp-to-string' or some
+ ;; function like that.
(insert ";;\n;; You are editing a gnosis note. DO NOT change the value of id.\n\n")
(insert "(gnosis-edit-update-note ")
(cl-loop for (field value) in `((id ,id)
@@ -1119,7 +1139,7 @@ changes."
(extra-notes ,extra-notes)
(image ,image)
(second-image ,second-image))
- do (cond ((equal field 'id)
+ do (cond ((eq field 'id)
(insert (format (concat ":%s " (propertize "%s" 'read-only t) "\n") field value)))
((numberp value)
(insert (format ":%s %s\n" field value)))
@@ -1127,7 +1147,7 @@ changes."
(not (equal value nil)))
(insert (format ":%s '%s\n" field (format "%s" (cl-loop for item in value
collect (format "\"%s\"" item))))))
- ((equal value nil)
+ ((nul value)
(insert (format ":%s %s\n" field 'nil)))
(t (insert (format ":%s \"%s\"\n" field value)))))
(delete-char -1) ;; delete extra line
@@ -1148,11 +1168,8 @@ changes."
(define-derived-mode gnosis-edit-mode emacs-lisp-mode "Gnosis EDIT"
"Gnosis Edit Mode."
- :interactive t
- :lighter " gnosis-edit-mode"
- :keymap gnosis-edit-mode-map)
-
-
+ :lighter " gnosis-edit-mode") ;this is a rather long lighter...
+
(cl-defun gnosis-edit-update-note (&key id main options answer tags (extra-notes nil) (image nil) (second-image nil))
"Update note with id value of ID.
@@ -1175,7 +1192,7 @@ SECOND-IMAGE: Image to display after user-input"
(image . ,image)
(second-image . ,second-image))
when value
- do (cond ((member field '(extra-notes image second-image))
+ do (cond ((memq field '(extra-notes image second-image))
(gnosis-update 'extras `(= ,field ,value) `(= id ,id)))
((listp value)
(gnosis-update 'notes `(= ,field ',value) `(= id ,id)))
@@ -1191,13 +1208,13 @@ SECOND-IMAGE: Image to display after user-input"
ID: Identifier of the note to export.
This function retrieves the fields of a note with the given ID and
-inserts them into the current buffer. Each field is represented as a
-property list entry. The following fields are exported: type, main,
+inserts them into the current buffer. Each field is represented as a
+property list entry. The following fields are exported: type, main,
options, answer, tags, extra-notes, image, and second-image.
The exported fields are formatted as key-value pairs with a colon,
-e.g., :field value. The fields are inserted sequentially into the
-buffer. For certain field values, like lists or nil, special
+e.g., :field value. The fields are inserted sequentially into the
+buffer. For certain field values, like lists or nil, special
formatting is applied.
If the value is a list, the elements are formatted as strings and
@@ -1249,11 +1266,11 @@ It then retrieves all the notes associated with the deck and exports
them.
The exported notes are formatted as an Emacs Lisp code block that can
-be evaluated to recreate the deck with its associated notes. The
+be evaluated to recreate the deck with its associated notes. The
resulting code is saved to a file with the provided FILENAME and a
'.el' extension is added automatically.
-Each note is exported using the `gnosis-export-note` function. The
+Each note is exported using the `gnosis-export-note` function. The
generated code includes a call to `gnosis-define-deck` with the deck
name and all notes formatted as nested lists"
(interactive (list (read-string "Filename: ")))
@@ -1271,27 +1288,27 @@ name and all notes formatted as nested lists"
"Define DECK consisting of NOTES, optionally add them as SUSPENDED.
The `gnosis-define-deck` function adds a new deck with the specified
-name to `gnosis-db'. It also adds each note from the given list
-of `notes` to the deck. The function takes three optional arguments:
+name to `gnosis-db'. It also adds each note from the given list
+of `notes` to the deck. The function takes three optional arguments:
`deck`, `notes`, and `suspended`.
-- `deck`: The name of the deck to be added. It should be provided as a
+- `deck`: The name of the deck to be added. It should be provided as a
symbol.
-- `notes`: A list containing the notes to be added to the deck. Each
+- `notes`: A list containing the notes to be added to the deck. Each
note should be represented as a property list with the
following keys: `:type`, `:main`, `:options`, `:answer`
- extras include :`:extra-notes`, `:tags`, `:image`, and `:second-image`.
- `suspended`: An optional argument specifying whether the deck should
- be created in a suspended state. A non-zero value
+ be created in a suspended state. A non-zero value
suspends the deck, while a value of 0 (default) creates
the deck in an active state.
When calling `gnosis-define-deck`, the deck is added to the Gnosis
-system by calling `gnosis-add-deck`. Each note is added to the deck
-using `gnosis-add-note-fields`. The function iterates over the list of
+system by calling `gnosis-add-deck`. Each note is added to the deck
+using `gnosis-add-note-fields`. The function iterates over the list of
`notes` and extracts the necessary fields from each note's property
list before adding them to the deck.
@@ -1300,6 +1317,10 @@ associated notes in `gnosis-db', ready for further processing or
review."
(gnosis-add-deck (symbol-name deck))
(sit-for 0.1) ;; wait for low-spec computers to create deck
+
+ ;; I am not sure what is going on, but `sit-for' is not a robust way
+ ;; to handle asynchronous processes. If everything is synchronous,
+ ;; there is no reason to block.
(cl-loop for note in notes
do (gnosis-add-note-fields (symbol-name deck)
(plist-get note :type)
@@ -1318,6 +1339,11 @@ review."
"Start gnosis review session."
(interactive)
(gnosis-db-init)
+ ;; There are a lot of string constants here that are being
+ ;; duplicated. And as mentioned before, `completing-read' does not
+ ;; appear to be the best interface. Keep in mind that not everyone
+ ;; uses a selecting interface like icomplete or vertico, where this
+ ;; kind of UI is pretty awkward.
(let ((review-type (completing-read "Review: " '("Due notes"
"Due notes of deck"
"Due notes of specified tag(s)"
@@ -1377,7 +1403,7 @@ review."
;; Make sure gnosis-db is initialized
(setf gnosis-db (emacsql-sqlite (concat (file-name-as-directory gnosis-dir) "gnosis.db"))))
;; Create database tables
- (unless (= (length (emacsql gnosis-db [:select name :from sqlite-master :where (= type table)])) 6)
+ (unless (length= (emacsql gnosis-db [:select name :from sqlite-master :where (= type table)]) 6)
;; Enable foreign keys
(emacsql gnosis-db "PRAGMA foreign_keys = ON")
;; Gnosis version
@@ -1397,12 +1423,10 @@ review."
;;;;;;;;;;;;;;;;;
(define-derived-mode gnosis-mode special-mode "Gnosis"
- "Gnosis Mode."
- :interactive t
+ "Gnosis Mode." ;this could be extended
+ :lighter " gnosis-mode"
(read-only-mode 0)
- (display-line-numbers-mode 0)
- :lighter " gnosis-mode")
-
+ (display-line-numbers-mode 0))
(provide 'gnosis)
;;; gnosis.el ends here
^ permalink raw reply related [relevance 19%]
* Re: [ELPA] New package: jami-bot and org-jami-bot
@ 2024-01-17 23:39 97% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-01-17 23:39 UTC (permalink / raw)
To: Hanno Perrey; +Cc: Stefan Kangas, emacs-devel
Hanno Perrey <hanno@hoowl.se> writes:
> Dear Philip,
>
>> Other than that, here is a diff with the remaining changes I would
>> propose:
>
> applied and pushed, thanks for the detailed comb-through! :)
OK, looks like it works now, so I have pushed the package specification.
One more thing I noticed is that you have this in your package header,
;; Author: Hanno Perrey <http://gitlab.com/hperrey>
which is not a valid Email address. The idea is to have an email
address here, that is used to generate a compose buffer when the user is
reading about the package from a package description buffer.
> Best wishes,
>
> Hanno
^ permalink raw reply [relevance 97%]
* Re: Auto-suggesting Packages
@ 2024-01-16 16:18 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-01-16 16:18 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: emacs-devel@gnu.org
>> Date: Tue, 16 Jan 2024 15:06:02 +0000
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> > Is it really a good idea to show this on the mode line? Why not in
>> > the echo-area? We have several features that suggest tips, and AFAIK
>> > they all show the tips in the echo-area.
>>
>> That is also implemented, I don't know what default is better. The
>> reason I considered the mode line is because having the information
>> displayed persistently might something that newcomer appreciate,
>> especially when they are prone to overlooking something, especially in
>> the echo area.
>
> Then how about displaying it on a header-line instead (or as an
> option)?
>
>> I know that VSCode has something along these lines with
>> a popup window.
>
> We could offer a popup window as well, or (on GUI terminals) maybe a
> dialog box.
Both are possible, but perhaps invasive. The popup buffer that VSCode
displays is more akin to a child window that disappears after a timeout,
and my understanding is that these are a conventional part of the user
experience, which IMO is not the case with Emacs.
^ permalink raw reply [relevance 99%]
* Re: Auto-suggesting Packages
@ 2024-01-16 15:06 96% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-01-16 15:06 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Date: Tue, 16 Jan 2024 08:18:55 +0000
>>
>> I posted a patch like this a few months back and forgot about it, but
>> Sacha's Emacs News this weeks reminded me again. I took the code and
>> changed the default behaviour to indicate a package can be installed in
>> the mode line:
>
> Is it really a good idea to show this on the mode line? Why not in
> the echo-area? We have several features that suggest tips, and AFAIK
> they all show the tips in the echo-area.
That is also implemented, I don't know what default is better. The
reason I considered the mode line is because having the information
displayed persistently might something that newcomer appreciate,
especially when they are prone to overlooking something, especially in
the echo area. I know that VSCode has something along these lines with
a popup window.
This is how the message would look like, for fundamental mode buffers:
--8<---------------cut here---------------start------------->8---
Found suggested packages: lua-mode. Install using M-x package-autosuggest
--8<---------------cut here---------------end--------------->8---
> Thanks.
^ permalink raw reply [relevance 96%]
* Re: Auto-suggesting Packages
@ 2024-01-16 9:26 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-01-16 9:26 UTC (permalink / raw)
To: Stephen Berman; +Cc: emacs-devel
Stephen Berman <stephen.berman@gmx.net> writes:
> On Tue, 16 Jan 2024 08:18:55 +0000 Philip Kaludercic <philipk@posteo.net> wrote:
>
>> I posted a patch like this a few months back and forgot about it, but
>> Sacha's Emacs News this weeks reminded me again. I took the code and
>> changed the default behaviour to indicate a package can be installed in
>> the mode line:
> [...]
>> +;;;; Autosuggest
> [...]
>> +(defvar package--autosugest-line-format
>> + '(:eval (package--autosugest-line-format)))
>> +(put 'package--autosugest-line-format 'risky-local-variable t)
> [...]
>> +(defun package--autosugest-line-format ()
> [...]
>> + `(package-autosuggest-mode ("" package--autosugest-line-format)))
>
> autosugest -> autosuggest
Thanks, fixed that.
> Steve Berman
^ permalink raw reply [relevance 99%]
* Auto-suggesting Packages
@ 2024-01-16 8:18 46% Philip Kaludercic
0 siblings, 2 replies; 200+ results
From: Philip Kaludercic @ 2024-01-16 8:18 UTC (permalink / raw)
To: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 229 bytes --]
I posted a patch like this a few months back and forgot about it, but
Sacha's Emacs News this weeks reminded me again. I took the code and
changed the default behaviour to indicate a package can be installed in
the mode line:
[-- Attachment #2: Type: text/plain, Size: 6665 bytes --]
diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el
index 868373f46c2..0c94a1df1cf 100644
--- a/lisp/emacs-lisp/package.el
+++ b/lisp/emacs-lisp/package.el
@@ -4533,6 +4533,155 @@ package-get-version
(or (lm-header "package-version")
(lm-header "version")))))))))
+\f
+;;;; Autosuggest
+
+(defvar package-autosuggest-database
+ '((sml-mode auto-mode-alist "\\.sml\\'")
+ (lua-mode auto-mode-alist "\\.lua\\'" )
+ (ada-mode auto-mode-alist "\\.ada\\'")
+ ;; ...
+ ;;
+ ;; this is just for testing, in practice I think this data should
+ ;; be generated and bundled with Emacs, and would ideally be
+ ;; loaded in at compile-time. When the "archive-contents" file
+ ;; format is updated, we can include more information in there
+ ;; that would be added to this database.
+ )
+ "Database of hints for packages to suggest installing.")
+
+(define-minor-mode package-autosuggest-mode
+ "Enable the automatic suggestion and installation of packages."
+ :init-value 'mode-line :global t
+ :type '(choice (const :tag "Indicate in mode line" mode-line)
+ (const :tag "Always prompt" always)
+ (const :tag "Prompt only once" once)
+ (const :tag "Indicate with message" message)
+ (const :tag "Do not suggest anything" nil))
+ (funcall (if package-autosuggest-mode #'add-hook #'remove-hook)
+ 'after-change-major-mode-hook
+ #'package--autosuggest-after-change-mode))
+
+(defun package--suggestion-applies-p (pkg-sug)
+ "Check if a suggestion PKG-SUG is applicable to the current buffer."
+ (pcase pkg-sug
+ (`(,(pred package-installed-p) . _) nil)
+ ((or `(,_ auto-mode-alist ,ext _)
+ `(,_ auto-mode-alist ,ext))
+ (and (string-match-p ext (buffer-name)) t))
+ ((or `(,_ magic-mode-alist ,mag _)
+ `(,_ magic-mode-alist ,mag))
+ (save-restriction
+ (widen)
+ (save-excursion
+ (goto-char (point-min))
+ (looking-at-p mag))))
+ ((or `(,_ interpreter-mode-alist ,magic _)
+ `(,_ interpreter-mode-alist ,magic))
+ (save-restriction
+ (widen)
+ (save-excursion
+ (goto-char (point-min))
+ (and (looking-at auto-mode-interpreter-regexp)
+ (string-match-p
+ (concat "\\`" (file-name-nondirectory (match-string 2)) "\\'")
+ magic)))))))
+
+(defun package--autosuggest-find-candidates ()
+ "Return a list of packages that might be interesting the current buffer."
+ (and package-autosuggest-mode
+ (let (suggetions)
+ (dolist (sug package-autosuggest-database)
+ (when (package--suggestion-applies-p sug)
+ (push sug suggetions)))
+ suggetions)))
+
+(defun package--autosuggest-install-and-enable (pkg-sug)
+ "Install and enable a package suggestion PKG-ENT.
+PKG-SUG has the same form as an element of
+`package-autosuggest-database'."
+ (package-install (car pkg-sug))
+ (with-demoted-errors "Failed to enable: %S"
+ (dolist (buf (buffer-list))
+ (with-current-buffer buf
+ (when (and (eq major-mode 'fundamental-mode) (buffer-file-name)
+ (package--suggestion-applies-p pkg-sug))
+ (funcall-interactively (or (cadddr pkg-sug) (car pkg-sug))))))))
+
+(defvar package--autosuggest-suggested '()
+ "List of packages that have already been suggested.")
+
+(defvar package--autosugest-line-format
+ '(:eval (package--autosugest-line-format)))
+(put 'package--autosugest-line-format 'risky-local-variable t)
+
+(defface package-autosuggest-face
+ '((t :inherit (success)))
+ "Face to use in the mode line to highlight suggested packages."
+ :version "30.1")
+
+(defun package--autosugest-line-format ()
+ "Generate a mode-line string to indicate a suggested package."
+ `(,@(and-let* (((eq package-autosuggest-mode 'mode-line))
+ (avail (seq-difference (package--autosuggest-find-candidates)
+ package--autosuggest-suggested)))
+ (propertize
+ (format "Install %s?"
+ (mapconcat
+ #'symbol-name
+ (delete-dups (mapcar #'car avail))
+ ", "))
+ 'face 'package-autosuggest-face
+ 'mouse-face 'mode-line-highlight
+ 'help-echo "Click to install suggested package."
+ 'keymap (let ((map (make-sparse-keymap)))
+ (define-key map [mode-line down-mouse-1] #'package-autosuggest)
+ map)))))
+
+(add-to-list 'mode-line-misc-info
+ `(package-autosuggest-mode ("" package--autosugest-line-format)))
+
+(defun package--autosuggest-after-change-mode ()
+ "Hook function to suggest packages for installation."
+ (when-let ((avail (seq-difference (package--autosuggest-find-candidates)
+ package--autosuggest-suggested))
+ (pkgs (mapconcat #'symbol-name
+ (delete-dups (mapcar #'car avail))
+ ", ")))
+ (add-to-list 'mode-line-misc-info
+ `(eglot--managed-mode (" [" eglot--mode-line-format "] ")))
+ (pcase package-autosuggest-mode
+ ('mode-line
+ (force-mode-line-update t))
+ ('always
+ (when (yes-or-no-p (format "Install suggested packages (%s)?" pkgs))
+ (mapc #'package--autosuggest-install-and-enable avail)))
+ ('once
+ (when (yes-or-no-p (format "Install suggested packages (%s)?" pkgs))
+ (mapc #'package--autosuggest-install-and-enable avail))
+ (setq package--autosuggest-suggested (append avail package--autosuggest-suggested)))
+ ('message
+ (message
+ (substitute-command-keys
+ (format "Found suggested packages: %s. Install using \\[package-autosuggest]"
+ pkgs)))))))
+
+(defun package-autosuggest ()
+ "Prompt the user for suggested packages."
+ (interactive)
+ (let* ((avail (or (package--autosuggest-find-candidates)
+ (user-error "No suggestions found")))
+ (pkgs (completing-read-multiple
+ "Install suggested packages: " avail
+ nil t
+ (mapconcat #'symbol-name
+ (delete-dups (mapcar #'car avail))
+ ",")))
+ (choice (concat "\\`" (regexp-opt pkgs) "\\'")))
+ (dolist (ent avail)
+ (when (string-match-p choice (symbol-name (car ent)))
+ (package--autosuggest-install-and-enable ent)))))
+
\f
;;;; Quickstart: precompute activation actions for faster start up.
[-- Attachment #3: Type: text/plain, Size: 449 bytes --]
One annoyance I cannot resolve right now is that when I click on the
mode line, it calls `package-autosuggest' that attempts to confirm the
installation wish using `completing-read-multiple' with an initial input
(so everything the user needs to do is to press enter). But due to the
mouse-click, it appears the minibuffer is not selected, which can be
confusing. Adding a `switch-to-minibuffer' didn't help either. Does
anyone know what to do?
^ permalink raw reply related [relevance 46%]
* Re: [ELPA] New package devicetree-ts-mode
@ 2024-01-16 7:30 96% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-01-16 7:30 UTC (permalink / raw)
To: Aleksandr Vityazev; +Cc: emacs-devel, Stefan Kangas
Aleksandr Vityazev <avityazev@disroot.org> writes:
> On 2024-01-16 06:18, Philip Kaludercic wrote:
>
>> Aleksandr Vityazev <avityazev@disroot.org> writes:
>>
>>> Hello,
>>>
>>> Since the previous thread [1] got lost over time and no more replies,
>>> I'm starting a new one.
>>
>> Sorry about that, I hadn't gotten around to answering your last ping.
>>
>>> All of Philip's suggested points have been fixed, is there any reason
>>> why this package should not be included in ELPA? I am willing to listen
>>> and fix if possible.
>>
>> I think code-wise everything should be fine. Just to be sure, you have
>> signed the FSF CA and are familiar with how the ELPA build server works
>> (at least from a package developer perspective)?
>>
>
> Yes, I have a signed CA FSF. One of my packages is already in ELPA, so I'm more
> or less familiar with the build process.
OK, great, I have tried building the package and it works. The package
has been added to the archive and should appear soon enough.
Another tip I can give you is that since you have a mailing list on
Soucehut, I recommend adding that is the maintainer address in the
package header.
Also, is it necessary to distribute both the README.md and README.org in
the package tarball? I would assume the former is for Sourcehut, right?
>>> Link to repository - https://git.sr.ht/~akagi/devicetree-ts-mode/
>>>
>>> [1] https://mail.gnu.org/archive/html/emacs-devel/2023-12/msg00629.html
^ permalink raw reply [relevance 96%]
* Re: [elpa] main 630bdd7c45: * elpa-packages: update all Protesilaos repo URLs
[not found] ` <20240112055545.BD592C00216@vcs2.savannah.gnu.org>
@ 2024-01-16 7:26 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-01-16 7:26 UTC (permalink / raw)
To: emacs-devel; +Cc: Protesilaos Stavrou
Protesilaos Stavrou <info@protesilaos.com> writes:
> branch: main
> commit 630bdd7c45982b71bcaf86019a0cd3bd1f2f9336
> Author: Protesilaos Stavrou <info@protesilaos.com>
> Commit: Protesilaos Stavrou <info@protesilaos.com>
>
> * elpa-packages: update all Protesilaos repo URLs
>
> SourceHut is down and I need to deliver new versions to users.
[...]
> - (agitate :url "https://git.sr.ht/~protesilaos/agitate"
> + (agitate :url "https://github.com/protesilaos/agitate"
It seems that the DDOS attack is over (see https://sourcehut.org/), do
you plan to revert these changes? I don't know what the background was,
but if there was some urgent change, you could have also just pushed the
changes directly to elpa.git.
^ permalink raw reply [relevance 99%]
* Re: [ELPA] New package devicetree-ts-mode
@ 2024-01-16 6:18 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-01-16 6:18 UTC (permalink / raw)
To: Aleksandr Vityazev; +Cc: emacs-devel, Stefan Kangas
Aleksandr Vityazev <avityazev@disroot.org> writes:
> Hello,
>
> Since the previous thread [1] got lost over time and no more replies,
> I'm starting a new one.
Sorry about that, I hadn't gotten around to answering your last ping.
> All of Philip's suggested points have been fixed, is there any reason
> why this package should not be included in ELPA? I am willing to listen
> and fix if possible.
I think code-wise everything should be fine. Just to be sure, you have
signed the FSF CA and are familiar with how the ELPA build server works
(at least from a package developer perspective)?
> Link to repository - https://git.sr.ht/~akagi/devicetree-ts-mode/
>
> [1] https://mail.gnu.org/archive/html/emacs-devel/2023-12/msg00629.html
^ permalink raw reply [relevance 99%]
* Re: [PATCH] New major-mode: bicep-ts-mode
@ 2024-01-15 17:35 98% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-01-15 17:35 UTC (permalink / raw)
To: Stefan Monnier
Cc: Stefan Kangas, Jostein Kjønigsen, Daniel Mendler,
Ergus via Emacs development discussions., Yuan Fu,
Theodor Thornhill, Dmitry
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> Stefan Kangas [2024-01-09 11:16:36] wrote:
>> Jostein Kjønigsen <jostein@secure.kjonigsen.net> writes:
>>> I'd be more happy if we can make it part elpa.git, since that to me
>>> sounds like a better "home" for an Emacs-package, but I must admit I've
>>> never actually contributed a package directly to ELPA earlier.
>>>
>>> Is there a process I would need to follow, or could someone else help
>>> land it there, based on the source provided so far?
>>
>> See README in elpa.git and ask here if you have any questions.
>>
>> I think you should apply for commit access for this workflow to be
>> really practical. Stefan M, is that correct?
>
> Yes, but doesn't Jostein already have it? IIRC the alternative was to
> host the major mode in `emacs.git` and Jostein has two other major
> modes in `emacs.git`, so how does he maintain those?
Did I miss something (see also <87bk9us421.fsf@posteo.net>), or what is
the reason for not taking the usual route of mirroring some external
repository, as is some with the vast majority of ELPA packages.
>
>
> Stefan
^ permalink raw reply [relevance 98%]
* Re: [ELPA] New package: jami-bot and org-jami-bot
@ 2024-01-15 7:06 66% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-01-15 7:06 UTC (permalink / raw)
To: Hanno Perrey; +Cc: Stefan Kangas, emacs-devel
[-- Attachment #1: Type: text/plain, Size: 297 bytes --]
Hanno Perrey <hanno@hoowl.se> writes:
> Hej Philip,
>
> I have now modified the code according to your suggestions and pushed
> the changes.
[...]
The sharp-quoting was my mistake, I misread the hooks as functions.
Other than that, here is a diff with the remaining changes I would
propose:
[-- Attachment #2: Type: text/plain, Size: 2710 bytes --]
diff --git a/jami-bot.el b/jami-bot.el
index 8ad3ed0..5ea9aad 100644
--- a/jami-bot.el
+++ b/jami-bot.el
@@ -1,6 +1,6 @@
;;; jami-bot.el --- An extendable chat bot for the private messenger GNU Jami -*- lexical-binding: t; -*-
-;; Copyright (C) 2023 Free Software Foundation, Inc.
+;; Copyright (C) 2023, 2024 Free Software Foundation, Inc.
;; Author: Hanno Perrey <http://gitlab.com/hperrey>
;; Maintainer: Hanno Perrey <hanno@hoowl.se>
@@ -73,14 +73,14 @@ consist of a single (lowercase) word. The corresponding function needs to
accept the account id, the conversation id and the message alist as
arguments and return a string (that is sent as reply to the original message)."
:group 'jami-bot
- :type '(alist :key-type 'string :value-type 'function))
+ :type '(alist :key-type string :value-type function))
(defcustom jami-bot-text-message-functions nil
"A list of functions that will be called when processing a plain text message.
Functions must take the ACCOUNT and CONVERSATION ids as well as
the actual MSG as arguments. Their return value will be ignored."
:group 'jami-bot
- :type '(group 'function))
+ :type '(group function))
(defcustom jami-bot-download-path "~/jami/"
"Path in which to store files downloaded from conversations.
@@ -95,9 +95,9 @@ Functions must take the ACCOUNT and CONVERSATION ids as well as
the actual MSG and the local downloaded file name, DLNAME, as
arguments. Their return value will be ignored."
:group 'jami-bot
- :type '(group 'function))
+ :type '(group function))
-;; Internal variables
+;;;; Internal variables
(defvar jami-bot--jami-local-account-ids nil
"List of `jami' local accounts user ids and name pairs.
@@ -105,7 +105,7 @@ arguments. Their return value will be ignored."
Caches output of dbus-methods \"getAccountList\" and
\"getAccountDetails\". For internal use in `jami-bot'.")
-;; Functions
+;;;; Functions
(defun jami-bot--messageReceived-handler (account conversation msg)
"Handle messages from Jami's `messageReceived' D-Bus signal.
@@ -254,7 +254,9 @@ corresponding ids to which the message MSG belongs to."
(filename (cadr (assoc-string "displayName" msg)))
(dlpath (file-name-as-directory
(expand-file-name jami-bot-download-path)))
- (dlname (concat dlpath (format-time-string "%Y%m%d-%H%M") "_" filename)))
+ (dlname (expand-file-name
+ (concat (format-time-string "%Y%m%d-%H%M") "_" filename)
+ dlpath)))
(unless (file-directory-p dlpath) (make-directory dlpath 't))
(message "jami-bot: downloading file %s" dlname)
(jami-bot--dbus-cfgmgr-call-method "downloadFile" account conversation id fileid dlname)
[-- Attachment #3: Type: text/plain, Size: 60 bytes --]
> Thanks again for the feedback!
>
> Best wishes,
> Hanno
^ permalink raw reply related [relevance 66%]
* Re: Is it better to add treesitter modes to core?
@ 2024-01-09 20:21 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-01-09 20:21 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: dmitry, stefankangas, emacs-devel, stephen_leake
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: dmitry@gutov.dev, stefankangas@gmail.com, emacs-devel@gnu.org,
>> stephen_leake@stephe-leake.org
>> Date: Tue, 09 Jan 2024 19:27:50 +0000
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> >> From: Philip Kaludercic <philipk@posteo.net>
>> >> Cc: Stefan Kangas <stefankangas@gmail.com>, emacs-devel@gnu.org, Stephen
>> >> Leake <stephen_leake@stephe-leake.org>
>> >> Date: Mon, 08 Jan 2024 06:15:07 +0000
>> >>
>> >> > Possible grammar versioning problems. But the above should be small
>> >> > and stable enough, nor should they require many changes over the
>> >> > years.
>> >>
>> >> I don't think this has to be a problem. Last year I had suggested that
>> >> `treesit-install-language-grammar' should download release GitHub
>> >> tarballs, not just clone the repository (which requires Git, and is
>> >> prone to upstream breakage).
>> >
>> > Alas, this solution is incomplete, because some grammar libraries
>> > don't have releases at all.
>>
>> Most if not all git forges should support requesting an archive for a
>> specific commit (basically git-archive over https). For example, this
>> will provide a tarball for the current newest commit for the python
>> tree-sitter library:
>>
>> https://github.com/tree-sitter/tree-sitter-python/archive/4bfdd9033a2225cc95032ce77066b7aeca9e2efc.tar.gz
>
> I was responding to the suggestion to download release tarballs.
Then I misunderstood you, my argument is just that we could avoid
grammar versioning issues by fetching specific revisions (be it by
commits or by releases), and that we don't even have to use git for
that.
^ permalink raw reply [relevance 99%]
* Re: [ELPA] New package: jami-bot and org-jami-bot
@ 2024-01-09 19:39 90% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-01-09 19:39 UTC (permalink / raw)
To: Stefan Kangas; +Cc: Hanno Perrey, emacs-devel
Stefan Kangas <stefankangas@gmail.com> writes:
> Hanno Perrey <hanno@hoowl.se> writes:
>
>> I would like to propose two tightly-coupled packages for inclusion into
>> ELPA: jami-bot and org-jami-bot.
>>
>> jami-bot is an extendable chat bot for the distributed, private
>> messenger Jami. It interacts with the locally-installed Jami daemon via
>> D-Bus and reacts to both plain text messages and file transfers sent to
>> local accounts.
>>
>> org-jami-bot builds upon jami-bot and extends it with Org mode capture
>> functionality for text messages and images. It allows to schedule agenda
>> items at specific dates, compose multi-measure captures and capture
>> images -- all by sending a message via the GNU Jami messenger.
>>
>> I would like to keep maintaining both packages at their current
>> repositories:
>>
>> - https://gitlab.com/hperrey/jami-bot
>> - https://gitlab.com/hperrey/org-jami-bot
>>
>> I have signed the copyright paperwork with the FSF already and changed
>> the copyright in the respective files for both packages.
>>
>> As this is the first time I am proposing a package for ELPA, any
>> guidance on the process and feedback would be highly welcome!
>
> Philip, could you please help add these packages to GNU ELPA?
>
> The copyright assignment is all taken care of.
Sure, but first Hanno could you bump the version header, so that the
ELPA build system uses a newer commit, that includes the stylistic
changes + the updated copyright line?
A few comments from my side:
- It seems like a few variable (`jami-bot-account-user-names'?) would be
nice to have as proper user options, defined with `defcustom' and a
type.
- Try to sharp-quote (#') function symbols.
- If possible, try to join file paths using functions like
`expand-file-name' with `default-directory' set, instead of using
"low-level" string-manipulation.
- There seem to be some indentation issues (jami-bot-send-message), try
running `indent-region' on the entire buffer.
- There are a few minor checkdoc issues, consider resolving them.
^ permalink raw reply [relevance 90%]
* Re: Is it better to add treesitter modes to core?
@ 2024-01-09 19:27 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-01-09 19:27 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: dmitry, stefankangas, emacs-devel, stephen_leake
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: Stefan Kangas <stefankangas@gmail.com>, emacs-devel@gnu.org, Stephen
>> Leake <stephen_leake@stephe-leake.org>
>> Date: Mon, 08 Jan 2024 06:15:07 +0000
>>
>> > Possible grammar versioning problems. But the above should be small
>> > and stable enough, nor should they require many changes over the
>> > years.
>>
>> I don't think this has to be a problem. Last year I had suggested that
>> `treesit-install-language-grammar' should download release GitHub
>> tarballs, not just clone the repository (which requires Git, and is
>> prone to upstream breakage).
>
> Alas, this solution is incomplete, because some grammar libraries
> don't have releases at all.
Most if not all git forges should support requesting an archive for a
specific commit (basically git-archive over https). For example, this
will provide a tarball for the current newest commit for the python
tree-sitter library:
https://github.com/tree-sitter/tree-sitter-python/archive/4bfdd9033a2225cc95032ce77066b7aeca9e2efc.tar.gz
^ permalink raw reply [relevance 99%]
* Re: [PATCH] New major-mode: bicep-ts-mode
@ 2024-01-09 19:24 95% ` Philip Kaludercic
1 sibling, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-01-09 19:24 UTC (permalink / raw)
To: Jostein Kjønigsen
Cc: Stefan Monnier, Stefan Kangas, Daniel Mendler,
Ergus via Emacs development discussions., Yuan Fu,
Theodor Thornhill, Dmitry
Jostein Kjønigsen <jostein@secure.kjonigsen.net> writes:
> On 09.01.2024 01:33, Stefan Monnier wrote:
>>> OK, let's go with GNU ELPA.
>>> Could you set up the repository and let us know where it is?
>>> Then we can add it.
>> Of course, we can also host it directly in `elpa.git`.
>>
>>
>> Stefan
>>
> Before reading this email, I created this bare-bones repo:
> https://github.com/josteink/bicep-ts-mode
>
> I'd be more happy if we can make it part elpa.git, since that to me
> sounds like a better "home" for an Emacs-package, but I must admit
> I've never actually contributed a package directly to ELPA earlier.
Most packages on ELPA are not primarily hosted inside of elpa.git, but
just mirrored, see
https://git.savannah.gnu.org/cgit/emacs/elpa.git/tree/elpa-packages
So this doesn't have to be a concern, it would be simpler to use an
external repository that you already have access to.
> Is there a process I would need to follow, or could someone else help
> land it there, based on the source provided so far?
>
> --
> Jostein
^ permalink raw reply [relevance 95%]
* Re: Is it better to add treesitter modes to core?
@ 2024-01-08 6:15 90% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-01-08 6:15 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: Stefan Kangas, emacs-devel, Stephen Leake
Dmitry Gutov <dmitry@gutov.dev> writes:
> On 07/01/2024 19:46, Stefan Kangas wrote:
>> Dmitry <dmitry@gutov.dev> writes:
>>
>>> On Sun, Jan 7, 2024, at 2:34 PM, Philip Kaludercic wrote:
>>>> What I am wondering, is if this simplification were to take place, if it
>>>> would be possible to add ada-mode (or ada-ts-mode in that case) back to
>>>> the core?
>>> What is this fetish of adding everything to the core?
>>> ELPA is just one 'M-x package-install' away.
>> In Emacs, whatever real work you need to do, it's often the case
>> that
>> "it's just one M-x package-install" away.
>
> That's right. It doesn't work for every purpose, though. Not for
> infrastructure packages (which we expect to be used by other
> packages), nor for features that we want to have enabled by default.
>
>> I see little reason for that.
>
> You don't want ELPA to be used?
>
>> In my ideal world, we should have basic editing support in place in
>> Emacs for typical tasks, and packages should provide extensions. Most
>> users don't particularly enjoy starting work with installing a bunch of
>> extras.
>
> The way VS Code works and its level of popularity seem to say otherwise.
One notable difference is that VS Code prompts users to install the
necessary packages, while with Emacs one has to figure out what to
install (and how to install it in the case of ada-mode).
>> Take a look at how much better things are elsewhere and weep:
>> https://github.com/vim/vim/tree/master/runtime/syntax
>> Yes, vim is different, their job is easier and so on and so forth.
>
> It is only better if the features provided in there are reasonably
> complete and well-maintained.
>
> Also note that in no cases Vim bundles advanced completion
> functionality of the kind that Ada-mode has. It's much bigger than any
> of the files in the above dir.
>
>> But
>> also consider that treesitter modes are looking far easier to maintain
>> than some of the behemoths we have sometimes had to write in ELisp.
>
> And yet the Vim repository doesn't have any tree-sitter integration,
> it's all third-party. I don't think we'll see it there anytime soon
> (or even in the medium term).
I don't know how to check this, but didn't Neovim have built-in
tree-sitter support?
>> We might not want _all_ language support in Emacs, but for the main
>> languages: why would we _not_ want it? While I appreciate the
>> importance of workflow related arguments, from the end users point of
>> view, it really is a no-brainer which way is better.
>
> I don't really mind having the major modes for most popular languages
> in here, because in those cases the problem of extra traffic is offset
> by the advantage that one can see a problem and contribute a fix that
> will go out to help a lot of people. Even if I don't use a language in
> question myself. But doing that with languages that are unfamiliar to
> most contributors, and have small audience, is questionable.
>
>> This doesn't only apply to prog-modes, but also many text-modes. Take a
>> look at toml-ts-mode.el for example, and tell me one reason why it
>> shouldn't be in Emacs core. Markdown. YAML. Stuff like that.
>
> Possible grammar versioning problems. But the above should be small
> and stable enough, nor should they require many changes over the
> years.
I don't think this has to be a problem. Last year I had suggested that
`treesit-install-language-grammar' should download release GitHub
tarballs, not just clone the repository (which requires Git, and is
prone to upstream breakage).
>>> And Ada is niche enough that even the argument of having the popular
>>> languages supported OOtB doesn't work.
>> I think historical context matters here. Ada is not exactly in
>> vogue
>> these days, but it _is_ supported by GCC, and it has an ISO standard.
>> It's not some random novelty language for people that feel that
>> Typescript is not edgy enough, or anything like that.
>> We also happened to support it in Emacs for ages.
>
> And it's still there in ELPA, available for everybody to install.
>
> Note that I don't mean to belittle Stephen's work, nor have any desire
> to throw it away, but the sentiment "it's unmaintained, let's bring it
> in the core and see what happens" sounds very wrong to me.
Just to clarify, my question was what people would think of adding
ada-mode back to the core, if it were simplified using tree sitter.
> It would be a good idea for the interested parties to pay more
> attention to ELPA and improve it there. And if we really want basic
> support for Ada in the core, one could extract the "traditional" major
> mode from it. Or perhaps start anew and implement the tree-sitter
> based mode. Since there is an existing (LSP) language server, Eglot
> could be used for the IDE features. And then it would be easier to
> compare the feature sets.
^ permalink raw reply [relevance 90%]
* Re: Ada-mode to be abandoned?
@ 2024-01-07 16:48 96% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-01-07 16:48 UTC (permalink / raw)
To: Fernando Oleo Blanco; +Cc: emacs-devel, Stephen Leake
Fernando Oleo Blanco <irvise_ml@irvise.xyz> writes:
> ada-mode, as it currently stands, requires compiling some Ada code in
> order for it to work. It comes with some helper scripts for that task.
> However, the experience to get it working is not as nice as with other
> packages due to the compilation step. One cannot simply install it and
> just M-x ada-mode...
On this point, I believe it could be improved if `ada-mode' could check
if the necessary programs are installed, and otherwise try to build them
on its own (as other packages do, e.g. pdf-tools). Playing around with
ada-mode today, I just got an error message after error message, having
to guess what packages, dependencies and package managers to install,
that I ended up writing my code in fundamental mode, which I find sad.
--
Philip Kaludercic
^ permalink raw reply [relevance 96%]
* Re: Ada-mode to be abandoned?
@ 2024-01-07 16:26 85% ` Philip Kaludercic
1 sibling, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-01-07 16:26 UTC (permalink / raw)
To: Dmitry; +Cc: emacs-devel, Stephen Leake
Dmitry <dmitry@gutov.dev> writes:
> On Sun, Jan 7, 2024, at 2:34 PM, Philip Kaludercic wrote:
>> What I am wondering, is if this simplification were to take place, if it
>> would be possible to add ada-mode (or ada-ts-mode in that case) back to
>> the core?
> What is this fetish of adding everything to the core?
For me it is usually just that it is easier for a newcomer to get stuff
working, without having to deal with package management, which can be a
bother when working offline or in isolated environments. TBH
tree-sitter complicates this somewhat, because the grammars are not
installed along with Emacs or by the system, but that is a different
issue.
> ELPA is just one 'M-x package-install' away.
>
> And Ada is niche enough that even the argument of having the popular
> languages supported OOtB doesn't work.
There are plenty of languages that are niche and supported OOtB,
especially since the introduction of tree-sitter (I for example am not
familiar with "heex"). If I were to consider helping out with
maintaining the major mode -- where my main disinclination is just the
lack of experience I have with Ada -- I'd prefer to maintain it inside
the core, because if nothing else it makes it easier for others to help
out with bugs/mistakes and use the newest features.
Either way, the current state of `ada-mode' is in my experience in no
way satisfactory, and I believe that this kind of issue is less likely
to happen inside the core.
--
Philip Kaludercic
^ permalink raw reply [relevance 85%]
* Ada-mode to be abandoned?
@ 2024-01-07 12:34 79% Philip Kaludercic
0 siblings, 2 replies; 200+ results
From: Philip Kaludercic @ 2024-01-07 12:34 UTC (permalink / raw)
To: emacs-devel; +Cc: Stephen Leake
I recently came across this message on the ada-mode-users' mailing list:
https://lists.nongnu.org/archive/html/ada-mode-users/2023-11/msg00000.html
Stephen (the maintainer, in the CC's) indicates that he would like to
retire from maintenance, which might mean that the package could become
abandon-ware.
One note he makes is that the current implementation could be
simplified, by just using tree-sitter, instead of the approach that
makes use of a custom parser:
--8<---------------cut here---------------start------------->8---
2) Drop the wisitoken parser generator and runtime, use tree-sitter
instead. This requires writing a wrapper for tree-sitter to match
the wisitoken syntax-tree API; then the current wisi indentation
code can be used.
This maintains all of the ada-mode features, while reducing the
maintenance burden significantly.
I believe the tree-sitter error correction is less powerful than
wisitoken, but it would be interesting to see if that matters in
practice.
--8<---------------cut here---------------end--------------->8---
What I am wondering, is if this simplification were to take place, if it
would be possible to add ada-mode (or ada-ts-mode in that case) back to
the core? I would be glad to help out, since I've been interested in
working with Ada for a while but never got it to work, I have just been
struggling with understanding how `treesit-font-lock-rules' is supposed
to be used, so some help would be appreciated.
--
Philip Kaludercic
^ permalink raw reply [relevance 79%]
* Re: man broken?
2024-01-03 15:45 88% ` Philip Kaludercic
@ 2024-01-03 15:48 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2024-01-03 15:48 UTC (permalink / raw)
To: Michael Albinus; +Cc: Visuwesh, T.V Raman, emacs-devel
Philip Kaludercic <philipk@posteo.net> writes:
> Michael Albinus <michael.albinus@gmx.de> writes:
>
>> Visuwesh <visuweshm@gmail.com> writes:
>>
>> Hi,
>>
>>> 1. emacs -Q
>>> 2. M-: (require 'tramp-adb) RET
>>> 3. M-x man RET ls RET
>>>
>>> This seems to be because connection-local-profile-alist has the adb
>>> configuration which sets shell-file-name to "/system/bin/sh".
>>
>> Thanks for the recipe. I'll work on it when my health condition is going
>> better, hopefully next days.
>
> Could it be that this is the issue:
>
> diff --git a/lisp/files-x.el b/lisp/files-x.el
> index 41d9cd3bab8..1911afe43e0 100644
> --- a/lisp/files-x.el
> +++ b/lisp/files-x.el
> @@ -1,6 +1,6 @@
> ;;; files-x.el --- extended file handling commands -*- lexical-binding: t; -*-
>
> -;; Copyright (C) 2009-2023 Free Software Foundation, Inc.
> +;; Copyright (C) 2009-2024 Free Software Foundation, Inc.
>
> ;; Author: Juri Linkov <juri@jurta.org>
> ;; Maintainer: emacs-devel@gnu.org
> @@ -704,7 +704,7 @@ connection-local-get-profiles
> profiles)
> (dolist (crit-alist connection-local-criteria-alist)
> (let ((crit criteria)
> - (match t))
> + (match nil))
> (while (and crit match)
> (when (plist-member (car crit-alist) (car crit))
> (setq match (equal (plist-get (car crit-alist) (car crit))
>
>
> I am not quite sure what is going on in the function, but the invariant
> is that match is always non-nil after the loop is done, which seems
> suspicious to me.
Never mind the last sentence, match can be nil if `equal' returns nil at
some point, but that doesn't happen locally since `criteria' is nil.
>> Best regrds, Michael.
^ permalink raw reply [relevance 99%]
* Re: man broken?
@ 2024-01-03 15:45 88% ` Philip Kaludercic
2024-01-03 15:48 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2024-01-03 15:45 UTC (permalink / raw)
To: Michael Albinus; +Cc: Visuwesh, T.V Raman, emacs-devel
[-- Attachment #1: Type: text/plain, Size: 461 bytes --]
Michael Albinus <michael.albinus@gmx.de> writes:
> Visuwesh <visuweshm@gmail.com> writes:
>
> Hi,
>
>> 1. emacs -Q
>> 2. M-: (require 'tramp-adb) RET
>> 3. M-x man RET ls RET
>>
>> This seems to be because connection-local-profile-alist has the adb
>> configuration which sets shell-file-name to "/system/bin/sh".
>
> Thanks for the recipe. I'll work on it when my health condition is going
> better, hopefully next days.
Could it be that this is the issue:
[-- Attachment #2: Type: text/plain, Size: 796 bytes --]
diff --git a/lisp/files-x.el b/lisp/files-x.el
index 41d9cd3bab8..1911afe43e0 100644
--- a/lisp/files-x.el
+++ b/lisp/files-x.el
@@ -1,6 +1,6 @@
;;; files-x.el --- extended file handling commands -*- lexical-binding: t; -*-
-;; Copyright (C) 2009-2023 Free Software Foundation, Inc.
+;; Copyright (C) 2009-2024 Free Software Foundation, Inc.
;; Author: Juri Linkov <juri@jurta.org>
;; Maintainer: emacs-devel@gnu.org
@@ -704,7 +704,7 @@ connection-local-get-profiles
profiles)
(dolist (crit-alist connection-local-criteria-alist)
(let ((crit criteria)
- (match t))
+ (match nil))
(while (and crit match)
(when (plist-member (car crit-alist) (car crit))
(setq match (equal (plist-get (car crit-alist) (car crit))
[-- Attachment #3: Type: text/plain, Size: 184 bytes --]
I am not quite sure what is going on in the function, but the invariant
is that match is always non-nil after the loop is done, which seems
suspicious to me.
> Best regrds, Michael.
^ permalink raw reply related [relevance 88%]
* Re: A new collaborative editing package (maybe tangent)
@ 2023-12-30 10:56 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-12-30 10:56 UTC (permalink / raw)
To: Karl Fogel; +Cc: Yuan Fu, emacs-devel
Karl Fogel <kfogel@red-bean.com> writes:
> On 29 Dec 2023, Yuan Fu wrote:
>> I’ve been working on a collaborative editing package on-and-off for
>> a
>> while. I call it collab-mode. It’s far from complete but I want to
>>gather some early feedback (and find some people to test it).
>>
>>Yes, another collab editing package. I know there’s a pile of
>> abandoned collab editing packages already, and whether it’s really
>>very useful is questionable in the age of google docs.
>
> There is no question at all about its usefulness! Having a reliable,
> usable, and easy-to-install Emacs package for collaborative editing
> would be amazing. Even if it were to only support Emacs<->Emacs it
> would be a great thing; if it allows collaborative editing with people
> using other editors, then it will make the stars shine and the moon
> sing.
Just because it doesn't appear to be mentioned, are you familiar with
the CRDT package on GNU ELPA? My understanding is that it is not
compatible with other editors, due to limits in the API they expose, but
it does provide P2P collaboration.
^ permalink raw reply [relevance 99%]
* Re: man broken?
@ 2023-12-29 19:38 99% ` Philip Kaludercic
1 sibling, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-12-29 19:38 UTC (permalink / raw)
To: Michael Albinus; +Cc: T.V Raman, emacs-devel
Michael Albinus <michael.albinus@gmx.de> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
> Hi Philip,
Hi,
>>>> Invoking man M-x man on any program, eg ls returns error:
>>>>
>>>> Invalid function: connection-local-value
>>>>
>>>> appears to be due to tramp related logic in man-shell-file-name
>>>
>>> connection-local-value is a new macro. So you need to recompile
>>> man.el. Since it is used somewhere else as well, 'make bootstrap' might
>>> be the best option.
>>
>> I've been having another issue, whatever man page I try to open I get a
>>
>> /system/bin/sh: No such file or directory
>>
>> error message, because
>>
>> (connection-local-value shell-file-name) => "/system/bin/sh"
>>
>> I haven't reported it as a bug yet, because I cannot reproduce it in
>> emacs -Q, and I haven't found any useful information to help debugging
>> the issue.
>>
>> Perhaps you have some ideas that could help me prepare a bug report?
>
> Im don't get it. Have you tried 'make bootstrap' Could you pls tell what
> hayou done, starting with "emacs -Q"?
I did try make bootstrap, and it didn't work, but I cannot reproduce the
issue with emacs -Q either, so my configuration is apparently playing a
part in the issue.
> Best regards, Michael.
^ permalink raw reply [relevance 99%]
* Re: man broken?
@ 2023-12-28 9:48 97% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-12-28 9:48 UTC (permalink / raw)
To: Michael Albinus; +Cc: T.V Raman, emacs-devel
Michael Albinus <michael.albinus@gmx.de> writes:
> "T.V Raman" <raman@google.com> writes:
>
> Hi,
>
>> Invoking man M-x man on any program, eg ls returns error:
>>
>> Invalid function: connection-local-value
>>
>> appears to be due to tramp related logic in man-shell-file-name
>
> connection-local-value is a new macro. So you need to recompile
> man.el. Since it is used somewhere else as well, 'make bootstrap' might
> be the best option.
I've been having another issue, whatever man page I try to open I get a
/system/bin/sh: No such file or directory
error message, because
(connection-local-value shell-file-name) => "/system/bin/sh"
I haven't reported it as a bug yet, because I cannot reproduce it in
emacs -Q, and I haven't found any useful information to help debugging
the issue.
Perhaps you have some ideas that could help me prepare a bug report?
> Best regards, Michael.
^ permalink raw reply [relevance 97%]
* Re: cond*
@ 2023-12-27 14:34 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-12-27 14:34 UTC (permalink / raw)
To: Richard Stallman; +Cc: 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. ]]]
>
> > Having a rough prototype of an implementation would still be useful to
> > have, to get a better felling of what the macro should look and feel
> > like.
>
> Yes, it might do that. Would you like to help write it?
> I think some parts of the pcase code could be adapted.
I have some time and could try it out. Can you link me to the most
current specification?
> > E.g. from reading your messages, I am
> > still not sure how `cond*' and `match' are supposed to interact with one
> > another.
>
> `match*' is not an independent construct defined on its own.
> It is meaningful only within a cond* construct. In effect,
> it marks a certain part of the cond*.
>
> If someone can figure out a way that `match*' could be meaningful on
> its own, whi;e also working together with `cond*' so that the two
> function together as desired, that would be a neat hack. But I'm not
> aiming for that.
I agree, that would be interesting to have.
^ permalink raw reply [relevance 99%]
* Re: Manuals for GNU ELPA packages
@ 2023-12-27 13:47 99% ` Philip Kaludercic
2024-02-26 10:49 84% ` Philip Kaludercic
1 sibling, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-12-27 13:47 UTC (permalink / raw)
To: Michael Albinus; +Cc: Kjartan Óli Ágústsson, emacs-devel@gnu.org
Michael Albinus <michael.albinus@gmx.de> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
> Hi Philip,
>
>> ... then the documentation should be packaged in
>> the tarball and also appear online under
>> https://elpa.gnu.org/packages/doc/calibre.html.
>
> On https://elpa.gnu.org/packages/doc/, there is a directory of all
> manuals, plus the README of plz.el. The latter is wrong here, I guess.
That is true, but it appears that the file is being regenerated
regularly, so this is probably an issue with elpa-admin.el. I'll look
into it.
> Best regards, Michael.
^ permalink raw reply [relevance 99%]
* Re: [elpa] externals/ellama 3b077c0842 4/7: Call ellama-setup-keymap on prefix change
[not found] ` <20231225205746.E0F24C004EC@vcs2.savannah.gnu.org>
@ 2023-12-26 17:18 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-12-26 17:18 UTC (permalink / raw)
To: emacs-devel; +Cc: Sergey Kostyaev
ELPA Syncer <elpasync@gnu.org> writes:
> branch: externals/ellama
> commit 3b077c0842941fa96295705b8414df628c25419c
> Author: Sergey Kostyaev <kostyaev.sergey2@wb.ru>
> Commit: Sergey Kostyaev <kostyaev.sergey2@wb.ru>
>
> Call ellama-setup-keymap on prefix change
> ---
> NEWS.org | 3 +++
> ellama.el | 6 +++++-
> 2 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/NEWS.org b/NEWS.org
> index bf97cb2c43..3fddc7a6bb 100644
> --- a/NEWS.org
> +++ b/NEWS.org
> @@ -1,3 +1,6 @@
> +* Version 0.4.10
> +- Add customization group.
> +- Call ellama-setup-keymap on prefix change.
> * Version 0.4.9
> - Call fill-region only for non-programming modes.
> * Version 0.4.8
> diff --git a/ellama.el b/ellama.el
> index 98e19337af..0bf1dec827 100644
> --- a/ellama.el
> +++ b/ellama.el
> @@ -6,7 +6,7 @@
> ;; URL: http://github.com/s-kostyaev/ellama
> ;; Keywords: help local tools
> ;; Package-Requires: ((emacs "28.1") (llm "0.6.0") (spinner "1.7.4"))
> -;; Version: 0.4.9
> +;; Version: 0.4.10
> ;; SPDX-License-Identifier: GPL-3.0-or-later
> ;; Created: 8th Oct 2023
>
> @@ -97,6 +97,10 @@
> (defcustom ellama-keymap-prefix "C-c e"
> "Key sequence for Ellama Commands."
> :type 'string
> + :set (lambda (symbol value)
> + (set symbol value)
AFAIK it is better to use a function like `set-default' or even
`custom-set-default'.
> + (when value
> + (ellama-setup-keymap)))
> :group 'ellama)
>
> (defcustom ellama-ollama-binary (executable-find "ollama")
^ permalink raw reply [relevance 99%]
* Re: Manuals for GNU ELPA packages
@ 2023-12-26 17:17 89% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-12-26 17:17 UTC (permalink / raw)
To: Kjartan Óli Ágústsson; +Cc: emacs-devel@gnu.org
[-- Attachment #1: Type: text/plain, Size: 584 bytes --]
Kjartan Óli Ágústsson <kjartanoli@outlook.com> writes:
> Some time ago my calibre package
> (https://elpa.gnu.org/packages/calibre.html) was added to GNU ELPA.
> Shortly after that I made my first attempt to write a Texinfo manual for
> the package. When I look at the tarball downloaded from ELPA I see the
> texi files are there but there are no info files. Does the ELPA package
> specification need to be updated, or did I do something wrong when
> adding the manual to my repository?
Yes, the package specification needs a new :doc attribute, something
like
[-- Attachment #2: Type: text/plain, Size: 543 bytes --]
diff --git a/elpa-packages b/elpa-packages
index 858948422f..8faa74d12b 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -123,7 +123,8 @@
;; :doc "cc-mode.texi"))
(buildbot :url "https://g.ypei.me/buildbot.el.git"
:readme "README.org")
- (calibre :url "https://git.disroot.org/kjartanoli/calibre.el")
+ (calibre :url "https://git.disroot.org/kjartanoli/calibre.el"
+ :doc "doc/calibre.tex")
(cape :url "https://github.com/minad/cape"
:doc "README.org"
:news "CHANGELOG.org"
[-- Attachment #3: Type: text/plain, Size: 301 bytes --]
Just note that the file extension .tex is wrong here, since this is not
a regular TeX or LaTeX file. If you rename it to .texi and we then
update the specification, then the documentation should be packaged in
the tarball and also appear online under
https://elpa.gnu.org/packages/doc/calibre.html.
^ permalink raw reply related [relevance 89%]
* Re: cond*
@ 2023-12-25 12:32 95% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-12-25 12:32 UTC (permalink / raw)
To: Richard Stallman; +Cc: 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. ]]]
>
> I'm going to finish designing the specs of cond* before trying to
> implement it. To implement each of the different spec versions
> would have been a lot more work than is really necessary.
Having a rough prototype of an implementation would still be useful to
have, to get a better felling of what the macro should look and feel
like. An advantage of `pcase' (as with Emacs) is that it is extensible
and can be adapted to new needs. My fear is that if `cond*' is conjured
up in our minds, it is easy to misunderstand the needs in practice, or
if it really will be easier to use. E.g. from reading your messages, I am
still not sure how `cond*' and `match' are supposed to interact with one
another.
^ permalink raw reply [relevance 95%]
* Re: Making package.el talk over Tor
@ 2023-12-24 15:19 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-12-24 15:19 UTC (permalink / raw)
To: Tomas Hlavaty; +Cc: rms, emacs-devel
Tomas Hlavaty <tom@logand.com> writes:
> On Sat 23 Dec 2023 at 22:57, Richard Stallman <rms@gnu.org> wrote:
>> > >> > '(url-proxy-services
>> > >> > '(("no_proxy" . "localhost")
>> > >> > ("http" . "127.0.0.1:8118")
>> > >> > ("https" . "127.0.0.1:8118")))
>>
>> Is there a reason for using the number 9118?
>
> in my case:
> 8118 has privoxy running
> so it looks like this:
> emacs -> 8118 privoxy -> 9050 tor
>
> 8118 is a HTTP proxy
> 9050 is a socks proxy
>
>> Tor's default seems to
>> be 9050; if I specify that number here, would it work
>> without changing /etc/tor/torrc?
>
> I don't think so.
>
> iirc emacs using socks proxy did not work for me
Do you recall what your configuration was. I gave an example earlier on
in this thread, but noticed that url wouldn't redirect all messages over
the SOCKS proxy.
> emacs using http proxy works fine
> and I can have other rules in privoxy
> which I do not thing is possible to specify directly in emacs
> without changing emacs
^ permalink raw reply [relevance 99%]
* Re: [ELPA] New package devicetree-ts-mode
@ 2023-12-22 7:36 65% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-12-22 7:36 UTC (permalink / raw)
To: Aleksandr Vityazev; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 291 bytes --]
Aleksandr Vityazev <avityazew@gmail.com> writes:
> Hello,
>
> I'd like to submit devicetree-ts-mode [1] to GNU ELPA.
> This is tree-sitter major mode for Devicetree [2] files.
>
> [1] https://git.sr.ht/~akagi/devicetree-ts-mode/
> [2] https://www.devicetree.org/
Here are a few comments:
[-- Attachment #2: Type: text/plain, Size: 3397 bytes --]
diff --git a/devicetree-ts-mode.el b/devicetree-ts-mode.el
index 1d9f72c..d26937c 100644
--- a/devicetree-ts-mode.el
+++ b/devicetree-ts-mode.el
@@ -33,6 +33,7 @@
;; * IMenu
;; * Font Lock
+;; The commentary section could elaborate on what "Devicetree" are.
;;; Code:
@@ -44,15 +45,21 @@
(declare-function treesit-parser-create "treesit.c")
(declare-function treesit-node-child-by-field-name "treesit.c")
+(defgroup devicetree ()
+ "Tree-sitter support for DTS."
+ :prefix "devicetree-ts-"
+ :group 'languages)
+
(defcustom devicetree-ts-mode-indent-offset 4
"Number of spaces for each indentation step in `devicetree-ts-mode'."
:version "29.1"
+ ;; This is not a core package, the version of your package is 0.2,
+ ;; so this doesn't match up
:type 'natnum
- :safe 'natnump
- :group 'devicetree)
+ :safe 'natnump)
;; Taken from the dts-mode
-(defvar devicetree-ts-mode--syntax-table
+(defvar devicetree-ts-mode-syntax-table
(let ((table (make-syntax-table)))
(modify-syntax-entry ?< "(>" table)
@@ -81,6 +88,10 @@
(defvar devicetree-ts-mode--indent-rules
(let ((offset devicetree-ts-mode-indent-offset))
+ ;; If this is a variable, that is set when the package is loaded,
+ ;; customising the user option `devicetree-ts-mode-indent-offset'
+ ;; will have no effect. You could turn this into a function
+ ;; instead.
`((devicetree
((node-is ">") parent-bol 0)
((node-is "]") parent-bol 0)
@@ -93,13 +104,14 @@
(no-node parent-bol 0))))
"Tree-sitter indent rules for `devicetree-ts-mode'.")
+;; Could these be defconst?
(defvar devicetree-ts-mode--treesit-keywords
'("/delete-node/" "/delete-property/" "#define" "#include"
"/omit-if-no-ref/" "/dts-v1/"))
(defvar devicetree-ts-mode--treesit-operators
- '( "!" "~" "-" "+" "*" "/" "%" "||" "&&" "|"
- "^" "&" "==" "!=" ">" ">=" "<=" ">" "<<" ">>"))
+ '("!" "~" "-" "+" "*" "/" "%" "||" "&&" "|"
+ "^" "&" "==" "!=" ">" ">=" "<=" ">" "<<" ">>"))
(defvar devicetree-ts-mode--font-lock-settings
(treesit-font-lock-rules
@@ -154,8 +166,8 @@
(defun devicetree-ts-mode--node-addresses (node)
"List of addresses for NODE."
- (reverse
- (seq-reduce
+ (reverse ;Why `reverse'? (or `nreverse'?)
+ (seq-reduce ;Isn't this a `seq-filter'?
(lambda (acc children)
(if (string-equal (treesit-node-field-name children)
"address")
@@ -175,8 +187,6 @@
;;;###autoload
(define-derived-mode devicetree-ts-mode prog-mode "DTS"
"Major mode for editing devicetree, powered by tree-sitter."
- :group 'devicetree
- :syntax-table devicetree-ts-mode--syntax-table
(when (treesit-ready-p 'devicetree)
(treesit-parser-create 'devicetree)
@@ -187,7 +197,7 @@
;; Imenu.
(setq-local treesit-simple-imenu-settings
- `((nil "\\`node\\'"
+ `((nil ,(rx bos "node" eos)
nil devicetree-ts--mode--name-function)))
(setq-local which-func-functions nil)
@@ -216,9 +226,8 @@
(treesit-major-mode-setup)))
-(if (treesit-ready-p 'devicetree)
- (add-to-list 'auto-mode-alist
- '("\\.dtsi?\\'" . devicetree-ts-mode)))
+(when (treesit-ready-p 'devicetree)
+ (add-to-list 'auto-mode-alist '("\\.dtsi?\\'" . devicetree-ts-mode)))
(provide 'devicetree-ts-mode)
;;; devicetree-ts-mode.el ends here
[-- Attachment #3: Type: text/plain, Size: 1151 bytes --]
>
> From b69687be8232cfd305893b7c0b6999e6667d6dd8 Mon Sep 17 00:00:00 2001
> Message-ID: <b69687be8232cfd305893b7c0b6999e6667d6dd8.1703075351.git.avityazew@gmail.com>
> From: Aleksandr Vityazev <avityazew@gmail.com>
> Date: Wed, 20 Dec 2023 15:28:35 +0300
> Subject: [PATCH] * elpa-packages (devicetree-ts-mode): New package
>
> ---
> elpa-packages | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/elpa-packages b/elpa-packages
> index 612bc676cd..6f86a59cfd 100644
> --- a/elpa-packages
> +++ b/elpa-packages
> @@ -207,6 +207,8 @@
> :news "CHANGELOG.org"
> :readme "README.md")
> (devdocs :url "https://github.com/astoff/devdocs.el")
> + (devicetree-ts-mode :url "https://sr.ht/~akagi/devicetree-ts-mode"
> + :ignored-files ("LICENSE"))
You can track this file in an .elpaignore file, within your repository
(which you appear to have anyway).
> (dict-tree :url nil) ;"http://www.dr-qubit.org/git/predictive.git"
> (diff-hl :url "https://github.com/dgutov/diff-hl.git")
> (diffview :url "https://github.com/mgalgs/diffview-mode.git")
>
> base-commit: b7bbd439862f2a58151eacacebc1815b7ddf3322
> --
> 2.41.0
^ permalink raw reply related [relevance 65%]
* Re: cond*
@ 2023-12-22 7:27 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-12-22 7:27 UTC (permalink / raw)
To: Richard Stallman; +Cc: 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. ]]]
>
> Fall-through clauses are an important feature of cond* and a big
> advance in flexibility. Precisely how to indicate one is a detail,
> and I've proposed three ways to design that:
>
> * A clause with one element.
> * A clause that starts with t.
> * A clause that starts with nil.
> * A keyword.
>
> If you have preferences about that detail, please let me know.
> I am also interested in other suggestions, but I will only accept
> it if it is as natural and simple as those above.
Have I missed something, or where is the source code for cond*.
Skimming through the messages, I don't quite understand how it is
supposed to work.
^ permalink raw reply [relevance 99%]
* Re: [elpa] main 080e09a4c6: * elpa-packages (spacious-padding): Add :doc, :news, and expand :ignored-files
[not found] ` <20231221073151.CF09CC00613@vcs2.savannah.gnu.org>
@ 2023-12-21 10:32 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-12-21 10:32 UTC (permalink / raw)
To: emacs-devel; +Cc: Protesilaos Stavrou
Protesilaos Stavrou <info@protesilaos.com> writes:
> branch: main
> commit 080e09a4c6f038818a5a7a9c5e53ff168e0fe00e
> Author: Protesilaos Stavrou <info@protesilaos.com>
> Commit: Protesilaos Stavrou <info@protesilaos.com>
>
> * elpa-packages (spacious-padding): Add :doc, :news, and expand :ignored-files
> ---
> elpa-packages | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/elpa-packages b/elpa-packages
> index 858948422f..f2c60cac5d 100644
> --- a/elpa-packages
> +++ b/elpa-packages
> @@ -638,8 +638,10 @@
> (sokoban :url nil)
> (sotlisp :url "https://github.com/Malabarba/speed-of-thought-lisp")
> (spacious-padding :url "https://git.sr.ht/~protesilaos/spacious-padding"
> + :doc "README.org"
> :readme "README.md"
> - :ignored-files ("COPYING"))
> + :news "CHANGELOG.org"
> + :ignored-files ("COPYING" "doclicense.texi"))
It would be better to track this in your repository, within a
.elpaignore file.
> (spinner :url "https://github.com/Malabarba/spinner.el")
> (sql-beeline :url nil)
> (sql-cassandra :url nil)
^ permalink raw reply [relevance 99%]
* Re: Making package.el talk over Tor
2023-12-21 9:52 99% ` Philip Kaludercic
@ 2023-12-21 9:55 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-12-21 9:55 UTC (permalink / raw)
To: Richard Stallman; +Cc: Tomas Hlavaty, emacs-devel
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. ]]]
>>
>> > (custom-set-variables
>> > '(url-cookie-confirmation nil)
>> > '(url-cookie-untrusted-urls '(".*"))
>> > '(url-gateway-method 'native)
>> > '(url-privacy-level 'paranoid)
>> > '(url-proxy-services
>> > '(("no_proxy" . "localhost")
>> > ("http" . "127.0.0.1:8118")
>> > ("https" . "127.0.0.1:8118")))
>
> For this to work, one has to add
>
> HTTPTunnelPort localhost:8118
* to /etc/tor/torrc
> and it only appears to work for https:// URLs, not unencrypted http://.
>
>> > '(url-queue-timeout 4)
>>
>> I will give that a try. Thanks.
>>
>> > why is this not a sufficient solution?
>>
>> I am the wrong person to ask. I don't have the background knowledge
>> to tell whether it solves the problem.
>
> You can use https://check.torproject.org/ to check, if the request goes
> through the Tor proxy, the page will say "Congratulations. This browser
> is configured to use Tor."
^ permalink raw reply [relevance 99%]
* Re: Making package.el talk over Tor
@ 2023-12-21 9:52 99% ` Philip Kaludercic
2023-12-21 9:55 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-12-21 9:52 UTC (permalink / raw)
To: Richard Stallman; +Cc: Tomas Hlavaty, 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. ]]]
>
> > (custom-set-variables
> > '(url-cookie-confirmation nil)
> > '(url-cookie-untrusted-urls '(".*"))
> > '(url-gateway-method 'native)
> > '(url-privacy-level 'paranoid)
> > '(url-proxy-services
> > '(("no_proxy" . "localhost")
> > ("http" . "127.0.0.1:8118")
> > ("https" . "127.0.0.1:8118")))
For this to work, one has to add
HTTPTunnelPort localhost:8118
and it only appears to work for https:// URLs, not unencrypted http://.
> > '(url-queue-timeout 4)
>
> I will give that a try. Thanks.
>
> > why is this not a sufficient solution?
>
> I am the wrong person to ask. I don't have the background knowledge
> to tell whether it solves the problem.
You can use https://check.torproject.org/ to check, if the request goes
through the Tor proxy, the page will say "Congratulations. This browser
is configured to use Tor."
^ permalink raw reply [relevance 99%]
Results 1-200 of ~1772 next (older) | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2023-10-16 2:04 Making package.el talk over Tor Richard Stallman
2023-10-16 6:54 ` Akib Azmain Turja
2023-11-17 3:53 ` Richard Stallman
2023-11-17 7:03 ` Philip Kaludercic
2023-11-19 3:39 ` Richard Stallman
2023-11-19 6:17 ` Eli Zaretskii
2023-12-09 4:06 ` Richard Stallman
2023-12-09 7:40 ` Eli Zaretskii
2023-12-13 4:58 ` Richard Stallman
2023-12-14 12:25 ` Philip Kaludercic
2023-12-17 3:21 ` Richard Stallman
2023-12-18 4:12 ` Richard Stallman
2023-12-18 8:05 ` Tomas Hlavaty
2023-12-21 4:20 ` Richard Stallman
2023-12-21 9:52 99% ` Philip Kaludercic
2023-12-21 9:55 99% ` Philip Kaludercic
2023-12-24 3:57 ` Richard Stallman
2023-12-24 13:36 ` Tomas Hlavaty
2023-12-24 15:19 99% ` Philip Kaludercic
2023-11-17 10:11 [Reminder]Decommissoned keyservers CHENG Gao via Emacs development discussions.
2023-11-17 21:15 ` Philip Kaludercic
2023-11-18 0:54 ` CHENG Gao via Emacs development discussions.
2024-02-11 17:39 88% ` Philip Kaludercic
2024-02-17 18:13 ` Stefan Kangas
2024-02-17 18:48 99% ` Philip Kaludercic
2023-12-12 3:43 Instead of pcase Richard Stallman
2023-12-13 1:32 ` Adam Porter
2023-12-16 4:23 ` Richard Stallman
2023-12-18 4:09 ` cond* Richard Stallman
2023-12-19 3:49 ` cond* Richard Stallman
2023-12-19 12:13 ` cond* João Távora
2023-12-22 3:14 ` cond* Richard Stallman
2023-12-22 7:27 99% ` cond* Philip Kaludercic
2023-12-25 3:41 ` cond* Richard Stallman
2023-12-25 12:32 95% ` cond* Philip Kaludercic
2023-12-27 4:54 ` cond* Richard Stallman
2023-12-27 14:34 99% ` cond* Philip Kaludercic
[not found] <170314391115.21254.4894167783688621192@vcs2.savannah.gnu.org>
[not found] ` <20231221073151.CF09CC00613@vcs2.savannah.gnu.org>
2023-12-21 10:32 99% ` [elpa] main 080e09a4c6: * elpa-packages (spacious-padding): Add :doc, :news, and expand :ignored-files Philip Kaludercic
2023-12-21 14:32 [PATCH] New major-mode: bicep-ts-mode Jostein Kjønigsen
2024-01-07 18:04 ` Daniel Mendler via Emacs development discussions.
2024-01-07 20:26 ` Stefan Kangas
2024-01-07 23:25 ` Stefan Monnier
2024-01-08 11:30 ` Jostein Kjønigsen
2024-01-08 19:23 ` Stefan Kangas
2024-01-09 0:33 ` Stefan Monnier
2024-01-09 19:12 ` Jostein Kjønigsen
2024-01-09 19:16 ` Stefan Kangas
2024-01-14 4:43 ` Stefan Monnier
2024-01-15 17:35 98% ` Philip Kaludercic
2024-01-09 19:24 95% ` Philip Kaludercic
2023-12-21 17:47 [ELPA] New package devicetree-ts-mode Aleksandr Vityazev
2023-12-22 7:36 65% ` Philip Kaludercic
2023-12-26 13:44 Manuals for GNU ELPA packages Kjartan Óli Ágústsson
2023-12-26 17:17 89% ` Philip Kaludercic
2023-12-27 8:41 ` Michael Albinus
2023-12-27 13:47 99% ` Philip Kaludercic
2024-02-26 10:49 84% ` Philip Kaludercic
2024-02-26 13:04 ` Stefan Monnier
2024-02-26 14:05 73% ` Philip Kaludercic
2024-02-26 15:03 ` Stefan Monnier
2024-02-26 15:27 99% ` Philip Kaludercic
[not found] <170353786620.20271.13080406788513813678@vcs2.savannah.gnu.org>
[not found] ` <20231225205746.E0F24C004EC@vcs2.savannah.gnu.org>
2023-12-26 17:18 99% ` [elpa] externals/ellama 3b077c0842 4/7: Call ellama-setup-keymap on prefix change Philip Kaludercic
2023-12-27 18:28 man broken? T.V Raman
2023-12-27 18:56 ` Michael Albinus
2023-12-28 9:48 97% ` Philip Kaludercic
2023-12-28 16:22 ` Michael Albinus
2023-12-29 19:38 99% ` Philip Kaludercic
2023-12-30 4:55 ` Visuwesh
2023-12-30 11:37 ` Michael Albinus
2024-01-03 15:45 88% ` Philip Kaludercic
2024-01-03 15:48 99% ` Philip Kaludercic
2023-12-28 11:21 [ELPA] New package: jami-bot and org-jami-bot Hanno Perrey
2024-01-07 21:01 ` Stefan Kangas
2024-01-09 19:39 90% ` Philip Kaludercic
2024-01-14 18:46 ` Hanno Perrey
2024-01-15 7:06 66% ` Philip Kaludercic
2024-01-17 7:59 ` Hanno Perrey
2024-01-17 23:39 97% ` Philip Kaludercic
2023-12-30 4:22 A new collaborative editing package (maybe tangent) Yuan Fu
2023-12-30 5:28 ` Karl Fogel
2023-12-30 10:56 99% ` Philip Kaludercic
2024-01-07 12:34 79% Ada-mode to be abandoned? Philip Kaludercic
2024-01-07 15:21 ` Dmitry
2024-01-07 16:26 85% ` Philip Kaludercic
2024-01-07 17:46 ` Is it better to add treesitter modes to core? Stefan Kangas
2024-01-07 21:27 ` Dmitry Gutov
2024-01-08 6:15 90% ` Philip Kaludercic
2024-01-08 12:47 ` Eli Zaretskii
2024-01-09 19:27 99% ` Philip Kaludercic
2024-01-09 19:54 ` Eli Zaretskii
2024-01-09 20:21 99% ` Philip Kaludercic
2024-01-07 16:29 ` Ada-mode to be abandoned? Fernando Oleo Blanco
2024-01-07 16:48 96% ` Philip Kaludercic
2024-01-14 17:28 Possible minibuffer completion enhancements Eshel Yaron
2024-01-15 21:35 ` Stefan Kangas
2024-01-16 13:58 ` Eshel Yaron
2024-01-16 22:44 ` Stefan Kangas
2024-01-17 19:17 ` Eshel Yaron
2024-01-17 21:17 ` Stefan Kangas
2024-01-19 12:31 ` Eshel Yaron
2024-01-21 9:03 ` Eshel Yaron
2024-01-22 21:11 88% ` Philip Kaludercic
2024-01-16 0:38 [ELPA] New package devicetree-ts-mode Aleksandr Vityazev
2024-01-16 6:18 99% ` Philip Kaludercic
2024-01-16 6:42 ` Aleksandr Vityazev
2024-01-16 7:30 96% ` Philip Kaludercic
[not found] <170503894510.17915.13706990899423234889@vcs2.savannah.gnu.org>
[not found] ` <20240112055545.BD592C00216@vcs2.savannah.gnu.org>
2024-01-16 7:26 99% ` [elpa] main 630bdd7c45: * elpa-packages: update all Protesilaos repo URLs Philip Kaludercic
2024-01-16 8:14 Package suggestion[nongnu]: Gnosis (γνῶσις) Thanos Apollo
2024-01-18 19:42 19% ` Philip Kaludercic
2024-01-19 14:45 ` Thanos Apollo
2024-01-20 12:20 98% ` Philip Kaludercic
2024-01-22 13:39 ` Thanos Apollo
2024-01-22 17:59 98% ` Philip Kaludercic
2024-01-22 22:55 ` Thanos Apollo
2024-01-23 7:53 91% ` Philip Kaludercic
2024-01-16 8:18 46% Auto-suggesting Packages Philip Kaludercic
2024-01-16 9:01 ` Stephen Berman
2024-01-16 9:26 99% ` Philip Kaludercic
2024-01-16 12:58 ` Eli Zaretskii
2024-01-16 15:06 96% ` Philip Kaludercic
2024-01-16 15:13 ` Eli Zaretskii
2024-01-16 16:18 99% ` Philip Kaludercic
[not found] <871qacrubf.fsf@thanosapollo.org>
2024-01-20 14:36 82% ` completing-read & emacsql Philip Kaludercic
2024-01-22 5:55 Patch for ansi-osc.el Brad Howes
2024-01-22 7:21 99% ` Philip Kaludercic
2024-01-23 15:31 [PATCH] dictonary.el documentation No Wayman
2024-01-23 17:14 99% ` Philip Kaludercic
2024-01-26 0:59 [ELPA] New package: activities Adam Porter
2024-01-26 7:33 99% ` Philip Kaludercic
2024-01-26 7:45 ` Eli Zaretskii
2024-01-26 10:42 ` Adam Porter
2024-01-26 12:32 ` Eli Zaretskii
2024-01-26 21:59 ` Adam Porter
2024-01-27 7:08 ` Eli Zaretskii
2024-01-27 8:46 ` Adam Porter
2024-01-27 14:53 ` Eric S Fraga
2024-01-27 16:14 ` Sergey Organov
2024-01-28 11:25 ` Eric S Fraga
2024-01-29 10:45 ` Sergey Organov
2024-01-29 13:03 99% ` Philip Kaludercic
2024-01-26 10:36 Adam Porter
2024-01-29 19:50 ` Adam Porter
2024-01-30 7:16 99% ` Philip Kaludercic
2024-01-31 23:23 discoverability, better defaults and which-key in Emacs Jeremy Bryant
2024-02-01 2:45 ` Po Lu
2024-02-03 13:40 99% ` Philip Kaludercic
2024-02-04 22:03 ` Dmitry Gutov
2024-02-05 7:11 99% ` Philip Kaludercic
2024-02-05 15:38 ` Dmitry Gutov
2024-02-05 18:47 97% ` Philip Kaludercic
2024-02-02 15:01 Automatically saving package sources sbaugh
2024-02-04 10:22 91% ` Philip Kaludercic
2024-02-03 12:36 Request to include a couple of packages in GNU ELPA Rahguzar
2024-02-04 4:45 ` Richard Stallman
2024-02-04 8:42 ` Rahguzar
2024-02-07 3:11 ` Richard Stallman
2024-02-07 8:29 97% ` Philip Kaludercic
2024-02-10 3:55 ` Richard Stallman
2024-02-10 9:11 ` Rahguzar
2024-02-10 15:49 99% ` Philip Kaludercic
2024-02-04 8:56 99% ` Philip Kaludercic
2024-02-05 14:30 cond* vs pcase Arthur Miller
2024-02-05 16:06 ` Alfred M. Szmidt
2024-02-05 18:39 99% ` Philip Kaludercic
2024-02-06 16:17 ` Alfred M. Szmidt
2024-02-06 16:50 94% ` Philip Kaludercic
2024-02-06 17:27 ` Alfred M. Szmidt
2024-02-06 18:57 94% ` Philip Kaludercic
2024-02-06 19:04 ` Alfred M. Szmidt
2024-02-06 19:39 85% ` Philip Kaludercic
2024-02-05 15:35 New package for NonGNU ELPA : totp-auth Vivek Das Mohapatra
2024-02-06 10:04 68% ` Philip Kaludercic
2024-02-06 10:24 ` Po Lu
2024-02-06 10:27 99% ` Philip Kaludercic
2024-02-07 3:16 ` Richard Stallman
2024-02-07 8:23 99% ` Philip Kaludercic
2024-02-05 20:12 nongnu ELPA and slime Peter Hull
2024-02-06 8:10 97% ` Philip Kaludercic
2024-02-06 9:38 ` Colin Baxter
2024-02-06 10:07 99% ` Philip Kaludercic
2024-02-06 7:05 Proposing new function for basic editing Pedro Andres Aranda Gutierrez
2024-02-06 8:14 98% ` Philip Kaludercic
[not found] <slime/slime/pull/809@github.com>
[not found] ` <slime/slime/pull/809/c1929127567@github.com>
2024-02-06 10:12 86% ` [slime/slime] Merge changes from ELPA (PR #809) Philip Kaludercic
2024-02-06 15:57 Elpa question: helping with maintainance of a package in Elpa Arthur Miller
2024-02-06 17:00 99% ` Philip Kaludercic
2024-02-06 17:17 ` chad
2024-02-06 17:24 99% ` Philip Kaludercic
2024-02-06 19:12 [External] : Re: cond* vs pcase Drew Adams
2024-02-06 20:08 ` Adam Porter
2024-02-06 23:32 ` Drew Adams
2024-02-07 13:14 ` Arthur Miller
2024-02-07 13:43 ` Po Lu
2024-02-07 18:00 ` Arthur Miller
2024-02-07 18:22 ` Alfred M. Szmidt
2024-02-08 1:55 ` Po Lu
2024-02-08 2:49 99% ` Philip Kaludercic
2024-02-08 19:55 [DISCUSSION] "quick-help" popup for org-columns (column view) Sławomir Grochowski
2024-02-08 22:16 ` Adam Porter
2024-02-08 23:01 ` Stefan Kangas
2024-02-09 23:02 ` Ihor Radchenko
2024-02-10 15:44 93% ` Philip Kaludercic
2024-03-20 14:08 ` Ihor Radchenko
2024-04-06 20:41 ` Sławomir Grochowski
2024-04-06 22:40 89% ` Philip Kaludercic
2024-04-07 5:57 ` Eli Zaretskii
2024-04-08 7:38 ` Sławomir Grochowski
2024-04-08 8:24 96% ` Philip Kaludercic
2024-04-08 19:13 ` Sławomir Grochowski
2024-04-10 8:26 84% ` Philip Kaludercic
2024-04-10 20:42 ` Sławomir Grochowski
2024-04-11 6:37 99% ` Philip Kaludercic
2024-04-11 6:58 86% ` Philip Kaludercic
2024-04-13 8:37 99% ` Philip Kaludercic
2024-04-15 12:39 ` Sławomir Grochowski
2024-04-16 7:24 93% ` Philip Kaludercic
[not found] <170756342270.29779.1651696549492519525@vcs2.savannah.gnu.org>
[not found] ` <20240210111023.1468FC0EFEF@vcs2.savannah.gnu.org>
2024-02-10 16:36 99% ` master 7e8b1863af8: Add support for deriving major modes in which-func Philip Kaludercic
2024-02-19 14:51 Adding Flycheck to NonGNU ELPA Bozhidar Batsov
2024-02-19 17:44 98% ` Philip Kaludercic
2024-02-19 18:08 ` Bozhidar Batsov
2024-02-19 18:53 58% ` Philip Kaludercic
2024-02-19 19:17 ` Bozhidar Batsov
2024-02-19 19:41 75% ` Philip Kaludercic
2024-02-19 19:32 ` Dmitry Gutov
2024-02-19 22:32 ` joakim
2024-02-20 11:48 60% ` Philip Kaludercic
2024-02-20 20:04 ` Dmitry Gutov
2024-02-21 14:38 ` Dmitry Gutov
2024-02-21 15:02 ` Stefan Monnier
2024-02-22 15:50 ` Dmitry Gutov
2024-02-22 16:57 94% ` Philip Kaludercic
2024-02-22 17:10 ` Dmitry Gutov
2024-02-22 17:29 ` Bozhidar Batsov
2024-02-23 16:07 ` Docs on ELPA (was Re: Adding Flycheck to NonGNU ELPA) Spencer Baugh
2024-02-23 16:13 92% ` Philip Kaludercic
2024-02-23 23:37 ` Adam Porter
2024-02-24 8:04 91% ` Philip Kaludercic
2024-02-24 23:25 ` Stefan Monnier
2024-02-25 10:06 87% ` Philip Kaludercic
2024-02-21 17:01 99% ` Adding Flycheck to NonGNU ELPA Philip Kaludercic
2024-02-21 17:38 ` Dmitry Gutov
2024-02-21 18:05 99% ` Philip Kaludercic
2024-02-21 17:00 63% ` Philip Kaludercic
[not found] <170836288097.22729.10027592558614089561@vcs2.savannah.gnu.org>
[not found] ` <20240219171441.76EC3C3421F@vcs2.savannah.gnu.org>
2024-02-19 18:59 82% ` master ddfba511c19 1/3: Check shortdoc keywords and fix one mistake Philip Kaludercic
2024-02-19 19:21 ` Eli Zaretskii
2024-02-19 19:25 99% ` Philip Kaludercic
2024-02-20 2:15 Adding package "Loopy" to Non-GNU Devel? Okamsn
2024-02-20 8:09 92% ` Philip Kaludercic
2024-02-22 3:20 ` Okamsn
2024-02-25 17:56 ` Okamsn
2024-02-25 20:50 91% ` Philip Kaludercic
2024-02-28 1:34 ` Okamsn
2024-03-14 18:52 99% ` Philip Kaludercic
[not found] <170844508291.3153.9183498620897065719@vcs2.savannah.gnu.org>
[not found] ` <20240220160445.7C360C00227@vcs2.savannah.gnu.org>
2024-02-20 16:43 99% ` [elpa] externals/auctex f124fe7d28: Release GNU AUCTeX 14.0.3 Philip Kaludercic
2024-02-21 12:06 ` Tassilo Horn
2024-02-21 13:00 ` Stefan Monnier
2024-02-21 14:26 ` Tassilo Horn
2024-02-21 15:01 ` Stefan Monnier
2024-02-21 16:24 ` Stefan Monnier
2024-02-21 17:07 99% ` Philip Kaludercic
2024-02-21 17:02 99% ` Philip Kaludercic
2024-02-25 7:28 [ELPA] New package: listen Adam Porter
2024-02-25 11:43 39% ` Philip Kaludercic
2024-02-25 13:14 ` Adam Porter
2024-02-25 13:45 51% ` Philip Kaludercic
2024-02-26 4:15 ` Adam Porter
2024-02-26 8:09 78% ` Philip Kaludercic
2024-02-26 8:50 ` Adam Porter
2024-02-26 10:13 86% ` Philip Kaludercic
2024-02-26 14:51 ` Adam Porter
2024-02-26 15:26 99% ` Philip Kaludercic
2024-02-26 17:17 ` [External] : " Drew Adams
2024-02-26 17:21 99% ` Philip Kaludercic
2024-02-25 14:17 ` Andreas Schwab
2024-02-26 3:46 ` Adam Porter
2024-02-26 7:47 99% ` Philip Kaludercic
2024-02-25 21:07 NonGNU ELPA: Conditions for accepting a potential new package 'rmsbolt' ? Jeremy Bryant
2024-02-26 7:44 99% ` Philip Kaludercic
2024-02-26 22:40 ` Jeremy Bryant
2024-02-27 7:47 16% ` Philip Kaludercic
2024-02-27 16:13 ` Jay Kamat
2024-02-27 17:10 98% ` Philip Kaludercic
2024-02-27 17:14 ` Jay Kamat
2024-02-27 17:21 98% ` Philip Kaludercic
2024-02-27 17:21 ` Stefan Monnier
2024-02-27 17:27 85% ` Philip Kaludercic
2024-02-27 17:49 ` Stefan Monnier
2024-02-27 18:42 99% ` Philip Kaludercic
2024-03-03 6:13 Reliability of melpa Pedro Andres Aranda Gutierrez
2024-03-03 7:19 99% ` Philip Kaludercic
2024-03-08 9:26 [ELPA] new single file package: mpdired.el Manuel Giraud via Emacs development discussions.
2024-03-08 10:25 61% ` Philip Kaludercic
2024-03-08 11:17 ` Manuel Giraud via Emacs development discussions.
2024-03-08 11:26 91% ` Philip Kaludercic
2024-03-08 12:22 ` Manuel Giraud via Emacs development discussions.
2024-03-08 13:18 94% ` Philip Kaludercic
2024-03-08 16:25 ` Manuel Giraud via Emacs development discussions.
2024-03-08 16:34 98% ` Philip Kaludercic
2024-03-08 17:06 ` Manuel Giraud via Emacs development discussions.
2024-03-08 17:29 91% ` Philip Kaludercic
2024-03-09 13:18 ` Manuel Giraud via Emacs development discussions.
2024-03-09 13:36 99% ` Philip Kaludercic
2024-03-10 16:00 ` Manuel Giraud via Emacs development discussions.
2024-03-10 17:03 99% ` Philip Kaludercic
2024-03-10 17:49 ` Manuel Giraud via Emacs development discussions.
2024-03-10 18:03 ` Manuel Giraud via Emacs development discussions.
2024-03-10 18:15 98% ` Philip Kaludercic
2024-03-08 10:27 I created a faster JSON parser Herman, Géza
2024-03-08 11:41 97% ` Philip Kaludercic
2024-03-09 20:37 ` Christopher Wellons
2024-03-10 6:31 ` Eli Zaretskii
2024-03-10 21:39 99% ` Philip Kaludercic
[not found] <170988163944.32233.2128179311431485478@vcs2.savannah.gnu.org>
[not found] ` <20240308070720.AC3ACC1FB4E@vcs2.savannah.gnu.org>
2024-03-08 13:13 96% ` master bd017175d45 6/6: Simplify type hierarchy operations Philip Kaludercic
2024-03-08 19:04 Work On Todo item: Convert defvar foo-mode-map to defvar-keymap binarydigitz01 via Emacs development discussions.
2024-03-09 9:21 99% ` Philip Kaludercic
[not found] <D57DBB96-82DE-4697-A358-032B04190724@gmail.com>
2024-03-09 9:03 99% ` Add elisa to gnu elpa Philip Kaludercic
2024-03-11 23:18 [PATCH] Flymake Support Indicator Errors in Margin Elijah G
2024-03-12 9:24 96% ` Philip Kaludercic
2024-03-15 12:51 builtin completion ? hx
2024-03-15 15:48 97% ` Philip Kaludercic
[not found] <87v8j28c2x.fsf@betli.tmit.bme.hu>
[not found] ` <874jdipfp5.fsf@posteo.net>
[not found] ` <87cys6t734.fsf@betli.tmit.bme.hu>
[not found] ` <87r0gmnjq4.fsf@posteo.net>
[not found] ` <87o7bprr04.fsf@betli.tmit.bme.hu>
[not found] ` <87bk7p57yz.fsf@posteo.net>
2024-03-16 12:16 ` (byte-compile '(append '(1 2) '(3 4))) Felician Nemeth
2024-03-16 12:46 88% ` Philip Kaludercic
2024-03-16 13:23 ` Basil L. Contovounesios
2024-03-16 13:55 99% ` Philip Kaludercic
2024-03-17 4:07 [ELPA] [PATCH] CSS readability improvements Adam Porter
2024-03-17 4:14 ` Stefan Monnier
2024-03-17 4:19 ` Adam Porter
2024-03-17 14:43 99% ` Philip Kaludercic
[not found] <87zfvl8r4e.fsf@jeremybryant.net>
[not found] ` <874jdspsqb.fsf@bernoul.li>
2024-02-28 20:56 ` Incorporate package macrostep into Emacs or NonGNU ELPA? Jeremy Bryant via Emacs development discussions.
2024-02-28 21:16 ` Stefan Monnier
2024-02-28 23:04 ` Jeremy Bryant
2024-02-29 20:44 ` Jeremy Bryant
2024-03-02 6:51 ` Eli Zaretskii
2024-03-02 21:36 ` Jeremy Bryant
2024-03-17 21:48 ` Incorporate package macrostep into Emacs core Jeremy Bryant via Emacs development discussions.
2024-03-18 9:09 86% ` Philip Kaludercic
2024-03-18 23:03 ` Jeremy Bryant
2024-03-19 6:36 85% ` Philip Kaludercic
2024-03-19 7:11 ` Gerd Möllmann
2024-03-19 7:26 95% ` Philip Kaludercic
2024-03-19 7:30 ` Gerd Möllmann
2024-03-19 9:33 98% ` Philip Kaludercic
2024-03-22 15:25 error when trying to a install a recent (2.24) seq version via the package system Uwe Brauer via Emacs development discussions.
2024-03-22 16:30 96% ` Philip Kaludercic
2024-03-22 22:56 recursion to iteration macro Emanuel Berg
2024-03-23 7:12 99% ` Philip Kaludercic
2024-03-28 13:40 Where should security issues with GNU ELPA packages be reported? Morgan Willcock
2024-03-28 16:07 99% ` Philip Kaludercic
2024-03-28 17:14 ` Morgan Willcock
2024-03-29 5:53 99% ` Philip Kaludercic
2024-03-31 11:05 Hundreds of ELPA packages updated today? Romain Francoise
2024-03-31 11:49 99% ` Philip Kaludercic
2024-03-31 16:00 GNU ELPA announcements - e.g.: [GNU ELPA] Csv-Mode version 1.23 Drew Adams
2024-03-31 16:40 99% ` Philip Kaludercic
2024-04-18 18:29 seq; Error during initial package install Parker, Ron
2024-04-27 8:36 ` Eli Zaretskii
2024-04-27 9:17 70% ` Philip Kaludercic
2024-04-27 14:40 ` Stefan Monnier
[not found] ` <MW4PR06MB8948E521FC9D0C00DDE24A16E9152@MW4PR06MB8948.namprd06.prod.outlook.com>
2024-04-27 18:24 99% ` Philip Kaludercic
2024-04-18 22:45 Objed maintenance Amy Grinn
2024-04-22 7:22 89% ` Philip Kaludercic
2024-04-25 12:38 ` Amy Grinn
2024-04-27 10:06 99% ` Philip Kaludercic
2024-04-27 11:32 ` Amy Grinn
2024-04-27 11:54 95% ` Philip Kaludercic
2024-04-27 21:51 ` Amy Grinn
2024-05-01 18:06 88% ` Philip Kaludercic
2024-05-02 1:39 ` Adam Porter
2024-05-02 6:02 99% ` Philip Kaludercic
2024-05-02 9:43 ` Adam Porter
2024-05-02 17:09 96% ` Philip Kaludercic
2024-05-03 4:06 ` Adam Porter
2024-05-03 5:49 95% ` Philip Kaludercic
2024-05-02 13:13 ` Amy Grinn
2024-05-03 6:51 92% ` Philip Kaludercic
2024-04-20 1:07 [ELPA] New package: colorful-mode Elijah G
2024-04-22 7:51 51% ` Philip Kaludercic
2024-04-23 2:49 ` Elijah G
2024-04-27 10:12 98% ` Philip Kaludercic
2024-04-27 16:44 ` Elijah G
2024-04-27 21:12 99% ` Philip Kaludercic
2024-04-28 23:39 ` Elijah G
2024-04-29 5:47 99% ` Philip Kaludercic
2024-04-20 3:23 [PATCH] feat: add markdown-ts-mode Rahul Martim Juliato
2024-04-20 6:44 ` Eli Zaretskii
2024-04-20 17:45 ` Jostein Kjønigsen
2024-04-21 5:50 ` Rahul Martim Juliato
2024-04-22 7:02 88% ` Philip Kaludercic
2024-04-23 1:20 ` Rahul Martim Juliato
2024-04-27 10:18 84% ` Philip Kaludercic
2024-04-27 9:02 Add plz-media-type and plz-event-source to GNU ELPA when stabilized Roman Scherer
2024-04-27 13:43 89% ` Philip Kaludercic
2024-04-28 12:56 ` Roman Scherer
2024-04-29 6:09 69% ` Philip Kaludercic
2024-04-29 7:44 ` Roman Scherer
2024-04-29 7:46 99% ` Philip Kaludercic
2024-04-29 7:48 ` Roman Scherer
2024-04-29 18:24 98% ` Add plz-media-type and plz-event-source to GNU ELPA when stabilised Philip Kaludercic
2024-05-01 11:25 ` Roman Scherer
2024-05-01 11:56 99% ` Philip Kaludercic
2024-04-28 3:55 [NonGNU ELPA] Add package gptel Karthik Chikmagalur
2024-04-28 8:21 29% ` Philip Kaludercic
2024-04-28 16:50 ` Karthik Chikmagalur
2024-04-29 6:18 88% ` Philip Kaludercic
2024-04-29 6:52 ` Karthik Chikmagalur
2024-04-29 7:29 79% ` Philip Kaludercic
2024-04-29 17:21 ` Karthik Chikmagalur
2024-04-29 18:21 93% ` Philip Kaludercic
2024-04-29 20:11 ` Karthik Chikmagalur
2024-05-01 12:02 99% ` Philip Kaludercic
2024-04-30 23:07 Proposal for a new emacs icon Elijah G
2024-05-02 8:05 99% ` Philip Kaludercic
2024-05-02 9:52 ` Po Lu
2024-05-02 17:01 99% ` Philip Kaludercic
2024-05-02 19:57 Maintenance of cobol-mode.el on ELPA kristofer
2024-05-03 5:42 95% ` Philip Kaludercic
2024-05-05 10:27 ` kristofer
2024-05-05 14:10 99% ` Philip Kaludercic
2024-05-05 19:22 ` kristofer
2024-05-05 19:32 99% ` Philip Kaludercic
2024-05-06 19:44 ` kristofer
2024-05-06 20:00 99% ` Philip Kaludercic
2024-05-20 6:42 99% ` Philip Kaludercic
2024-05-08 11:33 [ELPA] New consult-denote package Protesilaos Stavrou
2024-05-08 17:19 77% ` Philip Kaludercic
2024-05-09 4:00 ` Protesilaos Stavrou
2024-05-09 8:20 99% ` Philip Kaludercic
2024-05-09 10:35 SageMath and Emacs Rahguzar
2024-05-09 12:24 99% ` [ELPA] " Philip Kaludercic
2024-05-20 7:03 99% ` Philip Kaludercic
2024-05-14 21:26 A new Emacs maintainer: Andrea Corallo Richard Stallman
2024-05-18 16:59 ` Stefan Kangas
2024-05-20 6:34 99% ` Philip Kaludercic
2024-05-15 9:33 bind print-integers-as-characters to t in `describe-variable'? Robert Pluim
2024-05-15 10:13 ` Mattias Engdegård
2024-05-15 11:56 ` Eli Zaretskii
2024-05-16 5:46 99% ` Philip Kaludercic
2024-05-16 8:45 ` Eli Zaretskii
2024-05-16 9:05 99% ` Philip Kaludercic
2024-05-15 21:00 [NonGNU ELPA] hyperdrive: Use stable release branch Joseph Turner
2024-05-20 7:03 99% ` Philip Kaludercic
2024-05-17 14:24 [ELPA] New package: csv2ledger Joost Kremers
2024-05-20 7:02 85% ` Philip Kaludercic
2024-05-20 12:06 ` Joost Kremers
2024-05-20 12:18 78% ` Philip Kaludercic
2024-05-20 12:26 86% ` Philip Kaludercic
2024-05-19 17:06 [ELPA] some tex-related packages Paul Nelson
2024-05-20 6:33 93% ` Philip Kaludercic
2024-05-20 9:01 ` Paul Nelson
2024-05-20 9:18 91% ` Philip Kaludercic
2024-05-21 22:55 [PATCH] csv-mode.el: Add function for reading a CSV line Joost Kremers
2024-05-22 6:17 99% ` Philip Kaludercic
2024-05-22 7:00 ` Joost Kremers
2024-05-22 16:14 99% ` Philip Kaludercic
2024-05-22 16:21 ` Joost Kremers
2024-05-25 8:26 99% ` Philip Kaludercic
2024-05-28 8:48 Why not include all ELPA packages in an Emacs release? Jeremy Bryant
2024-05-28 23:15 ` Stefan Kangas
2024-05-29 5:59 99% ` Philip Kaludercic
2024-05-29 11:44 ` Eli Zaretskii
2024-05-29 15:27 ` Arash Esbati
2024-05-29 16:06 99% ` Philip Kaludercic
2024-05-29 19:33 ` Andrea Corallo
2024-05-30 19:25 ` Adding AUCTeX to core " Jeremy Bryant
2024-05-30 19:33 99% ` Philip Kaludercic
2024-05-29 22:16 ` Arash Esbati
2024-05-30 6:25 99% ` Philip Kaludercic
2024-05-30 6:33 ` Daniel Mendler via Emacs development discussions.
2024-05-30 7:28 92% ` Philip Kaludercic
2024-05-30 8:15 ` Daniel Mendler via Emacs development discussions.
2024-05-30 15:20 84% ` Philip Kaludercic
2024-05-29 20:35 ` Tassilo Horn
2024-05-30 8:00 99% ` Philip Kaludercic
2024-05-28 14:26 Adding new package hideshowvis to nongnu elpa Jan Rehders
2024-05-29 7:26 31% ` Philip Kaludercic
2024-05-29 16:31 Re Re: Why not include all ELPA packages in an Emacs release? Pedro Andres Aranda Gutierrez
2024-05-29 20:36 77% ` Philip Kaludercic
2024-05-30 6:16 ` Pedro Andres Aranda Gutierrez
2024-05-30 6:31 97% ` 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).