Skip to content

Implement the next/previous editor commands and keybindings - #1447

Merged
bryphe merged 3 commits into
onivim:masterfrom
leavengood:feature/workspace/editor-switching
Mar 10, 2020
Merged

bryphe merged 3 commits into
onivim:masterfrom
leavengood:feature/workspace/editor-switching

Conversation

@leavengood

Copy link
Copy Markdown
Contributor

This wraps around like VSCode.

Fixes #778 and part of #1423.

@CLAassistant

CLAassistant commented Mar 8, 2020 •

Copy link
Copy Markdown

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
Copy Markdown
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.

@glennsl glennsl left a comment

Copy link
Copy Markdown
Member

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!

Comment thread src/Model/Actions.re Outdated
Comment thread src/Model/EditorGroup.re Outdated
Comment thread src/Model/EditorGroup.re Outdated
Comment thread src/Model/EditorGroup.re Outdated
Comment thread src/Model/EditorGroup.re Outdated
@glennsl

glennsl commented Mar 8, 2020

Copy link
Copy Markdown
Member

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

@glennsl

glennsl commented Mar 8, 2020

Copy link
Copy Markdown
Member

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
Copy Markdown
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.

@glennsl glennsl left a comment

Copy link
Copy Markdown
Member

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 thread src/Model/EditorGroup.re
Comment on lines +71 to +74
switch (_getIndexOfElement(elem, tl)) {
| None => None
| Some(i) => Some(i + 1)
}

Copy link
Copy Markdown
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
Copy Markdown
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 thread src/Model/EditorGroup.re
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
Copy Markdown
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
Copy Markdown
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
Copy Markdown
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

glennsl commented Mar 9, 2020

Copy link
Copy Markdown
Member

Happy to do it! I enjoy nitpicking 🙃

@bryphe

bryphe commented Mar 10, 2020

Copy link
Copy Markdown
Member

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

Can't wait to start using this.

@bryphe

bryphe commented Mar 10, 2020

Copy link
Copy Markdown
Member

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

@bryphe

bryphe commented Mar 10, 2020

Copy link
Copy Markdown
Member

/azp run

@leavengood

Copy link
Copy Markdown
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
Copy Markdown
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
Copy Markdown
Contributor Author

/azp run

@azure-pipelines

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

@glennsl

glennsl commented Mar 10, 2020

Copy link
Copy Markdown
Member

/azp run

@glennsl

glennsl commented Mar 10, 2020

Copy link
Copy Markdown
Member

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
Copy Markdown
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

bryphe commented Mar 10, 2020

Copy link
Copy Markdown
Member

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