-
Notifications
You must be signed in to change notification settings - Fork 31
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 highlight component #237
base: master
Are you sure you want to change the base?
Conversation
613ff00
to
12dfec2
Compare
This is a massive improvement, thanks! I think it would be good to remove any mutli-line highlight support, since that really contributes to the complexity. By getting rid, it would mean we only have highlight logic in the |
Cool, yeah, I can do that. A couple questions:
|
yep
Hmm, yeah. I think it would be nice to have a |
12dfec2
to
ac2f86a
Compare
const paddingTop = parseInt(line_div.css("padding-top")); | ||
if (left >= 0) { | ||
left -= paddingLeft; | ||
} else { |
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.
@nrc since the position is now calculated differently, I adjusted the conditional for the left
padding subtraction to check for left >=0
rather than left > 0
. Do you know if there would ever be a case where left
is less than zero, or could I remove the else
here?
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.
We call it here: https://github.com/nrc/cargo-src/pull/237/files/ac2f86ab6bc765177f3e12af715b890c5de80476#diff-4018adfb8de39d7a30dd31dd44e3b4cdR22 and lhs is highlight.column - 1, so I think that should always be greater than 0 since the column should be 1-indexed, but we might want to check that it really is 1-indexed, not 0-indexed, and that seems like an easy mistake to make so it might be worth asserting that highlight.column >= 1 there.
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 found a case when testing a full-line highlight where lhs
ends up being 0, and without changing the left > 0
(as it is in utils.js
) to left >= 0
, the highlight calculation is off slightly. But it sounds like we could just adjust the validate_highlight
function to ensure highlight.column_start
is not <= 1 rather than 0, as it is currently?
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.
@nrc Ok, I'm re-thinking my previous comment - I think the validate_highlight
logic can be left as-is, but the conditional adjustment in make_highlight
could be reduced to left -= paddingLeft
, with no check for left >= 0
or any else
clause. At least that's working for the test cases I've been running through.
Creates and renders a highlight component for the
srcView
component. A couple of things to note:SearchResults
use of highlight with some additions, but I haven't attempted that yetmake_highlight
(L65). It seems to be working fine, but I think if we're seeing the highlight end up in the wrong location, there may be some render lifecycle conditions where the final position isn't yet available. If that's the case, I think we'd need to move most of themake_highlight
code intocomponentDidUpdate
insrcView
, and put positional data in state, pass down as props, etc.