all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Re: master 0695108 2/2: Revert "Add `r'/`l' grep command history commands"
       [not found] ` <E1amqnL-0001p7-2f@vcs.savannah.gnu.org>
@ 2016-04-04  5:16   ` Lars Magne Ingebrigtsen
  2016-04-04  5:18     ` John Wiegley
  0 siblings, 1 reply; 11+ messages in thread
From: Lars Magne Ingebrigtsen @ 2016-04-04  5:16 UTC (permalink / raw)
  To: emacs-devel; +Cc: John Wiegley

John Wiegley <johnw@gnu.org> writes:

>     Revert "Add `r'/`l' grep command history commands"
>
>     This reverts commit a32eea60ac90d367435860fe3a10bf843e6f497c.

When reverting a commit, it's helpful if the commit message says why the
commit was reverted.

An contrary to popular belief, reverting code is not a great way to
motivate people to contribute.

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



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: master 0695108 2/2: Revert "Add `r'/`l' grep command history commands"
  2016-04-04  5:16   ` master 0695108 2/2: Revert "Add `r'/`l' grep command history commands" Lars Magne Ingebrigtsen
@ 2016-04-04  5:18     ` John Wiegley
  2016-04-04 15:15       ` Eli Zaretskii
  2016-04-04 19:51       ` Lars Magne Ingebrigtsen
  0 siblings, 2 replies; 11+ messages in thread
From: John Wiegley @ 2016-04-04  5:18 UTC (permalink / raw)
  To: Lars Magne Ingebrigtsen; +Cc: emacs-devel

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> An contrary to popular belief, reverting code is not a great way to motivate
> people to contribute.

I agree, I just wanted to stop any further work before we started having merge
commits and other changes sitting on top of those.

My apologies for the abrupt revert, without comments (I'll remember to do that
in future). I like the direction your change is headed, but it shouldn't
happen before consensus either. The master branch, while intended for Emacs
26, isn't open for new features without some discussion beforehand.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: master 0695108 2/2: Revert "Add `r'/`l' grep command history commands"
  2016-04-04  5:18     ` John Wiegley
@ 2016-04-04 15:15       ` Eli Zaretskii
  2016-04-04 15:57         ` Mark Oteiza
  2016-04-04 18:38         ` Lars Magne Ingebrigtsen
  2016-04-04 19:51       ` Lars Magne Ingebrigtsen
  1 sibling, 2 replies; 11+ messages in thread
From: Eli Zaretskii @ 2016-04-04 15:15 UTC (permalink / raw)
  To: John Wiegley; +Cc: larsi, emacs-devel

> From: John Wiegley <jwiegley@gmail.com>
> Date: Sun, 03 Apr 2016 22:18:59 -0700
> Cc: emacs-devel@gnu.org
> 
> >>>>> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> 
> > An contrary to popular belief, reverting code is not a great way to motivate
> > people to contribute.
> 
> I agree, I just wanted to stop any further work before we started having merge
> commits and other changes sitting on top of those.

Can we continue discussing the design from the point we stopped,
please?

One comment that I have about the feature as it was committed is that
if we want to have an easy way of rerunning past commands, then it
should be defined in compilation-mode, so that all its derivatives
will get it.

I also don't see a lot of mnemonic value in binding these commands to
'l' and 'r', and would suggest additional bindings which would be
easier to remember even for those who don't browse URLs all day long.

I also think that 100-long history for these commands is waaaaay too
much.  It should be a defcustom, and the default value should be maybe
10 or 16.



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: master 0695108 2/2: Revert "Add `r'/`l' grep command history commands"
  2016-04-04 15:15       ` Eli Zaretskii
@ 2016-04-04 15:57         ` Mark Oteiza
  2016-04-04 17:12           ` Eli Zaretskii
  2016-04-04 18:38         ` Lars Magne Ingebrigtsen
  1 sibling, 1 reply; 11+ messages in thread
From: Mark Oteiza @ 2016-04-04 15:57 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: John Wiegley, larsi, emacs-devel


Eli Zaretskii <eliz@gnu.org> writes:

> I also don't see a lot of mnemonic value in binding these commands to
> 'l' and 'r', and would suggest additional bindings which would be
> easier to remember even for those who don't browse URLs all day long.

FYI, info uses these bindings. help-mode adopted them more
recently. Before then, help-mode already had C-c C-{b,f} for back and forward.



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: master 0695108 2/2: Revert "Add `r'/`l' grep command history commands"
  2016-04-04 15:57         ` Mark Oteiza
@ 2016-04-04 17:12           ` Eli Zaretskii
  0 siblings, 0 replies; 11+ messages in thread
From: Eli Zaretskii @ 2016-04-04 17:12 UTC (permalink / raw)
  To: Mark Oteiza; +Cc: jwiegley, larsi, emacs-devel

> From: Mark Oteiza <mvoteiza@udel.edu>
> Cc: John Wiegley <jwiegley@gmail.com>,  larsi@gnus.org,  emacs-devel@gnu.org
> Date: Mon, 04 Apr 2016 11:57:13 -0400
> 
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I also don't see a lot of mnemonic value in binding these commands to
> > 'l' and 'r', and would suggest additional bindings which would be
> > easier to remember even for those who don't browse URLs all day long.
> 
> FYI, info uses these bindings. help-mode adopted them more
> recently. Before then, help-mode already had C-c C-{b,f} for back and forward.

These don't do what 'l' and 'r' do in Grep.  So it's not really an
analogous use case.



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: master 0695108 2/2: Revert "Add `r'/`l' grep command history commands"
  2016-04-04 15:15       ` Eli Zaretskii
  2016-04-04 15:57         ` Mark Oteiza
@ 2016-04-04 18:38         ` Lars Magne Ingebrigtsen
  2016-04-04 20:25           ` Eli Zaretskii
  1 sibling, 1 reply; 11+ messages in thread
From: Lars Magne Ingebrigtsen @ 2016-04-04 18:38 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: John Wiegley, emacs-devel

Eli Zaretskii <eliz@gnu.org> writes:

> One comment that I have about the feature as it was committed is that
> if we want to have an easy way of rerunning past commands, then it
> should be defined in compilation-mode, so that all its derivatives
> will get it.

I considered that, but I thought it might be more controversial.  The
compilation commands may, in general, be somewhat destructive, and
rerunning them while hitting `r'/`l' may not be what you want at all.

The grep commands, on the other hand, are generally not destructive.  (I
mean, they can be if you say `M-x grep RET rm *', I guess, but that
would be a very strange thing to do.)

> I also don't see a lot of mnemonic value in binding these commands to
> 'l' and 'r', and would suggest additional bindings which would be
> easier to remember even for those who don't browse URLs all day long.

They are used in all the other special modes that offer traversing a
history of generated buffers: Info, *Help*, eww...

> I also think that 100-long history for these commands is waaaaay too
> much.  It should be a defcustom, and the default value should be maybe
> 10 or 16.

I don't think so.  Having a 100-long history is basically nothing these
days.  Creating a defcustom for something as trivial as this is a
disservice to our users: Offering pointless things to tweak (and this is
really pointless) is something that Emacs does too much already.

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



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: master 0695108 2/2: Revert "Add `r'/`l' grep command history commands"
  2016-04-04  5:18     ` John Wiegley
  2016-04-04 15:15       ` Eli Zaretskii
@ 2016-04-04 19:51       ` Lars Magne Ingebrigtsen
  2016-04-04 23:14         ` John Wiegley
  1 sibling, 1 reply; 11+ messages in thread
From: Lars Magne Ingebrigtsen @ 2016-04-04 19:51 UTC (permalink / raw)
  To: emacs-devel

John Wiegley <jwiegley@gmail.com> writes:

> The master branch, while intended for Emacs 26, isn't open for new
> features without some discussion beforehand.

There's been a bit of back and forth on that issue, hasn't there?  I
think the argument last time was that either is master open for
development, or it's not.  Realistically, Emacs 26 isn't going to be
released until late 2017 (and that's being kinda optimistic).

I seem to recall that the conclusion to the last round of this debate
(and there's been a few) was that master is open for development of new
features.  Without doing coordination for every single bit of these
small, non-invasive things.

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



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: master 0695108 2/2: Revert "Add `r'/`l' grep command history commands"
  2016-04-04 18:38         ` Lars Magne Ingebrigtsen
@ 2016-04-04 20:25           ` Eli Zaretskii
  2016-04-04 20:32             ` Lars Magne Ingebrigtsen
  0 siblings, 1 reply; 11+ messages in thread
From: Eli Zaretskii @ 2016-04-04 20:25 UTC (permalink / raw)
  To: Lars Magne Ingebrigtsen; +Cc: jwiegley, emacs-devel

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Cc: John Wiegley <jwiegley@gmail.com>,  emacs-devel@gnu.org
> Date: Mon, 04 Apr 2016 20:38:46 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > One comment that I have about the feature as it was committed is that
> > if we want to have an easy way of rerunning past commands, then it
> > should be defined in compilation-mode, so that all its derivatives
> > will get it.
> 
> I considered that, but I thought it might be more controversial.  The
> compilation commands may, in general, be somewhat destructive, and
> rerunning them while hitting `r'/`l' may not be what you want at all.

Then the user will not rerun those commands.  Most commands are not
destructive, though.  In addition, Grep mode is not the only one
derived from Compilation.

> > I also don't see a lot of mnemonic value in binding these commands to
> > 'l' and 'r', and would suggest additional bindings which would be
> > easier to remember even for those who don't browse URLs all day long.
> 
> They are used in all the other special modes that offer traversing a
> history of generated buffers: Info, *Help*, eww...

I asked for _additional_ bindings.  I didn't say these should be
removed.

> > I also think that 100-long history for these commands is waaaaay too
> > much.  It should be a defcustom, and the default value should be maybe
> > 10 or 16.
> 
> I don't think so.  Having a 100-long history is basically nothing these
> days.

I'm not talking about memory it takes.  I'm talking about someone
sitting and pressing 'l' 100 times, re-running all those commands in
between.  I cannot imagine someone will want that.



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: master 0695108 2/2: Revert "Add `r'/`l' grep command history commands"
  2016-04-04 20:25           ` Eli Zaretskii
@ 2016-04-04 20:32             ` Lars Magne Ingebrigtsen
  2016-04-04 20:44               ` Drew Adams
  0 siblings, 1 reply; 11+ messages in thread
From: Lars Magne Ingebrigtsen @ 2016-04-04 20:32 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: jwiegley, emacs-devel

Eli Zaretskii <eliz@gnu.org> writes:

> Then the user will not rerun those commands.  Most commands are not
> destructive, though.  In addition, Grep mode is not the only one
> derived from Compilation.

The user will hit `r'/`l'.  I mean, I do.

>> > I also don't see a lot of mnemonic value in binding these commands to
>> > 'l' and 'r', and would suggest additional bindings which would be
>> > easier to remember even for those who don't browse URLs all day long.
>> 
>> They are used in all the other special modes that offer traversing a
>> history of generated buffers: Info, *Help*, eww...
>
> I asked for _additional_ bindings.  I didn't say these should be
> removed.

I agree that they aren't very mnemonic bindings, but those are the
bindings that all modes that I know of that has a history uses.  I don't
even know what they stand for.  "Return"?  "L..."  uhm...

If you want to have an additional set of keystrokes available, I'm all
for that, but that's an orthogonal issue.  All these modes should have
the same keystrokes for these navigation commands.

> I'm not talking about memory it takes.  I'm talking about someone
> sitting and pressing 'l' 100 times, re-running all those commands in
> between.  I cannot imagine someone will want that.

I obviously chose 100 as a number that is larger than anybody could
reasonably want.  But I could well imagine 10.  Perhaps somebody would
want 20?  So we leave it at 100, and nobody will ever complain, and we
don't need to offer this as a customisation option.

There are no downsides to 100 that I can see.

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



^ permalink raw reply	[flat|nested] 11+ messages in thread

* RE: master 0695108 2/2: Revert "Add `r'/`l' grep command history commands"
  2016-04-04 20:32             ` Lars Magne Ingebrigtsen
@ 2016-04-04 20:44               ` Drew Adams
  0 siblings, 0 replies; 11+ messages in thread
From: Drew Adams @ 2016-04-04 20:44 UTC (permalink / raw)
  To: Lars Magne Ingebrigtsen, Eli Zaretskii; +Cc: jwiegley, emacs-devel

> I agree that they aren't very mnemonic bindings, but those are the
> bindings that all modes that I know of that has a history uses.  I don't
> even know what they stand for.  "Return"?  "L..."  uhm...

`l' stands for "last".  It was in use forever.  `r' was added later,
to be symmetric.

IIRC, I think the idea behind `r' was kind of "right", compared with
"left" (`l').  I don't know of another mnemonic that was touted for `r'.



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: master 0695108 2/2: Revert "Add `r'/`l' grep command history commands"
  2016-04-04 19:51       ` Lars Magne Ingebrigtsen
@ 2016-04-04 23:14         ` John Wiegley
  0 siblings, 0 replies; 11+ messages in thread
From: John Wiegley @ 2016-04-04 23:14 UTC (permalink / raw)
  To: Lars Magne Ingebrigtsen; +Cc: emacs-devel

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> I seem to recall that the conclusion to the last round of this debate (and
> there's been a few) was that master is open for development of new features.
> Without doing coordination for every single bit of these small, non-invasive
> things.

It's open for new features, but we'd like to have some agreement beforehand.
That is, it's not a free-for-all, and never will be. But a lot of minor
changes don't need any discussion at all. New APIs, behaviors, interfaces,
etc., deserve some discussion, since we'll be living with and maintaining them
for potentially a long time.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2



^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2016-04-04 23:14 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <20160403224658.6944.52006@vcs.savannah.gnu.org>
     [not found] ` <E1amqnL-0001p7-2f@vcs.savannah.gnu.org>
2016-04-04  5:16   ` master 0695108 2/2: Revert "Add `r'/`l' grep command history commands" Lars Magne Ingebrigtsen
2016-04-04  5:18     ` John Wiegley
2016-04-04 15:15       ` Eli Zaretskii
2016-04-04 15:57         ` Mark Oteiza
2016-04-04 17:12           ` Eli Zaretskii
2016-04-04 18:38         ` Lars Magne Ingebrigtsen
2016-04-04 20:25           ` Eli Zaretskii
2016-04-04 20:32             ` Lars Magne Ingebrigtsen
2016-04-04 20:44               ` Drew Adams
2016-04-04 19:51       ` Lars Magne Ingebrigtsen
2016-04-04 23:14         ` John Wiegley

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.