Re: Emacs as browser (was Re: Concurrency, again)

[Dov Grobgeld]

For whatever it is worth, I checked out the branch origin/old-branches/cairo compiled it and it seemed to work just fine under Fedora 24. I couldn't reproduce either of the bugs #20997 nor #23925.

In any case these two bugs both discuss refresh issues, which is outside of the scope of cairo which is a rendering engine.

My feeling is that the only issue in the bug tracker that you may need an "cairo expert" for, is the memory leak in #22961. The rest of the bugs are more related to exposure triggered redraws and interaction with the window manager. These are certainly related to the cairo branch, but have nothing to do with cairo per se.

Regards,

Dov

On Thu, Oct 20, 2016 at 6:42 PM, Eli Zaretskii <address@hidden> wrote:

> Date: Thu, 20 Oct 2016 11:15:27 -0400
> From: "Perry E. Metzger" <address@hidden>
> Cc: address@hidden, address@hidden, address@hidden,
>  address@hidden, address@hidden
>
> (There are four front ends now, right? MS Windows, X, NextStep and
> tty, yes?)

Yes.  Although the TTY back-end has some quirks in the MS-Windows
build, because termcap/terminfo is not supported by the Windows
console (or wasn't until Windows 10.1).

> Is there any documentation about the internal interfaces between the
> terminal layer and the back end?

Look at 'struct redisplay_interface' (for X it gets populated around
line 12470 of xterm.c) and at hooks in 'struct terminal' (populated
for X in x_create_terminal).  TTYs don't have 'struct
redisplay_interface' (for historical reasons), but instead call the
corresponding functions directly.

> I doubt I'm skilled enough in something like Wayland to do this work
> but I'd like to get a bit of a sense of how awful the work is.

Thanks for trying.

> And what *did* happen to the Cairo stuff?

I has bugs that we cannot fix because no one knowns enough about Cairo
drawing.  The person who wrote the code left the Emacs development
short time after merging the code.

> Cairo would make Wayland easy if I recall correctly.

That was the idea behind introducing it.

> > IMO, working on that is much more important for the future of Emacs
> > than any other improvements, including, but not limited to, the
> > "future of Emacs Lisp" discussions, the "feature/integrated-elpa"
> > discussions, etc.  Developing Emacs without first-class experts on X
> > on board makes no sense to me.
>
> Perhaps no first class experts in the area are aware that Emacs needs
> the help?

Perhaps.