GNU bug report logs - #7812
add a diff-list custom type; use it for compilation-error-regexp-alist

Previous Next

Full log

View this message in rfc822 format

From: Dave Abrahams <dave <at> boostpro.com>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 7812 <at> debbugs.gnu.org
Subject: bug#7812: 23.2; compilation-error-regexp-alist extremely unfriendly to customization interface
Date: Wed, 19 Jan 2011 22:30:16 -0500

At Wed, 19 Jan 2011 18:25:26 -0500,
Glenn Morris wrote:
> 
> Dave Abrahams wrote:
> 
> [customizing compilation-error-regexp-alist]
> 
> > It was never awesome: it *should* be possible to add support for a
> > couple of unique tools without losing the benefits of all the builtin
> > matchers that will come along next time I upgrade emacs.  It has
> > always been the case that if I customize one or two of these elements,
> > I'll never see new ones that are supplied by the maintainers on
> > upgrade...
> 
> That is a general issue with customize, albeit more of one for options
> with long, complicated values where new ones might be added to the old
> elements.

Yes, but you *can* design the module so as to make it a non-issue.
Give people a customizable variable that is solely for their own use,
and give them a way to override the contents of the base alist, which
is not customizable but updated with the module.

> There is M-x customize-changed to point out where options have changed
> since a given Emacs release. In an ideal world maybe there could be
> some automatic, version-control like merging of options when you start
> a new Emacs version for the first time.
> 
> > ...but now things are worse: I can't even add new alist elements
> > through the customize interface, and if do I add a single new one
> > using setq, all I see in the customize interface thenceforth is:
> >
> >   (mapcar 'car compilation-error-regexp-alist-alist)
> 
> compilation-error-regexp-alist has a bad custom :type. It does not
> allow you to do anything other than turn on/off the default settings.
> It is impossible to add a new element via customize, and doing so by
> hand will produce a mismatch.
> 
> AFAICS, it isn't possible to have a custom type that allows you to both:
> 
> i) toggle on/off the predefined options
> ii) add new elements of your own
> 
> So feature i) will probably have to go.

The problem is with the design that mashes all this functionality
together into a single customization variable.  Just use separate
variables for separate concerns, and you'll be golden.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.