Add tests for the generated completions

[minad]

There is an easy solution to quickly generate a large number of tests by copying some of the complex man pages and dump the parsed candidates and annotations to a separate file. These golden tests can then be used to quickly find regressions. This should help to reliably fix issues like #16.

If there is interest I am willing to contribute a patch. I am currently trying out eshell and I am kind of excited about its possibilities. I also talked the last few days with @LemonBreezes and @karthink, so maybe there is some interest in collaboration? pcmpl-args with its man/help parsing is the most promising candidate to get good eshell completion for many commands!

[CeleritasCelery]

Thanks for the issues! I would be very interested in patches to improve this package. Especially anything that improves reliability or user experience.

[minad]

@CeleritasCelery Thank you for hearing back from you! I have a question regarding your other package native-completion. Which one do you consider the best long term solution?

For me pcmpl-args seems to be the most promising candidate for an "Emacs-native" shell based only on Emacs components. I use Eshell and combine it with my Corfu completion UI. Another well-known alternative is Company. The experience of Eshell+pcmpl-args+Corfu is almost on par with the fish-completion, which is also based on parsing the man pages. In the last days we worked a bit with our Eshell configurations and I also experimented with help parsing. Then @LemonBreezes pointed me to pcmpl-args which is already a very complete solution - help and man parsing and also custom completers for special commands!

[CeleritasCelery]

question regarding your other package native-completion. Which one do you consider the best long term solution?

They serve two different purposes and can't be substituted for each other. native-complete talks to the underlying shell to get completions and knows nothing about the commands themselves. But because of that, it needs an underlying readline enabled shell, which eshell does not have by design. However I think a man/help page parsing solution like pcmpl-args is the best approach for eshell, which needs to make completions from scratch. The two packages can coexist and each serve their own purpose. Personally, I would love to see more people use eshell as it improves and becomes more powerful.

[minad]

Thanks! I agree that these packages are orthogonal to each other. I mainly asked because I was wondering if you had somehow given up on eshell or the pcomplete mechanism in favor of using the shell or even term, since from what I've read this seems to be a common pattern for many Emacs users. Many people try eshell but then abandon it after a while for various reasons, lack of some features, performance issues, problems with completion etc. For me the eshell integration into Emacs is unmatched thanks to nice features like redirecting to buffers and the ability to call Emacs commands or evaluate Elisp directly. However in order to use Eshell as a viable alternative to zsh or fish, better completions play a big role - ideally completions implemented directly in Emacs in contrast to just calling fish/bash as the fish/bash-completion packages do. The approach taken here with the parsing of help output and man pages is great since it "scales" - the user can quickly enable completions for a command by adding a single defalias.

[minad]

Incidentally just today on reddit https://www.reddit.com/r/emacs/comments/sbdmr7/improving_shell_in_emacs/ with comments like this:

imho: vterm is only one usable terminal solution for emacs without any compromise. Without it i need external terminals.

So I hope we can smooth some of the rough edges of eshell and make it slightly more friendly to new users. But I suspect that eshell will probably always remain a special solution which works well mostly for people who often write some elisp and treat Emacs as a programmable lisp machine.