From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jared Finder Newsgroups: gmane.emacs.devel Subject: Re: "Final" version of tty child frames Date: Thu, 12 Dec 2024 00:11:01 -0500 Message-ID: <5fedec86bce470555814acbdf999f99d@finder.org> References: <86wmi0g0x6.fsf@gnu.org> <11a86987cce9fe0a257c3fa58703dc33@finder.org> <86wmgl6jzv.fsf@gnu.org> <092cb755eee3a9b5e06d15c0b07e90b1@finder.org> <276414b03c24964aaeb9e43e8dba5e77@finder.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20297"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , emacs-devel@gnu.org, rudalics@gmx.at To: =?UTF-8?Q?Gerd_M=C3=B6llmann?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Dec 12 06:12:14 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 1tLbUk-000546-1a for ged-emacs-devel@m.gmane-mx.org; Thu, 12 Dec 2024 06:12:14 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tLbTo-0006ZC-IF; Thu, 12 Dec 2024 00:11:16 -0500 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 1tLbTl-0006Yz-Sd for emacs-devel@gnu.org; Thu, 12 Dec 2024 00:11:13 -0500 Original-Received: from greenhill.hpalace.com ([192.155.80.58]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tLbTj-0000ux-Ua; Thu, 12 Dec 2024 00:11:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=finder.org; s=2018; t=1733980261; bh=AQWineEuot3sjbXT6Ht0ftw5slkqPHKzCmVWV9Lc4Q4=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=MvmGupB5UZ4oShLlM70p3ltBOEjfM/QjhMQiG2yvtYjqpmefMZrpgNS2E6tgR7s1A 54Sw8ys8/Mf4sxaYAuaacG0rkEzRPL2z/4lmfdwzNo9B2Du5Fjt/GB55XXT6rN8FD+ pvHv66m4RJPDD6J01LQ1lqYfwX0E2k30zyETBwf6KiGUO3SfyjUuRp9jszFgKlPXfo sgQmPduwry0PalAat33PbEDISKxE+j3cQ7sEmG94rJWwnv2dARM49yQ9EOL9ePwH8w G0mKPCrChHeEDzuKpmpnRdAFVXqVi6HK26JWmKIISelOtixW5tPBYIvj5OcL2XOe70 KpzaMPwo4DrAw== Original-Received: from mail.finder.org (unknown [192.155.80.58]) by greenhill.hpalace.com (Postfix) with ESMTPSA id 9F51D133B; Thu, 12 Dec 2024 05:11:01 +0000 (UTC) In-Reply-To: X-Sender: jared@finder.org Received-SPF: pass client-ip=192.155.80.58; envelope-from=jared@finder.org; helo=greenhill.hpalace.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, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 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:326396 Archived-At: On 2024-12-11 02:59, Gerd Möllmann wrote: > Jared Finder writes: > >> Spent time just playing with child frames to get familiar with things. >> A few bugs I noticed: > > Nice! > >> There's something in the C code that makes this branch not work with >> the mini-frame package >> (https://github.com/muffinmad/emacs-mini-frame). The package works >> fine in graphical mode. > > The page says that the package is using mini-buffer-only frames, which > are not implemented, because I wasn't interested. See the #if 0 > make_terminal_frame. I think it would be good for unimplemented features to communicate that state to the user so users know clearly what is going on. Right now the error a user sees is "Can’t change the ‘minibuffer’ parameter of this frame". Wouldn't it be better to have make-terminal-frame (a brand new function with no existing clients to support) error with something like "Minibuffer only frames are not supported in terminals"? This also would avoid the bug that currently a minibuffer-only child frame gets left around which looks weird and confusing. Are there any other intentionally unimplemented features? It'd be nice to have similarly clean errors to inform users. >> I'm using posframe for iteration. There's a minor thing where the >> cursor position is inconsistent when at the end of a line with a >> posframe on it in the tty. Maybe that's intentional? It's kinda >> confusing to me. > > Could you please describe in detail what you are doing? I haven't > understood yet. Posframe and Corfu are BTW the reason I added the > child frames. > > Child frames in the more general sense was not so interesting. Always > talking about me personally of course. I think I talked with Martin > about adding stuff as needed if users really want it, or something, and > ISTR he agreed. But Martin can speak for himself :-). This was from me moving the cursor around (just using arrow keys) the text covered up by a child frame. >> There's also a major thing where I can click on the child frame in the >> tty and then my cursor is actually in the child frame and I can just >> alter the text there. That behavior is inconsistent with the behavior >> on graphical displays and something I can investigate. > > Could you please give a recipe? I don't understand yet what you mean. > Or, if you want to investigate, please do :-). Please don't hesitate to > ask me any question. At least I still remember more stuff about this > than about igc :-). This is from me using the mouse while in xterm and clicking on the child frame. Or just hovering over the child frame with mouse-autoselect-window set to t. I'm guessing this is just due to the frame parameter no-accept-focus not being implemented. Since this is a common path for posframe, I think it could be important to implement. Such an implementation probably needs to alter xt-mouse.el's generation of select-window events. To reproduce: (xterm-mouse-mode 1) (posframe-show "*scratch*" :poshandler 'posframe-poshandler-frame-center) Click on the posframe. -- MJF