Problem wih nXhtml in Emacs 24

Bug #892245 reported by lborgman
70
This bug affects 11 people
Affects Status Importance Assigned to Milestone
nXhtml
Confirmed
Critical
Unassigned

Bug Description

I'm using the latest nXhtml checked out from the repo, and using GNU Emacs version 24.0.91.1. When I open a PHP file it shows as un-syntax-highlighted text, and I get a compile error:

Error: Wrong type argument: number-or-marker-p, nil

and a message in the log:

File mode specification error: (cl-assertion-failed (functionp byte-compiled-fun))

I'm avoiding my .emacs and .emacs.d by running emacs with this command:

emacs -Q --eval '(load "/path/to/nxhtml/autostart")' /path/to/nxhtml/tests/in/heredoc.php

I searched for .elc and couldn't find any nxhtml compiled files, so if that error is happening in a byte-compiled file, how do I find out which one?

Someone on Stack Overflow suggested I try debugging but I'm lost with emacs lisp. I'm happy to do any kind of manual testing or updating.

Revision history for this message
lborgman (lennart-borgman) wrote :

Thanks MD, I converted your question to a bug report since this seems to be a bug.

I have not had time to test Emacs 24 at all yet. I hope I will be able to soon and then I will have a look at this.

Changed in nxhtml:
importance: Undecided → Critical
Revision history for this message
MDCore (mdcore) wrote :

Thanks, yes it should have been a bug report. Doh! I'm keen to help with any kind of testing.

Revision history for this message
sindikat (sindikat) wrote :

I had the following message in my *Compile-Log*:

Warning: `font-lock-beginning-of-syntax-function' is an obsolete variable (as
    of Emacs 23.3); use `syntax-begin-function' instead.
Warning: `font-lock-syntactic-keywords' is an obsolete variable (as of Emacs
    24.1); use `syntax-propertize-function' instead.

I use Emacs 24.0.91.3 and downloaded the latest nXhtml from the site.

Revision history for this message
Nate Cox (akujin) wrote :

Confirmed for Ubuntu 11.10 on Emacs 24.0.93.1 and nXhtml checked out from these repos.

The error I am seeing appears to be related to mumamo-fontify-region. Attached is my *Messages* for reference.

Any fix to this would be greatly appreciated, I'm trying to decide if I should switch to emacs from gvim and don't feel I'm getting a good impression of what emacs is really capable of at the moment.

Revision history for this message
Russell Sim (russell-sim) wrote :

Hi,

I decided to do a bit of debugging and I narrowed the Error: Wrong type argument: number-or-marker-p, nil error to line 3380 in util/mumamo.el the line looks like (byte-compile fetch-func-definition).

I dumbed the contents of the fetch-func-definition and it seemed that I could easily reproduce compile error. I also found the way to fix it was to delete some of the variables from the let. So perhaps there is an upper limit on how many variables can be assigned and 193 seems to be the max

for example if i create a file very symilar to the fetch-func-definition but instead just generate symbols with incrementing names. When I compile this it fails with the "Error: Wrong type argument: number-or-marker-p, nil" error, if I delete sym194 the compile error goes away.

(lambda
  (body)
  (make-local-variable 'parse-sexp-lookup-properties)
  (let
      ((sym1 "1")
       (sym2 "2")
       (sym3 "3")
....
       (sym193 "193")
       (sym194 "194")
       )
    (with-syntax-table php-mode-syntax-table
      (let
          (ret)
        (setq ret
              (eval body))
        ret))))

Perhaps this could be a bug in emacs24?

Revision history for this message
lborgman (lennart-borgman) wrote :

Thanks Russel, I have no idea, but I will send this to Emacs developers list to see if someone might understand what is going wrong here.

Could you please give details about what checkout of Emacs 24 you are using? (Emacs 24 is not yet released!)

Revision history for this message
lborgman (lennart-borgman) wrote :

Russel, your example did it. Stefan fixed the problem in Emacs 24 immediately. His answer should show up here soon:

http://lists.gnu.org/archive/html/emacs-devel/2012-03/msg00370.html

I am impressed by you two!

Changed in nxhtml:
status: New → Invalid
Gadji (gadjim4)
Changed in nxhtml:
assignee: nobody → Gadji (gadjim4)
assignee: Gadji (gadjim4) → nobody
Revision history for this message
Gavin van Lelyveld (mdcore+launchpad) wrote :

I recently upgraded to 12.04 and I just installed the latest emacs-snapshot. With an emacs setup that worked with version 23 nxhtml now works with version 24, specifically 24.1.50.1 . As far as I'm concerned this bug has been fixed.

Revision history for this message
lborgman (lennart-borgman) wrote :

Gavin, that sounds very nice. But what is 12.04?

The latest revision number of nXhtml in the Launchpad repository is 834. And I have given that nXhtml version 2.09 (not yet released).

Revision history for this message
Tom Davis (09rp9wq1q1h0lx-tom) wrote :

This appears to still be broken on Emacs 24.1.1 and nXhtml 2.09b. I'm pretty sure 24.1.1 is more up to date than the June snapshot.

Revision history for this message
Marc Bowes (marcbowes) wrote :

My emacs version is GNU Emacs 24.2.1 and this still affects me. Also see https://bugs.launchpad.net/nxhtml/+bug/659158

Revision history for this message
Marc Bowes (marcbowes) wrote :

I'm moving this to confirmed since it is trivially reproducible using either emacs 24 from a PPA such as ~cassou's or by building it by hand. Furthermore, this bug triggers exactly once per buffer that loads the mode (thereafter it seems ok) which is *extremely* frustrating when working on a project with many pages, such as a typical Rails project which has many pages and partials.

Changed in nxhtml:
status: Invalid → Confirmed
Revision history for this message
lborgman (lennart-borgman) wrote :

Thanks Marc, you are right it is broken. I took a quick look. Unfortunately it seems complicated. There is no chance I have time for it now. If any one can jump in it would be very good.

Revision history for this message
Lachlan Audas (laudas1) wrote :

Any news on a fix for this bug ?

Revision history for this message
lborgman (lennart-borgman) wrote : Re: [Bug 892245] Re: Problem wih nXhtml in Emacs 24

Sorry, no. As I said I would appreciate if anyone has time to look
into the problem.

On Thu, Feb 28, 2013 at 1:18 AM, Lachlan Audas <email address hidden> wrote:
> Any news on a fix for this bug ?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/892245
>
> Title:
> Problem wih nXhtml in Emacs 24
>
> Status in nXhtml for Emacs:
> Confirmed
>
> Bug description:
> I'm using the latest nXhtml checked out from the repo, and using GNU
> Emacs version 24.0.91.1. When I open a PHP file it shows as un-syntax-
> highlighted text, and I get a compile error:
>
> Error: Wrong type argument: number-or-marker-p, nil
>
> and a message in the log:
>
> File mode specification error: (cl-assertion-failed (functionp byte-
> compiled-fun))
>
> I'm avoiding my .emacs and .emacs.d by running emacs with this
> command:
>
> emacs -Q --eval '(load "/path/to/nxhtml/autostart")'
> /path/to/nxhtml/tests/in/heredoc.php
>
> I searched for .elc and couldn't find any nxhtml compiled files, so if
> that error is happening in a byte-compiled file, how do I find out
> which one?
>
> Someone on Stack Overflow suggested I try debugging but I'm lost with
> emacs lisp. I'm happy to do any kind of manual testing or updating.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/nxhtml/+bug/892245/+subscriptions

Revision history for this message
Soft Libre (softlibre) wrote :

I have found a partial solution to those warnings.

Those two variables are obsolet in emacs 24.

I try to find it in my nxhtml 2.08 directory and found them only un util/mumamo.el.
Then I proceed as following:

- I Commented those lines
- Bytecompile.
- Later, another warning shows up: the function `(interactive-p)` is also deprecated(or obsolete)
- I substitute it for `(called-interactively-p 'any)`.

Up to now works nice and without those warnings.

Here I will send you a diff output between the original mumamo.el and my edited file.

I will not correct this into the code because may has unwanted consequences: Some features may not work or may appear errors when using something specific. I haven't tested exahustivelly this!
Neither, I haven't analized what are the effects of commenting those parts nor why these variables has been used! It appears that the variable aren't useful because always has `nil` as value but I'm not sure about this.

Cheers!

Revision history for this message
lborgman (lennart-borgman) wrote :

That sounds very nice, Christian. :-)

Have you run the tests for nXhtml too?

Revision history for this message
Soft Libre (softlibre) wrote :

Actually, I'm writing a PHP page now and I fix this as soon as I could, so I couldn't test nXhtml more than just the escential: if compiles and work for continuing working... :P

Cheers!

Revision history for this message
lborgman (lennart-borgman) wrote :

Could you please run the test from nXhtml menu, Christian?

  nXhtml
      nXhtml Help and Setup
          Run nXhtml Tests in a Fresh Emacs

Revision history for this message
Soft Libre (softlibre) wrote :

done:

In *ert* buffer:

Selector: "nxhtml-ert-"
Passed: 21 (0 unexpected)
Failed: 0 (0 unexpected)
Error: 0 (0 unexpected)
Total: 21/21

Started at: 2013-06-03 11:08:08-0300
Finished.
Finished at: 2013-06-03 11:08:20-0300

.....................

In *Ert Failed Test Buffers*
 %* *ert* 228 ERT-Results

Is this correct?

Revision history for this message
lborgman (lennart-borgman) wrote :

That looks, very, very good, Christian! I will try to get time to test your patch a bit more this week. :-)

Revision history for this message
Soft Libre (softlibre) wrote :

I think I found some problems with this patch... some buffer highlighting don't update properly, for example when you type "/** my comment */" the font-lock continues working coloring the rest as comments despite you close it.

But as I said, I need time(I need some free time!) to analyze what are the consequences of commenting all those lines and if they can be substituted with something useful :-(

Cheers!

Revision history for this message
lborgman (lennart-borgman) wrote :

MuMaMo writes error messages into the *Messages* buffer. For your error above you might find more information there.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Related questions

Remote bug watches

Bug watches keep track of this bug in other bug trackers.