2

We have a few questions dealing with different aspects of the "behind-the-scenes" of emacs:

They all deal with different aspects of Emacs, but they all have that in common that they are asking about what is not presented to the user: compilation flags, source code organization or implementation of C built-ins.

This was already somewhat mentioned in this question: What should we do with the development tag?

However, I feel that our toolbox of tags is still insufficient. The first question of my list is tagged with , which is inappropriate, and would only be slightly better. I am going to suggest the creation of for this question.

But this tag (if accepted) will not host that many questions, and I think the questions above have really more in common than the 0 tags that they share (not that hard, eh? ^^).

Hence my suggestion/question: should we create a tag for this kind of questions, dealing with how emacs works behind the emacs-lisp?

Examples of topics belonging to that tag (including the ones above)

  • compilation flags
  • emacs source
  • C built-ins (not how to use them, but what's inside)
  • low-level dependencies
  • differences between emacs builds (e.g. emacsw32 vs cygwin emacs)

If so, I suggest the name , because (imo) it speaks both to the expert and the newcomer, and it is the name that the manual uses. And it is less prone to errors than e.g. would be.

Other suggestions could be , ...

3
  • 1
    emacs-core and emacs-source would be way too broad. Essentially anything that's not an external package is part of emacs-core (ido, dired, f90-mode). In fact, even GNU Elpa packages are part of GNU Emacs per se, so people would be entitled to think emacs-source includes them.
    – Malabarba
    Nov 20, 2014 at 9:40
  • That said, I do agree with this tag idea. Perhaps emacs-internals might be easier to find than internals.
    – Malabarba
    Nov 20, 2014 at 10:39
  • I don't have much of an opinion about the general question. Wrt emacs-compilation, I think maybe building-emacs would be a better term. It's slightly more general (can include platform, make, and build-script questions etc.), and it's generally the term used on emacs-devel@gnu.org. Compilation is a big part of building, but it's not all of it.
    – Drew
    Jan 12, 2019 at 2:53

1 Answer 1

Reset to default
2

Agreeing with Malabarba and posting as answer to allow for voting opinions:

  • used as the tag to ensure clarity
    • Set as a synonym if we end up having it used as well/instead
    • Not for built-in packages/ELPA
    • Not for How do I use YYY where YYY is in C-source (unless asking about implementation of.
  • used for any issues that relate to compiling Emacs
    • How do I compile Emacs on X
    • I get error ... when compiling, how do I fix/trace this issue
    • What are the differences in compilation using compile-flag XXX vs YYY
    • For questions relating to cd /path/to/emacs/src && make
    • Not for using Emacs to compile other languages
    • Not for telling Emacs to byte-compile.

would be a good tag for those dealing with implementation of Emacs. would be a good tag for those dealing with what results from compilation, or is needed for compilation.

There will likely be overlap between the two (and probably ),

6
  • Just for clarity, is your last paragraph aimed at questions like "I have error XXX when compiling emacs, what can I do?"? Do you include questions like the one about x toolkits in this category?
    – T. Verron
    Nov 20, 2014 at 14:13
  • For clarity (editing in): yes to both. Questions regarding errors compiling emacs, compile flags, how to compile on system X would fit under that.
    – Jonathan Leech-Pepin
    Nov 20, 2014 at 14:18
  • Hm. I do see your point, and the limit is much easier to place this way, to be fair, but I believe this limit will quickly lead to problems. For example, "what difference is there between compiling with library X or Y?" would be emacs-compilation. But then the more specific "is there a performance difference between function f defined using library X or Y?" would also be emacs-compilation... And then questions about the implementation or performances of a specific C function would be tagged differently, depending on how deeply they depend on external libraries (...)
    – T. Verron
    Nov 20, 2014 at 14:30
  • (...) But I agree that "there will probably be an overlap", no matter what definition we choose. If we agree that this implies that in overlap cases, either tag (or both) is valid, there isn't any real problem.
    – T. Verron
    Nov 20, 2014 at 14:31
  • 2
    I would say all (including development) could be valid in some cases. Tag it appropriately to show this overlap (since each also will have cases where the others do not) and it will be fine.
    – Jonathan Leech-Pepin
    Nov 20, 2014 at 14:47
  • 1
    Before this can be applied, we need an actual definition of what the emacs-internals tag actually applies to. Note that this answer only defines the tag in terms what it isn't. Furthermore, the question defined it mostly in terms of examples. Both are a start, but neither are enough. We need a wiki excerpt.
    – Malabarba
    Nov 21, 2014 at 0:20

You must log in to answer this question.

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