vc-next-action RCS vs hg: copies the entry of ChangeLog

vc-next-action RCS vs hg: copies the entry of ChangeLog

[Uwe Brauer]

Hi

Switching from RCS to HG I noted a difference.

If in RCS I run vc-next-action for checking in, Emacs copies into the
vc-log the content of the most recent ChangeLog. Using the HG backend
this behaviour is absent. Any possibility to enable it?

Thanks

Uwe Brauer 

Re: vc-next-action RCS vs hg: copies the entry of ChangeLog

[Dmitry Gutov]

On 10/15/2015 09:48 AM, Uwe Brauer wrote:

> If in RCS I run vc-next-action for checking in, Emacs copies into the
> vc-log the content of the most recent ChangeLog. Using the HG backend
> this behaviour is absent. Any possibility to enable it?

Works for me. Feel free to file a bug with full repro.

Re: vc-next-action RCS vs hg: copies the entry of ChangeLog

[Uwe Brauer]

>>> "Dmitry" == Dmitry Gutov <dgutov@yandex.ru> writes:

   > On 10/15/2015 09:48 AM, Uwe Brauer wrote:
   >> If in RCS I run vc-next-action for checking in, Emacs copies into the
   >> vc-log the content of the most recent ChangeLog. Using the HG backend
   >> this behaviour is absent. Any possibility to enable it?

   > Works for me. Feel free to file a bug with full repro.


Do you mean that if you use vc-log-print you see the content of the ChangeLog?

Re: vc-next-action RCS vs hg: copies the entry of ChangeLog

[Dmitry Gutov]

On 10/18/2015 10:02 AM, Uwe Brauer wrote:

> Do you mean that if you use vc-log-print you see the content of the ChangeLog?

I mean that when I make changes to a Hg-controlled file, save, add an 
entry to the nearby ChangeLog file, switch back to the source file and 
press `C-x v v', the entry from the ChangeLog file is added to the 
opened buffer (where you edit the commit message).

I haven't actually tried committing and then looking at the log, but why 
wouldn't it be there?

Re: vc-next-action RCS vs hg: copies the entry of ChangeLog

[Uwe Brauer]

>>> "Dmitry" == Dmitry Gutov <dgutov@yandex.ru> writes:

    > On 10/18/2015 10:02 AM, Uwe Brauer wrote:
    >> Do you mean that if you use vc-log-print you see the content of the ChangeLog?

    > I mean that when I make changes to a Hg-controlled file, save, add
    > an entry to the nearby ChangeLog file, switch back to the source
    > file and press `C-x v v', the entry from the ChangeLog file is
    > added to the opened buffer (where you edit the commit message).

This is also my case!

> I haven't actually tried committing and then looking at the log, but
> why wouldn't it be there?


Well I just repeated your steps and then run a vc-print-log to see


changeset:   34:8d6c1d9fcc44
branch:      banch-pub
tag:         tip
user:        Uwe Brauer <oub@mat.ucm.es>
date:        Sun Oct 18 11:21:55 2015 +0300
summary:     try out


But the change log contains
2015-10-18  Uwe Brauer  <oub@mat.ucm.es>

	* section-0002.tex (subsection{Weight._Sobol._fract._order_their}
	{} {}):
	test

Which is *not* displayed.

It is displayed if the file is under RCS!

Re: vc-next-action RCS vs hg: copies the entry of ChangeLog

[Dmitry Gutov]

On 10/18/2015 11:25 AM, Uwe Brauer wrote:

> But the change log contains
> 2015-10-18  Uwe Brauer  <oub@mat.ucm.es>
>
> 	* section-0002.tex (subsection{Weight._Sobol._fract._order_their}
> 	{} {}):
> 	test
>
> Which is *not* displayed.
>
> It is displayed if the file is under RCS!

Turns out, the problem is that vc-hg-print-log doesn't display multiline 
messages, just the first line.

Mercurial is weird.

The easiest way to display them is to pass -v to 'hg log'. However, that 
will also display the list of files touched by the commit, which can be 
long, and it's pretty annoying.

To avoid that, https://bz.mercurial-scm.org/show_bug.cgi?id=688 suggests 
using the --template argument, to indicate exactly what to output.

If someone were to look into it and tell us what template format 
corresponds to "current output plus long commit message", that would be 
helpful. Preferably, both for "short" and "long" types of output (see 
vc-hg-print-log).

Re: vc-next-action RCS vs hg: copies the entry of ChangeLog

[Uwe Brauer]

   > On 10/18/2015 11:25 AM, Uwe Brauer wrote:

   > Turns out, the problem is that vc-hg-print-log doesn't display
   > multiline messages, just the first line.

   > Mercurial is weird.

Right I just found out that git behaves differently and behaves as
expected. Sigh  I just made my up my mind to switch from RCS to hg...

   > The easiest way to display them is to pass -v to 'hg log'. However,
   > that will also display the list of files touched by the commit, which
   > can be long, and it's pretty annoying.

Ok that seems to do it, but is seems to me that from the command line
git log

Has the nicer output than 

 hg log -v

Shrug that cannot be helped.

   > To avoid that, https://bz.mercurial-scm.org/show_bug.cgi?id=688
   > suggests using the --template argument, to indicate exactly what to
   > output.

   > If someone were to look into it and tell us what template format
   > corresponds to "current output plus long commit message", that would
   > be helpful. Preferably, both for "short" and "long" types of output
   > (see vc-hg-print-log).


I am very interested in this and will look it up

Re: vc-next-action RCS vs hg: copies the entry of ChangeLog

[Uwe Brauer]

   > On 10/18/2015 11:25 AM, Uwe Brauer wrote:

   > Turns out, the problem is that vc-hg-print-log doesn't display
   > multiline messages, just the first line.

   > Mercurial is weird.

   > The easiest way to display them is to pass -v to 'hg log'. However,
   > that will also display the list of files touched by the commit, which
   > can be long, and it's pretty annoying.

   > To avoid that, https://bz.mercurial-scm.org/show_bug.cgi?id=688
   > suggests using the --template argument, to indicate exactly what to
   > output.

   > If someone were to look into it and tell us what template format
   > corresponds to "current output plus long commit message", that would
   > be helpful. Preferably, both for "short" and "long" types of output
   > (see vc-hg-print-log).


Hi it seems that

hg log --template "commit {node}\nAuthor : {author}\nDate: {date|rfc822date}\n\n{desc}\n\n{nofiles}\n" 

Does more or less what
 git log does

Re: vc-next-action RCS vs hg: copies the entry of ChangeLog

[Dmitry Gutov]

On 10/18/2015 04:06 PM, Uwe Brauer wrote:

> hg log --template "commit {node}\nAuthor : {author}\nDate: {date|rfc822date}\n\n{desc}\n\n{nofiles}\n"

Thank you, that's a step in the right direction. But do we really want 
to change Hg's log output beyond showing multiline messages?

Because if it's going to have more changes, at the very least, we'll 
need to adjust the font-lock rules as well (vc-hg-log-view-mode applies 
certain amount of highlighting).

Though if the output as exactly like Git's, we could use those.

The current changeset value format, containing both the numeric revision 
number and its hash, seems like it might be more useful as well.

Re: vc-next-action RCS vs hg: copies the entry of ChangeLog

[Uwe Brauer]

>>> "Dmitry" == Dmitry Gutov <dgutov@yandex.ru> writes:

> On 10/18/2015 04:06 PM, Uwe Brauer wrote:
>> hg log --template "commit {node}\nAuthor : {author}\nDate: {date|rfc822date}\n\n{desc}\n\n{nofiles}\n"

> Thank you, that's a step in the right direction. But do we really want
> to change Hg's log output beyond showing multiline messages?


You are right. I will dig further and report back.

Re: vc-next-action RCS vs hg: copies the entry of ChangeLog

[Uwe Brauer]

>>> "Dmitry" == Dmitry Gutov <dgutov@yandex.ru> writes:

   > On 10/18/2015 04:06 PM, Uwe Brauer wrote:
   >> hg log --template "commit {node}\nAuthor : {author}\nDate: {date|rfc822date}\n\n{desc}\n\n{nofiles}\n"

   > Thank you, that's a step in the right direction. But do we really want
   > to change Hg's log output beyond showing multiline messages?

I am right now confused. I go to the Emacs git trunc, switch into the
lisp directory:
the latest ChangeLog is ChangeLog.17
its most recent entry (this is not the most update git version of emacs) is

,----
| 2015-04-06  Alan Mackenzie  <acm@muc.de>
| 
| 	Fix miscellaneous glitches in cc-mode.el.  (Bug#20245)
| 	* progmodes/cc-mode.el (c-common-init): bind [Snip]
`----

However when I run git log in that directory I see

,----
| commit 09c15856a926eb80106a5c42571660601c2167d6
| Author: Glenn Morris <rgm@gnu.org>
| Date:   Fri Sep 4 06:19:49 2015 -0400
| 
|     ; Auto-commit of loaddefs files.
| 
| commit 2559d6e8dadead055e6b06b04f71b2eca195dae8
| Author: Eli Zaretskii <eliz@gnu.org>
| Date:   Fri Sep 4 09:56:40 2015 +0300
`----


So git log does not show the ChangeLogs neither?!

However when for example run vc-print-log in abbrev.el
is seems to show the ChangeLog but not the git commit message.
Is this correct??

So in order to have the same behavior for hg, what do we need that the

 hg log  format is *exactly* the same as the
 git log format?


Thanks

Uwe 

Re: vc-next-action RCS vs hg: copies the entry of ChangeLog

[Eli Zaretskii]

> From: Uwe Brauer <oub@mat.ucm.es>
> Date: Mon, 19 Oct 2015 09:55:50 +0300
> 
> I am right now confused. I go to the Emacs git trunc, switch into the
> lisp directory:
> the latest ChangeLog is ChangeLog.17
> its most recent entry (this is not the most update git version of emacs) is
> 
> ,----
> | 2015-04-06  Alan Mackenzie  <acm@muc.de>
> | 
> | 	Fix miscellaneous glitches in cc-mode.el.  (Bug#20245)
> | 	* progmodes/cc-mode.el (c-common-init): bind [Snip]
> `----
> 
> However when I run git log in that directory I see
> 
> ,----
> | commit 09c15856a926eb80106a5c42571660601c2167d6
> | Author: Glenn Morris <rgm@gnu.org>
> | Date:   Fri Sep 4 06:19:49 2015 -0400
> | 
> |     ; Auto-commit of loaddefs files.
> | 
> | commit 2559d6e8dadead055e6b06b04f71b2eca195dae8
> | Author: Eli Zaretskii <eliz@gnu.org>
> | Date:   Fri Sep 4 09:56:40 2015 +0300
> `----
> 
> 
> So git log does not show the ChangeLogs neither?!

Not in those ones.  Look at ChangeLog.2 at top level, this is the Git
commit log, updated once a week.

Re: vc-next-action RCS vs hg: copies the entry of ChangeLog

[Uwe Brauer]

   > Not in those ones.  Look at ChangeLog.2 at top level, this is the Git
   > commit log, updated once a week.


Hm not for me, but I have a repository which is some weeks old I first
pull a new one (if my connections allows it) and then report back.

I have to understand how
git log
is connected with vc-print-log

In order to modify hg log 

Re: vc-next-action RCS vs hg: copies the entry of ChangeLog

[Uwe Brauer]

   > Not in those ones.  Look at ChangeLog.2 at top level, this is the Git
   > commit log, updated once a week.

I successfully run git pull.

Now
ChangeLog.2 contains the following first lines
,----
| 2015-10-18  Michael Albinus  <michael.albinus@gmx.de>
| 
|         Minor edits in Tramp
| 
|         * lisp/net/tramp-adb.el (directory-listing-before-filename-regexp):
|         Declare it.
| 
|         * lisp/net/tramp-compat.el (directory-listing-before-filename-regexp):
|         Remove declaration.
`----

However git log | more

gives 
,----
| commit f1575763c0d30df9f9e5b730c2f2c68f501cda9c
| Author: Eli Zaretskii <eliz@gnu.org>
| Date:   Mon Oct 19 10:04:50 2015 +0300
| 
|     Fix return value of 'set-file-extended-attributes'
| 
|     * lisp/files.el (set-file-extended-attributes): Return non-nil
|     when setting either ACLs or SELinux context succeeds.  Document
|     the return value.  (Bug#21699)
| 
|     * doc/lispref/files.texi (Changing Files): Document the return
|     value of set-file-extended-attributes.
`----


 of course if in lisp/files.el I run vc-print-log it shows the above
 message.

What I am wondering where is the corresponding ChangeLog file?

Re: vc-next-action RCS vs hg: copies the entry of ChangeLog

[Eli Zaretskii]

> From: Uwe Brauer <oub@mat.ucm.es>
> Date: Mon, 19 Oct 2015 11:14:17 +0300
> 
> 
> 
>    > Not in those ones.  Look at ChangeLog.2 at top level, this is the Git
>    > commit log, updated once a week.
> 
> I successfully run git pull.
> 
> Now
> ChangeLog.2 contains the following first lines
> ,----
> | 2015-10-18  Michael Albinus  <michael.albinus@gmx.de>
> | 
> |         Minor edits in Tramp
> | 
> |         * lisp/net/tramp-adb.el (directory-listing-before-filename-regexp):
> |         Declare it.
> | 
> |         * lisp/net/tramp-compat.el (directory-listing-before-filename-regexp):
> |         Remove declaration.
> `----
> 
> However git log | more
> 
> gives 
> ,----
> | commit f1575763c0d30df9f9e5b730c2f2c68f501cda9c
> | Author: Eli Zaretskii <eliz@gnu.org>
> | Date:   Mon Oct 19 10:04:50 2015 +0300
> | 
> |     Fix return value of 'set-file-extended-attributes'
> | 
> |     * lisp/files.el (set-file-extended-attributes): Return non-nil
> |     when setting either ACLs or SELinux context succeeds.  Document
> |     the return value.  (Bug#21699)
> | 
> |     * doc/lispref/files.texi (Changing Files): Document the return
> |     value of set-file-extended-attributes.
> `----

Of course.  Like I said above:

>    > Look at ChangeLog.2 at top level, this is the Git
>    > commit log, updated once a week.
                   ^^^^^^^^^^^^^^^^^^^

Wait for a few hours, and you will ChangeLog.2 updated in the
repository.

Re: vc-next-action RCS vs hg: copies the entry of ChangeLog

[Uwe Brauer]

   > Of course.  Like I said above:

   >                    ^^^^^^^^^^^^^^^^^^^

   > Wait for a few hours, and you will ChangeLog.2 updated in the
   > repository.


Ok, thanks. Last question, a bit off topic I admit. Where is it
configured that git uses ChangeLog.2.

I did a grep in the .git directory but did not find anything useful.

thanks

Re: vc-next-action RCS vs hg: copies the entry of ChangeLog

[Dmitry Gutov]

On 10/19/2015 11:38 AM, Uwe Brauer wrote:

> Ok, thanks. Last question, a bit off topic I admit. Where is it
> configured that git uses ChangeLog.2.

This thread of discussion is very confused.

Git doesn't use ChangeLog files itself. We copy the most recent 
ChangeLog entry into commit message before making a commit.

Otherwise, Git doesn't know anything about them.

Re: vc-next-action RCS vs hg: copies the entry of ChangeLog

[Dmitry Gutov]

On 10/19/2015 11:52 AM, Dmitry Gutov wrote:

> Otherwise, Git doesn't know anything about them.

Except storing and updating ChangeLog.x when asked, of course.

Re: vc-next-action RCS vs hg: copies the entry of ChangeLog

[Eli Zaretskii]

> From: Uwe Brauer <oub@mat.ucm.es>
> Date: Mon, 19 Oct 2015 11:38:25 +0300
> 
> Ok, thanks. Last question, a bit off topic I admit. Where is it
> configured that git uses ChangeLog.2.

It doesn't.  We produce ChangeLog.2 from "git log".

Re: vc-next-action RCS vs hg: copies the entry of ChangeLog

[Uwe Brauer]

> It doesn't.  We produce ChangeLog.2 from "git log".

Ok, but git log
prints the commit msg and the relevant ChangeLog entry
(of that directory I presume.)

 Hg log seems not to have that feature.

Re: vc-next-action RCS vs hg: copies the entry of ChangeLog

[Dmitry Gutov]

On 10/19/2015 12:15 PM, Uwe Brauer wrote:

> Ok, but git log
> prints the commit msg and the relevant ChangeLog entry
> (of that directory I presume.)
>
>   Hg log seems not to have that feature.

hg log -v.

Re: vc-next-action RCS vs hg: copies the entry of ChangeLog

[Uwe Brauer]

>>> "Dmitry" == Dmitry Gutov <dgutov@yandex.ru> writes:

   > On 10/19/2015 12:15 PM, Uwe Brauer wrote:
   >> Ok, but git log
   >> prints the commit msg and the relevant ChangeLog entry
   >> (of that directory I presume.)
   >> 
   >> Hg log seems not to have that feature.

   > hg log -v.


No, this does not display the content of the ChangeLog!!!

Let me try to resume.

HG
    -  Edit a file and enter a comment "CHLcomment" into the ChangeLog

    -  From the command line: hg commit -m "test msg"

    -  From the command line: hg log -v

*Only* the comment "test msg" is displayed

GIT

    -  Edit a file and enter a comment "CHLcomment" into the ChangeLog

    -  From the command line: git commit -am "test msg"

    -  From the command line: git log 

*Only* the comment "test msg" is displayed!!

Now I use Emacs.

GIT

    -  Edit a file and enter a comment "CHLcommentEmacs" into the ChangeLog

    -  vc-next-action:  "test msgEmacs"

    -  vc-print-log: both comments are shown  "CHLcommentEmacs" and  "test       msgEmacs"

    - from the command line git log shows also *BOTH*

HG
    -  Edit a file and enter a comment "CHLcommentEmacs" into the ChangeLog

    -  vc-next-action:  "test msgEmacs"

    -  vc-print-log: only    "test msgEmacs" is displayed

    -       from the command line hg log only shows  "test msgEmacs"

So it seems the culprit is Emacs, when it commits using git is also
inserts part of the ChangeLog, otherwise I don't understand the
different behavior of

 git log

From the command line.

Re: vc-next-action RCS vs hg: copies the entry of ChangeLog

[Dmitry Gutov]

On 10/19/2015 01:45 PM, Uwe Brauer wrote:

>     > hg log -v.
>
>
> No, this does not display the content of the ChangeLog!!!

Right. It shows the full contents of commit messages. Which should have 
ChangeLog entries in them, if you committed from inside Emacs, using 
vc-next-action.

> Let me try to resume.
>
> HG
>      -  Edit a file and enter a comment "CHLcomment" into the ChangeLog
>
>      -  From the command line: hg commit -m "test msg"
>
>      -  From the command line: hg log -v
>
> *Only* the comment "test msg" is displayed

Indeed.

> Now I use Emacs.
>
> GIT
 > ...
> HG
>      -  Edit a file and enter a comment "CHLcommentEmacs" into the ChangeLog
>
>      -  vc-next-action:  "test msgEmacs"
>
>      -  vc-print-log: only    "test msgEmacs" is displayed

Because, like I explained in this very thread, vc-hg-print-log doesn't 
use the '-v' argument when calling 'hg log'.

>      -       from the command line hg log only shows  "test msgEmacs"

Call 'hg log -v' at this step.

> So it seems the culprit is Emacs, when it commits using git is also
> inserts part of the ChangeLog, otherwise I don't understand the
> different behavior of
>
>   git log
>
>  From the command line.

'git log' doesn't need '-v'.

Re: vc-next-action RCS vs hg: copies the entry of ChangeLog

[Uwe Brauer]

   > On 10/19/2015 01:45 PM, Uwe Brauer wrote:

   > Right. It shows the full contents of commit messages. Which should
   > have ChangeLog entries in them, if you committed from inside Emacs,
   > using vc-next-action.


   > Indeed.


   > Because, like I explained in this very thread, vc-hg-print-log doesn't
   > use the '-v' argument when calling 'hg log'.


   > Call 'hg log -v' at this step.


   > 'git log' doesn't need '-v'.


You are right I am wrong.

I send you a possible hg log
hg log --template "commit {node}\nAuthor: {author}\nDate: {date|rfc822date}\n{desc}\n{nofiles}\n"

And for me it looks very much than the one of git, so one could just use
the same code.

However you seem to prefer a different format.

Could you please tell me what you have in mind?

So I could try to play with the templates.

Thanks

Re: vc-next-action RCS vs hg: copies the entry of ChangeLog

[Dmitry Gutov]

On 10/19/2015 01:57 PM, Uwe Brauer wrote:

> I send you a possible hg log
> hg log --template "commit {node}\nAuthor: {author}\nDate: {date|rfc822date}\n{desc}\n{nofiles}\n"
>
> And for me it looks very much than the one of git, so one could just use
> the same code.
>
> However you seem to prefer a different format.
>
> Could you please tell me what you have in mind?

I don't know which template string that corresponds to, but for 
vc-print-log, we use the normal 'hg log' output.

For vc-print-root-log, we currently use this template:

(concat "{rev}:{ifeq(branch, 'default','', '{branch}')}"
         ":{bookmarks}:{tags}:{author|person}"
         " {date|shortdate} {desc|firstline}\\n")

So we have two of them, and we probably want to modify each of them 
slightly, so that the messages are displayed in full.

Re: vc-next-action RCS vs hg: copies the entry of ChangeLog

[Uwe Brauer]

>>> "Dmitry" == Dmitry Gutov <dgutov@yandex.ru> writes:

> On 10/19/2015 01:57 PM, Uwe Brauer wrote:
>> I send you a possible hg log
>> hg log --template "commit {node}\nAuthor: {author}\nDate: {date|rfc822date}\n{desc}\n{nofiles}\n"
>> 
>> And for me it looks very much than the one of git, so one could just use
>> the same code.
>> 
>> However you seem to prefer a different format.
>> 
>> Could you please tell me what you have in mind?

> I don't know which template string that corresponds to, but for
> vc-print-log, we use the normal 'hg log' output.

> For vc-print-root-log, we currently use this template:

> (concat "{rev}:{ifeq(branch, 'default','', '{branch}')}"
>         ":{bookmarks}:{tags}:{author|person}"
>         " {date|shortdate} {desc|firstline}\\n")

> So we have two of them, and we probably want to modify each of them
> slightly, so that the messages are displayed in full.


Ok 

However when I run

hg log --template "changeset: {rev}:{node|short}\ntag: {tags}\nuser:
{author}\nDate: {date|rfc822date}\ndescription: {desc}\n{nofiles}\n"

I obtain
,----
| changeset: 17:5d2e1c5cdb3c
| tag: tip
| user: Uwe Brauer <oub@mat.ucm.es>
| Date: Mon, 19 Oct 2015 13:51:29 +0300
| description: second commit
| 
| * testhg.tex: my first one.
`----

While with
hg log -v

,----
| changeset:   17:5d2e1c5cdb3c
| tag:         tip
| user:        Uwe Brauer <oub@mat.ucm.es>
| date:        Mon Oct 19 13:51:29 2015 +0300
| files:       testhg.tex
| description:
| second commit
| 
| * testhg.tex: my first one.
| 
`----


So I think the new template should be fine or you want to fiddle me the
 newlines?

How to implement that in is not entirely clear to me. Maybe a different
template for hg is needed?

Re: vc-next-action RCS vs hg: copies the entry of ChangeLog

[Dmitry Gutov]

On 10/19/2015 04:20 PM, Uwe Brauer wrote:

> So I think the new template should be fine or you want to fiddle me the
>   newlines?

Why newlines?

The obvious difference is that the values are not lined up vertically. 
But you can add spaces to fix that, manually. Then:

- No need to replace "summary:" with "description:".
- Even when the commit doesn't have a tag, your template still shows 
that line.
- The date format is slightly different.
- When the commit has multiple parents, the default style shows them 
both, yours doesn't.

> How to implement that in is not entirely clear to me. Maybe a different
> template for hg is needed?

I don't know what you mean by that.

It's okay if this is too much for you. Then please open a bug for this, 
and we'll get back to it later. Maybe someone experienced with Mercurial 
will come and help.

Re: vc-next-action RCS vs hg: copies the entry of ChangeLog

[Uwe Brauer]

>>> "Dmitry" == Dmitry Gutov <dgutov@yandex.ru> writes:

> On 10/19/2015 04:20 PM, Uwe Brauer wrote:
>> So I think the new template should be fine or you want to fiddle me the
>> newlines?

> Why newlines?

> The obvious difference is that the values are not lined up vertically.
> But you can add spaces to fix that, manually. Then:

> - No need to replace "summary:" with "description:".
> - Even when the commit doesn't have a tag, your template still shows that line.
> - The date format is slightly different.
> - When the commit has multiple parents, the default style shows them both, yours doesn't.

Ok, I will ask on the mercurial list for more help.

>> How to implement that in is not entirely clear to me. Maybe a different
>> template for hg is needed?

> I don't know what you mean by that.

What I mean is suppose I come up with the hg template which meets all
the requirements, I would leave it to the vc maintainer to implement
that in lisp. For me it is not obvious how to do it.

> It's okay if this is too much for you. Then please open a bug for
> this, and we'll get back to it later. Maybe someone experienced with
> Mercurial will come and help.

If I don't get a useful respond on the Mercurial list, I will do that.

Re: vc-next-action RCS vs hg: copies the entry of ChangeLog

[Dmitry Gutov]

On 10/20/2015 09:05 AM, Uwe Brauer wrote:

> What I mean is suppose I come up with the hg template which meets all
> the requirements, I would leave it to the vc maintainer to implement
> that in lisp. For me it is not obvious how to do it.

You could leave that to me, yes.

[Solved] (was: vc-next-action RCS vs hg: copies the entry of ChangeLog)

[Uwe Brauer]

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

>>> "Dmitry" == Dmitry Gutov <dgutov@yandex.ru> writes:

   > On 10/20/2015 09:05 AM, Uwe Brauer wrote:
   >> What I mean is suppose I come up with the hg template which meets all
   >> the requirements, I would leave it to the vc maintainer to implement
   >> that in lisp. For me it is not obvious how to do it.

   > You could leave that to me, yes.

I finally found a solution which was proposed to me by Simon King on the
mercury mailing list.

It seems impossible to run hg log from the commandline in order to
obtain a output similar/identical to «git  log».

There is however a two step procedure.

    -  write a style file (I attach the correct one below)

    -  then run hg log --style /path/to/hgstyle 

And voila!

,----
| changeset:   32:de9787eefb88
| tag: tip
| user:        Uwe Brauer <oub@mat.ucm.es>
| Date:        Mon Oct 26 16:27:35 2015 +0000
| summary:     A Huge commit
| 
|         * section-1.tex: Here comes an
|         important change
| 
|         * testhg2.tex (section{Nación} {} {}): New long change:
| 
|         * testhg2.tex (section{Introduction} {} {}): Add an
|         introduction
| 
|         * testneuneu.tex (section{Einfuehrung} {} {}): Eine
|         Neue Einfuehrung
`----

How to implement this is lisp I leave to you.

Thanks and regards

Uwe Brauer 


[-- Attachment #2: hgstyle --]
[-- Type: application/octet-stream, Size: 167 bytes --]

changeset = "changeset:   {rev}:{node|short}\n{tags}user:        {author}\nDate:        {date|date}\nsummary:     {tabindent(desc)}\n{nofiles}\n"
tag = "tag: {tag}\n"

Re: [Solved]

[Dmitry Gutov]

On 10/26/2015 06:35 PM, Uwe Brauer wrote:

> There is however a two step procedure.
>
>      -  write a style file (I attach the correct one below)
>
>      -  then run hg log --style /path/to/hgstyle
>
> And voila!

Thank you the style file. I was able to turn it back into a template 
string, using what the Mercurial documentation calls the "list operator" 
(percent sign).

I've also made some changes:

- Removed 'tabindent', because 8-spaces indentation looks too much, and 
'indent' doesn't work in my version of Mercurial (3.4).

- Added "parents:". I tried to put them on separate lines, but haven't 
managed do to that while retaining their short format.

- Added indentation after "tag:".

- Removed {nofiles}. Any idea what that expansion is supposed to do? It 
didn't seem to have any effect.

Pushed to master as 99ded6b.

Re: [Solved]

[Uwe Brauer]

> On 10/26/2015 06:35 PM, Uwe Brauer wrote:

> Thank you the style file. I was able to turn it back into a template
> string, using what the Mercurial documentation calls the "list
> operator" (percent sign).

> I've also made some changes:

> - Removed 'tabindent', because 8-spaces indentation looks too much,
> and 'indent' doesn't work in my version of Mercurial (3.4).


Nor in mine 3.0.1.
Pitty I liked the tabindentation makes it better readable. Will see
whether tabindent is configurable.

> - Added "parents:". I tried to put them on separate lines, but haven't
> managed do to that while retaining their short format.

> - Added indentation after "tag:".

> - Removed {nofiles}. Any idea what that expansion is supposed to do?
> It didn't seem to have any effect.

Well that is supposed not to show the list of modified files. As far as
I can remember this was one of your concerns about «hg log -v»

> Pushed to master as 99ded6b.

Ok I pulled and, since did not want to recompile my whole emacs, I just
compiled replaced the whole vc directory by a new one. But now how am I
suppose to use the new functionality? Because for me nothing has changed
in the behaviour of vc-print-log

Uwe 

Re: [Solved]

[Dmitry Gutov]

On 10/27/2015 04:23 PM, Uwe Brauer wrote:

> Pitty I liked the tabindentation makes it better readable. Will see
> whether tabindent is configurable.

I don't know if it makes that much of a difference: everything but the 
message contents is formatted in a distinct way.

> Well that is supposed not to show the list of modified files. As far as
> I can remember this was one of your concerns about «hg log -v»

We don't see the list of modified files without {nofiles} either.

> Ok I pulled and, since did not want to recompile my whole emacs, I just
> compiled replaced the whole vc directory by a new one. But now how am I
> suppose to use the new functionality? Because for me nothing has changed
> in the behaviour of vc-print-log

It should show multiline messages in commits that contain them.

Re: [Solved]

[Uwe Brauer]

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


   > On 10/26/2015 06:35 PM, Uwe Brauer wrote:

   > Thank you the style file. I was able to turn it back into a template
   > string, using what the Mercurial documentation calls the "list
   > operator" (percent sign).

   > I've also made some changes:

   > - Removed 'tabindent', because 8-spaces indentation looks too much,
   > and 'indent' doesn't work in my version of Mercurial (3.4).


 The function fill68  might come in handy, I attach a modified style
 file


[-- Attachment #2: hgstyle --]
[-- Type: application/octet-stream, Size: 176 bytes --]

changeset = "changeset:   {rev}:{node|short}\n{tags}user:        {author}\nDate:        {date|date}\nsummary:     {tabindent(fill68(desc)))}\n{nofiles}\n"
tag = "tag: {tag}\n"

[prop: change] (was: [Solved])

[Uwe Brauer]

>>> "Dmitry" == Dmitry Gutov <dgutov@yandex.ru> writes:

> On 10/26/2015 06:35 PM, Uwe Brauer wrote:
>> There is however a two step procedure.
>> 
>> -  write a style file (I attach the correct one below)
>> 
>> -  then run hg log --style /path/to/hgstyle
>> 
>> And voila!

> Thank you the style file. I was able to turn it back into a template
> string, using what the Mercurial documentation calls the "list
> operator" (percent sign).

> I've also made some changes:

> - Removed 'tabindent', because 8-spaces indentation looks too much,
> and 'indent' doesn't work in my version of Mercurial (3.4).

I got it to work, sorry for the noise.


I changed your code to
(defvar vc-hg-log-format (concat "changeset:   {rev}:{node|short}\n"
                                 "{tags % 'tag:         {tag}\n'}"
                                 "{if(parents, 'parents:     {parents}\n')}"
                                 "user:        {author}\n"
                                 "Date:        {date|date}\n"
                                 "summary:     {tabindent(fill68(desc))}\n\n")
  "Mercurial log template for `vc-hg-print-log' long format.")

And it seems to me closer to «git log»

Re: [prop: change]

[Dmitry Gutov]

On 10/27/2015 04:49 PM, Uwe Brauer wrote:

> I got it to work, sorry for the noise.

Good.

> I changed your code to
> (defvar vc-hg-log-format (concat "changeset:   {rev}:{node|short}\n"
>                                   "{tags % 'tag:         {tag}\n'}"
>                                   "{if(parents, 'parents:     {parents}\n')}"
>                                   "user:        {author}\n"
>                                   "Date:        {date|date}\n"
>                                   "summary:     {tabindent(fill68(desc))}\n\n")
>    "Mercurial log template for `vc-hg-print-log' long format.")
>
> And it seems to me closer to «git log»

I don't think 'git log' refills commit messages, or uses 8 spaces to 
indent them. Does it?

Re: [prop: change]

[Uwe Brauer]

   > On 10/27/2015 04:49 PM, Uwe Brauer wrote:

   > Good.


   > I don't think 'git log' refills commit messages, or uses 8 spaces
   > to indent them. Does it?


Here is a cat:
,----
| commit 99ded6be7afe843d7abc0e255fe36b684435cfd7
| Author: Dmitry Gutov <dgutov@yandex.ru>
| Date:   Tue Oct 27 14:55:06 2015 +0200
| 
|     Show full commit messages in 'hg log' when appropriate
| 
|     * lisp/vc/vc-hg.el (vc-hg-log-format): New variable.
|     (vc-hg-print-log, vc-hg-expanded-log-entry): Use it.
|     (http://lists.gnu.org/archive/html/emacs-devel/2015-10/msg02191.html)
`----

And here is a output with my modified using tabindent.

,----
| changeset:   133:a9f91e0993e9
| user:        Uwe Brauer <oub@mat.ucm.es>
| Date:        Sat Oct 24 09:15:23 2015 +0300
| summary:     Various changes
| 
|         * section-0003.tex (subsection{Properties_solutions} {equation}
|         {eq:gamblin:9}): important change
`----


So the difference is the degree of indentation.

Re: [prop: change]

[Uwe Brauer]

>>> "Dmitry" == Dmitry Gutov <dgutov@yandex.ru> writes:

> On 10/27/2015 04:49 PM, Uwe Brauer wrote:
>> I got it to work, sorry for the noise.

> Good.

>> I changed your code to
>> (defvar vc-hg-log-format (concat "changeset:   {rev}:{node|short}\n"
>> "{tags % 'tag:         {tag}\n'}"
>> "{if(parents, 'parents:     {parents}\n')}"
>> "user:        {author}\n"
>> "Date:        {date|date}\n"
>> "summary:     {tabindent(fill68(desc))}\n\n")
>> "Mercurial log template for `vc-hg-print-log' long format.")
>> 
>> And it seems to me closer to «git log»

> I don't think 'git log' refills commit messages, or uses 8 spaces to
> indent them. Does it?

 The function tabindent adds a tab, since tab-width is set to 8, this
 looks like 8 spaces, maybe in that case tab-width should be set to 4.

Re: [prop: change]

[Dmitry Gutov]

On 10/28/2015 02:22 PM, Uwe Brauer wrote:

>> I think 2 looks a bit better than 4, wastes less space. Hope that's
>> all right with you.
>
> I'd prefer 4, but I leave that to your judgment. One question I also had
> {tabindent(fill68(desc)).
>
> It seems that you don't like it, but I think it could be handy for very
> long lines in the Changelog file?

IMO, it's better to fix any long-line problems in the commit message 
before making the commit.

And if you wrap long lines in vc-hg-log output,

a) You risk not seeing these problems, which is problematic for the 
commits you made yourself (other members of your team will see them 
differently).

b) There's no guarantee that fill68 won't make some text layout worse. 
At least I think so; I've never tried it.

emacs hebrew script bidi nikud rendering bugs

[Mark David]

I want to report and maybe fix bugs in rendering Hebrew script, particularly with diacritics (nikud). It only partially works in environments I'm using (Ubunutu, Emacs 25.x).  (Hebrew without diacritics, used for everyday Hebrew language writing, is evidently functioning well.)  Is there a mailing list best suited for that?  Is there a separate development team for that kind of thing?  Where would I report, say, inability to correctly render a sequence of Hebrew base character and diacritic like this



Unicode Character 'HEBREW LETTER ALEF' (U+05D0)

Unicode Character 'HEBREW POINT QAMATS' (U+05B8)


(with a given font, window system, OS, "multlingual environment" setting, etc.)?

Thanks,

Mark

Re: emacs hebrew script bidi nikud rendering bugs

[Uwe Brauer]

>>> "Mark" == Mark David <markhd@fastmail.fm> writes:

    > I want to report and maybe fix bugs in rendering Hebrew script,
    > particularly with diacritics (nikud). It only partially works in
    > environments I'm using (Ubunutu, Emacs 25.x). (Hebrew without
    > diacritics, used for everyday Hebrew language writing, is evidently
    > functioning well.) Is there a mailing list best suited for that? Is
    > there a separate development team for that kind of thing? Where would
    > I report, say, inability to correctly render a sequence of Hebrew base
    > character and diacritic like this

    > Unicode Character 'HEBREW LETTER ALEF' (U+05D0)

    > Unicode Character 'HEBREW POINT QAMATS' (U+05B8)

I am not sure what you mean by rendered correctly.

Let A=aleph
    ^=QAMATS

Then for example OpenOffice displays this correctly as

   A
   ^
while Emacs 25 (and 24.5) displays it as

   A
  ^ 

That is what you mean? (Not sure whether to write hebrew+niqqud on the
list) 

Remark: using xelatex the hebrew text with niqquds get compiled and the
pdf displays the niqqud correctly.


Uwe Brauer 

Re: emacs hebrew script bidi nikud rendering bugs

[Eli Zaretskii]

> From: Uwe Brauer <oub@mat.ucm.es>
> Date: Sat, 07 Nov 2015 09:41:46 +0000
> 
> >>> "Mark" == Mark David <markhd@fastmail.fm> writes:
> 
>     > I want to report and maybe fix bugs in rendering Hebrew script,
>     > particularly with diacritics (nikud). It only partially works in
>     > environments I'm using (Ubunutu, Emacs 25.x). (Hebrew without
>     > diacritics, used for everyday Hebrew language writing, is evidently
>     > functioning well.) Is there a mailing list best suited for that? Is
>     > there a separate development team for that kind of thing? Where would
>     > I report, say, inability to correctly render a sequence of Hebrew base
>     > character and diacritic like this
> 
>     > Unicode Character 'HEBREW LETTER ALEF' (U+05D0)
> 
>     > Unicode Character 'HEBREW POINT QAMATS' (U+05B8)
> 
> I am not sure what you mean by rendered correctly.
> 
> Let A=aleph
>     ^=QAMATS
> 
> Then for example OpenOffice displays this correctly as
> 
>    A
>    ^
> while Emacs 25 (and 24.5) displays it as
> 
>    A
>   ^ 

Not here: I see A, as expected.
                ^

Re: emacs hebrew script bidi nikud rendering bugs

[Uwe Brauer]

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



   > Not here: I see A, as expected.
   >                 ^

You are right for 25, at least partially. I my default font is 
 '(default ((t (:family "DejaVu Sans Mono" :foundry "unknown" :slant
 normal :weight normal :height 143 :width normal)))) 

And I don't see *all* niqqud correctly. I attach a screenshot with the
misplaced niqqud of a latex file and a pdf file where they are displayed
correctly.


[-- Attachment #2: niqqud.png --]
[-- Type: image/png, Size: 14507 bytes --]

[-- Attachment #3: testheb.pdf --]
[-- Type: application/pdf, Size: 17688 bytes --]

Re: emacs hebrew script bidi nikud rendering bugs

[Eli Zaretskii]

> From: Uwe Brauer <oub@mat.ucm.es>
> Date: Sat, 07 Nov 2015 17:27:57 +0000
> 
>    > Not here: I see A, as expected.
>    >                 ^
> 
> You are right for 25, at least partially. I my default font is 
>  '(default ((t (:family "DejaVu Sans Mono" :foundry "unknown" :slant
>  normal :weight normal :height 143 :width normal)))) 

The default font is not what matters.  You should find out which
font(s) is/are used to display the problematic character combinations.
Emacs cannot compose characters that are displayed by different fonts.
Use "C-u C-x =" to show the font for each character.

Re: emacs hebrew script bidi nikud rendering bugs

[Uwe Brauer]

    > The default font is not what matters.  You should find out which
    > font(s) is/are used to display the problematic character combinations.
    > Emacs cannot compose characters that are displayed by different fonts.
    > Use "C-u C-x =" to show the font for each character.

Out of curiosity, are all niqqud displayed correctly in your setting?


    -  First of all the ones which work
       for example aleph+qamats: I obtain



,----
| 
|                     position: 431 of 708 (61%), column: 12
|             character: א‎ (displayed as א‎) (codepoint 1488, #o2720, #x5d0)
|     preferred charset: unicode (Unicode (ISO10646))
| code point in charset: 0x05D0
|                script: hebrew
|                syntax: w 	which means: word
|              category: .:Base, R:Right-to-left (strong)
|              to input: type "C-x 8 RET 5d0" or "C-x 8 RET HEBREW LETTER ALEF"
|           buffer code: #xD7 #x90
|             file code: #xD7 #x90 (encoded by coding system utf-8-unix)
|               display: composed to form "אָ" (see below)
| 
| Composed with the following character(s) "ָ" using this font:
|   xft:-unknown-DejaVu Sans-normal-normal-normal-*-19-*-*-*-*-0-iso10646-1
| by these glyphs:
|   [0 1 64303 4765 13 2 11 10 3 nil]
| 
| Character code properties: customize what to show
|   name: HEBREW LETTER ALEF
|   general-category: Lo (Letter, Other)
|   decomposition: (1488) ('א')
| 
| There are text properties here:
|   fontified            t
`----


    -  now to aleph+qubuts where qubuts is not displayed directly under
       the aleph. Cursor on the aleph

,----
| 
|              position: 464 of 708 (65%), column: 12
|             character: א‎ (displayed as א‎) (codepoint 1488, #o2720, #x5d0)
|     preferred charset: unicode (Unicode (ISO10646))
| code point in charset: 0x05D0
|                script: hebrew
|                syntax: w 	which means: word
|              category: .:Base, R:Right-to-left (strong)
|              to input: type "C-x 8 RET 5d0" or "C-x 8 RET HEBREW LETTER ALEF"
|           buffer code: #xD7 #x90
|             file code: #xD7 #x90 (encoded by coding system utf-8-unix)
|               display: composed to form "אֻ" (see below)
| 
| Composed with the following character(s) "ֻ" using this font:
|   xft:-unknown-DejaVu Sans-normal-normal-normal-*-19-*-*-*-*-0-iso10646-1
| by these glyphs:
|   [0 1 1488 1316 13 2 11 10 0 nil]
|   [0 1 1467 1305 0 2 11 -2 5 nil]
| 
| Character code properties: customize what to show
|   name: HEBREW LETTER ALEF
|   general-category: Lo (Letter, Other)
|   decomposition: (1488) ('א')
| 
| There are text properties here:
|   fontified            t
| 
| [back]
`----

I fail to see the difference.

Re: emacs hebrew script bidi nikud rendering bugs

[Eli Zaretskii]

> From: Uwe Brauer <oub@mat.ucm.es>
> Date: Sat, 07 Nov 2015 18:32:05 +0000
> 
> 
> 
>     > The default font is not what matters.  You should find out which
>     > font(s) is/are used to display the problematic character combinations.
>     > Emacs cannot compose characters that are displayed by different fonts.
>     > Use "C-u C-x =" to show the font for each character.
> 
> Out of curiosity, are all niqqud displayed correctly in your setting?

Yes.

> I fail to see the difference.

Right, it seems to be a problem with the shaping engine.  Try
upgrading libotf, libm17n-flt, and m17n-db.  If that doesn't help,
please submit a bug report to their bug tracker.

[SOLVED] (was: emacs hebrew script bidi nikud rendering bugs)

[Uwe Brauer]

    > Yes.


    > Right, it seems to be a problem with the shaping engine.  Try
    > upgrading libotf, libm17n-flt, and m17n-db.  If that doesn't help,
    > please submit a bug report to their bug tracker.


I upgraded libotf 0.9.13, libm17n-flt, and m17n-db to version 1.6.X
and the niqqud are displayed correctly.

Thanks

Uwe 

Re: [SOLVED]

[Benjamin Riefenstahl]

Hi Uwe,

Uwe Brauer writes:
> I upgraded libotf 0.9.13, libm17n-flt, and m17n-db to version 1.6.X
> and the niqqud are displayed correctly.

Good!

Just for the record, this is still with "DejaVu Sans" and relatively
standard stuff like alef+qamats and alef+qubuts specifically, right?
Did you try adding dagesh or the yiddish ligatures, like the things that
Mark has?

benny

count all spelling typos in a given buffer.

[Uwe Brauer]

Hi 

I asked this already on the emacs help list, but maybe somebody here,
knows about the following feature, namely:
Count all the typos, ispell (flyspell) finds in given buffer. 

I see two possibilities to make this work
    1. run flyspell-region or flyspell-buffer and simply (?) Count the
       highlighted expressions.
    2. run a complete ispell session, accept some changes, reject
       others, add new words (mostly names ispell does not know about)
       to your private dictionary. Once that is finished, the number of
       corrections+entry in the personal dictionary are counted and
       displayed.


Anybody knows about something like this, or is somebody working on it?
Might be very useful for teachers or lectures for correcting submitted works.

Regards

Uwe Brauer 

-- 
I strongly condemn Hamas heinous atrocities on Israel, especially the despicable pogroms.
I strongly condemn Putin's war of aggression against Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the EU and NATO membership of Ukraine. 

Re: count all spelling typos in a given buffer.

[Emanuel Berg]

Uwe Brauer wrote:

> I asked this already on the emacs help list, but maybe
> somebody here, knows about the following feature, namely:
> Count all the typos, ispell (flyspell) finds in
> given buffer.

I posted this solution on gnu.emacs.help several days ago but
it hasn't appeared, anyway here you go.

;;; -*- lexical-binding: t -*-
;;
;; this file:
;;   https://dataswamp.org/~incal/emacs-init/spell.el

(require 'cl-lib)

(defun ispell-count (&optional beg end)
  (interactive
    (if (use-region-p)
      (list (region-beginning) (region-end)) ))
  (or beg (setq beg (point-min)))
  (or end (setq end (point-max)))
  (save-mark-and-excursion
    (goto-char beg)
    (forward-word)
    (backward-word)
    (cl-loop
      with words  = 0
      with errors = 0
      while (< (point) end)
      do (let ((word (thing-at-point 'word t)))
           (unless (ispell-lookup-words word)
             (cl-incf errors) )
           (cl-incf words)
           (forward-to-word) )
      finally (message "%s words checked, %s errors" words errors) )))

;; this is a region wiht two
;; worsd spelled incorrectly

-- 
underground experts united
https://dataswamp.org/~incal

[SOLVED] (was: count all spelling typos in a given buffer.)

[Uwe Brauer]

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

>>> "EB" == Emanuel Berg <incal@dataswamp.org> writes:

> Uwe Brauer wrote:
>> I asked this already on the emacs help list, but maybe
>> somebody here, knows about the following feature, namely:
>> Count all the typos, ispell (flyspell) finds in
>> given buffer.

> I posted this solution on gnu.emacs.help several days ago but
> it hasn't appeared, anyway here you go.

> ;; this is a region wiht two
> ;; worsd spelled incorrectly

Thanks with the latest misc.el from master, it works, great
-- 
I strongly condemn Hamas heinous atrocities on Israel, especially the despicable pogroms.
I strongly condemn Putin's war of aggression against Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the EU and NATO membership of Ukraine. 


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

Re: [SOLVED] (was: count all spelling typos in a given buffer.)

[Emanuel Berg]

Uwe Brauer wrote:

>>> I asked this already on the emacs help list, but maybe
>>> somebody here, knows about the following feature, namely:
>>> Count all the typos, ispell (flyspell) finds in
>>> given buffer.
>>
>> I posted this solution on gnu.emacs.help several days ago
>> but it hasn't appeared, anyway here you go.
>
>> ;; this is a region wiht two
>> ;; worsd spelled incorrectly
>
> Thanks with the latest misc.el from master, it works, great

Right, I know what caused that, I had my own misc.el not
knowing there was such a file in Emacs already. Glad you got
it to work anyway and I renamed that file, so it improved my
Elisp as well, sweet.

If one is interested in "spell stats" one could do a more
integrated solution so it would report after each normal spell
run with ispell.

But I don't know how much that would be used, really, so maybe
that little Elisp is enough to just test and play with once in
a while. Or why did you want this to begin with? I guess there
are more people like me who just love to count things.

-- 
underground experts united
https://dataswamp.org/~incal

Re: [SOLVED]

[Uwe Brauer]

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

>>> "EB" == Emanuel Berg <incal@dataswamp.org> writes:

> Uwe Brauer wrote:
>>> I asked this already on the emacs help list, but maybe
>>> somebody here, knows about the following feature, namely:
>>> Count all the typos, ispell (flyspell) finds in
>>> given buffer.
>>> 
>>> I posted this solution on gnu.emacs.help several days ago
>>> but it hasn't appeared, anyway here you go.
>> 
>>> ;; this is a region wiht two
>>> ;; worsd spelled incorrectly
>> 
>> Thanks with the latest misc.el from master, it works, great

> Right, I know what caused that, I had my own misc.el not
> knowing there was such a file in Emacs already. Glad you got
> it to work anyway and I renamed that file, so it improved my
> Elisp as well, sweet.

> If one is interested in "spell stats" one could do a more
> integrated solution so it would report after each normal spell
> run with ispell.

I think right now the best strategy is: 

    1. first run ispell/aspell to check for names and expression he does
       not know and which should be inserted in your personal dictionary.

    2. Only then use the counting function.

> But I don't know how much that would be used, really, so maybe
> that little Elisp is enough to just test and play with once in
> a while. Or why did you want this to begin with? I guess there
> are more people like me who just love to count things.

I think I will ask also in the org mailing list, maybe someone there is
interested. 

-- 
I strongly condemn Hamas heinous atrocities on Israel, especially the despicable pogroms.
I strongly condemn Putin's war of aggression against Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the EU and NATO membership of Ukraine. 


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