-
-
Notifications
You must be signed in to change notification settings - Fork 49
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
Implemented help commands
and added notice thereof to help
output
#584
base: master
Are you sure you want to change the base?
Conversation
output += m::text("Numbat supports a number of commands. Use ") | ||
+ m::string("help commands") | ||
+ m::text(" for more info.") | ||
+ m::nl(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not 100% satisfied with the phrasing here. Numbat (the language) doesn't really support any commands. You can't write quit
in a Numbat program, for example. It's really the different REPL/CLI interfaces that support certain commands. And that leads me to the other problem here: with the current implementation, this message will also be displayed in the web version. But help commands
doesn't work there, and if it did, it would have to show a different list of commands.
I really like this new feature and the help commands
output looks great! But I think we need to work on the web version first. As I said elsewhere, it would be great if we could share command-parsing code between different "frontends". We would then need a way to customize (1) which commands are available and (2) how some of them are implemented in a particular frontend, e.g. using a trait or using simple callbacks.
In some sense, the whole command-parsing/handling thing probably doesn't even belong in the numbat
crate. It's not part of the compiler or the language implementation. Even now, there are some frontends (IRC bot, mobile app, Jupyter kernel) that don't make use of commands. So they could be moved to a separate crate (numbat-commands
or similar). But I guess for simplicity, we can also leave the code in the numbat
crate for now. We also have things like unicode_input.rs
that are only used in specific frontends.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, you're right. I'm definitely too CLI-centric 😄. I'll need to think about how to share almost-the-same code between frontends. A numbat-commands crate probably does sense, with features to enable/disable various commands. Then in the commands code, just slap a #[cfg(feature)]
on every branch of every match statement.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had something else in mind. Let's maybe discuss different options first. I'll try to write down what I thought about tomorrow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had something else in mind. Let's maybe discuss different options first. I'll try to write down what I thought about tomorrow.
Curious to hear what your idea was.
No description provided.