[NonGNU ELPA] New packages: Vcomplete, swsw

[NonGNU ELPA] New packages: Vcomplete, swsw

[Daniel Semyonov]

[-- Attachment #1: Type: text/plain, Size: 2526 bytes --]

Hi,

I'd like to submit two packages to NonGNU ELPA: Vcomplete and swsw.

Vcomplete provides a minor mode enhancing the default completion list
buffer.
It is designed to change as little as possible so as to remain
compatible with other enhancements to the default completion interface,
while also providing entry points for advanced users who wish to perform
actions on completion candidates.

From the package commentary:

When `vcomplete-mode' is active:
- The completion list buffer opens and updates automatically (see
  `vcomplete-auto-update').
- The completion list buffer can be controlled through the
  minibuffer (during minibuffer completion) or the current buffer
  (during in-buffer completion), if it's visible.
- The currently selected completion is highlighted in the
  completion list buffer.

C-n moves point to the next completion.

C-p moves point to the previous completion.

M-RET (C-M-m) chooses the completion at point.

Source code: https://sr.ht/~dsemy/vcomplete
Homepage (change log and manual): https://dsemy.com/projects/vcomplete

swsw (simple window switching) provides a minor mode for switching to
windows using IDs assigned to them automatically.
It is designed to be easily extensible, providing ways to change how IDs
are displayed and to easily define new actions to be performed on
windows.

From the package commentary:

When swsw-mode is active:
- A window ID is displayed using a mode line lighter or a display
  function (see `swsw-display-function').
- Window IDs are assigned to all windows on all frames except for
  the minibuffer(by default, see `swsw-scope').
- `other-window' (C-x o by default) is remapped to `swsw-select'.

C-x o ID switches focus to the window which corresponds to ID.

C-x o m switches focus to the minibuffer if it's active.

C-x o 0 ID deletes the window which corresponds to ID.

Source code: https://sr.ht/~dsemy/swsw
Homepage (change log and manual): https://dsemy.com/projects/swsw


Both packages include Texinfo manuals (from which the manuals on their
homepages is generated).
Please let me know beforehand if there is intention to add either
package to NonGNU ELPA, so I could update their manuals and add
'.elpaignore' files to their repositories.

Attached are patches for nongnu.git adding these packages.

Regards,
Daniel

PS: I initially intended to submit these packages to GNU ELPA, but
unfortunately I probably won't be able to assign copyright any time
soon. (I'm assuming it would be possible to move them to GNU ELPA in the
future?)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: vcomplete-patch --]
[-- Type: text/x-diff, Size: 789 bytes --]

From bf42dc60b335e9806130c072b5c30bce7c9809c6 Mon Sep 17 00:00:00 2001
From: Daniel Semyonov <daniel@dsemy.com>
Date: Sun, 22 May 2022 13:05:19 +0300
Subject: [PATCH 1/2] * elpa-packages (vcomplete): New package

---
 elpa-packages | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/elpa-packages b/elpa-packages
index 734584008d..30f7921dad 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -550,6 +550,10 @@
 
  ("vc-fossil"		:url "https://github.com/venks1/emacs-fossil")
 
+ ("vcomplete"		:url "https://git.sr.ht/~dsemy/vcomplete"
+  :doc "vcomplete.texi"
+  :news "NEWS")
+
  ("visual-fill-column"  :url "https://codeberg.org/joostkremers/visual-fill-column.git"
   :readme "README.md"
   :ignored-files ("Cask" "LICENSE" "adaptive-wrap.png" "after.png" "before.png"
-- 
2.36.1


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: swsw-patch --]
[-- Type: text/x-diff, Size: 773 bytes --]

From e5ffb0dbc4f1b390be01cc0e1137c3622fe36543 Mon Sep 17 00:00:00 2001
From: Daniel Semyonov <daniel@dsemy.com>
Date: Sun, 22 May 2022 13:09:41 +0300
Subject: [PATCH 2/2] * elpa-packages (swsw): New package

---
 elpa-packages | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/elpa-packages b/elpa-packages
index 30f7921dad..dcc726e639 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -522,6 +522,10 @@
  ("swift-mode"		:url "https://github.com/swift-emacs/swift-mode"
   :ignored-files ("COPYING" "scripts" "test" "Eldev" "Makefile"))
 
+ ("swsw"		:url "https://git.sr.ht/~dsemy/swsw"
+  :doc "swsw.texi"
+  :news "NEWS")
+ 
  ("textile-mode"	:url "https://github.com/juba/textile-mode")
 
  ("systemd"		:url "https://github.com/holomorph/systemd-mode"
-- 
2.36.1

Re: [NonGNU ELPA] New packages: Vcomplete, swsw

[Philip Kaludercic]

Daniel Semyonov <daniel@dsemy.com> writes:

> Hi,
>
> I'd like to submit two packages to NonGNU ELPA: Vcomplete and swsw.
>
> Vcomplete provides a minor mode enhancing the default completion list
> buffer.
> It is designed to change as little as possible so as to remain
> compatible with other enhancements to the default completion interface,
> while also providing entry points for advanced users who wish to perform
> actions on completion candidates.
>
> From the package commentary:
>
> When `vcomplete-mode' is active:
> - The completion list buffer opens and updates automatically (see
>   `vcomplete-auto-update').
> - The completion list buffer can be controlled through the
>   minibuffer (during minibuffer completion) or the current buffer
>   (during in-buffer completion), if it's visible.
> - The currently selected completion is highlighted in the
>   completion list buffer.
>
> C-n moves point to the next completion.
>
> C-p moves point to the previous completion.
>
> M-RET (C-M-m) chooses the completion at point.
>
> Source code: https://sr.ht/~dsemy/vcomplete
> Homepage (change log and manual): https://dsemy.com/projects/vcomplete

Very interesting.  From a brief look at the repo, I just have a few
questions/comments:

- You add vcomplete-embark.el, that seems to be a package in it's own
  right (with a dependency on embark), but with your patch this will
  just be bundled into the same package.  Is this intentional?

- A practice I have taken up for my own packages on SourceHut is to add
  the mailing list as the maintainer.  I'm not saying you should do the
  same, just that it might make sense to mention it somewhere.

- The -pkg.el file should be unnecessary, as ELPA generates its own.

- Could the vector key syntax ([?\C-a]) be replaced with a (kbd "C-a")?
  I think the general trend nowadays is towards the latter, and more
  people are familiar with it.

- You should probably format the reference to the manual in your
  commentary section as described in the Info node (elisp) Documentation
  Tips.

I hope to try it out soon and give comments on the code + behaviour too.

> swsw (simple window switching) provides a minor mode for switching to
> windows using IDs assigned to them automatically.
> It is designed to be easily extensible, providing ways to change how IDs
> are displayed and to easily define new actions to be performed on
> windows.

Have you made up your mind about the name, or could you be convinced to
change it to something like "window-switch" or "windswitch" (so that it
sounds similar to windmove)?  Just suggestions of course, I just
anticipate a discussion on this question, because the name itself is not
that expressive.

> From the package commentary:
>
> When swsw-mode is active:
> - A window ID is displayed using a mode line lighter or a display
>   function (see `swsw-display-function').
> - Window IDs are assigned to all windows on all frames except for
>   the minibuffer(by default, see `swsw-scope').
> - `other-window' (C-x o by default) is remapped to `swsw-select'.
>
> C-x o ID switches focus to the window which corresponds to ID.
>
> C-x o m switches focus to the minibuffer if it's active.
>
> C-x o 0 ID deletes the window which corresponds to ID.
>
> Source code: https://sr.ht/~dsemy/swsw
> Homepage (change log and manual): https://dsemy.com/projects/swsw

The same comments as above, for the most part.

> Both packages include Texinfo manuals (from which the manuals on their
> homepages is generated).
> Please let me know beforehand if there is intention to add either
> package to NonGNU ELPA, so I could update their manuals and add
> '.elpaignore' files to their repositories.

I don't see why not. 

> Attached are patches for nongnu.git adding these packages.
>
> Regards,
> Daniel
>
> PS: I initially intended to submit these packages to GNU ELPA, but
> unfortunately I probably won't be able to assign copyright any time
> soon. (I'm assuming it would be possible to move them to GNU ELPA in the
> future?)

It should be possible.

Re: [NonGNU ELPA] New packages: Vcomplete, swsw

[Daniel Semyonov]

>>>>> Philip Kaludercic writes:

    > - You add vcomplete-embark.el, that seems to be a package in it's
    > own right (with a dependency on embark), but with your patch this
    > will just be bundled into the same package.  Is this intentional?

Semi-intentional... now that you mention it, is it possible for two
(related) packages to share the same git repository? If so,
vcomplete-embark should be its own package.

In any case, I haven't tested this integration in a while, so I think it
would make more sense to completely exclude 'vcomplete-embark.el' for
now (this integration broke in the past due to changes to Embark and
Vcomplete, and might be broken in some way now as I don't currently use
Embark).  I'll do some testing in the next few days.

    > - A practice I have taken up for my own packages on SourceHut is
    > to add the mailing list as the maintainer.  I'm not saying you
    > should do the same, just that it might make sense to mention it
    > somewhere.

That's actually a very nice idea, thanks.

    > - The -pkg.el file should be unnecessary, as ELPA generates its
    > own.

Since both packages are complex (as in, they contain multiple files),
when I generate my own package tar (for distribution on my site for
example, as the packages weren't available on any archive before), it
needs to contain a <package>-pkg.el file for Emacs to install it (or at
least that's what I remember from testing I did long ago).
I will admit this file should just be generated automatically during the
build process in this case too, I just never got around to implementing
that.

    > - Could the vector key syntax ([?\C-a]) be replaced with a (kbd
    > "C-a")?  I think the general trend nowadays is towards the latter,
    > and more people are familiar with it.

Now that you mention it, since it's just an example, wouldn't it make
more sense to use 'keymap-set' for it? (Although technically both
packages could be used with an Emacs version that doesn't support
'keymap-set').

    > - You should probably format the reference to the manual in your
    > commentary section as described in the Info node (elisp)
    > Documentation Tips.

Fixed, thanks.

    > Have you made up your mind about the name, or could you be
    > convinced to change it to something like "window-switch" or
    > "windswitch" (so that it sounds similar to windmove)?  Just
    > suggestions of course, I just anticipate a discussion on this
    > question, because the name itself is not that expressive.

I wouldn't mind changing the name (I agree it's not very good), however
I would have to change this name in quite a few places.
OTOH, with 'list-packages' showing a brief description of each package,
I'm not sure if I see a big benefit to changing the name.  I'll have to
think about it.

    >> Both packages include Texinfo manuals (from which the manuals on
    >> their homepages is generated).  Please let me know beforehand if
    >> there is intention to add either package to NonGNU ELPA, so I
    >> could update their manuals and add '.elpaignore' files to their
    >> repositories.

    > I don't see why not.

Those changes have now been made for both packages.

    >> PS: I initially intended to submit these packages to GNU ELPA,
    >> but unfortunately I probably won't be able to assign copyright
    >> any time soon. (I'm assuming it would be possible to move them to
    >> GNU ELPA in the future?)

    > It should be possible.

Great!

BTW, when the packages are first imported, would the latest commit be
used, or should I bump the version (after I make all relevant changes)?

Re: [NonGNU ELPA] New packages: Vcomplete, swsw

[Philip Kaludercic]

Daniel Semyonov <daniel@dsemy.com> writes:

>>>>>> Philip Kaludercic writes:
>
>     > - You add vcomplete-embark.el, that seems to be a package in it's
>     > own right (with a dependency on embark), but with your patch this
>     > will just be bundled into the same package.  Is this intentional?
>
> Semi-intentional... now that you mention it, is it possible for two
> (related) packages to share the same git repository? If so,
> vcomplete-embark should be its own package.

It is, though not advised if not necessary (it works by excluding all
the files from package B in the specification for package A, and vice
versa).  A slightly more elegant approach is to use separate, detached
branches but at that point you effectively have two repositories anyway
(that you can associate as part of the same project on SourceHut).

> In any case, I haven't tested this integration in a while, so I think it
> would make more sense to completely exclude 'vcomplete-embark.el' for
> now (this integration broke in the past due to changes to Embark and
> Vcomplete, and might be broken in some way now as I don't currently use
> Embark).  I'll do some testing in the next few days.

In that case I'd advise just adding it to a .elpaignore so that you
don't have to change the package specification upstream.

>     > - Could the vector key syntax ([?\C-a]) be replaced with a (kbd
>     > "C-a")?  I think the general trend nowadays is towards the latter,
>     > and more people are familiar with it.
>
> Now that you mention it, since it's just an example, wouldn't it make
> more sense to use 'keymap-set' for it? (Although technically both
> packages could be used with an Emacs version that doesn't support
> 'keymap-set').

I wouldn't, as your package-dependency specification indicates that the
minimal version is 25.1, and no release of Emacs has been made with the
new keymap functions/macros.  It is easy for enthusiasts to forget that
most people are not tracking the master branch.

>     > Have you made up your mind about the name, or could you be
>     > convinced to change it to something like "window-switch" or
>     > "windswitch" (so that it sounds similar to windmove)?  Just
>     > suggestions of course, I just anticipate a discussion on this
>     > question, because the name itself is not that expressive.
>
> I wouldn't mind changing the name (I agree it's not very good), however
> I would have to change this name in quite a few places.
> OTOH, with 'list-packages' showing a brief description of each package,
> I'm not sure if I see a big benefit to changing the name.  I'll have to
> think about it.

Ok, no problem.  As I said it is just a suggestion, perhaps someone else
has a better idea that might make the change worth the effort.

>     >> PS: I initially intended to submit these packages to GNU ELPA,
>     >> but unfortunately I probably won't be able to assign copyright
>     >> any time soon. (I'm assuming it would be possible to move them to
>     >> GNU ELPA in the future?)
>
>     > It should be possible.
>
> Great!
>
> BTW, when the packages are first imported, would the latest commit be
> used, or should I bump the version (after I make all relevant changes)?

No, the last commit that bumps the version tag is always the one used.
I can push the specifications, though I will wait for a bit to see if
anyone wants to comment on anything discussed here.

Re: [NonGNU ELPA] New packages: Vcomplete, swsw

[Stefan Monnier]

> Semi-intentional... now that you mention it, is it possible for two
> (related) packages to share the same git repository?

Kind of, when really necessary, but with various caveats.
I think you'd be better off with a single package that just happens to
collaborate with Embark when Embark is used (i.e. without an explicit
dependency on Embark, which also means it should not require Embark to
compile vcomplete-embark), or else to move it to a separate repository.

> Since both packages are complex (as in, they contain multiple files),
> when I generate my own package tar (for distribution on my site for
> example, as the packages weren't available on any archive before), it
> needs to contain a <package>-pkg.el file for Emacs to install it (or at
> least that's what I remember from testing I did long ago).

Yes, but that doesn't mean it should be in the Git.

> I will admit this file should just be generated automatically during the
> build process in this case too, I just never got around to implementing
> that.

You don't need to.  The elpa.gnu.org scripts do that for you (and they
even sometimes trip over themselves when there's a competing
<foo>-pkg.el in the Git).

> BTW, when the packages are first imported, would the latest commit be
> used,

No: we ask Git when's the last commit that touched `Version:`.


        Stefan

Re: [NonGNU ELPA] New packages: Vcomplete, swsw

[Daniel Semyonov]

>>>>> Philip Kaludercic writes:

    >> In any case, I haven't tested this integration in a while, so I
    >> think it would make more sense to completely exclude
    >> 'vcomplete-embark.el' for now (this integration broke in the past
    >> due to changes to Embark and Vcomplete, and might be broken in
    >> some way now as I don't currently use Embark).  I'll do some
    >> testing in the next few days.

    > In that case I'd advise just adding it to a .elpaignore so that
    > you don't have to change the package specification upstream.

I've done some basic testing and it seems that Embark had changed pretty
drastically, and I would have to make significant changes to make this
integration work with the current version.
Since I'm not using Embark anymore, I've decided to remove this
completely.

    >>> - Could the vector key syntax ([?\C-a]) be replaced with a (kbd
    >>> "C-a")?  I think the general trend nowadays is towards the
    >>> latter, and more people are familiar with it.
    >> 
    >> Now that you mention it, since it's just an example, wouldn't it
    >> make more sense to use 'keymap-set' for it? (Although technically
    >> both packages could be used with an Emacs version that doesn't
    >> support 'keymap-set').

    > I wouldn't, as your package-dependency specification indicates
    > that the minimal version is 25.1, and no release of Emacs has been
    > made with the new keymap functions/macros.  It is easy for
    > enthusiasts to forget that most people are not tracking the master
    > branch.

Oh, I incorrectly remembered that 'keymap-set' and friends were included
in Emacs 28.1.  In any case, I updated the commentary of both packages
to use 'kbd' instead of the vector key syntax.

    > No, the last commit that bumps the version tag is always the one
    > used.  I can push the specifications, though I will wait for a bit
    > to see if anyone wants to comment on anything discussed here.

I bumped the version for both packages now, so they should be
completely ready for inclusion I think.

Thanks,
Daniel

Re: [NonGNU ELPA] New packages: Vcomplete, swsw

[Daniel Semyonov]

>>>>> Stefan Monnier writes:

    >> Semi-intentional... now that you mention it, is it possible for
    >> two (related) packages to share the same git repository?

    > Kind of, when really necessary, but with various caveats.  I think
    > you'd be better off with a single package that just happens to
    > collaborate with Embark when Embark is used (i.e. without an
    > explicit dependency on Embark, which also means it should not
    > require Embark to compile vcomplete-embark), or else to move it to
    > a separate repository.

I have decided to remove this file completely as it broke at some point
due to an update to Embark (in a non-trivial way it seems), and I'm no
longer an Embark user so it will be hard to keep up with breakage in the
future, too.

    >> I will admit this file should just be generated automatically
    >> during the build process in this case too, I just never got
    >> around to implementing that.

    > You don't need to.  The elpa.gnu.org scripts do that for you (and
    > they even sometimes trip over themselves when there's a competing
    > <foo>-pkg.el in the Git).

I do need to do this if I want to create a package archive automatically
outside of an ELPA.  For example, both of my packages contain a
.build.yml file in their repository, which causes the SourceHut build
system (at builds.sr.ht) to create a package archive for every commit
(see https://builds.sr.ht/~dsemy/vcomplete).
In any case, I implemented a simple generator using sed and removed the
<package>-pkg.el files from both repositories.

Regards,
Daniel

Re: [NonGNU ELPA] New packages: Vcomplete, swsw

[Philip Kaludercic]

Daniel Semyonov <daniel@dsemy.com> writes:

>     > Have you made up your mind about the name, or could you be
>     > convinced to change it to something like "window-switch" or
>     > "windswitch" (so that it sounds similar to windmove)?  Just
>     > suggestions of course, I just anticipate a discussion on this
>     > question, because the name itself is not that expressive.
>
> I wouldn't mind changing the name (I agree it's not very good), however
> I would have to change this name in quite a few places.
> OTOH, with 'list-packages' showing a brief description of each package,
> I'm not sure if I see a big benefit to changing the name.  I'll have to
> think about it.

I've pushed vcomplete, but just wanted to check if you made up your mind
on the name for swsw.  Should we keep it or do you want to use the
chance to change it now?

Re: [NonGNU ELPA] New packages: Vcomplete, swsw

[Daniel Semyonov]

>>>>> Philip Kaludercic writes:

    > I've pushed vcomplete, but just wanted to check if you made up
    > your mind on the name for swsw.  Should we keep it or do you want
    > to use the chance to change it now?

I haven't thought of a name I really like yet, so I'd prefer not to
change it.  Also, swsw has existed for close to two years at this point,
and I have no idea how many users it has which might be affected by a
name change.

Re: [NonGNU ELPA] New packages: Vcomplete, swsw

[Philip Kaludercic]

Daniel Semyonov <daniel@dsemy.com> writes:

>>>>>> Philip Kaludercic writes:
>
>     > I've pushed vcomplete, but just wanted to check if you made up
>     > your mind on the name for swsw.  Should we keep it or do you want
>     > to use the chance to change it now?
>
> I haven't thought of a name I really like yet, so I'd prefer not to
> change it.  

Ok, I've added it.

>             Also, swsw has existed for close to two years at this point,
> and I have no idea how many users it has which might be affected by a
> name change.

I don't think this would have been that critical of an issue, as most of
your users probably did not install it using package.el?

Re: [NonGNU ELPA] New packages: Vcomplete, swsw

[Daniel Semyonov]

>>>>> Philip Kaludercic writes:

    > Ok, I've added it.

Thanks.

    >> Also, swsw has existed for close to two years at this point, and
    >> I have no idea how many users it has which might be affected by a
    >> name change.

    > I don't think this would have been that critical of an issue, as
    > most of your users probably did not install it using package.el?

There are download links for both packages (archives install-able with
'package-install-file') on their homepages, and the install instructions
in the Git README and manual have explained how to build/download a
package archive and install it for a long time (mostly so people
installing from the repository also get the manual).  Not saying this
necessarily affected the amount of users doing that, but I'd prefer not
to inconvenience users who installed it in the documented way.