El 07/02/2007, a las 2:00, Charilaos Skiadas escribió:

On Feb 6, 2007, at 6:54 PM, Juan wrote:

...

I use a lot a command that I call "quickSearch" that look for the next text equal that the one that is selected. It is very useful since you can find quickly var declarations, etc. only selecting the word (you'll need only the keyboard!) and press, for exmple Shift-Ctrl-Opt- -> or Shift-Ctrl-Opt- <- (arrow keys) for quickSearchBackward. The only way I've found is building the macro:

copySelectionToFindPboard: findForward:

or the analogous for findPrevious:

The problem is with this simple action I destroy the FindPboard and this is an unnecessary, I think, colateral effect.

...

Have s/o solve this not destroying the FindPboard?

Thanks, as you say it does no destroy the FindPboard. That seems to mean that "Use local clipboard while executing macro" also includes that special paste-board.

In the bundle editor if you open a macro, there is a little checkbox called "Use local clipboard while executing macro". I think if you use that the pasteboard contents should not be affected. TM saves the pasteboard contents before executing macros/ commands, and reinstates the pasteboard to its previous state when it's done.

This checkbox is in fact by default on, so theoretically your macro should not be destroying the findPboard. In fact I just tried it with such a macro and it worked just fine, the Pboard got unaffected. (Btw, you perhaps meant findNext: instead of findForward: ? I don't know how to produce findForward:, or if there is a difference between the two).

(I assume of course you created the macro by recording the keystrokes cmd-E and cmd-G).

...

Another:

I love to reread the last closed file in a time sorted (stacked) way: last closed file, first one to open. This also allows me to open several files (and close) them quickly.

I used to use Ctrl-Opt-O for that process in AlphaX. I can't find the way for doing this with TM. I think you should save in a file the history of open files, or so... TM haven't memory variables, in any way. Alpha has an embedded interpreter inside it and then read many many procs and variables at start and is easy to refer to them and also has open-hook and close-hook procs that make this stack very easy.

Any idea?

You might want to file a feature request if there isn't one yet: http://macromates.com/ticket/

I have many many lines of code for to introduce in TM, but I am worried about the fact that many of them will be impossible since TM does not preserve states and always depends on external commands and not have an internal interpreter. This is a very deep limitation, you must agree with me.

El 07/02/2007, a las 21:45, Charilaos Skiadas escribió:

On Feb 7, 2007, at 2:47 PM, Juan wrote:

...

I have many many lines of code for to introduce in TM, but I am worried about the fact that many of them will be impossible since TM does not preserve states and always depends on external commands and not have an internal interpreter. This is a very deep limitation, you must agree with me.

No sorry, I don't. Partly because I don't understand exactly what you mean by built-in interpreter, and partly because I have found TM very extensible in many ways and there are very few things that find it limiting in. Using external commands has worked great for me because I can code in whatever scripting language I like, rather than be forced to use whatever language the author decided to have the built-in interpreter in. That's one of the reasons I gave up on emacs.

I have been working with an editor with built interpreter for more than ten years. I understand what you say about Emacs, Stallman decision was really argued over. I don't know about anyone that uses elisp, for any other thing than make emacs to work. I think you, like me, like better and modern languages. No doubt exist about which ones are the best, perhaps the order may change, but all of this have clear syntax and power regexps managing:

ruby, tcl, python, etc.

the one selected for being embedded in an editor is not important as far as the fact of having any one in it.

Its not true that having an interpreter embedded avoid the using of AppleScript, or any other scripting languages. That hasn't to do with that fact. You always can do "system(args)" with any scripting language calling any other with args.

Although I have been working deeply with Tcl and Perl, I recognize I fallen in love with Ruby as soon as I have try it.

I think however that there are a lot of things that can be done with TM as it is, and if there is something you think can't be done, then ask the list and perhaps we'll have some ideas about how to do it. If it really can't be done with things as is, and you have a good case for the need for this feature, then your feature request might make it into TM releases sooner than not.

Of course, I recognize TM has inside very clever design and more important, it is really MacOS friendly and it is very well integrated in the system exploiting everything in the system and using the cleverly the most important frameworks.

But ¡there are so many things that depends on having an EI, embedded interpreter, that the extensibility of TM is braked and will need a lot of extra efforts for reaching the half of the goals.

The examples I gave to you were only a few and can grow fast. There are many others. Things like Menu control (building them, etc), open/ close hooks (procs that must be called when anything open or closes), Access to the document: position, selecting parts of it, changing the insertion point position!!, are all of them impossible with the TM model except that in future versions TM hard-coded them and gives us direct access by new tricky interface gadgeds.

The most simple thing, like the building of a list of open windows inside your external scripting language is near impossible. You should resort to applescripting or so to ask TM for this, if possible.

TM needs an internal well organized dictionary of methods for accessing its state and an internal language for building in-memory structures. These both things doesn't have anything to do with the external scripting calling ability. Is my opinion.

-- Juan Falgueras

On Feb 7, 2007, at 6:11 PM, Juan wrote:

Things like Menu control (building them, etc),

Not sure what menus you are referring to, but tm_dialog allows commands to do a lot of things.

open/close hooks (procs that must be called when anything open or closes),

Make a feature request, with some examples of why this is needed. I've never felt the need for it. You can of course create commands that overwrite the cmd-S or cmd-W functionality and do whatever you want them to, for at least those cases of "closing".

Access to the document: position,

Can do with TextMate's dynamic environment variables: http:// macromates.com/textmate/manual/environment_variables

selecting parts of it,

A macro using Find or other ways of selecting could do this, depending on what you wanted to do.

changing the insertion point position!!,

Again you can use a Macro, or use the txmt:// scheme in a Command, or (last resort) use a command that replaces the entire document with a snippet, placing $0 at the location you want the caret to go.

I would venture to guess that adding an embedded interpreter would require a major overhaul of TM, and given that Allan hasn't done such a thing already I would guess that he does not consider it important enough.

TextMate is different than other editors, and I have often found that it helps to learn to do things "the TM way", rather than fighting with TM to make it see things your way. Just my opinion.

Haris

Juan writes, about a 'built-in interpreter':

I have been working with an editor with built[-in] interpreter for more than ten years. I understand what you say about Emacs [...]

Of course, I recognize TM has inside very clever design and more important, it is really MacOS friendly and it is very well integrated in the system exploiting everything in the system and using the cleverly the most important frameworks.

But ¡there are so many things that depends on having an EI, embedded interpreter, that the extensibility of TM is braked and will need a lot of extra efforts for reaching the half of the goals.

The examples I gave to you were only a few and can grow fast. There are many others [...] all of them impossible with the TM model except that in future versions TM hard-coded them and gives us direct access by new tricky interface gadge[t]s.

TM needs an internal well organized dictionary of methods for accessing its state and an internal language for building in-memory structures. These both things doesn't have anything to do with the external scripting calling ability. Is my opinion.

The thing is, I find the types of interactions supported by TextMate's "tricky interface gadgets" much more useful than the complex and varied interactions commonly used in editors such as emacs which allow in theory any behavior whatsoever.

While it is undoubtedly true that what you call "embedded" scripting is very powerful, and enables a user to do things otherwise impossible, the other result is that each user ends up re-inventing these interactions for themselves. And in the end, every language mode has a completely different style of interaction, which must be learned separately. These language modes are extremely difficult for regular users to modify or extend, because each one has its own architecture. To create their own modes, users need to have a deep understanding of the editor's metaphors and API. And interactions are brittle; small changes can break functionality in confusing ways.

TextMate has a different model. Instead of giving users a single entry point to customization in the form of a scripting language with a large API, Allan has taken a hard look at the types of editing patterns common to many languages, and designed flexible systems for *easily* building up functionality to meet those needs.

A simple TextMate language grammar, with far more granular control than any other editor I've seen, can be created in the course of an afternoon by a complete newcomer, with a tiny bit of help from a more experienced user. Snippets and macros which are immediately useful can be created by anyone who spends the 20 minutes to read the relevant sections of the manual. In the end, a bundle contains several discrete parts, which can be reused easily in different contexts, which can be changed independently of one another, and which are very transparent for even users unfamiliar with TextMate.

So, while I think TextMate will likely eventually get some more hooks for commands (or whatever structures Allan provides in the future) to interact with the application--something akin to the embedded interpreter you're talking about, though hopefully not tied to any specific language--until that day, we still have what I consider the most capable text editor.

I suppose what I'm trying to say is: take a look at the screencasts, try out the existing bundles, read the TextMate manual, and learn about the capabilities which are already available, before complaining about interactions which aren't yet possible. With a month or two of solid TextMate experience, I imagine your approach to solving your eding problems will have changed somewhat to align with TextMate's mechanisms. You might surprise yourself, and find that what exists is more powerful than what you think you want now.

If you have specific use cases, people on this list or in the IRC channel will be happy to discuss possible methods for accomplishing what you want. If there are new types of automation that would be a significant aid to a large number of users, I'm sure Allan wants to hear about it.

* * *

All that said, I myself am with you: we users and bundle developers will always be happy for *more* power. So I can't wait to see what Allan cooks up for TextMate 2.

Cheers, Jacob

On Feb 11, 2007, at 12:43 PM, Allan Odgaard wrote:

On 7. Feb 2007, at 00:54, Juan wrote:

...

I love to reread the last closed file in a time sorted (stacked) way: last closed file, first one to open. This also allows me to open several files (and close) them quickly.

If you are in a project, you can use ⌘T + ↩ to re-open the last closed file.

FWIW, this appears to work only if the file was closed by using &#x2318;W or clicking the "X" in the active tab. If you close a file by clicking the "X" in an inactive tab, then hit &#x2318;T, you don't get the file you just closed, you get the last file that was closed using one of the aforementioned methods...

-dan