* bug#50499: 28.0.50; project.el: Root of current project @ 2021-09-10 5:26 Augusto Stoffel 2021-09-10 12:16 ` Dmitry Gutov 0 siblings, 1 reply; 4+ messages in thread From: Augusto Stoffel @ 2021-09-10 5:26 UTC (permalink / raw) To: 50499 I guess most uses of `project-root' will be of the form (when-let ((p (project-current))) (project-root p)) Or at least this is true in the case of an user who is quickly defining a shortcut command in their config. Wouldn't it make sense to make the PROJECT argument of `project-root' optional, giving the above result when omitted? ^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#50499: 28.0.50; project.el: Root of current project 2021-09-10 5:26 bug#50499: 28.0.50; project.el: Root of current project Augusto Stoffel @ 2021-09-10 12:16 ` Dmitry Gutov 2021-09-10 16:08 ` Augusto Stoffel 0 siblings, 1 reply; 4+ messages in thread From: Dmitry Gutov @ 2021-09-10 12:16 UTC (permalink / raw) To: Augusto Stoffel, 50499 On 10.09.2021 08:26, Augusto Stoffel wrote: > I guess most uses of `project-root' will be of the form > > (when-let ((p (project-current))) > (project-root p)) > > Or at least this is true in the case of an user who is quickly defining > a shortcut command in their config. > > Wouldn't it make sense to make the PROJECT argument of `project-root' > optional, giving the above result when omitted? Given the way it this works, it would need to be a helper function. IIUC cl-defmethod does not support default values for arguments, and if it did, we'd have to have an implementation of project-root, etc, for nil argument. Which is a bad idea because someone else might not want to simply do nothing when there is no project found, and our type system would then fail to help them notice that. I don't mind adding said helper (naming suggestions welcome), but the way things work now seems fine to me already. Either you have: (project-root (project-current t)) where there is no risk of returning nil, and thus no need for when-let, or you call (project-current) first, check it for nil, and then _probably_ use some other fallbacks. If you don't have fallbacks, then the other approach seems better, no? ^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#50499: 28.0.50; project.el: Root of current project 2021-09-10 12:16 ` Dmitry Gutov @ 2021-09-10 16:08 ` Augusto Stoffel 2022-08-25 14:43 ` Lars Ingebrigtsen 0 siblings, 1 reply; 4+ messages in thread From: Augusto Stoffel @ 2021-09-10 16:08 UTC (permalink / raw) To: Dmitry Gutov; +Cc: 50499 On Fri, 10 Sep 2021 at 15:16, Dmitry Gutov <dgutov@yandex.ru> wrote: > On 10.09.2021 08:26, Augusto Stoffel wrote: >> I guess most uses of `project-root' will be of the form >> (when-let ((p (project-current))) >> (project-root p)) >> Or at least this is true in the case of an user who is quickly >> defining >> a shortcut command in their config. >> Wouldn't it make sense to make the PROJECT argument of >> `project-root' >> optional, giving the above result when omitted? > > Given the way it this works, it would need to be a helper function. Okay, introducing a new name is probably not worth the trouble for such a small benefit. Only if it was possible/easy to overload the existing function (and make it analogous the typical “&optional BUFFER” kind of argument) would there be a gain in it, I think. > > IIUC cl-defmethod does not support default values for arguments, and > if it did, we'd have to have an implementation of project-root, etc, > for nil argument. Which is a bad idea because someone else might not > want to simply do nothing when there is no project found, and our type > system would then fail to help them notice that. > > I don't mind adding said helper (naming suggestions welcome), but the > way things work now seems fine to me already. Either you have: > > (project-root (project-current t)) > > where there is no risk of returning nil, and thus no need for when-let, > or you call (project-current) first, check it for nil, and then > _probably_ use some other fallbacks. If you don't have fallbacks, then > the other approach seems better, no? ^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#50499: 28.0.50; project.el: Root of current project 2021-09-10 16:08 ` Augusto Stoffel @ 2022-08-25 14:43 ` Lars Ingebrigtsen 0 siblings, 0 replies; 4+ messages in thread From: Lars Ingebrigtsen @ 2022-08-25 14:43 UTC (permalink / raw) To: Augusto Stoffel; +Cc: 50499, Dmitry Gutov Augusto Stoffel <arstoffel@gmail.com> writes: > Okay, introducing a new name is probably not worth the trouble for such > a small benefit. Only if it was possible/easy to overload the existing > function (and make it analogous the typical “&optional BUFFER” kind of > argument) would there be a gain in it, I think. (I'm going through old bug reports that unfortunately weren't resolved at the time.) If I understand correctly, the conclusion here was that we don't want to do this, so I'm closing this bug report. If I misunderstood, please respond to the debbugs address and we'll reopen. ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2022-08-25 14:43 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-09-10 5:26 bug#50499: 28.0.50; project.el: Root of current project Augusto Stoffel 2021-09-10 12:16 ` Dmitry Gutov 2021-09-10 16:08 ` Augusto Stoffel 2022-08-25 14:43 ` Lars Ingebrigtsen
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).