GNU bug report logs -
#12492
24.2.50; Open vc-dir buffer easier and faster
Previous Next
Reported by: Dmitry Gutov <dgutov <at> yandex.ru>
Date: Sat, 22 Sep 2012 23:06:01 UTC
Severity: wishlist
Tags: patch
Found in version 24.2.50
Done: Dmitry Gutov <dgutov <at> yandex.ru>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 12492 in the body.
You can then email your comments to 12492 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Sat, 22 Sep 2012 23:06:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Dmitry Gutov <dgutov <at> yandex.ru>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Sat, 22 Sep 2012 23:06:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Tags: patch
Two changes:
1) All version controlled buffers have after-save-hook set up to call
vc-dir-resynch-file. So if we're just bringing up a buried vc-dir
buffer, we (almost?) never need to refresh it. This cuts about 1 second
or more on my machine, depending on the backend.
2) For almost all backends we can easily deduce the repository root
directory (exceptions: cvs, rcs, sccs), and I believe that in almost all
cases the user wants to see the status of this directory, not of some
subdirectory or any directory unrelated to the current buffer.
Hence the function vc-root-dir, which I think should be bound to 'C-x v
d' and the respective menu item.
In the rare case when the user need to do something unusual, they can do
M-x vc-dir.
When the backend doesn't have the function vc-xx-root, vc-root-dir
interactively delegates to vc-dir, so for CVS, for example, the behavior
will not change.
[vc-dir.diff (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Sat, 22 Sep 2012 23:34:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 12492 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Same patch, with ChangeLog entries.
[vc-dir.diff (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Sun, 23 Sep 2012 07:04:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 12492 <at> debbugs.gnu.org (full text, mbox):
I don't agree with either point. This should be optional with the
current behaviour left as the default.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Sun, 23 Sep 2012 08:41:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 12492 <at> debbugs.gnu.org (full text, mbox):
On 23.09.2012 11:01, Andreas Schwab wrote:
> I don't agree with either point. This should be optional with the
> current behaviour left as the default.
Do you have a counter-example for the first point? External changes made
outside Emacs? I can make a customize variable for that, I guess.
The second can be made "optional" by keeping the current keybinding.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Sun, 23 Sep 2012 08:49:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 12492 <at> debbugs.gnu.org (full text, mbox):
Dmitry Gutov <dgutov <at> yandex.ru> writes:
> On 23.09.2012 11:01, Andreas Schwab wrote:
>> I don't agree with either point. This should be optional with the
>> current behaviour left as the default.
>
> Do you have a counter-example for the first point? External changes made
> outside Emacs? I can make a customize variable for that, I guess.
Yes, that is what I was thinking of.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Sun, 23 Sep 2012 11:49:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 12492 <at> debbugs.gnu.org (full text, mbox):
On 23.09.2012 12:46, Andreas Schwab wrote:
> Dmitry Gutov <dgutov <at> yandex.ru> writes:
>
>> On 23.09.2012 11:01, Andreas Schwab wrote:
>>> I don't agree with either point. This should be optional with the
>>> current behaviour left as the default.
>>
>> Do you have a counter-example for the first point? External changes made
>> outside Emacs? I can make a customize variable for that, I guess.
>
> Yes, that is what I was thinking of.
Very well.
On the second point, do you always prefer to open vc-dir for a directory
other than repository root? Why?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Sun, 23 Sep 2012 11:57:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 12492 <at> debbugs.gnu.org (full text, mbox):
The repository root doesn't always coincide with the subsystem root.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Sun, 23 Sep 2012 12:29:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 12492 <at> debbugs.gnu.org (full text, mbox):
On 23.09.2012 15:54, Andreas Schwab wrote:
> The repository root doesn't always coincide with the subsystem root.
I see. Though personally, I'd prefer not to have uncommitted changes
outside the subsystem I'm working on. So vc-dir buffer contents would be
effectively the same either way.
My argument here is that selecting a different directory is a relatively
slow operation, and having to type 'M-x vc-dir' won't slow it down much.
If the command doesn't prompt you, though, and if point (1) is in
effect, then having a keybinding can make a bigger difference.
In addition, I can add a "pick vc directory function" variable, which
vc-root-dir will check and try to use. Better name suggestions welcome.
Before I make an updated patch, I'd like to get an opinion from VC or
Emacs maintainer.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Wed, 21 Jan 2015 20:56:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 12492 <at> debbugs.gnu.org (full text, mbox):
>>>>> Dmitry Gutov <dgutov <at> yandex.ru> writes:
[…]
> 2) For almost all backends we can easily deduce the repository root
> directory (exceptions: cvs, rcs, sccs), and I believe that in almost
> all cases the user wants to see the status of this directory, not of
> some subdirectory or any directory unrelated to the current buffer.
> Hence the function vc-root-dir, which I think should be bound to 'C-x
> v d' and the respective menu item. In the rare case when the user
> need to do something unusual, they can do M-x vc-dir.
We already have at least two pairs of commands (C-x v l vs.
C-x v L /and/ C-x v = vs. C-x v D), of which one operates on the
current file /and/ the other on the repository as a whole.
Is there any good reason we can’t have a similar arrangement for
vc-dir (C-x v d) and the proposed vc-root-dir command (say,
C-x v /, – where ‘/’ is a kind of obvious mnemonic for “root”)?
I find it way better than f302475471df, as it both keeps the
current behavior for C-x v d for those who may still want it
/and/ it offers a /prompt-free/ shortcut for those who’d always
want to use vc-dir on the root.
> When the backend doesn't have the function vc-xx-root, vc-root-dir
> interactively delegates to vc-dir, so for CVS, for example, the
> behavior will not change.
That’s certainly sensible, too.
[…]
--
FSF associate member #7257 http://boycottsystemd.org/ … 3013 B6A0 230E 334A
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Wed, 21 Jan 2015 21:56:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 12492 <at> debbugs.gnu.org (full text, mbox):
> Is there any good reason we can’t have a similar arrangement for
> vc-dir (C-x v d) and the proposed vc-root-dir command (say,
> C-x v /, – where ‘/’ is a kind of obvious mnemonic for “root”)?
If `C-x v D' were available, I guess that would be OK, but given that's
not the case, I don't think it's worth the trouble.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Thu, 22 Jan 2015 05:42:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 12492 <at> debbugs.gnu.org (full text, mbox):
>>>>> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> Is there any good reason we can’t have a similar arrangement for
>> vc-dir (C-x v d) and the proposed vc-root-dir command (say, C-x v /,
>> – where ‘/’ is a kind of obvious mnemonic for “root”)?
> If `C-x v D' were available, I guess that would be OK, but given
> that's not the case, I don't think it's worth the trouble.
Why is that a problem? Especially given that the recent
discussion seems to suggest that there’re going to be VC users
who’d stick to vc-root-dir exclusively.
--
FSF associate member #7257 http://boycottsystemd.org/ … 3013 B6A0 230E 334A
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Thu, 22 Jan 2015 17:05:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 12492 <at> debbugs.gnu.org (full text, mbox):
> Why is that a problem?
It's not a "problem", just a cost/benefit tradeoff.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Fri, 23 Jan 2015 12:14:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 12492 <at> debbugs.gnu.org (full text, mbox):
>>>>> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> Why is that a problem?
> It's not a "problem", just a cost/benefit tradeoff.
The “problem” as I see it is that we have at least two groups of
VC users, – those who’d use vc-root vc-dir buffers so often as
to make prompting an obstacle, /and/ those who’d prefer for
vc-dir to remain consistent with the likes of find-file in its
use of default-directory as, well, the default.
FTR, one another case where such an “inconsistent” behavior was
implemented at some point is desktop-read. However, this change
is easy to revert with an explicit (setq desktop-path '(".")) in
one’s ~/.emacs.
I believe it would be nice to offer the “pro-consistency” VC
users a similarly simple way to revert to the pre-f302475471df
behavior.
(Personally, I guess I’d simply revert the change locally,
should no suitable customization be implemented.)
TIA.
--
FSF associate member #7257 http://boycottsystemd.org/ … 3013 B6A0 230E 334A
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Wed, 24 Feb 2016 06:09:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 12492 <at> debbugs.gnu.org (full text, mbox):
Dmitry Gutov <dgutov <at> yandex.ru> writes:
> +;;;###autoload
> +(defun vc-root-dir ()
> + "Show the VC status of the current buffer's repository.
> +If the buffer is not visiting a version controlled file, or if
It looks to me like this was fixed in a different manner a few years
later, so I'm closing this bug report. Please reopen if it's still an
issue.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
bug closed, send any further explanations to
12492 <at> debbugs.gnu.org and Dmitry Gutov <dgutov <at> yandex.ru>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Wed, 24 Feb 2016 06:09:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Wed, 24 Feb 2016 15:00:02 GMT)
Full text and
rfc822 format available.
Message #49 received at 12492 <at> debbugs.gnu.org (full text, mbox):
Reopen!
On 02/24/2016 08:07 AM, Lars Ingebrigtsen wrote:
>> +;;;###autoload
>> +(defun vc-root-dir ()
>> + "Show the VC status of the current buffer's repository.
>> +If the buffer is not visiting a version controlled file, or if
>
> It looks to me like this was fixed in a different manner a few years
> later, so I'm closing this bug report. Please reopen if it's still an
> issue.
Not at all. The new vc-root-dir is a different beast from what I proposed.
Could you reopen it yourself? I'm writing this response from a
traditional email client.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Wed, 24 Feb 2016 23:47:01 GMT)
Full text and
rfc822 format available.
Message #52 received at 12492 <at> debbugs.gnu.org (full text, mbox):
Dmitry Gutov <dgutov <at> yandex.ru> writes:
> Could you reopen it yourself? I'm writing this response from a
> traditional email client.
I've now reopened.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Did not alter fixed versions and reopened.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Wed, 24 Feb 2016 23:47:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Thu, 27 Jun 2019 14:50:02 GMT)
Full text and
rfc822 format available.
Message #57 received at 12492 <at> debbugs.gnu.org (full text, mbox):
Dmitry Gutov <dgutov <at> yandex.ru> writes:
> +;;;###autoload
> +(defun vc-root-dir ()
> + "Show the VC status of the current buffer's repository.
> +If the buffer is not visiting a version controlled file, or if
> +the backend does not support function `root', prompt for
> +directory. See `vc-dir' for more details."
I think this sounds like a useful command -- whenever I'm not vc-dir-in
in the top level of the repo, I'm doing something wrong (and just
committing bits of the changes I meant to do).
I made my own command to do this, but I think it would be generally
useful.
[...]
> - (define-key map "d" 'vc-dir)
> + (define-key map "d" 'vc-root-dir)
But this would probably be very controversial. `C-x v /' is a nice
binding, though...
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Thu, 27 Jun 2019 22:00:02 GMT)
Full text and
rfc822 format available.
Message #60 received at 12492 <at> debbugs.gnu.org (full text, mbox):
>> +;;;###autoload
>> +(defun vc-root-dir ()
>> + "Show the VC status of the current buffer's repository.
>> +If the buffer is not visiting a version controlled file, or if
>> +the backend does not support function `root', prompt for
>> +directory. See `vc-dir' for more details."
>
> I think this sounds like a useful command -- whenever I'm not vc-dir-in
> in the top level of the repo, I'm doing something wrong (and just
> committing bits of the changes I meant to do).
>
> I made my own command to do this, but I think it would be generally
> useful.
I made my own too:
(defun vc-dir-in-project-root ()
"Run `vc-dir' in project root directory."
(interactive)
(let* ((project (project-current))
(root (and project (car (project-roots project)))))
(vc-dir (or (and root (file-directory-p root) root) default-directory))))
not sure if it should rely on `vc-root-dir' instead
(I mean the already existing function `vc-root-dir'
that returns the root dir).
>> - (define-key map "d" 'vc-dir)
>> + (define-key map "d" 'vc-root-dir)
>
> But this would probably be very controversial. `C-x v /' is a nice
> binding, though...
I'd prefer an option whose customization would allow `C-x v d'
to always use the root.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Thu, 27 Jun 2019 22:15:02 GMT)
Full text and
rfc822 format available.
Message #63 received at 12492 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> linkov.net> writes:
>>> - (define-key map "d" 'vc-dir)
>>> + (define-key map "d" 'vc-root-dir)
>>
>> But this would probably be very controversial. `C-x v /' is a nice
>> binding, though...
>
> I'd prefer an option whose customization would allow `C-x v d'
> to always use the root.
I this whether you want one or the other depends in the situation, so I
think `C-x v /' makes sense. It's as easy to type as `C-x v d' (at
least on US keyboards)...
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Fri, 28 Jun 2019 13:22:02 GMT)
Full text and
rfc822 format available.
Message #66 received at 12492 <at> debbugs.gnu.org (full text, mbox):
On 28.06.2019 0:16, Juri Linkov wrote:
> not sure if it should rely on `vc-root-dir' instead
> (I mean the already existing function `vc-root-dir'
> that returns the root dir).
I think it should (like my original patch did).
When a project contains several repository roots, you probably want to
use the closest one. Otherwise, the behavior will be the same.
>>> - (define-key map "d" 'vc-dir)
>>> + (define-key map "d" 'vc-root-dir)
>>
>> But this would probably be very controversial. `C-x v /' is a nice
>> binding, though...
>
> I'd prefer an option whose customization would allow `C-x v d'
> to always use the root.
Honestly, I think these are equivalent proposals, with the exception
that Lars' keeps the current behavior intact by default.
For those of us who want to change the behavior of 'C-x v d', we can
call define-key in the init script.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Fri, 28 Jun 2019 19:20:01 GMT)
Full text and
rfc822 format available.
Message #69 received at 12492 <at> debbugs.gnu.org (full text, mbox):
>>>> - (define-key map "d" 'vc-dir)
>>>> + (define-key map "d" 'vc-root-dir)
>>>
>>> But this would probably be very controversial. `C-x v /' is a nice
>>> binding, though...
>>
>> I'd prefer an option whose customization would allow `C-x v d'
>> to always use the root.
>
> I this whether you want one or the other depends in the situation, so I
> think `C-x v /' makes sense. It's as easy to type as `C-x v d' (at
> least on US keyboards)...
The difference in number of typed keys between the existing key sequence
and the proposed new one is just one key:
C-x v d RET (4 keys for existing)
C-x v / (3 keys for new)
But I don't oppose to the new keybinding if you get more support for it.
BTW, it also makes sense to use C-x D to open dired in the root directory
(added to ~/.emacs)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Fri, 28 Jun 2019 19:20:02 GMT)
Full text and
rfc822 format available.
Message #72 received at 12492 <at> debbugs.gnu.org (full text, mbox):
>> not sure if it should rely on `vc-root-dir' instead
>> (I mean the already existing function `vc-root-dir'
>> that returns the root dir).
>
> I think it should (like my original patch did).
>
> When a project contains several repository roots, you probably want to use
> the closest one. Otherwise, the behavior will be the same.
Yes, the closest one is the right.
>>>> - (define-key map "d" 'vc-dir)
>>>> + (define-key map "d" 'vc-root-dir)
>>>
>>> But this would probably be very controversial. `C-x v /' is a nice
>>> binding, though...
>>
>> I'd prefer an option whose customization would allow `C-x v d'
>> to always use the root.
>
> Honestly, I think these are equivalent proposals, with the exception that
> Lars' keeps the current behavior intact by default.
>
> For those of us who want to change the behavior of 'C-x v d', we can call
> define-key in the init script.
So we could have a new command anyway (with a different name than
the already added function vc-root-dir that returns the root directory),
even if unbound, so users can decide wherever they prefer to bind it.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Fri, 28 Jun 2019 19:30:03 GMT)
Full text and
rfc822 format available.
Message #75 received at 12492 <at> debbugs.gnu.org (full text, mbox):
On 28.06.2019 22:17, Juri Linkov wrote:
> So we could have a new command anyway (with a different name than
> the already added function vc-root-dir that returns the root directory),
> even if unbound, so users can decide wherever they prefer to bind it.
Yup, that would be fine by me.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Fri, 28 Jun 2019 19:31:02 GMT)
Full text and
rfc822 format available.
Message #78 received at 12492 <at> debbugs.gnu.org (full text, mbox):
On 28.06.2019 1:14, Lars Ingebrigtsen wrote:
> It's as easy to type as `C-x v d' (at
> least on US keyboards)...
Not exactly; the former can be typed using just one hand. That's easier,
in my book.
So overall, I'm leaning towards just adding a new command and leaving
the choice of binding it to the user.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Sat, 29 Jun 2019 10:20:02 GMT)
Full text and
rfc822 format available.
Message #81 received at 12492 <at> debbugs.gnu.org (full text, mbox):
Dmitry Gutov <dgutov <at> yandex.ru> writes:
> On 28.06.2019 22:17, Juri Linkov wrote:
>> So we could have a new command anyway (with a different name than
>> the already added function vc-root-dir that returns the root directory),
>> even if unbound, so users can decide wherever they prefer to bind it.
>
> Yup, that would be fine by me.
I don't see any reason not to bind this new command to a key: It seems
like a genuinely useful command that most people (if they knows it
exists) will want to use. I can well imagine more people wanting that
command than they want the `C-x v d' one.
But I also think that many people will want both, so the solution seems
to me to just bind this new command to a new keystroke, and leave the
rest alone.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Sun, 30 Jun 2019 22:16:02 GMT)
Full text and
rfc822 format available.
Message #84 received at 12492 <at> debbugs.gnu.org (full text, mbox):
>>> So we could have a new command anyway (with a different name than
>>> the already added function vc-root-dir that returns the root directory),
>>> even if unbound, so users can decide wherever they prefer to bind it.
>>
>> Yup, that would be fine by me.
>
> I don't see any reason not to bind this new command to a key: It seems
> like a genuinely useful command that most people (if they knows it
> exists) will want to use. I can well imagine more people wanting that
> command than they want the `C-x v d' one.
>
> But I also think that many people will want both, so the solution seems
> to me to just bind this new command to a new keystroke, and leave the
> rest alone.
C-x v / is so nicely mnemonic keybinding that it even makes sense
to use it as a key prefix to the whole set of root-related commands, e.g.:
C-x v / = vc-root-diff (mnemonic: '/' root, '=' diff)
C-x v / l vc-print-root-log (mnemonic: '/' root, 'l' log)
C-x v / d vc-root-dir (mnemonic: '/' root, 'd' dir)
...
Hmm, btw, why the extra prefix 'print-'? Why not simply 'vc-root-log'?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Mon, 01 Jul 2019 08:03:02 GMT)
Full text and
rfc822 format available.
Message #87 received at 12492 <at> debbugs.gnu.org (full text, mbox):
On Sep 23 2012, Dmitry Gutov <dgutov <at> yandex.ru> wrote:
> +(defun vc-root-dir ()
This is already defined in vc.el.
Andreas.
--
Andreas Schwab, SUSE Labs, schwab <at> suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Mon, 01 Jul 2019 12:57:01 GMT)
Full text and
rfc822 format available.
Message #90 received at 12492 <at> debbugs.gnu.org (full text, mbox):
On 01.07.2019 11:02, Andreas Schwab wrote:
> On Sep 23 2012, Dmitry Gutov <dgutov <at> yandex.ru> wrote:
>
>> +(defun vc-root-dir ()
>
> This is already defined in vc.el.
True. The patch predated the introduction of that function.
Here's the code that I have been using for the last few years:
(defun vc-dir-quick ()
(interactive)
(require 'vc-dir)
(let* ((file (or buffer-file-name default-directory))
(backend (vc-responsible-backend file))
(dir (vc-call-backend backend 'root file)))
(let (pop-up-windows)
(pop-to-buffer (vc-dir-prepare-status-buffer "*vc-dir*" dir
backend)))
(unless (derived-mode-p 'vc-dir-mode)
(let ((use-vc-backend backend))
(vc-dir-mode)))))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Mon, 01 Jul 2019 13:02:02 GMT)
Full text and
rfc822 format available.
Message #93 received at 12492 <at> debbugs.gnu.org (full text, mbox):
On 29.06.2019 13:19, Lars Ingebrigtsen wrote:
> I don't see any reason not to bind this new command to a key: It seems
> like a genuinely useful command that most people (if they knows it
> exists) will want to use. I can well imagine more people wanting that
> command than they want the `C-x v d' one.
I honestly don't see the point of having both having a binding. IME, the
new commands is useful 99% of the time, and in the remaining case it
would be faster to type 'M-x vc-dir' than remember the respective
different key binding.
But please do as you see fit. The fight for a better behavior for 'C-x v
d' seems to have been lost years ago, and it's the only key binding
change here that I would get behind.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Tue, 02 Jul 2019 12:40:02 GMT)
Full text and
rfc822 format available.
Message #96 received at 12492 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> linkov.net> writes:
> C-x v / is so nicely mnemonic keybinding that it even makes sense
> to use it as a key prefix to the whole set of root-related commands, e.g.:
>
> C-x v / = vc-root-diff (mnemonic: '/' root, '=' diff)
> C-x v / l vc-print-root-log (mnemonic: '/' root, 'l' log)
> C-x v / d vc-root-dir (mnemonic: '/' root, 'd' dir)
Hm... makes sense. But they are inconveniently long for tasks that you
do all the time.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Thu, 04 Jul 2019 20:39:02 GMT)
Full text and
rfc822 format available.
Message #99 received at 12492 <at> debbugs.gnu.org (full text, mbox):
>> C-x v / is so nicely mnemonic keybinding that it even makes sense
>> to use it as a key prefix to the whole set of root-related commands, e.g.:
>>
>> C-x v / = vc-root-diff (mnemonic: '/' root, '=' diff)
>> C-x v / l vc-print-root-log (mnemonic: '/' root, 'l' log)
>> C-x v / d vc-root-dir (mnemonic: '/' root, 'd' dir)
>
> Hm... makes sense. But they are inconveniently long for tasks that you
> do all the time.
Also it makes more sense to introduce a root prefix map for the whole set
of project related commands (not necessarily restricted to VCS):
C-x / d - project dir
C-x / f - project find file
C-x / r - project find regexp
C-x / t - project tag search
C-x / s - project search/grep
C-x / % - project query-replace
C-x / l - project log
C-x / = - project diff
...
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Thu, 04 Jul 2019 20:39:02 GMT)
Full text and
rfc822 format available.
Message #102 received at 12492 <at> debbugs.gnu.org (full text, mbox):
>>> +(defun vc-root-dir ()
>>
>> This is already defined in vc.el.
>
> True. The patch predated the introduction of that function.
Maybe better to add interactivity to the existing function
`vc-root-dir', i.e. to add a new arg `(&optional interactive)'
and add `(interactive "p")'.
BTW, I propose another useful command without a keybinding.
I have a habit of mistyping `v' in vc-dir to view a file like in dired.
That often has adverse effect. So I rebound these keys in ~/.emacs
to a Dired-like command. Maybe this command could be useful for anyone
who has the same problem:
diff --git a/lisp/vc/vc-dir.el b/lisp/vc/vc-dir.el
index 6afc599d4c..a6a87e51e3 100644
--- a/lisp/vc/vc-dir.el
+++ b/lisp/vc/vc-dir.el
@@ -784,6 +784,11 @@ vc-dir-display-file
(display-buffer (find-file-noselect (vc-dir-current-file))
t))
+(defun vc-dir-view-file ()
+ "Examine a file on the current line in view mode."
+ (interactive)
+ (view-file (vc-dir-current-file)))
+
(defun vc-dir-isearch ()
"Search for a string through all marked buffers using Isearch."
(interactive)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Thu, 04 Jul 2019 22:07:01 GMT)
Full text and
rfc822 format available.
Message #105 received at 12492 <at> debbugs.gnu.org (full text, mbox):
>>>> +(defun vc-root-dir ()
>>>
>>> This is already defined in vc.el.
>>
>> True. The patch predated the introduction of that function.
>
> Maybe better to add interactivity to the existing function
> `vc-root-dir', i.e. to add a new arg `(&optional interactive)'
> and add `(interactive "p")'.
BTW, why vc-git-log-incoming and vc-git-log-outgoing are interactive?
It seems these functions are not intended to be used as commands:
diff --git a/lisp/vc/vc-git.el b/lisp/vc/vc-git.el
index f62e108322..6a6036cf8a 100644
--- a/lisp/vc/vc-git.el
+++ b/lisp/vc/vc-git.el
@@ -1048,7 +1050,6 @@ vc-git-print-log
'("--")))))))
(defun vc-git-log-outgoing (buffer remote-location)
- (interactive)
(vc-setup-buffer buffer)
(vc-git-command
buffer 'async nil
@@ -1062,7 +1063,6 @@ vc-git-log-outgoing
"..HEAD")))
(defun vc-git-log-incoming (buffer remote-location)
- (interactive)
(vc-setup-buffer buffer)
(vc-git-command nil 0 nil "fetch")
(vc-git-command
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Fri, 05 Jul 2019 13:10:01 GMT)
Full text and
rfc822 format available.
Message #108 received at 12492 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> linkov.net> writes:
> Also it makes more sense to introduce a root prefix map for the whole set
> of project related commands (not necessarily restricted to VCS):
>
> C-x / d - project dir
> C-x / f - project find file
> C-x / r - project find regexp
> C-x / t - project tag search
> C-x / s - project search/grep
> C-x / % - project query-replace
> C-x / l - project log
> C-x / = - project diff
I like it. How would one define "project root" outside of a VCS, though?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Fri, 05 Jul 2019 13:42:01 GMT)
Full text and
rfc822 format available.
Message #111 received at 12492 <at> debbugs.gnu.org (full text, mbox):
On 05.07.2019 16:09, Lars Ingebrigtsen wrote:
> Juri Linkov <juri <at> linkov.net> writes:
>
>> Also it makes more sense to introduce a root prefix map for the whole set
>> of project related commands (not necessarily restricted to VCS):
>>
>> C-x / d - project dir
>> C-x / f - project find file
>> C-x / r - project find regexp
>> C-x / t - project tag search
>> C-x / s - project search/grep
>> C-x / % - project query-replace
>> C-x / l - project log
>> C-x / = - project diff
>
> I like it. How would one define "project root" outside of a VCS, though?
'project root' is defined in project.el.
I don't know how we would define 'project log' or 'project diff', though.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Fri, 05 Jul 2019 13:44:01 GMT)
Full text and
rfc822 format available.
Message #114 received at 12492 <at> debbugs.gnu.org (full text, mbox):
On 04.07.2019 23:25, Juri Linkov wrote:
> Maybe better to add interactivity to the existing function
> `vc-root-dir', i.e. to add a new arg `(&optional interactive)'
> and add `(interactive "p")'.
Not sure I would like such wide overloading of behaviors.
> BTW, I propose another useful command without a keybinding.
> I have a habit of mistyping `v' in vc-dir to view a file like in dired.
> That often has adverse effect. So I rebound these keys in ~/.emacs
> to a Dired-like command. Maybe this command could be useful for anyone
> who has the same problem:
I don't have this problem or a strong opinion, but this is a breaking
change. Could you bring it up on emacs-devel to gauge consensus, for
example?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Fri, 05 Jul 2019 13:46:02 GMT)
Full text and
rfc822 format available.
Message #117 received at 12492 <at> debbugs.gnu.org (full text, mbox):
On 05.07.2019 1:05, Juri Linkov wrote:
> BTW, why vc-git-log-incoming and vc-git-log-outgoing are interactive?
> It seems these functions are not intended to be used as commands:
Makes sense, thank you. Please install.
> diff --git a/lisp/vc/vc-git.el b/lisp/vc/vc-git.el
> index f62e108322..6a6036cf8a 100644
> --- a/lisp/vc/vc-git.el
> +++ b/lisp/vc/vc-git.el
> @@ -1048,7 +1050,6 @@ vc-git-print-log
> '("--")))))))
>
> (defun vc-git-log-outgoing (buffer remote-location)
> - (interactive)
> (vc-setup-buffer buffer)
> (vc-git-command
> buffer 'async nil
> @@ -1062,7 +1063,6 @@ vc-git-log-outgoing
> "..HEAD")))
>
> (defun vc-git-log-incoming (buffer remote-location)
> - (interactive)
> (vc-setup-buffer buffer)
> (vc-git-command nil 0 nil "fetch")
> (vc-git-command
>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Fri, 05 Jul 2019 19:14:05 GMT)
Full text and
rfc822 format available.
Message #120 received at 12492 <at> debbugs.gnu.org (full text, mbox):
>>> Also it makes more sense to introduce a root prefix map for the whole set
>>> of project related commands (not necessarily restricted to VCS):
>>>
>>> C-x / d - project dir
>>> C-x / f - project find file
>>> C-x / r - project find regexp
>>> C-x / t - project tag search
>>> C-x / s - project search/grep
>>> C-x / % - project query-replace
>>> C-x / l - project log
>>> C-x / = - project diff
>>
>> I like it. How would one define "project root" outside of a VCS, though?
>
> 'project root' is defined in project.el.
>
> I don't know how we would define 'project log' or 'project diff', though.
When a project is not under VCS then 'project log' could rely on
ChangeLog files, and 'project diff' to use backup files.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Fri, 05 Jul 2019 19:14:06 GMT)
Full text and
rfc822 format available.
Message #123 received at 12492 <at> debbugs.gnu.org (full text, mbox):
>> BTW, I propose another useful command without a keybinding.
>> I have a habit of mistyping `v' in vc-dir to view a file like in dired.
>> That often has adverse effect. So I rebound these keys in ~/.emacs
>> to a Dired-like command. Maybe this command could be useful for anyone
>> who has the same problem:
>
> I don't have this problem or a strong opinion, but this is a breaking
> change. Could you bring it up on emacs-devel to gauge consensus,
> for example?
This is not a breaking change because it's just a new command
without keybinding.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Sat, 06 Jul 2019 08:38:02 GMT)
Full text and
rfc822 format available.
Message #126 received at 12492 <at> debbugs.gnu.org (full text, mbox):
On 05.07.2019 21:56, Juri Linkov wrote:
> This is not a breaking change because it's just a new command
> without keybinding.
Ah, sorry. Please go ahead, then.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Sat, 06 Jul 2019 12:00:02 GMT)
Full text and
rfc822 format available.
Message #129 received at 12492 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> linkov.net> writes:
> When a project is not under VCS then 'project log' could rely on
> ChangeLog files, and 'project diff' to use backup files.
Which reminds me -- why doesn't `C-x v =' work on normal files that have
backups? I think that would be pretty nice, natural and useful...
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Sun, 07 Jul 2019 23:04:01 GMT)
Full text and
rfc822 format available.
Message #132 received at 12492 <at> debbugs.gnu.org (full text, mbox):
>> When a project is not under VCS then 'project log' could rely on
>> ChangeLog files, and 'project diff' to use backup files.
>
> Which reminds me -- why doesn't `C-x v =' work on normal files that have
> backups? I think that would be pretty nice, natural and useful...
I have the same problem of sometimes typing `C-x v =' instead of `M-='
(dired-backup-diff) on backuped files in dired, and vice versa - `M-='
instead of `C-x v =' on VC files.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Sun, 07 Jul 2019 23:10:02 GMT)
Full text and
rfc822 format available.
Message #135 received at 12492 <at> debbugs.gnu.org (full text, mbox):
On 08.07.2019 1:56, Juri Linkov wrote:
>>> When a project is not under VCS then 'project log' could rely on
>>> ChangeLog files, and 'project diff' to use backup files.
>>
>> Which reminds me -- why doesn't `C-x v =' work on normal files that have
>> backups? I think that would be pretty nice, natural and useful...
>
> I have the same problem of sometimes typing `C-x v =' instead of `M-='
> (dired-backup-diff) on backuped files in dired, and vice versa - `M-='
> instead of `C-x v =' on VC files.
But those are significantly different commands. One diffs against the
last saved copy of the file, the other works only on the saved files.
And anyway, there's no counterpart for vc-print-root-log.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Sun, 07 Jul 2019 23:12:02 GMT)
Full text and
rfc822 format available.
Message #138 received at 12492 <at> debbugs.gnu.org (full text, mbox):
On 05.07.2019 21:53, Juri Linkov wrote:
> When a project is not under VCS then 'project log' could rely on
> ChangeLog files, and 'project diff' to use backup files.
I don't imagine either would (or could) use project.el, so calling those
hypothetical commands project-based seems like a misnomer.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Tue, 25 Feb 2020 00:42:02 GMT)
Full text and
rfc822 format available.
Message #141 received at 12492 <at> debbugs.gnu.org (full text, mbox):
> Also it makes more sense to introduce a root prefix map for the whole set of
> project related commands (not necessarily restricted to VCS):
>
> C-x / d - project dir
> C-x / f - project find file
> C-x / r - project find regexp
> C-x / t - project tag search
> C-x / s - project search/grep
> C-x / % - project query-replace
> C-x / l - project log
> C-x / = - project diff
> ...
OTOH, wouldn't it be nicer to use more mnemonic prefix key
'C-x p' where 'p' means "project". Then:
C-x p d - project dir
C-x p s - project shell
C-x p g - project grep
...
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Tue, 25 Feb 2020 10:36:01 GMT)
Full text and
rfc822 format available.
Message #144 received at 12492 <at> debbugs.gnu.org (full text, mbox):
On 25.02.2020 2:10, Juri Linkov wrote:
> OTOH, wouldn't it be nicer to use more mnemonic prefix key
> 'C-x p' where 'p' means "project". Then:
Sure (and I'm fine with either prefix), but...
> C-x p d - project dir
That sounds more like "open Dired in the project's root".
> C-x p s - project shell
> C-x p g - project grep
Bind project-find-regexp to it?
> ...
And a command that opens VC-Dir in the VC root, wouldn't use the
project.el infractructure. Correct me if I'm wrong about that.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Tue, 25 Feb 2020 21:35:01 GMT)
Full text and
rfc822 format available.
Message #147 received at 12492 <at> debbugs.gnu.org (full text, mbox):
>> C-x p d - project dir
>
> That sounds more like "open Dired in the project's root".
Indeed, two commands compete for the same mnemonic key 'd':
Dired and VC-Dired.
>> C-x p g - project grep
>
> Bind project-find-regexp to it?
Not sure since project-find-regexp is not asynchronous as grep.
>> ...
>
> And a command that opens VC-Dir in the VC root, wouldn't use the project.el
> infractructure. Correct me if I'm wrong about that.
You know more about connection between project.el and VC.
What I could do is only to count occurrences of the word "vc"
in project.el: 39 occurrences.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Wed, 26 Feb 2020 22:52:02 GMT)
Full text and
rfc822 format available.
Message #150 received at 12492 <at> debbugs.gnu.org (full text, mbox):
On 25.02.2020 23:27, Juri Linkov wrote:
>>> C-x p d - project dir
>>
>> That sounds more like "open Dired in the project's root".
>
> Indeed, two commands compete for the same mnemonic key 'd':
> Dired and VC-Dired.
And only one of the is likely to use the project.el functions.
>>> C-x p g - project grep
>>
>> Bind project-find-regexp to it?
>
> Not sure since project-find-regexp is not asynchronous as grep.
All the more reason for someone to work on that. And the former has
other benefits.
>> And a command that opens VC-Dir in the VC root, wouldn't use the project.el
>> infractructure. Correct me if I'm wrong about that.
>
> You know more about connection between project.el and VC.
> What I could do is only to count occurrences of the word "vc"
> in project.el: 39 occurrences.
VC is just one of project.el's backends. The main one among the
built-ins, but that's not particularly important in this context.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Wed, 26 Feb 2020 23:48:02 GMT)
Full text and
rfc822 format available.
Message #153 received at 12492 <at> debbugs.gnu.org (full text, mbox):
> VC is just one of project.el's backends. The main one among the built-ins,
> but that's not particularly important in this context.
I guess other backends have no analogue of vc-dir and other vc commands.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Thu, 27 Feb 2020 07:28:02 GMT)
Full text and
rfc822 format available.
Message #156 received at 12492 <at> debbugs.gnu.org (full text, mbox):
On 27.02.2020 1:41, Juri Linkov wrote:
> I guess other backends have no analogue of vc-dir and other vc commands
Nope.
I mean, you call VC-Dir in an arbitrary project's root anyway, and a lot
of times it will work. But a project root doesn't have to be a VC root
and vice versa, so these notions are more or less orthogonal.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Thu, 27 Feb 2020 23:19:02 GMT)
Full text and
rfc822 format available.
Message #159 received at 12492 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> I'd prefer an option whose customization would allow `C-x v d'
> to always use the root.
Given all the discussed constraints (no change in default behavior of
`C-x v d' is allowed, etc.), I see one way to close this bug report -
to add a customizable variable:
[vc-dir-default-directory.patch (text/x-diff, inline)]
diff --git a/lisp/vc/vc-dir.el b/lisp/vc/vc-dir.el
index e5c5e16a17..2699f8155b 100644
--- a/lisp/vc/vc-dir.el
+++ b/lisp/vc/vc-dir.el
@@ -1285,6 +1285,22 @@ vc-dir-deduce-fileset
(setq model (vc-checkout-model vc-dir-backend only-files-list))))
(list vc-dir-backend files only-files-list state model)))
+(defcustom vc-dir-default-directory nil
+ "Default directory name for the command `vc-dir'.
+When nil, `vc-dir' reads a directory name using the minibuffer.
+When non-nil and the current directory is under version control,
+`vc-dir' doesn't ask for a directory name and uses the VC root directory.
+When a string and `vc-dir' is invoked in a directory outside of
+version control, then this string is used as a default directory name.
+
+However, the prefix arg of `vc-dir' overrides this customization
+and still asks for a directory name and backend."
+ :type '(choice (const :tag "Ask for directory" nil)
+ (const :tag "Use VC root directory" t)
+ (string :tag "Custom directory"))
+ :group 'vc
+ :version "28.1")
+
;;;###autoload
(defun vc-dir (dir &optional backend)
"Show the VC status for \"interesting\" files in and below DIR.
@@ -1304,22 +1320,29 @@ vc-dir
\\{vc-dir-mode-map}"
(interactive
- (list
- ;; When you hit C-x v d in a visited VC file,
- ;; the *vc-dir* buffer visits the directory under its truename;
- ;; therefore it makes sense to always do that.
- ;; Otherwise if you do C-x v d -> C-x C-f -> C-c v d
- ;; you may get a new *vc-dir* buffer, different from the original
- (file-truename (read-directory-name "VC status for directory: "
- (vc-root-dir) nil t
- nil))
- (if current-prefix-arg
- (intern
- (completing-read
- "Use VC backend: "
- (mapcar (lambda (b) (list (symbol-name b)))
- vc-handled-backends)
- nil t nil nil)))))
+ (let ((dir
+ ;; When you hit C-x v d in a visited VC file,
+ ;; the *vc-dir* buffer visits the directory under its truename;
+ ;; therefore it makes sense to always do that.
+ ;; Otherwise if you do C-x v d -> C-x C-f -> C-x v d
+ ;; you may get a new *vc-dir* buffer, different from the original
+ (file-truename
+ (let ((root-dir (vc-root-dir)))
+ (if (and vc-dir-default-directory
+ (not current-prefix-arg)
+ (or root-dir (and (stringp vc-dir-default-directory)
+ (file-directory-p vc-dir-default-directory))))
+ (or root-dir vc-dir-default-directory)
+ (read-directory-name "VC status for directory: "
+ (vc-root-dir) nil t nil))))))
+ (list dir (if current-prefix-arg
+ (intern
+ (completing-read
+ "Use VC backend: "
+ (mapcar (lambda (b) (list (symbol-name b)))
+ vc-handled-backends)
+ nil t nil nil (symbol-name (ignore-errors
+ (vc-responsible-backend dir)))))))))
(unless backend
(setq backend (vc-responsible-backend dir)))
(let (pop-up-windows) ; based on cvs-examine; bug#6204
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Sat, 29 Feb 2020 21:52:02 GMT)
Full text and
rfc822 format available.
Message #162 received at 12492 <at> debbugs.gnu.org (full text, mbox):
>>>> C-x p g - project grep
>>>
>>> Bind project-find-regexp to it?
>>
>> Not sure since project-find-regexp is not asynchronous as grep.
>
> All the more reason for someone to work on that. And the former has
> other benefits.
‘C-x p s g’ could be bound to a new command ‘M-x project-grep’ that could run:
git --no-pager grep --color -inH -p -e "search_string"
Then ‘C-x p C-s’ could be bound to ‘project-search’
and ‘C-x p M-%’ to ‘project-query-replace-regexp’.
BTW, why current project commands are not documented
in the Emacs Info manual? Should they?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Mon, 02 Mar 2020 22:12:01 GMT)
Full text and
rfc822 format available.
Message #165 received at 12492 <at> debbugs.gnu.org (full text, mbox):
On 29.02.2020 23:16, Juri Linkov wrote:
>>>>> C-x p g - project grep
>>>>
>>>> Bind project-find-regexp to it?
>>>
>>> Not sure since project-find-regexp is not asynchronous as grep.
>>
>> All the more reason for someone to work on that. And the former has
>> other benefits.
>
> ‘C-x p s g’ could be bound to a new command ‘M-x project-grep’ that could run:
>
> git --no-pager grep --color -inH -p -e "search_string"
And then we'll have three very similar commands side-by-side in the same
menu, or on the same prefix?
project-find-regexp is the available backend-agnostic option. You can
write project-grep, but it would most likely have to work with xargs,
like former does.
> Then ‘C-x p C-s’ could be bound to ‘project-search’
People are welcome to use it, but it's implementation and UI are
suboptimal in several respects.
> and ‘C-x p M-%’ to ‘project-query-replace-regexp’.
>
> BTW, why current project commands are not documented
> in the Emacs Info manual? Should they?
I don't know. What are the criteria?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Mon, 02 Mar 2020 22:19:02 GMT)
Full text and
rfc822 format available.
Message #168 received at 12492 <at> debbugs.gnu.org (full text, mbox):
On 28.02.2020 0:50, Juri Linkov wrote:
> Given all the discussed constraints (no change in default behavior of
> `C-x v d' is allowed, etc.), I see one way to close this bug report -
> to add a customizable variable:
Why not a new command, like I suggested before? Either way the user
would have to customize something (a keybinding, in that case).
That aside...
> +(defcustom vc-dir-default-directory nil
> + "Default directory name for the command `vc-dir'.
Both of these lines look wrong.
VC-Dir already uses the correct directory as the default. What you're
looking for is to avoid prompting the user.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Mon, 02 Mar 2020 23:39:02 GMT)
Full text and
rfc822 format available.
Message #171 received at 12492 <at> debbugs.gnu.org (full text, mbox):
>> Given all the discussed constraints (no change in default behavior of
>> `C-x v d' is allowed, etc.), I see one way to close this bug report -
>> to add a customizable variable:
>
> Why not a new command, like I suggested before? Either way the user would
> have to customize something (a keybinding, in that case).
You can implement a new command in addition to defcustom.
These options are not mutually exclusive.
And the command even could use the new defcustom
in the implementation, e.g.
(defun vc-root-dir ()
(interactive)
(let ((vc-dir-default-directory t))
(call-interactively 'vc-dir) ...
But the command has more unsolved issues:
1. command name - the most natural name would be vc-root-dir,
but this name is already taken by a non-interactive function.
2. keybinding - there are many contradicting proposals,
and leaving it unbound is not the best solution.
>> +(defcustom vc-dir-default-directory nil
>> + "Default directory name for the command `vc-dir'.
>
> Both of these lines look wrong.
>
> VC-Dir already uses the correct directory as the default. What you're
> looking for is to avoid prompting the user.
These details are explained further down in the docstring:
+When nil, `vc-dir' reads a directory name using the minibuffer.
+When non-nil and the current directory is under version control,
+`vc-dir' doesn't ask for a directory name and uses the VC root directory.
+When a string and `vc-dir' is invoked in a directory outside of
+version control, then this string is used as a default directory name.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Mon, 02 Mar 2020 23:39:02 GMT)
Full text and
rfc822 format available.
Message #174 received at 12492 <at> debbugs.gnu.org (full text, mbox):
>>>>>> C-x p g - project grep
>>>>>
>>>>> Bind project-find-regexp to it?
>>>>
>>>> Not sure since project-find-regexp is not asynchronous as grep.
>>>
>>> All the more reason for someone to work on that. And the former has
>>> other benefits.
>> ‘C-x p s g’ could be bound to a new command ‘M-x project-grep’ that could
>> run:
>> git --no-pager grep --color -inH -p -e "search_string"
>
> And then we'll have three very similar commands side-by-side in the same
> menu, or on the same prefix?
Yes, in the new Project menu.
> project-find-regexp is the available backend-agnostic option. You can write
> project-grep, but it would most likely have to work with xargs, like
> former does.
project-grep could rely on xargs indeed. But what about vc-grep?
Should it use xargs on ls-files, or the existing command vc-git-grep
should be generalized with a new backend operation e.g. "vc-grep pattern"
that could be implemented by more vc backends?
>> Then ‘C-x p C-s’ could be bound to ‘project-search’
>
> People are welcome to use it, but it's implementation and UI are suboptimal
> in several respects.
Maybe a better option is to implement project-isearch,
i.e. multi-file isearch on all project files?
This is trivial to do with just a call to (multi-isearch-files files)
>> and ‘C-x p M-%’ to ‘project-query-replace-regexp’.
>> BTW, why current project commands are not documented
>> in the Emacs Info manual? Should they?
>
> I don't know. What are the criteria?
Maybe when is becomes popular enough?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Tue, 03 Mar 2020 11:28:02 GMT)
Full text and
rfc822 format available.
Message #177 received at 12492 <at> debbugs.gnu.org (full text, mbox):
On 03.03.2020 0:57, Juri Linkov wrote:
>>> Given all the discussed constraints (no change in default behavior of
>>> `C-x v d' is allowed, etc.), I see one way to close this bug report -
>>> to add a customizable variable:
>>
>> Why not a new command, like I suggested before? Either way the user would
>> have to customize something (a keybinding, in that case).
>
> You can implement a new command in addition to defcustom.
> These options are not mutually exclusive.
Sure.
> And the command even could use the new defcustom
> in the implementation, e.g.
>
> (defun vc-root-dir ()
> (interactive)
> (let ((vc-dir-default-directory t))
> (call-interactively 'vc-dir) ...
>
> But the command has more unsolved issues:
>
> 1. command name - the most natural name would be vc-root-dir,
> but this name is already taken by a non-interactive function.
vc-dir-quick was my idea.
> 2. keybinding - there are many contradicting proposals,
> and leaving it unbound is not the best solution.
Like mentioned already, I think it's fine unbound. Not worse than having
a user option. It comes down to the user either customizing the option,
or binding the command to 'C-x v d' in their init script. We shouldn't
provide both in the core, though.
>>> +(defcustom vc-dir-default-directory nil
>>> + "Default directory name for the command `vc-dir'.
>>
>> Both of these lines look wrong.
>>
>> VC-Dir already uses the correct directory as the default. What you're
>> looking for is to avoid prompting the user.
>
> These details are explained further down in the docstring:
I'm saying both the option name and the first sentence of the docstring
don't fit its purpose, or the later description.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Tue, 03 Mar 2020 11:34:02 GMT)
Full text and
rfc822 format available.
Message #180 received at 12492 <at> debbugs.gnu.org (full text, mbox):
On 03.03.2020 1:05, Juri Linkov wrote:
>>>>>>> C-x p g - project grep
>>>>>>
>>>>>> Bind project-find-regexp to it?
>>>>>
>>>>> Not sure since project-find-regexp is not asynchronous as grep.
>>>>
>>>> All the more reason for someone to work on that. And the former has
>>>> other benefits.
>>> ‘C-x p s g’ could be bound to a new command ‘M-x project-grep’ that could
>>> run:
>>> git --no-pager grep --color -inH -p -e "search_string"
>>
>> And then we'll have three very similar commands side-by-side in the same
>> menu, or on the same prefix?
>
> Yes, in the new Project menu.
I think that would be silly.
> But what about vc-grep?
> Should it use xargs on ls-files, or the existing command vc-git-grep
> should be generalized with a new backend operation e.g. "vc-grep pattern"
> that could be implemented by more vc backends?
If it can be generalized, it can be generalized. But it seems unrelated
to the current discussion.
>>> Then ‘C-x p C-s’ could be bound to ‘project-search’
>>
>> People are welcome to use it, but it's implementation and UI are suboptimal
>> in several respects.
>
> Maybe a better option is to implement project-isearch,
> i.e. multi-file isearch on all project files?
> This is trivial to do with just a call to (multi-isearch-files files)
https://pics.me.me/thumb_why-mermegenerator-net-but-why-jackie-chan-meme-meme-50686141.png
project-find-regexp is both faster in most situations, works remotely,
and provides a decent UI.
You're free to implement any variations of existing commands, and they
can be good in certain situations, but we shouldn't prefer them over the
primary command (which has had quite some work put into) for the menu
placement.
>>> and ‘C-x p M-%’ to ‘project-query-replace-regexp’.
>>> BTW, why current project commands are not documented
>>> in the Emacs Info manual? Should they?
>>
>> I don't know. What are the criteria?
>
> Maybe when is becomes popular enough?
That doesn't sound right. We put info into the manual to popularize it,
not vice versa.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Tue, 03 Mar 2020 13:33:02 GMT)
Full text and
rfc822 format available.
Message #183 received at 12492 <at> debbugs.gnu.org (full text, mbox):
On 03.03.2020 13:33, Dmitry Gutov wrote:
> You're free to implement any variations of existing commands, and they
> can be good in certain situations, but we shouldn't prefer them over the
> primary command (which has had quite some work put into) for the menu
> placement.
Maybe your point was that it would be sufficiently different to have
both in the menu.
If so, maybe so.
BTW, I wonder how such project-isearch using multi-isearch-files would
work in a non-toy project with a sufficiently-rare input.
Even if we take the Emacs project itself, loading all 4000 files into
Emacs's memory to search through them all is likely to take a lot of time.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Wed, 04 Mar 2020 00:11:02 GMT)
Full text and
rfc822 format available.
Message #186 received at 12492 <at> debbugs.gnu.org (full text, mbox):
> project-find-regexp is both faster in most situations, works remotely, and
> provides a decent UI.
project-find-regexp is not asynchronous whereas vc-git-grep is.
UI of project-find-regexp is non-standard. A more familiar UI
would be like in occur, for example, as used by noccur-project.
> BTW, I wonder how such project-isearch using multi-isearch-files would work
> in a non-toy project with a sufficiently-rare input.
>
> Even if we take the Emacs project itself, loading all 4000 files into
> Emacs's memory to search through them all is likely to take a lot of time.
No problem at all - trying on the Emacs project:
(multi-isearch-files (project-files (project-current t)))
is like project-search, but with more convenient UI:
it's easier to type C-s to go to the next occurrence than
to invoke the command M-x fileloop-continue that has no keybinding.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Wed, 04 Mar 2020 00:11:02 GMT)
Full text and
rfc822 format available.
Message #189 received at 12492 <at> debbugs.gnu.org (full text, mbox):
>> But the command has more unsolved issues:
>> 1. command name - the most natural name would be vc-root-dir,
>> but this name is already taken by a non-interactive function.
>
> vc-dir-quick was my idea.
This name implies its implementation has better performance
over its slower competitor.
>> 2. keybinding - there are many contradicting proposals,
>> and leaving it unbound is not the best solution.
>
> Like mentioned already, I think it's fine unbound. Not worse than having
> a user option. It comes down to the user either customizing the option,
> or binding the command to 'C-x v d' in their init script. We shouldn't
> provide both in the core, though.
>
>>>> +(defcustom vc-dir-default-directory nil
>>>> + "Default directory name for the command `vc-dir'.
>>>
>>> Both of these lines look wrong.
>>>
>>> VC-Dir already uses the correct directory as the default. What you're
>>> looking for is to avoid prompting the user.
>> These details are explained further down in the docstring:
>
> I'm saying both the option name and the first sentence of the docstring
> don't fit its purpose, or the later description.
This option is multi-purpose and one of its possible values is:
When a string and `vc-dir' is invoked in a directory outside of
version control, then this string is used as a default directory name.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Wed, 04 Mar 2020 11:52:01 GMT)
Full text and
rfc822 format available.
Message #192 received at 12492 <at> debbugs.gnu.org (full text, mbox):
On 04.03.2020 1:27, Juri Linkov wrote:
>>> But the command has more unsolved issues:
>>> 1. command name - the most natural name would be vc-root-dir,
>>> but this name is already taken by a non-interactive function.
>>
>> vc-dir-quick was my idea.
>
> This name implies its implementation has better performance
> over its slower competitor.
vc-dir-instant?
>> I'm saying both the option name and the first sentence of the docstring
>> don't fit its purpose, or the later description.
>
> This option is multi-purpose and one of its possible values is:
>
> When a string and `vc-dir' is invoked in a directory outside of
> version control, then this string is used as a default directory name.
You got a point there, but that seems like a rare use case (not sure who
would ever use it). I think the variable would be better named after its
main use scenario.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Wed, 04 Mar 2020 12:06:01 GMT)
Full text and
rfc822 format available.
Message #195 received at 12492 <at> debbugs.gnu.org (full text, mbox):
On 04.03.2020 1:19, Juri Linkov wrote:
>> project-find-regexp is both faster in most situations, works remotely, and
>> provides a decent UI.
>
> project-find-regexp is not asynchronous whereas vc-git-grep is.
There's no project-agnostic asynchronous option on the table now.
> UI of project-find-regexp is non-standard. A more familiar UI
> would be like in occur, for example, as used by noccur-project.
It is standard enough, Xref commands use it. And they have both default
key bindings and menu items.
noccur-project like this naive implementation?
https://nicolas.petton.fr/blog/mutli-occur-on-projects.html
How long does it take to search the Emacs project for an arbitrary
string on your machine?
Not to mention the unfortunate side-effect of having to visit 4000 buffers.
If you have a better implementation in mind, I will certainly try it.
>> BTW, I wonder how such project-isearch using multi-isearch-files would work
>> in a non-toy project with a sufficiently-rare input.
>>
>> Even if we take the Emacs project itself, loading all 4000 files into
>> Emacs's memory to search through them all is likely to take a lot of time.
>
> No problem at all - trying on the Emacs project:
>
> (multi-isearch-files (project-files (project-current t)))
>
> is like project-search, but with more convenient UI:
> it's easier to type C-s to go to the next occurrence than
> to invoke the command M-x fileloop-continue that has no keybinding.
"like project-search" also implies "to take a lot of time", that's where
I made that conclusion from. How long does it take for the UI to say "no
matches"?
The UI is probably better (the main thing I like about this idea), but
the downside is opening several buffers with intermediate matches for
incomplete input (while you're still typing the search string). Though I
don't know how serious of a problem that is.
And when I try this, I'm getting messages about uncompressing files, and
prompts about local variables, which I can't answer.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Thu, 05 Mar 2020 00:23:01 GMT)
Full text and
rfc822 format available.
Message #198 received at 12492 <at> debbugs.gnu.org (full text, mbox):
>>> project-find-regexp is both faster in most situations, works remotely, and
>>> provides a decent UI.
>> project-find-regexp is not asynchronous whereas vc-git-grep is.
>
> There's no project-agnostic asynchronous option on the table now.
Only getting project file names should be synchronous and blocking,
everything else (including grepping) could be asynchronous.
>> UI of project-find-regexp is non-standard. A more familiar UI
>> would be like in occur, for example, as used by noccur-project.
>
> It is standard enough, Xref commands use it. And they have both default key
> bindings and menu items.
>
> noccur-project like this naive implementation?
> https://nicolas.petton.fr/blog/mutli-occur-on-projects.html
It works fine as a proof of concept.
> How long does it take to search the Emacs project for an arbitrary string
> on your machine?
The result is almost instantaneous: 1 sec on Emacs repo.
> Not to mention the unfortunate side-effect of having to visit 4000 buffers.
It visits only matched buffers.
>>> BTW, I wonder how such project-isearch using multi-isearch-files would work
>>> in a non-toy project with a sufficiently-rare input.
>>>
>>> Even if we take the Emacs project itself, loading all 4000 files into
>>> Emacs's memory to search through them all is likely to take a lot of time.
>> No problem at all - trying on the Emacs project:
>> (multi-isearch-files (project-files (project-current t)))
>> is like project-search, but with more convenient UI:
>> it's easier to type C-s to go to the next occurrence than
>> to invoke the command M-x fileloop-continue that has no keybinding.
>
> "like project-search" also implies "to take a lot of time", that's where
> I made that conclusion from. How long does it take for the UI to say "no
> matches"?
Depends on the search string.
> The UI is probably better (the main thing I like about this idea), but the
> downside is opening several buffers with intermediate matches for
> incomplete input (while you're still typing the search string). Though I
> don't know how serious of a problem that is.
Probably multi-isearch-files could be useful for projects
with small number of files.
> And when I try this, I'm getting messages about uncompressing files, and
> prompts about local variables, which I can't answer.
OT1H, an ability to search in compressed files is an advantage -
even grep can't search in compressed files. OTOH, it had to visit
all files - this is its downside.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Thu, 05 Mar 2020 00:23:01 GMT)
Full text and
rfc822 format available.
Message #201 received at 12492 <at> debbugs.gnu.org (full text, mbox):
>>>> But the command has more unsolved issues:
>>>> 1. command name - the most natural name would be vc-root-dir,
>>>> but this name is already taken by a non-interactive function.
>>>
>>> vc-dir-quick was my idea.
>> This name implies its implementation has better performance
>> over its slower competitor.
>
> vc-dir-instant?
vc-dir-with-the-speed-of-light :)
>>> I'm saying both the option name and the first sentence of the docstring
>>> don't fit its purpose, or the later description.
>> This option is multi-purpose and one of its possible values is:
>> When a string and `vc-dir' is invoked in a directory outside of
>> version control, then this string is used as a default directory name.
>
> You got a point there, but that seems like a rare use case (not sure who
> would ever use it). I think the variable would be better named after its
> main use scenario.
Yeah, this is a secondary feature, not sure if it's needed.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Thu, 05 Mar 2020 23:16:02 GMT)
Full text and
rfc822 format available.
Message #204 received at 12492 <at> debbugs.gnu.org (full text, mbox):
On 05.03.2020 2:04, Juri Linkov wrote:
>>>> project-find-regexp is both faster in most situations, works remotely, and
>>>> provides a decent UI.
>>> project-find-regexp is not asynchronous whereas vc-git-grep is.
>>
>> There's no project-agnostic asynchronous option on the table now.
>
> Only getting project file names should be synchronous and blocking,
> everything else (including grepping) could be asynchronous.
The API indeed allows it, but there are no good UIs with that support
that we can use. But you're welcome to fix/improve/write one.
>>> UI of project-find-regexp is non-standard. A more familiar UI
>>> would be like in occur, for example, as used by noccur-project.
>>
>> It is standard enough, Xref commands use it. And they have both default key
>> bindings and menu items.
>>
>> noccur-project like this naive implementation?
>> https://nicolas.petton.fr/blog/mutli-occur-on-projects.html
>
> It works fine as a proof of concept.
Not if I have to wait for >1 minute for the UI to show up. Or I don't
know how long, I never managed to muster enough patience to get past all
the 'local variables' prompts.
>> How long does it take to search the Emacs project for an arbitrary string
>> on your machine?
>
> The result is almost instantaneous: 1 sec on Emacs repo.
I don't understand how that's possible: it's much longer than that on my
machine, and I have a fast laptop manufactured last year, with NVMe and
stuff.
>> Not to mention the unfortunate side-effect of having to visit 4000 buffers.
>
> It visits only matched buffers.
No. It looks through all project files and calls 'find-file' on each of
them. Which is obviously inevitable since multi-occur only accepts a
list of buffers, not files.
>>> (multi-isearch-files (project-files (project-current t)))
>>> is like project-search, but with more convenient UI:
>>> it's easier to type C-s to go to the next occurrence than
>>> to invoke the command M-x fileloop-continue that has no keybinding.
>>
>> "like project-search" also implies "to take a lot of time", that's where
>> I made that conclusion from. How long does it take for the UI to say "no
>> matches"?
>
> Depends on the search string.
To sum up: project-isearch could be a fine addition, but not the "main"
search command to recommend to our users.
>> And when I try this, I'm getting messages about uncompressing files, and
>> prompts about local variables, which I can't answer.
>
> OT1H, an ability to search in compressed files is an advantage -
> even grep can't search in compressed files. OTOH, it had to visit
> all files - this is its downside.
zgrep can probably do that. Much faster, too.
Anyway, if you want to continue this chat, could you file a relevant
bug, or post to emacs-devel?
All of this is certainly not about vc-dir anymore.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Fri, 06 Mar 2020 00:06:01 GMT)
Full text and
rfc822 format available.
Message #207 received at 12492 <at> debbugs.gnu.org (full text, mbox):
>> Only getting project file names should be synchronous and blocking,
>> everything else (including grepping) could be asynchronous.
>
> The API indeed allows it, but there are no good UIs with that support that
> we can use. But you're welcome to fix/improve/write one.
rgrep/vc-git-grep provides good UI.
>> The result is almost instantaneous: 1 sec on Emacs repo.
>
> I don't understand how that's possible: it's much longer than that on my
> machine, and I have a fast laptop manufactured last year, with NVMe and
> stuff.
The speed depends on the number of files with matches.
It's quick when matches are in a few files.
>>> Not to mention the unfortunate side-effect of having to visit 4000 buffers.
>> It visits only matched buffers.
>
> No. It looks through all project files and calls 'find-file' on each of
> them. Which is obviously inevitable since multi-occur only accepts a
> list of buffers, not files.
No, it doesn't call 'find-file' on each file, noccur-project
calls 'find-file' only on files with matches found by grep.
> Anyway, if you want to continue this chat, could you file a relevant bug,
> or post to emacs-devel?
>
> All of this is certainly not about vc-dir anymore.
Regarding vc-dir, I see no better name than 'vc-dir-default'
meaning that it uses root-dir by default.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Fri, 06 Mar 2020 09:41:02 GMT)
Full text and
rfc822 format available.
Message #210 received at 12492 <at> debbugs.gnu.org (full text, mbox):
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Tue, 3 Mar 2020 00:11:48 +0200
> Cc: 12492 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>
>
> > BTW, why current project commands are not documented
> > in the Emacs Info manual? Should they?
>
> I don't know. What are the criteria?
We could start by coming up with a list of commands and the use cases
where these commands are useful. Then we could reason whether these
are important enough to add to the manual.
Do we have in core any feature that provides back-end for the
project.el infrastructure? It sounds like we only support VC as
back-end in project.el, is that true?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Fri, 06 Mar 2020 15:34:01 GMT)
Full text and
rfc822 format available.
Message #213 received at 12492 <at> debbugs.gnu.org (full text, mbox):
On 06.03.2020 1:59, Juri Linkov wrote:
> Regarding vc-dir, I see no better name than 'vc-dir-default'
> meaning that it uses root-dir by default.
But the question is not what the default is (which will be VC root), but
whether to prompt the user or use that value right away.
So I was thinking more along the lines of vc-dir-prompt-p. Or, more
verbosely, vc-dir-prompt-for-directory.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Fri, 06 Mar 2020 16:02:02 GMT)
Full text and
rfc822 format available.
Message #216 received at 12492 <at> debbugs.gnu.org (full text, mbox):
On 06.03.2020 11:40, Eli Zaretskii wrote:
> We could start by coming up with a list of commands and the use cases
> where these commands are useful. Then we could reason whether these
> are important enough to add to the manual.
project-find-file and project-find-regexp are the main ones. Useful
when... you want to visit a file within the current project, or search
it for a regexp?
xref-query-replace-in-results could also be mentioned, given that it
allows the user to replace the matches with some other string (both in
project-find-regexp output, and in xref-find-references output).
> Do we have in core any feature that provides back-end for the
> project.el infrastructure? It sounds like we only support VC as
> back-end in project.el, is that true?
It's extensible via project-find-functions, which was the core design goal.
In the core, we have only two backends indeed: one using VC, and another
for EDE.
Though I'm not sure if the latter has any users, and its implementation
is very simplistic.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Fri, 06 Mar 2020 16:15:02 GMT)
Full text and
rfc822 format available.
Message #219 received at 12492 <at> debbugs.gnu.org (full text, mbox):
> Cc: 12492 <at> debbugs.gnu.org, larsi <at> gnus.org, juri <at> linkov.net
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Fri, 6 Mar 2020 18:01:25 +0200
>
> On 06.03.2020 11:40, Eli Zaretskii wrote:
>
> > We could start by coming up with a list of commands and the use cases
> > where these commands are useful. Then we could reason whether these
> > are important enough to add to the manual.
>
> project-find-file and project-find-regexp are the main ones. Useful
> when... you want to visit a file within the current project, or search
> it for a regexp?
>
> xref-query-replace-in-results could also be mentioned, given that it
> allows the user to replace the matches with some other string (both in
> project-find-regexp output, and in xref-find-references output).
>
> > Do we have in core any feature that provides back-end for the
> > project.el infrastructure? It sounds like we only support VC as
> > back-end in project.el, is that true?
>
> It's extensible via project-find-functions, which was the core design goal.
>
> In the core, we have only two backends indeed: one using VC, and another
> for EDE.
>
> Though I'm not sure if the latter has any users, and its implementation
> is very simplistic.
So if we want to document the above two commands, we should do that in
the VC chapter, and talk about "project" meaning the current VCS
repository?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Fri, 06 Mar 2020 16:54:01 GMT)
Full text and
rfc822 format available.
Message #222 received at 12492 <at> debbugs.gnu.org (full text, mbox):
On 06.03.2020 18:14, Eli Zaretskii wrote:
> So if we want to document the above two commands, we should do that in
> the VC chapter, and talk about "project" meaning the current VCS
> repository?
Umm, that's not how I would do that.
Since the idea behind project.el was to create an abstraction that
third-party project packages could hook into (Projectile, most
prominently), I think making such an emphasis is counter-productive.
So I'd rather put it in its own section, rather than create an
impression that a project = VC repository. But I see how this creates a
tension between giving practical advice and saying that "things might
change a little as soon as you install a third-party package". Or enable
ede-mode, I suppose.
BTW, there is a planned cleanup in the API that I've been thinking on
for a while. I've been hoping to get it into Emacs 27, but a number of
other issues conspired to take up the free time, so I guess it'll only
be there in Emacs 28. So I'm not sure to which extent we should document
this package in Emacs 27. But the two aforementioned commands will
remain there, of course.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Fri, 06 Mar 2020 17:13:02 GMT)
Full text and
rfc822 format available.
Message #225 received at 12492 <at> debbugs.gnu.org (full text, mbox):
> Cc: 12492 <at> debbugs.gnu.org, larsi <at> gnus.org, juri <at> linkov.net
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Fri, 6 Mar 2020 18:53:39 +0200
>
> On 06.03.2020 18:14, Eli Zaretskii wrote:
> > So if we want to document the above two commands, we should do that in
> > the VC chapter, and talk about "project" meaning the current VCS
> > repository?
>
> Umm, that's not how I would do that.
>
> Since the idea behind project.el was to create an abstraction that
> third-party project packages could hook into (Projectile, most
> prominently), I think making such an emphasis is counter-productive.
>
> So I'd rather put it in its own section, rather than create an
> impression that a project = VC repository. But I see how this creates a
> tension between giving practical advice and saying that "things might
> change a little as soon as you install a third-party package". Or enable
> ede-mode, I suppose.
Exactly. For starters, how do you explain what a "project" is, when
the only example we can give is a repository?
I see nothing wrong with having this in the VC chapter for now; we can
always move it out later, when there are other back-ends. The
placement of sections in chapters of the manual is neither sacred nor
final.
> BTW, there is a planned cleanup in the API that I've been thinking on
> for a while. I've been hoping to get it into Emacs 27, but a number of
> other issues conspired to take up the free time, so I guess it'll only
> be there in Emacs 28. So I'm not sure to which extent we should document
> this package in Emacs 27. But the two aforementioned commands will
> remain there, of course.
I was only thinking about the commands, so the API change should not
be an issue.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Fri, 06 Mar 2020 22:35:02 GMT)
Full text and
rfc822 format available.
Message #228 received at 12492 <at> debbugs.gnu.org (full text, mbox):
On 06.03.2020 19:12, Eli Zaretskii wrote:
> For starters, how do you explain what a "project" is, when
> the only example we can give is a repository?
The way we should either way: with a higher level description.
Something like:
A project is set of files. Which we usually define through a list of
directories where the files reside, and a list of ignore rules that
exclude some files within said directories from being considered a part
of the project.
The above information is provided by the project backend that is in use.
The main backend supplied with Emacs is based on VC, and it uses
repository markers and associated ignore files (as well as the
`project-vc-ignores` variable).
> I see nothing wrong with having this in the VC chapter for now; we can
> always move it out later, when there are other back-ends. The
> placement of sections in chapters of the manual is neither sacred nor
> final.
As long as it doesn't say that a project is a VC repository.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Sat, 07 Mar 2020 07:38:01 GMT)
Full text and
rfc822 format available.
Message #231 received at 12492 <at> debbugs.gnu.org (full text, mbox):
> Cc: 12492 <at> debbugs.gnu.org, larsi <at> gnus.org, juri <at> linkov.net
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Sat, 7 Mar 2020 00:34:36 +0200
>
> On 06.03.2020 19:12, Eli Zaretskii wrote:
> > For starters, how do you explain what a "project" is, when
> > the only example we can give is a repository?
>
> The way we should either way: with a higher level description.
>
> Something like:
>
> A project is set of files. Which we usually define through a list of
> directories where the files reside, and a list of ignore rules that
> exclude some files within said directories from being considered a part
> of the project.
This is too abstract: it doesn't tell the reader how to "create a
project". Without knowing that, all the rest of the information about
the commands is mostly useless, because the commands cannot be used in
practice.
> The above information is provided by the project backend that is in use.
> The main backend supplied with Emacs is based on VC, and it uses
> repository markers and associated ignore files (as well as the
> `project-vc-ignores` variable).
Still falls short of clarifying the above.
We are talking about the Emacs User manual. The project API is
extensible on the Lisp programmer level, not on the user level. So
the user-level information should describe what is available to users;
too much abstractions is inappropriate.
> > I see nothing wrong with having this in the VC chapter for now; we can
> > always move it out later, when there are other back-ends. The
> > placement of sections in chapters of the manual is neither sacred nor
> > final.
>
> As long as it doesn't say that a project is a VC repository.
But with the VC back-end, it really is, isn't it? Then why not say
that the type of project supported by Emacs OOTB is a VCS repository?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Sun, 08 Mar 2020 00:50:02 GMT)
Full text and
rfc822 format available.
Message #234 received at 12492 <at> debbugs.gnu.org (full text, mbox):
On 07.03.2020 9:37, Eli Zaretskii wrote:
>> Something like:
>>
>> A project is set of files. Which we usually define through a list of
>> directories where the files reside, and a list of ignore rules that
>> exclude some files within said directories from being considered a part
>> of the project.
>
> This is too abstract: it doesn't tell the reader how to "create a
> project". Without knowing that, all the rest of the information about
> the commands is mostly useless, because the commands cannot be used in
> practice.
We don't provide a command to create a project, and we probably won't in
the future either.
I disagree about useless, since most users deal with existing projects
99% of the time. But I can see how a manual would seem incomplete
without such information. It doesn't have to be contained in the
definition of "what is a project", however.
> We are talking about the Emacs User manual. The project API is
> extensible on the Lisp programmer level, not on the user level. So
> the user-level information should describe what is available to users;
> too much abstractions is inappropriate.
Still, I'd prefer if it did that without conflating the terms.
>>> I see nothing wrong with having this in the VC chapter for now; we can
>>> always move it out later, when there are other back-ends. The
>>> placement of sections in chapters of the manual is neither sacred nor
>>> final.
>>
>> As long as it doesn't say that a project is a VC repository.
>
> But with the VC back-end, it really is, isn't it?
The relation is reverse (all repositories are projects, but not all
projects are repositories), but yes.
> Then why not say
> that the type of project supported by Emacs OOTB is a VCS repository?
Sure, we can say that. Maybe also add an adjective like "main" (the main
type of project ...), since EDE is also a part of Emacs.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Sun, 08 Mar 2020 01:06:01 GMT)
Full text and
rfc822 format available.
Message #237 received at 12492 <at> debbugs.gnu.org (full text, mbox):
>> Regarding vc-dir, I see no better name than 'vc-dir-default'
>> meaning that it uses root-dir by default.
>
> But the question is not what the default is (which will be VC root), but
> whether to prompt the user or use that value right away.
>
> So I was thinking more along the lines of vc-dir-prompt-p. Or, more
> verbosely, vc-dir-prompt-for-directory.
'vc-dir-default' was intended both as option name and command name,
so users can choose either to customize it, or bind 'C-x v d' to command.
'vc-dir-root' may be a better name.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Sun, 08 Mar 2020 09:58:01 GMT)
Full text and
rfc822 format available.
Message #240 received at 12492 <at> debbugs.gnu.org (full text, mbox):
On 08.03.2020 2:47, Juri Linkov wrote:
> 'vc-dir-default' was intended both as option name and command name,
> so users can choose either to customize it, or bind 'C-x v d' to command.
>
> 'vc-dir-root' may be a better name.
I think both of these work better as the command name. I also like
vc-dir-root best.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Mon, 09 Mar 2020 17:25:01 GMT)
Full text and
rfc822 format available.
Message #243 received at 12492 <at> debbugs.gnu.org (full text, mbox):
> Cc: 12492 <at> debbugs.gnu.org, larsi <at> gnus.org, juri <at> linkov.net
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Sun, 8 Mar 2020 02:49:24 +0200
>
> >> A project is set of files. Which we usually define through a list of
> >> directories where the files reside, and a list of ignore rules that
> >> exclude some files within said directories from being considered a part
> >> of the project.
> >
> > This is too abstract: it doesn't tell the reader how to "create a
> > project". Without knowing that, all the rest of the information about
> > the commands is mostly useless, because the commands cannot be used in
> > practice.
>
> We don't provide a command to create a project, and we probably won't in
> the future either.
I don't think having commands to create a project is really
necessary. If a project can be "created" by some external command,
like by placing some special file in the project root, or even by
defining a few Emacs variables, that is enough.
> I disagree about useless, since most users deal with existing projects
> 99% of the time.
In Emacs? Can you give examples of such existing projects, and how
users could use the commands we are discussing with those projects?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Mon, 09 Mar 2020 22:48:01 GMT)
Full text and
rfc822 format available.
Message #246 received at 12492 <at> debbugs.gnu.org (full text, mbox):
On 09.03.2020 19:24, Eli Zaretskii wrote:
> I don't think having commands to create a project is really
> necessary. If a project can be "created" by some external command,
> like by placing some special file in the project root, or even by
> defining a few Emacs variables, that is enough.
'git init' would do the trick. No extra files (for the VC project
backend, at least), nor having to change any variables.
>> I disagree about useless, since most users deal with existing projects
>> 99% of the time.
>
> In Emacs? Can you give examples of such existing projects,
An Emacs repository checkout itself, for instance? Or about any other
project where VC recognizes a root.
> and how
> users could use the commands we are discussing with those projects?
With 'M-x project-find-file' or 'M-x project-find-regexp' while being
inside the directory tree of any of such projects.
I thought you've tried and used these commands already.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Tue, 10 Mar 2020 18:19:01 GMT)
Full text and
rfc822 format available.
Message #249 received at 12492 <at> debbugs.gnu.org (full text, mbox):
> Cc: 12492 <at> debbugs.gnu.org, larsi <at> gnus.org, juri <at> linkov.net
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Tue, 10 Mar 2020 00:47:36 +0200
>
> On 09.03.2020 19:24, Eli Zaretskii wrote:
>
> > I don't think having commands to create a project is really
> > necessary. If a project can be "created" by some external command,
> > like by placing some special file in the project root, or even by
> > defining a few Emacs variables, that is enough.
>
> 'git init' would do the trick. No extra files (for the VC project
> backend, at least), nor having to change any variables.
>
> >> I disagree about useless, since most users deal with existing projects
> >> 99% of the time.
> >
> > In Emacs? Can you give examples of such existing projects,
>
> An Emacs repository checkout itself, for instance? Or about any other
> project where VC recognizes a root.
>
> > and how
> > users could use the commands we are discussing with those projects?
>
> With 'M-x project-find-file' or 'M-x project-find-regexp' while being
> inside the directory tree of any of such projects.
OK, my misunderstanding: I asked all those questions because I thought
you were saying these commands are used with projects other than VC
projects.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Wed, 11 Mar 2020 13:37:01 GMT)
Full text and
rfc822 format available.
Message #252 received at 12492 <at> debbugs.gnu.org (full text, mbox):
On 10.03.2020 20:18, Eli Zaretskii wrote:
> OK, my misunderstanding: I asked all those questions because I thought
> you were saying these commands are used with projects other than VC
> projects.
That's the main purpose of this package: to have an extension point that
allows us to write commands in such a way that would work with
potentially any kind of projects, as long as the [third-party] project
implementation makes an effort to interface.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Wed, 11 Mar 2020 16:15:02 GMT)
Full text and
rfc822 format available.
Message #255 received at 12492 <at> debbugs.gnu.org (full text, mbox):
> Cc: 12492 <at> debbugs.gnu.org, larsi <at> gnus.org, juri <at> linkov.net
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Wed, 11 Mar 2020 15:35:58 +0200
>
> On 10.03.2020 20:18, Eli Zaretskii wrote:
> > OK, my misunderstanding: I asked all those questions because I thought
> > you were saying these commands are used with projects other than VC
> > projects.
>
> That's the main purpose of this package: to have an extension point that
> allows us to write commands in such a way that would work with
> potentially any kind of projects, as long as the [third-party] project
> implementation makes an effort to interface.
Of course, but this loses context: we were discussing whether and how
to document these commands in the user manual. For that manual,
extensions that exist only in theory are not really relevant.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Wed, 11 Mar 2020 23:55:01 GMT)
Full text and
rfc822 format available.
Message #258 received at 12492 <at> debbugs.gnu.org (full text, mbox):
On 11.03.2020 18:14, Eli Zaretskii wrote:
>> That's the main purpose of this package: to have an extension point that
>> allows us to write commands in such a way that would work with
>> potentially any kind of projects, as long as the [third-party] project
>> implementation makes an effort to interface.
>
> Of course, but this loses context: we were discussing whether and how
> to document these commands in the user manual. For that manual,
> extensions that exist only in theory are not really relevant.
What if an extension materializes right after Emacs 27's release?
E.g. it's not hard to write a good project.el backend that uses
Projectile (a popular third-party package for project-related
functionality). Actually, a couple of ad-hoc integrations are already
floating around. I should probably write [a better] one myself. And
right after the release seems like a good time.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Thu, 12 Mar 2020 14:58:01 GMT)
Full text and
rfc822 format available.
Message #261 received at 12492 <at> debbugs.gnu.org (full text, mbox):
> Cc: 12492 <at> debbugs.gnu.org, larsi <at> gnus.org, juri <at> linkov.net
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Thu, 12 Mar 2020 01:54:30 +0200
>
> On 11.03.2020 18:14, Eli Zaretskii wrote:
>
> >> That's the main purpose of this package: to have an extension point that
> >> allows us to write commands in such a way that would work with
> >> potentially any kind of projects, as long as the [third-party] project
> >> implementation makes an effort to interface.
> >
> > Of course, but this loses context: we were discussing whether and how
> > to document these commands in the user manual. For that manual,
> > extensions that exist only in theory are not really relevant.
>
> What if an extension materializes right after Emacs 27's release?
How can we describe such an extension in advance in the user manual?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Fri, 13 Mar 2020 12:25:02 GMT)
Full text and
rfc822 format available.
Message #264 received at 12492 <at> debbugs.gnu.org (full text, mbox):
On 12.03.2020 16:57, Eli Zaretskii wrote:
>>> Of course, but this loses context: we were discussing whether and how
>>> to document these commands in the user manual. For that manual,
>>> extensions that exist only in theory are not really relevant.
>>
>> What if an extension materializes right after Emacs 27's release?
>
> How can we describe such an extension in advance in the user manual?
Maybe by using a higher-level language like I suggested earlier in this
discussions.
Projects are this and that, you can use commands xx and yy whn inside a
project. If the current buffer does not belong to a project, you will be
prompted for a directory to look in. The main project type supported by
Emacs OOB is VC repositories.
I'm not insisting or anything, but that's how I'd do it. How do we
document completion-at-point, for instance? It's also extensible.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Fri, 13 Mar 2020 14:32:02 GMT)
Full text and
rfc822 format available.
Message #267 received at 12492 <at> debbugs.gnu.org (full text, mbox):
> Cc: 12492 <at> debbugs.gnu.org, larsi <at> gnus.org, juri <at> linkov.net
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Fri, 13 Mar 2020 14:23:51 +0200
>
> > How can we describe such an extension in advance in the user manual?
>
> Maybe by using a higher-level language like I suggested earlier in this
> discussions.
That'd be some vague general principle, not a documentation of
specific commands.
> Projects are this and that, you can use commands xx and yy whn inside a
> project. If the current buffer does not belong to a project, you will be
> prompted for a directory to look in. The main project type supported by
> Emacs OOB is VC repositories.
Sorry, not in my book. This text begs gobs of questions for which
there will be no answers. User manuals shouldn't do that.
> How do we document completion-at-point, for instance? It's also
> extensible.
We describe the available variants. Please take a look at the
relevant text (in "Symbol Completion" and in "Shell Mode").
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Sun, 15 Mar 2020 21:58:01 GMT)
Full text and
rfc822 format available.
Message #270 received at 12492 <at> debbugs.gnu.org (full text, mbox):
On 13.03.2020 16:30, Eli Zaretskii wrote:
>> Cc: 12492 <at> debbugs.gnu.org, larsi <at> gnus.org, juri <at> linkov.net
>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>> Date: Fri, 13 Mar 2020 14:23:51 +0200
>>
>>> How can we describe such an extension in advance in the user manual?
>>
>> Maybe by using a higher-level language like I suggested earlier in this
>> discussions.
>
> That'd be some vague general principle, not a documentation of
> specific commands.
Surely you're not going to say that e.g. project-find-file calls 'git
ls-files' to enumerate a project's files in the most usual case, or that
project-find-regexp uses Grep under the hood?
Keeping a certain level of abstraction is a good thing.
>> Projects are this and that, you can use commands xx and yy whn inside a
>> project. If the current buffer does not belong to a project, you will be
>> prompted for a directory to look in. The main project type supported by
>> Emacs OOB is VC repositories.
>
> Sorry, not in my book. This text begs gobs of questions for which
> there will be no answers. User manuals shouldn't do that.
Could you give an example of a couple of such questions?
>> How do we document completion-at-point, for instance? It's also
>> extensible.
>
> We describe the available variants. Please take a look at the
> relevant text (in "Symbol Completion" and in "Shell Mode").
So it says that completion-at-point is "flexible", and that's basically
it on the subject of extensibility (IOW, the possibility of different
behaviors in different major modes)?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Mon, 16 Mar 2020 03:26:02 GMT)
Full text and
rfc822 format available.
Message #273 received at 12492 <at> debbugs.gnu.org (full text, mbox):
> Cc: 12492 <at> debbugs.gnu.org, larsi <at> gnus.org, juri <at> linkov.net
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Sun, 15 Mar 2020 23:57:11 +0200
>
> On 13.03.2020 16:30, Eli Zaretskii wrote:
> >> Cc: 12492 <at> debbugs.gnu.org, larsi <at> gnus.org, juri <at> linkov.net
> >> From: Dmitry Gutov <dgutov <at> yandex.ru>
> >> Date: Fri, 13 Mar 2020 14:23:51 +0200
> >>
> >>> How can we describe such an extension in advance in the user manual?
> >>
> >> Maybe by using a higher-level language like I suggested earlier in this
> >> discussions.
> >
> > That'd be some vague general principle, not a documentation of
> > specific commands.
>
> Surely you're not going to say that e.g. project-find-file calls 'git
> ls-files' to enumerate a project's files in the most usual case, or that
> project-find-regexp uses Grep under the hood?
We keep losing context, and this keep looping without any hope. I
hate to tell people please re-read the past discussion, but there's
nothing else I can say here, because you keep repeating the same
questions and I keep giving the same answers.
> >> Projects are this and that, you can use commands xx and yy whn inside a
> >> project. If the current buffer does not belong to a project, you will be
> >> prompted for a directory to look in. The main project type supported by
> >> Emacs OOB is VC repositories.
> >
> > Sorry, not in my book. This text begs gobs of questions for which
> > there will be no answers. User manuals shouldn't do that.
>
> Could you give an example of a couple of such questions?
I already did, up-thread.
> >> How do we document completion-at-point, for instance? It's also
> >> extensible.
> >
> > We describe the available variants. Please take a look at the
> > relevant text (in "Symbol Completion" and in "Shell Mode").
>
> So it says that completion-at-point is "flexible", and that's basically
> it on the subject of extensibility (IOW, the possibility of different
> behaviors in different major modes)?
No, that's not what the text said, at least not the text I read there.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Mon, 16 Mar 2020 08:04:01 GMT)
Full text and
rfc822 format available.
Message #276 received at 12492 <at> debbugs.gnu.org (full text, mbox):
On 16.03.2020 5:25, Eli Zaretskii wrote:
> We keep losing context, and this keep looping without any hope. I
> hate to tell people please re-read the past discussion, but there's
> nothing else I can say here, because you keep repeating the same
> questions and I keep giving the same answers.
In that case, let's stop here. We can continue if/when you decide to add
the manual entries upon discussion.
I hope that I made doing that that at least a little easier in the
preceding discussion.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Sat, 21 Mar 2020 11:29:02 GMT)
Full text and
rfc822 format available.
Message #279 received at 12492 <at> debbugs.gnu.org (full text, mbox):
> Cc: 12492 <at> debbugs.gnu.org, larsi <at> gnus.org, juri <at> linkov.net
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Mon, 16 Mar 2020 10:02:58 +0200
>
> On 16.03.2020 5:25, Eli Zaretskii wrote:
> > We keep losing context, and this keep looping without any hope. I
> > hate to tell people please re-read the past discussion, but there's
> > nothing else I can say here, because you keep repeating the same
> > questions and I keep giving the same answers.
>
> In that case, let's stop here. We can continue if/when you decide to add
> the manual entries upon discussion.
Done, please take a look. (I also found some issues/problems with
project.el itself, and fixed what I found.)
> I hope that I made doing that that at least a little easier in the
> preceding discussion.
You did, thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12492; Package
emacs.
(Mon, 30 Mar 2020 02:36:24 GMT)
Full text and
rfc822 format available.
Message #282 received at 12492 <at> debbugs.gnu.org (full text, mbox):
>> 'vc-dir-default' was intended both as option name and command name,
>> so users can choose either to customize it, or bind 'C-x v d' to command.
>> 'vc-dir-root' may be a better name.
>
> I think both of these work better as the command name. I also like
> vc-dir-root best.
vc-dir-root is now pushed to master without keybinding as discussed
in bug#34949.
Please close this report if you think everything is done here.
Reply sent
to
Dmitry Gutov <dgutov <at> yandex.ru>:
You have taken responsibility.
(Mon, 30 Mar 2020 02:36:50 GMT)
Full text and
rfc822 format available.
Notification sent
to
Dmitry Gutov <dgutov <at> yandex.ru>:
bug acknowledged by developer.
(Mon, 30 Mar 2020 02:36:50 GMT)
Full text and
rfc822 format available.
Message #287 received at 12492-done <at> debbugs.gnu.org (full text, mbox):
On 29.03.2020 02:08, Juri Linkov wrote:
> vc-dir-root is now pushed to master without keybinding as discussed
> in bug#34949.
Yes, it's all good. Thanks Juri!
> Please close this report if you think everything is done here.
I remembered why I called it vc-dir-quick, though: aside from using the
root, it avoids refreshing pre-existing vc-dir buffer, which was an
important improvement for me at the time (these days--less so). But this
can be introduced as an option in a separate discussion.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Mon, 27 Apr 2020 11:24:11 GMT)
Full text and
rfc822 format available.
This bug report was last modified 5 years and 4 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.