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

The inexplicable right fringe #276

Open
wymmij opened this issue Apr 15, 2024 · 6 comments
Open

The inexplicable right fringe #276

wymmij opened this issue Apr 15, 2024 · 6 comments

Comments

@wymmij
Copy link

wymmij commented Apr 15, 2024

Despite having both fringes set to 0 there appears always to be a right fringe of about 10 pixels in width, and no matter what I do I can't eliminate it.
I'm a long time user of pdf-tools but it was only recently when I inadvertently switched on pdf-view-midnight-minor-mode that I noticed this issue for the first time.

Any ideas what could be causing this?

@aikrahguzar
Copy link

Despite having both fringes set to 0 there appears always to be a right fringe of about 10 pixels in width, and no matter what I do I can't eliminate it. I'm a long time user of pdf-tools but it was only recently when I inadvertently switched on pdf-view-midnight-minor-mode that I noticed this issue for the first time.

Any ideas what could be causing this?

What you see is not the fringe but rather the space Emacs has reserved to display continuation glyphs. See the description of no-special-glyphs in the info node (elisp) Layout Parameters. You are better off setting the fringes to 1.

@wymmij
Copy link
Author

wymmij commented Jul 10, 2024

What you see is not the fringe but rather the space Emacs has reserved to display continuation glyphs. See the description of no-special-glyphs in the info node (elisp) Layout Parameters. You are better off setting the fringes to 1.

Thank you! Indeed the no-special-glyphs frame parameter was precisely what I was seeing.

Would there be any good reason for not setting this frame parameter to true though? It doesn't seem necessary to me in pdf buffers. Having said that, I can't think of a good reason for having fringes in pdf buffers either, since they're never used by pdf-view-mode as far as I'm aware.

@aikrahguzar
Copy link

Would there be any good reason for not setting this frame parameter to true though? It doesn't seem necessary to me in pdf buffers. Having said that, I can't think of a good reason for having fringes in pdf buffers either, since they're never used by pdf-view-mode as far as I'm aware.

This is a frame parameter so it has to be set for the whole frame and not just pdf buffers. The manual clearly states that it shouldn't be set non-nil for frames on which cursor is displayed and seems to be meant just for tooltips. I have had problems with scrolling on setting it to t. You can try and see what happens. But setting the fringe width to 1 is the safer idea. I don't think you will notice the 2 pixels this takes up.

@wymmij
Copy link
Author

wymmij commented Jul 10, 2024

This is a frame parameter so it has to be set for the whole frame and not just pdf buffers. The manual clearly states that it shouldn't be set non-nil for frames on which cursor is displayed and seems to be meant just for tooltips. I have had problems with scrolling on setting it to t. You can try and see what happens. But setting the fringe width to 1 is the safer idea. I don't think you will notice the 2 pixels this takes up.

Okay, I've set no-special-glyphs frame parameter to t and I'll be on the lookout for problems. None so far, mind.

If this is going to be a problem for me though, I would expect to find out quickly. This is because I use EXWM but with only one ‘workspace’, which means that I effectively only have a single frame. I then use tab-bar-mode tabs (window configurations) to achieve the same functional effect as having multiple workspaces. So setting a frame parameter with my set-up is in effect everywhere. Generally, this works perfectly well for me, but there has been ‘friction’ caused due to different modes' use of fringes. In particular, it's the EXWM windows where the fringe is not only redundant, it looks really quite ugly when it's present. Needless to say though, this really isn't a big deal.

Anyway, thank you very much for pointing out the no-special-glyphs frame parameter. I vaguely recall reading about it before in the elisp manual, but I just never made the connection between it and what I was mistakenly accusing of being the right fringe.

@aikrahguzar
Copy link

I noticed that the Info manual on machine with Emacs 29.4 had a warning that was missing in the webpage on gnu website I linked to. I was add as a result of this bug https://lists.gnu.org/archive/html/bug-gnu-emacs/2024-05/msg01504.html so you can read about some of the problems you might encounter there.

@wymmij
Copy link
Author

wymmij commented Jul 10, 2024

I noticed that the Info manual on machine with Emacs 29.4 had a warning that was missing in the webpage on gnu website I linked to. I was add as a result of this bug https://lists.gnu.org/archive/html/bug-gnu-emacs/2024-05/msg01504.html so you can read about some of the problems you might encounter there.

Thank you very much for pointing me towards the bug thread.

For me, the cursor doesn't disappear but is about half it's usual width - although given the width of the screen the cursor simply occupied the remaining width it possibly could, which just happened to be about half its usual width.

In any case, I fortunately haven't experienced any problematic behaviour so far, even in the cases described in that thread's discussion.

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

2 participants