Is there any way to make TextMate automatically detect the indentation when opening a file? For example if my indentation setting is set to tabs and I'm opening a file with soft tabs, I want TextMate to change my indentation setting to soft tabs. My Google Fu isn't good enough to find a bundle for this.
TabMate might work for you - it uses modelines to tweak your settings on a per file basis.
TextMate does do some of that for you, saving your settings on a per language setting. (aka: set soft tabs for a .py file and TM will remember that setting for all .py files
Related
For some time now, I can't change FileMerge's font. Then it suddenly started using a Helvetica-like font (sans serif, variable width) for files it doesn't recognize (like typescript source files). That could be changed temporarily to monaco by changing the font to ... Helvetica. Yes, it's very weird.
But now, it shows all text white on white, and only the changed section is visible because of the different background and I cannot change it. I've tried to locate all the pref files, and reinstalled Xcode, but the text remains white on white.
Does anyone know how to change that, or where which (pref) file to change?
It could be a write permission issue, since I'm running it from a non-admin account.
Thanks.
This feature is completely broken, so you have to edit the theme file manually. It's located here:
~/Library/Developer/FileMerge/UserData/FontAndColorThemes/Default.xccolortheme
The file itself is plaintext XML. Even though it's pretty straightforward, I recommend backing it up first.
For example, if you want to increase the font size from "11.0" to "14.0", just do a find and replace.
You might be tempted to copy in a theme from Xcode. Don't bother. The font sizes don't appear to take effect, and FileMerge expects a white background, so darker themes won't work correctly.
The other answers didn't work for me (as I didn't have any theme files), but the following did:
Open FileMerge
Go to Preferences
Click the 'Set...' button under 'Font'
Click the top of the Fonts window so that it gets focus (this is the key step - if the Fonts window doesn't get focus the changes won't stick). If the Fonts window has focus, you should see your changes reflected in the FileMerge Preferences window live as you make them.
The solution was to delete the folder ~/Library/Developer/FileMerge. It did not solve the font problem (typescript files rendered with proportional font of different size, which causes problems for long files).
For me also the font panel settings have no effect at all. Same problem in XCode "Font & Colors" preferences.
For your colors problem, I would try quitting FileMerge, archiving the preference file, and relaunching:
mv ~/Library/Preferences/com.apple.FileMerge.plist ~/Library/Preferences/com.apple.FileMerge.plist.backup
FileMerge has a XCFontAndColorCurrentTheme setting:
defaults read com.apple.FileMerge XCFontAndColorCurrentTheme
I've tried setting that:
defaults write com.apple.FileMerge XCFontAndColorCurrentTheme "Presentation.xccolortheme"
But I don't see a difference. So maybe Apple is in the middle of revising this feature.
In addition to the answers already given, if those do not work, check that the files you are comparing are plain text and not rich text. If they're rich text, file merge will get the font attributes from the files themselves, hence you will not be able to affect the size of the font. You could instead open the files in a text editor and either convert them to plain text, or increase the size of the font manually.
None of this helped in my case on Big Sur, but this did the job. Requires sudo throughout so be careful.
Make a copy of a theme within the xcode bundle:
sudo cp "/Applications/Xcode.app/Contents/SharedFrameworks/DVTUserInterfaceKit.framework/Versions/A/Resources/FontAndColorThemes/Default (Light).xccolortheme" "/Applications/Xcode.app/Contents/SharedFrameworks/DVTUserInterfaceKit.framework/Versions/A/Resources/FontAndColorThemes/fileComp.xccolortheme"
Edit (in xcode for example) ~/Library/Preferences/com.apple.FileMerge.plist. Select the new theme by setting the XCFontAndColorCurrentTheme value to fileComp.xccolortheme
Edit the font values in new theme file fileComp.xccolortheme. Quit and restart FileMerge each time to apply.
I'm working with RubyMine 2017.1.3 on Linux and it appears that RubyMine has modified one of my files to better fit its own idea of formatting. That causes distracting changes in the files since I have to inspect the differences (as detected by Git) and see if they are changes that I meant to make or what.
Is there a way to prevent RubyMine from automatically modifying a file? I searched through the settings but I wasn't able to find anything.
Go into Preferences -> Editor -> Code Style -> Ruby and change the settings to match your existing code (e.g. line spacing, tab width, etc).
Make sure to pick the correct boxes when commiting changes.
In Scite text editor there is a global properties file shipped with the editor. I downloaded Scite latest version from the website but when I open the open dialog in scite, not all the filters show up in the drop down menu. For example, verilog, TeX, and many more filters do not show up, even though they are enabled in the sciteglobal.properties file under open.filter
Is this a bug in scite or am I missing something?
For example some filters that do work are perl, lua, ada - but tex, verilog, pascal, and more do not show up in the drop down. They are not commented out in the global properties file.
A temporary work around is to move them around to different spots in the global properties file. for example if I move them to non alphabetical order and put them at the very top, they seem to be enabled.
I know the ALL SOURCE files filter is limited to 256 characters or something similar, but the individual filters should not be limited in the drop down menu and they should not be missing.. right?
I compiled scite from the source code myself, and it has the same problem. Or is there something as designed that I am missing and this is not a bug?
Found a solution to my own question...
The default sciteglobal.properties file that ships with scite is incorrect. It is parsed wrong due to the commenting out of items such as modula open filter. Remove all pound signs in the open filters so nothing is commented out in the open filter list, and this fixes the problem.
Instead of commenting out the items in open.filter list, use imports.exclude to remove an item from being seen.
I like to utilize Markdown for a lot of the text that I write. To that end I wanted to try out the MarkdownEditing plugin for Sublime Text 3, but am having some user experience issues:
I cannot figure out how to change the color scheme such that it affects the MarkdownEditing syntax editor. Changes to .Packages\User\Preferences.sublime-settings do not effect display settings when in this syntax highlighting mode. However, those changes are reflected in other tabs. How do I change the color scheme when making use of the MarkdownEditing syntax highlighting?
How do I turn on line numbers when making use of this syntax plugin?
TL;DR
If you are using Markdown GFM syntax, open/create "Data/Packages/User/Markdown.sublime-settings" and add:
{
"color_scheme": "Packages/your/custom.tmTheme",
"line_numbers": true
}
See menu: Preferences > Package Settings > MarkdownEditing.
There are 3 different settings there for 3 different syntaxes. First check what "default" settings does and then undo it in "user" settings.
To stop the MarkdownEditing package from overriding your color scheme on Markdown files:
Open Preferences > Settings - User
Find your color_scheme line - e.g. it looks like
"color_scheme": "Packages/Color Scheme - Default/Monokai.tmTheme",
Copy the entire line
Open Preferences > Package Settings > Markdown Editing > Markdown GFM Settings - Default
Comment out the other color_scheme lines by adding // in front of them
Paste your line instead
Save the file
Markdown files will now use your regular color scheme rather than using their own scheme just for .md files.
If you get an error about "Error trying to parse settings", make sure your line ends with a , if there are lines below it, and does not end with , if it is the last line.
This was one of the most annoying things about this plugin when I installed it a while back, so I promptly got rid of it. However, before doing so, I figured out how to solve your problems. First, since you're using ST3, you'll need to install the quite-useful PackageResourceViewer plugin. Open the Command Palette (CtrlShiftP on Windows), type in prv to bring up the PackageResourceViewer options, and select Extract Package. Scroll down and select MarkdownEditing, hit Enter, and you're all set. You can now open Packages/MarkdownEditing (Packages should be in C:\Users\username\AppData\Roaming\Sublime Text 3, also available by selecting Preferences -> Browse Packages...) in the sidebar and browse through all the different .sublime-settings files for the different syntaxes and for the main plugin, changing things as you want. The syntax-specific files use all the same options found in Preferences -> Settings-Default, so for example you can set "line_numbers": true to turn line numbering back on, and change the value of "color_scheme" to your preferred value.
I had another packaged named Markdownlight which was overriding the color scheme. I had to uninstall it before the color_scheme in the MarkdownEditing user settings took affect.
In our project there are two teams and are using different IDE for development (MyEclipse and Xcode). Is there any way to keep indentation similar in both the IDE, because when we are doing diff it's showing lots of changes only because of indentation.
If they are using the same code base, there should be no differences. If you are comparing copies of the same code base, maybe there are XCode settings that modify tabs when saving code. If you are using Windows with MyEclipse and OS X with XCode, maybe line endings get switched on save. There should be preferences for that, too. There are also preferences for formatting code on save, or you may have plug-ins for cleaning up code. Lastly, there is a preference for using spaces or tabs to indent code.
There are preferences for how code is displayed, such as how many spaces to use for tabs, but this doesn't affect the actual files. So, again, if the same code base is used then there should be no differences. Perhaps you could expand on what you are comparing with what, if this answer doesn't help.