bug#5018: 23.1.50; Feature request: truncate-lines text property

bug#5018: 23.1.50; Feature request: truncate-lines text property

[Carsten Dominik]

Hi, this is a feature request.

I would like to have a text property `truncate-lines' that can be used
to locally overrule the buffer-local or global value of the
`truncate-lines' variable.

The reason for this is that visual-line-mode and (setq wrap-word t) make
a good environment to allow people to write in  paragraph-oriented way,
but that text documents often contain blocks where line wrapping is
undesirable, such as a table, ASCII drawings, of source code examples.
Org-mode is a good example for a mode where text is intermingled with
these types of structured material.

A truncate-line property would allow a mode to arrange this property to
be set to t for specific lines only and in this way make it possible to get
the best of two worlds in a single buffer.

Thanks for considering it.


- Carsten

bug#5018:

[Michael Brand]

Hi all

I would like to express my serious interest in this. The smaller and
the more mobile the devices become, the more useful this feature seems
to be.

Besides the initial discussion for this feature request here
http://lists.gnu.org/archive/html/emacs-devel/2009-11/msg00883.html
there was a discussion (maybe several?) about this on the Org mode
mailing list here:
http://lists.gnu.org/archive/html/emacs-orgmode/2015-01/msg00640.html

The partial workaround discussed there to narrow a table column is not
really useful as it does not reveal the content when the buffer is
made wide enough, and it does not apply to for instance source code
blocks.

I would like to add that this new feature would have to allow to a)
truncate all lines, b) truncate only the lines with the new text
property or c) not truncate any line.

Michael

bug#5018: 23.1.50; Feature request: truncate-lines text property

[Eli Zaretskii]

> From: Michael Brand <michael.ch.brand@gmail.com>
> Date: Sun, 4 Jun 2017 20:11:51 +0200
> 
> I would like to express my serious interest in this.

Would you like to work on implementing this feature?  I can provide
guidance if needed.

> I would like to add that this new feature would have to allow to a)
> truncate all lines, b) truncate only the lines with the new text
> property or c) not truncate any line.

I would propose to come up with an agreed set of requirements for the
feature.  The original request is quite vague and leaves a lot TBD.
For example:

  . is the override supposed to work in reverse, i.e. when the
    buffer-specific value of truncate-lines is non-nil, but the
    property's value is nil, is it expected that the line with the
    property will wrap instead of being truncated?
  . what text is supposed to have this property to mark the line as
    truncated, and how will Emacs know where the effect of the
    property ends?  e.g., will we require the property to be set on
    the entire line, including the newline, or will it be enough to
    set it only on part of the line?
  . should truncate-partial-width-windows obey this property as well?
  . when point moves along a line which is being truncated, and goes
    outside of the visible portion of the window, how do we want to
    hscroll the text in the window, in those parts that display lines
    which wrap?
  . should we also truncate if this property is on a display string or
    on an overlay string, or only if it's on buffer text?

Needless to say, the more we require from the feature, the harder it
will be to implement correctly.  We should choose wisely.

bug#5018: 23.1.50; Feature request: truncate-lines text property

[Michael Brand]

Hi Eli

Thank you for looking into this and for offering guidance.

On Sun, Jun 4, 2017 at 9:05 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> Would you like to work on implementing this feature?  I can provide
> guidance if needed.

I can try. Maybe too ambitious for me or at least for me alone. I am
new for example to the style of C in Emacs and to the display engine.
And as usual for everybody my time is limited but as I have a need for
this feature since maybe years I could compensate a bit with patience
unless anybody wants to beat me.

> I would propose to come up with an agreed set of requirements for the
> feature.  The original request is quite vague and leaves a lot TBD.
> For example:

These are good points, they show me already some weak points I was
missing.

>   . is the override supposed to work in reverse, i.e. when the
>     buffer-specific value of truncate-lines is non-nil, but the
>     property's value is nil, is it expected that the line with the
>     property will wrap instead of being truncated?

In my opinion first the property only non-nil, nil can be postponed if
it helps.

>   . what text is supposed to have this property to mark the line as
>     truncated, and how will Emacs know where the effect of the
>     property ends?  e.g., will we require the property to be set on
>     the entire line, including the newline, or will it be enough to
>     set it only on part of the line?

The property only on \n looks good at first sight, missing the last
line accepted when without \n. Maybe editing becomes easier when the
property is on the entire line.

Anyway, I don't know if a text property will be the right solution in
the end.

>   . should truncate-partial-width-windows obey this property as well?

In my opinion yes, as soon as the property nil is respected.

>   . when point moves along a line which is being truncated, and goes
>     outside of the visible portion of the window, how do we want to
>     hscroll the text in the window, in those parts that display lines
>     which wrap?

This made me think most.

My first thought was:

Truncate on the left in sync with truncated lines and rewrap on the
right

    :             #################
    :    trunc1 tr#$unc2 trunc3 t$#
    :    wrap1 wra#$p2 wrap3 wrap\#
    :    4 wrap5 w#$rap6 wrap7 wr\#
    :    ap8      #               #
    :             #################

would lower or avoid column-related problems like with rectangle edit
or ruler-mode. On the other hand I hope that changing what is the
buffer bottom line after rewrap would not call for other problems.

But what would it help to wrap on the right when information is
already hidden on the left? So...

My second thought is:

Fall back to truncate all lines

    :             #################
    :    trunc1 tr#$unc2 trunc3 t$#
    :    wrap1 wra#$p2 wrap3 wrap$#
    :    more line#$s             #
    :    even more#$ lines        #
    :             #################

until column 0 becomes visible again is probably much easier, also for
the user to understand what happens.

>   . should we also truncate if this property is on a display string or
>     on an overlay string, or only if it's on buffer text?

It could make sense to wrap an Org mode heading without the property
or nil and truncate as soon as the overlay from Org column view adds
an overlay with the property non-nil. But at first I would say it is
enough to ignore the property on overlays. There should always be a
user choice to truncate everything or noting like now for such
imperfect situations.

Should this discussion move to emacs-devel to reach more developers?

Michael

bug#5018: 23.1.50; Feature request: truncate-lines text property

[Eli Zaretskii]

> From: Michael Brand <michael.ch.brand@gmail.com>
> Date: Mon, 5 Jun 2017 11:29:54 +0200
> Cc: 5018@debbugs.gnu.org
> 
> > Would you like to work on implementing this feature?  I can provide
> > guidance if needed.
> 
> I can try. Maybe too ambitious for me or at least for me alone. I am
> new for example to the style of C in Emacs and to the display engine.
> And as usual for everybody my time is limited but as I have a need for
> this feature since maybe years I could compensate a bit with patience
> unless anybody wants to beat me.

If you decide to try it, I suggest to start by looking at my recent
changes that introduced hscrolling of only the current line.  This
feature should use similar techniques and touch the same places.

> >   . what text is supposed to have this property to mark the line as
> >     truncated, and how will Emacs know where the effect of the
> >     property ends?  e.g., will we require the property to be set on
> >     the entire line, including the newline, or will it be enough to
> >     set it only on part of the line?
> 
> The property only on \n looks good at first sight

The property on a newline makes the preceding line truncated or the
following line?  If the former, than what about the last line in a
buffer that doesn't end in a newline?  Also, looking for the property
in a very long line could slow down redisplay, since it would need to
know about this when it gets to the first character of the line.

> Anyway, I don't know if a text property will be the right solution in
> the end.

What other solution is possible?

> >   . when point moves along a line which is being truncated, and goes
> >     outside of the visible portion of the window, how do we want to
> >     hscroll the text in the window, in those parts that display lines
> >     which wrap?
> 
> This made me think most.
> 
> My first thought was:
> 
> Truncate on the left in sync with truncated lines and rewrap on the
> right
> 
>     :             #################
>     :    trunc1 tr#$unc2 trunc3 t$#
>     :    wrap1 wra#$p2 wrap3 wrap\#
>     :    4 wrap5 w#$rap6 wrap7 wr\#
>     :    ap8      #               #
>     :             #################
> 
> would lower or avoid column-related problems like with rectangle edit
> or ruler-mode. On the other hand I hope that changing what is the
> buffer bottom line after rewrap would not call for other problems.
> 
> But what would it help to wrap on the right when information is
> already hidden on the left? So...
> 
> My second thought is:
> 
> Fall back to truncate all lines
> 
>     :             #################
>     :    trunc1 tr#$unc2 trunc3 t$#
>     :    wrap1 wra#$p2 wrap3 wrap$#
>     :    more line#$s             #
>     :    even more#$ lines        #
>     :             #################
> 
> until column 0 becomes visible again is probably much easier, also for
> the user to understand what happens.

It could well be that the first variant is easier to implement.

> Should this discussion move to emacs-devel to reach more developers?

I'm not sure.  Most if not all of the relevant people read the bug
list as well.  Perhaps post a short message to emacs-devel telling the
interested people to read this discussion either via the bug tracker
or via the bug-gnu-emacs list.

bug#5018: 23.1.50; Feature request: truncate-lines text property

[Michael Brand]

Hi Eli

On Mon, Jun 5, 2017 at 5:42 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> If you decide to try it, I suggest to start by looking at my recent
> changes that introduced hscrolling of only the current line.  This
> feature should use similar techniques and touch the same places.

Thanks for the pointer, looks good for a start.

> The property on a newline makes the preceding line truncated or the
> following line?  If the former, than what about the last line in a
> buffer that doesn't end in a newline?  Also, looking for the property
> in a very long line could slow down redisplay, since it would need to
> know about this when it gets to the first character of the line.

I would agree to set the property on the first char of non-empty
lines.

> What other solution is possible?

Not that I would know. With the knowledge about the internals missing
on my side it looked unnatural in the first place to use a property of
a char for a property related to a line.

> It could well be that the first variant is easier to implement.

Good to know. I just stumbled over the new current-line hscrolling in
the commit log, interesting.

> I'm not sure.  Most if not all of the relevant people read the bug
> list as well.  Perhaps post a short message to emacs-devel telling the
> interested people to read this discussion either via the bug tracker
> or via the bug-gnu-emacs list.

Bug tracker and bug-gnu-emacs list seems OK to me.

Michael

bug#5018: 23.1.50; Feature request: truncate-lines text property

[Eli Zaretskii]

> From: Michael Brand <michael.ch.brand@gmail.com>
> Date: Tue, 6 Jun 2017 21:40:02 +0200
> Cc: 5018@debbugs.gnu.org
> 
> I would agree to set the property on the first char of non-empty
> lines.

OK.

> > What other solution is possible?
> 
> Not that I would know. With the knowledge about the internals missing
> on my side it looked unnatural in the first place to use a property of
> a char for a property related to a line.

We already have similar features, like the line-prefix property.