* Oop customization group
@ 2009-06-06 12:24 David Reitter
2009-06-06 16:57 ` chad
` (2 more replies)
0 siblings, 3 replies; 8+ messages in thread
From: David Reitter @ 2009-06-06 12:24 UTC (permalink / raw
To: Emacs-Devel devel
[-- 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 --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Oop customization group
2009-06-06 12:24 Oop customization group David Reitter
@ 2009-06-06 16:57 ` chad
2009-06-06 18:08 ` Drew Adams
2009-06-06 19:06 ` Stefan Monnier
2 siblings, 0 replies; 8+ messages in thread
From: chad @ 2009-06-06 16:57 UTC (permalink / raw
To: David Reitter; +Cc: Emacs-Devel devel
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:
^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: Oop customization group
2009-06-06 12:24 Oop customization group David Reitter
2009-06-06 16:57 ` chad
@ 2009-06-06 18:08 ` Drew Adams
2009-06-07 0:14 ` Stephen J. Turnbull
2009-06-06 19:06 ` Stefan Monnier
2 siblings, 1 reply; 8+ messages in thread
From: Drew Adams @ 2009-06-06 18:08 UTC (permalink / raw
To: 'David Reitter', 'Emacs-Devel devel'
> 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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Oop customization group
2009-06-06 12:24 Oop customization group David Reitter
2009-06-06 16:57 ` chad
2009-06-06 18:08 ` Drew Adams
@ 2009-06-06 19:06 ` Stefan Monnier
2009-06-08 21:21 ` MON KEY
2 siblings, 1 reply; 8+ messages in thread
From: Stefan Monnier @ 2009-06-06 19:06 UTC (permalink / raw
To: David Reitter; +Cc: Emacs-Devel devel
> 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: Oop customization group
2009-06-06 18:08 ` Drew Adams
@ 2009-06-07 0:14 ` Stephen J. Turnbull
2009-06-07 3:32 ` Drew Adams
0 siblings, 1 reply; 8+ messages in thread
From: Stephen J. Turnbull @ 2009-06-07 0:14 UTC (permalink / raw
To: Drew Adams; +Cc: 'David Reitter', 'Emacs-Devel devel'
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: Oop customization group
2009-06-07 0:14 ` Stephen J. Turnbull
@ 2009-06-07 3:32 ` Drew Adams
2009-06-07 5:43 ` Stephen J. Turnbull
0 siblings, 1 reply; 8+ messages in thread
From: Drew Adams @ 2009-06-07 3:32 UTC (permalink / raw
To: 'Stephen J. Turnbull'
Cc: 'David Reitter', 'Emacs-Devel devel'
> > 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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: Oop customization group
2009-06-07 3:32 ` Drew Adams
@ 2009-06-07 5:43 ` Stephen J. Turnbull
0 siblings, 0 replies; 8+ messages in thread
From: Stephen J. Turnbull @ 2009-06-07 5:43 UTC (permalink / raw
To: Drew Adams; +Cc: 'David Reitter', 'Emacs-Devel devel'
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Oop customization group
2009-06-06 19:06 ` Stefan Monnier
@ 2009-06-08 21:21 ` MON KEY
0 siblings, 0 replies; 8+ messages in thread
From: MON KEY @ 2009-06-08 21:21 UTC (permalink / raw
To: emacs-devel
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
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2009-06-08 21:21 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-06-06 12:24 Oop customization group David Reitter
2009-06-06 16:57 ` chad
2009-06-06 18:08 ` Drew Adams
2009-06-07 0:14 ` Stephen J. Turnbull
2009-06-07 3:32 ` Drew Adams
2009-06-07 5:43 ` Stephen J. Turnbull
2009-06-06 19:06 ` Stefan Monnier
2009-06-08 21:21 ` MON KEY
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.