GNU bug report logs - #54228
29.0.50; project.el: Support local projects

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 54228 in the body.
You can then email your comments to 54228 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: Manuel Uberti <manuel.uberti <at> inventati.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; project.el: Support local projects
Date: Thu, 3 Mar 2022 08:15:06 +0100

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

Hi,

I attached a small patch which simply adds to project.el some code I
have been using for a while for projects that I do not intend to handle with Git.

The gist of it is that adding a `.project` (empty) file to the root
directory of your project make it possible for commands such as 'C-x p f' to 
work on it.

Is this of any interest?

-- 
Manuel Uberti
www.manueluberti.eu

[0001-Support-local-projects.patch (text/x-patch, attachment)]

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

From: Rudolf Schlatte <rudi <at> constantly.at>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#54228: 29.0.50; project.el: Support local projects
Date: Thu, 03 Mar 2022 13:36:44 +0100

Manuel Uberti via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs <at> gnu.org> writes:

> Hi,
>
> I attached a small patch which simply adds to project.el some code I
> have been using for a while for projects that I do not intend to handle with Git.
>
> The gist of it is that adding a `.project` (empty) file to the root
> directory of your project make it possible for commands such as 'C-x p f' to
> work on it.

The eclipse IDE uses files named `.project' for something-or-other.
Maybe naming the file `.emacs-project-root' or something similarly
unique is safer.

Rudi

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

From: Daniel Martín <mardani29 <at> yahoo.es>
To: Manuel Uberti via "Bug reports for GNU Emacs, the Swiss army knife of
 text editors" <bug-gnu-emacs <at> gnu.org>
Cc: Manuel Uberti <manuel.uberti <at> inventati.org>, 54228 <at> debbugs.gnu.org
Subject: Re: bug#54228: 29.0.50; project.el: Support local projects
Date: Fri, 04 Mar 2022 18:48:30 +0100

Manuel Uberti via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs <at> gnu.org> writes:

> Hi,
>
> I attached a small patch which simply adds to project.el some code I
> have been using for a while for projects that I do not intend to handle with Git.
>
> The gist of it is that adding a `.project` (empty) file to the root
> directory of your project make it possible for commands such as 'C-x p
> f' to work on it.
>
> Is this of any interest?
>

I use similar code in my config.  It's specially useful for monorepos,
where there is only one big .git folder, but multiple projects that you
want to handle separately.

If we want to contribute this to project.el, I wonder if it makes sense
to generalize it a little bit by making ".project" the default value of
a customization variable.  That'd avoid the name clash with some Eclipse
files.  We could also detect files from common build systems, but I
don't know if that would be out of scope for the rather minimalist
project.el (vs projectile.el, for example).

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

From: Manuel Uberti <manuel.uberti <at> inventati.org>
To: Daniel Martín <mardani29 <at> yahoo.es>,
 Manuel Uberti via Bug reports for GNU "Emacs," the Swiss army knife of text
 editors <bug-gnu-emacs <at> gnu.org>
Cc: 54228 <at> debbugs.gnu.org
Subject: Re: bug#54228: 29.0.50; project.el: Support local projects
Date: Fri, 4 Mar 2022 19:15:28 +0100

On 04/03/22 18:48, Daniel Martín wrote:
> I use similar code in my config.  It's specially useful for monorepos,
> where there is only one big .git folder, but multiple projects that you
> want to handle separately.

In my case it's super useful for projects where I do not have VC involved, of 
which I have a few. I just can't live without project.el facilities in my daily 
Emacs any more. :)

> If we want to contribute this to project.el, I wonder if it makes sense
> to generalize it a little bit by making ".project" the default value of
> a customization variable.  That'd avoid the name clash with some Eclipse
> files.  We could also detect files from common build systems, but I
> don't know if that would be out of scope for the rather minimalist
> project.el (vs projectile.el, for example).

I did not think about making ".project" the value of a defcustom, because I do 
not use anything that relies on ".project" files. But if as you say there is a 
chance of name clashing, then yes, making customizable seems about right.

I'd wait for Dmitry to jump in on this. I'd like to hear his opinion as well.

-- 
Manuel Uberti
www.manueluberti.eu

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Manuel Uberti <manuel.uberti <at> inventati.org>, mardani29 <at> yahoo.es,
 54228 <at> debbugs.gnu.org, Rudolf Schlatte <rudi <at> constantly.at>
Subject: Re: bug#54228: 29.0.50; project.el: Support local projects
Date: Sat, 5 Mar 2022 03:31:18 +0200

Hey folks,

Check out https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41572, of which 
this is a duplicate.

If the discussion seems daunting (and it is overly long), you can start 
at https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41572#82.

Comments welcome.

On 04.03.2022 20:15, Manuel Uberti via Bug reports for GNU Emacs, the 
Swiss army knife of text editors wrote:
> On 04/03/22 18:48, Daniel Martín wrote:
>> I use similar code in my config.  It's specially useful for monorepos,
>> where there is only one big .git folder, but multiple projects that you
>> want to handle separately.
> 
> In my case it's super useful for projects where I do not have VC 
> involved, of which I have a few. I just can't live without project.el 
> facilities in my daily Emacs any more. :)
> 
>> If we want to contribute this to project.el, I wonder if it makes sense
>> to generalize it a little bit by making ".project" the default value of
>> a customization variable.  That'd avoid the name clash with some Eclipse
>> files.  We could also detect files from common build systems, but I
>> don't know if that would be out of scope for the rather minimalist
>> project.el (vs projectile.el, for example).
> 
> I did not think about making ".project" the value of a defcustom, 
> because I do not use anything that relies on ".project" files. But if as 
> you say there is a chance of name clashing, then yes, making 
> customizable seems about right.
> 
> I'd wait for Dmitry to jump in on this. I'd like to hear his opinion as 
> well.

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

From: Manuel Uberti <manuel.uberti <at> inventati.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>, mardani29 <at> yahoo.es,
 54228 <at> debbugs.gnu.org, Rudolf Schlatte <rudi <at> constantly.at>
Subject: Re: bug#54228: 29.0.50; project.el: Support local projects
Date: Sat, 5 Mar 2022 08:42:48 +0100

On 05/03/22 02:31, Dmitry Gutov wrote:
> Check out https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41572, of which this is 
> a duplicate.
> 
> If the discussion seems daunting (and it is overly long), you can start at 
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41572#82.
> 
> Comments welcome.

Thanks for the link, this ticket can be closed then.

As for #41572, I see that adding support for local/plain/novc projects is not as 
simple as I thought.

As mentioned in that bug, probably I didn't see the possible implications of 
this change because my novc projects are quite small and so, for instance, 
`find' performs just fine within them. Also, I do not need to ignore anything in 
particular in these projects, so I didn't take that into consideration either.

To be more specific: these projects are not related to a programming language, 
so no build tools are involved. Just plain Markdown files and PDFs. They may 
involve LaTeX sometimes, but supporting project.el here could be something 
AUCTeX can take care of?

I don't know how much I can add on #41572. It looks like what I need is a small 
subset of not so trivial changes. For my specific use case, then, it makes 
little sense to change project.el.

-- 
Manuel Uberti
www.manueluberti.eu

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

From: Rudolf Adamkovič <salutis <at> me.com>
To: Daniel Martín <mardani29 <at> yahoo.es>, 54228 <at> debbugs.gnu.org
Cc: manuel.uberti <at> inventati.org
Subject: Re: bug#54228: 29.0.50; project.el: Support local projects
Date: Sat, 05 Mar 2022 17:15:01 +0100

Daniel Martín via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs <at> gnu.org> writes:

> I use similar code in my config.  It's specially useful for monorepos,
> where there is only one big .git folder, but multiple projects that you
> want to handle separately.

+1 vote for this feature from me.  I, too, have similar code in my Emacs
config, and it enables me to survive at work where we have a big
repository in which I often need to "zoom in" to a sub-project.

> If we want to contribute this to project.el, I wonder if it makes
> sense to generalize it a little bit by making ".project" the default
> value of a customization variable.

+1 and I also think that the customization variable should exist as a
list so that one can specify more than one "project stamp" file name.

Rudy
-- 
"Programming reliably -- must be an activity of an undeniably
mathematical nature […] You see, mathematics is about thinking, and
doing mathematics is always trying to think as well as possible."
-- Edsger W. Dijkstra, 1981

Rudolf Adamkovič <salutis <at> me.com> [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

Previous Next

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