There has been some talk in the past about TextMate's undesired tendency to use a software generated bold for the Bitstream Vera Sans Mono font.
One fix seems to be to run:
sudo rm -rf /Library/Caches/com.apple.ATS
Afterwards one will have to reboot the machine, but then the bold shows up as drawn. And what a difference it makes:
Though I don't know for how long this fix will work. And it will still look incorrect when the bold text is light on a dark background.
Good to know. I may have een the first to bring this up, many months ago, and I do use light text on dark, but I've managed to scrape by by simply having two slightly different versions of the base font (one in which I edited the name of Roman to Regular or somesuch) which I swap as VeraMono.ttf and VeraMono.ttf2. It doesn't matter which is which, I just periodically (about once/reboot, though not quite always, I believe) swap them when I notice the problem. Thankfully Quicksilver makes this easy enough I haven't ever even gotten around to automating it. I'd still, of course, love to see a real fix in or around whichever of Apple's subsystems is causing this problem. -jrk
On 2/1/06, Allan Odgaard throw-away-1@macromates.com wrote:
There has been some talk in the past about TextMate's undesired tendency to use a software generated bold for the Bitstream Vera Sans Mono font.
One fix seems to be to run:
sudo rm -rf /Library/Caches/com.apple.ATSAfterwards one will have to reboot the machine, but then the bold shows up as drawn. And what a difference it makes:
Though I don't know for how long this fix will work. And it will still look incorrect when the bold text is light on a dark background.
For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate
On 2/2/2006, at 15:09, Jonathan Ragan-Kelley wrote:
Good to know. I may have een the first to bring this up, many months ago, and I do use light text on dark, but I've managed to scrape by by simply having two slightly different versions of the base font (one in which I edited the name of Roman to Regular or somesuch) which I swap as VeraMono.ttf and VeraMono.ttf2. It doesn't matter which is which, I just periodically (about once/reboot, though not quite always, I believe) swap them when I notice the problem [...]
For me, if I do something with the font (e.g. gzip + gunzip) then it does fix the problem, but all glyphs which hadn't been loaded from the font at that time, will then show as blank for the rest of the session (i.e. until reboot).
On 02/02/2006, at 17:15, Allan Odgaard wrote:
For me, if I do something with the font (e.g. gzip + gunzip) then it does fix the problem, but all glyphs which hadn't been loaded from the font at that time, will then show as blank for the rest of the session (i.e. until reboot).
For me, it starts like that.. then it gets worse, last time ending by bringing the system down. Quite weird, actually.
-- Sune.
Hello,
Is it possible that I can SEE what source code line has changes since my last save? From the moment I type something on a line, it should TAG that line as "Changed". Maybe change the background color of the line number?
If the file is saved, the "Changed line" tag can be reset. -- Sincerely,
Patrick Mast, xHarbour.com Inc. http://www.xHarbour.com
On Feb 8, 2006, at 8:36 AM, Patrick Mast wrote:
Hello,
Is it possible that I can SEE what source code line has changes since my last save? From the moment I type something on a line, it should TAG that line as "Changed". Maybe change the background color of the line number?
Have you looked into the diff bundle? There is a command there to diff with the saved copy of the current file. I think it will sort of do what you want it to.
If the file is saved, the "Changed line" tag can be reset.
Sincerely,
Patrick Mast, xHarbour.com Inc. http://www.xHarbour.com
Haris
Hello,
Is it possible that I can SEE what source code line has changes since my last save? From the moment I type something on a line, it should TAG that line as "Changed". Maybe change the background color of the line number?
Have you looked into the diff bundle? There is a command there to diff with the saved copy of the current file. I think it will sort of do what you want it to.
I can see it in the Bundle Window yes. What should I do with it? Copy it to my personalized bundle? Or just pieces of it? -- Sincerely,
Patrick Mast, xHarbour.com Inc. http://www.xHarbour.com
On Feb 8, 2006, at 9:13 AM, Patrick Mast wrote:
Hello,
I can see it in the Bundle Window yes. What should I do with it? Copy it to my personalized bundle?
no, you should just run it. Open a file you are familiar with, then make some changes to it, don't save, and then run this command. It will open a new window showing you what the changes in the new document relative to the old document are.
This is maybe not exactly what you want, but hopefully it is close enough. I think it would be extremely difficult to highlight in the current document things that have changed. For instance, what should happen to to deleted parts? How would they be highlighted?
Sincerely,
Patrick Mast, xHarbour.com Inc. http://www.xHarbour.com
Haris
Hello,
I can see it in the Bundle Window yes. What should I do with it? Copy it to my personalized bundle?
no, you should just run it. Open a file you are familiar with, then make some changes to it, don't save, and then run this command. It will open a new window showing you what the changes in the new document relative to the old document are.
No, this is not what I want. I want it to be LIVE, IN the window where I'm working.
This is maybe not exactly what you want, but hopefully it is close enough. I think it would be extremely difficult to highlight in the current document things that have changed. For instance, what should happen to to deleted parts? How would they be highlighted?
A deleted LINE can not be tagged as "changed". If you delete a PART of the line, it should be tagged as changed.
I have a DOS (Windows console mode) editor of 1980 and THEY can do it, so, now in 2006 with OSX, I'm sure it's possible ;-)
-- Sincerely,
Patrick Mast, xHarbour.com Inc. http://www.xHarbour.com
On Feb 8, 2006, at 10:44 AM, Patrick Mast wrote:
I have a DOS (Windows console mode) editor of 1980 and THEY can do it, so, now in 2006 with OSX, I'm sure it's possible ;-)
It is theoretically possible of course to write an editor that does this. None of the editors I have seen currently does it. ASAIK TextMate does not do this, and the current Bundles support does not allow anything like that, so it is something that noone but allan can do anything about. You can always ask it as a feature request, but I am not sure how high in the priority list it would be. Allan has a number of high-priority tasks on the list atm.
But I am curious, how do you find this more useful than the diff functionality? I've never seen any editor do that, and I can't personally think of many use cases, nor have I seen anyone else ask this before. What specifically would you use this for, that the diff functionality is inconvenient for? Maybe we could suggest some other ways of approaching it.
-- Sincerely,
Patrick Mast, xHarbour.com Inc. http://www.xHarbour.com
Haris
Am 08.02.2006 um 18:06 schrieb Charilaos Skiadas:
But I am curious, how do you find this more useful than the diff functionality? I've never seen any editor do that, and I can't personally think of many use cases, nor have I seen anyone else ask this before. What specifically would you use this for, that the diff functionality is inconvenient for? Maybe we could suggest some other ways of approaching it.
subethaedit does something like this. its part of the collaboration- functionality but you can enable this in single-user-mode (no pun intended) as well. i really like that feature too because this way you can see the three, four places you changed a file. just have a look.
btw i like SEEs other collaboration-features as well but in my daily work i hardly ever used them and the editing features of TM seemed so much more usefull so i bought TM.
niko.
On Feb 8, 2006, at 12:06 PM, Charilaos Skiadas wrote:
But I am curious, how do you find this more useful than the diff functionality? I've never seen any editor do that, and I can't personally think of many use cases, nor have I seen anyone else ask this before. What specifically would you use this for, that the diff functionality is inconvenient for? Maybe we could suggest some other ways of approaching it.
I hadn't thought of it, but I would actually find this useful, FWIW. It's nice to be able to see what I've changed, especially if I have to walk away to do something else for a while.
How long would the highlight persist? Just to the next save, or would it only go away on closing the file?
Chris
On Feb 8, 2006, at 9:06 AM, Charilaos Skiadas wrote:
But I am curious, how do you find this more useful than the diff functionality? I've never seen any editor do that, and I can't personally think of many use cases, nor have I seen anyone else ask this before.
I think it would be quite nice. For instance, I would like to see the TextMate line numbers become bold (or highlighted or something similar) whenever a line changes. Their state would then be reset whenever a file is saved. It would be like having a more fine-grained version of the "file changed" icon in the file's tab. That is, the icon lets you easily see whether the file has changed, and the line numbers would show where the file has changed.
As for a use case, sure, you could use the diff feature for finding changes, but that's not the same thing. Diff is not real-time; it requires you to open up a new window every time a change is made. Patrick's idea would be much more convenient for when you're making many small changes to a large file and simply want help tracking the changes you've made. (In a way, it's kind of like the highlighting of the current line. Not truly necessary, just a nice convenience.)
Trevor
subethaedit has "go next/last change"-commands... nice!
On 8/2/2006, at 18:06, Charilaos Skiadas wrote:
[...] You can always ask it as a feature request, but I am not sure how high in the priority list it would be.
It has actually been requested a few times before. E.g. from http:// macromates.com/wiki/Suggestions/TextEditing
A useful feature I’d love to see (taken from SubEthaEdit) would be the ability to toggle show(highlight)/hide changes. I love to be able to look at a section of code and see where I’ve made changes during a session of editing.
> It’s however non-trivial to add, but 1.3 or later will introduce dynamic scopes where I also plan to allow them to markup things like this. — Allan Odgaard
Dynamic scopes will be awesome, but are currently in the distant future. I will not implement the highlighting of changes as a “standalone feature”.
Allan,
[...] You can always ask it as a feature request, but I am not sure how high in the priority list it would be.
It has actually been requested a few times before. E.g. from http:// macromates.com/wiki/Suggestions/TextEditing
A useful feature I’d love to see (taken from SubEthaEdit) would be the ability to toggle show(highlight)/hide changes. I love to be able to look at a section of code and see where I’ve made changes during a session of editing.
It’s however non-trivial to add, but 1.3 or later will introduce
dynamic scopes where I also plan to allow them to markup things like this. — Allan OdgaardDynamic scopes will be awesome, but are currently in the distant future. I will not implement the highlighting of changes as a “standalone feature”.
Ok, good to know it WILL be available at one time.
What exactly is "Dynamic scopes"?
-- Sincerely,
Patrick Mast, xHarbour.com Inc. http://www.xHarbour.com
On 9/2/2006, at 7:17, Patrick Mast wrote:
[...] Ok, good to know it WILL be available at one time.
Don't put too much in “plan to allow them to markup things like this”. With the current storage back-end, I don't think it's feasible to have meta-data like “this has been changed”. But I have some other plans in that respect.
What exactly is "Dynamic scopes"?
Currently only the language grammar will assign scope names to the text.
With dynamic scopes TextMate can assign additional names like dyn.current-word (the word the caret is on), dyn.placeholder (for a snippet placeholder) and similar to text fragments (and update accordingly as the user moves the caret, and mutates the text).
This will mainly allow styling of many things which are currently not styled (like e.g. column typing), including things like not having the invalid.illegal take effect for what the caret is at (using a scope selector of e.g.: “invalid.illegal - dyn.current-word”).
It should also allow for more sophisticated behavior, for example smart-typing should be disabled when we have a snippet placeholder fully selected (as that would wrap the placeholder text, which is generally the default value that we want to overwrite), and similar situations where the context which invite something to act slightly different than usual, is not extractable alone by parsing the text (via the language grammar).
So shortly put: dynamic scopes are a way for TextMate to expose various context dependent state variables in a way that should allow bundle items to use them.
Allan Odgaard wrote:
So shortly put: dynamic scopes are a way for TextMate to expose various context dependent state variables in a way that should allow bundle items to use them.
Do I understand correctly that this would allow me to highlight local variables differently than global ones, for languages where one or the other must be explicitly declared? That would be very welcome.
Regards, Christopher
On 16/2/2006, at 10:20, Christopher Creutzig wrote:
So shortly put: dynamic scopes are a way for TextMate to expose various context dependent state variables in a way that should allow bundle items to use them.
Do I understand correctly that this would allow me to highlight local variables differently than global ones, for languages where one or the other must be explicitly declared? That would be very welcome.
By “state variables” I refer to the internal variables of TextMate which describe state. For example the TextMate source might have a variable which tell whether or not the caret is inside a snippet placeholder.
So it has nothing to do with variables declared in your source code.
Allan Odgaard wrote:
On 16/2/2006, at 10:20, Christopher Creutzig wrote:
Do I understand correctly that this would allow me to highlight local variables differently than global ones, for languages where one or the other must be explicitly declared? That would be very welcome.
By “state variables” I refer to the internal variables of TextMate which describe state. For example the TextMate source might have a variable which tell whether or not the caret is inside a snippet placeholder.
So it has nothing to do with variables declared in your source code.
I didn't mean “state variables” to refer to variables in my code, I just had the impression that you meant more flexibility in what bundles can set state-dependently. Is what I described above already possible in TM? (I haven't seen a reasonable way yet.) If not, do you already have something on your todo-list that will allow such things? If not, ... well, I'd like to propose it. It would certainly be good to make typos and global variables stand out clearly, imho.
Best regards, Christopher
On 19/2/2006, at 19:48, Christopher Creutzig wrote:
[...] well, I'd like to propose it. It would certainly be good to make typos and global variables stand out clearly, imho.
Is your proposal that TextMate parse your language in the background, and based on that, expose as dynamic scopes where in the source there is an error, which parts are e.g. local variables (for languages which do not require any syntax like $variable), etc.?
While dynamic scopes could allow for some third party plug-in to provide scope names, I am unlikely to venture into the field of incremental parsers for the dozen of languages supported by TextMate ;)
Allan Odgaard wrote:
Is your proposal that TextMate parse your language in the background,
It does that already. At least, I can ask it to, using scopes and indentation rules. Obviously, I have no idea how the internal structures of TM work, so my suggestions may be extremely strange, but I could imagine something like
{ begin = '\bproc\s*('; end = 'end_proc'; { match = '^\s*local\s+(?:(\w+),\s*)*(\w+)\s*;'; captures = { 1 = { name = 'variable.other.foo'; }; 2 = { name = 'variable.other.foo'; }; } } { match = '(\b\w+\b)'; captures = { 1 = { inheritName = 'variable.other.foo'; }; } } ... }
(A real world pattern would probably look a bit more complicated.)
I'm not sure if the above syntax is all that desirable, but in my opinion the effect certainly is, namely, to *locally* change the scoping rules (probably best limited to what scope is actually assigned) based on the text edited. If a ruby method uses a variable only once and that variable is not known from an outer block, it would-be-nice[tm] to have it stick out visually, since it is likely a typo.
While dynamic scopes could allow for some third party plug-in to provide scope names, I am unlikely to venture into the field of incremental parsers for the dozen of languages supported by TextMate ;)
I'd certainly cry out loudly if you announced such plans. ;)
Best regards, Christopher
On Feb 8, 2006, at 3:48 PM, Allan Odgaard wrote:
Dynamic scopes will be awesome, but are currently in the distant future. I will not implement the highlighting of changes as a “standalone feature”.
I'm a little confused; are you saying that in the future a Bundle can be written to implement highlighting of changed lines?
Also, will this hypothetical Bundle (or any Bundle, for that matter) be able to modify TextMate's "gutter" in which line numbers are shown? I would much prefer to see changes marked in the gutter rather than simply highlighted in the text background.
Some kind of official interface for augmenting TextMate's gutter would be useful for other features, too. For instance, Xcode has an interesting feature that marks build errors and warnings in its gutter and its scroll bar [1]. It would be cool if a Bundle could be written to do the same thing in TextMate.
Trevor
[1] http://developer.apple.com/documentation/DeveloperTools/ Conceptual/XcodeUserGuide/Contents/Resources/en.lproj/Art/ errorinprojwindow.gif
On 9/2/2006, at 19:23, Trevor Harmon wrote:
Dynamic scopes will be awesome, but are currently in the distant future. I will not implement the highlighting of changes as a “standalone feature”.
I'm a little confused; are you saying that in the future a Bundle can be written to implement highlighting of changed lines?
No, a new entry in Preferences -> Fonts & Colors will be able to style e.g.: “dyn.changed-since-save.inserted” to target all insertions done since last save, or similar.
[...] Some kind of official interface for augmenting TextMate's gutter would be useful for other features, too [...]
Adding stuff to the gutter sounds more like a job for AppleScript, and unlikely this will be possible to combine with showing changes done to the file -- well, with the exception of my (even more long term) plan of allowing an xpath-inspired query language to query a document (based on scopes), which could then combine the query for the dynamic “changed” scopes with using AS (or similar) to use whatever API I may create to fiddle with the gutter -- and then have this run periodically.
But don't get your hopes up -- this is something I see happen maybe in TextMate 5.0 or so…
On Feb 9, 2006, at 7:01 PM, Allan Odgaard wrote:
But don't get your hopes up -- this is something I see happen maybe in TextMate 5.0 or so…
Fair enough. But is there anything that I should get my hopes up for? I couldn't find any mention on the website of features to expect in 2.0 (and beyond), although I suppose that's a closely guarded secret...
Trevor
On 10/2/2006, at 5:16, Trevor Harmon wrote:
[...] But is there anything that I should get my hopes up for? I couldn't find any mention on the website of features to expect in 2.0 (and beyond), although I suppose that's a closely guarded secret...
It's no secret, it's just unknown. But if you follow this list, you should be able to get some idea about at least what I plan to do -- but everything for which there is no shipping product is vaporware.
-
Allan Odgaard -
Charilaos Skiadas -
Chris Thomas -
Christopher Creutzig -
Jonathan Ragan-Kelley -
Niko Dittmann -
Patrick Mast -
Sune Foldager -
Trevor Harmon