From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: master 7362554: Widen around c-font-lock-fontify-region. This fixes bug #38049. Date: Wed, 13 Nov 2019 21:19:36 +0000 Message-ID: <20191113211936.GB4942@ACM> References: <20191109144026.20810.76129@vcs0.savannah.gnu.org> <20191109144027.DDC3720927@vcs0.savannah.gnu.org> <38328d99-23c8-7ba7-a23d-e70ac0aab67a@yandex.ru> <20191111203445.GA5135@ACM> <7497e71d-bab6-fa04-bbc4-f52fadeda16d@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="119162"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) Cc: emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 13 22:20:32 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iV040-000UsK-5W for ged-emacs-devel@m.gmane.org; Wed, 13 Nov 2019 22:20:32 +0100 Original-Received: from localhost ([::1]:51162 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iV03z-00086D-1d for ged-emacs-devel@m.gmane.org; Wed, 13 Nov 2019 16:20:31 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54314) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iV03F-000864-IZ for emacs-devel@gnu.org; Wed, 13 Nov 2019 16:19:47 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iV03E-0007P2-0p for emacs-devel@gnu.org; Wed, 13 Nov 2019 16:19:45 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:21864 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1iV03C-0007LL-5L for emacs-devel@gnu.org; Wed, 13 Nov 2019 16:19:43 -0500 Original-Received: (qmail 60781 invoked by uid 3782); 13 Nov 2019 21:19:39 -0000 Original-Received: from acm.muc.de (p4FE1584D.dip0.t-ipconnect.de [79.225.88.77]) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 13 Nov 2019 22:19:36 +0100 Original-Received: (qmail 20318 invoked by uid 1000); 13 Nov 2019 21:19:36 -0000 Content-Disposition: inline In-Reply-To: <7497e71d-bab6-fa04-bbc4-f52fadeda16d@yandex.ru> X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-Received-From: 193.149.48.1 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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" Xref: news.gmane.org gmane.emacs.devel:242128 Archived-At: Hello Dmitry. On Tue, Nov 12, 2019 at 15:36:08 +0200, Dmitry Gutov wrote: > Hi Alan, > On 11.11.2019 22:34, Alan Mackenzie wrote: > > On Mon, Nov 11, 2019 at 18:52:34 +0200, Dmitry Gutov wrote: > >> On 09.11.2019 16:40, Alan Mackenzie wrote: > >>> + (widen) > >> Could you try and honor font-lock-dont-widen here? > > Difficult. In CC Mode it is sometimes necessary to enlarge a font > > lock region so as to get the context needed to parse some element of > > the buffer. This was what gave rise to the bug. > Did that really happen in the reported scenario? I mean, > font-lock-dont-widen is usually nil, so font-lock will call widen for > you already. Cutting and pasting from the bug thread for bug #38049: [ Juri Linkov ]: > This is a reproducible test case: > 0. emacs -Q > 1. C-x C-f emacs/lib-src/emacsclient.c > 2. M-: (progn (search-forward "create-frame" nil t) > (reposition-window)) > Then half screen displays unfontified lines. > Fontification doesn't fail in other modes, only in C mode. > This has something to do with interaction between c-font-lock > and buffer navigation in reposition-window. [ Alan Mackenzie ]: Indeed it does. Briefly, (i) reposition-window narrows to (2758 3940) in repos-count-screen-lines. (ii) This latter function uses vertical-motion to count the lines. (iii) vertical-motion triggers jit-lock fontification. (iv) This calls (eventually) c-font-lock-fontify-region. (v) c-font-lock-fontify-region attempts to examine buffer text before the start of the jit-lock chunk to find syntactic context. (vi) This is outside the visible region, so Emacs raises an exception. (vii) The exception is caught and discarded by an unwind-protect in c-font-lock-fontify-region. (viii) The jit-lock chunk remains unfontified. > > In all of Emacs, there's just one use of font-lock-dont-widen, in > > rmail.el, and that is almost certainly for a different reason than > > your use of it (which is, I believe, having several major modes in a > > single buffer). > Does RMail use it for quoted pirces of code? If so, it would be > similar. I don't know RMail at all. I imagine font-lock-dont-widen is used with the region as the text of a mail message, excluding things like the headers. But I don't know. > > Could you, perhaps, suggest some alternative to using widen in > > c-font-lock-fontify-region? Some way which would still work for CC > > Mode (including the just fixed bug), but wouldn't adversely affect > > the several major mode code you're maintaining? Would it be > > possible to widen "a bit" rather than widening to the whole buffer? > > If so, how would I determine the bit to widen to? > Not sure what difference the supposed "bit" would make (and thus, how > would mmm-mode determine it). I was thinking about, perhaps, widening no wider than the CC Mode portion of the several major mode buffer. > But I think that would depend on your answer to my first question in > this email. Because, I think, normally you don't "have to" widen at > all, font-lock will do that for you. I think it does, normally, but it didn't when the font locking was invoked for vertical-motion. (Font locking is needed to determine the faces used, which might have different vertical sizes.) > In mmm-mode context, however, we apply definite boundaries to the > region chunks. Here's an example of some Noweb code: > https://en.wikipedia.org/wiki/Noweb#Example_of_a_simple_noweb_program > The inside of hello.c block would be narrowed to. I think I've said this before, but I don't think narrowing is the right tool for that task. I don't think there is a suitable tool in Emacs at the moment. > Now, I have remembered that CC Mode calls widen from many places > already, so it already is problematic for using in a context like that. It does, yes. Users also use widening and narrowing. > Thus this particular change doesn't change the picture much, and so > please feel free to drop this conversation at any point of time. OK. -- Alan Mackenzie (Nuremberg, Germany).