Re: enhanced debian-changelog-mode.el
>>>>> "Peter" == Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca> writes:
Peter> A few _quick_ comments. A diff to my installed version
Peter> shows you added menus and font-lock, so perhaps this line
Peter> is premature:
Peter> ;; This version has been heavily modified and enhanced by
Peter> ;; Chris Waters
Hmmm. I think Chris intends to do more work on it, and just tapped
that down with inspired optimistic fervor in response to a mental
`dont forget to mention this isn't the original version'.
Peter> Also, since you are _adding_ to existing code, it would be
Peter> polite to respect the indentation used: don't use hanging
Peter> closing parens, [...]
I sometimes leave a hanging paren as a reminder to myself that there
may be more lines needed inside an expression later on. Perhaps he
was just leaving it open for now like that, as an indicator to other
lisp coders reading it that "this is a place where more things might
go later on as this thing evolves".
Peter> Untested, but you get the idea. If you want to be sure to
Peter> fontify a `closes bug' line, implement a
Peter> debian-changelog-close-bug function. That could lead to a
Peter> more universal format used that users could grep for, etc.
It would be good to have a mode that uses Gnus and/or W3 to
facilitate bug manipulation as well. I've thought only that it
should exist, and not much about how it ought to work. Any ideas?
I thought that what I'd do is set up `nnmail-split-fancy' to toss
incoming mail (that's what I do now), and split out mail from the BTS
into its own mailbox. Perhaps the BTS could, if it turned out to be
necessary, write a special X-Header into the mails it sends so our
mode can distinguish the control message reply from normal bug report
mail?
Then, there'd be a minor mode that would have a few commands...
Hmmm. Perhaps the BTS could be modified to send mails in a special
format for this? We'd have to design it. I'm thinking of a mostly
point and click interface... like lets say I want to merge several
bugs. (this could be done with CGI also I imagine.) An interface
would be generated from data gained by a parse of BTS summary email
or somesuch. The interface would use the `widget' toolkit in the
emacsen. To merge bugs, you'd checkbox them off and click send. An
email would be generated and sent to the control bot.
The email approach would have the advantage over CGI that it would
work while offline. You could ask it to retrieve the summary
information, wait by the mailbox until it comes in, then hang up the
line. You'd then work for a while getting things squared away and
whatnot... and as you go, queue up (via sendmail) outgoing
requests/controls to the BTS. Next time you connect, you do a
`runq', and the batch goes out. A CGI interface would require you to
work online. The second advantage to the Gnus minor-mode (w/W3?)
approach is that it can interface to other IDE lisp code, such as
`debian-changelog-mode'.
Hmmm... maybe BTS admin control panel?
Perhaps W3-mode could be used internally by this minor mode? It's
ready and waiting to be explored. I've not the time right
now... until after I get everything packaged and uploaded; hopefully
prior to the freeze date. (when is that? I hope I've got another
month or so at least.) I think that it can be used to layout things
nicely, and you can put user-defined widgetry in, and stuff like
that. It doesn't necessarily need to hit an http server to get the
HTML it lays out... This area needs further study prior to trying to
write the BTS mode. (The BTS system itself needs to be studied by
the same set of coders, IMO).
Reply to: