From: Dmitry Gutov <dgutov@yandex.ru>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 41821@debbugs.gnu.org, juri@linkov.net
Subject: bug#41821: 28.0.50; read-directory-name in vc commands should provide defaults from projects
Date: Thu, 25 Jun 2020 16:50:24 +0300 [thread overview]
Message-ID: <14381b78-ab1c-91e0-2297-426620b19684@yandex.ru> (raw)
In-Reply-To: <83tuyzs2np.fsf@gnu.org>
On 25.06.2020 16:20, Eli Zaretskii wrote:
>> I mean, I'm not going to protest against an
>> extra wrapper, but that doesn't sound like it would solve any practical
>> problems. "Cleaner" solutions often have those.
>
> In general, code that doesn't _have_ to be preloaded, shouldn't be.
> If nothing else, it keeps the memory footprint of a bare Emacs
> smaller, and thus prevents us from slipping down the slippery slope of
> memory bloat.
And having vc-hooks call project.el functions at runtime would somehow
force us to preload it? How?
>>> Actually, I have a question: isn't project.el conceptually a
>>> higher-level feature than VC? If so, how come VC wants to call
>>> project.el?
>>
>> VC doesn't serve project.el only. project.el doesn't solely use VC.
>
> Yes, but that's not what I asked. I have the impression that
> project.el builds on VC as one project back-end, so it sounds strange
> to me that VC turns around and calls project.el for something.
Considering one doesn't exclusively serve the other, I wouldn't say
there is a strict hierarchy.
To be more accurate, we're actually talking about different parts of VC
and project.el (the UI and infrastructure parts), which have different
relations.
>> Apparently Juri wants to use certain data collected and saved by
>> project.el UI, for convenience.
>
> After reading the original complaint that Juri says he wanted to
> resolve, I still don't understand why we use project.el for that. No
> one says that every relevant VC repository must have been visited as a
> project as part of the current Emacs session. Why not have some
> relevant history in VC itself?
I would be totally fine with that solution as well.
>> The alternative would be to introduce some separate history-keeping
>> feature for the cases when VC code needs to ask the user to point to a
>> VC repository.
>
> Exactly. Why not?
The downside, of course, is having the user input the same thing
multiple times sometimes. And some extra code.
Overall, both seem minor (and the inconvenience is going to be infrequent).
> And if the history is collected by VC, it could be made available to
> project.el commands that call into VC, right?
But we want to store history on all projects, not just VC based ones.
> Anyway, if you-two feel strongly about keeping the current solution,
> i.e. having VC commands use project.el-collected history, I'd
> appreciate if that function could be moved to vc.el from vc-hooks.el,
> thanks in advance.
We can't just move it: it accesses information private to project.el.
The best we could do is a wrapper function.
next prev parent reply other threads:[~2020-06-25 13:50 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-11 23:03 bug#41821: 28.0.50; read-directory-name in vc commands should provide defaults from projects Juri Linkov
2020-06-12 13:43 ` Dmitry Gutov
2020-06-18 23:28 ` Juri Linkov
2020-06-20 1:35 ` Dmitry Gutov
2020-06-20 23:51 ` Juri Linkov
2020-06-21 0:12 ` Dmitry Gutov
2020-06-21 22:49 ` Juri Linkov
2020-06-22 0:08 ` Dmitry Gutov
2020-06-22 23:45 ` Juri Linkov
2020-06-23 0:37 ` Dmitry Gutov
2020-06-23 23:59 ` Juri Linkov
2020-06-24 14:39 ` Eli Zaretskii
2020-06-24 14:52 ` Basil L. Contovounesios
2020-06-24 15:16 ` Eli Zaretskii
2020-06-24 15:10 ` Dmitry Gutov
2020-06-24 15:18 ` Eli Zaretskii
2020-06-24 15:42 ` Eli Zaretskii
2020-06-24 18:13 ` Dmitry Gutov
2020-06-24 18:29 ` Eli Zaretskii
2020-06-24 18:44 ` Dmitry Gutov
2020-06-24 23:25 ` Juri Linkov
2020-06-25 11:19 ` Dmitry Gutov
2020-06-25 13:20 ` Eli Zaretskii
2020-06-25 13:50 ` Dmitry Gutov [this message]
2020-06-25 16:31 ` Eli Zaretskii
2020-06-25 16:45 ` Dmitry Gutov
2020-06-25 17:09 ` Eli Zaretskii
2020-06-25 17:19 ` Dmitry Gutov
2020-06-25 17:45 ` Eli Zaretskii
2020-06-25 17:50 ` Dmitry Gutov
2020-06-25 18:03 ` Eli Zaretskii
2020-06-25 18:13 ` Dmitry Gutov
2020-06-25 18:29 ` Eli Zaretskii
2020-06-27 23:51 ` Juri Linkov
2020-06-28 14:33 ` Eli Zaretskii
2020-06-28 21:55 ` Juri Linkov
2020-06-28 21:51 ` Juri Linkov
2020-06-28 22:37 ` Dmitry Gutov
2020-06-29 22:58 ` Juri Linkov
2020-06-30 12:36 ` Dmitry Gutov
2020-06-30 20:50 ` Juri Linkov
2020-06-30 21:59 ` Dmitry Gutov
2020-07-01 14:42 ` Eli Zaretskii
2020-07-01 20:24 ` Dmitry Gutov
2020-07-02 13:36 ` Eli Zaretskii
2020-07-02 14:43 ` Dmitry Gutov
2020-07-02 17:41 ` Eli Zaretskii
2020-07-02 19:37 ` Dmitry Gutov
2020-07-03 5:55 ` Eli Zaretskii
2020-07-03 10:23 ` Dmitry Gutov
2020-07-03 11:48 ` Eli Zaretskii
2020-07-03 13:13 ` Dmitry Gutov
2020-07-01 22:10 ` Juri Linkov
2020-07-02 14:39 ` Dmitry Gutov
2020-06-24 23:22 ` Juri Linkov
2020-06-24 18:29 ` Dmitry Gutov
2020-06-27 23:44 ` Juri Linkov
2020-06-28 0:19 ` Dmitry Gutov
2020-06-28 21:49 ` Juri Linkov
2020-06-28 22:42 ` Dmitry Gutov
[not found] <<87r1ulxk48.fsf@mail.linkov.net>
[not found] ` <<ed4d76c6-3ef2-cf0b-5f8b-3b3bd61bdee5@yandex.ru>
[not found] ` <<87366ohw5z.fsf@mail.linkov.net>
[not found] ` <<c9db50b6-fa5a-aa0b-076b-0fbcbcdec7b4@yandex.ru>
[not found] ` <<878sge7jls.fsf@mail.linkov.net>
[not found] ` <<7e136435-7123-fa42-e4a8-66b82e6595da@yandex.ru>
[not found] ` <<87pn9pxris.fsf@mail.linkov.net>
[not found] ` <<83d05ottnw.fsf@gnu.org>
[not found] ` <<0b42f540-f779-446b-4411-8dae3a50d09d@yandex.ru>
[not found] ` <<837dvwtrv1.fsf@gnu.org>
[not found] ` <<835zbgtqps.fsf@gnu.org>
[not found] ` <<625de669-0715-1467-0bd1-84328b4bee5f@yandex.ru>
[not found] ` <<83wo3ws4g8.fsf@gnu.org>
[not found] ` <<f9cd868b-ca2f-bb8e-9b48-af37cc215855@yandex.ru>
[not found] ` <<83tuyzs2np.fsf@gnu.org>
[not found] ` <<87h7uuj1v3.fsf@mail.linkov.net>
[not found] ` <<d93d0f5a-7067-de6a-c2f5-c263864c479e@yandex.ru>
[not found] ` <<87h7utjx75.fsf@mail.linkov.net>
[not found] ` <<3f9e85ba-66a9-abd0-61bf-800ea8bb4ee3@yandex.ru>
[not found] ` <<87eepw5nlt.fsf@mail.linkov.net>
[not found] ` <<faccdab8-153d-b31c-4be6-81bb924a200b@yandex.ru>
[not found] ` <<83v9j7xpoj.fsf@gnu.org>
[not found] ` <<990a9046-c4e6-efb2-01dd-60198994127b@yandex.ru>
[not found] ` <<831rluxcll.fsf@gnu.org>
[not found] ` <<c75015c8-9291-6a70-df7a-a02c112b5973@yandex.ru>
[not found] ` <<83r1ttx196.fsf@gnu.org>
[not found] ` <<9c09977f-18c2-facd-c1e2-e7fe488ee92c@yandex.ru>
[not found] ` <<83eeptw3a9.fsf@gnu.org>
2020-07-03 16:05 ` Drew Adams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=14381b78-ab1c-91e0-2297-426620b19684@yandex.ru \
--to=dgutov@yandex.ru \
--cc=41821@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=juri@linkov.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).