From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "Paul W. Rankin" via "Emacs development discussions." <emacs-devel@gnu.org> Newsgroups: gmane.emacs.devel Subject: Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021 Date: Wed, 24 Mar 2021 19:09:33 +1000 Message-ID: <A4AC0A08-5570-4C2B-8171-AE059C68B68E@bydasein.com> References: <32A55BBD-1A3F-4EC4-817F-7C3408C22A65@bydasein.com> <22aaf0faddac64397c7d@heytings.org> <4B2A00EB-8C04-4B9D-BA86-692D67207AFD@bydasein.com> <22aaf0faddc2bf87fd3a@heytings.org> <0009872A-AD9D-4B08-B714-BFEDDAAF9125@bydasein.com> <8786a8e8faf45a989904@heytings.org> Reply-To: "Paul W. Rankin" <pwr@bydasein.com> Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\)) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11034"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Gregory Heytings <gregory@heytings.org>, Stefan Monnier <monnier@iro.umontreal.ca> Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Mar 24 10:11:29 2021 Return-path: <emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org> 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 <emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org>) id 1lOzY0-0002l0-V8 for ged-emacs-devel@m.gmane-mx.org; Wed, 24 Mar 2021 10:11:28 +0100 Original-Received: from localhost ([::1]:39886 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from <emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org>) id 1lOzXz-0004cs-VQ for ged-emacs-devel@m.gmane-mx.org; Wed, 24 Mar 2021 05:11:27 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44586) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <pwr@bydasein.com>) id 1lOzWw-00045m-3v for emacs-devel@gnu.org; Wed, 24 Mar 2021 05:10:22 -0400 Original-Received: from sendmail.purelymail.com ([34.202.193.197]:39260) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <pwr@bydasein.com>) id 1lOzWt-0003tN-UI for emacs-devel@gnu.org; Wed, 24 Mar 2021 05:10:21 -0400 DKIM-Signature: a=rsa-sha256; b=ACYMt+9zoZJZxYns/C4Os/0FBlbrLsaNK6/9D25U10RmGQQf3qnYjPy8X41Ki+vUfRn8qOfDorHQKqyptSVPMm6ikFlctduKXRmOx8yxoiLvJgbcEC5BUz152xtWJlkGLW1tRofw3m3ZmdtmUEKYQp6hxxWZAvJN2i0PIPaZxSXF8YB9lUh3/d8QZTHUl0IAX/c7zQQEm9LoWdlYFeVtN+P9hjxd2THe334I7SLc6Nt09jqHXv3nUHi9Tf+J7b0BPnl6y53JahguH4xIyP2mU7ZjWhv49bpfa9IlgPFQrRXUIYVxsR0xasJFPjEJtb1Bs271pT86c7Th3WRRZk9Pgg==; s=purelymail2; d=bydasein.com; v=1; bh=yaFsNjWfPNJKJN8HV40mFsvvYyDks6z6x1eK2zcK0mo=; h=Received:From:To; DKIM-Signature: a=rsa-sha256; b=VcPeY+woM9Ol/15PJBA17ZdVP/hAa+lDtiYul/CUNHgKAfZQydqgaFkfhcOTF4ieHS66A++x7t+J95/HlNieDBIZ6sbI0z3CBNzTv+MG6Cm1z1n1IURWw/s2/3DxBYhyvLH4eAdL+CdJFP7G85opF/Mkp0CDldY0ByfZnFSWlao4Db9DBf/iRN+GpsLzwIe6hg3D8ZbHpOfWsouz5rIRdgxsVigWNfa6zNYVwn4ygh6y7LfPqTJQg/yPy4JIAs9+BQjVXDB0S4eJtQTysvB5SqJ/KgxGN3veNhLvTFHPQ7+VGTUJDY94a0CvM8eIbmF3Ds3NyV/gFPaCxO5VZIF89g==; s=purelymail2; d=purelymail.com; v=1; bh=yaFsNjWfPNJKJN8HV40mFsvvYyDks6z6x1eK2zcK0mo=; h=Feedback-ID:Received:From:To; Feedback-ID: 791:353:null:purelymail X-Pm-Original-To: emacs-devel@gnu.org Original-Received: by ip-172-30-0-124.ec2.internal (JAMES SMTP Server ) with ESMTPA ID 616905336; Wed, 24 Mar 2021 09:09:38 +0000 (UTC) In-Reply-To: <8786a8e8faf45a989904@heytings.org> X-Mailer: Apple Mail (2.3445.9.7) Received-SPF: pass client-ip=34.202.193.197; envelope-from=pwr@bydasein.com; helo=sendmail.purelymail.com 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." <emacs-devel.gnu.org> List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-devel>, <mailto:emacs-devel-request@gnu.org?subject=unsubscribe> List-Archive: <https://lists.gnu.org/archive/html/emacs-devel> List-Post: <mailto:emacs-devel@gnu.org> List-Help: <mailto:emacs-devel-request@gnu.org?subject=help> List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-devel>, <mailto:emacs-devel-request@gnu.org?subject=subscribe> Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" <emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org> Xref: news.gmane.io gmane.emacs.devel:266933 Archived-At: <http://permalink.gmane.org/gmane.emacs.devel/266933> > On 24 Mar 2021, at 6:01 pm, Gregory Heytings <gregory@heytings.org> = wrote: >=20 >>>> No bugs here. Both of these work as expected. I think the issue is = you're confused about font-lock-mode and text properties. These are not = the same thing. Font-lock-mode is just one way to add text properties to = text, so may other functions. Deactivating font-lock-mode does not = remove all text properties, only on text with the `(fontified . t)' = property. This is why you're seeing what you're seeing. >>>=20 >>> Please explain this to Stefan M, who considers this to be bugs, who = would like to deprecate the font-lock-fontify-{buffer,block} commands, = and who guided me to write the font-lock-update command. >>=20 >> For sure. If you can, please link me to the lists.gnu.org message? >>=20 >=20 > I'm curious how you will explain to the author of = font-lock-fontify-buffer that his command has no bugs, when he thinks it = has and would like to obsolete it. The first message is at = https://lists.gnu.org/archive/html/emacs-devel/2021-03/msg00581.html . Thanks for the link. I've looped in Stefan so he can tell me I'm wrong, = but... I think the issue you describe, where yanked text includes previous text = properties without font-lock-mode active is expected behaviour. You can = control this behaviour with the variable `yank-excluded-properties'. = (Eli I'm surprised you didn't use this?) I think Stefan was commenting on how this behaviour might be unexpected, = then separately, also commenting on the messiness of the code in = `font-lock-fontify-buffer'. But the messiness of that code does not = imply that the way text properties work is a bug. I'm pretty sure the idea is to have a cleaner version of = `font-lock-fontify-buffer' i.e. a duplicate, which is almost what you = have. > By the way, what actual problems do you see in font-lock-update? Do = you see cases where it produces unexpected results? Just the toggling part. The command is called `font-lock-update' but = when font-lock-mode is active and the command is called with ARG, it = turns font-lock-mode off. =46rom the docstring I'm not sure if that was = your intention? Given this is a default key binding on the Holy = ctl-x-map (technically the ctl-x-x-map), it should probably do what it = says on the tin. Here's the same but what I'd consider a cleaner approach: (defun font-lock-update () "Refontify the accessible portion of the buffer. Unconditionally activate `font-lock-mode'." (interactive) (unless font-lock-mode (font-lock-mode 1)) (save-excursion (font-lock-fontify-region (point-min) (point-max)))) Technically this is still a bit misleading because of teh aforementioned = `font-lock-dont-widen' variable, but we can't have everything.