Ok, stupid question, but I can not remember how to define the pdflatex path in the shell preferences.
something like TM_FILEPATH = usr/local/tetex/..... or is it TM_LATEX_MASTER = usr/local/.....
Could someone please remind me. Thanks
On Mar 15, 2005, at 4:36, Mr. Robert Ullrey wrote:
Ok, stupid question, but I can not remember how to define the pdflatex path in the shell preferences.
There are two variables you should set to fix the path problem: SHLVL=1 BASH_ENV=/etc/profile
The former is a workaround for a bug in bash and the latter sets which file bash should read before executing commands from within TextMate. Both of these variables are set like this by default in beta 5, but if you've made changes to the shell variables prior to beta 5, you won't get the defaults.
I have changed it for beta 6 so that 1) these variables are always set, even if you do not set them in the preferences and 2) BASH_ENV is set to a bash_init.sh script located in the TextMate bundle which does: [ -f /etc/profile ] && . /etc/profile [ -f ~/.bash_profile ] && . ~/.bash_profile
This should hopefully solve all future path problems, since by default this will then give TM the same path as when running a normal interactive shell.
But for now, just set the BASH_ENV and SHVL variables.
I heard somewhere the next release will overhaul the syntax highlighting engine.
Is there a description of the changes / new approach anywhere ?
Having spent a couple of hours yesterday tweaking colours in various bundles I'm somewhat curious
Cheers
D
On Mar 16, 2005, at 0:59, David Lee wrote:
Please compose a new letter when starting a new thread, for more info see item 2 here: http://linux.sgms-centre.com/misc/netiquette.php
I heard somewhere the next release will overhaul the syntax highlighting engine.
Is there a description of the changes / new approach anywhere ?
Only loose comments made by me, so to sum it up:
In parsing: Full recursion is supported, so e.g. interpolated code in strings work etc. Back-references in end pattern, so e.g. heredocs are possible (at least when they are not nested) Zero-width matches supported, rarely needed, but required for some stuff The \n at the end of a line can be included in a match, this is mostly useful for styling (to make a background color change extend to the right border) Captures can be named (this is important for the next part)
In styling: Styles are associated to a match using the name/prefix of the rule, optionally preceding it with the name/prefix of parent language rules for context, example: strings -- match all strings strings.double-quoted -- match all double-quoted strings source.php strings -- match only strings with a parent element named source.php (i.e. strings in php sources)
Basically this is the same as you do with CSS selectors. But I will allow for more than just visual styles, e.g. disable ' as a smart typing character in text.html but enable it again for markup.tags, or disable continuous spell checking for source but enable it again for source strings, source comments etc.
This same system is also what you will be able to fill in to the scope string in the bundle editor. That means that only in that scope, will the activation method be functional. So the most obvious is to limit snippets to their respective source, but we can also do much fancier stuff such as overload the behavior of return, but limited to e.g. strings -- this has great potential.
But all in all, the old syntax files are compatible -- there'll just be slightly more flexibility in the definition, and I'll ignore the styles embedded in these files, since that will instead be applied using style sheets -- but it should be relatively easy to extract the styles from a given syntax file and create the corresponding style sheet.
On Mar 16, 2005, at 1:53, Allan Odgaard wrote:
Is there a description of the changes / new approach anywhere ?
Only loose comments made by me, so to sum it up:
In parsing: [...]
Something I didn't mention but which is also a nice enhancement is that parsing is now done in a separate thread. Previously parsing was done lazy using a cache. This meant that e.g. scrolling to the bottom of a large source (for the first time) would cause a delay (depending on your machine of course), and the same when pasting a huge block of code (since that new block would then need to be parsed before it could be rendered).
Since parsing is now done in a separate thread, it will just display the text w/o styles if parsing hasn't completed the requested block, though since it's no longer lazy, the data should be available most of the time.
Though the bottleneck in TextMate remains the folding patterns, which are currently not handled by this new system, but I'm looking into how I can have it done :)
On 16-03-2005 02:26, Allan Odgaard wrote:
Since parsing is now done in a separate thread, it will just display the text w/o styles if parsing hasn't completed the requested block, though since it's no longer lazy, the data should be available most of the time.
Though the bottleneck in TextMate remains the folding patterns, which are currently not handled by this new system, but I'm looking into how I can have it done :)
Good to see that there's some performance tuning so TM can work better with large files.
However, since I've checkout the whole tree of bundles from the repository, it takes TM noticably longer to start up. I'm guessing this is because of all the bundles I have enabled, although I haven't tested this. Are there any plans to do some optimisation there as well? (e.g. read bundles as they are needed and do the rest lazy? This has the downside that not all commands are available immediately, but if you really need commands and use them outside the bundle, you should perhaps move them to a personal bundle or the default bundle?)
Jeroen.
On Mar 16, 2005, at 9:30, Jeroen van der Ham wrote:
However, since I've checkout the whole tree of bundles from the repository, it takes TM noticably longer to start up. I'm guessing this is because of all the bundles I have enabled, although I haven't tested this.
It is -- on that note, if you do checkout all the bundles from the repository, delete what's found in TextMate.app/Contents/SharedSupport, that will at least cut down some of the initial loading time.
Are there any plans to do some optimisation there as well?
Indeed there is :) Naturally I want TextMate to startup instantly, even when the user has a dozen bundles -- the problem with loading the bundles lazy is that I really need to know which syntax files are available before I can show a file, and as soon as you edit, I also need to know what key bindings are used by bundle items.
What I can do is load bundles in a separate thread, and just show whatever file(s) get loaded without styles until a style becomes available -- but since such optimizations are rather complex, it's not something I'm venturing into until the code involved is really set in stone.
********************************************************************* Quoting Allan Odgaard on [Wednesday, March 16, 2005, +0100]
There are two variables you should set to fix the path problem: SHLVL=1 BASH_ENV=/etc/profile
Thanks Allan. That of course did the trick. It was the BASH_ENV that I had forgotten.
cheers
-
Allan Odgaard -
David Lee -
Jeroen van der Ham -
Mr. Robert Ullrey