starred/BoostNote-App

Fork 0

mirror of https://github.com/BoostIO/BoostNote-App.git synced 2026-04-26 21:05:55 +03:00

[GH-ISSUE #755] Displaying preview resets cursor position to last search-found-position #392

New issue

Closed

opened 2026-03-03 00:20:48 +03:00 by kerem · 4 comments

kerem commented

2026-03-03 00:20:48 +03:00

Owner

Originally created by @myicq on GitHub (Jan 4, 2021).
Original GitHub issue: https://github.com/BoostIO/BoostNote-App/issues/755

Current behavior

The cursor position is reset to top of markdown if preview (rendered text) is switched on and off.

Expected behavior

It is expected that editing can continue from same place regardless of preview state.

Not much of a problem for 10 line documents, but for really long texts, it's annoying to search the same spot again.

Steps to reproduce

Create a document and add around 10+ lines.
Position cursor at last line.

Activate preview using CTRL-E, then remove preview again. Cursor is now at top of document.

Same thing happens when split screen is activated: immediately as split screen shows, cursor jumps to start.

It is same for keypresses and menu icon usage.

BoostNote Legacy has the same "feature", so this may be more of a "feature" than an actual bug. Can it be avoided ?

Environment

Desktop/Web

Win 10 64 bit, BoostNote 0.12.3

Originally created by @myicq on GitHub (Jan 4, 2021). Original GitHub issue: https://github.com/BoostIO/BoostNote-App/issues/755 # Current behavior The cursor position is reset to top of markdown if preview (rendered text) is switched on and off. # Expected behavior It is expected that editing can continue from same place regardless of preview state. Not much of a problem for 10 line documents, but for really long texts, it's annoying to search the same spot again. # Steps to reproduce Create a document and add around 10+ lines. Position cursor at last line. Activate preview using CTRL-E, then remove preview again. Cursor is now at top of document. Same thing happens when split screen is activated: immediately as split screen shows, cursor jumps to start. It is same for keypresses and menu icon usage. **BoostNote Legacy** has the same "feature", so this may be more of a "feature" than an actual bug. Can it be avoided ? # Environment ## Desktop/Web Win 10 64 bit, BoostNote 0.12.3

kerem

2026-03-03 00:20:48 +03:00

closed this issue
added the
improvement request 🔨
label

kerem commented

2026-03-03 00:20:49 +03:00

Author

Owner

@myicq commented on GitHub (Jan 19, 2021):

Update, boostnote.next 0.12.4: The cursor position seems to strangely be NOT at the top of the document, but at the location where last global search resullt was selected.

Example:

Make a long(ish) document of 50-60 lines. At the very end, please a unique marker like thisistheEND
Search for this marker using CTRL-P
select the marker using double click with mouse (no keyboard function available to select..)
Close search
Now position cursor at start of document and activate / deactivate preview(rendering). EVERY time, the cursor will now jump to the end of the document, just before the unique marker. If the marker is deleted, the end of document is used still (nice hack, but probably a regular bug)

@myicq commented on GitHub (Jan 19, 2021): Update, boostnote.next 0.12.4: The cursor position seems to strangely be NOT at the top of the document, but at the location where last global search resullt was selected. Example: * Make a long(ish) document of 50-60 lines. At the very end, please a unique marker like `thisistheEND` * Search for this marker using `CTRL-P` * select the marker using double click with mouse (no keyboard function available to select..) * Close search * Now position cursor at start of document and activate / deactivate preview(rendering). EVERY time, the cursor will now jump to the end of the document, just before the unique marker. If the marker is deleted, the end of document is used still (nice hack, but probably a regular bug)

kerem commented

2026-03-03 00:20:49 +03:00

Author

Owner

@Komediruzecki commented on GitHub (Jan 21, 2021):

Update, boostnote.next 0.12.4: The cursor position seems to strangely be NOT at the top of the document, but at the location where last global search resullt was selected.

Example:

* Make a long(ish) document of 50-60 lines. At the very end, please a unique marker like `thisistheEND`

* Search for this marker using  `CTRL-P`

* select the marker using double click with mouse (no keyboard function available to select..)

* Close search

* Now position cursor at start of document and activate / deactivate preview(rendering). EVERY time, the cursor will now jump to the end of the document, just before the unique marker. If the marker is deleted, the end of document is used still (nice hack, but probably a regular bug)

Yes, it's kind of a mess now with all of this.

I'll try to see why this happens and prevent this.

Editor cursor should be kept stable even after preview is activated.
Editor cursor should change when you go to found item in search preview
Editor cursor should update when user moves it inside editor.

Does this sound good to you, do you have any other suggestions?

@Komediruzecki commented on GitHub (Jan 21, 2021): > Update, boostnote.next 0.12.4: The cursor position seems to strangely be NOT at the top of the document, but at the location where last global search resullt was selected. > > Example: > > * Make a long(ish) document of 50-60 lines. At the very end, please a unique marker like `thisistheEND` > > * Search for this marker using `CTRL-P` > > * select the marker using double click with mouse (no keyboard function available to select..) > > * Close search > > * Now position cursor at start of document and activate / deactivate preview(rendering). EVERY time, the cursor will now jump to the end of the document, just before the unique marker. If the marker is deleted, the end of document is used still (nice hack, but probably a regular bug) Yes, it's kind of a mess now with all of this. I'll try to see why this happens and prevent this. Editor cursor should be kept stable even after preview is activated. Editor cursor should change when you go to found item in search preview Editor cursor should update when user moves it inside editor. Does this sound good to you, do you have any other suggestions?

kerem commented

2026-03-03 00:20:49 +03:00

Author

Owner

@myicq commented on GitHub (Mar 13, 2021):

@Rokt33r I think this sounds reasonable, with cursor being at same position on preview on/off, cursor located at found position, and cursor of course moving when user moves it.

@myicq commented on GitHub (Mar 13, 2021): @Rokt33r I think this sounds reasonable, with cursor being at same position on preview on/off, cursor located at found position, and cursor of course moving when user moves it.

kerem commented

2026-03-03 00:20:49 +03:00

Author

Owner

@Komediruzecki commented on GitHub (May 28, 2021):

Hi myicq,

Just an update, local search feature was merged and released so now you can use local editor search and navigate to find/move cursor easier.

It still has the same problems with cursor being reset over opening/closing preview, but I will fix this for next release (hopefully next week) alongside whole local space refactor (new topbar UI, new sidebar with drag and drop, new theming, timeline feature from cloud space etc.)

Take you for your patience.

@Komediruzecki commented on GitHub (May 28, 2021): Hi myicq, Just an update, local search feature was merged and released so now you can use local editor search and navigate to find/move cursor easier. It still has the same problems with cursor being reset over opening/closing preview, but I will fix this for next release (hopefully next week) alongside whole local space refactor (new topbar UI, new sidebar with drag and drop, new theming, timeline feature from cloud space etc.) Take you for your patience.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/BoostNote-App#392

No description provided.

Rows
Columns