I think I've mentioned this before, but I do wish it were fixed so I'm mentioning it again. Sometimes the global Find dialog shows (correctly) that my search text occurs on a certain line of a certain file but doesn't show the occurrence. In this screen shot, the first two occurrences are listed but the found text is at the end of the line whereas what we are being shown is the start of the line.
The occurrences listings are not horizontally scrollable so there seems no way to learn the context.
As the third line shows, this does work sometimes. It's a great feature and I've come to rely on it, so I do wish it worked all the time.
m.
--
matt neuburg, phd = http://www.apeth.net/matt/
pantes anthropoi tou eidenai oregontai phusei
Programming iOS 11! http://shop.oreilly.com/product/0636920107408.do
iOS 11 Fundamentals! http://shop.oreilly.com/product/0636920107415.do
RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html
1. Open ⌘⇧-T window
2. Open a file that takes some time to syntax highlight
Expected: newly opened file highlights, and function window populates
Obtained: Spinning wheel of death
Alternative repro
1. Open a file that takes some time to syntax highlight
2. Open ⌘⇧-T window (you probably have a few seconds to do this)
Expected: Function window populates with function list
Obtained: Spinning wheel of death
Version: 2.0-rc.7.
I’ve recently moved to a new machine (an iMac Pro), and have successfully installed Texlive 2017 and TextMate. When I use other LaTeX editors, I can successfully typeset LaTeX files, but not when I use TextMate. I typeset in the old fashioned dvips->ps->pdf way, and the problem I seem to be having is with the ps2pdf utility, that finishes the conversion of the file from postscript to pdf. The error message says that this utility has run too many times. When I view the postscript file that is created during this process, it looks fine and I can get Preview (and Skim) to translate it into a pdf.
Because other editors can typeset fine, I’m thinking that there is something wrong with the way that TextMate calls the ps2pdf process on my machine. Has anyone experienced this problem?
Thanks in advance,
Kyle Johnson
Both are system, macOS, limitations for QuickLook.
For the second point, I believe, and I’m sure someone here will correct me, the images and videos that are supported formats (that is handled natively by macOS, don’t seems to have this issue. If the image or video format requires/relies on external app’s quicklook abilities then those will exhibit the same behavior.
Best,
Farhan
> On Mar 25, 2018, at 4:08 PM, Christian Rosentreter <karibu(a)gmx.net> wrote:
>
> * It cuts off files at a certain amount of lines. This wouldn't be so bad by itself, but there
> is zero visual indication that the displayed text is cut off (something like a special coloured
> ellipsis symbol at the end, or something)
>
> * if the system is under load (say something else, e.g. a raytracing application, is using 100%
> CPU) I only get the spinning indicator in the QL window and it never manages to actual display
> the text. It is as the TextMate QL generator runs with such low priority it doesn't get a share
> of CPU by the OS. Other file types (images, even videos) don't seem to share the same problem.
Hi,
I have a command (copied below) which grabs the paths of the selected items in the Finder, and inserts them into a textmate doc.
I'd like to do some post-processing of the result (replace e.g. replace "/Users/.*/" with "~", and strip trailing return character.
How does one take the resulting string from a script, and process it, say, in php or bash. or should I just work on post-processing theList in applescript?
Thanks!
#!/usr/bin/env bash
osascript -e 'tell application "Finder"
set theFiles to selection
set theList to ""
repeat with f in theFiles
set theList to theList & "\"" & POSIX path of (f as alias) & "\","
end repeat
return theList
end tell'
Revert to RC7. RC8 has this breakage trying to deal with files that
have no extensions.
--
Marc Wilson
msw(a)cox.net
On Thu, Mar 22, 2018, at 6:13 AM, Rob McBroom wrote:
> After the last update, I noticed some garbled Quick Look previews in
> my Downloads folder.>
> I’m pretty sure it results from this commit:
> https://github.com/textmate/textmate/commit/fd827fb8179cd74e553680d605d2172…> As you can see form the image, it doesn’t seem to affect all files,
> but I would argue that no application should claim Quick Look support
> for every file in existence.>
> --
> Rob McBroom
> http://www.skurfer.com/
>
>
> _________________________________________________
> textmate mailing list
> textmate(a)lists.macromates.com
> http://lists.macromates.com/listinfo/textmate
Yes. I’ll second this. Having the same issue. Is there a better way to resolve the issue, as it is stated in the commit message?
Best,
Farhan
> On Mar 22, 2018, at 9:13 AM, Rob McBroom <mailinglist0(a)skurfer.com> wrote:
>
> After the last update, I noticed some garbled Quick Look previews in my Downloads folder.
>
> <Screen Shot 2018-03-22 at 9.06.59 AM.png>
>
> I’m pretty sure it results from this commit:
>
> https://github.com/textmate/textmate/commit/fd827fb8179cd74e553680d605d2172…
>
> As you can see form the image, it doesn’t seem to affect all files, but I would argue that no application should claim Quick Look support for every file in existence.
>
> --
> Rob McBroom
> http://www.skurfer.com/
After the last update, I noticed some garbled Quick Look previews in my
Downloads folder.
I’m pretty sure it results from this commit:
https://github.com/textmate/textmate/commit/fd827fb8179cd74e553680d605d2172…
As you can see form the image, it doesn’t seem to affect all files,
but I would argue that no application should claim Quick Look support
for every file in existence.
--
Rob McBroom
http://www.skurfer.com/
