From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#22873: Can we support multiple cursors? Date: Sun, 13 Aug 2017 21:36:22 +0300 Message-ID: <831sofiac9.fsf@gnu.org> References: Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1502649494 18228 195.159.176.226 (13 Aug 2017 18:38:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 13 Aug 2017 18:38:14 +0000 (UTC) Cc: jwiegley@gmail.com, mbork@mbork.pl, 22873@debbugs.gnu.org, rms@gnu.org To: Keith David Bershatsky Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Aug 13 20:38:09 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1dgxm5-0004Nw-Fy for geb-bug-gnu-emacs@m.gmane.org; Sun, 13 Aug 2017 20:38:09 +0200 Original-Received: from localhost ([::1]:49771 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dgxmC-0006qY-2A for geb-bug-gnu-emacs@m.gmane.org; Sun, 13 Aug 2017 14:38:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34187) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dgxm1-0006p2-UH for bug-gnu-emacs@gnu.org; Sun, 13 Aug 2017 14:38:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dgxly-0006ad-9Y for bug-gnu-emacs@gnu.org; Sun, 13 Aug 2017 14:38:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:51792) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dgxly-0006aV-5Q for bug-gnu-emacs@gnu.org; Sun, 13 Aug 2017 14:38:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dgxlx-0007gM-V6 for bug-gnu-emacs@gnu.org; Sun, 13 Aug 2017 14:38:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 13 Aug 2017 18:38:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22873 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 22873-submit@debbugs.gnu.org id=B22873.150264943429524 (code B ref 22873); Sun, 13 Aug 2017 18:38:01 +0000 Original-Received: (at 22873) by debbugs.gnu.org; 13 Aug 2017 18:37:14 +0000 Original-Received: from localhost ([127.0.0.1]:60471 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dgxlC-0007g8-HM for submit@debbugs.gnu.org; Sun, 13 Aug 2017 14:37:14 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:42948) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dgxlB-0007g2-6G for 22873@debbugs.gnu.org; Sun, 13 Aug 2017 14:37:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dgxl4-00068A-Rs for 22873@debbugs.gnu.org; Sun, 13 Aug 2017 14:37:07 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:39289) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dgxkp-00061W-ET; Sun, 13 Aug 2017 14:36:51 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3761 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dgxkg-0006R3-Sq; Sun, 13 Aug 2017 14:36:44 -0400 In-reply-to: (message from Keith David Bershatsky on Sun, 13 Aug 2017 11:19:30 -0700) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:135733 Archived-At: > Date: Sun, 13 Aug 2017 11:19:30 -0700 > From: Keith David Bershatsky > Cc: 22873@debbugs.gnu.org,John Wiegley ,Marcin Borkowski ,Richard Stallman > > I have encountered a situation where the Y and VPOS coordinates returned by `move_it_to` are sometimes out of bounds, and MATRIX_ROW crashes Emacs when drawing fake cursors that are out of bounds. The solution appears to be a test for whether Y and VPOS are out of bounds. Actually, the usual solution is to limit move_it_to to last_visible_y. Are you saying that you already do that, and the values of Y and VPOS are still out of bounds? That would be strange, because the display engine does that in many places. > I would like to use `window_box_height` to give me essentially the same value as `window-body-height` with a non-nil PIXELWISE argument. And that's not what you get? Can you show a simple example? `count-screen-lines` is not a viable option because using `vertical-motion` is too slow. It's strange that you say so because vertical-motion uses the same move_it_to subroutines that you'd like to use directly. > Testing and limiting the drawing of fake cursors with `y <= window_box_height (w)` gives me mixed results; i.e., sometimes fake cursors are drawn/erased only up to line 49, but sometimes it works up to line 50 (partially visible). I think I want to test for whether Y is less than or equal to 1000 and if VPOS is less than or equal to 50 -- if the test is true, then go ahead and draw fake cursors up to and including that location. Are you sure you account for the height of the cursor and the line on which it is shown? The Y coordinate is where the line begins; it ends several pixels lower, i.e. at a greater value of Y. > However, I can foresee situations where there might be mixed line heights on the visible window, and relying upon the frame character height and window body height will not be reliable. In a simple case, we can take 1000 divided by 20 and know that the VPOS is 50. For reliable calculations, you must do everything in pixels. > Is there a more reliable test for the last partially visible Y and VPOS within the window body height? Should I be using pos_visible_p in some capacity here? You could use pos_visible_p, although it, again, uses move_it_to. But I don't think I have a clear understanding of your problem, so maybe it's immaterial.