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

[Tom Lord]

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

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

    >     Tom> Ok.  While I don't think the functionality should exactly
    >     Tom> mimic your script, the desirability of interacting reasonably
    >     Tom> with `-L'

    > What bothers me about this whole thread is that anybody who has a
    > script that implements a different process is likely to get broken
    > every time you add features.  This has happened to archivist-mode
    > several times already; tla stops accepting certain options, runtime
    > error.  tla expects something in the environment, runtime error.

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

As previously announced, the 1.1preX series is the time for CLI
tweaking and so unstability in that regard is expected up until 1.1
which is not very far off.    Sorry the timing of that work is bad
from the archivist-mode perspective:  are these major setbacks your
suffering or fairly minor?

I'm not sure what you mean by "expects something in the environment".
Are you talking about environment variables?   I don't think I've
added any such dependencies recently.   Do you mean `diff3' and,
perhaps soon, a patched `diff3'?   That's true but if `diff3' isn't
present arch still works quite well.    I thought the external
dependencies were being kept down quite well.


    > If there were a public API implementing the arch commands at the C
    > level, I'd either link XEmacs to it or shut up, but there ain't.

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



    > Colin proved that this kind of interaction can be done by a script.
    > Why must it be added to tla?  Have we abandoned the tiny tools
    > approach?  :-(

Depends what you mean by "tiny tools".

I would have to say yes, if for no other reason than that `tla' is one
big executable.

I would say no, in this sense: the core functionality remains a set of
largely independent, specialized components, each with a clear and
narrow functionality, functionally composed, communicating between one
another in very simple ways.

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

Sometimes you'll hear old unix salts balk badly at two elements of the
proposed -E options:  the idea of running the editor for the user when 

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

might be just as good;   the idea of an actual _interact_loop_ that
asks the user whehter or not to proceed with the commit.

Here's my rationale:

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

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

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

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

   None of those options seem very user friendly to me: it's a
   legitimate observation that the handling of an editor session
   during a commit-like command involves feedback from the other
   options to commit, for example.

   So it doesn't seem to ridiculous to me to add an
   `arch_ensure_log_is_ready()' function and call that in the
   `main'-like functions that implement several commands.   It will
   fit in with the existing argument processing very nicely;  it has 0
   impact on any of the core functionality;  it provides the desired
   features;  it avoids the drawbacks illustrated by walters' script.

   Regarding the interat loop (the "Commit? ..." prompt):  walters'
   script also illustrates that (a) one of the outputs of an editting
   session should be a value that means "forget it -- abort the
   commit" and (b) in general, editors themselves provide no good
   mechanism for returning such a value.   Looking around at the
   patterns of other programs that invoke editors -- the interact loop
   was the only one I saw that addressed this very issue in a
   reasonable way.
   

I'm surprised you'd gripe about this in archivist-mode.  I can see
griping about the use of a global-per-user ~/.arch-params setting that
determines whether or not an editor is considered (since the behavior
and choice of editor in archivist-mode might not be the same as the
user's default setting).

-t