From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Evgeny Zajcev Newsgroups: gmane.emacs.devel Subject: Re: truncate-lines as newline property Date: Sun, 10 Mar 2024 23:21:21 +0300 Message-ID: References: <86le6pvpv5.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000cc87430613542b2d" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19581"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Mar 10 21:22:29 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rjPgi-0004pE-Je for ged-emacs-devel@m.gmane-mx.org; Sun, 10 Mar 2024 21:22:28 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rjPfv-0005WP-1K; Sun, 10 Mar 2024 16:21:39 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rjPft-0005W3-3M for emacs-devel@gnu.org; Sun, 10 Mar 2024 16:21:37 -0400 Original-Received: from mail-pl1-x636.google.com ([2607:f8b0:4864:20::636]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rjPfr-0004PX-Em; Sun, 10 Mar 2024 16:21:36 -0400 Original-Received: by mail-pl1-x636.google.com with SMTP id d9443c01a7336-1dca3951ad9so30274505ad.3; Sun, 10 Mar 2024 13:21:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1710102093; x=1710706893; darn=gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=gEtrRvk7RmMmTiqi+M2/mV21ALsA3zbg1kc8SJWpy68=; b=l6fXjMyNrGbOHig2rVXm7vKB1a0Ubkr/y+itaPy2/Ro7Bkck4kcYllsDtQgZeZx3dt bgCa1rGjb0IVz6KiE5b9XTvabBR1Tzb3tL+3WNHMLmnjYrcwRuybmvFn26eq7Wn07X0e px/00lLxva3QuCTxwOxuqV1g4C9whKAToVJHK/IZYPkOiO7CQlbhy9qk7mOkyfGa7qOY hp/T4BqeG04uJEmXRovWoWRtaFUsxO9tL3hGylp4edU6Lt14qYRBO/4bfg2Y0HzDoxkw Ce7RxUMjhp5RM1NXuyMyNLoaJVl3SmFS6eZZP78O79JPVqWxgXgpyhub3hASjW0HFK4N FpNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710102093; x=1710706893; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=gEtrRvk7RmMmTiqi+M2/mV21ALsA3zbg1kc8SJWpy68=; b=mIO/fQxWvtgmywROoMuXFOjdpKeRagTPKEkcYScFdzp5O5eCtsIUzVjEqez1hpWCuG rhk3gJvl9c6u3nFjnnTDrg79LiH78qIy6gUcaMtni2zbz7qY8YGcerFYIz6n0Qt9DvDK BaVIZWK5NKs+RZzPelKf88y+bYbyjyhtgdZvyVF5dnh2Y2CWh4sJ7EPDokqZjIEQmEUA n79Pgaqt2AchFhVDX+m9mWz5OUHw7sMLRMkZn+Q851+kQdpJ6X25YzKa5h4C2lOjaYBn oWmqjP+K6rT4vNiRJuzOEb6OpUAEhN0Wr/17AeCpAJMrPJKhqMm4EkVP/PxBU1wRrfCH 5cOA== X-Gm-Message-State: AOJu0Yx/U0BEWGPnTexqFZ67jjBc48VVLNe7Gh94YXuxoRNnhii80b2H rP2EIgGRCsbh7XQMzTFJu7AWBmOIlfrWxIbt3zxE4IYLBJw7GHN/TymVSLVAy4nhFBN4y6GRczn tPG2iL/rehmfPZf+31CmAsHexMVmQljnX X-Google-Smtp-Source: AGHT+IHGnBHj0BfcQZPkH3vUvU3Q5IK9uCYvAZ80Q8ZsWTIwuMPgNyI5UfY6cOh/X5ikKKCDTzPHO4tWLQWjIy62GpQ= X-Received: by 2002:a17:903:2282:b0:1dc:540f:c5eb with SMTP id b2-20020a170903228200b001dc540fc5ebmr6124378plh.51.1710102093266; Sun, 10 Mar 2024 13:21:33 -0700 (PDT) In-Reply-To: <86le6pvpv5.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::636; envelope-from=lg.zevlg@gmail.com; helo=mail-pl1-x636.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:316985 Archived-At: --000000000000cc87430613542b2d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =D0=B2=D1=81, 10 =D0=BC=D0=B0=D1=80. 2024=E2=80=AF=D0=B3. =D0=B2 22:39, Eli= Zaretskii : > > From: Evgeny Zajcev > > Date: Sun, 10 Mar 2024 21:53:19 +0300 > > > > (setq truncate-lines nil) > > (insert "" > > (propertize "\n" 'truncate-lines t)) ; this line will be > truncated > > (insert "" "\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: 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 --=20 lg --000000000000cc87430613542b2d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=D0=B2=D1=81, 1= 0 =D0=BC=D0=B0=D1=80. 2024=E2=80=AF=D0=B3. =D0=B2 22:39, Eli Zaretskii <= eliz@gnu.org>:
> Fro= m: Evgeny Zajcev <lg.zevlg@gmail.com>
> Date: Sun, 10 Mar 2024 21:53:19 +0300
>
> (setq truncate-lines nil)
> (insert "<very long line>"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(propertize "\n" = 9;truncate-lines t))=C2=A0 =C2=A0; this line will be truncated
> (insert "<another very long line>" "\n")=C2= =A0 =C2=A0 ; 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.=C2=A0 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 th= e whole line with truncate-lines property, so redisplay could examine any c= har on the line.

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

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

If t= he 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 wi= ndow width it wraps, making a gap between slices.=C2=A0 If we make first li= ne to be truncated everything will look nice even if first line does not fi= t

--
lg
--000000000000cc87430613542b2d--