When I am using gvim to write systemverilog program, it goes very well....until I am using define syntax to define my macro. The macro contains several lines of code like this:
define my_macro(addr)\
assign a[addr] = b[addr];\
assign c[addr] = d[addr];\
....;\
assign name[addr] = your_name[addr];
And when the line number of the macro increases, gvim becomes extremely slow.
Why? May be syntax highlighting isn't efficient to handle this construct, but which kind of code in the syntax will cost this problem? I am using a verilog_systemverilog.vim syntax.
Related
I would like to highlight certain function-like macros for C in Vim, and I'm having trouble with what type of highlighting category I should give it. The goal of this is to add highlighting support for some C libraries.
At a first glance, looking at c.vim the most suitable keyword groups seems to be cConstant, cPreProc, cDefine and cOperator. Here cPreProc and cDefine are made to go along with #, which leaves me to cOperator and cConstant. I'm not very proficient in computer science, but macros does not seem to (in general) fit very well into operators, and so this leaves me to cConstant. I could interpret this as a constant expression modulo inputs, which then makes sense.
Is cConstant the best fit for this, should I define a new highlighting group, or should I not highlight them at all?
Typing :help group says that the group Macro is the same as Define, which is what cDefine is linked as. Thus, one should use cDefine or perhaps define a new group called cMacro which is linked to Macro. Don't really know why Bram made it like this.
dd = (re.findall(r'">County<(.*?)</td>', lmth2))
if not dd:
dd = (re.findall(r'<small>Location in <a(.*?)</td>',lmth2)
if not dd:
county.append("")
fin.append(name[o]+';'+address[o]+';'+city[o]+';'+stateorg[o]+';'+county[o]+';'+phone[o]+';'+website[o])
continue
else:
ee = (re.findall(r'title="(.*?) County', dd[0]))
county.append(ee[0])
fin.append(name[o]+';'+address[o]+';'+city[o]+';'+stateorg[o]+';'+county[o]+';'+phone[o]+';'+website[o])
I'm trying to stack IF NOTs together to find the find result. If
If dd does not come up as a match then I want to try the second scenario. If that doesn't come up with a match then I want, for right now, for it to show it as nothing comes up and to set up the line to be saved to the file. If it does come up with a match than I need it continue on find the second level of the search with ee = (re.findall...)
Until I found the second possible scenario to search for everything had been working find but then I found another possible thing I need to look for so I'm trying to add it into the program and I keep getting an Invalid Syntax coming back on the : on the second
if not dd:
This is one that is WAY beyond me. I'm not use to having this trouble with stacked if's when I use to use VB6. Python seems to be handling things a bit differently.
Indentation is syntactically significant in Python. Unlike languages where blocks are determined by tokens like begin and end or { and }, in Python blocks are determined by indents and dedents.
As such, you cannot arbitrarily indent Python code. Whenever Python encounters a line that is indented further than the line above it, it expects that to be the first line of a new block. The issue you have is that inside the first if statement you have already established the indentation level of that block with the line dd = ..., and then you've indented the next if statement even further, while it should be at the same indentation level.
If you remove the extra indent on the second if not dd: line, it should no longer have a syntax error.
How can I can specific word wrapping for specific tags. For example, in LaTex I want word wrapping for my paragraphs but not for my figure commands (they are always very long and run off the screen).
Or with Javascript, I want the right margin for code to be at, for example 50 columns, but for the comments to be at only 40 columns
This is not builtin
You could probably script something yourself using a devious combination of `formatexpr` and synID(). I suggest you look at the help of the latter first, because it contains inspirational samples:
for id in synstack(line("."), col("."))
echo synIDattr(id, "name")
endfor
taken from :he synstack
The formatexpr is usually set to something like
:set formatexpr=mylang#Format()
thus delegating to a filetype plugin. You could implement the function to use different margins for different syntax contexts.
Bear in mind
the default formatexpr (if absent, formatprg) are probably no good for a source file (in my experience it has the tendency to string together lines as if they were text paragraphs). But then again, you can implement it any which way you want
that syntax highlighting may become out of sync. I'm not sure what happens when the cursor is at, say, 70% of a large document and you issue ggVGgq. It might not update the syntax highlighting all the way (meaning that your formatexpr function would get the 'wrong' synID() values. You get around this by saying something like
:syntax sync fromstart
this again might impact the highlighting performance depending on the size/complexity of the source and highlighting scripts
I have blocks of code that look like:
ICar car = new Car<int>(10);
var result = car.Start(100);
Assert.IsTrue(result.IsValid);
That I want to convert to this:
Assert.IsTrue((new Car<int>(10).Start(100)).IsValid);
I have about 20 of these types of snippets with the exact same format, could this be automated in vim?
Crash course in macros:
Go to ICar in normal mode.
Press qq to start the macro.
Modify the code. Try using word-based movements instead of left/right arrows.
Go to the next snippet, like with /ICar.
Press q again in normal mode to stop recording.
You can then type #q to execute the q macro and reformat one snippet. If it works as expected then type 20#q to execute 20 times.
:%s:^.* = \([^;]\+\);\_.[^.]\+\([^;]\+\);\n\n\+\([^(]\+\)(.*\.\(.*$\):\3((\1\2).\4
Will do it with the exact same format (placement of .s and =, etc are important in the original pattern.
HTH
Macros are the easiest, but another way to do it is with global commands - :g/regular expression/Ex command. For example(not your example - we will get to it later), you can use :g/^\s*ICar/delete will delete all lines starting with ICar(^ is for start of line, \s* is for skipping the tabs and spaces used for indention).
The advantage of this method over macros is that you can use it on a range: go into visual mode, mark the part you want to refactor, and use the global command. Only matches in the marked block will be affected. If you use macros, you need to either press ## over and over again until you clear the block, count the exact number of times you want the macro to run, or set a high number and make the no-match error stop the macro. While the third option is quite easy to execute, it's also quite dangerous - you need to make sure the pattern appears only in the parts you want to refactor - so it won't affects unrelated parts of the code - and that the refactoring removes it - otherwise the macro will run on the same lines over and over again.
The advantage of macros is that they are easier to record. In complex refactoring like yours, the global command you need to run can be very long and complex. A macro to do the same thing is just as long and complex as a global command - but you can see how it works while you record it - much easier than calculating the result in your head while designing the global command.
Luckily, you can enjoy both world!
First you record your macro like cdleonard explained in his answer, with two main differences.
The first one is that the first keystroke in the macro should be ^ or _ - to go to the first non-white-space character in the line(that means you start with qq_ and then record as usual). This will guarantee the macro starts from the right place in the line every time.
The second difference is that you don't need to go to the next snippet in the end of the macro. The global command will take care of that for you.
After you've recorded the macro(I'll assume you recorded it to q) mark all the snippets using visual mode, and type :g/^\s*ICar/norm #q - this will search the marked range for all lines that begin with ICar(possibly with indentation before them) and performs the macro on them. This is assuming everything in the range that begins with ICar - and only those places - are snippets you want to refactor. If you have lines that begin with ICar and you don't want to refactor, or if you have lines that you do want to apply the macro to, but they don't begin with ICar - you will have to modify the regex.
I'd like to highlight variables in my (Maple-code, but doesn't matter much) code which are global for routines.
e.g. I have
global_var1:=1;
global_var2:=2;
...
some_proc:=proc()
local local_var1, global_var2;
local_var1:=1;
local_var2:=local_var1*global_var1+global_var2;
end proc;
I want to highlight global_var1 inside of some_proc() in this example. Obviously the naming is not so trivial in general as in the example.
Can I use ctags to do this?
It depends on ctags. With some languages it is unable to extract local variables (viml), with other languages, it doesn't detect all local variables (C++). Hence, the first thing you'll have to do is to see what ctags can do for your language (Maple).
The other difficulty is to restrict the highlighting to one specific function, and to stay synchronized every time newlines are inserted to the edited file. I know no easy way to do this -- may be with a vim syntax region that starts at local.*{global-name} and ends at end proc to neutralize the highlighting of all global variables?
One task that'll be much more easier would be to highlight variable masking, i.e. highlight global_var2 at the point in the function where it is declared local. Alas, it's not what you're looking for.