Oop customization group

Oop customization group

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 851 bytes --]

There's a customization group defined, Oop, that's been in there since  
1997, but at least in my build it is empty.  I couldn't find anything  
refer to it.

cus-edit.el:

(defgroup oop nil
   "Support for object-oriented programming."
   :group 'programming)


Also, I don't think the structure of these groups is very well though  
out: We have "Languages", then "Tools", which is helpfully labeled  
"Programming tools".  What's a tool, and what's not?  I think this  
means "general utilities: tools for programming in any language".
But the structuring isn't good in the first place.  Discounting the  
empty Oop group (which shouldn't be here anyways, since we lack a  
group for functional or imperative or whatever programming), there are  
just two entries in the "Programming" group.  This doesn't justify an  
extra level in the hierarchy.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

Re: Oop customization group

[chad]

I too find the customize groups a little baffling, and usually end up  
grep'ing through for likely keywords (or just bypass customize  
entirely).  I imagine that a reorg of these groups would be a welcome  
but somewhat lengthy undertaking.  If  the PTB would be interested in  
such an effort, when would be the right time?  I imagine that it's too  
late to get t in before the next release...

*chad

On Jun 6, 2009, at 5:24 AM, David Reitter wrote:
> Also, I don't think the structure of these groups is very well  
> though out:

RE: Oop customization group

[Drew Adams]

> Also, I don't think the structure of these groups is very 
> well though[t] out: We have "Languages", then "Tools", which
> is helpfully labeled "Programming tools".  What's a tool,
> and what's not?  I think this means "general utilities:
> tools for programming in any language".
> But the structuring isn't good in the first place... 
> there are just two entries in the "Programming" group.
> This doesn't justify an extra level in the hierarchy.

Group inheritance can be multiple. This is essentially a tagging mechanism (in
the sense of del.icio.us tags, not Emacs tags), whether or not it was intended
that way. Perhaps the UI should reflect this more directly - be more like the
kinds of access typically provided for tag sets. Dunno.

I'm not a big user of tagging UIs, so I don't have an opinion about that. But
that's the way I see Emacs groups now - not so much as a hierarchical directory
structure, more like a tagging mechanism.

There are some tagging UIs in Emacs. IIUC, Org mode has one, and a few others
can be found on Emacs Wiki. Dunno if it would be worth it to adapt access to
Customize groups more along such lines.

Yes, some cleanup of the predefined groups might help. But as you point out,
it's not always super clear what each category/group/tag is supposed to
represent.

Yes, I agree that finding things by group/tag is not as simple as it might be.
No, I don't have any specific suggestions.

One problem with Customize seems to be that it's hard to find people who want to
work on it, to make improvements. Another problem is that it's hard to find
agreement here about what should be done. But if you have a minor, incremental
suggestion (fix) wrt Customize groups, there's a chance it would be adopted.

Re: Oop customization group

[Stefan Monnier]

> There's a customization group defined, Oop, that's been in there since 1997,
> but at least in my build it is empty.  I couldn't find anything  refer
> to it.

> cus-edit.el:

> (defgroup oop nil
>   "Support for object-oriented programming."
>   :group 'programming)

Should be removed, indeed.

> Also, I don't think the structure of these groups is very well though out:

It's not.  It'd be good to improve it.
Thanks to the fact that we have multiple-inheritance, such improvement
can be done incrementally.  General suggestions for useful categories
would be welcome (both category name and clear description of what it
shoujld contain).  We could start with `major-mode' (which I'd constrain
to be modes for use in files-buffers) and `minor-mode'.


        Stefan

RE: Oop customization group

[Stephen J. Turnbull]

Drew Adams writes:

 > Group inheritance can be multiple. This is essentially a tagging
 > mechanism (in the sense of del.icio.us tags, not Emacs tags),

No, it's not, not until the UI reflects that.  The issue with
Customize as it stands is that it's organized according to the
developers' tastes, and groups are strongly module-oriented, although
users often see commonalities not reflected in the implementation's
structure.

If we're going to go in the direction of d.i.u-style tagging, what I
think is needed is some way to communicate users' idea (ie, some sort
of consensus which may still be somewhat ambiguous or confused, not
coherent, well-thought-out individual systems) to the distribution.

RE: Oop customization group

[Drew Adams]

>  > Group inheritance can be multiple. This is essentially a tagging
>  > mechanism (in the sense of del.icio.us tags, not Emacs tags),
> 
> No, it's not, not until the UI reflects that.

You seem to be in violent agreement. ;-)

That was my point (in part). Groups are not really more than tags, because of
multiple inheritance and because this "inheritance" is so loose that it is
merely a kind of cross referencing ("see also") - you can even have group A that
inherits from a group B that inherits from A.

Groups are not more than tags in terms of their semantics, and they are less
than tags when it comes to UI. As I suggested, and as you reiterate, the UI is
not by design a tagging UI. 

That was my point in bringing this up: Since groups are nothing more than
arbitrary labels/tags, should we not perhaps provide a UI that is more in line
with the tagging and tag-searching UIs one sees today?

> If we're going to go in the direction of d.i.u-style tagging, what I
> think is needed is some way to communicate users' idea (ie, some sort
> of consensus which may still be somewhat ambiguous or confused, not
> coherent, well-thought-out individual systems) to the distribution.

Locally, that could come naturally, I think, if the UI were more tag-like.
Either on an individual basis or collectively among users at the same site, user
tagging would be reflected in the resultant tag set ("group hierarchy").
Regardless of the UI, that is what happens now, when users define groups that
other (local) users can see.

But yes, it could be useful to somehow integrate tagging by the wider user
community, so that it becomes part of Emacs, that is, part of a local Emacs
installation or a local Emacs session. Given Internet access, the tag set
available locally could dynamically (at least on demand) be made to reflect
tagging by users at large. 

How best to do that, I don't know - I'm pretty ignorant about this stuff.
Perhaps gnu.org could have a Web service that would federate user tagging, and
which could be used to update one's local Emacs. That is, local tagging by users
could be pushed out, and tags collected from non-local users could be pulled in.

RE: Oop customization group

[Stephen J. Turnbull]

Drew Adams writes:
 > >  > Group inheritance can be multiple. This is essentially a tagging
 > >  > mechanism (in the sense of del.icio.us tags, not Emacs tags),
 > > 
 > > No, it's not, not until the UI reflects that.
 > 
 > You seem to be in violent agreement. ;-)

Well, not entirely.  Some hierarchy is necessary, and the tagging
mechanisms I'm familiar with don't really provide that.  A few minutes
trying to get help on any GUI application whether from Microsoft or
GNOME convinces me that documentation is not something that should be
left to non-developer users.  (I don't know about del.icio.us, I stay
as far away from that kind of Web2.0 as I can.)

 > Perhaps gnu.org could have a Web service that would federate user
 > tagging, and which could be used to update one's local Emacs. That
 > is, local tagging by users could be pushed out, and tags collected
 > from non-local users could be pulled in.

This is what I had in mind, although like you I don't really know how
the "federating" algorithm should work.

Re: Oop customization group

[MON KEY]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> can be done incrementally.  General suggestions for useful categories
> would be welcome (both category name and clear description of what it
> shoujld contain).  We could start with `major-mode' (which I'd constrain
> to be modes for use in files-buffers) and `minor-mode'.

The best approach remains to mirror/reflect the structure of the
emacs/elisp manuals ITR esp. as this allows for reasonable and extensibl
xrefs to source and documentation going forward. 

The 'delicious tags' approach is _not_ TRT here, nor is a strict class
hiearchy 'multiple inhertiance' or otherwise. TRT is a thesaurus in the
z39.50 sense. Zthes offers a nice set of docs, tagsets, schemas,
attribute sets, etc. for such an implentation see (URL
`http://zthes.z3950.org/z3950/zthes-z3950-1.0.html#2.5')

The CQL, SRU, Soap, interfaces could afford mutiple paths to a
controlled _and_ open 'tagset' in the cataloger/indexer sense as opposed
to the "gee I better tag this library for custom" use that emacser's
tend to employ. 

Why is it that programmers believe they make good classifiers?

s_P