[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] Low level vs. high level UI
From: |
Pierce T . Wetter III |
Subject: |
Re: [Gnu-arch-users] Low level vs. high level UI |
Date: |
Wed, 25 Feb 2004 16:39:01 -0700 |
On Feb 25, 2004, at 4:00 PM, Aaron Bentley wrote:
On Wed, 2004-02-25 at 16:35, Pierce T. Wetter III wrote:
It says "Use aba command -h for help on `command', or aba help
command
for detailed help" at the bottom of "aba help" output. But it's
just a
frill-- aba command -H still works too.
Sure, but README doesn't mention any of that...
Really, you could bootstrap some documentation by just dumping aba
help, and aba help command for each of the aba comands to a file.
The aba command -H output is meant to be the authoritative help. In
fact, I use "aba help --ext" to generate part of the aba web page. I'd
rather improve that documentation than produce another set. A second
set of documentation would just get out-of-sync fast.
Sure, but perhaps you can mention aba help in the readme, as I found
it by accident.
I prefer easy interfaces, not simple ones. For example, I use vim.
And
I can use aba exactly the way I use tla.
The difference between an easy interface and a simple one? I'm not
sure I understand the distinction? I prefer levels of interfaces
myself.
vi is a program that is hard to learn (not simple), but easy to use
once
you do. That's the kind of thing I mean.
Now see, I found vi easier to learn then emacs, which is why I've
never learned to use emacs... tla is more like emacs then vi...
My view is that gradual evolution is a more certain way of
generating a
set of useful commands than high-level design.
Both have their place. I think its sometimes good to sit down and
think:
Ok, what do I do all the time in arch?
How could that be more automatic?
My objective with aba is to lower the barrier to entry, so that the
first time you think "I do this a lot", you go and write an aba
command.
Well, that makes it easier to use. Lowering the barrier to entry
would be aba + a lot of contributed commands.
I agree that tla's large command set represents a fairly high barrier
to
entry. On the other hand, I only use about 7 commands 95% of the
time.
Ah, what are the 7 commands you use.
tla update,
aba diff [tla changes --diffs],
aba elog [$EDITOR $(tla make-log)],
tla commit,
aba merge [tla star-merge $(cat $(tla tree-root)/++merge-source))],
tla archive-mirror,
aba branch-this.
Funny that 4 of them are aba commands.
aba suggestions:
have a register-archive that both registered the archive, and
built
an alias:
that
would not be useful for me. But if you'd like to write it,
contributions are always welcome.
If I knew arch a little better, I would...
I think it's just tla register-archive $1 $2; aba alias $3=$1
Maybe we can talk offline about how YOU work with tla, and I can
rough out some aba commands to work that way.
In the big picture, aliases are a general high-level facility so
that
aba users can work with much shorter names. I would think that
aliases
should be names that they tend to create as they go along with other
aba commands like "branch-this" and "tag-this".
Oh, I almost always branch into the default archive. So I haven't
seen
the need for it. How would you use it?
Well, like if I wanted a branch:
projects--fixingpunctuation--1.2 in archive:
Which archive? You can't branch into jblack's archive, only he can.
Perhaps aba should figure that out for me?
aba branch-this fixingpunctuation
would let you use
aba get ^fixingpunctuation
because that would expand to:
tla get address@hidden/projects--fixingpunctuation--1.2
Does that make a little more sense?
Not really. Because if it's your default archive, you can use
tla get projects--fixingpunctuation. And if it's not your archive, you
can't branch into it at all. The only case I can see for it is for a
non-default archive that you own.
Perhaps the get is a bad example. What about later on if you wanted
to do something else with the branch?
Pierce
smime.p7s
Description: S/MIME cryptographic signature
- [Gnu-arch-users] Low level vs. high level UI, Pierce T . Wetter III, 2004/02/24
- Re: [Gnu-arch-users] Low level vs. high level UI, Pierce T . Wetter III, 2004/02/25
- Re: [Gnu-arch-users] Low level vs. high level UI, Aaron Bentley, 2004/02/25
- Re: [Gnu-arch-users] Low level vs. high level UI, Pierce T . Wetter III, 2004/02/25
- Re: [Gnu-arch-users] Low level vs. high level UI, Aaron Bentley, 2004/02/25
- Re: [Gnu-arch-users] Low level vs. high level UI, Pierce T . Wetter III, 2004/02/25
- Re: [Gnu-arch-users] Low level vs. high level UI, Aaron Bentley, 2004/02/25
- Re: [Gnu-arch-users] Low level vs. high level UI,
Pierce T . Wetter III <=
- Re: [Gnu-arch-users] Low level vs. high level UI, Aaron Bentley, 2004/02/25
- Re: [Gnu-arch-users] Low level vs. high level UI, Dustin Sallings, 2004/02/25
- Re: [Gnu-arch-users] Low level vs. high level UI, Pierce T . Wetter III, 2004/02/25
- Re: [Gnu-arch-users] Low level vs. high level UI, Dustin Sallings, 2004/02/25
- Re: [Gnu-arch-users] Low level vs. high level UI, Robin Green, 2004/02/25