unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Protesilaos Stavrou <info@protesilaos.com>
To: Sean Whitton <spwhitton@spwhitton.name>
Cc: emacs-devel@gnu.org
Subject: Re: [ELPA] Add Agitate package
Date: Tue, 27 Sep 2022 20:18:34 +0300	[thread overview]
Message-ID: <875yh8wxat.fsf@protesilaos.com> (raw)
In-Reply-To: <87ill8er5k.fsf@melete.silentflame.com>

> From: Sean Whitton <spwhitton@spwhitton.name>
> Date: Tue, 27 Sep 2022 09:08:39 -0700
>
> Hello Prot,

Hello Sean,

> On Tue 27 Sep 2022 at 09:01AM +03, Protesilaos Stavrou wrote:
>
>> I want to install the attached patch on elpa.git.
>>
>> Agitate is a collection of commands or potentially useful functions
>> that expand on the available version control features of Emacs.  Those
>> are meant to complement a workflow that relies on the built-in Version
>> Control framework and its accoutrements ('diff-mode.el',
>> 'log-view.el', 'log-edit.el', 'vc-git.el', and potentially others).
>>
>> The reason I am posting this here is because I want to ask if it is okay
>> to publish such a package, given that at least some of its code may be
>> better suited for emacs.git directly.  I prefer the package format for
>> the time being, because it gives me (and others) the chance to refine
>> the code and decide on what is worth contributing to core Emacs.
>
> I just looked through the file.  I recently read your prot-vc.el from
> your personal Emacs configuration, and I believe that most (or all?) of
> Agitate is a cleaned-up version of that?

Thanks for taking the time to do that and to write this!  You are right:
some it is a rewritten version of what I had been using in my own setup.
Though I discarded most parts.  The idea with the package is to continue
with the discarding+refining process, with whatever help from the
community.

> I think that it is always worth taking a fresh look at one's personal
> code and seeing if versions of parts of it might be upstreamable, so
> thank you for your work.  One does have to accept, as I'm sure you
> realise, that some things will be too idiosyncratic or personal to be
> much use to others.  So it's reasonable to assume, given its origin,
> that Agitate is a mixture of things that should eventually go into
> emacs.git and things which should not.

I agree.

> In that case, it doesn't make too much sense to me to add it to ELPA,
> but not for the reasons that you give.  It's not that code which is
> targeting emacs.git cannot go on ELPA first, but it seems to me that
> anything on ELPA should be a coherent, singular package.  And Agitate
> isn't that -- it's a collection of functionality that you're filtering
> things out of over time.

The part about coherence is the trickiest when it comes to VC because
the whole workflow involves different processes, some of which are
implemented in vc-*.el, others in log-edit.el, and the like.  I think
that what I have and am working towards (this is not the finished
article) is coherent in terms of workflow.  Though I wanted to have this
discussion exactly because I may be caught in a bubble and misjudging
things.

> For myself, I'm looking forward to seeing some of this in core.

Yes, that is the end goal: to determine what should be in emacs.git and
which form it should take.

Thanks again!

All the best,
Prot

-- 
Protesilaos Stavrou
https://protesilaos.com



  reply	other threads:[~2022-09-27 17:18 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-27  6:01 [ELPA] Add Agitate package Protesilaos Stavrou
2022-09-27  8:01 ` Philip Kaludercic
2022-09-27  8:09   ` Protesilaos Stavrou
2022-09-27 16:08 ` Sean Whitton
2022-09-27 17:18   ` Protesilaos Stavrou [this message]
2022-09-27 22:07     ` Sean Whitton
2022-09-28  2:14       ` Protesilaos Stavrou
2022-09-28 11:00   ` Stefan Kangas
2022-09-29  5:52     ` Protesilaos Stavrou
2022-09-29  5:58       ` Protesilaos Stavrou
2022-10-01 22:19       ` Stefan Monnier
2022-10-02  2:07         ` Protesilaos Stavrou
2022-09-30  2:38     ` Richard Stallman

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=875yh8wxat.fsf@protesilaos.com \
    --to=info@protesilaos.com \
    --cc=emacs-devel@gnu.org \
    --cc=spwhitton@spwhitton.name \
    /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.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

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).