Closed AuLaSW closed 2 years ago
Yeah, it seems that telekasten has some issues with windows paths, as already mentioned in https://github.com/renerocksai/telekasten.nvim/issues/60
Now that I think of it, why do you home directory that is ~/zettelkasten
if you are on windows? Isn't there a problem with that?
I've had it set up both ways and still get the same results (if you're looking at my init.vim on GitHub, it's not up to date at the moment. I forgot to push last night and will have to wait until tonight to update it). I thought that may have been the issue, too, but it doesn't appear to be.
By both ways I mean I've put in the full path to the folder in my computer C:\Users\...\zettelkasten
and the issue still persists. What I have noticed is that I tried both an uppercase and lowecase "c" in the path and the file that the plugin produces matches either the uppercase or lowercase "c" that I chose.
Maybe it is the colon in Windows's paths that's giving it an issue?
Does everything work as expected if you use Telescope itself and not telekasten? Like in project repo or something? Maybe this issues comes from Telescope and not Telekasten.
I use Telescope often to open files (I use neovim for notetaking in my classes and frequently have to find and open files from it) and haven't had this issue before.
I just wanted to say that I was able to fix the problem: When I removed "C:" from the file path for home, everything worked well. It must be something with that.
I used: /Users/.../zettelkasten
instead of C:\Users\...\zettelkasten
. Now everything works regardless of the directory I'm in. I'm not sure what may need to change in the source code for that to work (I'm not very familiar with lua), but that may help with file paths working on Windows.
That's an interesting observation. Thanks!
I am not sure how this behaves if you have multiple drives (C:, D:, ...) - but great that it works for you!
Windows. Argh. I hate it. I don't have easy access to a Windows box at the moment so I cannot test things. I also didn't go out of my way to specifically support Windows in this plugin. While /
path separators usually work on Windows, things can get messy here and there. Especially, the C:
drive letter prefix is bound to cause troubles if not accounted for.
I strongly recommend NOT using Windows whenever you can - at least for nvim stuffs. If you are Administrator, check out WSL2 - that is supposed to give you the closest you can get to a Linux environment.
I strongly recommend NOT using Windows whenever you can
:joy: :joy:
What surprises me is: If Telescope is able to show you a file list and even produce previews, why can it not open the picked files? And why only in telekasten? I don't even override the "default_action" in find_files_sorted()
- which is used in this case.
edit: mayyyybe because the "normal" telescope file picker transforms paths on windows to a sane format - which my custom picker does not do. That's something worth investigating (there's a limit to my time though)
@AuLaSW , just to be sure, could you verify if the same behavior happens with dailies, weeklies and images search (when using a path like C:\user\...
) ?
@renerocksai , many times, we check if a file exsits with the following (for instance with dailies):
local fname = M.Cfg.dailies .. "/" .. today .. M.Cfg.extension
local fexists = file_exists(fname)
If M.Cfg.dailies
is in windows style, it will result in a mixed filename. Therefore if fexists
may return false and it will try to create a new note. Could that be the issue?
Although sometimes fexists
is evaluated using Path
. I am not knowledgable enough with Path
to know what it returns.
What I see in Telescope is that it splits the filename by :
to extract line number and column information, if present. I can only guess, this is where the observed behavior, creating a C
file comes from.
(edit: source: lua/telescope/actions/set.lua:116)
This might not happen when using Telescope in other situations, since those situations usually never require a user to configure a path - so nobody gets tempted to enter C:\
. It would be interesting what the paths Telescope works with on Windows look like. Probably \Users\.....
. (edit: no, it would more likely be /Users/...
)
So if my deduction is correct, @AuLaSW's workaround is actually the fix!
I also see that this does not happen if we provide a path
or filename
component to the entries we pass to the picker. So, there might be a fix for C:\
. However, I cannot guarantee that such paths won't screw up anything else.
How does Telescope work if we are in D:\
then ?
Ask a windows user :smile:
I bet it works like this:
In your shell you enter D:<enter>
to get onto the D drive.
(edit: Now you start nvim)
From here, paths starting with \
will reference the D drive.
What would be more interesting, is: will situations work where we start on the D drive and search on the C drive (some plugin)?
Telescope makes use of opts.cwd
a lot. Maybe that's their fix for mixing drive letters between use cases.
Specifying the cwd
might actually be necessary for Telekasten, too. If we follow a link, we don't specify a CWD since it could be any of the home
, daily
, ... If those would reside on different drives, it would most definitely not work.
So I am a bit wary of just smashing a opts.cwd = M.Cfg.home
in there.
So, the change I just pushed should stop Telescope from cutting off the filename after the colon. @AuLaSW can you check if that makes Telekasten work with C:\...
paths now?
AND:
To finally test if Telescope really supports C:\
paths, can you try to pick a file via:
lua require('telescope.builtin').find_files( { cwd = "C:\\" } )
So that it doesn't get lost: Windows users should configure paths in the following notation: /Users/username/zettelkasten
. This is likely to come with the caveat that nvim is only able to resolve that path if it's started from the same drive as the path in question.
We sould probably put that in the README.
I will close this for now as the workaround / solution seems to be the most compatible way anyway.
Using ~/
on Windows: ~
gets replaced by some C:\\....
path - which leads to a multitude of problems. One of them is the colon after the drive letter which telescope mistakes as separator for the line number of a search match, marking the end of the file name / path. Hence the file C
gets created in the current directory. It is a relative path after all. While I have pushed a change that circumvents this behavior, I am certain, paths with drive letters, colons, and backslashes are just bound to cause problems further down the road.
Using C:\Users\...
on Windows: I have no idea how that even got parsed since \
need to be escaped (\\
) in lua. print("C:\Users")
gives me a syntax error.
@renerocksai you are correct, it does need to be escaped by \\
(I had mistyped, my apologies).
Thank you for the wonderful discussion, I've learned a lot about how this works. I'm guessing I live in a very different time zone than you two, lol.
On another note, I've brought my laptop with me to work today and will be trying out some of the suggestions you have mentioned, @renerocksai and @lambtho12. I'll get back with you and let you know how they work.
I commented out the CleanPath function, and couldn't repro the original issue. Is it possible to let @AuLaSW test again without the tentative fix? I wonder if it was a temp glitch.
Please confirm
Describe the bug When I attempt to open a note while in a directory that isn't
~/zettelkasten
using one of the commands from the panel, it will create a new file in my current working directory named "c".To Reproduce Steps to reproduce the behavior:
<leader>zf
or<leader>zg
are what I first used to replicate the problem)Expected behavior I expected the file that I selected in my zettelkasten to open.
Screenshots I am on my phone at work at the moment, but when I get home I will add screenshots of what it is doing
Operating system (please complete the following information):
Additional context This problem occurs even if I use an init.vim with only the plugins required for this one (the minimum init file you can create and still have this plugin work). Again, at work so I'll post it here when I get the chance tonight.