TextMate January 2019

textmate@lists.macromates.com

9 participants
19 discussions

by feek

Hi, in the find window on macOS 10.13.6 using TM 2.0-rc.22 a black border appears: https://feek.d.pr/px7FtK == feek -- Sent from: http://textmate.1073791.n5.nabble.com/textmate-users-f3.html

1 year, 8 months

10.14 / Mojave Dark Mode

by jason

Are people using TextMate with Dark Mode? I see some issues with reading text (find input text is black until unfocused, then changes to white), but also curiously the icons in the outline view are also missing. [image: Screen Shot 2018-10-04 at 8.04.30 PM.png]

1 year, 8 months

Bundle support plist broken on Mojave

by Jacob Carlborg

I have a bundle command implemented in Ruby that uses TextMate.detatch. The tm/detach.rb requires ui.rb which requires plist.bundle. Loading the plist bundle crashes with a segmentation fault. The issue occurs on Mojave but not on High Sierra. I’m using "/usr/bin/env ruby20” as the Ruby for running the command. The command is available here [1]. [1] https://github.com/textmate/d.tmbundle/blob/master/Commands/Start%20DCD.tmC… -- /Jacob Carlborg

1 year, 8 months

Window scrolls up when moving between tabs

by Ed Wong

I’m running the latest RC 2.0-rc.15. I’ve only noticed this since I've installed this version. When I move between tabs (either by clicking on tab or using Option-Command left, right arrows) sometimes the page scrolls up by 1 to 3-4 lines each time. But once it does this scrolling then it will do so every time I come back to that tab. I’m not sure how TM handles window draws but there seems to be a miscalculated line offset between a buffered text image that gets shown when the window first shows and then an actual redraw of lines afterwards. I’ve noticed in some cases a clipped portion of the window being shown first and then the remaining page showing but the clipping is off so the text appears to move downwards. Sorry I haven’t looked into the code to get a better idea of what’s happening with window draws. Ed Wong

1 year, 8 months

Find dialog window problems

by Kelvin Wu

1. Use app "Check for Upgrade" to upgrade to RC 20/21/22, Cmd+F to bring up Find dialog window, unable to display/type non-English characters (such as Chinese, Japanese) in Find and Replace text box, have to un-focus input area to show the characters. No problem for English characters. 2. Manually upgrade by downloading RC 20/21/22 from Github, and replace existing TextMate.app in Applications. Cmd+F (or select Find... from Edit menu) will not bring Find dialog window. Rolled back to RC 19, solved the problem. -- Sent from my mobile. Ignore the typos unless they're funny. -- -- Sent from my mobile. Ignore the typos unless they're funny.

1 year, 11 months

Merging Pull Request

by Jens Axel Søgaard

Hi All, I am looking for someone that can merge the pull request below. The grammars of Textmate is used by Github. Sadly the grammar for the Scheme language colors square brackets red (as an error), and there are lots of Scheme implementations that allow squares. That makes it jarring to read source files on Github. A kind soul has found the error, fixed it and submitted a pull request. Unfortunately the grammars don't live in the main Textmate repo, so pull request are easily missed. This one is a couple of years old. It would be greatly appreciated by the Scheme community, if this could be merged. Thanks in advance. https://github.com/textmate/scheme.tmbundle/pull/9 /Jens Axel Søgaard

2 years

Re: Bundle support plist broken on Mojave (Philippe Huibonhoa)

by Greg

Default is "ruby 2.3.7p456" > > Today's Topics: > > 1. Re: Bundle support plist broken on Mojave (Philippe Huibonhoa) > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 30 Jan 2019 20:54:44 -0800 > From: Philippe Huibonhoa <phuibonhoa(a)gmail.com> > To: TextMate users <textmate(a)lists.macromates.com> > Subject: [TxMt] Re: Bundle support plist broken on Mojave > Message-ID: > <CABF6MVzbki=T+-DZ18Sg1AmJA+K2Jw7=WoYHDG+buNo+H9jHOg(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Does Mojave still have Ruby 1.8 available? I have bundle files > referencing /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby > but that directory does not exist. I'm not sure how to proceed, since this > does break some functionality. > > On Sat, Dec 15, 2018 at 12:29 AM Jacob Carlborg <doob(a)me.com> wrote: > >> On 15 Dec 2018, at 09:13, Allan Odgaard <mailinglist(a)textmate.org> wrote: >> >> The problem is that many bundle commands need ruby 1.8, so the bundle >> support code needs to remain compatible with 1.8 as well. >> >> This is support code has been written by a dozen different people over >> several years, I have no plans of rewriting it all to be compatible with >> both ruby 1.8 and 2.x, which in itself is not a fun excercise, not even >> sure we can make the plist extension compatible with both versions of ruby >> without switching to a version written entirely in ruby. >> >> Understandable. I?ve been wanting to completely re-implement the support >> code with support for 2.0 now for a while. But I?ve never prioritized it. >> >> My advice: If you want to use ruby 2.x for your custom commands, don?t use >> the support code. >> >> Yeah, in fact, most of my commands are written in Ruby 2.0 but one of them >> is using Ruby 1.8 to be able to use the completion window. >> >> In this case I see now that TextMate.detach is simple enough to copy to >> the bundle and remove the dependency on TextMate::UI. >> >> In retrospect we probably shouldn?t have made a ?shared support? >> directory, at least not without much much stricter discipline, as now we >> have a ton of legacy stuff that is pretty difficult to get rid of, because >> we have no idea about which third party bundles rely on it. >> >> The support code, at least the Ruby code, could be implemented as a >> separate gem. Then it could be versioned like any other gem. I have a >> bundle [1] where the whole Support directory is organized as a Ruby gem. It >> uses Bundler and several gems as dependencies. The gems are bundled >> directly in the Support directory and included in the Git repository. This >> works out quite nicely. >> >> [1] https://github.com/jacob-carlborg/GitLab.tmbundle/tree/master/Support >> >> -- >> /Jacob Carlborg >>

2 years, 1 month

Select /modify begin and end tags in HTML

by feek

Hi, a simple question, but I cannot find ;) When moving your cursor via arrow keys over a (HTML) tag, the corresponding beginning or ending tag is highlighted in yellow! So I assumed TM is able to select and / or change the tags at once. But unfortunately I cannot find the command. Hope someone can help me. == feek -- Sent from: http://textmate.1073791.n5.nabble.com/textmate-users-f3.html

2 years, 1 month

TextMate grammar help - stopping repository pattern includes overriding ?

by Scott McGillivray

Hello I am new to Textmate and grammars syntax but i want to fix a bug with a grammar used by GitHub for highlighting of SaltStack files. The grammar in question is this one ( https://github.com/saltstack/atom-salt/blob/master/grammars/yaml.cson ) and the problem is comments that span multiple lines don't get handled correctly so i fixed the regexp but the more i looked at the problem i don't think any comments are really being handled as the grammar expects because of an "include" that's overriding the local comment definition. As i said, i'm no Textmate/Grammar expert but with some fumbling around i think the problem occurs due to a repository entry that calls: { 'include': 'source.python' } This external grammar file has its own agenda when it comes to comments and lines matching the "#" type pattern. I think this included grammar is taking priority over the patterns/captures defined in the above .cson file. I believe it might be this pattern ( https://github.com/textmate/python.tmbundle/blob/master/Syntaxes/Python.tmL… ). If i comment/delete the 'include': 'source.python' from the "jinja-control" repository then my regexp change works and comments look as expected.. but obviously I've crippled the other highlighting brought with the python include. So at this point i'm stuck. I have no idea how the order or precedence works and how i should resolve this conflict ? Can someone explain please why the include is doing this and whats the way for me to ensure my local definitions to be enforced ? I tried moving my pattern to the top of the .cson, tried to make the regexp more explicit and increase the name depth in case any of those were the magic but no luck. thank you.

2 years, 1 month

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

TextMate January 2019