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: Tue, 06 Oct 2020 09:16:23 +0300 Message-ID: <83r1qbc214.fsf@gnu.org> References: <20201001164804.mqqyxtet4ttweuyv@Ergus> <83blhhdy3w.fsf@gnu.org> <87d01xghmt.fsf@gmail.com> <83sgatc8er.fsf@gnu.org> <83mu11c78j.fsf@gnu.org> <87tuv9eygk.fsf@gmail.com> <87imbogb6k.fsf@gmail.com> <83eemcdgg2.fsf@gnu.org> <83d01wdf8p.fsf@gnu.org> <838sckdby8.fsf@gnu.org> <87v9foeb8p.fsf@gmail.com> <83v9fobhmo.fsf@gnu.org> <87mu10eaet.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="1244"; 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 Tue Oct 06 08:17:18 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 1kPgHl-0000Ct-Jy for ged-emacs-devel@m.gmane-mx.org; Tue, 06 Oct 2020 08:17:17 +0200 Original-Received: from localhost ([::1]:42502 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kPgHk-0004Si-NR for ged-emacs-devel@m.gmane-mx.org; Tue, 06 Oct 2020 02:17:16 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52864) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kPgGu-0003zs-3j for emacs-devel@gnu.org; Tue, 06 Oct 2020 02:16:24 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:46224) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kPgGs-0001Jc-Jp; Tue, 06 Oct 2020 02:16:22 -0400 Original-Received: from [176.228.60.248] (port=3878 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kPgGr-0007fk-QF; Tue, 06 Oct 2020 02:16:22 -0400 In-Reply-To: <87mu10eaet.fsf@gmail.com> (message from =?utf-8?B?Sm/Do28g?= =?utf-8?B?VMOhdm9yYQ==?= on Mon, 05 Oct 2020 20:32:26 +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:257154 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:32:26 +0100 > > Eli Zaretskii writes: > > >> I think can understand some of Gregory's frustration. If those problems > >> are real, it should be possible to showcase them. > > The second one was showcased by Gregory himself. > > If I read that correctly that was a synthethic, not a real-life example. I fail to see how that is a disadvantage. Most examples that illustrate some point are synthetic, because real-life examples run the risk of hiding the important stuff behind gobs of irrelevant code. That's why, for example, we ask for simple reproduction recipes when people report bugs. > > Sorry, I'm unable to encourage Gregory to understand the shortcomings, > > no matter how much I tried, I guess it's my fault. > > It's not a question of "fault" or persuasion, it's a simple question > that code speaks louder than words: good examples can be taken through a > debugger and revealing where in actual code the shortcomings of a given > approach manifests themselves. I'm sorry, but I can only afford hand-holding up to a limit. I provided explanations and described how the relevant parts of the display engine work. I also reiterated considerations that should be apparent even without any details, such as that global variables get in the way of reentrancy, even if they are buffer-local variables. I invite you to read the 3 relevant threads and see for yourself. If that is not enough, and if the Emacs code doesn't speak loud enough to be of help, then Gregory should simply take my word for it, as someone who has many more hours hacking Emacs than he does. I simply cannot afford investing so much of the little time I have into educating people here, and expecting that would be unreasonable and even unfair. > > Although it sounds like the same situation is repeating with Martin's > > advice regarding mini-window resizing, so maybe it isn't entirely my > > fault after all. > > If I read correctly, Martin reinforced how non-trivial calculations > regarding mini-window sizing is, thus _strenghtening_ the case for > having a solution where the application isn't responsible for that, as > you suggest. That's not my interpretation. Gregory said that measuring the pixel-size of text is hard, to which Martin replied that resizing the mini-window accurately can be even harder. Then Gregory dismissed Martin's opinion out of hand. Martin has more experience with the window- and frame-related code in Emacs than all the rest of us, so dismissing his opinions on that is not recommended.