Re: [NonGNU ELPA] New package: tabspaces

(I've added emacs-devel back to the CC's so others can follow along)

Colin McLear <[email protected]> writes:

> Hi Philip,
>
> Thanks so much for the careful review and quick reply. Your
> suggestions were very helpful and taught me a few things.
> I've applied nearly all of it, pushed as commit 221484c on the
> Codeberg repo:

[... you don't have to repeat everything I wrote ;)]

Out of curiosity, since I don't know much about this, your commit
message ends with

  Claude-Session: https://claude.ai/code/session_019AtEULWCQRLrDCkm7p8KyU

but the link doesn't give me anything when I open it.  Is this supposed
to be a public URL?  (Also, your usage of AI precludes the package from
being added to GNU ELPA for now, so I'll regard that as a suitable
explanation for choice of NonGNU ELPA over GNU ELPA.)

>
> Your questions:
>
> Autoloaded internal functions: no good reason, just leftovers. The
> cookies are removed.
>
> tab-bar-tabs vs. the variable: good eye, though I harmonized in
> the other direction. tab-bar-tabs is the default value of
> tab-bar-tabs-function and reads the frame parameter directly, so
> calling it would bypass a customized provider.
> tabspaces--list-tabspaces now goes through the variable, and the
> places you flagged call it.
>
> Project-name uniqueness: basename collisions are real. The main
> entry point (tabspaces-open-or-create-project-and-workspace)
> resolves them by renaming the colliding tab to a "name (parent/dir)"
> form and tracking paths in tabspaces-project-tab-map. In the
> tab-bar-tab-name-function path a duplicate name is cosmetic only;
> nothing keys off it.

OK, that sounds good.

> I didn't take two of your suggestions; here is my reasoning:
>
> key-sequence: the option's value is a kbd-syntax string handed to kbd
> when the keymap is built. The key-sequence widget's external value is
> the raw key sequence, so the current default and existing user
> settings
> like "C-c TAB" would be misread as literal characters. When the
> package
> can require Emacs 28+ I'll switch to the `key' type, whose value stays
> a
> kbd-format string. Alternatively, I could drop Emacs 27 now, though
> I'm
> not sure if that would leave any significant user base out in the
> cold.
> It might make sense though. Correct me if I'm wrong, but NonGNU ELPA
> ships with Emacs 28.1 and later, so every user who installs tabspaces
> from the archive is on 28+ by definition. The only people a bump to
> 28.1
> could strand are MELPA users still on 27, and Emacs 28.1 is over four
> years old at this point. So maybe it is time. Let me know what you
> think.

Ah, my bad.  But in that case, why not just change the user option to be
an actual key binding, ie. the default value is (kbd "C-c TAB"), instead
of a string that denotes a binding?

> file-equal-p: pr-dir is compared against the sentinel completion
> entry "... (choose a dir)" rather than a file name, so equal is the
> right test here (this mirrors project-prompt-project-dir in
> project.el).

OK, I missed that context.  Adding a comment might help other readers in
the future from making that mistake.

> As for GNU ELPA: My thinking was that the package has accumulated over
> a
> dozen outside contributors and I haven't collected FSF copyright
> assignments from them, so GNU ELPA isn't an option without tracking
> all
> of them down, which I (perhaps lazily) don't particulary want to spend
> the time doing. I'm open to an alternative view, however, so please do
> let me know if you think otherwise.

That is also a fair explanation.  I just want to make sure it was not
dismissed a-priori as there are some people who either assume that it is
not possible to have a package added to ELPA without a certain
reputation or think that they cannot maintain the package on their own
as soon as it has been added to ELPA, none of which is true.

> Thanks again,
> Colin