srsudar / eg

Useful examples at the command line.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Option to remove or squeeze blank lines

srsudar opened this issue · comments

I arbitrarily set the number of blank lines in examples based on what was easy for me to visually parse with and without color. It's been pointed out by @cool-RR that this might be gratuitous and not the best use of screen real estate.

I like the idea of a --squeeze option that removes some of the blank lines. I'm not sure the best way to do this. Some output options I might like to support are:

1: a single blank line between all examples in a section, two lines between sections:

# tar

extract a file

    tar vfxz blah

show file contents

    tar vft blah

another example

    tar blah


# Basic Usage (notice two lines above this)

Blah blah blah.

2: Blank lines between sections, no blanks between examples (this might actually look terrible, not sure):

# tar

extract a file
    tar vfxz blah

show file contents
    tar vft blah

another example
    tar blah


# Basic Usage (notice two lines above this)

Blah blah blah.

Hmm, so maybe the places it would make sense to squeeze would be:

  • between sections (i.e. the things that begin with #)
  • within an example (although this might look ugly, as shown in number 2 up there)
  • between examples (as shown in number 1)

I'm trying to think of ways that would make sense to specify this. Maybe something like --squeeze to make everything one line, and something like --squeeze [0, 1, 2] to put 0 blank lines within an example, 1 between examples, and two between sections, if we wanted to keep it highly customizable. I like some of the blank lines and don't want to throw them out entirely.

I would go with the second output option.
In my opinion it goes better with the eyes.
I find it easier to "catch" a relevant example with less blank lines, since the output is colored, which is a really good eye-catcher.

About the feature, sounds very interesting, but I would go with a binary (on / off) option for convenience.

Do people have opinions on these two? The easiest way to explain --squeeze would just be to say it ensures no more than a single blank line at a time. I still am partial to the more spacious output, myself. Do people that want --squeeze think one would be stronger than the other?

No more than one blank line:
screen shot 2015-05-10 at 8 24 33 pm

Two lines between sections:
screen shot 2015-05-10 at 8 28 18 pm

I like the second example better.

Sent from my phone.
On May 11, 2015 06:37, "Sam Sudar" notifications@github.com wrote:

Do people have opinions on these two? The easiest way to explain --squeeze
would just be to say it ensures no more than a single blank line at a time.
I still am partial to the more spacious output, myself. Do people that want
--squeeze think one would be stronger than the other?

No more than one blank line:
[image: screen shot 2015-05-10 at 8 24 33 pm]
https://cloud.githubusercontent.com/assets/6362625/7558220/3e4eb176-f754-11e4-815d-56183ded5490.png

Two lines between sections:
[image: screen shot 2015-05-10 at 8 28 18 pm]
https://cloud.githubusercontent.com/assets/6362625/7558221/3e4fdace-f754-11e4-8311-25914b4e1050.png


Reply to this email directly or view it on GitHub
#20 (comment).

I also lean toward the second example.

Cool, that's the one we'll support out of the box. I'm also going to add a way to apply whatever you want to it, in case you really hate the default output. I'm adding a substitutions section to the egrc that lets you apply whatever regex-based substitutions you want. If you hate the 4-space indent, for example, you can add:

[substitutions]
remove_indent = [r'^    ', r'']

This would find all '^ ', which matches four spaces at the beginning of a line, and replace it with the empty string, removing indents.

The number of people that would kill to use this feature is probably small, but it will let people have a lot of say over how they want it displayed. It could even be used to extend or replace the default coloring mechanisms.

This is implemented in the tip and will be included in the next release. If someone finds problems, let me know.