all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: Stefan Monnier <monnier@IRO.UMontreal.CA>
Cc: Daniel Colascione <dancol@dancol.org>, emacs-devel@gnu.org
Subject: Re: [Emacs-diffs] emacs-24 d69e9f1: CC Mode: Stop Font Lock forcing fontification from BOL. Fixes debbugs#19669.
Date: Thu, 19 Mar 2015 20:37:25 +0000	[thread overview]
Message-ID: <20150319203724.GB2753@acm.fritz.box> (raw)
In-Reply-To: <jwvlhit6qz3.fsf-monnier+emacs@gnu.org>

Hello, Stefan.

On Thu, Mar 19, 2015 at 09:49:13AM -0400, Stefan Monnier wrote:
> > The problem in #19669 was that Font Lock's extension of the region to be
> > font locked to the beginning of the line was changing the syntactic
> > context, hence CC Mode's font locking didn't work in that case.  The
> > solution was to prevent that extension in the pertinent case.  However, I
> > got it wrong.

> The way I see it, the core of the problem is that the way you handle
> partial re-fontification of a multi-line `union' construct has
> a dead spot.

> More specifically, if you have code like

> 1    union
> 2      {
> 3        foo,
> 4        bar
> 5      }

> you can handle fontification from 1,3, or 4 but not from 2.  You need to
> refine the system you use to keep track of whether we're within
> a `union' so that it knows that position 2 is also "within a union".

Well, sort of.  The problem I'm facing is that in Dima Kogan's bug
#19669, the following construct appears:

1. enum xxx_xxxx_xxxxxxxxxx_x
2.     {XXX_XXXXXX_XXXX_XXX,
3.      XXX_XXXXXX_XXX_XXX,
4.      XXXX_XXXXX_XXXX_XXX,

Note that the brace on L2 is on the same line as the first XXX_....

When the user types on line 4, 5, ... here, CC Mode sets the
fontification region start to JUST AFTER THE { ON L2.  It is essential
that Font Lock doesn't change this.

When Daniel types the "r" of his "for", it is equally essential that
Font Lock (or something) does adjust the fontification region start to
BOL.  This is the more normal case.

How do we reconcile these?  The pertinent adjustment is done by having,
or not having, `font-lock-extend-region-wholelines' on
`font-lock-extend-region-functions'.  So, I have a solution which, in
the "enum case" sets a flag which instructs c-font-lock-fontify-region
later to bind `f-l-extend-r-f' to nil.  Should work.

Unfortunately, there is a dirty hack in
`font-lock-extend-jit-lock-region-after-change' which illegitimately
(i.e. at a time when it is forbidden, according to the contract on the
variable) tests `font-lock-extend-region-functions' for
'f-l-extend-region-wholelines' and then fouls up the beginning of the
"enum region" to BOL 2 before CC Mode's code has had a chance to bind
`f-l-extend-region-functions' to nil.

The purpose of this hack, made in 2006, is to prevent double redisplay,
according to the comments in font-lock.el.  I can't see how it works,
right at the moment, but couldn't we somehow remove this dirty hack?

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).



  reply	other threads:[~2015-03-19 20:37 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20150201212213.17840.3710@vcs.savannah.gnu.org>
     [not found] ` <E1YI1y9-0004eO-Re@vcs.savannah.gnu.org>
2015-02-02 18:50   ` [Emacs-diffs] emacs-24 d69e9f1: CC Mode: Stop Font Lock forcing fontification from BOL. Fixes debbugs#19669 Stefan Monnier
2015-02-02 19:27     ` Alan Mackenzie
2015-02-03  2:12       ` Stefan Monnier
2015-02-02 18:54   ` Stefan Monnier
2015-02-02 21:39     ` Alan Mackenzie
2015-02-03  2:26       ` Stefan Monnier
2015-02-07 12:27         ` Alan Mackenzie
2015-02-07 15:29           ` Stefan Monnier
2015-02-07 15:40             ` Alan Mackenzie
2015-03-16 23:53   ` Daniel Colascione
2015-03-18 12:08     ` Alan Mackenzie
2015-03-19  3:34       ` Daniel Colascione
2015-03-19  9:31         ` Alan Mackenzie
2015-03-19 13:49           ` Stefan Monnier
2015-03-19 20:37             ` Alan Mackenzie [this message]
2015-03-19 20:56               ` Stefan Monnier
2015-03-20 16:30                 ` Alan Mackenzie
2015-03-20 16:34                   ` Daniel Colascione
2015-03-20 17:29                     ` Alan Mackenzie
2015-03-20 21:25                       ` Daniel Colascione
2015-03-20 22:30                         ` Alan Mackenzie
2015-03-20 18:05                   ` Stefan Monnier
2015-03-20 21:12                     ` Alan Mackenzie
2015-03-20 22:01                       ` Stefan Monnier
2015-03-30 16:44     ` Alan Mackenzie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150319203724.GB2753@acm.fritz.box \
    --to=acm@muc.de \
    --cc=dancol@dancol.org \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@IRO.UMontreal.CA \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.