Re: trunk r113639: Fix typos in ChangeLogs.

Re: trunk r113639: Fix typos in ChangeLogs.

[Michael Albinus]

Juanma Barranquero <lekktu@gmail.com> writes:

Hi Juanma,

> === modified file 'lisp/ChangeLog'
> --- a/lisp/ChangeLog	2013-08-01 18:46:10 +0000
> +++ b/lisp/ChangeLog	2013-08-01 22:53:03 +0000
> @@ -15,8 +15,8 @@
>  	(tramp-handle-file-notify-rm-watch): New functions.
>  	(tramp-call-process): Do not bind `default-directory'.
>
> -	* net/tramp-adb.el (tramp-adb-file-name-handler-alist): Order
> -	alphabetically.
> +	* net/tramp-adb.el (tramp-adb-file-name-handler-alist):
> +	Order alphabetically.
>  	[access-file, add-name-to-file, dired-call-process]:
>  	[dired-compress-file, file-acl, file-notify-rm-watch]:
>  	[file-ownership-preserved-p, file-selinux-context]:

I really appreciate your effort to keep things clean. However, often you
(must) change entries in ChangeLog, which have been inserted by
automatic filling the lines. Shouldn't we rather adapt `change-log-mode'?

Best regards, Michael.

Re: trunk r113639: Fix typos in ChangeLogs.

[Juanma Barranquero]

On Fri, Aug 2, 2013 at 8:28 AM, Michael Albinus <michael.albinus@gmx.de> wrote:

> I really appreciate your effort to keep things clean. However, often you
> (must) change entries in ChangeLog, which have been inserted by
> automatic filling the lines. Shouldn't we rather adapt `change-log-mode'?

I don't think these changes can be automated.  Entries of the form

   * somefile.el (somefunc): Word
   and more words.

look better as

   * somefile.el (somefunc):
   Word and more words.

but there are cases where that's not so. It's a subjective call, so
that's why only some of us take the effort to do it (I seem to
remember Stefan said that he even has a font-locking regexp to
highlight such cases in ChangeLogs ;-).

   J

Re: trunk r113639: Fix typos in ChangeLogs.

[Michael Albinus]

Juanma Barranquero <lekktu@gmail.com> writes:

> I don't think these changes can be automated.  Entries of the form
>
>    * somefile.el (somefunc): Word
>    and more words.
>
> look better as
>
>    * somefile.el (somefunc):
>    Word and more words.

And even better:

   * somefile.el (somefunc): Word and more words.

> but there are cases where that's not so. It's a subjective call, so
> that's why only some of us take the effort to do it (I seem to
> remember Stefan said that he even has a font-locking regexp to
> highlight such cases in ChangeLogs ;-).

We won't get 100% satisfaction. But I have the feeling, that we could do
better than now.

Unfortunately, I'm a n00b wrt paragraph filling ...

>    J

Best regards, Michael.

Re: trunk r113639: Fix typos in ChangeLogs.

[Juanma Barranquero]

On Fri, Aug 2, 2013 at 12:04 PM, Michael Albinus <michael.albinus@gmx.de> wrote:

> And even better:
>
>    * somefile.el (somefunc): Word and more words.

Sure, but I used a short example because of laziness; of course I meant

        * somefile.el (somelongfuncname, someother, yetanother): One
       word all alone in the night.

> We won't get 100% satisfaction. But I have the feeling, that we could do
> better than now.

Oh, I'm sure we can do better. The question is, enough to make any
added complexity worthwhile?

    J

Re: trunk r113639: Fix typos in ChangeLogs.

[Glenn Morris]

BTW, choice of a different filling convention is not a "typo" IMO.

Re: trunk r113639: Fix typos in ChangeLogs.

[Juanma Barranquero]

> BTW, choice of a different filling convention is not a "typo" IMO.

Of course not. I never change filling convention as a typo fix, though
every now and then I refill some entries while fixing real typos. The
"Fix typos" in the commit log message refers to the real typos, not
the refills. I could use "Fix typos; refill some entries", if you
want, though I try to be as short as possible because these are all
trivial changes, and the less noise, the better.

(Now that I think of it, VCS' commits and log commands should have an
option like MediaWiki's "trivial changes", so they don't appear on
listings unless explicitly requested...; and, as the flag would be is
strictly metadata, it should be possible to switch it in case of error
without affecting the commit in any way...)

   J