From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Keith David Bershatsky Newsgroups: gmane.emacs.devel Subject: Re: Whether a struct window *w is a live/valid window. Date: Fri, 22 Mar 2019 23:30:26 -0700 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="62157"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel@gnu.org To: Alan Third Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 23 07:45:59 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h7aPm-000FzM-RK for ged-emacs-devel@m.gmane.org; Sat, 23 Mar 2019 07:45:59 +0100 Original-Received: from localhost ([127.0.0.1]:39560 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h7aPl-00039l-QS for ged-emacs-devel@m.gmane.org; Sat, 23 Mar 2019 02:45:57 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:54765) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h7aOe-0002wV-Qd for emacs-devel@gnu.org; Sat, 23 Mar 2019 02:44:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h7aAy-0005t6-5i for emacs-devel@gnu.org; Sat, 23 Mar 2019 02:30:41 -0400 Original-Received: from gateway30.websitewelcome.com ([50.116.127.1]:36603) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1h7aAx-0005Vg-KK for emacs-devel@gnu.org; Sat, 23 Mar 2019 02:30:40 -0400 Original-Received: from cm14.websitewelcome.com (cm14.websitewelcome.com [100.42.49.7]) by gateway30.websitewelcome.com (Postfix) with ESMTP id 7A0726CE3 for ; Sat, 23 Mar 2019 01:30:27 -0500 (CDT) Original-Received: from gator3053.hostgator.com ([50.87.144.69]) by cmsmtp with SMTP id 7aAlh3Gzg2qH77aAlhTlht; Sat, 23 Mar 2019 01:30:27 -0500 X-Authority-Reason: nr=8 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lawlist.com ; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Cc :To:From:Message-ID:Date:Sender:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=XbRP9aixG8gcS5ubio4VblHT2ffPcO1uXuakNF0yu98=; b=fKyLZ9LypfKGcH37lFdFXRBiuF /Rl0G9q5D31nEBy8Mec1+JdFiqa9z1ZFvTikNqDtjzLx7E6cq8LgnwiSaop9CutTE8MhZwMnCQtf+ TdVUvHq82PgofvnnRwp+i6ftSYGmbHVHv7Len0ZIs5Dmvf+NYIMF/FQ9FCJOR2VR1fAhOWVSggpAr U4MtLqYW/abD9ADsPFRHpsLEzCSQrrGmue7nhZVRX+okFiC5niKTguxy/xa5JLY3tnfNyFN/cvMBQ D8j5xg6tmmJa7bYklAKIkBO8wWE8eetwhEI+IHaFiRdvTsN5kn06/YCgZfeBaQckNXM5vvfUg7eog nLqBGaWQ==; Original-Received: from cpe-45-48-239-195.socal.res.rr.com ([45.48.239.195]:49832 helo=server.local) by gator3053.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.91) (envelope-from ) id 1h7aAk-003ak5-Op; Sat, 23 Mar 2019 01:30:26 -0500 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3053.hostgator.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - lawlist.com X-BWhitelist: no X-Source-IP: 45.48.239.195 X-Source-L: No X-Exim-ID: 1h7aAk-003ak5-Op X-Source-Sender: cpe-45-48-239-195.socal.res.rr.com (server.local) [45.48.239.195]:49832 X-Source-Auth: lawlist X-Email-Count: 1 X-Source-Cap: bGF3bGlzdDtsYXdsaXN0O2dhdG9yMzA1My5ob3N0Z2F0b3IuY29t X-Local-Domain: yes X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 50.116.127.1 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:234638 Archived-At: Thank you, Allen, for reading and responding to this particular thread. I could be wrong, but it appears to me that removal of the vertical scrol= l bars does not remove the glyphs that are underneath. As such, the glyp= hs that are underneath are not redrawn. However, removal of the vertical= scroll bar has the side effect of removing the fake cursors. My workaro= und has been to remove the scroll bars graciously so as not to cause remo= val of the fake cursors. That way, the fake cursors do not need to be re= drawn. On the NS port, I use removeFromSuperviewWithoutNeedingDisplay. = On the w32 port, I use SendMessage (hwnd, WM_SETREDRAW, false, 0) before = destroying a window (DestroyWindow); and, I set the bRepaint argument of = MoveWindow to false when the window just needs to be moved. In the current draft of multiple fake cursors, they are laid immediately = following the calls to draw_glyphs. FACT PATTERNS: Two (2) adjacent windows (left/right) within a single fra= me. Either the user deletes the left window; or, the user deletes the ri= ght window. When the user deletes the left window, its scroll bar (cente= r of screen) is no longer associated with a live/valid window. When a us= er deletes the right window, the scroll bar (center of screen) remains as= sociated with the left window but needs to be moved. When either the left or right window is deleted, update_window redraws al= l of the screen lines and effectively erases the scroll bar (center of sc= reen). In a related thread, Eli Z. was kind enough to provide an outline= of the relevant events: . `redisplay_internal' calls the `condemn_scroll_bars_hook', which mark= s all scroll bars as candidates for deletion. . Then `redisplay_internal' calls `redisplay_windows', which walks the = window-tree and examines each window, whereby each window that is still a= live in the window-tree "redeems" its scroll bars by marking them not to = be deleted. . Then `redisplay_internal' calls `judge_scroll_bars_hook', which remov= es all the scroll bars that were not "redeemed". . And only after that `redisplay_internal' calls `update_frame', which = calls `update_window' for each live window, and that ends up calling `dra= w_glyphs' to deliver the updated contents to the glass. When I stepped through the code, I observed that removal of the scroll ba= rs is delayed on the NS and W32 platforms. update_window runs _before_ s= croll bars are actually removed. Scroll bar removal occurs during read_c= har at approximately the location of read_decoded_event_from_main_queue. http://www.lawlist.com/images/after_03_10_2019.png The w32 port uses a Lisp_Object for the WINDOW component of the scroll ba= r structure. Calling WINDOW_LIVE_P seems to be working well on that plat= form. The NS port uses `struct window *window`, and Emacs occasionally crashes = when I have attempted to use XSETWINDOW (as described in the initial post= of this thread). My workaround is to tentatively use: if (w !=3D NULL && NILP (w->contents)) instead of trying to create a Lisp_Object with XSETWINDOW so that I can t= hen use WINDOW_LIVE_P. ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; > Date: [03-22-2019 08:01:48] <22 Mar 2019 15:01:48 +0000> > From: Alan Third > To: Keith David Bershatsky > Cc: Emacs Devel > Subject: Re: Whether a struct window *w is a live/valid window. >=20 > On Wed, Mar 20, 2019 at 01:14:13PM -0700, Keith David Bershatsky wrote: > > I am working on feature requests #22873 (multiple fake cursors) and > > crosshairs #17684 (crosshairs that track the cursor position). > > > > In trying to resolve an issue where removal of vertical scroll bars > > erased fake cursors that were laid during update_window >=20 > Sorry if this has already been covered, but after the scrollbar is > removed the toolkit should mark the area under the toolkit as needing > redrawn. That will then cause [EmacsView drawRect:], and subsequently > expose_frame, to be called on that rectangle. Why aren't the cursors > being redrawn at that time? >=20 > Is everything else =E2=80=98under' the scrollbars being drawn correctly= ? > -- > Alan Third