GNU bug report logs -
#33442
26.1.90; Cairo side-by-side windows scrolling fix should be cherry-picked
Previous Next
Reported by: Ari Roponen <ari.roponen <at> gmail.com>
Date: Tue, 20 Nov 2018 08:16:02 UTC
Severity: normal
Tags: fixed
Found in version 26.1.90
Fixed in version 26.2
Done: Robert Pluim <rpluim <at> gmail.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 33442 in the body.
You can then email your comments to 33442 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#33442
; Package
emacs
.
(Tue, 20 Nov 2018 08:16:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Ari Roponen <ari.roponen <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Tue, 20 Nov 2018 08:16:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Scrolling in --with-cairo -build doesn't work when there are
side-by-side split windows. That was fixed in the master branch by
commit 6e362a32bc9d21f73a0f29ca6f45481edeea6f29
Author: Ari Roponen <ari.roponen <at> gmail.com>
Date: Sun May 6 15:29:28 2018 +0300
Fix cairo scrolling for side-by-side windows
* src/xterm.c (x_scroll_run) [USE_CAIRO]: Fix scrolling for
side-by-side split windows. (Bug#31288)
Cherry-picking that commit fixes the problem in 26 branch too.
In GNU Emacs 26.1.90 (build 6, x86_64-pc-linux-gnu, GTK+ Version 3.24.1, cairo version 1.16.0)
of 2018-11-20 built on arirop
Repository revision: d667318a7f89a9daeffca6fb47503889bd23f3bd
Windowing system distributor 'Fedora Project', version 11.0.12003000
System Description: Fedora release 29 (Twenty Nine)
Configured using:
'configure --with-cairo'
Configured features:
XPM JPEG TIFF GIF PNG RSVG CAIRO IMAGEMAGICK SOUND DBUS GSETTINGS GLIB
NOTIFY LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM THREADS LIBSYSTEMD LCMS2
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#33442
; Package
emacs
.
(Tue, 20 Nov 2018 15:59:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 33442 <at> debbugs.gnu.org (full text, mbox):
> From: Ari Roponen <ari.roponen <at> gmail.com>
> Date: Tue, 20 Nov 2018 10:15:09 +0200
>
> Scrolling in --with-cairo -build doesn't work when there are
> side-by-side split windows. That was fixed in the master branch by
> commit 6e362a32bc9d21f73a0f29ca6f45481edeea6f29
>
> Author: Ari Roponen <ari.roponen <at> gmail.com>
> Date: Sun May 6 15:29:28 2018 +0300
>
> Fix cairo scrolling for side-by-side windows
>
> * src/xterm.c (x_scroll_run) [USE_CAIRO]: Fix scrolling for
> side-by-side split windows. (Bug#31288)
>
> Cherry-picking that commit fixes the problem in 26 branch too.
Thanks, but I'm not convinced we should backport that change. We
don't fix every bug on the release branch, only the important onces.
And the Cairo configuration doesn't strike me as important, what with
all the additional known bugs specific to it.
That said, I'm open to arguments to the contrary.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#33442
; Package
emacs
.
(Tue, 20 Nov 2018 16:17:03 GMT)
Full text and
rfc822 format available.
Message #11 received at 33442 <at> debbugs.gnu.org (full text, mbox):
On 20.11.2018 17:58, Eli Zaretskii wrote:
> Thanks, but I'm not convinced we should backport that change. We
> don't fix every bug on the release branch, only the important onces.
An argument could be made about the lesser impotance of stability
guarantees for the Cairo users (since it's already broken). So I'd ask
whether the given patch makes it considerably more usable, so that more
people are likely to try the --with-cairo build and submit patches/bug
reports/etc.
> And the Cairo configuration doesn't strike me as important, what with
> all the additional known bugs specific to it.
IIRC, somebody said it's the best approach we have for supporting
Wayland someday. I think it's a worthy goal.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#33442
; Package
emacs
.
(Tue, 20 Nov 2018 17:15:05 GMT)
Full text and
rfc822 format available.
Message #14 received at 33442 <at> debbugs.gnu.org (full text, mbox):
> Cc: 33442 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Tue, 20 Nov 2018 18:16:19 +0200
>
> On 20.11.2018 17:58, Eli Zaretskii wrote:
>
> > Thanks, but I'm not convinced we should backport that change. We
> > don't fix every bug on the release branch, only the important onces.
>
> An argument could be made about the lesser impotance of stability
> guarantees for the Cairo users (since it's already broken). So I'd ask
> whether the given patch makes it considerably more usable, so that more
> people are likely to try the --with-cairo build and submit patches/bug
> reports/etc.
Good point. I'd like to know the answer to that.
> > And the Cairo configuration doesn't strike me as important, what with
> > all the additional known bugs specific to it.
>
> IIRC, somebody said it's the best approach we have for supporting
> Wayland someday. I think it's a worthy goal.
Sure, but it needs someone to work on making it usable and on fixing
the bugs. Otherwise, it's just a teaser.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#33442
; Package
emacs
.
(Wed, 21 Nov 2018 07:12:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 33442 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Cc: 33442 <at> debbugs.gnu.org
>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>> Date: Tue, 20 Nov 2018 18:16:19 +0200
>>
>> On 20.11.2018 17:58, Eli Zaretskii wrote:
>>
>> > Thanks, but I'm not convinced we should backport that change. We
>> > don't fix every bug on the release branch, only the important onces.
>>
>> An argument could be made about the lesser impotance of stability
>> guarantees for the Cairo users (since it's already broken). So I'd ask
>> whether the given patch makes it considerably more usable, so that more
>> people are likely to try the --with-cairo build and submit patches/bug
>> reports/etc.
>
> Good point. I'd like to know the answer to that.
Cairo fixes went to the release branch after 26.1 was tagged
(commit aac541e75e2c22d05752025c2087ae2eea4cb525).
This patch is a left-over that fixes the scrolling when the window is
split side-by-side.
I have been using --with-cairo for my Emacs builds for six months, and
haven't had any major problems with it.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#33442
; Package
emacs
.
(Wed, 21 Nov 2018 21:42:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 33442 <at> debbugs.gnu.org (full text, mbox):
On 21.11.2018 9:11, Ari Roponen wrote:
> I have been using --with-cairo for my Emacs builds for six months, and
> haven't had any major problems with it.
Curious.
I've just tried building the master branch --with-cairo (on GNU/Linux),
and I see crippling rendering problems right away. Maybe the same issue
as reported at https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23925.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#33442
; Package
emacs
.
(Thu, 22 Nov 2018 06:45:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 33442 <at> debbugs.gnu.org (full text, mbox):
Dmitry Gutov <dgutov <at> yandex.ru> writes:
> On 21.11.2018 9:11, Ari Roponen wrote:
>
>> I have been using --with-cairo for my Emacs builds for six months, and
>> haven't had any major problems with it.
>
> Curious.
>
> I've just tried building the master branch --with-cairo (on
> GNU/Linux), and I see crippling rendering problems right away. Maybe
> the same issue as reported at
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23925.
>
It does work here. I use gnome-shell on Xwayland.
Could you try the following patch, if it helps?
diff --git a/src/xterm.c b/src/xterm.c
index 3a7e31e712..e82beacd7d 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -992,6 +992,9 @@ x_update_begin (struct frame *f)
if (FRAME_TOOLTIP_P (f) && !FRAME_VISIBLE_P (f))
return;
+ if (FRAME_GARBAGED_P (f))
+ x_cr_destroy_surface (f);
+
if (! FRAME_CR_SURFACE (f))
{
int width, height;
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#33442
; Package
emacs
.
(Thu, 22 Nov 2018 12:04:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 33442 <at> debbugs.gnu.org (full text, mbox):
On 22.11.2018 8:44, Ari Roponen wrote:
> It does work here. I use gnome-shell on Xwayland.
> Could you try the following patch, if it helps?
No change.
It's probably also related to HiDPI: the area that gets refreshed is at
half the window size and height. And my desktop scaling factor is 2.
X+Unity+Compiz+Ubuntu 18.04.1 here, though. I'll have to try it with
GNOME sometime.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#33442
; Package
emacs
.
(Thu, 22 Nov 2018 12:21:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 33442 <at> debbugs.gnu.org (full text, mbox):
Dmitry Gutov <dgutov <at> yandex.ru> writes:
> On 22.11.2018 8:44, Ari Roponen wrote:
>
>> It does work here. I use gnome-shell on Xwayland.
>> Could you try the following patch, if it helps?
>
> No change.
>
> It's probably also related to HiDPI: the area that gets refreshed is
> at half the window size and height. And my desktop scaling factor is
> 2.
That seems to be it: Starting Emacs with
GDK_SCALE=2 emacs -Q
shows the problem here, too.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#33442
; Package
emacs
.
(Thu, 22 Nov 2018 14:06:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 33442 <at> debbugs.gnu.org (full text, mbox):
On 22.11.2018 14:19, Ari Roponen wrote:
> That seems to be it: Starting Emacs with
> GDK_SCALE=2 emacs -Q
> shows the problem here, too.
Thanks for that. I've just tried a --with-cairo build with
GDK_SCALE=1 emacs
and it seems to work well, (even) without your extra patch. Aside from
the expected problems with toolbar icons and scrollbar (too small),
which I don't use anyway.
So maybe we shouldn't think of the Cairo build as too broken anymore.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#33442
; Package
emacs
.
(Thu, 22 Nov 2018 14:53:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 33442 <at> debbugs.gnu.org (full text, mbox):
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Thu, 22 Nov 2018 16:05:18 +0200
> Cc: 33442 <at> debbugs.gnu.org
>
> Thanks for that. I've just tried a --with-cairo build with
>
> GDK_SCALE=1 emacs
>
> and it seems to work well, (even) without your extra patch. Aside from
> the expected problems with toolbar icons and scrollbar (too small),
> which I don't use anyway.
>
> So maybe we shouldn't think of the Cairo build as too broken anymore.
How many users will agree to demote the DPI just to have the Cairo
build working? IOW, is the above a viable solution, or is it
something many users will regard as unacceptable?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#33442
; Package
emacs
.
(Thu, 22 Nov 2018 15:23:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 33442 <at> debbugs.gnu.org (full text, mbox):
On 22.11.2018 16:52, Eli Zaretskii wrote:
> How many users will agree to demote the DPI just to have the Cairo
> build working? IOW, is the above a viable solution, or is it
> something many users will regard as unacceptable?
I think so. The toolbar buttons and the scrollbar handle are simply
smaller, and a lot of hardcore users disable them anyway.
The font size or rendering quality don't seem to be affected by the
scaling factor.
Still, some users won't like it, or will simply be confused if they have
to hunt for "GDK_SCALE=1 emacs" in the PROBLEMS file, so we have to fix
that sooner a later, too. But it seems to be a separate bug, not one
we've already seen reported. And, judging from the past bug reports,
problems like this are relatively easy to fix.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#33442
; Package
emacs
.
(Thu, 29 Nov 2018 12:16:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 33442 <at> debbugs.gnu.org (full text, mbox):
Dmitry Gutov <dgutov <at> yandex.ru> writes:
> On 22.11.2018 14:19, Ari Roponen wrote:
>
>> That seems to be it: Starting Emacs with
>> GDK_SCALE=2 emacs -Q
>> shows the problem here, too.
>
> Thanks for that. I've just tried a --with-cairo build with
>
> GDK_SCALE=1 emacs
>
> and it seems to work well, (even) without your extra patch. Aside from
> the expected problems with toolbar icons and scrollbar (too small),
> which I don't use anyway.
With the following patch, GDK_SCALE=2 seems to work for me.
diff --git a/src/xterm.c b/src/xterm.c
index 3a7e31e712..42ddc4f5b1 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -360,10 +360,15 @@ x_begin_cr_clip (struct frame *f, GC gc)
if (! FRAME_CR_SURFACE (f))
{
+ int scale = 1;
+#ifdef USE_GTK
+ scale = xg_get_scale (f);
+#endif
+
FRAME_CR_SURFACE (f) =
cairo_image_surface_create (CAIRO_FORMAT_ARGB32,
- FRAME_PIXEL_WIDTH (f),
- FRAME_PIXEL_HEIGHT (f));
+ scale * FRAME_PIXEL_WIDTH (f),
+ scale * FRAME_PIXEL_HEIGHT (f));
}
cr = cairo_create (FRAME_CR_SURFACE (f));
FRAME_CR_CONTEXT (f) = cr;
@@ -999,8 +1004,9 @@ x_update_begin (struct frame *f)
if (FRAME_GTK_WIDGET (f))
{
GdkWindow *w = gtk_widget_get_window (FRAME_GTK_WIDGET (f));
- width = gdk_window_get_width (w);
- height = gdk_window_get_height (w);
+ int scale = xg_get_scale (f);
+ width = scale * gdk_window_get_width (w);
+ height = scale * gdk_window_get_height (w);
}
else
#endif
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#33442
; Package
emacs
.
(Thu, 29 Nov 2018 13:21:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 33442 <at> debbugs.gnu.org (full text, mbox):
Ari Roponen <ari.roponen <at> gmail.com> writes:
> Dmitry Gutov <dgutov <at> yandex.ru> writes:
>
>> On 22.11.2018 14:19, Ari Roponen wrote:
>>
>>> That seems to be it: Starting Emacs with
>>> GDK_SCALE=2 emacs -Q
>>> shows the problem here, too.
>>
>> Thanks for that. I've just tried a --with-cairo build with
>>
>> GDK_SCALE=1 emacs
>>
>> and it seems to work well, (even) without your extra patch. Aside from
>> the expected problems with toolbar icons and scrollbar (too small),
>> which I don't use anyway.
>
> With the following patch, GDK_SCALE=2 seems to work for me.
>
Works for me. Since this is all Cairo-only code, it could even go into
emacs-26, I think (with a ChangeLog and perhaps some comments).
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#33442
; Package
emacs
.
(Thu, 29 Nov 2018 14:01:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 33442 <at> debbugs.gnu.org (full text, mbox):
On 22.11.2018 17:22, Dmitry Gutov wrote:
> On 22.11.2018 16:52, Eli Zaretskii wrote:
>
>> How many users will agree to demote the DPI just to have the Cairo
>> build working? IOW, is the above a viable solution, or is it
>> something many users will regard as unacceptable?
>
> I think so. <...>
In any case, HiDPI users are still the minority, and the commit
requested to be backported is a localized fix for an obvious,
easy-to-reproduce regression (scrolling is indeed broken, I tested with
and without the patch).
So I highly suggest we allow it.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#33442
; Package
emacs
.
(Thu, 29 Nov 2018 14:08:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 33442 <at> debbugs.gnu.org (full text, mbox):
On 29.11.2018 14:15, Ari Roponen wrote:
> With the following patch, GDK_SCALE=2 seems to work for me.
Works for me as well. Please install it into master, at least.
Thank you!
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#33442
; Package
emacs
.
(Thu, 29 Nov 2018 14:12:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 33442 <at> debbugs.gnu.org (full text, mbox):
> From: Robert Pluim <rpluim <at> gmail.com>
> Date: Thu, 29 Nov 2018 14:19:56 +0100
> Cc: 33442 <at> debbugs.gnu.org, Dmitry Gutov <dgutov <at> yandex.ru>
>
> > With the following patch, GDK_SCALE=2 seems to work for me.
> >
>
> Works for me. Since this is all Cairo-only code, it could even go into
> emacs-26, I think (with a ChangeLog and perhaps some comments).
OK, let's do that.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#33442
; Package
emacs
.
(Fri, 30 Nov 2018 12:33:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 33442 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Robert Pluim <rpluim <at> gmail.com>
>> Date: Thu, 29 Nov 2018 14:19:56 +0100
>> Cc: 33442 <at> debbugs.gnu.org, Dmitry Gutov <dgutov <at> yandex.ru>
>>
>> > With the following patch, GDK_SCALE=2 seems to work for me.
>> >
>>
>> Works for me. Since this is all Cairo-only code, it could even go into
>> emacs-26, I think (with a ChangeLog and perhaps some comments).
>
> OK, let's do that.
>
The following patch fixes the scaling problem in Cairo builds. The
scrolling issue with side-by-side windows is in master branch (commit
6e362a32bc9d21f73a0f29ca6f45481edeea6f29), and can be cherry-picked.
From c76a784f7c345031f9bf1f88d2e4b13e44053638 Mon Sep 17 00:00:00 2001
From: Ari Roponen <ari.roponen <at> gmail.com>
Date: Fri, 30 Nov 2018 14:09:09 +0200
Subject: [PATCH 1/1] Fix scaling problem in cairo builds
* src/xterm.c (x_begin_cr_clip) [USE_GTK]:
(x_update_begin) [USE_CAIRO && USE_GTK]: Support scaling.
---
src/xterm.c | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/src/xterm.c b/src/xterm.c
index 3a7e31e712..42ddc4f5b1 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -360,10 +360,15 @@ x_begin_cr_clip (struct frame *f, GC gc)
if (! FRAME_CR_SURFACE (f))
{
+ int scale = 1;
+#ifdef USE_GTK
+ scale = xg_get_scale (f);
+#endif
+
FRAME_CR_SURFACE (f) =
cairo_image_surface_create (CAIRO_FORMAT_ARGB32,
- FRAME_PIXEL_WIDTH (f),
- FRAME_PIXEL_HEIGHT (f));
+ scale * FRAME_PIXEL_WIDTH (f),
+ scale * FRAME_PIXEL_HEIGHT (f));
}
cr = cairo_create (FRAME_CR_SURFACE (f));
FRAME_CR_CONTEXT (f) = cr;
@@ -999,8 +1004,9 @@ x_update_begin (struct frame *f)
if (FRAME_GTK_WIDGET (f))
{
GdkWindow *w = gtk_widget_get_window (FRAME_GTK_WIDGET (f));
- width = gdk_window_get_width (w);
- height = gdk_window_get_height (w);
+ int scale = xg_get_scale (f);
+ width = scale * gdk_window_get_width (w);
+ height = scale * gdk_window_get_height (w);
}
else
#endif
--
2.19.2
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#33442
; Package
emacs
.
(Sat, 08 Dec 2018 09:57:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 33442 <at> debbugs.gnu.org (full text, mbox):
> From: Ari Roponen <ari.roponen <at> gmail.com>
> Cc: Robert Pluim <rpluim <at> gmail.com>, 33442 <at> debbugs.gnu.org, dgutov <at> yandex.ru
> Date: Fri, 30 Nov 2018 14:31:51 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> From: Robert Pluim <rpluim <at> gmail.com>
> >> Date: Thu, 29 Nov 2018 14:19:56 +0100
> >> Cc: 33442 <at> debbugs.gnu.org, Dmitry Gutov <dgutov <at> yandex.ru>
> >>
> >> > With the following patch, GDK_SCALE=2 seems to work for me.
> >> >
> >>
> >> Works for me. Since this is all Cairo-only code, it could even go into
> >> emacs-26, I think (with a ChangeLog and perhaps some comments).
> >
> > OK, let's do that.
> >
>
> The following patch fixes the scaling problem in Cairo builds.
I pushed this to the emacs-26 branch, thanks.
Not sure there was a consensus about this part:
> The
> scrolling issue with side-by-side windows is in master branch (commit
> 6e362a32bc9d21f73a0f29ca6f45481edeea6f29), and can be cherry-picked.
Thoughts?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#33442
; Package
emacs
.
(Sat, 08 Dec 2018 10:43:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 33442 <at> debbugs.gnu.org (full text, mbox):
On 08.12.2018 11:55, Eli Zaretskii wrote:
> Not sure there was a consensus about this part:
>
>> The
>> scrolling issue with side-by-side windows is in master branch (commit
>> 6e362a32bc9d21f73a0f29ca6f45481edeea6f29), and can be cherry-picked.
> Thoughts?
Yes?
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33442#47
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#33442
; Package
emacs
.
(Sat, 08 Dec 2018 11:17:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 33442 <at> debbugs.gnu.org (full text, mbox):
> Cc: rpluim <at> gmail.com, 33442 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Sat, 8 Dec 2018 12:42:29 +0200
>
> On 08.12.2018 11:55, Eli Zaretskii wrote:
> > Not sure there was a consensus about this part:
> >
> >> The
> >> scrolling issue with side-by-side windows is in master branch (commit
> >> 6e362a32bc9d21f73a0f29ca6f45481edeea6f29), and can be cherry-picked.
> > Thoughts?
>
> Yes?
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33442#47
That was about scaling, no? And Robert only replied to the scaling
part, AFAIU.
Why is side-by-side scrolling important enough to get it in emacs-26?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#33442
; Package
emacs
.
(Sat, 08 Dec 2018 13:04:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 33442 <at> debbugs.gnu.org (full text, mbox):
On 08.12.2018 13:15, Eli Zaretskii wrote:
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33442#47
>
> That was about scaling, no?
In part it was about "so what if the scaling is broken".
> Why is side-by-side scrolling important enough to get it in emacs-26?
You mean why 'C-x 3 C-v C-v C-v' should work? Seems like a basic
functionality.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#33442
; Package
emacs
.
(Sat, 08 Dec 2018 14:25:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 33442 <at> debbugs.gnu.org (full text, mbox):
> Cc: ari.roponen <at> gmail.com, rpluim <at> gmail.com, 33442 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Sat, 8 Dec 2018 15:03:12 +0200
>
> On 08.12.2018 13:15, Eli Zaretskii wrote:
>
> >> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33442#47
> >
> > That was about scaling, no?
>
> In part it was about "so what if the scaling is broken".
>
> > Why is side-by-side scrolling important enough to get it in emacs-26?
>
> You mean why 'C-x 3 C-v C-v C-v' should work? Seems like a basic
> functionality.
Yes, and it works on master. And never worked before since the code
was written. 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#33442
; Package
emacs
.
(Sat, 08 Dec 2018 14:46:02 GMT)
Full text and
rfc822 format available.
Message #74 received at 33442 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#33442
; Package
emacs
.
(Sun, 09 Dec 2018 22:09:01 GMT)
Full text and
rfc822 format available.
Message #77 received at 33442 <at> debbugs.gnu.org (full text, mbox):
Dmitry Gutov <dgutov <at> 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.
On a separate note, should we turn cairo on by default in master? It
will still only get compiled for people who have the appropriate
development packages installed.
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#33442
; Package
emacs
.
(Mon, 10 Dec 2018 06:21:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 33442 <at> debbugs.gnu.org (full text, mbox):
> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, ari.roponen <at> gmail.com, 33442 <at> debbugs.gnu.org
> Date: Sun, 09 Dec 2018 23:08:06 +0100
>
> Dmitry Gutov <dgutov <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#33442
; Package
emacs
.
(Mon, 10 Dec 2018 13:24:01 GMT)
Full text and
rfc822 format available.
Message #83 received at 33442 <at> debbugs.gnu.org (full text, mbox):
tags 33442 fixed
close 33442 26.2
quit
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Robert Pluim <rpluim <at> gmail.com>
>> 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.
Done as 0220391c00
Closing this bug.
>> 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.
I donʼt use it myself at the moment. Iʼve only seen Ari report that he
uses is regularly.
Robert
Added tag(s) fixed.
Request was from
Robert Pluim <rpluim <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Mon, 10 Dec 2018 13:24:02 GMT)
Full text and
rfc822 format available.
bug marked as fixed in version 26.2, send any further explanations to
33442 <at> debbugs.gnu.org and Ari Roponen <ari.roponen <at> gmail.com>
Request was from
Robert Pluim <rpluim <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Mon, 10 Dec 2018 13:24:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#33442
; Package
emacs
.
(Tue, 11 Dec 2018 02:34:01 GMT)
Full text and
rfc822 format available.
Message #90 received at 33442 <at> debbugs.gnu.org (full text, mbox):
On 10.12.2018 8:20, Eli Zaretskii wrote:
>> 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.
I won't presume to speak about stability, but I've tried whatever
related bug reports I could find, and most seem fixed (bug#28236 being
the exception).
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#33442
; Package
emacs
.
(Tue, 11 Dec 2018 03:38:02 GMT)
Full text and
rfc822 format available.
Message #93 received at 33442 <at> debbugs.gnu.org (full text, mbox):
On 11.12.2018 4:33, Dmitry Gutov wrote:
> bug#28236 being the exception
...and the font rendering difference mentioned in bug#23925.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#33442
; Package
emacs
.
(Tue, 11 Dec 2018 06:28:02 GMT)
Full text and
rfc822 format available.
Message #96 received at 33442 <at> debbugs.gnu.org (full text, mbox):
> Cc: ari.roponen <at> gmail.com, 33442 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Tue, 11 Dec 2018 04:33:21 +0200
>
> On 10.12.2018 8:20, Eli Zaretskii wrote:
>
> >> 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.
>
> I won't presume to speak about stability, but I've tried whatever
> related bug reports I could find, and most seem fixed (bug#28236 being
> the exception).
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#33442
; Package
emacs
.
(Tue, 11 Dec 2018 06:32:01 GMT)
Full text and
rfc822 format available.
Message #99 received at 33442 <at> debbugs.gnu.org (full text, mbox):
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Cc: ari.roponen <at> gmail.com, 33442 <at> debbugs.gnu.org
> Date: Tue, 11 Dec 2018 05:37:34 +0200
>
> On 11.12.2018 4:33, Dmitry Gutov wrote:
> > bug#28236 being the exception
>
> ...and the font rendering difference mentioned in bug#23925.
Good to know, thanks. I think 28236 is important enough to try to
solve it before we re-enable Cairo by default.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Tue, 08 Jan 2019 12:24:03 GMT)
Full text and
rfc822 format available.
This bug report was last modified 6 years and 160 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.