[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]
Re: Unix text editor issues (was: st: mulitple comments using //and #d;)
Sadly, I agree with everything you say about the convenience or greater
value of more advanced text editors on unix. Unfortunately, they are not
and will not be available to me in the foreseeable future.
So, it really comes down to this: does the -delimit- command force anyone
to use it? As the answer is no, I don't see why there is this interest in
getting rid of a command someone else is using. I mean, I may not like to
use seemingly unrelated regressions in my work, but to act on my dislike I
need only ignore those models as options for my research. I don't have to
advocate for the removal of the -sur- command from stata.
Perhaps one day I will have access to a more advanced unix text editor,
and time to learn it. That'd be cool. :-) But, whether or not that
happens, there is no harm in maintaining a command others have found
useful, a command that is probably already embedded in tens of thousands
of programs around the world, its implications written at the end of
millions of stata code all over the globe.
On Sat, 2 Sep 2006, Michael S. Hanson wrote:
> Comments on two related messages, regarding the editing of Stata files
> on Unix, follow:
> On Sep 1, 2006, at 5:07 PM, SamL wrote:
> > Second, those who write code on a unix box with few bells and whistles
> > (e.g., color) are seriously advantaged by being able to specify their
> > own
> > delimiter.
> I write code on a Unix box, and I'm afraid I don't follow your logic.
> There exist Unix editors that offer syntax highlighting -- see the Text
> Editors with Stata FAQ:
> Even the lowly nano editor -- which I must confess I use frequently in
> Unix -- offers syntax highlighting:
> If you haven't yet tried a text editor with syntax highlighting, I
> think you'll be pleasantly surprised by the productivity boost.
> Beyond that, I personally do not find it easier to recognize that a
> line is continuing by the absence of ; than by the presence of /// --
> but of course, YMMV. I find that aligning all /// code in the far
> right-hand column, along with indenting continuing lines, makes it very
> easy to skim my code and see exactly which commands are on multiple
> lines -- whether or not syntax highlighting is enabled.
> On Sep 1, 2006, at 5:46 PM, Dimitriy V. Masterov wrote:
> > The reason that I care about this issue that I reserve "/*...*/"
> > comments for substantive comments, and use a Vim text editor script to
> > comment out parts of code using "//". This is why using ";" at the end
> > of the last line is not an option: it makes toggling comments
> > impossible. For this purpose, however,
> > #d;
> > * comment;
> > * comment;
> > pwd;
> > works like a charm. The "//" behavior is still a mystery.
> As I hinted above, I am not a vim (nor emacs) connoisseur /
> evangelist. However, I suspect it should be possible, through some
> clever use of regexp (interacting with ruby, perl, etc.?) to create a
> command that toggles in the way you need with the // notation. Someone
> with much more experience with vim will have to help you there.
> But I still would aver that it is easier to avoid using -delimit-
> altogether, and toggle all your comments with // -- including those in
> the middle of a line. One additional advantage of using /// for line
> continuations is that it also serves as a comment delimiter for any
> text placed after it on a line. I use this approach to place comments
> in the midst of 10 - 15 line graph commands, in order to later remind
> myself (or my RAs) why a particular graph option is specified the way
> it is. Hope this helps.
> -- Mike
> * For searches and help try:
> * http://www.stata.com/support/faqs/res/findit.html
> * http://www.stata.com/support/statalist/faq
> * http://www.ats.ucla.edu/stat/stata/
* For searches and help try: