대문 최근에 바뀐 글 새소식 찾기 하우투 문제 제안

SiteMap Discussion

리비젼 243 과 현재 리비젼 간의 차이

요약: Rollback to 2013-06-15 14:25 UTC

변경됨:

<

(으)로

> This page discusses how the front page, SiteMap, should look.
> The bottom half of this page lists decided issues, the top half is for
> discussion of open issues.
> Here's what SiteMap does:
> * It has a short introduction for newbies, pointing them to some pages with more information.
> * It lists all the major categories; a category is a tag attached to pages in order to classify them. The category pages offer a list of pages belonging to the category, and they offer a search for these tags (by searching for backlinks -- click on the title of the category page).
> * It has a small number of maintenance functions for interested users.
> == Open Issues ==
> === Creation of Categories and CategoryCategories ===
> In the past day or so, [[roland.walker]] has created several new category pages and a meta-category page, CategoryCategories. I thought, but don't find it now, that categories were to be created only after discussion (where? here?). Doesn't seem like a good idea that people should just be creating category pages willy nilly. -- DrewAdams
> [new]
> At the top of SiteMap it says:
> : Please check SiteMap Discussion before editing this SiteMap page, however.
> I think CategoryCategories is a tradition from the Portland Pattern Repository (the first wiki). It doesn't seem quite so useful here since the SiteMap is supposed do double duty as a commented list of all the categories. I'll read through the changes made and leave comments where appropriate. -- AlexSchroeder
> [new:DrewAdams:2012-08-28 23:12 UTC]
> Yes, it says that about editing SiteMap, but it says nothing about proposing new categories (e.g., here), for discussion, before creating them. Perhaps it should (I think so).
> Seems like there should be some discussion, or at least opportunity for discussion, before creating a new category page (or deleting an existing one). Category pages are at the meta level, and they determine the shape/organization of the wiki in a stronger way than do non-category pages. -- DrewAdams
> === CategoryBatchMode ===
> Let's just rename this to BatchMode, and make it a sub-page of CategoryCode. -- AaronHawley
> [new:DrewAdams:2010-08-05 18:10 UTC]
> I have no strong feelings about it, but why? Why not keep all categories with the prefix ##Category##, for consistency? For one thing, searching for `category' finds them all as the first hits. What's the reason for treating this category exceptionally?
> If your point was that we do not need such a category, then the response should be to just get rid of it, changing all refs to it to refs to ##CategoryCode##. And then perhaps have an anchor on the CategoryCode page for BatchMode. Maybe that's in fact what you meant? -- DrewAdams
> [new]
> I meant the latter. Shall we demote it from a category to a regular page? -- AaronHawley
> [new:DrewAdams:2010-08-05 20:02 UTC]
> OK by me. -- DrewAdams
> [new]
> Yes we should. :) -- AlexSchroeder
> === Mention Wiki Organization by Categories ===
> Categories are important to discovery and navigation. The SiteMap page is the canonical listing of all categories. It is there that you look, to see what categories are available for classifying your new page. However, the category names are abbreviated on the %%SiteMap%%. That helps readability, but it obscures the list of categories for editing purposes. The %%SiteMap%% should contain a brief mention such as the following:
> : Note: The category names are abbreviated in the links used on this page -- for example, CategoryKeys is abbreviated as [[CategoryKeys|Keys]]. It is the full name that you must add to a wiki page to add it to a given category: just add the prefix ##Category##.
> -- DrewAdams
> [new]
> Don't we have a page like HowToEdit or something similar? Maybe that would be a better place? -- AlexSchroeder
> [new:DrewAdams:2009-09-20 00:10 UTC]
> Yes, it's CreateNewPages, and I already added it there. I still think it's needed also on the SiteMap. Many people will create pages without passing through %%CreateNewPages%%. They are, however, likely to stumble upon the explanation at %%SiteMap%%. -- DrewAdams
> === "Customize" Pseudo-Heading Is Misguided ===
> Most of the categories under the pseudo-heading "Customize" are general and not necessarily about customizing at all. It was quite misguided to group things this way. Just look at those category pages ([[CategoryWindows|Windows]], [[CategoryKeys|Keys]], [[CategoryMouse|Mouse]], [[CategoryDisplay|Display]]...) -- you will find general information and lots of other material that has nothing to do with customization. [[CategoryKeys|Keys]] is not more about customization than is [[CategoryMenus|Menus]], for instance.
> This category organization is incorrect, misleading, and unhelpful. "Customize" should be removed altogether. Customization of different kinds of things (keys, faces, frames, etc.) is found within the categories for those features. Customization is everywhere in Emacs, and nearly everything is customizable. List the features here; users will look for their customization within their categories. -- DrewAdams
> [new]
> Well said -- indeed "nearly everything is customizable." I agree that the category is not selective enough. -- AlexSchroeder
> === Headings ===
> In my last edit of the SiteMap, I accidentally removed the headings when I was only trying to change the link format for all the categories.
> How about we give this format without a table of contents a try? Did anyone think the navigation was useful? I predict a lot of visitors need to scroll the page anyway to get an idea of where they should find what they're looking for. I know there are opinions that the SiteMap isn't well organized anyway. This would ease scrolling?
> If only there was time for a usability study... -- AaronHawley
> [new:DrewAdams:2009-07-08 13:31 UTC]
> Discussion should occur before a change is made, not afterward. I wonder how one "accidentally" removes "##==##" both before and after each individual heading?
> Now, people should compare the current version with the version before your change, by looking at two browser windows (not just a ##diff##).
> My opinion ''before'' comparing: It doesn't make much difference; it's OK as it is now.
> My opinion ''after'' comparing: the TOC helps, and should be restored. Especially because the categories are numerous and not always well-defined. A TOC helps you see at a glance how the page is organized and what the "categories of categories" are.
> Yes, people will often scroll the page, regardless. That does not mean that it isn't helpful to let them know what super-category a given category is in. And no, this does not "ease scrolling". It simply makes a global view more difficult. Being obliged to skim the entire page does not imply "easing scrolling". Just one opinion. -- DrewAdams
> [new:DrewAdams:2009-09-19 17:09 UTC]
> Aaron's "accidental" change should have been reverted, pending discussion and a consensus. Instead, the previous version is now lost (so you cannot even compare). So much for site-map "discussion". -- DrewAdams
> === Highlighting ===
> There is no category for highlighting. Currently, from the SiteMap, pages about highlighting text can only be found by going to '''Customize''', then '''Faces''', neither of which is suggestive for someone looking to, say, highlight matches for a regexp in a buffer -- that is not really about customizing. Highlighting can mean several things, including standard font-lock and everything in HighlightTemporarily. How about adding a [[Highlighting]] category? It could be situated next to category [[CategoryHideStuff|HideStuff]], for instance. If no objection is raised here, I'll do this. -- DrewAdams
> [new]
> I agree, a new category is necessary. -- Alex
> [new]
> So the cross-references on CategoryFaces would be moved to CategoryHighlighting, or will they need to be doubly-maintained on both pages? -- AaronHawley
> [new:DrewAdams:2009-04-20 14:34 UTC]
> My opinion: ''Add'' CategoryHighlighting to the pages that currently have CategoryFaces, but only if they seem to be about highlighting -- case by case. It's a judgment call. But I'd think that most, if not all, would continue to also be in CategoryFaces.
> We can view highlighting as a subcategory of faces or not; either would work. Probably not is better, since much to do with faces doesn't really involve highlighting.
> But the important thing is to not force this stuff to be part of CategoryCustomize. I don't even think category Faces should be under category Customize. It's not because you can customize faces that that's all that faces are about. -- DrewAdams
> [new]
> I predict things in CategoryFaces that have "highlight" in their name will be in highlighting--HighlightTemporarily,
> HighLight,
> HiLock,
> HighlightCurrentLine,
> HighlightCurrentColumn,
> HighlightEndOfBuffer,
> HighlightSymbol,
> HighlightParentheses. This might be a mistake. There are many things that have similar functionality but probably won't make it just because they aren't named highlighting--ReBuilder, EightyColumnRule, VisibleMark, ShowParenMode, TransientMarkMode or IncrementalSearch. CategoryFaces obviously doesn't even cover these pages.
> Further, "syntax highlighting", or FontLockMode as it's known to Emacsen users--isn't likely well served in a highlighting category because it's not predominant a connotation, see [[Manual:Highlight Interactively]]. There are pages on the site narrowly focused on highlighting that deserve this category, but we need to keep in mind that highlighting is a user interface technique that spans a lot of Emacs features. So, even for the "highlighting" examples above, the best solutions are probably still CategoryRegexp, CategoryRegion, CategoryDisplay, CategoryEditing, CategoryParentheses.
> I don't have a proposal, but I'm saying that "case by case" may backfire. I know many pages are cross-listed in two or more categories in an effective way. However, "highlighting" might become such a catch-all that it could become diluted and not useful. -- AaronHawley
> [new]
> Well, thinking about every page individually makes sense. We just need to define what "highlighting" is going to be about. I'd say that highlighting is about manually highlighting things (ie. not Font Lock), or automatically highlighting particular user interface features (a particular column, the current line, the end of the buffer, nothing mode-specific). -- Alex
> [new]
> I think you've defined highlighting well. So, would that put ReBuilder, EightyColumnRule, VisibleMark, ShowParenMode, TransientMarkMode and IncrementalSearch in the category? With that, I think it might still be too broad. My concern being "highlighting is a user interface technique that spans a lot of Emacs features". However, I guess there's no other way to do this but to include them all.
> Here's a proposal for the category's description.
> : ''This category contains pages about manually highlighting things in Emacs or automatically highlighting particular user interface features--the current line, a particular column, the end of the buffer. For pages about syntax highlighting (Font Lock), see CategoryFaces.''
> Feel free to delete what I have and make a comment containing your latest modification of the above. -- AaronHawley
> === Organization of Categories ===
> The SiteMap is less useful than it was. It's fine to try to group things into subcategories, but only if those groups make sense and are helpful. There is lots of stuff under '''Customize''', for instance, that is not necessarily about customizing Emacs. E.g., if you wanted to learn about manipulating and navigating among Emacs windows, you wouldn't think to look under '''Customize'''. A related problem is the lack of parallelism for categories: some are verb forms corresponding to things you might do ("customize"); others are noun forms corresponding to Emacs objects of different kinds ("commands"). Both task-oriented and object-oriented organizations can be useful, but they should generally be separated. No need to be anal about this, but the current mishmash is particularly unhelpful. -- DrewAdams
> [new]
> I'm not sure what the problem is. Do we have too many categories per page? Or do we need to support category synonyms (or more redirections)? Or do we just need to concentrate on the categories we actually use on the SiteMap and use those more consistently? -- Alex
> === External libraries ===
> [new]
> Added descriptive text about where to find categories and external libs (it wasn't obvious, as the Categories pages linked to on SiteMap seemed to me and others (at first glance) to be general emacs info, and not external libs). I've used the emacswiki for a long time (and have posted libs here) and it used to be more apparent where to find libs. -- [[trogdoroeu]]
> [new]
> Removed section, but included mention of where to find libraries for HowToNavigate. -- DrewAdams.
> [new]
> I put the mention of EmacsLisp in the intro for the SiteMap, since this site is more than just "documenting and discussing Emacs and XEmacs" -- there's a lot of Elisp hacking.
> I also put (back) a link for ElispArea at the top of SiteMap. I had moved it off the SiteMap to HowToNavigate, but its probably notable enough to put on the SiteMap. -- AaronHawley
> [new:DrewAdams:2008-09-15 16:05 UTC]
> I agree with what Aaron has done. [[trogdoroeu]]'s concern seems to be letting people know that they can find source code and especially links to source code, including code at off-wiki URLs, on the various category pages and other wiki pages. Linking to ElispArea up front is important, but it doesn't really take care of [[trogdoroeu]]'s concern. I'm not sure how best we could do that. I tend to think that people will figure that out, but s?he obviously got the opposite impression. -- DrewAdams
> [new]
> I think it might be good to put the different elisp sources on equal levels.
> As it is now ElispArea seems to be superior - which is true for some elisp files but not for others.
> Therefore elisp libraries that are not mentioned in ElispArea might go unnoticed to novices.
> I suggest this:
> * Add a new page ElispLibs and put this in the top row instead of ElispArea.
> * Move the explanation of the different sources from ElispArea to ElispLibs.
> * Encourage users to put ElispLibs at the bottom in the "category area" on pages that links to external elisp sources.
> -- LennartBorgman
> [new]
> Shouldn't elisp files that are not hosted here be listed on the WikifiedEmacsLispList because they are part of the [[ELL]]? Maybe we just need to link to it prominently? -- AlexSchroeder
> [new]
> Yes, maybe they should be listed there.
> But I think there is a problem with that list.
> It contains single files and there is no notion of packages there.
> CEDET is not mentioned at all, JDEE is mentioned as jdee.el and nXhtml as nxhtml.el.
> These should be better mentioned in another way.
> The list is really structured around single elisp files.
> It is problematic to find related files and all files are not mentioned there.
> -- LennartBorgman
> [new]
> I'm not sure what the conclusion of this discussion is. No problem? Must do something? What? -- Alex
> [new]
> I just added the page EmacsPackages. Please link to this from WikifiedEmacsLispList. -- LennartBorgman
> [new]
> I actually didn't think there was a problem. EmacsLispList lists many "packages". And if not, EmacsWiki -- as a project -- has been the making up by documenting "Emacs Lisp packages" -- a better phrase than "Emacs packages", perhaps. -- AaronHawley
> [new]
> Yes, Emacs Lisp Packages seems like a better name.
> But I really did think there was a problem.
> How do you expect a new comer to Emacs to find those packages listed on EmacsPackages now? -- Lennart
> [new]
> I was suggesting by EmacsWiki via the SiteMap or [[Search]]. Many "packages" are listed on the EmacsLispList already, anyway. -- AaronHawley
> [new]
> But packages of elisp code, like for example CEDET, are not at the same level as individual elisp files.
> There a much more effort put in these packages and the users deserves a good way to find them.
> I do not know how many elisp files there are here, but there are surely just a few packages with elisp files that are written to work together. -- LennartBorgman
> == Past Decisions ==
> These are some conclusions from past discussions.
> * "Emacs Community" does not belong at the top. People come to this site primarily to obtain information and secondarily to offer information -- about Emacs. All the rest is a third-level concern.
> * EmacsNewbie and [[CategoryPorts|Ports]] are important info on how to get started with Emacs.
> * [[News]] just collects the last few date pages. If you read RecentChanges, you'll get links to these pages anyway, so you don't need to look at the News page. The News page is for people that don't follow RecentChanges. Date pages are for important events, bugs on the wiki, and links to interesting threads on Emacs mailing-lists or newsgroups.
> * The header of this wiki usually shows national days. This includes messages such as "Iran, Victory of the Islamic Revolution in Iran." This is not a statement on current events. It just reminds us of the vast diversity of culture on this planet -- language, government, religion.
> * We won't be adding a sidebar to the wiki.


This page discusses how the front page, SiteMap, should look. The bottom half of this page lists decided issues, the top half is for discussion of open issues.

Here’s what SiteMap does:

Open Issues

Creation of Categories and CategoryCategories

In the past day or so, roland.walker has created several new category pages and a meta-category page, CategoryCategories. I thought, but don’t find it now, that categories were to be created only after discussion (where? here?). Doesn’t seem like a good idea that people should just be creating category pages willy nilly. – DrewAdams

At the top of SiteMap it says:

Please check SiteMap Discussion before editing this SiteMap page, however.

I think CategoryCategories is a tradition from the Portland Pattern Repository (the first wiki). It doesn’t seem quite so useful here since the SiteMap is supposed do double duty as a commented list of all the categories. I’ll read through the changes made and leave comments where appropriate. – AlexSchroeder

Yes, it says that about editing SiteMap, but it says nothing about proposing new categories (e.g., here), for discussion, before creating them. Perhaps it should (I think so).

Seems like there should be some discussion, or at least opportunity for discussion, before creating a new category page (or deleting an existing one). Category pages are at the meta level, and they determine the shape/organization of the wiki in a stronger way than do non-category pages. – DrewAdams

CategoryBatchMode

Let’s just rename this to BatchMode, and make it a sub-page of CategoryCode. – AaronHawley

I have no strong feelings about it, but why? Why not keep all categories with the prefix Category, for consistency? For one thing, searching for ‘category’ finds them all as the first hits. What’s the reason for treating this category exceptionally?

If your point was that we do not need such a category, then the response should be to just get rid of it, changing all refs to it to refs to CategoryCode. And then perhaps have an anchor on the CategoryCode page for BatchMode. Maybe that’s in fact what you meant? – DrewAdams

I meant the latter. Shall we demote it from a category to a regular page? – AaronHawley

OK by me. – DrewAdams

Yes we should. :) – AlexSchroeder

Mention Wiki Organization by Categories

Categories are important to discovery and navigation. The SiteMap page is the canonical listing of all categories. It is there that you look, to see what categories are available for classifying your new page. However, the category names are abbreviated on the SiteMap. That helps readability, but it obscures the list of categories for editing purposes. The SiteMap should contain a brief mention such as the following:

Note: The category names are abbreviated in the links used on this page – for example, CategoryKeys is abbreviated as Keys. It is the full name that you must add to a wiki page to add it to a given category: just add the prefix Category.

DrewAdams

Don’t we have a page like HowToEdit or something similar? Maybe that would be a better place? – AlexSchroeder

Yes, it’s CreateNewPages, and I already added it there. I still think it’s needed also on the SiteMap. Many people will create pages without passing through CreateNewPages. They are, however, likely to stumble upon the explanation at SiteMap. – DrewAdams

"Customize" Pseudo-Heading Is Misguided

Most of the categories under the pseudo-heading “Customize” are general and not necessarily about customizing at all. It was quite misguided to group things this way. Just look at those category pages (Windows, Keys, Mouse, Display…) – you will find general information and lots of other material that has nothing to do with customization. Keys is not more about customization than is Menus, for instance.

This category organization is incorrect, misleading, and unhelpful. “Customize” should be removed altogether. Customization of different kinds of things (keys, faces, frames, etc.) is found within the categories for those features. Customization is everywhere in Emacs, and nearly everything is customizable. List the features here; users will look for their customization within their categories. – DrewAdams

Well said – indeed “nearly everything is customizable.” I agree that the category is not selective enough. – AlexSchroeder

Headings

In my last edit of the SiteMap, I accidentally removed the headings when I was only trying to change the link format for all the categories.

How about we give this format without a table of contents a try? Did anyone think the navigation was useful? I predict a lot of visitors need to scroll the page anyway to get an idea of where they should find what they’re looking for. I know there are opinions that the SiteMap isn’t well organized anyway. This would ease scrolling?

If only there was time for a usability study… – AaronHawley

Discussion should occur before a change is made, not afterward. I wonder how one “accidentally” removes “==” both before and after each individual heading?

Now, people should compare the current version with the version before your change, by looking at two browser windows (not just a diff).

My opinion before comparing: It doesn’t make much difference; it’s OK as it is now.

My opinion after comparing: the TOC helps, and should be restored. Especially because the categories are numerous and not always well-defined. A TOC helps you see at a glance how the page is organized and what the “categories of categories” are.

Yes, people will often scroll the page, regardless. That does not mean that it isn’t helpful to let them know what super-category a given category is in. And no, this does not “ease scrolling”. It simply makes a global view more difficult. Being obliged to skim the entire page does not imply “easing scrolling”. Just one opinion. – DrewAdams

Aaron’s “accidental” change should have been reverted, pending discussion and a consensus. Instead, the previous version is now lost (so you cannot even compare). So much for site-map “discussion”. – DrewAdams

Highlighting

There is no category for highlighting. Currently, from the SiteMap, pages about highlighting text can only be found by going to Customize, then Faces, neither of which is suggestive for someone looking to, say, highlight matches for a regexp in a buffer – that is not really about customizing. Highlighting can mean several things, including standard font-lock and everything in HighlightTemporarily. How about adding a [[Highlighting?]] category? It could be situated next to category HideStuff, for instance. If no objection is raised here, I’ll do this. – DrewAdams

I agree, a new category is necessary. – Alex

So the cross-references on CategoryFaces would be moved to CategoryHighlighting?, or will they need to be doubly-maintained on both pages? – AaronHawley

My opinion: Add CategoryHighlighting? to the pages that currently have CategoryFaces, but only if they seem to be about highlighting – case by case. It’s a judgment call. But I’d think that most, if not all, would continue to also be in CategoryFaces.

We can view highlighting as a subcategory of faces or not; either would work. Probably not is better, since much to do with faces doesn’t really involve highlighting.

But the important thing is to not force this stuff to be part of CategoryCustomize. I don’t even think category Faces should be under category Customize. It’s not because you can customize faces that that’s all that faces are about. – DrewAdams

I predict things in CategoryFaces that have “highlight” in their name will be in highlighting--HighlightTemporarily, HighLight, HiLock, HighlightCurrentLine, HighlightCurrentColumn, HighlightEndOfBuffer, HighlightSymbol, HighlightParentheses. This might be a mistake. There are many things that have similar functionality but probably won’t make it just because they aren’t named highlighting--ReBuilder, EightyColumnRule, VisibleMark, ShowParenMode, TransientMarkMode or IncrementalSearch. CategoryFaces obviously doesn’t even cover these pages.

Further, “syntax highlighting”, or FontLockMode as it’s known to Emacsen users--isn’t likely well served in a highlighting category because it’s not predominant a connotation, see Highlight Interactively. There are pages on the site narrowly focused on highlighting that deserve this category, but we need to keep in mind that highlighting is a user interface technique that spans a lot of Emacs features. So, even for the “highlighting” examples above, the best solutions are probably still CategoryRegexp, CategoryRegion, CategoryDisplay, CategoryEditing, CategoryParentheses.

I don’t have a proposal, but I’m saying that “case by case” may backfire. I know many pages are cross-listed in two or more categories in an effective way. However, “highlighting” might become such a catch-all that it could become diluted and not useful. – AaronHawley

Well, thinking about every page individually makes sense. We just need to define what “highlighting” is going to be about. I’d say that highlighting is about manually highlighting things (ie. not Font Lock), or automatically highlighting particular user interface features (a particular column, the current line, the end of the buffer, nothing mode-specific). – Alex

I think you’ve defined highlighting well. So, would that put ReBuilder, EightyColumnRule, VisibleMark, ShowParenMode, TransientMarkMode and IncrementalSearch in the category? With that, I think it might still be too broad. My concern being “highlighting is a user interface technique that spans a lot of Emacs features”. However, I guess there’s no other way to do this but to include them all.

Here’s a proposal for the category’s description.

This category contains pages about manually highlighting things in Emacs or automatically highlighting particular user interface features--the current line, a particular column, the end of the buffer. For pages about syntax highlighting (Font Lock), see CategoryFaces.

Feel free to delete what I have and make a comment containing your latest modification of the above. – AaronHawley

Organization of Categories

The SiteMap is less useful than it was. It’s fine to try to group things into subcategories, but only if those groups make sense and are helpful. There is lots of stuff under Customize, for instance, that is not necessarily about customizing Emacs. E.g., if you wanted to learn about manipulating and navigating among Emacs windows, you wouldn’t think to look under Customize. A related problem is the lack of parallelism for categories: some are verb forms corresponding to things you might do (“customize”); others are noun forms corresponding to Emacs objects of different kinds (“commands”). Both task-oriented and object-oriented organizations can be useful, but they should generally be separated. No need to be anal about this, but the current mishmash is particularly unhelpful. – DrewAdams

I’m not sure what the problem is. Do we have too many categories per page? Or do we need to support category synonyms (or more redirections)? Or do we just need to concentrate on the categories we actually use on the SiteMap and use those more consistently? – Alex

External libraries

Added descriptive text about where to find categories and external libs (it wasn’t obvious, as the Categories pages linked to on SiteMap seemed to me and others (at first glance) to be general emacs info, and not external libs). I’ve used the emacswiki for a long time (and have posted libs here) and it used to be more apparent where to find libs. – [[trogdoroeu?]]

Removed section, but included mention of where to find libraries for HowToNavigate. – DrewAdams.

I put the mention of EmacsLisp in the intro for the SiteMap, since this site is more than just “documenting and discussing Emacs and XEmacs” – there’s a lot of Elisp hacking.

I also put (back) a link for ElispArea at the top of SiteMap. I had moved it off the SiteMap to HowToNavigate, but its probably notable enough to put on the SiteMap. – AaronHawley

I agree with what Aaron has done. [[trogdoroeu?]]’s concern seems to be letting people know that they can find source code and especially links to source code, including code at off-wiki URLs, on the various category pages and other wiki pages. Linking to ElispArea up front is important, but it doesn’t really take care of [[trogdoroeu?]]’s concern. I’m not sure how best we could do that. I tend to think that people will figure that out, but s?he obviously got the opposite impression. – DrewAdams

I think it might be good to put the different elisp sources on equal levels. As it is now ElispArea seems to be superior - which is true for some elisp files but not for others. Therefore elisp libraries that are not mentioned in ElispArea might go unnoticed to novices.

I suggest this:

  • Add a new page ElispLibs? and put this in the top row instead of ElispArea.
  • Move the explanation of the different sources from ElispArea to ElispLibs?.
  • Encourage users to put ElispLibs? at the bottom in the “category area” on pages that links to external elisp sources. – LennartBorgman

Shouldn’t elisp files that are not hosted here be listed on the WikifiedEmacsLispList because they are part of the ELL? Maybe we just need to link to it prominently? – AlexSchroeder

Yes, maybe they should be listed there. But I think there is a problem with that list. It contains single files and there is no notion of packages there. CEDET is not mentioned at all, JDEE is mentioned as jdee.el and nXhtml as nxhtml.el. These should be better mentioned in another way.

The list is really structured around single elisp files. It is problematic to find related files and all files are not mentioned there. – LennartBorgman

I’m not sure what the conclusion of this discussion is. No problem? Must do something? What? – Alex

I just added the page EmacsPackages. Please link to this from WikifiedEmacsLispList. – LennartBorgman

I actually didn’t think there was a problem. EmacsLispList lists many “packages”. And if not, EmacsWiki – as a project – has been the making up by documenting “Emacs Lisp packages” – a better phrase than “Emacs packages”, perhaps. – AaronHawley

Yes, Emacs Lisp Packages seems like a better name.

But I really did think there was a problem. How do you expect a new comer to Emacs to find those packages listed on EmacsPackages now? – Lennart

I was suggesting by EmacsWiki via the SiteMap or Search. Many “packages” are listed on the EmacsLispList already, anyway. – AaronHawley

But packages of elisp code, like for example CEDET, are not at the same level as individual elisp files. There a much more effort put in these packages and the users deserves a good way to find them. I do not know how many elisp files there are here, but there are surely just a few packages with elisp files that are written to work together. – LennartBorgman

Past Decisions

These are some conclusions from past discussions.