Great beta 3 Allan !!!
In the last week I have been writing some postings on a private forum, which uses UBB code [b]bold text[/b] tags. As I prefer to work in a bigger text editor window and in larger text sizes, I create my post in TM, and then post it into the posting form.
While doing this, I am missing the "Insert Closing Tag" functionality of HTML, and started wondering about how I could extend it to handle the basic UBB tags as well. Unfortunately I didn't get very far as I can't really see the starting point. :(
Ideally it would be great to have a syntax .tmbundle that made [b]bold[/b] and so on. Anyone has any ideas or input to help with ??
Kind regards,
Mats
---- "TextMate, coding with an incredible sense of joy and ease" - www.macromates.com -
On Jan 25, 2005, at 12:14, Mats Persson wrote:
While doing this, I am missing the "Insert Closing Tag" functionality of HTML
I'm not too happy about having this hardcoded to SGML/XML either :/ when I wrote it, I couldn't find any real use cases outside HTML/XML, so I figured okay -- thanks for bringing UBB to my attention.
and started wondering about how I could extend it to handle the basic UBB tags as well. Unfortunately I didn't get very far as I can't really see the starting point. :(
When I do emacs marks it should be possible to do a naive version with a macro (search back, copy tag, back to mark, paste/modify). When I do full backwards searching for regular expressions, it should even be possible to do a version that accommodates nesting (and scripting support will be yet another solution).
But of course none of that helps you currently...
On Jan 25, 2005, at 12:14, Mats Persson wrote:
Well, my original e-mail didn't make it to the list, so I guess it got stuck in Allan's inbox : )
While doing this, I am missing the "Insert Closing Tag" functionality of HTML, and started wondering about how I could extend it to handle the basic UBB tags as well. Unfortunately I didn't get very far as I can't really see the starting point. :( Ideally it would be great to have a syntax .tmbundle that made [b]bold[/b] and so on. Anyone has any ideas or input to help with ??
OK, sometimes I just absolutely LOVE TM !!! The above problem was so easily solved with TM's Snippet functionality that I feel ashamed I didn't think about it earlier.
Bold Snippet: Code: [b]`echo $TM_SELECTED_TEXT`$0[/b] Key Equivelent: Cmd+B
replace the 'b' with 'i', 'u' and so on for all the others.
Time spent creating a working solution once I worked out how = 2 minutes !! Try to do that with any other code/text editor !! Is it even possible ??
On 25 Jan 2005, at 11:29, Allan Odgaard wrote:
When I do emacs marks it should be possible to do a naive version with a macro (search back, copy tag, back to mark, paste/modify). When I do full backwards searching for regular expressions, it should even be possible to do a version that accommodates nesting (and scripting support will be yet another solution).
But of course none of that helps you currently...
Well, you did by making TM such a wonderful app !!! When I get rich, I'll buy you a Ferrari ! :)
Kind regards,
Mats
---- "TextMate, coding with an incredible sense of joy and ease" - www.macromates.com -
According to Mats Persson:
minutes !! Try to do that with any other code/text editor !! Is it even possible ??
Everything is possible within emacs. I still use TM on my Mac, thanks :-)
On 25. jan 2005, at 14:54, Ollivier Robert wrote:
According to Mats Persson:
minutes !! Try to do that with any other code/text editor !! Is it even possible ??
Everything is possible within emacs. I still use TM on my Mac, thanks :-)
Yes... of course, since emacs has a complete language built in. In the future I would like to see a built-in language in TM also (although, please not Lisp.. and NOT AppleScript) :-).
On Jan 25, 2005, at 16:43, Sune Foldager wrote:
Yes... of course, since emacs has a complete language built in. In the future I would like to see a built-in language in TM also (although, please not Lisp.. and NOT AppleScript) :-).
Then we're left with Brainfuck! [1]
Btw: I saw questions about TM features in comp.editors.emacs! :)
On 25 Jan 2005, at 15:47, Allan Odgaard wrote:
On Jan 25, 2005, at 16:43, Sune Foldager wrote:
Yes... of course, since emacs has a complete language built in. In the future I would like to see a built-in language in TM also (although, please not Lisp.. and NOT AppleScript) :-).
Then we're left with Brainfuck! [1]
Ruby! Ruby!
d
On 25. jan 2005, at 16:57, David Casal wrote:
On 25 Jan 2005, at 15:47, Allan Odgaard wrote:
On Jan 25, 2005, at 16:43, Sune Foldager wrote:
Yes... of course, since emacs has a complete language built in. In the future I would like to see a built-in language in TM also (although, please not Lisp.. and NOT AppleScript) :-).
Then we're left with Brainfuck! [1]
Ruby! Ruby!
Yes Ruby... except Ruby's current interpretor is not very well-suited for imbedding. All the problems mod_ruby has and had is a good showcase for this. For one, there is no way to reset the intepretor. It's just not designed for embedding, but maybe Matz will get around to rewrite the interpretor (which is also written in a kinda old-fashioned C-style currently).
On 25 Jan 2005, at 16:44, Sune Foldager wrote:
On 25. jan 2005, at 16:57, David Casal wrote:
On 25 Jan 2005, at 15:47, Allan Odgaard wrote:
On Jan 25, 2005, at 16:43, Sune Foldager wrote:
Yes... of course, since emacs has a complete language built in. In the future I would like to see a built-in language in TM also (although, please not Lisp.. and NOT AppleScript) :-).
Then we're left with Brainfuck! [1]
Ruby! Ruby!
Yes Ruby... except Ruby's current interpretor is not very well-suited for imbedding. All the problems mod_ruby has and had is a good showcase for this. For one, there is no way to reset the intepretor. It's just not designed for embedding, but maybe Matz will get around to rewrite the interpretor (which is also written in a kinda old-fashioned C-style currently).
Python + PyObjC ?
-- Andre
On Tue, 25 Jan 2005 17:56:26 +0000, Andre wrote:
Python + PyObjC ?
why dont let it be like now? i think its one of the best things that you can write commands with whatever language you want atm. if there would only be one language textmate would be much less interesting for me.
an alternative to make more integration possible could be to implement a easy "command-line-protocol" which you can speak with every language wich can read and print text from the commandline. so you can use very much languages and do more fancy things. its just and idea but i wouldnt like it if textmate is just scriptable with one language.
On 25. jan 2005, at 19:13, Torsten Becker wrote:
On Tue, 25 Jan 2005 17:56:26 +0000, Andre wrote:
Python + PyObjC ?
why dont let it be like now? i think its one of the best things that you can write commands with whatever language you want atm. if there would only be one language textmate would be much less interesting for me.
Yes but the point is not to remove what is now. The point is that an intergrated language can do stuff which is impossible or at least very hard to do with external scripts, namely exposing editor functionality and allowing the scripts in a more real-time nature to control the editor. This is good for communicating with read-eval-print style interpreters and other things like that. That it will also enable you to turn the editor into a game and what not, is just a bonus.. or at least irrelevant at worse :p.
an alternative to make more integration possible could be to implement a easy "command-line-protocol" which you can speak with every language wich can read and print text from the commandline. so you can use very much languages and do more fancy things. its just and idea but i wouldnt like it if textmate is just scriptable with one language.
Yes, an interface like that could also be an idea.. again though, having the script run interatively in the background while talking to the editor and sending output to a window in it, might not be easy. An interpreter I use for a project is intergrated with emacs in that way, where the bottom part of the window is a buffer it uses for input and output and control.
On Jan 25, 2005, at 19:13, Torsten Becker wrote:
why dont let it be like now? i think its one of the best things that you can write commands with whatever language you want atm. if there would only be one language textmate would be much less interesting for me.
Well, no functionality will be removed, by the adding of a scripting language.
an alternative to make more integration possible could be to implement a easy "command-line-protocol" which you can speak with every language wich can read and print text from the commandline. so you can use very much languages and do more fancy things.
With the osascript command, an AppleScript hook sort of takes care of this.
There need to be some way to call TM actions, and I'm sorry to say so, but I think AS is the correct answer.
AS integrates with other applications which one may use in combination with TextMate, like Automator, Script Editor (recording scripts) etc. and it should have support for the platform specific “structures” like unicode strings, file objects, images etc.
Basically though, TM is not adding support for apple script, but apple events, and in theory, one could provide another scripting language with the inter-application communication capabilities which currently makes AS a prime candidate.
So providing TM with AS support does not take away the ability to write functionality in Ruby, but if that Ruby program wants to e.g. place the caret within TM, it'll need either to go through the osascript command, or someone should write an extension to Ruby which allows it to send apple events.
On Jan 25, 2005, at 19:28, Allan Odgaard wrote:
AS integrates with other applications which one may use in combination with TextMate, like Automator, Script Editor [...]
Also a point I forgot to mention, AS has been refined over many years to be an application extension language, this means it has stuff like event handlers, so not only can a script call TM, but a script can setup hooks for TM to call (at least to the best of my knowledge) -- the infrastructure for all this is already defined and partially implemented, TM only needs to make use of it.
There is no language I'm aware of which has similar capabilities, so I'd have to invent a lot myself, which is more work and a bad idea.
Now we also need a tty or something like that, to archive what emacs can do. I am not sure it's gonna be very easy with AS compared to a built-in language, since now you need to have a script running in a loop as well, keeping the necessary state-variables (i.e. pipes for the interpreter or similar), and talking to both TM and the interpreter.
On Jan 25, 2005, at 10:35 AM, Allan Odgaard wrote:
On Jan 25, 2005, at 19:28, Allan Odgaard wrote:
AS integrates with other applications which one may use in combination with TextMate, like Automator, Script Editor [...]
Also a point I forgot to mention, AS has been refined over many years to be an application extension language, this means it has stuff like event handlers, so not only can a script call TM, but a script can setup hooks for TM to call (at least to the best of my knowledge) -- the infrastructure for all this is already defined and partially implemented, TM only needs to make use of it.
There is no language I'm aware of which has similar capabilities, so I'd have to invent a lot myself, which is more work and a bad idea.
What capabilities are you referring to? I mean, there's no functional difference between:
(1) Ruby, invoked using rb_call, IIRC
def save_hook( path, encoding, etc ) end
(2) AppleScript, invoked as described at http://www.scifihifi.com/weblog/mac/Cocoa-AppleEvent-Handlers.html
on save_hook( path, encoding, etc ) end save
To be clear, I believe that AppleScript support is a useful and TextMate should have it. I suspect, however, that it might be ultimately orthogonal to the question of an embedded scripting language. AppleScript requires a lot of overhead to perform the simplest of tasks. AppleScript also does not provide much in the way of object-oriented language features. For just one example, one way to get wide-ranging SCM support might be to export a simple Ruby object:
module TextMate class VersionControlSystem def file_remote_status(paths*)... def file_editable?... def commit_files!(paths*)... ... end end
Then it would be possible for users to subclass this object to support the less-popular RCS systems -- Perforce, svk, darcs... This sort of thing would be downright painful to implement with AppleScript.
Chris
On Jan 25, 2005, at 20:44, Chris Thomas wrote:
AS integrates with other applications which one may use in combination with TextMate, like Automator, Script Editor [...]
Also a point I forgot to mention, AS has been refined over many years to be an application extension language, this means it has stuff like event handlers [...]
What capabilities are you referring to? I mean, there's no functional difference between: [...]
You're right. In my mind I had made this out to be much more than it actually is (a callable function).
So I partially take back the thing about AS being the answer. AS (or apple events) will definitely be the first thing used to expose the editor API, which should allow the editor API to be called in most scripting languages.
But for callbacks I'm not sure AS makes sense with the current anti-AS attitude of TextMate (and AS just being crappy for the things you'd normally do in a callback/user function).
I see a few possibilities:
One (easy to achieve) solution is to run a script using bash, as currently done with commands, but give it arguments and probably re-use the environment space for all callbacks made for/from the same buffer. This script could be written in whatever language the user desires and would use normal environment variables for state (across invocations), gets its argument as the script arguments, and use the osascript command if it needs to talk to the editor (or an AE extension/binding, as the RubyAEOSA Chris linked to).
I think this gives maximum flexibility -- it does have syntactic overhead when 1) investigating script arguments, 2) talking with the editor, and 3) needing to read/write persistent (i.e. across invocations) variables (and generally a sub-optimal solution for storing such info, since it needs to be serialized into environment variables). #1 and #3 also exists for CGI scripts.
The other extreme is to embed a scripting language interpreter into TextMate, extend this language so that it can communicate with TM (i.e. w/o going through osascript -- like e.g. exposing TM settings as an {associative array|map|dictionary|hash}, adding commands like move_caret etc.), and simply let callbacks be functions (written in this scripting language) -- TM could scan scripts for event handlers and automatically establish the callbacks when the script is somehow added to TM.
I do however prefer not to choose a specific language, which is why I currently do lean a bit toward the shell solution, which, despite the more verbose syntax for the 3 things mentioned, is probably easier for most to use, since they would not need to learn a new language (but could choose their own, exactly as with CGI/apache) -- and I guess one could create TextMate bindings for most languages, similar to what's currently done for Cocoa.
Another solution (which could simply be in addition to the shell solution) would be to have TM delegate all scripting stuff to a plugin, and the 'embedded language' would lie entirely in this plugin. That way it would appear as if the embedded language was Python, Ruby, etc. (and the user could select which plugin to handle the callback on a case-by-case basis (or plugins would automatically be chosen based on script extension)).
The problem with supporting several languages is that the editor API may have to be lowest denominator (i.e. procedural) -- but if OO is required I could probably make the API so that OO wrappers could be more or less auto-generated based on naming/arguments (probably at run-time by the script plugin).
hmm... I'll need to give this some more thoughts -- though this is not something I plan to do over the next weeks, so there's plenty of time, and I'm just thinking out loud here! :)
On 26 janv. 05, at 10:28, Ralph Pöllath wrote(in "TM & UBB code some questions"):
As much as I loathe AS as a language, I have to agree here. AS (or AE) would let TM integrate not only with scripts, but other apps in a standardized way.
Same here. As much as I'd love to use Ruby instead of AS, I think AS support is needed. I've not tried it yet, but the coming of Automator will give a plus to AS-ready apps, I guess.
Just my 2 cents.
-- Fred
On Jan 25, 2005, at 10:28 AM, Allan Odgaard wrote:
or someone should write an extension to Ruby which allows it to send apple events.
http://www.fobj.com/rubyaeosa/
Chris
On Jan 25, 2005, at 19:28, Allan Odgaard wrote:
There need to be some way to call TM actions, and I'm sorry to say so, but I think AS is the correct answer.
AS integrates with other applications which one may use in combination with TextMate, like Automator, Script Editor (recording scripts) etc. and it should have support for the platform specific “structures” like unicode strings, file objects, images etc.
Basically though, TM is not adding support for apple script, but apple events, and in theory, one could provide another scripting language with the inter-application communication capabilities which currently makes AS a prime candidate.
So providing TM with AS support does not take away the ability to write functionality in Ruby, but if that Ruby program wants to e.g. place the caret within TM, it'll need either to go through the osascript command, or someone should write an extension to Ruby which allows it to send apple events.
IMHO Support for AS is the only sensible thing to do. For Python, there already is an the Appscript module, see: http://www.pythonmac.org/wiki/AppscriptModule for more information and http://www.pythonmac.org/wiki/AppleScript for other options.
-- Fingertips - http://www.fngtps.com Firefox - Take back the web - http://getfirefox.com
On 26.01.2005, at 09:37, Thijs van der Vossen wrote:
IMHO Support for AS is the only sensible thing to do. For Python, there already is an the Appscript module, see: http://www.pythonmac.org/wiki/AppscriptModule for more information and http://www.pythonmac.org/wiki/AppleScript for other options.
As much as I loathe AS as a language, I have to agree here. AS (or AE) would let TM integrate not only with scripts, but other apps in a standardized way.
Has anyone ever looked closely at F-Script? Seems to be a framework providing a very low-cost (in terms of implementation) bridge between Cocoa and the smalltalkish F-Script language. So if Allan wanted, instead of specifying an editor API, he could probably expose the whole object graph to plugins written with F-Script. I guess it's not so different from PyObjC etc., but it does look elegant. http://www.fscript.org
Also, with a future TM supporting AS, there should be some clever things we could pull off with Tiger's Automator, right? Anyone? http://www.apple.com/macosx/tiger/automator.html
Back to work, -Ralph.
On Tue, 25 Jan 2005 16:47:25 +0100, Allan Odgaard wrote:
Then we're left with Brainfuck! [1]
hmm .. i dont like brainfuck .. whitespace (http://compsoc.dur.ac.uk/whitespace/) is probably more usefull, with this build in, the invisible-bundle whould address much more people. :D
-
Allan Odgaard -
Andre -
Chris Thomas -
David Casal -
Fred B. -
Mats Persson -
Ollivier Robert -
Ralph Pöllath -
Sune Foldager -
Thijs van der Vossen -
Torsten Becker