[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Truncating scroll runs that copy to where we copied to

From: Eli Zaretskii
Subject: Re: Truncating scroll runs that copy to where we copied to
Date: Tue, 22 Nov 2011 04:54:28 -0500

> Date: Tue, 22 Nov 2011 18:09:55 +0900
> From: YAMAMOTO Mitsuharu <address@hidden>
> Cc: address@hidden,
>       address@hidden
> > 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.)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]