How to fix Emacs24 compiler warning w/o breaking code for previous versions

How to fix Emacs24 compiler warning w/o breaking code for previous versions

[Eric Schulte]

Hi,

I've been working to address the elisp byte-compiler warnings thrown
while compiling the current Org-mode head, and I do not know how to
address cases where the byte-compiler insists on usage of a new feature
not present in older Emacsen without breaking Org-mode support of those
Emacsen.  I'm writing to ask for the "best practices" approach?

Here are two examples.

On Emacs23 the `filter-buffer-substring-functions' variable (introduced
in May of 2010) is preferred over the `buffer-substring-filters'
function which is now deprecated.  Using the former breaks all prior
Emacsen while using the later throws compiler warnings on Emacs24.

Similarly, the `interactive-p' function is now defunct and not liked by
the byte compiler, however the suggested replacement function
`called-interactive-p' requires an argument in Emacs24, and accepts no
arguments in Emacs22.

The obvious solution here would be to replace both of these instances
with new Org-mode functions which check either Emacs version or check
for existence/definition of the relevant variable/function and then
behave accordingly.  That however seems uglier than just using the
deprecated version of these functions.

Any advice is greatly appreciated.

Thanks -- Eric

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: How to fix Emacs24 compiler warning w/o breaking code for previous versions

[Stefan Monnier]

> I've been working to address the elisp byte-compiler warnings thrown
> while compiling the current Org-mode head, and I do not know how to
> address cases where the byte-compiler insists on usage of a new feature
> not present in older Emacsen without breaking Org-mode support of those
> Emacsen.  I'm writing to ask for the "best practices" approach?

IMNSHO:
- The simplest solution is to only support a single or a very limited
  number of Emacs versions.
- Another good one is to support many versions, only pay attention to
  warnings in the most recent supported version, and accept some warnings
  as "better have the warnings than break backward compatibility".
- The next best one is to do as above except that you additionally wrap
  the remaining warnings in `with-no-warnings' (and regularly remove
  those `with-no-warnings' to remind you of the problems you can't fix
  yet because of backward compatibility).
I strongly recommend against aiming to silence warnings on all the
supported Emacs versions.  It's a waste of time and leads to poor code
(e.g. ugly/brittle byte-compiler hacks, cc-bytecomp comes to mind, I'd
better stop here or I'll have nightmares again).


        Stefan

Re: How to fix Emacs24 compiler warning w/o breaking code for previous versions

[Jambunathan K]

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

>> I've been working to address the elisp byte-compiler warnings thrown
>> while compiling the current Org-mode head, and I do not know how to
>> address cases where the byte-compiler insists on usage of a new feature
>> not present in older Emacsen without breaking Org-mode support of those
>> Emacsen.  I'm writing to ask for the "best practices" approach?
>
> IMNSHO:
> - The simplest solution is to only support a single or a very limited
>   number of Emacs versions.
> - Another good one is to support many versions, only pay attention to
>   warnings in the most recent supported version, and accept some warnings
>   as "better have the warnings than break backward compatibility".
> - The next best one is to do as above except that you additionally wrap
>   the remaining warnings in `with-no-warnings' (and regularly remove
>   those `with-no-warnings' to remind you of the problems you can't fix
>   yet because of backward compatibility).
> I strongly recommend against aiming to silence warnings on all the
> supported Emacs versions.  It's a waste of time and leads to poor code
> (e.g. ugly/brittle byte-compiler hacks, cc-bytecomp comes to mind, I'd
> better stop here or I'll have nightmares again).


I was hoping that there is an elisp equivalent for C-like

#if emacs-version > a
    do this
#else
    do that
#endif



>
>
>         Stefan
>
>

-- 

Re: How to fix Emacs24 compiler warning w/o breaking code for previous versions

[Stephen J. Turnbull]

Jambunathan K writes:

 > I was hoping that there is an elisp equivalent for C-like
 > 
 > #if emacs-version > a

First, I don't think this is generally a very good idea.  I prefer
actual feature tests where new features matter, and let the byte
compiler warnings fall where they may in older versions.  That said:

XEmacs has `emacs-version>=', although my local Emacs (21.2.1) doesn't
seem to (not with any spelling starting with "emacs-version", anyway).
I didn't write it and offhand don't know who did, so I can't
contribute it, but it's not hard to write.  You just have to take care
to handle the lexicographic comparison correctly (eg, w.r.t. null
arguments, which is why actually having it is useful vs. homebrew --
homebrew functions often got that wrong).

If you want to check XEmacs compatibility, I'll be happy to compare
anyone's version to the XEmacs algorithm (to avoid legal issues, the
programmer shouldn't do it himself of course).

We don't have `emacs-version=' or `emacs-version>'.  I don't think
they're very useful, though, compared to the ">=" variety.  Nor has
anybody asked for them or tried to contribute them that I can recall.

Here's our doctring:

`emacs-version>=' is a compiled Lisp function
  -- loaded from "/playpen/src/XEmacs/xemacs/lisp/version.elc"
(emacs-version>= MAJOR &optional MINOR PATCH)

Documentation:
Return true if the Emacs version is >= to the given MAJOR, MINOR,
   and PATCH numbers.
The MAJOR version number argument is required, but the other arguments
are optional. Only the Non-nil arguments are used in the test.

Re: How to fix Emacs24 compiler warning w/o breaking code for previous versions

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Date: Fri, 17 Jun 2011 15:34:27 +0900
> Cc: emacs-devel@gnu.org
> 
> XEmacs has `emacs-version>=', although my local Emacs (21.2.1) doesn't
> seem to (not with any spelling starting with "emacs-version", anyway).

The Emacs way of doing that is

  (version<= "23.2" emacs-version)

This was introduced in Emacs 22.1.

Re: How to fix Emacs24 compiler warning w/o breaking code for previous versions

[Daniel Colascione]

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

On 6/16/11 8:42 PM, Jambunathan K wrote:
> I was hoping that there is an elisp equivalent for C-like
> 
> #if emacs-version > a
>     do this
> #else
>     do that
> #endif
> 

The Common Lisp #+ reader macro provides the facility you want. For example,

    (progn #+some-feature 42)

would read as

    (progn 42)

on systems with some-feature present and

    (progn)

on systems without that feature.

CL also allows arbitrary combinations of and, or, and not calls, e.g,

    #+(or feature1 (not feature2))

#- also exists, and is similar, except that the sense of the test is
inverted.

Might this feature be worth adding to Emacs? Of course, it would only
help code written for Emacs 24 and above.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: How to fix Emacs24 compiler warning w/o breaking code for previous versions

[David Kastrup]

Jambunathan K <kjambunathan@gmail.com> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>> I've been working to address the elisp byte-compiler warnings thrown
>>> while compiling the current Org-mode head, and I do not know how to
>>> address cases where the byte-compiler insists on usage of a new feature
>>> not present in older Emacsen without breaking Org-mode support of those
>>> Emacsen.  I'm writing to ask for the "best practices" approach?
>>
>> IMNSHO:
>> - The simplest solution is to only support a single or a very limited
>>   number of Emacs versions.
>> - Another good one is to support many versions, only pay attention to
>>   warnings in the most recent supported version, and accept some warnings
>>   as "better have the warnings than break backward compatibility".
>> - The next best one is to do as above except that you additionally wrap
>>   the remaining warnings in `with-no-warnings' (and regularly remove
>>   those `with-no-warnings' to remind you of the problems you can't fix
>>   yet because of backward compatibility).
>> I strongly recommend against aiming to silence warnings on all the
>> supported Emacs versions.  It's a waste of time and leads to poor code
>> (e.g. ugly/brittle byte-compiler hacks, cc-bytecomp comes to mind, I'd
>> better stop here or I'll have nightmares again).
>
> I was hoping that there is an elisp equivalent for C-like
>
> #if emacs-version > a
>     do this
> #else
>     do that
> #endif

(if (version<= "21.0" emacs-version)

-- 
David Kastrup

Re: How to fix Emacs24 compiler warning w/o breaking code for previous versions

[Eric Schulte]

> 
> - Another good one is to support many versions, only pay attention to
>   warnings in the most recent supported version, and accept some warnings
>   as "better have the warnings than break backward compatibility".
> 

This solution looks great to me.

Thanks for the confirmation that the opinions of the byte-compiler don't
trump clean code.

Cheers -- Eric

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: How to fix Emacs24 compiler warning w/o breaking code for previous versions

[David Engster]

Eric Schulte writes:
> I've been working to address the elisp byte-compiler warnings thrown
> while compiling the current Org-mode head, and I do not know how to
> address cases where the byte-compiler insists on usage of a new feature
> not present in older Emacsen without breaking Org-mode support of those
> Emacsen.  I'm writing to ask for the "best practices" approach?

Not that I think that it is a particularly good example (it's pretty
messy, actually), but you might want to look at the Gnus-git repo for
ideas. The problem with the "ignore warnings on older Emacsen" approach
is that pretty soon you will have difficulties spotting those warnings
which signal a real problem. This is especially true if you're using a
continuous build system like Gnus does.

At least for this automatic build, it currently restricts warnings to
the classes '(free-vars unresolved callargs redefine suspicious). If a
spurious warning from one of that classes pops up, we make the
byte-compiler be quite about it (see lisp/lpath.el in the Gnus repo).

-David