Removing rollback from VC mode - request for comment

Removing rollback from VC mode - request for comment

[Eric S. Raymond]

I am trying to simplify and clean up the back-end API of VC mode.  The
low-hanging fruit, the methods and configuration variables that were
redundant or obvious shoot-self-in-foot anachronisms, are gone at this
point.  (And there were a lot of those; I count nine.)

I can go further, but to do so I need to actually change the behavior
of the mode and remove some features that, at least once upon a time,
had a real use case.

Rollback is a case in point.  It is a command that lets you undo the
last checkin.  Only SCCS and RCS actually support it.  Git possibly 
could, in theory, but the Git implementation would be tricky and have 
sharp edges when the last revision had been pushed.

Here are the arguments for doing this:

1. It simplifies the API and code - if I rip this out, I think I can
also remove latest-on-branch-p.  It also builds towards a difficult 
goal, which is to reduce the set of version-control states and
simplify the rather large hairball that vc-next-action has become.

2. VC in particular, and version-control systems in general, have
moved towards a philosophy of making history destruction difficult.
Old school, saving disk space was important enough that removing
deltas was actually done as an economy measure.  New school, making 
it difficult for the user to shoot self in foot is a higher virtue.

The argument against this is simply that someone, somewhere out there,
might be using it on some remnant RCS repo (I think we can safely
consider SCCS dead to us at this point).  And the broader question is
whether that possibility is a dealbreaker.

Is it really important to support a VC-mode operation that experience
has shown to generally be a Bad Thing, simply to preserve backward
compatibility?  How do we evaluate tradeoffs when a featurectomy
would reduce maintenance burden and possibly improve the quality
of support for new systems?

I don't think I have a pat answer to these questions.  Discuss.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Whether the authorities be invaders or merely local tyrants, the
effect of such [gun control] laws is to place the individual at the 
mercy of the state, unable to resist.
        -- Robert Anson Heinlein, 1949

Re: Removing rollback from VC mode - request for comment

[David Kastrup]

esr@snark.thyrsus.com (Eric S. Raymond) writes:

> Is it really important to support a VC-mode operation that experience
> has shown to generally be a Bad Thing,

We are really talking about RCS here.  RCS is not usually shared, at
least not network-shared.  I don't see that experience has shown
rollback to be a bad thing for RCS.  Experience does not tend to show a
lot for RCS anyway these days since few people are still using it.

> simply to preserve backward compatibility?  How do we evaluate
> tradeoffs when a featurectomy would reduce maintenance burden and
> possibly improve the quality of support for new systems?
>
> I don't think I have a pat answer to these questions.  Discuss.

I think that rollback may make sense in RCS-based workflows.  But I
don't think that this should be VC's problem.  VC does not provide every
functionality for every version control system, so think we should be
fine removing rollback from VC.  VC does not support every Git
functionality either: if it is really important to people, it can be
reimplemented in some RCS-specific mode/feature/library/command set.

-- 
David Kastrup

Re: Removing rollback from VC mode - request for comment

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 3339 bytes --]

() David Kastrup <dak@gnu.org>
() Thu, 11 Dec 2014 10:43:13 +0100

   > Is it really important to support a VC-mode operation that
   > experience has shown to generally be a Bad Thing,

   We are really talking about RCS here.  RCS is not usually
   shared, at least not network-shared.  I don't see that
   experience has shown rollback to be a bad thing for RCS.
   Experience does not tend to show a lot for RCS anyway
   these days since few people are still using it.

Conceptually, rollback is removing the last commit.

In RCS, this is implemented via ‘rcs -o’ (for "outdate"),
which in its general operation can remove a series of
consecutive non-tip commits, as well. In Git terms, "RCS
outdate" can be likened to both ‘git reset --hard HEAD~1’
(last commit only) and ‘git rebase -i’ + manual omission of
commits in the list (generally).  The ‘git rebase’ is more
powerful because an arbitrary set of commits can be dropped;
they need not be consecutive.

Anyway, this DAG-dicing is not shooting oneself in the foot
if one knows what one's doing.  Personally, i prefer VC not
to (try to) think for me in this regard.  [Already, i am
ready to gripe about "always editable" for RCS -- that's
wrong and embracing it in the name of progress is unwise.
(I'm "ready" but i haven't looked at the new code yet, much
less played w/ it, so there's still time to let my angst boil
over. :-D)]

So, i think "rollback" as a concept is actually not far
enough.  Being able to select arbitrary commits to drop (like
‘d’ and ‘x’ in Dired) is what i'd like to see, in its stead.

Another idea is to modify the "rollback" concept to leave the
working files "as-is" but remove the commit from the repo.

For RCS, this would be ‘co -p ; rcs -o ; mv’ (roughly), and
for Git this would be ‘git reset --mixed HEAD~1’.  On second
thought, using the same name w/ different meaning is indeed a
foot-shooting move, so maybe "step back" is what we want.

If we add "step back", then we can keep "rollback" as an
optional mode of operation (via ‘C-u’).  Or "rollback" can
take ‘C-u’ to mean "step back".  Or there could be a variable
to control things.  Etc.

   > simply to preserve backward compatibility?  How do we
   > evaluate tradeoffs when a featurectomy would reduce
   > maintenance burden and possibly improve the quality of
   > support for new systems?

   I think that rollback may make sense in RCS-based
   workflows.  But I don't think that this should be VC's
   problem.  VC does not provide every functionality for
   every version control system, so think we should be fine
   removing rollback from VC.  VC does not support every Git
   functionality either: if it is really important to people,
   it can be reimplemented in some RCS-specific
   mode/feature/library/command set.

I think if we can extend "rollback" to do something useful,
that would be best.  Dropping features is liberating for the
programmer but unkind for the user.  Being unkind to the old
and ugly is particularly lamentable.

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Removing rollback from VC mode - request for comment

[Eric S. Raymond]

[-- Attachment #1: Type: text/plain, Size: 999 bytes --]

Thien-Thi Nguyen <ttn@gnu.org>:
> So, i think "rollback" as a concept is actually not far
> enough.  Being able to select arbitrary commits to drop (like
> ‘d’ and ‘x’ in Dired) is what i'd like to see, in its stead.

RCCS and SCCS can do this, in theory.  But I've never trusted that
feature.  The obvious problem is that if you delete an earlier delta
you may well change the preconditions for a later one, so it will have
unexpected effects.  

I know how RCS's delta representation works; it is *not* smart enough
to fully compensate.  And no wonder. General patch composition is a
hard enough problem that it scuttled Darcs thirty years later!

In other VCSes it would be difficult to even attempt this.  In view
of the known problems, I recommend staying way the hell away from
it unless and until David Roundy successfully proves a correct
composition algorithm and we integrate it into Emacs somehow.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 173 bytes --]

Re: Removing rollback from VC mode - request for comment

[Eli Zaretskii]

> Date: Thu, 11 Dec 2014 07:51:45 -0500
> From: "Eric S. Raymond" <esr@thyrsus.com>
> 
> Thien-Thi Nguyen <ttn@gnu.org>:
> > So, i think "rollback" as a concept is actually not far
> > enough.  Being able to select arbitrary commits to drop (like
> > ‘d’ and ‘x’ in Dired) is what i'd like to see, in its stead.
> 
> RCCS and SCCS can do this, in theory.  But I've never trusted that
> feature.  The obvious problem is that if you delete an earlier delta
> you may well change the preconditions for a later one, so it will have
> unexpected effects.  
> 
> I know how RCS's delta representation works; it is *not* smart enough
> to fully compensate.  And no wonder. General patch composition is a
> hard enough problem that it scuttled Darcs thirty years later!
> 
> In other VCSes it would be difficult to even attempt this.

??? It's known as "reverse cherry-picking", and is AFAIK possible in
Git, bzr, and hg.

Or maybe I don't understand what ttn was alluding to.

Re: Removing rollback from VC mode - request for comment

[Steinar Bang]

>>>>> Eli Zaretskii <eliz@gnu.org>:

> ??? It's known as "reverse cherry-picking", and is AFAIK possible in
> Git, bzr, and hg.

Do you mean yank a commit from somewhere back in history, keeping the
newer one?

It would be possible from command line git, I guess... changing the sha1
hash of all commits following the yanked commit.

But I would use "git revert" for something like this instead, adding a
commit, rather than removing one, and keeping all of the existing
commits' sha1 values.

Re: Removing rollback from VC mode - request for comment

[Eli Zaretskii]

> From: Steinar Bang <sb@dod.no>
> Date: Thu, 11 Dec 2014 18:12:29 +0100
> 
> >>>>> Eli Zaretskii <eliz@gnu.org>:
> 
> > ??? It's known as "reverse cherry-picking", and is AFAIK possible in
> > Git, bzr, and hg.
> 
> Do you mean yank a commit from somewhere back in history, keeping the
> newer one?

You don't yank it -- history is immutable -- you undo it by another
commit.

> But I would use "git revert" for something like this instead, adding a
> commit, rather than removing one, and keeping all of the existing
> commits' sha1 values.

That's the mechanics.  From the human's POV, the commit was "removed".

Re: Removing rollback from VC mode - request for comment

[Eric S. Raymond]

Eli Zaretskii <eliz@gnu.org>:
> > In other VCSes it would be difficult to even attempt this.
> 
> ??? It's known as "reverse cherry-picking", and is AFAIK possible in
> Git, bzr, and hg.
> 
> Or maybe I don't understand what ttn was alluding to.

You don't, not quite.  Reverse cherry pick doesn't actually do the git
equivalent of removing a delta; the history is not altered.  Reverse
cherry pic only requires forward composition of a reversed patch onto
the current branch tip - a much, *much* more tractable problem.

The git equivalent of actually removing a delta would be *really hard*.  
You'd have to apply a reverse patch (in effect) against the blob, then
against all of its successors, dealing with conflicts in some way.  
All the downstream hashes would be invalidated.  A mess.

This is why git only lets you remove tip deltas.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Removing rollback from VC mode - request for comment

[Eli Zaretskii]

> Date: Thu, 11 Dec 2014 12:45:08 -0500
> From: "Eric S. Raymond" <esr@thyrsus.com>
> Cc: emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org>:
> > > In other VCSes it would be difficult to even attempt this.
> > 
> > ??? It's known as "reverse cherry-picking", and is AFAIK possible in
> > Git, bzr, and hg.
> > 
> > Or maybe I don't understand what ttn was alluding to.
> 
> You don't, not quite.  Reverse cherry pick doesn't actually do the git
> equivalent of removing a delta; the history is not altered.  Reverse
> cherry pic only requires forward composition of a reversed patch onto
> the current branch tip - a much, *much* more tractable problem.

Of course!  But that's the only possible way in modern VCSs to do
that, and the human-level abstraction is the same.

> The git equivalent of actually removing a delta would be *really hard*.  

I didn't (and couldn't) mean that.

Re: Removing rollback from VC mode - request for comment

[Sergey Organov]

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

> Eli Zaretskii <eliz@gnu.org>:
>> > In other VCSes it would be difficult to even attempt this.
>> 
>> ??? It's known as "reverse cherry-picking", and is AFAIK possible in
>> Git, bzr, and hg.
>> 
>> Or maybe I don't understand what ttn was alluding to.
>
> You don't, not quite.  Reverse cherry pick doesn't actually do the git
> equivalent of removing a delta; the history is not altered.  Reverse
> cherry pic only requires forward composition of a reversed patch onto
> the current branch tip - a much, *much* more tractable problem.
>
> The git equivalent of actually removing a delta would be *really
> hard*.

Nah. Try

git rebase --onto HEAD~7 HEAD~6

to kill HEAD~6 commit.

> You'd have to apply a reverse patch (in effect) against the blob, then
> against all of its successors, dealing with conflicts in some way.  
> All the downstream hashes would be invalidated.  A mess.

Yes, hashes would be invalidated. Not a big deal provided history
was not yet published.

>
> This is why git only lets you remove tip deltas.

Nah. See above.

And, strictly speaking, Git doesn't work in terms of deltas, nor does it
remove anything. To get rid of a few last commits, it only moves the
branch pointer back, and from the POV of drawbacks of history rewrite
I don't think it's too different from removing commit(s) in the middle.

-- 
Sergey.

Re: Removing rollback from VC mode - request for comment

[Sergey Organov]

Sergey Organov <sorganov@gmail.com> writes:

> "Eric S. Raymond" <esr@thyrsus.com> writes:
>
>> Eli Zaretskii <eliz@gnu.org>:
>>> > In other VCSes it would be difficult to even attempt this.
>>> 
>>> ??? It's known as "reverse cherry-picking", and is AFAIK possible in
>>> Git, bzr, and hg.
>>> 
>>> Or maybe I don't understand what ttn was alluding to.
>>
>> You don't, not quite.  Reverse cherry pick doesn't actually do the git
>> equivalent of removing a delta; the history is not altered.  Reverse
>> cherry pic only requires forward composition of a reversed patch onto
>> the current branch tip - a much, *much* more tractable problem.
>>
>> The git equivalent of actually removing a delta would be *really
>> hard*.
>
> Nah. Try
>
> git rebase --onto HEAD~7 HEAD~6
>
> to kill HEAD~6 commit.

And even if it's only some chunk(s) of the diff of the entire commit, it
is still rather simple, using --interactive option.

-- 
Sergey.

Re: Removing rollback from VC mode - request for comment

[Eric S. Raymond]

Sergey Organov <sorganov@gmail.com>:
> > This is why git only lets you remove tip deltas.
> 
> Nah. See above.

Rebase is a different operation. It's forward composition after
you've chopped off a last segnment.
 
> And, strictly speaking, Git doesn't work in terms of deltas, nor does it
> remove anything. To get rid of a few last commits, it only moves the
> branch pointer back, and from the POV of drawbacks of history rewrite
> I don't think it's too different from removing commit(s) in the middle.

It's...quite different.  I had to wrestle with this when implementing
commit deletion in reposurgeon.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Removing rollback from VC mode - request for comment

[Stephen J. Turnbull]

Eric S. Raymond writes:

 > Rebase is a different operation. It's forward composition after
 > you've chopped off a last segnment.

And?  Certainly, there are several ways you could define "commit
deletion", but this is equally certainly one of the reasonable ones.

 > It's...quite different.  I had to wrestle with this when implementing
 > commit deletion in reposurgeon.

There are at least three concepts of commit deletion.  All are
implemented in git.

The first is removing the effects on content but not the history in
the DAG.  git implements the command "revert" for this purpose.[1]
The second removes both the effects and the history.  git implements
the command "rebase" for this purpose.  Finally, one may wish to
remove the history, but not the effects.  git (in its gittishly
inimitable way) provides several ways to accomplish this: the "squash"
operation of the "rebase --interactive" command, the "--squash" option
to the "merge" command, and the ultimate generalization of all of the
above, the "filter-branch" command.

In git-like DAG implementations, all history alterations require
recreation of "forward history" as well.  It's theoretically possible
to equivalence commits (eg, git provides grafts) but as far as I know
there are no VCSes that try to do this automatically and consistently
through all DAG operations.  That is indeed a hard problem.  Bottom
line, in existing DAG-based VCSes, there is either no way to actually
remove commits, or the human keeps track of the equivalencing of
descendant commits in lieu of a Sufficiently Smart VCS.

Footnotes: 
[1]  Introspection suggests that "commit deletion" is a bad way to
describe this.  I don't know for sure that others feel that way, and I
include it for symmetry/completeness.

Re: Removing rollback from VC mode - request for comment

[Steinar Bang]

>>>>> "Stephen J. Turnbull" <stephen@xemacs.org>:

> In git-like DAG implementations, all history alterations require
> recreation of "forward history" as well.  It's theoretically possible
> to equivalence commits (eg, git provides grafts)

I hadn't heard about grafts before, but git has yet another possiblity
called "git replace" (that I have used), and this discussions seems to
indicate that replace is newer and better:
 http://stackoverflow.com/questions/6800692/how-do-git-grafts-and-replace-differ-are-grafts-now-deprecated

Description of git-replace:
 http://git-scm.com/blog/2010/03/17/replace.html

Re: Removing rollback from VC mode - request for comment

[Stephen J. Turnbull]

Eric S. Raymond writes:

 > The git equivalent of actually removing a delta would be *really
 > hard*.  

Nonsense.  It's called "rebase".  If you mean "to do completely
automatically", sure -- I'd say impossible -- but if we could automate
that, who needs vc.el?  The reason for having this functionality in
Emacs is that this kind of work needs to be human-driven, and Emacs is
the best tool we have for optimizing the balance between human
decision-making and automatable operations.

I'm really disappointed.  Re-specifying vc.el is a job for an expert.
You really ought to do more homework on the application domain and the
users' use cases before proposing major changes to the functionality.

This thread seriously undermines your whole thesis about "removing
barriers to committing patches Emacs will increase contribution".  I
suspect that the most important contributions to the vc.el revision
effort will be posts to emacs-devel, and conversely, most of those
posters will provide zero code to vc.el during this period.

Re: Removing rollback from VC mode - request for comment

[Eric S. Raymond]

Stephen J. Turnbull <stephen@xemacs.org>:
> Eric S. Raymond writes:
> 
>  > The git equivalent of actually removing a delta would be *really
>  > hard*.  
> 
> Nonsense.  It's called "rebase".

Sigh.  That's a different operation.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Removing rollback from VC mode - request for comment

[Ted Zlatanov]

On Thu, 11 Dec 2014 04:21:38 -0500 (EST) esr@snark.thyrsus.com (Eric S. Raymond) wrote: 

ESR> Rollback is a case in point.  It is a command that lets you undo the
ESR> last checkin.  Only SCCS and RCS actually support it.  Git possibly 
ESR> could, in theory, but the Git implementation would be tricky and have 
ESR> sharp edges when the last revision had been pushed.

I think Git should support it anyway, with rollback to any commit.
That's just a "git reset".  It's useful.

I don't see an issue with pushed revisions.  If you want to reset and
"push -f", that's a legitimate workflow.  Otherwise, your push will be
rejected.

Ted

Re: Removing rollback from VC mode - request for comment

[Steinar Bang]

>>>>> Ted Zlatanov <tzz@lifelogs.com>:

> I think Git should support it anyway, with rollback to any commit.
> That's just a "git reset".

"git reset --hard", actually.

> It's useful.

Yes, as "git reset --hard" is a somewhat dangerous operation to do from
the command line, it would be nice to be able to do it from a UI that
feels safe.

But there is one complication that git commits may span more files than
the one file currently seen by vc-git.el, and if so: what do you do?

Re: Removing rollback from VC mode - request for comment

[Eric S. Raymond]

Steinar Bang <sb@dod.no>:
> Yes, as "git reset --hard" is a somewhat dangerous operation to do from
> the command line, it would be nice to be able to do it from a UI that
> feels safe.
> 
> But there is one complication that git commits may span more files than
> the one file currently seen by vc-git.el, and if so: what do you do?

Right, this is one of the reasons I described it as tricky and
sharp-edged.

The problem is not specific to Git.  It's general to any changeset VCS, where
rollback is necessarily a repository-oriented operation rather than a
file-oriented one.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Removing rollback from VC mode - request for comment

[Eli Zaretskii]

> From: Steinar Bang <sb@dod.no>
> Date: Thu, 11 Dec 2014 13:42:22 +0100
> 
> >>>>> Ted Zlatanov <tzz@lifelogs.com>:
> 
> > I think Git should support it anyway, with rollback to any commit.
> > That's just a "git reset".
> 
> "git reset --hard", actually.

Not necessarily; both variants have their place.  It all depends on
the scenario.

Re: Removing rollback from VC mode - request for comment

[Steinar Bang]

>>>>> esr@snark.thyrsus.com (Eric S. Raymond):

> Rollback is a case in point.  It is a command that lets you undo the
> last checkin.  Only SCCS and RCS actually support it.  Git possibly 
> could, in theory, but the Git implementation would be tricky and have 
> sharp edges when the last revision had been pushed.

You could allow git rollback for branches that are only local (ie. not a
tracking branch for a remote).

Re: Removing rollback from VC mode - request for comment

[Steinar Bang]

>>>>> Steinar Bang <sb@dod.no>:

>>>>> esr@snark.thyrsus.com (Eric S. Raymond):
>> Rollback is a case in point.  It is a command that lets you undo the
>> last checkin.  Only SCCS and RCS actually support it.  Git possibly 
>> could, in theory, but the Git implementation would be tricky and have 
>> sharp edges when the last revision had been pushed.

> You could allow git rollback for branches that are only local (ie. not a
> tracking branch for a remote).

Or maybe better: disallow rollback if the current branch is a tracking
branch, that is up to date with the remote branch it is tracking.

Re: Removing rollback from VC mode - request for comment

[Eric S. Raymond]

Steinar Bang <sb@dod.no>:
> > You could allow git rollback for branches that are only local (ie. not a
> > tracking branch for a remote).
> 
> Or maybe better: disallow rollback if the current branch is a tracking
> branch, that is up to date with the remote branch it is tracking.

I could.  But step back from those details for a moment and consider
the larger picture.

The VC Git support is now about ten years old.  In all that time, the
fact that Ctrl-x v c is not bound to git reset seems never to have
been reported as a bug or wishlist item.  This suggests to me that
there is little or no demand for the feature.

Furthermore (and this is new information, I didn't know it when I
wrote the RFC) the Texinfo documentation contains this comment:

@c `C-x v c' (vc-rollback) was removed, since it's RCS/SCCS specific.

Looks like somebody else noticed this feature was a vermiform appendix.

I probably wouldn't be gunning for rollback if it weren't a history eraser.
But the fact that it is one means that leaving it in will have a cost
measured in the number of users who shoot self in foot.

Given that, I don't think "we *could* support it in Git" is adequate in
the absence of user demand for it.  Anyone can correct me on this by
showing evidence of such demand.  Google searches didn't turn up any. 

Mind not made up yet.  But leaning more towards deleting, now.  Willing
to listen to a more spirited defense.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Removing rollback from VC mode - request for comment

[David Kastrup]

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

> Steinar Bang <sb@dod.no>:
>> > You could allow git rollback for branches that are only local (ie. not a
>> > tracking branch for a remote).
>> 
>> Or maybe better: disallow rollback if the current branch is a tracking
>> branch, that is up to date with the remote branch it is tracking.
>
> I could.  But step back from those details for a moment and consider
> the larger picture.
>
> The VC Git support is now about ten years old.  In all that time, the
> fact that Ctrl-x v c is not bound to git reset seems never to have
> been reported as a bug or wishlist item.  This suggests to me that
> there is little or no demand for the feature.
>
> Furthermore (and this is new information, I didn't know it when I
> wrote the RFC) the Texinfo documentation contains this comment:
>
> @c `C-x v c' (vc-rollback) was removed, since it's RCS/SCCS specific.
>
> Looks like somebody else noticed this feature was a vermiform appendix.
>
> I probably wouldn't be gunning for rollback if it weren't a history eraser.
> But the fact that it is one means that leaving it in will have a cost
> measured in the number of users who shoot self in foot.
>
> Given that, I don't think "we *could* support it in Git" is adequate in
> the absence of user demand for it.  Anyone can correct me on this by
> showing evidence of such demand.

git rebase -i is rollback on steroids and is definitely seeing a lot of
active use.  Rollback by itself is not all that interesting.

-- 
David Kastrup

Re: Removing rollback from VC mode - request for comment

[Ted Zlatanov]

On Thu, 11 Dec 2014 07:36:29 -0500 "Eric S. Raymond" <esr@thyrsus.com> wrote: 

ESR> The VC Git support is now about ten years old.  In all that time, the
ESR> fact that Ctrl-x v c is not bound to git reset seems never to have
ESR> been reported as a bug or wishlist item.  This suggests to me that
ESR> there is little or no demand for the feature.

Most of us use the command line or Magit.  Those work fine.

ESR> Mind not made up yet.  But leaning more towards deleting, now.  Willing
ESR> to listen to a more spirited defense.

Talk like Yoda, will you.

On Thu, 11 Dec 2014 13:42:22 +0100 Steinar Bang <sb@dod.no> wrote: 

>>>>>> Ted Zlatanov <tzz@lifelogs.com>:

>> I think Git should support it anyway, with rollback to any commit.
>> That's just a "git reset".

SB> "git reset --hard", actually.

While they are both useful, I find `git reset' gentler because it
doesn't lose my changes. It's a soft rollback, perhaps.

SB> But there is one complication that git commits may span more files than
SB> the one file currently seen by vc-git.el, and if so: what do you do?

You tell the user "the rollback will affect more files than you
currently see."

ESR> The problem is not specific to Git.  It's general to any changeset VCS, where
ESR> rollback is necessarily a repository-oriented operation rather than a
ESR> file-oriented one.

Magit and the command line interface do all right.

Ted

Re: Removing rollback from VC mode - request for comment

[Steinar Bang]

>>>>> Ted Zlatanov <tzz@lifelogs.com>:

> Magit and the command line interface do all right.

Well... er... actually... you're right...

Re: Removing rollback from VC mode - request for comment

[Eli Zaretskii]

> Date: Thu, 11 Dec 2014 07:36:29 -0500
> From: "Eric S. Raymond" <esr@thyrsus.com>
> 
> The VC Git support is now about ten years old.  In all that time, the
> fact that Ctrl-x v c is not bound to git reset seems never to have
> been reported as a bug or wishlist item.  This suggests to me that
> there is little or no demand for the feature.

You assume that many people use VC with Git.  But that is not
necessarily so; I suspect that most people who use Git from Emacs (as
opposed to the shell) do it via magit instead.

IMO, if VC is to win hearts on the Git front, it should grow more
features, not less.  It is IMO sad, if not ridiculous, that I cannot
uncommit the last commit, and have to go outside Emacs for that.
Likewise with 'amend' and 'cherrypick' and half a dozen of other
commands we use every day in our workflows.

Re: Removing rollback from VC mode - request for comment

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

> You assume that many people use VC with Git.  But that is not
> necessarily so; I suspect that most people who use Git from Emacs (as
> opposed to the shell) do it via magit instead.

This is true, if you replace VC with VC-dir. Magit does not provide
convenient ways for doing certain operations, because VC does those well
enough. So Magit and VC are complementary, except for VC-dir, which is
the feature set that Magit covers.

> IMO, if VC is to win hearts on the Git front, it should grow more
> features, not less.

Right. However, it is difficult for a generic UI (VC) to compete with a
specific one (Magit).

[snip]

Re: Removing rollback from VC mode - request for comment

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Thu, 11 Dec 2014 18:01:05 +0100
> 
> > IMO, if VC is to win hearts on the Git front, it should grow more
> > features, not less.
> 
> Right. However, it is difficult for a generic UI (VC) to compete with a
> specific one (Magit).

I see nothing in magit that couldn't be done with VC.  It just needs
to be coded.  (And I hope very much that VC does NOT try to imitate
the horrible things that magit does to the display engine.)

Re: Removing rollback from VC mode - request for comment

[Steinar Bang]

>>>>> Eli Zaretskii <eliz@gnu.org>:

> (And I hope very much that VC does NOT try to imitate the horrible
> things that magit does to the display engine.)

What's that? And is that (ie. the horrible things magit does to the
display engine) the reason magit isn't a incorporated into emacs?

Re: Removing rollback from VC mode - request for comment

[Stefan Monnier]

>> (And I hope very much that VC does NOT try to imitate the horrible
>> things that magit does to the display engine.)
> What's that?

FWIW I don't know.  Then again, I haven't yet looked very much at Magit.

> And is that (ie. the horrible things magit does to the
> display engine) the reason magit isn't a incorporated into emacs?

No, I the only reason so far is the lack of actual effort to try and
do that.  I'd be happy to include it.


        Stefan

Re: Removing rollback from VC mode - request for comment

[Eli Zaretskii]

> From: Steinar Bang <sb@dod.no>
> Date: Thu, 11 Dec 2014 20:24:21 +0100
> 
> >>>>> Eli Zaretskii <eliz@gnu.org>:
> 
> > (And I hope very much that VC does NOT try to imitate the horrible
> > things that magit does to the display engine.)
> 
> What's that?

Look at its code.

> And is that (ie. the horrible things magit does to the display
> engine) the reason magit isn't a incorporated into emacs?

Not that I know of.

Re: Removing rollback from VC mode - request for comment

[John Mastro]

[-- Attachment #1: Type: text/plain, Size: 364 bytes --]

Eli Zaretskii <eliz@gnu.org> wrote:
> > > (And I hope very much that VC does NOT try to imitate the horrible
> > > things that magit does to the display engine.)
> >
> > What's that?
>
> Look at its code.

Would you mind providing a pointer? I'm curious but my brief
investigation was unsuccessful (when I realized I didn't know what I was
looking for).

-- 
john

[-- Attachment #2: Type: text/html, Size: 937 bytes --]

Re: Removing rollback from VC mode - request for comment

[Nicolas Richard]

John Mastro <john.b.mastro@gmail.com> writes:
> Would you mind providing a pointer? I'm curious but my brief
> investigation was unsuccessful (when I realized I didn't know what I
> was looking for).

I don't know what Eli has in mind, but perhaps magit-make-margin-overlay
is one such thing ? it is used in the "log" view to have the author in
the right margin.

-- 
Nicolas Richard

Re: Removing rollback from VC mode - request for comment

[Eli Zaretskii]

> From: Nicolas Richard <theonewiththeevillook@yahoo.fr>
> Cc: emacs-devel@gnu.org,  Eli Zaretskii <eliz@gnu.org>
> Date: Fri, 12 Dec 2014 17:01:57 +0100
> 
> I don't know what Eli has in mind, but perhaps magit-make-margin-overlay
> is one such thing ?

Yes, it's one of them.

Re: Removing rollback from VC mode - request for comment

[Jonas Bernoulli]

Eli Zaretskii <eliz@gnu.org> writes:

>> Nicolas Richard <theonewiththeevillook@yahoo.fr> writes:
>> 
>> I don't know what Eli has in mind, but perhaps magit-make-margin-overlay
>> is one such thing ?
>
> Yes, it's one of them.

`elisp(Displaying in the Margins)' states that, "to display something in
the margin _in association with_ certain buffer text, without altering
or preventing the display of that text, put a `before-string' property
on the text and put the margin display specification on the contents of
the before-string."

That's what `magit-make-margin-overlay' does:

  (defun magit-make-margin-overlay (&rest strings)
    (let ((o (make-overlay (point) (line-end-position) nil t)))
      (overlay-put o 'evaporate t)
      (overlay-put o 'before-string
                   (propertize "o" 'display
                               (list '(margin right-margin)
                                     (apply #'concat strings))))))

It seems to me that Magit is doing it the way it is supposed to be doing
it.  Is there another undocumented way?  Am I missing something?

The documentation above does not explicitly mention that an overlay has
to be used, but I could not get it to work otherwise.  There is only one
builtin package which uses `(margin [left|right]-margin)`, Linum-Mode,
and it also uses overlays, in pretty much the same way.

(There is one small difference in that Linum-Mode uses
  (make-overlay (point) (point) ...)
while Magit uses
  (make-overlay (point) (line-end-position))
which is kinda pointless because it unfortunately does not have the
desired effect of keeping to display the margin's text even when
`line-beginning-position' is scrolled of the window.  So yeah, I
could change that).

In summary, yeah this is ugly, but it ain't Magit's fault.

Or do you frown upon Magit making the margin "buffer-local" using
`magit-set-buffer-margin'?

Ps: I am only interested in constructive criticism of Magit's next
branch.  Neither broad "it's all wrong", nor wards which used to existed
in 1.2.* or master interest me.

Re: Removing rollback from VC mode - request for comment

[Eli Zaretskii]

> From: Jonas Bernoulli <jonas@bernoul.li>
> Cc: Nicolas Richard <theonewiththeevillook@yahoo.fr>, john.b.mastro@gmail.com, emacs-devel@gnu.org
> Date: Sun, 14 Dec 2014 13:11:06 +0100
> 
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Nicolas Richard <theonewiththeevillook@yahoo.fr> writes:
> >> 
> >> I don't know what Eli has in mind, but perhaps magit-make-margin-overlay
> >> is one such thing ?
> >
> > Yes, it's one of them.
> 
> `elisp(Displaying in the Margins)' states that, "to display something in
> the margin _in association with_ certain buffer text, without altering
> or preventing the display of that text, put a `before-string' property
> on the text and put the margin display specification on the contents of
> the before-string."
> 
> That's what `magit-make-margin-overlay' does:
> 
>   (defun magit-make-margin-overlay (&rest strings)
>     (let ((o (make-overlay (point) (line-end-position) nil t)))
>       (overlay-put o 'evaporate t)
>       (overlay-put o 'before-string
>                    (propertize "o" 'display
>                                (list '(margin right-margin)
>                                      (apply #'concat strings))))))
> 
> It seems to me that Magit is doing it the way it is supposed to be doing
> it.  Is there another undocumented way?  Am I missing something?

I didn't say that magit uses some undocumented feature, or uses it
contrary to documentation.  That's not the issue.

The issue is that magit uses these features too much, at times almost
completely obscuring the buffer text with display and overlay
strings.  The Emacs display engine was never meant to cope with such
massive usage of these features.  I think magit also uses a lot of
overlay/display strings with newlines, or maybe it did in the past.
That is one of the nastiest thing to do with Emacs display.  (I can
explain if you are interested.)

And frankly, I don't understand why this kind of design was necessary:
it's not like magit shows some file whose contents it can't control.
It presents a buffer that is entirely created out of thin air by Git.
If what Git generates doesn't fit what magit wants to show the user,
what prevents magit from massaging the text it gets from Git to its
heart's content, when creating the buffer?  Instead of overlaying
buffer text with display and overlay strings, it could simply format
the buffer text any way it likes, and then avoid the need to do all
that.

I hope this explains why I feel badly about that.

Re: Removing rollback from VC mode - request for comment

[Stefan Monnier]

> strings.  The Emacs display engine was never meant to cope with such
> massive usage of these features.  I think magit also uses a lot of
> overlay/display strings with newlines, or maybe it did in the past.
> That is one of the nastiest thing to do with Emacs display.  (I can
> explain if you are interested.)

FWIW, nhexl-mode is also guilty of very heavy use of display strings.

> And frankly, I don't understand why this kind of design was necessary:

I don't know enough about Magit to have an informed opinion, but your
analysis makes sense, indeed.  In the case of nhexl-mode we don't have
the luxury of changing the buffer's content.


        Stefan

Re: Removing rollback from VC mode - request for comment

[Jonas Bernoulli]

Eli Zaretskii <eliz@gnu.org> writes:

> I didn't say that magit uses some undocumented feature, or uses it
> contrary to documentation.  That's not the issue.
>
> The issue is that magit uses these features too much, at times almost
> completely obscuring the buffer text with display and overlay
> strings.  The Emacs display engine was never meant to cope with such
> massive usage of these features.  I think magit also uses a lot of
> overlay/display strings with newlines, or maybe it did in the past.
> That is one of the nastiest thing to do with Emacs display.  (I can
> explain if you are interested.)

Magit uses a lot of overlays indeed, but that is slowly being phased out
where possible.

One thing that will certainly stay is that section bodies are made
invisible using the invisible text-property.  I cannot think of another
place were Magit hides text.  You mention newlines being molested, but
I cannot remember having seen anything like that in Magit.

Back to overlays.  Magit highlights the current section(s) using an
overlay, which by default changes the background color like the region
does.  Unlike the region, it is always visible and it would therefor be
undesirable if it did overwrite text-property backgrounds.  To some
users that would be annoying for example in logs where "ref labels" like
branch names and tags, would lose their background.

Since overlays always win against text-properties the only way to keep
the backgrounds of various pieces of text visible, is to paint them
using overlays.  I agree that is icky, but as long as overlays cannot
have a negative priority, I can see why people use this sort of hack.

Unfortunately there was no abstraction to do this in Magit and some of
the ad hock implementations had severe bugs.  A lot of cleaning up later
there is an abstraction: `magit-insert'.  Like `insert' it inserts the
strings, but unlike that it also moves the face property to an overlay.
It's a hack.  The only thing missing is an option to control whether it
should do this at all, then it would behave more or less like `insert'
together with `propertize'.

Once that option exists and is set to *off* Magit won't use overlays in
any excessive kind of way anymore.  I will do that once I have changed
the "default themes" to not set the background anymore.

But this is not something that can be changed without there being a way
to "go back as it was in the good old days".  Users will protest about
this, even when there is an option to enable the hack again.

> And frankly, I don't understand why this kind of design was necessary:
> it's not like magit shows some file whose contents it can't control.
> It presents a buffer that is entirely created out of thin air by Git.

Mostly historic accidents, I think, and because negative priorities
haven't been implemented.

> If what Git generates doesn't fit what magit wants to show the user,
> what prevents magit from massaging the text it gets from Git to its
> heart's content, when creating the buffer?

Not much, and in fact that's what it is doing most of the time, except
when `magit-insert' is used.  There are other places where overlays are
used, but once `magit-insert' has been taught to not do so, they won't
be used excessively anymore.

> Instead of overlaying buffer text with display and overlay strings, it
> could simply format the buffer text any way it likes, and then avoid
> the need to do all that.

If a user wants to highlight the current section and also refnames with
a background color, which don't get lost, then Magit *does* have to use
overlays.  I wouldn't have added the overlay hack in the first place but
it has existed for years now, and cannot be removed completely because
doing that would be perceived as a regression.

> I hope this explains why I feel badly about that.

Yes.  I think you are saying that using these techniques aren't bad
per se, but that using them excessively has a negative impact on
performance.  The point I am trying to make is that I generally agree,
but there is/was a reason why it is/was done this way.  Also I think,
that while Magit has some performance issues, the use of overlays isn't
really a major cause of this.  And I am prioritizing fixing actual
performance issues over dealing with the overlay problem.

Re: Removing rollback from VC mode - request for comment

[Eli Zaretskii]

> From: Jonas Bernoulli <jonas@bernoul.li>
> Cc: theonewiththeevillook@yahoo.fr, john.b.mastro@gmail.com, emacs-devel@gnu.org
> Date: Mon, 15 Dec 2014 14:10:10 +0100
> 
> Magit uses a lot of overlays indeed, but that is slowly being phased out
> where possible.

That's very good news, thanks.

> One thing that will certainly stay is that section bodies are made
> invisible using the invisible text-property.

Invisible text is not too bad in itself, but beware of hiding too much
of it: it causes user dissatisfaction when redisplay seems to become
sluggish (because what the user sees as a small amount of text is
actually a very large chunk, and the display engine needs to traverse
it when it makes layout decisions).

> I cannot think of another place were Magit hides text.  You mention
> newlines being molested, but I cannot remember having seen anything
> like that in Magit.

Maybe it was in the past.  Or maybe I just misremembered.

> Back to overlays.  Magit highlights the current section(s) using an
> overlay, which by default changes the background color like the region
> does.

Overlays that change colors or other visual attributes of buffer text
don't bother me.  I was talking about overlay strings and display
properties that are strings.

> > Instead of overlaying buffer text with display and overlay strings, it
> > could simply format the buffer text any way it likes, and then avoid
> > the need to do all that.
> 
> If a user wants to highlight the current section and also refnames with
> a background color, which don't get lost, then Magit *does* have to use
> overlays.

Again, this use of overlays isn't a problem from my POV.  I meant only
displaying text that isn't actually in the buffer, by using overlay
and display strings.

Thanks.

Re: Removing rollback from VC mode - request for comment

[Eli Zaretskii]

> From: John Mastro <john.b.mastro@gmail.com>
> Date: Fri, 12 Dec 2014 07:44:37 -0800
> Cc: Eli Zaretskii <eliz@gnu.org>
> 
> > > > (And I hope very much that VC does NOT try to imitate the horrible
> > > > things that magit does to the display engine.)
> > >
> > > What's that?
> > 
> > Look at its code.
> 
> Would you mind providing a pointer?

Not sure what kind of pointer you are asking for.

What I meant is that magit almost completely conceals the buffer text
with display strings and overlays that display something entirely
different.  Emacs's display engine was never designed to work in such
conditions, and it's a wonder in my eyes that it doesn't break
completely, or at least becomes unbearably slow.

Re: Removing rollback from VC mode - request for comment

[Rasmus]

Steinar Bang <sb@dod.no> writes:

>>>>>> Eli Zaretskii <eliz@gnu.org>:
>
>> (And I hope very much that VC does NOT try to imitate the horrible
>> things that magit does to the display engine.)
>
> What's that? And is that (ie. the horrible things magit does to the
> display engine) the reason magit isn't a incorporated into emacs?

The current maintainer, Jonas Bernoulli, has mentioned that he would like
to integrate some of the code into Emacs at some point, maybe, eventually.
See:

   http://permalink.gmane.org/gmane.emacs.devel/174727
   https://github.com/magit/magit/issues/1107

—Rasmus

-- 
Hvor meget poesi tror De kommer ud af et glas isvand?

Re: Removing rollback from VC mode - request for comment

[Eric S. Raymond]

Eli Zaretskii <eliz@gnu.org>:
> IMO, if VC is to win hearts on the Git front, it should grow more
> features, not less.  It is IMO sad, if not ridiculous, that I cannot
> uncommit the last commit, and have to go outside Emacs for that.

That is not a bad argument in general.  Actually it's the best I've
seen for keeping and extending rollback.

> Likewise with 'amend' and 'cherrypick' and half a dozen of other
> commands we use every day in our workflows.

Amend is already supported in git, but the UI for it is strange.  It's
on my list to make that more uniform across backends.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Removing rollback from VC mode - request for comment

[Stephen J. Turnbull]

Eric S. Raymond writes:
 > Eli Zaretskii <eliz@gnu.org>:
 > > IMO, if VC is to win hearts on the Git front, it should grow more
 > > features, not less.  It is IMO sad, if not ridiculous, that I cannot
 > > uncommit the last commit, and have to go outside Emacs for that.
 > 
 > That is not a bad argument in general.  Actually it's the best I've
 > seen for keeping and extending rollback.

Except that the term itself is inconsistent with standard database
terminology, where rollback aborts an in-progress transaction, i.e.,
is basically equivalent to "git reset --soft HEAD".  I've always found
that confusing.

AFAICT, hg's rollback command, while it will destructively strip a
commit (to preserve the commit as a bundle, hg provides the
intuitively named "hg strip"), is really more intended to abort and
rollback merges with "too complicated" conflicts and the like *before*
committing.

I understand that vc has provided rollback "forever", but if you
decide to take Richard's suggestion of removing rollback's code and
providing a complete replacement, think about renaming the
functionality.

Re: Removing rollback from VC mode - request for comment

[Eric S. Raymond]

Stephen J. Turnbull <stephen@xemacs.org>:
> I understand that vc has provided rollback "forever", but if you
> decide to take Richard's suggestion of removing rollback's code and
> providing a complete replacement, think about renaming the
> functionality.

I intend to follow Stefan's suggestion of "uncommit".
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Removing rollback from VC mode - request for comment

[Steinar Bang]

>>>>> "Stephen J. Turnbull" <stephen@xemacs.org>:

> AFAICT, hg's rollback command, while it will destructively strip a
> commit (to preserve the commit as a bundle, hg provides the
> intuitively named "hg strip"), 

Huh...?  Do you really mean to say that
 git reset HEAD~1
or
 git reset --hard HEAD~1
isn't safe (especially the last one), and intuitive...?

Re: Removing rollback from VC mode - request for comment

[Stefan Monnier]

>  git reset --hard HEAD~1
> isn't safe (especially the last one), and intuitive...?

Well, no admittedly, I would have intuitively put a % rather than a ~


        Stefan

Re: Removing rollback from VC mode - request for comment

[Sergey Organov]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>  git reset --hard HEAD~1
>> isn't safe (especially the last one), and intuitive...?
>
> Well, no admittedly, I would have intuitively put a % rather than a ~

It's commit "HEAD minus 1". Why '%'?

Re: Removing rollback from VC mode - request for comment

[Stefan Monnier]

>>> git reset --hard HEAD~1
>>> isn't safe (especially the last one), and intuitive...?
>> Well, no admittedly, I would have intuitively put a % rather than a ~
> It's commit "HEAD minus 1". Why '%'?

Intuition is hard to explain ;-)


        Stefan

Re: Removing rollback from VC mode - request for comment

[Stephen J. Turnbull]

Steinar Bang writes:
 > >>>>> "Stephen J. Turnbull" <stephen@xemacs.org>:
 > 
 > > AFAICT, hg's rollback command, while it will destructively strip a
 > > commit (to preserve the commit as a bundle, hg provides the
 > > intuitively named "hg strip"), 
 > 
 > Huh...?  Do you really mean to say that
 >  git reset HEAD~1
 > or
 >  git reset --hard HEAD~1
 > isn't safe (especially the last one), and intuitive...?

I don't see where I said anything about git at all.  I was discussing
hg.

The only thing in git that destroys commits AFAIK is git-gc.

Re: Removing rollback from VC mode - request for comment

[Steinar Bang]

>>>>> "Stephen J. Turnbull" <stephen@xemacs.org>:

> I don't see where I said anything about git at all.  I was discussing
> hg.

I made an attempt at a joke.

It fell flat.

Though crowd.

> The only thing in git that destroys commits AFAIK is git-gc.

My favourite variant here, is (of course):
 git gc --aggressive --now

Re: Removing rollback from VC mode - request for comment

[Stefan Monnier]

> It fell flat.

FWIW, I liked it,


        Stefan

Re: Removing rollback from VC mode - request for comment

[Stephen J. Turnbull]

Steinar Bang writes:

 > I made an attempt at a joke.

I have no clue what you and Stefan think is funny about that, unless
you think that hg strip and git reset --hard are homomorphic.  That
Stefan could hold that idea makes me want to cry, not laugh.

Re: Removing rollback from VC mode - request for comment

[David Kastrup]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Steinar Bang writes:
>
>  > I made an attempt at a joke.
>
> I have no clue what you and Stefan think is funny about that, unless
> you think that hg strip and git reset --hard are homomorphic.  That
> Stefan could hold that idea makes me want to cry, not laugh.

That's the reason that Stefan is the maintainer of Emacs, and you of
XEmacs.  Different code making you laugh and cry.

-- 
David Kastrup

Re: Removing rollback from VC mode - request for comment

[Achim Gratz]

Eric S. Raymond writes:
> The VC Git support is now about ten years old.  In all that time, the
> fact that Ctrl-x v c is not bound to git reset seems never to have
> been reported as a bug or wishlist item.  This suggests to me that
> there is little or no demand for the feature.

No, that suggests that everyone who has looked at vc and wanted to use
Git to its full potential has decided to use magit instead.  I did,
anyway.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: Removing rollback from VC mode - request for comment

[Steinar Bang]

>>>>> Achim Gratz <Stromeko@nexgo.de>:

> No, that suggests that everyone who has looked at vc and wanted to use
> Git to its full potential has decided to use magit instead.  I did,
> anyway.

I use vc-git.el for blame and history, and for walking blame results to
see their their diffs, and magit and the command line for the rest.

Using vc-git in this way is hampered by vc-git not tracking history
across renames.

Re: Removing rollback from VC mode - request for comment

[Stefan Monnier]

> Using vc-git in this way is hampered by vc-git not tracking history
> across renames.

Indeed, vc-git.el should use --follow when possible.

BTW, while implementing vc-region-history (which only works with vc-git
so far and for the foreseeable future) I noticed that Git does not
support --follow for the -L%d,%d:%s case, even though that only applies
to a single file.


        Stefan

vc-region-authors (or some such)

[Sebastien Vauban]

Hello Stefan,

Stefan Monnier wrote:
>> Using vc-git in this way is hampered by vc-git not tracking history
>> across renames.
>
> Indeed, vc-git.el should use --follow when possible.
>
> BTW, while implementing vc-region-history (which only works with vc-git
> so far and for the foreseeable future) I noticed that Git does not
> support --follow for the -L%d,%d:%s case, even though that only applies
> to a single file.

Talking of `vc-region-history' reminded me of a feature I find powerful,
would it be easily available: "showing blame information about original
authors of lines changed or removed in a given branch".

  ┌────
  │ "This is useful when opening pull requests per GitHub Flow; you'll want
  │ your pull request reviewed by colleagues but you might not be sure who
  │ to ping. With git-overwritten you'll get the names of people who wrote
  │ the lines you just changed, so you'll know who to @-mention when opening
  │ a pull request."
  │  
  │ -- http://mislav.uniqpath.com/2014/02/hidden-documentation/, "Bonus script"
  └────

Maybe it'd be worth to think about that as well while implementing
`vc-region-history'. It seems to be its twin, no?

Best regards,
  Seb

-- 
Sebastien Vauban

Re: vc-region-authors (or some such)

[Stefan Monnier]

> Talking of `vc-region-history' reminded me of a feature I find powerful,
> would it be easily available: "showing blame information about original
> authors of lines changed or removed in a given branch".

So, given a patch (or a branch) together with a "base revision", you'd get
a list of code chunks modified by that patch, then run "annotate" on the
base revision, and look for those code chunks, collecting the names of
corresponding authors.

Sounds useful, indeed.  Patch welcome.

> Maybe it'd be worth to think about that as well while implementing
> `vc-region-history'. It seems to be its twin, no?

Kind of, but the implementation of one doesn't seem to help the
implementation of the other.


        Stefan

Re: vc-region-authors (or some such)

[Dmitry Gutov]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> So, given a patch (or a branch) together with a "base revision", you'd get
> a list of code chunks modified by that patch, then run "annotate" on the
> base revision, and look for those code chunks, collecting the names of
> corresponding authors.

Sounds like git-guilt (which I've just read about today), might be
relevant: https://bitbucket.org/tpettersen/git-guilt

Re: Removing rollback from VC mode - request for comment

[Stefan Monnier]

> Rollback is a case in point.  It is a command that lets you undo the
> last checkin.  Only SCCS and RCS actually support it.  Git possibly 
> could, in theory, but the Git implementation would be tricky and have 
> sharp edges when the last revision had been pushed.

Actually, I think most VCS can support it one way or another.

> might be using it on some remnant RCS repo (I think we can safely
> consider SCCS dead to us at this point).  And the broader question is

We've had some bug reports about vc-sccs.el in the
not-completely-distant past, so there might still be such people
out there.

But contrary to what the above two statements might lead you to think,
I'm in favor of removing this rollback, because I don't think it's good
enough as it stands.  E.g. I think it should be replaced by an
`uncommit' which would be the opposite of `commit' and should ideally
preserve as much info as possible (e.g. not change the file's contents,
and stash the commit message somewhere so it can be re-used if you
decide to recommit).


        Stefan

Re: Removing rollback from VC mode - request for comment

[Sergey Organov]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

[...]

> E.g. I think it should be replaced by an `uncommit' which would be
> the opposite of `commit' and should ideally preserve as much info as
> possible (e.g. not change the file's contents, and stash the commit
> message somewhere so it can be re-used if you decide to recommit).

Magit has nice feature of commit messages history. Once you have that,
there is no need to treat this case specially, I think.

-- 
Sergey.

Re: Removing rollback from VC mode - request for comment

[Eric S. Raymond]

Stefan Monnier <monnier@iro.umontreal.ca>:
> > Rollback is a case in point.  It is a command that lets you undo the
> > last checkin.  Only SCCS and RCS actually support it.  Git possibly 
> > could, in theory, but the Git implementation would be tricky and have 
> > sharp edges when the last revision had been pushed.
> 
> Actually, I think most VCS can support it one way or another.

It's not hard to simulate using what in git terms is a reverse cherry pick.
But modifying history in place is very difficult to do with a good outcome.
 
> But contrary to what the above two statements might lead you to think,
> I'm in favor of removing this rollback, because I don't think it's good
> enough as it stands.  E.g. I think it should be replaced by an
> `uncommit' which would be the opposite of `commit' and should ideally
> preserve as much info as possible (e.g. not change the file's contents,
> and stash the commit message somewhere so it can be re-used if you
> decide to recommit).

Interesting idea. I think you are right that this is what people usually
want - "oops, I just committed something incomplete, let me get back to
the repo and workfile state just before I hit the button, with the commit
message stashed for re-use".

The question then becomes whether preserving the rollback methods we have
now gets us anywhere towards that.

/me reads the code for vc-rcs-rollback.

And the answer is..no, not really.  The RCS backend code for coping
at a branch base might be slightly useful, but the rest is designed 
for a different UI and would have to be tossed out anyway.

Conclusion: rollback should indeed be scrapped, and uncommit added to
the list of features to be done along with stash/shelve support.  

It'll take a while, though.  Michael Albinus and I are finding a lot
of bit-rot.  He just told me that six of the eight working-revision
backend functions don't work right. Much repair is required before
adding new features.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Removing rollback from VC mode - request for comment

[Stefan Monnier]

>> Actually, I think most VCS can support it one way or another.
> It's not hard to simulate using what in git terms is a reverse cherry pick.

IIUC "reverse cherry pick" adds a new commit, so it's a different
operation, which does not require any special support (it's a normal
cherry pick, basically).

> But modifying history in place is very difficult to do with a good outcome.

The "clean" way to look at this feature is:
- create a new branch BAR off of the target revision.
- delete the current branch FOO.
- rename BAR to FOO.
- adjust the current checkout, if needed, in accordance with the new FOO.
AFAIK, most current VCS offer those operations.

> It'll take a while, though.  Michael Albinus and I are finding a lot
> of bit-rot.  He just told me that six of the eight working-revision
> backend functions don't work right. Much repair is required before
> adding new features.

That's OK, but:
- please make sure you get back promptly to replacing the removed features.
- the more important the feature, the shorter the delay before you
  replace it.



        Stefan

Re: Removing rollback from VC mode - request for comment

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Interesting idea. I think you are right that this is what people usually
  > want - "oops, I just committed something incomplete, let me get back to
  > the repo and workfile state just before I hit the button, with the commit
  > message stashed for re-use".

  > The question then becomes whether preserving the rollback methods we have
  > now gets us anywhere towards that.

That was always the reason I used vc-rollback, and it seemed to do
that job just fine.  What's lacking?

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Removing rollback from VC mode - request for comment

[Eric S. Raymond]

Richard Stallman <rms@gnu.org>:
>   > Interesting idea. I think you are right that this is what people usually
>   > want - "oops, I just committed something incomplete, let me get back to
>   > the repo and workfile state just before I hit the button, with the commit
>   > message stashed for re-use".
> 
>   > The question then becomes whether preserving the rollback methods we have
>   > now gets us anywhere towards that.
> 
> That was always the reason I used vc-rollback, and it seemed to do
> that job just fine.  What's lacking?

Leaving the *modified* workfile in place rather than reverting it.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Removing rollback from VC mode - request for comment

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > That was always the reason I used vc-rollback, and it seemed to do
  > > that job just fine.  What's lacking?

  > Leaving the *modified* workfile in place rather than reverting it.

That's not a bug, that's a feature.  When I used C-x v c, I wanted to
cancel the last checkin and keep the current file contents.  Then I
would do a new checkin.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Removing rollback from VC mode - request for comment

[Eric S. Raymond]

Richard Stallman <rms@gnu.org>:
>   > > That was always the reason I used vc-rollback, and it seemed to do
>   > > that job just fine.  What's lacking?
> 
>   > Leaving the *modified* workfile in place rather than reverting it.
> 
> That's not a bug, that's a feature.  When I used C-x v c, I wanted to
> cancel the last checkin and keep the current file contents.  Then I
> would do a new checkin.

One of us is confused, possibly me. That's how Stefan and I meant it
should work, too - that's what we mean by "uncommit".  Maybe rollback
worked that way at one time, but the RCS code before I deleted it said
this:

            ;; Check out the most recent remaining version.  If it
            ;; fails, because the whole branch got deleted, do a
            ;; double-take and check out the version where the branch
            ;; started.

It was followed by co -u.  So either it never worked the way all three
of us think it should, or it did at one time but someone "corrected" it
to leave the master and workfile in what they thought was a more coherent
state. The latter seems not unlikely.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Removing rollback from VC mode - request for comment

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > It was followed by co -u.  So either it never worked the way all three
  > of us think it should, or it did at one time but someone "corrected" it
  > to leave the master and workfile in what they thought was a more coherent
  > state. The latter seems not unlikely.

What does the change log say about this function?

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Removing rollback from VC mode - request for comment

[Eric S. Raymond]

Richard Stallman <rms@gnu.org>:
>   > It was followed by co -u.  So either it never worked the way all three
>   > of us think it should, or it did at one time but someone "corrected" it
>   > to leave the master and workfile in what they thought was a more coherent
>   > state. The latter seems not unlikely.
> 
> What does the change log say about this function?

Looking...nothing indicative.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Removing rollback from VC mode - request for comment

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 627 bytes --]

() "Eric S. Raymond" <esr@thyrsus.com>
() Sun, 14 Dec 2014 05:04:48 -0500

   > What does the change log say about this function?

   Looking...nothing indicative.

Well, it looks like ‘vc-rollback’ originally was named
‘vc-cancel-version’ (losing prefix arg support -- the
first jerk), then was subsequently jerked around some
more.  I fear the jerking is nowhere near finished.

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Removing rollback from VC mode - request for comment

[Karl Fogel]

esr@snark.thyrsus.com (Eric S. Raymond) writes:
>Rollback is a case in point.  It is a command that lets you undo the
>last checkin.  Only SCCS and RCS actually support it.  Git possibly 
>could, in theory, but the Git implementation would be tricky and have 
>sharp edges when the last revision had been pushed.

The above is about reverting the most recent checkin, but...

>2. VC in particular, and version-control systems in general, have
>moved towards a philosophy of making history destruction difficult.
>Old school, saving disk space was important enough that removing
>deltas was actually done as an economy measure.  New school, making 
>it difficult for the user to shoot self in foot is a higher virtue.
>
>The argument against this is simply that someone, somewhere out there,
>might be using it on some remnant RCS repo (I think we can safely
>consider SCCS dead to us at this point).  And the broader question is
>whether that possibility is a dealbreaker.

...this sounds more like the elimination of older revisions (i.e., not necessarily removing the last revision, but rather eliding/collapsing older revisions so that some contiguous series of past commits get folded into one commit in history).

You're only talking about the former, though, right?

If so, Git supports it quite well (as long as one hasn't pushed the change upstream somewhere, that is, but that's not necessarily VC's responsibility to notice).  So offering it for the git backend shouldn't be a problem...

However, if it's too much hair to support, +1 on removing it.

Best,
­K

Re: Removing rollback from VC mode - request for comment

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > 2. VC in particular, and version-control systems in general, have
  > moved towards a philosophy of making history destruction difficult.

I think that philosophy is simply mistaken.

When Emacs used RCS, I sometimes cancelled my own checkins, and it
wasn't for the sake of disk space.  It was to simplify the history, by
replacing a mistake with the checkin that should have been made.

This would be just as useful now.  It ought to be added to other
version systems.

However, I am not going to argue for keeping the existing rollback
code in VC merely in the hope that rollback will be implemented in
more version systems.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Removing rollback from VC mode - request for comment

[Uwe Brauer]

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

   > I am trying to simplify and clean up the back-end API of VC mode. 
[snip]


   > Rollback is a case in point.  It is a command that lets you undo the
   > last checkin.  Only SCCS and RCS actually support it.  Git possibly 
   > could, in theory, but the Git implementation would be tricky and have 
   > sharp edges when the last revision had been pushed.

   > Here are the arguments for doing this:


   > The argument against this is simply that someone, somewhere out there,
   > might be using it on some remnant RCS repo (I think we can safely
   > consider SCCS dead to us at this point).  And the broader question is
   > whether that possibility is a dealbreaker.

   > Is it really important to support a VC-mode operation that experience
   > has shown to generally be a Bad Thing, simply to preserve backward
   > compatibility?  How do we evaluate tradeoffs when a featurectomy
   > would reduce maintenance burden and possibly improve the quality
   > of support for new systems?

   > I don't think I have a pat answer to these questions.  Discuss.

From a very practical point of view: I use RCS on most of my longer
latex documents, as it happens (without going into details) sometimes,
not very often but often enough, the coding is scrambled during a check-in
making the LaTeX file completely useless. In that case I simply remove
the last commit and I am back in business again. Removing this feature
would be a deal breaker for me.

Uwe Brauer 

Re: Removing rollback from VC mode - request for comment

[David Kastrup]

Uwe Brauer <oub@mat.ucm.es> writes:

> From a very practical point of view: I use RCS on most of my longer
> latex documents, as it happens (without going into details) sometimes,
> not very often but often enough, the coding is scrambled during a
> check-in making the LaTeX file completely useless.

And I thought nobody was using X-Symbol anymore.

> In that case I simply remove the last commit and I am back in business
> again. Removing this feature would be a deal breaker for me.

If you have one directory per document, Git tends to be a more flexible
solution.  Admittedly, it is not all that good for keeping independent
files in the same directory versioned independently (sort of like a
glorified file backup).  It would be an interesting exercise to teach
this modus operandi to Emacs/VC (basically, keep a separate .git style
directory for each file-gittified file and set the respective
environment variable or command line argument to it for VC operations).

-- 
David Kastrup

Re: Removing rollback from VC mode - request for comment

[Uwe Brauer]

>> "David" == David Kastrup <dak@gnu.org> writes:

   > Uwe Brauer <oub@mat.ucm.es> writes:
   >> From a very practical point of view: I use RCS on most of my longer
   >> latex documents, as it happens (without going into details) sometimes,
   >> not very often but often enough, the coding is scrambled during a
   >> check-in making the LaTeX file completely useless.

   > And I thought nobody was using X-Symbol anymore.

I didn't mention x-symbol explicitly but you got me. :-D

   >> In that case I simply remove the last commit and I am back in business
   >> again. Removing this feature would be a deal breaker for me.

   > If you have one directory per document, Git tends to be a more flexible
   > solution. 

Some time ago I gave git+vc a try but then found it to complicated for
my purposes and was back with good old RCS.

   >  Admittedly, it is not all that good for keeping independent
   > files in the same directory versioned independently (sort of like a
   > glorified file backup). 

This is my situation.

   >  It would be an interesting exercise to teach
   > this modus operandi to Emacs/VC (basically, keep a separate .git style
   > directory for each file-gittified file and set the respective
   > environment variable or command line argument to it for VC operations).

Re: Removing rollback from VC mode - request for comment

[David Kastrup]

Uwe Brauer <oub@mat.ucm.es> writes:

>>> "David" == David Kastrup <dak@gnu.org> writes:
>
>    > Uwe Brauer <oub@mat.ucm.es> writes:
>    >> From a very practical point of view: I use RCS on most of my longer
>    >> latex documents, as it happens (without going into details) sometimes,
>    >> not very often but often enough, the coding is scrambled during a
>    >> check-in making the LaTeX file completely useless.
>
>    > And I thought nobody was using X-Symbol anymore.
>
> I didn't mention x-symbol explicitly but you got me. :-D

Well, it was the inspiration for preview-latex's "never touch the buffer
text" philosophy.  It would be interesting to redo X-Symbol with text
overlays rather than actual text replacements, but it could trigger
performance problems.

>    >  Admittedly, [Git] is not all that good for keeping independent
>    > files in the same directory versioned independently (sort of like
>    > a glorified file backup).
>
> This is my situation.

Ok.

-- 
David Kastrup

Re: Removing rollback from VC mode - request for comment

[Stefan Monnier]

> Well, it was the inspiration for preview-latex's "never touch the buffer
> text" philosophy.  It would be interesting to redo X-Symbol with text
> overlays rather than actual text replacements, but it could trigger
> performance problems.

Which part of X-Symbol is still useful?


        Stefan

Re: Removing rollback from VC mode - request for comment

[Uwe Brauer]

>> "Stefan" == Stefan Monnier <monnier@iro.umontreal.ca> writes:

   >> Well, it was the inspiration for preview-latex's "never touch the buffer
   >> text" philosophy.  It would be interesting to redo X-Symbol with text
   >> overlays rather than actual text replacements, but it could trigger
   >> performance problems.

   > Which part of X-Symbol is still useful?

I'd say the idea to have code, which does not even rely on correct latex
syntax, nor on a working Latex installation, to have semi-WYSIWYG for
buffers containing math formula.

   >         Stefan

Re: Removing rollback from VC mode - request for comment

[Stefan Monnier]

>> Which part of X-Symbol is still useful?
> I'd say the idea to have code, which does not even rely on correct latex
> syntax, nor on a working Latex installation, to have semi-WYSIWYG for
> buffers containing math formula.

I remember X-Symbol, but most of its feature set has been replaced by
other things (e.g. input-methods, or \inputenc{utf8} which lets you use
actual accented chars in the file).  Are you referring to the replacement
of "\alpha" with an "α" and things like that?

These could be added via prettify-symbols-mode (which, like
preview-latex relies on redisplay features rather than modifying the
actual buffer's content).


        Stefan

Re: Removing rollback from VC mode - request for comment

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 1087 bytes --]



   > I remember X-Symbol, but most of its feature set has been replaced by
   > other things (e.g. input-methods, or \inputenc{utf8} which lets you use

Do you mean \usepackage[utf8]{inputenc}

   > actual accented chars in the file).  Are you referring to the replacement
   > of "\alpha" with an "α" and things like that?

Do you mean (set-input-method "TeX")? 

Last time I looked into that, my impression was this functionality
included less symbols than x-symbols. Besides sub and super indices were
not supported.[1]

I really did not get it to work well in a LaTeX file: either compilation
failed or the symbols were displayed quite ugly in the dvi/pdf file.

   > These could be added via prettify-symbols-mode (which, like
   > preview-latex relies on redisplay features rather than modifying the
   > actual buffer's content).

I am curious to see whether that would have performance issues on big
files

Uwe 



Footnotes:
[1]  personal taste: the symbols provided by the input method look a lot
     uglier that the one provided x-symbol


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5556 bytes --]

Re: Removing rollback from VC mode - request for comment

[David Kastrup]

Uwe Brauer <oub@mat.ucm.es> writes:

>    > I remember X-Symbol, but most of its feature set has been replaced by
>    > other things (e.g. input-methods, or \inputenc{utf8} which lets you use
>
> Do you mean \usepackage[utf8]{inputenc}
>
>    > actual accented chars in the file).  Are you referring to the replacement
>    > of "\alpha" with an "α" and things like that?
>
> Do you mean (set-input-method "TeX")? 
>
> Last time I looked into that, my impression was this functionality
> included less symbols than x-symbols. Besides sub and super indices were
> not supported.[1]

IIRC, X-Symbol has a really large array of input methods including
completion, a "grid", and various forms of cycling through several
symbols.

The TeX input method is not at all helpful here since its purpose is
getting a single character in your file when knowing the full TeX
sequence which is pretty much the opposite of what X-Symbol does.

> I really did not get it to work well in a LaTeX file: either
> compilation failed or the symbols were displayed quite ugly in the
> dvi/pdf file.

The utf8x input encoding tends to fare somewhat better.

>    > These could be added via prettify-symbols-mode (which, like
>    > preview-latex relies on redisplay features rather than modifying the
>    > actual buffer's content).
>
> I am curious to see whether that would have performance issues on big
> files

Maybe doing overlays reasonably efficiently (like text properties are)
would be sort of an idea after decades.

-- 
David Kastrup

Re: Removing rollback from VC mode - request for comment

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Sat, 13 Dec 2014 10:42:56 +0100
> 
> Maybe doing overlays reasonably efficiently (like text properties are)
> would be sort of an idea after decades.

Why not use 'display' text properties instead?

Re: Removing rollback from VC mode - request for comment

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Date: Sat, 13 Dec 2014 10:42:56 +0100
>> 
>> Maybe doing overlays reasonably efficiently (like text properties are)
>> would be sort of an idea after decades.
>
> Why not use 'display' text properties instead?

Because they are sticky?  Cut&paste stuff from a TeX buffer with one
encoding into one with a different encoding or into an HTML buffer, and
the display will no longer correspond to the content in any meaningful
way.

I don't see the point in making the efficiency (or its lack of) a
governing parameter in choosing between text properties and overlays.

-- 
David Kastrup

Re: Removing rollback from VC mode - request for comment

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Sat, 13 Dec 2014 11:45:07 +0100
> 
> > Why not use 'display' text properties instead?
> 
> Because they are sticky?

Perhaps we should introduce a new property which acts exactly like
'display', but is member of 'yank-excluded-properties'?

> I don't see the point in making the efficiency (or its lack of) a
> governing parameter in choosing between text properties and overlays.

Given that evidently no one is motivated enough to making overlays
more efficient, it might be prudent to look for other ways of solving
this.

Re: Removing rollback from VC mode - request for comment

[Stefan Monnier]

> Do you mean \usepackage[utf8]{inputenc}

Yes.

>> actual accented chars in the file).  Are you referring to the replacement
>> of "\alpha" with an "α" and things like that?
> Do you mean (set-input-method "TeX")? 

No, I mean the thing that visually replaces \alpha with an actual
α character (and converts it back when you save).

> Last time I looked into that, my impression was this functionality
> included less symbols than x-symbols.

This should be fixable.

> Besides sub and super indices were not supported.[1]

Not sure what you mean by that.

>> These could be added via prettify-symbols-mode (which, like
>> preview-latex relies on redisplay features rather than modifying the
>> actual buffer's content).
> I am curious to see whether that would have performance issues on big
> files

No, performance should be unaffected by file-size: only the visible part
of the buffer is considered (it's done via jit-lock) and the display is
modified by "character composition text-properties", which have good
algorithmic properties.


        Stefan

Re: Removing rollback from VC mode - request for comment

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 1039 bytes --]

>> "Stefan" == Stefan Monnier <monnier@iro.umontreal.ca> writes:

   >> Do you mean \usepackage[utf8]{inputenc}
   > Yes.

>> actual accented chars in the file).  Are you referring to the replacement
>> of "\alpha" with an "α" and things like that?
   >> Do you mean (set-input-method "TeX")? 

   > No, I mean the thing that visually replaces \alpha with an actual
   > α character (and converts it back when you save).

Can you give me any example, I mean a function which does this?

Aidan provided some code some time ago, TeX-escape-region which seems to
do what you mean: it replaces (back and forth) between \alpha and α. 
However there were some problems I don't recall precisely but the
function was not bijective. 

I not sure whether this code made it into GNU emacs. Or are you saying
there is another package with the same functionality?

   >> Besides sub and super indices were not supported.[1]

   > Not sure what you mean by that.


Oh in Latex you can have $u_k$ or $u^l$ where k is the sup and l the
super index.


Uwe 

[-- Attachment #2.1: Type: text/html, Size: 1838 bytes --]

[-- Attachment #2.2: org-ZiALrP_88e78aed14d64d143c24da9743104ec9909b7f1c.png --]
[-- Type: image/png, Size: 213 bytes --]

[-- Attachment #2.3: org-ZiALrP_3df0e26f2742083035f00e5d75f1a760c9f477a5.png --]
[-- Type: image/png, Size: 217 bytes --]

Re: Removing rollback from VC mode - request for comment

[Stefan Monnier]

>> No, I mean the thing that visually replaces α with an actual
>> α character (and converts it back when you save).

Did I write the above?  Sorry, the first α should have been "\alpha".
And I was just referring to the X-Symbol feature:

AFAIK, one of one of X-Symbol's features is to shows you "nice symbols
and such", such as → ⊢ α, in place of the corresponding TeX code (such
as \to, \vdash, \alpha).  It does it in a way which is fairly intrusive,
replacing the \to, \vdash, \alpha text itself in the buffer (and
replacing it back when saving).

And I was pointing out that nowadays it would be a lot more natural to
do that via prettify-symbols-mode which would be more efficient and
wouldn't requiring changing the buffer's content (so, no risk of
messing up the file's content either).

>>> Besides sub and super indices were not supported.1
>> Not sure what you mean by that.

> Oh in Latex you can have 
> $u_k$
> or 
> $u^l$
> where k is the sup and l the
> super index.

I know that, but what does it have to do with X-Symbol?
More to the point: Emacs's built-in LaTeX mode already displays those
above "_k" and "^l" as sub- and superscripts (and has been doing it for
many years now).
So, what did X-Symbol do with super/subscript that isn't covered by this?


        Stefan

Re: Removing rollback from VC mode - request for comment

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 2171 bytes --]

>> "Stefan" == Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> No, I mean the thing that visually replaces α with an actual
>> α character (and converts it back when you save).

   > Did I write the above?  Sorry, the first α should have been "\alpha".
   > And I was just referring to the X-Symbol feature:

   > AFAIK, one of one of X-Symbol's features is to shows you "nice symbols
   > and such", such as → ⊢ α, in place of the corresponding TeX code (such
   > as \to, \vdash, \alpha).  It does it in a way which is fairly intrusive,
   > replacing the \to, \vdash, \alpha text itself in the buffer (and
   > replacing it back when saving).

   > And I was pointing out that nowadays it would be a lot more natural to
   > do that via prettify-symbols-mode which would be more efficient and
   > wouldn't requiring changing the buffer's content (so, no risk of
   > messing up the file's content either).

You are right, also I find the symbols provided my the functionality you
mentioned quite ugly compared to the one presented by x-symbol, a bit
like comparing a math documented generated by (La)TeX or say by an IBM
from then seventies.....



   > I know that, but what does it have to do with X-Symbol?

When x-symbol was introduced a bit more than 20 years ago it was
revolutionary.

   > More to the point: Emacs's built-in LaTeX mode already displays those
   > above "_k" and "^l" as sub- and superscripts (and has been doing it for
   > many years now).

   > So, what did X-Symbol do with super/subscript that isn't covered by this?


Well it does not display the ugly _ (while in x-symbols the _ or ^ are
omitted when the indices are displayed)[1]

Another important feature, which I have not seen so far by other
packages concerns: Graphics! Pdf, jpg gif

For example 
if you have 
\includegraphics{function.jpg}
in your latex file, then 
x-symbol with represents graphic file inline (in the same buffer) via
imagemagick

Uwe 

Footnotes:
[1]  and the functionality you describe does not work unfortunately in
     Xemacs, which is irrelevant for this list, but worth to mention.


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5556 bytes --]

Re: Removing rollback from VC mode - request for comment

[David Kastrup]

Uwe Brauer <oub@mat.ucm.es> writes:

[X-Symbol]

> Another important feature, which I have not seen so far by other
> packages concerns: Graphics! Pdf, jpg gif
>
> For example 
> if you have 
> \includegraphics{function.jpg}
> in your latex file, then 
> x-symbol with represents graphic file inline (in the same buffer) via
> imagemagick

preview-latex tends to do a reasonable job regarding \includegraphics,
and it also tends to work with things like tikz or pstricks.

I've never been overly impressed with the graphics handling of X-Symbol,
finding it too hard to get it working reliably.

-- 
David Kastrup

Re: Removing rollback from VC mode - request for comment

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 520 bytes --]


   > Uwe Brauer <oub@mat.ucm.es> writes:
   > [X-Symbol]


   > preview-latex tends to do a reasonable job regarding \includegraphics,
   > and it also tends to work with things like tikz or pstricks.

   > I've never been overly impressed with the graphics handling of X-Symbol,
   > finding it too hard to get it working reliably.


The only thing I can say, on huge beamer files with a lot of graphics,
preview-latex needs quite some time to compile, why x-symbol allows me a
fast way to get the graphics displayed.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5556 bytes --]

Re: Removing rollback from VC mode - request for comment

[Stefan Monnier]

> You are right, also I find the symbols provided my the functionality you
> mentioned quite ugly compared to the one presented by x-symbol, a bit
> like comparing a math documented generated by (La)TeX or say by an IBM
> from then seventies.....

This seems to be a simple matter of choosing the right font.  IOW it
completely depends on your particular setup.  Maybe if you post
a snapshot showing the symbols chosen by Emacs for the actual characters
alongside the symbols displayed by X-Symbol for the corresponding TeX
commands, someone will be able to help you get Emacs to choose
better symbols.

>> More to the point: Emacs's built-in LaTeX mode already displays those
>> above "_k" and "^l" as sub- and superscripts (and has been doing it for
>> many years now).
>> So, what did X-Symbol do with super/subscript that isn't covered by this?

> Well it does not display the ugly _ (while in x-symbols the _ or ^ are
> omitted when the indices are displayed)[1]

That's just a conscious choice of the font-lock settings used in
tex-mode.el.  You could easily tweak those settings to additionally hide
the _ or ^ characters.

> Another important feature, which I have not seen so far by other
> packages concerns: Graphics! Pdf, jpg gif

Indeed.  There's also no input method corresponding to the X-Symbol's
symbol menu, nor for its symbol table (which displays the symbols in
a buffer where you can select them wither with the mouse of by moving
the cursor to the symbol you like).


        Stefan

Re: Removing rollback from VC mode - request for comment

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> You are right, also I find the symbols provided my the functionality you
>> mentioned quite ugly compared to the one presented by x-symbol, a bit
>> like comparing a math documented generated by (La)TeX or say by an IBM
>> from then seventies.....
>
> This seems to be a simple matter of choosing the right font.  IOW it
> completely depends on your particular setup.  Maybe if you post
> a snapshot showing the symbols chosen by Emacs for the actual characters
> alongside the symbols displayed by X-Symbol for the corresponding TeX
> commands, someone will be able to help you get Emacs to choose
> better symbols.

I think X-Symbol installs its own set of fonts with an encoding of their
own.  I suspect those more likely or not to be hand-created (or at least
hand-corrected) on a per-pixel base rather than by some computational
tracing process from a vectorized description.

I see this effect a lot in musical instruments: mechanical processes and
milling precision have improved so much in the last half century that
there seems to be little point in putting in additional manual labor.

But it was actually the manual labor that created a coherent whole from
too crudely mechanically preprocessed raw materials.  When the raw
result was falling short by 10%, omitting the finishing work was not
much of an option.  If it falls short by 1%, why bother?

To get back to the issue in question: In particular for obscure code
points nobody is likely to be using?

The code points in X-Symbol's own fonts, in contrast, are known to be
exercised a lot, so correspondingly more care went into them.

-- 
David Kastrup

Re: Removing rollback from VC mode - request for comment

[Uwe Brauer]

[-- Attachment #1.1: Type: text/plain, Size: 1319 bytes --]



   > This seems to be a simple matter of choosing the right font.  IOW it

Right especially this font is very easily scalable so I can adapt it
either to my small Laptop screen or to a bigger Desktop one.

   > completely depends on your particular setup.  Maybe if you post
   > a snapshot showing the symbols chosen by Emacs for the actual characters
   > alongside the symbols displayed by X-Symbol for the corresponding TeX
   > commands, someone will be able to help you get Emacs to choose
   > better symbols.

Here are two snapshots attached below

   > That's just a conscious choice of the font-lock settings used in
   > tex-mode.el.  You could easily tweak those settings to additionally hide
   > the _ or ^ characters.


Can you give me an example. I have never seen such settings would be
most welcome.


   > Indeed.  There's also no input method corresponding to the X-Symbol's
   > symbol menu, nor for its symbol table (which displays the symbols in

Now I don't understand you. If I use (set-input-method "TeX")  (or
something like this)
typing \alpha results in α but the same happens in a LaTeX buffer with
x-symbol-mode (-minor) turned on. In this sense X-symbol provides a
input method (otherwise it would be very clumsy to use), or what do I miss?


Uwe 


[-- Attachment #1.2: symbols-utf8.png --]
[-- Type: image/png, Size: 35748 bytes --]

[-- Attachment #1.3: xsymbol.png --]
[-- Type: image/png, Size: 36108 bytes --]

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5556 bytes --]

Re: Removing rollback from VC mode - request for comment

[Stefan Monnier]

>> completely depends on your particular setup.  Maybe if you post
>> a snapshot showing the symbols chosen by Emacs for the actual characters
>> alongside the symbols displayed by X-Symbol for the corresponding TeX
>> commands, someone will be able to help you get Emacs to choose
>> better symbols.
> Here are two snapshots attached below

Hmm... the sizes are very different, which might be a significant part
of the explanation.  Of course the bad karma of using XEmacs might be
the main reason why things turn out so poorly for you ;-)

It seems that the symbols provided by X-Symbol have wildly varying
sizes, which seems to fit your expectations (since you say you like it),
but can't be matched by a simple font since usually fonts try to stick
to a "governing" font size.

So, to reproduce the X-Symbol size variations, you'd have to use a an
additional set of font-lock rules that change the size of some
characters such as the Σ used in sums.  Of course, in my area, we don't
use sums, so when Σ appears, it is typically just the name of some
environment and shouldn't be any larger than a normal capital letter.

>> That's just a conscious choice of the font-lock settings used in
>> tex-mode.el.  You could easily tweak those settings to additionally hide
>> the _ or ^ characters.
> Can you give me an example. I have never seen such settings would be
> most welcome.

Look at the font-lock rules used for the sub/superscript in tex-mode.el
and adjust them to place an `invisible' property on the ^/_ char.
Search for `tex-fontify-script' which is the boolean variable which
governs whether or not font-lock should raise/lower the super/subscripts
in (la)tex-mode.

>> Indeed.  There's also no input method corresponding to the X-Symbol's
>> symbol menu, nor for its symbol table (which displays the symbols in

> Now I don't understand you. If I use (set-input-method "TeX")  (or
> something like this)
> typing \alpha results in α but the same happens in a LaTeX buffer with
> x-symbol-mode (-minor) turned on. In this sense X-symbol provides a
> input method (otherwise it would be very clumsy to use), or what do I miss?

I didn't say X-Symbol doesn't provide an input method.  I said the
opposite: that there is no non-X-Sybmol input methods that correspond to
X-Symbol's symbol menu nor to X-Symbol's table (both of which are kinds
of input method).


        Stefan

Re: Removing rollback from VC mode - request for comment

[Uwe Brauer]

   > Uwe Brauer <oub@mat.ucm.es> writes:

   > Well, it was the inspiration for preview-latex's "never touch the buffer
   > text" philosophy.  

In a way X-symbol is faster than preview-latex and works even on
incorrect latex syntax it works even in email buffers[1]

   > It would be interesting to redo X-Symbol with text overlays rather
   > than actual text replacements, but it could trigger performance
   > problems.

X-symbol suffers, for large files, already performance problems. And yes
I wholeheartedly agree that it is a pity that x-symbol is basically dead
for a decade. I wish I could understand the code (and maintain it), but
I can't ....

Ok that gets off topic somehow

   > Ok.

Footnotes:
[1]  although org-mime-htmlize has replaced this feature in a more
     satisfactory way

Multiple independent projects per directory

[Eric S. Raymond]

David Kastrup <dak@gnu.org>:
> If you have one directory per document, Git tends to be a more flexible
> solution.  Admittedly, it is not all that good for keeping independent
> files in the same directory versioned independently (sort of like a
> glorified file backup).  It would be an interesting exercise to teach
> this modus operandi to Emacs/VC (basically, keep a separate .git style
> directory for each file-gittified file and set the respective
> environment variable or command line argument to it for VC operations).

This would have been an interesting exercise before about a month ago.
But SRC occupies this exact functional niche and has VC support.  By
what I see in my mailbox it's spreading like wildfire. I keep getting
this reaction: "Until I saw this I had no idea it was exactly what I
wanted."

The stack looks like this: Emacs VC -> SRC -> RCS.  There's a win from
having SRC as an intermediate layer that is part UI and part
architectural.  Its command set is good to have in circumstances where
you want the features but don't have Emacs handy, and it keeps the
complexity of the Emacs code really low.  You might find it
instructive to compare vc-rcs.el with vc-src.el.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Removing rollback from VC mode - request for comment

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 772 bytes --]

() Uwe Brauer <oub@mat.ucm.es>
() Fri, 12 Dec 2014 16:42:37 +0100

   I use RCS on most of my longer latex documents, as it happens
   (without going into details) sometimes, not very often but
   often enough, the coding is scrambled during a check-in
   making the LaTeX file completely useless.

If you have small reproducible test case, could you please send
it to bug-rcs, along w/ the version of RCS involved?  I'm sure
that if RCS is the source of the weirdness, its maintainers will
want to identify and fix the problem(s).

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]