TextMate Bugs

From Exterior Memory
Jump to: navigation, search

This is a small list of bug reports for TextMate.


I like TextMate. I changed from BBEdit to TextMate quite some time ago, and never regretted it. However, that means it is perfect to me (it probably is for the developer). TextMate is still clearly made by someone with a UNIX background, and it shows. Sometimes that's great, but some "Mac"-like behaviour is missing. On the other hand, some text-editing features such as control-T for swapping two characters are supported.

This page lists some of the missing features and bugs that I found most annoying.

Other bugs reported by me: as macfreek as Freek Dijkstra

Detect Finder renames

(status: fixed)

Ticket: F6478929

Steps to reproduce:

  1. Open an existing document in TextMate
  2. Rename it in the Finder
  3. Save document in TextMate

TextMate saves it under the old path, while most applications would recognize the finder rename.

Saving Piped Files

(status: unsolved)

Ticket: 2B88544C

Piped files are saved to a random filename instead of asking the user for a filename.

Steps to reproduce:

  1. In a terminal, type:
echo "hello world" | mate
  1. In TextMate, type Command-S

Expected Result:

I expect TextMate to ask the user for a file name. Since that is the behaviour for new files (Command-n, Command-S)

Actual result:

TextMate saves it to /tmp/<randomname>.txt, without asking


Data Loss when Disk is Full

(status: unsolved)

Ticket: 8D1CF295

A careless editor may loose data if the disk is (almost full).

Steps to reproduce

  1. Create a disk image, and fill it up almost completely
  2. Open a text file on the (nearly full) disk
  3. Add contents so that the total exceeds the available disk space. Alternatively, fill the disk in the mean time with other files.
  4. Save the file.

Actual results

  1. A pop-up appears: "TextMate requires that you type your password"
  2. A second pop-up appears: "The file for the document at /Volumes/Disk Image/test.txt has been modified by another application. There are also unsaved changes in TextMate. Do you want to keep the TextMate version or revert to the version on disk?"

If you press "Revert" here, the result will be a deletion of all your text.

Expected results

I expected a warning about a full disk. The current two warnings are confusing.

If revert is pressed, all data is lost, even though no other application accessed the file.

Because I did not know what was going on, I selected "Revert" (which is often the safest choice, given the inability of TextMate to recognize Finder renames). I then ended up with a an empty file. My though was "OK, something is really fishy here. Let's quit TextMate, too bad about my changes, and I continue with the file from the last save. If you do that (I did twice), you end up loosing all contents in the file, even though you never consciously saved the empty file.


No support for decomposed characters

(status: unsolved)

Tickets: 1A576542 22DC5DCA C1DDBEE5

Steps to reproduce:

  1. Make a text file with the line "Hellö world"
  2. Make sure the o-umlaut is represented as decomposed unicode. E.g. codepoints 006F + 0308, not the precomposed varaints 00F6. Use the Character Palete (Choose from the input menu, which you can enable in the International System Preferences) or run the following script:
#!/usr/bin/env python
f = open("test.txt", "w")
line = u"Hello\u0308 world\n".encode('utf-8')
f.write(line)
f.close()

3. open the file in textmate 4. position the cursor betwene the r and l. 5. press delete

Actual result:

The o character is removed, resulting in Hellö wrld

Expected result:

The r character should be removed, resulting in Hellö wold

Notes:

Textmate apparently assumes that one (Unicode) codepoint translates to one character on screen. This is not true. A work-around that works in most cases is to normalize the text to NFC right after opening. This will collapse most codepoints from decomposed to precomposed (e.g it will convert 006F + 0308 to 00F6). However, NOT ALL codepoints will collapse. For example, there is no precomposed equivalent for a with a macron (0061 + 0304) or o with a dot (006F + 0307).


Can not set Font in Output Window

Ticket: F65189C9

The default output window font depends on the theme. It is not possible to select the font. For example, the following text renders horribly in most "monospaced" fonts:

┍━━┯━━┓     ┍━━┱――┐     ┍━━┱――┐
│  │  ┃     │  ┃  │     │  ┃  │
├――┼――┨     ├――╄━━┪     ├――╂――┤
│  │  ▼     │  │  ▼     │  ┃  │
└――┴――┚     └――┴――┚     └――┺━►┙

Fortunately, the fonts Bitstream Vera Sans Mono and Luxi Mono work find (DejaVu Sans Mono, on which Bitstream is based, does not work).

I solved this by creating a custom output window theme (not the be confused with a main window theme), which includes the lines:

.bitstream blockquote {
	border-left: 4px solid #E6E5DD;
	font-family: "Bitstream Vera Sans Mono", "Luxi Mono", "DejaVu Sans Mono", "Monaco", serif;
}
.bitstream code {
	color: #1C360C;
	font-family: "Bitstream Vera Sans Mono", "Luxi Mono", "DejaVu Sans Mono", "Monaco", serif;
}

.bitstream pre {
	background-color: #f0f0f0;
	border: 1px solid #cccbba;
	font-family: "Bitstream Vera Sans Mono", "Luxi Mono", "DejaVu Sans Mono", "Monaco", serif;
}

Feel free to download the File:Bitstream.zip (bitstram/style.css, bitstream/images/header.png and bitstream/images/teaser.png) and put the bitstream folder inside the ~/Library/Application\ Support/TextMate/Support/themes folder. (Thus not the ~/Library/Application\ Support/TextMate/Themes folder!)

If the ~/Library/Application\ Support/TextMate/Support folder does not exist, create it as follows:

mkdir -p ~/Library/Application\ Support/TextMate
cd ~/Library/Application\ Support/TextMate
svn co http://svn.textmate.org/trunk/Support

If the new theme disappears after an upgrade of TextMate, update the Support folder:

cd ~/Library/Application\ Support/TextMate/Support
svn update


Print orientation

(status: unsolved)

Ticket: 1EBA6193

There is no "Page Setup..." item in the file menu, and it seems not possible to print in landscape view.


Click-Through

(status: work-around available as third-party application Klicko)

Ticket: 9EE7E17E

Click-through means that if a window is not active (it is in the background), and when you click it, it not only is brought to the foreground, but in addition the click is handled and processed by the Application.

Steps to reproduce:

  1. Open a TextMate window, and fill it with enough text so that a scrollbar appears
  2. Bring another application to the front
  3. Observe that the scrollbar is dimmed in the background. This is good practice.
  4. Click the (dimmed) scrollbar

Actual results

the window is brought t o the foreground, and in addition, the scrollbar is handled: the viewwindow scrolls up or down.

Expected results

I expected that only the application was brought to the foreground. That would be consistent since the scrollbar was dimmed (seemingly inactive).

Notes

TextMate partially handles click-through: clicks inside the text area are ignored. Click-through is generally considered unfavourable by GUI designers. See the following discussion at Daring Fireball and Apple Human Interface Guidelines.


Shift Right indentation

(status: workaround exists using a custom bundle)

Ticket: C8B9B77D

I would like that TextMate also alter the number of tabs with the "Shift Right" command. Now it leaves empty lines untouched.

I have two reasons for this:

  • visual clue (I have "Show Invisibles" always on)
  • recognition of folding blocks breaks with the current behaviour, and I have to manually adjust

Steps to reproduce:

  1. Create a new file, with contents:
#!/usr/bin/env python
def HelloWorld():
    print "Hello";
    
    print "world";

HelloWorld();
  1. Select line 3 to 5 in the file (the two print statements with the line with 4 spaces only in between)
  2. From the "Text" menu, select "Shift Right"

Expected result:

I expected that these lines would now read:

        print "Hello";
        
        print "world";

(thus that the middle line would have 8 spaces)

Actual result:

The lines actually read:

        print "Hello";
    
        print "world";

(thus the middle line still have 4 spaces)


Open URL

(status: unsolved)

I'm used to clicking on a URL in a text and go to that URL in a webbrowser. In Mac OS 9, there was an extension that allowed to do that by command-clicking on any URL. In Mac OS X virtually all text editors or text viewers, if you right-click on a URL, you get a menu which (among others) says "Open URL". Try BBEdit, SubEthaEdit, Stickies, or TextEdit. They all have this feature. Except for TextMate. Perhaps I can create it using "Filter Through Command...", but that's clumsy. I suggest to add this feature like in all other editors.

Workaround 1:

For this there is "Open URL" in the Services menu, look at this hint to assign a shortcut to it: http://www.macosxhints.com/article.php?story=20040416191600412

Workaround 2:

It's also easy to make a custom command to open the selected URL. I put one inside my Text bundle. Here's the entire thing:

 open "$TM_SELECTED_TEXT"

Both of these solutions do require the URL to be selected first. A version that didn't require that (i.e. you could simply place the caret inside the URL) would be nice, but a bit more work.


Dragging an URL to a HTML file

(status: unknown)

I struggled long to understand "DragCommands" (there is not useful mention of them in the help or on the wiki). I would love to be able to make a DragCommand that allows me to drag a URL to a HTML text file, and that the drag then automatically inserted a <a href="$URL">$name</a>, preferable with the previous selection as the $name. However, it seems that now, DragCommands only work on files, not on other drags like URL's and images.


Compare two files

(status: fixed, using the diff bundle)

TextMate can't properly compare two files; you can't even compare text in two open windows unless you saved them to disk.

Workaround: Use BBEdit or FileMerge from Apple (in the Developer tools), or same temporary files.

Sorting EURO character

http://lists.macromates.com/textmate/2009-August/029354.html

Summary: sort does not with euro symbol, and some other non-Latin characters (at least €, …, “, ”, ‘, and ’)

Steps to reproduce

  1. Open new text file.
  2. Add text with a EURO symbol, e.g.
aaa €
bbb ¥
ccc $
ddd £
  1. sort the file with F5 (Text > Sorting > Sort lines in document)

I get the error:

sort: string comparison failed: Illegal byte sequence
sort: Set LC_ALL='C' to work around the problem.
sort: The strings compared were `AAA \302\202\254' and `BBB ¥'.

Most non-Latin characters work fine. Just this one fails. If I save the file and simply run "sort test.txt" all is fine. Both in my shell and in TextMate, "echo $LC_ALL" return "en_GB.UTF-8".

Typing the following script in TextMate and "run script" works fine: echo "ccc\naaa€\nbbb" | sort

No solution known.

TextMate 2: headers in SeText files don't align underline

Textmate2 by default uses different font sizes for headers. This may look odd if you are using monospaces fonts.

To change this, open the Bundle Editor, pick the Themes bundle, and select Settings. In the Settings, change the preferences for larges or smaller fonts.