* RE: Recentish C-s M-y change [not found] ` <<83wnwwg8iu.fsf@gnu.org> @ 2021-01-01 19:10 ` Drew Adams 0 siblings, 0 replies; 101+ messages in thread From: Drew Adams @ 2021-01-01 19:10 UTC (permalink / raw) To: Eli Zaretskii, Alfred M. Szmidt; +Cc: larsi, emacs-devel, rms, drew.adams, juri > > 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
[parent not found: <<87r1na4tyu.fsf@gnus.org>]
[parent not found: <<87tus6tj7s.fsf@mail.linkov.net>]
[parent not found: <<87a6txigm1.fsf@gnus.org>]
[parent not found: <<874kk5lzew.fsf@mail.linkov.net>]
[parent not found: <<m2sg7o8nq3.fsf@fastmail.fm>]
[parent not found: <<87eej8ifll.fsf@mail.linkov.net>]
[parent not found: <<X+wLPA/Q8TwWYjM5@protected.rcdrun.com>]
[parent not found: <<87h7o3k5b5.fsf@mail.linkov.net>]
[parent not found: <<E1kuqup-0001Ly-18@fencepost.gnu.org>]
[parent not found: <<E1kuvRe-00051d-SB@fencepost.gnu.org>]
* RE: Recentish C-s M-y change [not found] ` <<E1kuvRe-00051d-SB@fencepost.gnu.org> @ 2020-12-31 16:54 ` Drew Adams 2020-12-31 17:18 ` Filipp Gunbin 2021-01-01 11:14 ` Alfred M. Szmidt [not found] ` <<83v9cigiaa.fsf@gnu.org> 1 sibling, 2 replies; 101+ messages in thread From: Drew Adams @ 2020-12-31 16:54 UTC (permalink / raw) To: Alfred M. Szmidt, rms; +Cc: larsi, juri, emacs-devel > 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2020-12-31 16:54 ` Drew Adams @ 2020-12-31 17:18 ` Filipp Gunbin 2021-01-01 11:14 ` Alfred M. Szmidt 1 sibling, 0 replies; 101+ messages in thread From: Filipp Gunbin @ 2020-12-31 17:18 UTC (permalink / raw) To: Drew Adams; +Cc: larsi, Alfred M. Szmidt, emacs-devel, rms, juri 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2020-12-31 16:54 ` Drew Adams 2020-12-31 17:18 ` Filipp Gunbin @ 2021-01-01 11:14 ` Alfred M. Szmidt 2021-01-01 12:13 ` Eli Zaretskii 2021-01-01 22:47 ` chad 1 sibling, 2 replies; 101+ messages in thread From: Alfred M. Szmidt @ 2021-01-01 11:14 UTC (permalink / raw) To: Drew Adams; +Cc: larsi, juri, rms, emacs-devel 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2021-01-01 11:14 ` Alfred M. Szmidt @ 2021-01-01 12:13 ` Eli Zaretskii 2021-01-02 5:34 ` Richard Stallman 2021-01-01 22:47 ` chad 1 sibling, 1 reply; 101+ messages in thread From: Eli Zaretskii @ 2021-01-01 12:13 UTC (permalink / raw) To: Alfred M. Szmidt; +Cc: larsi, emacs-devel, rms, drew.adams, juri > 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2021-01-01 12:13 ` Eli Zaretskii @ 2021-01-02 5:34 ` Richard Stallman 2021-01-02 7:15 ` Eli Zaretskii 0 siblings, 1 reply; 101+ messages in thread From: Richard Stallman @ 2021-01-02 5:34 UTC (permalink / raw) To: Eli Zaretskii; +Cc: ams, juri, larsi, drew.adams, emacs-devel [[[ 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) ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2021-01-02 5:34 ` Richard Stallman @ 2021-01-02 7:15 ` Eli Zaretskii 2021-01-03 6:01 ` Richard Stallman 2021-01-03 6:01 ` Richard Stallman 0 siblings, 2 replies; 101+ messages in thread From: Eli Zaretskii @ 2021-01-02 7:15 UTC (permalink / raw) To: rms; +Cc: ams, juri, larsi, drew.adams, emacs-devel > 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2021-01-02 7:15 ` Eli Zaretskii @ 2021-01-03 6:01 ` Richard Stallman 2021-01-03 15:05 ` Eli Zaretskii 2021-01-03 6:01 ` Richard Stallman 1 sibling, 1 reply; 101+ messages in thread From: Richard Stallman @ 2021-01-03 6:01 UTC (permalink / raw) To: Eli Zaretskii; +Cc: ams, emacs-devel, larsi, drew.adams, juri [[[ 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) ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2021-01-03 6:01 ` Richard Stallman @ 2021-01-03 15:05 ` Eli Zaretskii 2021-01-04 5:17 ` Richard Stallman 0 siblings, 1 reply; 101+ messages in thread From: Eli Zaretskii @ 2021-01-03 15:05 UTC (permalink / raw) To: rms; +Cc: ams, emacs-devel, larsi, drew.adams, juri > 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2021-01-03 15:05 ` Eli Zaretskii @ 2021-01-04 5:17 ` Richard Stallman 2021-01-04 15:03 ` Eli Zaretskii 0 siblings, 1 reply; 101+ messages in thread From: Richard Stallman @ 2021-01-04 5:17 UTC (permalink / raw) To: Eli Zaretskii; +Cc: ams, juri, larsi, drew.adams, emacs-devel [[[ 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) ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2021-01-04 5:17 ` Richard Stallman @ 2021-01-04 15:03 ` Eli Zaretskii 2021-01-04 17:44 ` Juri Linkov 0 siblings, 1 reply; 101+ messages in thread From: Eli Zaretskii @ 2021-01-04 15:03 UTC (permalink / raw) To: rms; +Cc: ams, juri, larsi, drew.adams, emacs-devel > 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2021-01-04 15:03 ` Eli Zaretskii @ 2021-01-04 17:44 ` Juri Linkov 2021-01-04 18:20 ` Eli Zaretskii 2021-01-04 18:22 ` Drew Adams 0 siblings, 2 replies; 101+ messages in thread From: Juri Linkov @ 2021-01-04 17:44 UTC (permalink / raw) To: Eli Zaretskii; +Cc: larsi, ams, rms, drew.adams, emacs-devel 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2021-01-04 17:44 ` Juri Linkov @ 2021-01-04 18:20 ` Eli Zaretskii 2021-01-04 18:22 ` Drew Adams 1 sibling, 0 replies; 101+ messages in thread From: Eli Zaretskii @ 2021-01-04 18:20 UTC (permalink / raw) To: Juri Linkov; +Cc: larsi, ams, rms, drew.adams, emacs-devel > 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* RE: Recentish C-s M-y change 2021-01-04 17:44 ` Juri Linkov 2021-01-04 18:20 ` Eli Zaretskii @ 2021-01-04 18:22 ` Drew Adams 1 sibling, 0 replies; 101+ messages in thread From: Drew Adams @ 2021-01-04 18:22 UTC (permalink / raw) To: Juri Linkov, Eli Zaretskii; +Cc: larsi, ams, rms, emacs-devel > 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? ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2021-01-02 7:15 ` Eli Zaretskii 2021-01-03 6:01 ` Richard Stallman @ 2021-01-03 6:01 ` Richard Stallman 2021-01-03 15:09 ` Eli Zaretskii 1 sibling, 1 reply; 101+ messages in thread From: Richard Stallman @ 2021-01-03 6:01 UTC (permalink / raw) To: Eli Zaretskii; +Cc: ams, juri, larsi, drew.adams, emacs-devel [[[ 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) ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2021-01-03 6:01 ` Richard Stallman @ 2021-01-03 15:09 ` Eli Zaretskii 0 siblings, 0 replies; 101+ messages in thread From: Eli Zaretskii @ 2021-01-03 15:09 UTC (permalink / raw) To: rms; +Cc: ams, juri, larsi, drew.adams, emacs-devel > 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.) ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2021-01-01 11:14 ` Alfred M. Szmidt 2021-01-01 12:13 ` Eli Zaretskii @ 2021-01-01 22:47 ` chad 1 sibling, 0 replies; 101+ messages in thread From: chad @ 2021-01-01 22:47 UTC (permalink / raw) To: EMACS development team [-- 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 --] ^ permalink raw reply [flat|nested] 101+ messages in thread
[parent not found: <<83v9cigiaa.fsf@gnu.org>]
[parent not found: <<E1kv065-0004mD-6v@fencepost.gnu.org>]
[parent not found: <<83k0sygc73.fsf@gnu.org>]
* RE: Recentish C-s M-y change [not found] ` <<83k0sygc73.fsf@gnu.org> @ 2020-12-31 17:02 ` Drew Adams 0 siblings, 0 replies; 101+ messages in thread From: Drew Adams @ 2020-12-31 17:02 UTC (permalink / raw) To: Eli Zaretskii, Alfred M. Szmidt; +Cc: larsi, emacs-devel, rms, juri > > 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Recentish C-s M-y change @ 2020-12-28 1:09 Lars Ingebrigtsen 2020-12-28 8:45 ` Juri Linkov 2020-12-29 5:56 ` Richard Stallman 0 siblings, 2 replies; 101+ messages in thread From: Lars Ingebrigtsen @ 2020-12-28 1:09 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2020-12-28 1:09 Lars Ingebrigtsen @ 2020-12-28 8:45 ` Juri Linkov 2020-12-28 17:19 ` Juri Linkov ` (3 more replies) 2020-12-29 5:56 ` Richard Stallman 1 sibling, 4 replies; 101+ messages in thread From: Juri Linkov @ 2020-12-28 8:45 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2020-12-28 8:45 ` Juri Linkov @ 2020-12-28 17:19 ` Juri Linkov 2020-12-28 17:30 ` Filipp Gunbin ` (2 subsequent siblings) 3 siblings, 0 replies; 101+ messages in thread From: Juri Linkov @ 2020-12-28 17:19 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2020-12-28 8:45 ` Juri Linkov 2020-12-28 17:19 ` Juri Linkov @ 2020-12-28 17:30 ` Filipp Gunbin 2020-12-28 17:50 ` Clément Pit-Claudel 2020-12-29 0:46 ` Lars Ingebrigtsen 2020-12-29 6:01 ` Richard Stallman 3 siblings, 1 reply; 101+ messages in thread From: Filipp Gunbin @ 2020-12-28 17:30 UTC (permalink / raw) To: Juri Linkov; +Cc: Lars Ingebrigtsen, emacs-devel 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2020-12-28 17:30 ` Filipp Gunbin @ 2020-12-28 17:50 ` Clément Pit-Claudel 2020-12-29 6:05 ` Richard Stallman 0 siblings, 1 reply; 101+ messages in thread From: Clément Pit-Claudel @ 2020-12-28 17:50 UTC (permalink / raw) To: emacs-devel 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? ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2020-12-28 17:50 ` Clément Pit-Claudel @ 2020-12-29 6:05 ` Richard Stallman 0 siblings, 0 replies; 101+ messages in thread From: Richard Stallman @ 2020-12-29 6:05 UTC (permalink / raw) To: Clément Pit-Claudel; +Cc: emacs-devel [[[ 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) ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2020-12-28 8:45 ` Juri Linkov 2020-12-28 17:19 ` Juri Linkov 2020-12-28 17:30 ` Filipp Gunbin @ 2020-12-29 0:46 ` Lars Ingebrigtsen 2020-12-29 9:34 ` Juri Linkov 2020-12-29 6:01 ` Richard Stallman 3 siblings, 1 reply; 101+ messages in thread From: Lars Ingebrigtsen @ 2020-12-29 0:46 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2020-12-29 0:46 ` Lars Ingebrigtsen @ 2020-12-29 9:34 ` Juri Linkov 2020-12-29 17:25 ` Drew Adams 2020-12-29 18:35 ` Filipp Gunbin 0 siblings, 2 replies; 101+ messages in thread From: Juri Linkov @ 2020-12-29 9:34 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: emacs-devel >> 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* RE: Recentish C-s M-y change 2020-12-29 9:34 ` Juri Linkov @ 2020-12-29 17:25 ` Drew Adams 2020-12-30 4:57 ` Jean Louis 2020-12-30 5:26 ` Richard Stallman 2020-12-29 18:35 ` Filipp Gunbin 1 sibling, 2 replies; 101+ messages in thread From: Drew Adams @ 2020-12-29 17:25 UTC (permalink / raw) To: Juri Linkov, Lars Ingebrigtsen; +Cc: emacs-devel > > 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2020-12-29 17:25 ` Drew Adams @ 2020-12-30 4:57 ` Jean Louis 2020-12-30 5:26 ` Richard Stallman 1 sibling, 0 replies; 101+ messages in thread From: Jean Louis @ 2020-12-30 4:57 UTC (permalink / raw) To: emacs-devel * 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2020-12-29 17:25 ` Drew Adams 2020-12-30 4:57 ` Jean Louis @ 2020-12-30 5:26 ` Richard Stallman 2020-12-31 15:28 ` Gregory Heytings via Emacs development discussions. 1 sibling, 1 reply; 101+ messages in thread From: Richard Stallman @ 2020-12-30 5:26 UTC (permalink / raw) To: Drew Adams; +Cc: larsi, emacs-devel, juri [[[ 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) ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2020-12-30 5:26 ` Richard Stallman @ 2020-12-31 15:28 ` Gregory Heytings via Emacs development discussions. 2021-01-01 7:21 ` Richard Stallman 0 siblings, 1 reply; 101+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2020-12-31 15:28 UTC (permalink / raw) To: Richard Stallman; +Cc: emacs-devel > > 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? ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2020-12-31 15:28 ` Gregory Heytings via Emacs development discussions. @ 2021-01-01 7:21 ` Richard Stallman 2021-01-01 9:15 ` Gregory Heytings via Emacs development discussions. 2021-01-01 19:12 ` Drew Adams 0 siblings, 2 replies; 101+ messages in thread From: Richard Stallman @ 2021-01-01 7:21 UTC (permalink / raw) To: Gregory Heytings; +Cc: emacs-devel [[[ 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) ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2021-01-01 7:21 ` Richard Stallman @ 2021-01-01 9:15 ` Gregory Heytings via Emacs development discussions. 2021-01-02 5:35 ` Richard Stallman 2021-01-01 19:12 ` Drew Adams 1 sibling, 1 reply; 101+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2021-01-01 9:15 UTC (permalink / raw) To: Richard Stallman; +Cc: emacs-devel >> 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). ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2021-01-01 9:15 ` Gregory Heytings via Emacs development discussions. @ 2021-01-02 5:35 ` Richard Stallman 2021-01-02 9:03 ` Gregory Heytings via Emacs development discussions. 0 siblings, 1 reply; 101+ messages in thread From: Richard Stallman @ 2021-01-02 5:35 UTC (permalink / raw) To: Gregory Heytings; +Cc: emacs-devel [[[ 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) ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2021-01-02 5:35 ` Richard Stallman @ 2021-01-02 9:03 ` Gregory Heytings via Emacs development discussions. 2021-01-02 9:27 ` Alfred M. Szmidt 0 siblings, 1 reply; 101+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2021-01-02 9:03 UTC (permalink / raw) To: Richard Stallman; +Cc: emacs-devel >> 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)))) ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2021-01-02 9:03 ` Gregory Heytings via Emacs development discussions. @ 2021-01-02 9:27 ` Alfred M. Szmidt 2021-01-02 11:55 ` Gregory Heytings via Emacs development discussions. 0 siblings, 1 reply; 101+ messages in thread From: Alfred M. Szmidt @ 2021-01-02 9:27 UTC (permalink / raw) To: Gregory Heytings; +Cc: rms, emacs-devel >> 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2021-01-02 9:27 ` Alfred M. Szmidt @ 2021-01-02 11:55 ` Gregory Heytings via Emacs development discussions. 2021-01-03 5:58 ` Richard Stallman 0 siblings, 1 reply; 101+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2021-01-02 11:55 UTC (permalink / raw) To: Alfred M. Szmidt; +Cc: rms, emacs-devel >>>> 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2021-01-02 11:55 ` Gregory Heytings via Emacs development discussions. @ 2021-01-03 5:58 ` Richard Stallman 2021-01-04 0:04 ` Drew Adams 2021-01-04 9:23 ` Gregory Heytings via Emacs development discussions. 0 siblings, 2 replies; 101+ messages in thread From: Richard Stallman @ 2021-01-03 5:58 UTC (permalink / raw) To: Gregory Heytings; +Cc: ams, emacs-devel [[[ 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) ^ permalink raw reply [flat|nested] 101+ messages in thread
* RE: Recentish C-s M-y change 2021-01-03 5:58 ` Richard Stallman @ 2021-01-04 0:04 ` Drew Adams 2021-01-05 6:28 ` Richard Stallman 2021-01-04 9:23 ` Gregory Heytings via Emacs development discussions. 1 sibling, 1 reply; 101+ messages in thread From: Drew Adams @ 2021-01-04 0:04 UTC (permalink / raw) To: rms, Gregory Heytings; +Cc: ams, emacs-devel > 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2021-01-04 0:04 ` Drew Adams @ 2021-01-05 6:28 ` Richard Stallman 2021-01-05 16:30 ` Drew Adams 0 siblings, 1 reply; 101+ messages in thread From: Richard Stallman @ 2021-01-05 6:28 UTC (permalink / raw) To: Drew Adams; +Cc: ghe, ams, emacs-devel [[[ 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) ^ permalink raw reply [flat|nested] 101+ messages in thread
* RE: Recentish C-s M-y change 2021-01-05 6:28 ` Richard Stallman @ 2021-01-05 16:30 ` Drew Adams 2021-01-06 5:14 ` Richard Stallman 0 siblings, 1 reply; 101+ messages in thread From: Drew Adams @ 2021-01-05 16:30 UTC (permalink / raw) To: rms; +Cc: ghe, ams, emacs-devel > > > 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.) ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2021-01-05 16:30 ` Drew Adams @ 2021-01-06 5:14 ` Richard Stallman 2021-01-06 9:41 ` Gregory Heytings via Emacs development discussions. 0 siblings, 1 reply; 101+ messages in thread From: Richard Stallman @ 2021-01-06 5:14 UTC (permalink / raw) To: Drew Adams; +Cc: ghe, ams, emacs-devel [[[ 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) ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2021-01-06 5:14 ` Richard Stallman @ 2021-01-06 9:41 ` Gregory Heytings via Emacs development discussions. 2021-01-08 6:17 ` Richard Stallman 0 siblings, 1 reply; 101+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2021-01-06 9:41 UTC (permalink / raw) To: Richard Stallman; +Cc: ams, Drew Adams, emacs-devel > > 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2021-01-06 9:41 ` Gregory Heytings via Emacs development discussions. @ 2021-01-08 6:17 ` Richard Stallman 0 siblings, 0 replies; 101+ messages in thread From: Richard Stallman @ 2021-01-08 6:17 UTC (permalink / raw) To: Gregory Heytings; +Cc: ams, drew.adams, emacs-devel [[[ 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) ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2021-01-03 5:58 ` Richard Stallman 2021-01-04 0:04 ` Drew Adams @ 2021-01-04 9:23 ` Gregory Heytings via Emacs development discussions. 2021-01-05 6:44 ` Richard Stallman 1 sibling, 1 reply; 101+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2021-01-04 9:23 UTC (permalink / raw) To: Richard Stallman; +Cc: ams, emacs-devel > > 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2021-01-04 9:23 ` Gregory Heytings via Emacs development discussions. @ 2021-01-05 6:44 ` Richard Stallman 2021-01-06 0:13 ` Gregory Heytings via Emacs development discussions. 0 siblings, 1 reply; 101+ messages in thread From: Richard Stallman @ 2021-01-05 6:44 UTC (permalink / raw) To: Gregory Heytings; +Cc: ams, emacs-devel [[[ 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) ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2021-01-05 6:44 ` Richard Stallman @ 2021-01-06 0:13 ` Gregory Heytings via Emacs development discussions. 2021-01-07 7:39 ` Richard Stallman 0 siblings, 1 reply; 101+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2021-01-06 0:13 UTC (permalink / raw) To: Richard Stallman; +Cc: ams, emacs-devel >> 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2021-01-06 0:13 ` Gregory Heytings via Emacs development discussions. @ 2021-01-07 7:39 ` Richard Stallman 0 siblings, 0 replies; 101+ messages in thread From: Richard Stallman @ 2021-01-07 7:39 UTC (permalink / raw) To: Gregory Heytings; +Cc: ams, emacs-devel [[[ 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) ^ permalink raw reply [flat|nested] 101+ messages in thread
* RE: Recentish C-s M-y change 2021-01-01 7:21 ` Richard Stallman 2021-01-01 9:15 ` Gregory Heytings via Emacs development discussions. @ 2021-01-01 19:12 ` Drew Adams 1 sibling, 0 replies; 101+ messages in thread From: Drew Adams @ 2021-01-01 19:12 UTC (permalink / raw) To: rms, Gregory Heytings; +Cc: emacs-devel > 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.) ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2020-12-29 9:34 ` Juri Linkov 2020-12-29 17:25 ` Drew Adams @ 2020-12-29 18:35 ` Filipp Gunbin 2020-12-29 19:20 ` Juri Linkov 2020-12-30 5:04 ` Jean Louis 1 sibling, 2 replies; 101+ messages in thread From: Filipp Gunbin @ 2020-12-29 18:35 UTC (permalink / raw) To: Juri Linkov; +Cc: Lars Ingebrigtsen, emacs-devel 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2020-12-29 18:35 ` Filipp Gunbin @ 2020-12-29 19:20 ` Juri Linkov 2020-12-30 2:45 ` Lars Ingebrigtsen ` (2 more replies) 2020-12-30 5:04 ` Jean Louis 1 sibling, 3 replies; 101+ messages in thread From: Juri Linkov @ 2020-12-29 19:20 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: emacs-devel >> 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2020-12-29 19:20 ` Juri Linkov @ 2020-12-30 2:45 ` Lars Ingebrigtsen 2020-12-30 5:08 ` Jean Louis 2020-12-30 15:05 ` Filipp Gunbin 2 siblings, 0 replies; 101+ messages in thread From: Lars Ingebrigtsen @ 2020-12-30 2:45 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2020-12-29 19:20 ` Juri Linkov 2020-12-30 2:45 ` Lars Ingebrigtsen @ 2020-12-30 5:08 ` Jean Louis 2020-12-30 9:32 ` Juri Linkov 2020-12-30 15:05 ` Filipp Gunbin 2 siblings, 1 reply; 101+ messages in thread From: Jean Louis @ 2020-12-30 5:08 UTC (permalink / raw) To: Juri Linkov; +Cc: Lars Ingebrigtsen, emacs-devel * 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2020-12-30 5:08 ` Jean Louis @ 2020-12-30 9:32 ` Juri Linkov 2020-12-30 10:08 ` Andreas Röhler ` (4 more replies) 0 siblings, 5 replies; 101+ messages in thread From: Juri Linkov @ 2020-12-30 9:32 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: emacs-devel >> 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2020-12-30 9:32 ` Juri Linkov @ 2020-12-30 10:08 ` Andreas Röhler 2020-12-30 11:13 ` Gregory Heytings via Emacs development discussions. ` (3 subsequent siblings) 4 siblings, 0 replies; 101+ messages in thread From: Andreas Röhler @ 2020-12-30 10:08 UTC (permalink / raw) To: emacs-devel; +Cc: Juri Linkov 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2020-12-30 9:32 ` Juri Linkov 2020-12-30 10:08 ` Andreas Röhler @ 2020-12-30 11:13 ` Gregory Heytings via Emacs development discussions. 2020-12-30 15:12 ` Filipp Gunbin 2020-12-31 5:54 ` Richard Stallman 2020-12-30 15:08 ` Filipp Gunbin ` (2 subsequent siblings) 4 siblings, 2 replies; 101+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2020-12-30 11:13 UTC (permalink / raw) To: Juri Linkov; +Cc: Lars Ingebrigtsen, emacs-devel > > 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)))) ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2020-12-30 11:13 ` Gregory Heytings via Emacs development discussions. @ 2020-12-30 15:12 ` Filipp Gunbin 2020-12-31 15:18 ` Gregory Heytings via Emacs development discussions. 2020-12-31 5:54 ` Richard Stallman 1 sibling, 1 reply; 101+ messages in thread From: Filipp Gunbin @ 2020-12-30 15:12 UTC (permalink / raw) To: Gregory Heytings via Emacs development discussions. Cc: Gregory Heytings, Lars Ingebrigtsen, Juri Linkov 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2020-12-30 15:12 ` Filipp Gunbin @ 2020-12-31 15:18 ` Gregory Heytings via Emacs development discussions. 2020-12-31 17:09 ` Filipp Gunbin 0 siblings, 1 reply; 101+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2020-12-31 15:18 UTC (permalink / raw) To: Filipp Gunbin; +Cc: emacs-devel >> 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2020-12-31 15:18 ` Gregory Heytings via Emacs development discussions. @ 2020-12-31 17:09 ` Filipp Gunbin 2020-12-31 19:09 ` Gregory Heytings via Emacs development discussions. 0 siblings, 1 reply; 101+ messages in thread From: Filipp Gunbin @ 2020-12-31 17:09 UTC (permalink / raw) To: Gregory Heytings; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2020-12-31 17:09 ` Filipp Gunbin @ 2020-12-31 19:09 ` Gregory Heytings via Emacs development discussions. 2021-01-04 17:50 ` Juri Linkov 0 siblings, 1 reply; 101+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2020-12-31 19:09 UTC (permalink / raw) To: Filipp Gunbin; +Cc: emacs-devel > > 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2020-12-31 19:09 ` Gregory Heytings via Emacs development discussions. @ 2021-01-04 17:50 ` Juri Linkov 2021-01-04 18:22 ` Gregory Heytings via Emacs development discussions. 0 siblings, 1 reply; 101+ messages in thread From: Juri Linkov @ 2021-01-04 17:50 UTC (permalink / raw) To: Gregory Heytings via Emacs development discussions. Cc: Gregory Heytings, Filipp Gunbin > 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2021-01-04 17:50 ` Juri Linkov @ 2021-01-04 18:22 ` Gregory Heytings via Emacs development discussions. 2021-01-13 18:19 ` Juri Linkov 0 siblings, 1 reply; 101+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2021-01-04 18:22 UTC (permalink / raw) To: Juri Linkov; +Cc: Filipp Gunbin, emacs-devel >> 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2021-01-04 18:22 ` Gregory Heytings via Emacs development discussions. @ 2021-01-13 18:19 ` Juri Linkov 2021-01-13 19:34 ` Filipp Gunbin 2021-01-27 22:01 ` Gregory Heytings 0 siblings, 2 replies; 101+ messages in thread From: Juri Linkov @ 2021-01-13 18:19 UTC (permalink / raw) To: Gregory Heytings; +Cc: Filipp Gunbin, emacs-devel >>> 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2021-01-13 18:19 ` Juri Linkov @ 2021-01-13 19:34 ` Filipp Gunbin 2021-01-14 8:44 ` Juri Linkov 2021-01-27 22:01 ` Gregory Heytings 1 sibling, 1 reply; 101+ messages in thread From: Filipp Gunbin @ 2021-01-13 19:34 UTC (permalink / raw) To: Juri Linkov; +Cc: Gregory Heytings, emacs-devel 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2021-01-13 19:34 ` Filipp Gunbin @ 2021-01-14 8:44 ` Juri Linkov 2021-01-14 15:34 ` Filipp Gunbin 0 siblings, 1 reply; 101+ messages in thread From: Juri Linkov @ 2021-01-14 8:44 UTC (permalink / raw) To: Gregory Heytings; +Cc: emacs-devel >>>>> 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2021-01-14 8:44 ` Juri Linkov @ 2021-01-14 15:34 ` Filipp Gunbin 0 siblings, 0 replies; 101+ messages in thread From: Filipp Gunbin @ 2021-01-14 15:34 UTC (permalink / raw) To: Juri Linkov; +Cc: Gregory Heytings, emacs-devel 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... ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2021-01-13 18:19 ` Juri Linkov 2021-01-13 19:34 ` Filipp Gunbin @ 2021-01-27 22:01 ` Gregory Heytings 2021-01-28 8:58 ` Juri Linkov 1 sibling, 1 reply; 101+ messages in thread From: Gregory Heytings @ 2021-01-27 22:01 UTC (permalink / raw) To: emacs-devel >>>> 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2021-01-27 22:01 ` Gregory Heytings @ 2021-01-28 8:58 ` Juri Linkov 2021-01-30 5:54 ` Richard Stallman 2021-01-30 10:42 ` Gregory Heytings 0 siblings, 2 replies; 101+ messages in thread From: Juri Linkov @ 2021-01-28 8:58 UTC (permalink / raw) To: Gregory Heytings; +Cc: emacs-devel >> 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2021-01-28 8:58 ` Juri Linkov @ 2021-01-30 5:54 ` Richard Stallman 2021-01-30 10:12 ` Gregory Heytings 2021-01-30 10:42 ` Gregory Heytings 1 sibling, 1 reply; 101+ messages in thread From: Richard Stallman @ 2021-01-30 5:54 UTC (permalink / raw) To: Juri Linkov; +Cc: gregory, emacs-devel [[[ 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) ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2021-01-30 5:54 ` Richard Stallman @ 2021-01-30 10:12 ` Gregory Heytings 2021-02-02 5:36 ` Richard Stallman 0 siblings, 1 reply; 101+ messages in thread From: Gregory Heytings @ 2021-01-30 10:12 UTC (permalink / raw) To: Richard Stallman; +Cc: emacs-devel >>> 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). ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2021-01-30 10:12 ` Gregory Heytings @ 2021-02-02 5:36 ` Richard Stallman 0 siblings, 0 replies; 101+ messages in thread From: Richard Stallman @ 2021-02-02 5:36 UTC (permalink / raw) To: Gregory Heytings; +Cc: emacs-devel [[[ 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) ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2021-01-28 8:58 ` Juri Linkov 2021-01-30 5:54 ` Richard Stallman @ 2021-01-30 10:42 ` Gregory Heytings 2021-01-30 18:37 ` Juri Linkov 1 sibling, 1 reply; 101+ messages in thread From: Gregory Heytings @ 2021-01-30 10:42 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel >> 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2021-01-30 10:42 ` Gregory Heytings @ 2021-01-30 18:37 ` Juri Linkov 0 siblings, 0 replies; 101+ messages in thread From: Juri Linkov @ 2021-01-30 18:37 UTC (permalink / raw) To: Gregory Heytings; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2020-12-30 11:13 ` Gregory Heytings via Emacs development discussions. 2020-12-30 15:12 ` Filipp Gunbin @ 2020-12-31 5:54 ` Richard Stallman 2020-12-31 15:29 ` Gregory Heytings via Emacs development discussions. 1 sibling, 1 reply; 101+ messages in thread From: Richard Stallman @ 2020-12-31 5:54 UTC (permalink / raw) To: Gregory Heytings; +Cc: larsi, emacs-devel, juri [[[ 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) ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2020-12-31 5:54 ` Richard Stallman @ 2020-12-31 15:29 ` Gregory Heytings via Emacs development discussions. 2021-01-01 7:21 ` Richard Stallman 0 siblings, 1 reply; 101+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2020-12-31 15:29 UTC (permalink / raw) To: Richard Stallman; +Cc: emacs-devel >> 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". ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2020-12-31 15:29 ` Gregory Heytings via Emacs development discussions. @ 2021-01-01 7:21 ` Richard Stallman 2021-01-01 8:02 ` Eli Zaretskii 0 siblings, 1 reply; 101+ messages in thread From: Richard Stallman @ 2021-01-01 7:21 UTC (permalink / raw) To: Gregory Heytings; +Cc: emacs-devel [[[ 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) ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2021-01-01 7:21 ` Richard Stallman @ 2021-01-01 8:02 ` Eli Zaretskii 2021-01-02 5:28 ` Richard Stallman 0 siblings, 1 reply; 101+ messages in thread From: Eli Zaretskii @ 2021-01-01 8:02 UTC (permalink / raw) To: rms; +Cc: ghe, emacs-devel > 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2021-01-01 8:02 ` Eli Zaretskii @ 2021-01-02 5:28 ` Richard Stallman 2021-01-02 7:09 ` Eli Zaretskii 0 siblings, 1 reply; 101+ messages in thread From: Richard Stallman @ 2021-01-02 5:28 UTC (permalink / raw) To: Eli Zaretskii; +Cc: ghe, emacs-devel [[[ 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) ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2021-01-02 5:28 ` Richard Stallman @ 2021-01-02 7:09 ` Eli Zaretskii 0 siblings, 0 replies; 101+ messages in thread From: Eli Zaretskii @ 2021-01-02 7:09 UTC (permalink / raw) To: rms; +Cc: ghe, emacs-devel > 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2020-12-30 9:32 ` Juri Linkov 2020-12-30 10:08 ` Andreas Röhler 2020-12-30 11:13 ` Gregory Heytings via Emacs development discussions. @ 2020-12-30 15:08 ` Filipp Gunbin 2020-12-30 17:32 ` Drew Adams 2020-12-31 5:54 ` Richard Stallman 4 siblings, 0 replies; 101+ messages in thread From: Filipp Gunbin @ 2020-12-30 15:08 UTC (permalink / raw) To: Juri Linkov; +Cc: Lars Ingebrigtsen, emacs-devel 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* RE: Recentish C-s M-y change 2020-12-30 9:32 ` Juri Linkov ` (2 preceding siblings ...) 2020-12-30 15:08 ` Filipp Gunbin @ 2020-12-30 17:32 ` Drew Adams 2020-12-31 5:54 ` Richard Stallman 4 siblings, 0 replies; 101+ messages in thread From: Drew Adams @ 2020-12-30 17:32 UTC (permalink / raw) To: Juri Linkov, Lars Ingebrigtsen; +Cc: emacs-devel > 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? ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2020-12-30 9:32 ` Juri Linkov ` (3 preceding siblings ...) 2020-12-30 17:32 ` Drew Adams @ 2020-12-31 5:54 ` Richard Stallman 2020-12-31 10:44 ` Alfred M. Szmidt 2020-12-31 15:29 ` Gregory Heytings via Emacs development discussions. 4 siblings, 2 replies; 101+ messages in thread From: Richard Stallman @ 2020-12-31 5:54 UTC (permalink / raw) To: Juri Linkov; +Cc: larsi, emacs-devel [[[ 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) ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2020-12-31 5:54 ` Richard Stallman @ 2020-12-31 10:44 ` Alfred M. Szmidt 2020-12-31 11:18 ` Lars Ingebrigtsen 2020-12-31 14:30 ` Eli Zaretskii 2020-12-31 15:29 ` Gregory Heytings via Emacs development discussions. 1 sibling, 2 replies; 101+ messages in thread From: Alfred M. Szmidt @ 2020-12-31 10:44 UTC (permalink / raw) To: rms; +Cc: larsi, emacs-devel, juri > 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2020-12-31 10:44 ` Alfred M. Szmidt @ 2020-12-31 11:18 ` Lars Ingebrigtsen 2020-12-31 11:29 ` Alfred M. Szmidt 2020-12-31 14:30 ` Eli Zaretskii 1 sibling, 1 reply; 101+ messages in thread From: Lars Ingebrigtsen @ 2020-12-31 11:18 UTC (permalink / raw) To: Alfred M. Szmidt; +Cc: emacs-devel, rms, juri "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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2020-12-31 11:18 ` Lars Ingebrigtsen @ 2020-12-31 11:29 ` Alfred M. Szmidt 2021-01-01 10:53 ` Lars Ingebrigtsen 0 siblings, 1 reply; 101+ messages in thread From: Alfred M. Szmidt @ 2020-12-31 11:29 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: emacs-devel, rms, juri "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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2020-12-31 11:29 ` Alfred M. Szmidt @ 2021-01-01 10:53 ` Lars Ingebrigtsen 2021-01-01 11:14 ` Alfred M. Szmidt 0 siblings, 1 reply; 101+ messages in thread From: Lars Ingebrigtsen @ 2021-01-01 10:53 UTC (permalink / raw) To: Alfred M. Szmidt; +Cc: emacs-devel, rms, juri "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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2021-01-01 10:53 ` Lars Ingebrigtsen @ 2021-01-01 11:14 ` Alfred M. Szmidt 2021-01-01 12:14 ` Eli Zaretskii 0 siblings, 1 reply; 101+ messages in thread From: Alfred M. Szmidt @ 2021-01-01 11:14 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: emacs-devel, rms, juri 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2021-01-01 11:14 ` Alfred M. Szmidt @ 2021-01-01 12:14 ` Eli Zaretskii 2021-01-01 12:41 ` Alfred M. Szmidt 0 siblings, 1 reply; 101+ messages in thread From: Eli Zaretskii @ 2021-01-01 12:14 UTC (permalink / raw) To: Alfred M. Szmidt; +Cc: larsi, juri, rms, emacs-devel > 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2021-01-01 12:14 ` Eli Zaretskii @ 2021-01-01 12:41 ` Alfred M. Szmidt 0 siblings, 0 replies; 101+ messages in thread From: Alfred M. Szmidt @ 2021-01-01 12:41 UTC (permalink / raw) To: Eli Zaretskii; +Cc: larsi, juri, rms, emacs-devel > 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2020-12-31 10:44 ` Alfred M. Szmidt 2020-12-31 11:18 ` Lars Ingebrigtsen @ 2020-12-31 14:30 ` Eli Zaretskii 2020-12-31 15:42 ` Alfred M. Szmidt 2020-12-31 15:48 ` Dmitry Gutov 1 sibling, 2 replies; 101+ messages in thread From: Eli Zaretskii @ 2020-12-31 14:30 UTC (permalink / raw) To: Alfred M. Szmidt; +Cc: larsi, juri, rms, emacs-devel > 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2020-12-31 14:30 ` Eli Zaretskii @ 2020-12-31 15:42 ` Alfred M. Szmidt 2020-12-31 16:41 ` Eli Zaretskii 2020-12-31 15:48 ` Dmitry Gutov 1 sibling, 1 reply; 101+ messages in thread From: Alfred M. Szmidt @ 2020-12-31 15:42 UTC (permalink / raw) To: Eli Zaretskii; +Cc: larsi, juri, rms, emacs-devel > 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2020-12-31 15:42 ` Alfred M. Szmidt @ 2020-12-31 16:41 ` Eli Zaretskii 2021-01-01 7:20 ` Richard Stallman 0 siblings, 1 reply; 101+ messages in thread From: Eli Zaretskii @ 2020-12-31 16:41 UTC (permalink / raw) To: Alfred M. Szmidt; +Cc: larsi, juri, rms, emacs-devel > 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2020-12-31 16:41 ` Eli Zaretskii @ 2021-01-01 7:20 ` Richard Stallman 0 siblings, 0 replies; 101+ messages in thread From: Richard Stallman @ 2021-01-01 7:20 UTC (permalink / raw) To: Eli Zaretskii; +Cc: ams, emacs-devel, larsi, juri [[[ 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) ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2020-12-31 14:30 ` Eli Zaretskii 2020-12-31 15:42 ` Alfred M. Szmidt @ 2020-12-31 15:48 ` Dmitry Gutov 1 sibling, 0 replies; 101+ messages in thread From: Dmitry Gutov @ 2020-12-31 15:48 UTC (permalink / raw) To: Eli Zaretskii, Alfred M. Szmidt; +Cc: larsi, emacs-devel, rms, juri 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? ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2020-12-31 5:54 ` Richard Stallman 2020-12-31 10:44 ` Alfred M. Szmidt @ 2020-12-31 15:29 ` Gregory Heytings via Emacs development discussions. 1 sibling, 0 replies; 101+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2020-12-31 15:29 UTC (permalink / raw) To: Richard Stallman; +Cc: emacs-devel > > 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2020-12-29 19:20 ` Juri Linkov 2020-12-30 2:45 ` Lars Ingebrigtsen 2020-12-30 5:08 ` Jean Louis @ 2020-12-30 15:05 ` Filipp Gunbin 2 siblings, 0 replies; 101+ messages in thread From: Filipp Gunbin @ 2020-12-30 15:05 UTC (permalink / raw) To: Juri Linkov; +Cc: Lars Ingebrigtsen, emacs-devel 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! ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2020-12-29 18:35 ` Filipp Gunbin 2020-12-29 19:20 ` Juri Linkov @ 2020-12-30 5:04 ` Jean Louis 1 sibling, 0 replies; 101+ messages in thread From: Jean Louis @ 2020-12-30 5:04 UTC (permalink / raw) To: Juri Linkov, Lars Ingebrigtsen, emacs-devel * 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2020-12-28 8:45 ` Juri Linkov ` (2 preceding siblings ...) 2020-12-29 0:46 ` Lars Ingebrigtsen @ 2020-12-29 6:01 ` Richard Stallman 2020-12-29 6:14 ` Drew Adams 2020-12-30 9:33 ` Juri Linkov 3 siblings, 2 replies; 101+ messages in thread From: Richard Stallman @ 2020-12-29 6:01 UTC (permalink / raw) To: Juri Linkov; +Cc: larsi, emacs-devel [[[ 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) ^ permalink raw reply [flat|nested] 101+ messages in thread
* RE: Recentish C-s M-y change 2020-12-29 6:01 ` Richard Stallman @ 2020-12-29 6:14 ` Drew Adams 2020-12-30 9:33 ` Juri Linkov 1 sibling, 0 replies; 101+ messages in thread From: Drew Adams @ 2020-12-29 6:14 UTC (permalink / raw) To: rms, Juri Linkov; +Cc: larsi, emacs-devel > > 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2020-12-29 6:01 ` Richard Stallman 2020-12-29 6:14 ` Drew Adams @ 2020-12-30 9:33 ` Juri Linkov 2020-12-31 5:54 ` Richard Stallman 1 sibling, 1 reply; 101+ messages in thread From: Juri Linkov @ 2020-12-30 9:33 UTC (permalink / raw) To: Richard Stallman; +Cc: larsi, emacs-devel > > > 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2020-12-30 9:33 ` Juri Linkov @ 2020-12-31 5:54 ` Richard Stallman 0 siblings, 0 replies; 101+ messages in thread From: Richard Stallman @ 2020-12-31 5:54 UTC (permalink / raw) To: Juri Linkov; +Cc: larsi, emacs-devel [[[ 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) ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Recentish C-s M-y change 2020-12-28 1:09 Lars Ingebrigtsen 2020-12-28 8:45 ` Juri Linkov @ 2020-12-29 5:56 ` Richard Stallman 1 sibling, 0 replies; 101+ messages in thread From: Richard Stallman @ 2020-12-29 5:56 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: emacs-devel [[[ 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) ^ permalink raw reply [flat|nested] 101+ messages in thread
end of thread, other threads:[~2021-02-02 5:36 UTC | newest] Thread overview: 101+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <<<87r1na4tyu.fsf@gnus.org> [not found] ` <<<87tus6tj7s.fsf@mail.linkov.net> [not found] ` <<<87a6txigm1.fsf@gnus.org> [not found] ` <<<874kk5lzew.fsf@mail.linkov.net> [not found] ` <<<m2sg7o8nq3.fsf@fastmail.fm> [not found] ` <<<87eej8ifll.fsf@mail.linkov.net> [not found] ` <<<X+wLPA/Q8TwWYjM5@protected.rcdrun.com> [not found] ` <<<87h7o3k5b5.fsf@mail.linkov.net> [not found] ` <<<E1kuqup-0001Ly-18@fencepost.gnu.org> [not found] ` <<<E1kuvRe-00051d-SB@fencepost.gnu.org> [not found] ` <<fed43c20-1c46-4cc9-b02a-b9f48f10c035@default> [not found] ` <<E1kvIOG-00011a-4w@fencepost.gnu.org> [not found] ` <<83wnwwg8iu.fsf@gnu.org> 2021-01-01 19:10 ` Recentish C-s M-y change Drew Adams [not found] <<87r1na4tyu.fsf@gnus.org> [not found] ` <<87tus6tj7s.fsf@mail.linkov.net> [not found] ` <<87a6txigm1.fsf@gnus.org> [not found] ` <<874kk5lzew.fsf@mail.linkov.net> [not found] ` <<m2sg7o8nq3.fsf@fastmail.fm> [not found] ` <<87eej8ifll.fsf@mail.linkov.net> [not found] ` <<X+wLPA/Q8TwWYjM5@protected.rcdrun.com> [not found] ` <<87h7o3k5b5.fsf@mail.linkov.net> [not found] ` <<E1kuqup-0001Ly-18@fencepost.gnu.org> [not found] ` <<E1kuvRe-00051d-SB@fencepost.gnu.org> 2020-12-31 16:54 ` Drew Adams 2020-12-31 17:18 ` Filipp Gunbin 2021-01-01 11:14 ` Alfred M. Szmidt 2021-01-01 12:13 ` Eli Zaretskii 2021-01-02 5:34 ` Richard Stallman 2021-01-02 7:15 ` Eli Zaretskii 2021-01-03 6:01 ` Richard Stallman 2021-01-03 15:05 ` Eli Zaretskii 2021-01-04 5:17 ` Richard Stallman 2021-01-04 15:03 ` Eli Zaretskii 2021-01-04 17:44 ` Juri Linkov 2021-01-04 18:20 ` Eli Zaretskii 2021-01-04 18:22 ` Drew Adams 2021-01-03 6:01 ` Richard Stallman 2021-01-03 15:09 ` Eli Zaretskii 2021-01-01 22:47 ` chad [not found] ` <<83v9cigiaa.fsf@gnu.org> [not found] ` <<E1kv065-0004mD-6v@fencepost.gnu.org> [not found] ` <<83k0sygc73.fsf@gnu.org> 2020-12-31 17:02 ` Drew Adams 2020-12-28 1:09 Lars Ingebrigtsen 2020-12-28 8:45 ` Juri Linkov 2020-12-28 17:19 ` Juri Linkov 2020-12-28 17:30 ` Filipp Gunbin 2020-12-28 17:50 ` Clément Pit-Claudel 2020-12-29 6:05 ` Richard Stallman 2020-12-29 0:46 ` Lars Ingebrigtsen 2020-12-29 9:34 ` Juri Linkov 2020-12-29 17:25 ` Drew Adams 2020-12-30 4:57 ` Jean Louis 2020-12-30 5:26 ` Richard Stallman 2020-12-31 15:28 ` Gregory Heytings via Emacs development discussions. 2021-01-01 7:21 ` Richard Stallman 2021-01-01 9:15 ` Gregory Heytings via Emacs development discussions. 2021-01-02 5:35 ` Richard Stallman 2021-01-02 9:03 ` Gregory Heytings via Emacs development discussions. 2021-01-02 9:27 ` Alfred M. Szmidt 2021-01-02 11:55 ` Gregory Heytings via Emacs development discussions. 2021-01-03 5:58 ` Richard Stallman 2021-01-04 0:04 ` Drew Adams 2021-01-05 6:28 ` Richard Stallman 2021-01-05 16:30 ` Drew Adams 2021-01-06 5:14 ` Richard Stallman 2021-01-06 9:41 ` Gregory Heytings via Emacs development discussions. 2021-01-08 6:17 ` Richard Stallman 2021-01-04 9:23 ` Gregory Heytings via Emacs development discussions. 2021-01-05 6:44 ` Richard Stallman 2021-01-06 0:13 ` Gregory Heytings via Emacs development discussions. 2021-01-07 7:39 ` Richard Stallman 2021-01-01 19:12 ` Drew Adams 2020-12-29 18:35 ` Filipp Gunbin 2020-12-29 19:20 ` Juri Linkov 2020-12-30 2:45 ` Lars Ingebrigtsen 2020-12-30 5:08 ` Jean Louis 2020-12-30 9:32 ` Juri Linkov 2020-12-30 10:08 ` Andreas Röhler 2020-12-30 11:13 ` Gregory Heytings via Emacs development discussions. 2020-12-30 15:12 ` Filipp Gunbin 2020-12-31 15:18 ` Gregory Heytings via Emacs development discussions. 2020-12-31 17:09 ` Filipp Gunbin 2020-12-31 19:09 ` Gregory Heytings via Emacs development discussions. 2021-01-04 17:50 ` Juri Linkov 2021-01-04 18:22 ` Gregory Heytings via Emacs development discussions. 2021-01-13 18:19 ` Juri Linkov 2021-01-13 19:34 ` Filipp Gunbin 2021-01-14 8:44 ` Juri Linkov 2021-01-14 15:34 ` Filipp Gunbin 2021-01-27 22:01 ` Gregory Heytings 2021-01-28 8:58 ` Juri Linkov 2021-01-30 5:54 ` Richard Stallman 2021-01-30 10:12 ` Gregory Heytings 2021-02-02 5:36 ` Richard Stallman 2021-01-30 10:42 ` Gregory Heytings 2021-01-30 18:37 ` Juri Linkov 2020-12-31 5:54 ` Richard Stallman 2020-12-31 15:29 ` Gregory Heytings via Emacs development discussions. 2021-01-01 7:21 ` Richard Stallman 2021-01-01 8:02 ` Eli Zaretskii 2021-01-02 5:28 ` Richard Stallman 2021-01-02 7:09 ` Eli Zaretskii 2020-12-30 15:08 ` Filipp Gunbin 2020-12-30 17:32 ` Drew Adams 2020-12-31 5:54 ` Richard Stallman 2020-12-31 10:44 ` Alfred M. Szmidt 2020-12-31 11:18 ` Lars Ingebrigtsen 2020-12-31 11:29 ` Alfred M. Szmidt 2021-01-01 10:53 ` Lars Ingebrigtsen 2021-01-01 11:14 ` Alfred M. Szmidt 2021-01-01 12:14 ` Eli Zaretskii 2021-01-01 12:41 ` Alfred M. Szmidt 2020-12-31 14:30 ` Eli Zaretskii 2020-12-31 15:42 ` Alfred M. Szmidt 2020-12-31 16:41 ` Eli Zaretskii 2021-01-01 7:20 ` Richard Stallman 2020-12-31 15:48 ` Dmitry Gutov 2020-12-31 15:29 ` Gregory Heytings via Emacs development discussions. 2020-12-30 15:05 ` Filipp Gunbin 2020-12-30 5:04 ` Jean Louis 2020-12-29 6:01 ` Richard Stallman 2020-12-29 6:14 ` Drew Adams 2020-12-30 9:33 ` Juri Linkov 2020-12-31 5:54 ` Richard Stallman 2020-12-29 5:56 ` Richard Stallman
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).