'M-o' ('facemap-keymap') has now been removed until March 10th 2021

'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Lars Ingebrigtsen]

In the transition period, 'M-o' is bound to a command that pops up a
buffer that explains the sitch, and what to do to recover the old action
in the test period.  (And where to complain; i.e. here.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Alan Mackenzie]

Hello, Lars.

On Wed, Feb 10, 2021 at 19:40:03 +0100, Lars Ingebrigtsen wrote:
> In the transition period, 'M-o' is bound to a command that pops up a
> buffer that explains the sitch, and what to do to recover the old action
> in the test period.  (And where to complain; i.e. here.)

..... and the build is broken.

facemenu-color-alist is referenced in faces.el and wid-edit.el.  It is
defined in facemenu.el, which is no longer being loaded.

> -- 
> (domestic pets only, the antidote for overdose, milk.)
>    bloggy blog: http://lars.ingebrigtsen.no

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Lars Ingebrigtsen]

Alan Mackenzie <acm@muc.de> writes:

> ..... and the build is broken.
>
> facemenu-color-alist is referenced in faces.el and wid-edit.el.  It is
> defined in facemenu.el, which is no longer being loaded.

Oops.  I'll get fixing.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Oops.  I'll get fixing.

Should work better now...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Alan Mackenzie]

Hello, Lars.

On Wed, Feb 10, 2021 at 20:38:00 +0100, Lars Ingebrigtsen wrote:
> Lars Ingebrigtsen <larsi@gnus.org> writes:

> > Oops.  I'll get fixing.

> Should work better now...

Indeed: it now builds.  :-)

> -- 
> (domestic pets only, the antidote for overdose, milk.)
>    bloggy blog: http://lars.ingebrigtsen.no

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > In the transition period, 'M-o' is bound to a command that pops up a
  > buffer that explains the sitch, and what to do to recover the old action
  > in the test period.  (And where to complain; i.e. here.)

You're taking a lot of care.  Very good.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> In the transition period, 'M-o' is bound to a command that pops up a
> buffer that explains the sitch, and what to do to recover the old action
> in the test period.  (And where to complain; i.e. here.)

The test period is now over, so we should now discuss whether to make
the change permanent, and if so, whether we should bind any of the
affected commands to something else.

There hasn't been much feedback during the one month test period.  I
think there's been one complaint about missing `center-line', and
there's been at least two people mentioning `font-lock-fontify-block'
(previously bound to `M-o M-o').  I don't recall anybody complaining
about `facemenu-keymap' itself, though, or `center-paragraph'.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Thu, 11 Mar 2021 17:27:42 +0100
> 
> Lars Ingebrigtsen <larsi@gnus.org> writes:
> 
> > In the transition period, 'M-o' is bound to a command that pops up a
> > buffer that explains the sitch, and what to do to recover the old action
> > in the test period.  (And where to complain; i.e. here.)
> 
> The test period is now over, so we should now discuss whether to make
> the change permanent, and if so, whether we should bind any of the
> affected commands to something else.
> 
> There hasn't been much feedback during the one month test period.  I
> think there's been one complaint about missing `center-line', and
> there's been at least two people mentioning `font-lock-fontify-block'
> (previously bound to `M-o M-o').  I don't recall anybody complaining
> about `facemenu-keymap' itself, though, or `center-paragraph'.

IMO, font-lock-fontify-block should have a keybinding.  IME, it's too
important to be left without one.

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Gregory Heytings]

>>> In the transition period, 'M-o' is bound to a command that pops up a 
>>> buffer that explains the sitch, and what to do to recover the old 
>>> action in the test period.  (And where to complain; i.e. here.)
>>
>> The test period is now over, so we should now discuss whether to make 
>> the change permanent, and if so, whether we should bind any of the 
>> affected commands to something else.
>>
>> There hasn't been much feedback during the one month test period.  I 
>> think there's been one complaint about missing `center-line', and 
>> there's been at least two people mentioning `font-lock-fontify-block' 
>> (previously bound to `M-o M-o').  I don't recall anybody complaining 
>> about `facemenu-keymap' itself, though, or `center-paragraph'.
>
> IMO, font-lock-fontify-block should have a keybinding.  IME, it's too 
> important to be left without one.
>

I suggest to put it in the new keymap for buffer-related commands, for 
example:

C-x x l = font-lock-mode (i.e. toggle font lock mode on and off)
C-x x b = font-lock-fontify-block
C-x x B = font-lock-fontify-buffer

font-lock-fontify-block (was: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021)

[Stefan Monnier]

>> There hasn't been much feedback during the one month test period.  I
>> think there's been one complaint about missing `center-line', and
>> there's been at least two people mentioning `font-lock-fontify-block'
>> (previously bound to `M-o M-o').  I don't recall anybody complaining
>> about `facemenu-keymap' itself, though, or `center-paragraph'.
>
> IMO, font-lock-fontify-block should have a keybinding.  IME, it's too
> important to be left without one.

Wow, I didn't expect that.  I was instead about to ask for details about
the mentions of `font-lock-fontify-block' since I view it as a command
which "should" be a no-op (barring bugs, obviously).

I'd be quite interested to know more about those existing use cases (they
may point to other misgivings of mine, as well).


        Stefan

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Eli Zaretskii]

> Date: Thu, 11 Mar 2021 17:02:33 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: Lars Ingebrigtsen <larsi@gnus.org>, emacs-devel@gnu.org
> 
> C-x x b = font-lock-fontify-block

That's better than nothing, but nowhere as convenient to type as "M-o M-o",
IMO.

Re: font-lock-fontify-block (was: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021)

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Thu, 11 Mar 2021 12:12:47 -0500
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, emacs-devel@gnu.org
> 
> > IMO, font-lock-fontify-block should have a keybinding.  IME, it's too
> > important to be left without one.
> 
> Wow, I didn't expect that.  I was instead about to ask for details about
> the mentions of `font-lock-fontify-block' since I view it as a command
> which "should" be a no-op (barring bugs, obviously).
> 
> I'd be quite interested to know more about those existing use cases (they
> may point to other misgivings of mine, as well).

When I edit code, I sometimes see it mis-fontified when I'm half-way
through editing a syntactic construct.  Unlike some others, I don't
expect font-lock to do a 110% perfect job in every situation, and
prefer a casual M-o M-o to having font-lock definition for a mode
perfected to a point where it becomes unbearably sluggish.

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> The test period is now over, so we should now discuss whether to make
> the change permanent, and if so, whether we should bind any of the
> affected commands to something else.

From the feedback received so far, it seems okay to remove that binding.

I think we should also consider binding `M-o' to `other-window'.  I've
been using such a binding for the last month, and IMHO it is a big
improvement to `C-x o'.

Re: font-lock-fontify-block

[Stefan Monnier]

>> > IMO, font-lock-fontify-block should have a keybinding.  IME, it's too
>> > important to be left without one.
>> 
>> Wow, I didn't expect that.  I was instead about to ask for details about
>> the mentions of `font-lock-fontify-block' since I view it as a command
>> which "should" be a no-op (barring bugs, obviously).
>> 
>> I'd be quite interested to know more about those existing use cases (they
>> may point to other misgivings of mine, as well).
>
> When I edit code, I sometimes see it mis-fontified when I'm half-way
> through editing a syntactic construct.  Unlike some others, I don't
> expect font-lock to do a 110% perfect job in every situation, and
> prefer a casual M-o M-o to having font-lock definition for a mode
> perfected to a point where it becomes unbearably sluggish.

OK, so your use case is when font-lock is already enabled.
Do you have some general idea of what are the most common reasons for
the temporary mis-fontification?

AFAIK usually misfontifications aren't temporary unless they're linked
to some multiline element, most commonly an unclosed string or comment
and those should get fixed automatically after a short delay.
So is it the case that the cases where you needed `M-o M-o` would
fix themselves after a short delay anyway (I'm OK with keeping such
a command for the case you don't want to wait, I'm just trying to
understand what it is that `M-o M-o` corrects).
Can you think of other cases where `M-o M-o` improved the fontification?

Would you be OK with the idea of deprecating the use of
`font-lock-fontify-block' for the specific case where font-lock is
not enabled?

Also, I suspect that for your use case, we could have a general
"refresh" command, which just calls `font-lock-flush`, which would not
depend on the ill-defined notion of "block" (and wouldn't mess with the
mark).


        Stefan

Re: font-lock-fontify-block

[Gregory Heytings]

>
> Also, I suspect that for your use case, we could have a general 
> "refresh" command, which just calls `font-lock-flush`, which would not 
> depend on the ill-defined notion of "block" (and wouldn't mess with the 
> mark).
>

Yes, I agree that a

(defun font-lock-fontify-window ()
   (interactive)
   (font-lock-flush (window-start) (window-end)))

would probably be useful.

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Alfred M. Szmidt]

   There hasn't been much feedback during the one month test period.  I
   think there's been one complaint about missing `center-line', [...]

There have been two complaints at least, and I recall that I got told
off to just bind a key for center-line and center-paragraph'.

Re: font-lock-fontify-block

[Stefan Monnier]

>> Also, I suspect that for your use case, we could have a general "refresh"
>> command, which just calls `font-lock-flush`, which would not depend on the
>> ill-defined notion of "block" (and wouldn't mess with the mark).
> Yes, I agree that a
>
> (defun font-lock-fontify-window ()
>   (interactive)
>   (font-lock-flush (window-start) (window-end)))
>
> would probably be useful.

It could even flush from point-min to point-max.


        Stefan

Re: font-lock-fontify-block

[Gregory Heytings]

>>> Also, I suspect that for your use case, we could have a general 
>>> "refresh" command, which just calls `font-lock-flush`, which would not 
>>> depend on the ill-defined notion of "block" (and wouldn't mess with 
>>> the mark).
>>
>> Yes, I agree that a
>>
>> (defun font-lock-fontify-window ()
>>   (interactive)
>>   (font-lock-flush (window-start) (window-end)))
>>
>> would probably be useful.
>
> It could even flush from point-min to point-max.
>

Is that not what font-lock-fontify-buffer already does (except during 
narrowing)?

Re: font-lock-fontify-block

[Stefan Monnier]

>>>> Also, I suspect that for your use case, we could have a general
>>>> "refresh" command, which just calls `font-lock-flush`, which would not
>>>> depend on the ill-defined notion of "block" (and wouldn't mess with the
>>>> mark).
>>>
>>> Yes, I agree that a
>>>
>>> (defun font-lock-fontify-window ()
>>>   (interactive)
>>>   (font-lock-flush (window-start) (window-end)))
>>>
>>> would probably be useful.
>>
>> It could even flush from point-min to point-max.
>>
>
> Is that not what font-lock-fontify-buffer already does (except during
> narrowing)?

Indeed (but that one, just like `font-lock-fontify-block`) suffers from
a heavy heritage so it's messy and misused, so I'd be very happy to
obsolete it (by replacing it with something simpler and that only
caters to the relevant cases).


        Stefan

Re: font-lock-fontify-block

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: larsi@gnus.org,  emacs-devel@gnu.org
> Date: Thu, 11 Mar 2021 12:52:27 -0500
> 
> Do you have some general idea of what are the most common reasons for
> the temporary mis-fontification?
> 
> AFAIK usually misfontifications aren't temporary unless they're linked
> to some multiline element, most commonly an unclosed string or comment
> and those should get fixed automatically after a short delay.

Probably.  But also when fontification is highly context-dependent, I
think.

> So is it the case that the cases where you needed `M-o M-o` would
> fix themselves after a short delay anyway (I'm OK with keeping such
> a command for the case you don't want to wait, I'm just trying to
> understand what it is that `M-o M-o` corrects).

No, in most cases where I used it, the delay isn't short.  More like
infinite.

> Would you be OK with the idea of deprecating the use of
> `font-lock-fontify-block' for the specific case where font-lock is
> not enabled?

I only ever use it in that case to _remove_ the faces from text yanked
from a fontified buffer.  So that's another important use case for
M-o M-o.

> Also, I suspect that for your use case, we could have a general
> "refresh" command, which just calls `font-lock-flush`, which would not
> depend on the ill-defined notion of "block" (and wouldn't mess with the
> mark).

I'd have to use it for a while to have an opinion.

Re: font-lock-fontify-block

[Gregory Heytings]

>
> Indeed (but that one, just like `font-lock-fontify-block`) suffers from 
> a heavy heritage so it's messy and misused, so I'd be very happy to 
> obsolete it (by replacing it with something simpler and that only caters 
> to the relevant cases).
>

In that case I would perhaps suggest:

(defun font-lock-refontify (&optional arg)
   (interactive "P")
   (font-lock-flush (if arg (point-min) (window-start))
                    (if arg (point-max) (window-end))))
(global-set-key (kbd "C-x x f") 'font-lock-refontify)
(global-set-key (kbd "C-x x F") 'font-lock-mode)

Re: font-lock-fontify-block

[Eli Zaretskii]

> Date: Thu, 11 Mar 2021 22:10:31 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: larsi@gnus.org, emacs-devel@gnu.org
> 
> > Would you be OK with the idea of deprecating the use of
> > `font-lock-fontify-block' for the specific case where font-lock is
> > not enabled?
> 
> I only ever use it in that case to _remove_ the faces from text yanked
> from a fontified buffer.  So that's another important use case for
> M-o M-o.

Actually, I see I've misremembered: this is handy not when
font-lock-mode is off, but when it's on and I yank text from another
mode.  A typical use case is when I yank from some program fragment
into a text-mode buffer: the original fontification is left alone
until I type M-o M-o.

Re: font-lock-fontify-block

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Actually, I see I've misremembered: this is handy not when
> font-lock-mode is off, but when it's on and I yank text from another
> mode.  A typical use case is when I yank from some program fragment
> into a text-mode buffer: the original fontification is left alone
> until I type M-o M-o.

That does sound quite useful, yes -- that's something I bump into from
time to time, but has never known what to do about.  So we should
probably give it a new default key binding (if we decide to free up
`M-o').

In a couple of test cases here, though, `font-lock-fontify-buffer' seems
to give more dependable results.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: font-lock-fontify-block

[Gregory Heytings]

>>> Would you be OK with the idea of deprecating the use of 
>>> `font-lock-fontify-block' for the specific case where font-lock is not 
>>> enabled?
>>
>> I only ever use it in that case to _remove_ the faces from text yanked 
>> from a fontified buffer.  So that's another important use case for M-o 
>> M-o.
>
> Actually, I see I've misremembered: this is handy not when 
> font-lock-mode is off, but when it's on and I yank text from another 
> mode.  A typical use case is when I yank from some program fragment into 
> a text-mode buffer: the original fontification is left alone until I 
> type M-o M-o.
>

I have four remarks:

1. I was surprised to read this, it's something I never see.  It turns out 
that I don't see this because I have in my .emacs:

(global-whitespace-mode 1)
(setq whitespace-style '(face trailing empty))

2. That being said, font-lock-fontify-block is not a good solution to that 
problem, it doesn't work when the yanked text is larger than 16 lines, 
except of course with a prefix argument.

3. font-lock-flush would not solve that problem, it has no apparent effect 
in the case you mention.

4. Is this not something that could/should be done inside yank, with (if 
font-lock-mode (font-lock-fontify-region (point-min) (point-max)))?

Re: font-lock-fontify-block

[Stefan Monnier]

>> Do you have some general idea of what are the most common reasons for
>> the temporary mis-fontification?
>> AFAIK usually misfontifications aren't temporary unless they're linked
>> to some multiline element, most commonly an unclosed string or comment
>> and those should get fixed automatically after a short delay.
> Probably.  But also when fontification is highly context-dependent, I
> think.

Hmm... I winder what those situations are like.
If/when you can think of examples, that would be very helpful, thanks.

>> So is it the case that the cases where you needed `M-o M-o` would
>> fix themselves after a short delay anyway (I'm OK with keeping such
>> a command for the case you don't want to wait, I'm just trying to
>> understand what it is that `M-o M-o` corrects).
> No, in most cases where I used it, the delay isn't short.  More like
> infinite.

So they really correspond to what I would consider as bugs (some of
which might be known and we don't really know how to fix).

>> Would you be OK with the idea of deprecating the use of
>> `font-lock-fontify-block' for the specific case where font-lock is
>> not enabled?
> I only ever use it in that case to _remove_ the faces from text yanked
> from a fontified buffer.  So that's another important use case for
> M-o M-o.

Oh, that never occurred to me.  I generally just "live with it".

>> Also, I suspect that for your use case, we could have a general
>> "refresh" command, which just calls `font-lock-flush`, which would not
>> depend on the ill-defined notion of "block" (and wouldn't mess with the
>> mark).
>
> I'd have to use it for a while to have an opinion.

For the "yank into text-mode" case, I guess we'd still need to limit the
effect, either via the use of the notion of "block" or by requiring to
select a region.


        Stefan

Re: font-lock-fontify-block

[Eli Zaretskii]

> Date: Thu, 11 Mar 2021 21:57:18 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: emacs-devel@gnu.org
> 
> 2. That being said, font-lock-fontify-block is not a good solution to that 
> problem, it doesn't work when the yanked text is larger than 16 lines, 
> except of course with a prefix argument.

I guess 16 lines is really beyond anything I ever needed to deal with
in this use case, because I don't remember ever having such problems.

"M-o M-o" is convenient here because I need to remember only a single
command to "fix" any issues with faces, whether it means re-fontify
the block or "un-fontify" it.  I'm okay with any other command to
perform the same duty, as long as its key-binding is convenient to
type ("C-x x ..." is less convenient, because it requires me to
release the Ctrl key half-way through the sequence).

> 4. Is this not something that could/should be done inside yank, with (if 
> font-lock-mode (font-lock-fontify-region (point-min) (point-max)))?

I don't think we can make such behavior changes in yank at this point.
And even if we did, we will never be able to make sure "wrong" faces
aren't left after some command, so a convenient command to fix
fontification will always be needed, IMO.

Re: font-lock-fontify-block

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Thu, 11 Mar 2021 17:14:02 -0500
> Cc: larsi@gnus.org, emacs-devel@gnu.org
> 
> For the "yank into text-mode" case, I guess we'd still need to limit the
> effect, either via the use of the notion of "block" or by requiring to
> select a region.

How about doing it for the current paragraph by default?

Re: font-lock-fontify-block

[Stefan Reichör]

[-- Attachment #1: Type: text/plain, Size: 1742 bytes --]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> > IMO, font-lock-fontify-block should have a keybinding.  IME, it's too
>>> > important to be left without one.
>>> 
>>> Wow, I didn't expect that.  I was instead about to ask for details about
>>> the mentions of `font-lock-fontify-block' since I view it as a command
>>> which "should" be a no-op (barring bugs, obviously).
>>> 
>>> I'd be quite interested to know more about those existing use cases (they
>>> may point to other misgivings of mine, as well).
>>
>> When I edit code, I sometimes see it mis-fontified when I'm half-way
>> through editing a syntactic construct.  Unlike some others, I don't
>> expect font-lock to do a 110% perfect job in every situation, and
>> prefer a casual M-o M-o to having font-lock definition for a mode
>> perfected to a point where it becomes unbearably sluggish.
>
> OK, so your use case is when font-lock is already enabled.
> Do you have some general idea of what are the most common reasons for
> the temporary mis-fontification?

I am still using emacs-muse. My .muse files often contain a lot of links
to files. These links are often wrong fontified (not the whole file link
is fontified, but just the start of it).

M-o M-o seems to cure this problem.

This mis-fontification is in Emacs since years. But I am sure there was
a time when it worked without a problem.

The mis-fontification is not always on the same position. I varies every
time a open the file (no idea why).

For me this is inconvenient, but I have learned to live with it.

In the attached image you see on the top 3 incomplete fontified lines.
In the bottom part you see the result after M-x font-lock-fontify-block
(everything is fontified correct here).

Stefan.


[-- Attachment #2: muse-misfontification.png --]
[-- Type: image/png, Size: 316397 bytes --]

Re: font-lock-fontify-block

[Gregory Heytings]

>
> Indeed (but that one, just like `font-lock-fontify-block`) suffers from 
> a heavy heritage so it's messy and misused, so I'd be very happy to 
> obsolete it (by replacing it with something simpler and that only caters 
> to the relevant cases).
>

Another question: is font-lock-fontify-region also among the functions 
you'd like to obsolete?

Re: font-lock-fontify-block

[Gregory Heytings]

>
> I guess 16 lines is really beyond anything I ever needed to deal with in 
> this use case, because I don't remember ever having such problems.
>
> "M-o M-o" is convenient here because I need to remember only a single 
> command to "fix" any issues with faces, whether it means re-fontify the 
> block or "un-fontify" it.  I'm okay with any other command to perform 
> the same duty, as long as its key-binding is convenient to type ("C-x x 
> ..." is less convenient, because it requires me to release the Ctrl key 
> half-way through the sequence).
>

You can always rebind it to a key you find convenient in your .emacs file 
(e.g. C-F5).  If you use that command often and really think a "C-x x ..." 
key binding in vanilla Emacs would not be sufficient, I would perhaps 
suggest C-M-|, which is close to C-M-\ = indent-region and would do 
something similar.

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Filipp Gunbin]

On 11/03/2021 17:02 +0000, Gregory Heytings wrote:

> I suggest to put it in the new keymap for buffer-related commands, for
> example:
>
> C-x x l = font-lock-mode (i.e. toggle font lock mode on and off)
> C-x x b = font-lock-fontify-block
> C-x x B = font-lock-fontify-buffer

But it's not an operation on buffer itself...  Yes there's
toggle-truncate-lines on C-x x t, but it also looks a bit alien on this
prefix.

Re: font-lock-fontify-block

[Eli Zaretskii]

> Date: Fri, 12 Mar 2021 08:28:36 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: emacs-devel@gnu.org
> 
> > "M-o M-o" is convenient here because I need to remember only a single 
> > command to "fix" any issues with faces, whether it means re-fontify the 
> > block or "un-fontify" it.  I'm okay with any other command to perform 
> > the same duty, as long as its key-binding is convenient to type ("C-x x 
> > ..." is less convenient, because it requires me to release the Ctrl key 
> > half-way through the sequence).
> >
> 
> You can always rebind it to a key you find convenient in your .emacs file 

That is true for any key binding, as well as for commands that don't
have a key binding.  But here we are talking about a command that had
a convenient key binding for ages, so if we move it to an inconvenient
key binding, that is a kind of regression.

Re: font-lock-fontify-block

[Gregory Heytings]

>>> "M-o M-o" is convenient here because I need to remember only a single 
>>> command to "fix" any issues with faces, whether it means re-fontify 
>>> the block or "un-fontify" it.  I'm okay with any other command to 
>>> perform the same duty, as long as its key-binding is convenient to 
>>> type ("C-x x ..." is less convenient, because it requires me to 
>>> release the Ctrl key half-way through the sequence).
>>
>> You can always rebind it to a key you find convenient in your .emacs 
>> file
>
> That is true for any key binding, as well as for commands that don't 
> have a key binding.
>
> But here we are talking about a command that had a convenient key 
> binding for ages, so if we move it to an inconvenient key binding, that 
> is a kind of regression.
>

I understand that you find the "C-x x f" not as convenient as "M-o M-o", 
although it seems to me that for a not-often-used command, that binding 
could be okay, but that's just me.  What do you think of the "C-M-|" 
binding I proposed?

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Gregory Heytings]

>
> But it's not an operation on buffer itself...  Yes there's 
> toggle-truncate-lines on C-x x t, but it also looks a bit alien on this 
> prefix.
>

AFAIU, the C-x x prefix was meant for buffer-related commands, not only 
for operations on buffers.  And changing the way the buffer is displayed 
is a buffer-related command.

Re: font-lock-fontify-block

[Eli Zaretskii]

> Date: Fri, 12 Mar 2021 12:43:34 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: emacs-devel@gnu.org
> 
> I understand that you find the "C-x x f" not as convenient as "M-o M-o", 
> although it seems to me that for a not-often-used command, that binding 
> could be okay, but that's just me.  What do you think of the "C-M-|" 
> binding I proposed?

It's slightly better, although having to press 3 modifier keys isn't
easy.  Plus, it doesn't work on TTY frames.

Re: font-lock-fontify-block

[tomas]

[-- Attachment #1: Type: text/plain, Size: 670 bytes --]

On Fri, Mar 12, 2021 at 12:43:34PM +0000, Gregory Heytings wrote:

[...]

> I understand that you find the "C-x x f" not as convenient as "M-o
> M-o", although it seems to me that for a not-often-used command,
> that binding could be okay, but that's just me.  What do you think
> of the "C-M-|" binding I proposed?

DISCLAIMER: I'm not touched by this, since I don't use this command
often. For me, it's clearly in the "M-x" category.

But when doing such keybindings, please think of us poor sods with
a non-US keyboard. For many, "C-M-|" degenerates to a "C-M-AltGr-|",
which is... acrobatic :-)

(not saying you shouldn't do it, just raising awareness)

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: font-lock-fontify-block

[tomas]

[-- Attachment #1: Type: text/plain, Size: 643 bytes --]

On Fri, Mar 12, 2021 at 02:56:52PM +0200, Eli Zaretskii wrote:
> > Date: Fri, 12 Mar 2021 12:43:34 +0000
> > From: Gregory Heytings <gregory@heytings.org>
> > cc: emacs-devel@gnu.org
> > 
> > I understand that you find the "C-x x f" not as convenient as "M-o M-o", 
> > although it seems to me that for a not-often-used command, that binding 
> > could be okay, but that's just me.  What do you think of the "C-M-|" 
> > binding I proposed?
> 
> It's slightly better, although having to press 3 modifier keys isn't
> easy.  Plus, it doesn't work on TTY frames.

Ah, three. Your keyboard is as funny as mine is :)

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: font-lock-fontify-block

[Eli Zaretskii]

> Date: Fri, 12 Mar 2021 14:07:33 +0100
> Cc: Gregory Heytings <gregory@heytings.org>, emacs-devel@gnu.org
> From:  <tomas@tuxteam.de>
> 
> > It's slightly better, although having to press 3 modifier keys isn't
> > easy.  Plus, it doesn't work on TTY frames.
> 
> Ah, three. Your keyboard is as funny as mine is :)

I'm not sure.  '|' is above '\', so it needs a Shift in addition to
Ctrl and Alt.

Re: font-lock-fontify-block

[tomas]

[-- Attachment #1: Type: text/plain, Size: 701 bytes --]

On Fri, Mar 12, 2021 at 03:11:55PM +0200, Eli Zaretskii wrote:
> > Date: Fri, 12 Mar 2021 14:07:33 +0100
> > Cc: Gregory Heytings <gregory@heytings.org>, emacs-devel@gnu.org
> > From:  <tomas@tuxteam.de>
> > 
> > > It's slightly better, although having to press 3 modifier keys isn't
> > > easy.  Plus, it doesn't work on TTY frames.
> > 
> > Ah, three. Your keyboard is as funny as mine is :)
> 
> I'm not sure.  '|' is above '\', so it needs a Shift in addition to
> Ctrl and Alt.

Ah. Not the same modifier. On mine it's AltGr instead of Shift, but
the gymnastics are similar, I guess. At least you get the choice
whether you break your left or your right pinky ;-)

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: font-lock-fontify-block

[Stefan Monnier]

> But when doing such keybindings, please think of us poor sods with
> a non-US keyboard. For many, "C-M-|" degenerates to a "C-M-AltGr-|",
> which is... acrobatic :-)

Oh, come on, three modifiers plus the actual key is pretty far from
the limit (which is of course 20 except for those rare users who refuse
to use their feet).


        Stefan

Re: font-lock-fontify-block

[Stefan Monnier]

>> Indeed (but that one, just like `font-lock-fontify-block`) suffers from
>> a heavy heritage so it's messy and misused, so I'd be very happy to
>> obsolete it (by replacing it with something simpler and that only caters
>> to the relevant cases).
> Another question: is font-lock-fontify-region also among the functions you'd
> like to obsolete?

`font-lock-fontify-region` is an important function internally (it's
the one and only function which performs font-locking, fundamentally),
so no.


        Stefan

Re: font-lock-fontify-block

[Gregory Heytings]

>>> Indeed (but that one, just like `font-lock-fontify-block`) suffers 
>>> from a heavy heritage so it's messy and misused, so I'd be very happy 
>>> to obsolete it (by replacing it with something simpler and that only 
>>> caters to the relevant cases).
>>
>> Another question: is font-lock-fontify-region also among the functions 
>> you'd like to obsolete?
>
> `font-lock-fontify-region` is an important function internally (it's the 
> one and only function which performs font-locking, fundamentally), so 
> no.
>

Thank you.  That was my impression, too, but I wasn't 100% sure.  Given 
this, my updated suggestion is:

(defun font-lock-update (&optional arg)
   (interactive "P")
   (save-mark-and-excursion
     (if (not arg)
 	(font-lock-fontify-region (point-min) (point-max))
       (font-lock-unfontify-region (point-min) (point-max))
       (font-lock-mode 'toggle))))
(global-set-key (kbd "C-x x f") 'font-lock-update)

Re: font-lock-fontify-block

[Gregory Heytings]

>> I understand that you find the "C-x x f" not as convenient as "M-o 
>> M-o", although it seems to me that for a not-often-used command, that 
>> binding could be okay, but that's just me.  What do you think of the 
>> "C-M-|" binding I proposed?
>
> It's slightly better, although having to press 3 modifier keys isn't 
> easy.  Plus, it doesn't work on TTY frames.
>

If you believe this command is widely used and needs a short key binding 
that can be used both in GUI and TTY frames, one of the other free keys 
could be used for that purpose.  For example C-x C-a, or C-x C-y, or M-".

Re: font-lock-fontify-block

[Eli Zaretskii]

> Date: Fri, 12 Mar 2021 14:40:19 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: emacs-devel@gnu.org
> 
> >> I understand that you find the "C-x x f" not as convenient as "M-o 
> >> M-o", although it seems to me that for a not-often-used command, that 
> >> binding could be okay, but that's just me.  What do you think of the 
> >> "C-M-|" binding I proposed?
> >
> > It's slightly better, although having to press 3 modifier keys isn't 
> > easy.  Plus, it doesn't work on TTY frames.
> 
> If you believe this command is widely used

I don't see how my beliefs are relevant here, sorry.

> and needs a short key binding that can be used both in GUI and TTY
> frames, one of the other free keys could be used for that purpose.
> For example C-x C-a, or C-x C-y, or M-".

C-x C-a is used in GUD, so it's a non-starter.

Re: font-lock-fontify-block

[Stefan Monnier]

> Thank you.  That was my impression, too, but I wasn't 100% sure.
> Given this, my updated suggestion is:
>
> (defun font-lock-update (&optional arg)
>   (interactive "P")
>   (save-mark-and-excursion
>     (if (not arg)
> 	(font-lock-fontify-region (point-min) (point-max))
>       (font-lock-unfontify-region (point-min) (point-max))
>       (font-lock-mode 'toggle))))
> (global-set-key (kbd "C-x x f") 'font-lock-update)

No, if you start with that you will end with what we have.


        Stefan

Re: font-lock-fontify-block

[tomas]

[-- Attachment #1: Type: text/plain, Size: 623 bytes --]

On Fri, Mar 12, 2021 at 08:54:07AM -0500, Stefan Monnier wrote:
> > But when doing such keybindings, please think of us poor sods with
> > a non-US keyboard. For many, "C-M-|" degenerates to a "C-M-AltGr-|",
> > which is... acrobatic :-)
> 
> Oh, come on, three modifiers plus the actual key is pretty far from
> the limit (which is of course 20 except for those rare users who refuse
> to use their feet).
               ^^^^

Pics or it didn't happen. Bonus points for a video workshop ;-D

Back on topic: for me not that important, since this command is
(for me) deeply in M-x land anyway.

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: font-lock-fontify-block

[Gregory Heytings]

>> Thank you.  That was my impression, too, but I wasn't 100% sure. Given 
>> this, my updated suggestion is:
>>
>> (defun font-lock-update (&optional arg)
>>   (interactive "P")
>>   (save-mark-and-excursion
>>     (if (not arg)
>> 	(font-lock-fontify-region (point-min) (point-max))
>>       (font-lock-unfontify-region (point-min) (point-max))
>>       (font-lock-mode 'toggle))))
>> (global-set-key (kbd "C-x x f") 'font-lock-update)
>
> No, if you start with that you will end with what we have.
>

Sorry, I don't understand what you mean.

Re: font-lock-fontify-block

[Stefan Monnier]

>>> (defun font-lock-update (&optional arg)
>>>   (interactive "P")
>>>   (save-mark-and-excursion
>>>     (if (not arg)
>>> 	(font-lock-fontify-region (point-min) (point-max))
>>>       (font-lock-unfontify-region (point-min) (point-max))
>>>       (font-lock-mode 'toggle))))
>>> (global-set-key (kbd "C-x x f") 'font-lock-update)
>> No, if you start with that you will end with what we have.
> Sorry, I don't understand what you mean.

That its behavior is defined by its implementation.

E.g. I find the current behavior to be a bug when font-lock-mode is
disabled in an elisp-mode buffer and your code would be similarly buggy.


        Stefan

Re: font-lock-fontify-block

[Gregory Heytings]

>
> That its behavior is defined by its implementation.
>
> E.g. I find the current behavior to be a bug when font-lock-mode is 
> disabled in an elisp-mode buffer and your code would be similarly buggy.
>

Indeed, what I proposed would be similar to what exists.  But I still 
don't understand: what is the bug when font-lock-mode is disabled in an 
elisp-mode buffer?  Do I understand correctly that you would like to keep 
the current fontification when font-lock-mode is disabled?

Re: font-lock-fontify-block

[Stefan Monnier]

> Indeed, what I proposed would be similar to what exists.  But I still don't
> understand: what is the bug when font-lock-mode is disabled in an elisp-mode
> buffer?

It gives you some part of the code fontified and the rest not, and if
you edit that part that is fontified the fontification will just "stick"
where it is, regardless if it's still valid/relevant.

I can't think of any reason why anyone would consider this to be a feature.


        Stefan

Re: font-lock-fontify-block

[Gregory Heytings]

>> Indeed, what I proposed would be similar to what exists.  But I still 
>> don't understand: what is the bug when font-lock-mode is disabled in an 
>> elisp-mode buffer?
>
> It gives you some part of the code fontified and the rest not, and if 
> you edit that part that is fontified the fontification will just "stick" 
> where it is, regardless if it's still valid/relevant.
>

Now I'm totally puzzled.  emacs -Q, "unless", M-., M-x font-lock-mode: the 
whole buffer is unfontified.  What am I missing?

Re: font-lock-fontify-block

[Stefan Monnier]

> Now I'm totally puzzled.  emacs -Q, "unless", M-., M-x font-lock-mode: the
> whole buffer is unfontified.  What am I missing?

Running font-lock-fontify-block and then edit the now fontified text?


        Stefan

Re: font-lock-fontify-block

[Gregory Heytings]

>> Now I'm totally puzzled.  emacs -Q, "unless", M-., M-x font-lock-mode: 
>> the whole buffer is unfontified.  What am I missing?
>
> Running font-lock-fontify-block and then edit the now fontified text?
>

What I proposed was under the assumption that font-lock-fontify-block was 
(about to be) obsolete(d).  But you are correct, I got the condition 
wrong:

(defun font-lock-update (&optional arg)
   (interactive "P")
   (save-mark-and-excursion
     (if (and (not arg) font-lock-mode)
         (font-lock-fontify-region (point-min) (point-max))
       (font-lock-unfontify-region (point-min) (point-max))
       (font-lock-mode 'toggle))))
(global-set-key (kbd "C-x x f") 'font-lock-update)

Re: font-lock-fontify-block

[Stefan Monnier]

> What I proposed was under the assumption that font-lock-fontify-block was
> (about to be) obsolete(d).  But you are correct, I got the condition wrong:

I don't know: show us the docstring and then maybe we'll be able to tell
when the code is wrong.


        Stefan

Re: font-lock-fontify-block

[Gregory Heytings]

>> What I proposed was under the assumption that font-lock-fontify-block 
>> was (about to be) obsolete(d).  But you are correct, I got the 
>> condition wrong:
>
> I don't know: show us the docstring and then maybe we'll be able to tell 
> when the code is wrong.
>

Here it is (it's a kind of "dwim" command):

(defun font-lock-update (&optional arg)
   "Updates the syntax highlighting in this buffer.
Enable Font Lock mode if it is disabled.
Otherwise, refontify the accessible portion of the buffer.
With prefix ARG, toggle Font Lock mode."
   (interactive "P")
   (save-mark-and-excursion
     (if (and (not arg) font-lock-mode)
         (font-lock-fontify-region (point-min) (point-max))
       (font-lock-unfontify-region (point-min) (point-max))
       (font-lock-mode 'toggle))))
(global-set-key (kbd "C-x x f") 'font-lock-update)

Re: font-lock-fontify-block

[Stefan Monnier]

>   (save-mark-and-excursion
>     (if (and (not arg) font-lock-mode)
>         (font-lock-fontify-region (point-min) (point-max))
>       (font-lock-unfontify-region (point-min) (point-max))
>       (font-lock-mode 'toggle))))

Why do you need `save-mark-and-excursion`?


        Stefan

Re: font-lock-fontify-block

[Gregory Heytings]

>>   (save-mark-and-excursion
>>     (if (and (not arg) font-lock-mode)
>>         (font-lock-fontify-region (point-min) (point-max))
>>       (font-lock-unfontify-region (point-min) (point-max))
>>       (font-lock-mode 'toggle))))
>
> Why do you need `save-mark-and-excursion`?
>

Because font-lock-fontify-region changes point.  It seems that it doesn't 
change mark, but I'm not sure it never will, so I've used 
save-mark-and-excursion just in case.

Re: font-lock-fontify-block

[Stefan Monnier]

> Because font-lock-fontify-region changes point.  It seems that it doesn't
>  change mark, but I'm not sure it never will, so I've used
>  save-mark-and-excursion just in case.

It never will so you can use `save-excursion`.


        Stefan

Re: font-lock-fontify-block

[Gregory Heytings]

>> Because font-lock-fontify-region changes point.  It seems that it 
>> doesn't change mark, but I'm not sure it never will, so I've used 
>> save-mark-and-excursion just in case.
>
> It never will so you can use `save-excursion`.
>

Okay, thanks:

(defun font-lock-update (&optional arg)
   "Updates the syntax highlighting in this buffer.
Refontify the accessible portion of this buffer, or enable Font Lock mode
in this buffer if it is currently disabled.  With prefix ARG, toggle Font
Lock mode."
   (interactive "P")
   (save-excursion
     (if (and (not arg) font-lock-mode)
         (font-lock-fontify-region (point-min) (point-max))
       (font-lock-unfontify-region (point-min) (point-max))
       (font-lock-mode 'toggle))))
(global-set-key (kbd "C-x x f") 'font-lock-update)

The "C-x x f" binding is less convenient than the "M-o M-o" one, but this 
regression is compensated by the fact that font-lock-update works 
correctly, unlike font-lock-fontify-block.  It is also more general, as it 
can be used to toggle Font Lock mode.  All in all, it seems to me that 
this is a progress.

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Sean Whitton]

Hello,

On Thu 11 Mar 2021 at 05:27PM +01, Lars Ingebrigtsen wrote:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> In the transition period, 'M-o' is bound to a command that pops up a
>> buffer that explains the sitch, and what to do to recover the old action
>> in the test period.  (And where to complain; i.e. here.)
>
> The test period is now over, so we should now discuss whether to make
> the change permanent, and if so, whether we should bind any of the
> affected commands to something else.

There was previously some suggestion to reserve M-o as a prefix map for
third-party packages like Magit, to avoid a situation like the recent
one with C-x g.

It occurs to me that in that case, Emacs could still bind a few keys
under the prefix, like M-o M-o, for core functionality, but leave the
rest open.

Is there still an appetite for something like that?

-- 
Sean Whitton

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Lars Ingebrigtsen]

Sean Whitton <spwhitton@spwhitton.name> writes:

> There was previously some suggestion to reserve M-o as a prefix map for
> third-party packages like Magit, to avoid a situation like the recent
> one with C-x g.
>
> It occurs to me that in that case, Emacs could still bind a few keys
> under the prefix, like M-o M-o, for core functionality, but leave the
> rest open.

I'd rather leave it unbound for users.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> The test period is now over, so we should now discuss whether to make
> the change permanent, and if so, whether we should bind any of the
> affected commands to something else.

We've now had a one week discussion period, so I've made some decisions.

1) Nobody wanted to keep the global `M-o' binding (facemenu), so I've
removed that.

2) There was no clamouring to keep a global binding for `center-line'
and `center-paragraph', so those that find those commands extremely
useful will have to bind it themselves.

3) 99.7% of the discussion involved whether `font-lock-fontify-block'
was useful or not.  Apparently most people had never heard of it, but
when they did hear of it, several said (I'm paraphrasing) "that sounds
quite useful indeed, but it's a bit odd" (i.e., the "block" it fontifies
doesn't seem ideal).  Gregory suggested a variation on it, and that
seems to work even better, so I've included it and bound it to
`C-x x f'.  (But those that really want `font-lock-fontify-block' will
have to bind it themselves.)

I've now pushed these changes.  (And we no longer need to preload
facemenu, I guess, so I'll try to remove that, but it's not totally
trivial.)

This concludes our first experimental test on the devel branch.  The
amount of feedback wasn't overwhelming, but we did get some -- and I
guess the `M-o' command wasn't very popular, so I'm not really that
surprised.

So I think it was a moderately successful experiment, and we should use
this way of trying out user interface changes more.  The time periods
seem OK to me -- one month for the experiment, and then one additional
week for discussion at the end (so I guess it's really more like five
weeks).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Sean Whitton]

Hello Lars,

On Thu 18 Mar 2021 at 04:43AM +01, Lars Ingebrigtsen wrote:

> Sean Whitton <spwhitton@spwhitton.name> writes:
>
>> There was previously some suggestion to reserve M-o as a prefix map for
>> third-party packages like Magit, to avoid a situation like the recent
>> one with C-x g.
>>
>> It occurs to me that in that case, Emacs could still bind a few keys
>> under the prefix, like M-o M-o, for core functionality, but leave the
>> rest open.
>
> I'd rather leave it unbound for users.

In the sense that C-c LETTER is reserved for users, or something weaker?

-- 
Sean Whitton

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Lars Ingebrigtsen]

Sean Whitton <spwhitton@spwhitton.name> writes:

> In the sense that C-c LETTER is reserved for users, or something weaker?

I'm not sure.  :-)  There's been many suggestions as to what to use
`M-o' for, and I don't think there's any consensus yet.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Thu, 18 Mar 2021 05:16:03 +0100
> 
> Lars Ingebrigtsen <larsi@gnus.org> writes:
> 
> > The test period is now over, so we should now discuss whether to make
> > the change permanent, and if so, whether we should bind any of the
> > affected commands to something else.
> 
> We've now had a one week discussion period, so I've made some decisions.
> 
> 1) Nobody wanted to keep the global `M-o' binding (facemenu), so I've
> removed that.
> 
> 2) There was no clamouring to keep a global binding for `center-line'
> and `center-paragraph', so those that find those commands extremely
> useful will have to bind it themselves.
> 
> 3) 99.7% of the discussion involved whether `font-lock-fontify-block'
> was useful or not.  Apparently most people had never heard of it, but
> when they did hear of it, several said (I'm paraphrasing) "that sounds
> quite useful indeed, but it's a bit odd" (i.e., the "block" it fontifies
> doesn't seem ideal).  Gregory suggested a variation on it, and that
> seems to work even better, so I've included it and bound it to
> `C-x x f'.  (But those that really want `font-lock-fontify-block' will
> have to bind it themselves.)
> 
> I've now pushed these changes.  (And we no longer need to preload
> facemenu, I guess, so I'll try to remove that, but it's not totally
> trivial.)

Fair enough, but please include in NEWS a recipe to get back the old
behavior.  Is the following enough?

  (require 'facemenu)
  (define-key global-map "\M-o" 'facemenu-keymap)

Also, if facemenu isn't preloaded anymore, why does it still use
purecopy?

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Alfred M. Szmidt]

   1) Nobody wanted to keep the global `M-o' binding (facemenu), so I've
   removed that.

How do you know? You ask a very small sample of users.  I recall that
Eli used M-o in other context than enriched-mode.

   2) There was no clamouring to keep a global binding for `center-line'
   and `center-paragraph', so those that find those commands extremely
   useful will have to bind it themselves.

Eh? How much do people have to complain that center-FOO should be
keept for it to be keept somewhere?  Or is user input totally ignored
here?  You are constantly dismissing any user input.

There had at least three requests for center-FOO to be bound to
at least something else.

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Eli Zaretskii]

> Date: Thu, 18 Mar 2021 11:00:37 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> Fair enough, but please include in NEWS a recipe to get back the old
> behavior.  Is the following enough?
> 
>   (require 'facemenu)
>   (define-key global-map "\M-o" 'facemenu-keymap)

Actually, it looks like the following is needed to get back the old
bindings:

  (require 'facemenu)
  (define-key global-map "\M-o" 'facemenu-keymap)
  (define-key facemenu-keymap "\es" 'center-line)
  (define-key facemenu-keymap "\eS" 'center-paragraph)

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Jean Louis]

* Lars Ingebrigtsen <larsi@gnus.org> [2021-03-18 07:17]:
> So I think it was a moderately successful experiment, and we should use
> this way of trying out user interface changes more.  The time periods
> seem OK to me -- one month for the experiment, and then one additional
> week for discussion at the end (so I guess it's really more like five
> weeks).

For your kind considerations:

You should not make it a strict rule just because the experiment
worked well. It maybe worked well because not many developers use the
enriched mode.

You should rather make the experiment flexible and not bound to some
period of time based on first experiment.

Additionally, you cannot get and did not get a feedback from common
users, you got it only from those using the development version.

Use the feeling on how long the period of test should be, as some more
common keybindings would cause more problems. And some keybindings you
would never get reported back as developers may not be the users of
those.

Jean

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2021-03-18 12:03]:
> Fair enough, but please include in NEWS a recipe to get back the old
> behavior.  Is the following enough?
> 
>   (require 'facemenu)
>   (define-key global-map "\M-o" 'facemenu-keymap)

Thank you, that is what I did not know. But I would rather define the
key only for enriched mode.

(require 'facemenu)
(define-key enriched-mode-map "\M-o" 'facemenu-keymap)

Do I really need to use `require' in init file for this?

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Eli Zaretskii]

> Date: Thu, 18 Mar 2021 16:28:10 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, emacs-devel@gnu.org
> 
> (require 'facemenu)
> (define-key enriched-mode-map "\M-o" 'facemenu-keymap)
> 
> Do I really need to use `require' in init file for this?

The recipe I've shown is for getting back all of the old behavior that
was changed, not just the M-o keymap.  The recipe loads facemenu
because it used to be preloaded.  If you don't need that for whatever
you have to do, you can omit loading it.

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Sean Whitton]

Hello,

On Thu 18 Mar 2021 at 05:16AM +01, Lars Ingebrigtsen wrote:

> So I think it was a moderately successful experiment, and we should use
> this way of trying out user interface changes more.  The time periods
> seem OK to me -- one month for the experiment, and then one additional
> week for discussion at the end (so I guess it's really more like five
> weeks).

I often have weeks where I'm too occupied with other things to follow
emacs-devel closely, but I typically catch up, so I'd appreciate a
little bit longer than one week.  Thanks!

-- 
Sean Whitton

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> Fair enough, but please include in NEWS a recipe to get back the old
>> behavior.  Is the following enough?
>> 
>>   (require 'facemenu)
>>   (define-key global-map "\M-o" 'facemenu-keymap)

Yup; I've now added this to NEWS.

> Actually, it looks like the following is needed to get back the old
> bindings:
>
>   (require 'facemenu)
>   (define-key global-map "\M-o" 'facemenu-keymap)
>   (define-key facemenu-keymap "\es" 'center-line)
>   (define-key facemenu-keymap "\eS" 'center-paragraph)

These two functions aren't really related to the facemenu functionality,
so I think that just confuses the issue.  If somebody wants to have a
binding for these two commands, that's presumably orthogonal to whether
they want to have the facemenu-keymap functionality.  So these people
should just put them on `C-c LETTER' or wherever they put things.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Fri, 19 Mar 2021 08:46:38 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Fair enough, but please include in NEWS a recipe to get back the old
> >> behavior.  Is the following enough?
> >> 
> >>   (require 'facemenu)
> >>   (define-key global-map "\M-o" 'facemenu-keymap)
> 
> Yup; I've now added this to NEWS.

Thanks.

> > Actually, it looks like the following is needed to get back the old
> > bindings:
> >
> >   (require 'facemenu)
> >   (define-key global-map "\M-o" 'facemenu-keymap)
> >   (define-key facemenu-keymap "\es" 'center-line)
> >   (define-key facemenu-keymap "\eS" 'center-paragraph)
> 
> These two functions aren't really related to the facemenu functionality,
> so I think that just confuses the issue.  If somebody wants to have a
> binding for these two commands, that's presumably orthogonal to whether
> they want to have the facemenu-keymap functionality.  So these people
> should just put them on `C-c LETTER' or wherever they put things.

We are talking about getting back the old behavior, so we should let
users have _all_ of it back.  We could, of course, clarify that the
last two bindings are unrelated to faces, and that they are needed
only if the user wants them back.

(FWIW, I'm a long-time and happy user of center-line, and was quite
annoyed when it moved from its original M-s to a longer "M-o M-s", but
that's water under the bridge.)

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Gregory Heytings]

>
> (FWIW, I'm a long-time and happy user of center-line, and was quite 
> annoyed when it moved from its original M-s to a longer "M-o M-s", but 
> that's water under the bridge.)
>

In which Emacs version was M-s bound to center-line?  Are you perhaps 
thinking of M-S (aka M-S-s) in enriched-mode, which was (and still is) 
bound to set-justification-center?

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Eli Zaretskii]

> Date: Fri, 19 Mar 2021 09:35:23 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: emacs-devel@gnu.org
> 
> > (FWIW, I'm a long-time and happy user of center-line, and was quite 
> > annoyed when it moved from its original M-s to a longer "M-o M-s", but 
> > that's water under the bridge.)
> 
> In which Emacs version was M-s bound to center-line?

All the versions up until 23.1.  From v23.1's NEWS:

  ** In Text mode, `center-line' and `center-paragraph' are rebound from
  `M-s' and `M-S' to global keys `M-o M-s' and `M-o M-S' on the global
  prefix map `M-o', which is intended for such formatting commands.

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Gregory Heytings]

[-- Attachment #1: Type: text/plain, Size: 608 bytes --]


>
> 3) 99.7% of the discussion involved whether `font-lock-fontify-block' 
> was useful or not.  Apparently most people had never heard of it, but 
> when they did hear of it, several said (I'm paraphrasing) "that sounds 
> quite useful indeed, but it's a bit odd" (i.e., the "block" it fontifies 
> doesn't seem ideal).  Gregory suggested a variation on it, and that 
> seems to work even better, so I've included it and bound it to `C-x x 
> f'.  (But those that really want `font-lock-fontify-block' will have to 
> bind it themselves.)
>

Thank you!  I suggest two minor corrections, see attached patch.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-diff; name=0001-etc-NEWS-Small-corrections-for-the-new-command-font-.patch, Size: 1501 bytes --]

From c0afa1c3c69a0194f7eb7ec4ce890125a512f14e Mon Sep 17 00:00:00 2001
From: Gregory Heytings <gregory@heytings.org>
Date: Fri, 19 Mar 2021 12:56:15 +0000
Subject: [PATCH] * etc/NEWS: Small corrections for the new command
 'font-lock-update'

---
 etc/NEWS | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/etc/NEWS b/etc/NEWS
index 6dda3423c1..fee0009da6 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -254,8 +254,8 @@ search buffer due to too many matches being highlighted.
 The 'C-x x' keymap now holds keystrokes for various buffer-oriented
 commands.  The new keystrokes are 'C-x x g' ('revert-buffer'),
 'C-x x r' ('rename-buffer'), 'C-x x u' ('rename-uniquely'), 'C-x x n'
-('clone-buffer'), 'C-x x i' ('insert-buffer') and 'C-x x t'
-('toggle-truncate-lines').
+('clone-buffer'), 'C-x x i' ('insert-buffer'), 'C-x x t'
+('toggle-truncate-lines') and 'C-x x f' ('font-lock-update').
 
 ---
 ** Commands 'set-frame-width' and 'set-frame-height' can now get their
@@ -2270,7 +2270,7 @@ Use 'M-x center-line' and 'M-x center-paragraph' instead.
 
 ** The 'M-o M-o' global binding has been removed.
 Use 'M-x font-lock-fontify-block' instead, or the new 'C-x x f'
-command, which toggles fontification in the current buffer.
+command, which updates the syntax highlighting in the current buffer.
 
 ** In 'f90-mode', the backslash character ('\') no longer escapes.
 For about a decade, the backslash character has no longer had a
-- 
2.30.1

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Lars Ingebrigtsen]

Gregory Heytings <gregory@heytings.org> writes:

> Thank you!  I suggest two minor corrections, see attached patch.

Thanks; applied to Emacs 28.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> > Actually, it looks like the following is needed to get back the old
>> > bindings:
>> >
>> >   (require 'facemenu)
>> >   (define-key global-map "\M-o" 'facemenu-keymap)
>> >   (define-key facemenu-keymap "\es" 'center-line)
>> >   (define-key facemenu-keymap "\eS" 'center-paragraph)
>> 
>> These two functions aren't really related to the facemenu functionality,
>> so I think that just confuses the issue.  If somebody wants to have a
>> binding for these two commands, that's presumably orthogonal to whether
>> they want to have the facemenu-keymap functionality.  So these people
>> should just put them on `C-c LETTER' or wherever they put things.
>
> We are talking about getting back the old behavior, so we should let
> users have _all_ of it back.  We could, of course, clarify that the
> last two bindings are unrelated to faces, and that they are needed
> only if the user wants them back.

If the user just wants to get center-line back with the old binding
(without doing the facemap thing), they'll have to say something like:

(global-set-key "\M-o" (let ((map (make-sparse-keymap)))
                         (define-key map "\es" 'center-line)
                         map))

Which is why I'd rather not talk about center-line in the context of
facemenu.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Andreas Schwab]

On Mär 20 2021, Lars Ingebrigtsen wrote:

> If the user just wants to get center-line back with the old binding
> (without doing the facemap thing), they'll have to say something like:
>
> (global-set-key "\M-o" (let ((map (make-sparse-keymap)))
>                          (define-key map "\es" 'center-line)
>                          map))

What's wrong with (define-key global-map "\M-o\M-s" 'center-line)?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Lars Ingebrigtsen]

Andreas Schwab <schwab@linux-m68k.org> writes:

> What's wrong with (define-key global-map "\M-o\M-s" 'center-line)?

Even better.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Gregory Heytings]

>> What's wrong with (define-key global-map "\M-o\M-s" 'center-line)?
>
> Even better.
>

And (global-set-key (kbd "M-o M-s") 'center-line)? ;-)

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Sat, 20 Mar 2021 08:58:59 +0100
> 
> > We are talking about getting back the old behavior, so we should let
> > users have _all_ of it back.  We could, of course, clarify that the
> > last two bindings are unrelated to faces, and that they are needed
> > only if the user wants them back.
> 
> If the user just wants to get center-line back with the old binding
> (without doing the facemap thing), they'll have to say something like:
> 
> (global-set-key "\M-o" (let ((map (make-sparse-keymap)))
>                          (define-key map "\es" 'center-line)
>                          map))
> 
> Which is why I'd rather not talk about center-line in the context of
> facemenu.

We aren't under obligation to describe any possible combination of old
behaviors.  It is enough to show how to get the old behavior in its
entirety.  So I've now went ahead and made that change in NEWS.

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Paul W. Rankin via Emacs development discussions.]

Unless I'm fundamentally missing something, the new command font-lock-update only duplicates the functionality of existing command font-lock-fontify-buffer, and adds some confusion...

When font-lock-mode is active and font-lock-update is called with ARG, the command unfontifies the buffer and deactivates font-lock-mode. Wut? Makes no sense for a command called font-lock-update...

The docstring states that font-lock-update only fontifies the accessible portion of the buffer. This isn't true; the command calls font-lock-fontify-region, which widens the restriction unless font-lock-dont-widen is non-nil, which is nil by default.

Given the removal of M-o M-o to fontify block, the addition of C-x x f to update fontification is a good idea, but let's just have it call font-lock-fontify-buffer and get rid of this command.

If someone wants specifically to toggle font-lock-mode, they'd just call M-x font-lock-mode. If they're toggling font-lock-mode enough for it to become an issue, they'd bind that to a key.

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Gregory Heytings]

>
> Unless I'm fundamentally missing something, the new command 
> font-lock-update only duplicates the functionality of existing command 
> font-lock-fontify-buffer, and adds some confusion...
>

It does not duplicate the fonctionality, font-lock-fontify-buffer is 
bugged, font-lock-update isn't (hopefully).  To see one of its bugs, open 
your .emacs file, M-x font-lock-mode (which turns font-lock-mode off), M-x 
font-lock-fontify-buffer.  Now change some characters: the fontification 
remains.

>
> When font-lock-mode is active and font-lock-update is called with ARG, 
> the command unfontifies the buffer and deactivates font-lock-mode. Wut? 
> Makes no sense for a command called font-lock-update...
>

It allows you to toggle font-lock-mode correctly, which M-x font-lock-mode 
can't do.  Try the following: emacs -Q, unless, M-., M-h, M-w, C-x b RET, 
M-x text-mode, C-y, M-x font-lock-mode.

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Paul W. Rankin via Emacs development discussions.]

> On 24 Mar 2021, at 8:07 am, Gregory Heytings <gregory@heytings.org> wrote:
> 
> 
>> 
>> Unless I'm fundamentally missing something, the new command font-lock-update only duplicates the functionality of existing command font-lock-fontify-buffer, and adds some confusion...
>> 
> 
> It does not duplicate the fonctionality, font-lock-fontify-buffer is bugged, font-lock-update isn't (hopefully).  To see one of its bugs, open your .emacs file, M-x font-lock-mode (which turns font-lock-mode off), M-x font-lock-fontify-buffer.  Now change some characters: the fontification remains.
> 
>> 
>> When font-lock-mode is active and font-lock-update is called with ARG, the command unfontifies the buffer and deactivates font-lock-mode. Wut? Makes no sense for a command called font-lock-update...
>> 
> 
> It allows you to toggle font-lock-mode correctly, which M-x font-lock-mode can't do.  Try the following: emacs -Q, unless, M-., M-h, M-w, C-x b RET, M-x text-mode, C-y, M-x font-lock-mode.

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.

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Gregory Heytings]

>
> 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.
>

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.

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Paul W. Rankin via Emacs development discussions.]

> On 24 Mar 2021, at 9:13 am, Gregory Heytings <gregory@heytings.org> wrote:
> 
>> 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.
> 
> 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.

For sure. If you can, please link me to the lists.gnu.org message?

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Gregory Heytings]

>>> 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.
>>
>> 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.
>
> For sure. If you can, please link me to the lists.gnu.org message?
>

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 .

By the way, what actual problems do you see in font-lock-update?  Do you 
see cases where it produces unexpected results?

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Paul W. Rankin via Emacs development discussions.]

> On 24 Mar 2021, at 6:01 pm, Gregory Heytings <gregory@heytings.org> wrote:
> 
>>>> 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.
>>> 
>>> 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.
>> 
>> For sure. If you can, please link me to the lists.gnu.org message?
>> 
> 
> 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. From 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.

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Gregory Heytings]

>> 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. From the docstring I'm not sure if that was 
> your intention?
>

Of course it was my intention, the docstring says "With prefix ARG, toggle 
Font Lock mode."  Isn't that clear enough?

>
> 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.
>

You mean, it's the word "update" in the name of the command you don't 
like?  It's supposed to be a "dwim"-like command:

- when font-lock-mode is disabled, enable it and fontify buffer
- when font-lock-mode is enabled, refontify buffer
- with a prefix argument, toggle font-lock-mode "correctly" (i.e. making sure that the buffer is unfontified when disabling)

Whe font-lock-mode is enabled, you can turn it off with C-u C-x x f. 
When it is disabled, you can turn it on with C-u C-x x f, or simply C-x x 
f.

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Paul W. Rankin via Emacs development discussions.]

> - with a prefix argument, toggle font-lock-mode "correctly" (i.e. making sure that the buffer is unfontified when disabling)

This part is what shouldn't be in there. Calling `font-lock-unfontify-region' is the nuclear option to remove all text properties, including those that font lock doesn't "own", so to speak. As I mentioned before, I think you're getting confused about how font-lock and text properties work, and so what you're saying is "correct" is not so. Deactivating font-lock-mode does not and should not remove all text properties -- only those with the `(fontified . t)' property.

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Gregory Heytings]

>> - with a prefix argument, toggle font-lock-mode "correctly" (i.e. 
>> making sure that the buffer is unfontified when disabling)
>
> This part is what shouldn't be in there. Calling 
> `font-lock-unfontify-region' is the nuclear option to remove all text 
> properties, including those that font lock doesn't "own", so to speak.
>

Does it?  AFAICS, font-lock-unfontify-region does not "remove _all_ text 
properties", it uses remove-list-of-text-properties, which "removes _some_ 
properties from text", namely those of font-lock-mode.

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Paul W. Rankin via Emacs development discussions.]

> Does it?  AFAICS, font-lock-unfontify-region does not "remove _all_ text properties", it uses remove-list-of-text-properties, which "removes _some_ properties from text", namely those of font-lock-mode.

Sure, you're right that it does not remove *all* text properties per se. It removes, let's say, "all that it can" which is more than "all that is intended".

In my last mail I was attempting to explain what you're seeing in the second issue you described:

> It allows you to toggle font-lock-mode correctly, which M-x font-lock-mode can't do.  Try the following: emacs -Q, unless, M-., M-h, M-w, C-x b RET, M-x text-mode, C-y, M-x font-lock-mode.

This is again correct behaviour. When you yank the defun from an emacs-lisp-mode buffer into a text-mode buffer, you're inserting text with (most of) its text properties, except for the property `(fontified . t)' because within the context of *this* buffer, the text properties have not been applied with font-lock-mode and so this would be false and prevent font-lock from doing its work.

To see how this works, try the reverse: yank a defun from a text-mode-buffer (i.e. no syntax highlighting) into an emacs-lisp-mode buffer with font-lock-mode active. Since there is no `(fontified . t)' property you'll see font-lock go to work and the yanked text will be fontified.

If you dislike this behaviour that's also fine, there's a user option for that: yank-excluded-properties, which you can set to t and have what you expect as correct behaviour (which fwiw is what I have it set to).

I hope this clears things up for you. Unless there's any outside objection I'm going to fix up the command in master to reflect as pasted above.

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Gregory Heytings]

>> Does it?  AFAICS, font-lock-unfontify-region does not "remove _all_ 
>> text properties", it uses remove-list-of-text-properties, which 
>> "removes _some_ properties from text", namely those of font-lock-mode.
>
> Sure, you're right that it does not remove *all* text properties per se. 
> It removes, let's say, "all that it can" which is more than "all that is 
> intended".
>

Please provide a recipe to demonstrate when this actually matters.

>> It allows you to toggle font-lock-mode correctly, which M-x 
>> font-lock-mode can't do.  Try the following: emacs -Q, unless, M-., 
>> M-h, M-w, C-x b RET, M-x text-mode, C-y, M-x font-lock-mode.
>
> This is again correct behaviour.  When you yank the defun from an 
> emacs-lisp-mode buffer into a text-mode buffer, you're inserting text 
> with (most of) its text properties, except for the property `(fontified 
> . t)' because within the context of *this* buffer, the text properties 
> have not been applied with font-lock-mode and so this would be false and 
> prevent font-lock from doing its work.
>

This is not the problem here.  The problem is that M-x font-lock-mode 
(last part of the recipe) is supposed to turn font-lock-mode off, yet the 
font-lock-mode fontification remains.

>
> I hope this clears things up for you. Unless there's any outside 
> objection I'm going to fix up the command in master to reflect as pasted 
> above.
>

I strongly object, there's no need to "fix" a working command to make it 
worse.

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Paul W. Rankin via Emacs development discussions.]

> On 24 Mar 2021, at 10:12 pm, Gregory Heytings <gregory@heytings.org> wrote:
> 
> 
>>> Does it?  AFAICS, font-lock-unfontify-region does not "remove _all_ text properties", it uses remove-list-of-text-properties, which "removes _some_ properties from text", namely those of font-lock-mode.
>> 
>> Sure, you're right that it does not remove *all* text properties per se. It removes, let's say, "all that it can" which is more than "all that is intended".
>> 
> 
> Please provide a recipe to demonstrate when this actually matters.

Programs should do what they're intended to.

>>> It allows you to toggle font-lock-mode correctly, which M-x font-lock-mode can't do.  Try the following: emacs -Q, unless, M-., M-h, M-w, C-x b RET, M-x text-mode, C-y, M-x font-lock-mode.
>> 
>> This is again correct behaviour.  When you yank the defun from an emacs-lisp-mode buffer into a text-mode buffer, you're inserting text with (most of) its text properties, except for the property `(fontified . t)' because within the context of *this* buffer, the text properties have not been applied with font-lock-mode and so this would be false and prevent font-lock from doing its work.
>> 
> 
> This is not the problem here.  The problem is that M-x font-lock-mode (last part of the recipe) is supposed to turn font-lock-mode off, yet the font-lock-mode fontification remains.

I have quite fully explained how that is not the case as per your examples. The "font-lock-mode fontification" does not remain, only text properties that are not added by font-lock remain, and as such why should turning off font-lock remove these? As previously noted, you are confusing text properties and font-lock. Font-lock is only one method to manipulate text properties.

Please read the Elisp Info manual chapters on Font Lock and Text Properties.

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Gregory Heytings]

>> Please provide a recipe to demonstrate when this actually matters.
>
> Programs should do what they're intended to.
>

That's not a recipe... and what you think is intended is perhaps not what 
I intended.

>
> I have quite fully explained how that is not the case as per your 
> examples. The "font-lock-mode fontification" does not remain, only text 
> properties that are not added by font-lock remain, and as such why 
> should turning off font-lock remove these? As previously noted, you are 
> confusing text properties and font-lock. Font-lock is only one method to 
> manipulate text properties.
>

Apparently we're miscommunicating.  When the current command is used to 
turn font lock off with a prefix argument, it does something equivalent to 
"C-x x f M-x font-lock-mode", that is, it first updates the fontification 
of the buffer to make it correspond to the mode, then turns font-lock-mode 
off (which removes the fontification that was just added).  That's the "do 
what I mean": when I turn font-lock-mode off in a buffer, I want to remove 
the fontification.

In other words, it should be equivalent to the following:

(defun font-lock-update (&optional arg)
   "Updates the syntax highlighting in this buffer.
Refontify the accessible portion of the buffer, or enable Font Lock mode
if it is disabled.  With prefix ARG, toggle Font Lock mode."
   (interactive "P")
   (save-excursion
     (font-lock-fontify-region (point-min) (point-max))
     (if (or arg (not font-lock-mode))
         (font-lock-mode 'toggle))))

except that this one is much slower.

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Stefan Monnier]

>> Unless I'm fundamentally missing something, the new command
>> font-lock-update only duplicates the functionality of existing command
>> font-lock-fontify-buffer, and adds some confusion...
>>
>
> It does not duplicate the fonctionality, font-lock-fontify-buffer is bugged,
> font-lock-update isn't (hopefully).  To see one of its bugs, open your
> .emacs file, M-x font-lock-mode (which turns font-lock-mode off), M-x
> font-lock-fontify-buffer.  Now change some characters: the
> fontification remains.

BTW, the problem with the above is not whether this behavior is
"expected" or not (after all, the behavior of known bugs is also
arguably "expected").

The question is whether it's *desirable*, and some concrete use-cases to
back up the claim would be very handy.

So far, the only use-case I know of is the one where font-lock-keywords
is nil, so the "fontification" ends up *removing* faces.


        Stefan

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Stefan Monnier]

> properties -- only those with the `(fontified . t)' property.

Font-lock doesn't pay attention to `fontified`.
`fontified` is used by `jit-lock` only.


        Stefan

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Paul W. Rankin via Emacs development discussions.]

> On 24 Mar 2021, at 11:09 pm, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> 
>> properties -- only those with the `(fontified . t)' property.
> 
> Font-lock doesn't pay attention to `fontified`.
> `fontified` is used by `jit-lock` only.

It seems that `font-lock-mode' eventually calls `font-lock-default-function' which calls `font-lock-mode-internal' which sets `font-lock-fontify-buffer-function' to `jit-lock-refontify' (in e.g. emacs-lisp-mode) which would explain what we're seeing?

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Paul W. Rankin via Emacs development discussions.]

> On 24 Mar 2021, at 11:07 pm, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> 
>>> Unless I'm fundamentally missing something, the new command
>>> font-lock-update only duplicates the functionality of existing command
>>> font-lock-fontify-buffer, and adds some confusion...
>>> 
>> 
>> It does not duplicate the fonctionality, font-lock-fontify-buffer is bugged,
>> font-lock-update isn't (hopefully).  To see one of its bugs, open your
>> .emacs file, M-x font-lock-mode (which turns font-lock-mode off), M-x
>> font-lock-fontify-buffer.  Now change some characters: the
>> fontification remains.
> 
> BTW, the problem with the above is not whether this behavior is
> "expected" or not (after all, the behavior of known bugs is also
> arguably "expected").
> 
> The question is whether it's *desirable*, and some concrete use-cases to
> back up the claim would be very handy.
> 
> So far, the only use-case I know of is the one where font-lock-keywords
> is nil, so the "fontification" ends up *removing* faces.

There are two pretty separate issues here;

One is the nuances of font-lock vs text properties, on which we've gone a bit around in circles.

The other is much more trivial: that a command on the default C-x map should only do what its name implies (with no need to duplicate functionality of calling the mode itself).

The difficulty of the former has over-inflated the importance of the latter.

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Gregory Heytings]

>
> The other is much more trivial: that a command on the default C-x map 
> should only do what its name implies (with no need to duplicate 
> functionality of calling the mode itself).
>

If it's the name "font-lock-update" that you don't like, what do you think 
of "font-lock-update-or-toggle"?

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Stefan Monnier]

> It seems that `font-lock-mode' eventually calls `font-lock-default-function'
> which calls `font-lock-mode-internal' which sets
> `font-lock-fontify-buffer-function' to `jit-lock-refontify' (in
> e.g. emacs-lisp-mode) which would explain what we're seeing?

These are internal implementation details, which depend also on things
like `font-lock-support-mode`.
I was just pointing out that your understanding of the interaction between
font-lock and the `fontified` property is not right.

And that's a problem in this discussion because the "expected" behavior
of `font-lock-fontify-block` and `font-lock-fontify-buffer` (and sadly,
to a lesser extent also `font-lock-update`) is by and large accidentally
defined by the implementation rather than by any
human-level description.


        Stefan

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Paul W. Rankin via Emacs development discussions.]

> On 25 Mar 2021, at 1:14 am, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> 
>> It seems that `font-lock-mode' eventually calls `font-lock-default-function'
>> which calls `font-lock-mode-internal' which sets
>> `font-lock-fontify-buffer-function' to `jit-lock-refontify' (in
>> e.g. emacs-lisp-mode) which would explain what we're seeing?
> 
> These are internal implementation details, which depend also on things
> like `font-lock-support-mode`.
> I was just pointing out that your understanding of the interaction between
> font-lock and the `fontified` property is not right.
> 
> And that's a problem in this discussion because the "expected" behavior
> of `font-lock-fontify-block` and `font-lock-fontify-buffer` (and sadly,
> to a lesser extent also `font-lock-update`) is by and large accidentally
> defined by the implementation rather than by any
> human-level description.

I'm responding to a very narrow issue Gregory raised, which was that yanking a defun from an emacs-lisp-mode into a text-mode-buffer, then deactivating font-lock-mode did not remove what he considers to be fontification. To me, this makes sense because text-mode does not fontify most text, thus any text properties on text would not be associated with font-lock and so there's no expectation they be removed.

The focus on the fontified property is more for demonstration of why this is the case when the action is reversed.

But again, Emacs already has the solution for anyone who finds this unexpected, which is the option `yank-excluded-properties'.

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Stefan Monnier]

> I'm responding to a very narrow issue Gregory raised, which was that yanking
> a defun from an emacs-lisp-mode into a text-mode-buffer, then deactivating
> font-lock-mode did not remove what he considers to be fontification. To me,
> this makes sense because text-mode does not fontify most text, thus any text

Yes, but the question is not whether it makes sense but whether it's desirable.
If it's not desirable than it doesn't matter whether we provide/preserve
this behavior.


        Stefan

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Paul W. Rankin via Emacs development discussions.]

> On 25 Mar 2021, at 1:40 am, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> 
>> I'm responding to a very narrow issue Gregory raised, which was that yanking
>> a defun from an emacs-lisp-mode into a text-mode-buffer, then deactivating
>> font-lock-mode did not remove what he considers to be fontification. To me,
>> this makes sense because text-mode does not fontify most text, thus any text
> 
> Yes, but the question is not whether it makes sense but whether it's desirable.
> If it's not desirable than it doesn't matter whether we provide/preserve
> this behavior.

I see. Yes I think it's desirable. For me the desirable aspect is the distinction between text props and font-lock. Moreover I think the degree to which a thing makes sense also contributes to its desirability (if that makes sense).

And the undesirable aspects of the font-lock-update command the misleading side-effects: that it removed things and/or deactivated a minor mode. Put these things in other commands if they're going on C-x.

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Eli Zaretskii]

> Date: Wed, 24 Mar 2021 19:09:33 +1000
> Cc: emacs-devel@gnu.org
> From:  "Paul W. Rankin" via "Emacs development discussions." <emacs-devel@gnu.org>
> 
> > 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?)

Of course I use yank-excluded-properties!  But manually tweaking that
variable each time I intend to yank some text (which would require
first to find out which properties are in that text) is much less
convenient than typing "M-o M-o", don't you agree?  And adding face
properties permanently to yank-excluded-properties would get in the
way of the use cases where I do want faces to be copied.

Btw, the "without font-lock-mode active" part is not the situation I
was talking about.  Remember: global-font-lock-mode is now t by
default, so bumping into a buffer where font-lock-mode isn't active is
quite hard...

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Stefan Monnier]

>>> I'm responding to a very narrow issue Gregory raised, which was that yanking
>>> a defun from an emacs-lisp-mode into a text-mode-buffer, then deactivating
>>> font-lock-mode did not remove what he considers to be fontification. To me,
>>> this makes sense because text-mode does not fontify most text, thus any text
>> Yes, but the question is not whether it makes sense but whether it's desirable.
>> If it's not desirable than it doesn't matter whether we provide/preserve
>> this behavior.
> I see. Yes I think it's desirable.

Could you explain why you think it's desirable, e.g. with concrete use cases?

> For me the desirable aspect is the distinction between text props and
> font-lock.

I don't know what you mean by that.


        Stefan

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Stefan Monnier]

> Btw, the "without font-lock-mode active" part is not the situation I
> was talking about.  Remember: global-font-lock-mode is now t by
> default, so bumping into a buffer where font-lock-mode isn't active is
> quite hard...

FWIW, `text-mode` *is* in that category, which is why
`font-lock-fontify-block` does something (i.e. erase `face` properties).

In `text-mode`, `font-lock-mode` is t (if you use default config) yet
font-lock is not actually activated because `font-lock-keywords` is nil.
This is because of the `font-lock-specified-p` test in
`font-lock-default-function`.

I don't much like this distinction between "`font-lock-mode` is non-nil"
and "the font-lock machinery is actually activated".


        Stefan

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: "Paul W. Rankin" <pwr@bydasein.com>,  gregory@heytings.org,
>   emacs-devel@gnu.org
> Date: Wed, 24 Mar 2021 17:58:07 -0400
> 
> In `text-mode`, `font-lock-mode` is t (if you use default config) yet
> font-lock is not actually activated because `font-lock-keywords` is nil.
> This is because of the `font-lock-specified-p` test in
> `font-lock-default-function`.

That's your interpretation of "font-lock-mode active"?  But I'm not
sure that's what Paul meant: he never explained that part.

Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

[Stefan Monnier]

> That's your interpretation of "font-lock-mode active"?

By and large, yes: in the literal sens of "active" meaning "does
something", font-lock-mode is not "active".


        Stefan