AW: Synchronize syntax highlighting

Hi Christian! > > I've tried various suggestions (minlines, synmaxcol, etc.), > > read the manual for information about possible tweaks > > searched the web, ... - to no avail! > > > > Trying with various numbers in configs like > > set smc=9000 > > syntax sync minlines=1000 maxlines=1000 > > > > I'm still getting no sync in a (even non-demanding) test case: > > opening a 476 line file, max. columns 84 => highlighting okay, > > searching for a text that appears in line 438 => NO SYNC here! > > (After scrolling 3 pages up the sync was okay again.) > > > > More testing... > > Opened a 80x25 terminal window. > > Same testcase as above. => highlighting okay!!! > > Resized the terminal window to 120x50. > > Opened the file again, same testcase => NO SYNC ! > > Resized the terminal window back to 80x25. > > Opened the file again, same testcase => highlighting okay > > > > This is strange!!! > > Highlighting depends on the terminal size, not on the actual text! > > does > :syn sync fromstart > > help? I've meanwhile extended my file and the effect wasn't seen then any more, but with an old version this trick indeed re-established the sync. - Thanks! > > This depends on the current syntax script and file being used, but it is > worth a try when this happens. I suppose this happens with algol68 > files? This has a hard-coded limit of 500 lines. While I had observed this effect in the past also with other languages or text data in this case it's indeed an Algol 68 source. After your hint I've meanwhile also noticed the hard-coded limit. Do these limits make sense? (They appear to be quite small anyway!) Would it hurt to remove those limits? (Or define higher values?) The parameters are defined as: syn sync minlines=250 maxlines=500 which I think means a context of +/- 250 lines considered for syncing? - That's not much given that the sync is obviously not done on language-specific syntax sync points. - I've now changed my local ~/.vim/syntax/algol68.vim and adjusted these values to 1000 each[*]; this solved the issue - at least locally, and for this specific source; let's see how far I get with those values. [*] Is that sensible or should 'maxvalue' be twice as large to to obtain the +/- 1000 context range? (The parameter names are a bit confusing to me; a "sync-lines-before" and "sync-lines-after" semantics might be clearer.) Though I'm wondering that a user-specific setting (in .vimrc) cannot override the system setting here. (But that may be an effect of this syntax file is in my system also locally below ~/.vim/syntax, and therefore it takes precedence?) And the dependency of the effect on the window size is still a mystery to me! (To me that smells like a bug or design problem in this specific case.) > It is not generally recommended to use syn sync fromstart in syntax > script, because it comes with a performance penalty, but in cases when > you notice syntax being off, it is worth a try. Yes, that's certainly useful and good to know! With Vim I've never had any performance problem editing program's text. (Only on *very* large textual data there's regularly a performance issue.) I'd think an increase of (hard-coded) sync values for program texts would generally not hurt. (Or are people really writing _monolithic code_ of tens of thousands line of code in one file without structuring it in files?) There's a couple questions raised in this post; can you tell me whether you think some of these needs attention to be changed? Thanks again! Regards, Janis -- -- You received this message from the "vim_use" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/vim_use/AS2SPRMB0054C3CAB8CDA9B45BF0E344F3DD2%40AS2SPRMB0054.eurprd05.prod.outlook.com.