Bug 145759 - Error when fontifying Makefile with conditional
Error when fontifying Makefile with conditional
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: emacs (Show other bugs)
3
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jens Petersen
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-01-21 01:55 EST by Mark Huang
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-07-13 20:16:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Mark Huang 2005-01-21 01:55:11 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041111 Firefox/1.0

Description of problem:
Attempting to interactively call M-x font-lock-fontify-buffer (or if
lazy-lock-mode is enabled) on a Makefile that contains a conditional:

ifndef foo
all:
endif

causes emacs to print an error "No match 2 in highlight (2
font-lock-variable-name-face)".

If lazy-lock-mode is enabled, then emacs will load the Makefile into a
buffer and mark it as modified (annoying), but will not switch to the
buffer (really annoying). If you manually switch to the buffer, emacs
will print the error every time the line containing the conditional is
changed (really, really annoying).

The problem does not occur on RHAS-3 (emacs-21.3-4) but I could see no
difference between make-mode.elc and font-lock.elc on my RHAS-3 box
and the same files on (several) FC3 boxes.

Version-Release number of selected component (if applicable):
emacs-21.3-17

How reproducible:
Always

Steps to Reproduce:
1. cat >Makefile <<EOF
ifndef foo
all:
endif
EOF
2. emacs -q --no-site-file Makefile
3. M-x font-lock-fontify-buffer

Actual Results:  emacs will mark the buffer as modified and print "No
match 2 in highlight (2 font-lock-variable-name-face)".

Expected Results:  emacs should fontify the buffer and not print an error.

Additional info:

Backtrace:

Debugger entered--Lisp error: (error "No match 2 in highlight (2
font-lock-variable-name-face)")
  signal(error ("No match 2 in highlight (2
font-lock-variable-name-face)"))
  error("No match %d in highlight %S" 2 (2 font-lock-variable-name-face))
  font-lock-fontify-keywords-region(1 23 t)
  font-lock-default-fontify-region(1 23 t)
  font-lock-fontify-region(1 23 t)
  byte-code("&#138;� �&#142;�ed	#&#136;� &#136;�+�&#135;"
[save-match-data-internal verbose font-lock-fontified match-data
((set-match-data save-match-data-internal)) font-lock-fontify-region
font-lock-after-fontify-buffer t] 4)
  font-lock-default-fontify-buffer()
  font-lock-fontify-buffer()
* call-interactively(font-lock-fontify-buffer)
  execute-extended-command(nil)
  call-interactively(execute-extended-command)
Comment 1 Jens Petersen 2005-02-24 08:38:28 EST
Seems to work fine for me both in a terminal and under X window.
I must be missing something.

Can you tell me more about your environment: which desktop?
What locale are you running in?
Comment 2 Mark Huang 2005-02-24 15:33:28 EST
I created a dummy user on my FC3 box, to see if it was my dotfiles,
but I got the same error.

Desktop is KDE and locale is en_US.UTF-8, but I see the problem in
both console and X mode, with and without LC_ALL=C.

--Mark
Comment 3 Jens Petersen 2005-02-25 01:08:39 EST
Is it reproducible for you about under GNOME too?
Comment 4 Mark Huang 2005-02-25 11:23:46 EST
Yes, it is reproducible under GNOME with default dotfiles. It is
reproducible under KDE, on a virtual text console, and on a pty via
SSH. I have tried TERM=vt100, TERM=linux, TERM=xterm, all with the
same results.
Comment 5 Mark Huang 2005-07-13 14:23:06 EDT
FYI, this problem seems to have disappeared in FC4 emacs-21.4-5. The error
message no longer prints, and Makefile conditionals are now fontified correctly.
You can probably close this off. Thanks!
Comment 6 Jens Petersen 2005-07-13 20:16:55 EDT
Ok, thanks, that is good.  Not sure why though. :)

Perhaps this bug is related to bug 158044 afterall?

Note You need to log in before you can comment on or make changes to this bug.