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.