Sensible Defaults | Hacker News Reader

Sensible Defaults

pgcli.com

74 pointsamjith27 comments

Filling the indent area with dots is not a sensible default IMO. Often when I work on a query I am going to reuse it in an application. If PgAdmin III or psql filled the indent area with dots then they would be included when I copied the query I'd written.

Even though I always reformat the query, and even though the text editor I use -- vim / neo-vim -- supports rectangular text selection, I would be annoyed at such dots.

That's good to know. Perhaps I should replace the dots with empty space. I'll do that if we get more requests for it.

Thank you for the feedback.

Empty space would be the better default I think yes.

Definitely empty space!

Same, dots are obnoxious when copy-pasting.

The Python REPL notoriously uses >>>/... like in the screenshot, ẃith the effect that e.g. IPython has a special paste-from-repl magic just to remove these.

The dots are my biggest gripe about pgcli. That would be an awesome change!

You can change this to an empty space via the config file right now. In ~/.config/pgcli/config look for continuation prompt and set it to empty string.

Don't want to pile on, but yes to empty spaces

While you are data gathering, I will half-vote the other way.

In VIM I make my whitespace visible, and just live with the consequences when I cut an paste. That said, I most of my empty spaces are still invisible, I only show tabs and trailing spaces.

Well, an editor should not copy whitespace visibility characters in the first place.

Or alternatively the prompt character could start on a new line. That way you can have smaller windows fit more query per line with less space wasted on white-space.

But in return you might use more vertical space, and with a terminal size of 80x24, vertical space is more precious.

With the "newline after prompt" scheme, you only get one extra line per query.

Which, if the query is long (e.g. longer than 20+ lines) it's not gonna make any difference anyway -- it's not like it matters if you can fit e.g. 24 or 23 lines of a 30 line query (besides, the result rows are gonna take much more vertical space, further making the measly 1 extra line issue moot).

As for for multiple small queries (and one extra line after each of those prompts), you can always scroll. And, again, the results are gonna take far more vertical space than the single extra line per prompt.

And, of course, with the full horizontal space available (and not half wasted by dots) you get to fit more characters in each line, and thus your queries will probably end up using FEWER lines.

So, not only the extra line from the "newline after prompt" is no big deal vertical-space wise, but the dot scheme wastes MORE vertical space AND renders queries unpastable.

Don't fill it with dots, use it. This is my shell prompt. I break after the '%', so that long commands use as much of a line as possible, and I break before the prompt, because I like to visibly separate operations.

  aaron@tesla ~ % 
  pwd
  /home/aaron
  
  aaron@tesla ~ % 
  cd Projects 
  
  aaron@tesla ~/Projects % 
  pwd
  /home/aaron/Projects
  
  aaron@tesla ~/Projects %

I do something similar which is based on the Cygwin default bash prompt:

    PS1='\033]0;${PWD}\n\033[32m${USER}@${HOSTNAME} \033[33m${PWD/${HOME}/~}\033[0m\n# '

Looks like:

    root@myhost.name /etc/httpd/conf
    #

This is what my shell prompt looks like:

    : stuff;

If you copy the entire line, stuff is arguments to the ‘:’ command, which does nothing. (This does mean stuff can't contain unmatched shell special characters.)

I think this was invented in the Blit era by someone I've forgotten.

Beyond "sensible defaults", it's also important to have the defaults specified sensibly. For robust application development, mainly when working with large software systems, I find it best to disallow "unset" configuration options and the implicit behaviour they entail. That is, every option must have its setting explicitly specified in the configuration. The defaults should exist as a "full" configuration, similar to the configuration file pgcli comes with. Unset configuration options result in a runtime error during application startup.

Also, I believe I first heard of pgcli from an HN comment, and since then I have been a daily user of it.

  Expanded mode in psql is a way to output the results of a
  query if the output is too wide to fit in the screen when
  shown as a table. This can be toggled by \x on or \x off.
  
  [...] In pgcli, we have the ability to do this but this is
  not enabled by default. It has to be enabled via the config
  file (~/.config/pgcli/config) by the user.
  
  I don't think we'll change this behavior.

Why not? Seems quite sensible a thing to do when the output otherwise wouldn't fit.

The reason being the format change will be jarring to someone who is not used to seeing the expanded mode.

But you bring up a good point. I'm not mired by maintaining legacy, so I could take this as an opportunity to educate users about the \x auto by enabling it as default.

This is a serious, genuinely curious and open-ended comment - I'm not arguing for a position here or making a point and can accept any response.

Do people here think the world would be a better place if installing something didn't require reading any documentation (not even 45 minutes of it) or necessarily spend any time making choices?

For example, if it were possible to requisition a new AWS instance and install a Ruby on Rails configuration with "sensible" defaults on it, in, say, < 30 seconds, and it being secure and properly configured so that a newbie without any experience can immediately deploy apps on it securely and without understanding the parts involved or making choices?

I can see arguments for both sides.

Sounds like https://zeit.co/now now you should find or create a Dockerfile that has the sensible defaults and you're good to go.

"Make a system any idiot can use and any idiot will."

The floor in user capabilities is low.

https://www.reddit.com/r/dredmorbius/comments/69wk8y/the_tyr...

Also: http://wiki.c2.com/?IdiotProofProcess

Actually a really nice command-line interface with autocomplete to postgres. I'm usually rapidly dissappointed with all the GUI offerings to Postgres so this is a breath of fresh air. Defaults definitely seemed reasonable as per TFA

I still think a Mathematica-eque workbook format (manipulable inline graphics and objects interspersed with regular REPL) would be the best of two worlds.

I think there are SQL backends for Jupyter and Zeppelin notebooks.

Oh, for a command-line SQL client.

I was expecting this to be about web pages.

"Yes, of course I want to sign up for your "newsletter" offering me the latest deals every hour on the hour!" Click on the invisible x to opt out. (Very Facebook.)

Reply on news.ycombinator.com