Re: proposed patch: Make syntax highlighting independent of 'iskeyword' setting
Updated patch attached.
Best,
Christian
--
Raketentriebwerk:
gibt es in Schubladen zu kaufen
--
--
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
diff --git a/runtime/doc/options.txt b/runtime/doc/options.txt
--- a/runtime/doc/options.txt
+++ b/runtime/doc/options.txt
@@ -4489,6 +4489,9 @@ A jump table for the options with a shor
'*', '"' and '|' (so that CTRL-] on a command finds the help for that
command).
When the 'lisp' option is on the '-' character is always included.
+ This option also influences syntax highlighting.
+ For syntax highlighting this option can be specified separately by
+ using |:syn-iskeyword| (and overrides this option).
NOTE: This option is set to the Vi default value when 'compatible' is
set and to the Vim default value when 'compatible' is reset.
diff --git a/runtime/doc/syntax.txt b/runtime/doc/syntax.txt
--- a/runtime/doc/syntax.txt
+++ b/runtime/doc/syntax.txt
@@ -3444,6 +3444,32 @@ SPELL CHECKING *:syn-spell*
To activate spell checking the 'spell' option must be set.
+SYNTAX ISKEYWORD SETTING*:syn-iskeyword*
+
+:sy[ntax] iskeyword [clear | {option}]
+ This defines the 'iskeyword' option for syntax highlighting.
+
+ clear: Syntax specific iskeyword setting is disabled and the
+ buffer-local 'iskeyword' setting is used.
+ {option}Set the syntax 'iskeyword' option to a new value.
+
+ Example: >
+ :syntax iskeyword @,48-57,192-255,$,_
+<
+ This would set the syntax specific iskeyword option to include all
+ alphabetic characters, plus the numeric characters, all accented
+ characters and also includes the "_" and the "$".
+
+ If no option is given, the current setting will be output.
+
+ Setting this option, influences what |/\k| matches in syntax patterns
+ and also determines where |:syn-keywords| will be checked for a new
+ match.
+
+ It is recommended when writing syntax files, to set the syntax
+ 'iskeyword' option to the correct value for the specific syntax
+ language (e.g. the global 'isk' option) to have the syntax
+ highlighting work independently of the users 'isk' settings.
DEFINING KEYWORDS *:syn-keyword*
@@ -3475,6 +3501,7 @@ DEFINING KEYWORDS *:syn-keyword*
isn't, the keyword will never be recognized.
Multi-byte characters can also be used. These do not have to be in
'iskeyword'.
+ See |:syn-iskeyword| for defining syntax specific iskeyword settings.
A keyword always has higher priority than a match or region, the
keyword is used if more than one item matches. Keywords do not nest
diff --git a/src/buffer.c b/src/buffer.c
--- a/src/buffer.c
+++ b/src/buffer.c
@@ -1955,6 +1955,7 @@ free_buf_options(buf, free_p_ff)
clear_string_option(&buf->b_p_nf);
#ifdef FEAT_SYN_HL
clear_string_option(&buf->b_p_syn);
+clear_string_option(&buf->b_s.b_syn_isk);
#endif
#ifdef FEAT_SPELL
clear_string_option(&buf->b_s.b_p_spc);
diff --git a/src/option.c b/src/option.c
--- a/src/option.c
+++ b/src/option.c
@@ -5484,6 +5484,7 @@ check_buf_options(buf)
#endif
#ifdef FEAT_SYN_HL
check_string_option(&buf->b_p_syn);
+check_string_option(&buf->b_s.b_syn_isk);
#endif
#ifdef FEAT_SPELL
check_string_option(&buf->b_s.b_p_spc);
@@ -10779,6 +10780,7 @@ buf_copy_options(buf, flags)
/* Don't copy 'syntax', it must be set */
buf->b_p_syn = empty_option;
buf->b_p_smc = p_smc;
+ buf->b_s.b_syn_isk = vim_strsave(p_isk);
#endif
#ifdef FEAT_SPELL
buf->b_s.b_p_spc = vim_strsave(p_spc);
diff --git a/src/structs.h b/src/structs.h
--- a/src/structs.h
+++ b/src/structs.h
@@ -1361,6 +1361,8 @@ typedef struct {
#if !defined(FEAT_SYN_HL) && !defined(FEAT_SPELL)
int dummy;
#endif
+char_u b_syn_chartab[32]; /* syntax iskeyword option */
+char_u *b_syn_isk; /* iskeyword option */
} synblock_T;
diff --git a/src/syntax.c b/src/syntax.c
--- a/src/syntax.c
+++ b/src/syntax.c
@@ -993,14 +993,23 @@ syn_match_linecont(lnum)
{
regmmatch_T regmatch;
int r;
+char_u buf_chartab[32]; /* chartab array for syn iskyeyword */
if (syn_block->b_syn_linecont_prog != NULL)
{
+ /* use syntax iskeyword option */
+ if (syn_block->b_syn_isk != empty_option)
+ {
+ memcpy(buf_chartab, syn_buf->b_chartab, (size_t)32);
+ memcpy(syn_buf->b_chartab, syn_win->w_s->b_syn_chartab, (size_t)32);
+ }
regmatch.rmm_ic = syn_block->b_syn_linecont_ic;
regmatch.regprog = syn_block->b_syn_linecont_prog;
r = syn_regexec(®match, lnum, (colnr_T)0,
IF_SYN_TIME(&syn_block->b_syn_linecont_time));
syn_block->b_syn_linecont_prog = regmatch.regprog
Re: proposed patch: Make syntax highlighting independent of 'iskeyword' setting
Christian Brabandt wrote:
> Hi vim-dev!
>
> On Sa, 31 Okt 2015, Christian Brabandt wrote:
>
> > On Fr, 30 Okt 2015, Bram Moolenaar wrote:
> >
> > > I suppose that for syntax highlighting using a :syntax command is
> > > appropriate. For other contexts we might still want to use an actual
> > > setting.
> > >
> > > Not sure about the ":syn option" command. Why not use ":syn iskeyword"?
> >
> > That was my first approach. Than I thought perhaps later we'll need
> > another option to be set, perhaps 'isfname' so I thought, let's make it
> > abstract enough that it can be easily extended later if needed.
> >
> > > In a way, all :syn commands change options/settings in some way.
> >
> > Actually I even thought about making e.g. syn spell or syn sync an alias
> > for syn option spell
> >
> > > I would not see this as an option, but part of the syntax definition.
> > > Thus ":syn clear" removes it and goes back to 'iskeyword'.
> >
> > I'll send an updated patch later this week.
>
> Attached is an updated patch, including a test
[...]
> When the 'lisp' option is on the '-' character is always included.
> + This option also influences syntax highlighting, see |:syn-iskeyword|
> + how to circumvent it.
> NOTE: This option is set to the Vi default value when 'compatible' is
When we have the new feature, it should be mentioned when the
'iskeyword' value applies to syntax or not. Something like "for syntax
the keyword characters can be specified separately".
> +SYNTAX ISKEYWORD SETTING *:syn-iskeyword*
> +
> +:sy[ntax] iskeyword [clear | {option}]
> + This defines the 'iskeyword' option for the syntax highlighting.
> +
> + clear: Reset the syntax 'iskeyword' option to its buffer
> + local value.
It would be simpler to understand to say that the syntax-specific value
is omitted and the value of the 'iskeyword' option is used.
> + {option}Set the syntax 'iskeyword' option to the new value.
Please add an example that shows what it looks like. e.g., the normal
value with $ added.
> + It is recommended when writing syntax files, to set the syntax
> + 'iskeyword' option to a sane value (e.g. the global 'isk' option) to
> + have the syntax highlighting work independently of the users 'isk'
> + settings.
I would call it "correct value for the syntax" instead of "sane value".
--
>From "know your smileys":
:-&Eating spaghetti
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--
--
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: proposed patch: Make syntax highlighting independent of 'iskeyword' setting
Hi vim-dev!
On Sa, 31 Okt 2015, Christian Brabandt wrote:
> On Fr, 30 Okt 2015, Bram Moolenaar wrote:
>
> > I suppose that for syntax highlighting using a :syntax command is
> > appropriate. For other contexts we might still want to use an actual
> > setting.
> >
> > Not sure about the ":syn option" command. Why not use ":syn iskeyword"?
>
> That was my first approach. Than I thought perhaps later we'll need
> another option to be set, perhaps 'isfname' so I thought, let's make it
> abstract enough that it can be easily extended later if needed.
>
> > In a way, all :syn commands change options/settings in some way.
>
> Actually I even thought about making e.g. syn spell or syn sync an alias
> for syn option spell
>
> > I would not see this as an option, but part of the syntax definition.
> > Thus ":syn clear" removes it and goes back to 'iskeyword'.
>
> I'll send an updated patch later this week.
Attached is an updated patch, including a test
.
Mit freundlichen Grüßen
Christian
--
Irren ist menschlich, Vergeben göttlich und Vergessen human.
--
--
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
diff --git a/runtime/doc/options.txt b/runtime/doc/options.txt
--- a/runtime/doc/options.txt
+++ b/runtime/doc/options.txt
@@ -4489,6 +4489,8 @@ A jump table for the options with a shor
'*', '"' and '|' (so that CTRL-] on a command finds the help for that
command).
When the 'lisp' option is on the '-' character is always included.
+ This option also influences syntax highlighting, see |:syn-iskeyword|
+ how to circumvent it.
NOTE: This option is set to the Vi default value when 'compatible' is
set and to the Vim default value when 'compatible' is reset.
diff --git a/runtime/doc/syntax.txt b/runtime/doc/syntax.txt
--- a/runtime/doc/syntax.txt
+++ b/runtime/doc/syntax.txt
@@ -3444,6 +3444,25 @@ SPELL CHECKING *:syn-spell*
To activate spell checking the 'spell' option must be set.
+SYNTAX ISKEYWORD SETTING*:syn-iskeyword*
+
+:sy[ntax] iskeyword [clear | {option}]
+ This defines the 'iskeyword' option for the syntax highlighting.
+
+ clear: Reset the syntax 'iskeyword' option to its buffer
+ local value.
+ {option}Set the syntax 'iskeyword' option to the new value.
+
+ If no option is given, the current setting will be output.
+
+ Setting this option, influences what |/\k| matches in syntax patterns
+ and also determines where |:syn-keywords| will be checked for a new
+ match.
+
+ It is recommended when writing syntax files, to set the syntax
+ 'iskeyword' option to a sane value (e.g. the global 'isk' option) to
+ have the syntax highlighting work independently of the users 'isk'
+ settings.
DEFINING KEYWORDS *:syn-keyword*
@@ -3475,6 +3494,7 @@ DEFINING KEYWORDS *:syn-keyword*
isn't, the keyword will never be recognized.
Multi-byte characters can also be used. These do not have to be in
'iskeyword'.
+ See |:syn-iskeyword| for defining syntax specific iskeyword settings.
A keyword always has higher priority than a match or region, the
keyword is used if more than one item matches. Keywords do not nest
diff --git a/src/buffer.c b/src/buffer.c
--- a/src/buffer.c
+++ b/src/buffer.c
@@ -1955,6 +1955,7 @@ free_buf_options(buf, free_p_ff)
clear_string_option(&buf->b_p_nf);
#ifdef FEAT_SYN_HL
clear_string_option(&buf->b_p_syn);
+clear_string_option(&buf->b_s.b_syn_isk);
#endif
#ifdef FEAT_SPELL
clear_string_option(&buf->b_s.b_p_spc);
diff --git a/src/option.c b/src/option.c
--- a/src/option.c
+++ b/src/option.c
@@ -5484,6 +5484,7 @@ check_buf_options(buf)
#endif
#ifdef FEAT_SYN_HL
check_string_option(&buf->b_p_syn);
+check_string_option(&buf->b_s.b_syn_isk);
#endif
#ifdef FEAT_SPELL
check_string_option(&buf->b_s.b_p_spc);
@@ -10779,6 +10780,7 @@ buf_copy_options(buf, flags)
/* Don't copy 'syntax', it must be set */
buf->b_p_syn = empty_option;
buf->b_p_smc = p_smc;
+ buf->b_s.b_syn_isk = vim_strsave(p_isk);
#endif
#ifdef FEAT_SPELL
buf->b_s.b_p_spc = vim_strsave(p_spc);
diff --git a/src/structs.h b/src/structs.h
--- a/src/structs.h
+++ b/src/structs.h
@@ -1361,6 +1361,8 @@ typedef struct {
#if !defined(FEAT_SYN_HL) && !defined(FEAT_SPELL)
int dummy;
#endif
+char_u b_syn_chartab[32]; /* syntax iskeyword option */
+char_u *b_syn_isk; /* iskeyword option */
} synblock_T;
diff --git a/src/syntax.c b/src/syntax.c
--- a/src/syntax.c
+++ b/src/syntax.c
@@ -993,14 +993,23 @@ syn_match_linecont(lnum)
{
regmmatch_T regmatch;
int r;
+char_u buf
Re: proposed patch: Make syntax highlighting independent of 'iskeyword' setting
On Fr, 30 Okt 2015, Bram Moolenaar wrote: > I suppose that for syntax highlighting using a :syntax command is > appropriate. For other contexts we might still want to use an actual > setting. > > Not sure about the ":syn option" command. Why not use ":syn iskeyword"? That was my first approach. Than I thought perhaps later we'll need another option to be set, perhaps 'isfname' so I thought, let's make it abstract enough that it can be easily extended later if needed. > In a way, all :syn commands change options/settings in some way. Actually I even thought about making e.g. syn spell or syn sync an alias for syn option spell > I would not see this as an option, but part of the syntax definition. > Thus ":syn clear" removes it and goes back to 'iskeyword'. I'll send an updated patch later this week. Best, Christian -- Zeitknappheit ist die Rache des Wohlstandes. Die Navacho Indianer kannten 256 Gegenstände. All unsere Gegenstände erfordern unsere Zeit, das Resultat ist Hektik und Streß. -- Misereor -- -- -- You received this message from the "vim_dev" 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_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: proposed patch: Make syntax highlighting independent of 'iskeyword' setting
Nikolay Pavlov wrote: > 2015-10-27 14:44 GMT+03:00 Christian Brabandt : > > Hi, > > currently setting 'isk' option has - among others - an unwanted side > > effect on the syntax highlighting. > > > > For example by removing the '_' from the 'iskeyword' setting, defined > > syntax keywords start matching where they didn't match before. > > > > E.g. in a SQL buffer, > > > > CREATE TABLE FOOBAR( > > CRTD_BY VARCHAR2(100)); > > > > Setting :setlocal isk-=_ will make the 'BY' highlighted as syntax > > keyword. I believe this is unwanted and therefore I propose the > > following enhancement: > > > > Add a new syntax command ":syn option iskeyword" for specifically > > setting the 'iskeyword' setting to sane values. So in a syntax file, one > > could set: > > > :syn option iskeyword @,48-57,_,192-255 > > < > > and have syntax highlighting make work as expected independent on the > > users choice of setting the 'isk' setting. If this is not done, syntax > > highlighting will depend on the users 'isk' setting as before. > > > > The current syntax iskeyword setting can be seen by using: > > > :syn option iskeyword > > < > > > > And it can be reset to the old behaviour using: > > > :syn option iskeyword clear > > < > > > > I did add the syn-option command, so that later on, it can be extended > > to other options as well, if this should be necessary. > > > > Attached is a proof of concept patch, that does this. > > > > Any comments? > > Somewhere in the Neovim bug tracker I suggested that it would be > better to do another thing: > > When syntax file is being loaded > save user &iskeyword setting then > at the each :syn statement save :syn-statement-specific &iskeyword > setting, attached to :syn statement. > After syntax file was loaded restore user &iskeyword setting. I think all statements in a syntax should use the same definition of what is a keyword character, not an a per-statement level. Otherwise the rule that keywords overrule matches and regions becomes very complex. > From your description this is going to work like if all syntax authors > replaced :setl isk with :syn option iskeyword. But note the > differences: > > 1. No need to change existing syntax files. > 2. &iskeyword setting is attached to *:syn statement*, not buffer or > window structure. Note that user &iskeyword setting is not the only > cause for highlighting breakage: there is also :syn include and files > included this way may have different &iskeyword setting (:syn include > should also save/restore &iskeyword thus). > > This will, of course, either raise memory footprint very much or > require managing &iskeyword tables separately of syntax definitions. > > Note that my approach is not fixing syntax highlighting affected by > user &iskeyword setting. My approach is fixing syntax files, messing > with my &iskeyword setting. :syn option iskeyword is not going to > solve this because it is not currently used. And with policies > “runtime file updates can only be sent by file maintainers” (like if > they can’t pull in the changes) and “other people commits are too ? to > merge them into the master” with “squash the world before updating > runtime files” (so that it is harder to maintain a parrallel branch, > and there are no explanations “why was this change made” in commit > messages and “who made this change” in other metadata) this is not > going to happen ever. The syntax file could perhaps also say "Use the default 'iskeyword' value, not the current value. That's because 'iskeyword' might be changed for completely different reasons. Anyway, one could also just put in the default value, so that it doesn't depend on it. -- hundred-and-one symptoms of being an internet addict: 57. You begin to wonder how on earth your service provider is allowed to call 200 hours per month "unlimited." /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- You received this message from the "vim_dev" 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_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: proposed patch: Make syntax highlighting independent of 'iskeyword' setting
Christian wrote: > currently setting 'isk' option has - among others - an unwanted side > effect on the syntax highlighting. > > For example by removing the '_' from the 'iskeyword' setting, defined > syntax keywords start matching where they didn't match before. > > E.g. in a SQL buffer, > > CREATE TABLE FOOBAR( > CRTD_BY VARCHAR2(100)); > > Setting :setlocal isk-=_ will make the 'BY' highlighted as syntax > keyword. I believe this is unwanted and therefore I propose the > following enhancement: > > Add a new syntax command ":syn option iskeyword" for specifically > setting the 'iskeyword' setting to sane values. So in a syntax file, one > could set: > > :syn option iskeyword @,48-57,_,192-255 > < > and have syntax highlighting make work as expected independent on the > users choice of setting the 'isk' setting. If this is not done, syntax > highlighting will depend on the users 'isk' setting as before. > > The current syntax iskeyword setting can be seen by using: > > :syn option iskeyword > < > > And it can be reset to the old behaviour using: > > :syn option iskeyword clear > < > > I did add the syn-option command, so that later on, it can be extended > to other options as well, if this should be necessary. > > Attached is a proof of concept patch, that does this. > > Any comments? Separately defining keyword characters in different contexts has been a todo item for a very long time. I suppose that for syntax highlighting using a :syntax command is appropriate. For other contexts we might still want to use an actual setting. Not sure about the ":syn option" command. Why not use ":syn iskeyword"? In a way, all :syn commands change options/settings in some way. I would not see this as an option, but part of the syntax definition. Thus ":syn clear" removes it and goes back to 'iskeyword'. -- Over the years, I've developed my sense of deja vu so acutely that now I can remember things that *have* happened before ... /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- You received this message from the "vim_dev" 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_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: proposed patch: Make syntax highlighting independent of 'iskeyword' setting
Hi Tony! On Di, 27 Okt 2015, Tony Mechelynck wrote: > What about using the already existing commands below (assuming Vim > version 6.2 or later)? > > let s:save_isk = &l:isk > try > setl isk&vim" or to whatever value is desired > … > … > … > finally > let &l:isk = s:save_isk > endtry > > IMHO authors who won't bother saving and restoring the option won't > use your new command either, especially since it will have to be > bracketed by if exists() in all third-party syntax scripts, to guard > against the possibility of running on a Vim compiled without the > patch. That does not work, as the isk setting is applied at runtime. Best, Christian -- Ist Weltfrieden ohne religiöse Abrüstung überhaupt möglich? -- M.S. Salomon (eigentl. Michael Schmidt-Salomon) -- -- You received this message from the "vim_dev" 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_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: proposed patch: Make syntax highlighting independent of 'iskeyword' setting
2015-10-27 23:12 GMT+03:00 Tony Mechelynck : > What about using the already existing commands below (assuming Vim > version 6.2 or later)? > > let s:save_isk = &l:isk > try > setl isk&vim" or to whatever value is desired > … > … > … > finally > let &l:isk = s:save_isk > endtry > > IMHO authors who won't bother saving and restoring the option won't > use your new command either, especially since it will have to be > bracketed by if exists() in all third-party syntax scripts, to guard > against the possibility of running on a Vim compiled without the > patch. And what is this construct for? When processing syntax rules Vim uses current &iskeyword option value, *not* the one which used to be when syntax rule was defined. It is my variant that adds the behaviour which makes saving/restoring useful. Except that I expect saving/restoring to be done by Vim. > > > Best regards, > Tony. > > On Tue, Oct 27, 2015 at 12:44 PM, Christian Brabandt > wrote: >> Hi, >> currently setting 'isk' option has - among others - an unwanted side >> effect on the syntax highlighting. >> >> For example by removing the '_' from the 'iskeyword' setting, defined >> syntax keywords start matching where they didn't match before. >> >> E.g. in a SQL buffer, >> >> CREATE TABLE FOOBAR( >> CRTD_BY VARCHAR2(100)); >> >> Setting :setlocal isk-=_ will make the 'BY' highlighted as syntax >> keyword. I believe this is unwanted and therefore I propose the >> following enhancement: >> >> Add a new syntax command ":syn option iskeyword" for specifically >> setting the 'iskeyword' setting to sane values. So in a syntax file, one >> could set: > >> :syn option iskeyword @,48-57,_,192-255 >> < >> and have syntax highlighting make work as expected independent on the >> users choice of setting the 'isk' setting. If this is not done, syntax >> highlighting will depend on the users 'isk' setting as before. >> >> The current syntax iskeyword setting can be seen by using: > >> :syn option iskeyword >> < >> >> And it can be reset to the old behaviour using: > >> :syn option iskeyword clear >> < >> >> I did add the syn-option command, so that later on, it can be extended >> to other options as well, if this should be necessary. >> >> Attached is a proof of concept patch, that does this. >> >> Any comments? >> >> Best, >> Christian >> -- >> Letzte Worte eines Fahrlehrers: >> "Nun versuchen Sie's alleine." >> >> -- >> -- >> You received this message from the "vim_dev" 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_dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to vim_dev+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. > > -- > -- > You received this message from the "vim_dev" 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_dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to vim_dev+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- -- You received this message from the "vim_dev" 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_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: proposed patch: Make syntax highlighting independent of 'iskeyword' setting
2015-10-27 18:04 GMT+03:00 Christian Brabandt : > Hi Nikolay! > > On Di, 27 Okt 2015, Nikolay Pavlov wrote: >> Somewhere in the Neovim bug tracker I suggested that it would be >> better to do another thing: > > Is there anything you haven't thought about it yet? > >> When syntax file is being loaded >> save user &iskeyword setting then >> at the each :syn statement save :syn-statement-specific &iskeyword >> setting, attached to :syn statement. >> After syntax file was loaded restore user &iskeyword setting. >> >> From your description this is going to work like if all syntax authors >> replaced :setl isk with :syn option iskeyword. But note the >> differences: >> >> 1. No need to change existing syntax files. >> 2. &iskeyword setting is attached to *:syn statement*, not buffer or >> window structure. Note that user &iskeyword setting is not the only >> cause for highlighting breakage: there is also :syn include and files >> included this way may have different &iskeyword setting (:syn include >> should also save/restore &iskeyword thus). > > Yes this is true. But I believe that the 'isk' setting should be > specific to a single language and not to each statement. And I think, > this would really bloat Vims memory footprint and possibly slow down > syntax highlighting. OTOH I don't know, how well my proposal would work > with syn include. Not much if implemented properly. This is 1. One pointer per synpat_T item. On my system sizeof(synpat_T) == 160, sizeof(void*) == 8: +5%. 2. One additional chartab per one &iskeyword setting switch: 32 bytes. 3. One integer (refcount) per one chartab: 4 bytes. 4. Increase of the binary due to added code: unknown number of bytes. Though nobody counts this. It is not going to bloat much. Also &iskeyword setting in my variant will be specific to the *language* because nobody changes &iskeyword in the middle of the syntax file. In your variant it is *not* specific to the language, it is specific to the *buffer*. And with :syn include buffer may contain more then one language. Also I do not see why my variant should slow down the highlighting more then your variant. (BTW, I expected you to modify `vim_iswordc_*` and places where it is called to accept a pointer to custom chartab and not mess with `memcpy`.) > >> Note that my approach is not fixing syntax highlighting affected by >> user &iskeyword setting. My approach is fixing syntax files, messing >> with my &iskeyword setting. :syn option iskeyword is not going to >> solve this because it is not currently used. And with policies >> “runtime file updates can only be sent by file maintainers” (like if >> they can’t pull in the changes) and “other people commits are too ? to >> merge them into the master” with “squash the world before updating >> runtime files” (so that it is harder to maintain a parrallel branch, >> and there are no explanations “why was this change made” in commit >> messages and “who made this change” in other metadata) this is not >> going to happen ever. > > That is true with many patches however. It works only well, if > contributors do use it. And a lot of syntax files need to be maintained, > if only because the language evolves within times. Problem is not that they need to be maintained. Problem is that your change generates to much hassle and thus is going to be used by almost nobody a long time. > > Best, > Christian > -- > > -- > -- > You received this message from the "vim_dev" 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_dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to vim_dev+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- -- You received this message from the "vim_dev" 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_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: proposed patch: Make syntax highlighting independent of 'iskeyword' setting
What about using the already existing commands below (assuming Vim version 6.2 or later)? let s:save_isk = &l:isk try setl isk&vim" or to whatever value is desired … … … finally let &l:isk = s:save_isk endtry IMHO authors who won't bother saving and restoring the option won't use your new command either, especially since it will have to be bracketed by if exists() in all third-party syntax scripts, to guard against the possibility of running on a Vim compiled without the patch. Best regards, Tony. On Tue, Oct 27, 2015 at 12:44 PM, Christian Brabandt wrote: > Hi, > currently setting 'isk' option has - among others - an unwanted side > effect on the syntax highlighting. > > For example by removing the '_' from the 'iskeyword' setting, defined > syntax keywords start matching where they didn't match before. > > E.g. in a SQL buffer, > > CREATE TABLE FOOBAR( > CRTD_BY VARCHAR2(100)); > > Setting :setlocal isk-=_ will make the 'BY' highlighted as syntax > keyword. I believe this is unwanted and therefore I propose the > following enhancement: > > Add a new syntax command ":syn option iskeyword" for specifically > setting the 'iskeyword' setting to sane values. So in a syntax file, one > could set: > > :syn option iskeyword @,48-57,_,192-255 > < > and have syntax highlighting make work as expected independent on the > users choice of setting the 'isk' setting. If this is not done, syntax > highlighting will depend on the users 'isk' setting as before. > > The current syntax iskeyword setting can be seen by using: > > :syn option iskeyword > < > > And it can be reset to the old behaviour using: > > :syn option iskeyword clear > < > > I did add the syn-option command, so that later on, it can be extended > to other options as well, if this should be necessary. > > Attached is a proof of concept patch, that does this. > > Any comments? > > Best, > Christian > -- > Letzte Worte eines Fahrlehrers: > "Nun versuchen Sie's alleine." > > -- > -- > You received this message from the "vim_dev" 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_dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to vim_dev+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- -- You received this message from the "vim_dev" 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_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: proposed patch: Make syntax highlighting independent of 'iskeyword' setting
2015-10-27 20:00 GMT+03:00 Charles Campbell : > Christian Brabandt wrote: >> That is true with many patches however. It works only well, if >> contributors do use it. And a lot of syntax files need to be >> maintained, if only because the language evolves within times. Best, >> Christian > Also because suggested syntax changes are occasionally ill-advised. I > just got a suggestion, for example, that would have obliterated Bourne > shell syntax handling by conflating it with posix shell syntax. And > there've been innumerable attempts to get a LaTeX package supported by > syntax/tex.vim (my position on that: its impractical to maintain > syntax/latex.vim with it supporting tens, hundreds, or thousands of > LaTex packages; instead, the best way is to set up small > after/syntax/tex/pkgname.tex files and publish them). This problem is orthogonal to the problem of throwing away history when squashing. And it is enough to require *review* (not “making and sending a patch/PR” which is more actions to do) from the reviewers attached to a syntax file (which will replace maintainers; also there should be more then one reviewer). Also I once made a patch that removed backslash from a number of collections (I mean `[chars]` in regexp) where it did not mean backslash (e.g. `[\[]` is “backslash or opening bracket”, while intention is just “opening bracket”). Such changes, as well as &iskeyword -> syn option iskeyword do not need reviewers familiar with the language. (Obviously it was not merged. You can find the patch somewhere in this mailing list.) It is as well easier to switch the reviewer then the maintainer in case maintainer opinion contradicts with the official position: maintainer role creates more obligations then reviewer. === With reviewers replacing the maintainers I can open a PR which changes `setlocal iskeyword` to `syntax option iskeyword` and it will be accepted once all reviewers accept, without much problems, even if policy “changes that do not alter the highlighting produced by syntax files may be accepted without reviewing by syntax file reviewer” will not be present. *One* PR. With maintainers it would be needed to 1. bother me with creating 100500 messages to maintainers and tracking all the replies 2. bother maintainers with creating 10500 pull requests or patches 3. bother Bram with merging all of them *one by one*. === In any case what you said does not justify “squash the world” policy. > > Regards, > Chip Campbell > > -- > -- > You received this message from the "vim_dev" 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_dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to vim_dev+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- -- You received this message from the "vim_dev" 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_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: proposed patch: Make syntax highlighting independent of 'iskeyword' setting
Christian Brabandt wrote: > That is true with many patches however. It works only well, if > contributors do use it. And a lot of syntax files need to be > maintained, if only because the language evolves within times. Best, > Christian Also because suggested syntax changes are occasionally ill-advised. I just got a suggestion, for example, that would have obliterated Bourne shell syntax handling by conflating it with posix shell syntax. And there've been innumerable attempts to get a LaTeX package supported by syntax/tex.vim (my position on that: its impractical to maintain syntax/latex.vim with it supporting tens, hundreds, or thousands of LaTex packages; instead, the best way is to set up small after/syntax/tex/pkgname.tex files and publish them). Regards, Chip Campbell -- -- You received this message from the "vim_dev" 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_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: proposed patch: Make syntax highlighting independent of 'iskeyword' setting
Hi Nikolay! On Di, 27 Okt 2015, Nikolay Pavlov wrote: > Somewhere in the Neovim bug tracker I suggested that it would be > better to do another thing: Is there anything you haven't thought about it yet? > When syntax file is being loaded > save user &iskeyword setting then > at the each :syn statement save :syn-statement-specific &iskeyword > setting, attached to :syn statement. > After syntax file was loaded restore user &iskeyword setting. > > From your description this is going to work like if all syntax authors > replaced :setl isk with :syn option iskeyword. But note the > differences: > > 1. No need to change existing syntax files. > 2. &iskeyword setting is attached to *:syn statement*, not buffer or > window structure. Note that user &iskeyword setting is not the only > cause for highlighting breakage: there is also :syn include and files > included this way may have different &iskeyword setting (:syn include > should also save/restore &iskeyword thus). Yes this is true. But I believe that the 'isk' setting should be specific to a single language and not to each statement. And I think, this would really bloat Vims memory footprint and possibly slow down syntax highlighting. OTOH I don't know, how well my proposal would work with syn include. > Note that my approach is not fixing syntax highlighting affected by > user &iskeyword setting. My approach is fixing syntax files, messing > with my &iskeyword setting. :syn option iskeyword is not going to > solve this because it is not currently used. And with policies > “runtime file updates can only be sent by file maintainers” (like if > they can’t pull in the changes) and “other people commits are too ? to > merge them into the master” with “squash the world before updating > runtime files” (so that it is harder to maintain a parrallel branch, > and there are no explanations “why was this change made” in commit > messages and “who made this change” in other metadata) this is not > going to happen ever. That is true with many patches however. It works only well, if contributors do use it. And a lot of syntax files need to be maintained, if only because the language evolves within times. Best, Christian -- -- -- You received this message from the "vim_dev" 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_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: proposed patch: Make syntax highlighting independent of 'iskeyword' setting
2015-10-27 14:44 GMT+03:00 Christian Brabandt : > Hi, > currently setting 'isk' option has - among others - an unwanted side > effect on the syntax highlighting. > > For example by removing the '_' from the 'iskeyword' setting, defined > syntax keywords start matching where they didn't match before. > > E.g. in a SQL buffer, > > CREATE TABLE FOOBAR( > CRTD_BY VARCHAR2(100)); > > Setting :setlocal isk-=_ will make the 'BY' highlighted as syntax > keyword. I believe this is unwanted and therefore I propose the > following enhancement: > > Add a new syntax command ":syn option iskeyword" for specifically > setting the 'iskeyword' setting to sane values. So in a syntax file, one > could set: > > :syn option iskeyword @,48-57,_,192-255 > < > and have syntax highlighting make work as expected independent on the > users choice of setting the 'isk' setting. If this is not done, syntax > highlighting will depend on the users 'isk' setting as before. > > The current syntax iskeyword setting can be seen by using: > > :syn option iskeyword > < > > And it can be reset to the old behaviour using: > > :syn option iskeyword clear > < > > I did add the syn-option command, so that later on, it can be extended > to other options as well, if this should be necessary. > > Attached is a proof of concept patch, that does this. > > Any comments? Somewhere in the Neovim bug tracker I suggested that it would be better to do another thing: When syntax file is being loaded save user &iskeyword setting then at the each :syn statement save :syn-statement-specific &iskeyword setting, attached to :syn statement. After syntax file was loaded restore user &iskeyword setting. >From your description this is going to work like if all syntax authors replaced :setl isk with :syn option iskeyword. But note the differences: 1. No need to change existing syntax files. 2. &iskeyword setting is attached to *:syn statement*, not buffer or window structure. Note that user &iskeyword setting is not the only cause for highlighting breakage: there is also :syn include and files included this way may have different &iskeyword setting (:syn include should also save/restore &iskeyword thus). This will, of course, either raise memory footprint very much or require managing &iskeyword tables separately of syntax definitions. Note that my approach is not fixing syntax highlighting affected by user &iskeyword setting. My approach is fixing syntax files, messing with my &iskeyword setting. :syn option iskeyword is not going to solve this because it is not currently used. And with policies “runtime file updates can only be sent by file maintainers” (like if they can’t pull in the changes) and “other people commits are too ? to merge them into the master” with “squash the world before updating runtime files” (so that it is harder to maintain a parrallel branch, and there are no explanations “why was this change made” in commit messages and “who made this change” in other metadata) this is not going to happen ever. > > Best, > Christian > -- > Letzte Worte eines Fahrlehrers: > "Nun versuchen Sie's alleine." > > -- > -- > You received this message from the "vim_dev" 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_dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to vim_dev+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- -- You received this message from the "vim_dev" 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_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
