From: Eric Abrahamsen <eric@ericabrahamsen.net>
To: Matt <matt@excalamus.com>
Cc: "help-gnu-emacs" <help-gnu-emacs@gnu.org>
Subject: Re: Navigating Lisp data structures
Date: Wed, 07 Dec 2022 10:01:44 -0800 [thread overview]
Message-ID: <87mt7zm6t3.fsf@ericabrahamsen.net> (raw)
In-Reply-To: <184eac39ef5.10ef824861550048.9156825989194888863@excalamus.com> (Matt's message of "Tue, 06 Dec 2022 23:06:39 -0500")
Matt <matt@excalamus.com> writes:
> ---- On Sun, 04 Dec 2022 21:05:13 -0500 Eric Abrahamsen wrote ---
> > Wow, it looks like you're recreating complete project management
> > facilities from scratch! That's impressive, and also a bit terrifying.
>
> Yeah, pretty much :)
>
> I've been refactoring a package I wrote and have been using for a few
> years now, peut-gerer (https://codeberg.org/excalamus/peut-gerer). I
> found I'd written a handful of utilities sharing the loose theme of
> "project workflow management" and so packaged them up. I recall at the
> time project.el being largely undocumented (it seems to have an info
> entry now) and was, at least to me, incoherent. I'm glad to see it's
> been developed since then. I also found myself reading the projectile
> documentation trying to figure out how to do what I wanted instead of
> actually coding. Why spend 30 minutes reading when you could spend 30
> hours programming, right?
Ugh, I know that mindset...
> > Your adventurous spirit is to be commended, but you might _also_ look
> > into making use of more of Emacs' built-in facilities for this stuff.
> > Emacs has projects, and projects have `project-compile', which calls
> > `compile', and a bunch of the config above looks like it could be worked
> > into existing facilities.
>
> I agree, it looks like what I'm doing could be fit to project.el. I
> appreciate you mentioning it because I was able to steal some ideas
>>:) Unfortunately, I still find the documentation for project.el
> lacking. Specifically, there appears to be nothing about how to
> actually define a project. All the commands assume one exists. I'm on
> 28.2, though, so maybe the documentation and code is different on
> HEAD.
And like I said, it's all under very active development, and I think
will end up looking much different (and much more feature-complete) in a
few months' time. Personally I'm making the minimal effective use of
project.el (and eglot), and waiting for the dust to clear to invest more
time in customization. But I do think they appreciate hearing feature
requests and use cases.
prev parent reply other threads:[~2022-12-07 18:01 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-04 19:00 Navigating Lisp data structures Matt
2022-12-05 0:46 ` Joost Kremers
2022-12-06 15:36 ` Matt
2022-12-05 2:05 ` Eric Abrahamsen
2022-12-07 4:06 ` Matt
2022-12-07 18:01 ` Eric Abrahamsen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87mt7zm6t3.fsf@ericabrahamsen.net \
--to=eric@ericabrahamsen.net \
--cc=help-gnu-emacs@gnu.org \
--cc=matt@excalamus.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).