Skip to content
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

editor and preview out of sync when two soft line breaks are followed by includes #1624

Open
pstueck opened this issue May 24, 2024 · 7 comments

Comments

@pstueck
Copy link

pstueck commented May 24, 2024

1624.zip

Observation vs. expected behaviour

Editor and preview are out of sync when navigating through the source of mini.adoc.
Possibly related to the inclusion of tagged files, yet even without tags, the preview “goes mayhem” with included files.

I would expect the preview to jump to the first line of an included file, when the cursor reaches the actual include:: directive (or at least in closest vicinity-st). Not just “somewhere” (micro jumps not taken into account).

Steps to reproduce

I added a—not sooo—minimal example.
Please reduce the preview window so that the jumps do happen.

When I navigate with the cursor through mini.adoc, the “jump lines” are 5 and 6 (which is waaayyy to early, IMHO).

  • 5 to 6 – preview jumps to the end of the rendered HTML
  • 6 to 5 – preview jumps to back to the text in the editor (about 2.5 lines before the actual text)

I was able to (slightly) workaround that by adding {empty} after each include.
This does not completely fix the issue, yet provides a little bit better navigation.
And now the “jump lines” differ on direction.
Going down, it’s …

  • 5-to-6 (“Nam 1” at bottom of preview) … uhm … we are still way off from even the first include 🤣
  • 10-to-11 (“Consetetur 2” near bottom of preview)
  • 13-to-14 (end-of-preview)

Going up, it’s (to give it credit, the jumps seem sensible, as they more or less go “to the other extreme”) ...

  • 14-to-13 (“Consetetur 2”)
  • 11-to-10 (“Nam 1”)
  • 6-to-5 (actual editor position)

And even when you remove the soft line breaks ( +), the main jump starts with line 5.
The preview syncer seems to think that line 5 is the very last line before the first included file.

Environment

Plugin Version: 0.41.14

IntelliJ Details:
IntelliJ IDEA 2024.1.2 (Ultimate Edition)
Build #IU-241.17011.79, built on May 22, 2024
Licensed to *******

Runtime version: 17.0.11+1-b1207.24 amd64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
Linux 6.2.0-36-generic
GC: G1 Young Generation, G1 Old Generation
Memory: 3966M
Cores: 12
Registry:
ide.experimental.ui=true
Non-Bundled Plugins:
com.jetbrains.space (241.17011.48)
digital.pedda.loremIpsum (1.1)
org.jetbrains.plugins.ruby (241.17011.79)
org.asciidoctor.intellij.asciidoc (0.41.14)
com.intellij.ml.llm (241.17011.2)
com.mallowigi.colorHighlighter (18.0.0)
com.firsttimeinforever.intellij.pdf.viewer.intellij-pdf-viewer (0.15.0)
Kotlin: 241.17011.79-IJ
Current Desktop: ubuntu:GNOME

@pstueck pstueck added the bug label May 24, 2024
@ahus1
Copy link
Contributor

ahus1 commented May 26, 2024

Thank you for reaching out. The scroll positions are determined by line markers on each paragraph that exist as hidden attributes in the preview.

At the moment I receive one marker per block (equivalent to a paragraph or a heading).

I had a look and I can improve it in a way that if there is an include, it will place the preview where the include begins. Still, if there are multiple includes, it will not scroll to the second and third if there is no content between them. I'll make this part of the next release of the plugin.

When there are multiple includes from the same file (with tags as in your example), there is currently no good way to determine wich content in the preview matches which include.

How common is it in your setup that there are multiple includes in sequence?

@pstueck
Copy link
Author

pstueck commented May 27, 2024

Unfortunately the preview positions are always off, no matter tagged includes or separate files (tested that).

I am afraid, I need to see commit 42ef53d in action (as in: Plugin updates to 0.41.15).
I will check on this issue then.

If there would be an easy way to teach the pre-processor to automatically place an {empty} just after each include, that could also help (and it isn’t even required to check for existing content, as far as my mini-tests go).
Those post-include-{empty}-ies seem to help the preview-er to get a better scroll-to position.

How common is it in your setup that there are multiple includes in sequence?

Actually for me, that is the common resp. basic setup … yet as I know to place an {empty} after the include, I can kinda deal with it.

@ahus1
Copy link
Contributor

ahus1 commented May 30, 2024

The changes are available as part of version 0.41.15 of the plugin which is currently available as a pre-release. Please let me know if you think this is an improvement, especially if you add the {empty} after each include.

The pre-release of the plugin is available from GitHub releases and the IntelliJ AsciiDoc EAP repository.

@HaLo1701
Copy link

HaLo1701 commented Jun 24, 2024

Hello,
I have the same effect in new version 0.42.0.

Clicking in preview or editor takes no effect on synchronisation.

Also the icons for editor/preview are on the most right site and the other icons for bold/italic/... and generating PDF are missing now:
grafik

@ahus1
Copy link
Contributor

ahus1 commented Jun 24, 2024

@HaLo1701 - I messed this up when trying to make it compatible with IntelliJ 2024.2. There will be an updated release shortly.

Instead of the menu bar, please use the context menu. Unfortunately there is no workaround when clicking on the preview except for downgrading to a 0.41.x version.

@ahus1
Copy link
Contributor

ahus1 commented Jun 24, 2024

Follow #1636 for the updates, as that is really related to that issue.

@HaLo1701
Copy link

Hello,
many thanks for your fast response.
It works now and the icon bar is back.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants