truncate-lines as newline property

truncate-lines as newline property

[Evgeny Zajcev]

[-- Attachment #1: Type: text/plain, Size: 538 bytes --]

As I understand, truncate-lines is a buffer property, so it applies to
every line in the buffer.

Is it possible with some rather small changes to redisplay make it per
newline property, so you can specify which line to truncate and to which
apply buffer setting?

Here is the example:

(setq truncate-lines nil)
(insert "<very long line>"
          (propertize "\n" 'truncate-lines t))   ; this line will be
truncated
(insert "<another very long line>" "\n")    ; this line will be wrapped

What do you think about this feature?

-- 
lg

[-- Attachment #2: Type: text/html, Size: 940 bytes --]

Re: truncate-lines as newline property

[Eli Zaretskii]

> From: Evgeny Zajcev <lg.zevlg@gmail.com>
> Date: Sun, 10 Mar 2024 21:53:19 +0300
> 
> As I understand, truncate-lines is a buffer property, so it applies to every line in the buffer.
> 
> Is it possible with some rather small changes to redisplay make it per newline property, so you can specify
> which line to truncate and to which apply buffer setting?

Not without serious changes to the display code, specifically to the
code that lays out screen lines and decides what to do when it reaches
the edge of the window.

Also, there's some C code outside of redisplay, and a lot of Lisp code
out there that looks at the buffer-local variable assuming all the
lines behave the same.  If this can be per-line, all that code will
have to be updated.

Any real-life rationale for adding such a feature?

Re: truncate-lines as newline property

[Kévin Le Gouguec]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Evgeny Zajcev <lg.zevlg@gmail.com>
>> Date: Sun, 10 Mar 2024 21:53:19 +0300
>> 
>> As I understand, truncate-lines is a buffer property, so it applies to every line in the buffer.
>> 
>> Is it possible with some rather small changes to redisplay make it per newline property, so you can specify which line to truncate and to which apply buffer setting?
>
> Not without serious changes to the display code, specifically to the
> code that lays out screen lines and decides what to do when it reaches
> the edge of the window.
>
> Also, there's some C code outside of redisplay, and a lot of Lisp code
> out there that looks at the buffer-local variable assuming all the
> lines behave the same.  If this can be per-line, all that code will
> have to be updated.
>
> Any real-life rationale for adding such a feature?

Selectively truncating "classes" of "noisy" lines.

For example, in buffers featuring both free-flowing prose and
pre-formatted text, e.g. a user's guide showcasing code samples, or a
conversation where people alternate between describing symptoms and
dumping backtraces.

In situations where…

* the prose is either filled at a sensible length with hard newlines, or
  completely unfilled and wrapped with visual-line-mode,

* the pre-formatted text has the occasional long line that is longer
  than the window width, but (a) most of the information can be gleaned
  just from the leftmost tokens (b) visual-line-mode wrapping the
  rightmost tokens makes things very confusing¹,

… I wish that I had a way to mark a region and tell Emacs "just truncate
this please".  And I could imagine markup modes (rst-mode,
markdown-mode, org-mode) peppering such a property on constructs where
wrapping is more confusing than helpful, like code blocks or tables.


TBH this is not a big itch for me; just something I've been pondering
from time to time, never going past the stage of "it probably would be a
terrible idea if not downright impossible to make the display engine run
Lisp to answer the question “should this line be truncated”; but maybe
if we spoon-fed the answer in a text property… ?"

Figured I'd throw my 2¢ since this "use-case" sounds distinct from
Evgeny's.


¹ With visual-wrap-prefix-mode, wrapped code snippets are usually not
too confusing; tabular data on the other hand gets unreadable fast.
Taking the example of backtraces: when reading Git forge comment threads
with markdown-mode, most prose is unfilled, so I'll enable
visual-line-mode; but then I'll come across this:

    (gdb) bt
    #0  0x00007ffff7d069ae in write () from ↩
    /lib64/libc.so.6
    #1  0x00007ffff7c8a1cd in               ↩
    _IO_file_write@@GLIBC_2.2.5 () from     ↩
    /lib64/libc.so.6
    #2  0x00007ffff7c882e4 in new_do_write  ↩
    () from /lib64/libc.so.6

… which I wish Emacs would keep truncated to:

    (gdb) bt
    #0  0x00007ffff7d069ae in write () from →
    #1  0x00007ffff7c8a1cd in _IO_file_write→
    #2  0x00007ffff7c882e4 in new_do_write (→

OT1H the latter does hide information; OTOH that information might not
be crucial, and I struggle to read the former, for all its extra
information.

Re: truncate-lines as newline property

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> As I understand, truncate-lines is a buffer property, so it applies to every line in the buffer.
>> 
>> Is it possible with some rather small changes to redisplay make it per newline property, so you can specify
>> which line to truncate and to which apply buffer setting?
> ...
> Any real-life rationale for adding such a feature?

In Org mode, users often ask to disable line wrapping for tables
specifically:

| very wide table with a lot of text in it | is unreadable when wrapped  |
| so                                       | people                      |
| often                                    | want tables to be truncated |

| very wide table with a lot of text in it | is ⏎
unreadable when wrapped  |
| so                                       | peo⏎
ple                      |
| often                                    | want⏎
tables to be truncated |

At the same time, line wrapping in normal paragraphs is expected even
when wide tables are present.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: truncate-lines as newline property

[Rudolf Adamkovič]

Ihor Radchenko <yantar92@posteo.net> writes:

> In Org mode, users often ask to disable line wrapping for tables [...]

+1 and also for source code blocks!

This feature would *significantly* improve Org mode user experience, by
bringing it closer to modern word processing, where tables do not look
like loose leaf tea, of course.

Rudy
-- 
"Great minds discuss ideas; average minds discuss events; small minds
discuss people."  --- Anna Eleanor Roosevelt (1884-1962)

Rudolf Adamkovič <rudolf@adamkovic.org> [he/him]
Studenohorská 25, 84103 Bratislava, Slovakia, European Union

Re: truncate-lines as newline property

[Eli Zaretskii]

> From: Evgeny Zajcev <lg.zevlg@gmail.com>
> Date: Sun, 10 Mar 2024 21:53:19 +0300
> 
> (setq truncate-lines nil)
> (insert "<very long line>"
>           (propertize "\n" 'truncate-lines t))   ; this line will be truncated
> (insert "<another very long line>" "\n")    ; this line will be wrapped

Btw, this specification would mean that redisplay needs to go all the
way to the newline to know what to do when a screen line exceeds the
window width, which could happen long before the newline is rendered.
This is completely against the current design of the display engine,
which tries very hard not to examine any characters except those it
needs to display.  So a better design would be to have the special
text property on the first character of a line, the one that _follows_
the newline, so as to make sure the display code knows whether or not
to truncate as soon as it needs to make that decision.

Re: truncate-lines as newline property

[Evgeny Zajcev]

[-- Attachment #1: Type: text/plain, Size: 2077 bytes --]

вс, 10 мар. 2024 г. в 22:39, Eli Zaretskii <eliz@gnu.org>:

> > From: Evgeny Zajcev <lg.zevlg@gmail.com>
> > Date: Sun, 10 Mar 2024 21:53:19 +0300
> >
> > (setq truncate-lines nil)
> > (insert "<very long line>"
> >           (propertize "\n" 'truncate-lines t))   ; this line will be
> truncated
> > (insert "<another very long line>" "\n")    ; this line will be wrapped
>
> Btw, this specification would mean that redisplay needs to go all the
> way to the newline to know what to do when a screen line exceeds the
> window width, which could happen long before the newline is rendered.
> This is completely against the current design of the display engine,
> which tries very hard not to examine any characters except those it
> needs to display.  So a better design would be to have the special
> text property on the first character of a line, the one that _follows_
> the newline, so as to make sure the display code knows whether or not
> to truncate as soon as it needs to make that decision.
>

Or maybe even propertize the whole line with truncate-lines property, so
redisplay could examine any char on the line.

As to side packages utilizing value of the truncate-lines, we can make
(defun truncate-lines-p (position) ...) function for future packages.  Old
packages that uses truncate-lines might work partially correctly for the
buffers with per-line truncate-lines, and this is ok I think.

Real life example for this feature is next.  We have image with two line
height and display it in the buffer next way:
<img slice 1><not very important text following first image slice, but may
be long, it can be truncated>
<img slice 2><very important long text following second slice that need to
be wrapped>

If the first line fits into the window's width, then image slices form the
correct image without gaps, however, if the first line does not fit into
window width it wraps, making a gap between slices.  If we make first line
to be truncated everything will look nice even if first line does not fit

-- 
lg

[-- Attachment #2: Type: text/html, Size: 2789 bytes --]