Thread (25 messages) flat view 25 messages, 5 authors, 2016-06-15

Re: [PATCH v3] Add core.mode configuration

From: Krzysztof Mazur <hidden>
Date: 2016-06-15 22:59:01

On Tue, Oct 15, 2013 at 11:03:26PM -0500, Felipe Contreras wrote:
quoted
not some "next" behavior that may change in future.
But I'm suggesting to add a core.addremove option as well, like you suggested,
am I not?
Yes, I think we both agreed on adding core.addremove. I'm just not
convinced if we should also add core.mode.
So you would be happy if we had core.addremove = true *and* core.mode = next,
right? You would use one, different people with different needs would use the
other.
Yes, if there are people that will use core.mode it will be worth
adding. I'm just not one of them.
quoted
quoted
quoted
That's safer than next (at least for interactive use) and maybe more users
would use that, but I don't think that's worth adding.
Maybe, but I don't think many users would use either mode, and that's good.
quoted
For me, old behavior by default and warnings with information how to
enable new incompatible features, is sufficient. So I don't need
core.mode option, but as long it will be useful for other users I have
nothing against it.
OK, but that seems to mean you don't need core.mode = next-warn either. I'm not
against adding such a mode, but I would like to hear about _somebody_ that
would like to actually use it. I don't like to program for ghosts.
As I said earlier, I don't think that next-warn it's worth adding, but
such option might increase the number of people interested in the
core.mode.
Well that's a hypothesis, and I would be interested in finding out if that's
true, but until I see somebody that says "I want core.mode = next-war", I'm
going to assume they are hypothetical.
Yes, that's just a hypothesis.

Krzysiek
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help