7
votes

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

  • 1
    I'm pretty sure that the questions here are for questions about creating emacs.stackexchange. – Edgar Aroutiounian Sep 11 '14 at 0:37
  • 3
    Yes. My question is targeted towards the kind of answer that we're looking for on emacs.stackexchange. I believe that it on-topic, in order to figure out what we are trying to get out of emacs.stackexchange. Do you disagree? – Trevoke Sep 11 '14 at 1:05
  • No, you're right. – Edgar Aroutiounian Sep 11 '14 at 14:01
17
votes

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.

  • Yes, built-in vs user-created is not relevant. But who should be giving a "preference" to the "best" solution? Let the asker see all technical solutions, and let the asker decide what is "best". – Drew Sep 20 '14 at 15:57
4
votes

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.

  • I reject your #1 vs #2. The "unique combination" is served well currently. Asking an Emacs question should not preclude answers of a particular kind. As an asker you are helped by technical answers of all sorts, because Emacs is Elisp. An answer might point you to a key binding or to a 3rd-party pkg or provide Elisp instruction. Askers benefit from such a variety of different-level answers. There are lots of "end-user" [emacs] questions on SO. Because of programmatic replies, they do not get migrated to SuperUser. 84% of [emacs] Qs are on SO. IOW, this is not a problem currently. – Drew Sep 20 '14 at 15:47
3
votes

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).

  • Good answer. There are no clear divisions here. Much of base emacs was once "user-written" solutions. – Faheem Mitha Sep 18 '14 at 10:17
  • Precisely. See my comment to @Mark Aufflick's answer. [emacs]-tagged questions on SO tend to remain there, even when they are "end-user" questions and might invite some "end-user" answers. This is because Emacs being Emacs (being Elisp), there is more than one way to skin a cat, and multiple levels of answer are possible, from nitty-gritty Elisp to simple RTFM-use-this-key reminders. Askers benefit from such a variety of answers - they learn that Emacs is open, and they learn how to look under the hood themselves. – Drew Sep 20 '14 at 15:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .