Re: [NonGNU ELPA] New package: tabspaces
Stéphane Marks <[email protected]> Sat, 1 Aug 2026 16:23:32 +0200
| Newsgroups | gmane.emacs.devel |
|---|---|
| Message-ID | <CAN+1Hbqp-d7gFE67wxLpiiBJJJtdvdiAgK-dY4UOvLwp74u8_w@mail.gmail.com> |
--0000000000006b6a370657fd0d47 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Aug 1, 2026 at 10:00=E2=80=AFAM Philip Kaludercic <[email protected]= et> wrote: > (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. > To the degree LLMs were used, assignment of unassignable uncopyrightable assets to the FSF is likely not possible. There are 9 commits with references to Claude sessions, so keep this in mind. --0000000000006b6a370657fd0d47 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon= t-family:monospace"><span style=3D"font-family:Arial,Helvetica,sans-serif;b= ackground-color:transparent">On Sat, Aug 1, 2026 at 10:00=E2=80=AFAM Philip= Kaludercic <<a href=3D"mailto:[email protected]">[email protected]</a= >> wrote:</span></div></div><div class=3D"gmail_quote gmail_quote_contai= ner"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo= rder-left:1px solid rgb(204,204,204);padding-left:1ex">(I've added emac= s-devel back to the CC's so others can follow along)<br> <br> Colin McLear <<a href=3D"mailto:[email protected]" target=3D"_blank">m= [email protected]</a>> writes:<br> <br> > Hi Philip,<br> ><br> > Thanks so much for the careful review and quick reply. Your<br> > suggestions were very helpful and taught me a few things.<br> > I've applied nearly all of it, pushed as commit 221484c on the<br> > Codeberg repo:<br> <br> [... you don't have to repeat everything I wrote ;)]<br> <br> Out of curiosity, since I don't know much about this, your commit<br> message ends with<br> <br> =C2=A0 Claude-Session: <a href=3D"https://claude.ai/code/session_019AtEULWC= QRLrDCkm7p8KyU" rel=3D"noreferrer" target=3D"_blank">https://claude.ai/code= /session_019AtEULWCQRLrDCkm7p8KyU</a><br> <br> but the link doesn't give me anything when I open it.=C2=A0 Is this sup= posed<br> to be a public URL?=C2=A0 (Also, your usage of AI precludes the package fro= m<br> being added to GNU ELPA for now, so I'll regard that as a suitable<br> explanation for choice of NonGNU ELPA over GNU ELPA.)<br> <br> ><br> > Your questions:<br> ><br> > Autoloaded internal functions: no good reason, just leftovers. The<br> > cookies are removed.<br> ><br> > tab-bar-tabs vs. the variable: good eye, though I harmonized in<br> > the other direction. tab-bar-tabs is the default value of<br> > tab-bar-tabs-function and reads the frame parameter directly, so<br> > calling it would bypass a customized provider.<br> > tabspaces--list-tabspaces now goes through the variable, and the<br> > places you flagged call it.<br> ><br> > Project-name uniqueness: basename collisions are real. The main<br> > entry point (tabspaces-open-or-create-project-and-workspace)<br> > resolves them by renaming the colliding tab to a "name (parent/di= r)"<br> > form and tracking paths in tabspaces-project-tab-map. In the<br> > tab-bar-tab-name-function path a duplicate name is cosmetic only;<br> > nothing keys off it.<br> <br> OK, that sounds good.<br> <br> > I didn't take two of your suggestions; here is my reasoning:<br> ><br> > key-sequence: the option's value is a kbd-syntax string handed to = kbd<br> > when the keymap is built. The key-sequence widget's external value= is<br> > the raw key sequence, so the current default and existing user<br> > settings<br> > like "C-c TAB" would be misread as literal characters. When = the<br> > package<br> > can require Emacs 28+ I'll switch to the `key' type, whose val= ue stays<br> > a<br> > kbd-format string. Alternatively, I could drop Emacs 27 now, though<br= > > I'm<br> > not sure if that would leave any significant user base out in the<br> > cold.<br> > It might make sense though. Correct me if I'm wrong, but NonGNU EL= PA<br> > ships with Emacs 28.1 and later, so every user who installs tabspaces<= br> > from the archive is on 28+ by definition. The only people a bump to<br= > > 28.1<br> > could strand are MELPA users still on 27, and Emacs 28.1 is over four<= br> > years old at this point. So maybe it is time. Let me know what you<br> > think.<br> <br> Ah, my bad.=C2=A0 But in that case, why not just change the user option to = be<br> an actual key binding, ie. the default value is (kbd "C-c TAB"), = instead<br> of a string that denotes a binding?<br> <br> > file-equal-p: pr-dir is compared against the sentinel completion<br> > entry "... (choose a dir)" rather than a file name, so equal= is the<br> > right test here (this mirrors project-prompt-project-dir in<br> > project.el).<br> <br> OK, I missed that context.=C2=A0 Adding a comment might help other readers = in<br> the future from making that mistake.<br> <br> > As for GNU ELPA: My thinking was that the package has accumulated over= <br> > a<br> > dozen outside contributors and I haven't collected FSF copyright<b= r> > assignments from them, so GNU ELPA isn't an option without trackin= g<br> > all<br> > of them down, which I (perhaps lazily) don't particulary want to s= pend<br> > the time doing. I'm open to an alternative view, however, so pleas= e do<br> > let me know if you think otherwise.<br> <br> That is also a fair explanation.=C2=A0 I just want to make sure it was not<= br> dismissed a-priori as there are some people who either assume that it is<br= > not possible to have a package added to ELPA without a certain<br> reputation or think that they cannot maintain the package on their own<br> as soon as it has been added to ELPA, none of which is true.<br></blockquot= e><div><br></div><div class=3D"gmail_default" style=3D"font-family:monospac= e">To the degree LLMs were used, assignment of unassignable uncopyrightable= assets to the FSF is likely not possible.=C2=A0 There are 9 commits with r= eferences to Claude sessions, so keep this in mind.</div></div></div> --0000000000006b6a370657fd0d47--