SANGOI DINO wrote:
I completely agree with you, I've tried it before posting my patch, and it didn't work. It's not so easy because cover_exposed_area() calls send_attr_str(), and this function is called also by msw_smart_puts() to write to Vterm. So changing this means duplicating send_attr_str(),msw_write_smgchars() and msw_reverse_video().It is doable, but as Jed still calls wterm functions to write to Vterm, I don't see a big win here. Much better would be if jed writes directly to Vterm and then calls a function to say: you should redraw this, but it's not like it works today, and changing it may not be so easy (most calls starts inside slsmg in slang). Later, Dino
I implemented such a thing in fljed: when jed sends a refresh, vterm is updated, but when FLTK surface needs a redraw, all the necesasry data is read from vterm and written to the screen. But then I found out (from Johns posting) that there is a variable VTerm_Suspend_Update that has the same effect - nothing gets written to vterm. I discovered another thing. I do not know for other terminals, but this is true for fljed: Jed keeps the content of the screen in an internal buffer from the SLsmg system. When anything changes in the SLsmg buffer, only the changed areas are sent to vterm using smart_puts. Smart_puts then copies the data to vterm. I did some logging and found out that smart_puts is the only function ever called for screen updates. Maybe I compiled fljed to behave so and maybe it can be made to work in a different way. But if we had access to the SLsmg screen buffer (or do we?) would we still need vterm? Marko -------------------------- To unsubscribe send email to <jed-users-request@xxxxxxxxxxx> with the word "unsubscribe" in the message body. Need help? Email <jed-users-owner@xxxxxxxxxxx>.