GNU bug report logs - #77974
Manual updates for the VC-aware project backend

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 77974 in the body.
You can then email your comments to 77974 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: bug-gnu-emacs <at> gnu.org
Subject: Manual updates for the VC-aware project backend
Date: Tue, 22 Apr 2025 00:51:30 +0300

[Message part 1 (text/plain, inline)]

Tags: patch

Here are some proposed updates, which create a new node for this backend 
and list some of the options that were until now not mentioned in the 
manual.

Feedback welcome on the general structure (do we want the new node in 
that place?) and the phrasing of the new text as well.

[project-vc-manual-updates.diff (text/x-patch, attachment)]

Message #8 received at 77974 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: 77974 <at> debbugs.gnu.org
Subject: Re: bug#77974: Manual updates for the VC-aware project backend
Date: Tue, 22 Apr 2025 14:58:07 +0300

> Date: Tue, 22 Apr 2025 00:51:30 +0300
> From: Dmitry Gutov <dmitry <at> gutov.dev>
> 
> Here are some proposed updates, which create a new node for this backend 
> and list some of the options that were until now not mentioned in the 
> manual.
> 
> Feedback welcome on the general structure (do we want the new node in 
> that place?) and the phrasing of the new text as well.

Thanks.

This node should probably be the last in its parent node, not the
first one, because it describes a specific project backend while the
rest of the section describes backend-agnostic features.

I'm also not sure why these 5 user options are deemed important enough
to be in the manual, while the other 14 defined in project.el aren't.
E.g., is project-vc-merge-submodules (which seems to be specific to
Git, but its name doesn't say so?) really important enough to be in
the manual?

> +@node VC-Aware Project Backend

Index entry leading to this node is missing here.  Think about a
reader who wants to find this quickly without knowing the exact name
of the node.

> +This backend is used by default.

This sentence confused me.  What does it mean for a backend to be used
by default?  This should be explained, I think, if we consider this
backend important enough to be described.

> +@defopt project-vc-include-untracked
> +``untracked'' files are considered to be part of the project.  To change
     ^^^^^^^^^^^
Sentences should start with capital letters.

Also, when you introduce new terminology, it is best to use @dfn
instead of literal quotes, and also have an indexing command for that
terminology.

> +that, you can customize this variable to nil.
> +@end defopt
> +
> +@defopt project-vc-ignores
> +Using this variable you can add more ignore patterns to the project, to
> +exclude more files from the project's file listing.  The value is a list
> +of glob strings.  They can match both regular files and directories.  To
> +anchor an entry to the project root, start it with @code{./}.  To match
> +directories only, end it with @code{/}.
> +@end defopt
> +
> +@defopt project-vc-merge-submodules
> +By default all submodules inside a Git project are considered to be part
> +of the parent repository's project.  Customize this to nil to make them
> +separate projects.
> +@end defopt
> +
> +Each element is either a base file name or a glob pattern for such.
> +
> +Example values: @samp{".dir-locals.el"}, @samp{"package.json"},
> +@samp{"requirements.txt}, @samp{"*.gemspec"}.

Since these are file names, it is better to use @file markup and lose
the quotes.

If you decide to install this, don't forget to update the @detailmenu
in emacs.texi.

Message #11 received at 77974 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77974 <at> debbugs.gnu.org
Subject: Re: bug#77974: Manual updates for the VC-aware project backend
Date: Tue, 22 Apr 2025 20:04:12 +0300

On 22/04/2025 14:58, Eli Zaretskii wrote:
>> Date: Tue, 22 Apr 2025 00:51:30 +0300
>> From: Dmitry Gutov <dmitry <at> gutov.dev>
>>
>> Here are some proposed updates, which create a new node for this backend
>> and list some of the options that were until now not mentioned in the
>> manual.
>>
>> Feedback welcome on the general structure (do we want the new node in
>> that place?) and the phrasing of the new text as well.
> 
> Thanks.
> 
> This node should probably be the last in its parent node, not the
> first one, because it describes a specific project backend while the
> rest of the section describes backend-agnostic features.

All right.

> I'm also not sure why these 5 user options are deemed important enough
> to be in the manual, while the other 14 defined in project.el aren't.

These are the options for the backend, which this aims to document.

Got a request to have 'project-vc-extra-root-markers' documented: 
https://github.com/buzztaiki/project-rootfile.el/issues/17#issuecomment-2816505984

Most of the other options added affect which files are contained in a 
project. The existing manual mentions project-vc-include-untracked 
already, and it seemed to make sense to add project-vc-ignores and 
project-vc-merge-submodules which also affect the fileset (and should be 
more popular than the former, IMO).

> E.g., is project-vc-merge-submodules (which seems to be specific to
> Git, but its name doesn't say so?) really important enough to be in
> the manual?

I don't really mind dropping this one, except for the fact that it's 
also among the options that affects the fileset.

Being Git-specific seems unimportant (99% of all projects use Git), but 
being specific to submodules might make it too specialized, I don't know.

>> +@node VC-Aware Project Backend
> 
> Index entry leading to this node is missing here.  Think about a
> reader who wants to find this quickly without knowing the exact name
> of the node.

Any suggestions for what it should say?

>> +This backend is used by default.
> 
> This sentence confused me.  What does it mean for a backend to be used
> by default?  This should be explained, I think, if we consider this
> backend important enough to be described.

Used out of the box. Without extra configuration necessary. Before any 
third-package uses the hook variable.

Which of the explanations sounds better?

>> +@defopt project-vc-include-untracked
>> +``untracked'' files are considered to be part of the project.  To change
>       ^^^^^^^^^^^
> Sentences should start with capital letters.
> 
> Also, when you introduce new terminology, it is best to use @dfn
> instead of literal quotes, and also have an indexing command for that
> terminology.

"Untracked" is a fairly common term to the VC subsystem and VC systems 
in general. It doesn't seem like it has a description in the manual, though.

>> +Each element is either a base file name or a glob pattern for such.
>> +
>> +Example values: @samp{".dir-locals.el"}, @samp{"package.json"},
>> +@samp{"requirements.txt}, @samp{"*.gemspec"}.
> 
> Since these are file names, it is better to use @file markup and lose
> the quotes.

Not exactly file names -- they are globs. The last one contains a 
wildcard, for example.

Should @file still be used?

> If you decide to install this, don't forget to update the @detailmenu
> in emacs.texi.

Thanks.

Message #14 received at 77974 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: 77974 <at> debbugs.gnu.org
Subject: Re: bug#77974: Manual updates for the VC-aware project backend
Date: Wed, 23 Apr 2025 14:17:43 +0300

> Date: Tue, 22 Apr 2025 20:04:12 +0300
> Cc: 77974 <at> debbugs.gnu.org
> From: Dmitry Gutov <dmitry <at> gutov.dev>
> 
> >> +@node VC-Aware Project Backend
> > 
> > Index entry leading to this node is missing here.  Think about a
> > reader who wants to find this quickly without knowing the exact name
> > of the node.
> 
> Any suggestions for what it should say?

Something simple and obvious.  I'd start with

  @cindex VC-aware project backend
  @cindex project backend, VC-aware

> >> +This backend is used by default.
> > 
> > This sentence confused me.  What does it mean for a backend to be used
> > by default?  This should be explained, I think, if we consider this
> > backend important enough to be described.
> 
> Used out of the box.

Aren't other backends available out of the box?  If not, I'd say

  This backend is part of Emacs and is enabled by default.  (Other
  backend may need installation of add-on packages and their proper
  configuration.)

> >> +@defopt project-vc-include-untracked
> >> +``untracked'' files are considered to be part of the project.  To change
> >       ^^^^^^^^^^^
> > Sentences should start with capital letters.
> > 
> > Also, when you introduce new terminology, it is best to use @dfn
> > instead of literal quotes, and also have an indexing command for that
> > terminology.
> 
> "Untracked" is a fairly common term to the VC subsystem and VC systems 
> in general.

That's beside the point (you don't explain what it means, presumably
because that is known well enough).  The important part is that this
is the first (or only) place where it is mentioned in the Emacs
manual.

> >> +Each element is either a base file name or a glob pattern for such.
> >> +
> >> +Example values: @samp{".dir-locals.el"}, @samp{"package.json"},
> >> +@samp{"requirements.txt}, @samp{"*.gemspec"}.
> > 
> > Since these are file names, it is better to use @file markup and lose
> > the quotes.
> 
> Not exactly file names -- they are globs. The last one contains a 
> wildcard, for example.
> 
> Should @file still be used?

Yes.  Glob patterns are file-name specifications, so @file is still
the best markup.

Message #17 received at 77974 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77974 <at> debbugs.gnu.org
Subject: Re: bug#77974: Manual updates for the VC-aware project backend
Date: Fri, 25 Apr 2025 03:27:29 +0300

On 23/04/2025 14:17, Eli Zaretskii wrote:
>> Date: Tue, 22 Apr 2025 20:04:12 +0300
>> Cc: 77974 <at> debbugs.gnu.org
>> From: Dmitry Gutov <dmitry <at> gutov.dev>
>>
>>>> +@node VC-Aware Project Backend
>>>
>>> Index entry leading to this node is missing here.  Think about a
>>> reader who wants to find this quickly without knowing the exact name
>>> of the node.
>>
>> Any suggestions for what it should say?
> 
> Something simple and obvious.  I'd start with
> 
>    @cindex VC-aware project backend
>    @cindex project backend, VC-aware

Very good.

>>>> +This backend is used by default.
>>>
>>> This sentence confused me.  What does it mean for a backend to be used
>>> by default?  This should be explained, I think, if we consider this
>>> backend important enough to be described.
>>
>> Used out of the box.
> 
> Aren't other backends available out of the box?

We have EDE as well, which adds itself to project-find-functions, but 
with lower priority and only when the ede package is loaded. So... 
however you want to phrase it.

> If not, I'd say
> 
>    This backend is part of Emacs and is enabled by default.  (Other
>    backend may need installation of add-on packages and their proper
>    configuration.)

"Installation of add-on packages and/or additional setup" perhaps would 
be more correct. After all some users create their own small backends 
(which isn't always advised, but still).

>>>> +@defopt project-vc-include-untracked
>>>> +``untracked'' files are considered to be part of the project.  To change
>>>        ^^^^^^^^^^^
>>> Sentences should start with capital letters.
>>>
>>> Also, when you introduce new terminology, it is best to use @dfn
>>> instead of literal quotes, and also have an indexing command for that
>>> terminology.
>>
>> "Untracked" is a fairly common term to the VC subsystem and VC systems
>> in general.
> 
> That's beside the point (you don't explain what it means, presumably
> because that is known well enough).  The important part is that this
> is the first (or only) place where it is mentioned in the Emacs
> manual.

Okay. Do we provide a definition inline? Or link to another node? Here's 
what Git says about it:

  Untracked files in Git are files that exist in your working directory
  but are not being tracked by Git, meaning they haven't been added to
  version control.

>>> Since these are file names, it is better to use @file markup and lose
>>> the quotes.
>>
>> Not exactly file names -- they are globs. The last one contains a
>> wildcard, for example.
>>
>> Should @file still be used?
> 
> Yes.  Glob patterns are file-name specifications, so @file is still
> the best markup.

Great.

Message #20 received at 77974 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: 77974 <at> debbugs.gnu.org
Subject: Re: bug#77974: Manual updates for the VC-aware project backend
Date: Fri, 25 Apr 2025 10:23:25 +0300

> Date: Fri, 25 Apr 2025 03:27:29 +0300
> Cc: 77974 <at> debbugs.gnu.org
> From: Dmitry Gutov <dmitry <at> gutov.dev>
> 
> >>> Also, when you introduce new terminology, it is best to use @dfn
> >>> instead of literal quotes, and also have an indexing command for that
> >>> terminology.
> >>
> >> "Untracked" is a fairly common term to the VC subsystem and VC systems
> >> in general.
> > 
> > That's beside the point (you don't explain what it means, presumably
> > because that is known well enough).  The important part is that this
> > is the first (or only) place where it is mentioned in the Emacs
> > manual.
> 
> Okay. Do we provide a definition inline? Or link to another node? Here's 
> what Git says about it:
> 
>    Untracked files in Git are files that exist in your working directory
>    but are not being tracked by Git, meaning they haven't been added to
>    version control.

If you want to explain what "untracked" mean, I think in this case I'd
go with a @footnote, and tell there what you quote from Git, but
without mentioning Git (because I believe all VCSes handle untracked
files the same).

Message #23 received at 77974 <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: 77974 <at> debbugs.gnu.org
Subject: Re: bug#77974: Manual updates for the VC-aware project backend
Date: Sun, 27 Apr 2025 13:12:49 +0800

Hello,

Thanks for this.

On Tue 22 Apr 2025 at 12:51am +03, Dmitry Gutov wrote:

>  @menu
> +* VC-Aware Project Backend:: Default project backend.
>  * Project File Commands::   Commands for handling project files.
>  * Project Buffer Commands:: Commands for handling project buffers.
>  * Switching Projects::      Switching between projects.
>  * Managing Projects::       Managing the project list file.
>  @end menu

I agree with Eli that it should probably go last, not just because the
other parts are backend-agnostic, but also because it is probably less
useful information to a new user than what comes before.

> +@node VC-Aware Project Backend
> +
> +This backend is used by default.  It determines the contents of the
> +project based on the VCS repository's configuration (if any), excluding
> +the ``ignored'' files from the output.

I'd prefer to avoid the scare quotes around both 'ignored' and
'untracked' (I dislike scare quotes almost as much as Eli dislikes the
passive voice ;)).

I think you can just say

    ... excluding files the VCS has been configured to ignore from its
    output.

> +It has some performance optimizations for listing the files with some of
> +the popular VCS systems (currently Git and Mercurial).
> +
> +@defopt project-vc-include-untracked
> +``untracked'' files are considered to be part of the project.  To change
> +that, you can customize this variable to nil.
> +@end defopt

We already have the "unregistered" state in VC.  How about using that?

    By default, files which are neither registered nor ignored are
    considered part of this proejct.  Customize this variable to nil to
    change that.

... possibly with a cross-reference to the definitions of the VC terms.

(And maybe we should rename the variable?)

-- 
Sean Whitton

Message #26 received at 77974 <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: 77974 <at> debbugs.gnu.org
Subject: Re: bug#77974: Manual updates for the VC-aware project backend
Date: Sun, 27 Apr 2025 13:14:41 +0800

Hello,

On Sun 27 Apr 2025 at 01:12pm +08, Sean Whitton wrote:

> I think you can just say
>
>     ... excluding files the VCS has been configured to ignore from its
>     output.

I meant

    ... excluding files the VCS has been configured to ignore.

-- 
Sean Whitton

Message #29 received at 77974 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: dmitry <at> gutov.dev, 77974 <at> debbugs.gnu.org
Subject: Re: bug#77974: Manual updates for the VC-aware project backend
Date: Sun, 27 Apr 2025 09:29:50 +0300

> Cc: 77974 <at> debbugs.gnu.org
> From: Sean Whitton <spwhitton <at> spwhitton.name>
> Date: Sun, 27 Apr 2025 13:12:49 +0800
> 
> > +@node VC-Aware Project Backend
> > +
> > +This backend is used by default.  It determines the contents of the
> > +project based on the VCS repository's configuration (if any), excluding
> > +the ``ignored'' files from the output.
> 
> I'd prefer to avoid the scare quotes around both 'ignored' and
> 'untracked' (I dislike scare quotes almost as much as Eli dislikes the
> passive voice ;)).

Then please get used to them: that's how we introduce terminology in
Texinfo.  (In HTML and printed output, there's no quotes; instead, the
term has slanted typeface.  But that cannot be used in Info output.)

There's nothing scary about introducing new terminology.

> I think you can just say
> 
>     ... excluding files the VCS has been configured to ignore from its
>     output.

I see no reason to avoid accepted terminology, because that makes the
text less clear and potentially more confusing.  Anyone who uses a VCS
knows what are ignored and untracked files; by contrast, "files the
VCS has been configured to ignore from its output" is both wordier and
less definitive.

Message #32 received at 77974 <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: dmitry <at> gutov.dev, 77974 <at> debbugs.gnu.org
Subject: Re: bug#77974: Manual updates for the VC-aware project backend
Date: Sun, 27 Apr 2025 15:48:32 +0800

Hello,

On Sun 27 Apr 2025 at 09:29am +03, Eli Zaretskii wrote:

> Then please get used to them: that's how we introduce terminology in
> Texinfo.  (In HTML and printed output, there's no quotes; instead, the
> term has slanted typeface.  But that cannot be used in Info output.)

TIL.  Thanks.  They are not scare quotes if they are replaced with
slanted text.

It can be used in *Info* on graphical frames just like how Gnus already
displays italics sometimes; I will see about enabling that for Info too.

>> I think you can just say
>>
>>     ... excluding files the VCS has been configured to ignore from its
>>     output.
>
> I see no reason to avoid accepted terminology, because that makes the
> text less clear and potentially more confusing.  Anyone who uses a VCS
> knows what are ignored and untracked files; by contrast, "files the
> VCS has been configured to ignore from its output" is both wordier and
> less definitive.

"files the VCS has been configured to ignore", not "files the VCS has
been configured to ignore from its output", to be clear.

I was just thinking that an untracked file is one the VCS is ignoring,
in a sense, but it has not been configured to ignore.

If we don't think we are going to confuse anyone by using the VC terms,
that's fine with me.

-- 
Sean Whitton

Message #35 received at 77974 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 77974 <at> debbugs.gnu.org
Subject: Re: bug#77974: Manual updates for the VC-aware project backend
Date: Mon, 28 Apr 2025 01:39:00 +0300

Hi!

On 27/04/2025 08:12, Sean Whitton wrote:

> On Tue 22 Apr 2025 at 12:51am +03, Dmitry Gutov wrote:
> 
>>   @menu
>> +* VC-Aware Project Backend:: Default project backend.
>>   * Project File Commands::   Commands for handling project files.
>>   * Project Buffer Commands:: Commands for handling project buffers.
>>   * Switching Projects::      Switching between projects.
>>   * Managing Projects::       Managing the project list file.
>>   @end menu
> 
> I agree with Eli that it should probably go last, not just because the
> other parts are backend-agnostic, but also because it is probably less
> useful information to a new user than what comes before.

This makes sense to me indeed, even though the backend itself will 
probably be relevant for >90% of the users who read that text.

>> +It has some performance optimizations for listing the files with some of
>> +the popular VCS systems (currently Git and Mercurial).
>> +
>> +@defopt project-vc-include-untracked
>> +``untracked'' files are considered to be part of the project.  To change
>> +that, you can customize this variable to nil.
>> +@end defopt
> 
> We already have the "unregistered" state in VC.  How about using that?
> 
>      By default, files which are neither registered nor ignored are
>      considered part of this proejct.  Customize this variable to nil to
>      change that.

"Neither registered nor ignored" sounds like the definition for 
"unregistered", actually.

Sounds good to me as a phrasing (might even be more accurate than the 
Git definition I quoted previously).

> ... possibly with a cross-reference to the definitions of the VC terms.

If there is a node to reference, happy to.

> (And maybe we should rename the variable?)

Doesn't seem worth the hassle for us and existing users, TBH.

Message #40 received at 77974-done <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77974-done <at> debbugs.gnu.org
Subject: Re: bug#77974: Manual updates for the VC-aware project backend
Date: Mon, 28 Apr 2025 01:53:31 +0300

Version: 31.1

On 25/04/2025 10:23, Eli Zaretskii wrote:
>> Date: Fri, 25 Apr 2025 03:27:29 +0300
>> Cc:77974 <at> debbugs.gnu.org
>> From: Dmitry Gutov<dmitry <at> gutov.dev>
>>
>>>>> Also, when you introduce new terminology, it is best to use @dfn
>>>>> instead of literal quotes, and also have an indexing command for that
>>>>> terminology.
>>>> "Untracked" is a fairly common term to the VC subsystem and VC systems
>>>> in general.
>>> That's beside the point (you don't explain what it means, presumably
>>> because that is known well enough).  The important part is that this
>>> is the first (or only) place where it is mentioned in the Emacs
>>> manual.
>> Okay. Do we provide a definition inline? Or link to another node? Here's
>> what Git says about it:
>>
>>     Untracked files in Git are files that exist in your working directory
>>     but are not being tracked by Git, meaning they haven't been added to
>>     version control.
> If you want to explain what "untracked" mean, I think in this case I'd
> go with a @footnote, and tell there what you quote from Git, but
> without mentioning Git (because I believe all VCSes handle untracked
> files the same).

Thank you, though it seems Sean's suggestion helped avoid using the 
footnote in that paragraph.

Other than that, pushed the patch in revision 568a4894a8d7cc61. I think 
it contains all the other improvements, but LMK is anything is amiss.

Message #43 received at 77974 <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: 77974 <at> debbugs.gnu.org
Subject: Re: bug#77974: Manual updates for the VC-aware project backend
Date: Mon, 28 Apr 2025 10:48:28 +0800

Hello,

On Mon 28 Apr 2025 at 01:39am +03, Dmitry Gutov wrote:

> "Neither registered nor ignored" sounds like the definition for
> "unregistered", actually.
>
> Sounds good to me as a phrasing (might even be more accurate than the Git
> definition I quoted previously).

Thanks.  I've tweaked the phrasing slightly.

>> ... possibly with a cross-reference to the definitions of the VC terms.
>
> If there is a node to reference, happy to.

Turns out there is not.  Hrm.

>> (And maybe we should rename the variable?)
>
> Doesn't seem worth the hassle for us and existing users, TBH.

I've added a FIXME to keep thinking about it
(hope it's okay with you for me to go ahead and add such a thing to
project.el, let me know if not).

My thinking is: if we have another very popular VCS in the future which
doesn't use the name "untracked", then falling back on our own existing
"unregistered" terminology to unify things would be better than using
Git and Hg's "untracked" in this one place.

-- 
Sean Whitton

Message #46 received at 77974 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 77974 <at> debbugs.gnu.org
Subject: Re: bug#77974: Manual updates for the VC-aware project backend
Date: Mon, 28 Apr 2025 16:10:37 +0300

On 28/04/2025 05:48, Sean Whitton wrote:
> Hello,
> 
> On Mon 28 Apr 2025 at 01:39am +03, Dmitry Gutov wrote:
> 
>> "Neither registered nor ignored" sounds like the definition for
>> "unregistered", actually.
>>
>> Sounds good to me as a phrasing (might even be more accurate than the Git
>> definition I quoted previously).
> 
> Thanks.  I've tweaked the phrasing slightly.

Thank you.

>>> (And maybe we should rename the variable?)
>>
>> Doesn't seem worth the hassle for us and existing users, TBH.
> 
> I've added a FIXME to keep thinking about it
> (hope it's okay with you for me to go ahead and add such a thing to
> project.el, let me know if not).
> 
> My thinking is: if we have another very popular VCS in the future which
> doesn't use the name "untracked", then falling back on our own existing
> "unregistered" terminology to unify things would be better than using
> Git and Hg's "untracked" in this one place.

Sure. That seems like a pretty distant future, though.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.