11

Emacs is, as everyone knows, self documented lisp environment with very good Info system built-in.

Given that, is it good way to start an answer with "Ask Emacs"? I'm referring What's the difference between setq and defvar for an example.

I know @Drew has been actively answering and maintaining the site, so he must be right. I'd like to make sure that it is the way we are answering here at emacs sx.

Thank you everyone for making emacs stackexchange such a great place.

14

The risk is that it may sound somewhat condescending to the asker as it implies that they have not already "asked Emacs" (aka "RTFM"). They may have asked and not understood what the manual told them.

I often do something like:

  1. Ask Emacs.
  2. Fail to understand Emacs.
  3. Ask Google.
  4. Find a StackExchange questions whose answer explains what I want.

I think I would be justified in being slightly annoyed if the first sentence of that answer was an imperative telling me to do exactly the thing I already did. Starting off with "Ask Emacs" adds little to the answer and may unnecessarily alienate a user.

An opening like

This is explained in the manual section Defining Variables. You can access this from inside Emacs using C-h i, choosing the Elisp manual, then i defvar.

has the same content (the useful link to the manual and instruction on how to find it) but seems less hostile.

  • 4
    A good question should include troubleshooting steps already taken. If the user has already asked Emacs, then they should be including that information in the question to help potential answerers identify the issue. – Ryan Jan 5 '17 at 22:55
  • Thank you for your answer. That's what I felt when I first saw the "Ask Emacs". I agree completely with @Ryan 's comment here but that doesn't mean a question should start with "Ask Emacs". ATM, I personally favor the opening suggested in this answer. – Yasushi Shoji Jan 6 '17 at 1:45
  • 2
    @Drew regularly answers questions with 'Ask Emacs', and I've never seen him do so without immediately explaining how exactly to do that in the context of the current question. I think these are very valuable answers, and not really comparable to a typical 'RTFM'. – Tyler Jan 6 '17 at 18:52
  • 1
    It would be neat if the Elisp doc str quoting style -- `` `defvar' `` -- would auto-linkify here. :) (Yes yes I realize the SE markdown parser will never support that.) – Greg Hendershott Jan 10 '17 at 18:29
  • 1
    If a user has tried to ask Emacs and not found the information, and they read an answer which shows them another way to ask Emacs which does provide the information, then they may well have learned something new about the different ways to ask Emacs -- which will benefit them in future. When the same answer goes on to provide the requested information directly, I feel the reader should be the very opposite of "annoyed". SE is about helping users with Emacs, and promoting and helping them learn how to ask Emacs is probably the single most valuable thing we can do. – phils Jan 17 '17 at 7:01
7

FWIW, Drew does not start all, or most, answers with ask Emacs. (Nor does he include ask Emacs in all, or most, answers.) Only a tiny percentage of his answers include ask Emacs in one form or another. Only when he thinks it is germane to the particular question - when he thinks it is a question where asking Emacs makes a lot of sense.

The point of not just telling, but showing users how to ask Emacs is to help them learn to help themselves. That's not to dismiss their question or toss them on their own or tell them they shouldn't ask here. Emacs doesn't act that way, and neither does Drew, he hopes.

The point is that Emacs itself is especially good at helping you help yourself, but learning how to ask it is, well, a learning process. And not only for newbies.

But it's not just to help users learn to help themselves, in the usual sense. It's also to point out that Emacs is transparent all the way down (at least in Lisp). This is really the message underneath ask Emacs, beyond getting you to your specific answer. Not RTFM, but Look Ma, you can see inside this thing!

That asking Emacs works, that it is one of the best ways to both learn Emacs and solve problems, is precisely a thing about Emacs itself - one of its most important features - maybe its central feature: You can interact with it. Talk to it. Look deeply into it. Ask it how it works. It's usually easy and often powerful. (This is mostly because Emacs is Lisp. And because it is free software - no hidden implementation.)

This is not something obvious, even today (when apps and languages have built-in doc, contextual help, AI assistants, good search, etc.). What Emacs does to help you - what Emacs is - is not something that most people are used to or expect.

Why not just show them, without adding the mantra "ask Emacs"? Because the message is not just that you can look something up in the manual or use help keys, and how to do so. The broader message is that Emacs is something you can ask Emacs about in other ways too - and they can be worth discovering.

It's not about doc, in the narrow sense. Emacs exposes itself more than just by way of its doc. It's about inspection or introspection. It's about the fact that pretty much every action you take with Emacs invokes a command - typically a Lisp function. It's about Lisp.

You ask, "Is it good way to start an answer with 'Ask Emacs'?" My answer is it can be. Sometimes that's the right help and the right message, beyond getting the immediate question answered.

And it's pretty much always part of the answer, at some level - part of the point about helping with Emacs in general, whether stated that way or not.

You start your question with "Emacs is, as everyone knows, self documented lisp environment with very good Info system built-in." No, everyone does not know that.

How long have you known it, for example? You didn't know it before you knew it, right? You might know all about Info now, and you might be annoyed to hear someone teach it (point it out), especially over and over. You can be annoyed, or you can just skip it and move on to an answer that is a better fit for you.

Can an answer here misjudge where the questioner is at, supposing too little or too much know-how about, or interest in, Emacs? Sure. Maybe it provides just the code for a command that is sought. Or maybe it says something about that code, to help a bit more. It depends on a guess about the asker, and maybe on how interesting the question is (and maybe on how much time the answerer has).

Some people will sometimes appreciate some such extra help. Some won't care. And some will sometimes be annoyed. (And an answer is not just for the person who asked the question.)

Teaching is repetitive, but learners don't usually repeat the same material over and over, and they generally don't get annoyed by things that are new to them. ;-) Here, all levels are mixed. What is old to one is new to another. If you see an answer that teaches you something you already know, consider moving along to one that teaches you something new...

6

I think it's a fine way to start an answer, as it helps users learn how to find answers to their own questions. I consider myself a novice Emacs user, and it certainly helps me to be shown how to find answers to my own questions in Emacs.

I do not think that "Ask Emacs" is an answer on its own, however. Drew's example is great because it starts with telling the user how to find the answer for themselves, then goes on to answer the question directly. As is typical for StackExchange sites, it's not sufficient to direct users to a place where the answers can be found. I do think it's good, especially for new users of Emacs, to be shown how to seek answers themselves in the future.

  • Yes Drew's answer is fine. And I agree with you that a good answer should include the way to find an answer by yourself. But it doesn't mean, IMHO, that it's a good way to start an answer. Changing the opening as meta.emacs.stackexchange.com/a/465/2055 or put "Ask Emacs" as a footer would be better for reader, don't you think? – Yasushi Shoji Jan 6 '17 at 1:56
  • 4
    Yasushi Shoji: I disagree -- I think Drew's answer is good the way it was written originally. I do not believe any user will be frustrated by reading an answer which helps them, and I believe that highlighting how to ask Emacs, by leading with that information, is of greater value to readers than relegating it to a footnote (where it may easily be ignored). If the user had already tried to ask Emacs, they have now learned a new way to do so. If they had not tried at all, it's even more valuable to show them. – phils Jan 17 '17 at 6:51
3

I think it is a good approach from a logical standpoint. I think different phrasing might change the tone while conveying the intent. My experience is that phrases like "you should" can evoke negative reactions in a reader and I sense that that might be behind this question. As an alternative, "Did you know that C-h i..." might come across as a bit softer -- it's less likely to be associated with other potentially emotional contexts.

To me, "Did you know" probably more accurately conveys the intent...which I take as a reminder that unlike much other software Emacs is self-documenting and doesn't necessarily require 'defaulting to Google'. Sometimes, I need a reminder to RTFM, but I'd probably prefer a gentle one and when I'm under pressure and stressed I'm less inclined to a charitable reading of "you should"...i.e. I'm inclined toward telling people what they should do with their "you should."

On the other hand, I often prefer statements of first person experience to provide a less wishy-washy phrasing and to preclude an interpretation that I am making an argument.

When I ask Emacs this question using C-h i, then choose the Elisp manual, then i defvar, Emacs takes me to the node Defining Variables.

There's nothing to grab onto an argue about (so long as the correct keystrokes are listed). It's just a little fable that shows how I RTFM with the moral that anyone can RTFM.

You must log in to answer this question.

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