Comments (9)
@ysthakur I am really happy you are going to start taking a look at this issue.
Here are some other things to keep in mind as you go down this path.
These might be longer term goals of where we want to possibly go than
what is possible in your first PR to address this issue but keeping
it in mind might be helpful in the design decisions you make.
Longer term we should probably consolidate the location of all of our menus into one place.
Meaning the description menu that is now located in the nushell repo and
the reedline menus should probably come together...
Not sure the best location of this code but options would include...
- Moving the description menu over to reedline from nushell
- Having a separate menu crate that lives in the reedline repo ?
- Having a separate menu crate that lives inside the nushell organization
so that both reedline and nushell have access to them along with other
projects that want a terminal based menu system.
Which brings me to my next point 😄
It might be nice to think of this effort longer term as having a nice API
where completers and menus work together and is available to the broader
rust community... Just an idea but keeping this in mind in your design
might be helpful.
The reason I bring this up is because @maxomatic458 is considering broadening
the scope of how completers work and maybe some brainstorming is in order
for thinking about what the menu system needs from a completion point of
view and what the API should look like ?
In the nushell community we always like to crawl, walk, run so I am not
saying this work needs to be done. But its always nice to have bigger
ideas of where we are possibly going with this work.
Of course we are all having fun and all of our efforts are greatly appreciated.
from reedline.
hmm i see,
so i guess we could do something like this then
struct MenuCommon {
name: String,
active: bool,
// a bunch of fields that the menus share
}
// and then include this in the menus
struct Menu {
common: MenuCommon,
some_specific_thing_for_this_menu: ...
}
this would remove a good bit of code duplication, but then we would need two builders (one for the MenuCommon, and one for the menu itself) to build a menu
from reedline.
@ysthakur Thanks for you comments and the HackMd write up as well...
As far as the crate idea is concerned thats probably further down the road than the work proposed in this issue and the Hackmd document...
The concept of having a crate is that if the Menu System API was well designed and generic enough it could be used by other Line Editor and CLI Applications that wanted an off the shelf ready built Menu and Completer System that was not tied to Reedline...
By having a Menu and Completer crate then Reedline could be built and distributed without the baggage of the Menu System and Completer System... Clearly this would require a dramatic Engine refactorization which probably is not going to happen.
But in any case its always good to keep modularity in mind --- @sholderbach would tell me in a polite way that there is a tradeoff here as well ---- and part of me tends to agree with him.
But for now --- its clearly not necessary in any way 😄
from reedline.
I added your HackMd document here as well so it can be found easier in the next period of time...
https://hackmd.io/gDNAvI-8TDyubogworDyCA
from reedline.
cc: @maxomatic458, since you're working on improving completers
im probably not making more changes to the completer anytime soon. I just added a function for convenience that menus can make use of.
All the menus also have a lot of fields in common (which could be compacted in a struct).
maybe we could also just get rid of the all the builder functions and use a proc macro for that?
from reedline.
cc: @maxomatic458, since you're working on improving completers
im probably not making more changes to the completer anytime soon. I just added a function for convenience that menus can make use of.
All the menus also have a lot of fields in common (which could be compacted in a struct).
maybe we could also just get rid of the all the builder functions and use a proc macro for that?
I would probably 👎 the proc macro concept simply because longer term they are more difficult to read, understand, and maintain.
In my view, larger open source projects like nushell etc has lots of different people over time maintaining and reading the code and we should make it easy as possible for them to understand what is going on (including myself) 😄
from reedline.
To add on to this, only_buffer_difference
is also handled pretty much the same way in all the menus, including description_menu
, I think
from reedline.
I don't know if there's already a discussion going somewhere, but in case there isn't, I made a HackMD for brainstorming, would love to get more of your opinions @stormasm (cc: @maxomatic458, since you're working on improving completers) (also, just to clarify, I wasn't planning on making a PR all by myself anytime soon, just wanted to be involved in the discussion 🙂)
Moving the description menu into the same crate as the other menus makes sense to me too. Is there any reason to make a separate crate just for the Menu
trait and its implementations, though? (I figured such a crate wouldn't be used by anyone other Reedline and Reedline users)
from reedline.
Ah, a line-editor-agnostic menu system sounds cool
from reedline.
Related Issues (20)
- After `ExecuteHostCommand` is handled, new prompt is rendered HOT 1
- When prompt starting row is 0, new prompt is rendered on each key type HOT 5
- external_printer does not print until I press some key
- Implicit copy to system clipboard doesn't obey law of least surprise and poses potential security hazard HOT 10
- Suggestion about is_valid function of LineBuffer struct HOT 1
- Tab keybind doesnt work with modifiers HOT 5
- [QUESTION]: can I disable the indicator HOT 2
- `Move(Big)WordRightEnd` is off-by-1 in insert mode HOT 1
- New actions to cancel menu & accept-and-hold
- Index out of bounds HOT 8
- 0.30.0 (Nu 0.91.0) does not respect cursor position after host cmd exec in a keybinding HOT 10
- Prefix history search broken in vi-mode HOT 5
- `columnar_menu` panics on non-ASCII characters in directory
- Mouse controls HOT 1
- vi keybinds are wrong and/or inconsistent with readline HOT 2
- Modal Menus
- Default keybind for "newline" HOT 1
- Column menu spaces don't respect special characters (accents, emojis...)
- Cursor slowdown when pressing left/right arrows and there is a lot of text in the prompt HOT 2
- analog to inputrc for programs using reedline HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from reedline.