On Tue, Aug 11, 2015 at 4:32 PM, Christopher Barry <[email protected]> wrote: > On Tue, 11 Aug 2015 09:02:56 +0900 > Carsten Haitzler (The Rasterman) <[email protected]> wrote: >>On Mon, 10 Aug 2015 09:17:46 -0400 Christopher Barry >><[email protected]> said: >>> On Mon, 10 Aug 2015 10:40:40 +0200 >>> Pierre Couderc <[email protected]> wrote: >>> >>> >I have a (very) small problem when editing C++ : >>> > >>> ><code> >>> > >>> >///////////////////// C++? comment >>> >o=f; >>> > >>> ></code> >>> > >>> >if I click on //// it opens me file:/// in the browser... >>> > >>> >I understand that usually it is wanted, but in the current case it >>> >is not... >>> > >>> >>> Seems like that feature, not at all limited to Terminology mind >>> you, an handy as it may be at times, really should require a modifier >>> key when clicked to do anything (or a right-click). >>> Highlighting/Copying text that is 'hot' like this is also a PITA >>> because of this UI feature. >>> >>> Overall, I would say it generally causes the computer a lot of >>> parsing work for nothing. Now, if the parsing only occurred when the >>> mouse was over a string and ctl-alt (or whatever) was pressed, and >>> then it resolved it as a link and then clicking it would go there, >>> then that would be quite useful, performant and unobtrusive. >> >>it only parses when the mouse is over a link - no mods. the parsing is >>nothing really work-wise. you can also still select just fine. its a >>click without a drag (no selection) that causes the link to be >>activated. the only obtrusiveness is the visual underline. > > 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.
Yes, I have also noticed that during scrolling we may drop some frame due to the link parsing. I am guessing it would be just a fine patch to trigger the parsing in an idler that would be triggered only when the scrolling is done. That would stop unecessary cost. And you are also right that this is only a feeling as this doesn't affect the timing of running any command in the shell, it just drop some frame (I did some benchmarking on the subject a while back). > I guess my point about it, and it's just my opinion, is that needing to > click a link that appears in a terminal (for me) is probably the less > followed code path, therefore it should probably require a modifier or > context menu to activate. And, maybe should require the text being > highlighted *before* ever wasting even one cycle thinking about it... > > Something like: > > highlight-> > right-click-> > context-menu->[Copy|Follow|Open|Run|Search|Locate|etc.] > > is still very useful and a bit cleaner UI presentation-wise IMHO. > > And, having that action list in the menu be easily configurable and > extensible would be very, very useful indeed. That is an interesting feature request. I think you should open a ticket on phab just for that feature alone. Thanks, -- Cedric BAIL ------------------------------------------------------------------------------ _______________________________________________ enlightenment-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-users
