bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Michael Brand
Subject: bug#5018: 23.1.50; Feature request: truncate-lines text property
Date: Mon, 5 Jun 2017 11:29:54 +0200

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]