Skip to content

[RFC] allow external ui to draw wildmenu #6168

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

Closed
wants to merge 7 commits into from

Conversation

dzhou121
Copy link
Contributor

Part of PR #5686

@dzhou121 dzhou121 mentioned this pull request Feb 24, 2017
@marvim marvim added the RFC label Feb 24, 2017
for (i = 0; i < num_files; i++) {
ADD(args, STRING_OBJ(cstr_to_string((char *)files_found[i])));
}
ui_event("wildmenu", args);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wildmenu_show

elseif name == "wildmenu_hide" then
items = nil
end
end)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The wildmenu events may be best handled in screen.lua via functions Screen:_handle_wildmenu_select/Screen:_handle_wildmenu_hide etc as otherwise, any wildmenu events in other tests will make the test fail (as there will be no handler for the event).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There won't be any of these events if the test doens't attach with ext_wildmenu=ture just as other externalised items such as ext_tabline etc.

@bfredl
Copy link
Member

bfredl commented May 11, 2017

I wonder if we really want a separate ext_wildmenu flag or if it just should follow along with ext_cmdline. Are there a good reason an UI will externalize one and not the other?

@ZyX-I
Copy link
Contributor

ZyX-I commented May 11, 2017

Command-line is fine for me where it is now, but insert-completion-like popups or something like this would really be nicer for completion then wildmenu is.

@bfredl
Copy link
Member

bfredl commented May 11, 2017

but that problem is not nvim side for external ui? ui could draw wildmenu however, the same as popupmenu for instance.

Though I think it might be not to hard to use popupmnu.c in the TUI for wildmenu, if one doesn't mind a few extra redraws.

@ZyX-I
Copy link
Contributor

ZyX-I commented May 11, 2017

@bfredl I mean developer may want not take control over drawing cmdline because it is already fine as it is, but take control over wildmenu because it is not. If wildmenu was nicer I would agree that there is not much sense.

Though for command-line zsh does better when there are many choices then insert-mode popup. If selection would go in any direction (up, down, left, right) and used (highlighted) candidates appearing above the “statusline” (AFAIR this is being enabled by some option, but I do not remember which exactly) and “statusline” with completion entries did not exist at all it would be better in my opinion.

@bfredl
Copy link
Member

bfredl commented May 11, 2017

true, it is just my guess that most extended gui:s would use the external cmdline, if they consider wildmenu. I'm not completely against separate control, just trying to see to not to have too many options.

@dzhou121 dzhou121 force-pushed the external-wildmenu branch from e22bf00 to b6dc40c Compare June 26, 2017 14:32
@justinmk justinmk added the ui-extensibility UI extensibility, events, protocol, externalized UI label Jul 4, 2017
@justinmk justinmk added this to the 0.2.1 milestone Oct 27, 2017
@bfredl bfredl mentioned this pull request Oct 29, 2017
@justinmk justinmk closed this in b67f58b Oct 31, 2017
@justinmk justinmk removed the RFC label Oct 31, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ui-extensibility UI extensibility, events, protocol, externalized UI
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants