4

For example, *scratch*, *Messages*.

Is this some kind of convention?
If so, what does it mean?

shynur
  • 4,065
  • 1
  • 3
  • 23

1 Answers1

2

It’s just a convention. The purpose of this convention is to make it easy to distinguish buffers which content was created or generated by eLisp from buffers representing content of files.

Claudio
  • 410
  • 2
  • 11
db48x
  • 15,741
  • 1
  • 19
  • 23
  • 3
    Or buffers that are not associated with files such as `*scratch*`. There are also buffer names that start with space. Those are normally not shown in buffer lists. – Tobias May 10 '23 at 05:49
  • 2
    It would be better if you could provide the corresponding references to the manual. – shynur May 10 '23 at 05:52
  • In principle I agree with you, but in practice there might not be anything to refer to. A quick glance through the Emacs manual finds a paragrah in chapter 19.1 that recommends not creating buffers whose name starts with a space, but nothing about the asterisks. Although plenty of chapters mention commands that open “a buffer named \*…\*”; anyone who reads a few of those will get the idea pretty quickly. – db48x May 10 '23 at 06:43
  • Same with the Emacs Lisp manual. “It seems you shall have to continue your search; they can hide well enough to escape my mere glance.” – db48x May 10 '23 at 06:50
  • 1
    They are not necessarily generated from buffers that are visiting files (e.g. `*scratch*` and `*Messages*` are not). They are "special" buffers of any kind: session buffers for inferior command processors are commonly named like this, log buffers and command output buffers are too, help and Info buffers, package listings, buffer listings, tramp work buffers etc, etc. Basically, any time that some package needs a buffer for a scratch pad/logging/comand output, it is likely to use this convention. – NickD May 10 '23 at 16:41
  • 1
    [EmacsWiki](https://www.emacswiki.org/emacs/Buffer) also states "By convention, buffers whose names start with an asterisk (\*) are not associated with files. ", but I couldn't find *official blessing* for that statement in the manuals / mailing lists. – Y. E. May 11 '23 at 12:25
  • 1
    @NickD, I think you might have misparsed my statement :) – db48x May 12 '23 at 02:09
  • Yeah, I did :-) Sorry about that: may I suggest you invert the order? – NickD May 12 '23 at 02:31
  • I could add parentheses… – db48x May 12 '23 at 03:33