Recentish C-s M-y change

Recentish C-s M-y change

[Lars Ingebrigtsen]

In Emacs 27, putting something in the kill ring and then `C-s M-y' would
yank that text to use when isearching.  This now enters a prompt instead
where I can autocomplete over all the things in the kill ring.

This is good functionality, and I can use `C-s C-y' to get the old
behaviour, but the `C-s M-y' is deeply ingrained in my muscle memory,
and it's tripping me up all the time.  (And if it's doing that to me,
it'll probably annoy somebody else, too.)

Could we move the new `C-s M-y' functionality somewhere else and retain
the old `C-s M-y' binding?

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

Re: Recentish C-s M-y change

[Juri Linkov]

> In Emacs 27, putting something in the kill ring and then `C-s M-y' would
> yank that text to use when isearching.  This now enters a prompt instead
> where I can autocomplete over all the things in the kill ring.

This was changed according to this comment in isearch-yank-pop:

  Fall back on `isearch-yank-kill' for the benefits of people
  who are used to the old behavior of `M-y' in isearch mode.
  In future, this fallback may be changed if we ever change
  `yank-pop' to do something like the kill-ring-browser.

The future is now.

> This is good functionality, and I can use `C-s C-y' to get the old
> behaviour, but the `C-s M-y' is deeply ingrained in my muscle memory,
> and it's tripping me up all the time.  (And if it's doing that to me,
> it'll probably annoy somebody else, too.)
>
> Could we move the new `C-s M-y' functionality somewhere else and retain
> the old `C-s M-y' binding?

This has been discussed many times, and the most promising solution is
to add a single variable that will define whether the user prohibits
changing the definitions of traditional keys.  When its value is nil,
then with a new release the user gets new keybindings that are more
logical and consistent with other keybindings and new functionality.
However, when you set it to t, then you get all old keybindings untouched.

Re: Recentish C-s M-y change

[Juri Linkov]

> This has been discussed many times, and the most promising solution is
> to add a single variable that will define whether the user prohibits
> changing the definitions of traditional keys.  When its value is nil,
> then with a new release the user gets new keybindings that are more
> logical and consistent with other keybindings and new functionality.
> However, when you set it to t, then you get all old keybindings untouched.

Or better to add a new theme that would restore the old values:

  (deftheme back-to-emacs-27)

  (define-key isearch-mode-map "\M-y" 'isearch-yank-kill)
  (setq read-char-choice-use-read-key t)
  (setq y-or-n-p-use-read-key t)
  ...

Then if you don't want to revert all changes, it's easy
to pick some of them and copy to the init file.

Re: Recentish C-s M-y change

[Filipp Gunbin]

On 28/12/2020 10:45 +0200, Juri Linkov wrote:

>> Could we move the new `C-s M-y' functionality somewhere else and retain
>> the old `C-s M-y' binding?
>
> This has been discussed many times, and the most promising solution is
> to add a single variable that will define whether the user prohibits
> changing the definitions of traditional keys.  When its value is nil,
> then with a new release the user gets new keybindings that are more
> logical and consistent with other keybindings and new functionality.
> However, when you set it to t, then you get all old keybindings untouched.

Why can't we just add another key for the new "yank from kill ring"?
The new behaviour is indeed annoying when you don't expect it.

Filipp

Re: Recentish C-s M-y change

[Clément Pit-Claudel]

On 12/28/20 12:30 PM, Filipp Gunbin wrote:
> On 28/12/2020 10:45 +0200, Juri Linkov wrote:
> 
>>> Could we move the new `C-s M-y' functionality somewhere else and retain
>>> the old `C-s M-y' binding?
>>
>> This has been discussed many times, and the most promising solution is
>> to add a single variable that will define whether the user prohibits
>> changing the definitions of traditional keys.  When its value is nil,
>> then with a new release the user gets new keybindings that are more
>> logical and consistent with other keybindings and new functionality.
>> However, when you set it to t, then you get all old keybindings untouched.
> 
> Why can't we just add another key for the new "yank from kill ring"?
> The new behaviour is indeed annoying when you don't expect it.

I imagine C-s M-y was chosen for consistency with the usual M-y binding?

Re: Recentish C-s M-y change

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

  > I imagine C-s M-y was chosen for consistency with the usual M-y binding?

"Consistency" is not quite correct.  I used M-y for this because (1)
the operation is comparable to yanking and (2) the usual binding of
M-y was never useful after C-s.

In recent years, we have given several control characters a
special meaning after C-s.  Most of those special meanings are not
useful for me, but there were some that I used to type often
to exit the search.  Now that no longer works.

-- 
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: Recentish C-s M-y change

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> This has been discussed many times, and the most promising solution is
> to add a single variable that will define whether the user prohibits
> changing the definitions of traditional keys.

I don't think that's a feasible solution -- some changed keybindings are
fine (because nobody are using them) and some are annoying.  The only
way to find out which is which is to try and see whether somebody says
"eep".

And it seems like we've gotten three "eep"s on this one, so I think it's
time to admit that this one didn't work out, and restore the old
keybinding.  (And move the new functionality to some new key binding.)

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

Re: Recentish C-s M-y change

[Juri Linkov]

>> This has been discussed many times, and the most promising solution is
>> to add a single variable that will define whether the user prohibits
>> changing the definitions of traditional keys.
>
> I don't think that's a feasible solution -- some changed keybindings are
> fine (because nobody are using them) and some are annoying.  The only
> way to find out which is which is to try and see whether somebody says
> "eep".
>
> And it seems like we've gotten three "eep"s on this one, so I think it's
> time to admit that this one didn't work out, and restore the old
> keybinding.  (And move the new functionality to some new key binding.)

To tell the truth, after making this change I noticed that I have the same
habit of using 'C-s M-y' to get the last kill ring entry.  But I quickly
relearned it because objectively 'C-s C-y' is a better keybinding to do
the same - you don't need to press a different key modifier.

Such changes of keybindings are not something new: in 2011 we changed
'C-s M-y' from 'isearch-yank-kill' to 'isearch-yank-pop', and also
in 2011 changed 'C-s C-y' from 'isearch-yank-line' to 'isearch-yank-kill'
that was a more fundamental change.

Of course, if after trying 'C-s C-y', you'd still prefer the old 'C-s M-y',
we could revert this change, but this would be a step backwards.

RE: Recentish C-s M-y change

[Drew Adams]

> > And it seems like we've gotten three "eep"s on this one, so I think it's
> > time to admit that this one didn't work out, and restore the old
> > keybinding.  (And move the new functionality to some new key binding.)
> 
> To tell the truth, after making this change I noticed that I have the same
> habit of using 'C-s M-y' to get the last kill ring entry.  But I quickly
> relearned it because objectively 'C-s C-y' is a better keybinding to do
> the same - you don't need to press a different key modifier.
> 
> Such changes of keybindings are not something new: in 2011 we changed
> 'C-s M-y' from 'isearch-yank-kill' to 'isearch-yank-pop', and also
> in 2011 changed 'C-s C-y' from 'isearch-yank-line' to 'isearch-yank-kill'
> that was a more fundamental change.
> 
> Of course, if after trying 'C-s C-y', you'd still prefer the old 'C-s M-y',
> we could revert this change, but this would be a step backwards.

Personally, I use `C-s C-y' as a prefix key for
several different yank commands.  So that's another
reason I'm not in favor of moving the longstanding
`C-s M-y' behavior to `C-s C-y'.

(And with luck Emacs itself might someday want to
use `C-s C-y' as a prefix key for yank commands.)

For users, reverting this change "would be a step
backwards" only in the sense of reverting an
unsolicited step backward.

Re: Recentish C-s M-y change

[Jean Louis]

* Drew Adams <drew.adams@oracle.com> [2020-12-29 20:26]:
> Personally, I use `C-s C-y' as a prefix key for
> several different yank commands.  So that's another
> reason I'm not in favor of moving the longstanding
> `C-s M-y' behavior to `C-s C-y'.

My experience:

When people spoke about C-s M-y I was wondering because I was thinking
I use that and I never had a problem, but then I see I was using C-s
C-y without even thinking.

C-y is yank so C-s C-y is logical.

M-y is yank-pop usually used after C-y, so C-s M-y is logical
extension to same basic feature.

I would not expenct C-s M-y to do something different than what M-y
does without C-s

Re: Recentish C-s M-y change

[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 past I often found it useful to search for same string I
previously searched for, ten insert the same string I previously
inserted.  I would type C-s C-s C-y.

Now, to do that, I have to exit the search in some other way.  But
how?  Nothing pops into my mind.  I know that RET exits a search
nowadays, but I have to pose the question mentally to find that answer.

I am more likely to type C-f C-b, or some other no-op editing command.

-- 
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: Recentish C-s M-y change

[Gregory Heytings via Emacs development discussions.]

>
> Now, to do that, I have to exit the search in some other way.  But how? 
> Nothing pops into my mind.  I know that RET exits a search nowadays, but 
> I have to pose the question mentally to find that answer.
>
> I am more likely to type C-f C-b, or some other no-op editing command.
>

I don't understand your difficulty here.  RET (or C-m) has been bound to 
isearch-exit since Emacs 21 at least; why do you need to use another more 
complex command like C-f C-b to do this?

Re: Recentish C-s M-y change

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

  > I don't understand your difficulty here.  RET (or C-m) has been bound to 
  > isearch-exit since Emacs 21 at least;

Yes, and in all that time it has not worked its way into what I recall
when I need to exit a search.  It never became natural.  I have to dig
around to remember this.

                                          why do you need to use another more 
  > complex command like C-f C-b to do this?

I told you why -- because exiting with RET does not occur to me
in a search.

I almost always exit a search with a command that will execute after
exiting.

-- 
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: Recentish C-s M-y change

[Gregory Heytings via Emacs development discussions.]

>> I don't understand your difficulty here.  RET (or C-m) has been bound 
>> to isearch-exit since Emacs 21 at least;
>
> Yes, and in all that time it has not worked its way into what I recall 
> when I need to exit a search.  It never became natural.  I have to dig 
> around to remember this.
>

I just searched in the trunk history, and apparently C-m/RET, C-y and C-w 
already had their current meaning in 1992.

>> why do you need to use another more complex command like C-f C-b to do 
>> this?
>
> I told you why -- because exiting with RET does not occur to me in a 
> search.
>
> I almost always exit a search with a command that will execute after 
> exiting.
>

May I respectfully suggest you to add the following to your .emacs?

(define-key isearch-mode-map (kbd "C-f") '(lambda () (interactive) (message "Use C-m or RET to exit isearch")))
(define-key isearch-mode-map (kbd "C-b") '(lambda () (interactive) (message "Use C-m or RET to exit isearch")))

I did this when I wanted to unlearn to use the arrow keys to move around, 
that is, to force myself to learn to use C-f/b/n/p.  It's annoying during 
a day or two, but it's the best way I found to enter something into my 
"muscle memory".

>
> It is no surprise to me that I don't remember WHEN various keys were 
> changed from the default meaning, of "exit the search and execute". 
> There have been so many that I don't remember what they all are.
>

In isearch-mode-map at least, the number of changes on control keys during 
the last twenty years or so is very small: C-u (to allow arguments to 
subcommands), C-h (to enable help on the isearch-mode-map keys) and C-x 
(to allow C-x 8 RET).

Re: Recentish C-s M-y change

[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 isearch-mode-map at least, the number of changes on control keys during 
  > the last twenty years or so is very small: C-u (to allow arguments to 
  > subcommands), C-h (to enable help on the isearch-mode-map keys) and C-x 
  > (to allow C-x 8 RET).

Recent discussion shows there has been at least one more -- C-y.
And I recall C-w.  And C-e, I think.

-- 
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: Recentish C-s M-y change

[Gregory Heytings via Emacs development discussions.]

>> In isearch-mode-map at least, the number of changes on control keys 
>> during the last twenty years or so is very small: C-u (to allow 
>> arguments to subcommands), C-h (to enable help on the isearch-mode-map 
>> keys) and C-x (to allow C-x 8 RET).
>
> Recent discussion shows there has been at least one more -- C-y. And I 
> recall C-w.  And C-e, I think.
>

No, as I wrote a few lines above in the message you are replying to, C-y 
and C-w are bound in isearch-mode-map since at least 1992.

C-y was isearch-yank-line until 2011; it then became isearch-yank-kill.

C-w was isearch-yank-word until 2004; it then became 
isearch-yank-word-or-char.

C-e is not (and AFAIK was never) bound in isearch-mode-map, at least not 
in vanilla Emacs.

Anyway, this moves the discussion away from my proposal, which was to bind 
C-u C-y and C-u M-y to the new isearch-yank-pop feature.  I include the 
code (which changes a few lines in isearch.el) again:

(defun isearch-yank-select ()
   (with-isearch-suspended
    (let ((string (read-from-kill-ring)))
      (if (and isearch-case-fold-search
               (eq 'not-yanks search-upper-case))
          (setq string (downcase string)))
      (if isearch-regexp (setq string (regexp-quote string)))
      (setq isearch-yank-flag t)
      (setq isearch-new-string (concat isearch-string string)
            isearch-new-message (concat isearch-message
                                        (mapconcat 'isearch-text-char-description
                                                   string ""))))))

(defun isearch-yank-pop (&optional arg)
   "Replace just-yanked search string with previously killed string."
   (interactive "p")
   (if (and arg (> arg 1))
       (isearch-yank-select)
     (if (not (memq last-command '(isearch-yank-kill isearch-yank-pop)))
         (isearch-yank-kill)
       (isearch-pop-state)
       (isearch-yank-string (current-kill 1)))))

(defun isearch-yank-kill (&optional arg)
   "Pull string from kill ring into search string."
   (interactive "p")
   (unless isearch-mode (isearch-mode t))
   (if (and arg (> arg 1))
       (isearch-yank-select)
     (isearch-yank-string (current-kill 0))))

Re: Recentish C-s M-y change

[Alfred M. Szmidt]

   >> In isearch-mode-map at least, the number of changes on control keys 
   >> during the last twenty years or so is very small: C-u (to allow 
   >> arguments to subcommands), C-h (to enable help on the isearch-mode-map 
   >> keys) and C-x (to allow C-x 8 RET).
   >
   > Recent discussion shows there has been at least one more -- C-y. And I 
   > recall C-w.  And C-e, I think.

   No, as I wrote a few lines above in the message you are replying to, C-y 
   and C-w are bound in isearch-mode-map since at least 1992.

I think Richards point was that there had been such changes, if they
where made in 1992 or some other year isn't really significant.
Rather, that they still trip him over.

Re: Recentish C-s M-y change

[Gregory Heytings via Emacs development discussions.]

>>>> In isearch-mode-map at least, the number of changes on control keys 
>>>> during the last twenty years or so is very small: C-u (to allow 
>>>> arguments to subcommands), C-h (to enable help on the 
>>>> isearch-mode-map keys) and C-x (to allow C-x 8 RET).
>>>
>>> Recent discussion shows there has been at least one more -- C-y. And I 
>>> recall C-w.  And C-e, I think.
>>
>> No, as I wrote a few lines above in the message you are replying to, 
>> C-y and C-w are bound in isearch-mode-map since at least 1992.
>
> I think Richards point was that there had been such changes, if they 
> where made in 1992 or some other year isn't really significant. Rather, 
> that they still trip him over.
>

Yes, and my question is: to which point of time is he referring?  I looked 
further back in time again, and in Emacs 16.56 (1985!), the isearch.el 
file already has (in the comments and in the code):

"^G means the user tried to quit"
"^S means search again, forward, for the same string"
"^R is similar but it searches backward"
"^W means gobble next word from buffer"
"^Y means gobble rest of line from buffer"

And ^Q was already bound to isearch-quote-char.

At that point of time IIUC isearch was terminated by either ESC or a 
random control char.

Apparently (but I could not find a precise point of time) RET started to 
mean exit search near the end of the development of Emacs 18, around 1990.

Re: Recentish C-s M-y change

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

  > > I think Richards point was that there had been such changes, if they 
  > > where made in 1992 or some other year isn't really significant. Rather, 
  > > that they still trip him over.
  > >

  > Yes, and my question is: to which point of time is he referring?

It isn't about any particular date or time.
That's not the kind point this is.

You're addressing a specific detail.  That would make sense if the
detail were part of a step in an argument for a technical point.  But
this isn't that kind of point.

Maybe that is why I have not stated the point in a precise and sharp
way.  Because the idea doesn't come sharp.  Coming up with a clear
analysis of it takes reflection.

After some reflection, here's what I think the point is.

isearch-mode-map is not like a prefix key's map.
A control character which is undefined in isearch-mode-map is not a
vacant space, not a place you can put some nice new feature
and nobody will mind.

The undefined control character is a useful convenience feature,
which people use.

Except that with many control characters defined, it is hard to
remember which ones are defined -- hard to be confident that a given
control character is one that will exit the search for you.

-- 
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: Recentish C-s M-y change

[Drew Adams]

> Except that with many control characters defined, it is hard to
> remember which ones are defined -- hard to be confident that a given
> control character is one that will exit the search for you.

To this point (only), let me point out that we will
have `describe-keymap' (in Emacs 28, I guess), to
which you can enter `isearch-mode-map' at the prompt
to see all of its key bindings human-readably.

That should help, at least.

Re: Recentish C-s M-y change

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

  > > Except that with many control characters defined, it is hard to
  > > remember which ones are defined -- hard to be confident that a given
  > > control character is one that will exit the search for you.

  > To this point (only), let me point out that we will
  > have `describe-keymap' (in Emacs 28, I guess), to
  > which you can enter `isearch-mode-map' at the prompt
  > to see all of its key bindings human-readably.

Sure -- there are various ways to find the current state
of these bindings.  But not while thinking about how to
exit the current search.

-- 
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: Recentish C-s M-y change

[Drew Adams]

>   > > Except that with many control characters defined, it is hard to
>   > > remember which ones are defined -- hard to be confident that a given
>   > > control character is one that will exit the search for you.
> 
>   > To this point (only), let me point out that we will
>   > have `describe-keymap' (in Emacs 28, I guess), to
>   > which you can enter `isearch-mode-map' at the prompt
>   > to see all of its key bindings human-readably.
> 
> Sure -- there are various ways to find the current state
> of these bindings.  But not while thinking about how to
> exit the current search.

Not to belabor this, but in case it helps as food for
thought, to help deal with your concern:

1. We could provide a key in `isearch-mode-map', by
   default, that shows that info, and that continues
   searching normally when you hit some other key.

2. We could provide behavior similar to that of Icicles
   key completion or `which-key.el' but adapted to handle
   Isearch.  That is, continually show the keys available
   currently (either on demand or by option).

3. Provide such on-the-fly key help in some other way.

___

FWIW, although I haven't tried to address that need
directly, with my library isearch+.el you can already
get it currently, albeit in a somewhat roundabout way:

1. `C-x o' in Isearch opens a recursive edit.
2. `C-h M-k isearch-mode-map' shows Isearch keys.
3. `C-M-c' ends recursive edit and continues Isearch
   where you left off.

(`C-x o' is a general Isearch command.  It lets you
interrupt a search, do whatever, then continue the
search where you left off.)
___

And here's a quick and dirty command (thrown together
in a minute) that if bound to an Isearch key shows the
Isearch bindings in another window without interrupting
Isearch.  It makes use of another Isearch+ feature.

(defun isearchp-show-keys (arg)
  "..."
  (interactive "P")
  (save-window-excursion
    (let ((isearchp-on-demand-action-function
           'isearch-describe-bindings))
      (isearchp-act-on-demand arg))
    (setq this-command  'isearchp-act-on-demand)))

(define-key isearch-mode-map <SOME KEY>
            'isearchp-show-keys)

[`isearchp-act-on-demand' is itself bound in Isearch
to `C-M-RET'.  It invokes the value of option
`isearchp-on-demand-action-function', passing it the
current search hit string and its start/end positions.
Repeating it continues the action on subsequent hits.
The default value of the action function replaces the
search hit.  This means you can replace (or delete)
chosen search hits on demand.]
___

I'm not proposing any of this.  Just showing that we
could provide some on-the-fly key help, to give users
an idea what's possible at any time during Isearch.

(Yes, doing that might involve binding some key in
Isearch or setting some option.)

Re: Recentish C-s M-y change

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

  > 1. We could provide a key in `isearch-mode-map', by
  >    default, that shows that info, and that continues
  >    searching normally when you hit some other key.

This might be good if it does not deny one more key
for exiting the search.

  > 2. We could provide behavior similar to that of Icicles
  >    key completion or `which-key.el' but adapted to handle
  >    Isearch.

What would that look like?  Can you make a mock-up?

  > 3. Provide such on-the-fly key help in some other way.

It would be easy to display a message like
  All but C-g C-h C-q C-r C-s  C-x 8 RET  C-w C-y C-\ C-^ M-n M-p M-s M-% C-M-d C-M-i C-M-y C-M-z C-M-% exit
except that it it is too wide for the screen.

By the way, this shows how many keys which used to exit the seach and
thn execute have been redefined over the years to do something else.
I was sure there were more than the few someone showed me from 1992 or so.

-- 
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: Recentish C-s M-y change

[Gregory Heytings via Emacs development discussions.]

>
> It would be easy to display a message like
>  All but C-g C-h C-q C-r C-s  C-x 8 RET  C-w C-y C-\ C-^ M-n M-p M-s M-% C-M-d C-M-i C-M-y C-M-z C-M-% exit
> except that it it is too wide for the screen.
>
> By the way, this shows how many keys which used to exit the seach and 
> thn execute have been redefined over the years to do something else. I 
> was sure there were more than the few someone showed me from 1992 or so.
>

I was replying to you initial question, which was about "control 
characters": "In recent years, we have given several control characters a 
special meaning after C-s.  Most of those special meanings are not useful 
for me, but there were some that I used to type often to exit the search. 
Now that no longer works."  I may have misunderstood what you meant, but 
for me "control characters" meant C-a ... C-z.

C-\ and C-^ were bound in Emacs 20, and have the same meaning in isearch 
as in global-map, but specialized for isearch.

Discussing all M- and C-M- bindings in detail would be much longer, but 
again most of these bindings are not recent.  Those you mention above:

M-n and M-p were bound in Emacs 19.

M-% and C-M-% were bound in Emacs 22, and have the same meaning in isearch 
as in global-map, but specialized for isearch.

M-s was bound in Emacs 23, and has the meaning in isearch as in 
global-map, but specialized for isearch.

C-M-i was bound in Emacs 19.

C-M-d C-M-y C-M-z were bound in Emacs 27, but have no meaning in 
global-map.

Re: Recentish C-s M-y change

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

  > I was replying to you initial question, which was about "control 
  > characters": "In recent years, we have given several control characters a 
  > special meaning after C-s.  Most of those special meanings are not useful 
  > for me, but there were some that I used to type often to exit the search. 
  > Now that no longer works."  I may have misunderstood what you meant, but 
  > for me "control characters" meant C-a ... C-z.

I am sorry I spoke imprecisely.

  > again most of these bindings are not recent.

Yes, it has been happening over time.

-- 
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: Recentish C-s M-y change

[Gregory Heytings via Emacs development discussions.]

>
> After some reflection, here's what I think the point is.
>
> isearch-mode-map is not like a prefix key's map. A control character 
> which is undefined in isearch-mode-map is not a vacant space, not a 
> place you can put some nice new feature and nobody will mind.
>
> The undefined control character is a useful convenience feature, which 
> people use.
>

Thank you, now I understand what you mean.  I don't use that feature 
myself, but it's there and I can understand that people (and in particular 
you) find it convenient.

>
> Except that with many control characters defined, it is hard to remember 
> which ones are defined -- hard to be confident that a given control 
> character is one that will exit the search for you.
>

Yes, but the only newly defined control character which makes Emacs in 
2020 different from Emacs in 1985 is C-m / RET, bound to isearch-exit 
around 1990.  Previously C-m / RET terminated isearch and inserted a 
newline; now C-m / RET only terminates isearch.

You defined C-g, C-q, C-r, C-s, C-w and C-y in 1985 (or perhaps earlier).

C-h has also been bound in the meantime, but you can still exit isearch 
with C-h as you would have done it in 1985, for instance with C-h C-g, or 
C-h f.  IIUC the only difference is that C-h k now describes the key in 
isearch-mode-map instead of the key in global-map.

Likewise, C-x has been bound in the meantime, to allow C-x 8 RET, but you 
can still exit isearch with C-x as you would have done in 1985, for 
instance with C-x C-f or C-x b.

Likewise, C-u has been bound in the meantime, to allow arguments to 
subcommands, but again you can still exit isearch with C-u as you would 
have done in 1985, for instance with C-u C-b or C-u C-n.

Re: Recentish C-s M-y change

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

  > You defined C-g, C-q, C-r, C-s, C-w and C-y in 1985 (or perhaps earlier).

When we changed to RET to exit, did we also change C-y to M-y?
I do have a memory of using M-y years ago to yank the last kill
into a search, and choosing M-y for that precisely because
using it to exit the search was pointless (since it would always
get an error after a search).

I remembered those keys because they were so prominent and so natural
that they stuck in my mind.  Also, C-q in search was comparable to C-q
in insertion.

  > C-h has also been bound in the meantime, but you can still exit isearch 
  > with C-h as you would have done it in 1985, for instance with C-h C-g, or 
  > C-h f.  IIUC the only difference is that C-h k now describes the key in 
  > isearch-mode-map instead of the key in global-map.

  > Likewise, C-x has been bound in the meantime, to allow C-x 8 RET, but you 
  > can still exit isearch with C-x as you would have done in 1985, for 
  > instance with C-x C-f or C-x b.

  > Likewise, C-u has been bound in the meantime, to allow arguments to 
  > subcommands, but again you can still exit isearch with C-u as you would 
  > have done in 1985, for instance with C-u C-b or C-u C-n.

I did not know that.  Thanks for telling me.

But is there really nothing else now?  I have a nonspecific memory
of seeing discussion of various new key bindings in search.


-- 
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: Recentish C-s M-y change

[Gregory Heytings via Emacs development discussions.]

>> You defined C-g, C-q, C-r, C-s, C-w and C-y in 1985 (or perhaps 
>> earlier).
>
> When we changed to RET to exit, did we also change C-y to M-y?
>

No, C-y remained bound to isearch-yank-line until Emacs 24, when it was 
rebound to isearch-yank-kill.  M-y was initially unbound; it was bound to 
isearch-yank-kill in Emacs 19 and was rebound to isearch-yank-pop in Emacs 
24.

>
> I do have a memory of using M-y years ago to yank the last kill into a 
> search, and choosing M-y for that precisely because using it to exit the 
> search was pointless (since it would always get an error after a 
> search).
>

Yes, your memory is correct AFAICS.

>
> But is there really nothing else now?  I have a nonspecific memory of 
> seeing discussion of various new key bindings in search.
>

The isearch-mode-map contains a number of other keybindings indeed, and 
most of them are quite old.

No other control character is defined, except (since at least Emacs 21) 
C-\ (bound to isearch-toggle-input-method; C-\ is bound to 
toggle-input-method in global-map) and C-^ (bound to 
isearch-toggle-specified-input-method; C-^ is unbound in global-map).

The other bindings have a M- or C-M- prefix.  I guess that the discussions 
you remember were about these ones.

As Drew told you, you can get the detailed list of bindings with M-x 
describe-keymap RET isearch-mode-map RET.

Re: Recentish C-s M-y change

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

  > No other control character is defined, except (since at least Emacs 21) 
  > C-\ (bound to isearch-toggle-input-method; C-\ is bound to 
  > toggle-input-method in global-map) and C-^ (bound to 
  > isearch-toggle-specified-input-method; C-^ is unbound in global-map).

  > The other bindings have a M- or C-M- prefix.

That is true, but I don't think it chabges the issue.  Some of those
keys are things you might actually want to type after finishing the
search.
-- 
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: Recentish C-s M-y change

[Drew Adams]

> I almost always exit a search with a command that
> will execute after exiting.

Some thoughts (maybe relevant, maybe not):

1. There is (longstanding) option `search-exit-option'.
   But I guess that doesn't override explicit bindings
   in `isearch-mode-map'.

   Its doc string doesn't say that, however.  At least
   the doc string of `isearch-forward' does suggest it:

   "Other control and meta characters terminate the
    ^^^^^
    search and are then executed normally (depending on
    `search-exit-option').

   That "other" comes after descriptions of keys that
   are bound in `isearch-mode-map', so it suggests that
   IF a control or meta char isn't bound in the Isearch
   map THEN `search-exit-option' applies.

2. In Emacs 27, `search-exit-option' has more possible
   values.  Perhaps it could have a value that lets
   control and meta bindings override `isearch-mode-map'
   bindings.  (I'm not _proposing_ that.)

3. FWIW, in `isearch+.el' I have a white-list option,
   `isearchp-initiate-edit-commands', whose commands /
   keys don't exit Isearch but instead initiate
   `isearch-edit'.  E.g., if `backward-char' is in the
   list then `C-b' during Isearch won't exit search but
   will instead invoke `isearch-edit-string'.

   A similar white-list option could be added to Emacs
   to let users specify commands/keys that _should_
   exit and perform their own actions, e.g. movements.
   IOW, this would override their bindings, if any, in
   `isearch-mode-map'.  This would provide more specific
   control than would an overriding `search-exit-option' (#2).

   (Of course, users can explicitly bind whatever
   control or meta keys they want to `isearch-exit',
   but that doesn't, by itself, let the command perform
   its normal action.)

Re: Recentish C-s M-y change

[Filipp Gunbin]

On 29/12/2020 11:34 +0200, Juri Linkov wrote:

> Such changes of keybindings are not something new: in 2011 we changed
> 'C-s M-y' from 'isearch-yank-kill' to 'isearch-yank-pop',

But this continued to work for the most frequent case of yanking last
kill?

> and also in 2011 changed 'C-s C-y' from 'isearch-yank-line' to
> 'isearch-yank-kill' that was a more fundamental change.

In Emacs 27 there was also change in C-M-w, and it's still painful :-)

--8<---------------cut here---------------start------------->8---
'C-M-w' in isearch changed from 'isearch-del-char' to the new function
'isearch-yank-symbol-or-char'.  'isearch-del-char' is now bound to
'C-M-d'.
--8<---------------cut here---------------end--------------->8---

> Of course, if after trying 'C-s C-y', you'd still prefer the old 'C-s M-y',
> we could revert this change, but this would be a step backwards.

The new workflow is "C-s C-y M-y M-y...", the old one is "C-s M-y
M-y...".  If we could make the first M-y just insert the last kill, then
both workflows can live together, no?  It's just the prompt after C-s
M-y which annoys me currently.

Filipp

Re: Recentish C-s M-y change

[Juri Linkov]

>> Such changes of keybindings are not something new: in 2011 we changed
>> 'C-s M-y' from 'isearch-yank-kill' to 'isearch-yank-pop',
>
> But this continued to work for the most frequent case of yanking last
> kill?

If 'C-s C-y' is easier to type than 'C-s M-y', shouldn't then
more beneficial to have 'C-s C-y' the most frequent case of
yanking last kill?

>> and also in 2011 changed 'C-s C-y' from 'isearch-yank-line' to
>> 'isearch-yank-kill' that was a more fundamental change.
>
> In Emacs 27 there was also change in C-M-w, and it's still painful :-)
>
> 'C-M-w' in isearch changed from 'isearch-del-char' to the new function
> 'isearch-yank-symbol-or-char'.  'isearch-del-char' is now bound to
> 'C-M-d'.

A good example of the change for better that makes these keybindings
more consistent and easier to use:

C-M-y isearch-yank-char
C-M-d isearch-del-char

and

  C-w isearch-yank-word-or-char
C-M-w isearch-yank-symbol-or-char

If it was painful at first, how easy it was to adapt?

>> Of course, if after trying 'C-s C-y', you'd still prefer the old 'C-s M-y',
>> we could revert this change, but this would be a step backwards.
>
> The new workflow is "C-s C-y M-y M-y...", the old one is "C-s M-y
> M-y...".  If we could make the first M-y just insert the last kill, then
> both workflows can live together, no?  It's just the prompt after C-s
> M-y which annoys me currently.

Do you suggest to show the prompt only after 'C-s M-y M-y'?
OT1H, it would have an unexpected effect for users who expect
'C-s M-y M-y M-y ...' to continue inserting more items from
the kill-ring.  OTOH, for users who want the prompt it would be
too inconvenient first to insert the last kill then show
the prompt.

Ok, since everyone wants the old keybinding back, I'll restore
isearch-yank-pop to old code, and also add a new command
'isearch-yank-from-kill-ring', but unbound because there is
no free key in isearch-mode.

Re: Recentish C-s M-y change

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> Ok, since everyone wants the old keybinding back, I'll restore
> isearch-yank-pop to old code, and also add a new command
> 'isearch-yank-from-kill-ring', but unbound because there is
> no free key in isearch-mode.

Thanks!

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

Re: Recentish C-s M-y change

[Jean Louis]

* Juri Linkov <juri@linkov.net> [2020-12-29 22:30]:
> >> Such changes of keybindings are not something new: in 2011 we changed
> >> 'C-s M-y' from 'isearch-yank-kill' to 'isearch-yank-pop',
> >
> > But this continued to work for the most frequent case of yanking last
> > kill?
> 
> If 'C-s C-y' is easier to type than 'C-s M-y', shouldn't then
> more beneficial to have 'C-s C-y' the most frequent case of
> yanking last kill?

That is exactly beneficial and way more easier. I did not in first
place even understand here the problem as it was all in my fingers
without thinking.

C-s C-y is what is logical deriving from basic C-y command.

C-s C-y M-y is what is logical to find some previous searches.

And if using C-s M-y directly that means user wish to select something
from the kill ring. Logical.

> Ok, since everyone wants the old keybinding back, I'll restore
> isearch-yank-pop to old code, and also add a new command
> 'isearch-yank-from-kill-ring', but unbound because there is
> no free key in isearch-mode.

Not everyone and it is definitely not logical.

Re: Recentish C-s M-y change

[Juri Linkov]

>> Ok, since everyone wants the old keybinding back, I'll restore
>> isearch-yank-pop to old code, and also add a new command
>> 'isearch-yank-from-kill-ring', but unbound because there is
>> no free key in isearch-mode.
>
> Not everyone and it is definitely not logical.

Thanks, now I see that not everyone wants the old keybinding back.
Maybe then on every use of old command we could display a message
that will suggest to use a better keybinding 'C-y' because to
hold the Control key, then type 's' and 'y' is easier than to
hold the Control key, type 's', release the Control key,
hold the Meta key, type 'y'.  Then later we could bind
the new command to 'M-y' again.

Re: Recentish C-s M-y change

[Andreas Röhler]

On 30.12.20 10:32, Juri Linkov wrote:
>>> Ok, since everyone wants the old keybinding back, I'll restore
>>> isearch-yank-pop to old code, and also add a new command
>>> 'isearch-yank-from-kill-ring', but unbound because there is
>>> no free key in isearch-mode.
>> Not everyone and it is definitely not logical.
> Thanks, now I see that not everyone wants the old keybinding back.
> Maybe then on every use of old command we could display a message
> that will suggest to use a better keybinding 'C-y' because to
> hold the Control key, then type 's' and 'y' is easier than to
> hold the Control key, type 's', release the Control key,
> hold the Meta key, type 'y'.  Then later we could bind
> the new command to 'M-y' again.
>
With the old behavior could circle through kill-ring, in order to select 
the right one for C-s

Now get the kill-ring-buffer, which feels kind of distracting. I.e., if 
circling, commonly know what I'm looking for, don't need a buffer displayed.

After all, old behavior just feels more convenient.

Re: Recentish C-s M-y change

[Gregory Heytings via Emacs development discussions.]

>
> Thanks, now I see that not everyone wants the old keybinding back.
>

Would it not be possible to use C-u to have both behaviors?  With the 
following code C-s C-y M-y... and C-s M-y M-y... work as before, and C-s 
C-u C-y and C-s C-u M-y use the new feature.

(defun isearch-yank-select ()
   (with-isearch-suspended
    (let ((string (read-from-kill-ring)))
      (if (and isearch-case-fold-search
               (eq 'not-yanks search-upper-case))
          (setq string (downcase string)))
      (if isearch-regexp (setq string (regexp-quote string)))
      (setq isearch-yank-flag t)
      (setq isearch-new-string (concat isearch-string string)
            isearch-new-message (concat isearch-message
                                        (mapconcat 'isearch-text-char-description
                                                   string ""))))))

(defun isearch-yank-pop (&optional arg)
   "Replace just-yanked search string with previously killed string."
   (interactive "p")
   (if (and arg (> arg 1))
       (isearch-yank-select)
     (if (not (memq last-command '(isearch-yank-kill isearch-yank-pop)))
         (isearch-yank-kill)
       (isearch-pop-state)
       (isearch-yank-string (current-kill 1)))))

(defun isearch-yank-kill (&optional arg)
   "Pull string from kill ring into search string."
   (interactive "p")
   (unless isearch-mode (isearch-mode t))
   (if (and arg (> arg 1))
       (isearch-yank-select)
     (isearch-yank-string (current-kill 0))))

Re: Recentish C-s M-y change

[Filipp Gunbin]

On 30/12/2020 11:13 +0000, Gregory Heytings via "Emacs development discussions." wrote:

> Would it not be possible to use C-u to have both behaviors?  With the
> following code C-s C-y M-y... and C-s M-y M-y... work as before, and C-s
> C-u C-y and C-s C-u M-y use the new feature.

Looks overly complex, and currently "sub-commands" (bound to keys in
isearch-mode-map) do not use universal arg AFAICT.

Re: Recentish C-s M-y change

[Gregory Heytings via Emacs development discussions.]

>> Would it not be possible to use C-u to have both behaviors?  With the 
>> following code C-s C-y M-y... and C-s M-y M-y... work as before, and 
>> C-s C-u C-y and C-s C-u M-y use the new feature.
>
> Looks overly complex
>

What is "overly complex"?  The "u" and "y" keys are next to each other on 
most keyboards.

There are not many possible solutions if we want to make that new feature, 
which I think is a useful one, accessible without changing the keymap too 
much.  C-y, M-y and C-M-y are already bound.  Using TAB as you suggested 
does not seem to be a good solution, newcomers would have to learn that 
searching for TAB requires a C-q.

Another solution would be to use C-S-y or M-S-y.

But I do believe that C-u is better, the universal argument is commonly 
used to select between different behaviors in Emacs, and is in particular 
already used to start a regexp isearch and a regular isearch.

>
> and currently "sub-commands" (bound to keys in isearch-mode-map) do not 
> use universal arg AFAICT.
>

That's not correct.  C-s C-u C-q C-i searches for four consecutive tabs, 
for example; C-s C-u 6 C-w starts isearch with the next six words.

Re: Recentish C-s M-y change

[Filipp Gunbin]

On 31/12/2020 15:18 +0000, Gregory Heytings wrote:

>>> Would it not be possible to use C-u to have both behaviors?  With the
>>> following code C-s C-y M-y... and C-s M-y M-y... work as before, and
>>> C-s C-u C-y and C-s C-u M-y use the new feature.
>>
>> Looks overly complex
>>
>
> What is "overly complex"?  The "u" and "y" keys are next to each other on
> most keyboards.

I was referring to the usage of prefix arg in subcommands.

> There are not many possible solutions if we want to make that new feature,
> which I think is a useful one, accessible without changing the keymap too
> much.  C-y, M-y and C-M-y are already bound.  Using TAB as you suggested
> does not seem to be a good solution, newcomers would have to learn that
> searching for TAB requires a C-q.

I suggested TAB because a second TAB would conveniently show
*Completions* with alternatives from the kill ring.  Yet you're right,
having to enter C-q to search for tab *character* may be confusing for
newcomers.

> Another solution would be to use C-S-y or M-S-y.
>
> But I do believe that C-u is better, the universal argument is commonly
> used to select between different behaviors in Emacs, and is in particular
> already used to start a regexp isearch and a regular isearch.
>
>>
>> and currently "sub-commands" (bound to keys in isearch-mode-map) do not
>> use universal arg AFAICT.
>>
>
> That's not correct.  C-s C-u C-q C-i searches for four consecutive tabs,
> for example; C-s C-u 6 C-w starts isearch with the next six words.

Now I know about this, thanks!

Are there any examples where the prefix arg would alter the *behavior*
of the subcommand (make it do something different), not just set a
quantifier?

Filipp

Re: Recentish C-s M-y change

[Gregory Heytings via Emacs development discussions.]

>
> Are there any examples where the prefix arg would alter the *behavior* 
> of the subcommand (make it do something different), not just set a 
> quantifier?
>

In isearch-mode-map, I think not.  In other places, I don't know.

Many commands in isearch-mode-map explicitly allow and use a prefix 
argument (C-q, C-r, C-s, C-w, ...).  isearch-yank-kill (C-y) and 
isearch-yank-pop (M-y) accept one, but it is unused.  I don't see what 
meaning could be attached to a numeric argument to isearch-yank-kill or 
isearch-yank-pop, so I think that using C-u to start an interactive 
selection with these two commands would make sense.

Re: Recentish C-s M-y change

[Juri Linkov]

> Many commands in isearch-mode-map explicitly allow and use a prefix
> argument (C-q, C-r, C-s, C-w, ...).  isearch-yank-kill (C-y) and
> isearch-yank-pop (M-y) accept one, but it is unused.  I don't see what
> meaning could be attached to a numeric argument to isearch-yank-kill or
> isearch-yank-pop, so I think that using C-u to start an interactive
> selection with these two commands would make sense.

The problem is that C-u has other meaning in 'C-u M-y'
where it puts point at beginning and mark at end.

Re: Recentish C-s M-y change

[Gregory Heytings via Emacs development discussions.]

>> Many commands in isearch-mode-map explicitly allow and use a prefix 
>> argument (C-q, C-r, C-s, C-w, ...).  isearch-yank-kill (C-y) and 
>> isearch-yank-pop (M-y) accept one, but it is unused.  I don't see what 
>> meaning could be attached to a numeric argument to isearch-yank-kill or 
>> isearch-yank-pop, so I think that using C-u to start an interactive 
>> selection with these two commands would make sense.
>
> The problem is that C-u has other meaning in 'C-u M-y' where it puts 
> point at beginning and mark at end.
>

Are you sure?  I don't see this, I do not see any difference between C-s 
M-y and C-s C-u M-y.

Re: Recentish C-s M-y change

[Juri Linkov]

>>> Many commands in isearch-mode-map explicitly allow and use a prefix
>>> argument (C-q, C-r, C-s, C-w, ...).  isearch-yank-kill (C-y) and
>>> isearch-yank-pop (M-y) accept one, but it is unused.  I don't see what
>>> meaning could be attached to a numeric argument to isearch-yank-kill or
>>> isearch-yank-pop, so I think that using C-u to start an interactive
>>> selection with these two commands would make sense.
>>
>> The problem is that C-u has other meaning in 'C-u M-y' where it puts
>> point at beginning and mark at end.
>
> Are you sure?  I don't see this, I do not see any difference between C-s
> M-y and C-s C-u M-y.

I meant the global C-u M-y.  But since its global meaning makes no sense
in isearch, I added C-s C-u M-y as you suggested.

Re: Recentish C-s M-y change

[Filipp Gunbin]

On 13/01/2021 20:19 +0200, Juri Linkov wrote:

>>>> Many commands in isearch-mode-map explicitly allow and use a prefix
>>>> argument (C-q, C-r, C-s, C-w, ...).  isearch-yank-kill (C-y) and
>>>> isearch-yank-pop (M-y) accept one, but it is unused.  I don't see what
>>>> meaning could be attached to a numeric argument to isearch-yank-kill or
>>>> isearch-yank-pop, so I think that using C-u to start an interactive
>>>> selection with these two commands would make sense.
>>>
>>> The problem is that C-u has other meaning in 'C-u M-y' where it puts
>>> point at beginning and mark at end.
>>
>> Are you sure?  I don't see this, I do not see any difference between C-s
>> M-y and C-s C-u M-y.
>
> I meant the global C-u M-y.  But since its global meaning makes no sense
> in isearch, I added C-s C-u M-y as you suggested.

I'm a bit opposed to this change, because, as I wrote in this thread, it
will introduce a behaviour-changing prefix arg in isearch-specific
command.

isearch already has many commands, and we'd better keep them simple,
because they're already "nested", in a sense.  In this concrete case,
this is even worse, because `C-u M-y' has (different) meaning globally.

Yes, in isearch there're `M-%', `M-s o' and others taking prefix arg for
behavior change (not just simple repetition count), but they can be
viewed as global commands only being _started_ in isearch.

Just my opinion.
Filipp

Re: Recentish C-s M-y change

[Juri Linkov]

>>>>> Many commands in isearch-mode-map explicitly allow and use a prefix
>>>>> argument (C-q, C-r, C-s, C-w, ...).  isearch-yank-kill (C-y) and
>>>>> isearch-yank-pop (M-y) accept one, but it is unused.  I don't see what
>>>>> meaning could be attached to a numeric argument to isearch-yank-kill or
>>>>> isearch-yank-pop, so I think that using C-u to start an interactive
>>>>> selection with these two commands would make sense.
>>>>
>>>> The problem is that C-u has other meaning in 'C-u M-y' where it puts
>>>> point at beginning and mark at end.
>>>
>>> Are you sure?  I don't see this, I do not see any difference between C-s
>>> M-y and C-s C-u M-y.
>>
>> I meant the global C-u M-y.  But since its global meaning makes no sense
>> in isearch, I added C-s C-u M-y as you suggested.
>
> I'm a bit opposed to this change, because, as I wrote in this thread, it
> will introduce a behaviour-changing prefix arg in isearch-specific
> command.
>
> isearch already has many commands, and we'd better keep them simple,

I agree that better to keep isearch commands simple, and indeed
a new isearch command that precisely mirrors the global command
is as simple as possible.  But its backward-compatible counterpart
isearch command is already a mess, so adding a prefix arg to it
doesn't make it much more complicated.

Re: Recentish C-s M-y change

[Filipp Gunbin]

On 14/01/2021 10:44 +0200, Juri Linkov wrote:

>>>>>> Many commands in isearch-mode-map explicitly allow and use a prefix
>>>>>> argument (C-q, C-r, C-s, C-w, ...).  isearch-yank-kill (C-y) and
>>>>>> isearch-yank-pop (M-y) accept one, but it is unused.  I don't see what
>>>>>> meaning could be attached to a numeric argument to isearch-yank-kill or
>>>>>> isearch-yank-pop, so I think that using C-u to start an interactive
>>>>>> selection with these two commands would make sense.
>>>>>
>>>>> The problem is that C-u has other meaning in 'C-u M-y' where it puts
>>>>> point at beginning and mark at end.
>>>>
>>>> Are you sure?  I don't see this, I do not see any difference between C-s
>>>> M-y and C-s C-u M-y.
>>>
>>> I meant the global C-u M-y.  But since its global meaning makes no sense
>>> in isearch, I added C-s C-u M-y as you suggested.
>>
>> I'm a bit opposed to this change, because, as I wrote in this thread, it
>> will introduce a behaviour-changing prefix arg in isearch-specific
>> command.
>>
>> isearch already has many commands, and we'd better keep them simple,
>
> I agree that better to keep isearch commands simple, and indeed
> a new isearch command that precisely mirrors the global command
> is as simple as possible.  But its backward-compatible counterpart
> isearch command is already a mess, so adding a prefix arg to it
> doesn't make it much more complicated.

Except that it sets a precedent for complicating other isearch
commands...

Re: Recentish C-s M-y change

[Gregory Heytings]

>>>> Many commands in isearch-mode-map explicitly allow and use a prefix 
>>>> argument (C-q, C-r, C-s, C-w, ...).  isearch-yank-kill (C-y) and 
>>>> isearch-yank-pop (M-y) accept one, but it is unused.  I don't see 
>>>> what meaning could be attached to a numeric argument to 
>>>> isearch-yank-kill or isearch-yank-pop, so I think that using C-u to 
>>>> start an interactive selection with these two commands would make 
>>>> sense.
>>>
>>> The problem is that C-u has other meaning in 'C-u M-y' where it puts 
>>> point at beginning and mark at end.
>>
>> Are you sure?  I don't see this, I do not see any difference between 
>> C-s M-y and C-s C-u M-y.
>
> I meant the global C-u M-y.  But since its global meaning makes no sense 
> in isearch, I added C-s C-u M-y as you suggested.
>

Thank you!

But... could you perhaps also add C-s C-u C-y, as I suggested?  If not, 
why not?  The prefix argument is currently ignored by C-y.

I believe accessing the new feature with both C-s C-u C-y and C-s C-u M-y 
is useful: C-s C-u C-y is useful to immediately enter an interactive 
selection (it's convenient because it only uses the control modifier), and 
C-s C-y M-y ... C-u M-y is useful to enter an interactive selection while 
using the non-interactive selection.

Re: Recentish C-s M-y change

[Juri Linkov]

>> I meant the global C-u M-y.  But since its global meaning makes no sense
>> in isearch, I added C-s C-u M-y as you suggested.
>
> Thank you!
>
> But... could you perhaps also add C-s C-u C-y, as I suggested?  If not, why
> not?  The prefix argument is currently ignored by C-y.

The current interface of isearch-yank-kill and isearch-yank-pop
corresponds exactly to the global commands yank and yank-pop.
So their behaviors are mirrors, but adding C-u to one of them
will break consistency, i.e. C-u of yank and isearch-yank-kill
would have a completely different meaning.

The isearch command currently bound to C-s M-y is a mess for
backward-compatibility, so a prefix argument C-u was necessary to add
to it as a compromise to support the old behavior and the new feature of
M-y.

> I believe accessing the new feature with both C-s C-u C-y and C-s C-u M-y
> is useful: C-s C-u C-y is useful to immediately enter an interactive
> selection (it's convenient because it only uses the control modifier), and
> C-s C-y M-y ... C-u M-y is useful to enter an interactive selection while
> using the non-interactive selection.

BTW, such sequence might not do what you want.  I mean that often after typing
C-s C-y M-y ... C-u M-y, the second C-u M-y doesn't replace the search string
with a string from the kill-ring, it appends it.  I don't know if this is ok
to simply change the implementation to replace the search string instead of
appending, or many users already prefer appending, I have no idea.
Maybe to add a new argument to specify whether append or replace?
Like the argument C-u of the global command yank defines whether
to put point at beginning and mark at end.

Re: Recentish C-s M-y change

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

  > > But... could you perhaps also add C-s C-u C-y, as I suggested?  If not, why
  > > not?  The prefix argument is currently ignored by C-y.

I type C-u C-y to exit a search by yanking.  Just C-y won't do it.

-- 
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: Recentish C-s M-y change

[Gregory Heytings]

>>> But... could you perhaps also add C-s C-u C-y, as I suggested?  If 
>>> not, why not?  The prefix argument is currently ignored by C-y.
>
> I type C-u C-y to exit a search by yanking.  Just C-y won't do it.
>

What version of Emacs do you use?  With Emacs 24 and above, C-y and C-u 
C-y in isearch-mode-map have the exact same effect (isearch-yank-kill).

Re: Recentish C-s M-y change

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

  > What version of Emacs do you use?  With Emacs 24 and above, C-y and C-u 
  > C-y in isearch-mode-map have the exact same effect (isearch-yank-kill).

I use master, so it looks like guess I have not done that recently.
I have a memory of doing it in the past.

Since there is no point in a search string, how does C-u C-y in search
differ from plain C-y?  If it is an alias, then currently it serves no
purpose, so why not put it back to what it used to be (exit search
then C-u C-y)?


-- 
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: Recentish C-s M-y change

[Gregory Heytings]

>> But... could you perhaps also add C-s C-u C-y, as I suggested?  If not, 
>> why not?  The prefix argument is currently ignored by C-y.
>
> The current interface of isearch-yank-kill and isearch-yank-pop 
> corresponds exactly to the global commands yank and yank-pop. So their 
> behaviors are mirrors, but adding C-u to one of them will break 
> consistency, i.e. C-u of yank and isearch-yank-kill would have a 
> completely different meaning.
>

I understand, but the consistency is broken anyway: C-u has an effect on 
yank, and no effect on isearch-yank-kill.  And mirroring the effect of C-u 
on yank (exchanging point and mark) in isearch-yank-kill is not possible.

I stand by my suggestion: using the universal argument on 
isearch-yank-kill to immediately enter the interactive selection of an 
element of the kill-ring with C-s C-u C-y without releasing the control 
modifier.

>> I believe accessing the new feature with both C-s C-u C-y and C-s C-u 
>> M-y is useful: C-s C-u C-y is useful to immediately enter an 
>> interactive selection (it's convenient because it only uses the control 
>> modifier), and C-s C-y M-y ... C-u M-y is useful to enter an 
>> interactive selection while using the non-interactive selection.
>
> BTW, such sequence might not do what you want.  I mean that often after 
> typing C-s C-y M-y ... C-u M-y, the second C-u M-y doesn't replace the 
> search string with a string from the kill-ring, it appends it.
>

That's not correct.  C-s C-y M-y ... or C-s M-y M-y ... cycle through the 
kill-ring entries.  Typing C-u M-y enters an interactive selection of the 
kill-ring elements in the minibuffer.

What you probably meant is that C-s <something> C-y M-y ... or C-s 
<something> M-y M-y ... cycle through the kill-ring entries and appends 
each of them in turn to the <something>, and that typing C-u M-y discards 
the <something> and enters the interactive selection of a kill-ring 
element in the minibuffer.

It could indeed make sense to use C-u C-u M-y (for example) to enter an 
interactive selection of a kill-ring element prepended with the 
<something>, but I'm not convinced it would be very useful in practice.

Re: Recentish C-s M-y change

[Juri Linkov]

> I understand, but the consistency is broken anyway: C-u has an effect on
> yank, and no effect on isearch-yank-kill.

There is a difference between no effect and a completely different effect.

> And mirroring the effect of C-u on yank (exchanging point and mark) in
> isearch-yank-kill is not possible.

It's still possible to give C-s C-u C-y the meaning similar to C-u C-y
where point at the beginning of the search string means to replace the string,
not to append to the end as it does now by default.

> What you probably meant is that C-s <something> C-y M-y ... or C-s
> <something> M-y M-y ... cycle through the kill-ring entries and appends
> each of them in turn to the <something>, and that typing C-u M-y discards
> the <something> and enters the interactive selection of a kill-ring element
> in the minibuffer.

Actually the same problem exists for both cases:

C-s <something> C-y
C-s <something> C-u M-y

Both cases (either directly by C-y and M-y, or the interactive selection
by C-u M-y) append the string to the end of the search string.

> It could indeed make sense to use C-u C-u M-y (for example) to enter an
> interactive selection of a kill-ring element prepended with the
> <something>, but I'm not convinced it would be very useful in practice.

I agree, it makes no sense to prepend the old search string to the
initial input of the interactive selection.  This is why this would be
more convenient:

C-s <something> C-u C-y
C-s <something> C-u M-y

Both these cases will replace the search string, similar to what their
global versions do in regard to switching mark and point.

Then we need to find a new prefix instead of C-u M-y to keep
the old behavior of appending the yanked string to the end.
Maybe C-s <something> C-0 M-y.

Re: Recentish C-s M-y change

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

  > Would it not be possible to use C-u to have both behaviors?  With the 
  > following code C-s C-y M-y... and C-s M-y M-y... work as before, and C-s 
  > C-u C-y and C-s C-u M-y use the new feature.

It is a nuisance that C-u doesn't exit the search as it ought to.

-- 
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: Recentish C-s M-y change

[Gregory Heytings via Emacs development discussions.]

>> Would it not be possible to use C-u to have both behaviors?  With the 
>> following code C-s C-y M-y... and C-s M-y M-y... work as before, and 
>> C-s C-u C-y and C-s C-u M-y use the new feature.
>
> It is a nuisance that C-u doesn't exit the search as it ought to.
>

This changed in Emacs 24, eight years ago.  Previously C-u was bound to 
isearch-other-control-char, which (by default) aborted isearch and called 
universal-argument.  With Emacs 24 and above it is bound to 
universal-argument without aborting isearch; for example, C-s C-u a 
searches for "aaaa".

Re: Recentish C-s M-y change

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

It is no surprise to me that I don't remember WHEN various keys
were changed from the default meaning, of "exit the search and execute".
There have been so many that I don't remember what they all are.

-- 
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: Recentish C-s M-y change

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Fri, 01 Jan 2021 02:21:50 -0500
> Cc: emacs-devel@gnu.org
> 
> It is no surprise to me that I don't remember WHEN various keys
> were changed from the default meaning, of "exit the search and execute".
> There have been so many that I don't remember what they all are.

I would urge you (and other veteran Emacs users) to report any
annoying change as a bug the first time you see it.  It will certainly
make sure the maintainers are aware of the issue and will pay
attention to it in the future.  Thus, a succession of such changes
will be probably cut short much sooner, before it gathers too many
changes and too many people who like them.

Re: Recentish C-s M-y change

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

  > > It is no surprise to me that I don't remember WHEN various keys
  > > were changed from the default meaning, of "exit the search and execute".
  > > There have been so many that I don't remember what they all are.

  > I would urge you (and other veteran Emacs users) to report any
  > annoying change as a bug the first time you see it.

I saw many of them when they were proposed.  I did not argue against
them because there was apparent support for each one at the time.

But so many of these search bindings have accumulated that it
adds up to a problem -- and worst of all, people seem to be drawn
to propose more changes in that keymap.

-- 
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: Recentish C-s M-y change

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: ghe@sdf.org, emacs-devel@gnu.org
> Date: Sat, 02 Jan 2021 00:28:31 -0500
> 
>   > I would urge you (and other veteran Emacs users) to report any
>   > annoying change as a bug the first time you see it.
> 
> I saw many of them when they were proposed.  I did not argue against
> them because there was apparent support for each one at the time.

I didn't mean to report a bug when the change is proposed, I meant to
report a bug when you actually see the changed behavior in your Emacs
for the first time.

> But so many of these search bindings have accumulated that it
> adds up to a problem -- and worst of all, people seem to be drawn
> to propose more changes in that keymap.

I think (or rather hope) that timely reporting of these changes as
bugs would contribute to us being more cautious with similar changes
in the future.

Re: Recentish C-s M-y change

[Filipp Gunbin]

On 30/12/2020 11:32 +0200, Juri Linkov wrote:

>>> Ok, since everyone wants the old keybinding back, I'll restore
>>> isearch-yank-pop to old code, and also add a new command
>>> 'isearch-yank-from-kill-ring', but unbound because there is
>>> no free key in isearch-mode.
>>
>> Not everyone and it is definitely not logical.
>
> Thanks, now I see that not everyone wants the old keybinding back.
> Maybe then on every use of old command we could display a message
> that will suggest to use a better keybinding 'C-y' because to
> hold the Control key, then type 's' and 'y' is easier than to
> hold the Control key, type 's', release the Control key,
> hold the Meta key, type 'y'.  Then later we could bind
> the new command to 'M-y' again.

It all depends on your way of typing, and on the keyboard layout.

RE: Recentish C-s M-y change

[Drew Adams]

> Maybe then on every use of old command we could display a message

Please don't.  Not by default anyway.

> that will suggest to use a better keybinding 'C-y'

One person's "better" is another's "worse".

> because to hold the Control key, then type 's' and 'y' is easier

There are reasons for, and reasons not for.

> Then later we could bind the new command to 'M-y' again.

Why later?  You want to make a default key change,
with a suggestion that maybe-later-we-could change
it back?

Re: Recentish C-s M-y change

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

  > Maybe then on every use of old command we could display a message
  > that will suggest to use a better keybinding 'C-y' because to
  > hold the Control key, then type 's' and 'y' is easier than to
  > hold the Control key, type 's', release the Control key,

Please do not do this.  I want to see the new search string,
not some repetitions informational message.

Besides, I may rebind C-y in a search to do what it used to do:
exit the search!

People are wantonly redefining control characters in searches to do
other things, as if people though that these characters are somehow
undefined.  They are not undefined.  They exit the search and then
take an action.


-- 
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: Recentish C-s M-y change

[Alfred M. Szmidt]

     > Maybe then on every use of old command we could display a message
     > that will suggest to use a better keybinding 'C-y' because to
     > hold the Control key, then type 's' and 'y' is easier than to
     > hold the Control key, type 's', release the Control key,

   Please do not do this.  I want to see the new search string,
   not some repetitions informational message.

   Besides, I may rebind C-y in a search to do what it used to do:
   exit the search!

Or we could just restore the behaviour to what it was -- why are these
things changed without doing some rudimentary query of users?


I too find this new behaviour annoying, and want it restored.

Re: Recentish C-s M-y change

[Lars Ingebrigtsen]

"Alfred M. Szmidt" <ams@gnu.org> writes:

> Or we could just restore the behaviour to what it was -- why are these
> things changed without doing some rudimentary query of users?

Trying out new things on the development branch is fine.  And the
behaviour has been restored to what it was, so I don't get the point of
this pile-on.

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

Re: Recentish C-s M-y change

[Alfred M. Szmidt]

   "Alfred M. Szmidt" <ams@gnu.org> writes:

   > Or we could just restore the behaviour to what it was -- why are these
   > things changed without doing some rudimentary query of users?

   Trying out new things on the development branch is fine.  

There is a difference between trying something new, and changing
defaults.  When changing default behaviour it is a good idea to do a
initial poll before changing it.  It will cause less friction later
on.

   And the behaviour has been restored to what it was, so I don't get
   the point of this pile-on.

They might not read the commit history, or every single message posted
to the list.

Re: Recentish C-s M-y change

[Lars Ingebrigtsen]

"Alfred M. Szmidt" <ams@gnu.org> writes:

> There is a difference between trying something new, and changing
> defaults.  When changing default behaviour it is a good idea to do a
> initial poll before changing it.  It will cause less friction later
> on.

We are testing things out on the development branch -- that's the only
way to get real experience with a change, and that includes changes of
defaults.

>    And the behaviour has been restored to what it was, so I don't get
>    the point of this pile-on.
>
> They might not read the commit history, or every single message posted
> to the list.

This is the Emacs development list.  If "they" aren't following the
development, "they" should feel free not to pile on.

All this bickering makes the Emacs development distinctly less friendly
-- any change, no matter how trivial, seemingly leads to these endless
demands for change of process or cries of outrage.  Here a developer
made a change, we tried it out for a time, I said "this is a bit
annoying", others agreed, and the change was reverted.  This is how the
system should work.  And then we get messages, like yours, beating a
horse that's long dead, and that's not helpful.

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

Re: Recentish C-s M-y change

[Alfred M. Szmidt]

   All this bickering makes the Emacs development distinctly less
   friendly [..snip..]

Nobody is bickering, but your message is unfriendly and unkind and
accusing me of I have no idea what.  

Re: Recentish C-s M-y change

[Eli Zaretskii]

> From: "Alfred M. Szmidt" <ams@gnu.org>
> Date: Fri, 01 Jan 2021 06:14:42 -0500
> Cc: emacs-devel@gnu.org, rms@gnu.org, juri@linkov.net
> 
>    All this bickering makes the Emacs development distinctly less
>    friendly [..snip..]
> 
> Nobody is bickering, but your message is unfriendly and unkind and
> accusing me of I have no idea what.  

Your messages were accusatory as well, so I can understand why Lars
was irritated.

Re: Recentish C-s M-y change

[Alfred M. Szmidt]

   >    All this bickering makes the Emacs development distinctly less
   >    friendly [..snip..]
   > 
   > Nobody is bickering, but your message is unfriendly and unkind and
   > accusing me of I have no idea what.  

   Your messages were accusatory as well, so I can understand why Lars
   was irritated.

They did not accuse Lars, or anyone of anything so I cannot see how
they where "accusatory" -- but if Lars or anyone did find it then
there are far better ways to raise that instead of attacking people.

Re: Recentish C-s M-y change

[Eli Zaretskii]

> From: "Alfred M. Szmidt" <ams@gnu.org>
> Date: Thu, 31 Dec 2020 05:44:38 -0500
> Cc: larsi@gnus.org, emacs-devel@gnu.org, juri@linkov.net
> 
> why are these things changed without doing some rudimentary query of
> users?

It is unreasonable to expect us to conduct a user survey before every
behavior change.  It would make an impossible obstacle to any such
development in Emacs.  We also don't have any practical way of asking
a large sample of typical users and getting answers quickly.

We trust our developers that they keep the UX aspects in mind, and
bring issues to discussions here when they see the need.  Sometimes a
developer might think a change in behavior is a no-brainer, whereas in
fact it isn't; in that case complaining about the problematic change
is exactly the right way of fixing the problem, better later than
never.

So I suggest that we focus on fixing the change so it leaves everyone
happy, instead of developing impractical expectations from the process
of Emacs development.

Re: Recentish C-s M-y change

[Alfred M. Szmidt]

   > From: "Alfred M. Szmidt" <ams@gnu.org>
   > Date: Thu, 31 Dec 2020 05:44:38 -0500
   > Cc: larsi@gnus.org, emacs-devel@gnu.org, juri@linkov.net
   > 
   > why are these things changed without doing some rudimentary query of
   > users?

   It is unreasonable to expect us to conduct a user survey before every
   behavior change.  It would make an impossible obstacle to any such
   development in Emacs.  

But that is not what I asked for.

Just recently two changes at least (y-or-n-p and C-s M-y) have caused
grief because one didn't query even the smallest sample say in
emacs-devel and discuss it for a bit before making the change.

   We also don't have any practical way of asking a large sample of
   typical users and getting answers quickly.

Thats a good thing, people act to fast these days and hurry through
changes.

Re: Recentish C-s M-y change

[Eli Zaretskii]

> From: "Alfred M. Szmidt" <ams@gnu.org>
> Cc: rms@gnu.org, larsi@gnus.org, emacs-devel@gnu.org, juri@linkov.net
> Date: Thu, 31 Dec 2020 10:42:41 -0500
> 
> Just recently two changes at least (y-or-n-p and C-s M-y) have caused
> grief because one didn't query even the smallest sample say in
> emacs-devel and discuss it for a bit before making the change.

I guess because the change seemed to be non-controversial.  It turned
to be otherwise, and that can always happen.

Re: Recentish C-s M-y change

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

  > I guess because the change seemed to be non-controversial.

Perhaps the crucial point is that keys which are not explicitly
defined by the search keymap do all have a meaning there, and users
know that meaning and may be accustomed to using it.  Therefore,
changing it is always controversial.

-- 
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: Recentish C-s M-y change

[Dmitry Gutov]

On 31.12.2020 16:30, Eli Zaretskii wrote:
> We trust our developers that they keep the UX aspects in mind

Let's apply this standard in more cases, shall we?

Re: Recentish C-s M-y change

[Gregory Heytings via Emacs development discussions.]

>
> Besides, I may rebind C-y in a search to do what it used to do: exit the 
> search!
>

Since Emacs 21 at least, twenty years ago, C-y does not exit isearch.  In 
Emacs 21 to 23 it was bound to isearch-yank-line; starting with Emacs 24 
it is bound to isearch-yank-kill.

Re: Recentish C-s M-y change

[Filipp Gunbin]

On 29/12/2020 21:20 +0200, Juri Linkov wrote:

>>> Such changes of keybindings are not something new: in 2011 we changed
>>> 'C-s M-y' from 'isearch-yank-kill' to 'isearch-yank-pop',
>>
>> But this continued to work for the most frequent case of yanking last
>> kill?
>
> If 'C-s C-y' is easier to type than 'C-s M-y', shouldn't then
> more beneficial to have 'C-s C-y' the most frequent case of
> yanking last kill?

It's not easier.  Some time ago I learned to type all modifiers with one
hand, and a letter with another.  This sometimes may be slower, but in
the end it's more comfortable, as there's no need to press distant keys
by one hand.  With this way of typing, C-s C-y and C-s M-y are
equivalent.

> A good example of the change for better that makes these keybindings
> more consistent and easier to use:
>
> C-M-y isearch-yank-char
> C-M-d isearch-del-char
>
> and
>
>   C-w isearch-yank-word-or-char
> C-M-w isearch-yank-symbol-or-char
>
> If it was painful at first, how easy it was to adapt?

These are good changes IMO, they make sense, it's just that I would
prefer to have the new binding while preserving the old, so I could
re-learn smootly.  I still occasionally type the wrong key.

>>> Of course, if after trying 'C-s C-y', you'd still prefer the old 'C-s M-y',
>>> we could revert this change, but this would be a step backwards.
>>
>> The new workflow is "C-s C-y M-y M-y...", the old one is "C-s M-y
>> M-y...".  If we could make the first M-y just insert the last kill, then
>> both workflows can live together, no?  It's just the prompt after C-s
>> M-y which annoys me currently.
>
> Do you suggest to show the prompt only after 'C-s M-y M-y'?
> OT1H, it would have an unexpected effect for users who expect
> 'C-s M-y M-y M-y ...' to continue inserting more items from
> the kill-ring.  OTOH, for users who want the prompt it would be
> too inconvenient first to insert the last kill then show
> the prompt.

No, I was suggesting that the promting command be put on some other key
binding, like C-s TAB maybe (it inserts TAB currently, but that can be
done with C-s C-q TAB).

And both C-s C-y M-y M-y.. and C-s M-y M-y... may do the same - insert
last kill, then continue with previous ones.  This way everybody can
learn new binding.

> Ok, since everyone wants the old keybinding back, I'll restore
> isearch-yank-pop to old code, and also add a new command
> 'isearch-yank-from-kill-ring', but unbound because there is
> no free key in isearch-mode.

Thanks!

Re: Recentish C-s M-y change

[Jean Louis]

* Filipp Gunbin <fgunbin@fastmail.fm> [2020-12-29 21:36]:
> The new workflow is "C-s C-y M-y M-y...", the old one is "C-s M-y
> M-y...".  If we could make the first M-y just insert the last kill, then
> both workflows can live together, no?  It's just the prompt after C-s
> M-y which annoys me currently.

I was thinking that basic workflow without incremental search would
be:

C-y M-y M-y...

and that it is logical and user friendly to keep that workflow also
after prefix key for incremental search:

C-s C-y M-y M-y... which currently does its job well.

If I do only this:

M-y then I am asked to yank it from kill-ring and so I expect the same
when I do:

C-s M-y to be asked to yank it from kill ring.

In my opinion users who expect that C-s M-y yank it immediately have
learned it little wrong, instead of changing the function, maybe they
could change their habit.

But then again if function is changed why not change everything to be
consistent. Then M-y should be same as C-y to insert straight yanked
part of text. But that again is highly not logical to basics of Emacs
editing as we have C-y for that.

Re: Recentish C-s M-y change

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

  > > Could we move the new `C-s M-y' functionality somewhere else and retain
  > > the old `C-s M-y' binding?

  > This has been discussed many times, and the most promising solution is
  > to add a single variable that will define whether the user prohibits
  > changing the definitions of traditional keys.

I think that is a bad approach, and here is why.

Various changes are made in the Emacs user interface.  Occasionally
there is one I find inconvenient and want to avoid.  But not all of
them.  Probably not most of them.

I want options to undo the changes I don't like, but I don't
want that to imply rejecting _all_ changes in a blanket way.

Now, if there are people who would like the ability to say, "Give me
the Emacs 26 user interface," I don't object to offering it.  We could
have a mechanism to associate user interface changes with major versions
and then let users choose a version.

But this is not a substitute for letting people disable specific
changes independently -- those changes which need it.  Some changes
are easy to revert by setting a key binding, and they don't need
an option.

We could pay attention to implementing a change, when possible, in a
way that would make it easy to revert by setting a key binding or an
option.  In other words, think in advance about the possibility that
some people may not like the change.



-- 
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: Recentish C-s M-y change

[Drew Adams]

>   > This has been discussed many times, and the most promising solution is
>   > to add a single variable that will define whether the user prohibits
>   > changing the definitions of traditional keys.
> 
> I think that is a bad approach, and here is why.
> 
> Various changes are made in the Emacs user interface.  Occasionally
> there is one I find inconvenient and want to avoid.  But not all of
> them.  Probably not most of them.
> 
> I want options to undo the changes I don't like, but I don't
> want that to imply rejecting _all_ changes in a blanket way.
> 
> Now, if there are people who would like the ability to say, "Give me
> the Emacs 26 user interface," I don't object to offering it.  We could
> have a mechanism to associate user interface changes with major versions
> and then let users choose a version.
> 
> But this is not a substitute for letting people disable specific
> changes independently -- those changes which need it.  Some changes
> are easy to revert by setting a key binding, and they don't need
> an option.
> 
> We could pay attention to implementing a change, when possible, in a
> way that would make it easy to revert by setting a key binding or an
> option.  In other words, think in advance about the possibility that
> some people may not like the change.

This is exactly what I think those of us -
I, at least - who've not appreciated some
such changes, would like to say.  Thank
you for saying it clearly.

Re: Recentish C-s M-y change

[Juri Linkov]

>   > > Could we move the new `C-s M-y' functionality somewhere else and retain
>   > > the old `C-s M-y' binding?
>
>   > This has been discussed many times, and the most promising solution is
>   > to add a single variable that will define whether the user prohibits
>   > changing the definitions of traditional keys.
>
> I think that is a bad approach, and here is why.
>
> Various changes are made in the Emacs user interface.  Occasionally
> there is one I find inconvenient and want to avoid.  But not all of
> them.  Probably not most of them.
>
> I want options to undo the changes I don't like, but I don't
> want that to imply rejecting _all_ changes in a blanket way.
>
> Now, if there are people who would like the ability to say, "Give me
> the Emacs 26 user interface," I don't object to offering it.  We could
> have a mechanism to associate user interface changes with major versions
> and then let users choose a version.
>
> But this is not a substitute for letting people disable specific
> changes independently -- those changes which need it.  Some changes
> are easy to revert by setting a key binding, and they don't need
> an option.
>
> We could pay attention to implementing a change, when possible, in a
> way that would make it easy to revert by setting a key binding or an
> option.  In other words, think in advance about the possibility that
> some people may not like the change.

What do you think about adding a new theme that contains all changes,
e.g.:

  (deftheme back-to-emacs-27)

  (define-key isearch-mode-map "\M-y" 'isearch-yank-pop)
  (setq read-char-choice-use-read-key t)
  (setq y-or-n-p-use-read-key t)
  ...

Then people could disable specific changes independently by copying
parts of such theme to their init files.

Re: Recentish C-s M-y change

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

  > What do you think about adding a new theme that contains all changes,
  > e.g.:

  >   (deftheme back-to-emacs-27)

  >   (define-key isearch-mode-map "\M-y" 'isearch-yank-pop)
  >   (setq read-char-choice-use-read-key t)
  >   (setq y-or-n-p-use-read-key t)
  >   ...

  > Then people could disable specific changes independently by copying
  > parts of such theme to their init files.

That's gratuitously inconvenient.  It has no advantage.

-- 
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: Recentish C-s M-y change

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

  > Could we move the new `C-s M-y' functionality somewhere else and retain
  > the old `C-s M-y' binding?

I had not noticed this, but I just tried it and I feel the same way.
I do use C-s M-y to get the last kill ring entry, and I want that to
continue to work.

-- 
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: Recentish C-s M-y change

[Drew Adams]

> Or we could just restore the behaviour to what it was -- why are these
> things changed without doing some rudimentary query of users?
> 
> I too find this new behaviour annoying, and want it restored.

Query of users can be good.

In addition, this kind of thing should, I think, be
brought up in emacs-devel for discussion, before
being changed in the code.

More and more (my impression), things, even major
things, are getting changed through just bug reports.
Dunno whether that's intentionally to avoid wider
discussion, but it has that effect.

Bug threads not only have less participation; they
also tend to be more focused, possibly disregarding
wider implications.

I, for one, think it's better to hash things out
first here.

Re: Recentish C-s M-y change

[Filipp Gunbin]

On 31/12/2020 08:54 -0800, Drew Adams wrote:

> In addition, this kind of thing should, I think, be
> brought up in emacs-devel for discussion, before
> being changed in the code.
>
> More and more (my impression), things, even major
> things, are getting changed through just bug reports.
> Dunno whether that's intentionally to avoid wider
> discussion, but it has that effect.
>
> Bug threads not only have less participation; they
> also tend to be more focused, possibly disregarding
> wider implications.
>
> I, for one, think it's better to hash things out
> first here.

Such visible changes are usually reflected in the NEWS.  There could be
a post-commit hook or something which would send the notification when a
change in NEWS is being committed.  For me, such a thing would be very
useful (in addition, I almost never get to read the NEWS even after new
release, this way I won't need to).

Filipp

Re: Recentish C-s M-y change

[Alfred M. Szmidt]

   More and more (my impression), things, even major
   things, are getting changed through just bug reports.
   Dunno whether that's intentionally to avoid wider
   discussion, but it has that effect.

I share that impression as well, it does seems that the modus operandi
is to change first, discuss later.  Which causes friction between all
parties -- it is not all that much to ask that changes to existing
behaviour is done by discussion first, in a small group to feel what
the reprecautions might be.

Re: Recentish C-s M-y change

[Eli Zaretskii]

> From: "Alfred M. Szmidt" <ams@gnu.org>
> Date: Fri, 01 Jan 2021 06:14:40 -0500
> Cc: larsi@gnus.org, juri@linkov.net, rms@gnu.org, emacs-devel@gnu.org
> 
>    More and more (my impression), things, even major
>    things, are getting changed through just bug reports.
>    Dunno whether that's intentionally to avoid wider
>    discussion, but it has that effect.
> 
> I share that impression as well, it does seems that the modus operandi
> is to change first, discuss later.

I think this impression might be skewed.  Many people feel the
opposite: that we discuss too much, and moreover, that starting a
discussion on emacs-devel almost invariably leads to stalemate that
blocks the proposed changes.

If someone wants to be intimately involved in the Emacs development,
he or she should subscribe to the bug list, because many issues are
discussed there (as they should be), and sometimes the conclusion is
that we should make changes.

People who cannot afford subscribing to the bug list still have the
usual means: submitting bug reports about behavior changes that annoy
them or are in their opinion wrong.  (But please note that we don't
promise to agree with every single objection or protest against a
change that was installed, we have our judgment and pour opinions.)

It is impractical to expect that every potentially annoying or
problematic change will be detected before it is committed, so I urge
people not to develop such unrealistic expectations.

Re: Recentish C-s M-y change

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

  > If someone wants to be intimately involved in the Emacs development,
  > he or she should subscribe to the bug list, because many issues are
  > discussed there (as they should be), and sometimes the conclusion is
  > that we should make changes.

I probably won't read a thread that discusses how to fix a bug.
I would not expect a decision about a change in features to be
made in such a thread.

Thus I propose a rule, which I hope people will remember to apply,
that if a change in features has been discussed inside a thread
about a specific bug, always to raise the issue on emacs-devel
afterward.

-- 
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: Recentish C-s M-y change

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: ams@gnu.org, larsi@gnus.org, emacs-devel@gnu.org,
> 	drew.adams@oracle.com, juri@linkov.net
> Date: Sat, 02 Jan 2021 00:34:04 -0500
> 
> I probably won't read a thread that discusses how to fix a bug.
> I would not expect a decision about a change in features to be
> made in such a thread.

That expectation is incorrect, both factually and in principle.
People tend to continue a discussion thread even when it wanders far
away of the original topic or issue.  Calls to change the Subject when
that happens have only very limited success.  Such is life.

> Thus I propose a rule, which I hope people will remember to apply,
> that if a change in features has been discussed inside a thread
> about a specific bug, always to raise the issue on emacs-devel
> afterward.

As a guideline, I could agree.  But as an enforced rule, I don't think
this will fly, and I don't think we should waste our limited resources
to try enforcing it.

Re: Recentish C-s M-y change

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

  > > Thus I propose a rule, which I hope people will remember to apply,
  > > that if a change in features has been discussed inside a thread
  > > about a specific bug, always to raise the issue on emacs-devel
  > > afterward.

  > As a guideline, I could agree.  But as an enforced rule, I don't think
  > this will fly, and I don't think we should waste our limited resources
  > to try enforcing it.

What is the sort of "enforcement" that seems so bad to you?
Maybe I have no intention of doing that anyway.


-- 
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: Recentish C-s M-y change

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: ams@gnu.org, juri@linkov.net, larsi@gnus.org,
> 	drew.adams@oracle.com, emacs-devel@gnu.org
> Date: Sun, 03 Jan 2021 01:01:45 -0500
> 
>   > > Thus I propose a rule, which I hope people will remember to apply,
>   > > that if a change in features has been discussed inside a thread
>   > > about a specific bug, always to raise the issue on emacs-devel
>   > > afterward.
> 
>   > As a guideline, I could agree.  But as an enforced rule, I don't think
>   > this will fly, and I don't think we should waste our limited resources
>   > to try enforcing it.
> 
> What is the sort of "enforcement" that seems so bad to you?
> Maybe I have no intention of doing that anyway.

A "rule" that is enforced is something that people are required to
abide by, and if they don't, they should expect to be reprimanded.  It
also means that changes should be rejected and/or reverted if they
weren't discussed up front on emacs-devel.

I'm opposed to this kind of enforcement.

A "guideline" means we encourage people to start discussions about
changes they think might be controversial.  This is OK IMO, and is
already being done, actually, but maybe we should encourage more.

Re: Recentish C-s M-y change

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

  > A "rule" that is enforced is something that people are required to
  > abide by, and if they don't, they should expect to be reprimanded.

That is a strict kind of enforcement.  There are gentler ways of
giving some strength to the rule, and I think they would be preferable
for this.

  >   It
  > also means that changes should be rejected and/or reverted if they
  > weren't discussed up front on emacs-devel.

Again, that is more strict than this rule calls for.

  > A "guideline" means we encourage people to start discussions about
  > changes they think might be controversial.

What I have in mind is somewhere in between the two.  Here is
what I mean.

1. When people see a UI change being discussed in a bug report context,
people should try to speak up and say, "Remember, the rule is we should
discuss this on emacs-devel.  Let's move this discussion there now!"

2. Someone should send mail to emacs-devel with a Subject line saying
"UI change proposal: <what it is>", and a body proposing and explaining
the change.

3. If someone notices the change after it is release, and objects, and
if the discussion on emacs-devel did not happen as the rule calls for,
then we would drop the usual reluctance to undo a change that had been
in a release.  That's all.

Point 3 would be the "enforcement".  It doesn't call for reprimands or
for reverting changes precipitously.  But it does have an effect, and
that would encourage people to remember and follow the rule.

4. We would not actually revert the change -- after all, some people
do like the changed behavior.  Instead, we would add a variable to
specify whether to use the changed behavior or the old behavior, and
make the old behavior the default.

This will satisfy everyone more or less.

-- 
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: Recentish C-s M-y change

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: ams@gnu.org, emacs-devel@gnu.org, larsi@gnus.org,
> 	drew.adams@oracle.com, juri@linkov.net
> Date: Mon, 04 Jan 2021 00:17:45 -0500
> 
> 1. When people see a UI change being discussed in a bug report context,
> people should try to speak up and say, "Remember, the rule is we should
> discuss this on emacs-devel.  Let's move this discussion there now!"
> 
> 2. Someone should send mail to emacs-devel with a Subject line saying
> "UI change proposal: <what it is>", and a body proposing and explaining
> the change.

People can always speak up, and someone -- anyone -- can always start
a discussion about some change they think deserves a discussion.
There's no need for rules to do that.

What I object to is a rule that a change cannot be committed before
such a discussion happens and runs to its conclusion.

> 3. If someone notices the change after it is release, and objects, and
> if the discussion on emacs-devel did not happen as the rule calls for,
> then we would drop the usual reluctance to undo a change that had been
> in a release.

I object to this as well.  I see no reason to undo a change just
because someone objects to it.  That'd mean we give single individuals
too much power, just because they post to emacs-devel.  It's a sure
recipe for stalemate.  Based on the experience, this is completely
unjustified, as in the vast majority of cases the changes are
sensible, and mistakes are in good faith and usually quickly fixed.

> 4. We would not actually revert the change -- after all, some people
> do like the changed behavior.  Instead, we would add a variable to
> specify whether to use the changed behavior or the old behavior, and
> make the old behavior the default.

Like I said, this already happens, at least as a policy.  You can find
many threads here and on the bug list where changes are requested to
become backward-compatible or provide options to revert to previous
behavior.  There's no need for any new rules here, certainly not rules
that will so significantly slow down development.

Re: Recentish C-s M-y change

[Juri Linkov]

I don't understand how this comment applies to minibuffer-local-isearch-map:

  ;; Note: Before adding more key bindings to this map, please keep in
  ;; mind that any unbound key exits Isearch and runs the command bound
  ;; to it in the local or global map.  So in effect every key unbound
  ;; in this map is implicitly bound.

It makes sense in regard to isearch-mode-map, but not minibuffer-local-isearch-map.

Re: Recentish C-s M-y change

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: rms@gnu.org,  ams@gnu.org,  emacs-devel@gnu.org,  larsi@gnus.org,
>   drew.adams@oracle.com
> Date: Mon, 04 Jan 2021 19:44:18 +0200
> 
> I don't understand how this comment applies to minibuffer-local-isearch-map:
> 
>   ;; Note: Before adding more key bindings to this map, please keep in
>   ;; mind that any unbound key exits Isearch and runs the command bound
>   ;; to it in the local or global map.  So in effect every key unbound
>   ;; in this map is implicitly bound.
> 
> It makes sense in regard to isearch-mode-map, but not minibuffer-local-isearch-map.

If you sure it isn't relevant, feel free to remove that instance of
the comment.

RE: Recentish C-s M-y change

[Drew Adams]

> It makes sense in regard to isearch-mode-map, but not minibuffer-local-
> isearch-map.

Can you please post, or point to, some info about
that (new) map?  Why was it created, for instance?

Re: Recentish C-s M-y change

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

  > > I probably won't read a thread that discusses how to fix a bug.
  > > I would not expect a decision about a change in features to be
  > > made in such a thread.

  > That expectation is incorrect, both factually and in principle.

I think we are failing to communicate.  I described an expectation
that I use to reduce the amount of work I have to do.  Whether it
is ever mistaken is simply not the point.

I expect that many other people on this list skip threads when
the thread topic does not seem interesting.  They too need
to find ways to reduce how much they have to read.


-- 
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: Recentish C-s M-y change

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: ams@gnu.org, larsi@gnus.org, emacs-devel@gnu.org,
> 	drew.adams@oracle.com, juri@linkov.net
> Date: Sun, 03 Jan 2021 01:01:55 -0500
> 
>   > > I probably won't read a thread that discusses how to fix a bug.
>   > > I would not expect a decision about a change in features to be
>   > > made in such a thread.
> 
>   > That expectation is incorrect, both factually and in principle.
> 
> I think we are failing to communicate.  I described an expectation
> that I use to reduce the amount of work I have to do.  Whether it
> is ever mistaken is simply not the point.

Each one of us can and does choose the criteria by which he or she
reads the mailing lists.  But if those criteria don't fit the reality
of how and where changes of interest are being discussed, then some of
the messages one would like to read will be necessarily missed.

A criterion that discussions about fixing a bug couldn't possibly end
up discussing behavior changes or even new features is IMO and IME
mistaken, because such shifts in the discussion's focus happen quite
frequently, and are natural.

So I'm saying that by applying such a criterion you will miss messages
that are of interest to you.

> I expect that many other people on this list skip threads when
> the thread topic does not seem interesting.  They too need
> to find ways to reduce how much they have to read.

People who skip threads based on some simplistic criteria, like their
Subject or the fact that they discuss a bug fix, risk missing messages
they might be interested in.  I don't know how to fix that on the
sending end, as we are an informal community of people with very
different interests and different levels of writing capabilities.  I
don't think we have any practical way of enforcing some discipline
that would make such simplistic criteria of selecting threads work
reliably.  This can only be handled by sophisticated enough measures
on the receiving end: some sort of smart classification of messages,
keyword searches, etc.  (I don't use any of that because I simply read
everything on both lists.)

Re: Recentish C-s M-y change

[chad]

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

I've removed the name from the following quote, because the topic I'm
bringing up is not about that person, not even the context of "their"
message, but simply and solely the sentiment quoted.

On Fri, Jan 1, 2021 at 3:15 AM someone wrote:

>  it is not all that much to ask that changes to existing
> behaviour is done by discussion first, in a small group to feel what
> the reprecautions might be.
>

This might feel true, but both academics who study software engineering and
people who manage software projects for large, medium, and small teams will
all tell you that it's very rarely borne out by experiment. In practice,
the sort of "must check first" approach to multi-person software creation
leads to some combination of massive overhead, ossification, cover-your-ass
behavior, and deteriorating team dynamics. It works in small, tightly-knit
groups with a high degree of both on-topic and incidental interaction, and
basically doesn't work otherwise*. In a widely distributed volunteer group
like most multi-person free software communities, you either have a BDFL,
you trust your developers to use their judgement (including occasionally
being wrong and recovering), or your project atrophies.

In this case, Lars was exactly right:

> Here a developer
> made a change, we tried it out for a time, I said "this is a bit
> annoying", others agreed, and the change was reverted.  This is how the
> system should work.


That said, it's fine for people to say something semantically like "I think
we might be getting a little too loose with big changes on the bleeding
edge. Maybe we should use feature branches more often?". It's possible that
that's the exact sentiment that people are trying to express, but the
realities of email lists creates a wide gulf between the above expression
and "why are these things changed without doing some rudimentary query of
users?".

I hope this helps, and doesn't just add to the noise.
~Chad

* I've seen this reported by people including researchers at MIT; at large
companies like Amazon, Boeing, Google, IBM, and Microsoft; at medium-sized
companies like Oracle (back when their software teams were medium-sized),
Cygnus, and Red Hat, and at companies so small that nobody should recognize
their names. If you're interested in the topic, I suggest Fred Brooks'
_Mythical Man-Month_ as a baseline, and his _The Design of Design_ for a
follow-up, as well as _Peopleware: Productive Projects and Teams_. (Caveat:
it's been a while since I studied this, so there are probably more recent
sources available.)

[-- Attachment #2: Type: text/html, Size: 3190 bytes --]

RE: Recentish C-s M-y change

[Drew Adams]

> > Just recently two changes at least (y-or-n-p and C-s M-y) have caused
> > grief because one didn't query even the smallest sample say in
> > emacs-devel and discuss it for a bit before making the change.
> 
> I guess because the change seemed to be non-controversial.  

Did it?  There was objection in the bug threads.
It wasn't heeded.

> It turned to be otherwise, and that can always happen.

No surprise.  The issues were brought up in the
bug threads - "it turned out to be" long ago.

RE: Recentish C-s M-y change

[Drew Adams]

> >    More and more (my impression), things, even major
> >    things, are getting changed through just bug reports.
> >    Dunno whether that's intentionally to avoid wider
> >    discussion, but it has that effect.
> >
> > I share that impression as well, it does seems that the modus operandi
> > is to change first, discuss later.
> 
> I think this impression might be skewed.  Many people feel the
> opposite: that we discuss too much, and moreover, that starting a
> discussion on emacs-devel almost invariably leads to stalemate that
> blocks the proposed changes.

Sounds to me like you're rather confirming my
impression - just expressing (skewing?) it a bit
differently.

Someone who wants to make a change and not risk
discussion that involves actually _proposing_ the
change, and that might lead to the change ultimately
not being agreed to, may decide to do an end-run, by
"fixing" a "bug" instead.

We all know here that discussion on emacs-devel does
NOT "invariably" lead to stalemate that blocks changes.

There can in fact be no "stalemate", because we have
a decider - you.  Instead of stalemate, end-runners
might avoid a wider discussion that ends with your
decision to "block" the change.  (A decision I'm
often in agreement with, FWIW.)

> If someone wants to be intimately involved in the Emacs development,
> he or she should subscribe to the bug list, because many issues are
> discussed there (as they should be), and sometimes the conclusion is
> that we should make changes.

Of course.  Issues.  And even new feature requests.

But as mentioned, lately there have been some
pretty _big_ changes made that way.

It's a judgment call whether something should be
discussed in a bug thread or on emacs-devel.

My impression (and it's only that), is that more
and more some are choosing to do the former -
perhaps, as you suggest, to avoid a wider or longer
discussion, which might involve greater risk of
counter-arguments or push-back.

> It is impractical to expect that every potentially
> annoying or problematic change will be detected
> before it is committed, so I urge people not to
> develop such unrealistic expectations.

I don't think anyone has such expectations.  This
isn't a black-&-white thing.  It doesn't help much,
I think, to hypothesize expectations of "every"
this or that.