How do we (if at all) draw the line between built-in emacs features and user-written packages?

Question

NOTICE:

Since this site is now in beta, it is time to have these conversations with the folks who are actually building this site. Please bring your comments and discussions to this site's 'meta' support forum so not to split these conversations. Thanks.

The emacs mentality encourages everyone to solve the problem they have, scratch their own itches. So there's a lot of existing user-written solutions out there.

Should we mark a preference for built-in emacs solutions? What do you think?

Proposal: Emacs

Answer 1

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.

Answer 2

It should explicitly cover both. There are two reasonable options IMO:

1. We need a specific Emacs stack exchange because of the unique combination of programming and regular usage; or
2. We want to keep Elisp programming and Emacs "general usage" separate, in which case StackOverflow and Superuser (and Tex overflow etc.) are decent forums for those two issues separately.

I definitely agree with (1) since it's usually difficult to know which you are asking - and sometimes you use a standard package, but customise it with a snippet of elisp, which could mean bouncing back and forth between SO and SU.

Answer 3

As I understand it, it is more complicated than "built-in vs 3rd-party". There are:

• core features
• elisp which is part of the default emacs distribution
• elisp which is part of the default emacs package repository (elpa)
• elisp which is part of alternative emacs distributions
• elisp packages bundled together into user-friendly initial configurations (prelude, ergoemacs...)
• elisp which is maintained and available on melpa, github...
• ad-hoc elisp snippets (available on emacswiki or stackoverflow for example).

Add to that the existence of different flavors of emacs, each with its own set of specific features... For example, if a user asks for tabs in the emacs UI, aquamacs users will tell him that it is built in, while vanilla emacs users will need a 3rd party package. Not even mentioning the different emacs versions ("does there exist a package manager?" or "how to change the color theme?" in pre-24 for example).

But it isn't a problem that is exclusive to emacs either. A C++ question on SO can get one answer using only built-in features, another with the standard library, and another with ad-hoc code. Votes will just select the most convenient one.

This would work here as well: let each answer advertise its favorite way of doing things, and the asker will pick the one he likes most (or even try several).