Improve CLI usage errors to hint about nvim vs. gnvim flags

[dbarnett]

vim and neovim support a few flags for opening multiple files, -d for opening in side-by-side diff mode, -o/-O for opening multiple windows stacked vertically/horizontally, -p to open in multiple tabs, etc. gnvim supports opening splits and diffs from within nvim after starting it, but doesn't support those multiple-file options. If I try to pass flags like that when launching gnvim, I get errors like error: Found argument '-d' which wasn't expected, or isn't valid in this context.

Is it intentional not to support those flags, or could they be added?

[smolck]

GNvim does support those commands; you just have to pass them to nvim directly using $ gnvim -- -<nvim option>. Try running those commands like this:

$ gnvim -- -d <file1> <file2>
$ gnvim -- -o <file1> <file2>

The double dash is used to pass args to nvim; run gnvim --help for more info.

[dbarnett]

Thanks, that does what I wanted!

I see now the subtle hint about how args are handled in the usage line gnvim [FLAGS] [OPTIONS] [FILES]... [-- <ARGS>...]. FWIW I would have figured it out on my own if the error a little more self-explanatory, like

$ gnvim -d file1 file2 
error: Found argument '-d' which wasn't expected, or isn't valid in this context.
If this is an argument for nvim, try moving it after a -- separator.

USAGE:
    gnvim [GNVIM_FLAGS] [OPTIONS] [FILES]... [-- <NVIM_ARGS>...]

For more information try --help

[smolck]

FWIW I would have figured it out on my own if the error a little more self-explanatory, like . . .

Thanks for the info, I'll get a PR for this according to your suggestion when I get the chance, hopefully later today (unless someone else does it first; it is a small change, so that's cool too).

[dbarnett]

Sure thing, thanks!

And BTW one reason I've been going out of my way to report minor issues is I'm interested in eventually getting comfortable with Rust and contributing, so I'm poking around for things that bug me that I could solve. Hope it's not a nuisance. So far I'm somewhat interested in #70 which I'm running into on my Pixelbook, and possibly scrollbars and multigrid (#25). I'd also love to get some fancy navigation features like GUI menus, a minimap, or marking placed signs directly on the scrollbar, but I'm getting the impression that gnvim specifically strives to not get fancy and might discourage adding those kinds of features.

[smolck]

And BTW one reason I've been going out of my way to report minor issues is I'm interested in eventually getting comfortable with Rust and contributing, so I'm poking around for things that bug me that I could solve. Hope it's not a nuisance.

Thank you! Your helping to improve GNvim, which is certainly not a nuisance. The fix for this issue here may be a bit more involved than I figured at the first, but if you want to take a stab at it then please do! This project welcomes contributors, so any help is greatly appreciated! (If you have any questions let us know, either here on Github or on GNvim's gitter.)

I'd also love to get some fancy navigation features like GUI menus, a minimap, or marking placed signs directly on the scrollbar, but I'm getting the impression that gnvim specifically strives to not get fancy and might discourage adding those kinds of features.

GNvim, from my perspective, strives to enhance Neovim in a way that isn't possible with a terminal; therefore, things that contribute to that objective (scrollbars, minimaps, GUI file browser, etc.) will likely not be discouraged, so long as they keep the Vim-centric feeling (i.e. everything should be keyboard navigable and such). See #75 (comment) for my feelings concerning this (see the whole thread if you want more info). At the end of the day, our goal (AFAIK, being a contributor and not the author of the project) is not to make an IDE, but a GUI frontend for Neovim that improves upon the (Neo)Vim experience.

Note that the features you mentioned are welcome AFAIK, but GNvim really needs multigrid support before we get into adding more GUI enhancements like what you mentioned.

[badosu]

And BTW one reason I've been going out of my way to report minor issues is I'm interested in eventually getting comfortable with Rust and contributing, so I'm poking around for things that bug me that I could solve.

Happy to hear that! When I started submitting a few patches I did not know anything about Rust and I started picking up as I went.

If you want to try and play with it (it would be a good first issue), this is the relevant section:

gnvim/src/main.rs

Lines 89 to 111 in 68e3fc8

	let mut cmd = Command::new(&opts.nvim_path);
	cmd.arg("--embed")
	.arg("--cmd")
	.arg("let g:gnvim=1")
	.arg("--cmd")
	.arg("set termguicolors")
	.arg("--cmd")
	.arg(format!("let &rtp.=',{}'", opts.gnvim_rtp));
	// Pass arguments from cli to nvim.
	for arg in opts.nvim_args.iter() {
	cmd.arg(arg);
	}
	// Open files "normally" through nvim.
	for file in opts.open_files.iter() {
	cmd.arg(file);
	}
	// Print the nvim cmd which is executed if asked.
	if opts.print_nvim_cmd {
	println!("nvim cmd: {:?}", cmd);
	}

https://github.com/badosu/gnvim/blob/06f1d9b00c29e0f301df5b9b30d42a4d31e2dc77/src/main.rs#L67-L69

Notice the comments on top of the arguments are used to serialize the message.

[smolck]

@badosu I’m not sure this is as straightforward as it may seem. AFAIK the error message when a bad argument is passed via CLI isn’t configurable via structopt procedural macros, which makes fixing this issue more involved (unless I’m missing something).

@dbarnett Would you mind updating this issue’s title to Improve CLI Errors or something like that so it more accurately describes the issue we’re discussing here?

[dbarnett]

@smolck Title LGTY?

Make sure to cross-link the structopt issue if you file one. I did find one about "Access to usage for custom error messages" but it looks like it's about programmatically inspecting the usage, not programmatically customizing it.

[smolck]

@smolck Title LGTY?

Yup, thanks!

Make sure to cross-link the structopt issue if you file one. I did find one about "Access to usage for custom error messages" but it looks like it's about programmatically inspecting the usage, not programmatically customizing it.

Will do. Such a feature in structopt would make this fix a whole lot simpler, and I’d be willing to [help] implement the feature over there if needed so we can use it sooner. I should be able to open and cross-link the issue later today (assuming I get the chance). In the meantime, while the feature is being implemented (if they decide they want it), feel free to tinker around with an alternative. There may be a workaround, although adding customizable error messages to structopt is probably the path with the least “hacky-ness.”

[vhakulinen]

I'd also love to get some fancy navigation features like GUI menus, a minimap, or marking placed signs directly on the scrollbar, but I'm getting the impression that gnvim specifically strives to not get fancy and might discourage adding those kinds of features.

I definitely want to have fancy GUI features, but in a way that it they stay true to nvim[1]. Multigrid is already in progress in #95, which is semi requirement for scroll bars. Marking sings directly to the scroll bar shouldn't be too big of a thing, since afaik you can get required information for that from nvim without needing any special APIs.

And BTW one reason I've been going out of my way to report minor issues is I'm interested in eventually getting comfortable with Rust and contributing...

Please, go for it! Any help is appreciated. I think nobody is working on #70, so that should be good starting point if you want to fix a bigger problem. Also this issue is good place to start.

1: currently a notable exception to this is the cursor tooltip, since its completely custom and nvim it self doesn't provide anything for it. This might be replaced in favor of floating windows in future, so gnvim stays closer to nvim.

[smolck]

No need for a structopt issue to fix this, turns out custom error messages are already a feature. See here and here. Will get a PR for it shortly.

Basically, involves something like this:

let opts = Options::clap();
let opts = Options::from_clap(&opts.get_matches_safe().unwrap_or_else(|err| {
   structopt::clap::Error::with_description("error goes here", err.kind)
      .exit()
}));