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

[Philip Kaludercic <philipk@posteo.net>]

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.