Hey all,
I've been having this issue for a while now where the global find window
doesn't search .hbs (Handlebars) files. It's now occurring too with .elm
files. There's nothing in my .tm_properties that would suggest anything
like this:
windowTitle = "$TM_DISPLAYNAME – $TM_DIRECTORY (git: $TM_SCM_BRANCH)"
excludeInFolderSearch =
"{$excludeInFolderSearch,$extraExcludes,dist,node_modules,deps}"
excludeInFileChooser =
"{$excludeInFolderSearch,$extraExcludes,dist,node_modules}"
And the global find is matching all file extensions. Not sure where else to
look here, anyone know what I'm doing wrong?
Thanks!
Hello,
I cloned https://github.com/textmate/textmate <https://github.com/textmate/textmate> to my Mac, then successfully built and ran it.
But when I copy the binary to another Mac, it cannot be launched because of missed dylibs.
I compared linked dependencies with public Beta version and detected the following difference:
/Applications/TextMate.app/Contents/Frameworks/plist.dylib:
@rpath/plist.dylib (compatibility version 1.0.0, current version 1.0.1)
@rpath/cf.dylib (compatibility version 1.0.0, current version 1.0.1)
@rpath/io.dylib (compatibility version 1.0.0, current version 1.0.1)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1258.1.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.1.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1)
vs
/Users/vadim/build/TextMate/Applications/TextMate/TextMate.app/Contents/Frameworks/plist.dylib:
@rpath/plist.dylib (compatibility version 1.0.0, current version 1.0.1)
@rpath/cf.dylib (compatibility version 1.0.0, current version 1.0.1)
@rpath/io.dylib (compatibility version 1.0.0, current version 1.0.1)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1348.15.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 307.4.0)
/usr/local/lib/libcapnp--no-undefined.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/local/lib/libkj--no-undefined.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.0.0)
Apparently that another Mac does not have capnp and kj in /usr/local/lib/.
Maybe you can hint why these dylibs are linked and why the paths are absolute? 🙏
Thanks in advance,
Vadim
P. S. This is my first request, and I submitted it to the IRC channel because not sure where to look for help, sorry for duplication.
I use the pdflatex option and view in Skim. Ever since I installed macOS Sierra, when I typeset my latex file, the page in the created pdf file no longer corresponds to the location in the latex file. In fact, the opened page is where the last opened page is. I would appreciate your help with any solution to this problem.
Tao
Hi,
I’m running TextMate 2.0-beta.12.26 on OSX El Capitan (10.11.6)
I ran into the following issue today:
While going through some code refactoring, I changed a couple of files, but I forgot to save one of these files (so it showed up half transparant in the file list sidebar).
I then modified the name of the folder which contained that open file (I did that in TextMates file list sidebar). The project is in a git repo by the way.
After that I moved focus to another program (I’ve got TextMate set to automatically save on focus lost) but TextMate then switched to the open file, presenting me a modal sheet “No parent folder for <filename>. Do you wish to create a folder at <previous_name_of_renamed_folder>” with buttons ‘Cancel’ and ‘Create Folder’.
None of these buttons are reacting to mouse clicks, space bar or return keys. Due to the sheet being modal, my only recourse is to force quite TextMate.
After relaunching TextMate, I found the file in the renamed folder (without the unsaved changes I made to it).
I made the changes again, saved this time, changed the file name and then changed the folder name.
On focus lost showed me the same modal sheet again! (after which I had to force quite TextMate again).
Now when I open this project in TextMate, it opens in the tab containing the above file, with the new contents, but with the *old* name. The file list sidebar shows the new name.
As soon as I move focus elsewhere, it shows me the unresponsive modal sheet (with the old file name in the error message!), so I’m actually kind of stuck now…
Best regards,
Bas
Hi,
I recently created a [TextMate bundle][] for [ABNF][]. The [RFC][] that describes the current version of ABNF explicitly states that the standard uses CRLF (Carriage Return + Line Feed) for line endings.
[TextMate bundle]: http://github.com/sanssecours/ABNF.tmbundle
[ABNF]: http://en.wikipedia.org/wiki/Augmented_Backus–Naur_Form
[RFC]: https://tools.ietf.org/html/rfc5234
TextMate already supports different line endings in the “Save Dialog”. This works quite well, as far as I can tell. We can also explicitly tell TextMate to always use specific line endings via “Preferences” → “Files” → “Line Endings”. If we set this option to “CRLF” then TextMate adds the entry
lineEndings = '\r\n'
to the global properties file `Global.tmProperties`. However, in both the current development version of TextMate (2.0-beta.12.26), and the lastest normal release (TextMate 2.0-beta.12.4), this feature does not seem to work as expected:
---
# Steps to Reproduce
1. Set line Endings to “CRLF” in “Preferences…”
2. Create a new file via `mate test.txt`
3. Enter the following text in the new document
line 1
line 2
4. Check the line endings via the command `file test.txt`
# Expected Result
The `file` utility displays the following output:
test.txt: ASCII text, with CRLF line terminators
# Actual Result
The `file` utility displays the following output:
test.txt: ASCII text
---
Maybe I am doing something wrong here?
I would also expect that the default “Save Dialog” reflects the line ending option currently set via “Preferences…”. This seems not to be the case. If I save a new document via `⇧` + `⌘` + `S`, TextMate always shows “LF” as default option for line endings. Again, maybe this might be a problem with my expectations on how the system works.
After this long introduction :o) here is my feature request. It would be very nice if it would be possible to set scope- and file-specific line endings. For example, I want to create a new “Settings” item set to the scope `source.abnf` that contains the following code:
{ lineEndings = '\r\n'; }
The “TextMate Settings” grammar currently marks `lineEndings` as invalid key. I suspect this feature is currently not available/implemented? If this is correct, then please consider this a (low priority) request to add this feature.
Kind regards,
René