zero-width line continuation glyph

zero-width line continuation glyph

[Robert Pluim]

Hi,

Iʼm trying to get the line continuation character to not be shown for
lines that are exactly as long as the window width. In a GUI frame,
with the fringe turned off, I can do:

(let ((disptab (or buffer-display-table
                   (setq buffer-display-table (make-display-table)))))
    (set-display-table-slot disptab 'wrap (gethash "ZERO WIDTH SPACE" (ucs-names))))

which causes the '\' to not be shown, but the next character does not
get displayed in its place, ie

0123456789
xxxxxxxxxx\
x

gets transformed to

0123456789
xxxxxxxxxx
x

In emacs -nw, the behaviour is different:

0123456789
xxxxxxxxxx\
x

gets transformed to

0123456789
xxxxxxxxxxx

which is what I want, but then any characters I add to the end of that line are not
displayed at all.

Thanks

Robert

Re: zero-width line continuation glyph

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Date: Tue, 11 Sep 2018 13:58:55 +0200
> 
> Iʼm trying to get the line continuation character to not be shown for
> lines that are exactly as long as the window width. In a GUI frame,
> with the fringe turned off, I can do:
> 
> (let ((disptab (or buffer-display-table
>                    (setq buffer-display-table (make-display-table)))))
>     (set-display-table-slot disptab 'wrap (gethash "ZERO WIDTH SPACE" (ucs-names))))
> 
> which causes the '\' to not be shown, but the next character does not
> get displayed in its place, ie

ZERO WIDTH SPACE by default is displayed as a 1-pixel thin space, so I
think you will have to tweak glyphless-char-display-control to display
that character as nothing, to get what you want.  Otherwise, the 1
pixel less space left on the line is not enough for Emacs to display
another character.

> In emacs -nw, the behaviour is different:
> 
> 0123456789
> xxxxxxxxxx\
> x
> 
> gets transformed to
> 
> 0123456789
> xxxxxxxxxxx
> 
> which is what I want, but then any characters I add to the end of that line are not
> displayed at all.

Since TTYs cannot display thin characters, the above sounds like a bug
to me.  But again, without tweaking glyphless-char-display-control,
what you want cannot happen (if at all).

Re: zero-width line continuation glyph

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Date: Tue, 11 Sep 2018 13:58:55 +0200
> 
> Iʼm trying to get the line continuation character to not be shown for
> lines that are exactly as long as the window width. In a GUI frame,
> with the fringe turned off, I can do:
> 
> (let ((disptab (or buffer-display-table
>                    (setq buffer-display-table (make-display-table)))))
>     (set-display-table-slot disptab 'wrap (gethash "ZERO WIDTH SPACE" (ucs-names))))
> 
> which causes the '\' to not be shown, but the next character does not
> get displayed in its place, ie

Actually, I'm not sure this will work at all, because Emacs needs a
place to put the cursor at EOL.  So it cannot put a character there,
because without a fringe, there's no place to display the cursor.

I think you will have a much better approximation of what you want if
you keep the fringe, but make it 1-pixel wide.

Re: zero-width line continuation glyph

[Robert Pluim]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Robert Pluim <rpluim@gmail.com>
>> Date: Tue, 11 Sep 2018 13:58:55 +0200
>> 
>> Iʼm trying to get the line continuation character to not be shown for
>> lines that are exactly as long as the window width. In a GUI frame,
>> with the fringe turned off, I can do:
>> 
>> (let ((disptab (or buffer-display-table
>>                    (setq buffer-display-table (make-display-table)))))
>>     (set-display-table-slot disptab 'wrap (gethash "ZERO WIDTH SPACE" (ucs-names))))
>> 
>> which causes the '\' to not be shown, but the next character does not
>> get displayed in its place, ie
>
> Actually, I'm not sure this will work at all, because Emacs needs a
> place to put the cursor at EOL.  So it cannot put a character there,
> because without a fringe, there's no place to display the cursor.

Youʼre right: customizing glyphless-char-display-control to
zero-width for 'format-control' makes no difference.

> I think you will have a much better approximation of what you want if
> you keep the fringe, but make it 1-pixel wide.

Unfortunately emacs -nw has no fringes.

Robert

Re: zero-width line continuation glyph

[Robert Pluim]

Eli Zaretskii <eliz@gnu.org> writes:

>> In emacs -nw, the behaviour is different:
>> 
>> 0123456789
>> xxxxxxxxxx\
>> x
>> 
>> gets transformed to
>> 
>> 0123456789
>> xxxxxxxxxxx
>> 
>> which is what I want, but then any characters I add to the end of that line are not
>> displayed at all.
>
> Since TTYs cannot display thin characters, the above sounds like a bug
> to me.  But again, without tweaking glyphless-char-display-control,
> what you want cannot happen (if at all).

Even with glyphless-char-display-control tweaked for 'format-control',
I get the same behaviour.

Robert

Re: zero-width line continuation glyph

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Tue, 11 Sep 2018 14:51:32 +0200
> 
> > I think you will have a much better approximation of what you want if
> > you keep the fringe, but make it 1-pixel wide.
> 
> Unfortunately emacs -nw has no fringes.

Is -nw so important that it must be part of the solution?  It should
be easier to make the window slightly wider, no?

More radical solutions will need changes on the C level, I think.

Re: zero-width line continuation glyph

[Robert Pluim]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Robert Pluim <rpluim@gmail.com>
>> Cc: emacs-devel@gnu.org
>> Date: Tue, 11 Sep 2018 14:51:32 +0200
>> 
>> > I think you will have a much better approximation of what you want if
>> > you keep the fringe, but make it 1-pixel wide.
>> 
>> Unfortunately emacs -nw has no fringes.
>
> Is -nw so important that it must be part of the solution?  It should
> be easier to make the window slightly wider, no?
>

It would be nice if the same mechanism worked for both, but itʼs not
mandatory.

> More radical solutions will need changes on the C level, I think.

Itʼs not a big problem, I was just intrigued by the
possibilities. Getting d-s-m sorted out is more important :-)

Thanks

Robert