22

It's been mentioned here before. This type of question is the most frequent one we get around here. Something is not behaving as it should, and the asker either gives us nothing or dumps their entire init file in the question. Some examples:

The duplicates facility is one of StackExchange's most important features, so I propose we use it.

  1. We need a general well-written question (herein, the motherthread) detailing this kind of issue and a couple of answers detailing ways to pintpoint the problem.
  2. When this type of question shows up, we mark it as a duplicate of the motherthread, and leave a comment asking the user to edit their question if those instructions are not enough for them.
  3. Once the user follows the instructions on the motherthread, if they're still confused they can edit their original question with details on what they found, and we'll gladly unmark it as a duplicate and give informed answers.

This post is meant to discuss the following:

  • Is there a high-voted question out there we can clean up for this purpose? Or should we make a new one?
  • What could be the content of this question?
  • What answers should we write on it?
    • The usual “Try emacs -Q then bisect your init file in the following way” should be one, of course, and there are already several samples of it in the questions linked above.
    • toggle-debug-on-error/warning should also have an answer there.
    • I've also been working (for the very purpose of using it on this site) on a package that performs the bisection automatically, assuming that the problem itself can be detected with elisp code.
  • There isn't a way to "pin" a question to always remain on top. Is there? – Kaushal Modi Mar 25 '15 at 15:57
  • 1
    @kaushalmodi No. But the more votes and the more duplicates a question gets, the more views it will receive, and it will be easier to find on google. I think we can also link to the question on one of our help pages. – Malabarba Mar 25 '15 at 15:59
  • Alternately, we could open it in Meta and ensure it keeps the Featured tag, like that it will show up on the side. – Jonathan Leech-Pepin Mar 25 '15 at 16:27
  • 3
    @JonathanLeech-Pepin The question should be on main, not meta, for many reasons: that's where it belongs, that's where people will look for it, that's where it must be to serve as a duplicate target, the featured tag wouldn't work (you can't feature all the questions, and anyway it expires after a month)... – Gilles Mar 25 '15 at 21:26
  • @Gilles Thank you. I had considered the issues with duplicating and where people would look, was mostly thinking in regards to how to keep it pinned and wasn't aware of the expiration time. – Jonathan Leech-Pepin Mar 26 '15 at 15:43
9

I would lean towards a new Community Wiki question specifically dedicated to this sort of troubleshooting (and possibly there will be other similar questions worth doing so for). This will ensure that the question is clearly focused on troubleshooting init-file issues. We can always provide links within the question to other specific questions where this occurred.

  • Set the question as more of an announcement/explanation. This would be akin to the announcement meta posts regarding new features.

    • Provide a summary of what symptoms/error mights come up (package/feature not working, keybindings no longer working, error on init, unexpected behaviour)

    • Provide a quick template of basic troubleshooting to perform/to include in any questions related to this (i.e)

      1. Steps to reproduce the error

        The following should hopefully provide backtraces if there are errors and not just undesired behaviour.

        1. emacs --debug-on-init :: if error on init
        2. toggle-debug-on-warning/error :: if errors and warnings are popping up
      2. Can it be reproduced with emacs -q :: If error occurs in emacs -q, file a bug report with upstream (m-x report-emacs-bug, open issue on Github, etc)
      3. Narrow down configuration to the minimal elements involved. Ideally rename your init-file and then create a new init-file that only includes the elements below.
        1. If issue is with a package/feature, test the variables/custom functions for that package/feature.
        2. If none of the immediately related configuration causes the issue, look at any (other) minor-modes that would be in effect
        3. If minor modes are not the cause, look for any setq,hook,defalias that would be in effect across multiple buffers.

Then the content for the question:

  • How to reproduce: Explain how to cause the error
  • Can it be reproduced with emacs -q:
    • If yes: has a bug-report been submitted (Emacs.SE may be able to lead to a bug-fix)
  • Backtrace (if available)

<!-- language:lang-lisp -->

(error backtrace here)

  • Minimal configuration required to reproduce:

<!-- language:lang-lisp -->

(this is my config
  (that continues here))

Answers could then include:

  • (More) Detailed examples of the steps above such as actual/contrived examples
  • Additional packages/tips on how to identify the error (edebug, bug-hunter, which toggle-debug-on-* can be useful in which context).
  • How to change warning level so that warn and lwarn (if used) will be more verbose.
  • Eventually at least a minimal list of of common variables/functions that are not set/are set that have (unexpected) consequences. As a non-Emacs example, installing msys-git on Windows allows you to add all the executables to path, but warns that doing so will shadow certain built-in functions, potentially causing issues.
  • Similarly to above, a list of common variables/functions to provide features that might have been overlooked (focused on non-package-specific variables). For example those relating to coding-system.
1

On the TeX Stack Exchange site, there is a culture that all-but-requires "Minimum Working Examples" to accompany questions on the site. That goes for features, as well as bugs.

What makes a good MWE?

'A good minimal example is one which shows that someone really used his/her brain and invested some time and effort to make a clear and concise question.'

'A good MWE is some compilable, "to-the-point" code that clearly isolates the problem and contains no superfluous clutter and only a limited amount of jargon from the particular area.'

Many of the same kinds of reproduction steps that Jonathan Leech-Pepin put in his answer here would apply to "positive" examples, not just bugs. Here's one example of a question that I think could benefit from being reformulated in this way:

And here's one answer that I phrased as a MWE:

But I think the same idea applies to most questions.

  • Definitely. Any MWE/ECM (example complet minime) that can be generated for a question will help answer it. On the other hand, being able to generalize the question can lead to the example being applicable in other cases (concept vs implementation). Bugs and feature implementation are probably the best use-cases for this (as opposed to asking if a feature exists). – Jonathan Leech-Pepin Sep 4 '15 at 19:25

You must log in to answer this question.

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