From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Michael Brand Newsgroups: gmane.emacs.bugs Subject: bug#5018: 23.1.50; Feature request: truncate-lines text property Date: Mon, 5 Jun 2017 11:29:54 +0200 Message-ID: References: <83vaoba80r.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Trace: blaine.gmane.org 1496655077 11715 195.159.176.226 (5 Jun 2017 09:31:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 5 Jun 2017 09:31:17 +0000 (UTC) Cc: 5018@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Jun 05 11:31:11 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dHoLs-0002a5-Vr for geb-bug-gnu-emacs@m.gmane.org; Mon, 05 Jun 2017 11:31:09 +0200 Original-Received: from localhost ([::1]:60454 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dHoLy-0008EL-31 for geb-bug-gnu-emacs@m.gmane.org; Mon, 05 Jun 2017 05:31:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56879) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dHoLr-0008EE-8n for bug-gnu-emacs@gnu.org; Mon, 05 Jun 2017 05:31:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dHoLm-0000SK-G5 for bug-gnu-emacs@gnu.org; Mon, 05 Jun 2017 05:31:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:53793) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dHoLm-0000Rw-Cm for bug-gnu-emacs@gnu.org; Mon, 05 Jun 2017 05:31:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dHoLm-0004tK-4K for bug-gnu-emacs@gnu.org; Mon, 05 Jun 2017 05:31:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Michael Brand Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 05 Jun 2017 09:31:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 5018 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 5018-submit@debbugs.gnu.org id=B5018.149665500318658 (code B ref 5018); Mon, 05 Jun 2017 09:31:02 +0000 Original-Received: (at 5018) by debbugs.gnu.org; 5 Jun 2017 09:30:03 +0000 Original-Received: from localhost ([127.0.0.1]:56469 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dHoKo-0004qk-Gb for submit@debbugs.gnu.org; Mon, 05 Jun 2017 05:30:03 -0400 Original-Received: from mail-qt0-f174.google.com ([209.85.216.174]:32987) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dHoKm-0004q5-Lc for 5018@debbugs.gnu.org; Mon, 05 Jun 2017 05:30:01 -0400 Original-Received: by mail-qt0-f174.google.com with SMTP id u12so54417040qth.0 for <5018@debbugs.gnu.org>; Mon, 05 Jun 2017 02:30:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=97aHaUgnp725JArPRJ3ik/63PB6TKgTfcfFHGtizACE=; b=UZVSpSygryGDatu8r2lkJb8G/UL3jWBXpRVec1f6sTHlpq37KbaVZzCuBxUyIDI/dp MibrnaUuL05rbkdpCCcSd9390Epo4H1uOC5A1yhRTHyayrASzhuQ/kKnOgnYsFJi3jUj 4raZI3tu1a6rH7r8p7WCK2QmWn+fbbokkU2IPzly2yjf6U8ROwBx1hCk8Y5xWoOttOoz KgDpws5q53yspmzTjS1LiJfqI4ZBgzNVJPNfuufmw3r4oHIITUNppMnyhEHHRqGeOXoE P9f57XW+Xn5TvixHB5sH8wCQzNQ+8sl7WTQ1UdU+YypJQ82ihbL9nLUs+F/6BM48IL0V ToBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=97aHaUgnp725JArPRJ3ik/63PB6TKgTfcfFHGtizACE=; b=btMExuLwwmM83TFYwNS7V/Gb+1V5vFDj0clG2lbXKo0ltAQEnw+quhCoerAElxlvzY EeJx+iK/yeYuaOvS0SKnpIWo1Db/h9nvf8jUGWJ3K6sN+Xd+2XzsSj0RaAutYZ+j9NYK 6vSGrRsZQRJ/HCw02JR5Bar0gKQAvh4sBZsnktDqivkbgLYpTAp4bn/sXTWPwzY3qp15 4HOn1KmcB0JQ5LrkZIP9u3b/2qnTjnJjraiJ6brjsJgxm+MSAYrmwTqcN/NX5wTBWZag i0z/mR8YfOrIgHcJ6ELYx67wCsK2wzJgKvR06CPj4Y2noDOFBGGsznI1EwGx1LvDVO0Z t5hQ== X-Gm-Message-State: AODbwcAPzKHC4RTyOiE+ZIxkIjLeB4dCRwwRiVMkhjCvLYPpzE3iksKM XWTdYTxslpAEioBUJ3BN7oZF4r4w8w== X-Received: by 10.200.37.129 with SMTP id e1mr22153916qte.21.1496654994839; Mon, 05 Jun 2017 02:29:54 -0700 (PDT) Original-Received: by 10.12.148.166 with HTTP; Mon, 5 Jun 2017 02:29:54 -0700 (PDT) In-Reply-To: <83vaoba80r.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:133286 Archived-At: Hi Eli Thank you for looking into this and for offering guidance. On Sun, Jun 4, 2017 at 9:05 PM, Eli Zaretskii 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