Disable highlighting the current word. lazarus / 9-Editor ---------------------------------------------------------------------- taazz · 2014-05-28 17:05 is there any way to change the mentioned setting to stop running and add a short cut to invoke it when I need it? For now I have remove all the color changes from the editor's color options but I think it is just a waste cpu to run something just to repaint some words or even not repaint them the IDE as it is it runs too many parsing procedures Is it going to stop if I uninstall the codetools or something? ---------------------------------------------------------------------- Blaazen · 2014-05-28 17:46 I hope that Source Editor is smart enough so when you set all three checkboxes off then it does not parse anything. ---------------------------------------------------------------------- Martin_fr · 2014-05-28 22:21 Yes it does not search, if all colors are off. There is on key to enable / disable it. Ideally something could be added to the pascal script macros to allow change settings like this. Macros can be assigned to keys. And doing it via macro would avoid the need to  define hundreds of configurable keys (of which the majority would never be used) ---------------------------------------------------------------------- taazz · 2014-05-29 09:31 macros is one way to do it action is my preferred way though. ---------------------------------------------------------------------- Martin_fr · 2014-05-29 12:19 I understand. But "action" will end up with many actions. Today you want this as an action. Tomorrow someone wants another setting from the option dialog. The current word highlight is no more special than many of the other option. So we would need to introduce an action for most of them. I dont see that as the path to go... Btw on the actual feature. The search is done very very effective. The pascal highlighter stores info for each line. This info is needed for the proper highlight (so when you type in most cases only one, maybe 2 lines) are re-scanned. This info allows the search to find the matching line *without* looking at the line text. It then just needs to scan one line for the keyword. So it is very fast. (2 lines on a tripple keyword) What takes way more time, is the repaint. Because invalidating a word on for example line 10 (visible 10th line on screen) and line 20 (visible 20th...) will (forced by the OS / afaik  any OS) invalidate the entire rectangle including all lines from 10 to 20. Yet that goes usually unnoticed. The one case where occasionally on a slow computer it may be noticeable is scrolling. If during scrolling the caret touches a word that has a match, then for that line scrolling may be just a tick slower. Also in 1.3 under "Markup and Matches" you can select which pairs to highlight and which not. So you can have "try finally", but not "begin end" or whatever you like. (and 1.3 offers "if then else" too) ---------------------------------------------------------------------- taazz · 2014-05-29 13:37 Quote from: Martin_fr on May 29, 2014, 02:19:26 pmI understand. But "action" will end up with many actions. Today you want this as an action. Tomorrow someone wants another setting from the option dialog. The current word highlight is no more special than many of the other option. So we would need to introduce an action for most of them. I dont see that as the path to go... Just have a mechanism where I can register an action that can be shown in the short cut options and stop woring about who is going to implement what or even supporting those whats. Let me and any 3rd party developer create their own packages with actions to register so they can customize the ide their way, simple expandable and no support except perhaps a couple of examples on how to write action for the most important parts of the ide eg codetools, highlighting etc and let the community extend and redefine as needed. Quote from: Martin_fr on May 29, 2014, 02:19:26 pmBtw on the actual feature. The search is done very very effective. The pascal highlighter stores info for each line. This info is needed for the proper highlight (so when you type in most cases only one, maybe 2 lines) are re-scanned. This info allows the search to find the matching line *without* looking at the line text. It then just needs to scan one line for the keyword. So it is very fast. (2 lines on a tripple keyword) What takes way more time, is the repaint. Because invalidating a word on for example line 10 (visible 10th line on screen) and line 20 (visible 20th...) will (forced by the OS / afaik  any OS) invalidate the entire rectangle including all lines from 10 to 20. Yet that goes usually unnoticed. The one case where occasionally on a slow computer it may be noticeable is scrolling. If during scrolling the caret touches a word that has a match, then for that line scrolling may be just a tick slower. Also in 1.3 under "Markup and Matches" you can select which pairs to highlight and which not. So you can have "try finally", but not "begin end" or whatever you like. (and 1.3 offers "if then else" too) Well I never doubted the effectiveness of the code I just find the "highlight current word" feature more destructing than helpful especially since most of the times I'm going to use sync editing I see no real value on the feature as long as it doesn't consume my cpu cycles I see no reason to even attempt to put it on a short cut let then ones that want enable it. ---------------------------------------------------------------------- Martin_fr · 2014-05-29 13:56 QuoteLet me and any 3rd party developer create their own packages with actions to register so they can customize the ide their way That should be possible?  Jedi code formatter adds a menu, that can have an optional shortcode. SourceEditor has an interface for packages too. I do not thing you can change the EditorOptions (yet) but you can directly control SynEdit.