I'm using Ruby's ReadLine library to implement a CLI.
I'm getting a weird behaviour with typing lines that are longer then the terminal width. Instead of continuing the text in a new line (like Bash does), the line gets overlapped. So the instead of going down one line, the input overrides the current line from the beginning of it.
Readline exposes screen_size, so I can create a new thread that listens to Readline's line_buffer and puts a new line whenever the length of the line equals the width of the terminal, but it feels wrong.
Is there another option? I saw that IRB and pry both use Readline and do support word wrap, however I couldn't figure how they do it.
Thanks.
Well, the solution is quite simple:
apt-get install ncurses-dev
Apparently, this seems to work, for whatever reason.
Related
Sometimes, parsing done by text editors for syntax highlighting is not accurate. It often happens that introducing a heredoc in ruby-mode messes up syntax highlighting on emacs as in this question. I am having problem with such case:
<<_
some here doc content
...
last line of the intended heredoc
_
this_ruby_code_line_and_any_line_after_it_is_highlightened_as_part_of_heredoc
I do not expect a fix on emacs ruby-mode for this, but is there some kind of a commented string that I can generally put between the heredoc and the following Ruby code in order to reset the highlighting problem? When I have problems not with heredoc but with funky string literals (especially those including quotes), sometimes, putting a commented string like
#"'`
at the end of the line fixes the problem. Is there such thing to fix the problem for heredoc, and further, is there a string that can be used more generally?
Works fine for me in an Emacs trunk build.
Try a more recent Emacs version (I'm quite certain that this works in the upcoming 24.3 version, but maybe in the current release, too) and/or make sure that you are using ruby-mode bundled with Emacs, not installed through ELPA, etc:
ELISP> (require 'which-func)
which-func
ELISP> (find-library-name "ruby-mode")
"/home/gutov/emacs-bzr/trunk/lisp/progmodes/ruby-mode.el"
I am converting a zsh shell app to ruby. I am used to using zsh's vared for letting user edit value of variable. Is there any equivalent in ruby?
This is a command-line app. I currently am using ruby's gets but this does not allow editing of a previous value. I once used highline, but IIRC, it allows using up arrow to get history, which is quite close, but not the same thing.
edit: I meant readline when i said highline. I use both actually.
I'm sure we're all familiar with the "unexpected kEnd" problem. They are always (to me) a lot of trouble to track down, because Vim doesn't match "do"s and "end"s. (And, obviously, other elements that end with "end", like "if")
Is there a way to configure Vim to show these matches to help make debugging easier?
If you are using a recent vim (I'm using 7.4), the built-in matchit macro works well with ruby code.
Simply enable it by adding the following to your .vimrc
runtime macros/matchit.vim
Hit % to match do/end combos and many others in ruby files.
I use this macro and then add this to my vimrc to enable it:
" % to bounce from do to end etc.
runtime! macros/matchit.vim
When I want to find the matching end for a do, I cursor over the do and hit %.
"endwise" is a pretty nice vim extension that adds them automatically, which I found greatly reduces the amount of missing ends. etc:
http://www.vim.org/scripts/script.php?script_id=2386
I use this matchit clone, that can be installed easily with vundle.
I've seen a number of option parsing libraries out there for ruby, but they all come with weird constraints about them.
'executable' gem claims that all command line binaries must have a syntax "binary
'micro-optparse' can't handle trailing list of filenames and requires you have defaults for all non-boolean commands. Strange.
Some other one I used made it impossible to run a command without arguments.
And so on and so on. And I don't want to parse ARGV myself.
Is there anything close to a specification or standard for command line options and arguments? And then what option parsing library complies to that standard?
Do you know about optparse? It's included in stdlib - as standard as it gets.
But there is no unix standard set in stone as to parsing command-line parameters.
You should define your requirements more clearly and then choose a library that suits them.
There's no standard I have ever heard of, but AFAIR Trollop was started out of the frustration with the other command line parsers.
+1 for Michael Kohl's mention of Trollop. Trollop makes it very easy to write command line options that conform to the gnu style.
I wrote a simple self-contained example in How do I make a Ruby script using Trollop for command line parsing?.
can anyone suggest a nice (not Netbeans) platform where i would be able to write ruby code to test?
I find irb a bit hard to follow when you want to define a method more than 3 lines long, and then test it.
Also, maybe just as a wish list item, some way where I could do follow the code step by step to monitor values in variables and make sure things are being done properly?
I'm asking because so far I've been writing in rails, but what you see is the final result of the method, and if you already expected a certain answer, then is fine, but if I need a more complicated method, i would like to be able to follow all the steps to make sure is doing what I want it to do.
Thanks a lot!
a great ide is rubymines by intellij. it is not free though. you can step through code and have the usual ide debugging features.
otherwise if the only problem you have is that you are examining code that is more than 3 lines, you can install the ruby-debug gem and then put the keyword debugger in your code and it will cause a break. So you don't need to put code into irb, just run your ruby script and it will break.
I know you said you find irb a bit hard to follow when you want to define a method more than 3 lines long, but if you use irb -rn ./(your file name here), you will get an irb output of every class, method, module, etc.
irb will walk through line by line so you can see what is working and what is not (you'll get true, false, nil, etc) for each line of code. I've found that you can skip what you already know is working and move on to where you feel the issues are.