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: Implementing child frames on terminal Date: Wed, 13 Jul 2022 21:11:32 +0300 Message-ID: <83leswvq5n.fsf@gnu.org> References: <87czfxu7be.fsf@disroot.org> <874k19tya1.fsf@disroot.org> <83h759lb6f.fsf@gnu.org> <87tu99s860.fsf@disroot.org> <838rqklurd.fsf@gnu.org> <87tu7n10hr.fsf@disroot.org> <87h73mykv6.fsf@yahoo.com> <87h73m20fg.fsf@disroot.org> <83o7xuxyc0.fsf@gnu.org> <874jzm1kfl.fsf@disroot.org> <8335f6xrjo.fsf@gnu.org> <87bkttytdb.fsf@disroot.org> <83y1wxuhsi.fsf@gnu.org> <877d4gzyma.fsf@disroot.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23209"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org, ibluefocus@outlook.com To: Akib Azmain Turja Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jul 13 20:12:33 2022 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 1oBgqf-0005v2-Od for ged-emacs-devel@m.gmane-mx.org; Wed, 13 Jul 2022 20:12:33 +0200 Original-Received: from localhost ([::1]:53542 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oBgqe-000796-Qf for ged-emacs-devel@m.gmane-mx.org; Wed, 13 Jul 2022 14:12:32 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36864) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oBgpp-0006Sk-Mx for emacs-devel@gnu.org; Wed, 13 Jul 2022 14:11:41 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:55160) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oBgpp-0006cc-7P; Wed, 13 Jul 2022 14:11:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=F3Ek7t1U3x51CJrhLa6O9Z0ynk9H2R0ogcXvdQczj2U=; b=FU+cgGw3XDgO i89RnrbxhWpl7vd55dBeTb+BFNpnEwq9iLbcbPg15i2VFPTxXcajxWjEM8vMtobNlJ3BsijCJQOSH WNUcbWfCPtFcGhxDMQQbBzfMU0c7awWVZtFxxokdXEPFqo6NKUH3FSea5+q3bUdTo1KNvTxsAJLya U+uqE7ichHDFnZaBSWnl2SDFfq3/pgEnrQzPNqKe5Uuc+S31dU+tXqoEUd45weScgoRy/pxHghcls oo1mu5IS4ebdQwgLxCV11QOnuF9Ha76KKKtLtC/rbjvXwp8i7PZRXylJgzBzdCc4HPYtQJU5HhiO9 WpHTVfrGOoIC3jxGM3Pjpg==; Original-Received: from [87.69.77.57] (port=2022 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oBgpo-0001c8-MY; Wed, 13 Jul 2022 14:11:41 -0400 In-Reply-To: <877d4gzyma.fsf@disroot.org> (message from Akib Azmain Turja on Wed, 13 Jul 2022 23:55:09 +0600) 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" Xref: news.gmane.io gmane.emacs.devel:292108 Archived-At: > From: Akib Azmain Turja > Cc: luangruo@yahoo.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org, > ibluefocus@outlook.com > Date: Wed, 13 Jul 2022 23:55:09 +0600 > > > You mean, the display margins? If that is the problem that bothers > > you, then yes, the functions in dispnew.c that calculate the > > dimensions of each window will have to take the clipping into account. > > And again, this calculation happens just once, in the beginning of a > > redisplay cycle, and only if needed (i.e. only when the previously > > calculated dimensions no longer fit). > > > > But last_visible_x will still need to be adjusted as I outlined, > > I don't think so. I tried to hard-code last_visible_x to 40. Then I > compiled and started Emacs and found that the lines of *scratch* buffer > wrapped at 39th column (and the 40th column being the continuation > glyph). Right. You just discovered that setting last_visible_x is not the only thing that should be done. But I never said it's the only thing, just that it is _one_ thing that needs to be done. Changing the code which produces the continuation/truncation glyphs to support child frames is not hard, but it does need some coding. And there really is no way around that, because that's how Emacs display works. Remember: this all came out of discussions about the design of child frames on TTY displays, where you expressed doubt that we could easily "clip" child frames where needed. But that basic design is just the beginning; there's more to this than meets the eye. > It seems that line numbers are also unaffected by that > last_visible_x. Yes, they are. From maybe_produce_line_number: /* We must leave space for 2 glyphs for continuation and truncation, and at least one glyph for buffer text. */ int width_limit = tem_it.last_visible_x - tem_it.first_visible_x - 3 * FRAME_COLUMN_WIDTH (it->f); [...] PRODUCE_GLYPHS (&tem_it); /* Stop producing glyphs, and refrain from producing the line number, if we don't have enough space on this line. */ if (tem_it.current_x >= width_limit) { it->lnum_width = 0; it->lnum_pixel_width = 0; bidi_unshelve_cache (itdata, false); inhibit_free_realized_faces = save_free_realized_faces; return; } > > Why produce glyphs that will never get written to the glass? It's > > just a waste of cycles. And it isn't for free: we'd need to have code > > that checks whether a glyph should or shouldn't be written to the > > screen, because writing it outside of the terminal could have bad > > effects. > > IIUC, we won't need additional code. Because those garbage glyphs are > outside of the frame's glyph matrix, so the terminal display code won't > notice them at all. > > I think we are all trying to do premature optimization. Do we bother > whether a character is clipped on X? On X, the clipping is a given. But on text-mode terminal there's no clipping: if you write one character too many on a line, it will generally wrap to the next line. > Or is there any real reason to optimize? It isn't an optimization, it's safe coding.