From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#42406: Mouse-wheel scrolling can be flickering Date: Fri, 18 Dec 2020 18:12:45 -0500 Message-ID: References: <20200722201659.GA1541@breton.holly.idiocy.org> <969D8DEC-6837-4DD4-93E9-F359DADE1EAB@univie.ac.at> <20201010095100.GG60347@breton.holly.idiocy.org> <9849711D-8DBE-4030-8020-84D86E72505B@univie.ac.at> <83czzg3ge1.fsf@gnu.org> <83sg89cyrq.fsf@gnu.org> <837dpkcqpa.fsf@gnu.org> <83im9070x6.fsf@gnu.org> <83ft446uh7.fsf@gnu.org> <837dpf7e5n.fsf@gnu.org> <83tusi6e2b.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15691"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: alan@idiocy.org, konrad.podczeck@univie.ac.at, 42406@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Dec 19 00:13:12 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1kqOvw-00040F-IG for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 19 Dec 2020 00:13:12 +0100 Original-Received: from localhost ([::1]:47998 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kqOvv-0003yo-If for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 18 Dec 2020 18:13:11 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53528) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kqOvm-0003xG-Eb for bug-gnu-emacs@gnu.org; Fri, 18 Dec 2020 18:13:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:57152) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kqOvm-0000jv-75 for bug-gnu-emacs@gnu.org; Fri, 18 Dec 2020 18:13:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kqOvm-0001iE-2c for bug-gnu-emacs@gnu.org; Fri, 18 Dec 2020 18:13:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 18 Dec 2020 23:13:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 42406 X-GNU-PR-Package: emacs Original-Received: via spool by 42406-submit@debbugs.gnu.org id=B42406.16083331766566 (code B ref 42406); Fri, 18 Dec 2020 23:13:02 +0000 Original-Received: (at 42406) by debbugs.gnu.org; 18 Dec 2020 23:12:56 +0000 Original-Received: from localhost ([127.0.0.1]:40465 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kqOvf-0001hq-N3 for submit@debbugs.gnu.org; Fri, 18 Dec 2020 18:12:55 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:21459) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kqOve-0001hb-CP for 42406@debbugs.gnu.org; Fri, 18 Dec 2020 18:12:54 -0500 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id D2E0E10022E; Fri, 18 Dec 2020 18:12:48 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 4B93A1000CF; Fri, 18 Dec 2020 18:12:47 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1608333167; bh=Ky0U6ZRagm8g0Vk2E6FxAZdQzkPXsLZUgLIFMFtunBM=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=SDJI5tYD7AU1pl2eG/714GDE9wWRnDJ8OV/ubT7Z2gMNk61pp+9EjiqDMstHb62ck WcqCxvQXHWhrujKZAwgKM0eqEH5UR9n8GmT7fjEmTO5C3GCsWm/rWiWcn8mxHxlOWe VEuM6cuQBxHFFggK0AZ+5mKlh0vmG3LsRtHMGThK8/3NsfsdWCxgXPhmyC49sZ7fjO 35w0bQNveTagC/L8+2EE3QDkk5bFts2RW/mx9+u6XQow5qdvNE1rUOWoXrml0aCLJe ZkzKt17acBpoc/y+oyCcvpXJj0fOknJgbGNYN6+wjkBTg7EsrxQJ4bpjZK/Ewj8m8A JfMFt2AT6+Eng== Original-Received: from alfajor (69-165-136-52.dsl.teksavvy.com [69.165.136.52]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 044261201A6; Fri, 18 Dec 2020 18:12:46 -0500 (EST) In-Reply-To: <83tusi6e2b.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 18 Dec 2020 22:42:52 +0200") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:196354 Archived-At: >> From: Stefan Monnier >> Cc: alan@idiocy.org, konrad.podczeck@univie.ac.at, 42406@debbugs.gnu.org >> Date: Fri, 18 Dec 2020 11:22:40 -0500 >> >> To be clear: I have no intention to push this to `emacs-27`, but >> I can't see any good reason not to push it to master (after fixing its >> FIXME, obviously). > > I thought I already explained why I'm not interested in such "fixes". I resent the way you used scare-quotes around this word. This *is* a fix and it only touches "flags" whose semantics we understand well. Any change to the redisplay will risk introducing regressions because of the previous code's intricate workings so if you reject this simple change, I can't see why you wouldn't reject similarly any other change to the redisplay (including your advocated big redesign). After all, my `redisplay` bits did pretty much exactly what you suggest we do, except that they did not try to use a finer distinction between frametitles, headerlines, modelines, ... I really just don't understand your stance here. > Oh, and your question about where the change in mode-line dimensions > is handled? it's here: > > display_mode_lines (w); > > /* If mode line height has changed, arrange for a thorough > immediate redisplay using the correct mode line height. */ > if (window_wants_mode_line (w) > && CURRENT_MODE_LINE_HEIGHT (w) != DESIRED_MODE_LINE_HEIGHT (w)) > { > f->fonts_changed = true; > w->mode_line_height = -1; > MATRIX_MODE_LINE_ROW (w->current_matrix)->height > = DESIRED_MODE_LINE_HEIGHT (w); > } > [...] > if (f->fonts_changed) > goto need_larger_matrices; Ah, right, thanks, that makes sense. And it shows that the division between "mode-lines" and "window contents" was a good idea, since in most cases they can be handled separately and in the few cases where they can't, we can easily arrange to augment the amount that's actually redisplayed once we discover that more needs to be done. Stefan