I have a plugin configuration parameter named suffix. I would like the user to be able to specify a newline (a literal character produced by pressing the Return key, not some escaped variant, although I'll get to that) as the value for that parameter.
At the same time, the parameter has a default-value setting. I would like to continue to use that.
How do I specify, in my plugin's configuration stanza, that the suffix parameter should take a newline?
I've tried this:
<suffix><![CDATA[
]]></suffix>
...and this:
<suffix>${line.separator}</suffix>
...(that one actually substitutes the right character in but XML parsing stomps on it) and this:
<suffix><[!CDATA[${line.separator}]]></suffix>
...and this:
<suffix>&x0d;</suffix>
...and this:
<suffix xml:space="preserve">
</suffix>
...all to no avail. Specifically, I see the default value of the parameter instead.
Edit: Interestingly, the whitespace is eaten long before Maven's internals ever get a chance to work on the value. mvn help:effective-pom will show that the whitespace has been removed. Leading, trailing and "only" whitespace content is removed early on in the parsing stage.
This seems to me most likely to be a bug, so I've filed http://jira.codehaus.org/browse/PLX-461 to track it.
The codehaus links don't work anymore, but I found in the maven documentation that since version 3.0.something you can add an attribute xml:space="preserve" to any element you don't want trimmed.
Per instructions, I am answering this question by referring people to the following JIRA: https://issues.apache.org/jira/browse/MNG-5380 (originally at http://jira.codehaus.org/browse/PLX-461 ).
Use $${line.separator}. The double $$ escape it. A chap on the Codehaus IRC channel shared his finding recently, so the credit should actually go to him.
Related
I've recently encountered these two variables in some Velocity code:
$!variable1
!$variable2
I was surprised by the similarity of these so I became suspicious about the correctness of the code and become interested in finding the difference between two.
Is it possible that velocity allows any order of these two symbols or do they have different purpose? Do you know the answer?
#Jr. Here is the guide I followed when doing VM R&D: http://velocity.apache.org/engine/1.7/user-guide.html
Velocity uses the !$ and $! annotations for different things. If you use !$ it will basically be the same as a normal "!" operator, but the $! is used as a basic check to see if the variable is blank and if so it prints it out as an empty string. If your variable is empty or null and you don't use the $! annotation it will print the actual variable name as a string.
I googled and stackoverflowed a lot before I finally found the answer at people.apache.org.
According to that:
It is very easy to confuse the quiet reference notation with the
boolean not-Operator. Using the not-Operator, you use !${foo}, while
the quiet reference notation is $!{foo}. And yes, you will end up
sometimes with !$!{foo}...
Easy after all, shame it didn't struck me immediately. Hope this helps someone.
I wish to use a string handed to me as a parameter as an element of a pathname. I do not wish to be troubled with 'Little Bobby Tables'. That is, I don't want '..' to be acceptable. I want this to work with an arbitrary NIO2 FileSystem, so just looking for the string .. isn't good enough. I can make some checks, such as !path.isAbsolute(), and path.getNameCount() == 1 to filter out other problem cases, but can I do anything other than pass it to resolve and look for the wrong name count to tell if it has the semantics of ..?
toRealPath()
Is mostly the answer. The method on a path after resolved gives you
the real path after resolving parent (e.g. "..") and links.
You can then use root.startsWith( path ) to quickly check that it is in your subtree.
But: Works only for existing files.
I've implemented auto completion to a combobox like this article shows. Is it possible to make it search for substrings instead of just the beginning of the words?
http://www.codeproject.com/Articles/2371/IAutoComplete-and-custom-IEnumString-implementatio
I haven't found any way to customize how IEnumString/IAutoComplete compares the strings. Is it possible?
The built in search options help a bit but it is complete chaos. To find instring matches you need to set flag AcoWordFilter. But this will prevent from numbers being matched!! However, there is a trick to get the numbers to match: preced with a double-quote as in "3 to find a string containing or starting with "3". Some more chaos? In the AcoWordFilter you also need to prefix other characters not considered part of a "word", eg. you need to prefix parentheses with a " but then you will not find parentheses at the first position!
So the solution is either to create your own implementation of IAutoComplete or offer the user to switch between the modes (a bit awkward).
I dont think that the MS engineers are especially proud of such chaos. How about one more option: AcoSearchAnwhere?
After retrieving the Edit control's IAutoComplete interface, query it for an IAutoComplete2 interface. Calling its SetOptions member you can disable prefix filtering by specifying the ACO_NOPREFIXFILTERING AUTOCOMPLETEOPTIONS.
This is available on Windows Vista and later. If you need a solution that works with pre-Vista versions, you'll have to write your own.
I use \newtheorem and the numbering is done automatically. Sometimes in the text I'll refer to a theorem by this number. I'd like to have a variable equal to this number, so if the theorem number changes, the references will change also.
Yes, it works through the usual \label/\ref-mechanism:
\begin{theorem}\label{thm:foo} ...
That was Theorem~\ref{thm:foo}
(You'll need two runs of LaTeX for the number to settle, you'll get a message about changed references.) Label commands "tack onto" certain things like section headers, captions, items of enumerations and, indeed, theorems and friends.
There are also extensions that can automatically distinguish sections from subsections or figures, for that, see hyperref's \autoref or the cleveref package, but don't worry about it at this point.
You need to put a \label between the \begin{yourtheorem} \end{yourtheorem} and use \ref to refer to it as usual.
You can check this link for explanations with some broader context about theorems
I set the culture to Hungarian language, and Chr() seems to be broken.
System.Threading.Thread.CurrentThread.CurrentCulture = "hu-US"
System.Threading.Thread.CurrentThread.CurrentUICulture = "hu-US"
Chr(254)
This returns "ţ" when it should be "þ"
However, Asc("ţ") returns 116.
This: Asc(Chr(254)) returns 116.
Why would Asc() and Chr() be different?
I checked and the 'wide' functions do work correctly: ascw(chrw(254)) = 254
Chr(254) interprets the argument in a system dependent way, by looking at the System.Globalization.CultureInfo.CurrentCulture.TextInfo.ANSICodePage property. See the MSDN article about Chr. You can check whether that value is what you expect. "hu-US" (the hungarian locale as used in the US) might do something strange there.
As a side-note, Asc() has no promise about the used codepage in its current documentation (it was there until 3.0).
Generally I would stick to the unicode variants (ending on -W) if at all possible or use the Encoding class to explicitly specify the conversions.
My best guess is that your Windows tries to represent Chr(254)="ţ" as a combined letter, where the first letter is Chr(116)="t" and the second ("¸" or something like that) cannot be returned because Chr() only returns one letter.
Unicode text should not be handled character-by-character.
It sounds like you need to set the code page for the current thread -- the current culture shouldn't have any effect on Asc and Chr.
Both the Chr docs and the Asc docs have this line:
The returned character depends on the code page for the current thread, which is contained in the ANSICodePage property of the TextInfo class. TextInfo.ANSICodePage can be obtained by specifying System.Globalization.CultureInfo.CurrentCulture.TextInfo.ANSICodePage.
I have seen several problems in VBA on the Mac where characters over 127 and some control characters are not treated properly.
This includes paragraph marks (especially in text copied from the internet or scanned), "¥", and "Ω".
They cannot always be searched for, cannot be used in file names - though they could in the past, and when tested, come up as another ascii number. I have had to write algorithms to change these when files open, as they often look like they are the right character, but then crash some of my macros when they act strangely. The character will look and act right when I save the file, but may be changed when it is reopened.
I will eventually try to switch to unicode, but I am not sure if that will help this issue.
This may not be the issue that you are observing, but I would not rule out isolated problems with certain characters like this. I have sent notes to MS about this in the past but have received no joy.
If you cannot find another solution and the character looks correct when you type it in, then I recommend using a macro snippet like the one below, which I run when updating tables. You of course have to setup theRange as the area you are looking at. A whole file can take a while.
For aChar = 1 To theRange.Characters.count
theRange.Characters(aChar).Select
If Asc(Selection.Text) = 95 And Selection.Text <> "_" Then Selection.TypeText "Ω"
Next aChar