bug#15746: 24.3; [PATCH] bookmark should confirm when overwrite

[Karl Fogel <kfogel@red-bean.com>]

Drew Adams <drew.adams@oracle.com> writes:
>You seem to be turning things around, as if the proposal gave users
>a choice and I were arguing against that or I were arguing only
>about a different default behavior.  Look at the proposed patch,
>please.

Oh, sure, I saw the patch.  I saw it as a starting point; subsequent
discussion (before my mail, IIRC) turned to the question of providing a
customizeable behavior, so that both ways were available.  In any case,
I assumed that potential customization was so obvious we were clearly
just talking about the question of what the default should be.  I see
now that I should have made that assumption more explicit, however.

>It seems that you have not recognized the silent-update use case,
>and so have not understood why the proposed change would be
>annoying, hence why users need a choice here.  I hope you understand
>it now.

Actually, no -- not only do I recognize it, it is the majority use case
for me as well.  I just don't think it's good as a default, that's all.

>No.  A variable is not user friendly.  There should be two different
>commands, bound to two different keys.  It is about different use
>cases - for different contexts.  It is not about different users,
>some of whom always want silent updating and some of whom always
>want confirmation querying.

That's another solution, hmmm, but it seems to me it complexifies the
user interface a bit (it adds another binding in the keyspace, which the
user then cannot avoid encountering when looking at the available bound
commands -- whereas a variable is something they only need to deal with
if/when they go looking for it, read the documentation, etc).  So I'm
not sure which way is better; I think we might be down to the "tyranny
of small differences" at that point :-).

>Providing a variable as the only means to silently update does
>not provide equal flexibility.
>
>There is no need for a discussion about defaults (except for which
>command goes on which key), if you provide two different commands
>bound to two different keys.  And that really *does* provide
>"equal flexibility".

As far as that assertion goes, it is true, yes.  It doesn't address the
keyspace complexity issue.

I guess I'll ponder, and then commit some patch.  It need not be the
final patch, but 90% of the code is the same either way and I'd like to
get that part into the codebase so we can discuss the other 10%.

Best,
-K