From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] emacs-24 d69e9f1: CC Mode: Stop Font Lock forcing fontification from BOL. Fixes debbugs#19669. Date: Fri, 20 Mar 2015 14:25:09 -0700 Message-ID: <550C9035.7020204@dancol.org> References: <55076CF8.60309@dancol.org> <20150318120806.GA4160@acm.fritz.box> <550A43BB.3070904@dancol.org> <20150319093110.GA2753@acm.fritz.box> <20150319203724.GB2753@acm.fritz.box> <20150320163027.GB3493@acm.fritz.box> <550C4C2C.9060807@dancol.org> <20150320172918.GC3493@acm.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="kPAkjx8V4op6IfFTwC899NSQ4ddoO8nN5" X-Trace: ger.gmane.org 1426886735 19016 80.91.229.3 (20 Mar 2015 21:25:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 20 Mar 2015 21:25:35 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 20 22:25:34 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YZ4Q5-0007Ep-LN for ged-emacs-devel@m.gmane.org; Fri, 20 Mar 2015 22:25:30 +0100 Original-Received: from localhost ([::1]:45801 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZ4Q4-0008KF-QH for ged-emacs-devel@m.gmane.org; Fri, 20 Mar 2015 17:25:28 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44939) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZ4Pz-0008Jy-PZ for emacs-devel@gnu.org; Fri, 20 Mar 2015 17:25:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YZ4Pu-0000WV-3B for emacs-devel@gnu.org; Fri, 20 Mar 2015 17:25:23 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:55842) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZ4Pt-0000VA-L1 for emacs-devel@gnu.org; Fri, 20 Mar 2015 17:25:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=Ae7css/e0sDsyjBDQVfAnXThuehG4kG4XMeNEVfdjmE=; b=nLIY6ac1y3jnjYhyCoUehWRjZ1zsG1WYyMuZ/xHQa6910i7TspwJDMBdAzdsdBuB+XE60BVw6WlnxmvGw9y1RtoUGivAlMTQs7y58AxdVkOg6Mos4mXRCV6YO4N2opRlrY9WeFXhcxeIPhi1rAarh8RbWB7CTxEPNy9b3nHPyBMCaIPAG7zIak+O58PCVS0RgTA4Ph9nqizb0xTLltD9TJrS8jbknKU8eaWd1+Pq2nOjitfFkrPWDsKf3/ADxjkBf5eOUfy/q3SWnLp4xg7A1dAGcT1NfqMTZUvhw/PXpvU0V43/+tPPsD8HN7gBkNfI4tz+sjTQVvttq+dMGCCpbQ==; Original-Received: from [2620:10d:c083:1004:56ee:75ff:fe20:83dc] by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1YZ4Ps-0006dO-4N; Fri, 20 Mar 2015 14:25:16 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 In-Reply-To: <20150320172918.GC3493@acm.fritz.box> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:184059 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kPAkjx8V4op6IfFTwC899NSQ4ddoO8nN5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 03/20/2015 10:29 AM, Alan Mackenzie wrote: > On Fri, Mar 20, 2015 at 09:34:52AM -0700, Daniel Colascione wrote: >> On 03/20/2015 09:30 AM, Alan Mackenzie wrote: >>> On Thu, Mar 19, 2015 at 04:56:16PM -0400, Stefan Monnier wrote: >>>>>> you can handle fontification from 1,3, or 4 but not from 2. You n= eed 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= ". >=20 >>>>> Well, sort of. The problem I'm facing is that in Dima Kogan's bug >>>>> #19669, the following construct appears: >=20 >>>>> 1. enum xxx_xxxx_xxxxxxxxxx_x >>>>> 2. {XXX_XXXXXX_XXXX_XXX, >>>>> 3. XXX_XXXXXX_XXX_XXX, >>>>> 4. XXXX_XXXXX_XXXX_XXX, >=20 >>>>> Note that the brace on L2 is on the same line as the first XXX_....= >=20 >>>>> When the user types on line 4, 5, ... here, CC Mode sets the >>>>> fontification region start to JUST AFTER THE { ON L2. It is essent= ial >>>>> that Font Lock doesn't change this. >=20 >>>> There's your problem: your current setup needs the starting point to= be >>>> either before "union" or after the first open brace. >>>> It breaks down if it's between the two. That's the problem you need= to fix. >=20 >>> Not really. CC Mode is quite capable of handling the Font Lock regio= n >>> starting at BOL2. The problem is, when that starting point needs to = be >>> after the brace on L2, Font Lock moves the starting point somewhere >>> else, fouling up the font locking. This is proving surprisingly toug= h >>> to fix. >=20 >> I don't understand. Why shouldn't I be able to tell cc-mode to fontify= >> *arbitrary* regions and expect it to correctly apply highlighting to >> these regions? >=20 > You can, as a CC Mode user. In its turn CC Mode needs to be able to > select the region in which it does its analysis, so that that analysis > starts at a neutral syntactic position. By itself, this statement makes sense, but isn't the right "neutral syntactic position" for a given fontification region purely a function of the region bounds and buffer state? cc-mode should be able to find the right position for any pair of buffer positions. If the right start position is before the region to be fontified, cc-mode can expand the region to encompass it. >> It's the idea that the region "needs to be after brace" that I find >> confusing. Shouldn't jit-lock have the right to expand the region >> arbitrarily? >=20 > Absolutely not. CC Mode needs to do syntactic analysis inside this > region, so the region needs to start at the (syntactically) right place= =2E Isn't it cc-mode's job to find a good position within or before the region font-lock gives it to fontify? cc-mode can nominate a good region using the extend-region functions, but as I see it, there's no contractual requirement that font-lock not arbitrarily enlarge this regio= n. > To do this analysis CC Mode must first find the beginning of any > definition the current position is in, otherwise context fontification > can go wrong. An example of this going wrong is in this snippet: >=20 > 1. template > 2. > 3. > 4. void myfunc(T* p) {} >=20 > If a space is inserted on L3, this will trigger context fontification o= f > L4. L4 is fontified differently in the presence of the template > declaration (for reasons you, a C++ hacker, probably understand better > than me). What the bug reporter saw was L4's fontification going wrong= a > half second after typing the space, something as irritating as what is > happening to your "for". The solution I implemented for the problem wa= s > to extend the font lock region to include L1. Extending the region to L1 is the right behavior. Why can't we perform this extension when asked to fontify any range in L1-L4? > That same region extension which includes that template line, in the en= um > example goes back to after the "{" on L2. Bug #19669 went wrong in > c-font-lock-enum-tail, the function which handles a the start of a > fontification region being within an enum brace block. > c-font-lock-enum-tail will only trigger when the starting point is with= in > that brace block. When Font Lock moves the starting point somewhere el= se > (in particular, BOL), that condition no longer holds, and the font lock= ing > fails. Why can't we check whether any character inside the region to fontify is an enum brace end? --kPAkjx8V4op6IfFTwC899NSQ4ddoO8nN5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJVDJA2AAoJEN4WImmbpWBlw1kP/2kLKtZ6CT9H6Yw9L8u3DyDh 6hQWa8PTWgzEmFMVASp/mBygtT5f0k4WR0DmI8KzejJhbEkB/BAOEJQNglaYkPWS M0+yWU94rN02IBN44UBSrBIUbKhmvBhRsiQQGaNa5ja/W5k5UU3Lu+WXWEC3yPwT 54TglI+zNUIwIQ2VfsZk7O+s7XGRzQVbKU+xyKfkhszMKUMUWo8MNdnKi7MFNKRj K/GUhsaKdSUemtxsCBf5P1NGzE0XzLKNSQZR5lUtofoW+Pt282F3naFS2/XHzADt sjaEMRPn9jgfHTFWnURTFIle47X3Qzyl65x7WTlbJAM8VnKtzKMO5vPtywOyRYQ3 WNvIfVfzUUvc73kpd4Fb8o4fpyAaphSLZooSn3242Bps7+5BMNpjByjqP5owz5oA 50yGbq9FAQZo/ENGBOWFQOQXtG3WK0chdn2Tt0Qz7qGtf2WV0IZVvq5mC3vgHYGE lLwlgCst3B7h4JXrii6o3AXj9udy/smlY8TBkJPo3q3iqbF0I0CeXpJ8YcEApGwi V/YlIwyiT276Tr0GsLuO/fKWpcZlT6VzGjHPIkyAeryXi2IT2CJyfZfzIAsGPA8g K3CPvIR39CKC25rMuKbJexVhBsjpOLOeoiSLbkIRnofOccHAgUIH3l7IlHj5egTf Na3H93Z6ZKm5Yru8uwZ1 =2Vw7 -----END PGP SIGNATURE----- --kPAkjx8V4op6IfFTwC899NSQ4ddoO8nN5--