On 24/12/13 22:28, Ben Fritz wrote:
On Tuesday, December 24, 2013 1:31:30 PM UTC-6, riemann wrote:
I would like to have automatic user defined types syntax highlighting in Vim.
So that if I have for example a syntax match group for classes
and have this in the buffer
1 class mytype {
2 //...
3 };
4
5 mytype a;
6 mytype b;
"mytype" is automatically highlighted on lines 5 and 6 besides 1.
I would like to modify the source code rather than use scripts, for
responsiveness of highlight and efficiency reason.
I am reading src/syntax.c and I'm trying to answer these questions:
1) Which data structure holds the syntax information of a certain group?
2) Which function triggers on a match event to update this structure?
2) Can I extract from the structure the strings to be highlighted?
Any help appreciated,
Thanks
Vim doesn't even defined syntax highlighting in source code! You're going at
this all wrong. Vim always does syntax highlighting via script. There are
exactly zero languages Vim highlights without a script.
And in addition, I think you (riemann) are going against history. Let's
recapitulate:
- Once upon a time, programmers (were they called prograamers then?)
worked on the bare metal, writing programs in machine code (either in
binary, or, for machines like the IBM 1401 which had not only
decimal-only arithmetic but decimal-only addressing, in decimal).
- Then came assembly language which afforded them symbolic labels,
symbolic opcodes, and macro instructions. Each processor had a different
assembly language though, sometimes several. Even now, there are two
different assembly languages (ATT syntax and Intel syntax) for Intel x86
processors.
- The next step was compiled languages like FORTRAN, COBOL, ALGOL, C etc.
- Interpreted languages and script languages, such as Perl, Python,
shell script, Vimscript, Javascript, etc., came even later. I'm counting
Javascript, though you may need something in another language (such as
XULrunner) to make it run, but that is also true of other interpreted
languages (the shell is not written in shell script, or, AFAIK, the
Python interpreter in Python).
Does that mean that program efficiency went to the dumps? Not
necessarily, and the fact that today's processors are unbelievably
faster and memory stores biggers than those of a few decades ago is not
the only reason. (The computer on which I first worked had 131072
six-bit characters and ran at 667 kHz, and that was a really big one —
for its time.)
To make a program run faster, one should identify where the bottlenecks
are, and work on that. Bad code will run slowly, and often be hard to
understand (and debug), no matter if written in Python (or Vimscript),
in C (or COBOL), in assembly language or even (blerh) in pure binary
without symbols or macros. OTOH, code that is used only once a day, or
even once a minute, may run at less than ideal speed, the difference
will usually not be noticeable.
For a program like Vim, if "the kind of Vimcode" (the set of builtin
ex-commands etc.) that makes programs go slowly can be identified, the
backend for that kind of code may (and, if possible, should) be
optimized, which ideally would work across the board, making even
already written Vim scripts run faster. That would provide a much
greater advantage than just adding one ad-hoc plugin in C, that no one
else would use. This kind of "backend optimization" is what is being
done now for searching, and I'd say it is almost finished but maybe not
completely (bugs are still found now and then in the new search engine).
Time will tell if I was being too pessimistic in the preceding sentence.
Best regards,
Tony.
--
San Francisco is my kind of city,
Where the women are strong and the men are pretty.
--
--
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.
