Selection-set editing without VC-dired

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

Automatically generated ChangeLogs (was: Selection-set editing without VC-dired)

[Reiner Steib]

[ The following message is a courtesy copy of an article that has
  been posted to news:gmane.emacs.devel as well. ]

On Thu, Jan 03 2008, Stefan Monnier wrote:

> Richard Stallman wrote:
>> 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.

Currently our ChangeLogs contain information about the contributor
which is not necessarily identical to the committer.  Would a recent
VCS hold this information in a form that an automatically regenerated
ChangeLog contains it too?

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Automatically generated ChangeLogs (was: Selection-set editing without VC-dired)

[Andreas Schwab]

Reiner Steib <reinersteib+gmane@imap.cc> writes:

> Currently our ChangeLogs contain information about the contributor
> which is not necessarily identical to the committer.  Would a recent
> VCS hold this information in a form that an automatically regenerated
> ChangeLog contains it too?

Git distinguishes between the author and the committer.  (But I don't
think it can directly deal with multiple authors.)

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Automatically generated ChangeLogs (was: Selection-set editing without VC-dired)

[Eli Zaretskii]

> From: Andreas Schwab <schwab@suse.de>
> Date: Thu, 03 Jan 2008 17:48:09 +0100
> Cc: esr@golux.thyrsus.com, rms@gnu.org, emacs-devel@gnu.org
> 
> Reiner Steib <reinersteib+gmane@imap.cc> writes:
> 
> > Currently our ChangeLogs contain information about the contributor
> > which is not necessarily identical to the committer.  Would a recent
> > VCS hold this information in a form that an automatically regenerated
> > ChangeLog contains it too?
> 
> Git distinguishes between the author and the committer.  (But I don't
> think it can directly deal with multiple authors.)

We also have "(tiny change)" labels in the ChangeLog entries, which
need to be accessible when one looks up a file's history.

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.

merging the unicode-2 branch (was: Re: Selection-set editing without VC-dired)

[Dan Nicolaescu]

Richard Stallman <rms@gnu.org> writes:

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

Can we then proceed with the unicode-2 branch merging then? Splitting
the ChangeLog per file was what was blocking the merge.
There's no reason to postpone this any longer, it serves no useful
purpose and it only delays the 23.1 release.

Re: merging the unicode-2 branch (was: Re: Selection-set editing without VC-dired)

[Richard Stallman]

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

    Can we then proceed with the unicode-2 branch merging then?

Sorry, I don't follow.  I think there is a misunderstanding here.

     Splitting
    the ChangeLog per file was what was blocking the merge.

I think that is the misunderstanding.  What I asked for was not
to "split" the ChangeLog file.  It was to simplify it,
getting rid of unnecessary duplicate entries.  For instance,
if we have

	(foobar): Change xyz.

and on a previous date

        (foobar): New function.

then we only need the latter.  If foobar is a new function, being
installed now, then we only need the "new function" entry.

Re: merging the unicode-2 branch (was: Re: Selection-set editing without VC-dired)

[Dan Nicolaescu]

Richard Stallman <rms@gnu.org> writes:

  >       > 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.
  > 
  >     Can we then proceed with the unicode-2 branch merging then?
  > 
  > Sorry, I don't follow.  I think there is a misunderstanding here.
  > 
  >      Splitting
  >     the ChangeLog per file was what was blocking the merge.
  > 
  > I think that is the misunderstanding.  What I asked for was not
  > to "split" the ChangeLog file.  It was to simplify it,
  > getting rid of unnecessary duplicate entries.  For instance,
  > if we have
  > 
  > 	(foobar): Change xyz.
  > 
  > and on a previous date
  > 
  >         (foobar): New function.
  > 
  > then we only need the latter.  If foobar is a new function, being
  > installed now, then we only need the "new function" entry.

Well, Handa-san didn't sound like he thought this would be a good
idea. Here is what he replied to you:

   (3) RMS wrote:
   
     > The most important part of the massaging is to get rid of duplicate
     > entries.  For instance suppose a function named foo is added and then
     > changed 10 times.  There will be 11 change log entries for it, but  we
     > we only need to keep one: "New function".
   
   Even for a new funciton, I want to know why some piece of
   code is in the current shape.  I many times encountered such
   a case that I don't remember why I wrote some code as the
   current way.  In such a case, I read changelogs and get a
   hint.  So, I don't want to loose the current information.
   If you don't insist on having just one entry for changes of
   a non-new function, please apply that also to a new
   function.  For instance, I want to keep all of these
   information.
   
           (insert_from_gap): Adjust intervals correctly.
           (insert_from_gap): Fix argument to offset_intervals.
           (insert_from_gap): Make it work even if PT != GTP.
           (insert_from_gap): Call record_insert.
           (insert_from_gap): New function.
   
   Then, for instance, I can know (or recall) that the function
   is intentionally coded to work in the PT != GTP case.


And I also stated that given the experience with the work I've done for
doing such ChangeLog rewriting for the multi-tty merge the amount of
effort involved in doing this type of rewrite is non-trivial, it can be
at least a full day of work.  I have yet to see any benefit from all
that effort. 

Re: merging the unicode-2 branch (was: Re: Selection-set editing without VC-dired)

[Andreas Schwab]

Dan Nicolaescu <dann@ics.uci.edu> writes:

>    Then, for instance, I can know (or recall) that the function
>    is intentionally coded to work in the PT != GTP case.

That is supposed to be written in a comment.  A change log is not a good
replacement.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: merging the unicode-2 branch

[Stefan Monnier]

>> Then, for instance, I can know (or recall) that the function
>> is intentionally coded to work in the PT != GTP case.

> That is supposed to be written in a comment.  A change log is not a good
> replacement.

There's theory and then there's practice: I agree that it "should" be in
a comment, but experience shows that often people don't think hard
enough about what to put in a changelog and what to put in comments, so
the changelog is often a necessary crutch (which can also be used to
improve the comments in the code, after the fact).


        Stefan

Re: merging the unicode-2 branch (was: Re: Selection-set editing without VC-dired)

[Richard Stallman]

I will accept non-simplified change logs for the unicode-2 merge.

I usually find simplified change logs easier to read precisely because
they are simpler, but these changes may be so voluminous that it makes
no difference.

Re: merging the unicode-2 branch

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
> I will accept non-simplified change logs for the unicode-2 merge.
>
> I usually find simplified change logs easier to read precisely because
> they are simpler, but these changes may be so voluminous that it makes
> no difference.

Are there any other issues blocking the merge?

-Miles

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

Re: merging the unicode-2 branch

[Nick Roberts]

 > Are there any other issues blocking the merge?

If unicode-2 is merged before Emacs 22.2 is released, does that make merges
from EMACS_22_BASE more difficult?

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: merging the unicode-2 branch

[David Kastrup]

Nick Roberts <nickrob@snap.net.nz> writes:

>  > Are there any other issues blocking the merge?
>
> If unicode-2 is merged before Emacs 22.2 is released, does that make
> merges from EMACS_22_BASE more difficult?

Seems like a red herring to me since the changes have to be merged into
unicode-2 anyway.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: merging the unicode-2 branch

[Miles Bader]

Nick Roberts <nickrob@snap.net.nz> writes:
>  > Are there any other issues blocking the merge?
>
> If unicode-2 is merged before Emacs 22.2 is released, does that make merges
> from EMACS_22_BASE more difficult?

I doubt it.  They're already being merged into unicode-2 indirectly
(rel-22 -> trunk -> unicode) anyway.

-Miles

-- 
Suburbia: where they tear out the trees and then name streets after them.