Is the error 1:1 no such buffer message an invalid issue?

Complaints & Improvements
2

Kakoune expands paths, so buffer would be named with absolute path.

oops, it’s not. It’s tab completion what does expanding. Never mind then.

3

I’m using Kakoune v2019.01.20-244-g0cc89b2b, not the latest, but hopefully not too old.

If I start kak -n from my home directory, I can type:

:e ~/.config/kak/kakrc
:b *debug*
:b ~/.config/kak/kakrc

…and it switches to the debug buffer and back to the original buffer with no errors. However, in the buffer in question:

  • %val{bufname} is .dotfiles/.config/kak/kakrc (since I keep my dotfiles in a git repo and ~/.config/kak is a symlink to ~/.dotfiles/.config/kak)
  • %val{buffile} is/home/st/.dotfiles/kak/kakrc(the actual path with~` expanded)

Neither of those matches the text I’m typing, so I assume :buffer tries to expand and canonise its argument to see if it matches any buffer’s %val{buffile} as well as exactly matching %val{bufname}.

Also note that the above is entirely without tab-completion. If I type :edit ~/.config/kak/kakrc and then hit <tab>, the command-line is amended to show yet another path, /home/st/.config/kak/kakrc (~ expanded, but path not canonised). The resulting buffer still has %val{bufname} and %val{buffile} as above, though.

It might be possible that there’s some kind of path canonisation that’s done for :edit and isn’t done for :buffer that’s confusing things. Also, if you’re asking Kakoune to connect to a server that was launched from a different working directly you might encounter surprises. However, I’d be very surprised if "whether kak is on $PATH" is relevant, and I don’t understand how cd is relevant, since the reproduction instructions you give don’t mention cd at all.

4

It’s tab completion what does expanding.

thank goodnes for that if that’s the case.

this is with 31149558 but the same is replicated under https://github.com/mawww/kakoune/releases/tag/v2019.01.20

 :b *debug* 
 :e! ~/.config/kak/kakrc 
 :e! ~/Documents/atest.txt
 :b ~/.config/kak/kakrc #everything good
 :b atest.txt #everything good too

as soon as :cd somepath is invoked, then the problem starts
and it’d throw the error. Of course, the files - if any that -
happen to be under the same directory, are not affected. So from the above example, if cd Documents is invoked, the file atest.txt can be switched back to and from respectively.

All of this is also with the -n option by the way.

5

It might be possible that there’s some kind of path canonisation

:smiley: could you explain that further?

When I typed path canonisation on google it returned:

Path to Sainthood

“Saint” (“Sanctus” or “Sancta”; abbreviated “St.” or “S.”): To be canonized as a saint, ordinarily at least two miracles must have been performed

but if I were to say
echo $PATH

it returns the path under which both of my kaks are under

  echo $PATH
  /usr/local/bin:/usr/bin
6

Here’s what happens for me:

$ kak -n
:e ~/Documents/atest.txt
:b *debug*
:b ~/Documents/atest.txt

All this works fine. The resulting buffer has:

  • %val{bufname} as Documents/atest.txt
  • %val{buffile} as /home/st/Documents/atest.txt

As might be expected, the completion menu for the :b command suggests Documents/atest.txt (the bufname) rather than the full path.

If I then run :cd Documents:

  • :b ~/Documents/atest.txt still works fine
  • :b Documents/atest.txt complains “no such buffer”
  • The :b completion menu now suggests the name atest.txt
  • %val{bufname} has now changed to atest.

So I guess if you’re in the habit of using :cd then using :<up> to pick a buffer-switching command from history, especially one you used tab-completion to write in the first place, you’re likely to encounter this error.

The concept I meant is sometimes called “canonicalization”, but I suddenly wondered if that were an overly-complex version of a simpler word (an extreme example might be “canonicalitudinalismification”).

7

(an extreme example might be “canonicalitudinalismification”).

that alone puts any tongue twister (trabalenguas) to shame

So I guess if you’re in the habit of using :cd then using :<up> to pick a buffer-switching command from history, especially one you used tab-completion to write in the first place, you’re likely to encounter this error.

Thanks

Now the question that stands in my end, and out of all the kaks I may have been running or I may have compiled and invoked the executable…

Why. why then only the desktop.file works see Menu entry after installation, as opposed to the rest

Specifically the one with the

 Exec=uxterm /usr/local/bin/kak
 Path=
 Terminal=false

And no, none of these options for the Desktop Entry Specifications is specified thereafter

I lost count of the modifications to bash configuration file. Nothing seemed to work.

Only the kak desktop.file worked for this current issue.

edit I noticed it first between say a file such as ~/.config/kak/kakrc and the debug buffer. Error 1:1 no such buffer

Then, a make install would take care of it, or so I thought. But I was wrong again!!

on the terminal

 $which kak
 $/usr/local/bin/kak

If I invoke kak from the terminal and edit! ~/.config/kak/kakrc and then try to switch back to that file after cd onto another directory the error would come back. 1:1 'b' no such buffer '~.config/kak/kakrc'

but with the desktop.file I don’t encounter this error.

Is the Makefile correct?

And you might tell me, ‘that’s just wild a guess’. but I’m almost certain that that’s where the problem lies.

Because kak needs a XDG_CONFIG_HOME to breathe, correct? or if not it will fallback to $HOME/.config/kak

Then, if I were to put kak the executable on my personal bin (whatever this bin might be) is supposed to work under this current issue, but it doesn’t. So the only thing left is the Makefile by which make makes it.

edit

Furthermore, I’ve always compiled it as such

  g++ -rdynamic -O3 -pedantic -std=c++17 -g -Wall -Wextra - 
  Wno-unused-      parameter - Wno-sign-compare -Wno-address
  ln -sf kak.opt kak

Except the last one from sources

   g++ -rdynamic -pedantic -std=gnu++14 -g -Wall -Wextra - 
   Wno-unused-parameter -   Wnoeorder -Wno-sign-compare - 
   Wno-address -Wno-noexcept-type -Wno-unknown-       
   attributesWno-unknown-warning-option
   ...
   ln -sf kak.debug kak

Regardless, in both cases, the error is still there.
Only the desktop.file apparently works as intended.

8

What does :echo %sh{ echo $HOME } outputs in both cases ? is that the same ?

regarding the kakoune binary path, support files (rc/ scripts, system-wide kakrc that takes care of loading user config, colorschemes…) are located relative to it. Kakoune looks up what /proc/self/exe points to, and looks for its support file at …/share/kak relative to that.

9

What does :echo %sh{ echo $HOME } outputs in both cases ? is that the same ?

Yes, the same, both the destkop.file and by invoking /usr/local/bin/kak from the terminal … both return the /home directory

are located relative to it.

right right. And in the case of uxterm, I hadn’t noticed that the colors directory was not being found because I wasn’t even thinking of such trivialities or thinking about loading another colorscheme

And also because uxterm is not so color-friendly as the rest.

But in another desktop.file with the following settings:

 Exec=kak
 Path=
 Terminal=true
 StartupNotify=false

If I were to :b *debug* and then as soon as I type a space right after colorscheme, the following error appears

  *** This is the debug buffer, where debug info will be 
  written ***
 shell stderr: <<<
 find: ‘/home/c/.config/kak/colors’: No such file or directory
 >>>

So yes, it’s obvious and as soon as I move the colors directory back (let me scratch that part because that dir was never there) into XDG_CONFIG_HOME everything is good from there.

But is the other issue which I’m still struggling with, meaning that whatever desktop.file settings are, the 1:1 Error no such buffer is nowhere to be seen.

But If I were to invoke kak from the terminal directly, the error comes back.

In light of this recent colors dir issue with the xfce4-terminal I also copied rc and even autoload to .config/kak to see if there was no error, but I was wrong.

edit

Also, the reason why I mentioned earlier that I would have expected after copying the executable kak onto another bin directory, to have it working without an issue, is simply because my old nemesis hugo is there. I would’ve known by now.

second edit

also, I thought a make install would supersede the prior one but I invoke from the terminal

 $which kak
 $/usr/local/bin/kak

But this is my latest installation

 ln -sf kak.opt kak
 gzip -n -9 -f -k ../doc/kak.1
 install -d /usr/local/sbin/bin \
         /usr/local/sbin/share/kak/rc \
         /usr/local/sbin/share/kak/colors \
         /usr/local/sbin/share/kak/doc \
         /usr/local/sbin/share/doc/kak \
         /usr/local/sbin/share/man/man1
 install -m 0755 kak /usr/local/sbin/bin
 install -m 0644 ../share/kak/kakrc /usr/local/sbin/share/kak
 install -m 0644 ../doc/pages/*.asciidoc /usr/local/sbin/share/kak/doc
 cp -r ../rc/* /usr/local/sbin/share/kak/rc
 find /usr/local/sbin/share/kak/rc -type f -exec chmod 0644 {} +
 [ -e /usr/local/sbin/share/kak/autoload ] || ln -s rc /usr/local/sbin/share/kak/autoload
 install -m 0644 ../colors/* /usr/local/sbin/share/kak/colors
 install -m 0644 ../README.asciidoc /usr/local/sbin/share/doc/kak
 install -m 0644 ../doc/kak.1.gz /usr/local/sbin/share/man/man1

And yes, echo $PATH shows /usr/local/sbin/bin and also /usr/local/sbin

10

@Screwtapello @andreyorst @mawww

I don’t know if you guys have ever followed it, but As silly as it may sound this issue reminds me of one of those Star Trek episodes.

Me: ‘Computer, I gave you specific instructions to implement desktop.file on installation.’

Computer: ‘Instructions were deployed. Desktop.file functioning’

Me: ‘Computer!! discard Desktop.file instructions’

Computer: ‘Desktop.file instructions discarded. Error 1:1 no such buffer’

Me: ‘Sigh’

image3775

Postscript
after losing count of the modifications to bash initialization file, I started the initialization from scratch. No more errors. Problem solved

11

@Screwtapello @andreyorst @mawww

guys guys I dare you to

  export HOME=/home/username/

:smiley:

on your bash configuration file

make sure the path separator is after your username though

If you were to ask me: ‘why did you have it as such?’

because I’d be working on say some/dir/somewhere and I always found it convenient to say $HOME

i’m laughing now, but it did drained my energy because of the inconsistency with the desktop.file. It threw me off.

12

why not just call cd without any arguments? It will change directory to your home dir.

13

why not just call cd without any arguments? It will change directory to your home dir.

the same as ~ if you think about it, but I wanted to see my username

And I also have

 shopt -s direxpand
 shopt -s autocd

on bashrc but also a list of directories

@andreyorst if you were to type env your HOME should be there right?

14

I don’t get it, if I enter ~ it will error:

$ ~
bash: /home/username: Is a directory

The same with typing $HOME:

$ $HOME
bash: /home/username: Is a directory

What’s the Idea behind this again?

Maybe you’re using zsh or some bash plugin?

15

looks like I got what you mean, exporting HOME changes prompt. What it has to do with your bug?

16

Let me give you an example

say you call env and the list is there, I do remember you mentioned once you’re an Arch user, so your results should be similar than mine. I don’t expect it to be the same.

what does PWD shows for you?

that’s the current working directory you may have been working on and not the home working directory

17

I tried:

$ HOME=$HOME/ kak -n
:e ~/Documents/atest.txt
:b *debug*
:b ~/Documents/atest.txt

…and it worked properly. I know $HOME was mis-set as intended, because I saw the extra slash in the completions for the :e command. Next I tried:

:cd Documents
:b *debug*
:b ~/Documents/atest.txt

…and it still worked properly. So, I’m still confused and I don’t know what’s going on.

18

…and it worked properly. I know $HOME was mis-set as intended, because I saw the extra slash in the completions for the :e command. Next I tried:

thank you for that @Screwtapello … I didn’t even pay attention because I was trying to touch all bases in my reply to @mawww

The reason why I delved further into this is like with anything , I didn’t like the fact that the desktop.file was behaving as it should have been, and yet, and yet I was unable to call kak reliably from the terminal.

The desktop.file always, and I mean always worked - regardless of the settings but invoking the terminal would always give back 1:1 no such buffer

and yes, @mawww suspicions were right on about the home directory. It would still show the same output, the same output on the destkop.file and from the terminal

  :echo %sh{ echo $HOME }

both returned the same

edit

The destkop.file never had a problem with it. Not once.

It didn’t matter, whether it was

  Exec=kak
  Terminal=true

or

 Exec=uxterm /usr/bin/kak
 Terminal=false
19

…and it still worked properly.

And if you add another forward slash to HOME=$HOME// kak -n everything is working properly?

In other words, is only one of the two, but not both, so something gottta give

If it’s working let me know, so I will throw away this computer and the system behind it.

20

shell ignores additional slashes

mkdir -p a/b/c; cd a/////b/////////c////////////////

works in dash. I think Kakoune should handle this the same way

21

the problem with Kak is that it doesn’t even know what directory is on

What is ~ by the way? I don’t want to sound senile like a cranky old man, but what is ~ really?

So if any testing is goiing to be done, I’d like to know what is the rationale behind it?

for example,

what is before $ when calling the terminal ? If is ~ is wrong

If it’s the username is correct

End of the story, as simple as that

~ is tilde but what is it exactly? It doesn’t mean nothing! whereas a username for the system does