Re: enhanced debian-changelog-mode.el
[Sorry for being so late, I've been away]
Chris Waters wrote:
> Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca> writes:
> > Chris Waters wrote:
> > > Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca> writes:
> > > > Also, I'd add optional whitespace space between "bug" and "#" and
> > > > also make the colon optional:
> > > The colon is required, and whitespace is not allowed. The perl regexp
> > > used by dinstall is: "/closes:\s*(bug)?\#\d+(,\s*(bug)?\#\d+)*/i". I
> > ^^ ^^
> > That's whitespace.
> That's whitespace a) after the colon, and b) after the comma which
> follows a number. My regexp does recognize whitespace there. No
> whitespace is allowed between "bug" and "#".
Sorry then. I'd lost the original email with your regexp.
I still think no space in "bug#" loos weird, but since you say
it's magic then that makes sense.
> > I tried to find a reference to the suggested format used in a
> > changelog, but couldn't.
> That's a problem, but it's not my fault. :-)
> > Developers tend to use all sorts of formats. Should we try to
> > fontify them all?
> The syntax in question is magic. It will cause the bug to be
> *automatically* closed by dinstall. I think that's an important
> enough feature to be worth highlighting. Developers may use other
> formats, but those won't trigger any automatic behavior by Debian
> tools, so I see no reason to specially highlight them.
Might be useful to fontify them in a less `urgent' colour (if a
good regexp can be found), but I agree that the _magic_ meaning
is most useful.
> > The only problem is that bug numbers only end up in the changelog
> > after they are closed and then they disappear quickly from the
> > BTS. If bugs were archived forever, we could add a
> > lookup-this-bug function easily, but this wouldn't be useful now.
> I was thinking more along the lines of a "lookup the open bugs for
> this package" function for changelog mode, so you could more easily
> add the closers in the changelog. My primary target here is
> developers working on their own packages. What you suggest might be
> nice for browsing the changelogs of other people's packages, but
> that's not really my main focus here.
I understnad now. Great idea.