[Konrad Zdeb]

Just to add to the discussion on the integration of TextWrangler and Stata, is there a way to prevent TW from spell checking text inside the macros? Ideally, I would like TW to check comments and strings within the "" only.

[Rich Goldstein]

have you ensured that "check spelling while you type" (under editor defaults under preferences) is UNchecked?

[Konrad Zdeb]

Yes, I can switch off like that but I was hoping to achieve more fancy solution of spell checking only text in comments

[Konrad Zdeb]

To add to the subject, is it possible to make TextWrangler highlight comments more intelligently:

[Steve Samuels]

You can change the color of comments in the Text Colors pane of BBEdit Preferences. I assume that you can do the same in TextWrangler.

[Konrad Zdeb]

Hi Steve,

Thanks for your note. I did that but what is interesting is that the second comment is highlighted as it should be but the first one is ignored. The syntax is the same with /* */ signs marking the commented space.

[Phil Schumm]

Just to add to the discussion on the integration of TextWrangler and Stata, is there a way to prevent TW from spell checking text inside the macros? Ideally, I would like TW to check comments and strings within the "" only.

FWIW, TextMate allows you to enable/disable spell checking for any scope within a file. Thus, for example, you can enable spell checking for string literals and comments only, if you want. One thing to note is that, depending on the file, comments sometimes include a lot of commented out code, which you probably don't want to spellcheck. Thus, in languages like Python where it is standard practice to distinguish between different types of comments, you might enable spell checking in docstrings (descriptive comments at the beginning of each module, class or function) but not in other comments. You could do something similar in Stata by using the different comment characters for different purposes, if you wanted (see below).

I did that but what is interesting is that the second comment is highlighted as it should be but the first one is ignored. The syntax is the same with /* */ signs marking the commented space.

I don't know how this is handled in TextWrangler, but in TextMate, different comment characters may be scoped differently, allowing you to treat them differently WRT syntax highlighting, spellchecking, automatic indenting and other behaviors.

[Konrad Zdeb]

TM looks like an interesting alternative but it's quite pricey. TW is free. Out of curiosity, how do you execute Stata code in Stata via TM is there a similar script as for the TW?

[Phil Schumm]

TextMate 2 (which is what you should use—the alpha designation is not really appropriate any longer) may currently be used without a license key without any limitations (the actual code itself is open source). At some point, they may start requiring a license key for TM 2, but note that they have always provided an educational discount. TextMate includes a Stata mode, which is developed on GitHub.

[Konrad Zdeb]

Perfect, thank you very much for this. I'll happily explore TM2

[Konrad Zdeb]

TextMate 2 (which is what you should use—the alpha designation is not really appropriate any longer) may currently be used without a license key without any limitations (the actual code itself is open source). At some point, they may start requiring a license key for TM 2, but note that they have always provided an educational discount. TextMate includes a Stata mode, which is developed on GitHub.

Hi, I'm currently trying TM2 with the Stata bundle. I'm not sure why, but the syntax highlighting appears to be absent:

I installed the bundle via the Bundles option in the menu. Is there something else I should switch one in order to make the syntax highlighting present? Further on the highlighting, will the highlighting support custom commands or will I have to add them manually, as in case of TW?

[Phil Schumm]

At present, syntax coloring for Stata/Mata is restricted to keywords, string literals, operators and comments. Stata commands (e.g., list, summarize, regress, etc.) are not colored. There are several reasons for this:

1) Coloring all Stata commands IMO reduces the utility of syntax coloring, which is to highlight key syntactical features of the language both to reduce coding errors and to make the code easier to read. Admittedly, this is a subjective opinion.

2) Coloring Stata commands correctly is hard. To do this properly, you need to account for all possible abbreviations for each command, and ensure that commands are only colored when they appear in specific contexts (e.g., at the beginning of a new command line, following prefix commands, etc.). Stata's own do-file editor does a pretty nice job here, but even it is not perfect.

3) Although I haven't tested it, I would be concerned that attempting to color all Stata commands would have a noticable effect on performance. This is an empirical question.

My original objective with this bundle was not so much syntax coloring as it was being able to use all of TextMate's editing features when writing Stata and Mata code. As a result, I did only the minimal amount with regard to syntax coloring. This really should be revisited, and I would be glad to include a facility for coloring Stata commands (including 3rd-party commands installed on the user's system) if it were optional and didn't affect performance too much. The first task here would be a systematic review of Stata's syntax, to figure out exactly which elements, constructs, etc. we would want to handle. I spent a few hours on this a year or two ago, but didn't have time to finish it. However, the Stata bundle is on GitHub, and anyone is welcome to fork it and/or to contribute.

One final thing. Since Mata is a standard programming language, coloring Mata code is a much easier task. However, there are several things remaining to be done here too. For example, we do not currently color function defs or calls, class defs, etc. For anyone interested in helping to improve the bundle's syntax coloring, working on improving/extending the coloring for Mata would be an easier place to start.

[Konrad Zdeb]

1) Coloring all Stata commands IMO reduces the utility of syntax coloring, which is to highlight key syntactical features of the language both to reduce coding errors and to make the code easier to read. Admittedly, this is a subjective opinion.

I see your point but I beg to differ. I use Notepad++ on Windows an TW on Mac and enjoy nice colouring of Stata commands that N++ Stata language module provides:

[Konrad Zdeb]

To add to the discussion on syntax highlighting, it occurs to me that TW does not properly recognise where the strings end. The code below is working fine but it had to insert dummy " to make sure that the remaining part of the code won't be highlighted as string. Is there something I could change in my TW configuration?

[Konrad Zdeb]

Of course, the compiled version of my "do selection in Stata" script for BBEdit/TextWrangler now includes a mention of Ben Hulley's original contribution.

Just to add, when executing the code below I got the timed out error. The code simply sources publicly available lookup file for postcodes and other statistical/administrative geographies in Scotland disseminated and maintained by the Information Services Division (NHS). As the file is big the code has to run for a while in order to download the data.

/* Load the postcode file */
import delimited using ///
"https://isdscotland.scot.nhs.uk/Products-and-Services/GPD-Support/Geography/Postcode-Reference-File/_docs/latestpcinfowithlinkpc_240714.csv", ///
    varnames(1) clear