Hi there,
This is my first post to the list - many thanks to everyone on here
for making it such a valuable resource for a TextMate beginner!
If I am writing in a Markdown document and I want to save as a PDF,
it seems I have two options:
- Preview in textMate and then use the print dialog 'Save as PDF'
command
- Use the MultiMarkdown 'Convert to PDF' command to go directly to PDF
What control do I have over the format of the resulting PDF if I
generate it from the print dialog rather than the 'convert to PDF'
command? I like the 'out of the box' look of the print dialog PDF
better than the htmldoc-generated one, and wondered if I could do
anything to tweak, e.g. fonts, space after headings, list
indentation, etc.
If anyone knows of a good htmldoc intro document that is a little
friendlier than the manpage I'd be grateful too!!
Many thanks,
Nigel
Mike,
I'm trying to use wait, unwait, done & delegate actions, yet none of
them work. I type the shortcut letter such as 'w' and then press tab,
this merely replaces my task with a blank line.
Actually, I just tested manually choosing the action from the bundle
menu and it seems that the shortcuts work fine, it's the actions that
are not working. Choosing the action from the menu does the same thing.
Any info would be helpful.
Thanks
Mike
I'm currently testing out TextMate for doing some Ruby coding. It gets very high marks from the community at large and so far things have looked fairly good.
However, I ran into a bug and I need the list's help to solve it.
The code I'm writing and testing uses the plist gem [1] from rubyforge. Whenever I try to test code that uses any functionality from that gem, the test fails with the following error:
1) Error:
test_temp(TC_MyTest):
NameError: uninitialized constant Some::Plist
method some in temp.rb at line 12
method test_temp in tc_temp.rb at line 13
(where Some is a class I created for the purpose of trapping this bug.)
I searched for this problem and discovered another complaint about it back in July [2] along with a response [3]. The response wasn't very helpful for figuring out a workaround, so I thought I'd ask again.
How can I modify TextMate so it doesn't stomp on the ruby namespace for Plist? Alternately, how can I modify my ruby code to avoid the namespace collision? BTW, I have already "deleted" the Property List Macro Bundle from TextMate but that didn't appear to have any positive effect.
I've already tried different scoping shenanigans with modules and the :: scope operator, but it still blows up. Thanks for your help.
cr
[1] http://plist.rubyforge.org/
[2] http://article.gmane.org/gmane.editors.textmate.general/11813
[3] http://article.gmane.org/gmane.editors.textmate.general/11814
The firstLineMatch in the Mail bundle is '^From: (?=\w+(a)[\w-]+\.\w+)', which doesn't match addresses with names. For example, the first line of my emails is 'From: Grant Hollingworth <grant(a)antiflux.org>'.
I changed the match to '^From: .*(?=\w+(a)[\w-]+\.\w+)' (i.e., check for an email address somewhere on the line).
Hello,
while playing with the Saxon8-parser from M. Kay [ http://
www.saxonica.com ] i found myself typing a lot of <xsl:command
foo="bar"/> stuff producing lot's of typos and mixing up the syntax.
To simplify my life and to learn xslt2 i did these snippets. Almost
any xsl-instruction i found in M.Kay's documents is in the bundle -
these make up ~70 snippets. Some of them are chained-together, some
contain links M.Kay's documentation or the related W3C-docs. Some xsl
which u might find in the official-doc's are not 'visible' in the
bundle, because theses are only allowed as children inside another
instruction - that way the snippets might help to prevent errors. Any
'mandatory'-attribute=must have is in the snippets, characterized by
a fixed attribute-name and a placeholder for the value. Optional-atts
or sub-instructions show up as entire placeholders. Defaults are
always in first place, if a signature is provided with the placeholder.
This is not very much tested, yet. I'll continue to use and improve
it more and plan to make the xsl:functions also available - maybe
within a second bundle.
limitations : i left out one or two xsl:instructions which deal with
schema-processing and are not supported by the basic-version of
Saxon. Furthermore there is and probably will never be more
documentation than provided within this email-thread :-)
One question : I'd thought of auto-generation of snippets, as these
are simple .plist-files, i believe it to be possible to write a
stylesheet to process the html-Saxon-Doc's in order to retrieve the
info from the function-library, including all signatures. I've seen
that the plist-files contain a string-element like this :
<string>F631FE3C-7D78-4E2E-8A17-688E9890D0B6</string>
which looks like a 'unique'-(cocoa)-identifier. I have no idea what
to put into this and which consequences this might have ? any ideas
are truly welcome ;-)
have phun, andreas
--- XSL(v2) - bundle // v0.1 ---
Hello,
while playing with the Saxon8-parser from M. Kay [ http://
www.saxonica.com ] i found myself typing a lot of <xsl:command
foo="bar"/> stuff producing lot's of typos and mixing up the syntax.
To simplify my life and to learn xslt2 i did these snippets. Almost
any xsl-instruction i found in M.Kay's documents is in the bundle -
these make up ~70 snippets. Some of them are chained-together, some
contain links M.Kay's documentation or the related W3C-docs. Some xsl
which u might find in the official-doc's are not 'visible' in the
bundle, because theses are only allowed as children inside another
instruction - that way the snippets might help to prevent errors. Any
'mandatory-attribute'='must have' is in the snippets, characterized
by a fixed attribute-name and a placeholder only for the value.
Optional-atts or sub-instructions show up as entire placeholders.
Defaults are always in first place, if a signature is provided with
the placeholder.
This is not very much tested, yet. I'll continue to use and improve
it more and plan to make the xsl:functions also available - maybe
within a second bundle.
limitations : i left out one or two xsl:instructions which deal with
schema-processing and are not supported by the basic-(freely-avail.)
version of Saxon. Furthermore there is and probably will never be
more documentation than provided within this email-thread :-)
One question : I'd thought of auto-generation of snippets, as these
are simple .plist-files, i believe it to be possible to write a
stylesheet to process the html-Saxon-Doc's in order to transform the
info's from the function-library, including all signatures, into
snippets-files (plists). I've seen that these plist-files contain a
string-element like this :
<string>F631FE3C-7D78-4E2E-8A17-688E9890D0B6</string>
which looks like a 'unique'-(cocoa)-identifier. I have no idea what
to put into this and which consequences this might have ? any ideas
are truly welcome ;-)
have phun, andreas
--- XSL(v2) - bundle // v0.1 ---
PS: sending this for the second time, hope it will arrive only once.
i guess the mailer has eaten the unzipped bundle the first time i
send it ?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi,
I'm using the (newest) PHP-Package and I would like to color normal
comments other then phpdoc comments.
So I changed the PHP Language a bit to perform this. I replace the
normal comment.block.php with this one:
{ name = 'comment.block.php.phpdoc';
begin = '/\*\*';
end = '\*/';
patterns = (
{ name = 'keyword.other.phpdoc.php';
match = '\@(a(ccess|uthor)|c(ategory|
opyright)|global|li(cense|nk)|pa(ckage|ram)|return|s(ee|ince|tatic|
ubpackage)|t(hrows|odo)|v(ar|ersion))\b';
}
);
},
{ name = 'comment.block.php';
begin = '/\*';
end = '\*/';
},
So I have an own scope for the phpdoc comment. I also added @license
as phpdoc keyword. It would be nice if you could add this changes to
the official PHP-Package.
I also have another question: How can I activate the spell-check in
(PHP)comments. I tried to use a Preference Item and added
{ spellChecking = 1; } to it and set the scope to "comment" but it
didn't worked.
Do you have any ideas?
Thanks in advance,
Simon Ruderich
- ----
> privacy is necessary
> using http://gnupg.org
> public key id: 0x6115F804EFB33229 http://ruderich.com/
simonruderich.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
iD8DBQFFOQF2YRX4BO+zMikRCn6YAKDUCbqHUHmgkX8VMBag367nBI1wVgCfYqUF
sMHhifE1Hs9wR4Np6QP3Bhw=
=nHGU
-----END PGP SIGNATURE-----
Hi,
I just installed a new version of a bundle. TM asked me whether it
should be updated. I chose YES.
Well, the files within the bundle were updated but NOT the changed
code for commands!?
Can anyone verify this bug?
Cheers,
Hans
