From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs 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 Message-ID: <14381b78-ab1c-91e0-2297-426620b19684@yandex.ru> References: <87r1ulxk48.fsf@mail.linkov.net> <7164426e-8c37-8839-64da-563cfa829b53@yandex.ru> <87mu50j5cu.fsf@mail.linkov.net> <87y2oh8fdv.fsf@mail.linkov.net> <87366ohw5z.fsf@mail.linkov.net> <878sge7jls.fsf@mail.linkov.net> <7e136435-7123-fa42-e4a8-66b82e6595da@yandex.ru> <87pn9pxris.fsf@mail.linkov.net> <83d05ottnw.fsf@gnu.org> <0b42f540-f779-446b-4411-8dae3a50d09d@yandex.ru> <837dvwtrv1.fsf@gnu.org> <835zbgtqps.fsf@gnu.org> <625de669-0715-1467-0bd1-84328b4bee5f@yandex.ru> <83wo3ws4g8.fsf@gnu.org> <83tuyzs2np.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="67019"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 Cc: 41821@debbugs.gnu.org, juri@linkov.net To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jun 25 15:51:12 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1joSHW-000HHR-VE for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 25 Jun 2020 15:51:11 +0200 Original-Received: from localhost ([::1]:45312 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1joSHW-0006S8-1C for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 25 Jun 2020 09:51:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39546) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1joSHO-0006Pa-AB for bug-gnu-emacs@gnu.org; Thu, 25 Jun 2020 09:51:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:56639) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1joSHO-0005ia-0W for bug-gnu-emacs@gnu.org; Thu, 25 Jun 2020 09:51:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1joSHN-0005Mw-T7 for bug-gnu-emacs@gnu.org; Thu, 25 Jun 2020 09:51:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 25 Jun 2020 13:51:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 41821 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: fixed Original-Received: via spool by 41821-submit@debbugs.gnu.org id=B41821.159309303720605 (code B ref 41821); Thu, 25 Jun 2020 13:51:01 +0000 Original-Received: (at 41821) by debbugs.gnu.org; 25 Jun 2020 13:50:37 +0000 Original-Received: from localhost ([127.0.0.1]:39952 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1joSGz-0005MH-CR for submit@debbugs.gnu.org; Thu, 25 Jun 2020 09:50:37 -0400 Original-Received: from mail-ej1-f42.google.com ([209.85.218.42]:45595) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1joSGv-0005Lz-JD for 41821@debbugs.gnu.org; Thu, 25 Jun 2020 09:50:36 -0400 Original-Received: by mail-ej1-f42.google.com with SMTP id a1so5977876ejg.12 for <41821@debbugs.gnu.org>; Thu, 25 Jun 2020 06:50:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=ml9GdNN+D7krosnnD5eKoccQYezbm2e0mujQxjLfjmM=; b=UmsJcM6DA7oUQ0UHwGrCcPIoX83ay95Z0DU7G/i3ztwWflq/BEvD/3JhGQCUm5cHVW rUwfs6PeV9fcZWTJbm2h3cF2r1Dy2iO8AE6aK0QLncs2TTdRAYUipp+qyaBZQ2yIP2yj oblX459+Q9r3eM90HTHiOf4WMo2eFwQyf3qEaa42+U1BYrb6UI775wo06mtN/ZJjpop5 m0uPVGZUgFoZCgIaUY2Ucg04TNbtH/33Dv05PT0E+F0f5cw88dmC3L3QPAl1FLrxySXZ 9wED88m6Fp3lsRN4D0ymhDFJrRTDf3Qf7VEwgfLI7GET0BZLQp79mcCOB68k+soI4Mgb mwhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ml9GdNN+D7krosnnD5eKoccQYezbm2e0mujQxjLfjmM=; b=FiQL0NZV7FTwadeWXxDa9nAg7eYdtacjtmJzEzMhRqPGBa05+bCAGYMWA+yVw8TpI8 toqg+d9KBjtkZ+7/7WZSQsrxhiGyF1hXR/At3IaqJc6fehwZH7y/f2aaCcK4oWDd+07A ID0jBVLUJoHBvzopuSREjUKjNJfYma9F4lv0SEbeHu90uD6WFHCVvWQ9B5R0laYvQuQZ 2xa5NeN987x3JO5tuICBch9bHDxxHffEKuBhaw1iOnuSE64HcTx5uvfvG7gA2ZETYvZa tOfoNWCZUz8l4GXX0GFqjtHosvtowCftrheTOI/dFtGm4nLBK+5JuRqj8rWLDLjLnUC+ tBtA== X-Gm-Message-State: AOAM530eBzqQcrKOhs5DcRsNm3hvqFcwiV5oPa6fxuO5nAPHEGE8cPOM vhZ6aYgrFFJulpnJSFgIdGA= X-Google-Smtp-Source: ABdhPJwWYfawpz7MuwFVlMSnd1BDGcXliBa6twu45ZYbopT/DCwnBAo6GLI8oRTJ0cVY5wtXcbQzQA== X-Received: by 2002:a17:906:1357:: with SMTP id x23mr17987327ejb.148.1593093027644; Thu, 25 Jun 2020 06:50:27 -0700 (PDT) Original-Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id t5sm18480474eds.81.2020.06.25.06.50.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 25 Jun 2020 06:50:26 -0700 (PDT) In-Reply-To: <83tuyzs2np.fsf@gnu.org> Content-Language: en-US X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:182368 Archived-At: 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.