unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Michael Brand <michael.ch.brand@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 5018@debbugs.gnu.org
Subject: bug#5018: 23.1.50; Feature request: truncate-lines text property
Date: Mon, 5 Jun 2017 11:29:54 +0200	[thread overview]
Message-ID: <CALn3zoj8xJc+pQv_Qa9PMEgS75on7X3=c=TG9K-7Gh0XATmGKQ@mail.gmail.com> (raw)
In-Reply-To: <83vaoba80r.fsf@gnu.org>

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	other threads:[~2017-06-05  9:29 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-23 10:33 bug#5018: 23.1.50; Feature request: truncate-lines text property Carsten Dominik
2017-06-04 18:11 ` bug#5018: Michael Brand
2017-06-04 19:05   ` bug#5018: 23.1.50; Feature request: truncate-lines text property Eli Zaretskii
2017-06-05  9:29     ` Michael Brand [this message]
2017-06-05 15:42       ` Eli Zaretskii
2017-06-06 19:40         ` Michael Brand
2017-06-07  4:53           ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CALn3zoj8xJc+pQv_Qa9PMEgS75on7X3=c=TG9K-7Gh0XATmGKQ@mail.gmail.com' \
    --to=michael.ch.brand@gmail.com \
    --cc=5018@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).