Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

:A can't see alternate files #187

Open
j-xella opened this issue Jan 8, 2024 · 2 comments
Open

:A can't see alternate files #187

j-xella opened this issue Jan 8, 2024 · 2 comments

Comments

@j-xella
Copy link

j-xella commented Jan 8, 2024

It happens when I save nvim session and then reload it. I use NVIM v0.10.0-dev-2016+g5dc0bdfe9, the latest version of projectionist (commit a57b9bf) and have the following config:

"*.cc" : {
   "alternate" : [
      "{dirname|dirname}/include/{basename}.h",
      "{}.h"
   ]
},

After I restart nvim, load my session and am in file /path/to/src/Name.cc (pathes redacted), executing :A command, I get this prompt:

Create alternate file?
1 /path/to/include/Name.h
2 /path/to/src/Name.h
Type number and <Enter> or click with the mouse (q or empty cancels):

This is already a problem, because the file 1 actually exists. If I manually enter the command :e /path/to/include/Name.h, I can open and edit the header file without any problems. But if I select the option 1 from the above prompt, I am landed in a new (!!!) buffer that is empty but has the same file name as existing file. Reloading the new buffer (:e! or :e %) does not work - I am still in that empty buffer... Using :ls, I see that I have 2 buffers now with the same file path:

460 #a   /path/to/include/Name.h:1
12  %a=  /path/to/include/Name.h:274

The buffer with lower id is the real file that has been opened before. The buffer with higher id is the one created by projectionist instead of opening the real file.

@j-xella
Copy link
Author

j-xella commented Jan 8, 2024

Possibly related to #185 ?

@tpope
Copy link
Owner

tpope commented Jan 8, 2024

You've redacted a bit too much for me to tell what is going on, but that {dirname|dirname} is setting off alarm bells. I wouldn't be surprised if there's an edge case hiding in there.

But if I select the option 1 from the above prompt, I am landed in a new (!!!) buffer that is empty but has the same file name as existing file.

This is impossible; you're probably missing some difference between the two names. Presumably in the part you redacted.

Possibly related to #185 ?

#185 should be fixed by #187.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants