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.
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/kakis 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.
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.
It might be possible that there’s some kind of path canonisation
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
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}asDocuments/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.txtstill works fine:b Documents/atest.txtcomplains “no such buffer”- The
:bcompletion menu now suggests the nameatest.txt %val{bufname}has now changed toatest.
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”).
(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
:cdthen 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.
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.
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
@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’
Postscript
after losing count of the modifications to bash initialization file, I started the initialization from scratch. No more errors. Problem solved
@Screwtapello @andreyorst @mawww
guys guys I dare you to
export HOME=/home/username/
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.
why not just call cd without any arguments? It will change directory to your home dir.
why not just call
cdwithout 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?
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?
looks like I got what you mean, exporting HOME changes prompt. What it has to do with your bug?
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
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.
…and it worked properly. I know
$HOMEwas mis-set as intended, because I saw the extra slash in the completions for the:ecommand. 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
…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.
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
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