[ditz-talk] First impressions

David Masover ninja at slaphack.com
Sun Aug 3 19:02:56 EDT 2008

On Sunday 03 August 2008 17:39:31 William Morgan wrote:
> Reformatted excerpts from David Masover's message of 2008-07-31:
> > Couple things I'm starting to notice, though -- one thing I miss from
> > Trac is the ability to go back and edit other parts of the issue
> > before I submit.
> There's ditz edit, but that generates a log message. I've just added an
> issue requesting a --silent flag to turn off logging, so that would be
> useful in this case.
> > Could probably get the same effect by providing an editor-friendly
> > format (not yaml) in which to enter a complete ticket. 
> That seems like a different use case to me. Personally I consider YAML
> to be editor-friendly, but in general I'm not adverse to other input
> mechanisms besides what's there now. So, make a proposal.

Something like:


Type: (b)ugfix, (f)eature, (t)ask?

Issue creator:
My Name <autofilled at example.com>

Throw it all in an editor, and the result is: Press the down arrow once to 
start typing a title, then twice to edit bugfix/feature/task (and I am 
proposing a default), twice more to fill in a description. Filled out, it'd 
look like this:

Some Ticket
Type: (b)ugfix, (f)eature, (t)ask?
Filling in some description
Issue creator:
My Name <autofilled at example.com>

The idea is, up and down arrows in the editor are going to be a lot faster 
than save/quit + reopen with "ditz edit". I'm speaking mostly of the process 
of initially posting the issue, though it might also help with editing.

I think that's almost as quick as tabbing between fields in a GUI, and it has 
the added benefit of using your favorite editor to edit the description.

And I agree, YAML is editor-friendly -- but in this simple case, I think the 
special-purpose format is both faster and more readable.

> > Bugfix/Feature/Task should probably be set to some default, as I'm
> > assuming it must be provided.
> If you can come up with a default that satisfies everyone, sure.

Point is not that there needs to be one in Ditz itself, but that it should be 
a config option.

> > One more thing: For a one-project setup, having to type <project>-123
> > at the commandline is annoying. That could be implied.
> With tab completion I don't see this being that big of a deal.

Where can I get Bash tab-completion for Ditz? Or was that a proposal?

Could imply it everywhere in that project, including editing issues -- kind of 
nice how, in Trac, I only need to refer to issue #384 (say) and it becomes a 

It'd still be bad if that one Ditz installation had a separate project added, 
maybe -- either you'd have errors, or you'd have to always assume the old 
default project.

More information about the ditz-talk mailing list