Subject: Re: new --to command line option
From: Paul Rohr (paul@abisource.com)
Date: Wed Jan 26 2000 - 18:21:46 CST
Cool. I think we're in consensus here. By default, the -to option should
be a pure batch feature, with no GUI.
At 04:46 PM 1/26/00 -0600, sam th wrote:
>I give on this one, however, I prefer the solution Paul suggests (a --show
>option) to abiword -to abi; abiword. I think using an option just looks
>nicer, in additon to having us give the user flexibility, rather than
>having the user create it him/herself.
OK. There are three options here.
1. Do nothing. Let people double-launch if they want.
2. Add -show as a synonym for "; abiword". Syntactic sugar is sometimes
nice. Other times it results in Perl. YMMV.
3. Use -show to provide some specific kind of *extra* functionality. For
example, this way you might get to see all the specific files which got
converted *before* they're saved or something.
For obvious reasons, I'd be happier with 1 or 3, but I'm not going to be
dogmatic about it.
>Currently, parseCommandLine is supposed to return false if it gets bad
>argument, however, it always returns true. Joaquin's patch changes it so
>that it returns false if the user specified -to, so that the app is not
>started. _convertTo currently fprintf's to stderr if there is a problem
>reading the file, and does nothing on writing errors. However, the MANY
>differnt reading errors are not treated seperately, and finally, the error
>code is likeley to generate bugs in the near future, as once Shaw
>integrate the patch that I sent him (which should be soon), readFromFile
>will no longer return a UT_Bool, but instead an UT_Error. I will send him
>a patch that will hopefully fix this. Additionally, all the differnt
>errors that could be generated should be treated seperately.
I don't envy the patch-collision problem that Shaw's currently facing. Both
the UT_Error and -to patches are very worth having in the tree in some clean
form, but you guys are tromping all over each other today. :-)
Sam and Joaquin -- once Shaw gets through the current set of conflicting
patches and applies a coherent subset, then could the two of you work
together to come up with a coherent strategy for handling errors in batch
mode?
> This brings up the further question of how we should treat error
>messages on the command line. Should we just print them to stderr?
>Should we give the user chocices as to wether or not to continue? If we
>have abiword running on just a command line basis, these are issues we
>need to consider.
Please. Let's not nickel and dime this design by peppering the list with
mini-debates on various random questions and issues. Yes, these are all
good questions to answer, but...
Somebody needs to go off and think through an entire design which addresses
all the issues they're aware of in some coherent fashion. Anyone who'd
actually *use* the proposed feature a lot would be a prime candidate for
this.
Then, once there's a specific proposal to review, we can have a much more
coherent discussion of open issues not resolved by that design.
Paul
PS: Yes, I know I started it. Shame on me. I'm trying to undo that
mistake.
This archive was generated by hypermail 2b25 : Wed Jan 26 2000 - 18:16:24 CST