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

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]

> 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

[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

[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

[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]

> 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

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

[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"?

'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

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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