In fact, the good answer to my question was maybe : go to settings, and "disable active links". It took me only one month to understand it...
On 08/12/2015 11:54 AM, Boris Faure wrote: >>>> First, Terminology is written with a lot of love, creativity and >>>> craftsmanship and it shows, and I'm not bashing it. I'm not using >>>> terminology right now, but I was a while back, and things like running >>>> apt-get update that would display a bunch of links as it scrolled by, >>>> and with the mouse pointer over the window, seemed to me at the time to >>>> be doing a lot of work for no required reason that no other terminal I >>>> am aware of would have done. Was it 'a lot' in the grand scheme? Dunno. >>>> Was it 'more' and unneeded? Yes. I recall it seeming to consume a lot >>>> of cycles on that, as the underlining lagged the scrolling quite >>>> visibly, but that could have simply been my perception. I personally >>>> found it visually disconcerting and pointless. When my build broke for >>>> some reason, it was one of the reasons I just switched back to >>>> lxterminal, rather than figuring out what caused the build breakage. > Thank you for the kind words. > The behavior you describe is no longer the case, just as raster > explains: > >> link parsing has nothing to do with it. read the code. it's TRIVIAL. >> _termio_link_find(). try time how long that takes and see if that is causing >> a >> frame drop. it won't. it just snarfs out a utf8 string with >> termio_selection_get >> () from a given coord range (which just walks cells and adds chars to a >> buffer) >> then looks at string to see what it starts with etc. and if it needs >> extending, >> is a url or is not. most of the time it is not. thats all called from >> _smart_mouseover_delay() which is triggered from a delayed job - so 0.05 >> seconds ... so as long as mouse moves at least once every 1/20th of a >> second... >> nothing will be looked for. maybe it should also consider an scroll action >> due >> to new input to delay this too, not just a mouse move. it won't re-parse just >> because content changed. it requires your mouse to move. it likely should >> cancel the link on any scroll and queue a reparse with the same job as >> opposed >> to leave a danglining link, and any ypdates to the region the link is over >> should queue the same job. but it isn't re-parsing every time your terminal >> scrolls at all. it simply doesnt have code to do that. it does it when your >> mouse moves or mouse wheel is rolled. > >> i think it's a poor feature as it hides the fact that links are even known >> about to the user. its an extra codepath that needs maintaining ad we have >> too >> many of these in e and efl by now. this is just a "no" to feature imho >> because >> the complaints are based on totally false ideas that this is consuming any >> reasonable amount of cpu. if u dont like it - disable "active links". no more >> links for you then. but ANOTHER option to only show on right click, then only >> show when modifier is pressed (then have to configure modifier, track >> modifier >> press/release) is just a waste of code, maintenance and time. > I second that. _termio_link_find() is not perfect though but there are > more important priorities than improving that. It works fine enough for > the moment. > >> fixing the parser to realize it's a c++ comment and ignore would make this >> all >> go away and requires no options and far less code than anything else >> suggested >> here. > That's probably the only thing that should be done. > > > > ------------------------------------------------------------------------------ > > > _______________________________________________ > enlightenment-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-users ------------------------------------------------------------------------------ _______________________________________________ enlightenment-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-users
