[publican-list] --lang vs --langs

[Joshua Wulf]

On 06/15/2010 10:13 AM, Jeff Fearn wrote:
> On Sat, 2010-06-12 at 21:23 +0200, Jaromir Hradilek wrote:
>    
>> On 06/12/2010 04:07 AM, Joshua Wulf wrote:
>>      
>>>        
>>>>> What about a warning message, something like ``A single language
>>>>> expected, using --lang instead''?
>>>>>            
>>>> I think the generic "that parameter can't be used with this action" is
>>>> pretty clear. Again, to harp on, if you say --langs is a valid
>>>> parameter, then you have to support people supplying a list of
>>>> languages. Generating an error for a valid parameter that has a valid
>>>> format is a bug.
>>>>
>>>>          
>>> Can we make it prompt for the parameter if it is not supplied? That way
>>> I don't have to think about lang or langs, I just type the thing in when
>>> it asks for it.
>>>
>>> Publican create would also be great with a wizard-like interface.
>>>        
>> Personally, I don't think this is something Publican should ever do, as
>> applications with interactive prompt are harder to use from scripts, not
>> to mention counter-intuitive if they do not do so consistently. This is
>> an ideal task for a wrapper, though.
>>
>> By the way, I am starting to think that implementing a full featured
>> interactive prompt in the best spirit of git-sh [1] would be cool.
>> Having all defaults set and current language displayed as a part of the
>> prompt, you could just type ``test'', ``build'', ``package'', and so on,
>> or even use configurable aliases like ``te'', ``bu'', or ``pk''
>> respectively.
>>
>> [1] http://github.com/rtomayko/git-sh
>>
>> Regards,
>>      
> I'd give that a very low score on "useful things I could do for
> Publican". I'd give it even a lower score on "listening to the users",
> there are other requests that have been discussed by a much wider range
> of users. I certainly wouldn't stop you from doing it, but there are
> many more useful things to do IMHO.
>
> Here are a few ideas I don't have time to implement, all of which I
> think are much more useful.
>
>
> 3: Ground work for supporting different XML DTDs, e.g. DITA
>
>
> Number 3 can probably be done by sub classing Builder.pm. Lots of work
> required on deciding which bits to split in to the sub classes. Could be
> handy, might not be used.
>    
+1 for Number 3.