On Thu, Oct 5, 2017 at 4:11 AM martin rudalics <rudalics@gmx.at> wrote:

>  > The screenshots attached in my previous email show the truncation arrows
>  > with/without scrollbars.. they look the same in both cases to me (see
>  > below, without scrollbars on left, and with, on right):
>  >
>  > I am using diff-hl-mode because the truncation is very evident as you
> see
>  > in that same image.
>  >
>  > [image: image.png]
>
> Unfortunately, I don't see any image here.
>

I think that's partially responsible for some miscommunication between us.
debbugs doesn't show the images inline in the messages (as I see them in
Google Inbox when I am sending the emails). debbugs instead just creates an
attachment named image.png for each inline image.

In a later email, you mention that you can see the above reference image,
but just for clarity, this is the one:
https://debbugs.gnu.org/cgi/bugreport.cgi?att=2;msg=17;bug=27830;filename=image.png


>  > Oh no, can this be please fixed in emacs 26.1? I am pretty sure that
> people
>  > using emacs without scroll bars and without window dividers are not in
>  > minority. This artifact will be pretty evident to people using fringe
>  > elements like in diff-hl-mode.
>  >
>  > @Eli: Can this be a blocker for 26.1?
>
> This behavior has been with us ever since the vertical border has been
> used for GUI frames so it hardly qualifies as a blocker for the release.
>

I understand. I thought this was a regression in 26, because I started
using the native line number implementation.

Earlier (in emacs 25), when using nlinum, this was the order of window
elements:

    | line num | fringe | window text | ..

In emacs 26, when using native line numbers, this became the order of
window elements:

    | fringe | line num | window text | ..

So the issue was essentially masked earlier if you were using line numbers
using (n)linum.

I confirm that this issue was in emacs 25.1 too. Sorry for the drastic
measure suggestion.
-- 

Kaushal Modi