Guidelines for external packages in answers

Question

With the advent of package.el and external package repos such as MELPA, Emacs has an increasingly vague notion of what's "built-in". What should the guidelines be regarding answers that reference external packages? Should a "good" answer be restricted to "core" Emacs and/or GNU ELPA, or should packages from the Wiki and/or MELPA also be fair game? What about popular packages such as Evil, which might be better served by a different forum?

Answer 1

Restricting questions to only those in core Emacs and the default ELPA repository severely limits the breadth of knowledge which can be disseminated through emacs.SX.

A prerequisite question is "what is our goal?" If our goal is to build an approachable and accessible compendium of Emacs-related knowledge (which I think is -- at the least -- a reasonable starting point for a goal) does it make sense to restrict it to core Emacs?

I would say no. Here are examples:

Suppose that I am a Vim user interested in immigrating to Emacs. I like the way that Vim editing works, but want the power and flexibility that Emacs' foundation provides. If Evil questions are off-topic, then I will have to look elsewhere for information on it. Is this desired?

Suppose that I am a new user working primarily on a large C++ project. I like working in Linux, but miss several features from Visual Studio like code snippets and auto-completion. If yasnippet and auto-complete/company questions are off-topic, then I will have to look elsewhere for information. Is this desired?

Suppose that I am an existing user and I want to install a new package to simplify some task. However, this package has a conflict with another package. Try as I might, I have not been able to resolve the conflict in a satisfactory fashion. If external packages are off-topic, then I will have to look elsewhere for information. Is this desired?

My answer in all three cases is a resounding no. External packages are one of the big draws of Emacs. They help it stand out from other editing environments and are one of the reasons that it has survived for almost 40 years.

We have tags for a reason and we should use them. Evil questions should be tagged evil, Magit questions should be tagged magit, etc. The tagging system helps keep questions organized and accessible while also allowing users to avoid questions that they can't answer and answers that they aren't interested in.

Regarding the guidelines for referring an external vs built-in package, I already gave an answer on the proposal:

A preference should be given towards the 'best' solution -- built in or user-created barely enters the equation.

For example, Emacs has Version Control tools built-in. However, I and many others find Magit a better solution for Git-specific tasks. Which should be the appropriate answer to "How can I view git log in Emacs?"?

My answer would be Magit, because it is much more powerful for viewing git logs. VC can show decent logs for the current branch (C-x v l) and short logs for the branch and its parent (C-x v L) but has no obvious way to do more complex log viewing; Magit can do those as well on top of being able to easily show logs with file change info (magit-prefix l L), commits by individuals (l =c L), commits after/before/on a given date, and much more.

tl;dr version: where it came from matters much less than the potency of the solution.

I still hold this view. If a built-in package is adequate but an external package has more to offer, then both may warrant mention. If a built-in package is less-than-adequate for some task, it makes sense for the answerer to recommend what they think is the best solution within the context of the Emacs ecosystem (if I wanted vim-style bindings, "switch to vim" would not be an acceptable solution, but "use evil-mode" would be).

tl;dr - External packages should be on-topic. Tag them as appropriate.

Answer 2

I'd find it ironic, if we would discourage questions about packages. After all, isn't extensibility what Emacs is all about?

And how could be possibly draw a line between an answer that recommends an external package (e.g. IDO Ubiquitous) and an answer that includes a rather lengthy convoluted code to implement a similar behaviour in your own init.el, albeit with much less testing and much more bugs?

Answer 3

I don't see why not. Heck, I'd even say that XEmacs is ontopic.

Answer 4

Anything is fair game as long as you're doing it in Emacs. This goes for answers, but also for questions: questions about a specific Emacs package are on-topic too.

This is the policy used on other sites. For example, Ask Ubuntu, Ask Different and Unix & Linux aren't limited to applications bundled with the operating system, questions about third-party applications (even cross-platform ones) are on-topic as long as the question is about running them on an on-topic operating system.

I think this is the only policy that makes sense. We certainly can't prevent answers that propose third-party packages: extensibility is a key feature of Emacs. As for questions about third-party packages, forbidding them would make an odd distinction: a question would be on-topic if it asked how to do something that's best done with a specific third-party package, but off-topic if the asker had already started to use that package. The distinction is blurry anyway as more and more third-party packages get included in the core system with each release; and different Emacs implementations and distributions come bundled with different sets of packages. Furthermore users may be using packages that happen to be installed on their system and wouldn't know or care whether these packages are part of the core release.

Answer 5

I agree with the spirit of the answers here. However let me play the devil's advocate. Should we recommend installing dash.el so that OP can use one convenient piece of elisp to attain her objective that could be performed using emacs core, albeit in a convoluted way ? Won't the typically faster development cycles of external packages lead to outdated or conflicting suggestions ?

I think a little bit of effort in framing acceptable alternatives for 3rd party packages would be helpful to the community in the long run. Emacs has a way of subsuming useful behavior into its core, so the balance in terms of 3rd party packages and core emacs will trade places.

Personally though, my answer to the above two questions would be in favor of the 3rd party packages.

EDIT: By "we" I meant any person as referred in @Drew's comment. Also my intention was to point out that answers with fewer dependencies should also be welcome irrespective of how long/convoluted they are. More importantly, the answer should explain what is entailed of the user to get that answer to work. This could mean things like pointing out which version/repo of a package to get in some cases as well. As always the reader will choose, but only if there is a choice.