I was reading buffers.asciidoc
One particular scratch buffer, named *scratch*, is automatically created when there are no other buffers left in the current session. (which is also the case at Kakoune’s startup when no files to open have been provided)
A scratch buffer can be created by passing the -scratch
switch to the
:edit
command.
As Only create a default *scratch* when we dont have any non debug buffers · mawww/kakoune@5440d31 · GitHub specified it this is when any non debug buffers exists
But on my Arch Linux pre-packaged kak, invoking it, does not open the default **scratch** buffer.
I tried to follow some of the discussions regarding this issue, but I didn’t see anything that would be related
Bottom line is that my pre-packaged kak does not have a scratch buffer.
I’m wondering if my configuration or if other flags were passed during compilation of kak. But I guess if it’s the latter, the maintainer is obviously whom to ask in this case.
Build Date: 01-20-2019
Maintainer: Maxim Baz
There’s a difference between “the *scratch*
buffer” (the specific
buffer named *scratch*
) and “a scratch buffer” (any buffer that
happens to have the “scratch” flag set). The *scratch*
buffer is a
scratch buffer, but not every scratch buffer is the *scratch*
buffer.
If you run kak
with no arguments, or if you’re in Kakoune and you
execute the :delete-buffer
command enough times, you should wind up in
the *scratch*
buffer. In the bottom-right corner of the terminal,
the status line should say something like:
*scratch* 1:1 [scratch] 1 sel - client0@[1234]
…where *scratch*
is the name of the buffer, and [scratch]
is a
flag that shows up in the status line for every scratch buffer.
If you’re in Kakoune and you run a command like:
:edit -scratch foo
…then Kakoune will create a new scratch buffer named “foo”. The status
line should look like:
foo 1:1 [scratch] 1 sel - client0@[1234]
It still has the [scratch]
flag because it’s a scratch buffer, but the
name is foo
.
@Screwtapello thank you. I always go through your detailed answers. I do appreciate it.
I don’t know what system you’re running, but on Arch Linux, (not the derived distros), a pre-packaged Kakoune does not, unlike a compiled kakoune, open the notes buffer named **scratch** (as Emacs usually does).
Going by the documentation quote
*scratch*, is automatically
created when there are no other buffers left in the current
session. (which is also the case at Kakoune’s startup when no files to
open have been provided)
endquote
To be more exact, and normally you’d have something like
*** this is a *scratch* buffer which won't be automatically saved ***
*** use it for notes or open a file buffer with the :edit command ***
but not on the pre-packaged Kakoune
Correction: the scratch buffer and the flag are opened with the pre-packaged version, but not the warning (notes.)
Interesting, the compiled version showed - in addition to the warning (notes) of the buffer named scratch - the compilation of the gcc-libs that were used for the compilation.
e.g., Kakoune v2019-01-20-175-gcc
But the pre-packaged Kakoune only shows the date.
Perhaps some users prefer this ‘feature’ of not having the notes, but I’m certainly not among them. The notes serve as a warning, that the buffer itself won’t be automatically saved.
pre-packaged without notes
compiled with notes
I don’t know what system you’re running, but on Arch Linux, (not the derived distros), a pre-packaged Kakoune does not, unlike a compiled kakoune, opens the buffer named **scratch** (as Emacs usually does).
I think you’ll find it does, by looking at the status line in the bottom
right.
To be more exact, and normally you’d have something like
*** this is a *scratch* buffer which won't be automatically saved ***
*** use it for notes or open a file buffer with the :edit command ***
but not on the pre-packaged Kakoune
That message is newer than the most recent stable release of
Kakoune. In version 2019.01.20 (and all previous versions), the
automatically-created *scratch*
buffer is empty, with no message.
Thank you! @Screwtapello
With guys like you, no need for documentation
1 Like
Interesting, the compiled version showed - in addition to the warning (notes) of the buffer named scratch - the compilation of the gcc-libs that were used for the compilation.
e.g., Kakoune v2019-01-20-175-gcc
Actually, “gcc” there is a coincidence. Kakoune use the “git describe”
tool to generate a version number from repository metadata, which
produces a version string like:
v2019.01.20-175-gcc788c88
Which means that copy of Kakoune was built from commit cc788c88, 175
commits past the tag v2019.01.20 (I don’t know why git describe
puts a
“g” before the commit ID, but that’s what it does).
But the pre-packaged Kakoune only shows the date.
When describing a commit that has an exact tag, “git describe” only
names the tag.