* How to fix Emacs24 compiler warning w/o breaking code for previous versions
@ 2011-06-16 17:44 Eric Schulte
2011-06-17 3:10 ` Stefan Monnier
2011-06-17 7:19 ` David Engster
0 siblings, 2 replies; 9+ messages in thread
From: Eric Schulte @ 2011-06-16 17:44 UTC (permalink / raw
To: emacs-devel
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/
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: How to fix Emacs24 compiler warning w/o breaking code for previous versions
2011-06-16 17:44 How to fix Emacs24 compiler warning w/o breaking code for previous versions Eric Schulte
@ 2011-06-17 3:10 ` Stefan Monnier
2011-06-17 3:42 ` Jambunathan K
2011-06-17 4:45 ` Eric Schulte
2011-06-17 7:19 ` David Engster
1 sibling, 2 replies; 9+ messages in thread
From: Stefan Monnier @ 2011-06-17 3:10 UTC (permalink / raw
To: Eric Schulte; +Cc: emacs-devel
> 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: How to fix Emacs24 compiler warning w/o breaking code for previous versions
2011-06-17 3:10 ` Stefan Monnier
@ 2011-06-17 3:42 ` Jambunathan K
2011-06-17 6:34 ` Stephen J. Turnbull
` (2 more replies)
2011-06-17 4:45 ` Eric Schulte
1 sibling, 3 replies; 9+ messages in thread
From: Jambunathan K @ 2011-06-17 3:42 UTC (permalink / raw
To: Stefan Monnier; +Cc: Eric Schulte, emacs-devel
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
>
>
--
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: How to fix Emacs24 compiler warning w/o breaking code for previous versions
2011-06-17 3:10 ` Stefan Monnier
2011-06-17 3:42 ` Jambunathan K
@ 2011-06-17 4:45 ` Eric Schulte
1 sibling, 0 replies; 9+ messages in thread
From: Eric Schulte @ 2011-06-17 4:45 UTC (permalink / raw
To: Stefan Monnier; +Cc: emacs-devel
>
> - 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/
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: How to fix Emacs24 compiler warning w/o breaking code for previous versions
2011-06-17 3:42 ` Jambunathan K
@ 2011-06-17 6:34 ` Stephen J. Turnbull
2011-06-17 7:17 ` Eli Zaretskii
2011-06-19 21:14 ` Daniel Colascione
2011-06-20 7:53 ` David Kastrup
2 siblings, 1 reply; 9+ messages in thread
From: Stephen J. Turnbull @ 2011-06-17 6:34 UTC (permalink / raw
To: Jambunathan K; +Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: How to fix Emacs24 compiler warning w/o breaking code for previous versions
2011-06-17 6:34 ` Stephen J. Turnbull
@ 2011-06-17 7:17 ` Eli Zaretskii
0 siblings, 0 replies; 9+ messages in thread
From: Eli Zaretskii @ 2011-06-17 7:17 UTC (permalink / raw
To: Stephen J. Turnbull; +Cc: kjambunathan, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: How to fix Emacs24 compiler warning w/o breaking code for previous versions
2011-06-16 17:44 How to fix Emacs24 compiler warning w/o breaking code for previous versions Eric Schulte
2011-06-17 3:10 ` Stefan Monnier
@ 2011-06-17 7:19 ` David Engster
1 sibling, 0 replies; 9+ messages in thread
From: David Engster @ 2011-06-17 7:19 UTC (permalink / raw
To: Eric Schulte; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: How to fix Emacs24 compiler warning w/o breaking code for previous versions
2011-06-17 3:42 ` Jambunathan K
2011-06-17 6:34 ` Stephen J. Turnbull
@ 2011-06-19 21:14 ` Daniel Colascione
2011-06-20 7:53 ` David Kastrup
2 siblings, 0 replies; 9+ messages in thread
From: Daniel Colascione @ 2011-06-19 21:14 UTC (permalink / raw
To: Stefan Monnier, Eric Schulte, emacs-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: How to fix Emacs24 compiler warning w/o breaking code for previous versions
2011-06-17 3:42 ` Jambunathan K
2011-06-17 6:34 ` Stephen J. Turnbull
2011-06-19 21:14 ` Daniel Colascione
@ 2011-06-20 7:53 ` David Kastrup
2 siblings, 0 replies; 9+ messages in thread
From: David Kastrup @ 2011-06-20 7:53 UTC (permalink / raw
To: emacs-devel
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
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2011-06-20 7:53 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-06-16 17:44 How to fix Emacs24 compiler warning w/o breaking code for previous versions Eric Schulte
2011-06-17 3:10 ` Stefan Monnier
2011-06-17 3:42 ` Jambunathan K
2011-06-17 6:34 ` Stephen J. Turnbull
2011-06-17 7:17 ` Eli Zaretskii
2011-06-19 21:14 ` Daniel Colascione
2011-06-20 7:53 ` David Kastrup
2011-06-17 4:45 ` Eric Schulte
2011-06-17 7:19 ` David Engster
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.