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