– DrewAdams 2012-08-29 14:09 UTC
I think the Code page is very long and could use some splitting up. The way I see it, the Code category currently has pages that teach people about coding and pages that help people to write code (libraries or extensions).
Thus, I approve of the split Roland made, even if I might not agree with the names used (I guess I’d prefer “Learning To Code” and “Libraries” categories), and I haven’t verified the placement of each and every item on either lists.
More on Comments on roland.walker.
– AlexSchroeder 2012-08-29 19:46 UTC
What I disagree with is the specific content of the split that was made. DoReMi has some things for end users, but the main thing it provides is an extension (a macro) to be used by EmacsLisp programmers. Similarly, CompletionUI and Icicles offer both, as well.
Sure, we can always list a page twice, in two places. But I don’t see the distinction of “Extensions” from “Other Lisp Libraries for Emacs Coders”. I don’t see it as a clear (thus useful) distinction. That was why I rolled back CategoryCode.
– DrewAdams 2012-08-29 20:42 UTC
I’m a bit confused by the hubub, as I created a small CategoryExtensions page to match the canonical term in the Emacs sources, and then reorganized (moved) items from CategoryCode to CategoryExtensions only when prompted to do so by AlexShroeder?.
None of us has any love for the term “extensions”, but it has standing as EmacsJargon just like other idiosyncratic terms such as “frame” for “window” and “window” for “pane”.
Drew, I did not want to put DoReMe?, Icicles, and CompletionUI beneath a boldfaced warning “this is not for end users” since all three advertise commands for end users. That was simply a conservative choice, which can be fixed in the next iteration. If you argue in particular that DoReMi is primarily an “extension” I’ll add that.
Alex, if you think that was reasonable work, I’ll follow through on three or four more, keeping an ear out for your feedback.
– roland.walker 2012-08-29 22:00 UTC
I see. Then what I guess I disagree with is that bold-faced warning.
It is not uncommon that a library has both features that extend EmacsLisp and features that provide something for end users. The point of such a category should be that the library or snippet gives you something useful for Elisp code. Whether it might also provide stuff for end users should be irrelevant.
Sure, it’s a judgment call, and if a library is 99% for end users and just happens to offer something small that might be useful to Lisp programmers, then I guess you might not want to include it in this category.
Or more reasonably, what counts is probably the degree to which a library helps in coding Lisp, regardless of whether its Lisp extensions constitute 10% or 70% of its code.
It might not be best to include Icicles after all, I guess. CompletionUI (IIUC), and DoReMi however, do offer stuff for Lisp programmers. (For DoReMi, it is mainly doremi.el that is a Lisp extension (macro
‘doremi’). doremi-frm.el is a combination, but is mostly for end users. doremi-cmd.el is only for end users – not a Lisp extension.)
That said, I still do not see the point of separating, in CategoryCode, “Extensions” from “Other Lisp Libraries for Emacs Coders”.
HTH. Sorry if I misunderstood something or overreacted.
– DrewAdams 2012-08-29 23:20 UTC
It’s cool, bro.
Yes, there’s that whole judgment call thing: an end-user library could be used by a clever programmer as a building brick (and it happens all the time), and a building-brick extension could be used by a clever end-user in their .emacs (and it happens all the time).
Yet the distinction between the two types of library is real enough. I side-stepped the judgment call by taking the library’s doc as gospel.
Another rationale for creating CategoryExtensions is that, with the advent of package.el and the various repos, this type of library will grow in popularity.
As for CategoryCode, do with it what you will. I was only following feedback from Alex and your revert is just another variety of community feedback.
– roland.walker 2012-08-30 12:52 UTC