-
Notifications
You must be signed in to change notification settings - Fork 283
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
Implement the next/previous editor commands and keybindings #1447
Implement the next/previous editor commands and keybindings #1447
Conversation
This wraps around like VSCode. Fixes onivim#778 and part of onivim#1423.
6a9ac8e
to
95dc0f0
Compare
Hmmm, I just did some testing in VSCode and I think this works a bit different than I thought. If you have just one editor group, it moves between the tabs in that group (which is what I implemented), if you have multiple editor groups it moves between them when you reach each end (with full wrap around.) That is probably why the command has This is probably still a good first step, but I may be able to implement the full version too at a later date, if we want it. |
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.
Nice work @leavengood! I think the approach overall looks good, but have commented on a few nits below. And most of it seems to be caused by our own code being a bad example of how to do things!
You should also run |
Yes, I agree on both counts! |
Resolve the TODO for _getIndexOfElement by making it return option(int). List.find_opt is not actually the right choice to get an index. Also ran `esy format`.
I believe I have addressed most of the comments. I am still not very happy with how awkward the |
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.
Looks good! I'd consider this mergable if you're happy, but still have a few suggestions below you might consider:
switch (_getIndexOfElement(elem, tl)) { | ||
| None => None | ||
| Some(i) => Some(i + 1) | ||
} |
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.
You can use Option.map
for this:
switch (_getIndexOfElement(elem, tl)) { | |
| None => None | |
| Some(i) => Some(i + 1) | |
} | |
_getIndexOfElement(elem, tl) |> Option.map(succ) |
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 figured there had to be something for that like in Rust but when looking at the Reason docs I did not see much. I need to check the OCaml docs more I suppose. Good tip with using succ
too.
let newIndex = | ||
if (newIndex < 0) { | ||
// Wrapping negative, go to end | ||
count - 1; | ||
} else if (newIndex >= count) { | ||
0; | ||
// If this is past the end, go to zero | ||
} else { | ||
newIndex; | ||
}; |
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.
There are some convenience functions in Core.Utility.IndexEx
for this:
oni2/src/Core/Utility/IndexEx.re
Lines 1 to 27 in 7493356
let prevRollOver = (~first=0, ~last, current) => | |
if (first >= last) { | |
first; | |
} else if (current <= first) { | |
last; | |
} else { | |
current - 1; | |
}; | |
let prevRollOverOpt = (~first=0, ~last) => | |
fun | |
| Some(index) => Some(prevRollOver(index, ~first, ~last)) | |
| None => Some(last); | |
let nextRollOver = (~first=0, ~last, current) => | |
if (first >= last) { | |
first; | |
} else if (current >= last) { | |
first; | |
} else { | |
current + 1; | |
}; | |
let nextRollOverOpt = (~first=0, ~last) => | |
fun | |
| Some(index) => Some(nextRollOver(index, ~first, ~last)) | |
| None => Some(first); |
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.
Yep, that is exactly what I need. I'll give it a try when I get a chance.
By the way, I just want to say I appreciate all the time and guidance on the reviews. I know it can be a lot of work, as I am frequently on the other side. |
Happy to do it! I enjoy nitpicking 🙃 |
Such a great addition! Thank you for all the help with this @leavengood and @glennsl 🎉 Can't wait to start using this. |
Looking at the CI - looks like an intermittent test failure, not related to the changes - kicking off a new run. |
/azp run |
Thanks @bryphe! This is a really great project, I am amazed how nice it is already and I am glad to help how I can. If CI passes I think we can merge this as is, and I can do a bit more clean-up when I work on the setting editor by number commands. I also would like to add a test for EditorGroup then as well. |
I think this CI failure is not from my code again Is there any way to speed up the CI? Taking 30-60 minutes seems pretty long to me. I don't know if this is something people can contribute to fix, of course it is probably very complicated with esy and dune, Azure, multiple operating systems, etc. |
/azp run |
Commenter does not have sufficient privileges for PR 1447 in repo onivim/oni2 |
/azp run |
I think @bryphe is pretty on top of this, constantly tweaking the Ci process, but it seems tricky. I think caching was brought back a few days ago, but it's often failed for us for various reasons. And the Windows CI is particularly slow and finicky, and often just hangs. So I think it'd be hard to contribute to this, especially without a good overview of what's been tried before and what might seem to work in the short term but has proven to not work over time. |
As noted now that CI passed I think we can merge this as is and I can do some of the adjustments Glenn recommended in future work. |
Yeah, the CI is always a challenge. When the caching works - it really speeds up the builds! But it tends to be fragile - all kinds of things can break it (ie, recently Azure Pipelines changed the default paths, which broke our cache directories). Some previous battles with the build cache: https://github.com/onivim/oni2/pulls?q=is%3Apr+cache+is%3Aclosed I just noticed we weren't restoring the cache builds for OSX - so I opened a PR for that: #1458 One thing we are missing is we don't have a cache strategy at all for our one environment that builds on Docker (the It can be contributed to for sure - the files that control it are the
Sounds great! Merging now 🎉 Thanks @leavengood for all the work on this! It's an excellent contribution. |
This wraps around like VSCode.
Fixes #778 and part of #1423.