Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

border.separator = :each_row #18

Closed
MadBomber opened this issue Apr 5, 2018 · 6 comments
Closed

border.separator = :each_row #18

MadBomber opened this issue Apr 5, 2018 · 6 comments

Comments

@MadBomber
Copy link

This option as documented in the README does not work. Here is my IRB session:

>> require 'tty-table' #=> true
>> table = TTY::Table.new ['header1', 'header2'], [['a1', 'a2'], ['b1', 'b2']]
=> #<TTY::Table header=#<TTY::Table::Header fields=["header1", "header2"]> rows=[#<TTY::Table::Row fields=["a1", "a2"]>, #<TTY::Table::Row fields=["b1", "b2"]>] orientation=#<TTY::Table::Orientation::Horizontal:0x00007f819b8be740 @name=:horizontal> original_rows=nil original_columns=nil>
>> puts table.render(:ascii) do |renderer|
 >       renderer.border.separator = :each_row
|    end #=> nil
+-------+-------+
|header1|header2|
+-------+-------+
|a1     |a2     |
|b1     |b2     |
+-------+-------+
@RylanBauermeister
Copy link

The README is wrong, but it works. You need to pass it:

renderer.border.separator = TTY::Table::Border::EACH_ROW

@MadBomber
Copy link
Author

MadBomber commented Mar 28, 2019

I tryed that and got the same result...

>> puts table.render(:ascii) do |renderer|
 >       renderer.border.separator = :each_row
|    end  #=> nil
+-------+-------+
|header1|header2|
+-------+-------+
|a1     |a2     |
|b1     |b2     |
+-------+-------+
>> puts table.render(:ascii) do |renderer|
 >       renderer.border.separator = TTY::Table::Border::EACH_ROW
|    end  #=> nil
+-------+-------+
|header1|header2|
+-------+-------+
|a1     |a2     |
|b1     |b2     |
+-------+-------+

I am using Ruby 2.6.2. and tty-table (0.10.0.

This is the first time I've tried the gem since upgrading to Ruby 2.6.2. I ran into some gem conflicts with version 1.5.0 of unicode-display_width. I had to uninstall it an reinstall version 1.4.1 in order to get tty-table to load into my IRB session.

@piotrmurach
Copy link
Owner

This option works when the renderer class is used as evidenced in tests. I'm rather busy now preparing to speak at a conference next week. When I'm back I will try to find some time to look at some issues in this gem. Do you have anytime to submit PR that fixes this?

Re unicode-display_width which is used by strings dependency. I will upgrade soon to remove such strict versioning.

@RylanBauermeister
Copy link

@MadBomber The render method seems to have some interesting behavior with regards to what it returns--if you store the rendered table into a variable then put it, it works.

@piotrmurach I'm a student with a pretty busy schedule, but I'll see if I can find a little time to address this. It's certainly good experience for me to hunt things like this down!

rendered = table.render(:ascii) do |renderer|
    renderer.border.separator = TTY::Table::Border::EACH_ROW
end
puts rendered

@RylanBauermeister
Copy link

Okay, I've found some weirdness here. It looks like the issue isn't actually in the function, but in how it is called in conjunction with puts. The block executes fine as this:

puts table.render(:ascii) { |renderer|
    renderer.border.separator = :each_row
}

If you run it as a do/end block, it ignores the function aspect and just calls table.render(:ascii). This feels more like a problem with ruby's base puts function than with TTY-Table to me, but is certainly worth noting.

@piotrmurach
Copy link
Owner

@RylanBauermeister good find! I wasn't aware of this behaviour.

@MadBomber I've released new strings version which should fix the issue with unicode_display-width compatibilities. You should be able to install the latest version.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants