We are collaborating on a project with several team members who are using Mac, Windows and Unix based systems. I am curious if text can be configured to issue a \n instead of a \r\n at an end of line on a windows system to conform to unix standards? We are using UTF8
Yes, this is possible. Add the following to your preferences file, or to the shared .sublime-project file:
"default_line_ending": "unix"
This overrides the default value of "system". Note that this is only for new files. To change the line endings in an existing file, go to View -> Line Endings and select Unix.
Related
My local development environment based on Windows and my production environment based on Linux.
I have an issue about "line separators (CR, LF, CRLF)". Every time I got blank lines in my code.
Which line separator type to should I choose for prevent the blank lines?
I am working in this exact environment as well, except my development environment is also in Linux.
The aggravating problem I have run into is editing CRLF text files in the Linux environment, whether they were Apache files, or shell scripts. Mainly, I couldn't easily edit them in Linux through vi, which is unhappy with the CR. If you never do that, then it may not be a problem for you. But if you see blank lines in your code, it might be something similar.
For HTML and PHP, Apache running in the Linux environment has never complained when serving up files or reading configuration files in CRLF.
The other side of it, was that it was hard to wrangle PHPStorm. The related post #LazyOne provided works, but PHPStorm is stubborn if you have been using CRLF as I had when I switched this setting. I found I still needed to change files by hand at times, which you can do along the bottom right of the editor window. You will see CR, LF or CRLF and you can click and change the setting for the particular file loaded in the editor:
As a side note, if you use git, you can set up a .gitattributes file in the project directory with this:
# Set the default behavior to always be linefeed for linux
* text eol=lf
Which causes git to normalize to LF as it states in the git documentation:
Set to string value "lf"
This setting forces Git to normalize line endings to LF on checkin and
prevents conversion to CRLF when the file is checked out.
There is an excellent package to preview markdown written using sublime text. I wanted to know how I might modify it, or perhaps use it as the basis for writing one that could process multi-markdown.
I'm using Linux (Ubuntu) and I'm currently calling multimarkdown in the terminal on each file.
One of the issues I think I might face is that multimarkdown refuses to parse an open file for some reason.
Any thoughts on how I might begin this or if an alternative solution exists would be very gratefully received.
There is a MultiMarkdown option in the syntax list - View > Syntax > Markdown > MultiMarkdown. Isn't that working? By the way the syntax (and almost any other) files are in packages folder of Sublime Text 2. This is the syntax file:
/Users/[username]/Library/Application Support/Sublime Text 2/Packages/Markdown/Markdown.tmLanguage
And MultiMarkdown file is in the same directory.
I'm intrigued by your statement that "multimarkdown refuses to parse an open file". Can you provide more information, or email me, or open an issue on github? MultiMarkdown doesn't check to see whether a file is open or not --- it simply reads the file and processes it. So if there's a problem, then the OS is not allowing MMD to proceed for some reason...
I don't have Sublime Text installed on Ubuntu (I generally use a command line only version of Ubuntu for testing MMD), so I can't test this situation exactly. I haven't had any other reports of difficulties parsing files (open or not). I don't have any trouble with Sublime Text 2 on Mac OS X and MMD.
As an alternative, you could try using one of the support scripts (e.g. mmd if you want MMD->HTML) and see if that has the same problem with open files.
PS> Are you using the latest build of MultiMarkdown, e.g. 4.2+?? (Though it shouldn't change anything related to open files)
I have an option trim_trailing_white_space_on_save turned on. And for some files I should prevent removing trailing white spaces, because they are important.
How to remove this behaviour for some files, e.g. *.dat?
Have you already tried to create a configuration file for that specific extension and put trim_trailing_white_space_on_save = false ?
Settings Files
Settings files are consulted in this order:
Packages/Default/Preferences.sublime-settings
Packages/Default/Preferences (< platform >).sublime-settings
Packages/User/Preferences.sublime-settings
< Project Settings >
Packages/< syntax >/< syntax >.sublime-settings
Packages/User/.sublime-settings
< Buffer Specific Settings >
In general, you should place your settings in Packages/User/Preferences.sublime-settings.
If you want to specify settings for a certain file type, for example, Python, you should place them in Packages/User/Python.sublime-settings.
http://www.sublimetext.com/docs/2/settings.html
In Sublime 3, just open any file with the extension you'd like to have specific settings for, and go to Preferences > Settings - Syntax Specific.
In my case I did it for Markdown (.md) and Sublime created a Markdown.sublime-settings file in which I added the following:
"trim_trailing_white_space_on_save": false,
In your case, for a .dat file, Sublime will create a Plain text.sulbime-settings file in which you can add the exact same setting.
I am running a non-english Windows 7 system, and apparently Oracle SQL Developer (version 3.0.04.34, 64-bit) tries to auto-guess my preferred language based on the OS. Is there any way to change the language to english?
I've tried the tip found at http://misteratmisis.com/infotech/how-change-oracle-sql-developer-interface-japanese-english, namely adding the VM options
AddVMOption -Duser.language=en
AddVMOption -Duser.country=US
to file ide.conf in directory
/ide/bin
within the SQL Developer installation directory, as suggested, but that didn't help.
Solution (edited on 13.09.2012):
I decided to try again the solution proposed by Alex K. and this time it worked, namely adding
AddVMOption -Duser.language=en
to the file sqldeveloper.conf file located in sqldeveloper\bin\ folder. I presume that it did work now but not before, because meanwhile I have changed my UAC (user access control) settings in Windows 7 so that I am administrator by default. What happened before was probably that even though the changes appeared to be there, the configuration file read by the program was another one (shadow copy).
Solution for Mac OS X (added on 26.02.2016):
Edit file at
/Applications/SQLDeveloper.app/Contents/Resources/sqldeveloper/sqldeveloper/bin/sqldeveloper.conf
and add the line
AddVMOption -Duser.language=en
(Tested with SQL Developer 4.1.3.20)
Try to set user.language and user.country properties in sqldeveloper.conf file located in sqldeveloper\bin folder (%APPDATA%\sqldeveloper\<version>\product.conf for more recent versions) .
Sample for set french language:
IncludeConfFile ../../ide/bin/ide.conf
SetJavaHome D:\jdk1.6.0_25
AddVMOption -Doracle.ide.util.AddinPolicyUtils.OVERRIDE_FLAG=true
AddVMOption -Dsun.java2d.ddoffscreen=false
AddVMOption -Dwindows.shell.font.languages=
AddVMOption -Duser.language=fr
AddVMOption -Duser.country=FR
AddVMOption -XX:MaxPermSize=128M
AddVMOption -Doracle.jdbc.mapDateToTimestamp=false
IncludeConfFile sqldeveloper-nondebug.conf
To switch off language try to remove its support by editing oracle.translated.locales option in ide.boot file (located in ide\bin folder).
For example, if I want to 'break' french language support this option will be:
oracle.translated.locales = de,es,it,ja,ko,pt_BR,zh_CN,zh_TW
The original value was:
oracle.translated.locales = de,fr,es,it,ja,ko,pt_BR,zh_CN,zh_TW
The configuration above (sqldeveloper.conf file) will be wrong after remove french support and the french language does not appear as GUI localization.
You can also set language at runtime
sqldeveloper.exe --AddVMOption=-Duser.language=en
to avoid editing sqldeveloper.conf every time you install new version.
You can also configure directly on the file ..sqldeveloper\ide\bin\ide.conf:
Just add the JVM Option:
AddVMOption -Duser.language=en
The file will be like this:
Or use the menu: Tools->Preferences->Database->NLS and change language and territory.
With SQL Developer 4.x, the language option is to be added to ..\sqldeveloper\bin\sqldeveloper.conf, rather than ..\sqldeveloper\bin\ide.conf:
# ----- MODIFICATION BEGIN -----
AddVMOption -Duser.language=en
# ----- MODIFICATION END -----
Before installation use the Control Panel Region and Language Preferences tool to change everything (Format, Keyboard default input, language for non Unicode programs) to English. Revert to the original selections after the installation.
On MAC High Sierra (10.13.6)
cd /Users/vkrishna/.sqldeveloper/18.2.0
nano product.conf
on the last line add
AddVMOption -Duser.language=en
Save the file and restart.
=======================================
If you are using standalone Oracle Data Modeller
find ~/ -name "datamodeler.conf"
and edit this file
cd /Users/vkrishna//Desktop/OracleDataModeler-18.2.0.179.0756.app/Contents/Resources/datamodeler/datamodeler/bin/
Add somewhere in the last
AddVMOption -Duser.language=en
save and restart, done!
+> In Oracle SQL Developer, you can follow steps by steps as the below image:
+> After opening the file in step 3, you can add this text "AddVMOption -Duser.language=en" to this file and save it.
+> After saving the file, reopen Oracle SQL Developer and check the result.
Problem
Frequently (but not every time) when using CVS to check in files like: .java, .cs, .xml, etc, every line of the file is gets a carriage return.
Example:
File before check-in by a team member:
// Begin file
class Foo
{
public Foo()
{
// Do step 1
// Do step 2
}
}
// End file
File when checked out by a team member:
// Begin file
class Foo
{
public Foo()
{
// Do step 1
// Do step 2
}
}
// End file
Development Environment
NetBeans 6.8 and now 6.9 (the problem occurred when using 6.8 as well).
Visual Studio 2008 and 2010.
Repository: CVS; checkins and checkouts done from Cygwin bash shell.
Operating system: Widows XP Professional.
What I Have Tried
I tried changing the value: build.compiler.emacs=true within NetBeans under Tools->Options, thinking this might be causing some kind of Unix/Windows translation problem when checking in? This made no difference.
Am I missing something about what happens to a file when it gets checked into CVS in a Windows/IDE/Cygwin stack that can cause this problem?
Something is converting DOS line breaks (CR LF) to pairs of Unix line breaks (just LF). I would personally bet on its being CVS. You might want to try using TortoiseCVS instead of Cygwin CVS.
A Windwos-native CVS client will convert MS-DOS line endings in a text file (\r\n) to Unix-style line endings when submitting the file to the server, so that in the repository, the files are maintained in a 'canonical' form with \n representing a line ending. When Windows native client will also convert the line ending when bringing a file down from the server.
However, I believe that the default Cygwin CVS client acts like a Unix client and assumes that no line ending conversion is required. So if you use that client to check in a file with MS-DOS-style endings (\r\n), you'll get this kind of confusion.
It looks like the people who are using the Cygwin client are using tools that care converting the files to MS-DOS style line endings (or something is).
A potential fix is to uninstall the Cygwin CVS client and install the WinCVS client on your Windows/Cygwin boxes so the Windows native client will be used even when a Cygwin shell is active:
http://www.dehora.net/journal/2003/07/a_fix_for_cygwin_and_cvs_linefeeds.html
Another possibility to to configure your Cygwin mounts under a specific mode (but I'm not really familiar enough with Cygwin to know how well this works or if it might introduce otehr problems - it's been a long time since I've tried using Cygwin):
http://www.gigascale.org/softdevel/faq/23.html
Another possibility that I just ran into - if the file was saved in Unicode format but stored in CVS as ASCII/Text, extra line terminators will be added.