unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Keith David Bershatsky <esq@lawlist.com>
To: Alan Third <alan@idiocy.org>
Cc: emacs-devel@gnu.org
Subject: Re: nsterm.m: How to prevent _inactive_ window update from overreaching.
Date: Mon, 26 Nov 2018 20:58:59 -0800	[thread overview]
Message-ID: <m2o9abru98.wl%esq@lawlist.com> (raw)

Feature requests #17684 (crosshairs / visible fill column) and #22873 (multiple fake cursors) have not been approved by anyone on the Emacs development team.  There has been some discussion regarding whether multiple fake cursors should become a part of Emacs someday, but nothing was ever decided.  I continue to develop these features because I use them in my every day workflow and am hoping to convince the Emacs development team to someday include similar features.  I figure that if I do a good enough job, eventually the Emacs development team will say:  "sure, why not ..."

-  Fake cursors are removed in two (2) locations within redisplay_internal (if the cursor cache exists).  If the frame is not being updated, then call update_begin before removing and call update_end when removing is complete.

-  Fake cursors are removed in two (2) locations within redisplay_window (if the cursor cache exists).  If the frame is not being updated, then call update_begin before removing and call update_end when removing is complete.

-  Whenever display_and_set_cursor is called and not immediately returned, fake cursors are calculated and drawn; or if the cursor cache already exist, then erase and redraw.  If the frame is not being updated, then call update_begin before drawing/removing and call update_end when drawing/removing is complete.

-  The calculations for drawing fake cursors are based upon modified versions of the functions dump_glyph_matrix and dump_glyph_row, which generate the correct coordinates for placing the fake cursors.

-  Fake cursors come in two types:  (1) cursor with a glyph on top; (2) cursor with nothing on top [e.g., floating anywhere on the visible window].

-  There are two basic settings:  (1) draw or erase/redraw forthwith (whenever the real cursor would ordinarily be drawn); or, (2) draw on an idle-timer and, if the cursor cache exists, then erase/redraw in certain circumstances when the real cursor would ordinarily be redrawn.  New calculations and cursor cache update occur on the initial call of either of the two scenarios.

The present design calculates and draws/erases fake cursors based upon particular visible windows that get updated during redisplay, rather than rectangles within a particular window or set of windows.  If I am understanding your comments correctly, it sounds like a new rectangle system of fake cursor calculation and drawing/erasing of fake cursors would need to be designed (solely for the benefit of MacOS Mojave users).  Or, at the very least, calculate fake cursors once for each visible window (where fake cursors are active) and then loop through cached coordinates when a rectangle is drawn to see if any fake cursors are contained within -- if so, then draw/erase fake cursors within that rectangle.

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

> Date: [11-26-2018 12:09:02] <26 Nov 2018 20:09:02 +0000>
> From: Alan Third <alan@idiocy.org>
> To: Keith David Bershatsky <esq@lawlist.com>
> Cc: emacs-devel@gnu.org
> Subject: Re: nsterm.m: How to prevent _inactive_ window update from overreaching.
> 
> * * *
> 
> Because we can't draw directly to the screen any more, when redisplay
> is running all we can do is mark the parts of the frame that need
> updated. Later we call expose_frame on those parts and it does the
> actual drawing.
> 
> That process must be working to some extent. I don't know your code
> very well but I suspect the crosshair code is called when the cursor
> is redrawn. If part of the frame is marked as dirty, but that doesn't
> include the cursor, then the cursor isn't redrawn and therefore your
> crosshair code will not be called. Does that make sense?
> 
> If that is the case we need to work out how to ensure the crosshair
> code is called even if the cursor is not redrawn.
> 
> I've had a quick look at the patches and, if I'm honest, it would take
> me some time to work out what's going on. How is the crosshair drawn?
> --
> Alan Third



             reply	other threads:[~2018-11-27  4:58 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-27  4:58 Keith David Bershatsky [this message]
2018-11-28 21:31 ` nsterm.m: How to prevent _inactive_ window update from overreaching Alan Third
  -- strict thread matches above, loose matches on Subject: below --
2018-12-12  7:07 Keith David Bershatsky
2018-11-29  5:52 Keith David Bershatsky
2018-11-26  2:14 Keith David Bershatsky
2018-11-26 20:09 ` Alan Third
2018-11-25  2:20 Keith David Bershatsky
2018-11-22 20:13 Keith David Bershatsky
2018-11-22 19:07 Keith David Bershatsky
2018-11-22 22:57 ` Alan Third

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m2o9abru98.wl%esq@lawlist.com \
    --to=esq@lawlist.com \
    --cc=alan@idiocy.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).