Skip to content
This repository was archived by the owner on Sep 6, 2021. It is now read-only.

Fix find first result centering #4339

Merged
merged 5 commits into from
Jul 11, 2013

Conversation

JeffryBooher
Copy link
Contributor

@ghost ghost assigned dangoor Jun 25, 2013
@JeffryBooher
Copy link
Contributor Author

@dangoor this should be good to go.

*/
Editor.prototype.isLineVisible = function (line) {
var $scrollerElement = $(this.getScrollerElement()),
coords = this._codeMirror.charCoords({line: line, ch: 0}),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to specify mode here "local" or "page". Seems like there might be an issue if the html menu or modal bar (find, quick open, etc.) is visible.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The mode param is optional and so far this hasn't been an issue (with find anyway). I'm not sure which one of these you would specify if either those cases were true. Once find has determined if the line is visible or not it will scroll the line to the center of the display if it's covered by the modal bar at the top anyway so the modal bar hasn't been a problem with this -- i tried various cases when i wrote it and it just seemed to work as desired. Not sure if you can get into this state with a menu -- those should dismiss when a command is executed.

@jasonsanjose
Copy link
Member

line 1 out of viewport-1
line 41 in viewport

See screenshots. I disabled the shell menus by commenting lines 272-274 in brackets.js to move the editorholder position downwards.

  • Screenshot 1: Line 1 is above the editor viewport but is reported as visible
  • Screenshot 2: Line 41 is visible in the viewport but is **not* reported visible

@dangoor
Copy link
Contributor

dangoor commented Jun 26, 2013

It looks like we'll want to take this in sprint 28 after the bug Jason noticed has been squashed.

(What Jeff said is true: this shouldn't affect the find feature. the trouble I see is that isLineVisible is new public API that should work for other cases.)

@JeffryBooher
Copy link
Contributor Author

@jasonsanjose @dangoor try it now. I'm using scroll position and page relative result checking which so far appears to be bullet-proof

@JeffryBooher
Copy link
Contributor Author

scratch that... "Local" coordinates not "Page"... I had tried "Page" earlier without success. "Local" is what we want...

@ghost ghost assigned jasonsanjose Jul 10, 2013
@JeffryBooher
Copy link
Contributor Author

@jasonsanjose @dangoor I may have dropped the ball on this. I should have let you all know that it is ready to merge now.

@@ -893,6 +893,21 @@ define(function (require, exports, module) {
};

/**
* Deterines if line is fully visible.
* @param {number} zero-based index of the line to test
* @returns {boolean} true if it's visible, false if not
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo @return. Also, change comment to true if the line is fully visible, false otherwise

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nevermind, I fix it myself.

@jasonsanjose
Copy link
Member

Looks good. Merging.

jasonsanjose added a commit that referenced this pull request Jul 11, 2013
@jasonsanjose jasonsanjose merged commit 8aa5fb3 into master Jul 11, 2013
@jasonsanjose jasonsanjose deleted the jeff/fix-find-result-centering-rebased branch July 11, 2013 18:37
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants