Ruby Editor

[alex_land]

Greetings:


I am new to Ruby (from C++) so these are quite basic questions i'm
afraid.

My questions are also more about Editor mechanics rather than Ruby per
se-if anyone can suggest a better forum, my apologies, just let me
know and i'll re-post.

I have spent the few weeks with Ruby using irb from the Terminal and
Text Edit, while i got a better sense from the Ruby Community
regarding the editors of choice. So yesterday i bought a license to
TextMate, which by the way, might just be the most beautiful (and t/4
useful) App i have ever seen, let alone owned and used.

My question relates to "commands" (i believe this term has two
meanings in TM-i'm using it to refer to one of the three automation
means). "Scope"?

1. Can I specify different lexical scopes for different
"languages" (that might not be the TM lingo-i mean "Ruby," "HTML,"
"Text," etc.)?

2. If i leave this field empty, is my default, "unlimited scope?"

3. When i go to the Bundle Editor, i get a drop down of like 20 or so
languages-3-5 of these i'll use regularly, another 3-4 ocasionally,
and the rest, unlikely. I see i can "filter" which i've done before in
other editors, so i know from painful experience that when i've had to
re-add one or more of these, and i do an update, all default bundle
items write over my customizations. T/4, i would like to put my 3-5
"everyday set" in a different folder to prevent this. Is there a
better solution w/ TM?


Thanks,

-alex

 

[John Joyce]

I don't use TextMate myself, however James Edward Gray II who is a
prolific
and helpful contributor to this list has written a book (which I
haven't
read) all about TextMate. It might be worth checking out.

http://www.pragmaticprogrammer.com/titles/textmate/index.html

Thanks,

Mr. Gray not only wrote "the" book on TextMate (available also as a
pdf ebook at the Pragmatic Programmers' site at a discount versus the
print book) but he also wrote a lot of bundles for TextMate, I believe.
Get the book. Read a little bit of it at a time. Just learn something
new every day or two or ten. As you learn your way around TextMate
you will find your productivity increasing rapidly, particularly with
Ruby, Rails and HTML.
For some languages there may be better solutions available.
PHP, especially big projects, for example is probably best done with
Zend's IDE.
TextMate also works well with Transmit, Panic software's nice FTP app.
TextMate's big weakness is with non-western languages. Japanese for
example. It can display the characters (if they're in the font you
are using) but things go crazy when you use the Kotoeri input system.
This is why in Japan many Rubyists are using Jedit or something.

John Joyce

 

[Bertram Scharpf]

Hi,

Am Samstag, 21. Jul 2007, 07:50:00 +0900 schrieb alex_land:

[...] regarding the editors of choice.

I suppose myself to be the most critical Vim user abroad.
I sure took long to accept Vim as a software to be at least installed.
I deeply recommend to use and getting used to Vim.

Bertram

 

[M. Edward (Ed) Borasky]

Mr. Gray not only wrote "the" book on TextMate (available also as a pdf
ebook at the Pragmatic Programmers' site at a discount versus the print
book) but he also wrote a lot of bundles for TextMate, I believe.
Get the book. Read a little bit of it at a time. Just learn something
new every day or two or ten. As you learn your way around TextMate you
will find your productivity increasing rapidly, particularly with Ruby,
Rails and HTML.
For some languages there may be better solutions available.
PHP, especially big projects, for example is probably best done with
Zend's IDE.
TextMate also works well with Transmit, Panic software's nice FTP app.
TextMate's big weakness is with non-western languages. Japanese for
example. It can display the characters (if they're in the font you are
using) but things go crazy when you use the Kotoeri input system. This
is why in Japan many Rubyists are using Jedit or something.

TextMate has a much bigger weakness ... it only runs on a Mac.

 

[John Joyce]

TextMate has a much bigger weakness ... it only runs on a Mac.

That's hardly a weakness. The developer doesn't want to be bothered
with developing for other systems. If you've used Xcode and Inteface
Builder (or NeXTStep before) can you blame him?

But there is a TextMate Bundle compatible Windows app in the works
from another developer who is getting much support from the TextMate
maker!
Much like the long wait for the OS X Ruby one-click-installer (tried
it today, works like a charm),
the Windows crowd will soon have it's own equivalent... (minus the OS)

 

[Cliff Rowley]

But there is a TextMate Bundle compatible Windows app in the works
from another developer who is getting much support from the TextMate
maker!
Much like the long wait for the OS X Ruby one-click-installer (tried
it today, works like a charm),
the Windows crowd will soon have it's own equivalent... (minus the OS)

That would be E (http://www.e-texteditor.com). I like it, personally,
but it's far from polished, and there are a few caveats still being
ironed out. For example, to remain compatible with as many TextMate
bundles as it can, it employs the use of Cygwin to supply *nix commands
and such, which can cause a few hiccups here and there if you don't
generally use Cygwin anyway (which under Windows I can't do without).

 

[Chad Perrin]

That's hardly a weakness. The developer doesn't want to be bothered
with developing for other systems. If you've used Xcode and Inteface
Builder (or NeXTStep before) can you blame him?

It's a big enough weakness that I won't use it for that very reason. The
way I see it, any requirement to use an OS that I don't much like is a
weakness of the application in question.

But there is a TextMate Bundle compatible Windows app in the works
from another developer who is getting much support from the TextMate
maker!
Much like the long wait for the OS X Ruby one-click-installer (tried
it today, works like a charm),
the Windows crowd will soon have it's own equivalent... (minus the OS)

Whee . . . even worse than having to use a Mac.

This is just one man's opinion, of course.

 

[Dan Zwell]

Hi,

Am Samstag, 21. Jul 2007, 07:50:00 +0900 schrieb alex_land:

[...] regarding the editors of choice.

I suppose myself to be the most critical Vim user abroad.
I sure took long to accept Vim as a software to be at least installed.
I deeply recommend to use and getting used to Vim.

Bertram

I deeply respect Vim. I am convinced that there is no more elegant way
to do simple or complex manipulation of text/code. However, learning
Dvorak put a damper on my ability to use Vim. Instead, I am learning
Emacs. If Vim is the most elegant editor, Emacs is the most
customizable. That is a strength and a weakness--I probably won't feel
completely satisfied with the editor until I have put another 30 hours
into writing customizations and scripts for the program.

These two editors have a steep learning curve, if you want to use them
effectively. (Don't bother trying, otherwise.) I would think that Vim is
a little better for beginners, because it will force you to learn
without being overly difficult. It is too easy to use Emacs without
learning about its advanced features, and that would be a waste.

Welcome to the cult,
Dan

 

[Alexandru E. Ungur]

sender: "Dan Zwell" date: "Sat, Jul 21, 2007 at 04:04:51PM +0900" <<<EOQ

I deeply respect Vim. I am convinced that there is no more elegant way
to do simple or complex manipulation of text/code. However, learning
Dvorak put a damper on my ability to use Vim. Instead, I am learning
Emacs. If Vim is the most elegant editor, Emacs is the most
customizable. That is a strength and a weakness--I probably won't feel
completely satisfied with the editor until I have put another 30 hours
into writing customizations and scripts for the program.

Just for the sake of completness (and for those that don't know vim):
currently there are 1947 vim plugins listed at vim.sf.net and about
1300 tips for customization. You can also extend vim in one of
vimscript, python, *ruby*, tcl and/or mzscheme... so I really don't
think Emacs is more customizable than Vim. Those being said, I love
Emacs just as much as Vim, they both rock!

Cheers,
Alex

 

[Robert Dober]

It's a big enough weakness that I won't use it for that very reason. The
way I see it, any requirement to use an OS that I don't much like is a
weakness of the application in question.



Whee . . . even worse than having to use a Mac.

This is just one man's opinion, of course.

+ 42! (yes ! means what you think it does

IOW there is no doubt TextMate is a great piece of SW, it is not Open
Source, for some of us this is a big burden.
And for those who think it is not, just imagine there will be no
TextMate around anymore in some future time...

Robert

 

[M. Edward (Ed) Borasky]

Just for the sake of completness (and for those that don't know vim):
currently there are 1947 vim plugins listed at vim.sf.net and about
1300 tips for customization. You can also extend vim in one of
vimscript, python, *ruby*, tcl and/or mzscheme... so I really don't
think Emacs is more customizable than Vim. Those being said, I love
Emacs just as much as Vim, they both rock!

Cheers,
Alex

I must confess that

a. I don't use most of the extras Vim gives over good old vi, and
b. Hard-core geek that I am, I never learned either Teco or Emacs.

 

[Alexandru E. Ungur]

sender: "M. Edward (Ed) Borasky" date: "Sun, Jul 22, 2007 at 02:07:48AM +0900" <<<EOQ

I must confess that

a. I don't use most of the extras Vim gives over good old vi, and
b. Hard-core geek that I am, I never learned either Teco or Emacs.

Too bad, as it's pretty cool for editing Erlang ;-)

Cheers,
Alex

=== excerpt from Emacs Erlang mode help page ==============================
Erlang mode:
Major mode for editing Erlang source files in Emacs.
It knows about syntax and comment, it can indent code, it is capable
of fontifying the source file, the TAGS commands are aware of Erlang
modules, and the Erlang man pages can be accessed.

Should this module, "erlang.el", be installed properly, Erlang mode
is activated whenever an Erlang source or header file is loaded into
Emacs. To indicate this, the mode line should contain the word
"Erlang".

The main feature of Erlang mode is indentation, press TAB and the
current line will be indented correctly.

Comments starting with only one `%' are indented to the column stored
in the variable `comment-column'. Comments starting with two `%':s
are indented with the same indentation as code. Comments starting
with at least three `%':s are indented to the first column.

However, Erlang mode contains much more, this is a list of the most
useful commands:
TAB - Indent the line.
C-c C-q - Indent current function.
M-; - Create a comment at the end of the line.
M-q - Fill a comment, i.e. wrap lines so that they (hopefully)
will look better.
M-a - Goto the beginning of an Erlang clause.
M-C-a - Ditto for function.
M-e - Goto the end of an Erlang clause.
M-C-e - Ditto for function.
M-h - Mark current Erlang clause.
M-C-h - Ditto for function.
C-c C-z - Start, or switch to, an inferior Erlang shell.
C-c C-k - Compile current file.
C-x ` - Next error.
, - Electric comma.
; - Electric semicolon.

Erlang mode check the name of the file against the module name when
saving, whenever a mismatch occurs Erlang mode offers to modify the
source.

[..]

 

[John Joyce]

+ 42! (yes ! means what you think it does

IOW there is no doubt TextMate is a great piece of SW, it is not Open
Source, for some of us this is a big burden.
And for those who think it is not, just imagine there will be no
TextMate around anymore in some future time...

Robert

Open source is nice sometimes, but it isn't the most important thing
to everyone.
There's no need to ignore software because it's closed source.

 

[Dan Zwell]

You can also extend vim in one of
vimscript, python, *ruby*, tcl and/or mzscheme... so I really don't
think Emacs is more customizable than Vim.

That is precisely why I think Emacs is more customizable than Vim. Elisp
is capable of controlling every aspect of the program, as I understand
it. All plugins are in Elisp, and many of them can play nice together or
extend each other. By running a few lines of elisp, I have even
(accidentally) changed functions that were necessary to save or exit!
(Like I said earlier, extreme customizability is not always an
advantage. But if you like that sort of thing...)

With Vim, you have to delve into vimscript if you want to have complete
control of the editor (or so I've read). Further, many plugins are
written (mostly) in ruby, python, vimscript, etc. If you want to modify
a plugin, it will inevitably not be written in a language that you are
comfortable with. (Maybe others have had more luck with Vim plugins than
me.)

Dan

P.s., just my opinions! Not trying to bash anyone's religion, here!

 

[Robert Dober]

Open source is nice sometimes, but it isn't the most important thing
to everyone.
There's no need to ignore software because it's closed source.

It is the only means to assure persistence, if X who has the copyright
of TextMate decides that there will be no more TextMate, than there
will be no more TextMate.
Hopefully that will never happen but it is a legal fact.
That is the only point I wanted to make.

Robert

 

[Chad Perrin]

I generally agree. In some cases, though, I can see the reasons for making
those tradeoffs. If my choices are to write something elegant, reliable,
and clean in Ruby, taking a week to do it, or to spend a month mostly getting
it running in C, I might be better off with Ruby, even though it may restrict
my choice of targets some.

I can understand the developer's desire to develop for the platform he
uses. From his perspective, I'm sure that's not a weakness of the
software at all. From the perspective of someone else who uses Macs
every time, all the time, I'm sure it doesn't look like a weakness.

On the other hand, from the perspective of someone who never uses Macs,
rarely uses Macs, or even uses Macs a lot (but not always), it starts
looking like a weakness.

So it goes. . . .

 

[Chad Perrin]

Open source is nice sometimes, but it isn't the most important thing
to everyone.
There's no need to ignore software because it's closed source.

It appeared pretty clear to me that Robert's point was that, like all
proprietary, closed source software, TextMate may one day disappear from
the market simply on the whim of the copyright holder (or because the
copyright holder "goes out of business", gets hit by a bus, whatever).
As such, putting all your eggs in the TextMate basket may be kind of a
losing proposition.

There are other reasons to prefer open source over closed source, as
well. All in all, I don't think TextMate is good enough that it
overcomes the negatives of being a closed source, proprietary
application. There are cases where, in a strictly technical sense, the
benefits of a given piece of software *do* overcome the detriments, but
for my money this is not one of them. This in no way means that whether
or not something is open source is the only, or even biggest, concern,
but rather that whether it's open source is simply an *important*
concern.

Your mileage may vary.

 

[Chad Perrin]

That is precisely why I think Emacs is more customizable than Vim. Elisp
is capable of controlling every aspect of the program, as I understand
it. All plugins are in Elisp, and many of them can play nice together or
extend each other. By running a few lines of elisp, I have even
(accidentally) changed functions that were necessary to save or exit!
(Like I said earlier, extreme customizability is not always an
advantage. But if you like that sort of thing...)

With Vim, you have to delve into vimscript if you want to have complete
control of the editor (or so I've read). Further, many plugins are
written (mostly) in ruby, python, vimscript, etc. If you want to modify
a plugin, it will inevitably not be written in a language that you are
comfortable with. (Maybe others have had more luck with Vim plugins than
me.)

I'm not sure that tracks. You consider Emacs to be more customizable
because all the plugins are written in Elisp, but you consider Vim less
customizable because you have to know vimscript to write plugins. Am I
reading what you're saying correctly?

So . . . how are those two things different from one another?

(leaving aside for the moment the ability to write significant chunks of
plugin code in other languages -- which I think is present in both, but
more obvious and common with Vim)

 

[Chad Perrin]

Welcome to the cult,

This cult . . . ?
http://www.splange.freeserve.co.uk/misc/vi.html

 

[M. Edward (Ed) Borasky]

It appeared pretty clear to me that Robert's point was that, like all
proprietary, closed source software, TextMate may one day disappear from
the market simply on the whim of the copyright holder (or because the
copyright holder "goes out of business", gets hit by a bus, whatever).
As such, putting all your eggs in the TextMate basket may be kind of a
losing proposition.

Well ... I'll have to go look at Robert's post, but I don't think open
source vs. closed source is a significant factor in the viability or
longevity of a piece of software. I personally think MacOS is a fine
product, and I think the same thing about Windows XP Professional SP 2.
And I think the same thing about the major breeds of Linux I've dealt
with: Red Hat/CentOS/Fedora, Debian/Ubuntu and Gentoo.

There are other reasons to prefer open source over closed source, as
well. All in all, I don't think TextMate is good enough that it
overcomes the negatives of being a closed source, proprietary
application.

Neither do I -- requiring a Macintosh is a deal breaker. I'm not against
buying software. If you recall I compared KDevelop and Komodo a few
months back in my search for an industrial strength IDE and ended up
purchasing Komodo. Why?

1. Komodo was cross-platform. Not only is KDevelop Linux-only, it's
really KDE-only and Qt-only. Linux, Qt and KDE are also fine products,
but I didn't want to limit myself to them.

2. Komodo did a better job of syncing with my RubyForge repositories
than KDevelop did.

3. I didn't need C/C++, which KDevelop supports and Komodo doesn't.

There are cases where, in a strictly technical sense, the
benefits of a given piece of software *do* overcome the detriments, but
for my money this is not one of them. This in no way means that whether
or not something is open source is the only, or even biggest, concern,
but rather that whether it's open source is simply an *important*
concern.

To me, viability and energy of the development team are more important
than whether I can hack on the source or not, except for software in
very specialized areas. For example, there are a lot of Petri net
analysis and modeling packages out there that are freely available to
the academic community in source form but not for commercial users.

I'd like to hack on such stuff, but I can't. But I *don't* want to hack
on an IDE, or a word processor, or a browser. In those cases, open
source only means I probably don't have to pay for it and I return the
favor by filing bug reports rather than trashing them in my blog. * I
want IDEs and browsers and word processors that do my bidding and make
easier hacking on the stuff I want to hack on.


* Except for Firefox and OpenOffice -- those I *have* trashed in my blog.