From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Truncating scroll runs that copy to where we copied to Date: Tue, 22 Nov 2011 04:54:28 -0500 Message-ID: References: <8339dibqlc.fsf@gnu.org> <6D358885-0CD8-4FC0-9598-549AB7E3D4AC@gmail.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1321955682 7440 80.91.229.12 (22 Nov 2011 09:54:42 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 22 Nov 2011 09:54:42 +0000 (UTC) Cc: david.reitter@gmail.com, emacs-devel@gnu.org To: YAMAMOTO Mitsuharu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 22 10:54:35 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RSn3h-0006Xb-4n for ged-emacs-devel@m.gmane.org; Tue, 22 Nov 2011 10:54:33 +0100 Original-Received: from localhost ([::1]:55493 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RSn3g-0000y9-Pv for ged-emacs-devel@m.gmane.org; Tue, 22 Nov 2011 04:54:32 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:52183) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RSn3e-0000y3-88 for emacs-devel@gnu.org; Tue, 22 Nov 2011 04:54:31 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RSn3d-00041O-2q for emacs-devel@gnu.org; Tue, 22 Nov 2011 04:54:30 -0500 Original-Received: from fencepost.gnu.org ([140.186.70.10]:54792) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RSn3d-00041K-0F for emacs-devel@gnu.org; Tue, 22 Nov 2011 04:54:29 -0500 Original-Received: from eliz by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1RSn3c-0005MT-FB; Tue, 22 Nov 2011 04:54:28 -0500 In-reply-to: (message from YAMAMOTO Mitsuharu on Tue, 22 Nov 2011 18:09:55 +0900) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.10 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:146141 Archived-At: > Date: Tue, 22 Nov 2011 18:09:55 +0900 > From: YAMAMOTO Mitsuharu > Cc: david.reitter@gmail.com, > emacs-devel@gnu.org > > > Alternatively, maybe we should assign only those rows that have > > their enabled_p flag set? Why would we even want to copy disabled > > glyph rows? > > This alternative is actually what I tried first. But I thought > truncation could also avoid redundant graphics operations as explained > above. If truncation indirectly prevents copying of disabled rows, then I think at least a comment to that effect should be in the loop which "assigns the rows". Just looking at the loop, it is not at all apparent that only enabled rows are being assigned. > > Also, what about the unconditional setting of to->enabled_p to 1 in > > the above loop, regardless of what was that flag in `from'? Does it > > look right to you? > > In the current code, to->enabled_p seems already be set to 1 > unconditionally. Maybe I don't understand the question. The question was whether the current code is right when it unconditionally sets that flag. If the `from' row is disabled, why should its assignee `to' row be enabled? If, after your changes, a disabled row is never assigned, then `to' will already have its enabled_p flag set, by virtue of the assignment. Either way, setting this flag unconditionally after the call to assign_row looks bogus to me. (By contrast, resetting the flag in `from' looks like TRT, at least as long as we garble it.)