From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gregory Heytings Newsgroups: gmane.emacs.devel Subject: Re: master 2399541: Remove font-lock toggle from font-lock-update Date: Thu, 25 Mar 2021 20:58:30 +0000 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: multipart/mixed; BOUNDARY="-212064758-1552094458-1616703468=:569" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21862"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Mar 25 21:59:21 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 1lPX4a-0005aZ-BP for ged-emacs-devel@m.gmane-mx.org; Thu, 25 Mar 2021 21:59:20 +0100 Original-Received: from localhost ([::1]:46270 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lPX4Z-0005SZ-Cz for ged-emacs-devel@m.gmane-mx.org; Thu, 25 Mar 2021 16:59:19 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36872) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lPX3r-0004nQ-9A for emacs-devel@gnu.org; Thu, 25 Mar 2021 16:58:35 -0400 Original-Received: from heytings.org ([95.142.160.155]:45278) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lPX3p-0006ZQ-13 for emacs-devel@gnu.org; Thu, 25 Mar 2021 16:58:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20210101; t=1616705910; bh=6U1Se9I72ZuJJZjqyoEl1Ld2Dum31omNWbKutGU3xdc=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=HuLm+PFiyPMiNKzPuMFUpwHYR/j7qj3AIM04huvLZ9zBlqS6YdInmNvrvW78mWKWK w/exxrVN/X6eoCUXJgRX/W97x8O325rJpae9kYzmDGU95ReIDrByhHXjLLv595oNam RXgWyY2bksRN++ky+7rQ8cB7pF/5tMCuCWEomNgULMtntcGovamAre2sdxg4dGEO6o Jz3U3ITlWz96uXVovZyilGxRz4al/YY1h28h3NbgSmFjD96Z/jrPADbmUK4yb6SBRu ZDW5PgTPuZQoPVlp2Qy6uk3E0njXe0fL86IjtEJ1lxJgAhsduuOCku4scqx3VUJsUN CwhbwvO6qb20Q== In-Reply-To: Content-ID: Received-SPF: pass client-ip=95.142.160.155; envelope-from=gregory@heytings.org; helo=heytings.org X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-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:267048 Archived-At: ---212064758-1552094458-1616703468=:569 Content-Type: text/plain; CHARSET=US-ASCII; format=flowed Content-ID: > > That's the wrong question, since my beef is about the definition of what > the function should do, as opposed to how it's implemented. > I think the simplest way to express what the function should do is: if something is wrong with the fontification, fix it. (And with a prefix argument, toggle fontification.) That's basically what Eli used font-lock-fontify-block for, for instance. Someone else said something like "I did not know that font-lock-fontify-block exists, when the fontification is wrong, I just turn font-lock-mode off and on". > > [ 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. >>> 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? Or does font-lock-mode t imply that the font-lock machinery is activated? (Apart from the case where someone would do (progn (font-lock-mode -1) (setq font-lock-mode t)) of course.) > > Currently, I've heard mention of two use cases for > font-lock-fontify-block: > > ;; - 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. 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). In those case font-lock-flush should work well, too. > > 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? What would be the benefit of identifying use cases one by one and adding them to a (presumably much more complex) function? I attach an updated patch; it occurred to me that with outline-mode and friends, "far away from point" might not be enough to cover the window. ---212064758-1552094458-1616703468=:569 Content-Type: text/x-diff; NAME=0001-Improve-font-lock-update-and-rename-it-to-font-lock-.patch; CHARSET=us-ascii Content-Transfer-Encoding: base64 Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME=0001-Improve-font-lock-update-and-rename-it-to-font-lock-.patch RnJvbSBjNzdlNmU2N2RhMzFiOTE4ZDkyYWFjY2UxYzg2YWM4MTljZmQ1ZmNj IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQ0KRnJvbTogR3JlZ29yeSBIZXl0 aW5ncyA8Z3JlZ29yeUBoZXl0aW5ncy5vcmc+DQpEYXRlOiBUaHUsIDI1IE1h ciAyMDIxIDIwOjA4OjUzICswMDAwDQpTdWJqZWN0OiBbUEFUQ0hdIEltcHJv dmUgZm9udC1sb2NrLXVwZGF0ZSBhbmQgcmVuYW1lIGl0IHRvIGZvbnQtbG9j ay1kd2ltDQoNCiogbGlzcC9mb250LWxvY2suZWwgKGZvbnQtbG9jay1kd2lt KTogUmVuYW1lZCBmcm9tICdmb250LWxvY2stdXBkYXRlJy4NCk9ubHkgcmVm b250aWZ5IHRoZSByZWdpb24gd2hlbiBpdCBpcyBhY3RpdmUuICBEbyBub3Qg cmVmb250aWZ5IHRvbw0KbGFyZ2UgYnVmZmVycyBhdCBvbmNlLg0KDQoqIGxp c3AvYmluZGluZ3MuZWwgKGN0bC14LXgtbWFwKTogQWRqdXN0IHRoZSBjb21t YW5kIG5hbWUuDQoNCiogZXRjL05FV1M6IEFkanVzdCB0aGUgY29tbWFuZCBu YW1lLg0KLS0tDQogZXRjL05FV1MgICAgICAgICAgfCAgNCArKy0tDQogbGlz cC9iaW5kaW5ncy5lbCAgfCAgMiArLQ0KIGxpc3AvZm9udC1sb2NrLmVsIHwg MTQgKysrKysrKysrLS0tLS0NCiAzIGZpbGVzIGNoYW5nZWQsIDEyIGluc2Vy dGlvbnMoKyksIDggZGVsZXRpb25zKC0pDQoNCmRpZmYgLS1naXQgYS9ldGMv TkVXUyBiL2V0Yy9ORVdTDQppbmRleCA2ODgxMmM2NGNjLi41OGNjNGEyYjgy IDEwMDY0NA0KLS0tIGEvZXRjL05FV1MNCisrKyBiL2V0Yy9ORVdTDQpAQCAt OTQsNyArOTQsNyBAQCB1c2VmdWwgb24gc3lzdGVtcyBzdWNoIGFzIEZyZWVC U0Qgd2hpY2ggc2hpcHMgb25seSB3aXRoICJldGMvdGVybWNhcCIuDQogKiBD aGFuZ2VzIGluIEVtYWNzIDI4LjENCiANCiArKysNCi0qKiBOZXcgY29tbWFu ZCAnZm9udC1sb2NrLXVwZGF0ZScsIGJvdW5kIHRvICdDLXggeCBmJy4NCisq KiBOZXcgY29tbWFuZCAnZm9udC1sb2NrLWR3aW0nLCBib3VuZCB0byAnQy14 IHggZicuDQogVGhpcyBjb21tYW5kIHVwZGF0ZXMgdGhlIHN5bnRheCBoaWdo bGlnaHRpbmcgaW4gdGhpcyBidWZmZXIuDQogDQogKiogVGhlIG5ldyBOb25H TlUgRUxQQSBhcmNoaXZlIGlzIGVuYWJsZWQgYnkgZGVmYXVsdCBhbG9uZ3Np ZGUgR05VIEVMUEEuDQpAQCAtMjU1LDcgKzI1NSw3IEBAIFRoZSAnQy14IHgn IGtleW1hcCBub3cgaG9sZHMga2V5c3Ryb2tlcyBmb3IgdmFyaW91cyBidWZm ZXItb3JpZW50ZWQNCiBjb21tYW5kcy4gIFRoZSBuZXcga2V5c3Ryb2tlcyBh cmUgJ0MteCB4IGcnICgncmV2ZXJ0LWJ1ZmZlcicpLA0KICdDLXggeCByJyAo J3JlbmFtZS1idWZmZXInKSwgJ0MteCB4IHUnICgncmVuYW1lLXVuaXF1ZWx5 JyksICdDLXggeCBuJw0KICgnY2xvbmUtYnVmZmVyJyksICdDLXggeCBpJyAo J2luc2VydC1idWZmZXInKSwgJ0MteCB4IHQnDQotKCd0b2dnbGUtdHJ1bmNh dGUtbGluZXMnKSBhbmQgJ0MteCB4IGYnICgnZm9udC1sb2NrLXVwZGF0ZScp Lg0KKygndG9nZ2xlLXRydW5jYXRlLWxpbmVzJykgYW5kICdDLXggeCBmJyAo J2ZvbnQtbG9jay1kd2ltJykuDQogDQogLS0tDQogKiogQ29tbWFuZHMgJ3Nl dC1mcmFtZS13aWR0aCcgYW5kICdzZXQtZnJhbWUtaGVpZ2h0JyBjYW4gbm93 IGdldCB0aGVpcg0KZGlmZiAtLWdpdCBhL2xpc3AvYmluZGluZ3MuZWwgYi9s aXNwL2JpbmRpbmdzLmVsDQppbmRleCA2ZWFjNTI4ZWI2Li42ZjI1ZTk3Mzhh IDEwMDY0NA0KLS0tIGEvbGlzcC9iaW5kaW5ncy5lbA0KKysrIGIvbGlzcC9i aW5kaW5ncy5lbA0KQEAgLTE0MzIsNyArMTQzMiw3IEBAIGN0bC14LW1hcA0K IA0KIChkZWZ2YXIgY3RsLXgteC1tYXANCiAgIChsZXQgKChtYXAgKG1ha2Ut c3BhcnNlLWtleW1hcCkpKQ0KLSAgICAoZGVmaW5lLWtleSBtYXAgImYiICMn Zm9udC1sb2NrLXVwZGF0ZSkNCisgICAgKGRlZmluZS1rZXkgbWFwICJmIiAj J2ZvbnQtbG9jay1kd2ltKQ0KICAgICAoZGVmaW5lLWtleSBtYXAgImciICMn cmV2ZXJ0LWJ1ZmZlcikNCiAgICAgKGRlZmluZS1rZXkgbWFwICJyIiAjJ3Jl bmFtZS1idWZmZXIpDQogICAgIChkZWZpbmUta2V5IG1hcCAidSIgIydyZW5h bWUtdW5pcXVlbHkpDQpkaWZmIC0tZ2l0IGEvbGlzcC9mb250LWxvY2suZWwg Yi9saXNwL2ZvbnQtbG9jay5lbA0KaW5kZXggODI5MTVkOGM4Yi4uMTgwMGYw YjU2ZCAxMDA2NDQNCi0tLSBhL2xpc3AvZm9udC1sb2NrLmVsDQorKysgYi9s aXNwL2ZvbnQtbG9jay5lbA0KQEAgLTExMjAsMTUgKzExMjAsMTkgQEAgZm9u dC1sb2NrLWVuc3VyZQ0KICAgICAoZnVuY2FsbCBmb250LWxvY2stZW5zdXJl LWZ1bmN0aW9uDQogICAgICAgICAgICAgIChvciBiZWcgKHBvaW50LW1pbikp IChvciBlbmQgKHBvaW50LW1heCkpKSkpDQogDQotKGRlZnVuIGZvbnQtbG9j ay11cGRhdGUgKCZvcHRpb25hbCBhcmcpDQorKGRlZnVuIGZvbnQtbG9jay1k d2ltICgmb3B0aW9uYWwgYXJnKQ0KICAgIlVwZGF0ZXMgdGhlIHN5bnRheCBo aWdobGlnaHRpbmcgaW4gdGhpcyBidWZmZXIuDQotUmVmb250aWZ5IHRoZSBh Y2Nlc3NpYmxlIHBvcnRpb24gb2YgdGhpcyBidWZmZXIsIG9yIGVuYWJsZSBG b250IExvY2sgbW9kZQ0KLWluIHRoaXMgYnVmZmVyIGlmIGl0IGlzIGN1cnJl bnRseSBkaXNhYmxlZC4gIFdpdGggcHJlZml4IEFSRywgdG9nZ2xlIEZvbnQN Ci1Mb2NrIG1vZGUuIg0KK0VuYWJsZSBGb250IExvY2sgbW9kZSBpZiBpdCBp cyBkaXNhYmxlZC4gIE90aGVyd2lzZSwgcmVmb250aWZ5IHRoZSByZWdpb24N CitpZiBpdCBpcyBhY3RpdmUsIG9yIGEgbGFyZ2UgcGFydCBvZiB0aGUgYWNj ZXNzaWJsZSBwb3J0aW9uIG9mIHRoZSBidWZmZXIuDQorT3RoZXJ3aXNlLCB3 aXRoIHByZWZpeCBBUkcsIHRvZ2dsZSBGb250IExvY2sgbW9kZS4iDQogICAo aW50ZXJhY3RpdmUgIlAiKQ0KICAgKHNhdmUtZXhjdXJzaW9uDQogICAgIChp ZiAoYW5kIChub3QgYXJnKSBmb250LWxvY2stbW9kZSkNCi0gICAgICAgIChm b250LWxvY2stZm9udGlmeS1yZWdpb24gKHBvaW50LW1pbikgKHBvaW50LW1h eCkpDQorICAgICAgICAoaWYgKHVzZS1yZWdpb24tcCkNCisgICAgICAgICAg ICAoZm9udC1sb2NrLWZvbnRpZnktcmVnaW9uIChyZWdpb24tYmVnaW5uaW5n KSAocmVnaW9uLWVuZCkpDQorICAgICAgICAgIChmb250LWxvY2stZmx1c2gg KHBvaW50LW1pbikgKHBvaW50LW1heCkpDQorICAgICAgICAgIChmb250LWxv Y2stZm9udGlmeS1yZWdpb24gKG1heCAocG9pbnQtbWluKSAobWluICgtIChw b2ludCkgNTAwMDApICh3aW5kb3ctc3RhcnQpKSkNCisgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAobWluIChwb2ludC1tYXgpIChtYXgg KCsgKHBvaW50KSA1MDAwMCkgKHdpbmRvdy1lbmQpKSkpKQ0KICAgICAgIChm b250LWxvY2stdW5mb250aWZ5LXJlZ2lvbiAocG9pbnQtbWluKSAocG9pbnQt bWF4KSkNCiAgICAgICAoZm9udC1sb2NrLW1vZGUgJ3RvZ2dsZSkpKSkNCiAN Ci0tIA0KMi4zMC4yDQoNCg== ---212064758-1552094458-1616703468=:569--