Home / GitHub Page

While Editing, the current line jumps upward

Setup
Joplin 1.0.179 (prod, darwin)
macOSX

While editing a note the current line that I am looking at has a tendency to jump upwards steadily by small amounts. I was wondering if anyone else had seen this behavior or could speak to it being intentional or a potential bug.

Basically, I tend to move the cursor around a lot, create new lines, and type (all pretty standard stuff for a text editor). I feel like it’s distracting that as I am looking at it everything shifts upwards. I have to follow it with my eyes, and I haven’t been able to find a specific repro case. I had a hunch it had something to do with the program trying to line up the raw markdown scroll position and the rendered markdown scroll position so I changed the view to just the raw markdown. It may still be doing that though, even if the rendered markdown is collapsed.

I am new to Joplin, I just made an account here. I tried searching around a bit before posting, but if this is a well-known or intended thing my apologies.

Yes, there’s a gh issue open. When I’m home I’ll search for it and add it here as a reference.

1 Like
1 Like

Hey tessus,

Thank you so much for the reply. I am glad its a known issue and someone will be working on it.

Joplin is awesome!

I would like to say that I am also having this issue.
Windows 10.
Joplin 1.0.195 (prod, win32)

Client ID: d129a95aedbc42baa2c9bd6ebd4fee8a
Sync Version: 1
Profile Version: 28

Revision: f4a562bc (master)

There is a PR that might fix the bahvior. Laurent has to review it though. Right now there are way more PRs than normal…

1 Like

Is there any progress on this? The editor constantly moving around in unexpected ways has got to be one of the bigger nuisances of Joplin. Solving this should preclude adding any more features since it is so fundamental (IMHO).

Could this have anything to do with the editor having to fight the viewer all the time on who controls the scrolling? Note, personally I would decouple the two since they are not really scrolling-compatible. What you see in the left may be pages different than what is seen on the right. Undo and redo also do bizarre things with scrolling (and highlighting) behavior.

Lots of little bugs add up to erratic behavior.

1 Like

@t0dd

Good point, well made.

It was only yesterday I had to do some extensive editing to some older and longer notes for the first time in a while. The jumping was more noticable than I remembered it. In some cases I had to scroll the area I was editing back into the edit pane as the text just kept creeping upwards until it was no longer viewable.

I believe that recently on this forum @bedwardly-down suggested taking some time to tighten up the code / packages for existing features before moving on to newer things. This seems similar to what you are suggesting and It would look like a sensible thing to do now the GSoC “gold-rush” is over… :slight_smile:

I am not a dev and have absolutely no say in the matter, but as a user I still think it could be a worthwhile exercise.

It might look like a lot of people are working on the app, but when it comes to fixing bugs it’s mainly me. You’re free to help though:

  • Provide patches to fix the bugs
  • Triage the issues on GitHub - ask people to provide more info, etc.
  • Provide step by step instructions on how to replicate bugs

etc.

Fixing bugs is a top priority as it always was, but it takes time.

@laurent

I’m having trouble reading the “tone” of your previous post. For me it wanders between an upbeat “Hi there! This is what you can do to help me a bit!” and a weary “Oh, come on, please give me a break. I’m doing as much as I can, already!” :slight_smile:

TBH I did think that there was actually a group of “core developers / maintainers” holding eveything together. If it is mainly just you squashing bugs then you should be congratulated for achieving what you have whilst being restricted to having just 24 hours in every day.

I’ll never be able to assist with bug patches but I will help out with the other suggestions wherever I can.

Thank you :+1:

Yes somewhere in there I guess :grin: But I really mean that any help is welcome, and thanks anyway for giving a try to the pre-releases. The coming release is huge as it incorporate everything from GSoC and I wouldn’t be able to release that (or at least nothing really stable) without the feedback you and others are providing.

2 Likes

On second thought, the challenge of decoupling the viewer from the editor would be the search, I think. I scroll and review the finished document, and then I have to go find it in the editor. That’s challenging if it is a longer, or complicated document. At least with them scrolling together, you know you are approximately in the same area in the other viewport.

Just know we appreciate you, @laurent.

As for contributing. I certainly try (I know you weren’t singling me out but speaking in general). I file enough bugs, I suppose. So, I suppose that makes me a certified whiner. :slight_smile: And I test drive the release candidates (was playing with 211 today). As for diving in the code … 20 years ago? yes. Today? unlikely.

This is off-topic, but figuring out a way to monetize this thing would be good. Even better (more sustainable) is the recruitment of coders, as you are doing here. I suppose that comes with popularity. Joplin is seeing traction, but nailing these few really annoying bugs and solving some of the more annoying use case problems, I think will really draw people in. When I was an engineering manager years ago, I called them “broken windows.” We saw our clients satisfaction rating go through the roof when we dropped everything and focused on everything that contributed negatively to user unhappiness: anything hard to use, odd to use, ugly, or annoying. Even small stuff got prioritized over most features if the issue fell into that special category. It was a triage flag that trumped everything. We called it the Broken Window Campaign, and it was an enormous success.

I am meandering here so I will shut up. Keep up the good work, Laurent, and I do hope more folks dive into the code. Being on the sidelines here for a couple years I have certainly seen a rise in participation in one form or another, which is hopeful.

Anyway. Cheers. Stay positive. Avoid the virus and all that. :slight_smile: -t

3 Likes

Holy cow! I don’t know what you did in 1.0.216, @laurent, but the editing experience is suddenly far more stable.

Was it:

  • Fixed: Markdown editor would not scroll in sync with viewer in some cases (#3228)
    . . . or . . .
  • Fixed: Fixed two way scrolling issue in Markdown editor (no issue number)

. . . or both? I think I see what you did. You made the editor the “master” of scroll and the viewer adjust? Or some such? Cuz, you are typing in the editor, not the viewer. Makes sense.

Regardless, thank you. Thank you thank you thank you.

And, by the way, I finally started contributing via GitHub Sponsor (hey, folks, if you use Joplin quite a bit, like I do, you should toss him a few bucks every month as well!): go to the top of https://joplinapp.org/ and you can sponsor a couple different ways.

Again. Thank you, Laurent. This was a huge HUGE headache.

1 Like

Good to hear scroll is getting more stable, and I guess it was due to both these changes. There’s still this annoying bug to fix but I suspect I’ll need to do a bit of refactoring to get this working.