27.0.50, (void-function with-buffer-prepared-for-jit-lock)

27.0.50, (void-function with-buffer-prepared-for-jit-lock)

[Andreas Röhler]

Hi,

when running an uncompiled Emacs --which is preferred for jumping into 
maybe changed sources-- got

Error during redisplay: (jit-lock-function 1245) signaled (void-function 
with-buffer-prepared-for-jit-lock)

As it turns out in jit-lock.el it's wrapped into

(eval-when-compile

Might that envelope be removed?

Thanks,
Andreas
In GNU Emacs 27.0.50 (build 1, i686-pc-linux-gnu, GTK+ Version 3.14.5)
  of 2018-05-29

Re: 27.0.50, (void-function with-buffer-prepared-for-jit-lock)

[Stefan Monnier]

> when running an uncompiled Emacs --which is preferred for jumping into maybe
> changed sources-- got

There's no such thing as "an uncompiled Emacs".  All it means is that
you did something to use some uncompiled code somewhere, but without
clarifying what it is you did.

> Error during redisplay: (jit-lock-function 1245) signaled (void-function
> with-buffer-prepared-for-jit-lock)

So, apparently what you did was not right: if it hurts, don't do it.
Without knowing what it is you did, nor what it is you were trying to
do, it's hard to help you much further.


        Stefan

Re: 27.0.50, (void-function with-buffer-prepared-for-jit-lock)

[Andreas Röhler]

On 30.06.2018 01:14, Stefan Monnier wrote:
>> when running an uncompiled Emacs --which is preferred for jumping into maybe
>> changed sources-- got
> 
> There's no such thing as "an uncompiled Emacs". 

Okay. Should mean didn't compile elisp .el files into .elc



  All it means is that
> you did something to use some uncompiled code somewhere, but without
> clarifying what it is you did.
> 
>> Error during redisplay: (jit-lock-function 1245) signaled (void-function
>> with-buffer-prepared-for-jit-lock)
> 
> So, apparently what you did was not right: 


Well, the question is if a general used function should depend from

(eval-when-compile

Maybe there are reasons, don't know.
Being able to run elisp code without compiling its .el sources is a gain 
to consider.

Might be also a design issue of eval-when-compile, saying:

"In interpreted code, this is entirely equivalent to
‘progn’, except that the value of the expression may be (but is
not necessarily) computed at load time if eager macro expansion
is enabled."

Such "may be (but is not necessarily)" doesn't sound that well.

Best,
Andreas

Re: 27.0.50, (void-function with-buffer-prepared-for-jit-lock)

[Stefan Monnier]

> Okay. Should mean didn't compile elisp .el files into .elc

All files?  Some of the files?

>  All it means is that
>> you did something to use some uncompiled code somewhere, but without
>> clarifying what it is you did.
>>
>>> Error during redisplay: (jit-lock-function 1245) signaled (void-function
>>> with-buffer-prepared-for-jit-lock)
>>
>> So, apparently what you did was not right: 
>
> Well, the question is if a general used function should depend from
>
> (eval-when-compile

The content of eval-when-compile is executed when the .el file is loaded
(it's not executed when the .elc file is loaded, because it's executed
when the .elc file is generated instead).

So, loading jit-lock.el will define with-buffer-prepared-for-jit-lock
just fine and hence not compiling jit-lock.el (like you seem to claim you
did) doesn't explain the error you got.

IOW, I still don't think you've actually described what you've done.
My guess is that you M-C-x (or eval-region or something like that) to
(re)evaluate a particular chunk of jit-lock.el.

And indeed, doing that doesn't always work right because of things like

    (eval-when-compile (require <foo>))

But M-x eval-buffer (or M-x load-file RET .../foo.el) normally works fine.


        Stefan

Re: 27.0.50, (void-function with-buffer-prepared-for-jit-lock)

[Alan Mackenzie]

Hello, Stefan.

On Fri, Jun 29, 2018 at 19:14:50 -0400, Stefan Monnier wrote:
> > when running an uncompiled Emacs --which is preferred for jumping into maybe
> > changed sources-- got

> There's no such thing as "an uncompiled Emacs".  All it means is that
> you did something to use some uncompiled code somewhere, but without
> clarifying what it is you did.

> > Error during redisplay: (jit-lock-function 1245) signaled (void-function
> > with-buffer-prepared-for-jit-lock)

> So, apparently what you did was not right: if it hurts, don't do it.
> Without knowing what it is you did, nor what it is you were trying to
> do, it's hard to help you much further.

I had a similar experience with the macro save-buffer-state in
font-lock.el.  This macro is restricted by the surrounding
eval-when-compile.  So when I tried to instrument
font-lock-default-fontify-region for edebug, edebug assumed
save-buffer-state was an unknown function, and when I tried to run it,
it threw an error.

It was irritating to have to compile save-buffer-state by hand (with C-x
C-e) and then to instrument f-l-d-fontify-region again.

I thus concur with Andreas, that such macros (and possibly require
operations) should be available at run time.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: 27.0.50, (void-function with-buffer-prepared-for-jit-lock)

[Stefan Monnier]

> I had a similar experience with the macro save-buffer-state in
> font-lock.el.  This macro is restricted by the surrounding
> eval-when-compile.  So when I tried to instrument
> font-lock-default-fontify-region for edebug, edebug assumed
> save-buffer-state was an unknown function, and when I tried to run it,
> it threw an error.

Oh, yes, been there, many times.
Maybe we could look for preceding `eval-when-compile` forms when
instrumenting (as well as when using C-M-x and a few other cases) and
either blindly run them or ask the user.  We already have some similar
code that looks for preceding (defvar FOO) in eval-sexp-add-defvars
maybe we could just extend that.


        Stefan