From xemacs-m  Tue Apr 29 18:47:29 1997
Received: from CNRI.Reston.VA.US (CNRI.Reston.VA.US [132.151.1.1])
	by xemacs.org (8.8.5/8.8.5) with SMTP id SAA11770
	for <xemacs-beta@xemacs.org>; Tue, 29 Apr 1997 18:47:27 -0500 (CDT)
Received: from newcnri.cnri.reston.va.us by CNRI.Reston.VA.US id aa23374;
          29 Apr 97 19:48 EDT
Received: from anthem.CNRI.Reston.Va.US by newcnri.CNRI.Reston.Va.US (SMI-8.6/SMI-SVR4)
	id TAA12674; Tue, 29 Apr 1997 19:48:35 -0400
Received: by anthem.CNRI.Reston.Va.US (SMI-8.6/SMI-SVR4)
	id TAA03359; Tue, 29 Apr 1997 19:48:33 -0400
Date: Tue, 29 Apr 1997 19:48:33 -0400
Message-Id: <199704292348.TAA03359@anthem.CNRI.Reston.Va.US>
From: "Barry A. Warsaw" <bwarsaw@CNRI.Reston.VA.US>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="S8i/rSB6Ox"
Content-Transfer-Encoding: 7bit
To: xemacs-beta@xemacs.org
Subject: Reproduceable font-lock bug
X-Mailer: VM 6.29 under 19.15 XEmacs Lucid
Reply-To: bwarsaw@python.org
X-Attribution: BAW
X-Oblique-Strategy: State the problem in words as clearly as possible
X-Url: http://www.python.org/~bwarsaw


--S8i/rSB6Ox
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Here is a bug in font-lock that I've been able to reproduce under
19.15 and 20.2-b1.  I have a feeling that the problem is at the C
level; most likely the line cache is getting messed up.

Visit the attached file in python-mode, turn on font-locking, and
watch how the strings in the two lists at the end of the file are
font-locked correctly.

Now, go to the beginning of the third line in the CDE_REGEXPS list;
this is the one that says '1.0.[1-2]_x86'.  Hit C-o and then C-k.
Watch the line lose it's string fontification on the kill-line.  Every
following line will now be fontified incorrectly.

I can `fix' the problem by putting a comment like

    # '

at the end of the line preceeding the offending line.  Power cycling
font-lock-mode does *not* fix the problem.

-Barry


--S8i/rSB6Ox
Content-Type: text/plain
Content-Disposition: inline;
	filename="foo.py"
Content-Transfer-Encoding: 7bit

#! /usr/bin/env python

"""Download a Solaris patch set.

The set of patches to retrieve is extracted from a *.PatchReport file,
which has a very regular format.  By default, the most current
PatchReport file will be retrieved from Sunsolve, and will be checked
for missing patches.  Any missing patches will be downloaded,
uncompressed, and un-tar'd.

Usage:

    %(program)s [-t N | -f file] [-c] [-q] [-h]

    --type N
    -t N         -- retrieve PatchReport for system type N.  Use --help
                    option to see list of valid system types

    --file file
    -f file      -- Use patch report `file'.  In this case, the patch report
                    file is not downloaded from Sunsolve

    --checkonly
    -c           -- Check only.  Do not download missing files (note that
                    if --file is not used, the patch report file will
                    still be downloaded)

    --quiet
    -q           -- work silently

    --help
    -h           -- print this message

"""

# IMPORTANT!  Since this file is intended for CNRI internal use only,
# I've hard-coded our Sun support information in this file.  If this
# file ever gets exported this information should be removed.

PATCHSITE = 'sunsolve1.sun.com'
PATCHLOGIN = 'sunsolve'
PATCHPASSWD = 'xxxxxxx'
PATCHACCOUNT = 'xxxxxxxxxxxxxxx'

# TBD: make this grok CDE patch set from PatchSummary file!

# system types
SYSTYPES = [
    # index is key, value is leader for *.PatchReport file
    'Solaris2.5',			# Sparc
    'Solaris2.5_x86',
    'Solaris2.5.1',			# Sparc
    'Solaris2.5.1_x86',
    'Solaris2.5.1_ppc',
    ]

CDE_REGEXPS = [
    # parallel list to SYSTYPES
    '1.0.[1-2]',
    '1.0.[1-2]_x86',
    '1.0.[1-2]',
    '1.0.[1-2]_x86',
    '1.0.[1-2]_ppc',
    ]

--S8i/rSB6Ox--

