Emacs version compatibility

Emacs version compatibility

[Lars Ingebrigtsen]

I think Ma Gnus should drop Emacs 22 compatibility, and it should also
drop non-Mule XEmacs compatibility.

More controversially :-), I think 真 Gnus should also stop defining
compatibility functions like `gnus-mark-active-p', and instead just
start maintaining a `gnus-compat.el' library that would define functions
like `mark-active-p' for Emacsen that don't define them.

This will make the source code more readable, I think.

-- 
(domestic pets only, the antidote for overdose, milk.)
  http://lars.ingebrigtsen.no  *  Sent from my Rome

Re: Emacs version compatibility

[Steinar Bang]

>>>>> Lars Ingebrigtsen <larsi@gnus.org>:

> I think Ma Gnus should drop Emacs 22 compatibility, 

Sadness! :-(

But I will bow to the inevitable.

Re: Emacs version compatibility

[Ted Zlatanov]

On Wed, 01 Feb 2012 14:15:03 +0100 Lars Ingebrigtsen <larsi@gnus.org> wrote: 

LI> I think Ma Gnus should drop Emacs 22 compatibility, and it should also
LI> drop non-Mule XEmacs compatibility.

LI> More controversially :-), I think 真 Gnus should also stop defining
LI> compatibility functions like `gnus-mark-active-p', and instead just
LI> start maintaining a `gnus-compat.el' library that would define functions
LI> like `mark-active-p' for Emacsen that don't define them.

LI> This will make the source code more readable, I think.

I am 100% in favor of both.  But gnus-compat.el could be an ELPA package
so other packages and users can have the same functionality.  Which
reminds me, are you interested in packaging Ma Gnus as an ELPA package?
That would let us pull its source code out of Emacs, except for the
pieces that Emacs wants, and would make installation easier.

Ted

Re: Emacs version compatibility

[Lars Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> LI> More controversially :-), I think 真 Gnus should also stop defining
> LI> compatibility functions like `gnus-mark-active-p', and instead just
> LI> start maintaining a `gnus-compat.el' library that would define functions
> LI> like `mark-active-p' for Emacsen that don't define them.
>
> LI> This will make the source code more readable, I think.

I've now started this, with `delete-directory' as the first victim.  It
redefines it to have the `recursive' parameter, if it doesn't already.

I know this is really bad engineering.  I know this is pretty much a
maintainability nightmare.  If all packages redefined Emacs core
functions willy-nilly, Emacs would become totally unusable.

But enough is enough.  Bring your Emacsen up to par, or be redefined.

> I am 100% in favor of both.  But gnus-compat.el could be an ELPA package
> so other packages and users can have the same functionality.

There's already an fsf-compat package that people use.  If somebody
wants to take stuff out of gnus-compat and put it there, that's fine.

> Which reminds me, are you interested in packaging Ma Gnus as an ELPA
> package?

Not really.  Ma Gnus is going to be seriously unstable if I'm able to
type fast enough.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  http://lars.ingebrigtsen.no  *  Sent from my Rome

Re: Emacs version compatibility

[Reiner Steib]

On Wed, Feb 01 2012, Lars Ingebrigtsen wrote:

> I think Ma Gnus should drop Emacs 22 compatibility, and it should also
> drop non-Mule XEmacs compatibility.

Fine with me.  Although dropping Emacs 22 probably doesn't help too
much as long as you support XEmacs 21.4.

> More controversially :-), I think 真 Gnus should also stop defining
> compatibility functions like `gnus-mark-active-p', and instead just
> start maintaining a `gnus-compat.el' library that would define functions
> like `mark-active-p' for Emacsen that don't define them.

Please don't.  It violates the Emacs coding guidelines.  Packages that
have gone that road have broken other packages in the past.
E.g. color-scheme defined `replace-in-string´[1] which broke Gnus and
emacs-jabber.

> This will make the source code more readable, I think.

I can't see that `mark-active-p' is much more readable as
`gnus-mark-active-p´.

Bye, Reiner.

[1]
,----
| From: Reiner Steib
| Subject: Bogus definition of replace-in-string in color-theme.el
|   (was: Fwd: Re: Error viewing PGP/mime signed messages)
| To: Xavier Maillard <xma // gnu.org>
| Cc: Katsumi Yamaoka <yamaoka <at> jpl.org>
| Date: Wed, 19 Mar 2008 13:39:51 +0100
| Message-ID: <v9d4pqj39g.fsf <at> marauder.physik.uni-ulm.de>
| 
| Hi Xavier,
|
| please fix the use of `replace-in-string' in color-theme.el ASAP (see
| the problem described below and in <https://gna.org/bugs/?9494>).
| 
| No package should ever define functions and variables out of it's own
| name space:
| 
| ,----[ (info "(elisp)Coding Conventions") ]
| |    * If a package needs to define an alias or a new function for
| |      compatibility with some other version of Emacs, name it with the
| |      package prefix, not with the raw name with which it occurs in the
| |      other version.  Here is an example from Gnus, which provides many
| |      examples of such compatibility issues.
| | 
| |           (defalias 'gnus-point-at-bol
| |             (if (fboundp 'point-at-bol)
| |                 'point-at-bol
| |               'line-beginning-position))
| `----
| [ Forwarded articles from
|   <http://thread.gmane.org/gmane.emacs.gnus.general/66521/focus=66522>
|   stripped. ]
`----
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Emacs version compatibility

[Michael Albinus]

Reiner Steib <reinersteib+gmane@imap.cc> writes:

> On Wed, Feb 01 2012, Lars Ingebrigtsen wrote:
>
>> More controversially :-), I think 真 Gnus should also stop defining
>> compatibility functions like `gnus-mark-active-p', and instead just
>> start maintaining a `gnus-compat.el' library that would define functions
>> like `mark-active-p' for Emacsen that don't define them.
>
> Please don't.  It violates the Emacs coding guidelines.  Packages that
> have gone that road have broken other packages in the past.
> E.g. color-scheme defined `replace-in-string´[1] which broke Gnus and
> emacs-jabber.

1+.

Tramp defines already an own `tramp-compat-delete-directory', in order
to handle the recursive case. It checks for the existence of a proper
`delete-directory' first. I do not want to add another check, whether
the "proper" `delete-directory' comes from gnuis-compat.el (and refuse
to use it then).

> Bye, Reiner.

Best regards, Michael.

Re: Emacs version compatibility

[David Engster]

Reiner Steib writes:
> On Wed, Feb 01 2012, Lars Ingebrigtsen wrote:
>
>> I think Ma Gnus should drop Emacs 22 compatibility, and it should also
>> drop non-Mule XEmacs compatibility.
>
> Fine with me.  Although dropping Emacs 22 probably doesn't help too
> much as long as you support XEmacs 21.4.

Indeed. The current problem regarding `delete-directory' is already an
example for that (at least Emacs22 warns during compilation, which
Xemacs 21.4 for some reason does not with our setup...).

>> More controversially :-), I think 真 Gnus should also stop defining
>> compatibility functions like `gnus-mark-active-p', and instead just
>> start maintaining a `gnus-compat.el' library that would define functions
>> like `mark-active-p' for Emacsen that don't define them.
>
> Please don't.  It violates the Emacs coding guidelines.  Packages that
> have gone that road have broken other packages in the past.
> E.g. color-scheme defined `replace-in-string´[1] which broke Gnus and
> emacs-jabber.

Agreed. I know it's tempting, but please don't do that; it *will* haunt
you later. The only solution is to radically drop support for older
(X)Emacs versions and live with it. Others can provide a compat package
if they want to, but do not put it in Gnus itself.

-David

Re: Emacs version compatibility

[Lars Ingebrigtsen]

Reiner Steib <reinersteib+gmane@imap.cc> writes:

> Please don't.  It violates the Emacs coding guidelines.  Packages that
> have gone that road have broken other packages in the past.
> E.g. color-scheme defined `replace-in-string´[1] which broke Gnus and
> emacs-jabber.

Yes, it's a maintenance nightmare.

On the other hand, I think there should be a (shared) repository of
compatibility functions, so that we all can pretend that we're
programming for the Emacs trunk.  The problem with that
`replace-in-string' was that it wasn't compatible with anything much.

I'm proposing that (learning from the gnulib example), that we should
have a repository of compat functions that behave like you'd expect them
to behave.

>> This will make the source code more readable, I think.
>
> I can't see that `mark-active-p' is much more readable as
> `gnus-mark-active-p´.

If you can rely on `gnus-mark-active-p' doing the same as
`mark-active-p', then that's true.  But you can't know that without
reading the code for the function in question.  It slows down reading
the code.

If you read some of the Gnus code, there are so many equivalent `gnus-*'
functions that's it's pretty frustrating.

-- 
(domestic pets only, the antidote for overdose, milk.)
  http://lars.ingebrigtsen.no  *  Sent from my Rome

Re: Emacs version compatibility

[Michael Albinus]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I'm proposing that (learning from the gnulib example), that we should
> have a repository of compat functions that behave like you'd expect them
> to behave.

That would be a way to go. However, that compat library shall support
older Emacsen as well as XEmacs. Could be put in the ELPA repository,
and shall be added to release tarballs. Amd shall be synced with XEmacs'
fsf-compat, somehow.

Which older Emacsen do you want to support? You have just dropped Emacs
22 support, Tramp is a little bit more friendly (it has dropped Emacs 21
support recently)

I would be willing to contribute to such repository. Tramp has stolen so
much code from Gnus, it's time to pay back :-)

Best regards, Michael.

Re: Emacs version compatibility

[Lars Ingebrigtsen]

Michael Albinus <michael.albinus@gmx.de> writes:

> That would be a way to go. However, that compat library shall support
> older Emacsen as well as XEmacs. Could be put in the ELPA repository,
> and shall be added to release tarballs. Amd shall be synced with XEmacs'
> fsf-compat, somehow.

Sounds good.  :-)

But I was thinking that (as with gnulib), projects would just copy stuff
from the compat library at will as they need it, instead of having to
include the entire shebang.  And they'd include different bits of it,
according to what Emacs versions they attempt supporting.

> Which older Emacsen do you want to support? You have just dropped Emacs
> 22 support, Tramp is a little bit more friendly (it has dropped Emacs 21
> support recently)
>
> I would be willing to contribute to such repository. Tramp has stolen so
> much code from Gnus, it's time to pay back :-)

:-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  http://lars.ingebrigtsen.no  *  Sent from my Rome

Re: Emacs version compatibility

[Michael Albinus]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> But I was thinking that (as with gnulib), projects would just copy stuff
> from the compat library at will as they need it, instead of having to
> include the entire shebang.  And they'd include different bits of it,
> according to what Emacs versions they attempt supporting.

Sure. First step into this direction could be a modularization of that
compat library into compat22.el, compat23.el, xcompat.el.

compat22.el would include compatibility functions needed in Emacs 22 and
introduced in Emacs 23, and compat23.el would include those from Emacs
24 aso. In Gnus, you could do

(if (featurep 'xemacs)
    (require 'xcompat)
  (require 'compat23))

In Tramp, I would also require compat22.el (as long as I'm not bored of
Emacs 22 support).

And there is a relation between fsf-compat.el from XEmacs, and
xcompat.el.

Best regards, Michael.

Re: Emacs version compatibility

[Lars Ingebrigtsen]

Michael Albinus <michael.albinus@gmx.de> writes:

> Sure. First step into this direction could be a modularization of that
> compat library into compat22.el, compat23.el, xcompat.el.

I was thinking the opposite.  :-)  All the items should check explicitly
for whatever they want to do, and not rely on Emacs versions at all.

That is, if you want to have `help-function-arglist' defined, then check
whether it's undefined, and then define it.  If you want a recursive
`delete-directories', then check the version of that function that's
installed, and if it's not satisfactory, then define a version that is.

So this would be orthogonal to the Emacs versions.  (Well, sort of.  The
function (re)definitions wouldn't necessarily work on all Emacs versions
that have ever been, so they need to check whether they can actually do
what they're trying to do.  Or give up.  Like this:

(when (and (not (fboundp 'help-function-arglist))
	   (fboundp 'function-arglist))
  (defun help-function-arglist (def &optional preserve-names)
     ))

So if you're on an Emacs that doesn't even have `function-arglist', then
you won't get this function.

-- 
(domestic pets only, the antidote for overdose, milk.)
  http://lars.ingebrigtsen.no  *  Sent from my Rome

Re: Emacs version compatibility

[Michael Albinus]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> So this would be orthogonal to the Emacs versions.  (Well, sort of.  The
> function (re)definitions wouldn't necessarily work on all Emacs versions
> that have ever been, so they need to check whether they can actually do
> what they're trying to do.  Or give up.  Like this:
>
> (when (and (not (fboundp 'help-function-arglist))
> 	   (fboundp 'function-arglist))
>   (defun help-function-arglist (def &optional preserve-names)
>      ))

You might support Emacs 22, and you might need this compatibility
code. Then you decide to drop Emacs 22 support, and you might not need
it any longer. How would you know whether you still need this code? And
how would you organize to take only the compatibility functions for
Emacs 23 and up?

Best regards, Michael.

Re: Emacs version compatibility

[Lars Ingebrigtsen]

Michael Albinus <michael.albinus@gmx.de> writes:

> You might support Emacs 22, and you might need this compatibility
> code. Then you decide to drop Emacs 22 support, and you might not need
> it any longer. How would you know whether you still need this code?
> And how would you organize to take only the compatibility functions
> for Emacs 23 and up?

Well, if you say "./configure --with-emacs=emacs23; make" and you then
get a warning about function `foo' being undefined or taking the wrong
number of parameters, then you just copy that function from the compat
library, and you're done.

Removing stuff you no longer need is slightly trickier, but isn't really
that vital, either.  If there are a few functions your targets no longer
need, that's no catastrophe.

But if you want to remove stuff, the just remove the entire compat file
and see what warnings you get, and put the stuff you need back in.

-- 
(domestic pets only, the antidote for overdose, milk.)
  http://lars.ingebrigtsen.no  *  Sent from my Rome

Re: Emacs version compatibility

[Michael Albinus]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> But if you want to remove stuff, the just remove the entire compat file
> and see what warnings you get, and put the stuff you need back in.

I package and release Tramp for years. When I started, it was
half-compatible with Emacs 19.

Your scenario doesn't sound appealing to me. Too much hand work. If
there is a general purpose compatibility package, I would like to
include it with minimal adaptation from my side. Otherwise, keeping an
own compatibility package is easier to handle.

Best regards, Michael.

Re: Emacs version compatibility

[Ted Zlatanov]

On Thu, 02 Feb 2012 13:32:45 +0100 Lars Ingebrigtsen <larsi@gnus.org> wrote: 

LI> Michael Albinus <michael.albinus@gmx.de> writes:
>> Sure. First step into this direction could be a modularization of that
>> compat library into compat22.el, compat23.el, xcompat.el.

LI> I was thinking the opposite.  :-)  All the items should check explicitly
LI> for whatever they want to do, and not rely on Emacs versions at all.

I think the package should use `provide' and `require' with subfeatures.

Then you can say

(if (featurep 'compat 'abc) 
    (use-abc)
  (message "No ABC, sorry"))

Ted

Re: Emacs version compatibility

[Lars Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> I think the package should use `provide' and `require' with subfeatures.
>
> Then you can say
>
> (if (featurep 'compat 'abc) 
>     (use-abc)
>   (message "No ABC, sorry"))

No, I don't want to say anything at all other than (require
'gnus-compat), and then forget about it.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  http://lars.ingebrigtsen.no  *  Sent from my Rome

Re: Emacs version compatibility

[Ted Zlatanov]

On Thu, 02 Feb 2012 14:29:33 +0100 Lars Ingebrigtsen <larsi@gnus.org> wrote: 

LI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> I think the package should use `provide' and `require' with subfeatures.
>> 
>> Then you can say
>> 
>> (if (featurep 'compat 'abc) 
>> (use-abc)
>> (message "No ABC, sorry"))

LI> No, I don't want to say anything at all other than (require
LI> 'gnus-compat), and then forget about it.  :-)

Your way sounds tempting, like donuts when you're on a diet, and yet you
know it's wrong...

Ted