pinard/Pymacs

Byte compile warning 'interactive-p' on Emacs 24.1

Closed this issue · 6 comments

insikk commented

Here is error.

pymacs.el:196:21:Warning: 'interactive-p' is an obsolete function (as of
23.2); use 'called-interactively-p' instead.

In pymacs-exec:
pymacs.el:206:21:Warning: 'interactive-p' is an obsolete function (as of
23.2); use 'called-interactively-p' instead.

leoliu commented

Hello François,

Which versions of emacs do we intend to support? If emacs >= 22, interactive-p can be replaced with called-interactive-p.

Cheers,
Leo

pinard commented

leoliu notifications@github.com writes:

Which versions of emacs do we intend to support? If emacs >= 22,
interactive-p can be replaced with called-interactive-p.

Hi, Leo! :-) I hope life is kind to you!

If we do that replacement, older Emacs versions might not work, might
they? Maybe wait until interactive-p disappears until we switch?

However, in the need of silencing some future diagnostic, we might have
to "configure" one of the function at run-time, like Pymacs already does
for a few functions.

Do not hesitate to raise the question again if you feel the time has
come, before I realize it...

François

leoliu commented

Hello François,

Thanks.

OK, in that case I can live with the warnings for another few years ;) On the other hand I have neither access nor interest to emacs before 22, so I wouldn't mind if support for emacs < 22 were dropped.

Leo

pinard commented

leoliu notifications@github.com writes:

OK, in that case I can live with the warnings for another few years ;)

If you are indeed annoyed by warnings, we should take some action. The
next time in Pymacs, I'll be back to you on this.

On the other hand I have neither access nor interest to emacs before
22, so I wouldn't mind if support for emacs < 22 were dropped.

I do not know how to proceed for past versions. Rather than improvise
all the time, maybe some fixed guidelines might be helpful. Something
like "we support five years in the past", maybe. Besides, by the
virtues of Git, one in the need of older code could easily get it.

François

leoliu commented

I personally think it is quite generous to support two major releases and the development version, i.e. for the time being 23, 24 and devel. We could then tag before dropping a support when emacs has a new major release. So rare users that need support for older emacsen can easily find a working version.

Time based compatibility has the problem of being difficult to police while major-version-based compatibility could make good use of emacs-major-version.

pinard commented

OK, Leo. I merely configured it so to use whatever exists. Thanks.