From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: feature/icomplete-vertical Date: Mon, 05 Oct 2020 22:30:17 +0300 Message-ID: <83sgasbhdi.fsf@gnu.org> References: <83lfh4zfml.fsf@gnu.org> <838sd4z6lz.fsf@gnu.org> <20201001164804.mqqyxtet4ttweuyv@Ergus> <83blhhdy3w.fsf@gnu.org> <87d01xghmt.fsf@gmail.com> <83sgatc8er.fsf@gnu.org> <83mu11c78j.fsf@gnu.org> <87tuv9eygk.fsf@gmail.com> <83k0w5c4yt.fsf@gnu.org> <87mu10gbjs.fsf@gmail.com> <83h7r8dhfv.fsf@gnu.org> <87a6x0ga5v.fsf@gmail.com> <83ft6sdgjq.fsf@gnu.org> <875z7og6ti.fsf@gmail.com> <83a6x0dcup.fsf@gnu.org> <871ricfqbf.fsf@gmail.com> <83wo04bi6t.fsf@gnu.org> <87r1qceb0l.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16719"; mail-complaints-to="usenet@ciao.gmane.io" Cc: ghe@sdf.org, spacibba@aol.com, juri@linkov.net, casouri@gmail.com, emacs-devel@gnu.org To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Oct 05 21:31:38 2020 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 1kPWCv-0004E2-NO for ged-emacs-devel@m.gmane-mx.org; Mon, 05 Oct 2020 21:31:37 +0200 Original-Received: from localhost ([::1]:43762 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kPWCu-00074B-Nn for ged-emacs-devel@m.gmane-mx.org; Mon, 05 Oct 2020 15:31:36 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52588) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kPWBm-0006QR-2i for emacs-devel@gnu.org; Mon, 05 Oct 2020 15:30:26 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:36865) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kPWBl-0004S6-57; Mon, 05 Oct 2020 15:30:25 -0400 Original-Received: from [176.228.60.248] (port=4065 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kPWBc-0000PG-Cf; Mon, 05 Oct 2020 15:30:18 -0400 In-Reply-To: <87r1qceb0l.fsf@gmail.com> (message from =?utf-8?B?Sm/Do28g?= =?utf-8?B?VMOhdm9yYQ==?= on Mon, 05 Oct 2020 20:19:22 +0100) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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" Xref: news.gmane.io gmane.emacs.devel:257143 Archived-At: > From: João Távora > Cc: ghe@sdf.org, spacibba@aol.com, emacs-devel@gnu.org, > casouri@gmail.com, juri@linkov.net > Date: Mon, 05 Oct 2020 20:19:22 +0100 > > Eli Zaretskii writes: > > >> From: João Távora > >> Cc: ghe@sdf.org, spacibba@aol.com, emacs-devel@gnu.org, > >> casouri@gmail.com, juri@linkov.net > >> Date: Mon, 05 Oct 2020 20:03:32 +0100 > >> > >> >> I think the easiest way to make this function is to give it a buffer > >> >> where text exists as buffer text and truncate-lines is what it it. Then > >> >> it can say exactly where it _would_ cut off. > >> > > >> > That doesn't work for displaying text with continuation lines, does > >> > it? > >> > >> I'm not sure what you mean. Maybe? Can you provide an example? The > >> idea is to use this buffer to "stage" what needs to be displayed, and > >> gather guiding information from that, not necessarily to _do_ that > >> displaying on that particular "stage". > > > > If the real buffer will be displayed without truncating lines, then > > each physical line might take more than one screen line. You need to > > account for that when you decide where to truncate. > > Yes, but presumably, the (vapourware) function we are talking about > would interpret the value of truncate-lines "in the stage", and you'd > set that to the same value that you plan to use in the "real buffer". I guess I misunderstand your original proposal: did you mean to leave truncate-lines at its value in the window where the text will be displayed? If so, that's OK, but then why did you mentioned that variable? there are many more that affect the display, and they all should be left at their values in the window. In a nutshell, the function we are discussing should get the window in which the text will be displayed as the argument, so that its layout calculations are accurate. The code should be very similar to window-text-pixel-size, just the stop condition should be different.