Re: [Emacs-diffs] emacs-25 8726de6: Finish excising electric indent from `open-line'

Re: [Emacs-diffs] emacs-25 8726de6: Finish excising electric indent from `open-line'

[Stefan Monnier]

>     * lisp/simple.el (open-line): Remove INTERACTIVE argument.

Nit pick: the point of this change is to stop passing `interactive' to
`newline'.  As a consequence, `interactive' becomes unused so it can be
removed, but the removal of `interactive' is not the crucial element.


        Stefan

Re: [Emacs-diffs] emacs-25 8726de6: Finish excising electric indent from `open-line'

[Karl Fogel]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
>>     * lisp/simple.el (open-line): Remove INTERACTIVE argument.
>
>Nit pick: the point of this change is to stop passing `interactive' to
>`newline'.  As a consequence, `interactive' becomes unused so it can be
>removed, but the removal of `interactive' is not the crucial element.

Thanks for the review, Stefan.

Since I explained the overall point of the change elsewhere in the commit message, I deliberately kept a narrower focus in the part of the commit message that's about the diff to `open-line'.  However, on reflection, I think you're right that it would have been clearer to say something like this:

  * lisp/simple.el (open-line): Remove INTERACTIVE flag, so that
    it is no longer passed to `newline', so that invoking `newline'
    no longer causes electric indentation to happen.

Oh, well.  Although mostly pleased with Emacs' transition to distributed version control, I do miss one thing: being able to edit log messages after the fact!

Best regards
-Karl

Re: [Emacs-diffs] emacs-25 8726de6: Finish excising electric indent from `open-line'

[Stefan Monnier]

> Oh, well.  Although mostly pleased with Emacs' transition to
> distributed version control, I do miss one thing: being able to edit
> log messages after the fact!

Yes, that's a shortcoming of Git.  Hopefully it'll be fixed eventually.


        Stefan

Re: [Emacs-diffs] emacs-25 8726de6: Finish excising electric indent from `open-line'

[David Kastrup]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> Oh, well.  Although mostly pleased with Emacs' transition to
>> distributed version control, I do miss one thing: being able to edit
>> log messages after the fact!
>
> Yes, that's a shortcoming of Git.  Hopefully it'll be fixed eventually.

It is a limitation, not a shortcoming.  The commit message is
intentionally part of the commit id and consequently part of the commit
graph.  You can rewrite messages when rebasing, but the result is a new
commit graph.  This ensures the integrity of the commit tree including
the original commit messages.

Consequently it will not "be fixed", ever.  It's part of the system
design.  For the purpose of automated ChangeLog generation/maintenance,
one could add additional information to commits (possibly including a
commit message for the sake of ChangeLog generation) with "git notes"
and integrate it at ChangeLog generation time.

But the canonical commit message itself is off-limits once the commit is
part of an accepted commit tree.

-- 
David Kastrup

Re: [Emacs-diffs] emacs-25 8726de6: Finish excising electric indent from `open-line'

[Yuri Khan]

On Sun, Nov 22, 2015 at 12:23 PM, Karl Fogel <kfogel@red-bean.com> wrote:

> Oh, well.  Although mostly pleased with Emacs' transition to distributed version control, I do miss one thing: being able to edit log messages after the fact!

In fact you can. (1) you put out a branch for review; (2) somebody
tells you your commit messages are all wrong; (3) you rewrite your
branch and push --force; (4) nobody complains; (5) you integrate it
into the appropriate development branch.

Re: [Emacs-diffs] emacs-25 8726de6: Finish excising electric indent from `open-line'

[Stefan Monnier]

> Consequently it will not "be fixed", ever.  It's part of the system
> design.  For the purpose of automated ChangeLog generation/maintenance,
> one could add additional information to commits (possibly including a
> commit message for the sake of ChangeLog generation) with "git notes"
> and integrate it at ChangeLog generation time.

And once this workaround is well integrated into "git log", I'll call
this "fixed".  So I think it can be "fixed".


        Stefan