There are various features fo the SQL filetype plugin mentioned in this helpfile that do not seem to work for me. I have installed the following files in to the correct places (all called sql.vim)
syntax - http://www.vim.org/scripts/script.php?script_id=498
ftplugin - http://www.vim.org/scripts/script.php?script_id=454
Was this even necessary? The syntax highlighting is now correct, but should something that is in the help files by default require downloading plugins?
Anyway, for example, the functions [[,]],[] and ][ do not work as described, and :SQLSetType is not a recognised command. Do I need to do more to enable these?
Thank you in advance for any help
The SQL syntax and filetype plugins by David Fishburn are indeed distributed with the Vim runtime; you only need to install them into your ~/.vim/ directory if you want a newer version than what is delivered by your current Vim version. (So usually, no.)
If the syntax is working but the filetype definitions aren't, you're likely missing
:filetype plugin indent on
in your ~/.vimrc. You can check the :scriptnames output and with :verbose nmap ]].
Related
I am automating a process and I use GPG2.exe for it.
Because I need to parse console output - potentially from different systems I need to set the languge to a controlled value.
I am following the Instructions from the manual which states that
LANGUAGE
Apart from its use by GNU, it is used in the W32 version to override the
language selection done through the Registry. If used and set to a valid and
available language name (langid), the file with the translation is loaded from
gpgdir/gnupg.nls/langid.mo. Here gpgdir is the directory out of which the
gpg binary has been loaded. If it can’t be loaded the Registry is tried and as
last resort the native Windows locale system is used.
I found a thread from 2011 that goes into a bit more detail regarding this problem, but this may actaully concern a different version.
I created a batch file for manual testing.
#echo off
REM C is meant to display untranslated messages according to one internet source
set LANGUAGE="C"
call "C:\Program Files (x86)\GNU\GnuPG\gpg2.exe" --version
pause
I ecpext the output to be english but it is still german.
The manual states something about there beegin a "gnupg.nls" folder somewhere.
I was not able to locate this folder, which makes me wonder where german is loaded from.
Is there an error in the man page?
The pdf Version of the man page shows the same content as the man page that came with the installation.
Can someone shed some light on this?
I had the same problem that the output was in Swedish though I wanted it in English. The Windows display language was set to English, and I also tried setting environment variables but what solved it for me was to remove the Swedish translation for gnupg file found here:
C:\Program Files (x86)\gnupg\share\locale
After having removed the "sv" directory all output was in English.
The language directory can be pulled from the registry or I suppose it can also have a fixed path since I can not find the information in my registry.
On my testsysten the path is 'C:\Program Files (x86)\GNU\GnuPG\share\locale'.
This path contains folders for each language - not all of them contain translation files for gpg2 as far as I can tell.
The environment variable for language is not LANGUAGE but LANG. Setting it to C causes gpg2 to default to english.
I successfully tested the following call.
#echo off
set LANG=C
call "C:\Program Files (x86)\GNU\GnuPG\gpg2.exe" --version
User bignose is still correct when he states that I should use the API instead but within my current restrictions I do not see a straight forward way to do so.
This isn't a programming question, as noted in the votes to close.
To answer a different question that could be asked from a programming perspective: Don't parse inherently-changeable console output, when there is a well-defined library API for the same functionality.
I've always wondered why vim lacks some indentation files that would be handy for everyday life. Example: I sometimes have to deal with really messed up apache config files (/etc/apache2/sites-available/*). It's impossible to have them indented correctly by vim. With apache config files I usually try to improve indentation by typing
:set ft=xml
gg=G
:set ft=apache
I know that apache configuration files are not XML and that XML indentation doesn't work remarkably good here, but at least it's better than having every config line in the first column. There's a vim script which seems to work correctly but I have to install it on all Linux systems. If we take this plugin as an example: It's from 2007 - why did it never make it into a vim release?
The maintainer of the [indent] script has to submit the file to Bram (Vim's BDFL) for inclusion (and commit to maintaining it); that's how the process works. So, if you want to have this in the runtime, please ask the maintainer, or, (as the last update of that script on vim.org is from 2007 and he may be gone), ask on the vim_dev mailing list for someone to volunteer as such.
But... you shouldn't have to rely on those files being in the official runtime. Unless you're an atypical user without any customization, you must already have a mechanism in place to distribute your personal ~/.vimrc and plugins; if you put the script into ~/.vim/indent/, you should be all set.
I'm working with gendarme for .net called by Sonar (launched by Jenkins).
I've a lot of AvoidVisibleFieldsRule violations. The main violations are found in the generated files. As I can't do anything on it, i would like to exclude *.designer.cs from the scan.
I can't find a way to do that. There is a properties in Sonar to exclude generated files but it doesn't seem to be applied for gendarme.
Is there a way to do such a thing ?
Thanks for all
Gendarme expects you provide an ignore list,
http://www.mono-project.com/Gendarme.FAQ
https://github.com/mono/mono-tools/blob/master/gendarme/self-test.ignore
The ignore file format is bit of weird, but you can learn it by experiments.
Indeed that is actually not normal at all. Generated code is excluded by the plugin with the standard configuration. What version of the C# plugins are you using ?
Anyway, the configuration property you can try is "sonar.exclusions" (see http://docs.codehaus.org/display/SONAR/Advanced+parameters).
If you do not solve your problem right away, the best thing would be to drop a mail to the user mailing list (see http://www.sonarsource.org/support/support/) and send the verbose output of your build. To get this output simply add "-X" to the command line.
Hope it helps
I use Zend Guard 5.0.1 and I've just noticed that it changes the capitalization of files that it is excluding (Copy as is). Since my filenames are case-sensitive this must have just changed as nothing works now, but I don't know how.
I use Obfuscation for Variables and Functions (not Classes).
I have tried to delete and create the project from scratch as there are other projects which don't just capitalization.
Does anyone have any clues?
Thanks
Adrian
Try to use command-line tools (zendenc52/zendenc53) from your Zend Guard. They do not mess filename capitalization.
I have created a WiX project that installs a bunch of different EXEs and DLLs. Unfortunately when I build the project I receive the following warning for each one of them:
ICE60: The file fileName is not a
Font, and its version is not a
companion file reference. It should
have a language specified in the
Language column.
I have found examples and possible solutions for this and each time it is suggested to set the DefaultLanguage tag to 0 in order to fix the warning. Once doing that I then get this warning:
The DefaultLanguage '0' was used for
file 'fileName' which has no language
or version. For unversioned files,
specifying a value for DefaultLanguage
is not neccessary and it will not be
used when determining file versions.
Remove the DefaultLanguage attribute
to eliminate this warning.
How can I handle this warning?
I beileve you are stuck with the warning until the executables are updated. Not helpful, I know, but I would focus on fixing the executables rather than trying to hack the Windows Installer.
The answer is to use something besides Wix. Having an test for a condition which the developer has no means to solve anyway, is a fruitless search for perfection that just results in wasting peoples time. In the end, your installer will work fine with this warning, and the warning being there will lead to you missing some other warning because you over looked it in the stream of useless output produced by this warning.
There is no value in demanding language when there is no net use of that language to fix the users life. The executable still run, they still produce the same results and they still have no support for language. So, why would this test, with an unquenchable warning, really add value to the developer or users life?