Skip to content
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

Merged
merged 3 commits into from
Mar 10, 2020

Conversation

leavengood
Copy link
Contributor

This wraps around like VSCode.

Fixes #778 and part of #1423.

@CLAassistant
Copy link

CLAassistant commented Mar 8, 2020

CLA assistant check
All committers have signed the CLA.

@leavengood leavengood force-pushed the feature/workspace/editor-switching branch from 6a9ac8e to 95dc0f0 Compare March 8, 2020 19:40
@leavengood
Copy link
Contributor Author

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 workspace as a prefix.

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.

Copy link
Member

@glennsl glennsl left a 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!

src/Model/Actions.re Outdated Show resolved Hide resolved
src/Model/EditorGroup.re Outdated Show resolved Hide resolved
src/Model/EditorGroup.re Outdated Show resolved Hide resolved
src/Model/EditorGroup.re Outdated Show resolved Hide resolved
src/Model/EditorGroup.re Outdated Show resolved Hide resolved
@glennsl
Copy link
Member

glennsl commented Mar 8, 2020

You should also run esy format before pushing to make sure the CI is happy.

@glennsl
Copy link
Member

glennsl commented Mar 8, 2020

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.

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`.
@leavengood
Copy link
Contributor Author

I believe I have addressed most of the comments. I am still not very happy with how awkward the setActiveEditorTo function is in EditorGroup, but it works. The need for wrap around makes other ways of iterating through the list less workable.

Copy link
Member

@glennsl glennsl left a 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:

Comment on lines +71 to +74
switch (_getIndexOfElement(elem, tl)) {
| None => None
| Some(i) => Some(i + 1)
}
Copy link
Member

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:

Suggested change
switch (_getIndexOfElement(elem, tl)) {
| None => None
| Some(i) => Some(i + 1)
}
_getIndexOfElement(elem, tl) |> Option.map(succ)

Copy link
Contributor Author

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.

Comment on lines +111 to +120
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;
};
Copy link
Member

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:

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);

Copy link
Contributor Author

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.

@leavengood
Copy link
Contributor Author

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.

@glennsl
Copy link
Member

glennsl commented Mar 9, 2020

Happy to do it! I enjoy nitpicking 🙃

@bryphe
Copy link
Member

bryphe commented Mar 10, 2020

Such a great addition! Thank you for all the help with this @leavengood and @glennsl 🎉

Can't wait to start using this.

@bryphe
Copy link
Member

bryphe commented Mar 10, 2020

Looking at the CI - looks like an intermittent test failure, not related to the changes - kicking off a new run.

@bryphe
Copy link
Member

bryphe commented Mar 10, 2020

/azp run

@leavengood
Copy link
Contributor Author

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.

@leavengood
Copy link
Contributor Author

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.

@leavengood
Copy link
Contributor Author

/azp run

@azure-pipelines
Copy link

Commenter does not have sufficient privileges for PR 1447 in repo onivim/oni2

@glennsl
Copy link
Member

glennsl commented Mar 10, 2020

/azp run

@glennsl
Copy link
Member

glennsl commented Mar 10, 2020

Is there any way to speed up the CI?

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.

@leavengood
Copy link
Contributor Author

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.

@bryphe
Copy link
Member

bryphe commented Mar 10, 2020

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.

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 CentOS build) - it'd be nice to have that cached, because it's the bottleneck if the caches are working everywhere else.

It can be contributed to for sure - the files that control it are the azure-pipelines.yml file and the [.ci] folder (https://github.com/onivim/oni2/tree/master/.ci) but it can be a grind! Tends to be very time consuming to test and iterate on fixes & changes.

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.

Sounds great! Merging now 🎉

Thanks @leavengood for all the work on this! It's an excellent contribution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Input: Add Control+PageUp/Control+PageDown to switch between open files
4 participants