Hi,
maybe this is a general issue.
I'm working a lot with bash/perl scripts. Sometimes I would like to
drag'n'drop a file from the Finder or from the Project Drawer to my
current document to only insert the relative/absolute file path plus
name. Up to now it is "only" possible to insert the content of that
file which is very useful. How about to use SHIFT drag'n'drop to
insert the relative file path and OPT drag'n'drop to insert the
absolute file path. Of course, the drag'n'drop commands specified in
bundles come first.
The only solution I found is to generate a drag'n'drop command, File
Types: *, Scope: empty, and handle the insertion stuff by myself.
--Hans
In the dialog after executing "Call Generate Script in Rails"
I think "OK" is more appropriate than "Ok" as the button label.
Takaaki
--
Takaaki Kato
http://samuraicoder.net
Thomas Aylott - subtleGradient wrote:
>
>
> I do recommend using Transmit with DockSend and the Transmit bundle
> for TextMate.
> Set it up properly and you can upload with a single action from
> inside textmate.
>
>
> —Thomas Aylott – subtleGradient—
>
>
Hi Thomas, thanks for the tip - I just found it on the forum archives. I'm
just getting started with TextMate and the Transmit bundle was just what I
needed. I have a small problem with DockSend though. I'm using Transmit
3.6.2.
Let's say my Transmit is already connected to my server, and my "Their
Stuff" is at the root level on the server. When I use DockSend to upload a
file that's in a directory within the root, say an img directory, it uploads
the file, but after it does so, I can't navigate to the img directory nor
any other directory within root. I always get this message:
http://www.nabble.com/file/p16265488/24cxhcn.png
where the blurred out part is the directory name I'm trying to open.
The only way to get out of it is to navigate to a higher-level directory
using the dropdown that's above the "My Stuff" directory box or to
disconnect. Once I can get to the location of the file, however, I see that
it's uploaded. If I'm DockSending to the root (the current directory my
"Their Stuff" is in), I can navigate to any other directory just fine.
It doesn't seem to be TextMate-specific (if I drag a file to the Transmit
icon on the dock I get the same error), but I can't find any Transmit forums
nor can I find the problem when I search for it. So I'm hoping maybe
someone on here has had this problem too. Maybe it's an outlier bug, but I
often have my Transmit window open and would rather not have to deal with
this every time I DockSend a file!
Thanks,
Annie
--
View this message in context: http://www.nabble.com/Remote-editing-of-projects-tp15053548p16265488.html
Sent from the textmate users mailing list archive at Nabble.com.
I recently recognized, that the control + escape shortcut to envoke
the gear menu doesn't work. Now I searched the archives, and found
that this question has come up before.
The only answer was, that it could be that the keyboard shortcut is
already assigned in the system-preferences.
Looked there, and it sure isn't.
I even created a new user and tried there, but even there it doesn't
work. Is this a known bug? Or am I just missing something?
running latest Leopard.
Thanks,
Thomas
Does textmate have an equivalent to emacs query replace that takes
term to search for, what to replace it with and then steps through
each match and asks if you want to replace or not
( moving view obviously to that area so you can view the code around
it )
?
hi, first post to this forum, after switching from BBEdit to TextMate.
while I'm discovering everyday the benefit of this change, I came
across a syntax problem with a Applescript I was using successfully
with BBEdit.
the principle of the script was to create folders and sub-folders,
then create a new document in one of them with my text editor, save it
with a title, bringing it to the front for entry.
changing the app to TextMate, I get an error:
[quote] AppleEvent Handler failed: expect end of line but get "to" [/
quote]
I have posted an entry on MacScripter, to hear that TextMate was
"poorly scriptable, even Standard Suite is badly implemented".
any solution to contradict that?!
below the script in question:
> set theFolder to choose folder with prompt "Create/Choose Client
> Project folder"
> try
> set briefFolder to ((theFolder as text) & "Brief") as alias
> on error
> tell application "Finder" to set briefFolder to make new folder at
> theFolder with properties {name:"Brief"}
> end try
> tell application "Finder"
> set capturesFolder to make new folder at theFolder with properties
> {name:"Captures"}
> end tell
> tell application "TextMate" -- was BBEdit
> set briefDoc to make new document at beginning with properties
> {name:"$.tasks"} -- was "$.todo"
> save briefDoc to ((briefFolder as text) & "$.tasks")
> end tell
> tell application "TextMate" to activate -- was BBEdit
--
cheers, Pascal
Hi,
We have a big problem in our society.
We updated to Leopard 2 weeks ago. Since, we have a LOT of kernel
panics when using TextMate (1.5.7 1455). Just for yesterday, I got 5.
It happened every time saving a file from TextMate on servers
connected via SMB (Windows or Linux servers). But not each time. All
our macs under Leopard are affected (10.5.2). We're trying to solve
this problem over the past week without success (desactivate IPv6,
uninstall BlueHarvest,…).
The problem does'nt happen with programs like Coda or CSSEdit, and not
on Tiger + TextMate.
Someone would have an idea?
Thank you
Tue Mar 18 13:36:08 2008
panic(cpu 0 caller 0x001A8C8A): Kernel trap at 0x0105624a, type
14=page fault, registers:
CR0: 0x8001003b, CR2: 0x00000010, CR3: 0x01504000, CR4: 0x00000660
EAX: 0x00000800, EBX: 0x00000800, ECX: 0x00000f80, EDX: 0x00000000
CR2: 0x00000010, EBP: 0x34d33558, ESI: 0x00000000, EDI: 0x34d33780
EFL: 0x00010206, EIP: 0x0105624a, CS: 0x00000008, DS: 0x34d30010
Error code: 0x00000000
Backtrace, Format - Frame : Return Address (4 potential args on stack)
0x34d332a8 : 0x12b0e1 (0x457024 0x34d332dc 0x13321a 0x0)
0x34d332f8 : 0x1a8c8a (0x460550 0x105624a 0xe 0x45fd00)
0x34d333d8 : 0x19eb67 (0x34d333f0 0x34d33458 0x34d33558 0x105624a)
0x34d333e8 : 0x105624a (0xe 0x48 0x34d30010 0x1a0010)
0x34d33558 : 0x1058036 (0x78c1dd0 0x1 0x34d335c8 0x19d73a)
0x34d33578 : 0x1f1707 (0x34d3359c 0x0 0x34d335a8 0x1da8c3)
0x34d335c8 : 0x1f41dd (0x78c1dd0 0x34d33780 0xbd76484 0x385118)
0x34d33628 : 0x1db413 (0x78c1dd0 0x34d33780 0xbd76484 0x0)
0x34d338c8 : 0x356d8c (0x45ad550 0x0 0x80000002 0xbd76484)
0x34d33908 : 0x1d794d (0x45e5204 0x45ad550 0x80000002 0xbd76484)
0x34d33958 : 0x1c4d1a (0x78c1dd0 0x0 0x80000002 0xbd76484)
0x34d33f78 : 0x3dbe77 (0x4d8ea00 0xbd76380 0xbd763c4 0x13d1ed)
0x34d33fc8 : 0x19f084 (0xbd22240 0x0 0x1a20b5 0xbd22240)
No mapping exists for frame pointer
Backtrace terminated-invalid frame pointer 0xb045a2e8
Kernel loadable modules in backtrace (with dependencies):
com.apple.filesystems.smbfs(1.4.2)@0x1040000->0x106ffff
BSD process name corresponding to current thread: TextMate
Mac OS version:
9C31
Kernel version:
Darwin Kernel Version 9.2.0: Tue Feb 5 16:13:22 PST 2008;
root:xnu-1228.3.13~1/RELEASE_I386
System model name: iMac6,1 (Mac-F4218FC8)
I've got both a personal MacBook, and a work MacBook pro, each with
licensed copies of TextMate.
A few weeks back on my personal machine, I followed the instructions
here to get Textmate to detect files ending in _spec.rb as rspec, and
just .rb as Ruby on Rails:
http://blog.macromates.com/2007/file-type-detection-rspec-rails/
I've just now tried to do the same thing on the work machine, and
while it detects rspec, Normal .rb files are coming up as Ruby rather
than Ruby on Rails.
The Ruby On Rails language has
fileTypes= { 'rxml', 'rb'}
as per the blog post (Yes I realize as I type this I need to make it
work with Rails 2.0 conventions).
When went looking in the Ruby language def to delete the file type
association to 'rb', there doesn't seem to be one.
Any ideas?
--
Rick DeNatale
My blog on Ruby
http://talklikeaduck.denhaven2.com/
(forgive my noobishness, I had to re-join the list after a long period
of inattention, and cannot respond directly to the original message,
from Thomas Aylott)
> Those few of you who care, please let me know what I need to do
> before I can replace the core bundles with these guys.
I was really excited to see activity related to JavaScript in /Review,
and I immediately switched my checkouts to track the JavaScript and
Prototype bundles in Review. The irony of someone who follows the
commit log feed yet had to re-subscribe to the mailing list is
exquisite, I know.
I've been using them for the past few weeks with few (if any)
noticeable problems, using the Prototype bundle as my chosen grammar
for *.js. That is, until today, when I decided to go poking about the
latest Prototype trunk.
The file generated by `rake dist` has _never_ been small, I'll grant,
but I don't recall so much chugging and whinging by my 2.2Ghz MacBook,
or seconds-long gaps of white syntax colorless-ness when switching
tabs (a beachball will occasionally pop up for a few seconds, even).
My wild shot-in-the-dark hypothesis is that it might be related to the
increased number of `include $base` declarations in the "new" grammar.
To reiterate, this only occurs on files like the `rake dist`-generated
prototype.js, which itself is over 4,000 lines of syntactically dense,
idiomatic (and often beautiful) JS.
There seems to be a regression in the regex literal highlighting, as
it no longer works when the RegExp literal notation is used as a
member of an object with any space separating the key's colon
delimiter and the literal itself. The literals are colored fine when
it begins on the very first character of the line, or when immediately
following a parenthesis. Line 275+ of prototype/trunk/src/selector.js
is a perfect example of this regression.
I narrowed down the cause of this anomaly to the 'string.regexp.js'
key of the Embedded grammar, specifically the `begin` regexp:
(?<=[=(:]|^|return)\s*(/)(?![/*+{}?])
The lookbehind seems to be blocking it; when I remove it, the RegExp
literals in the object values highlight as intended. This does cause
any single `/` to color everything after it as a regexp, but adding an
alternate end-of-line anchor ($) to the negative lookahead seemed to
fix that. (?![/*+{}?]|$)
There is also an oddity with the folding markers, which appears to be
related to the block comment syntax. Line 135 of prototype/trunk/src/
ajax.js:
'Accept': 'text/javascript, text/html, application/xml, text/
xml, */*'
Again, inside an object literal, but this time the "*/*" seems to make
the folding parser think "I need to start a new fold here!", when in
fact it is the last member of the object, and should have no folding
marker whatsoever. Take away the second * (thus turning it into a
block comment closing delimiter), and the folding marker disappears. I
was unable to parse the gargantuan folding regexps in the grammar
clearly enough to suggest a solution.
> The Review Prototype bundle is NOT upgraded for the latest version
> of prototype.
I'd be willing to pitch in on this effort, if you (or whomever "owns"
the bundle) would like. I've done a bit of local hacking on various
bundles, and I can certainly provide examples off-list. The Prototype
grammar itself could use a little cleaning up, I'm sure.
Big thanks to all the bundle contributors for continuing to make
TextMate great! (Oh, and Allan, too :D)
~ Daniel Stockman
evocateur.org
