On 27/12/13 10:24, Luca Rocca wrote:
2013/12/24 Tony Mechelynck <[email protected]
<mailto:[email protected]>>
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.
Well, this can also be regarded as a compliment eh eh...
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.
I think that the right abstraction level and distance from the machine
is dictated
by the particular problem faced. No particular level is ideal for
every situation.
Let's consider this case. Existing solutions proposed like easytags
http://www.vim.org/scripts/script.php?script_id=3114
show limitations as expressed by the same author that I quote as I've
already done
in vim_use group:
(quote from http://peterodding.com/code/vim/easytags/)
"... the plug-in automatically generates and highlights tags when you
stop typing
for a few seconds ... it tries hard to do the least amount of work
possible in this
break but it might still interrupt your workflow ... ". And if you
choose to enable
it always, "... Every time you edit a file in Vim, the plug-in will
first run
Exuberant Ctags and then highlight the tags, and this slows Vim down
quite a lot.
I have some ideas on how to improve this latency by running Exuberant
Ctags
in the background so stay tuned! ...".
Honestly I don't find this satisfactory.
In lack of the information subject of my post, for the moment I've solved
the problem the hard way editing syntax.c and writing the parser myself.
The responsiveness is the same of the normal syntax highlighting.
The cost of the elaboration is reasonable: benchmarking the specific
code with
clock_gettime() in a generous 24k lines of code file it is under 0.007
seconds.
For the curious I've attached a screencast of the highlighting in action.
In a terminal is shown in each run of the parser the time it takes in
nanoseconds.
That said, I still hope that my question could have an answer because
a more elegant
and minimal solution is possible given that the information needed is
certainly buried
in the data structures inside Vim.
This kind of highlighting is inherently language specific.
I haven't seen your patch, but are we going to be having to augment syntax.c
to support every language for which there is currently a ".vim" syntax file?
That's a huge amount of work and code bloat.
Doesn't seem like a very elegant solution at all, which is probably why
it hasn't
been attempted before now.
Cheers,
Thanks for your time,
Best regards
--
--
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.
--
--
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.
