bug#33442: 26.1.90; Cairo side-by-side windows scrolling fix should be cherry-picked

[Eli Zaretskii <eliz@gnu.org>]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  ari.roponen@gmail.com,  33442@debbugs.gnu.org
> Date: Sun, 09 Dec 2018 23:08:06 +0100
> 
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
> > On 08.12.2018 16:24, Eli Zaretskii wrote:
> >
> >> And never worked before since the code
> >> was written.
> >
> > If that is true, I have no strong arguments for why it "has to" be on
> > emacs-26.
> >
> >> I was asking why it has to be on emacs-26, and hoped for
> >> responses that take the pros and cons into consideration and show how
> >> the pros win over cons.
> >
> > But I'm not seeing any cons either. It's not like there are any
> > plausible Cairo build users that are fine with the current state of
> > emacs-26 but would get annoyed by any possible regression that the
> > patch in question might introduce.
> >
> > Anyway, it seems I've already made all the applicable arguments at the
> > beginning of this discussion. So I'll stop here.
> 
> I thought we were in a state on emacs-26 where we can get away with
> cherry-picking minor fixes like the side-by-side stuff, precisely
> because cairo is disabled by default.  Also if any brave soul does
> turn it on on emacs-26, we should probably strive to have fixed things
> for them that are easy to fix.

OK, please cherry-pick that part as well.

> On a separate note, should we turn cairo on by default in master?

I have no strong opinion on this.  IMO, the decision should be based
on what those who use Cairo say about its stability.  I'd also
encourage people to see whether the reported bugs are still there, or
maybe they were solved indirectly.