I just had a brief look at Diakonos. Seems nice and clean: just one
main .rb file for the editor, and one conf file. Sadly, aside from a
few comments here and there in the code and in the conf file, Diakonos
looks to be entirely undocumented.
There *is* a readme describing how to install (which is (happily)
trivial), but no mention anywhere how to use the editor (though,
passing "--help" (I guessed that one) gives 4 lines of info). I also
guessed that Ctrl-q exits the editor, but that's it.
The site implies that its first release was in June, 2004.
···
On 5/3/06, Pistos Christou <jesusrubsyou.5.pistos@geoshell.com> wrote:
[snip] Diakonos is still young and fledgling, but it is almost
fully scriptable in Ruby; that is, if you can press a key to do a
certain function, then you can also call that function in a Ruby script.
Pistos
Fascinating. I'm familiar with plugins for writing
major extensions. But what about writing small macros?
Is there a "macro" capability in FreeRide, or are
plugins the new-world way of customizing behaviors?
>
> Hmm. The only thing that turned me off to Emacs was the
> weird command names--and probably the lisp-ness, had I
> gotten close enough to it to get into that.
>
> Which gets me thinking...
>
> Ruby is Lisp-like...Emacs is based on Lisp...
> There really ought to be an editor based on Ruby...
>
I believe FreeRIDE is written in Ruby, as are the plug-ins you might write for it.
> ...it could start with new user interface semantics
> that adhere to the standards that have evolved
> over the last 35 years
>
> ...that would make it easy to use right from the start
>
> ...it could use Ruby, and be extended with Ruby, so
> it could be customized and evolved using the
> rather terrific language that Ruby is
>
Again -- I think more good things should be happening with FreeRIDE in the near future, especially after the wxRuby rewrite is done (and there's been good progress on that front lately).
···
-------- Original Message --------
From: John Gabriele <jmg3000@gmail.com>
Reply-To: ruby-talk@ruby-lang.org
On 4/29/06, Eric Armstrong <Eric.Armstrong@sun.com> wrote:
Can you share what you put in your .vimrc to configure that?
···
On 4/26/06, Alexandru E. Ungur <alexandru@globalterrasoft.ro> wrote:
I came up with a rather nice solution to it: I use the entire statusbar's
background color to tell me where I am: RED background == edit mode, GREEN
background == normal mode.
--
R. Mark Volkmann
Object Computing, Inc.
Can you give an example? The reason I ask is that I'm wondering if that is
something fundamentally better / different than the macro language facility
in nedit. With that, you can select some text, then run a macro against it
to do almost anything you want.
(You do have to write the macro, but nedit also has keystroke recording which
can give you a good start on many macros. (Almost??) every keyboard command
is available in the macro language, along with others which have no keyboard
counterpart (the first example that comes to mind are looping constructs.)
Randy Kramer
···
On Wednesday 26 April 2006 04:33 am, Jeff Rose wrote:
For example, the whole concept of filtering ranges of text through
commands is really genius. It mixes in perfectly with the unix
mentality, and it lets you compose your own commands from a simple set
of primitives.
> Besides that, in general I find myself slowed down constantly hitting
> Ctrl-[, forgetting whether I'm in command mode or not. Either that, or
> I'm filling my files with ":w" or ">>" or "i", "b", "w"...
>
You're in command mode unless the bottom says
--INSERT--
or
--VISUAL--
Right. Maybe I just haven't gotten into the habit of glancing down at
the bottom of the window. It seems to me to take less concentration to
just hit Ctrl-[ than to quickly look down and lose/find my place on
the page.
I find ESC to be much faster than Ctrl-[, YMMV.
I use a funky programmable keyboard which only has a tiny rubber Esc
button up away from the main keys. (
http://www.kinesis-ergo.com/contoured.htm ). So Ctrl-[ turns out to be
faster for me.
···
On 4/25/06, Logan Capaldo <logancapaldo@gmail.com> wrote:
On Apr 25, 2006, at 9:20 PM, John Gabriele wrote:
On the Contoured keyboard (see link in my previous post), you hit the
control keys (and alt keys, and a few others) with your thumbs. It's
symmetrical, so you can use either thumb.
The escape key is way up to the top left side of the keyboard and is
just a little rubber nub of a key, about 6 mm X 9 mm, and is not
useful for regular use. You have to take your left hand off the home
row to reach it (and hope you hit it instead of one of the also tiny
rubber F-keys).
Incidentally, I type using the dvorak layout, and on my keyboard the
'[' is in a fairly awkward position (2 rows down from the home row on
my right ring finger), but is still way easier to deal with than the
Esc key.
···
On 4/26/06, tsuraan@tsuraan.net <tsuraan@tsuraan.net> wrote:
> Besides that, in general I find myself slowed down constantly hitting
> Ctrl-[, forgetting whether I'm in command mode or not. Either that, or
> I'm filling my files with ":w" or ">>" or "i", "b", "w"...
The Ctrl-[ thing is interesting to me, because I've never heard of
anyone else escaping that way. Out of curiosity, is your control key
in the corner of your keyboard, or next to the 'a' key? For me, with
my control key right by my 'a' key, hitting ctrl-[ is really quick and
easy. The escape key is just too far off the home row for me to bother
with 
I found that I never use the caps lock key, so I remapped it to be another
Esc. Works great for vim. Until you use another computer...
Mark
···
On Wednesday 26 April 2006 15:56, tsuraan@tsuraan.net wrote:
> Besides that, in general I find myself slowed down constantly hitting
> Ctrl-[, forgetting whether I'm in command mode or not. Either that, or
> I'm filling my files with ":w" or ">>" or "i", "b", "w"...
The Ctrl-[ thing is interesting to me, because I've never heard of
anyone else escaping that way. Out of curiosity, is your control key
in the corner of your keyboard, or next to the 'a' key? For me, with
my control key right by my 'a' key, hitting ctrl-[ is really quick and
easy. The escape key is just too far off the home row for me to bother
with
The config file is pretty easy on the eyes, you can pick up the keybindings from that.
···
On May 4, 2006, at 1:20 AM, John Gabriele wrote:
On 5/3/06, Pistos Christou <jesusrubsyou.5.pistos@geoshell.com> wrote:
[snip] Diakonos is still young and fledgling, but it is almost
fully scriptable in Ruby; that is, if you can press a key to do a
certain function, then you can also call that function in a Ruby script.
Pistos
I just had a brief look at Diakonos. Seems nice and clean: just one
main .rb file for the editor, and one conf file. Sadly, aside from a
few comments here and there in the code and in the conf file, Diakonos
looks to be entirely undocumented.
There *is* a readme describing how to install (which is (happily)
trivial), but no mention anywhere how to use the editor (though,
passing "--help" (I guessed that one) gives 4 lines of info). I also
guessed that Ctrl-q exits the editor, but that's it.
The site implies that its first release was in June, 2004.
John Gabriele wrote:
I just had a brief look at Diakonos. Seems nice and clean: just one
main .rb file for the editor, and one conf file. Sadly, aside from a
few comments here and there in the code and in the conf file, Diakonos
looks to be entirely undocumented.
There *is* a readme describing how to install (which is (happily)
trivial), but no mention anywhere how to use the editor (though,
passing "--help" (I guessed that one) gives 4 lines of info). I also
guessed that Ctrl-q exits the editor, but that's it.
You are absolutely correct: There is very little user documentation. I
actually have more solid plans to come up with more material (online
documentation, in-application help) to give a better out-of-box
experience within the next two releases. I've walked a few people
through getting started, but I completely agree that a quick start
walkthrough of some kind is definitely in order. That and sprucing up
the F1 page by, perhaps, organizing into groups and showing the most
commonly used keybindings higher up.
I've also entertained notions of making a "for people coming from emacs"
conf file which would override most keystrokes to match emacs.
Thanks for trying Diakonos.
Pistos
···
--
Posted via http://www.ruby-forum.com/\.
jedit is nice. i use it all the time and it's got a few ruby plugins
(although i forget what they do).
Also there's SubEthaEdit if you're on a mac. The previous version is
available free for non-commercial use.
-Kate
sender: "Mark Volkmann" date: "Wed, Apr 26, 2006 at 09:51:45PM +0900" <<<EOQ
> I came up with a rather nice solution to it: I use the entire statusbar's
> background color to tell me where I am: RED background == edit mode, GREEN
> background == normal mode.
Can you share what you put in your .vimrc to configure that?
Sure, here you go:
--- .vimrc excerpt for statusbar highlighting ---
" Only do this part when compiled with support for autocommands,
" You better have Vim7 'cause this does all the magic
if has("autocmd")
augroup InsertStatus
au InsertEnter * hi StatusLine term=inverse,bold cterm=inverse,bold ctermfg=red ctermbg=white
au InsertLeave * hi StatusLine term=inverse,bold cterm=inverse,bold ctermfg=green ctermbg=white
augroup END
endif
" ensure statusline is always shown
set ls=2
" custom statusline
set statusline=%<file[%n]:\ %f\ %y%=\ %3lx%02c\ [%1*%M%*%R%H]\ %2P\
" initial statusline highlighting
hi StatusLine term=inverse,bold cterm=inverse,bold ctermfg=green ctermbg=white
hi StatusLineNC term=inverse,bold cterm=inverse,bold ctermfg=gray
hi User1 term=inverse,bold cterm=inverse,bold ctermfg=red
--- end ---
Adjust the colors as you see fit. I noticed the green looks too ugly on
plain xterm, but I use Terminal (http://www.os-cillation.com/index.php?id=42&L=5\)
and it looks quite nice there.
BTW, you also get a 'red spot' on the green statusbar when you have
unsaved changes, that feels nice too 
Good luck,
Alex
···
On 4/26/06, Alexandru E. Ungur <alexandru@globalterrasoft.ro> wrote:
First, thanks to John for pointing out that FreeRide
is most likely exactly the thing I'm using for.
Next, Pistos:
After many years coding, I became a writer. But I
still code whenever I can. But the result of the
writing experience led me to start writing the user
guide as part of the design process.
Note for aqile developers:
The user guide is one of process artifacts at
every stage. You modify it at the start of each
cycle to explain what you plan to have accomplished
at the end of the cycle. If the plan changes, you
modify the document accordingly.
That experience had several tremendous benefits:
* When I finally finished coding a project, I was
generally too burned out to write a user guide.
* Since a project was never really "finished", it
was hard to define that point at which I really
/should/ write the guide.
* When I was coding, a myriad of ideas would occur
to me about things the users ought to know. When
I wrote at the end of a project, I always had the
nagging feeling that I was only recalling a fraction
of the things I wanted to say.
* But with the user guide already written, it's an
easy matter to add such things as they come in
note format to be fleshed out later, if in no other
form.
I've used that strategy successfully on several projects.
The user guide lets people give me feedback on how they
want to work even before it's written. And you never
find yourself in that awful position where you've created
something great, but no one uses it because they can't
find out how.
I'll do a design document as well, to keep track of implementation ideas. Between the two of them, I've
never needed a "specification".
Pistos Christou wrote:
···
John Gabriele wrote:
I just had a brief look at Diakonos. Seems nice and clean: just one
main .rb file for the editor, and one conf file. Sadly, aside from a
few comments here and there in the code and in the conf file, Diakonos
looks to be entirely undocumented.
There *is* a readme describing how to install (which is (happily)
trivial), but no mention anywhere how to use the editor (though,
passing "--help" (I guessed that one) gives 4 lines of info). I also
guessed that Ctrl-q exits the editor, but that's it.
You are absolutely correct: There is very little user documentation. I actually have more solid plans to come up with more material (online documentation, in-application help) to give a better out-of-box experience within the next two releases. I've walked a few people through getting started, but I completely agree that a quick start walkthrough of some kind is definitely in order. That and sprucing up the F1 page by, perhaps, organizing into groups and showing the most commonly used keybindings higher up.
I've also entertained notions of making a "for people coming from emacs" conf file which would override most keystrokes to match emacs.
Thanks for trying Diakonos.
Pistos
kate rhodes wrote:
jedit is nice. i use it all the time and it's got a few ruby plugins
(although i forget what they do).
Also there's SubEthaEdit if you're on a mac. The previous version is
available free for non-commercial use.
-Kate
I use jEdit all the time, and I've found a number of very useful
plugins:
Ruby plugin (of course)
BufferTabs
Project Viewer
Fast Open
SuperAbbrevs - TextMate snippet-like functionality
Editor Scheme - create color schemes
One thing - on Windows, the Monaco font )which I believe is the default
for TextMate) with anti-aliasing looks really bad. A better choice
would be Bitstream Vera Sans Mono.
···
--
Posted via http://www.ruby-forum.com/\.
Eric Armstrong wrote:
First, thanks to John for pointing out that FreeRide
is most likely exactly the thing I'm using for.
Next, Pistos:
After many years coding, I became a writer. But I
still code whenever I can. But the result of the
writing experience led me to start writing the user
guide as part of the design process.
Note for aqile developers:
The user guide is one of process artifacts at
every stage. You modify it at the start of each
cycle to explain what you plan to have accomplished
at the end of the cycle. If the plan changes, you
modify the document accordingly.
Similar to what I call "comment-driven development"
···
--
James Britt
“Design depends largely on constraints.”
— Charles Eames
Eric Armstrong wrote:
Next, Pistos:
After many years coding, I became a writer. But I
still code whenever I can. But the result of the
writing experience led me to start writing the user
guide as part of the design process.
* Since a project was never really "finished", it
was hard to define that point at which I really
/should/ write the guide.
* When I was coding, a myriad of ideas would occur
to me about things the users ought to know. When
I wrote at the end of a project, I always had the
nagging feeling that I was only recalling a fraction
of the things I wanted to say.
I've used that strategy successfully on several projects.
The user guide lets people give me feedback on how they
want to work even before it's written. And you never
find yourself in that awful position where you've created
something great, but no one uses it because they can't
find out how.
Interesting points; thanks for sharing. I've absorbed them, and will
change the development process of Diakonos a bit.
I've recently released 0.8.1, and with it, I've begun growing a Diakonos
wiki: http://wiki.purepistos.net/doku.php?id=Diakonos At the moment,
there is a Getting Started page, as well as a larval "Tips and Tricks"
section which describes some perhaps unobvious features of Diakonos.
I still would like to follow through on the claim/goal that Diakonos is
(will be) a "usable" editor. Part of that is making the learning curve
shallow and the first-impression Ruby-like.
Pistos
···
--
Posted via http://www.ruby-forum.com/\.
Similar, but with an important difference. The user
guide tells someone how to use the program to do what
they need to do. It's necessarily use-case oriented.
Comments tend to be implementation-oriented. They
tell how the /program/ does what it does. The user
guide tells the /user/ how to do what they need to do.
James Britt wrote:
···
Eric Armstrong wrote:
First, thanks to John for pointing out that FreeRide
is most likely exactly the thing I'm using for.
Next, Pistos:
After many years coding, I became a writer. But I
still code whenever I can. But the result of the
writing experience led me to start writing the user
guide as part of the design process.
Note for aqile developers:
The user guide is one of process artifacts at
every stage. You modify it at the start of each
cycle to explain what you plan to have accomplished
at the end of the cycle. If the plan changes, you
modify the document accordingly.
Similar to what I call "comment-driven development"
Cool! I look forward to finding out more.
Pistos Christou wrote:
···
Eric Armstrong wrote:
Next, Pistos:
After many years coding, I became a writer. But I
still code whenever I can. But the result of the
writing experience led me to start writing the user
guide as part of the design process.
* Since a project was never really "finished", it
was hard to define that point at which I really
/should/ write the guide.
* When I was coding, a myriad of ideas would occur
to me about things the users ought to know. When
I wrote at the end of a project, I always had the
nagging feeling that I was only recalling a fraction
of the things I wanted to say.
I've used that strategy successfully on several projects.
The user guide lets people give me feedback on how they
want to work even before it's written. And you never
find yourself in that awful position where you've created
something great, but no one uses it because they can't
find out how.
Interesting points; thanks for sharing. I've absorbed them, and will change the development process of Diakonos a bit.
I've recently released 0.8.1, and with it, I've begun growing a Diakonos wiki: http://wiki.purepistos.net/doku.php?id=Diakonos At the moment, there is a Getting Started page, as well as a larval "Tips and Tricks" section which describes some perhaps unobvious features of Diakonos.
I still would like to follow through on the claim/goal that Diakonos is (will be) a "usable" editor. Part of that is making the learning curve shallow and the first-impression Ruby-like.
Pistos
Eric Armstrong wrote:
Similar, but with an important difference. The user
guide tells someone how to use the program to do what
they need to do. It's necessarily use-case oriented.
Comments tend to be implementation-oriented. They
tell how the /program/ does what it does.
Well, comments that just describe what the code is doing aren't always helpful. I tend toward comments that explain the purpose and rationale for the code. The code itself should be clear enough to describe what it is doing.
Yes, they are always user-centric. But they do often have a "thinking out loud" quality which is handy when writing up user docs.
The comments are often user stories that are then transmogrified into tests and code to make the stories live.
···
--
James Britt
"In Ruby, no one cares who your parents were, all they care
about is if you know what you are talking about."
- Logan Capaldo
We are currently developing an IDE ("Ruby In Steel") for Visual Studio
2005.
The current release (0.5) has
Code colouring
Code collapsing
Integrated interactive console
Commenting/uncommenting
Bracket matching/location
Project Manager (tree view pane)
Syntax errors - click to find
The next release (0.6) due out in about 2 weeks has:
Debugging
Breakpoints
drag/drop watch variables
step into/step over
autos window
locals window
call stack
interactive debug console
After that we are adding Rails support features, IntelliSense, snippets
etc.
You can keep up to date with developments at:
http://www.sapphiresteel.com/
best wishes
Huw
···
--
Posted via http://www.ruby-forum.com/.
Ah ha. VERY nice. I see the integration now.
James Britt wrote:
···
Eric Armstrong wrote:
Similar, but with an important difference. The user
guide tells someone how to use the program to do what
they need to do. It's necessarily use-case oriented.
Comments tend to be implementation-oriented. They
tell how the /program/ does what it does.
Well, comments that just describe what the code is doing aren't always helpful. I tend toward comments that explain the purpose and rationale for the code. The code itself should be clear enough to describe what it is doing.
Yes, they are always user-centric. But they do often have a "thinking out loud" quality which is handy when writing up user docs.
The comments are often user stories that are then transmogrified into tests and code to make the stories live.