[rmail-mbox-branch]: expunge

[rmail-mbox-branch]: expunge

[Alfred M. Szmidt]

Okie, this is *really* annoying, rmail expunges messages WITHOUT
asking me.  I can't see how I didn't notice this eariler....

rmail-confirm-expunge's value is y-or-n-p

And another thing, when you open a RMAIL mbox with find-file, it
doesn't change to rmail-mode automaticly; since Emacs doesn't see any
magic that makes it change into the correct mode.

[I wouldn't recommened merging this back into trunk by a long shot, it
 is far to broken]

Happy hacking (and any appologise if this mail sounds harsh, but I
really wasn't that happy when RMAIL deleted mail without asking me!).

Re: [rmail-mbox-branch]: expunge

[Kim F. Storm]

"Alfred M. Szmidt" <ams@kemisten.nu> writes:

> Okie, this is *really* annoying, rmail expunges messages WITHOUT
> asking me.  I can't see how I didn't notice this eariler....
>
> rmail-confirm-expunge's value is y-or-n-p
>
> And another thing, when you open a RMAIL mbox with find-file, it
> doesn't change to rmail-mode automaticly; since Emacs doesn't see any
> magic that makes it change into the correct mode.
>
> [I wouldn't recommened merging this back into trunk by a long shot, it
>  is far to broken]

It seems that the new rmail-mbox-branch code is quite far from
'production quality' so IMHO it is not ready for inclusion in 21.4.

Do we really need to postpone the release of 21.4 just for this one
feature?  Can't it wait until 22.1 ?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: [rmail-mbox-branch]: expunge

[Alfred M. Szmidt]

   > [I wouldn't recommened merging this back into trunk by a long
   >  shot, it is far to broken]

   It seems that the new rmail-mbox-branch code is quite far from
   'production quality' so IMHO it is not ready for inclusion in 21.4.

I'm kinda curious if anyone actually used the rmail-mbox-branch
before...  I was hoping that it would only contain minor bugs, but it
contains some quite serious bugs (eating my mail is serious, not even
being able to run it is serious since it means that it hasn't been
even tested!).

   Do we really need to postpone the release of 21.4 just for this one
   feature?  Can't it wait until 22.1 ?

To me as a user of rmail, I would really prefer it to wait for 22.1.
Right now it is far to broken, if there were more people that could
actualy help out and test it and send patches, then just maybe.  Even
if I said that one shouldn't merge that branch into trunk, maybe that
would be one good way to force people who use rmail to actually use it
and fix it right now and get it ready for 21.4; but I don't know what
the current status of the tree is right now.

And anyway, the babyl format has been used for such a long time that
postponing this feature until 22.1, 23.1 or even 100.1 won't do any
harm anyway.

Those are just my opionions as a user of rmail and emacs; feel free to
ignore them completely.

Re: [rmail-mbox-branch]: expunge

[Kim F. Storm]

"Alfred M. Szmidt" <ams@kemisten.nu> writes:

>    > [I wouldn't recommened merging this back into trunk by a long
>    >  shot, it is far to broken]
>
>    It seems that the new rmail-mbox-branch code is quite far from
>    'production quality' so IMHO it is not ready for inclusion in 21.4.
>
> I'm kinda curious if anyone actually used the rmail-mbox-branch
> before...  I was hoping that it would only contain minor bugs, but it
> contains some quite serious bugs (eating my mail is serious, not even
> being able to run it is serious since it means that it hasn't been
> even tested!).
>
>    Do we really need to postpone the release of 21.4 just for this one
>    feature?  Can't it wait until 22.1 ?
>
> To me as a user of rmail, I would really prefer it to wait for 22.1.
> Right now it is far to broken, if there were more people that could
> actualy help out and test it and send patches, then just maybe.  Even
> if I said that one shouldn't merge that branch into trunk, maybe that
> would be one good way to force people who use rmail to actually use it
> and fix it right now and get it ready for 21.4; but I don't know what
> the current status of the tree is right now.
>
> And anyway, the babyl format has been used for such a long time that
> postponing this feature until 22.1, 23.1 or even 100.1 won't do any
> harm anyway.
>
> Those are just my opionions as a user of rmail and emacs; feel free to
> ignore them completely.

I think your opinion (based on actual experience with using the code)
is very important (to me at least :-) as it clearly expresses the
concern I have had (and expressed) for some time regarding the mbox
branch:

Unless we are 99.9% confident that the new mbox-rmail works as good
the the current babyl-rmail, releasing 21.4 with a broken/deficient
mbox-rmail would be a disaster!

Your findings indicates to me that we are far from those 99.9% ...

And as you say, babyl has done the job fine for MANY years, so what's
wrong using it a little longer (1-2 years isn't long in emacs
development :-)

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: [rmail-mbox-branch]: expunge

[Paul Michael Reilly]

Kim F. Storm wrote:
> "Alfred M. Szmidt" <ams@kemisten.nu> writes:
> 
> 
>>   > [I wouldn't recommened merging this back into trunk by a long
>>   >  shot, it is far to broken]
>>
>>   It seems that the new rmail-mbox-branch code is quite far from
>>   'production quality' so IMHO it is not ready for inclusion in 21.4.
>>
>>I'm kinda curious if anyone actually used the rmail-mbox-branch
>>before...  I was hoping that it would only contain minor bugs, but it
>>contains some quite serious bugs (eating my mail is serious, not even
>>being able to run it is serious since it means that it hasn't been
>>even tested!).
>>
>>   Do we really need to postpone the release of 21.4 just for this one
>>   feature?  Can't it wait until 22.1 ?
>>
>>To me as a user of rmail, I would really prefer it to wait for 22.1.
>>Right now it is far to broken, if there were more people that could
>>actualy help out and test it and send patches, then just maybe.  Even
>>if I said that one shouldn't merge that branch into trunk, maybe that
>>would be one good way to force people who use rmail to actually use it
>>and fix it right now and get it ready for 21.4; but I don't know what
>>the current status of the tree is right now.
>>
>>And anyway, the babyl format has been used for such a long time that
>>postponing this feature until 22.1, 23.1 or even 100.1 won't do any
>>harm anyway.
>>
>>Those are just my opionions as a user of rmail and emacs; feel free to
>>ignore them completely.
> 
> 
> I think your opinion (based on actual experience with using the code)
> is very important (to me at least :-) as it clearly expresses the
> concern I have had (and expressed) for some time regarding the mbox
> branch:
> 
> Unless we are 99.9% confident that the new mbox-rmail works as good
> the the current babyl-rmail, releasing 21.4 with a broken/deficient
> mbox-rmail would be a disaster!
> 
> Your findings indicates to me that we are far from those 99.9% ...
> 
> And as you say, babyl has done the job fine for MANY years, so what's
> wrong using it a little longer (1-2 years isn't long in emacs
> development :-)
> 

As the author of much of the mbox code, I have long felt that the code 
should be tested in the trunk starting immediately after a release.
Yes, there is no rush for this code.

-pmr

Re: [rmail-mbox-branch]: expunge

[Richard Stallman]

We are a long way from the release--people have to do a lot of work on
the documentation, and then we need to pretest.  rmail-mbox-branch has
many bugs today which have not been fixed, but I will fix them soon,
if no one else does.

Re: [rmail-mbox-branch]: expunge

[Alexander Pohoyda]

Richard Stallman <rms@gnu.org> writes:

> We are a long way from the release--people have to do a lot of work on
> the documentation, and then we need to pretest.  rmail-mbox-branch has
> many bugs today which have not been fixed, but I will fix them soon,
> if no one else does.

I'm actively working on rmail-mbox-branch for one year now.  I had to
fix and redo many functions and the diff was growing too fast.  It's
200 KB (diffs to rmail*) + 20 KB (diffs to mail-utils) + 70 KB (a new
MIME library which is IMHO cleaner than the one we have in Gnus).

What's working already:
 * message sorting (name, date, size, etc.), filtering (based on
 labels), editing (complicated by MIME)
 * header field sorting, filtering, RFC 2047, RFC 2231
 * some text, image, message and multipart MIME handlers
 * simple MIME-compose functions (to be heavily changed soon)

I have some new ideas which I'll be working on.

I would very like to integrate all my changes into Emacs CVS, but it
is by no means complete or even better than the current
rmail-mbox-branch.


If you take my changes as a base, I will find time to fix whatever you
consider broken in my code.  Thank you.


-- 
Alexander Pohoyda <alexander.pohoyda@gmx.net>
PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72  15 54 5F 62 20 23 C6 44

Re: [rmail-mbox-branch]: expunge

[Richard Stallman]

    I'm actively working on rmail-mbox-branch for one year now.

If you had been sending or installing your changes all the while,
they might be easy to install now.  Saving them up was a mistake
because that will make it a lot of work to think about them.

So if you would like them to be installed someday, how about
starting to send us diffs?

[rmail-mbox-branch]: mail-utils

[Alexander Pohoyda]

Richard Stallman <rms@gnu.org> writes:

> So if you would like them to be installed someday, how about
> starting to send us diffs?

OK, let's start with the mail-utils.el, because it is used a lot
in Rmail.

Before I send diffs, I'd like to clear some general questions.


For example, the original implementation of `mail-[un]quote-printable'
functions is too limited.  I suppose that this is desired: 

(defun mail-quote-printable (string &optional wrapper)
 "Encode the STRING in such a way that the resulting octets are unlikely to
be modified by mail transport.  Defined by RFC 2045.
If the optional argument WRAPPER is non-nil, decorate the resulting string
with =?charset?Q?....?=, as defined by RFC 2047."
 (if wrapper
     (rfc2047-encode-string string)
   (rfc2045-quoted-printable-encode-string string)))


Now, there are many other functions and constants which are defined by
some RFCs and I have implemented them in such a way:

mime/
  rfc2045.el (13 functions)
  rfc2047.el (11 functions)
  rfc2231.el (7 functions)
  (some other less important files)

Functions in these files have corresponding `rfcXXXX-' prefix.
Functions of general use have aliases like this:
  (defalias 'mime-is-conformant 'rfc2045-is-conformant)
  (defalias 'quoted-printable-encode-string 'rfc2045-quoted-printable-encode-string)

Is this OK?


I would propose to add this new `mime' directory into
$EMACSROOT/lisp/mail/, but there are files named:

 rfc2045.el
 rfc2047.el
 rfc2231.el

in $EMACSROOT/lisp/gnus/ directory already.  While it's easy to merge
two versions of rfc2045.el, rfc2047.el is more troublesome.
The gnus/rfc2047.el file contains something like this:

 (require 'mm-util)
 ;; Fixme: Avoid this (used for mail-parse-charset) mm dependence on gnus.
 (require 'mail-prsvr)
 (require 'base64)
 (autoload 'mm-body-7-or-8 "mm-bodies")

and I decided that I better not merge pure RFC-defined functionality
with GNUS-specific functions.

What's your decision on this?


-- 
Alexander Pohoyda <alexander.pohoyda@gmx.net>
PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72  15 54 5F 62 20 23 C6 44

Re: [rmail-mbox-branch]: mail-utils

[Miles Bader]

On Wed, Oct 06, 2004 at 11:38:54PM +0200, Alexander Pohoyda wrote:
> The gnus/rfc2047.el file contains something like this:
> 
>  (require 'mm-util)
>  ;; Fixme: Avoid this (used for mail-parse-charset) mm dependence on gnus.
>  (require 'mail-prsvr)
>  (require 'base64)
>  (autoload 'mm-body-7-or-8 "mm-bodies")
> 
> and I decided that I better not merge pure RFC-defined functionality
> with GNUS-specific functions.

The mm- stuff seems not to be intended to be gnus-specific, but rather
general-purpose code for handling mime that happens to be developed as part
of gnus.

There are probably a few dependencies on gnus that have crept in, but I
presume these could be excised.

-Miles
-- 
Love is a snowmobile racing across the tundra.  Suddenly it flips over,
pinning you underneath.  At night the ice weasels come.  --Nietzsche

Re: [rmail-mbox-branch]: mail-utils

[Alexander Pohoyda]

Miles Bader <miles@gnu.org> writes:

> On Wed, Oct 06, 2004 at 11:38:54PM +0200, Alexander Pohoyda wrote:
> > The gnus/rfc2047.el file contains something like this:
> > 
> >  (require 'mm-util)
> >  ;; Fixme: Avoid this (used for mail-parse-charset) mm dependence on gnus.
> >  (require 'mail-prsvr)
> >  (require 'base64)
> >  (autoload 'mm-body-7-or-8 "mm-bodies")
> > 
> > and I decided that I better not merge pure RFC-defined functionality
> > with GNUS-specific functions.
> 
> The mm- stuff seems not to be intended to be gnus-specific, but rather
> general-purpose code for handling mime that happens to be developed as part
> of gnus.

Yes, I understand the intention.


> There are probably a few dependencies on gnus that have crept in, but I
> presume these could be excised.

Some mm-*.el files use quite often functions or constants with gnus-
prefix.  I would like to have a clean MIME library first.


-- 
Alexander Pohoyda <alexander.pohoyda@gmx.net>
PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72  15 54 5F 62 20 23 C6 44

Re: [rmail-mbox-branch]: mail-utils

[Miles Bader]

On Sat, Oct 09, 2004 at 01:34:49AM +0200, Alexander Pohoyda wrote:
> > The mm- stuff seems not to be intended to be gnus-specific, but rather
> > general-purpose code for handling mime that happens to be developed as part
> > of gnus.
> 
> Yes, I understand the intention.
> 
> 
> > There are probably a few dependencies on gnus that have crept in, but I
> > presume these could be excised.
> 
> Some mm-*.el files use quite often functions or constants with gnus-
> prefix.

Can you be more specific?  I did a grep, and the dependencies seem pretty
much restricted to a few files (e.g., mm-view.el); the most general mime
functionality seems pretty clean at first glance.

Note that some places the mm- stuff has code of the form:

  (if (or (eq foo ...) (eq foo ...) (eq foo 'gnus-magic-constant))
     ...)

But this sort of thing is perfectly fine -- it's not really a dependency at
all, because all it does is tweak the behavior specially for gnus in some
way.

> I would like to have a clean MIME library first.

Sure, and the mm- stuff seems like the right to start from.  It would
completely silly to reimplement all of it when mm- is pretty close to what
you want anyway.

Maybe I'm wrong, but if so, please give details, don't just assert it.

Thanks,

-Miles
-- 
I'm beginning to think that life is just one long Yoko Ono album; no rhyme
or reason, just a lot of incoherent shrieks and then it's over.  --Ian Wolff

Re: [rmail-mbox-branch]: mail-utils

[Alexander Pohoyda]

Miles Bader <miles@gnu.org> writes:

> On Sat, Oct 09, 2004 at 01:34:49AM +0200, Alexander Pohoyda wrote:
> > > The mm- stuff seems not to be intended to be gnus-specific, but rather
> > > general-purpose code for handling mime that happens to be developed as part
> > > of gnus.
> > 
> > Yes, I understand the intention.
> > 
> > 
> > > There are probably a few dependencies on gnus that have crept in, but I
> > > presume these could be excised.
> > 
> > Some mm-*.el files use quite often functions or constants with gnus-
> > prefix.
> 
> Can you be more specific?  I did a grep, and the dependencies seem pretty
> much restricted to a few files (e.g., mm-view.el);

Yes, there are only very few cases:

mm-partial.el:(require 'gnus-sum)
mm-partial.el:             (set-buffer gnus-summary-buffer)
mm-partial.el:    (gnus-request-article-this-buffer (aref header 0)
mm-partial.el:                     (gnus-summary-article-number))))
mm-partial.el:      (setq gnus-article-mime-handles
mm-partial.el:      (append (if (listp (car gnus-article-mime-handles))
mm-partial.el:                  gnus-article-mime-handles
mm-partial.el:                (list gnus-article-mime-handles))
mm-partial.el:      (run-hooks 'gnus-article-decode-hook)
mm-partial.el:      (gnus-article-prepare-display)

mm-uu.el:  :group 'gnus-article-mime)

mm-view.el:  (autoload 'gnus-article-prepare-display "gnus-art")
mm-view.el:       (run-hooks 'gnus-article-decode-hook)


My primary concern, however, is that mm- stuff is rather a MIME
parser (viewer), while rfc*.el files implement basic functions.
Wouldn't it be good to have these two things clearly separated?

If we don't separate mm- and basic MIME functions, and if we don't
move them out of gnus directory, people will continue to re-implement
basic functions.

Do you know of any good reason to have the mm-* stuff used in rfc*
files?

Anyway, we need MIME support in Rmail.  Would it be correct to make
Rmail depend on file from Gnus directory?  My idea is to move MIME
stuff into lisp/mail(/mime?) directory.  Both Gnus and Rmail could use
these basic functions.  All I propose to move, are few files:
    lisp/gnus/rfc2045.el
    lisp/gnus/rfc2047.el
    lisp/gnus/rfc2231.el
leaving mm-* files intact.  What exactly do you disagree with?

> > I would like to have a clean MIME library first.
> 
> Sure, and the mm- stuff seems like the right to start from.

By "MIME library" I mean functions like
    rfc2045-qp-decode-string,
    rfc2231-decode-string,
    rfc2047-decode-region
but not
    mm-inline-partial,
    mm-inline-image-xemacs,
    mm-setup-w3, 
    mm-inline-message

> would completely silly to reimplement all of it when mm- is pretty
> close to what you want anyway.

People may have their own ideas how to use MIME, let's not force them
to use mm- as a bonus.


-- 
Alexander Pohoyda <alexander.pohoyda@gmx.net>
PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72  15 54 5F 62 20 23 C6 44

Re: [rmail-mbox-branch]: mail-utils

[Stefan]

> My primary concern, however, is that mm- stuff is rather a MIME
> parser (viewer), while rfc*.el files implement basic functions.
> Wouldn't it be good to have these two things clearly separated?

I guess I'd agree with the following:
- changes that remove dependencies from rfc* to mm*
- changes that remove dependencies from mm* to gnus*
- moving rfc* and mm* files from gnus/ to mail/

I don't see a strong need to create a mime-only subdirectory (of course
mail/mime is even worse since we currently only support one level of
subdirectory).


        Stefan

Re: [rmail-mbox-branch]: mail-utils

[Alexander Pohoyda]

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

> > My primary concern, however, is that mm- stuff is rather a MIME
> > parser (viewer), while rfc*.el files implement basic functions.
> > Wouldn't it be good to have these two things clearly separated?
> 
> I guess I'd agree with the following:
> - changes that remove dependencies from rfc* to mm*

Great!  I'll work out the patch.

> - changes that remove dependencies from mm* to gnus*

That would be another step, OK?

> - moving rfc* and mm* files from gnus/ to mail/

Good.  I'm only interested in rfc* files, so that's what I'm advocating.


> I don't see a strong need to create a mime-only subdirectory (of course
> mail/mime is even worse since we currently only support one level of
> subdirectory).

OK, no problems, I agree to what you say.

Just for my education, what's the problem with two level directories? 


-- 
Alexander Pohoyda <alexander.pohoyda@gmx.net>
PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72  15 54 5F 62 20 23 C6 44

Re: [rmail-mbox-branch]: mail-utils

[Miles Bader]

On Sat, Oct 09, 2004 at 08:15:40PM +0200, Alexander Pohoyda wrote:
> > - changes that remove dependencies from rfc* to mm*
> 
> Great!  I'll work out the patch.

Please CC your patch to the ding list <ding@gnus.org>.

Thanks,

-Miles
-- 
"Though they may have different meanings, the cries of 'Yeeeee-haw!' and
 'Allahu akbar!' are, in spirit, not actually all that different."

Re: [rmail-mbox-branch]: mail-utils

[Alexander Pohoyda]

Miles Bader <miles@gnu.org> writes:

> On Sat, Oct 09, 2004 at 08:15:40PM +0200, Alexander Pohoyda wrote:
> > > - changes that remove dependencies from rfc* to mm*
> > 
> > Great!  I'll work out the patch.
> 
> Please CC your patch to the ding list <ding@gnus.org>.

Will do.  Does this mean that you agree with the separation now?

-- 
Alexander Pohoyda <alexander.pohoyda@gmx.net>
PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72  15 54 5F 62 20 23 C6 44

Re: [rmail-mbox-branch]: mail-utils

[Miles Bader]

On Sat, Oct 09, 2004 at 11:02:03PM +0200, Alexander Pohoyda wrote:
> > > Great!  I'll work out the patch.
> > 
> > Please CC your patch to the ding list <ding@gnus.org>.
> 
> Will do.  Does this mean that you agree with the separation now?

I have no objection to moving files around, or to removing unnecessary
dependencies.  The hierarchy (gnus -> mm -> rfc*) is reasonable.

Some care should be taken to not step on Gnus' toes -- e.g., if some rfc*.el
file uses a mm- function for a good reason, instead of just removing the
functionality, it should be replaced with something like a callback or
something.

Anyway, it's easier to talk with a patch.

Thanks,

-Miles
-- 
/\ /\
(^.^)
(")")
*This is the cute kitty virus, please copy this into your sig so it can spread.

Re: [rmail-mbox-branch]: mail-utils

[Miles Bader]

I wrote:
> I have no objection to moving files around, or to removing unnecessary
> dependencies.  The hierarchy (gnus -> mm -> rfc*) is reasonable.

Oh, BTW, of course the files should probably stay in their current location
in the Gnus distribution -- the renaming will only effect their location
within the Emacs source tree.

-Miles
-- 
Would you like fries with that?

Re: [rmail-mbox-branch]: mail-utils

[Richard Stallman]

    Oh, BTW, of course the files should probably stay in their current location
    in the Gnus distribution -- the renaming will only effect their location
    within the Emacs source tree.

If some files from Gnus are moved out of the gnus subdirectory, that
means we will maintain them as ordinary parts of Emacs.

It is fine if Gnus developers copy changes from these files, and
contribute changes to them.  But they can't just install new
versions of them as they do with the Gnus files.

Re: [rmail-mbox-branch]: mail-utils

[Miles Bader]

On Sun, Oct 10, 2004 at 11:15:51AM -0400, Richard Stallman wrote:
>     Oh, BTW, of course the files should probably stay in their current
>     location in the Gnus distribution -- the renaming will only effect
>     their location within the Emacs source tree.
> 
> If some files from Gnus are moved out of the gnus subdirectory, that
> means we will maintain them as ordinary parts of Emacs.
> 
> It is fine if Gnus developers copy changes from these files, and
> contribute changes to them.  But they can't just install new
> versions of them as they do with the Gnus files.

I'm not sure what the difference between "contribute new changes" and
"install new versions" is.  Do you mean that a patch from a gnus maintainer
would have to be posted to the mailing list to be put into emacs (unlike Gnus
changes)?

I don't like such a distinction in principle, as it has the potential be
extremely annoying for me (as the person who is currently dealing with
interfacing Gnus and Emacs).  However I'm not if it's would be a problem in
practice, because the Gnus branch Emacs is using is relatively slowly
changing: I would likely implement such a restriction simply by giving any
Gnus changes to "non-Gnus" files a more thorough examination -- and expect
that mostly they would be perfectly fine (minor bugfixes and the like) and
apply them.

I'll it up to the Gnus maintainers to comment on Alexander's (forthcoming)
patch in light of this.  If these files are mature enough that they should
rarely be changed, there may be no problem.

-Miles
-- 
My spirit felt washed.  With blood.  [Eli Shin, on "The Passion of the Christ"]

Re: [rmail-mbox-branch]: mail-utils

[Richard Stallman]

    I'm not sure what the difference between "contribute new changes" and
    "install new versions" is.

In the gnus directory, the Gnus developers occasionally copy in new
versions of the files.  (They look first for changes on our side that
ought not to be lost.)  But they should not do this for files
outside the gnus directory.

    Do you mean that a patch from a gnus maintainer would have to be
    posted to the mailing list to be put into emacs (unlike Gnus
    changes)?

I mean they should treat these files the same way they treat all the
other Lisp files that are not part of Gnus.  That does not mean ALL
changes have to be discussed.  They can install local uncontroversial
bug fixes without discussion, just as any of us would.  However,
beyond that, they ought to post on this list.

Re: [rmail-mbox-branch]: mail-utils

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
>     Do you mean that a patch from a gnus maintainer would have to be
>     posted to the mailing list to be put into emacs (unlike Gnus
>     changes)?
>
> I mean they should treat these files the same way they treat all the
> other Lisp files that are not part of Gnus.  That does not mean ALL
> changes have to be discussed.  They can install local uncontroversial
> bug fixes without discussion, just as any of us would.  However,
> beyond that, they ought to post on this list.

Ok, that sounds reasonable, and workable in practice for my Gnus-syncing.

-Miles
-- 
If you can't beat them, arrange to have them beaten.  [George Carlin]

Re: [rmail-mbox-branch]: mail-utils

[Juri Linkov]

> In the gnus directory, the Gnus developers occasionally copy in new
> versions of the files.  (They look first for changes on our side that
> ought not to be lost.)  But they should not do this for files
> outside the gnus directory.

There are other Gnus files in Emacs outside the gnus directory:
gnus.texi, gnus-faq.texi, message.texi + some other texi files in the
emacs/man directory.

Miles, are changes made in these files in Emacs CVS synced automagically
with the Gnus CVS repository?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: [rmail-mbox-branch]: mail-utils

[Miles Bader]

On Tue, Oct 12, 2004 at 05:42:38PM +0300, Juri Linkov wrote:
> > In the gnus directory, the Gnus developers occasionally copy in new
> > versions of the files.  (They look first for changes on our side that
> > ought not to be lost.)  But they should not do this for files
> > outside the gnus directory.
> 
> There are other Gnus files in Emacs outside the gnus directory:
> gnus.texi, gnus-faq.texi, message.texi + some other texi files in the
> emacs/man directory.
> 
> Miles, are changes made in these files in Emacs CVS synced automagically
> with the Gnus CVS repository?

Yes; these files are clearly part of Gnus, so it would be absurd to not do so.

-Miles
-- 
"Unless there are slaves to do the ugly, horrible, uninteresting work, culture
and contemplation become almost impossible. Human slavery is wrong, insecure,
and demoralizing.  On mechanical slavery, on the slavery of the machine, the
future of the world depends." -Oscar Wilde, "The Soul of Man Under Socialism"

Syncing Gnus with Emacs and back (was: [rmail-mbox-branch]: mail-utils)

[Reiner Steib]

On Tue, Oct 12 2004, Miles Bader wrote:

> On Tue, Oct 12, 2004 at 05:42:38PM +0300, Juri Linkov wrote:
[...]
>> There are other Gnus files in Emacs outside the gnus directory:
>> gnus.texi, gnus-faq.texi, message.texi + some other texi files in the
>> emacs/man directory.
>> 
>> Miles, are changes made in these files in Emacs CVS synced automagically
>> with the Gnus CVS repository?
>
> Yes; these files are clearly part of Gnus, so it would be absurd to
> not do so.

I saw that you have synced my recent changes from Gnus to Emacs, but
Juri's recent changes in emacs/man/gnus.texi haven't made it from
Emacs to Gnus (v5-10 and trunk).

There are also some changes in v5-10/texi/ that are not yet synced to
the Gnus trunk and to emacs/man.  (Sorry to bother you in case you are
already aware of it.)

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Syncing Gnus with Emacs and back

[Miles Bader]

Reiner Steib <reinersteib+gmane@imap.cc> writes:
> I saw that you have synced my recent changes from Gnus to Emacs, but
> Juri's recent changes in emacs/man/gnus.texi haven't made it from
> Emacs to Gnus (v5-10 and trunk).

I do Emacs->Gnus less often (than Gnus->Emacs) because it tends to
require more manual work.

By default I sync about once a week.  I also try to follow any Gnus
threads on the mailing lists and make sure any changes being discussed
are kept more up-to-date (so say 1-2 days delay for "topical" changes).

> There are also some changes in v5-10/texi/ that are not yet synced to
> the Gnus trunk and to emacs/man.  (Sorry to bother you in case you are
> already aware of it.)

Ok, I've synced up everything I know about.  If there's anything still
missing, let me know (that would probably mean I messed up resolving a
conflict or something).

Thanks,

-Miles
-- 
Quidquid latine dictum sit, altum viditur.

Re: Syncing Gnus with Emacs and back

[Reiner Steib]

On Wed, Oct 13 2004, Miles Bader wrote:

> I do Emacs->Gnus less often (than Gnus->Emacs) because it tends to
> require more manual work.
>
> By default I sync about once a week.  I also try to follow any Gnus
> threads on the mailing lists and make sure any changes being discussed
> are kept more up-to-date (so say 1-2 days delay for "topical" changes).

Sounds good.  Thanks for the explanation.

> Ok, I've synced up everything I know about.  If there's anything still
> missing, let me know (that would probably mean I messed up resolving a
> conflict or something).

One change in gnus-faq.texi needs to be synced from v5-10 to
emacs/man: revision 6.19.2.5 (Gnus CVS) is missing.  I think this
corresponds to miles@gnu.org--gnu-2004/gnus--rel--5.10--patch-46.

BTW, a disadvantage of the arch syncing is that e.g. in the cvs log of
texi/gnus-faq.texi we get the following:

,----[1]
| revision 7.5
| date: 2004/10/13 01:27:08;  author: miles;  state: Exp;  lines: +7 -4
| Revision: miles@gnu.org--gnu-2004/gnus--devo--0--patch-145
| 
| Merge from gnus--rel--5.10
| 
| Patches applied:
| 
|  * miles@gnu.org--gnu-2004/gnus--rel--5.10--patch-46
|    Update from CVS
`----

The original commit had the following log message:

,----[2]
| revision 6.19.2.5
| date: 2004/10/12 15:54:46;  author: rsteib;  state: Exp;  lines: +7 -4
| ([5.9]): Improve code for reply-in-news.
`----

In [1], there is no indication what this changes is about.  People
need to find and read the ChangeLog entry to find out what has been
changed.  It would be nice if the original log message could be
included.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Syncing Gnus with Emacs and back

[Miles Bader]

On Wed, Oct 13, 2004 at 10:21:42PM +0200, Reiner Steib wrote:
> BTW, a disadvantage of the arch syncing is that e.g. in the cvs log of
> texi/gnus-faq.texi we get the following:
...
> It would be nice if the original log message could be included.

A pretty basic constraint though is that all the files have to have the same
log message (it's a changeset log, not a file change log).  Furthermore it's
probably not practical to base this on CVS log messages[*].

However I've had pretty good success using "ChangeLog-changes" for this
purpose when generating log messages for emacs.  ChangeLog-changes are the
additions to all ChangeLogs, i.e., do a diff of all ChangeLogs, look for "+"
lines, and tweak them to be prettier -- it basically ends up looking like a
big ChangeLog entry for all files in the changeset.

[*] Several reasons: (1) CVS makes it quite difficult to retrieve the precise
log messages corresponding to an update, and (2) The CVS log messages for all
changed files would have to be combined, and getting a usable (not ugly and
bloated) result from this doesn't look at all easy given the typically
inconsistent log messages people use.

-Miles
-- 
`To alcohol!  The cause of, and solution to,
 all of life's problems' --Homer J. Simpson

Re: Syncing Gnus with Emacs and back

[Miles Bader]

Ok, I've implemented something so that future merges into Gnus, and into
the Emacs trunk[*] will have log messages like:

   Merge from $MERGE_VERSION

   $MERGE_LOG

   $CHANGELOG

Where $MERGE_LOG is the same sort of log that has been used up until
now, and $CHANGELOG is an aggregation of any new ChangeLog entries
present in the merge.

[*] Merges into Emacs branches will _not_ use this style; I thought they
might be too verbose, as such merges tend to contain large numbers of
changes, so such an aggregate changelog is less useful.

-Miles
-- 
We live, as we dream -- alone....

Re: [rmail-mbox-branch]: mail-utils

[Richard Stallman]

    There are other Gnus files in Emacs outside the gnus directory:
    gnus.texi, gnus-faq.texi, message.texi + some other texi files in the
    emacs/man directory.

Yes.  These are in a different directory but they are clearly part of
Gnus.

However, if we move some subroutines into different files and turn
them into general facilities for Emacs, they are not part of Gnus any
more.

Re: [rmail-mbox-branch]: mail-utils

[Stefan]

>> I don't see a strong need to create a mime-only subdirectory (of course
>> mail/mime is even worse since we currently only support one level of
>> subdirectory).

> OK, no problems, I agree to what you say.

I'm just yet-another-emacs-maintainer.  Only Richard can make final decisions.

> Just for my education, what's the problem with two level directories? 

Nothing serious.  It's just that the curent code doesn't support them.


        Stefan

Re: [rmail-mbox-branch]: mail-utils

[Alexander Pohoyda]

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

> >> I don't see a strong need to create a mime-only subdirectory (of
> >> course mail/mime is even worse since we currently only support
> >> one level of subdirectory).
> 
> > Just for my education, what's the problem with two level
> > directories?
> 
> Nothing serious.  It's just that the curent code doesn't support
> them.

Interesting.  I see no problems on my machine.  I have created a file
lisp/mail/subdirs.el, but I don't remember why I had to do that.


-- 
Alexander Pohoyda <alexander.pohoyda@gmx.net>
PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72  15 54 5F 62 20 23 C6 44

Re: [rmail-mbox-branch]: mail-utils

[Simon Josefsson]

Alexander Pohoyda <alexander.pohoyda@gmx.net> writes:

> Wouldn't it be good to have these two things clearly separated?

I support this.  Although I don't know whether using mm is all that
problematic.  I don't think the user need to use mm just because
rfc*.el uses it.  Modularizing files from Gnus is generally a good
thing.

As an aside, Lars once said, on the topic of rfc*.el, that "RFCs
wither and die, lisp is forever", arguing against rfc*.el as the name
of lisp files.  Instead, the RFC 2047 functionality could be moved
into qp.el, RFC 2231 could be moved into (say) encoded-word.el, etc.
One reason is that RFC numbers are obsoleted once in a while.

Re: [rmail-mbox-branch]: mail-utils

[Richard Stallman]

    For example, the original implementation of `mail-[un]quote-printable'
    functions is too limited.  I suppose that this is desired: 

    (defun mail-quote-printable (string &optional wrapper)
     "Encode the STRING in such a way that the resulting octets are unlikely to
    be modified by mail transport.  Defined by RFC 2045.
    If the optional argument WRAPPER is non-nil, decorate the resulting string
    with =?charset?Q?....?=, as defined by RFC 2047."
     (if wrapper
	 (rfc2047-encode-string string)
       (rfc2045-quoted-printable-encode-string string)))

I do not know whether that is desired; I don't understand it.

It looks like you are talking about functions in Gnus; I don't know
anything about those functions, though.  Gnus is more recent than
mail-utils.el, and the Gnus developers do not cooperate closely with
us, so it does not surprise me that they contain duplications and
perhaps useful facilities that we mostly do not know about.

    Now, there are many other functions and constants which are defined by
    some RFCs and I have implemented them in such a way:

    mime/
      rfc2045.el (13 functions)
      rfc2047.el (11 functions)
      rfc2231.el (7 functions)
      (some other less important files)

I do not understand what "such a way" means.  What way do you mean?
All I see here is a list of names (file names?); I don't know what
the names MEAN, so I don't understand.

Are you saying you have written files with the same names as certain
files in Gnus?

If that's what you mean, the simplest way to avoid conflict
is to rename these functions, then add them to mail-utils.el
or put them together in some other new file.  Why not?

Re: [rmail-mbox-branch]: mail-utils

[Alexander Pohoyda]

Richard Stallman <rms@gnu.org> writes:

>     For example, the original implementation of `mail-[un]quote-printable'
>     functions is too limited.  I suppose that this is desired: 
> 
>     (defun mail-quote-printable (string &optional wrapper)
>      "Encode the STRING in such a way that the resulting octets are unlikely to
>     be modified by mail transport.  Defined by RFC 2045.
>     If the optional argument WRAPPER is non-nil, decorate the resulting string
>     with =?charset?Q?....?=, as defined by RFC 2047."
>      (if wrapper
> 	 (rfc2047-encode-string string)
>        (rfc2045-quoted-printable-encode-string string)))
> 
> I do not know whether that is desired; I don't understand it.

I'll try to explain.

RFC 2045, among other things, defines quoted-printable encoding.

   The Quoted-Printable encoding is intended to represent data that
   largely consists of octets that correspond to printable characters in
   the US-ASCII character set.

RFC 2045 describes a mechanism for denoting textual body parts which
are coded in various character sets, as well as methods for encoding
such body parts as sequences of printable US-ASCII characters.

RFC 2047 defines similar techniques to allow the encoding of non-ASCII
text in various portions of a RFC 822 [2] message header, in a manner
which is unlikely to confuse existing message handling software.

Both techniques are used very often if you live outside of the US.


> It looks like you are talking about functions in Gnus;

These functions are currently implemented in Gnus, but they are
general MIME functions and are needed by Rmail or any other
MIME-related software.


>     Now, there are many other functions and constants which are
>     defined by some RFCs and I have implemented them in such a way:
> 
>     mime/
>       rfc2045.el (13 functions)
>       rfc2047.el (11 functions)
>       rfc2231.el (7 functions)
>       (some other less important files)
> 
> I do not understand what "such a way" means.  What way do you mean?

I propose to create a directory called "mime" in
"$EMACSROOT/lisp/mail" and put all MIME-related functionality in
there.

I further propose to group functions defined by RFCs (Request
For Comment) into corresponding files.  I have partly implemented
RFCs 2045, 2047 and 2231, but other will follow.

I ask you because I recall that you are opposed to creating new files
in the source tree.


> Are you saying you have written files with the same names as certain
> files in Gnus?

Exactly!  Once again, I propose that we move general-purpose MIME
functions out of lisp/gnus into lisp/mail/mime directory.

Are you OK with this?


> If that's what you mean, the simplest way to avoid conflict
> is to rename these functions, then add them to mail-utils.el
> or put them together in some other new file.  Why not?

Yes, we can put all MIME-related functions into mail-utils.el, but it
would be better to put them into a separate file (mime.el) or even a
separate directory (mime) with separate files implementing specific
RFCs, e.g. the file lisp/mail/mime/rfc2045.el contains functions
defined by RFC 2045.

Please choose and I will send a patch.


-- 
Alexander Pohoyda <alexander.pohoyda@gmx.net>
PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72  15 54 5F 62 20 23 C6 44

Re: [rmail-mbox-branch]: mail-utils

[Richard Stallman]

    > Are you saying you have written files with the same names as certain
    > files in Gnus?

    Exactly!  Once again, I propose that we move general-purpose MIME
    functions out of lisp/gnus into lisp/mail/mime directory.

I am not sure what you mean.  Do you mean moving the existing gnus
code, as now found in lisp/gnus/rfc*.el?  Or have you written
completely different code to do the same jobs?

Re: [rmail-mbox-branch]: mail-utils

[Alexander Pohoyda]

Richard Stallman <rms@gnu.org> writes:

>     > Are you saying you have written files with the same names as certain
>     > files in Gnus?
> 
>     Exactly!  Once again, I propose that we move general-purpose MIME
>     functions out of lisp/gnus into lisp/mail/mime directory.
> 
> I am not sure what you mean.  Do you mean moving the existing gnus
> code, as now found in lisp/gnus/rfc*.el?  Or have you written
> completely different code to do the same jobs?

I don't mean moving existing Gnus code (as it is now), because I don't
like that rfc*.el files depend on mm-*.el files.  Once we break this
dependency, we could move only rfc*.el files (what's what I target
right now).

Meanwhile, I have re-implemented about 20 rfc* functions because I
didn't like their dependency on mm-* code.  My implementation is also
cleaner in a way that it uses even more basic general-purpose mail
functions which I will try to put into mail-utils.el file.

So, in fact, I already have a completely mm-* independent
implementation, but it may be missing some function used by Gnus, so
I don't ask you to take my files either.

What I'm going to do now is to remove mm-* dependency from
lisp/gnus/rfc*.el files and submit a patch here.  If it is accepted
and commited, we move lisp/gnus/rfc*.el files into lisp/mail/
directory and I can continue with Rmail patches.


-- 
Alexander Pohoyda <alexander.pohoyda@gmx.net>
PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72  15 54 5F 62 20 23 C6 44

Re: [rmail-mbox-branch]: mail-utils

[Richard Stallman]

    Meanwhile, I have re-implemented about 20 rfc* functions because I
    didn't like their dependency on mm-* code.  My implementation is also
    cleaner in a way that it uses even more basic general-purpose mail
    functions which I will try to put into mail-utils.el file.

I like the idea of doing it this way.  How many lines do they add up
to?  Let's decide whether this should be one file or many.

    What I'm going to do now is to remove mm-* dependency from
    lisp/gnus/rfc*.el files and submit a patch here.

I cannot follow this part.  If we are replacing and eliminating the
code in lisp/gnus/rfc*.el, why talk about patching those files?

Re: [rmail-mbox-branch]: mail-utils

[Alexander Pohoyda]

Richard Stallman <rms@gnu.org> writes:

>     Meanwhile, I have re-implemented about 20 rfc* functions because I
>     didn't like their dependency on mm-* code.  My implementation is also
>     cleaner in a way that it uses even more basic general-purpose mail
>     functions which I will try to put into mail-utils.el file.
> 
> I like the idea of doing it this way.  How many lines do they add up
> to?  Let's decide whether this should be one file or many.

My "lightweight" implementation is currently ~20KB (organized in 6
files) plus ~16KB of new code for mail-utils.el file.

I'm perfectly fine with the idea to put those 20KB in one file (let's
call it lisp/mail/mime.el)


>     What I'm going to do now is to remove mm-* dependency from
>     lisp/gnus/rfc*.el files and submit a patch here.
> 
> I cannot follow this part.  If we are replacing and eliminating the
> code in lisp/gnus/rfc*.el, why talk about patching those files?

You're right, that sounds suboptimal.  However, I'm afraid that Gnus
people will not like the idea of adapting Gnus to a new code and I
don't want to force them to do this.  Then again, there may be almost
no adaptation needed.


-- 
Alexander Pohoyda <alexander.pohoyda@gmx.net>
PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72  15 54 5F 62 20 23 C6 44

Re: [rmail-mbox-branch]: mail-utils

[Richard Stallman]

    My "lightweight" implementation is currently ~20KB (organized in 6
    files) plus ~16KB of new code for mail-utils.el file.

    I'm perfectly fine with the idea to put those 20KB in one file (let's
    call it lisp/mail/mime.el)

Yes, let's do that.

    > I cannot follow this part.  If we are replacing and eliminating the
    > code in lisp/gnus/rfc*.el, why talk about patching those files?

    You're right, that sounds suboptimal.  However, I'm afraid that Gnus
    people will not like the idea of adapting Gnus to a new code and I
    don't want to force them to do this.

Sorry, what does this refer to?  Force them to do what?

Re: [rmail-mbox-branch]: mail-utils

[Alexander Pohoyda]

Richard Stallman <rms@gnu.org> writes:

>     > I cannot follow this part.  If we are replacing and eliminating the
>     > code in lisp/gnus/rfc*.el, why talk about patching those files?
> 
>     You're right, that sounds suboptimal.  However, I'm afraid that Gnus
>     people will not like the idea of adapting Gnus to a new code and I
>     don't want to force them to do this.
> 
> Sorry, what does this refer to?  Force them to do what?

Force Gnus developers to adapt Gnus to a new MIME library.

Anyway, I'm working on a patch and we'll see how the community will
like my code.

-- 
Alexander Pohoyda <alexander.pohoyda@gmx.net>
PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72  15 54 5F 62 20 23 C6 44

Re: [rmail-mbox-branch]: mail-utils

[Richard Stallman]

    >     You're right, that sounds suboptimal.  However, I'm afraid that Gnus
    >     people will not like the idea of adapting Gnus to a new code and I
    >     don't want to force them to do this.
    > 
    > Sorry, what does this refer to?  Force them to do what?

    Force Gnus developers to adapt Gnus to a new MIME library.

It would be easy to replace the old files with a compatible
interface to the new code.  Or just give the new code the same
interface.  Then they would not need to change
anything in Gnus.

how-many/count-matches for non-interactive use

[Alexander Pohoyda]

The `how-many' function is not especially friendly for non-interactive
use, because is issues a message.

Is there a better way to count matches from a lisp program?

How about this patch?

Index: replace.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/replace.el,v
retrieving revision 1.171
diff -u -r1.171 replace.el
--- replace.el	30 May 2004 21:50:35 -0000	1.171
+++ replace.el	13 Oct 2004 18:14:35 -0000
@@ -490,7 +490,9 @@
 	(if (= opoint (point))
 	    (forward-char 1)
 	  (setq count (1+ count))))
-      (message "%d occurrences" count))))
+      (if (interactive-p)
+	  (message "%d occurrences" count)
+	count))))
 
 \f
 (defvar occur-mode-map


-- 
Alexander Pohoyda <alexander.pohoyda@gmx.net>
PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72  15 54 5F 62 20 23 C6 44

Re: how-many/count-matches for non-interactive use

[Richard Stallman]

    How about this patch?

    Index: replace.el
    ===================================================================
    RCS file: /cvsroot/emacs/emacs/lisp/replace.el,v
    retrieving revision 1.171
    diff -u -r1.171 replace.el
    --- replace.el	30 May 2004 21:50:35 -0000	1.171
    +++ replace.el	13 Oct 2004 18:14:35 -0000
    @@ -490,7 +490,9 @@
	    (if (= opoint (point))
		(forward-char 1)
	      (setq count (1+ count))))
    -      (message "%d occurrences" count))))
    +      (if (interactive-p)
    +	  (message "%d occurrences" count)
    +	count))))

interactive-p is the wrong function to call here, because it is nil
when the command is called froma keyboard macro.  The right thing
to do here is to take an argument saying whether to print the message,
and use "p" in the interactive spec to set that argument non-nil
in an interactive call.

It seems that interactive-p as currently defined is very rarely useful
-- perhaps never.  Perhaps we should change interactive-p to ignore
whether the command is running from a macro and do what most people
seem to expect.

It would be useful for someone to find all calls to interactive-p
and see if any of them really want interactive-p to do what
it is currently defined to do.

I just grepped for it, and looked at two calls in bookmark.el;
I think the second one should be changed, but I can't tell
about the first with a quick glance.  I looked at the one call
in emerge.el and I think it should be changed.  I looked at
the call in env.el and I think it should be changed.

I looked at the call in faces.el, in describe-face, where it is used
as an argument to help-setup-xref.  It tells whether to clear the
stack of help xrefs followed.  I tend to think this should be changed,
because the command should behave the same in a macro as it would when
not called from a macro.

So are there any calls to interactive-p that really want it to return
nil when running in a keyboard macro?

Re: how-many/count-matches for non-interactive use

[Alexander Pohoyda]

Richard Stallman <rms@gnu.org> writes:

>     How about this patch?
> 
>     Index: replace.el
>     ===================================================================
>     RCS file: /cvsroot/emacs/emacs/lisp/replace.el,v
>     retrieving revision 1.171
>     diff -u -r1.171 replace.el
>     --- replace.el	30 May 2004 21:50:35 -0000	1.171
>     +++ replace.el	13 Oct 2004 18:14:35 -0000
>     @@ -490,7 +490,9 @@
> 	    (if (= opoint (point))
> 		(forward-char 1)
> 	      (setq count (1+ count))))
>     -      (message "%d occurrences" count))))
>     +      (if (interactive-p)
>     +	  (message "%d occurrences" count)
>     +	count))))
> 
> interactive-p is the wrong function to call here, because it is nil
> when the command is called froma keyboard macro.  The right thing
> to do here is to take an argument saying whether to print the message,
> and use "p" in the interactive spec to set that argument non-nil
> in an interactive call.

(defun how-many (regexp &optional rstart rend)
  "..."
  (interactive
   (keep-lines-read-args "How many matches for (regexp): "))

How do I use "p" here?


-- 
Alexander Pohoyda <alexander.pohoyda@gmx.net>
PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72  15 54 5F 62 20 23 C6 44

Re: how-many/count-matches for non-interactive use

[Richard Stallman]

    (defun how-many (regexp &optional rstart rend)
      "..."
      (interactive
       (keep-lines-read-args "How many matches for (regexp): "))

    How do I use "p" here?

Since it is using Lisp code, you just do it with more Lisp code.  Add
a t to the list in a place that corresponds to where the new extra arg
gets its value.

Re: how-many/count-matches for non-interactive use

[Alexander Pohoyda]

Richard Stallman <rms@gnu.org> writes:

>     (defun how-many (regexp &optional rstart rend)
>       "..."
>       (interactive
>        (keep-lines-read-args "How many matches for (regexp): "))
> 
>     How do I use "p" here?
> 
> Since it is using Lisp code, you just do it with more Lisp code.  Add
> a t to the list in a place that corresponds to where the new extra arg
> gets its value.

Like this?

Index: replace.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/replace.el,v
retrieving revision 1.171
diff -u -r1.171 replace.el
--- replace.el	30 May 2004 21:50:35 -0000	1.171
+++ replace.el	15 Oct 2004 15:30:02 -0000
@@ -457,8 +457,8 @@
 		       (progn (forward-line 1) (point)))))))
 
 
-(defun how-many (regexp &optional rstart rend)
-  "Print number of matches for REGEXP following point.
+(defun how-many (regexp &optional rstart rend verbose)
+  "Return the number of matches for REGEXP following point.
 
 If REGEXP contains upper case characters (excluding those preceded by `\\'),
 the matching is case-sensitive.
@@ -467,10 +467,14 @@
 
 Interactively, in Transient Mark mode when the mark is active, operate
 on the contents of the region.  Otherwise, operate from point to the
-end of the buffer."
+end of the buffer.
+
+If VERBOSE is t (or the function is called interactively), issue a message
+with the number of matches."
 
   (interactive
-   (keep-lines-read-args "How many matches for (regexp): "))
+   (append (keep-lines-read-args "How many matches for (regexp): ")
+	   '(nil nil t)))
   (save-excursion
     (if rstart
 	(goto-char (min rstart rend))
@@ -490,7 +494,8 @@
 	(if (= opoint (point))
 	    (forward-char 1)
 	  (setq count (1+ count))))
-      (message "%d occurrences" count))))
+      (when verbose (message "%d occurrences" count))
+      count)))
 
 \f
 (defvar occur-mode-map


-- 
Alexander Pohoyda <alexander.pohoyda@gmx.net>
PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72  15 54 5F 62 20 23 C6 44

Re: how-many/count-matches for non-interactive use

[Richard Stallman]

    > Since it is using Lisp code, you just do it with more Lisp code.  Add
    > a t to the list in a place that corresponds to where the new extra arg
    > gets its value.

    Like this?

It looks right to me, assuming that keep-lines-read-args
returns a list of one element (which it currently does).
You might instead do (list (car (keep-lines-read-args...)) nil nil t)
to make it clear you're taking just one arg value from that.

Re: how-many/count-matches for non-interactive use

[Alexander Pohoyda]

Richard Stallman <rms@gnu.org> writes:

>     > Since it is using Lisp code, you just do it with more Lisp code.  Add
>     > a t to the list in a place that corresponds to where the new extra arg
>     > gets its value.
> 
>     Like this?
> 
> It looks right to me, assuming that keep-lines-read-args
> returns a list of one element (which it currently does).
> You might instead do (list (car (keep-lines-read-args...)) nil nil t)
> to make it clear you're taking just one arg value from that.

Yes, I was considering that style too.  So here it goes.

Would somebody please install the change?  Thank you.


2004-10-16  Alexander Pohoyda  <alexander.pohoyda@gmx.net> (tiny change)

	* replace.el (how-many): New VERBOSE argument, which is used
	to suppress the message for non-interactive use.


Index: replace.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/replace.el,v
retrieving revision 1.171
diff -u -r1.171 replace.el
--- replace.el	30 May 2004 21:50:35 -0000	1.171
+++ replace.el	16 Oct 2004 20:12:49 -0000
@@ -457,8 +457,8 @@
 		       (progn (forward-line 1) (point)))))))
 
 
-(defun how-many (regexp &optional rstart rend)
-  "Print number of matches for REGEXP following point.
+(defun how-many (regexp &optional rstart rend verbose)
+  "Return the number of matches for REGEXP following point.
 
 If REGEXP contains upper case characters (excluding those preceded by `\\'),
 the matching is case-sensitive.
@@ -467,10 +467,14 @@
 
 Interactively, in Transient Mark mode when the mark is active, operate
 on the contents of the region.  Otherwise, operate from point to the
-end of the buffer."
+end of the buffer.
+
+If VERBOSE is t (or the function is called interactively), issue a message
+with the number of matches."
 
   (interactive
-   (keep-lines-read-args "How many matches for (regexp): "))
+   (list (car (keep-lines-read-args "How many matches for (regexp): "))
+	 nil nil t))
   (save-excursion
     (if rstart
 	(goto-char (min rstart rend))
@@ -490,7 +494,8 @@
 	(if (= opoint (point))
 	    (forward-char 1)
 	  (setq count (1+ count))))
-      (message "%d occurrences" count))))
+      (when verbose (message "%d occurrences" count))
+      count)))
 
 \f
 (defvar occur-mode-map


-- 
Alexander Pohoyda <alexander.pohoyda@gmx.net>
PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72  15 54 5F 62 20 23 C6 44

Re: how-many/count-matches for non-interactive use

[Stefan]

> interactive-p is the wrong function to call here, because it is nil
> when the command is called froma keyboard macro.  The right thing
> to do here is to take an argument saying whether to print the message,
> and use "p" in the interactive spec to set that argument non-nil
> in an interactive call.

Silly me, I never thought of abusing `p' for this purpose.
I always thought (why isn't there a letter for "always t") and the used
(interactive (list t)).

> It seems that interactive-p as currently defined is very rarely useful
> -- perhaps never.  Perhaps we should change interactive-p to ignore
> whether the command is running from a macro and do what most people
> seem to expect.

I think we should declare it obsolete because the alternative (of adding an
argument) is always clearer, less brittle, and allows callers better
control.  I've already been bitten once where I just "reorganized"
a function by moving a large subpart into its own function without noticing
that that subpart used `interactive-p'.


        Stefan

Re: how-many/count-matches for non-interactive use

[Richard Stallman]

    > It seems that interactive-p as currently defined is very rarely useful
    > -- perhaps never.  Perhaps we should change interactive-p to ignore
    > whether the command is running from a macro and do what most people
    > seem to expect.

    I think we should declare it obsolete because the alternative (of adding an
    argument) is always clearer, less brittle, and allows callers better
    control.

Before we say it is obsolete, we had better see if anyone does really
want it.  It would be very good for someone to determine which, if
any, of the current uses of interactive-p really want the current
behavior of interactive-p.

Re: how-many/count-matches for non-interactive use

[Stefan Monnier]

>> It seems that interactive-p as currently defined is very rarely useful
>> -- perhaps never.  Perhaps we should change interactive-p to ignore
>> whether the command is running from a macro and do what most people
>> seem to expect.

>     I think we should declare it obsolete because the alternative (of
>     adding an argument) is always clearer, less brittle, and allows
>     callers better control.

> Before we say it is obsolete, we had better see if anyone does really
> want it.  It would be very good for someone to determine which, if
> any, of the current uses of interactive-p really want the current
> behavior of interactive-p.

The current behavior can still be obtained without interactive-p by checking
executing-macro.  Doing it that way also has the advantage of being much
more clear.
I doubt anybody used interactive-p rather than an extra argument just
because of the subtle difference w.r.t keyboard macros.  I expect 99% of the
people who used interactive-p haven't even thought about the interaction
with keyboard macros.


        Stefan

Re: how-many/count-matches for non-interactive use

[Kim F. Storm]

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

>>> It seems that interactive-p as currently defined is very rarely useful
>>> -- perhaps never.  

Thinking more about it, I belive that the current behaviour of
interactive-p makes good sense in cases where it is used to determine
whether a command should do sit-for or output a message, as those are
typically not desireable during macro execution.

>>>                       Perhaps we should change interactive-p to ignore
>>> whether the command is running from a macro and do what most people
>>> seem to expect.
>
>>     I think we should declare it obsolete because the alternative (of
>>     adding an argument) is always clearer, less brittle, and allows
>>     callers better control.
>
>> Before we say it is obsolete, we had better see if anyone does really
>> want it.  It would be very good for someone to determine which, if
>> any, of the current uses of interactive-p really want the current
>> behavior of interactive-p.
>
> The current behavior can still be obtained without interactive-p by checking
> executing-macro.  Doing it that way also has the advantage of being much
> more clear.
> I doubt anybody used interactive-p rather than an extra argument just
> because of the subtle difference w.r.t keyboard macros.  I expect 99% of the
> people who used interactive-p haven't even thought about the interaction
> with keyboard macros.

You could just as well do

    (and  (not executing-macro) (interactive-p))

But without checking all current uses, it is hard to say what the right
functionality is.

I won't have time to do that ...

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: how-many/count-matches for non-interactive use

[Stefan Monnier]

> Thinking more about it, I belive that the current behaviour of
> interactive-p makes good sense in cases where it is used to determine
> whether a command should do sit-for or output a message, as those are
> typically not desireable during macro execution.

Sit-for doesn't wait when executed from a macro.  As for messages you might
be right in some (maybe even in many) cases but I doubt it matters much
since unless the message is the last in the macro it will just be
overwritten anyway.


        Stefan

Re: how-many/count-matches for non-interactive use

[Luc Teirlinck]

Stefan Monnier wrote:

   Sit-for doesn't wait when executed from a macro.  As for messages you might
   be right in some (maybe even in many) cases but I doubt it matters much
   since unless the message is the last in the macro it will just be
   overwritten anyway.

If the macro is called with M-1000 or M-0, then, if nothing else, all
these messages might slow macro execution down.  Moreover, if there
are at least two different messages printed during execution of the
macro, it will also get rid of all previous info in *Messages*.

It is not clear to me whether we are currently discussing _changing_
the behavior of `interactive-p', or declaring it obsolete.  

I believe that changing it now would be very bad.  The current
behavior is very well documented in both the docstring and the Elisp
manual (and even in comments in the source code and such) and has been
in effect for a long time.  We can theoretically check all occurrences
in the Emacs tree (although there are tons of those), but we can not
possibly check all packages not included with the Emacs distribution.

On the other hand, there also is the problem that `interactive-p'
returns t while _defining_ a keyboard macro.  It would appear to be
deceiving to the user to have different behavior while _defining_ the
macro and while executing it.

I do not know what declaring a function obsolete _exactly_ means.  I
believe that what we could do is keep the function around indefinitely
in its current form, but discourage its use in new code meant for
inclusion in Emacs.  If people write their own functions for private
use, they might find interactive-p more convenient than the
alternative.  It also would mean that we would not have to worry about
checking all existing calls _right now_.

We could then recommend the following in the Elisp manual:

     (defun foo (&optional interactive-p)
       (interactive "p")
       (when interactive-p
         (message "foo")))

if the message needs to be printed even during keyboard
macro-execution and:

     (defun foo (&optional interactive-p)
       (interactive "p")
       (or (not interactive-p)
	   executing-kbd-macro
           defining-kbd-macro
	   (message "foo")))
 
if not.

Note that the behavior of the latter version of `foo' differs from the
current behavior of `interactive-p' by not showing the message during
macro definition either.

Sincerely,

Luc.

Re: how-many/count-matches for non-interactive use

[Stefan Monnier]

> It is not clear to me whether we are currently discussing _changing_
> the behavior of `interactive-p', or declaring it obsolete.

I have no interest in changing it.  I want to mark it obsolete.


        Stefan

Re: how-many/count-matches for non-interactive use

[Kim F. Storm]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Stefan Monnier wrote:
>
>    Sit-for doesn't wait when executed from a macro.  As for messages you might
>    be right in some (maybe even in many) cases but I doubt it matters much
>    since unless the message is the last in the macro it will just be
>    overwritten anyway.
>
> If the macro is called with M-1000 or M-0, then, if nothing else, all
> these messages might slow macro execution down.  Moreover, if there
> are at least two different messages printed during execution of the
> macro, it will also get rid of all previous info in *Messages*.

Another good point in favour of the current functionality!

>
> On the other hand, there also is the problem that `interactive-p'
> returns t while _defining_ a keyboard macro.  It would appear to be
> deceiving to the user to have different behavior while _defining_ the
> macro and while executing it.

I see this as a feature -- not a problem.  

I think it would be far more confusing if a command behaves
differently when defining a macro.


> I do not know what declaring a function obsolete _exactly_ means.  I
> believe that what we could do is keep the function around indefinitely
> in its current form, but discourage its use in new code meant for
> inclusion in Emacs.  

Or enhance it:

(interactive-p)    => current behaviour
(interactive-p t)  => interactive or executing macro

(interactive-p 1)  => interactive or executing macro ONCE


>                      If people write their own functions for private
> use, they might find interactive-p more convenient than the
> alternative.  It also would mean that we would not have to worry about
> checking all existing calls _right now_.
>
> We could then recommend the following in the Elisp manual:

This would be good.

>
>      (defun foo (&optional interactive-p)
>        (interactive "p")
>        (when interactive-p
>          (message "foo")))
>
> if the message needs to be printed even during keyboard
> macro-execution and:
>
>      (defun foo (&optional interactive-p)
>        (interactive "p")
>        (or (not interactive-p)
> 	   executing-kbd-macro
>            defining-kbd-macro
> 	   (message "foo")))
>  
> if not.
>
> Note that the behavior of the latter version of `foo' differs from the
> current behavior of `interactive-p' by not showing the message during
> macro definition either.
>
> Sincerely,
>
> Luc.
>
>
>
>

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: how-many/count-matches for non-interactive use

[Richard Stallman]

    If the macro is called with M-1000 or M-0, then, if nothing else, all
    these messages might slow macro execution down.

That is the motive for the existing definition of interactive-p.

    It is not clear to me whether we are currently discussing _changing_
    the behavior of `interactive-p', or declaring it obsolete.  

Someone proposed declaring it obsolete, but that by itself won't solve
the problem.

The immediate problem is that there are many uses of interactive-p,
and many of them, perhaps all, are now incorrect.  We need to either
change those uses or change interactive-p.  If we change
interactive-p, the uses which are now incorrect will become correct.
However, any uses which are now correct would need to be changed.

These are the ONLY two approaches that would make these commands
correct.

The first step in fixing this is to take inventory.  Which uses of
interactive-p are correct with the current definition of
interactive-p?  Which would be correct with the modified definition of
interactive-p that would not check for macros?

Would someone like to check them?

    On the other hand, there also is the problem that `interactive-p'
    returns t while _defining_ a keyboard macro.  It would appear to be
    deceiving to the user to have different behavior while _defining_ the
    macro and while executing it.

If we change the definition, it won't check for macros at all.

Re: how-many/count-matches for non-interactive use

[Luc Teirlinck]

Richard Stallman wrote:

   The immediate problem is that there are many uses of interactive-p,
   and many of them, perhaps all, are now incorrect.  We need to either
   change those uses or change interactive-p.

It would definitely seem to be a lot better to change existing
"incorrect" (whatever that means, it seems to be completely
subjective) uses than to change `interactive-p'.  This way we will
not break any currently correct code in the Emacs distribution, third
party packages, user Elisp functions and, most importantly, user
defined keyboard macros.  The current behavior has been in place for a
long time and users have defined (and saved) their keyboard macros to
work with that behavior.

The most convenient way to change any currently "wrong" uses would, in
my opinion, be to go with Kim's suggestion:

   (interactive-p)    => current behaviour
   (interactive-p t)  => interactive or executing macro

   (interactive-p 1)  => interactive or executing macro ONCE

I am not _completely_ sure about the last line, however.

   The first step in fixing this is to take inventory.  Which uses of
   interactive-p are correct with the current definition of
   interactive-p?  Which would be correct with the modified definition of
   interactive-p that would not check for macros?

I doubt that many uses are going to be obviously "correct" or
"incorrect".  It all depends on what the keyboard macro in which it is
going to be used is designed to do.  But users have designed (and
saved) their keyboard macros to work with the current behavior.  I
believe we should be very conservative before changing the current
behavior for any individual function.  Certainly, we should not change
the default behavior of `interactive-p'.

   Would someone like to check them?

There are tons of them.  We can have 100 message long discussions
about nearly every single one of them, because all of them are likely
to be subjective and depend on the type of keyboard macro.  If we
leave _everything_ as is we will not break one single currently
correct keyboard macro.

In as far as the current example is concerned, it would seem _wrong_
to _try_ to show the how-many/count-matches messages in an executing
keyboard macro, like it is wrong to _try_ to show _any_ message in a
keyboard macro.  The reason for that is that it does not work anyway.

Try the following.

emacs -q

C-M-x the following:

(defun myfun ()
  (interactive)
  (message "This is the message"))

Note, no `interactive-p'.

Move point to end of buffer.

C-x ( a M-x myfun RET C-x )

We now have defined a keyboard macro.

Question:

How do we execute this macro in such a way that "This is the message"
gets printed in the echo area?  It does reliably get printed to
*Messages*, but how many users routinely check *Messages*?

Maybe the above could be considered a bug that should be fixed.  But
even if this "bug" would be fixed, then if the macro is executed with
`C-x e', the "(Type e to repeat macro)" message will still overwrite
any message that the macro would try to print.

Sincerely,

Luc.

Re: how-many/count-matches for non-interactive use

[Luc Teirlinck]

>From my previous message:

   How do we execute this macro in such a way that "This is the message"
   gets printed in the echo area?

Well, since it got printed to *Messages*, it must have gotten printed
in the echo area for some small fraction of a second.  So the real
question is:

How do we execute this macro in such a way that we are actually able
to _notice_ that "This is the message" got printed in the echo area?

I have a reasonably fast computer.  Who knows, maybe it actually works
on a very slow computer.

Sincerely,

Luc.

Re: how-many/count-matches for non-interactive use

[Kim F. Storm]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Richard Stallman wrote:
>
>    The immediate problem is that there are many uses of interactive-p,
>    and many of them, perhaps all, are now incorrect.  We need to either
>    change those uses or change interactive-p.
>
> It would definitely seem to be a lot better to change existing
> "incorrect" (whatever that means, it seems to be completely
> subjective) uses than to change `interactive-p'.  This way we will
> not break any currently correct code in the Emacs distribution, third
> party packages, user Elisp functions and, most importantly, user
> defined keyboard macros.  The current behavior has been in place for a
> long time and users have defined (and saved) their keyboard macros to
> work with that behavior.

Fully agree.

>
> The most convenient way to change any currently "wrong" uses would, in
> my opinion, be to go with Kim's suggestion:
>
>    (interactive-p)    => current behaviour
>    (interactive-p t)  => interactive or executing macro
>
>    (interactive-p 1)  => interactive or executing macro ONCE
>
> I am not _completely_ sure about the last line, however.

It would be true if C-x e or C-x e e e,
but not if M-2 C-x e or C-u C-x e.

>    Would someone like to check them?
>
> There are tons of them.  We can have 100 message long discussions
> about nearly every single one of them, because all of them are likely
> to be subjective and depend on the type of keyboard macro.  If we
> leave _everything_ as is we will not break one single currently
> correct keyboard macro.
>
> In as far as the current example is concerned, it would seem _wrong_
> to _try_ to show the how-many/count-matches messages in an executing
> keyboard macro, like it is wrong to _try_ to show _any_ message in a
> keyboard macro.  

I agree, so in the current example, interactive-p actually does the
right thing IMO.  So as there is no clear idea of what is "correct",
checking anything seems futile.

>                  The reason for that is that it does not work anyway.
>
> How do we execute this macro in such a way that "This is the message"
> gets printed in the echo area?  It does reliably get printed to
> *Messages*, but how many users routinely check *Messages*?

Actually, you can't!!!  

I tried to make a quick fix for this, but the "This is a message"
still doesn't appear... because there is an explicit check in the C
code for `message':

  if (INTERACTIVE)
    {
       ... output message in echo area ...
    }

where the definition of INTERACTIVE closely matches that of
interactive-p:

/* Nonzero if input is coming from the keyboard */

#define INTERACTIVE (NILP (Vexecuting_macro) && !noninteractive)


So no matter whether we use interactive-p in the current or new
form, it cannot be used to determine whether message should
print in the echo area during macro execution -- message doesn't
print in that case!

So what's the point in the whole discussion ?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: how-many/count-matches for non-interactive use

[Alexander Pohoyda]

storm@cua.dk (Kim F. Storm) writes:

> So what's the point in the whole discussion ?

I thought that issuing a message makes no sense when how-many function
is called from a LISP code.  That was my bad idea to use
(interactive-p) here.  I'm sorry for this.

My last patch does not use interactive-p.  Do you see any other
problems why it is not accepted yet?


-- 
Alexander Pohoyda <alexander.pohoyda@gmx.net>
PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72  15 54 5F 62 20 23 C6 44

Re: how-many/count-matches for non-interactive use

[Kim F. Storm]

Alexander Pohoyda <alexander.pohoyda@gmx.net> writes:

> storm@cua.dk (Kim F. Storm) writes:
>
>> So what's the point in the whole discussion ?
>
> I thought that issuing a message makes no sense when how-many function
> is called from a LISP code.  That was my bad idea to use
> (interactive-p) here.  I'm sorry for this.
>
> My last patch does not use interactive-p.  Do you see any other
> problems why it is not accepted yet?

Actually, we are a couple of persons who think interactive-p was the
correct thing to use there...

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: how-many/count-matches for non-interactive use

[Richard Stallman]

    It would definitely seem to be a lot better to change existing
    "incorrect" (whatever that means, it seems to be completely
    subjective) uses than to change `interactive-p'.  This way we will
    not break any currently correct code in the Emacs distribution, third
    party packages, user Elisp functions and, most importantly, user
    defined keyboard macros.

If most of the uses in Emacs are wrong, and expect interactive-p
to have the other meaning, I would expect that the same is true
for most uses of interactive-p outside Emacs.  After all, those
installed in Emacs have received more scrutiny by Emacs developers.

      The current behavior has been in place for a
    long time and users have defined (and saved) their keyboard macros to
    work with that behavior.

Sorry, I do not understand.  In what way would a keyboard macro be
defined "to work with" the current behavior?  How would anyone have
defined any keyboard macro differently if interactive-p worked the
other way.  I do not see it.  This change would cause certain commands
to work differently in keyboard macros, yes, but there is nothing you
can do in a keyboard macro to select the other behavior.  And there
still will be nothing if this change is made.

       The first step in fixing this is to take inventory.  Which uses of
       interactive-p are correct with the current definition of
       interactive-p?  Which would be correct with the modified definition of
       interactive-p that would not check for macros?

    I doubt that many uses are going to be obviously "correct" or
    "incorrect".

We can judge each of them by some predecided criteria of what is
right.

    In as far as the current example is concerned, it would seem _wrong_
    to _try_ to show the how-many/count-matches messages in an executing
    keyboard macro, like it is wrong to _try_ to show _any_ message in a
    keyboard macro.

I don't agree at all.

    Maybe the above could be considered a bug that should be fixed.  But
    even if this "bug" would be fixed, then if the macro is executed with
    `C-x e', the "(Type e to repeat macro)" message will still overwrite
    any message that the macro would try to print.

Investigating the reason for this, I found that message3_nolog tests
INTERACTIVE, which is 0 when executing a macro.  Thus, calls to
`message' never display a message while in a keyboard macro.  They
write into the *Messages* buffer, and that's all they do.  So all
calls to interactive-p to decide whether to call `message' should be
judged based on whether we want to put the message into *Messages*.

Anything but a progress message should go into *Messages*.

Would someone like to start checking the code that uses interactive-p
and judge them?  You could put each instance into one of these four
categories:

* Needs the current definition of interactive-p to be correct.
* Needs the changed definition of interactive-p to be correct.
* Is correct either way.
* You're not sure.

If you do that for even 10 of the uses, we should start to get a
picture.

Re: how-many/count-matches for non-interactive use

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

> So all
> calls to interactive-p to decide whether to call `message' should be
> judged based on whether we want to put the message into *Messages*.

Right!  So we should fix the doc string for message to state that
messages are not shown when executing a macro.

> Anything but a progress message should go into *Messages*.

In principle yes, in practice I'm not sure..

If I use such a command in a macro and I do M-1000 C-x e, I get
1000 similar messages in *Messages* -- or actually just the last
message-log-max (50) copies. ... for what purpose ?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: how-many/count-matches for non-interactive use

[Richard Stallman]

    > Anything but a progress message should go into *Messages*.

    In principle yes, in practice I'm not sure..

    If I use such a command in a macro and I do M-1000 C-x e, I get
    1000 similar messages in *Messages* -- or actually just the last
    message-log-max (50) copies. ... for what purpose ?

That is an interesting question--what to do when the macro is repeated
so many times.  Perhaps that case should be handled differently.
For instance, if a macro is repeating many times, maybe only in the last
few times should Fmessage actually put something into *Messages*.
Before them maybe it could insert a line of ellipses.

Would you like to implement that?  It could be done with changes
in xdisp.c.  To reliably get the last iterations might require
inserting the messages on every iteration, but deleting each iteration
once it gets "old".  This is a little like what message-log-max
does; you could think of it as a separate limit on messages from
macros.

But this has nothing to do with what to do about interactive-p and
its callers.

Re: how-many/count-matches for non-interactive use

[Luc Teirlinck]

>From my previous message:

   In other words, instead of changing the behavior of `interactive-p',
   it would seem to make relatively more sense to do (in the `how-many' code
   and any similar places):

   (if (interactive-p)
       (message "%d occurrences" count)
     (with-current-buffer "*Messages*"
       (insert (format "%d occurrences" count))))

Well:

(insert (format "%d occurrences\n" count))

Sincerely,

Luc.

Re: how-many/count-matches for non-interactive use

[Luc Teirlinck]

Richard Stallman wrote:

   If most of the uses in Emacs are wrong,

There is one thing I know with absolute certainty: the current
behavior of `interactive-p' is correct for every single one of the
many keyboard macros I have ever written.  The proposed new behavior
would be wrong for every single macro I have ever written and for
which it would make any difference.  It would slow them down a lot and
those that print at least two different messages would hopelessly ruin
my *Messages* buffers by replacing important information with junk.
(Most of the time, keyboard macros are repeated countless times.)

A keyboard macro is a poor man's Lisp function.  There are two reasons
for using a keyboard macro: because the user does not know Lisp, or
because defining a keyboard macro takes less time than writing a Lisp
function.  Before I learned Elisp, I used tons of sometimes very
complex keyboard macros for the first reason.  Now I still
occasionally use keyboard macros for the second reason.  Probably the
main reason to use a Lisp function instead of a keyboard macro (for
something that can actually be done using a keyboard macro) is that it
tends to run a lot faster.  The choice between keyboard macro and Lisp
function is determined by necessity or convenience and by execution
speed.  It has nothing to do with wanting or not wanting messages to
be printed to *Messages*.

Like during execution of a Lisp function and unlike real interactive
use, the user does not get to enter arguments in the minibuffer during
execution of a macro.  The arguments are given during definition of
the macro.  Like in a Lisp function, the user can not determine what
to do after each command in the macro, except the last.  A command
that is part of a keyboard macro is much more like a command invoked
from a Lisp function than a really interactively invoked command.

Actually, one has to be a lot _more_ careful with messages during
macro execution than during Lisp function execution.  The absolute
_worst_ time to print messages is during long loops.  It slows things
down tremendously and hopelessly clobbers *Messages*.  I use most
keyboard macros with very large or zero numeric arguments, that is, in
long loops.  I suspect most people do.

Sincerely,

Luc.

Re: how-many/count-matches for non-interactive use

[David Kastrup]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Actually, one has to be a lot _more_ careful with messages during
> macro execution than during Lisp function execution.  The absolute
> _worst_ time to print messages is during long loops.  It slows things
> down tremendously and hopelessly clobbers *Messages*.  I use most
> keyboard macros with very large or zero numeric arguments, that is, in
> long loops.  I suspect most people do.

(defun execute-keyboard-macro
  [...]
  (let (saved-message)
     (flet (message (&rest args) (setq saved-message args))
        [execute the keyboard macro as often as wanted])
     (when saved-message
        (message "In macro: %s" (apply #'format saved-message)))))

Something like that.  Note that only the last message will actually
get formatted.     

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: how-many/count-matches for non-interactive use

[Robert J. Chassell]

As Luc Teirlinck said,

    A keyboard macro is a poor man's Lisp function. 

Ten or twelve years ago, GNU Emacs Calc contained a function that
converted keyboard macros to GNU Emacs Lisp functions.  It might be
useful to focus again on this.  Such a conversion function might help
novices and those who put short expressions in their .emacs files.

The original conversion function was not very good.  It did not print
the resulting defun right and it did not take arguments.  It changed a
few commands to others.  But it was good enough as a beginning.

For example, if I remember rightly, the conversion function could take
a keyboard macro named `foo'

     C-x ( C-s Emacs C-b C-b C-b C-b C-b GNU C-n C-a C-x )

and create a function that looked like this:

    (defun foo ()
      (interactive)
      (search-forward "Emacs")
      (backward-char)
      (backward-char)
      (backward-char)
      (backward-char)
      (backward-char)
      (insert "G")
      (insert "N")
      (insert "U")
      (insert " ")
      (next-line)
      (beginning-of-line))

(except that the result was more poorly pretty printed), rather than
this:

    C-s Emacs 5*C-b GNU SPC C-n C-a
or
    (fset 'foo
       (lambda (&optional arg) "Keyboard macro." (interactive "p") (kmacro-exec-ring-item (quote ("\x13Emacs\x02\x02\x02\x02\x02GNU \x0e\x01" 0 "%d")) arg)))

I lost interest in the function and now cannot find it.  Either I have
not looked well enough or it has been removed from the sources.

Interestingly, the `kmacro-edit-macro-repeat' command (`C-x C-k C-e')
lists command names as comments.  Perhaps the fairly deficient
conversion function transmogrified into this command.

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: how-many/count-matches for non-interactive use

[Luc Teirlinck]

Richard Stallman wrote:

	 The current behavior has been in place for a
       long time and users have defined (and saved) their keyboard macros to
       work with that behavior.

   Sorry, I do not understand.  In what way would a keyboard macro be
   defined "to work with" the current behavior?  How would anyone have
   defined any keyboard macro differently if interactive-p worked the
   other way.  I do not see it.

When the user currently tests a keyboard macro, he tests it with the
current behavior.  Hence, the current behavior of `interactive-p'
determines whether the macro does what the user wants it to do,
whether it does it fast enough and without negative side effects, like
ruining *Messages*.

   Anything but a progress message should go into *Messages*.

Definitely not.  For instance, messages that are supposed to help the
user decide what to do next are useless during macro execution.  (But
not during macro definition, so I now believe that the current
behavior is completely correct.)

Sincerely,

Luc.

Re: how-many/count-matches for non-interactive use

[Richard Stallman]

       Anything but a progress message should go into *Messages*.

    Definitely not.  For instance, messages that are supposed to help the
    user decide what to do next are useless during macro execution.

Maybe you are right about that.

So, are the messages which currently are controlled by testing
interactive-p messages of that kind?  Someone should look.

    When the user currently tests a keyboard macro, he tests it with the
    current behavior.  Hence, the current behavior of `interactive-p'
    determines whether the macro does what the user wants it to do,

This argument assumes that people who wrote this code knew what they
were doing.  I can't assume that.  I want to see what sort of messages
they really are.  I want someone to look at them.

      I use most
    > keyboard macros with very large or zero numeric arguments, that is, in
    > long loops.

I don't.

Re: how-many/count-matches for non-interactive use

[Luc Teirlinck]

What I do not understand at all is:

If it is so important for a message to be printed to *Messages*,
during execution of a keyboard macro, then why would it no longer be
important if the user wants to increase efficiency by converting the
macro to an Elisp function?

This thread started with the following (quoted from Alexander
Pohoyda):

   The `how-many' function is not especially friendly for non-interactive
   use, because is issues a message.

Unless I missed it, no example of a Lisp function calling `how-many'
where this caused problems was given.  But assuming there is such a
function, then assuming that a non-Elisp programmer wants to achieve a
similar functionality using a keyboard macro instead of a function,
why would it no longer be a nuisance?  Because it is not printed in
the echo area?  The person getting the functionality from a keyboard
macro apparently needs to have the message printed to *Messages*.  Why
does the person getting the functionality from a Lisp function not
need that?

In other words, instead of changing the behavior of `interactive-p',
it would seem to make relatively more sense to do (in the `how-many' code
and any similar places):

(if (interactive-p)
    (message "%d occurrences" count)
  (with-current-buffer "*Messages*"
    (insert (format "%d occurrences" count))))

or something similar.

Sincerely,

Luc.

Re: how-many/count-matches for non-interactive use

[Richard Stallman]

The discussion seems to have wandered into a tangent about
how to best convert keyboard macros to Lisp.

Convert keyboard macros to Lisp (was: how-many/count-matches for non-interactive use)

[Juri Linkov]

Richard Stallman <rms@gnu.org> writes:
> The discussion seems to have wandered into a tangent about
> how to best convert keyboard macros to Lisp.

I tend to avoid using keyboard macros as much as possible because when
requirements for a macro are changed beyond the macro capabilities all
user's efforts on defining a macro are wasted and Lisp code needs to be
written from scratch.

Bob already mentioned an old command that would convert a keyboard
macro to an Emacs Lisp program.  I am not aware of such a command,
but I think it would be useful.  It also might serve as a quick start
for writing Lisp code: to generate most of Lisp function calls after
typing corresponding keys and add complex Lisp constructs manually later.

I imagine that such command can't convert a keyboard macro to Lisp code
statically since a keyboard macro may switch buffers where keys have
different bindings.  It should perform conversion either during macro
definition or execution.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Convert keyboard macros to Lisp (was: how-many/count-matches for non-interactive use)

[Richard Stallman]

    Bob already mentioned an old command that would convert a keyboard
    macro to an Emacs Lisp program.  I am not aware of such a command,
    but I think it would be useful.


I agree it would be a good thing to add.

Re: how-many/count-matches for non-interactive use

[Luc Teirlinck]

Richard Stallman wrote:

   The discussion seems to have wandered into a tangent about
   how to best convert keyboard macros to Lisp.

The argument I made is that it should be _possible_ to convert a
keyboard macro into a Lisp function.  Hence if some command needs to
printed to *Messages* during macro execution, then it should be
possible to have that command print the same message from Lisp.
Hence if printing the message from Lisp _by default_ is undesirable in
such a situation, one needs to use an argument, as explained in
`(elisp)Interactive Call'.

Hence the current behavior of interactive-p is correct.

Sincerely,

Luc.

Re: how-many/count-matches for non-interactive use

[Luc Teirlinck]

Sorry, I messed up a previous message, by not properly including it in
this thread.  Here is a copy:

I took a look at all calls to `interactive-p' in the Emacs Elisp code.
For many (actually most) it is impossible to check whether the call is
"correct" without studying tons of code, which I did not do and am not
going to do.  For most others, the current behavior prevents nuisance
messaging, as intended.

_Maybe_ the following are exceptions to that (they should be checked
further).  Most of these seem to abuse `interactive-p' to read their
arguments outside the interactive declaration.  (Something that should
be avoided anyway, regardless of the negative effect on keyboard
macros.)

1. Info-goto-emacs-key-command-node

I can not check this one right now, because
`Info-goto-emacs-command-node' seems broken.  I do not even know
whether this is worth worrying about.  It would seem to make no sense
to define a macro that always checks the documentation for the _same_
command.  Better use bookmarks in that case.

2.  Three functions in `indent.el'.  I could check these out further.
    If they give any problems, they are trivial to fix.

Apart from that, two files _seem_ to have problems: ibuf-ext.el, in
particular the function `ibuffer-jump-to-buffer' and allout.el, in
particular `allout-init', `allout-backward-current-level' and maybe
others.  I CC the maintainers of those files.  They can better
determine than I do whether the calls to interactive-p in those files
are appropriate and in particular, appropriate for keyboard macros.

Like I said I do not know whether the above list of (potential)
problems is exhaustive.  It probably is not.  Checking every single
call to `interactive-p' in detail is hopeless.  But what we know is
that the current behavior of `interactive-p', which has been in place
for a long time, has not exactly led to a flood of complaints from
keyboard macro users.  Keyboard macro users appear to be happy with
the current situation. What we do not know is whether changing the
behavior will lead to a flood a bug reports and complaints about macro
execution speed getting ruined.

Sincerely,

Luc.

Re: how-many/count-matches for non-interactive use

[Luc Teirlinck]

>From my previous message:

   2.  Three functions in `indent.el'.  I could check these out further.
       If they give any problems, they are trivial to fix.

I checked it now.  The functions `set-left-margin' and
`set-right-margin' do not give any problems with keyboard macros.
However, their call to `interactive-p' is a useless and ugly no-op.
The `N' interactive code _gives_ the numeric prefix argument, hence
the lines removed in the patch below are useless and confusing.

In as far as `increase-right-margin' is concerned, I did not check its
effect on keyboard macros, because again, the call to `interactive-p'
is stylistically ugly.  It is inconsistent with the way exactly the
same thing gets achieved in `set-left-margin', `set-right-margin' and
`decrease-right-margin' and with the usual way to handle this in other
places in Emacs.

I propose the following patch to indent.el.  It eliminates all uses of
`interactive-p' from indent.el.  I can install if desired.

That leaves _maybe_ problems in ibuf-ext.el and allout.el.  I have the
impression that here again the (maybe) offending calls to
interactive-p should be eliminated and that the argument reading should
instead be done in the interactive calls.  I am not really familiar
with these files however and I will leave this up to the maintainers of
the respective files.

Proposed patch to indent.el:

===File ~/indent.el-diff====================================
*** indent.el	29 Sep 2004 20:45:32 -0500	1.58
--- indent.el	22 Oct 2004 19:47:31 -0500	
***************
*** 205,211 ****
  Interactively, WIDTH is the prefix argument, if specified.
  Without prefix argument, the command prompts for WIDTH."
    (interactive "r\nNSet left margin to column: ")
-   (if (interactive-p) (setq width (prefix-numeric-value width)))
    (save-excursion
      ;; If inside indentation, start from BOL.
      (goto-char from)
--- 205,210 ----
***************
*** 229,235 ****
  Interactively, WIDTH is the prefix argument, if specified.
  Without prefix argument, the command prompts for WIDTH."
    (interactive "r\nNSet right margin to width: ")
-   (if (interactive-p) (setq width (prefix-numeric-value width)))
    (save-excursion
      (goto-char from)
      (skip-chars-backward " \t")
--- 228,233 ----
***************
*** 289,300 ****
  the right margin width.
  If `auto-fill-mode' is active, re-fill the region to fit the new margin."
    (interactive "r\nP")
!   (if (interactive-p)
!       (setq inc (if inc (prefix-numeric-value current-prefix-arg)
! 		  standard-indent)))
    (save-excursion
      (alter-text-property from to 'right-margin
!        (lambda (v) (+ inc (or v 0))))
      (if auto-fill-function
  	(fill-region from to nil t t))))
  
--- 287,296 ----
  the right margin width.
  If `auto-fill-mode' is active, re-fill the region to fit the new margin."
    (interactive "r\nP")
!   (setq inc (if inc (prefix-numeric-value inc) standard-indent))
    (save-excursion
      (alter-text-property from to 'right-margin
! 			 (lambda (v) (+ inc (or v 0))))
      (if auto-fill-function
  	(fill-region from to nil t t))))
  
============================================================

Re: how-many/count-matches for non-interactive use

[John Paul Wallington]

> Apart from that, two files _seem_ to have problems: ibuf-ext.el, in
> particular the function `ibuffer-jump-to-buffer' [...]

Thanks for pointing this out.

I have changed `ibuffer-jump-to-buffer' in ibuf-ext.el so that reading
the buffer name is done in the interactive spec and will consider
removing the `interactive-p' calls from `ibuffer-find-file' in
ibuffer.el and `ibuffer-kill-line' in ibuf-ext.el too.

Re: how-many/count-matches for non-interactive use

[Richard Stallman]

      For most others, the current behavior prevents nuisance
    messaging, as intended.

Could you tell me some of the functions where you reached this
conclusion?

    I checked it now.  The functions `set-left-margin' and
    `set-right-margin' do not give any problems with keyboard macros.
    However, their call to `interactive-p' is a useless and ugly no-op.

It is not a no-op, but it is not correct either.  These commands as
currently written would behave incorrectly in some cases in a keyboard
macro.  They are certainly instances of the problem I was worried
about: expecting interactive-p not to be affected by keyboard macros.
They need to be fixed.

Your approach to the third one is to replace interactive-p with t (in
effect).  I think that is the right approach for all three.  Your
approach to the first two is to delete the call to
prefix-numeric-value.  As far as I can see, that would extend the bug
to the non-macro case.

So I think this is the right fix for those.


*** indent.el	12 Oct 2004 04:45:09 -0400	1.58
--- indent.el	23 Oct 2004 13:29:00 -0400	
***************
*** 205,211 ****
  Interactively, WIDTH is the prefix argument, if specified.
  Without prefix argument, the command prompts for WIDTH."
    (interactive "r\nNSet left margin to column: ")
!   (if (interactive-p) (setq width (prefix-numeric-value width)))
    (save-excursion
      ;; If inside indentation, start from BOL.
      (goto-char from)
--- 205,211 ----
  Interactively, WIDTH is the prefix argument, if specified.
  Without prefix argument, the command prompts for WIDTH."
    (interactive "r\nNSet left margin to column: ")
!   (setq width (prefix-numeric-value width))
    (save-excursion
      ;; If inside indentation, start from BOL.
      (goto-char from)
***************
*** 229,235 ****
  Interactively, WIDTH is the prefix argument, if specified.
  Without prefix argument, the command prompts for WIDTH."
    (interactive "r\nNSet right margin to width: ")
!   (if (interactive-p) (setq width (prefix-numeric-value width)))
    (save-excursion
      (goto-char from)
      (skip-chars-backward " \t")
--- 229,235 ----
  Interactively, WIDTH is the prefix argument, if specified.
  Without prefix argument, the command prompts for WIDTH."
    (interactive "r\nNSet right margin to width: ")
!   (setq width (prefix-numeric-value width))
    (save-excursion
      (goto-char from)
      (skip-chars-backward " \t")
***************
*** 289,297 ****
  the right margin width.
  If `auto-fill-mode' is active, re-fill the region to fit the new margin."
    (interactive "r\nP")
!   (if (interactive-p)
!       (setq inc (if inc (prefix-numeric-value current-prefix-arg)
! 		  standard-indent)))
    (save-excursion
      (alter-text-property from to 'right-margin
         (lambda (v) (+ inc (or v 0))))
--- 289,296 ----
  the right margin width.
  If `auto-fill-mode' is active, re-fill the region to fit the new margin."
    (interactive "r\nP")
!   (setq inc (if inc (prefix-numeric-value current-prefix-arg)
! 	      standard-indent))
    (save-excursion
      (alter-text-property from to 'right-margin
         (lambda (v) (+ inc (or v 0))))

Re: how-many/count-matches for non-interactive use

[Luc Teirlinck]

Richard Stallman wrote:

   It is not a no-op, but it is not correct either.  These commands as
   currently written would behave incorrectly in some cases in a keyboard
   macro.

I do not believe so (I checked).  I still believe those lines are
no-ops and should simply be deleted, like my patch does.

       (interactive "r\nNSet left margin to column: ")
   !   (setq width (prefix-numeric-value width))

That second line is redundant.  The `N' code character already _gives_ the
numeric value.

   Your approach to the first two is to delete the call to
   prefix-numeric-value.  As far as I can see, that would extend the
   bug to the non-macro case.

I do not believe so.  I checked.  The `N' already gives the numeric value.

   !   (setq inc (if inc (prefix-numeric-value current-prefix-arg)
   ! 	      standard-indent))

That would appear wrong for non-interactive calls.  For such calls
`current-prefix-arg' would not give the prefix arg of
`increase-right-margin', but of whichever function was actually called
interactively (and then directly or indirectly called
`increase-right-margin').

The line I used:

!   (setq inc (if inc (prefix-numeric-value inc) standard-indent)

is the _same_ line that is used in the three other completely analogous
functions in indent.el.  If there is something wrong with that line
for `increase-right-margin', then there would be something wrong in
the three other {in,de}crease-{left,right}-margin functions.  I
believe we need to use consistent code in all four.  Anything else
would appear to make no sense.

I still believe my original patch is the logical solution in all three
cases.

>From (elisp)Interactive Codes: 

`N'
     The numeric prefix argument; but if there is no prefix argument,
     read a number as with `n'.  Requires a number.  *Note Prefix
     Command Arguments::.  Prompt.

Note: The numeric prefix argument;

Sincerely,

Luc.

Re: how-many/count-matches for non-interactive use

[Richard Stallman]

    That second line is redundant.  The `N' code character already _gives_ the
    numeric value.

The documentation of `interactive' says that N can return the raw
prefix arg, which is not necessarily numeric.  However, I checked the
code in callint.c, and `N' actually returns the numeric prefix
argument, if there is a prefix.

So your fix to indent.el is correct, but we have uncovered
a different bug.

Since the Lisp manual agrees with the code, I will fix the doc string
of `interactive'.

Re: how-many/count-matches for non-interactive use

[Luc Teirlinck]

The list of files _outside the main Lisp directory_ that contain calls
to `interactive-p', which I sent yesterday, contained 18 false alarms
due to imperfect grepping.  Here is the corrected list.  It contains
49 files.

===File ~/new-interactive-list==============================
calc/calc-misc.el
calc/calc-rewr.el
calc/calc.el
gnus/gnus-art.el
gnus/message.el
gnus/pgg.el
calendar/diary-lib.el
calendar/timeclock.el
emacs-lisp/advice.el
emacs-lisp/autoload.el
emacs-lisp/checkdoc.el
emacs-lisp/easy-mmode.el
emacs-lisp/edebug.el
emacs-lisp/elp.el
emacs-lisp/lisp-mnt.el
emacs-lisp/shadow.el
emulation/cua-base.el
emulation/edt.el
emulation/tpu-edt.el
emulation/tpu-extras.el
emulation/viper-cmd.el
eshell/esh-mode.el
international/mule-cmds.el
international/mule-diag.el
mail/supercite.el
mh-e/mh-e.el
net/ange-ftp.el
net/browse-url.el
net/eudc.el
net/quickurl.el
obsolete/hilit19.el
play/5x5.el
play/fortune.el
play/yow.el
progmodes/ada-xref.el
progmodes/cperl-mode.el
progmodes/f90.el
progmodes/idlw-shell.el
progmodes/idlwave.el
progmodes/vhdl-mode.el
progmodes/python.el
textmodes/bibtex.el
textmodes/flyspell.el
textmodes/ispell.el
textmodes/page-ext.el
textmodes/reftex-index.el
textmodes/table.el
textmodes/tex-mode.el
textmodes/texinfmt.el
============================================================

Re: how-many/count-matches for non-interactive use

[Kim F. Storm]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> The list of files _outside the main Lisp directory_ that contain calls
> to `interactive-p', which I sent yesterday, contained 18 false alarms
> due to imperfect grepping.  Here is the corrected list.  It contains
> 49 files.

> emulation/cua-base.el


This call is intentional.

It occurs in (define-minor-mode cua-mode ...) to avoid
outputting a longish message when used non-interactively
(e.g. when cua-mode is enabled in .emacs).  Since it only
guards a message, it's ok with macros execution as well.

BTW, in define-minor-mode, you cannot use the (interactive "p")
alternative to check for interactive usage.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: how-many/count-matches for non-interactive use

[Richard Stallman]

I've gone through most of the files in subdirectories.
A few files I didn't handle but instead sent mail to their maintainers.
I checked the rest, and found many incorrect calls to interactive-p.

I fixed all of them except for the calls to help-setup-xref.
(I checked in some of these files but did not have time for all.)

I found that advice.el and another file that modify existing code
couldn't be fixed by adding an argument.  So I decided it was
necessary to add a function called-interactively-p for them.  I was
able to check in the documentation for this, but not yet the code.

I did not fix the calls to help-setup-xref, but I've concluded that
they all need to be fixed.  It is not right for this decision to be
affected by whether a keyboard macro is running.  I think the easiest
fix is to change all of those cases to call called-interactively-p.

Could someone offer to do that, after I check that function in?

Re: how-many/count-matches for non-interactive use

[Luc Teirlinck]

Richard Stallman wrote:

	 For most others, the current behavior prevents nuisance
       messaging, as intended.

   Could you tell me some of the functions where you reached this
   conclusion?

Here are twenty examples:

FILE LINE-NUMBER FUNCTION:

font-lock.el line 951. font-lock-fontify-buffer
comint.el, line 2945, comint-goto-process-mark
simple.el, line 4867, normal-erase-is-backspace-mode
strokes.el, line 1095,  strokes-load-user-strokes
shadowfile.el, line 521, shadow-copy-files
recentf.el, line 1198, recentf-mode
dired.el, line 2200, dired-build-subdir-alist
auto-save-mode line 3847, auto-save-mode
winner-mode, line 398 and 407, winner-mode
menubar.el, line 1647, menubar-mode
type-break.el, line 389, 431 and 447, type-break-mode
type-break.el, line 469, type-break-mode-line-message-mode
type-break.el, line 490, type-break-query-mode
env.el, line 177, getenv
elide.el, line 100, elide-head
elide.el, line 117, elide-head-show
vt-control.el, line 92, vt-keypad-on
vt-control.el, line 94, vt-keypad-off
vt-contol.el, line 101, vt-numlock
tooltip.el, line 409, tooltip-gud-toggle-dereference

Re: how-many/count-matches for non-interactive use

[Richard Stallman]

    Here are twenty examples:

I looked first at elide-head, and it definitely has a bug.

	  (if (not (and beg end))
	      (if (interactive-p)
		  (error "No header found"))

This means that the error won't occur when the command is called from
a macro.  The other call in elide.el, which is in elide-head-show, has
a similar bug.  I will change both of them to call message instead.

Next I looked at shadow-copy-files.  The code may be correct, but it
is written in a confusing way that makes it to prove that to oneself.

The rest of them seem to be correct.  It was luck that I found the
incorrect ones first.  Still, this experience shows that there
are more problems lurking here.

I wish you had made a list of the functions you didn't check,
because we should ask the maintainers of those files to check them.


Could one of you who uses shadowfile.el check whether the following
change is really correct?

*** shadowfile.el	01 Oct 2004 13:54:45 -0400	1.22
--- shadowfile.el	24 Oct 2004 04:32:07 -0400	
***************
*** 518,525 ****
  `shadow-save-buffers-kill-emacs', so it is not usually necessary to
  call it manually."
    (interactive "P")
!   (if (and (not shadow-files-to-copy) (interactive-p))
!       (message "No files need to be shadowed.")
      (save-excursion
        (map-y-or-n-p (function
  		     (lambda (pair)
--- 518,526 ----
  `shadow-save-buffers-kill-emacs', so it is not usually necessary to
  call it manually."
    (interactive "P")
!   (if (not shadow-files-to-copy)
!       (if (interactive-p)
! 	  (message "No files need to be shadowed."))
      (save-excursion
        (map-y-or-n-p (function
  		     (lambda (pair)

Re: how-many/count-matches for non-interactive use

[Luc Teirlinck]

Richard Stallman wrote:

   I wish you had made a list of the functions you didn't check,
   because we should ask the maintainers of those files to check them.

I already mentioned ibuf-ext.el and allout.el earlier.

I know looked at the three remaining calls in simple.el myself.  The
call in `kill-ring-save' _seems_ to me to be an example of correct
non-message use.  I have used `kill-ring-save' in keyboard macros
before I knew Elisp and was satisfied with its behavior.  I do not
know whether the calls in `next-line' and `previous-line' should be
considered "abstractly correct" or not.  I have used these tons of
times in keyboard macros and hit beginning or end of buffer countless
times.  No complaints from me _as a user_ about the present behavior.

There are tons of uses in help.el, help-fns, faces.el, apropos.el,
which are all of exactly the same "help-xref" type.  I did not check
these.  However, I somehow get the impression that whoever wrote the
code knew what they were doing.

Some functions quite simply make no sense to be called from a keyboard
macro in their present form, say ediff-version and emerge-version.
For functions of the *-version variety to be useful in keyboard
macros, they should accept an HERE argument, that prints the version
number at point in the buffer, like emacs-version does.

That leaves:

comint.el: comint-strip-ctrl-m
strokes.el: several.  Of those, strokes-prompt-user-save-strokes is
            another one that seems suspicious.  I am completely
            unfamiliar with strokes.el.  But these seem to be mouse
            related functions.  I do not know whether calling these
            from keyboard macros makes any sense to begin with.
newcomment.el: comment-indent-new-line
printing.el: several
woman.el: woman
man.el: Man-cleanup-manpage
dired-x.el: dired-omit-expunge, dired-x-bind-find-file
bookmark.el: bookmark-maybe-historicize-string, bookmark-bmenu-list 
ffap.el: several.
completion.el: add-completion, add-permanent-completion
menubar.el: menu-bar-make-toggle
pcomplete.el:  pcomplete

Re: how-many/count-matches for non-interactive use

[Richard Stallman]

    I know looked at the three remaining calls in simple.el myself.  The
    call in `kill-ring-save' _seems_ to me to be an example of correct
    non-message use.

I agree, in this case.  This code gives the user visual feedback,
which is what message does.

    There are tons of uses in help.el, help-fns, faces.el, apropos.el,
    which are all of exactly the same "help-xref" type.  I did not check
    these.  However, I somehow get the impression that whoever wrote the
    code knew what they were doing.

I think those are all erroneous.

The behavior controlled in this case is clearing a stack.
Whether to clear the stack should be the same regardless
of whether a keyboard macro is executing.

Can someone look at how to fix these?


    That leaves:

I started checking these, and I found:

    man.el: Man-cleanup-manpage

I think the reason for checking interactive-p here is just in case
someone wants to do M-x Man-cleanup-manpage.  I am not sure that
feature is worth having, but in any case the code is not correct.

    menubar.el: menu-bar-make-toggle

That was a bug.  It was using interactive-p to control whether to call
customize-mark-as-set.  The toggle command would have done the wrong
thing in a keyboard macro.

    pcomplete.el:  pcomplete

That is a bug too.  The code does something substantive, not just
visual feedback for the user.

    woman.el: woman

That is a bug too.  The code it controls does find-file; it is not
just visual feedback.

So far, four errors out of four.  I fixed these.  Could other people
check the rest?  The rule is simple: if it conditionalizes anything
more than visual feedback for the user, it is wrong to use
interactive-p.  Therefore, you don't have to really master the code to
fix these problems.


Here is what is left on that list:

comint.el: comint-strip-ctrl-m
strokes.el: several.  Of those, strokes-prompt-user-save-strokes is
            another one that seems suspicious.  I am completely
            unfamiliar with strokes.el.  But these seem to be mouse
            related functions.  I do not know whether calling these
            from keyboard macros makes any sense to begin with.
newcomment.el: comment-indent-new-line
printing.el: several
dired-x.el: dired-omit-expunge, dired-x-bind-find-file
bookmark.el: bookmark-maybe-historicize-string, bookmark-bmenu-list 
ffap.el: several.
completion.el: add-completion, add-permanent-completion

Re: how-many/count-matches for non-interactive use

[Luc Teirlinck]

Richard Stallman wrote:

   I wish you had made a list of the functions you didn't check,
   because we should ask the maintainers of those files to check them.

I forgot that given the way I did this, I covered only the main lisp
directory and not its subdirectories.  So my problem list is probably
not complete.

Sincerely,

Luc.

Re: how-many/count-matches for non-interactive use

[Richard Stallman]

    I forgot that given the way I did this, I covered only the main lisp
    directory and not its subdirectories.  So my problem list is probably
    not complete.

You've done about half the job; would you like to do the rest?

Re: how-many/count-matches for non-interactive use

[Luc Teirlinck]

Attached is  a list of the files outside the main lisp directory that
contain calls to intercative-p.  I checked none of those.

===File ~/interactive-p-file================================
calc/calc-misc.el
calc/calc-rewr.el
calc/calc.el
gnus/gnus-art.el
gnus/message.el
gnus/pgg.el
calendar/diary-lib.el
calendar/timeclock.el
emacs-lisp/advice.el
emacs-lisp/autoload.el
emacs-lisp/byte-opt.el
emacs-lisp/bytecomp.el
emacs-lisp/checkdoc.el
emacs-lisp/disass.el
emacs-lisp/easy-mmode.el
emacs-lisp/edebug.el
emacs-lisp/elp.el
emacs-lisp/lisp-mnt.el
emacs-lisp/shadow.el
emulation/cua-base.el
emulation/edt.el
emulation/tpu-edt.el
emulation/tpu-extras.el
emulation/viper-cmd.el
eshell/em-banner.el
eshell/em-cmpl.el
eshell/em-hist.el
eshell/em-prompt.el
eshell/em-rebind.el
eshell/em-script.el
eshell/em-smart.el
eshell/em-term.el
eshell/em-unix.el
eshell/esh-cmd.el
eshell/esh-io.el
eshell/esh-mode.el
eshell/esh-proc.el
eshell/esh-test.el
eshell/eshell.el
international/mule-cmds.el
international/mule-diag.el
mail/supercite.el
mh-e/mh-e.el
net/ange-ftp.el
net/browse-url.el
net/eudc.el
net/quickurl.el
obsolete/hilit19.el
play/5x5.el
play/fortune.el
play/yow.el
progmodes/ada-xref.el
progmodes/cperl-mode.el
progmodes/f90.el
progmodes/idlw-shell.el
progmodes/idlwave.el
progmodes/sql.el
progmodes/vhdl-mode.el
progmodes/python.el
textmodes/bibtex.el
textmodes/flyspell.el
textmodes/ispell.el
textmodes/page-ext.el
textmodes/reftex-index.el
textmodes/table.el
textmodes/tex-mode.el
textmodes/texinfmt.el             
============================================================

Re: how-many/count-matches for non-interactive use

[Richard Stallman]

I'm thinking of installing this doc string for Finteractive_p.
Any comments or suggestions?

    DEFUN ("interactive-p", Finteractive_p, Sinteractive_p, 0, 0, 0,
	   doc: /* Return t if the function was run directly by user input.
    This means that the function was called with call-interactively (which
    includes being called as the binding of a key)
    and input is currently coming from the keyboard (not in keyboard macro).

    The only known proper use of `interactive-p' is in deciding whether to
    print a helpful message.  If you're thinking of using it for any other
    purpose, it is quite likely that you're making a mistake.  Think: what
    do you want to do when the command is called from a keyboard macro?

    If you want to test whether your function was called with
    `call-interactively', the way to do that is by adding an extra
    optional argument, and making the `interactive' spec specify non-nil
    unconditionally for that argument.  (`p' is a good way to do this.)  */)

I'm also thinking of this change for commands.texi.
Any comments or suggestions?

*** commands.texi	08 Sep 2004 11:40:24 -0400	1.55
--- commands.texi	24 Oct 2004 04:52:32 -0400	
***************
*** 605,629 ****
  @end deffn
  
  @defun interactive-p
! This function returns @code{t} if the containing function (the one whose
! code includes the call to @code{interactive-p}) was called
! interactively, with the function @code{call-interactively}.  (It makes
! no difference whether @code{call-interactively} was called from Lisp or
! directly from the editor command loop.)  If the containing function was
! called by Lisp evaluation (or with @code{apply} or @code{funcall}), then
! it was not called interactively.
! @end defun
  
!   The most common use of @code{interactive-p} is for deciding whether to
! print an informative message.  As a special exception,
! @code{interactive-p} returns @code{nil} whenever a keyboard macro is
! being run.  This is to suppress the informative messages and speed
! execution of the macro.
  
!   For example:
  
  @example
  @group
  (defun foo ()
    (interactive)
    (when (interactive-p)
--- 605,626 ----
  @end deffn
  
  @defun interactive-p
! This function returns @code{t} if the containing function (the one
! whose code includes the call to @code{interactive-p}) was called in
! direct response to user input.  This means that it was called with the
! function @code{call-interactively}, and that a keyboard macro is
! not running.
  
! If the containing function was called by Lisp evaluation (or with
! @code{apply} or @code{funcall}), then it was not called interactively.
! @end defun
  
!   The most common use of @code{interactive-p} is for deciding whether
! to print an informative message.  For example:
  
  @example
  @group
+ ;; @r{Here's the usual way to use @code{interactive-p}.}
  (defun foo ()
    (interactive)
    (when (interactive-p)
***************
*** 632,637 ****
--- 629,635 ----
  @end group
  
  @group
+ ;; @r{This function is just to illustrate the behavior.}
  (defun bar ()
    (interactive)
    (setq foobar (list (foo) (interactive-p))))
***************
*** 645,651 ****
  
  @group
  ;; @r{Type @kbd{M-x bar}.}
! ;; @r{This does not print anything.}
  @end group
  
  @group
--- 643,649 ----
  
  @group
  ;; @r{Type @kbd{M-x bar}.}
! ;; @r{This does not display a message.}
  @end group
  
  @group
***************
*** 654,663 ****
  @end group
  @end example
  
!   The other way to do this sort of job is to make the command take an
! argument @code{print-message} which should be non-@code{nil} in an
! interactive call, and use the @code{interactive} spec to make sure it is
! non-@code{nil}.  Here's how:
  
  @example
  (defun foo (&optional print-message)
--- 652,662 ----
  @end group
  @end example
  
!   If you want to test @emph{only} whether the function was called
! using @code{call-interactively}, add an optional argument
! @code{print-message} which should be non-@code{nil} in an interactive
! call, and use the @code{interactive} spec to make sure it is
! non-@code{nil}.  Here's an example:
  
  @example
  (defun foo (&optional print-message)

Re: how-many/count-matches for non-interactive use

[Richard Stallman]

The code in allout.el uses interactive-p in a rather confused way.

The first use of interactive-p in allout is clearly a bug.
That command would fail in a macro.  The right way to right
that code is to read the argument inside the interactive spec.

Another use does call-interactively only if (interactive-p) is true.
That also is clearly wrong.

Many calls to interactive-p appear in functions that are not commands.
The only way interactive-p can return non-nil is when these functions
are called from commands run from macros.  It doesn't seem right for
allout commands to move the cursor differently when they are run from
macros.  So I am pretty sure these are bugs.

I think this is the right way to fix these bugs, but I don't use
allout.el.  Could someone who uses it please check this?


*** allout.el	04 Sep 2004 13:19:28 -0400	1.50
--- allout.el	23 Oct 2004 13:42:44 -0400	
***************
*** 954,973 ****
  \(require 'allout)
  \(allout-init t)"
  
!   (interactive)
!   (if (interactive-p)
!       (progn
! 	(setq mode
! 	      (completing-read
! 	       (concat "Select outline auto setup mode "
! 		       "(empty for report, ? for options) ")
! 	       '(("nil")("full")("activate")("deactivate")
! 		 ("ask") ("report") (""))
! 	       nil
! 	       t))
! 	(if (string= mode "")
! 	    (setq mode 'report)
! 	  (setq mode (intern-soft mode)))))
    (let
        ;; convenience aliases, for consistent ref to respective vars:
        ((hook 'allout-find-file-hook)
--- 954,969 ----
  \(require 'allout)
  \(allout-init t)"
  
!   (interactive
!    (let ((m (completing-read
! 	     (concat "Select outline auto setup mode "
! 		     "(empty for report, ? for options) ")
! 	     '(("nil")("full")("activate")("deactivate")
! 	       ("ask") ("report") (""))
! 	     nil
! 	     t)))
!      (if (string= m "") 'report
!        (intern-soft m))))
    (let
        ;; convenience aliases, for consistent ref to respective vars:
        ((hook 'allout-find-file-hook)
***************
*** 1904,1917 ****
                     depth)
            (goto-char last-good)
            nil))
!     (if (interactive-p) (allout-end-of-prefix))))
  ;;;_   > allout-ascend ()
  (defun allout-ascend ()
    "Ascend one level, returning t if successful, nil if not."
    (prog1
        (if (allout-beginning-of-level)
  	  (allout-previous-heading))
!     (if (interactive-p) (allout-end-of-prefix))))
  ;;;_   > allout-descend-to-depth (depth)
  (defun allout-descend-to-depth (depth)
    "Descend to depth DEPTH within current topic.
--- 1900,1913 ----
                     depth)
            (goto-char last-good)
            nil))
!     (allout-end-of-prefix)))
  ;;;_   > allout-ascend ()
  (defun allout-ascend ()
    "Ascend one level, returning t if successful, nil if not."
    (prog1
        (if (allout-beginning-of-level)
  	  (allout-previous-heading))
!     (allout-end-of-prefix)))
  ;;;_   > allout-descend-to-depth (depth)
  (defun allout-descend-to-depth (depth)
    "Descend to depth DEPTH within current topic.
***************
*** 1931,1943 ****
        nil))
    )
  ;;;_   > allout-up-current-level (arg &optional dont-complain)
! (defun allout-up-current-level (arg &optional dont-complain)
    "Move out ARG levels from current visible topic.
  
  Positions on heading line of containing topic.  Error if unable to
  ascend that far, or nil if unable to ascend but optional arg
  DONT-COMPLAIN is non-nil."
!   (interactive "p")
    (allout-back-to-current-heading)
    (let ((present-level (allout-recent-depth))
  	(last-good (point))
--- 1927,1939 ----
        nil))
    )
  ;;;_   > allout-up-current-level (arg &optional dont-complain)
! (defun allout-up-current-level (arg &optional dont-complain interactive)
    "Move out ARG levels from current visible topic.
  
  Positions on heading line of containing topic.  Error if unable to
  ascend that far, or nil if unable to ascend but optional arg
  DONT-COMPLAIN is non-nil."
!   (interactive "p\ni\np")
    (allout-back-to-current-heading)
    (let ((present-level (allout-recent-depth))
  	(last-good (point))
***************
*** 1958,1969 ****
      (if (or failed
  	    (> arg 0))
  	(progn (goto-char last-good)
! 	       (if (interactive-p) (allout-end-of-prefix))
  	       (if (not dont-complain)
  		   (error "Can't ascend past outermost level")
! 		 (if (interactive-p) (allout-end-of-prefix))
  		 nil))
!       (if (interactive-p) (allout-end-of-prefix))
        allout-recent-prefix-beginning)))
  
  ;;;_  - Linear
--- 1954,1965 ----
      (if (or failed
  	    (> arg 0))
  	(progn (goto-char last-good)
! 	       (if interactive (allout-end-of-prefix))
  	       (if (not dont-complain)
  		   (error "Can't ascend past outermost level")
! 		 (if interactive (allout-end-of-prefix))
  		 nil))
!       (if interactive (allout-end-of-prefix))
        allout-recent-prefix-beginning)))
  
  ;;;_  - Linear
***************
*** 2029,2035 ****
    (let ((depth (allout-depth)))
      (while (allout-previous-sibling depth nil))
      (prog1 (allout-recent-depth)
!       (if (interactive-p) (allout-end-of-prefix)))))
  ;;;_   > allout-next-visible-heading (arg)
  (defun allout-next-visible-heading (arg)
    "Move to the next ARG'th visible heading line, backward if arg is negative.
--- 2025,2031 ----
    (let ((depth (allout-depth)))
      (while (allout-previous-sibling depth nil))
      (prog1 (allout-recent-depth)
!       (allout-end-of-prefix))))
  ;;;_   > allout-next-visible-heading (arg)
  (defun allout-next-visible-heading (arg)
    "Move to the next ARG'th visible heading line, backward if arg is negative.
***************
*** 2067,2079 ****
    (interactive "p")
    (allout-next-visible-heading (- arg)))
  ;;;_   > allout-forward-current-level (arg)
! (defun allout-forward-current-level (arg)
    "Position point at the next heading of the same level.
  
  Takes optional repeat-count, goes backward if count is negative.
  
  Returns resulting position, else nil if none found."
!   (interactive "p")
    (let ((start-depth (allout-current-depth))
  	(start-point (point))
  	(start-arg arg)
--- 2063,2075 ----
    (interactive "p")
    (allout-next-visible-heading (- arg)))
  ;;;_   > allout-forward-current-level (arg)
! (defun allout-forward-current-level (arg &optional interactive)
    "Position point at the next heading of the same level.
  
  Takes optional repeat-count, goes backward if count is negative.
  
  Returns resulting position, else nil if none found."
!   (interactive "p\np")
    (let ((start-depth (allout-current-depth))
  	(start-point (point))
  	(start-arg arg)
***************
*** 2101,2107 ****
  		  (= (allout-recent-depth) start-depth)))
  	allout-recent-prefix-beginning
        (goto-char last-good)
!       (if (not (interactive-p))
  	  nil
  	(allout-end-of-prefix)
  	(error "Hit %s level %d topic, traversed %d of %d requested"
--- 2097,2103 ----
  		  (= (allout-recent-depth) start-depth)))
  	allout-recent-prefix-beginning
        (goto-char last-good)
!       (if (not interactive)
  	  nil
  	(allout-end-of-prefix)
  	(error "Hit %s level %d topic, traversed %d of %d requested"
***************
*** 2110,2119 ****
  	       (- (abs start-arg) arg)
  	       (abs start-arg))))))
  ;;;_   > allout-backward-current-level (arg)
! (defun allout-backward-current-level (arg)
    "Inverse of `allout-forward-current-level'."
!   (interactive "p")
!   (if (interactive-p)
        (let ((current-prefix-arg (* -1 arg)))
  	(call-interactively 'allout-forward-current-level))
      (allout-forward-current-level (* -1 arg))))
--- 2106,2115 ----
  	       (- (abs start-arg) arg)
  	       (abs start-arg))))))
  ;;;_   > allout-backward-current-level (arg)
! (defun allout-backward-current-level (arg &optional interactive)
    "Inverse of `allout-forward-current-level'."
!   (interactive "p\np")
!   (if interactive
        (let ((current-prefix-arg (* -1 arg)))
  	(call-interactively 'allout-forward-current-level))
      (allout-forward-current-level (* -1 arg))))

Re: how-many/count-matches for non-interactive use

[Ken Manheimer]

Thanks, all, for including me in the discussion about misuses of 
interactive-p.  I'm the developer of allout, and haven't had time yet to 
examine the specifics.  I hope to do so this week, but have one 
preliminary comment.

On Sat, 23 Oct 2004, Richard Stallman wrote:

> Many calls to interactive-p appear in functions that are not commands.
> The only way interactive-p can return non-nil is when these functions
> are called from commands run from macros.  It doesn't seem right for
> allout commands to move the cursor differently when they are run from
> macros.  So I am pretty sure these are bugs.

This use *may* be deliberate.  Allout has a special "hot-spot" operation 
mode, where the behavior of the movement functions varies depending on 
whether or not you started from on top of a bullet glyph.  The thing is 
that this behavioral nuance should not happen when being called 
non-interactively.  It *may* be that the interactive-p conditioning is for 
that purpose.

> I think this is the right way to fix these bugs, but I don't use
> allout.el.  Could someone who uses it please check this?

As i said though, the above is an entirely preliminary thought.  I'm 
hoping to get time this evening or tomorrow to investigate, and try out 
the proposed changes to see if this is disrupted.  I'll report back when i 
know more, one way or another.

Ken Manheimer
klm@zope.com (please shift to ken.manheimer@gmail.com or klm@i.am)

Re: how-many/count-matches for non-interactive use

[Richard Stallman]

    This use *may* be deliberate.  Allout has a special "hot-spot" operation 
    mode, where the behavior of the movement functions varies depending on 
    whether or not you started from on top of a bullet glyph.  The thing is 
    that this behavioral nuance should not happen when being called 
    non-interactively.  It *may* be that the interactive-p conditioning is for 
    that purpose.

Perhaps that makes interactive-p useful in some of the commands.
However, when a function is not a command, it cannot be called
interctively.  (interactive-p) is equivalent to nil in such a
function.  So I don't see how the calls to interactive-p can do
something useful there.

Re: how-many/count-matches for non-interactive use

[Ken Manheimer]

I applied your allout patch, and it checks out fine, hot-spot operation 
included.

Ken Manheimer
ken.manheimer@gmail.com, klm@i.am

On Mon, 25 Oct 2004, Ken Manheimer wrote:

> Thanks, all, for including me in the discussion about misuses of 
> interactive-p.  I'm the developer of allout, and haven't had time yet to 
> examine the specifics.  I hope to do so this week, but have one 

Re: how-many/count-matches for non-interactive use

[Ken Manheimer]

On Thu, 28 Oct 2004 00:39:20 -0400 (EDT), I wrote:
> I applied your allout patch, and it checks out fine, hot-spot operation
> included.

I discovered a bug related to this conversion for which i have a fix,
but only in my skewed version of the code.  The problem now is that
the skew in my version is big enough (eg, the function name prefix in
my version is "outline-", which yields hundreds of spurious
differences), and i haven't succeeded in fixing the problem in the
current gnu CVS version of the code with a little bit of effort.

The problem may well have existed in the gnu version of the code
before the interactive-p-to-interactive conversion - though it only
started appearing in my version after applying the conversion.  (The
fix in my version entailed applying the conversion to some functions
that were missed in RMS patch, specifically outline-end-of-level - but
changing the current gnu version's 'allout-end-of-level' so it's
similar doesn't help.)

(The problem is in allout's mechanism which automatically adjusts the
outline level of a pasted topic and its subtopics to that of the
header into which it's being pasted, if the paste target header is
bare.  With the bug, the adjustment process infinitely loops.)

I intend to chip away on eliminating all (750) differences, to
converge my version and the gnu one (preferring the gnu one when not
incorrect, eg using the 'allout-' function name prefix), and finally
bring them into sync.  I am hoping to do this over the next several
weeks, though i'm in the process of a big move so i can't give an
assured estimate of the finish time.

One question i have for you all is how best to get the result to you. 
I would like to work against a checkout of the current CVS, and expect
it'll be easy to find instructions for doing that checkout.  Should i
just send the diff (along with a ChangeLog entry) for the converged 
(and fixed) version to the list of addresses in this conversation?

In the long run, i would like to become more active maintaining
allout, and wonder what the common practice is for applying changes to
code that's part of the main distribution.  I welcome pointers to
guidelines, etc.
---
Ken Manheimer
ken.manheimer@gmail.com, klm@i.am

Re: how-many/count-matches for non-interactive use

[Richard Stallman]

    One question i have for you all is how best to get the result to you. 
    I would like to work against a checkout of the current CVS, and expect
    it'll be easy to find instructions for doing that checkout.  Should i
    just send the diff (along with a ChangeLog entry) for the converged 
    (and fixed) version to the list of addresses in this conversation?

Yes, that is the best way.

Also please send text for etc/NEWS describing any user-visible changes
that are worth mentioning.

    In the long run, i would like to become more active maintaining
    allout,

Thank you, that will be useful.

	    and wonder what the common practice is for applying changes to
    code that's part of the main distribution.  I welcome pointers to
    guidelines, etc.

If you do it only occasionally, you can mail your diffs, change logs,
and etc/NEWS text to emacs-devel@gnu.org and ask someone to install
them.  If you do it often, we could give you write access to the
repository.

Re: how-many/count-matches for non-interactive use

[Richard Stallman]

The call to interactive-p in ibuf-ext.el is in ibuffer-kill-line.
Since it conditions the choice of whether to use call-interactively,
it is most surely wrong.  I think this is the right fix; would someone
who uses ibuf-ext.el please check it?


*** ibuf-ext.el	23 Oct 2004 10:00:10 -0400	1.39
--- ibuf-ext.el	23 Oct 2004 13:45:58 -0400	
***************
*** 645,660 ****
    (ibuffer-update nil t))
  
  ;;;###autoload
! (defun ibuffer-kill-line (&optional arg)
    "Kill the filter group at point.
  See also `ibuffer-kill-filter-group'."
!   (interactive "P")
    (ibuffer-aif (save-excursion
  		 (ibuffer-forward-line 0)
  		 (get-text-property (point) 'ibuffer-filter-group-name))
        (progn
  	(ibuffer-kill-filter-group it))
!       (funcall (if (interactive-p) #'call-interactively #'funcall)
  	       #'kill-line arg)))
  
  (defun ibuffer-insert-filter-group-before (newgroup group)
--- 645,660 ----
    (ibuffer-update nil t))
  
  ;;;###autoload
! (defun ibuffer-kill-line (&optional arg interactive)
    "Kill the filter group at point.
  See also `ibuffer-kill-filter-group'."
!   (interactive "P\np")
    (ibuffer-aif (save-excursion
  		 (ibuffer-forward-line 0)
  		 (get-text-property (point) 'ibuffer-filter-group-name))
        (progn
  	(ibuffer-kill-filter-group it))
!       (funcall (if interactive-p #'call-interactively #'funcall)
  	       #'kill-line arg)))
  
  (defun ibuffer-insert-filter-group-before (newgroup group)

Re: how-many/count-matches for non-interactive use

[John Paul Wallington]

> The call to interactive-p in ibuf-ext.el is in ibuffer-kill-line.
> Since it conditions the choice of whether to use call-interactively,
> it is most surely wrong.  I think this is the right fix; would someone
> who uses ibuf-ext.el please check it?

Yup.  Installed.

Re: how-many/count-matches for non-interactive use

[Richard Stallman]

Thanks for looking at many uses of interactive-p.  You found three
files that have the sort of bugs I was worried about.

The examples of ibuf-menu.el and allout.el (and, to a lesser extent,
of indent.el) show that the lack of complaints about problems using a
certain command in a macro is no proof it doesn't misuse
interactive-p.

The other commands that use it may indeed be correct.  But we have no
evidence about it, except from checking their code.

Re: how-many/count-matches for non-interactive use

[Luc Teirlinck]

I took a closer look at what started this thread, `how-many'.  I
somewhat changed my opinion on this particular example.  It indeed
seems to make some sense to print that message in a keyboard macro in
some situations (if `how-many' is the very last command in the macro).
But it makes equally much sense in the same situations when called from
Lisp.  Remember that `how-many' without Alexander's patch prints the
message even when called from Lisp.  Alexander's latest patch looks
OK because you still are able to print the message even from Lisp.
Trying to solve the problem by changing interactive-p makes in my
opinion no sense, because if you sometimes need the message in a
keyboard macro, you automatically also sometimes need the message from
Lisp, for instance if you translate your keyboard macro into a Lisp
function for efficiency.

There are many messages that make no sense when called from a keyboard
macro, so the present behavior of `interactive-p' makes sense.  In
situations where the message should appear in a keyboard macro, one
should always use an argument, because then you will sometimes also
need to print the message from Lisp.  This is exactly what is
currently clearly documented in the Elisp manual and in plenty of
other places.

       When the user currently tests a keyboard macro, he tests it with the
       current behavior.  Hence, the current behavior of `interactive-p'
       determines whether the macro does what the user wants it to do,

   This argument assumes that people who wrote this code knew what they
   were doing.  I can't assume that.  I want to see what sort of messages
   they really are.  I want someone to look at them.

The argument assumed that _keyboard macro users_ know what they want
their macros to do.

I am aware that some people who write code do not know what they are
doing, although I would hope that this does not apply to the majority
of people whose code winds up in the Emacs sources.  I have not seen a
flood of bug reports related to uses of `interactive-p' that were
inappropriate for macros.

Sincerely,

Luc.

Re: how-many/count-matches for non-interactive use

[Richard Stallman]

    Trying to solve the problem by changing interactive-p makes in my
    opinion no sense, because if you sometimes need the message in a
    keyboard macro, you automatically also sometimes need the message from
    Lisp, for instance if you translate your keyboard macro into a Lisp
    function for efficiency.

Calling how-many in a translated macro and writing a Lisp program to
call it are different kinds of usage.

    There are many messages that make no sense when called from a keyboard
    macro, so the present behavior of `interactive-p' makes sense.  In
    situations where the message should appear in a keyboard macro, one
    should always use an argument, because then you will sometimes also
    need to print the message from Lisp.

This is an interesting argument.

If this means interactive-p should not be changed, then we really need
to look at the many existing calls to interactive-p and see if they
should be rewritten to use the other technique.

       This argument assumes that people who wrote this code knew what they
       were doing.  I can't assume that.  I want to see what sort of messages
       they really are.  I want someone to look at them.

    The argument assumed that _keyboard macro users_ know what they want
    their macros to do.

It assumes that they chose this behavior deliberately among various
options.  That is clearly not usually so.  They used command FOO
because they wanted its effects, and they probably did not consider
rewriting FOO at all.

Re: how-many/count-matches for non-interactive use

[Luc Teirlinck]

Richard Stallman wrote:

   If this means interactive-p should not be changed, then we really need
   to look at the many existing calls to interactive-p and see if they
   should be rewritten to use the other technique.

This is going to be difficult (or infeasible).  I do not want to give
the impression of actually having _done_ that.  What I did was go to
the lisp directory in Dired, *% .el$ RET, unmark a few obviously
uninteresting files, and then `A interactive-p RET' M-, M-, ...

Some of the calls are obviously correct, some where obviously suspicious.
I listed those in my earlier message and sent a patch fixing some.

For most it was impossible to tell without studying a lot of code in
detail.  Just doing M-, until all files are processed without even
looking at anything already takes time.  So conducting a detailed
study of all of them is hopeless.

By leaving `interactive-p' like it is, we are not going to break
anything in 21.4 that was not already broken in previous Emacs
versions.  Better than that, we are in the process of eliminating the
most obvious problems.  Misuses of `interactive-p' do not seem to be
that ubiquitous that they lead to floods of bug reports from keyboard
macro users.

Sincerely,

Luc.

Re: how-many/count-matches for non-interactive use

[Kim F. Storm]

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

>> Thinking more about it, I belive that the current behaviour of
>> interactive-p makes good sense in cases where it is used to determine
>> whether a command should do sit-for or output a message, as those are
>> typically not desireable during macro execution.
>
> Sit-for doesn't wait when executed from a macro.  

But it still does redisplay -- not really interesting if you execute a
macro N times with a prefix.

>                                                   As for messages you might
> be right in some (maybe even in many) cases but I doubt it matters much
> since unless the message is the last in the macro it will just be
> overwritten anyway.

Again, it does redisplay.


I think we should keep interactive-p as is.
I see no benefit from changing it or making it obsolete.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: how-many/count-matches for non-interactive use

[Richard Stallman]

    I doubt anybody used interactive-p rather than an extra argument just
    because of the subtle difference w.r.t keyboard macros.  I expect 99% of the
    people who used interactive-p haven't even thought about the interaction
    with keyboard macros.

I agree with you, but I think we should check the existing calls
to make sure that we're not breaking some while we fix others.