From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: master 2399541: Remove font-lock toggle from font-lock-update Date: Thu, 25 Mar 2021 18:39:58 -0400 Message-ID: References: <20210324143048.23515.75257@vcs0.savannah.gnu.org> <20210324143050.40C6E20D10@vcs0.savannah.gnu.org> <8786a8e8fa731c1bd1ef@heytings.org> <87h7l0blrc.fsf@gnus.org> <87czvobksy.fsf@gnus.org> <87r1k4a1c0.fsf@gnus.org> <8786a8e8fa96815c66e3@heytings.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2190"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Gregory Heytings Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Mar 25 23:41:37 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lPYfY-0000Tp-SY for ged-emacs-devel@m.gmane-mx.org; Thu, 25 Mar 2021 23:41:36 +0100 Original-Received: from localhost ([::1]:59050 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lPYfX-0006gM-Rg for ged-emacs-devel@m.gmane-mx.org; Thu, 25 Mar 2021 18:41:35 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33420) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lPYeB-00067v-QJ for emacs-devel@gnu.org; Thu, 25 Mar 2021 18:40:11 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:49734) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lPYe8-0003wk-OC for emacs-devel@gnu.org; Thu, 25 Mar 2021 18:40:10 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 2EB8B10022E; Thu, 25 Mar 2021 18:40:07 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 923C41001D2; Thu, 25 Mar 2021 18:39:59 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1616711999; bh=ELBJsbVGbMilHuCtIG/m8avbOwNdbickfKfHSHbDvGs=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=hnYtowgliWG/9W+HQ172eKKlkB4mFeGiqHfIun6HwtC8SGQiu2ebtNohvnCWcbAHm /Uhj504ovZiHLx9deWkF41b/EZXXhD2TXn1fgQkm5WKxJFH1fd9b5j48rgsYYPxq0e PPrEGiUasjan06OmTiegMsXpr4tKi1E58GLWK4XW7EgK0j2gvPcTUErN9eGVTWCGly CcEhbouaG7YvUtTF+5iDPHX7az73p0/mdSLi7FDXRXOvQu0/Jgi02O3cU2Gj/NH1kX Dlhk0+wEsVTKxzIBiZe/nrSMOENRpwehhsIBO7beNvPEjDzDLtzgK5SwpLdg3tNCnO Q8z0nUW8imiJw== Original-Received: from alfajor (unknown [216.154.43.249]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 604C7120191; Thu, 25 Mar 2021 18:39:59 -0400 (EDT) In-Reply-To: (Gregory Heytings's message of "Thu, 25 Mar 2021 20:58:30 +0000") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:267050 Archived-At: >> [ Tho maybe I'd prefer if it used `font-lock-flush` or >> `font-lock-ensure`. ] > > Yes, but alas that doesn't work e.g. when yanking a font-locked string into > a text-mode buffer. And that's part of the problem: as it is the code can't be changed to use those functions because it would behave slightly differently. With a proper definition of what the behavior should be (as opposed to it being just the result of the current implementation), we could write the code so that it can use `font-lock-flush` when that gives the right behavior and something else in other cases). >>>> I'd much prefer a longer `font-lock-fontify-diwm` which tries to >>>> reproduce more or less the same behavior as your favorite, but by >>>> explicitly testing the different circumstances you care about. >>> >>> Could you perhaps give an example of such a circumstance and its >>> corresponding action? >> >> The main "circumstances" that matter are whether the font-lock machinery >> is activated and whether font-lock-mode is nil or not. > Are these two separate conditions? Yes, there are three cases: - font-lock-mode is nil - font-lock-mode is t but the font-lock machinery is not activated (e.g. in text-mode with the default config). - font-lock fully activated. >> ;; - Correct misfontification when fontification is highly context-dependent >> ;; and has a bug (typically associated with multiline constructs). >> ;; `font-lock-flush` should work as well in that case. >> ;; - Removing fontification, e.g. when yanking font-locked strings into >> ;; a text-mode buffer. Not sure if the intention would be to generalize >> ;; this to all buffers with a nil `font-lock-keywords` or also to buffers >> ;; where font-lock-mode is disabled. > > There is another use case I think, which is close to your first use case, > and is perhaps the most common one: the fontification is not what you expect > (say, you're inside a function and the fontification indicates you're inside > a comment), and you are not sure whether it's because the fontification has > not yet been updated, or because you indeed forgot to close a comment. > A refontifcation is useful in that case, too. Yes, tho I think it's the same case as far as Emacs is concerned: The difference is only in what motivated the user to launch the command and how the user uses the result. > Another similar case is when you know that the fontification should change > and do not want to wait for the refontification to take place (say, you > open a comment, and want immediately see the effect). Indeed, and I guess this one is slightly different. > In those case font-lock-flush should work well, too. That's right. >> Maybe the docstring should describe just those behaviors, and the >> implementation could then implement them explicitly, rather than have that >> grow accidentally as a result of the implementation. > Is a KISS approach not better? Could it do something wrong? I don't like a command which is only right because it is defined to do what it happens to do. [ And in the case of `font-lock-fontify-buffer` it also makes it hard/impossible to make it more efficient: in many cases what is needed is just `font-lock-flush`, and in many other cases what is needed is `font-lock-ensure`, both of which can be significantly more efficient than `font-lock-fontify-buffer`. But the function itself can't know which was meant. ] > -(defun font-lock-update (&optional arg) > +(defun font-lock-dwim (&optional arg) > "Updates the syntax highlighting in this buffer. BTW, This should say "Update" without a final "s". > +Enable Font Lock mode if it is disabled. Is this behavior useful? > +Otherwise, refontify the region > +if it is active, or a large part of the accessible portion of the buffer. I don't see any mention of what should happen in a case like `text-mode`. > +Otherwise, with prefix ARG, toggle Font Lock mode." Is this behavior useful? > (interactive "P") > (save-excursion > (if (and (not arg) font-lock-mode) > - (font-lock-fontify-region (point-min) (point-max)) > + (if (use-region-p) > + (font-lock-fontify-region (region-beginning) (region-end)) When font-lock is active and the region is about the refreshed (e.g. a comment was just opened or something), this will result in double font-locking (first it will happen now in response to this command, and then it will happen again because this command did not tell jit-lock that it just refreshed the area, so the planned refresh will take place anyway). And to make things worse, the second refresh may re-introduce problems which were fixed by the first. > + (font-lock-flush (point-min) (point-max)) > + (font-lock-fontify-region (max (point-min) (min (- (point) 50000) (window-start))) > + (min (point-max) (max (+ (point) 50000) (window-end))))) Why use `font-lock-flush` and `font-lock-fontify-region`? > (font-lock-unfontify-region (point-min) (point-max)) > (font-lock-mode 'toggle)))) If font-lock-mode was already activated, then (font-lock-mode 'toggle) will call `font-lock-unfontify-region`, and if it's not then there's nothing to unfontify, I think. Or am I missing something? Stefan