The inexplicable right fringe

[wymmij]

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]

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]

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]

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]

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]

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]

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.