2013/12/27 Ben Fritz <[email protected]> Here I disagree. The language.vim file you speak of defines regular > expressions. The syntax.c file highlights those regular expressions, > nothing more. Vim doesn't keep a semantic understanding of code structure > anywhere. Everything Vim knows about the highlighted code is defined in the > language.vim file, and everything matched by that file is accessible in > vimscript using synstack() and other functions. > > The information you seek to highlight isn't made available to vimscript, > because vim itself doesn't know that information. Vim doesn't actually > understand the code. It just highlights regular expressions. >
> Sure, it would be neat if there was some way for Vim to actually do this > for arbitrary languages. I'm interested in seeing what you've accomplished. > But what you're looking for in the code just isn't there. > Thank you all for your insightful comments. To take stock of the situation I think there are two main questions: 1) ------------------------------------------------------------------------ Is the information needed to solve the problem already disposable, perhaps concealed, in Vim or do we have to add an ad-hoc parser to get it? I'm always convinced of the first and that there is no real need of duplicate the efforts. I'll try to explain myself. Even without knowning all the intricacies of syntax.c, I think that there has to be a point when Vim knows that from character M to character N of line I it has to render to the screen following the rules associated with group XYZ. But wait a moment... Here it is the information! It's the string from character M to character N. In syntax.c we have the function add_keyword () that adds a given string to a specified group ID. Use it with the string from character M to character N and the group ID of XYZ and the job is done. Generally user defined types can be catched with a match: syntax match group regular_expression So I think it is possible to implement a new argument for match (as it is with contains, contained etc) called for example "add_as_keyword" syntax match group regular_expression add_as_keyword so that the user wants that the resulting string matched by the regular expression is also added as keyword to the group. Fot the implementation I can imagine that the code that searches for a regular expression match, if the user has specified the "add_as_keyword" argument, on a hit calls also add_keyword () with arguments it has easily disposable. Language agnostic, no need to parse the file, few lines of code to add. 2) ----------------------------------------------------------------------- Here is the excellent point exposed by James McCoy. And if the type is defined in another file? In trying to identify a language agnostic and efficient solution, an approach could be to add a "file_dependency" construct as possible argument to syntax syntax file_dependency regular_expression With this the user tells Vim how to recognize the names of files upon which a file could depend (for example it could be an #include <> pattern). This allows the creation of a list of files in which to perform the search. The scenario then could be: - On opening a file Vim first creates a list L of files containing the name of the current buffer and of those of all the files on which it depends, of course considering also the recursion of dependencies. - Vim performs the search on all the files in L and associates with each file a list of the strings found in it if any. Then adds all the keywords with add_keyword (). This is done only once at the opening of the file. - Then while we are editing the file, Vim monitors the files in L for modifications. If a modification in one of them occurs, vim first clear the set of keywords associated with that file with syn_clear_keyword (), research that file, add the new found keywords with add_keyword () and reassociates the file with the new set. It should also be considered the case when the modification in a file determines a modification of L (an #include <> directive could have been added or removed for example) but I think this can be managed also. Just speculative level here but I think this deserves interest. To be continued... Please criticize without mercy. -- -- 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
