From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: mouse-drag-and-drop-region Date: Sat, 18 Nov 2017 09:54:21 +0200 Message-ID: <83a7zkggya.fsf@gnu.org> References: <5A0ABD41.5040402@gmx.at> <874lpwobsa.fsf@gmail.com> <5A0C0765.2040908@gmx.at> <87375fl3z1.fsf@gmail.com> <831skzjo2o.fsf@gnu.org> <87y3n7jj2y.fsf@gmail.com> <83r2syi5h6.fsf@gnu.org> <87r2sx4do3.fsf@gmail.com> <837eupiclf.fsf@gnu.org> <83lgj4hnaa.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1510991687 28086 195.159.176.226 (18 Nov 2017 07:54:47 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 18 Nov 2017 07:54:47 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 18 08:54:42 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eFxxW-0006ma-Ou for ged-emacs-devel@m.gmane.org; Sat, 18 Nov 2017 08:54:38 +0100 Original-Received: from localhost ([::1]:49094 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eFxxd-0005kb-Ji for ged-emacs-devel@m.gmane.org; Sat, 18 Nov 2017 02:54:45 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33748) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eFxxX-0005kU-4T for emacs-devel@gnu.org; Sat, 18 Nov 2017 02:54:39 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eFxxU-0003qc-0Z for emacs-devel@gnu.org; Sat, 18 Nov 2017 02:54:39 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:53467) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eFxxT-0003qI-TD; Sat, 18 Nov 2017 02:54:35 -0500 Original-Received: from [176.228.60.248] (port=4137 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eFxxT-0005CO-93; Sat, 18 Nov 2017 02:54:35 -0500 In-reply-to: (message from Stefan Monnier on Fri, 17 Nov 2017 17:44:02 -0500) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:220259 Archived-At: > From: Stefan Monnier > Cc: emacs-devel@gnu.org > Date: Fri, 17 Nov 2017 17:44:02 -0500 > > > I don't see how this solves the problem, because the display engine > > will still know nothing about that "second" matrix. > > As mentioned: "it's this one which is then sent to be displayed", so > this assumes we'd change the display engine to use the combined matrix: > > render buffer text to desired-glyph-matrix > combine desired-glyph-matrix with overlay-matrix into combined-matrix > send combined-matrix to screen If you mean that literally, then the above will disable (almost) all redisplay optimizations, and will cause Emacs always to display each window in its entirety. Redisplay optimizations require that Emacs be able to _reason_ about parts of the window display being unchanged, by looking at the related objects and variables -- buffers, overlays, etc. You introduce a factor into this equation about which Emacs will not be able to reason, because its relation to the other objects is unknown. E.g., the most frequent redisplay use case is cursor movement with no other changes. This case is detected and handled specially, because it must be fast. How will that work with your proposal, when cursor motion will (or could) change some parts in that "second" matrix? Am I missing something?