[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:
Title:
Type: (b)ugfix, (f)eature, (t)ask?
b
Description:
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:
Title:
Some Ticket
Type: (b)ugfix, (f)eature, (t)ask?
b
Description:
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
link.
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