obsidian-hover-editor
obsidian-hover-editor copied to clipboard
nothingislost
Default View Mode Seems Out of Date, and Scroll Back to Top Randomly
When I open a hover editor window, it seems that the default mode setting in the plugin setting doesn't work.
Although I set it to Reading Mode, it always shows me Editing mode every time I open a hover editor.
What's more, There is a chance that the main notes will slide straight to the top when you end the hover editor view. After you finished viewing one hover editor window, maybe two, three of it..... the number is totally random and when I turn off the plugin, This will no longer happen under the ob default hover view.
Can you reproduce this in the sandbox vault with stock theme, no snippets, and no other plugins? If so, please send info on your settings and versions, as I can't get this to happen. The right mode comes up and I can create dozens of popups without making anything in the main notes scroll.
I just tried it and it's true that reading mode and won't scroll up are in effect inside the sandbox.
But in my original vault the problem still exists...🥲
Hey, I have found the reason of the first fault! After I turn off another plugin, Force note view mode, the default reading mode setting in hover editor is in effect! Could you please optimize the compatibility between these two plugins?
I have tried many times in the sandbox vault, and I found that if I turn on the Force note view mode and remember cursor position plugin concurrently, the scrolling bug would occur again.🥲
I don't know what you mean by "optimize the compatibility" here. Presumably the issue is that "Force view mode" is just doing its job of forcing the view mode, and "Remember cursor position" is doing the scrolling. There really isn't a sensible way for Hover Editor to stop them from doing their jobs; it would be up to those plugins to not do those things if the user doesn't want them. (For example, by having an option to not force the view mode if the target pane is in a hover editor - they can detect this via leaf.containerEl.matchParent('.popover.hover-editor').)
Sorry, maybe I forgot to add one thing. The situation is like this: when I use force the view mode plugin to lock the view mode to reading mode, no matter what I set the default reading mode in the hover editor settings (reading mode, editing mode or mathc current view) the reading mode of the article in the popup window displayed will always be editing mode.
(of course, the md document in the hover editor does not have the yaml header of the force the view mode plugin added to it, if it did, it would still be displayed in the mode locked by the force the view mode plugin)
Did you turn on "Ignore force view when not in front matter" in the "Force note view mode" settings? If you don't, it will force everything into the default mode as soon as the note is activated.
No, I didn't. After turning on, the plugins work perfectly! Thank you for your patience and dedication!
Hello,
I love this plugin but i have the same problem. The cursos scrolls back to top randomly. I tried to reproduce on a sandbox vault and it doesn't happend.
I tried to change appareance but nothing, i tried to disabble some plugins but i don't find where coult be the issue. I also tried to disabble all my snippets but the issue is still here. Do you know any way to find how to know where the issue is ? I love this plugin but it drives me crazy lol.
Thank you for your help.
Hello, thank you for your help.
If you mean custom HTML added directly on the note yes, it happen without custoum html.
But think i spotted with wich plugin the conflict is ! I'v got the plugin "Continuous mode" installed, and when i disable it it seems that the problem goes away ! Do you know any way to solve this ? Thank you very much.
Le ven. 26 avr. 2024 à 23:13, PJ Eby @.***> a écrit :
Does it happen on notes without any custom HTML?
— Reply to this email directly, view it on GitHub https://github.com/nothingislost/obsidian-hover-editor/issues/188#issuecomment-2080125561, or unsubscribe https://github.com/notifications/unsubscribe-auth/AXEBBU3MV2VVXUJGT73NHFLY7K7OLAVCNFSM6AAAAAARYHJY36VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBQGEZDKNJWGE . You are receiving this because you commented.Message ID: @.***>
-- Cordialement. Cheikh N'Diaye
I've not used nor even heard of that plugin before, but after a quick Google search my guess would be that the plugin is responding to the layout change caused by adding the popup. That is, when a Hover Editor opens, it is basically opening a new tab. So if it is noticing that and redrawing in order to make all the tabs work in a continuous flow, it might as a side effect end up scrolling to the top.
Okay, now I've just tried installing it and doing some tests, and it turns out I'm correct - the issue is that the other plugin watches for any changes to the workspace layout (like adding a new tab), and then scrolls the active leaf in continuous mode into view, wherever the cursor is at that point. So if you're seeing a scroll to the very top, it's because that's where your cursor is. If you click somewhere else first, then that's where it'll scroll to instead.
So the fix is for you to either click before hovering , or for the other plugin developer to not do the scrolling. Even though they have an option to disable the scroll, it appears to not actually work. I also tried setting Hover Editor to auto-focus, but this merely delays the scrolling until after the hover editor disappears -- i.e. it scrolls on close of a hover editor instead of on opening.
There is nothing that Hover Editor can do to work around this, since the other plugin is deliberately forcing the scroll to happen. I don't know why they believe the scrolling is actually needed for any change to the workspace layout, as it means if you've intentionally scrolled elsewhere you'll lose your position -- even for things like opening new tabs or even doing things in other windows. Anyway, you'll need to take this up with them I'm afraid.