emacs-devel
[Top][All Lists]
Advanced

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

Re: Emacs canvas support


From: David Engster
Subject: Re: Emacs canvas support
Date: Wed, 29 Apr 2020 21:23:30 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.91 (gnu/linux)

>> From: David Engster <address@hidden>
>> Cc: Eli Zaretskii <address@hidden>,  address@hidden
>> Date: Wed, 29 Apr 2020 18:14:55 +0200
>
>> 
>> IMHO, What would be much more exciting, is if you could draw directly
>> over normal text. This would enable a whole new set of
>> possibilities. For instance, I always liked visual diff tools like
>> 'Meld' or 'Code Compare', but I don't see how you could do this with
>> Emacs. Or things like proper indentation guides, or widgets inside text
>> for code folding. Yes, those can be done in Emacs today, but it is very
>> difficult to get right and often not really satisfactory (weird
>> interactions between packages, too slow, etc.).
>
> AFAIU, Meld seems to draw the graphics _between_ windows, and only
> highlights the source lines with background colors.  I think we can do
> that if we use an extra window in-between the two being compared, and
> put images in that extra window to show the graphical description of
> the changes between the two versions.

I actually tried exactly that, many years ago. I dimly remember that
handling the coordinates was pretty complicated and it was slow. Like,
orders of magnitude too slow, even with the simplest and fastest image
types. There was no way you would ever be able to scroll text and update
the diff visualization alongside it. It was just a flickery mess. It
would of course be possible to visualize the diff in an idle timer and
not during scrolling, but that is exactly what I mean above with "not
really satisfactory", so I gave up.

> Drawing over normal text, if we don't want to redesign the entire
> display engine, needs some new kind of "display element" ( a sibling
> to "character", "image", "stretch", etc.), one that doesn't
> necessarily have any effect on the metrics of the screen lines it is
> drawn upon.  I'm not sure I have a clear idea about what features such
> a drawing will need to support, but it could be possible to add such
> an element with not too much effort.  Would someone want to come up
> with a reasonable list of requirements for such a feature?

When I played around with it, I thought a first iteration could be to
simply expose the basic Cairo API to ELisp, which is essentially drawing
lines/arcs/rectangles and filling. I thought that maybe it would be
possible that one could handle this like a graphical transparent
overlay, but I'm afraid I'm way out of my depth here. I have no idea how
one would handle scrolling, for instance.

-David



reply via email to

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