* Re: The place for the "ELPA bundling" project
@ 2023-12-19 6:45 96% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-12-19 6:45 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: emacs-devel
Dmitry Gutov <dmitry@gutov.dev> writes:
> I've tried to find the bug number, or a specific emacs-devel
> discussion, that would contain the existing knowledge and some hint of
> the current state. And failed.
>
> Could somebody give me the link I could post in public? Both to refer
> to that potential feature, and to invite people to help out.
Eli send me this <83zg27emh8.fsf@gnu.org>, or if you cannot resolve it,
here is the copied text:
--8<---------------cut here---------------start------------->8---
> From: Philip Kaludercic <philipk@posteo.net>
> Cc: rms@gnu.org, emacs-devel@gnu.org
> Date: Thu, 31 Aug 2023 06:10:17 +0000
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > 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?
That's not the only issue we need to resolve. See
https://lists.gnu.org/archive/html/emacs-devel/2020-12/msg00917.html
https://lists.gnu.org/archive/html/emacs-devel/2021-01/msg01017.html
https://lists.gnu.org/archive/html/emacs-devel/2021-01/msg01373.html
for the previous discussions, where the issues were raised and
discussed.
--8<---------------cut here---------------end--------------->8---
^ permalink raw reply [relevance 96%]
* 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: Ellama comments
@ 2023-12-17 12:06 92% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-12-17 12:06 UTC (permalink / raw)
To: Sergey Kostyaev; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 86 bytes --]
Sergey Kostyaev <sskostyaev@gmail.com> writes:
> Done.
OK, the package builds now.
[-- Attachment #2: Type: text/plain, Size: 509 bytes --]
diff --git a/elpa-packages b/elpa-packages
index 07f9e2373e..8695a87faf 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -258,6 +258,7 @@
;;(eldoc-eval :url "https://github.com/thierryvolpiatto/eldoc-eval.git")
(electric-spacing :url nil)
(elisp-benchmarks :url nil)
+ (ellama :url "https://github.com/s-kostyaev/ellama")
(emacs-gc-stats :url "https://git.sr.ht/~yantar92/emacs-gc-stats"
:ignored-files ("COPYING"))
;; FIXME: Work in progress. The copyright paperwork is ready.
[-- Attachment #3: Type: text/plain, Size: 3362 bytes --]
I would also recommend adding an .elpaignore, with these lines:
--8<---------------cut here---------------start------------->8---
.github
imgs
--8<---------------cut here---------------end--------------->8---
To avoid packaging them in the release tarball.
I'll wait a bit to see if there are any comments, and then publish the
package.
>> 14 дек. 2023 г., в 18:18, Philip Kaludercic <philipk@posteo.net> написал(а):
>>
>> The development mailing list got dropped, I've added it again.
>>
>> Sergey Kostyaev <sskostyaev@gmail.com> writes:
>>
>>> Today I finally got signed CA. What’s my next steps to move ellama to GNU Elpa?
>>
>> The first thing that you'll need to do is to update the copyright
>> string, and replace it with
>>
>> ;; Copyright (C) 2023 Free Software Foundation, Inc.
>>
>> and bump the version header.
>>
>> Unless we find any further issues, I can just add the package to
>> elpa.git and that is that.
>>
>>> I have fixed most of your comments and fix customization group
>>> soon. Spinner instead of progress-reporter because it was contribution
>>> from other person. And I like it - it has high level api. And it’s
>>> informative enough.
>>
>> OK, if you say so, it just seems like an unnecessary dependency to me,
>> that might also be a soft dependency.
>>
>>> Best Regards,
>>> Sergei Kostiaev
>>>
>>>> 3 нояб. 2023 г., в 00:24, Philip Kaludercic <philipk@posteo.net> написал(а):
>>>>
>>>> Sergey Kostyaev <sskostyaev@gmail.com> writes:
>>>>
>>>>> Hi, Philip. I'm honored. It's OK for me in general. I need to check my
>>>>> job contract about signature for GNU Elpa. And I'm in Russia now, can
>>>>> this be a problem? I need some time to investigate your comments. I
>>>>> will reply more specifically a few days later.
>>>>
>>>> I don't expect that there should be an issue wrt to Russia, but I cannot
>>>> say for sure.
>>>>
>>>>> Best regards,
>>>>> Sergey Kostyaev
>>>>>
>>>>> 2 ноября 2023 г. 11:23:04 UTC, Philip Kaludercic <philipk@posteo.net> пишет:
>>>>>>
>>>>>> Hi, I was looking into proposing the inclusion of Ellama to NonGNU ELPA
>>>>>> (or ideally GNU ELPA if you are OK with it), but I first wanted to send
>>>>>> you a few comments on the code:
>>>>>>
>>>>
>>>> Sergey Kostyaev <sskostyaev@gmail.com> writes:
>>>>
>>>>> About job contract all fine. What should I do with code by other
>>>>> contributors to move project to GNU Elpa? Are there any cheatsheets
>>>>> about it? About code comments I will reply later.
>>>>
>>>> It is necessary that all significant contributors have signed the FSF
>>>> copyright assignment (CA), but from what I see you seem to be the only one
>>>> that would qualify as such (more than 15 lines of substantial code is
>>>> the way this is usually approximated).
>>>>
>>>> Have you already signed the CA? If not, send an email to
>>>> emacs-devel@gnu.org to request the form.
>>>>
>>>>> 2 ноября 2023 г. 11:23:04 UTC, Philip Kaludercic <philipk@posteo.net> пишет:
>>>>>>
>>>>>> Hi, I was looking into proposing the inclusion of Ellama to NonGNU ELPA
>>>>>> (or ideally GNU ELPA if you are OK with it), but I first wanted to send
>>>>>> you a few comments on the code:
>>>>>>
>
--
Philip Kaludercic
^ permalink raw reply related [relevance 92%]
* Re: Making package.el talk over Tor
@ 2023-12-17 11:51 73% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-12-17 11:51 UTC (permalink / raw)
To: Richard Stallman; +Cc: akib, 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. ]]]
>
> > 185.220.101.26 - - [14/Dec/2023:13:04:00 +0100] "GET /test HTTP/1.1" 301 169 "https://amodernist.com/" "URL/Emacs Emacs/30.0.50 (PureGTK; x86_64-pc-linux-gnu)"
>
> > As you can see the User-Agent indicates that I am using Emacs, what
> > version and even my architecture. Compare that to the user agent that
> > you'd regularly encounter from an average browser:
>
> We should (1) let users specify what User-Agent to send,
That is already possible using the `url-user-agent' user option.
> and (2) maybe
> choose a different default.
1+
> Icecat, by default, identifies itself as some widely used proprietary
> browser running on Windows.
While helpful, it could also be dangerous if the server decides to send
the user content that only a widely used proprietary browser running on
Windows could process.
> > Other than the user-agent, there are certainly other bits of behaviour
> > that a malicious actor can use to track a user, such as the order in
> > which HTTP headers are transmitted, the size of chunks by which the
> > client sends and receives data and of course what requests aren't being
> > sent (e.g. due to a lack of Javascript in EWW).
>
> We could work on making Emacs-based browsing more similar to the most
> common browsers, in such aspects of visible behavior.
>
> > and of course what requests aren't being
> > sent (e.g. due to a lack of Javascript in EWW).
>
> Compareed with the harm done by _running_ the page's Javascript,
> giving evidence of not running Javascript is arguably a far lesser
> evil.
The way I see this, this is a security/privacy vs freedom issue. If you
really want to blend in, you have to behave the way most people do.
> That said, one important method for preventing sites from effectively
> profiling you is to connect to them through Tor. In fact, connecting
> directly enables OTHERS that observe your network traffic to figure
> out what you are talking to!
Tor hides your IP address, in which sense it acts like a trusted VPN
service, but I am just trying to emphasise that (in general) just using
Tor as a transport layer can give users a false sense of security.
> That is why I want to connect to the Emacs package repo via Tor.
> I am not worried about being profiled by the Emacs package repo!
>
> More generally, if all that distinguishes you in the actual
> interaction with a site is that you don't run the Javascript, and you
> connect through Tor, whatever site you are talking to will have
> trouble distinguishing you from other users that don't run the
> Javascript.
True, but considering how infrequent this is on a global scale, "no
Javascript" still holds a lot of information.
> > That being said: All of this doesn't matter that much for package.el,
> > since most people are accessing it via Emacs.
>
> I agree. However, these issues may have some real importance for the case
> of using EWW to look at pages _other than_ the Emacs package repo.
Right, that is where my concerns from above apply.
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. ]]]
>
> > If you have a Tor daemon running on your system, it should provide a
> > SOCKS proxy by default,
>
> I believe it does that.
>
> meaning that you can configure every package
> > that uses url.el to go through this proxy (unless I have misunderstood
> > something):
>
> Maybe that is possible. But I know very little about sockets or how
> to use them. I would appreciate precise advice about what I should do
> to tell package.el to connect using Tor.
That was the code you quoted below with `url-gateway-method'.
> You sent this code
>
> (let ((conn
> (open-network-stream
> "test" (current-buffer) "gnu.org" "http"
> :type 'shell
> :shell-command "torsocks nc %s %p")))
> (process-send-string conn "GET / HTTP/1.0\r\n\r\n"))
>
> but I don't think that is a solution ready to use. It looks like a
> proposed approach for designing that solution.
>
> Also, the end of your message MAY mean that this approach is not
> applicable to package.el.
Yes, this was just a proof of concept integrating torsocks into a
network connection open from within Emacs.
> > If you have a Tor daemon running on your system, it should provide a
> > SOCKS proxy by default, meaning that you can configure every package
> > that uses url.el to go through this proxy (unless I have misunderstood
> > something):
>
> > --8<---------------cut here---------------start------------->8---
> > (setq url-gateway-method 'socks
> > socks-server '("Tor" "localhost" 9050 5))
> > --8<---------------cut here---------------end--------------->8---
>
> > That being said, while testing I noticed that when connecting to a
> > server I have access to, I always receive two requests, one from a Tor
> > exit node and one from my current IP address. Unless I missed something
> > obvious, that might be a bug.
>
> I await word about further progress.
I will try and look into if I am mis-configuring something, and
otherwise report a bug.
> When I know enough to be able to do it, I will add a feature to
> package.el for a user option to tell it to go through Tor always.
Stefan Kangas <stefankangas@gmail.com> writes:
> Richard Stallman <rms@gnu.org> writes:
>
>> > 185.220.101.26 - - [14/Dec/2023:13:04:00 +0100] "GET /test
>> > HTTP/1.1" 301 169 "https://amodernist.com/" "URL/Emacs
>> > Emacs/30.0.50 (PureGTK; x86_64-pc-linux-gnu)"
>>
>> > As you can see the User-Agent indicates that I am using Emacs, what
>> > version and even my architecture. Compare that to the user agent that
>> > you'd regularly encounter from an average browser:
>>
>> We should (1) let users specify what User-Agent to send, and (2) maybe
>> choose a different default.
>>
>> Icecat, by default, identifies itself as some widely used proprietary
>> browser running on Windows.
>
> Should we bump the default to 'paranoid'? Do what icecat does?
That wouldn't send any Use-Agent header at all, which is still
fingerprintable. Richard mentioned that Icecat uses a false user agent like
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.3
but that would have to be updated on a regular basis, to keep up with
whatever is being used. That being said, I don't believe that this is
enough, if we take the threat model into account that a Tor user is
operating under. In their case, it probably is the best to just use the
Tor Browser.
> Does the remote ever need to know if we're using X11 or PureGTK?
> I think they don't, and we should never add that information, in any
> configuration.
Yes, it might make sense to just add `os' to `url-privacy-level'.
>> > Other than the user-agent, there are certainly other bits of behaviour
>> > that a malicious actor can use to track a user, such as the order in
>> > which HTTP headers are transmitted, the size of chunks by which the
>> > client sends and receives data and of course what requests aren't being
>> > sent (e.g. due to a lack of Javascript in EWW).
>>
>> We could work on making Emacs-based browsing more similar to the most
>> common browsers, in such aspects of visible behavior.
>
> If you are very concerned about your privacy, it's probably better to
> browse the web using the Tor web browser and eschew Emacs altogether.
>
> How about telling users about this in the EWW manual?
1+
--
Philip Kaludercic
^ permalink raw reply [relevance 73%]
* 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: Making package.el talk over Tor
@ 2023-12-14 12:41 79% ` Philip Kaludercic
1 sibling, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-12-14 12:41 UTC (permalink / raw)
To: Richard Stallman; +Cc: akib, emacs-devel
Richard Stallman <rms@gnu.org> writes:
> > because one will continue to leak fingerprintable
> > metadata (specially inside of Emacs)
>
> Could you give me an example of what you mean?
As mention in my other message, I was testing what my web server was
logging when accessing the server via Tor, and this was the log entry:
185.220.101.26 - - [14/Dec/2023:13:04:00 +0100] "GET /test HTTP/1.1" 301 169 "https://amodernist.com/" "URL/Emacs Emacs/30.0.50 (PureGTK; x86_64-pc-linux-gnu)"
As you can see the User-Agent indicates that I am using Emacs, what
version and even my architecture. Compare that to the user agent that
you'd regularly encounter from an average browser:
31.10.139.153 - - [14/Dec/2023:00:18:33 +0100] "GET / HTTP/1.1" 200 10585 "-" "Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Mobile Safari/537.36"
This can be remedied by setting the `url-privacy-level' user option to
'paranoid, but in that case you are still identifiable because there is
no user agent, which carries some information.
Other than the user-agent, there are certainly other bits of behaviour
that a malicious actor can use to track a user, such as the order in
which HTTP headers are transmitted, the size of chunks by which the
client sends and receives data and of course what requests aren't being
sent (e.g. due to a lack of Javascript in EWW).
The EFF has more information on the topic here:
https://coveryourtracks.eff.org/learn.
That being said: All of this doesn't matter that much for package.el,
since most people are accessing it via Emacs.
^ permalink raw reply [relevance 79%]
* Re: Making package.el talk over Tor
@ 2023-12-14 12:25 85% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-12-14 12:25 UTC (permalink / raw)
To: Richard Stallman; +Cc: Eli Zaretskii, akib, 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 sounds like a way to make the connection by running a shell
> > command. Maybe you could arrange for using this facility to do what
> > you want?
>
> I have no idea. I don't know how to make a program talk to anything
> over the net, either with Tor or without.
I tried out Eli's suggestion, and it seems to work:
(let ((conn
(open-network-stream
"test" (current-buffer) "gnu.org" "http"
:type 'shell
:shell-command "torsocks nc %s %p")))
(process-send-string conn "GET / HTTP/1.0\r\n\r\n"))
>
> I think all Emacs features to do something over the internet should
> give users a way to say "go through Tor". (For most applicaions I
> think a global variable is the preferable way to specify this.)
If you have a Tor daemon running on your system, it should provide a
SOCKS proxy by default, meaning that you can configure every package
that uses url.el to go through this proxy (unless I have misunderstood
something):
--8<---------------cut here---------------start------------->8---
(setq url-gateway-method 'socks
socks-server '("Tor" "localhost" 9050 5))
--8<---------------cut here---------------end--------------->8---
That being said, while testing I noticed that when connecting to a
server I have access to, I always receive two requests, one from a Tor
exit node and one from my current IP address. Unless I missed something
obvious, that might be a bug.
> Can someone who knows how to do that please implement it for Emacs package.el?
FWIW As package.el doesn't directly use any low level networking, so the
:shell trick wouldn't be something that could be easily implemented.
^ permalink raw reply [relevance 85%]
* Re: Ellama comments
[not found] ` <6B0DECA2-8E81-495E-99AC-A9F81B43C05E@gmail.com>
@ 2023-12-14 11:18 97% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-12-14 11:18 UTC (permalink / raw)
To: Sergey Kostyaev; +Cc: emacs-devel
The development mailing list got dropped, I've added it again.
Sergey Kostyaev <sskostyaev@gmail.com> writes:
> Today I finally got signed CA. What’s my next steps to move ellama to GNU Elpa?
The first thing that you'll need to do is to update the copyright
string, and replace it with
;; Copyright (C) 2023 Free Software Foundation, Inc.
and bump the version header.
Unless we find any further issues, I can just add the package to
elpa.git and that is that.
> I have fixed most of your comments and fix customization group
> soon. Spinner instead of progress-reporter because it was contribution
> from other person. And I like it - it has high level api. And it’s
> informative enough.
OK, if you say so, it just seems like an unnecessary dependency to me,
that might also be a soft dependency.
> Best Regards,
> Sergei Kostiaev
>
>> 3 нояб. 2023 г., в 00:24, Philip Kaludercic <philipk@posteo.net> написал(а):
>>
>> Sergey Kostyaev <sskostyaev@gmail.com> writes:
>>
>>> Hi, Philip. I'm honored. It's OK for me in general. I need to check my
>>> job contract about signature for GNU Elpa. And I'm in Russia now, can
>>> this be a problem? I need some time to investigate your comments. I
>>> will reply more specifically a few days later.
>>
>> I don't expect that there should be an issue wrt to Russia, but I cannot
>> say for sure.
>>
>>> Best regards,
>>> Sergey Kostyaev
>>>
>>> 2 ноября 2023 г. 11:23:04 UTC, Philip Kaludercic <philipk@posteo.net> пишет:
>>>>
>>>> Hi, I was looking into proposing the inclusion of Ellama to NonGNU ELPA
>>>> (or ideally GNU ELPA if you are OK with it), but I first wanted to send
>>>> you a few comments on the code:
>>>>
>>
>> Sergey Kostyaev <sskostyaev@gmail.com> writes:
>>
>>> About job contract all fine. What should I do with code by other
>>> contributors to move project to GNU Elpa? Are there any cheatsheets
>>> about it? About code comments I will reply later.
>>
>> It is necessary that all significant contributors have signed the FSF
>> copyright assignment (CA), but from what I see you seem to be the only one
>> that would qualify as such (more than 15 lines of substantial code is
>> the way this is usually approximated).
>>
>> Have you already signed the CA? If not, send an email to
>> emacs-devel@gnu.org to request the form.
>>
>>> 2 ноября 2023 г. 11:23:04 UTC, Philip Kaludercic <philipk@posteo.net> пишет:
>>>>
>>>> Hi, I was looking into proposing the inclusion of Ellama to NonGNU ELPA
>>>> (or ideally GNU ELPA if you are OK with it), but I first wanted to send
>>>> you a few comments on the code:
>>>>
^ permalink raw reply [relevance 97%]
* Re: [ELPA] New package: dape
@ 2023-12-05 10:59 98% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-12-05 10:59 UTC (permalink / raw)
To: João Távora
Cc: Daniel Pettersson, Dmitry Gutov, John Yates, Krister Schuchardt,
Adam Porter, emacs-devel
João Távora <joaotavora@gmail.com> writes:
> On Tue, Dec 5, 2023 at 8:41 AM Philip Kaludercic <philipk@posteo.net> wrote:
>
>> I have resolved the issue directly with Daniel. The package has been
>> added to GNU ELPA.
>>
>> Depending on how it is received, it would be nice to see the package be
>> added to the core in some form or another.
>
> Yes to this. I'm working to make it as well received as possible.
>
> In fact, I've been working on dape.el (slightly late unfortunately,
> but hope to pick up on that soon) and these enhancements need
> `jsonrpc.el` changes too, so I've been working on a branch of Emacs
> where dape.el lives alongside eglot.el in core. Of course this was
> just for practical reasons, I'll take it out if there when I'm done,
> unless someone tells me to _not_ take it out ;-).
I guess that depends on what model of development Daniel would prefer.
>> By my book, the naming issue
>> could be resolved by adding a `start-dap' command (a `start-lsp' alias
>> for Eglot would also be nice).
>
> There is no real naming issue, but I'm not opposed to adding those
> aliases if M-x dape and M-x eglot both stay)
Hence the "in my book", I know there is disagreement there, it is just
that my main objection "Arbitrary names are difficult to memorise and
communicate" would be sufficiently resolved by adding these kinds of
aliases.
^ permalink raw reply [relevance 98%]
* Re: [ELPA] New package: dape
2023-11-23 6:10 91% ` Philip Kaludercic
@ 2023-12-05 8:41 95% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-12-05 8:41 UTC (permalink / raw)
To: Daniel Pettersson
Cc: João Távora, Dmitry Gutov, John Yates,
Krister Schuchardt, Adam Porter, emacs-devel
Philip Kaludercic <philipk@posteo.net> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> 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.
>
> It seems that the name is here to stay, so I'd go ahead and add the
> package to GNU ELPA. It just seems that you forgot to add a copyright
> notice to the package header. Could you apply a change along these
> lines:
>
> diff --git a/dape.el b/dape.el
> index f5de1cd..949049d 100644
> --- a/dape.el
> +++ b/dape.el
> @@ -1,5 +1,7 @@
> ;;; dape.el --- Debug Adapter Protocol for Emacs -*- lexical-binding: t -*-
>
> +;; Copyright (C) 2023 Free Software Foundation, Inc.
> +
> ;; Author: Daniel Pettersson
> ;; Created: 2023
> ;; License: GPL-3.0-or-later
>
>
> Followed by a commit (or in the same one) that bumps the "Version"
> header, indicating a new package release?
I have resolved the issue directly with Daniel. The package has been
added to GNU ELPA.
Depending on how it is received, it would be nice to see the package be
added to the core in some form or another. By my book, the naming issue
could be resolved by adding a `start-dap' command (a `start-lsp' alias
for Eglot would also be nice).
^ permalink raw reply [relevance 95%]
* Re: Instead of pcase
@ 2023-12-02 9:02 76% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-12-02 9:02 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Richard Stallman, Lynn Winebarger, dmitry, emacs-devel
Andreas Schwab <schwab@linux-m68k.org> writes:
> On Dez 01 2023, Richard Stallman wrote:
>
>> confusing. I know what dotted pairs mean, but I was not sure what
>> they meant in pcase patterns.
>
> They don't mean anything. It's pure lisp syntax.
Right, the doc-string mentions this as well:
--8<---------------cut here---------------start------------->8---
-- `QPAT
Backquote-style pcase patterns: `QPAT
QPAT can take the following forms:
(QPAT1 . QPAT2) matches if QPAT1 matches the car and QPAT2 the cdr.
[...]
--8<---------------cut here---------------end--------------->8---
Just like cons-cells are the "real" constituents of a list, so
pattern-matching on a list "really" means pattern matching on
cons-cells. I believe this is the kind of behaviour that would arise
naturally, whenever someone tries to re-implement this themselves.
As has been said many times already in this thread: All of this seems to
point in the direction that the main issue people are having is that of
documentation, and part of the problem might be that pcase is generating
its doc-string dynamically, which -- while cool -- might not present the
information in the most understandable way.
Another question I meant to raise, and forgive me if I missed it
somewhere in the remaining discussions, is those who find themselves
confused by `pcase': Do you have experience with programming languages
that heavily rely on pattern matching and/or unification (ML, Haskell,
Prolog, ...)? Myself having experience with this kind of programming,
all I had to do to understand `pcase' was to translate the existing
abstract notion I had to the syntax that `pcase' provides. While I can
imagine that one is more prone to be confused, if trying to learn both
the syntax and the point of `pcase', assuming that this kind of
articulating oneself is not natural.
^ permalink raw reply [relevance 76%]
* 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: 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: [ELPA] New package: SachaC-news
@ 2023-11-25 22:50 93% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-11-25 22:50 UTC (permalink / raw)
To: Christian; +Cc: emacs-devel
Christian <cnngimenez@disroot.org> writes:
> Hi Philip!
>
> Sorry, I misunderstood your idea. What would you like to
> discuss specifically?
>
> I will try to pinpoint some things you suggested that is nice
> to talk about. The diff has many modifications, and I find it
> difficult to see the exact places you want to discuss. In
> fact, most of them are changes that I think are better in the
> way you wrote.
>
> Below are extracts from the diff and my comments. Tell me if
> this method is a good idea to talk about them.
It is entirely fine; I'll just be responding to the parts of the message
where I have something constructive to add.
> 4)
>> (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")
>
> The str variable was used to insert the last new string. The
> portion of the Org-mode text with the last title.
No, that was my bad, I must have replaced the variable with a constant
while testing and forgot to change it back.
> But now I changed this function to support diferent formats (txt,
> html, org, etc.). This code changed in the current version.
Would it be worth checking out the code again?
> 5)
>> @@ -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."
>
> Mmm... to my eyes it seems that it does the same but it may be
> something I do not know... or maybe I am missing something?
> Can I ask you why did you change it? Is the new code a
> more convenient or accepted way to do what is intended?
>
> I wonder if perhaps is a parameter or something I do not know
> what it does...
> Maybe is efficiency: the data is directly printed to the buffer
> without transforming into a string?
Yes; The point of these two changes is to avoid generating a string,
that is immediately discarded (less GC), and to avoid generating a
message when writing the buffer contents to disk.
> 6)
>> @@ -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
> Yes, that could be a good idea... However, it should not be a
> large string, because it will be displayed on the
> minibuffer. Mmm... maybe it is already large...
>
> What do you think? should the string be formatted in a
> temporary buffer?
It just seemed like it would be more readable, than having a multi-line
format-string.
> This string is shown when using M-x
> sachac-news-show-update-time when an update has been executed
> before.
Perhaps `display-message-or-buffer' could be of interest?
--
Philip Kaludercic
^ permalink raw reply [relevance 93%]
* Re: Don't see PATCH on bug-gnu-emacs
@ 2023-11-24 20:57 98% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-11-24 20:57 UTC (permalink / raw)
To: Niall Dooley; +Cc: emacs-devel
Niall Dooley <dooleyn@gmail.com> writes:
> I submitted a simple patch email titled as follows over two hours ago.
>
> [PATCH] eglot: Add ruff-lsp as an alternative python server
>
> This is my first patch so likely I did something wrong.
>
> I did not attach a patch file but rather sent it inline in the mail.
> Reading CONTRIBUTE more carefully I now see an attachment is preferred.
> Is this why it does not appear on the list? Should I send the mail
> again with the attachment or reply to my original mail?
Both should appear on the mailing list, the issue with inline patches
depending on your MUA is that that might be misrendered. I couldn't
find anything by your name on bug-gnu-emacs@gnu.org, so I guess
something else went wrong. Try resending your message -- even if you
make a mistake, it is nothing to worry about, it happens all the time
and nobody will get annoyed or anything like that.
> Thanks for your time.
^ permalink raw reply [relevance 98%]
* Re: [ELPA] Add theme-buffet package
@ 2023-11-24 18:11 72% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-11-24 18:11 UTC (permalink / raw)
To: Bruno Boal; +Cc: emacs-devel, info
[-- Attachment #1: Type: text/plain, Size: 995 bytes --]
Bruno Boal <egomet@bboal.com> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Bruno Boal <egomet@bboal.com> writes:
>>
>>> Hello everyone,
>>>
>>> I would like you to consider including my package in the GNU ELPA.
>>> I've just filled out the copyright assignment form, and in the meantime
>>> I'm sending the proposed changes below for your consideration.
>>
>> Here are a few comments in form of a diff (this is not a patch that you
>> should apply, but just some suggestions, hints and ideas that can be
>> discussed):
>>
>
> [...]
>
> Hello again Philip,
>
> I took a look at your constructive review, made some changes accordingly
> and now it looks good to me.
> Thanks in advance for any additional feedback.
I have added the package to GNU ELPA. You can now change the "This file
is NOT part of GNU Emacs." to "This file is part of GNU Emacs.".
I just noticed that there were a few instances of `pcase' that might
seem to be better suited by using `pcase-exhaustive':
[-- Attachment #2: Type: text/plain, Size: 1829 bytes --]
diff --git a/theme-buffet.el b/theme-buffet.el
index 00120d307e..2b88b81c8d 100644
--- a/theme-buffet.el
+++ b/theme-buffet.el
@@ -205,7 +205,7 @@ Prefilled with Emacs default themes as an example to be changed by the user."
(defun theme-buffet--selected-menu ()
"Return property list based on `theme-buffet-menu' value."
- (pcase theme-buffet-menu
+ (pcase-exhaustive theme-buffet-menu
('built-in theme-buffet--built-in)
('modus-ef theme-buffet--modus-ef)
('end-user theme-buffet--end-user)))
@@ -387,11 +387,9 @@ UNITS is an unquoted symbol, mins or hours and refers to timer of the same
naming."
(let ((fn-name (intern (format "theme-buffet-timer-%s" units)))
factor max-num)
- (pcase units
+ (pcase-exhaustive units
('mins (setq factor 60 max-num 180))
- ('hours (setq factor 3600 max-num 12))
- (_ (user-error
- "Bad `units' arg on `theme-buffet--define-timer %s'" units)))
+ ('hours (setq factor 3600 max-num 12)))
`(defun ,fn-name (number)
,(format "Set interactively the timer for NUMBER of %s.
When NUMBER is 0, the timer is cancelled. Maximum value is %s" units max-num)
@@ -425,11 +423,10 @@ Theme-Buffet uses both Modus and Ef themes, mixed and matched for a maximum
\"Wow!!\" factor of pleasure and professionalism. At least in this developer's
opinion.")
(doc-end-user "End user selected themes")
- (docstring (pcase menu
+ (docstring (pcase-exhaustive menu
('built-in doc-built-in)
('modus-ef doc-modus-ef)
- ('end-user doc-end-user)
- (_ "This is not correct!"))))
+ ('end-user doc-end-user))))
`(defun ,(intern (format "theme-buffet-%s" menu)) ()
,docstring
(interactive)
[-- Attachment #3: Type: text/plain, Size: 177 bytes --]
Depending on how extensible you want to make the package, it might also
be interesting to investigate the usage of generic functions and
methods.
> All the best,
> Bruno Boal
^ permalink raw reply related [relevance 72%]
* 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: [ELPA] New package: dape
2023-11-04 10:00 99% ` Philip Kaludercic
@ 2023-11-23 6:10 91% ` Philip Kaludercic
2023-12-05 8:41 95% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-11-23 6:10 UTC (permalink / raw)
To: Daniel Pettersson
Cc: João Távora, Dmitry Gutov, John Yates,
Krister Schuchardt, Adam Porter, emacs-devel
[-- Attachment #1: Type: text/plain, Size: 850 bytes --]
Philip Kaludercic <philipk@posteo.net> writes:
> 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.
It seems that the name is here to stay, so I'd go ahead and add the
package to GNU ELPA. It just seems that you forgot to add a copyright
notice to the package header. Could you apply a change along these
lines:
[-- Attachment #2: Type: text/plain, Size: 319 bytes --]
diff --git a/dape.el b/dape.el
index f5de1cd..949049d 100644
--- a/dape.el
+++ b/dape.el
@@ -1,5 +1,7 @@
;;; dape.el --- Debug Adapter Protocol for Emacs -*- lexical-binding: t -*-
+;; Copyright (C) 2023 Free Software Foundation, Inc.
+
;; Author: Daniel Pettersson
;; Created: 2023
;; License: GPL-3.0-or-later
[-- Attachment #3: Type: text/plain, Size: 111 bytes --]
Followed by a commit (or in the same one) that bumps the "Version"
header, indicating a new package release?
^ permalink raw reply related [relevance 91%]
* 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] Add theme-buffet package
@ 2023-11-20 19:05 21% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-11-20 19:05 UTC (permalink / raw)
To: Bruno Boal; +Cc: emacs-devel, info
[-- Attachment #1: Type: text/plain, Size: 422 bytes --]
Bruno Boal <egomet@bboal.com> writes:
> Hello everyone,
>
> I would like you to consider including my package in the GNU ELPA.
> I've just filled out the copyright assignment form, and in the meantime
> I'm sending the proposed changes below for your consideration.
Here are a few comments in form of a diff (this is not a patch that you
should apply, but just some suggestions, hints and ideas that can be
discussed):
[-- Attachment #2: Type: text/plain, Size: 17397 bytes --]
diff --git a/theme-buffet.el b/theme-buffet.el
index 08934cd..e65cc0d 100644
--- a/theme-buffet.el
+++ b/theme-buffet.el
@@ -7,7 +7,10 @@
;; Maintainer: Theme-Buffet Development <~bboal/general-issues@lists.sr.ht>
;; URL: https://git.sr.ht/~bboal/theme-buffet
;; Version: 0.0.0
-;; Package-Requires: ((emacs "29.1"))
+;; Package-Requires: ((emacs "26.1"))
+
+;; According to package-lint, the newest function you depend on is
+;; from Emacs 29 is `take', If you want to depend on Compat, you could lower the
;; This file is NOT part of GNU Emacs.
@@ -29,7 +32,7 @@
;; Theme-Buffet lets the user specify different time periods of the day and for
;; each period, a list of preferred themes to be randomly loaded accordingly.
;; To install you just have to clone the repo from the url, add the path to the
-;; 'load-path variable and then require the library. Here's an example, for
+;; 'load-path variable and then require the library. Here's an example, for
;; those who still love the Emacs 28 or earlier way of doing things:
;;
;; # In the terminal
@@ -44,7 +47,7 @@
;; (package-vc-install "https://git.sr.ht/~bboal/theme-buffet")
;;
;;
-;; There are two templates preconfigured available for usage. One enabled by
+;; There are two templates preconfigured available for usage. One enabled by
;; default, with the standard themes that come with vanilla Emacs; the other
;; more fancier, can be easily enabled by evaluating the following:
;;
@@ -52,39 +55,38 @@
;;
;; The binding above will set the themes to be either Modus or Ef, authored by
;; Protesilaos Stavrou <https://git.sr.ht/~protesilaos>, distributed across six
-;; periods of the day (night, twilight, morning, day, afternoon and evening). The
+;; periods of the day (night, twilight, morning, day, afternoon and evening). The
;; library will require the aforementioned package, installing if
-;; necessary. Finally to start using Theme-Buffet, evaluate:
+;; necessary. Finally to start using Theme-Buffet, evaluate:
;;
;; (theme-buffet-mode 1)
;;
;;
;; Following the appanage way of Emacs, both the names and number of themes and
-;; time periods can be freely changed while mantaining the same structure. There
+;; time periods can be freely changed while mantaining the same structure. There
;; is also a time-offset that can be set by the user to match a specific
-;; time-zone/personal preference. E.g
+;; time-zone/personal preference. E.g
;;
;; (setq theme-buffet-time-offset 2)
;;
-;; All this can be achieved by tweaking `theme-buffet-end-user'. For
+;; All this can be achieved by tweaking `theme-buffet-end-user'. For
;; inspiration, take a look at `theme-buffet--modus-ef' which is used when
;; setting `theme-buffet-menu' to 'modus-ef like demonstrated above.
;;
;;
;; Disclaimer from Bruno Boal to the reader: This package was produced during
;; my learning sessions with Protesilaos "Prot" Stavrou and improved as
-;; homework. Most of the credit goes to him, the mistakes you may find are my
-;; own. Personally, despite the disadvantages and advantages of not being a
+;; homework. Most of the credit goes to him, the mistakes you may find are my
+;; own. Personally, despite the disadvantages and advantages of not being a
;; professional programmer, it is essential for me to always have fun and
-;; enjoyment during learning and programming. In this respect, mission
-;; accomplished, a big "thank you!" to my mentor. Also, keep in mind at least
+;; enjoyment during learning and programming. In this respect, mission
+;; accomplished, a big "thank you!" to my mentor. Also, keep in mind at least
;; two things - the fact that this package, like many others before it, has its
;; genesis in a collective effort, with didatic purposes and personal use in
;; mind, but also that future improvements could and should come from people
;; like you, a user of free software.
;;
;; Happy hacking!
-;;
;;; Code:
@@ -92,22 +94,22 @@
(defgroup theme-buffet nil
"Time based theme switcher.
Assortment of preference based themes available for consumption according to
-the time of the day. A true theme feast for the eyes..."
+the time of the day. A true theme feast for the eyes..."
:group 'faces)
-
-(defun theme-buffet--get-themes(&optional plist-usage)
+(defun theme-buffet--get-themes (&optional plist-usage)
"Get themes from default Emacs build directory and `custom-theme-load-path'.
Return list for usage in `theme-buffet-menu' type options if PLIST-USAGE is
non-nil."
+ ;; Why not `custom-available-themes'?
(let* ((default (expand-file-name "themes/" data-directory))
(custom (butlast custom-theme-load-path))
(themes-dirs (cons default custom))
- (themes (flatten-tree
- (mapcar (lambda (f)
- (if (symbolp f) (setq f (symbol-value f)))
- (directory-files f nil ".*-theme\\.el\\'"))
- themes-dirs))))
+ (themes (mapcan (lambda (f)
+ (directory-files
+ (if (symbolp f) (symbol-value f) f)
+ nil ".*-theme\\.el\\'"))
+ themes-dirs)))
(mapcar (lambda (theme)
(let ((symbol-list (intern
(string-trim-right theme "-theme\\.el"))))
@@ -116,8 +118,6 @@ non-nil."
(defvar theme-buffet--const-themes (theme-buffet--get-themes t))
-
-
(defconst theme-buffet--built-in
'(:night (wheatgrass manoj-dark modus-vivendi)
:morning (adwaita whiteboard leuven modus-operandi tango dichromacy tsdh-light)
@@ -171,20 +171,20 @@ For those who just don't have the time and want the best.")
:afternoon (leuven-dark tango-dark tsdh-dark misterioso)
:evening (deeper-blue wombat))
"Associate day periods with list of themes.
-Each association is of the form `:KEYWORD (THEMES)' where :KEYWORD is one among
-:dark, :twilight, :dawn, etc, and (THEMES), a list of existent themes. Prefilled
-with Emacs default themes as an example to change by the user."
+Each association is of the form `:KEYWORD (THEMES)' where
+:KEYWORD is one among :dark, :twilight, :dawn, etc, and (THEMES),
+a list of existent themes. Prefilled with Emacs default themes
+as an example to change by the user."
:type `(plist
:options
- (((const :tag "Darkness of the night" :night)
- (repeat (choice symbol ,@theme-buffet--const-themes)))
- ((const :tag "Bright sun is up" :morning)
- (repeat (choice symbol ,@theme-buffet--const-themes)))
- ((const :tag "Perhaps a clouded afternoon" :afternoon)
- (repeat (choice symbol ,@theme-buffet--const-themes)))
- ((const :tag "Close to the sunset" :evening)
- (repeat (choice symbol ,@theme-buffet--const-themes))))))
-
+ (((const :tag "Darkness of the night" :night)
+ (repeat (choice symbol ,@theme-buffet--const-themes)))
+ ((const :tag "Bright sun is up" :morning)
+ (repeat (choice symbol ,@theme-buffet--const-themes)))
+ ((const :tag "Perhaps a clouded afternoon" :afternoon)
+ (repeat (choice symbol ,@theme-buffet--const-themes)))
+ ((const :tag "Close to the sunset" :evening)
+ (repeat (choice symbol ,@theme-buffet--const-themes))))))
(defcustom theme-buffet-menu 'built-in
"Define which property list to use when selecting the theme list."
@@ -192,49 +192,37 @@ with Emacs default themes as an example to change by the user."
(const :tag "Modus and Ef themes" modus-ef)
(const :tag "User specified themes" end-user)))
-
(defun theme-buffet--selected-menu ()
"Return property list based on given MENU."
- (cond
- ((eq theme-buffet-menu 'built-in)
- theme-buffet--built-in)
- ((eq theme-buffet-menu 'modus-ef)
- theme-buffet--modus-ef)
- ((eq theme-buffet-menu 'end-user)
- theme-buffet--end-user)
- (t
- nil)))
-
+ (pcase-exhaustive theme-buffet-menu
+ ('built-in theme-buffet--built-in)
+ ('modus-ef theme-buffet--modus-ef)
+ ('end-user theme-buffet--end-user)))
-(defun theme-buffet--hours-secs(hours)
+(defun theme-buffet--hours-secs (hours)
"Number of seconds in HOURS."
(* hours 60 60))
-
(defconst theme-buffet--secs-in-day
(theme-buffet--hours-secs 24)
"Number of seconds in a day.")
-
-(defun theme-buffet--keywords()
+(defun theme-buffet--keywords ()
"Get the name of the keywords defining the day periods."
(let ((selected-menu (theme-buffet--selected-menu)))
(if (plistp selected-menu)
(seq-filter #'keywordp selected-menu)
- (user-error "The Theme-Buffet Chef cannot work with your supplied themes. Check `theme-buffet-menu'"))))
-
+ (user-error "The Theme-Buffet Chef cannot work with your supplied themes. Check `theme-buffet-menu'"))))
-(defun theme-buffet--periods()
+(defun theme-buffet--periods ()
"Get the number of keywords that define the day periods."
(length (theme-buffet--keywords)))
-
-(defun theme-buffet--interval()
+(defun theme-buffet--interval ()
"Get the number of seconds that each given time period should remain active."
(/ theme-buffet--secs-in-day (theme-buffet--periods)))
-
-(defun theme-buffet--get-time()
+(defun theme-buffet--get-time ()
"Get the `current-time' in seconds."
(let ((time-smh (take 3 (decode-time)))
seconds)
@@ -242,8 +230,7 @@ with Emacs default themes as an example to change by the user."
(setq seconds (cons (pop time-smh) seconds)
time-smh (mapcar (lambda (n) (* 60 n))
time-smh)))
- (apply #'+ seconds)))
-
+ (seq-reduce #'+ seconds 0)))
(defun theme-buffet--natnum-from-to (start end &optional step)
"Create a list for applying in defcustom's type choice customization.
@@ -254,14 +241,12 @@ END-STEP) (const END))"
(list 'const x))
(number-sequence start end step)))
-
(defcustom theme-buffet-time-offset 0
"Added time in HOURS (integer number) to shift the day periods.
Used for compensate winter/summer times or specific weather situations."
:type `(choice ,@(theme-buffet--natnum-from-to -12 12)))
-
-(defun theme-buffet--get-offset()
+(defun theme-buffet--get-offset ()
"Error checking for `theme-buffet-time-offset' variable.
Has to be an integer number and no greater than 12h in absolute value"
(cond
@@ -273,21 +258,18 @@ Has to be an integer number and no greater than 12h in absolute value"
(t
(theme-buffet--hours-secs theme-buffet-time-offset))))
-
-(defun theme-buffet--current-period()
+(defun theme-buffet--current-period ()
"Get the current period reference the number of keywords in `theme-buffet'."
(let ((offset (mod (+ (theme-buffet--get-time)
(theme-buffet--get-offset))
theme-buffet--secs-in-day)))
(ceiling offset (theme-buffet--interval))))
-
-(defun theme-buffet--get-period-keyword()
+(defun theme-buffet--get-period-keyword ()
"Get the keyword of the current period as specified in `theme-buffet'."
(nth (1- (theme-buffet--current-period)) (theme-buffet--keywords)))
-
-(defun theme-buffet--reload-theme(chosen-theme &optional added-message)
+(defun theme-buffet--reload-theme (chosen-theme &optional added-message)
"Load CHOSEN-THEME after disabling the current one.
An additional ADDED-MESSAGE can be appended to the original string for added
information."
@@ -298,20 +280,18 @@ information."
(load-theme chosen-theme :no-confirm)
(message "%s `%s'" message chosen-theme)))
-
-(defun theme-buffet--get-theme-list(period)
+(defun theme-buffet--get-theme-list (period)
"Get list of themes of PERIOD, excluding the current if more are available."
(when-let ((selected-menu (theme-buffet--selected-menu))
(theme-list (plist-get selected-menu period)))
(or (remq (car custom-enabled-themes) theme-list)
theme-list)))
-
-(defun theme-buffet--load-random(period)
+(defun theme-buffet--load-random (period)
"Load random theme according to PERIOD.
Omit current theme if it's not the only pertaining to the list of the
-corresponding period. Being this the case, the same theme shall be served.
+corresponding period. Being this the case, the same theme shall be served.
An error message will appear if the theme is not available to load through
`load-theme'."
@@ -322,12 +302,10 @@ An error message will appear if the theme is not available to load through
(user-error "Theme-Buffet Chef says `%s' is not known or installed!"
chosen-theme)))
-
-
(defvar theme-buffet-theme-history nil
"Theme-Buffet period history.")
-(defun theme-buffet--theme-prompt()
+(defun theme-buffet--theme-prompt ()
"Prompt the user the theme to choose for the present period."
(let ((prompt "From current period choose a theme: ")
(collection (theme-buffet--get-theme-list
@@ -336,19 +314,17 @@ An error message will appear if the theme is not available to load through
(completing-read prompt collection nil t nil history-var)))
;;;###autoload
-(defun theme-buffet-a-la-carte()
+(defun theme-buffet-a-la-carte ()
"Prompt user for theme according to the current period of the day."
(declare (interactive-only t))
(interactive)
(let ((chosen-theme (intern (theme-buffet--theme-prompt))))
(theme-buffet--reload-theme chosen-theme "as per your desires. Enjoy..." )))
-
-
(defvar theme-buffet-period-history nil
"Theme-Buffet period history.")
-(defun theme-buffet--period-prompt()
+(defun theme-buffet--period-prompt ()
"Prompt user for the day period from the list of periods."
(let ((prompt "Choose a period of the day: ")
(collection (theme-buffet--keywords))
@@ -356,28 +332,24 @@ An error message will appear if the theme is not available to load through
(completing-read prompt collection nil t nil history-var)))
;;;###autoload
-(defun theme-buffet-order-other-period()
+(defun theme-buffet-order-other-period ()
"Interactively load a random theme from the current day period."
(declare (interactive-only t))
(interactive)
(let ((period (intern (theme-buffet--period-prompt))))
(theme-buffet--load-random period)))
-
;;;###autoload
-(defun theme-buffet-anything-goes()
+(defun theme-buffet-anything-goes ()
"Interactively load an existing random theme."
(declare (interactive-only t))
(interactive)
(theme-buffet--reload-theme (seq-random-elt (theme-buffet--get-themes))
"as a suprise"))
-
-
(defvar theme-buffet-user-timers-history nil
"Theme-Buffet user timers history.")
-
;;;; Period timer
(defvar theme-buffet-timer-periods nil
"Timer that calls Theme-Buffet's Chef into the kitchen.")
@@ -390,14 +362,19 @@ An error message will appear if the theme is not available to load through
(defvar theme-buffet-timer-mins nil
"Timer that calls another Theme-Buffet's Sous-Chef into the kitchen.")
-
-(defun theme-buffet--free-timer(timer-obj)
+(defun theme-buffet--free-timer (timer-obj)
"Cancel and set to nil the timer TIMER-OBJ."
(when-let (((boundp timer-obj))
(obj (symbol-value timer-obj)))
(cancel-timer obj)
(set timer-obj nil)))
+;; I am not too thrilled about this section. It would be nice if
+;; instead of generating a macro you could use construct a lambda
+;; expression that you bind to the intended symbol using `defalias'.
+;; A yet simpler approach would be to define a generic, internal
+;; function that written-out functions would directly invoke, instead
+;; of manually writing autoload cookies.
(defmacro theme-buffet--define-timer(units)
"Define interactive functions to set timer in UNITS.
@@ -431,14 +408,14 @@ naming."
(theme-buffet--get-period-keyword)))
(message "Theme-Buffet Sous-Chef is rushing into the kitchen...")))))))
+
+
;;;###autoload (autoload 'theme-buffet-timer-mins "theme-buffet")
(theme-buffet--define-timer mins) ; (theme-buffet-timer-mins n)
;;;###autoload (autoload 'theme-buffet-timer-hours "theme-buffet")
(theme-buffet--define-timer hours) ; (theme-buffet-timer-hours n)
-
-
-(defmacro theme-buffet--define-menu-defuns(menu)
+(defmacro theme-buffet--define-menu-defuns (menu)
"Define interactive functions to choose property list with themes to use.
The timer is clean, the chosen MENU is set with it's corresponding keywords."
(let* ((doc-built-in "Built-in Emacs themes. If you like minimalism and standard suits your needs.")
@@ -470,17 +447,13 @@ opinion.")
;;;###autoload (autoload 'theme-buffet-end-user "theme-buffet")
(theme-buffet--define-menu-defuns end-user) ; (theme-buffet-end-user)
-
-
;;;###autoload
(define-minor-mode theme-buffet-mode
"Theme-Buffet serves your preferred themes according to the time of day.
-You eyes will thank you. Or not...
+You eyes will thank you. Or not...
The preference for the themes is specified in the `theme-buffet-menu'"
- :init-value nil
:global t
- :keymap nil
(if theme-buffet-mode
;; 2023-11-20 FIXME => The `unless' below is because `theme-buffet-mode' is
;; called every time the timer runs without an explanation.
[-- Attachment #3: Type: text/plain, Size: 908 bytes --]
>
> diff --git a/elpa-packages b/elpa-packages
> index 608d8a353b..de5e15df48 100644
> --- a/elpa-packages
> +++ b/elpa-packages
> @@ -683,6 +683,8 @@
> :news "CHANGELOG.org"
> :ignored-files ("LICENSE"))
> (test-simple :url "https://github.com/rocky/emacs-test-simple")
> + (theme-buffet :url "https://git.sr.ht/~bboal/theme-buffet"
> + :readme "README.md")
Are you sure you want this, the contents of your README appear to be
identical to your "Commentary" section (something I don't recommend in
general, I see a README as something that interests people who have
checked out your repository, while the Commentary should describe the
intention and the entry-points of your package).
> (timerfunctions :url nil)
> (tiny :url "https://github.com/abo-abo/tiny")
> (tmr :url "https://git.sr.ht/~protesilaos/tmr"
>
>
> Let me know what you think.
>
> Best regards,
> Bruno Boal
^ permalink raw reply related [relevance 21%]
* 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: [External] : Turning on savehist-mode by default
@ 2023-11-18 21:42 70% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-11-18 21:42 UTC (permalink / raw)
To: Drew Adams; +Cc: sbaugh@catern.com, emacs-devel@gnu.org
Drew Adams <drew.adams@oracle.com> writes:
>> > There are a zillion minor modes that many
>> > users find useful to turn on by default.
>> > It doesn't follow that `emacs -Q' should
>> > turn on any of them by default.
>>
>> If something is done by (practically) everyone,
>
> Is it?
Given that my sentence was a hypothetical, I cannot answer this question
since the term "something" cannot be unambiguously instantiated as to be
answered concretely.
>> especially when it is something that (practically)
>> all beginners would be interested in,
>
> How is that known?
It is not known, otherwise there wouldn't really be a discussion. Our
knowledge can only approximate reality through experience and talking
with different kinds of Emacs users.
Taking the example of savehist-mode, then my experience, which takes
different kinds of users, of different experience levels, people I have
met online and in-person, appears to indicate that this is a popular and
useful feature.
>> I wouldn't dismiss the proposal to enable it by default.
>
> I don't dismiss it.
So you don't oppose enabling savehist-mode by default?
>> The issue is that beginners neither know how to do it, nor
>> what all the options are that they might be interested in.
>
> And yet it's "done by (practically) everyone"?
Let us say, "(practically) everyone" who manages to stay along, by
finding the right options to create a comfortable and productive
environment for themselves. There are certainly many beginners that
never change this user option; but I suspect that these are also the
ones that never get to taking a look at any user options, because they
give up too soon.
> ___
>
> Let's enable `delete-selection-mode' by default.
>
> It took decades to get `transient-mark-mode' ON
> by default. `delete-selection-mode' completes
> that job. It welcomes new users with the same
> type-to-replace behavior they're used to outside
> Emacs (everywhere).
>
> Persists nothing. Is easy for anyone not who
> doesn't want it ON to turn OFF.
One has to keep in mind that there are a lot of people who use Emacs,
and are familiar with the "feel" of the default key bindings or at least
some subset of these, without having much of an understanding of how to
do things or what is going on. These are users that should nevertheless
be respected -- hence my point that enabling a feature has to take the
workflow of people into account, for whom a change would break an
expectation.
Note that I am *not* saying that the goal should be to accommodate
newcomers (following whatever current trends may be) at any cost,
especially when this comes at the expense of long-term users.
To make this argument with savehist-mode, one would have to make the
use-case believable, that someone expects the history of mini-buffer
input to not persist between sessions. I think that is a claim that it
a lot harder to justify, than that inserting a key while a selection is
active, replaces the selection.
--
Philip Kaludercic
^ permalink raw reply [relevance 70%]
* 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: SachaC-news
@ 2023-11-18 21:10 99% ` Philip Kaludercic
0 siblings, 1 reply; 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: [External] : Turning on savehist-mode by default
@ 2023-11-18 18:19 81% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-11-18 18:19 UTC (permalink / raw)
To: Drew Adams; +Cc: sbaugh@catern.com, emacs-devel@gnu.org
Drew Adams <drew.adams@oracle.com> writes:
>> savehist-mode is a useful mode which is turned on by many Emacs
>> users. It matches the default behavior of programs like bash and
>> vim, which save command history by default. I suggest that we
>> should find some way to enable savehist by default.
>
> Why? It's trivial to turn it on. As you
> say, many users (moi aussi) do so.
>
> There are a zillion minor modes that many
> users find useful to turn on by default.
> It doesn't follow that `emacs -Q' should
> turn on any of them by default.
If something is done by (practically) everyone, especially when it is
something that (practically) all beginners would be interested in, I
wouldn't dismiss the proposal to enable it by default. How many
features satisfy this condition shouldn't matter. After all, there are
already a number of features that are enabled by default, like
show-paren-mode, that individually are easy to enable, if you know how
to do it. The issue is that beginners neither know how to do it, nor
what all the options are that they might be interested in.
IMO the more important question when considering to enable a feature
OOTB, is if it will inconvenience any existing users. I don't think
there should be any issues with savehist-mode, but I might not know of
some issue? Been using it myself as well for a while.
On a related topic, I have been running a configuration generator that
has been mentioned here on the list for a while now
(https://emacs.amodernist.com/), that could provide opt-in participation
in statistics of what features people are interested in. That might
help ground matters like these in somewhat more empirical data, or least
a different perspective.
--
Philip Kaludercic
^ permalink raw reply [relevance 81%]
* 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: 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: [ELPA] New package: ert-font-lock
@ 2023-11-18 11:18 61% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-11-18 11:18 UTC (permalink / raw)
To: Vladimir Kazanov; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 606 bytes --]
Vladimir Kazanov <vekazanov@gmail.com> writes:
> Hi all,
>
> I want to propose a new package to be included in ELPA. ert-font-lock
> (ERT Font Lock) is an extension to the standard ERT unit testing tool
> that makes it possible to write font-locking tests using a
> comment-based syntax. The syntax itself is based on the Tree-sitter
> unit testing system
> (https://tree-sitter.github.io/tree-sitter/syntax-highlighting#unit-testing).
>
> Find the package along with a test suite and a README here:
> https://github.com/vkazanov/ert-font-lock
Here are a few comments from reading over the source code:
[-- Attachment #2: Type: text/plain, Size: 3441 bytes --]
diff --git a/ert-font-lock.el b/ert-font-lock.el
index 7b8df01..6a6593f 100644
--- a/ert-font-lock.el
+++ b/ert-font-lock.el
@@ -6,7 +6,7 @@
;; Keywords: lisp, test
;; URL: https://github.com/vkazanov/ert-font-lock
;; Version: 0.1.0
-;; Package-Requires: ((emacs "29.1"))
+;; Package-Requires: ((emacs "28.1"))
;; This program is free software; you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
@@ -61,7 +61,7 @@
"Validate if MODE is a valid major mode."
(unless (functionp mode)
(user-error "Invalid major mode: %s. Please specify a valid major mode for
-syntax highlighting tests" mode)))
+ syntax highlighting tests" mode)))
(defmacro ert-font-lock-deftest (name mode test-string &optional docstring)
@@ -69,6 +69,7 @@ syntax highlighting tests" mode)))
TEST-STRING is the string to test, MODE is the major mode, and
DOCSTRING is a docstring to use for the test."
(declare (indent 2) (debug t) (doc-string 4))
+ ;; Or would it be possible to define a function that calls `ert-set-test'?
`(ert-deftest ,name ()
,@(when docstring `(,docstring))
(ert-font-lock--validate-major-mode ',mode)
@@ -79,7 +80,6 @@ DOCSTRING is a docstring to use for the test."
(let ((tests (ert-font-lock--parse-comments)))
(ert-font-lock--check-faces tests)))))
-
(defmacro ert-font-lock-deftest-file (name mode file &optional docstring)
"Define an ERT test NAME for font-lock syntax highlighting.
FILE is the path to a file in ert resource dir with test cases,
@@ -91,23 +91,24 @@ the test."
(ert-font-lock--validate-major-mode ',mode)
(ert-font-lock-test-file (ert-resource-file ,file) ',mode)))
-
(defun ert-font-lock--line-comment-p ()
"Return t if the current line is a comment-only line."
+ (syntax-ppss)
(save-excursion
(beginning-of-line)
(skip-syntax-forward " ")
- ;; skip empty lines
- (unless (eolp)
- (or
- ;; try the most convenient approach
- (looking-at "\\s<")
- ;; a bit smarter
- (and comment-start (looking-at (regexp-quote comment-start)))
- (and comment-start-skip (looking-at comment-start-skip))
- ;; hardcoded
- (and (derived-mode-p 'c-mode 'c++-mode 'java-mode)
- (looking-at-p "//"))))))
+ (or
+ ;; skip empty lines
+ (eolp)
+ ;; try the most convenient approach
+ (looking-at "\\s<")
+ ;; a bit smarter
+ (and comment-start (looking-at (regexp-quote comment-start)))
+ (and comment-start-skip (looking-at comment-start-skip))
+ ;; hardcoded
+ (cond
+ ((derived-mode-p 'c-mode 'c++-mode 'java-mode)
+ (looking-at-p "//"))))))
(defun ert-font-lock--goto-first-char ()
"Move the point to the first character."
@@ -143,7 +144,7 @@ the test."
(line-end-position) t)
(unless (> linetocheck -1)
- (user-error "Invalid test comment syntax at line %d. Expected a line to test before the comment line" curline))
+ (user-error "Invalid test comment syntax at line %d. Expected a line to test before the comment line" curline)) ;is this a user error?
;; construct a test
(let* (;; either comment start char column (for arrows) or
@@ -243,5 +244,4 @@ The function is meant to be run from within an ERT test."
(provide 'ert-font-lock)
-
;;; ert-font-lock.el ends here
[-- Attachment #3: Type: text/plain, Size: 971 bytes --]
> I am the sole author of the package, and did sign FSF papers some time
> ago so this should not be an issue.
>
> Comments, suggestions and critique are very welcome as the package is
> very new. I am open to ideas on the best places to publish the package
> if ELPA is not suitable for it.
ELPA shouls be fine.
> Some additional context.
>
> A while ago I created quakec-mode
> (https://github.com/vkazanov/quakec-mode). One of the most painful
> things about the mode is regex-based syntax highlighting. So I turned
> to creating a Tree-sitter grammar
> (https://github.com/vkazanov/tree-sitter-quakec) as well as a TS-based
> mode (https://github.com/vkazanov/quakec-ts-mode).
>
> While doing the syntax highlighting part proved to be much, much
> easier, I couldn't do work without relying on some kind of unit tests.
> Existing font-lock systems didn't feel convenient compared to the way
> Tree-sitter specifies parser tests so I replicated that.
>
> Thank you
^ permalink raw reply related [relevance 61%]
* Re: [Reminder]Decommissoned keyservers
@ 2023-11-17 21:15 99% ` Philip Kaludercic
1 sibling, 0 replies; 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: p4_16-mode
@ 2023-11-17 7:36 40% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-11-17 7:36 UTC (permalink / raw)
To: Soham Gumaste; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 262 bytes --]
Soham Gumaste <sohamg2@gmail.com> writes:
> Hello Emacs Devs,
>
> I am writing to ask that my package "p4_16-mode.el" be added to ELPA.
> The repo is at the following link:
>
> https://github.com/SohamG/p4_16-mode.el
Here are a few quick changes I'd propose:
[-- Attachment #2: Type: text/plain, Size: 8632 bytes --]
diff --git a/p4_16-mode.el b/p4_16-mode.el
index 23c2825..f9d146b 100644
--- a/p4_16-mode.el
+++ b/p4_16-mode.el
@@ -3,26 +3,42 @@
;; Author: Soham S Gumaste <sohamg2@gmail.com>
;; Maintainer: Soham S Gumaste <sohamg2@gmail.com>
;; Created: 11 Nov 2023
-;; Original Source: https://github.com/p4lang/tutorials/blob/master/vm/p4_16-mode.el
-;; Original License: Apache 2.0
-;; Original Author: Vladimir Gurevich <vladimir.gurevich@barefootnetworks.com>
-;; Modifications bylicensed under the same license OR the MIT License.
+;; Modifications bilicensed under the same license OR the MIT License.
;; Keywords: languages p4_16
;; This file is not part of GNU Emacs.
-;; This file is free software…
-;; …
-;; along with this file. If not, see <https://www.gnu.org/licenses/>.
+;; This program is free software; you can redistribute it and/or modify
+;; it under the terms of the GNU General Public License as published by
+;; the Free Software Foundation, either version 3 of the License, or
+;; (at your option) any later version.
+
+;; This program is distributed in the hope that it will be useful,
+;; but WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+;; GNU General Public License for more details.
+
+;; You should have received a copy of the GNU General Public License
+;; along with this program. If not, see <https://www.gnu.org/licenses/>.
;;; Commentary:
+
;; P4 (Programming Protocol Independent Packet Processors) is a domain
;; specific language designed to program network fabric devices.
;; This mode has preliminary support for P4_16. It covers the core language,
;; but it is not clear yet, how we can highlight the indentifiers, defined
-;; for a particular architecture. Core library definitions are included
+;; for a particular architecture. Core library definitions are included
+;;; 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?
+
+;; Original Source: https://github.com/p4lang/tutorials/blob/master/vm/p4_16-mode.el
+;; Original License: Apache 2.0
+;; Original Author: Vladimir Gurevich <vladimir.gurevich@barefootnetworks.com>
;;; Code:
(defvar p4_16-mode-hook nil)
@@ -30,46 +46,46 @@
;; Define the keymap (for now it is pretty much default)
(defvar p4_16-mode-map
(let ((map (make-keymap)))
- (define-key map "\C-j" 'newline-and-indent)
+ (define-key map (kbd "C-j") 'newline-and-indent)
map)
- "Keymap for P4_16 major mode")
+ "Keymap for P4_16 major mode.")
-;; Syntactic HighLighting
+;;; Syntactic Highlighting
-;; Main keywords (declarations and operators)
+;;;; Main keywords (declarations and operators)
(defconst p4_16-keywords
- '("action" "apply"
- "control"
- "default"
- "else" "enum" "extern" "exit"
- "header" "header_union"
- "if"
- "match_kind"
- "package" "parser"
- "return"
- "select" "state" "struct" "switch"
- "table" "transition" "tuple" "typedef"
- "verify")
- "P4_16 Standard Keywords")
+ '("action" "apply"
+ "control"
+ "default"
+ "else" "enum" "extern" "exit"
+ "header" "header_union"
+ "if"
+ "match_kind"
+ "package" "parser"
+ "return"
+ "select" "state" "struct" "switch"
+ "table" "transition" "tuple" "typedef"
+ "verify")
+ "P4_16 Standard Keywords.")
(defconst p4_16-annotations
'("@name" "@metadata" "@alias")
- "P4_16 Standard Annotations")
+ "P4_16 Standard Annotations.")
(defconst p4_16-attributes
- '("const" "in" "inout" "out"
- ;; Tables
- "key" "actions" "default_action" "entries" "implementation"
- "counters" "meters")
- "P4_16 Object Attributes and Access Specifiers")
+ '("const" "in" "inout" "out"
+ ;; Tables
+ "key" "actions" "default_action" "entries" "implementation"
+ "counters" "meters")
+ "P4_16 Object Attributes and Access Specifiers.")
(defconst p4_16-variables
'("packet_in" "packet_out")
- "P4_16 Packet Types")
+ "P4_16 Packet Types.")
(defconst p4_16-operations
'("&&&" ".." "++" "?" ":")
- "P4_16 Operators")
+ "P4_16 Operators.")
(defconst p4_16-constants
'(;; Don't care
@@ -83,11 +99,11 @@
"exact" "ternary" "lpm" "range"
;; We can add constants for supported architectures here
)
- "P4_16 Standard Constants")
+ "P4_16 Standard Constants.")
(defconst p4_16-types
'("bit" "bool" "int" "varbit" "void" "error")
- "P4_16 Standard Datatypes")
+ "P4_16 Standard Datatypes.")
(defconst p4_16-primitives
'(;; Header methods
@@ -102,37 +118,36 @@
"accept" "reject"
;; misc
"NoAction")
- "P4_16 Standard Primitives")
+ "P4_16 Standard Primitives.")
(defconst p4_16-cpp
- '("#include"
- "#define" "#undef"
- "#if" "#ifdef" "#ifndef"
- "#elif" "#else"
- "#endif"
- "defined"
- "#line" "#file"))
+ '("#include"
+ "#define" "#undef"
+ "#if" "#ifdef" "#ifndef"
+ "#elif" "#else"
+ "#endif"
+ "defined"
+ "#line" "#file"))
(defconst p4_16-cppwarn
- '("#error" "#warning"))
+ '("#error" "#warning"))
;; Optimize the strings
-(setq p4_16-keywords-regexp (regexp-opt p4_16-keywords 'words))
-(setq p4_16-annotations-regexp (regexp-opt p4_16-annotations 1))
-(setq p4_16-attributes-regexp (regexp-opt p4_16-attributes 'words))
-(setq p4_16-variables-regexp (regexp-opt p4_16-variables 'words))
-(setq p4_16-operations-regexp (regexp-opt p4_16-operations 'words))
-(setq p4_16-constants-regexp (regexp-opt p4_16-constants 'words))
-(setq p4_16-types-regexp (regexp-opt p4_16-types 'words))
-(setq p4_16-primitives-regexp (regexp-opt p4_16-primitives 'words))
-(setq p4_16-cpp-regexp (regexp-opt p4_16-cpp 1))
-(setq p4_16-cppwarn-regexp (regexp-opt p4_16-cppwarn 1))
-
+(defvar p4_16-keywords-regexp (regexp-opt p4_16-keywords 'words))
+(defvar p4_16-annotations-regexp (regexp-opt p4_16-annotations 1))
+(defvar p4_16-attributes-regexp (regexp-opt p4_16-attributes 'words))
+(defvar p4_16-variables-regexp (regexp-opt p4_16-variables 'words))
+(defvar p4_16-operations-regexp (regexp-opt p4_16-operations 'words))
+(defvar p4_16-constants-regexp (regexp-opt p4_16-constants 'words))
+(defvar p4_16-types-regexp (regexp-opt p4_16-types 'words))
+(defvar p4_16-primitives-regexp (regexp-opt p4_16-primitives 'words))
+(defvar p4_16-cpp-regexp (regexp-opt p4_16-cpp 1))
+(defvar p4_16-cppwarn-regexp (regexp-opt p4_16-cppwarn 1))
;; create the list for font-lock.
;; each category of keyword is given a particular face
(defconst p4_16-font-lock-keywords
- (list
+ (list ;Perhaps use backquoting?
(cons p4_16-cpp-regexp font-lock-preprocessor-face)
(cons p4_16-cppwarn-regexp font-lock-warning-face)
(cons p4_16-types-regexp font-lock-type-face)
@@ -154,16 +169,16 @@
(cons "\\([^_A-Za-z][+-]?\\([0-9]+w\\)?[0-9]+\\)" font-lock-constant-face)
;;(cons "\\(\\w*\\)" font-lock-variable-name-face)
)
- "Default Highlighting Expressions for P4_16")
+ "Default Highlighting Expressions for P4_16.")
(defvar p4_16-mode-syntax-table
(let ((st (make-syntax-table)))
(modify-syntax-entry ?_ "w" st)
(modify-syntax-entry ?/ ". 124b" st)
(modify-syntax-entry ?* ". 23" st)
- (modify-syntax-entry ?\n "> b" st)
+ (modify-syntax-entry ?\n "> b" st)
st)
- "Syntax table for p4_16-mode")
+ "Syntax table for p4_16-mode.")
;;; Indentation
(defvar p4_16-indent-offset 4
@@ -192,7 +207,7 @@
;; Put everything together
(defun p4_16-mode ()
- "Major mode for editing P4_16 programs"
+ "Major mode for editing P4_16 programs."
(interactive)
(kill-all-local-variables)
(set-syntax-table p4_16-mode-syntax-table)
@@ -201,8 +216,8 @@
(set (make-local-variable 'indent-line-function) 'p4_16-indent-line)
(setq major-mode 'p4_16-mode)
(setq mode-name "P4_16")
- (with-eval-after-load "xcscope" (cscope-minor-mode))
+ (when (fboundp 'cscope-minor-mode) (cscope-minor-mode))
(run-hooks 'p4_16-mode-hook))
-;; The most important line
(provide 'p4_16-mode)
+;;; p4_16-mode.el ends here
[-- Attachment #3: Type: text/plain, Size: 742 bytes --]
Also, would it be imaginable to rename it to p4-16-mode? The mid-symbol
underscore looks unusual in a Lisp context
> Summary:
> P4 (Programming Protocol Independent Packet Processors) is a domain
> specific language used to program network fabric devices like NICs or
> switches. The project can be found at https://p4.org . This package
> adds a major mode for this language. This mode was initially a part of
> the github repo "p4lang/tutorials" (Apache 2.0). I have added some
> polish, and obtained permission from the repo maintainers to submit
> here.
I suppose you want to add the package to NonGNU ELPA then?
> I do not have write access to the ELPA git repo. Please let me know if
> I need to make any modifications.
>
> Thanks
^ permalink raw reply related [relevance 40%]
* Re: [ELPA] New package: SachaC-news
@ 2023-11-17 7:28 21% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-11-17 7:28 UTC (permalink / raw)
To: Christian; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 959 bytes --]
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:
[-- Attachment #2: Type: text/plain, Size: 17723 bytes --]
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
[-- Attachment #3: Type: text/plain, Size: 774 bytes --]
> 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!!"
^ permalink raw reply related [relevance 21%]
* Re: Making package.el talk over Tor
@ 2023-11-17 7:03 98% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-11-17 7:03 UTC (permalink / raw)
To: Richard Stallman; +Cc: Akib Azmain Turja, emacs-devel
Richard Stallman <rms@gnu.org> writes:
> [[[ To any NSA and FBI agents reading my email: please consider ]]]
> [[[ whether defending the US Constitution against all enemies, ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> Thanks for replying to my question a month ago.
> I got so backlogged I just saw the reply.
>
> > > 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?
>
> > Isearching for 'url-' reveals that the following functions use the URL
> > package to access the HTTP server: 'package--with-work-buffer',
> > 'package--archive-file-exists-p' and'package--with-response-buffer-1'.
>
> > But I think a better/safer solution will be to use torsocks.
>
> I agree, and I plan to use torsocks. But in order to do thst, I need
> to know where to do that. That's really what my question was about.
>
> Can you suggest where I should do that?
>
> Does the url package have a variable to specify the command to use?
> I could specify torsocks there.
No, url.el eventually calls `make-network-process', that directly
invokes the respective networking system calls, not making it possible
to interject torsocks. What I believe Akib meant was to start Emacs
with torsocks, but to my understanding this is not a recommended
practice either, because one will continue to leak fingerprintable
metadata (specially inside of Emacs) that would undermine the point of
using Tor to begin with.
^ permalink raw reply [relevance 98%]
* Re: Instead of pcase
@ 2023-11-16 18:47 81% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-11-16 18:47 UTC (permalink / raw)
To: T.V Raman; +Cc: dmitry, rms, emacs-devel
"T.V Raman" <raman@google.com> writes:
> when-let let-alist etc have worked well for me.
>
> What threw me with pcase is there are lots of special chars in that
> particular example whose meaning I dont know, and looking those up and
> understanding their use at the same time was what chased me away
Taking the concrete example you mentioned,
(pcase res
(`(,_ . ,(and (pred functionp) f)) (funcall f))
(`(,hookfun . (,start ,end ,collection . ,plist))
the unknown or unfamiliar characters are "`" and ",". The (dynamic)
pcase documentation string is pretty straightforward in explaining what
it does, or can you recall what confused you?:
--8<---------------cut here---------------start------------->8---
-- `QPAT
Backquote-style pcase patterns: `QPAT
QPAT can take the following forms:
(QPAT1 . QPAT2) matches if QPAT1 matches the car and QPAT2 the cdr.
[QPAT1 QPAT2..QPATn] matches a vector of length n and QPAT1..QPATn match
its 0..(n-1)th elements, respectively.
,PAT matches if the ‘pcase’ pattern PAT matches.
SYMBOL matches if EXPVAL is ‘equal’ to SYMBOL.
KEYWORD likewise for KEYWORD.
NUMBER likewise for NUMBER.
STRING likewise for STRING.
The list or vector QPAT is a template. The predicate formed
by a backquote-style pattern is a combination of those
formed by any sub-patterns, wrapped in a top-level condition:
EXPVAL must be "congruent" with the template. For example:
`(technical ,forum)
--8<---------------cut here---------------end--------------->8---
Or if you mean "_", then
--8<---------------cut here---------------start------------->8---
PATTERN can take one of the forms:
_ matches anything.
--8<---------------cut here---------------end--------------->8---
which is familiar to people coming from functional languages, but even
Elisp uses underscores to denote unused variables.
^ permalink raw reply [relevance 81%]
* 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: Instead of pcase
@ 2023-11-16 7:37 95% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-11-16 7:37 UTC (permalink / raw)
To: Richard Stallman; +Cc: emacs-devel
Richard Stallman <rms@gnu.org> writes:
> I can see why people want something along those lines. Using `cond'
> and `let' to do these jobs feels long-winded and cumbersome; they were
> not designed to make this easy. So we wish for something to make such
> code more concise.
[...]
> I'm looking at adapting some of the features of `pcase' into other
> constructs, so as to make type-discrimination code more concise than
> in old-fashioned Lisp, but _not_ so concise as to be cryptic and
> burdensome.
The critical feature of pcase is pattern matching. The complexity of
`pcase' is the extensibility -- a lisp-like flexibility that makes it so
attractive -- that a simpler macro might not need. The question is, if
one would restrict pcase to just matching expressions using ` and , like
(pcase sexp ;match various top-level constructs
(`(defun ,name ,args ,body) ...)
(`(defvar ,name, ,value) ...)
(`(require ',symbol) ...)
...)
would that be simple enough in your opinion? Anyone familiar with
ML-style functional programming, Prolog or the notion of unification
should be able to understand this quickly enough, I assume?
^ permalink raw reply [relevance 95%]
* 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: ELPA submission: drepl (REPL protocol)
2023-10-31 9:08 76% ` Philip Kaludercic
@ 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: seq.el and the complexity of Emacs Lisp.
@ 2023-11-06 6:51 97% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-11-06 6:51 UTC (permalink / raw)
To: Richard Stallman; +Cc: Gerd Möllmann, paaguti, 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 looked at seq.el to try to get an idea what those functions do. It
> was difficult to get this from the doc strings, because it wasn't
> explicitly stated which ones are for users and which ones are
> internal. Eventually I got somewhat of an idea.
>
[...]
> I expect that they are slower at run-time, because each seq- function
> needs to do the generic dispatch for each call. Is that correct?
Yes, I believe this has been empirically verified on multiple occasions.
[...]
> Could we replace all the cl-lib sequence function calls with seq-
> calls, in core and GNU ELPA code? Seq is simpler and cleaner, so that
> would be an improvement. We could keep cl-lib permanently for
> compatibility for external code, but it would not need to be loaded
> (into Emacs or your brain) very often.
Cl-lib would still be used, because it provides more than just functions
to operate on sequences. There are a number of macros (cl-flet,
cl-loop, cl-incf, ...) and functions (cl-map accepting multiple lists,
cl-subst) that are frequently used and to my recollection to not yet
have analogous replacements in seq.
^ permalink raw reply [relevance 97%]
* 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] New package: dape
@ 2023-11-04 15:27 72% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-11-04 15:27 UTC (permalink / raw)
To: Adam Porter
Cc: daniel, dmitry, eliz, emacs-devel, joaotavora, john,
krister.schuchardt
Adam Porter <adam@alphapapa.net> writes:
> Hello Philip,
>
>> In addition to this, there have on multiple occasions been authors
>> who have been open and appreciative of names being suggested here on
>> the mailing list, especially if they don't have a strong opinion wrt
>> the name to begin with. It seems unjustified to claim that
>> mentioning the topic will necessarily scare people away.
>
> Please don't misunderstand me. I am not claiming that it will
> necessarily scare people away. I am claiming that the bikeshedding can
> be discouraging to authors who consider submitting to GNU ELPA. This
> should not be surprising, as I don't think anyone would enjoy having to
> endure a lengthy thread second-guessing their decision, which usually
> seems to proceed with the assumption that the author hasn't already
> spent time making it deliberately.
In this context, as is usually the case with a package submission, I
submitted comments and suggestions on how to improve the package, and
then apologised for braining up the topic of naming the package, to see
if Daniel was committed or not to the name (implying they have spent
time making a deliberate decision), to which he responded:
I'm not overly attached to it. What are your objections? And do you have
any suggestions? I find it quite difficult to name things like this.
Which I think is a fair starting point for a discussion.
> As well, I can go through the list of packages on GNU ELPA and find
> tens of them whose names don't bear any apparent relation to their
> purpose or description. Should that stop us from seeking better
> names? Of course not. But at what point do we admit that Shakespeare
> was right?
That is true, but there are a number of them with great names IMO:
- aggressive-completion
- comint-mime
- cycle-at-point
- idle-highlight-mode
- notmuch-indicator
- page-break-lines
- rainbow-delimiters
- scroll-on-jump
- visual-fill-column
I have always associated GNU ELPA with having proper and expressive
names, that either are self-descriptive or re-use nomenclature that
Emacs users would be familiar with to begin with (things like "electric"
or "i"-something for interactive). Makes it easier to remember the
names and builds on intuition, which we shouldn't underestimate as a
measure for user comfort. Not everyone is young and enthusiastic enough
to keep memorising and associating new names.
>> (I didn't want to bring this up initially, but one of the reasons I
>> mentioned changing the name is due to the small edit distance between
>> "dape" and "r*pe", that I can imagine would make other people more
>> uncomfortable).
>
> Well, let's see, in QWERTY order: tape, ape, gape, jape, cape, vape,
> nape... I think that's not a practical reason to reject an author's
> name, and not a very polite association to make with the name he
> chose.
I am not sure what you are trying to say here, this is just the
association I made. I usually think about how saying packages names out
loud, when speaking with other people feels like. Names name "eglot"
(not 'elgot) or "vertico" (not "vertigo") are frequently misunderstood
in my experience, and names in this case I could imagine a third person
listening in on a conversation could misunderstand something, because it
sounds like a slang word. FWIW urban dictionary doesn't have the nicest
entry when you look up "dape"...
^ permalink raw reply [relevance 72%]
* Re: [ELPA] New package: dape
@ 2023-11-04 14:24 92% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-11-04 14:24 UTC (permalink / raw)
To: Eli Zaretskii
Cc: Adam Porter, daniel, joaotavora, dmitry, john, krister.schuchardt,
emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> Date: Sat, 4 Nov 2023 08:46:35 -0500
>> Cc: Dmitry Gutov <dmitry@gutov.dev>, John Yates <john@yates-sheets.org>,
>> Krister Schuchardt <krister.schuchardt@gmail.com>, emacs-devel@gnu.org,
>> philipk@posteo.net
>> From: Adam Porter <adam@alphapapa.net>
>>
>> While friendly, gentle suggestions are ok, the pressure being put on
>> authors in this process is unbecoming, to say the least.
>
> Please stop the insinuations. There's no pressure. We are asking
> authors to consider changing the names, that's all; if they don't
> agree, the issue is dropped on the floor. It is, after all, our
> prerogative and even our job, out of the wish to serve our users
> better, to try to have packages with reasonablt self-explanatory names
> where possible. You don't have to like it, but at least please
> respect our views on that and our perspective. Your flat rejection of
> it is unbecoming, to say the least.
In addition to this, there have on multiple occasions been authors who
have been open and appreciative of names being suggested here on the
mailing list, especially if they don't have a strong opinion wrt the
name to begin with. It seems unjustified to claim that mentioning the
topic will necessarily scare people away. (I didn't want to bring this
up initially, but one of the reasons I mentioned changing the name is
due to the small edit distance between "dape" and "r*pe", that I can
imagine would make other people more uncomfortable).
^ permalink raw reply [relevance 92%]
* Re: [ELPA] New package: dape
@ 2023-11-04 10:00 99% ` Philip Kaludercic
2023-11-23 6:10 91% ` Philip Kaludercic
1 sibling, 1 reply; 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-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: What's missing in ELisp that makes people want to use cl-lib?
@ 2023-11-03 8:13 95% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-11-03 8:13 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: rms, joaotavora, adam, emacs-devel, stefankangas
Eli Zaretskii <eliz@gnu.org> writes:
>> >> Could you explain what you mean by "traditional" Emacs Lisp?
>> >
>> > Basically, the language as it is, without macros whose syntax is
>> > different from Emacs Lisp. For example, cl-loop has syntax that to my
>> > eyes is starkly not Emacs Lisp, because it uses many keyword-like
>> > parts that look like they were lifted from Fortran.
>>
>> Then again (cl-)loop is a peculiar example; even among CL programmers
>> there are many that dislike using it on the same grounds.
>
> Grepping our own sources for "(cl-loop" comes back with more than 760
> hits. That's more than one use for every 2 Lisp files in our tree.
>
> And cl-loop is not the only example of additions whose syntax deviates
> from Emacs Lisp traditions.
It certainly has fans, though I believe this is more due to the utility
and flexibility than the syntax. If there were a Elisp'ish alternative
(in the sense in which pcase is also an alternative to cl-case --
assuming that you see pcase as Elisp'ish?), then I honestly believe it
could be more popular than cl-loop. I would be disappointed if being
Elisp'ish would mean that these kinds of language features per se
wouldn't be permissible.
^ permalink raw reply [relevance 95%]
* 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: What's missing in ELisp that makes people want to use cl-lib?
@ 2023-11-03 7:48 75% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-11-03 7:48 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: rms, joaotavora, adam, emacs-devel, stefankangas
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: rms@gnu.org, joaotavora@gmail.com, adam@alphapapa.net,
>> emacs-devel@gnu.org, stefankangas@gmail.com
>> Date: Thu, 02 Nov 2023 21:26:00 +0000
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> > AFAIU, it means that Emacs Lisp traditionally doesn't use keyword
>> > arguments, except as relatively rare exceptions.
>>
>> It is used rather prominently in `define-minor-mode' or
>> `define-derived-mode', or do you specifically mean keyword arguments to
>> functions?
>
> I did mention exceptions, didn't I?
>
> And define-derived-mode supports keyword arguments only since Emacs
> 22; the original implementation didn't.
Ok, I interpreted this as in "few usages", not in "few definitions".
>> >> what constitutes "Emacs Lisp"? It would
>> >> seem peculiar if it were to be defined by the arbitrary decisions of the
>> >> past, constrained by the contingent circumstances of the time.
>> >
>> > Those "arbitrary decisions" are what got us to where we are now, 40
>> > years later. So some respect for those "arbitrary decisions" is due,
>> > I think.
>>
>> No disrespect meant, but I am not sure we are thinking of the same
>> things. An "arbitrary decision" usually doesn't matter much, like
>> calling a function rplacd or setcdr. If a decision got us to where we
>> are now, I would say it wasn't that arbitrary, but a good one?
>
> Exactly my point. So what did you mean by "It would seem peculiar if
> [what constitutes Emacs Lisp] were to be defined by the arbitrary
> decisions of the past"?
That "setcar" is supposed to be more Elisp-ish than "rplacd", or things
like that.
>> > IMNSHO, extending Emacs Lisp as the language is not the main goal of
>> > Emacs development. Emacs Lisp is not a programming language on its
>> > own, it is a language for implementing and extending features and
>> > extensions in Emacs. Thus, the main goal of Emacs development is to
>> > develop applications and application-level features, and provide more
>> > opportunities for extending the core where that is considered useful.
>> > What we have in Emacs Lisp is IMO ample for that purpose. Moreover,
>> > most participants in Emacs development are not experts in programming
>> > languages, their expertise is elsewhere (which is definitely a Good
>> > Thing).
>>
>> Of course not extending it for its own sake, but I would assume that
>> making it easier for users to write practical and useful code should be
>> something that is valued.
>
> We should consider such additions carefully, weighing their advantages
> against the disadvantages: introducing "alien" syntax, making the
> language larger, etc.
What I had in mind were extensions like the recent `with-restriction'.
Defining something like this came to my mine on more than one occasion
when combining `save-restriction' and `narrow-to-region' in exactly the
same pattern as I had done many times before, because it seems natural
to have it combined in a single form. I don't think this is necessarily
alien, perhaps even natural in the long term.
>> > Objectively, adding new syntax and semantics to Emacs Lisp does make
>> > the source code harder to read and maintain, because it makes the
>> > language larger and requires familiarization with those new language
>> > features, which more often than not look and feel completely different
>> > from the "traditional" Emacs Lisp. So even if we conclude that these
>> > additions are worthwhile, we should not pretend they come without a
>> > price, and IMO we should think carefully whether their use is
>> > justified before we use them in each and every case.
>>
>> Could you explain what you mean by "traditional" Emacs Lisp?
>
> Basically, the language as it is, without macros whose syntax is
> different from Emacs Lisp. For example, cl-loop has syntax that to my
> eyes is starkly not Emacs Lisp, because it uses many keyword-like
> parts that look like they were lifted from Fortran.
Then again (cl-)loop is a peculiar example; even among CL programmers
there are many that dislike using it on the same grounds. As a macro,
it doesn't really even attempt to blend into the surrounding language,
but uses special keywords and syntax parsing, that has both its
advantages and disadvantages, but it is still used if only because CL
doesn't have a simple `while' macro.
This is a much more stark example than pushnew. I could imagine that
pushnew could be implemented without a keyword argument, if we accepted
three arguments (newelt place compare-fn).
But there are a plenty of definitions in cl-lib that in some form or
another I think would be nice to have in Elisp proper as well: list*,
flet, defmacro/defgeneric, defstruct would be some examples that come to
mind. This is not only my personal perspective, but the feeling I get
from reviewing Elisp packages that include cl-lib for only two or three
definitions.
^ permalink raw reply [relevance 75%]
* Re: What's missing in ELisp that makes people want to use cl-lib?
@ 2023-11-02 21:26 87% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-11-02 21:26 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: rms, joaotavora, adam, emacs-devel, stefankangas
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: João Távora <joaotavora@gmail.com>,
>> adam@alphapapa.net, emacs-devel@gnu.org, stefankangas@gmail.com
>> Date: Thu, 02 Nov 2023 08:55:54 +0000
>>
>> Richard Stallman <rms@gnu.org> writes:
>>
>> > It might be ok to add some keyword arguments to `sort', which are more
>> > unusual and complex to use, but not to simple constructs like
>> > `pushnew'. This is Emacs Lisp, not Common Lisp.
>>
>> What does that last sentence mean?
>
> AFAIU, it means that Emacs Lisp traditionally doesn't use keyword
> arguments, except as relatively rare exceptions.
It is used rather prominently in `define-minor-mode' or
`define-derived-mode', or do you specifically mean keyword arguments to
functions?
>> what constitutes "Emacs Lisp"? It would
>> seem peculiar if it were to be defined by the arbitrary decisions of the
>> past, constrained by the contingent circumstances of the time.
>
> Those "arbitrary decisions" are what got us to where we are now, 40
> years later. So some respect for those "arbitrary decisions" is due,
> I think.
No disrespect meant, but I am not sure we are thinking of the same
things. An "arbitrary decision" usually doesn't matter much, like
calling a function rplacd or setcdr. If a decision got us to where we
are now, I would say it wasn't that arbitrary, but a good one?
>> to me the main aspects and attractions of Emacs Lisp (in contrast to
>> CL and Scheme) have been:
>>
>> 1. Not standardised; it is possible to extend the language without
>> having to worry about how many implementations will follow along
>
> IMNSHO, extending Emacs Lisp as the language is not the main goal of
> Emacs development. Emacs Lisp is not a programming language on its
> own, it is a language for implementing and extending features and
> extensions in Emacs. Thus, the main goal of Emacs development is to
> develop applications and application-level features, and provide more
> opportunities for extending the core where that is considered useful.
> What we have in Emacs Lisp is IMO ample for that purpose. Moreover,
> most participants in Emacs development are not experts in programming
> languages, their expertise is elsewhere (which is definitely a Good
> Thing).
Of course not extending it for its own sake, but I would assume that
making it easier for users to write practical and useful code should be
something that is valued.
> Objectively, adding new syntax and semantics to Emacs Lisp does make
> the source code harder to read and maintain, because it makes the
> language larger and requires familiarization with those new language
> features, which more often than not look and feel completely different
> from the "traditional" Emacs Lisp. So even if we conclude that these
> additions are worthwhile, we should not pretend they come without a
> price, and IMO we should think carefully whether their use is
> justified before we use them in each and every case.
Could you explain what you mean by "traditional" Emacs Lisp? But yes, I
am not advocating for senselessly adding whatever seems remotely
interesting, of course.
>> Emacs Lisp can learn from interesting ideas that other
>> languages provide, adapt and add them, making them available to
>> everyone.
>
> It certainly can. The question is: should it? Since we are not
> driven by any standard, it is completely up to us to make those
> decisions, and we should IMO make them judiciously and carefully,
> taking the downsides into consideration. In particular, I hope people
> agree that making a language too large and complex is not a good
> thing in the long run.
>
>> If a form expresses something that people frequently want to
>> do, but either have to elaborate using (unless (memq ...) (push ...)),
>> then we are making Emacs more useful and expressive by providing the
>> functionality OOTB. And isn't that the real point of Emacs Lisp?
>
> AFAIU, what Richard says is that if some form is frequently used, we
> should indeed consider adding a primitive or an API for it, but that
> primitive or API doesn't have to look like CL. Cf the pushnew
> argument.
Right, I agree with everything here. The functionality, not the style
is of interest.
^ permalink raw reply [relevance 87%]
* Re: What's missing in ELisp that makes people want to use cl-lib?
@ 2023-11-02 8:55 80% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-11-02 8:55 UTC (permalink / raw)
To: Richard Stallman
Cc: João Távora, adam, emacs-devel,
stefankangas
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 might be ok to add some keyword arguments to `sort', which are more
> unusual and complex to use, but not to simple constructs like
> `pushnew'. This is Emacs Lisp, not Common Lisp.
What does that last sentence mean? I hope this is not a too
philosophical question, but what constitutes "Emacs Lisp"? It would
seem peculiar if it were to be defined by the arbitrary decisions of the
past, constrained by the contingent circumstances of the time.
Certainly part of it is that it is part of a tradition of Lisp
implementations, that gives it a distinctive flavour, but to me the main
aspects and attractions of Emacs Lisp (in contrast to CL and Scheme)
have been:
1. Not standardised; it is possible to extend the language without
having to worry about how many implementations will follow along
2. Accepting Unix; not trying to abstract over various different
operating systems and file systems, making it easier to work with GNU
and other POSIX-based environments.
The first point would be relevant here. Just like if-let or
thread-first, Emacs Lisp can learn from interesting ideas that other
languages provide, adapt and add them, making them available to
everyone. If a form expresses something that people frequently want to
do, but either have to elaborate using (unless (memq ...) (push ...)),
then we are making Emacs more useful and expressive by providing the
functionality OOTB. And isn't that the real point of Emacs Lisp?
^ permalink raw reply [relevance 80%]
* Re: [ELPA] New package: dired-duplicates
@ 2023-11-01 21:29 88% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-11-01 21:29 UTC (permalink / raw)
To: Harald Judt; +Cc: emacs-devel, Stefan Kangas, Eli Zaretskii, Visuwesh
Harald Judt <h.judt@gmx.at> writes:
> Hi,
>
> On 2023-11-01 12:32, Philip Kaludercic wrote:
>
>> You forgot to CC me in the response, I would have almost missed your response.
>
> I am very sorry for this.
No worries, happens to everyone :)
>> Harald Judt <h.judt@gmx.at> writes:
>>
>>> On 2023-10-31 13:21, Philip Kaludercic wrote:
>>>
>>> [...]
>>>
>>>> @@ -225,7 +220,7 @@ This is the same as `dired-do-flagged-delete', but calls
>>>> (defvar dired-duplicates-map
>>>> (let ((map (make-sparse-keymap)))
>>>> - ;; workaround for Emacs bug #57565
>>>> + ;; workaround for Emacs bug#57565
>>>> (when (< emacs-major-version 29)
>>>> (define-key map (kbd "x") 'dired-duplicates--do-flagged-delete)
>>>> (define-key map (kbd "D") 'dired-duplicates--do-delete))
>>>
>>> BTW: What's the reasoning behind this suggested change?
>> I thought that this would be necessary for bug-reference-mode to
>> work,
>> but apparently it can detect both of these references.
>
> Yes, whether space or not, it doesn't matter, at least in
> Emacs-29.1. But that aside, bug reference mode wants to take me to a
> page on my project (https://codeberg.org/bug/issues/57565) which does
> not exist because it is an *Emacs* bug that is referenced in the
> comment, not a bug in dired-duplicates.
I am afraid I don't understand. Did you modify `bug-reference-url-format'?
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>>>> From: Philip Kaludercic <philipk@posteo.net>
>>>> Cc: emacs-devel@gnu.org
>>>> Date: Tue, 31 Oct 2023 12:21:51 +0000
>>>>
>>>> In the meantime, here is some quick and superficial feedback on the code:
>>>
>>> What I would like to ask is whether Harald tried to calculate SHA256
>>> using Emacs's own primitives, instead of relying on an external
>>> program, which may or may not be installed.
>> That is a good point, but I can imagine that one reason for using an
>> external tool is that if the user has a specific program they wish to
>> use that is not available as an Emacs primitive?
>
> I have not tried to calculate SHA256 using Emacs's own primitives, but
> not because I did not want to. The reasoning behind my decision is the
> following:
>
> dired-duplicates does support local files and *remote* files - via
> TRAMP. For local files using Emacs's own primitives could be OK
> performance-wise, I have not tested this. But if one starts to use
> them for fetching files via TRAMP which means over network, then
> things could slow down to a crawl pretty fast (it even takes quite a
> while collecting size stats over the network). So it is not Emacs's
> SHA256 calculation that would be a problem here, but instead slow
> transport over network. If the host does the calculation, this should
> be a lot faster (though that of course depends on whether the files
> are local files on the host of course and not some mounted network
> resource). I think it is reasonable to assume that one would *not*
> want to download large video files over the network to check if they
> are duplicates.
>
> The second thing is customizability of course, and probably necessary
> because of my reasoning explained in the previous paragraph. The
> remote host might have md5sum installed, but not sha256sum. So I
> wanted to provide a way for the user to configure the checksum
> command.
>
> I do not object against implementing a fallback as Eli suggested; I
> simply have not implemented it because I did not know about Emacs's
> primitives, and at that same time my reasoning about remote files
> started and so that is the way it is now.
>
> Regards,
> Harald
Harald Judt <h.judt@gmx.at> writes:
> Hi,
>
> On 2023-11-01 20:24, Eli Zaretskii wrote:
>>> From: Philip Kaludercic <philipk@posteo.net>
>>> Cc: Visuwesh <visuweshm@gmail.com>, h.judt@gmx.at, emacs-devel@gnu.org
>>> Date: Wed, 01 Nov 2023 17:57:40 +0000
>>>
>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>
>>>> I'd like to see the numbers which led to the conclusion that
>>>> performance was prohibitive.
>>>>
>>>> And even if the performance is indeed much worse, it could be a
>>>> fallback in case the program is not available -- which would IMO be
>>>> much better than simply failing to provide the functionality in that
>>>> case.
>>>
>>> This is a cheap test on a 1.4GB ISO I had lying around:
>> Thanks. But this is just a single large file, not a frequent use
>> case
>> for this package.
>>
>>> --8<---------------cut here---------------start------------->8---
>>> (benchmark-run 1
>>> (with-temp-buffer
>>> (insert-file-contents-literally "~/Downloads/haiku-r1beta4-x86_64-anyboot.iso")
>>> (secure-hash 'sha512 (current-buffer))))
>>> ;; (44.389091035 1 1.5836082630000021)
>>>
>>> (benchmark-run 1
>>> (with-temp-buffer
>>> (call-process "sha512sum" nil t nil (expand-file-name "~/Downloads/haiku-r1beta4-x86_64-anyboot.iso"))
>>> (goto-char (point-min))
>>> (and (looking-at (rx bos (+ alnum)))
>>> (match-string 0))))
>>> ;; (5.155846791 0 0.0)
>>> --8<---------------cut here---------------end--------------->8---
>> And this is not the package doing its job, this is just a single
>> task
>> the package does when looking for duplicates. The numbers when
>> running the package with call-process replaced by secure-hash will
>> probably be different.
>
> Thanks for the numbers. What troubles me a bit more than the speed is
> which effects inserting such a large file into a buffer has
> memory-wise?
It appears to depend on the size of the file. I haven't determined the
exact tipping point where loading a file into memory becomes more
expensive than spawning a process, but it seems to be relatively low.
Another advantage of using a subprocess, is that the files can be
processed in parallel, assuming you start the processes asynchronously.
> Regards,
> Harald
Harald Judt <h.judt@gmx.at> writes:
> Hi Philip,
>
> Another more organisational question regarding your review: If I apply
> your patch and create commits from it in the project, should I then
> use your name and email address as author of the commit (I guess I can
> assume you also assigned copyright to the FSF ;-))?
You can attribute it to me, but I don't really care much either way. I
didn't really send you a patch to apply, but just the output of C-x v =
after leaving a few comments in the file.
> Harald
^ permalink raw reply [relevance 88%]
* 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] New package: dired-duplicates
@ 2023-11-01 17:57 96% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-11-01 17:57 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Visuwesh, h.judt, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Visuwesh <visuweshm@gmail.com>
>> Cc: Philip Kaludercic <philipk@posteo.net>, h.judt@gmx.at,
>> emacs-devel@gnu.org
>> Date: Wed, 01 Nov 2023 19:23:32 +0530
>>
>> [புதன் நவம்பர் 01, 2023] Eli Zaretskii wrote:
>>
>> >> From: Philip Kaludercic <philipk@posteo.net>
>> >> Cc: emacs-devel@gnu.org
>> >> Date: Tue, 31 Oct 2023 12:21:51 +0000
>> >>
>> > What I would like to ask is whether Harald tried to calculate SHA256
>> > using Emacs's own primitives, instead of relying on an external
>> > program, which may or may not be installed.
>>
>> >From OP,
>>
>> The only external requirement is a checksum program like md5 or
>> sha256sum that generates a hash value from the contents of a file used
>> for comparison, because Emacs cannot do that in a performance-efficient
>> way.
>>
>> So I guess the answer is no.
>
> I'd like to see the numbers which led to the conclusion that
> performance was prohibitive.
>
> And even if the performance is indeed much worse, it could be a
> fallback in case the program is not available -- which would IMO be
> much better than simply failing to provide the functionality in that
> case.
This is a cheap test on a 1.4GB ISO I had lying around:
--8<---------------cut here---------------start------------->8---
(benchmark-run 1
(with-temp-buffer
(insert-file-contents-literally "~/Downloads/haiku-r1beta4-x86_64-anyboot.iso")
(secure-hash 'sha512 (current-buffer))))
;; (44.389091035 1 1.5836082630000021)
(benchmark-run 1
(with-temp-buffer
(call-process "sha512sum" nil t nil (expand-file-name "~/Downloads/haiku-r1beta4-x86_64-anyboot.iso"))
(goto-char (point-min))
(and (looking-at (rx bos (+ alnum)))
(match-string 0))))
;; (5.155846791 0 0.0)
--8<---------------cut here---------------end--------------->8---
^ permalink raw reply [relevance 96%]
* Re: [ELPA] New package: dape
2023-10-19 15:12 97% ` Philip Kaludercic
@ 2023-11-01 16:50 99% ` Philip Kaludercic
2 siblings, 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: [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: dired-duplicates
@ 2023-11-01 11:32 81% ` Philip Kaludercic
1 sibling, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-11-01 11:32 UTC (permalink / raw)
To: Harald Judt; +Cc: emacs-devel
You forgot to CC me in the response, I would have almost missed your response.
Harald Judt <h.judt@gmx.at> writes:
> Hi,
>
>
> On 2023-10-31 13:21, Philip Kaludercic wrote:
>
> [...]
>
>> Sure, I can take care of adding the package to the archive, you'll only
>> have to bump the "Version" header when you want the package to be
>> released (and in the future as well, the commit that touches the
>> "Version" header triggers a new release).
>> In the meantime, here is some quick and superficial feedback on the
>> code:
>
> Great news! Thank you for your feedback, I'll try to incorporate it
> and push the changes to the package git repository soon. Though I have
> a few questions understanding some of this:
>
>> diff --git a/dired-duplicates.el b/dired-duplicates.el
>> index d62af02..4af37a3 100644
>> --- a/dired-duplicates.el
>> +++ b/dired-duplicates.el
>> @@ -54,7 +54,6 @@
>> (defcustom dired-duplicates-separate-results
>> t
>> "Boolean value indicating whether to separate results with new-lines."
>> - :group 'dired-duplicates
>
> [...]
>
> Why should I not use :group for customization? I thought this makes it
> easier to explore customization?
See Michael's response. Basically what is going on is that the defgroup
macro has a side effect during macro expansion. Consider something like:
(defvar foo)
(defmacro bar (val)
(ignore (setq foo val)))
(defmacro baz ()
foo)
then:
(progn (bar 2) (baz)) expands to (progn nil 2)
>> @@ -103,21 +98,22 @@ return boolean t if the file matches a criteria, otherwise nil."
>> The executable used is defined by
>> `dired-duplicates-checksum-exec'."
>> (let* ((default-directory (file-name-directory (expand-file-name file)))
>> - (exec (executable-find dired-duplicates-checksum-exec t)))
>> + (exec (executable-find dired-duplicates-checksum-exec t))
>> + (file (expand-file-name (file-local-name file))))
>> (unless exec
>> - (user-error "Checksum program %s not found in exec-path" exec))
>> - (car (split-string
>> - (shell-command-to-string
>> - (concat exec " \"" (expand-file-name (file-local-name file)) "\""))
>> - nil
>> - t))))
>> + (user-error "Checksum program %s not found in `exec-path'" exec))
>> + (with-temp-buffer
>> + (unless (zerop (call-process exec nil t nil file))
>> + (error "Failed to start checksum program %s" exec))
>> + (goto-char (point-min))
>> + (if (looking-at "\\`[[:alnum:]]+")
>> + (match-string 0)
>> + (error "Unexpected output from checksum program %s" exec)))))
>
> Yeah, good idea to improve the error handling.
>
> [...]
>
>> (defun dired-duplicates--find-and-filter-files (directories)
>> "Search below DIRECTORIES for duplicate files.
>> @@ -140,14 +136,14 @@ duplicate files as values."
>> (append (gethash size same-size-table) (list f)))
>> finally
>> (cl-loop for same-size-files being the hash-values in same-size-table
>> - if (> (length same-size-files) 1) do
>> + if (> (length same-size-files) 1) do ;see length>
>> (cl-loop for f in same-size-files
>> for checksum = (dired-duplicates-checksum-file f)
>> do (setf (gethash checksum checksum-table)
>> (append (gethash checksum checksum-table) (list f)))))
>> (cl-loop for same-files being the hash-value in checksum-table using (hash-key checksum)
>> do
>> - (if (> (length same-files) 1)
>> + (if (cdr same-files) ;(> (length same-files) 1) in O(1)
>> (setf (gethash checksum checksum-table)
>> (cons (file-attribute-size (file-attributes (car same-files)))
>> (sort same-files #'string<)))
>
> Nice to know. Though I find length> more readable, I'll use cdr since
> I also use car ;-)
Note that that would require a hard dependency on Emacs 28 (unless you
use Compat).
>> @@ -180,7 +176,6 @@ Currently, this simply adds a new-line after each results group."
>> for len in lengths
>> do
>> (forward-line len)
>> - ;; (forward-line len)
>> (let ((inhibit-read-only t))
>> (beginning-of-line)
>> (unless (= (point) (point-max))
>
> Thanks, I wonder how I have not noticed this.
>
>> @@ -225,7 +220,7 @@ This is the same as `dired-do-flagged-delete', but calls
>> (defvar dired-duplicates-map
>> (let ((map (make-sparse-keymap)))
>> - ;; workaround for Emacs bug #57565
>> + ;; workaround for Emacs bug#57565
>> (when (< emacs-major-version 29)
>> (define-key map (kbd "x") 'dired-duplicates--do-flagged-delete)
>> (define-key map (kbd "D") 'dired-duplicates--do-delete))
>> @@ -248,7 +243,7 @@ The results will be shown in a Dired buffer."
>> default-directory)))
>> (unless directories
>> (user-error "Specify one or more directories to search in"))
>> - (let* ((directories (if (listp directories) directories (list directories)))
>> + (let* ((directories (if (listp directories) directories (list directories))) ;see `ensure-list'
>
> `ensure-list' would bump emacs requirements to 28.1 or require compat
> hence I did not use it.
But you have used other definitions that would have also raised the
dependency to at least 28.1? You can use package-lint to detect these.
> [...]
>
> Thanks for the review and your suggestions.
>
> Regards,
> Harald
Michael Heerdegen <michael_heerdegen@web.de> writes:
> Harald Judt <h.judt@gmx.at> writes:
>
>> > diff --git a/dired-duplicates.el b/dired-duplicates.el
>> > index d62af02..4af37a3 100644
>> > --- a/dired-duplicates.el
>> > +++ b/dired-duplicates.el
>> > @@ -54,7 +54,6 @@
>> > (defcustom dired-duplicates-separate-results
>> > t
>> > "Boolean value indicating whether to separate results with new-lines."
>> > - :group 'dired-duplicates
>>
>> [...]
>>
>> Why should I not use :group for customization? I thought this makes it
>> easier to explore customization?
>
> It's redundant - see (info "(elisp) Variable Definitions"):
>
> If a ‘defcustom’ does not specify any ‘:group’, the last group
> defined with ‘defgroup’ in the same file will be used. This way,
> most ‘defcustom’ do not need an explicit ‘:group’.
>
> If :group is specified, it will most of the time mean the defcustom should
> be assigned to some other, not to the default, group. So it's better
> style to not explicitly specify the default.
One notable exception is if you have two groups defined in one file, and
you want to disambiguate the user options or avoid having to write these
in a specific order.
> Michael.
Harald Judt <h.judt@gmx.at> writes:
> On 2023-10-31 13:21, Philip Kaludercic wrote:
>
> [...]
>
>> @@ -225,7 +220,7 @@ This is the same as `dired-do-flagged-delete', but calls
>> (defvar dired-duplicates-map
>> (let ((map (make-sparse-keymap)))
>> - ;; workaround for Emacs bug #57565
>> + ;; workaround for Emacs bug#57565
>> (when (< emacs-major-version 29)
>> (define-key map (kbd "x") 'dired-duplicates--do-flagged-delete)
>> (define-key map (kbd "D") 'dired-duplicates--do-delete))
>
> BTW: What's the reasoning behind this suggested change?
I thought that this would be necessary for bug-reference-mode to work,
but apparently it can detect both of these references.
> Harald
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: emacs-devel@gnu.org
>> Date: Tue, 31 Oct 2023 12:21:51 +0000
>>
>> In the meantime, here is some quick and superficial feedback on the code:
>
> What I would like to ask is whether Harald tried to calculate SHA256
> using Emacs's own primitives, instead of relying on an external
> program, which may or may not be installed.
That is a good point, but I can imagine that one reason for using an
external tool is that if the user has a specific program they wish to
use that is not available as an Emacs primitive?
^ permalink raw reply [relevance 81%]
* 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: [ELPA] New package: dired-duplicates
@ 2023-10-31 12:21 47% ` Philip Kaludercic
0 siblings, 2 replies; 200+ results
From: Philip Kaludercic @ 2023-10-31 12:21 UTC (permalink / raw)
To: Harald Judt; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1422 bytes --]
Harald Judt <h.judt@gmx.at> writes:
> Hi,
>
> I have developed the following package and assigned copyright for it
> to the FSF and would now like to publish it to GNU ELPA (it has
> previously been published to MELPA):
>
> URL: https://codeberg.org/hjudt/dired-duplicates
>
> Description:
> This package helps to find duplicate files on local and remote filesystems.
> It is similar to the fdupes command-line utility but written in Emacs Lisp
> and should also work on every remote filesystem that TRAMP supports and
> where executable commands can be called remotely. The only external
> requirement is a checksum program like md5 or sha256sum that generates a
> hash value from the contents of a file used for comparison, because Emacs
> cannot do that in a performance-efficient way.
>
> dired-duplicates works by first searching files of the same size, then
> invoking the calculation of the checksum for these files, and presents the
> grouped results in a Dired buffer that the user can work with similarly to
> a regular Dired buffer.
> ----
>
> Could someone help me with the next steps?
Sure, I can take care of adding the package to the archive, you'll only
have to bump the "Version" header when you want the package to be
released (and in the future as well, the commit that touches the
"Version" header triggers a new release).
In the meantime, here is some quick and superficial feedback on the code:
[-- Attachment #2: Type: text/plain, Size: 6202 bytes --]
diff --git a/dired-duplicates.el b/dired-duplicates.el
index d62af02..4af37a3 100644
--- a/dired-duplicates.el
+++ b/dired-duplicates.el
@@ -54,7 +54,6 @@
(defcustom dired-duplicates-separate-results
t
"Boolean value indicating whether to separate results with new-lines."
- :group 'dired-duplicates
:tag "Separate results"
:type 'boolean)
@@ -64,7 +63,6 @@
The checksums will be used for comparison of files of the same
size."
- :group 'dired-duplicates
:tag "Checksum executable"
:type 'string)
@@ -73,10 +71,9 @@ size."
"The comparison function used for sorting grouped results.
The sorting can be in ascending (<) or descending (>) order."
- :group 'dired-duplicates
:tag "Ascending or descending file size sort order"
- :type '(choice (const :tag "Ascending" :value <)
- (const :tag "Descending" :value >)))
+ :type '(choice (const :tag "Ascending" <)
+ (const :tag "Descending" >)))
(defcustom dired-duplicates-file-filter-functions
nil
@@ -84,14 +81,12 @@ The sorting can be in ascending (<) or descending (>) order."
A filter function must accept as its single argument the file and
return boolean t if the file matches a criteria, otherwise nil."
- :group 'dired-duplicates
:tag "File filter functions"
:type 'hook)
(defcustom dired-duplicates-search-directories-recursively
t
"Search directories recursively."
- :group 'dired-duplicates
:tag "Search directories recursively"
:type 'boolean)
@@ -103,21 +98,22 @@ return boolean t if the file matches a criteria, otherwise nil."
The executable used is defined by `dired-duplicates-checksum-exec'."
(let* ((default-directory (file-name-directory (expand-file-name file)))
- (exec (executable-find dired-duplicates-checksum-exec t)))
+ (exec (executable-find dired-duplicates-checksum-exec t))
+ (file (expand-file-name (file-local-name file))))
(unless exec
- (user-error "Checksum program %s not found in exec-path" exec))
- (car (split-string
- (shell-command-to-string
- (concat exec " \"" (expand-file-name (file-local-name file)) "\""))
- nil
- t))))
+ (user-error "Checksum program %s not found in `exec-path'" exec))
+ (with-temp-buffer
+ (unless (zerop (call-process exec nil t nil file))
+ (error "Failed to start checksum program %s" exec))
+ (goto-char (point-min))
+ (if (looking-at "\\`[[:alnum:]]+")
+ (match-string 0)
+ (error "Unexpected output from checksum program %s" exec)))))
(defun dired-duplicates--apply-file-filter-functions (files)
"Apply file filter functions to FILES, returning the resulting list."
- (if (and dired-duplicates-file-filter-functions files)
- (dolist (filter-func dired-duplicates-file-filter-functions files)
- (setf files (cl-delete-if-not filter-func files)))
- files))
+ (dolist (filter-func dired-duplicates-file-filter-functions files)
+ (setf files (cl-delete-if-not filter-func files))))
(defun dired-duplicates--find-and-filter-files (directories)
"Search below DIRECTORIES for duplicate files.
@@ -140,14 +136,14 @@ duplicate files as values."
(append (gethash size same-size-table) (list f)))
finally
(cl-loop for same-size-files being the hash-values in same-size-table
- if (> (length same-size-files) 1) do
+ if (> (length same-size-files) 1) do ;see length>
(cl-loop for f in same-size-files
for checksum = (dired-duplicates-checksum-file f)
do (setf (gethash checksum checksum-table)
(append (gethash checksum checksum-table) (list f)))))
(cl-loop for same-files being the hash-value in checksum-table using (hash-key checksum)
do
- (if (> (length same-files) 1)
+ (if (cdr same-files) ;(> (length same-files) 1) in O(1)
(setf (gethash checksum checksum-table)
(cons (file-attribute-size (file-attributes (car same-files)))
(sort same-files #'string<)))
@@ -180,7 +176,6 @@ Currently, this simply adds a new-line after each results group."
for len in lengths
do
(forward-line len)
- ;; (forward-line len)
(let ((inhibit-read-only t))
(beginning-of-line)
(unless (= (point) (point-max))
@@ -225,7 +220,7 @@ This is the same as `dired-do-flagged-delete', but calls
(defvar dired-duplicates-map
(let ((map (make-sparse-keymap)))
- ;; workaround for Emacs bug #57565
+ ;; workaround for Emacs bug#57565
(when (< emacs-major-version 29)
(define-key map (kbd "x") 'dired-duplicates--do-flagged-delete)
(define-key map (kbd "D") 'dired-duplicates--do-delete))
@@ -248,7 +243,7 @@ The results will be shown in a Dired buffer."
default-directory)))
(unless directories
(user-error "Specify one or more directories to search in"))
- (let* ((directories (if (listp directories) directories (list directories)))
+ (let* ((directories (if (listp directories) directories (list directories))) ;see `ensure-list'
(truncated-dirs (truncate-string-to-width (string-join directories ", ") 40 0 nil t)))
(message "Finding duplicate files in %s..." truncated-dirs)
(if-let ((default-directory "/")
@@ -257,7 +252,7 @@ The results will be shown in a Dired buffer."
(message "Finding duplicate files in %s completed." truncated-dirs)
(dired (cons "/" (flatten-list results)))
(set-keymap-parent dired-duplicates-map (current-local-map))
- (setf (current-local-map) dired-duplicates-map)
+ (use-local-map dired-duplicates-map)
(setq-local dired-duplicates-directories directories)
(setq-local revert-buffer-function 'dired-duplicates-dired-revert)
(dired-duplicates--post-process-dired-buffer results))
[-- Attachment #3: Type: text/plain, Size: 44 bytes --]
> Regards,
> Harald
--
Philip Kaludercic
^ permalink raw reply related [relevance 47%]
* Re: ELPA submission: drepl (REPL protocol)
@ 2023-10-31 9:08 76% ` Philip Kaludercic
2023-11-07 8:20 99% ` Philip Kaludercic
0 siblings, 2 replies; 200+ results
From: Philip Kaludercic @ 2023-10-31 9:08 UTC (permalink / raw)
To: Augusto Stoffel; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 762 bytes --]
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:
[-- Attachment #2: Type: text/plain, Size: 1738 bytes --]
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"))
;; This program is free software; you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
@@ -49,7 +51,7 @@
(defface drepl-prompt-incomplete '((t :inherit (comint-highlight-prompt default)))
"Face for continuation prompts when input is incomplete but valid.")
-(defface drepl-prompt-invalid '((t :inherit (error default)))
+(defface drepl-prompt-invalid '((t :inherit (error default))) ;why both?
"Face for continuation prompts when input is invalid.")
(defcustom drepl-directory #'drepl--project-directory
@@ -68,6 +70,8 @@ buffers, this is the dREPL buffer or nil.")
;;; Basic definitions
+;; Are classes needed here or could you use `cl-defstruct' with
+;; `:include'?
(defclass drepl-base ()
((buffer :initarg :buffer :reader drepl--buffer)
(status :initform nil :accessor drepl--status)
@@ -96,6 +100,8 @@ The message is formed by calling `format' with FMTSTRING and ARGS."
;;; Communication protocol
+;; 1. Mention /what/ is not available.
+;; 2. why not fall back to json.el?
(defalias 'drepl--json-decode
(if (json-available-p)
(lambda (s)
@@ -413,7 +419,7 @@ if needed."
(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
(cl-defgeneric drepl--init (repl)
"Initialization code for REPL.
[-- Attachment #3: Type: text/plain, Size: 23 bytes --]
--
Philip Kaludercic
^ permalink raw reply related [relevance 76%]
* Re: ELPA submission: plz-see
@ 2023-10-31 8:43 79% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-10-31 8:43 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Augusto Stoffel, emacs-devel
[-- Attachment #1: Type: text/plain, Size: 274 bytes --]
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Augusto Stoffel <arstoffel@gmail.com>
>> Date: Mon, 30 Oct 2023 08:17:30 +0100
>>
>> I would like to submit the following package to ELPA:
>>
>> https://github.com/astoff/plz-see.el
Loks good, I only have a few comments:
[-- Attachment #2: Type: text/plain, Size: 1492 bytes --]
diff --git a/plz-see.el b/plz-see.el
index 2e5451f..74d62b1 100644
--- a/plz-see.el
+++ b/plz-see.el
@@ -4,6 +4,8 @@
;; Author: Augusto Stoffel <arstoffel@gmail.com>
;; Keywords: comm, network, http
+;; Version: 1.0.0
+;; Package-Requires: ((emacs "29.1"))
;; This program is free software; you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
@@ -20,10 +22,12 @@
;;; Commentary:
-;;
+;; Please write a brief commentary section, that is useful when
+;; querying the package from a `describe-package' buffer.
;;; Code:
+(eval-when-compile (require 'cl-lib))
(require 'json)
(require 'plz)
@@ -57,7 +61,7 @@ If nil, never delete old response buffers."
(defcustom plz-see-display-action nil
"The ACTION argument `plz-see' passes to `display-buffer'."
- :type 'sexp)
+ :type display-buffer--action-custom-type)
(defcustom plz-see-header-line-format
(let ((headers '(plz-see-header-line-status
@@ -181,7 +185,7 @@ call and AS specifies the argument type they expect."
('response response)
('buffer buffer)
((or 'binary 'string 'file `(file ,_))
- (user-error "plz-see does not accept :as %s" as))
+ (user-error "`plz-see' does not accept :as %s" as))
((pred functionp)
(with-temp-buffer
(insert (plz-response-body response))
[-- Attachment #3: Type: text/plain, Size: 617 bytes --]
>> It is an interactive HTTP client in the sense that request responses are
>> pretty-printed in a pop-up buffer. It is useful e.g. to test REST APIs.
>
> I wonder if you could come up with a name that tells something about
> the package's purpose. "plz-see" tells me "please see", and I don't
> see any relation to HTTP, REST, pretty-printing, or popup buffers.
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?
--
Philip Kaludercic
^ permalink raw reply related [relevance 79%]
* 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] 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: 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: [External] : Re: Updating *Completions* as you type
@ 2023-10-20 7:45 88% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-10-20 7:45 UTC (permalink / raw)
To: Drew Adams; +Cc: Spencer Baugh, emacs-devel@gnu.org
Drew Adams <drew.adams@oracle.com> writes:
> I'm not asking you, or anyone, to use Icicles.
> Unfortunately, talking about its features can
> perhaps give the opposite impression.
I didn't understand it that way either, my I just wanted to point out
that my impressions is that people miss out on even trying your packages
out, because they aren't distributed on any standard archive. The
reason they aren't distributed on GNU or NonGNU ELPA is that you
overwrite built-in definitions -- hence my question: Are you sure this
is necessary, since if not and you could change them, your packages
could be added to GNU/NonGNU ELPA and more people could profit from your
work.
> As I tried to make clear in my posts, their aim
> was to mention various Icicles features I think
> are relevant to this thread - not to advertise
> Icicles or suggest its use.
>
> The point was to encourage consideration of such
> or similar features as useful and perhaps worth
> adding to vanilla Emacs. Nothing more.
>
> Icicles is just a reference point here. Its doc
> about such features might hopefully provide some
> food for thought. _What users can do_ is the
> point, not how such features can be implemented.
>
> It's good to see others coming around to similar
> feature ideas now. Knowledge that such features
> work _in combination_, and they have done so for
> quite a while, should be helpful, I hope.
I might be mistaken, but the reason I thought your were "advertising"
Icicles, was that you usually respond to the suggestion to add some
feature with something like "Icicles had this feature since 200X".
> ___
>
> Wrt la petite histoire -
>
> To my knowledge, the first appearance of any
> incremental completion was in icomplete-mode.
> But that wasn't a completion whose result you
> could _use_; it was only completion you could
> _see_ (and only a few completions). You could
> use it only as a guide/preview of what you could
> then type. (Much later, completion of input was
> finally added to icomplete-mode.)
>
> Next was IswitchB, which later became the model
> for Ido. Completion candidates were shown only
> in the minibuffer (and again, only a few) - no
> use of *Completions* to show candidates.
>
> Icicles came after icomplete-mode and IswitchB,
> and before Ido. It introduced incremental
> completion showing candidates in *Completions*;
> cycling among candidates (notion of "current"
> candidate); on-the-fly sorting of them; etc.
The copyright files indicate this chronology:
icomplete: 1992
icicles: 1995
iswitchb: 1996
ido: 1996
^ permalink raw reply [relevance 88%]
* Re: [ELPA] New package: dape
@ 2023-10-19 15:12 97% ` Philip Kaludercic
2023-11-01 16:50 99% ` Philip Kaludercic
2 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-10-19 15:12 UTC (permalink / raw)
To: Daniel Pettersson; +Cc: emacs-devel
Daniel Pettersson <daniel@dpettersson.net> writes:
> On Sat, Oct 14, 2023 at 4:54 PM Philip Kaludercic <philipk@posteo.net> wrote:
>
>> I have tried to try it out right now, but because I've never used DAP
>> before, I am not sure how to get it running properly. Nevertheless, I
>> think it would be useful to have something along these lines:
>
> Did you get working?
I haven't had the time to try since.
>> + (customize-variable 'dape-configs)
>
> Implemented
1+
>> Another interesting idea to pursue might be to have modular UIs.
>> Instead of splitting up the current Emacs frame, I think a minimalist,
>> more edebug-like interface would be nice, where variable values could be
>> displayed using overlays instead of having a separate buffer.
>
> Nice suggestion. I did try to implement a more minimalist interface with
> variable overlays.
>
> Which can be enabled with the following.
> (setq dape-inline-variables t)
> (setq dape-on-start-hooks nil)
This sounds great, I'll have to try it out at some point! It might be
nice to have this as a minor mode that you could enable with a hook or
as a global minor mode.
> Second screenshot in the README.org, it's more inline with edebug.
Just FYI these don't appear to be displayed on the GitHub page.
> But
> there is some issues with placement and variable lookup. The current
> implementation relies on regex and font lock to search for symbols.
> If that work could be offloaded to Eglot/lsp-mode via xref (*I don't
> know if lsp support it). But currently that is not possible because
> Eglot only supports looking up reference at point.
Have you contacted João?
>> Note that you don't need to add Compat just for `defvar-keymap', as you
>> could also just use the traditional method of defining a keymap instead:
>
> Fixed.
>
>> It just doesn't say that much, and I don't know if it is intended, but
>> the usual way I would read/pronounce it (rhyming with cape) wouldn't
>> immediately signal any relation to DAP. Note that you can use (elisp)
>> Shorthands to avoid writing out a longer name inside the file, in case a
>> longer name like debuger-adapter. It seems there is no package by the
>> name of "dbg"? If we are not interested in a self-descriptive and
>> memorable name, and would want to create a parallel to Eglot (IIRC Emacs
>> polyGLOT), perhaps something like based on "Emacs Debugger" (Egger?
>> Ebugger? Edebugger?) might be possible as well.
>
> "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.
While I like eldap, note that this doesn't have a direct connection to
Eglot -- which is /not/ Elgot.
> Personally I like eldap, probably because it feels familiar.
^ permalink raw reply [relevance 97%]
* Re: [External] : Re: Updating *Completions* as you type
@ 2023-10-16 9:25 68% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-10-16 9:25 UTC (permalink / raw)
To: Drew Adams; +Cc: Spencer Baugh, emacs-devel@gnu.org
Drew Adams <drew.adams@oracle.com> writes:
> FWIW:
>
> I'll mention some similar features in Icicles. They
> were introduced together from the outset (in 2005!),
> and have proven useful.
You have mentioned Icicles a number of times, and one of the main
reasons I have never tried it out is that it is not available on ELPA or
any kind of official repository. I believe wrote about this a while
back, but according to [0], the main issue remains that your libraries
overwrite Emacs primitives, as you mention in the main file:
--8<---------------cut here---------------start------------->8---
;; ***** NOTE: These EMACS PRIMITIVES have been REDEFINED in Icicles:
;;
;; `completing-read' - (See below and doc string.)
;; `display-completion-list' - (See below and doc string.)
;; `exit-minibuffer' - Remove *Completion* window.
;; `minibuffer-complete-and-exit' - Remove *Completion* window.
;; `read-file-name' - (See below and doc string.)
;; `read-from-minibuffer' - (See below and doc string.)
;; `read-string' - (See below and doc string.)
;;
;;
;; ***** NOTE: The following functions defined in `dabbrev.el' have
;; been REDEFINED in Icicles:
;;
;; `dabbrev-completion' - Use Icicles completion when you repeat
;; (`C-M-/').
;;
;;
;; ***** NOTE: The following functions defined in `lisp.el' have
;; been REDEFINED in Icicles:
;;
;; `lisp-complete-symbol' - Selects `*Completions*' window even if on
;; another frame.
;;
;;
;; ***** NOTE: The following functions defined in `mouse.el' have
;; been REDEFINED in Icicles:
;;
;; `mouse-choose-completion' - Return the number of the completion.
;;
;;
;; ***** NOTE: The following functions defined in `simple.el' have
;; been REDEFINED in Icicles:
;;
;; `choose-completion-string' -
;; Don't exit minibuffer after `lisp-complete-symbol' completion.
;; `completion-setup-function' - 1. Put faces on inserted string(s).
;; 2. Help on help.
;; `switch-to-completions' - Always selects `*Completions*' window.
;;
;; `next-history-element' (advised only) -
;; Depending on `icicle-default-value', select minibuffer
;; contents.
;;
;; `repeat-complex-command' - Use `completing-read' to read command.
;;
;; For descriptions of changes to this file, see `icicles-chg.el'.
--8<---------------cut here---------------end--------------->8---
Is this really necessary? Somehow all the other completion systems
appear to get by without these kinds of invasive changes, and it would
be a pity the barriers for trying out your package continue to be
unnecessarily high, if the functionality is so advanced. At the very
least it would be nice if you could have your own ELPA, perhaps hosted
on Emacs Wiki to distribute these packages in a more standardised way.
[0] https://www.emacswiki.org/emacs/icicles.el
--
Philip Kaludercic
^ permalink raw reply [relevance 68%]
* 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: [ELPA] New package: dape
@ 2023-10-15 14:12 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-10-15 14:12 UTC (permalink / raw)
To: James Thomas; +Cc: Daniel Pettersson, emacs-devel
James Thomas <jimjoe@gmx.net> writes:
> Philip Kaludercic wrote:
>
>>>> Also, sorry for bringing this up, but how married are you to the name?
>>> I'm not overly attached to it. What are your objections? And do you have
>>> any suggestions? I find it quite difficult to name things like this.
>>
>> It just doesn't say that much, and I don't know if it is intended, but
>> the usual way I would read/pronounce it (rhyming with cape) wouldn't
>> immediately signal any relation to DAP. Note that you can use (elisp)
>> Shorthands to avoid writing out a longer name inside the file, in case a
>> longer name like debuger-adapter. It seems there is no package by the
>> name of "dbg"? If we are not interested in a self-descriptive and
>> memorable name, and would want to create a parallel to Eglot (IIRC Emacs
>> polyGLOT), perhaps something like based on "Emacs Debugger" (Egger?
>> Ebugger? Edebugger?) might be possible as well.
>
> There's also 'gudap':
>
> https://github.com/joaotavora/eglot/issues/716#issuecomment-895866818
That would make sense if the package was based on gud, but unless I
missed something that is not the case with Daniel's implementation.
That name would make sense when combining the existing GUD/GDB interface
with the DAP extension[0], as an alternative implementation for more
traditional users.
[0] https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=de7d7cb58e6209ed11c31f635545ee2ee6ded307
--
Philip Kaludercic
^ 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: [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: [ELPA] New package: dape
@ 2023-10-14 14:54 63% ` Philip Kaludercic
0 siblings, 2 replies; 200+ results
From: Philip Kaludercic @ 2023-10-14 14:54 UTC (permalink / raw)
To: Daniel Pettersson; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 403 bytes --]
Daniel Pettersson <daniel@dpettersson.net> writes:
> On Fri, Oct 13, 2023 at 2:24 PM Philip Kaludercic <philipk@posteo.net> wrote:
>> Very interesting!
> Thank you for your interest :)
I have tried to try it out right now, but because I've never used DAP
before, I am not sure how to get it running properly. Nevertheless, I
think it would be useful to have something along these lines:
[-- Attachment #2: Type: text/plain, Size: 1909 bytes --]
diff --git a/dape.el b/dape.el
index 3b27104..e24b0ea 100644
--- a/dape.el
+++ b/dape.el
@@ -2320,22 +2320,24 @@ If SKIP-FUNCTIONS function values are not called during evaluation."
(defun dape--read-config ()
"Read config name and options."
- (let ((candidate
- (completing-read "Dape config: "
- (append
- (mapcan
- (lambda (name-config)
- (let* ((config (cdr name-config))
- (modes (plist-get config 'modes)))
- (when (apply 'provided-mode-derived-p major-mode modes)
- (list (car name-config)))))
- dape-configs)
- dape--config-history)
- nil nil nil 'dape-history)))
- (if-let ((config
- (alist-get (intern candidate) dape-configs)))
- (list (intern candidate) config)
- (dape--config-from-string candidate))))
+ (if (null dape-configs)
+ (customize-variable 'dape-configs)
+ (let ((candidate
+ (completing-read "Dape config: "
+ (append
+ (mapcan
+ (lambda (name-config)
+ (let* ((config (cdr name-config))
+ (modes (plist-get config 'modes)))
+ (when (apply 'provided-mode-derived-p major-mode modes)
+ (list (car name-config)))))
+ dape-configs)
+ dape--config-history)
+ nil nil nil 'dape-history)))
+ (if-let ((config
+ (alist-get (intern candidate) dape-configs)))
+ (list (intern candidate) config)
+ (dape--config-from-string candidate)))))
\f
;;; Hover
[-- Attachment #3: Type: text/plain, Size: 1957 bytes --]
Another interesting idea to pursue might be to have modular UIs.
Instead of splitting up the current Emacs frame, I think a minimalist,
more edebug-like interface would be nice, where variable values could be
displayed using overlays instead of having a separate buffer.
>> Here are a few comments and suggestions I found from a brief skim over
>> the code:
> I made some updates based on your suggestions and added a todo for
> Compat.
Note that you don't need to add Compat just for `defvar-keymap', as you
could also just use the traditional method of defining a keymap instead:
--8<---------------cut here---------------start------------->8---
(defvar dape-global-map
(let ((map (make-sparse-keymap)))
(define-key map "d" #'dape)
;; ...
map))
--8<---------------cut here---------------end--------------->8---
> Couldn't bring myself to fix all of the checkdoc stuff, but made
> some improvments.
It is not urgent or in any way blocking inclusion to GNU ELPA, it is
just something I think one should keep in mind in the long-term to make
maintaining and contributing to the package easier.
>> Also, sorry for bringing this up, but how married are you to the name?
> I'm not overly attached to it. What are your objections? And do you have
> any suggestions? I find it quite difficult to name things like this.
It just doesn't say that much, and I don't know if it is intended, but
the usual way I would read/pronounce it (rhyming with cape) wouldn't
immediately signal any relation to DAP. Note that you can use (elisp)
Shorthands to avoid writing out a longer name inside the file, in case a
longer name like debuger-adapter. It seems there is no package by the
name of "dbg"? If we are not interested in a self-descriptive and
memorable name, and would want to create a parallel to Eglot (IIRC Emacs
polyGLOT), perhaps something like based on "Emacs Debugger" (Egger?
Ebugger? Edebugger?) might be possible as well.
^ permalink raw reply related [relevance 63%]
* 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: [ELPA] New package: dape
@ 2023-10-13 12:24 33% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-10-13 12:24 UTC (permalink / raw)
To: Daniel Pettersson; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 339 bytes --]
Daniel Pettersson <daniel@dpettersson.net> writes:
> This package integrates debug adapters within Emacs.
> Alternative to the well known package dap-mode.
Very interesting!
> See repository for code and more information https://github.com/svaante/dape
Here are a few comments and suggestions I found from a brief skim over
the code:
[-- Attachment #2: Type: text/plain, Size: 12223 bytes --]
diff --git a/dape.el b/dape.el
index 7ce7132..47a1b17 100644
--- a/dape.el
+++ b/dape.el
@@ -5,6 +5,7 @@
;; License: GPL-3.0-or-later
;; Version: 0.1
;; Homepage: https://github.com/svaante/dape
+;; Package-Requires: ((emacs "29.1"))
;; This file is not part of GNU Emacs.
@@ -55,7 +56,7 @@
(defcustom dape-configs nil
"This variable holds the Dape configurations as an alist.
In this alist, the car element serves as a symbol identifying each
-configuration. Each configuration, in turn, is a property list (plist)
+configuration. Each configuration, in turn, is a property list (plist)
where keys can be symbols or keywords.
Symbol Keys (Used by Dape):
@@ -72,13 +73,13 @@ Debug adapter connection in configuration:
- If only command is specified (without host and port), Dape
will communicate with the debug adapter through stdin/stdout.
- If both host and port are specified, Dape will connect to the
- debug adapter. If `command is specified, Dape will wait until the
+ debug adapter. If `command is specified, Dape will wait until the
command is initiated before it connects with host and port.
Keywords in configuration:
Keywords are transmitted to the adapter during the initialize and
- launch/attach requests. Refer to `json-serialize' for detailed
- information on how Dape serializes these keyword elements. Dape
+ launch/attach requests. Refer to `json-serialize' for detailed
+ information on how Dape serializes these keyword elements. Dape
uses nil as false.
Functions and symbols in configuration:
@@ -160,10 +161,10 @@ The hook is run with one argument, the compilation buffer."
(defcustom dape--debug-on
'(io info error std-server)
"Types of logs should be printed to *dape-debug*."
- :type '(list (const io :tag "dap IO")
- (const info :tag "info logging")
- (const error :tag "error logging")
- (const std-server :tag "dap tcp server stdout")))
+ :type '(list (const :tag "dap IO" io)
+ (const :tag "info logging" info)
+ (const :tag "error logging" error)
+ (const :tag "dap tcp server stdout" std-server)))
;;; Face
(defface dape-log-face
@@ -323,8 +324,8 @@ The hook is run with one argument, the compilation buffer."
default-directory)))
(defun dape-find-file (&optional default)
- (let* ((completion-ignored-extensions nil)
- (default-directory (funcall dape-cwd-fn)))
+ (let ((completion-ignored-extensions nil)
+ (default-directory (funcall dape-cwd-fn)))
(expand-file-name
(read-file-name (if default
(format "Program (default %s): " default)
@@ -387,8 +388,8 @@ The hook is run with one argument, the compilation buffer."
(symbol-name type))
'face 'match)
" "
- (apply 'format string objects)))
- (newline)))))
+ (apply 'format string objects))
+ "\n")))))
(defun dape--live-process (&optional nowarn)
(if (and dape--process
@@ -684,7 +685,7 @@ The hook is run with one argument, the compilation buffer."
(defun dape--stack-trace (process thread cb)
(cond
((or (plist-get (dape--current-thread) :stackFrames)
- (not (numberp (plist-get thread :id))))
+ (not (numberp (plist-get thread :id)))) ;any number? including floats?
(funcall cb process))
(t
(dape-request process
@@ -840,7 +841,7 @@ The hook is run with one argument, the compilation buffer."
(cl-defmethod dape-handle-event (_process (_event (eql output)) body)
(let ((category (plist-get body :category)))
- (cond
+ (cond ;perhapse `pcase' would be nice
((equal category "stdout")
(dape--repl-insert-text (plist-get body :output)))
((equal category "stderr")
@@ -996,8 +997,7 @@ The hook is run with one argument, the compilation buffer."
(dape-request dape--process "restart" nil))
((and dape--name dape--config)
(dape dape--name dape--config))
- (t
- (user-error "Unable to derive session to restart."))))
+ ((user-error "Unable to derive session to restart"))))
(defun dape-kill ()
"Kill debug session."
@@ -1164,7 +1164,7 @@ Executes launch `dape-configs' with :program as \"bin\"."
(seq-reduce (apply-partially 'apply 'plist-put)
(seq-partition options 2)
(copy-tree base-config))))
- (when (called-interactively-p)
+ (when (called-interactively-p 'interactive)
(push (dape--config-to-string name
base-config
config)
@@ -1232,13 +1232,9 @@ Watched symbols are displayed in *dape-info* buffer.
;;; Memory viewer
(defun dape--address-to-number (address)
- (cond
- ((and (> (length address) 2)
- (equal "0x" (substring address 0 2)))
- (string-to-number (string-trim-left address "0x0*")
- 16))
- (t
- (string-to-number address))))
+ (if (string-match "\\`0x\\([[:alnum:]]+\\)" address)
+ (string-to-number (match-string 1 address) 16)
+ (string-to-number address)))
(defun dape-read-memory (memory-reference count)
"Read COUNT bytes of memory at MEMORY-REFERENCE."
@@ -1796,10 +1792,12 @@ See `dape-info' for more information."
desktop-save-buffer nil
tree-widget-image-enable nil))
-(defun dape-info ()
+(defun dape-info (&optional select-buffer)
"Create or select *dape-info* buffer.
-Buffer contains debug session information."
- (interactive)
+Buffer contains debug session information. If the optional
+argument SELECT-BUFFER is nil, or the command is not invoked
+interactively, then the buffer is not displayed." ;perhaps rephrase this
+ (interactive (list t))
(let ((buffer (get-buffer-create "*dape-info*"))
window)
(with-current-buffer buffer
@@ -1867,7 +1865,8 @@ Buffer contains debug session information."
(setq window (display-buffer buffer
'((display-buffer-in-side-window)
. ((side . left)))))
- (when (called-interactively-p)
+
+ (when select-buffer
(select-window window)
(goto-char (point-min)))))
@@ -1882,32 +1881,31 @@ Buffer contains debug session information."
(dape--repl-insert-text-guard
(run-with-timer 0.1 nil 'dape--repl-insert-text msg))
(t
- (progn
- (setq dape--repl-insert-text-guard t)
- (when-let ((buffer (get-buffer "*dape-repl*")))
- (with-current-buffer buffer
- (save-excursion
- (condition-case err
- (progn
- (goto-char (point-max))
- (comint-previous-prompt 0)
- (forward-line -1)
- (end-of-line)
- (when-let (line (thing-at-point 'line))
- (when (eq (aref line 0) ?>)
- (let ((inhibit-read-only t))
- (insert "\n"))))
- (let ((inhibit-read-only t))
- (insert (propertize msg 'font-lock-face face))))
- (error
- (setq dape--repl-insert-text-guard nil)
- (signal (car err) (cdr err))))
- (setq dape--repl-insert-text-guard nil))))
- (unless (get-buffer-window "*dape-repl*")
- (when (stringp msg)
- (message (format "%s"
- (string-trim msg "\\\n" "\\\n"))
- 'face face)))))))
+ (setq dape--repl-insert-text-guard t)
+ (when-let ((buffer (get-buffer "*dape-repl*")))
+ (with-current-buffer buffer
+ (save-excursion
+ (condition-case err
+ (progn
+ (goto-char (point-max))
+ (comint-previous-prompt 0)
+ (forward-line -1)
+ (end-of-line)
+ (when-let (line (thing-at-point 'line))
+ (when (eq (aref line 0) ?>)
+ (let ((inhibit-read-only t))
+ (insert "\n"))))
+ (let ((inhibit-read-only t))
+ (insert (propertize msg 'font-lock-face face))))
+ (error
+ (setq dape--repl-insert-text-guard nil)
+ (signal (car err) (cdr err))))
+ (setq dape--repl-insert-text-guard nil))))
+ (unless (get-buffer-window "*dape-repl*")
+ (when (stringp msg)
+ (message (format "%s"
+ (string-trim msg "\\\n" "\\\n"))
+ 'face face))))))
(defun dape--repl-input-sender (dummy-process input)
(let (cmd)
@@ -2050,7 +2048,7 @@ Buffer contains debug session information."
:group 'dape
:interactive nil
(when dape-repl-mode
- (user-error "`dape-repl-mode' all ready enabled."))
+ (user-error "`dape-repl-mode' all ready enabled"))
(setq-local dape-repl-mode t
comint-prompt-read-only t
comint-input-sender 'dape--repl-input-sender
@@ -2099,7 +2097,7 @@ Empty input will rerun last command.\n\n\n"
display-buffer-in-side-window)
. ((side . bottom)
(slot . -1)))))
- (when (called-interactively-p)
+ (when (called-interactively-p) ;‘called-interactively-p’ called with 0 arguments, but requires 1!
(select-window window)))))
\f
@@ -2131,14 +2129,14 @@ Empty input will rerun last command.\n\n\n"
(defun dape--config-from-string (str)
(let (name read-config base-config)
(when (string-empty-p str)
- (user-error "Expected config name."))
+ (user-error "Expected config name"))
(setq name (read str)
base-config (copy-tree (alist-get name dape-configs))
str (substring str (length (symbol-name name))))
(unless (string-empty-p str)
(setq read-config (read (format "(%s)" str))))
(unless (plistp read-config)
- (user-error "Unexpected config format, see `dape-configs'."))
+ (user-error "Unexpected config format, see `dape-configs'"))
(cl-loop for (key value) on read-config by 'cddr
do (setq base-config (plist-put base-config key value)))
(list name base-config)))
@@ -2153,8 +2151,7 @@ Empty input will rerun last command.\n\n\n"
(let ((config-diff (dape--config-diff pre-eval-config
post-eval-config)))
(concat (format "%s" name)
- (when-let ((config-str (and config-diff
- (prin1-to-string config-diff))))
+ (and-let* ((config-diff) (config-str (prin1-to-string config-diff)))
(format " %s"
(substring config-str
1
@@ -2181,6 +2178,7 @@ Empty input will rerun last command.\n\n\n"
;;; Hover
(defun dape-hover-function (cb)
+ ;; Please consider addressing checkdoc issues like those raised here.
(when-let ((symbol (thing-at-point 'symbol)))
(dape--evaluate-expression (dape--live-process)
(plist-get (dape--current-stack-frame) :id)
@@ -2232,6 +2230,8 @@ Empty input will rerun last command.\n\n\n"
\f
;;; Keymaps
+;; this raises the minimum version to 29.1, but you could take a look
+;; at Compat to avoid this
(defvar-keymap dape-global-map
:doc "Keymap to repeat dape commands. Used in `repeat-mode'."
"d" #'dape
@@ -2251,6 +2251,8 @@ Empty input will rerun last command.\n\n\n"
"w" #'dape-watch-dwim
"q" #'dape-quit)
+;; Why are you mapping over the keymap, instead of just iterating over
+;; the command you want to mark as repeatable?
(map-keymap-internal (lambda (_ cmd)
(unless (memq cmd '(dape
dape-repl
[-- Attachment #3: Type: text/plain, Size: 72 bytes --]
Also, sorry for bringing this up, but how married are you to the name?
^ permalink raw reply related [relevance 33%]
* Re: [package-vc] Consider cleaning up files from install process
@ 2023-10-07 13:31 69% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-10-07 13:31 UTC (permalink / raw)
To: Adam Porter; +Cc: Joseph Turner, Emacs Devel Mailing List
Adam Porter <adam@alphapapa.net> writes:
> Hi Philip,
>
> On 9/20/23 03:13, Philip Kaludercic wrote:
>
>>> IMHO that seems like a sort of user-error, to leave uncommitted
>>> changes in a repo that's under the control of a system that doesn't
>>> take such changes into account when operating on the repo. IOW, if I
>>> install a package with command package-FOO, I expect the files it
>>> makes to be under its purview, not mine; they are not my personal data
>>> files, but belong to Emacs and its package.el library, the same as if
>>> I used "M-x package-install".
>> I don't believe in these kinds of distinctions. I can change what I
>> want, the only question I have to keep in mind is what the chances of
>> loosing these changes is going to be.
>
> I think I understand what you mean. However, that seems to conflict
> with the idea of loading packages directly from git worktrees,
> regardless of their status. That is, when I install a package into my
> Emacs configuration, I intend for the version I installed to be
> available when I start Emacs, not whatever state I might have left the
> repository in when I last touched it. If I had last checked out an
> in-progress feature branch and then shut down my computer, I wouldn't
> want Emacs to attempt to load that next time.
It is not that I don't get your argument, I think it is a fair point; my
issue is that this ends up just being a discussion of anecdotal
use-cases. I can point out that if I check out a feature branch, I
would like to use it, that if I modify a function, I'd like to test it.
If I just want to hack on something that I am not using, I wouldn't be
using package-vc. But I suspect that this doesn't mean that much to
you, because we just have different workflows.
>>> To put it another way, it seems like a bit of an anti-pattern to
>>> develop a package that's stored in "~/.emacs.d/elpa"--that directory
>>> is supposed to be for installed packages' files, and it should be safe
>>> to wipe that directory out at any time and reinstall packages from
>>> their sources--after all,
>> Is that documented anywhere? I know it can be done, if your
>> configuration is written accordingly, but if you see installed packages
>> as not being part of your domain, then transgressing layers of
>> abstraction and accessing, then deleting the "internal" representation
>> of package.el would seem to also be wrong?
>
> I don't know if that idea is documented anywhere, but it seems
> implicit to me by reason of users not necessarily needing to be aware
> of what files and directories get created when installing a package.
> If a user only used the package-install and package-delete commands,
> and didn't look at the filesystem or messages output, he wouldn't know
> nor care where the packages' files were.
I don't think I agree. Just because a user doesn't know what "apt
install coreutils" does, doesn't mean that the system should have to be
resilient to a "rm -rf {,/usr{,/local}}/bin". It would be a different
matter if the user could reasonably assume that elpa/ is a cache
directory, but I don't see why that should be the case.
> (I regularly advocate
> committing one's "elpa/" directory to git along with one's "init.el",
> and in so doing I've learned how many users aren't aware of how it all
> works.)
That is something i wouldn't recommend, but mostly because I avoid
adding auto-generated files to a git repository.
>>>> Can you describe the interface you are imagining. From what I
>>>> understand, it should be possible to reproduce what you need by
>>>> combining `package-vc-checkout' and `package-install-file'?
>>>
>>> Well, I would expect it to act similarly to Quelpa:
>>>
>>> 1. Clone the git repo (shallowly, at least by default) to a directory
>>> (perhaps a temporary one, but at least one stored in the appropriate
>>> XDG cache directory, outside of user-emacs-directory).
>>>
>>> 2. Call package-install-file on that worktree.
>>>
>>> 3. The package ends up installed into package-user-dir as if it were
>>> installed with package-install from ELPA.
>> How does this look like:
>> --8<---------------cut here---------------start------------->8---
>> (defun package-vc-install-copy (pkg-desc)
>> "Fetch the package sources of PKG-DESC and install a copy."
>> (interactive (list (package-vc--read-package-desc "Fetch package source: ")))
>> (let* ((copy (copy-package-desc pkg-desc))
>> (package-dir (expand-file-name
>> (symbol-name (package-desc-name pkg-desc))
>> (make-temp-file "package-vc-" t)))
>> (package-vc-register-as-project nil))
>> (setf (package-desc-dir copy) package-dir)
>> (save-window-excursion
>> (package-vc-checkout pkg-desc package-dir)
>> (package-install-from-buffer))))
>> --8<---------------cut here---------------end--------------->8---
>> I'd ideally pass :last-release to package-vc-checkout, but I have
>> detected a bug with this setup that should be fixed.
>
> I tested that command in a clean Emacs 29.1, and it seems to work
> well. Thanks.
>
> The only suggestion I have would be for an optional persistent
> directory used for keeping the git repositories around as a cache
> (i.e. outside of user-emacs-directory, likely in $XDG_CACHE_HOME), so
> that when upgrading the package, the whole repo wouldn't need to be
> cloned again, e.g. Quelpa configures this in the `quelpa-dir' option.
Currently I wouldn't want to add this to package-vc itself, but I could
imagine adding a package to ELPA that would provide the functionality
with all the related user option.
>> The main question I have is what advantage or disadvantage this would
>> provide over Quelpa? The functionality you describe misses the point of
>> what I see to be the point of package-vc, as it wasn't written to be a
>> replacement of Straight or Quelpa (I have never used either of the two),
>> but just as a tool to streamline fetching and preparing packages
>> directly from source code repositories.
>
> The advantage over Quelpa would simply be to not require Quelpa. :)
> I'd like for this functionality to be built-in to Emacs. I thought
> that's what package-vc was basically intended to do (i.e. give a user
> a git repo URL and he can install the package into his Emacs with a
> single command, as if he had cloned it manually and ran
> package-install on it), but maybe I misunderstood.
The background for package-vc is that it is a further iteration on my
site-lisp package. I wrote that to automatically manage (add to
`load-path', byte-compile, scrape for autoloads) my packages, that I
load directly from their Git repositories, because I want M-x
find-function to work. Following Stefan Monnier advice, the approach
with package-vc was to delegate loading the package.el, and add an
alternative "back-end" for fetching packages + means for contributing
local changes back upstream (package-vc-prepare-patch, and why
package-vc-install fetches an index of package specifications from ELPA
servers). Installing packages that are not listed in GNU or NonGNU ELPA
is neat, but not my focus behind developing the package. That remains
streamlining the process of contributing to packages and hacking
directly on the code that is being loaded.
> Thanks for your help,
> Adam
^ permalink raw reply [relevance 69%]
* 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: [External] : Re: [NonGNU ELPA] Package suggestion: yeetube
@ 2023-10-06 8:59 88% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-10-06 8:59 UTC (permalink / raw)
To: Thanos Apollo; +Cc: Drew Adams, Daniel Martín, emacs-devel@gnu.org
Thanos Apollo <public@thanosapollo.com> writes:
> Drew Adams <drew.adams@oracle.com> writes:
>
>> How old? Emacs 20? What minimal version
>> does that package itself require? Does
>> it, itself, need some compat support...?
Emacs 24.4 is the current minimum version. This is currently the oldest
version that one can reasonably support without running into too many
edge-cases that are beyond the scope of the library, while also being
distributed in most supported, popular distributions.
> Philip will give you a more concrete answer, but according to the
> documentation:
>
> ```
> Requires: ((emacs "24.4") (compat "29.1.4.2"))
>
> There is no need to depend on ‘emacs 24.4’ specifically. One can
> choose any newer version, if features not provided by Compat
> necessitate
> it, for example bug fixes or UI improvements.
>
> In any file where compatibility forms are used, a
>
> (require 'compat)
>
> should be added early on. In packages which are part of Emacs
> itself
> and which want to take advantage of Compat, the ‘noerror’ flag should
> be
> specified: ‘(require 'compat nil 'noerror)’. In the future a minimal
> version of Compat may be added to the Emacs core, such that the
> ‘noerror’ flag will not be necessary anymore.
> ```
>
> Not sure, but maybe something like this is a valid use case?
>
> ``` emacs-lisp
> (compat-call defvar-keymap yeetube-mode-map
> :doc "Keymap for yeetube commands"
> "RET" #'yeetube-play
> ...
There is no need to use compat-call, if the function/macro was
introduced in a more recent version than the minimum version of Emacs
you wish to support. In other words, the point of `compat-call' is to
ensure the compatibility version of function is used, where the
signature was updated at some point (e.g. IIRC in Emacs 26.1 `assoc'
gained an optional TESTFN argument), but to avoid the complexity of
advising the default function with an updated signature, the API of
Compat allows/requires for developers to opt-in to new signatures.
> ``` -- Thanos Apollo
> https://thanosapollo.com
^ permalink raw reply [relevance 88%]
* 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: [NonGNU ELPA] Package suggestion: yeetube
@ 2023-10-04 15:22 99% ` Philip Kaludercic
0 siblings, 1 reply; 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: [NonGNU ELPA] New package: blueprint-ts-mode
@ 2023-10-02 10:20 67% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-10-02 10:20 UTC (permalink / raw)
To: Huan Thieu Nguyen; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 298 bytes --]
Huan Thieu Nguyen <nguyenthieuhuan@gmail.com> writes:
> Hi hi,
>
> I made a tree-sitter based mode for blueprint files
> <https://github.com/huanie/blueprint-ts-mode>. I'd like to add it to
> NonGNU ELPA.
>
> With best regards!
>
> Nguyen Thieu Huan
A few suggestions and comments from my side:
[-- Attachment #2: Type: text/plain, Size: 3045 bytes --]
diff --git a/blueprint-ts-mode.el b/blueprint-ts-mode.el
index 9a88399..d33e6d0 100644
--- a/blueprint-ts-mode.el
+++ b/blueprint-ts-mode.el
@@ -25,26 +25,34 @@
;;; Commentary:
;; Treesitter based major mode for editing Blueprint files.
-;; Blueprint is a new markup language for GTK4 user interfaces. For more information see <https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/>.
-;; This mode provides syntax highlighting, eglot integration and Treesitter based navigation.
+
+;; Blueprint is a new markup language for GTK4 user interfaces. For
+;; more information see
+;; <https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/>.
+;; This mode provides syntax highlighting, eglot integration and
+;; Treesitter based navigation.
;;; Code:
(require 'treesit)
-(require 'rx)
+(eval-when-compile (require 'rx))
(require 'eglot)
+(defgroup blueprint ()
+ "Tree-sitter support for Blueprint files."
+ :prefix "blueprint-ts-"
+ :group 'languages)
+
(defcustom blueprint-ts-mode-indent-offset 2
"Number of spaces for each indentation step in `json-ts-mode'."
- :version "29.1"
:type 'integer
- :safe 'integerp
- :group 'blueprint)
+ :safe #'integerp)
(defvar blueprint-ts-mode--keywords
'("menu" "item" "section" "styles" "using" "bind" "template")
"Blueprint keywords for tree-sitter font-locking.")
+;; Why a macro?
(defmacro blueprint-ts-mode--treesit-font-lock-rules (language &rest rules)
"Wrapper around `treesit-font-lock-rules'.
`LANGUAGE' is the treesitter language to use.
@@ -62,7 +70,7 @@
((node-is ")") parent-bol 0)
((node-is "]") parent-bol 0)
((n-p-gp "object" "child" "object_content")
- prev-sibling 0) ;; [child_type] indent
+ prev-sibling 0) ;; [child_type] indent (is this a meaningful comment?)
((parent-is "object_content") parent-bol blueprint-ts-mode-indent-offset)
((parent-is "template") parent-bol blueprint-ts-mode-indent-offset)
((parent-is "styles") parent-bol blueprint-ts-mode-indent-offset)
@@ -101,7 +109,6 @@
;;;###autoload
(define-derived-mode blueprint-ts-mode prog-mode "Blueprint"
"Blueprint major mode using treesitter."
- :group 'blueprint
(when (treesit-ready-p 'blueprint)
(treesit-parser-create 'blueprint)
;; Comments
@@ -118,7 +125,7 @@
(rx (or "template" "object" "menu")))
(setq-local treesit-sentence-type-regexp (rx (or "menu_attribute" "property")))
;; Font-lock
- (setq-local treesit-font-lock-level 4)
+ (setq-local treesit-font-lock-level 4) ;isn't this a user option?
(setq-local treesit-font-lock-feature-list
'((comment variable)
(string keyword type)
@@ -128,9 +135,8 @@
(treesit-major-mode-setup)))
(add-to-list 'auto-mode-alist '("\\.blp\\'" . blueprint-ts-mode))
-(add-to-list 'eglot-server-programs
+(add-to-list 'eglot-server-programs ;is there some way around having to load Eglot?
'(blueprint-ts-mode . ("blueprint-compiler" "lsp")))
-
(provide 'blueprint-ts-mode)
;;; blueprint-ts-mode.el ends here
^ permalink raw reply related [relevance 67%]
* Re: package-vc support for :files keyword
@ 2023-09-27 14:03 67% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-09-27 14:03 UTC (permalink / raw)
To: Tony Zorman; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1167 bytes --]
Tony Zorman <tonyzorman@mailbox.org> writes:
> On Sun, Sep 24 2023 16:31, Philip Kaludercic wrote:
>> Tony Zorman <tonyzorman@mailbox.org> writes:
>>
>>> On Wed, Sep 20 2023 07:32, Philip Kaludercic wrote:
>>>> + (unless (string-match-p ignored-files file)
>>>
>>> One thing that did jump out to me just now, which I hadn't considered
>>> before: when ignored-files is the empty string, this will always match
>>> any file—not what we want :)
>>
>> Do you mean because the empty glob expression doesn't match everything,
>> but the empty regular expression does?
>>
>> The easiest solution seems to be to just check if the empty string is
>> listed and handle that separately (whatever the correct behaviour is in
>> that case), but on the other hand, why should a user list an empty
>> string in the list of ignored files?
>
> The point I was making was that `(mapconcat (λ…) nil) ≡ ""`, since
> mapconcat always returns a string. Even if there were no :ignored-files
> listed, the ignored-files variable would then be the empty string,
> matching each and every file.
Oops, right, in that case this should be preferable:
[-- Attachment #2: Type: text/plain, Size: 3287 bytes --]
diff --git a/lisp/emacs-lisp/package-vc.el b/lisp/emacs-lisp/package-vc.el
index a8393cb7e75..d100e0bcb58 100644
--- a/lisp/emacs-lisp/package-vc.el
+++ b/lisp/emacs-lisp/package-vc.el
@@ -213,7 +213,7 @@ package-vc--desc->spec
name for PKG-DESC."
(alist-get
(setq name (or name (package-desc-name pkg-desc)))
- (if (and (package-desc-archive pkg-desc)
+ (if (and pkg-desc (package-desc-archive pkg-desc)
(not (alist-get name package-vc-selected-packages
nil nil #'string=)))
(alist-get (intern (package-desc-archive pkg-desc))
@@ -501,7 +501,8 @@ package-vc--unpack-1
autoloads, generating a package description file (used to
identify a package as a VC package later on), building
documentation and marking the package as installed."
- (let (missing)
+ (let ((pkg-spec (package-vc--desc->spec pkg-desc))
+ missing)
;; Remove any previous instance of PKG-DESC from `package-alist'
(let ((pkgs (assq (package-desc-name pkg-desc) package-alist)))
(when pkgs
@@ -510,17 +511,29 @@ package-vc--unpack-1
;; In case the package was installed directly from source, the
;; dependency list wasn't know beforehand, and they might have
;; to be installed explicitly.
- (let ((deps '()))
+ (let ((ignored-files
+ (if (plist-get pkg-spec :ignored-files)
+ (mapconcat
+ (lambda (ignore)
+ (wildcard-to-regexp
+ (if (string-match-p "\\`/" ignore)
+ (concat pkg-dir ignore)
+ (concat "*/" ignore))))
+ (plist-get pkg-spec :ignored-files)
+ "\\|")
+ regexp-unmatchable))
+ (deps '()))
(dolist (file (directory-files pkg-dir t "\\.el\\'" t))
- (with-temp-buffer
- (insert-file-contents file)
- (when-let* ((require-lines (lm-header-multiline "package-requires")))
- (thread-last
- (mapconcat #'identity require-lines " ")
- package-read-from-string
- package--prepare-dependencies
- (nconc deps)
- (setq deps)))))
+ (unless (string-match-p ignored-files file)
+ (with-temp-buffer
+ (insert-file-contents file)
+ (when-let* ((require-lines (lm-header-multiline "package-requires")))
+ (thread-last
+ (mapconcat #'identity require-lines " ")
+ package-read-from-string
+ package--prepare-dependencies
+ (nconc deps)
+ (setq deps))))))
(dolist (dep deps)
(cl-callf version-to-list (cadr dep)))
(setf missing (package-vc-install-dependencies (delete-dups deps)))
@@ -529,8 +542,7 @@ package-vc--unpack-1
missing)))
(let ((default-directory (file-name-as-directory pkg-dir))
- (pkg-file (expand-file-name (package--description-file pkg-dir) pkg-dir))
- (pkg-spec (package-vc--desc->spec pkg-desc)))
+ (pkg-file (expand-file-name (package--description-file pkg-dir) pkg-dir)))
;; Generate autoloads
(let* ((name (package-desc-name pkg-desc))
(auto-name (format "%s-autoloads.el" name))
^ permalink raw reply related [relevance 67%]
* 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: package-vc support for :files keyword
[not found] ` <87jzsgm82h.fsf@hyperspace>
@ 2023-09-24 14:31 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-09-24 14:31 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:
>> + (unless (string-match-p ignored-files file)
>
> One thing that did jump out to me just now, which I hadn't considered
> before: when ignored-files is the empty string, this will always match
> any file—not what we want :)
Do you mean because the empty glob expression doesn't match everything,
but the empty regular expression does?
The easiest solution seems to be to just check if the empty string is
listed and handle that separately (whatever the correct behaviour is in
that case), but on the other hand, why should a user list an empty
string in the list of ignored files?
--
Philip Kaludercic
^ 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: New tree-sitter mode: bison-ts-mode
@ 2023-09-22 20:40 81% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-09-22 20:40 UTC (permalink / raw)
To: Augustin Chéneau (BTuin); +Cc: emacs-devel
"Augustin Chéneau (BTuin)" <btuin@mailo.com> writes:
> Le 22/09/2023 à 09:38, Philip Kaludercic a écrit :
>> "Augustin Chéneau (BTuin)" <btuin@mailo.com> writes:
>> A few comments on the proposed file:
>>
>>> ;;; bison-ts-mode --- Tree-sitter mode for Bison -*- lexical-binding: t; -*-
>>>
>> Could you add the usual header information here?
>> ;; Copyright (C) 2022-2023 Free Software Foundation, Inc.
>> --8<---------------cut here---------------start------------->8---
>> ;; Author: Augustin Chéneau <btuin@mailo.com>
>> ;; This file is part of GNU Emacs.
>> ;; GNU Emacs is free software: you can redistribute it and/or modify
>> ;; it under the terms of the GNU General Public License as published by
>> ;; the Free Software Foundation, either version 3 of the License, or
>> ;; (at your option) any later version.
>> ;; GNU Emacs is distributed in the hope that it will be useful,
>> ;; but WITHOUT ANY WARRANTY; without even the implied warranty of
>> ;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> ;; GNU General Public License for more details.
>> ;; You should have received a copy of the GNU General Public License
>> ;; along with GNU Emacs. If not, see <https://www.gnu.org/licenses/>.
>> --8<---------------cut here---------------end--------------->8---
>>
>>> ;;; Commentary:
>>>
>>> ;; This is a mode based on tree-sitter for Bison and Yacc files, tools to generate parsers.
>> Shouldn't you mention what tree sitter grammar is being being used
>> here?
>>
>>> ;;; Code:
>>>
>>> (require 'treesit)
>>> (require 'c-ts-common)
>>>
>>> (declare-function treesit-parser-create "treesit.c")
>>> (declare-function treesit-induce-sparse-tree "treesit.c")
>>> (declare-function treesit-node-child-by-field-name "treesit.c")
>>> (declare-function treesit-search-subtree "treesit.c")
>>> (declare-function treesit-node-parent "treesit.c")
>>> (declare-function treesit-node-next-sibling "treesit.c")
>>> (declare-function treesit-node-type "treesit.c")
>>> (declare-function treesit-node-child "treesit.c")
>>> (declare-function treesit-node-end "treesit.c")
>>> (declare-function treesit-node-start "treesit.c")
>>> (declare-function treesit-node-string "treesit.c")
>>> (declare-function treesit-query-compile "treesit.c")
>>> (declare-function treesit-query-capture "treesit.c")
>>> (declare-function treesit-parser-add-notifier "treesit.c")
>>> (declare-function treesit-parser-buffer "treesit.c")
>>> (declare-function treesit-parser-list "treesit.c")
>>>
>>>
>>> (defgroup bison nil
>> bison or bison-ts?
>>
>
> As far as I know, no group is explicitly reserved for
> tree-sitter. rust-ts-mode uses the group "rust", java-ts-mode uses
> "java", ruby-ts-mode uses "ruby"...
OK, that is fine then.
>
>>> "Support for Bison and Yacc."
>> Shouldn't tree-sitter be mentioned here?
>>
> Same as above.
Sure? Above I was talking about using the group name "bison" or
"bison-ts", this is about mentioning that tree sitter is required for
the mode to work.
>>> :group 'languages)
>>>
>>> (defcustom bison-ts-mode-indent-offset 2
>>> "Number of spaces for each indentation step in `bison-ts-mode'.
>>> It has no effect in the epilogue part of the file."
>>> :version "30.1"
>>> :type 'integer
>>> :safe 'integerp
>>> :group 'bison)
>>>
>>> (defcustom bison-ts-mode-autodetect-language t
>>> "Search for a %language directive in the file at initialization.
>>> Changing the value of this directive in the file requires to reload the mode to
>>> be effective. If `bison-ts-mode-buffer-language' is set by a file-local
>>> variable, the auto-detection is not run."
>>> :version "30.1"
>>> :type 'boolean
>>> :safe 'boolean
>>> :group 'bison)
>>>
>>> (defvar-local bison-ts-mode-embedded-language nil
>>> "Embedded language in Bison buffer.")
>>>
>>> (defun bison-ts-mode--merge-feature-lists (l1 l2)
>>> "Merge the lists of lists L1 and L2.
>>> The first sublist of L1 is merged with the first sublist of L2 and so on.
>>> L1 and L2 don't need to have the same size."
>>> (let ((res ()))
>>> (while (or l1 l2)
>>> (setq res (push (append (car l1) (car l2)) res))
>>> (setq l1 (cdr l1) l2 (cdr l2)))
>>> (nreverse res)))
>> Is this a generic function that should be extracted into some common
>> file?
>>
> It probably should, it could be useful for other *-ts-mode that want
> to mix multiple languages, unless there already is such a function in
> Elisp.
Then again, if you use `cl-loop', you can reproduce this specific
behaviour using
(cl-loop for i1 in '(1 2 3) collect i1
for i2 in '(a b c) collect i2)
>
>>> (defun bison-ts-mode--find-language-in-buffer (&optional buffer)
>>> "Find and return the language set by the Bison directive %language.
>>> If BUFFER is set, search in this buffer, otherwise search in the current
>>> buffer."
>>> (save-excursion
>>> (when buffer
>>> (switch-to-buffer buffer))
>> Or rather?
>> (with-current-buffer (or buffer (current-buffer))
>> (save-excursion
>> ...))
>>
>>> (goto-char (point-min))
>>> (let ((pos-end
>>> (re-search-forward
>>> (rx
>>> bol (0+ blank) "%language" (0+ blank) "\"" (1+ (in alpha "+")) "\"")
>>> nil
>>> t))
>>> (pos-beg nil))
>>> (when pos-end
>> Using when-let might be nice here.
>>
>>> (goto-char (1- pos-end))
>>> (setq pos-beg (1+ (search-backward "\"" nil t)))
>>> (buffer-substring-no-properties pos-beg (1- pos-end))))))
>> I'd use a single regular expression here with a group, then extract
>> the
>> right information using `match-string'.
>>
> Nice, I didn't know it was possible.
>>>
>>>
>>> (defun bison-ts-mode--detect-language (&optional buffer)
>>> "Dectect the embedded language in a Bison buffer.
>>> Known languages are C, C++, D, and Java, but D is not supported as there is
>>> no support for tree-sitter D in Emacs yet.
>>> If BUFFER is set, search in this buffer, otherwise search in the current
>>> buffer."
>>> (if-let ((str (bison-ts-mode--find-language-in-buffer buffer)))
>>> (pcase (downcase str)
>>> ("c" 'c)
>>> ("c++" 'cpp)
>>> ("d" (progn (message "D language not yet supported") nil))
>> Each pcase case has an implicit progn.
>>
>>> ("java" 'java))
>>> (progn
>> Use when-let to avoid this progn.
>>
>>> (message
>>> "bison-ts-mode: %%language specification not found or invalid, defaulting to C.")
>> Is it necessary to prefix the message with the major mode name?
>>
> If feared it would be a bit cryptic without. Anyway I modified this
> function to only display a message if "%language" is present but the
> language is invalid, so it probably isn't necessary anymore.
OK.
>>> 'c)))
>>>
>>>
>>> (defun bison-ts-mode--language-at-point-function (position)
>>> "Return the language at POSITION."
>>> (let* ((node (treesit-node-at position 'bison)))
>> ^
>> let is enough
>>
>>> (if (equal (treesit-node-type node)
>>> "embedded_code")
>> There is no need to break the line here.
>>
>>> bison-ts-mode-embedded-language
>>> 'bison)))
>>>
>>> (defun bison-ts-mode--font-lock-settings (language)
>>> "Return the font-lock settings for Bison.
>>> LANGUAGE should be set to \\='bison."
>>> (treesit-font-lock-rules
>>> :language language
>>> :feature 'bison-comment
>>> '((comment) @font-lock-comment-face)
>>>
>>> :language language
>>> :feature 'bison-declaration
>>> '((declaration_name) @font-lock-keyword-face)
>>>
>>> :language language
>>> :feature 'bison-type
>>> '((type) @font-lock-type-face)
>>>
>>> :language language
>>> :feature 'bison-grammar-rule-usage
>>> '((grammar_rule_identifier) @font-lock-variable-use-face)
>>>
>>> :language language
>>> :feature 'bison-grammar-rule-declaration
>>> '((grammar_rule (grammar_rule_declaration)
>>> @font-lock-variable-use-face))
>>>
>>> :language language
>>> :feature 'bison-string
>>> :override t
>>> '((string) @font-lock-string-face)
>>>
>>> :language language
>>> :feature 'bison-literal
>>> :override t
>>> '((char_literal) @font-lock-keyword-face
>>> (number_literal) @font-lock-number-face)
>>>
>>> :language language
>>> :feature 'bison-directive-grammar-rule
>>> :override t
>>> '((grammar_rule (directive) @font-lock-keyword-face))
>>>
>>> :language language
>>> :feature 'bison-operator
>>> :override t
>>> '(["|"] @font-lock-operator-face)
>>>
>>> :language language
>>> :feature 'bison-delimiter
>>> :override t
>>> '([";"] @font-lock-delimiter-face)))
>>>
>>>
>>> (defvar bison-ts-mode--font-lock-feature-list
>>> '(( bison-comment bison-declaration bison-type
>>> bison-grammar-rule-usage bison-grammar-rule-declaration
>>> bison-string bison-literal bison-directive-grammar-rule
>>> bison-operator bison-delimiter)))
>>>
>>>
>>> (defun bison-ts-mode--bison-matcher-action (root-name)
>>> "Treesit matcher to check if NODE at BOL is not located in the epilogue.
>>> ROOT-NAME is the highest-level node of the embedded language."
>>> (lambda (node _parent bol &rest _)
>>> (if (equal (treesit-node-type (treesit-node-parent node)) root-name)
>>> (let* ((bison-node (treesit-node-at bol 'bison)))
>> ^
>> here again, let is enough
>> (if (equal
>>> (treesit-node-type
>>> (treesit-node-parent(treesit-node-parent bison-node))) "action")
>> Though you could bind the (treesit-node-type ...) expression under
>> the
>> above let.
>>
>>> t
>>> nil)))))
>> Why (if foo t nil) when foo would do the same job (equal only
>> returns
>> nil and t, so normalising the value isn't even necessary).
>>
> Because I was stupid.
OK, I am glad I didn't miss something obvious ^^
>>>
>>> (defun bison-ts-mode--bison-matcher-not-epilogue (root-name)
>>> "Treesit matcher to check if NODE at BOL is not located in the epilogue.
>>> ROOT-NAME is the highest-level node of the embedded language."
>>> (lambda (node _parent bol &rest _)
>>> (if (equal (treesit-node-type (treesit-node-parent node)) root-name)
>>> (let* ((bison-node (treesit-node-at bol 'bison)))
>>> (if (equal (treesit-node-type (treesit-node-parent bison-node)) "epilogue")
>>> nil
>>> t)))))
>> Am I missing something, or couldn't these two functions be merged if
>> you
>> give them a third argument NODE-TYPE and pass it "action" or "epilogue".
>>
> No, bison-ts-mode--bison-matcher-action checks if the _grandparent_ is
> an "action" node, while bison-ts-mode--bison-matcher-not-epilogue
> checks if the _parent_ is an "epilogue" node.
In that case, would adding another parameter and then binding the
returned lambda expression via defalias be worth the effort?
>>>
>>>
>>> (defun bison-ts-mode--bison-parent (_node _parent bol &rest _)
>>> "Get the parent of the bison node at BOL."
>>> (treesit-node-start (treesit-node-parent (treesit-node-at bol 'bison))))
>>>
>>>
>>> (defun bison-ts-mode--indent-rules ()
>>> "Indent rules supported by `bison-ts-mode'."
>>> (let*
>>> ((common
>>> `(((node-is "^declaration$")
>>> column-0 0)
>>> ((and (parent-is "^declaration$")
>>> (not (node-is "^code_block$")))
>>> column-0 2)
>>> ((and (parent-is "comment") c-ts-common-looking-at-star)
>>> c-ts-common-comment-start-after-first-star -1)
>>> (c-ts-common-comment-2nd-line-matcher
>>> c-ts-common-comment-2nd-line-anchor
>>> 1)
>>> ((parent-is "comment") prev-adaptive-prefix 0)
>>>
>>> ;; Opening and closing brackets "{}" of declarations
>>> ((and (parent-is "^declaration$")
>>> (node-is "^code_block$"))
>>> column-0 0)
>>> ((and (n-p-gp "}" "" "^declaration$"))
>>> column-0 0)
>>> ((parent-is "^declaration$") parent 2)
>>> ((node-is "^grammar_rule$") column-0 0)
>>> ((and
>>> (parent-is "^grammar_rule$")
>>> (node-is ";"))
>>> column-0 bison-ts-mode-indent-offset)
>>> ((and (parent-is "^grammar_rule$")
>>> (node-is "|"))
>>> column-0 bison-ts-mode-indent-offset)
>>> ((and (parent-is "^grammar_rule$")
>>> (not (node-is "^grammar_rule_declaration$"))
>>> (not (node-is "^action$")))
>>> column-0 ,(+ bison-ts-mode-indent-offset 2))
>>> ((or
>>> (node-is "^action$")
>>> (node-is "^}$"))
>>> column-0 12)
>>> ;; Set '%%' at the beginning of the line
>>> ((or
>>> (and (parent-is "^grammar_rules_section$")
>>> (node-is "%%"))
>>> (node-is "^grammar_rules_section$"))
>>> column-0 0)
>>> (no-node parent-bol 0))))
>>> `((bison . ,common)
>>> ;; Import and override embedded languages rules to add an offset
>>> ,(pcase bison-ts-mode-embedded-language
>>> ('c `(c
>>> ((bison-ts-mode--bison-matcher-action "translation_unit")
>>> bison-ts-mode--bison-parent ,bison-ts-mode-indent-offset)
>>> ((bison-ts-mode--bison-matcher-not-epilogue "translation_unit")
>>> column-0 ,bison-ts-mode-indent-offset)
>>> ,@(alist-get 'c (c-ts-mode--get-indent-style 'c))))
>>> ('cpp `(cpp
>>> ((bison-ts-mode--bison-matcher-action "translation_unit")
>>> bison-ts-mode--bison-parent ,bison-ts-mode-indent-offset)
>>> ((bison-ts-mode--bison-matcher-not-epilogue "translation_unit")
>>> parent-0 ,bison-ts-mode-indent-offset)
>>> ,@(alist-get 'cpp (c-ts-mode--get-indent-style 'cpp))))
>>> ('java `(java
>>> ((bison-ts-mode--bison-matcher-action "program")
>>> bison-ts-mode--bison-parent ,bison-ts-mode-indent-offset)
>>> ((bison-ts-mode--bison-matcher-not-epilogue "program")
>>> column-0 ,bison-ts-mode-indent-offset)
>>> ,@java-ts-mode--indent-rules))))))
>>>
>>>
>>> (define-derived-mode bison-ts-mode prog-mode "Bison"
>>> "A mode for Bison."
>> ^
>> major-mode
>> Also, mentioning tree-sitter seems like something worth doing.
>>
>>> (when (treesit-ready-p 'bison)
>>> (when (not bison-ts-mode-embedded-language)
>>> (setq bison-ts-mode-embedded-language (bison-ts-mode--detect-language)))
>>>
>>> ;; Require only if needed, to avoid warnings if a grammar is not
>>> ;; installed but not used.
>>> (pcase bison-ts-mode-embedded-language
>> Would a `pcase-exhaustive' be appropriate here?
>>
> No, the language D is recognized but not supported yet in Emacs, so if
> this language is detected it will not configure anything.
There is a d-mode in NonGNU ELPA, but I guess that isn't enough since
you need a d-ts-mode, right?
>>> ('c (require 'c-ts-mode))
>>> ('cpp (require 'c-ts-mode))
>>> ('java (require 'java-ts-mode)))
>>>
>>> (setq-local treesit-font-lock-settings
>>> (append (bison-ts-mode--font-lock-settings 'bison)
>>> (pcase bison-ts-mode-embedded-language
>>> ('c (c-ts-mode--font-lock-settings 'c))
>>> ('cpp (c-ts-mode--font-lock-settings 'cpp))
>>> ('java java-ts-mode--font-lock-settings))))
>>>
>>> (setq-local treesit-font-lock-feature-list
>>> (if bison-ts-mode-embedded-language
>>> (bison-ts-mode--merge-feature-lists
>>> bison-ts-mode--font-lock-feature-list
>>> (pcase bison-ts-mode-embedded-language
>>> ('c c-ts-mode--feature-list)
>>> ('cpp c-ts-mode--feature-list)
>>> ('java java-ts-mode--feature-list)))
>>> bison-ts-mode--font-lock-feature-list))
>>>
>>> (setq-local treesit-simple-imenu-settings
>>> `(("Grammar"
>>> "\\`grammar_rule_declaration\\'"
>>> nil
>>> (lambda (node) (substring-no-properties (treesit-node-text node))))))
>>>
>>> (c-ts-common-comment-setup)
>>>
>>> (setq-local treesit-simple-indent-rules
>>> (bison-ts-mode--indent-rules))
>>>
>>> (setq-local treesit-language-at-point-function 'bison-ts-mode--language-at-point-function)
>>>
>>> (when bison-ts-mode-embedded-language
>>> (setq-local treesit-range-settings
>>> (treesit-range-rules
>>> :embed bison-ts-mode-embedded-language
>>> :host 'bison
>>> :local t
>>> '((embedded_code) @capture))))
>>>
>>> (treesit-major-mode-setup)))
>>>
>>> (provide 'bison-ts-mode)
>>> ;;; bison-ts-mode.el ends here
>> Sorry for the number of comments, but there has been a discussion on
>> the
>> code-quality of tree-sitter major modes that has been less than optimal,
>> so I hope that your contribution could help raise the bar.
>
> No problem, thank you for your review!
[...]
>
> (defgroup bison-ts nil
> "Support for Bison and Yacc."
> :group 'languages)
>
> (defcustom bison-ts-mode-indent-offset 2
> "Number of spaces for each indentation step in `bison-ts-mode'.
> It has no effect in the epilogue part of the file."
> :version "30.1"
> :type 'integer
> :safe 'integerp
> :group 'bison)
The ":group" annotations here are not necessary in general, defcustoms
can automatically detect the previous defgroup.
> (defcustom bison-ts-mode-autodetect-language t
> "Search for a %language directive in the file at initialization.
> Changing the value of this directive in the file requires to reload the mode to
> be effective. If `bison-ts-mode-buffer-language' is set by a file-local
> variable, the auto-detection is not run."
> :version "30.1"
> :type 'boolean
> :safe 'boolean
> :group 'bison)
>
> (defvar-local bison-ts-mode-embedded-language nil
> "Embedded language in Bison buffer.
> Supported values are `c', `cpp', and `java'.")
> ;;;###autoload
> (put 'bison-ts-mode-embedded-language 'safe-local-variable 'symbolp)
>
>
> (defun bison-ts-mode--merge-feature-lists (l1 l2)
> "Merge the lists of lists L1 and L2.
> The first sublist of L1 is merged with the first sublist of L2 and so on.
> L1 and L2 don't need to have the same size."
> (let ((res ()))
> (while (or l1 l2)
> (setq res (push (seq-uniq (append (car l1) (car l2)) 'eq) res))
> (setq l1 (cdr l1) l2 (cdr l2)))
> (nreverse res)))
>
> (defun bison-ts-mode--find-language-in-buffer (&optional buffer)
> "Find and return the language set by the Bison directive %language.
> If BUFFER is set, search in this buffer, otherwise search in the current
> buffer."
> (save-excursion
> (with-current-buffer (or buffer (current-buffer))
> (goto-char (point-min))
> (when
> (re-search-forward
> (rx
> bol (0+ blank) "%language" (0+ blank) "\"" (group (1+ (in alpha "+"))) "\"")
I'd say this regular expression is complex enough to be split into
multiple lines. And you can use the fact that `rx' takes s-expressions
to add comments inbetween.
> nil
> t)))
> (substring-no-properties (match-string 1))))
Or `match-string-no-properties'
>
>
> (defun bison-ts-mode--detect-language (&optional buffer)
> "Dectect the embedded language in a Bison buffer.
> Known languages are C, C++, D, and Java, but D is not supported as there is
> no support for tree-sitter D in Emacs yet.
> If BUFFER is set, search in this buffer, otherwise search in the current
> buffer."
> (if-let ((str (bison-ts-mode--find-language-in-buffer buffer)))
> (pcase-exhaustive (downcase str)
> ("c" 'c)
> ("c++" 'cpp)
> ("d" (message "D language not yet supported") nil)
> ("java" 'java)
> (_ (message "%%language specification \"%s\" is invalid, defaulting to C" str) 'c))))
No point in using `pcase-exhaustive' if you end with _ anyway?
>
>
> (defun bison-ts-mode--language-at-point-function (position)
> "Return the language at POSITION."
> (let ((node (treesit-node-at position 'bison)))
> (if (equal (treesit-node-type node) "embedded_code")
> bison-ts-mode-embedded-language
> 'bison)))
>
> (defun bison-ts-mode--font-lock-settings (language)
> "Return the font-lock settings for Bison.
> LANGUAGE should be set to \\='bison."
> (treesit-font-lock-rules
> :language language
> :feature 'comment
> '((comment) @font-lock-comment-face)
>
> :language language
> :feature 'declaration
> '((declaration_name) @font-lock-keyword-face)
>
> :language language
> :feature 'type
> '((type) @font-lock-type-face)
>
> :language language
> :feature 'variable
> '((grammar_rule_identifier) @font-lock-variable-use-face)
>
> :language language
> :feature 'grammar-declaration
> '((grammar_rule (grammar_rule_declaration)
> @font-lock-variable-use-face))
>
> :language language
> :feature 'string
> :override t
> '((string) @font-lock-string-face)
>
> :language language
> :feature 'literal
> :override t
> '((char_literal) @font-lock-keyword-face
> (number_literal) @font-lock-number-face)
>
> :language language
> :feature 'directive-grammar-rule
> :override t
> '((grammar_rule (directive) @font-lock-keyword-face))
>
> :language language
> :feature 'operator
> :override t
> '(["|"] @font-lock-operator-face)
>
> :language language
> :feature 'delimiter
> :override t
> '([";"] @font-lock-delimiter-face)))
>
>
> (defvar bison-ts-mode--font-lock-feature-list
I am not that familiar with the tree-sitter stuff, but would it be
possible to use `defconst' here?
> '(( comment declaration grammar-declaration)
> ( type string directive-grammar-rule)
> ( literal)
> ( variable operator delimiter)))
>
>
> (defun bison-ts-mode--bison-matcher-action (root-name)
> "Treesit matcher to check if NODE at BOL is located in an action node.
> ROOT-NAME is the highest-level node of the embedded language."
> (lambda (node _parent bol &rest _)
> (if (equal (treesit-node-type (treesit-node-parent node)) root-name)
> (let ((bison-node (treesit-node-at bol 'bison)))
> (equal
> (treesit-node-type
> (treesit-node-parent (treesit-node-parent bison-node)))
> "action")))))
>
> (defun bison-ts-mode--bison-matcher-not-epilogue (root-name)
> "Treesit matcher to check if NODE at BOL is not located in the epilogue.
> ROOT-NAME is the highest-level node of the embedded language."
> (lambda (node _parent bol &rest _)
> (if (equal (treesit-node-type (treesit-node-parent node)) root-name)
> (let ((bison-node (treesit-node-at bol 'bison)))
> (not (equal (treesit-node-type (treesit-node-parent bison-node)) "epilogue"))))))
>
>
> (defun bison-ts-mode--bison-parent (_node _parent bol &rest _)
> "Get the parent of the bison node at BOL."
> (treesit-node-start (treesit-node-parent (treesit-node-at bol 'bison))))
>
>
> (defun bison-ts-mode--indent-rules ()
> "Indent rules supported by `bison-ts-mode'."
> (let*
> ((common
> `(((node-is "^declaration$")
> column-0 0)
> ((and (parent-is "^declaration$")
> (not (node-is "^code_block$")))
> column-0 2)
> ((and (parent-is "comment") c-ts-common-looking-at-star)
> c-ts-common-comment-start-after-first-star -1)
> (c-ts-common-comment-2nd-line-matcher
> c-ts-common-comment-2nd-line-anchor
> 1)
> ((parent-is "comment") prev-adaptive-prefix 0)
>
> ;; Opening and closing brackets "{}" of declarations
> ((and (parent-is "^declaration$")
> (node-is "^code_block$"))
> column-0 0)
> ((and (n-p-gp "}" "" "^declaration$"))
> column-0 0)
> ((parent-is "^declaration$") parent 2)
> ((node-is "^grammar_rule$") column-0 0)
> ((and
> (parent-is "^grammar_rule$")
> (node-is ";"))
> column-0 bison-ts-mode-indent-offset)
> ((and (parent-is "^grammar_rule$")
> (node-is "|"))
> column-0 bison-ts-mode-indent-offset)
> ((and (parent-is "^grammar_rule$")
> (not (node-is "^grammar_rule_declaration$"))
> (not (node-is "^action$")))
> column-0 ,(+ bison-ts-mode-indent-offset 2))
> ((or
> (node-is "^action$")
> (node-is "^}$"))
> column-0 12)
> ;; Set '%%' at the beginning of the line
> ((or
> (and (parent-is "^grammar_rules_section$")
> (node-is "%%"))
> (node-is "^grammar_rules_section$"))
> column-0 0)
> (no-node parent-bol 0))))
> `((bison . ,common)
> ;; Import and override embedded languages rules to add an offset
> ,(pcase bison-ts-mode-embedded-language
> ('c `(c
> ((bison-ts-mode--bison-matcher-action "translation_unit")
> bison-ts-mode--bison-parent ,bison-ts-mode-indent-offset)
> ((bison-ts-mode--bison-matcher-not-epilogue "translation_unit")
> column-0 ,bison-ts-mode-indent-offset)
> ,@(alist-get 'c (c-ts-mode--get-indent-style 'c))))
> ('cpp `(cpp
> ((bison-ts-mode--bison-matcher-action "translation_unit")
> bison-ts-mode--bison-parent ,bison-ts-mode-indent-offset)
> ((bison-ts-mode--bison-matcher-not-epilogue "translation_unit")
> parent-0 ,bison-ts-mode-indent-offset)
> ,@(alist-get 'cpp (c-ts-mode--get-indent-style 'cpp))))
> ('java `(java
> ((bison-ts-mode--bison-matcher-action "program")
> bison-ts-mode--bison-parent ,bison-ts-mode-indent-offset)
> ((bison-ts-mode--bison-matcher-not-epilogue "program")
> column-0 ,bison-ts-mode-indent-offset)
> ,@java-ts-mode--indent-rules))))))
>
>
> (define-derived-mode bison-ts-mode prog-mode "Bison"
> "A major-mode for Bison based on tree-sitter."
> (when (treesit-ready-p 'bison)
> (when (not bison-ts-mode-embedded-language)
Or `unless'
> (setq bison-ts-mode-embedded-language (bison-ts-mode--detect-language)))
>
> ;; Require only if needed, to avoid warnings if a grammar is not
> ;; installed but not used.
> (pcase bison-ts-mode-embedded-language
> ('c (require 'c-ts-mode))
> ('cpp (require 'c-ts-mode))
> ('java (require 'java-ts-mode)))
>
> (setq-local treesit-font-lock-settings
> (append (bison-ts-mode--font-lock-settings 'bison)
> (pcase bison-ts-mode-embedded-language
> ('c (c-ts-mode--font-lock-settings 'c))
> ('cpp (c-ts-mode--font-lock-settings 'cpp))
> ('java java-ts-mode--font-lock-settings))))
>
> (setq-local treesit-font-lock-feature-list
> (if bison-ts-mode-embedded-language
> (bison-ts-mode--merge-feature-lists
> bison-ts-mode--font-lock-feature-list
> (pcase bison-ts-mode-embedded-language
> ('c c-ts-mode--feature-list)
> ('cpp c-ts-mode--feature-list)
> ('java java-ts-mode--feature-list)))
> bison-ts-mode--font-lock-feature-list))
>
> (setq-local treesit-simple-imenu-settings
> `(("Grammar"
> "\\`grammar_rule_declaration\\'"
> nil
> (lambda (node) (substring-no-properties (treesit-node-text node))))))
The function `treesit-node-text' appears to take an optional NO-PROPERTY argument.
>
> (c-ts-common-comment-setup)
>
> (setq-local treesit-simple-indent-rules
> (bison-ts-mode--indent-rules))
>
> (setq-local treesit-language-at-point-function 'bison-ts-mode--language-at-point-function)
>
> (when bison-ts-mode-embedded-language
> (setq-local treesit-range-settings
> (treesit-range-rules
> :embed bison-ts-mode-embedded-language
> :host 'bison
> :local t
> '((embedded_code) @capture))))
>
> (treesit-major-mode-setup)))
>
> (provide 'bison-ts-mode)
> ;;; bison-ts-mode.el ends here
^ permalink raw reply [relevance 81%]
* 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: New tree-sitter mode: bison-ts-mode
@ 2023-09-22 7:38 67% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-09-22 7:38 UTC (permalink / raw)
To: Augustin Chéneau (BTuin); +Cc: emacs-devel
"Augustin Chéneau (BTuin)" <btuin@mailo.com> writes:
A few comments on the proposed file:
> ;;; bison-ts-mode --- Tree-sitter mode for Bison -*- lexical-binding: t; -*-
>
Could you add the usual header information here?
;; Copyright (C) 2022-2023 Free Software Foundation, Inc.
--8<---------------cut here---------------start------------->8---
;; Author: Augustin Chéneau <btuin@mailo.com>
;; This file is part of GNU Emacs.
;; GNU Emacs is free software: you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation, either version 3 of the License, or
;; (at your option) any later version.
;; GNU Emacs is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
;; GNU General Public License for more details.
;; You should have received a copy of the GNU General Public License
;; along with GNU Emacs. If not, see <https://www.gnu.org/licenses/>.
--8<---------------cut here---------------end--------------->8---
> ;;; Commentary:
>
> ;; This is a mode based on tree-sitter for Bison and Yacc files, tools to generate parsers.
Shouldn't you mention what tree sitter grammar is being being used here?
> ;;; Code:
>
> (require 'treesit)
> (require 'c-ts-common)
>
> (declare-function treesit-parser-create "treesit.c")
> (declare-function treesit-induce-sparse-tree "treesit.c")
> (declare-function treesit-node-child-by-field-name "treesit.c")
> (declare-function treesit-search-subtree "treesit.c")
> (declare-function treesit-node-parent "treesit.c")
> (declare-function treesit-node-next-sibling "treesit.c")
> (declare-function treesit-node-type "treesit.c")
> (declare-function treesit-node-child "treesit.c")
> (declare-function treesit-node-end "treesit.c")
> (declare-function treesit-node-start "treesit.c")
> (declare-function treesit-node-string "treesit.c")
> (declare-function treesit-query-compile "treesit.c")
> (declare-function treesit-query-capture "treesit.c")
> (declare-function treesit-parser-add-notifier "treesit.c")
> (declare-function treesit-parser-buffer "treesit.c")
> (declare-function treesit-parser-list "treesit.c")
>
>
> (defgroup bison nil
bison or bison-ts?
> "Support for Bison and Yacc."
Shouldn't tree-sitter be mentioned here?
> :group 'languages)
>
> (defcustom bison-ts-mode-indent-offset 2
> "Number of spaces for each indentation step in `bison-ts-mode'.
> It has no effect in the epilogue part of the file."
> :version "30.1"
> :type 'integer
> :safe 'integerp
> :group 'bison)
>
> (defcustom bison-ts-mode-autodetect-language t
> "Search for a %language directive in the file at initialization.
> Changing the value of this directive in the file requires to reload the mode to
> be effective. If `bison-ts-mode-buffer-language' is set by a file-local
> variable, the auto-detection is not run."
> :version "30.1"
> :type 'boolean
> :safe 'boolean
> :group 'bison)
>
> (defvar-local bison-ts-mode-embedded-language nil
> "Embedded language in Bison buffer.")
>
> (defun bison-ts-mode--merge-feature-lists (l1 l2)
> "Merge the lists of lists L1 and L2.
> The first sublist of L1 is merged with the first sublist of L2 and so on.
> L1 and L2 don't need to have the same size."
> (let ((res ()))
> (while (or l1 l2)
> (setq res (push (append (car l1) (car l2)) res))
> (setq l1 (cdr l1) l2 (cdr l2)))
> (nreverse res)))
Is this a generic function that should be extracted into some common file?
> (defun bison-ts-mode--find-language-in-buffer (&optional buffer)
> "Find and return the language set by the Bison directive %language.
> If BUFFER is set, search in this buffer, otherwise search in the current
> buffer."
> (save-excursion
> (when buffer
> (switch-to-buffer buffer))
Or rather?
(with-current-buffer (or buffer (current-buffer))
(save-excursion
...))
> (goto-char (point-min))
> (let ((pos-end
> (re-search-forward
> (rx
> bol (0+ blank) "%language" (0+ blank) "\"" (1+ (in alpha "+")) "\"")
> nil
> t))
> (pos-beg nil))
> (when pos-end
Using when-let might be nice here.
> (goto-char (1- pos-end))
> (setq pos-beg (1+ (search-backward "\"" nil t)))
> (buffer-substring-no-properties pos-beg (1- pos-end))))))
I'd use a single regular expression here with a group, then extract the
right information using `match-string'.
>
>
> (defun bison-ts-mode--detect-language (&optional buffer)
> "Dectect the embedded language in a Bison buffer.
> Known languages are C, C++, D, and Java, but D is not supported as there is
> no support for tree-sitter D in Emacs yet.
> If BUFFER is set, search in this buffer, otherwise search in the current
> buffer."
> (if-let ((str (bison-ts-mode--find-language-in-buffer buffer)))
> (pcase (downcase str)
> ("c" 'c)
> ("c++" 'cpp)
> ("d" (progn (message "D language not yet supported") nil))
Each pcase case has an implicit progn.
> ("java" 'java))
> (progn
Use when-let to avoid this progn.
> (message
> "bison-ts-mode: %%language specification not found or invalid, defaulting to C.")
Is it necessary to prefix the message with the major mode name?
> 'c)))
>
>
> (defun bison-ts-mode--language-at-point-function (position)
> "Return the language at POSITION."
> (let* ((node (treesit-node-at position 'bison)))
^
let is enough
> (if (equal (treesit-node-type node)
> "embedded_code")
There is no need to break the line here.
> bison-ts-mode-embedded-language
> 'bison)))
>
> (defun bison-ts-mode--font-lock-settings (language)
> "Return the font-lock settings for Bison.
> LANGUAGE should be set to \\='bison."
> (treesit-font-lock-rules
> :language language
> :feature 'bison-comment
> '((comment) @font-lock-comment-face)
>
> :language language
> :feature 'bison-declaration
> '((declaration_name) @font-lock-keyword-face)
>
> :language language
> :feature 'bison-type
> '((type) @font-lock-type-face)
>
> :language language
> :feature 'bison-grammar-rule-usage
> '((grammar_rule_identifier) @font-lock-variable-use-face)
>
> :language language
> :feature 'bison-grammar-rule-declaration
> '((grammar_rule (grammar_rule_declaration)
> @font-lock-variable-use-face))
>
> :language language
> :feature 'bison-string
> :override t
> '((string) @font-lock-string-face)
>
> :language language
> :feature 'bison-literal
> :override t
> '((char_literal) @font-lock-keyword-face
> (number_literal) @font-lock-number-face)
>
> :language language
> :feature 'bison-directive-grammar-rule
> :override t
> '((grammar_rule (directive) @font-lock-keyword-face))
>
> :language language
> :feature 'bison-operator
> :override t
> '(["|"] @font-lock-operator-face)
>
> :language language
> :feature 'bison-delimiter
> :override t
> '([";"] @font-lock-delimiter-face)))
>
>
> (defvar bison-ts-mode--font-lock-feature-list
> '(( bison-comment bison-declaration bison-type
> bison-grammar-rule-usage bison-grammar-rule-declaration
> bison-string bison-literal bison-directive-grammar-rule
> bison-operator bison-delimiter)))
>
>
> (defun bison-ts-mode--bison-matcher-action (root-name)
> "Treesit matcher to check if NODE at BOL is not located in the epilogue.
> ROOT-NAME is the highest-level node of the embedded language."
> (lambda (node _parent bol &rest _)
> (if (equal (treesit-node-type (treesit-node-parent node)) root-name)
> (let* ((bison-node (treesit-node-at bol 'bison)))
^
here again, let is enough
(if (equal
> (treesit-node-type
> (treesit-node-parent(treesit-node-parent bison-node))) "action")
Though you could bind the (treesit-node-type ...) expression under the
above let.
> t
> nil)))))
Why (if foo t nil) when foo would do the same job (equal only returns
nil and t, so normalising the value isn't even necessary).
>
> (defun bison-ts-mode--bison-matcher-not-epilogue (root-name)
> "Treesit matcher to check if NODE at BOL is not located in the epilogue.
> ROOT-NAME is the highest-level node of the embedded language."
> (lambda (node _parent bol &rest _)
> (if (equal (treesit-node-type (treesit-node-parent node)) root-name)
> (let* ((bison-node (treesit-node-at bol 'bison)))
> (if (equal (treesit-node-type (treesit-node-parent bison-node)) "epilogue")
> nil
> t)))))
Am I missing something, or couldn't these two functions be merged if you
give them a third argument NODE-TYPE and pass it "action" or "epilogue".
>
>
> (defun bison-ts-mode--bison-parent (_node _parent bol &rest _)
> "Get the parent of the bison node at BOL."
> (treesit-node-start (treesit-node-parent (treesit-node-at bol 'bison))))
>
>
> (defun bison-ts-mode--indent-rules ()
> "Indent rules supported by `bison-ts-mode'."
> (let*
> ((common
> `(((node-is "^declaration$")
> column-0 0)
> ((and (parent-is "^declaration$")
> (not (node-is "^code_block$")))
> column-0 2)
> ((and (parent-is "comment") c-ts-common-looking-at-star)
> c-ts-common-comment-start-after-first-star -1)
> (c-ts-common-comment-2nd-line-matcher
> c-ts-common-comment-2nd-line-anchor
> 1)
> ((parent-is "comment") prev-adaptive-prefix 0)
>
> ;; Opening and closing brackets "{}" of declarations
> ((and (parent-is "^declaration$")
> (node-is "^code_block$"))
> column-0 0)
> ((and (n-p-gp "}" "" "^declaration$"))
> column-0 0)
> ((parent-is "^declaration$") parent 2)
> ((node-is "^grammar_rule$") column-0 0)
> ((and
> (parent-is "^grammar_rule$")
> (node-is ";"))
> column-0 bison-ts-mode-indent-offset)
> ((and (parent-is "^grammar_rule$")
> (node-is "|"))
> column-0 bison-ts-mode-indent-offset)
> ((and (parent-is "^grammar_rule$")
> (not (node-is "^grammar_rule_declaration$"))
> (not (node-is "^action$")))
> column-0 ,(+ bison-ts-mode-indent-offset 2))
> ((or
> (node-is "^action$")
> (node-is "^}$"))
> column-0 12)
> ;; Set '%%' at the beginning of the line
> ((or
> (and (parent-is "^grammar_rules_section$")
> (node-is "%%"))
> (node-is "^grammar_rules_section$"))
> column-0 0)
> (no-node parent-bol 0))))
> `((bison . ,common)
> ;; Import and override embedded languages rules to add an offset
> ,(pcase bison-ts-mode-embedded-language
> ('c `(c
> ((bison-ts-mode--bison-matcher-action "translation_unit")
> bison-ts-mode--bison-parent ,bison-ts-mode-indent-offset)
> ((bison-ts-mode--bison-matcher-not-epilogue "translation_unit")
> column-0 ,bison-ts-mode-indent-offset)
> ,@(alist-get 'c (c-ts-mode--get-indent-style 'c))))
> ('cpp `(cpp
> ((bison-ts-mode--bison-matcher-action "translation_unit")
> bison-ts-mode--bison-parent ,bison-ts-mode-indent-offset)
> ((bison-ts-mode--bison-matcher-not-epilogue "translation_unit")
> parent-0 ,bison-ts-mode-indent-offset)
> ,@(alist-get 'cpp (c-ts-mode--get-indent-style 'cpp))))
> ('java `(java
> ((bison-ts-mode--bison-matcher-action "program")
> bison-ts-mode--bison-parent ,bison-ts-mode-indent-offset)
> ((bison-ts-mode--bison-matcher-not-epilogue "program")
> column-0 ,bison-ts-mode-indent-offset)
> ,@java-ts-mode--indent-rules))))))
>
>
> (define-derived-mode bison-ts-mode prog-mode "Bison"
> "A mode for Bison."
^
major-mode
Also, mentioning tree-sitter seems like something worth doing.
> (when (treesit-ready-p 'bison)
> (when (not bison-ts-mode-embedded-language)
> (setq bison-ts-mode-embedded-language (bison-ts-mode--detect-language)))
>
> ;; Require only if needed, to avoid warnings if a grammar is not
> ;; installed but not used.
> (pcase bison-ts-mode-embedded-language
Would a `pcase-exhaustive' be appropriate here?
> ('c (require 'c-ts-mode))
> ('cpp (require 'c-ts-mode))
> ('java (require 'java-ts-mode)))
>
> (setq-local treesit-font-lock-settings
> (append (bison-ts-mode--font-lock-settings 'bison)
> (pcase bison-ts-mode-embedded-language
> ('c (c-ts-mode--font-lock-settings 'c))
> ('cpp (c-ts-mode--font-lock-settings 'cpp))
> ('java java-ts-mode--font-lock-settings))))
>
> (setq-local treesit-font-lock-feature-list
> (if bison-ts-mode-embedded-language
> (bison-ts-mode--merge-feature-lists
> bison-ts-mode--font-lock-feature-list
> (pcase bison-ts-mode-embedded-language
> ('c c-ts-mode--feature-list)
> ('cpp c-ts-mode--feature-list)
> ('java java-ts-mode--feature-list)))
> bison-ts-mode--font-lock-feature-list))
>
> (setq-local treesit-simple-imenu-settings
> `(("Grammar"
> "\\`grammar_rule_declaration\\'"
> nil
> (lambda (node) (substring-no-properties (treesit-node-text node))))))
>
> (c-ts-common-comment-setup)
>
> (setq-local treesit-simple-indent-rules
> (bison-ts-mode--indent-rules))
>
> (setq-local treesit-language-at-point-function 'bison-ts-mode--language-at-point-function)
>
> (when bison-ts-mode-embedded-language
> (setq-local treesit-range-settings
> (treesit-range-rules
> :embed bison-ts-mode-embedded-language
> :host 'bison
> :local t
> '((embedded_code) @capture))))
>
> (treesit-major-mode-setup)))
>
> (provide 'bison-ts-mode)
> ;;; bison-ts-mode.el ends here
Sorry for the number of comments, but there has been a discussion on the
code-quality of tree-sitter major modes that has been less than optimal,
so I hope that your contribution could help raise the bar.
^ permalink raw reply [relevance 67%]
* Re: [GNU ELPA] New package: tam
@ 2023-09-21 16:38 86% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-09-21 16:38 UTC (permalink / raw)
To: Lynn Winebarger; +Cc: emacs-devel
Lynn Winebarger <owinebar@gmail.com> writes:
> On Wed, Sep 20, 2023 at 4:26 AM Philip Kaludercic <philipk@posteo.net> wrote:
>> Re your last change in [0], why use records directly instead of having
>> the code being generated via cl-defstruct? The commit messages doesn't
>> really explain your reasoning to me.
>
> The library is supposed to provide alloc/free functions that run in
> O(1) time to the extent that is possible for emacs-lisp code, for use
> in process sentinels and similar situations. I took a look at the
> byte-code generated for those two functions when using the
> cl-defstruct definitions, and the accessors and setters were not
> inlined. Aside from the unknown complexity of invoking those
> functions, every call has a risk of overflowing the current stack and
> requiring an additional stack segment be allocated.
>
> I rewrote the code so the only appearances of the call operator in the
> byte-code of those functions is for error signaling. I also provide
> an inlining version of each operation so library clients can avoid
> call instructions in their code.
From what I understand this situation was resolved in the other
subthread, right?
>> >> I am the kind of person who thinks twice about installing a package when
>> >> it has dependencies. But if you prefer to use a package available on
>> >> ELPA, then that is of course OK as well.
>
> BTW, there's something ironic about this, since you actually appear to
> review most packages on GNU/NonGNU ELPA - how many users would be more
> familiar with the packages that might be installed from those
> archives?
> At any rate, it does not depend on any packages, or even cl-lib, now -
> though I have to revise the header to say so.
I don't know if this is ironic or not, I just don't like having too many
packages installed in general? As I said, this is my personal taste and
I am not forcing this onto anyone.
>>
>> The question was supposed to be more general, sorry for the confusion.
>> I wanted to know if there was a reason you were using setf even when
>> setq would be enough, but it really doesn't matter either way since setf
>> on a symbol expands directly to setq.
>
> If I had setf on a symbol, it was a typo. They are all gone now,
> since they did not get optimized out.
OK.
>> No, it uses nreverse:
>>
>> --8<---------------cut here---------------start------------->8---
>> (macroexpand-all '(cl-loop for i to 10 collect i))
>> (let* ((i 0) (--cl-var-- nil))
>> (while (<= i 10)
>> (setq --cl-var-- (cons i --cl-var--))
>> (setq i (+ i 1)))
>> (nreverse --cl-var--))
>> --8<---------------cut here---------------end--------------->8---
> Blech, I replaced it with a simple function.
Another idea could be using mapcan, but usually requires calling a
lambda expression -- at which point we have firmly reached the territory
of micro-optimisation, and it makes no sense to progress any further
without some substantial, empirical measurements and good technical
explanations behind the observations.
>> These kinds of arguments lead to leftpad like situations, where people
>> defer any slightly complicated functionality to a library. The last
>> thing I want to see when installing a package is that it drags along
>> dozens or even hundreds of recursive dependants, causing me to loose an
>> overview of what I have installed and what is being installed. Every
>> dependency a package brings with it (especially packages like dash &
>> co.) is an argument against using it, imo.
>
> I don't think the leftpad situation (which I had to look up) can
> happen on GNU ELPA. Even if, despite the FSF's precautions, something
> had to be removed, I'm sure there would be plenty of warning.
The point isn't so much that something gets removed (as you say, ELPA
plays the middle-man here by mirroring the repository contents), but
rather that a downstream bug or even a malicious change in a deep
dependency can cause much more harm, even if the inherent utility,
ie. need for the package in the first place was not that significant in
the first place.
> Lynn
^ permalink raw reply [relevance 86%]
* 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: [GNU ELPA] New package: tam
@ 2023-09-20 8:26 80% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-09-20 8:26 UTC (permalink / raw)
To: Lynn Winebarger; +Cc: emacs-devel
Lynn Winebarger <owinebar@gmail.com> writes:
> On Mon, Sep 18, 2023 at 1:02 PM Philip Kaludercic <philipk@posteo.net> wrote:
>> > Apologies, I renamed the library to tam.el and failed to note the
>> > changes I made to the renamed file did not get committed and pushed.
>>
>> So what does that mean?
>
> That I don't use git enough to avoid rookie errors? I had already
> addressed some of the items you brought up in my working copy, they
> just hadn't been committed and pushed to the server.
> I think I've addressed all the items you brought up in the last
> version I pushed.
Ok. What I wanted to make sure was that you didn't change the
repository URL or something like that.
Re your last change in [0], why use records directly instead of having
the code being generated via cl-defstruct? The commit messages doesn't
really explain your reasoning to me.
[0] https://github.com/owinebar/emacs-table-allocation-manager/commit/bc654b6d687c67c5ad45218d6f45f95b8f1e0478
>> I am the kind of person who thinks twice about installing a package when
>> it has dependencies. But if you prefer to use a package available on
>> ELPA, then that is of course OK as well.
>
> I revised it to make use of cl-loop per your observation in the
> previous email. I'm not really a fan of the loop imperative DSL, but
> this case was simple enough (as you pointed out).
> Some packages (like queue) provide pretty basic data structures, so I
> think avoiding packages that depend on them only encourages
> reimplementing the wheel.
> However, I might be the world record holder for the number of elisp
> libraries loaded and included in a dump file.
>> >> -(defsubst tam-table-size (tbl)
>> >> +(defsubst tam-table-size (tbl) ;why not `defalias'
>> >
>> > I tried defalias first, but got a byte-compiler error about a void
>> > variable. Which I found confusing, since it should be looking for a
>> > function definition, not a variable. I'm using 28.3.
>> > Some of the following should have already been fixed from when I
>> > ran checkdoc.
>>
>> What did you do? That sounds like something was misquoted:
>>
>> (defalias 'tam-table-size #'tam--table-size)
>
> I forgot defalias is a function and not a macro. Thanks.
>
>> > I'll
>> > change it if required, but I find computing the place inside a set
>> > form to be disconcerting if it's not required. For example, I
>> > wouldn't use a set form like
>> > (set (if P 'A 'B) some-value)
>> > in place of
>> > (if P (setq A some-value) (setq B some-value))
>>
>> In that case, is there a reason you are using setf?
>
> I'm confused - the documentation does not indicate that an "if" form
> would be a "place" that setf knows how to handle. The cl-lib doc does
> say it extends setf to handle macro expansions, but 'if' is a special
> form that does not macro-expand.
> I use setf because that's the cleanest way to set fields of a
> structure. It's more like setq than set (it's a macro for one thing)
> as far as I can tell.
The question was supposed to be more general, sorry for the confusion.
I wanted to know if there was a reason you were using setf even when
setq would be enough, but it really doesn't matter either way since setf
on a symbol expands directly to setq.
>> > I do want to return lists reflecting the ordering of the slots. I am
>> > not a fan of constructing an ordered structure only to reverse it.
>>
>> FWIW this is standard practice, and what a cl-loop with collect would
>> also expand to. And if I am not mistaken, this is more efficient, than
>> accumulating a linked list in the right order to begin with (it is a
>> difference of O(n) vs O(n^2), I believe).
>
> Wait, did you mean cl-loop with collect will do the nreverse? I
> thought you meant it would keep track of the tail of the list and
> update it.
No, it uses nreverse:
--8<---------------cut here---------------start------------->8---
(macroexpand-all '(cl-loop for i to 10 collect i))
(let* ((i 0) (--cl-var-- nil))
(while (<= i 10)
(setq --cl-var-- (cons i --cl-var--))
(setq i (+ i 1)))
(nreverse --cl-var--))
--8<---------------cut here---------------end--------------->8---
> Accumulating a list in the right order is only O(n^2) if you only keep
> the head of the list. The queue structure (or what I would write with
> let-bound variables) holds a reference to the last cons cell of the
> list to use in adding an entry on the end. It's probably negligible
> for very short lists, but it's just bad form.
>
>> > That said, these functions are primarily intended for debugging.
>>
>> Wouldn't that kind of a convenience be an argument against adding an
>> extra dependency?
>
> Only if I was trying to get a library included in startup.el, or if
> the dependency was not in GNU ELPA. Otherwise, why are people writing
> packages? They are not all stand-alone user interfacing programs.
> Some are just basic data structures and algorithms that haven't been
> included in core emacs for whatever reason. Queue is one of those.
These kinds of arguments lead to leftpad like situations, where people
defer any slightly complicated functionality to a library. The last
thing I want to see when installing a package is that it drags along
dozens or even hundreds of recursive dependants, causing me to loose an
overview of what I have installed and what is being installed. Every
dependency a package brings with it (especially packages like dash &
co.) is an argument against using it, imo.
> Lynn
^ permalink raw reply [relevance 80%]
* Re: [package-vc] Consider cleaning up files from install process
@ 2023-09-20 8:13 68% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-09-20 8:13 UTC (permalink / raw)
To: Adam Porter; +Cc: Joseph Turner, Emacs Devel Mailing List
Adam Porter <adam@alphapapa.net> writes:
> On 9/19/23 08:50, Philip Kaludercic wrote:
>
>>> An alternative would be to follow Quelpa's example: rather than
>>> loading the package directly from the git repository's directory, the
>>> package's files could be copied into a new directory in the elpa/
>>> directory, and Emacs could load the package from there.
>>>
>>> As a developer, I would prefer that approach, because I don't usually
>>> want Emacs to load whatever commit I may have checked out in a
>>> package's repository. I want to install a commit of a package into my
>>> Emacs configuration and have that one loaded until I install a
>>> different one.
>> Isn't this workflow already supported by `package-install-file'?
>> And
>> otherwise, there wouldn't be much of a point to just replicate the
>> functionality of an existing package manager.
>
> That doesn't seem to do the same thing: it doesn't install from a git
> repo, per se, but from local files or directories:
>
> (package-install-file FILE)
>
> Install a package from FILE.
> The file can either be a tar file, an Emacs Lisp file, or a
> directory.
>
> What I like to do is to install the package from the git repo as a,
> well, "normal package," i.e. as if it were installed from ELPA.
> That's how Quelpa works: it produces,
> e.g. "~/.emacs.d/elpa/PACKAGE-VERSION/PACKAGE{,...}.el". I don't have
> to have a local clone of the repo first.
>
> (Also, the name of the command suggests that it only installs from
> files rather than directories; I didn't even realize it could install
> from directories until now.)
>
>>> In other words, the way package-vc-install currently works leaves me
>>> vulnerable to this scenario:
>>>
>>> 1. I use package-vc-install to install one of my packages from its
>>> local repository directory.
>>> 2. I check out a feature branch of that package to work on a new
>>> feature, saving some files but not loading any of the changed code.
>>> 3. I restart Emacs (e.g. maybe I shut down the system and turned it
>>> back on the next day).
>>> 4. That work-in-progress feature branch of my package gets loaded
>>> into Emacs automatically (which may be entirely broken, being a WIP).
>> I understand your issue, but anecdotally, I can also give an example
>> where I wanted to change some functionality, by M-x find-function'ing
>> the source buffer and then loosing the change after upgrading the
>> package.
>
> IMHO that seems like a sort of user-error, to leave uncommitted
> changes in a repo that's under the control of a system that doesn't
> take such changes into account when operating on the repo. IOW, if I
> install a package with command package-FOO, I expect the files it
> makes to be under its purview, not mine; they are not my personal data
> files, but belong to Emacs and its package.el library, the same as if
> I used "M-x package-install".
I don't believe in these kinds of distinctions. I can change what I
want, the only question I have to keep in mind is what the chances of
loosing these changes is going to be.
> To put it another way, it seems like a bit of an anti-pattern to
> develop a package that's stored in "~/.emacs.d/elpa"--that directory
> is supposed to be for installed packages' files, and it should be safe
> to wipe that directory out at any time and reinstall packages from
> their sources--after all,
Is that documented anywhere? I know it can be done, if your
configuration is written accordingly, but if you see installed packages
as not being part of your domain, then transgressing layers of
abstraction and accessing, then deleting the "internal" representation
of package.el would seem to also be wrong?
> "M-x package-delete" shouldn't be wiping out
> user data. Development on packages should be done on clones stored
> outside of "~/.emacs.d", e.g. in "~/src" or whatever one uses. IMHO,
> of course--Emacs is all about user freedom--yet I think we should
> encourage the better practices.
I don't see it that way, but the technical background for this decision
is that source packages -- written with the intention of loading the
source code directly from the checkout -- should be loadable without
having to require package-vc, since package-vc is just an extension of
package.el that allows for an alternative way of installing packages.
>>> Whereas if I use Quelpa, it installs the files a package's recipe
>>> specifies into the expected location in the elpa/ directory, and that
>>> remains independent of whatever I may have checked out in the
>>> package's local git directory. My Emacs configuration and installed
>>> packages remain consistent regardless of whatever in-between state I
>>> may have left a package's repository in.
>>>
>>> Philip, would you be willing to consider switching to that model for
>>> package-vc-install, or offering it as an option?
>> Can you describe the interface you are imagining. From what I
>> understand, it should be possible to reproduce what you need by
>> combining `package-vc-checkout' and `package-install-file'?
>
> Well, I would expect it to act similarly to Quelpa:
>
> 1. Clone the git repo (shallowly, at least by default) to a directory
> (perhaps a temporary one, but at least one stored in the appropriate
> XDG cache directory, outside of user-emacs-directory).
>
> 2. Call package-install-file on that worktree.
>
> 3. The package ends up installed into package-user-dir as if it were
> installed with package-install from ELPA.
How does this look like:
--8<---------------cut here---------------start------------->8---
(defun package-vc-install-copy (pkg-desc)
"Fetch the package sources of PKG-DESC and install a copy."
(interactive (list (package-vc--read-package-desc "Fetch package source: ")))
(let* ((copy (copy-package-desc pkg-desc))
(package-dir (expand-file-name
(symbol-name (package-desc-name pkg-desc))
(make-temp-file "package-vc-" t)))
(package-vc-register-as-project nil))
(setf (package-desc-dir copy) package-dir)
(save-window-excursion
(package-vc-checkout pkg-desc package-dir)
(package-install-from-buffer))))
--8<---------------cut here---------------end--------------->8---
I'd ideally pass :last-release to package-vc-checkout, but I have
detected a bug with this setup that should be fixed.
> Then if the user wants to modify the package, he should either a) use
> a local clone wherever he keeps such projects, or b) configure
> package-vc to clone the repo to such a directory, and then a command
> could automate finding the source files in that directory rather than
> the ones in package-user-dir which are loaded into Emacs. (IIRC
> Straight, for example, does something like this, but I don't use it
> myself.)
To my understanding Straight maintains all packages in separate
repositories, then symlinks the files that are to be loaded. So just
like with package-vc, you always have direct access to the source code
under VC.
> Do these explanations clarify what I mean? Let me know if I need to
> try again. :)
The main question I have is what advantage or disadvantage this would
provide over Quelpa? The functionality you describe misses the point of
what I see to be the point of package-vc, as it wasn't written to be a
replacement of Straight or Quelpa (I have never used either of the two),
but just as a tool to streamline fetching and preparing packages
directly from source code repositories.
> --Adam
^ permalink raw reply [relevance 68%]
* Re: package-vc support for :files keyword
@ 2023-09-20 7:32 67% ` Philip Kaludercic
[not found] ` <87jzsgm82h.fsf@hyperspace>
0 siblings, 2 replies; 200+ results
From: Philip Kaludercic @ 2023-09-20 7:32 UTC (permalink / raw)
To: Tony Zorman; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1392 bytes --]
Tony Zorman <tonyzorman@mailbox.org> writes:
> On Tue, Sep 19 2023 08:47, Philip Kaludercic wrote:
>> Tony Zorman <tonyzorman@mailbox.org> writes:
>>
>> [… 42 lines elided …]
>>
>>> 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.
>>
>> Hmm, this is interesting example that I was not familiar with. As an
>> alternative idea, do you think that using `:ignored-files' like
>> elpa-admin.el could be useful? You could exclude all the files with
>> "soft-dependencies", that wouldn't be scraped in `package-vc--unpack-1'
>> when looking for dependency files.
>
> Overall, I think this would be the better (even best) approach, yes.
Here is a sketch of how that could look like. Can you test it to see if
it works:
[-- Attachment #2: Type: text/plain, Size: 3169 bytes --]
diff --git a/lisp/emacs-lisp/package-vc.el b/lisp/emacs-lisp/package-vc.el
index a8393cb7e75..07e660d9f33 100644
--- a/lisp/emacs-lisp/package-vc.el
+++ b/lisp/emacs-lisp/package-vc.el
@@ -213,7 +213,7 @@ package-vc--desc->spec
name for PKG-DESC."
(alist-get
(setq name (or name (package-desc-name pkg-desc)))
- (if (and (package-desc-archive pkg-desc)
+ (if (and pkg-desc (package-desc-archive pkg-desc)
(not (alist-get name package-vc-selected-packages
nil nil #'string=)))
(alist-get (intern (package-desc-archive pkg-desc))
@@ -501,7 +501,8 @@ package-vc--unpack-1
autoloads, generating a package description file (used to
identify a package as a VC package later on), building
documentation and marking the package as installed."
- (let (missing)
+ (let ((pkg-spec (package-vc--desc->spec pkg-desc))
+ missing)
;; Remove any previous instance of PKG-DESC from `package-alist'
(let ((pkgs (assq (package-desc-name pkg-desc) package-alist)))
(when pkgs
@@ -510,17 +511,27 @@ package-vc--unpack-1
;; In case the package was installed directly from source, the
;; dependency list wasn't know beforehand, and they might have
;; to be installed explicitly.
- (let ((deps '()))
+ (let ((ignored-files
+ (mapconcat
+ (lambda (ignore)
+ (wildcard-to-regexp
+ (if (string-match-p "\\`/" ignore)
+ (concat pkg-dir ignore)
+ (concat "*/" ignore))))
+ (plist-get pkg-spec :ignored-files)
+ "\\|"))
+ (deps '()))
(dolist (file (directory-files pkg-dir t "\\.el\\'" t))
- (with-temp-buffer
- (insert-file-contents file)
- (when-let* ((require-lines (lm-header-multiline "package-requires")))
- (thread-last
- (mapconcat #'identity require-lines " ")
- package-read-from-string
- package--prepare-dependencies
- (nconc deps)
- (setq deps)))))
+ (unless (string-match-p ignored-files file)
+ (with-temp-buffer
+ (insert-file-contents file)
+ (when-let* ((require-lines (lm-header-multiline "package-requires")))
+ (thread-last
+ (mapconcat #'identity require-lines " ")
+ package-read-from-string
+ package--prepare-dependencies
+ (nconc deps)
+ (setq deps))))))
(dolist (dep deps)
(cl-callf version-to-list (cadr dep)))
(setf missing (package-vc-install-dependencies (delete-dups deps)))
@@ -529,8 +540,7 @@ package-vc--unpack-1
missing)))
(let ((default-directory (file-name-as-directory pkg-dir))
- (pkg-file (expand-file-name (package--description-file pkg-dir) pkg-dir))
- (pkg-spec (package-vc--desc->spec pkg-desc)))
+ (pkg-file (expand-file-name (package--description-file pkg-dir) pkg-dir)))
;; Generate autoloads
(let* ((name (package-desc-name pkg-desc))
(auto-name (format "%s-autoloads.el" name))
[-- Attachment #3: Type: text/plain, Size: 250 bytes --]
> (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?
^ permalink raw reply related [relevance 67%]
* Re: Distribution statistics for ELPA and EMMS
@ 2023-09-19 22:06 74% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-09-19 22:06 UTC (permalink / raw)
To: Akib Azmain Turja; +Cc: Adam Porter, rms, yoni, emacs-devel
Akib Azmain Turja <akib@disroot.org> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Adam Porter <adam@alphapapa.net> writes:
>>
>>> [I just noticed this message from a few months ago.]
>>>
>>> On 7/16/23 21:25, Richard Stallman wrote:
>>>> [[[ To any NSA and FBI agents reading my email: please consider ]]]
>>>> [[[ whether defending the US Constitution against all enemies, ]]]
>>>> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>>>> We could have two options for downloading, one which is "for a real
>>>> user" and one which is "for periodic testing".
>>>> The only difference would be that the former increments the user
>>>> download count and the latter does not.
>>>
>>> I like this idea, but it seems like it would be hard to enforce. It
>>> could even go the other way, i.e. have Emacs send a query string or
>>> header when installing a package manually, which could be logged and
>>> used to filter the download logs later. But even that might be harder
>>> than it seems, e.g. if I call a command like:
>>>
>>> emacs --eval "(package-install FOO)"
>>>
>>> ...to non-interactively install a package into a local directory for
>>> testing, how far, and in how many places, would some kind of flag need
>>> to be propagated to end up in the server's logs?
>>
>> There is an inherent unreliability in these kinds of statistics that has
>> to be accepted. The question is therefore are issues like these
>> significant or would they skew the results. This has to be considered
>> under a false-positive and a false-negative approach, depending on what
>> we want to measure.
>
> How are these numbers going to be useful? This can't be a measure of
> "popularity."
Yes, they are at best an indicator. A malicious person could always
manipulate them, unless considerable effort is put into verifying the
information -- which not only comes at the cost of time but also is
likely to decrease the amount of available information.
> Say, for example, the package "git-commit" is 11th most downloaded
> package on MELPA. Is it really popular? Few people install it
> explicitly. Only one package depends on it, which is Magit, a super
> popular package. So git-commit is automatically installed as a
> dependency when Magit is installed.
We should be able to solve that problem by adding a query string to the
request, as Adam suggests:
https://elpa.gnu.org/packages/poker-0.2.tar?selected=yes
https://elpa.gnu.org/packages/seq-2.24.tar?selected=no
https://elpa.gnu.org/packages/project-0.10.0.tar?selected=yes&upgrade=yes
etc.
Given this information, you know the user doesn't object to having this
information used (depending on whether or not this is a opt-in or
out-out thing), the version being fetched, whether it is a dependency or
not and whether it was an upgrade.
> And also, packages that get more frequent update are downloaded more
> than whose update less frequently. So its indeed possible for a less
> popular but frequently updated package gets more downloaded than a
> mature well written more popular package.
We can remember upgrade-counts over the last week, year and all time.
> And also there are straight.el, Elpaca and Quelpa guys who don't use the
> ELPA at all.
Of course, hence "inherent unreliability", though I would be surprised
if the choice of package manager has a strong causal effect on what
packages one uses (setting aside that from-source package managers can
install unreleased packages that are not distributed in any archive).
>> If it is all about dopamine-boosting, I think a
>> false-positive approach would be better ;^)
>
> OK...
>
> (while t
> (package-install 'eat)
> (package-delete (cadr (assoc 'eat package-alist))))
>
> Soon: Eat is the most popular terminal emulator. xD
Good point (though just asynchronously spamming the right URL would be
more efficient), my idea would be to count an IP address only once per
day, ignoring how many concrete requests were sent out and also use a
list of excluded addresses, such as Tor exit nodes, to filter out from
the statistics.
This approach approach, together with the fact that from-source package
managers wouldn't participate unless they are actively instructed to do
so, are further arguments for a false-negative approach.
^ permalink raw reply [relevance 74%]
* Re: Distribution statistics for ELPA and EMMS
@ 2023-09-19 16:38 98% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-09-19 16:38 UTC (permalink / raw)
To: Adam Porter; +Cc: rms, yoni, emacs-devel
Adam Porter <adam@alphapapa.net> writes:
> [I just noticed this message from a few months ago.]
>
> On 7/16/23 21:25, Richard Stallman wrote:
>> [[[ To any NSA and FBI agents reading my email: please consider ]]]
>> [[[ whether defending the US Constitution against all enemies, ]]]
>> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>> We could have two options for downloading, one which is "for a real
>> user" and one which is "for periodic testing".
>> The only difference would be that the former increments the user
>> download count and the latter does not.
>
> I like this idea, but it seems like it would be hard to enforce. It
> could even go the other way, i.e. have Emacs send a query string or
> header when installing a package manually, which could be logged and
> used to filter the download logs later. But even that might be harder
> than it seems, e.g. if I call a command like:
>
> emacs --eval "(package-install FOO)"
>
> ...to non-interactively install a package into a local directory for
> testing, how far, and in how many places, would some kind of flag need
> to be propagated to end up in the server's logs?
There is an inherent unreliability in these kinds of statistics that has
to be accepted. The question is therefore are issues like these
significant or would they skew the results. This has to be considered
under a false-positive and a false-negative approach, depending on what
we want to measure. If it is all about dopamine-boosting, I think a
false-positive approach would be better ;^)
^ permalink raw reply [relevance 98%]
* Re: [NonGNU ELPA] New package: llm
@ 2023-09-19 16:34 45% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-09-19 16:34 UTC (permalink / raw)
To: Andrew Hyatt; +Cc: Stefan Kangas, rms, jporterbugs, emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1080 bytes --]
Andrew Hyatt <ahyatt@gmail.com> writes:
> I've submitted the configuration for llm and set up the branch from my
> repository last Friday. However, I'm still not seeing this package being
> reflected in GNU ELPA's package archive. I followed the instructions, but
> perhaps there's some step that I've missed, or it is only periodically
> rebuilt?
Did you try to run make build/llm? I get this error:
--8<---------------cut here---------------start------------->8---
$ make build/llm
emacs --batch -l /home/philip/.../elpa/admin/elpa-admin.el \
-f elpaa-batch-make-one-package llm
Cloning branch llm:
Preparing worktree (new branch 'externals/llm')
branch 'externals/llm' set up to track 'origin/externals/llm'.
HEAD is now at 39ae6fc794 Assign copyright to FSF, in preparation of inclusion to GNU ELPA
Debugger entered--Lisp error: (search-failed ";;; llm.el ends here")
...
--8<---------------cut here---------------end--------------->8---
In other words the footer is missing. I have prepared a patch that
would address that and a few other checkdoc issues:
[-- Attachment #2: Type: text/plain, Size: 4851 bytes --]
diff --git a/llm.el b/llm.el
index 11b508cb36..08f07b65ca 100644
--- a/llm.el
+++ b/llm.el
@@ -23,9 +23,9 @@
;;; Commentary:
;; This file defines a generic interface for LLMs (large language models), and
-;; functionality they can provide. Not all LLMs will support all of these, but
+;; functionality they can provide. Not all LLMs will support all of these, but
;; programs that want to integrate with LLMs can code against the interface, and
-;; users can then choose the LLMs they want to use. It's advisable to have the
+;; users can then choose the LLMs they want to use. It's advisable to have the
;; possibility of using multiple LLMs when that make sense for different
;; functionality.
;;
@@ -50,7 +50,7 @@
(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').
+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.
@@ -72,7 +72,7 @@ EXAMPLES is a list of conses, where the car is an example
inputs, and cdr is the corresponding example outputs. This is optional.
INTERACTIONS is a list message sent by either the llm or the
-user. It is a list of `llm-chat-prompt-interaction' objects. This
+user. It is a list of `llm-chat-prompt-interaction' objects. This
is required.
TEMPERATURE is a floating point number with a minimum of 0, and
@@ -80,8 +80,7 @@ maximum of 1, which controls how predictable the result is, with
0 being the most predicatable, and 1 being the most creative.
This is not required.
-MAX-TOKENS is the maximum number of tokens to generate. This is optional.
-"
+MAX-TOKENS is the maximum number of tokens to generate. This is optional."
context examples interactions temperature max-tokens)
(cl-defstruct llm-chat-prompt-interaction
@@ -102,19 +101,20 @@ This should be a cons of the name of the LLM, and the URL of the
terms of service.
If the LLM is free and has no restrictions on use, this should
-return nil. Since this function already returns nil, there is no
+return nil. Since this function already returns nil, there is no
need to override it."
(ignore provider)
nil)
(cl-defgeneric llm-chat (provider prompt)
"Return a response to PROMPT from PROVIDER.
-PROMPT is a `llm-chat-prompt'. The response is a string."
+PROMPT is a `llm-chat-prompt'. The response is a string."
(ignore provider prompt)
(signal 'not-implemented nil))
(cl-defmethod llm-chat ((_ (eql nil)) _)
- (error "LLM provider was nil. Please set the provider in the application you are using."))
+ "Catch trivial configuration mistake."
+ (error "LLM provider was nil. Please set the provider in the application you are using"))
(cl-defmethod llm-chat :before (provider _)
"Issue a warning if the LLM is non-free."
@@ -130,7 +130,8 @@ ERROR-CALLBACK receives the error response."
(signal 'not-implemented nil))
(cl-defmethod llm-chat-async ((_ (eql nil)) _ _ _)
- (error "LLM provider was nil. Please set the provider in the application you are using."))
+ "Catch trivial configuration mistake."
+ (error "LLM provider was nil. Please set the provider in the application you are using"))
(cl-defmethod llm-chat-async :before (provider _ _ _)
"Issue a warning if the LLM is non-free."
@@ -143,7 +144,8 @@ ERROR-CALLBACK receives the error response."
(signal 'not-implemented nil))
(cl-defmethod llm-embedding ((_ (eql nil)) _)
- (error "LLM provider was nil. Please set the provider in the application you are using."))
+ "Catch trivial configuration mistake."
+ (error "LLM provider was nil. Please set the provider in the application you are using"))
(cl-defmethod llm-embedding :before (provider _)
"Issue a warning if the LLM is non-free."
@@ -159,7 +161,8 @@ error signal and a string message."
(signal 'not-implemented nil))
(cl-defmethod llm-embedding-async ((_ (eql nil)) _ _ _)
- (error "LLM provider was nil. Please set the provider in the application you are using."))
+ "Catch trivial configuration mistake."
+ (error "LLM provider was nil. Please set the provider in the application you are using"))
(cl-defmethod llm-embedding-async :before (provider _ _ _)
"Issue a warning if the LLM is non-free."
@@ -169,7 +172,7 @@ error signal and a string message."
(cl-defgeneric llm-count-tokens (provider string)
"Return the number of tokens in STRING from PROVIDER.
This may be an estimate if the LLM does not provide an exact
-count. Different providers might tokenize things in different
+count. Different providers might tokenize things in different
ways."
(ignore provider)
(with-temp-buffer
@@ -199,3 +202,4 @@ This should only be used for logging or debugging."
"")))
(provide 'llm)
+;;; llm.el ends here
[-- Attachment #3: Type: text/plain, Size: 559 bytes --]
>
> On Tue, Sep 12, 2023 at 11:05 AM Stefan Kangas <stefankangas@gmail.com>
> wrote:
>
>> Andrew Hyatt <ahyatt@gmail.com> writes:
>>
>> > 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.
>>
>> It's easier for users if it's just one package.
>>
^ permalink raw reply related [relevance 45%]
* 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-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] Consider cleaning up files from install process
@ 2023-09-19 13:50 93% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-09-19 13:50 UTC (permalink / raw)
To: Adam Porter; +Cc: Joseph Turner, Emacs Devel Mailing List
Adam Porter <adam@alphapapa.net> writes:
> I noticed this problem myself when I first tried using package-vc-install.
>
> An alternative would be to follow Quelpa's example: rather than
> loading the package directly from the git repository's directory, the
> package's files could be copied into a new directory in the elpa/
> directory, and Emacs could load the package from there.
>
> As a developer, I would prefer that approach, because I don't usually
> want Emacs to load whatever commit I may have checked out in a
> package's repository. I want to install a commit of a package into my
> Emacs configuration and have that one loaded until I install a
> different one.
Isn't this workflow already supported by `package-install-file'? And
otherwise, there wouldn't be much of a point to just replicate the
functionality of an existing package manager.
> In other words, the way package-vc-install currently works leaves me
> vulnerable to this scenario:
>
> 1. I use package-vc-install to install one of my packages from its
> local repository directory.
> 2. I check out a feature branch of that package to work on a new
> feature, saving some files but not loading any of the changed code.
> 3. I restart Emacs (e.g. maybe I shut down the system and turned it
> back on the next day).
> 4. That work-in-progress feature branch of my package gets loaded
> into Emacs automatically (which may be entirely broken, being a WIP).
I understand your issue, but anecdotally, I can also give an example
where I wanted to change some functionality, by M-x find-function'ing
the source buffer and then loosing the change after upgrading the
package.
> Whereas if I use Quelpa, it installs the files a package's recipe
> specifies into the expected location in the elpa/ directory, and that
> remains independent of whatever I may have checked out in the
> package's local git directory. My Emacs configuration and installed
> packages remain consistent regardless of whatever in-between state I
> may have left a package's repository in.
>
> Philip, would you be willing to consider switching to that model for
> package-vc-install, or offering it as an option?
Can you describe the interface you are imagining. From what I
understand, it should be possible to reproduce what you need by
combining `package-vc-checkout' and `package-install-file'?
> Thanks,
> Adam
^ permalink raw reply [relevance 93%]
* Re: [package-vc] Consider cleaning up files from install process
@ 2023-09-19 9:03 83% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-09-19 9:03 UTC (permalink / raw)
To: Joseph Turner; +Cc: Emacs Devel Mailing List, Adam Porter
Joseph Turner <joseph@breatheoutbreathe.in> writes:
> package-vc-install currently adds a number of files to a package's
> repository which are not tracked by VC. It is inconvenience to add each
> of them to a .gitignore file (or equivalent in other VC systems). Are
> they necessary? Are you open to removing them in a clean up phase?
Initially package-vc would automatically add these as ignored files
using `vc-ignore', but I decided against keeping that behaviour in
e08e9bc40, due to issues I should have documented at the time.
> 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:
"Sadly", all of these files are necessary for package.el:
> dir
This file is used by info to indicate that there is a manual file that
should be listed in in (dir) Top.
> hyperdrive-autoloads.el
This file contains all the autoload information, including function
and user options stubs, that allow the user to invoke the package
directly without a (require 'hyperdrive)
> hyperdrive-pkg.el
This contains the package descriptor, that tracks the basic package
metadata used to decide what package to load.
> hyperdrive.info
This is the compiled manual, generated from a .texi or .org file in your
repository. Without this file, there is no manual.
So in summary, this is the difference between just cloning a repository
and adding it to your `load-path'. Unless I am forgetting something,
there shouldn't be any more files than these, so adding them to your
.gitignore should be a constant effort and should solve the issue.
> Best,
>
> Joseph
^ permalink raw reply [relevance 83%]
* Re: package-vc support for :files keyword
@ 2023-09-19 8:47 94% ` Philip Kaludercic
1 sibling, 2 replies; 200+ results
From: Philip Kaludercic @ 2023-09-19 8:47 UTC (permalink / raw)
To: Tony Zorman; +Cc: emacs-devel
Tony Zorman <tonyzorman@mailbox.org> writes:
> On Mon, Sep 18 2023 15:52, Philip Kaludercic wrote:
>>> I think that
>>>
>>> $ rm foo.el
>>> $ git update-index --assume-unchanged foo.el
>>>
>>> should work. It should merge cleanly (I've tried this out just now, and
>>> it worked, but I may have overlooked something). If it's part of the
>>> package description, then updating should work out of the box, since
>>> package-vc-upgrade also calls package-vc--unpack-1, which would execute
>>> the respective :early-shell-command again.
>>
>> Being a git-specific command, this shouldn't be added to package-vc
>> directly. If there is a VCS agnostic/generalisable way of doing this,
>> then it could be added to VC.
>
> Ah, sometimes I forget that there are VCs other than Git—sorry :)
>
>> But for now, if I understand you correctly, you are suggesting that
>> users give package specifications like this:
>>
>> (foo :url "https://some.vcs/repository"
>> ;; ...
>> :early-shell-command "rm [all the files]; git update-index --assume-unchanged [all the files]")
>>
>> where [all the files] might change between updates.
>
> Yes, exactly.
>
>> At this point I continue to question the utility of emulating
>> MELPA-style :files attributes, unless there are concrete usability
>> issues.
>>
>> For the record, these are all the repositories in {Non,}GNU ELPA that
>> develop multiple packages in a single repository:
>>
>> [… 12 lines elided …]
>>
>> From what I understand, there is no technical necessity for this mode of
>> development? I wonder how difficult it would be to push for a
>> one-package-one-repo approach.
>
> 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.
Hmm, this is interesting example that I was not familiar with. As an
alternative idea, do you think that using `:ignored-files' like
elpa-admin.el could be useful? You could exclude all the files with
"soft-dependencies", that wouldn't be scraped in `package-vc--unpack-1'
when looking for dependency files.
Alternatively, since I am still not convinced that having
:early-shell-command built-in to package-vc is a good idea, one could
scatter a number of hooks around the code that could be used to extend
installation procedure with additional functionality, like a
:early-shell-command.
> [1]: https://github.com/slotThe/vc-use-package/issues/12
> [2]: https://github.com/alphapapa/org-ql/
^ permalink raw reply [relevance 94%]
* Re: package-vc support for :files keyword
@ 2023-09-19 8:37 97% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-09-19 8:37 UTC (permalink / raw)
To: Adam Porter; +Cc: emacs-devel, tonyzorman
Adam Porter <adam@alphapapa.net> writes:
> Hi Philip, et al,
>
>> For the record, these are all the repositories in {Non,}GNU ELPA that
>> develop multiple packages in a single repository:
>> GNU ELPA:
>> http://www.dr-qubit.org/git/predictive.git
>> https://github.com/oantolin/embark
>> https://github.com/abo-abo/swiper
>> https://github.com/abo-abo/hydra
>> https://github.com/alphapapa/taxy.el.git
>> From what I understand, there is no technical necessity for this
>> mode of
>> development? I wonder how difficult it would be to push for a
>> one-package-one-repo approach.
>
> 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?
> 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"?
> Thanks for your work,
> Adam
^ permalink raw reply [relevance 97%]
* Re: [GNU ELPA] New package: tam
@ 2023-09-18 17:02 84% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-09-18 17:02 UTC (permalink / raw)
To: Lynn Winebarger; +Cc: emacs-devel
Lynn Winebarger <owinebar@gmail.com> writes:
> On Mon, Sep 18, 2023 at 5:37 AM Philip Kaludercic <philipk@posteo.net> wrote:
>>
>> Lynn Winebarger <owinebar@gmail.com> writes:
>>
>> > I'd like to submit "tam" (table allocation manager) for inclusion in
>> > GNU ELPA. The source is available at
>> > https://github.com/owinebar/emacs-table-allocation-manager
>>
>> Here are a few comments:
> Thanks for taking a look.
>
>>
>> diff --git a/table-allocation-manager.el b/table-allocation-manager.el
>> index 59a5718..286c9a2 100644
>> --- a/table-allocation-manager.el
>> +++ b/table-allocation-manager.el
>> @@ -3,6 +3,10 @@
>> ;; Copyright (C) 2023 Onnie Lynn Winebarger
>>
>> ;; Author: Onnie Lynn Winebarger <owinebar@gmail.com>
>> +;; Maintainer: Onnie Lynn Winebarger <owinebar@gmail.com>
>> +;; URL: https://github.com/owinebar/emacs-table-allocation-manager
>> +;; Package-Requires: ((emacs "24.4") (queue "0.2"))
>> +
>
> Apologies, I renamed the library to tam.el and failed to note the
> changes I made to the renamed file did not get committed and pushed.
So what does that mean?
>> ;; Keywords: lisp, tools
>>
>> ;; This program is free software; you can redistribute it and/or modify
>> @@ -24,7 +28,9 @@
>> ;; table. All allocation is done during initialization to avoid triggering
>> ;; garbage collection during allocation/free operations.
>>
>> -;; API:
>> +;; API: (is it necessary to document the API here? This has to be
>> +;; kept up to date, while a M-x apropos-function tam- RET could avoid
>> +;; the issue.)
>
> I thought it would be helpful to summarize the functionality for review.
That is true, but I wouldn't bother with maintaining this in the long
term. Encouraging the usage of apropos commands is good anyway.
>> ;;
>> ;; (tam-create-table N) => table of size N
>> ;; (tam-table-fullp TABLE) => nil unless TABLE is full
>> @@ -43,13 +49,12 @@
>> ;; (tam-table-free-list TABLE) => list of free indices in TABLE
>> ;; (tam-table-live-list TABLE) => list of in-use indices in TABLE
>>
>> -
>> ;;; Code:
>>
>> (eval-when-compile
>> (require 'cl-lib))
>>
>> -(require 'queue)
>> +(require 'queue) ;is this even necessary? see below.
>
> If it's a big deal, then no. Since queue is a GNU package, I
> preferred to not repeat code.
I am the kind of person who thinks twice about installing a package when
it has dependencies. But if you prefer to use a package available on
ELPA, then that is of course OK as well.
>>
>> (cl-defstruct (tam--table (:constructor tam--table-create (size))
>> (:copier tam--copy-table))
>> @@ -66,16 +71,15 @@
>> (table index in-use next previous))
>> (:copier tam--copy-slot))
>> "Slot in TAM table"
>> - table ;; table containing this slot
>> - index ;; index of slot in table
>> - in-use ;; flag indicating if contents are "live"
>> - next ;; next on list of used/free
>> - previous ;; previous on list of used/free
>> - contents ;; contents of slot
>> - )
>> + (table :documentation "table containing this slot")
>> + (index :documentation "index of slot in table")
>> + (in-use :documentation "flag indicating if contents are live")
>> + (next :documentation "next on list of used/free")
>> + (previous :documentation "previous on list of used/free")
>> + (contents :documentation "contents of slot"))
>>
>> (defun tam-create-table (N)
>> - "Make a tam table of size N."
>> + "Make a tam table of size N." ;"tam table" might not be clear.
>> (let ((tbl (tam--table-create N))
>> (v (make-vector N nil))
>> (N-1 (- N 1))
>> @@ -98,8 +102,6 @@
>> (setf (tam--table-last-free tbl) (aref v N-1))
>> tbl))
>>
>> -
>> -
>> (defun tam-table-fullp (tbl)
>> "Test if TBL is full."
>> (<= (tam--table-size tbl) (tam--table-used tbl)))
>> @@ -108,22 +110,20 @@
>> "Test if TBL is empty."
>> (= (tam--table-used tbl) 0))
>>
>> -(defsubst tam-table-size (tbl)
>> +(defsubst tam-table-size (tbl) ;why not `defalias'
>
> I tried defalias first, but got a byte-compiler error about a void
> variable. Which I found confusing, since it should be looking for a
> function definition, not a variable. I'm using 28.3.
> Some of the following should have already been fixed from when I ran checkdoc.
What did you do? That sounds like something was misquoted:
(defalias 'tam-table-size #'tam--table-size)
?
>> "Number of slots in TBL."
>> (tam--table-size tbl))
>>
>> -
>> (defsubst tam-table-used (tbl)
>> "Number of slots of TBL in use."
>> (tam--table-used tbl))
>>
>> (defun tam--table-get-slot (tbl idx)
>> - "Get slot IDX of TBL"
>> + "Get slot IDX of TBL."
>> (aref (tam--table-slots tbl) idx))
>>
>> -
>> (defun tam-table-get (tbl idx)
>> - "Get contents of slot IDX of TBL"
>> + "Get contents of slot IDX of TBL."
>> (tam--slot-contents (aref (tam--table-slots tbl) idx)))
>>
>> (defun tam-allocate (tbl obj)
>> @@ -133,9 +133,14 @@ Returns index or nil if table is full."
>> next idx)
>> (when (not (tam-table-fullp tbl))
>> (setf (tam--slot-previous s) (tam--table-last-used tbl))
>> - (if (tam-table-emptyp tbl)
>> - (setf (tam--table-first-used tbl) s)
>> - (setf (tam--slot-next (tam--table-last-used tbl)) s))
>> + (setf (if (tam-table-emptyp tbl)
>> + (tam--table-first-used tbl)
>> + (tam--slot-next (tam--table-last-used tbl)))
>> + s)
>
> Is this a personal stylistic preference, or a requirement?
Nothing I say is a requirement, I should have made that explicit. More
of a "look what you could also do, in case you are interested".
> I'll
> change it if required, but I find computing the place inside a set
> form to be disconcerting if it's not required. For example, I
> wouldn't use a set form like
> (set (if P 'A 'B) some-value)
> in place of
> (if P (setq A some-value) (setq B some-value))
In that case, is there a reason you are using setf?
> where I might be amenable to
> (set (opaque-function-call args ...) some-value)
>
>> + (setf (if (tam-table-emptyp tbl)
>> + (tam--table-first-used tbl)
>> + (tam--slot-next (tam--table-last-used tbl)))
>> + s)
> I'm assuming this is a typo.
Probably.
>> (setf (tam--table-last-used tbl) s)
>> (setq next (tam--slot-next s))
>> (setf (tam--table-first-free tbl) next)
>> @@ -151,8 +156,9 @@ Returns index or nil if table is full."
>> idx))
>>
>> (defun tam-free (tbl idx)
>> - "Free slot at IDX in TBL. Returns contents of slot IDX.
>> -Signals an error if IDX is not in use."
>> + "Free slot at IDX in TBL.
>> +Returns contents of slot IDX. Signals an error if IDX is not in
>> +use."
>> (let ((s (tam--table-get-slot tbl idx))
>> (last-free (tam--table-last-free tbl))
>> prev next obj)
>> @@ -185,17 +191,19 @@ Signals an error if IDX is not in use."
>> (cl-decf (tam--table-used tbl))
>> obj))
>>
>> +;; you appear to only use the queue to track a list of objects, right?
>> +;; Why not this then:
>> (defun tam-table-free-list (tbl)
>> - "Return list of free indices in TBL"
>> + "Return list of free indices in TBL."
>> (let ((s (tam--table-first-free tbl))
>> - (q (queue-create)))
>> + (q '()))
>> (while s
>> - (queue-enqueue q (tam--slot-index s))
>> + (push (tam--slot-index s) q)
>> (setq s (tam--slot-next s)))
>> - (queue-all q)))
>> + (nreverse q))) ;iff even necessary
>
> I do want to return lists reflecting the ordering of the slots. I am
> not a fan of constructing an ordered structure only to reverse it.
FWIW this is standard practice, and what a cl-loop with collect would
also expand to. And if I am not mistaken, this is more efficient, than
accumulating a linked list in the right order to begin with (it is a
difference of O(n) vs O(n^2), I believe).
> I can rewrite this to append to the tail using let-bound head and tail
> variables, but it seems excessive to avoid a single allocation of a
> queue structure.
> That said, these functions are primarily intended for debugging.
Wouldn't that kind of a convenience be an argument against adding an
extra dependency?
>>
>> (defun tam-table-live-list (tbl)
>> - "Return list of live indices in TBL"
>> + "Return list of live indices in TBL."
>> (let ((s (tam--table-first-used tbl))
>> (q (queue-create)))
>> (while s
>>
>> --
>> Philip Kaludercic
--
Philip Kaludercic
^ permalink raw reply [relevance 84%]
* Re: package-vc support for :files keyword
@ 2023-09-18 15:52 81% ` Philip Kaludercic
0 siblings, 2 replies; 200+ results
From: Philip Kaludercic @ 2023-09-18 15:52 UTC (permalink / raw)
To: Tony Zorman; +Cc: emacs-devel
Tony Zorman <tonyzorman@mailbox.org> writes:
> On Mon, Sep 18 2023 09:10, Philip Kaludercic wrote:
>> Tony Zorman <tonyzorman@mailbox.org> writes:
>>> here's an idea: why not create e.g. a variable to decide when
>>> :shell-command is executed? Moving the execution to right after cloning
>>> the repository, instead of before building documentation, would enable
>>> one to easily emulate :files directives, as well as other keywords that
>>> need to be executed before things actually get built.
>>>
>>> Alternatively one could have a second :shell-command like keyword.
>>
>> My issue with the first idea would be that this would create a greater
>> discrepancy between what elpa-admin and package-vc do. So if anything,
>> I think only the second option, e.g. :early-shell-command, would be
>> viable.
>
> Fair enough.
>
>> In both cases, what would you imagine that the command would do? If it
>> just calls "rm foo.el bar.el ...", then we have an issue when upgrading,
>> because there would at least be a merge conflict any time the other
>> files are modified upstream. Upgrading isn't easy the way it is, but
>> raising the necessity for manual intervention every time is something
>> I'd like to avoid.
>
> I think that
>
> $ rm foo.el
> $ git update-index --assume-unchanged foo.el
>
> should work. It should merge cleanly (I've tried this out just now, and
> it worked, but I may have overlooked something). If it's part of the
> package description, then updating should work out of the box, since
> package-vc-upgrade also calls package-vc--unpack-1, which would execute
> the respective :early-shell-command again.
Being a git-specific command, this shouldn't be added to package-vc
directly. If there is a VCS agnostic/generalisable way of doing this,
then it could be added to VC.
But for now, if I understand you correctly, you are suggesting that
users give package specifications like this:
(foo :url "https://some.vcs/repository"
;; ...
:early-shell-command "rm [all the files]; git update-index --assume-unchanged [all the files]")
where [all the files] might change between updates.
At this point I continue to question the utility of emulating
MELPA-style :files attributes, unless there are concrete usability
issues.
For the record, these are all the repositories in {Non,}GNU ELPA that
develop multiple packages in a single repository:
GNU ELPA:
http://www.dr-qubit.org/git/predictive.git
https://github.com/oantolin/embark
https://github.com/abo-abo/swiper
https://github.com/abo-abo/hydra
https://github.com/alphapapa/taxy.el.git
NonGNU ELPA:
https://github.com/lewang/flx
https://github.com/emacs-helm/helm
https://github.com/magit/magit
https://github.com/brianc/jade-mode
From what I understand, there is no technical necessity for this mode of
development? I wonder how difficult it would be to push for a
one-package-one-repo approach.
>> Also, what would a :early-shell-command be used for
>> on the ELPA build server?
>
> That I don't know, I've never consciously looked at the ELPA build
> server.
--
Philip Kaludercic
^ permalink raw reply [relevance 81%]
* Re: [GNU ELPA] New package: tam
@ 2023-09-18 9:37 48% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-09-18 9:37 UTC (permalink / raw)
To: Lynn Winebarger; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 245 bytes --]
Lynn Winebarger <owinebar@gmail.com> writes:
> I'd like to submit "tam" (table allocation manager) for inclusion in
> GNU ELPA. The source is available at
> https://github.com/owinebar/emacs-table-allocation-manager
Here are a few comments:
[-- Attachment #2: Type: text/plain, Size: 5048 bytes --]
diff --git a/table-allocation-manager.el b/table-allocation-manager.el
index 59a5718..286c9a2 100644
--- a/table-allocation-manager.el
+++ b/table-allocation-manager.el
@@ -3,6 +3,10 @@
;; Copyright (C) 2023 Onnie Lynn Winebarger
;; Author: Onnie Lynn Winebarger <owinebar@gmail.com>
+;; Maintainer: Onnie Lynn Winebarger <owinebar@gmail.com>
+;; URL: https://github.com/owinebar/emacs-table-allocation-manager
+;; Package-Requires: ((emacs "24.4") (queue "0.2"))
+
;; Keywords: lisp, tools
;; This program is free software; you can redistribute it and/or modify
@@ -24,7 +28,9 @@
;; table. All allocation is done during initialization to avoid triggering
;; garbage collection during allocation/free operations.
-;; API:
+;; API: (is it necessary to document the API here? This has to be
+;; kept up to date, while a M-x apropos-function tam- RET could avoid
+;; the issue.)
;;
;; (tam-create-table N) => table of size N
;; (tam-table-fullp TABLE) => nil unless TABLE is full
@@ -43,13 +49,12 @@
;; (tam-table-free-list TABLE) => list of free indices in TABLE
;; (tam-table-live-list TABLE) => list of in-use indices in TABLE
-
;;; Code:
(eval-when-compile
(require 'cl-lib))
-(require 'queue)
+(require 'queue) ;is this even necessary? see below.
(cl-defstruct (tam--table (:constructor tam--table-create (size))
(:copier tam--copy-table))
@@ -66,16 +71,15 @@
(table index in-use next previous))
(:copier tam--copy-slot))
"Slot in TAM table"
- table ;; table containing this slot
- index ;; index of slot in table
- in-use ;; flag indicating if contents are "live"
- next ;; next on list of used/free
- previous ;; previous on list of used/free
- contents ;; contents of slot
- )
+ (table :documentation "table containing this slot")
+ (index :documentation "index of slot in table")
+ (in-use :documentation "flag indicating if contents are live")
+ (next :documentation "next on list of used/free")
+ (previous :documentation "previous on list of used/free")
+ (contents :documentation "contents of slot"))
(defun tam-create-table (N)
- "Make a tam table of size N."
+ "Make a tam table of size N." ;"tam table" might not be clear.
(let ((tbl (tam--table-create N))
(v (make-vector N nil))
(N-1 (- N 1))
@@ -98,8 +102,6 @@
(setf (tam--table-last-free tbl) (aref v N-1))
tbl))
-
-
(defun tam-table-fullp (tbl)
"Test if TBL is full."
(<= (tam--table-size tbl) (tam--table-used tbl)))
@@ -108,22 +110,20 @@
"Test if TBL is empty."
(= (tam--table-used tbl) 0))
-(defsubst tam-table-size (tbl)
+(defsubst tam-table-size (tbl) ;why not `defalias'
"Number of slots in TBL."
(tam--table-size tbl))
-
(defsubst tam-table-used (tbl)
"Number of slots of TBL in use."
(tam--table-used tbl))
(defun tam--table-get-slot (tbl idx)
- "Get slot IDX of TBL"
+ "Get slot IDX of TBL."
(aref (tam--table-slots tbl) idx))
-
(defun tam-table-get (tbl idx)
- "Get contents of slot IDX of TBL"
+ "Get contents of slot IDX of TBL."
(tam--slot-contents (aref (tam--table-slots tbl) idx)))
(defun tam-allocate (tbl obj)
@@ -133,9 +133,14 @@ Returns index or nil if table is full."
next idx)
(when (not (tam-table-fullp tbl))
(setf (tam--slot-previous s) (tam--table-last-used tbl))
- (if (tam-table-emptyp tbl)
- (setf (tam--table-first-used tbl) s)
- (setf (tam--slot-next (tam--table-last-used tbl)) s))
+ (setf (if (tam-table-emptyp tbl)
+ (tam--table-first-used tbl)
+ (tam--slot-next (tam--table-last-used tbl)))
+ s)
+ (setf (if (tam-table-emptyp tbl)
+ (tam--table-first-used tbl)
+ (tam--slot-next (tam--table-last-used tbl)))
+ s)
(setf (tam--table-last-used tbl) s)
(setq next (tam--slot-next s))
(setf (tam--table-first-free tbl) next)
@@ -151,8 +156,9 @@ Returns index or nil if table is full."
idx))
(defun tam-free (tbl idx)
- "Free slot at IDX in TBL. Returns contents of slot IDX.
-Signals an error if IDX is not in use."
+ "Free slot at IDX in TBL.
+Returns contents of slot IDX. Signals an error if IDX is not in
+use."
(let ((s (tam--table-get-slot tbl idx))
(last-free (tam--table-last-free tbl))
prev next obj)
@@ -185,17 +191,19 @@ Signals an error if IDX is not in use."
(cl-decf (tam--table-used tbl))
obj))
+;; you appear to only use the queue to track a list of objects, right?
+;; Why not this then:
(defun tam-table-free-list (tbl)
- "Return list of free indices in TBL"
+ "Return list of free indices in TBL."
(let ((s (tam--table-first-free tbl))
- (q (queue-create)))
+ (q '()))
(while s
- (queue-enqueue q (tam--slot-index s))
+ (push (tam--slot-index s) q)
(setq s (tam--slot-next s)))
- (queue-all q)))
+ (nreverse q))) ;iff even necessary
(defun tam-table-live-list (tbl)
- "Return list of live indices in TBL"
+ "Return list of live indices in TBL."
(let ((s (tam--table-first-used tbl))
(q (queue-create)))
(while s
[-- Attachment #3: Type: text/plain, Size: 23 bytes --]
--
Philip Kaludercic
^ permalink raw reply related [relevance 48%]
* Re: package-vc support for :files keyword
@ 2023-09-18 9:10 91% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-09-18 9:10 UTC (permalink / raw)
To: Tony Zorman; +Cc: emacs-devel
Tony Zorman <tonyzorman@mailbox.org> writes:
> Hi,
>
> Philip Kaludercic <philipk@posteo.net> writes:
>> But just like :make and :shell-command, or use-package support was not
>> intended in the beginning, I don't insist on anything as long as a
>> good compromise can be found. I just have my doubts, since supporting
>> this would probably run against a number of basic assumptions that
>> package-vc was written around.
>
> here's an idea: why not create e.g. a variable to decide when
> :shell-command is executed? Moving the execution to right after cloning
> the repository, instead of before building documentation, would enable
> one to easily emulate :files directives, as well as other keywords that
> need to be executed before things actually get built.
>
> Alternatively one could have a second :shell-command like keyword.
My issue with the first idea would be that this would create a greater
discrepancy between what elpa-admin and package-vc do. So if anything,
I think only the second option, e.g. :early-shell-command, would be
viable.
In both cases, what would you imagine that the command would do? If it
just calls "rm foo.el bar.el ...", then we have an issue when upgrading,
because there would at least be a merge conflict any time the other
files are modified upstream. Upgrading isn't easy the way it is, but
raising the necessity for manual intervention every time is something
I'd like to avoid. Also, what would a :early-shell-command be used for
on the ELPA build server?
> Tony
--
Philip Kaludercic
^ permalink raw reply [relevance 91%]
* 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: Adding package-vc to ELPA
@ 2023-09-17 8:02 90% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-09-17 8:02 UTC (permalink / raw)
To: Stefan Kangas; +Cc: Jonas Bernoulli, emacs-devel
Stefan Kangas <stefankangas@gmail.com> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>>>> I had a look at vc-clone and a few vc-*-clone. They seem trivial
>>>> enough to backport, either as part of Compat or in package-vc.el.
>>
>> I have put some more though into this, and I don't think adding the new
>> VC functionality to Compat or package-vc.el would be a good idea.
>> Beside vc-clone we would also need `vc-prepare-patch' and the
>> "last-change" method. What would be imaginable would be to add the
>> package to ELPA and make it depend on Emacs 29? Would that sound
>> useful?
>
> What happened to this? package-vc is still not on ELPA, is it?
I have posted an update in another thread:
https://mail.gnu.org/archive/html/emacs-devel/2023-08/msg00667.html. To
summarise, if you take a look at the feature/elpa-package branch you'll
find the changes necessary to add both package.el and package-vc.el to
ELPA. I have been wanting for confirmation from above™ before
progressing with the idea.
There were some objections to adding package.el to ELPA, in case
package.el breaks itself when updating, but I hope that that issue
should be handled by adding a verbatim autoloaded function that can be
used to remove the local package.el installation. Of course if the
complains remain, we can also just add package-vc.el to ELPA.
> I can't see any replies to the question you asked above, but FWIW I
> think requiring Emacs 29 is fine if backporting is too much of a hassle.
Agree.
> Note that Debian stable is still on Emacs 28, so presumably that is what
> will be available in many Debian derivative distros for the next year or
> two. That may or may not be a factor in your decision here.
--
Philip Kaludercic
^ permalink raw reply [relevance 90%]
* Re: Emacs design and architecture
@ 2023-09-14 16:23 98% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-09-14 16:23 UTC (permalink / raw)
To: Helmut Eller
Cc: Gerd Möllmann, Po Lu, Eli Zaretskii, Lynn Winebarger, rms,
emacs-devel
Helmut Eller <eller.helmut@gmail.com> writes:
> On Thu, Sep 14 2023, Gerd Möllmann wrote:
>
>> What I meant is that (a) this technology has advanced layout
>> capabilities, and (b) can obviously be used for interactive
>> applications, like an editor.
>
> So has nobody yet written a front-end for Emacs that runs in a web
> browser?
Using PGTK it is allegedly possible to have Emacs run in a browser[0],
but on my system the command fails with
$ GDK_BACKEND=broadway BROADWAY_DISPLAY=:6 lemacs -Q
(emacs:44517): Gtk-WARNING **: 18:23:14.025: cannot open display: :0
[0] https://lists.gnu.org/archive/html/emacs-devel/2020-12/msg01442.html,
^ permalink raw reply [relevance 98%]
* 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: [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
[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: compat.el and Emacs unstable master branch features
@ 2023-09-13 10:31 55% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-09-13 10:31 UTC (permalink / raw)
To: Daniel Mendler
Cc: Ihor Radchenko, Joseph Turner, Stefan Monnier, Adam Porter,
Eli Zaretskii, phillip.lord, emacs-devel, ~pkal/compat-devel
[-- Attachment #1: Type: text/plain, Size: 1484 bytes --]
Daniel Mendler <mail@daniel-mendler.de> writes:
> On 9/12/23 12:02, Philip Kaludercic wrote:
>> Ihor Radchenko <yantar92@posteo.net> writes:
>>
>>> Daniel Mendler <mail@daniel-mendler.de> writes:
>>>
>>>> ... Providing a public API won't work
>>>> since Compat is not included in Emacs itself. A design criterion of
>>>> Compat is also to keep the public API surface as small as possible.
>>>
>>> Maybe it is the time to consider including the compat.el API into Emacs?
>>> We are getting a number of :core packages published on ELPA and
>>> naturally having to solve various compatibility problems.
>>
>> I am a bit behind wrt Compat development. Are we talking about adding
>> the `compat-call, etc. macros to the core? So basically just a
>>
>> (defmacro compat-call (&rest args) args)
>>
>> that would be overriden by compat's compat-call, as soon as that is
>> loaded
>
> 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:
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Add-the-public-API-of-Compat-to-the-core.patch --]
[-- Type: text/x-diff, Size: 3834 bytes --]
From 3245c3c4e6a8a4c35c4072df3a0bfefcabe0555d Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Wed, 13 Sep 2023 12:26:22 +0200
Subject: [PATCH] Add the public API of Compat to the core
* lisp/emacs-lisp/compat.el: Add stub file with minimal definitions,
so that core packages, that haven't been installed from ELPA, can make
use of the public API and use more recent function signatures.
* lisp/progmodes/python.el (compat): Remove 'noerror flag, because
Compat can now be required without the real package being available.
---
lisp/emacs-lisp/compat.el | 61 +++++++++++++++++++++++++++++++++++++++
lisp/progmodes/python.el | 2 +-
2 files changed, 62 insertions(+), 1 deletion(-)
create mode 100644 lisp/emacs-lisp/compat.el
diff --git a/lisp/emacs-lisp/compat.el b/lisp/emacs-lisp/compat.el
new file mode 100644
index 00000000000..4c60093b6be
--- /dev/null
+++ b/lisp/emacs-lisp/compat.el
@@ -0,0 +1,61 @@
+;;; compat.el --- Pseudo-Compatibility for Elisp -*- lexical-binding: t; -*-
+
+;; Copyright (C) 2021-2023 Free Software Foundation, Inc.
+
+;; Author: \
+;; Philip Kaludercic <philipk@posteo.net>, \
+;; Daniel Mendler <mail@daniel-mendler.de>
+;; Maintainer: \
+;; Daniel Mendler <mail@daniel-mendler.de>, \
+;; Compat Development <~pkal/compat-devel@lists.sr.ht>,
+;; emacs-devel@gnu.org
+;; URL: https://github.com/emacs-compat/compat
+;; Version: 1.0
+;; Keywords: lisp, maint
+
+;; This program is free software; you can redistribute it and/or modify
+;; it under the terms of the GNU General Public License as published by
+;; the Free Software Foundation, either version 3 of the License, or
+;; (at your option) any later version.
+
+;; This program is distributed in the hope that it will be useful,
+;; but WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+;; GNU General Public License for more details.
+
+;; You should have received a copy of the GNU General Public License
+;; along with this program. If not, see <https://www.gnu.org/licenses/>.
+
+;;; Commentary:
+
+;; The Compat package on ELPA provides forward-compatibility
+;; definitions for other packages. While mostly transparent, a
+;; minimal API is necessary whenever core definitions change calling
+;; conventions (e.g. `plist-get' can be invoked with a predicate from
+;; Emacs 29.1 onward). For core packages on ELPA to be able to take
+;; advantage of this functionality, the macros `compat-function' and
+;; `compat-call' have to be available in the core, usable even if
+;; users do not have the Compat package installed, which this file
+;; ensures.
+
+;; Note that Compat is not a core package and this file is not
+;; available on GNU ELPA.
+
+;;; Code:
+
+(defmacro compat-function (fun)
+ "Return compatibility function symbol for FUN.
+This is a pseudo-compatibility stub for core packages on ELPA,
+that depend on the Compat package, whenever the user doesn't have
+the package installed on their current system."
+ `#',fun)
+
+(defmacro compat-call (fun &rest args)
+ "Call compatibility function or macro FUN with ARGS.
+This is a pseudo-compatibility stub for core packages on ELPA,
+that depend on the Compat package, whenever the user doesn't have
+the package installed on their current system."
+ (cons fun args))
+
+(provide 'compat)
+;;; compat.el ends here
diff --git a/lisp/progmodes/python.el b/lisp/progmodes/python.el
index 4b940b3f13b..bf0e27bc786 100644
--- a/lisp/progmodes/python.el
+++ b/lisp/progmodes/python.el
@@ -264,7 +264,7 @@
(eval-when-compile (require 'subr-x)) ;For `string-empty-p' and `string-join'.
(require 'treesit)
(require 'pcase)
-(require 'compat nil 'noerror)
+(require 'compat)
(require 'project nil 'noerror)
(require 'seq)
--
2.39.2
^ permalink raw reply related [relevance 55%]
* Re: compat.el and Emacs unstable master branch features
@ 2023-09-12 10:02 96% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-09-12 10:02 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:
>
>> ... Providing a public API won't work
>> since Compat is not included in Emacs itself. A design criterion of
>> Compat is also to keep the public API surface as small as possible.
>
> Maybe it is the time to consider including the compat.el API into Emacs?
> We are getting a number of :core packages published on ELPA and
> naturally having to solve various compatibility problems.
I am a bit behind wrt Compat development. Are we talking about adding
the `compat-call, etc. macros to the core? So basically just a
(defmacro compat-call (&rest args) args)
that would be overriden by compat's compat-call, as soon as that is
loaded
^ permalink raw reply [relevance 96%]
* Re: [NonGNU ELPA] New package: llm
@ 2023-09-12 9:57 99% ` Philip Kaludercic
1 sibling, 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: Proposal to add Popper to ELPA
@ 2023-09-09 8:10 89% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-09-09 8:10 UTC (permalink / raw)
To: Karthik Chikmagalur; +Cc: Mauro Aranda, emacs-devel
Karthik Chikmagalur <karthikchikmagalur@gmail.com> writes:
>> 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?
>
> I'm not sure it makes sense to enter these keybindings one-by-one, or to
> have tags attached to each entry. The idea is that this is a list of
> keys that will be bound to buffers.
>
> I will change it from (group string character) to (group key-sequence character).
The issue here is that `group' is the wrong type. See (elisp) Composite
Types,
‘(group ELEMENT-TYPES...)’
This works like ‘list’ except for the formatting of text in the
Custom buffer.
and
‘(list ELEMENT-TYPES...)’
The value must be a list with exactly as many elements as the
ELEMENT-TYPES given; and each element must fit the corresponding
ELEMENT-TYPE.
So your type now will match
(list (kbd "C-a") ?z)
but not
(list (kbd "C-a"))
(list ?z)
(list)
(list ?a ?z)
(list (kbd "C-a") (kbd "C-a") ?z)
or the current default value.
> As an aside, how do I determine when a customization type was added to
> Emacs? I want to be sure that (for instance) the `key-binding' type is
> available on Emacs 26.1.
I don't know if this is the best way, but I checked wid-edit.el and
using vc-annotate I could see that it was added in 2005. It is also
documented in the ChangeLog files.
>> Other than that, I have added the package to the archive, thanks for
>> contributing your package!
>
> Thank you Philip.
>
> Karthik
^ permalink raw reply [relevance 89%]
* 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: Proposal to add Popper to ELPA
@ 2023-09-08 17:25 99% ` Philip Kaludercic
0 siblings, 1 reply; 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: Distribution statistics for ELPA and EMMS
@ 2023-09-08 7:51 97% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-09-08 7:51 UTC (permalink / raw)
To: Stefan Kangas; +Cc: Yoni Rabkin, emacs-devel
Stefan Kangas <stefankangas@gmail.com> writes:
> Yoni Rabkin <yoni@rabkins.net> writes:
>
>> Currently we have two developers who have voiced that they would like
>> this feature in ELPA. Perhaps if others chime in then it should be
>> considered.
>
> (I'm a bit late on the ball here.)
>
> We have Bug#50686 where I requested this feature. It seems like the
> status is that we need someone to volunteer to write up the scripts.
I can look into this, but it will probably not be easy to share this
information in the current archive-contents format (though I might be
mistaken, I'll have to check). If it does turn out to be difficult, I'd
add this to the list of features that would be of interest when updating
the archive-contents format, as was proposed by Jonas Bernoulli a few
months back.
--
Philip Kaludercic
^ permalink raw reply [relevance 97%]
* Re: question regarding my emacs package
@ 2023-09-08 7:40 98% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-09-08 7:40 UTC (permalink / raw)
To: ram; +Cc: emacs-devel@gnu.org, Stefan Kangas
ram <chat@rj95.be> writes:
> thanks for the feedback. i've incorporated your suggestions. i believe
> i cleared check doc locally; please let me know otherwise
There still appear to be a few minor issues. Do you use Flymake? If
not, try out M-x flymake-mode and it should highlight the byte-compiler
and checkdoc issues. None of the issues appear to be blocking
inclusion though.
> i have not signed the fsf copyright assignment. what does this process entail?
You have to request the copyright assignment form here on emacs-devel (I
have CC'ed a maintainer) and then sign the form you will receive.
> ------- Original Message -------
> On Thursday, June 8th, 2023 at 3:26 AM, Philip Kaludercic <philipk@posteo.net> wrote:
>
>
>>
>>
>> ram chat@rj95.be writes:
>>
>> > i believe i've incorporated your suggestions, fixed the bugs, and
>> > satisfied check doc. let me know what else i need to do, eg fsf
>> > copyright notice, etc
>>
>>
>> Here are a few more things I noticed:
>>
>> diff -u /tmp/breadcrumbs.el.1 /tmp/breadcrumbs.el
>> --- /tmp/breadcrumbs.el.1 2023-06-08 09:20:18.490560968 +0200
>> +++ /tmp/breadcrumbs.el 2023-06-08 09:23:13.217684032 +0200
>> @@ -35,9 +35,9 @@
>> ;; https://github.com/gitrj95/breadcrumbs.el
>> ;;
>> ;; In order to use breadcrumbs, `breadcrumbs-mode' must be
>> enabled. -;; -;;; Interface: -;; + +;;;; Interface: + ;;`
>> breadcrumbs-drop-breadcrumb' adds the current position in the
>> ;; buffer to a ring. If point is at a known breadcrumb, the existing
>> ;; breadcrumb will be moved to the head of the ring. Adding
>> @@ -103,28 +103,26 @@
>> "Set up the state required to start using breadcrumbs."
>> (unless breadcrumbs-ring
>> (setq breadcrumbs-ring (make-ring breadcrumb-ring-max)))
>> - (mapcar (lambda (fn)
>> - (advice-add fn :around #'breadcrumbs--drop-around))
>> - breadcrumbs-drop-around-fn-list))
>> + (dolist (fn breadcrumbs-drop-around-fn-list)
>> + (advice-add fn :around #'breadcrumbs--drop-around)))
>>
>> (defun breadcrumbs--teardown ()
>> "Tear down the state required for breadcrumbs."
>> (setq breadcrumbs-ring nil
>> breadcrumbs--neighbor nil)
>> - (mapcar (lambda (fn)
>> - (advice-remove fn #'breadcrumbs--drop-around))
>> - breadcrumbs-drop-around-fn-list))
>> + (dolist (fn breadcrumbs-drop-around-fn-list)
>> + (advice-remove fn #'breadcrumbs--drop-around)))
>>
>> (defun breadcrumbs--switch-to-fileless-buffer (breadcrumb)
>> - "Switch to BREADCRUMB's `fileless-buffer-name' if it is non-nil
>> and optionally remove dead ones." + "Switch to BREADCRUMB's`
>> fileless-buffer-name' if it is non-nil.
>> +Optionally remove dead ones."
>> (if-let* ((buffer-name (breadcrumbs--breadcrumb-fileless-buffer-name breadcrumb))
>> (buffer (get-buffer buffer-name)))
>> (switch-to-buffer buffer)
>> (when (yes-or-no-p (format "%s has been killed. Remove from all
>> instances from `breadcrumbs-ring'? " buffer-name)) - (mapcar (lambda
>> (breadcrumb-to-remove) - (when (equal buffer-name
>> (breadcrumbs--breadcrumb-fileless-buffer-name breadcrumb-to-remove))
>> - (ring-remove breadcrumbs-ring (ring-member breadcrumbs-ring
>> breadcrumb-to-remove)))) - (ring-elements breadcrumbs-ring)) +
>> (dolist (breadcrumb-to-remove (ring-elements breadcrumbs-ring)) +
>> (when (equal buffer-name
>> (breadcrumbs--breadcrumb-fileless-buffer-name breadcrumb-to-remove))
>> + (ring-remove breadcrumbs-ring (ring-member breadcrumbs-ring
>> breadcrumb-to-remove)))) (breadcrumbs-list--revert) nil))) @@ -170,7
>> +168,7 @@ ((eq direction 'previous) (ring-next breadcrumbs-ring
>> jump-target))))) (breadcrumbs--neighbor (when (eq direction
>> 'previous) - (breadcrumbs--jump breadcrumbs--neighbor)))))) +
>> (breadcrumbs--jump breadcrumbs--neighbor)))))) ;;;###autoload
>> (define-minor-mode breadcrumbs-mode @@ -195,9 +193,9 @@ (defun
>> breadcrumbs--format-breadcrumb (breadcrumb) "Return BREADCRUMB's
>> formatted slots as a vector." (let* ((buffer-file-name
>> (breadcrumbs--breadcrumb-buffer-file-name breadcrumb)) -
>> (buffer-position (breadcrumbs--breadcrumb-buffer-position
>> breadcrumb)) - (buffer-name
>> (breadcrumbs--breadcrumb-fileless-buffer-name breadcrumb)) -
>> (breadcrumb-name (or buffer-file-name buffer-name))) +
>> (buffer-position (breadcrumbs--breadcrumb-buffer-position
>> breadcrumb)) + (buffer-name
>> (breadcrumbs--breadcrumb-fileless-buffer-name breadcrumb)) +
>> (breadcrumb-name (or buffer-file-name buffer-name))) (vector
>> (breadcrumbs--format-slot breadcrumb-name 64)
>> (breadcrumbs--format-slot buffer-position 16)))) @@ -207,7 +205,8 @@
>> (mapcar (lambda (breadcrumb) (list breadcrumb -
>> (breadcrumbs--format-breadcrumb breadcrumb))) (ring-elements
>> breadcrumbs-ring))) + (breadcrumbs--format-breadcrumb breadcrumb)))
>> + (ring-elements breadcrumbs-ring))) (defun breadcrumbs-list--revert
>> () "Reverts` breadcrumbs-list-buffer'."
>> @@ -232,7 +231,7 @@
>> (ring-remove breadcrumbs-ring
>> (ring-member breadcrumbs-ring (tabulated-list-get-id)))
>> (when (ring-empty-p breadcrumbs-ring)
>> - (setq breadcrumbs--neighbor nil))
>> + (setq breadcrumbs--neighbor nil))
>> (breadcrumbs-list--revert))
>>
>> ;;;###autoload
>>
>> Diff finished. Thu Jun 8 09:24:02 2023
>>
>> The main things were inconsistent indentation, using mapcar for
>> side-effects (if anything mapc should be used in that case, but I think
>> dolist is the best choice) and there still was one checkdoc complaint.
>> On the topic of docstrings, I think you should invest some more time to
>> make them understandable to someone who doesn't already know what the
>> code is about.
>>
>> Have you signed the FSF copyright assignment?
>>
>> > ------- Original Message -------
>> > On Wednesday, June 7th, 2023 at 6:34 PM, ram chat@rj95.be wrote:
>> >
>> > > just got back to this. calling find-file appears to not open the new
>> > > file when called through the code. i'm not immediately sure what the
>> > > problem is. any tips? i'll look more into this tonight
>> > >
>> > > ------- Original Message -------
>> > > On Wednesday, June 7th, 2023 at 3:50 PM, ram chat@rj95.be wrote:
>> > >
>> > > > yes i figured; i found other bugs as well, but i don't think
>> > > > this is a typo. i'll dig a bit more and see what i can find
>> > > >
>> > > > ------- Original Message -------
>> > > > On Wednesday, June 7th, 2023 at 3:48 PM, Philip Kaludercic philipk@posteo.net wrote:
>> > > >
>> > > > > ram chat@rj95.be writes:
>> > > > >
>> > > > > > changing the central type from defclass to cl-defstruct has appeared
>> > > > > > to cause bugs?
>> > > > >
>> > > > > That might have been a typo on my end, I did not evaluate the code and
>> > > > > was is a hurry to send you the diff. My point is that you don't need
>> > > > > defclass, unless I am missing something in your code (and I don't think
>> > > > > the minimal convenience of `with-slots' warrants classes here).
>> > > > >
>> > > > > > i am not sure what to make of this, but find-file and
>> > > > > > its variants do not appear to work when changing only this. the file
>> > > > > > is not opened; it is not that the file is opened but the active buffer
>> > > > > > isn't switched
>> > > > > >
>> > > > > > ------- Original Message -------
>> > > > > > On Wednesday, June 7th, 2023 at 2:04 PM, Philip Kaludercic philipk@posteo.net wrote:
>> > > > > >
>> > > > > > > Philip Kaludercic philipk@posteo.net writes:
>> > > > > > >
>> > > > > > > > > here is the repo: https://github.com/gitrj95/breadcrumbs.el
>> > > > > > > >
>> > > > > > > > Here are a few suggestions:
>> > > > > > >
>> > > > > > > Oh, and can you address the issue raised by checkdoc?
>
--
Philip Kaludercic
^ permalink raw reply [relevance 98%]
* 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: [ELPA] New package: ob-asymptote.el
@ 2023-09-06 22:08 82% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-09-06 22:08 UTC (permalink / raw)
To: Stefan Kangas; +Cc: Jarmo Hurri, emacs-devel
[-- Attachment #1: Type: text/plain, Size: 701 bytes --]
Stefan Kangas <stefankangas@gmail.com> writes:
> Stefan Kangas <stefankangas@gmail.com> writes:
>
>> Philip Kaludercic <philipk@posteo.net> writes:
>>
>>>> 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.
>>
>> It was discussed previously here:
>> https://lists.gnu.org/r/emacs-devel/2023-07/msg00339.html
>
> Do you think we could add it now?
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.
Otherwise, I think a change like this would be nice to have:
[-- Attachment #2: Type: text/plain, Size: 1421 bytes --]
diff --git a/ob-asymptote.el b/ob-asymptote.el
index de99ca3..a088fab 100644
--- a/ob-asymptote.el
+++ b/ob-asymptote.el
@@ -61,20 +61,19 @@ This function is called by `org-babel-execute-src-block'."
"pdf"))
(cmdline (cdr (assq :cmdline params)))
(in-file (org-babel-temp-file "asymptote-"))
- (cmd
- (concat "asy "
- (if out-file
- (concat
- "-globalwrite -f " format
- " -o " (org-babel-process-file-name out-file))
- "-V")
- " " cmdline
- " " (org-babel-process-file-name in-file))))
+ (cmd `("asy"
+ ,@(if out-file
+ `("-globalwrite" "-f" format
+ "-o" (org-babel-process-file-name out-file))
+ "-V")
+ cmdline
+ (org-babel-process-file-name in-file))))
(with-temp-file in-file
(insert (org-babel-expand-body:generic
- body params
- (org-babel-variable-assignments:asymptote params))))
- (message cmd) (shell-command cmd)
+ body params
+ (org-babel-variable-assignments:asymptote params))))
+ (message (mapconcat #'shell-quote-argument cmd " "))
+ (apply #'call-process "asy" nil nil cmd) ;should "asy" be a user option?
nil)) ;; signal that output has already been written to file
(defun org-babel-prep-session:asymptote (_session _params)
^ permalink raw reply related [relevance 82%]
* Re: Proposal to add Popper to ELPA
@ 2023-09-06 17:36 91% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-09-06 17:36 UTC (permalink / raw)
To: Karthik Chikmagalur; +Cc: emacs-devel
Karthik Chikmagalur <karthikchikmagalur@gmail.com> writes:
> Thank you for the review, especially for the changes to the defcustoms.
> I'm not very familiar with the many options the customization interface
> provides. I have applied all changes except the one in the defcustom
> for `popper-reference-buffers' (which see below).
>
> In case you missed it during the review, the package has two files:
> `popper.el' and `popper-echo.el'. (The latter provides `popper-echo-mode',
> which adds echo-area display of available popups and allows for quick
> selection using a transient keymap.)
>
>> +;; If you are interested in depending on Compat, you could use
>> +;; `buffer-match-p' here.
>> (defcustom popper-reference-buffers '("\\*Messages\\*$")
>> "List of buffers to treat as popups.
>
> I would like to avoid depending on Compat for one utility function.
That is understandable, I just wanted to bring it up.
>> - :type '(restricted-sexp :match-alternatives (stringp symbolp functionp consp))
>> - :group 'popper)
>> + :type '(repeat (string :tag "Regular Expression")
>> + (symbol :tag "Major Mode")
>> + (function :tag "Predicate Function")
>> + ;; What is the consp in (restricted-sexp :match-alternatives (stringp symbolp functionp consp))?
>> + ))
>
> The `consp' here is for specifying additional behavior per popup.
> Presently this is limited to requesting that (initial) display of the
> popup be suppressed, but support for other special behavior could be
> provided in the future. Examples of this are in the README in the
> section "Suppressing popups".
>
> An example: `("\\*Compilation\\*" . hide)'
>
> How do you suggest incorporating this into the defcustom?
>
>> Also, it seems adding a .elpaignore file would be nice to remove
>> unnecessary files from the tarball: For now a file just containing
>> "images" should suffice.
>
> Done, thank you.
>
>> Also also, by default the README file will be used to generate a package
>> description (as seen in C-h P). I feel that the current file is just a
>> tad too long for this indent, and the description in the commentary
>> section might be preferable. Would you be fine with using that instead?
>
> Yes, that should be fine. The commentary section explains the purpose
> of the package and the main functions.
1+
>>> What is Popper?
>>>
>>> Short for "Popup Buffer",
>>
>> FWIW I don't think I would have understood this. Perhaps it is just me,
>> but despite fearing a general discussion about package names, do you
>> think renaming the package to something like "popup-buffers" would be
>> imaginable. If not, it is fine, just wanted to bring it up /briefly/.
>
> I took my cue for the name `popper' from Emacs' built-in `winner-mode'.
> At 16K+ downloads, Popper is a reasonably well known package and I think
> renaming it now will create more confusion than clarity.
For the record, I supposed you are referring to MELPA?
> The byline for the package is "Summon and dismiss buffers as popups",
> which shows up in package listings and should help discoverability.
Of course, which is why I am not insisting on anything, I just wanted to
point out that people like me with slight dyslexia have difficulties
reading and remembering names like these. It was actually just
yesterday that I noticed the name is not "poppler".
>>> There are other features, and a few video demos at the link.
>>
>> Is the video mirrored on some other platform as well?
>
> It's not. Do you have a suggestion for where you'd like the videos to
> be available? I can make that happen.
I guess any peertube instance should be OK:
https://joinpeertube.org/publish-videos. I haven't taken a look at the
video, but as long as there is nothing mentioned in the video that is
not mentioned elsewhere, everything should be fine. While some people
prefer it, others find videos to be a information-sparse format.
> Karthik
^ permalink raw reply [relevance 91%]
* Re: NonGNU ELPA: New package 'xdg-appmenu'
@ 2023-09-06 7:42 97% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-09-06 7:42 UTC (permalink / raw)
To: Stefan Kangas; +Cc: Akib Azmain Turja, Emacs Developer List, Juri Linkov
Stefan Kangas <stefankangas@gmail.com> writes:
> Akib Azmain Turja <akib@disroot.org> writes:
>
>> Ping? (2)
>>
>> Akib Azmain Turja <akib@disroot.org> writes:
>>
>>> I've just written a new package and would like to publish it to on
>>> NonGNU ELPA:
>>>
>>> XDG Appmenu allows you to run XDG desktop application right from your
>>> Emacs. To run an application, just do `M-x xdg-appmenu'.
>
> Thanks, this looks like a useful addition. I have two questions:
>
> - How does this compare to the work made by Juri in Bug#63911? Could
> the efforts be merged somehow, such that the end result ends up in
> Emacs, or does that not make sense? (I'm copying in Juri too.)
I am inclined to argue for something like this as well, the
functionality itself it rather limited for just one package.
> - Do you think that it might make sense to add it to GNU ELPA instead?
> I see that you're the only author, so we would only need a copyright
> assignment from you.
From what I recall, Akib is in a situation where he couldn't sign the
copyright assignment. I don't know if anything has changed on that
front, but if it has, it would be a nice opportunity to move some
packages from NonGNU to GNU ELPA.
> In case you're interested, there is also Bug#18132 where we have
> previously discussed XDG and mailcap in relation to Dired.
>
>>> From 32b80f3bc0e4c35a74cc7027017676849ab311bf Mon Sep 17 00:00:00 2001
>>> From: Akib Azmain Turja <akib@disroot.org>
>>> Date: Sat, 8 Jul 2023 15:24:20 +0600
>>> Subject: [PATCH] * elpa-packages (xdg-appmenu): New package
>>>
>>> ---
>>> elpa-packages | 2 ++
>>> 1 file changed, 2 insertions(+)
>>>
>>> diff --git a/elpa-packages b/elpa-packages
>>> index 0610724..ef0af0c 100644
>>> --- a/elpa-packages
>>> +++ b/elpa-packages
>>> @@ -784,6 +784,8 @@
>>> (xah-fly-keys :url "https://github.com/xahlee/xah-fly-keys"
>>> :ignored-files ("*.png"))
>>>
>>> + (xdg-appmenu :url "https://codeberg.org/akib/emacs-xdg-appmenu")
>>> +
>>> (xkcd :url "https://github.com/vibhavp/emacs-xkcd"
>>> :readme "README.org"
>>> :ignored-files ("LICENSE" ".travis.yml" "images"))
>>> --
>>> 2.40.1
^ permalink raw reply [relevance 97%]
* 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: Proposal to add Popper to ELPA
@ 2023-09-05 17:38 25% ` Philip Kaludercic
0 siblings, 2 replies; 200+ results
From: Philip Kaludercic @ 2023-09-05 17:38 UTC (permalink / raw)
To: Karthik Chikmagalur; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 260 bytes --]
Karthik Chikmagalur <karthikchikmagalur@gmail.com> writes:
> I would like to add my package Popper to GNU ELPA.
>
> URL: https://github.com/karthink/popper
Here are a few changes I would propose to make. Haven't tested it, so
take it with a grain of salt:
[-- Attachment #2: Type: text/plain, Size: 14164 bytes --]
diff --git a/popper.el b/popper.el
index 2c392d6..563a655 100644
--- a/popper.el
+++ b/popper.el
@@ -26,55 +26,56 @@
;;; Commentary:
;; Popper is a minor-mode to tame the flood of ephemeral windows Emacs
-;; produces, while still keeping them within arm's reach. Designate any
-;; buffer to "popup" status, and it will stay out of your way. Disimss
-;; or summon it easily with one key. Cycle through all your "popups" or
-;; just the ones relevant to your current buffer. Useful for many
+;; produces, while still keeping them within arm's reach. Designate any
+;; buffer to "popup" status, and it will stay out of your way. Disimss
+;; or summon it easily with one key. Cycle through all your "popups" or
+;; just the ones relevant to your current buffer. Useful for many
;; things, including toggling display of REPLs, documentation,
;; compilation or shell output, etc.
;;
;; For a demo describing usage and customization see
;; https://www.youtube.com/watch?v=E-xUNlZi3rI
-;;
-;; COMMANDS:
-;;
-;; popper-mode : Turn on popup management
-;; popper-toggle-latest : Toggle latest popup
-;; popper-cycle : Cycle through all popups, or close all open popups
-;; popper-toggle-type : Turn a regular window into a popup or vice-versa
-;; popper-kill-latest-popup : Kill latest open popup
-;;
-;; CUSTOMIZATION:
-;;
+
+;;;; Commands:
+
+;; `popper-mode': Turn on popup management
+;; `popper-toggle-latest': Toggle latest popup
+;; `popper-cycle': Cycle through all popups, or close all open popups
+;; `popper-toggle-type': Turn a regular window into a popup or vice-versa
+;; `popper-kill-latest-popup': Kill latest open popup
+
+;;;; Customization:
+
;; `popper-reference-buffers': A list of major modes or regexps whose
;; corresponding buffer major-modes or regexps (respectively) should be
;; treated as popups.
;;
;; `popper-mode-line': String or sexp to show in the mode-line of
-;; popper. Setting this to nil removes the mode-line entirely from
+;; popper. Setting this to nil removes the mode-line entirely from
;; popper.
;;
;; `popper-group-function': Function that returns the context a popup
-;; should be shown in. The context is a string or symbol used to group
+;; should be shown in. The context is a string or symbol used to group
;; together a set of buffers and their associated popups, such as the
-;; project root. Customize for available options.
+;; project root. Customize for available options.
;;
;; `popper-display-control': This package summons windows defined by the
-;; user as popups by simply calling `display-buffer'. By default,
-;; it will display your popups in a non-obtrusive way. If you want
+;; user as popups by simply calling `display-buffer'. By default,
+;; it will display your popups in a non-obtrusive way. If you want
;; Popper to display popups according to window rules you specify in
;; `display-buffer-alist' (or through a package like Shackle), set this
;; variable to nil.
;;
;; There are other customization options, such as the ability to suppress
-;; certain popups and keep them from showing. Please customize the popper group
+;; certain popups and keep them from showing. Please customize the popper group
;; for details.
;;; Code:
(eval-when-compile
- (require 'cl-lib)
(require 'subr-x))
+(require 'cl-lib)
+(require 'seq)
(declare-function project-root "project")
(declare-function project-current "project")
@@ -84,9 +85,11 @@
(defvar popper-mode)
(defgroup popper nil
- "Provide functions for easy access to popup windows"
+ "Provide functions for easy access to popup windows."
:group 'convenience)
+;; If you are interested in depending on Compat, you could use
+;; `buffer-match-p' here.
(defcustom popper-reference-buffers '("\\*Messages\\*$")
"List of buffers to treat as popups.
Each entry in the list can be a regexp (string) to match buffer
@@ -113,31 +116,31 @@ Output*, and all help and compilation buffers.
will match against the Messages buffer, all help buffers and any
buffer with major-mode derived from fundamental mode that has
fewer than 10 lines at time of creation."
- :type '(restricted-sexp :match-alternatives (stringp symbolp functionp consp))
- :group 'popper)
+ :type '(repeat (string :tag "Regular Expression")
+ (symbol :tag "Major Mode")
+ (function :tag "Predicate Function")
+ ;; What is the consp in (restricted-sexp :match-alternatives (stringp symbolp functionp consp))?
+ ))
(defcustom popper-mode-line '(:eval (propertize " POP" 'face 'mode-line-emphasis))
"String or sexp to show in the mode-line of popper.
- Can be a quoted list or function. Setting this to nil removes
+ Can be a quoted list or function. Setting this to nil removes
the mode-line entirely from popper."
- :group 'popper
:type '(choice (const :tag "Off" nil)
(string :tag "Literal text")
(sexp :tag "General `mode-line-format' entry")))
(defcustom popper-mode-line-position 0
"Position in mode-line to place `popper-mode-line'."
- :type 'integer
- :group 'popper)
+ :type 'natnum)
(defcustom popper-display-control t
"Whether popper should control the placement of popup windows.
Choices are:
-\\='user: The default. Only control placement of explicitly marked popups.
+\\='user: The default. Only control placement of explicitly marked popups.
nil : Do not control popup placement.
t : Control placement of all popups."
- :group 'popper
:type '(choice (const :tag "Explicitly set popups only" user)
(const :tag "All popups" t)
(const :tag "Never" nil)))
@@ -149,9 +152,8 @@ Choices are:
`popper-display-control' is non-nil.
This function accepts two arguments, a buffer and (optional) an
-action alist and displays the buffer. See (info \"(elisp) Buffer
+action alist and displays the buffer. See (info \"(elisp) Buffer
Display Action Alists\") for details on the alist."
- :group 'popper
:type 'function)
(defcustom popper-group-function nil
@@ -160,7 +162,7 @@ Display Action Alists\") for details on the alist."
When set to nil popups are not grouped by context.
This function is called with no arguments and should return a
-string or symbol identifying a popup buffer's group. This
+string or symbol identifying a popup buffer's group. This
identifier is used to associate popups with regular buffers (such
as by project, directory, or `major-mode') so that popup-cycling
from a regular buffer is restricted to its associated group.
@@ -171,7 +173,6 @@ Built-in choices include
`popper-group-by-project': Return project root using project.el.
`popper-group-by-projectile': Return project root using projectile.
`popper-group-by-perspective': Return perspective name."
- :group 'popper
:type '(choice
(const :tag "Don't group popups" nil)
(const :tag "Group by project (project.el)" popper-group-by-project)
@@ -185,7 +186,7 @@ Built-in choices include
This can be a number representing the height in chars or a
function that optionally takes one argument (the popup window)
-and returns the height in chars. This option is ignored when
+and returns the height in chars. This option is ignored when
`popper-display-control' is set to nil.
Examples:
@@ -199,7 +200,6 @@ the frame height.
(fit-window-to-buffer
win
(floor (frame-height) 3)))"
- :group 'popper
:type '(choice (integer :tag "Height in chars")
(function :tag "Height function")))
@@ -208,8 +208,7 @@ the frame height.
Each function in the hook is called with the opened popup-buffer
as current."
- :type 'hook
- :group 'popper)
+ :type 'hook)
(defvar popper--reference-names nil
"List of buffer names whose windows are treated as popups.")
@@ -243,7 +242,7 @@ grouped by the predicate `popper-group-function'.")
(defvar-local popper-popup-status nil
"Identifies a buffer as a popup by its buffer-local value.
- Valid values are \\='popup, \\='raised, \\='user-popup or nil.
+Valid values are \\='popup, \\='raised, \\='user-popup or nil.
\\='popup : This is a popup buffer specified in `popper-reference-buffers'.
\\='raised : This is a POPUP buffer raised to regular status by the user.
@@ -257,15 +256,21 @@ grouped by the predicate `popper-group-function'.")
(floor (frame-height) 6)))
(defun popper-select-popup-at-bottom (buffer &optional alist)
- "Display and switch to popup-buffer BUFFER at the bottom of the screen."
+ "Display and switch to popup-buffer BUFFER at the bottom of the screen.
+ALIST is an association list of action symbols and values. See
+Info node `(elisp) Buffer Display Action Alists' for details of
+such alists."
(let ((window (popper-display-popup-at-bottom buffer alist)))
(select-window window)))
(defun popper-display-popup-at-bottom (buffer &optional alist)
- "Display popup-buffer BUFFER at the bottom of the screen."
+ "Display popup-buffer BUFFER at the bottom of the screen.
+ALIST is an association list of action symbols and values. See
+Info node `(elisp) Buffer Display Action Alists' for details of
+such alists."
(display-buffer-in-side-window
buffer
- (append alist
+ (append alist
`((window-height . ,popper-window-height)
(side . bottom)
(slot . 1)))))
@@ -306,9 +311,9 @@ directory as a fall back."
(defun popper-group-by-project ()
"Return an identifier (project root) to group popups."
(unless (fboundp 'project-root)
- (user-error "Cannot find project directory to group popups.
- Please install `project' or customize
- `popper-group-function'"))
+ (user-error "Cannot find project directory to group popups. \
+Please install `project' or customize \
+`popper-group-function'"))
(when-let ((project (project-current)))
(project-root project)))
@@ -317,8 +322,8 @@ directory as a fall back."
This returns the project root found using the projectile package."
(unless (fboundp 'projectile-project-root)
- (user-error "Cannot find project directory to group popups.
- Please install `projectile' or customize
+ (user-error "Cannot find project directory to group popups. \
+Please install `projectile' or customize
`popper-group-function'"))
(projectile-project-root))
@@ -327,9 +332,9 @@ This returns the project root found using the projectile package."
This returns the name of the perspective."
(unless (fboundp 'persp-current-name)
- (user-error "Cannot find perspective name to group popups.
- Please install `perspective' or customize
- `popper-group-function'"))
+ (user-error "Cannot find perspective name to group popups. \
+Please install `perspective' or customize \
+`popper-group-function'"))
(persp-current-name))
(defun popper--find-popups (test-buffer-list)
@@ -519,7 +524,7 @@ next popup windows while keeping the current one (FIXME: This
behavior can be inconsistent.)
With a double prefix ARG \\[universal-argument]
-\\[universal-argument], toggle all popup-windows. Note that only
+\\[universal-argument], toggle all popup-windows. Note that only
one buffer can be show in one slot, so it will display as many
windows as it can."
(interactive "p")
@@ -620,9 +625,9 @@ If BUFFER is not specified act on the current buffer instead."
(seq-some (lambda (pred) (funcall pred buf)) popper--suppressed-predicates)))
(defun popper--suppress-popups ()
- "Suppress open popups in the user-defined
- `popper-suppress-buffers' list. This should run after
- `popper--update-popups' in `window-configuration-change-hook'."
+ "Suppress open popups in the user-defined `popper-suppress-buffers' list.
+This should run after `popper--update-popups' in
+`window-configuration-change-hook'."
;; Check if popup-status for any open popup is 'suppressed. If yes, change
;; its popup-status to 'popup and hide it.
(let ((configuration-changed-p))
@@ -644,7 +649,7 @@ If BUFFER is not specified act on the current buffer instead."
(defun popper--set-reference-vars ()
"Unpack `popper-reference-buffers' to set popper--reference- variables."
(cl-labels ((popper--classify-type
- (elm) (pcase elm
+ (elm) (pcase-exhaustive elm
((pred stringp) 'name)
((and (pred symbolp)
(guard (or (memq 'derived-mode-parent (symbol-plist elm))
@@ -654,12 +659,12 @@ If BUFFER is not specified act on the current buffer instead."
((pred functionp) 'pred)
((pred consp) 'cons)))
(popper--insert-type
- (elm) (pcase (popper--classify-type elm)
+ (elm) (pcase-exhaustive (popper--classify-type elm)
('name (cl-pushnew elm popper--reference-names))
('mode (cl-pushnew elm popper--reference-modes))
('pred (cl-pushnew elm popper--reference-predicates))
('cons (when (eq (cdr elm) 'hide)
- (pcase (popper--classify-type (car elm))
+ (pcase-exhaustive (popper--classify-type (car elm))
('name (cl-pushnew (car elm) popper--suppressed-names))
('mode (cl-pushnew (car elm) popper--suppressed-modes))
('pred (cl-pushnew (car elm) popper--suppressed-predicates))))
@@ -669,10 +674,11 @@ If BUFFER is not specified act on the current buffer instead."
;;;###autoload
(define-minor-mode popper-mode
- "Toggle Popper mode. When enabled, treat certain buffer
-windows as popups, a class of window that can be summoned or
-dismissed with a command. See the customization options for
-details on how to designate buffer types as popups."
+ "Toggle Popper mode.
+When enabled, treat certain buffer windows as popups, a class of
+window that can be summoned or dismissed with a command. See the
+customization options for details on how to designate buffer
+types as popups."
:global t
:version "0.4.5"
:lighter ""
[-- Attachment #3: Type: text/plain, Size: 2622 bytes --]
Also, it seems adding a .elpaignore file would be nice to remove
unnecessary files from the tarball: For now a file just containing
"images" should suffice.
Also also, by default the README file will be used to generate a package
description (as seen in C-h P). I feel that the current file is just a
tad too long for this indent, and the description in the commentary
section might be preferable. Would you be fine with using that instead?
> What is Popper?
>
> Short for "Popup Buffer",
FWIW I don't think I would have understood this. Perhaps it is just me,
but despite fearing a general discussion about package names, do you
think renaming the package to something like "popup-buffers" would be
imaginable. If not, it is fine, just wanted to bring it up /briefly/.
> it's a global minor mode that designates
> buffers as "popups", which means their display can be toggled with a
> single key-press. This is useful for quickly displaying and dismissing
> "auxiliary" buffers like shells, compilation, help/man, grep buffers
> etc. If you have used the guake/yakuake pull-down terminals on GNOME or
> KDE, the experience should be similar.
>
> - You can designate a buffer as a "popup" manually or automatically
> ahead of time via name/major-mode or any predicate of your choosing.
>
> - You can cycle through your popups with one key.
>
> - You can group your popups by any predicate: for example, by project so
> that you only see auxiliary buffers relevant to your current project.
>
> There are other features, and a few video demos at the link.
Is the video mirrored on some other platform as well?
> There are a few other packages that do this kind of thing, but they are
> one or more of:
>
> - Unmaintained (Popwin).
>
> - Too limited in scope. For example, the shellpop and vterm-toggle
> packages allows this kind of behavior but only for shells. Popper is
> generic.
>
> - Too rigid/overarching in their display behavior. In contrast, Popper
> does not try to control how popups are displayed: your
> display-buffer-alist rules are respected, so that it composes well with
> your other packages or customizations involving buffer display.
>
> This package is now 4+ years old and (I think) in a stable state. It
> has been installed 16,000+ times.
>
> Copyright assignment: I have signed the FSF copyright assignment papers.
> Popper has several other contributors, but each of their contributions
> is limited to 1-2 lines, usually fixing a linting issue or typo.
Wunderbar.
> Please let me know if need more information or have any concerns.
>
> Karthik
^ permalink raw reply related [relevance 25%]
* 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 16:55 41% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-09-05 16:55 UTC (permalink / raw)
To: João Távora; +Cc: Jonas Bernoulli, emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1499 bytes --]
João Távora <joaotavora@gmail.com> writes:
> On Tue, Sep 5, 2023 at 4:58 PM Jonas Bernoulli <jonas@bernoul.li> wrote:
>>
>> João Távora <joaotavora@gmail.com> writes:
>>
>> > Hi all
>> >
>> > I'd like to add my package "breadcrumb" to GNU ELPA.
>> > [...]
>> > Here's a link to the project (which has a screenshot)
>> > https://github.com/joaotavora/breadcrumb
>>
>> Another package by that name already exists, but it wasn't touched in
>> 13 years: https://github.com/pheaver/breadcrumb.
>>
>> If you weren't aware of this and would like to avoid taking over an
>> existing name in the future (or be aware that you are doing that, and
>> possibly reach out to the author of the older implementation), you could
>> consult my list at https://emacsmirror.net/stats/upstreams.html, which
>> lists all packages in the Emacsmirror and Emacsattic, which is a
>> superset of packages in GNU ELPA, NonGNU ELPA and MELPA (modulo recent
>> additions).
>
> Oops, I missed that. What does it do.
>
>> Unrelated, but since I looked at your package: Please use just two
>> semicolons inside library commentaries (and in other "non-heading"
>> comments) . Otherwise all the lines that match "^;;;+ ." are treated
>> as headings by outline-minor-mode. (You can of course continue to use
>> ";;;; subheading".)
>
> 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,
[-- Attachment #2: Type: text/plain, Size: 6953 bytes --]
diff --git a/breadcrumb.el b/breadcrumb.el
index cf527afacc..a6c1a868d7 100644
--- a/breadcrumb.el
+++ b/breadcrumb.el
@@ -21,78 +21,77 @@
;; along with this program. If not, see <https://www.gnu.org/licenses/>.
;;; Commentary:
-;;;
+
;;;; Usage:
-;;;
-;;; Breadcrumbs are sequences of short strings indicating where you
-;;; are in some big tree-like maze.
-;;;
-;;; To craft these strings, this library uses the maps provided by
-;;; project.el and Imenu, respectively. Project breadcrumbs shows you
-;;; the current buffer's path in a large project. Imenu breadcrumbs
-;;; show the current position of point in the buffer's nested
-;;; structure of programming constructs (for example, a specific
-;;; functions within multiple C++ nested namespaces).
-;;;
-;;; To use this library:
-;;;
-;;; * `M-x breadcrumb-mode` is a global mode. Will try to turn itself
-;;; on conservatively and only if there's a project.
-
-;;; * `M-x breadcrumb-local-mode` is a buffer-local minor mode, if you
-;;; don't want the default heuristics for turning it on everywhere.
-;;;
-;;; * Manually put the mode-line constructs
-;;;
-;;; (:eval (breadcrumb-imenu-crumbs))
-;;;
-;;; and
-;;;
-;;; (:eval (breadcrumb-project-crumbs))
-;;;
-;;; in your settings of the `mode-line-format' or
-;;; `header-line-format' variables.
-;;;
-;;; The shape and size of each breadcrumb groups may be tweaked via
-;;; `breadcrumb-imenu-max-length', `breadcrumb-project-max-length',
-;;; `breadcrumb-imenu-crumb-separator', and
-;;; `breadcrumb-project-crumb-separator'.
-;;;
-;;; The structure each the breadcrumbs varies depending on whether
-;;; either project.el and imenu.el (or both) can do useful things for
-;;; your buffer.
-;;;
-;;; For Project breadcrumbs, this depends on whether project.el's
-;;; `project-current' can guess what project the current buffer
-;;; belongs to.
-;;;
-;;; For Imenu breadcrumbs, this varies. Depending on the major-mode
-;;; author's taste, the Imenu tree (in variable `imenu--index-alist')
-;;; may have different structure. Sometimes, minor mode also tweak
-;;; the Imenu tree in useful ways. For example, with recent Eglot (I
-;;; think Eglot 1.14+), managed buffers get extra region info added to
-;;; it, which makes Breadcrumb show "richer" paths.
-;;;
-;;;; Implementation notes:
-;;;
-;;; This _should_ be faster than which-func.el due some caching
-;;; strategies. One of these strategies occurs in `bc--ipath-alist',
-;;; which takes care not to over-call `imenu--make-index-alist', which
-;;; could be slow (in fact very slow if an external process needs to
-;;; be contacted). The variable `breadcrumb-idle-delay' controls
-;;; that. Another cache occurs in `bc--ipath-plain-cache' second is
-;;; just a simple "space-for-speed" cache.
-;;;
-;;; Breadcrumb uses the double-dashed Imenu symbols
-;;; `imenu--index-alist' and `imenu--make-index-alist'. There's
-;;; really no official API here. It's arguable that, despite the
-;;; name, these aren't really internal symbols (the much older
-;;; which-func.el library makes liberal use of them, for example).
-;;;
-;;;; Todo:
-;;;
-;;; Make more clicky buttons in the headerline to do whatever
-;;;
+
+;; Breadcrumbs are sequences of short strings indicating where you
+;; are in some big tree-like maze.
+;;
+;; To craft these strings, this library uses the maps provided by
+;; project.el and Imenu, respectively. Project breadcrumbs shows you
+;; the current buffer's path in a large project. Imenu breadcrumbs
+;; show the current position of point in the buffer's nested
+;; structure of programming constructs (for example, a specific
+;; functions within multiple C++ nested namespaces).
+
+;; To use this library:
+
+;; * `M-x breadcrumb-mode` is a global mode. Will try to turn itself
+;; on conservatively and only if there's a project.
+
+;; * `M-x breadcrumb-local-mode` is a buffer-local minor mode, if you
+;; don't want the default heuristics for turning it on everywhere.
+
+;; * Manually put the mode-line constructs
+;;
+;; (:eval (breadcrumb-imenu-crumbs))
+;;
+;; and
+;;
+;; (:eval (breadcrumb-project-crumbs))
+;;
+;; in your settings of the `mode-line-format' or
+;; `header-line-format' variables.
+
+;; The shape and size of each breadcrumb groups may be tweaked via
+;; `breadcrumb-imenu-max-length', `breadcrumb-project-max-length',
+;; `breadcrumb-imenu-crumb-separator', and
+;; `breadcrumb-project-crumb-separator'.
+
+;; The structure each the breadcrumbs varies depending on whether
+;; either project.el and imenu.el (or both) can do useful things for
+;; your buffer.
+
+;; For Project breadcrumbs, this depends on whether project.el's
+;; `project-current' can guess what project the current buffer
+;; belongs to.
+
+;; For Imenu breadcrumbs, this varies. Depending on the major-mode
+;; author's taste, the Imenu tree (in variable `imenu--index-alist')
+;; may have different structure. Sometimes, minor mode also tweak
+;; the Imenu tree in useful ways. For example, with recent Eglot (I
+;; think Eglot 1.14+), managed buffers get extra region info added to
+;; it, which makes Breadcrumb show "richer" paths.
+
+;;; Implementation notes:
+
+;; This _should_ be faster than which-func.el due some caching
+;; strategies. One of these strategies occurs in `bc--ipath-alist',
+;; which takes care not to over-call `imenu--make-index-alist', which
+;; could be slow (in fact very slow if an external process needs to
+;; be contacted). The variable `breadcrumb-idle-delay' controls
+;; that. Another cache occurs in `bc--ipath-plain-cache' second is
+;; just a simple "space-for-speed" cache.
+
+;; Breadcrumb uses the double-dashed Imenu symbols
+;; `imenu--index-alist' and `imenu--make-index-alist'. There's
+;; really no official API here. It's arguable that, despite the
+;; name, these aren't really internal symbols (the much older
+;; which-func.el library makes liberal use of them, for example).
+
+;;; Todo:
+
+;; Make more clicky buttons in the headerline to do whatever
;;; Code:
(require 'cl-lib)
@@ -100,7 +99,7 @@
(require 'project)
\f
-;;; Customization options
+;;;; Customization options
(defgroup breadcrumb nil
"One-liner indication of where you are in the maze."
@@ -147,8 +146,8 @@ percentage of `window-width'."
"Face for the project leaf crumb in breadcrumb project path.")
\f
-;;; "ipath" management logic and imenu interoperation
-;;;
+;;;; "ipath" management logic and imenu interoperation
+
(cl-defun bc--bisect (a x &key (from 0) (to (length a)) key from-end)
"Compute index to insert X in sequence A, keeping it sorted.
If X already in A, the resulting index is the leftmost such
@@ -244,7 +243,7 @@ These structures don't have a `breadcrumb-region' property on."
imenu--index-alist))
\f
-;;; Higher-level functions
+;;;; Higher-level functions
;; FIXME: Why do I need to put these key definitiosn in special
;; variables?
[-- Attachment #3: Type: text/plain, Size: 163 bytes --]
You can see the effect this as in practice by enabling
outline-minor-mode and running M-x outline-hide-body before and after
applying the changes.
> João
^ permalink raw reply related [relevance 41%]
* Re: [NonGNU ELPA] New package: flymake-guile
@ 2023-09-05 16:01 92% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-09-05 16:01 UTC (permalink / raw)
To: Distopico; +Cc: emacs-devel
Distopico <distopico@riseup.net> writes:
> On 2023-09-05, Philip Kaludercic <philipk@posteo.net> wrote:
>
>> 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?
>
> Thank you,
No problem :)
> About the process I'm not sure about it, how I publish a
> new version? I guess is just update version in the repo but not sure
> if I need to do something more
No, all you need to do is to bump the version tag in the package header,
and that commit will be used to create a new release tarball. You can
also check out the NonGNU ELPA package guidelines[0], but I don't assume
there should be any issues here wrt non-free dependencies, since Guile
is firmly free software.
If you change anything and want to see how the ELPA build server handled
the change without triggering a release, you can check the "NonGNU
ELPA-devel" repository, that creates a new release for each individual
commit: https://elpa.nongnu.org/nongnu-devel/.
[0] https://git.savannah.gnu.org/cgit/emacs/nongnu.git/tree/README.org#n118
^ permalink raw reply [relevance 92%]
* 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: 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: [NonGNU ELPA] New package: flymake-guile
@ 2023-09-05 7:08 99% ` Philip Kaludercic
0 siblings, 1 reply; 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 6:21 96% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-09-05 6:21 UTC (permalink / raw)
To: João Távora; +Cc: emacs-devel
João Távora <joaotavora@gmail.com> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> João Távora <joaotavora@gmail.com> writes:
>
>>> Here's a link to the project (which has a screenshot)
>>> https://github.com/joaotavora/breadcrumb
>>
>> Looks nice! I have no notable comments on the code, except that the
>> indentation out of place in two parts of the file.
>
> Thanks, I just spotted that and will fix briefly.
1+
>>> Here's the patch for elpa.git
>>>
>>> diff --git a/elpa-packages b/elpa-packages
>>> index 7bbf35a..cfceb7e 100644
>>> --- a/elpa-packages
>>> +++ b/elpa-packages
>>> @@ -99,6 +99,9 @@
>>> (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")
>>> + (breadcrumb :url "https://github.com/joaotavora/breadcrumb"
>>> + :readme "README.md"
>>
>> Are you sure you want to use the README.md file to generate the package
>> description, or wouldn't you rather rely on the Commentary section?
>
> Better rely on the Commentary, yes. Just consider remove that line
> removed from the patch.
Ok.
>> Having a "Screenshot" heading followed by nothing might look weird.
>>
>>> + :ignored-files ("screenshot.png"))
>>
>> 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.
> João
^ permalink raw reply [relevance 96%]
* Re: master 82cc1f4fda1: Revert use of seq-count in shr-count
[not found] ` <20230904193238.46053C04DB0@vcs2.savannah.gnu.org>
@ 2023-09-04 20:54 98% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-09-04 20:54 UTC (permalink / raw)
To: emacs-devel; +Cc: Stefan Kangas
Stefan Kangas <stefankangas@gmail.com> writes:
> branch: master
> commit 82cc1f4fda19a635cc29577a4da051cf3e062afe
> Author: Stefan Kangas <stefankangas@gmail.com>
> Commit: Stefan Kangas <stefankangas@gmail.com>
>
> Revert use of seq-count in shr-count
>
> * lisp/net/shr.el (shr-count): Prefer handwritten code to using
> 'seq-count', as it's more performant.
> Problem reported by Mattias Engdegård <mattiase@acm.org>.
With seq becoming more and more popular, is there any conceivable way of
making it faster as well? The overhead of generic functional-call
dispatching always has me weary of using the library, or at the very
least has me think about it twice as it is convenient. Is there some
way to use the type inference that native compilation appears to provide
to statically determine what implementation to use?
> ---
> lisp/net/shr.el | 11 +++++++----
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/lisp/net/shr.el b/lisp/net/shr.el
> index 84033c31ef4..645e1cc51e5 100644
> --- a/lisp/net/shr.el
> +++ b/lisp/net/shr.el
> @@ -2617,10 +2617,13 @@ flags that control whether to collect or render objects."
> columns))
>
> (defun shr-count (dom elem)
> - (seq-count (lambda (sub)
> - (and (not (stringp sub))
> - (eq (dom-tag sub) elem)))
> - (dom-children dom)))
> + ;; This is faster than `seq-count', and shr can use it.
> + (let ((i 0))
> + (dolist (sub (dom-children dom))
> + (when (and (not (stringp sub))
> + (eq (dom-tag sub) elem))
> + (setq i (1+ i))))
> + i))
>
> (defun shr-max-columns (dom)
> (let ((max 0)
^ permalink raw reply [relevance 98%]
* 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: [ELPA] New package: breadcrumb.el
@ 2023-09-04 20:47 98% ` Philip Kaludercic
1 sibling, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-09-04 20:47 UTC (permalink / raw)
To: João Távora; +Cc: emacs-devel
João Távora <joaotavora@gmail.com> writes:
> Hi all
>
> I'd like to add my package "breadcrumb" to GNU ELPA.
>
> Breadcrumbs are a a "header-line" indication of where you are in a large
> project, both in terms of "which file"and "where point is within a
> file". You turn this on with breadcrumb-mode.
>
> Here's a link to the project (which has a screenshot)
> https://github.com/joaotavora/breadcrumb
Looks nice! I have no notable comments on the code, except that the
indentation out of place in two parts of the file.
>
> breadcrumb.el uses information derived from existing Emacs libraries
> imenu.el and project.el. It has some points in common with
> "which-func.el" but is simpler (and faster).
>
> You don't really have to put "breadcrumbs" in the header-line (I don't)
> so the package also come with some lower-level utils so you can plug this
> into mode-line-format however you see fit.
>
> I created this package some time ago to answer some common feature
> requests for Eglot, but it turned out somewhat more generic and works
> nicely with or without Eglot. I recently cleaned it up a little and
> implemented some pendingfeature requests like faces and mouse stuff.
>
> There are a few few TODOs/FIXMEs to help out with, of course.
>
> Here's the patch for elpa.git
>
> diff --git a/elpa-packages b/elpa-packages
> index 7bbf35a..cfceb7e 100644
> --- a/elpa-packages
> +++ b/elpa-packages
> @@ -99,6 +99,9 @@
> (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")
> + (breadcrumb :url "https://github.com/joaotavora/breadcrumb"
> + :readme "README.md"
Are you sure you want to use the README.md file to generate the package
description, or wouldn't you rather rely on the Commentary section?
Having a "Screenshot" heading followed by nothing might look weird.
> + :ignored-files ("screenshot.png"))
If possible, it would be nice to track this on your end with a
.elpaignore file.
> (brief :url nil)
> (buffer-env :url "https://github.com/astoff/buffer-env")
> (buffer-expose :url "https://github.com/clemera/buffer-expose")
^ permalink raw reply [relevance 98%]
* Re: package-autosuggest
@ 2023-09-04 16:10 95% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-09-04 16:10 UTC (permalink / raw)
To: chad; +Cc: Stefan Monnier, Eshel Yaron, Stefan Kangas, emacs-devel
chad <yandros@gmail.com> writes:
> This might be over-engineering at this point, but it was my not-so-secret
> hope when suggesting along this line that there would be a good place to
> add a branch in the middle, where the system would offer more than one
> (incompatible, at least sometimes) choice to the user, with the hope of
> eventually being a bridge to "hey, this looks like C-Sharp. Would you like
> c-sharp-ts-mode or CC-mode for this? (Now/future/ask again later)"
From my testing, a prompt like this seems too aggressive and annoying.
The best alternative, it seems to me is a message in the echo area or a
lighter in the mode line. I am leaning more and more towards the
latter, since might make the most mouse-friendly interface that
newcomers are likely to appreciate.
> and
> maybe also "This is probably Perl or Prolog code. Would you like perl-mode,
> cperl-mode, perl-ts-mode, prolog-mode, or...."
My last proposal used completing-read-multiple, but another idea would
be to pop open a filtered down *Packages* buffer, assuming that isn't to
confusing of an interface.
> I hope this helps,
> ~Chad
^ permalink raw reply [relevance 95%]
* 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: Brand new clojure support in Emacs ;-)
@ 2023-09-03 16:03 77% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-09-03 16:03 UTC (permalink / raw)
To: Bozhidar Batsov
Cc: João Távora, Richard Stallman, Danny Freeman,
Eli Zaretskii, Emacs Devel, Manuel Uberti
"Bozhidar Batsov" <bozhidar@batsov.dev> writes:
>> Of course, it would be even better if you and your co-maintainers could
>> be convinced to distribute clojure-mode along with Emacs (again, this
>> doesn't mean development must be moved away from GitHub), but just like
>> with CC-mode, Org, cperl, Modus-Themes, releases would just have to be
>> synchronised with the core. But IIUC, your main issues is the copyright
>> assignment and the concern that it might limit who might contribute,
>> right?
>
> Other than the contributor agreement there's development overhead to consider:
>
> - where are issues reported? I don't want to use the Emacs issue
> tracker, but that'd be unavoidable for something built-in, so instead
> of having one issue tracker you end up with two (one of which I really
> dislike)
> - some patches will be submitted on GitHub, some on emacs-devel - I highly doubt that all the clojure-mode maintainers would be willing to deal with this
> - discussions related to problems/ideas would be happening in different places
To my knowledge, this is not an issue with the packages I have
mentioned. Of course there are exceptions, but to my knowledge
basically all conversation about org-mode happens on their mailing
lists, basically all conversation about the modus themes, happen on
Prot's mailing list/issue trackers.
> - there's also so overhead of keeping the GitHub repo and the code in Emacs in sync
This is a minor point, IMO, and if it is relevant, it will usually be
because of a downstream change that should be upstreamed anyway
(e.g. someone replaced all occurrences of an inefficient construct, and
happens to do so in clojure-mode as well).
> I can go on and on about this - hybrid development models simply come
> with a lot of overhead.
The mistake I want to emphasise here is that this is not a "hybrid
development model". Development continues on your own terms, and just
gets copied over into emacs.git on a regular basis.
> I get that here many people think that GitHub
> is the root of all evil, but political preferences aside - it's the
> largest forge in the world by a huge margin and I think it provides
> unique benefits to projects that can't be replicated elsewhere. At
> least not today.
While I disagree, especially with GitHubs recent 2FA push, IIUC I just
want to clarify that this is not what is being discussed.
Other than these points, is the CA the only major issue. Or to put it
differently, if you could state the conditions for clojure-mode to be
distributed with Emacs, what would your conditions be? My point here is
just to clarify if there is a solution to this discussion -- in which
case I think it is worth continuing it -- of if you /want to not want
to/ have clojure-mode added to core Emacs?
>
> On Sun, Sep 3, 2023, at 5:19 PM, Philip Kaludercic wrote:
>> "Bozhidar Batsov" <bozhidar@batsov.dev> writes:
>>
>> >> I would guess that anyone who is seriously interested in working with
>> >> Clojure, would install the proper major mode and the proper package
>> >
>> > That's one of the things that bother me the most in the conversations
>> > so far - lots of people tell us what the Clojure users need, but other
>> > than me and Danny, no one here has any real interest in Clojure. :-)
>> > Without an understanding of Clojure and its tooling ecosystem (and
>> > it's history) it's hard to make good suggestions about what makes
>> > sense and what doesn't.
>>
>> This suggestion comes from a different point of view, namely that if I
>> open a clojure file, that I have anything else but fundamental mode to
>> structure the file. And if it is true that LSP integration could
>> provide xref, imenu, capf, etc. support, one would come a long way for
>> modest needs with very little code. Just like with the common-lisp
>> mode, the support is of course better if you install SLIME or Sly, but
>> having some basic OOTB support is already a good thing and all this
>> thread started out with.
>>
>> Of course, it would be even better if you and your co-maintainers could
>> be convinced to distribute clojure-mode along with Emacs (again, this
>> doesn't mean development must be moved away from GitHub), but just like
>> with CC-mode, Org, cperl, Modus-Themes, releases would just have to be
>> synchronised with the core. But IIUC, your main issues is the copyright
>> assignment and the concern that it might limit who might contribute,
>> right?
>>
>> > I already wrote we tried the "thin layer on top of lisp-mode" and this
>> > didn't worked out great in the past. Of course, people are welcome to
>> > try and learn from experience themselves if they thing they can do
>> > things better/differently.
>> >
>> > On Wed, Aug 30, 2023, at 9:17 AM, Philip Kaludercic wrote:
>> >> João Távora <joaotavora@gmail.com> writes:
>> >>
>> >> > On Fri, Aug 25, 2023 at 8:26 AM Philip Kaludercic <philipk@posteo.net> wrote:
>> >> >>
>> >> >> 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 appears that there is no clojure-mode command in core Emacs.
>> >> >> > There is a Clojure mode package, but it is in NonGNU ELPA.
>> >> >> >
>> >> >> > I think that language is important enough that, notwithstanding not
>> >> >> > really being similar to Lisp, we ought to have a major mode to support it.
>> >> >> > Would someone please work on that?
>> >> >>
>> >> >> I had brought this up in the recent clojure-ts-mode thread, that I
>> >> >> assume you are referring to. Sadly, I have no experience with the
>> >> >> language, but one idea might be to extend lisp-data-mode by whatever the
>> >> >
>> >> > I don't know if this counts as "work on that" but here's two interesting lines
>> >> > Elisp:
>> >> >
>> >> > (define-derived-mode clojure-mode lisp-data-mode "Clojure"
>> >> > "Barebones Clojure")
>> >> > (add-to-list 'auto-mode-alist '("\\.clj" . clojure-mode))
>> >>
>> >> I suggested something along these lines up the thread, but didn't try it
>> >> out myself. Nice to see that the idea works. To avoid confusion, I
>> >> think it might be a good idea to not call this `clojure-mode' as well,
>> >> but something like "clojure-proto-mode" or "primitive-clojure-mode".
>> >>
>> >> > Since it is a lisp dialect many things works here, like indentation,
>> >> > symbol recognition, parenthesis balancing, C-M navigation, and thing-at-point.
>> >> >
>> >> > And then there's LSP, right?
>> >> >
>> >> > So I installed clojure-lsp from here:
>> >> > https://aur.archlinux.org/packages/clojure-lsp-bin
>> >> >
>> >> > I created a hello world project with the "lein" tool, git init, found the
>> >> > src/helloworld/core.clj inside it, pressed M-x eglot and suddenly I had
>> >> > at-point-documentation, diagnostics, lots of refactorings, completion, etc.
>> >> >
>> >> > The thing that's a bit minimal is the syntax highlighting, but it's
>> >> > not that bad either IMHO. Eglot doesn't yet support LSP-mandated syntax
>> >> > highlighting. I have no idea what it takes to add TreeSitter support
>> >> > to such a bare-bones mode (but shouldn't it be really easy like mapping
>> >> > syntactic symbols to faces?)
>> >> >
>> >> > No idea if this works with the CIDER or SLIME backends for clojure.
>> >> > Don't ask me to test any more cause I've just uninstalled it all
>> >> > but any clojurians rading can have a go.
>> >>
>> >> I would guess that anyone who is seriously interested in working with
>> >> Clojure, would install the proper major mode and the proper packages.
>> >>
>> >> > João
>> >>
>> >>
>>
^ permalink raw reply [relevance 77%]
* Re: Brand new clojure support in Emacs ;-)
@ 2023-09-03 15:19 83% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-09-03 15:19 UTC (permalink / raw)
To: Bozhidar Batsov
Cc: João Távora, Richard Stallman, Danny Freeman,
Eli Zaretskii, Emacs Devel, Manuel Uberti
"Bozhidar Batsov" <bozhidar@batsov.dev> writes:
>> I would guess that anyone who is seriously interested in working with
>> Clojure, would install the proper major mode and the proper package
>
> That's one of the things that bother me the most in the conversations
> so far - lots of people tell us what the Clojure users need, but other
> than me and Danny, no one here has any real interest in Clojure. :-)
> Without an understanding of Clojure and its tooling ecosystem (and
> it's history) it's hard to make good suggestions about what makes
> sense and what doesn't.
This suggestion comes from a different point of view, namely that if I
open a clojure file, that I have anything else but fundamental mode to
structure the file. And if it is true that LSP integration could
provide xref, imenu, capf, etc. support, one would come a long way for
modest needs with very little code. Just like with the common-lisp
mode, the support is of course better if you install SLIME or Sly, but
having some basic OOTB support is already a good thing and all this
thread started out with.
Of course, it would be even better if you and your co-maintainers could
be convinced to distribute clojure-mode along with Emacs (again, this
doesn't mean development must be moved away from GitHub), but just like
with CC-mode, Org, cperl, Modus-Themes, releases would just have to be
synchronised with the core. But IIUC, your main issues is the copyright
assignment and the concern that it might limit who might contribute,
right?
> I already wrote we tried the "thin layer on top of lisp-mode" and this
> didn't worked out great in the past. Of course, people are welcome to
> try and learn from experience themselves if they thing they can do
> things better/differently.
>
> On Wed, Aug 30, 2023, at 9:17 AM, Philip Kaludercic wrote:
>> João Távora <joaotavora@gmail.com> writes:
>>
>> > On Fri, Aug 25, 2023 at 8:26 AM Philip Kaludercic <philipk@posteo.net> wrote:
>> >>
>> >> 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 appears that there is no clojure-mode command in core Emacs.
>> >> > There is a Clojure mode package, but it is in NonGNU ELPA.
>> >> >
>> >> > I think that language is important enough that, notwithstanding not
>> >> > really being similar to Lisp, we ought to have a major mode to support it.
>> >> > Would someone please work on that?
>> >>
>> >> I had brought this up in the recent clojure-ts-mode thread, that I
>> >> assume you are referring to. Sadly, I have no experience with the
>> >> language, but one idea might be to extend lisp-data-mode by whatever the
>> >
>> > I don't know if this counts as "work on that" but here's two interesting lines
>> > Elisp:
>> >
>> > (define-derived-mode clojure-mode lisp-data-mode "Clojure"
>> > "Barebones Clojure")
>> > (add-to-list 'auto-mode-alist '("\\.clj" . clojure-mode))
>>
>> I suggested something along these lines up the thread, but didn't try it
>> out myself. Nice to see that the idea works. To avoid confusion, I
>> think it might be a good idea to not call this `clojure-mode' as well,
>> but something like "clojure-proto-mode" or "primitive-clojure-mode".
>>
>> > Since it is a lisp dialect many things works here, like indentation,
>> > symbol recognition, parenthesis balancing, C-M navigation, and thing-at-point.
>> >
>> > And then there's LSP, right?
>> >
>> > So I installed clojure-lsp from here:
>> > https://aur.archlinux.org/packages/clojure-lsp-bin
>> >
>> > I created a hello world project with the "lein" tool, git init, found the
>> > src/helloworld/core.clj inside it, pressed M-x eglot and suddenly I had
>> > at-point-documentation, diagnostics, lots of refactorings, completion, etc.
>> >
>> > The thing that's a bit minimal is the syntax highlighting, but it's
>> > not that bad either IMHO. Eglot doesn't yet support LSP-mandated syntax
>> > highlighting. I have no idea what it takes to add TreeSitter support
>> > to such a bare-bones mode (but shouldn't it be really easy like mapping
>> > syntactic symbols to faces?)
>> >
>> > No idea if this works with the CIDER or SLIME backends for clojure.
>> > Don't ask me to test any more cause I've just uninstalled it all
>> > but any clojurians rading can have a go.
>>
>> I would guess that anyone who is seriously interested in working with
>> Clojure, would install the proper major mode and the proper packages.
>>
>> > João
>>
>>
^ permalink raw reply [relevance 83%]
* 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: master c290b034e0f 1/2: Move `wholenump` alias definition
[not found] ` <20230903094826.33FFAC045B5@vcs2.savannah.gnu.org>
@ 2023-09-03 9:54 98% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-09-03 9:54 UTC (permalink / raw)
To: emacs-devel; +Cc: Mattias Engdegård
Mattias Engdegård <mattiase@acm.org> writes:
> branch: master
> commit c290b034e0f9a2660e455b9dad471ff54c7a840c
> Author: Mattias Engdegård <mattiase@acm.org>
> Commit: Mattias Engdegård <mattiase@acm.org>
>
> Move `wholenump` alias definition
>
> * src/data.c (syms_of_data): From here...
> * lisp/subr.el (wholenump): ...to here, with the other aliases.
> ---
> lisp/subr.el | 1 +
> src/data.c | 2 --
> 2 files changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/lisp/subr.el b/lisp/subr.el
> index 47fcbc2f317..0894a644d28 100644
> --- a/lisp/subr.el
> +++ b/lisp/subr.el
> @@ -2021,6 +2021,7 @@ instead; it will indirectly limit the specpdl stack size as well.")
> (defalias 'store-match-data #'set-match-data)
> (defalias 'chmod #'set-file-modes)
> (defalias 'mkdir #'make-directory)
> +(defalias 'wholenump #'natnump)
I didn't know about this function (even though it appears to go back to
Emacs 19), but it might be confusing to some people. In German "Ganze
Zahlen" (literally "whole numbers") is the term for integers, but
apparently Wikipedia[0] mentions that the term is ambiguous and might
refer both to ℤ and ℕ. Is there anything that can be done about this?
[0] https://en.wikipedia.org/wiki/Whole_number
>
> ;; These were the XEmacs names, now obsolete:
> (defalias 'point-at-eol #'line-end-position)
> diff --git a/src/data.c b/src/data.c
> index 377bcfce35d..9d6bf5a142c 100644
> --- a/src/data.c
> +++ b/src/data.c
> @@ -4369,8 +4369,6 @@ syms_of_data (void)
> defsubr (&Sbool_vector_count_consecutive);
> defsubr (&Sbool_vector_count_population);
>
> - set_symbol_function (Qwholenump, XSYMBOL (Qnatnump)->u.s.function);
> -
> DEFVAR_LISP ("most-positive-fixnum", Vmost_positive_fixnum,
> doc: /* The greatest integer that is represented efficiently.
> This variable cannot be set; trying to do so will signal an error. */);
^ permalink raw reply [relevance 98%]
* 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: 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: [NonGNU ELPA] New package: hyperdrive (repast)
2023-08-29 11:56 99% ` Philip Kaludercic
@ 2023-09-03 8:18 45% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-09-03 8:18 UTC (permalink / raw)
To: Joseph Turner
Cc: Emacs Devel Mailing List, Adam Porter, Paula Maas,
Protesilaos Stavrou
[-- Attachment #1: Type: text/plain, Size: 2191 bytes --]
Philip Kaludercic <philipk@posteo.net> writes:
> 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
Done. Overall it looks fine, and I'll add the
package to NonGNU ELPA, it would be nice if you could take a look and
consider addressing the changes I propose and comments I made:
[-- Attachment #2: Type: text/plain, Size: 7212 bytes --]
diff --git a/hyperdrive-lib.el b/hyperdrive-lib.el
index 43ca32e3cb..d77b3d1e3c 100644
--- a/hyperdrive-lib.el
+++ b/hyperdrive-lib.el
@@ -1034,6 +1034,8 @@ Affected by option `hyperdrive-reuse-buffers', which see."
"Call `message' with MESSAGE and ARGS, prefixing MESSAGE with \"Hyperdrive:\"."
(apply #'message (concat "Hyperdrive: " message) args))
+;; Might be nice to use `define-error' for `condition-case' to detect
+;; this as a specific error type?
(defun hyperdrive-error (string &rest args)
"Call `error' with STRING and ARGS, prefixing STRING with \"Hyperdrive:\"."
(apply #'error (concat "Hyperdrive: " string) args))
@@ -1099,6 +1101,8 @@ When BASE is non-nil, PATH will be expanded against BASE instead."
;; of Emacs (going back to the version we declare support for), for
;; features that aren't present in `compat'.
+;; If there is anything you'd like to see in Compat, please mention it.
+
(eval-and-compile
(if (< emacs-major-version 29)
(define-derived-mode hyperdrive-clean-mode fundamental-mode "Clean"
diff --git a/hyperdrive-mirror.el b/hyperdrive-mirror.el
index caa9e881b7..27113c5052 100644
--- a/hyperdrive-mirror.el
+++ b/hyperdrive-mirror.el
@@ -166,7 +166,7 @@ predicate and set NO-CONFIRM to t."
;;;; Mode
(defvar-keymap hyperdrive-mirror-mode-map
- :parent tabulated-list-mode-map
+ :parent tabulated-list-mode-map
:doc "Local keymap for `hyperdrive-mirror-mode' buffers."
"C-c C-c" #'hyperdrive-mirror-do-upload)
diff --git a/hyperdrive-vars.el b/hyperdrive-vars.el
index afc3cf6ef5..ba59e042d9 100644
--- a/hyperdrive-vars.el
+++ b/hyperdrive-vars.el
@@ -39,18 +39,15 @@
(defcustom hyperdrive-storage-location
(expand-file-name "~/.local/share/hyper-gateway-nodejs/")
"Location to store Hypercore data."
- :type '(file :must-match t)
- :group 'hyperdrive)
+ :type '(file :must-match t))
(defcustom hyperdrive-hyper-gateway-port 4973
"Port on which to run the hyper-gateway server."
- :type 'natnum
- :group 'hyperdrive)
+ :type 'natnum)
(defcustom hyperdrive-honor-auto-mode-alist t
"If non-nil, use file extension of hyperdrive file to set `major-mode'."
- :type 'boolean
- :group 'hyperdrive)
+ :type 'boolean)
(defcustom hyperdrive-persist-location nil
"Location where `persist' will store data.
@@ -58,19 +55,18 @@
- `hyperdrive-hyperdrives'
- `hyperdrive-version-ranges'"
:type '(choice (const :tag "Use default persist location" nil)
- (file :tag "Custom location"))
- :group 'hyperdrive)
-
-(defcustom hyperdrive-download-directory (expand-file-name
- (if (bound-and-true-p eww-download-directory)
- (if (stringp eww-download-directory)
- eww-download-directory
- (funcall eww-download-directory))
- "~/"))
+ (file :tag "Custom location")))
+
+(defcustom hyperdrive-download-directory
+ (expand-file-name
+ (if (bound-and-true-p eww-download-directory)
+ (if (stringp eww-download-directory)
+ eww-download-directory
+ (funcall eww-download-directory))
+ "~/"))
"Location where `hyperdrive-download-url' will download files.
Defaults to `eww-download-directory'."
- :type '(file :must-match t)
- :group 'hyperdrive)
+ :type '(file :must-match t))
(defvar hyperdrive-timestamp-format-string)
(defcustom hyperdrive-timestamp-format "%x %X"
@@ -78,20 +74,20 @@ Defaults to `eww-download-directory'."
Passed to `format-time-string', which see."
:type 'string
:set (lambda (option value)
- (set option value)
+ (set-default option value)
(setf hyperdrive-timestamp-format-string
(format "%%%ds"
;; FIXME: This value varies based on current
;; time. (format-time-string "%-I") will
;; be one or two characters long
;; depending on the time of day
- (string-width (format-time-string value)))))
- :group 'hyperdrive)
+ (string-width (format-time-string value))))))
(defcustom hyperdrive-directory-display-buffer-action
'(display-buffer-same-window)
"Display buffer action for hyperdrive directories.
Passed to `display-buffer', which see."
+ ;; Perhaps use `display-buffer--action-custom-type'?
:type '(choice (const :tag "Same window" (display-buffer-same-window))
(const :tag "Pop up window" (display-buffer-pop-up-window))
(sexp :tag "Other"))
@@ -103,13 +99,11 @@ Passed to `display-buffer', which see."
Passed to `display-buffer', which see."
:type '(choice (const :tag "Same window" (display-buffer-same-window))
(const :tag "Pop up window" (display-buffer-pop-up-window))
- (sexp :tag "Other"))
- :group 'hyperdrive)
+ (sexp :tag "Other")))
-(defcustom hyperdrive-column-headers 't
+(defcustom hyperdrive-column-headers t
"Display column headers in `hyperdrive-dir' and `hyperdrive-history' buffers."
- :type 'boolean
- :group 'hyperdrive)
+ :type 'boolean)
(defcustom hyperdrive-default-host-format
'(petname nickname domain seed short-key public-key)
@@ -125,8 +119,7 @@ used."
(const :tag "DNSLink domain" domain)
(const :tag "Seed" seed)
(const :tag "Shortened public key" short-key)
- (const :tag "Full public key" public-key)))
- :group 'hyperdrive)
+ (const :tag "Full public key" public-key))))
(defcustom hyperdrive-stream-player-command "mpv --force-window=immediate %s"
"Command used to play streamable URLs externally.
@@ -135,19 +128,17 @@ quoted, because the arguments are passed directly rather than
through a shell)."
:type '(choice (const :tag "MPV" "mpv --force-window=immediate %s")
(const :tag "VLC" "vlc %s")
- (string :tag "Other command"))
- :group 'hyperdrive)
+ (string :tag "Other command")))
(defcustom hyperdrive-queue-size 2
"Default size of request queues."
;; TODO: Use this elsewhere also.
- :type 'integer
- :group 'hyperdrive)
+ :type 'integer) ;natnum?
+
(defcustom hyperdrive-render-html t
"Render HTML hyperdrive files with EWW."
- :type 'boolean
- :group 'hyperdrive)
+ :type 'boolean)
(defcustom hyperdrive-reuse-buffers 'any-version
"How to reuse buffers when showing entries.
diff --git a/hyperdrive.el b/hyperdrive.el
index f3024417ae..c94da62fb0 100644
--- a/hyperdrive.el
+++ b/hyperdrive.el
@@ -2,9 +2,9 @@
;; Copyright (C) 2022 Joseph Turner <joseph@ushin.org>
-;; Author: Joseph Turner
+;; Author: Joseph Turner <joseph@ushin.org>
;; Author: Adam Porter <adam@alphapapa.net>
-;; Maintainer: Joseph Turner <joseph@ushin.org>
+;; Maintainer: Joseph Turner <~ushin/ushin@lists.sr.ht>
;; Created: 2022
;; Version: 0.2-pre
;; Package-Requires: ((emacs "27.1") (map "3.0") (compat "29.1.4.0") (plz "0.7") (persist "0.5"))
^ permalink raw reply related [relevance 45%]
* 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: 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-01 13:50 67% ` Monthy emacs-devel digest, similar to "This month in Org" Philip Kaludercic
@ 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: package-autosuggest
@ 2023-09-01 15:47 99% ` Philip Kaludercic
0 siblings, 1 reply; 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: New Package for NonGNU-ELPA: clojure-ts-mode
@ 2023-09-01 14:55 82% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-09-01 14:55 UTC (permalink / raw)
To: Jens Schmidt
Cc: Ihor Radchenko, Po Lu, Dmitry Gutov, Stefan Kangas, Danny Freeman,
Eli Zaretskii, emacs-devel, manuel.uberti
Jens Schmidt <jschmidt4gnu@vodafonemail.de> writes:
>> Some people are afraid of communicating with the mailing list or
>> reporting bugs because of an image issue. I have on more than one
>> occasion heard of people who intentionally avoid communicating with
>> emacs-devel due to bad experience. Others fear sending a message out
>> into the blue and not knowing who will read and respond to what they
>> said, will they be shouted down or just ignored.
>
> Exactly. TBH I still have to assemble courage to post here. All these
> top dogs with their super-dry yet elaborate communication style are
> surely, um, intimidating. Po Lu's mails, to pick one example, are a
> constant source of new English vocabulary for me (recent addition:
> "brazen"). But at least RMS lets slip in some typos in his mails...
I think everyone makes mistakes sometimes when posting here. I can't
count the number of times when I added the wrong patch, forgot to CC
everyone, responded to the wrong message, misunderstood someones point
entirely, typos .... and nobody really cares. If I see someone make a
mistake, I just gloss over it (unless it affects me or I can help in
some way).
The fear you describe is relatable, my first message to the Emacs
developers was written just over 4½ years ago, and I have only been
contributing more regularly for about 3 years. That being said, I
cannot explain the fact that I don't worry about every message, other
than if you send normal and kind messages, you get normal and kind
responses.
>> 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.
>
> Mixing the "help" mailing list with the "devel" mailing list is another
> things that makes Org more attractive to users, I guess. It feels more
> democratic. But then, Org feels more bazaar-like, as a whole, and Emacs
> more cathedral-like.
Democratic is a weird word to use here, IMO. Either way, I think it
makes sense to split between development-talk and regular help. There
is a lot of weird noise on help-gnu-emacs@ that really don't have
to make reading emacs-devel@ any more difficult.
^ permalink raw reply [relevance 82%]
* Re: package-autosuggest
@ 2023-09-01 14:40 87% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-09-01 14:40 UTC (permalink / raw)
To: Eshel Yaron; +Cc: Stefan Kangas, Stefan Monnier, emacs-devel
Eshel Yaron <me@eshelyaron.com> writes:
> Hello Stefan,
>
> Stefan Kangas <stefankangas@gmail.com> writes:
>
>> Eshel Yaron <me@eshelyaron.com> writes:
>>
>>> That'd indeed already be an improvement, my point is that in some cases
>>> we would know that it really is the right package with very high
>>> certainty.
>>
>> Shouldn't that just be the criterion, then? In other words, isn't
>> that what it would mean to only recommend things that are likely to be
>> helpful?
>
> I'm not sure. In Philip's draft, I don't think that this is the case.
> (Correct me if I've missed anything, please.)
The assumption in my draft was that the database would only be
populated with entries that would be considered helpful, or rather if
the database were to be generated from GNU ELPA and NonGNU ELPA
packages, it shouldn't recommend unhelpful packages, as all packages in
GNU and NonGNU ELPA are supposed to be helpful in the first place.
> The way I see it there
> are two parameters to consider for each recommendation. Let's call them
> potential and confidence. Potential is how much value the user can
> obtain from Emacs's recommendation. That depends mostly on the
> recommended package itself. Confidence is how certain Emacs is that
> this user should use this package. For example, again, in the current
> draft we have a recommendation for `sml-mode` based on files with
> extension `.sml`. This recommendation has great potential to benefit
> Standard ML users (I assume, I haven't tried it out myself), but the
> confidence for this recommendation isn't that high, because it's prone
> to false positives (not all `.sml` files are Standard ML).
That is a legitimate point, but one that Emacs suffers from in general.
I frequently find Perl and Prolog files that both end in .pl, but there
can only be one entry in auto-mode-list (unless you manually do a
`c-or-c++-mode').
> The crux is that the quality of a recommendation depends not only on the
> quality of the package but also on the strength of the signal that leads
> Emacs to recommend it (the quality of the "hint").
So are you thinking of a numerical value? And wouldn't the value depend
on the file contents? And how do you think this valuation should be
used?
> Personally, I think that even with a chance of false positives,
> suggesting `sml-mode` to a user that opens `foo.sml` is great. For this
> reason, I proposed that Emacs should make both high-confidence and
> low-confidence recommendations, but use different messages for the two
> cases (or three, if you want to also have "medium-confidence").
The current proposal wouldn't install anything automatically anyway, it
would prompt the user if they are interested in this kind of a file
>
> Best,
>
> Eshel
^ permalink raw reply [relevance 87%]
* Re: [NonGNU ELPA] New package: flymake-guile
@ 2023-09-01 14:23 50% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-09-01 14:23 UTC (permalink / raw)
To: Distopico; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 2552 bytes --]
Distopico <distopico@riseup.net> writes:
> On 2023-09-01, 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:
>>>>
>>>>> 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.
>
> 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:
[-- Attachment #2: Type: text/plain, Size: 6091 bytes --]
diff --git a/flymake-guile.el b/flymake-guile.el
index d4b17b6..da64903 100644
--- a/flymake-guile.el
+++ b/flymake-guile.el
@@ -3,7 +3,7 @@
;; Copyright (c) 2023 Camilo Q.S. (Distopico) <distopico@riseup.net>
;; Author: Distopico <distopico@riseup.net>
-;; Package-Requires: ((emacs "26.1") (flymake "1.2.1") (flymake-quickdef "1.0.0"))
+;; Package-Requires: ((emacs "26.1") (flymake "1.2.1"))
;; Keywords: language, tools
;; Version: 0.3
@@ -35,14 +35,12 @@
;;; Code:
-(require 'flymake-quickdef)
-
(defgroup flycheck-guile nil
"GNU Guile Flymake backend."
:prefix "flymake-guile-"
:group 'flymake)
-(defcustom flymake-guile-guild-binary "guild"
+(defcustom flymake-guile-guild-executable "guild"
"Name of the Guile `guild' executable."
:type 'string
:group 'flymake-guile)
@@ -142,47 +140,122 @@ Also verify if the `STACK-FILE' and the source file are te same."
(- col 1))))
text)))
-(flymake-quickdef-backend flymake-guile-backend
- :pre-let ((guild-exec (executable-find flymake-guile-guild-binary)))
- :pre-check (unless guild-exec (error "Cannot find guild executable"))
- :write-type 'file
- :proc-form (append
- (list guild-exec
- "compile"
- "-O0")
- (flymake-guile--warning-level-args)
- (flymake-guile--load-path-args)
- flymake-guile-guild-args
- (list fmqd-temp-file))
- :search-regexp (concat
- "\\(.*\\)"
- flymake-guile--diag-lnum-rx
- "\\(.*\\):[[:space:]]?"
- "\\(Syntax error:[[:space:]].*\\|.*\\)$")
- :prep-diagnostic
- (let* ((stack_file (match-string 1))
- (stack_lnum (match-string 2))
- (stack_cnum (match-string 3))
- (severity (match-string 4))
- (stack_msg (match-string 5))
- (report (flymake-guile--get-diagnostic
- stack_msg
- stack_lnum
- stack_cnum
- stack_file
- fmqd-source))
- (lnum (car (car report)))
- (cnum (cdr (car report)))
- (text (cdr report))
- (pos (flymake-diag-region fmqd-source lnum cnum))
- (beg (car pos))
- (end (cdr pos))
- (type (cond
- ((string= severity "warning") :warning)
- ((string= severity "In procedure raise-exception") :error)
- (t :note)))
- (msg (string-trim text)))
- (list fmqd-source beg end type msg)))
+(defvar-local flymake-guile-process nil)
+
+(defun flymake-make-guile-sentinel (report-fn source temp-dir)
+ "Generate a process sentinel reporting to REPORT-FN.
+The argument SOURCE and TEMP-DIR are respectively used to pass
+the buffer containing the source code being checked and the
+temporary director generated for the checking."
+ (lambda (proc _event)
+ (unless (process-live-p proc)
+ (unwind-protect
+ (if (eq proc (buffer-local-value 'flymake-guile-process source))
+ (with-current-buffer source
+ (save-restriction
+ (widen)
+ (with-current-buffer (process-buffer proc)
+ (goto-char (point-min))
+ (save-match-data
+ (let ((diags nil))
+ (while (search-forward-regexp
+ (concat
+ "\\(.*\\)"
+ flymake-guile--diag-lnum-rx
+ "\\(.*\\):[[:space:]]?"
+ "\\(Syntax error:[[:space:]].*\\|.*\\)$")
+ nil t)
+ (save-match-data
+ (save-excursion
+ (let* ((diag-vals
+ (let* ((stack_file
+ (match-string 1))
+ (stack_lnum
+ (match-string 2))
+ (stack_cnum
+ (match-string 3))
+ (severity
+ (match-string 4))
+ (stack_msg
+ (match-string 5))
+ (report
+ (flymake-guile--get-diagnostic
+ stack_msg
+ stack_lnum
+ stack_cnum
+ stack_file
+ source))
+ (lnum (caar report))
+ (cnum (cdar report))
+ (text (cdr report))
+ (pos
+ (flymake-diag-region
+ source
+ lnum
+ cnum))
+ (beg (car pos))
+ (end (cdr pos))
+ (type
+ (cond
+ ((string= severity "warning") :warning)
+ ((string= severity "In procedure raise-exception")
+ :error)
+ (t :note)))
+ (msg (string-trim text)))
+ (list source beg end type msg)))
+ (diag-beg (nth 1 diag-vals))
+ (diag-end (nth 2 diag-vals))
+ (diag-type (nth 3 diag-vals)))
+ (if (and
+ (integer-or-marker-p diag-beg)
+ (integer-or-marker-p diag-end))
+ (when diag-type
+ (push (apply #'flymake-make-diagnostic diag-vals)
+ diags))
+ (with-current-buffer source
+ (flymake-log
+ :error
+ "Got invalid buffer position %s or %s in %s"
+ diag-beg
+ diag-end
+ proc)))))))
+ (funcall
+ report-fn
+ (nreverse
+ diags)))))))
+ (flymake-log :warning
+ "Canceling obsolete check %s"
+ proc))
+ (delete-directory temp-dir t)
+ (kill-buffer (process-buffer proc))))))
+
+(defun flymake-guile-backend (report-fn &rest _args)
+ "Flymake backend for Scheme buffers using GNU Guile.
+For the interpretation of REPORT-FN, consult the Info
+node `(flymake) Backend functions'."
+ (let* ((guild-exec (or (executable-find flymake-guile-guild-executable)
+ (error "Cannot find guild executable")))
+ (temp-dir (make-temp-file "flymake-guile-" t))
+ (temp-file (expand-file-name
+ (file-name-nondirectory (or (buffer-file-name) (buffer-name)))
+ temp-dir)))
+ (when (process-live-p flymake-guile-process)
+ (kill-process flymake-guile-process))
+ (save-restriction
+ (widen)
+ (write-region nil nil temp-file nil 'silent)
+ (setq flymake-guile-process
+ (make-process
+ :name "flymake-guile-backend-flymake"
+ :noquery t :connection-type 'pipe
+ :buffer (generate-new-buffer " *flymake-guile-backend-flymake*")
+ :sentinel (flymake-make-guile-sentinel report-fn (current-buffer) temp-dir)
+ :command
+ (append (list guild-exec "compile" "-O0")
+ (flymake-guile--warning-level-args)
+ (flymake-guile--load-path-args)
+ flymake-guile-guild-args
+ (list temp-file)))))))
;;;###autoload
(defun flymake-guile ()
^ permalink raw reply related [relevance 50%]
* 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: Monthy emacs-devel digest, similar to "This month in Org"
@ 2023-09-01 13:50 67% ` Philip Kaludercic
2023-09-02 19:17 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-09-01 13:50 UTC (permalink / raw)
To: Ihor Radchenko
Cc: Timothy, Sacha Chua, Po Lu, Dmitry Gutov, Stefan Kangas,
Danny Freeman, Eli Zaretskii, emacs-devel, manuel.uberti
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 67%]
* Re: Choice of bug tracker
@ 2023-09-01 13:24 86% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-09-01 13:24 UTC (permalink / raw)
To: Visuwesh
Cc: Dmitry Gutov, Eli Zaretskii, Stefan Kangas, Michael Albinus,
emacs-devel
Visuwesh <visuweshm@gmail.com> writes:
> As for submitting patches, I much much much much prefer the Emacs way™.
> It is so much better than forking the repo, creating a new branch,
> fighting with Git to merge/rebase and push properly without --force (I
> still don't know how to do the latter FWIW). And don't get me started on
> amendments after creating the PR...
People appear to forget how unintuitive the PR approach actually is, and
prefer it mostly because they are used to the notion of doing what you
describe here. But I (unsurprisingly) agree, I submitted a few patches
to Agda-mode earlier this year[0], but because they depend on one
another, the web UI is confused and displays all the commits. Perhaps
just anecdotal, but at least an example of how these kinds of interfaces
restrict the Git workflow.
[0] https://github.com/agda/agda/pull/6123#issuecomment-1472151296
[1] https://github.com/agda/agda/pull/6540/commits
>> There should also be SourceHut on this scale, but I don't know where
>> to put it.
>
> Cannot comment on how everyone else uses Sourcehut but my experience was
> slightly better than Debbugs because I got instant feedback from the
> mailing list archive and Philip accepts patches as attachments. ;-)
> Generally, I don't find their web UI all that useful since they drop the
> entire message after the attachment. I am not sure if there are plans
> to fix it since Sourcehut people prefer `git send-email' AFAIK.
FWIW I spoke with the Sourcehut developers at FOSDEM this year and IIRC
they told me that while they aren't interested in upstreaming the
features that would be nice to have for Emacs development, they would be
happy to help with any issues if a fork were to be maintained.
^ permalink raw reply [relevance 86%]
* 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: New Package for NonGNU-ELPA: clojure-ts-mode
@ 2023-08-31 18:17 71% ` Philip Kaludercic
0 siblings, 2 replies; 200+ results
From: Philip Kaludercic @ 2023-08-31 18:17 UTC (permalink / raw)
To: Ihor Radchenko
Cc: Po Lu, Dmitry Gutov, Stefan Kangas, Danny Freeman, Eli Zaretskii,
emacs-devel, manuel.uberti
Ihor Radchenko <yantar92@posteo.net> writes:
> Po Lu <luangruo@yahoo.com> writes:
>
>>> That way, some users may be able to create new threads at least, which
>>> is apparently more comfortable for some users.
>>
>> Do we really want to trouble Emacs development with yet another burden
>> to mind? Two kinds of threads, in one of which certain subjects or
>> measures are off-limits, really?
>
> What about using mailing list first then?
> For mailing list users, there will be no difference.
> For Disccourse, some topics might remain merged even when mailing list
> thread branched off several discussion threads.
At this point I don't know what the problem is that you are trying to
solve. If we want to invite more people to participate in discussions
on emacs-devel, but treat those who use Disccourse as lesser citizens.
There comes a point where people have to accept that mailing lists
aren't weird and unusable -- this is not a primarily technical problem.
Some people are afraid of communicating with the mailing list or
reporting bugs because of an image issue. I have on more than one
occasion heard of people who intentionally avoid communicating with
emacs-devel due to bad experience. Others fear sending a message out
into the blue and not knowing who will read and respond to what they
said, will they be shouted down or just ignored. In principle these
issues are shared in common with all other Fora (Discourse, Reddit,
etc.), with perhaps the difference that you can delete and edit a post
after posting it.
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. Just in the past few days, I have seen people ask on the
#emacs@libera.chat IRC channel what they think would happen if they were
to submit a patch, and if it would be accepted. This demonstrates an
uncertainty, that apparently cannot be resolved by actually sending a
patch and seeing what happens. 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?
^ permalink raw reply [relevance 71%]
* Re: [NonGNU ELPA] New package: flymake-guile
@ 2023-08-31 18:02 93% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-08-31 18:02 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:
>>
>>> 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.
>>> ;;; Commentary:
>>>
>>> ;; Flymake backend for GNU Guile using `guild' compile.
>>> ;;
>>> ;; Usage:
>>> ;; (require 'flymake-guile)
>>> ;; (add-hook 'scheme-mode-hook 'flymake-guile)
>>
>> It would probably make sense to autoload the `flymake-guile' function,
>> so that it is not necessary to require it in a user configuration.
>>
> It already have autoload, I just update the commentary there.
1+
>>
>> Are you sure the README.md is right thing to include here? It includes
>> installation instructions, that are usually redundant when you install
>> the package using package.el. I would recommend writing out the
>> "Commentary" section in flymake-guile.el with a brief description of
>> what package and its entry points.
>>
>> Also, the package appears to include files that needn't be distributed
>> in the release tarball, such as .envrc and guix.scm. It would be nice
>> if you could track these and future files of this type in a .elpaignore
>> file, to instruct the build server that they should be removed before
>> packaging.
>>
> Updated in the last version ignoring those file and removing the README
> declaration.
>
> Thank you!
Distopico <distopico@riseup.net> writes:
> v1 -> v2: Remove unnecesary README and ignore files.
>
>
> From 1f683e46e59f5ebff923b493aa911e489ecd7bb0 Mon Sep 17 00:00:00 2001
> From: Distopico <distopico@riseup.net>
> Date: Wed, 30 Aug 2023 20:53:27 -0500
> Subject: [PATCH v2 2/2] * elpa-packages (flymake-guile): New package
>
> ---
> elpa-packages | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/elpa-packages b/elpa-packages
> index 93e7c38600..e80486aec6 100644
> --- a/elpa-packages
> +++ b/elpa-packages
> @@ -223,6 +223,9 @@
> (flymake-quickdef :url "https://github.com/karlotness/flymake-quickdef.git"
> :readme "README.md")
>
> + (flymake-guile :url "https://framagit.org/flymake-backends/flymake-guile.git"
> + :ignored-files (".envrc" "guix.scm"))
It would be preferable to track this information in your own repository,
instead of having to update the info in the future in elpa-packages.
Also, it is totally fine to add both packages in a single patch.
^ permalink raw reply [relevance 93%]
* 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: 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: [NonGNU ELPA] New package: flymake-guile
@ 2023-08-31 6:52 80% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-08-31 6:52 UTC (permalink / raw)
To: Distopico; +Cc: emacs-devel
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.
> ;;; Commentary:
>
> ;; Flymake backend for GNU Guile using `guild' compile.
> ;;
> ;; Usage:
> ;; (require 'flymake-guile)
> ;; (add-hook 'scheme-mode-hook 'flymake-guile)
It would probably make sense to autoload the `flymake-guile' function,
so that it is not necessary to require it in a user configuration.
> Best!
>
> From c6a3d53bb56d3e0d8638fe069a49fc4d364e0e84 Mon Sep 17 00:00:00 2001
> From: Distopico <distopico@riseup.net>
> Date: Wed, 30 Aug 2023 20:41:28 -0500
> Subject: [PATCH 1/2] * elpa-packages (flymake-quickdef): New package
>
> ---
> elpa-packages | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/elpa-packages b/elpa-packages
> index 0d9da00c84..93e7c38600 100644
> --- a/elpa-packages
> +++ b/elpa-packages
> @@ -220,6 +220,9 @@
> :ignored-files (".travis.yml" "Cask" "LICENSE" "tests" "Makefile"
> "flx.el" "misc/flx-helm-demo.el" "misc/flx-test-list.el"))
>
> + (flymake-quickdef :url "https://github.com/karlotness/flymake-quickdef.git"
> + :readme "README.md")
> +
> (flymake-kondor :url "https://github.com/turbo-cafe/flymake-kondor"
> :ignored-files ("COPYING.txt"))
>
> --
> 2.41.0
>
>
> From 50674f93285692a4e7ca1c9b22d13bbffa89eabe Mon Sep 17 00:00:00 2001
> From: Distopico <distopico@riseup.net>
> Date: Wed, 30 Aug 2023 20:53:27 -0500
> Subject: [PATCH 2/2] * elpa-packages (flymake-guile): New package
>
> ---
> elpa-packages | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/elpa-packages b/elpa-packages
> index 93e7c38600..b07894fe1a 100644
> --- a/elpa-packages
> +++ b/elpa-packages
> @@ -223,6 +223,9 @@
> (flymake-quickdef :url "https://github.com/karlotness/flymake-quickdef.git"
> :readme "README.md")
>
> + (flymake-guile :url "https://framagit.org/flymake-backends/flymake-guile.git"
> + :readme "README.md")
Are you sure the README.md is right thing to include here? It includes
installation instructions, that are usually redundant when you install
the package using package.el. I would recommend writing out the
"Commentary" section in flymake-guile.el with a brief description of
what package and its entry points.
Also, the package appears to include files that needn't be distributed
in the release tarball, such as .envrc and guix.scm. It would be nice
if you could track these and future files of this type in a .elpaignore
file, to instruct the build server that they should be removed before
packaging.
> > +
> (flymake-kondor :url "https://github.com/turbo-cafe/flymake-kondor"
> :ignored-files ("COPYING.txt"))
^ permalink raw reply [relevance 80%]
* 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 5:43 98% ` Philip Kaludercic
1 sibling, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-08-31 5:43 UTC (permalink / raw)
To: João Távora
Cc: Richard Stallman, Danny Freeman, Eli Zaretskii, emacs-devel,
Manuel Uberti
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.
Not so much that that is the intention, but just that the Clojure-mode
developers might not like using the same name, when for this example a
different name would have the same use. There are a few here in the
thread, perhaps they can comment on it.
^ permalink raw reply [relevance 98%]
* 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: 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%]
* package-autosuggest
@ 2023-08-30 19:26 53% ` Philip Kaludercic
0 siblings, 2 replies; 200+ results
From: Philip Kaludercic @ 2023-08-30 19:26 UTC (permalink / raw)
To: Eli Zaretskii
Cc: monnier, stefankangas, yandros, bozhidar, dmitry, rms, danny,
emacs-devel
[-- Attachment #1: Type: text/plain, Size: 870 bytes --]
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: monnier@iro.umontreal.ca, stefankangas@gmail.com, yandros@gmail.com,
>> bozhidar@batsov.dev, dmitry@gutov.dev, rms@gnu.org,
>> danny@dfreeman.email, emacs-devel@gnu.org, manuel.uberti@inventati.org
>> Date: Wed, 30 Aug 2023 12:25:20 +0000
>>
>> Are there any other examples, where we would want to have minor modes
>> for specific file types? These sorts of entries would probably have to
>> be added manually.
>
> I don't know, maybe someone else has an idea.
>
>> I am glad to see that there is interest in this proposal. I can try and
>> create an example of how this could work, and push it to a feature
>> branch for further review, some time soon.
>
> I think this could be useful, yes.
Here is a quick and rough draft of how this feature could look like:
[-- Attachment #2: Type: text/plain, Size: 4933 bytes --]
diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el
index e1172d69bf0..723900318c5 100644
--- a/lisp/emacs-lisp/package.el
+++ b/lisp/emacs-lisp/package.el
@@ -4534,6 +4534,116 @@ package-get-version
(or (lm-header "package-version")
(lm-header "version")))))))))
+\f
+;;;; Autosuggest
+
+(defvar package-autosuggest-database
+ '((sml-mode auto-mode-alist "\\.sml\\'")
+ (lua-mode auto-mode-alist "\\.lua\\'" )
+ (ada-mode auto-mode-alist "\\.ada\\'")
+ ;; ...
+ ;;
+ ;; this is just for testing, in practice I think this data should
+ ;; be generated and bundled with Emacs, and would ideally be
+ ;; loaded in at compile-time. When the "archive-contents" file
+ ;; format is updated, we can include more information in there
+ ;; that would be added to this database.
+ )
+ "Database of hints for packages to suggest installing.")
+
+(define-minor-mode package-autosuggest-mode
+ "Enable the automatic suggestion and installation of packages."
+ :init-value 'message :global t
+ (funcall (if package-autosuggest-mode #'add-hook #'remove-hook)
+ 'after-change-major-mode-hook
+ #'package--autosuggest-after-change-mode))
+
+(defun package--suggestion-applies-p (pkg-sug)
+ "Check if a suggestion PKG-SUG is applicable to the current buffer."
+ (pcase pkg-sug
+ (`(,(pred package-installed-p) . _) nil)
+ ((or `(,_ auto-mode-alist ,ext _)
+ `(,_ auto-mode-alist ,ext))
+ (and (string-match-p ext (buffer-name)) t))
+ ((or `(,_ magic-mode-alist ,mag _)
+ `(,_ magic-mode-alist ,mag))
+ (save-restriction
+ (widen)
+ (save-excursion
+ (goto-char (point-min))
+ (looking-at-p mag))))
+ ((or `(,_ interpreter-mode-alist ,magic _)
+ `(,_ interpreter-mode-alist ,magic))
+ (save-restriction
+ (widen)
+ (save-excursion
+ (goto-char (point-min))
+ (and (looking-at auto-mode-interpreter-regexp)
+ (string-match-p
+ (concat "\\`" (file-name-nondirectory (match-string 2)) "\\'")
+ magic)))))))
+
+(defun package--autosuggest-find-candidates ()
+ "Return a list of packages that might be interesting the current buffer."
+ (and package-autosuggest-mode
+ (let (suggetions)
+ (dolist (sug package-autosuggest-database)
+ (when (package--suggestion-applies-p sug)
+ (push sug suggetions)))
+ suggetions)))
+
+(defun package--autosuggest-install-and-enable (pkg-sug)
+ "Install and enable a package suggestion PKG-ENT.
+PKG-SUG has the same form as an element of
+`package-autosuggest-database'."
+ (package-install (car pkg-sug))
+ (with-demoted-errors "Failed to enable: %S"
+ (dolist (buf (buffer-list))
+ (with-current-buffer buf
+ (when (and (eq major-mode 'fundamental-mode) (buffer-file-name)
+ (package--suggestion-applies-p pkg-sug))
+ (funcall-interactively (or (cadddr pkg-sug) (car pkg-sug))))))))
+
+(defvar package--autosuggest-suggested '()
+ "List of packages that have already been suggested.")
+
+(defun package--autosuggest-after-change-mode ()
+ "Hook function to suggest packages for installation."
+ (when-let ((avail (seq-difference (package--autosuggest-find-candidates)
+ package--autosuggest-suggested))
+ (pkgs (mapconcat #'symbol-name
+ (delete-dups (mapcar #'car avail))
+ ", ")))
+ (pcase package-autosuggest-mode
+ ('always
+ (when (yes-or-no-p (format "Install suggested packages (%s)?" pkg))
+ (mapc #'package--autosuggest-install-and-enable avail)))
+ ('once
+ (when (yes-or-no-p (format "Install suggested packages (%s)?" pkg))
+ (mapc #'package--autosuggest-install-and-enable avail))
+ (setq package--autosuggest-suggested (append avail package--autosuggest-suggested)))
+ ('message
+ (message
+ (substitute-command-keys
+ (format "Found suggested packages: %s. Install using \\[package-autosuggest]"
+ pkgs)))))))
+
+(defun package-autosuggest ()
+ "Prompt the user for suggested packages."
+ (interactive)
+ (let* ((avail (or (package--autosuggest-find-candidates)
+ (user-error "No suggestions found")))
+ (pkgs (completing-read-multiple
+ "Install suggested packages: " avail
+ nil t
+ (mapconcat #'symbol-name
+ (delete-dups (mapcar #'car avail))
+ ",")))
+ (choice (concat "\\`" (regexp-opt pkgs) "\\'")))
+ (dolist (ent avail)
+ (when (string-match-p choice (symbol-name (car ent)))
+ (package--autosuggest-install-and-enable ent)))))
+
\f
;;;; Quickstart: precompute activation actions for faster start up.
[-- Attachment #3: Type: text/plain, Size: 250 bytes --]
The documentation is obviously lacking and incomplete, I just wanted to
have a POC to discuss the idea.
I am not sure if the default option 'message is still too aggressive, as
opinions differ on how and who should print messages in the echo area.
^ permalink raw reply related [relevance 53%]
* Re: Clojure mode
@ 2023-08-30 12:25 90% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-08-30 12:25 UTC (permalink / raw)
To: Eli Zaretskii
Cc: monnier, stefankangas, yandros, bozhidar, dmitry, rms, danny,
emacs-devel, manuel.uberti
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: monnier@iro.umontreal.ca, stefankangas@gmail.com, yandros@gmail.com,
>> bozhidar@batsov.dev, dmitry@gutov.dev, rms@gnu.org,
>> danny@dfreeman.email, emacs-devel@gnu.org, manuel.uberti@inventati.org
>> Date: Wed, 30 Aug 2023 11:51:37 +0000
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> >> To make a concrete suggestion: The database would probably consist of
>> >> possible extensions to `auto-mode-alist', `magic-mode-alist' and
>> >> `interpreter-mode-alist'.
>> >
>> > That'd be the anchor, definitely, at least for major modes. It could
>> > be a single function that is called if no suitable entry is found in
>> > any of these variables.
>>
>> What could be a single function?
>
> That function would look up some database and suggest a package if it
> exists.
Ah, yes that is true.
Are there any other examples, where we would want to have minor modes
for specific file types? These sorts of entries would probably have to
be added manually.
I am glad to see that there is interest in this proposal. I can try and
create an example of how this could work, and push it to a feature
branch for further review, some time soon. As mentioned elsewhere, this
might or might not be related to updating the "archive-contents" format
and adding package.el to GNU ELPA, as mentioned in [0]
[0] https://mail.gnu.org/archive/html/emacs-devel/2023-08/msg00667.html
--
Philip Kaludercic
^ permalink raw reply [relevance 90%]
* Re: Clojure mode
@ 2023-08-30 11:51 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-08-30 11:51 UTC (permalink / raw)
To: Eli Zaretskii
Cc: monnier, stefankangas, yandros, bozhidar, dmitry, rms, danny,
emacs-devel, manuel.uberti
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, stefankangas@gmail.com,
>> yandros@gmail.com, bozhidar@batsov.dev, dmitry@gutov.dev, rms@gnu.org,
>> danny@dfreeman.email, emacs-devel@gnu.org, manuel.uberti@inventati.org
>> Date: Tue, 29 Aug 2023 20:13:43 +0000
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> > I think if we want to offer such a feature, we need first to come up
>> > with some friendly enough UI: when exactly to pop the suggestion, how
>> > to allow users to decline, how to install and configure if they say
>> > yes, etc. Then there would be a need for some kind of DB with popular
>> > features that are not built-in and that people may wish to want; the
>> > challenge here is not to make the DB list too many features, otherwise
>> > we will be popping suggestions every single second...
>>
>> How about splitting this into two separate tasks? E.g. when a more
>> specific mode is found, a message is displayed in the minibuffer. This
>> can occur once a session or once for every file. The message would
>> instruct the user to invoke the appropriate command (e.g. a custom
>> command or by using the future history for `package-install').
>
> Something like that, yes. But maybe there are other ideas?
Another idea might be to indicate that a package can be installed in the
mode-line. If the user interacts with it, some the right package would
be installed, activated and enabled in the applicable buffers.
>> To make a concrete suggestion: The database would probably consist of
>> possible extensions to `auto-mode-alist', `magic-mode-alist' and
>> `interpreter-mode-alist'.
>
> That'd be the anchor, definitely, at least for major modes. It could
> be a single function that is called if no suitable entry is found in
> any of these variables.
What could be a single function?
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Brand new clojure support in Emacs ;-)
@ 2023-08-30 10:15 88% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-08-30 10:15 UTC (permalink / raw)
To: João Távora
Cc: Richard Stallman, Danny Freeman, Eli Zaretskii, emacs-devel,
Manuel Uberti
João Távora <joaotavora@gmail.com> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> I suggested something along these lines up the thread, but didn't try it
>> out myself.
>
> Yes, I read your suggestion, that's why I quoted you ;-)
Oh, did you know I can't read ^^
>> Nice to see that the idea works. To avoid confusion, I
>> think it might be a good idea to not call this `clojure-mode' as well,
>> but something like "clojure-proto-mode" or "primitive-clojure-mode".
>
> 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. For example,
if a user has a (fboundp 'clojure-mode) check in their configuration
somewhere, their script might falsely assume that the entire package has
been installed. I know, their check was not particularly robust, but
personal configurations are often lenient on these issues.
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).
>>> No idea if this works with the CIDER or SLIME backends for clojure.
>>> Don't ask me to test any more cause I've just uninstalled it all
>>> but any clojurians rading can have a go.
>>
>> I would guess that anyone who is seriously interested in working with
>> Clojure, would install the proper major mode and the proper packages.
>
> I don't know: for some people and/or some tasks, a 3000 LOC major mode
> may feel quite bloated, at least when compared one which is -- quite
> literally -- a thousand times smaller.
>
> So, not being a Clojure programmer, I wouldn't "guess" what such
> programmer would do. I would just compare one by one what features are
> provided by the two modes -- when complemented by LSP of course.
>
> Also, I would try to establish if the CIDER environment can be invoked
> from this new major mode, or if it is strongly coupled to the NonGNU
> Clojure mode. If it works anything like SLIME or SLY, it should be some
> kind of minor mode which manages a network connection, and thus
> theoretically composable.
I suppose so too, but can also just guess, since I don't use the
language.
> João
--
Philip Kaludercic
^ permalink raw reply [relevance 88%]
* Re: Clojure mode
@ 2023-08-30 7:26 95% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-08-30 7:26 UTC (permalink / raw)
To: Stefan Kangas
Cc: Eli Zaretskii, Stefan Monnier, yandros, bozhidar, dmitry, rms,
danny, emacs-devel, manuel.uberti
Stefan Kangas <stefankangas@gmail.com> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> > FWIW, my ideal scenario looks like this:
>> >
>> > "You seem to have opened a Clojure file. Would you like to install
>> > clojure-mode (yes/no/help)?"
>> >
>> > When the user types "yes RET", the package gets installed, loaded in
>> > the running session, and enabled in the relevant buffer.
>>
>> This seems invasive, especially if the database has false-positives for
>> a user.
>
> With false positives it would suck, of course. On the other hand,
> perhaps adding a "don't ask me again" would make it more tolerable.
>
>> If anything, I think this kind of behaviour sound be opt-in.
>
> One idea would be to make the less-invasive "message in minibuffer"
> variant the default, and the more-invasive "in your face prompt"
> variant opt-in.
So we are thinking about a user-option like `package-autosuggest' that
would have the values
- always :: always prompt the user when a more specific package is
available
- once (or t) :: ask the user once per session, when a more specific
package is available
- message :: only print a message if a more specific package is
available
- nil :: do not look for more specific packages at all
^ permalink raw reply [relevance 95%]
* Re: Brand new clojure support in Emacs ;-)
@ 2023-08-30 7:17 94% ` Philip Kaludercic
0 siblings, 2 replies; 200+ results
From: Philip Kaludercic @ 2023-08-30 7:17 UTC (permalink / raw)
To: João Távora
Cc: Richard Stallman, Danny Freeman, Eli Zaretskii, emacs-devel,
Manuel Uberti
João Távora <joaotavora@gmail.com> writes:
> On Fri, Aug 25, 2023 at 8:26 AM Philip Kaludercic <philipk@posteo.net> wrote:
>>
>> 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 appears that there is no clojure-mode command in core Emacs.
>> > There is a Clojure mode package, but it is in NonGNU ELPA.
>> >
>> > I think that language is important enough that, notwithstanding not
>> > really being similar to Lisp, we ought to have a major mode to support it.
>> > Would someone please work on that?
>>
>> I had brought this up in the recent clojure-ts-mode thread, that I
>> assume you are referring to. Sadly, I have no experience with the
>> language, but one idea might be to extend lisp-data-mode by whatever the
>
> I don't know if this counts as "work on that" but here's two interesting lines
> Elisp:
>
> (define-derived-mode clojure-mode lisp-data-mode "Clojure"
> "Barebones Clojure")
> (add-to-list 'auto-mode-alist '("\\.clj" . clojure-mode))
I suggested something along these lines up the thread, but didn't try it
out myself. Nice to see that the idea works. To avoid confusion, I
think it might be a good idea to not call this `clojure-mode' as well,
but something like "clojure-proto-mode" or "primitive-clojure-mode".
> Since it is a lisp dialect many things works here, like indentation,
> symbol recognition, parenthesis balancing, C-M navigation, and thing-at-point.
>
> And then there's LSP, right?
>
> So I installed clojure-lsp from here:
> https://aur.archlinux.org/packages/clojure-lsp-bin
>
> I created a hello world project with the "lein" tool, git init, found the
> src/helloworld/core.clj inside it, pressed M-x eglot and suddenly I had
> at-point-documentation, diagnostics, lots of refactorings, completion, etc.
>
> The thing that's a bit minimal is the syntax highlighting, but it's
> not that bad either IMHO. Eglot doesn't yet support LSP-mandated syntax
> highlighting. I have no idea what it takes to add TreeSitter support
> to such a bare-bones mode (but shouldn't it be really easy like mapping
> syntactic symbols to faces?)
>
> No idea if this works with the CIDER or SLIME backends for clojure.
> Don't ask me to test any more cause I've just uninstalled it all
> but any clojurians rading can have a go.
I would guess that anyone who is seriously interested in working with
Clojure, would install the proper major mode and the proper packages.
> João
^ permalink raw reply [relevance 94%]
* Re: Clojure mode
@ 2023-08-29 20:31 97% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-08-29 20:31 UTC (permalink / raw)
To: Stefan Kangas
Cc: Eli Zaretskii, Stefan Monnier, yandros, bozhidar, dmitry, rms,
danny, emacs-devel, manuel.uberti
Stefan Kangas <stefankangas@gmail.com> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> How about splitting this into two separate tasks? E.g. when a more
>> specific mode is found, a message is displayed in the minibuffer.
>
> FWIW, my ideal scenario looks like this:
>
> "You seem to have opened a Clojure file. Would you like to install
> clojure-mode (yes/no/help)?"
>
> When the user types "yes RET", the package gets installed, loaded in
> the running session, and enabled in the relevant buffer.
This seems invasive, especially if the database has false-positives for
a user. If anything, I think this kind of behaviour sound be opt-in.
But you are right, package-install is not sufficient, enabling the right
mode for all the relevant buffer(s) seems like the right thing to do.
^ permalink raw reply [relevance 97%]
* Re: Clojure mode
@ 2023-08-29 20:13 93% ` Philip Kaludercic
0 siblings, 2 replies; 200+ results
From: Philip Kaludercic @ 2023-08-29 20:13 UTC (permalink / raw)
To: Eli Zaretskii
Cc: Stefan Monnier, stefankangas, yandros, bozhidar, dmitry, rms,
danny, emacs-devel, manuel.uberti
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Cc: chad <yandros@gmail.com>, Eli Zaretskii <eliz@gnu.org>,
>> bozhidar@batsov.dev, dmitry@gutov.dev, rms@gnu.org,
>> danny@dfreeman.email, emacs-devel@gnu.org, manuel.uberti@inventati.org
>> Date: Mon, 28 Aug 2023 23:21:50 -0400
>>
>> Maybe we should go for a different implementation strategy.
>
> I think if we want to offer such a feature, we need first to come up
> with some friendly enough UI: when exactly to pop the suggestion, how
> to allow users to decline, how to install and configure if they say
> yes, etc. Then there would be a need for some kind of DB with popular
> features that are not built-in and that people may wish to want; the
> challenge here is not to make the DB list too many features, otherwise
> we will be popping suggestions every single second...
How about splitting this into two separate tasks? E.g. when a more
specific mode is found, a message is displayed in the minibuffer. This
can occur once a session or once for every file. The message would
instruct the user to invoke the appropriate command (e.g. a custom
command or by using the future history for `package-install').
To make a concrete suggestion: The database would probably consist of
possible extensions to `auto-mode-alist', `magic-mode-alist' and
`interpreter-mode-alist'.
^ permalink raw reply [relevance 93%]
* 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: Choice of bug tracker
@ 2023-08-29 11:58 99% ` Philip Kaludercic
1 sibling, 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: [NonGNU ELPA] New package: hyperdrive (repast)
@ 2023-08-29 11:56 99% ` Philip Kaludercic
2023-09-03 8:18 45% ` Philip Kaludercic
0 siblings, 1 reply; 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: New Package for NonGNU-ELPA: clojure-ts-mode
@ 2023-08-29 11:33 88% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-08-29 11:33 UTC (permalink / raw)
To: Bozhidar Batsov
Cc: Eli Zaretskii, Lynn Winebarger, Dmitry Gutov, Po Lu,
Danny Freeman, Stefan Kangas, Emacs Devel, Manuel Uberti
"Bozhidar Batsov" <bozhidar@batsov.dev> writes:
>> That's formally true, but doing this over the objections of the
>> original authors would be IMO rude, and I would not agree to that
>> lightly.
>
> I agree that'd be rude. I also think that'd be quite confusing for the
> end users and will make some of the operations (e.g. submission of
> bugs) a total mess. Neither the Clojure, nor the Emacs communities are
> big enough to engage lightly in time-wasting activities.
>
> And, I'll say it once more - in case this was missed in the
> conversations. Personal misgivings about the mechanics of Emacs's
> development aside, I think it's not prudent to keep growing its core,
> which is already huge. Obviously it's up to the Emacs developers to
> decide what to do, but I'd be moving more things into packages and
> bundling less things with Emacs. You might have seen this trend in
> some programming languages - e.g. Ruby has slimmed down its core a lot
> and this helped channel the efforts of the core team.
>
> I think by now pretty much every user of an editor or a programming
> language is used to installing packages to augment the core
> functionality, so I'm not buying the argument that we need to have
> more things OOTB. IMO the core of Emacs should consist of fewer, but
> truly essential packages.
>
> Someone mentioned it'd be nice if Emacs suggested packages to install
> for certain (unsupported OOTB) file types and I think that'd be a nice
> way to help with package discovery. Perhaps packages can just mention
> this in their metadata?
Most of the time this would be duplicating information, since most
packages already have a
;;;###autoload
(add-to-list 'auto-mode-alist '("\\.foo\\'" . foo-mode))
in their body somewhere, that can be scraped. I proposed doing this in
the context of updating the archive-contents file format to address a
few issues that people have been raising for a couple of years now.
Of course this doesn't work when users work in environments without any
internet access or their access to {GNU,NonGNU} ELPA is restricted by a
firewall. I don't know if it is points like these that motivate adding
functionality directly to the core?
^ permalink raw reply [relevance 88%]
* Re: New Package for NonGNU-ELPA: clojure-ts-mode
@ 2023-08-27 19:05 80% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-08-27 19:05 UTC (permalink / raw)
To: Bozhidar Batsov
Cc: Stefan Kangas, Eli Zaretskii, Dmitry Gutov, luangruo, danny,
Emacs Devel, Manuel Uberti
"Bozhidar Batsov" <bozhidar@batsov.dev> writes:
> Fair enough. Although experience shows that some packages with
> assigned copyright are barely maintained (even in Emacs's core), so
> obviously that's no silver bullet.
How did you come to this perspective? For both core packages and ELPA
packages there is a lot of activity. Of course there are stable and
complete packages, where there are only an infrequent need for bug
fixes, but that is a different issue.
> My perspective is simple - don't mess with something that's working
> well.
Is this still related to the point of suggesting adding packages to
GNU ELPA or the core? I am a bit disappointed to hear that being seen
as "messing with a workflow", that certainly isn't the intention, just
an offer that would ideally benefit everyone.
> (e.g. you're getting many occasional contributors on GitHub and
> you want to keep it simple for them)
It is hard to judge, but it seems that there might be some truth to
this. But this is an unfortunate circumstance, that should be changed,
if you ask me. At the same time, one should keep in mind that
contributing via GitHub requires an account and a number of
complications, while mailing-lists (either here or via SourceHut) are
open to anyone with an email address -- something I consider to be a
major advantage.
My hope is that this is not an inherent issue of GitHub vs. something
else, and that commands like package-vc-prepare-patch could help make
contributing upstream changes easier for everyone.
> On Sun, Aug 27, 2023, at 9:32 PM, Stefan Kangas wrote:
>> Bozhidar Batsov <bozhidar@batsov.dev writes>:
>>
>> > I have to say I'm a bit frustrated that every time someone wants
>> > to submit something to NonGNU ELPA there's some push to either
>> > submit to GNU ELPA or core instead.
>>
>> Some of us believe that assigned packages are often better for the
>> overall health of the project, so we continue to argue for it. It
>> would be irresponsible not to.
^ permalink raw reply [relevance 80%]
* Re: New Package for NonGNU-ELPA: clojure-ts-mode
@ 2023-08-27 14:13 91% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-08-27 14:13 UTC (permalink / raw)
To: Eli Zaretskii
Cc: dmitry, luangruo, danny, stefankangas, emacs-devel, manuel.uberti
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: Po Lu <luangruo@yahoo.com>, Eli Zaretskii <eliz@gnu.org>,
>> danny@dfreeman.email, stefankangas@gmail.com, emacs-devel@gnu.org,
>> manuel.uberti@inventati.org
>> Date: Sun, 27 Aug 2023 13:25:49 +0000
>>
>> BTW. what is the current system by which releases are cut? I don't know
>> if the maintainers have a schedule or some general plan for internal
>> usage.
>
> I don't know how to answer this.
How did you decide when to draw the line between Emacs 29 and Emacs 30?
>> What might be nice would be if the release-dates could take the
>> release-dates of popular distributions such as Debian into account,
>
> Why Debian?
Because it is a fairly popular distribution on which a lot of other
distributions are based. Also you'll frequently find it "in the wild",
and is a prominent "stable" distribution (CentOS or whatever the current
fork is) would be an alternative example.
> And why should we take them into account, and not the
> other way around? I have never seen a Debian (or any other distro)
> approach us asking when the next release is expected.
That is true, but I don't see any reason why there shouldn't be any
cooperation. All the necessary information should be available here
https://tracker.debian.org/pkg/emacs. One of the most active people
behind the package appears to be Sean Whitton, who does frequent the
mailing list.
^ permalink raw reply [relevance 91%]
* Re: New Package for NonGNU-ELPA: clojure-ts-mode
@ 2023-08-27 13:25 89% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-08-27 13:25 UTC (permalink / raw)
To: Dmitry Gutov
Cc: Po Lu, Eli Zaretskii, danny, stefankangas, emacs-devel,
manuel.uberti
Dmitry Gutov <dmitry@gutov.dev> writes:
> On 27/08/2023 15:57, Po Lu wrote:
>> Dmitry Gutov<dmitry@gutov.dev> writes:
>>
>>> We could easily have more frequent releases, it's all in the hands of
>>> the maintainers, actually. Stability/velocity tradeoffs.
>> Producing another atrocity following the footsteps of Mozilla? No
>> thanks!
>
> Releasing a new Emacs, say, even 6 month won't suddenly turn it into a
> crashing mess. But we would get more and faster feedback for new
> features and changes.
BTW. what is the current system by which releases are cut? I don't know
if the maintainers have a schedule or some general plan for internal
usage. If not, it really wouldn't make much of a difference if releases
are made every six months or two years.
What might be nice would be if the release-dates could take the
release-dates of popular distributions such as Debian into account,
avoiding as was now the case, that Emacs 28.2 gets added to stable. Of
course, this is not an easy thing to do, but I guess if the release
procedure would be more transparent, akin to [0], it might help.
[0] https://release.debian.org/bookworm/freeze_policy.html
> That's the main issue why we have to drag on the release schedule: we
> don't get reports of regressions soon enough after introducing
> them. So we have to wait months for the users to try and report back.
>
> How to change that? Either make releases more often, or make snapshot
> releases more prominent and easier to try, or improve the bug
> reporting experience so that more people do that. Or all of that
> together, of course.
>
> In this thread specifically I'm talking about number 3.
>
>>> Oh sure, we never have bugs or regressions in Emacs.
>> As a rule of thumb, we don't release Emacs with readily encountered bugs
>> that subject the user to irrecoverable hangs.
>
> I wonder what wonderful curious bug reports we would also get if we
> had the number of users that Firefox has.
^ permalink raw reply [relevance 89%]
* Re: New Package for NonGNU-ELPA: clojure-ts-mode
@ 2023-08-27 13:16 98% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-08-27 13:16 UTC (permalink / raw)
To: João Távora
Cc: Eli Zaretskii, Dmitry Gutov, Danny Freeman, Stefan Kangas,
emacs-devel, Manuel Uberti
João Távora <joaotavora@gmail.com> writes:
> On Sat, Aug 26, 2023, 21:15 Philip Kaludercic <philipk@posteo.net> wrote:
>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> >> Date: Sat, 26 Aug 2023 21:52:31 +0300
>> >> Cc: stefankangas@gmail.com, philipk@posteo.net, emacs-devel@gnu.org,
>> >> manuel.uberti@inventati.org
>> >> From: Dmitry Gutov <dmitry@gutov.dev>
>> >>
>> >> On 25/08/2023 08:42, Eli Zaretskii wrote:
>> >> > IME, the development model of Emacs is an important reason why Emacs
>> >> > is still alive and kicking almost 40 years since it was first
>> >> > developed. And important major modes in Emacs are alive and kicking
>> >> > with it. So inclusion in Emacs and the pains of adjusting to a
>> >> > different development model are justified if one wants the major mode
>> >> > to remain alive for many years to come. Something to think about, I
>> >> > guess.
>> >>
>> >> Or the longevity stems from other reasons (e.g. good fundamental ideas,
>> >> unique proposition, being part of the original GNU system, ...), and
>> the
>> >> development process is the reason the current user base is a fraction
>> of
>> >> even Vim's (not to mention popular commercial offerings).
>> >>
>> >> Just an alternative POV to consider. In truth, could be a little of
>> both.
>> >
>> > Mine wasn't a POV, it was an observation based on many years of
>> > watching the development and being part of it.
>>
>> Correct me if I am wrong: This seems to be related to the fact that the
>> GitHub-model (thought it probably precedes it) of development has
>> motivated more and more individuals to maintain packages, instead of
>> organisations like GNU, Apache, etc. Or at least I understand that if
>> there is a collective effort behind maintaining the components of a
>> system, contributors can come and go without a package being abandoned
>> -- this is especially true for Emacs due to the extensive
>> introspectability. But it appears this reaches a limit, if a component
>> is too complex (CEDET was mentioned as one example, and if João were to
>> suddenly loose interest in contributing to Emacs, something similar
>> might happen to Eglot as well).
>
[...]
> I'm a bit perplexed why you picked me as the star of "what if
> he were to disappear?" but I guess I'm as good a candidate as
> Michael, Lars, Dmitry or so many others.
Mainly because I am under the impression that of all the contributors to
Eglot, you have the best understanding of LSP as a protocol. But you
are right, it was mostly the first example that came to mind when
comparing it to CEDET.
^ permalink raw reply [relevance 98%]
* 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: 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: hyperdrive (repast)
@ 2023-08-26 20:27 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-08-26 20:27 UTC (permalink / raw)
To: Joseph Turner
Cc: Emacs Devel Mailing List, Adam Porter, Paula Maas,
Protesilaos Stavrou
Joseph Turner <joseph@ushin.org> writes:
> On August 26, 2023 4:55:56 AM PDT, Philip Kaludercic <philipk@posteo.net> wrote:
>>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?
>
> In the future I will do that. I didn't receive a response after a couple weeks, so I guessed that maybe the thread had slipped through the cracks.
That was certainly the case for me.
> Shall I continue discussion on the original thread or here?
Either is fine. My main difficulty is understanding what Hyperdrive
is... 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.
> Thanks,
>
> Joseph
^ permalink raw reply [relevance 99%]
* Re: New Package for NonGNU-ELPA: clojure-ts-mode
@ 2023-08-26 20:14 76% ` Philip Kaludercic
0 siblings, 2 replies; 200+ results
From: Philip Kaludercic @ 2023-08-26 20:14 UTC (permalink / raw)
To: Eli Zaretskii
Cc: Dmitry Gutov, danny, stefankangas, emacs-devel, manuel.uberti
Eli Zaretskii <eliz@gnu.org> writes:
>> Date: Sat, 26 Aug 2023 21:52:31 +0300
>> Cc: stefankangas@gmail.com, philipk@posteo.net, emacs-devel@gnu.org,
>> manuel.uberti@inventati.org
>> From: Dmitry Gutov <dmitry@gutov.dev>
>>
>> On 25/08/2023 08:42, Eli Zaretskii wrote:
>> > IME, the development model of Emacs is an important reason why Emacs
>> > is still alive and kicking almost 40 years since it was first
>> > developed. And important major modes in Emacs are alive and kicking
>> > with it. So inclusion in Emacs and the pains of adjusting to a
>> > different development model are justified if one wants the major mode
>> > to remain alive for many years to come. Something to think about, I
>> > guess.
>>
>> Or the longevity stems from other reasons (e.g. good fundamental ideas,
>> unique proposition, being part of the original GNU system, ...), and the
>> development process is the reason the current user base is a fraction of
>> even Vim's (not to mention popular commercial offerings).
>>
>> Just an alternative POV to consider. In truth, could be a little of both.
>
> Mine wasn't a POV, it was an observation based on many years of
> watching the development and being part of it.
Correct me if I am wrong: This seems to be related to the fact that the
GitHub-model (thought it probably precedes it) of development has
motivated more and more individuals to maintain packages, instead of
organisations like GNU, Apache, etc. Or at least I understand that if
there is a collective effort behind maintaining the components of a
system, contributors can come and go without a package being abandoned
-- this is especially true for Emacs due to the extensive
introspectability. But it appears this reaches a limit, if a component
is too complex (CEDET was mentioned as one example, and if João were to
suddenly loose interest in contributing to Emacs, something similar
might happen to Eglot as well).
I only mention this, because I don't agree with the premise that this
boils down to "mailing-list" or "web-interface". While it is true that
a lot of people are uncertain and afraid of sending a message to a
mailing list, this fear is unreasonable and worth dispelling.
I think there is a reasonable point to be made that the CA prevents
certain valuable contributions from entering Emacs/GNU ELPA. IANAL, so
I don't know if a sign-off procedure would be a sufficient alternative?
But if I am a bit cynical, I cannot deny that having a CA-system can
also help filtering out a lot of noise and low-quality code (I'd claim
that the average quality of a ELPA package is higher than that of
packages on MELPA...).
^ permalink raw reply [relevance 76%]
* 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: Stefen Kangas is now an Emacs maintainer
@ 2023-08-26 7:21 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-08-26 7:21 UTC (permalink / raw)
To: Po Lu; +Cc: Eli Zaretskii, rms, emacs-devel
Po Lu <luangruo@yahoo.com> writes:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Richard Stallman <rms@gnu.org>
>>> Date: Fri, 25 Aug 2023 22:02:47 -0400
>>>
>>> I've appointed Stefan Kangas as a comaintainer of Emacs.
>>
>> Good news!
>
> Seconded. We're lucky to have secured the assistance of an individual
> such as Stefan, who's indefatigable efforts towards a better Emacs
> benefit us all.
I agree, he is a true maintainer in action and spirit ;),
This is especially good news since the prolonged and mysterious absence
of Lars, which seems to have put undue pressure on Eli during the last
release cycle.
Stefan: Are there any {concrete,vague} plans you wish to pursue as
maintainer?
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Clojure mode
@ 2023-08-26 7:16 88% ` Philip Kaludercic
1 sibling, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-08-26 7:16 UTC (permalink / raw)
To: Richard Stallman; +Cc: danny, eliz, emacs-devel, manuel.uberti
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 could be done by getting copyright assignments for code in the
> > > NonGNU ELPA package, or by writing new code to replace it, or by a
> > > mixture of the two.
>
> > The issue here is, that the clojure-mode developers are mostly averse to
> > assigning their code to the FSF.
>
> What those people think should not be a crucial issue, because writing
> a major mode to handle a language is not a big job. We have dozens of
> them in Emacs. Lots of us here would be able to replace it.
IMO it really depends on the level of integration one is aiming for. As
mentioned in my last message, if it is just basic syntax support, then I
guess anyone with a language specification could do it. But since
Closure is some sort of a mock-lisp, a user might be interested in
having more complex features such as REPL integration and perhaps some
kind of proper indentation for macros (assuming Clojure has macros).
> The trick is to start thinking of it as a module to be written,
> rather than as a need for something that we can't have;
I still question the need for replicating the labour, if the only
advantage the user has is that they don't have to M-x package-install
the existing major mode from NonGNU ELPA. Especially when given
functionality like what the "gnu-elpa" package provides, in being able
to suggest the right packages for a file type (which is currently
underutilised and IMO should be moved into package.el itself).
> > , but one idea might be to extend lisp-data-mode by whatever the
> > syntactic differences are, to at least have some basic visual support in
> > terms of syntax highlighting and the like.
>
> It is fine to copy some code from an existing mode. I just advise
> people not to try to arrange to share the code between the two modes.
> I expect that the sharing would make for more complexity than it is
> worth.
--
Philip Kaludercic
^ permalink raw reply [relevance 88%]
* Re: [elpa] externals/standard-themes 0604883ecc: Expand 'deftheme' with metadata
@ 2023-08-25 19:01 98% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-08-25 19:01 UTC (permalink / raw)
To: Protesilaos Stavrou; +Cc: emacs-devel
Protesilaos Stavrou <info@protesilaos.com> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Date: Fri, 25 Aug 2023 07:43:55 +0000
>>
>> 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.
>
>> [... 20 lines elided]
>>
>> 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.
>
> Thank you Philip! In that the case, I will have to revert the commit
> and only apply it to the modus-themes on the emacs.git trunk.
>
> That granted, I am evaluating the following with Emacs 28 and it does
> not throw an error (see attached screenshot as well):
>
> (deftheme modus-operandi
> "Elegant, highly legible theme with a white background.
> Conforms with the highest legibility standard for color contrast
> between background and foreground in any given piece of text,
> which corresponds to a minimum contrast in relative luminance of
> 7:1 (WCAG AAA standard)."
> :background-mode 'light
> :kind 'color-scheme
> :family 'modus)
My bad, the old definition of `deftheme' actually had a &rest _ignored
at the end of the argument list, but that was removed in a4a35305 (which
according to git tag --contains was after Emacs 28). From what I
recall, in bug#57639 the issue was related to the scraping of autoload
cookies, and that before that report, the scraper would have copied the
entire definition, while the new definition just copies the properties.
^ permalink raw reply [relevance 98%]
* Re: Org mode and Emacs
@ 2023-08-25 18:56 96% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-08-25 18:56 UTC (permalink / raw)
To: Bastien Guerry; +Cc: Richard Stallman, emacs-devel
Bastien Guerry <bzg@gnu.org> writes:
> Richard Stallman <rms@gnu.org> writes:
>
>> The term "as good as" may suggest, incorrectly, that this is a matter
>> of comparing the two formats over some sense of _quality_. But that's
>> not what this is about. The improvements I've proposed for Org format
>> are a matter of _supporting the range of necessary constructs_.
>
> I'm confident we can support the necessary constructs in Org.
>
>> > Let's simply try to improve Org in general, and see if more GNU
>> > maintainers want to use it as their native documentat format (the
>> > example of Org's documentation shows it's already possible.)
>>
>> We need to be careful here. What does the existence of Org mode
>> documentation written in Org format actually show -- given that the
>> format doesn't support all the constructs that are needed in general?
>>
>> It might show that the Org mode documentation doesn't make all the
>> textual distinctions properly -- that it fails to follow our style
>> guide. If so, then it is "possible" but only with flawed output.
>
> If a .texi expert can report such flaws in the Org manual, we can then
> fix them and, if needed, implement the necessary constructs.
I don't know if this is of any use, but the initial manual for Compat
(https://elpa.gnu.org/packages/compat.html) was written using Org and
ox-texinfo and I later switched to writing .texi directly. This commit
here documents the switch that includes a partial rewrite.
https://git.sr.ht/~pkal/compat/commit/dd48603a136881a5321de4419be95ea873496172
Some things here might be difficult to map, such as the proper usage of
reference macros or the different kinds of markup from (texinfo) Indicating.
>
>> But not necesarily. Perhaps it shows that the Org mode documentation
>> needs only a limited subset of those constructs, and those are all
>> implemened in Ogr format. If so, that could mean that Org format is
>> fine for the Org mode manual in prticular, but is not adequate for the
>> whole range of our documentation.
>
> I believe this is more plausible.
>
>> Either way, to make Org format adequate for that whole range of
>> constructs, in all the output formats, will require working
>> specifically towards that goal.
>
> Agreed, and this is what Org maintainers are working on.
^ permalink raw reply [relevance 96%]
* 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, 1 reply; 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: Clojure mode
@ 2023-08-25 7:25 96% ` Philip Kaludercic
0 siblings, 2 replies; 200+ results
From: Philip Kaludercic @ 2023-08-25 7:25 UTC (permalink / raw)
To: Richard Stallman; +Cc: Danny Freeman, eliz, emacs-devel, manuel.uberti
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 appears that there is no clojure-mode command in core Emacs.
> There is a Clojure mode package, but it is in NonGNU ELPA.
>
> I think that language is important enough that, notwithstanding not
> really being similar to Lisp, we ought to have a major mode to support it.
> Would someone please work on that?
I had brought this up in the recent clojure-ts-mode thread, that I
assume you are referring to. Sadly, I have no experience with the
language, but one idea might be to extend lisp-data-mode by whatever the
syntactic differences are, to at least have some basic visual support in
terms of syntax highlighting and the like.
> This could be done by getting copyright assignments for code in the
> NonGNU ELPA package, or by writing new code to replace it, or by a
> mixture of the two.
The issue here is, that the clojure-mode developers are mostly averse to
assigning their code to the FSF.
^ permalink raw reply [relevance 96%]
* 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: New Package for NonGNU-ELPA: clojure-ts-mode
@ 2023-08-24 16:20 89% ` Philip Kaludercic
1 sibling, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-08-24 16:20 UTC (permalink / raw)
To: Danny Freeman; +Cc: Eli Zaretskii, emacs-devel, manuel.uberti
Danny Freeman <danny@dfreeman.email> writes:
> Danny Freeman <danny@dfreeman.email> writes:
>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>>> I'm at a loss how people who develop an Emacs package can object to
>>> adding their package to Emacs. But so be it.
>>
>> Well down the road when clojure-ts-mode has stabilized I will make sure
>> we will revisit the idea of moving it to the core. Until then, I hope
>> y'all see the value of making it available in NonGNU ELPA.
>
>
> Bumping this thread. Will y'all consider listing this on non-gnu elpa?
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")
--
2.40.1
>
> Thank you,
^ permalink raw reply related [relevance 89%]
* Re: vc-git-grep vs project-find-regexp
@ 2023-08-21 18:51 96% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-08-21 18:51 UTC (permalink / raw)
To: Nicolás Ojeda Bär; +Cc: emacs-devel
Nicolás Ojeda Bär <n.oje.bar@gmail.com> writes:
> Hello,
>
> I have used M-x vc-git-grep for a long time, but decided to give M-x
> project-find-regexp a try after switching to 29.1.
>
> While it seems to work well, project-find-regexp seems much slower
> than vc-git-grep. After you execute the command, it pauses for what it
> feels a long time (~2s in a medium-size codebase) before showing the
> results. vc-git-grep on the other hand, starts displaying results
> immediately.
I suspect the reason is that in the former case, you are actually using
the "git grep" sub-command, that is more efficient, while
`project-find-regexp' defers to `xref-matches-in-files' and uses
`xref-search-program', which is set to regular "grep" by default. You
can try out the other available tools (ripgrep and ugrep) to see if it
might improve your performance?
> Is there a good reason for this difference? The only visible
> difference between both commands is that project-find-regexp's results
> are displayed in a XREF buffer while vc-git-grep uses Grep mode.
That shouldn't make much of a difference, the main bottle-neck here is
disk IO.
> Insights appreciated!
>
> Best wishes,
> Nicolas
^ permalink raw reply [relevance 96%]
* 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: 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: 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: Proposal for 'package-isolate' command
@ 2023-08-20 18:41 97% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-08-20 18:41 UTC (permalink / raw)
To: Thierry Volpiatto; +Cc: emacs-devel
Thierry Volpiatto <thievol@posteo.net> writes:
> Thierry Volpiatto <thievol@posteo.net> writes:
>
>> Hello 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):
>>>
>>> [2. text/x-diff; 0001-Add-command-to-start-Emacs-with-specific-packages.patch]...
>>
>> I was reading the code of the new version of `package--dependencies` and
>> had some questions:
>>
>> --8<---------------cut here---------------start------------->8---
>> (named-let more ((pkg-desc desc))
>> (let (deps)
>> (dolist (req (package-desc-reqs pkg-desc))
>> (setq deps (nconc
>> (catch 'found
>> (dolist (p (apply #'append (mapcar #'cdr (package--alist))))
>> (when (and (string= (car req) (package-desc-name p))
>> (version-list-<= (cadr req) (package-desc-version p)))
>> (throw 'found (more p)))))
>> deps)))
>> (delete-dups (cons pkg-desc deps))))
>> --8<---------------cut here---------------end--------------->8---
>>
>> Why are you using `string=` to compare (car req)
>> with (package-desc-name p)?
>>
>> Isn't (apply #'append (mapcar #'cdr (package--alist))) same as
>> (mapcar #'cadr (package--alist))?
>>
>> I am not a fan of named-let but isn't using deps as a second arg of
>> 'more' more in the named-let spirit? (fully not tested)
>>
>> --8<---------------cut here---------------start------------->8---
>> (named-let more ((pkg-desc desc)
>> (deps nil))
>> (dolist (req (package-desc-reqs pkg-desc))
>> (setq deps (nconc
>> (catch 'found
>> (dolist (p (apply #'append (mapcar #'cdr (package--alist))))
>> (when (and (string= (car req) (package-desc-name p))
>> (version-list-<= (cadr req) (package-desc-version p)))
>> (throw 'found (more p deps)))))
>> deps)))
>> (delete-dups (cons pkg-desc deps)))
>> --8<---------------cut here---------------end--------------->8---
>
> After some tests this create circular lists, so forget it.
I guess you could avoid that by replacing 'nconc' with 'append'.
> Also now from Emacs 29 (magit is NOT installed):
>
> (package-initialize)
> (package--dependencies 'magit)
> => (emacs compat dash git-commit magit-section seq transient with-editor)
>
> Now if I eval your new package--dependencies from Emacs 30:
> (package-initialize)
> (package--dependencies 'magit)
> => (compat)
>
> What is wrong is you are looping in package-alist instead of
> package-archive-contents, in fact you don't need to loop at all, just
> using assq or package-get-descriptor:
>
> (defun package--dependencies (pkg)
> "Return a list of all transitive dependencies of PKG.
> If PKG is a package descriptor, the return value is a list of
> package descriptors. If PKG is a symbol designating a package,
> the return value is a list of symbols designating packages."
> (when-let* ((desc (if (package-desc-p pkg) pkg
> (cadr (assq pkg package-archive-contents)))))
> ;; Can we have circular dependencies? Assume "nope".
> (let ((all (cl-labels ((more (pkg-desc)
> (let (deps)
> (dolist (req (package-desc-reqs pkg-desc))
> (setq deps (nconc
> (when-let* ((matched (package-get-descriptor (car req)))
> (version<= (version-list-<=
> (cadr req)
> (package-desc-version matched))))
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?
> (more matched))
> deps)))
> (delete-dups (cons pkg-desc deps)))))
> (more desc))))
> (remq pkg (mapcar (if (package-desc-p pkg) #'identity #'package-desc-name) all)))))
>
> PS: Sorry I used cl-labels to test as I am not easy with named-let.
"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.
^ permalink raw reply [relevance 97%]
* Re: Proposal for 'package-isolate' command
@ 2023-08-20 7:51 91% ` Philip Kaludercic
1 sibling, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-08-20 7:51 UTC (permalink / raw)
To: Thierry Volpiatto; +Cc: emacs-devel
Thierry Volpiatto <thievol@posteo.net> writes:
> Hello 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):
>>
>> [2. text/x-diff;
>> 0001-Add-command-to-start-Emacs-with-specific-packages.patch]...
>
> I was reading the code of the new version of `package--dependencies` and
> had some questions:
>
> (named-let more ((pkg-desc desc))
> (let (deps)
> (dolist (req (package-desc-reqs pkg-desc))
> (setq deps (nconc
> (catch 'found
> (dolist (p (apply #'append (mapcar #'cdr (package--alist))))
> (when (and (string= (car req) (package-desc-name p))
> (version-list-<= (cadr req) (package-desc-version p)))
> (throw 'found (more p)))))
> deps)))
> (delete-dups (cons pkg-desc deps))))
>
>
> Why are you using `string=` to compare (car req)
> with (package-desc-name p)?
As opposed to what alternative? The advantage of `string=' compared to
something like equal is that 1. that I do not have to care if a package
name is a symbol or a string 2. that all other values would trigger an
error.
> Isn't (apply #'append (mapcar #'cdr (package--alist))) same as
> (mapcar #'cadr (package--alist))?
Iff every package in (package--alist) only had one package descriptor,
which is not the case
(seq-filter
(lambda (e) (length> e 2))
(package--alist))
;=> non-nil
Also, see
(seq-set-equal-p
(apply #'append (mapcar #'cdr (package--alist)))
(mapcar #'cadr (package--alist)))
;=> nil
> I am not a fan of named-let but isn't using deps as a second arg of
> 'more' more in the named-let spirit? (fully not tested)
>
> (named-let more ((pkg-desc desc)
> (deps nil))
> (dolist (req (package-desc-reqs pkg-desc))
> (setq deps (nconc
> (catch 'found
> (dolist (p (apply #'append (mapcar #'cdr (package--alist))))
> (when (and (string= (car req) (package-desc-name p))
> (version-list-<= (cadr req) (package-desc-version p)))
> (throw 'found (more p deps)))))
> deps)))
> (delete-dups (cons pkg-desc deps)))
The only difference I believe would occur in this case, is that we would
always maintain "the same" list of dependencies, throughout traversing
all package dependencies. In the end that shouldn't change much, and it
is only more work for `delete-dups'.
> Thanks.
^ permalink raw reply [relevance 91%]
* Re: Preferred approach to inclusion of data in ELPA package
@ 2023-08-19 15:51 89% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2023-08-19 15:51 UTC (permalink / raw)
To: Hugo Thunnissen; +Cc: emacs-devel
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.
> Some more context, as I built and bench-marked a prototype: The
> resulting index file is 3.1MB of s-expressions which when compressed
> with gzip becomes a file of 172K (there's a lot of duplicate
> symbols/strings in there). Loading this file takes about 30% less time
> than building the index from scratch (300ms vs 430-450ms on my laptop
> with Core i5-8250U, byte compiled). I suppose this could be further
> optimized with a more efficient serialization format, but I don't want
> to spend much time on implementing that as I'm working towards an
> initial package release.
>
> How would having a Makefile like you suggest work in practice? Would I
> need to request that the ELPA maintainers add my Makefile to the build
> process of my package somehow? Or is there a standard automated way to
> have Makefiles be executed during an ELPA build?
An ELPA package specification can include :make and :shell-command
queries, that are executed on the ELPA build server, with restricted
permissions. If you take a look at
https://git.savannah.gnu.org/cgit/emacs/elpa.git/tree/elpa-packages and
their respective repositories, you will find a few examples.
> 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.
^ permalink raw reply [relevance 89%]
* 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: [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: Adding package and package-vc to ELPA
@ 2023-08-18 18:34 81% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2023-08-18 18:34 UTC (permalink / raw)
To: Thierry Volpiatto; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1237 bytes --]
Philip Kaludercic <philipk@posteo.net> writes:
>> Now your function is working fine and nearly finish, did you think how
>> you are going to distribute it? It seems you are going to merge it in
>> master, but what about providing it as well as a Elpa package so that
>> users of old emacs (at some point of course, say emacs-27) can use it to
>> report bugs?
>
> I am not a fan of small ELPA packages, but what I'd like to bring up
> again was the proposal to add package.el itself to ELPA. I wrote a
> patch in <873559q83j.fsf@posteo.net> that should arrange everything
> necessary for this move, there are still a few points that should be
> discussed in terms of stability and recovering from a possibly
> inconsistent state. I think I'll create a feature branch some day soon
> to make the proposal more concrete.
I have pushed the patch from that thread, together with a patch for
package-vc and a custom command that would revert Emacs to use the
built-in version of package.el. The branch is called
"feature/elpa-package", and I have added to tarballs with packages built
by elpa-admin.el in case anyone wants to try out the packages. I'll be
testing these tarballs with older versions of Emacs, to see how that
works out.
[-- Attachment #2: package.tar --]
[-- Type: application/x-tar, Size: 204800 bytes --]
[-- Attachment #3: package-vc.tar --]
[-- Type: application/x-tar, Size: 51200 bytes --]
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #4: 0001-elpa-packages-package-package-vc-New-packages.patch --]
[-- Type: text/x-diff, Size: 910 bytes --]
From 3834109bf379fae333b60adf49dd119bd538635a Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Fri, 18 Aug 2023 20:33:24 +0200
Subject: [PATCH] * elpa-packages (package,package-vc): New packages
---
elpa-packages | 2 ++
1 file changed, 2 insertions(+)
diff --git a/elpa-packages b/elpa-packages
index 3949d8fe14..ced827955b 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -521,7 +521,9 @@
(paced :url "bzr::bzr://bzr.savannah.nongnu.org/paced-el/trunk"
;; The Bzr<->Git bridge wasn't working well enough last time I tried.
:manual-sync t)
+ (package :core "lisp/emacs-lisp/package.el")
(package-fixes :url nil)
+ (package-vc :core "lisp/emacs-lisp/package-vc.el")
(parsec :url "https://github.com/cute-jumper/parsec.el.git")
(parser-generator :url "https://github.com/cjohansson/emacs-parser-generator")
(path-iterator :url nil)
--
2.41.0
^ permalink raw reply related [relevance 81%]
Results 201-400 of ~1772 next (older) | prev (newer) | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
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
2023-08-23 2:12 ` Richard Stallman
2023-08-24 11:52 ` Bastien Guerry
2023-08-25 1:14 ` Richard Stallman
2023-08-25 9:04 ` Bastien Guerry
2023-08-25 18:56 96% ` Philip Kaludercic
2023-03-30 13:42 Request to add Package to GNU ELPA Jonas Bernoulli
2023-03-30 17:32 ` Philip Kaludercic
2023-03-31 17:15 ` Jonas Bernoulli
2023-04-05 8:59 ` Philip Kaludercic
2023-04-17 16:24 ` Adding package-vc to ELPA Philip Kaludercic
2023-09-16 17:20 ` Stefan Kangas
2023-09-17 8:02 90% ` Philip Kaludercic
2023-06-07 3:18 question regarding my emacs package ram
2023-06-07 15:53 ` Philip Kaludercic
2023-06-07 18:04 ` Philip Kaludercic
2023-06-07 19:45 ` ram
2023-06-07 19:48 ` Philip Kaludercic
2023-06-07 19:50 ` ram
2023-06-07 22:34 ` ram
2023-06-08 7:13 ` ram
2023-06-08 7:26 ` Philip Kaludercic
2023-06-08 18:50 ` ram
2023-09-08 7:40 98% ` Philip Kaludercic
2023-07-08 9:35 NonGNU ELPA: New package 'xdg-appmenu' Akib Azmain Turja
2023-09-05 18:31 ` Akib Azmain Turja
2023-09-05 20:11 ` Stefan Kangas
2023-09-06 7:42 97% ` 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 82% ` Philip Kaludercic
2023-09-08 11:34 ` Stefan Kangas
2023-09-08 17:28 99% ` Philip Kaludercic
2023-07-13 20:54 Distribution statistics for ELPA and EMMS Yoni Rabkin
2023-07-13 23:16 ` Eduardo Ochs
2023-07-14 7:03 ` Philip Kaludercic
2023-07-14 14:02 ` Yoni Rabkin
2023-07-14 19:45 ` Adam Porter
2023-07-17 2:25 ` Richard Stallman
2023-09-19 14:49 ` Adam Porter
2023-09-19 16:38 98% ` Philip Kaludercic
2023-09-19 19:00 ` Akib Azmain Turja
2023-09-19 22:06 74% ` Philip Kaludercic
2023-09-07 16:46 ` Stefan Kangas
2023-09-08 7:51 97% ` 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-19 5:09 ` Yuan Fu
2023-08-19 9:04 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 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 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-17 13:56 ` Thierry Volpiatto
2023-08-17 14:28 ` Thierry Volpiatto
2023-08-17 18:17 ` Philip Kaludercic
2023-08-18 4:57 ` Thierry Volpiatto
2023-08-18 7:49 ` Philip Kaludercic
2023-08-18 18:34 81% ` Adding package and package-vc to ELPA Philip Kaludercic
2023-08-20 6:40 ` Proposal for 'package-isolate' command Thierry Volpiatto
2023-08-20 7:51 91% ` Philip Kaludercic
2023-08-20 16:06 ` Thierry Volpiatto
2023-08-20 18:41 97% ` Philip Kaludercic
2023-08-20 19:15 ` Thierry Volpiatto
2023-08-20 20:28 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-09-12 15:05 ` Stefan Kangas
2023-09-19 16:26 ` Andrew Hyatt
2023-09-19 16:34 45% ` Philip Kaludercic
2023-08-12 18:35 New Package for NonGNU-ELPA: clojure-ts-mode Danny Freeman
2023-08-12 19:10 ` 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-24 16:20 89% ` Philip Kaludercic
2023-08-25 1:47 ` Danny Freeman
2023-08-25 7:20 99% ` Philip Kaludercic
2023-08-25 1:11 ` Clojure mode Richard Stallman
2023-08-25 7:25 96% ` Philip Kaludercic
2023-08-26 2:05 ` Richard Stallman
2023-08-26 7:16 88% ` Philip Kaludercic
2023-08-26 14:05 ` Dmitry Gutov
2023-08-27 1:35 ` 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 93% ` Philip Kaludercic
2023-08-29 20:24 ` Stefan Kangas
2023-08-29 20:31 97% ` Philip Kaludercic
2023-08-29 20:43 ` Stefan Kangas
2023-08-30 7:26 95% ` Philip Kaludercic
2023-08-30 11:11 ` Eli Zaretskii
2023-08-30 11:51 99% ` Philip Kaludercic
2023-08-30 12:09 ` Eli Zaretskii
2023-08-30 12:25 90% ` Philip Kaludercic
2023-08-30 13:32 ` Eli Zaretskii
2023-08-30 19:26 53% ` 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 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 87% ` package-autosuggest Philip Kaludercic
2023-09-01 15:20 ` package-autosuggest Stefan Monnier
2023-09-01 15:47 99% ` package-autosuggest Philip Kaludercic
2023-09-03 19:25 ` package-autosuggest chad
2023-09-04 16:10 95% ` 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-29 21:09 ` Brand new clojure support in Emacs ;-) João Távora
2023-08-30 7:17 94% ` Philip Kaludercic
2023-08-30 9:24 ` João Távora
2023-08-30 10:15 88% ` Philip Kaludercic
2023-08-30 21:47 ` João Távora
2023-08-31 5:43 98% ` Philip Kaludercic
2023-08-31 6:46 ` Kévin Le Gouguec
2023-08-31 7:01 99% ` Philip Kaludercic
2023-09-03 15:04 ` Bozhidar Batsov
2023-09-03 15:19 83% ` Philip Kaludercic
2023-09-03 15:37 ` Bozhidar Batsov
2023-09-03 16:03 77% ` Philip Kaludercic
2023-08-24 20:21 ` New Package for NonGNU-ELPA: clojure-ts-mode 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 76% ` 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:22 ` Po Lu
2023-08-27 12:44 ` Dmitry Gutov
2023-08-27 12:57 ` Po Lu
2023-08-27 13:12 ` Dmitry Gutov
2023-08-27 13:25 89% ` Philip Kaludercic
2023-08-27 13:36 ` Eli Zaretskii
2023-08-27 14:13 91% ` Philip Kaludercic
2023-08-27 16:04 ` Eli Zaretskii
2023-08-27 17:38 ` Bozhidar Batsov
2023-08-27 18:32 ` Stefan Kangas
2023-08-27 18:43 ` Bozhidar Batsov
2023-08-27 19:05 80% ` Philip Kaludercic
2023-08-28 15:22 ` Lynn Winebarger
2023-08-28 16:21 ` Eli Zaretskii
2023-08-28 20:03 ` Lynn Winebarger
2023-08-29 2:27 ` Eli Zaretskii
2023-08-29 7:33 ` Bozhidar Batsov
2023-08-29 11:33 88% ` Philip Kaludercic
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-30 0:11 ` Dmitry Gutov
2023-08-30 11:24 ` Eli Zaretskii
2023-08-30 20:29 ` Dmitry Gutov
2023-08-31 7:18 ` Eli Zaretskii
2023-09-01 0:29 ` Dmitry Gutov
2023-09-01 7:15 ` Visuwesh
2023-09-01 13:24 86% ` Philip Kaludercic
2023-08-27 6:26 ` New Package for NonGNU-ELPA: clojure-ts-mode João Távora
2023-08-27 13:16 98% ` Philip Kaludercic
2023-08-26 14:07 ` 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 71% ` Philip Kaludercic
2023-08-31 22:05 ` Jens Schmidt
2023-09-01 14:55 82% ` 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 67% ` 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 8:53 ` Ihor Radchenko
2023-09-03 9:40 99% ` Philip Kaludercic
2023-09-03 9:39 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 89% ` 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-08-19 6:03 Adding refactoring capabilities to Emacs Eli Zaretskii
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-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
[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 ` Philip Kaludercic
2023-08-19 11:08 ` Stefan Kangas
2023-08-19 15:46 99% ` Philip Kaludercic
2023-08-21 15:29 vc-git-grep vs project-find-regexp Nicolás Ojeda Bär
2023-08-21 18:51 96% ` 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
2023-08-25 9:15 ` Protesilaos Stavrou
2023-08-25 19:01 98% ` Philip Kaludercic
2023-08-26 2:02 Stefen Kangas is now an Emacs maintainer Richard Stallman
2023-08-26 5:48 ` Eli Zaretskii
2023-08-26 6:26 ` Po Lu
2023-08-26 7:21 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-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 99% ` [NonGNU ELPA] New package: hyperdrive (repast) Philip Kaludercic
2023-08-29 4:04 ` Joseph Turner
2023-08-29 11:56 99% ` Philip Kaludercic
2023-09-03 8:18 45% ` Philip Kaludercic
2023-08-27 15:14 Shrinking the C core Arthur Miller
2023-08-28 5:36 ` Po Lu
2023-08-28 6:55 ` Arthur Miller
2023-08-28 7:31 ` Po Lu
2023-08-28 14:08 ` Arthur Miller
2023-08-31 2:07 ` Richard Stallman
2023-09-01 14:58 ` Arthur Miller
2023-09-04 1:32 ` Richard Stallman
2023-09-04 1:44 ` Emanuel Berg
2023-09-07 1:21 ` Richard Stallman
2023-09-07 1:54 ` Emanuel Berg
2023-09-11 0:43 ` Richard Stallman
2023-09-11 12:24 ` Eli Zaretskii
2023-09-12 11:31 ` Lynn Winebarger
2023-09-12 13:00 ` Emacs design and architecture (was: Shrinking the C core) Eli Zaretskii
2023-09-13 20:52 ` Lynn Winebarger
2023-09-14 5:57 ` Eli Zaretskii
2023-09-14 6:30 ` Emacs design and architecture Gerd Möllmann
2023-09-14 6:38 ` Po Lu
2023-09-14 6:49 ` Gerd Möllmann
2023-09-14 15:03 ` Helmut Eller
2023-09-14 16:23 98% ` 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
2023-08-31 2:23 [NonGNU ELPA] New package: flymake-guile Distopico
2023-08-31 6:52 80% ` Philip Kaludercic
2023-08-31 16:08 ` Distopico
2023-08-31 18:02 93% ` 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 50% ` Philip Kaludercic
2023-09-05 2:23 ` Distopico
2023-09-05 7:08 99% ` Philip Kaludercic
2023-09-05 15:09 ` Distopico
2023-09-05 16:01 92% ` Philip Kaludercic
[not found] <169373450576.30740.4674573984693456027@vcs2.savannah.gnu.org>
[not found] ` <20230903094826.33FFAC045B5@vcs2.savannah.gnu.org>
2023-09-03 9:54 98% ` 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
2023-09-03 22:18 [IDEA] Add function clean-buffer Joseph Turner
2023-09-04 16:02 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
2023-09-04 20:34 [ELPA] New package: breadcrumb.el João Távora
2023-09-04 20:47 98% ` Philip Kaludercic
2023-09-04 20:56 ` João Távora
2023-09-05 6:21 96% ` Philip Kaludercic
2023-09-05 9:16 ` João Távora
2023-09-05 10:16 99% ` Philip Kaludercic
2023-09-05 15:58 ` Jonas Bernoulli
2023-09-05 16:41 ` João Távora
2023-09-05 16:55 41% ` Philip Kaludercic
2023-09-05 17:00 ` João Távora
2023-09-05 17:39 99% ` Philip Kaludercic
[not found] <169385595799.24305.652316651780689026@vcs2.savannah.gnu.org>
[not found] ` <20230904193238.46053C04DB0@vcs2.savannah.gnu.org>
2023-09-04 20:54 98% ` 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
2023-09-05 16:55 Proposal to add Popper to ELPA Karthik Chikmagalur
2023-09-05 17:38 25% ` Philip Kaludercic
2023-09-05 20:12 ` Karthik Chikmagalur
2023-09-06 17:36 91% ` 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-09-08 21:52 ` Karthik Chikmagalur
2023-09-09 8:10 89% ` Philip Kaludercic
2023-09-09 10:10 [NonGNU ELPA] New package: blueprint-ts-mode Huan Thieu Nguyen
2023-10-02 10:20 67% ` Philip Kaludercic
[not found] <87wn1axgh6.fsf@breatheoutbreathe.in>
[not found] ` <87v8csku60.fsf@breatheoutbreathe.in>
[not found] ` <83cyyz94c6.fsf@gnu.org>
[not found] ` <87a5u2ydzg.fsf@breatheoutbreathe.in>
[not found] ` <83msy25g0s.fsf@gnu.org>
[not found] ` <624CBB7F-1442-400D-8D4D-1B26EBE9DACB@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 96% ` compat.el and Emacs unstable master branch features Philip Kaludercic
2023-09-12 10:27 ` Daniel Mendler
2023-09-13 10:31 55% ` 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] <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
2023-09-18 2:28 [GNU ELPA] New package: tam Lynn Winebarger
2023-09-18 9:37 48% ` Philip Kaludercic
2023-09-18 16:22 ` Lynn Winebarger
2023-09-18 17:02 84% ` Philip Kaludercic
2023-09-19 15:38 ` Lynn Winebarger
2023-09-20 8:26 80% ` Philip Kaludercic
2023-09-20 16:14 ` Lynn Winebarger
2023-09-21 16:38 86% ` Philip Kaludercic
2023-09-18 7:25 package-vc support for :files keyword Tony Zorman
2023-09-18 9:10 91% ` Philip Kaludercic
2023-09-18 14:43 ` Tony Zorman
2023-09-18 15:52 81% ` Philip Kaludercic
2023-09-18 18:54 ` Adam Porter
2023-09-19 8:37 97% ` Philip Kaludercic
2023-09-19 12:23 ` Adam Porter
2023-09-19 13:56 99% ` Philip Kaludercic
2023-09-18 19:40 ` Tony Zorman
2023-09-19 8:47 94% ` 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 67% ` Philip Kaludercic
2023-09-21 13:28 ` Tony Zorman
2023-09-21 16:32 99% ` Philip Kaludercic
[not found] ` <87jzsgm82h.fsf@hyperspace>
2023-09-24 14:31 99% ` Philip Kaludercic
2023-09-25 13:32 ` Tony Zorman
2023-09-27 14:03 67% ` Philip Kaludercic
2023-09-19 22:51 ` Jonas Bernoulli
2023-09-22 12:38 ` Stefan Kangas
2023-09-22 13:26 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
2023-09-19 7:24 [package-vc] Consider cleaning up files from install process Joseph Turner
2023-09-19 9:03 83% ` Philip Kaludercic
2023-09-19 12:19 ` Adam Porter
2023-09-19 13:50 93% ` Philip Kaludercic
2023-09-19 14:34 ` Adam Porter
2023-09-20 8:13 68% ` Philip Kaludercic
2023-10-07 7:52 ` Adam Porter
2023-10-07 13:31 69% ` Philip Kaludercic
2023-09-21 20:15 New tree-sitter mode: bison-ts-mode Augustin Chéneau (BTuin)
2023-09-22 7:38 67% ` Philip Kaludercic
2023-09-22 14:53 ` Augustin Chéneau (BTuin)
2023-09-22 20:40 81% ` 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-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
2023-10-04 15:35 ` [External] : " Drew Adams
2023-10-04 16:26 ` Thanos Apollo
2023-10-06 8:59 88% ` 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
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-10-13 18:11 ` Updating *Completions* as you type Daniel Semyonov
2023-10-13 18:48 ` Spencer Baugh
2023-10-16 3:16 ` [External] : " Drew Adams
2023-10-16 9:25 68% ` Philip Kaludercic
2023-10-16 16:03 ` Drew Adams
2023-10-20 7:45 88% ` Philip Kaludercic
2023-10-13 10:35 [ELPA] New package: dape Daniel Pettersson
2023-10-13 12:24 33% ` Philip Kaludercic
2023-10-14 12:28 ` Daniel Pettersson
2023-10-14 14:54 63% ` Philip Kaludercic
2023-10-15 13:50 ` James Thomas
2023-10-15 14:12 99% ` Philip Kaludercic
2023-10-18 21:54 ` Daniel Pettersson
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
2023-11-23 6:10 91% ` Philip Kaludercic
2023-12-05 8:41 95% ` Philip Kaludercic
2023-12-05 9:18 ` João Távora
2023-12-05 10:59 98% ` Philip Kaludercic
2023-11-04 13:46 ` Adam Porter
2023-11-04 14:01 ` Eli Zaretskii
2023-11-04 14:24 92% ` Philip Kaludercic
2023-11-04 15:06 ` Adam Porter
2023-11-04 15:27 72% ` Philip Kaludercic
2023-10-19 15:12 97% ` Philip Kaludercic
2023-11-01 16:50 99% ` 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
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 98% ` 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 85% ` Philip Kaludercic
2023-12-14 12:41 79% ` Philip Kaludercic
2023-12-17 3:21 ` Richard Stallman
2023-12-17 11:51 73% ` Philip Kaludercic
2023-10-16 7:12 ` Stefan Kangas
2023-10-16 9:15 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
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-10-30 2:09 What's missing in ELisp that makes people want to use cl-lib? Richard Stallman
2023-10-31 2:31 ` Adam Porter
2023-10-31 10:38 ` João Távora
2023-11-02 2:28 ` Richard Stallman
2023-11-02 8:55 80% ` Philip Kaludercic
2023-11-02 9:27 ` Eli Zaretskii
2023-11-02 21:26 87% ` Philip Kaludercic
2023-11-03 7:07 ` Eli Zaretskii
2023-11-03 7:48 75% ` Philip Kaludercic
2023-11-03 7:59 ` Eli Zaretskii
2023-11-03 8:13 95% ` 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 79% ` 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
2023-10-30 7:18 ELPA submission: drepl (REPL protocol) Augusto Stoffel
2023-10-31 9:08 76% ` Philip Kaludercic
2023-11-01 18:28 ` Augusto Stoffel
2023-11-01 18:38 99% ` Philip Kaludercic
2023-11-07 8:20 99% ` Philip Kaludercic
2023-10-31 10:34 [ELPA] New package: dired-duplicates Harald Judt
2023-10-31 12:21 47% ` 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 81% ` Philip Kaludercic
2023-11-01 20:04 ` Harald Judt
2023-11-01 21:29 88% ` 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
2023-11-01 3:30 ` Eli Zaretskii
2023-11-01 13:53 ` Visuwesh
2023-11-01 14:12 ` Eli Zaretskii
2023-11-01 17:57 96% ` Philip Kaludercic
2023-11-03 8:21 What's missing in ELisp that makes, people want to use cl-lib? Pedro Andres Aranda Gutierrez
2023-11-03 13:37 ` Gerd Möllmann
2023-11-06 2:27 ` seq.el and the complexity of Emacs Lisp Richard Stallman
2023-11-06 6:51 97% ` Philip Kaludercic
2023-11-12 19:32 [ELPA] New package: SachaC-news Christian
2023-11-17 7:28 21% ` Philip Kaludercic
2023-11-18 20:30 ` Christian
2023-11-18 21:10 99% ` Philip Kaludercic
2023-11-25 22:07 ` Christian
2023-11-25 22:50 93% ` Philip Kaludercic
2023-11-13 20:31 [ELPA] New Package: p4_16-mode Soham Gumaste
2023-11-17 7:36 40% ` 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-11-16 3:04 Instead of pcase Richard Stallman
2023-11-16 7:37 95% ` 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-11-16 18:21 ` Dmitry Gutov
2023-11-16 18:39 ` T.V Raman
2023-11-16 18:47 81% ` Philip Kaludercic
2023-11-18 3:04 ` Richard Stallman
2023-11-19 13:49 ` Dmitry Gutov
2023-11-21 2:42 ` Richard Stallman
2023-11-24 17:29 ` Lynn Winebarger
2023-11-28 2:44 ` Richard Stallman
2023-11-30 19:14 ` Lynn Winebarger
2023-12-02 3:20 ` Richard Stallman
2023-12-02 8:41 ` Andreas Schwab
2023-12-02 9:02 76% ` Philip Kaludercic
2023-11-17 10:11 [Reminder]Decommissoned keyservers CHENG Gao via Emacs development discussions.
2023-11-17 21:02 ` Jonas Bernoulli
2023-11-18 15:41 99% ` Philip Kaludercic
2023-11-17 21:15 99% ` Philip Kaludercic
2023-11-18 10:43 [ELPA] New package: ert-font-lock Vladimir Kazanov
2023-11-18 11:18 61% ` 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-11-18 14:54 Turning on savehist-mode by default sbaugh
2023-11-18 16:33 ` [External] : " Drew Adams
2023-11-18 18:19 81% ` Philip Kaludercic
2023-11-18 21:06 ` Drew Adams
2023-11-18 21:42 70% ` Philip Kaludercic
2023-11-20 12:08 [ELPA] Add theme-buffet package Bruno Boal
2023-11-20 19:05 21% ` Philip Kaludercic
2023-11-24 11:38 ` Bruno Boal
2023-11-24 18:11 72% ` Philip Kaludercic
2023-11-24 18:39 Don't see PATCH on bug-gnu-emacs Niall Dooley
2023-11-24 20:57 98% ` 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
[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 97% ` Ellama comments Philip Kaludercic
2023-12-16 17:05 ` Sergey Kostyaev
2023-12-17 12:06 92% ` Philip Kaludercic
2023-12-17 16:56 ` Sergey Kostyaev
2023-12-17 21:39 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-12-18 19:12 The place for the "ELPA bundling" project Dmitry Gutov
2023-12-19 6:45 96% ` Philip Kaludercic
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).