Selection-set editing without VC-dired

Selection-set editing without VC-dired

[Eric S. Raymond]

(Apologies if this appears as a resend.  I'm having hardware and
Postfix-configuration troubles this morning and I think my first
attempt bounced.)

The selection-set editing commands I proposed in a reply to David
Kastrup would be easy to implement.  However, on reflection, I am
not at all sure doing so would be wise design.

In general, I think it is better to have one UI method that works well
than lots of semi-gratuitous knobs and switches. And I might want to
use C-x v + and C-x v - for something else someday.

So, I'm not outright rejecting the idea of a non-VC-Dired UI for
specifying selection sets. But I think it would be better for
now if I continued to focus on making VC-Dired so fast that
you won't really want or need an alternate set-editing method.  

I expect to capture another substantial speed gain in the
next rewrite.  I'd have done this already, but I've been a
bit distracted by the holiday social round.
--
						>>esr>>

Re: Selection-set editing without VC-dired

[Miles Bader]

"Eric S. Raymond" <esr@golux.thyrsus.com> writes:
> In general, I think it is better to have one UI method that works well
> than lots of semi-gratuitous knobs and switches.

I guess somebody else will have to implement it then.

-Miles

-- 
We live, as we dream -- alone....

Re: Selection-set editing without VC-dired

[Thien-Thi Nguyen]

() "Eric S. Raymond" <esr@golux.thyrsus.com>
() Sun, 30 Dec 2007 09:36:06 -0500 (EST)

   So, I'm not outright rejecting the idea of a non-VC-Dired UI for
   specifying selection sets. But I think it would be better for
   now if I continued to focus on making VC-Dired so fast that
   you won't really want or need an alternate set-editing method.  

probably it is better to consider set editing more fundamental
and rework vc-dired to use the more fundamental operations.

thi

Selection-set editing without VC-dired

[Stephen J. Turnbull]

Eric S. Raymond writes:

 > So, I'm not outright rejecting the idea of a non-VC-Dired UI for
 > specifying selection sets. But I think it would be better for
 > now if I continued to focus on making VC-Dired so fast that
 > you won't really want or need an alternate set-editing method.  

For subfile (hunk-level) selection, you definitely will.  This is one
of the features that makes Darcs fanatics.

Re: Selection-set editing without VC-dired

[Miles Bader]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:
>  > So, I'm not outright rejecting the idea of a non-VC-Dired UI for
>  > specifying selection sets. But I think it would be better for
>  > now if I continued to focus on making VC-Dired so fast that
>  > you won't really want or need an alternate set-editing method.  
>
> For subfile (hunk-level) selection, you definitely will.  This is one
> of the features that makes Darcs fanatics.

Git can also do this sort of thing (I don't use it often, but it can be
reallly nice when you need it!), and using the "index" for commit allows
for even more possibilities.

However, are there enough common details to make a common vc interface
to such details practical?

-Miles

-- 
The car has become... an article of dress without which we feel uncertain,
unclad, and incomplete.  [Marshall McLuhan, Understanding Media, 1964]

Re: Selection-set editing without VC-dired

[Stephen J. Turnbull]

Miles Bader writes:

 > However, are there enough common details to make a common vc interface
 > to [hunk-level] details practical?

I'm thinking diff-mode + quilt, not using the SCM's native interface.
Eg, in Darcs's case you'd have to drive it using comint or similar.
Blargh.  No generality there, fer shure.

Selection-set editing without VC-dired

[Eric S. Raymond]

The selection-set editing commands I proposed in a reply to David
Kastrup would be easy to implement.  However, on reflection, I am
not at all sure doing so would be wise design.

In general, I think it is better to have one UI method that works well
than lots of semi-gratuitous knobs and switches. And I might want to
use C-x v + and C-x v - for something else someday.

So, I'm not outright rejecting the idea of a non-VC-Dired UI for
specifying selection sets. But I think it would be better for
now if I continued to focus on making VC-Dired so fast that
you won't really want or need an alternate set-editing method.  

I expect to capture another substantial speed gain in the
next rewrite.  I'd have done this already, but I've been a
bit distracted by the holiday social round.
--
						>>esr>>

Re: Selection-set editing without VC-dired

[David Kastrup]

"Eric S. Raymond" <esr@golux.thyrsus.com> writes:

> The selection-set editing commands I proposed in a reply to David
> Kastrup would be easy to implement.  However, on reflection, I am
> not at all sure doing so would be wise design.
>
> In general, I think it is better to have one UI method that works well
> than lots of semi-gratuitous knobs and switches. And I might want to
> use C-x v + and C-x v - for something else someday.
>
> So, I'm not outright rejecting the idea of a non-VC-Dired UI for
> specifying selection sets. But I think it would be better for
> now if I continued to focus on making VC-Dired so fast that
> you won't really want or need an alternate set-editing method.

PCL-CVS is certainly fast enough but I still consider having to use it
(or other directory-based methods) for multi-file commits a crutch and
inconvenience.  There is no point in having to go through a directory
listing when committing two files already loaded and edited in buffers.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Selection-set editing without VC-dired

[Stefan Monnier]

>> So, I'm not outright rejecting the idea of a non-VC-Dired UI for
>> specifying selection sets. But I think it would be better for
>> now if I continued to focus on making VC-Dired so fast that
>> you won't really want or need an alternate set-editing method.

> PCL-CVS is certainly fast enough but I still consider having to use it
> (or other directory-based methods) for multi-file commits a crutch and
> inconvenience.  There is no point in having to go through a directory
> listing when committing two files already loaded and edited in buffers.

While I like PCL-CVS, obviously, I agree that I also use VC to commit
single files and that I occasionally feel like it would be nice to have
an intermediate level.  Typically I see it work something like:
- from foo.c I'd do C-x v v: makes me jump to *VC-log* set up to commit foo.c
- go to foo.h
- from foo.h I'd also do a C-x v v:  makes me jump again to *VC-log*
  but this time setup to commit both foo.c and foo.h.
- C-c C-c then commits both.

On a related note, with current VCS making ChangeLog file less relevant,
it'd also make sense to make C-x 4 a jump to the *VC-log* buffer, add
the relevant piece of text and maybe also add the file to the set of
files that will be committed.


        Stefan

Re: Selection-set editing without VC-dired

[Bob Rogers]

   From: Stefan Monnier <monnier@iro.umontreal.ca>
   Date: Tue, 01 Jan 2008 21:52:55 -0500

   >> So, I'm not outright rejecting the idea of a non-VC-Dired UI for
   >> specifying selection sets. But I think it would be better for
   >> now if I continued to focus on making VC-Dired so fast that
   >> you won't really want or need an alternate set-editing method.

   > PCL-CVS is certainly fast enough but I still consider having to use it
   > (or other directory-based methods) for multi-file commits a crutch and
   > inconvenience.  There is no point in having to go through a directory
   > listing when committing two files already loaded and edited in buffers.

   While I like PCL-CVS, obviously, I agree that I also use VC to commit
   single files and that I occasionally feel like it would be nice to have
   an intermediate level . . .

Sorry for stepping into this conversation so late.  I have code to do
multi-file commits based on *VC-log* comments.  The workflows goes like
this:

   1.  M-x vc-start-commit to create a new *VC-log* buffer with all of
the modified files named.  Only those files still named in the buffer at
commit time are actually committed, and new files can be added manually.
(There is also a M-x vc-split-entry command to split the log buffer at
point, copying half out into a new buffer).

   2.  C-x v = in the log-edit buffer produces a diff of the listed
files for perusal while writing the comment.

   3.  C-! in a diff hunk snarfs the definition name from point in the
source (though only a few language modes are handled so far) and starts
a comment for that definition, under the correct file.

   4.  Iterate and/or split until happy, then commit normally.

   Unfortunately, I have been lazy about updating this code to work with
the changes ESR has introduced since the Emacs 22.1 release.  Worse, it
is also essentially undocumented.  But if there's interest, I will try
to accelerate work on making it current (and documenting it!).

					-- Bob Rogers
					   http://rgrjr.dyndns.org/

Re: Selection-set editing without VC-dired

[Richard Stallman]

    On a related note, with current VCS making ChangeLog file less relevant,
    it'd also make sense to make C-x 4 a jump to the *VC-log* buffer, 

Recent trends in VCS make the ChangeLog file more important.  The
reason I dropped my opposition to multi-file commits is that I
realized that the info I used to get by looking at a CVS log, I could get
from the ChangeLog file instead with a suitable selective visibility
mode.

I am therefore opposed to any changes which have the effect of
downgrading Change Log files, or which presume they are downgraded.

Re: Selection-set editing without VC-dired

[Stefan Monnier]

>     On a related note, with current VCS making ChangeLog file less relevant,
>     it'd also make sense to make C-x 4 a jump to the *VC-log* buffer, 

> Recent trends in VCS make the ChangeLog file more important.  The
> reason I dropped my opposition to multi-file commits is that I
> realized that the info I used to get by looking at a CVS log, I could get
> from the ChangeLog file instead with a suitable selective visibility
> mode.

From what I can see, recent trends in VCS make the ChangeLog file less
important because it can be automatically regenerated from the
commit logs.  And by "automatically regenerated" I really mean that the
output is just as good, or even identical.


        Stefan

Re: Selection-set editing without VC-dired

[Richard Stallman]

    >From what I can see, recent trends in VCS make the ChangeLog file less
    important because it can be automatically regenerated from the
    commit logs.  And by "automatically regenerated" I really mean that the
    output is just as good, or even identical.

I'd like to see this demonstrated.