Sounds like a lot of overlap with CategoryCode?
– AlexSchroeder 2012-08-28 15:31 UTC
It does have overlap with many things. I had three motivations
1. To start Category pages (even redirects) for each of the official toplevel categories defined by ‘finder-by-keyword’. 2. Personally uploading some very general utilities which had no reasonable Category to assign. 3. Clearly marking (for end-users) “This library won’t be useful for you”
– roland.walker 2012-08-28 15:49 UTC
Maybe we can simply extract those elements from CategoryCode that might better fit into CategoryExtensions. If I understand the distinction correctly, everything under the “Emacs Lisp Libraries” header can be moved from Code to Extensions?
– AlexSchroeder 2012-08-29 08:35 UTC
Almost everything, will give it a shot. I have to say I’m not a fan of the Emacs lingo for this distinction - “utilities” or “frameworks” would have been better choices.
– roland.walker 2012-08-29 11:36 UTC
This category is due to become a monster, if you fairly add links to all wiki pages that fit the description (and hopefully you at the category to each of those pages, as well). There is so much (most?) of the wiki content that extends Emacs for programmers writing Emacs Lisp.
And the category should not be only for utility libraries that do that. It should include also snippets that might not be in libraries – this is a wiki, after all.
I think this category – or other categories that it greatly overlaps – should be removed. – DrewAdams
– DrewAdams 2012-08-29 14:06 UTC
It’s a bit murky, I agree. When I looked at the Code category, it seemed to have a lot of pages that were about writing elisp instead of documenting useful libraries for programmers. Perhaps that is a useful distinction to make? Perhaps then Code should be Learning To Code, of course. :)
– AlexSchroeder 2012-08-29 18:11 UTC
I repeat that I think the best approach is to start by grouping things on the existing category page, and only later (after some discussion) decide whether to reorg (e.g. split a category).
For example, you could split Code now into two such groups – within the category, on the same page, using a heading. Just the act of doing that might tell you whether you really think it’s a good idea.
That kind of change is relatively harmless, as it does not affect the wiki organization immediately. It’s just text on a page. And that is how most of the reorganization has taken place on the wiki so far, IIRC. Not doing that only on category pages but also on other pages. That is a natural way to split, fuse/merge, etc. Do it first only as text, and locally, so minimal consequences elsewhere.
– DrewAdams 2012-08-29 20:35 UTC