On Sun, Aug 30, 2009 at 3:57 AM, Adrian Buehlmann<adrian@...> wrote:
> On 30.08.2009 10:19, Peer Sommerlund wrote:
>> 2009/8/28 Steve Borho <steve@... <mailto:steve@...>>
>> On Fri, Aug 28, 2009 at 12:50 PM, Adrian
>> Buehlmann<adrian@... <mailto:adrian@...>> wrote:
>> > On 28.08.2009 19:15, Steve Borho wrote:
>> >> There's a lot of rather advanced features being tacked onto the
>> >> changelog and commit tools on the last few months, which is all fine
>> >> and grand for experienced Mercurial users, but I'm beginning to
>> >> if we want to hide many of these commands by default to protect new
>> >> users from shooting themselves in the feet.
>> >> Specifically: rebase, strip, transplant, backout, MQ
>> >> Many of those operations have failure modes that require command line
>> >> manipulations to get back to a normal working state.
>> >> I'm curious how other people feel about this.
>> > I'm fine with not showing these by default, turning them
>> > on with some expert mode -- or something.
>> Yeah, either through 'tortoisehg.trainingwheels = False' or just
>> checking for loaded extensions.
>> I'm not too fond of modes in general.
>> See for example
> That term "mode" is s bit overly loaded here, as hiding more advanced
> user interface parts surely isn't as hard as an interface element that
> fundamentally changes its meaning based on a state or true hard-to-leave
> UI states like the ones in my Vibra LITE2 wristwatch (I definitely
> start getting to old for such devices...).
> Not presenting complicated / advanced features in GUI user interfaces
> IMHO doesn't count as a "mode" in that sense. Otherwise we might start
> counting tabs in dialog boxes as modes as well.... (and end up doing
> everything on the command line again, which is the absolute king of
My shell always has vi bindings, and there are definitely modes :)
The approach I'm leaning towards is the one we used in the commit
tool. Certain features will be hidden if they require extensions that
are not loaded.