I have a custom SPICE (electronics) syntax highlighting for gEdit, it's working, but I would like to modify the highlighting for variables (and I don't know how to). What I have now is this:
<context id="variables" style-ref="string">
<match extended="true">
(\s[^\s><&(){};,=/+\-*\^]+|
(?![({])\s*[^\s><&(){};,=/+\-*\^]+)
\s*(\=)(?!(\s*\=))
</match>
</context>
The parameters (variables) are defined like this:
.param Value=3.14
and, with the above code, "Value=" is highlighted, but I would like to omit the "=" from being coloured. I have tried (?!\=) on the last row, after 's*, plus a few combinations but... nothing.
In a more detailed way:
the parameters are defined by a mandatory first .param or .params (this is solved)
they cannot have spaces or any character like these -- [^\s><&(){};,=/+-*\^] -- inside their namings (solved)
they must have at least one space before to not "mingle" with the previous characters (solved)
the above condition has the "(" and "{" exceptions (solved)
they can have spaces between them and "=" (solved)
Please bear in mind that I have very little knowledge about PCRE, this is probably childish-looking but I don't mind as long as it's working. What I have now is done by too many trials-and-errors.
In the meantime I solved it with the help from jessevdk from #gedit on irc.gimp.org. The line
\s*(\=)(?!(\s*\=))
needs to be changed to
(?=(\s*\=(?!(\s*\=))))
Now I can update the file on https://bugzilla.gnome.org/show_bug.cgi?id=692822 and wait some more for acceptance...
Related
I've search both SO and Rstudio's community pages and failed to find aquestion, much less and answer to this annoyance I have experienced with Rstudio. (The Rstudio help pages won't let me post a second question within 12 hours of my first, which was explained as a bug.)
If I type:
(test)
... and then realize that test should be quoted, then putting the cursor at the end to test and entering a double-quote will give me two double-quotes "". It will not do this if I first enter a quote between ( and t and then it will also not give me doubling of the double-quote character at the end of `test. Why should it matter whether I first correct my error at the end of the symbol or at the beginning? Is there anything I can do to modify this quirk> It seems that a syntax aware console editor out to be able to tell when a doubling of quotes does not make sense. It's obviously making that "decision" when the quotes are entered between an open-paren and a character. Why not suppress the unhelpful behavior when it is between a character and a close-paren?
My target asciidoc text is this:
[red]#Some prompt[x]# Make sure the option is [checked]
But it won't display in asciidoc
On further investigation, I found that any line beginning with a [colour] in square brackets, and ending in a right-bracket is similarly not displayed.
Now, in this case, I've got around the problem by putting the whole prompt section in bold, like this:
*[red]#Some prompt[x]#* Make sure the option is [checked]
but this is not ideal. Adding a period after the final close bracket \] also AVOIDS the problem - but in my use case I didn't like it.
I'd like to know if there is a better way. So far I've tried:
Escaping the leading open bracket \[
Escaping the final close bracket \]
Removing the [x] in the middle, thinging the additional brackets in the middle may influence the outcome
but none of these has worked.
So my question is:
Is there a way to get around the problem of lines beginning with [colour] attributes ending with ] not displaying in asciidoc?
It seems to me that a line which begins with an opening bracket and ends with a closing bracket is being interpreted as a block attribute line.
There are a number of ways you can mitigate this.
Use a character replacement attribute. There are many built-in attributes, or you can easily define your own.
For example:
[.red]#Some prompt[x]# Make sure the option is [checked{endsb}
Use one of the inline pass-through syntaxes, for example ++:
[.red]#Some prompt[x]# Make sure the option is [checked++]++
Prevent the first opening bracket from being the first character of the line. Also, uses a built-in attribute, and the markup needs to be changed to unconstrained.
For example:
{empty}[.red]##Some prompt[x]## Make sure the option is [checked]
I seem to be having issues with leading/trailing spaces in textareas!
If the last user has typed values into a textarea with leading/trailing spaces across multiple lines, they all disappear with exception to one space in the beginning & end.
Example:
If the textbox had the following lines: (quotes present only to help illustrate spaces)
" 3.0"
" 2.2 "
"0.3 "
it would be saved in the backend as
"<textarea id=... > 3.0/n 2.2 /n0.3 </textarea>"
My template (for this part) is fairly straightforward (entire template, not as easy...): ${label} ${textField}
When I load up the values again, I notice getTextField() is properly getting the desired string, quoted earlier... But when I look at the html page it's showing
" 3.0"
"2.2"
"0.3 "
And of course when "View Sourcing" it doesn't have the string seen in getTextField()
What I've tried:
Ensure the backend has setWhitespaceStripping(false); set
Adding the <#ftl strip_whitespace=false>
Adding the <#nl> on the same line as ${textField}
No matter what I've tried, I'm not having luck keeping the spaces after the interpolation.
Any help would be very appreciated!
Maybe you are inside a <#compress>...</#compress> (or <#compress>...</#compress>) block. Those filter the whole output on runtime and reduce whitespace regardless where it comes from. I recommend not using this directive. It makes the output somewhat smaller, but it has runtime overhead, and can corrupt output in cases like this.
FreeMarker interpolations don't remove whitespace from the inserted value, or change the value in any way. Except, if you are lexically inside an <#escape ...>....</#escape>, block, that will be automatically applied. But it's unlikely that you have an escaping expression that corrupts whitespace. But to be sure., you can check if there's any <#escape ...> in the same template file (no need to check elsewhere, as it's not a runtime directive).
strip_whitespace and #nt are only removing white-space during parsing (that's before execution), so they are unrelated.
You can also check if the whitespace is still there in the inserted value before inserting like this:
${textField?replace(" ", "[S]")?replace("\n", "[N]")?replace("\t", "[T]")}
If you find that they were already removed that probably means that they were already removed before the value was put into the data-model. So then if wasn't FreeMarker.
I want my vim to highlight in red some keywords from the Pouet group like 'if(' in my .c files.
I figured out how to highlight if with:
syn keyword Pouet if
(This is my ~/.vim/syntax/c.vim)
and with
highlight Pouet term=NONE cterm=NONE Ctermfg=160 ctermbg=NONE gui=NONE
(And this is a part of my .vimrc)
The problem is,this code doesn't work with special characters like '(' or maybe a space or many spaces.
My question is: how do I make sentences like 'if(' highlight in red ?
Thanks
:syn keyword only works for keyword characters (as defined by the 'iskeyword' setting), and ( usually is not contained.
You have to use :syn match instead, e.g.:
:syn match Pouet "\<if("
This is fine if you define your syntax all on your own. If you want this in addition to the existing C syntax highlighting, you need to analyze the original syntax groups and add stuff like containedin=cConditional, maybe you even have to modify the original syntax definition.
An alternative is matchadd(), which goes on top of the syntax highlighting:
:call matchadd('Pouet', '\<if(')
The problem here is that these matches are window-local, not bound to the filetype like syntax highlighting, so when you split windows or edit another filetype in the current window, the highlighting will be gone / will persist. These problems can be worked around with autocmds, but now it's getting really complex.
I'm having problems about a regexp.
I'm trying to implement a regex to select just the tab indent blocks, but i cant find a way of make it work:
Example:
INDENT(1)
INDENT(2)
CONTENT(a)
CONTENT(b)
INDENT(3)
CONTENT(c)
So I need blocks like:
INDENT(2)
CONTENT(a)
CONTENT(b)
AND
INDENT(3)
CONTENT(c)
How I can do this?
really tks, its almost that, here is my original need:
table
tr
td
"joao"
"joao"
td
"marcos"
I need separated "td" blocks, could i adapt your example to that?
It depends on exactly what you are trying to do, but maybe something like this:
^(\t+)(\S.*)\n(?:\1\t.*\n)*
Working example: http://www.rubular.com/r/qj3WSWK9JR
The pattern searches for:
^(\t+)(\S.*)\n - a line that begins with a tab (I've also captured the first line in a group, just to see the effect), followed by
(?:\1\t.*\n)* - lines with more tabs.
Similarly, you can use ^( +)(\S.*)\n(?:\1 .*\n)* for spaces (example). Mixing spaces and tabs may be a little problematic though.
For the updated question, consider using ^(\t{2,})(\S.*)\n(?:\1\t.*\n)*, for at least 2 tabs at the beginning of the line.
You could use the following regex to get the groups...
[^\s]*.*\r\n(?:\s+.*\r*\n*)*
this requires that your lines not begin with white space for the beginning of the blocks.