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

Difference with OpenBSD vi on handling filename completion #22

Open
krsanky opened this issue Aug 20, 2022 · 4 comments
Open

Difference with OpenBSD vi on handling filename completion #22

krsanky opened this issue Aug 20, 2022 · 4 comments
Assignees
Labels
bug Something isn't working help wanted Extra attention is needed
Milestone

Comments

@krsanky
Copy link

krsanky commented Aug 20, 2022

Hi!,
I'm using OpenVi on Mac. It's great!
One big difference between OpenVi and OpenBSD's vi is when I use filec= to expand filenames.
On OpenVi I have to keep typing in an '*' and then push tab if I want to expand what I have so far.
On OpenBSD vi it seems like the '*' is assumed. All I have to do i keep hitting tab as i type more specific
filenames, and it keeps matching.

Can you think of a way that I can not have to enter the '*' char to match all like in OpenBSD vi ?

@johnsonjh johnsonjh self-assigned this Aug 23, 2022
@johnsonjh
Copy link
Owner

johnsonjh commented Aug 24, 2022

Confirmed the behavior you noted, comparing OpenBSD 7.2-beta with OpenVi master.

I'll look into it and see what is happening. I'm totally not surprised that I broke this (the completion code is a bit hairy -- as you can see, almost all open issues are related to completion), but I'm not sure just how I broke it yet - sorry!

Traditional vi completion worked by calling the shell to do the expansion. This is probably the smartest thing to do - the expansion in vi will always follow the same rules as the users shell - a zsh user can use zsh globs like **/*(.), csh users can use whatever they use, etc. Because calling a new shell is an expensive operation, especially on a old VAX, nvi accelerated the most common completion case of '*' by handling it internally, avoiding the need to fork a shell.

I see if you disable the shell-based completion by setting shell="" in Nvi or OpenBSD's vi, the "default" internal tab completion still works as you expect it to, but not on OpenVi.

This seems to point towards having broken the internal completion in some way, as that is the one that's called in the default case.

It will be a bit before I'm able to investigate this further, but it's a bug for sure and I'll make a new release once it's fixed because it creates an annoying and unnecessary incompatibility between OpenVi and OpenBSD vi/nvi.

@johnsonjh johnsonjh added the bug Something isn't working label Aug 24, 2022
@krsanky
Copy link
Author

krsanky commented Aug 24, 2022

Thanks for investigating and the explanation :)
I can build from git if you get to the point you want anything tested.

PS.
my shell from OpenVi: shell="/opt/local/bin/oksh"
That's OpenBSD ksh from macports, which so far seems just like on ksh on OpenBSD.
It must get that from $SHELL (which is the same), because I didn't set it.

@johnsonjh
Copy link
Owner

Just checking in.

Yes, it will use your SHELL from the environment by default for the shell to call for completions. You can override this if you desire. (In the days of slow VAXen, it was somewhat more common to use a faster minimalist shell for providing completions and/or shelling out to execute commands from buffers, and using a more featured shell for interactive logins.)

I've not had a moment to look at this issue yet, but I'm hoping to do so before the OpenBSD 7.2 release, which will bump OpenVi to 7.2.x.

@johnsonjh
Copy link
Owner

Bumping again.

@johnsonjh johnsonjh added the help wanted Extra attention is needed label Nov 22, 2023
@johnsonjh johnsonjh added this to the 7.5 milestone Nov 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

2 participants