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

A question: "dead" margin on the left and right side of an editor pane #117

Open
Randy-Astle opened this issue Jul 31, 2022 · 2 comments
Open

Comments

@Randy-Astle
Copy link

Randy-Astle commented Jul 31, 2022

My question may not be relevant to the SlidingPanes plugin, but I suspect you will understand the underlying cause and be able to provide some direction.

There is a margin on the left and right of an editor pane that seems "dead" for lack of a better word. If I click in this margin, the focus shifts to that editor pane, but the caret is inactive. (I have Vim key bindings enabled.) If the editor is in normal mode, the cursor is solid and non-blinking and non-responsive. If the editor is in insert mode, the caret disappears, and typing doesn't insert text.

I have to click again farther into the editor pane before the cursor starts to blink and respond to commands.

If Leaf Auto Width is enabled, these margins are quite wide. If I disabled Leaf Auto Width and set Leaf Width on Desktop to 850, I can minimize the width of the margins, but I can't eliminate them.

Is there a way to configure Obsidian or Sliding Panes to enable editing if the pane is clicked in one of these margins? Or perhaps, pressing the ESC key will put the pane into editing mode?

A different point: it would be handy if the note title is being edited (or just has the focus because I clicked on it), to shift to editing the note by pressing ESC.

Thanks,

Randy

@colintedford
Copy link

colintedford commented Sep 5, 2022

I think this has to do with how Obsidian (and/or it's themes) has structured its HTML and CSS (Obsidian is, kind of, a very fancy webpage packaged as an app). I think whatever the maximum text width is, is also the maximum width of the editable area. Outside of that is just margin or another div or something that's considered a different part. My explanation might not be totally right but I think it's along those lines. The question has come up in the forum before. I don't remember the discussion but you can search for it.

This might be correctable by theme or CSS snippet. But before exploring that you might want to wait for the new default theme (it's already in the Insider builds) so you don't have to redo things (plus the new theme is intended to be easier to tinker with).

You might try tinkering with settings. The Minimal Settings plugin (used by Minimal Theme and maybe some others) has a few line length settings that could perhaps be adjusted in combination to fix the problem. I suspect that if that works at all it probably comes with annoying trade offs.

@asteriskCat
Copy link

Did this ever get resolved? My snap-store updated Obsidian (15.9) and its plugins today, and this makes Obsidian practically unusable now. It's hiding pane spines so they can't be accessed unless you use the horizontal scroll bar and leaving empty spaces. If I mess with Leaf width on manual, I can get it to work most of the time (there's probably a single number that is right for a certain number of open panes), but as soon as I open/close the explore/search panel, it falls apart again. It seems the formula for how big the window and panes are is wrong in the leaf width setting.

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

No branches or pull requests

3 participants