Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

Syndacate

macrumors regular
Original poster
Mar 16, 2008
127
0
Hey,

I despise TextEdit. I've used VI since I've been using computers so naturally I took very well to MacVim. Though I want to set it as my default editor for editing blank files (plain UTF-8 text files without an extension).

So I threw the .app inside of a folder named "oldTextEdit" and created a symlink to MacVim and named it TextEdit.app and placed it in /Applications, but it doesn't work.

When I go to the command line and type "open -e" it still opens with TextEdit.app - The only thing I can think of is that it ignores symlinks (or as mac calls them, an "alias.")

I moved TextEdit.app to another drive and my alias worked fine on double clicking a blank file, it opened up MacVim. BUT - if I go to terminal and type "open -e" it opened up TextEdit (not sure how). Now when I click that same UTF-8 blank text file (created using "touch") it opens in TextEdit (again, I have no clue how, TextEdit.app is on a different drive).

Update:
I zipped up TextEdit.app and now when I open blank text files it opens in MacVim like it should.

This time when I type "open -e" it throws the following error:
LSGetApplicationForInfo() failed with error -10814 while trying to determine the application with bundle identifier com.apple.TextEdit.

Which I guess is fine, as long as in the GUI is opening with MacVim instead of TextEdit...

Anybody have any ideas on the proper way of doing this? I realize it involves the LaunchServices.framework database, but I can't figure out how to use that for hell.

I realize to some this is a weird request, so I ask if you don't have any good input you just ignore it.

Thank you for your time.
 

Thank you for your reply, though that doesn't fix my problem.

That was the first thing I tried, before I started linking everything. The only problem is that mac seems to have a big problem for defining an application to open files where "type" is null and "extension" is null, since it's a blank/flat UTF-8 text file it has none of the above, the GUI extension of "open" in which you change what opens it via "Get Info" depends on the extension and the mime type, which this has neither.

It'll let me change it for each individually, but obviously that's a pain, if I click "Change All" it throws an error saying:
"An error occured whioe changing the application that opens "filename" because not enough information is available. Do you want to open "filename" with "MacVim.app"?"

My choices then are "Cancel", "Don't Update", and "Update. If I hit "Cancel" or "Don't Update" it just goes away. If I hit "Update" it will set it as the default application to open with for THAT file only. If I touch another file it will again open with TextEdit. I mean right now it won't because the fact that I hid TextEdit along with a pointer at TextEdit to MacVim is holding, though that's a hack, that's nothing like actually changing the default editor. Also, if I go into "get info" on the new file, the "open with" dialog is blank, like it would be for a blank file. If I didn't have TextEdit zipped up, it would have opened with that (tried to "Change All") before I zipped up TextEdit.

The problem is that it relies on MIME types and extensions to pick the app to open it with. It wasn't given a way to handle null strings for the MIME type or extension.
 
The only problem is that mac seems to have a big problem for defining an application to open files where "type" is null and "extension" is null, since it's a blank/flat UTF-8 text file it has none of the above, the GUI extension of "open" in which you change what opens it via "Get Info" depends on the extension and the mime type, which this has neither.

Why not just select all such files and give them an extension? Then you'd be able to assign a default app.
 
Why not just select all such files and give them an extension? Then you'd be able to assign a default app.

I'm sorry, I work in Linux or UNIX environments all day. I'm really not used to flat text UTF-8 encoded files having extensions. That is an alternative, but there should be a way to set the default text editor.

The mac managed fine using TextEdit to open the files without extensions, so there's no reason to think it shouldn't work fine with MacVim if I was somehow able to change that to the default text editor.

Ever since I zipped up TextEdit and made a pointer to MacVim.app called "TextEdit.app" it's been pretty good about opening blank text files with no extension with MacVim - though this is still a hack to fool OS X, I rather do it the right way.
 
Interesting... I wanna do the exact same thing.

Syndacate, did you find a way to solve this without hacking, i.e. without creating a symlink TextEdit.app pointing to MacVim (and removing the TextEdit application)?

I can't believe there isn't an easy way to simply tell OS-X to use MacVim instead of TextEdit as default editor (system-wide, NOT for each file extension individually)...
 
Interesting... I wanna do the exact same thing.

Syndacate, did you find a way to solve this without hacking, i.e. without creating a symlink TextEdit.app pointing to MacVim (and removing the TextEdit application)?

I can't believe there isn't an easy way to simply tell OS-X to use MacVim instead of TextEdit as default editor (system-wide, NOT for each file extension individually)...

I can believe it, because it's not in Apple's interest for the default editor to be changed. Though you can try the UNIX method though, which is what works on most other non-proprietary UNIX systems, and all Linux systems, which I didn't think about until just now:
"export EDITOR=/Applications/MacVim.app"

Although that may not work, that may only replace pico with MacVim - which isn't at all what we want, we still want pico in there. Though it may be worth a shot, if it fails, then revert to using pico for a command line editor:
"export EDITOR=/usr/bin/pico"

Though I haven't found any better ways. I've simply symlinking TextEdit.app to wherever I want to start it, and that works well for me. I also just put the MacVim icon on my dock (I don't keep any program that's on my dock when off), so I can drag it onto the MacVim icon and open it at any time. I'm not big on the whole drag and drop thing, but it's pretty much been the only answer I can find to this pain in the ass thing.

** still loooking
 
I'm new to this but,

I've been having the same problems since i often work with the "null" files. However, after renaming the applications (TextEdit.app -> TextEdit_old.app AND TextWrangler.app -> TextEdit.app) the mac did what i wanted.

I'm not sure if this will mesh with the system when an upgrade to the editor rolls out, but it did the trick.
 
I've been having the same problems since i often work with the "null" files. However, after renaming the applications (TextEdit.app -> TextEdit_old.app AND TextWrangler.app -> TextEdit.app) the mac did what i wanted.

I'm not sure if this will mesh with the system when an upgrade to the editor rolls out, but it did the trick.

I'm not entirely sure what you mean by a "null" file - if a file is null, it doesn't exist, the file pointer simply points to 0x0 and nothing is read when it's accessed. This will result in a null pointer failure which may result in Finder jamming up, or possibly a kernel panic. I do not know how to create a "null" file so I never did that - I don't know if they have catches in place for it, but a text editor (whether it be textedit, text wrangler, bbedit, or what have you) sure as **** won't be able to open it. It might even get segmentation faulted by OS X while trying to access memory out of its space.

That method will work as long as you use the GUI to work with your files. If you use the `open` command from a command terminal it will open with textedit IIRC, even though you re-named it. This is most likely because it's simply a pointer to the program data, not necessarily where the program appears in a human readable sense. Regardless, if you zip the textedit.app (or whatever you renamed it to), it will throw an error if you use the `open` command.

I ended up just renaming it, like you did, and use that, although I'm not sure I've found a code editor for Mac that I really like. It is annoying though that most of its coding abilities are heavily integrated into XCode, but aside from that, as far as quick code editors go, there's (from what I see) smultron, textwrangler, bbedit, textmate, macvim, and maybe a few more that are escaping me at the moment. Nothing that really made me all warm and fuzzy.
 
Sorry to dig up such an old thread but I could not find any more recent information on that matter.

I think I found a solution that works in a shell with "open -e" as well. At least it works with TextWrangler.

It is quite an ugly hack. Any more elegant solution would be welcome.

Step 1: Disable TextEdit
Renaming the TextEdit.app folder is not enough. Renaming the Contents folder inside works though (I renamed it to Contents_ ) as the OS cannot find the application files anymore.

Step 2: Rename (or copy) your favorite editor .app folder to TextEdit.app (a symbolic link does NOT work!)

Step 3: Go into your new TextEdit.app folder and edit the file "Contents/Info.plist".
Find the lines

<key>CFBundleIdentifier</key>
<string>com.barebones.textwrangler</string>

(This is for TextWrangler. The second line will vary depending on your text editor)

Change the second line to "com.apple.TextEdit"

<key>CFBundleIdentifier</key>
<string>com.apple.TextEdit</string>

Step 4: You might have to make the Mac forget about TextEdit.
Easy solution: reboot. Otherwise, renaming some files in the Applications folder seems to force it to rebuild the database of installed applications and file associations (or something like that).


Notes:
Step 2 seems necessary for the GUI to find the text editor. It has no impact on "open -e" which apparently relies on another mechanism to find the text editor.

Step 3 is necessary for "open -e" to work. (Actually "open -e" works even without step 2.)


Known issue: the editor is named TextEdit in the dock (but shows up with its own icon).
 
Sorry to dig up such an old thread but I could not find any more recent information on that matter.

I think I found a solution that works in a shell with "open -e" as well. At least it works with TextWrangler.

It is quite an ugly hack. Any more elegant solution would be welcome.

Step 1: Disable TextEdit
Renaming the TextEdit.app folder is not enough. Renaming the Contents folder inside works though (I renamed it to Contents_ ) as the OS cannot find the application files anymore.

Step 2: Rename (or copy) your favorite editor .app folder to TextEdit.app (a symbolic link does NOT work!)

Step 3: Go into your new TextEdit.app folder and edit the file "Contents/Info.plist".
Find the lines

<key>CFBundleIdentifier</key>
<string>com.barebones.textwrangler</string>

(This is for TextWrangler. The second line will vary depending on your text editor)

Change the second line to "com.apple.TextEdit"

<key>CFBundleIdentifier</key>
<string>com.apple.TextEdit</string>

Step 4: You might have to make the Mac forget about TextEdit.
Easy solution: reboot. Otherwise, renaming some files in the Applications folder seems to force it to rebuild the database of installed applications and file associations (or something like that).


Notes:
Step 2 seems necessary for the GUI to find the text editor. It has no impact on "open -e" which apparently relies on another mechanism to find the text editor.

Step 3 is necessary for "open -e" to work. (Actually "open -e" works even without step 2.)


Known issue: the editor is named TextEdit in the dock (but shows up with its own icon).

Makes sense, good work-around!

What I ended up doing was just saying:
Code:
open -a MacVim <file>

It is longer, but yeah. Though I've gotten quite used to it by now, haha. I also keep MacVim on my dock and drag files there whenever I'm not working on them in the Terminal. Thx for the methodology, though.
 
Makes sense, good work-around!

What I ended up doing was just saying:
Code:
open -a MacVim <file>

It is longer, but yeah. Though I've gotten quite used to it by now, haha.

Make a shell alias:
Code:
alias ov 'open -a MacVim'
ov your-file-here
A name other than ov would also work. Pick one that isn't an existing command.
 
Make a shell alias:
Code:
alias ov 'open -a MacVim'
ov your-file-here
A name other than ov would also work. Pick one that isn't an existing command.

That's true, I can also (and probably would rather) use a symbolic link and drop it in /usr/bin or /bin. It would have similar (same0 functionality.
 
I've been using vi since the mid-80s and would rather use just about anything else instead lol. I still use it most days at work but definitely not at home. I guess it's one of those things where you either love it or hate it :)
 
That's true, I can also (and probably would rather) use a symbolic link and drop it in /usr/bin or /bin. It would have similar (same0 functionality.

A symlink to what? MacVim? No, that's not the same. It's not even similar.

Telling an app to open a file sends it a message (an "open document" Apple event). That's what the 'open' command does: send a message. A symlink to MacVim would start a new process when used as a shell command.
 
I've been using vi since the mid-80s and would rather use just about anything else instead lol. I still use it most days at work but definitely not at home. I guess it's one of those things where you either love it or hate it :)

For me it's a love/hate relationship. On one hand I love it, I love the option-set, especially. On the other hand, there's nothing like mousing over a variable and a tool-tip telling you every detail, or hitting ctrl+****+U and finding every place that variable is accessed (not just a global find).

A symlink to what? MacVim? No, that's not the same. It's not even similar.

Telling an app to open a file sends it a message (an "open document" Apple event). That's what the 'open' command does: send a message. A symlink to MacVim would start a new process when used as a shell command.

I suppose similar would be a more appropriate term, I do, however, feel it would have a similar effect. Though it doesn't matter as I'm already set in my way of using it as I have been.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.