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 17:04:05 +0200 Message-ID: <83h8trfx22.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> <83a7zkggya.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1511017504 13837 195.159.176.226 (18 Nov 2017 15:05:04 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 18 Nov 2017 15:05:04 +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 16:05:00 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 1eG4fz-0003F2-6Q for ged-emacs-devel@m.gmane.org; Sat, 18 Nov 2017 16:04:59 +0100 Original-Received: from localhost ([::1]:50335 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eG4g6-0005qH-3a for ged-emacs-devel@m.gmane.org; Sat, 18 Nov 2017 10:05:06 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59291) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eG4fP-0005qC-Qg for emacs-devel@gnu.org; Sat, 18 Nov 2017 10:04:24 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eG4fL-0004Zy-9P for emacs-devel@gnu.org; Sat, 18 Nov 2017 10:04:23 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:57929) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eG4fL-0004Zp-5e; Sat, 18 Nov 2017 10:04:19 -0500 Original-Received: from [176.228.60.248] (port=4810 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eG4fK-0008Ty-MM; Sat, 18 Nov 2017 10:04:19 -0500 In-reply-to: (message from Stefan Monnier on Sat, 18 Nov 2017 09:36:40 -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:220266 Archived-At: > From: Stefan Monnier > Cc: emacs-devel@gnu.org > Date: Sat, 18 Nov 2017 09:36:40 -0500 > > > 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. > > The above is the *model*. I'd describe the current model as: > > render buffer text to glyph-matrix > send glyph-matrix to screen This model is incomplete. Emacs first tries to reuse (parts of) the current matrix, if that's possible given the information about what has changed since the last redisplay cycle. It only generates a new ("desired") glyph matrix if the attempt to reuse the current one failed. In addition, AFAIR there are situations when only small portions of the desired matrix are generated. When doing this, Emacs must be able to decide which parts don't need to be regenerated. > both models are amenable to various optimizations. Most of the > optimizations applicable to the current model should be applicable to > the other as well. If you are thinking about reviewing the existing optimizations and changing them to account for the new model, including adding some new optimization methods, then I'm sure it's possible. But it's a large job, and I cannot promise that the result will be acceptable, performance-wise, unless very deep changes are done in the control and logic flow of the current code. IOW, I think the way redisplay is implemented simply isn't ready for such changes. The current implementation of the TTY menus was proposed by Gerd Möllmann, the author of the current display engine; if something like what you suggest were feasible, he'd most probably mention it when this was discussed. He didn't. Of course, it's possible that he simply didn't think about such an alternative, but I personally find that unlikely.