byte-compilation woes (cont'd)

byte-compilation woes (cont'd)

[Drew Adams]

Just wondering whether there is any way around this...

With a build from 3/21 I had no problem:

In GNU Emacs 24.4.50.1 (i686-pc-mingw32)
 of 2014-03-21 on ODIEONE
Bzr revision: 116829 dancol@dancol.org-20140321121023-5tjxtiws6qa4qyod
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/Devel/emacs/snapshot/trunk
 --enable-checking=yes,glyphs 'CFLAGS=-O0 -g3' 'CPPFLAGS=-DGC_MCHECK=1
 -Ic:/Devel/emacs/include' LDFLAGS=-Lc:/Devel/emacs/lib'

With a build from 3/23 I have a problem:

In GNU Emacs 24.4.50.1 (i686-pc-mingw32)
 of 2014-03-23 on ODIEONE
Bzr revision: 116869 yamaoka@jpl.org-20140324004210-m3ek4k40qwamyabx
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/Devel/emacs/snapshot/trunk
 --enable-checking=yes,glyphs 'CFLAGS=-O0 -g3'
 LDFLAGS=-Lc:/Devel/emacs/lib 'CPPFLAGS=-DGC_MCHECK=1
 -Ic:/Devel/emacs/include''

Here's the problem.  My library help-fns+.el extends help-fns.el
in various ways.  It is compatible with Emacs 22 through 24.  Until
now, you could byte-compile it using Emacs 23 and use the compiled
file with Emacs 22, 23, or 24 - no problem.  Handy for someone (like
me) who has multiple Emacs versions.

(You could not byte-compile it using 22 or 24 and be able to use
the result with other versions, however.  Emacs 23 was Goldilocks
for this.)

With the latest Emacs 24 build (from 3/23), I now must byte-compile
help-fns+.el using that build, to be able to use it with that build.
And doing that prevents using the compiled file with Emacs 22 or 23.

Worse still.  If byte-compiled with the latest build it is not even
usable with Emacs 24.3 (wrong number of args for `help-window-setup').

What is the symptom if you use the library compiled with Emacs 23
in the latest Emacs 24 build?  Buffer *Help* is in Fundamental mode.
I have no idea why, and I don't really feel like digging into
finding out why, in hopes that some minor tweak might fix things.

Anyone have an idea what recent change causes this difference
between a build from 3/21 and a build from 3/23?  Anyone see a
simple fix/workaround to the problem?  Thx.

As Emacs 24.4 is not yet released, I'm hoping this might represent
just another temporary hiccup from "using a revision from that
unfortunate period" where an inadvertent mistake crept in
temporarily.  (There's always room for hope, no?)  If not, and if
there is no simple workaround, so be it.

Re: byte-compilation woes (cont'd)

[Juanma Barranquero]

On Wed, Mar 26, 2014 at 12:19 AM, Drew Adams <drew.adams@oracle.com> wrote:

> With the latest Emacs 24 build (from 3/23), I now must byte-compile
> help-fns+.el using that build, to be able to use it with that build.
> And doing that prevents using the compiled file with Emacs 22 or 23.
>
> Worse still.  If byte-compiled with the latest build it is not even
> usable with Emacs 24.3 (wrong number of args for `help-window-setup').

Do your functions use cl-style :keyword args? There's been two recent
changes related to &key parsing, and your snapshot only includes the
first one (the second one is revno:116871).

   J

Re: byte-compilation woes (cont'd)

[Daniel Colascione]

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

On 03/25/2014 04:41 PM, Juanma Barranquero wrote:
> On Wed, Mar 26, 2014 at 12:19 AM, Drew Adams <drew.adams@oracle.com> wrote:
> 
>> With the latest Emacs 24 build (from 3/23), I now must byte-compile
>> help-fns+.el using that build, to be able to use it with that build.
>> And doing that prevents using the compiled file with Emacs 22 or 23.
>>
>> Worse still.  If byte-compiled with the latest build it is not even
>> usable with Emacs 24.3 (wrong number of args for `help-window-setup').
> 
> Do your functions use cl-style :keyword args? There's been two recent
> changes related to &key parsing, and your snapshot only includes the
> first one (the second one is revno:116871).

I thought about that --- but the change only affects newly-compiled
code, and it should be perfectly compatible with the old code. The new
&key parsing code doesn't appear to be intrinsically buggy, since Drew's
code works when run on the same Emacs on which it's compiled. I'd be
very surprised if this change ended up being the problem.


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

RE: byte-compilation woes (cont'd)

[Drew Adams]

> Do your functions use cl-style :keyword args? There's been two recent
> changes related to &key parsing, and your snapshot only includes the
> first one (the second one is revno:116871).

No, except:

I use `define-button-type', to which I pass :type or :supertype.
And I use `defface', with face specs that use keyword args.

And my redefinition of `describe-variable', like the original, uses
an error handler of (error :help-eval-error).

And I use a predicate that calls (widget-get type :match),
(widget-apply type :match value), (widget-get type :validate), and
(widget-put type :value value).

And my command `describe-file' uses '(:margin 10) as part of a
`display' property value with `propertize'.

Re: byte-compilation woes (cont'd)

[Daniel Colascione]

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

On 03/25/2014 04:19 PM, Drew Adams wrote:
> Just wondering whether there is any way around this...
> 
> With a build from 3/21 I had no problem:
> 
> In GNU Emacs 24.4.50.1 (i686-pc-mingw32)
>  of 2014-03-21 on ODIEONE
> Bzr revision: 116829 dancol@dancol.org-20140321121023-5tjxtiws6qa4qyod
> Windowing system distributor `Microsoft Corp.', version 6.1.7601
> Configured using:
>  `configure --prefix=/c/Devel/emacs/snapshot/trunk
>  --enable-checking=yes,glyphs 'CFLAGS=-O0 -g3' 'CPPFLAGS=-DGC_MCHECK=1
>  -Ic:/Devel/emacs/include' LDFLAGS=-Lc:/Devel/emacs/lib'
> 
> With a build from 3/23 I have a problem:
> 
> In GNU Emacs 24.4.50.1 (i686-pc-mingw32)
>  of 2014-03-23 on ODIEONE
> Bzr revision: 116869 yamaoka@jpl.org-20140324004210-m3ek4k40qwamyabx
> Windowing system distributor `Microsoft Corp.', version 6.1.7601
> Configured using:
>  `configure --prefix=/c/Devel/emacs/snapshot/trunk
>  --enable-checking=yes,glyphs 'CFLAGS=-O0 -g3'
>  LDFLAGS=-Lc:/Devel/emacs/lib 'CPPFLAGS=-DGC_MCHECK=1
>  -Ic:/Devel/emacs/include''
> 
> Here's the problem.  My library help-fns+.el extends help-fns.el
> in various ways.  It is compatible with Emacs 22 through 24.  Until
> now, you could byte-compile it using Emacs 23 and use the compiled
> file with Emacs 22, 23, or 24 - no problem.  Handy for someone (like
> me) who has multiple Emacs versions.
> 
> (You could not byte-compile it using 22 or 24 and be able to use
> the result with other versions, however.  Emacs 23 was Goldilocks
> for this.)
> 
> With the latest Emacs 24 build (from 3/23), I now must byte-compile
> help-fns+.el using that build, to be able to use it with that build.
> And doing that prevents using the compiled file with Emacs 22 or 23.
> 
> Worse still.  If byte-compiled with the latest build it is not even
> usable with Emacs 24.3 (wrong number of args for `help-window-setup').

I think breaking this way is perfectly reasonable. I don't think we
should invest in downward compatibility of byte-compiled files.

> What is the symptom if you use the library compiled with Emacs 23
> in the latest Emacs 24 build?  Buffer *Help* is in Fundamental mode.
> I have no idea why, and I don't really feel like digging into
> finding out why, in hopes that some minor tweak might fix things.

Can you please share the Emacs 23 elc file?

> 
> Anyone have an idea what recent change causes this difference
> between a build from 3/21 and a build from 3/23?  Anyone see a
> simple fix/workaround to the problem?  Thx.

package.el :-D

> 
> As Emacs 24.4 is not yet released, I'm hoping this might represent
> just another temporary hiccup from "using a revision from that
> unfortunate period" where an inadvertent mistake crept in
> temporarily.  (There's always room for hope, no?)  If not, and if
> there is no simple workaround, so be it.

I took a look at the changelog, but no breaking changes are immediately
apparent.


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

Re: byte-compilation woes (cont'd)

[Daniel Colascione]

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

On 03/25/2014 04:42 PM, Daniel Colascione wrote:
> On 03/25/2014 04:19 PM, Drew Adams wrote:
>> Here's the problem.  My library help-fns+.el extends help-fns.el
>> in various ways.  It is compatible with Emacs 22 through 24.  Until
>> now, you could byte-compile it using Emacs 23 and use the compiled
>> file with Emacs 22, 23, or 24 - no problem.  Handy for someone (like
>> me) who has multiple Emacs versions.

By the way: you might want to reconsider your use of function overrides
in your *+.el packages. That's about the riskiest possible thing to do
from a compatibility perspective, and it's impossible to maintain
compatibility with packages that work like this. I know you want to run
on older versions of Emacs, but it'd be better to contribute these
changes to the core.


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

RE: byte-compilation woes (cont'd)

[Drew Adams]

> it'd be better to contribute these changes to the core.

I've already explicitly contributed all of the features in
help-fns+.el, long ago.  Emacs Dev wasn't interested.  The
offer still stands, of course.

I have no desire to maintain a separate library for such
stuff.  But as long as Emacs does not incorporate such features
I will continue to offer them separately for anyone who wants
them. (Same is true for info+.el, isearch+.el, bookmark+, etc.)

RE: byte-compilation woes (cont'd)

[Drew Adams]

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

> Can you please share the Emacs 23 elc file?

Attached.

[-- Attachment #2: help-fns+.elc --]
[-- Type: application/octet-stream, Size: 76193 bytes --]

RE: byte-compilation woes (cont'd)

[Drew Adams]

Actually, it is not just the byte-compiled file that is the problem.

It seems that I need to replace `with-output-to-temp-buffer' with
`with-help-window' everywhere.  Otherwise, *Help* ends up in
Fundamental mode.  This should not be, I would think.

I've filed bug # for this regression in the behavior of
`with-output-to-temp-buffer'.

Re: byte-compilation woes (cont'd)

[Daniel Colascione]

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

On 03/26/2014 01:17 PM, Drew Adams wrote:
> Actually, it is not just the byte-compiled file that is the problem.
> 
> It seems that I need to replace `with-output-to-temp-buffer' with
> `with-help-window' everywhere.  Otherwise, *Help* ends up in
> Fundamental mode.  This should not be, I would think.
> 
> I've filed bug # for this regression in the behavior of
> `with-output-to-temp-buffer'.

Thanks. That makes a lot more sense. We can talk about the help issue
separately; I'm just glad we don't have a much scarier bytecode problem.


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