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

Complaints & Improvements
1

I just need to confirm if an issue that I opened with the 1:1 error no such buffer is invalid, especially after reading https://github.com/mawww/kakoune/issues/1441

Although my issue was originally by invoking edit! from kak source directory, and failing to switch back and forth between buffers after that, I am not quite sure what the current implementation of edit is either.

I would have assumed that an edit that would autocompletes a given file, it would therefore switch back and forth between whatever filename was autocompleted.

The above is possible under any kak under a path, but not aftermake ing compliing kak from source directory.

I just need to verify whether this issue that I opened and consequently closed, has stupid written all over or not. The stupid part is from opening an issue like this to start with.

I would have to agree with this comment but this is in conflict with the otherwise edit command which autocompletes the filenames.

e.g

 /apathsomewhere/./kak
 :edit ~/.config/kak/kakrc #autocompletes it
 :b *debug* 
 :b ~/.config/kak/kakrc #throws the error 1:1 no such buffer

is the above naturally expected?

All I can say, is that I have no idea what cd is supposed to do. If I agree with that comment then what is the need of having an edit that autocompletes a given filename?

So, under the current implemetation, cd takes precedence over switching buffers And while that is understandable, edit on the other hand edits, but that pretty much leaves buffer command ostracized among any other file that is not on the current directory.

So the original intention of even having buffer buffer-next buffer-previous is thrown out the door in favor of a cd that is behaving worse than the cd from the Posix programmer’s manual

If cd is supposed to take precedence, then a suggestion would be to change the error message to change directories or no buffer under current directory instead of no such buffer perhaps?

And if :b is supposed to behave as it does behave with other editors, then cd is the problem here, and thus the error.

This is a regression because rather than a cd a dired list as emacs currently uses by C-x d could have been used instead

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 Release v2019.01.20 ¡ mawww/kakoune ¡ GitHub

 :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 - #9 by nonumeros, 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