The name gnus-cloud.el

The name gnus-cloud.el

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

  > I had some followups, last one:
  > https://lists.gnu.org/archive/html/emacs-devel/2016-07/msg00617.html

I looked at the old conversation.  It was said that the name
gnus-cloud.el was a joke.  I asked, what is the joke, and no one said.

Now that the file is installed, I can look at it.  I don't see
anything in the file that is evidently a joke.  What is the joke?

Back then, you said,

    OK, I'll let you and Lars and the maintainers figure it out. Let's do
    the rename, if that's the decision, after the current gnus-cloud code is
    reviewed and merged, or it will get confusing (because the feature
    branch currently removes the old gnus-sync.el).

That time has now arrived.

The file starts with this:

;;; gnus-cloud.el --- storing and retrieving data via IMAP

So how about renaming it to gnus-imap.el?  That name is clear and fits
what the program does.

Or perhaps gnus-imap-sync.el; it would say more about what functionality
the file provides.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Skype: No way! See https://stallman.org/skype.html.

Re: The name gnus-cloud.el

[Ted Zlatanov]

On Fri, 15 Dec 2017 16:26:57 -0500 Richard Stallman <rms@gnu.org> wrote: 

>> I had some followups, last one:
>> https://lists.gnu.org/archive/html/emacs-devel/2016-07/msg00617.html

RS> I looked at the old conversation.  It was said that the name
RS> gnus-cloud.el was a joke.  I asked, what is the joke, and no one said.

RS> Now that the file is installed, I can look at it.  I don't see
RS> anything in the file that is evidently a joke.  What is the joke?

I think the main joke is that it's the kind of cloud that the GNU
project might produce. But it's only funny until we start analyzing it.

RS> Back then, you said,

RS>     OK, I'll let you and Lars and the maintainers figure it out. Let's do
RS>     the rename, if that's the decision, after the current gnus-cloud code is
RS>     reviewed and merged, or it will get confusing (because the feature
RS>     branch currently removes the old gnus-sync.el).

RS> That time has now arrived.

I don't see a discussion between you and Lars and the maintainers.
Please come to an agreement with them. My vote is for the Silly Party.

RS> The file starts with this:

RS> ;;; gnus-cloud.el --- storing and retrieving data via IMAP

RS> So how about renaming it to gnus-imap.el?  That name is clear and fits
RS> what the program does.

RS> Or perhaps gnus-imap-sync.el; it would say more about what functionality
RS> the file provides.

I'd like to avoid pinning the name on IMAP, that's just a storage backend.

Ted

Re: The name gnus-cloud.el

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

  > I don't see a discussion between you and Lars and the maintainers.

Yes you do.  Lars and the Emacs maintainers are on this list.

Is anyone else here concerned about the name of that file?

  > I'd like to avoid pinning the name on IMAP, that's just a storage backend.

Perhaps you should change the first line of the file, then.
It says,

  ;;; gnus-cloud.el --- storing and retrieving data via IMAP

Perhaps this ought to say

  ;;; gnus-WHAT.el --- storing and retrieving data via a mail server

How about gnus-noncloud.el?
That would make the joke clearer so we could all get it.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Skype: No way! See https://stallman.org/skype.html.

Re: The name gnus-cloud.el

[Lars Ingebrigtsen]

Richard Stallman <rms@gnu.org> writes:

> How about gnus-noncloud.el?
> That would make the joke clearer so we could all get it.

Wouldn't a name like that imply that somewhere there is such a thing as
a cloud?

The current name is an explicit joke on the concept that a "cloud"
exists.  It's just a server somewhere, and perhaps having a joke like
that as a name can be didactic.  "Hey!  There's a cloud in Emacs!
*reads manual*  Oh, it's just stores something on a server...  Is that
what all clouds are about?"

I mean, we can dream.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: The name gnus-cloud.el

[Eric Abrahamsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Richard Stallman <rms@gnu.org> writes:
>
>> How about gnus-noncloud.el?
>> That would make the joke clearer so we could all get it.
>
> Wouldn't a name like that imply that somewhere there is such a thing as
> a cloud?
>
> The current name is an explicit joke on the concept that a "cloud"
> exists.  It's just a server somewhere, and perhaps having a joke like
> that as a name can be didactic.  "Hey!  There's a cloud in Emacs!
> *reads manual*  Oh, it's just stores something on a server...  Is that
> what all clouds are about?"
>
> I mean, we can dream.

I could have sworn that there was something called "Cloudy Gnus" at some
point, did I dream that? We could call it gnus-cloudy.el. Let people
interpret that as they will.

Re: The name gnus-cloud.el

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

  > I could have sworn that there was something called "Cloudy Gnus" at some
  > point, did I dream that? We could call it gnus-cloudy.el. Let people
  > interpret that as they will.

I like gnus-cloudy.el.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Skype: No way! See https://stallman.org/skype.html.

Re: The name gnus-cloud.el

[Stephen Berman]

On Sun, 17 Dec 2017 23:31:37 +0100 Lars Ingebrigtsen <larsi@gnus.org> wrote:

> Richard Stallman <rms@gnu.org> writes:
>
>> How about gnus-noncloud.el?
>> That would make the joke clearer so we could all get it.
>
> Wouldn't a name like that imply that somewhere there is such a thing as
> a cloud?
>
> The current name is an explicit joke on the concept that a "cloud"
> exists.  It's just a server somewhere, and perhaps having a joke like
> that as a name can be didactic.  "Hey!  There's a cloud in Emacs!
> *reads manual*  Oh, it's just stores something on a server...  Is that
> what all clouds are about?"
>
> I mean, we can dream.

How about gnus-sky.el?  
(Though then maybe only Norwegians will get the joke.)

Steve Berman

Re: The name gnus-cloud.el

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

  > > How about gnus-noncloud.el?
  > > That would make the joke clearer so we could all get it.

  > Wouldn't a name like that imply that somewhere there is such a thing as
  > a cloud?

No, it wouldn't imply that.  It would only mean that this isn't a cloud.

  > The current name is an explicit joke on the concept that a "cloud"
  > exists.

You can view it as a joke -- that would be an "in joke" -- but it
is not explicitly visible as one.

If you'd like to contribute to a joke about this to Emacs, please do
it in a way that the users can see and understand.  That way, they
can appreciate it.


-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Skype: No way! See https://stallman.org/skype.html.

Re: The name gnus-cloud.el

[Stefan Monnier]

>   ;;; gnus-cloud.el --- storing and retrieving data via IMAP
>
> Perhaps this ought to say
>
>   ;;; gnus-WHAT.el --- storing and retrieving data via a mail server
>
> How about gnus-noncloud.el?

FWIW, I think "gnus-cloud" is a great color for this particular bikeshed.
But if IMAP is not meant to be the only backend, then the first line
could arguably refrain from mentioning IMAP.


        Stefan

Re: The name gnus-cloud.el

[Ted Zlatanov]

On Sun, 17 Dec 2017 17:22:42 -0500 Richard Stallman <rms@gnu.org> wrote: 

>> I don't see a discussion between you and Lars and the maintainers.

RS> Yes you do.  Lars and the Emacs maintainers are on this list.

Let me be explicit: I need a go-ahead from the current Emacs maintainers
and from Lars to do the renaming.

>> I'd like to avoid pinning the name on IMAP, that's just a storage backend.

RS> Perhaps you should change the first line of the file, then.
RS>   ;;; gnus-cloud.el --- storing and retrieving data via IMAP

Understood. Thank you for noting that; I'll adjust the comment.

RS> How about gnus-noncloud.el?
RS> That would make the joke clearer so we could all get it.

That would make the humor more nebulous though.

Ted

Re: The name gnus-cloud.el

[Eli Zaretskii]

> From: Ted Zlatanov <tzz@lifelogs.com>
> Date: Sun, 17 Dec 2017 19:33:25 -0500
> Cc: emacs-devel@gnu.org
> 
> Let me be explicit: I need a go-ahead from the current Emacs maintainers
> and from Lars to do the renaming.

I don't like renaming files because that makes some VCS commands fail
or work less efficiently, and makes forensics much harder and less
convenient.

Re: The name gnus-cloud.el

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

  > I don't like renaming files because that makes some VCS commands fail
  > or work less efficiently, and makes forensics much harder and less
  > convenient.

We can't have a policy that badly chosen file names are set in stone
and can never be changed.  Haven't any files' names been changed since
we started using Git?  How was that done?

gnus-cloud.el is fairly new, so it hasn't got a years-long history
entwined with other files.  We will not delete its history, but if
that history gets a little less convenient to access, it won't be
a big deal.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Skype: No way! See https://stallman.org/skype.html.

Re: The name gnus-cloud.el

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> CC: tzz@lifelogs.com, emacs-devel@gnu.org
> Date: Mon, 18 Dec 2017 16:16:47 -0500
> 
>   > I don't like renaming files because that makes some VCS commands fail
>   > or work less efficiently, and makes forensics much harder and less
>   > convenient.
> 
> We can't have a policy that badly chosen file names are set in stone
> and can never be changed.

There's no such policy, of course.  I'm just saying that renaming
should be avoided.

In this case, I cannot for the life of me understand what's all the
fuss about.  "Cloud" is just a word, and there's nothing wrong with it
per se.  We are not talking about cloud computing, nor about using
some cloud storage, we are talking about using the word itself.  I
cannot believe we are going to use the GNU and FSF authority and
reputation to proclaim the word "cloud" persona non-grata.

> Haven't any files' names been changed since we started using Git?
> How was that done?

This has been done, of course, and I'm annoyed every time I need to
check something about such files in Git.

> gnus-cloud.el is fairly new, so it hasn't got a years-long history
> entwined with other files.  We will not delete its history, but if
> that history gets a little less convenient to access, it won't be
> a big deal.

I say we should avoid that, and in this case I see absolutely no
reason to sustain more annoyance or inconvenience.

Re: The name gnus-cloud.el

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

  > In this case, I cannot for the life of me understand what's all the
  > fuss about.  "Cloud" is just a word, and there's nothing wrong with it
  > per se.

The problem is in the expression "cloud computing".  It is a bogus
generalization whose use spreads confusion.

  >  We are not talking about cloud computing,

It makes no sense to "talk about cloud computing" because "cloud
computing" doesn't have a coherent meaning.  It is a confused
overgeneraligation.  When people think they are "talking about cloud
computing", that means they are under the confusion of the
overgeneraligation.

See https://gnu.org/philosophy/words-to-avoid.html#CloudComputing for
explanation of how that expression does harm.

    we are talking about using the word itself.

In this context, "cloud" means that something "uses cloud computing".

It could be different in another context.  For instance, in a program
for weather forecasting, "cloud" might refer to a meteorological
phenomenon.  That would not spread any confusion about computing
practices.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Skype: No way! See https://stallman.org/skype.html.

Re: The name gnus-cloud.el

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> CC: tzz@lifelogs.com, emacs-devel@gnu.org
> Date: Thu, 21 Dec 2017 11:50:42 -0500
> 
>   > In this case, I cannot for the life of me understand what's all the
>   > fuss about.  "Cloud" is just a word, and there's nothing wrong with it
>   > per se.
> 
> The problem is in the expression "cloud computing".  It is a bogus
> generalization whose use spreads confusion.

But gnus-cloud doesn't do or mention cloud computing.

>   >  We are not talking about cloud computing,
> 
> It makes no sense to "talk about cloud computing"

We are mis-communicating: I meant to say that gnus-cloud doesn't do or
mention cloud computing.  Thus, "we are not talking" about that.

>     we are talking about using the word itself.
> 
> In this context, "cloud" means that something "uses cloud computing".

No, it doesn't.  It just stands for itself.

> It could be different in another context.

The context here is the name of a file.  That context is unrelated to
anything mentioned in
https://gnu.org/philosophy/words-to-avoid.html#CloudComputing.

The word "cloud" is not to blame for some of its abuses.  We should
not be afraid of using "cloud" as a word.  Doing so makes us look
ridiculous at best.  I don't think we want to be like some regimes
that are afraid of certain words.

Re: The name gnus-cloud.el

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

  > > The problem is in the expression "cloud computing".  It is a bogus
  > > generalization whose use spreads confusion.

  > But gnus-cloud doesn't do or mention cloud computing.

The word "cloud", in the context of computing, can't help but stand
for "cloud computing".  That was surely the reason for choosing that
word, because otherwise it would make no sense here.

Why does the name gnus-cloud.el seem more appropriate than
gnus-rain.el or gnus-snow.el?  Than gnus-tent.el or gnus-shirt.el?
Than gnus-shrimp.el or gnus-leaf.el?  The only reason "cloud"
could make sense here is if it refers to "the cloud".

  > The word "cloud" is not to blame for some of its abuses.

What a droll straw man.

							      We should
  > not be afraid of using "cloud" as a word.

The point is to avoid supporting a line of thinking that we campaign
against.

					       Doing so makes us look
  > ridiculous at best.

It is better to risk looking ridiculous than to sheepishly follow the
crowd and spread the ideas we criticize.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Skype: No way! See https://stallman.org/skype.html.

Re: The name gnus-cloud.el

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> CC: tzz@lifelogs.com, emacs-devel@gnu.org
> Date: Fri, 22 Dec 2017 13:47:50 -0500
> 
>   > But gnus-cloud doesn't do or mention cloud computing.
> 
> The word "cloud", in the context of computing, can't help but stand
> for "cloud computing".

The context here is not of computing, the context is of naming files.

> That was surely the reason for choosing that word, because otherwise
> it would make no sense here.

The reason is immaterial, as long as it is really known only to the
person who invented the name.

> Why does the name gnus-cloud.el seem more appropriate than
> gnus-rain.el or gnus-snow.el?

They all are appropriate just the same.

> The point is to avoid supporting a line of thinking that we campaign
> against.

Naming a file something that has "cloud" in it doesn't mean supporting
that line of thinking in any way.

> It is better to risk looking ridiculous than to sheepishly follow the
> crowd and spread the ideas we criticize.

We don't follow the crowd in this regard, sheepishly or otherwise.  We
just use "cloud" in a file name.

Re: The name gnus-cloud.el

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Fri, 22 Dec 2017 13:47:50 -0500
> Cc: tzz@lifelogs.com, emacs-devel@gnu.org
> 
> It is better to risk looking ridiculous than to sheepishly follow the
> crowd and spread the ideas we criticize.

Btw, by always doing the exact opposite of what the crowd does in this
matter, we are actually still "following the crowd", instead of
applying our own healthy judgment in each case.

Re: The name gnus-cloud.el

[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 is better to risk looking ridiculous than to sheepishly follow the
  > > crowd and spread the ideas we criticize.

  > Btw, by always doing the exact opposite of what the crowd does in this
  > matter, we are actually still "following the crowd", 

What is "the exact opposite" of using a buzzword?  I don't think that
concept is well-defined.  What I want to do is _not use it_.

By declining to use that buzzword, we are _reacting_ to the crowd that
uses it.  Reacting is different from following.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Skype: No way! See https://stallman.org/skype.html.

Re: The name gnus-cloud.el

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> CC: tzz@lifelogs.com, emacs-devel@gnu.org
> Date: Sat, 23 Dec 2017 09:58:21 -0500
> 
>   > Btw, by always doing the exact opposite of what the crowd does in this
>   > matter, we are actually still "following the crowd", 
> 
> What is "the exact opposite" of using a buzzword?

The exact opposite is to never use it.

> By declining to use that buzzword, we are _reacting_ to the crowd that
> uses it.  Reacting is different from following.

If we never use it, unconditionally, then we do follow the crowd, just
in reverse direction.  A silly idea doesn't become a smart idea just
by negating everything it says.

Re: The name gnus-cloud.el

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

  > > What is "the exact opposite" of using a buzzword?

  > The exact opposite is to never use it.

Oh no, that's hardly opposite enough to be "the exact opposite".
Here are some better candidates for "the exact opposite":

* Play kazoos whenever others use the buzzword.
* Turn on a siren whenever others use the buzzword.
* Say the buzzword over and over, backwards.
* Invent a politically contrary buzzword and say that all the time.

There are so many ways one action can be "the opposite" of another
action that people could never agree on what the "opposite" is.

But that's a purely academic question.  The GNU Project has a policy
towards the term "cloud computing": criticize it, avoid using it, and
urge others to avoid it.  Whether or not it is "the exact opposite",
it's the rational way to work against the confusion of that term.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Skype: No way! See https://stallman.org/skype.html.

Re: The name gnus-cloud.el

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> CC: tzz@lifelogs.com, emacs-devel@gnu.org
> Date: Sun, 24 Dec 2017 15:34:32 -0500
> 
> There are so many ways one action can be "the opposite" of another
> action that people could never agree on what the "opposite" is.
> 
> But that's a purely academic question.  The GNU Project has a policy
> towards the term "cloud computing": criticize it, avoid using it, and
> urge others to avoid it.  Whether or not it is "the exact opposite",
> it's the rational way to work against the confusion of that term.

Let me just say that I've read the relevant page on the FSF site, and
I support what it says, but I still think ostracizing the word "cloud"
in _any_ computing-related discussion is too extreme, and may even
"cloud" the minds of some of our followers.  And if you don't agree,
then let's agree to disagree on that.

Re: The name gnus-cloud.el

[Paul Eggert]

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

Assuming we leave the name alone, we can add a brief comment saying that 
it's a parody and is not intended to implement "cloud computing". The 
comment can point to the Gnu page explaining why "cloud computing" is 
normally an unwise choice of phrase. I installed the attached to try to 
do this. I hope this patch helps to address qualms about using the name 
gnus-cloud as a joke.

[-- Attachment #2: 0001-Say-that-gnus-cloud-is-a-parody-name.patch --]
[-- Type: text/x-patch, Size: 1414 bytes --]

From dc15a04354dac5601e17d50dc90411e5de2ecc76 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Mon, 25 Dec 2017 14:19:37 -0800
Subject: [PATCH] Say that "gnus-cloud" is a parody name

---
 doc/misc/gnus.texi      | 5 ++++-
 lisp/gnus/gnus-cloud.el | 4 ++++
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/doc/misc/gnus.texi b/doc/misc/gnus.texi
index 318f510588..76d83163c2 100644
--- a/doc/misc/gnus.texi
+++ b/doc/misc/gnus.texi
@@ -26197,7 +26197,10 @@ The Gnus Cloud
 
 The Gnus Cloud package stores the marks, plus any files you choose, on
 an IMAP server in a special folder. It's like a
-DropTorrentSyncBoxOakTree(TM).
+DropTorrentSyncBoxOakTree(TM).@footnote{The name ``Gnus Cloud''
+parodizes but otherwise has little to do with ``cloud computing'', a
+@url{https://www.gnu.org/philosophy/words-to-avoid.html#CloudComputing,
+misleading term normally best avoided}.}
 
 @menu
 * Gnus Cloud Setup::
diff --git a/lisp/gnus/gnus-cloud.el b/lisp/gnus/gnus-cloud.el
index 34d54ec3ca..6b64e40181 100644
--- a/lisp/gnus/gnus-cloud.el
+++ b/lisp/gnus/gnus-cloud.el
@@ -22,6 +22,10 @@
 
 ;;; Commentary:
 
+;; The name gnus-cloud parodizes but otherwise has little to do with
+;; "cloud computing", a misleading term normally best avoided.  See:
+;; https://www.gnu.org/philosophy/words-to-avoid.html#CloudComputing
+
 ;;; Code:
 
 (eval-when-compile (require 'cl))
-- 
2.14.1

Re: The name gnus-cloud.el

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

I'll agree to this solution to avoid the inconvenience of renaming the
file.  Thanks for writing it -- you've expressed the point well.

I expressed unhappiness with the name when it was first proposed, but
we didn't settle the issue then.  It was proposed to "install it
first, then choose the name," and that's what happened.

In principle, it's ok to proceed that way, but it requires renaming a
file.  Since renaming an installed file is inconvenient, from now on
let's make sure to settle all issues about names of files before
installing them.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Skype: No way! See https://stallman.org/skype.html.

Re: The name gnus-cloud.el

[Ted Zlatanov]

On Tue, 26 Dec 2017 14:40:51 -0500 Richard Stallman <rms@gnu.org> wrote: 

RS> I'll agree to this solution to avoid the inconvenience of renaming the
RS> file.  Thanks for writing it -- you've expressed the point well.

Thank you for being reasonable. I appreciate it.

Ted

Re: The name gnus-cloud.el

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

  > If we never use it, unconditionally, then we do follow the crowd, just

You're using a unique definition of "follow".  If someone else walks
out of a restaurant as you enter it, do you say "Stop following me"?

The GNU Project follows a policy of rejecting the term "cloud
computing", or "cloud" for short.

  >   A silly idea doesn't become a smart idea just
  > by negating everything it says.

I agree, and in https://gnu.org/philosophy/words-to-avoid.html you'll
see we hardly condemn all the things that some call "cloud computing".
On the contrary, we say that those things are different issues: some are ok,
some are bad, so _let's not mix them up_.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Skype: No way! See https://stallman.org/skype.html.

Re: The name gnus-cloud.el

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> CC: tzz@lifelogs.com, emacs-devel@gnu.org
> Date: Sun, 24 Dec 2017 15:34:33 -0500
> 
>   > If we never use it, unconditionally, then we do follow the crowd, just
> 
> You're using a unique definition of "follow".  If someone else walks
> out of a restaurant as you enter it, do you say "Stop following me"?

If they do that every time I enter a restaurant, I might very well
think that, yes, although I won't necessarily say it out loud.

> The GNU Project follows a policy of rejecting the term "cloud
> computing", or "cloud" for short.

But "cloud" is not always a short for "cloud computing".  Sometimes,
it's just "cloud".

Anyway, I think we should leave it at that.

Re: The name gnus-cloud.el

[Steinar Bang]

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

>> From: Ted Zlatanov <tzz@lifelogs.com>
>> Date: Sun, 17 Dec 2017 19:33:25 -0500
>> Cc: emacs-devel@gnu.org

>> Let me be explicit: I need a go-ahead from the current Emacs maintainers
>> and from Lars to do the renaming.

> I don't like renaming files because that makes some VCS commands fail
> or work less efficiently, and makes forensics much harder and less
> convenient.

git itself handles history tracking across renames if the first commit
with the new name has the exact same sha1 hash.

This is what "git mv" does, ie.
	git mv git-cloud.el git-cloudly.el
        git commit -m "Rename git-cloud.el to git-cloudly.el"
gives something that "git log --follow -- gnus-cloudly.el" can use to
list the history across the rename.

Tool support is something else.  There used to be
  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=8756
which was merged with
  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=19045
and both closed as fixed, however 'C-x v l' doesn't do the right thing
in emacs 25.2.1, history stops at the rename.

Annotate, ie. 'C-x v g' will show changes from across the rename, and
pressing 'd' (to see the diff) and 'l' (to see the log message) on an
annotated line, will show the correct information

Re: The name gnus-cloud.el

[Eli Zaretskii]

> From: Steinar Bang <sb@dod.no>
> Date: Sun, 31 Dec 2017 17:27:26 +0100
> 
> > I don't like renaming files because that makes some VCS commands fail
> > or work less efficiently, and makes forensics much harder and less
> > convenient.
> 
> git itself handles history tracking across renames if the first commit
> with the new name has the exact same sha1 hash.

It does that erratically.  E.g., try displaying history of changes of
a portion of a file with "git log -L", in a file that was moved (files
under subdirectories of doc/ or good examples), and you see it stop at
the rename.  Same with "git annotate", AFAIR.  These are important
forensic tools, and when they hit the brick wall of the rename,
finding a way of jumping over that wall and continuing whatever
investigation you are doing is not easy, sometimes impossible.  E.g.,
I don't know how to cross that line with "git log -L".

> Annotate, ie. 'C-x v g' will show changes from across the rename

It does?  That's not what I see, e.g., with doc/lispref/display.texi:
it never shows anything before 2007-09-06, when the file was moved.
What am I missing?

Re: The name gnus-cloud.el

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> Annotate, ie. 'C-x v g' will show changes from across the rename
>
> It does?  That's not what I see, e.g., with doc/lispref/display.texi:
> it never shows anything before 2007-09-06, when the file was moved.
> What am I missing?

Most likely, the migration tool didn't bother to perform a `git mv
<from> <to>' and did the equivalent of `cp <from> <to>; git rm <from>;
git add <to>' instead.

Re: The name gnus-cloud.el

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sun, 31 Dec 2017 19:12:52 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Annotate, ie. 'C-x v g' will show changes from across the rename
> >
> > It does?  That's not what I see, e.g., with doc/lispref/display.texi:
> > it never shows anything before 2007-09-06, when the file was moved.
> > What am I missing?
> 
> Most likely, the migration tool didn't bother to perform a `git mv
> <from> <to>' and did the equivalent of `cp <from> <to>; git rm <from>;
> git add <to>' instead.

I don't understand why this is relevant: since Git doesn't record
renames, but instead "deduces" them by comparing contents, why should
it matter how the file was moved?

Re: The name gnus-cloud.el

[Steinar Bang]

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

> I don't understand why this is relevant: since Git doesn't record
> renames, but instead "deduces" them by comparing contents, why should
> it matter how the file was moved?

It doesn't.

Where it breaks down is usually where the moved/renamed file is modified
as part of the move commit, so that the hash changes.

Re: The name gnus-cloud.el

[Eli Zaretskii]

> From: Steinar Bang <sb@dod.no>
> Date: Mon, 01 Jan 2018 01:48:30 +0100
> 
> >>>>> Eli Zaretskii <eliz@gnu.org>:
> 
> > I don't understand why this is relevant: since Git doesn't record
> > renames, but instead "deduces" them by comparing contents, why should
> > it matter how the file was moved?
> 
> It doesn't.
> 
> Where it breaks down is usually where the moved/renamed file is modified
> as part of the move commit, so that the hash changes.

AFAIK, the file I used as an example wasn't modified as part of the
move.

Re: The name gnus-cloud.el

[Andreas Schwab]

On Dez 31 2017, Óscar Fuentes <ofv@wanadoo.es> wrote:

> Most likely, the migration tool didn't bother to perform a `git mv
> <from> <to>' and did the equivalent of `cp <from> <to>; git rm <from>;
> git add <to>' instead.

No, that's exactly the same operation.  The problem is that commit
b8d4c8d0e9 didn't rename anything.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: The name gnus-cloud.el

[Steinar Bang]

>>>>> Andreas Schwab <schwab@linux-m68k.org>:

> On Dez 31 2017, Óscar Fuentes <ofv@wanadoo.es> wrote:
>> Most likely, the migration tool didn't bother to perform a `git mv
>> <from> <to>' and did the equivalent of `cp <from> <to>; git rm <from>;
>> git add <to>' instead.

> No, that's exactly the same operation.  The problem is that commit
> b8d4c8d0e9 didn't rename anything.

Yep.  This commit only adds that file, and doesn't remove the existing
file (it doesn't actually have to remove anything for history tracking
to work, but there has to be a file with the same hash available in a
different location in the commit prior to the addition of the new file,
it doesn't look like there is).

2007?  Was that still CVS?  Or was that during bazaar?  How did bazaar
track renames?  How was bazaar renames handled during the conversion to
git?

Re: The name gnus-cloud.el

[Eli Zaretskii]

> From: Steinar Bang <sb@dod.no>
> Date: Mon, 01 Jan 2018 02:05:27 +0100
> 
> >>>>> Andreas Schwab <schwab@linux-m68k.org>:
> 
> > On Dez 31 2017, Óscar Fuentes <ofv@wanadoo.es> wrote:
> >> Most likely, the migration tool didn't bother to perform a `git mv
> >> <from> <to>' and did the equivalent of `cp <from> <to>; git rm <from>;
> >> git add <to>' instead.
> 
> > No, that's exactly the same operation.  The problem is that commit
> > b8d4c8d0e9 didn't rename anything.
> 
> Yep.  This commit only adds that file, and doesn't remove the existing
> file

The file was removed in the previous commit.

> 2007?  Was that still CVS?  Or was that during bazaar?

It was Bazaar.

> How did bazaar track renames?

Bazaar did track renames, but that commit didn't use "bzr mv".

> How was bazaar renames handled during the conversion to git?

I have no idea, but you see the results in the Git repository.

git history tracking across renames (and emacs support) (Was: The name gnus-cloud.el)

[Steinar Bang]

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

>> How did bazaar track renames?

> Bazaar did track renames, but that commit didn't use "bzr mv".

>> How was bazaar renames handled during the conversion to git?

> I have no idea, but you see the results in the Git repository.

If the result you pointed at is the case for all bzr moves converted to
git, then history tracking was lost at that point, and there isn't
really anything to do about it.

But that doesn't imply that "git mv" won't work (well,.. except for
inconsistent support across git commands and missing tool support, that
is...).

After all this years I really, really, would have liked to see 'C-x v l'
in emacs work across renames.

So I think it's a pity that
 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=8756
 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=19045
were closed as fixed.

Because they are not, really.

Re: git history tracking across renames (and emacs support)

[Andreas Schwab]

On Jan 01 2018, Steinar Bang <sb@dod.no> wrote:

> If the result you pointed at is the case for all bzr moves

There were no bzr move.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: git history tracking across renames (and emacs support)

[Steinar Bang]

>>>>> Andreas Schwab <schwab@linux-m68k.org>:
> On Jan 01 2018, Steinar Bang <sb@dod.no> wrote:
>> If the result you pointed at is the case for all bzr moves

> There were no bzr move.

Ok.  Are there examples in the emacs history of a bzr move that was
translated into something git can track history across? (ie. a file with
an identical hash as the old file being added with a new name/location)

Re: git history tracking across renames (and emacs support)

[Andreas Schwab]

On Jan 01 2018, Steinar Bang <sb@dod.no> wrote:

> But that doesn't imply that "git mv" won't work

git mv is just syntactic sugar.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: git history tracking across renames (and emacs support)

[Steinar Bang]

>>>>> Andreas Schwab <schwab@linux-m68k.org>:

> On Jan 01 2018, Steinar Bang <sb@dod.no> wrote:
>> But that doesn't imply that "git mv" won't work

> git mv is just syntactic sugar.

I know.

I just try to keep advice simple.

Re: git history tracking across renames (and emacs support)

[Andreas Schwab]

On Jan 01 2018, Steinar Bang <sb@dod.no> wrote:

> So I think it's a pity that
>  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=8756
>  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=19045
> were closed as fixed.
>
> Because they are not, really.

In which way?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: git history tracking across renames (and emacs support)

[Steinar Bang]

>>>>> Andreas Schwab <schwab@linux-m68k.org>:

> On Jan 01 2018, Steinar Bang <sb@dod.no> wrote:
>> So I think it's a pity that
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=8756
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=19045
>> were closed as fixed.
>> 
>> Because they are not, really.

> In which way?

'C-x v l' doesn't show log messages past the first move/rename.

Re: git history tracking across renames (and emacs support)

[Andreas Schwab]

On Jan 01 2018, Steinar Bang <sb@dod.no> wrote:

>>>>>> Andreas Schwab <schwab@linux-m68k.org>:
>
>> On Jan 01 2018, Steinar Bang <sb@dod.no> wrote:
>>> So I think it's a pity that
>>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=8756
>>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=19045
>>> were closed as fixed.
>>> 
>>> Because they are not, really.
>
>> In which way?
>
> 'C-x v l' doesn't show log messages past the first move/rename.

Do you have an example?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: git history tracking across renames (and emacs support)

[Steinar Bang]

>>>>> Andreas Schwab <schwab@linux-m68k.org>:
> On Jan 01 2018, Steinar Bang <sb@dod.no> wrote:
>>>>>>> Andreas Schwab <schwab@linux-m68k.org>:

>>> On Jan 01 2018, Steinar Bang <sb@dod.no> wrote:

>>>> So I think it's a pity that
>>>>  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=8756
>>>>  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=19045
>>>> were closed as fixed.

>>>> Because they are not, really.

>>> In which way?
>> 
>> 'C-x v l' doesn't show log messages past the first move/rename.

> Do you have an example?

This is when using GNU Emacs 25.2.1 (i686-w64-mingw32) of 2017-04-24

 cd emacs/lisp
 git pull
 git checkout -b scratch/try-rename-a-file
 git mv gnus-cloud.el gnus-cloudly.el
 git commit -m "Rename file gnus-cloud.el to gnus-cloudly.el"

Then open emacs/lisp/gnus-cloudly.el in emacs and do 'C-x v l'

Re: git history tracking across renames (and emacs support)

[Óscar Fuentes]

Steinar Bang <sb@dod.no> writes:

>>>>>> Andreas Schwab <schwab@linux-m68k.org>:
>
>> On Jan 01 2018, Steinar Bang <sb@dod.no> wrote:
>>> So I think it's a pity that
>>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=8756
>>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=19045
>>> were closed as fixed.
>>> 
>>> Because they are not, really.
>
>> In which way?
>
> 'C-x v l' doesn't show log messages past the first move/rename.

Looking at those bug reports, I see that 19045 was created by me with a
naive patch. Someone mentioned the more complete 8756 and then I closed
19045 without realizing that it has been merged with 8756, which was
closed by the same command and so it remains to this day.

What a shame. For a casual user, Debbugs is not adequate at all.

Re: git history tracking across renames (and emacs support)

[Noam Postavsky]

unarchive 8756
reopen 8756
tags 8756 - patch
quit

On Mon, Jan 1, 2018 at 5:04 PM, Óscar Fuentes <ofv@wanadoo.es> wrote:

> Looking at those bug reports, I see that 19045 was created by me with a
> naive patch. Someone mentioned the more complete 8756 and then I closed
> 19045 without realizing that it has been merged with 8756, which was
> closed by the same command and so it remains to this day.

Okay, reopened.

Re: git history tracking across renames (and emacs support)

[Óscar Fuentes]

Noam Postavsky <npostavs@users.sourceforge.net> writes:

> On Mon, Jan 1, 2018 at 5:04 PM, Óscar Fuentes <ofv@wanadoo.es> wrote:
>
>> Looking at those bug reports, I see that 19045 was created by me with a
>> naive patch. Someone mentioned the more complete 8756 and then I closed
>> 19045 without realizing that it has been merged with 8756, which was
>> closed by the same command and so it remains to this day.
>
> Okay, reopened.

Thanks.

Re: git history tracking across renames (and emacs support) (Was: The name gnus-cloud.el)

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

  > If the result you pointed at is the case for all bzr moves converted to
  > git, then history tracking was lost at that point, and there isn't
  > really anything to do about it.

Was the whole history of our repository lost at that time ???

If so, good thing we had change log files, eh?

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Skype: No way! See https://stallman.org/skype.html.

Re: git history tracking across renames (and emacs support) (Was: The name gnus-cloud.el)

[Paul Eggert]

Richard Stallman wrote:
> Was the whole history of our repository lost at that time ???

Not at all. It's still there.

As part of maintenance I've done quite a bit of spelunking through the history 
of Emacs and other GNU programs, and the problem of following renames is small 
potatoes compared to the issues that normally consume most of my 
software-archaeology time: namely, figuring out *why* a change was made, not the 
mechanical details of what changed.

What would be most helpful (and I realize I'm asking for a lot) would be 
ChangeLog entries or commit messages (it doesn't matter which) that explain the 
*motivation* for each change. In contrast, often it is counterproductive to 
burden commit messages with mechanical details such as naming each and every 
function that was modified, as it wastes developers' time to wade through these 
details when they're trying to look for stuff that's more important.

Re: git history tracking across renames (and emacs support)

[Lars Ingebrigtsen]

Paul Eggert <eggert@cs.ucla.edu> writes:

> What would be most helpful (and I realize I'm asking for a lot) would
> be ChangeLog entries or commit messages (it doesn't matter which) that
> explain the *motivation* for each change. In contrast, often it is
> counterproductive to burden commit messages with mechanical details
> such as naming each and every function that was modified, as it wastes
> developers' time to wade through these details when they're trying to
> look for stuff that's more important.

Hear, hear.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: git history tracking across renames (and emacs support)

[Ted Zlatanov]

On Tue, 02 Jan 2018 09:49:41 +0100 Lars Ingebrigtsen <larsi@gnus.org> wrote: 

LI> Paul Eggert <eggert@cs.ucla.edu> writes:
>> What would be most helpful (and I realize I'm asking for a lot) would
>> be ChangeLog entries or commit messages (it doesn't matter which) that
>> explain the *motivation* for each change. In contrast, often it is
>> counterproductive to burden commit messages with mechanical details
>> such as naming each and every function that was modified, as it wastes
>> developers' time to wade through these details when they're trying to
>> look for stuff that's more important.

LI> Hear, hear.

I would appreciate that too. If I need to know what functions were
modified, I look at the diff, which Git makes trivial.

Is there any chance of evolving the commit message formatting
requirements to lower the friction of making a commit and reduce
redundancy?

Ted

Re: git history tracking across renames (and emacs support)

[Marcin Borkowski]

On 2018-07-10, at 15:14, Ted Zlatanov <tzz@lifelogs.com> wrote:

> On Tue, 02 Jan 2018 09:49:41 +0100 Lars Ingebrigtsen <larsi@gnus.org> wrote: 
>
> LI> Paul Eggert <eggert@cs.ucla.edu> writes:
>>> What would be most helpful (and I realize I'm asking for a lot) would
>>> be ChangeLog entries or commit messages (it doesn't matter which) that
>>> explain the *motivation* for each change. In contrast, often it is
>>> counterproductive to burden commit messages with mechanical details
>>> such as naming each and every function that was modified, as it wastes
>>> developers' time to wade through these details when they're trying to
>>> look for stuff that's more important.
>
> LI> Hear, hear.
>
> I would appreciate that too. If I need to know what functions were
> modified, I look at the diff, which Git makes trivial.
>
> Is there any chance of evolving the commit message formatting
> requirements to lower the friction of making a commit and reduce
> redundancy?

+1.

I sometimes made some simple patch, and every time I had to find the
information about the commit message/ChangeLog entry format somewhere in
the docs.  It was very uncomfortable.

Best,

-- 
Marcin Borkowski
http://mbork.pl

Re: git history tracking across renames (and emacs support)

[Eli Zaretskii]

> From: Ted Zlatanov <tzz@lifelogs.com>
> Date: Tue, 10 Jul 2018 13:14:39 +0000
> Cc: emacs-devel@gnu.org
> 
> On Tue, 02 Jan 2018 09:49:41 +0100 Lars Ingebrigtsen <larsi@gnus.org> wrote: 
> 
> LI> Paul Eggert <eggert@cs.ucla.edu> writes:
> >> What would be most helpful (and I realize I'm asking for a lot) would
> >> be ChangeLog entries or commit messages (it doesn't matter which) that
> >> explain the *motivation* for each change. In contrast, often it is
> >> counterproductive to burden commit messages with mechanical details
> >> such as naming each and every function that was modified, as it wastes
> >> developers' time to wade through these details when they're trying to
> >> look for stuff that's more important.
> 
> LI> Hear, hear.
> 
> I would appreciate that too. If I need to know what functions were
> modified, I look at the diff, which Git makes trivial.
> 
> Is there any chance of evolving the commit message formatting
> requirements to lower the friction of making a commit and reduce
> redundancy?

IMO, what you'd like to have will actually _raise_ the friction
(i.e. will be harder to provide) for many contributors, according to
my experience of reviewing quite a few patches.

Re: git history tracking across renames (and emacs support)

[Ted Zlatanov]

On Tue, 10 Jul 2018 18:36:23 +0300 Eli Zaretskii <eliz@gnu.org> wrote: 

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

>> I would appreciate that too. If I need to know what functions were
>> modified, I look at the diff, which Git makes trivial.
>> 
>> Is there any chance of evolving the commit message formatting
>> requirements to lower the friction of making a commit and reduce
>> redundancy?

EZ> IMO, what you'd like to have will actually _raise_ the friction
EZ> (i.e. will be harder to provide) for many contributors, according to
EZ> my experience of reviewing quite a few patches.

I really don't think the current format is easy for anyone, especially
new developers. It's also essentially repeating the headers from the
diff.

Anecdotally, every time I want to make a larger commit with a lot of
items, it feels to me like paperwork for its own sake and takes up a
long time.

Let's take a recent example.

commit 2fde6275b69fd113e78243790bf112bbdd2fe2bf
Author: Basil L. Contovounesios <contovob@tcd.ie>
Date:   Mon Jul 9 18:46:33 2018 -0700

    Add predicate proper-list-p
    
    For discussion, see emacs-devel thread starting at
    https://lists.gnu.org/archive/html/emacs-devel/2018-04/msg00460.html.
    
    * lisp/subr.el (proper-list-p): New function.
    Implementation suggested by Paul Eggert <eggert@cs.ucla.edu> in
    https://lists.gnu.org/archive/html/emacs-devel/2018-06/msg00138.html.
    * doc/lispref/lists.texi (List Elements):
    * etc/NEWS: Document proper-list-p.
    * lisp/org/ob-core.el (org-babel-insert-result):
    * lisp/emacs-lisp/byte-opt.el (byte-optimize-if):
    * lisp/emacs-lisp/cl-macs.el (cl--make-usage-args): Use proper-list-p.
    * lisp/emacs-lisp/ert.el (ert--proper-list-p): Remove.
    Replaced by proper-list-p in lisp/subr.el.
    (ert--explain-equal-rec): Use proper-list-length.
    * lisp/format.el (format-proper-list-p): Remove.
    Replaced by proper-list-p in lisp/subr.el.
    (format-annotate-single-property-change): Use proper-list-p.
    * test/lisp/emacs-lisp/ert-tests.el (ert-test-proper-list-p):
    Move from here...
    * test/lisp/subr-tests.el (subr-tests--proper-list-length):
    ...to here, mutatis mutandis.

Here's one way to write it more concisely and make it more readable,
keeping in mind that the diff is part of the same log and is thus going
to be right below the explanation, and Git usually already *knows* which
files and functions have been modified. I'd much rather read the second
version.

commit 2fde6275b69fd113e78243790bf112bbdd2fe2bf
Author: Basil L. Contovounesios <contovob@tcd.ie>
Date:   Mon Jul 9 18:46:33 2018 -0700

    Adds and documents the new predicate function proper-list-p

    Factors out several one-off implementations of the same functionality.
    For discussion, see emacs-devel thread starting at
    https://lists.gnu.org/archive/html/emacs-devel/2018-04/msg00460.html.

    Implementation suggested by Paul Eggert <eggert@cs.ucla.edu> in
    https://lists.gnu.org/archive/html/emacs-devel/2018-06/msg00138.html.

Re: git history tracking across renames (and emacs support)

[Basil L. Contovounesios]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Tue, 10 Jul 2018 18:36:23 +0300 Eli Zaretskii <eliz@gnu.org> wrote: 
>
>>> From: Ted Zlatanov <tzz@lifelogs.com>
>
>>> I would appreciate that too. If I need to know what functions were
>>> modified, I look at the diff, which Git makes trivial.
>>> 
>>> Is there any chance of evolving the commit message formatting
>>> requirements to lower the friction of making a commit and reduce
>>> redundancy?
>
> EZ> IMO, what you'd like to have will actually _raise_ the friction
> EZ> (i.e. will be harder to provide) for many contributors, according to
> EZ> my experience of reviewing quite a few patches.
>
> I really don't think the current format is easy for anyone, especially
> new developers. It's also essentially repeating the headers from the
> diff.
>
> Anecdotally, every time I want to make a larger commit with a lot of
> items, it feels to me like paperwork for its own sake and takes up a
> long time.
>
> Let's take a recent example.
>
> commit 2fde6275b69fd113e78243790bf112bbdd2fe2bf
> Author: Basil L. Contovounesios <contovob@tcd.ie>
> Date:   Mon Jul 9 18:46:33 2018 -0700
>
>     Add predicate proper-list-p
>     
>     For discussion, see emacs-devel thread starting at
>     https://lists.gnu.org/archive/html/emacs-devel/2018-04/msg00460.html.
>     
>     * lisp/subr.el (proper-list-p): New function.
>     Implementation suggested by Paul Eggert <eggert@cs.ucla.edu> in
>     https://lists.gnu.org/archive/html/emacs-devel/2018-06/msg00138.html.
>     * doc/lispref/lists.texi (List Elements):
>     * etc/NEWS: Document proper-list-p.
>     * lisp/org/ob-core.el (org-babel-insert-result):
>     * lisp/emacs-lisp/byte-opt.el (byte-optimize-if):
>     * lisp/emacs-lisp/cl-macs.el (cl--make-usage-args): Use proper-list-p.
>     * lisp/emacs-lisp/ert.el (ert--proper-list-p): Remove.
>     Replaced by proper-list-p in lisp/subr.el.
>     (ert--explain-equal-rec): Use proper-list-length.
>     * lisp/format.el (format-proper-list-p): Remove.
>     Replaced by proper-list-p in lisp/subr.el.
>     (format-annotate-single-property-change): Use proper-list-p.
>     * test/lisp/emacs-lisp/ert-tests.el (ert-test-proper-list-p):
>     Move from here...
>     * test/lisp/subr-tests.el (subr-tests--proper-list-length):
>     ...to here, mutatis mutandis.
>
> Here's one way to write it more concisely and make it more readable,
> keeping in mind that the diff is part of the same log and is thus going
> to be right below the explanation, and Git usually already *knows* which
> files and functions have been modified. I'd much rather read the second
> version.
>
> commit 2fde6275b69fd113e78243790bf112bbdd2fe2bf
> Author: Basil L. Contovounesios <contovob@tcd.ie>
> Date:   Mon Jul 9 18:46:33 2018 -0700
>
>     Adds and documents the new predicate function proper-list-p
>
>     Factors out several one-off implementations of the same functionality.
>     For discussion, see emacs-devel thread starting at
>     https://lists.gnu.org/archive/html/emacs-devel/2018-04/msg00460.html.
>
>     Implementation suggested by Paul Eggert <eggert@cs.ucla.edu> in
>     https://lists.gnu.org/archive/html/emacs-devel/2018-06/msg00138.html.

I haven't been following this thread, so I apologise in advance if the
following comment completely misses the point or has been expressed
before.

Speaking as a relatively new and young Emacs contributor (i.e. one who
has learned to program in the age of Git and GitHub pull requests of the
last handful of years, is largely unfamiliar with and neither married to
nor dependent on older traditions and conventions, and has little to no
experience in maintaining large collaborative free software projects),
one aspect of changelog-style commit messages which I really appreciate
is that they are generally more amenable to fast and precise git-log
search.

In particular, I find 'git log --grep=<pattern>' is often significantly
faster and closer to what I'm looking for than a corresponding
'git log -G<regex>'.

In my fictional ideal world, I could avail of fast, accurate, and dwim
history search without ever having to write a tedious, mechanical
changelog.

In my day-to-day, however, there's nothing inherent in the changelog
style stopping me from writing clearer, less lazy, and human-readable
commit messages.

Just one datum.

-- 
Basil

Re: git history tracking across renames (and emacs support)

[Eli Zaretskii]

> From: Ted Zlatanov <tzz@lifelogs.com>
> Cc: larsi@gnus.org,  emacs-devel@gnu.org
> Date: Tue, 10 Jul 2018 20:54:33 +0000
> 
> >> Is there any chance of evolving the commit message formatting
> >> requirements to lower the friction of making a commit and reduce
> >> redundancy?
> 
> EZ> IMO, what you'd like to have will actually _raise_ the friction
> EZ> (i.e. will be harder to provide) for many contributors, according to
> EZ> my experience of reviewing quite a few patches.
> 
> I really don't think the current format is easy for anyone, especially
> new developers.

The format is produced mechanically by Emacs commands, so I don't see
why suddenly the format is the issue.  Maybe I interpret "format" not
the way you meant it?

> It's also essentially repeating the headers from the diff.

It summarizes diffs, in a way, yes (and allows to add explanations if
appropriate).  I don't see that as a disadvantage: you don't always
have the ability to generate diffs (e.g., in a release tarball).

> Anecdotally, every time I want to make a larger commit with a lot of
> items, it feels to me like paperwork for its own sake and takes up a
> long time.

It usually takes me a few seconds per change, so I don't see why you
feel like that.

> Here's one way to write it more concisely and make it more readable,

I'm not sure we should try to be as concise as possible in this case.
Why does the number of characters matter?  With the current format,
most of those characters are automatically generated by Emacs.

> keeping in mind that the diff is part of the same log and is thus going
> to be right below the explanation

Not when a ChangeLog is generated from it and put in the tarball.

> commit 2fde6275b69fd113e78243790bf112bbdd2fe2bf
> Author: Basil L. Contovounesios <contovob@tcd.ie>
> Date:   Mon Jul 9 18:46:33 2018 -0700
> 
>     Adds and documents the new predicate function proper-list-p
> 
>     Factors out several one-off implementations of the same functionality.
>     For discussion, see emacs-devel thread starting at
>     https://lists.gnu.org/archive/html/emacs-devel/2018-04/msg00460.html.
> 
>     Implementation suggested by Paul Eggert <eggert@cs.ucla.edu> in
>     https://lists.gnu.org/archive/html/emacs-devel/2018-06/msg00138.html.

Here are the problems with this method:

 . How do you explain in CONTRIBUTE what should and what shouldn't be
   in a log message?  We have trouble getting contributors to follow
   the current format; this one will leave us no levers to ask them to
   do it correctly, I think.  The same situation exists with comments,
   but comments we can fix by followup commits, whereas log messages
   are carved in stone once pushed.

 . We lose information about the "several one-off implementations"
   where the changes were done.  You assume this information can
   easily be gleaned by examining the diffs, but even if the diffs are
   readily available, that assumption is not really true IME: it
   sometimes takes a non-trivial effort.  For example, determining the
   function or variable in which the change was made is not always
   easy, as the diff hunks don't always announce the right symbol,
   especially if a single hunk describes changes in several of them,
   or if the language of the source is not supported by Diff for these
   purposes.

 . With changes that touch a single function or a small number of
   them, your proposal will actually yield _longer_ logs, which goes
   against your intent.  Worse, it will require contributors to sit
   down and think how to describe a simple change without repeating
   the diffs, something that at least some of them will find not so
   easy, being non-native English speakers.

Re: git history tracking across renames (and emacs support)

[Stefan Monnier]

> It summarizes diffs, in a way, yes (and allows to add explanations if
> appropriate).  I don't see that as a disadvantage: you don't always
> have the ability to generate diffs (e.g., in a release tarball).

FWIW, while I don't see the need to have such info when diffs aren't
available, I do sometimes appreciate the summarizing part: it's
easier to scan the commit message to see "oh there were 3 ad-hoc
definitions of proper-list-p replaced by the new one" than to try and
extract that info from the diff.

Whether this occasional benefit is worth the effort, I don't know.

> It usually takes me a few seconds per change, so I don't see why you
> feel like that.

It also takes me very little time, but our view is strongly biased here,
since we're doing it so often that we got really good at it.  For people
who don't contribute often to Emacs (or other projects using a similar
format) I'm sure it takes them significantly more time.

>  . How do you explain in CONTRIBUTE what should and what shouldn't be
>    in a log message?  We have trouble getting contributors to follow
>    the current format; this one will leave us no levers to ask them to
>    do it correctly, I think.  The same situation exists with comments,
>    but comments we can fix by followup commits, whereas log messages
>    are carved in stone once pushed.

Agreed.


        Stefan

Re: git history tracking across renames (and emacs support)

[Marcin Borkowski]

On 2018-07-11, at 05:32, Eli Zaretskii <eliz@gnu.org> wrote:

>> Anecdotally, every time I want to make a larger commit with a lot of
>> items, it feels to me like paperwork for its own sake and takes up a
>> long time.

I feel exactly the same.

> It usually takes me a few seconds per change, so I don't see why you
> feel like that.

I think Ted feels like that for a similar reason I do.  If you do your
contributions at least, say, three times a week, you just remember the
way (and Emacs commands to achieve the desired result).  Do it once
every month (or more rarely), and you're completely stuck every time.

>  . How do you explain in CONTRIBUTE what should and what shouldn't be
>    in a log message?  We have trouble getting contributors to follow
>    the current format; this one will leave us no levers to ask them to
>    do it correctly, I think.  The same situation exists with comments,
>    but comments we can fix by followup commits, whereas log messages
>    are carved in stone once pushed.

I don't think CONTRIBUTE is very clear on how to actually make your
commit message comply with the standards anyway.

I could try to make some simple change to see where the friction is so
that CONTRIBUTE can be made better, or even create a detailed technical
HOWTO explaining the steps you should take to create a correct commit
message.  I don't know about Ted and others, but for me that would be
a tremendous help with the process which I now consider arcane and
time-consuming.

Best,

--
Marcin Borkowski
http://mbork.pl

Re: git history tracking across renames (and emacs support)

[Eli Zaretskii]

> From: Marcin Borkowski <mbork@mbork.pl>
> Date: Wed, 11 Jul 2018 06:44:37 +0200
> Cc: Ted Zlatanov <tzz@lifelogs.com>, larsi@gnus.org, emacs-devel@gnu.org
> 
> >  . How do you explain in CONTRIBUTE what should and what shouldn't be
> >    in a log message?  We have trouble getting contributors to follow
> >    the current format; this one will leave us no levers to ask them to
> >    do it correctly, I think.  The same situation exists with comments,
> >    but comments we can fix by followup commits, whereas log messages
> >    are carved in stone once pushed.
> 
> I don't think CONTRIBUTE is very clear on how to actually make your
> commit message comply with the standards anyway.

If the text in CONTRIBUTE is unclear or needs more details, your
comments and suggestions to improve it will be welcome.

> I could try to make some simple change to see where the friction is so
> that CONTRIBUTE can be made better, or even create a detailed technical
> HOWTO explaining the steps you should take to create a correct commit
> message.

If you can afford it, please show such an explanation.

FWIW, I pretty much certain that it is impossible to provide such
instructions and yet keep your goal, because what Ted actually wants
is total freedom in what text is written, and to what depth and detail
level it should describe the change.  IMO and IME, trying to give too
specific instructions there will cause someone else, perhaps even
yourself, complain that the bar is too high again...  But don't let
that prevent you from trying to change my mind and the mind of others.

Thanks.

Re: git history tracking across renames (and emacs support), Re: git history tracking across renames (and emacs support), Re: git history tracking across renames (and emacs support), Re: git history tracking across renames (and emacs support)

[Ted Zlatanov]

On Wed, 11 Jul 2018 06:32:58 +0300 Eli Zaretskii <eliz@gnu.org> wrote: 

>> From: Ted Zlatanov <tzz@lifelogs.com>
>> I really don't think the current format is easy for anyone, especially
>> new developers.

EZ> The format is produced mechanically by Emacs commands, so I don't see
EZ> why suddenly the format is the issue.  Maybe I interpret "format" not
EZ> the way you meant it?

Any time you force people to produce artificially structured text, it's
a tedious chore no matter how much technology you wrap around it.

Emacs does not produce the format mechanically, unless you know the
right commands. It's IMHO a pain to learn them.

EZ> It summarizes diffs, in a way, yes (and allows to add explanations if
EZ> appropriate).  I don't see that as a disadvantage: you don't always
EZ> have the ability to generate diffs (e.g., in a release tarball).

Releases communicate through NEWS and release notes.

If the users need to read the commit logs to find what files and
functions have changed since the last release, something's wrong with
the release process.

>> Anecdotally, every time I want to make a larger commit with a lot of
>> items, it feels to me like paperwork for its own sake and takes up a
>> long time.

EZ> It usually takes me a few seconds per change, so I don't see why you
EZ> feel like that.

On Tue, 10 Jul 2018 23:53:21 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

SM> It also takes me very little time, but our view is strongly biased here,
SM> since we're doing it so often that we got really good at it.  For people
SM> who don't contribute often to Emacs (or other projects using a similar
SM> format) I'm sure it takes them significantly more time.

As Stefan said, it's mainly because I don't do it as often as you.
Familiarity takes time to achieve and sustain. In this case, it feels
like I'm doing work to satisfy the computer rather than to improve Emacs.

>> Here's one way to write it more concisely and make it more readable,

EZ> I'm not sure we should try to be as concise as possible in this case.
EZ> Why does the number of characters matter?  With the current format,
EZ> most of those characters are automatically generated by Emacs.

I'm advocating readability and less mechanical content, not conciseness
for its own sake.

EZ> Here are the problems with this method:

EZ>  . How do you explain in CONTRIBUTE what should and what shouldn't be
EZ>    in a log message?  We have trouble getting contributors to follow
EZ>    the current format; this one will leave us no levers to ask them to
EZ>    do it correctly, I think.  The same situation exists with comments,
EZ>    but comments we can fix by followup commits, whereas log messages
EZ>    are carved in stone once pushed.

SM> Agreed.

Log messages don't have to be carved in stone. You're justifying a human
cost with a technical side effect of the version control system.

I agree it's hard to explain what should be in a log message, but that's
because there's no perfect solution to the problem of writing down the
thought process and decisions that led to a solution. Certainly, I don't
think the current mechanical content improves that situation. It
*formalizes* the description of a specific subset of the decisions.

EZ>  . We lose information about the "several one-off implementations"
EZ>    where the changes were done.  You assume this information can
EZ>    easily be gleaned by examining the diffs, but even if the diffs are
EZ>    readily available, that assumption is not really true IME: it
EZ>    sometimes takes a non-trivial effort.

Good points. I don't think the current format makes that easy either.
Maybe there's a format that can link better and with less effort between
code and commit description in these complex cases.

EZ>  . With changes that touch a single function or a small number of
EZ>    them, your proposal will actually yield _longer_ logs, which goes
EZ>    against your intent.  Worse, it will require contributors to sit
EZ>    down and think how to describe a simple change without repeating
EZ>    the diffs, something that at least some of them will find not so
EZ>    easy, being non-native English speakers.

I think you're mixing several use cases and needs here.

Tiny changes: use the current format, it's cool.

Asking contributors to describe simple changes without repeating the
diffs: hell yeah.

Non-native English speakers: I don't see a big difference for them, they
will have a hard time regardless because Emacs is written and maintained
in English.

On Wed, 11 Jul 2018 06:44:37 +0200 Marcin Borkowski <mbork@mbork.pl> wrote: 

MB> I could try to make some simple change to see where the friction is so
MB> that CONTRIBUTE can be made better, or even create a detailed technical
MB> HOWTO explaining the steps you should take to create a correct commit
MB> message.  I don't know about Ted and others, but for me that would be
MB> a tremendous help with the process which I now consider arcane and
MB> time-consuming.

EZ> FWIW, I pretty much certain that it is impossible to provide such
EZ> instructions and yet keep your goal, because what Ted actually wants
EZ> is total freedom in what text is written, and to what depth and detail
EZ> level it should describe the change.

ALSO I WANT A PONY.

OK, OK. I'm assuming there will be no change to the current format
requirements based on this thread. I'll be happily surprised if it
happens but let's be realistic. It's not a bad thing--we're having a
discussion about how to improve things. It's definitely helped me
understand Stefan and Eli's position, and we've heard from Basil and
Marcin as well.

With that assumption, ideally the current mechanical format should be
entirely pre-populated from the diff, and filled out where possible
(e.g. "added new function" "deleted symbol"). This should be a single
command "make a commit message" without a thousand options and VC or
other special interactions.

The editing mode for that format should have enough intelligence to
refresh itself (asking first, of course) if the source code is changed
underneath.

That would probably be enough to save a significant amount of time for
most non-daily contributors. Is it possible?

(This is where I'm informed it's been done already but in Haskell)

Ted

Re: git history tracking across renames (and emacs support), Re: git history tracking across renames (and emacs support), Re: git history tracking across renames (and emacs support), Re: git history tracking across renames (and emacs support)

[Eli Zaretskii]

> From: Ted Zlatanov <tzz@lifelogs.com>
> Cc: Marcin Borkowski <mbork@mbork.pl>,  Stefan Monnier <monnier@iro.umontreal.ca>,  emacs-devel@gnu.org,  larsi@gnus.org
> Date: Wed, 11 Jul 2018 13:54:49 +0000
> 
> Emacs does not produce the format mechanically, unless you know the
> right commands. It's IMHO a pain to learn them.

There's only one command: "C-x 4 a".

> EZ> It summarizes diffs, in a way, yes (and allows to add explanations if
> EZ> appropriate).  I don't see that as a disadvantage: you don't always
> EZ> have the ability to generate diffs (e.g., in a release tarball).
> 
> Releases communicate through NEWS and release notes.
> 
> If the users need to read the commit logs to find what files and
> functions have changed since the last release, something's wrong with
> the release process.

We have no release notes except NEWS.  And NEWS only mentions new
features and changes in behavior, it doesn't mention bugfixes, which
is a large portion (if not the majority) of changes in any release.

ChangeLog files provide information about changes when one has no
up-to-date repository around.

> As Stefan said, it's mainly because I don't do it as often as you.
> Familiarity takes time to achieve and sustain. In this case, it feels
> like I'm doing work to satisfy the computer rather than to improve Emacs.

This old curmudgeon found solution to such situations: where I do
something rarely enough to be unable to trust my memory, I keep notes.
It's a surprisingly effective and efficient way, you should try that
some time.

> I'm advocating readability and less mechanical content, not conciseness
> for its own sake.

I understand.  I'm just saying that it takes more time and effort to
generate such less mechanical content, so you are probably raising the
bar, not lowering it.

> Log messages don't have to be carved in stone. You're justifying a human
> cost with a technical side effect of the version control system.

It doesn't have to be so, but AFAIK the last VCS where log messages
could be amended was CVS.  In our brave new world, log messages _are_
carved in stone once committed.  That's the reality in which we live,
whether we like it or not.

> I agree it's hard to explain what should be in a log message, but that's
> because there's no perfect solution to the problem of writing down the
> thought process and decisions that led to a solution. Certainly, I don't
> think the current mechanical content improves that situation. It
> *formalizes* the description of a specific subset of the decisions.

It gives me easy tools to teach newcomers how to write log messages we
want to see.  Once this is taken from me, what can I say to a
contributor who claims that his/her log message is just fine, because
there's nothing in CONTRIBUTE to say it isn't?

> Maybe there's a format that can link better and with less effort between
> code and commit description in these complex cases.

If someone would like to write a command that looks at the last commit
(or several commits), and generates a skeleton of a log entry, I'm all
for it.  (People will have to "git commit --amend" to use such a
command, but that's not a problem, I think, and could also be
automated.)

Re: git history tracking across renames (and emacs support), Re: git history tracking across renames (and emacs support), Re: git history tracking across renames (and emacs support), Re: git history tracking across renames (and emacs support)

[Clément Pit-Claudel]

On 2018-07-11 11:42, Eli Zaretskii wrote:
> If someone would like to write a command that looks at the last commit
> (or several commits), and generates a skeleton of a log entry, I'm all
> for it.  (People will have to "git commit --amend" to use such a
> command, but that's not a problem, I think, and could also be
> automated.)

Indeed, I suspect a simple magit extension to populate the current commit message buffer with the appropriate text would satisfy most people who dislike the current format.
(I'm suggesting magit because I don't know how the build-in VC frontend works in terms of inputing commit messages)

Clément.

Re: git history tracking across renames (and emacs support), Re: git history tracking across renames (and emacs support), Re: git history tracking across renames (and emacs support), Re: git history tracking across renames (and emacs support)

[Eric Abrahamsen]

Clément Pit-Claudel <cpitclaudel@gmail.com> writes:

> On 2018-07-11 11:42, Eli Zaretskii wrote:
>> If someone would like to write a command that looks at the last commit
>> (or several commits), and generates a skeleton of a log entry, I'm all
>> for it.  (People will have to "git commit --amend" to use such a
>> command, but that's not a problem, I think, and could also be
>> automated.)
>
> Indeed, I suspect a simple magit extension to populate the current
> commit message buffer with the appropriate text would satisfy most
> people who dislike the current format.
> (I'm suggesting magit because I don't know how the build-in VC
> frontend works in terms of inputing commit messages)

I use `magit-commit-add-log' ("C" in the magit diff buffer) and that
gets me close enough to the correct format that it's only a small pain
to get the rest of the way there. Perhaps all that's needed is a
refinement for that command (mostly in the way it accumulates symbol
names as you use it multiple times).

Eric

Re: git history tracking across renames (and emacs support), Re: git history tracking across renames (and emacs support), Re: git history tracking across renames (and emacs support), Re: git history tracking across renames (and emacs support)

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

Changing Magit cannot be a real solution unless/until we can have Magit
included in Emacs.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: git history tracking across renames (and emacs support), Re: git history tracking across renames (and emacs support), Re: git history tracking across renames (and emacs support), Re: git history tracking across renames (and emacs support)

[Noam Postavsky]

On 11 July 2018 at 18:50, Richard Stallman <rms@gnu.org> wrote:

> Changing Magit cannot be a real solution unless/until we can have Magit
> included in Emacs.

Magit's maintainer is generally in favour of improving add-log.el so
that both Magit and Emacs vc modes could use it.

https://github.com/magit/magit/issues/2931
Which also references Emacs Bug#16301
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=16301

Re: git history tracking across renames (and emacs support), Re: git history tracking across renames (and emacs support), Re: git history tracking across renames (and emacs support), Re: git history tracking across renames (and emacs support)

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

  > Magit's maintainer is generally in favour of improving add-log.el so
  > that both Magit and Emacs vc modes could use it.

I think that's a good approach.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: git history tracking across renames (and emacs support), Re: git history tracking across renames (and emacs support), Re: git history tracking across renames (and emacs support), Re: git history tracking across renames (and emacs support)

[Jonas Bernoulli]

Noam Postavsky <npostavs@gmail.com> writes:

> On 11 July 2018 at 18:50, Richard Stallman <rms@gnu.org> wrote:
>
>> Changing Magit cannot be a real solution unless/until we can have Magit
>> included in Emacs.
>
> Magit's maintainer is generally in favour of improving add-log.el so
> that both Magit and Emacs vc modes could use it.
>
> https://github.com/magit/magit/issues/2931
> Which also references Emacs Bug#16301
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=16301

For people not following links, this is the most important point I am
making there:

The functionality should be split like so:

1. Generate a list of all changed symbols.
2. Format the list according to some preference.
3. Insert the formatted list somewhere.

Currently this is kinda squashed into a single task implemented in
`add-change-log-entry' for the most part and the current approach to
adding multiple entries (`diff-add-change-log-entries-other-window')
is implemented by calling that function multiple times.

`add-log-current-defun' implements part of (1), returning DEFUN,
but I think it should be extended to return (DEFUN FILE) at least.

And to complete (1) we would also need `add-log-defuns', returning
((FILE (DEFUN LINE)...)...).  Both of these functions should operate
on an (actual) diff, I think.

---

I haven't read all of the current discussion but got the impression that
a lot of it revolved around ChangeLog vs. commit message.  I think we
can easily have both, but only if we split the functionality as
suggested above.  Whether *Emacs* should ChangeLog files is a different
discussion (which I don't want to take part in), and it really does not
matter; some projects (currently including Emacs) use ChangeLog files,
while other (possibly including Emacs in the future) put the list of
modified symbols into the commit message only.  And regardless of where
the information is put, not every project uses the same format.

As I see it, the hard part -- from a technical perspective -- is to
reliably collect the list of modified "defuns" for as many languages as
possible (1).  Currently this is done using `add-log-current-defun', but
there are probably more reliable and universal, yet customizable,
implementations to be found elsewhere in Emacs.

From a non-technical perspective the hard part is agreeing on what the
one and only correct way of recording this information is, which I think
we never be able to agree on.  We (everyone using version control) also
don't have to.  So lets keep those things separate.

Re: git history tracking across renames (and emacs support)

[Eli Zaretskii]

> From: Jonas Bernoulli <jonas@bernoul.li>
> Date: Fri, 13 Jul 2018 15:13:41 -0500
> Cc: Clément Pit-Claudel <cpitclaudel@gmail.com>,
> 	Richard Stallman <rms@gnu.org>, Emacs developers <emacs-devel@gnu.org>
> 
> The functionality should be split like so:
> 
> 1. Generate a list of all changed symbols.
> 2. Format the list according to some preference.
> 3. Insert the formatted list somewhere.

Sounds reasonable, thanks.

> Whether *Emacs* should ChangeLog files is a different discussion
> (which I don't want to take part in)

This has never been part of this discussion, because that ship has
sailed more than 3 years ago, and I don't think it's coming back.

> some projects (currently including Emacs) use ChangeLog files,
> while other (possibly including Emacs in the future) put the list of
> modified symbols into the commit message only.  And regardless of where
> the information is put, not every project uses the same format.

Actually, Emacs stopped maintaining ChangeLog files in Apr 2015.  We
nowadays generate ChangeLog from the Git log as part of preparing a
release tarball.  The ChangeLog-like entries we've been discussing are
those we put into the Git commit log messages.

> >From a non-technical perspective the hard part is agreeing on what the
> one and only correct way of recording this information is, which I think
> we never be able to agree on.  We (everyone using version control) also
> don't have to.  So lets keep those things separate.

They are not entirely separate, though: my impression is that some of
the friction uncovered in this and similar discussions is that people
have difficulties integrating the technical part (i.e. generation of
the log entries) into their workflows.  So one way of making the
friction lower is to make this integration easier by providing
convenience features that cater to more workflows than we currently
support.

Thanks.

Re: git history tracking across renames (and emacs support)

[Ted Zlatanov]

(Sorry about the triple subject message. Gnus did it! I blame Lars!)

On Wed, 11 Jul 2018 18:42:02 +0300 Eli Zaretskii <eliz@gnu.org> wrote: 

>> From: Ted Zlatanov <tzz@lifelogs.com>
>> 
>> Emacs does not produce the format mechanically, unless you know the
>> right commands. It's IMHO a pain to learn them.

EZ> There's only one command: "C-x 4 a".

I think that's not entirely accurate. It sort of works for most cases
from a single file. But it opens a ChangeLog file, not a commit entry,
which is really odd. And it has many other special behaviors (e.g.
doesn't regenerate entries if the code changes).

But it could open a *mode* where users can interact with the commit
message, as you and Clément suggested.

Ted

Re: git history tracking across renames (and emacs support)

[Eli Zaretskii]

> From: Ted Zlatanov <tzz@lifelogs.com>
> Cc: Clément Pit-Claudel <cpitclaudel@gmail.com>,
>   emacs-devel@gnu.org,  larsi@gnus.org,  monnier@iro.umontreal.ca
> Date: Wed, 11 Jul 2018 17:31:57 +0000
> 
> EZ> There's only one command: "C-x 4 a".
> 
> I think that's not entirely accurate. It sort of works for most cases
> from a single file. But it opens a ChangeLog file, not a commit entry,
> which is really odd. And it has many other special behaviors (e.g.
> doesn't regenerate entries if the code changes).

Yes, it opens ChangeLog, but copy-pasting from there to the log buffer
when committing is trivial, right?  And you will see that our
.gitignore conveniently ignores ChangeLog.

> But it could open a *mode* where users can interact with the commit
> message, as you and Clément suggested.

There's the "C-c C-a" command in the *vc-log* buffer, if the above
somehow is not convenient for you.  One of these always does the job
for me.

Re: git history tracking across renames (and emacs support)

[Paul Eggert]

Eli Zaretskii wrote:

> There's the "C-c C-a" command in the *vc-log* buffer, if the above
> somehow is not convenient for you.  One of these always does the job
> for me.

I use vc-dwim instead, and combine this with C-x 4 a to edit the commit messages 
/ ChangeLog entries. It's pretty awkward, but for me it beats the alternatives.

https://www.gnu.org/software/vc-dwim/

Re: git history tracking across renames (and emacs support)

[João Távora]

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

On Wed, Jul 11, 2018, 19:14 Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Ted Zlatanov <tzz@lifelogs.com>
> > Cc: Clément Pit-Claudel <cpitclaudel@gmail.com>,
> >   emacs-devel@gnu.org,  larsi@gnus.org,  monnier@iro.umontreal.ca
> > Date: Wed, 11 Jul 2018 17:31:57 +0000
> >
> > EZ> There's only one command: "C-x 4 a".
> >
> > I think that's not entirely accurate. It sort of works for most cases
> > from a single file. But it opens a ChangeLog file, not a commit entry,
> > which is really odd. And it has many other special behaviors (e.g.
> > doesn't regenerate entries if the code changes).
>
> Yes, it opens ChangeLog, but copy-pasting from there to the log buffer
> when committing is trivial, right?  And you will see that our
> .gitignore conveniently ignores .ChangeLog
>

To be fair, there isn't even any copy-paste involved if you use
vc-next-action and such.

But that doesn't mean it's not horribly impractical. I hate the ChangeLog
buffers, especially how they interact with save-some-buffers because
invariably I end up saving them inadvertently.

I wish there was a way to make these buffers without buffer-file-name and
still have vc collect the entries from them.  Also, after committing, the
entries would actually be removed.

Would a patch for this be welcome?

This would be a big improvement for me, because otherwise I quite like
the ChangeLog
format. It has saved my hide many times, especially during tricky merges or
rebases.




>

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

Re: git history tracking across renames (and emacs support)

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Wed, 11 Jul 2018 23:36:56 +0100
> Cc: Ted Zlatanov <tzz@lifelogs.com>, Clément Pit-Claudel <cpitclaudel@gmail.com>, 
> 	larsi@gnus.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> To be fair, there isn't even any copy-paste involved if you use vc-next-action and such.
> 
> But that doesn't mean it's not horribly impractical. I hate the ChangeLog buffers, especially how they interact
> with save-some-buffers because invariably I end up saving them inadvertently.

Why is it a problem to save ChangeLog to its file?  Our .gitignore
already ignores such a file.  I have a local ChangeLog file full of
log messages I used for commits I pushed.

> Would a patch for this be welcome?

I'd need to see the patch, of course.  For now, I'm afraid I don't
understand the problem.

Re: git history tracking across renames (and emacs support)

[João Távora]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: João Távora <joaotavora@gmail.com>
>> Date: Wed, 11 Jul 2018 23:36:56 +0100
>> Cc: Ted Zlatanov <tzz@lifelogs.com>, Clément Pit-Claudel <cpitclaudel@gmail.com>, 
>> 	larsi@gnus.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org
>> 
>> To be fair, there isn't even any copy-paste involved if you use vc-next-action and such.
>> 
>> But that doesn't mean it's not horribly impractical. I hate the
>> ChangeLog buffers, especially how they interact
>> with save-some-buffers because invariably I end up saving them inadvertently.
>
> Why is it a problem to save ChangeLog to its file?  Our .gitignore
> already ignores such a file. I have a local ChangeLog file full of
> log messages I used for commits I pushed.
>
>> Would a patch for this be welcome?
>
> I'd need to see the patch, of course.  For now, I'm afraid I don't
> understand the problem.

To be clear, it's a minor annoyance (that's what "horribly impractical"
means to me :-)) but it's repeated across all my projects, because I use
this format there too.

So I typically end up having around 5 ChangeLog files per session.
Generally, because the ChangeLog _file_ is now a useless intermediary,
any friction it gives me is too much.

Now the actual annoyance:

1.  save-some-buffers constantly nags me about saving the useless file
    ChangeLog.  I worked around this with a
    save-some-buffers-default-predicate, but sometimes I like to work
    from Emacs -Q (typically after reproducing a bug) and I'm still
    annoyed there.

2.  killing the ChangeLog buffer in other situations (when generally
    cleaning up my buffer list) also prompts me about saving it;
    
3.  when performing multiple commits to one project on the same day,
    vc-next-action blindly copies all entries for the day, duplicating
    entries in my commit message.  So I have to remember to kill the
    buffer before the first `C-x 4 a' of the commit I'm about to do.
    Which means I have to find it in my buffer list, and then it asks me
    if I want to save it ("grrr, no! yes! whatever!").  Alternatively, I
    can find the buffer and delete its contents, also kind-of
    impractical.  Alternatively, what I've been doing recently, is to
    issue the first `C-x 4 a' just to find the dang buffer, then delete
    everything, then `C-x o', then do that same `C-x 4 a' again.  It
    works, but feels kinda silly.

4.  When I do need, for whatever reason, to manually copy-paste from the
    ChangeLog buffer, it annoys me that the indentation is not the same.
    It also annoys me that fontification and fill-paragraph doesn't work
    in vc-git-log-edit-mode like it does in change-log-mode.  Can it be
    made to?

So the patch I envison would address some or all of these points
friction (and would be optional, for those who for some reason really
like to have a file-supported ChangeLog buffer around).

But perhaps, before spending time on the patch, you or someone else can
tell me if you use ChangeLog for more projects than Emacs and/or how you
avoid these annoyances.

João

Re: git history tracking across renames (and emacs support)

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Cc: larsi@gnus.org,  tzz@lifelogs.com,  emacs-devel@gnu.org,  cpitclaudel@gmail.com,  monnier@iro.umontreal.ca
> Date: Thu, 12 Jul 2018 10:04:17 +0100
> 
> Now the actual annoyance:
> 
> 1.  save-some-buffers constantly nags me about saving the useless file
>     ChangeLog.  I worked around this with a
>     save-some-buffers-default-predicate, but sometimes I like to work
>     from Emacs -Q (typically after reproducing a bug) and I'm still
>     annoyed there.
> 
> 2.  killing the ChangeLog buffer in other situations (when generally
>     cleaning up my buffer list) also prompts me about saving it;
>     
> 3.  when performing multiple commits to one project on the same day,
>     vc-next-action blindly copies all entries for the day, duplicating
>     entries in my commit message.  So I have to remember to kill the
>     buffer before the first `C-x 4 a' of the commit I'm about to do.
>     Which means I have to find it in my buffer list, and then it asks me
>     if I want to save it ("grrr, no! yes! whatever!").  Alternatively, I
>     can find the buffer and delete its contents, also kind-of
>     impractical.  Alternatively, what I've been doing recently, is to
>     issue the first `C-x 4 a' just to find the dang buffer, then delete
>     everything, then `C-x o', then do that same `C-x 4 a' again.  It
>     works, but feels kinda silly.
> 
> 4.  When I do need, for whatever reason, to manually copy-paste from the
>     ChangeLog buffer, it annoys me that the indentation is not the same.
>     It also annoys me that fontification and fill-paragraph doesn't work
>     in vc-git-log-edit-mode like it does in change-log-mode.  Can it be
>     made to?

You are working too hard, IMO.  I generally write the GNU-style
ChangeLog entries only when I land a feature on the development
branch, I don't write them while working on a feature branch.  On a
feature branch, my log entries are very short and only describe what
milestones were reached and what significant issues fixed.  So the
multiple entries and related problems never happen for me.

As for the rest, if you insist on not having a real file with
ChangeLog entries, then perhaps add-log.el could be extended to be
able to use a buffer name, not just a file name, for where to put the
log messages.  It already allows you to customize the file name; it
could do something similar with a buffer name, and that buffer could
have no file name.  Then a large part of your problems would go away,
AFAIU.  (This will not solve the problem in "emacs -Q", but nothing
like this could ever do that, since it should be obvious that whatever
you code will be an optional feature.)

And having the vc-log buffer under change-log-mode is, of course,
trivial, either with your customizations or by default.

> But perhaps, before spending time on the patch, you or someone else can
> tell me if you use ChangeLog for more projects than Emacs and/or how you
> avoid these annoyances.

I just told you: I have a real ChangeLog file in the repository.  With
some projects, this file is versioned; with others, it is a local
untracked file mentioned in .gitignore.  Emacs belongs to the latter
category.

Re: git history tracking across renames (and emacs support)

[João Távora]

Eli Zaretskii <eliz@gnu.org> writes:

> You are working too hard, IMO.  I generally write the GNU-style
> ChangeLog entries only when I land a feature on the development
> branch, I don't write them while working on a feature branch.  On a
> feature branch, my log entries are very short and only describe what
> milestones were reached and what significant issues fixed.  So the
> multiple entries and related problems never happen for me.

Yeah I do scratchy local dev work without proper entries too, but I
wasn't talking about that, just about committing twice to the same file
on the same day.  I take it you never do (really?)

> As for the rest, if you insist on not having a real file with
> ChangeLog entries, then perhaps add-log.el could be extended to be
> able to use a buffer name, not just a file name, for where to put the
> log messages.  It already allows you to customize the file name; it
> could do something similar with a buffer name, and that buffer could
> have no file name.  Then a large part of your problems would go away,
> AFAIU.

Yes, this was more or less what I had in mind, except I thought about
encoding that information in a buffer-local variable.  But your idea of
doing it in the buffer's name sounds better.

> (This will not solve the problem in "emacs -Q", but nothing like this
> could ever do that, since it should be obvious that whatever you code
> will be an optional feature.)

Perhaps it could work in emacs -Q if you make the whole feature depend
on a variable which I can set dir-locally (presumably not in Emacs, but
in all my other projects).

> And having the vc-log buffer under change-log-mode is, of course,
> trivial, either with your customizations or by default.

But that in turn would lose me some useful that vc-log functionality.
AFAIU the two modes should be merged, maybe one deriving from the other.

>> But perhaps, before spending time on the patch, you or someone else can
>> tell me if you use ChangeLog for more projects than Emacs and/or how you
>> avoid these annoyances.
>
> I just told you: I have a real ChangeLog file in the repository.  With
> some projects, this file is versioned; with others, it is a local
> untracked file mentioned in .gitignore.  Emacs belongs to the latter
> category.

Right, I was just making sure I wasn't missing some other trick.

I think the changes envisioned above (particularly the fileless
ChangeLog buffer) only justify working on them if noone else is working
on the better alternative, which is IMO to automatically generate the "*
file.ext (changed entity)" list from the diff at commit-preparation
time, as I think someone suggested already.

João

Re: git history tracking across renames (and emacs support)

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Thu, 12 Jul 2018 17:26:21 +0100
> Cc: larsi@gnus.org, cpitclaudel@gmail.com, tzz@lifelogs.com,
> 	monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > You are working too hard, IMO.  I generally write the GNU-style
> > ChangeLog entries only when I land a feature on the development
> > branch, I don't write them while working on a feature branch.  On a
> > feature branch, my log entries are very short and only describe what
> > milestones were reached and what significant issues fixed.  So the
> > multiple entries and related problems never happen for me.
> 
> Yeah I do scratchy local dev work without proper entries too, but I
> wasn't talking about that, just about committing twice to the same file
> on the same day.  I take it you never do (really?)

Of course, I do.  But I have a real ChangeLog file, and I use
"C-x 4 a", not the vc-next-action followed by "C-c C-a".

Re: git history tracking across renames (and emacs support)

[João Távora]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: João Távora <joaotavora@gmail.com>
>> Date: Thu, 12 Jul 2018 17:26:21 +0100
>> Cc: larsi@gnus.org, cpitclaudel@gmail.com, tzz@lifelogs.com,
>> 	monnier@iro.umontreal.ca, emacs-devel@gnu.org
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > You are working too hard, IMO.  I generally write the GNU-style
>> > ChangeLog entries only when I land a feature on the development
>> > branch, I don't write them while working on a feature branch.  On a
>> > feature branch, my log entries are very short and only describe what
>> > milestones were reached and what significant issues fixed.  So the
>> > multiple entries and related problems never happen for me.
>> 
>> Yeah I do scratchy local dev work without proper entries too, but I
>> wasn't talking about that, just about committing twice to the same file
>> on the same day.  I take it you never do (really?)
>
> Of course, I do.  But I have a real ChangeLog file, and I use
> "C-x 4 a", not the vc-next-action followed by "C-c C-a".

OK, to be clear I also use "C-x 4 a" and, begrudgingly, a real ChangeLog
file.  So I take it the difference is that you find and copy-paste the
entries from the file.  It's my turn to say you are working too hard,
IMO :-).

João

Re: git history tracking across renames (and emacs support)

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Cc: larsi@gnus.org,  cpitclaudel@gmail.com,  tzz@lifelogs.com,  monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Thu, 12 Jul 2018 17:47:53 +0100
> 
> OK, to be clear I also use "C-x 4 a" and, begrudgingly, a real ChangeLog
> file.  So I take it the difference is that you find and copy-paste the
> entries from the file.  It's my turn to say you are working too hard,
> IMO :-).

It's just 2 keypresses, and then "C-u -8 C-x TAB" to fix the
indentation.  That's all.  I can almost do that in my sleep.

Re: git history tracking across renames (and emacs support)

[Stefan Monnier]

> Perhaps it could work in emacs -Q if you make the whole feature depend
> on a variable which I can set dir-locally (presumably not in Emacs, but
> in all my other projects).

Actually, I think it can be made to work without any customization
(take the absence of a ChangeLog file as the cue).

>> And having the vc-log buffer under change-log-mode is, of course,
>> trivial, either with your customizations or by default.
> But that in turn would lose me some useful that vc-log functionality.
> AFAIU the two modes should be merged, maybe one deriving from the other.

They're different:
- change-log-mode handles a sequence of commit messages
- it includes dates
- it uses a different syntax for authorship
- its entries are indented with a TAB
- it doesn't know about the special first line "Subject: ".

So, while I do think that some of change-log-mode's features should be
made available in *vc-log* buffers, it's not just a "merge".

> I think the changes envisioned above (particularly the fileless
> ChangeLog buffer) only justify working on them if noone else is working
> on the better alternative, which is IMO to automatically generate the "*
> file.ext (changed entity)" list from the diff at commit-preparation
> time, as I think someone suggested already.

AFAIK the two issues are orthogonal/complementary: ChangeLog files are
being phased out pretty much everywhere, AFAIK, so while we'll probably
want change-log-mode to keep supporting them for the foreseeable future,
we do want to adapt it to the newer use case where similar entries are
recorded in the commit log rather than in a file.

BTW, there's diff-add-change-log-entries-other-window (bound to `C-x
4 A` in diff-mode) which already tries to create the list of entries
from the diff.
[ It turns out it's not as easy as it seems to make it work well :-(  ]


        Stefan

Re: git history tracking across renames (and emacs support)

[João Távora]

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

>> Perhaps it could work in emacs -Q if you make the whole feature depend
>> on a variable which I can set dir-locally (presumably not in Emacs, but
>> in all my other projects).
>
> Actually, I think it can be made to work without any customization
> (take the absence of a ChangeLog file as the cue).

Yes, I'm fine with that.

>>> And having the vc-log buffer under change-log-mode is, of course,
>>> trivial, either with your customizations or by default.
>> But that in turn would lose me some useful that vc-log functionality.
>> AFAIU the two modes should be merged, maybe one deriving from the other.
>
> They're different:
> - change-log-mode handles a sequence of commit messages
> - it includes dates
> - it uses a different syntax for authorship
> - its entries are indented with a TAB
> - it doesn't know about the special first line "Subject: ".
>
> So, while I do think that some of change-log-mode's features should be
> made available in *vc-log* buffers, it's not just a "merge".

Right, we agree.  I should have said a "process whereby things from two
different things are combined into one thing".

>> I think the changes envisioned above (particularly the fileless
>> ChangeLog buffer) only justify working on them if noone else is working
>> on the better alternative, which is IMO to automatically generate the "*
>> file.ext (changed entity)" list from the diff at commit-preparation
>> time, as I think someone suggested already.
>
> AFAIK the two issues are orthogonal/complementary: ChangeLog files are
> being phased out pretty much everywhere, AFAIK, so while we'll probably
> want change-log-mode to keep supporting them for the foreseeable future,
> we do want to adapt it to the newer use case where similar entries are
> recorded in the commit log rather than in a file.

I have no problem in keeping the ChangeLog funtionality intact.  I just
said that the small enhancements I proposed to it would probably be
useless in the face of an "add-from-diff-directly-into-vc-log"
alternative.

> BTW, there's diff-add-change-log-entries-other-window (bound to `C-x
> 4 A` in diff-mode) which already tries to create the list of entries
> from the diff.
> [ It turns out it's not as easy as it seems to make it work well :-(  ]

Thanks, didn't knwo that.  Are the current hangups listed somewhere?

João

Re: git history tracking across renames (and emacs support)

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Thu, 12 Jul 2018 17:56:09 +0100
> Cc: tzz@lifelogs.com, Eli Zaretskii <eliz@gnu.org>, cpitclaudel@gmail.com,
> 	larsi@gnus.org, emacs-devel@gnu.org
> 
> > BTW, there's diff-add-change-log-entries-other-window (bound to `C-x
> > 4 A` in diff-mode) which already tries to create the list of entries
> > from the diff.
> > [ It turns out it's not as easy as it seems to make it work well :-(  ]
> 
> Thanks, didn't know that.

It's an invaluable feature when you need to generate log entries from
diffs that someone submitted without ones.

Re: git history tracking across renames (and emacs support)

[Ted Zlatanov]

On Thu, 12 Jul 2018 20:01:37 +0300 Eli Zaretskii <eliz@gnu.org> wrote: 

>> From: João Távora <joaotavora@gmail.com>
>> 
>> > BTW, there's diff-add-change-log-entries-other-window (bound to `C-x
>> > 4 A` in diff-mode) which already tries to create the list of entries
>> > from the diff.
>> > [ It turns out it's not as easy as it seems to make it work well :-(  ]
>> 
>> Thanks, didn't know that.

EZ> It's an invaluable feature when you need to generate log entries from
EZ> diffs that someone submitted without ones.

That's more or less what I'm suggesting, except it should be more of an
interactive editor with auto or manual refreshing, not a one-shot
command. I don't know how to write it, personally.

Ted

Re: git history tracking across renames (and emacs support)

[Eli Zaretskii]

> From: Ted Zlatanov <tzz@lifelogs.com>
> Cc: João Távora <joaotavora@gmail.com>,
>   larsi@gnus.org,  cpitclaudel@gmail.com,  monnier@IRO.UMontreal.CA,
>   emacs-devel@gnu.org
> Date: Thu, 12 Jul 2018 19:37:56 +0000
> 
> >> > BTW, there's diff-add-change-log-entries-other-window (bound to `C-x
> >> > 4 A` in diff-mode) which already tries to create the list of entries
> >> > from the diff.
> >> > [ It turns out it's not as easy as it seems to make it work well :-(  ]
> >> 
> >> Thanks, didn't know that.
> 
> EZ> It's an invaluable feature when you need to generate log entries from
> EZ> diffs that someone submitted without ones.
> 
> That's more or less what I'm suggesting, except it should be more of an
> interactive editor with auto or manual refreshing, not a one-shot
> command.

If you ever used it, then you know that all it does is generate the
names of the functions to which the hunks belong.  That's important,
but it is not the only important part in the log, of course.

And it doesn't work at all when you are presented with a merge-commit,
because that one has no diffs with Git.

Re: git history tracking across renames (and emacs support)

[Stefan Monnier]

> Thanks, didn't knwo that.  Are the current hangups listed somewhere?

I don't think so, no.
IIRC the problems where linked to hunk that delete/add
several definitions and is made more "interesting" for languages that
allow nested definitions.


        Stefan

Re: git history tracking across renames (and emacs support)

[João Távora]

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

>> Thanks, didn't knwo that.  Are the current hangups listed somewhere?
>
> I don't think so, no.
> IIRC the problems where linked to hunk that delete/add
> several definitions and is made more "interesting" for languages that
> allow nested definitions.

I see.  Any thoughts on leveraging imenu for this?

João

Re: git history tracking across renames (and emacs support)

[Stefan Monnier]

>>> Thanks, didn't knwo that.  Are the current hangups listed somewhere?
>> I don't think so, no.
>> IIRC the problems where linked to hunk that delete/add
>> several definitions and is made more "interesting" for languages that
>> allow nested definitions.
> I see.  Any thoughts on leveraging imenu for this?

I suspect beginning-of-defun will be more convenient, but yes, I guess
`imenu` could come in handy as well.


        Stefan

[PATCH] New option to make C-x 4 a use file-less ChangeLog buffers (was Re: git history tracking across renames (and emacs support))

[João Távora]

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

Eli Zaretskii <eliz@gnu.org> writes:

> [...] perhaps add-log.el could be extended to be able to use a buffer
> name, not just a file name, for where to put the log messages.  It
> already allows you to customize the file name; it could do something
> similar with a buffer name, and that buffer could have no file name.
> Then a large part of your problems would go away, AFAIU.

Hi Eli,

Find attached a patch that does exactly this.  It is only lightly
tested, so I need a clinical eye that I didn't break anything.
Fortunately, it is quite short.  Appropriately, I used it to compose the
commit message (and I don't have any ChangeLog files lying around).

If this is accepted, I can submit more patches for more related
functionality.  The next two I imagine, in this order, are:

* C-c C-c (commit-time in vc-log) somehow disables the entries collected
  by C-c C-a in the ChangeLog buffer.

* Use a single ChangeLog buffer indexed by projects (Stefan's idea)

Thanks,
João


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-New-option-to-make-C-x-4-a-use-file-less-ChangeLog-b.patch --]
[-- Type: text/x-diff, Size: 6411 bytes --]

From 867540c9310ee12ca477e744571d93f56f5f888d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jo=C3=A3o=20T=C3=A1vora?= <joaotavora@gmail.com>
Date: Sat, 14 Jul 2018 18:29:48 +0100
Subject: [PATCH] New option to make C-x 4 a use file-less ChangeLog buffers

* lisp/vc/add-log.el (add-log-file-name): Update docstring.
(add-log-use-pseudo-changelog): New defcustom.
(add-log-find-changelog-buffer): New helper.
(add-change-log-entry): Can work with ChangeLog file-less
buffers.  Change name of argument FILE-NAME arg to be more
explicit.  Explain new meaning of arg in docstring.
(add-log--changelog-buffer-p): New helper.

* lisp/vc/log-edit.el (log-edit-changelog-entries): Use
add-log-use-pseudo-changelog and add-log-find-changelog-buffer.
---
 lisp/vc/add-log.el  | 67 +++++++++++++++++++++++++++++++++++++--------
 lisp/vc/log-edit.el |  6 ++--
 2 files changed, 59 insertions(+), 14 deletions(-)

diff --git a/lisp/vc/add-log.el b/lisp/vc/add-log.el
index 4d69aac454..983024327c 100644
--- a/lisp/vc/add-log.el
+++ b/lisp/vc/add-log.el
@@ -744,6 +744,7 @@ find-change-log
   file-name)
 
 (defun add-log-file-name (buffer-file log-file)
+  "Compute file-name of BUFFER-FILE as displayed in LOG-FILE."
   ;; Never want to add a change log entry for the ChangeLog file itself.
   (unless (or (null buffer-file) (string= buffer-file log-file))
     (if add-log-file-name-function
@@ -767,15 +768,49 @@ add-log-file-name
 	  (file-name-sans-versions buffer-file)
 	buffer-file))))
 
+(defcustom add-log-use-pseudo-changelog nil
+  "If non-nil, don't create ChangeLog files for log entries."
+  :type :boolean)
+
+(put 'add-log-use-pseudo-changelog 'safe-local-variable 'booleanp)
+
+(defun add-log--pseudo-changelog-buffer-name (changelog-file-name)
+  "Compute suitable name for a pseudo-ChangeLog buffer."
+  (format "*PseudoChangeLog for %s*"
+          (file-name-directory changelog-file-name)))
+
+(defun add-log--changelog-buffer-p (changelog-file-name buffer)
+  "Tell if BUFFER is a ChangeLog for CHANGELOG-FILE-NAME."
+  (with-current-buffer buffer
+    (if buffer-file-name
+        (equal buffer-file-name changelog-file-name)
+      (equal (add-log--pseudo-changelog-buffer-name changelog-file-name)
+             (buffer-name)))))
+
+(defun add-log-find-changelog-buffer (changelog-file-name)
+  "Find a ChangeLog buffer for CHANGELOG-FILE-NAME.
+Respect `add-log-use-pseudo-changelog', which see."
+  (if (or (file-exists-p changelog-file-name)
+          (not add-log-use-pseudo-changelog))
+      (find-file-noselect changelog-file-name)
+    (get-buffer-create
+     (add-log--pseudo-changelog-buffer-name changelog-file-name))))
+
 ;;;###autoload
-(defun add-change-log-entry (&optional whoami file-name other-window new-entry
+(defun add-change-log-entry (&optional whoami
+                                       changelog-file-name
+                                       other-window new-entry
 				       put-new-entry-on-new-line)
-  "Find change log file, and add an entry for today and an item for this file.
-Optional arg WHOAMI (interactive prefix) non-nil means prompt for user
-name and email (stored in `add-log-full-name' and `add-log-mailing-address').
+  "Find ChangeLog buffer, add an entry for today and an item for this file.
+Optional arg WHOAMI (interactive prefix) non-nil means prompt for
+user name and email (stored in `add-log-full-name' and
+`add-log-mailing-address').
 
-Second arg FILE-NAME is file name of the change log.
-If nil, use the value of `change-log-default-name'.
+Second arg CHANGELOG-FILE-NAME is file name of the change log.
+If nil, use the value of `change-log-default-name'.  If the file
+thus named exists, it's used for the new entry.  If it doesn't
+exist, it is created, unless `add-log-use-pseudo-changelog' in
+which case a suitably named file-less buffer is used.
 
 Third arg OTHER-WINDOW non-nil means visit in other window.
 
@@ -804,20 +839,28 @@ add-change-log-entry
 		       (change-log-version-number-search)))
 	 (buf-file-name (funcall add-log-buffer-file-name-function))
 	 (buffer-file (if buf-file-name (expand-file-name buf-file-name)))
-	 (file-name (expand-file-name (find-change-log file-name buffer-file)))
+	 (changelog-file-name (expand-file-name (find-change-log
+                                                 changelog-file-name
+                                                 buffer-file)))
 	 ;; Set ITEM to the file name to use in the new item.
-	 (item (add-log-file-name buffer-file file-name)))
+	 (item (add-log-file-name buffer-file changelog-file-name)))
 
-    (unless (equal file-name buffer-file-name)
+    ;; don't add entries from the ChangeLog file/buffer to itself.
+    (unless (equal changelog-file-name buffer-file-name)
       (cond
-       ((equal file-name (buffer-file-name (window-buffer)))
+       ((add-log--changelog-buffer-p
+         changelog-file-name
+         (window-buffer))
         ;; If the selected window already shows the desired buffer don't show
         ;; it again (particularly important if other-window is true).
         ;; This is important for diff-add-change-log-entries-other-window.
         (set-buffer (window-buffer)))
        ((or other-window (window-dedicated-p))
-        (find-file-other-window file-name))
-       (t (find-file file-name))))
+        (switch-to-buffer-other-window
+         (add-log-find-changelog-buffer changelog-file-name)))
+       (t
+        (switch-to-buffer
+         (add-log-find-changelog-buffer changelog-file-name)))))
     (or (derived-mode-p 'change-log-mode)
 	(change-log-mode))
     (undo-boundary)
diff --git a/lisp/vc/log-edit.el b/lisp/vc/log-edit.el
index 6ff782a606..f071d029a5 100644
--- a/lisp/vc/log-edit.el
+++ b/lisp/vc/log-edit.el
@@ -913,8 +913,10 @@ log-edit-changelog-entries
              (setq change-log-default-name nil)
              (find-change-log)))))
     (when (or (find-buffer-visiting changelog-file-name)
-              (file-exists-p changelog-file-name))
-      (with-current-buffer (find-file-noselect changelog-file-name)
+              (file-exists-p changelog-file-name)
+              add-log-use-pseudo-changelog)
+      (with-current-buffer
+          (add-log-find-changelog-buffer changelog-file-name)
         (unless (eq major-mode 'change-log-mode) (change-log-mode))
         (goto-char (point-min))
         (if (looking-at "\\s-*\n") (goto-char (match-end 0)))
-- 
2.17.1

Re: [PATCH] New option to make C-x 4 a use file-less ChangeLog buffers

[Basil L. Contovounesios]

Hi João, just a minor question:

João Távora <joaotavora@gmail.com> writes:

> From 867540c9310ee12ca477e744571d93f56f5f888d Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Jo=C3=A3o=20T=C3=A1vora?= <joaotavora@gmail.com>
> Date: Sat, 14 Jul 2018 18:29:48 +0100
> Subject: [PATCH] New option to make C-x 4 a use file-less ChangeLog buffers
>
> * lisp/vc/add-log.el (add-log-file-name): Update docstring.
> (add-log-use-pseudo-changelog): New defcustom.
> (add-log-find-changelog-buffer): New helper.
> (add-change-log-entry): Can work with ChangeLog file-less
> buffers.  Change name of argument FILE-NAME arg to be more
> explicit.  Explain new meaning of arg in docstring.
> (add-log--changelog-buffer-p): New helper.
>
> * lisp/vc/log-edit.el (log-edit-changelog-entries): Use
> add-log-use-pseudo-changelog and add-log-find-changelog-buffer.
> ---
>  lisp/vc/add-log.el  | 67 +++++++++++++++++++++++++++++++++++++--------
>  lisp/vc/log-edit.el |  6 ++--
>  2 files changed, 59 insertions(+), 14 deletions(-)
>
> diff --git a/lisp/vc/add-log.el b/lisp/vc/add-log.el
> index 4d69aac454..983024327c 100644
> --- a/lisp/vc/add-log.el
> +++ b/lisp/vc/add-log.el
> @@ -744,6 +744,7 @@ find-change-log
>    file-name)
>  
>  (defun add-log-file-name (buffer-file log-file)
> +  "Compute file-name of BUFFER-FILE as displayed in LOG-FILE."
>    ;; Never want to add a change log entry for the ChangeLog file itself.
>    (unless (or (null buffer-file) (string= buffer-file log-file))
>      (if add-log-file-name-function
> @@ -767,15 +768,49 @@ add-log-file-name
>  	  (file-name-sans-versions buffer-file)
>  	buffer-file))))
>  
> +(defcustom add-log-use-pseudo-changelog nil
> +  "If non-nil, don't create ChangeLog files for log entries."
> +  :type :boolean)
> +
> +(put 'add-log-use-pseudo-changelog 'safe-local-variable 'booleanp)

Any reason to prefer this over adding ":safe 'booleanp" directly to the
defcustom?

Thanks,

-- 
Basil

Re: [PATCH] New option to make C-x 4 a use file-less ChangeLog buffers

[João Távora]

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

On Sun, Jul 15, 2018, 06:33 Basil L. Contovounesios <contovob@tcd.ie> wrote:

> Hi João, just a minor question:
>
> > +(put 'add-log-use-pseudo-changelog 'safe-local-variable 'booleanp)
>
> Any reason to prefer this over adding ":safe 'booleanp" directly to the
> defcustom?
>

Hi Basil,

>
A number of very minor reasons:

I didn't know you could do that (thanks for telling me)
The name is less explicit as to the goal
The rest of the file uses the older form

But if you insist and noone objects, I can change it.

João

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

Re: [PATCH] New option to make C-x 4 a use file-less ChangeLog buffers

[Basil L. Contovounesios]

João Távora <joaotavora@gmail.com> writes:

> On Sun, Jul 15, 2018, 06:33 Basil L. Contovounesios <contovob@tcd.ie> wrote:
>
>> Hi João, just a minor question:
>>
>>> +(put 'add-log-use-pseudo-changelog 'safe-local-variable 'booleanp)
>>
>> Any reason to prefer this over adding ":safe 'booleanp" directly to the
>> defcustom?
>
> A number of very minor reasons:
>
> I didn't know you could do that (thanks for telling me)
> The name is less explicit as to the goal
> The rest of the file uses the older form
>
> But if you insist and noone objects, I can change it.

I couldn't insist on something evidently so trivial, was just wondering.

Thanks,

-- 
Basil

Re: [PATCH] New option to make C-x 4 a use file-less ChangeLog buffers (was Re: git history tracking across renames (and emacs support))

[Stefan Monnier]

> +(defcustom add-log-use-pseudo-changelog nil
> +  "If non-nil, don't create ChangeLog files for log entries."
> +  :type :boolean)
> +
> +(put 'add-log-use-pseudo-changelog 'safe-local-variable 'booleanp)

Regarding the use of `put` instead of `:safep`, the advantage of `put`
is that you can add an autoload cookie to it, which can be useful if the
var's safety might be tested before the package is loaded.

But to tell you the truth, I think the default should be t and those
very rare users who might need it to be nil will probably just be happy
to set it to nil globally once and for all, so I think the safety
specification is a case of overengineering.

> +(defun add-log--pseudo-changelog-buffer-name (changelog-file-name)
> +  "Compute suitable name for a pseudo-ChangeLog buffer."
> +  (format "*PseudoChangeLog for %s*"
> +          (file-name-directory changelog-file-name)))

I'd drop the "pseudo" part.
[ Ideally, it would interact with uniquify to show only the relevant part
  of the directory name.  I.e. you can use a name like "*ChangeLog*"
  and have it uniquified by setting

      (setq list-buffers-directory
            (expand-file-name "*ChangeLog*" default-directory))

  it's a bit tricky to get it to work, IIRC, but you can take a look at
  vc-dir-mode (in vc-dir.el) and cvs-get-buffer-create (in pcvs-util.el)
  for examples.  ]

> +(defun add-log--changelog-buffer-p (changelog-file-name buffer)
> +  "Tell if BUFFER is a ChangeLog for CHANGELOG-FILE-NAME."

Not clear: is CHANGELOG-FILE-NAME supposed to be the name of a ChangeLog
file?

I believe it is the case, but if so "BUFFER is a ChangeLog for" doesn't
sound quite right (it suggests that BUFFER holds the changelog that
describes changes applied to CHANGELOG-FILE-NAME).  Instead, you might
say something like "BUFFER is the buffer holding the contents of
CHANGELOG-FILE-NAME"?

> +      (equal (add-log--pseudo-changelog-buffer-name changelog-file-name)
> +             (buffer-name)))))

With uniquification, this test will have to be changed since the buffer-name
can change from "*ChangeLog*" to, say, "*ChangeLog*|emacs".


        Stefan

Re: [PATCH] New option to make C-x 4 a use file-less ChangeLog buffers (was Re: git history tracking across renames (and emacs support))

[João Távora]

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

>> +(defcustom add-log-use-pseudo-changelog nil
>> +  "If non-nil, don't create ChangeLog files for log entries."
>> +  :type :boolean)
>> +
>> +(put 'add-log-use-pseudo-changelog 'safe-local-variable 'booleanp)
>
> Regarding the use of `put` instead of `:safep`, the advantage of `put`
> is that you can add an autoload cookie to it, which can be useful if the
> var's safety might be tested before the package is loaded.
>
> But to tell you the truth, I think the default should be t and those
> very rare users who might need it to be nil will probably just be happy
> to set it to nil globally once and for all, so I think the safety
> specification is a case of overengineering.

OK.  If noone strongly objects to setting this t, I will do so in the
next iteration.  I think it should be safe for people like Eli who
have/like a local .gitignored ChangeLog file, because in that case the
existing file will be used.

IOW, only if the option is t and there is no such file is a fileless
ChangeLog created.

>> +(defun add-log--pseudo-changelog-buffer-name (changelog-file-name)
>> +  "Compute suitable name for a pseudo-ChangeLog buffer."
>> +  (format "*PseudoChangeLog for %s*"
>> +          (file-name-directory changelog-file-name)))
>
> I'd drop the "pseudo" part.

Yeah, it's clunky.  I added it for clarity during the implementation,
but it's not needed.

> [ Ideally, it would interact with uniquify to show only the relevant part
>   of the directory name.  I.e. you can use a name like "*ChangeLog*"
>   and have it uniquified by setting
>
>       (setq list-buffers-directory
>             (expand-file-name "*ChangeLog*" default-directory))
>
>   it's a bit tricky to get it to work, IIRC, but you can take a look at
>   vc-dir-mode (in vc-dir.el) and cvs-get-buffer-create (in pcvs-util.el)
>   for examples.  ]

To tell you the truth, I was hoping to *avoid* uniquify here.  IMO, it
is designed for those cases where the file creator could reasonably be
convinced that his/her file would be unique (probably within a
dir/project).  This is not one of these cases, since Emacs is generally
useful for working more than one project at the same time.  In practice,
I find the "|<uniqueness>" much harder to read, and I prefer to save it
for when it can't be avoided.

This would also avoid the added complexity that you foresee.

>> +(defun add-log--changelog-buffer-p (changelog-file-name buffer)
>> +  "Tell if BUFFER is a ChangeLog for CHANGELOG-FILE-NAME."
>
> Not clear: is CHANGELOG-FILE-NAME supposed to be the name of a ChangeLog
> file?
>
> I believe it is the case, but if so "BUFFER is a ChangeLog for" doesn't
> sound quite right (it suggests that BUFFER holds the changelog that
> describes changes applied to CHANGELOG-FILE-NAME).  Instead, you might
> say something like "BUFFER is the buffer holding the contents of
> CHANGELOG-FILE-NAME"?

Right, that is clearer.  But will it fit in the miniscule column limit? 

>> +      (equal (add-log--pseudo-changelog-buffer-name changelog-file-name)
>> +             (buffer-name)))))
>
> With uniquification, this test will have to be changed since the buffer-name
> can change from "*ChangeLog*" to, say, "*ChangeLog*|emacs".

As I said, I was hoping to avoid this.  "*ChangeLog for
<full-project-path>*" seems acceptable to me, but we could shorten it to
$HOME or sth (how?).

João

Re: [PATCH] New option to make C-x 4 a use file-less ChangeLog buffers (was Re: git history tracking across renames (and emacs support))

[Stefan Monnier]

> To tell you the truth, I was hoping to *avoid* uniquify here.  IMO, it
> is designed for those cases where the file creator could reasonably be
> convinced that his/her file would be unique (probably within a
> dir/project).  This is not one of these cases, since Emacs is generally
> useful for working more than one project at the same time.

I don't follow.  `uniquify` is designed specifically for those cases
where the same file name can occur in multiple projects and lets you see
"foo|bar" and "foo|baz" instead of "foo" and "foo<1>".

> In practice, I find the "|<uniqueness>" much harder to read,

Harder then what?  In any case, you should be able to get pretty much
the same as what your patch currently does by setting
uniquify-buffer-name-style and uniquify-min-dir-content appropriately.

> This would also avoid the added complexity that you foresee.

Yes, but it's not as nice for the user.

> Right, that is clearer.  But will it fit in the miniscule column limit? 

We can split it into two sentences if needed ;-)

> As I said, I was hoping to avoid this.  "*ChangeLog for
> <full-project-path>*" seems acceptable to me, but we could shorten it to
> $HOME or sth (how?).

[ We call those things "filenames" rather than "path" in the GNU project.  ]

These are awfully long, with a lot of redundancy in the middle, making
it harder to find the relevant information.

This part will be easy to fix if you `setq` a buffer-local variable in the
buffer, e.g.:

    (defun add-log--changelog-buffer-p (file-name buffer)
      (equal file-name (or buffer-file-name add-log--buffer-file-name)))


-- Stefan

Re: [PATCH] New option to make C-x 4 a use file-less ChangeLog buffers (was Re: git history tracking across renames (and emacs support))

[João Távora]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> To tell you the truth, I was hoping to *avoid* uniquify here.  IMO, it
> I don't follow.  `uniquify` is designed specifically for those cases
> where the same file name can occur in multiple projects and lets you see
> "foo|bar" and "foo|baz" instead of "foo" and "foo<1>".

Evidently, having opened two Makefile's more than once in my life, I
know that.  However:

* This isn't a file, it's a file-less buffer.  I haven't seen uniquify
  ever used for those, so it would probably confuse users into thinking
  there's a funnily named file after all;

* Uniquify is designed to have a very shortest possible distinguishing
  string because the file's name is foremost in importance.  It's quite
  different here. The file's name doesn't exist.  The buffer's name does
  exist, but is quite irrelevant.  The path to the directory, on the
  contrary, isn't.  And I want that bit to show even if I have only one
  *ChangeLog* buffer.

>> In practice, I find the "|<uniqueness>" much harder to read,
> Harder then what?

Harder than reading a short, plain-english phrase using the "for"
preposition: "*ChangeLog for project-path*".

> In any case, you should be able to get pretty much the same as what
> your patch currently does by setting uniquify-buffer-name-style and
> uniquify-min-dir-content appropriately.
>> This would also avoid the added complexity that you foresee.

Can I make add-log.el set this buffer-locally by default in the
*ChangeLog* buffer, so that the suffix always appears even if I have
only one?  Can I make it so that the suffix is inside the *EarMuffs*?

> Yes, but it's not as nice for the user.

The problem is that I don't understand the niceness being advocated
here?  And zero niceness versus non-zero complexity always loses.

>> Right, that is clearer.  But will it fit in the miniscule column limit? 
>
> We can split it into two sentences if needed ;-)

Rephrase away!

>> As I said, I was hoping to avoid this.  "*ChangeLog for
>> <full-project-path>*" seems acceptable to me, but we could shorten it to
> [ We call those things "filenames" rather than "path" in the GNU
> project.  ]

In code and doc, yes.  In this list, I think everybody gets me.

> These are awfully long, with a lot of redundancy in the middle, making
> it harder to find the relevant information.

Really, I don't think it's redundant: it's the only thing semantically
(and formally) tying that buffer to the directory whose (vc-)project
it's representing.

If there's a part of it that is so common as to be distracting, we
should use `abbreviate-file-name' (which you can probably customize to
abbreviate extremely using directory-abbrev-alist).

João

Re: [PATCH] New option to make C-x 4 a use file-less ChangeLog buffers (was Re: git history tracking across renames (and emacs support))

[Stefan Monnier]

> * This isn't a file, it's a file-less buffer.  I haven't seen uniquify
>   ever used for those,

That's because you don't use vc-dir and haven't use PCL-CVS before that.

[ IIUC it can only be made to work for *shell* buffers, but I don't use
  them enough to know for sure, and it doesn't work that way out of the
  box anyway, from what I know.  ]

>   so it would probably confuse users into thinking
>   there's a funnily named file after all;

I haven't seen any sign of users being confused by it back in the
PCL-CVS days, nor now with vc-dir.

> * Uniquify is designed to have a very shortest possible distinguishing
>   string because the file's name is foremost in importance.  It's quite
>   different here. The file's name doesn't exist.  The buffer's name does
>   exist, but is quite irrelevant.  The path to the directory, on the
>   contrary, isn't.  And I want that bit to show even if I have only one
>   *ChangeLog* buffer.

We're just replacing "ChangeLog" files with "*ChangeLog*" buffers.

Currently, if you have a single ChangeLog file opened, it just says
"ChangeLog", so I don't see a strong reason to impose that the sole
"*ChangeLog*" buffer you have opened states in its buffer name which
directory it's associated to.

>>> In practice, I find the "|<uniqueness>" much harder to read,
>> Harder then what?
> Harder than reading a short, plain-english phrase using the "for"
> preposition: "*ChangeLog for project-path*".

Maybe you'd like

    (setq uniquify-separator " for ")

better?

> Can I make add-log.el set this buffer-locally by default in the
> *ChangeLog* buffer, so that the suffix always appears even if I have
> only one?

I don't think so, no.  But as a user I'd personally not want that "at
least 1 dir element" behavior.

> Can I make it so that the suffix is inside the *EarMuffs*?

No.

>> Yes, but it's not as nice for the user.
> The problem is that I don't understand the niceness being advocated
> here?  And zero niceness versus non-zero complexity always loses.

You don't have to it, indeed.  It's just a suggestion.

I'll probably sooner or later apply such a patch either into `master` or
into my own local branch because I find such long buffer
names insuperable.

>> These are awfully long, with a lot of redundancy in the middle, making
>> it harder to find the relevant information.
> Really, I don't think it's redundant: it's the only thing semantically
> (and formally) tying that buffer to the directory whose (vc-)project
> it's representing.

Formally, clearly not: default-directory and list-buffers-directory tye
that buffer to the directory (and you can add the new
`add-log--buffer-file-name` to those two).

The file names introduced by `C-x 4 a` more informally do as well.

> If there's a part of it that is so common as to be distracting, we
> should use `abbreviate-file-name' (which you can probably customize to
> abbreviate extremely using directory-abbrev-alist).

abbreviate-file-name is supposed to return a valid file name.
And it can't abbreviate in a context-sensitive manner (e.g. if I have
two ChangeLog buffers opened, one for .../src/emacs/master and another
for .../src/typer/master, it can't shorten things to "ChangeLog | emacs"
and "ChangeLog | typer" like uniquify does).


        Stefan

Re: [PATCH] New option to make C-x 4 a use file-less ChangeLog buffers (was Re: git history tracking across renames (and emacs support))

[João Távora]

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

>> * This isn't a file, it's a file-less buffer.  I haven't seen uniquify
>>   ever used for those,
>
> That's because you don't use vc-dir and haven't use PCL-CVS before that.
>
> [ IIUC it can only be made to work for *shell* buffers, but I don't use
>   them enough to know for sure, and it doesn't work that way out of the
>   box anyway, from what I know.  ]
>
>>   so it would probably confuse users into thinking
>>   there's a funnily named file after all;
>
> I haven't seen any sign of users being confused by it back in the
> PCL-CVS days, nor now with vc-dir.

Probabaly because vc-dir wasn't ever a notable file-name.

>
>> * Uniquify is designed to have a very shortest possible distinguishing
>>   string because the file's name is foremost in importance.  It's quite
>>   different here. The file's name doesn't exist.  The buffer's name does
>>   exist, but is quite irrelevant.  The path to the directory, on the
>>   contrary, isn't.  And I want that bit to show even if I have only one
>>   *ChangeLog* buffer.
>p
> We're just replacing "ChangeLog" files with "*ChangeLog*" buffers.

Yes. 

>
> Currently, if you have a single ChangeLog file opened, it just says
> "ChangeLog", so I don't see a strong reason to impose that the sole
> "*ChangeLog*" buffer you have opened states in its buffer name which
> directory it's associated to.

I don't see what's wrong in being able seeing in the buffer name, at a
glance, what the buffer is for.  This was actually in the original
suggestion by Eli, and I think it's a good idea.

And it goes for *vc-dir* too, where arguably it's a little silly: its a
"dir" but what dir?  I have to go in the buffer and read down the second
line to know.

If anything I'd go all out on (a modified version of) uniquify: use it
for *grep*, *Find*, *Occur* and the like, so I can distinguish by
reading from the buffer list what these buffers apply to.  I'd start
with an option to make uniquify always show the suffix.

> Maybe you'd like
>
>     (setq uniquify-separator " for ")
>
> better?

I probably would, a little. But it didn't do anything (for vc dir at
least).

>> Can I make add-log.el set this buffer-locally by default in the
>> *ChangeLog* buffer, so that the suffix always appears even if I have
>> only one?
>
> I don't think so, no.  But as a user I'd personally not want that "at
> least 1 dir element" behavior.

OK, let's make this optional.

> You don't have to it, indeed.  It's just a suggestion.  I'll probably
> sooner or later apply such a patch either into `master` or into my own
> local branch

Well if you say you're going to turn the suggestion into a commit sooner
or later, we might as well coordinate first :-)

> I find such long buffer names insuperable.

I don't see why.  Don't you use gnus?  This buffer's name reads "*unsent
wide reply to Stefan Monnier*".  Using ido, i can just C-x b stefan and
see every file I have on you (kidding, I only have one right now).  I
wouldn't like to see "*unsent wide reply*".

If you want your mode-line to diet, we could cut down on the
major-mode's name, which uselessly parrots "ChangeLog", or make slightly
smaller as "*changes to <project>*".

Or I'll cut you a simpler deal: let's first do this very simple change
and then do the single ChangeLog file/buffer that you proposed earlier,
that way you won't be bothered by long buffer names.

>>> These are awfully long, with a lot of redundancy in the middle, making
>>> it harder to find the relevant information.
>> Really, I don't think it's redundant: it's the only thing semantically
>> (and formally) tying that buffer to the directory whose (vc-)project
>> it's representing.
>
> Formally, clearly not: default-directory and list-buffers-directory tye

Indirectly yes, but by that reasoning so does the mark ring, or
view-lossage, or the user's memory.

> abbreviate-file-name is supposed to return a valid file name.  And it
> can't abbreviate in a context-sensitive manner (e.g. if I have two
> ChangeLog buffers opened, one for .../src/emacs/master and another for
> .../src/typer/master, it can't shorten things to "ChangeLog | emacs"
> and "ChangeLog | typer" like uniquify does).

Maybe uniquify could provide that bit of functionality as an utility
function that other modes can use irrespective of "requiring"
uniquification.

If it did, would you be happy with "*changes for emacs*", "*changes for
typer*" and the like?

João

Re: [PATCH] New option to make C-x 4 a use file-less ChangeLog buffers (was Re: git history tracking across renames (and emacs support))

[Stefan Monnier]

> I don't see what's wrong in being able seeing in the buffer name, at a
> glance, what the buffer is for.

It's a tradeoff w.r.t buffer name length.
Part of the benefit of uniquify is that it lets the user choose which
side of the tradeoff he wants to favor.

> And it goes for *vc-dir* too, where arguably it's a little silly: its a
> "dir" but what dir?

We've had the same for ChangeLog buffers for years (and README buffers,
and `src` dired buffers, and ...).

> If anything I'd go all out on (a modified version of) uniquify: use it
> for *grep*, *Find*, *Occur* and the like, so I can distinguish by
> reading from the buffer list what these buffers apply to.

I could go along with that (and indeed the *cvs-commit* buffer in
PCL-CVS (in which to write the commit message) followed this idea).
The other tradeoff at play here (beside the buffer name) is reuse of
existing buffers.

> I'd start with an option to make uniquify always show the suffix.

It's called uniquify-min-dir-content.

>> Maybe you'd like
>>     (setq uniquify-separator " for ")
>> better?
> I probably would, a little. But it didn't do anything (for vc dir at
> least).

Hmm... apparently it only kicks for some of the style options.  Try:

    (setq uniquify-separator " for ")
    (setq uniquify-buffer-name-style 'post-forward)

>> I find such long buffer names insuperable.
> I don't see why.

To each his own.

> Don't you use gnus?  This buffer's name reads "*unsent
> wide reply to Stefan Monnier*".

I hate those (and there's no uniquify to save me there).
Luckily I rarely need to look at those buffers's modeline.

> Using ido, i can just C-x b stefan and see every file I have on you
> (kidding, I only have one right now).  I wouldn't like to see "*unsent
> wide reply*".

I'd be quite happy with "*mail*".

> Or I'll cut you a simpler deal: let's first do this very simple change

In any case, let's leave this uniquify beside on the side, because
I don't want it to hold us back.

> and then do the single ChangeLog file/buffer that you proposed earlier,
> that way you won't be bothered by long buffer names.

The way I imagine it, this "single file" is completely internal: the
user would never view/edit it directly.

>> abbreviate-file-name is supposed to return a valid file name.  And it
>> can't abbreviate in a context-sensitive manner (e.g. if I have two
>> ChangeLog buffers opened, one for .../src/emacs/master and another for
>> .../src/typer/master, it can't shorten things to "ChangeLog | emacs"
>> and "ChangeLog | typer" like uniquify does).
>
> Maybe uniquify could provide that bit of functionality as an utility
> function that other modes can use irrespective of "requiring"
> uniquification.
>
> If it did, would you be happy with "*changes for emacs*", "*changes for
> typer*" and the like?

It needs to be dynamic: what if I later open some "changes" for
.../src/emacs/work?


        Stefan

Re: [PATCH] New option to make C-x 4 a use file-less ChangeLog buffers (was Re: git history tracking across renames (and emacs support))

[João Távora]

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

>> And it goes for *vc-dir* too, where arguably it's a little silly: its a
>> "dir" but what dir?
> We've had the same for ChangeLog buffers for years (and README buffers,
> and `src` dired buffers, and ...).

Those are files.  I'm just proposing that we use the advantage of
file-less buffers, which is non-persistently naming them after a
specific location or context

You can't do with a with a file name, and, on a tangent, I think this is
what many people like the "project drawer" for: to know whence a file
comes by looking at their screen.

> PCL-CVS (in which to write the commit message) followed this idea).
> The other tradeoff at play here (beside the buffer name) is reuse of
> existing buffers.
>> I'd start with an option to make uniquify always show the suffix.
> It's called uniquify-min-dir-content.

Oh so it does exist.  Can it be set buffer-locally?

>> Don't you use gnus?  This buffer's name reads "*unsent
>> wide reply to Stefan Monnier*".
> I hate those (and there's no uniquify to save me there).
> Luckily I rarely need to look at those buffers's modeline.

But don't you find it useful in a buffer list (C-x b, C-x C-b, etc) to
know _whom_ that *mail* is for? Or what project that *vc-dir* is
editing?

>> Or I'll cut you a simpler deal: let's first do this very simple change
> In any case, let's leave this uniquify beside on the side, because
> I don't want it to hold us back.

OK, good idea: then I'll update the patch to be

  (defun add-log--pseudo-changelog-buffer-name (changelog-file-name)
  "Compute suitable name for a pseudo-ChangeLog buffer."
  (format "*changes to %s*"
          (abbreviate-file-name
           (file-name-directory changelog-file-name))))

and wait for Eli's comments.

Then we can plug uniquify in there somehow later.  I'll be happy just to
rid myself of ChangeLog files tbh...

>> and then do the single ChangeLog file/buffer that you proposed earlier,
>> that way you won't be bothered by long buffer names.
> The way I imagine it, this "single file" is completely internal: the
> user would never view/edit it directly.

Even better, then!

>> If it did, would you be happy with "*changes for emacs*", "*changes for
>> typer*" and the like?
> It needs to be dynamic: what if I later open some "changes" for
> .../src/emacs/work?

Did you mean a file named *changes*? If you did, it's like opening some
"*grep*" file today (I've just checked: it's uniquified, correctly).  If
you didn't I don't understand the problem.  To be clear, I was talking
about always having a (potentially short) suffix.

               João (who would like it known that he used "whom" and
                    "whence" having no idea if he botched it)

Re: [PATCH] New option to make C-x 4 a use file-less ChangeLog buffers (was Re: git history tracking across renames (and emacs support))

[Stefan Monnier]

> You can't do with a with a file name,

What makes you think we can't.  It's rather the contrary: buffer names
for file buffers can be chosen much more freely compared to most
non-file buffers (where the main identifying mark is the buffer name).

> and, on a tangent, I think this is what many people like the "project
> drawer" for: to know whence a file comes by looking at their screen.

I don't know what's the "project drawer", so I'll take your word for it ;-)

>> It's called uniquify-min-dir-content.
> Oh so it does exist.  Can it be set buffer-locally?

Hmm... I think I answered this one earlier this morning, but no
I believe it only works as a global setting (more specifically, looking
at the code, it seems like it could support it, but trying it out, it
seems that buffer-local settings lead trigger a bug somewhere).

> But don't you find it useful in a buffer list (C-x b, C-x C-b, etc) to
> know _whom_ that *mail* is for? Or what project that *vc-dir* is
> editing?

No.  If there's more than one, then the buffer-name would tell me, and
if there's only one, I normally remember what it was about.

>>> If it did, would you be happy with "*changes for emacs*", "*changes for
>>> typer*" and the like?
>> It needs to be dynamic: what if I later open some "changes" for
>> .../src/emacs/work?
> Did you mean a file named *changes*?

No, I meant just another one of those buffers.

> If you did, it's like opening some
> "*grep*" file today (I've just checked: it's uniquified, correctly).  If
> you didn't I don't understand the problem.  To be clear, I was talking
> about always having a (potentially short) suffix.

Currently:
- I open ..../src/emacs/work/README I get "README"
- I open ..../src/typer/work/README I get "README | typer" and the
  previous "README" gets renamed to "README | emacs"
- I open ..../src/emacs/master/README, I get "README | emacs/master"
  and the previous 2 get renamed to "README | emacs/work" and
  "README | typer/work".
- If I kill two of those buffers, the remaining one reverts to just "README"

IMO, the same dynamic (re)naming should hold for "*changes to <foo>".

>                João (who would like it known that he used "whom" and
>                     "whence" having no idea if he botched it)

Duly noted.  I can't guarantee that it was used properly, but at least
my english-as-a-third-language-trained-brain did not find it jarring.


        Stefan

Re: [PATCH] New option to make C-x 4 a use file-less ChangeLog buffers (was Re: git history tracking across renames (and emacs support))

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Mon, 16 Jul 2018 11:10:01 +0100
> Cc: emacs-devel@gnu.org
> 
> > But to tell you the truth, I think the default should be t and those
> > very rare users who might need it to be nil will probably just be happy
> > to set it to nil globally once and for all, so I think the safety
> > specification is a case of overengineering.
> 
> OK.  If noone strongly objects to setting this t, I will do so in the
> next iteration.  I think it should be safe for people like Eli who
> have/like a local .gitignored ChangeLog file, because in that case the
> existing file will be used.
> 
> IOW, only if the option is t and there is no such file is a fileless
> ChangeLog created.

This should be called out in NEWS, including the way to get the
previous behavior, but as long as the behavior is not too
backward-incompatible, I don't think I'd mind.

Re: [PATCH] New option to make C-x 4 a use file-less ChangeLog buffers (was Re: git history tracking across renames (and emacs support))

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Cc: larsi@gnus.org,  tzz@lifelogs.com,  emacs-devel@gnu.org,  cpitclaudel@gmail.com
> Date: Sat, 14 Jul 2018 18:36:57 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > [...] perhaps add-log.el could be extended to be able to use a buffer
> > name, not just a file name, for where to put the log messages.  It
> > already allows you to customize the file name; it could do something
> > similar with a buffer name, and that buffer could have no file name.
> > Then a large part of your problems would go away, AFAIU.
> 
> Hi Eli,
> 
> Find attached a patch that does exactly this.  It is only lightly
> tested, so I need a clinical eye that I didn't break anything.
> Fortunately, it is quite short.  Appropriately, I used it to compose the
> commit message (and I don't have any ChangeLog files lying around).
> 
> If this is accepted, I can submit more patches for more related
> functionality.  The next two I imagine, in this order, are:
> 
> * C-c C-c (commit-time in vc-log) somehow disables the entries collected
>   by C-c C-a in the ChangeLog buffer.
> 
> * Use a single ChangeLog buffer indexed by projects (Stefan's idea)

Thanks.  I didn't forget about this and didn't lose it.  I'm just a
bit busy these days, and may need a couple more days before I get to
reviewing this.  I'm saving Stefan's comments and your responses for
that time.

Stay tuned.

Re: [PATCH] New option to make C-x 4 a use file-less ChangeLog buffers (was Re: git history tracking across renames (and emacs support))

[João Távora]

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

Eli Zaretskii <eliz@gnu.org> writes:

>> From: João Távora <joaotavora@gmail.com>
>> Cc: larsi@gnus.org,  tzz@lifelogs.com,  emacs-devel@gnu.org,  cpitclaudel@gmail.com
>> Date: Sat, 14 Jul 2018 18:36:57 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > [...] perhaps add-log.el could be extended to be able to use a buffer
>> > name, not just a file name, for where to put the log messages.  It
>> > already allows you to customize the file name; it could do something
>> > similar with a buffer name, and that buffer could have no file name.
>> > Then a large part of your problems would go away, AFAIU.
>> 
>> Hi Eli,
>> 
>> Find attached a patch that does exactly this.  It is only lightly
>> tested, so I need a clinical eye that I didn't break anything.
>> Fortunately, it is quite short.  Appropriately, I used it to compose the
>> commit message (and I don't have any ChangeLog files lying around).
>> 
>> If this is accepted, I can submit more patches for more related
>> functionality.  The next two I imagine, in this order, are:
>> 
>> * C-c C-c (commit-time in vc-log) somehow disables the entries collected
>>   by C-c C-a in the ChangeLog buffer.
>> 
>> * Use a single ChangeLog buffer indexed by projects (Stefan's idea)
>
> Thanks.  I didn't forget about this and didn't lose it.  I'm just a
> bit busy these days, and may need a couple more days before I get to
> reviewing this.  I'm saving Stefan's comments and your responses for
> that time.
>
> Stay tuned.

No worries.  When you do get around to it, have a look at the patch I
attach to this mail instead, because it integrates a few of Stefan's
suggestions (the part we don't yet agree is how, if at all, to add
uniquify.el into the equation...).

João


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-New-option-to-make-C-x-4-a-use-file-less-ChangeLog-b.patch --]
[-- Type: text/x-diff, Size: 6513 bytes --]

From 2287a08e58cb2fc3ee82dbf3861e7c8d9d1c9b74 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jo=C3=A3o=20T=C3=A1vora?= <joaotavora@gmail.com>
Date: Sat, 14 Jul 2018 18:29:48 +0100
Subject: [PATCH] New option to make C-x 4 a use file-less ChangeLog buffers

* lisp/vc/add-log.el (add-log-file-name): Update docstring.
(add-log-use-pseudo-changelog): New defcustom.
(add-log-find-changelog-buffer): New helper.
(add-change-log-entry): Can work with ChangeLog file-less
buffers.  Change name of argument FILE-NAME arg to be more
explicit.  Explain new meaning of arg in docstring.
(add-log--changelog-buffer-p): New helper.

* lisp/vc/log-edit.el (log-edit-changelog-entries): Use
add-log-use-pseudo-changelog and add-log-find-changelog-buffer.
---
 lisp/vc/add-log.el  | 71 ++++++++++++++++++++++++++++++++++++---------
 lisp/vc/log-edit.el |  6 ++--
 2 files changed, 62 insertions(+), 15 deletions(-)

diff --git a/lisp/vc/add-log.el b/lisp/vc/add-log.el
index 4d69aac454..d8517d6196 100644
--- a/lisp/vc/add-log.el
+++ b/lisp/vc/add-log.el
@@ -744,6 +744,7 @@ find-change-log
   file-name)
 
 (defun add-log-file-name (buffer-file log-file)
+  "Compute file-name of BUFFER-FILE as displayed in LOG-FILE."
   ;; Never want to add a change log entry for the ChangeLog file itself.
   (unless (or (null buffer-file) (string= buffer-file log-file))
     (if add-log-file-name-function
@@ -767,15 +768,51 @@ add-log-file-name
 	  (file-name-sans-versions buffer-file)
 	buffer-file))))
 
+(defcustom add-log-use-pseudo-changelog t
+  "If non-nil, don't create ChangeLog files for log entries."
+  :type :boolean)
+
+(put 'add-log-use-pseudo-changelog 'safe-local-variable 'booleanp)
+
+(defun add-log--pseudo-changelog-buffer-name (changelog-file-name)
+  "Compute suitable name for a pseudo-ChangeLog buffer."
+  (format "*changes to %s*"
+          (abbreviate-file-name
+           (file-name-directory changelog-file-name))))
+
+(defun add-log--changelog-buffer-p (changelog-file-name buffer)
+  "Tell if BUFFER holds a ChangeLog for CHANGELOG-FILE-NAME."
+  (with-current-buffer buffer
+    (if buffer-file-name
+        (equal buffer-file-name changelog-file-name)
+      (equal (add-log--pseudo-changelog-buffer-name changelog-file-name)
+             (buffer-name)))))
+
+(defun add-log-find-changelog-buffer (changelog-file-name)
+  "Find a ChangeLog buffer for CHANGELOG-FILE-NAME.
+Respect `add-log-use-pseudo-changelog', which see."
+  (if (or (file-exists-p changelog-file-name)
+          (not add-log-use-pseudo-changelog))
+      (find-file-noselect changelog-file-name)
+    (get-buffer-create
+     (add-log--pseudo-changelog-buffer-name changelog-file-name))))
+
 ;;;###autoload
-(defun add-change-log-entry (&optional whoami file-name other-window new-entry
+(defun add-change-log-entry (&optional whoami
+                                       changelog-file-name
+                                       other-window new-entry
 				       put-new-entry-on-new-line)
-  "Find change log file, and add an entry for today and an item for this file.
-Optional arg WHOAMI (interactive prefix) non-nil means prompt for user
-name and email (stored in `add-log-full-name' and `add-log-mailing-address').
-
-Second arg FILE-NAME is file name of the change log.
-If nil, use the value of `change-log-default-name'.
+  "Find ChangeLog buffer, add an entry for today and an item for this file.
+Optional arg WHOAMI (interactive prefix) non-nil means prompt for
+user name and email (stored in `add-log-full-name' and
+`add-log-mailing-address').
+
+Second arg CHANGELOG-FILE-NAME is file name of the change log.
+If nil, use the value of `change-log-default-name'.  If the file
+thus named exists, it's used for the new entry.  If it doesn't
+exist, it is created, unless `add-log-use-pseudo-changelog' is t,
+in which case a suitably named file-less buffer is used for
+keeping entries pertaining to CHANGELOG-FILE-NAME's directory.
 
 Third arg OTHER-WINDOW non-nil means visit in other window.
 
@@ -804,20 +841,28 @@ add-change-log-entry
 		       (change-log-version-number-search)))
 	 (buf-file-name (funcall add-log-buffer-file-name-function))
 	 (buffer-file (if buf-file-name (expand-file-name buf-file-name)))
-	 (file-name (expand-file-name (find-change-log file-name buffer-file)))
+	 (changelog-file-name (expand-file-name (find-change-log
+                                                 changelog-file-name
+                                                 buffer-file)))
 	 ;; Set ITEM to the file name to use in the new item.
-	 (item (add-log-file-name buffer-file file-name)))
+	 (item (add-log-file-name buffer-file changelog-file-name)))
 
-    (unless (equal file-name buffer-file-name)
+    ;; don't add entries from the ChangeLog file/buffer to itself.
+    (unless (equal changelog-file-name buffer-file-name)
       (cond
-       ((equal file-name (buffer-file-name (window-buffer)))
+       ((add-log--changelog-buffer-p
+         changelog-file-name
+         (window-buffer))
         ;; If the selected window already shows the desired buffer don't show
         ;; it again (particularly important if other-window is true).
         ;; This is important for diff-add-change-log-entries-other-window.
         (set-buffer (window-buffer)))
        ((or other-window (window-dedicated-p))
-        (find-file-other-window file-name))
-       (t (find-file file-name))))
+        (switch-to-buffer-other-window
+         (add-log-find-changelog-buffer changelog-file-name)))
+       (t
+        (switch-to-buffer
+         (add-log-find-changelog-buffer changelog-file-name)))))
     (or (derived-mode-p 'change-log-mode)
 	(change-log-mode))
     (undo-boundary)
diff --git a/lisp/vc/log-edit.el b/lisp/vc/log-edit.el
index 6ff782a606..f071d029a5 100644
--- a/lisp/vc/log-edit.el
+++ b/lisp/vc/log-edit.el
@@ -913,8 +913,10 @@ log-edit-changelog-entries
              (setq change-log-default-name nil)
              (find-change-log)))))
     (when (or (find-buffer-visiting changelog-file-name)
-              (file-exists-p changelog-file-name))
-      (with-current-buffer (find-file-noselect changelog-file-name)
+              (file-exists-p changelog-file-name)
+              add-log-use-pseudo-changelog)
+      (with-current-buffer
+          (add-log-find-changelog-buffer changelog-file-name)
         (unless (eq major-mode 'change-log-mode) (change-log-mode))
         (goto-char (point-min))
         (if (looking-at "\\s-*\n") (goto-char (match-end 0)))
-- 
2.17.1

Re: [PATCH] New option to make C-x 4 a use file-less ChangeLog buffers (was Re: git history tracking across renames (and emacs support))

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Cc: monnier@iro.umontreal.ca,  larsi@gnus.org,  tzz@lifelogs.com,  emacs-devel@gnu.org,  cpitclaudel@gmail.com
> Date: Tue, 17 Jul 2018 00:02:47 +0100
> 
> > Thanks.  I didn't forget about this and didn't lose it.  I'm just a
> > bit busy these days, and may need a couple more days before I get to
> > reviewing this.  I'm saving Stefan's comments and your responses for
> > that time.
> >
> > Stay tuned.
> 
> No worries.  When you do get around to it, have a look at the patch I
> attach to this mail instead, because it integrates a few of Stefan's
> suggestions (the part we don't yet agree is how, if at all, to add
> uniquify.el into the equation...).

Looks reasonable, thanks.

> +(defcustom add-log-use-pseudo-changelog t
> +  "If non-nil, don't create ChangeLog files for log entries."
> +  :type :boolean)

I frequently find that what we say in the doc string is a very good
hint on how to name the variable.  So how about
add-log-don't-create-change-log-file instead?

Also, this needs a :version tag.

> +(defun add-log--pseudo-changelog-buffer-name (changelog-file-name)
> +  "Compute suitable name for a pseudo-ChangeLog buffer."
> +  (format "*changes to %s*"
> +          (abbreviate-file-name
> +           (file-name-directory changelog-file-name))))

Would the name of the buffer be something like "*changes to ChangeLog*"?
That's awkward, IMO.  How about just "*ChangeLog*" instead?

The above are minor nits, so what else is left that needs to be agreed
upon?

Thanks.

Re: [PATCH] New option to make C-x 4 a use file-less ChangeLog buffers (was Re: git history tracking across renames (and emacs support))

[João Távora]

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

On Sat, Jul 21, 2018, 11:43 Eli Zaretskii <eliz@gnu.org> wrote:

>
> Looks reasonable, thanks.
>
> > +(defcustom add-log-use-pseudo-changelog t
> > +  "If non-nil, don't create ChangeLog files for log entries."
> > +  :type :boolean)
>
> I frequently find that what we say in the doc string is a very good
> hint on how to name the variable.  So how about
> add-log-don't-create-change-log-file instead?
>

Fine by me.  But even with the apostrophe?

>
> Also, this needs a :version tag.
>

Right. 27.1?


> > +(defun add-log--pseudo-changelog-buffer-name (changelog-file-name)
> > +  "Compute suitable name for a pseudo-ChangeLog buffer."
> > +  (format "*changes to %s*"
> > +          (abbreviate-file-name
> > +           (file-name-directory changelog-file-name))))
>
> Would the name of the buffer be something like "*changes to ChangeLog*"?
> That's awkward, IMO.  How about just "*ChangeLog*" instead?
>

Yeah, that would be pretty awkward, hehe, but it's not what happens,
because of the file-name-directory call.

>
> The above are minor nits, so what else is left that needs to be agreed
> upon?
>

Nothing, afaik.  Stefan had said he would probably enhance this later with
uniquify support.

I'll do the NEWS, should the manual also mention it?

João

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

Re: [PATCH] New option to make C-x 4 a use file-less ChangeLog buffers (was Re: git history tracking across renames (and emacs support))

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Sat, 21 Jul 2018 14:02:04 +0100
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, Lars Ingebrigtsen <larsi@gnus.org>, tzz@lifelogs.com, 
> 	emacs-devel@gnu.org, cpitclaudel@gmail.com
> 
>  > +(defcustom add-log-use-pseudo-changelog t
>  > +  "If non-nil, don't create ChangeLog files for log entries."
>  > +  :type :boolean)
> 
>  I frequently find that what we say in the doc string is a very good
>  hint on how to name the variable.  So how about
>  add-log-don't-create-change-log-file instead?
> 
> Fine by me.  But even with the apostrophe?

No, that slipped through without my meaning it.

>  Also, this needs a :version tag.
> 
> Right. 27.1?

Yes.

> I'll do the NEWS, should the manual also mention it?

I think it would be a good idea to describe this in "Change Logs and
VC", yes.

Re: [PATCH] New option to make C-x 4 a use file-less ChangeLog buffers (was Re: git history tracking across renames (and emacs support))

[João Távora]

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

> > I'll do the NEWS, should the manual also mention it?
>
> I think it would be a good idea to describe this in "Change Logs and
> VC", yes.
>

Actually, I think it fit much better in "Change Log Mode", since the section
you suggest states that it applies to RCS and CVS only and is for
"Generating
a change log file from log entries", to which the new option doesn't apply.

I just pushed the thing in f96fe57fb76df8e7282f266d42a0d471780e1d75,
have a look.

-- 
João Távora

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

Re: [PATCH] New option to make C-x 4 a use file-less ChangeLog buffers (was Re: git history tracking across renames (and emacs support))

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Sat, 21 Jul 2018 16:08:51 +0100
> Cc: Ted Zlatanov <tzz@lifelogs.com>, Lars Ingebrigtsen <larsi@gnus.org>,
> 	Clément Pit-Claudel <cpitclaudel@gmail.com>,
> 	Stefan Monnier <monnier@iro.umontreal.ca>,
> 	emacs-devel <emacs-devel@gnu.org>
> 
> Actually, I think it fit much better in "Change Log Mode", since the section
> you suggest states that it applies to RCS and CVS only and is for "Generating 
> a change log file from log entries", to which the new option doesn't apply.
> 
> I just pushed the thing in f96fe57fb76df8e7282f266d42a0d471780e1d75, 
> have a look.

Thanks, it's fine, module a few minor wording changes.

Re: [PATCH] New option to make C-x 4 a use file-less ChangeLog buffers (was Re: git history tracking across renames (and emacs support))

[Ted Zlatanov]

On Sat, 21 Jul 2018 19:13:30 +0300 Eli Zaretskii <eliz@gnu.org> wrote: 

>> From: João Távora <joaotavora@gmail.com>
>> 
>> I just pushed the thing in f96fe57fb76df8e7282f266d42a0d471780e1d75, 
>> have a look.

EZ> Thanks, it's fine, module a few minor wording changes.

I wanted to thank João, Eli, and everyone else that helped implement
this feature. It works well and has eliminated a pain point in daily
Emacs usage.

Ted

Re: [PATCH] New option to make C-x 4 a use file-less ChangeLog buffers (was Re: git history tracking across renames (and emacs support))

[João Távora]

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

You're very welcome!

On Mon, Oct 8, 2018 at 2:10 AM Ted Zlatanov <tzz@lifelogs.com> wrote:

> On Sat, 21 Jul 2018 19:13:30 +0300 Eli Zaretskii <eliz@gnu.org> wrote:
>
> >> From: João Távora <joaotavora@gmail.com>
> >>
> >> I just pushed the thing in f96fe57fb76df8e7282f266d42a0d471780e1d75,
> >> have a look.
>
> EZ> Thanks, it's fine, module a few minor wording changes.
>
> I wanted to thank João, Eli, and everyone else that helped implement
> this feature. It works well and has eliminated a pain point in daily
> Emacs usage.
>
> Ted
>


-- 
João Távora

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

Re: git history tracking across renames (and emacs support)

[Stefan Monnier]

> I wish there was a way to make these buffers without buffer-file-name and
> still have vc collect the entries from them.  Also, after committing, the
> entries would actually be removed.

How 'bout making C-x 4 a add entries directly to the *vc-log* buffer
when there's one and there's no ChangeLog?

I had played with such a hack at some point but never finished it
because it turned out I like saving it into a file (lets you write the
comment calmly, with no inconvenience if you have to temporarily switch
to some other commit elsewhere, or have to restart Emacs or something).

Maybe another take on it is to use a "hidden" ChangeLog file, saved
somewhere in ~/.emacs.d, indexed by the project location and with some
way to recover some earlier commit message you worked on and had
to abandon?


        Stefan

Re: git history tracking across renames (and emacs support)

[Basil L. Contovounesios]

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

> Maybe another take on it is to use a "hidden" ChangeLog file, saved
> somewhere in ~/.emacs.d, indexed by the project location and with some
> way to recover some earlier commit message you worked on and had
> to abandon?

Like a more persistent and/or VCS-agnostic "${GIT_DIR}/COMMIT_EDITMSG"?

-- 
Basil

Re: git history tracking across renames (and emacs support)

[Stefan Monnier]

>> Maybe another take on it is to use a "hidden" ChangeLog file, saved
>> somewhere in ~/.emacs.d, indexed by the project location and with some
>> way to recover some earlier commit message you worked on and had
>> to abandon?
> Like a more persistent and/or VCS-agnostic "${GIT_DIR}/COMMIT_EDITMSG"?

I think so, yes (and one which allows several messages to be kept).


        Stefan

Re: git history tracking across renames (and emacs support)

[Robert Pluim]

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

>>> Maybe another take on it is to use a "hidden" ChangeLog file, saved
>>> somewhere in ~/.emacs.d, indexed by the project location and with some
>>> way to recover some earlier commit message you worked on and had
>>> to abandon?
>> Like a more persistent and/or VCS-agnostic "${GIT_DIR}/COMMIT_EDITMSG"?
>
> I think so, yes (and one which allows several messages to be kept).

This sounds very much like a file :-)

I just put messages in ChangeLog with C-x 4 a , vc-dir automatically
pulls those into the commit message, and then any subsequent amending
I do via magit's commit interface.

It would be nice if the 'C' command in magit worked better, I donʼt
think it has a 'apply to all diffs' mode.

Robert

Re: git history tracking across renames (and emacs support)

[Stefan Monnier]

> I just put messages in ChangeLog with C-x 4 a , vc-dir automatically
> pulls those into the commit message, and then any subsequent amending
> I do via magit's commit interface.

I do the same, but if you think about it, this intermediate step of
putting things in a new file with a funny name (and which you then need
to tell your VCS to ignore) is rather quaint.

It only seems "natural" if you've used ChangeLog files before.

We need a similarly convenient solution for the post-ChangeLog world.


        Stefan

Re: git history tracking across renames (and emacs support)

[Robert Pluim]

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

>> I just put messages in ChangeLog with C-x 4 a , vc-dir automatically
>> pulls those into the commit message, and then any subsequent amending
>> I do via magit's commit interface.
>
> I do the same, but if you think about it, this intermediate step of
> putting things in a new file with a funny name (and which you then need
> to tell your VCS to ignore) is rather quaint.
>
> It only seems "natural" if you've used ChangeLog files before.
>

I never said it was natural, Iʼm just used to it. If there was a way
to do hunk-by-hunk commit message accumulation from magit's diffs,
then I think Iʼd prefer that, since it would allow me to skip the
'visit the file/hunk from the diff, C-x 4 a' portion of generating a
commit message, and would allow me to avoid vc-dir completely. Or a
magit command I could point at just my staged files to generate the
ChangeLog entries. (isnʼt this vc-chlog? Iʼve not tried it yet)

Regards

Robert

Re: git history tracking across renames (and emacs support)

[Stefan Monnier]

> I never said it was natural, Iʼm just used to it. If there was a way
> to do hunk-by-hunk commit message accumulation from magit's diffs,
> then I think Iʼd prefer that, since it would allow me to skip the
> 'visit the file/hunk from the diff, C-x 4 a' portion of generating a
> commit message,

You can use `C-x 4 a` from the diff, at least (it will still go to the
ChangeLog rather than the vc-log, tho).

> and would allow me to avoid vc-dir completely. Or a
> magit command I could point at just my staged files to generate the
> ChangeLog entries. (isnʼt this vc-chlog? Iʼve not tried it yet)

Generate the diff and then use `C-x 4 A` from the diff.
It should be fairly easy to combine the two into a single command.


        Stefan

Re: git history tracking across renames (and emacs support)

[Robert Pluim]

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

>> I never said it was natural, Iʼm just used to it. If there was a way
>> to do hunk-by-hunk commit message accumulation from magit's diffs,
>> then I think Iʼd prefer that, since it would allow me to skip the
>> 'visit the file/hunk from the diff, C-x 4 a' portion of generating a
>> commit message,
>
> You can use `C-x 4 a` from the diff, at least (it will still go to the
> ChangeLog rather than the vc-log, tho).

Yes, that works from within a magit diff...

>> and would allow me to avoid vc-dir completely. Or a
>> magit command I could point at just my staged files to generate the
>> ChangeLog entries. (isnʼt this vc-chlog? Iʼve not tried it yet)
>
> Generate the diff and then use `C-x 4 A` from the diff.
> It should be fairly easy to combine the two into a single command.

...but this doesnʼt. M-! git diff is always possible, but it would be
nice if this could be integrated with the magit diff output, since it
has useful options for specifying which files you want to diff.

Robert

Re: git history tracking across renames (and emacs support)

[Stefan Monnier]

>> Generate the diff and then use `C-x 4 A` from the diff.
>> It should be fairly easy to combine the two into a single command.
> ...but this doesnʼt.

You meant `C-x 4 A` doesn't work (if so, why not), or combining the two
into a single command doesn't (if so, it probably depends on how you
did it)?


        Stefan

Re: git history tracking across renames (and emacs support)

[Robert Pluim]

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

>>> Generate the diff and then use `C-x 4 A` from the diff.
>>> It should be fairly easy to combine the two into a single command.
>> ...but this doesnʼt.
>
> You meant `C-x 4 A` doesn't work (if so, why not), or combining the two
> into a single command doesn't (if so, it probably depends on how you
> did it)?

C-x 4 A doesnʼt work from a magit diff buffer that contains changes
for multiple files, it creates a ChangeLog entry for whichever file
entry point happens to be in. So I would need to do M-! git diff M-x
diff-mode C-x 4 A. That could be made into a single command, but if
C-x 4 A understood magit diffs, then you'd get complete control over
the content of the diff (staged, unstaged, commit, etc).

Regards

Robert

Re: git history tracking across renames (and emacs support)

[Stefan Monnier]

> C-x 4 A doesnʼt work from a magit diff buffer that contains changes
> for multiple files, it creates a ChangeLog entry for whichever file
> entry point happens to be in.

That's odd.  It sounds like `C-x 4 A` is not bound and it just falls
back on `C-x 4 a`.  What does `C-h k C-x 4 A` say?
I suspect the problem is simply a missing binding in Magit's diff-mode
(which would seem to indicate they don't derive from diff-mode, which
would be sad).


        Stefan

Re: git history tracking across renames (and emacs support)

[Robert Pluim]

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

>> C-x 4 A doesnʼt work from a magit diff buffer that contains changes
>> for multiple files, it creates a ChangeLog entry for whichever file
>> entry point happens to be in.
>
> That's odd.  It sounds like `C-x 4 A` is not bound and it just falls
> back on `C-x 4 a`.  What does `C-h k C-x 4 A` say?

    C-x 4 a (translated from C-x 4 A) runs the command
    magit-add-change-log-entry-other-window (found in

> I suspect the problem is simply a missing binding in Magit's diff-mode
> (which would seem to indicate they don't derive from diff-mode, which
> would be sad).

I donʼt think that would be enough. Running
diff-add-change-log-entries-other-window manually from a magit diff
buffer produces zero changelog entries. Perhaps time to punt to the
magit folks.

Robert

Re: git history tracking across renames (and emacs support)

[Clément Pit-Claudel]

On 2018-07-13 09:07, Robert Pluim wrote:
> I donʼt think that would be enough. Running
> diff-add-change-log-entries-other-window manually from a magit diff
> buffer produces zero changelog entries. Perhaps time to punt to the
> magit folks.

https://github.com/magit/magit/issues/3513

Re: git history tracking across renames (and emacs support)

[Stefan Monnier]

> I donʼt think that would be enough.
> Running diff-add-change-log-entries-other-window manually from a magit
> diff buffer produces zero changelog entries.

Indeed, I see now that Magit goes through the trouble of "prettifying"
Git's diff output, making it incompatible with diff-mode commands (and
inventing a new syntax so you can't save the buffer and then pipe it to
`patch` (or `git am`) for example).

That's too bad: they could get the same visual prettiness without
changing the actual buffer's content.


        Stefan

Re: git history tracking across renames (and emacs support)

[João Távora]

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

>> I wish there was a way to make these buffers without buffer-file-name and
>> still have vc collect the entries from them.  Also, after committing, the
>> entries would actually be removed.
>
> How 'bout making C-x 4 a add entries directly to the *vc-log* buffer
> when there's one and there's no ChangeLog?

I though about that too, but how exactly you deal with multi-file
commits?  The current ChangeLog file, akward as it is, solves this
problem: when you M-x vc-next-action from the *vc-dir*, only the entries
pertaining to the marked files are fetched into the log buffer by
`log-edit-insert-changelog'.

> Maybe another take on it is to use a "hidden" ChangeLog file, saved
> somewhere in ~/.emacs.d, indexed by the project location and with some
> way to recover some earlier commit message you worked on and had
> to abandon?

A single ChangeLog for all my C-x 4 a needs?  Doesn't sound bad, too.
All that would be needed, I think, is to make log-edit-insert-changelog
fix the paths and refill the "paragraphs" when collecting entries.

It leaves me with the multiple-commit-per-day-per-file problem.  I think
the entries copied to the vc-log buffer by `log-edit-insert-changelog'
could be deleted from that file when you C-c C-c (log-edit-done).

João

Re: git history tracking across renames (and emacs support)

[Stefan Monnier]

>>> I wish there was a way to make these buffers without buffer-file-name and
>>> still have vc collect the entries from them.  Also, after committing, the
>>> entries would actually be removed.
>> How 'bout making C-x 4 a add entries directly to the *vc-log* buffer
>> when there's one and there's no ChangeLog?
> I though about that too, but how exactly you deal with multi-file
> commits?

Hmm... I'm missing something because I fail to see in what way this
needs to be treated differently than the single-file case: `C-x 4 a`
only adds a single entry, and you just call it on every relevant part
of the code.

>> Maybe another take on it is to use a "hidden" ChangeLog file, saved
>> somewhere in ~/.emacs.d, indexed by the project location and with some
>> way to recover some earlier commit message you worked on and had
>> to abandon?
> A single ChangeLog for all my C-x 4 a needs?  Doesn't sound bad, too.
> All that would be needed, I think, is to make log-edit-insert-changelog
> fix the paths and refill the "paragraphs" when collecting entries.

I'd think that the file names would already be project-relative when
inserting them with `C-x 4 a`: log-edit-insert-changelog shouldn't have
to mess with the message at all.

More specifically, the suggestion is split into 2 parts:
- a feature for vc-log that lets you save a commit message in a file (in
  ~/.emacs.d, but indexed by the project).  When erasing a *vc-log*
  buffer, I'd probably want the previous message to be automatically be
  stashed into that file.  This would be commit-message-format-agnostic,
  hence not directly related to change-log-mode.
- a new feature of add-log.el which lets you use a vc-log buffer (using
  the slightly different format expected there) instead of the
  ChangeLog file.

> It leaves me with the multiple-commit-per-day-per-file problem.  I think
> the entries copied to the vc-log buffer by `log-edit-insert-changelog'
> could be deleted from that file when you C-c C-c (log-edit-done).

I often re-use some old commit message, so I think I'd rather rely on
a better UI to choose which message to use than on actual deletion of
messages we think are unlikely to be useful.

IOW I think the "multiple-commit-per-day-per-file problem" needs to be
solved by looking more carefully at what happens (e.g. the operation
to fetch a previous commit message would likely first give you the most
recently added message, which should usually be the right choice, no?).

I suspect in your case, the issue with "the
multiple-commit-per-day-per-file problem" is simply that add-log.el
doesn't know where one entry stops and the other starts (and you can
"solve" it by explicitly adding a "<DATE> <NAME> <EMAIL>" line to
separate them), but in the model suggested above, each entry would be
naturally separated, so I think the problem wouldn't show up at all.


        Stefan

Re: git history tracking across renames (and emacs support)

[João Távora]

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

>>>> I wish there was a way to make these buffers without buffer-file-name and
>>>> still have vc collect the entries from them.  Also, after committing, the
>>>> entries would actually be removed.
>>> How 'bout making C-x 4 a add entries directly to the *vc-log* buffer
>>> when there's one and there's no ChangeLog?
>> I though about that too, but how exactly you deal with multi-file
>> commits?
>
> Hmm... I'm missing something because I fail to see in what way this
> needs to be treated differently than the single-file case: `C-x 4 a`
> only adds a single entry, and you just call it on every relevant part
> of the code.

Yes, but imagine that you do that for a bunch of files, and then decide
only to commit a subset of those files.  I guess I could discipline
myself to only add entries for whatever I'm about to commit (sometimes I
add entries for everything I've changed).

>>> Maybe another take on it is to use a "hidden" ChangeLog file, saved
>>> somewhere in ~/.emacs.d, indexed by the project location and with some
>>> way to recover some earlier commit message you worked on and had
>>> to abandon?
>> A single ChangeLog for all my C-x 4 a needs?  Doesn't sound bad, too.
>> All that would be needed, I think, is to make log-edit-insert-changelog
>> fix the paths and refill the "paragraphs" when collecting entries.
>
> I'd think that the file names would already be project-relative when
> inserting them with `C-x 4 a`: log-edit-insert-changelog shouldn't have
> to mess with the message at all.
>
> More specifically, the suggestion is split into 2 parts:
> - a feature for vc-log that lets you save a commit message in a file (in
>   ~/.emacs.d, but indexed by the project).  When erasing a *vc-log*
>   buffer, I'd probably want the previous message to be automatically be
>   stashed into that file.  This would be commit-message-format-agnostic,
>   hence not directly related to change-log-mode.
> - a new feature of add-log.el which lets you use a vc-log buffer (using
>   the slightly different format expected there) instead of the
>   ChangeLog file.

Apart from my comment above, I could probably learn to work with that.

But I had something potentially simpler in mind.  It's very similar to
the current operation.  In this version the file-backed ChangeLog stays
put, but there's only one for every project, this should ease some of
the pain:

1. change-log-default-name is set to something very near the top of the
   file hierarchy, say ~/.emacs.d/UeberChangeLog

2. C-x 4 a is used as usual, but because of point 1, a much longer file
   path gets inserted in the file, like

   * ../Source/Emacs/emacs-master/lisp/jsonrpc.el (jsonrpc--lambda): what
     thingy

   This is working fine currently.

3. After vc-next-action in project dir, C-c C-a inserts the entries

   This doesn't at all work currently if the ChangeLog is higher up in
   the hierarchy than the vc-log buffer's default-directly.

   The paths would need fixing to make them relative to project's
   root. The paragraphs would need refilling. The entry above would
   become

   * lisp/jsonrpc.el (jsonrpc--lambda): what thingy

4. Optionally, C-c C-a would set local variables in the vc-log buffer
   that are markers in ~/.emacs.d/UeberChangeLog.  When the user presses
   C-c C-c the region is deleted (or somehow disabled) in that file.

>> It leaves me with the multiple-commit-per-day-per-file problem.  I think
>> the entries copied to the vc-log buffer by `log-edit-insert-changelog'
>> could be deleted from that file when you C-c C-c (log-edit-done).
>
> I often re-use some old commit message, so I think I'd rather rely on
> a better UI to choose which message to use than on actual deletion of
> messages we think are unlikely to be useful.
>
> IOW I think the "multiple-commit-per-day-per-file problem" needs to be
> solved by looking more carefully at what happens (e.g. the operation
> to fetch a previous commit message would likely first give you the most
> recently added message, which should usually be the right choice, no?).
>
> I suspect in your case, the issue with "the
> multiple-commit-per-day-per-file problem" is simply that add-log.el
> doesn't know where one entry stops and the other starts (and you can
> "solve" it by explicitly adding a "<DATE> <NAME> <EMAIL>" line to
> separate them), but in the model suggested above, each entry would be
> naturally separated, so I think the problem wouldn't show up at all.

I didn't understand this part.  Maybe I need to see it in action.
Generally there's no way of knowing what delimits "the changes I want to
commit now" from other changes without using the actual commit action as
a boundary.

João

Re: git history tracking across renames (and emacs support)

[Stefan Monnier]

> Yes, but imagine that you do that for a bunch of files, and then decide
> only to commit a subset of those files.  I guess I could discipline
> myself to only add entries for whatever I'm about to commit (sometimes I
> add entries for everything I've changed).

Ah, I see.  You want to document each modification first, and then
split them into commits.  That'd be more difficult, yes (tho it's
probably not too hard to do if you only cater to splitting the changes
into commits on a file-by-file granularity).

>    The paths would need fixing to make them relative to project's
>    root. The paragraphs would need refilling. The entry above would
>    become
>
>    * lisp/jsonrpc.el (jsonrpc--lambda): what thingy

I wouldn't want to rely on such an automatic filename rewrite and text
refilling (it's OK for M-q to try and DTRT because I get to see the
result and fix it immediately): I'd feel obligated to tweak (a second
time) the result when the layout isn't quite to my liking.

>> I suspect in your case, the issue with "the
>> multiple-commit-per-day-per-file problem" is simply that add-log.el
>> doesn't know where one entry stops and the other starts (and you can
>> "solve" it by explicitly adding a "<DATE> <NAME> <EMAIL>" line to
>> separate them), but in the model suggested above, each entry would be
>> naturally separated, so I think the problem wouldn't show up at all.
>
> I didn't understand this part.  Maybe I need to see it in action.
> Generally there's no way of knowing what delimits "the changes I want to
> commit now" from other changes without using the actual commit action as
> a boundary.

The content of the vc-log would be defined as "one commit", so if the
user wants to split it, he'd need to explicitly switch to another commit
message, hence telling Emacs where the boundary is: these commits would
likely be combined into a single buffer/file somewhere else but when the
user edits them, he'd only see a single commit (contrary to the current
case with ChangeLog).


        Stefan

Re: git history tracking across renames (and emacs support)

[João Távora]

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

>> Yes, but imagine that you do that for a bunch of files, and then decide
>> only to commit a subset of those files.  I guess I could discipline
>> myself to only add entries for whatever I'm about to commit (sometimes I
>> add entries for everything I've changed).
>
> Ah, I see.  You want to document each modification first, and then
> split them into commits.  That'd be more difficult, yes (tho it's
> probably not too hard to do if you only cater to splitting the changes
> into commits on a file-by-file granularity).

Yeah, hunk by hunk would be nirvana.  This is probably the only thing
about Magit that I envy.  I remeber seeing that diff-mode seems to have
the line-counting machinery that could be made to interact with git add
-p (no idea if that's how Magit does it)


>>>    The paths would need fixing to make them relative to project's
>>    root. The paragraphs would need refilling. The entry above would
>>    become
>>
>>    * lisp/jsonrpc.el (jsonrpc--lambda): what thingy
>
> I wouldn't want to rely on such an automatic filename rewrite and text
> refilling (it's OK for M-q to try and DTRT because I get to see the
> result and fix it immediately): I'd feel obligated to tweak (a second
> time) the result when the layout isn't quite to my liking.

OK scratch refilling.  But the filename rewrite should be perfectly safe.

I'm going to try to implement either this or the fileless ChangeLog idea
that Eli floated before.  Which one do you prefer?

>>> I suspect in your case, the issue with "the
>>> multiple-commit-per-day-per-file problem" is simply that add-log.el
>>> doesn't know where one entry stops and the other starts (and you can
>>> "solve" it by explicitly adding a "<DATE> <NAME> <EMAIL>" line to
>>> separate them), but in the model suggested above, each entry would be
>>> naturally separated, so I think the problem wouldn't show up at all.
>>
>> I didn't understand this part.  Maybe I need to see it in action.
>> Generally there's no way of knowing what delimits "the changes I want to
>> commit now" from other changes without using the actual commit action as
>> a boundary.
>
> The content of the vc-log would be defined as "one commit", so if the
> user wants to split it, he'd need to explicitly switch to another commit
> message, hence telling Emacs where the boundary is: these commits would
> likely be combined into a single buffer/file somewhere else but when the
> user edits them, he'd only see a single commit (contrary to the current
> case with ChangeLog).

Right.  But where would you record this information?  In the
~/.emacs.d/PseudoChangeLog file?

João

Re: git history tracking across renames (and emacs support)

[Stefan Monnier]

>> I wouldn't want to rely on such an automatic filename rewrite and text
>> refilling (it's OK for M-q to try and DTRT because I get to see the
>> result and fix it immediately): I'd feel obligated to tweak (a second
>> time) the result when the layout isn't quite to my liking.
> OK scratch refilling.  But the filename rewrite should be perfectly safe.

Filename rewrite means you change the length of one of the lines, hence
I'd again feel compelled to fix the layout when the result is not to
my liking.

I don't see why you'd need to use some awfully long file names only to
later fix them, even though you know what will be the proper final name
right from the start.

> Right.  But where would you record this information?  In the
> ~/.emacs.d/PseudoChangeLog file?

That wouldn't be my choice of filename, but sure, why not.


        Stefan

Re: git history tracking across renames (and emacs support)

[Radon Rosborough]

> The format is produced mechanically by Emacs commands, so I don't
> see why suddenly the format is the issue. Maybe I interpret "format"
> not the way you meant it?

Wait, what? I was writing these commit messages manually, and it was a
huge pain. How do you do it automatically?

I looked in CONTRIBUTE and there was lots of information about the
format, but none about how to auto-generate it. The section
"Generating ChangeLog entries" linked me to the "Change Log Commands"
section of the manual, which is all about ChangeLog files and doesn't
mention commit messages at all. CONTRIBUTE also mentioned something
about `vc-dwim' but this is not relevant since I use Magit. Also, the
information is completely impossible to find via Google because it is
a tiny niche thing that nobody else uses.

> IMO, what you'd like to have will actually _raise_ the friction
> (i.e. will be harder to provide) for many contributors, according to
> my experience of reviewing quite a few patches.

FWIW, I'm totally on the side of "get rid of the format". No other
project I contribute to has this kind of requirement, and it most
definitely raises the bar to new contributors. I don't understand the
above comment at all; maybe you can elaborate?

If you're concerned about new contributors not knowing how to write
commit messages in the absence of the existing format, why not just
link them to <https://chris.beams.io/posts/git-commit/>?

---

I think that when discussing all sorts of these issues on emacs-devel
(using modern code hosting, modern issue tracking, modern CI, modern
pull request workflow, ...) the discussion is biased because most of
the people who would benefit from moving into the future simply don't
bother to contribute to Emacs or post here. It's an opportunity cost
that you will not be able to measure by posting an inquiry to a
mailing list(!). And naturally the maintainers all have extensive
experience with using the existing tooling and are inclined to think
it is easier to use than it actually is.

Perhaps I am wrong about this; if so, please correct me. But I've
gotten a very strong impression in this direction in the course of
being subscribed to this list and maintaining several open-source
Emacs projects over the past year.

Re: git history tracking across renames (and emacs support)

[Paul Eggert]

Radon Rosborough wrote:
> naturally the maintainers all have extensive
> experience with using the existing tooling and are inclined to think
> it is easier to use than it actually is.

I'm not inclined to think that way at all, and I have more experience with using 
the existing tooling than most. ChangeLog was designed before software tools 
like Git were common, and the format's insistence on recording details easily 
findable elsewhere wastes my time and my readers' time, as well as being a 
barrier to entry as you mention. Unfortunately, we have not been able to 
convince RMS to fix the format, even though it really needs an upgrade.

Re: git history tracking across renames (and emacs support)

[Eli Zaretskii]

> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Wed, 11 Jul 2018 10:56:08 -0700
> Cc: Ted Zlatanov <tzz@lifelogs.com>, larsi@gnus.org,
> 	emacs-devel <emacs-devel@gnu.org>
> 
> Unfortunately, we have not been able to convince RMS to fix the
> format, even though it really needs an upgrade.

It doesn't help that dropping the current format makes the commit logs
deteriorate in quality in every project I saw (present parties
excluded, of course).

Re: git history tracking across renames (and emacs support)

[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 doesn't help that dropping the current format makes the commit logs
  > deteriorate in quality in every project I saw (present parties
  > excluded, of course).

Could you show examples of what you mean?
This could be a very important issue.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: git history tracking across renames (and emacs support)

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: eggert@cs.ucla.edu, tzz@lifelogs.com, radon.neon@gmail.com,
> 	larsi@gnus.org, emacs-devel@gnu.org
> Date: Wed, 11 Jul 2018 18:51:52 -0400
> 
>   > It doesn't help that dropping the current format makes the commit logs
>   > deteriorate in quality in every project I saw (present parties
>   > excluded, of course).
> 
> Could you show examples of what you mean?
> This could be a very important issue.

I agree it's important, but I'm not sure this is the right place to
discuss it.  But since you asked, I'll show a typical example.

GNU enscript stopped using ChangeLog in 2014.  Since then the log
messages look like this:

  commit 0779ca6512bf93e8f8dfe53c1a3446adb2475acc
  Author:     Werner Fink <werner@suse.de>
  AuthorDate: Tue Jan 23 15:26:50 2018 +0100

      Simply avoid warnings of modern gcc

      Signed-off-by: Werner Fink <werner@suse.de>
      Signed-off-by: James Cloos <cloos@jhcloos.com>

  commit 1b76685a8e405f54bae2b0f131588e8018e80f71
  Author:     Werner Fink <werner@suse.de>
  AuthorDate: Tue Jan 23 15:26:49 2018 +0100

      Mention options for helper apps in manual page

      Signed-off-by: Werner Fink <werner@suse.de>
      Signed-off-by: James Cloos <cloos@jhcloos.com>

  commit 9cccf335aafe68d04f6b4daeeb435e5188db4acb
  Author:     Werner Fink <werner@suse.de>
  AuthorDate: Tue Jan 23 15:26:48 2018 +0100

      Add optional address for mailto option

      Signed-off-by: Werner Fink <werner@suse.de>
      Signed-off-by: James Cloos <cloos@jhcloos.com>

  commit 3638fc4643436b27b4fd034416d77651a057fc42
  Author:     Werner Fink <werner@suse.de>
  AuthorDate: Tue Jan 23 15:26:47 2018 +0100

      Flexible encoding and support of locale paper size

      as well paper size names known by ghostscript

      Signed-off-by: Werner Fink <werner@suse.de>
      Signed-off-by: James Cloos <cloos@jhcloos.com>

  commit a356d343aa9db52b75432cde927b6f9bad6a7c44
  Author:     Werner Fink <werner@suse.de>
  AuthorDate: Tue Jan 23 15:26:45 2018 +0100

      Automake 1.12 and up no longer supports pre-ANSI

      Signed-off-by: Werner Fink <werner@suse.de>
      Signed-off-by: James Cloos <cloos@jhcloos.com>

etc.  You can see the whole thing here:

   http://git.savannah.gnu.org/cgit/enscript.git/log/

I see something similar in many projects, except that "old hands" like
Paul Eggert, Jim Meyering, and others still write log entries in GNU
style, so where these guys are active, the overall picture is not too
bad.  But others don't, and their entries are much less informative.

Re: git history tracking across renames (and emacs support)

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

  > like Git were common, and the format's insistence on recording details easily 
  > findable elsewhere wastes my time and my readers' time, as well as being a 
  > barrier to entry as you mention. Unfortunately, we have not been able to 
  > convince RMS to fix the format, even though it really needs an upgrade.

It is not a matter of an "upgrade" to the "format".

The issue is whether to stop including the detailed changes.
I've agreeds to this in principle, provided that we have tools
that really provide those data correctly.

Proponents of the change claim that some Git commands provide the same
data.  However, I've shown that the output is incorrect in certain
situations.  They are unusual, but not rare or absurd.

If you'd like this change to be made, recognize the problem and fix
it.  Implement a kind of diff that reliably gives the correct list
of entities changed -- at least for C and Emacs Lisp -- and then
I'll agree to this change for Emacs Lisp.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: git history tracking across renames (and emacs support)

[Ted Zlatanov]

On Wed, 11 Jul 2018 18:51:53 -0400 Richard Stallman <rms@gnu.org> wrote: 

RS> The issue is whether to stop including the detailed changes. I've
RS> agreeds to this in principle, provided that we have tools that
RS> really provide those data correctly.

RS> Proponents of the change claim that some Git commands provide the
RS> same data. However, I've shown that the output is incorrect in
RS> certain situations. They are unusual, but not rare or absurd.

RS> If you'd like this change to be made, recognize the problem and fix
RS> it. Implement a kind of diff that reliably gives the correct list of
RS> entities changed -- at least for C and Emacs Lisp -- and then I'll
RS> agree to this change for Emacs Lisp.

Could you provide a reference to the previous discussion or summarize
it? I couldn't find it.

Ted

Re: git history tracking across renames (and emacs support)

[Paul Eggert]

On 07/12/2018 02:46 PM, Ted Zlatanov wrote:
> RS> If you'd like this change to be made, recognize the problem and fix
> RS> it. Implement a kind of diff that reliably gives the correct list of
> RS> entities changed -- at least for C and Emacs Lisp -- and then I'll
> RS> agree to this change for Emacs Lisp.
>
> Could you provide a reference to the previous discussion or summarize
> it? I couldn't find it.

The discussion has come up multiple times. A recent lengthy iteration
started here:

https://lists.gnu.org/r/bug-standards/2017-11/msg00005.html

and continued for months. I think RMS's request is buried in that thread
somewhere. Nobody has implemented the request, as far as I know.

Re: git history tracking across renames (and emacs support)

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

The previous discussion of change logs was in the first half of May.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: git history tracking across renames (and emacs support)

[Eli Zaretskii]

> From: Radon Rosborough <radon.neon@gmail.com>
> Date: Wed, 11 Jul 2018 11:08:54 -0600
> Cc: Ted Zlatanov <tzz@lifelogs.com>, larsi@gnus.org, emacs-devel <emacs-devel@gnu.org>
> 
> Wait, what? I was writing these commit messages manually, and it was a
> huge pain. How do you do it automatically?

Semi-automatically.  See my other message where I hope I explained
what I meant.

> I looked in CONTRIBUTE and there was lots of information about the
> format, but none about how to auto-generate it. The section
> "Generating ChangeLog entries" linked me to the "Change Log Commands"
> section of the manual, which is all about ChangeLog files and doesn't
> mention commit messages at all.

I hope you will understand the connection after reading my other
message.  But if you have suggestions for clarifying CONTRIBUTE,
please tell.

> CONTRIBUTE also mentioned something
> about `vc-dwim' but this is not relevant since I use Magit.

I believe magit has a command that helps you produce the log message.

> No other project I contribute to has this kind of requirement, and
> it most definitely raises the bar to new contributors.

I guess it depends on the projects.  I contribute to several other
projects, like GDB, Gawk, and Texinfo, and they all maintain ChangeLog
files, let alone require the format.  GNU Make doesn't keep ChangeLog
files, but its log messages are formatted like ChangeLog.

So I guess my experience is 100% opposite of yours.

> I don't understand the above comment at all; maybe you can
> elaborate?

I think I already did, in my other messages.

> If you're concerned about new contributors not knowing how to write
> commit messages in the absence of the existing format, why not just
> link them to <https://chris.beams.io/posts/git-commit/>?

Like I said: free text log messages leave a lot of space for
disagreement about what is and what isn't a good message.  IME, new
contributors want clear and concise instructions; telling them to read
a long blog will definitely turn off many of them.

> I think that when discussing all sorts of these issues on emacs-devel
> (using modern code hosting, modern issue tracking, modern CI, modern
> pull request workflow, ...) the discussion is biased because most of
> the people who would benefit from moving into the future simply don't
> bother to contribute to Emacs or post here. It's an opportunity cost
> that you will not be able to measure by posting an inquiry to a
> mailing list(!). And naturally the maintainers all have extensive
> experience with using the existing tooling and are inclined to think
> it is easier to use than it actually is.

There's no way around that: the only practical way of changing the
Emacs development practices is from within.  Think about it: why would
I support radical changes in our procedures that get in the way of my
work, when I have so little time to work on Emacs and so much to do?
Any project is shaped by those who work on it the most.

Re: git history tracking across renames (and emacs support)

[Radon Rosborough]

> But if you have suggestions for clarifying CONTRIBUTE, please tell.

I think that CONTRIBUTE needs to give a step-by-step guide for how to
generate a commit message with Magit, since Magit is certainly either
the most popular or second most popular version-control frontend for
Emacs.

It should probably also provide a step-by-step guide for doing this
with VC. As soon as I am linked to documentation about editing
ChangeLog files, I will assume I've gone astray, unless it's explained
why editing ChangeLog files is necessary in order to generate a commit
message.

> I guess it depends on the projects. I contribute to several other
> projects, like GDB, Gawk, and Texinfo

Well, those are all GNU projects. So I think that's the difference. It
seems to me that ChangeLog is a "GNU thing". As are mailing lists,
avoidance of GitLab, using debbugs, etc.

> Like I said: free text log messages leave a lot of space for
> disagreement about what is and what isn't a good message.

This is true, but it seems to me that we already have this problem.
After all, the current format doesn't say anything about how to
actually describe your change. It just tells you how to replicate the
diff in your commit message. By dropping the format, we would only be
losing the replicated diff information; we wouldn't be losing any
directions on how to communicate useful information that *can't* be
auto-generated, because there are no such instructions now.

> IME, new contributors want clear and concise instructions; telling
> them to read a long blog will definitely turn off many of them.

I think the blog does a much better job of getting across its
information clearly, concisely, and understandably:

1. Separate subject from body with a blank line
2. Limit the subject line to 50 characters
3. Capitalize the subject line
4. Do not end the subject line with a period
5. Use the imperative mood in the subject line
6. Wrap the body at 72 characters
7. Use the body to explain what and why vs. how

Plus, everybody knows this already, since virtually every open-source
project follows more or less these guidelines for commit messages.
I've seen many projects which link to exactly the same blog article,
in fact! On the contrary, it seems to me like the only people who know
about ChangeLog format are regular contributors to GNU projects.

> Think about it: why would I support radical changes in our
> procedures that get in the way of my work, when I have so little
> time to work on Emacs and so much to do?

Of course. And I don't mean to criticize your work at all; if I came
across that way, it is my fault and I apologize.

I only wish to push for an agreement that "if somebody were willing to
do the work to remove the ChangeLog format, then the patch would be
accepted". Otherwise, who is going to write a patch?

Re: git history tracking across renames (and emacs support)

[Eli Zaretskii]

> From: Radon Rosborough <radon.neon@gmail.com>
> Date: Thu, 12 Jul 2018 11:03:09 -0600
> Cc: Ted Zlatanov <tzz@lifelogs.com>, Lars Ingebrigtsen <larsi@gnus.org>, emacs-devel <emacs-devel@gnu.org>
> 
> > But if you have suggestions for clarifying CONTRIBUTE, please tell.
> 
> I think that CONTRIBUTE needs to give a step-by-step guide for how to
> generate a commit message with Magit, since Magit is certainly either
> the most popular or second most popular version-control frontend for
> Emacs.

Is it really an issue with magit?  And if it is, why isn't it
documented in magit's documentation?

> It should probably also provide a step-by-step guide for doing this
> with VC.

It is: in the Emacs manual.

> As soon as I am linked to documentation about editing
> ChangeLog files, I will assume I've gone astray, unless it's explained
> why editing ChangeLog files is necessary in order to generate a commit
> message.

I don't understand why.  How about providing detailed critique of what
CONTRIBUTE says under "Generating ChangeLog entries"?

> > I guess it depends on the projects. I contribute to several other
> > projects, like GDB, Gawk, and Texinfo
> 
> Well, those are all GNU projects. So I think that's the difference. It
> seems to me that ChangeLog is a "GNU thing". As are mailing lists,
> avoidance of GitLab, using debbugs, etc.

Well, we are talking about Emacs, and Emacs will always be a GNU
project.

> > Like I said: free text log messages leave a lot of space for
> > disagreement about what is and what isn't a good message.
> 
> This is true, but it seems to me that we already have this problem.

Not IME, no.

> After all, the current format doesn't say anything about how to
> actually describe your change. It just tells you how to replicate the
> diff in your commit message.

Nevertheless, log messages provided by contributors are pretty close
to what I'd like to see, after a couple of initial submissions, where
we generally need to point out some minor nits.

> By dropping the format, we would only be losing the replicated diff
> information; we wouldn't be losing any directions on how to
> communicate useful information that *can't* be auto-generated,
> because there are no such instructions now.

I guess you never had to deal with contributors who ask "where's that
written" right away when you make some comment about their submission.
That's how CONTRIBUTE was born in the first place.

> > IME, new contributors want clear and concise instructions; telling
> > them to read a long blog will definitely turn off many of them.
> 
> I think the blog does a much better job of getting across its
> information clearly, concisely, and understandably:

It's too long, IMO.

> Plus, everybody knows this already, since virtually every open-source
> project follows more or less these guidelines for commit messages.

If so, why would someone need to write a blog, and why would we need
to point to it?  Evidently not everybody knows that.

> I only wish to push for an agreement that "if somebody were willing to
> do the work to remove the ChangeLog format, then the patch would be
> accepted". Otherwise, who is going to write a patch?

I cannot answer that because I don't think I understand what is being
proposed here.  If the proposal is to let people write what they want,
then I don't think I'd agree, for reasons I tried to explain.

Re: git history tracking across renames (and emacs support)

[Radon Rosborough]

> Is it really an issue with magit? And if it is, why isn't it
> documented in magit's documentation?

In my opinion, it doesn't really make sense for Magit, a
general-purpose Git frontend, to document the specific contribution
guidelines for GNU projects.

Sure, Magit should document the functionality it provides, and I
believe it does provide ChangeLog-related functionality. But in that
case, the Emacs CONTRIBUTE should most assuredly link to that
documentation. It can't simply say "please figure it out yourself"!
Since GNU projects are using a nonstandard commit message formatting
from the perspective of the rest of the world, I think the burden is
on them to tell contributors about that format and how to produce it
(if indeed the format is too burdensome to write by hand, which I
believe the ChangeLog format is).

>> As soon as I am linked to documentation about editing
>> ChangeLog files, I will assume I've gone astray, unless it's explained
>> why editing ChangeLog files is necessary in order to generate a commit
>> message.
>
> I don't understand why. How about providing detailed critique of
> what CONTRIBUTE says under "Generating ChangeLog entries"?

On re-reading very carefully, I see that I read "write ChangeLog
entries" as an operation that one would do when creating a ChangeLog
file, whereas it was meant more generally.

So, yes, the misunderstanding is my fault. However, I think it would
be much clearer if there were actual, literal step-by-step
instructions on how to go from a working directory with some changes
in it to a properly formatted commit. Directing people to pore through
the manual just so they can commit to Emacs seems a bit burdensome to
me; isn't there a reason we have CONTRIBUTE? To make contributing as
easy as possible?

I'm sure somebody will say that I am just being lazy. But the fact
remains that Emacs is much harder to contribute to than other
open-source projects, because of things like this.

>> It seems to me that ChangeLog is a "GNU thing". As are mailing
>> lists, avoidance of GitLab, using debbugs, etc.
>
> Well, we are talking about Emacs, and Emacs will always be a GNU
> project.

*cough* https://github.com/Wilfred/remacs *cough*

But seriously though, just because GNU projects usually have
ChangeLogs doesn't mean that ChangeLogs are a good idea. If they are
such a good idea, then why don't any other projects have them?

> Nevertheless, log messages provided by contributors are pretty close
> to what I'd like to see, after a couple of initial submissions,
> where we generally need to point out some minor nits.

But what do you want to see? Auto-generated ChangeLog entries? If
that's really what you want, then it sounds like you aren't open to
any other format.

Personally, what I want to see in commit messages is a properly
formatted summary line, links to any related bug reports, and an
explanation of anything important to know about the change that can't
be put in comments. These things could be included or not regardless
of whether ChangeLog format is used. They are what *I* want to see;
what do you want to see?

> > I think the blog does a much better job of getting across its
> > information clearly, concisely, and understandably:
>
> It's too long, IMO.

Surely the seven-line bullet-point list is not too long, is it?
Honestly, the rest of the article is just embellishment. If you
*really* want a shorter article, there are plenty of others that say
essentially the same thing in different words (because, as I've said,
essentially every open-source project uses these guidelines as a
baseline):

* https://gist.github.com/robertpainsi/b632364184e70900af4ab688decf6f53
* https://github.com/erlang/otp/wiki/writing-good-commit-messages
* https://medium.com/@steveamaza/how-to-write-a-proper-git-commit-message-e028865e5791

>> Plus, everybody knows this already, since virtually every open-source
>> project follows more or less these guidelines for commit messages.
>
> If so, why would someone need to write a blog, and why would we need
> to point to it? Evidently not everybody knows that.

I said "everybody knows" in the same sense that I say "everyone knows
you're not supposed to check the binaries into Git". Like, sure, there
are people who don't know, but in that case it's pretty much on them
because this is a really basic thing that you just have to learn if
you want to do open-source software development. As a corollary, if
"everybody knows" something, then we should certainly mention it, but
we shouldn't consider it burdensome to expect people to learn about it
if they didn't already know.

> If the proposal is to let people write what they want, then I don't
> think I'd agree, for reasons I tried to explain.

That's unfortunate. What would change your mind?

My position is based on the belief that the current format makes it
harder for new contributors than a more open format. If potential new
contributors to Emacs were to tell me they prefer the current format,
then that would change *my* mind.

Re: git history tracking across renames (and emacs support)

[Eli Zaretskii]

> From: Radon Rosborough <radon.neon@gmail.com>
> Date: Thu, 12 Jul 2018 22:33:13 -0600
> Cc: Ted Zlatanov <tzz@lifelogs.com>, Lars Ingebrigtsen <larsi@gnus.org>, emacs-devel <emacs-devel@gnu.org>
> 
> > Is it really an issue with magit? And if it is, why isn't it
> > documented in magit's documentation?
> 
> In my opinion, it doesn't really make sense for Magit, a
> general-purpose Git frontend, to document the specific contribution
> guidelines for GNU projects.
> 
> Sure, Magit should document the functionality it provides, and I
> believe it does provide ChangeLog-related functionality. But in that
> case, the Emacs CONTRIBUTE should most assuredly link to that
> documentation.

Sorry, I've misinterpreted what you wrote to mean that magit's docs
don't cover the features we need.  If the docs do cover that, then
yes, a short reference to them, as in "If you use magit, set
this-and-that variable and use such-and-such commands" would be a
welcome addition to CONTRIBUTE.

> On re-reading very carefully, I see that I read "write ChangeLog
> entries" as an operation that one would do when creating a ChangeLog
> file, whereas it was meant more generally.
> 
> So, yes, the misunderstanding is my fault. However, I think it would
> be much clearer if there were actual, literal step-by-step
> instructions on how to go from a working directory with some changes
> in it to a properly formatted commit. Directing people to pore through
> the manual just so they can commit to Emacs seems a bit burdensome to
> me; isn't there a reason we have CONTRIBUTE? To make contributing as
> easy as possible?
> 
> I'm sure somebody will say that I am just being lazy. But the fact
> remains that Emacs is much harder to contribute to than other
> open-source projects, because of things like this.

At the risk of sounding like a broken record, may I suggest to provide
a specific critique of the relevant CONTRIBUTE parts?  Like a patch,
or a quotation followed by an explanation why you think that
particular text is unclear or missing something?

> But seriously though, just because GNU projects usually have
> ChangeLogs doesn't mean that ChangeLogs are a good idea. If they are
> such a good idea, then why don't any other projects have them?

That might be an interesting discussion, but I doubt it belongs to
this list.  GNU projects have several peculiar requirements, like
copyright assignments and adherence to the GNU Coding Standards
document, which are not specific to Emacs, and against which people
sometimes complain, because other projects don't bother with those.
Discussing that here is not useful.

> > Nevertheless, log messages provided by contributors are pretty close
> > to what I'd like to see, after a couple of initial submissions,
> > where we generally need to point out some minor nits.
> 
> But what do you want to see? Auto-generated ChangeLog entries?

I want to see log entries that mention the functions/variables which
were changed, and a high-level description of the changes, with
motivation for the changes where appropriate.  (Note that a pointer to
a bug number can usually serve instead of many words, because the
discussion of the bug includes a lot of useful information.)  The
exact form is much less important to me, except that changelog-mode
already makes that available in a format that is well known.  But IMO
that format in itself is not sacred; the information it provides is.

> Personally, what I want to see in commit messages is a properly
> formatted summary line

Actually, I find the summary line to be a nuisance in too many cases.
From my POV, it's something we must do because Git more-or-less
requires that, but I find myself thinking about it for too long in
some cases, and OTOH some header lines I see in the repository are
(non-funny) jokes.  I grind my teeth and adhere to that convention,
but I don't like it.  This is the other face of dropping ChangeLog:
there was never a requirement for a header line in ChangeLog entries,
so I provided one when that made sense, and didn't when it didn't.
Now I _must_ provide it unless the log entry is short enough to serve
as its own header line (which is sometimes downright impossible
because the file name and the function name are already too long).

> links to any related bug reports, and an
> explanation of anything important to know about the change that can't
> be put in comments. These things could be included or not regardless
> of whether ChangeLog format is used. They are what *I* want to see;
> what do you want to see?

It's the "anything important to know about the change that can't be
put in comments" part that I'm worried about.  How do you tell
contributors clearly and concisely how to achieve that, if the idea is
that they can write anything they think is right there?

> > > I think the blog does a much better job of getting across its
> > > information clearly, concisely, and understandably:
> >
> > It's too long, IMO.
> 
> Surely the seven-line bullet-point list is not too long, is it?

It's not really a seven-line list, because the important part is the
explanations after that.  Let me rephrase: it's too long to put in
CONTRIBUTE, and it's too long to ask contributors to read before they
submit a patch.

> > If the proposal is to let people write what they want, then I don't
> > think I'd agree, for reasons I tried to explain.
> 
> That's unfortunate. What would change your mind?

Propose specific changes that will make the job easier without losing
information.  Explain, and ask others to explain, _why_ what we
currently require is so much harder than the alternatives (and limit
the valid alternatives to those that don't lose information).  Submit
patches to commands that will make the job easier.  Etc. etc.

> My position is based on the belief that the current format makes it
> harder for new contributors than a more open format.

If there is a reasonable way to make it easier without losing valuable
information, sure, we'd like to do that.  Otherwise, it's just one of
those cases where one needs to pay a (IMO small) fee to participate in
a project.  Because making contributions easier is not the only valid
motivation in setting up our procedures, there are certain
considerations that we must observe.

Re: git history tracking across renames (and emacs support)

[Paul Eggert]

On 07/13/2018 03:14 AM, Eli Zaretskii wrote:
> I find the summary line to be a nuisance in too many cases.

Although the summary line is sometimes a nuisance to write, when done
well it is so useful that it's clearly a net win over our old way of
doing things. Many Git user interfaces list only the summary lines, and
for good reason: they let you quickly scan a list of commits looking for
what happened in those commits. Writing a useful summary line is thus a
real service to later developers, and is far more helpful than the file,
function and variable names that the GNU coding standards currently
require in ChangeLogs.

The primary UI that we promote on the web
<http://git.savannah.gnu.org/cgit/emacs.git> lists just summary lines. I
just now looked at the most recent ten summary lines in Emacs master,
and eight of them seemed useful. The two I found less useful were
"Unbreak bootstrap" (a motivation for the change, but not enough
description) and "Fix Bug#32107" (likewise). It'd be helpful for us to
encourage people to write commit messages with summary lines that are
suitable for later readers.

Re: git history tracking across renames (and emacs support)

[Eli Zaretskii]

> Cc: tzz@lifelogs.com, larsi@gnus.org, emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Fri, 13 Jul 2018 09:15:55 -0500
> 
> On 07/13/2018 03:14 AM, Eli Zaretskii wrote:
> > I find the summary line to be a nuisance in too many cases.
> 
> Although the summary line is sometimes a nuisance to write, when done
> well it is so useful that it's clearly a net win over our old way of
> doing things. Many Git user interfaces list only the summary lines, and
> for good reason: they let you quickly scan a list of commits looking for
> what happened in those commits. Writing a useful summary line is thus a
> real service to later developers, and is far more helpful than the file,
> function and variable names that the GNU coding standards currently
> require in ChangeLogs.
> 
> The primary UI that we promote on the web
> <http://git.savannah.gnu.org/cgit/emacs.git> lists just summary lines. I
> just now looked at the most recent ten summary lines in Emacs master,
> and eight of them seemed useful. The two I found less useful were
> "Unbreak bootstrap" (a motivation for the change, but not enough
> description) and "Fix Bug#32107" (likewise). It'd be helpful for us to
> encourage people to write commit messages with summary lines that are
> suitable for later readers.

All true.  Like I said: this is the price we pay for using Git and
related UIs instead of ChangeLog, where header lines were optional, to
be used where that really made sense (which was relatively rare).
With Git, they're mandatory, because if we don't use them, various
dependent features will not work well, or not at all.

Like almost every other feature, this one has its price.

Re: git history tracking across renames (and emacs support)

[Stefan Monnier]

> Although the summary line is sometimes a nuisance to write, when done
> well it is so useful that it's clearly a net win over our old way of
> doing things.

Agreed, they're very handy.  Basically for the same reason that
ChangeLog messages are handy (as a summary of the diff).


        Stefan

Re: git history tracking across renames (and emacs support)

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

  > The two I found less useful were
  > "Unbreak bootstrap" (a motivation for the change, but not enough
  > description) and "Fix Bug#32107" (likewise). It'd be helpful for us to
  > encourage people to write commit messages with summary lines that are
  > suitable for later readers.

I agree.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Commit header lines (was: git history tracking across renames (and emacs support))

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Fri, 13 Jul 2018 19:11:26 -0400
> Cc: larsi@gnus.org, eliz@gnu.org, radon.neon@gmail.com, tzz@lifelogs.com,
> 	emacs-devel@gnu.org
> 
>   > The two I found less useful were
>   > "Unbreak bootstrap" (a motivation for the change, but not enough
>   > description) and "Fix Bug#32107" (likewise). It'd be helpful for us to
>   > encourage people to write commit messages with summary lines that are
>   > suitable for later readers.
> 
> I agree.

Unfortunately, the percent of the "less useful" summary lines I see is
significantly larger than 2 in 10.  There are header lines that don't
add any information to the log message, in many cases they are just
the first entry slightly rephrased.  In other cases, they say
something uninformative like "Minor copyedits SOMEWHERE".  And in
many/most of those cases I see no better way to phrase the header line
that would fit into 65 characters.  (Some of those header lines are
mine, btw, which means it's already the best wording I could come up
with.)

Again, it's a minor gripe, and a little price to pay.  But let's not
forget that a price it is.

Re: Commit header lines (was: git history tracking across renames (and emacs support))

[Paul Eggert]

On 07/14/2018 01:58 AM, Eli Zaretskii wrote:
> There are header lines that don't
> add any information to the log message, in many cases they are just
> the first entry slightly rephrased.

If a summary line is a shorter version of the main text, that's a good
thing. It's like a good title for a news article or a research paper: it
restates the main text briefly, and there is real value in that.

If a summary line is merely a copy of the first sentence of the log,
then of course you're right: why bother? Just say it once, in the
summary. Again, this is like an article or paper.

> In other cases, they say
> something uninformative like "Minor copyedits SOMEWHERE".

If the copyedits truly are minor those are OK. The main point of
one-line summaries is to let readers quickly see which changes are
relevant to their concerns. For example the most recent commit using
that form, "Minor copyedits in Emacs manual in macos.texi", is OK;
unless I'm interested in editing macos.texi I can quickly skip over that
commit.

If the copyedits aren't truly minor then of course that would be a
problem, as would be any incorrect summary line.

> And in
> many/most of those cases I see no better way to phrase the header line
> that would fit into 65 characters.

If it's "Minor copyedits in Emacs manual in macos.texi" then we're doing
OK already; I wouldn't worry about rephrasing that one, anyway.

By the way, the usual suggested length limit for summary lines is 50
characters, not 65.

Re: Commit header lines (was: git history tracking across renames (and emacs support))

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Sat, 14 Jul 2018 11:09:27 -0500
> 
> On 07/14/2018 01:58 AM, Eli Zaretskii wrote:
> > There are header lines that don't
> > add any information to the log message, in many cases they are just
> > the first entry slightly rephrased.
> 
> If a summary line is a shorter version of the main text, that's a good
> thing. It's like a good title for a news article or a research paper: it
> restates the main text briefly, and there is real value in that.

I disagree with your perception, but I guess we are getting into the
gray area where personal preferences mean more than anything else.

> By the way, the usual suggested length limit for summary lines is 50
> characters, not 65.

50 is the suggested length, but 65 is the absolute maximum, mainly
because otherwise it will overflow the margin when we create a
ChangeLog out of Git log.

Re: Commit header lines (was: git history tracking across renames (and emacs support))

[Paul Eggert]

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

On 07/14/2018 11:23 AM, Eli Zaretskii wrote:
>> If a summary line is a shorter version of the main text, that's a good
>> thing. It's like a good title for a news article or a research paper: it
>> restates the main text briefly, and there is real value in that.
> I disagree with your perception, but I guess we are getting into the
> gray area where personal preferences mean more than anything else.
>
I suppose it could be called a personal preference, in that I prefer to
follow the common practice of summarizing the commit message in its
first line. This standard for Git, where the summary line is commonly
used to good effect. We old-timers know about predecessor
version-control systems like RCS and CVS where other commit-message
conventions might have made sense too. But those days are gone, and good
riddance if you ask me.

Today the primary use of a summary line is to give readers a quick way
to see whether a change is worth looking into in more detail, and
authors of patches should keep this in mind.


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

Re: git history tracking across renames (and emacs support)

[Ted Zlatanov]

On Wed, 11 Jul 2018 21:25:20 +0300 Eli Zaretskii <eliz@gnu.org> wrote: 

EZ> Think about it: why would I support radical changes in our
EZ> procedures that get in the way of my work, when I have so little
EZ> time to work on Emacs and so much to do? Any project is shaped by
EZ> those who work on it the most.

To attract new contributors who can take the work off your shoulders.

Ted

Re: git history tracking across renames (and emacs support)

[Eli Zaretskii]

> From: Ted Zlatanov <tzz@lifelogs.com>
> Cc: Radon Rosborough <radon.neon@gmail.com>,  larsi@gnus.org,  emacs-devel@gnu.org
> Date: Thu, 12 Jul 2018 19:42:57 +0000
> 
> On Wed, 11 Jul 2018 21:25:20 +0300 Eli Zaretskii <eliz@gnu.org> wrote: 
> 
> EZ> Think about it: why would I support radical changes in our
> EZ> procedures that get in the way of my work, when I have so little
> EZ> time to work on Emacs and so much to do? Any project is shaped by
> EZ> those who work on it the most.
> 
> To attract new contributors who can take the work off your shoulders.

It works the other way around.

Re: git history tracking across renames (and emacs support) (Was: The name gnus-cloud.el)

[Eli Zaretskii]

> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Tue, 2 Jan 2018 00:06:11 -0800
> Cc: emacs-devel@gnu.org
> 
> What would be most helpful (and I realize I'm asking for a lot) would be 
> ChangeLog entries or commit messages (it doesn't matter which) that explain the 
> *motivation* for each change.

IME, using log messages for this is OK, but it should be the last
resort, because log messages don't lend themselves to detailed
explanations, so the result will more often than not cryptic and not
detailed enough.  I would suggest the following alternatives:

  . the first priority should be to leave the explanation as comments
    in the code, if that is feasible, because then the commit explains
    itself, and the information is also available during simple code
    reading unrelated to VCS history searching;
  . if the change was discussed in some public forum, include the
    pointer to that discussion in the log message (bug number is a
    special case of this, but it's not the only one) -- this is
    preferable because many times these discussions include test cases
    that are important if you want to make sure further changes don't
    break what was fixed;
  . if none of the above is possible/practical, then yes, write the
    explanation in the log message, if the code change is not
    self-explanatory enough.

> In contrast, often it is counterproductive to 
> burden commit messages with mechanical details such as naming each and every 
> function that was modified, as it wastes developers' time to wade through these 
> details when they're trying to look for stuff that's more important.

If you are looking for a specific change in a specific function, then
ChangeLog style is exactly what you want.  If you are looking for
something else, why would you look at the log messages at all, instead
of using VCS commands related to history and forensics?

Re: git history tracking across renames (and emacs support) (Was: The name gnus-cloud.el)

[Paul Eggert]

Eli Zaretskii wrote:

> If you are looking for a specific change in a specific function, then
> ChangeLog style is exactly what you want.  If you are looking for
> something else, why would you look at the log messages at all, instead
> of using VCS commands related to history and forensics?

Because I am looking for *why* the code is the way it is, and ChangeLog entries 
that emphasize function names are typically not that helpful.

For example, I'm currently working on a Coreutils patch so that "mv a b c 
d/e/f/g/" will traverse the directories in d/e/f/g/ just once instead of three 
times (once each for "a", "b", and "c"), thus reducing an O(N**2) to an O(N) 
algorithm. In writing this patch I needed to answer the question, "Why does 
Coreutils currently insist on traversing d/e/f/g/ once for each source file, 
instead of just once for all the source files?" One cannot answer this question 
from the text of Coreutils' ChangeLog entries, even though these entries are 
reasonably well-written using the approved GNU style.

In contrast, the problem "I am looking for a specific change in a specific 
function" is not a big deal, as it is so easily addressed by "git blame" etc. 
that it's not worth the maintenance hassle of writing and maintaining and 
reading commit messages that laboriously list every function that's affected by 
every patch.

I'm not saying that commit messages should *never* mention file or function 
names; far from it. Just that our current style emphasizes them too much, and 
that we'd be better off spending our limited resources on commit messages that 
emphasize motivation instead of enumerating trivia.

 >    . the first priority should be to leave the explanation as comments
 >      in the code, if that is feasible, because then the commit explains
 >      itself, and the information is also available during simple code
 >      reading unrelated to VCS history searching;

Yes, that is preferable if it makes sense in the new code. However, it often 
doesn't make sense. For example, when deleting a file one typically does not 
want to leave a message behind where the file used to be, saying "this file was 
deleted", as that would just slow down later maintainers who normally shouldn't 
be burdened with the detritus of older versions.

 >    . if the change was discussed in some public forum, include the
 >      pointer to that discussion in the log message (bug number is a
 >      special case of this, but it's not the only one)

Very good advice.

Re: git history tracking across renames (and emacs support)

[Stefan Monnier]

> I'm not saying that commit messages should *never* mention file or function
> names; far from it. Just that our current style emphasizes them too much,
> and that we'd be better off spending our limited resources on commit
> messages that emphasize motivation instead of enumerating trivia.

Agreed.  I find the ChangeLog format is not a bad starting point, but
it tends to encourage paraphrasing the change instead of explaining it,
so we need to be careful to try and avoid that pitfall.

Also we need to "interpret" the ChangeLog guidelines in the context of
tools such as vc-region-history where we don't need to look through the
ChangeLog just to know when a given piece of code was modified.


        Stefan

Re: git history tracking across renames (and emacs support)

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Tue, 02 Jan 2018 22:24:57 -0500
> 
> Also we need to "interpret" the ChangeLog guidelines in the context of
> tools such as vc-region-history where we don't need to look through the
> ChangeLog just to know when a given piece of code was modified.

Let's not forget that we don't always have access to a VCS.  Moreover,
sometimes you are looking for information that is not easily gleaned
from Git history.  One example is establishing whether some change was
in Emacs XX.YY or in a later version.  Given our messy DAG and Git's
general indifference to branch-specific history, I find the
ChangeLog's in the tarball a better tool for this job.

Re: git history tracking across renames (and emacs support)

[Stefan Monnier]

> from Git history.  One example is establishing whether some change was
> in Emacs XX.YY or in a later version.

FWIW, I generally do that by comparing the change to the actual code of
Emacs-XX.YY.


        Stefan

Re: git history tracking across renames (and emacs support)

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: emacs-devel@gnu.org
> Date: Wed, 03 Jan 2018 13:20:18 -0500
> 
> > from Git history.  One example is establishing whether some change was
> > in Emacs XX.YY or in a later version.
> 
> FWIW, I generally do that by comparing the change to the actual code of
> Emacs-XX.YY.

How do you do that when XX.YY is not known in advance?  Check every
version of Emacs from the last one back?  That's not really efficient.

Re: git history tracking across renames (and emacs support)

[Stefan Monnier]

>> > from Git history.  One example is establishing whether some change was
>> > in Emacs XX.YY or in a later version.
>> FWIW, I generally do that by comparing the change to the actual code of
>> Emacs-XX.YY.
> How do you do that when XX.YY is not known in advance?  Check every
> version of Emacs from the last one back?  That's not really efficient.

I'm not saying it's the best way, just that it's the way I've done it so
far (I guess I could have used the ChangeLog, but it's just not part of
the things that cross my mind).  I haven't needed it very often and
usually I can guess from the change date what version it likely belongs
to, so I can't remember having had to look at more than 1 version (and
since I have Emacs versions 19.34, 20.7, 21.4, 22.3, 23.4, 24.5, and
25.2 readily installed on my machine, it's very easy to check for those
versions).


        Stefan

Re: git history tracking across renames (and emacs support)

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org
> Date: Wed, 03 Jan 2018 15:17:55 -0500
> 
> >> > from Git history.  One example is establishing whether some change was
> >> > in Emacs XX.YY or in a later version.
> >> FWIW, I generally do that by comparing the change to the actual code of
> >> Emacs-XX.YY.
> > How do you do that when XX.YY is not known in advance?  Check every
> > version of Emacs from the last one back?  That's not really efficient.
> 
> I'm not saying it's the best way, just that it's the way I've done it so
> far (I guess I could have used the ChangeLog, but it's just not part of
> the things that cross my mind).  I haven't needed it very often and
> usually I can guess from the change date what version it likely belongs
> to, so I can't remember having had to look at more than 1 version (and
> since I have Emacs versions 19.34, 20.7, 21.4, 22.3, 23.4, 24.5, and
> 25.2 readily installed on my machine, it's very easy to check for those
> versions).

So you remember when each release was made?  And also when the
corresponding release branch was cut?  If you remember all that, then
I understand why you don't need ChangeLog's.

And mind you, in my scenario many times the date of the change is not
given.  Rather, someone complains about something in version XX.YY,
and I suspect some feature/change, but don't have a clear idea whether
that feature/change was introduced before or after that version.

Re: git history tracking across renames (and emacs support)

[Stefan Monnier]

> So you remember when each release was made?

Wikipedia does (that's what I use to find that part of the information).

> And also when the corresponding release branch was cut?

If I know that the commit was before the release branch was cut, then
I don't even need to look at the final code.  But usually, I don't know
that and I don't know either on which branch the commit was installed.

That's the reason that I need to check the actual code of the release.

> And mind you, in my scenario many times the date of the change is not
> given.  Rather, someone complains about something in version XX.YY,
> and I suspect some feature/change, but don't have a clear idea whether
> that feature/change was introduced before or after that version.

I look at the feature's code, dig in with vc-region-history to get the
corresponding commit, and that gives me the date.

vc-region-history is almost always the first thing I use when it comes
to "commit/changelog" info.  And that's also where the subject of this
thread hurts (I sometimes resort to making a "git worktree add" to get
the revision before the file was moved, and use vc-region-history on
that to see the rest of the history).


        Stefan

Re: git history tracking across renames (and emacs support)

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Wed, 03 Jan 2018 17:02:03 -0500
> 
> I look at the feature's code, dig in with vc-region-history to get the
> corresponding commit, and that gives me the date.

That will only give you the latest change there.  For something before
that, you are back to the original problem.

> vc-region-history is almost always the first thing I use when it comes
> to "commit/changelog" info.  And that's also where the subject of this
> thread hurts (I sometimes resort to making a "git worktree add" to get
> the revision before the file was moved, and use vc-region-history on
> that to see the rest of the history).

I find all of those needed, but I also find ChangeLog to be of help.

Re: git history tracking across renames (and emacs support)

[Stefan Monnier]

>> I look at the feature's code, dig in with vc-region-history to get the
>> corresponding commit, and that gives me the date.
> That will only give you the latest change there.

No, it gives me the whole history (which is one of the main benefits
compared to "git blame": I'm not blinsided by cosmetic changes).


        Stefan

Re: git history tracking across renames (and emacs support)

[Eli Zaretskii]

On January 4, 2018 7:00:33 AM GMT+02:00, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> >> I look at the feature's code, dig in with vc-region-history to get
> the
> >> corresponding commit, and that gives me the date.
> > That will only give you the latest change there.
> 
> No, it gives me the whole history (which is one of the main benefits
> compared to "git blame": I'm not blinsided by cosmetic changes).
> 
> 
>         Stefan

Then you have back the problem with branches, since the changes
in the region will not tell you whether the change was merged or
backported etc.

Anyway, I don't really understand the point you are trying to make.  If you
are saying that ChangeLogs are _never_ useful in these situations,
then that's a strangely extremist view, and my experience is very far
from that.

Re: git history tracking across renames (and emacs support)

[Paul Eggert]

Eli Zaretskii wrote:
> If you
> are saying that ChangeLogs are_never_  useful in these situations,
> then that's a strangely extremist view

I doubt whether anybody is going that far. (Hand-illuminated manuscripts are 
occasionally useful too, but nobody is recommending them for maintaining Emacs. :-)

Although the current ChangeLog format is sometimes useful, nowadays it is an 
unnecessary luxury because so much of its benefit is now available via 
reasonably-effective VC tools, whereas its cost hasn't gone down (quite the 
reverse, I'd say). And I say that as someone who reads ChangeLogs quite a bit 
and who appreciates their occasional utility.

Re: git history tracking across renames (and emacs support)

[Stefan Monnier]

> Then you have back the problem with branches, since the changes
> in the region will not tell you whether the change was merged or
> backported etc.

As explained, this is the part of the info that vc-region-history can't
give me, and the reason why I instead have to look at the actual code of
a few releases (usually just one, but potentially more).

> Anyway, I don't really understand the point you are trying to make.
> If you are saying that ChangeLogs are _never_ useful in these
> situations, then that's a strangely extremist view, and my experience
> is very far from that.

I'm just pointing out that not only we *can* live without the
ChangeLog files, but that's exactly what I happen to do.


        Stefan

Re: git history tracking across renames (and emacs support)

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org
> Date: Thu, 04 Jan 2018 09:25:25 -0500
> 
> > Then you have back the problem with branches, since the changes
> > in the region will not tell you whether the change was merged or
> > backported etc.
> 
> As explained, this is the part of the info that vc-region-history can't
> give me, and the reason why I instead have to look at the actual code of
> a few releases (usually just one, but potentially more).

And as I explained, this method is less efficient than using
ChangeLog.

> > Anyway, I don't really understand the point you are trying to make.
> > If you are saying that ChangeLogs are _never_ useful in these
> > situations, then that's a strangely extremist view, and my experience
> > is very far from that.
> 
> I'm just pointing out that not only we *can* live without the
> ChangeLog files, but that's exactly what I happen to do.

And I'm pointing out that using ChangeLog files when they are useful
makes the quality of my life higher.

Re: git history tracking across renames (and emacs support)

[Dmitry Gutov]

On 1/4/18 8:00 AM, Stefan Monnier wrote:
>>> I look at the feature's code, dig in with vc-region-history to get the
>>> corresponding commit, and that gives me the date.
>> That will only give you the latest change there.
> 
> No, it gives me the whole history (which is one of the main benefits
> compared to "git blame": I'm not blinsided by cosmetic changes).

IME, the vc-annotate buffer is a bit more helpful. Yes, it lists 
cosmetic changes, but you can jump over them with 'a'.

And you can dig down with the same command, until you find the commit 
that is responsible for the change you're looking for. And you ignore 
the commits that don't touch the relevant lines this way.

Unlike the region history, where you're going to have to scroll through 
all commits that have ever touched any part of the function (if you 
selected the whole function, like you're recommending; but otherwise, 
you risk missing relevant changes, I think).

Re: git history tracking across renames (and emacs support)

[Stefan Monnier]

> IME, the vc-annotate buffer is a bit more helpful. Yes, it lists cosmetic
> changes, but you can jump over them with 'a'.

Interesting.  I find vc-annotate so frustrating compared to
vc-region-history that I tend to forget that some people may have
a different experience.

> Unlike the region history, where you're going to have to scroll through all
> commits that have ever touched any part of the function (if you selected the
> whole function, like you're recommending; but otherwise, you risk missing
> relevant changes, I think).

Usually I just select a handful of lines (rarely a whole
function,unless its small).


        Stefan

Re: git history tracking across renames (and emacs support)

[Alan Mackenzie]

Hello, Eli.

On Wed, Jan 03, 2018 at 17:36:31 +0200, Eli Zaretskii wrote:
> > From: Stefan Monnier <monnier@iro.umontreal.ca>
> > Date: Tue, 02 Jan 2018 22:24:57 -0500

> > Also we need to "interpret" the ChangeLog guidelines in the context of
> > tools such as vc-region-history where we don't need to look through the
> > ChangeLog just to know when a given piece of code was modified.

> Let's not forget that we don't always have access to a VCS.  Moreover,
> sometimes you are looking for information that is not easily gleaned
> from Git history.  One example is establishing whether some change was
> in Emacs XX.YY or in a later version.  Given our messy DAG and Git's
> general indifference to branch-specific history, I find the
> ChangeLog's in the tarball a better tool for this job.

I agree.  Frequently, I am looking for recent changes in a particular
function.  C-s in the ChangeLog is much more convenient than a git blame
(or several of them in succession) followed by remembering the hash of an
indicated change (or several of them), followed by a git show (or several
of them).

Let's please keep these individual function change descriptions in the VC
log (which will eventually become the ChangeLog).

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: git history tracking across renames (and emacs support)

[Stefan Monnier]

> I agree.  Frequently, I am looking for recent changes in a particular
> function.  C-s in the ChangeLog is much more convenient than a git blame
> (or several of them in succession) followed by remembering the hash of an
> indicated change (or several of them), followed by a git show (or several
> of them).

Hmm... could it be you haven't tried vc-region-history yet?

Try:

- put the region around the chunk of code of interest.
- hit C-x v h (or M-x vc-region-history if you use Emacs<26).
- enjoy pure bliss.

> Let's please keep these individual function change descriptions in the VC
> log (which will eventually become the ChangeLog).

I tend to agree, but the text after the ":" should focus much more on
the purpose of the change than on the description of the change itself.


        Stefan

Re: git history tracking across renames (and emacs support)

[Alan Mackenzie]

Hello, Stefan.

On Wed, Jan 03, 2018 at 17:45:27 -0500, Stefan Monnier wrote:
> > I agree.  Frequently, I am looking for recent changes in a
> > particular function.  C-s in the ChangeLog is much more convenient
> > than a git blame (or several of them in succession) followed by
> > remembering the hash of an indicated change (or several of them),
> > followed by a git show (or several of them).

> Hmm... could it be you haven't tried vc-region-history yet?

It could indeed.

> Try:

> - put the region around the chunk of code of interest.
> - hit C-x v h (or M-x vc-region-history if you use Emacs<26).
> - enjoy pure bliss.

Yes, thanks, that's nice.  Incidentally, the doc string for
vc-region-history is somewhat brief.

> > Let's please keep these individual function change descriptions in
> > the VC log (which will eventually become the ChangeLog).

> I tend to agree, but the text after the ":" should focus much more on
> the purpose of the change than on the description of the change itself.

I've been trying to do "motivational" commit messages for some while,
now.  Though, most of that has been in an explanatory paragraph below
the introductory line rather than in the description of each defun
change.  I think trying to explain the purpose of each individual change
might become things like "prevent doing <xxxx> with a nil argument",
which might not be much better than what we already have.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: git history tracking across renames (and emacs support)

[Stefan Monnier]

>> - enjoy pure bliss.
> Yes, thanks, that's nice.  Incidentally, the doc string for
> vc-region-history is somewhat brief.

Indeed.  Can you improve it?
To me what it does is "show me the history of a chunk of text, the way
I've been dreaming of ever since I tried to implement it for GNU Arch".

> I've been trying to do "motivational" commit messages for some while,
> now.  Though, most of that has been in an explanatory paragraph below
> the introductory line rather than in the description of each defun
> change.

That works as well, yes.

> I think trying to explain the purpose of each individual change
> might become things like "prevent doing <xxxx> with a nil argument",
> which might not be much better than what we already have.

Often it's not much better, indeed, but sometimes even that small
difference would be very appreciated years down the line.


        Stefan

Re: git history tracking across renames (and emacs support) (Was: The name gnus-cloud.el)

[Eli Zaretskii]

> Cc: rms@gnu.org, sb@dod.no, emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Tue, 2 Jan 2018 18:50:06 -0800
> 
> Eli Zaretskii wrote:
> 
> > If you are looking for a specific change in a specific function, then
> > ChangeLog style is exactly what you want.  If you are looking for
> > something else, why would you look at the log messages at all, instead
> > of using VCS commands related to history and forensics?
> 
> Because I am looking for *why* the code is the way it is, and ChangeLog entries 
> that emphasize function names are typically not that helpful.

I don't think ChangeLog style entries pretend to be the answer to such
questions.  ChangeLog files are supposed to be a concise log of
changes, nothing more, nothing less.

> For example, I'm currently working on a Coreutils patch so that "mv a b c 
> d/e/f/g/" will traverse the directories in d/e/f/g/ just once instead of three 
> times (once each for "a", "b", and "c"), thus reducing an O(N**2) to an O(N) 
> algorithm. In writing this patch I needed to answer the question, "Why does 
> Coreutils currently insist on traversing d/e/f/g/ once for each source file, 
> instead of just once for all the source files?" One cannot answer this question 
> from the text of Coreutils' ChangeLog entries, even though these entries are 
> reasonably well-written using the approved GNU style.

I very much doubt that such design-level information can be reasonably
well explained in commit log messages.  It should be a subject for a
relatively long and detailed commentary, i.e. part of the code.  Or,
if a package has an "internals" document, this kind of information
should be there.

> In contrast, the problem "I am looking for a specific change in a specific 
> function" is not a big deal, as it is so easily addressed by "git blame" etc. 

When you know the name of the function, the likes of "git annotate"
and "git log -L" might indeed frequently be what you want.
Frequently, but not always: I find ChangeLog's more convenient when I
need to know the date or the Emacs release where some specific change
appeared.  Git tools might be overkill here, and they need non-trivial
startup time before you can search anything.

>  >    . the first priority should be to leave the explanation as comments
>  >      in the code, if that is feasible, because then the commit explains
>  >      itself, and the information is also available during simple code
>  >      reading unrelated to VCS history searching;
> 
> Yes, that is preferable if it makes sense in the new code. However, it often 
> doesn't make sense. For example, when deleting a file one typically does not 
> want to leave a message behind where the file used to be, saying "this file was 
> deleted", as that would just slow down later maintainers who normally shouldn't 
> be burdened with the detritus of older versions.

Deleting a file or deleting some code without a trace is relatively
rare, but indeed this is one situation where comments are sometimes
inadequate, especially if all the change does is remove something (as
opposed to remove something in one place and add/modify another).

>  >    . if the change was discussed in some public forum, include the
>  >      pointer to that discussion in the log message (bug number is a
>  >      special case of this, but it's not the only one)
> 
> Very good advice.

I can say from my experience that I almost always find related
discussions around the date of a change, but looking for them is
tedious: we have 2 mailing lists, and until 10 years ago we had 3.  It
takes time to look in all of them, especially since it's not always
evident what search keywords to use.  Having references in the log
message makes this much easier.

Re: git history tracking across renames (and emacs support)

[Stefan Monnier]

> I very much doubt that such design-level information can be reasonably
> well explained in commit log messages.

In my experience, it is usually easy to write one's changelog such that
it explains some of the motivation for the change.  I often fail to do
it right, but that's mostly out of bad habit rather than because it's hard.


        Stefan

Re: git history tracking across renames (and emacs support)

[Stephen Leake]

Paul Eggert <eggert@cs.ucla.edu> writes:

> Eli Zaretskii wrote:
>
>>    . the first priority should be to leave the explanation as comments
>>      in the code, if that is feasible, because then the commit explains
>>      itself, and the information is also available during simple code
>>      reading unrelated to VCS history searching;
> Yes, that is preferable if it makes sense in the new code. However, it
> often doesn't make sense. For example, when deleting a file one
> typically does not want to leave a message behind where the file used
> to be, saying "this file was deleted", as that would just slow down
> later maintainers who normally shouldn't be burdened with the detritus
> of older versions.

Yes, but for design decisions, it is useful to keep comments that say
"an alternative design ... was rejected because ..." so when some bright
newbie suggests the alternative, they are easily detered (or forced to
make it even better).

Sometimes these comments belong in the elisp manual.

-- 
-- Stephe

Re: git history tracking across renames (and emacs support)

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

  > Yes, but for design decisions, it is useful to keep comments that say
  > "an alternative design ... was rejected because ..." so when some bright
  > newbie suggests the alternative, they are easily detered (or forced to
  > make it even better).

Based on my experience as a programmer, I concluded the right place
for that information is in comments in the code.

Programmers who decide to change to a new method of handling a certain
point don't always see a reason to consult the history, but they
always look at the code they are changing.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Skype: No way! See https://stallman.org/skype.html.

Re: git history tracking across renames (and emacs support) (Was: The name gnus-cloud.el)

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

  > > Was the whole history of our repository lost at that time ???

  > Not at all. It's still there.

That's a relief.

But even if we still have the old Bzr and CVS repos, the info from
them won't appear when you loook at the program's current Git repo.
So it is a good thing that we have the change log files from that era,
in the Git repo.


-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Skype: No way! See https://stallman.org/skype.html.

Re: git history tracking across renames (and emacs support)

[Stefan Monnier]

Richard Stallman <rms@gnu.org> writes:
> But even if we still have the old Bzr and CVS repos, the info from
> them won't appear when you loook at the program's current Git repo.

Yes, all that history has been painstakingly preserved (by ESR, if
I remember properly) when we converted to Git.

The imperfections in the Git history are mostly carried over from the
imperfection of the data in the CVS repository.

> So it is a good thing that we have the change log files from that era,
> in the Git repo.

Maybe it can be of use to some, but I can't remember the last time
I really used them.


        Stefan

Re: git history tracking across renames (and emacs support) (Was: The name gnus-cloud.el)

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

  > What would be most helpful (and I realize I'm asking for a lot) would be 
  > ChangeLog entries or commit messages (it doesn't matter which) that explain the 
  > *motivation* for each change.

Our current practice is to put the explanation into comments in the
code.  I think that makes it moe visible than in the history.

If you think it is better to put the explanation in the history?
could you explain what advantage you see?

You later wrote

  > Yes, that is preferable if it makes sense in the new
  > code. However, it often doesn't make sense. For example, when
  > deleting a file one typically does not want to leave a message
  > behind where the file used to be, saying "this file was deleted",
  > as that would just slow down later maintainers who normally
  > shouldn't

Indeed, you can't put a message in a deleted file.  But if that file
was not disused, I presume the same change includes code in other
files.  That's the best place to put the explanation.

But if there is no natural place for the explanation in the source
code, you should put it in the history.  If that's not clear enough
now, we can make it clearer.

======================================================================
For changes to code, there's no need to describe the full purpose of
the changes or how they work together.  If you think that a change
calls for explanation, you're probably right.  Please do explain
it---but please put the full explanation in comments in the code,
where people will see it whenever they see the code.  For example,
``New function'' is enough for the change log when you add a function,
because there should be a comment before the function definition to
explain what it does, how to call it, and so on.

For changes to files that do not support a comment syntax (e.g., media
files), it is ok to include the full explanation in the change log file,
after the title and before the list of individual changes.
======================================================================

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Skype: No way! See https://stallman.org/skype.html.

Re: git history tracking across renames (and emacs support) (Was: The name gnus-cloud.el)

[Paul Eggert]

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

Richard Stallman wrote:

>    > What would be most helpful (and I realize I'm asking for a lot) would be
>    > ChangeLog entries or commit messages (it doesn't matter which) that explain the
>    > *motivation* for each change.
> 
> Our current practice is to put the explanation into comments in the
> code.

Although that may be what the guidelines say, it's not done that often and it's 
often not worth doing. This is because code comments should explain the code, 
and not waste time explaining the code's history -- unless knowing the history 
is helpful for understanding the code's current state, which it's often not.

For example, I'm attaching a small Emacs patch I installed last month. If the 
guidelines really required us to put change descriptions into code commentary, 
the patch should have changed the declaration in src/sysdep.c to look something 
like this:

   /* This variable used to be extern, but is static now.  */
   static pthread_t main_thread_id;

But such a comment would have been silly, as it would record a fact that is 
irrelevant to how Emacs works today, and this historical footnote would take up 
valuable real estate on the screens of today's maintainers for no good reason.

> But if there is no natural place for the explanation in the source
> code, you should put it in the history.

That's too weak, as the example comment above should not be added to the code 
even though it is in the natural place for the explanation.

> ======================================================================
> For changes to code, there's no need to describe the full purpose of
> the changes or how they work together.  If you think that a change
> calls for explanation, you're probably right.  Please do explain
> it---but please put the full explanation in comments in the code,

This is too strong. That last sentence should begin like this instead:

"Please do explain it---but please put the full explanation of the new code in 
comments in the code,"

> where people will see it whenever they see the code.  For example,

and here, after "see the code", insert:

", and please limit the ChangeLog entry to non-obvious change-related aspects 
that do not appear in the new code's comments"

> ``New function'' is enough for the change log when you add a function,
> because there should be a comment before the function definition to
> explain what it does, how to call it, and so on.



[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Make-main_thread_id-private.patch --]
[-- Type: text/x-patch; name="0001-Make-main_thread_id-private.patch", Size: 1232 bytes --]

From d87bdd2f8a5da117e5e4d7ea0c26de0f91c424f2 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Sun, 24 Dec 2017 11:29:36 -0800
Subject: [PATCH] Make main_thread_id private

* src/sysdep.c (main_thread_id) [FORWARD_SIGNAL_TO_MAIN_THREAD]:
Now static.
---
 src/sysdep.c    | 2 +-
 src/syssignal.h | 1 -
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/sysdep.c b/src/sysdep.c
index e223a67..9522aa4 100644
--- a/src/sysdep.c
+++ b/src/sysdep.c
@@ -1671,7 +1671,7 @@ emacs_sigaction_init (struct sigaction *action, signal_handler_t handler)
 }
 
 #ifdef FORWARD_SIGNAL_TO_MAIN_THREAD
-pthread_t main_thread_id;
+static pthread_t main_thread_id;
 #endif
 
 /* SIG has arrived at the current process.  Deliver it to the main
diff --git a/src/syssignal.h b/src/syssignal.h
index 61e1c5f..b43a256 100644
--- a/src/syssignal.h
+++ b/src/syssignal.h
@@ -32,7 +32,6 @@ extern void unblock_tty_out_signal (sigset_t const *);
 
 #ifdef HAVE_PTHREAD
 #include <pthread.h>
-extern pthread_t main_thread_id;
 /* If defined, asynchronous signals delivered to a non-main thread are
    forwarded to the main thread.  */
 #define FORWARD_SIGNAL_TO_MAIN_THREAD
-- 
2.7.4

Re: git history tracking across renames (and emacs support) (Was: The name gnus-cloud.el)

[Eli Zaretskii]

> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Sun, 7 Jan 2018 20:22:28 -0800
> Cc: sb@dod.no, emacs-devel@gnu.org
> 
> > Our current practice is to put the explanation into comments in the
> > code.
> 
> Although that may be what the guidelines say, it's not done that often and it's 
> often not worth doing. This is because code comments should explain the code, 
> and not waste time explaining the code's history -- unless knowing the history 
> is helpful for understanding the code's current state, which it's often not.
> 
> For example, I'm attaching a small Emacs patch I installed last month. If the 
> guidelines really required us to put change descriptions into code commentary, 
> the patch should have changed the declaration in src/sysdep.c to look something 
> like this:
> 
>    /* This variable used to be extern, but is static now.  */
>    static pthread_t main_thread_id;
> 
> But such a comment would have been silly, as it would record a fact that is 
> irrelevant to how Emacs works today, and this historical footnote would take up 
> valuable real estate on the screens of today's maintainers for no good reason.

Actually, that's not the reason why this comment would be silly.  It
would be silly because there's no need to explain why a certain
variable is static.  Also, when/if someone looks at the diffs, they
will see exactly what the comment says, so the comment doesn't add any
useful information.

If you somehow understood what Richard said to mean we need to add
useless comments, then I'm sure we could clarify that comments should
add useful information.  (I thought it was obvious, but that's me.)

Re: git history tracking across renames (and emacs support) (Was: The name gnus-cloud.el)

[Paul Eggert]

On 01/08/2018 10:30 AM, Eli Zaretskii wrote:
> there's no need to explain why a certain variable is static.
Sometimes there is, sometimes there isn't. If it's important enough to 
mention the change from extern to static in the commit message, the 
current guidelines would seem to imply that it's important enough to 
mention why the change was made in code comments.

Another possibility would be to say that trivial changes like this one 
(where the change and its intent are obvious-enough from the diff) don't 
need to be mentioned in the ChangeLog. That would be OK.

Re: git history tracking across renames (and emacs support) (Was: The name gnus-cloud.el)

[Eli Zaretskii]

> Cc: rms@gnu.org, sb@dod.no, emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Mon, 8 Jan 2018 10:41:34 -0800
> 
> Another possibility would be to say that trivial changes like this one 
> (where the change and its intent are obvious-enough from the diff) don't 
> need to be mentioned in the ChangeLog.

That'd be a step backward because then there won't be any reasonable
way of finding out when that change was made, except by finding a
machine with a reasonably fast Internet connection and/or where
there's already a cloned Git repository (or some other similar option
that is not always available in Real Life).

Re: git history tracking across renames (and emacs support) (Was: The name gnus-cloud.el)

[Paul Eggert]

On 01/08/2018 11:13 AM, Eli Zaretskii wrote:
> there won't be any reasonable
> way of finding out when that change was made, except by finding a
> machine with a reasonably fast Internet connection and/or where
> there's already a cloned Git repository (or some other similar option
> that is not always available in Real Life).

Nowadays, I would not consider doing nontrivial development on Emacs 
without having a Git repository available. (This does not require an 
Internet connection, just a copy of the repository; I commonly work this 
way.) These days, serious hacking without the repository would be like 
hacking without the ChangeLog files would have been in the old days. 
It'd be like hacking with one arm tied behind one's back, and it's not 
something that we need to cater to.

Re: git history tracking across renames (and emacs support) (Was: The name gnus-cloud.el)

[Eli Zaretskii]

> Cc: rms@gnu.org, sb@dod.no, emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Mon, 8 Jan 2018 11:29:27 -0800
> 
> Nowadays, I would not consider doing nontrivial development on Emacs 
> without having a Git repository available. (This does not require an 
> Internet connection, just a copy of the repository; I commonly work this 
> way.) These days, serious hacking without the repository would be like 
> hacking without the ChangeLog files would have been in the old days. 
> It'd be like hacking with one arm tied behind one's back, and it's not 
> something that we need to cater to.

That's all very far from my everyday's experience.  Let's just agree
that ChangeLog files are useful for some of us.

Re: git history tracking across renames (and emacs support) (Was: The name gnus-cloud.el)

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

  > If it's important enough to 
  > mention the change from extern to static in the commit message, the 
  > current guidelines would seem to imply that it's important enough to 
  > mention why the change was made in code comments.

Here's what the standard actually says:

      If you think that a change
    calls for explanation, you're probably right.  Please do explain
    it---but please put the full explanation in comments in the code,
    where people will see it whenever they see the code.

So you're criticizing a practice which is NOT our standard.

Note also that it talks about "explanation".  We recommend such
comments, NOT to state the facts of what changed, but to explain the
reasons for the change _when that seems useful to explain_.

Our advice does NOT suggest adding a comment to state the fact that
the variable was changed to static.  However, if the reason for this
change was not evident, it would be good to explain that reason in
comments.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Skype: No way! See https://stallman.org/skype.html.

Re: git history tracking across renames (and emacs support) (Was: The name gnus-cloud.el)

[Paul Eggert]

Richard Stallman wrote:
>    > If it's important enough to
>    > mention the change from extern to static in the commit message, the
>    > current guidelines would seem to imply that it's important enough to
>    > mention why the change was made in code comments.
> 
> Here's what the standard actually says:
> 
>        If you think that a change
>      calls for explanation, you're probably right.  Please do explain
>      it---but please put the full explanation in comments in the code,
>      where people will see it whenever they see the code.
> 
> So you're criticizing a practice which is NOT our standard.

I didn't think that particular change required any description or explanation. 
That is, the change and its intent was obvious from the diff, and I put 
something into the commit message (aka ChangeLog entry) only because the coding 
standards required it. If commit messages are not required for trivial changes, 
it'd be helpful for the coding standards to say so, as this will save us some 
unnecessary work.

Re: git history tracking across renames (and emacs support) (Was: The name gnus-cloud.el)

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

  > I didn't think that particular change required any description or explanation. 

Description and explanation are two different issues.  Please don't
treat them as the same -- if you do that, we are miscommunicating.

Under our current practices, this change required a description in the
history.  It did not need a written explanation anywhere.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Skype: No way! See https://stallman.org/skype.html.

Re: git history tracking across renames (and emacs support) (Was: The name gnus-cloud.el)

[Paul Eggert]

Richard Stallman wrote:
> Description and explanation are two different issues.  Please don't
> treat them as the same -- if you do that, we are miscommunicating.

I'm afraid that this miscommunication is endemic to the coding standards, which 
lump description and explanation together. For example, "Change Log Concepts" 
currently starts like this (*emphasis* added):

"You can think of the change log as a conceptual “undo list” which *explains* 
how earlier versions were different from the current version. People can see the 
current version; they don’t need the change log to tell them what is in it. What 
they want from a change log is a clear *explanation* of how the earlier version 
differed. Each entry in a change log *describes* either an individual change or 
the smallest batch of changes that belong together ..."


The above text uses "explains", "explanation", and "description" for the same 
thing, namely the change log entry. It is not at all clear from this text that 
the example change that I gave needs a description and not an explanation.

More generally, if a fact is obvious from the diff listing, the fact needn't 
appear in the change log entry (and this is true regardless of whether the fact 
is described or explained). People who are curious about the fact can look at 
the diff listing and easily figure it out.

Re: git history tracking across renames (and emacs support) (Was: The name gnus-cloud.el)

[Eli Zaretskii]

> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Wed, 10 Jan 2018 00:22:04 -0800
> Cc: eliz@gnu.org, sb@dod.no, emacs-devel@gnu.org
> 
> More generally, if a fact is obvious from the diff listing, the fact needn't 
> appear in the change log entry (and this is true regardless of whether the fact 
> is described or explained). People who are curious about the fact can look at 
> the diff listing and easily figure it out.

Don't forget that this requires an easy access to the diffs, which in
practice means a Git repository nearby.

Re: git history tracking across renames (and emacs support)

[Stefan Monnier]

> Don't forget that this requires an easy access to the diffs, which in
> practice means a Git repository nearby.

FWIW, I think we should design the system for the case where the
user *does* have the VCS history at hand.

Those users who don't have the VCS history available are by definition
at a disadvantage but we don't need to do anything special to help them,
since there's already a trivial solution for that (i.e. getting the VCS
history).

It's perfectly OK for someone to decide to hack on Emacs starting from
a tarball rather than from a Git tree, but then this user gets what he
asked for.


        Stefan

Re: git history tracking across renames (and emacs support)

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Thu, 11 Jan 2018 17:08:51 -0500
> 
> FWIW, I think we should design the system for the case where the
> user *does* have the VCS history at hand.

We already do that.

> It's perfectly OK for someone to decide to hack on Emacs starting from
> a tarball rather than from a Git tree, but then this user gets what he
> asked for.

Since I'm frequently in that situation, I don't want to be
disadvantaged like that, especially since keeping the ChangeLog files
nowadays means a barely tangible effort from the project.

IOW, the color of this particular bike shed can stay as it is, without
anyone being unnecessarily at a disadvantage.

Re: git history tracking across renames (and emacs support)

[Paul Eggert]

Eli Zaretskii wrote:
>> It's perfectly OK for someone to decide to hack on Emacs starting from
>> a tarball rather than from a Git tree, but then this user gets what he
>> asked for.
> Since I'm frequently in that situation,

How so? I'm almost never in that situation.

Do you download distribution tarballs and hack on them directly? If not, how do 
you end up with development copies of Emacs without having a repository near to 
hand?

> keeping the ChangeLog files
> nowadays means a barely tangible effort from the project.

We're not talking about removing the existing ChangeLog files. We're talking 
about what should be put into commit messages from here on out. That is an 
ongoing and nontrivial maintenance effort, and if we can ease the burden of 
writing commit messages then that will be a win.

Re: git history tracking across renames (and emacs support)

[Stefan Monnier]

> We're not talking about removing the existing ChangeLog files.

Indeed.

> We're talking about what should be put into commit messages from here
> on out.  That is an ongoing and nontrivial maintenance effort, and if
> we can ease the burden of writing commit messages then that will be
> a win.

I'm not particularly concerned about "easing the burden", but rather
about improving the quality: when the commit message just paraphrases
the diff, the commit message is not very useful and would benefit from
being rephrased so as to give more information about the
intention/motivation behind the change (information not readily
available from the diff).


        Stefan

Re: git history tracking across renames (and emacs support)

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sat, 13 Jan 2018 00:13:13 -0500
> 
> I'm not particularly concerned about "easing the burden", but rather
> about improving the quality: when the commit message just paraphrases
> the diff, the commit message is not very useful

Since ChangeLog is generated from Git log, it _is_ useful when all you
have is the ChangeLog.  Which could happen if, for example, you want
to work on Emacs while off-line during a long flight.

> and would benefit from being rephrased so as to give more
> information about the intention/motivation behind the change
> (information not readily available from the diff).

I already suggested near the beginning of this bike-shedding the way
of making the reasons more visible.  What we need is to have more
people, including the veteran contributors, write better commentary
for their changes, and then we'll be just fine.  Commit log messages
are not the best place for this information, and should be used only
as the last resort.

Re: git history tracking across renames (and emacs support)

[Tim Landscheidt]

Eli Zaretskii <eliz@gnu.org> wrote:

>> I'm not particularly concerned about "easing the burden", but rather
>> about improving the quality: when the commit message just paraphrases
>> the diff, the commit message is not very useful

> Since ChangeLog is generated from Git log, it _is_ useful when all you
> have is the ChangeLog.  Which could happen if, for example, you want
> to work on Emacs while off-line during a long flight.

> […]

Especially for long offline durations I find Git simply won-
derful: You don't just have the tar balls you have download-
ed prior to going offline, you have essentially all of them.
And when you want to pull a patch from another user's repo-
sitory or something similar, Git will minimize the data vol-
ume transferred.  Combined with GNU's habit of including all
relevant documentation in the source repository (and not in
another or on some web site only available by http), this
makes GNU software simply a treat to develop for.

Tim

Re: git history tracking across renames (and emacs support)

[Stefan Monnier]

> Since ChangeLog is generated from Git log, it _is_ useful when all you
> have is the ChangeLog.  Which could happen if, for example, you want
> to work on Emacs while off-line during a long flight.

I very often work off-line, but Git gives me just as much info in that case.


        Stefan

Re: git history tracking across renames (and emacs support)

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: emacs-devel@gnu.org
> Date: Sat, 13 Jan 2018 12:42:20 -0500
> 
> > Since ChangeLog is generated from Git log, it _is_ useful when all you
> > have is the ChangeLog.  Which could happen if, for example, you want
> > to work on Emacs while off-line during a long flight.
> 
> I very often work off-line, but Git gives me just as much info in that case.

That depends on the job you need to do.  Having outdated Git
repository for prolonged amounts of time is not recommended.

Re: git history tracking across renames (and emacs support)

[Stefan Monnier]

>> > Since ChangeLog is generated from Git log, it _is_ useful when all you
>> > have is the ChangeLog.  Which could happen if, for example, you want
>> > to work on Emacs while off-line during a long flight.
>> I very often work off-line, but Git gives me just as much info in that case.
> That depends on the job you need to do.  Having outdated Git
> repository for prolonged amounts of time is not recommended.

The question under discussion is what to put in ChangeLogs and
commit messages.  Fetching new changes (and corresponding commit
messages) is an orthogonal problem.


        Stefan

Re: git history tracking across renames (and emacs support)

[Paul Eggert]

Stefan Monnier wrote:
> I very often work off-line, but Git gives me just as much info in that case.

Likewise. I am simply mystified by the assertion that offline developers can't 
easily use Git. Git works very well in offline environments.

Eli Zaretskii wrote:
 > Not everyone spends his/her office hours in academic environments.

Although years ago academics often had better hardware for Emacs hacking, that's 
no longer the case. I do most of my GNU-related development on my own time on a 
personal desktop and laptop that I bought with my own money, and these machines 
are considerably better than the desktop in my office at UCLA. Git works better 
on my personal machines than it does on my UCLA-supplied equipment.

Re: git history tracking across renames (and emacs support)

[Eli Zaretskii]

> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Sat, 13 Jan 2018 11:35:34 -0800
> 
>  > Not everyone spends his/her office hours in academic environments.
> 
> Although years ago academics often had better hardware for Emacs hacking

You simply misunderstood me: I didn't mean the hardware.

Re: git history tracking across renames (and emacs support)

[Paul Eggert]

Eli Zaretskii wrote:
> You simply misunderstood me: I didn't mean the hardware.

Then I'm afraid you weren't clear. I don't know why academic environments would 
be significantly different from home environments when it comes to Emacs hacking 
in general or Git support in particular.

Even in places where network connectivity is limited, I don't see why a serious 
Emacs hacker would intentionally avoid the Git repository and instead download 
and manipulate tarballs by hand. Git doesn't need constant network connectivity, 
and its benefit (in terms of examining and managing Emacs history) far exceeds 
the few minutes of delay in the initial download.

Re: git history tracking across renames (and emacs support)

[Eli Zaretskii]

> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Sat, 13 Jan 2018 12:22:03 -0800
> Cc: emacs-devel@gnu.org
> 
> Even in places where network connectivity is limited, I don't see why a serious 
> Emacs hacker would intentionally avoid the Git repository and instead download 
> and manipulate tarballs by hand.

You will have to believe me that I have my reasons, and they are good
ones.

Re: git history tracking across renames (and emacs support)

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Fri, 12 Jan 2018 18:33:32 -0800
> 
> Eli Zaretskii wrote:
> >> It's perfectly OK for someone to decide to hack on Emacs starting from
> >> a tarball rather than from a Git tree, but then this user gets what he
> >> asked for.
> > Since I'm frequently in that situation,
> 
> How so? I'm almost never in that situation.

To each one their own.  Not everyone spends his/her office hours in
academic environments.

> Do you download distribution tarballs and hack on them directly? If not, how do 
> you end up with development copies of Emacs without having a repository near to 
> hand?

For some value of "near", I do.  But that's not near enough to make
consulting the repository a practical part of my workflow in those
cases.

> > keeping the ChangeLog files
> > nowadays means a barely tangible effort from the project.
> 
> We're not talking about removing the existing ChangeLog files. We're talking 
> about what should be put into commit messages from here on out.

As long as ChangeLog is generated from Git log, we _are_ talking about
ChangeLog as well.

> That is an ongoing and nontrivial maintenance effort

You are exaggerating.

Re: git history tracking across renames (and emacs support) (Was: The name gnus-cloud.el)

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

  > I'm afraid that this miscommunication is endemic to the coding
  > standards, which lump description and explanation together.

You are right.

I just went through and clarified that, and encouraged
longer overall descriptions of what has changed.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Skype: No way! See https://stallman.org/skype.html.

Re: git history tracking across renames (and emacs support) (Was: The name gnus-cloud.el)

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

  > This is because code comments should explain the code, 
  > and not waste time explaining the code's history

Comments should state whatever will help future developers
do a good job.  If it's important for them to know why the code
should work this way, rather than some other way which was tried
in the past, then it's appropriate to explain in a comment.

  >    /* This variable used to be extern, but is static now.  */
  >    static pthread_t main_thread_id;

  > But such a comment would have been silly, 

As I explain in another message today, we don't suggest including
that silly comment.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Skype: No way! See https://stallman.org/skype.html.

Re: git history tracking across renames (and emacs support)

[Steinar Bang]

>>>>> Richard Stallman <rms@gnu.org>:

>> If the result you pointed at is the case for all bzr moves converted to
>> git, then history tracking was lost at that point, and there isn't
>> really anything to do about it.

> Was the whole history of our repository lost at that time ???

No commits in the history of the repositor would have been lost.

But tracking the history of a file through renames would not be present.

(note that one wouldn't be worse off by this, than the regular state of
things in CVS)

Re: git history tracking across renames (and emacs support)

[Stefan Monnier]

> (well,.. except for inconsistent support across git commands and
> missing tool support, that is...).

That's the main problem, in my experience.

E.g. try to use `C-x v ~` or something similar to extract an old version
of a file FOO (old enough that the file was named BAR at that point).
For extra credit, do that when some *other* file exists with name FOO in
that old revision .


        Stefan

Re: The name gnus-cloud.el

[Karl Fogel]

Eli Zaretskii <eliz@gnu.org> writes:
>> From: Steinar Bang <sb@dod.no>
>> 2007?  Was that still CVS?  Or was that during bazaar?
>
>It was Bazaar.

Actually, 2007 was still CVS.  The switch to Bazaar happened in 2008.  Here's some evidence:

  https://lists.nongnu.org/archive/html/emacs-devel/2008-03/msg00228.html

Best regards,
-Karl

Re: The name gnus-cloud.el

[Chad Brown]

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

Is there any way to patch up the git history for cases like this (absolutely not a git expert)? I know that we don’t want to edit history in general, but if there are a set of specific issues liek this, it might be worth a batch change.

~Chad

> On 31Dec, 2017, at 20:42, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Steinar Bang <sb@dod.no>
>> Date: Mon, 01 Jan 2018 02:05:27 +0100
>> 
>>>>>>> Andreas Schwab <schwab@linux-m68k.org>:
>> 
>>> On Dez 31 2017, Óscar Fuentes <ofv@wanadoo.es> wrote:
>>>> Most likely, the migration tool didn't bother to perform a `git mv
>>>> <from> <to>' and did the equivalent of `cp <from> <to>; git rm <from>;
>>>> git add <to>' instead.
>> 
>>> No, that's exactly the same operation.  The problem is that commit
>>> b8d4c8d0e9 didn't rename anything.
>> 
>> Yep.  This commit only adds that file, and doesn't remove the existing
>> file
> 
> The file was removed in the previous commit.
> 
>> 2007?  Was that still CVS?  Or was that during bazaar?
> 
> It was Bazaar.
> 
>> How did bazaar track renames?
> 
> Bazaar did track renames, but that commit didn't use "bzr mv".
> 
>> How was bazaar renames handled during the conversion to git?
> 
> I have no idea, but you see the results in the Git repository.


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

Re: The name gnus-cloud.el

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

  > RS> How about gnus-noncloud.el?
  > RS> That would make the joke clearer so we could all get it.

  > That would make the humor more nebulous though.

A nebulous joke is better than an invisible joke ;-).
How about gnus-nebulous.el?


-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Skype: No way! See https://stallman.org/skype.html.

Re: The name gnus-cloud.el

[John Wiegley]

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

>>>>> "RS" == Richard Stallman <rms@gnu.org> writes:

RS> Is anyone else here concerned about the name of that file?

I have no issue with the name gnus-cloud.el. Given the modern era, it has come
to simply mean "The data lives on someone else's computer". I don't see any
negative connotations, or misleading meaning.The data is just using Gnus to
put the data "somewhere else", and being what Gnus is, that somewhere else
happens to be an IMAP server (though really, it could be anywhere at all,
you're just using Gnus as an interface to fetch it as though it were on a
news/mail server).

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

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

Re: The name gnus-cloud.el

[Eli Zaretskii]

On December 19, 2017 8:09:59 AM GMT+02:00, John Wiegley <johnw@gnu.org> wrote:
> >>>>> "RS" == Richard Stallman <rms@gnu.org> writes:
> 
> RS> Is anyone else here concerned about the name of that file?
> 
> I have no issue with the name gnus-cloud.el. Given the modern era, it
> has come
> to simply mean "The data lives on someone else's computer". I don't
> see any
> negative connotations, or misleading meaning.The data is just using
> Gnus to
> put the data "somewhere else", and being what Gnus is, that somewhere
> else
> happens to be an IMAP server (though really, it could be anywhere at
> all,
> you're just using Gnus as an interface to fetch it as though it were
> on a
> news/mail server).

AFAIU, what you say is not the issue.  No one asked to change what gnus-cloud _does_.  The issue at hand is just the _name_ of the file, and that makes very little sense to me.

Re: The name gnus-cloud.el

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

  > I have no issue with the name gnus-cloud.el. Given the modern era, it has come
  > to simply mean "The data lives on someone else's computer".

I wish it had such a simple and clear meaning.  Please look at
https://gnu.org/philosophy/words-to-avoid.html#CloudComputing for the
explanation of why the term "cloud"'s confusion has real influence and
harmful effects.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Skype: No way! See https://stallman.org/skype.html.

Re: The name gnus-cloud.el

[joakim]

Richard Stallman <rms@gnu.org> writes:

> [[[ 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. ]]]
>
>   > I had some followups, last one:
>   > https://lists.gnu.org/archive/html/emacs-devel/2016-07/msg00617.html
>
> I looked at the old conversation.  It was said that the name
> gnus-cloud.el was a joke.  I asked, what is the joke, and no one said.
>
> Now that the file is installed, I can look at it.  I don't see
> anything in the file that is evidently a joke.  What is the joke?
>
> Back then, you said,
>
>     OK, I'll let you and Lars and the maintainers figure it out. Let's do
>     the rename, if that's the decision, after the current gnus-cloud code is
>     reviewed and merged, or it will get confusing (because the feature
>     branch currently removes the old gnus-sync.el).
>
> That time has now arrived.
>
> The file starts with this:
>
> ;;; gnus-cloud.el --- storing and retrieving data via IMAP
>
> So how about renaming it to gnus-imap.el?  That name is clear and fits
> what the program does.
>
> Or perhaps gnus-imap-sync.el; it would say more about what functionality
> the file provides.

I don't have an opininon about what this file should be named.

I can offer a small datapoint about the connotation of the word "cloud"
in the segment I work in. The "cloud" is something to be feared and
avoided, especially since the advent of the european GDPR
legislation. The term "on premise cloud", where an organization has its
own servers, does have a positive connotation though.

-- 
Joakim Verona
joakim@verona.se
+46705459454