* Re: [NonGNU ELPA] New package: devil
@ 2023-05-17 14:06 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-05-17 14:06 UTC (permalink / raw)
To: João Távora; +Cc: Susam Pal, emacs-devel
João Távora <joaotavora@gmail.com> writes:
> FWIW i agree with you on all points.
>
> It's important for packages to be allowed to keep the names the developers
> baptized them with.
Important in what sense? There have frequently been authors that have
changed the names of their packages when this was suggested to them, so
it doesn't like it was important for them. People are making a bigger
deal out of quirky names than it should be.
^ permalink raw reply [relevance 99%]
* Re: [ELPA] New package: dict
@ 2023-05-18 12:59 99% ` Philip Kaludercic
1 sibling, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-05-18 12:59 UTC (permalink / raw)
To: Eshel Yaron; +Cc: Eli Zaretskii, emacs-devel
Eshel Yaron <me@eshelyaron.com> writes:
> diff --git a/lisp/net/dictionary.el b/lisp/net/dictionary.el
> index ba65225692a..adf1f409f26 100644
> --- a/lisp/net/dictionary.el
> +++ b/lisp/net/dictionary.el
> @@ -38,6 +38,7 @@
> (require 'custom)
> (require 'dictionary-connection)
> (require 'button)
> +(require 'help-mode)
>
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> ;; Stuff for customizing.
> @@ -247,6 +248,39 @@ dictionary-coding-systems-for-dictionaries
> )))
> :version "28.1")
>
> +(defcustom dictionary-read-word-prompt "Search word"
> + "Prompt string to use when prompting for a word."
> + :type 'string
> + :version "30.1")
> +
> +(defcustom dictionary-display-definition-function nil
> + "Function to use for displaying dictionary definitions.
> +It is called with three string arguments: the word being defined,
> +the dictionary name, and the full definition."
> + :type '(choice (const :tag "Dictionary buffer" nil)
> + (const :tag "Help buffer"
> + dictionary-display-definition-in-help-buffer)
> + (function :tag "Custom function"))
> + :version "30.1")
> +
> +(defcustom dictionary-read-word-function nil
> + "Function to use for prompting for a word.
> +It is called with no arguments and must return a string."
> + :type '(choice (const :tag "Default" nil)
> + (const :tag "Dictionary-based completion"
> + dictionary-completing-read-word)
> + (function :tag "Custom function"))
> + :version "30.1")
> +
> +(defcustom dictionary-read-dictionary-function nil
> + "Function to use for prompting for a dictionary.
> +It is called with no arguments and must return a string."
> + :type '(choice (const :tag "Default" nil)
> + (const :tag "Choose among server-provided dictionaries"
> + dictionary-completing-read-dictionary)
> + (function :tag "Custom function"))
> + :version "30.1")
Would there be a point in implementing the previous, default
implementations as functions here that would be invoked, instead of
relying using nil?
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: [ELPA] New package: calibre.el
@ 2023-05-18 13:01 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-05-18 13:01 UTC (permalink / raw)
To: Kjartan Óli Águstsson; +Cc: emacs-devel
Kjartan Óli Águstsson <kjartanoli@outlook.com> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> $ git clone https://git.disroot.org/kjartanoli/calibre.el
>> Cloning into 'calibre.el'...
>> fatal: repository 'https://git.disroot.org/kjartanoli/calibre.el/' not found
>>
>> Did something change since your last message. Sorry for the delay, but
>> I just got around to packaging it now.
>
> No worries about the delay. No nothing has changed that I'm aware of,
> and the command succeeds on my end. I can push to some other git host
> if you think that would solve it.
This might have been a temporary issue, I can clone it now. So unless
you have any ideas what the issue was, or if there is reason to suspect
it might occur again, then we can leave it as it is.
> Should I push a commit changing the
> copyright headers to list the FSF as the copyright holder?
Yes, along with a commit that would update the Version header.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: [ELPA] New package: dict
@ 2023-05-18 15:58 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-05-18 15:58 UTC (permalink / raw)
To: Eshel Yaron; +Cc: Eli Zaretskii, emacs-devel
Eshel Yaron <me@eshelyaron.com> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Would there be a point in implementing the previous, default
>> implementations as functions here that would be invoked, instead of
>> relying using nil?
>
> I'm not sure, I think these default functions wouldn't be very useful on
> their own, so I don't know if it's worth extracting them. But of course
> we can do it if there's some important benefit I'm missing.
I would imagine that if you wanted to extend the default functionality,
e.g. by binding some variable or whatever one might want, having this
available as a function you can just call, would be useful.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Naming guidelines for ELPA packages
@ 2023-05-20 16:51 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-05-20 16:51 UTC (permalink / raw)
To: Akib Azmain Turja
Cc: Jim Porter, rms, eliz, relekarpayas, susam.pal, emacs-devel
Akib Azmain Turja <akib@disroot.org> writes:
> Jim Porter <jporterbugs@gmail.com> writes:
>
>> On 5/14/2023 12:33 PM, Philip Kaludercic wrote:
>>> Jim Porter <jporterbugs@gmail.com> writes:
>>>
>>>> I think I need to adjust the passage a bit to emphasize that the
>>>> Emacs/ELPA maintainers would *prefer* a simple and straightforward
>>>> name like "gobject". ...
>>> That would sound acceptable to me.
>>
>> Ok, how about something like the following? I just expanded it a bit
>> to provide more context and adjusted the wording slightly here and
>> there (for example, these are now "recommendations" instead of
>> "guidelines").
>>
>> ----------------------------------------
>>
>> Naming is hard. However, taking some time to choose a good name for
>> your package will help make your package easier to find and to use. To
>> assist package authors, here are some recommendations for choosing
>> good Emacs package names. Package names should be:
>>
>> * Memorable: Aim for short, distinct names that users can easily recall.
>> * Intuitive: Names don't need to fully describe a package, but they
>> should at least provide a hint about what the package does.
>>
>> For example, suppose I've written a package that provides an interface
>> between GObjects and Emacs Lisp, and named it "goeli". This isn't a
>> very good name, since it's not easy to remember (users may find
>> themselves asking, "Wait... was it 'goli' or 'goeli'?"), and it's
>> nearly impossible to guess what it does from the name.
>>
>> After thinking about it some more, I have a flash of insight: I'll
>> call it "goblin" (for _GOb_ject _L_isp _In_terface)! This is easy
>> enough to remember, but it's still not intuitive.
>>
>> Perhaps the best name for a package like this would simply be
>> "gobject". That's both memorable *and* intuitive, not to mention being
>> as straightforward as you can get. If possible, the ELPA maintainers
>> recommend that you choose a name like this.
>>
>> However, suppose that at this point, I find myself disappointed: while
>> "gobject" is a thoroughly practical name, I just don't want to give up
>> the name "goblin". Instead, I could opt for a compromise: I'll still
>> use "Goblin" when documenting the package and prefix names in my code
>> with "goblin-", but I decide to submit it to GNU ELPA as
>> "goblin-gobject". While this isn't as concise as "gobject", it does
>> let the user know right away that this package has something to do
>> with GObjects.
>>
>
> The example name you suggested, "gobject", is indeed a good name, but
> there's a little problem that if someone ever comes up with a better
> package, it won't find any name for itself.
One could argue this would help preventing NIH and encouraging people to
contribute to existing projects.
^ permalink raw reply [relevance 99%]
* Re: [ELPA] New package: dict
@ 2023-05-20 19:11 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-05-20 19:11 UTC (permalink / raw)
To: Eshel Yaron; +Cc: Eli Zaretskii, emacs-devel
Eshel Yaron <me@eshelyaron.com> writes:
>>> +(defcustom dictionary-display-definition-function nil
>>> + "Function to use for displaying dictionary definitions.
>>> +It is called with three string arguments: the word being defined,
>>> +the dictionary name, and the full definition."
>>> + :type '(choice (const :tag "Dictionary buffer" nil)
>>> + (const :tag "Help buffer"
>>> + dictionary-display-definition-in-help-buffer)
>>> + (function :tag "Custom function"))
>>> + :version "30.1")
>>
>> What is the reason for having this option fallback to nil? I couldn't
>> make that out from the patch. If all the other options offer a
>> concrete-default function (that you could also call in your own
>> function), then it seems inconsistent to not provide this here as well.
>
> The reason is that, unlike the other options, the default path that
> `dictionary-search` takes to displaying a definition is highly coupled
> with how it obtains the definition, making it difficult to extract into
> a standalone function. That's a refactor I prefer to avoid at this
> point. So, if you set `dictionary-display-definition-function` to a
> custom function, we use the new function `dictionary-define-word` to
> cleanly obtain the definition and let your custom function display it.
> If you use the default (nil) value, we let `dictionary-search` call the
> "old" function `dictionary-new-search` that both obtains and displays
> the definition.
OK, I am not familiar with the code and I get that it could take too
much effort to refactor this properly right now.
>>> +(defun dictionary-define-word (word dictionary)
>>> + "Return the definition of WORD in DICTIONARY, or nil if not found."
>>> + (dictionary-send-command
>>> + (format "define %s \"%s\"" dictionary word))
>>> + (when (and (= (read (dictionary-read-reply)) 150)
>>> + (= (read (dictionary-read-reply)) 151))
>>
>> I think a memq would be nice here.
>>
>
> No, `memq` would be appropriate if we wanted to check that the
> expression `(read (dictionary-read-reply))` evaluates to either 150 or
> to 151, but here we want to check that it evaluates 150 and then
> afterwards that it evaluates to 151.
Whoops, misread that as and `or' and forgot about side-effects.
>>> +(defun dictionary-display-definition-in-help-buffer (word dictionary definition)
>>> + "Display DEFINITION, the definition of WORD in DICTIONARY."
>>> + (let ((help-buffer-under-preparation t))
>>> + (help-setup-xref (list #'dictionary-search word dictionary)
>>> + (called-interactively-p 'interactive))
>>> + (with-help-window (help-buffer)
>>> + (with-current-buffer (help-buffer)
>>> + (insert definition)
>>> + (goto-char (point-min))
>>> + (while (re-search-forward (rx "{"
>>> + (group-n 1 (* (not (any ?}))))
>>> + "}")
>>> + nil t)
>>
>> Perhaps you could explain what is going on here. Why is this pattern
>> significant?
>
> We want to buttonize references to other definitions in the *Help*
> buffer, which appear enclosed in curly braces. I've added a comment
> explaining this.
So the protocol always wraps other definitions in curly braces?
^ permalink raw reply [relevance 99%]
* Re: [PROPOSAL] Builder, a build system integration for Emacs
@ 2023-05-21 12:11 99% ` Philip Kaludercic
1 sibling, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-05-21 12:11 UTC (permalink / raw)
To: BTuin; +Cc: emacs-devel
Your proposal sounds interesting, and I think it is worth adding to GNU
or NonGNU ELPA. Do you have a preference? Also, it would be nice if
you could host the files in a Git repository somewhere, so that the ELPA
build-system can mirror your changes.
^ permalink raw reply [relevance 99%]
* Re: Builder, a build system integration for Emacs
@ 2023-05-23 8:36 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-05-23 8:36 UTC (permalink / raw)
To: Richard Stallman; +Cc: BTuin, emacs-devel
Richard Stallman <rms@gnu.org> writes:
> [[[ To any NSA and FBI agents reading my email: please consider ]]]
> [[[ whether defending the US Constitution against all enemies, ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> > As far as I know, Emacs does not provide a convenient way to use build
> > systems,
>
> Isn't "use build systems" what M-x compile does?
> Assuming that each bui;d system provides a shell command to invoke it,
> M-x compile can run that command and build the package.
The issue is not what M-x compile, but that with a lot of modern
programming languages the build systems are complex but automatable, to
a point that it would be nice if Emacs could detect the necessary
information to invoke the right command or sequence of commands.
^ permalink raw reply [relevance 99%]
* Re: Inferred function types in the *Help* buffer
@ 2023-05-23 18:51 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-05-23 18:51 UTC (permalink / raw)
To: Payas Relekar; +Cc: Andrea Corallo, emacs-devel
Payas Relekar <relekarpayas@gmail.com> writes:
> Andrea Corallo <akrl@sdf.org> writes:
>
>> ====
>> foo is a native-compiled Lisp function in
>> ‘~/.emacs.d/eln-cache/30.0.50-e29d76eb/test-a526a80f-5481bc95.eln’.
>>
>> Signature: (foo N)
>>
>> Inferred type: (function (t) (or (member to-small too-big) (integer
>> 100 100)))
>>
>> ...
>> ====
>
> Pretty cool.
>
> Tangentially, there's also Elsa: https://github.com/emacs-elsa/Elsa
>
> How feasible would you say it would be to integrate it within
> Emacs/native-compiler?
Elsa? In a recent discussion[0] the author (Matus Goljer) told me this:
> Elsa is complex and it currently can't run from user session Emacs and
> most likely never will. There is many ways to run Elsa mentioned in
> the Readme. Currently no other ways are supported, but I'm sure it's
> possible. Elsa is not a linter like "checkdoc", it is a full
> evaluation engine for Emacs Lisp, it's a gradual type system, it's a
> language server, it's a refactoring tool. It will be more things in
> the future. You should imagine it being a separate program that you
> run alongside Emacs, not inside Emacs.
[0] https://github.com/emacs-elsa/Elsa/issues/218#issuecomment-1470421487
> Regards,
> Payas
>
> --
^ permalink raw reply [relevance 99%]
* Re: [nongnu] main 83410aacf7: * elpa-packages (devil): New package
@ 2023-05-24 6:41 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-05-24 6:41 UTC (permalink / raw)
To: Susam Pal; +Cc: Stefan Monnier, emacs-devel
Susam Pal <susam.pal@gmail.com> writes:
> Philip Kaludercic <philipk@posteo.net> wrote:
>>
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>
>> >>> + (devil :url "https://github.com/susam/devil"
>> >>> + :readme "README.org"
>> >>> + :news "CHANGES.org")
>> >>
>> >> We created a separate MANUAL.org file, is that ready to be used?
>> >
>> > If that works, then please add `:doc "MANUAL.org"`, of course.
>>
>> Susam, what do you say?
>
> Sorry for the delay in responding to this. I was away for a while.
No problem.
> Yes, I think it is good to add `:doc "MANUAL.org"`.
Done.
^ permalink raw reply [relevance 99%]
* Re: Builder, a build system integration for Emacs
@ 2023-05-24 10:26 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-05-24 10:26 UTC (permalink / raw)
To: David Masterson; +Cc: Richard Stallman, BTuin, emacs-devel
David Masterson <dsmasterson@gmail.com> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Richard Stallman <rms@gnu.org> writes:
>>
>>> [[[ To any NSA and FBI agents reading my email: please consider ]]]
>>> [[[ whether defending the US Constitution against all enemies, ]]]
>>> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>>>
>>> > As far as I know, Emacs does not provide a convenient way to use build
>>> > systems,
>>>
>>> Isn't "use build systems" what M-x compile does?
>>> Assuming that each bui;d system provides a shell command to invoke it,
>>> M-x compile can run that command and build the package.
>>
>> The issue is not what M-x compile, but that with a lot of modern
>> programming languages the build systems are complex but automatable, to
>> a point that it would be nice if Emacs could detect the necessary
>> information to invoke the right command or sequence of commands.
>
> Isn't this the province of EDE (Emacs Development Environment)?
I might be wrong, but I am under the impression that EDE is not actively
maintained, and that newer systems like project and Eglot have taken
over.
^ permalink raw reply [relevance 99%]
* Re: [ELPA] New package: dict
@ 2023-05-25 19:10 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-05-25 19:10 UTC (permalink / raw)
To: Eshel Yaron; +Cc: emacs-devel, Eli Zaretskii
Eshel Yaron <me@eshelyaron.com> writes:
> Hi,
>
> I'm attaching a slightly updated patch to dictionary.el. The only
> change wrt to my previous patch is that `dictionary-match-word` now uses
> the new `external-completion-table` from Emacs 29 instead of
> `completion-table-dynamic` to allow leveraging arbitrary matching
> strategies that the dictionary server provides.
>
> For example, we can now set `dictionary-default-strategy` to the
> "soundex" matching strategy that dict.org provides to get completion
> candidates that sound similar to the minibuffer input (such as "tail",
> "tale" and "tell").
>
> I've also rebased onto master branch to avoid conflicts in etc/NEWS.
>
>
> From 749743aa703a98352cb12ad84c04c971b22ea44c Mon Sep 17 00:00:00 2001
> From: Eshel Yaron <me@eshelyaron.com>
> Date: Mon, 15 May 2023 21:04:21 +0300
> Subject: [PATCH v4] Add customization options for dictionary-search
>
> Allow users to customize 'dictionary-search' via several new
> customization options.
LGTM.
^ permalink raw reply [relevance 99%]
* Re: [NonGNU Elpa] New package: electric-french
@ 2023-06-05 8:34 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-06-05 8:34 UTC (permalink / raw)
To: Ruijie Yu via Emacs development discussions.; +Cc: Ruijie Yu
Ruijie Yu via "Emacs development discussions." <emacs-devel@gnu.org>
writes:
> Hello,
>
> I am proposing a new package called electric-french [1]. This stemmed
> from a discussion on emacs-humanities [2], where Jean-Christophe
> ("l@tlo") outlined a few common practices on nonbreak spaces in the
> French language. See near the end of the message for the commentary
> section.
Perhaps just a general point, there is already a package on GNU ELPA
called "ef-themes", and it could be confusing if you use the "ef-"
prefix, since it is might make it appear to be a more
general/super-feature.
^ permalink raw reply [relevance 99%]
* Re: master a30781399b3: * subr-x (eval-command-interactive-spec): New function.
[not found] ` <20230605073635.19060C00613@vcs2.savannah.gnu.org>
@ 2023-06-05 10:24 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-06-05 10:24 UTC (permalink / raw)
To: emacs-devel; +Cc: Sean Whitton
Sean Whitton <spwhitton@spwhitton.name> writes:
> branch: master
> commit a30781399b3ef48150b9cb13cb0aeba7086c2d9e
> Author: Sean Whitton <spwhitton@spwhitton.name>
> Commit: Sean Whitton <spwhitton@spwhitton.name>
>
> * subr-x (eval-command-interactive-spec): New function.
> ---
> etc/NEWS | 5 +++++
> lisp/emacs-lisp/nadvice.el | 2 ++
> lisp/emacs-lisp/subr-x.el | 7 +++++++
> 3 files changed, 14 insertions(+)
>
> diff --git a/etc/NEWS b/etc/NEWS
> index 9529282f047..910472e5519 100644
> --- a/etc/NEWS
> +++ b/etc/NEWS
> @@ -648,6 +648,11 @@ Since circular alias chains now cannot occur, 'function-alias-p',
> 'indirect-function' and 'indirect-variable' will never signal an error.
> Their 'noerror' arguments have no effect and are therefore obsolete.
>
> +---
> +** New function 'eval-command-interactive-spec' in the subr-x library.
> +This function evaluates a command's interactive form and returns the
> +resultant list.
What is the motivation for this feature?
> > +
> \f
> * Changes in Emacs 30.1 on Non-Free Operating Systems
>
> diff --git a/lisp/emacs-lisp/nadvice.el b/lisp/emacs-lisp/nadvice.el
> index e457387acc9..e6977f2012a 100644
> --- a/lisp/emacs-lisp/nadvice.el
> +++ b/lisp/emacs-lisp/nadvice.el
> @@ -165,6 +165,8 @@ DOC is a string where \"FUNCTION\" and \"OLDFUN\" are expected.")
> (buffer-string))
> usage))))
>
> +;; FIXME: How about renaming this to just `eval-interactive-spec'?
> +;; It's not specific to the advice system.
> (defun advice-eval-interactive-spec (spec)
> "Evaluate the interactive spec SPEC."
> (cond
> diff --git a/lisp/emacs-lisp/subr-x.el b/lisp/emacs-lisp/subr-x.el
> index 9e906930b92..a7d8f785508 100644
> --- a/lisp/emacs-lisp/subr-x.el
> +++ b/lisp/emacs-lisp/subr-x.el
> @@ -504,6 +504,13 @@ Used by `emacs-authors-mode' and `emacs-news-mode'."
> (progn (forward-line -1) (point))
> (point-max)))))
>
> +(defun eval-command-interactive-spec (command)
> + "Evaluate COMMAND's interactive form and return resultant list.
> +If COMMAND has no interactive form, return nil."
> + (advice-eval-interactive-spec
> + (cadr (or (and (symbolp command) (get command 'interactive-form))
> + (interactive-form command)))))
> +
> (provide 'subr-x)
>
> ;;; subr-x.el ends here
^ permalink raw reply [relevance 99%]
* Re: [elpa] externals/firefox-javascript-repl 056b687af4 2/3: Work around missing submodule support in GNU ELPA
[not found] ` <20230601213415.21F57C21A9F@vcs2.savannah.gnu.org>
@ 2023-06-05 12:46 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-06-05 12:46 UTC (permalink / raw)
To: emacs-devel; +Cc: Thomas Fitzsimmons
Thomas Fitzsimmons <fitzsim@fitzsim.org> writes:
> branch: externals/firefox-javascript-repl
> commit 056b687af4d70252dee2cdd2323da3990fabd558
> Author: Thomas Fitzsimmons <fitzsim@fitzsim.org>
> Commit: Thomas Fitzsimmons <fitzsim@fitzsim.org>
>
> Work around missing submodule support in GNU ELPA
What do you need to do?
> * wtfjs.README.md: New file.
> * firefox-javascript-repl.el (fjrepl--show-quirk): Load
> quirk-of-the-day from wtfjs.README.md snapshot. Increase quirk
> message timeout to seven seconds.
> (firefox-javascript-repl--mode): Do not ignore quirk errors.
^ permalink raw reply [relevance 99%]
* Re: question regarding my emacs package
@ 2023-06-07 18:04 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-06-07 18:04 UTC (permalink / raw)
To: ram; +Cc: emacs-devel@gnu.org
Philip Kaludercic <philipk@posteo.net> writes:
>> here is the repo: https://github.com/gitrj95/breadcrumbs.el
>
> Here are a few suggestions:
Oh, and can you address the issue raised by checkdoc?
^ permalink raw reply [relevance 99%]
* Re: question regarding my emacs package
@ 2023-06-07 19:48 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-06-07 19:48 UTC (permalink / raw)
To: ram; +Cc: emacs-devel@gnu.org
ram <chat@rj95.be> writes:
> changing the central type from defclass to cl-defstruct has appeared
> to cause bugs?
That might have been a typo on my end, I did not evaluate the code and
was is a hurry to send you the diff. My point is that you don't need
defclass, unless I am missing something in your code (and I don't think
the minimal convenience of `with-slots' warrants classes here).
> i am not sure what to make of this, but find-file and
> its variants do not appear to work when changing only this. the file
> is not opened; it is not that the file is opened but the active buffer
> isn't switched
>
>
>
>
> ------- Original Message -------
> On Wednesday, June 7th, 2023 at 2:04 PM, Philip Kaludercic <philipk@posteo.net> wrote:
>
>
>>
>>
>> Philip Kaludercic philipk@posteo.net writes:
>>
>> > > here is the repo: https://github.com/gitrj95/breadcrumbs.el
>> >
>> > Here are a few suggestions:
>>
>>
>> Oh, and can you address the issue raised by checkdoc?
^ permalink raw reply [relevance 99%]
* Re: [ELPA] New package: emacs-gc-stats
@ 2023-06-11 9:12 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-06-11 9:12 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Stefan Monnier, Eli Zaretskii, emacs-devel
Ihor Radchenko <yantar92@posteo.net> writes:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>>> Let me know if you need help adding the package (I couldn't find a URL
>>>> for the code, so I have no opinion about it (yet :-))
>>> Oops... https://git.sr.ht/~yantar92/emacs-gc-stats
>>
>> Thanks, added.
>
> For some reason, I am getting build failure:
>
> ======== Building tarball archive/emacs-gc-stats-1.0.tar...
> Problem with copyright notices:
> emacs-gc-stats/emacs-gc-stats.el:;; Copyright (C) 2023 Ihor Radchenko
> Missing copyright notice in emacs-gc-stats/emacs-gc-stats.el
> Build error for archive/emacs-gc-stats-1.0.tar: (error "Abort")
>
> Note that I have
>
> ;; Copyright (C) 2023 Free Software Foundation, Inc.
>
> in <https://git.sr.ht/~yantar92/emacs-gc-stats/tree/main/item/emacs-gc-stats.el>
>
> What am I missing?
ELPA uses the latest commit that bumped the version tag in the package
header. If that commit doesn't have the right copyright data, then that
is cause for the above error.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: question regarding my emacs package
@ 2023-06-12 8:45 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-06-12 8:45 UTC (permalink / raw)
To: ram via Emacs development discussions.; +Cc: joaotavora, ram
ram via "Emacs development discussions." <emacs-devel@gnu.org> writes:
> thanks. did not know this existed. from a quick glance, it looks like
> there’s no crossover in prefixes? that seems ok
Yes, but it is pretty close and will probably cause confusion. That
being said, João is not part of any ELPA so one could argue the name
hasn't been reserved...
> On Sun, Jun 11, 2023 at 2:49 PM, João Távora <joaotavora@gmail.com> wrote:
>
> Just a FYI, I've recently (about a month ago) created a package called breadcrumb.el, singular. Lives at
> https://github.com/joaotavora/breadcrumb and seems to be fairly popular.
>
> Not saying anyone should consider changing package names, just dropping this note here as a FYI.
>
> João
>
> On Wed, Jun 7, 2023, 13:09 ram <chat@rj95.be> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> hi, i am a professional programmer, but this is my first time submitting an emacs package. i have
> conversed a little with stefan monnier, and i believe the package i have meets the requirements for
> elpa submission, but i am unsure as to the appropriate licensure. i took some inspiration from two
> packages: dogears and gumshoe, neither of which is in elpa. however, i did not use any code from
> here; i just wanted some inspiration regarding the feature set
>
> it is unclear to me whether my package warrants inclusion in gnu or non gnu elpa, if at all, but i
> have certainly found it useful, despite its simplicity
>
> here is the repo: https://github.com/gitrj95/breadcrumbs.el
>
> best,
> ram
> -----BEGIN PGP SIGNATURE-----
> Version: ProtonMail
>
> wnUEARYKACcFgmR/9tMJkLWF/Pp8PQPNFiEExUjWugOWGzBgCQZvtYX8+nw9
> A80AACtMAQDBJcq/+hW8lFC/JkXKSAsIjD5/dFF/jcjYjfRh3o0TMwD9Eb4W
> f0DKtY6/QCgyoPMLsMIBUf1cDZ1c53rQ9xHWCAI=
> =5pUI
> -----END PGP SIGNATURE-----
>
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: contributing to Emacs
@ 2023-06-18 10:00 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-06-18 10:00 UTC (permalink / raw)
To: Konstantin Kharlamov; +Cc: Eli Zaretskii, ams, emacs-devel
Konstantin Kharlamov <hi-angel@yandex.ru> writes:
> On Sun, 2023-06-18 at 08:20 +0300, Eli Zaretskii wrote:
>> > From: Konstantin Kharlamov <hi-angel@yandex.ru>
>> > Cc: eliz@gnu.org, arne_bab@web.de, luangruo@yahoo.com, emacs-devel@gnu.org
>> > Date: Sun, 18 Jun 2023 01:39:17 +0300
>> >
>> > No. I measured specifically for you: "Sending Patches" alone is 5884
>> > characters
>> > not counting bullets, and my email was 3491 characters.
>>
>> When someone posts a patch, he or she is not requested to read that
>> section, let alone pass some kind of exam on being familiar with it.
>> I'm quite sure 99% of contributors don't even know that section exists
>> in the manual, and have never read it. So the size of that node is
>> utterly irrelevant to how hard it is to contribute to Emacs.
>
> You can't send a patch if you don't know how and where to send it 😊 So you
> can't avoid reading that section.
I think `submit-emacs-patch' is supposed to help here. But I don't get
how this is a Emacs/ML specific issue?
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: contributing to Emacs
@ 2023-06-24 15:37 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-06-24 15:37 UTC (permalink / raw)
To: Sean Whitton; +Cc: Konstantin Kharlamov, Eli Zaretskii, ams, emacs-devel
Sean Whitton <spwhitton@spwhitton.name> writes:
> Hello,
>
> On Sun 18 Jun 2023 at 10:22AM GMT, Philip Kaludercic wrote:
>
>> One idea (but I don't know if this is practicable), is to use the
>> configure script to set up Git's `sendemail.to' option or to add
>> `vc-default-patch-addressee' to .dir-locals.el.
>
> I thought we were going to do that anyway, just as soon as enough time
> had passed that people are not going to get unsafe local variable
> popups?
That was (is?) the plan, but I guess it was just delayed because people
on older versions got irritated by the unsafe variable warnings, and
then everyone forgot.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Use radix-tree for string arrays
@ 2023-07-05 16:47 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-07-05 16:47 UTC (permalink / raw)
To: Yuchen Pei; +Cc: Emacs Devel mailing list
Yuchen Pei <id@ypei.org> writes:
> @@ -1,6 +1,6 @@
> ;;; radix-tree.el --- A simple library of radix trees -*- lexical-binding: t; -*-
>
> -;; Copyright (C) 2016-2023 Free Software Foundation, Inc.
> +;; Copyright (C) 2016-2022 Free Software Foundation, Inc.
I suppose this edit was not intentional?
^ permalink raw reply [relevance 99%]
* Re: Use radix-tree for string arrays
@ 2023-07-06 18:50 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-07-06 18:50 UTC (permalink / raw)
To: Yuchen Pei; +Cc: Emacs Devel mailing list
Yuchen Pei <id@ypei.org> writes:
> On Wed 2023-07-05 16:47:38 +0000, Philip Kaludercic wrote:
>
>> Yuchen Pei <id@ypei.org> writes:
>>
>>> @@ -1,6 +1,6 @@
>>> ;;; radix-tree.el --- A simple library of radix trees -*-
>>> lexical-binding: t; -*-
>>>
>>> -;; Copyright (C) 2016-2023 Free Software Foundation, Inc.
>>> +;; Copyright (C) 2016-2022 Free Software Foundation, Inc.
>>
>> I suppose this edit was not intentional?
>
> It's not. It's because I modified emacs 28.2, the version I use, and
> diffed against master.
In that case I can recommend using copyright-update. I have this block
in my init.el:
(setopt copyright-names-regexp
(regexp-opt '("Free Software Foundation, Inc."
"<your name here>")))
(add-hook 'before-save-hook #'copyright-update)
> Best,
> Yuchen
^ permalink raw reply [relevance 99%]
* Re: Stability of project.el
@ 2023-07-11 5:26 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-07-11 5:26 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: emacs-devel
Dmitry Gutov <dmitry@gutov.dev> writes:
> Hi Philip,
>
> On 10/07/2023 21:53, Philip Kaludercic wrote:
>> The commentary section for project.el still begins with
>> --8<---------------cut here---------------start------------->8---
>> ;; NOTE: The project API is still experimental and can change in major,
>> ;; backward-incompatible ways. Everyone is encouraged to try it, and
>> ;; report to us any problems or use cases we hadn't anticipated, by
>> ;; sending an email to emacs-devel, or `M-x report-emacs-bug'.
>> --8<---------------cut here---------------end--------------->8---
>> Is this still true, or would it be warranted to remove it just like
>> we
>> did for Xref a few years ago (9a15694a45), perhaps even in time for
>> Emacs 29?
>
> I think that's a good idea. Even if there still some less-than-ideal
> bits, we need to maintain it backward-compatibly, given the age.
Great. Should the major version number also be bumped?
> And documentation-only changes should still be good for Emacs 29.
Eli, what do you say?
^ permalink raw reply [relevance 99%]
* Re: NonGNU ELPA: add Logview
@ 2023-07-13 18:35 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-07-13 18:35 UTC (permalink / raw)
To: Bozhidar Batsov; +Cc: Paul Pogonyshev, Emacs Devel
"Bozhidar Batsov" <bozhidar@batsov.dev> writes:
> Just bumping this conversation, as we're still looking for someone to help us apply the patch.
I was still waiting for comments from other people, as I haven't had the
time to review the packages myself.
^ permalink raw reply [relevance 99%]
* Re: [elpa] main 2ec80977e1: * elpa-packages (dired-preview): New package
@ 2023-07-13 20:29 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-07-13 20:29 UTC (permalink / raw)
To: Protesilaos Stavrou; +Cc: Stefan Monnier, emacs-devel
Protesilaos Stavrou <info@protesilaos.com> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Date: Mon, 10 Jul 2023 18:29:23 +0000
>
>> [... 35 lines elided]
>
>> diff --git a/dired-preview.el b/dired-preview.el
>> index 853131b..b3517bd 100644
>> --- a/dired-preview.el
>> +++ b/dired-preview.el
>
>> [... 206 lines elided]
>
> Hello again Philip,
>
> I believe I pushed all the relevant changes you suggested. The only one
> I have not done yet is the 'dolist' VS 'mapc' that you and Stefan
> commented on. I need to understand the technical differences better, so
> as to know when to use 'mapc'.
Do you have any concrete questions? Semantically they should be
equivalent, it is just a matter of estimating the cost of a funcall and
of closures, which is why I suggest replacing (mapc (lambda (x) ... x
...) xs) with (dolist (x xs) ... x ...).
> All the best,
> Prot
^ permalink raw reply [relevance 99%]
* Re: Lisp reader syntax and bootstrap
@ 2023-07-15 5:18 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-07-15 5:18 UTC (permalink / raw)
To: Po Lu; +Cc: Richard Stallman, Paul Eggert, ulm, eliz, contovob, emacs-devel
Po Lu <luangruo@yahoo.com> writes:
> Richard Stallman <rms@gnu.org> writes:
>
>> Do you know of a machine where this would really happen?
>
> VAXen, of course, and possibly future machines that haven't been
> designed yet.
Floating point operations are regarded as optional (but conventional)
extensions by RISC-V.
> I think I overheard some of the NetBSD porters talking about this
> problem.
^ permalink raw reply [relevance 99%]
* Re: New branch feature/named-lambdas.
@ 2023-07-17 19:52 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-07-17 19:52 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: emacs-devel
Alan Mackenzie <acm@muc.de> writes:
> Hello, Emacs.
>
> I've just committed the first version of branch feature/named-lambdas.
>
> This will output the @dfn{defining symbol} of any anonymous functions in
> backtraces.
>
> For example, in
>
> (defun foo ()
> "foo doc string"
> (lambda (bar) "lambda doc string" (car bar)))
>
> M-: (funcall (foo) 'baz) will produce this backtrace:
>
> Debugger entered--Lisp error: (wrong-type-argument listp baz)
> car(baz)
> {foo} #f(compiled-function (bar) "lambda doc string" #<bytecode -0x105933d3d8452e4e>)(baz) <=============================
> funcall({foo} #f(compiled-function (bar) "lambda doc string" #<bytecode -0x105933d3d8452e4e>) baz)
> (progn (funcall (foo) 'baz))
> elisp--eval-last-sexp(nil)
> eval-last-sexp(nil)
> funcall-interactively(eval-last-sexp nil)
> command-execute(eval-last-sexp)
>
> .. Note the {foo} on the third and fourth lines. This is (usually) the
> defun where the lambda was defined, and is helpful in locating its
> source code.
>
> This was achieved by adding an extra defining-symbol field to each of
> the three forms of function (interpreted, byte-compiled,
> native-compiled). It is indended that this version of Emacs will
> continue to handle functions compiled without this enhancement.
I think the idea is nice, but there are a lot of whitespace changes in
your commit that make identifying the real changes a bit difficult.
^ permalink raw reply [relevance 99%]
* Re: Suggestion for package.el: atomic package-upgrade
@ 2023-08-01 7:32 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-08-01 7:32 UTC (permalink / raw)
To: Tegar Syahputra; +Cc: emacs-devel
Tegar Syahputra <dqs7cp2e@gmail.com> writes:
>>> The current `package-upgrade' from package.el delete old package
>>> before installing the new one. This can be problematic if the user
>>> interrupt the process or if there is some network problems.
>>>
>>> `package-install' allow the same package to be installed if the
>>> argument is `package-desc' instead symbol representing package name.
>>> This allow package to be upgraded atomically. Is this a bad idea?
>> No, I think this is a good idea, but it would be best if you could write
>> a Git patch and send it to "bug-gnu-emacs@gnu.org" (you can use M-x
>> submit-emacs-patch).
>
> I'm not part of FSF contributor, and wasn't really thinking of contributing
> directly. Just giving a heads up that's all.
So you are not interested in contributing a patch?
>>> diff -u --label \#\<buffer\ package.el.gz\> --label \#\<buffer\ \*scratch\*\> /tmp/buffer-content-4azQGZ /tmp/buffer-content-x8FLpt
>>> --- #<buffer package.el.gz>
>>> +++ #<buffer *scratch*>
>>> @@ -2275,16 +2275,20 @@
>>> package using this command, first upgrade the package to a
>>> newer version from ELPA by using `\\<package-menu-mode-map>\\[package-menu-mark-install]' after `\\[list-packages]'."
>>> (interactive
>>> - (list (completing-read
>>> - "Upgrade package: " (package--upgradeable-packages) nil t)))
>>> - (let* ((package (if (symbolp name)
>>> - name
>>> - (intern name)))
>>> - (pkg-desc (cadr (assq package package-alist))))
>>> - (if (package-vc-p pkg-desc)
>>> - (package-vc-upgrade pkg-desc)
>>> - (package-delete pkg-desc 'force 'dont-unselect)
>>> - (package-install package 'dont-select))))
>>> + (list (intern (completing-read
>>> + "Upgrade package: " (package--upgradeable-packages) nil t))))
>>> + (let* ((name (if (symbolp name)
>>> + name
>>> + (intern name)))
>> If you always intern the package name, you don't need this check
>> anymore. On the other hand, you don't need to intern the name, because
>> of this check, and I think it is better to keep it because that gives
>> the user more flexibility when invoking the function.
>
> I intern the interactive input because the actual type needed is
> symbol type.
> The check was from original, it accept both string and symbol.
Right, you kept the check (which I think is correct), which makes the
conversion unnecessary.
>>> + (old-pkg-desc (cadr (assq name package-alist)))
>>> + (new-pkg-desc (cadr (assq name package-archive-contents))))
>>> + (if (package-vc-p old-pkg-desc)
>>> + (package-vc-upgrade old-pkg-desc)
>>> + (unwind-protect
>> I am wondering if unwind-protect is the best approach here, or even
>> necessary. Wouldn't something like
>>
>> --8<---------------cut here---------------start------------->8---
>> (when (progn (package-install new-pkg-desc 'dont-select) t)
>> (package-delete old-pkg-desc 'force 'dont-unselect))
>> --8<---------------cut here---------------end--------------->8---
>
> No, you must check if the package is installed. That will always delete
> `old-pkg-desc' even if installation error occurs.
>
>> have the same effect? My reasoning is that we are not actually cleaning
>> anything up in the UNWIND-FORMS, but just checking if the
>> `package-install' was not interrupted, right?
>
> Yes, it's to check if the installations was interrupted or if error occur.
> I don't think `package-install' gives meaningful return that indicates
> package was properly installed. The output it gives could be used but,
> I just thought checking the output string may not be reliable or elegant.
Unless I am mistaken, package-install should raise a signal (ie. causing
a non-local exit). The return value of `package-install' is not
reliable, hence the (progn ... t).
>>> + (package-install new-pkg-desc 'dont-select)
>>> + (if (package-installed-p (package-desc-name new-pkg-desc)
>>> + (package-desc-version new-pkg-desc))
>> If you check the definition of `package-installed-p', you will find it
>> does not use MIN-VERSION if the first argument satisfied
>> `package-desc-p', which makes sense because with a concrete descriptor,
>> we can unambiguously check if a specific package version has been
>> installed (the implementation just checks if the expected directory
>> exists).
>
> Yeah, and new-pkg-desc which is a package-desc from package-archive-contents
> is implied to be remote thus doesn't include directory.
Right, my mistake.
> I'm OP, sorry I didn't configure my email name earlier.
^ permalink raw reply [relevance 99%]
* Re: Adding adoc-mode (a major mode for working with AsciiDoc) to NonGNU ELPA
@ 2023-08-02 12:49 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-08-02 12:49 UTC (permalink / raw)
To: Bozhidar Batsov; +Cc: Emacs Devel
"Bozhidar Batsov" <bozhidar@batsov.net> writes:
> Hey there!
>
> I've taken up the maintenance of adoc-mode
> (https://github.com/bbatsov/adoc-mode) a while ago (see
> https://metaredux.com/posts/2023/03/12/adoc-mode-reborn.html) and I
> was wondering if we can include it in NonGNU ELPA. I think AsciiDoc is
> fairly popular, so it'd be nice if people can get a major mode for
> editing AsciiDoc documents without setting up additional repos. Any
> thoughts on this?
I think it would be nice, do you think there is a chance that it could
be added to GNU ELPA?
^ permalink raw reply [relevance 99%]
* Re: Question about eval and compile-command
@ 2023-08-03 20:02 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-08-03 20:02 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Eli Zaretskii, Eshel Yaron, emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> It looks like Stefan added the 'eval' calls as a minor cleanup and not
>> as part of the change itself. Stefan, any chance you remember why you
>> added the 'eval' calls?
>
> I added it to allow the `compile-command` to be
> (re)computed dynamically.
In retrospect, shouldn't the type be be a string or a function? For
former for a static command, the latter for a dynamically computed one?
>
> Stefan
^ permalink raw reply [relevance 99%]
* Re: Changes to make in elpa-packages file for nongnu elpa
@ 2023-08-08 16:37 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-08-08 16:37 UTC (permalink / raw)
To: Michael Albinus; +Cc: Thierry Volpiatto, emacs-devel
Michael Albinus <michael.albinus@gmx.de> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
> Hi Philip,
>
>>>> Sorry about that, you can always feel free to CC me if you have specific
>>>> questions that might get lost on the mailing list. I suppose Stefan
>>>> Monnier wouldn't object to be mentioned either.
>>>
>>> Ok thanks, I will next time now I know you and Stefan are in charge of
>>> this.
>>
>> I am sort of an unofficial co-maintainer, without access to any
>> server-side infrastructure, but other than that I'm glad to help within
>> my possibilities.
>
> Perhaps it is worth to mention this in admin/MAINTAINERS?
There seems to be no information on ELPA in admin/MAINTAINERS.
> Best regards, Michael.
^ permalink raw reply [relevance 99%]
* Re: Changes to make in elpa-packages file for nongnu elpa
@ 2023-08-09 7:06 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-08-09 7:06 UTC (permalink / raw)
To: Michael Albinus; +Cc: emacs-devel, 'Eli Zaretskii', Stefan Monnier
Michael Albinus <michael.albinus@gmx.de> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
> Hi Philip,
>
>>>> I am sort of an unofficial co-maintainer, without access to any
>>>> server-side infrastructure, but other than that I'm glad to help within
>>>> my possibilities.
>>>
>>> Perhaps it is worth to mention this in admin/MAINTAINERS?
>>
>> There seems to be no information on ELPA in admin/MAINTAINERS.
>
> Yes, the file is incomplete. So it is time to say something about GNU
> ELPA, IMHO.
In that case I'd like to request access to elpa.gnu.org, and ideally
also the list of users who have signed the CA.
I've CC'ed Eli and Stefan.
> Best regards, Michael.
^ permalink raw reply [relevance 99%]
* Re: Changes to make in elpa-packages file for nongnu elpa
@ 2023-08-09 15:24 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-08-09 15:24 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: michael.albinus, emacs-devel, monnier
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: michael.albinus@gmx.de, emacs-devel@gnu.org, monnier@iro.umontreal.ca
>> Date: Wed, 09 Aug 2023 14:53:12 +0000
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> >> In that case I'd like to request access to elpa.gnu.org
>> >
>> > You mean you cannot access it now?
>>
>> I can access it as a user, but I cannot access it to fix something.
>
> Maybe I'm misremembering, but AFAIR if you have write access to the
> Emacs Git repository, you also have write access to the ELPA Git
> repository.
No I have access to emacs.git, elpa.git and nongnu.git, what I was
referent to was the server associated with elpa.gnu.org.
>> >> and ideally also the list of users who have signed the CA.
>> >
>> > No can do, for privacy reasons. You can always ask me or Stefan to
>> > check a name for you, though.
>>
>> OK, but most of the time I don't have to check a single user but would
>> like to see check a set of names to see how many have or haven't signed
>> the CA. Is that still a manageable effort on your end?
>
> Yes, feel free.
OK, thank you for the clarification.
^ permalink raw reply [relevance 99%]
* Re: [elpa] externals/compat 6a60af22da: Optimize string-search
@ 2023-08-11 8:15 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-08-11 8:15 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel, mail
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: Daniel Mendler <mail@daniel-mendler.de>
>> Date: Fri, 11 Aug 2023 06:07:32 +0000
>>
>> I don't believe this is a legal optimisation, even if the regular
>> expression is quoted.
>
> It is certainly "legal", in the sense that it breaks no laws.
>
> The GNU Coding Standards frown on using "legal" or "illegal" for
> anything that doesn't involve the laws and jurisprudence; we use
> "valid" and "invalid" instead.
Ok, I did not know that. Thanks.
^ permalink raw reply [relevance 99%]
* Re: [elpa] externals/compat 6a60af22da: Optimize string-search
@ 2023-08-11 8:17 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-08-11 8:17 UTC (permalink / raw)
To: Daniel Mendler; +Cc: emacs-devel
Daniel Mendler <mail@daniel-mendler.de> writes:
> On 8/11/23 08:07, Philip Kaludercic wrote:
>> ELPA Syncer <elpasync@gnu.org> writes:
>>
>>> branch: externals/compat
>>> commit 6a60af22da1f1a7b08457a4016b9412a475afe4a
>>> Author: Daniel Mendler <mail@daniel-mendler.de>
>>> Commit: Daniel Mendler <mail@daniel-mendler.de>
>>>
>>> Optimize string-search
>>> ---
>>> compat-28.el | 5 ++---
>>> 1 file changed, 2 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/compat-28.el b/compat-28.el
>>> index fe69315522..b305ab2fff 100644
>>> --- a/compat-28.el
>>> +++ b/compat-28.el
>>> @@ -52,9 +52,8 @@ issues are inherited."
>>> (when (and start-pos (or (< (length haystack) start-pos)
>>> (< start-pos 0)))
>>> (signal 'args-out-of-range (list start-pos)))
>>> - (save-match-data
>>> - (let ((case-fold-search nil))
>>> - (string-match (regexp-quote needle) haystack start-pos))))
>>> + (let (case-fold-search)
>>> + (string-match-p (regexp-quote needle) haystack start-pos)))
>>>
>>> (compat-defun length= (sequence length) ;; [[compat-tests:length=]]
>>> "Returns non-nil if SEQUENCE has a length equal to LENGTH."
>>
>> I don't believe this is a legal optimisation, even if the regular
>> expression is quoted. Consider
>
> Hi Philip,
>
> did you notice that I replaced `string-match' with `string-match-p'?
No, I missed that. Never mind then.
> Daniel
^ permalink raw reply [relevance 99%]
* Re: [ELPA] Proposing to add express to ELPA
@ 2023-08-11 18:14 99% ` Philip Kaludercic
1 sibling, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-08-11 18:14 UTC (permalink / raw)
To: Yuan Fu; +Cc: emacs-devel
Yuan Fu <casouri@gmail.com> writes:
>> On Jul 31, 2023, at 11:38 AM, Yuan Fu <casouri@gmail.com> wrote:
>>
>> Hi all,
>>
>> Since Emacs 29 is now released, I’d like to propose adding expreg to
>> ELPA. Expreg can be considered a lite version of expand-region. The
>> notable difference is its use of tree-sitter for language-specific
>> expansions. I also took the liberty to do things differently than
>> expand-region, eg, expreg uses a smaller number of expanders [1]; it
>> is easier to debug when the expansion isn’t what you expected; and
>> it only provides two functions for expansion and contraction, and
>> one variable for adding/removing expanders—no transient maps and
>> other “smart” features, nor different variables to set for each
>> major mode.
>
> What do you think, guys? Should it be added to ELPA?
I think it would be a nice addition, were there any open objections?
> Yuan
^ permalink raw reply [relevance 99%]
* Re: New Package for NonGNU-ELPA: clojure-ts-mode
@ 2023-08-13 6:23 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-08-13 6:23 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: danny, emacs-devel, manuel.uberti
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: danny@dfreeman.email, emacs-devel@gnu.org, manuel.uberti@inventati.org
>> Date: Sat, 12 Aug 2023 20:22:32 +0000
>>
>> This was my understanding as well, and while I understand it from a
>> technical perspective, I have a hunch there must be a tolerable
>> alternative with a better user interface.
>>
>> Perhaps this is a point at which the approach at which the major-mode
>> abstraction breaks down and has to be rethought? There have been
>> instances of alternative major modes for different languages in the past
>> (cperl, perl; js, js2, js3) that have found one way or another to
>> co-exist, but seeing how this is becoming more and more common, it would
>> be nice to have some consistent and unified way of expressing these
>> kinds of alternatives.
>
> If someone suggests such an arrangement, and demonstrates its
> viability in at least one example, we could discuss that and perhaps
> decide on migration towards such an approach. So far, no one came
> with any workable ideas, AFAIR.
OK good to know that there is potential interest. I had a few ideas I
wanted to try out. As soon as (or if ever) I have something working,
I'll push the code to a feature/ branch and ping this thread again
>> > The aspects of these modes that are not yet firmly decided are how to
>> > activate/deactivate them in a way that would be convenient and simple.
>> > But I don't think we will be removing the *-ts-modes as major modes,
>> > no.
>>
>> I get that we wouldn't want to remove them, out of backwards
>> compatibility, but is the plan to write more ...-ts-mode major modes?
>
> Yes, I think so. There doesn't seem to be any good alternative in
> existence.
^ permalink raw reply [relevance 99%]
* Proposal for 'package-isolate' command
@ 2023-08-15 19:39 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-08-15 19:39 UTC (permalink / raw)
To: Eshel Yaron; +Cc: Thierry Volpiatto, emacs-devel
Eshel Yaron <me@eshelyaron.com> writes:
> Hi Philip,
>
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Here is my first attempt at providing this kind of a command. Any
>> comments?
>
> I haven't followed the thread very closely, but this looks quite useful!
> A few minor suggestions:
This is mostly a tangent, so the previous discussion is not that
relevant. I've changed the subject accordingly.
>> diff --git a/etc/NEWS b/etc/NEWS
>> index 57f04609679..c374695a571 100644
>> --- a/etc/NEWS
>> +++ b/etc/NEWS
>> @@ -505,6 +505,12 @@ project, that you can quickly select using 'project-switch-project'
>> When non-nil, package specifications with side-effects for building
>> software will be used when building a package.
>>
>> +---
>> +*** New command to start Emacs only with specific packages
>
> This should probably end with a period.
>
>> +The command 'package-isolate' is equivalent to starting Emacs with the
>> +-Q flag and loading specific packages (and their dependencies)
>> +manually.
>
> I'd rephrase this as: "The command 'package-isolate' starts a new Emacs
> instance with minimum customizations (similar to 'emacs -Q') and a given
> set of packages (with their dependencies)."
>
>> +(defun package-isolate (packages)
>> + "Start a new instance of Emacs and load only PACKAGES."
>
> I'd clarify that the new instance disregards the user's
> config/customizations, how about "Start a new Emacs instance with
> minimum customizations and load PACKAGES."
>
>> +DEFUN ("emacs-executable", Femacs_executable, Semacs_executable, 0, 0, "",
>> + doc: /* Return a string with the file name of the Emacs executable.
>> +If this is not known, nil will be returned instead. */)
>
> Maybe say "Return the file name of the Emacs executable, or nil if
> unknown." to steer clear of the passive voice.
Thanks, I obviously cannot write documentation. I've addressed the
changes locally, and will send an updated patch in response to Eli's
message.
> Best,
>
> Eshel
^ permalink raw reply [relevance 99%]
* Re: [ELPA] New Package: phpinspect.el
@ 2023-08-15 20:28 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-08-15 20:28 UTC (permalink / raw)
To: Hugo Thunnissen; +Cc: Stefan Monnier, emacs-devel
Hugo Thunnissen <devel@hugot.nl> writes:
> On 8/12/23 06:56, Stefan Monnier wrote:
>>> I would like to propose my package, phpinspect.el, to be added to GNU Elpa.
>> Done.
>>
>> AFAICT the code has currently some significant problems in terms of
>> dependencies which make its compilation fail because variables are used
>> by macros during compilation when the var has not yet been defined, or
>> macros are used before they're defined, etc...
>>
>> The patch below seems to make the compilation go through (and fixes
>> various warnings), but there are a lot of compilation warnings left
>> which you might want to check. It also includes a few FIXMEs.
>>
>>
>> Stefan
>>
>>
>
> And here I was thinking that I had fixed all of the byte compilation
> problems.. Turns out it was only working because I byte compiled
> everything within the same emacs session. I made some changes and
> think things should be in order now. At least, the following shell
> script doesn't seem to result in any errors:
>
> for file in ./*.el; do
> cask emacs -batch -L . --eval '(setq byte-compile-error-on-warn
> t)' -f batch-byte-compile "$file" || break
> done
I am not familiar with Cask, what does this provide over a simple
Makefile?
> I see some warnings in your log that concern files in the "benchmark"
> and "test" directories. These files are not required for the package
> to function. Can these be excluded from the ELPA build somehow? I have
> seen some projects use a "lisp" directory for their source code, is
> that the recommended approach for this?
You can add an .elpaignore file to your package root. You can list all
files in there that you do not with to have added to a package tarball.
The file is passed to GNU tar's -X option (see (info "(tar) exclude")).
> Thanks,
>
> - Hugo
^ permalink raw reply [relevance 99%]
* Re: [ELPA] New Package: phpinspect.el
@ 2023-08-15 21:56 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-08-15 21:56 UTC (permalink / raw)
To: Hugo Thunnissen; +Cc: Stefan Monnier, emacs-devel
Hugo Thunnissen <devel@hugot.nl> writes:
> On 8/15/23 22:28, Philip Kaludercic wrote:
>>
>> I am not familiar with Cask, what does this provide over a simple
>> Makefile?
>
>
> It locally installs the package's dependencies and starts emacs with a
> clean profile that only has those dependencies available. It doesn't
> do much, but it's easy to use and it seems to help prevent "it works
> with my setup" scenarios. I only started using it recently though so
> I'm not very familiar with it, nor am I very skilled with make for
> that matter ;)
>
> What would a simple Makefile for a typical elisp package look like? Is
> it common practice to create clean environments like cask does?
This article goes into it https://nullprogram.com/blog/2020/01/22/,
though I understand now that it doesn't do the same thing (or at least
you would have to manually implement something like creating a clean
environment or installing dependencies).
^ permalink raw reply [relevance 99%]
* Re: Changes to make in elpa-packages file for nongnu elpa
@ 2023-08-16 18:52 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-08-16 18:52 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: thievol, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: emacs-devel@gnu.org
>> Date: Wed, 16 Aug 2023 10:10:46 +0000
>>
>> +---
>> +*** New command to start Emacs only with specific packages
>> +The command 'package-isolate' is equivalent to starting Emacs with the
>> +-Q flag and loading specific packages (and their dependencies)
>> +manually.
>
> If this is how this feature is going to be implemented, I suggest to
> reword this NEWS entry to make the intent and the feature easier to
> understand:
>
> *** New command to start an inferior Emacs loading only specific packages.
> The new command 'package-isolate' will start a new Emacs process, as
> a sub-process of Emacs where you invoke the command, in a way that
> causes the new process to load only some of the installed packages.
> The command prompts for the packages to activate in this
> sub-process, and is intended for testing Emacs and/or the packages
> in a clean environment.
As usual, I prefer your phrasing. Will update the patch.
^ permalink raw reply [relevance 99%]
* Re: master 5892b4db8de 2/3: Convert dictionary-mode to define-derived-mode
@ 2023-08-16 22:33 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-08-16 22:33 UTC (permalink / raw)
To: Visuwesh; +Cc: emacs-devel, Stefan Kangas
Visuwesh <visuweshm@gmail.com> writes:
> [சனி ஆகஸ்ட் 12, 2023] Stefan Kangas wrote:
>
>> branch: master
>> commit 5892b4db8de4694904f631dd86438926fb9d7ff1
>> Author: Stefan Kangas <stefankangas@gmail.com>
>> Commit: Stefan Kangas <stefankangas@gmail.com>
>>
>> Convert dictionary-mode to define-derived-mode
>>
>> * lisp/net/dictionary.el (dictionary-instances): Delete.
>> (dictionary-mode): Use define-derived-mode.
>> (dictionary--count-mode-buffers): New function.
>> (dictionary-close): Use above new function.
>
>> +(defun dictionary--count-mode-buffers ()
>> + "Return the number of buffers that "
>
> The docstring is incomplete here. :-(
>
>> + (seq-reduce #'+
>> + (mapcar
>> + (lambda (buf)
>> + (with-current-buffer buf
>> + (if (derived-mode-p 'dictionary-mode) 1 0)))
>> + (buffer-list))
>> + 0))
>> +
>
> I believe the following function should be faster
>
> (defun dictionary--count-mode-buffers ()
> "Return the number of buffers that "
> (seq-reduce (lambda (count buf)
> (if (provided-mode-derived-p (buffer-local-value 'major-mode buf)
> 'dictionary-mode)
> (+ count 1)
> count))
> (buffer-list)
> 0))
Alternatively (length (match-buffers '(derived-mode . dictionary-mode)))
^ permalink raw reply [relevance 99%]
* Re: Proposal for 'package-isolate' command
@ 2023-08-17 14:04 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-08-17 14:04 UTC (permalink / raw)
To: Thierry Volpiatto; +Cc: emacs-devel
Thierry Volpiatto <thievol@posteo.net> writes:
> Hello Philip,
>
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Thierry Volpiatto <thievol@posteo.net> writes:
>>
>>> Philip Kaludercic <philipk@posteo.net> writes:
>>>
>>>>> No don't worry, helm will work in any cases, thanks.
>>>>
>>>> OK, in that case I'd prefer to keep it the way it is.
>>>
>>> Ok, fair enough.
>>>
>>>>>> Mainly to avoid issues with packages that might place files in the
>>>>>> configuration directory, which might hinder the reproduction of bugs.
>>>>>
>>>>> Hmm, maybe, I don't have an example in mind though.
>>>>
>>>> It might not be the best example, but my package autocrypt generates a
>>>> file in the `user-emacs-directory'. If we don't use --init-directory,
>>>> the existing file would be re-used.
>>>
>>> Ok, for such case it is easy to either rename the file temporarily to
>>> foo_ori or foo_save or to set the variable handling the file (generally
>>> it is not harcoded) to something else. But another issue is if your
>>> isolated package needs the history file or tramp file or whatever file
>>> ~/.emacs.d is handling; e.g. a package providing completion on history.
>>> I still think it is more handy to reuse user-emacs-directory and its
>>> elpa directory where the packages are already installed.
>>
>> How about this patch, that will use a temporary directory when
>> `package-isolate' is invoked with a prefix argument (not sure what the
>> default should be, I guess reusing `user-emacs-directory' is less
>> surprising):
>
> Yes.
>
> Isn't these two loop the same? (save one loop)
No, because that assumes that we are only interested in the first
package descriptor in every package--alist entry, while there might be
multiple.
> (cl-loop for p in (cl-loop for p in (package--alist) append (cdr p))
> unless (package-built-in-p p)
Also, do we want this or wouldn't it be useful to be able to force a
built-in package being loaded?
> collect (cons (package-desc-full-name p) p) into table
> finally return
> (list (cl-loop for c in (completing-read-multiple
> "Isolate packages: " table
> nil t)
> collect (alist-get c table nil nil #'string=))
> current-prefix-arg))
>
> (cl-loop for p in (package--alist)
> for desc = (cadr p)
> for name = (car p)
> unless (package-built-in-p desc)
> collect (cons (package-desc-full-name desc) p) into table
> finally return
> (list (cl-loop for c in (completing-read-multiple
> "Isolate packages: " table
> nil t)
> append (cdr (alist-get c table nil nil #'string=)))
> current-prefix-arg))
>
>
>> [2. text/x-diff;
>> 0001-Add-command-to-start-Emacs-with-specific-packages.patch]...
^ permalink raw reply [relevance 99%]
* Re: Proposal for 'package-isolate' command
@ 2023-08-17 14:19 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-08-17 14:19 UTC (permalink / raw)
To: Eshel Yaron; +Cc: Thierry Volpiatto, emacs-devel
Eshel Yaron <me@eshelyaron.com> writes:
> Hi Philip,
>
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> How about this patch, that will use a temporary directory when
>> `package-isolate' is invoked with a prefix argument (not sure what the
>> default should be, I guess reusing `user-emacs-directory' is less
>> surprising):
>
> I'm again looking forward to trying this out, I think it could be
> helpful for testing the Compat integration I'm working on for a package
> of mine. I also again have a couple of minor suggestions around
> documentation:
>
>> (defun package--dependencies (pkg)
>> - "Return a list of all dependencies PKG has.
>> -This is done recursively."
>> - ;; Can we have circular dependencies? Assume "nope".
>> - (when-let* ((desc (cadr (assq pkg package-archive-contents)))
>> - (deps (mapcar #'car (package-desc-reqs desc))))
>> - (delete-dups (apply #'nconc deps (mapcar #'package--dependencies deps)))))
>> + "Return a list of all recursive dependencies of PKG.
>
> I'd say "transitive" rather than "recursive" dependencies, because I
> think a recursive dependency is more commonly used to refer to a case in
> which a package (or library, etc.) depends on itself.
I wouldn't say recursive but cyclical in that case, but either way I
think transitive is a better word here. Will change it.
>> +If PKG is a package descriptor, the return value will consist of
>> +a list of package descriptors. If PKG is a symbol, designating a
>> +package, the return value will be a list of symbols designating
>> +packages."
>
> Personally, I find the future tense less clear than the present tense
> when describing deterministic software behavior. So usually I prefer it
> when the docs say what the program "does", not what it "will do". In
> this case that be "if PKG is a package descriptor, the return value is a
> list of package descriptors..."
Right, makes sense as well.
> Best,
>
> Eshel
^ permalink raw reply [relevance 99%]
* Re: [ELPA] Proposing to add express to ELPA
@ 2023-08-19 9:04 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-08-19 9:04 UTC (permalink / raw)
To: Yuan Fu; +Cc: emacs-devel
Yuan Fu <casouri@gmail.com> writes:
>> On Aug 11, 2023, at 10:14 AM, Yuan Fu <casouri@gmail.com> wrote:
>>
>>
>>
>>> On Jul 31, 2023, at 11:38 AM, Yuan Fu <casouri@gmail.com> wrote:
>>>
>>> Hi all,
>>>
>>> Since Emacs 29 is now released, I’d like to propose adding expreg
>>> to ELPA. Expreg can be considered a lite version of
>>> expand-region. The notable difference is its use of tree-sitter for
>>> language-specific expansions. I also took the liberty to do things
>>> differently than expand-region, eg, expreg uses a smaller number of
>>> expanders [1]; it is easier to debug when the expansion isn’t what
>>> you expected; and it only provides two functions for expansion and
>>> contraction, and one variable for adding/removing expanders—no
>>> transient maps and other “smart” features, nor different variables
>>> to set for each major mode.
>>
>> What do you think, guys? Should it be added to ELPA?
>>
>> Yuan
>
> I think I might have write access to ELPA, so if no one objects and no one adds it to ELPA, I’ll add it later :-)
If you have access to emacs.git, you should also have access to
elpa.git. Just make sure to test building the package locally before
pushing anything.
> Yuan
^ permalink raw reply [relevance 99%]
* Re: master 5892b4db8de 2/3: Convert dictionary-mode to define-derived-mode
@ 2023-08-19 15:46 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-08-19 15:46 UTC (permalink / raw)
To: Stefan Kangas; +Cc: Visuwesh, emacs-devel
Stefan Kangas <stefankangas@gmail.com> writes:
> Philip Kaludercic <philipk@posteo.net>:
>
>> Alternatively (length (match-buffers '(derived-mode . dictionary-mode)))
>
> Nice golfing, thanks. I installed that.
Though one should note that it does cons unnecessarily. It probably
doesn't matter that much, due to the scope of the problem, but perhaps
it would be a good idea to add an optional COUNT argument to
`match-buffer', like the one that was added to `directory-files'.
^ permalink raw reply [relevance 99%]
* Re: Proposal for 'package-isolate' command
@ 2023-08-20 20:28 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-08-20 20:28 UTC (permalink / raw)
To: Thierry Volpiatto; +Cc: emacs-devel
Thierry Volpiatto <thievol@posteo.net> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> An issue I see here, is that a required version might not be satisfied
>> by the version of the package returned by `package-get-descriptor'. Or
>> am I mistaken?
>
> So I guess we need a function that get the dependencies from installed
> packages and one from all to fit with what we previously had.
> If one wants to have all the dependencies for a given package not
> already installed, there is actually nothing available.
> Also `package-menu--list-to-prompt` is now wrong when used as prompt for
> package-install.
I think a sufficient solution might be just to extend
`package-get-descriptor' with an optional MIN-VERSION argument.
>> "Not easy" in the sense that you are not familiar with how it works, or
>> thin k it shouldn't be used? All in all, `named-let' just compiles down
>> to a cl-labels call, similar to the one you propose.
>
> Not familiar.
Ok.
^ permalink raw reply [relevance 99%]
* Re: Preferred approach to inclusion of data in ELPA package
@ 2023-08-20 20:42 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-08-20 20:42 UTC (permalink / raw)
To: Hugo Thunnissen; +Cc: emacs-devel
Hugo Thunnissen <devel@hugot.nl> writes:
> On 8/19/23 17:51, Philip Kaludercic wrote:
>> Hugo Thunnissen <devel@hugot.nl> writes:
>>
>>> On 8/17/23 23:14, Philip Kaludercic wrote:
>>>> Another idea is to have a Makefile generate the file, like the one you
>>>> describe in option 2., that is generate whenever the package is built
>>>> and bundled into a tarball for distribution. That way you don't have to
>>>> store a binary blob in your repository, and you can avoid burdening the
>>>> user with additional computations at either compile or runtime.
>>>>
>>>> Does the generation require any special functionality/tools/code to be
>>>> provided on the device the index is generated on?
>>> The php function/class stubs are generated with a php script, but I'm
>>> checking the resulting stubs file into git. The index itself can be
>>> built with just my package based on the stubs file.
>> I saw that, and the commit did not look that nice, but I cannot say that
>> I have looked into the issue in sufficient detail to say with certainty
>> or not that there is no better solution.
>>
> There are alternatives or improvements to this approach, which I
> mentioned in my response to sbaug
> (https://lists.gnu.org/archive/html/emacs-devel/2023-08/msg00748.html)
> . I don't think I'll be able to get around having to distribute-, or
> having the user download/generate some kind of index though.
If PHP were available in the ELPA build environment, do you think that
would change anything?
>>> Also: If the former is the case, is the reduction in load time that
>>> this brings even significant enough to be worth the bother or should I
>>> just hold off on this while I look for a more efficient solution?
>> I'd say it would be worth it, if the resulting package would be smaller
>> and would load quicker. After all, the performance on your laptop might
>> not be that significant of a difference, while for someone else with an
>> older or slower device, a 30%-speedup is pretty significant.
>
> You're right, on less performant systems it could make a more
> significant difference. And good news, after a few improvements the
> load time is now down to ~150ms on my laptop. I also chose to load the
> data when the mode is first initialized, so simply loading my package
> won't cause the index to be loaded with it. The dumping of the index
> is done automatically when it is not present, so it would technically
> be fine to just distribute the PHP stubs with the package instead of
> the .eld index file. This would just make the user wait a little
> longer the first time they use the mode.
Would it be possible to load the information when it is required
(e.g. necessary for completion)?
^ permalink raw reply [relevance 99%]
* Re: Org mode and Emacs
@ 2023-08-21 7:56 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-08-21 7:56 UTC (permalink / raw)
To: Richard Stallman
Cc: Eli Zaretskii, yantar92, bzg, yantar92, theophilusx, 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 don't know why Richard made that request.
>
> I don't remember making that request. I must have done so, but I
> don't know why.
>
> Can someone please show me that message? Once i see its date,
> I can find the pertinent messages in my saved old mail, and
> think about this.
These were the two messages referenced in the thread:
https://yhetil.org/emacs-devel/E1ocmvz-0002iB-2M@fencepost.gnu.org/
https://list.orgmode.org/orgmode/87bkqx4jyg.fsf@localhost/
^ permalink raw reply [relevance 99%]
* Re: New Package for NonGNU-ELPA: clojure-ts-mode
@ 2023-08-25 7:20 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-08-25 7:20 UTC (permalink / raw)
To: Danny Freeman; +Cc: Eli Zaretskii, emacs-devel, manuel.uberti
Danny Freeman <danny@dfreeman.email> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> There seems to be no objection against adding it, despite the name. Can
>> you confirm that this is the latest version of the patch you would like
>> to have applies to nongnu.git:
>>
>> From baf7c0d081cbda5760c8f7523780316fcb041714 Mon Sep 17 00:00:00 2001
>> From: dannyfreeman <danny@dfreeman.email>
>> Date: Sat, 12 Aug 2023 14:31:44 -0400
>> Subject: [PATCH] * elpa-packages (clojure-ts-mode): new package
>>
>> ---
>> elpa-packages | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/elpa-packages b/elpa-packages
>> index 9dac0cd..6ea2057 100644
>> --- a/elpa-packages
>> +++ b/elpa-packages
>> @@ -87,6 +87,10 @@
>> :ignored-files ("clojure-mode-extra-font-locking.el" "doc" "test" "test.clj")
>> :news "CHANGELOG.md")
>>
>> + (clojure-ts-mode :url "https://github.com/clojure-emacs/clojure-ts-mode"
>> + :readme "README.md"
>> + :news "CHANGELOG.md")
>> +
>> (coffee-mode :url "https://github.com/defunkt/coffee-mode")
>>
>> (corfu-terminal :url "https://codeberg.org/akib/emacs-corfu-terminal")
>
> Yes, I can confirm this is the patch. The latest version also includes
> the .elpaignore file you mentioned so everything should be set.
>
> Thank you,
Done :)
^ permalink raw reply [relevance 99%]
* Re: [elpa] externals/standard-themes 0604883ecc: Expand 'deftheme' with metadata
[not found] ` <20230825045847.7DFE9C1D362@vcs2.savannah.gnu.org>
@ 2023-08-25 7:43 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-08-25 7:43 UTC (permalink / raw)
To: emacs-devel; +Cc: Protesilaos Stavrou
ELPA Syncer <elpasync@gnu.org> writes:
> branch: externals/standard-themes
> commit 0604883ecc89f37f2d8fcb33ec3c8f7f2b8bbe2e
> Author: Protesilaos Stavrou <info@protesilaos.com>
> Commit: Protesilaos Stavrou <info@protesilaos.com>
>
> Expand 'deftheme' with metadata
>
> This is to support new features in Emacs where themes can specify
> the set they belong to, as well as whether they are light or dark.
> The built-in command is 'theme-choose-variant'.
>
> This is in response to Emacs bug#65468:
> <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=65468>. Thanks to
> Mauro Aranda for bringing this matter to my attention.
> ---
> standard-dark-theme.el | 9 +++++----
> standard-light-theme.el | 9 +++++----
> 2 files changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/standard-dark-theme.el b/standard-dark-theme.el
> index 726e888915..cf863c7fa4 100644
> --- a/standard-dark-theme.el
> +++ b/standard-dark-theme.el
> @@ -40,8 +40,12 @@
> (eval-and-compile
> (require 'standard-themes)
>
> +;;;###theme-autoload
> (deftheme standard-dark
> - "Like the unthemed dark Emacs, but more consistent.")
> + "Like the unthemed dark Emacs, but more consistent."
> + :background-mode 'dark
> + :kind 'color-scheme
> + :family 'standard)
Please note that this will cause an issue for anyone using the package
before Emacs 29, because deftheme only accepts 1-2 arguments before
da2e6da72296.
> (defconst standard-dark-palette
> '(;; Basic tones
> @@ -246,7 +250,4 @@ represents."
>
> (provide-theme 'standard-dark))
>
> -;;;###theme-autoload
> -(put 'standard-dark 'theme-properties '(:background-mode dark :kind color-scheme :family standard))
> -
> ;;; standard-dark-theme.el ends here
> diff --git a/standard-light-theme.el b/standard-light-theme.el
> index 3c7e518548..a4fcf16b82 100644
> --- a/standard-light-theme.el
> +++ b/standard-light-theme.el
> @@ -40,8 +40,12 @@
> (eval-and-compile
> (require 'standard-themes)
>
> +;;;###theme-autoload
> (deftheme standard-light
> - "Like the unthemed light Emacs, but more consistent.")
> + "Like the unthemed light Emacs, but more consistent."
> + :background-mode 'light
> + :kind 'color-scheme
> + :family 'standard)
>
> (defconst standard-light-palette
> '(;; Basic tones
> @@ -246,7 +250,4 @@ represents."
>
> (provide-theme 'standard-light))
>
> -;;;###theme-autoload
> -(put 'standard-light 'theme-properties '(:background-mode light :kind color-scheme :family standard))
> -
> ;;; standard-light-theme.el ends here
^ permalink raw reply [relevance 99%]
* Re: [NonGNU ELPA] New package: hyperdrive (repost)
@ 2023-08-26 11:55 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-08-26 11:55 UTC (permalink / raw)
To: Joseph Turner
Cc: Emacs Devel Mailing List, Adam Porter, Paula Maas,
Protesilaos Stavrou
It would usually be better to just ping the previous thread, in case
the discussion died down to quickly. From the archives, it seems there
was no further discussion on the matter, or did I miss something?
Joseph Turner <joseph@ushin.org> writes:
> Hello all,
>
> Adam Porter and I have been working on an Emacs interface
> (<https://git.sr.ht/~ushin/hyperdrive.el>) for managing hyperdrives,
> which are real-time, versioned, p2p filesystems.
> (<https://docs.holepunch.to/building-blocks/hyperdrive>).
>
> Some features have already been implemented and described in the manual
> (<https://ushin.org/hyperdrive-manual.html>). We plan to work on a peer
> discovery mechanism so you can announce interest in a topic, e.g.
> "Emacs", and discover other online peers who share that topic interest.
>
> I look forward to hearing feedback!
>
> Best,
>
> Joseph
>
>
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Org mode and Emacs
@ 2023-08-26 20:28 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-08-26 20:28 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Jose E. Marchesi, Eli Zaretskii, rms, bzg, emacs-devel
Ihor Radchenko <yantar92@posteo.net> writes:
> "Jose E. Marchesi" <jemarch@gnu.org> writes:
>
>> I think the point here is not just these particular marks, or some other
>> particular set. It is that "markdown-style" formats, like org-mode, are
>> not very good supporting "inline" marking.
>>
>> For inline marks, Texinfo uses a conventient generic and extensible
>> form: @NAME{CONTENT}.
>
> That's what we plan to add to Org. Not just because of this discussion;
> there are other reasons why we want such custom inline markup.
Do you have a reference where I could read up on how this is going?
>> Block marks are usually supported well enough by these formats. In the
>> case of org it would be #+BEGIN_WHATEVER end #+END_WHATEVER I suppose.
>
> Yup.
^ permalink raw reply [relevance 99%]
* Re: [NonGNU ELPA] New package: llm
@ 2023-08-27 13:11 99% ` Philip Kaludercic
1 sibling, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-08-27 13:11 UTC (permalink / raw)
To: Andrew Hyatt; +Cc: rms, emacs-devel
Andrew Hyatt <ahyatt@gmail.com> writes:
> I've now made the changes requested to the llm package on github (
> https://github.com/ahyatt/llm).
>
> Because what was requested was a warning to the user, I used `lwarn', and
> have added an option to turn the warnings off (and the user can turn the
> warnings off through the warning mechanism as well, via
> `warning-suppress-log-types').
>
> To save you the trouble of looking at the code to see what exactly it says,
> here's the function I'm using to warn:
>
> (defun llm--warn-on-nonfree (name tos)
> "Issue a warning if `llm-warn-on-nonfree' is non-nil.
> NAME is the human readable name of the LLM (e.g 'Open AI').
>
> TOS is the URL of the terms of service for the LLM.
>
> All non-free LLMs should call this function on each llm function
> invocation."
> (when llm-warn-on-nonfree
> (lwarn '(llm nonfree) :warning "%s API is not free software, and your
> freedom to use it is restricted.
> See %s for the details on the restrictions on use." name tos)))
>
> If this is sufficient, please consider accepting this package into GNU ELPA
> (see above where we decided this is a better fit than the Non-GNU ELPA).
I would be fine with this, and would go ahead if there are no objections.
>
> On Sat, Aug 12, 2023 at 9:43 PM Richard Stallman <rms@gnu.org> wrote:
>
>> [[[ To any NSA and FBI agents reading my email: please consider ]]]
>> [[[ whether defending the US Constitution against all enemies, ]]]
>> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>>
>> > What you are saying is consistent with the GNU coding standard.
>> However, I
>> > think any message about this would be annoying,
>>
>> I am sure it would be a little annoying. But assuming the user can
>> type SPC and move on from that message, the annoyance will be quite
>> little.
>>
>> personally, and would
>> be a
>> > deterrent for clients to use this library.
>>
>> If the library is quite useful I doubt anyone would be deterred.
>> If anyone minded it the message enough to stop using the package, perse
>> could
>> edit this out of the code.
>>
>> This issue is an example of those where two different values are
>> pertinent. There is convenience, which counts but is superficial.
>> And there is the purpose of the GNU system, which for 40 years has led
>> the fight against injustice in software. That value is deep and, in the
>> long term, the most important value of all.
>>
>> When they conflict in a specific practical matter, there is always
>> pressure to prioritize convenience. But that is not wise.
>> The right approach is to look for a ocmpromise which serves both
>> goals. I am sure we can find one here.
>>
>> I suggested showing the message once a day, because that is what first
>> occurred to me. But there are lots of ways to vary the details.
>> Here's an idea. For each language model, it could diisplay the
>> message the first, second, fifth, tenth, and after that every tenth
>> time the user starts that mode. With this, the frequency of little
>> annoyance will diminish soon, but the point will not be forgotten.
>>
>>
>> You made suggestions for how to exclude more code from Emacs itself,
>> and support for obscure language models we probably should exclude.
>> But there is no need to exclude the support for the well-known ones,
>> as I've explained.
>>
>> And we can do better than that! We can educate the users about what
>> is wrong with those systems -- something that the media hysteria fails
>> to mention at all. That is important -- let's use Emacs for it!
>>
>> > All implementations can then separately be made available on some other
>> > package library not associated with GNU. In this scenario, I wouldn't
>> have
>> > warnings on those implementations, just as the many llm-based packages
>> on
>> > various alternative ELPAs do not have warnings today.
>>
>> They ought to show warnings -- the issue is exactly the same.
>>
>> We should not slide quietly into acceptance and normalization of a new
>> systematic injustice. Opposing it is our job.
>>
>> --
>> Dr Richard Stallman (https://stallman.org)
>> Chief GNUisance of the GNU Project (https://gnu.org)
>> Founder, Free Software Foundation (https://fsf.org)
>> Internet Hall-of-Famer (https://internethalloffame.org)
>>
>>
>>
^ permalink raw reply [relevance 99%]
* Re: [NonGNU ELPA] New package: hyperdrive (repast)
@ 2023-08-29 11:56 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-08-29 11:56 UTC (permalink / raw)
To: Joseph Turner
Cc: Emacs Devel Mailing List, Adam Porter, Paula Maas,
Protesilaos Stavrou
Joseph Turner <joseph@ushin.org> writes:
>> My main difficulty is understanding what Hyperdrive is...
>
> Hyperdrive is a p2p file-sharing tool (like Dropbox, but FLOSS and with
> no third-party intermediary; like Bittorrent, but mutable and versioned;
> like IPFS, but without CIDs and faster for mutable data).
>
> User story: Alice creates a new hyperdrive and adds some files. Her
> computer returns a public key URL that uniquely identies the hyperdrive.
> Alice shares that URL with Bob, who can then download Alice's files
> directly from Alice's computer (no third-party servers are required to
> route the connection - they find each other using a DHT or using mDNS if
> they're on the same LAN). Bob can download some of Alice's without
> having to load her whole drive.
>
> Data is distributed on the network; once Bob has loaded Alice's files,
> Carol can get them from Bob even when Alice is offline. Drives are
> mutable; When Alice adds/removes/changes files in the drive, Bob can
> refresh her drive on his machine to get the latest changes. Drives are
> versioned; anyone with the URL can "check out" prior versions of Alice's
> drive to see what her files used to look like.
>
> There's more info in the manual, especially in the Concepts section:
>
> https://ushin.org/hyperdrive/hyperdrive-manual.html#Concepts
>
> There's also this talk at LibrePlanet 2023. Comparison of peer-to-peer
> protocols starts @36:49:
>
> https://media.libreplanet.org/u/libreplanet/m/emacs-for-p2p-deliberation/
Thanks!
>> The second issue I have is that there is quite a lot of code, and
>> I'd like to take a look at everything before I add anything.
>
> Take your time. I'm happy to get on a videocall to go through the code
> together with you.
That is not necessary, I'll understand what is going on, the issue is
just finding the time to at least skim through everything once.
> Thank you!
>
> Joseph
^ permalink raw reply [relevance 99%]
* Re: Choice of bug tracker
@ 2023-08-29 11:58 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-08-29 11:58 UTC (permalink / raw)
To: Eli Zaretskii
Cc: Dmitry Gutov, danny, stefankangas, emacs-devel, manuel.uberti
Eli Zaretskii <eliz@gnu.org> writes:
>> Date: Tue, 29 Aug 2023 00:16:09 +0300
>> Cc: philipk@posteo.net, danny@dfreeman.email, stefankangas@gmail.com,
>> emacs-devel@gnu.org, manuel.uberti@inventati.org
>> From: Dmitry Gutov <dmitry@gutov.dev>
>>
>> > The problem from my POV was that alternatives were researched, the
>> > results of the research were published and discussed, the downsides
>> > identified, and then the process stalled, perhaps because people got
>> > disappointed by the deficiencies.
>>
>> Last time we produced this overblown list which mixed necessities with
>> nice-to-haves: https://gitlab.com/gitlab-org/gitlab/-/issues/28152
>
> That list is just our reference and a repository of ideas that came up
> in the discussions. The real requirements are simpler:
>
> . we must have support for feature we have now on debbugs
We count the fact that everything can everything can be done via Email
as a feature, right?
> . we should decide which additional features are the absolute
> minimum to justify the switch (those which will attract
> contributors, make feedback easier, and help people who are more
> used to PR-type workflow)
> . all the other features that debbugs doesn't have are a bonus, but
> not hard requirements
^ permalink raw reply [relevance 99%]
* Re: Why shouldn't we have a #if .... #else .... #endif construct in Emacs Lisp?
@ 2023-08-29 12:54 99% ` Philip Kaludercic
1 sibling, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-08-29 12:54 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: emacs-devel
Alan Mackenzie <acm@muc.de> writes:
> Hello, Emacs.
>
> In C, we have the very useful conditional compilation directives
> introduced by #if or #ifdef, etc., which end at #end.
>
> In Emacs Lisp we have no such construct. This is a Bad Thing.
>
> More and more, especially recently, irritating warning messages are
> occurring for, for example, obsolete variables and functions inside
> conditionals which ensure they aren't used. For example:
>
> (when (< emacs-major-version 24)
> (defadvice .....))
>
> produces the warning about defadvice being obsolete. (I haven't actually
> tested this example). What we really want here is for the defadvice only
> to be _compiled_ when (< emacs-major-version 24), rather than compiled
> unconditionally and not run.
In this specific case, would it be possible to use the nadvice
compatibility package on GNU ELPA?
> I propose a new function, hash-if, which would do what we want. The
> above example could then be written something like:
>
> (hash-if (< emacs-major-version 24)
> (defadvice .....)
> (advice-add .....))
>
> .. This is not actually all that difficult to write. My first attempt
> uses a compiler-macro, and looks like this:
>
> (defun hash-if (condition if-part &rest else-part)
> "A compiler macro analogous to C's #if.
> CONDITION is evaluated at compile time. If it is non-nil,
> IF-PART gets compiled. Otherwise ELSE-PART (enclosed in a
> `progn') gets compiled."
> (declare (indent 2))
> (error "hash-if has been called directly"))
>
> (put 'hash-if 'compiler-macro
> (lambda (form condition if-part &rest else-part)
> (if (eval condition lexical-binding)
> if-part
> (cons 'progn else-part))))
Would something like work as well:
--8<---------------cut here---------------start------------->8---
(defmacro cif (test then &rest else)
"Evaluate TEST during macro-expansion and return THEN or ELSE."
(if (eval test t) then else))
--8<---------------cut here---------------end--------------->8---
> .. I propose adding it to subr.el, just before (defmacro when ....).
>
> What do people think about this?
^ permalink raw reply [relevance 99%]
* Re: Preferred approach to inclusion of data in ELPA package
@ 2023-08-30 19:27 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-08-30 19:27 UTC (permalink / raw)
To: Hugo Thunnissen; +Cc: emacs-devel
Hugo Thunnissen <devel@hugot.nl> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Hugo Thunnissen <devel@hugot.nl> writes:
>>
>>> On 8/19/23 17:51, Philip Kaludercic wrote:
>>>> Hugo Thunnissen <devel@hugot.nl> writes:
>>>>
>>>>> On 8/17/23 23:14, Philip Kaludercic wrote:
>>>>>> Another idea is to have a Makefile generate the file, like the one you
>>>>>> describe in option 2., that is generate whenever the package is built
>>>>>> and bundled into a tarball for distribution. That way you don't have to
>>>>>> store a binary blob in your repository, and you can avoid burdening the
>>>>>> user with additional computations at either compile or runtime.
>>>>>>
>>>>>> Does the generation require any special functionality/tools/code to be
>>>>>> provided on the device the index is generated on?
>>>>> The php function/class stubs are generated with a php script, but I'm
>>>>> checking the resulting stubs file into git. The index itself can be
>>>>> built with just my package based on the stubs file.
>>>> I saw that, and the commit did not look that nice, but I cannot say that
>>>> I have looked into the issue in sufficient detail to say with certainty
>>>> or not that there is no better solution.
>>>>
>>> There are alternatives or improvements to this approach, which I
>>> mentioned in my response to sbaug
>>> (https://lists.gnu.org/archive/html/emacs-devel/2023-08/msg00748.html)
>>> . I don't think I'll be able to get around having to distribute-, or
>>> having the user download/generate some kind of index though.
>>
>> If PHP were available in the ELPA build environment, do you think that
>> would change anything?
>>
>
> Theoretically, yes, as I would not have to check the stubs into version
> control. Is this a realistic scenario though? To generate stubs, I
> currently require a PHP installation with a whole slew of extensions
> installed to be able to generate stubs for them. Currently, I only do
> this for PHP 8.2, but I will probably end up having to do this for more
> versions of PHP. That is a whole lot of packages that would have to be
> present in ELPA's build environment. And the list of extensions is not
> guaranteed to be static either.
In that case I had underestimated the effort. While not perfect, it
seems the best approach for now might well be to track the generated
file in the Git repository :/
> My current idea is to create container images for each version of PHP
> and generate stub files by executing the generation scripts in these
> containers. To give you an idea of the list of required packages, this
> is an example of the installation step in a Dockerfile I'm using:
>
> RUN apt-get update && apt-get -y install \
> php8.2-memcached \
> php-redis \
> php8.2-bcmath \
> php8.2-bz2 \
> php8.2-cli \
> php8.2-common \
> php8.2-curl \
> php8.2-gmp \
> php8.2-intl \
> php-json \
> php8.2-mbstring \
> php8.2-mysql \
> php8.2-odbc \
> php8.2-opcache \
> php8.2-pgsql \
> php8.2-readline \
> php8.2-tidy \
> php8.2-xml \
> php8.2-xsl \
> php8.2-zip \
> php8.2-gd \
> php-bcmath \
> php-apcu \
> php-cli \
> php-imagick \
> php-intl \
> php-xdebug \
> php-amqp
>
>>>>> Also: If the former is the case, is the reduction in load time that
>>>>> this brings even significant enough to be worth the bother or should I
>>>>> just hold off on this while I look for a more efficient solution?
>>>> I'd say it would be worth it, if the resulting package would be smaller
>>>> and would load quicker. After all, the performance on your laptop might
>>>> not be that significant of a difference, while for someone else with an
>>>> older or slower device, a 30%-speedup is pretty significant.
>>>
>>> You're right, on less performant systems it could make a more
>>> significant difference. And good news, after a few improvements the
>>> load time is now down to ~150ms on my laptop. I also chose to load the
>>> data when the mode is first initialized, so simply loading my package
>>> won't cause the index to be loaded with it. The dumping of the index
>>> is done automatically when it is not present, so it would technically
>>> be fine to just distribute the PHP stubs with the package instead of
>>> the .eld index file. This would just make the user wait a little
>>> longer the first time they use the mode.
>>
>> Would it be possible to load the information when it is required
>> (e.g. necessary for completion)?
>
> This is a good idea. Classes within the project's scope are already
> parsed/indexed on demand like that, I should apply this to stub classes
> as well.
>
> Global/native functions are another story though. Since they're not
> namespaced, it's hard to break them into smaller loadable sets. Aside
> from that, function completion generally requires the list of functions
> to be loaded indiscriminately. Luckily, the functions only make up a
> little over 1/4th of the stubs (~2000 out of ~7300 lines).
^ permalink raw reply [relevance 99%]
* Re: package-autosuggest
@ 2023-08-31 5:38 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-08-31 5:38 UTC (permalink / raw)
To: Stefan Monnier
Cc: Eli Zaretskii, stefankangas, yandros, bozhidar, dmitry, rms,
danny, emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> +(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)
>
> I think we should strive to minimize the dependency on `package.el` (as
> well as the performance impact) so we should try and use something like
> `fboundp` here instead (testing "the function" provided by the package
> when it's installed).
Would you argue it would be better to implement this feature outside of
package.el? And by function we mean something like the major mode of a
package, right?
>
> Stefan
^ permalink raw reply [relevance 99%]
* Re: Bundling ELPA packages with Emacs
@ 2023-08-31 6:10 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-08-31 6:10 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: rms, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Richard Stallman <rms@gnu.org>
>> Cc: emacs-devel@gnu.org
>> Date: Wed, 30 Aug 2023 22:07:44 -0400
>>
>> > The current idea of including ELPA packages is to include them in the
>> > release tarball, so that for the end-user it looks exactly like a core
>> > package.
>>
>> We can do that with some GNU ELPA packages, but the GNU Project cannot
>> distribute NonGNU ELPA packages as part of GNU Emacs.
>
> It is indeed planned to do that only with packages on GNU ELPA. But
> we haven't yet figured some important aspects of including ELPA
> packages in release tarballs, so the idea is there, but it is not yet
> actionable.
I was under the assumption that issue was resolved, if
`package-directory-list' would contain the right directory?
^ permalink raw reply [relevance 99%]
* Re: Brand new clojure support in Emacs ;-)
@ 2023-08-31 7:01 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-08-31 7:01 UTC (permalink / raw)
To: Kévin Le Gouguec
Cc: João Távora, Richard Stallman, Danny Freeman,
Eli Zaretskii, emacs-devel, Manuel Uberti
Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:
> João Távora <joaotavora@gmail.com> writes:
>
>> Philip Kaludercic <philipk@posteo.net> writes:
>>
>>>> Why? If the NonGNU people are "too cool for school" after having been
>>>> invited to GNU, why should the GNU project make even more special
>>>> accomodations for them? Not up to me to decide anyway.
>>>
>>> Mainly because this will affect users, not the maintainer.
>>> [...]
>>> Also, I don't see a reason to provoke the Clojure-mode maintainers. I
>>> disagree with their reasoning and fear they have been misinformed, but
>>> the best way to remedy situations like these is to be understanding and
>>> prove ourselves to be cooperative by example (IMO).
>>
>> You seem to be under the misguided impression that my proposal is meant
>> to bother, provoke or help change the minds of the NonGNU Clojure
>> maintainers? It's not.
>>
>> I simply think they shouldn't have a say in how the Emacs project
>> answers Richard's original request of a Clojure editing mode in Emacs
>> propoer.
>
> IMHO that is disproportionately combative. Regardless of whether
> clojure-mode maintainers contribute to core and/or GNU ELPA, they
> contribute to Emacs's continued success by serving their users's needs
> and keeping these users invested in Emacs.
>
> I think they deserve the courtesy of not encroaching if alternatives can
> be found; I second Philip's assessment above.
>
>> As to naming, it's not my call, so let's have Richard chime in.
>> clojure-mode, newclojure-mode, etc, I personally don't care, since I'm
>> not a Clojure user.
>
> My 2¢, as a passive observer, not a Clojure programmer either, whose
> only interests lie in (a) alienating as few people as possible (b)
> getting dopamine hits from finding specks of consistency amidst chaos:
>
> * "lisp-clojure-mode", following other "FAMILY-DIALECT-mode" examples
> like "makefile-gmake-mode",
>
> * no specific name (keep the name from the inherited mode,
> lisp-data-mode in your example), just a mode-line hint, following
> other "FAMILY[DIALECT]" examples like sh-script and
> "Shell-script[bash]".
I like these ideas as well, even though I am hesitant to call Clojure a
Lisp proper ;)
^ permalink raw reply [relevance 99%]
* Re: New Package for NonGNU-ELPA: clojure-ts-mode
@ 2023-08-31 11:35 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-08-31 11:35 UTC (permalink / raw)
To: Ihor Radchenko
Cc: Dmitry Gutov, Stefan Kangas, Danny Freeman, Eli Zaretskii,
emacs-devel, manuel.uberti
Ihor Radchenko <yantar92@posteo.net> writes:
> Dmitry Gutov <dmitry@gutov.dev> writes:
>
>> - Talking to our users (better, more familiar access to bug tracking
>> first and foremost, but anything that makes mailing lists friendlier
>> would also be a win; GitHub has "Discussions" which are pretty nice, but
>> that seems entirely out of reach).
>
> What about using something other than forge for discussions?
> On Org ML, we have recently discussed an idea to have Discourse as the
> means for users to interact with the mailing list via web UI:
> https://list.orgmode.org/orgmode/87edvxnnqw.fsf@localhost/
Do you have an example of how this looks like, eg. a link to both a
mailing list archive and a discourse forum?
> Discourse has free licence, can be self-hosted, and has mailing list
> integration.
^ permalink raw reply [relevance 99%]
* Re: [NonGNU ELPA] New package: flymake-guile
@ 2023-09-01 13:09 99% ` Philip Kaludercic
0 siblings, 2 replies; 200+ results
From: Philip Kaludercic @ 2023-09-01 13:09 UTC (permalink / raw)
To: Distopico; +Cc: emacs-devel
Distopico <distopico@riseup.net> writes:
> On 2023-08-31, Philip Kaludercic <philipk@posteo.net> wrote:
>
>> Distopico <distopico@riseup.net> writes:
>>
>>> On 2023-08-31, Philip Kaludercic <philipk@posteo.net> wrote:
>>>
>>>> Distopico <distopico@riseup.net> writes:
>>>>
>>>>> Hi all!
>>>>>
>>>>> I'm the author of a new package `flymake-guile` and I
>>>>> would like to include it in Nongnu ELPA.
>>>>
>>>> Just to be sure, you are sure you don't want to include your package in
>>>> GNU ELPA?
>>>>
>>>>> Here the repo: https://framagit.org/flymake-backends/flymake-guile
>>>>
>>>> I am not familiar with the "flymake-quickdef" package, but it doesn't
>>>> seem to be much shorter than just defining a regular flymake backend.
>>>> As there have been some discussions wrt providing a kind of DSL for
>>>> Flymake backends, I am not sure if adding flymake-quickdef would be that
>>>> constructive at this point. Would you consider updating your package to
>>>> not use the dependency? You can check out other flymake-... modes in
>>>> GNU and NonGNU ELPA for inspiration.
>>>>
>>> Thank you for your feedback, For now I'm fine sending it to NonGNU ELPA,
>>> and for now I would like to keep `flymake-quickdef`, I have plans to
>>> write other backend and I don't wanna repeat the same validations and
>>> code over and over, I'll switch to the DLS when it is implemented.
>>
>> FWIW it already exists in this form https://github.com/mohkale/flymake-collection.
>>
>> And just to make sure, you are certain you want to implement this on top
>> of a DSL? I have to admit that I am really not a fan of the way that
>> flymake-quickdef is implemented, but one redeeming feature appears to be
>> that you could macroexpand it away, then clean the code up.
>>
>
> flymake-collection use an adaptation of flymake-quickdef[1], that is
> a macro similar to the quickdef one[2], could be use quickdef a blocker
> to add the package on NonGNU ELPA?
I am afraid I don't understand your question.
^ permalink raw reply [relevance 99%]
* Re: [NonGNU ELPA] New package: flymake-guile
@ 2023-09-01 13:52 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-09-01 13:52 UTC (permalink / raw)
To: Dr. Arne Babenhauserheide; +Cc: Distopico, emacs-devel
"Dr. Arne Babenhauserheide" <arne_bab@web.de> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>>> flymake-collection use an adaptation of flymake-quickdef[1], that is
>>> a macro similar to the quickdef one[2], could be use quickdef a blocker
>>> to add the package on NonGNU ELPA?
>>
>> I am afraid I don't understand your question.
>
> I think it means: "do I have to or can I stick to the plans I have?"
>
> Basically: is this a requirement to be added, or is it a suggestion that
> Distopico can decide not to take.
If Distopico insists on having the `flymake-quickdef' added to NonGNU
ELPA, I will do so, but I advise against it.
> Best wishes,
> Arne
^ permalink raw reply [relevance 99%]
* Re: package-autosuggest
@ 2023-09-01 15:47 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-09-01 15:47 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Eshel Yaron, Stefan Kangas, emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> The current proposal wouldn't install anything automatically anyway, it
>> would prompt the user if they are interested in this kind of a file
>
> Also, the system should make it easy to "just say no", so the prompt
> should only appear once (unless the user explicitly chooses to "do
> nothing for now, but remind me later").
Right, which is why I think that the user option to aggressively prompt
the user to install a package is misguided. The most sensible options I
think are to generate a message every time a fundamental-mode buffer is
found with a matching package, or just once for every package.
^ permalink raw reply [relevance 99%]
* Re: Monthy emacs-devel digest, similar to "This month in Org"
@ 2023-09-02 19:17 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-09-02 19:17 UTC (permalink / raw)
To: emacs-devel
Here is a demonstration of how this kind of a medium could look like:
https://amodernist.com/eaez/
This is just a mockup, but it seems like something that can be
reasonably maintained as long as I continue to regularly follow the
mailing list and track new additions to ELPA.
Philip Kaludercic <philipk@posteo.net> writes:
> Ihor Radchenko <yantar92@posteo.net> writes:
>
>> Philip Kaludercic <philipk@posteo.net> writes:
>>
>>> There comes a point where people have to accept that mailing lists
>>> What I think the Org project does well is the "This month in Org" line
>>> of posts, that help highlight contributions from newcomers and
>>> familiarise those familiar with a mailing list with the procedures going
>>> on here.
>>
>> This is actually quite an effort. AFAIK, the author had difficulties
>> allocating time to write more posts for TMiO.
>>
>> Also, for reference, we are talking about
>> https://blog.tecosaur.com/tmio/2022-05-31-folding.html
>
> TMiO might be too detailed and reliant on a single person, which might
> be part of the problem in keeping it rolling. I cannot evaluate that,
> because I didn't follow the project in too much detail.
>
> My initial plan (see https://amodernist.com/texts/elpa-zine.html) was
> just to focus on ELPA-related development, such as new packages or
> updates, since this is what most users are probably also interested in.
> An idea that was discussed, and that might be emphasises in greater
> detail could be to have a sort of "builtin-board" for announcements of
> more important news or help requests from core ELPA development.
>
> I think it is obvious, that this kind of a thing would have to be a
> collaborative effort. While it only requires a single or just a few
> people to compile this kind of a post/newsletter,
>
>>> ... I have mentioned the idea of a ELPA
>>> newsletter somewhere around here once, but upon reflection, it seems
>>> like a TMIO-like idea should be implemented to the entire
>>> core-development, not just the ELPAs. Would anyone here be interested
>>> in working on something like that?
>>
>> A somewhat relevant effort is by Sacha Chua:
>> https://sachachua.com/blog/2023/08/2023-08-28-emacs-news/
>>
>> It is less detailed (just an outline), but I find it pretty useful.
>
> Crucially it is incomplete, when it comes to core development. There
> are frequently longer discussions and bugs that never get mentioned on
> the newsletter, even though they *should* be highlighted *and* explained
> for an average user, especially if their feedback is what is needed.
>
> On the other hand, the newsletter is as complete as it gets wrt all the
> other news (I am under the impression that it summarises every
> blog-post, reddit-submission, video, etc. published on the topic of
> Emacs over the last week), which is not what I am interested in.
>
> Timothy <orgmode@tec.tecosaur.net> writes:
>
>> Hi Ihor,
>>
>>> This is actually quite an effort. AFAIK, the author had difficulties
>>> allocating time to write more posts for TMiO.
>>>
>>> Also, for reference, we are talking about
>>> <https://blog.tecosaur.com/tmio/2022-05-31-folding.html>
>>
>> Each post took several hours to do, despite how short they were. The major
>> difficulty is in making sure that I’ve read as much as I can in that month, and
>> trying to feel like I’ve treated most contributions “fairly” (i.e. not missing
>> people out) which requires looking at the ML + git log since the last TMiO.
>>
>> For what it’s worth, once the org-latex-preview branch gets merged, I plan on
>> doing another TMiO with the disclaimer that I may have missed out a bunch of
>> things in that edition.
>>
>> Something else we could do is have some sort of “community draft” as is now
>> being done on the Julia discourse, which could help reduce the individual
>> workload (ref: <https://discourse.julialang.org/t/this-month-in-julia-world-2023-08/103242>).
>
> I am not sure what this means, does one person create a summary of what
> has been going on and others comment on it before it is published on a
> proper blog?
>
>> All the best,
>> Timothy
>
> John Yates <john@yates-sheets.org> writes:
>
>> Writing new content (à la Linux Weekly News) is a massive effort. I would
>> expect any attempt at such a product to peter out in short order.
>>
>> A big, big +1 for Sacha's weekly Emacs News. I find it just the right
>> level of detail. It directs one to Emacs mail threads, upcoming events and
>> get togethers, blogs and Reddit posts, Youtube videos, etc. And, IIRC, she
>> is even set up to accept contributions from others. Let's support her.
>
> I am not proposing an alternative toe Emacs News in any sense. What I
> am trying to convince people in joining me bootstrap is a medium that is
> published less frequently, goes into more detail on core-development and
> ELPA news and ideally wouldn't be written by a single person, but
> feature more guest posts.
>
>> /john
^ permalink raw reply [relevance 99%]
* Re: Why shouldn't we have a #if .... #else .... #endif construct in Emacs Lisp?
@ 2023-09-02 19:20 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-09-02 19:20 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: Stefan Kangas, emacs-devel, Mattias Engdegård
Alan Mackenzie <acm@muc.de> writes:
> +;; Note: `static-if' handles the version of `eval' without the &optional
> +;; parameter LEXICAL so that it can be copied unchanged for use in older
> +;; Emacsen.
Is this really a concern for the version that would be added to Emacs itself?
> +(defmacro static-if (condition then-form &rest else-forms)
> + "A conditional compilation macro analogous to C's #if.
> +Evaluate CONDITION at macro-expansion time. If it is non-nil,
> +expand the macro to THEN-FORM. Otherwise expand it to ELSE-FORMS
> +enclosed in a `progn' form. ELSE-FORMS may be empty."
> + (declare (indent 2)
> + (debug (sexp sexp &rest sexp)))
> + (if (condition-case err
> + (eval condition lexical-binding)
> + ((wrong-number-of-arguments void-variable) (eval condition))
> + ((debug error) (signal (car err) (cdr err))))
> + then-form
> + (cons 'progn else-forms)))
^ permalink raw reply [relevance 99%]
* Re: Monthy emacs-devel digest, similar to "This month in Org"
@ 2023-09-03 5:47 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-09-03 5:47 UTC (permalink / raw)
To: Yuan Fu; +Cc: emacs-devel
Yuan Fu <casouri@gmail.com> writes:
>> On Sep 2, 2023, at 12:17 PM, Philip Kaludercic <philipk@posteo.net> wrote:
>>
>>
>> Here is a demonstration of how this kind of a medium could look like:
>>
>> https://amodernist.com/eaez/
>>
>> This is just a mockup, but it seems like something that can be
>> reasonably maintained as long as I continue to regularly follow the
>> mailing list and track new additions to ELPA.
>
> I like it. I can send you some progress report on tree-sitter (not
> unlike what I sent to emacs-devel) and some package/faeture ideas, if
> you decide to soft-launch this.
That would be great. I hope to have enough material to publish a proper
edition at the month.
> Yuan
^ permalink raw reply [relevance 99%]
* Re: Monthy emacs-devel digest, similar to "This month in Org"
@ 2023-09-03 9:39 99% ` Philip Kaludercic
1 sibling, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-09-03 9:39 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Ihor Radchenko, casouri, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Ihor Radchenko <yantar92@posteo.net>
>> Cc: Yuan Fu <casouri@gmail.com>, emacs-devel@gnu.org
>> Date: Sun, 03 Sep 2023 08:03:38 +0000
>>
>> > That would be great. I hope to have enough material to publish a proper
>> > edition at the month.
>>
>> +1. Looks nice.
>>
>> You may also consider announcing that you are gathering a material in a
>> dedicated emacs-devel thread. Then, users can reply with proposals.
>> Or maintainers may ping you in the threads that should be brought to
>> wider audience (like help requests).
>
> I'm not sure I understand the details of this. Where would this
> digest be published? I hope not on emacs-devel itself -- we have more
> than enough volume of traffic here.
I'll be publishing it for now on my personal site, perhaps I might move
it to some other location, but I'd not post it here, don't worry. The
target audience are precisely people who don't follow the mailing list.
> Emacs News gets posted to
> emacs-tangents, so I think that should be the preferred forum for this
> digest as well.
>
> Apologies if I misunderstood something.
No problem.
^ permalink raw reply [relevance 99%]
* Re: Monthy emacs-devel digest, similar to "This month in Org"
@ 2023-09-03 9:40 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-09-03 9:40 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Eli Zaretskii, casouri, emacs-devel
Ihor Radchenko <yantar92@posteo.net> writes:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> You may also consider announcing that you are gathering a material in a
>>> dedicated emacs-devel thread. Then, users can reply with proposals.
>>> Or maintainers may ping you in the threads that should be brought to
>>> wider audience (like help requests).
>>
>> I'm not sure I understand the details of this. Where would this
>> digest be published?
>
> https://amodernist.com/eaez/
>
>> ... I hope not on emacs-devel itself -- we have more
>> than enough volume of traffic here. Emacs News gets posted to
>> emacs-tangents, so I think that should be the preferred forum for this
>> digest as well.
>
> I proposed to drop some kind of monthly thread here, on emacs-devel, in
> case if you or other contributors want to encourage feedback or ask for
> help from more users.
I have created a separated mailing list here, to avoid noise over here:
https://lists.sr.ht/~pkal/elpa-zine.
^ permalink raw reply [relevance 99%]
* Re: master c290b034e0f 1/2: Move `wholenump` alias definition
@ 2023-09-03 10:46 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-09-03 10:46 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Mattias Engdegård, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Mattias Engdegård <mattias.engdegard@gmail.com>
>> Date: Sun, 3 Sep 2023 12:22:07 +0200
>> Cc: philipk@posteo.net,
>> emacs-devel@gnu.org
>>
>> 3 sep. 2023 kl. 12.07 skrev Eli Zaretskii <eliz@gnu.org>:
>>
>> > I'm guessing that was for compatibility with some other Lisp.
>>
>>
>> Maybe an obscure dialect (can't find it in Common Lisp, MacLisp or Interlisp).
>>
>> The symbol `wholenump` is most commonly seen by users in errors as
>> it's generated by CHECK_FIXNAT. It would be good to change that to
>> the less obscure `natnump`, and it seems implausible that such a
>> change would break any code. Any objections?
>
> You assume that "natnump" will be much more clear? why?
The term natural number is less likely to confuse a reader (though it is
not perfect either, due to disagreements on whether or not 0 is a
natural number).
> It will definitely break decade-long habits, and for what? for the
> benefit of some abstract rigor?
^ permalink raw reply [relevance 99%]
* Re: [IDEA] Add function clean-buffer
@ 2023-09-04 16:02 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-09-04 16:02 UTC (permalink / raw)
To: Joseph Turner; +Cc: Emacs Devel Mailing List, mail+gh
Joseph Turner <joseph@breatheoutbreathe.in> writes:
> Prompted by Daniel Mendler's comment here:
>
> https://github.com/emacs-compat/compat/issues/27#issuecomment-1704381157
>
> IIUC, clean-mode is intended for interactive, debugging usage. I am
> interested in a function that performs some of the internal behavior of
> the Emacs 29 clean-mode in non-interactive use. Note that
> yank-excluded-properties is not set in clean-buffer.
Perhaps you could explain what the concrete example is where you need
the functionality?
>
> (defun clean-buffer (&optional buffer)
> "Remove all local variables, overlays, and text properties in BUFFER.
> When BUFFER is nil, act on current buffer."
> (with-current-buffer (or buffer (current-buffer))
> (kill-all-local-variables t)
> (let ((inhibit-read-only t))
> (dolist (overlay (overlays-in (point-min) (point-max)))
> (delete-overlay overlay))
> (set-text-properties (point-min) (point-max) nil))))
>
> It could also be used internally in clean-mode.
Could you prepare this as a patch?
> Joseph
^ permalink raw reply [relevance 99%]
* Re: Adding refactoring capabilities to Emacs
@ 2023-09-04 20:49 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-09-04 20:49 UTC (permalink / raw)
To: Juri Linkov
Cc: Dmitry Gutov, João Távora, Yuri Khan, Eli Zaretskii,
emacs-devel
Juri Linkov <juri@linkov.net> writes:
>>> Note: Files are not saved automatically, because this is a different
>>> concern.
>>
>> "Not saving files automatically" is a power-user approach too.
>>
>> We have that in query-replace and naturally in
>> xref-query-replace-in-results too, but having a large refactoring across
>> many files end up in a not-synced-to-disk condition is a complication. Not
>> everyone knows about save-some-buffers and auto-revert-mode.
>
> This is a real problem. Diff mode requires typing a long sequence of
> 'C-c C-a C-c C-a C-c C-a C-c C-a ...' to apply the whole diff.
I had proposed adding a command to diff-mode, that would apply the
entire buffer. It appears that was not applied.
>
> A possible solution would be to support a region by 'C-c C-a'.
> Then it will be possible to activate the region on the whole buffer
> or on a few hunks, and type a single 'C-c C-a'.
>
> Another problem that the changes are not saved automatically
> on multiple files. This limitation forces to use tricks like
> 'M-| git apply RET' after selecting the whole diff buffer with 'C-x h'
> or a region of the diff buffer. A "poor man's auto-save".
^ permalink raw reply [relevance 99%]
* Re: [NonGNU ELPA] New package: flymake-guile
@ 2023-09-05 7:08 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-09-05 7:08 UTC (permalink / raw)
To: Distopico; +Cc: emacs-devel
Distopico <distopico@riseup.net> writes:
> Hi Philip,
>
> On 2023-09-01, Philip Kaludercic <philipk@posteo.net> wrote:
>
>>>>>
>>>>> flymake-collection use an adaptation of flymake-quickdef[1], that is
>>>>> a macro similar to the quickdef one[2], could be use quickdef a blocker
>>>>> to add the package on NonGNU ELPA?
>>>>
>>>> I am afraid I don't understand your question.
>>>
>>> My Question is if remove flymake-quickdef as dependency is a requirement
>>> to merge flymake-guile package into NonGNU ELPA or it's just a
>>> recommendation?
>>
>> It is a strong recommendation. FWIW I have done the work of
>> macroexpanding and cleaning the resulting code up (but there is still
>> some more work to be done), and you can see what I had in mind:
>>
>
> I just made those change in the repo, you can check those now:
> https://framagit.org/flymake-backends/flymake-guile, and BTW I added
> `.elpaignore`, attache the patch adding just `flymake-guile`.
Great, thank you very much. I'll push the changes to nongnu.git. Are
you otherwise familiar with the process of how ELPAs work?
^ permalink raw reply [relevance 99%]
* Re: [ELPA] New package: breadcrumb.el
@ 2023-09-05 10:16 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-09-05 10:16 UTC (permalink / raw)
To: João Távora; +Cc: emacs-devel
João Távora <joaotavora@gmail.com> writes:
> On Tue, Sep 5, 2023 at 7:21 AM Philip Kaludercic <philipk@posteo.net> wrote:
>
>> >> If possible, it would be nice to track this on your end with a
>> >> .elpaignore file.
>> >
>> > That's perfectlky doable, but I do think it makes a bit more sense like
>> > this. Why do you think it's "nicer"? And can we merge it as is for now
>> > (so I can tick this off my todo? ;-)
>>
>> The advantage of having this information locally in your repository is
>> that if anything changes (files are added or renamed), it is easier to
>> update what files shouldn't be bundled in the release tarball, instead
>> of having to change stuff in elpa.git. I guess in your case it doesn't
>> matter that much because you also have push-access to the repository.
>> "Nice" just means that we avoid small "Add foo.bar to :ignored-files for
>> baz" commits, that are more noisy than useful.
>
> I guess so, but there's also the case to be made that we want to keep
> repos package-repository-agnostic. breadcrumb.el is really intended to go
> into GNU ELPA . But maybe straight.el has a .straightignore and so on...
> And el-get (if it is still alive) has something else, etc.
> IMO it's a good principle to have meta info nearest to where it's
> actually used, and in this case it would be elpa.git. But as I said,
> I don't mind adding it, so if you want open a PR over at the breadcrumb
> upstream and I'll merge it.
Done.
> Anyway, if there are no objections, and you don't beat me to it, I'll
> push the (revised) patch to elpa.git later today.
Done.
> João
^ permalink raw reply [relevance 99%]
* Re: another stats problem, example solution [stats.el]
@ 2023-09-05 11:53 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-09-05 11:53 UTC (permalink / raw)
To: emacs-devel
Emanuel Berg <incal@dataswamp.org> writes:
> John Haman wrote:
>
>> Seems neither statistical (having to do with inferring
>> something about a population from a sample) or topical.
>
> `1-'
What I believe that John is trying to say is that the development
mailing list seems to be the wrong place to share your script, unless
you are proposing to add something specific to Emacs?
^ permalink raw reply [relevance 99%]
* Re: [ELPA] New package: ob-asymptote.el
@ 2023-09-05 17:12 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-09-05 17:12 UTC (permalink / raw)
To: Stefan Kangas; +Cc: Jarmo Hurri, emacs-devel
Stefan Kangas <stefankangas@gmail.com> writes:
> Jarmo Hurri <jarmo.hurri@iki.fi> writes:
>
>> Jarmo Hurri <jarmo.hurri@iki.fi> writes:
>>
>>>> The package can be found at
>>>>
>>>> https://github.com/hurrja/ob-asymptote
>>>
>>> Is this new package package ready to be pushed, since no issues have
>>> come up, and it has been over a week?
>>
>> A gentle bump.
>
> Is there anything blocking this package from going in?
I don't think so, I am just confused why I appear to not find any
previous discussion on this in the archives.
^ permalink raw reply [relevance 99%]
* Re: [ELPA] New package: breadcrumb.el
@ 2023-09-05 17:39 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-09-05 17:39 UTC (permalink / raw)
To: João Távora; +Cc: Jonas Bernoulli, emacs-devel
João Távora <joaotavora@gmail.com> writes:
> On Tue, Sep 5, 2023 at 5:55 PM Philip Kaludercic <philipk@posteo.net> wrote:
>
>> > Not sure I 100% understand what you mean, but if you propose a
>> > patch I'll happily merge it.
>>
>> I believe Jonas is proposing a change along these lines,
>
> OK, I pushed it.
If I had known that you are fine with patches for this package, I could
have saved myself from bothering with GitHub earlier ;)
> João
^ permalink raw reply [relevance 99%]
* Re: master 82cc1f4fda1: Revert use of seq-count in shr-count
@ 2023-09-06 22:21 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-09-06 22:21 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: karthikchikmagalur, emacs-devel, stefankangas
Eli Zaretskii <eliz@gnu.org> writes:
>> Date: Wed, 06 Sep 2023 14:34:35 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: philipk@posteo.net, emacs-devel@gnu.org, stefankangas@gmail.com
>>
>> > From: Karthik Chikmagalur <karthikchikmagalur@gmail.com>
>> > Cc: emacs-devel@gnu.org, stefankangas@gmail.com
>> > Date: Tue, 05 Sep 2023 17:02:03 -0700
>> >
>> > > I think we should start by measuring its actual performance as
>> > > compared to more "traditional" implementations. Then we will have the
>> > > base line and data for making the decisions.
>> >
>> > There are some benchmarks by Kisaragi Hiu comparing seq, cl-lib and dash
>> > on Emacs 28.1 here:
>> >
>> > https://kisaragi-hiu.com/performance-cl-lib-dash-seq/
>> >
>> > seq appears to be much slower than cl-lib.
>>
>> Then I agree that we should convert to seq with caution, only where we
>> are sure that the slowdown won't matter much, and we should always
>> time the old vs the new code before making the decision.
>
> Of course, speeding up seq would be even better.
There seems to be ways for common lisp to statically dispatch the right
implementations, but I don't understand enough of it to judge if
something like this would be possible for cl-generic:
https://github.com/marcoheisig/fast-generic-functions
^ permalink raw reply [relevance 99%]
* Re: Proposal to add Popper to ELPA
@ 2023-09-08 17:25 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-09-08 17:25 UTC (permalink / raw)
To: Karthik Chikmagalur; +Cc: Mauro Aranda, emacs-devel
Karthik Chikmagalur <karthikchikmagalur@gmail.com> writes:
>> :type '(repeat (choice regexp
>> (symbol :tag "Major Mode")
>> (function :tag "Predicate Function")
>> (cons (choice regexp
>> (symbol :tag "Major Mode"))
>> (const :tag "Hide" hide))))
>
> Thanks, I improved the documentation for this user option and added this
> customization type. I think this addresses all the issues raised by
> Philip.
One more point, the user option `popper-echo-dispatch-keys' seems to
have a broken type. Shouldn't it be something like
(repeat (choice key-sequence character))
with proper tag annotations?
Other than that, I have added the package to the archive, thanks for
contributing your package!
> Karthik
^ permalink raw reply [relevance 99%]
* Re: [ELPA] New package: ob-asymptote.el
@ 2023-09-08 17:28 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-09-08 17:28 UTC (permalink / raw)
To: Stefan Kangas; +Cc: Jarmo Hurri, emacs-devel
Stefan Kangas <stefankangas@gmail.com> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> The requirements section mentioned that "asy-mode" is necessary, but
>> there is no package for that. I guess that is a blocker, unless the
>> information is outdated.
>
> Jarmo, could we please delete that part so that we can add this package?
If the comment is outdated, this shouldn't block adding the package to
ELPA. I am just not in a position to judge this, as I cannot really
test the package.
^ permalink raw reply [relevance 99%]
* Re: [NonGNU ELPA] New package: llm
@ 2023-09-12 9:57 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-09-12 9:57 UTC (permalink / raw)
To: Andrew Hyatt; +Cc: rms, jporterbugs, emacs-devel
Andrew Hyatt <ahyatt@gmail.com> writes:
> To bring this thread back to the original purpose: It doesn't seem like
> there are any objections to having this package in GNU ELPA, in its current
> form. I'd like to resolve this long-running discussion by committing the
> first version. I believe I have commit access, so if no one does object, I
> can add this to GNU ELPA myself. I'll do so on Friday (September 15th),
> unless someone wants me to hold off.
No objections from my side.
> Another question is whether this should be one package or many. The
> many-package option would have the llm and llm-fake package in the main llm
> package, with a package for all llm clients, such as llm-openai and
> llm-vertex (which are the two options I have now). If someone has an
> opinion on this, please let me know.
I think it would be easier to have it distributed as a single package,
but no strong opinions here.
>
>
> On Wed, Sep 6, 2023 at 9:21 PM Richard Stallman <rms@gnu.org> wrote:
>
>> [[[ To any NSA and FBI agents reading my email: please consider ]]]
>> [[[ whether defending the US Constitution against all enemies, ]]]
>> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>>
>> > The warn functionality in emacs does this already: it will pop up a
>> buffer
>> > with a warning. The user can choose, by clicking on the (-) symbol to
>> the
>> > left, to suppress the warning, or suppress the popup. Since the warn
>> > functionality is built-into emacs, I prefer to use it then create a
>> similar
>> > functionality that is nonstandard.
>>
>> That is a good approach for this.
>>
>> A few days ago, someone asked if it might be possible
>> to have a general Emacs-wide way of customizing warnings
>> and notifications that would apply to the various mechanisms.
>> It could be a good idea. If someone wants to think about what
>> specific customizations this might do, that might lead to ideas
>> to implement.
>>
>>
>> --
>> Dr Richard Stallman (https://stallman.org)
>> Chief GNUisance of the GNU Project (https://gnu.org)
>> Founder, Free Software Foundation (https://fsf.org)
>> Internet Hall-of-Famer (https://internethalloffame.org)
>>
>>
>>
^ permalink raw reply [relevance 99%]
* Re: [nongnu] elpa/helm 07dacfe2e2 08/11: Prefer string-match-p over string-suffix-p
[not found] ` <20230914105954.20BD1C051D0@vcs2.savannah.gnu.org>
@ 2023-09-14 12:25 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-09-14 12:25 UTC (permalink / raw)
To: emacs-devel; +Cc: Thierry Volpiatto
ELPA Syncer <elpasync@gnu.org> writes:
> branch: elpa/helm
> commit 07dacfe2e2db980a9e42afef2fc8539c155fdd0d
> Author: Thierry Volpiatto <thievol@posteo.net>
> Commit: Thierry Volpiatto <thievol@posteo.net>
>
> Prefer string-match-p over string-suffix-p
> ---
> helm-lib.el | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/helm-lib.el b/helm-lib.el
> index 2a93271f57..70df22089c 100644
> --- a/helm-lib.el
> +++ b/helm-lib.el
> @@ -1732,7 +1732,7 @@ Directories expansion is not supported."
> (with-temp-buffer
> (call-process-shell-command
> (format cmd
> - (if (string-suffix-p ".gz" file)
> + (if (string-match-p ".gz\\'" file)
Is there a reason for this preference? Also, I assume you want to quote
the period in ".gz\\'"? If so, I can recommend using `rx' or
`wildcard-to-regexp' to avoid mistakes like these.
> "gzip -c -q -d" "cat")
> (shell-quote-argument file)
> regexp)
^ permalink raw reply [relevance 99%]
* Re: [nongnu] elpa/helm 07dacfe2e2 08/11: Prefer string-match-p over string-suffix-p
@ 2023-09-14 13:06 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-09-14 13:06 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel, thievol
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: Thierry Volpiatto <thievol@posteo.net>
>> Date: Thu, 14 Sep 2023 12:25:55 +0000
>>
>> ELPA Syncer <elpasync@gnu.org> writes:
>>
>> > --- a/helm-lib.el
>> > +++ b/helm-lib.el
>> > @@ -1732,7 +1732,7 @@ Directories expansion is not supported."
>> > (with-temp-buffer
>> > (call-process-shell-command
>> > (format cmd
>> > - (if (string-suffix-p ".gz" file)
>> > + (if (string-match-p ".gz\\'" file)
>>
>> Is there a reason for this preference?
>
> I think this change is simply incorrect: the first argument of
> string-suffix-p is not interpreted as a regexp, but as a simple
> literal string (the implementation uses compare-strings internally).
But why is it incorrect? `string-suffix-p' is passed a string, while
`string-match-p' takes a regular expression, that might be too liberal
but should still match everything the previous check did -- or am I
missing something?
>> Also, I assume you want to quote the period in ".gz\\'"?
>
> No need to quote it, see above.
^ permalink raw reply [relevance 99%]
* Re: [nongnu] elpa/helm 07dacfe2e2 08/11: Prefer string-match-p over string-suffix-p
@ 2023-09-14 16:21 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-09-14 16:21 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel, thievol
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: emacs-devel@gnu.org, thievol@posteo.net
>> Date: Thu, 14 Sep 2023 13:06:47 +0000
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> > I think this change is simply incorrect: the first argument of
>> > string-suffix-p is not interpreted as a regexp, but as a simple
>> > literal string (the implementation uses compare-strings internally).
>>
>> But why is it incorrect? `string-suffix-p' is passed a string, while
>> `string-match-p' takes a regular expression, that might be too liberal
>> but should still match everything the previous check did -- or am I
>> missing something?
>
> Why do the change when string-suffix-p already ensures there's nothing
> in the second argument after the suffix?
I don't know, that is what I wanted to ask Thierry.
^ permalink raw reply [relevance 99%]
* Re: Adding with-editor to Emacs?
@ 2023-09-18 8:59 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-09-18 8:59 UTC (permalink / raw)
To: Richard Stallman; +Cc: Björn Bidar, eliz, 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. ]]]
>
> > It's about telling the external programs to do THING /with-editor/,
> > editor because the $EDITOR environment that is used.
>
> Now I see how it is useful, but I suggest we change its name before
> installing it in Emacs or either ELPA. If we call it
> `with-EDITOR-envvar' it purpose will be much clearer.
As someone who also frequently has difficulties understanding how people
come up with package names, I don't see how your suggestion is clearer
than the current name.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: package-vc support for :files keyword
@ 2023-09-19 13:56 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-09-19 13:56 UTC (permalink / raw)
To: Adam Porter; +Cc: emacs-devel, tonyzorman
Adam Porter <adam@alphapapa.net> writes:
> Hi Philip,
>
> On 9/19/23 03:37, Philip Kaludercic wrote:
>
>>> Please note out that while `taxy' and `taxy-magit-section' are both
>>> developed in "taxy.el.git", they are in separate branches, so there is
>>> no need to build the two packages from a single set of files by
>>> excluding some files and then the others.
>> Oops, I just wrote a quick script that compared URLs but did not
>> check
>> what :branch they are developed on.
>>
>>> I've chosen to keep these packages in the same repo because they are
>>> so closely related. I'd like to be able to keep this arrangement.
>> That is totally fine, would you mind sharing your setup, in case
>> someone
>> else is interested in this approach as well?
>
> I'm not sure what you're asking for, but I'll be glad to share. All I
> did was create an orphan branch in the same repository and add the
> "taxy-magit-section.el" and associated files there, as if it were a
> separate repo.
What I meant was if you just had multiple, separate checkouts of the
same repository or were using something more fancy like git worktrees.
>>> Having said that, while I wouldn't personally object to dropping
>>> support for building multiple packages from a single branch (since I
>>> don't do it myself), I wouldn't favor doing so, because existing
>>> packages do, and it would create more work for the authors to have to
>>> split them up.
>> That is the issue, and I certainly don't want to be the one to blame
>> for
>> breakage, be it for package developers let alone users.
>>
>>> Maybe it would be reasonable to make a new policy against building
>>> multiple packages from a single branch, while "grandfathering" in the
>>> existing packages that do so, if it would solve a problem for ELPA.
>> What do you mean by "grandfathering"?
>
> It's an expression; in this context, it would mean to allow the
> packages that already work this way to continue doing so, while
> requiring newly submitted packages to only build one package per
> branch (or repo, depending on the policy).
FWIW I have been bringing this up whenever a package like this was
proposed, but usually they refer to existing users on MELPA and then I
don't want to bother them any further.
^ permalink raw reply [relevance 99%]
* Re: package-vc support for :files keyword
@ 2023-09-19 14:00 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-09-19 14:00 UTC (permalink / raw)
To: Adam Porter; +Cc: emacs-devel, tonyzorman
Adam Porter <adam@alphapapa.net> writes:
> FWIW, it seems like a bit of an anti-pattern for shell commands to be
> part of Elisp packages' recipes. I can see how it may be necessary
> for certain ones that support external software that may need to build
> a module, etc, but it seems like that sort of thing should be kept to
> a minimum due to, e.g. potential security issues with executing code
> at install time. Or am I missing something? :)
It usually is a hack, and it isn't enabled by default either. Emacs 30
has a special user option to regulate it. I certainly don't recommend
using it, and am not that enthusiastic about promoting it.
> --Adam
^ permalink raw reply [relevance 99%]
* Re: package-vc support for :files keyword
@ 2023-09-21 16:32 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-09-21 16:32 UTC (permalink / raw)
To: Tony Zorman; +Cc: emacs-devel
Tony Zorman <tonyzorman@mailbox.org> writes:
> On Wed, Sep 20 2023 07:32, Philip Kaludercic wrote:
>> Here is a sketch of how that could look like. Can you test it to see if
>> it works:
>>
>> [… 71 lines elided …]
>
> Yup, works beautifully; thanks!
OK, I'll convert this into a proper patch and update the documentation.
>>> (I also consider executing external shell commands during build-time an
>>> anti pattern, I just got the feeling that making package-vc support
>>> `:ignored-files' wasn't on the table—glad to realise that I was wrong!)
>>
>> Why did you think so?
>
> I perhaps read your first email[1] more negatively than you intended it
> to be.
My point there was that using :ignored-files as a ":files" substitute
won't work, but I understand how my statement there could be misread.
Sorry about that.
> [1]: https://lists.gnu.org/archive/html/emacs-devel/2023-06/msg00247.html
^ permalink raw reply [relevance 99%]
* Re: package-vc support for :files keyword
@ 2023-09-22 13:26 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-09-22 13:26 UTC (permalink / raw)
To: Stefan Kangas; +Cc: Jonas Bernoulli, Tony Zorman, emacs-devel
Stefan Kangas <stefankangas@gmail.com> writes:
> Jonas Bernoulli <jonas@bernoul.li> writes:
>
>> Tony Zorman <tonyzorman@mailbox.org> writes:
>>
>>> This is not just for multiple packages in a single repository—at least
>>> one has to somewhat broaden what "multiple packages" means. Some
>>> packages include small shims for bigger projects, and inadvertently
>>> require them as dependencies. The original issue[1] on the
>>> vc-use-package repo mentions org-ql[2], more specifically its helm
>>> integration in the form of helm-org-ql.el. Some people might not want to
>>> pull down helm as a dependency just for one file that they are not going
>>> to use anyways.
>>>
>>> I'm not sure how common of a situation this actually is, but at least
>>> for the big completion frameworks—helm and ivy—it's not totally unheard
>>> of.
>
> If a user uses foo, and also bar, then foo may support bar optionally,
> or the other way around. We have ways of dealing with that without an
> explicit dependency, including e.g. autoloads and `eval-after-load'.
> The user will simply install both foo and bar, and things should ideally
> work as expected, including their integration. See for example
> use-package-ensure-system-package.el.
>
> Is there any reason why that can't work?
>
> A separate but related issue is that we should really teach package.el
> to deal with optional dependencies. I personally like Debian's model
> with "Recommends" and "Suggests" sections.
What is the difference between the two?
>> Here's a complete list for all of these packages that are available on
>> Melpa. Obviously not all of these pairings fall into the "foo and
>> helm-foo share a repository" category, but you can get an idea of what
>> other reasons exist for splitting a repository into multiple packages,
>> based on the names of the packages/libraries. I have included links to
>> the repositories, so you can quickly jump there, when only looking at
>> the names is not enough.
>
> Having reviewed this list, my conclusion remains that there is usually
> no need for splitting up packages like this.
I might be mistaken, but I believe that MELPA and specifically
package-lint advise against using {with,}eval-after-load, encouraging
splitting up packages like these.
^ permalink raw reply [relevance 99%]
* Re: [PATCH] Improve find-sibling-rules option type
@ 2023-09-24 8:34 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-09-24 8:34 UTC (permalink / raw)
To: Paul W. Rankin via Emacs development discussions.; +Cc: Paul W. Rankin
"Paul W. Rankin" via "Emacs development discussions."
<emacs-devel@gnu.org> writes:
> * lisp/files.el (find-sibling-rules): use alist with tags for custom
> type
> ---
> This is preferable than having to enter a sexp as a user option.
>
>
> lisp/files.el | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/lisp/files.el b/lisp/files.el
> index 9d76668..e7adccd 100644
> --- a/lisp/files.el
> +++ b/lisp/files.el
> @@ -7572,7 +7572,8 @@ files, you could say something like:
> In this example, if you're in \"src/emacs/emacs-27/lisp/abbrev.el\",
> and a \"src/emacs/emacs-28/lisp/abbrev.el\" file exists, it's now
> defined as a sibling."
> - :type 'sexp
> + :type '(alist :key-type (string :tag "Match")
^
(elisp) Simple Types lists a type `regexp'
that you could use here as well.
> + :value-type (string :tag "Expansion"))
> :version "29.1")
>
> (defun find-sibling-file (file)
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Adding refactoring capabilities to Emacs
@ 2023-09-26 13:38 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-09-26 13:38 UTC (permalink / raw)
To: João Távora
Cc: Dmitry Gutov, Alfred M. Szmidt, monnier, eliz, emacs-devel
João Távora <joaotavora@gmail.com> writes:
> On Tue, Sep 26, 2023 at 11:57 AM Dmitry Gutov <dmitry@gutov.dev> wrote:
>>
>> On 26/09/2023 11:06, João Távora wrote:
>> > On Tue, Sep 26, 2023 at 6:36 AM Alfred M. Szmidt<ams@gnu.org> wrote:
>> >
>> >> If you have a diff on file, you are most probobly going to apply it,
>> >> and also probobly going to remove a hunk or two or edit the diff in
>> >> some manner. (That this is "relatively rare" I disagree from my own
>> >> usage and experience). Not to mention that visiting a file on disk,
>> >> that is read-write, and Emacs making it read-only would be very
>> >> strange.
>> > I completely agree with these two points. Even non-file diff-mode
>> > buffers, such as the ones provided by piping git diff into Emacs
>> > (yes, I can do that 😄 ) are generally better left read-write,
>> > since I frequently edit them to kill hunks I'm not interested in.
>>
>> 'k' (or M-k), 'C-c C-s' and 'C-_' all work fine in a read-only diff-mode
>> buffer. 'C-x C-s' also works, of course.
>
> I think it's very inconsistent to have specialized commands to modify
> a buffers contents and not allow all the other regular commands that
> modify a buffer do their work. I don't have unlimited brain address
> space for keybindings and I think C-SPC C-n a few times C-w does
> the job just fine.
While I get this perspective, I also think that being able to close a
diff using 'q' is a nice, ergonomic-wise.
> Opening regular files of a special type read-only mode would be a
> spectacular failure in the basic ergonomics of an editor.
>
> João
^ permalink raw reply [relevance 99%]
* Re: [NonGNU ELPA] Package suggestion: yeetube
@ 2023-10-04 15:22 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-10-04 15:22 UTC (permalink / raw)
To: Thanos Apollo; +Cc: Daniel Martín, emacs-devel
Thanos Apollo <public@thanosapollo.com> writes:
> Daniel Martín <mardani29@yahoo.es> writes:
>
>> Thanos Apollo <public@thanosapollo.com> writes:
>>
>>> Hello,
>>>
>>> I've been trying to learn elisp and made this simple niche package,
>>> to
>>> watch & download youtube content via Emacs using only free
>>> software.
>>>
>>> Homepage: https://git.thanosapollo.com/yeetube/about/
>>>
>>
>> Thanks for writing this package, it looks interesting.
>
> Thanks!
>
>> I see it requires Emacs 29.1, but is there a reason it requires such
>> a recent
>> version of Emacs? I'd set the minimum version to something older,
>> if
>> possible, so that users on older versions of Emacs can still use
>> recent
>> packages like yours.
>
> I only used `defvar-keymap` which requires 29.1. I will redo the
> keymap the 'old way' and set the minimum version to 27.2 (for cl-lib)
For defvar-keymap, you can also depend on the Compat package, that
defines a compatibility version for older Emacs releases.
^ permalink raw reply [relevance 99%]
* Re: [package-vc] Consider cleaning up files from install process
@ 2023-10-04 15:23 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-10-04 15:23 UTC (permalink / raw)
To: Joseph Turner; +Cc: monnier, Adam Porter, Emacs Devel Mailing List
Joseph Turner <joseph@breatheoutbreathe.in> writes:
>> > For example, when following these instructions to install hyperdrive.el:
>> > https://ushin.org/hyperdrive/hyperdrive-manual.html#package_002dvc
>> >
>> > the git repository ends up with these extra untracked files:
>> >
>> > dir
>> > hyperdrive-autoloads.el
>> > hyperdrive-pkg.el
>> > hyperdrive.info
>
>> Please report this as a bug in the Hyperdrive repository: its
>> `.gitignore` should be adjusted to ignore those files.
>
> Good to know. We have updated the hyperdrive.el .gitignore.
>
> Are all package authors are expected to add these files to .gitignore
> (or equivalent in other VCS)? If so, we should probably put a notice in
> the package-vc documentation or somewhere else. What do you suggest?
This is not related to package-vc, it is also the recommended practice
for regular ELPA packages.
> Thank you!
>
> Joseph
^ permalink raw reply [relevance 99%]
* Re: [package-vc] Consider cleaning up files from install process
@ 2023-10-06 9:00 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-10-06 9:00 UTC (permalink / raw)
To: Joseph Turner; +Cc: monnier, Adam Porter, Emacs Devel Mailing List
Joseph Turner <joseph@breatheoutbreathe.in> writes:
> On October 4, 2023 8:23:07 AM PDT, Philip Kaludercic <philipk@posteo.net> wrote:
>>Joseph Turner <joseph@breatheoutbreathe.in> writes:
>>
>>>> > For example, when following these instructions to install hyperdrive.el:
>>>> > https://ushin.org/hyperdrive/hyperdrive-manual.html#package_002dvc
>>>> >
>>>> > the git repository ends up with these extra untracked files:
>>>> >
>>>> > dir
>>>> > hyperdrive-autoloads.el
>>>> > hyperdrive-pkg.el
>>>> > hyperdrive.info
>>>
>>>> Please report this as a bug in the Hyperdrive repository: its
>>>> `.gitignore` should be adjusted to ignore those files.
>>>
>>> Good to know. We have updated the hyperdrive.el .gitignore.
>>>
>>> Are all package authors are expected to add these files to .gitignore
>>> (or equivalent in other VCS)? If so, we should probably put a notice in
>>> the package-vc documentation or somewhere else. What do you suggest?
>>
>>This is not related to package-vc, it is also the recommended practice
>>for regular ELPA packages.
>
> Would you mind sharing a link to this recommendation? I searched the Emacs/Elisp info manuals as well as the ELPA README.
I don't know of any link, what I meant with "recommendation" was "it is
frequently recommended when reviewing a package".
>>> Thank you!
>>>
>>> Joseph
^ permalink raw reply [relevance 99%]
* Re: [nongnu] elpa/hyperdrive b5294b4354 4/4: Tidy: Use zerop instead of = 0
[not found] ` <20231013200057.2C7FCC09BC9@vcs2.savannah.gnu.org>
@ 2023-10-13 22:12 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-10-13 22:12 UTC (permalink / raw)
To: emacs-devel; +Cc: Joseph Turner
FWIW this doesn't matter that much, you can check the disassembly to
see what is going on after byte compilation:
(disassemble (byte-compile (lambda (a) (= a 0))))
(disassemble (byte-compile (lambda (a) (zerop a))))
ELPA Syncer <elpasync@gnu.org> writes:
> branch: elpa/hyperdrive
> commit b5294b43547379e87435c294670f4a23ac0739b7
> Author: Joseph Turner <joseph@ushin.org>
> Commit: Joseph Turner <joseph@ushin.org>
>
> Tidy: Use zerop instead of = 0
> ---
> hyperdrive-lib.el | 2 +-
> hyperdrive.el | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/hyperdrive-lib.el b/hyperdrive-lib.el
> index 1801fe0076..e2696160c9 100644
> --- a/hyperdrive-lib.el
> +++ b/hyperdrive-lib.el
> @@ -1033,7 +1033,7 @@ With universal prefix argument \\[universal-argument], prompt for entry."
> With FORCE-PROMPT or when current hyperdrive does not match
> PREDICATE, return a hyperdrive selected with completion. In this
> case, when PREDICATE, only offer hyperdrives matching it."
> - (when (= 0 (hash-table-count hyperdrive-hyperdrives))
> + (when (zerop (hash-table-count hyperdrive-hyperdrives))
> (hyperdrive-user-error "No known hyperdrives. Use `hyperdrive-new' to create a new one"))
> (unless predicate
> ;; cl-defun default value doesn't work when nil predicate value is passed in.
> diff --git a/hyperdrive.el b/hyperdrive.el
> index 824d33ba24..fcd2715b55 100644
> --- a/hyperdrive.el
> +++ b/hyperdrive.el
> @@ -827,7 +827,7 @@ The return value of this function is the retrieval buffer."
> :help "Create a new hyperdrive"]
> ("Drives"
> :active (< 0 (hash-table-count hyperdrive-hyperdrives))
> - :label (if (= 0 (hash-table-count hyperdrive-hyperdrives))
> + :label (if (zerop (hash-table-count hyperdrive-hyperdrives))
> "Drives (empty)"
> "Drives")
> :filter (lambda (_)
^ permalink raw reply [relevance 99%]
* Re: [nongnu] elpa/hyperdrive b5294b4354 4/4: Tidy: Use zerop instead of = 0
@ 2023-10-15 9:17 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-10-15 9:17 UTC (permalink / raw)
To: emacs-devel
You dropped me out of the CC's.
Emanuel Berg <incal@dataswamp.org> writes:
> Philip Kaludercic wrote:
>
>> FWIW this doesn't matter that much, you can check the
>> disassembly to see what is going on after byte compilation:
>>
>> (disassemble (byte-compile (lambda (a) (= a 0))))
>
> byte code:
> args: (a)
> 0 varref a
> 1 constant 0
> 2 eqlsign
> 3 return
>
>> (disassemble (byte-compile (lambda (a) (zerop a))))
>
> byte code:
> args: (a)
> 0 varref a
> 1 constant 0
> 2 eqlsign
> 3 return
>
> They are identical, is that what you mean it doesn't matter
> that much?
My comment was just to indicate that there is no need to change from one
to the other, e.g. for performance reasons (which would have been my
intuition), but also as a reminder to check the result of byte
compilation.
> To use `zerop' is maybe more classy - the attitude being to
> minimize everything as much as possible - as it is a unary
> function (1 argument) while `=', as it is used here, is binary
> (2 arguments).
>
> BTW = can be used unary as well, then it always returns t -
> even for nil. (= nil) ; t
>
> But why do that? As it is more classy to just use t :)
I guess?
^ permalink raw reply [relevance 99%]
* Re: compat.el and Emacs unstable master branch features
@ 2023-10-15 12:09 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-10-15 12:09 UTC (permalink / raw)
To: Ihor Radchenko
Cc: Daniel Mendler, Joseph Turner, Stefan Monnier, Adam Porter,
Eli Zaretskii, phillip.lord, emacs-devel, ~pkal/compat-devel
Ihor Radchenko <yantar92@posteo.net> writes:
> Daniel Mendler <mail@daniel-mendler.de> writes:
>
>>>> Yes, if the Emacs maintainers agree I think this could be done. Take
>>>> compat.el, remove the part which requires compat-29, and copy it to
>>>> lisp/ or lisp/emacs-lisp/. As you said, if Compat (the package) is
>>>> installed it will be preferred over the core compat.el. The advantage of
>>>> this move is that core package could require compat directly without
>>>> passing a noerror argument to require. Furthermore `compat-call' and
>>>> `compat-function' would be available and wouldn't have to be copied as
>>>> is currently the case for example in erc-compat.el.
>>>
>>> That sounds good! How does this look like:
>>
>> Yes, this is what I meant. I forgot to mention one additional advantage
>> in my last mail: If the compat.el in core is registered with package.el
>> as builtin with version 30, the ELPA Compat package wouldn't get pulled
>> in by external packages which depend on Compat version 29. The core
>> compat.el version should then be bumped together with the Emacs version.
>
> Nobody raised objections. I recommend sending the patch to debbugs (M-x
> submit-emacs-patch), so that it can be seen by Emacs maintainers.
See bug#66554.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Making package.el talk over Tor
@ 2023-10-16 9:15 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-10-16 9:15 UTC (permalink / raw)
To: Stefan Kangas; +Cc: rms, emacs-devel
Stefan Kangas <stefankangas@gmail.com> writes:
> Richard Stallman <rms@gnu.org> writes:
>
>> I would like to arrange for package.el
>> to always connect to ELPA across the Tor network.
>> But it is 4600 lines of code and I would rather not have to read it all.
>>
>> Can someone tell me where to find the code that actually
>> communicates with the ELPA repos? Where is the best place
>> to make that change?
>
> I found these macros by searching for the string "(url":
>
> package--with-response-buffer-1
> package--with-work-buffer
>
> I don't know if you want this to affect package-vc, but I guess a new
> option would be even more useful if it could cover that too.
IIRC all HTTP requests by package-vc go through these functions as well,
so if they were to be made Tor-compatible and vc-tor was set, then this
/could/ be safe, setting aside issues such as detailed fingerprinting.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: zcomplete
@ 2023-10-20 9:35 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-10-20 9:35 UTC (permalink / raw)
To: Juri Linkov; +Cc: sbaugh, emacs-devel
Juri Linkov <juri@linkov.net> writes:
> diff --git a/lisp/zcomplete.el b/lisp/zcomplete.el
> new file mode 100644
> index 00000000000..75a40c0afd3
> --- /dev/null
> +++ b/lisp/zcomplete.el
> @@ -0,0 +1,317 @@
> +;;; zcomplete.el --- zsh-like minibuffer completion based on icomplete -*- lexical-binding: t -*-
I have been trying out zcomplete for the last week, and it works really
well. If there is no plan to add it to the core, would you at least be
interested in having it added to GNU ELPA?
^ permalink raw reply [relevance 99%]
* Re: [ELPA] Updated packages: boxy, boxy-headings, and org-real
@ 2023-10-25 6:34 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-10-25 6:34 UTC (permalink / raw)
To: Amy Grinn; +Cc: emacs-devel
Amy Grinn <grinn.amy@gmail.com> writes:
> I would like to update the URL for ELPA packages I am a maintainer
> of.
I've applied the changes and pushed them to elpa.git. Thanks for
letting us know.
> Best,
>
> Amy
>
> diff --git a/elpa-packages b/elpa-packages
> index 97174cc591..28e0ac3525 100644
> --- a/elpa-packages
> +++ b/elpa-packages
> @@ -96,8 +96,8 @@
> :readme "README.org")
> (bluetooth :url "https://gitlab.com/rstocker/emacs-bluetooth")
> (bnf-mode :url "https://github.com/sergeyklay/bnf-mode")
> - (boxy :url "https://gitlab.com/tygrdev/boxy")
> - (boxy-headings :url "https://gitlab.com/tygrdev/boxy-headings")
> + (boxy :url "https://gitlab.com/grinn.amy/boxy")
> + (boxy-headings :url "https://gitlab.com/grinn.amy/boxy-headings")
> (breadcrumb :url "https://github.com/joaotavora/breadcrumb")
> (brief :url nil)
> (buffer-env :url "https://github.com/astoff/buffer-env")
> @@ -505,7 +505,7 @@
> ;; FIXME: Upstream diverged; https://github.com/p-m/org-notify/issues/9
> ;; :merge t
> )
> - (org-real :url "https://gitlab.com/tygrdev/org-real"
> + (org-real :url "https://gitlab.com/grinn.amy/org-real"
> :ignored-files ("LICENSE"))
> (org-remark :url "https://github.com/nobiot/org-remark"
> :readme "README.org"
^ permalink raw reply [relevance 99%]
* Re: [NonGnu ELPA] New package: flymake-codespell
@ 2023-10-31 8:29 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-10-31 8:29 UTC (permalink / raw)
To: Chmouel Boudjnah; +Cc: Stefan Kangas, emacs-devel
Chmouel Boudjnah <chmouel@chmouel.com> writes:
> On Sun, Oct 29, 2023 at 11:41 PM Stefan Kangas <stefankangas@gmail.com>
> wrote:
>
>> I didn't take a look at it, but I have had something similar cooking for
>> a while:
>>
>> https://github.com/skangas/flymake-codespell
>>
>> How do you feel about merging our efforts? It would be better with just
>> one package for this, for obvious reasons. I don't really care which
>> package to use as a base, but I do think it would be better to keep the
>> result on GNU ELPA.
>>
>
> This is great, I didn't see this before.
>
> Your package seems a bit better documented and configurable, I would not
> mind deprecating mine and just put a notice on the repository to have users
> (but I doubt i have many) redirected to your's.
>
> (and I guess maybe to have a submission of your's for GNU ELPA ?)
Should we go ahead and add Stefan's package then?
> Cheers,
> Chmouel
>
>
>
>
>> Please let me know what you think.
>>
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: ELPA submission: plz-see
@ 2023-11-01 9:14 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-11-01 9:14 UTC (permalink / raw)
To: Augusto Stoffel; +Cc: Eli Zaretskii, emacs-devel
Augusto Stoffel <arstoffel@gmail.com> writes:
> Thanks for the comments!
>
> On Tue, 31 Oct 2023 at 08:43, Philip Kaludercic wrote:
>
>> +(eval-when-compile (require 'cl-lib))
>> (require 'json)
>
> By the way, the latter is kind of a non-essential require, would you
> rather write this near line 88?
>
> (defcustom plz-see-content-type-alist
> `(...
> ("\\`application/json" . ,(lambda ()
> (require 'json)
> (declare-function 'json-pretty-print-buffer "json.el")
> (json-pretty-print-buffer)
> (js-json-mode)))
> ...))
I don't have a strong opinion either way.
>> I agree, from what I see this is just an implementation detail. Plz is
>> a peculiar enough name as it is, it shouldn't be inherited by packages
>> that depend on it. Or is there any reason why the package couldn't also
>> use url.el?
>
> The packages is really closely tied to plz's API, which by the way is a
> very nice one.
But is this fact exposed to the user?
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: [External] : Re: [ELPA] New package: dired-duplicates
@ 2023-11-01 16:33 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-11-01 16:33 UTC (permalink / raw)
To: Drew Adams; +Cc: Michael Heerdegen, emacs-devel@gnu.org
Drew Adams <drew.adams@oracle.com> writes:
> Yes, this is a personal choice - and IMO it should
> be. I don't see a reason for suggesting any
> particular convention for users wrt including
> :group when it's "redundant".
One reason for suggesting it is that many people don't know that it is
optional. Most of the suggestions I make at least are of a "fun fact"
or "neat but not necessary" type.
^ permalink raw reply [relevance 99%]
* Re: [ELPA] New package: dape
@ 2023-11-01 16:50 99% ` Philip Kaludercic
1 sibling, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-11-01 16:50 UTC (permalink / raw)
To: Daniel Pettersson; +Cc: emacs-devel
Daniel Pettersson <daniel@dpettersson.net> writes:
> "dbg" is nice and sweet, but I think it's a + for discoverability to have
> dap in the name of the package. How about eldap? If it should signify
> a connection to Eglot, maybe Ebug or even closer Dpoly? Or maybe a
> reference to Grace Hopper, hopper.
> Personally I like eldap, probably because it feels familiar.
Did we ever come to a conclusion on this point?
^ permalink raw reply [relevance 99%]
* Re: ELPA submission: drepl (REPL protocol)
@ 2023-11-01 18:38 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-11-01 18:38 UTC (permalink / raw)
To: Augusto Stoffel; +Cc: emacs-devel
Augusto Stoffel <arstoffel@gmail.com> writes:
> On Tue, 31 Oct 2023 at 09:08, Philip Kaludercic wrote:
>
>> The idea seems interesting, I'll have to try it out at some point
>> (though I don't really use Python or Lua much, so I hope you plan to add
>> more languages in the future).
> Sure, let me know if you have any ideas. A good candidate, as I
> mention in the readme, would be a language that has a good embeddable
> REPL library that you hack into (as opposed to a program where the
> REP-loop is more or less hardcoded).
What does a REPL library need, that most languages couldn't implement
themselves if they have an eval function?
>> (cl-defgeneric drepl--command (repl)
>> "The command to start the REPL interpreter as a list of strings."
>> (ignore repl)
>> - (error "This needs an implementation"))
>> + (error "This needs an implementation")) ;Mention what "this" is
>
> _This_ is the method. This is one of the two things that cannot have a
> default implementation and should be implemented by every subclass :-).
> Is the message confusing?
I am just imagining an error message appearing in the mini buffer saying
"This needs an implementation", without an indication where the error is
coming from.
^ permalink raw reply [relevance 99%]
* Re: ELPA submission: plz-see
@ 2023-11-03 7:50 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-11-03 7:50 UTC (permalink / raw)
To: brickviking; +Cc: rms, emacs-devel
brickviking <brickviking@gmail.com> writes:
> I have it listed here in my elpa packages listing. A very short summary
> from
> the package itself is as follows:
>
> `plz' is an HTTP library for Emacs. It uses `curl' as a backend, which
> avoids some of the issues with using Emacs's built-in `url' library.
And yes, the name is not indicative of what the packages does, but the
author had a strong preference of using a "fun" name and has advocated
this on multiple occasions, so it is extremely unlikely that it will
ever change -- not worth attempting to discuss again. My only hope was
that this wouldn't proliferate further to other package names :/
> HTH, brickviking
>
>
> On Fri, 3 Nov 2023 at 15:31, Richard Stallman <rms@gnu.org> wrote:
>
>> [[[ To any NSA and FBI agents reading my email: please consider ]]]
>> [[[ whether defending the US Constitution against all enemies, ]]]
>> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>>
>> > > Totally. Perhaps if you had a look into plz you would appreciate
>> this
>> > > fact :-).
>>
>> I looked at plz (disambiguation) in Wikipedia, and found nothing
>> that seems to be what you mean here. What is the plz in question?
>>
>> --
>> Dr Richard Stallman (https://stallman.org)
>> Chief GNUisance of the GNU Project (https://gnu.org)
>> Founder, Free Software Foundation (https://fsf.org)
>> Internet Hall-of-Famer (https://internethalloffame.org)
>>
>>
>>
>>
^ permalink raw reply [relevance 99%]
* Re: [ELPA] New package: dired-duplicates
@ 2023-11-03 8:19 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-11-03 8:19 UTC (permalink / raw)
To: Harald Judt; +Cc: emacs-devel, Stefan Kangas, Eli Zaretskii, Visuwesh
Harald Judt <h.judt@gmx.at> writes:
> Now, I think I have addressed all points from your feedback, how may I
> go on pushing a release? Simply increase the version number to 0.2 as
> you said in my codeberg repo?
In principle yes, but we haven't added the package yet. Were there any
outstanding issues that were not resolved?
^ permalink raw reply [relevance 99%]
* Re: [ELPA] New package: dape
@ 2023-11-04 10:00 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-11-04 10:00 UTC (permalink / raw)
To: Daniel Pettersson
Cc: João Távora, Dmitry Gutov, John Yates,
Krister Schuchardt, Adam Porter, emacs-devel
Daniel Pettersson <daniel@dpettersson.net> writes:
> On Wed, Nov 1, 2023 at 7:35 PM Philip Kaludercic <philipk@posteo.net> wrote:
>> Did we ever come to a conclusion on this point?
>
> Sorry I have been putting the naming thing off as this thread sparked
> a bit of interest in the package which lead to a lot of great input and
> bugfixing. There have been a lot of good suggestions and no consensus
> which has made the even task harder.
In the end that is your call, it is just currently a blocking issue
before we add the package to GNU ELPA.
^ permalink raw reply [relevance 99%]
* Re: [ELPA] New package: dired-duplicates
@ 2023-11-04 15:27 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-11-04 15:27 UTC (permalink / raw)
To: Harald Judt; +Cc: emacs-devel, Stefan Kangas, Eli Zaretskii, Visuwesh
Harald Judt <h.judt@gmx.at> writes:
> Am 03.11.23 um 09:19 schrieb Philip Kaludercic:
>> Harald Judt <h.judt@gmx.at> writes:
>>
>>> Now, I think I have addressed all points from your feedback, how may I
>>> go on pushing a release? Simply increase the version number to 0.2 as
>>> you said in my codeberg repo?
>> In principle yes, but we haven't added the package yet. Were there
>> any
>> outstanding issues that were not resolved?
>
> I do not think there are any outstanding issues left, I have fixed the
> things discussed here with the last 7 commits
> (https://codeberg.org/hjudt/dired-duplicates/commits/branch/main). Of
> course, there is Eli's proposal to use Emacs's primitives as a
> fallback, but I intend to implement this in a future version.
OK, I have added the package to GNU ELPA. It should appear within the
next day (you'll get an email, because your address is listed as the
maintainer).
> Harald
^ permalink raw reply [relevance 99%]
* Re: ELPA submission: drepl (REPL protocol)
@ 2023-11-07 8:20 99% ` Philip Kaludercic
1 sibling, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-11-07 8:20 UTC (permalink / raw)
To: Augusto Stoffel; +Cc: emacs-devel
Philip Kaludercic <philipk@posteo.net> writes:
> Augusto Stoffel <arstoffel@gmail.com> writes:
>
>> Hi again,
>>
>> I would like to submit the following package to ELPA:
>>
>> https://github.com/astoff/drepl
>>
>> It provides alternative shells for the Python and Lua languages. More
>> importantly, however, it defines a framework and a protocol to create
>> new REPLs which hopefully helps doing some things which are tricky in
>> Comint (especially completion and multi-line editing).
>>
>> This is kind of an experiment at this point, but I would like to make it
>> public and see what people think.
>
> The idea seems interesting, I'll have to try it out at some point
> (though I don't really use Python or Lua much, so I hope you plan to add
> more languages in the future).
>
> Code-wise, I just have a few minor comments:
>
> diff --git a/drepl.el b/drepl.el
> index 1c6bd71..1a11b47 100644
> --- a/drepl.el
> +++ b/drepl.el
> @@ -4,6 +4,8 @@
>
> ;; Author: Augusto Stoffel <arstoffel@gmail.com>
> ;; Keywords: languages, processes
> +;; Version: 1.0.0
> +;; Package-Requires: ((emacs "29.1"))
I have added the package, but it won't appear until you apply these
changes and tag a new release.
^ permalink raw reply [relevance 99%]
* Re: [ELPA] New package: dired-duplicates
@ 2023-11-10 8:37 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-11-10 8:37 UTC (permalink / raw)
To: Harald Judt; +Cc: emacs-devel
Harald Judt <h.judt@gmx.at> writes:
> Hi,
>
> On 2023-11-04 at 16:27, Philip Kaludercic wrote:
>> Harald Judt <h.judt@gmx.at> writes:
>>
>>> Am 03.11.23 um 09:19 schrieb Philip Kaludercic:
>>>> Harald Judt <h.judt@gmx.at> writes:
>>>>
>>>>> Now, I think I have addressed all points from your feedback, how may I
>>>>> go on pushing a release? Simply increase the version number to 0.2 as
>>>>> you said in my codeberg repo?
>>>> In principle yes, but we haven't added the package yet. Were there
>>>> any
>>>> outstanding issues that were not resolved?
>>>
>>> I do not think there are any outstanding issues left, I have fixed the
>>> things discussed here with the last 7 commits
>>> (https://codeberg.org/hjudt/dired-duplicates/commits/branch/main). Of
>>> course, there is Eli's proposal to use Emacs's primitives as a
>>> fallback, but I intend to implement this in a future version.
>> OK, I have added the package to GNU ELPA. It should appear within
>> the
>> next day (you'll get an email, because your address is listed as the
>> maintainer).
>>
>>> Harald
>
> Unfortunately, I got a mail that it failed to build and tried to
> follow the instructions locally but it also failed for me (likely due
> to some other issue here because it is missing a shared lib in a
> sandboxed environment?):
>
> --------------------------------------------------------------------------------
> make build/dired-duplicates
> emacs --batch -l /mnt/scratch/work/elpa/admin/elpa-admin.el \
> -f elpaa-batch-make-one-package dired-duplicates
> ======== Building tarball
> archive-devel/dired-duplicates-0.1.0.20231105.3955.tar...
> Build error for
> archive-devel/dired-duplicates-0.1.0.20231105.3955.tar: (error
> "Error-indicating exit code in elpaa--call-sandboxed:
> emacs: error while loading shared libraries: libgccjit.so.0: cannot
> open shared object file: No such file or directory
> ")
> ######## Build of package
> archive-devel/dired-duplicates-0.1.0.20231105.3955.tar
> FAILED!!
> ======== Building tarball archive/dired-duplicates-0.1.tar...
> Build error for archive/dired-duplicates-0.1.tar: (error "Can’t find
> main file
> /mnt/scratch/work/elpa/packages/dired-duplicates/dired-duplicates.el
> file in /mnt/scratch/work/elpa/packages/dired-duplicates/")
> ######## Build of package archive/dired-duplicates-0.1.tar FAILED!!
> --------------------------------------------------------------------------------
>
>
> The error I got by mail from ELPA is the following:
>
>
> --------------------------------------------------------------------------------
> The build scripts failed to build the tarball
> for version 0.1 of the package dired-duplicates.
> You can consult the latest error output in the file
> "dired-duplicates-build-failure.txt" in the GNU ELPA archive web site.
>
> You can also try and reproduce the error locally as follows:
>
> git clone --single-branch https://git.sv.gnu.org/git/emacs/elpa.git
> cd elpa
> make # Setup the infrastructure
> make packages/dired-duplicates # Create a worktree of the package
> make build/dired-duplicates # Build the tarballs into archive(-devel)/
>
> ## The current error output was the following:
>
> ======== Building tarball archive/dired-duplicates-0.1.tar...
> Build error for archive/dired-duplicates-0.1.tar: (error "Can't find
> main file home/elpa/elpa/packages/dired-duplicates/dired-duplicates.el
> file in /home/elpa/elpa/packages/dired-duplicates")
> ######## Build of package archive/dired-duplicates-0.1.tar FAILED!!
> --------------------------------------------------------------------------------
>
> When I look into the archive/dired-duplicates-build-failure.txt file
> the paths mentioned there seem correct.
Sorry for the late response; It appears that the package can now be
built (see https://elpa.gnu.org/packages/dired-duplicates.html), I had
the same issue as you describe on my local machine and now it appears to
be gone. Perhaps this was resolved by your recent 0.2 commit?
>
>
> Regards,
> Harald
^ permalink raw reply [relevance 99%]
* Re: Instead of pcase
@ 2023-11-16 18:16 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-11-16 18:16 UTC (permalink / raw)
To: Michael Heerdegen; +Cc: emacs-devel
Michael Heerdegen <michael_heerdegen@web.de> writes:
> "T.V Raman" <raman@google.com> writes:
>
>> I recently tried to understand some of the completion code; --
>> specifically, completion-at-point, and immediately hit the pcase wall
>> and gave up --- my lack of understanding of pcase made that code in
>> Emacs Core read like line-noise.
>
> But that pcase form is only performing trivial destructuring. Only
> that, nothing more. If you can read backquote expressions, you can read
> that with exactly the same ease.
Right, and if one wouldn't use it to destruct values, you'd end up with
a lot more boiler-plate code that would be harder to maintain and more
to read. If one has to talk about difficult to understand/remember
domain specific languages, then `font-lock-defaults' would be a much
more pressing candidate.
> Michael.
^ permalink raw reply [relevance 99%]
* Re: [Reminder]Decommissoned keyservers
@ 2023-11-17 21:15 99% ` Philip Kaludercic
1 sibling, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-11-17 21:15 UTC (permalink / raw)
To: CHENG Gao via Emacs development discussions.; +Cc: CHENG Gao
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.
> ,----
> | (defcustom epa-keyserver "pgp.mit.edu"
> | "Domain of keyserver.
> |
> | This is used by `epa-search-keys', for looking up public keys."
> | :type '(choice :tag "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")
> `----
^ permalink raw reply [relevance 99%]
* Re: [ELPA] New package: ert-font-lock
@ 2023-11-18 14:47 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-11-18 14:47 UTC (permalink / raw)
To: Po Lu; +Cc: Eli Zaretskii, vekazanov, emacs-devel
Po Lu <luangruo@yahoo.com> writes:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>> Doesn't this library require ert? if it does, cl-lib is already
>> loaded by ert.
>
> That's a disappointment, but let's not double the problem.
The problem, as in the usage of cl-lib? You are probably referring to
the other thread about using CL in Elisp, right?
>> But if people like cl-incf so much, we could just add incf to subr.el
>> or something.
>
> Fine by me, thanks. (Don't we have incf elsewhere in core? Or was it
> in the old cl.el?)
That is part of cl, and is aliased to cl-incf.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: [Reminder]Decommissoned keyservers
@ 2023-11-18 15:41 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-11-18 15:41 UTC (permalink / raw)
To: Jonas Bernoulli; +Cc: CHENG Gao, emacs-devel
Jonas Bernoulli <jonas@bernoul.li> writes:
> This would also be a good time to add keys.openpgp.org.
Unless something has changed, the protocol spoken by keys.openpgp.org is
not the same as what the old keyservers used, and what epa-ks.el
implements. That being said, there is a `openpgp' package on GNU ELPA.
> See also https://keys.openpgp.org/about/news#2023-04-28-governance
> and https://gitlab.com/keys.openpgp.org/governance/-/blob/main/constitution.md.
>
> Jonas
>
>
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: [ELPA] New package: SachaC-news
@ 2023-11-18 21:10 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-11-18 21:10 UTC (permalink / raw)
To: Christian; +Cc: emacs-devel
Christian <cnngimenez@disroot.org> writes:
> Thanks Philip!
>
> I applied the diff to this commit:
>
> https://git.sr.ht/~cngimenez/sachac-news/commit/8263dbc7982f543f673172c4a60d4bb68a48c6f6
It appears you applied my comments as well? I should have made it
clear, that my message just intended to propose some changes,
demonstrate possible alternatives and raise some questions for us to
discuss.
> Cheers!
> Christian.
>
> On Fri, 17 Nov 2023 04:28:35 -0300, Kaludercic wrote:
>>
>> [1 <text/plain (7bit)>]
>> Christian <cnngimenez@disroot.org> writes:
>>
>> > Hi!
>> >
>> > I want to propose SachaC-news (or sachac-news.el if you like)
>> > package to be included in ELPA. Its objective is to check for
>> > Sacha Chua's news repository periodically, and to show the Org
>> > file if there is a new commit with a new post in it. It has
>> > some customizations too, such as folding specific sections
>> > automatically, and desktop notifications via "notify-send". The
>> > requirement is the git program to be installed on your system.
>> > This information and its usage is at the README.org file at the
>> > package repository:
>> >
>> > https://github.com/cnngimenez/sachac-news
>> >
>> > The code has been checked with byte-compile-file, and
>> > flycheck configured with checkdoc and flycheck-package [1].
>>
>> > They do not display any warnings up to commit d00e629, but tell
>> > me if you find something to fix or any suggestions.
>>
>> I found a few things, here is a diff with some comments and suggestions:
>>
>> [2 <text/plain (7bit)>]
>> diff --git a/sachac-news.el b/sachac-news.el
>> index 8d67911..1f389b2 100644
>> --- a/sachac-news.el
>> +++ b/sachac-news.el
>> @@ -22,7 +22,6 @@
>> ;; You should have received a copy of the GNU General Public License
>> ;; along with this program. If not, see <https://www.gnu.org/licenses/>.
>>
>> -
>> ;;; Commentary:
>>
>> ;; Check periodically for new commits on Sacha Chua's news repository.
>> @@ -58,29 +57,29 @@
>>
>> ;;; Code:
>>
>> -(provide 'sachac-news)
>> (require 'org-element)
>> (require 'org-list)
>> -(require 'cl-extra)
>> +(require 'cl-lib)
>>
>> (defgroup sachac-news nil
>> "Sacha Chua's Emacs news customizations."
>> :group 'applications)
>>
>> -(defcustom sachac-news-git-command "git"
>> +(defcustom sachac-news-git-command
>> + (eval-when-compile
>> + (require 'vc-git)
>> + vc-git-program)
>> "Path or git command name.
>>
>> Valid values are \"/usr/bin/git\" or \"git\" if it is in the current PATH."
>> - :type 'string
>> - :group 'sachac-news) ;; defcustom
>> + :type 'string) ;; defcustom
>>
>> (defcustom sachac-news-fold-category-regexp-list '()
>> "A list of regexp strings of the matching categories that should be folded.
>>
>> The function `sachac-news-fold-categories' use this variable to find
>> categories that the user wants to hide."
>> - :type '(repeat regexp)
>> - :group 'sachac-news) ;; defcustom
>> + :type '(repeat regexp)) ;; defcustom
>>
>> (defcustom sachac-news-alarm-sound-file
>> "/usr/share/sounds/freedesktop/stereo/bell.oga"
>> @@ -88,8 +87,7 @@ categories that the user wants to hide."
>> If the value is nil or the file does not exists, the `ding' function is used.
>>
>> See `sachac-news-default-sound-alarm' function."
>> - :type 'file
>> - :group 'sachac-news) ;; defcustom
>> + :type 'file) ;; defcustom
>>
>> (defcustom sachac-news-alarm-sound-programs
>> '(("mpv" . "--really-quiet %s")
>> @@ -100,22 +98,20 @@ programs is founded on the system, the `ding' function will be used. The
>> first program founded is used.
>>
>> This variable is used by `sachac-news-default-sound-alarm' function."
>> - :type '(alist :key-type string :value-type string)
>> - :group 'sachac-news ) ;; defcustom
>> + :type '(alist :key-type string :value-type string)) ;; defcustom
>>
>> (defcustom sachac-news-alarm-functions-hook
>> '(sachac-news-default-notify-alarm
>> sachac-news-default-sound-alarm)
>> "The alarm functions.
>> These functions are called when there are new news."
>> - :type 'hook
>> - :group 'sachac-news ) ;; defcustom
>> + :type 'hook) ;; defcustom
>>
>> (defconst sachac-news-title-regexp
>> "^\\*\\*[[:space:]]+[[:digit:]]+-[[:digit:]]+-[[:digit:]]+[[:space:]]+Emacs news"
>> - "Regexp used to find news titles in the index.org file." ) ;; defconst
>> + "Regexp used to find news titles in the index.org file.") ;; defconst
>>
>> -(defvar sachac-news-timer-setted-time 0
>> +(defvar sachac-news-timer-setted-time 0 ;perhaps mark these as internal: sachac-news--...
>> "At what time the timer has been setted?
>> See `sachac-news-set-timer'.")
>>
>> @@ -148,66 +144,67 @@ Else, this variable contains nil.")
>>
>> If USE-INDEX-ORG is t, then load the index.org file. Else, use the current
>> buffer as if it is the index.org."
>> -
>> (if use-index-org
>> (with-temp-buffer
>> (insert-file-contents (sachac-news-git-index-org))
>> - (sachac-news-take-last-new nil) )
>> + (sachac-news-take-last-new nil))
>> (progn
>> (goto-char (point-min))
>> (search-forward-regexp sachac-news-title-regexp)
>> (let ((sachac-news-title (org-element-at-point)))
>> (buffer-substring-no-properties
>> (org-element-property :begin sachac-news-title)
>> - (org-element-property :end sachac-news-title))))) )
>> + (org-element-property :end sachac-news-title))))))
>>
>> -(defcustom sachac-news-data-directory (concat user-emacs-directory
>> - "sachac/")
>> +(defcustom sachac-news-data-directory
>> + (locate-user-emacs-file "sachac")
>> "Where is the data directory?"
>> - :type 'directory
>> - :group 'sachac-news) ;; defcustom
>> + :type 'directory) ;; defcustom
>>
>> -(defcustom sachac-news-data-file "data.el"
>> +(defcustom sachac-news-data-file "data.eld"
>> "The configuration and data file.
>> This is where the last updated date and other data is stored."
>> - :type 'file
>> - :group 'sachac-news) ;; defcustom
>> + :type 'file) ;; defcustom
>>
>> (defcustom sachac-news-git-dirname "git"
>> "The directory where the git repository should be cloned."
>> - :type 'string
>> - :group 'sachac-news)
>> + :type 'string)
>>
>> +;; She publishes the news every week around the beginning, why check
>> +;; every day?
>> (defcustom sachac-news-update-hours-wait 24
>> "The amount of hours when the git clone/pull must wait before be called.
>>
>> Default is 24 hours. Only positive values should be used."
>> - :type 'integer
>> - :group 'sachac-news ) ;; defcustom
>> + :type 'natnum
>> + :group 'sachac-news) ;; defcustom
>>
>> (defun sachac-news-dir-git ()
>> "Return the complete git path."
>> - (concat sachac-news-data-directory "/" sachac-news-git-dirname) )
>> + (expand-file-name sachac-news-git-dirname sachac-news-data-directory))
>>
>> (defun sachac-news-dir-datafile ()
>> "Return the complete data file path."
>> - (concat sachac-news-data-directory "/" sachac-news-data-file) )
>> -
>> + (expand-file-name sachac-news-data-file sachac-news-data-directory))
>>
>> (defun sachac-news-git-index-org ()
>> "Return the index.org path on the git directory."
>> - (concat (sachac-news-dir-git) "/emacs-news/index.org") )
>> + (expand-file-name
>> + "index.org"
>> + (expand-file-name
>> + "emacs-news"
>> + (sachac-news-dir-git))))
>>
>> (defun sachac-news--show-last-new-internal ()
>> "Show the last news.
>> This is used after the update sentinel is executed.
>> See `sachac-news-show-last-new'."
>> - (let ((str (sachac-news-take-last-new t)))
>> + (let ((str (sachac-news-take-last-new t))) ;unused!
>> (with-current-buffer (get-buffer-create "*last-news*")
>> (org-mode)
>>
>> - (delete-region (point-min) (point-max))
>> - (insert str)
>> + (erase-buffer)
>> + (insert "foo")
>>
>> (goto-char (point-min))
>>
>> @@ -217,7 +214,7 @@ See `sachac-news-show-last-new'."
>> (sachac-news-update-last-saved-title)
>> (sachac-news-fold-categories))
>>
>> - (display-buffer (current-buffer)))) )
>> + (display-buffer (current-buffer)))))
>>
>> (defun sachac-news-show-last-new-if-new ()
>> "Show the last new if there is a new title.
>> @@ -241,16 +238,12 @@ see `sachac-news-update-hours-wait' variable."
>> #'sachac-news--show-last-new-internal
>> #'sachac-news--show-last-new-internal))
>>
>> -;;
>> -;; --------------------
>> -;; Last saved title
>> -;;
>> +;;; Last saved title
>>
>> (defun sachac-news-update-last-saved-title ()
>> "Save the last title into the data file."
>> -
>> (setq sachac-news-last-saved-title (sachac-news-get-last-title))
>> - (sachac-news-save-data) )
>> + (sachac-news-save-data))
>>
>> (defun sachac-news-get-last-title (&optional use-current-buffer)
>> "Get the first title founded in the current buffer.
>> @@ -264,7 +257,7 @@ the last title. Else, if t, use the current buffer, but remember to call
>> nil t)
>> (with-temp-buffer
>> (insert (sachac-news-take-last-new t))
>> - (sachac-news-get-last-title t))) )
>> + (sachac-news-get-last-title t))))
>>
>> (defun sachac-news-is-there-new-title-p (&optional use-current-buffer)
>> "According to the last save, return t when a new post is found.
>> @@ -284,12 +277,9 @@ last news buffer. Else, open the index.org and retrieve the last news."
>>
>> (or (null sachac-news-last-saved-title)
>> (not (string-equal last-title
>> - sachac-news-last-saved-title)))) )
>> + sachac-news-last-saved-title)))))
>>
>> -;;
>> -;; --------------------
>> -;; Data or config. load/save
>> -;;
>> +;;; Data or config. load/save
>>
>> (defun sachac-news-load-data ()
>> "Update variables which values are in the configuration file.
>> @@ -305,7 +295,7 @@ important variables."
>> (setq sachac-news-last-saved-title
>> (alist-get 'last-saved-title expr))
>> ;; Return the expression loaded
>> - expr))) )
>> + expr))))
>>
>> (defun sachac-news-save-data ()
>> "Save some important variables into the data file.
>> @@ -313,20 +303,17 @@ These variables can be loaded again with `sachac-news-load-data'."
>> (with-temp-buffer
>> (let ((data (list (cons 'last-update sachac-news-last-update)
>> (cons 'last-saved-title sachac-news-last-saved-title))))
>> - (insert (prin1-to-string data))
>> - (write-file (sachac-news-dir-datafile))
>> - data)) )
>> + (prin1 data (current-buffer))
>> + (write-region nil nil (sachac-news-dir-datafile) nil 'silent)
>> + data)))
>>
>> (defun sachac-news-load-data-if-needed ()
>> "If the data has not been loaded yet, load it."
>> (unless sachac-news-data-loaded
>> (sachac-news-load-data)
>> - (setq sachac-news-data-loaded t)) )
>> + (setq sachac-news-data-loaded t)))
>>
>> -;;
>> -;; --------------------
>> -;; Git clone/update
>> -;;
>> +;;; Git clone/update
>>
>> (defun sachac-news-update-last-update ()
>> "Update the `sachac-news-last-update' date with the current date."
>> @@ -335,6 +322,7 @@ These variables can be loaded again with `sachac-news-load-data'."
>>
>> (defun sachac-news-update-time-str ()
>> "Return a string with the last time and the amount of time left."
>> + ;; Perhaps format this in a temporary buffer, then return the buffer string?
>> (format "Waiting time: %s hours
>> -- Update --
>> Last time updated: %s
>> @@ -361,19 +349,19 @@ Time left for automatic forced update: %s %s"
>> (* sachac-news-update-hours-wait 60 60)))
>> "No timer setted")
>> (number-to-string (/ (sachac-news-get-update-time-left) 60))
>> - "minutes") )
>> + "minutes"))
>>
>> (defun sachac-news-get-update-wait-seconds ()
>> "Get the `sachac-news-update-hours-wait' in seconds."
>> - (* sachac-news-update-hours-wait 60 60) )
>> + (* sachac-news-update-hours-wait 60 60))
>>
>> (defun sachac-news-show-update-time ()
>> "Display the time left for the next update."
>> (interactive)
>> (sachac-news-load-data-if-needed)
>> (if sachac-news-last-update
>> - (message (sachac-news-update-time-str))
>> - (message "Git has not been called before.")) )
>> + (message "%s" (sachac-news-update-time-str))
>> + (message "Git has not been called before.")))
>>
>> (defun sachac-news-get-update-time-left ()
>> "Return the seconds left for the next scheduled update.
>> @@ -384,7 +372,7 @@ been setted)."
>> (if sachac-news-timer-setted-time
>> (- (+ sachac-news-timer-setted-time (sachac-news-get-update-wait-seconds))
>> (time-convert (current-time) 'integer))
>> - 0) )
>> + 0))
>>
>> (defun sachac-news-get-update-enable-time-left ()
>> "Return the seconds left for the next enabled update.
>> @@ -398,7 +386,7 @@ loaded)."
>> (if sachac-news-last-update
>> (- (+ sachac-news-last-update (sachac-news-get-update-wait-seconds))
>> (time-convert (current-time) 'integer))
>> - 0) )
>> + 0))
>>
>> (defun sachac-news-get-update-time-elapsed ()
>> "Return the seconds elapsed since the last update.
>> @@ -408,19 +396,19 @@ Return the numbre of seconds after the maximum wait + 1 if
>> (if sachac-news-last-update
>> (- (time-convert (current-time) 'integer)
>> sachac-news-last-update)
>> - (+ (sachac-news-get-update-wait-seconds) 1)) )
>> + (+ (sachac-news-get-update-wait-seconds) 1)))
>>
>> (defun sachac-news-is-time-for-update-p ()
>> "Check if a day has passed since the last update."
>> (if sachac-news-last-update
>> (>= (sachac-news-get-update-time-elapsed)
>> - (sachac-news-get-update-wait-seconds) )
>> - t) )
>> + (sachac-news-get-update-wait-seconds))
>> + t))
>>
>> (defun sachac-news-create-dirs ()
>> "Create the needed directories to save data and the repository."
>> (make-directory sachac-news-data-directory t)
>> - (make-directory (sachac-news-dir-git) t) )
>> + (make-directory (sachac-news-dir-git) t))
>>
>> (defun sachac-news--git-sentinel (_process event)
>> "Git sentinel.
>> @@ -454,19 +442,19 @@ FUNC-CALL-AFTER is a function called after the git process endend successfully."
>> (when func-call-after
>> (add-hook 'sachac-news--git-hook func-call-after))
>> (setq sachac-news--git-process
>> - (if (file-exists-p (sachac-news-git-index-org))
>> - (start-process-shell-command "sachac-news-git-pull"
>> + (let ((default-directory (expand-file-name "emacs-news" (sachac-news-dir-git))))
>> + ;; I am not sure what the point is there, but I suspect
>> + ;; there should be a better way to do this using timers
>> + ;; and vc-git.
>> + (if (file-exists-p (sachac-news-git-index-org))
>> + (start-process-shell-command "sachac-news-git-pull"
>> + "*sachac-news-git*"
>> + (concat "sleep 60 ; " git-program " pull"))
>> + (start-process-shell-command "sachac-news-git-clone"
>> "*sachac-news-git*"
>> - (concat
>> - "cd " (sachac-news-dir-git) "/emacs-news ; sleep 60 ; "
>> - git-program
>> - " pull"))
>> - (start-process-shell-command "sachac-news-git-clone"
>> - "*sachac-news-git*"
>> - (concat
>> - "cd " (sachac-news-dir-git) "; sleep 60 ; "
>> - git-program " clone https://github.com/sachac/emacs-news.git"))))
>> - (set-process-sentinel sachac-news--git-process #'sachac-news--git-sentinel)) )
>> + (concat "sleep 60 ; " git-program " clone \
>> +https://github.com/sachac/emacs-news.git")))))
>> + (set-process-sentinel sachac-news--git-process #'sachac-news--git-sentinel)))
>>
>>
>> (defun sachac-news-update-git (&optional force-update
>> @@ -501,11 +489,11 @@ pull/clone."
>> (when callback-if-no-update
>> (funcall callback-if-no-update))))
>> ;; Git program not founded
>> - (message "%s %s\n%s\n%s"
>> - "The Git program has not been founded!"
>> - "SachaC-news cannot download news without it!"
>> - "Please install it in our system or customize the variable:"
>> - "M-x customize-option sachac-news-git-command"))) )
>> + (message (substitute-command-keys
>> + "The Git program has not been founded! \
>> +SachaC-news cannot download news without it!
>> +Please install it in our system or customize the variable: )
>> +\\[customize-option] sachac-news-git-command")))))
>>
>> (defun sachac-news-open-index-file ()
>> "Open the index.org file from the local repository.
>> @@ -519,15 +507,10 @@ how the update is done."
>> (sachac-news-update-git)
>> (if (file-exists-p (sachac-news-git-index-org))
>> (find-file (sachac-news-git-index-org))
>> - (message "%s\n%s"
>> - "Index file not found! Did something wrong happen?"
>> - "See `sachac-news-update-git'.")) )
>> + (message "Index file not found! Did something wrong happen?
>> +See `sachac-news-update-git'.")))
>>
>> -
>> -;;
>> -;; --------------------
>> -;; Folding categories
>> -;;
>> +;;; Folding categories
>>
>> (defun sachac-news-find-all-categories (category-regexps &optional org-element)
>> "Match paragraph with the CATEGORY-REGEXPS regexp.
>> @@ -554,7 +537,7 @@ Returns a list of org-element of type \\'item found in the index.org."
>> (string-match-p category element))
>> category-regexps))
>>
>> - parent)))) )
>> + parent)))))
>>
>>
>> (defun sachac-news-fold-all-items (item-list)
>> @@ -582,12 +565,9 @@ This function works on any Org file, even at the Emacs news' index.org."
>> (let ((category-list (if category-regexp-list category-regexp-list
>> sachac-news-fold-category-regexp-list)))
>> (sachac-news-fold-all-items
>> - (sachac-news-find-all-categories category-list))) )
>> + (sachac-news-find-all-categories category-list))))
>>
>> -;;
>> -;; --------------------
>> -;; Alarm
>> -;;
>> +;;; Alarm
>>
>> (defun sachac-news-default-notify-alarm ()
>> "The default alarm.
>> @@ -596,7 +576,7 @@ Use the notify-send to send the alarm."
>> (when program
>> (shell-command (concat program
>> " --app-name=\"Emacs: SachaC-news\""
>> - " \"Check the News!\"")))) )
>> + " \"Check the News!\"")))))
>>
>> (defun sachac-news-default-sound-alarm ()
>> "The default sound alarm.
>> @@ -619,17 +599,14 @@ as fallback."
>> (car program-data)
>> (split-string
>> (format (cadr program-data) sachac-news-alarm-sound-file)))
>> - (ding t))) )
>> + (ding t))))
>>
>> (defun sachac-news-run-alarm-if-needed ()
>> "Run the alarm hook functions if there is a new post ."
>> (when (sachac-news-is-there-new-title-p)
>> - (run-hooks 'sachac-news-alarm-functions-hook)) )
>> + (run-hooks 'sachac-news-alarm-functions-hook)))
>>
>> -;;
>> -;; --------------------
>> -;; Timer
>> -;;
>> +;;; Timer
>>
>> (defun sachac-news-timer-function ()
>> "The function used by the timer."
>> @@ -638,7 +615,7 @@ as fallback."
>> (sachac-news-update-git t #'sachac-news-show-last-new-if-new)
>> (sachac-news-run-alarm-if-needed)
>>
>> - (sachac-news-activate-timer) )
>> + (sachac-news-activate-timer))
>>
>>
>> (defun sachac-news-activate-timer ()
>> @@ -650,9 +627,9 @@ Set the timer for executing on `sachac-news-update-hours-wait' hours."
>> (setq sachac-news-timer-setted-time (time-convert (current-time) 'integer))
>> (setq sachac-news-timer
>> (run-at-time
>> - (concat (number-to-string sachac-news-update-hours-wait) "hours")
>> - nil
>> - #'sachac-news-timer-function)) )
>> + (format "%d hours" sachac-news-update-hours-wait)
>> + nil
>> + #'sachac-news-timer-function)))
>>
>> (defun sachac-news-deactivate-timer ()
>> "Stop and cancel the timer."
>> @@ -660,7 +637,7 @@ Set the timer for executing on `sachac-news-update-hours-wait' hours."
>> (when (timerp sachac-news-timer)
>> (cancel-timer sachac-news-timer)
>> (setq sachac-news-timer nil))
>> - (setq sachac-news-timer-setted-time nil) )
>> + (setq sachac-news-timer-setted-time nil))
>>
>> (defun sachac-news-timer-status ()
>> "Is the timer setted or not?
>> @@ -668,8 +645,13 @@ Report the user about the timer status."
>> (interactive)
>> (if (timerp sachac-news-timer)
>> (message "Timer is setted and running.")
>> - (message "Timer is deactivated")) )
>> + (message "Timer is deactivated")))
>> +
>> +;; Don't activate side effects while loading your package! Instruct
>> +;; the users to add this to their init.el, so that one knows what is
>> +;; going on.
>>
>> -(sachac-news-activate-timer)
>> +;; (sachac-news-activate-timer)
>>
>> +(provide 'sachac-news)
>> ;;; sachac-news.el ends here
>> [3 <text/plain (7bit)>]
>>
>> > According to http://elpa.gnu.org/, and the README.org [2] file
>> > linked there, it says to notify to this mail address as
>> > first step. Also, it mentions other steps regarding pushing the
>> > code and adding an entry on elpa-packages file. But, there is a
>> > marker above indicating "OUTDATED" [3].
>>
>> That should be addressed ^^
>>
>> > Please, could you tell me if these steps are needed?
>> > If they are not, how should I proceed?
>>
>> As soon as we sort out the above comments, I can take care of adding the
>> package for you.
>>
>> > Cheers!
>> > Christian Gimenez
>> >
>> > [1] https://github.com/purcell/flycheck-package
>> > [2] https://git.savannah.gnu.org/cgit/emacs/elpa.git/plain/README
>> > [3] The section states: "Text below this marker is OUTDATED and
>> > still needs to be reviewed/rewritten!!"
>
> --
>
> - Mastodon: @cnngimenez@mastodon.social
>
> ,= ,-_-. =. Utilice GPG:
> ((_/)o o(\_)) * https://emailselfdefense.fsf.org/
> `-'(. .)`-' * Usando la terminal GNU/Linux:
> \_/ $ gpg2 --search-keys 77A56F0DA5DD9E05
>
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: [ELPA] New Package: p4_16-mode
@ 2023-11-18 21:12 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-11-18 21:12 UTC (permalink / raw)
To: Soham Gumaste; +Cc: emacs-devel
Soham Gumaste <sohamg2@gmail.com> writes:
>> +;;; History:
>> +
>> +;; The headers above have no special meaning, and could also be
>> +;; re-written in prose under a special section. Also, was the package
>> +;; really created just a few days ago?
>> +
>
> I mean, moved the file into a repo of its own on that day, and began making some
> modifications to better suit ELPA. The original file has a date from 2017.
> Should I use that instead?
I think that would reflect the history better.
>>
>> I suppose you want to add the package to NonGNU ELPA then?
>>
>
> I was not familiar with the distinction between GNU ELPA and NonGNU
> ELPA. But now
> that I have read up a bit, NonGNU ELPA does fit better.
OK.
> I have applied your patch, thanks for taking the time to help me with it.
> Please let me know if any further changes are needed, or if I need to
> create a new thread to submit to NonGNU ELPA.
As mentioned in the last thread, I don't know if "p4_16" is a technical
term, but I know that it is an unusual symbol name, so I want to make
sure if it would be possible to call it p4-16 or something like that
instead.
> Thanks
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: [ELPA] New Package: p4_16-mode
@ 2023-11-18 21:51 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-11-18 21:51 UTC (permalink / raw)
To: Soham Gumaste; +Cc: emacs-devel
Soham Gumaste <sohamg2@gmail.com> writes:
>> As mentioned in the last thread, I don't know if "p4_16" is a technical
>> term, but I know that it is an unusual symbol name, so I want to make
>> sure if it would be possible to call it p4-16 or something like that
>> instead.
>>
>
> Apologies for forgetting to reply to that part. So the language itself
> goes by "p4" or "p4lang" (think go/golang). The _14 and _16 refer to
> different diverging versions of the language. P4_14 is officially
> abandoned/deprecated (think python 2.7) and P4_16 is the "current
> revision of the p4 language" [1].
>
> That being said, I think "p4-16-mode" is clear enough to indicate
> which version is being implied and we could/should take the liberty to
> change the _ to a -. I am of the opinion that the "16" bit is
> necessary as the language itself is evolving. I do not see an issue
> with "p4-16-mode".
OK, the only thing which I believe is missing now is a "Version" tag in
the package header (see (info "(elisp) Simple Packages")). A new
version of every ELPA package is released whenever a commit touches that
line.
> Thanks
>
> [1]: https://p4.org/specs/
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: [ELPA] New Package: p4_16-mode
@ 2023-11-23 5:57 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-11-23 5:57 UTC (permalink / raw)
To: Soham Gumaste; +Cc: emacs-devel
Soham Gumaste <sohamg2@gmail.com> writes:
> Hello Philip,
>
> I was wondering if I get some notification that the package has been
> added to NonGNU ELPA.
You (or whatever address is listed under maintainer) will receive a
message every time a new release is made. I have just been
unfortunately busy the last few weeks so I got delayed, sorry about
that.
> I am new to the "mailing list world" and was
> wondering what the process looks like. I guess I will eventually see a
> commit adding the package on savannah. Anyway, I don't mean to rush.
Basically yes, I just had to add the package specification to
elpa-packages. There is no magic here in the "mailing list world" :^)
> Thanks
^ permalink raw reply [relevance 99%]
* Re: [ELPA] New package: dired-duplicates
@ 2023-11-23 6:12 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-11-23 6:12 UTC (permalink / raw)
To: Harald Judt; +Cc: emacs-devel
Harald Judt <h.judt@gmx.at> writes:
> Hi,
>
> On 2023-11-10 at 09:37, Philip Kaludercic wrote:
>
> [...]
>
>> Sorry for the late response; It appears that the package can now be
>> built (see https://elpa.gnu.org/packages/dired-duplicates.html), I had
>> the same issue as you describe on my local machine and now it appears to
>> be gone. Perhaps this was resolved by your recent 0.2 commit?
>
> Thank you. Yes that seems to be so. Everything is fine now.
>
> I am still unable to build it locally using the elpa instructions, but
> I suppose this has something todo with sandboxing and my local
> configuration. It can byte-compile dired-duplicates.el but not create
> the tarball:
>
> make packages/dired-duplicates
> -----------------------------------------------------------------------------
> emacs --batch -Q -l admin/elpa-admin.el \
> -f elpaa-batch-pkg-spec-make-dependencies .pkg-descs.mk
> Generating description file packages/dired-duplicates/dired-duplicates-pkg.el
> Byte compiling packages/dired-duplicates/dired-duplicates.el
> emacs --batch -l admin/elpa-admin.el \
> -f elpaa-batch-generate-autoloads
> packages/dired-duplicates/dired-duplicates-autoloads.el
> INFO Scraping files for loaddefs...
> INFO Scraping files for loaddefs...done
> GEN dired-duplicates-autoloads.el
> -----------------------------------------------------------------------------
>
>
> make build/dired-duplicates
> -----------------------------------------------------------------------------
> emacs --batch -l /mnt/scratch/work/elpa/admin/elpa-admin.el \
> -f elpaa-batch-make-one-package dired-duplicates
> ======== Building tarball
> archive-devel/dired-duplicates-0.2.0.20231109.135341.tar...
> Build error for
> archive-devel/dired-duplicates-0.2.0.20231109.135341.tar: (error
> "Error-indicating exit code in elpaa--call-sandboxed:
> emacs: error while loading shared libraries: libgccjit.so.0: cannot
> open shared object file: No such file or directory
> ")
> ######## Build of package
> archive-devel/dired-duplicates-0.2.0.20231109.135341.tar
> FAILED!!
> ======== Building tarball archive/dired-duplicates-0.2.tar...
> Build error for archive/dired-duplicates-0.2.tar: (error
> "Error-indicating exit code in elpaa--call-sandboxed:
> emacs: error while loading shared libraries: libgccjit.so.0: cannot
> open shared object file: No such file or directory
> ")
> ######## Build of package archive/dired-duplicates-0.2.tar FAILED!!
> -----------------------------------------------------------------------------
>
> The libgccjit.so resides in a directory that is a subdir of /usr which
> is listed in the sandbox ro-binds
> (/usr/lib/gcc/x86_64-pc-linux-gnu/13/libgccjit.so.0), so I wonder
> what's the problem.
I am not sure either... what version of bwrap do you have installed? If
you manually edit the `elpaa--sandbox' in elpa-admin.el to nil, does
anything change?
> Harald
^ permalink raw reply [relevance 99%]
* Re: a mode for algol 68
@ 2023-11-30 7:10 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-11-30 7:10 UTC (permalink / raw)
To: Omar Polo; +Cc: emacs-devel
Omar Polo <op@omarpolo.com> writes:
> (please Cc: me since I'm not subscribed to this list)
>
> Two years ago I started hacking on Jose E. Marchesi' algol-mode (that
> I've renamed a68-mode) while I was playing with the algol68g compiler.
> Truth to be told, I think I've spent more time hacking on the emacs mode
> that with the language itself, but anyway...
>
> I haven't touched the mode any more for the last two years, and I doubt
> I'll hack again on it in the future. Although it's almost finished,
> there remains issues with the indentation and font-locking in some
> cases.
>
> My hope would be that some friendly hacker would take interest in
> maintaining it and maybe even distribute it in ELPA / NonGNU Elpa.
I think it would be very nice to have this added to GNU ELPA. If the
code works (and I see it isn't too much), it shouldn't be too much of a
maintenance burden, so I'd be fine with helping out.
> On the copyright side, I don't know Jose E. Marchesi and I copied
> initial the code from some random github repository. Not great, I know,
> but it was the only major mode for algol68. However, I *do* have an FSF
> copyright assignment and I ended up rewriting almost all of the code in
> the end. I paied attention to do the 'initial import' with the original
> code as-is and do my changes on top. It's 53 commits in total.
I cannot evaluate this myself, do you a link to the original GitHub
repository?
> The code is available here for browsing here:
> <https://git.omarpolo.com/?action=summary&path=a68-mode.git>
> and can be cloned with git via anonymous SSH via
> <ssh://anon@omarpolo.com/a68-mode.git> or with HTTPS via
> <https://git.omarpolo.com/a68-mode.git>.
>
>
> Thanks,
>
> Omar Polo
^ permalink raw reply [relevance 99%]
* Re: a mode for algol 68
@ 2023-11-30 13:01 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-11-30 13:01 UTC (permalink / raw)
To: Jose E. Marchesi; +Cc: Omar Polo, emacs-devel
"Jose E. Marchesi" <jemarch@gnu.org> writes:
>> On 2023/11/30 07:10:20 +0000, Philip Kaludercic <philipk@posteo.net> wrote:
>>> Omar Polo <op@omarpolo.com> writes:
>>>
>>> > (please Cc: me since I'm not subscribed to this list)
>>> >
>>> > Two years ago I started hacking on Jose E. Marchesi' algol-mode (that
>>> > I've renamed a68-mode) while I was playing with the algol68g compiler.
>>> > Truth to be told, I think I've spent more time hacking on the emacs mode
>>> > that with the language itself, but anyway...
>>> >
>>> > I haven't touched the mode any more for the last two years, and I doubt
>>> > I'll hack again on it in the future. Although it's almost finished,
>>> > there remains issues with the indentation and font-locking in some
>>> > cases.
>>> >
>>> > My hope would be that some friendly hacker would take interest in
>>> > maintaining it and maybe even distribute it in ELPA / NonGNU Elpa.
>>>
>>> I think it would be very nice to have this added to GNU ELPA. If the
>>> code works (and I see it isn't too much), it shouldn't be too much of a
>>> maintenance burden, so I'd be fine with helping out.
>>>
>>> > On the copyright side, I don't know Jose E. Marchesi and I copied
>>> > initial the code from some random github repository. Not great, I know,
>>> > but it was the only major mode for algol68. However, I *do* have an FSF
>>> > copyright assignment and I ended up rewriting almost all of the code in
>>> > the end. I paied attention to do the 'initial import' with the original
>>> > code as-is and do my changes on top. It's 53 commits in total.
>>>
>>> I cannot evaluate this myself, do you a link to the original GitHub
>>> repository?
>>
>> I took the code from
>> https://github.com/lachrymology/me/blob/master/.emacs.d/extras/algol-mode.el
>> but upon a closer look it seems to originate from here:
>> https://www.jemarch.net/algol68.html
>>
>> I'm cc'ing Jose E. Marchesi using the mail found on (presumibly) their
>> website. Having a @gnu.org account makes me think that there shouldn't
>> be copyright issues :-)
>
> I have papers in place for Emacs, and I am totally willing to transfer
> the copyright for a68-mode.el's original code (whatever of it survives
> in latest algol-mode.el) to the FSF.
OK, in that case everything should be given to add the package to GNU
ELPA. The only matter left discussing is if you want to continue to
host the repository yourself and have the ELPA server mirror the
repository regularly.
>> I apologize for not searching better initially, I should have contacted
>> Marchesi in the first place. I somehow have completely missed their
>> website.
>>
>>> > The code is available here for browsing here:
>>> > <https://git.omarpolo.com/?action=summary&path=a68-mode.git>
>>> > and can be cloned with git via anonymous SSH via
>>> > <ssh://anon@omarpolo.com/a68-mode.git> or with HTTPS via
>>> > <https://git.omarpolo.com/a68-mode.git>.
>>> >
>>> >
>>> > Thanks,
>>> >
>>> > Omar Polo
^ permalink raw reply [relevance 99%]
* Re: [ELPA] Use :release-branch for plz.el
@ 2023-12-17 8:38 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-12-17 8:38 UTC (permalink / raw)
To: Adam Porter; +Cc: emacs-devel
Adam Porter <adam@alphapapa.net> writes:
> Hi Stefan, Philip, et al,
>
> Please see the attached patch which sets the release branch for
> plz.el. This will allow me to make small, bug-fix version releases
> from the stable branch while the next version is in development on the
> master branch.
Thanks, I have applied and pushed the patch.
> BTW, after having done this for a few packages now, this seems to me
> to be the best practice. It might be worth recommending this for new
> packages.
I have no real opinion on this, other than that it might be
unnecessarily complicated for most packages.
> Thanks,
> Adam
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Ellama comments
@ 2023-12-17 21:39 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-12-17 21:39 UTC (permalink / raw)
To: Sergey Kostyaev; +Cc: emacs-devel
Sergey Kostyaev <sskostyaev@gmail.com> writes:
> .elpaignore added, thank you.
OK, as there haven't been any comments I have added the package to GNU
ELPA.
^ 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%]
* 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: [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: 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: 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] 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-27 13:47 99% ` 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: 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: 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: 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?
@ 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: 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 devicetree-ts-mode
@ 2024-01-16 6:18 99% ` Philip Kaludercic
0 siblings, 0 replies; 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: [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: 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%]
* 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: 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: [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: [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: [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-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: 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: 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-05 7:11 99% ` Philip Kaludercic
0 siblings, 0 replies; 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: 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: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: 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: 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: [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-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: 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: [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: 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: [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-21 17:01 99% ` Philip Kaludercic
0 siblings, 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: [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: [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: 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: 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: [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 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: [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: 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: 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: 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: 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: [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: [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: 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: (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: [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: 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: 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: 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: 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: 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: [DISCUSSION] "quick-help" popup for org-columns (column view)
@ 2024-04-11 6:37 99% ` Philip Kaludercic
2024-04-13 8:37 99% ` Philip Kaludercic
0 siblings, 1 reply; 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-11 6:37 99% ` Philip Kaludercic
@ 2024-04-13 8:37 99% ` Philip Kaludercic
0 siblings, 0 replies; 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: Objed maintenance
@ 2024-04-27 10:06 99% ` Philip Kaludercic
0 siblings, 0 replies; 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
[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: [ELPA] New package: colorful-mode
@ 2024-04-27 21:12 99% ` Philip Kaludercic
0 siblings, 0 replies; 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: 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: 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: [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: Objed maintenance
@ 2024-05-02 6:02 99% ` Philip Kaludercic
0 siblings, 0 replies; 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: 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: 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: 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: 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-06 20:00 99% ` Philip Kaludercic
0 siblings, 0 replies; 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: [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%]
* [ELPA] Re: SageMath and Emacs
@ 2024-05-09 12:24 99% ` Philip Kaludercic
0 siblings, 0 replies; 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: 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%]
* 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%]
Results 1-200 of ~1000 next [<= 99%] | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
[not found] <168884609732.27984.6450580686777461843@vcs2.savannah.gnu.org>
[not found] ` <20230708195457.95F1AC11DD8@vcs2.savannah.gnu.org>
2023-07-08 21:47 ` [elpa] main 2ec80977e1: * elpa-packages (dired-preview): New package Stefan Monnier
2023-07-10 18:29 ` Philip Kaludercic
2023-07-13 18:40 ` Protesilaos Stavrou
2023-07-13 20:29 99% ` Philip Kaludercic
[not found] <85msy98sni.fsf@elpa.gnu.org>
[not found] ` <E1qbslO-0006oK-RA@fencepost.gnu.org>
2023-09-01 14:38 ` Adding with-editor to Emacs? Jonas Bernoulli
2023-09-01 16:12 ` Eli Zaretskii
2023-09-01 17:44 ` Jonas Bernoulli
2023-09-01 18:42 ` Eli Zaretskii
2023-09-03 14:36 ` Manuel Giraud via Emacs development discussions.
2023-09-03 15:34 ` Eli Zaretskii
2023-09-03 18:54 ` Manuel Giraud via Emacs development discussions.
2023-09-03 19:26 ` Eli Zaretskii
2023-09-05 0:27 ` Richard Stallman
2023-09-15 21:59 ` Björn Bidar
2023-09-17 23:03 ` Richard Stallman
2023-09-18 8:59 99% ` Philip Kaludercic
[not found] <168565525463.8048.4344900670894070114@vcs2.savannah.gnu.org>
[not found] ` <20230601213415.21F57C21A9F@vcs2.savannah.gnu.org>
2023-06-05 12:46 99% ` [elpa] externals/firefox-javascript-repl 056b687af4 2/3: Work around missing submodule support in GNU ELPA Philip Kaludercic
[not found] <169385595799.24305.652316651780689026@vcs2.savannah.gnu.org>
[not found] ` <20230904193238.46053C04DB0@vcs2.savannah.gnu.org>
2023-09-04 20:54 ` master 82cc1f4fda1: Revert use of seq-count in shr-count Philip Kaludercic
2023-09-05 2:34 ` Eli Zaretskii
2023-09-06 0:02 ` Karthik Chikmagalur
2023-09-06 11:34 ` Eli Zaretskii
2023-09-06 12:34 ` Eli Zaretskii
2023-09-06 22:21 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
[not found] <169293952710.29420.14302018247730714407@vcs2.savannah.gnu.org>
[not found] ` <20230825045847.7DFE9C1D362@vcs2.savannah.gnu.org>
2023-08-25 7:43 99% ` [elpa] externals/standard-themes 0604883ecc: Expand 'deftheme' with metadata Philip Kaludercic
[not found] <87sf5oqu07.fsf@posteo.net>
[not found] ` <F7BC15FC-3F0C-48CA-BE77-F0846B61DAB1@gmail.com>
[not found] ` <87o7gcqd96.fsf@posteo.net>
[not found] ` <6B0DECA2-8E81-495E-99AC-A9F81B43C05E@gmail.com>
2023-12-14 11:18 ` Ellama comments Philip Kaludercic
2023-12-16 17:05 ` Sergey Kostyaev
2023-12-17 12:06 ` Philip Kaludercic
2023-12-17 16:56 ` Sergey Kostyaev
2023-12-17 21:39 99% ` Philip Kaludercic
[not found] <169468919249.10884.8856179202519044902@vcs2.savannah.gnu.org>
[not found] ` <20230914105954.20BD1C051D0@vcs2.savannah.gnu.org>
2023-09-14 12:25 99% ` [nongnu] elpa/helm 07dacfe2e2 08/11: Prefer string-match-p over string-suffix-p Philip Kaludercic
2023-09-14 12:59 ` Eli Zaretskii
2023-09-14 13:06 99% ` Philip Kaludercic
2023-09-14 13:13 ` Eli Zaretskii
2023-09-14 16:21 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 17:02 99% ` Philip Kaludercic
2024-02-21 16:24 ` Stefan Monnier
2024-02-21 17:07 99% ` Philip Kaludercic
[not found] <87wn1axgh6.fsf@breatheoutbreathe.in>
[not found] ` <jwvr0ndq3b8.fsf-monnier+emacs@gnu.org>
[not found] ` <877cp5bmig.fsf@breatheoutbreathe.in>
[not found] ` <jwvtts8ib4b.fsf-monnier+emacs@gnu.org>
2022-06-08 8:41 ` Comparing hash table objects Ihor Radchenko
[not found] ` <8734zoaolv.fsf@localhost>
[not found] ` <jwv1qf8iqua.fsf-monnier+emacs@gnu.org>
[not found] ` <87fs3o8uil.fsf@localhost>
[not found] ` <87msxwa8kd.fsf@breatheoutbreathe.in>
[not found] ` <87il8j7ji9.fsf@localhost>
[not found] ` <80479897-500e-fe60-6586-0a44ccb5993b@daniel-mendler.de>
[not found] ` <877coz7f6h.fsf@localhost>
[not found] ` <86d6e412-9e5b-9086-56ce-e3794085096a@daniel-mendler.de>
2023-09-09 12:12 ` compat.el and Emacs unstable master branch features (was: bug#63513: [PATCH] Make persist-defvar work with records and hash tables) Ihor Radchenko
2023-09-09 12:29 ` Daniel Mendler
2023-09-11 8:45 ` Ihor Radchenko
2023-09-12 10:02 ` compat.el and Emacs unstable master branch features Philip Kaludercic
2023-09-12 10:27 ` Daniel Mendler
2023-09-13 10:31 ` Philip Kaludercic
2023-09-13 17:11 ` Daniel Mendler
2023-10-15 8:43 ` Ihor Radchenko
2023-10-15 12:09 99% ` Philip Kaludercic
[not found] <168595059426.2523.2109338263713299231@vcs2.savannah.gnu.org>
[not found] ` <20230605073635.19060C00613@vcs2.savannah.gnu.org>
2023-06-05 10:24 99% ` master a30781399b3: * subr-x (eval-command-interactive-spec): New function Philip Kaludercic
[not found] <169158945793.6388.8459711282582712176@vcs2.savannah.gnu.org>
[not found] ` <20230809135738.457BDC038BF@vcs2.savannah.gnu.org>
2023-08-11 6:07 ` [elpa] externals/compat 6a60af22da: Optimize string-search Philip Kaludercic
2023-08-11 7:12 ` Daniel Mendler
2023-08-11 8:17 99% ` Philip Kaludercic
2023-08-11 6:23 ` Eli Zaretskii
2023-08-11 8:15 99% ` 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
[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 ` Philip Kaludercic
2024-03-16 13:23 ` Basil L. Contovounesios
2024-03-16 13:55 99% ` Philip Kaludercic
[not found] <168416742839.11327.1066281628551652191@vcs2.savannah.gnu.org>
[not found] ` <20230515161708.AD134C13919@vcs2.savannah.gnu.org>
2023-05-15 16:21 ` [nongnu] main 83410aacf7: * elpa-packages (devil): New package Philip Kaludercic
2023-05-15 16:41 ` Stefan Monnier
2023-05-16 16:12 ` Philip Kaludercic
2023-05-23 23:37 ` Susam Pal
2023-05-24 6:41 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
[not found] <169722725606.27637.3820182151024041420@vcs2.savannah.gnu.org>
[not found] ` <20231013200057.2C7FCC09BC9@vcs2.savannah.gnu.org>
2023-10-13 22:12 99% ` [nongnu] elpa/hyperdrive b5294b4354 4/4: Tidy: Use zerop instead of = 0 Philip Kaludercic
2023-10-14 21:33 ` Emanuel Berg
2023-10-15 9:17 99% ` 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
[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
[not found] <169373450576.30740.4674573984693456027@vcs2.savannah.gnu.org>
[not found] ` <20230903094826.33FFAC045B5@vcs2.savannah.gnu.org>
2023-09-03 9:54 ` master c290b034e0f 1/2: Move `wholenump` alias definition Philip Kaludercic
2023-09-03 10:02 ` Mattias Engdegård
2023-09-03 10:07 ` Eli Zaretskii
2023-09-03 10:22 ` Mattias Engdegård
2023-09-03 10:41 ` Eli Zaretskii
2023-09-03 10:46 99% ` Philip Kaludercic
[not found] <169185199333.11628.2162615922937919004@vcs2.savannah.gnu.org>
[not found] ` <20230812145313.C853CC038C2@vcs2.savannah.gnu.org>
2023-08-16 12:55 ` master 5892b4db8de 2/3: Convert dictionary-mode to define-derived-mode Visuwesh
2023-08-16 22:33 99% ` Philip Kaludercic
2023-08-19 11:08 ` Stefan Kangas
2023-08-19 15:46 99% ` Philip Kaludercic
[not found] <170836288097.22729.10027592558614089561@vcs2.savannah.gnu.org>
[not found] ` <20240219171441.76EC3C3421F@vcs2.savannah.gnu.org>
2024-02-19 18:59 ` 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
2023-11-17 10:11 [Reminder]Decommissoned keyservers CHENG Gao via Emacs development discussions.
2023-11-17 21:15 99% ` Philip Kaludercic
2023-11-18 0:54 ` CHENG Gao via Emacs development discussions.
2024-02-11 17:39 ` Philip Kaludercic
2024-02-17 18:13 ` Stefan Kangas
2024-02-17 18:48 99% ` Philip Kaludercic
2023-11-17 21:02 ` Jonas Bernoulli
2023-11-18 15:41 99% ` Philip Kaludercic
2024-05-01 18:06 Objed maintenance Philip Kaludercic
2024-05-02 1:39 ` Adam Porter
2024-05-02 6:02 99% ` Philip Kaludercic
2023-08-31 2:23 [NonGNU ELPA] New package: flymake-guile Distopico
2023-08-31 6:52 ` Philip Kaludercic
2023-08-31 16:08 ` Distopico
2023-08-31 18:02 ` Philip Kaludercic
2023-08-31 19:22 ` Distopico
2023-09-01 13:09 99% ` Philip Kaludercic
2023-09-01 13:45 ` Dr. Arne Babenhauserheide
2023-09-01 13:52 99% ` Philip Kaludercic
2023-09-01 13:58 ` Distopico
2023-09-01 14:23 ` Philip Kaludercic
2023-09-05 2:23 ` Distopico
2023-09-05 7:08 99% ` Philip Kaludercic
2023-10-13 10:35 [ELPA] New package: dape Daniel Pettersson
2023-10-13 12:24 ` Philip Kaludercic
2023-10-14 12:28 ` Daniel Pettersson
2023-10-14 14:54 ` Philip Kaludercic
2023-10-18 21:54 ` Daniel Pettersson
2023-11-01 16:50 99% ` Philip Kaludercic
2023-10-19 2:08 ` Adam Porter
2023-10-19 10:52 ` Krister Schuchardt
2023-10-19 11:06 ` Dmitry Gutov
2023-10-20 14:53 ` John Yates
2023-11-01 19:13 ` Dmitry Gutov
2023-11-02 14:42 ` João Távora
2023-11-04 9:51 ` Daniel Pettersson
2023-11-04 10:00 99% ` Philip Kaludercic
2024-01-23 15:31 [PATCH] dictonary.el documentation No Wayman
2024-01-23 17:14 99% ` Philip Kaludercic
2023-07-10 18:53 Stability of project.el Philip Kaludercic
2023-07-11 1:27 ` Dmitry Gutov
2023-07-11 5:26 99% ` Philip Kaludercic
2024-03-08 10:27 I created a faster JSON parser Herman, Géza
2024-03-09 20:37 ` Christopher Wellons
2024-03-10 6:31 ` Eli Zaretskii
2024-03-10 21:39 99% ` Philip Kaludercic
2023-10-29 13:45 [NonGnu ELPA] New package: flymake-codespell Chmouel Boudjnah
2023-10-29 22:40 ` Stefan Kangas
2023-10-30 3:59 ` Chmouel Boudjnah
2023-10-31 8:29 99% ` Philip Kaludercic
2023-08-07 7:57 Changes to make in elpa-packages file for nongnu elpa Thierry Volpiatto
2023-08-07 13:30 ` Philip Kaludercic
2023-08-07 18:19 ` Thierry Volpiatto
2023-08-07 20:33 ` Philip Kaludercic
2023-08-08 6:34 ` Michael Albinus
2023-08-08 16:37 99% ` Philip Kaludercic
2023-08-08 16:41 ` Michael Albinus
2023-08-09 7:06 99% ` Philip Kaludercic
2023-08-09 11:53 ` Eli Zaretskii
2023-08-09 14:53 ` Philip Kaludercic
2023-08-09 14:55 ` Eli Zaretskii
2023-08-09 15:24 99% ` Philip Kaludercic
2023-08-08 4:33 ` Thierry Volpiatto
2023-08-08 5:52 ` Philip Kaludercic
2023-08-15 16:55 ` Philip Kaludercic
2023-08-16 6:51 ` Thierry Volpiatto
2023-08-16 10:10 ` Philip Kaludercic
2023-08-16 14:10 ` Eli Zaretskii
2023-08-16 18:52 99% ` Philip Kaludercic
2023-08-16 10:14 ` Thierry Volpiatto
2023-08-16 11:03 ` Philip Kaludercic
2023-08-16 11:55 ` Thierry Volpiatto
2023-08-16 18:34 ` Proposal for 'package-isolate' command Philip Kaludercic
2023-08-17 5:30 ` Thierry Volpiatto
2023-08-17 8:34 ` Philip Kaludercic
2023-08-20 6:40 ` Thierry Volpiatto
2023-08-20 16:06 ` Thierry Volpiatto
2023-08-20 18:41 ` Philip Kaludercic
2023-08-20 19:15 ` Thierry Volpiatto
2023-08-20 20:28 99% ` Philip Kaludercic
2023-08-17 13:32 ` Thierry Volpiatto
2023-08-17 14:04 99% ` Philip Kaludercic
2023-08-17 9:07 ` Eshel Yaron
2023-08-17 14:19 99% ` Philip Kaludercic
2023-08-15 17:34 ` Changes to make in elpa-packages file for nongnu elpa Eshel Yaron
2023-08-15 19:39 99% ` Proposal for 'package-isolate' command Philip Kaludercic
2024-05-09 10:35 SageMath and Emacs Rahguzar
2024-05-09 12:24 99% ` [ELPA] " Philip Kaludercic
2023-08-07 20:22 [ELPA] New Package: phpinspect.el Hugo Thunnissen
2023-08-12 4:56 ` Stefan Monnier
2023-08-15 17:45 ` Hugo Thunnissen
2023-08-15 20:28 99% ` Philip Kaludercic
2023-08-15 21:33 ` Hugo Thunnissen
2023-08-15 21:56 99% ` Philip Kaludercic
2023-09-18 7:25 package-vc support for :files keyword Tony Zorman
2023-09-18 9:10 ` Philip Kaludercic
2023-09-18 14:43 ` Tony Zorman
2023-09-18 15:52 ` Philip Kaludercic
2023-09-18 19:40 ` Tony Zorman
2023-09-19 8:47 ` Philip Kaludercic
2023-09-19 13:48 ` Adam Porter
2023-09-19 14:00 99% ` Philip Kaludercic
2023-09-19 14:17 ` Tony Zorman
2023-09-20 7:32 ` Philip Kaludercic
2023-09-21 13:28 ` Tony Zorman
2023-09-21 16:32 99% ` Philip Kaludercic
2023-09-19 22:51 ` Jonas Bernoulli
2023-09-22 12:38 ` Stefan Kangas
2023-09-22 13:26 99% ` Philip Kaludercic
2023-09-18 18:54 ` Adam Porter
2023-09-19 8:37 ` Philip Kaludercic
2023-09-19 12:23 ` Adam Porter
2023-09-19 13:56 99% ` Philip Kaludercic
2023-07-17 10:14 New branch feature/named-lambdas Alan Mackenzie
2023-07-17 19:52 99% ` Philip Kaludercic
2024-03-22 22:56 recursion to iteration macro Emanuel Berg
2024-03-23 7:12 99% ` Philip Kaludercic
2024-05-08 11:33 [ELPA] New consult-denote package Protesilaos Stavrou
2024-05-08 17:19 ` Philip Kaludercic
2024-05-09 4:00 ` Protesilaos Stavrou
2024-05-09 8:20 99% ` Philip Kaludercic
2023-08-26 5:50 Org mode and Emacs Eli Zaretskii
2023-08-26 16:49 ` Jose E. Marchesi
2023-08-26 16:56 ` Ihor Radchenko
2023-08-26 20:28 99% ` Philip Kaludercic
2023-08-12 18:35 New Package for NonGNU-ELPA: clojure-ts-mode Danny Freeman
2023-08-27 1:35 ` Clojure mode Richard Stallman
2023-08-27 1:42 ` Dmitry Gutov
2023-08-27 18:55 ` Bozhidar Batsov
2023-08-27 18:58 ` Eli Zaretskii
2023-08-27 19:08 ` Bozhidar Batsov
2023-08-27 19:13 ` Eli Zaretskii
2023-08-28 16:35 ` chad
2023-08-28 17:04 ` Eli Zaretskii
2023-08-28 20:51 ` chad
2023-08-28 22:03 ` Stefan Kangas
2023-08-29 3:21 ` Stefan Monnier
2023-08-29 11:40 ` Eli Zaretskii
2023-08-29 20:13 ` Philip Kaludercic
2023-08-30 11:11 ` Eli Zaretskii
2023-08-30 11:51 ` Philip Kaludercic
2023-08-30 12:09 ` Eli Zaretskii
2023-08-30 12:25 ` Philip Kaludercic
2023-08-30 13:32 ` Eli Zaretskii
2023-08-30 19:26 ` package-autosuggest Philip Kaludercic
2023-08-31 8:34 ` package-autosuggest Eshel Yaron
2023-08-31 17:40 ` package-autosuggest Stefan Monnier
2023-08-31 18:26 ` package-autosuggest Eshel Yaron
2023-08-31 21:09 ` package-autosuggest Stefan Kangas
2023-09-01 7:01 ` package-autosuggest Eshel Yaron
2023-09-01 14:40 ` package-autosuggest Philip Kaludercic
2023-09-01 15:20 ` package-autosuggest Stefan Monnier
2023-09-01 15:47 99% ` package-autosuggest Philip Kaludercic
2023-08-30 23:13 ` package-autosuggest Stefan Monnier
2023-08-31 5:38 99% ` package-autosuggest Philip Kaludercic
2023-08-31 2:07 ` Clojure mode Richard Stallman
2023-08-31 5:51 ` Eli Zaretskii
2023-08-31 6:10 99% ` Bundling ELPA packages with Emacs Philip Kaludercic
2023-08-12 19:10 ` New Package for NonGNU-ELPA: clojure-ts-mode Philip Kaludercic
2023-08-12 19:12 ` Danny Freeman
2023-08-12 20:31 ` Philip Kaludercic
2023-08-13 5:19 ` Eli Zaretskii
2023-08-13 13:02 ` Danny Freeman
2023-08-13 13:30 ` Eli Zaretskii
2023-08-13 13:35 ` Danny Freeman
2023-08-13 14:13 ` Eli Zaretskii
2023-08-14 13:14 ` Danny Freeman
2023-08-23 12:55 ` Danny Freeman
2023-08-25 1:11 ` Clojure mode Richard Stallman
2023-08-25 7:25 ` Philip Kaludercic
2023-08-29 21:09 ` Brand new clojure support in Emacs ;-) João Távora
2023-08-30 7:17 ` Philip Kaludercic
2023-08-30 9:24 ` João Távora
2023-08-30 10:15 ` Philip Kaludercic
2023-08-30 21:47 ` João Távora
2023-08-31 6:46 ` Kévin Le Gouguec
2023-08-31 7:01 99% ` Philip Kaludercic
2023-08-26 2:05 ` Clojure mode Richard Stallman
2023-08-26 14:05 ` Dmitry Gutov
2023-08-24 16:20 ` New Package for NonGNU-ELPA: clojure-ts-mode Philip Kaludercic
2023-08-25 1:47 ` Danny Freeman
2023-08-25 7:20 99% ` Philip Kaludercic
2023-08-24 20:21 ` Stefan Kangas
2023-08-25 1:58 ` Danny Freeman
2023-08-25 5:42 ` Eli Zaretskii
2023-08-26 18:52 ` Dmitry Gutov
2023-08-26 19:05 ` Eli Zaretskii
2023-08-26 20:14 ` Philip Kaludercic
2023-08-26 21:41 ` Dmitry Gutov
2023-08-27 4:38 ` Eli Zaretskii
2023-08-27 11:07 ` Dmitry Gutov
2023-08-27 11:46 ` Eli Zaretskii
2023-08-27 12:59 ` Dmitry Gutov
2023-08-27 13:09 ` Eli Zaretskii
2023-08-27 18:13 ` Dmitry Gutov
2023-08-27 18:46 ` Eli Zaretskii
2023-08-27 21:15 ` Choice of bug tracker Dmitry Gutov
2023-08-28 11:45 ` Eli Zaretskii
2023-08-28 21:16 ` Dmitry Gutov
2023-08-29 11:26 ` Eli Zaretskii
2023-08-29 11:58 99% ` Philip Kaludercic
2023-08-26 14:07 ` New Package for NonGNU-ELPA: clojure-ts-mode Dmitry Gutov
2023-08-26 14:31 ` Stefan Kangas
2023-08-26 21:27 ` Dmitry Gutov
2023-08-31 11:21 ` Ihor Radchenko
2023-08-31 11:35 99% ` Philip Kaludercic
2023-08-31 12:38 ` Ihor Radchenko
2023-08-31 13:06 ` Po Lu
2023-08-31 13:12 ` Ihor Radchenko
2023-08-31 13:22 ` Po Lu
2023-08-31 13:36 ` Ihor Radchenko
2023-08-31 13:41 ` Po Lu
2023-08-31 13:49 ` Ihor Radchenko
2023-08-31 18:17 ` Philip Kaludercic
2023-09-01 10:14 ` Monthy emacs-devel digest, similar to "This month in Org" (was: New Package for NonGNU-ELPA: clojure-ts-mode) Ihor Radchenko
2023-09-01 13:50 ` Monthy emacs-devel digest, similar to "This month in Org" Philip Kaludercic
2023-09-02 19:17 99% ` Philip Kaludercic
2023-09-02 21:44 ` Yuan Fu
2023-09-03 5:47 99% ` Philip Kaludercic
2023-09-03 8:03 ` Ihor Radchenko
2023-09-03 8:43 ` Eli Zaretskii
2023-09-03 9:39 99% ` Philip Kaludercic
2023-09-03 8:53 ` Ihor Radchenko
2023-09-03 9:40 99% ` Philip Kaludercic
2023-08-12 19:26 ` New Package for NonGNU-ELPA: clojure-ts-mode Eli Zaretskii
2023-08-12 20:22 ` Philip Kaludercic
2023-08-13 5:16 ` Eli Zaretskii
2023-08-13 6:23 99% ` 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 ` Philip Kaludercic
2024-04-28 12:56 ` Roman Scherer
2024-04-29 6:09 ` 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 ` 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
2023-11-29 12:16 a mode for algol 68 Omar Polo
2023-11-30 7:10 99% ` Philip Kaludercic
2023-11-30 10:19 ` Omar Polo
2023-11-30 11:33 ` Jose E. Marchesi
2023-11-30 13:01 99% ` Philip Kaludercic
2023-11-13 20:31 [ELPA] New Package: p4_16-mode Soham Gumaste
2023-11-17 7:36 ` Philip Kaludercic
2023-11-17 20:11 ` Soham Gumaste
2023-11-18 21:12 99% ` Philip Kaludercic
2023-11-18 21:20 ` Soham Gumaste
2023-11-18 21:51 99% ` Philip Kaludercic
2023-11-18 22:18 ` Soham Gumaste
2023-11-20 18:09 ` Soham Gumaste
2023-11-23 5:57 99% ` Philip Kaludercic
2023-09-04 18:15 another stats problem, example solution [stats.el] Emanuel Berg
2023-09-04 20:08 ` John Haman
2023-09-05 3:42 ` Emanuel Berg
2023-09-05 11:53 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
2023-09-04 20:34 [ELPA] New package: breadcrumb.el João Távora
2023-09-05 15:58 ` Jonas Bernoulli
2023-09-05 16:41 ` João Távora
2023-09-05 16:55 ` Philip Kaludercic
2023-09-05 17:00 ` João Távora
2023-09-05 17:39 99% ` Philip Kaludercic
2023-09-04 20:47 ` Philip Kaludercic
2023-09-04 20:56 ` João Távora
2023-09-05 6:21 ` Philip Kaludercic
2023-09-05 9:16 ` João Távora
2023-09-05 10:16 99% ` Philip Kaludercic
2024-04-18 22:45 Objed maintenance Amy Grinn
2024-04-22 7:22 ` Philip Kaludercic
2024-04-25 12:38 ` Amy Grinn
2024-04-27 10:06 99% ` Philip Kaludercic
2023-10-31 10:34 [ELPA] New package: dired-duplicates Harald Judt
2023-10-31 12:21 ` Philip Kaludercic
2023-10-31 21:05 ` Harald Judt
2023-11-01 2:14 ` Michael Heerdegen
2023-11-01 15:16 ` [External] : " Drew Adams
2023-11-01 16:33 99% ` Philip Kaludercic
2023-11-01 11:32 ` Philip Kaludercic
2023-11-01 20:04 ` Harald Judt
2023-11-01 21:29 ` Philip Kaludercic
2023-11-02 8:44 ` Harald Judt
2023-11-03 8:19 99% ` Philip Kaludercic
2023-11-03 20:19 ` Harald Judt
2023-11-04 15:27 99% ` Philip Kaludercic
2023-11-06 9:33 ` Harald Judt
2023-11-10 8:37 99% ` Philip Kaludercic
2023-11-10 10:02 ` Harald Judt
2023-11-23 6:12 99% ` Philip Kaludercic
2024-01-26 10:36 [ELPA] New package: activities Adam Porter
2024-01-29 19:50 ` Adam Porter
2024-01-30 7:16 99% ` Philip Kaludercic
2024-04-20 1:07 [ELPA] New package: colorful-mode Elijah G
2024-04-22 7:51 ` Philip Kaludercic
2024-04-23 2:49 ` Elijah G
2024-04-27 10:12 ` Philip Kaludercic
2024-04-27 16:44 ` Elijah G
2024-04-27 21:12 99% ` Philip Kaludercic
2024-04-28 3:55 [NonGNU ELPA] Add package gptel Karthik Chikmagalur
2024-04-28 8:21 ` Philip Kaludercic
2024-04-28 16:50 ` Karthik Chikmagalur
2024-04-29 6:18 ` Philip Kaludercic
2024-04-29 6:52 ` Karthik Chikmagalur
2024-04-29 7:29 ` Philip Kaludercic
2024-04-29 17:21 ` Karthik Chikmagalur
2024-04-29 18:21 ` Philip Kaludercic
2024-04-29 20:11 ` Karthik Chikmagalur
2024-05-01 12:02 99% ` Philip Kaludercic
2024-02-25 7:28 [ELPA] New package: listen Adam Porter
2024-02-25 11:43 ` Philip Kaludercic
2024-02-25 13:14 ` Adam Porter
2024-02-25 13:45 ` Philip Kaludercic
2024-02-26 4:15 ` Adam Porter
2024-02-26 17:17 ` [External] : " Drew Adams
2024-02-26 17:21 99% ` Philip Kaludercic
2024-02-26 8:09 ` Philip Kaludercic
2024-02-26 8:50 ` Adam Porter
2024-02-26 10:13 ` Philip Kaludercic
2024-02-26 14:51 ` Adam Porter
2024-02-26 15:26 99% ` Philip Kaludercic
2023-11-12 19:32 [ELPA] New package: SachaC-news Christian
2023-11-17 7:28 ` Philip Kaludercic
2023-11-18 20:30 ` Christian
2023-11-18 21:10 99% ` Philip Kaludercic
2023-07-31 1:58 Suggestion for package.el: atomic package-upgrade dqs7cp2e
2023-07-31 6:45 ` Philip Kaludercic
2023-07-31 13:13 ` Tegar Syahputra
2023-08-01 7:32 99% ` Philip Kaludercic
2023-09-24 1:03 [PATCH] Improve find-sibling-rules option type Paul W. Rankin via Emacs development discussions.
2023-09-24 8:34 99% ` Philip Kaludercic
2023-06-07 3:18 question regarding my emacs package ram
2023-06-11 18:49 ` João Távora
2023-06-11 19:08 ` ram via Emacs development discussions.
2023-06-12 8:45 99% ` Philip Kaludercic
2023-06-07 15:53 ` Philip Kaludercic
2023-06-07 18:04 99% ` Philip Kaludercic
2023-06-07 19:45 ` ram
2023-06-07 19:48 99% ` Philip Kaludercic
2024-03-03 6:13 Reliability of melpa Pedro Andres Aranda Gutierrez
2024-03-03 7:19 99% ` Philip Kaludercic
2024-01-16 8:18 Auto-suggesting Packages Philip Kaludercic
2024-01-16 12:58 ` Eli Zaretskii
2024-01-16 15:06 ` Philip Kaludercic
2024-01-16 15:13 ` Eli Zaretskii
2024-01-16 16:18 99% ` Philip Kaludercic
2024-01-16 9:01 ` Stephen Berman
2024-01-16 9:26 99% ` Philip Kaludercic
2024-01-22 5:55 Patch for ansi-osc.el Brad Howes
2024-01-22 7:21 99% ` Philip Kaludercic
2024-02-19 14:51 Adding Flycheck to NonGNU ELPA Bozhidar Batsov
2024-02-19 17:44 ` Philip Kaludercic
2024-02-19 18:08 ` Bozhidar Batsov
2024-02-19 18:53 ` Philip Kaludercic
2024-02-19 19:32 ` Dmitry Gutov
2024-02-19 22:32 ` joakim
2024-02-20 11:48 ` Philip Kaludercic
2024-02-20 20:04 ` Dmitry Gutov
2024-02-21 14:38 ` Dmitry Gutov
2024-02-21 17:01 99% ` Philip Kaludercic
2024-02-21 17:38 ` Dmitry Gutov
2024-02-21 18:05 99% ` Philip Kaludercic
2023-12-27 18:28 man broken? T.V Raman
2023-12-27 18:56 ` Michael Albinus
2023-12-28 9:48 ` 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 ` Philip Kaludercic
2024-01-03 15:48 99% ` Philip Kaludercic
2023-05-23 16:47 Inferred function types in the *Help* buffer Payas Relekar
2023-05-23 18:51 99% ` Philip Kaludercic
2023-06-16 11:20 Android port of Emacs Eli Zaretskii
2023-06-16 15:16 ` Dr. Arne Babenhauserheide
2023-06-16 15:32 ` Eli Zaretskii
2023-06-17 0:49 ` Konstantin Kharlamov
2023-06-17 6:20 ` Eli Zaretskii
2023-06-17 13:34 ` Konstantin Kharlamov
2023-06-17 16:47 ` Alfred M. Szmidt
2023-06-17 18:11 ` contributing to Emacs Konstantin Kharlamov
2023-06-17 18:36 ` Alfred M. Szmidt
2023-06-17 19:39 ` Konstantin Kharlamov
2023-06-17 21:00 ` Alfred M. Szmidt
2023-06-17 21:10 ` Konstantin Kharlamov
2023-06-17 21:19 ` Alfred M. Szmidt
2023-06-17 21:26 ` Konstantin Kharlamov
2023-06-17 22:25 ` Alfred M. Szmidt
2023-06-17 22:39 ` Konstantin Kharlamov
2023-06-18 5:20 ` Eli Zaretskii
2023-06-18 8:53 ` Konstantin Kharlamov
2023-06-18 10:00 99% ` Philip Kaludercic
2023-06-18 10:15 ` Konstantin Kharlamov
2023-06-18 10:22 ` Philip Kaludercic
2023-06-23 6:49 ` Sean Whitton
2023-06-24 15:37 99% ` Philip Kaludercic
2024-01-07 12:34 Ada-mode to be abandoned? Philip Kaludercic
2024-01-07 15:21 ` Dmitry
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 ` Philip Kaludercic
2024-01-08 12:47 ` Eli Zaretskii
2024-01-09 19:27 ` Philip Kaludercic
2024-01-09 19:54 ` Eli Zaretskii
2024-01-09 20:21 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-02-05 20:12 nongnu ELPA and slime Peter Hull
2024-02-06 8:10 ` Philip Kaludercic
2024-02-06 9:38 ` Colin Baxter
2024-02-06 10:07 99% ` Philip Kaludercic
2023-04-14 17:03 [ELPA] New package: emacs-gc-stats Ihor Radchenko
2023-06-09 9:14 ` Ihor Radchenko
2023-06-09 10:17 ` Eli Zaretskii
2023-06-09 16:19 ` Stefan Monnier
2023-06-10 10:13 ` Ihor Radchenko
2023-06-10 16:33 ` Stefan Monnier
2023-06-11 9:15 ` Ihor Radchenko
2023-06-11 9:12 99% ` Philip Kaludercic
2023-09-05 16:55 Proposal to add Popper to ELPA Karthik Chikmagalur
2023-09-05 17:38 ` Philip Kaludercic
2023-09-05 20:27 ` Mauro Aranda
2023-09-05 20:49 ` Karthik Chikmagalur
2023-09-05 21:05 ` Mauro Aranda
2023-09-06 17:13 ` Karthik Chikmagalur
2023-09-08 17:25 99% ` Philip Kaludercic
2023-12-16 13:02 [ELPA] Use :release-branch for plz.el Adam Porter
2023-12-17 8:38 99% ` Philip Kaludercic
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-10-16 7:12 ` Stefan Kangas
2023-10-16 9:15 99% ` Philip Kaludercic
2023-05-11 13:22 [ELPA] New package: dict Eshel Yaron
2023-05-11 13:59 ` Eli Zaretskii
2023-05-11 14:14 ` Philip Kaludercic
2023-05-11 17:56 ` Eshel Yaron
2023-05-11 18:29 ` Philip Kaludercic
2023-05-12 13:17 ` Eshel Yaron
2023-05-12 13:44 ` Eli Zaretskii
2023-05-14 6:41 ` Eshel Yaron
2023-05-14 9:14 ` Eli Zaretskii
2023-05-15 18:50 ` Eshel Yaron
2023-05-18 12:59 99% ` Philip Kaludercic
2023-05-18 15:37 ` Eshel Yaron
2023-05-18 15:58 99% ` Philip Kaludercic
2023-05-18 10:59 ` Eli Zaretskii
2023-05-18 12:21 ` Eshel Yaron
2023-05-18 14:09 ` Eli Zaretskii
2023-05-18 15:51 ` Eshel Yaron
2023-05-18 15:58 ` Eli Zaretskii
2023-05-19 8:34 ` Eshel Yaron
2023-05-20 16:49 ` Philip Kaludercic
2023-05-20 18:27 ` Eshel Yaron
2023-05-20 19:11 99% ` Philip Kaludercic
2023-05-21 6:52 ` Eshel Yaron
2023-05-25 9:52 ` Eshel Yaron
2023-05-25 19:10 99% ` Philip Kaludercic
2023-10-04 7:24 [NonGNU ELPA] Package suggestion: yeetube Thanos Apollo
2023-10-04 13:14 ` Daniel Martín
2023-10-04 13:33 ` Thanos Apollo
2023-10-04 15:22 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-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
2023-08-02 7:56 Adding adoc-mode (a major mode for working with AsciiDoc) to NonGNU ELPA Bozhidar Batsov
2023-08-02 12:49 99% ` Philip Kaludercic
2023-08-07 23:54 [NonGNU ELPA] New package: llm Andrew Hyatt
2023-08-09 3:47 ` Richard Stallman
2023-08-09 4:37 ` Andrew Hyatt
2023-08-13 1:43 ` Richard Stallman
2023-08-27 1:07 ` Andrew Hyatt
2023-08-27 13:11 99% ` Philip Kaludercic
2023-08-27 18:36 ` Jim Porter
2023-09-04 1:27 ` Richard Stallman
2023-09-04 5:18 ` Andrew Hyatt
2023-09-07 1:21 ` Richard Stallman
2023-09-12 4:54 ` Andrew Hyatt
2023-09-12 9:57 99% ` Philip Kaludercic
2023-11-16 3:04 Instead of pcase Richard Stallman
2023-11-16 7:37 ` Philip Kaludercic
2023-11-16 17:18 ` T.V Raman
2023-11-16 17:44 ` Michael Heerdegen
2023-11-16 18:16 99% ` Philip Kaludercic
2023-05-11 5:23 [NonGNU ELPA] New package: devil Payas Relekar
2023-05-11 6:33 ` Eli Zaretskii
2023-05-12 16:19 ` Jim Porter
2023-05-13 22:30 ` Richard Stallman
2023-05-14 4:29 ` Naming guidelines for ELPA packages (was: Re: [NonGNU ELPA] New package: devil) Jim Porter
2023-05-14 7:47 ` Naming guidelines for ELPA packages Philip Kaludercic
2023-05-14 19:23 ` Jim Porter
2023-05-14 19:33 ` Philip Kaludercic
2023-05-19 3:49 ` Jim Porter
2023-05-19 4:33 ` Akib Azmain Turja
2023-05-20 16:51 99% ` Philip Kaludercic
2023-05-13 7:10 ` [NonGNU ELPA] New package: devil Philip Kaludercic
2023-05-13 9:05 ` Susam Pal
2023-05-17 13:30 ` João Távora
2023-05-17 14:06 99% ` Philip Kaludercic
2023-10-04 8:31 [package-vc] Consider cleaning up files from install process Joseph Turner
2023-10-04 15:23 99% ` Philip Kaludercic
2023-10-04 18:54 ` Joseph Turner
2023-10-06 9:00 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 ` 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
2023-10-12 23:53 Updating *Completions* as you type sbaugh
2023-10-13 6:34 ` Juri Linkov
2023-10-20 9:35 99% ` zcomplete 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-03-31 11:05 Hundreds of ELPA packages updated today? Romain Francoise
2024-03-31 11:49 99% ` Philip Kaludercic
2024-02-08 19:55 [DISCUSSION] "quick-help" popup for org-columns (column view) Sławomir Grochowski
2024-03-20 14:08 ` Ihor Radchenko
2024-04-06 20:41 ` Sławomir Grochowski
2024-04-07 5:57 ` Eli Zaretskii
2024-04-08 7:38 ` Sławomir Grochowski
2024-04-08 8:24 ` Philip Kaludercic
2024-04-08 19:13 ` Sławomir Grochowski
2024-04-10 8:26 ` Philip Kaludercic
2024-04-10 20:42 ` Sławomir Grochowski
2024-04-11 6:37 99% ` Philip Kaludercic
2024-04-13 8:37 99% ` Philip Kaludercic
2023-09-03 22:18 [IDEA] Add function clean-buffer Joseph Turner
2023-09-04 16:02 99% ` Philip Kaludercic
2023-08-17 13:58 Preferred approach to inclusion of data in ELPA package Hugo Thunnissen
2023-08-17 21:14 ` Philip Kaludercic
2023-08-19 11:26 ` Hugo Thunnissen
2023-08-19 15:51 ` Philip Kaludercic
2023-08-20 19:24 ` Hugo Thunnissen
2023-08-20 20:42 99% ` Philip Kaludercic
2023-08-29 8:41 ` Hugo Thunnissen
2023-08-30 19:27 99% ` Philip Kaludercic
2023-07-05 13:01 Use radix-tree for string arrays Yuchen Pei
2023-07-05 16:47 99% ` Philip Kaludercic
2023-07-05 22:15 ` Yuchen Pei
2023-07-06 18:50 99% ` Philip Kaludercic
2020-08-23 11:46 Disambiguate modeline character for UTF-8? Ulrich Mueller
2023-07-05 13:44 ` Eli Zaretskii
2023-07-05 21:50 ` Ulrich Mueller
2023-07-06 12:31 ` Po Lu
2023-07-06 13:08 ` Ulrich Mueller
2023-07-06 17:37 ` Paul Eggert
2023-07-06 18:44 ` Ulrich Müller
2023-07-06 19:01 ` Eli Zaretskii
2023-07-06 19:31 ` Ulrich Mueller
2023-07-07 5:18 ` Eli Zaretskii
2023-07-07 5:48 ` Ulrich Müller
2023-07-08 8:49 ` Eli Zaretskii
2023-07-08 15:27 ` Basil Contovounesios
2023-07-08 15:38 ` Eli Zaretskii
2023-07-09 9:22 ` Lisp reader syntax and bootstrap (was: Re: Disambiguate modeline character for UTF-8?) Ulrich Mueller
2023-07-09 9:57 ` Lisp reader syntax and bootstrap Po Lu
2023-07-13 2:04 ` Richard Stallman
2023-07-13 4:27 ` Po Lu
2023-07-13 22:07 ` Paul Eggert
2023-07-15 2:10 ` Richard Stallman
2023-07-15 2:38 ` Po Lu
2023-07-15 5:18 99% ` Philip Kaludercic
2023-06-04 14:15 [NonGNU Elpa] New package: electric-french Ruijie Yu via Emacs development discussions.
2023-06-05 8:34 99% ` Philip Kaludercic
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:56 99% ` Philip Kaludercic
2024-02-04 8:42 ` Rahguzar
2024-02-07 3:11 ` Richard Stallman
2024-02-07 8:29 ` Philip Kaludercic
2024-02-10 3:55 ` Richard Stallman
2024-02-10 9:11 ` Rahguzar
2024-02-10 15:49 99% ` Philip Kaludercic
2023-10-30 7:17 ELPA submission: plz-see Augusto Stoffel
2023-10-30 11:56 ` Eli Zaretskii
2023-10-31 8:43 ` Philip Kaludercic
2023-10-31 20:17 ` Augusto Stoffel
2023-11-01 9:14 99% ` Philip Kaludercic
2023-11-01 18:36 ` Augusto Stoffel
2023-11-01 20:21 ` brickviking
2023-11-03 2:31 ` Richard Stallman
2023-11-03 6:32 ` brickviking
2023-11-03 7:50 99% ` 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
2022-09-25 2:52 Org mode and Emacs Payas Relekar
2022-09-25 6:35 ` Bastien
2022-09-25 8:01 ` Eli Zaretskii
2022-09-25 19:47 ` Tim Cross
2022-09-26 6:12 ` Bastien
2022-09-26 6:35 ` Ihor Radchenko
2022-09-26 6:57 ` Bastien
2023-08-18 17:09 ` Ihor Radchenko
2023-08-18 18:31 ` Eli Zaretskii
2023-08-18 18:49 ` Ihor Radchenko
2023-08-18 19:11 ` Eli Zaretskii
2023-08-18 19:31 ` Ihor Radchenko
2023-08-19 5:51 ` Eli Zaretskii
2023-08-19 9:04 ` Ihor Radchenko
2023-08-19 9:26 ` Eli Zaretskii
2023-08-21 1:12 ` Richard Stallman
2023-08-21 7:56 99% ` Philip Kaludercic
2024-01-16 0:38 [ELPA] New package devicetree-ts-mode Aleksandr Vityazev
2024-01-16 6:18 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 ` Philip Kaludercic
2024-02-27 16:13 ` Jay Kamat
2024-02-27 17:21 ` Stefan Monnier
2024-02-27 17:27 ` Philip Kaludercic
2024-02-27 17:49 ` Stefan Monnier
2024-02-27 18:42 99% ` Philip Kaludercic
2023-08-03 9:29 Question about eval and compile-command Eshel Yaron
2023-08-03 9:56 ` Eli Zaretskii
2023-08-03 15:14 ` Stefan Monnier
2023-08-03 20:02 99% ` Philip Kaludercic
2023-08-26 6:56 [NonGNU ELPA] New package: hyperdrive (repost) Joseph Turner
2023-08-26 11:55 99% ` Philip Kaludercic
2023-08-26 19:19 ` Joseph Turner
2023-08-26 20:27 ` [NonGNU ELPA] New package: hyperdrive (repast) Philip Kaludercic
2023-08-29 4:04 ` Joseph Turner
2023-08-29 11:56 99% ` Philip Kaludercic
2023-11-18 10:43 [ELPA] New package: ert-font-lock Vladimir Kazanov
2023-11-18 11:18 ` Philip Kaludercic
2023-11-18 12:07 ` Po Lu
2023-11-18 12:43 ` Eli Zaretskii
2023-11-18 13:14 ` Po Lu
2023-11-18 14:47 99% ` Philip Kaludercic
2023-12-26 13:44 Manuals for GNU ELPA packages Kjartan Óli Ágústsson
2023-12-26 17:17 ` Philip Kaludercic
2023-12-27 8:41 ` Michael Albinus
2023-12-27 13:47 99% ` Philip Kaludercic
2024-02-26 10:49 ` Philip Kaludercic
2024-02-26 15:03 ` Stefan Monnier
2024-02-26 15:27 99% ` Philip Kaludercic
2023-07-09 10:20 [ELPA] New package: ob-asymptote.el Jarmo Hurri
2023-07-17 12:51 ` Jarmo Hurri
2023-07-27 7:19 ` Jarmo Hurri
2023-09-04 1:27 ` Stefan Kangas
2023-09-05 17:12 99% ` Philip Kaludercic
2023-09-05 20:15 ` Stefan Kangas
2023-09-06 9:37 ` Stefan Kangas
2023-09-06 22:08 ` Philip Kaludercic
2023-09-08 11:34 ` Stefan Kangas
2023-09-08 17:28 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-03-08 9:26 [ELPA] new single file package: mpdired.el Manuel Giraud via Emacs development discussions.
2024-03-08 10:25 ` Philip Kaludercic
2024-03-08 11:17 ` Manuel Giraud via Emacs development discussions.
2024-03-08 11:26 ` Philip Kaludercic
2024-03-08 12:22 ` Manuel Giraud via Emacs development discussions.
2024-03-08 13:18 ` Philip Kaludercic
2024-03-08 16:25 ` Manuel Giraud via Emacs development discussions.
2024-03-08 16:34 ` Philip Kaludercic
2024-03-08 17:06 ` Manuel Giraud via Emacs development discussions.
2024-03-08 17:29 ` 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
2023-08-28 19:37 Why shouldn't we have a #if .... #else .... #endif construct in Emacs Lisp? Alan Mackenzie
2023-08-29 12:54 99% ` Philip Kaludercic
2023-08-29 20:09 ` Stefan Kangas
2023-08-30 10:31 ` Alan Mackenzie
2023-08-30 17:36 ` Stefan Kangas
2023-08-30 18:03 ` Alan Mackenzie
2023-08-30 18:17 ` Stefan Kangas
2023-09-02 15:06 ` Alan Mackenzie
2023-09-02 19:20 99% ` Philip Kaludercic
2024-02-06 15:57 Elpa question: helping with maintainance of a package in Elpa Arthur Miller
2024-02-06 17:00 ` Philip Kaludercic
2024-02-06 17:17 ` chad
2024-02-06 17:24 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 ` cond* Philip Kaludercic
2023-12-27 4:54 ` cond* Richard Stallman
2023-12-27 14:34 99% ` cond* Philip Kaludercic
2023-10-30 7:18 ELPA submission: drepl (REPL protocol) Augusto Stoffel
2023-10-31 9:08 ` Philip Kaludercic
2023-11-07 8:20 99% ` Philip Kaludercic
2023-11-01 18:28 ` Augusto Stoffel
2023-11-01 18:38 99% ` Philip Kaludercic
2023-04-17 23:23 [ELPA] New package: calibre.el Kjartan Óli Águstsson
2023-04-18 6:05 ` Philip Kaludercic
2023-04-18 8:19 ` Kjartan Óli Águstsson
2023-05-09 12:50 ` Kjartan Óli Águstsson
2023-05-10 6:36 ` Philip Kaludercic
2023-05-10 12:34 ` Kjartan Óli Águstsson
2023-05-16 19:38 ` Philip Kaludercic
2023-05-17 15:01 ` Kjartan Óli Águstsson
2023-05-18 13:01 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
2023-07-31 18:38 [ELPA] Proposing to add express to ELPA Yuan Fu
2023-08-11 17:14 ` Yuan Fu
2023-08-11 18:14 99% ` Philip Kaludercic
2023-08-19 5:09 ` Yuan Fu
2023-08-19 9:04 99% ` Philip Kaludercic
2023-08-19 6:03 Adding refactoring capabilities to Emacs Eli Zaretskii
2023-09-07 14:39 ` João Távora
2023-09-07 16:20 ` Stefan Monnier
2023-09-07 22:18 ` João Távora
2023-09-07 22:39 ` Dmitry Gutov
2023-09-08 6:55 ` João Távora
2023-09-08 15:42 ` Stefan Monnier
2023-09-08 16:05 ` João Távora
2023-09-08 16:20 ` João Távora
2023-09-25 23:11 ` Dmitry Gutov
2023-09-26 5:36 ` Alfred M. Szmidt
2023-09-26 8:06 ` João Távora
2023-09-26 10:57 ` Dmitry Gutov
2023-09-26 11:24 ` João Távora
2023-09-26 13:38 99% ` Philip Kaludercic
2023-08-20 1:19 ` Dmitry Gutov
2023-08-20 8:44 ` Yuri Khan
2023-08-20 22:51 ` Dmitry Gutov
2023-08-29 10:53 ` João Távora
2023-08-30 0:52 ` Dmitry Gutov
2023-08-30 20:37 ` João Távora
2023-08-30 21:49 ` Dmitry Gutov
2023-09-04 17:23 ` Juri Linkov
2023-09-04 20:49 99% ` Philip Kaludercic
2023-10-24 16:29 [ELPA] Updated packages: boxy, boxy-headings, and org-real Amy Grinn
2023-10-25 6:34 99% ` Philip Kaludercic
2024-02-05 15:35 New package for NonGNU ELPA : totp-auth Vivek Das Mohapatra
2024-02-07 3:16 ` Richard Stallman
2024-02-07 8:23 99% ` Philip Kaludercic
2024-02-06 10:04 ` Philip Kaludercic
2024-02-06 10:24 ` Po Lu
2024-02-06 10:27 99% ` Philip Kaludercic
2024-05-02 19:57 Maintenance of cobol-mode.el on ELPA kristofer
2024-05-03 5:42 ` 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
2023-07-06 16:14 NonGNU ELPA: add Logview Paul Pogonyshev
2023-07-06 17:59 ` Philip Kaludercic
2023-07-06 19:47 ` Paul Pogonyshev
2023-07-07 5:21 ` Bozhidar Batsov
2023-07-13 13:34 ` Bozhidar Batsov
2023-07-13 18:35 99% ` Philip Kaludercic
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
2023-05-21 10:21 [PROPOSAL] Builder, a build system integration for Emacs BTuin
2023-05-21 12:11 99% ` Philip Kaludercic
2023-05-22 22:00 ` Richard Stallman
2023-05-23 8:36 99% ` Philip Kaludercic
2023-05-24 3:34 ` David Masterson
2023-05-24 10:26 99% ` Philip Kaludercic
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
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).