Re: [Gnu-arch-users] Re: give us a hand with arch

[Stephen J. Turnbull]

>>>>> "Tom" == Tom Lord <address@hidden> writes:

    > From: "Stephen J. Turnbull" <address@hidden>

    > >>>>> "Tom" == Tom Lord <address@hidden> writes:

    > error.  tla expects something in the environment, runtime error.

    > This is a bad thing, because it inhibits experimentation.

    Tom> Sorry the timing of that work is bad from the archivist-mode
    Tom> perspective: are these major setbacks your suffering or
    Tom> fairly minor?

No apology necessary, they're minor.  What I really want is the
library API, but if I can't get that, I'd like a simple, orthogonal
CLI so that easily adaptable scripts/emacs modes do as much of the
"intelligent" UI parts as possible, without bumping into the
"intelligent" parts of tla.

One way this could be done would be to have a "simple orthogonal" CLI
with (long) command names that only a program would be willing to
type.  Another would be to bite the API bullet and say, "These
internal modules are the API v. 0.1.  I don't plan any changes at the
moment, but this API should not be considered 'stable'.  I will listen
to complaints about changes in it, but reserve the right to respond by
bumping the API version number and requesting a doc patch from the
person who bitched."

    Tom> I'm not sure what you mean by "expects something in the
    Tom> environment".

Environment is the contents of envvars, .arch-params, etc.  "Expects"
was inaccurate, what I meant was "the default changed and getting the
old behavior requires setting an envvar, .arch-param, or command line
option."

    Tom> I thought the external dependencies were being kept down
    Tom> quite well.

So far I have encountered no problems (I keep my Debian system pretty
fully loaded with tools I probably never will use ;-).

    Tom> Isn't there a thin layer of lisp in archivist-mode that wraps
    Tom> the CLI?  I would have thought that the CLI changes would
    Tom> have pretty low impact.

In terms of lines of code, yes.  In terms of "now what does _this_ do
_today_", on one occasion I had to resort to source to get a precise
enough answer.  That's wrong.

    Tom> In the CLI?  I would say no, in this sense: some of the
    Tom> specialized "do one thing well" tasks for tla components to
    Tom> handle are providing a comfortable user interface to the
    Tom> core.  Each sub-command has a 1-file CLI processor for just
    Tom> that purpose.  The recent changes are just specializing these
    Tom> CLI processors.

Could this be abstracted a bit more?  My feeling when browsing the tla
sources is that there are starting to be three levels there, not two
(the two are the cmd-* files and the non-cmd-* files).  That is the
cmd-* group is starting to split into "comfortable user interface"
that sometimes does complex things, and "tiny tools interface" where
things are still very straightforward (from the point of view of a
superior UI such as tla itself or archivist-mode).

    Tom>    Many users expressed a desire to run an editor at commit
    Tom> time -- that's not controversial.  I'd be perfectly happy to
    Tom> do nothing at all to tla if a reasonable answer was:

        #!/bin/sh
        $my_editor `tla make-log` ; tla "$@"

    Tom>    walters code pointed out something interesting, though, at
    Tom> least to me.  He pointed out that the ideal behavior of a
    Tom> script that might run the editor for you is to be sensative
    Tom> to the command and options being invoked.

This is true in archivist-mode already, as well.  There are three ways
that the log buffer can be popped up, with slightly different
interactions.

    Tom>    Should having a commit-time editor mean that I can't use
    Tom> `commit -L'?  or should it mean that I have two commands: one
    Tom> to run when I want an editor and one when I don't?  Does it
    Tom> mean that everyone must have a script like walters' that
    Tom> tries to parse the command name and options?

I don't see why such a script shouldn't be distributed with tla.  This
encourages people to fix the script rather than train their fingers to
work around a feature that hasn't been added to tla yet.  Scripts are
text, and can be diffed.  I don't know how to do that with muscle memory.

    Tom> it avoids the drawbacks illustrated by walters' script.

What drawbacks?

    Tom> (b) in general, editors themselves provide no good mechanism
    Tom> for returning such a value.  Looking around at the patterns
    Tom> of other programs that invoke editors -- the interact loop
    Tom> was the only one I saw that addressed this very issue in a
    Tom> reasonable way.

archivist-mode is not going to "return" to tla; it's the other way
around.

While the tla CLI is amazingly hackable for C code, I still prefer
interpreted code that can reimplement behavior while maintaining state.

    Tom> I can see griping about the use of a global-per-user
    Tom> ~/.arch-params setting that determines whether or not an
    Tom> editor is considered

I didn't need to because you already figured it out.  :-)

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.