-
Notifications
You must be signed in to change notification settings - Fork 3k
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
Add modal keyboard motion mode #3315
Conversation
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.
it looks idk, "normal", like I don't really see how could you implement this thing the other way. Well, I have question about configuration though. I don't think we should provide most of those bindings to normal mode, right? maybe we should put them in a separate restricted section section?
Also, I haven't touched keyboard_motion.rs
, since I don't remember whether I can review it now or no.
if I type |
@kchibisov I can't seem to replicate this, after typing |
@nixpulvis it was stated on IRC that it’s expected vim behavior, so it’s not a problem. |
I think I should have implemented everything now, except for a good name for the keyboard motion click action. I'll have to think about that for a bit but that shouldn't stop anyone from reviewing all the changes I have made, since it's quite a bit of stuff. |
0394e93
to
eadd3ee
Compare
After some consideration, I've made the decision to remove the ability to emulate the mouse using the keyboard motion mode. The main reason for this is that it created a lot of additional complexity, especially related to modifiers. As far as I can tell, there's no clear solution on how clicking or scrolling with modifiers should be emulated. So this would only allow a very limited amount of emulation and could easily cause confusion on what exactly is going on and how things work. I think since we're talking about terminal emulators here, we should be able to make the assumption that the applications never rely on mouse input and always have their own solutions for keyboard controls. So we should encourage users to make use of these instead, since they allow properly doing things instead of hacking around it. |
@chrisduerr I agree completely. However, there's still something I think that's strange about the state of this PR (stemming from the branch name). I don't want to think of this as vi-mode, I want to think of this as adding modes (like vi), which use the same bindings as vi. This would be the first (two?) mode(s):
I don't personally care about having multiple modes to use, as long as there are logical bindings to get to them. This would also solve a minor thing about this PR that's been bugging me, which is the inverted nature of the default mode switch bindings with respect to vi, because now I'm thinking I want to get to selection mode through a mode selection leader key which could default to Ctrl + ESC. Then I'd press s to enter selection mode. Otherwise, we could just have two mode activation bindings, Ctrl + s and (something like) Ctrl + u. I don't want to overly complicate things too much for you, but I do think it might be worth some about of refactoring. |
@nixpulvis I definitely think that at least a search mode is still missing, however I don't think I want to block this PR on that addition. I'd personally like to get some feedback on this before moving forward with additional features. My idea for the progression of this feature was to implement it in an incremental nature, to get optimal feedback on how people feel about things and to make it possible to stick to minimal possible implementation. After this, I'd like to go for a search mode for example. This search mode would likely start a selection including everything you've searched for and move your keyboard cursor to the end of the selection. I plan on starting that using the Once that is implemented, it will obviously be much easier to open URLs already. You could simply run At that point, launching URLs should already be pretty simple. So I'd like to give that a run for a bit first. I'd like to find out if it makes more sense to just add a shortcut for Even if we do add a dedicated url mode, the implementation could still be done in multpile ways. Either by having a completely separate mode with a completely separate binding, or by adding the URL search as a 'motion' where pressing the key combination for a URL (like tridactyl/vimium) would just move the cursor to that URL. I think it's worthwhile going slow on this because I think at this point it's difficult to say how exactly this will play out once you use it a bit. So I definitely want to give the normal search a test before implementing specialized URL search. With something like vimium there are a ton of URLs open at a time, making it an obvious necessity to have a way to jump to one specific URL immediately, but I'm not sure if the same is true for a terminal emulator. @nixpulvis How do you feel about this approach? Do you think it would be a mistake to go for a minimal approach first and get it merged before a second iteration? If so, are you concerned about users complaining that the mode sucks and giving up on it before it ever gets good, or are you more concerned about the initial PR going in a direction that will be completely scrapped in the future? |
I've noticed that you're not expanding keyboard cursor on full-width glyphs properly, by that I mean that you're not doing it from spacer. |
alacritty.yml
Outdated
# - ScrollPageUp, ScrollPageDown, ScrollHalfPageUp, ScrollHalfPageDown, | ||
# ScrollLineUp, ScrollLineDown, ScrollToTop, ScrollToBottom | ||
# - ToggleKeyboardMode, ToggleNormalSelection, ToggleLineSelection, | ||
# ToggleBlockSelection, ClearSelection, KeyboardMotionLaunchUrl, |
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.
KeyboardMotionLaunchUrl
if we want to support more than just opening URLs we should likely name it properly, so we don't have broken binding in a future.
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.
What else do we want to support? There's nothing as far as I know.
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 just afraid of naming things so specific, like you never know what could we support next. But we I'm not insisting on rename.
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.
Don't get me wrong, I definitely agree with you here, but what would you suggest instead?
KeyboardMotionTriggerAction
? That doesn't say very well what it does though, launch url is more specific.
We should also update selection on actions that change cursor position, like |
🎉 thanks for implementing this. I can't wait to use it literally all the time! |
Speaking of launching I wonder if it would make sense to have an action to "xdg-open" the complete word where my cursor is? So I do this :
|
No, it's not really related to URL matching directly. You can implement it in terms of selection and bindings.
We don't have a way to toggle xdg-open on selected content, but I feel like it could make some sense to do that. However custom matchers are nicer, since you'll get underline, etc. |
@kchibisov I'm assuming they want to open things that are missing the I'm also a bit irritated that our default launcher doesn't seem to open relative paths, but that isn't our fault. |
@nixpulvis you're right about my wanting to open things that are missing file:// bit. The solution I'm requesting is much simpler though, without a need for a complex regex. Just |
@SRGOM The issue is that we'd like to underline the link before pressing enter to open it. This requires detecting links in some way. If I'm understanding your suggestion correctly, then I would be able to press enter on words that would not open, and we would still pass the string to I'm honestly not a huge fan on this suggestion, but curious what @chrisduerr has to say. It would be nice to find a way to be "in sync" with the launcher program, in one way or another. Meaning that all supported links were properly detected. Either way, this is probably better handled as a separate issue, since this mode has been merged now, and the current functionality is working as intended. |
@nixpulvis That is indeed what I'm suggesting- basically say here's a sample shell session:
I would like to enter the "vi"-mode. Then move around and go wherever I want. Say I am on I don't know if you guys like it but if I feel this is both simple and intuitive (and while alacritty users are all power users, ultimately simplicity helps) |
@SRGOM I recommend you try out this feature. Most of what you desire is already implemented. If the VI mode cursor is over a valid URL, like the ones you've posted below |
@nixpulvis Yeah basically my point was not specifically supporting anything, just blindly launching xdg-open so that I can also open background.png. Can't wait to try out the release after this though (I believe that's when the feature lands...) |
@SRGOM I'm not a fan of adding a built in feature to blindly launch xdg-open, but I believe it's already possible to do what you want. You can setup the key bindings so that whenever a binding is pressed, the active selection is copied to the clipboard and after that you can launch xdg-open using the data that has been saved to your clipboard. That should work just fine. |
I think this is 90% of what I ever wanted from this, where last 10% would be search mode that was already mentioned as next feature by @chrisduerr. Amazing work, I m really excited about this ...in a meantime, tmux to the rescue just curious, are you planning to support regex searches? if not that would be next level of said feature for sure ! |
Make notmodes follow modes in terms of override behavior, so default binding won't be pruned if and only if its modes intersect with new binding notmodes and vise-versa. Fixes alacritty#3315.
@chrisduerr Thanks for this feature. I use Tmux within Alacritty solely for its selection mode. Having this feature directly in Alacritty will simplify my life and save memory. |
This implements a basic mode for navigating inside of Alacritty's
history with keyboard bindings. They're bound by default to vi's motion
shortcuts but are fully customizable. Since this relies on key bindings
only single key bindings are currently supported (so no
ge
, orrepetition).
Other than navigating the history and moving the viewport, this mode
should enable making use of all available selection modes to copy
content to the clipboard and launch URLs below the cursor.
This also changes the rendering of the block cursor at the side of
selections, since previously it could be inverted to be completely
invisible. Since that would have caused some troubles with this keyboard
selection mode, the block cursor now is no longer inverted when it is at
the edges of a selection.
Fixes #262.