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

Ability to define the default settings #100

Open
ccoVeille opened this issue Apr 21, 2024 · 9 comments
Open

Ability to define the default settings #100

ccoVeille opened this issue Apr 21, 2024 · 9 comments
Labels
🕹 aspect: interface Concerns end-users' experience with the software ✨ goal: improvement Improvement to an existing user-facing feature 🟨 priority: medium Not blocking but should be fixed soon

Comments

@ccoVeille
Copy link
Contributor

Problem

I looked at the documentation, I thought I would be able to configure the way pls would be displayed without passing some options on CLI each time.

I thought it would be documented here https://pls.cli.rs/reference/conf/#app_const

Description

I found a lot of examples on how to customize the rendering of something, but not about setting via the configuration file the value that are described on this page

Did I miss something ?

Alternatives

create an alias to launch pls=pls --grid true

Additional information

@ccoVeille
Copy link
Contributor Author

Detail view:
  -d, --det <DETAILS>
          the data points to show about each node
          
          [default: none]

          Possible values:
          - dev
          - ino
          - nlink
          - typ
          - perm
          - oct
          - user
          - uid
          - group
          - gid
          - size
          - blocks
          - btime:  created at
          - ctime:  changed at
          - mtime:  modified at
          - atime:  accessed at
          - git
          - none
          - std
          - all

  -H, --header <HEADER>
          show headers above columnar data
          
          [default: true]
          [possible values: true, false]

  -u, --unit <UNIT>
          the type of units to use for the node sizes
          
          [default: binary]
          [possible values: binary, decimal, none]

Grid view:
  -g, --grid <GRID>
          display node names in multiple columns
          
          [default: false]
          [possible values: true, false]

  -D, --down <DOWN>
          display node names column-first
          
          [default: false]
          [possible values: true, false]

Presentation:
  -i, --icon <ICON>
          display icons next to node names
          
          [default: true]
          [possible values: true, false]

  -S, --suffix <SUFFIX>
          display node type suffixes after the node name
          
          [default: true]
          [possible values: true, false]

  -l, --sym <SYM>
          show symlink targets
          
          [default: true]
          [possible values: true, false]

  -c, --collapse <COLLAPSE>
          show dependent nodes as children of their principal nodes
          
          [default: true]
          [possible values: true, false]

  -a, --align <ALIGN>
          align items accounting for leading dots
          
          [default: true]
          [possible values: true, false]

I would expect to be able to change the default value via the configuration for any of these settings.

@ccoVeille
Copy link
Contributor Author

ccoVeille commented Apr 21, 2024

I mean I want file to be reported as grid via the configuration, unless I use pls --grid false

@dhruvkb
Copy link
Collaborator

dhruvkb commented Apr 22, 2024

That is a shortcoming in the documentation, and I should've been more clear about this but the idea is to definitely use aliases more. For example if you prefer grids, you can alias pls to pls --grid=true. For example, I have aliased ls to grid view and lsal to list view with details.

Screenshot 2024-04-22 at 9 13 43 AM

What are your thoughts on implementing a config file like ripgrep?

@ccoVeille
Copy link
Contributor Author

I find this strange. There are two main reasons:

  • you mention exa (now eza) was a pain as it relies on obscure env variables
  • you already have a configuration file.

I mean if someone want to use your tool, hr would expect to be able to change what you mention as being the default value via something else than the command line arguments.

If you had no configuration, I would have said, ok an alias maybe.

@ccoVeille
Copy link
Contributor Author

ccoVeille commented Apr 22, 2024

What are your thoughts on implementing a config file like ripgrep?

Many tools support this, yes.

Some others remove the training --, so the file becomes a valid .ini or .toml file

But I would find strange you implement something like this while you already have a pls.yml config file. Or maybe I misunderstood what you where suggesting.

@dhruvkb
Copy link
Collaborator

dhruvkb commented Apr 23, 2024

The issue here is that .pls.yml files are supposed to configure how pls works at a directory/repository level. If the settings controlled by pls's flags could be set in the .pls.yml file, it would mean that the same command would render differently for different directories which does not feel right.

@ccoVeille
Copy link
Contributor Author

Oh I didn't get that, it's clearer

But at same time, I hope you understand the problem I raised.

There is a config file, and there is no way to say I want to display a grid and disable icons by default.

@ccoVeille
Copy link
Contributor Author

ccoVeille commented Apr 23, 2024

So except something like PLS_DEFAULTS="--grid true --icons false" I don't see a solution

@dhruvkb dhruvkb added ✨ goal: improvement Improvement to an existing user-facing feature 🕹 aspect: interface Concerns end-users' experience with the software 🟨 priority: medium Not blocking but should be fixed soon labels Apr 24, 2024
@dhruvkb
Copy link
Collaborator

dhruvkb commented Apr 24, 2024

I see the value in your proposal so I'm going to triage this issue and think about an elegant solution. If you have recommendations, please post them here. In the meantime, please use aliases as a workaround for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🕹 aspect: interface Concerns end-users' experience with the software ✨ goal: improvement Improvement to an existing user-facing feature 🟨 priority: medium Not blocking but should be fixed soon
Projects
None yet
Development

No branches or pull requests

2 participants