* Re: Update of ELPA package guess-language
@ 2021-08-25 10:24 98% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-08-25 10:24 UTC (permalink / raw)
To: Titus von der Malsburg; +Cc: emacs-devel
Titus von der Malsburg <malsburg@posteo.de> writes:
> A while ago I contributed the package guess-language to ELPA [1]. In
> the meantime, I’ve added some improvements in my own git repository
> but it’s not entirely clear to me how I can update the ELPA version.
> From reading the ELPA README [2], it seems that I have to request an
> update on this list every time there is (significant-enough) change in
> my repo (since I wasn’t given push permissions). Is that really true?
> I’m asking because I rarely see such requests here and because it’s
> not a terribly efficient workflow. Is there no way that ELPA can
> automatically pull changes from the original repository?
It should be possible, some package specifications (see elpa-packages)
are given the :auto-sync attribute, but I am not sure what the
conditions are for a package to be granted this status.
If you want to, I can update the package for now. The only question is
whether or not everyone with a significant contribution has signed the
copyright assignment to the FSF.
> Titus
>
> [1] https://elpa.gnu.org/packages/guess-language.html
> [2] https://git.savannah.gnu.org/cgit/emacs/elpa.git/plain/README
>
>
--
Philip Kaludercic
^ permalink raw reply [relevance 98%]
* Re: master abe5eb9: Explain what ( . c) means to the Emacs Lisp reader
@ 2021-08-25 10:25 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-08-25 10:25 UTC (permalink / raw)
To: Stefan Kangas; +Cc: Lars Ingebrigtsen, Emacs developers
Stefan Kangas <stefan@marxist.se> writes:
> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> diff --git a/doc/lispref/objects.texi b/doc/lispref/objects.texi
>> index d8091f1..365d5ac 100644
>> --- a/doc/lispref/objects.texi
>> +++ b/doc/lispref/objects.texi
>> @@ -1001,6 +1001,13 @@ It looks like this:
>> @end example
>> @end ifnottex
>>
>> + As a somewhat peculiar side effect of @code{(a b . c)} and
>> +@code{(a . (b . c))} being equivalent, for consistency this means
>> +that if you replace @code{b} here with the empty sequence, then it
>> +follows that @code{(a . c)} and @code{(a . ( . c))} are equivalent,
>> +too. This also means that @code{( . c)} is equivalent to @code{c},
>> +but this is seldom used.
>
> This really is nitpicking but... should we perhaps say something even
> stronger here, for example "almost never used"?
Is it ever used?
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Easy configuration of a site-lisp directory
@ 2021-08-25 10:47 92% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-08-25 10:47 UTC (permalink / raw)
To: Arthur Miller; +Cc: emacs-devel
Arthur Miller <arthur.miller@live.com> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Just wanted to ping this message to check if there is any interest in
>> doing something with my initial suggestion?
>
> I do something similar as you do, but I use it only for some loose
> files I write myself, and for some I download from emacs wiki etc.
>
>>> The fundamental idea is to have an easy-to-use ~/.emacs.d/site-lisp/
>>> directory where a user can clone any repository or create their own,
>>> without having to manually add these to load-path, generate autoloads or
>>> byte compile.
>
> I have a question: is it desirable to use a working git directory as
> installed package? When I write my own files, I usually don't wish to
> copy them over to my "lisp" directory which I autoload in Emacs, untill
> I am done. Admittedly I started doing so before git has entered the
> scene. Now I guess one can switch branches every time one works on a package
> between some development branch and some stable, but isn't it a bit tedious?
Usually I don't store them in my site-lisp directory, but just symlink
what I want to use from my source code directory. If something isn't
functional or ready, there shouldn't be any reason I would want it
byte-compiled, autoloaded and ready to use by default.
If there is some critical change or something that isn't ready yet, I'd
just use "git stash".
> What you are suggesting is to effectively use "site-lisp" as another
> package-user-dir (~/.emacs.d/elpa on my machine). You are also auto
> recursing in all dirs, so if user wish to remove something they have to
> remove that directory from the path?
Yes, but I hesitate to compare it to package-user-dir, as to me packages
stand in relation to some package manager, while site-lisp.el only
implements the bare minimum.
> Why not hack pacakge.el to use "local archives", would work something like this:
It could be done, but as you say it is a hack.
--
Philip Kaludercic
^ permalink raw reply [relevance 92%]
* Re: Adding new packages to NonGNU ELPA
@ 2021-08-25 11:05 88% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-08-25 11:05 UTC (permalink / raw)
To: Bozhidar Batsov; +Cc: Emacs Devel
"Bozhidar Batsov" <bozhidar@batsov.dev> writes:
> Here's the next batch of patches, I hope I got everything right. I've
> started with the simple packages and I'll continue with CIDER and its
> related packages, as they have a bunch of transitive deps I'll need to
> add to NonGNU ELPA as well (a, parseedn, parseclj).
One of my hopes regarding NonGNU ELPA was that certain packages,
including dependencies could be effectively deprecated. Among these I
hoped to see packages such as a (but also s, f, ht, ...). My
understanding was that these were created to either compensate
deficiencies in the build-in functions provided by older versions of
Emacs. The other reason is that some people prefer a more functional
style of programming, that the usual stateful, imperative-ish Elisp
doesn't always provide.
Regarding the first motivation, I think it is legitimate, because that
is how backwards compatibility can be maintained. It might therefore
make sense to provide a compatibility library-package to provide useful
but perhaps simplified/dummy definitions of new functions, macros and
variables added in newer versions of Emacs. That of course would only
make sense if there is any consensus that the community libraries
shouldn't be used.
--
Philip Kaludercic
^ permalink raw reply [relevance 88%]
* Re: Easy configuration of a site-lisp directory
@ 2021-08-25 11:13 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-08-25 11:13 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> Max Brieiev [2021-08-23 12:14:46] wrote:
>> So is there any conclusion in this long thread about preferable setup
>> for the case described in the original post? And making local git
>> repositeries be package.el aware.
>
> From my point of view, the "preferable setup" is for someone to spice up
> `elpa-admin.el` to make it more user-friendly for that use-case.
I could look into this, because I was intending to work on elpa-admin.el
a bit anyway. But this would mean that it wouldn't work OOTB, right?
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Easy configuration of a site-lisp directory
@ 2021-08-25 14:55 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-08-25 14:55 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> Philip Kaludercic [2021-08-25 11:13:49] wrote:
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> Max Brieiev [2021-08-23 12:14:46] wrote:
>>>> So is there any conclusion in this long thread about preferable setup
>>>> for the case described in the original post? And making local git
>>>> repositeries be package.el aware.
>>>
>>> From my point of view, the "preferable setup" is for someone to spice up
>>> `elpa-admin.el` to make it more user-friendly for that use-case.
>>
>> I could look into this, because I was intending to work on elpa-admin.el
>> a bit anyway. But this would mean that it wouldn't work OOTB, right?
>
> Not sure what you mean by that, but I'm pretty sure the answer is no.
My suggestion to add something like site-lisp.el to Emacs itself was to
allow anyone to use unpackaged elisp code on their local system, without
having to manually bother with updating load-path and autoloading.
> My suggestion is quite vague, includes things like extracting the
> *ideas* but rewrite them differently or copying the few relevant parts
> of the code, ...
>
>
> Stefan
>
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Easy configuration of a site-lisp directory
@ 2021-08-26 9:42 88% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-08-26 9:42 UTC (permalink / raw)
To: Arthur Miller; +Cc: emacs-devel
Arthur Miller <arthur.miller@live.com> writes:
> I think that something like what you propose is OK for you who are developer and
> know what you do. But if you put something like this on auto in Emacs, I think
> that lots of people with get troubles which can lead to even more frequent mailing
> list :).
I guess this depends on whether or not this would be enabled by default
or not. My suggestion uses ~/.emacs.d/site-lisp by default if it
exists. I get what you mean that this might be an issue, so it something
like this could (and probably should) be disabled by default, but easy
to activate.
>> If there is some critical change or something that isn't ready yet, I'd
>> just use "git stash".
>>
>>> What you are suggesting is to effectively use "site-lisp" as another
>>> package-user-dir (~/.emacs.d/elpa on my machine). You are also auto
>>> recursing in all dirs, so if user wish to remove something they have to
>>> remove that directory from the path?
>>
>> Yes, but I hesitate to compare it to package-user-dir, as to me packages
>> stand in relation to some package manager, while site-lisp.el only
>> implements the bare minimum.
>
> Exactly. I am not sure if it is even the bare miniumum.
>
> Bringing in paths and code in Emacs, is just but one part of package
> management. Installling dependencies and also uninstalling everything correctly,
> not leaving orphaned pacakges behind or removing something still needed is as
> important as well. For that reason I think that going through package.el would
> be a better idea.
I think I agree. package-list-packages already lists different
package states (available, installed, built-in, ...) so it might also
make sense to have a "local" package as well.
> Everyone's setup is of course private, but I don't think that is a
> good idea and good alternative to proper package management. For the same reason
> why we don't install packages manually in our gnu/linux distributions but use
> some sort of package management system. Doing manually ./configure - make dance
> is nowdays considered a bad practice.
I'm not sure, it depends on what you are doing. package managers usually
don't expect the user to change the software that has been
installed. You usually only get a binary version and any modification
will be overridden. If you want to work on some software, and actually
use your software freedom, you have to do the ./configure-make-dance.
> Anyway, I understand your attempt, and I responded, because I was lately
> looking for myself what to do, becuase I also would prefer to have easy hackable
> packages, with same consideration as you said, to have emacs help system and
> xref bring me to correct spot. I am not sure myself what I am gonna use.
--
Philip Kaludercic
^ permalink raw reply [relevance 88%]
* Re: Gitlab Migration
@ 2021-08-26 17:24 80% ` Philip Kaludercic
0 siblings, 2 replies; 200+ results
From: Philip Kaludercic @ 2021-08-26 17:24 UTC (permalink / raw)
To: Daniel Fleischer; +Cc: emacs-devel
Hi,
Daniel Fleischer <danflscr@gmail.com> writes:
> One issue which I think is important is the move to a new VC system,
> e.g. Gitlab. I started reading the relevant threads and I'm not sure
> where the issue stands today. Let me recap the benefits:
>
> 1 The need for new people to join the community and help. Newer
> (younger) people will be more familiar with the newer VC platforms
> (github/lab and similar). These are not only developers but regular
> users who want to report an issue (bug) or suggest a feature.
Shouldn't it be easier to send an email than create an account, navigate
some web UI and fill in some form? The same goes for
patches. Git{Lab,Hub} usually requires leaving the development context,
to prepare a patch online, that requires "forking", more navigation and
more fora. Just today I tried preparing a "pull request" on GitLab and
didn't manage to do so, because it insisted on merging the commit into
my own repository, no matter what I did. Just attaching a git patch
seems much easier.
> Lowering the bar for participation is the key to growing Emacs and
> the community.
I think that showing people that they biases against mailing list
development might be illegitimate would be a viable alternative.
> 2 Having the code + issues + discussions in the same place as opposed
> to now, where the code and discussions (lists) are in 3 different
> places (Savannah, Gnu mailing lists and Gnu bug tracker). With a
> modern VC system, one can jump easily between issues, discussions,
> code commits back and forth easily as opposed to now, where if it's a
> bug you can use its number to search lists and commits messages but
> if it's a discussion, it's not "connected" to anything.
Correct me if I am wrong, but all the discussions are at least mirrored
on the mailing lists. Savannah is just for project management and the
GNU bug tracker uses the mailing list too. It is more uniform too, as
everything is just a mail-message, not part of a forcefully linearized
thread. Commenting on a issue, "pull request" or a patch is always just
responding to a message.
That being said, I wouldn't mind prettier web interface for the mailing
list (I think that the Guix project is doing well on that front).
> Possible issue:
>
> 1 Being able to use Emacs for all these needs. One way is being able to
> interact with the VC system using emails, i.e. issues, features,
> discussions should have a nice and efficient email interface in
> addition to using a website. Another approach is using the wonderful
> Magit and Forge packages. Forge currently is lacking the discussions
> feature but has a very good git + pull-requests + org-mode
> integration abilities.
I remember Sourceforge being suggested as an alternative to Gitlab, but
the software is currently still in a beta stage (AFAIR).
> 2 Changing processes, how people operate. Whether it's the technical
> aspect of a pull-request approval vs. patch submission to the more
> conceptual change of dealing with "issues" representing bugs, ideas,
> feature requests or general discussions instead of mailing lists.
> These changes shouldn't be too disruptive. However I do believe a
> small price has to be paid in order to go from one local minima of
> effort in a given practice to another, hopefully better local minima.
>
> Does this describe well the current situation?
> What areas need attention in order to facilitate the change?
>
> Thanks for any feedback.
>
> Daniel Fleischer
>
--
Philip Kaludercic
^ permalink raw reply [relevance 80%]
* Re: Gitlab Migration
@ 2021-08-26 18:21 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-08-26 18:21 UTC (permalink / raw)
To: Theodor Thornhill; +Cc: Daniel Fleischer, emacs-devel
Theodor Thornhill <theo@thornhill.no> writes:
> On 26 August 2021 19:24:07 CEST, Philip Kaludercic <philipk@posteo.net> wrote:
>>
>>
>>I remember Sourceforge being suggested as an alternative to Gitlab, but
>>the software is currently still in a beta stage (AFAIR).
>>
>
> Do you mean SourceHut or Sourceforge? SourceHut does have an explicit goal to support mailbased workflow, and supports an interface to it as well. It is pretty neat IMO.
Oops, sourcehut of course.
>
> https://sr.ht/
>
> --
> Theodor Thornhill
>
>>>
>>
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Gitlab Migration
@ 2021-08-27 14:50 99% ` Philip Kaludercic
1 sibling, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-08-27 14:50 UTC (permalink / raw)
To: Lars Ingebrigtsen
Cc: Eli Zaretskii, Daniel Fleischer, Stefan Monnier, emacs-devel
Lars Ingebrigtsen <larsi@gnus.org> writes:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> AFAIK SourceHut is the only project which explicitly aims to provide
>> full and convenient support for both web and email control, which makes
>> it the obvious&natural choice for Emacs, IMO.
>
> There doesn't seem to be much movement on getting GitLab to support the
> features we want, so perhaps we should take a closer look at SourceHut
> instead. Has anybody here done an evaluation of SourceHut to see
> whether it'd fit our requirements?
I have seen this thread:
https://lists.sr.ht/~sircmpwn/sr.ht-discuss/%3CC03B4X6WE7XN.9NAXAORGDJ0B%40homura%3E
It is over a year old, so I am not sure if anything has changed.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: NonGNU ELPA work
@ 2021-08-27 15:42 14% ` Philip Kaludercic
2021-09-23 22:51 56% ` Philip Kaludercic
2021-12-09 23:24 36% ` Philip Kaludercic
2 siblings, 2 replies; 200+ results
From: Philip Kaludercic @ 2021-08-27 15:42 UTC (permalink / raw)
To: Adam Tack, emacs-devel; +Cc: Stefan Monnier
[-- Attachment #1: Type: text/plain, Size: 462 bytes --]
Here another batch of packages that could be added. For the most part,
these are major modes, and dependencies. The list partially based on
Bozhidar Batsov prelude configuration[0], but includes other modes too.
As far as I have checked, none of these promote non-free software
(e.g. swift-mode "promotes" Swift, that was initially proprietary, but
has since re-released under the Apache License). Unless I have missed
something all of these build correctly.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-elpa-packages-apache-mode-Add-package.patch --]
[-- Type: text/x-diff, Size: 678 bytes --]
From 0985338f42ce760a80232be5dd77cfa6deb5bf96 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Fri, 27 Aug 2021 15:37:12 +0200
Subject: [PATCH 01/20] * elpa-packages (apache-mode): Add package
---
elpa-packages | 2 ++
1 file changed, 2 insertions(+)
diff --git a/elpa-packages b/elpa-packages
index cdf360838ab..db32d765324 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -9,6 +9,8 @@
;; that can be used in PLIST.
(
+ ("apache-mode" :url "https://github.com/emacs-php/apache-mode")
+
("caml" :url "https://github.com/ocaml/caml-mode"
;; The version 4.7.1 from Melpa-stable seems to correspond to
;; revision a9134009.
--
2.30.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0002-elpa-packages-arduino-mode-Add-package.patch --]
[-- Type: text/x-diff, Size: 748 bytes --]
From cbfc26d262318c7153e90301bdd4427107777015 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Fri, 27 Aug 2021 15:37:40 +0200
Subject: [PATCH 02/20] * elpa-packages (arduino-mode): Add package
---
elpa-packages | 3 +++
1 file changed, 3 insertions(+)
diff --git a/elpa-packages b/elpa-packages
index db32d765324..6358ce8dc36 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -11,6 +11,9 @@
(
("apache-mode" :url "https://github.com/emacs-php/apache-mode")
+ ("arduino-mode" :url "https://github.com/stardiviner/arduino-mode"
+ :ignored-files ("Cask"))
+
("caml" :url "https://github.com/ocaml/caml-mode"
;; The version 4.7.1 from Melpa-stable seems to correspond to
;; revision a9134009.
--
2.30.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #4: 0003-elpa-packages-bison-mode-Add-package.patch --]
[-- Type: text/x-diff, Size: 738 bytes --]
From 162bda32afc30b947e2a4277fde6749f409eb55d Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Fri, 27 Aug 2021 15:37:47 +0200
Subject: [PATCH 03/20] * elpa-packages (bison-mode): Add package
---
elpa-packages | 2 ++
1 file changed, 2 insertions(+)
diff --git a/elpa-packages b/elpa-packages
index 6358ce8dc36..b2e067c6380 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -14,6 +14,8 @@
("arduino-mode" :url "https://github.com/stardiviner/arduino-mode"
:ignored-files ("Cask"))
+ ("bison-mode" :url "https://github.com/Wilfred/bison-mode")
+
("caml" :url "https://github.com/ocaml/caml-mode"
;; The version 4.7.1 from Melpa-stable seems to correspond to
;; revision a9134009.
--
2.30.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #5: 0004-elpa-packages-d-mode-Add-package.patch --]
[-- Type: text/x-diff, Size: 783 bytes --]
From 201ce0f0f937467fbe990d96544f37ce000f4ec2 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Fri, 27 Aug 2021 15:42:36 +0200
Subject: [PATCH 04/20] * elpa-packages (d-mode): Add package
---
elpa-packages | 3 +++
1 file changed, 3 insertions(+)
diff --git a/elpa-packages b/elpa-packages
index b2e067c6380..e8f18dffa6d 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -27,6 +27,9 @@
("crux" :url "https://github.com/bbatsov/crux")
+ ("d-mode" :url "https://github.com/Emacs-D-Mode-Maintainers/Emacs-D-Mode"
+ :ignored-files ("coverage" "tests-todo" "tests" "Cask" "Makefile" "d-mode-tests.el"))
+
("editorconfig" :url "https://github.com/editorconfig/editorconfig-emacs"
:doc "doc/editorconfig.texi"
:news "CHANGELOG.md"
--
2.30.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #6: 0005-elpa-packages-dart-mode-Add-package.patch --]
[-- Type: text/x-diff, Size: 838 bytes --]
From 3c914c27eca2686a978355ce94e2d406724e518e Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Fri, 27 Aug 2021 15:42:45 +0200
Subject: [PATCH 05/20] * elpa-packages (dart-mode): Add package
---
elpa-packages | 3 +++
1 file changed, 3 insertions(+)
diff --git a/elpa-packages b/elpa-packages
index e8f18dffa6d..67f9772c8ce 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -30,6 +30,9 @@
("d-mode" :url "https://github.com/Emacs-D-Mode-Maintainers/Emacs-D-Mode"
:ignored-files ("coverage" "tests-todo" "tests" "Cask" "Makefile" "d-mode-tests.el"))
+ ("dart-mode" :url "https://github.com/bradyt/dart-mode"
+ :ignored-files ("test" "Cask" "Makefile"))
+
("editorconfig" :url "https://github.com/editorconfig/editorconfig-emacs"
:doc "doc/editorconfig.texi"
:news "CHANGELOG.md"
--
2.30.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #7: 0006-elpa-packages-gnuplot-Add-package.patch --]
[-- Type: text/x-diff, Size: 788 bytes --]
From ce69f25bdde851b379f632c33a118c5abcf20659 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Fri, 27 Aug 2021 15:51:44 +0200
Subject: [PATCH 06/20] * elpa-packages (gnuplot): Add package
---
elpa-packages | 3 +++
1 file changed, 3 insertions(+)
diff --git a/elpa-packages b/elpa-packages
index 67f9772c8ce..fae776d4900 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -68,6 +68,9 @@
("geiser-racket" :url "https://gitlab.com/emacs-geiser/racket.git")
("geiser-stklos" :url "https://gitlab.com/emacs-geiser/stklos.git")
+ ("gnuplot" :url "https://github.com/emacsorphanage/gnuplot"
+ :ignored-files ("Makefile" "gpelcard.tex"))
+
("go-mode" :url "https://github.com/dominikh/go-mode.el"
:ignored-files ("generate_authors.sh"))
--
2.30.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #8: 0007-elpa-packages-haml-mode-Add-package.patch --]
[-- Type: text/x-diff, Size: 727 bytes --]
From 254d81d1642b225e61ae6b2c13a7e9b49597ff63 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Fri, 27 Aug 2021 15:56:14 +0200
Subject: [PATCH 07/20] * elpa-packages (haml-mode): Add package
---
elpa-packages | 2 ++
1 file changed, 2 insertions(+)
diff --git a/elpa-packages b/elpa-packages
index fae776d4900..251bf2d5d6b 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -78,6 +78,8 @@
("guru-mode" :url "https://github.com/bbatsov/guru-mode")
+ ("haml-mode" :url "https://github.com/nex3/haml-mode")
+
;; haskell-mode has been removed until further notice from the
;; upstream maintainers:
;; https://github.com/haskell/haskell-mode/issues/1755#issuecomment-896127958
--
2.30.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #9: 0008-elpa-packages-idris-mode-Add-package.patch --]
[-- Type: text/x-diff, Size: 1112 bytes --]
From c5b248411c3081c7f17d4013f9f7e29e0e34fd04 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Fri, 27 Aug 2021 15:56:20 +0200
Subject: [PATCH 08/20] * elpa-packages (idris-mode): Add package
---
elpa-packages | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/elpa-packages b/elpa-packages
index 251bf2d5d6b..84fa4fa34ac 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -101,6 +101,10 @@
:ignored-files ("htmlize.el.html")
:release-branch "stable")
+ ("idris-mode" :url "https://github.com/idris-hackers/idris-mode"
+ :ignored-files ("test-data" "Makefile" "documentation.tex" "logo-small.png"
+ "idris-tests*.el"))
+
("inf-clojure" :url "https://github.com/clojure-emacs/inf-clojure"
:ignored-files ("test")
:news "CHANGELOG.md")
@@ -167,6 +171,9 @@
:news "CHANGES"
:doc "doc/ProofGeneral.texi")
+ ("prop-menu" :url "https://github.com/david-christiansen/prop-menu-el"
+ :ignored-files ("Makefile" "prop-menu-tests.el"))
+
("request" :url "https://github.com/tkf/emacs-request"
:ignored-files ("tests" "doc" "COPYING"))
--
2.30.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #10: 0009-elpa-packages-j-mode-Add-package.patch --]
[-- Type: text/x-diff, Size: 654 bytes --]
From e6f7d540d79a601650c31ac5e0bac499a1013955 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Fri, 27 Aug 2021 15:56:30 +0200
Subject: [PATCH 09/20] * elpa-packages (j-mode): Add package
---
elpa-packages | 2 ++
1 file changed, 2 insertions(+)
diff --git a/elpa-packages b/elpa-packages
index 84fa4fa34ac..be31a9a0b10 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -109,6 +109,8 @@
:ignored-files ("test")
:news "CHANGELOG.md")
+ ("j-mode" :url "https://github.com/zellio/j-mode")
+
("lua-mode" :url "https://github.com/immerrr/lua-mode/"
:ignored-files ("test" "travis" "init-tryout.el"))
--
2.30.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #11: 0010-elpa-packages-julia-mode-Add-package.patch --]
[-- Type: text/x-diff, Size: 737 bytes --]
From 6a172119bba1de6ec8d67b0e071f428f68c2af50 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Fri, 27 Aug 2021 15:59:41 +0200
Subject: [PATCH 10/20] * elpa-packages (julia-mode): Add package
---
elpa-packages | 3 +++
1 file changed, 3 insertions(+)
diff --git a/elpa-packages b/elpa-packages
index be31a9a0b10..a74dd201850 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -111,6 +111,9 @@
("j-mode" :url "https://github.com/zellio/j-mode")
+ ("julia-mode" :url "https://github.com/JuliaEditorSupport/julia-emacs"
+ :ignored-files ("julia-mode-tests.el" "logo.png"))
+
("lua-mode" :url "https://github.com/immerrr/lua-mode/"
:ignored-files ("test" "travis" "init-tryout.el"))
--
2.30.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #12: 0011-elpa-packages-nasm-mode-Add-package.patch --]
[-- Type: text/x-diff, Size: 759 bytes --]
From 6ee18e17e46eaa9550d9998e3d4a817a2e7b4f3c Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Fri, 27 Aug 2021 16:00:26 +0200
Subject: [PATCH 11/20] * elpa-packages (nasm-mode): Add package
---
elpa-packages | 3 +++
1 file changed, 3 insertions(+)
diff --git a/elpa-packages b/elpa-packages
index a74dd201850..b646da81bec 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -164,6 +164,9 @@
("multiple-cursors" :url "https://github.com/magnars/multiple-cursors.el"
:ignored-files ("features"))
+ ("nasm-mode" :url "https://github.com/skeeto/nasm-mode"
+ :ignored-files ("Makefile"))
+
("paredit" :url "https://mumble.net/~campbell/git/paredit.git"
:ignored-files ("check.sh" "genhtml.sh" "test.el"))
--
2.30.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #13: 0012-elpa-packages-nginx-mode-Add-package.patch --]
[-- Type: text/x-diff, Size: 710 bytes --]
From 98cac4b6ce86c5212d740eadd78efa033453cc0a Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Fri, 27 Aug 2021 16:02:42 +0200
Subject: [PATCH 12/20] * elpa-packages (nginx-mode): Add package
---
elpa-packages | 2 ++
1 file changed, 2 insertions(+)
diff --git a/elpa-packages b/elpa-packages
index b646da81bec..18e97de5196 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -167,6 +167,8 @@
("nasm-mode" :url "https://github.com/skeeto/nasm-mode"
:ignored-files ("Makefile"))
+ ("nginx-mode" :url "https://github.com/ajc/nginx-mode")
+
("paredit" :url "https://mumble.net/~campbell/git/paredit.git"
:ignored-files ("check.sh" "genhtml.sh" "test.el"))
--
2.30.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #14: 0013-elpa-packages-php-mode-Add-package.patch --]
[-- Type: text/x-diff, Size: 759 bytes --]
From 89172b5b88ffd6176a97bef06d9778d17f058af5 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Fri, 27 Aug 2021 16:06:27 +0200
Subject: [PATCH 13/20] * elpa-packages (php-mode): Add package
---
elpa-packages | 3 +++
1 file changed, 3 insertions(+)
diff --git a/elpa-packages b/elpa-packages
index 18e97de5196..197e82d942d 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -172,6 +172,9 @@
("paredit" :url "https://mumble.net/~campbell/git/paredit.git"
:ignored-files ("check.sh" "genhtml.sh" "test.el"))
+ ("php-mode" :url "https://github.com/emacs-php/php-mode"
+ :lisp-dir "lisp")
+
("projectile" :url "https://github.com/bbatsov/projectile"
:ignored-files ("doc" "test")
:news "CHANGELOG.md")
--
2.30.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #15: 0014-elpa-packages-sass-mode-Add-package.patch --]
[-- Type: text/x-diff, Size: 629 bytes --]
From 923e977ecb24a5a313f19ebdb7232a72164e93db Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Fri, 27 Aug 2021 16:06:43 +0200
Subject: [PATCH 14/20] * elpa-packages (sass-mode): Add package
---
elpa-packages | 2 ++
1 file changed, 2 insertions(+)
diff --git a/elpa-packages b/elpa-packages
index 197e82d942d..74f43336aff 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -200,6 +200,8 @@
:readme "README.org"
:ignored-files ("README.md"))
+ ("sass-mode" :url "https://github.com/nex3/sass-mode")
+
("slime" :url "https://github.com/slime/slime"
:doc "doc/slime.texi")
--
2.30.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #16: 0015-elpa-packages-scala-mode-Add-package.patch --]
[-- Type: text/x-diff, Size: 691 bytes --]
From 8e4e86550eeca6acfab9e134a9f597c6ea5597d0 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Fri, 27 Aug 2021 16:06:49 +0200
Subject: [PATCH 15/20] * elpa-packages (scala-mode): Add package
---
elpa-packages | 3 +++
1 file changed, 3 insertions(+)
diff --git a/elpa-packages b/elpa-packages
index 74f43336aff..2d0eadc2c6a 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -202,6 +202,9 @@
("sass-mode" :url "https://github.com/nex3/sass-mode")
+ ("scala-mode" :url "https://github.com/hvesalai/emacs-scala-mode"
+ :ignored-files ("test" "Cask" "Makefile"))
+
("slime" :url "https://github.com/slime/slime"
:doc "doc/slime.texi")
--
2.30.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #17: 0016-elpa-packages-scss-mode-Add-package.patch --]
[-- Type: text/x-diff, Size: 689 bytes --]
From d35fbf105169d8c3f489052a82ea066e921d83f0 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Fri, 27 Aug 2021 16:06:56 +0200
Subject: [PATCH 16/20] * elpa-packages (scss-mode): Add package
---
elpa-packages | 2 ++
1 file changed, 2 insertions(+)
diff --git a/elpa-packages b/elpa-packages
index 2d0eadc2c6a..84439b5e479 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -205,6 +205,8 @@
("scala-mode" :url "https://github.com/hvesalai/emacs-scala-mode"
:ignored-files ("test" "Cask" "Makefile"))
+ ("scss-mode" :url "https://github.com/antonj/scss-mode")
+
("slime" :url "https://github.com/slime/slime"
:doc "doc/slime.texi")
--
2.30.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #18: 0017-elpa-packages-swift-mode-Add-package.patch --]
[-- Type: text/x-diff, Size: 817 bytes --]
From cf658c5f508940e0d6c7837ff782260e1413e03c Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Fri, 27 Aug 2021 16:07:04 +0200
Subject: [PATCH 17/20] * elpa-packages (swift-mode): Add package
---
elpa-packages | 3 +++
1 file changed, 3 insertions(+)
diff --git a/elpa-packages b/elpa-packages
index 84439b5e479..6044008d819 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -225,6 +225,9 @@
;; https://github.com/Fuco1/smartparens/releases/tag/1.11.0
:version-map ((nil "1.11.0" "4873352b5d0a1c5142658122de1b6950b8fe7e4d")))
+ ("swift-mode" :url "https://github.com/swift-emacs/swift-mode"
+ :ignored-files ("scripts" "test" "Eldev" "Makefile"))
+
("tuareg" :url "https://github.com/ocaml/tuareg.git")
("web-mode" :url "https://github.com/fxbois/web-mode"
--
2.30.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #19: 0018-elpa-packages-systemd-Add-package.patch --]
[-- Type: text/x-diff, Size: 776 bytes --]
From 95bf58bf45f9beb0e7a28e066be58b22d4d0c82f Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Fri, 27 Aug 2021 16:07:15 +0200
Subject: [PATCH 18/20] * elpa-packages (systemd): Add package
---
elpa-packages | 3 +++
1 file changed, 3 insertions(+)
diff --git a/elpa-packages b/elpa-packages
index 6044008d819..38981e4eca2 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -228,6 +228,9 @@
("swift-mode" :url "https://github.com/swift-emacs/swift-mode"
:ignored-files ("scripts" "test" "Eldev" "Makefile"))
+ ("systemd" :url "https://github.com/holomorph/systemd-mode"
+ :ignored-files ("test" "Makefile"))
+
("tuareg" :url "https://github.com/ocaml/tuareg.git")
("web-mode" :url "https://github.com/fxbois/web-mode"
--
2.30.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #20: 0019-elpa-packages-yaml-mode-Add-package.patch --]
[-- Type: text/x-diff, Size: 738 bytes --]
From aca73ab9ab6179b85a4adebfb6d1de826c97757c Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Fri, 27 Aug 2021 16:07:22 +0200
Subject: [PATCH 19/20] * elpa-packages (yaml-mode): Add package
---
elpa-packages | 3 +++
1 file changed, 3 insertions(+)
diff --git a/elpa-packages b/elpa-packages
index 38981e4eca2..4c7905ce155 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -242,6 +242,9 @@
("wgrep" :url "https://github.com/mhayashi1120/Emacs-wgrep")
+ ("yaml-mode" :url "https://github.com/yoshiki/yaml-mode"
+ :ignored-files ("test-files" "Makefile"))
+
("yasnippet-snippets" :url "https://github.com/AndreaCrotti/yasnippet-snippets"
:ignored-files ("report" "snippets.html"))
--
2.30.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #21: 0020-elpa-packages-zig-mode-Add-package.patch --]
[-- Type: text/x-diff, Size: 688 bytes --]
From 29f28b5de66493b7256b5495b5e72f5aa9a072b1 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Fri, 27 Aug 2021 17:12:08 +0200
Subject: [PATCH 20/20] * elpa-packages (zig-mode): Add package
---
elpa-packages | 3 +++
1 file changed, 3 insertions(+)
diff --git a/elpa-packages b/elpa-packages
index 4c7905ce155..e35cfc2471d 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -248,4 +248,7 @@
("yasnippet-snippets" :url "https://github.com/AndreaCrotti/yasnippet-snippets"
:ignored-files ("report" "snippets.html"))
+ ("zig-mode" :url "https://github.com/ziglang/zig-mode"
+ :ignored-files ("appveyor.yml" "run_tests.sh" "tests.el"))
+
)
--
2.30.2
[-- Attachment #22: Type: text/plain, Size: 147 bytes --]
A few more packages couldn't be added just now or are still pending
upstream input. I have documented the issues in my local file attached
here:
[-- Attachment #23: elpa-packages --]
[-- Type: application/octet-stream, Size: 12869 bytes --]
;; -*- lisp-data -*-
;; List of packages.
;; The list is made of elements of the form (NAME . PLIST)
;; Every package needs a corresponding Git branch in the repository
;; with name `externals/NAME`.
;;
;; See "Specifications" in the admin/README file for the properties
;; that can be used in PLIST.
(
("apache-mode" :url "https://github.com/emacs-php/apache-mode")
("arduino-mode" :url "https://github.com/stardiviner/arduino-mode"
:ignored-files ("Cask"))
("bison-mode" :url "https://github.com/Wilfred/bison-mode")
("caml" :url "https://github.com/ocaml/caml-mode"
;; The version 4.7.1 from Melpa-stable seems to correspond to
;; revision a9134009.
:version-map ((nil "4.7.1" "a9134009bd037a39cbda21806867d0534d340bca")))
("clojure-mode" :url "https://github.com/clojure-emacs/clojure-mode"
:ignored-files ("clojure-mode-extra-font-locking.el" "doc" "test" "test.clj")
:news "CHANGELOG.md")
("crux" :url "https://github.com/bbatsov/crux")
("d-mode" :url "https://github.com/Emacs-D-Mode-Maintainers/Emacs-D-Mode"
:ignored-files ("coverage" "tests-todo" "tests" "Cask" "Makefile" "d-mode-tests.el"))
("dart-mode" :url "https://github.com/bradyt/dart-mode"
:ignored-files ("test" "Cask" "Makefile"))
;; FIXME This package lacks a version tag
;; ("dockerfile-mode" :url "https://github.com/spotify/dockerfile-mode")
("editorconfig" :url "https://github.com/editorconfig/editorconfig-emacs"
:doc "doc/editorconfig.texi"
:news "CHANGELOG.md"
:ignored-files ("bin" "ert-tests"))
;; FIXME Waiting for pkg-info dependency to be dropped:
;; https://github.com/elixir-editors/emacs-elixir/pull/482
;;
;; ("emacs-elixir" :url "https://github.com/elixir-editors/emacs-elixir"
;; :ignored-files ("tests" "Eldev"))
;; FIXME remove dependencies: s.el, f.el
;; ("elm-mode" :url "https://github.com/jcollard/elm-mode"
;; :ignored-files ("elm.tags" "Makefile"))
("evil" :url "https://github.com/emacs-evil/evil"
:ignored-files ("lib" "scripts")
:doc "doc/build/texinfo/evil.texi")
("git-commit" :url "https://github.com/magit/magit"
:lisp-dir "lisp"
:ignored-files
(".dir-locals.el" ".github" ".mailmap"
"Documentation" "Makefile" "default.mk" "lisp/Makefile" "lisp/*-pkg.el" "t"
"README.md" "RelNotes.org"
"lisp/git-rebase.el" "lisp/magit-*.el" "lisp/magit.el"))
("geiser" :url "https://gitlab.com/emacs-geiser/geiser.git"
:lisp-dir "elisp"
:readme "readme.org"
:doc "doc/geiser.texi")
("geiser-chez" :url "https://gitlab.com/emacs-geiser/chez.git")
("geiser-chibi" :url "https://gitlab.com/emacs-geiser/chibi.git")
("geiser-chicken" :url "https://gitlab.com/emacs-geiser/chicken.git")
("geiser-gambit" :url "https://gitlab.com/emacs-geiser/gambit.git")
("geiser-gauche" :url "https://gitlab.com/emacs-geiser/gauche.git")
("geiser-guile" :url "https://gitlab.com/emacs-geiser/guile.git")
("geiser-kawa" :url "https://gitlab.com/emacs-geiser/kawa.git"
:lisp-dir "elisp"
:ignored-files ("elisp/tests"))
("geiser-mit" :url "https://gitlab.com/emacs-geiser/mit.git")
("geiser-racket" :url "https://gitlab.com/emacs-geiser/racket.git")
("geiser-stklos" :url "https://gitlab.com/emacs-geiser/stklos.git")
;; FIXME This package lacks a version tag
("git-modes" :url "https://github.com/magit/git-modes"
:ignored-files ("Makefile"))
;; FIXME This package (apparently?) lacks a version tag
;; ("gnu-apl-mode" :url "https://github.com/lokedhs/gnu-apl-mode"
;; :doc "texi/gnu-apl-mode.texi")
("gnuplot" :url "https://github.com/emacsorphanage/gnuplot"
:ignored-files ("Makefile" "gpelcard.tex"))
("go-mode" :url "https://github.com/dominikh/go-mode.el"
:ignored-files ("generate_authors.sh"))
("goto-chg" :url "https://github.com/emacs-evil/goto-chg")
;; FIXME This package lacks a version tag
;; ("graphql-mode" :url "https://github.com/davazp/graphql-mode"
;; :ignored-files ("test"))
("guru-mode" :url "https://github.com/bbatsov/guru-mode")
("haml-mode" :url "https://github.com/nex3/haml-mode")
;; haskell-mode has been removed until further notice from the
;; upstream maintainers:
;; https://github.com/haskell/haskell-mode/issues/1755#issuecomment-896127958
;;
;; ("haskell-mode" :url "https://github.com/haskell/haskell-mode"
;; :doc "doc/haskell-mode.texi"
;; :ignored-files ("images" "test" "logo.svg")
;; ;; Until a version tag is added, the commit of the latest tag is
;; ;; used to determine the last stable release:
;; ;; https://github.com/haskell/haskell-mode/releases/tag/17.2
;; :version-map ((nil "17.2" "e72677668f5fc7cc148008e885a0f256e245dd43")))
("highlight-parentheses"
:url "https://git.sr.ht/~tsdh/highlight-parentheses.el"
:branch "main"
:readme "README.md")
("htmlize" :url "https://github.com/hniksic/emacs-htmlize"
:ignored-files ("htmlize.el.html")
:release-branch "stable")
("idris-mode" :url "https://github.com/idris-hackers/idris-mode"
:ignored-files ("test-data" "Makefile" "documentation.tex" "logo-small.png"
"idris-tests*.el"))
("inf-clojure" :url "https://github.com/clojure-emacs/inf-clojure"
:ignored-files ("test")
:news "CHANGELOG.md")
;; FIXME This package lacks a version tag and a commentary section
;; ("jade-mode" :url "https://github.com/brianc/jade-mode"
;; :ignored-files ("test" "Cask" "Makefile" "example.jade" "example.json"
;; "stylus-mode.el" "sws-mode.el"))
("j-mode" :url "https://github.com/zellio/j-mode")
("julia-mode" :url "https://github.com/JuliaEditorSupport/julia-emacs"
:ignored-files ("julia-mode-tests.el" "logo.png"))
("lua-mode" :url "https://github.com/immerrr/lua-mode/"
:ignored-files ("test" "travis" "init-tryout.el"))
;; FIXME This package lacks a version tag
;; ("kotlin-mode" :url "https://github.com/Emacs-Kotlin-Mode-Maintainers/kotlin-mode"
;; :ignored-files ("doc" "test" "Cask" "Makefile"))
("magit" :url "https://github.com/magit/magit"
:lisp-dir "lisp"
:doc "Documentation/magit.texi"
:renames (("Documenation/" ""))
:ignored-files
(".dir-locals.el" ".github" ".mailmap"
"Documentation" "Makefile" "default.mk" "lisp/Makefile" "lisp/*-pkg.el" "t"
"lisp/git-commit.el" "lisp/magit-libgit.el" "lisp/magit-section.el"))
("magit-section" :url "https://github.com/magit/magit"
:lisp-dir "lisp"
:doc "Documentation/magit-section.texi"
:renames (("Documenation/" ""))
:ignored-files
(".dir-locals.el" ".github" ".mailmap"
"Documentation" "Makefile" "default.mk" "lisp/Makefile" "lisp/*-pkg.el" "t"
"README.md" "RelNotes.org"
"lisp/git-commit.el" "lisp/git-rebase.el" "lisp/magit-apply.el"
"lisp/magit-autoloads.el" "lisp/magit-autorevert.el" "lisp/magit-bisect.el"
"lisp/magit-blame.el" "lisp/magit-bookmark.el" "lisp/magit-branch.el"
"lisp/magit-bundle.el"
"lisp/magit-clone.el" "lisp/magit-commit.el" "lisp/magit-core.el"
"lisp/magit-diff.el" "lisp/magit-ediff.el" "lisp/magit.el"
"lisp/magit-extras.el" "lisp/magit-fetch.el" "lisp/magit-files.el"
"lisp/magit-git.el" "lisp/magit-gitignore.el" "lisp/magit-imenu.el"
"lisp/magit-libgit.el" "lisp/magit-log.el" "lisp/magit-margin.el"
"lisp/magit-merge.el" "lisp/magit-mode.el" "lisp/magit-notes.el"
"lisp/magit-obsolete.el" "lisp/magit-patch.el" "lisp/magit-process.el"
"lisp/magit-pull.el" "lisp/magit-push.el" "lisp/magit-reflog.el"
"lisp/magit-refs.el" "lisp/magit-remote.el" "lisp/magit-repos.el"
"lisp/magit-reset.el" "lisp/magit-sequence.el" "lisp/magit-stash.el"
"lisp/magit-status.el" "lisp/magit-submodule.el" "lisp/magit-subtree.el"
"lisp/magit-tag.el" "lisp/magit-transient.el" "lisp/magit-utils.el"
"lisp/magit-wip.el" "lisp/magit-worktree.el"))
("macrostep" :url "https://github.com/joddie/macrostep"
:ignored-files ("lib" "macrostep-test.el"))
("markdown-mode" :url "https://github.com/jrblevin/markdown-mode"
:readme "README.md"
;; Not needed any more:
;; :dont-release "-dev\\'"
)
("multiple-cursors" :url "https://github.com/magnars/multiple-cursors.el"
:ignored-files ("features"))
("nasm-mode" :url "https://github.com/skeeto/nasm-mode"
:ignored-files ("Makefile"))
;; FIXME Add package as soon as a release it made without depending on f:
;; https://github.com/NixOS/nix-mode/pull/138
;;
;; ("nix-mode" :url "https://github.com/NixOS/nix-mode"
;; :ignored-files ("tests" "Cask" "Makefile" "defaut.nix" "flake.lock" "flake.nix"))
("nginx-mode" :url "https://github.com/ajc/nginx-mode")
;; FIXME Remove or evaluate dependencies epc, commenter, flycheck-nimsuggest
;; ("nim-mode" :url "https://github.com/nim-lang/nim-mode"
;; :ignored-files ("tests" "Cask" "Makefile" "starterKit.nims"))
("paredit" :url "https://mumble.net/~campbell/git/paredit.git"
:ignored-files ("check.sh" "genhtml.sh" "test.el"))
("php-mode" :url "https://github.com/emacs-php/php-mode"
:lisp-dir "lisp")
("projectile" :url "https://github.com/bbatsov/projectile"
:ignored-files ("doc" "test")
:news "CHANGELOG.md")
("proof-general" :url "https://github.com/ProofGeneral/PG"
:ignored-files ("ci")
:news "CHANGES"
:doc "doc/ProofGeneral.texi")
("prop-menu" :url "https://github.com/david-christiansen/prop-menu-el"
:ignored-files ("Makefile" "prop-menu-tests.el"))
;; FIXME Waiting for pkg-info dependency to be removed:
;; https://github.com/Raku/raku-mode/pull/53
;;
;; ("raku-mode" :url "https://github.com/Raku/raku-mode"
;; :ignored-files ("test" "Cask" "Makefile"))
("request" :url "https://github.com/tkf/emacs-request"
:ignored-files ("tests" "doc" "COPYING"))
("rubocop" :url "https://github.com/rubocop/rubocop-emacs")
("rust-mode" :url "https://github.com/rust-lang/rust-mode"
:ignored-files ("test-*" "triagebot.toml" "*.sh"))
;; FIXME This package lacks a version tag
("typescript-mode" :url "https://github.com/emacs-typescript/typescript.el"
:ignored-files ("*test*" "Cask" "Dockerfile" "Makefile"))
("org-contrib" :url "https://git.sr.ht/~bzg/org-contrib"
:lisp-dir "lisp"
:readme "README.org"
:ignored-files ("README.md"))
("sass-mode" :url "https://github.com/nex3/sass-mode")
("scala-mode" :url "https://github.com/hvesalai/emacs-scala-mode"
:ignored-files ("test" "Cask" "Makefile"))
("scss-mode" :url "https://github.com/antonj/scss-mode")
("slime" :url "https://github.com/slime/slime"
:doc "doc/slime.texi")
("sly" :url "https://github.com/joaotavora/sly"
:texinfo "doc/sly.texi"
;; Not needed any more:
;; :version-map (("1.0.0-beta-3" "1.0.0beta3"))
)
("smartparens" :url "https://github.com/Fuco1/smartparens"
:ignored-files ("dev" "doc" "images" "test")
;; See https://github.com/Fuco1/smartparens/issues/1095
;;
;; Until a version tag is added, the commit of the latest tag is
;; used to mark the last stable release:
;; https://github.com/Fuco1/smartparens/releases/tag/1.11.0
:version-map ((nil "1.11.0" "4873352b5d0a1c5142658122de1b6950b8fe7e4d")))
;; FIXME This package lacks a version tag and a commentary section
;; ("stylus-mode" :url "https://github.com/brianc/jade-mode"
;; :ignored-files ("test" "Cask" "Makefile" "example.jade" "example.json"
;; "jade-mode.el" "sws-mode.el"))
("swift-mode" :url "https://github.com/swift-emacs/swift-mode"
:ignored-files ("scripts" "test" "Eldev" "Makefile"))
;; FIXME This package lacks a version tag and a commentary section
;; ("sws-mode" :url "https://github.com/brianc/jade-mode"
;; :ignored-files ("test" "Cask" "Makefile" "example.jade" "example.json"
;; "jade-mode.el" "stylus-mode.el"))
;; FIXME This package lacks a version tag and a commentary section
;; ("textile-mode" :url "https://github.com/juba/textile-mode")
("systemd" :url "https://github.com/holomorph/systemd-mode"
:ignored-files ("test" "Makefile"))
("tuareg" :url "https://github.com/ocaml/tuareg.git")
("web-mode" :url "https://github.com/fxbois/web-mode"
:ignored-files ("issues" "tests" "run.sh"))
("with-editor" :url "https://github.com/magit/with-editor"
:ignored-files ("htmlxref.cnf" ".travis.yml" ".mailmap" "Makefile")
:doc "with-editor.texi")
("wgrep" :url "https://github.com/mhayashi1120/Emacs-wgrep")
("yaml-mode" :url "https://github.com/yoshiki/yaml-mode"
:ignored-files ("test-files" "Makefile"))
("yasnippet-snippets" :url "https://github.com/AndreaCrotti/yasnippet-snippets"
:ignored-files ("report" "snippets.html"))
("zig-mode" :url "https://github.com/ziglang/zig-mode"
:ignored-files ("appveyor.yml" "run_tests.sh" "tests.el"))
)
;; The following packages are part of a monorepo, and can currently
;; not be added directly:
;;
;; - https://github.com/cython/cython/blob/master/Tools/cython-mode.el
;; - https://gitlab.kitware.com/cmake/cmake/-/blob/master/Auxiliary/cmake-mode.el
;; - https://github.com/protocolbuffers/protobuf/blob/master/editors/protobuf-mode.el
[-- Attachment #24: Type: text/plain, Size: 169 bytes --]
[0] https://github.com/bbatsov/prelude/blob/master/core/prelude-packages.el#L143
[1] https://en.wikipedia.org/wiki/Swift_(programming_language)
--
Philip Kaludercic
^ permalink raw reply related [relevance 14%]
* Re: Gitlab Migration
@ 2021-08-27 20:58 67% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-08-27 20:58 UTC (permalink / raw)
To: Eli Zaretskii
Cc: danflscr, Theodor Thornhill, emacs-devel, monnier, larsi, sir
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Theodor Thornhill <theo@thornhill.no>
>> Cc: emacs-devel@gnu.org, larsi@gnus.org, monnier@iro.umontreal.ca,
>> danflscr@gmail.com, philipk@posteo.net, sir@cmpwn.com
>> Date: Fri, 27 Aug 2021 21:38:43 +0200
>>
>> >> https://lists.gnu.org/archive/html/emacs-devel/2020-09/msg00534.html
>> >
>> > That was almost a year ago, and the discussion is thin on actual
>> > details. Support for email-based workflow is a good start, and is one
>> > of the main requirements, but what about the GitLab/Github-like
>> > features? if they are missing or incomplete, we will be trading
>> > debbugs for something that is basically the same beast in a different
>> > wrapping. And what about the other requirements we collected and
>> > documented in the GitLab issue about this?
>> >
>>
>> It seems like Sourcehut supports everything requested, but I might be
>> missing something, of course. In particular the CI is very nice and
>> simple, at least for the hosted version at https://sr.ht. It also
>> supports running without javascript at all, so the libreJS debate should
>> be settled right there. Instead of me speaking on sourcehuts behalf,
>> with which I have no affiliation outside of being a happy customer
>> myself, I'll ping the creator.
>
> Would it be possible to have a more detailed review, like short
> description of what is available for each of the requirements in the
> GitLab issue? That should give us a good idea of how close we are to
> the goal.
Here is my take:
+ Email workflow
Is supported as a first-class interaction method
+ Reduce email noise
The mailing lists are just mailing lists, from
what I know the only "spam" might be CI responding with the results of
a test
+ Submitting patches by email
Is supported as part of the email workflow
+ Offline review
Same as above
+ Reviewing patches by email
Ditto, and the comments are rendered properly in the web UI.
* Merge request creation
Not sure if this is applicable, you'd usually just send a patch and
not create a format "merge request".
* Code should be accompanied by documentation
Here too I cannot say for sure, but I can imagine integrating checkdoc
into a CI that automatically warns a patch-submitter if something
isn't documented properly.
* Formatting code commits
Same as above.
* Traceability of Merge Requests
Again, merge requests are not formal but just a message on the mailing
list, usually generated by git send-email. (There might be an issue
here if users just attach patches as they do now.)
+ Continuous integration
Is given
? Closely integrated bugtracker
I haven't used "todo" (the issue tracker,
https://man.sr.ht/todo.sr.ht/) enough to really comment on this. My
general understanding is that this, integration between the different
components, is one of the things that remain in need of improvement
before the project leaves the beta stage
* Spell & grammar checking
Again, could be done with CIs. Assuming one has a grammar checker.
- Branch rules
I don't know of any mechanism to limit access to branches.
* Copyright assignments
CI should be able to handle this.
+ Licensing
Yes!
- Integration with savannah
Is not implemented, but the question is if the existing infrastructure
should be extended or replaced.
- Integration with debbugs
Same as above.
- Emacs frontend for bug tracker
There is no package for sourcehut comparable to debbugs, but it
shouldn't be hard to implement considering that.
+ Bug reporting
The mailing list should be able to handle bugs M-x report-emacs-bug.
> I tried to find answers to those questions myself, but there doesn't
> seem to be any detailed documentation that describes the setup and
> usage from the routine user POV (or maybe I missed it?). I did find a
> heads-up that "from the beta onwards, unpaid accounts will be limited
> to read-only access to their own projects", so I wonder what that
> means for us. It also says that "web-based workflow for submitting
> and reviewing patches" is still under development.
It shouldn't mean anything, if GNU decides to host their own
instance. Otherwise, every project member would have to play to have an
account, but I assume mailing list contributors could continue accessing
the mailing list without any issue.
--
Philip Kaludercic
^ permalink raw reply [relevance 67%]
* Re: NonGNU ELPA work
@ 2021-08-27 22:04 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-08-27 22:04 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> Here another batch of packages that could be added. For the most part,
>> these are major modes, and dependencies. The list partially based on
>> Bozhidar Batsov prelude configuration[0], but includes other modes too.
>
> I haven't looked yet at your list, really, but I happened to notice
> `scss-mode` in there which seems to conflict with the builtin
> `scss-mode`, so I think it should first be updated so as not to conflict
> with it (or better yet, to integrate the two).
I did not know about it, but from a quick glance I don't think that
the scss-mode package provides anything more than the scss-mode bundled
in Emacs. So that package should probably be ignored.
> Stefan
>
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Adding major or popular language modes to Emacs distribution
@ 2021-08-27 23:12 93% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-08-27 23:12 UTC (permalink / raw)
To: Yuchen Pei; +Cc: Emacs Devel mailing list
Yuchen Pei <hi@ypei.me> writes:
> Hello,
>
> I notice some glaring omissions of modes supporting major / popular
> languages like php, haskell and wikitext in Emacs, though there are
> widely used versions available externally as packages.
See the thread "Re: NonGNU ELPA work" from today: I submitted patches
for NonGNU ELPA, the repository that has been enabled for Emacs 28+,
adding new major modes, so that they can be installed without any
further configuration.
> I feel it is important that Emacs support these languages natively.
Why natively? With packages like gnu-elpa, the user can be notified when
a major mode exists for a file they have opened. The advantage is that
bug-fixes and improvements are not tied to Emacs releases but can happen
concurrently. The disadvantage is that it requires an internet
connection.
> What is the process of adding these modes? My understanding is:
>
> 1. Ask the maintainer of a mode to contribute the mode to Emacs.
And any significant contributor have to sign the FSF copyright
agreement.
> 2. If for some reason the maintainer is unable or unwilling to add the
> mode, someone writes the mode and contribute to Emacs.
>
> In step 2, is it conventional to add the mode to GNU ELPA first,
> before moving it into Emacs itself?
>
> I am asking because I am interested in working on some of these modes.
--
Philip Kaludercic
^ permalink raw reply [relevance 93%]
* Re: Collaborative editing.
@ 2021-08-28 11:40 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-08-28 11:40 UTC (permalink / raw)
To: Qiantan Hong; +Cc: Ergus, Perry E. Metzger, Jean Louis, emacs-devel@gnu.org
Qiantan Hong <qhong@alum.mit.edu> writes:
> I'm happy to release crdt.el into either ELPA, or into mainstream Emacs
> (maybe after it's battle tested on ELPA first)!
I think adding it to ELPA first would be preferable. Just note that you
would have to update the copyright notice before it could be added, and
I think incrementing the version from 0.0.0 would be nice too.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Gitlab Migration
@ 2021-08-28 11:43 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-08-28 11:43 UTC (permalink / raw)
To: Daniel Fleischer
Cc: Eli Zaretskii, emacs-devel, Theodor Thornhill, monnier, dgutov
Daniel Fleischer <danflscr@gmail.com> writes:
> 1. Code exploration; view code with syntax highlighting for most file
> types. Being able to jump to function definitions and usages (at least
> in github). Many people explore code in the web before possibly cloning
> it locally so it's an important QOL feature.
I think this is supported in principle, one would have to see what is
necessary for this to work with Elisp too.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Collaborative editing.
@ 2021-08-28 12:14 93% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-08-28 12:14 UTC (permalink / raw)
To: Qiantan Hong
Cc: Qiantan Hong, Ergus, perry@piermont.com, Jean Louis,
emacs-devel@gnu.org
[-- Attachment #1: Type: text/plain, Size: 216 bytes --]
Qiantan Hong <qhong@mit.edu> writes:
> Sounds good, I’ve updated the copyright notice and assigned version number 0.1.0
Yep, I managed to build the package now, using the following package
specification:
[-- Attachment #2: Type: text/plain, Size: 551 bytes --]
diff --git a/elpa-packages b/elpa-packages
index 8eab656624..576c96e704 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -105,6 +105,7 @@
("counsel" :url "https://github.com/abo-abo/swiper")
("cpio-mode" :url "https://github.com/dlewan/cpio-mode")
("crisp" :url nil)
+ ("crdt" :url "https://code.librehq.com/qhong/crdt.el")
;; ("crossword" :url "https://github.com/Boruch-Baum/emacs-crossword")
;; ("csharp-mode" :url "https://github.com/emacs-csharp/csharp-mode")
("csharp-mode" :url "https://github.com/emacs-csharp/csharp-mode"
[-- Attachment #3: Type: text/plain, Size: 24 bytes --]
--
Philip Kaludercic
^ permalink raw reply related [relevance 93%]
* Re: Gitlab Migration
@ 2021-08-28 12:25 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-08-28 12:25 UTC (permalink / raw)
To: Theodor Thornhill
Cc: Eli Zaretskii, emacs-devel, Daniel Fleischer, monnier, dgutov
Theodor Thornhill <theo@thornhill.no> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Daniel Fleischer <danflscr@gmail.com> writes:
>>
>>> 1. Code exploration; view code with syntax highlighting for most file
>>> types. Being able to jump to function definitions and usages (at least
>>> in github). Many people explore code in the web before possibly cloning
>>> it locally so it's an important QOL feature.
>>
>> I think this is supported in principle, one would have to see what is
>> necessary for this to work with Elisp too.
>>
>
>
> You can absolutely read the repo, but the newish feature of github where
> some languages are backed by lsp is most likely not on the roadmap
I had to look it up, what I was referring to was this:
https://drewdevault.com/2019/07/08/Announcing-annotations-for-sourcehut.html
Yet when trying out the examples given at the end of this article, it
seems the feature isn't working/has been removed?
> --
> Theo
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Adding major or popular language modes to Emacs distribution
@ 2021-08-28 13:45 83% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-08-28 13:45 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: hi, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Date: Fri, 27 Aug 2021 23:12:41 +0000
>> Cc: Emacs Devel mailing list <emacs-devel@gnu.org>
>>
>> > I notice some glaring omissions of modes supporting major / popular
>> > languages like php, haskell and wikitext in Emacs, though there are
>> > widely used versions available externally as packages.
>>
>> See the thread "Re: NonGNU ELPA work" from today: I submitted patches
>> for NonGNU ELPA, the repository that has been enabled for Emacs 28+,
>> adding new major modes, so that they can be installed without any
>> further configuration.
>
> That's not the same as having these come with Emacs in the first
> place.
Of course, I agree that it is preferable, but how realistic is it
currently. While reviewing a lot of popular packages (php-mode,
haskell-mode, ...) it seems improbable to gather all the copyright
assignments even necessary to transfer the code into ELPA.
Another issue that already exists with major modes included in Emacs is
that they often differ in insignificant but annoying ways. When
comparing the binding C-c C-c in python-mode, scheme-mode and
prolog-mode, one respectively finds a send-buffer, compile-defun command
and a keymap. I can only imagine that with more and more languages in
Emacs itself, this issue would get worse (this of course isn't solved by
distributing the code in ELPA, but one would imagine that core-code
should be a bit more consistent). It might make sense to extend
prog-mode by additional generic modes like compiled-prog-mode,
interpreted-prog-mode, interactive-prog-mode, etc. to make it easier to
define and customize language modes.
>> > I feel it is important that Emacs support these languages natively.
>>
>> Why natively? With packages like gnu-elpa, the user can be notified when
>> a major mode exists for a file they have opened. The advantage is that
>> bug-fixes and improvements are not tied to Emacs releases but can happen
>> concurrently. The disadvantage is that it requires an internet
>> connection.
>
> It sounds like your vision of the role of the ELPA repositories vs
> what comes bundled with Emacs is different from the current project's
> vision. In which case it would help if in the future you mentioned
> that you don't speak for the project, to make that clear to people who
> don't necessarily know who is who in the project.
Sincerely sorry about that! I'll keep that in mind and try to avoid
confusion between my hopes and the actual project line.
--
Philip Kaludercic
^ permalink raw reply [relevance 83%]
* Re: Adding major or popular language modes to Emacs distribution
@ 2021-08-28 14:30 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-08-28 14:30 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: hi, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> Another issue that already exists with major modes included in Emacs is
>> that they often differ in insignificant but annoying ways. When
>> comparing the binding C-c C-c in python-mode, scheme-mode and
>> prolog-mode, one respectively finds a send-buffer, compile-defun command
>> and a keymap. I can only imagine that with more and more languages in
>> Emacs itself, this issue would get worse (this of course isn't solved by
>> distributing the code in ELPA, but one would imagine that core-code
>> should be a bit more consistent). It might make sense to extend
>> prog-mode by additional generic modes like compiled-prog-mode,
>> interpreted-prog-mode, interactive-prog-mode, etc. to make it easier to
>> define and customize language modes.
>
> We should definitely make the PL modes more consistent wrt the basic
> key bindings. But having sch packages in ELPA doesn't help solving
> this problem, because it's an orthogonal issue, right?
Yes, I was jut mentioning that if there ever were a push to include more
major modes in Emacs, that something like this might be worth
considering.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Adding major or popular language modes to Emacs distribution
@ 2021-08-28 15:32 73% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-08-28 15:32 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: hi, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: hi@ypei.me, emacs-devel@gnu.org
>> Date: Sat, 28 Aug 2021 14:30:16 +0000
>>
>> > We should definitely make the PL modes more consistent wrt the basic
>> > key bindings. But having sch packages in ELPA doesn't help solving
>> > this problem, because it's an orthogonal issue, right?
>>
>> Yes, I was jut mentioning that if there ever were a push to include more
>> major modes in Emacs, that something like this might be worth
>> considering.
>
> To clarify, I was only talking about programming languages that are
> very popular -- I think Emacs should offer those OOTB. I didn't mean
> we should necessarily have in core every possible language under the
> sun. We could discuss the less popular ones on a case by case basis.
Out of curiosity, I checked [0] to see what the languages are said to be
popular:
| Language | Status |
|----------------------+---------------------------------------|
| C | Built-In |
| Python | Built-In |
| Java | Built-In |
| C++ | Built-In |
| C# | ELPA |
| Visual Basic | Not packaged, just EmacsWiki[1] |
| JavaScript | Built-In and ELPA (js2-mode) |
| PHP | MELPA, NonGNU proposed |
| Assembly | Built-In |
| SQL | Built-In |
| Groovy | MELPA |
| Classical VB | Couldn't find anything |
| Fortran | Built-In |
| R | MELPA (via ess) |
| Ruby | Built-In |
| Swift | MELPA, NonGNU proposed |
| MATLAB | MELPA |
| Go | NonGNU |
| Prolog | Built-In |
| Perl | Built-In |
| SAS | MELPA (via ess) |
| Delphi/Object Pascal | Just GitHub[2] |
| Objective C | Built-In |
| Rust | NonGNU |
| Scratch | Not applicable (graphical) |
| Julia | MELPA, NonGNU proposed |
| Ada | Built-In and ELPA |
| Lisp | Built-In |
| Dart | MELPA, NonGNU proposed |
| PL/SQL | Built-In (part of sql-mode) |
| (Visual) FoxPro | Nothing I could find |
| Scala | MELPA, NonGNU Proposed |
| ABAP | Just GitHub[3] |
| COBOL | ELPA |
| Logo | Mentioned on EmacsWiki[4] |
| F# | MELPA |
| Kotlin | MELPA, NonGNU proposed |
| Transact-SQL | Unsure if this is part of sql-mode |
| Lua | NonGNU |
| Ladder Logic | Nothing or not applicable (graphical) |
| VBScript | Unsure how VBScript relates to VB |
| D | MELPA, NonGNU proposed |
| Clojure | NonGNU |
| LabVIEW | Not applicable (graphical) |
| Nim | MELPA, NonGNU proposed |
| VHDL | Built-In |
| Apex | GitHub[5] |
| TypeScript | MELPA, NonGNU proposed |
| Bash | Built-In |
There are more, but I am not sure how productive it is to continue. What
I probably missing more urgently is full compatibility, especially with
complex languages like C++, or languages embedded in one another as web
developers often work with.
[0] https://www.tiobe.com/tiobe-index/
[1] https://www.emacswiki.org/emacs/VisualBasicMode
[2] https://github.com/ki11men0w/emacs-delphi-mode
[3] https://github.com/hugo-dc/abap-mode
[4] https://www.emacswiki.org/emacs/LogoMode
[5] https://github.com/ctomo/apex-mode
--
Philip Kaludercic
^ permalink raw reply [relevance 73%]
* Re: Update of ELPA package guess-language
@ 2021-08-29 10:58 97% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-08-29 10:58 UTC (permalink / raw)
To: Richard Stallman; +Cc: Bozhidar Batsov, 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. ]]]
>
> > Seems like a prudent idea to me. I was surprised to learn that GNU
> ELPA and NonGNU ELPA behave differently in this regard. Perhaps
> there's some concern that changes that are not properly copyrighted
> might make their way into GNU ELPA?
>
> It is that, but more than that. The developers of some NonGNU ELPA
> packages have not (as far as I know) made any arrangements with us.
> They never engaged to maintain the code in accord with the rules of
> NonGNU ELPA, so we can't presume that they are doing so. We can only
> look at their changes and then decide what to do.
To be fair, I have notified every package maintainer that has been added
to NonGNU ELPA, to inform them of how (NonGNU) ELPA works, what they
should remember if they are interested in being part of the repository.
Sadly a few have not responded yet, mostly because the projects are
quasi dead, others have asked to be removed temporarily, but most have
responded positively and are interested in cooperating.
--
Philip Kaludercic
^ permalink raw reply [relevance 97%]
* Re: NonGNU ELPA work
@ 2021-08-29 14:36 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-08-29 14:36 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> I did not know about it, but from a quick glance I don't think that
>> the scss-mode package provides anything more than the scss-mode bundled
>> in Emacs.
>
> I saw some flymake support and there might be other things.
>
>> So that package should probably be ignored.
>
> OK. Feel free to prod the author into submitting patches to integrate
> his code into Emacs ;-)
I have looked into this, and it seems that the package only provides a
legacy back-end, so it would have to be rewritten anyway.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: NonGNU ELPA work
@ 2021-08-29 15:59 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-08-29 15:59 UTC (permalink / raw)
To: Bozhidar Batsov; +Cc: Emacs Devel
"Bozhidar Batsov" <bozhidar@batsov.dev> writes:
> Great work, Philip!
Thank you!
> I did notice that some packages (e.g. julia-mode) have changelogs that
> should probably be mentioned (e.g. julia-emacs/CHANGELOG.md at master
> · JuliaEditorSupport/julia-emacs (github.com)
> <https://github.com/JuliaEditorSupport/julia-emacs/blob/master/CHANGELOG.md>). It's
> useful to be able to lookup changelogs quickly.
You are right, I'll go over all the packages once more and check if
NEWS/CHANGELOG files can be added.
> I've also noticed you added haml-mode, but not slim-mode (and I think
> the second is more popular with Rails these days).
To be perfectly honest, I must have just missed it. It seems to build
without any issues, so it should be add'able.
> Adding web-mode will be a good idea as well (it supports many
> templating languages).
That has actually already been added: http://elpa.nongnu.org/nongnu/web-mode.html
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Update of ELPA package guess-language
@ 2021-08-30 15:20 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-08-30 15:20 UTC (permalink / raw)
To: Richard Stallman; +Cc: bozhidar, 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 is that, but more than that. The developers of some NonGNU ELPA
> > > packages have not (as far as I know) made any arrangements with us.
> > > They never engaged to maintain the code in accord with the rules of
> > > NonGNU ELPA, so we can't presume that they are doing so. We can only
> > > look at their changes and then decide what to do.
>
> > To be fair, I have notified every package maintainer that has been added
> > to NonGNU ELPA, to inform them of how (NonGNU) ELPA works, what they
> > should remember if they are interested in being part of the repository.
>
> I am concerned there may have been a misunderstanding here.
>
> We specifically did not want to insist that every package's developer
> agree to follow NonGNU ELPA rules. Our plan was to have two ways of
> handling a package in NonGNU ELPA:
>
> 1. The developers would undertake to follow the NonGNU ELPA rules,
> and we would import their changes automatically.
>
> 2. The developers would not undertake anything, and we would look
> at new versions to see whether to import them.
>
> Did you just say to all of them that they all had to do (1)?
No, I just inform the maintainers that their packages have been added to
NonGNU ELPA, how it works (new versions are released when the "Version"
attribute is updated) and that they might update the documentation if
they are interested in promoting NonGNU ELPA as a installation method.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: [ELPA/elpa-admin] Render README.org as ASCII with ox-ascii
@ 2021-08-30 17:49 99% ` Philip Kaludercic
1 sibling, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-08-30 17:49 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Adam Porter, emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> From 85c9d3070c6d87695f57613ed51a43e7ebd5bafa Mon Sep 17 00:00:00 2001
>> From: Adam Porter <adam@alphapapa.net>
>> Date: Sun, 29 Aug 2021 17:35:59 -0500
>> Subject: [PATCH 1/2] * elpa-admin.el (elpaa--get-section): Add docstring,
>> rename vars
>
> Thanks, looks good, pushed.
>
>> From 7e34b7fb6396513560ea7e2994ee73d3e2a9820a Mon Sep 17 00:00:00 2001
>> From: Adam Porter <adam@alphapapa.net>
>> Date: Sun, 29 Aug 2021 17:45:22 -0500
>> Subject: [PATCH 2/2] * elpa-admin.el (elpaa--get-README): Docstring, export
>> Org readmes
>
> I hope we can generate HTML rather than "clean text", but in the mean
> time, clean text is better than raw source, so: thanks.
I think that raw rendering would also be good for C-h P, unless Emacs
renders the documentation using eww or something.
> There's one problem with your patch, tho: `org-export-as` can run
> arbitrary code so we want to run that in a sandbox (and hence in
> a separate Emacs process).
>
>
> Stefan
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Update of ELPA package guess-language
@ 2021-08-31 7:31 90% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-08-31 7:31 UTC (permalink / raw)
To: Richard Stallman; +Cc: bozhidar, 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. ]]]
>
> > > Did you just say to all of them that they all had to do (1)?
>
> > No, I just inform the maintainers that their packages have been added to
> > NonGNU ELPA, how it works (new versions are released when the "Version"
> > attribute is updated) and that they might update the documentation if
> > they are interested in promoting NonGNU ELPA as a installation method.
>
> Thanks.
>
> Did I understand correctly that your message saying that had the
> effect of causing some of them to act uncomfortable? If so, did any
> of them say just what it was that had that effect? We would rather
> not have that effect, and if a considerable number of them have an
> issue with it, it would be useful for us to find out just what. Then
> we could think about whether we might want to make some change --
> either in our policies for NonGNU ELPA, or in the way we present them.
I wouldn't say uncomfortable, the specific package was haskell-mode that
seems to use some special release mechanism geared towards MELPA. The
difference there is that MELPA always generates their own version tag,
so they do not add one manually in the repo itself. The maintainer Steve
Purcell, who is also one of the main MELPA contributors, just asked for
some more time to make sure that everything will work as expected.
The only other complaint I have heard of is that in ELPA differing from
MELPA, package maintainers have to change their workflow.
All of the complaints where technical in nature. Nobody explicitly
opposed NonGNU on policy or ideological grounds (at least up until now),
so I don't think anything has to be changed for now.
--
Philip Kaludercic
^ permalink raw reply [relevance 90%]
* Re: [elpa] New package: vc-got
@ 2021-08-31 13:32 90% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-08-31 13:32 UTC (permalink / raw)
To: Omar Polo; +Cc: Timo Myyrä, emacs-devel
Omar Polo <op@omarpolo.com> writes:
> The code can be found here:
>
> https://git.omarpolo.com/vc-got
>
> or here as a mirror:
>
> https://github.com/omar-polo/vc-got
>
> and I've just tagged the 1.0 release.
Which of the two URLs are preferred?
> Regarding the code: I've discovered vc-do-command too late and rolled my
> own vc-got--call in the meantime. I do intend to make more use of the
> existing vc interface in future versions.
Would you want to update the project before it is added to ELPA? I might
also be able to find some time to comment on it if you are interested
(I too released a vc package (vc-backup) just a short while ago, so I
might be able to give some input of value).
> Talking about updates, one thing that I'm not sure is how to handle
> them: if tomorrow I'll release a v1.1 I do have to ping emacs-devel,
> right?
Not necessarily. The ELPA package specification can also contain an
:auto-sync attribute, indicating that the ELPA server will regularly
check for new updates (update-commits are identified by bumping the
version tag in the package header). If you can ensure that all
contributors have signed the copyright assignment and can maintain basic
repository hygiene, the packages can be updated manually too.
--
Philip Kaludercic
^ permalink raw reply [relevance 90%]
* Re: [elpa] New package: vc-got
@ 2021-08-31 16:54 99% ` Philip Kaludercic
2021-09-09 15:50 88% ` Philip Kaludercic
1 sibling, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-08-31 16:54 UTC (permalink / raw)
To: Omar Polo; +Cc: Timo Myyrä, emacs-devel
Omar Polo <op@omarpolo.com> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Omar Polo <op@omarpolo.com> writes:
>>
>>> The code can be found here:
>>>
>>> https://git.omarpolo.com/vc-got
>>>
>>> or here as a mirror:
>>>
>>> https://github.com/omar-polo/vc-got
>>>
>>> and I've just tagged the 1.0 release.
>>
>> Which of the two URLs are preferred?
>
> I prefer the one on the domain I control and that's the one I'm
> advertising as URL in the package header, but for packaging purpose I
> think github offers less downtime than my humble server :)
In that case I'd suggest using your repository first, and perhaps adding
a comment linking to the mirror.
>> I might
>> also be able to find some time to comment on it if you are interested
>
> If you have some time to spare, I'll be more than happy to receive
> comments on the code, thanks!
Ok, I'll try to see if I can find anything to say.
>> Not necessarily. The ELPA package specification can also contain an
>> :auto-sync attribute, indicating that the ELPA server will regularly
>> check for new updates (update-commits are identified by bumping the
>> version tag in the package header). If you can ensure that all
>> contributors have signed the copyright assignment and can maintain basic
>> repository hygiene, the packages can be updated manually too.
>
> Ah right, now I remember reading about the :auto-sync attribute.
>
> Yes, all the code was written by me with help from Timo, and we both
> have a FSF copyright assignment. I've also noted this requirement in
> the ``Contributing'' section of the readme.
Then this should work too.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Representation of the Emacs userbase on emacs-devel
@ 2021-09-02 20:35 86% ` Philip Kaludercic
1 sibling, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-09-02 20:35 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: danflscr, rms, emacs-devel, monnier, eliz, John Yates
Dmitry Gutov <dgutov@yandex.ru> writes:
> Under the current system a sufficiently loud single user can
> effectively veto any change. Or at least 3-4 such users.
>
> But even 5 or 10 users are in no way representative of our entire user base.
But don't they represent other users? The fundamental issue underlying
all of this is that different people have different ideas of who is
using Emacs. We cannot say if emacs-devel is representative of the
entire user base or not. One can certainly sense differences when
comparing it to different communities (HN, /r/emacs, /emg/, popular
bloggers, various developer groups, ...), but these all tend to skew
towards Emacs enthusiasts, so they cannot be seen as reliable metric
either.
I agree that the ability for a handful of users to veto changes can be
annoying, but how harmful it is should be decided on a case-to-case
basis. Do you (or anyone else) have any examples of where one or just a
few people prevented a change from being made that you think would have
been good in your eyes?
--
Philip Kaludercic
^ permalink raw reply [relevance 86%]
* Re: Gitlab Migration
@ 2021-09-03 7:26 85% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-09-03 7:26 UTC (permalink / raw)
To: Ihor Radchenko
Cc: Daniel Fleischer, Richard Stallman, Elias Mårtenson,
emacs-devel, Stefan Monnier, Dmitry Gutov, Eli Zaretskii
Ihor Radchenko <yantar92@gmail.com> writes:
> Can Emacs have "experimental" and "stable" dev branches with the former
> being more open to "popular" changes? Then, people who wish a more
> "popular" approach can use the experimental branch without disturbing
> more conservative users. If features in experimental branch prove their
> usefulness and quality, they can be moved to the stable branch.
In some sense this exists with prepared configurations (or
"distributions" as some call them). The changes they can make are not
exactly the same as a "experimental" branch could, but they can do a lot
of superficial and organisational changes.
The issue there is that prepared configurations bundle a lot of options
together, so it is harder to evaluate what is popular and what the
maintainers of these projects prefer.
An idea I was playing around with for a while was to build a website to
generate Emacs configurations. You'd select what you like to use, what
you don't want, etc. and it would let you download an init.el
file. Optionally, the user could select to have their preferences
anonymously logged, for statistical purposes (comparable to Debian's
popcon). Of course the data could be manipulated easily, so it is
debatable how reliable it would be.
--
Philip Kaludercic
^ permalink raw reply [relevance 85%]
* Re: Gitlab Migration
@ 2021-09-03 7:28 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-09-03 7:28 UTC (permalink / raw)
To: Lars Ingebrigtsen
Cc: danflscr, rms, emacs-devel, monnier, Dmitry Gutov, Eli Zaretskii,
john
Lars Ingebrigtsen <larsi@gnus.org> writes:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>> Opt-in changes are an effective way of dealing with such resistance.
>> They cannot be easily vetoed.
>
> We have previously discussed extending the concept of a "theme", which
> is currently basically just visual. I think the way forward here is to
> allow people to create opinionated views on how Emacs should work (from
> keystrokes on up to basically... anything), and include these in Emacs.
Conversely, themes could also be used to reset changes. You could have
an Emacs-21, Emacs-27, XEmacs theme bundled by default, allowing people
to reset the defaults to whatever they are used to.
> New users, when starting Emacs, would then be able to choose between,
> say, five of these mega-themes on the start-up screen by just clicking
> them.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Gitlab Migration
@ 2021-09-03 8:35 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-09-03 8:35 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: danflscr, rms, emacs-devel, monnier, dgutov, larsi, john
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: Eli Zaretskii <eliz@gnu.org>, Dmitry Gutov <dgutov@yandex.ru>,
>> danflscr@gmail.com, rms@gnu.org, emacs-devel@gnu.org,
>> monnier@iro.umontreal.ca, john@yates-sheets.org
>> Date: Fri, 03 Sep 2021 07:28:29 +0000
>>
>> Conversely, themes could also be used to reset changes. You could have
>> an Emacs-21, Emacs-27, XEmacs theme bundled by default, allowing people
>> to reset the defaults to whatever they are used to.
>
> Yes. This was all discussed in the past, I just hope it will happen
> some time soon.
Ah, that is good to hear. The last time I was following one of the
discussions that proposed something like this, it seemed as though the
list was against it. I'll look into how successfully this could be done.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Gitlab Migration
@ 2021-09-03 11:11 77% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-09-03 11:11 UTC (permalink / raw)
To: Dmitry Gutov
Cc: Daniel Fleischer, Richard Stallman, Elias Mårtenson,
Ihor Radchenko, emacs-devel, Stefan Monnier, Eli Zaretskii
Dmitry Gutov <dgutov@yandex.ru> writes:
> On 03.09.2021 10:26, Philip Kaludercic wrote:
>> Ihor Radchenko<yantar92@gmail.com> writes:
>>
>>> Can Emacs have "experimental" and "stable" dev branches with the former
>>> being more open to "popular" changes? Then, people who wish a more
>>> "popular" approach can use the experimental branch without disturbing
>>> more conservative users. If features in experimental branch prove their
>>> usefulness and quality, they can be moved to the stable branch.
>> In some sense this exists with prepared configurations (or
>> "distributions" as some call them). The changes they can make are not
>> exactly the same as a "experimental" branch could, but they can do a lot
>> of superficial and organisational changes.
>
> And as those distributions have been around for some time, we could
> look at the changes in options they made and strongly consider making
> the changes in defaults where those distributions agree, or largely
> agree.
>
> Those kind of arguments, however, aren't generally accepted around
> here either.
I guess because it is easy to conflate the changes they make. These
distributions and prepared configurations don't have to care about
backwards compatibility, to they are a lot more flexible to change
whatever they want. But there are different things:
* Rebinding existing commands to ...
- different functionalities (C-x to kill)
- stronger equivalents (M-/ to hippie-expand)
- slightly different but more intuitive commands (M-z to zap-up-to-char)
* Binding commands to new keys (C-x p for project.el)
* Providing more or different packages by-default (various major modes
not available in ELPA, use-package, ...)
* Enabling options by default ...
- that might have been considered to intensive in the past
(show-paren-mode, decreasing lazy-highlight-initial-delay, ...)
- that change the default behaviour by trying to be intuitive (electric
modes)
* Changing the default UI to ...
- match modern design trends (adding blank space, adding those
little triangles to the mode line, ...)
- improve readability (changing the default theme, using more
variable-width faces in the UI)
And I am sure there are more, but the point is that there are different
discussions and motivations behind these changes. Emacs is currently in
the weird position where it is already different but doesn't want to
confuse new users even more by disabling some commands by default
(upcase-region, narrow-to-region) or offer more power by default
(searching using regular expressions by default).
--
Philip Kaludercic
^ permalink raw reply [relevance 77%]
* Re: Gitlab Migration
@ 2021-09-03 14:15 93% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-09-03 14:15 UTC (permalink / raw)
To: Dmitry Gutov
Cc: danflscr, rms, lokedhs, yantar92, emacs-devel, monnier,
Eli Zaretskii
Dmitry Gutov <dgutov@yandex.ru> writes:
> What if we do introduce the "profiles" feature, *and* we change our
> practice to alter the defaults more easily as well? Including radical,
> mutinous ones, like indent-tabs-mode -> nil. Not all of them, of
> course, but with more of an eye toward being useful for new users
> (violent discussions about the default values will continue, but will
> sometimes results in changes, too).
1+
It seems to me that the current practice ends up disappointing both
those who want to change the default (everything is stale) and
traditional users (minor annoyances are introduced all the time).
If it were possible for the former to fix how they want the defaults to
be by adding something like
(load-theme 'emacs-27)
to their init, they wouldn't have to fight against every minor change,
while at the same time making it easier to argue for incremental changes
for the other users.
--
Philip Kaludercic
^ permalink raw reply [relevance 93%]
* Re: Why not set Emacs development workflow based on the popular git forges (GitHub, Bitbucket, Gitlab, ect)?
@ 2021-09-04 23:25 89% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-09-04 23:25 UTC (permalink / raw)
To: Hongyi Zhao; +Cc: Po Lu, Emacs-devel, Kévin Le Gouguec
Hongyi Zhao <hongyi.zhao@gmail.com> writes:
> Sending patches isn't quite as simple as sending a pull request, but
> fortunately it is a well documented process.
It depends, I have certainly had times where sending a patch was easier
than preparing a pull request. One thing that was mentioned in the other
thread is that people are not used to patches on mailing
lists. Sourcehut and specifically git-send-email.io came up with the
clever idea of providing a testing list that nobody reads, just to see
how their messages will end up looking like. As long as you don't have
to worry that any small small mistake will have an army of greybeards
shouting at you for messing up, I think people are more accepting of a
different workflow (or that is at least my experience).
--
Philip Kaludercic
^ permalink raw reply [relevance 89%]
* Re: Variables for easy customization
@ 2021-09-06 6:39 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-09-06 6:39 UTC (permalink / raw)
To: Richard Stallman
Cc: danflscr, lokedhs, yantar92, emacs-devel, monnier, dgutov,
Lars Ingebrigtsen, eliz
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'd suggest "Prose" rather than "Text".
> > >
> > > Stefan "who has been known to consider replacing `text` with
> > > `prose` in `text-mode` and `lisp/textmodes`"
>
> > What about all the people using Emacs to write poetry? Won't anybody
> > think of the poets?
>
> I had the same reaction, but you beat me to it.
>
> Seriously, shouldn't poetry and prose be treated alike,
> in regard to editing with Emacs?
Shouldn't on the contrary, prose differ from poetry as prose doesn't
have as strict of a "structure" while poetry e.g. has to preserve line
breaks (fill-paragraph shouldn't break the visual representation of a
poem)?
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Representation of the Emacs userbase on emacs-devel
@ 2021-09-06 14:11 86% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-09-06 14:11 UTC (permalink / raw)
To: Arthur Miller
Cc: Yuan Fu, Daniel Fleischer, Richard Stallman, Stefan Kangas,
Emacs developers, Stefan Monnier, Dmitry Gutov, Eli Zaretskii,
John Yates
Arthur Miller <arthur.miller@live.com> writes:
> Dmitry Gutov <dgutov@yandex.ru> writes:
>
>> On 06.09.2021 08:04, Arthur Miller wrote:
>>
>>>>> Different or alternative as Tim proposed goes for anything:).
>>>>
>>>> But it's not "Different", it's rather "Familiar", as far as new users are
>>>> concerned.
>>> That is a different meaning to "different" indeed :). You are interpretting
>>> "different" as not-familiar or unkown, why I was thinking of "different" as of
>>> just somethin else.
>>
>> I'm just looking at the profiles as something for the new users. So if we're
>> picking names, tailoring them to the news user seems advantageous.
>>
>>> Maybe it is best just to smash together something and present it rather than
>>> trying people to agree to what is to be done? Like vim-people did with evil?
>>
>> Sure. Please don't let me stop anyone from experimenting and creating whatever
>> number of different profiles.
>>
>> It's better we start this process, rather than get bogged down here arguing
>> about particulars.
>>
>>> A diffent profile could be just a bunch of settings in a file. Why not just take
>>> a so called contermporary setup and put it in a init file, and add a customize
>>> variable to let people choose it? Could that work?
>>
>> I was thinking themes can be a good vehicle because someone can both enable and
>> disable a theme (if they find it doesn't suit their preference) without
>> restarting Emacs.
>
> That is true, but same can be done with a toggle button in customize?
> I remember when Stefan M. proposed to use themes. Themes are just lisp,
> so they can contain any lisp code, but how will it work with visual themes? There
> can be only one theme loaded at time, right?
No, you can load more than one "theme" at a time, it just usually
doesn't make any sense for visual themes. But I agree, it might be
confusing. There was some talk about "profiles", but I am not sure if
the idea is to reuse the theme system or create something new. From what
I have been experimenting with antinews themes (ie. revert all changes
since Emacs XY), it requires a minor mode to be activated anyway, so it
might also make sense to just provide a minor mode instead of a theme.
>> But, again, let us not have this preconception stop anyone from experimenting.
>
> Indeed.
>
> By the way, how much work would it be to switch C-x and M-x prefixes to C-space and
> M-space respectively. That way someone could rebind keys to resemble more of
> "modern" key usage (C-o, C-x, C-v etc ). C-z would need rework in terminal. But
> generally, if a prefix can be remaped automatically, it would be an easy thing to
> start with?
I think directly switching might be difficult, because a lot of people
hard-code C-x into keymaps, even without using kbd.
--
Philip Kaludercic
^ permalink raw reply [relevance 86%]
* Re: Gitlab Migration
@ 2021-09-07 8:03 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-09-07 8:03 UTC (permalink / raw)
To: Arthur Miller
Cc: Daniel Fleischer, Richard Stallman, Elias Mårtenson,
Stefan Kangas, Emacs developers, Stefan Monnier, Dmitry Gutov,
Eli Zaretskii
Arthur Miller <arthur.miller@live.com> writes:
> Stefan Kangas <stefan@marxist.se> writes:
>
>> Arthur Miller <arthur.miller@live.com> writes:
>>
>>> Introduce an extra prefix: C-v? And put undo on C-v u, and windmove undo on C-v U? :)
>>
>> C-v is bound to scroll-up-command.
> I know, but scroll-up can be rebound .... I use M-v for scroll
So where would you rebind scroll-down-command?
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: [ELPA/elpa-admin] Render README.org as HTML with ox-html
@ 2021-09-07 8:12 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-09-07 8:12 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Adam Porter, emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> After tweaking your code a bit to get it to work (see patch below), I'm
> still not getting the HTML I expect (the "HTML" doc only contains
> Debian Emacs's extraneous init messages but not the actual HTML from
> org-export-as, even though running the Emacs command by hand does
> output it, I haven't had time to dig deeper into the problem).
There seems to be no patch attached to your message?
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Gathering data on user preferences
@ 2021-09-08 7:52 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-09-08 7:52 UTC (permalink / raw)
To: tomas; +Cc: emacs-devel
<tomas@tuxteam.de> writes:
> On Tue, Sep 07, 2021 at 01:22:46PM +1000, Tim Cross wrote:
>>
>> Recent threads on proposed changes to default settings, provision of
>> configuration profiles, surveying Emacs users etc make me wonder if we
>> could use ELPA more effectively to gather valuable data on settings of
>> interest.
>>
>> My thinking is that we could create an ELPA package [...]
>> [...] for users to submit details about
>> their current settings which could be used to help inform decisions
>> regarding default settings.
>
> Basically a good idea. There's well-established precedent with
> Debian's popcon [1]. At install you are asked whether you want
> to take part in it, the default being "no". So it is active
> "opt in".
[...]
> I.e. some categorising of variables into publishable and private
> (perhaps with more than just two levels? Decisions, decisions)
> seems in order (reminds one of that "safe variable" thing, doesn't
> it?).
At this point, couldn't the information attached to bug reports be
used. I remember someone making the suggestion in last years
discussion. The advantage is that there is already a lot of data
available right now, and that this data contains the evolution of trends
over a number of years.
I might also imagine that if people knew bug reports contribute to a
better representation of the entire user-base.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Gathering data on user preferences
@ 2021-09-08 12:52 96% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-09-08 12:52 UTC (permalink / raw)
To: Tim Cross; +Cc: tomas, emacs-devel
Tim Cross <theophilusx@gmail.com> writes:
> I would imagine the package I'm proposing would likely leverage off some
> of the code which generates the data attached to bug reports. I also
> think it would be good to be able to mine the data which exists in bug
> reports, but have no idea how easily that could be done.
You are probably right that a separate package would provide better and
more accurate data, I just wonder what the incentive is for someone who
uses Emacs, has opinions but isn't part of any "community". Unless this
is automated, which become annoying, it seems like this is a quality vs
quantity problem -- and if that is the case, it might be more helpful to
improve the quality of the quantity (more detail in bug reports) than
improve the quantity of the quality.
--
Philip Kaludercic
^ permalink raw reply [relevance 96%]
* Re: Gathering data on user preferences
@ 2021-09-08 13:37 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-09-08 13:37 UTC (permalink / raw)
To: Howard Melman; +Cc: Eli Zaretskii, emacs-devel
Howard Melman <hmelman@gmail.com> writes:
>> On Sep 7, 2021, at 2:28 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>>
>>> From: Howard Melman <hmelman@gmail.com>
>>>
>>> I proposed this almost exactly a year ago...
>>> https://lists.gnu.org/archive/html/emacs-devel/2020-09/msg00451.html
>>> I got no responses.
>>
>> How about if you do this job yourself?
>
> By "respond" I meant no one sent an email in support of or opposed to the idea.
In my experience, the best thing you can do in that case is prepare a
prototype, so that something substantial can be discussed. No response
usually just means nobody has anything worthwhile to add.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Suggestion for improving ergonomics of repeat-maps: define-repeat-map
@ 2021-09-08 14:54 97% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-09-08 14:54 UTC (permalink / raw)
To: acdw; +Cc: emacs-devel
acdw <acdw@acdw.net> writes:
> I wrote the macro `define-repeat-map' to alleviate this large amount
> of configuration. Using this macro, the above turns into this:
>
> ~~~
> (define-repeat-map case
> ("c" capitalize-word
> "u" upcase-word
> "l" downcase-word)
> (:continue "f" forward-word
> "b" backward-word)
> (:enter downcase-dwim
> upcase-dwim
> capitalize-dwim))
> ~~~
I haven't taken a detailed look at the source, but I have two
superficial questions:
1. Why is the name argument required? Shouldn't the macro be able to
gensym a new symbol to use for the map?
2. Could the argument structure be flattened, so that you could write
something like
(define-repeat-map
"c" capitalize-word
"u" upcase-word
"l" downcase-word
:continue
"f" forward-word
"b" backward-word
:enter
downcase-dwim
upcase-dwim
capitalize-dwim)
?
--
Philip Kaludercic
^ permalink raw reply [relevance 97%]
* Re: Emacs default bindings
@ 2021-09-08 15:06 95% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-09-08 15:06 UTC (permalink / raw)
To: Stefan Kangas
Cc: Daniel Fleischer, Richard Stallman, Elias Mårtenson,
Ihor Radchenko, Emacs developers, Stefan Monnier, Dmitry Gutov,
Lars Ingebrigtsen, Eli Zaretskii
Stefan Kangas <stefan@marxist.se> writes:
> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> So it should be rewritten as a show-paren-mode/show-paren-local-mode and
>> then enabled
>
> I've always found the effect of show-paren-mode pointless (and rather
> annoying) when writing prose, e.g. in org-mode. I therefore think it
> should be enabled by default only in prog-mode.
There are also some tricky situations where from what I understand
unusual syntax tables break the highlighting. I remember a forth-mode
wanting to pair the ":" and ";" in word definitions, but show-paren-mode
didn't work as expected.
> By the way, VSCode seems to have a feature to enable highlighting the
> enclosing brackets when inside expressions. Perhaps we should add
> that feature as well (unless we already have it)?
There is highlight-parentheses (in NonGNU ELPA):
https://sr.ht/~tsdh/highlight-parentheses.el/
> https://stackoverflow.com/questions/45182543/highlight-enclosing-bracket-in-visual-studio-code
--
Philip Kaludercic
^ permalink raw reply [relevance 95%]
* Re: "Raw" string literals for elisp
@ 2021-09-08 19:22 98% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-09-08 19:22 UTC (permalink / raw)
To: Alan Mackenzie
Cc: Mattias Engdegård, Anna Glasgall, Stefan Monnier,
emacs-devel
Alan Mackenzie <acm@muc.de> writes:
> It is more readable in the same way Cobol was very readable; each small
> grouping of text is immediately understandable. But the thing as a
> whole? The rx form of that regexp takes up 6 lines, the string form 1
> line. If there are several regexps in a function rx can lead to a lot of
> bloat. Having the function fit entirely on one's screen contributes a
> lot towards readability and maintainability.
The reason I use rx in a lot of my scripts is that I can add comments,
explanations, formatting, etc. when it gets complicated. I think that is
a significant advantage, that even raw strings wouldn't have (unless a
comment syntax were to be added into the regular expression language,
which is unlikely).
--
Philip Kaludercic
^ permalink raw reply [relevance 98%]
* Re: "Raw" string literals for elisp
@ 2021-09-08 21:24 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-09-08 21:24 UTC (permalink / raw)
To: Stefan Kangas
Cc: Alan Mackenzie, Emacs developers, Anna Glasgall, Stefan Monnier,
Mattias Engdegård
Stefan Kangas <stefan@marxist.se> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> The reason I use rx in a lot of my scripts is that I can add comments,
>> explanations, formatting, etc. when it gets complicated. I think that is
>> a significant advantage, that even raw strings wouldn't have (unless a
>> comment syntax were to be added into the regular expression language,
>> which is unlikely).
>
> Perl has this:
>
> perl -e '$foo = "bar"; print "yes" if $foo =~ / bar # comment /x;'
>
> is equivalent to
>
> perl -e '$foo = "bar"; print "yes" if $foo =~ /bar/;'
Yes, but taking backwards compatibility into account, you cannot just
define some character to be used for comments.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: [elpa] New package: vc-got
2021-08-31 16:54 99% ` Philip Kaludercic
@ 2021-09-09 15:50 88% ` Philip Kaludercic
1 sibling, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-09-09 15:50 UTC (permalink / raw)
To: emacs-devel; +Cc: Timo Myyrä, Omar Polo
[-- Attachment #1: Type: text/plain, Size: 104 bytes --]
Omar and I have fixed a few issues and prepared vc-got for submission in
GNU ELPA. Here is the patch:
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-elpa-packages-vc-got-Add-package.patch --]
[-- Type: text/x-diff, Size: 862 bytes --]
From 6d8c39676e004c33c6c8caa1f8ca4b95a02d8baf Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Thu, 9 Sep 2021 14:58:37 +0200
Subject: [PATCH] * elpa-packages (vc-got): Add package
---
elpa-packages | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/elpa-packages b/elpa-packages
index 69dd6e33dd..18be9055cb 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -397,6 +397,10 @@
("url-http-ntlm" :url nil)
("validate" :url "https://github.com/Malabarba/validate.el")
("valign" :url "https://github.com/casouri/valign")
+ ("vc-got" :url "https://git.omarpolo.com/vc-got"
+ ;; Mirror: https://github.com/omar-polo/vc-got/
+ :ignored-files ("targets")
+ :auto-sync t)
("vc-hgcmd" :url "https://github.com/muffinmad/emacs-vc-hgcmd"
:auto-sync t)
("vc-backup" :url "https://git.sr.ht/~pkal/vc-backup"
--
2.30.2
[-- Attachment #3: Type: text/plain, Size: 61 bytes --]
If it is ok, I can push the commit.
--
Philip Kaludercic
^ permalink raw reply related [relevance 88%]
* EmacsConf presentation on NonGNU ELPA
@ 2021-09-10 14:30 94% Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-09-10 14:30 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
Hi Stefan, et al.,
I was talking with the Amin Bandali, the Emacs Conf organizer, and we
discussed the possibility of another NonGNU ELPA talk for this years
round. I suggested preparing a presentation to give an overview of what
has happened since last year, how to contribute, what to keep in mind,
etc.
Before submitting anything, I just wanted to make sure if you or any of
the other maintainers would object to this, as I am just a
contributor. Naturally I'd cooperate with any requests and clarify that
I am not speaking for the Emacs project, but as a contributor.
--
Philip K.
^ permalink raw reply [relevance 94%]
* Re: Cleaning up rcirc
@ 2021-09-11 16:21 94% Philip Kaludercic
2021-09-11 20:16 98% ` Philip Kaludercic
0 siblings, 2 replies; 200+ results
From: Philip Kaludercic @ 2021-09-11 16:21 UTC (permalink / raw)
To: emacs-devel
Hi,
the feature/rcirc-update should have everything implemented that I
wanted to suggest adding to Emacs 28, that were missing in the last
merge. The manual and the NEWS file should reflect all the changes.
Unless there are any objections, I would like to suggest merging the
branch into master, as from what I gather the master branch will be cut
off soon.
Finally, because of my work on rcirc, it might make sense to add me as a
maintainer in the header, so that anyone submitting a bug might Cc me in
the report. Would that be ok, or is there some procedure for these kinds
of things?
--
Philip K.
^ permalink raw reply [relevance 94%]
* Re: Cleaning up rcirc
@ 2021-09-11 17:49 98% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-09-11 17:49 UTC (permalink / raw)
To: Tassilo Horn; +Cc: emacs-devel
Tassilo Horn <tsdh@gnu.org> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
> Hi Philip,
Hi Tassilo, just wanted to say that your comment and encouragement has
been very helpful,
>> the feature/rcirc-update should have everything implemented that I
>> wanted to suggest adding to Emacs 28, that were missing in the last
>> merge. The manual and the NEWS file should reflect all the changes.
>>
>> Unless there are any objections, I would like to suggest merging the
>> branch into master, as from what I gather the master branch will be
>> cut off soon.
>
> I'd say, go ahead. I've been using that branch on my server where I
> have my tmux/rcirc session since you've started it and it works fine.
Ok, but I'll just wait a bit longer.
I am not sure if you've tried out the recent changes, including
asynchronous connecting and reconnecting -- this is what I am worrying
about the most. It seems to be working, and I have tried a few edge
cases, but there might be some other situation that break in ways I
didn't expect.
--
Philip Kaludercic
^ permalink raw reply [relevance 98%]
* Re: Cleaning up rcirc
@ 2021-09-11 20:13 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-09-11 20:13 UTC (permalink / raw)
To: Tassilo Horn; +Cc: emacs-devel
Tassilo Horn <tsdh@gnu.org> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> I am not sure if you've tried out the recent changes, including
>> asynchronous connecting and reconnecting -- this is what I am worrying
>> about the most. It seems to be working, and I have tried a few edge
>> cases, but there might be some other situation that break in ways I
>> didn't expect.
>
> Is there something I can test explicitly? FWIW, I'm also connected to
> irc.gitter.im which happens to become disconnected quite often (meaning
> every few days).
Nothing in particular, the intention is that asynchronous connecting
should just be an improvement that doesn't break any workflow.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Cleaning up rcirc
2021-09-11 16:21 94% Cleaning up rcirc Philip Kaludercic
@ 2021-09-11 20:16 98% ` Philip Kaludercic
1 sibling, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-09-11 20:16 UTC (permalink / raw)
To: emacs-devel
Oh, and another thing I was thinking about. Currently the default value
for rcirc-server-alist connects the user to irc.libera.chat and lets
them join #rcirc. I was wondering if it would be ok to add #emacs to
this list too, seeing as rcirc is implied to be the default IRC client
for Emacs (by "M-x irc"). I can imagine that since the channel is not
directly affiliated to the GNU project, that there might be objections?
Philip Kaludercic <philipk@posteo.net> writes:
> Hi,
>
> the feature/rcirc-update should have everything implemented that I
> wanted to suggest adding to Emacs 28, that were missing in the last
> merge. The manual and the NEWS file should reflect all the changes.
>
> Unless there are any objections, I would like to suggest merging the
> branch into master, as from what I gather the master branch will be cut
> off soon.
>
> Finally, because of my work on rcirc, it might make sense to add me as a
> maintainer in the header, so that anyone submitting a bug might Cc me in
> the report. Would that be ok, or is there some procedure for these kinds
> of things?
--
Philip Kaludercic
^ permalink raw reply [relevance 98%]
* Proposal: Forwards-Compatibility Library for Emacs
@ 2021-09-20 23:35 79% Philip Kaludercic
` (5 more replies)
0 siblings, 6 replies; 200+ results
From: Philip Kaludercic @ 2021-09-20 23:35 UTC (permalink / raw)
To: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 124 bytes --]
Hi,
over the last few days I have been working on a forwards-compatibility
library for Emacs, here is a first iteration:
[-- Attachment #2: compat.el --]
[-- Type: application/emacs-lisp, Size: 51650 bytes --]
[-- Attachment #3: Type: text/plain, Size: 1384 bytes --]
The idea is to allow developers who don't want to break backwards
compatibility to use newer functionality that wasn't provided in older
versions of Emacs. This version tries to implement as much as possible
from Emacs 24.2 onwards.
By its very nature it is an intrusive package, as it defines functions,
macros and advice outside of the "namespace", but I don't see any way
around that if transparent compatibility is to be provided (anything
else would just replicate dash, s, f, ...).
As some of the functions are lisp reimplementations of core functions,
there exists the risk of a performance overhead. To minimize this, the
compatibility layer is only applied necessary: Ideally someone using
Emacs 28.1 should have a quasi-empty file, with all the definitions
byte-compiled away.
Eventually I would like to propose adding something like this to
ELPA. It would only makes sense, as more than a few functions were
copied verbatim or quasi-verbatim from Emacs itself.
There still is work to be done, before anything could be added to ELPA,
especially providing tests to ensure that the compatibility layer is
implemented correctly, and making sure that no functions are used that
break the compatibility promise.
So before I continue working on this, I would like to ask if there is
any interest/there are any objections to providing such a library?
--
Philip Kaludercic
^ permalink raw reply [relevance 79%]
* Re: Proposal: Forwards-Compatibility Library for Emacs
@ 2021-09-21 8:28 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-09-21 8:28 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: emacs-devel
Lars Ingebrigtsen <larsi@gnus.org> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> So before I continue working on this, I would like to ask if there is
>> any interest/there are any objections to providing such a library?
>
> In the past, it was frowned upon to create these shims because of
> "pollution" and "cleanliness" and all that sort of stuff -- when
> something breaks, the question becomes "which version of `when-let*' was
> that, then?" which most users aren't able to answer.
To avoid this issue, I intentionally never overwrote the actual
function, so it should be possible to remove the compatibility layer,
and secondly the docstring for every compatibility function starts with
a line indicating that it is in fact a compatibility function:
[Compatibility function for ‘cdddr’, defined in Emacs 26.1]
> That said, it's just so much more practical for package authors to have
> these compat shim libraries. I naughtily had a gnus-compat.el library
> in the external Gnus distribution for a decade that did pretty much what
> you're doing here, and I can't recall anything breaking.
>
> So I'm for it.
Great, I'll ping this thread when the package is ready.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Proposal: Forwards-Compatibility Library for Emacs
@ 2021-09-21 12:58 82% ` Philip Kaludercic
2 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-09-21 12:58 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> By its very nature it is an intrusive package, as it defines functions,
>> macros and advice outside of the "namespace", but I don't see any way
>> around that if transparent compatibility is to be provided (anything
>> else would just replicate dash, s, f, ...).
>
> I think this uncleanliness is a bit risky. Better put the definitions
> in their own namespace.
Just to be on the same page, what exactly is the risk? I understand the
issue on a gut-level, it goes against convention and recommendations,
but the idea is that this package would do that, so that others don't
have to.
Other than that, all the functions and macros are defined first using a
"compat--" prefix, then perhaps are aliased to a symbol without a
prefix.
> I don't think "transparent compatibility" is
> worth the trouble here, and I don't think `s`, `f`, ... solve the
> same problem.
Of course not, s, f, and the rest of the dash-adjacent ecosystem have
different intentions, it is only as a side effect that they provide more
functionality than older versions of Emacs do.
Most of the examples I provide in the file I attached above are simple
or slower reimplementations that make programming more convenient, but
where "transparent compatibility" becomes interesting is when providing
noop compatibility that allows package developers to make use of newer
features that are not backwards compatible, such as the additional
interactive argument. The infrastructure doesn't exist to handle this
information, but package developers will hold back from using these new
features because they don't want to abandon all users that aren't on
28.1.
I don't see how examples like these could be handled without transparent
compatibility.
> Stefan
--
Philip Kaludercic
^ permalink raw reply [relevance 82%]
* Re: Proposal: Forwards-Compatibility Library for Emacs
@ 2021-09-21 13:00 99% ` Philip Kaludercic
1 sibling, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-09-21 13:00 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel, Stefan Monnier, João Távora
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Cc: emacs-devel@gnu.org
>> Date: Tue, 21 Sep 2021 08:31:39 -0400
>>
>> > By its very nature it is an intrusive package, as it defines functions,
>> > macros and advice outside of the "namespace", but I don't see any way
>> > around that if transparent compatibility is to be provided (anything
>> > else would just replicate dash, s, f, ...).
>>
>> I think this uncleanliness is a bit risky. Better put the definitions
>> in their own namespace. I don't think "transparent compatibility" is
>> worth the trouble here, and I don't think `s`, `f`, ... solve the
>> same problem.
>
> Can symbol-renaming help here, perhaps? I believe João is trying to
> get it ready in time for Emacs 28.
Going by my proposal, the library does nothing when loaded in Emacs
28.1, because it is already compatible to itself. No need for an extra
layer. It is only of interest to older versions, and they won't be able
to make use of symbol-renaming.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Proposal: Forwards-Compatibility Library for Emacs
2021-09-20 23:35 79% Proposal: Forwards-Compatibility Library for Emacs Philip Kaludercic
@ 2021-09-21 13:05 93% ` Philip Kaludercic
` (2 subsequent siblings)
5 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-09-21 13:05 UTC (permalink / raw)
To: emacs-devel
Philip Kaludercic <philipk@posteo.net> writes:
> ;; Is this excusable?
> ;;
> ;; ;;;; Ensure NonGNU ELPA is in `package-archives'
> ;; (eval-after-load "package"
> ;; (lambda ()
> ;; (unless (or (rassoc "https://elpa.nongnu.org/nongnu/" package-archives)
> ;; (rassoc "http://elpa.nongnu.org/nongnu/" package-archives)
> ;; (rassoc "https://elpa.nongnu.org/nongnu-devel/" package-archives)
> ;; (rassoc "http://elpa.nongnu.org/nongnu-devel/" package-archives))
> ;; (add-to-list 'package-archives '("nongnu" . "https://elpa.nongnu.org/nongnu/")))))
I also wanted to bring attention to this snippet, which if uncommented
might be a lot more controversial than the actual content of the library
itself. More generally, if a compatibility library were to be used more
widely, it would offer a possible route to update old defaults, such as
in this case, adding NonGNU ELPA to package-archives, or perhaps update
the default values of the IRC servers used by rcirc and ERC from
freenode to libera. If this could even be excused (and I get why people
could have issues with this), it would have to be used very
conservatively to not interfere with any existing configurations.
--
Philip Kaludercic
^ permalink raw reply [relevance 93%]
* Re: Proposal: Forwards-Compatibility Library for Emacs
@ 2021-09-21 13:28 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-09-21 13:28 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: joaotavora, monnier, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Date: Tue, 21 Sep 2021 13:00:16 +0000
>> Cc: emacs-devel@gnu.org, Stefan Monnier <monnier@iro.umontreal.ca>,
>> João Távora <joaotavora@gmail.com>
>>
>> > Can symbol-renaming help here, perhaps? I believe João is trying to
>> > get it ready in time for Emacs 28.
>>
>> Going by my proposal, the library does nothing when loaded in Emacs
>> 28.1, because it is already compatible to itself. No need for an extra
>> layer. It is only of interest to older versions, and they won't be able
>> to make use of symbol-renaming.
>
> Why it is a problem for older versions to load symbol-renaming as
> well?
My understanding was that this would depend on Emacs 28, but if not then
I retract my comment.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Proposal: Forwards-Compatibility Library for Emacs
@ 2021-09-21 13:29 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-09-21 13:29 UTC (permalink / raw)
To: João Távora; +Cc: Eli Zaretskii, Stefan Monnier, emacs-devel
João Távora <joaotavora@gmail.com> writes:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> I think this uncleanliness is a bit risky. Better put the definitions
>>> in their own namespace. I don't think "transparent compatibility" is
>>> worth the trouble here, and I don't think `s`, `f`, ... solve the
>>> same problem.
>>
>> Can symbol-renaming help here, perhaps? I believe João is trying to
>> get it ready in time for Emacs 28.
>
> Confirmed. I am working on the documentation and hope to provide
> "hygienic", drop-in versions of those very `s.el`, `f.el` libraries. I
> agree with Stefan that those libraries don't seem to be solving the same
> problem of forward-compatibility, though (at least how I've understood
> it, which may very well be "not at all").
Where can I find the code/examples on how this would look like?
> João
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Proposal: Forwards-Compatibility Library for Emacs
@ 2021-09-21 13:45 81% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-09-21 13:45 UTC (permalink / raw)
To: Arthur Miller; +Cc: emacs-devel
Arthur Miller <arthur.miller@live.com> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> The idea is to allow developers who don't want to break backwards
>> compatibility to use newer functionality that wasn't provided in older
>> versions of Emacs. This version tries to implement as much as possible
>> from Emacs 24.2 onwards.
>>
>> By its very nature it is an intrusive package, as it defines functions,
>> macros and advice outside of the "namespace", but I don't see any way
>> around that if transparent compatibility is to be provided (anything
>> else would just replicate dash, s, f, ...).
>
> Is there a problem if something replicates something else? :) If it is a good
> thing, we just call it a "design pattern".
Just to clarify: My point is that I *don't* want to just propose a
different dash/s/f/... library, that consists of only a few new useful
functions and macros.
>> As some of the functions are lisp reimplementations of core functions,
>> there exists the risk of a performance overhead. To minimize this, the
>> compatibility layer is only applied necessary: Ideally someone using
>> Emacs 28.1 should have a quasi-empty file, with all the definitions
>> byte-compiled away.
>>
>> Eventually I would like to propose adding something like this to
>> ELPA. It would only makes sense, as more than a few functions were
>> copied verbatim or quasi-verbatim from Emacs itself.
>
> I had a similar idea once, and I think it definitely belongs to an external
> package.
>
> If you had this as an external library, than people who use older Emacs:es could
> install compat-libs as a package, and in cases where there is a compatibility
> function provided, they would just load a compat library after a package is
> loaded.
>
> Say I use dired-empty-p which is introuded in Emacs 28, in "some-program". A user
> of some-program could then:
>
> (with-eval-after-load 'some-program
> (require 'compat-lib-28))
Why would a user do this?
> I am just a bit concerned about all-in approach. As I udnerstand your code, it is
> loaded as a library, and all code is loaded at once. So there might be code that
> affects files and naming, or they might be coad that affects displayign of
> windows, frames or code of handling user input etc. User might not want to load
> everything and change behaviour of his/her entire Emacs. This might also lead to
> unnexpected problems when there are 3rd party packages that rely on the old
> behaviour.
The audience of this library are developers, not (non-developer)
users. The point is not to make older versions of Emacs work like 28 or
newer, but to make code that targets Emacs 28 work with older versions
(insofar this is possible).
> I would rather prefer if compat-lib-28.el (or whatver called), would check on
> it's features it overloads.
>
> Easy case is wiith named features. It could check if user has loaded dired, and
> load it's compatibility functions for dired that were introuded in emacs 28, and
> it could also put itself in with-eval-after-load statement, so that if some
> feature is loaded again, it loads itself. Harder is case when library does not
> export a named feature, like files.el.
>
> That would provide for transparent "namespace" handling as you describe in your
> next paragraph.
>
> Of course, newly introduced functions are not the problem; I am concerned with
> already existing functions, which might have changed slightly how they
> function. I don't know if such exists, but I am thinking that some code could be
> broken or still not function, despite function being advised to '28 version'.
>
> I think it is important to not load and advise too much. If a program uses only
> function foo, than there is no need to twinkle with function bar.
I agree, it might make sense to remove some of the compatibility
definitions, that just supply an additional argument. I'd argue there
are cases where it makes sense, such as assoc and the testfn argument,
but they have to be evaluated.
> Another thing I was thinking of is use of advice. Advice is global, it means it
> affects all users of the function. Isn't it better to define a buffer-local
> variable, stash old function in the variable, and than call this buffer-local
> from the compat function. That would also require compat layer to be a minor
> mode, which is why I call it a layer rather than a library. User would have to
> do slightly more:
>
> (with-eval-after-load 'some-program
> (require 'compat-lib-28)
> (compat-mode +1))
>
> That way the risk of conflicts when function has slightly change from it's
> previous version is minimized since it will run only in that buffer, affecting
> (hepofully) just 'some-program.
>
> Or something ... I don't know; those were just thoughts, maybe I am wrong about.
A different idea might be to try an integrate the compatibility layer
into the byte-compilation process for specific files. But once again,
this wouldn't be done by the user, but a (package) developer would
request for it to be done.
>> There still is work to be done, before anything could be added to ELPA,
>> especially providing tests to ensure that the compatibility layer is
>> implemented correctly, and making sure that no functions are used that
>> break the compatibility promise.
>
> Ert tests provided in version it provides compatibility for can always be used,
> when there are some?
I know, I am currently working on writing a test suite with ert.
>> So before I continue working on this, I would like to ask if there is
>> any interest/there are any objections to providing such a library?
>
> Why should there be objections? It is free to write a library and give it to the
> world, right?
Yes, but I respect the opinion of the list and would like to add this to
ELPA, so good objections could change my mind that it is worthwhile to
implement something like this to the end.
--
Philip Kaludercic
^ permalink raw reply [relevance 81%]
* Re: Proposal: Forwards-Compatibility Library for Emacs
@ 2021-09-21 13:54 74% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-09-21 13:54 UTC (permalink / raw)
To: Arthur Miller; +Cc: Stefan Monnier, emacs-devel
Arthur Miller <arthur.miller@live.com> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>
>>>> By its very nature it is an intrusive package, as it defines functions,
>>>> macros and advice outside of the "namespace", but I don't see any way
>>>> around that if transparent compatibility is to be provided (anything
>>>> else would just replicate dash, s, f, ...).
>>>
>>> I think this uncleanliness is a bit risky. Better put the definitions
>>> in their own namespace.
>>
>> Just to be on the same page, what exactly is the risk? I understand the
>> issue on a gut-level, it goes against convention and recommendations,
>> but the idea is that this package would do that, so that others don't
>> have to.
>
> It is not on a "gut-level" :). I was thinking about same, and wrote you a longer
> answer I just sent. There were no replys when I started, I see now several
> people replied.
>
> There can be two functions defineing slightly different behaviour in different
> version, there can also be 3rd party packages expecting certain behaviour, and
> there is no need to advise too much, say windowing code if application need to
> just check is directory-empty-p.
Yes, I think cases where different versions switch back and forth are
hard to make compatible, so they should be left out of any attempt like
this.
>> Other than that, all the functions and macros are defined first using a
>> "compat--" prefix, then perhaps are aliased to a symbol without a
>> prefix.
>>
>>> I don't think "transparent compatibility" is
>>> worth the trouble here, and I don't think `s`, `f`, ... solve the
>>> same problem.
>>
>> Of course not, s, f, and the rest of the dash-adjacent ecosystem have
>> different intentions, it is only as a side effect that they provide more
>> functionality than older versions of Emacs do.
>
> They define different API from Emacs, more used by people comming from different
> Lisp(s), clojure if I am correct?
From what I know they are inspired by Clojure and try to provide better
compatibility with the various macros that dash provides (such as
threading), but I am not sure if they are direct translations from
Clojure's standard library.
>> Most of the examples I provide in the file I attached above are simple
>> or slower reimplementations that make programming more convenient, but
>> where "transparent compatibility" becomes interesting is when providing
>> noop compatibility that allows package developers to make use of newer
>> features that are not backwards compatible, such as the additional
>> interactive argument. The infrastructure doesn't exist to handle this
>> information, but package developers will hold back from using these new
>> features because they don't want to abandon all users that aren't on
>> 28.1.
>>
>> I don't see how examples like these could be handled without transparent
>> compatibility.
>
> When it comes to providing newly intoduced functionality, there shouldn't be a
> problem, it should always be possible to just add a function, like
> dired-empty-p:
>
>
> (when (version< emacs-version "28")
> (defun directory-empty-p (file-name)
> "Check if a directory contains any other files then dot-files"
> (when (file-directory-p file-name)
> (null (directory-files file-name nil
> directory-files-no-dot-files-regexp t)))))
>
> You don't even need to advise directory-files for that.
That wouldn't even be advised. My definition
(compat-defun directory-empty-p (dir)
"Return t if DIR names an existing directory containing no other files.
Return nil if DIR does not name a directory, or if there was
trouble determining whether DIR is a directory or empty.
Symbolic links to directories count as directories.
See `file-symlink-p' to distinguish symlinks."
:version "28.1"
(and (file-directory-p dir)
(null (directory-files dir nil directory-files-no-dot-files-regexp t))))
is expanded to
(progn
(declare-function compat--directory-empty-p "compat"
'(dir))
(let nil
(defun compat--directory-empty-p
(dir)
"[Compatibility function for `directory-empty-p', defined in Emacs 28.1]\n\nReturn t if DIR names an existing directory containing no other files.\nReturn nil if DIR does not name a directory, or if there was\ntrouble determining whether DIR is a directory or empty.\n\nSymbolic links to directories count as directories.\nSee `file-symlink-p' to distinguish symlinks." nil
(and
(file-directory-p dir)
(null
(directory-files dir nil directory-files-no-dot-files-regexp t))))
(compat-ignore
(defalias 'directory-empty-p #'compat--directory-empty-p))))
which is more or less the same as what you do (setting aside the fact
that on my system, the installation via defalias is ignored).
> But for already existing functions that might lead to problems. I think so at
> least. In the answer I sent you, I was thinking of buffer-local function
> variables instead of advices which are global.
--
Philip Kaludercic
^ permalink raw reply [relevance 74%]
* Re: Proposal: Forwards-Compatibility Library for Emacs
@ 2021-09-21 16:10 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-09-21 16:10 UTC (permalink / raw)
To: João Távora; +Cc: Lars Ingebrigtsen, Stefan Monnier, emacs-devel
João Távora <joaotavora@gmail.com> writes:
> On Tue, Sep 21, 2021 at 4:02 PM Lars Ingebrigtsen <larsi@gnus.org> wrote:
>
>> The point here is to not to have any separate namespace, so that you can
>> just can put core packages into ELPA without doing any rewrites.
>>
>> What's the concrete risk here?
>
> It was Philip who described as "intrusive", "by its very nature",
> since it relies on advice and such. This can be seen as "dirty" in itself.
> But say that the contract/promise that a given function in Emacs 28 makes
> is different from the promise that the same function in Emacs 24.2 makes.
> The new ELPA code doesn't have a problem, but you have potential problem
> to all the other 24.2 code that expects the "old promise". Right?
Yes, that is why full compatibility isn't possible, but on the other
hand, these kinds of changes are not that common to begin with. After
all, you don't want to break existing code, with or without a
compatibility library.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Cleaning up rcirc
@ 2021-09-21 19:18 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-09-21 19:18 UTC (permalink / raw)
To: Tassilo Horn; +Cc: emacs-devel
Tassilo Horn <tsdh@gnu.org> writes:
> Tassilo Horn <tsdh@gnu.org> writes:
>
> Hi Philip,
>
>> AFAICS, auto-reconnect is triggered when the process sentinel for a
>> server receives "deleted\n" but it's only tried once, right? I think
>> it would make sense to run reconnect from a timer trying again every
>> `rcirc-reconnect-delay' seconds (probably with a minimum of 10 seconds
>> or so) because if something's wrong (broken connection) it might take
>> a bit longer before reconnect will work.
>
> I can report that with your new option and
>
> (setq rcirc-reconnect-delay 10
> rcirc-reconnect-attempts 10)
>
> rcirc successfully reconnected to libera.chat when they had to restart
> all services after a system upgrade.
Great!
> However, irc.gitter.im again broke at some point in time and did not
> reconnect. In the server buffer, there's just
>
> 01:23 !!! irc.gitter.im: connection broken by remote peer (closed)
>
> A manual /reconnect worked fine.
Thank you for the report, I will look into this specific issue. Were
there any other messages about previous reconnection attempts?
> Bye,
> Tassilo
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Proposal: Forwards-Compatibility Library for Emacs
@ 2021-09-21 21:06 98% ` Philip Kaludercic
1 sibling, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-09-21 21:06 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Lars Ingebrigtsen, emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> The point here is to not to have any separate namespace, so that you can
>> just can put core packages into ELPA without doing any rewrites.
>> What's the concrete risk here?
>
> I think in practice it's usually not a problem, but I'd be surprised if
> there aren't counter examples. So for a library that wants to do it in
> a somewhat predictable/systematic way, I think it's much simple to have
> all the definitions in a specific namespace (like `compat28-`), and then
> it's a small matter of have a trivial `compat28.el` library that comes
> with Emacs-28 which has a bunch of `defalias`.
I am not sure how this would help provide forwards compatibility for
older versions? Are you proposing that instead of using
file-name-concat, libraries use compat28-file-name-concat that is
defined in a library for older versions?
My intuition would be that this wouldn't be worth the effort, seeing as
most people would probably hesitate to use such long names.
> The main advantage is that we then don't need to assess the possible
> risks at all, so we're free to think about the things that actually matter.
>
>
> Stefan
--
Philip Kaludercic
^ permalink raw reply [relevance 98%]
* Re: Proposal: Forwards-Compatibility Library for Emacs
@ 2021-09-22 6:48 92% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-09-22 6:48 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Lars Ingebrigtsen, emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> I am not sure how this would help provide forwards compatibility for
>> older versions? Are you proposing that instead of using
>> file-name-concat, libraries use compat28-file-name-concat that is
>> defined in a library for older versions?
>
> Yes.
>
>> My intuition would be that this wouldn't be worth the effort, seeing as
>> most people would probably hesitate to use such long names.
>
> If the function is important enough that the author would otherwise make
> its own local function, then I think they'd be happy to use that
> slightly longer name rather than having their own local definition.
>
> If not, then it's probably just as well if they simply don't use it
> (and that should avoid having the compatibility library accrue
> too many definitions of too little value).
This I'd describe as compatibility for convenience, but there are also
examples where core ELPA implement general algorithms and functionality
that could be used elsewhere too (project--buffers-to-kill and
project--kill-buffer-check were mentioned as one example last year). But
they cannot be factored out, because that would raise the minimal
required version. The complementary example are external packages that
hesitate to use newer functionality, for the same reason (I already gave
the example of the second optional "interactive" argument). The
infrastructure may not exist, but for anyone before Emacs 28, this could
just be ignored away, while newer users get to keep it.
> Stefan
>
--
Philip Kaludercic
^ permalink raw reply [relevance 92%]
* Re: Proposal: Forwards-Compatibility Library for Emacs
@ 2021-09-22 6:53 94% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-09-22 6:53 UTC (permalink / raw)
To: João Távora; +Cc: Lars Ingebrigtsen, Stefan Monnier, emacs-devel
João Távora <joaotavora@gmail.com> writes:
> On Tue, Sep 21, 2021 at 10:57 PM Lars Ingebrigtsen <larsi@gnus.org> wrote:
>> We can just start slowly and see whether any problems occur.
>
>> The main point here is to be able to put things that are in core into
>> ELPA, too.
>
> Right. And so if this is the goal (and given that I also agree to
> "start slow"), why not have more :core ELPA packages?
> Say subr-x.el, as an example. It has no dependencies. Why
> not make it a :core package right now? Then other ELPA packages
> could just rely on it. Or pp.el, or any other util-rich package which
> has no dependencies.
This might work for subr-x and other elisp packages (in which case these
could just be added as dependencies to the effectively virtual package
compat).
On the other hand: If the functions are implemented in C, then they have
to be replicated some other way. And this doesn't just apply to
length{<,=,>}, string-distance, etc. but any function that might end up
using them down the call stack.
In principle, these two approaches can be merged, but I have the
impression that this would be more complicated
--
Philip Kaludercic
^ permalink raw reply [relevance 94%]
* Re: Proposal: Forwards-Compatibility Library for Emacs
@ 2021-09-22 9:54 60% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-09-22 9:54 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: Richard Stallman, emacs-devel
Lars Ingebrigtsen <larsi@gnus.org> writes:
> Richard Stallman <rms@gnu.org> writes:
>
>> > The idea is to allow developers who don't want to break backwards
>> > compatibility to use newer functionality that wasn't provided in older
>> > versions of Emacs. This version tries to implement as much as possible
>> > from Emacs 24.2 onwards.
>>
>> Would you please state concretely what this package would do?
Functionality-wise: The package uses custom macros to define
"compatibility functions". A compatibility function implements at least
a subset of the behaviour the "real function" would provide, if it were
defined in whatever release of Emacs.
The macros it provides are:
- compat-defun
Defines a compatibility function that is only aliased to the "real"
symbol, if this is unbound and the specified version is greater than
the current version. Example:
(compat-defun always (&rest _arguments)
"Do nothing and return t.
This function accepts any number of ARGUMENTS, but ignores them.
Also see `ignore'."
:version "28.1"
t)
On Emacs 28.1 an newer, this just expands to `nil', because the plist
after the documentation sting specifies that this function was defined
in Emacs 28.1. Other attributes can be given such as part of what
library this function was defined, so that it is wrapped in an
eval-after-load body, preventing the developer from using the
function, without loading the right library beforehand.
Otherwise it defines
(defun compat--always (&rest _)
"[Compatibility function for `always', defined in Emacs 28.1]
Do nothing and return t.
This function accepts any number of ARGUMENTS, but ignores them.
Also see `ignore'."
t)
followed by
(unless (fboundp 'always)
(defalias 'always #'compat-always))
- compat-macro
Analogous to compat-defun, just for macros.
- compat-advise
Defines an advice function that is then applied to wrap (ie. :around)
the actual function. Example:
(compat-advise sort (seq predicate)
"Handle SEQ of type vector."
:version "25.1"
(cond
((listp seq)
(funcall oldfun seq predicate))
((vectorp seq)
(let ((cseq (sort (append seq nil) predicate)))
(dotimes (i (length cseq))
(setf (aref seq i) (nth i cseq)))
(apply #'vector cseq)))
((signal 'wrong-type-argument 'list-or-vector-p))))
Again, it defines a compat--sort function with the same body as
compat-advise, and an additional argument "oldfun".
- compat-defvar
Defines a variable, constant, buffer-local or permanent-local
variable, again using a version attribute and boundp to check if it
should do so.
I plan to add at least compat-defface, for defining faces that older
versions of Emacs didn't provide.
> The library defines versions of newer functions if Emacs doesn't already
> have them. For instance, Emacs 28 has a new function
> 'buffer-local-boundp'. Philip's library would provide a definition of
> functions like that for use in ELPA code that's written for newer Emacs
> versions, so that they can be used in older Emacs versions without
> introducing compatibility shims like `foo-package-buffer-local-boundp'.
>
> This also allows us to put (more) core packages into GNU ELPA without
> any code changes.
I am not sure if no-code-changes are always possible, but that would be
the best-case scenario.
>> > By its very nature it is an intrusive package, as it defines functions,
>> > macros and advice outside of the "namespace", but I don't see any way
>> > around that if transparent compatibility is to be provided (anything
>> > else would just replicate dash, s, f, ...).
>>
>> I have a plan to put those names into optional namespaces (using
>> symbol renaming) so that the entry points of those packages will
>> be visible only from packages that require specific libraries.
>
> Philip shouldn't have mentioned s and dash and the rest -- his proposal
> has absolutely nothing to do with those, but it seems like many people
> have lashed onto that part, somehow.
The reason I mentioned these libraries at all, is that for more than a
few package developers, I have noticed that they use these libraries for
the sake of convenience *and* backwards compatibility. As these
libraries are updated externally, they provide more easily usable
functionality that wasn't given in say Emacs 24.x. If they are
interested in convince and less repetitive programming, as I am sure
many are, they would have to choose between raising the minimal version
required to use their package or to add these external libraries.
My point in mentioning these was not to give a direct comparison, but
just to say that if compat.el didn't use transparent compatibility, it
would just become another utility function library -- just instead of
using a Clojure style of programming, it would stick to the more
traditional Elisp conventions.
--
Philip Kaludercic
^ permalink raw reply [relevance 60%]
* Re: Proposal: Forwards-Compatibility Library for Emacs
@ 2021-09-22 18:54 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-09-22 18:54 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Lars Ingebrigtsen, emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> My conclusion is that it all depends and it can't really be decided in
> the abstract. So, if you show a prototype things will be much
> more clear.
I attached a prototype to the first message?
> Stefan
>
>
> Philip Kaludercic [2021-09-22 06:48:30] wrote:
>
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>
>>>> I am not sure how this would help provide forwards compatibility for
>>>> older versions? Are you proposing that instead of using
>>>> file-name-concat, libraries use compat28-file-name-concat that is
>>>> defined in a library for older versions?
>>>
>>> Yes.
>>>
>>>> My intuition would be that this wouldn't be worth the effort, seeing as
>>>> most people would probably hesitate to use such long names.
>>>
>>> If the function is important enough that the author would otherwise make
>>> its own local function, then I think they'd be happy to use that
>>> slightly longer name rather than having their own local definition.
>>>
>>> If not, then it's probably just as well if they simply don't use it
>>> (and that should avoid having the compatibility library accrue
>>> too many definitions of too little value).
>>
>> This I'd describe as compatibility for convenience, but there are also
>> examples where core ELPA implement general algorithms and functionality
>> that could be used elsewhere too (project--buffers-to-kill and
>> project--kill-buffer-check were mentioned as one example last year). But
>> they cannot be factored out, because that would raise the minimal
>> required version. The complementary example are external packages that
>> hesitate to use newer functionality, for the same reason (I already gave
>> the example of the second optional "interactive" argument). The
>> infrastructure may not exist, but for anyone before Emacs 28, this could
>> just be ignored away, while newer users get to keep it.
>>
>>> Stefan
>>>
>
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: NonGNU ELPA work
2021-08-27 15:42 14% ` Philip Kaludercic
@ 2021-09-23 22:51 56% ` Philip Kaludercic
2021-12-09 23:24 36% ` Philip Kaludercic
2 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-09-23 22:51 UTC (permalink / raw)
To: emacs-devel; +Cc: Stefan Monnier, Drew Adams
[-- Attachment #1: Type: text/plain, Size: 898 bytes --]
It might be interesting to consider adding a few of these libraries to
NonGNU ELPA: https://www.emacswiki.org/emacs/DrewsElispLibraries
For them to be added to nongnu.git, we'd have to use the emacsmirror
(https://github.com/emacsmirror) repositories.
These seem interesting:
- bookmark+
* buff-menu+
* calendar+
* compile+
- dired+
* doremi
* grep+
* help+
* help-fns+
* highlight
* hl-line+
- icicles
* imenu+
* info+
* isearch+
* lacarte
* window+
There are two main issues:
1. The ...+ libraries tend to overwrite functions defined in Emacs
itself. While from what I understand this is also the intention, it
might be nice if this could be avoided.
2. The packages with an "*" have a version number set to 0. This
indicates they shouldn't be released on the main archive.
I Cc'ed Drew to see if he is interested in cooperating.
Here is the (untested) diff of elpa-packages:
[-- Attachment #2: Type: text/plain, Size: 3676 bytes --]
diff --git a/elpa-packages b/elpa-packages
index 1074f4c30..d8a4704d4 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -16,6 +16,12 @@
("bison-mode" :url "https://github.com/Wilfred/bison-mode")
+ ("bookmark+" :url "https://github.com/emacsmirror/bookmark-plus")
+
+ ("buff-menu+" :url "https://github.com/emacsmirror/buff-menu-plus")
+
+ ("calendar+" :url "https://github.com/emacsmirror/calendar-plus")
+
("caml" :url "https://github.com/ocaml/caml-mode"
;; The version 4.7.1 from Melpa-stable seems to correspond to
;; revision a9134009.
@@ -25,6 +31,8 @@
:ignored-files ("clojure-mode-extra-font-locking.el" "doc" "test" "test.clj")
:news "CHANGELOG.md")
+ ("compile+" :url "https://github.com/emacsmirror/compile-plus")
+
("crux" :url "https://github.com/bbatsov/crux")
("d-mode" :url "https://github.com/Emacs-D-Mode-Maintainers/Emacs-D-Mode"
@@ -34,6 +42,10 @@
:ignored-files ("test" "Cask" "Makefile")
:news "CHANGELOG.md")
+ ("dired+" :url "https://github.com/emacsmirror/dired-plus")
+
+ ("doremi" :url "https://github.com/emacsmirror/doremi")
+
("editorconfig" :url "https://github.com/editorconfig/editorconfig-emacs"
:doc "doc/editorconfig.texi"
:news "CHANGELOG.md"
@@ -78,6 +90,8 @@
("goto-chg" :url "https://github.com/emacs-evil/goto-chg")
+ ("grep+" :url "https://github.com/emacsmirror/grep-plus")
+
("guru-mode" :url "https://github.com/bbatsov/guru-mode")
("haml-mode" :url "https://github.com/nex3/haml-mode")
@@ -94,15 +108,25 @@
;; ;; https://github.com/haskell/haskell-mode/releases/tag/17.2
;; :version-map ((nil "17.2" "e72677668f5fc7cc148008e885a0f256e245dd43")))
+ ("help+" :url "https://github.com/emacsmirror/help-plus")
+
+ ("help-fns+" :url "https://github.com/emacsmirror/help-fns-plus")
+
+ ("highlight" :url "https://github.com/emacsmirror/highlight")
+
("highlight-parentheses"
:url "https://git.sr.ht/~tsdh/highlight-parentheses.el"
:branch "main"
:readme "README.md")
+ ("hl-line+" :url "https://github.com/emacsmirror/hl-line-plus")
+
("htmlize" :url "https://github.com/hniksic/emacs-htmlize"
:ignored-files ("htmlize.el.html")
:release-branch "stable")
+ ("icicles" :url "https://github.com/emacsmirror/icicles")
+
("idris-mode" :url "https://github.com/idris-hackers/idris-mode"
:ignored-files ("test-data" "Makefile" "documentation.tex" "logo-small.png"
"idris-tests*.el")
@@ -112,12 +136,20 @@
:ignored-files ("test")
:news "CHANGELOG.md")
+ ("imenu+" :url "https://github.com/emacsmirror/imenu-plus")
+
+ ("info+" :url "https://github.com/emacsmirror/info-plus")
+
+ ("isearch+" :url "https://github.com/emacsmirror/isearch-plus")
+
("j-mode" :url "https://github.com/zellio/j-mode")
("julia-mode" :url "https://github.com/JuliaEditorSupport/julia-emacs"
:ignored-files ("julia-mode-tests.el" "logo.png")
:news "CHANGELOG.md")
+ ("lacarte" :url "https://github.com/emacsmirror/lacarte")
+
("lua-mode" :url "https://github.com/immerrr/lua-mode/"
:ignored-files ("test" "travis" "init-tryout.el"))
@@ -165,6 +197,8 @@
;; :dont-release "-dev\\'"
)
+ ("mouse+" :url "https://github.com/emacsmirror/mouse-plus")
+
("multiple-cursors" :url "https://github.com/magnars/multiple-cursors.el"
:ignored-files ("features"))
@@ -239,6 +273,8 @@
("web-mode" :url "https://github.com/fxbois/web-mode"
:ignored-files ("issues" "tests" "run.sh"))
+ ("window+" :url "https://github.com/emacsmirror/window-plus")
+
("with-editor" :url "https://github.com/magit/with-editor"
:ignored-files ("htmlxref.cnf" ".travis.yml" ".mailmap" "Makefile")
:doc "with-editor.texi")
[-- Attachment #3: Type: text/plain, Size: 24 bytes --]
--
Philip Kaludercic
^ permalink raw reply related [relevance 56%]
* Re: [External] : Re: NonGNU ELPA work
@ 2021-09-24 10:05 83% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-09-24 10:05 UTC (permalink / raw)
To: Drew Adams; +Cc: Stefan Monnier, emacs-devel@gnu.org
Drew Adams <drew.adams@oracle.com> writes:
>> I Cc'ed Drew to see if he is interested in cooperating.
>
> tl;dr More or less passively, sure.
> I'm not going to go to bat for it or overhaul it.
> Been there; tried that.
That shouldn't be necessary, from what I see, but I haven't experimented
a lot yet either.
> All of my code is GPL, and I've signed Emacs/FSF
> papers. I've said many times that any of it can
> be used in any way by Emacs.
Ok, I wasn't sure because 1. the libraries aren't part of ELPA 2. as
they are developed on EmacsWiki, I wasn't sure if there were any other
significant contributors.
> I've proposed many of the individual features
> to Emacs dev. The code is one thing; the ideas
> behind it are another - there are multiple ways
> to implement the latter (or similar). I don't
> care to re-implement, myself, and I have no
> special desire to "own" any of it.
>
> The main (probably unconscious) uptake of the
> ideas has been from 3rd-party libraries such
> as Helm (aka Anything), Ivy, etc. implementing
> features that Icicles originally introduced
> (typically long ago). Vanilla Emacs hasn't
> been much interested, IMO.
That is one of the reasons I am interested in seeing if they could be
added. I am part of a user-generation that's usually to lazy to install
new software manually, and instead limit myself to whatever is available
on various ELPAs. Not to defend this mentality, just mentioning it.
> I don't really understand what "NonGnu" means,
> though I've scanned emails that mention it.
> There's nothing non-GNU about my code, AFAIK.
> But what's in a name? ;-)
Nothing in particular, again I (falsely) assume there was a reason
against adding your packages to ELPA.
> My libraries that have a Version # of 0 do so
> because I didn't want to be bothered to update
> that field for no special reason, whenever any
> "version" (date) of the library could be used.
> I don't feel strongly about this; that's just
> the reason I did that.
I see. Date versioning works too, so this shouldn't be too much of an
issue.
> I don't use GIT to manage my code. I just post
> updates to EmacsWiki. Nearly all of my code
> used to be on MELPA, but they stopped pulling
> from Emacs Wiki (my pages on the wiki are
> locked to all but the wiki admins, FWIW).
>
> I've been clear that I have no problem with
> someone mirroring any of my code from the wiki
> to GIT repositories or whatever. I think at
> least some of the libraries have been mirrored.
> ___
>
> I don't have a lot of time to devote to helping
> with any mirroring and such. I intend to keep
> maintaining my code on EmacsWiki, when I make
> changes to it.
From what I see, this is already being done by the emacsmirror project.
> As for overlap or redefinition of vanilla
> constructs: yes, that's no doubt a problem if
> someone expects to somehow integrate it with
> Emacs. Loading some libraries redefines
> vanilla code. Users of the code need to know
> that.
>
> Most often a redefinition is because either
> (1) I think my definition is better (a
> replacement) or (2) my definition provides
> compatibility with multiple Emacs versions.
> Or both at the same time. For integration
> with Emacs, changes for #2 aren't needed.
I still hesitate, but as I haven't experimented with anything yet, I
don't want to give up because of this.
> Thank you for your suggestion. I don't expect
> anything to come of it, frankly. But anyone
> interested is welcome to reuse any bits of my
> code, or to look to it for ideas/inspiration
> when writing other code.
My suggestion would be to start out with a few popular libraries, such
as icicles, and see how that goes.
--
Philip Kaludercic
^ permalink raw reply [relevance 83%]
* Re: Cleaning up rcirc
@ 2021-09-25 16:34 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-09-25 16:34 UTC (permalink / raw)
To: Tassilo Horn; +Cc: emacs-devel
Tassilo Horn <tsdh@gnu.org> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>>> However, irc.gitter.im again broke at some point in time and did not
>>> reconnect. In the server buffer, there's just
>>>
>>> 01:23 !!! irc.gitter.im: connection broken by remote peer (closed)
>>>
>>> A manual /reconnect worked fine.
>>
>> Thank you for the report, I will look into this specific issue. Were
>> there any other messages about previous reconnection attempts?
>
> Nope, there last message before "connection broken by remote peer" was
> from my login days before.
I just pushed a few commits onto master that use process-status instead
of the sentinel message. From what I gather, there are cases where the
process state may change without this being detected by analysing the
message the sentinel function receives.
> Bye,
> Tassilo
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: [ELPA] New package: ERC
@ 2021-09-26 19:28 99% ` Philip Kaludercic
1 sibling, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-09-26 19:28 UTC (permalink / raw)
To: Amin Bandali; +Cc: Lars Ingebrigtsen, emacs-erc, Stefan Monnier, emacs-devel
Amin Bandali <bandali@gnu.org> writes:
> On this topic, I've briefly seen philipk's proposal for `compat.el' on
> emacs-devel, but I'm not yet sure if it's meant to tend to the needs
> of individual packages like ERC and add funs/vars on request. So for
> ERC's purposes it might be better to revive and use `erc-compat.el'.
It certainly could, the question is only if the functionality of a 300+
line file should be copied into a general-purpose compatibility library.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: [ELPA] New package: ERC
@ 2021-09-27 10:22 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-09-27 10:22 UTC (permalink / raw)
To: Amin Bandali; +Cc: Lars Ingebrigtsen, emacs-erc, Stefan Monnier, emacs-devel
Amin Bandali <bandali@gnu.org> writes:
> Philip Kaludercic writes:
>
>> Amin Bandali <bandali@gnu.org> writes:
>>
>>> On this topic, I've briefly seen philipk's proposal for `compat.el' on
>>> emacs-devel, but I'm not yet sure if it's meant to tend to the needs
>>> of individual packages like ERC and add funs/vars on request. So for
>>> ERC's purposes it might be better to revive and use `erc-compat.el'.
>>
>> It certainly could, the question is only if the functionality of a 300+
>> line file should be copied into a general-purpose compatibility library.
>
> By "300+ line file" you mean `iso8601.el'? If so, I would indeed not
> expect `compat.el' to duplicate all of that. However, I wonder if
> `compat.el' may be able to house some funs/vars needed to port
> `iso8601.el' to older Emacsen?
That should certainly be possible. I don't think iso8601 depends on
anything that wasn't possible with Emacs 24.
> I haven't had a close look at it, nor at the time-related changes in
> Emacs 27, to know if this would be doable in a reasonable way.
> Perhaps Lars might.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: [ELPA] New package: ERC
@ 2021-09-27 10:23 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-09-27 10:23 UTC (permalink / raw)
To: Amin Bandali
Cc: Lars Ingebrigtsen, emacs-devel, emacs-erc, Stefan Kangas,
Stefan Monnier
Amin Bandali <bandali@gnu.org> writes:
> Stefan Kangas writes:
>
>> Amin Bandali <bandali@gnu.org> writes:
>>
>>> Oh, right. I just recalled that we used to have an `erc-compat.el'
>>> that we obsoleted last year. I think I will revive that and put it
>>> back into lisp/erc/, and that the additional things I wanted in there.
>>
>> I just marked the unused stuff in there explicitly obsolete, so it
>> should be easy to just move it out of obsolete/ and continue from there.
>>
>> Perhaps it is better to do it before Emacs 28.1 to avoid any confusion,
>> even if the only concrete step is to move the file out of obsolete/.
>>
>
> Thanks. I've been a bit torn about restoring `erc-compat.el'
> vs. potentially working something out with Philip's `compat.el'.
> However, I suppose if we're very close to `emacs-28' being cut (as in
> days ?) and if `compat.el' is currently mainly only a proposal and not
> being urgently added,
To clarify, compat would be an ELPA package (and if accepted, it
wouldn't be added before Emacs 28.1 is released).
>it would probably be better for me to go ahead
> and restore `erc-compat.el' sooner rather than later (in a day or two)
> and do what we already used to for ERC in the past anyway.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Shorthands have landed on master
@ 2021-09-27 22:40 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-09-27 22:40 UTC (permalink / raw)
To: João Távora
Cc: Adam Porter, emacs-devel, Stefan Kangas, Dmitry Gutov
João Távora <joaotavora@gmail.com> writes:
> Hello all.
>
> Anyway, as you may have noticed, "Shorthands" have landed on master.
> Please check out the NEWS entry and the manual section on "Shorthands".
>
> For the impatient, I leave with with a tiny animated gif.
From what I see, elisp-shorthands only allows a shorter prefix to be
mapped to a longer prefix, right? So this doesn't allow me to use cl-lib
without the cl- prefix, or remove the compat-- prefix from compatibility
functions?
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Emacs default bindings
@ 2021-09-28 6:58 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-09-28 6:58 UTC (permalink / raw)
To: Stefan Kangas
Cc: danflscr, rms, lokedhs, yantar92, emacs-devel, monnier,
Dmitry Gutov, Eli Zaretskii
Stefan Kangas <stefankangas@gmail.com> writes:
> Dmitry Gutov <dgutov@yandex.ru> writes:
>
>> Unless anybody has strong objections, I'll flip the default tomorrow.
>
> I still think the default should only be flipped for prog-mode.
>
> When writing prose, it does not help to highlight the parens, in fact it
> is distracting.
How come? The only case where I can think of this being distracting is
when using emoticons that may contain parentheses.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Shorthands have landed on master
@ 2021-09-28 7:15 88% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-09-28 7:15 UTC (permalink / raw)
To: João Távora
Cc: Adam Porter, Dmitry Gutov, Stefan Kangas, emacs-devel
João Távora <joaotavora@gmail.com> writes:
> On Mon, Sep 27, 2021 at 11:40 PM Philip Kaludercic <philipk@posteo.net> wrote:
>>
>> João Távora <joaotavora@gmail.com> writes:
>>
>> > Hello all.
>> >
>> > Anyway, as you may have noticed, "Shorthands" have landed on master.
>> > Please check out the NEWS entry and the manual section on "Shorthands".
>> >
>> > For the impatient, I leave with with a tiny animated gif.
>>
>> From what I see, elisp-shorthands only allows a shorter prefix to be
>> mapped to a longer prefix, right? So this doesn't allow me to use cl-lib
>> without the cl- prefix,
>
> You need to have _some_ prefix. It cannot be of 0 length. Best
> you can do is '-loop' and '-destructuring-bind', for example.
>
> In fact, I lie. You _can_ map 'loop' to 'cl-loop' explicitly.
> 'loop' is the shorthand. 'cl-loop' is still the symbol.
> But you have to do it symbol by symbol.
>
> That's because I've purposely turned off "freer" renamings in
> favor of prefixes, simplicity and read speed. But they are
> not impossible.
I see. Do you think it would make sense to use predefined shorthand
groups, in case someone *would* want to use cl-lib without the prefix?
>> or remove the compat-- prefix from compatibility
>> functions?
>
> It's too late in the day for me to understand what you mean by
> "remove" here :-) You must first understand what shorthands are:
> they are merely file-local aliases to symbols which keep their
> full names.
This was in reference to the compat.el discussion from a few days
ago. It was mentioned that shorthands might provide an alternative to
aliasing function definitions. But this doesn't make much sense, if a
prefix has to be used, short or long: I want to call
(macroexp-file-name), not (co-macroexp-file-name), (~macroexp-file-name)
or (compat--macroexp-file-name) to provide transparent compatibility.
> Does this help in answering your question?
After trying out
;; elisp-shorthands: (("" . "cl-"))
I saw what went wrong and I understand why. On that topic, I think the
behaviour was inadequate, because a lot of unrelated commands also
broke that might become annoying.
> If it doesn't, provide a toy example with files and code in it,
> and illustrate clearly what you would like to be able to write,
> but can't (right now) Then maybe I can say if shorthands can
> help you.
>
> João
>
>
--
Philip Kaludercic
^ permalink raw reply [relevance 88%]
* Re: Shorthands have landed on master
@ 2021-09-28 9:22 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-09-28 9:22 UTC (permalink / raw)
To: João Távora
Cc: Adam Porter, Dmitry Gutov, Stefan Kangas, emacs-devel
João Távora <joaotavora@gmail.com> writes:
>> This was in reference to the compat.el discussion from a few days
>> ago. It was mentioned that shorthands might provide an alternative to
>> aliasing function definitions. But this doesn't make much sense, if a
>> prefix has to be used, short or long: I want to call
>> (macroexp-file-name), not (co-macroexp-file-name), (~macroexp-file-name)
>> or (compat--macroexp-file-name) to provide transparent compatibility.
>
> If I understand this right, then I think you may solve it similarly to the
> cl- situation.
>
> But you understand that, for the moment, shorthands are only supported in
> Emacs 28, right? Not sure where (in which versions) the library you're
> intending to write would be loaded. If that library is loaded in Emacs 27,
> elisp-shorthands is simply ignored and the file is loaded normally.
Yes, my idea was to use shorthands for versions greater or equal to
28.1.
> João
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: vc-fossil to non-gnu elpa?
@ 2021-09-28 12:06 90% ` Philip Kaludercic
1 sibling, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-09-28 12:06 UTC (permalink / raw)
To: Alfred M. Szmidt
Cc: rms, bandali, emacs-devel, stefankangas, larsi, eliz, monnier
"Alfred M. Szmidt" <ams@gnu.org> writes:
> [Lets try this again and send it to emacs-devel@. Sorry for the noise.]
>
> So trying to get back to adding vc-fossil to non-GNU ELPA, I tried to
> follow the instructions in the README.org, added this to elpa-packages
>
> ("vc-fossil" :url "https://github.com/ams/vc-fossil")
>
> And then did,
>
> ~/nongnu-elpa $ gmake -f GNUmakefile build/vc-fossil
> emacs --batch -l /home/ams/nongnu-elpa/admin/elpa-admin.el \
> -f elpaa-batch-make-one-package vc-fossil
> Cloning branch vc-fossil:
> +refs/heads/*:refs/remotes/origin/Preparing worktree (new branch 'elpa/vc-fossil')
> HEAD is now at f365e4389 vc-fossil.el: Update from fossil.
> *
>
> ======== Building tarball archive-devel/vc-fossil-20210928.0...tar...
> Build error for archive-devel/vc-fossil-20210928.0...tar: (error "Invalid version syntax: `20210928.0..'")
> ######## Build of package archive-devel/vc-fossil-20210928.0...tar FAILED!!
> ======== Building tarball archive/vc-fossil-20210928.tar...
> ######## Built new package archive/vc-fossil-20210928.tar!
>
> The error message is strange, and I don't understand it. Any idea
> what is going on?
It seems to build on my system:
icterid$ make build/vc-fossil
emacs --batch -l /home/philip/Code/src/nongnu/admin/elpa-admin.el \
-f elpaa-batch-make-one-package vc-fossil
Cloning branch vc-fossil:
+refs/heads/*:refs/remotes/origin/Preparing worktree (new branch 'elpa/vc-fossil')
HEAD is now at 7815c30d7 vc-fossil.el: Update from fossil.
*
======== Building tarball archive-devel/vc-fossil-20210928.0.20210928.73744.tar...
######## Built new package archive-devel/vc-fossil-20210928.0.20210928.73744.tar!
======== Building tarball archive/vc-fossil-20210928.tar...
######## Built new package archive/vc-fossil-20210928.tar!
Did you change the history or do you have a local commit with
"20210928.0.." as a version number?
--
Philip Kaludercic
^ permalink raw reply [relevance 90%]
* Re: vc-fossil to non-gnu elpa?
@ 2021-09-28 12:35 96% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-09-28 12:35 UTC (permalink / raw)
To: Alfred M. Szmidt
Cc: rms, bandali, emacs-devel, stefankangas, larsi, eliz, monnier
[-- Attachment #1: Type: text/plain, Size: 1502 bytes --]
"Alfred M. Szmidt" <ams@gnu.org> writes:
> It seems to build on my system:
>
> icterid$ make build/vc-fossil
> emacs --batch -l /home/philip/Code/src/nongnu/admin/elpa-admin.el \
> -f elpaa-batch-make-one-package vc-fossil
> Cloning branch vc-fossil:
> +refs/heads/*:refs/remotes/origin/Preparing worktree (new branch 'elpa/vc-fossil')
> HEAD is now at 7815c30d7 vc-fossil.el: Update from fossil.
> *
>
> ======== Building tarball archive-devel/vc-fossil-20210928.0.20210928.73744.tar...
> ######## Built new package archive-devel/vc-fossil-20210928.0.20210928.73744.tar!
> ======== Building tarball archive/vc-fossil-20210928.tar...
> ######## Built new package archive/vc-fossil-20210928.tar!
>
> Did you change the history or do you have a local commit with
> "20210928.0.." as a version number?
>
> No, but could it be how the string is constructed?
ELPA uses functions based on version-to-list to find the commit that the
tarball is based on. From the error message you got, it might be that
you were using an invalid versioning scheme. Consider how
(version-to-list "1.0.0") ; => (1 0 0)
but
(version-to-list "1.0..0")
throws an error.
> ======== Building tarball archive-devel/vc-fossil-20210928.0.20210928.73744.tar...
> ^^^^^^^^ ^^^^^
> If that those two parts are missing/empty then you will get vc-fossil-20210928.0...tar...
What do you mean, I seem to have everything necessary in the tarball:
[-- Attachment #2: vc-fossil.tar --]
[-- Type: application/x-tar, Size: 30720 bytes --]
[-- Attachment #3: Type: text/plain, Size: 25 bytes --]
--
Philip Kaludercic
^ permalink raw reply [relevance 96%]
* Re: ELPA: New package: nano-theme
@ 2021-09-28 17:47 79% ` Philip Kaludercic
2021-10-01 9:59 97% ` Philip Kaludercic
0 siblings, 2 replies; 200+ results
From: Philip Kaludercic @ 2021-09-28 17:47 UTC (permalink / raw)
To: Nicolas P. Rougier (inria); +Cc: emacs-devel
"Nicolas P. Rougier (inria)" <nicolas.rougier@inria.fr> writes:
> Dear all,
>
> I would like to submit a new package to ELPA which is a theme based on
> Material colors (https://material.io/) for the light version and Nord
> colors (https://www.nordtheme.com/) for the dark version. The theme
> itself is made of (only) 6 different faces and the rationale is here:
> https://arxiv.org/abs/2008.06030
>
> The theme is hosted at https://github.com/rougier/nano-theme and the
> README displays what it looks like. Note that the theme exploits face
> inheritance a lot and Eli explained me that it might degrade
> performances. I don't know if this needs to be fixed.
I see that a lot of faces inherit from nano-default, nano-strong,
nano-faded, etc. Wouldn't it make more sense to inherit from built-in
faces and then let default, bold, shadow, etc. inherit from these faces.
Furthermore, I wonder why you define the commands nano-light and
nano-dark, instead of two themes, nano-light and nano-dark (along the
same lines of what modus-themes currently does). You could also turn
nano-setup into a custom theme, so that the user can easily enable and
disable it.
A few more points:
- Should the font really be part of the face? I think it makes sense to
recommend a few fonts, but it is unconventional to add it as part of a
theme.
- When you are only using one branch of a if expression, prefer
when. Instead of (if (not ...) ...), prefer unless.
- Lines 363ff. seem to be indented unconventionally. Maybe add a
.dir-locals.el to make sure everyone is using the same whitespace
configuration.
Also, as you depend on at least 27.1, you probably don't have to check
if custom-theme-load-path is defined. The same applies to tooltip-mode,
scroll-bar-mode and tool-bar-mode. What you are doing looks more like
configuration code, where you want to make sure that a .emacs works on
older versions of Emacs.
> Best,
> Nicolas
>
>
--
Philip Kaludercic
^ permalink raw reply [relevance 79%]
* Re: ELPA: New package: nano-theme
@ 2021-09-28 18:37 96% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-09-28 18:37 UTC (permalink / raw)
To: Nicolas P. Rougier (inria); +Cc: emacs-devel
"Nicolas P. Rougier (inria)" <nicolas.rougier@inria.fr> writes:
> Many thanks for the review and the feedback.
>
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> "Nicolas P. Rougier (inria)" <nicolas.rougier@inria.fr> writes:
>
>> I see that a lot of faces inherit from nano-default, nano-strong,
>> nano-faded, etc. Wouldn't it make more sense to inherit from
>> built-in
>> faces and then let default, bold, shadow, etc. inherit from these
>> faces.
>
> Having such names helps a lot when you assign faces. For example, when
> I define font-lock-comment-face, I want to make it faded and it feels
> more natural and explicit to inherit from nano-faded. Also, is there
> an associated computational cost when defining a new face?
There has to be *some* computation, but thinking again about this, it
probably shouldn't matter much if you define bold and let everything
inherit from bold or if you define nano-strong and inherit from
nano-strong.
>> Furthermore, I wonder why you define the commands nano-light and
>> nano-dark, instead of two themes, nano-light and nano-dark (along
>> the
>> same lines of what modus-themes currently does). You could also turn
>> nano-setup into a custom theme, so that the user can easily enable
>> and
>> disable it.
>
> Maybe I need to read the documentation on what a theme can set. For
> example, I set the face for the minibuffer (0 & 1) and echo area (0 &
> 1) and I wasn't sure how to specify this in a theme. Same for
> underline to be set at descent line, etc.
Not directly, but you could define a custom option/minor mode that is
activated as part of the theme to change these things too.
>> A few more points:
>>
>> - Should the font really be part of the face? I think it makes sense
>> to
>> recommend a few fonts, but it is unconventional to add it as
>> part of a
>> theme.
>
> I agree this might be unconventional but since you can specify a font
> family for each face, why not use it? And user can still choose its
> own font stack.
It was always my impression that faces are for users to set.
>> - When you are only using one branch of a if expression, prefer
>> when. Instead of (if (not ...) ...), prefer unless.
>
> Thanks, I'll do that.
>
>
>> - Lines 363ff. seem to be indented unconventionally. Maybe add a
>> .dir-locals.el to make sure everyone is using the same
>> whitespace
>> configuration.
>
> Not sure what you mean by add a .dir-locals.el.
> Can you give me a pointer to the documentation?
See (emacs) Directory Variables.
>> Also, as you depend on at least 27.1, you probably don't have to
>> check
>> if custom-theme-load-path is defined. The same applies to
>> tooltip-mode,
>> scroll-bar-mode and tool-bar-mode. What you are doing looks more
>> like
>> configuration code, where you want to make sure that a .emacs works
>> on
>> older versions of Emacs.
>
> Thansk, didn't know, I'll correct it.
--
Philip Kaludercic
^ permalink raw reply [relevance 96%]
* Re: ELPA: New package: nano-theme
@ 2021-09-29 6:24 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-09-29 6:24 UTC (permalink / raw)
To: Nicolas P. Rougier (inria); +Cc: emacs-devel
"Nicolas P. Rougier (inria)" <nicolas.rougier@inria.fr> writes:
>>>> Furthermore, I wonder why you define the commands nano-light and
>>>> nano-dark, instead of two themes, nano-light and nano-dark (along
>>>> the
>>>> same lines of what modus-themes currently does). You could also
>>>> turn
>>>> nano-setup into a custom theme, so that the user can easily enable
>>>> and
>>>> disable it.
>>>
>>> Maybe I need to read the documentation on what a theme can set. For
>>> example, I set the face for the minibuffer (0 & 1) and echo area (0
>>> &
>>> 1) and I wasn't sure how to specify this in a theme. Same for
>>> underline to be set at descent line, etc.
>>
>> Not directly, but you could define a custom option/minor mode that
>> is
>> activated as part of the theme to change these things too.
>
> But then you need to load the theme and activate the minor mode, do
> you?. Having a (nano-light) command is more direct in my opinion and
> in any case, user is free to only load the theme the regular way.
No, a custom theme can enable a custom option (via
custom-theme-set-variables), and since every minor mode is also a user
option, you can enable a minor mode as part of a theme.
>>>> - Lines 363ff. seem to be indented unconventionally. Maybe add a
>>>> .dir-locals.el to make sure everyone is using the same
>>>> whitespace
>>>> configuration.
>
> I had a mix of space and tabs for unknown reason. Hopefully it has
> been fixed.
>
> Nicolas
>
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: vc-fossil to non-gnu elpa?
@ 2021-09-30 14:22 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-09-30 14:22 UTC (permalink / raw)
To: Stefan Kangas
Cc: rms, bandali, emacs-devel, Alfred M. Szmidt, Stefan Monnier,
larsi, eliz
Stefan Kangas <stefan@marxist.se> writes:
> "Alfred M. Szmidt" <ams@gnu.org> writes:
>
>> Small suggestion, it would be a good idea to add a time-stamp to the
>> https://elpa.nongnu.org/nongnu/ page, and in general to any
>> auto-generated page. Hard to know when it was last updated or not.
>
> This would be fixed by the second of the attached patches.
>
> But I have two issues that maybe Stefan M can help with.
>
> A) It seems like there are two versions of the elpa-admin branch, or at
> least that the one in elpa.git is out of synch/outdated?
>
> B) I can't push to elpa-admin from nongnu.git. Am I supposed to do
> that?
I am not sure, but elpa-admin is actually part of elpa.git, have you
tried to push the changes from that checkout?
> Probably I'm just confused by this whole worktree business.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: flymake-kondor on NonGNU ELPA
@ 2021-10-01 8:59 94% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-10-01 8:59 UTC (permalink / raw)
To: Manuel Uberti; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 270 bytes --]
Manuel Uberti <manuel.uberti@inventati.org> writes:
> Hi,
>
> would it be possible to add flymake-kondor[1] on NonGNU ELPA? It's
> basically a Flymake backend to use clj-kondo[2] (a Clojure linter)
> with Flymake.
I have tried building it, and everything seems fine:
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-elpa-packages-flymake-kondor-Add-package.patch --]
[-- Type: text/x-diff, Size: 669 bytes --]
From cf47130161348e09c6faa331088aec54187dc661 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Fri, 1 Oct 2021 10:57:23 +0200
Subject: [PATCH] * elpa-packages (flymake-kondor): Add package
---
elpa-packages | 2 ++
1 file changed, 2 insertions(+)
diff --git a/elpa-packages b/elpa-packages
index 616a1f921..764320cbe 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -43,6 +43,8 @@
:ignored-files ("lib" "scripts")
:doc "doc/build/texinfo/evil.texi")
+ ("flymake-kondor" :url "https://github.com/turbo-cafe/flymake-kondor")
+
("git-commit" :url "https://github.com/magit/magit"
:lisp-dir "lisp"
:ignored-files
--
2.30.2
[-- Attachment #3: Type: text/plain, Size: 492 bytes --]
> I am not sure about the maintainer's desire, but he/she left me merge
> some changes and cut a new release a couple of months ago so I guess
> this should be fine.
>
> Note that he/she doesn't seem to be very active on GitHub at the
> moment, though, and I was not able to reach him/her via email
> (admin@turbocafe.in.eu.org does not seem to be working any more).
>
>
> [1] https://github.com/turbo-cafe/flymake-kondor
> [2] https://github.com/clj-kondo/clj-kondo
--
Philip Kaludercic
^ permalink raw reply related [relevance 94%]
* Re: ELPA: New package: nano-theme
2021-09-28 17:47 79% ` Philip Kaludercic
@ 2021-10-01 9:59 97% ` Philip Kaludercic
1 sibling, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-10-01 9:59 UTC (permalink / raw)
To: Nicolas P. Rougier (inria); +Cc: emacs-devel
Philip Kaludercic <philipk@posteo.net> writes:
> "Nicolas P. Rougier (inria)" <nicolas.rougier@inria.fr> writes:
>
>> Dear all,
>>
>> I would like to submit a new package to ELPA which is a theme based on
>> Material colors (https://material.io/) for the light version and Nord
>> colors (https://www.nordtheme.com/) for the dark version. The theme
>> itself is made of (only) 6 different faces and the rationale is here:
>> https://arxiv.org/abs/2008.06030
>>
>> The theme is hosted at https://github.com/rougier/nano-theme and the
>> README displays what it looks like. Note that the theme exploits face
>> inheritance a lot and Eli explained me that it might degrade
>> performances. I don't know if this needs to be fixed.
>
> I see that a lot of faces inherit from nano-default, nano-strong,
> nano-faded, etc. Wouldn't it make more sense to inherit from built-in
> faces and then let default, bold, shadow, etc. inherit from these faces.
>
> Furthermore, I wonder why you define the commands nano-light and
> nano-dark, instead of two themes, nano-light and nano-dark (along the
> same lines of what modus-themes currently does). You could also turn
> nano-setup into a custom theme, so that the user can easily enable and
> disable it.
I see nano-theme was added despite still providing functions for themes,
instead of using customize (and a few other points I raised). Have I
missed an explanation as to why this decision was made? Did it turn out
to not be possible? It seems regrettable to provide a theme on ELPA that
evades the conventional theme infrastructure, especially considering
that ELPA currently doesn't provide that many themes to begin with.
> A few more points:
>
> - Should the font really be part of the face? I think it makes sense to
> recommend a few fonts, but it is unconventional to add it as part of a
> theme.
> - When you are only using one branch of a if expression, prefer
> when. Instead of (if (not ...) ...), prefer unless.
> - Lines 363ff. seem to be indented unconventionally. Maybe add a
> .dir-locals.el to make sure everyone is using the same whitespace
> configuration.
>
> Also, as you depend on at least 27.1, you probably don't have to check
> if custom-theme-load-path is defined. The same applies to tooltip-mode,
> scroll-bar-mode and tool-bar-mode. What you are doing looks more like
> configuration code, where you want to make sure that a .emacs works on
> older versions of Emacs.
>
>> Best,
>> Nicolas
--
Philip Kaludercic
^ permalink raw reply [relevance 97%]
* Re: ELPA: New package: nano-theme
@ 2021-10-01 10:15 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-10-01 10:15 UTC (permalink / raw)
To: Nicolas P. Rougier (inria); +Cc: emacs-devel
"Nicolas P. Rougier (inria)" <nicolas.rougier@inria.fr> writes:
> I cannot speak for decision but I intend to address all your comments
> for next version (next week most probably).
Ok, that is good to hear. I was just surprised to see the package in
elpa.git all of a sudden.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: project-find-file: switch to include non-tracked files
@ 2021-10-04 11:24 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-10-04 11:24 UTC (permalink / raw)
To: Manuel Uberti; +Cc: Dmitry Gutov, emacs-devel
Manuel Uberti <manuel.uberti@inventati.org> writes:
> Sorry to bring up this again, but is there anything that can be done on this?
>
> The proposed solution with C-u C-x p f seems very reasonable to me, I
> don't know what others project.el users think though.
I agree, my only concern is if there might be a better use for C-u that
we aren't seeing right now.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: flymake-kondor on NonGNU ELPA
@ 2021-10-04 12:08 99% ` Philip Kaludercic
2021-10-08 11:36 99% ` Philip Kaludercic
1 sibling, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-10-04 12:08 UTC (permalink / raw)
To: Manuel Uberti; +Cc: emacs-devel
Manuel Uberti <manuel.uberti@inventati.org> writes:
> On 01/10/21 10:59, Philip Kaludercic wrote:
>> I have tried building it, and everything seems fine[.]
>
> Is there anything more from my side you need for this?
The package seems to have no issues, clj-kondo is free software, so I
don't think so.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* [ELPA] Add compat.el
2021-09-20 23:35 79% Proposal: Forwards-Compatibility Library for Emacs Philip Kaludercic
` (4 preceding siblings ...)
@ 2021-10-04 23:00 75% ` Philip Kaludercic
2021-10-07 7:03 95% ` Old (static) builds of Emacs Philip Kaludercic
` (2 more replies)
5 siblings, 3 replies; 200+ results
From: Philip Kaludercic @ 2021-10-04 23:00 UTC (permalink / raw)
To: emacs-devel
Hello again,
I have been working on compat.el over the last week, and have written a
number of tests. The source code has been uploaded here:
https://git.sr.ht/~pkal/compat
The library should be usable in it's current state, but I'd be
interested to hear from other people and developers too. There might be
missing functions or macros, edge cases that could be added to the
tests, etc. that could be improved.
Finally, compat.el now ends with these lines:
--8<---------------cut here---------------start------------->8---
;; ;;;; Ensure NonGNU ELPA is in `package-archives'
;; (with-eval-after-load 'package
;; (unless (or (rassoc "https://elpa.nongnu.org/nongnu/" package-archives)
;; (rassoc "http://elpa.nongnu.org/nongnu/" package-archives)
;; (rassoc "https://elpa.nongnu.org/nongnu-devel/" package-archives)
;; (rassoc "http://elpa.nongnu.org/nongnu-devel/" package-archives))
;; (add-to-list 'package-archives '("nongnu" . "https://elpa.nongnu.org/nongnu/"))))
;; To ensure that compat.el is loaded as soon as possible, a require
;; call is inserted directly into the autoload file:
;;;###autoload (require 'compat)
--8<---------------cut here---------------end--------------->8---
The first block ensures that NonGNU ELPA is added to package-archives,
in the hope that if ELPA packages were to use compat.el, older versions
would automatically be configured to use NonGNU ELPA. The upside is
wider adoption, the downside is that this is pretty invasive (an
alternative would be to check if package-archives is unmodified, and
only update it in that case).
The second block would automatically require compat.el in the autoload
file, so as to avoid manual (require 'compat) statements in packages
that use the library. I haven't tested this part extensively yet, but
could there be something that this might break?
Philip Kaludercic <philipk@posteo.net> writes:
> Hi,
>
> over the last few days I have been working on a forwards-compatibility
> library for Emacs, here is a first iteration:
>
> The idea is to allow developers who don't want to break backwards
> compatibility to use newer functionality that wasn't provided in older
> versions of Emacs. This version tries to implement as much as possible
> from Emacs 24.2 onwards.
>
> [...]
--
Philip Kaludercic
^ permalink raw reply [relevance 75%]
* Re: Elisp LSP Server
@ 2021-10-05 9:50 99% ` Philip Kaludercic
0 siblings, 2 replies; 200+ results
From: Philip Kaludercic @ 2021-10-05 9:50 UTC (permalink / raw)
To: Po Lu; +Cc: Phil Sainty, emacs-devel, Ag Ibragimov, rms, joaotavora
Po Lu <luangruo@yahoo.com> writes:
> Ag Ibragimov <agzam.ibragimov@gmail.com> writes:
>
>> Another reason: VSCode. The damn thing is spreading like a
>> disease. And now it's even possible to browse code on GitHub, in a
>> browser, by simply pressing <.> (the dot). I would love to be able to
>> comfortably browse through elisp code without having to clone it
>> locally, but none of the existing VSCode Lisp plugins are any good.
>> For example, there's no equivalent of imenu for Lisp files. You can't
>> jump to a given function.
>
> Isn't the code behind that particular feature proprietary?
In what sense? GitHub is inherently proprietary, so yes, but what
about this specific feature is different.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Elisp LSP Server
@ 2021-10-05 11:46 98% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-10-05 11:46 UTC (permalink / raw)
To: Po Lu; +Cc: Phil Sainty, joaotavora, Ag Ibragimov, rms, emacs-devel
Po Lu <luangruo@yahoo.com> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Po Lu <luangruo@yahoo.com> writes:
>>
>>> Ag Ibragimov <agzam.ibragimov@gmail.com> writes:
>>>
>>>> Another reason: VSCode. The damn thing is spreading like a
>>>> disease. And now it's even possible to browse code on GitHub, in a
>>>> browser, by simply pressing <.> (the dot). I would love to be able to
>>>> comfortably browse through elisp code without having to clone it
>>>> locally, but none of the existing VSCode Lisp plugins are any good.
>>>> For example, there's no equivalent of imenu for Lisp files. You can't
>>>> jump to a given function.
>>>
>>> Isn't the code behind that particular feature proprietary?
>>
>> In what sense? GitHub is inherently proprietary, so yes, but what
>> about this specific feature is different.
>
> I think it is dangerous for Emacs to "integrate" with such proprietary
> software. It would make people gravitate towards that software.
That yes, but that is an inherent problem of LSP (e.g. see how VSCode
can automatically download and run a propitiatory LSP server like
Pylance), and not the "." command itself.
I think a better solution to Ag's problem is to make editing online
repositories easier, without to manually clone a directory every time.
--
Philip Kaludercic
^ permalink raw reply [relevance 98%]
* Re: ELPA: New package: nano-modeline
@ 2021-10-06 15:38 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-10-06 15:38 UTC (permalink / raw)
To: Nicolas P. Rougier (inria); +Cc: emacs-devel
"Nicolas P. Rougier (inria)" <nicolas.rougier@inria.fr> writes:
> Dear all,
Hi again,
> I would like to submit a new package to ELPA which is an adaptive
> modeline (depending on major-mode) that can go on top (header-line) or
> bottom (mode-line). It makes use of dedicated faces for active /
> inactive states.
>
> The project is hosted at https://github.com/rougier/nano-modeline and
> the
> README displays what it looks like.
Are you sure you want to call
(nano-modeline)
when loading the package? Also, wouldn't it make sense to provide the
functionality in terms of a (global) minor mode, the user can activate
or deactivate?
Also, some functions (e.g. nano-modeline-compose) seem to have
indentation issues.
> Best,
> Nicolas
>
>
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: ELPA: New package: nano-modeline
@ 2021-10-06 18:50 93% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-10-06 18:50 UTC (permalink / raw)
To: Nicolas P. Rougier (inria); +Cc: emacs-devel
"Nicolas P. Rougier (inria)" <nicolas.rougier@inria.fr> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Are you sure you want to call
>>
>> (nano-modeline)
>
> Not at all, I can remove the autoload.
>
>> when loading the package? Also, wouldn't it make sense to provide
>> the
>> functionality in terms of a (global) minor mode, the user can
>> activate
>> or deactivate?
>
> It might be possible to make it a minor mode (with some extra work)
> but it seems counter-intuitive (to me) to have this as a
> minor-mode. But I've no strong opinion actually.
How come? A minor mode usually modifies the behaviour or appearance of
Emacs. Think of menu-bar-mode, scroll-bar-mode, etc.
But the main reason I mention this is that a minor mode is
reversible. If someone were to download nano-modeline and try it out,
they would have to restart their Emacs session to reset it.
(I wrote an text that represents MY (not necessarily the views of this
list, or of the emacs developers) views on the topic here:
http://ruzkuku.com/texts/emacs-style.html. Maybe that might help you to
understand where I am coming from.)
--
Philip Kaludercic
^ permalink raw reply [relevance 93%]
* Re: Elisp LSP Server
@ 2021-10-06 21:22 70% ` Philip Kaludercic
1 sibling, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-10-06 21:22 UTC (permalink / raw)
To: Richard Stallman; +Cc: emacs-devel
Richard Stallman <rms@gnu.org> writes:
> [[[ To any NSA and FBI agents reading my email: please consider ]]]
> [[[ whether defending the US Constitution against all enemies, ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> > > I think it is dangerous for Emacs to "integrate" with such proprietary
> > > software. It would make people gravitate towards that software.
>
> Po Lu is right.
>
> > That yes, but that is an inherent problem of LSP (e.g. see how VSCode
> > can automatically download and run a propitiatory LSP server like
> > Pylance), and not the "." command itself.
>
> Can you please explain the problem that you're talking about? If it
> is true that LSP inherently tends to use nonfree LSP servers, then
> using LSP is inherently a problem, and maybe we should not include
> that feature in Emacs at all.
I don't think that this is currently the case, most LSP servers I know
of are free software.
The difference between Emacs (at least Eglot) and other LSP
implementations, is that the latter can download servers automatically.
This is done without regard to the license, as projects like VSCode are
not focused on software freedom. The intent is to take care of setting
up a server without the user having to care, but the effect is that
actual programs, possibly propitiatory, are being downloaded and run on
the host system.
> Or can we fix that problem? Maybe loading nonfree servers is not
> totally inherent -- maybe we can arrange to avoid it.
Of course. Currently the problem doesn't exist to begin with, since LSP
servers have to be installed manually for Emacs. If LSP clients for
Emacs were to automatically configure a server, then I do think that the
licensing should be seriously taken into consideration.
> > I think a better solution to Ag's problem is to make editing online
> > repositories easier, without to manually clone a directory every time.
>
> Would you spell out in more detail what you're thinking of? Perhaps this
> would be a solution, but what is the solution, and what is the problem?
The problem is when you are browsing the online interface of a source
code repository, you might decide to want to make a change. This
introduces friction in the user's workflow, because you have to find a
directory, the repository has to be cloned into said directory, opened
in Emacs and then you can start working.
GitHub has introduced a feature where a in-browser Editor (derived from
VSCode as far as I see) can be invoked by literally at the press of a
button. Everything has been initialized, and you can make your changes
in a matter of seconds.
Replicating this for Emacs seems hard to do, but it is probably the
wrong approach. My guess would be that most people wouldn't want Emacs
in a browser. A solution could be to provide a script or command that
automatically clones a repository to a temporary directory and opens
Emacs (possibly by making use of emacsclient). The tricky part would be
to integrate this into a web browser, but my guess would be that this
could be done by use of a browser extension. This would recognize the
website, extract the git repository and start the script.
Haven't tried any of this, it is just brainstorming.
--
Philip Kaludercic
^ permalink raw reply [relevance 70%]
* Re: Elisp LSP Server
@ 2021-10-06 21:35 93% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-10-06 21:35 UTC (permalink / raw)
To: Richard Stallman; +Cc: emacs-devel
Richard Stallman <rms@gnu.org> writes:
> GitHub is inherently proprietary, so yes, but what
> > about this specific feature is different.
>
> GitHub has grave moral faults and has done great harm to the free
> software community, but saying it is "proprietary" is not well
> defined. That is because GitHub is not a program -- it is a service.
> The distinction of free vs proprietary is defined for programs, but it
> is not defined for services.
>
> [...]
>
> However, I think we're talking about a different kind of feature here.
Yes, that was phrased inadequately, but I do think that the term
"proprietary" is right here, because this is not about
GitHub-the-service but the editor that is actually running in the
browser. Apparently, you can even download extensions, which can also be
non-free.
The documentation[0] is supposed to explain the licensing situation, but
I cannot find a clear statement. And since VSCode is a propitiatory
fork of "Code" (the editor maintained by Microsoft, published on GitHub
under the MIT license), I assume that the in-browser-VSCode
("Codespaces") is propitiatory too.
[0] https://docs.github.com/en/github/site-policy/github-terms-for-additional-products-and-features#codespaces
--
Philip Kaludercic
^ permalink raw reply [relevance 93%]
* Old (static) builds of Emacs
2021-10-04 23:00 75% ` [ELPA] Add compat.el Philip Kaludercic
@ 2021-10-07 7:03 95% ` Philip Kaludercic
` (2 more replies)
2021-10-07 20:49 90% ` [ELPA] Add compat.el Philip Kaludercic
2021-10-15 19:08 83% ` Philip Kaludercic
2 siblings, 3 replies; 200+ results
From: Philip Kaludercic @ 2021-10-07 7:03 UTC (permalink / raw)
To: emacs-devel
Until now I have only been able to test the library using Emacs 27.2 and
Emacs 28.0.50/60. This doesn't seem like enough for a library that
actually targets older versions of Emacs.
My question is therefore: Does anyone know where to download old Emacs
builds? I have tried building 24.x and 25.x on my system, but it seems
(?) that changes in glibc prevent this from being done.
So before I have to set up virtual machines with older distributions, I
was wondering if anyone knew of an archive with pre-build, preferably
static, Emacs builds.
Philip Kaludercic <philipk@posteo.net> writes:
> Hello again,
>
> I have been working on compat.el over the last week, and have written a
> number of tests. The source code has been uploaded here:
>
> https://git.sr.ht/~pkal/compat
>
> The library should be usable in it's current state, but I'd be
> interested to hear from other people and developers too. There might be
> missing functions or macros, edge cases that could be added to the
> tests, etc. that could be improved.
--
Philip Kaludercic
^ permalink raw reply [relevance 95%]
* Re: Old (static) builds of Emacs
@ 2021-10-07 7:56 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-10-07 7:56 UTC (permalink / raw)
To: Michael Albinus; +Cc: emacs-devel
Michael Albinus <michael.albinus@gmx.de> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
> Hi Philip,
>
>> Until now I have only been able to test the library using Emacs 27.2 and
>> Emacs 28.0.50/60. This doesn't seem like enough for a library that
>> actually targets older versions of Emacs.
>>
>> My question is therefore: Does anyone know where to download old Emacs
>> builds? I have tried building 24.x and 25.x on my system, but it seems
>> (?) that changes in glibc prevent this from being done.
>>
>> So before I have to set up virtual machines with older distributions, I
>> was wondering if anyone knew of an archive with pre-build, preferably
>> static, Emacs builds.
>
> There's <https://hub.docker.com/r/silex/emacs>, which offers different
> Emacs versions in a docker container. I've never tried it myself, but
> maybe it helps you.
It might help, thank you!
> Best regards, Michael.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Old (static) builds of Emacs
@ 2021-10-07 20:29 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-10-07 20:29 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> So before I have to set up virtual machines with older distributions, I
>> was wondering if anyone knew of an archive with pre-build, preferably
>> static, Emacs builds.
>
> FWIW, I keep older versions of Emacs in my Debian install by tweaking
> the .deb files to eliminate the conflicts.
And they still run? I tried extracting a executable from an old package,
but it immediately failed.
> Stefan
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: ELPA: New pacReferences: <m135pepivk.fsf@P-E6-PFredo1.imn.u-bordeaux2.fr> <m15yu9unaa.fsf@P-E6-PFredo1.imn.u-bordeaux2.fr>
@ 2021-10-07 20:32 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-10-07 20:32 UTC (permalink / raw)
To: Nicolas P. Rougier (gmail); +Cc: emacs-devel
"Nicolas P. Rougier (gmail)" <nicolas.rougier@gmail.com> writes:
> I've rewrote the modeline as a minor-mode. However, the previous
> version landed on ELPA before I made the push on GitHub. Hopefully, it
> will soon be replaced with the newest version.
Your package is marked with :auto-sync, so it should be updated
automatically sooner or later.
> Nicolas
>
>
> "Nicolas P. Rougier (inria)" <nicolas.rougier@inria.fr> writes:
>
>> Dear all,
>>
>> I would like to submit a new package to ELPA which is an adaptive
>> modeline (depending on major-mode) that can go on top (header-line)
>> or bottom (mode-line). It makes use of dedicated faces
>> for active / inactive states.
>>
>> The project is hosted at https://github.com/rougier/nano-modeline
>> and
>> the
>> README displays what it looks like.
>>
>> Best,
>> Nicolas
>
>
>
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: [ELPA] Add compat.el
2021-10-04 23:00 75% ` [ELPA] Add compat.el Philip Kaludercic
2021-10-07 7:03 95% ` Old (static) builds of Emacs Philip Kaludercic
@ 2021-10-07 20:49 90% ` Philip Kaludercic
2021-10-15 19:08 83% ` Philip Kaludercic
2 siblings, 2 replies; 200+ results
From: Philip Kaludercic @ 2021-10-07 20:49 UTC (permalink / raw)
To: emacs-devel
Philip Kaludercic <philipk@posteo.net> writes:
> Hello again,
>
> I have been working on compat.el over the last week, and have written a
> number of tests. The source code has been uploaded here:
>
> https://git.sr.ht/~pkal/compat
>
> The library should be usable in it's current state, but I'd be
> interested to hear from other people and developers too. There might be
> missing functions or macros, edge cases that could be added to the
> tests, etc. that could be improved.
An interesting issue I found when testing compat.el with older versions
is that string-replace and string-search fail, due to the same kind of
issue.
From Emacs 27 onwards, this works as expected:
(string-replace "\377" "x" "a\377b")
;; => "axb"
internally, the compatibility function for string-replace uses
replace-regexp-in-string.
The same code, when evaluated by a version of Emacs older than 27 fails
to replace the character
(string-replace "\377" "x" "a\377b")
;; => "a\377b"
For string-search, using string-match internally, the "unusual" byte
cannot be found:
(string-search (string-to-multibyte "\377") "ab\377c")
;; => nil
whereas the expected answer is 2.
I couldn't find anything in NEWS.27 to indicate that something had
changed, so I wonder if there was a bug that was fixed? Does anyone
know or remember why this behaviour changed?
--
Philip Kaludercic
^ permalink raw reply [relevance 90%]
* Re: [ELPA] Add compat.el
@ 2021-10-08 9:59 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-10-08 9:59 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Date: Thu, 07 Oct 2021 20:49:12 +0000
>>
>> >From Emacs 27 onwards, this works as expected:
>>
>> (string-replace "\377" "x" "a\377b")
>> ;; => "axb"
>>
>> internally, the compatibility function for string-replace uses
>> replace-regexp-in-string.
>>
>> The same code, when evaluated by a version of Emacs older than 27 fails
>> to replace the character
>>
>> (string-replace "\377" "x" "a\377b")
>> ;; => "a\377b"
>
> Why did you expect that to work? What is the semantics of matching
> unibyte strings to multibyte strings? do you compare bytes or do you
> compare characters? There are no "100% correct" answers for these
> questions.
The only reason I expect it is that it does work for Emacs 27.1 and
newer.
>> I couldn't find anything in NEWS.27 to indicate that something had
>> changed, so I wonder if there was a bug that was fixed? Does anyone
>> know or remember why this behaviour changed?
>
> This is a gray area of regexp matching, and it keeps constantly
> changing in Emacs under the hood. The changes are generally seen as
> "bugfixes" (though IMNSHO they aren't), and so they aren't called out
> in NEWS. And what would you say there about such subtle changes,
> anyway? So no one should expect it to work the same in different
> versions of Emacs.
True, but my concern here is to provide older versions of Emacs with the
same behaviour (for these newer functions, like string-search and
string-replace), so I do have to take it into consideration.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: [ELPA] Add compat.el
@ 2021-10-08 10:00 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-10-08 10:00 UTC (permalink / raw)
To: Mattias Engdegård; +Cc: emacs-devel
Mattias Engdegård <mattiase@acm.org> writes:
> 7 okt. 2021 kl. 22.49 skrev Philip Kaludercic <philipk@posteo.net>:
>
>> I couldn't find anything in NEWS.27 to indicate that something had
>> changed, so I wonder if there was a bug that was fixed?
>
> Yes, it was a bug, fixed in a1f76adfb03c23bb4242928e8efe6193c301f0c1.
Thank you, knowing what changed I can provide two different
implementations.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: [ELPA] Add compat.el
@ 2021-10-08 11:35 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-10-08 11:35 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: emacs-devel@gnu.org
>> Date: Fri, 08 Oct 2021 09:59:45 +0000
>>
>> > This is a gray area of regexp matching, and it keeps constantly
>> > changing in Emacs under the hood. The changes are generally seen as
>> > "bugfixes" (though IMNSHO they aren't), and so they aren't called out
>> > in NEWS. And what would you say there about such subtle changes,
>> > anyway? So no one should expect it to work the same in different
>> > versions of Emacs.
>>
>> True, but my concern here is to provide older versions of Emacs with the
>> same behaviour (for these newer functions, like string-search and
>> string-replace), so I do have to take it into consideration.
>
> That's fine, but you seem to be asking why the change and whether it's
> "right". I'm saying that you just need to accept that this is how
> things are, and if the compatibility package needs to account for
> that, so be it.
Oh no, I wasn't questioning the current behaviour, I just wanted to know
what changed internally, to better understand what was going on.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: flymake-kondor on NonGNU ELPA
2021-10-04 12:08 99% ` Philip Kaludercic
@ 2021-10-08 11:36 99% ` Philip Kaludercic
1 sibling, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-10-08 11:36 UTC (permalink / raw)
To: Manuel Uberti; +Cc: emacs-devel
Manuel Uberti <manuel.uberti@inventati.org> writes:
> On 01/10/21 10:59, Philip Kaludercic wrote:
>> I have tried building it, and everything seems fine[.]
>
> Is there anything more from my side you need for this?
Seeing as there have been no objections, I'll go ahead an add the
package to NonGNU ELPA.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Elisp LSP Server
@ 2021-10-10 16:49 99% ` Philip Kaludercic
1 sibling, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-10-10 16:49 UTC (permalink / raw)
To: Daniel Martín
Cc: Richard Stallman, psainty, emacs-devel, Po Lu, joaotavora,
Ag Ibragimov
Daniel Martín <mardani29@yahoo.es> writes:
> Ag Ibragimov <agzam.ibragimov@gmail.com> writes:
>
>> And as a side effect, that would also make it possible for better
>> navigation and code introspection of Elisp outside of Emacs.
>
> I think this is a good point, but I don't expect there is a lot of
> people that work on ELisp without Emacs (even if we consider people that
> use a web IDE that supports LSP). Wouldn't we spend a lot of time
> building something that almost no one would use?
I agree, it seems like too much effort, if all you need is navigation
and introspection. E.g. htmlfontify uses etags (but I guess that could
be updated to use xref) to generate links for definitions.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Elisp LSP Server
@ 2021-10-12 10:21 85% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-10-12 10:21 UTC (permalink / raw)
To: Ag Ibragimov; +Cc: Po Lu, Joost Kremers, rms, emacs-devel
Ag Ibragimov <agzam.ibragimov@gmail.com> writes:
> It was my mistake to even mention godforsaken VSCode - I don't even
> use it, I don't know why I brought it up. I apologize; Can we please
> start it over and forget about GitHub, VSCode, etc.?
I do think there is some association, because it seems there is little
use for a Elisp language server outside of these use-cases. When someone
wants to debug a broken configuration, they'd usually emacs -Q, not open
VSCode.
> - Has anyone ever tried figuring out something similar? Surely, in 45
> years of Emacs, someone must have done something like that?
LSP has not existed for that long, and I am not sure if there were any
comparable projects of the same ambition before. At most "language
servers" have existed for specific languages, such as Common Lisp.
> - If someone attempts to create a cli tool that potentially could
> introspect, lint, format, and maybe even refactor elisp outside of
> Emacs, where would they need to be looking?
If I wanted to do this, I'd just write Elisp scripts that would be
invoked via shell scripts or something of that sort using Emacs' batch
mode.
An alternative would be to implement everything yourself from group up,
and follow up on the development whenever something changes.
Another one would be to extend something like tree sitter by Elisp
support.
> - Is it possible to build something like this by examining relevant
> pieces of C in Emacs codebase?
Not everything relating to Elisp development in implemented in C. You'd
also have to read the Elisp parts.
> - Maybe there are parts in REmacs project that would be easier to go
> through?
I don't know about that, but AFAIK the project has stalled.
--
Philip Kaludercic
^ permalink raw reply [relevance 85%]
* Re: Elisp LSP Server
@ 2021-10-12 12:51 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-10-12 12:51 UTC (permalink / raw)
To: tomas; +Cc: emacs-devel
<tomas@tuxteam.de> writes:
> On Tue, Oct 12, 2021 at 10:21:57AM +0000, Philip Kaludercic wrote:
>> Ag Ibragimov <agzam.ibragimov@gmail.com> writes:
>>
>> > It was my mistake to even mention godforsaken VSCode - I don't even
>> > use it, I don't know why I brought it up. I apologize; Can we please
>> > start it over and forget about GitHub, VSCode, etc.?
>>
>> I do think there is some association, because it seems there is little
>> use for a Elisp language server outside of these use-cases. When someone
>> wants to debug a broken configuration, they'd usually emacs -Q, not open
>> VSCode.
>
> FWIW there are LSP bindings for vim. Exotic, I know, but hey, it's free
> software.
From my understanding of vim, this seems more practical, since Vimscript
isn't evaluated at runtime (like in a *scratch* buffer or M-:), or am I
mistaken?
> Cheers
> - t
>
P.S. could you Cc all the participants in the thread. I wouldn't have
noticed your repose if I hadn't checked the gmane.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: ELPA: new package coterm
@ 2021-10-12 19:14 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-10-12 19:14 UTC (permalink / raw)
To: miha; +Cc: emacs-devel
miha@kamnitnik.top writes:
> There is a lot of duplicated functionality with term.el. For
> information on the differences from [M-x term] and why I didn't reuse
> term.el functions, see the commentary section and the comment at the
> start of ";;; Terminal emulation" section.
Is there any reason this shouldn't be added to shell or comint directly?
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: ELPA: new package nano-agenda
@ 2021-10-12 19:19 95% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-10-12 19:19 UTC (permalink / raw)
To: Nicolas P. Rougier (inria); +Cc: emacs-devel
"Nicolas P. Rougier (inria)" <nicolas.rougier@inria.fr> writes:
> The sources are hosted at https://github.com/rougier/nano-agenda and
> the README displays what it looks like. I find it quite convenient for
> my own use but maybe it's too specific for ELPA.
It seems you are using ts.el, which isn't on ELPA, and additionally depends
on s.el that also (famously) isn't on ELPA.
That being said, ts seems to only have a weak dependency on s (two
usages of s-join), so maybe ts could be added to ELPA -- in one form or
another -- as it seems to have a few useful improvements over the
default time and duration functions.
Otherwise, I don't see any grave issues from quickly skimming over the
code.
--
Philip Kaludercic
^ permalink raw reply [relevance 95%]
* Re: ELPA: new package nano-agenda
@ 2021-10-12 19:41 98% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-10-12 19:41 UTC (permalink / raw)
To: Nicolas P. Rougier (inria); +Cc: adam, emacs-devel
"Nicolas P. Rougier (inria)" <nicolas.rougier@inria.fr> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> It seems you are using ts.el, which isn't on ELPA, and additionally
>> depends
>> on s.el that also (famously) isn't on ELPA.
>>
>> That being said, ts seems to only have a weak dependency on s (two
>> usages of s-join), so maybe ts could be added to ELPA -- in one form
>> or
>> another -- as it seems to have a few useful improvements over the
>> default time and duration functions.
>
> Thanks for the review, I didn't pay attention to this point
> actually. I confirm than ts would be a very nice addition to ELPA
> since it really simplifies time management for user and comes with a
> very clean API. I guess only Adam Porter can answer if he want to add
> it to ELPA or not.
As he is the only major contributor, this might be worth considering.
I've Cc'ed Adam to see what he thinks.
What might be an issue is if the "ts-" namespace is considered to be
"too valuable", as was the issue with "s-" and "f-". The maintainers
would have to decide on that, I can only speculate.
> Should I try to remove the dependency in the meantime?
Personally, I'd wait to see.
--
Philip Kaludercic
^ permalink raw reply [relevance 98%]
* Re: Elisp LSP Server
@ 2021-10-13 13:38 96% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-10-13 13:38 UTC (permalink / raw)
To: Eli Zaretskii
Cc: rms, psainty, emacs-devel, Po Lu, joaotavora, mardani29,
agzam.ibragimov
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Po Lu <luangruo@yahoo.com>
>> Cc: agzam.ibragimov@gmail.com, rms@gnu.org, philipk@posteo.net,
>> psainty@orcon.net.nz, emacs-devel@gnu.org, joaotavora@gmail.com,
>> mardani29@yahoo.es
>> Date: Wed, 13 Oct 2021 20:49:11 +0800
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> > Please tell me that I misunderstood something very important in what
>> > you had in mind.
>>
>> Yes, I was stating that this feature won't find an audience in Emacs
>> users, but will instead find one in people who want to use GitHub and VS
>> Code to edit Emacs Lisp.
>
> How can it NOT find any users in Emacs? We edit Lisp all the time,
> don't we? Shouldn't advanced features for indentation, syntax
> highlight, refactoring, etc. of Emacs Lisp programs be very welcome in
> Emacs?
I think the question here is would an Elisp LSP server be able to offer
anything over a direct implementation within Emacs. That this seems
improbable was mentioned previously, so in effect this would only
improve the ELisp support for non-Emacs editors (why there would be
interest for that I find hard to understand, but that is not the point).
--
Philip Kaludercic
^ permalink raw reply [relevance 96%]
* Re: [ELPA] Add compat.el
2021-10-04 23:00 75% ` [ELPA] Add compat.el Philip Kaludercic
2021-10-07 7:03 95% ` Old (static) builds of Emacs Philip Kaludercic
2021-10-07 20:49 90% ` [ELPA] Add compat.el Philip Kaludercic
@ 2021-10-15 19:08 83% ` Philip Kaludercic
2 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-10-15 19:08 UTC (permalink / raw)
To: emacs-devel
Philip Kaludercic <philipk@posteo.net> writes:
> Hello again,
... and once more.
> I have been working on compat.el over the last week, and have written a
> number of tests. The source code has been uploaded here:
>
> https://git.sr.ht/~pkal/compat
>
> The library should be usable in it's current state, but I'd be
> interested to hear from other people and developers too. There might be
> missing functions or macros, edge cases that could be added to the
> tests, etc. that could be improved.
After debugging the code for a while, I can now say that the code is
functional and passes all the tests I prepared. Sadly this required me
to bump the minimal version up to 24.3. It would have been a lot easier
to bump it to 24.4, but 24.3 is the oldest release still in use on
CentOS 7 machines (I know this because my fathers workstation has this
version of Emacs).
For now I am using GitHub's CI to ensure that changes don't break the
test-suit. I plan to use SourceHut's service at some later point, but
for now the work of preparing old Emacs builds was already taken care of
by Steve Purcell (https://github.com/purcell/setup-emacs), so I took the
easier route for now.
With the infrastructure ready, this means the package could be added to
ELPA, and released along with Emacs 28.1, leaving my some time to
improve the documentation. I'd like to once again make sure there are no
fundamental objections to anything I am doing here. If so, I'd do my
best to fix the issues.
> Finally, compat.el now ends with these lines:
>
> ;; ;;;; Ensure NonGNU ELPA is in `package-archives'
> ;; (with-eval-after-load 'package
> ;; (unless (or (rassoc "https://elpa.nongnu.org/nongnu/" package-archives)
> ;; (rassoc "http://elpa.nongnu.org/nongnu/" package-archives)
> ;; (rassoc "https://elpa.nongnu.org/nongnu-devel/" package-archives)
> ;; (rassoc "http://elpa.nongnu.org/nongnu-devel/" package-archives))
> ;; (add-to-list 'package-archives '("nongnu" . "https://elpa.nongnu.org/nongnu/"))))
It seems better to steer away from controversy for now, so I have
removed this snippet.
--
Philip Kaludercic
^ permalink raw reply [relevance 83%]
* Re: Prettify elpa.gnu.org
@ 2021-10-18 19:45 95% ` Philip Kaludercic
2021-10-18 20:05 93% ` Philip Kaludercic
0 siblings, 2 replies; 200+ results
From: Philip Kaludercic @ 2021-10-18 19:45 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> Hi,
>
> I'd like to change the style sheet so that our ELPA weg pages don't
> spend as much screen real estate showing:
>
> To install this package, run in Emacs:
>
> M-x package-install RET haskell-tng-mode RET
>
> I don't want to remove this info, just make it use less space.
> I expect it should be a very simple change to make in the CSS, but
> I also suspect that it would be much easier for someone more familiar
> with CSS than I am.
I feel that in general the "margin-bottom" value for paragraphs could be
reduced to 1em (from the current 2em, in layout.css:129), without
squeezing the page together too much.
Another idea might also to be to use details elements[0] to hide the
information by default (most users will know how a package is installed,
I suspect the note is added for people installing their first packages),
but to present it in more detail if explicitly requested.
[0] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/details
--
Philip Kaludercic
^ permalink raw reply [relevance 95%]
* Re: [NonGNU ELPA] New package proposal: git-modes
@ 2021-10-18 19:50 97% ` Philip Kaludercic
1 sibling, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-10-18 19:50 UTC (permalink / raw)
To: Jonas Bernoulli; +Cc: emacs-devel
Jonas Bernoulli <jonas@bernoul.li> writes:
> Hello,
Hi!
> "git-modes" can be found at https://github.com/magit/git-modes. You
> can git-clone from that URL to avoid non-free javascript. Note that
> I am preparing for the addition to NonGNU ELPA on the "next" branch.
I seem to see no "next" branch in the repository at the moment (neither
on GitHub nor in my local checkout).
$ git branch -al
* master
remotes/origin/HEAD -> origin/master
remotes/origin/master
Also, do you plan to continue the development on the next branch (so
that the MELPA and the NonGNU ELPA version are maintained in parallel),
or will you merge the NonGNU ELPA version back into the master branch
later on?
--
Philip Kaludercic
^ permalink raw reply [relevance 97%]
* Re: Prettify elpa.gnu.org
2021-10-18 19:45 95% ` Philip Kaludercic
@ 2021-10-18 20:05 93% ` Philip Kaludercic
1 sibling, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-10-18 20:05 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1269 bytes --]
Philip Kaludercic <philipk@posteo.net> writes:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> Hi,
>>
>> I'd like to change the style sheet so that our ELPA weg pages don't
>> spend as much screen real estate showing:
>>
>> To install this package, run in Emacs:
>>
>> M-x package-install RET haskell-tng-mode RET
>>
>> I don't want to remove this info, just make it use less space.
>> I expect it should be a very simple change to make in the CSS, but
>> I also suspect that it would be much easier for someone more familiar
>> with CSS than I am.
>
> I feel that in general the "margin-bottom" value for paragraphs could be
> reduced to 1em (from the current 2em, in layout.css:129), without
> squeezing the page together too much.
>
> Another idea might also to be to use details elements[0] to hide the
> information by default (most users will know how a package is installed,
> I suspect the note is added for people installing their first packages),
> but to present it in more detail if explicitly requested.
>
> [0] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/details
Also related to the website, I think the NonGNU ELPA webpage could be
improved. This is how it currently looks like in Firefox when I shrink
the window:
[-- Attachment #2: Screenshot_2021-10-18 NonGNU Emacs Lisp Package Archive.png --]
[-- Type: image/png, Size: 81345 bytes --]
[-- Attachment #3: Type: text/plain, Size: 431 bytes --]
First of all the "NonGNU Emacs Lisp Package Archive" is too packed, and
the instructions to configure NonGNU ELPA for versions prior to 28 are
wrapped in a <code> instead of <pre> element. Only the former preserves
indentation as intended, so that should be replaced.
I would fix these issues, but I cannot find where the HTML and CSS is
stored. Nongnu.git seems to have no html directory like elpa.git.
--
Philip Kaludercic
^ permalink raw reply [relevance 93%]
* Re: Prettify elpa.gnu.org
@ 2021-10-18 21:27 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-10-18 21:27 UTC (permalink / raw)
To: Stefan Kangas; +Cc: Stefan Monnier, emacs-devel
Stefan Kangas <stefankangas@gmail.com> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Another idea might also to be to use details elements[0] to hide the
>> information by default (most users will know how a package is installed,
>> I suspect the note is added for people installing their first packages),
>> but to present it in more detail if explicitly requested.
>>
>> [0] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/details
>
> If it has reasonable support in typical web browsers, then I don't see
> why not.
It appears to be well supported:
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/details#browser_compatibility
I'd say the real question is if this is necessary in the first place. A
single line in the body doesn't seem worth hiding.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Moving kbd to subr.el
@ 2021-10-19 10:46 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-10-19 10:46 UTC (permalink / raw)
To: Gregory Heytings
Cc: Lars Ingebrigtsen, Stefan Kangas, Stefan Monnier, emacs-devel
Gregory Heytings <gregory@heytings.org> writes:
> This thread is rather long, so for those who did not read all its
> posts, this is what my proposal is:
I sadly didn't follow the thread from the beginning (because the subject
wasn't changed), but was the actual issue with using kbd discussed
somewhere you could point me to?
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: ELPA: new package nano-agenda
@ 2021-10-19 11:55 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-10-19 11:55 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Adam Porter, Nicolas P. Rougier (inria), emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> What might be an issue is if the "ts-" namespace is considered to be
>>> "too valuable", as was the issue with "s-" and "f-". The maintainers
>>> would have to decide on that, I can only speculate.
>
> two-letter (well, 3 if you count the dash) prefixes are fine, thanks
> (we have loads of them).
Really? When I run
(seq-count
(lambda (ent)
(<= (length (symbol-name (car ent))) 2))
package-archive-contents)
all I get is one result (xr).
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: ELPA: new package nano-agenda
@ 2021-10-19 12:24 94% ` Philip Kaludercic
2021-10-21 14:28 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-10-19 12:24 UTC (permalink / raw)
To: Stefan Kangas
Cc: Adam Porter, emacs-devel, Stefan Monnier,
Nicolas P. Rougier (inria)
Stefan Kangas <stefan@marxist.se> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> all I get is one result (xr).
>
> ~/wip/emacs $ find -name '??.el' | wc -l
> 28
Ah, the core has more, but even then a number are obsolete (cl, gs, vi),
some are autogenerated (PY, QJ, SW) and a number are part of specific
packages (org has ob, oc, ol, ox; cedet as db, fw, ia, sb, el). The only
real two packages names are bs, js and vc (if you include Elisp
libraries, then gv, pp and rx would be included too).
The other question with ts is should the missing functionality be added
directly to Emacs itself?
^ permalink raw reply [relevance 94%]
* Re: Prettify elpa.gnu.org
@ 2021-10-19 16:47 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-10-19 16:47 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> I would fix these issues, but I cannot find where the HTML and CSS is
>> stored. Nongnu.git seems to have no html directory like elpa.git.
>
> I think it's in the `main` branch of `elpa.git` in the `html`
> subdirectory (it's the same CSS used for NonGNU).
Yes, but where is the index.html for NonGNU ELPA located?
> [ If/when you update it, let me know because it's not automatically
> copied to the actual web site. ]
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* [NonGNU ELPA] Colour themes
@ 2021-10-19 20:20 59% Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-10-19 20:20 UTC (permalink / raw)
To: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 132 bytes --]
Hi,
I have collected a list of popular colour themes that could be added to
NonGNU ELPA directly. Here is the patch to add them:
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Add-a-number-of-colour-themes.patch --]
[-- Type: text/x-diff, Size: 3841 bytes --]
From d22c5abfa8a1671e1e1b2864f847591b78bf1731 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Tue, 19 Oct 2021 22:13:53 +0200
Subject: [PATCH] Add a number of colour themes
---
elpa-packages | 47 ++++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 46 insertions(+), 1 deletion(-)
diff --git a/elpa-packages b/elpa-packages
index 30296e46c1..d41b93f585 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -9,8 +9,23 @@
;; that can be used in PLIST.
(
+ ("afternoon-theme" :url "https://github.com/osener/emacs-afternoon-theme"
+ :ignored-files ("*.png"))
+
+ ("alect-themes" :url "https://github.com/alezost/alect-themes"
+ :ignored-files ("tests" "Makefile" "colors"))
+
+ ("ample-theme" :url "https://github.com/jordonbiondo/ample-theme")
+
+ ("anti-zenburn-theme" :url "https://github.com/m00natic/anti-zenburn-theme"
+ :ignored-files ("anti-zenburn-snapshot.jpeg"))
+
("apache-mode" :url "https://github.com/emacs-php/apache-mode")
+ ("apropospriate-theme" :url "https://github.com/waymondo/apropospriate-theme"
+ :ignored-files ("*.png")
+ :main-file "apropospriate.el")
+
("arduino-mode" :url "https://github.com/stardiviner/arduino-mode"
:ignored-files ("Cask"))
@@ -25,8 +40,14 @@
:ignored-files ("clojure-mode-extra-font-locking.el" "doc" "test" "test.clj")
:news "CHANGELOG.md")
+ ("color-theme-tangotango" :url "https://github.com/juba/color-theme-tangotango"
+ :ignored-files ("screenshots" "color-theme-tangotango.el"))
+
("crux" :url "https://github.com/bbatsov/crux")
+ ("cyberpunk-theme" :url "https://github.com/n3mo/cyberpunk-theme.el"
+ :ignored-files ("cyberpunk-theme.png" "example-org-file.org"))
+
("d-mode" :url "https://github.com/Emacs-D-Mode-Maintainers/Emacs-D-Mode"
:ignored-files ("coverage" "tests-todo" "tests" "Cask" "Makefile" "d-mode-tests.el"))
@@ -34,6 +55,9 @@
:ignored-files ("test" "Cask" "Makefile")
:news "CHANGELOG.md")
+ ("dracula-theme" :url "https://github.com/dracula/emacs"
+ :ignored-files ("INSTALL.md" "screenshot.png" "start_emacs_test.sh" "test-profile.el"))
+
("editorconfig" :url "https://github.com/editorconfig/editorconfig-emacs"
:doc "doc/editorconfig.texi"
:news "CHANGELOG.md"
@@ -174,6 +198,13 @@
;; :dont-release "-dev\\'"
)
+ ("material-theme" :url "https://github.com/cpaulik/emacs-material-theme"
+ :ignored-files ("*.png")
+ :news "changes.org")
+
+ ("monokai-theme" :url "https://github.com/oneKelvinSmith/monokai-emacs"
+ :ignored-files ("assets"))
+
("multiple-cursors" :url "https://github.com/magnars/multiple-cursors.el"
:ignored-files ("features"))
@@ -242,6 +273,13 @@
;; ("subed" :url "https://github.com/rndusr/subed"
;; :lisp-dir "subed")
+ ("solarized-theme" :url "https://github.com/bbatsov/solarized-emacs"
+ :ignored-files ("child-theme-example" "colorlab" "dev-emacs.d"
+ "Cask" "Makefile"))
+
+ ("subatomic-theme" :url "https://github.com/cryon/subatomic-theme"
+ :ignored-files ("readme-files"))
+
("swift-mode" :url "https://github.com/swift-emacs/swift-mode"
:ignored-files ("scripts" "test" "Eldev" "Makefile"))
@@ -250,6 +288,8 @@
("tuareg" :url "https://github.com/ocaml/tuareg.git")
+ ("ujelly-theme" :url "https://github.com/marktran/color-theme-ujelly")
+
("vc-fossil" :url "https://github.com/venks1/emacs-fossil")
("web-mode" :url "https://github.com/fxbois/web-mode"
@@ -268,7 +308,12 @@
("yasnippet-snippets" :url "https://github.com/AndreaCrotti/yasnippet-snippets"
:ignored-files ("report" "snippets.html"))
+ ("zenburn-theme" :url "https://github.com/bbatsov/zenburn-emacs"
+ :news "CHANGELOG.md"
+ :ignored-files ("screenshots"))
+
("zig-mode" :url "https://github.com/ziglang/zig-mode"
:ignored-files ("appveyor.yml" "run_tests.sh" "tests.el"))
- )
+)
+
--
2.30.2
[-- Attachment #3: Type: text/plain, Size: 267 bytes --]
Some packages depend on a library called authothemer[0], that currently
isn't on GNU or NonGNU ELPA, so I haven't added those yet. It seems
that at least one popular theme (Gruvbox) depends on it.
[0] https://github.com/jasonm23/autothemer
--
Philip Kaludercic
^ permalink raw reply related [relevance 59%]
* Re: Moving kbd to subr.el
@ 2021-10-20 18:51 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-10-20 18:51 UTC (permalink / raw)
To: Lars Ingebrigtsen
Cc: Eli Zaretskii, gregory, stefankangas, Richard Stallman,
emacs-devel
Lars Ingebrigtsen <larsi@gnus.org> writes:
> Richard Stallman <rms@gnu.org> writes:
>
>> If we are going to relegate the old syntax to "permanently deprecated"
>> as I recommend, we can design a new syntax, whichever syntax we like.
>> It doesn't have to use the function `kbd'.
>
> The syntax that `kbd' understands is the one that we're using to display
> keystrokes in help texts and manuals, so inventing another syntax for
> defining keys doesn't seem productive.
That doesn't mean that the new functions couldn't be more lax while
parsing, and dwim when I say C-f1 for M-space.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: [NonGNU ELPA] New package proposal: git-modes
@ 2021-10-20 18:52 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-10-20 18:52 UTC (permalink / raw)
To: Richard Stallman; +Cc: Jonas Bernoulli, 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 would like to propose the addition of "git-modes" to NonGNU Elpa. It
> > provides three simple major-modes gitattributes-mode, gitconfig-mode and
> > gitignore-mode.
>
> Assuming these are worth distributing (I have no opinion on that),
> should these be part of Emacs? Can we get papers for them?
Seems like it sadly isn't possible, as Jonas says:
> Adding to GNU ELPA is not an option because one of the main authors is
> against assigning copyright to the FSF as a matter of principle.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Moving kbd to subr.el
@ 2021-10-21 13:40 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-10-21 13:40 UTC (permalink / raw)
To: Lars Ingebrigtsen
Cc: Eli Zaretskii, emacs-devel, gregory, Richard Stallman,
stefankangas
Lars Ingebrigtsen <larsi@gnus.org> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> That doesn't mean that the new functions couldn't be more lax while
>> parsing, and dwim when I say C-f1 for M-space.
>
> That sounds very lax indeed.
Do you think it would be impractical?
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: ELPA: new package capf-autosuggest
@ 2021-10-21 13:43 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-10-21 13:43 UTC (permalink / raw)
To: miha; +Cc: emacs-devel
miha@kamnitnik.top writes:
> Source code is available at https://repo.or.cz/emacs-coterm.git
I like the idea, but this link seems to be pointing to the wrong repo
(or at least I just see coterm what was recently added, and nothing
called capf-autosuggest).
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: ELPA: new package nano-agenda
2021-10-19 12:24 94% ` Philip Kaludercic
@ 2021-10-21 14:28 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-10-21 14:28 UTC (permalink / raw)
To: Stefan Kangas
Cc: Adam Porter, Nicolas P. Rougier (inria), Stefan Monnier,
emacs-devel
Philip Kaludercic <philipk@posteo.net> writes:
> Stefan Kangas <stefan@marxist.se> writes:
>
>> Philip Kaludercic <philipk@posteo.net> writes:
>>
>>> all I get is one result (xr).
>>
>> ~/wip/emacs $ find -name '??.el' | wc -l
>> 28
>
> Ah, the core has more, but even then a number are obsolete (cl, gs, vi),
> some are autogenerated (PY, QJ, SW) and a number are part of specific
> packages (org has ob, oc, ol, ox; cedet as db, fw, ia, sb, el). The only
> real two packages names are bs, js and vc (if you include Elisp
> libraries, then gv, pp and rx would be included too).
>
> The other question with ts is should the missing functionality be added
> directly to Emacs itself?
Either way, something should be done. ts.el should be added or
nano-agenda should remove the (silent) dependency, because in it's
current state it breaks for anyone who doesn't install ts manually.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: ELPA: new package capf-autosuggest
@ 2021-10-21 14:55 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-10-21 14:55 UTC (permalink / raw)
To: miha; +Cc: emacs-devel
<miha@kamnitnik.top> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> miha@kamnitnik.top writes:
>>
>>> Source code is available at https://repo.or.cz/emacs-coterm.git
>>
>> I like the idea, but this link seems to be pointing to the wrong repo
>> (or at least I just see coterm what was recently added, and nothing
>> called capf-autosuggest).
>
> Whoops, thanks for pointing this out.
>
> Correct url: https://repo.or.cz/emacs-capf-autosuggest.git
Two notes:
You should add the
--8<---------------cut here---------------start------------->8---
;; Copyright (C) 2021 Free Software Foundation, Inc.
--8<---------------cut here---------------end--------------->8---
notice to the begining of capf-autosuggest.el, and it think it might be
nice to use a version greater than 0.0.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: ELPA: new package capf-autosuggest
@ 2021-10-21 17:17 91% ` philipk
1 sibling, 0 replies; 200+ results
From: philipk @ 2021-10-21 17:17 UTC (permalink / raw)
To: miha; +Cc: emacs-devel
On 21.10.2021 18:01, miha@kamnitnik.top wrote:
> Thanks, now done.
Great, it builds now.
Looking at the file, there seem to be a few checkdoc issues that could
be easily fixed. I guess that would be nice to see. Along these lines it
might also be cool to mark the Commentary sections "Instillation" (that
could be updated when the package is added), "Configuration", ... as
subsections of Commentary by having them begin with four
semicolons. That way when using outline-minor-mode, you'll see all of
them when the section is folded.
A general question I have is if this could be generalized to a general
completion system? You of course don't have to, I'm asking more out of
personal curiosity.
Otherwise, I can add it the package to ELPA with autosync'ing, unless
there are any objections.
^ permalink raw reply [relevance 91%]
* Re: ELPA: new package capf-autosuggest
@ 2021-10-21 18:24 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-10-21 18:24 UTC (permalink / raw)
To: miha; +Cc: emacs-devel
<miha@kamnitnik.top> writes:
> Philip Kaludercic <philip.kaludercic@fau.de> writes:
>
>> <miha@kamnitnik.top> writes:
>>
>>> Thanks, now done.
>>
>> Great, it builds now.
>>
>> Looking at the file, there seem to be a few checkdoc issues that could
>> be easily fixed. I guess that would be nice to see. Along these lines it
>> might also be cool to mark the Commentary sections "Instillation" (that
>> could be updated when the package is added), "Configuration", ... as
>> subsections of Commentary by having them begin with four
>> semicolons. That way when using outline-minor-mode, you'll see all of
>> them when the section is folded.
>
> Thanks for suggestions, now done.
1+
>> A general question I have is if this could be generalized to a general
>> completion system? You of course don't have to, I'm asking more out of
>> personal curiosity.
>
> It already is, enabling 'capf-autosuggest-mode' in an ordinary buffer
> displays an auto-suggestion for the first completion at point candidate
> as you type. By default, it is only displayed if point is at EOL.
> However, I don't advertise this feature that much mostly because I find
> it a bit intrusive. For more information, including how to lift the EOL
> restriction, you can read the ";;;; Details" section.
Yes, I saw that and wanted to know if you were planning to extend
capf-autosuggest in this direction or not. It seems interesting (and I
remember CEDET had something like this), but it isn't easy to get right,
I agree.
>> Otherwise, I can add it the package to ELPA with autosync'ing, unless
>> there are any objections.
>
> Okay, thanks.
I'll wait for a day or so, just to wait for responses.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Prettify elpa.gnu.org
@ 2021-10-21 21:02 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-10-21 21:02 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> Philip Kaludercic [2021-10-19 16:47:41] wrote:
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>>> I would fix these issues, but I cannot find where the HTML and CSS is
>>>> stored. Nongnu.git seems to have no html directory like elpa.git.
>>>
>>> I think it's in the `main` branch of `elpa.git` in the `html`
>>> subdirectory (it's the same CSS used for NonGNU).
>>
>> Yes, but where is the index.html for NonGNU ELPA located?
>
> Ah, I think it's currently "nowhere in Git".
> I suggest you add it to elpa.git:main:html
I am not sure what you mean by this? Do you mean elpa.git (or nongnu.git),
on the main branch, in a html directory?
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Moving kbd to subr.el
@ 2021-10-22 14:57 97% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-10-22 14:57 UTC (permalink / raw)
To: Lars Ingebrigtsen
Cc: Eli Zaretskii, emacs-devel, gregory, Richard Stallman,
stefankangas
Lars Ingebrigtsen <larsi@gnus.org> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>>>> That doesn't mean that the new functions couldn't be more lax while
>>>> parsing, and dwim when I say C-f1 for M-space.
>>>
>>> That sounds very lax indeed.
>>
>> Do you think it would be impractical?
>
> Depends. Do you also mean M-<return> when you say C-<home>?
No, but I am not sure what you mean by this.
My point is that instead of extending or creating a new syntax, that the
new functions could handle a superset of what kbd currently does. So
where as (kbd "C-f1") currently throws an error, the new functions could
interpret the previous expression to be equivalent to (kbd "C-<f1>").
--
Philip Kaludercic
^ permalink raw reply [relevance 97%]
* Re: Moving kbd to subr.el
@ 2021-10-22 15:06 98% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-10-22 15:06 UTC (permalink / raw)
To: Lars Ingebrigtsen
Cc: Eli Zaretskii, emacs-devel, gregory, Richard Stallman,
stefankangas
Lars Ingebrigtsen <larsi@gnus.org> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>>>>>> That doesn't mean that the new functions couldn't be more lax while
>>>>>> parsing, and dwim when I say C-f1 for M-space.
>>>>>
>>>>> That sounds very lax indeed.
>>>>
>>>> Do you think it would be impractical?
>>>
>>> Depends. Do you also mean M-<return> when you say C-<home>?
>>
>> No, but I am not sure what you mean by this.
>>
>> My point is that instead of extending or creating a new syntax, that the
>> new functions could handle a superset of what kbd currently does. So
>> where as (kbd "C-f1") currently throws an error, the new functions could
>> interpret the previous expression to be equivalent to (kbd "C-<f1>").
>
> But you said that C-f1 should be interpreted as M-space, so I wasn't
> sure what you were getting at.
Oh my, now I understand what you mean. No, that was a typo ("or" ->
"for"). Sorry about that.
> But, no, I don't think the functions should be lax when interpreting
> these strings -- it's just confusing.
How come? It could just as well be argued that throwing errors while
parsing key bindings is also confusing, especially when guessing that
C-f1 is the same C-<f1> isn't that far of a jump.
--
Philip Kaludercic
^ permalink raw reply [relevance 98%]
* Re: Moving kbd to subr.el
@ 2021-10-22 18:16 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-10-22 18:16 UTC (permalink / raw)
To: Lars Ingebrigtsen
Cc: Eli Zaretskii, emacs-devel, gregory, Richard Stallman,
stefankangas
Lars Ingebrigtsen <larsi@gnus.org> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> How come? It could just as well be argued that throwing errors while
>> parsing key bindings is also confusing, especially when guessing that
>> C-f1 is the same C-<f1> isn't that far of a jump.
>
> Because then you end up with code that says
>
> (define-keymap
> ...
> "C-f1" 'some-function
> "C-<f2>" 'other-function)
>
> and the person reading it will then wonder "but what's the difference"?
But doesn't this issue already exist? e.g. kbd parses both "C-c" and
"^C", which might lead to the same confusion ("is one of these for X11
and the other one for TUI Emacs?", they might ask).
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Prettify elpa.gnu.org
@ 2021-10-22 20:00 99% ` Philip Kaludercic
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Philip Kaludercic @ 2021-10-22 20:00 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> Philip Kaludercic [2021-10-21 21:02:04] wrote:
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> Philip Kaludercic [2021-10-19 16:47:41] wrote:
>>>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>>>>> I would fix these issues, but I cannot find where the HTML and CSS is
>>>>>> stored. Nongnu.git seems to have no html directory like elpa.git.
>>>>>
>>>>> I think it's in the `main` branch of `elpa.git` in the `html`
>>>>> subdirectory (it's the same CSS used for NonGNU).
>>>>
>>>> Yes, but where is the index.html for NonGNU ELPA located?
>>>
>>> Ah, I think it's currently "nowhere in Git".
>>> I suggest you add it to elpa.git:main:html
>>
>> I am not sure what you mean by this? Do you mean elpa.git (or nongnu.git),
>> on the main branch, in a html directory?
>
> Yes, I was thinking the `html` directory of the `main` branch of the
> `elpa.git` (which is what I meant by `elpa.git:main:html`).
> But if you prefer putting it in a new `html` directory in the `main`
> branch of `nongnu.git` that would work as well.
Yes, this confused me because index.html is for GNU ELPA, so I couldn't
just name it index.html for NonGNU.
Having to many implicit dependencies between elpa.git and nongnu.git
seems like potential for confusion.
Along these lines, should nongnu.git:main:html also contain the other
files (css, images, javascript, ...)?
>
> Stefan
>
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Prettify elpa.gnu.org
@ 2021-10-22 20:44 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-10-22 20:44 UTC (permalink / raw)
To: Stefan Kangas; +Cc: Stefan Monnier, emacs-devel
Stefan Kangas <stefankangas@gmail.com> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Having to many implicit dependencies between elpa.git and nongnu.git
>> seems like potential for confusion.
>
> Could we perhaps simplify all this by moving such things into a third,
> shared repository?
Or even everything into one, with elpa.git and nongnu.git being
different branches.
> (BTW, how about renaming "elpa.git" and "nongnu.git"? I find it
> slightly counter-intuitive and would prefer something more explicit like
> "gnu-elpa.git" and "nongnu-elpa.git". Alternatively, the "new" nongnu
> ELPA repository could be named "nongnu-elpa.git". Maybe it's too late
> to suggest this though.)
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: [nongnu] main e7a6b32: * elpa-packages (haml-mode): Manually pin a version
[not found] ` <20211017094027.2E0DE209AA@vcs0.savannah.gnu.org>
@ 2021-10-22 21:09 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-10-22 21:09 UTC (permalink / raw)
To: emacs-devel
zge@savannah.gnu.org (Philip Kaludercic) writes:
> branch: main
> commit e7a6b32fbf4c7821bdb223aa28f1d09d0ccd7c19
> Author: Philip Kaludercic <philipk@posteo.net>
> Commit: Philip Kaludercic <philipk@posteo.net>
>
> * elpa-packages (haml-mode): Manually pin a version
> ---
> elpa-packages | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/elpa-packages b/elpa-packages
> index 20f44aa..30296e4 100644
> --- a/elpa-packages
> +++ b/elpa-packages
> @@ -82,7 +82,12 @@
>
> ("guru-mode" :url "https://github.com/bbatsov/guru-mode")
>
> - ("haml-mode" :url "https://github.com/nex3/haml-mode")
> + ("haml-mode" :url "https://github.com/nex3/haml-mode"
> + ;; The version attribute is set to "0", yet the the maintainer(s?)
> + ;; seem unresponsive (https://github.com/nex3/haml-mode/issues/40)
> + ;; and thus the package isn't published on the main archive. We
> + ;; manually set the latest commit to a proper version number:
> + :version-map ((nil "3.1.10" "bf5b6c11b1206759d2b28af48765e04882dd1fc4")))
>
> ("haskell-tng-mode" :url "https://gitlab.com/tseenshe/haskell-tng.el")
It seems that despite pinning a release, no package was released on the
default archive? This should be done to fix the incompatibility in
sass-mode dependency list.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Prettify elpa.gnu.org
@ 2021-10-24 9:15 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-10-24 9:15 UTC (permalink / raw)
To: Richard Stallman; +Cc: monnier, 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 am not sure what you mean by this? Do you mean elpa.git (or nongnu.git),
> > >> on the main branch, in a html directory?
> > >
> > > Yes, I was thinking the `html` directory of the `main` branch of the
> > > `elpa.git` (which is what I meant by `elpa.git:main:html`).
> > > But if you prefer putting it in a new `html` directory in the `main`
> > > branch of `nongnu.git` that would work as well.
>
> > Yes, this confused me because index.html is for GNU ELPA, so I couldn't
> > just name it index.html for NonGNU.
>
> > Having to many implicit dependencies between elpa.git and nongnu.git
> > seems like potential for confusion.
>
> Would someone please explain to me the question under discussion here?
> What change has been proposed?
The HTML files of elpa.gnu.org are stored in elpa.git, but the HTML
files for elpa.nongnu.org are currently not part of any repository.
I wanted to know where/how it would be best to add the HTML files for
elpa.nongnu.org, so that contributors like me can suggest changes.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Prettify elpa.gnu.org
@ 2021-10-24 10:25 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-10-24 10:25 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> Yes, this confused me because index.html is for GNU ELPA, so I couldn't
>> just name it index.html for NonGNU.
>>
>> Having to many implicit dependencies between elpa.git and nongnu.git
>> seems like potential for confusion.
>>
>> Along these lines, should nongnu.git:main:html also contain the other
>> files (css, images, javascript, ...)?
>
> The files are shared via symlinks and they're copied from the Git clone
> to the web site in an ad-hoc way anyway, so there's no great benefit to
> try and have a structure in the Git that matches the Web
> site's structure.
>
> I suggested to put the file in elpa.git:main:html so that's the only
> place from which we need to copy those files, which makes things
> marginally simpler.
I see. So adding it to elpa.git makes sense, but I think adding a note
to nongnu.git:main:README would also be worthwhile.
> Stefan
>
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Moving kbd to subr.el
@ 2021-10-25 16:10 98% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-10-25 16:10 UTC (permalink / raw)
To: Corwin Brust
Cc: Richard Stallman, Emacs developers, gregory, Stefan Kangas,
Lars Ingebrigtsen, Eli Zaretskii
Corwin Brust <corwin@bru.st> writes:
> Thank you for the reply, Lars.
>
> On Sun, Oct 24, 2021, 13:42 Lars Ingebrigtsen <larsi@gnus.org> wrote:
>
>> Corwin Brust <corwin@bru.st> writes:
>>
>> > Are there design goals at stake here that bind-keys leaves aside? And,
>> > assuming there, would someone be so kind as to enumerate the design goals
>> > for a new keyboard binding layer?
>>
>> I'm not quite sure what you're asking
>
>
> Now that you ask, I wonderifmy thinkingis muddled, here.
>
> -- that Emacs should be pre-loaded
>> with bind-keys?
>>
>
> That sounds great to me Are there barriers or concerns?
If I am not mistaken, bind-keys is a package for user-configurations,
right? The intention is to provide a better syntax for modifying
existing key maps, while this discussion is about extending core Emacs
to simplify the definitions of key maps in (among other things)
preloaded packages.
--
Philip Kaludercic
^ permalink raw reply [relevance 98%]
* Re: [ELPA] New package: vertico-posframe
@ 2021-10-25 16:13 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-10-25 16:13 UTC (permalink / raw)
To: tumashu; +Cc: emacs-devel@gnu.org
tumashu <tumashu@163.com> writes:
> ** What is vertico-posframe
> vertico-posframe is an vertico extension, which lets vertico use posframe to show its candidate menu.
> NOTE: vertico-posframe requires Emacs 26 and do not support mouse click.
>
> ** How to enable vertico-posframe
> (require 'vertico-posframe)
> (vertico-posframe-mode 1)
>
> URL: https://github.com/tumashu/vertico-posframe
Would it make sense to bundle this directly in Vertico?
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: master f8fed41 2/3: image-dired: Improve XDG compliance
@ 2021-10-25 16:14 99% ` Philip Kaludercic
0 siblings, 2 replies; 200+ results
From: Philip Kaludercic @ 2021-10-25 16:14 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Stefan Kangas, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
> XDG is also prone to fashion changes. What will we do when it goes
> out of fashion, and we have dozens of xdg-user-dir calls in our
> application code? change all of them to some latest desktop fashion?
What do you mean by this? Shouldn't XDG as a specification prevent this
from being an issue?
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: master f8fed41 2/3: image-dired: Improve XDG compliance
@ 2021-10-25 17:52 95% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-10-25 17:52 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: stefan, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: Stefan Kangas <stefan@marxist.se>, emacs-devel@gnu.org
>> Date: Mon, 25 Oct 2021 16:14:33 +0000
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> > XDG is also prone to fashion changes. What will we do when it goes
>> > out of fashion, and we have dozens of xdg-user-dir calls in our
>> > application code? change all of them to some latest desktop fashion?
>>
>> What do you mean by this? Shouldn't XDG as a specification prevent this
>> from being an issue?
>
> Sorry, I don't understand the second question. What can "XDG as a
> specification" prevent?
I misunderstood what you meant by fashion, assuming you meant how XDG
was implemented was a matter of fashion.
> It cannot prevent XDG ceasing to be the fashion, that's entirely out
> of control of any specification. Fashions some and go, and when they
> come, users rightfully expect us to support the latest fashions, and
> we generally comply.
If anything, I think XDG is becoming more and more popular since 2003,
and I wouldn't know of any other serious contender to replace XDG.
Generally I'd agree that it would be better to provide better support
for the problem XDG solves, without having to use XDG directly for
cross-platform compliance, but XDG is certainly preferable to
hard-coding directories as is still done in Emacs.
--
Philip Kaludercic
^ permalink raw reply [relevance 95%]
* Re: master f8fed41 2/3: image-dired: Improve XDG compliance
@ 2021-10-25 17:55 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-10-25 17:55 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Eli Zaretskii, Stefan Kangas, emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> Philip Kaludercic [2021-10-25 16:14:33] wrote:
>> Eli Zaretskii <eliz@gnu.org> writes:
>>> XDG is also prone to fashion changes. What will we do when it goes
>>> out of fashion, and we have dozens of xdg-user-dir calls in our
>>> application code? change all of them to some latest desktop fashion?
>> What do you mean by this?
>
> The YEH spec from the Wayland++ guys is quite different, for one.
I have never heard of this, nor can I find any information about YEH.
Do you have a link or some other pointer?
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: [ELPA] New package: vertico-posframe
@ 2021-10-26 9:12 99% ` Philip Kaludercic
2021-10-27 18:00 99% ` Philip Kaludercic
1 sibling, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-10-26 9:12 UTC (permalink / raw)
To: tumashu; +Cc: mail, emacs-devel@gnu.org
tumashu <tumashu@163.com> writes:
> At 2021-10-26 00:13:16, "Philip Kaludercic" <philipk@posteo.net> wrote:
>>tumashu <tumashu@163.com> writes:
>>
>>> ** What is vertico-posframe
>>> vertico-posframe is an vertico extension, which lets vertico use posframe to show its candidate menu.
>>> NOTE: vertico-posframe requires Emacs 26 and do not support mouse click.
>>>
>>> ** How to enable vertico-posframe
>>> (require 'vertico-posframe)
>>> (vertico-posframe-mode 1)
>>>
>>> URL: https://github.com/tumashu/vertico-posframe
>>
>>Would it make sense to bundle this directly in Vertico?
>
> I think vertico prefer keep simple and less code, so we should see the opinion of Daniel Mendler
No problem, then it should be possible to add your package too. I will
look over the code later today to check if there is anything that might
be worth discussing.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: master f8fed41 2/3: image-dired: Improve XDG compliance
@ 2021-10-26 16:47 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-10-26 16:47 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: stefan, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: stefan@marxist.se, emacs-devel@gnu.org
>> Date: Mon, 25 Oct 2021 17:52:56 +0000
>>
>> If anything, I think XDG is becoming more and more popular since 2003,
>> and I wouldn't know of any other serious contender to replace XDG.
>
> Yes, XDG is the current fashion. As were the ones before it.
What time frames are we talking about? Fashion can be anything that
remains popular for only a few months up until something that dominates
the scene for years or decades. XDG appears to lean towards the latter.
>> Generally I'd agree that it would be better to provide better support
>> for the problem XDG solves, without having to use XDG directly for
>> cross-platform compliance, but XDG is certainly preferable to
>> hard-coding directories as is still done in Emacs.
>
> I wasn't suggesting we hard-code directories, I suggested something
> quite different.
I understood that, my point was that using XDG is preferable to that,
and anything that abstracts over XDG might be even better.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: [ELPA] New package: vertico-posframe
@ 2021-10-26 16:51 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-10-26 16:51 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Daniel Mendler, emacs-devel, Iñigo Serna, tumashu
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> Indeed, the packages should not be bundled together. vertico-posframe is
>> an independent component, which pulls in a third-party dependency.
>
> I don't have an opinion on how those should be packaged, but I'll just
> point out that Vertico would not needed to have `posframe` in its
> `Package-Requires` in order to provide support for Posframe.
Yes, this was what I was thinking about. A soft dependency that would
raise an error of the posframe part were actually required, but would
otherwise ignore it.
But as Daniel has said he prefers not to do it this way, we can add
vertico-posframe as a separate package.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: GNU ELPA package proposal: visual-fill-column
@ 2021-10-26 19:03 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-10-26 19:03 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Joost Kremers, Stefan Kangas, Emacs developers
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> Stefan Kangas [2021-10-26 17:17:16] wrote:
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> No, `package.el` is not smart enough. The reason is that the version
>>> numbers used by MELPA don't match the ones used in GNU ELPA, so the
>>> MELPA versions always seem to be "much higher" than the ones in GNU ELPA
>>> (e.g. 20180223.223 > 5.7.2).
>> Maybe we should fix that. Could it be as easy as looking for version
>> numbers starting with "YYYYMMDD", and if there is no package available
>> with a version formatted that way, just assume that the currently
>> highest numbered "normally versioned" package is more recent?
>
> Assuming would definitely not be a good idea because scenarios where
> this is a bad idea aren't sufficiently hypothetical, IMO.
Yes, there are packages on both GNU and NonGNU ELPA that use this as
their stable versioning scheme.
> But we could add a hack that would detect such cases are prompt the user.
How about introducing a package header to indicate that the versioning
scheme, so that package.el can fix it?
> Better if we could get the release date of the package version 5.7.2 ;-)
>
>
> Stefan
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: [ELPA] New package: vertico-posframe
2021-10-26 9:12 99% ` Philip Kaludercic
@ 2021-10-27 18:00 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-10-27 18:00 UTC (permalink / raw)
To: tumashu; +Cc: mail, emacs-devel@gnu.org
Philip Kaludercic <philipk@posteo.net> writes:
> tumashu <tumashu@163.com> writes:
>
>> At 2021-10-26 00:13:16, "Philip Kaludercic" <philipk@posteo.net> wrote:
>>>tumashu <tumashu@163.com> writes:
>>>
>>>> ** What is vertico-posframe
>>>> vertico-posframe is an vertico extension, which lets vertico use posframe to show its candidate menu.
>>>> NOTE: vertico-posframe requires Emacs 26 and do not support mouse click.
>>>>
>>>> ** How to enable vertico-posframe
>>>> (require 'vertico-posframe)
>>>> (vertico-posframe-mode 1)
>>>>
>>>> URL: https://github.com/tumashu/vertico-posframe
>>>
>>>Would it make sense to bundle this directly in Vertico?
>>
>> I think vertico prefer keep simple and less code, so we should see the opinion of Daniel Mendler
>
> No problem, then it should be possible to add your package too. I will
> look over the code later today to check if there is anything that might
> be worth discussing.
The package builds as expected so I'll add it with auto-syncing as there
haven't been any objections. I'd just question why you are requiring
cl-lib? It seems you aren't using it?
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* [ELPA] Add embark
@ 2021-10-30 20:28 94% Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-10-30 20:28 UTC (permalink / raw)
To: emacs-devel
Hi,
I'd like to propose adding the "embark"[0] package to GNU
ELPA. Functionality wise, it describes itself as "sort of right-click
contextual menu", and it seems to have attracted a lot of attention
recently.
The only issue is that all but one contributor has signed the copyright
assignment[1]. Yet Protesilaos Stavrou claims his contributions do not
amount to a "significant contribution", and thus should not block the
addition of Embark to GNU ELPA[2]:
> [...]
>
> A quick check:
>
> - `eebbcf8` contains two typos and an indentation change. Even they
> are still applicable, they are a negligible change for our legal
> purposes.
>
> - `a35d9de` makes some changes to `embark-act`. I would expect those
> to no longer apply, given that this command has changed a lot over
> time. `git blame` tells me that nothing of that remains, but please
> double check.
>
> - `4790949` adds three lines of docs and a small code sample to the
> README. A quick look suggests that it no longer exists.
>
> - `7c42885` changes the old implementation of keymaps and affects the
> `embark-keymap` function. That function no longer exists. It has
> been replaced by `embark-keymap-help` and `embark-keymap-prompter`.
> Again, `git blame` tells me that no old code remains.
>
> - `34ebcb9` is also about the old keymap implementation. Those
> have undergone thoroughgoing reform since last year.
>
> In conclusion: what remains from DK's contributions does not block the
> process. Please verify those findings, otherwise embark is eligible
> for inclusion in GNU ELPA.
>
> And I claim that this does not constitute a blocking issue, because I
> have read before on emacs-devel (I think by Richard Stallman?) that in
> cases where we cannot secure the paperwork, the relevant code needs to
> be written anew. In other words, Git history does not count, but only
> the current files. Though please confirm this with the Emacs
> maintainers.
If this is true, I would take care of adding Embark to GNU ELPA.
[0] https://github.com/oantolin/embark
[1] https://github.com/oantolin/embark/issues/233
[2] https://github.com/oantolin/embark/issues/233#issuecomment-890383731
--
Philip Kaludercic
^ permalink raw reply [relevance 94%]
* Re: [ELPA] Add embark
@ 2021-10-31 8:22 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-10-31 8:22 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> The only issue is that all but one contributor has signed the copyright
>> assignment[1]. Yet Protesilaos Stavrou claims his contributions do not
>> amount to a "significant contribution", and thus should not block the
>> addition of Embark to GNU ELPA[2]:
>
> [ At first I read the above to mean that Protesilaos was claiming that
> his own contributions were insignificant, implying that he was the
> last remaining contributor not covered by paperwork, which made me
> doubt my memory, so I went to double check and after finding that he
> indeed had signed the paperwork I finally re-read the above and
> understood what you meant ;-) ]
Whoops, I recognize the potential for confusion, phrased that stupidly.
To clarify, an anonymous contributor "DK" hasn't responded to the call to
add Embark to GNU ELPA, but it turns out that they didn't contribute
enough to prevent the package from being added.
> Indeed, I confirm his analysis. Some of those contributions can still
> be traced to the latest code, but it's small enough to fall below the
> "trivial" threshold, IMO.
Ok, great! I will add the "embark" and "embark-consult" packages then.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: GNU ELPA package proposal: visual-fill-column
@ 2021-11-01 20:27 99% ` Philip Kaludercic
1 sibling, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-11-01 20:27 UTC (permalink / raw)
To: Joost Kremers; +Cc: emacs-devel
Joost Kremers <joostkremers@fastmail.fm> writes:
> Hi list,
>
> Philip Kaludercic asked me if I would be interested in adding my package
> `visual-fill-column` to GNU ELPA.[1] While I'm still a bit hazy on the details
> (though I'm sure it will all clear itself up it due time), I do know the process
> starts with a copyright assignment. I haven't done that yet, so my first
> question is: how do I do that?
So should visual-fill-column be added or not? I think it is a popular
enough package to warrant adding now, even if the functionality might
later be reimplemented in C.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: GNU ELPA package proposal: visual-fill-column
@ 2021-11-01 23:39 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-11-01 23:39 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Joost Kremers, emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> Philip Kaludercic asked me if I would be interested in adding my package
>>> `visual-fill-column` to GNU ELPA.[1] While I'm still a bit hazy on the details
>>> (though I'm sure it will all clear itself up it due time), I do know the process
>>> starts with a copyright assignment. I haven't done that yet, so my first
>>> question is: how do I do that?
>> So should visual-fill-column be added or not? I think it is a popular
>> enough package to warrant adding now, even if the functionality might
>> later be reimplemented in C.
>
> Of course.
Ok, has Joost completed the copyright assignment?
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: [nongnu] main e7a6b32: * elpa-packages (haml-mode): Manually pin a version
@ 2021-11-02 8:08 97% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-11-02 8:08 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> + ;; The version attribute is set to "0", yet the the maintainer(s?)
>>> + ;; seem unresponsive (https://github.com/nex3/haml-mode/issues/40)
>>> + ;; and thus the package isn't published on the main archive. We
>>> + ;; manually set the latest commit to a proper version number:
>>> + :version-map ((nil "3.1.10" "bf5b6c11b1206759d2b28af48765e04882dd1fc4")))
>> It seems that despite pinning a release, no package was released on the
>> default archive? This should be done to fix the incompatibility in
>> sass-mode dependency list.
>
> I believe I just fixed it (we'll see if the package gets released).
> The above map means "use 3.1.10 if there's no Version:".
> Of course, that doesn't fix issue #40 :-(
True, but it seems that haml-mode is practically abandoned. The
maintainer is still active, but there appears to be no activity on their
Emacs Lisp packages.
And on the topic of broken packages, it seems color-theme-tangotango is
still part of NonGNU ELPA, even though I have removed it from
elpa-packages and (attempted to) deleted the branch. Is there something
I am forgetting?
--
Philip Kaludercic
^ permalink raw reply [relevance 97%]
* Re: ELPA: add mct.el
@ 2021-11-11 15:34 99% ` Philip Kaludercic
2021-11-14 0:00 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-11-11 15:34 UTC (permalink / raw)
To: Theodor Thornhill
Cc: Protesilaos Stavrou, James Norman Vladimir Cash, emacs-devel
Theodor Thornhill <theo@thornhill.no> writes:
> Hi!
>
>> Hello everyone,
>> I have a package called "Minibuffer and Completions in Tandem" (MCT,
>> mct, mct.el, ...) that I want to submit to GNU ELPA. Patch attached.
>>
>
>
> I'm not really the target for this mail, but I'll just chime in that
> I've been using this package for a little while, and I enjoy it. I've
> always liked the idea of having the completions in a buffer rather than
> using the layouts offered by ido/fido/vertico etc etc. However, I never
> took the time to hack together something like this. So thanks, Prot :)
>
> I'd love to see this in elpa too!
You don't have to wait, it has already been added:
http://elpa.gnu.org/packages/mct.html.
The reason you might not have noticed is that it depends on Emacs 28.1,
that hasn't been released yet (you'd at best have version 28.0.60).
> Theodor Thornhill
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: ELPA: add mct.el
2021-11-11 15:34 99% ` Philip Kaludercic
@ 2021-11-14 0:00 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-11-14 0:00 UTC (permalink / raw)
To: Protesilaos Stavrou; +Cc: emacs-devel
Philip Kaludercic <philipk@posteo.net> writes:
> The reason you might not have noticed is that it depends on Emacs 28.1,
> that hasn't been released yet (you'd at best have version 28.0.60).
Prot, do you indent to "fix" this issue or do you want to wait until
Emacs 28.1 is released?
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: [ELPA] new package: sndio.el
@ 2021-11-14 18:17 93% ` Philip Kaludercic
0 siblings, 2 replies; 200+ results
From: Philip Kaludercic @ 2021-11-14 18:17 UTC (permalink / raw)
To: Omar Polo; +Cc: emacs-devel
Omar Polo <op@omarpolo.com> writes:
> Hello,
>
> Some time ago to scratch an itch I wrote sndio.el, a package to interact
> with the OpenBSD' audio daemon sndiod(8). Recently, I've enhanced it a
> bit and added an hydra-like window for a quick interaction and thought
> it may be useful to others, so here's the submission. It should work
> outside of OpenBSD too provided that you're running sndio and have
> sndioctl(1), but I never tried.
From what I see, if I were to download and run the package on a GNU
System without sndio, there wouldn't be any clear error message
indicating what went wrong, just an error message indicating that
sndioctl has failed, right? (this is just from reading and using faulty
mental evaluation). If the package is to be added to GNU ELPA, you
should probably add a explicit error message (perhaps even at compile
time) to clarify what is missing, and that the package isn't mean to
work on this system.
> There's a small gif on the repo that shows sndio.el in action:
>
> https://git.omarpolo.com/sndio.el/about/
>
> I was able to fetch and checkout the source in the elpa repository using
> the attached diff.
The source looks good, I can add it to GNU ELPA if there are no objections.
> Thanks,
>
> Omar Polo
>
> diff --git a/elpa-packages b/elpa-packages
> index efa53e3e40..2e21c9bffb 100644
> --- a/elpa-packages
> +++ b/elpa-packages
> @@ -438,6 +438,7 @@
> ("smalltalk-mode" :url nil) ;; Was "git://git.sv.gnu.org/smalltalk"
> ("smart-yank" :url nil)
> ("sml-mode" :url nil)
> + ("sndio" :url "https://git.omarpolo.com/sndio.el")
> ("so-long" :core "lisp/so-long.el")
> ("soap-client" :core ("lisp/net/soap-client.el" "lisp/net/soap-inspect.el"))
> ("sokoban" :url nil)
>
>
--
Philip Kaludercic
^ permalink raw reply [relevance 93%]
* Re: [RFC] certfp for rcirc
@ 2021-11-14 18:25 94% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-11-14 18:25 UTC (permalink / raw)
To: Omar Polo; +Cc: Emacs developers
Omar Polo <op@omarpolo.com> writes:
> For some reason I don't know yet, the NickServ still says that I've got
> 30 seconds to identify myself, but in reality I'm already logged in. I
> don't know basically anything about how the irc protocol works, so I'm
> probably missing something incredibly obvious.
Have you experienced any issues since? It might also be that this is a
server side issue? What do other clients say?
> What do you think?
I think this would be a good addition. One might even want to go
further and add functions to automate the certfp authentication. But
that might be a too much for rcirc.
Also, the manual should be updated to explain how this works.
> Cheers,
>
> Omar Polo
>
>
> diff --git a/lisp/net/rcirc.el b/lisp/net/rcirc.el
> index 52d74a3394..070218ef0a 100644
> --- a/lisp/net/rcirc.el
> +++ b/lisp/net/rcirc.el
> @@ -262,10 +262,12 @@ The ARGUMENTS for each METHOD symbol are:
> `bitlbee': NICK PASSWORD
> `quakenet': ACCOUNT PASSWORD
> `sasl': NICK PASSWORD
> + `certfp': KEY CERT
>
> Examples:
> ((\"Libera.Chat\" nickserv \"bob\" \"p455w0rd\")
> (\"Libera.Chat\" chanserv \"bob\" \"#bobland\" \"passwd99\")
> + (\"Libera.Chat\" certfp \"/path/to/key.pem\" \"/path/to/cert.pem\")
> (\"bitlbee\" bitlbee \"robert\" \"sekrit\")
> (\"dal.net\" nickserv \"bob\" \"sekrit\" \"NickServ@services.dal.net\")
> (\"quakenet.org\" quakenet \"bobby\" \"sekrit\")
> @@ -291,7 +293,11 @@ Examples:
> (list :tag "SASL"
> (const sasl)
> (string :tag "Nick")
> - (string :tag "Password")))))
> + (string :tag "Password"))
> + (list :tag "CertFP"
> + (const certfp)
> + (string :tag "Key")
> + (string :tag "Certificate")))))
>
> (defcustom rcirc-auto-authenticate-flag t
> "Non-nil means automatically send authentication string to server.
> @@ -547,6 +553,9 @@ If ARG is non-nil, instead prompt for connection parameters."
> (password (plist-get (cdr c) :password))
> (encryption (plist-get (cdr c) :encryption))
> (server-alias (plist-get (cdr c) :server-alias))
> + (client-cert (when (eq (rcirc-get-server-method (car c))
> + 'certfp)
> + (rcirc-get-server-cert (car c))))
> contact)
> (when-let (((not password))
> (auth (auth-source-search :host server
> @@ -563,7 +572,7 @@ If ARG is non-nil, instead prompt for connection parameters."
> (condition-case nil
> (let ((process (rcirc-connect server port nick user-name
> full-name channels password encryption
> - server-alias)))
> + client-cert server-alias)))
> (when rcirc-display-server-buffer
> (pop-to-buffer-same-window (process-buffer process))))
> (quit (message "Quit connecting to %s"
> @@ -662,13 +671,22 @@ See `rcirc-connect' for more details on these variables.")
> (when (string-match server-i server)
> (throw 'pass (car args)))))))
>
> +(defun rcirc-get-server-cert (server)
> + "Return a list of key and certificate for SERVER."
> + (catch 'pass
> + (dolist (i rcirc-authinfo)
> + (let ((server-i (car i))
> + (args (cddr i)))
> + (when (string-match server-i server)
> + (throw 'pass args))))))
Why not use alist-get with a test function?
> ;;;###autoload
> (defun rcirc-connect (server &optional port nick user-name
> full-name startup-channels password encryption
> - server-alias)
> + certfp server-alias)
> "Connect to SERVER.
> The arguments PORT, NICK, USER-NAME, FULL-NAME, PASSWORD,
> -ENCRYPTION, SERVER-ALIAS are interpreted as in
> +ENCRYPTION, CERTFP, SERVER-ALIAS are interpreted as in
> `rcirc-server-alist'. STARTUP-CHANNELS is a list of channels
> that are joined after authentication."
> (save-excursion
> @@ -692,10 +710,16 @@ that are joined after authentication."
> (delete-process process))
>
> ;; Set up process
> - (setq process (open-network-stream
> - (or server-alias server) nil server port-number
> - :type (or encryption 'plain)
> - :nowait t))
> + (setq process (if certfp
> + (open-network-stream
> + (or server-alias server) nil server port-number
> + :type 'tls
> + :nowait t
> + :client-certificate certfp)
Is this case-distinction necessary? If `certfp' is nil, then
open-network-stream should just ignore the argument if I am not
mistaken.
> + (open-network-stream
> + (or server-alias server) nil server port-number
> + :type (or encryption 'plain)
> + :nowait t)))
> (set-process-coding-system process 'raw-text 'raw-text)
> (with-current-buffer (get-buffer-create (rcirc-generate-new-buffer-name process nil))
> (set-process-buffer process (current-buffer))
>
>
--
Philip Kaludercic
^ permalink raw reply [relevance 94%]
* Re: [ELPA] new package: sndio.el
@ 2021-11-14 18:32 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-11-14 18:32 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Omar Polo, emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> From what I see, if I were to download and run the package on a GNU
>> System without sndio, there wouldn't be any clear error message
>> indicating what went wrong, just an error message indicating that
>> sndioctl has failed, right? (this is just from reading and using faulty
>> mental evaluation). If the package is to be added to GNU ELPA, you
>> should probably add a explicit error message (perhaps even at compile
>> time) to clarify what is missing, and that the package isn't mean to
>> work on this system.
>
> From where I stand, OTOH, I'd ask not to emit an error or warning during
> compilation (e.g. I compile all the files in elpa.git and I don't have
> sndio). Similarly, don't sign an error when loading `sndio.el` (a
> warning is tolerable).
I did not consider that. In that case a warning/error is certainly not
acceptable.
It should probably suffice to just throw an error when calling the
autoloaded `sndio' command.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: [ELPA] new package: sndio.el
@ 2021-11-14 18:46 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-11-14 18:46 UTC (permalink / raw)
To: Omar Polo; +Cc: emacs-devel
Omar Polo <op@omarpolo.com> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Omar Polo <op@omarpolo.com> writes:
>>
>>> Hello,
>>>
>>> Some time ago to scratch an itch I wrote sndio.el, a package to interact
>>> with the OpenBSD' audio daemon sndiod(8). Recently, I've enhanced it a
>>> bit and added an hydra-like window for a quick interaction and thought
>>> it may be useful to others, so here's the submission. It should work
>>> outside of OpenBSD too provided that you're running sndio and have
>>> sndioctl(1), but I never tried.
>>
>> From what I see, if I were to download and run the package on a GNU
>> System without sndio, there wouldn't be any clear error message
>> indicating what went wrong, just an error message indicating that
>> sndioctl has failed, right? (this is just from reading and using faulty
>> mental evaluation). If the package is to be added to GNU ELPA, you
>> should probably add a explicit error message (perhaps even at compile
>> time) to clarify what is missing, and that the package isn't mean to
>> work on this system.
>
> Yes, as things are now if sndio-sndioctl-cmd is not found `sndio-update'
> fails with a generic error due to process-file not finding the
> executable.
>
> Would something like this be a viable option?
>
> --- sndio.el
> +++ sndio.el
> @@ -67,6 +67,8 @@
> (defun sndio-update ()
> "Update the current sndio buffer."
> (interactive)
> + (unless (executable-find sndio-sndioctl-cmd)
> + (error "Can't find executable %s" sndio-sndioctl-cmd))
> (when (derived-mode-p 'sndio-mode)
> (let ((inhibit-read-only t))
> (erase-buffer)
>
> (sndio-update is the first function called in both the entrypoints of
> the package, so it seems a good place for such a check)
This looks like a good place to add the check. I just have two
questions:
1. Should an error or a user-error be raised?
2. Should the error message be more explicit, and mention that sndio
isn't being used on the current system?
>>> There's a small gif on the repo that shows sndio.el in action:
>>>
>>> https://git.omarpolo.com/sndio.el/about/
>>>
>>> I was able to fetch and checkout the source in the elpa repository using
>>> the attached diff.
>>
>> The source looks good, I can add it to GNU ELPA if there are no objections.
>>
>>> Thanks,
>>>
>>> Omar Polo
>>>
>>> diff --git a/elpa-packages b/elpa-packages
>>> index efa53e3e40..2e21c9bffb 100644
>>> --- a/elpa-packages
>>> +++ b/elpa-packages
>>> @@ -438,6 +438,7 @@
>>> ("smalltalk-mode" :url nil) ;; Was "git://git.sv.gnu.org/smalltalk"
>>> ("smart-yank" :url nil)
>>> ("sml-mode" :url nil)
>>> + ("sndio" :url "https://git.omarpolo.com/sndio.el")
>>> ("so-long" :core "lisp/so-long.el")
>>> ("soap-client" :core ("lisp/net/soap-client.el" "lisp/net/soap-inspect.el"))
>>> ("sokoban" :url nil)
>>>
>>>
>
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Grammar checking in Emacs
@ 2021-11-16 18:01 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-11-16 18:01 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel, Daniel Martín
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> I recently enhanced flycheck-languagetool so that it’s able to start its own
>> server if so configured, so I’m sure something similar could be done with
>> the various other LanguageTool modes.
>
> Any chance you could port it to `flymake` and contribute it to GNU ELPA?
Should this use flymake or should ispell be generalized to handle
grammar checking as well? Usually flymake doesn't offer you direct
suggestions on how to fix code (or at least I haven't seen it yet),
while ispell gives me a list of possible fixes.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: [RFC] certfp for rcirc
@ 2021-11-17 20:23 99% ` Philip Kaludercic
2021-11-21 18:01 99% ` Philip Kaludercic
1 sibling, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-11-17 20:23 UTC (permalink / raw)
To: Omar Polo; +Cc: Emacs developers
Omar Polo <op@omarpolo.com> writes:
> I messed up with the third diff, here's another try :)
It looks good to me, I will push these changes to master in the coming days.
> From f96474342caca8aa1df4f5df66ce1a2c0e4ed976 Mon Sep 17 00:00:00 2001
> From: Omar Polo <op@omarpolo.com>
> Date: Mon, 15 Nov 2021 17:33:51 +0000
> Subject: [PATCH 1/3] Move the sasl section after the bitlbee text
>
> ---
> doc/misc/rcirc.texi | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/doc/misc/rcirc.texi b/doc/misc/rcirc.texi
> index a4ca54a8b0..696983dc77 100644
> --- a/doc/misc/rcirc.texi
> +++ b/doc/misc/rcirc.texi
> @@ -609,12 +609,6 @@ Use this symbol if you need to identify yourself in the Bitlbee channel
> as follows: @code{identify secret}. The necessary arguments are the
> nickname you want to use this for, and the password to use.
>
> -@item sasl
> -@cindex sasl authentication
> -Use this symbol if you want to use @acronym{SASL} authentication. The
> -necessary arguments are the nickname you want to use this for, and the
> -password to use.
> -
> @cindex gateway to other IM services
> @cindex instant messaging, other services
> @cindex Jabber
> @@ -633,6 +627,12 @@ the other instant messaging services, and Bitlbee will log you in. All
> @code{rcirc} needs to know, is the login to your Bitlbee account. Don't
> confuse the Bitlbee account with all the other accounts.
>
> +@item sasl
> +@cindex sasl authentication
> +Use this symbol if you want to use @acronym{SASL} authentication. The
> +necessary arguments are the nickname you want to use this for, and the
> +password to use.
> +
> @end table
>
> @end table
> --
> 2.33.1
>
> From 6fda9317fbe496c36d1e5be4fa15dd3569a26aa1 Mon Sep 17 00:00:00 2001
> From: Omar Polo <op@omarpolo.com>
> Date: Mon, 15 Nov 2021 17:40:58 +0000
> Subject: [PATCH 2/3] implement certfp authentication to rcirc
>
> * lisp/net/rcirc.el (rcirc-connect): Use the provided client certs
> * doc/misc/rcirc.texi (Configuration): Document the change
> ---
> doc/misc/rcirc.texi | 7 +++++++
> lisp/net/rcirc.el | 26 ++++++++++++++++++++++----
> 2 files changed, 29 insertions(+), 4 deletions(-)
>
> diff --git a/doc/misc/rcirc.texi b/doc/misc/rcirc.texi
> index 696983dc77..58ca045e78 100644
> --- a/doc/misc/rcirc.texi
> +++ b/doc/misc/rcirc.texi
> @@ -633,6 +633,13 @@ Use this symbol if you want to use @acronym{SASL} authentication. The
> necessary arguments are the nickname you want to use this for, and the
> password to use.
>
> +@item certfp
> +@cindex certfp authentication
> +Use this symbol if you want to use CertFP authentication. The
> +necessary arguments are the path to the client certificate key and
> +password. The CertFP authentication requires a @acronym{TLS}
> +connection.
> +
> @end table
>
> @end table
> diff --git a/lisp/net/rcirc.el b/lisp/net/rcirc.el
> index 5c92c60eda..6030db9dae 100644
> --- a/lisp/net/rcirc.el
> +++ b/lisp/net/rcirc.el
> @@ -262,6 +262,7 @@ The ARGUMENTS for each METHOD symbol are:
> `bitlbee': NICK PASSWORD
> `quakenet': ACCOUNT PASSWORD
> `sasl': NICK PASSWORD
> + `certfp': KEY CERT
>
> Examples:
> ((\"Libera.Chat\" nickserv \"bob\" \"p455w0rd\")
> @@ -291,7 +292,11 @@ Examples:
> (list :tag "SASL"
> (const sasl)
> (string :tag "Nick")
> - (string :tag "Password")))))
> + (string :tag "Password"))
> + (list :tag "CertFP"
> + (const certfp)
> + (string :tag "Key")
> + (string :tag "Certificate")))))
>
> (defcustom rcirc-auto-authenticate-flag t
> "Non-nil means automatically send authentication string to server.
> @@ -547,6 +552,9 @@ If ARG is non-nil, instead prompt for connection parameters."
> (password (plist-get (cdr c) :password))
> (encryption (plist-get (cdr c) :encryption))
> (server-alias (plist-get (cdr c) :server-alias))
> + (client-cert (when (eq (rcirc-get-server-method (car c))
> + 'certfp)
> + (rcirc-get-server-cert (car c))))
> contact)
> (when-let (((not password))
> (auth (auth-source-search :host server
> @@ -563,7 +571,7 @@ If ARG is non-nil, instead prompt for connection parameters."
> (condition-case nil
> (let ((process (rcirc-connect server port nick user-name
> full-name channels password encryption
> - server-alias)))
> + client-cert server-alias)))
> (when rcirc-display-server-buffer
> (pop-to-buffer-same-window (process-buffer process))))
> (quit (message "Quit connecting to %s"
> @@ -662,13 +670,22 @@ See `rcirc-connect' for more details on these variables.")
> (when (string-match server-i server)
> (throw 'pass (car args)))))))
>
> +(defun rcirc-get-server-cert (server)
> + "Return a list of key and certificate for SERVER."
> + (catch 'cert
> + (dolist (i rcirc-authinfo)
> + (let ((server-i (car i))
> + (args (cddr i)))
> + (when (string-match server-i server)
> + (throw 'cert args))))))
> +
> ;;;###autoload
> (defun rcirc-connect (server &optional port nick user-name
> full-name startup-channels password encryption
> - server-alias)
> + certfp server-alias)
> "Connect to SERVER.
> The arguments PORT, NICK, USER-NAME, FULL-NAME, PASSWORD,
> -ENCRYPTION, SERVER-ALIAS are interpreted as in
> +ENCRYPTION, CERTFP, SERVER-ALIAS are interpreted as in
> `rcirc-server-alist'. STARTUP-CHANNELS is a list of channels
> that are joined after authentication."
> (save-excursion
> @@ -695,6 +712,7 @@ that are joined after authentication."
> (setq process (open-network-stream
> (or server-alias server) nil server port-number
> :type (or encryption 'plain)
> + :client-certificate certfp
> :nowait t))
> (set-process-coding-system process 'raw-text 'raw-text)
> (with-current-buffer (get-buffer-create (rcirc-generate-new-buffer-name process nil))
> --
> 2.33.1
>
> From a21962b6213cef558ae9294d41e14d42035495fc Mon Sep 17 00:00:00 2001
> From: Omar Polo <op@omarpolo.com>
> Date: Mon, 15 Nov 2021 21:49:23 +0000
> Subject: [PATCH 3/3] ; Simplify rcirc authentication querying functions
>
> ---
> lisp/net/rcirc.el | 21 +++------------------
> 1 file changed, 3 insertions(+), 18 deletions(-)
>
> diff --git a/lisp/net/rcirc.el b/lisp/net/rcirc.el
> index 6030db9dae..b4e9031e0d 100644
> --- a/lisp/net/rcirc.el
> +++ b/lisp/net/rcirc.el
> @@ -654,30 +654,15 @@ See `rcirc-connect' for more details on these variables.")
>
> (defun rcirc-get-server-method (server)
> "Return authentication method for SERVER."
> - (catch 'method
> - (dolist (i rcirc-authinfo)
> - (let ((server-i (car i))
> - (method (cadr i)))
> - (when (string-match server-i server)
> - (throw 'method method))))))
> + (cadr (assoc server rcirc-authinfo #'string-match)))
>
> (defun rcirc-get-server-password (server)
> "Return password for SERVER."
> - (catch 'pass
> - (dolist (i rcirc-authinfo)
> - (let ((server-i (car i))
> - (args (cdddr i)))
> - (when (string-match server-i server)
> - (throw 'pass (car args)))))))
> + (cadddr (assoc server rcirc-authinfo #'string-match)))
>
> (defun rcirc-get-server-cert (server)
> "Return a list of key and certificate for SERVER."
> - (catch 'cert
> - (dolist (i rcirc-authinfo)
> - (let ((server-i (car i))
> - (args (cddr i)))
> - (when (string-match server-i server)
> - (throw 'cert args))))))
> + (cddr (assoc server rcirc-authinfo #'string-match)))
>
> ;;;###autoload
> (defun rcirc-connect (server &optional port nick user-name
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: could matlab-mode be in ELPA or the GNU emacs tree (like auctex and org-mode)?
@ 2021-11-20 22:42 98% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-11-20 22:42 UTC (permalink / raw)
To: Uwe Brauer; +Cc: emacs-devel
Uwe Brauer <oub@mat.ucm.es> writes:
> However, before addressing this problem, I would like to know:
>
> Could matlab-mode become part of ELPA or even could dwell in the GNU
> emacs tree?
If the CA situation is solved, there shouldn't be an issue with adding
the package to GNU ELPA (and later perhaps GNU Emacs), but...
> I know that matlab is a commercial product and its license is not
> compatible with the GPL, but the same could be said about MS Windows OS
> and MacOS and yet GNU Emacs support these OSs.
my understanding is that the GNU Project doesn't want to refer to
propitiatory software and/or incentivise it's users to use non-free
software. With Mathlab, there is the additional issue that GNU Octave
exists.
> It would benefit the users of matlab who wish to use GNU Emacs for coding.
>
> Regards
>
> Uwe Brauer
>
--
Philip Kaludercic
^ permalink raw reply [relevance 98%]
* Re: [RFC] certfp for rcirc
2021-11-17 20:23 99% ` Philip Kaludercic
@ 2021-11-21 18:01 99% ` Philip Kaludercic
1 sibling, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-11-21 18:01 UTC (permalink / raw)
To: Omar Polo; +Cc: Emacs developers
Omar Polo <op@omarpolo.com> writes:
> I messed up with the third diff, here's another try :)
The changes have been pushed.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: File names in ChangeLog entries
@ 2021-11-30 20:07 81% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-11-30 20:07 UTC (permalink / raw)
To: Stefan Kangas; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 231 bytes --]
Stefan Kangas <stefan@marxist.se> writes:
> I recommend using `add-change-log-entry-other-window' bound to `C-x 4 a'
> to get this right.
As I use C-c C-w in log-edit, I would appreciate it if a patch like this
could be merged:
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Use-VC-relative-file-names-in-ChangeLog-entries.patch --]
[-- Type: text/x-patch, Size: 1285 bytes --]
From f3f87cab56d1bc1754d9e83a9dd53d0cb48c02b0 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Tue, 30 Nov 2021 21:05:42 +0100
Subject: [PATCH] Use VC-relative file names in ChangeLog entries
* lisp/vc/diff-mode.el (diff-add-log-current-defuns): Check
vc-root-dir to prepend the project path to the file being modified.
See https://mail.gnu.org/archive/html/emacs-devel/2021-11/msg02195.html
---
lisp/vc/diff-mode.el | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/lisp/vc/diff-mode.el b/lisp/vc/diff-mode.el
index 057ffcd06e..40749754d8 100644
--- a/lisp/vc/diff-mode.el
+++ b/lisp/vc/diff-mode.el
@@ -2343,7 +2343,10 @@ diff-add-log-current-defuns
;; hunks (e.g., "diff --git ..." etc).
(re-search-forward diff-hunk-header-re nil t)
(setq hunk-end (save-excursion (diff-end-of-hunk)))
- (pcase-let* ((filename (substring-no-properties (diff-find-file-name)))
+ (pcase-let* ((filename (substring-no-properties
+ (file-relative-name
+ (diff-find-file-name)
+ (vc-root-dir))))
(=lines 0)
(+lines 0)
(-lines 0)
--
2.34.0
[-- Attachment #3: Type: text/plain, Size: 130 bytes --]
(Something is currently wrong with my Savannah account so I wouldn't be
able to push the change myself).
--
Philip Kaludercic
^ permalink raw reply related [relevance 81%]
* Re: Old (static) builds of Emacs
2021-10-07 7:03 95% ` Old (static) builds of Emacs Philip Kaludercic
@ 2021-11-30 21:21 99% ` Philip Kaludercic
2 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-11-30 21:21 UTC (permalink / raw)
To: emacs-devel
I have tried using GNU Guix to build old versions of Emacs, and it seems
to work well up until 24.5. It seems something was changed in glibc (?)
that necessitated a change in Emacs, if I understand correctly. Does
anyone remember what happened here, so that I can patch these versions
(or would it be easier to build an old version of Glibc)?
Philip Kaludercic <philipk@posteo.net> writes:
> Until now I have only been able to test the library using Emacs 27.2 and
> Emacs 28.0.50/60. This doesn't seem like enough for a library that
> actually targets older versions of Emacs.
>
> My question is therefore: Does anyone know where to download old Emacs
> builds? I have tried building 24.x and 25.x on my system, but it seems
> (?) that changes in glibc prevent this from being done.
>
> So before I have to set up virtual machines with older distributions, I
> was wondering if anyone knew of an archive with pre-build, preferably
> static, Emacs builds.
>
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Hello again,
>>
>> I have been working on compat.el over the last week, and have written a
>> number of tests. The source code has been uploaded here:
>>
>> https://git.sr.ht/~pkal/compat
>>
>> The library should be usable in it's current state, but I'd be
>> interested to hear from other people and developers too. There might be
>> missing functions or macros, edge cases that could be added to the
>> tests, etc. that could be improved.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: [PATCH] * elpa-packages (webpaste): New package
@ 2021-12-02 16:05 93% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-12-02 16:05 UTC (permalink / raw)
To: Elis Hirwing; +Cc: emacs-devel
Elis Hirwing <elis@hirwing.se> writes:
> I would like to submit a package that I maintain to the NonGNU ELPA,
> it's currently on MELPA, I've been maintaining it for years and using
> it for years.
Before someone else brings it up, have you considered adding the package
to GNU ELPA? Or are there reasons you are attempting to add the package
to NonGNU ELPA first?
> I find it to be fairly stable and usable, I mostly do releases to
> address actual bugs with remote services or addition of new remote
> services to interact with.
>
> ~ Elis
>
> From cda6d5dfd6536069793fee296c8f08100a63f869 Mon Sep 17 00:00:00 2001
> From: Elis Hirwing <elis@hirwing.se>
> Date: Thu, 2 Dec 2021 14:00:21 +0100
> Subject: [PATCH] * elpa-packages (webpaste): New package
>
> ---
> elpa-packages | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/elpa-packages b/elpa-packages
> index 0de123b1dc..10d4d4fed8 100644
> --- a/elpa-packages
> +++ b/elpa-packages
> @@ -295,6 +295,11 @@
> ("web-mode" :url "https://github.com/fxbois/web-mode"
> :ignored-files ("issues" "tests" "run.sh"))
>
> + ("webpaste" :url "https://github.com/etu/webpaste.el"
> + :ignored-files (".github" "tests" ".envrc" ".gitignore" "Cask" "Makefile" "shell.nix")
Just in case you haven't heard of it, you can also add a ".elpaignore"
file to Git, and that will be used to exclude files. If something about
your project structure were to change, it might be easier to adapt.
> + :readme "README.org"
The file "README.org" is already in the default list of files that the
ELPA build system checks if they exist. So it shouldn't be necessary.
> + :branch "main")
This also shouldn't be necessary, as long as "main" is the default
branch.
> +
> ("with-editor" :url "https://github.com/magit/with-editor"
> :ignored-files ("htmlxref.cnf" ".travis.yml" ".mailmap" "Makefile")
> :doc "with-editor.texi")
--
Philip Kaludercic
^ permalink raw reply [relevance 93%]
* Re: [PATCH] * elpa-packages (webpaste): New package
@ 2021-12-02 23:15 97% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-12-02 23:15 UTC (permalink / raw)
To: Elis Hirwing; +Cc: emacs-devel
Elis Hirwing <elis@hirwing.se> writes:
> On Thu, 2021-12-02 at 16:05 +0000, Philip Kaludercic wrote:
>> Elis Hirwing <elis@hirwing.se> writes:
>>
>> > I would like to submit a package that I maintain to the NonGNU
>> > ELPA,
>> > it's currently on MELPA, I've been maintaining it for years and
>> > using
>> > it for years.
>>
>> Before someone else brings it up, have you considered adding the
>> package
>> to GNU ELPA? Or are there reasons you are attempting to add the
>> package
>> to NonGNU ELPA first?
>
> Partly because I haven't signed the CLA with GNU and that I have
> contributors which I don't know if they have signed the CLA or not, so
> I just found it easier that way.
Looking at the contributor list, I certainly recognise more than a few
names that have signed the CA and I'd expect to agree when asked if they
would want to add the package to ELPA. It is up to you if you would
want to ask your contributors or not.
If you are sure that ELPA is not the right place, then adding the
package to NonGNU ELPA shouldn't be an issue, and would certainly be a
worthwhile addition.
--
Philip Kaludercic
^ permalink raw reply [relevance 97%]
* Re: Variable for Confirming Killing a Buffer
@ 2021-12-02 23:17 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-12-02 23:17 UTC (permalink / raw)
To: Stefan Kangas; +Cc: Oliver Taylor, emacs-devel
Stefan Kangas <stefankangas@gmail.com> writes:
> Oliver Taylor <olivertaylor@me.com> writes:
>
>> Now, doing (setq-local buffer-confirm-kill t) will prevent accidental data
>> loss.
>
> Could you describe the scenario(s) under which you have experienced
> accidental data loss in more detail? Which modes were you using?
A common example I can imagine lot of people have experienced is the
accidental killing of the *scratch* buffer.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: [PATCH] * elpa-packages (webpaste): New package
@ 2021-12-04 8:36 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-12-04 8:36 UTC (permalink / raw)
To: Po Lu; +Cc: Elis Hirwing, emacs-devel
Po Lu <luangruo@yahoo.com> writes:
> Could you please explain what "webpaste" services are? Could they be
> SaaSS by any chance?
>
> Is the software run by these services free software, and can the user
> run them locally?
The "service" of a pastebin site is to provide a method of uploading and
hosting files, often program snippets or logs. This can not be replaced
by local software, unless the user provides the same service.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: [PATCH] * elpa-packages (webpaste): New package
@ 2021-12-04 8:37 99% ` Philip Kaludercic
1 sibling, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-12-04 8:37 UTC (permalink / raw)
To: Elis Hirwing; +Cc: emacs-devel
Elis Hirwing <elis@hirwing.se> writes:
> I've now considered this and would still prefer the NonGNU ELPA.
Ok, I'll add the package specification as soon as I get my Savannah
access working again. Thank you for your contribution!
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: `csv-mode' part of core?
@ 2021-12-04 11:46 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-12-04 11:46 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: Tor Kringeland, emacs-devel
Lars Ingebrigtsen <larsi@gnus.org> writes:
> Tor Kringeland <tor.a.s.kringeland@ntnu.no> writes:
>
>> Is there a reason `csv-mode' is not part of core currently, or could it
>> be included?
>
> The plan is to bundle all the GNU ELPA packages in the Emacs releases,
> which should make the difference between a GNU ELPA package and the core
> less important. But the progress towards this has been rather ... slow. 🙃
Where could I find out more about this plan?
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Suggestions for improvements to the *Completions* buffer
@ 2021-12-09 17:22 34% Philip Kaludercic
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Philip Kaludercic @ 2021-12-09 17:22 UTC (permalink / raw)
To: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 664 bytes --]
Hi,
I'd like to suggest a few modifications to the default behaviour of
the *Completions* buffer. These are mostly conservative extensions of
the current defaults.
Currently, next-completion (and previous-completion) stops at either the
end or the beginning of a buffer. This patch would allow for the
command to also wrap around, and if the end has been reached to jump
back to the beginning. In my experience, the improvement is most
noticeable when choosing between a small number choices, and pressing
tab twice is easier than shift-tab.
Optionally, this could also be extended to only enable cycling when
there are less than n options to select from.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Allow-for-next-completion-to-wrap-around-the-complet.patch --]
[-- Type: text/x-patch, Size: 2725 bytes --]
From 250d743cf53002b4c696ad33eb76a4454c4d254c Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Thu, 9 Dec 2021 17:26:14 +0100
Subject: [PATCH 1/4] Allow for next-completion to wrap around the completion
buffer
* lisp/simple.el (completion-wrap-movement): Add new option.
(previous-completion): Update docstring.
(next-completion): Respect completion-wrap-movement.
---
lisp/simple.el | 23 +++++++++++++++++++----
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/lisp/simple.el b/lisp/simple.el
index 94a459b779..5183a7e053 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -9013,25 +9013,38 @@ delete-completion-window
(if (get-buffer-window buf)
(select-window (get-buffer-window buf))))))
+(defcustom completion-wrap-movement t
+ "Non-nil means to wrap around when selecting completion options.
+This affects the commands `next-completion' and
+`previous-completion'."
+ :type 'boolean
+ :version "29.1"
+ :group 'completion)
+
(defun previous-completion (n)
- "Move to the previous item in the completion list."
+ "Move to the previous item in the completion list.
+With prefix argument N, move back N items (negative N means move
+forward)."
(interactive "p")
(next-completion (- n)))
(defun next-completion (n)
"Move to the next item in the completion list.
-With prefix argument N, move N items (negative N means move backward)."
+With prefix argument N, move N items (negative N means move
+backward)."
(interactive "p")
(let ((beg (point-min)) (end (point-max)))
- (while (and (> n 0) (not (eobp)))
+ (while (> n 0)
;; If in a completion, move to the end of it.
(when (get-text-property (point) 'mouse-face)
(goto-char (next-single-property-change (point) 'mouse-face nil end)))
+ (when (and (eobp) completion-wrap-movement)
+ (goto-char (point-min)))
;; Move to start of next one.
(unless (get-text-property (point) 'mouse-face)
(goto-char (next-single-property-change (point) 'mouse-face nil end)))
(setq n (1- n)))
- (while (and (< n 0) (not (bobp)))
+ (while (< n 0)
(let ((prop (get-text-property (1- (point)) 'mouse-face)))
;; If in a completion, move to the start of it.
(when (and prop (eq prop (get-text-property (point) 'mouse-face)))
@@ -9041,6 +9054,8 @@ next-completion
(unless (or (bobp) (get-text-property (1- (point)) 'mouse-face))
(goto-char (previous-single-property-change
(point) 'mouse-face nil beg)))
+ (when (and (bobp) completion-wrap-movement)
+ (goto-char (point-max)))
;; Move to the start of that one.
(goto-char (previous-single-property-change
(point) 'mouse-face nil beg))
--
2.34.0
[-- Attachment #3: Type: text/plain, Size: 387 bytes --]
Currently, as soon as the minibuffer cannot expand the completion any
further, tab becomes a noop and the user is caught in a state that they
have to exit with some other command (M-v, C-g, ...). Again, just like
above, I prefer to stay on the same key, so this patch introduces a user
option to automatically switch to the completion buffer, as soon as it
pops up, to just "tab on".
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #4: 0002-Allow-for-the-completion-buffer-to-be-automatically-.patch --]
[-- Type: text/x-patch, Size: 1412 bytes --]
From 4bc0d69c00cc650ec2be437ac7d45ccad7926ea1 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Thu, 9 Dec 2021 17:34:54 +0100
Subject: [PATCH 2/4] Allow for the completion buffer to be automatically
selected
* lisp/simple.el (completion-auto-select): Add new option.
(completion-setup-function): Respect completion-auto-select.
---
lisp/simple.el | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/lisp/simple.el b/lisp/simple.el
index 5183a7e053..b5f5122153 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -9227,6 +9227,12 @@ completion-show-help
:version "22.1"
:group 'completion)
+(defcustom completion-auto-select t
+ "Non-nil means to automatically select the completions buffer."
+ :type 'boolean
+ :version "29.1"
+ :group 'completion)
+
;; This function goes in completion-setup-hook, so that it is called
;; after the text of the completion list buffer is written.
(defun completion-setup-function ()
@@ -9263,7 +9269,9 @@ completion-setup-function
(insert "Click on a completion to select it.\n"))
(insert (substitute-command-keys
"In this buffer, type \\[choose-completion] to \
-select the completion near point.\n\n"))))))
+select the completion near point.\n\n")))))
+ (when completion-auto-select
+ (switch-to-completions)))
(add-hook 'completion-setup-hook #'completion-setup-function)
--
2.34.0
[-- Attachment #5: Type: text/plain, Size: 438 bytes --]
When exiting the *Completions* buffer, C-g and q seem not to send the
user back to minibuffer. This introduces friction via uncertainty,
because you don't know where the active point will land, so you have to
manually switch back. This command adds and binds command that ensure
the minibuffer is always selected once it is closed or unfocused. I
think this is an absolute improvement, so there is no option to reset
this behaviour.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #6: 0003-Switch-back-to-minibuffer-when-quitting-completion-b.patch --]
[-- Type: text/x-patch, Size: 1822 bytes --]
From 8f2433d70eadef47772b01b71ff44f5010c0935b Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Thu, 9 Dec 2021 17:36:14 +0100
Subject: [PATCH 3/4] Switch back to minibuffer when quitting completion
buffer
* lisp/simple.el (completion-quit): Add new command
(completion-kill-buffer): Add new command
(completion-list-mode-map): Bind completion-quit and
rebind kill-current-buffer to completion-kill-buffer
---
lisp/simple.el | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/lisp/simple.el b/lisp/simple.el
index b5f5122153..5ca8142548 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -8957,6 +8957,18 @@ set-variable
\f
;; Define the major mode for lists of completions.
+(defun completion-quit ()
+ "Close the completion buffer and return to the minibuffer."
+ (interactive)
+ (quit-window)
+ (switch-to-minibuffer))
+
+(defun completion-kill-buffer ()
+ "Close the completion buffer and return to the minibuffer."
+ (interactive)
+ (kill-buffer "*Completions*")
+ (switch-to-minibuffer))
+
(defvar completion-list-mode-map
(let ((map (make-sparse-keymap)))
(set-keymap-parent map special-mode-map)
@@ -8970,10 +8982,12 @@ completion-list-mode-map
(define-key map [right] 'next-completion)
(define-key map [?\t] 'next-completion)
(define-key map [backtab] 'previous-completion)
- (define-key map "z" 'kill-current-buffer)
(define-key map "n" 'next-completion)
(define-key map "p" 'previous-completion)
(define-key map "\M-g\M-c" 'switch-to-minibuffer)
+ (define-key map "z" #'completion-kill-buffer)
+ (define-key map [remap keyboard-quit] #'completion-quit)
+ (define-key map [remap quit-window] #'switch-to-minibuffer)
map)
"Local map for completion list buffers.")
--
2.34.0
[-- Attachment #7: Type: text/plain, Size: 409 bytes --]
In the *Completions*, self-insert-command is not bound so that "q", "n",
"p", "z", ... can be used. This patch would add "s" (for
isearch-forward) and "S" (for isearch-forward-regexp) to the default
bunch. This is my most recent change, that I am least certain about.
If I played around with it for a bit longer, maybe this could also be
extended to an interactive narrowing along the lines of icomplete.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #8: 0004-Bind-modifier-less-isearch-commands-in-the-completio.patch --]
[-- Type: text/x-patch, Size: 958 bytes --]
From 4f311034fac33698534090c35fb7e662f1cef47a Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Thu, 9 Dec 2021 17:37:44 +0100
Subject: [PATCH 4/4] Bind modifier-less isearch commands in the completion
buffer
* lisp/simple.el (completion-list-mode-map): Bind isearch-forward and
isearch-forward-regexp
---
lisp/simple.el | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lisp/simple.el b/lisp/simple.el
index 5ca8142548..cb2d4cd7f4 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -8982,6 +8982,8 @@ completion-list-mode-map
(define-key map [right] 'next-completion)
(define-key map [?\t] 'next-completion)
(define-key map [backtab] 'previous-completion)
+ (define-key map "s" #'isearch-forward)
+ (define-key map "S" #'isearch-forward-regexp)
(define-key map "n" 'next-completion)
(define-key map "p" 'previous-completion)
(define-key map "\M-g\M-c" 'switch-to-minibuffer)
--
2.34.0
[-- Attachment #9: Type: text/plain, Size: 453 bytes --]
So, any opinions on these suggestions? I get the impression that many
people avoid the default completion system because of small
peculiarities such as the ones I describe above. Protesilaos Stavrou's
recent library MCT (https://gitlab.com/protesilaos/mct) demonstrates
that it doesn't take much to fix these issues, but I think that the
above already does a lot, with a lot less code (mostly because this is
not a package).
--
Philip Kaludercic
^ permalink raw reply related [relevance 34%]
* Re: sqlite3
@ 2021-12-09 17:36 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-12-09 17:36 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: emacs-devel
Lars Ingebrigtsen <larsi@gnus.org> writes:
> I think it'd be good to bring that into core, and then write a small
> wrapper library (well, a trivial ORM) for the rest of Emacs to use, so
> that we don't have to write SQL all over the place. That is:
>
> (setf (persistent-data :namespace "emoji" :key "favorites") emoji--favorites)
>
> I.e., what Emacs needs is a persistent key/value store, and this would
> give us that.
>
> In addition, if somebody really wants to write SQL stuff (it can be very
> handy for some things), having sqlite3 in there gives us that in
> addition for free.
What would the use-case for this be? And would this be part of the same
interface ("persistent-data"), or would they be separate? I think the
latter would be preferable, because then systems that might not have
SQLite installed -- for whatever reason, despite it's wide
availability -- could fall back on a Elisp implementation.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: [External] : Suggestions for improvements to the *Completions* buffer
@ 2021-12-09 18:05 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-12-09 18:05 UTC (permalink / raw)
To: Drew Adams; +Cc: emacs-devel@gnu.org
Drew Adams <drew.adams@oracle.com> writes:
>> Currently, next-completion (and previous-completion) stops at either the
>> end or the beginning of a buffer. This patch would allow for the
>> command to also wrap around, and if the end has been reached to jump
>> back to the beginning. In my experience, the improvement is most
>> noticeable when choosing between a small number choices, and pressing
>> tab twice is easier than shift-tab.
>
> Yet another feature introduced by Icicles, back in 2006.
To clarify, I am not claiming any of this is new, all I am doing it
preparing these changes as patches that could be applied to Emacs
itself.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Suggestions for improvements to the *Completions* buffer
@ 2021-12-09 20:07 99% ` Philip Kaludercic
0 siblings, 2 replies; 200+ results
From: Philip Kaludercic @ 2021-12-09 20:07 UTC (permalink / raw)
To: Juri Linkov; +Cc: emacs-devel
Juri Linkov <juri@linkov.net> writes:
>> I'd like to suggest a few modifications to the default behaviour of
>> the *Completions* buffer. These are mostly conservative extensions of
>> the current defaults.
>
> Thanks, all your patches is a nice improvement. I have a question only
> about the last patch.
>
>> When exiting the *Completions* buffer, C-g and q seem not to send the
>> user back to minibuffer.
>
> This was just a plain bug.
>
>> +(defun completion-quit ()
>> + "Close the completion buffer and return to the minibuffer."
>> + (interactive)
>> + (quit-window)
>> + (switch-to-minibuffer))
>> +
>> +(defun completion-kill-buffer ()
>> + "Close the completion buffer and return to the minibuffer."
>> + (interactive)
>> + (kill-buffer "*Completions*")
>> + (switch-to-minibuffer))
>> @@ -8970,10 +8982,12 @@ completion-list-mode-map
>> + (define-key map "z" #'completion-kill-buffer)
>> + (define-key map [remap keyboard-quit] #'completion-quit)
>> + (define-key map [remap quit-window] #'switch-to-minibuffer)
>
> So typing C-g in the *Completions* buffer will be the same as
> typing C-g in the minibuffer? This would provide more consistency.
No, currently not: C-g will close the completions buffer, "reverting" a
change so to say, and another C-g in the minibuffer will cancel the
completion.
>> In the *Completions*, self-insert-command is not bound so that "q", "n",
>> "p", "z", ... can be used. This patch would add "s" (for
>> isearch-forward) and "S" (for isearch-forward-regexp) to the default
>> bunch. This is my most recent change, that I am least certain about.
>> If I played around with it for a bit longer, maybe this could also be
>> extended to an interactive narrowing along the lines of icomplete.
>
> I guess it's too late to allow all self-inserting keys in the *Completions*
> buffer to be used either to add characters to the search string,
> or to narrow completions interactively as if they were typed in the minibuffer,
> because "q", "n", "p", "z" are already bound to other commands?
True, so immediate narrowing (at least with the default bindings)
couldn't be done, but that doesn't mean that narrowing couldn't be
enabled by binding an activation command to conventional keys like "s"
and "/".
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: NonGNU ELPA work
2021-08-27 15:42 14% ` Philip Kaludercic
2021-09-23 22:51 56% ` Philip Kaludercic
@ 2021-12-09 23:24 36% ` Philip Kaludercic
2021-12-18 14:22 92% ` Philip Kaludercic
2 siblings, 2 replies; 200+ results
From: Philip Kaludercic @ 2021-12-09 23:24 UTC (permalink / raw)
To: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1549 bytes --]
Hi,
I'm attaching a few packages I have collected that should now work with
NonGNU ELPA. These include a bunch of language major modes:
- kotlin-mode (https://kotlinlang.org/), per
https://github.com/Emacs-Kotlin-Mode-Maintainers/kotlin-mode/issues/62
- jade-mode (https://jade-lang.com/)
- stylus-mode (https://stylus-lang.com/)
- textile-mode (https://textile-lang.com/)
- graphql-mode (https://graphql.org/)
- raku-mode (https://raku.org/), as per
https://github.com/Raku/raku-mode/pull/53
- elixir-mode (https://elixir-lang.org/), as per
https://github.com/elixir-editors/emacs-elixir/pull/482
I don't think we have progressed on the issue of major modes developed
in mono-repos related to the programming languages they are made for.
Last I heard of the wish was to not mirror unrelated code in nongnu.git.
Currently these packages are effected by this issue:
- erlang-mode
https://github.com/erlang/otp/tree/master/lib/tools/emacs
- cython-mode
https://github.com/cython/cython/blob/master/Tools/cython-mode.el
- cmake-mode
https://gitlab.kitware.com/cmake/cmake/-/blob/master/Auxiliary/cmake-mode.el
- protobuf-mode
https://github.com/protocolbuffers/protobuf/blob/master/editors/protobuf-mode.el
Furthermore these packages can also be added directly: Elpher
(https://thelambdalab.xyz/elpher/) a Gopher/Gemini client, as well as
Helm (https://github.com/emacs-helm/helm) the completion framework.
The respective patches are attached below in case anyone wants to see
the package specifications.
--
Philip Kaludercic
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-elpa-packages-kotlin-mode-Add-package.patch --]
[-- Type: text/x-diff, Size: 792 bytes --]
From 6a378b76267c74080acf5c181139bb4700ffc77d Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Wed, 8 Sep 2021 21:51:09 +0200
Subject: [PATCH 01/10] * elpa-packages (kotlin-mode): Add package
---
elpa-packages | 3 +++
1 file changed, 3 insertions(+)
diff --git a/elpa-packages b/elpa-packages
index 0444cf90c4..4955a9ed1a 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -154,6 +154,9 @@
("lua-mode" :url "https://github.com/immerrr/lua-mode/"
:ignored-files ("test" "travis" "init-tryout.el"))
+ ("kotlin-mode" :url "https://github.com/Emacs-Kotlin-Mode-Maintainers/kotlin-mode"
+ :ignored-files ("doc" "test" "Cask" "Makefile"))
+
("magit" :url "https://github.com/magit/magit"
:lisp-dir "lisp"
:doc "Documentation/magit.texi"
--
2.30.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0002-elpa-packages-jade-mode-stylus-mode-Add-packages.patch --]
[-- Type: text/x-diff, Size: 1173 bytes --]
From cf7c26be1f0f7df4630131b1d0b88cde2aa48bc1 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Thu, 9 Sep 2021 12:10:47 +0200
Subject: [PATCH 02/10] * elpa-packages (jade-mode, stylus-mode): Add packages
---
elpa-packages | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/elpa-packages b/elpa-packages
index 4955a9ed1a..cd336e230b 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -145,6 +145,10 @@
:ignored-files ("test")
:news "CHANGELOG.md")
+ ("jade-mode" :url "https://github.com/brianc/jade-mode"
+ :ignored-files ("test" "Cask" "Makefile" "example.jade" "example.json"
+ "stylus-mode.el"))
+
("j-mode" :url "https://github.com/zellio/j-mode")
("julia-mode" :url "https://github.com/JuliaEditorSupport/julia-emacs"
@@ -280,6 +284,10 @@
:ignored-files ("child-theme-example" "colorlab" "dev-emacs.d"
"Cask" "Makefile"))
+ ("stylus-mode" :url "https://github.com/brianc/jade-mode"
+ :ignored-files ("test" "Cask" "Makefile" "example.jade" "example.json"
+ "jade-mode.el"))
+
("subatomic-theme" :url "https://github.com/cryon/subatomic-theme"
:ignored-files ("readme-files"))
--
2.30.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #4: 0003-elpa-packages-textile-mode-Add-package.patch --]
[-- Type: text/x-diff, Size: 727 bytes --]
From 9feefab8a93d6bc0a3fb16cd0c507f929a865cf6 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Sun, 12 Sep 2021 11:10:18 +0200
Subject: [PATCH 03/10] * elpa-packages (textile-mode): Add package
---
elpa-packages | 2 ++
1 file changed, 2 insertions(+)
diff --git a/elpa-packages b/elpa-packages
index cd336e230b..e95df077bf 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -294,6 +294,8 @@
("swift-mode" :url "https://github.com/swift-emacs/swift-mode"
:ignored-files ("scripts" "test" "Eldev" "Makefile"))
+ ("textile-mode" :url "https://github.com/juba/textile-mode")
+
("systemd" :url "https://github.com/holomorph/systemd-mode"
:ignored-files ("test" "Makefile"))
--
2.30.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #5: 0004-elpa-packages-graphql-mode-Add-package.patch --]
[-- Type: text/x-diff, Size: 714 bytes --]
From 60b3ca3e58bec94a399ad3400a93d6a8396ef7f1 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Sun, 12 Sep 2021 17:50:25 +0200
Subject: [PATCH 04/10] * elpa-packages (graphql-mode): Add package
---
elpa-packages | 3 +++
1 file changed, 3 insertions(+)
diff --git a/elpa-packages b/elpa-packages
index e95df077bf..f186070a2e 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -104,6 +104,9 @@
("goto-chg" :url "https://github.com/emacs-evil/goto-chg")
+ ("graphql-mode" :url "https://github.com/davazp/graphql-mode"
+ :ignored-files ("test"))
+
("guru-mode" :url "https://github.com/bbatsov/guru-mode")
("haml-mode" :url "https://github.com/nex3/haml-mode"
--
2.30.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #6: 0005-elpa-packages-raku-mode-Add-package.patch --]
[-- Type: text/x-diff, Size: 810 bytes --]
From 7c4514be6e5ad3a493880f1ae537ce4af3f5dc13 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Mon, 27 Sep 2021 17:32:33 +0200
Subject: [PATCH 05/10] * elpa-packages (raku-mode): Add package
---
elpa-packages | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/elpa-packages b/elpa-packages
index f186070a2e..be31b6d9b2 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -244,6 +244,10 @@
("prop-menu" :url "https://github.com/david-christiansen/prop-menu-el"
:ignored-files ("Makefile" "prop-menu-tests.el"))
+ ("raku-mode" :url "https://github.com/Raku/raku-mode"
+ :ignored-files ("test" "Cask" "Makefile" "npq-mode.el")
+ :news "CHANGELOG.md")
+
("request" :url "https://github.com/tkf/emacs-request"
:ignored-files ("tests" "doc" "COPYING"))
--
2.30.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #7: 0006-elpa-packages-elpher-Add-package.patch --]
[-- Type: text/x-diff, Size: 764 bytes --]
From 8673ce96ef4801ae88ab09b1d3a475ac8afca789 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Thu, 7 Oct 2021 16:44:22 +0200
Subject: [PATCH 06/10] * elpa-packages (elpher): Add package
---
elpa-packages | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/elpa-packages b/elpa-packages
index be31b6d9b2..6f0fecf2e4 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -60,6 +60,10 @@
:news "CHANGELOG.md"
:ignored-files ("bin" "ert-tests"))
+ ("elpher" :url "git://thelambdalab.xyz/elpher.git"
+ :doc "elpher.texi"
+ :ignored-files ("Makefile" "ISSUES.org" "RELEASE" "config.mk"))
+
("evil" :url "https://github.com/emacs-evil/evil"
:ignored-files ("lib" "scripts")
:doc "doc/build/texinfo/evil.texi")
--
2.30.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #8: 0007-elpa-packages-helm-helm-code-Add-packages.patch --]
[-- Type: text/x-diff, Size: 1807 bytes --]
From c5877e3c9fd5cdff9155fa7e144320eb8f3ea22c Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Tue, 19 Oct 2021 13:44:42 +0200
Subject: [PATCH 07/10] * elpa-packages (helm, helm-code): Add packages
---
elpa-packages | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/elpa-packages b/elpa-packages
index 6f0fecf2e4..fc4862ac6f 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -134,6 +134,23 @@
;; ;; https://github.com/haskell/haskell-mode/releases/tag/17.2
;; :version-map ((nil "17.2" "e72677668f5fc7cc148008e885a0f256e245dd43")))
+ ("helm" :url "https://github.com/emacs-helm/helm"
+ :ignored-files ("images" "Cask" "Makefile" "emacs-helm.sh" "helm-core-pkg.el" "helm.el"
+ "helm-lib.el" "helm-source.el" "helm-multi-match.el"))
+
+ ("helm-core" :url "https://github.com/emacs-helm/helm"
+ :ignored-files ("images" "Cask" "Makefile" "emacs-helm.sh" "helm-adaptive.el"
+ "helm-bookmark.el" "helm-buffers.el" "helm-color.el" "helm-comint.el"
+ "helm-command.el" "helm-config.el" "helm-dabbrev.el" "helm-easymenu.el"
+ "helm-elisp.el" "helm-elisp-package.el" "helm-epa.el" "helm-eshell.el"
+ "helm-eval.el" "helm-external.el" "helm-fd.el" "helm-files.el" "helm-find.el"
+ "helm-font.el" "helm-for-files.el" "helm-global-bindings.el" "helm-grep.el"
+ "helm-help.el" "helm-id-utils.el" "helm-imenu.el" "helm-info.el" "helm-locate.el"
+ "helm-man.el" "helm-misc.el" "helm-mode.el" "helm-net.el" "helm-occur.el"
+ "helm-pkg.el" "helm-regexp.el" "helm-ring.el" "helm-semantic.el" "helm-shell.el"
+ "helm-sys.el" "helm-tags.el" "helm-types.el" "helm-utils.el" "helm-x-files.el")
+ :main-file "helm.el")
+
("highlight-parentheses"
:url "https://git.sr.ht/~tsdh/highlight-parentheses.el"
:branch "main"
--
2.30.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #9: 0008-elpa-packages-elixir-mode-Add-package.patch --]
[-- Type: text/x-diff, Size: 775 bytes --]
From ecba41f8c243131b42f33cc61f31bd5a08fd6f95 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Sun, 14 Nov 2021 10:35:53 +0100
Subject: [PATCH 08/10] * elpa-packages (elixir-mode): Add package
---
elpa-packages | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/elpa-packages b/elpa-packages
index fc4862ac6f..1822140c69 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -60,6 +60,10 @@
:news "CHANGELOG.md"
:ignored-files ("bin" "ert-tests"))
+ ("elixir-mode" :url "https://github.com/elixir-editors/emacs-elixir"
+ :ignored-files ("tests" "Eldev")
+ :news "CHANGELOG.md")
+
("elpher" :url "git://thelambdalab.xyz/elpher.git"
:doc "elpher.texi"
:ignored-files ("Makefile" "ISSUES.org" "RELEASE" "config.mk"))
--
2.30.2
^ permalink raw reply related [relevance 36%]
* Re: sqlite3
@ 2021-12-10 14:46 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-12-10 14:46 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: emacs-devel
Lars Ingebrigtsen <larsi@gnus.org> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>>> I think it'd be good to bring that into core, and then write a small
>>> wrapper library (well, a trivial ORM) for the rest of Emacs to use, so
>>> that we don't have to write SQL all over the place. That is:
>>>
>>> (setf (persistent-data :namespace "emoji" :key "favorites") emoji--favorites)
>>>
>>> I.e., what Emacs needs is a persistent key/value store, and this would
>>> give us that.
>>>
>>> In addition, if somebody really wants to write SQL stuff (it can be very
>>> handy for some things), having sqlite3 in there gives us that in
>>> addition for free.
>>
>> What would the use-case for this be? And would this be part of the
>> same interface ("persistent-data"), or would they be separate? I
>> think the latter would be preferable, because then systems that might
>> not have SQLite installed -- for whatever reason, despite it's wide
>> availability -- could fall back on a Elisp implementation.
>
> I'm not quite sure what you're asking here? The use case for having
> persistent data or for writing SQL?
>
> Nobody that uses the persistent data interface would have to write SQL.
Yes, but do you want the persistent data interface to be bound to
SQLite, or should a separate backed be implemented, if required?
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: NonGNU ELPA work
@ 2021-12-10 14:47 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-12-10 14:47 UTC (permalink / raw)
To: Stefan Kangas; +Cc: emacs-devel
Stefan Kangas <stefankangas@gmail.com> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> I'm attaching a few packages I have collected that should now work with
>> NonGNU ELPA. These include a bunch of language major modes:
>
> Thanks, this is important work.
>
> Are there any additional steps you currently take besides just adding
> these packages (such as communicating with the package authors)?
I haven't added anything yet, and have only contacted the authors that
have had issues with packaging.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: New package: resist!
@ 2021-12-10 19:24 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-12-10 19:24 UTC (permalink / raw)
To: Qiantan Hong
Cc: Karl Fogel, Tassilo Horn, Stefan Monnier, emacs-devel@gnu.org
Qiantan Hong <qhong@mit.edu> writes:
> I’m thinking the “package” as an extension to Elisp language itself,
> so I didn’t have package prefix in mind. Thus the name like `compact-kv-store`.
>
> Maybe the file should be named `persistence.el`?
I like this name better!
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: New package: resist!
@ 2021-12-10 20:34 98% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-12-10 20:34 UTC (permalink / raw)
To: Qiantan Hong
Cc: emacs-devel@gnu.org, kfogel@red-bean.com,
monnier@iro.umontreal.ca, Alexandre Garreau, tsdh@gnu.org,
Eli Zaretskii
Qiantan Hong <qhong@mit.edu> writes:
>> persist: it’s shorter, so shorter identifiers
>>
>> maybe even prsist
> Sounds good. I’ll do prsist then.
(I know this is bike-shedding, but...) What is the point of leaving out
a single vowel? Doesn't using a "real" or at least pronounceable word
avoid typos and make it easier to remember?
> Best,
> Qiantan
>
--
Philip Kaludercic
^ permalink raw reply [relevance 98%]
* Re: sqlite3
@ 2021-12-11 20:03 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-12-11 20:03 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: emacs-devel
Lars Ingebrigtsen <larsi@gnus.org> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Yes, but do you want the persistent data interface to be bound to
>> SQLite, or should a separate backed be implemented, if required?
>
> I don't think a separate backend is necessary, but I won't stand in the
> way of somebody implementing it. (I'm sure somebody has also
> implemented a GIF decoder in Emacs Lisp because they're against using C
> or something.)
I raise this question from the perspective of the forwards-compatibility
library (compat.el, https://sr.ht/~pkal/compat/). If there were no
distinction between persistent values and SQLite, then it would become
considerably more difficult to provide compatibility definitions if is
expected that the persistent value library can be mixed together with
raw SQL queries at any time.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: sqlite3
@ 2021-12-12 12:19 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-12-12 12:19 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: emacs-devel
Lars Ingebrigtsen <larsi@gnus.org> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> I raise this question from the perspective of the forwards-compatibility
>> library (compat.el, https://sr.ht/~pkal/compat/). If there were no
>> distinction between persistent values and SQLite, then it would become
>> considerably more difficult to provide compatibility definitions if is
>> expected that the persistent value library can be mixed together with
>> raw SQL queries at any time.
>
> I'm not sure I understand the question. There's no SQL in the
> multisession interface. It looks like this:
>
> (multisession-value foo)
>
> and
>
> (setf (multisession-value foo) 'bar)
I get that, is it defined or undefined behaviour if I mix in a few SQL
queries around various
(multisession-value foo)
calls?
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Suggestions for improvements to the *Completions* buffer
@ 2021-12-13 19:13 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-12-13 19:13 UTC (permalink / raw)
To: Stefan Kangas; +Cc: emacs-devel, Juri Linkov
Stefan Kangas <stefankangas@gmail.com> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>>> I guess it's too late to allow all self-inserting keys in the *Completions*
>>> buffer to be used either to add characters to the search string,
>>> or to narrow completions interactively as if they were typed in the minibuffer,
>>> because "q", "n", "p", "z" are already bound to other commands?
>
> I'm not sure how useful "q" and "z" are. I'd suggest just binding "C-g"
> to quit-window instead.
"q" via (quit-window) and "z" are already mapped, so I don't think it
makes sense to remove them. My intention is just to provide a superset
of the current behaviour.
> I guess "n" and "p" has some use, but maybe that behavior could be
> optional. IIRC, they were introduced in Emacs 28, so we could just
> revert that binding before the second pretest.
True, but "q" and "z" go back further, so enabling something like
narrowing would have to be disabled by default anyway.
>> True, so immediate narrowing (at least with the default bindings)
>> couldn't be done, but that doesn't mean that narrowing couldn't be
>> enabled by binding an activation command to conventional keys like "s"
>> and "/".
>
> Having an option would be a useful first step.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Suggestions for improvements to the *Completions* buffer
@ 2021-12-13 19:16 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-12-13 19:16 UTC (permalink / raw)
To: Juri Linkov; +Cc: emacs-devel
Juri Linkov <juri@linkov.net> writes:
>>>> +(defun completion-quit ()
>>>> + "Close the completion buffer and return to the minibuffer."
>>>> + (interactive)
>>>> + (quit-window)
>>>> + (switch-to-minibuffer))
>>>> +
>>>> +(defun completion-kill-buffer ()
>>>> + "Close the completion buffer and return to the minibuffer."
>>>> + (interactive)
>>>> + (kill-buffer "*Completions*")
>>>> + (switch-to-minibuffer))
>>>> @@ -8970,10 +8982,12 @@ completion-list-mode-map
>>>> + (define-key map "z" #'completion-kill-buffer)
>>>> + (define-key map [remap keyboard-quit] #'completion-quit)
>>>> + (define-key map [remap quit-window] #'switch-to-minibuffer)
>>>
>>> So typing C-g in the *Completions* buffer will be the same as
>>> typing C-g in the minibuffer? This would provide more consistency.
>>
>> No, currently not: C-g will close the completions buffer, "reverting" a
>> change so to say, and another C-g in the minibuffer will cancel the
>> completion.
>
> I misread the patch. Then double C-g C-g will be like in Isearch where
> the first C-g cancels wrong characters, and another C-g cancels the search.
Yes, didn't think of that but good to be reminded that there is already
a precedent for this kind of behaviour.
>>>> In the *Completions*, self-insert-command is not bound so that "q", "n",
>>>> "p", "z", ... can be used. This patch would add "s" (for
>>>> isearch-forward) and "S" (for isearch-forward-regexp) to the default
>>>> bunch. This is my most recent change, that I am least certain about.
>>>> If I played around with it for a bit longer, maybe this could also be
>>>> extended to an interactive narrowing along the lines of icomplete.
>>>
>>> I guess it's too late to allow all self-inserting keys in the *Completions*
>>> buffer to be used either to add characters to the search string,
>>> or to narrow completions interactively as if they were typed in the minibuffer,
>>> because "q", "n", "p", "z" are already bound to other commands?
>>
>> True, so immediate narrowing (at least with the default bindings)
>> couldn't be done, but that doesn't mean that narrowing couldn't be
>> enabled by binding an activation command to conventional keys like "s"
>> and "/".
>
> Wouldn't it be easier just to switch to the minibuffer (with e.g. 'q')
> and continue narrowing by typing more characters in the minibuffer?
That is what it would basically boil down to. The question is just
should "q" quit close the completion window or now.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Suggestions for improvements to the *Completions* buffer
2021-12-09 17:22 34% Suggestions for improvements to the *Completions* buffer Philip Kaludercic
@ 2021-12-13 21:36 96% ` Philip Kaludercic
2 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-12-13 21:36 UTC (permalink / raw)
To: emacs-devel
Philip Kaludercic <philipk@posteo.net> writes:
> From 8f2433d70eadef47772b01b71ff44f5010c0935b Mon Sep 17 00:00:00 2001
> From: Philip Kaludercic <philipk@posteo.net>
> Date: Thu, 9 Dec 2021 17:36:14 +0100
> Subject: [PATCH 3/4] Switch back to minibuffer when quitting completion
> buffer
>
> * lisp/simple.el (completion-quit): Add new command
> (completion-kill-buffer): Add new command
> (completion-list-mode-map): Bind completion-quit and
> rebind kill-current-buffer to completion-kill-buffer
> ---
> lisp/simple.el | 16 +++++++++++++++-
> 1 file changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/lisp/simple.el b/lisp/simple.el
> index b5f5122153..5ca8142548 100644
> --- a/lisp/simple.el
> +++ b/lisp/simple.el
> @@ -8957,6 +8957,18 @@ set-variable
> \f
> ;; Define the major mode for lists of completions.
>
> +(defun completion-quit ()
> + "Close the completion buffer and return to the minibuffer."
> + (interactive)
> + (quit-window)
> + (switch-to-minibuffer))
> +
> +(defun completion-kill-buffer ()
> + "Close the completion buffer and return to the minibuffer."
> + (interactive)
> + (kill-buffer "*Completions*")
> + (switch-to-minibuffer))
> +
> (defvar completion-list-mode-map
> (let ((map (make-sparse-keymap)))
> (set-keymap-parent map special-mode-map)
> @@ -8970,10 +8982,12 @@ completion-list-mode-map
> (define-key map [right] 'next-completion)
> (define-key map [?\t] 'next-completion)
> (define-key map [backtab] 'previous-completion)
> - (define-key map "z" 'kill-current-buffer)
> (define-key map "n" 'next-completion)
> (define-key map "p" 'previous-completion)
> (define-key map "\M-g\M-c" 'switch-to-minibuffer)
> + (define-key map "z" #'completion-kill-buffer)
> + (define-key map [remap keyboard-quit] #'completion-quit)
> + (define-key map [remap quit-window] #'switch-to-minibuffer)
It seems that remapping quit-window to switch-to-minibuffer creates
issues when the completion buffer is not invoked by the minibuffer, but
e.g. by complete-symbol. Binding it to completion-quit (defined above)
instead, might actually be more natural, as "q"/quit-window is expected
to close a window.
The question is whether or not there is a need for a separate
switch-to-minibuffer binding (besides M-g M-c)? Is keeping the
completions buffer active while returning to the minibuffer a real need?
> map)
> "Local map for completion list buffers.")
--
Philip Kaludercic
^ permalink raw reply [relevance 96%]
* Re: Suggestions for improvements to the *Completions* buffer
@ 2021-12-17 11:27 62% ` Philip Kaludercic
2021-12-17 15:00 97% ` Philip Kaludercic
2021-12-18 12:22 35% ` Philip Kaludercic
0 siblings, 2 replies; 200+ results
From: Philip Kaludercic @ 2021-12-17 11:27 UTC (permalink / raw)
To: Juri Linkov; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1042 bytes --]
Juri Linkov <juri@linkov.net> writes:
>>> - (define-key map "z" 'kill-current-buffer)
>>> (define-key map "\M-g\M-c" 'switch-to-minibuffer)
>>> + (define-key map "z" #'completion-kill-buffer)
>>> + (define-key map [remap keyboard-quit] #'completion-quit)
>>> + (define-key map [remap quit-window] #'switch-to-minibuffer)
>>
>> It seems that remapping quit-window to switch-to-minibuffer creates
>> issues when the completion buffer is not invoked by the minibuffer, but
>> e.g. by complete-symbol. Binding it to completion-quit (defined above)
>> instead, might actually be more natural, as "q"/quit-window is expected
>> to close a window.
>
> Good point, so `q' should not be rebound from its standard command
> `quit-window'. Like you noticed, currently `quit-window' fails
> to select the minibuffer window, but this is a bug, so this regression
> was reported in bug#52491.
Ok, great!
> Then "z" could be bound to a variant of `quit-window'
> that calls it with the argument KILL non-nil.
So something like this?
[-- Attachment #2: Type: text/plain, Size: 2662 bytes --]
diff --git a/lisp/mail/smtpmail.el b/lisp/mail/smtpmail.el
index bd8aa611e9..95e7abdeae 100644
--- a/lisp/mail/smtpmail.el
+++ b/lisp/mail/smtpmail.el
@@ -78,6 +78,19 @@ smtpmail-smtp-server
"The name of the host running SMTP server."
:type '(choice (const nil) string))
+(defcustom smtpmail-smtp-server-alist '()
+ "Alist of SMTP servers for different addresses."
+ :type '(alist :key-type
+ (string :tag "Sender")
+ :value-type
+ (list (string :tag "SMTP Server")
+ (natnum :tag "Service")
+ (choice :tag "Stream type"
+ (const :tag "Possibly upgrade to STARTTLS" nil)
+ (const :tag "Always use STARTTLS" starttls)
+ (const :tag "Never use STARTTLS" plain)
+ (const :tag "Use TLS/SSL" ssl)))))
+
(defcustom smtpmail-smtp-service 25
"SMTP service port number.
The default value would be \"smtp\" or 25."
@@ -706,13 +719,9 @@ smtpmail-user-mail-address
(defun smtpmail-via-smtp (recipient smtpmail-text-buffer
&optional ask-for-password
send-attempts)
- (unless smtpmail-smtp-server
+ (unless (or smtpmail-smtp-server smtpmail-smtp-server-alist)
(smtpmail-query-smtp-server))
- (let ((process nil)
- (send-attempts (or send-attempts 1))
- (host (or smtpmail-smtp-server
- (error "`smtpmail-smtp-server' not defined")))
- (port smtpmail-smtp-service)
+ (let* ((process nil)
;; `smtpmail-mail-address' should be set to the appropriate
;; buffer-local value by the caller, but in case not:
(envelope-from
@@ -727,6 +736,14 @@ smtpmail-via-smtp
(and from
(cadr (mail-extract-address-components from))))
(smtpmail-user-mail-address))))
+ (send-attempts (or send-attempts 1))
+ (server (alist-get envelope-from smtpmail-smtp-server-alist
+ (list smtpmail-smtp-server)
+ nil #'string=))
+ (host (or (car server)
+ (error "No known SMTP Server for %S" envelope-from)))
+ (port (or (cadr server)
+ smtpmail-smtp-service))
process-buffer
result
auth-mechanisms
@@ -757,7 +774,7 @@ smtpmail-via-smtp
(setq result
(open-network-stream
"smtpmail" process-buffer host port
- :type smtpmail-stream-type
+ :type (or (caddr server) smtpmail-stream-type)
:return-list t
:warn-unless-encrypted ask-for-password
:capability-command (format "EHLO %s\r\n" (smtpmail-fqdn))
[-- Attachment #3: Type: text/plain, Size: 2049 bytes --]
> Like currently `ESC ESC ESC' can close the completion window
> by the special command `delete-completion-window', then the same
> command could be bound to `[remap keyboard-quit]' as well.
Sure, but what noticeable difference does this make? It seems to me
that quitting or killing the completion buffer doesn't amount to much of
a difference, as *Completion* is rarely selected manually.
The only case I can think of where the difference could matter, is when
*Completion* is so large that you need to kill it. But considering that
even with "C-h o TAB" the difference appears to be indistinguishable.
Quitting a window and requesting the came completion doesn't even reuse
the existing buffer.
>> The question is whether or not there is a need for a separate
>> switch-to-minibuffer binding (besides M-g M-c)? Is keeping the
>> completions buffer active while returning to the minibuffer a real need?
>
> Good question. If four key bindings (q, z, C-g, ESC ESC ESC)
> all will close the completions (first two using quit-window,
> and last two using delete-completion-window), then maybe we should have
> an easy-to-type keybinding that will switch to the minibuffer without
> closing the completions window?
>
> There is an easy-to-type keys <PgUp> and M-v to switch to the
> completions window, but no an easy-to-type key to switch back.
>
> It seems wrong for `q' to switch to the minibuffer without closing
> the window because `quit-window' implies that window should quit.
> But what key to use instead, I have no idea.
Seeing as <left> and <right> are bound to previous-completion and
next-completion, maybe <up> and <down> could be used for
completion/minibuffer switching?
Or to take inspiration from Protesilaos's MCT package, that switches
back to the minibuffer once next-completion and previous-completion
reaches the end/beginning of the buffer, without quitting the window.
With next-completion bound to TAB while TAB also jumps back to the
completion buffer, it would behave to just by cycling.
--
Philip Kaludercic
^ permalink raw reply related [relevance 62%]
* Re: Suggestions for improvements to the *Completions* buffer
2021-12-17 11:27 62% ` Philip Kaludercic
@ 2021-12-17 15:00 97% ` Philip Kaludercic
2021-12-18 12:22 35% ` Philip Kaludercic
1 sibling, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-12-17 15:00 UTC (permalink / raw)
To: Juri Linkov; +Cc: emacs-devel
Philip Kaludercic <philipk@posteo.net> writes:
>> Then "z" could be bound to a variant of `quit-window'
>> that calls it with the argument KILL non-nil.
>
> So something like this?
I inserted the wrong patch, here. It was supposed to be
--8<---------------cut here---------------start------------->8---
diff --git a/lisp/simple.el b/lisp/simple.el
index a55df604c1..1521c325dc 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -8967,7 +8967,8 @@ completion-quit
(defun completion-kill-buffer ()
"Close the completion buffer and return to the minibuffer."
(interactive)
- (kill-buffer "*Completions*")
+ (let ((win (get-buffer-window "*Completions*")))
+ (when win (quit-window t win)))
(switch-to-minibuffer))
(defvar completion-list-mode-map
--8<---------------cut here---------------end--------------->8---
--
Philip Kaludercic
^ permalink raw reply related [relevance 97%]
* Re: Suggestions for improvements to the *Completions* buffer
2021-12-17 11:27 62% ` Philip Kaludercic
2021-12-17 15:00 97% ` Philip Kaludercic
@ 2021-12-18 12:22 35% ` Philip Kaludercic
1 sibling, 2 replies; 200+ results
From: Philip Kaludercic @ 2021-12-18 12:22 UTC (permalink / raw)
To: Juri Linkov; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1615 bytes --]
Philip Kaludercic <philipk@posteo.net> writes:
>>> The question is whether or not there is a need for a separate
>>> switch-to-minibuffer binding (besides M-g M-c)? Is keeping the
>>> completions buffer active while returning to the minibuffer a real need?
>>
>> Good question. If four key bindings (q, z, C-g, ESC ESC ESC)
>> all will close the completions (first two using quit-window,
>> and last two using delete-completion-window), then maybe we should have
>> an easy-to-type keybinding that will switch to the minibuffer without
>> closing the completions window?
>>
>> There is an easy-to-type keys <PgUp> and M-v to switch to the
>> completions window, but no an easy-to-type key to switch back.
>>
>> It seems wrong for `q' to switch to the minibuffer without closing
>> the window because `quit-window' implies that window should quit.
>> But what key to use instead, I have no idea.
>
> Or to take inspiration from Protesilaos's MCT package, that switches
> back to the minibuffer once next-completion and previous-completion
> reaches the end/beginning of the buffer, without quitting the window.
> With next-completion bound to TAB while TAB also jumps back to the
> completion buffer, it would behave to just by cycling.
Here are the patches that would implement this behaviour. I have to use
it for a bit longer before I can say if it is preferable, but I guess if
something along these lines were to be applied, this could be an option.
The mechanism used to make backtab in the minibuffer switch to the last
completion option is not that nice as it uses this-command and
this-command-keys.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Allow-for-the-completion-buffer-to-be-automatically-.patch --]
[-- Type: text/x-diff, Size: 1412 bytes --]
From 0cc155ee3395fab376b06838a79c9a8b6fee6378 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Thu, 9 Dec 2021 17:34:54 +0100
Subject: [PATCH 1/3] Allow for the completion buffer to be automatically
selected
* lisp/simple.el (completion-auto-select): Add new option.
(completion-setup-function): Respect completion-auto-select.
---
lisp/simple.el | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/lisp/simple.el b/lisp/simple.el
index 84928caa31..213720784c 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -9226,6 +9226,12 @@ completion-show-help
:version "22.1"
:group 'completion)
+(defcustom completion-auto-select t
+ "Non-nil means to automatically select the completions buffer."
+ :type 'boolean
+ :version "29.1"
+ :group 'completion)
+
;; This function goes in completion-setup-hook, so that it is called
;; after the text of the completion list buffer is written.
(defun completion-setup-function ()
@@ -9262,7 +9268,9 @@ completion-setup-function
(insert "Click on a completion to select it.\n"))
(insert (substitute-command-keys
"In this buffer, type \\[choose-completion] to \
-select the completion near point.\n\n"))))))
+select the completion near point.\n\n")))))
+ (when completion-auto-select
+ (switch-to-completions)))
(add-hook 'completion-setup-hook #'completion-setup-function)
--
2.30.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0002-Allow-for-next-completion-to-wrap-around-the-complet.patch --]
[-- Type: text/x-diff, Size: 5889 bytes --]
From 1b53b0c60c830c5e9173f143e4ed7e4719288ec9 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Thu, 9 Dec 2021 17:26:14 +0100
Subject: [PATCH 2/3] Allow for next-completion to wrap around the completion
buffer
* lisp/simple.el (completion-wrap-movement): Add new option.
(previous-completion): Update docstring.
(next-completion): Respect completion-wrap-movement.
(switch-to-completions): Handle backwards completion by jumping to the
end of the buffer.
* lisp/minibuffer.el: (minibuffer-local-completion-map): Bind
minibuffer-complete to backtab
---
lisp/minibuffer.el | 1 +
lisp/simple.el | 81 ++++++++++++++++++++++++++++++----------------
2 files changed, 54 insertions(+), 28 deletions(-)
diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 28bd1df59a..5f831665eb 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -2651,6 +2651,7 @@ minibuffer-local-completion-map
(let ((map (make-sparse-keymap)))
(set-keymap-parent map minibuffer-local-map)
(define-key map "\t" 'minibuffer-complete)
+ (define-key map [backtab] 'minibuffer-complete)
;; M-TAB is already abused for many other purposes, so we should find
;; another binding for it.
;; (define-key map "\e\t" 'minibuffer-force-complete)
diff --git a/lisp/simple.el b/lisp/simple.el
index 213720784c..6a7d7ba918 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -9027,38 +9027,57 @@ delete-completion-window
(if (get-buffer-window buf)
(select-window (get-buffer-window buf))))))
+(defcustom completion-wrap-movement t
+ "Non-nil means to wrap around when selecting completion options.
+This affects the commands `next-completion' and
+`previous-completion'."
+ :type 'boolean
+ :version "29.1"
+ :group 'completion)
+
(defun previous-completion (n)
- "Move to the previous item in the completion list."
+ "Move to the previous item in the completion list.
+With prefix argument N, move back N items (negative N means move
+forward)."
(interactive "p")
(next-completion (- n)))
(defun next-completion (n)
"Move to the next item in the completion list.
-With prefix argument N, move N items (negative N means move backward)."
+With prefix argument N, move N items (negative N means move
+backward)."
(interactive "p")
(let ((beg (point-min)) (end (point-max)))
- (while (and (> n 0) (not (eobp)))
- ;; If in a completion, move to the end of it.
- (when (get-text-property (point) 'mouse-face)
- (goto-char (next-single-property-change (point) 'mouse-face nil end)))
- ;; Move to start of next one.
- (unless (get-text-property (point) 'mouse-face)
- (goto-char (next-single-property-change (point) 'mouse-face nil end)))
- (setq n (1- n)))
- (while (and (< n 0) (not (bobp)))
- (let ((prop (get-text-property (1- (point)) 'mouse-face)))
- ;; If in a completion, move to the start of it.
- (when (and prop (eq prop (get-text-property (point) 'mouse-face)))
- (goto-char (previous-single-property-change
- (point) 'mouse-face nil beg)))
- ;; Move to end of the previous completion.
- (unless (or (bobp) (get-text-property (1- (point)) 'mouse-face))
- (goto-char (previous-single-property-change
- (point) 'mouse-face nil beg)))
- ;; Move to the start of that one.
- (goto-char (previous-single-property-change
- (point) 'mouse-face nil beg))
- (setq n (1+ n))))))
+ (catch 'bound
+ (while (> n 0)
+ ;; If in a completion, move to the end of it.
+ (when (get-text-property (point) 'mouse-face)
+ (goto-char (next-single-property-change (point) 'mouse-face nil end)))
+ (when (and completion-wrap-movement (eobp))
+ (throw 'bound nil))
+ ;; Move to start of next one.
+ (unless (get-text-property (point) 'mouse-face)
+ (goto-char (next-single-property-change (point) 'mouse-face nil end)))
+ (setq n (1- n)))
+ (while (< n 0)
+ (let ((prop (get-text-property (1- (point)) 'mouse-face)))
+ ;; If in a completion, move to the start of it.
+ (when (and prop (eq prop (get-text-property (point) 'mouse-face)))
+ (goto-char (previous-single-property-change
+ (point) 'mouse-face nil beg)))
+ ;; Move to end of the previous completion.
+ (unless (or (bobp) (get-text-property (1- (point)) 'mouse-face))
+ (goto-char (previous-single-property-change
+ (point) 'mouse-face nil beg)))
+ (when (and completion-wrap-movement (bobp))
+ (goto-char (next-single-property-change (point) 'mouse-face nil end))
+ (throw 'bound nil))
+ ;; Move to the start of that one.
+ (goto-char (previous-single-property-change
+ (point) 'mouse-face nil beg))
+ (setq n (1+ n)))))
+ (when (/= 0 n)
+ (switch-to-minibuffer))))
(defun choose-completion (&optional event)
"Choose the completion at point.
@@ -9283,10 +9302,16 @@ switch-to-completions
(get-buffer-window "*Completions*" 0)))))
(when window
(select-window window)
- ;; In the new buffer, go to the first completion.
- ;; FIXME: Perhaps this should be done in `minibuffer-completion-help'.
- (when (bobp)
- (next-completion 1)))))
+ (cond
+ ((and (memq this-command '(completion-at-point minibuffer-complete))
+ (equal (this-command-keys) [backtab])
+ (bobp))
+ (goto-char (point-max))
+ (previous-completion 1))
+ ;; In the new buffer, go to the first completion.
+ ;; FIXME: Perhaps this should be done in `minibuffer-completion-help'.
+ ((bobp)
+ (next-completion 1))))))
(defun read-expression-switch-to-completions ()
"Select the completion list window while reading an expression."
--
2.30.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #4: 0003-Switch-back-to-minibuffer-when-quitting-completion-b.patch --]
[-- Type: text/x-diff, Size: 1881 bytes --]
From 1612aa4f9a5c1d4afa9e0d97b959c9623c400ce2 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Thu, 9 Dec 2021 17:36:14 +0100
Subject: [PATCH 3/3] Switch back to minibuffer when quitting completion buffer
* lisp/simple.el (completion-quit): Add new command
(completion-kill-buffer): Add new command
(completion-list-mode-map): Bind completion-quit and
rebind kill-current-buffer to completion-kill-buffer
---
lisp/simple.el | 17 ++++++++++++++++-
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/lisp/simple.el b/lisp/simple.el
index 6a7d7ba918..c9ddca7b0a 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -8971,6 +8971,19 @@ set-variable
\f
;; Define the major mode for lists of completions.
+(defun completion-quit ()
+ "Close the completion buffer and return to the minibuffer."
+ (interactive)
+ (quit-window)
+ (switch-to-minibuffer))
+
+(defun completion-kill-buffer ()
+ "Close the completion buffer and return to the minibuffer."
+ (interactive)
+ (let ((win (get-buffer-window "*Completions*")))
+ (when win (quit-window t win)))
+ (switch-to-minibuffer))
+
(defvar completion-list-mode-map
(let ((map (make-sparse-keymap)))
(set-keymap-parent map special-mode-map)
@@ -8984,10 +8997,12 @@ completion-list-mode-map
(define-key map [right] 'next-completion)
(define-key map [?\t] 'next-completion)
(define-key map [backtab] 'previous-completion)
- (define-key map "z" 'kill-current-buffer)
(define-key map "n" 'next-completion)
(define-key map "p" 'previous-completion)
(define-key map "\M-g\M-c" 'switch-to-minibuffer)
+ (define-key map "z" #'completion-kill-buffer)
+ (define-key map [remap keyboard-quit] #'delete-completion-window)
+ (define-key map [remap quit-window] #'completion-quit)
map)
"Local map for completion list buffers.")
--
2.30.2
[-- Attachment #5: Type: text/plain, Size: 24 bytes --]
--
Philip Kaludercic
^ permalink raw reply related [relevance 35%]
* Re: Suggestions for improvements to the *Completions* buffer
@ 2021-12-18 13:39 81% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-12-18 13:39 UTC (permalink / raw)
To: Po Lu; +Cc: emacs-devel, Juri Linkov
[-- Attachment #1: Type: text/plain, Size: 652 bytes --]
Po Lu <luangruo@yahoo.com> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Here are the patches that would implement this behaviour. I have to use
>> it for a bit longer before I can say if it is preferable, but I guess if
>> something along these lines were to be applied, this could be an option.
>
> Could this part be made optional, at least for those of us with muscle
> memory? I actually expect the focus to return to the previous window
> (not necessarily the minibuffer) when I press `z' in a completion
> buffer.
Sure, that was a mistake on end. I don't even think it needs an option,
so I just removed the code entirely:
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0003-Switch-back-to-minibuffer-when-quitting-completion-b.patch --]
[-- Type: text/x-diff, Size: 1349 bytes --]
From b1f2aa11bdad6f07baef54ac6db15ee714d3941e Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Thu, 9 Dec 2021 17:36:14 +0100
Subject: [PATCH 3/3] Switch back to minibuffer when quitting completion buffer
* lisp/simple.el (completion-quit): Add new command
(completion-list-mode-map): Rebind completion-quit over keyboard-quit
and delete-completion-window over keyboard-quit.
---
lisp/simple.el | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/lisp/simple.el b/lisp/simple.el
index 6a7d7ba918..74deb4bdc4 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -8971,6 +8971,12 @@ set-variable
\f
;; Define the major mode for lists of completions.
+(defun completion-quit ()
+ "Close the completion buffer and return to the minibuffer."
+ (interactive)
+ (quit-window)
+ (switch-to-minibuffer))
+
(defvar completion-list-mode-map
(let ((map (make-sparse-keymap)))
(set-keymap-parent map special-mode-map)
@@ -8988,6 +8994,8 @@ completion-list-mode-map
(define-key map "n" 'next-completion)
(define-key map "p" 'previous-completion)
(define-key map "\M-g\M-c" 'switch-to-minibuffer)
+ (define-key map [remap keyboard-quit] #'delete-completion-window)
+ (define-key map [remap quit-window] #'completion-quit)
map)
"Local map for completion list buffers.")
--
2.30.2
[-- Attachment #3: Type: text/plain, Size: 35 bytes --]
> Thanks.
--
Philip Kaludercic
^ permalink raw reply related [relevance 81%]
* Re: NonGNU ELPA work
2021-12-09 23:24 36% ` Philip Kaludercic
@ 2021-12-18 14:22 92% ` Philip Kaludercic
1 sibling, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-12-18 14:22 UTC (permalink / raw)
To: emacs-devel
Philip Kaludercic <philipk@posteo.net> writes:
> Hi,
>
> I'm attaching a few packages I have collected that should now work with
> NonGNU ELPA. These include a bunch of language major modes:
>
> - kotlin-mode (https://kotlinlang.org/), per
> https://github.com/Emacs-Kotlin-Mode-Maintainers/kotlin-mode/issues/62
> - jade-mode (https://jade-lang.com/)
> - stylus-mode (https://stylus-lang.com/)
> - textile-mode (https://textile-lang.com/)
> - graphql-mode (https://graphql.org/)
> - raku-mode (https://raku.org/), as per
> https://github.com/Raku/raku-mode/pull/53
> - elixir-mode (https://elixir-lang.org/), as per
> https://github.com/elixir-editors/emacs-elixir/pull/482
I forgot to mention the following packages:
- dockerfile-mode (https://github.com/spotify/dockerfile-mode), as per
https://github.com/spotify/dockerfile-mode/issues/67
- nix-mode (https://github.com/NixOS/nix-mode), as per
https://github.com/spotify/dockerfile-mode/issues/67
- gnu-apl-mode (https://github.com/lokedhs/gnu-apl-mode), as per
https://github.com/lokedhs/gnu-apl-mode/pull/42 and
https://github.com/lokedhs/gnu-apl-mode/pull/43 (not yet merged)
- free-keys (https://github.com/Fuco1/free-keys), as per
https://github.com/Fuco1/free-keys/pull/6
- forth-mode (https://github.com/larsbrinkhoff/forth-mode), as per
https://github.com/larsbrinkhoff/forth-mode/issues/82
I would add these packages in the next few days, unless anyone objects.
> I don't think we have progressed on the issue of major modes developed
> in mono-repos related to the programming languages they are made for.
> Last I heard of the wish was to not mirror unrelated code in nongnu.git.
> Currently these packages are effected by this issue:
>
> - erlang-mode
> https://github.com/erlang/otp/tree/master/lib/tools/emacs
> - cython-mode
> https://github.com/cython/cython/blob/master/Tools/cython-mode.el
> - cmake-mode
> https://gitlab.kitware.com/cmake/cmake/-/blob/master/Auxiliary/cmake-mode.el
> - protobuf-mode
> https://github.com/protocolbuffers/protobuf/blob/master/editors/protobuf-mode.el
Ping?
> Furthermore these packages can also be added directly: Elpher
> (https://thelambdalab.xyz/elpher/) a Gopher/Gemini client, as well as
> Helm (https://github.com/emacs-helm/helm) the completion framework.
>
> The respective patches are attached below in case anyone wants to see
> the package specifications.
--
Philip Kaludercic
^ permalink raw reply [relevance 92%]
* Re: Merging the pgtk branch
@ 2021-12-18 15:37 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-12-18 15:37 UTC (permalink / raw)
To: Bozhidar Batsov; +Cc: Emacs Devel
"Bozhidar Batsov" <bozhidar@batsov.dev> writes:
> Fair enough, let me try to clarify my question. I had just assumed
> that all Unix systems (except macOS) default to the old GTK front-end
So what you mean to ask is "will Emacs use PGTK by default when it is
build using GTK"?
> (when it comes to Emacs with GUI, that is) and I was wondering if the
> expectation was that pgtk would mostly replace it right away
> (e.g. because of it's improved compatibility with Wayland) once Emacs
> 28 is released.
Note that this was merged on to the master branch, not the emacs-28
branch (that is being prepared for release).
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Suggestions for improvements to the *Completions* buffer
@ 2021-12-19 14:55 38% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-12-19 14:55 UTC (permalink / raw)
To: Juri Linkov; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 462 bytes --]
Juri Linkov <juri@linkov.net> writes:
>> The mechanism used to make backtab in the minibuffer switch to the last
>> completion option is not that nice as it uses this-command and
>> this-command-keys.
>
> When completion-auto-select is not enabled, TAB scrolls the completions buffer
> forward. So S-TAB (backtab) could scroll backward.
>
> When completion-auto-select will be enabled, backtab could switch to
> the completions as well, indeed.
How is this?
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Allow-for-the-completion-buffer-to-be-automatically-.patch --]
[-- Type: text/x-diff, Size: 1412 bytes --]
From 6315289b47083c32ca28d2c582eb80b5c80345e0 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Thu, 9 Dec 2021 17:34:54 +0100
Subject: [PATCH 1/3] Allow for the completion buffer to be automatically
selected
* lisp/simple.el (completion-auto-select): Add new option.
(completion-setup-function): Respect completion-auto-select.
---
lisp/simple.el | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/lisp/simple.el b/lisp/simple.el
index 26c3ff575e..d0e58575e1 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -9226,6 +9226,12 @@ completion-show-help
:version "22.1"
:group 'completion)
+(defcustom completion-auto-select t
+ "Non-nil means to automatically select the completions buffer."
+ :type 'boolean
+ :version "29.1"
+ :group 'completion)
+
;; This function goes in completion-setup-hook, so that it is called
;; after the text of the completion list buffer is written.
(defun completion-setup-function ()
@@ -9262,7 +9268,9 @@ completion-setup-function
(insert "Click on a completion to select it.\n"))
(insert (substitute-command-keys
"In this buffer, type \\[choose-completion] to \
-select the completion near point.\n\n"))))))
+select the completion near point.\n\n")))))
+ (when completion-auto-select
+ (switch-to-completions)))
(add-hook 'completion-setup-hook #'completion-setup-function)
--
2.30.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0002-Allow-for-next-completion-to-wrap-around-the-complet.patch --]
[-- Type: text/x-diff, Size: 6395 bytes --]
From 300b30423f1515d5d1b2fcc477185b79ac4bb832 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Thu, 9 Dec 2021 17:26:14 +0100
Subject: [PATCH 2/3] Allow for next-completion to wrap around the completion
buffer
* lisp/simple.el (completion-wrap-movement): Add new option.
(previous-completion): Update docstring.
(next-completion): Respect completion-wrap-movement.
(switch-to-completions): Handle backwards completion by jumping to the
end of the buffer.
* lisp/minibuffer.el: (minibuffer-local-completion-map): Bind
minibuffer-complete to backtab
(completion--in-region-1): Handle backtab to scroll backwards
---
lisp/minibuffer.el | 5 ++-
lisp/simple.el | 81 ++++++++++++++++++++++++++++++----------------
2 files changed, 57 insertions(+), 29 deletions(-)
diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 28bd1df59a..559e36e370 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -1386,7 +1386,9 @@ completion--in-region-1
(set-window-start window (point-min) nil)
;; Else scroll down one screen.
(with-selected-window window
- (scroll-up)))
+ (if (equal (this-command-keys) [backtab])
+ (scroll-down)
+ (scroll-up))))
nil)))
;; If we're cycling, keep on cycling.
((and completion-cycling completion-all-sorted-completions)
@@ -2651,6 +2653,7 @@ minibuffer-local-completion-map
(let ((map (make-sparse-keymap)))
(set-keymap-parent map minibuffer-local-map)
(define-key map "\t" 'minibuffer-complete)
+ (define-key map [backtab] 'minibuffer-complete)
;; M-TAB is already abused for many other purposes, so we should find
;; another binding for it.
;; (define-key map "\e\t" 'minibuffer-force-complete)
diff --git a/lisp/simple.el b/lisp/simple.el
index d0e58575e1..626c24e10d 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -9027,38 +9027,57 @@ delete-completion-window
(if (get-buffer-window buf)
(select-window (get-buffer-window buf))))))
+(defcustom completion-wrap-movement t
+ "Non-nil means to wrap around when selecting completion options.
+This affects the commands `next-completion' and
+`previous-completion'."
+ :type 'boolean
+ :version "29.1"
+ :group 'completion)
+
(defun previous-completion (n)
- "Move to the previous item in the completion list."
+ "Move to the previous item in the completion list.
+With prefix argument N, move back N items (negative N means move
+forward)."
(interactive "p")
(next-completion (- n)))
(defun next-completion (n)
"Move to the next item in the completion list.
-With prefix argument N, move N items (negative N means move backward)."
+With prefix argument N, move N items (negative N means move
+backward)."
(interactive "p")
(let ((beg (point-min)) (end (point-max)))
- (while (and (> n 0) (not (eobp)))
- ;; If in a completion, move to the end of it.
- (when (get-text-property (point) 'mouse-face)
- (goto-char (next-single-property-change (point) 'mouse-face nil end)))
- ;; Move to start of next one.
- (unless (get-text-property (point) 'mouse-face)
- (goto-char (next-single-property-change (point) 'mouse-face nil end)))
- (setq n (1- n)))
- (while (and (< n 0) (not (bobp)))
- (let ((prop (get-text-property (1- (point)) 'mouse-face)))
- ;; If in a completion, move to the start of it.
- (when (and prop (eq prop (get-text-property (point) 'mouse-face)))
- (goto-char (previous-single-property-change
- (point) 'mouse-face nil beg)))
- ;; Move to end of the previous completion.
- (unless (or (bobp) (get-text-property (1- (point)) 'mouse-face))
- (goto-char (previous-single-property-change
- (point) 'mouse-face nil beg)))
- ;; Move to the start of that one.
- (goto-char (previous-single-property-change
- (point) 'mouse-face nil beg))
- (setq n (1+ n))))))
+ (catch 'bound
+ (while (> n 0)
+ ;; If in a completion, move to the end of it.
+ (when (get-text-property (point) 'mouse-face)
+ (goto-char (next-single-property-change (point) 'mouse-face nil end)))
+ (when (and completion-wrap-movement (eobp))
+ (throw 'bound nil))
+ ;; Move to start of next one.
+ (unless (get-text-property (point) 'mouse-face)
+ (goto-char (next-single-property-change (point) 'mouse-face nil end)))
+ (setq n (1- n)))
+ (while (< n 0)
+ (let ((prop (get-text-property (1- (point)) 'mouse-face)))
+ ;; If in a completion, move to the start of it.
+ (when (and prop (eq prop (get-text-property (point) 'mouse-face)))
+ (goto-char (previous-single-property-change
+ (point) 'mouse-face nil beg)))
+ ;; Move to end of the previous completion.
+ (unless (or (bobp) (get-text-property (1- (point)) 'mouse-face))
+ (goto-char (previous-single-property-change
+ (point) 'mouse-face nil beg)))
+ (when (and completion-wrap-movement (bobp))
+ (goto-char (next-single-property-change (point) 'mouse-face nil end))
+ (throw 'bound nil))
+ ;; Move to the start of that one.
+ (goto-char (previous-single-property-change
+ (point) 'mouse-face nil beg))
+ (setq n (1+ n)))))
+ (when (/= 0 n)
+ (switch-to-minibuffer))))
(defun choose-completion (&optional event)
"Choose the completion at point.
@@ -9283,10 +9302,16 @@ switch-to-completions
(get-buffer-window "*Completions*" 0)))))
(when window
(select-window window)
- ;; In the new buffer, go to the first completion.
- ;; FIXME: Perhaps this should be done in `minibuffer-completion-help'.
- (when (bobp)
- (next-completion 1)))))
+ (cond
+ ((and (memq this-command '(completion-at-point minibuffer-complete))
+ (equal (this-command-keys) [backtab])
+ (bobp))
+ (goto-char (point-max))
+ (previous-completion 1))
+ ;; In the new buffer, go to the first completion.
+ ;; FIXME: Perhaps this should be done in `minibuffer-completion-help'.
+ ((bobp)
+ (next-completion 1))))))
(defun read-expression-switch-to-completions ()
"Select the completion list window while reading an expression."
--
2.30.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #4: 0003-Delete-completion-window-on-quitting.patch --]
[-- Type: text/x-diff, Size: 909 bytes --]
From 37af745b2f97ea7f9a719b4ba4c488bb8df0d79a Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Thu, 9 Dec 2021 17:36:14 +0100
Subject: [PATCH 3/3] Delete completion window on quitting
* lisp/simple.el (completion-list-mode-map): Rebind
delete-completion-window over keyboard-quit.
---
lisp/simple.el | 1 +
1 file changed, 1 insertion(+)
diff --git a/lisp/simple.el b/lisp/simple.el
index 626c24e10d..d30b52e286 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -8980,6 +8980,7 @@ completion-list-mode-map
(define-key map [down-mouse-2] nil)
(define-key map "\C-m" 'choose-completion)
(define-key map "\e\e\e" 'delete-completion-window)
+ (define-key map [remap keyboard-quit] #'delete-completion-window)
(define-key map [left] 'previous-completion)
(define-key map [right] 'next-completion)
(define-key map [?\t] 'next-completion)
--
2.30.2
[-- Attachment #5: Type: text/plain, Size: 24 bytes --]
--
Philip Kaludercic
^ permalink raw reply related [relevance 38%]
* Re: Suggestions for improvements to the *Completions* buffer
@ 2021-12-19 23:58 41% ` Philip Kaludercic
2021-12-20 9:03 41% ` Philip Kaludercic
0 siblings, 2 replies; 200+ results
From: Philip Kaludercic @ 2021-12-19 23:58 UTC (permalink / raw)
To: Juri Linkov; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 2409 bytes --]
Juri Linkov <juri@linkov.net> writes:
>>>> The mechanism used to make backtab in the minibuffer switch to the last
>>>> completion option is not that nice as it uses this-command and
>>>> this-command-keys.
>>>
>>> When completion-auto-select is not enabled, TAB scrolls the completions buffer
>>> forward. So S-TAB (backtab) could scroll backward.
>>>
>>> When completion-auto-select will be enabled, backtab could switch to
>>> the completions as well, indeed.
>>
>> How is this?
>
> Thanks, this has now such a nice property that after typing TAB
> that switches to the completions buffer, it's easy to switch back
> to the minibuffer by typing S-TAB. But this works only when
> completion-wrap-movement is non-nil.
True, even that was not the primary intention. I guess this also raises
the question of whether or not completion-wrap-movement and
completion-auto-select should be set to non-nil by default or not? If
applied, maybe they could be enabled for a month or so, to gather
experiences and then decide how to continue on that basis.
>> +(defcustom completion-wrap-movement t
>> + "Non-nil means to wrap around when selecting completion options.
>> +This affects the commands `next-completion' and
>> +`previous-completion'."
>> + :type 'boolean
>> + :version "29.1"
>> + :group 'completion)
>
> It seems now completion-wrap-movement has no effect:
> typing n, p, <right> or <left> eventually switches to the minibuffer,
> where continuing typing these keys uses other commands.
True, the only way I see right now to avoid this would be to check if
tab/backtab was used before switching to the minibuffer, and otherwise
wrap within the completions buffer.
>> (completion--in-region-1): Handle backtab to scroll backwards
>> @@ -1386,7 +1386,9 @@ completion--in-region-1
>> (set-window-start window (point-min) nil)
>> ;; Else scroll down one screen.
>> (with-selected-window window
>> - (scroll-up)))
>> + (if (equal (this-command-keys) [backtab])
>> + (scroll-down)
>> + (scroll-up))))
>
> Using S-TAB to scroll backwards also works nice.
> The only difference with TAB is that while typing
> several TABs reaches the end of the completions buffer,
> typing more TABs wraps to the beginning of the completions
> buffer, but S-TAB doesn't wrap to the end of the buffer.
Good point, this should fix that:
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Allow-for-next-completion-to-wrap-around-the-complet.patch --]
[-- Type: text/x-diff, Size: 7177 bytes --]
From 6155e4a3347a9f7d188eae125d71040b8c8dcdf2 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Thu, 9 Dec 2021 17:26:14 +0100
Subject: [PATCH] Allow for next-completion to wrap around the completion
buffer
* lisp/simple.el (completion-wrap-movement): Add new option.
(previous-completion): Update docstring.
(next-completion): Respect completion-wrap-movement.
(switch-to-completions): Handle backwards completion by jumping to the
end of the buffer.
* lisp/minibuffer.el: (minibuffer-local-completion-map): Bind
minibuffer-complete to backtab
(completion--in-region-1): Handle backtab to scroll backwards
---
lisp/minibuffer.el | 15 ++++++---
lisp/simple.el | 81 ++++++++++++++++++++++++++++++----------------
2 files changed, 63 insertions(+), 33 deletions(-)
diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 28bd1df59a..112c609a0a 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -1379,14 +1379,18 @@ completion--in-region-1
;; and this command is repeated, scroll that window.
((and (window-live-p minibuffer-scroll-window)
(eq t (frame-visible-p (window-frame minibuffer-scroll-window))))
- (let ((window minibuffer-scroll-window))
+ (let ((window minibuffer-scroll-window)
+ (reverse (equal (this-command-keys) [backtab])))
(with-current-buffer (window-buffer window)
- (if (pos-visible-in-window-p (point-max) window)
- ;; If end is in view, scroll up to the beginning.
- (set-window-start window (point-min) nil)
+ (if (pos-visible-in-window-p (if reverse (point-min) (point-max)) window)
+ ;; If end or beginning is in view, scroll up to the
+ ;; beginning or end respectively.
+ (if reverse
+ (set-window-point window (point-max))
+ (set-window-start window (point-min) nil))
;; Else scroll down one screen.
(with-selected-window window
- (scroll-up)))
+ (if reverse (scroll-down) (scroll-up))))
nil)))
;; If we're cycling, keep on cycling.
((and completion-cycling completion-all-sorted-completions)
@@ -2651,6 +2655,7 @@ minibuffer-local-completion-map
(let ((map (make-sparse-keymap)))
(set-keymap-parent map minibuffer-local-map)
(define-key map "\t" 'minibuffer-complete)
+ (define-key map [backtab] 'minibuffer-complete)
;; M-TAB is already abused for many other purposes, so we should find
;; another binding for it.
;; (define-key map "\e\t" 'minibuffer-force-complete)
diff --git a/lisp/simple.el b/lisp/simple.el
index d0e58575e1..626c24e10d 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -9027,38 +9027,57 @@ delete-completion-window
(if (get-buffer-window buf)
(select-window (get-buffer-window buf))))))
+(defcustom completion-wrap-movement t
+ "Non-nil means to wrap around when selecting completion options.
+This affects the commands `next-completion' and
+`previous-completion'."
+ :type 'boolean
+ :version "29.1"
+ :group 'completion)
+
(defun previous-completion (n)
- "Move to the previous item in the completion list."
+ "Move to the previous item in the completion list.
+With prefix argument N, move back N items (negative N means move
+forward)."
(interactive "p")
(next-completion (- n)))
(defun next-completion (n)
"Move to the next item in the completion list.
-With prefix argument N, move N items (negative N means move backward)."
+With prefix argument N, move N items (negative N means move
+backward)."
(interactive "p")
(let ((beg (point-min)) (end (point-max)))
- (while (and (> n 0) (not (eobp)))
- ;; If in a completion, move to the end of it.
- (when (get-text-property (point) 'mouse-face)
- (goto-char (next-single-property-change (point) 'mouse-face nil end)))
- ;; Move to start of next one.
- (unless (get-text-property (point) 'mouse-face)
- (goto-char (next-single-property-change (point) 'mouse-face nil end)))
- (setq n (1- n)))
- (while (and (< n 0) (not (bobp)))
- (let ((prop (get-text-property (1- (point)) 'mouse-face)))
- ;; If in a completion, move to the start of it.
- (when (and prop (eq prop (get-text-property (point) 'mouse-face)))
- (goto-char (previous-single-property-change
- (point) 'mouse-face nil beg)))
- ;; Move to end of the previous completion.
- (unless (or (bobp) (get-text-property (1- (point)) 'mouse-face))
- (goto-char (previous-single-property-change
- (point) 'mouse-face nil beg)))
- ;; Move to the start of that one.
- (goto-char (previous-single-property-change
- (point) 'mouse-face nil beg))
- (setq n (1+ n))))))
+ (catch 'bound
+ (while (> n 0)
+ ;; If in a completion, move to the end of it.
+ (when (get-text-property (point) 'mouse-face)
+ (goto-char (next-single-property-change (point) 'mouse-face nil end)))
+ (when (and completion-wrap-movement (eobp))
+ (throw 'bound nil))
+ ;; Move to start of next one.
+ (unless (get-text-property (point) 'mouse-face)
+ (goto-char (next-single-property-change (point) 'mouse-face nil end)))
+ (setq n (1- n)))
+ (while (< n 0)
+ (let ((prop (get-text-property (1- (point)) 'mouse-face)))
+ ;; If in a completion, move to the start of it.
+ (when (and prop (eq prop (get-text-property (point) 'mouse-face)))
+ (goto-char (previous-single-property-change
+ (point) 'mouse-face nil beg)))
+ ;; Move to end of the previous completion.
+ (unless (or (bobp) (get-text-property (1- (point)) 'mouse-face))
+ (goto-char (previous-single-property-change
+ (point) 'mouse-face nil beg)))
+ (when (and completion-wrap-movement (bobp))
+ (goto-char (next-single-property-change (point) 'mouse-face nil end))
+ (throw 'bound nil))
+ ;; Move to the start of that one.
+ (goto-char (previous-single-property-change
+ (point) 'mouse-face nil beg))
+ (setq n (1+ n)))))
+ (when (/= 0 n)
+ (switch-to-minibuffer))))
(defun choose-completion (&optional event)
"Choose the completion at point.
@@ -9283,10 +9302,16 @@ switch-to-completions
(get-buffer-window "*Completions*" 0)))))
(when window
(select-window window)
- ;; In the new buffer, go to the first completion.
- ;; FIXME: Perhaps this should be done in `minibuffer-completion-help'.
- (when (bobp)
- (next-completion 1)))))
+ (cond
+ ((and (memq this-command '(completion-at-point minibuffer-complete))
+ (equal (this-command-keys) [backtab])
+ (bobp))
+ (goto-char (point-max))
+ (previous-completion 1))
+ ;; In the new buffer, go to the first completion.
+ ;; FIXME: Perhaps this should be done in `minibuffer-completion-help'.
+ ((bobp)
+ (next-completion 1))))))
(defun read-expression-switch-to-completions ()
"Select the completion list window while reading an expression."
--
2.30.2
[-- Attachment #3: Type: text/plain, Size: 24 bytes --]
--
Philip Kaludercic
^ permalink raw reply related [relevance 41%]
* Re: Development Speed
@ 2021-12-20 8:16 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-12-20 8:16 UTC (permalink / raw)
To: xenodasein--- via Emacs development discussions.; +Cc: Po Lu, xenodasein
xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
writes:
> Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg01900.html
> From: Po Lu
> Date: Mon, 20 Dec 2021 08:31:18 +0800
>
>> and why should we use C17? What advantages does it hold?
>
> This is a legitimate question we can assess.
> Features like restricted pointers could improve performance?
> But I think the better question is what is the excuse for striving not to
> keep up with the latest language standard? (Assuming someone wants to work on
> it.)
I think the main issue is that by raising the language standard, you
break compatibility with systems that do not provide the compiler yet.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Suggestions for improvements to the *Completions* buffer
2021-12-19 23:58 41% ` Philip Kaludercic
@ 2021-12-20 9:03 41% ` Philip Kaludercic
1 sibling, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-12-20 9:03 UTC (permalink / raw)
To: Juri Linkov; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 795 bytes --]
Philip Kaludercic <philipk@posteo.net> writes:
> Juri Linkov <juri@linkov.net> writes:
>
>>> +(defcustom completion-wrap-movement t
>>> + "Non-nil means to wrap around when selecting completion options.
>>> +This affects the commands `next-completion' and
>>> +`previous-completion'."
>>> + :type 'boolean
>>> + :version "29.1"
>>> + :group 'completion)
>>
>> It seems now completion-wrap-movement has no effect:
>> typing n, p, <right> or <left> eventually switches to the minibuffer,
>> where continuing typing these keys uses other commands.
>
> True, the only way I see right now to avoid this would be to check if
> tab/backtab was used before switching to the minibuffer, and otherwise
> wrap within the completions buffer.
I have tried this behaviour out, and it seems reasonable.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0002-Allow-for-next-completion-to-wrap-around-the-complet.patch --]
[-- Type: text/x-diff, Size: 7738 bytes --]
From b5e1548e571c093e682996d0a5b32eb8fb4d7919 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Thu, 9 Dec 2021 17:26:14 +0100
Subject: [PATCH 2/3] Allow for next-completion to wrap around the completion
buffer
* lisp/simple.el (completion-wrap-movement): Add new option.
(previous-completion): Update docstring.
(next-completion): Respect completion-wrap-movement.
(switch-to-completions): Handle backwards completion by jumping to the
end of the buffer.
* lisp/minibuffer.el: (minibuffer-local-completion-map): Bind
minibuffer-complete to backtab
(completion--in-region-1): Handle backtab to scroll backwards
---
lisp/minibuffer.el | 15 +++++---
lisp/simple.el | 92 ++++++++++++++++++++++++++++++++--------------
2 files changed, 74 insertions(+), 33 deletions(-)
diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 28bd1df59a..112c609a0a 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -1379,14 +1379,18 @@ completion--in-region-1
;; and this command is repeated, scroll that window.
((and (window-live-p minibuffer-scroll-window)
(eq t (frame-visible-p (window-frame minibuffer-scroll-window))))
- (let ((window minibuffer-scroll-window))
+ (let ((window minibuffer-scroll-window)
+ (reverse (equal (this-command-keys) [backtab])))
(with-current-buffer (window-buffer window)
- (if (pos-visible-in-window-p (point-max) window)
- ;; If end is in view, scroll up to the beginning.
- (set-window-start window (point-min) nil)
+ (if (pos-visible-in-window-p (if reverse (point-min) (point-max)) window)
+ ;; If end or beginning is in view, scroll up to the
+ ;; beginning or end respectively.
+ (if reverse
+ (set-window-point window (point-max))
+ (set-window-start window (point-min) nil))
;; Else scroll down one screen.
(with-selected-window window
- (scroll-up)))
+ (if reverse (scroll-down) (scroll-up))))
nil)))
;; If we're cycling, keep on cycling.
((and completion-cycling completion-all-sorted-completions)
@@ -2651,6 +2655,7 @@ minibuffer-local-completion-map
(let ((map (make-sparse-keymap)))
(set-keymap-parent map minibuffer-local-map)
(define-key map "\t" 'minibuffer-complete)
+ (define-key map [backtab] 'minibuffer-complete)
;; M-TAB is already abused for many other purposes, so we should find
;; another binding for it.
;; (define-key map "\e\t" 'minibuffer-force-complete)
diff --git a/lisp/simple.el b/lisp/simple.el
index d0e58575e1..2d81dc62f4 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -9027,38 +9027,68 @@ delete-completion-window
(if (get-buffer-window buf)
(select-window (get-buffer-window buf))))))
+(defcustom completion-wrap-movement t
+ "Non-nil means to wrap around when selecting completion options.
+This affects the commands `next-completion' and
+`previous-completion'."
+ :type 'boolean
+ :version "29.1"
+ :group 'completion)
+
(defun previous-completion (n)
- "Move to the previous item in the completion list."
+ "Move to the previous item in the completion list.
+With prefix argument N, move back N items (negative N means move
+forward)."
(interactive "p")
(next-completion (- n)))
(defun next-completion (n)
"Move to the next item in the completion list.
-With prefix argument N, move N items (negative N means move backward)."
+With prefix argument N, move N items (negative N means move
+backward)."
(interactive "p")
(let ((beg (point-min)) (end (point-max)))
- (while (and (> n 0) (not (eobp)))
- ;; If in a completion, move to the end of it.
- (when (get-text-property (point) 'mouse-face)
- (goto-char (next-single-property-change (point) 'mouse-face nil end)))
- ;; Move to start of next one.
- (unless (get-text-property (point) 'mouse-face)
- (goto-char (next-single-property-change (point) 'mouse-face nil end)))
- (setq n (1- n)))
- (while (and (< n 0) (not (bobp)))
- (let ((prop (get-text-property (1- (point)) 'mouse-face)))
- ;; If in a completion, move to the start of it.
- (when (and prop (eq prop (get-text-property (point) 'mouse-face)))
- (goto-char (previous-single-property-change
- (point) 'mouse-face nil beg)))
- ;; Move to end of the previous completion.
- (unless (or (bobp) (get-text-property (1- (point)) 'mouse-face))
- (goto-char (previous-single-property-change
- (point) 'mouse-face nil beg)))
- ;; Move to the start of that one.
- (goto-char (previous-single-property-change
- (point) 'mouse-face nil beg))
- (setq n (1+ n))))))
+ (catch 'bound
+ (while (> n 0)
+ ;; If in a completion, move to the end of it.
+ (when (get-text-property (point) 'mouse-face)
+ (goto-char (next-single-property-change (point) 'mouse-face nil end)))
+ ;; If at the last completion option, wrap or skip to the
+ ;; minibuffer, if requested.
+ (when (and completion-wrap-movement (eobp))
+ (if (and (member (this-command-keys) '("\t" [backtab]))
+ completion-auto-select)
+ (throw 'bound nil)
+ (goto-char (point-min))))
+ ;; Move to start of next one.
+ (unless (get-text-property (point) 'mouse-face)
+ (goto-char (next-single-property-change (point) 'mouse-face nil end)))
+ (setq n (1- n)))
+ (while (< n 0)
+ (let ((prop (get-text-property (1- (point)) 'mouse-face)))
+ ;; If in a completion, move to the start of it.
+ (when (and prop (eq prop (get-text-property (point) 'mouse-face)))
+ (goto-char (previous-single-property-change
+ (point) 'mouse-face nil beg)))
+ ;; Move to end of the previous completion.
+ (unless (or (bobp) (get-text-property (1- (point)) 'mouse-face))
+ (goto-char (previous-single-property-change
+ (point) 'mouse-face nil beg)))
+ ;; If at the first completion option, wrap or skip to the
+ ;; minibuffer, if requested.
+ (when (and completion-wrap-movement (bobp))
+ (if (and (member (this-command-keys) '("\t" [backtab]))
+ completion-auto-select)
+ (progn
+ (goto-char (next-single-property-change (point) 'mouse-face nil end))
+ (throw 'bound nil))
+ (goto-char (point-max))))
+ ;; Move to the start of that one.
+ (goto-char (previous-single-property-change
+ (point) 'mouse-face nil beg))
+ (setq n (1+ n)))))
+ (when (/= 0 n)
+ (switch-to-minibuffer))))
(defun choose-completion (&optional event)
"Choose the completion at point.
@@ -9283,10 +9313,16 @@ switch-to-completions
(get-buffer-window "*Completions*" 0)))))
(when window
(select-window window)
- ;; In the new buffer, go to the first completion.
- ;; FIXME: Perhaps this should be done in `minibuffer-completion-help'.
- (when (bobp)
- (next-completion 1)))))
+ (cond
+ ((and (memq this-command '(completion-at-point minibuffer-complete))
+ (equal (this-command-keys) [backtab])
+ (bobp))
+ (goto-char (point-max))
+ (previous-completion 1))
+ ;; In the new buffer, go to the first completion.
+ ;; FIXME: Perhaps this should be done in `minibuffer-completion-help'.
+ ((bobp)
+ (next-completion 1))))))
(defun read-expression-switch-to-completions ()
"Select the completion list window while reading an expression."
--
2.30.2
[-- Attachment #3: Type: text/plain, Size: 24 bytes --]
--
Philip Kaludercic
^ permalink raw reply related [relevance 41%]
* Re: Migrating to sourcehut - what's missing?
@ 2021-12-21 21:24 93% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-12-21 21:24 UTC (permalink / raw)
To: Eric Abrahamsen; +Cc: emacs-devel
Eric Abrahamsen <eric@ericabrahamsen.net> writes:
> Theodor Thornhill <theo@thornhill.no> writes:
>
>>> Preferably any gotchas when installing should be noted down somewhere
>>> (e.g. sent to emacs-devel).
>>>
>>> Next, I would start looking into those things that are still missing.
>>> For starters, they would need to be listed and it should be ensured that
>>> there are good feature requests on the sourcehut issue tracker. If the
>>> sourcehut developers are willing to implement those things then great,
>>> otherwise it would be obviously be very useful if someone would
>>> volunteer to start working on those things.
>>>
>>
>> Actually, I think that running Sourcehut as a local instance wouldn't
>> really be necessary for the evaluation, because it is the same code that
>> is running on sr.ht. Apart from the fiddly bits with self hosting, the
>> workflow should be the same. I'd encourage people on this list getting
>> their own user there and trying it out, as I think many already have.
>> Specifically, emacs-devel would want to use the `meta`, `lists`, `git`,
>> `todo` and `builds` subprojects, that is all apart from the `hg` one.
>
> I wonder if it would make sense to have one of the maintainers sign up
> there and start a "pretend" official Emacs repo. They could start a
> mailing list alongside it that we could play with, and who knows, maybe
> that would eventually become the "real" official sr.ht repo.
>
> Eric
So that would be something like git.sr.ht/~eliz/emacs or
git.sr.ht/~lars/emacs? This makes me wonder how "hard coded" the user
names are in the sourcehut code base. Assuming the GNU project would
host its sourcehut instance on the domain git.gnu.org, srht.gnu.org,
source.gnu.org, or whatever, would it still be possible to remove the
"~..." username part? (I know this is as minor of an issue as it gets,
it's just curiosity).
Until then, it seems that the username "~gnu" is not taken. Maybe
someone more entitled than me could mirror a few repositories over there
for testing purposes?
--
Philip Kaludercic
^ permalink raw reply [relevance 93%]
* Re: Suggestions for improvements to the *Completions* buffer
@ 2021-12-21 21:32 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-12-21 21:32 UTC (permalink / raw)
To: Juri Linkov; +Cc: emacs-devel
Juri Linkov <juri@linkov.net> writes:
>> I guess this also raises the question of whether or not
>> completion-wrap-movement and completion-auto-select should be set to
>> non-nil by default or not? If applied, maybe they could be enabled
>> for a month or so, to gather experiences and then decide how to
>> continue on that basis.
>
> I agree it's a good idea to enable them both now, and hear any feedback
> for a month.
Done.
I'll be awaiting the angry mob.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Migrating to sourcehut - what's missing?
@ 2021-12-21 21:42 96% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-12-21 21:42 UTC (permalink / raw)
To: Theodor Thornhill; +Cc: Eric Abrahamsen, emacs-devel
Theodor Thornhill <theo@thornhill.no> writes:
>>
>> So that would be something like git.sr.ht/~eliz/emacs or
>> git.sr.ht/~lars/emacs? This makes me wonder how "hard coded" the user
>> names are in the sourcehut code base. Assuming the GNU project would
>> host its sourcehut instance on the domain git.gnu.org, srht.gnu.org,
>> source.gnu.org, or whatever, would it still be possible to remove the
>> "~..." username part? (I know this is as minor of an issue as it gets,
>> it's just curiosity).
>>
>> Until then, it seems that the username "~gnu" is not taken. Maybe
>> someone more entitled than me could mirror a few repositories over there
>> for testing purposes?
>>
>
> See my other mail just sent. ~emacs is owned by me as for now, unless
> ~gnu is preferred :)
My understanding is that this would be a practical demonstration right?
(I believe the consensus last time was that the service should be hosted
on FSF servers.) If that is the case, I think that if you could set up a
few example repositories (emacs, elpa, nongnu) on git., import a few
mailing list archives on lists. and make up some issues on todo. then
the discussion could become more concrete and the path forward more
clear.
--
Philip Kaludercic
^ permalink raw reply [relevance 96%]
Results 201-400 of ~1787 next (newer) | prev (older) | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2021-01-01 12:56 vc-fossil to non-gnu elpa? Alfred M. Szmidt
2021-01-03 17:21 ` Stefan Monnier
2021-01-04 5:15 ` Richard Stallman
2021-01-04 11:14 ` Alfred M. Szmidt
[not found] ` <E1kwfvo-00023O-2q@fencepost.gnu.org>
[not found] ` <E1kwi8m-000728-6Y@fencepost.gnu.org>
[not found] ` <E1kxPoY-0001xs-3z@fencepost.gnu.org>
2021-09-28 7:46 ` Alfred M. Szmidt
2021-09-28 12:06 90% ` Philip Kaludercic
2021-09-28 12:11 ` Alfred M. Szmidt
2021-09-28 12:35 96% ` Philip Kaludercic
2021-09-28 12:45 ` Stefan Monnier
2021-09-28 14:21 ` Alfred M. Szmidt
2021-09-28 15:25 ` Stefan Monnier
2021-09-29 6:13 ` Alfred M. Szmidt
2021-09-29 12:32 ` Stefan Monnier
2021-09-29 15:29 ` Alfred M. Szmidt
2021-09-29 17:24 ` Stefan Kangas
2021-09-30 14:22 99% ` Philip Kaludercic
2021-06-16 5:25 Emacs CLA requirement Andrei Kuznetsov
2021-06-16 9:37 ` Philip Kaludercic
2021-06-16 10:05 ` Andrei Kuznetsov
2021-06-16 10:22 ` Philip Kaludercic
2021-06-16 12:42 ` Andrei Kuznetsov
2021-06-16 12:55 ` Philip Kaludercic
2021-06-16 13:23 ` Christopher Dimech
2021-06-16 14:34 ` Adam Tack
2021-06-16 14:47 ` Stefan Monnier
2021-06-16 15:13 ` Adam Tack
2021-06-16 15:44 ` Stefan Monnier
2021-06-16 21:34 ` NonGNU ELPA work (Was: Emacs CLA requirement) Philip Kaludercic
2021-06-16 22:24 ` NonGNU ELPA work Stefan Monnier
2021-06-17 8:36 ` Philip Kaludercic
2021-08-27 15:42 14% ` Philip Kaludercic
2021-08-27 21:34 ` Stefan Monnier
2021-08-27 22:04 99% ` Philip Kaludercic
2021-08-27 22:25 ` Stefan Monnier
2021-08-29 14:36 99% ` Philip Kaludercic
2021-08-29 15:25 ` Bozhidar Batsov
2021-08-29 15:59 99% ` Philip Kaludercic
2021-09-23 22:51 56% ` Philip Kaludercic
2021-09-24 0:16 ` [External] : " Drew Adams
2021-09-24 10:05 83% ` Philip Kaludercic
2021-12-09 23:24 36% ` Philip Kaludercic
2021-12-10 1:06 ` Stefan Kangas
2021-12-10 14:47 99% ` Philip Kaludercic
2021-12-18 14:22 92% ` Philip Kaludercic
2021-08-03 7:17 Adding new packages to NonGNU ELPA Bozhidar Batsov
2021-08-03 13:06 ` Stefan Monnier
2021-08-09 8:07 ` Bozhidar Batsov
2021-08-09 17:06 ` Stefan Monnier
2021-08-09 17:54 ` Bozhidar Batsov
2021-08-09 18:15 ` Stefan Monnier
2021-08-11 7:03 ` Bozhidar Batsov
2021-08-25 11:05 88% ` Philip Kaludercic
2021-08-08 15:40 Easy configuration of a site-lisp directory Philip Kaludercic
2021-08-19 9:25 ` Philip Kaludercic
2021-08-19 20:24 ` Arthur Miller
2021-08-25 10:47 92% ` Philip Kaludercic
2021-08-25 22:13 ` Arthur Miller
2021-08-26 9:42 88% ` Philip Kaludercic
2021-08-23 9:14 ` Max Brieiev
2021-08-24 21:35 ` Stefan Monnier
2021-08-25 11:13 99% ` Philip Kaludercic
2021-08-25 14:37 ` Stefan Monnier
2021-08-25 14:55 99% ` Philip Kaludercic
2021-08-12 23:43 Collaborative editing Perry E. Metzger
2021-08-15 5:46 ` Jean Louis
2021-08-15 11:24 ` Ergus
2021-08-19 9:33 ` Philip Kaludercic
2021-08-19 14:18 ` Ergus
2021-08-19 15:36 ` Philip Kaludercic
2021-08-28 8:41 ` Qiantan Hong
2021-08-28 11:40 99% ` Philip Kaludercic
2021-08-28 11:53 ` Qiantan Hong
2021-08-28 12:14 93% ` Philip Kaludercic
2021-08-23 10:40 Update of ELPA package guess-language Titus von der Malsburg
2021-08-25 10:24 98% ` Philip Kaludercic
2021-08-25 11:51 ` Tassilo Horn
2021-08-26 5:31 ` Bozhidar Batsov
2021-08-29 3:03 ` Richard Stallman
2021-08-29 10:58 97% ` Philip Kaludercic
2021-08-30 3:03 ` Richard Stallman
2021-08-30 15:20 99% ` Philip Kaludercic
2021-08-31 3:08 ` Richard Stallman
2021-08-31 7:31 90% ` Philip Kaludercic
[not found] <20210706171402.18082.17826@vcs0.savannah.gnu.org>
[not found] ` <20210706171404.117E720B72@vcs0.savannah.gnu.org>
2021-08-24 14:45 ` master abe5eb9: Explain what ( . c) means to the Emacs Lisp reader Stefan Kangas
2021-08-25 10:25 99% ` Philip Kaludercic
2021-08-26 16:20 Gitlab Migration Daniel Fleischer
2021-08-26 17:24 80% ` Philip Kaludercic
2021-08-26 17:52 ` Theodor Thornhill
2021-08-26 18:21 99% ` Philip Kaludercic
2021-08-27 7:00 ` Daniel Fleischer
2021-08-27 11:30 ` Eli Zaretskii
2021-08-27 14:33 ` Stefan Monnier
2021-08-27 14:46 ` Lars Ingebrigtsen
2021-08-27 14:50 99% ` Philip Kaludercic
2021-08-27 15:29 ` Theodor Thornhill
2021-08-27 19:08 ` Eli Zaretskii
2021-08-27 19:38 ` Theodor Thornhill
2021-08-27 20:07 ` Eli Zaretskii
2021-08-27 20:58 67% ` Philip Kaludercic
2021-08-27 21:09 ` Dmitry Gutov
2021-08-27 21:17 ` Theodor Thornhill
2021-08-28 6:01 ` Eli Zaretskii
2021-08-28 6:26 ` Theodor Thornhill
2021-08-28 7:30 ` Eli Zaretskii
2021-08-28 10:18 ` Daniel Fleischer
2021-08-28 11:43 99% ` Philip Kaludercic
2021-08-28 11:45 ` Theodor Thornhill
2021-08-28 12:25 99% ` Philip Kaludercic
2021-08-28 6:00 ` Eli Zaretskii
2021-08-29 2:27 ` Dmitry Gutov
2021-08-30 2:58 ` Richard Stallman
2021-08-30 12:20 ` Dmitry Gutov
2021-08-30 12:48 ` Daniel Fleischer
2021-08-30 12:55 ` Dmitry Gutov
2021-09-03 4:57 ` Elias Mårtenson
2021-09-03 5:26 ` Ihor Radchenko
2021-09-03 7:26 85% ` Philip Kaludercic
2021-09-03 10:26 ` Dmitry Gutov
2021-09-03 11:11 77% ` Philip Kaludercic
2021-09-03 11:31 ` Dmitry Gutov
2021-09-03 11:41 ` Eli Zaretskii
2021-09-03 12:12 ` Dmitry Gutov
2021-09-03 12:27 ` Eli Zaretskii
2021-09-03 12:32 ` Dmitry Gutov
2021-09-03 12:45 ` Eli Zaretskii
2021-09-03 13:26 ` Dmitry Gutov
2021-09-03 14:15 93% ` Philip Kaludercic
2021-09-04 8:02 ` Daniel Fleischer
2021-09-04 8:18 ` Variables for easy customization (was: Gitlab Migration) Eli Zaretskii
2021-09-04 13:41 ` Variables for easy customization Stefan Monnier
2021-09-04 13:48 ` Lars Ingebrigtsen
2021-09-06 3:10 ` Richard Stallman
2021-09-06 6:39 99% ` Philip Kaludercic
2021-09-06 3:06 ` Emacs default bindings Richard Stallman
2021-09-06 12:02 ` Dmitry Gutov
2021-09-08 3:22 ` Richard Stallman
2021-09-08 6:39 ` Eli Zaretskii
2021-09-08 12:26 ` Dmitry Gutov
2021-09-08 13:37 ` Lars Ingebrigtsen
2021-09-08 14:53 ` Stefan Kangas
2021-09-08 15:06 95% ` Philip Kaludercic
2021-09-27 23:17 ` Dmitry Gutov
2021-09-27 23:40 ` Stefan Kangas
2021-09-28 6:58 99% ` Philip Kaludercic
2021-09-03 10:45 ` Gitlab Migration Stefan Kangas
2021-09-05 3:44 ` Richard Stallman
2021-09-07 2:55 ` Dmitry Gutov
2021-09-07 4:56 ` Arthur Miller
2021-09-07 5:01 ` Stefan Kangas
2021-09-07 5:38 ` Arthur Miller
2021-09-07 8:03 99% ` Philip Kaludercic
2021-08-31 3:09 ` Richard Stallman
2021-08-31 11:43 ` Dmitry Gutov
2021-08-31 16:21 ` John Yates
2021-08-31 16:37 ` Eli Zaretskii
2021-08-31 19:17 ` Dmitry Gutov
2021-08-31 19:37 ` Eli Zaretskii
2021-09-01 11:35 ` John Yates
2021-09-02 3:38 ` Richard Stallman
2021-09-02 19:02 ` Dmitry Gutov
2021-09-02 20:35 86% ` Representation of the Emacs userbase on emacs-devel Philip Kaludercic
2021-09-02 22:39 ` Dmitry Gutov
2021-09-03 6:28 ` Eli Zaretskii
2021-09-04 5:34 ` Yuan Fu
2021-09-05 4:40 ` Arthur Miller
2021-09-05 5:22 ` Stefan Kangas
2021-09-05 6:37 ` Arthur Miller
2021-09-05 7:13 ` Stefan Kangas
2021-09-05 8:08 ` Arthur Miller
2021-09-05 19:16 ` Dmitry Gutov
2021-09-05 19:45 ` Arthur Miller
2021-09-05 20:20 ` Dmitry Gutov
2021-09-06 5:04 ` Arthur Miller
2021-09-06 12:09 ` Dmitry Gutov
2021-09-06 13:52 ` Arthur Miller
2021-09-06 14:11 86% ` Philip Kaludercic
2021-09-03 6:06 ` Gitlab Migration Eli Zaretskii
2021-09-03 6:12 ` Lars Ingebrigtsen
2021-09-03 7:28 99% ` Philip Kaludercic
2021-09-03 7:31 ` Eli Zaretskii
2021-09-03 8:35 99% ` Philip Kaludercic
2021-08-27 23:04 Adding major or popular language modes to Emacs distribution Yuchen Pei
2021-08-27 23:12 93% ` Philip Kaludercic
2021-08-28 6:24 ` Eli Zaretskii
2021-08-28 13:45 83% ` Philip Kaludercic
2021-08-28 13:56 ` Eli Zaretskii
2021-08-28 14:30 99% ` Philip Kaludercic
2021-08-28 14:40 ` Eli Zaretskii
2021-08-28 15:32 73% ` Philip Kaludercic
2021-08-29 22:52 [ELPA/elpa-admin] Render README.org as ASCII with ox-ascii Adam Porter
2021-08-30 0:48 ` Stefan Monnier
2021-08-30 2:13 ` [ELPA/elpa-admin] Render README.org as HTML with ox-html Adam Porter
2021-09-03 2:01 ` Adam Porter
2021-09-07 3:31 ` Stefan Monnier
2021-09-07 8:12 99% ` Philip Kaludercic
2021-08-30 17:49 99% ` [ELPA/elpa-admin] Render README.org as ASCII with ox-ascii Philip Kaludercic
2021-08-31 10:17 [elpa] New package: vc-got Omar Polo
2021-08-31 13:32 90% ` Philip Kaludercic
2021-08-31 13:59 ` Omar Polo
2021-08-31 16:54 99% ` Philip Kaludercic
2021-09-09 15:50 88% ` Philip Kaludercic
2021-09-04 6:55 Why not set Emacs development workflow based on the popular git forges (GitHub, Bitbucket, Gitlab, ect)? Hongyi Zhao
2021-09-04 11:24 ` Po Lu
2021-09-04 12:50 ` Hongyi Zhao
2021-09-04 13:47 ` Kévin Le Gouguec
2021-09-04 13:58 ` Hongyi Zhao
2021-09-04 23:25 89% ` Philip Kaludercic
2021-09-07 3:22 Gathering data on user preferences Tim Cross
2021-09-07 4:25 ` Howard Melman
2021-09-07 6:28 ` Eli Zaretskii
2021-09-07 13:22 ` Howard Melman
2021-09-08 13:37 99% ` Philip Kaludercic
2021-09-07 6:42 ` tomas
2021-09-08 7:52 99% ` Philip Kaludercic
2021-09-08 8:14 ` Tim Cross
2021-09-08 12:52 96% ` Philip Kaludercic
2021-09-08 1:49 "Raw" string literals for elisp Anna Glasgall
2021-09-08 13:10 ` Stefan Monnier
2021-09-08 14:31 ` Anna Glasgall
2021-09-08 15:27 ` Mattias Engdegård
2021-09-08 16:01 ` Alan Mackenzie
2021-09-08 19:22 98% ` Philip Kaludercic
2021-09-08 21:11 ` Stefan Kangas
2021-09-08 21:24 99% ` Philip Kaludercic
2021-09-08 3:22 Suggestion for improving ergonomics of repeat-maps: define-repeat-map acdw
2021-09-08 14:54 97% ` Philip Kaludercic
2021-09-10 14:30 94% EmacsConf presentation on NonGNU ELPA Philip Kaludercic
2021-09-11 16:21 94% Cleaning up rcirc Philip Kaludercic
2021-09-11 16:49 ` Tassilo Horn
2021-09-11 17:49 98% ` Philip Kaludercic
2021-09-11 18:32 ` Tassilo Horn
2021-09-11 20:13 99% ` Philip Kaludercic
2021-09-11 21:01 ` Tassilo Horn
2021-09-21 18:52 ` Tassilo Horn
2021-09-21 19:18 99% ` Philip Kaludercic
2021-09-21 19:47 ` Tassilo Horn
2021-09-25 16:34 99% ` Philip Kaludercic
2021-09-11 20:16 98% ` Philip Kaludercic
2021-09-18 17:03 [ELPA] New package: ERC Amin Bandali
2021-09-19 14:38 ` Lars Ingebrigtsen
2021-09-26 15:22 ` Amin Bandali
2021-09-26 19:28 99% ` Philip Kaludercic
2021-09-26 20:41 ` Amin Bandali
2021-09-27 10:22 99% ` Philip Kaludercic
2021-09-26 20:15 ` Stefan Kangas
2021-09-26 21:03 ` Amin Bandali
2021-09-27 10:23 99% ` Philip Kaludercic
2021-09-20 23:35 79% Proposal: Forwards-Compatibility Library for Emacs Philip Kaludercic
2021-09-21 4:10 ` Lars Ingebrigtsen
2021-09-21 8:28 99% ` Philip Kaludercic
2021-09-21 12:31 ` Stefan Monnier
2021-09-21 12:40 ` Eli Zaretskii
2021-09-21 13:00 99% ` Philip Kaludercic
2021-09-21 13:12 ` Eli Zaretskii
2021-09-21 13:28 99% ` Philip Kaludercic
2021-09-21 13:24 ` João Távora
2021-09-21 13:29 99% ` Philip Kaludercic
2021-09-21 12:58 82% ` Philip Kaludercic
2021-09-21 13:37 ` Arthur Miller
2021-09-21 13:54 74% ` Philip Kaludercic
2021-09-21 15:02 ` Lars Ingebrigtsen
2021-09-21 15:40 ` João Távora
2021-09-21 16:10 99% ` Philip Kaludercic
2021-09-21 19:24 ` Stefan Monnier
2021-09-21 21:06 98% ` Philip Kaludercic
2021-09-21 21:50 ` Stefan Monnier
2021-09-22 6:48 92% ` Philip Kaludercic
2021-09-22 17:53 ` Stefan Monnier
2021-09-22 18:54 99% ` Philip Kaludercic
2021-09-21 21:57 ` Lars Ingebrigtsen
2021-09-21 22:08 ` João Távora
2021-09-22 6:53 94% ` Philip Kaludercic
2021-09-21 13:05 93% ` Philip Kaludercic
2021-09-21 13:27 ` Arthur Miller
2021-09-21 13:45 81% ` Philip Kaludercic
2021-09-21 22:17 ` Richard Stallman
2021-09-21 22:24 ` Lars Ingebrigtsen
2021-09-22 9:54 60% ` Philip Kaludercic
2021-10-04 23:00 75% ` [ELPA] Add compat.el Philip Kaludercic
2021-10-07 7:03 95% ` Old (static) builds of Emacs Philip Kaludercic
2021-10-07 7:48 ` Michael Albinus
2021-10-07 7:56 99% ` Philip Kaludercic
2021-10-07 12:49 ` Stefan Monnier
2021-10-07 20:29 99% ` Philip Kaludercic
2021-11-30 21:21 99% ` Philip Kaludercic
2021-10-07 20:49 90% ` [ELPA] Add compat.el Philip Kaludercic
2021-10-08 5:56 ` Eli Zaretskii
2021-10-08 9:59 99% ` Philip Kaludercic
2021-10-08 11:10 ` Eli Zaretskii
2021-10-08 11:35 99% ` Philip Kaludercic
2021-10-08 7:45 ` Mattias Engdegård
2021-10-08 10:00 99% ` Philip Kaludercic
2021-10-15 19:08 83% ` Philip Kaludercic
[not found] <20210927003203.15806.29864@vcs0.savannah.gnu.org>
[not found] ` <20210927003205.EF26620A5E@vcs0.savannah.gnu.org>
2021-09-27 11:10 ` Better way to require with shorthands/renamed symbols Stefan Kangas
2021-09-27 11:58 ` Dmitry Gutov
2021-09-27 12:54 ` Shorthands have landed on master (Was: Better way to require with shorthands/renamed symbols) João Távora
2021-09-27 22:40 99% ` Shorthands have landed on master Philip Kaludercic
2021-09-27 22:58 ` João Távora
2021-09-28 7:15 88% ` Philip Kaludercic
2021-09-28 9:03 ` João Távora
2021-09-28 9:22 99% ` Philip Kaludercic
2021-09-28 0:38 Do shorthands break basic tooling (tags, grep, etc)? (was Re: Shorthands have landed on master) Phil Sainty
2021-09-28 7:21 ` João Távora
2021-09-28 12:49 ` Phil Sainty
2021-09-30 6:06 ` Richard Stallman
2021-10-05 5:57 ` Elisp LSP Server Ag Ibragimov
2021-10-05 6:38 ` Po Lu
2021-10-05 9:50 99% ` Philip Kaludercic
2021-10-05 11:27 ` Po Lu
2021-10-05 11:46 98% ` Philip Kaludercic
2021-10-06 20:57 ` Richard Stallman
2021-10-06 21:22 70% ` Philip Kaludercic
2021-10-07 0:49 ` Po Lu
2021-10-10 12:48 ` Ag Ibragimov
2021-10-10 14:19 ` Daniel Martín
2021-10-10 16:49 99% ` Philip Kaludercic
2021-10-11 7:44 ` Po Lu
2021-10-12 5:29 ` Ag Ibragimov
2021-10-12 22:43 ` Richard Stallman
2021-10-13 3:42 ` Ag Ibragimov
2021-10-13 5:20 ` Po Lu
2021-10-13 12:39 ` Eli Zaretskii
2021-10-13 12:49 ` Po Lu
2021-10-13 13:25 ` Eli Zaretskii
2021-10-13 13:38 96% ` Philip Kaludercic
2021-10-06 20:57 ` Richard Stallman
2021-10-06 21:35 93% ` Philip Kaludercic
2021-10-05 10:15 ` Joost Kremers
2021-10-06 20:57 ` Richard Stallman
2021-10-12 2:52 ` Ag Ibragimov
2021-10-12 5:55 ` Po Lu
2021-10-12 7:22 ` Ag Ibragimov
2021-10-12 10:21 85% ` Philip Kaludercic
2021-10-12 12:14 ` tomas
2021-10-12 12:51 99% ` Philip Kaludercic
2021-09-28 13:11 ELPA: New package: nano-theme Nicolas P. Rougier (inria)
2021-09-28 17:47 79% ` Philip Kaludercic
2021-09-28 17:57 ` Nicolas P. Rougier (inria)
2021-09-28 18:37 96% ` Philip Kaludercic
2021-09-29 5:07 ` Nicolas P. Rougier (inria)
2021-09-29 6:24 99% ` Philip Kaludercic
2021-10-01 9:59 97% ` Philip Kaludercic
2021-10-01 10:05 ` Nicolas P. Rougier (inria)
2021-10-01 10:15 99% ` Philip Kaludercic
2021-10-01 8:21 flymake-kondor on NonGNU ELPA Manuel Uberti
2021-10-01 8:59 94% ` Philip Kaludercic
2021-10-04 5:39 ` Manuel Uberti
2021-10-04 12:08 99% ` Philip Kaludercic
2021-10-08 11:36 99% ` Philip Kaludercic
2021-10-04 8:33 project-find-file: switch to include non-tracked files Manuel Uberti
2021-10-04 11:24 99% ` Philip Kaludercic
2021-10-06 9:35 ELPA: New package: nano-modeline Nicolas P. Rougier (inria)
2021-10-06 15:38 99% ` Philip Kaludercic
2021-10-06 15:42 ` Nicolas P. Rougier (inria)
2021-10-06 18:50 93% ` Philip Kaludercic
2021-10-07 10:42 Nicolas P. Rougier (gmail)
2021-10-07 20:32 99% ` ELPA: New pacReferences: <m135pepivk.fsf@P-E6-PFredo1.imn.u-bordeaux2.fr> <m15yu9unaa.fsf@P-E6-PFredo1.imn.u-bordeaux2.fr> Philip Kaludercic
2021-10-12 17:01 ELPA: new package nano-agenda Nicolas P. Rougier (inria)
2021-10-12 19:19 95% ` Philip Kaludercic
2021-10-12 19:29 ` Nicolas P. Rougier (inria)
2021-10-12 19:41 98% ` Philip Kaludercic
2021-10-18 22:50 ` Adam Porter
2021-10-18 23:05 ` Stefan Monnier
2021-10-19 11:55 99% ` Philip Kaludercic
2021-10-19 12:07 ` Stefan Kangas
2021-10-19 12:24 94% ` Philip Kaludercic
2021-10-21 14:28 99% ` Philip Kaludercic
2021-10-12 18:57 ELPA: new package coterm miha
2021-10-12 19:14 99% ` Philip Kaludercic
2021-10-18 17:46 Prettify elpa.gnu.org Stefan Monnier
2021-10-18 19:45 95% ` Philip Kaludercic
2021-10-18 20:05 93% ` Philip Kaludercic
2021-10-18 22:34 ` Stefan Monnier
2021-10-19 16:47 99% ` Philip Kaludercic
2021-10-19 20:34 ` Stefan Monnier
2021-10-21 21:02 99% ` Philip Kaludercic
2021-10-21 21:26 ` Stefan Monnier
2021-10-22 20:00 99% ` Philip Kaludercic
2021-10-22 20:38 ` Stefan Kangas
2021-10-22 20:44 99% ` Philip Kaludercic
2021-10-23 16:12 ` Stefan Monnier
2021-10-24 10:25 99% ` Philip Kaludercic
2021-10-23 23:28 ` Richard Stallman
2021-10-24 9:15 99% ` Philip Kaludercic
2021-10-18 20:22 ` Stefan Kangas
2021-10-18 21:27 99% ` Philip Kaludercic
2021-10-18 18:08 [NonGNU ELPA] New package proposal: git-modes Jonas Bernoulli
2021-10-18 19:50 97% ` Philip Kaludercic
2021-10-20 6:46 ` Richard Stallman
2021-10-20 18:52 99% ` Philip Kaludercic
2021-10-19 20:20 59% [NonGNU ELPA] Colour themes Philip Kaludercic
[not found] <20211004081724.6281.11798@vcs0.savannah.gnu.org>
2021-10-14 7:23 ` Moving kbd to subr.el Eli Zaretskii
2021-10-14 11:50 ` Stefan Kangas
2021-10-14 11:56 ` Eli Zaretskii
2021-10-14 12:06 ` Lars Ingebrigtsen
2021-10-14 20:28 ` Stefan Kangas
2021-10-14 20:55 ` Lars Ingebrigtsen
2021-10-14 21:04 ` Stefan Kangas
2021-10-14 21:13 ` Lars Ingebrigtsen
2021-10-15 2:07 ` Stefan Kangas
2021-10-16 13:48 ` Lars Ingebrigtsen
2021-10-16 14:33 ` Stefan Kangas
2021-10-16 15:55 ` Lars Ingebrigtsen
2021-10-17 18:54 ` Lars Ingebrigtsen
2021-10-17 19:32 ` Gregory Heytings
2021-10-17 19:39 ` Eli Zaretskii
2021-10-17 19:42 ` Gregory Heytings
2021-10-17 19:58 ` Lars Ingebrigtsen
2021-10-18 11:41 ` Eli Zaretskii
2021-10-20 6:47 ` Richard Stallman
2021-10-20 7:48 ` Lars Ingebrigtsen
2021-10-20 18:51 99% ` Philip Kaludercic
2021-10-21 2:53 ` Lars Ingebrigtsen
2021-10-21 13:40 99% ` Philip Kaludercic
2021-10-22 14:20 ` Lars Ingebrigtsen
2021-10-22 14:57 97% ` Philip Kaludercic
2021-10-22 15:02 ` Lars Ingebrigtsen
2021-10-22 15:06 98% ` Philip Kaludercic
2021-10-22 15:10 ` Lars Ingebrigtsen
2021-10-22 18:16 99% ` Philip Kaludercic
2021-10-22 18:18 ` Lars Ingebrigtsen
2021-10-23 23:29 ` Richard Stallman
2021-10-24 13:24 ` Lars Ingebrigtsen
2021-10-24 18:10 ` Corwin Brust
2021-10-24 18:42 ` Lars Ingebrigtsen
2021-10-25 16:06 ` Corwin Brust
2021-10-25 16:10 98% ` Philip Kaludercic
2021-10-17 19:55 ` Lars Ingebrigtsen
2021-10-17 21:20 ` Gregory Heytings
2021-10-18 6:02 ` Lars Ingebrigtsen
2021-10-18 12:46 ` Gregory Heytings
2021-10-18 13:15 ` Lars Ingebrigtsen
2021-10-18 13:53 ` Stefan Kangas
2021-10-18 15:53 ` Stefan Monnier
2021-10-18 15:58 ` Lars Ingebrigtsen
2021-10-18 16:33 ` Stefan Monnier
2021-10-19 2:30 ` Lars Ingebrigtsen
2021-10-19 7:48 ` Gregory Heytings
2021-10-19 10:46 99% ` Philip Kaludercic
2021-10-20 21:30 ELPA: new package capf-autosuggest miha
2021-10-21 13:43 99% ` Philip Kaludercic
2021-10-21 14:10 ` miha
2021-10-21 14:55 99% ` Philip Kaludercic
2021-10-21 16:01 ` miha
2021-10-21 17:17 91% ` philipk
2021-10-21 17:18 ` Philip Kaludercic
2021-10-21 18:14 ` miha
2021-10-21 18:24 99% ` Philip Kaludercic
[not found] <20211017094026.1751.35204@vcs0.savannah.gnu.org>
[not found] ` <20211017094027.2E0DE209AA@vcs0.savannah.gnu.org>
2021-10-22 21:09 99% ` [nongnu] main e7a6b32: * elpa-packages (haml-mode): Manually pin a version Philip Kaludercic
2021-10-23 23:39 ` Stefan Monnier
2021-11-02 8:08 97% ` Philip Kaludercic
2021-10-25 3:06 [ELPA] New package: vertico-posframe tumashu
2021-10-25 16:13 99% ` Philip Kaludercic
2021-10-26 0:45 ` tumashu
2021-10-26 7:25 ` Iñigo Serna
2021-10-26 7:35 ` Daniel Mendler
2021-10-26 12:00 ` Stefan Monnier
2021-10-26 16:51 99% ` Philip Kaludercic
2021-10-26 9:12 99% ` Philip Kaludercic
2021-10-27 18:00 99% ` Philip Kaludercic
2021-10-25 13:14 master f8fed41 2/3: image-dired: Improve XDG compliance Eli Zaretskii
2021-10-25 16:14 99% ` Philip Kaludercic
2021-10-25 16:39 ` Eli Zaretskii
2021-10-25 17:52 95% ` Philip Kaludercic
2021-10-25 18:30 ` Eli Zaretskii
2021-10-26 16:47 99% ` Philip Kaludercic
2021-10-25 17:48 ` Stefan Monnier
2021-10-25 17:55 99% ` Philip Kaludercic
2021-10-26 8:38 GNU ELPA package proposal: visual-fill-column Joost Kremers
2021-10-26 14:50 ` Stefan Monnier
2021-10-26 15:17 ` Stefan Kangas
2021-10-26 15:20 ` Stefan Monnier
2021-10-26 19:03 99% ` Philip Kaludercic
2021-11-01 20:27 99% ` Philip Kaludercic
2021-11-01 21:35 ` Stefan Monnier
2021-11-01 23:39 99% ` Philip Kaludercic
2021-10-30 20:28 94% [ELPA] Add embark Philip Kaludercic
2021-10-31 4:20 ` Stefan Monnier
2021-10-31 8:22 99% ` Philip Kaludercic
2021-11-09 17:45 ELPA: add mct.el Protesilaos Stavrou
2021-11-11 10:25 ` Theodor Thornhill
2021-11-11 15:34 99% ` Philip Kaludercic
2021-11-14 0:00 99% ` Philip Kaludercic
2021-11-11 9:02 [RFC] certfp for rcirc Omar Polo
2021-11-14 18:25 94% ` Philip Kaludercic
2021-11-15 18:02 ` Omar Polo
2021-11-15 21:49 ` Omar Polo
2021-11-17 20:23 99% ` Philip Kaludercic
2021-11-21 18:01 99% ` Philip Kaludercic
2021-11-14 8:44 [ELPA] new package: sndio.el Omar Polo
2021-11-14 18:17 93% ` Philip Kaludercic
2021-11-14 18:27 ` Omar Polo
2021-11-14 18:46 99% ` Philip Kaludercic
2021-11-14 18:29 ` Stefan Monnier
2021-11-14 18:32 99% ` Philip Kaludercic
[not found] <m1zgq6xon7.fsf.ref@yahoo.es>
2021-11-15 0:12 ` Grammar checking in Emacs Daniel Martín
2021-11-15 2:46 ` Stefan Monnier
2021-11-15 22:43 ` Peter Oliver
2021-11-15 23:02 ` Stefan Monnier
2021-11-16 18:01 99% ` Philip Kaludercic
2021-11-20 17:53 could matlab-mode be in ELPA or the GNU emacs tree (like auctex and org-mode)? Uwe Brauer
2021-11-20 22:42 98% ` Philip Kaludercic
2021-11-30 19:19 File names in ChangeLog entries Stefan Kangas
2021-11-30 20:07 81% ` Philip Kaludercic
2021-12-02 13:13 [PATCH] * elpa-packages (webpaste): New package Elis Hirwing
2021-12-02 16:05 93% ` Philip Kaludercic
2021-12-02 21:02 ` Elis Hirwing
2021-12-02 23:15 97% ` Philip Kaludercic
2021-12-03 11:06 ` Elis Hirwing
2021-12-03 11:24 ` Po Lu
2021-12-04 8:36 99% ` Philip Kaludercic
2021-12-04 8:37 99% ` Philip Kaludercic
2021-12-02 19:30 `csv-mode' part of core? Tor Kringeland
2021-12-03 16:50 ` Lars Ingebrigtsen
2021-12-04 11:46 99% ` Philip Kaludercic
2021-12-02 21:06 Variable for Confirming Killing a Buffer Oliver Taylor
2021-12-02 22:41 ` Stefan Kangas
2021-12-02 23:17 99% ` Philip Kaludercic
2021-12-06 1:51 sqlite3 Lars Ingebrigtsen
2021-12-09 17:36 99% ` sqlite3 Philip Kaludercic
2021-12-10 0:25 ` sqlite3 Lars Ingebrigtsen
2021-12-10 14:46 99% ` sqlite3 Philip Kaludercic
2021-12-11 3:19 ` sqlite3 Lars Ingebrigtsen
2021-12-11 20:03 99% ` sqlite3 Philip Kaludercic
2021-12-12 4:43 ` sqlite3 Lars Ingebrigtsen
2021-12-12 12:19 99% ` sqlite3 Philip Kaludercic
2021-12-08 20:55 New package: resist! Qiantan Hong
2021-12-09 2:48 ` Karl Fogel
2021-12-09 9:15 ` Tassilo Horn
2021-12-09 9:25 ` Qiantan Hong
2021-12-09 9:36 ` Tassilo Horn
2021-12-09 20:37 ` Qiantan Hong
2021-12-10 18:25 ` Qiantan Hong
2021-12-10 18:59 ` Stefan Monnier
2021-12-10 19:15 ` Qiantan Hong
2021-12-10 19:24 99% ` Philip Kaludercic
2021-12-10 19:57 ` Eli Zaretskii
2021-12-10 20:19 ` Alexandre Garreau
2021-12-10 20:28 ` Qiantan Hong
2021-12-10 20:34 98% ` Philip Kaludercic
2021-12-09 17:22 34% Suggestions for improvements to the *Completions* buffer Philip Kaludercic
2021-12-09 17:49 ` [External] : " Drew Adams
2021-12-09 18:05 99% ` Philip Kaludercic
2021-12-09 19:49 ` Juri Linkov
2021-12-09 20:07 99% ` Philip Kaludercic
2021-12-09 20:21 ` Juri Linkov
2021-12-13 19:16 99% ` Philip Kaludercic
2021-12-09 21:16 ` Stefan Kangas
2021-12-13 19:13 99% ` Philip Kaludercic
2021-12-13 21:36 96% ` Philip Kaludercic
2021-12-14 21:13 ` Juri Linkov
2021-12-17 11:27 62% ` Philip Kaludercic
2021-12-17 15:00 97% ` Philip Kaludercic
2021-12-18 12:22 35% ` Philip Kaludercic
2021-12-18 12:31 ` Po Lu
2021-12-18 13:39 81% ` Philip Kaludercic
2021-12-18 17:41 ` Juri Linkov
2021-12-19 14:55 38% ` Philip Kaludercic
2021-12-19 17:18 ` Juri Linkov
2021-12-19 23:58 41% ` Philip Kaludercic
2021-12-20 9:03 41% ` Philip Kaludercic
2021-12-21 19:02 ` Juri Linkov
2021-12-21 21:32 99% ` Philip Kaludercic
2021-12-18 13:01 Merging the pgtk branch Po Lu
2021-12-18 13:24 ` Po Lu
2021-12-18 13:26 ` Po Lu
2021-12-18 13:56 ` Yuuki Harano
2021-12-18 14:15 ` Bozhidar Batsov
2021-12-18 14:21 ` Eli Zaretskii
2021-12-18 15:12 ` Bozhidar Batsov
2021-12-18 15:37 99% ` Philip Kaludercic
2021-12-19 17:06 Development Speed xenodasein--- via Emacs development discussions.
2021-12-20 0:31 ` Po Lu
2021-12-20 4:16 ` xenodasein--- via Emacs development discussions.
2021-12-20 8:16 99% ` Philip Kaludercic
2021-12-21 12:51 Migrating to sourcehut - what's missing? Theodor Thornhill
2021-12-21 17:32 ` Stefan Kangas
2021-12-21 18:30 ` Theodor Thornhill
2021-12-21 18:58 ` Eric Abrahamsen
2021-12-21 21:24 93% ` Philip Kaludercic
2021-12-21 21:29 ` Theodor Thornhill
2021-12-21 21:42 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).