Re: Platform independent graphical display for Emacs

["Óscar Fuentes" <ofv@wanadoo.es>]

Eli Zaretskii <eliz@gnu.org> writes:

>> A closer look at Skia makes me think that it is not a good candidate for
>> Emacs, for several reasons. But Skia was just an example, we (or, better
>> said, the OP) can examine what other options are available.
>
> Yes, examples are being thrown here and there without any relevance,
> just to make a point in a dispute, it seems.  It doesn't help to have
> a useful discussion.

It also happens that people make a big fuss over minor details instead
of dicussing the meat of the matter.

I don't think the outcome of this "dispute" depends on an example of
what it could be used. 

BTW, on the Skia-Emacs inadequacy issue, I would not be sure about what
part to blame the most.

>> > Please explain in detail what the new graphical capabilities are, and
>> > how using a different graphics library will help.
>> 
>> We could turn the frame into a canvas. Take
>> display-fill-column-indicator for instance. Instead of faking a line
>> with characters, we could simply draw the line as a graphic object.
>
> If you think this kind of enhancement could materialize just by
> changing the *term backends of the Emacs display, you don't have a
> clear idea about the relevant architecture aspects of that.  It is
> nigh impossible to do something like that without the knowledge of
> xdisp.c and dispnew.c.  I'm telling you that as the single person
> around here who has any kind of practical experience in implementing
> something like that: the TTY menus do something very similar, and that
> code gets away by the skin of its teeth, and would be probably simply
> impossible with GUI display.
>
> Throwing around such ideas without any real knowledge is simply
> irresponsible.  Someone might believe you and spend some non-trivial
> time trying to implement that.

You are overthinking something that's actually very simple: locating the
x coordinate of the n-th column and drawing a vertical line from top to
bottom of the window on each redisplay. Any sane graphics system can do
that simple, trivial thing. If it is difficult to do it in Emacs, that
only demonstrates how limited the display engine is on its capabilities.

If I were the hacker implementing the proposal, I would start with the
data structures that hold what needs to be shown and with a surface:
then, do the rendering. I know it is not as straightfordward as just
throwing a bunch of text on a textbox, but what I've seen on the sources
and your claims makes me think that any attempt at reusing the legacy
code (the one that actually paints the frame's contents) would be a
waste of time.

You are talking as if the complexity, quirks and limitations of Emacs'
display engine were something good, something to be preserved, when it
is quite the contrary, ever more when so few people understands it. By
your description, the current display engine is a big liability and any
proposal that could end with replacing it with something comprehensible
by mere mortals should be welcome.