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

Config (r)evolution #499

Closed
The-Compiler opened this issue Feb 2, 2015 · 106 comments
Closed

Config (r)evolution #499

The-Compiler opened this issue Feb 2, 2015 · 106 comments

Comments

@The-Compiler
Copy link
Member

@The-Compiler The-Compiler commented Feb 2, 2015

Having the config in an .ini-like format might be a bad idea. Things like per-domain configs would probably be a lot easier in YAML...

Some links:


See this proposal for more information about what the exact plans are for this.


Note: There's currently a Kickstarter campaign running with the goal of finally making this happen!

@The-Compiler The-Compiler self-assigned this Feb 2, 2015
@The-Compiler The-Compiler added this to the v0.2 milestone Feb 2, 2015
@pedromj
Copy link

@pedromj pedromj commented Feb 3, 2015

I think this is a good idea but you have to "budget" the effort and weight it against the benefits.

@avelino
Copy link

@avelino avelino commented Feb 3, 2015

+1

The-Compiler added a commit that referenced this issue Feb 4, 2015
@The-Compiler
Copy link
Member Author

@The-Compiler The-Compiler commented Feb 4, 2015

I believe the effort is neglible if you put it in perspective with how many hours I've put into qutebrowser so far, and how many more I probably will. I still believe in using the best tool available for the task at hand - and I think now I realized there's a better tool, and it's much more future-proof for the config.

I started the sessions branch (see #12) and I decided I'll use yaml for the session files, as using ini for that is definitely too cumbersome. I'll get more familiar with yaml/PyYAML there, and if it feels right, I'll convert the config stuff to yaml as well after sessions are done.

The-Compiler added a commit that referenced this issue Feb 5, 2015
The-Compiler added a commit that referenced this issue Feb 8, 2015
@traverseda
Copy link

@traverseda traverseda commented Feb 9, 2015

I personally like prettified json. It's generally not too painful to edit, it's dead simple, and if you use it via an import then it's a pretty good place to implement a bit of custom deployment logic. Instead of having settings.yaml or settings.json, you have a settings.py with some inline json.

It works fine for projects like django, scrapy, awesomewm... Really it depends on your target audience. If you're expecting mainly programmers, then I wouldn't expect there to be any problem with a .py config file, and you'd probably get clearer error messages.

I wouldn't mind taking a crack it it if you think it's a viable direction going forward.

@The-Compiler
Copy link
Member Author

@The-Compiler The-Compiler commented Feb 9, 2015

@traverseda
Copy link

@traverseda traverseda commented Feb 9, 2015

Makes sense to me.

The-Compiler added a commit that referenced this issue Feb 15, 2015
The-Compiler added a commit that referenced this issue Feb 16, 2015
Closes #12.
See #499.
See #11.

This adds PyYAML as a new dependency.

It adds the following new commands:

    :session-delete <name>
    Delete a session.

    :session-load <name>
    Load a session.

    :session-save [<name>]
    Save a session.

    :wq [<name>]
    Save open pages and quit.

And the following new settings:

    general -> save-session:
    Whether to always save the open pages.
@The-Compiler
Copy link
Member Author

@The-Compiler The-Compiler commented Feb 18, 2015

It might also make sense to add some dependency to validate the structure of the yaml files.

Possibilities:

@The-Compiler
Copy link
Member Author

@The-Compiler The-Compiler commented Feb 25, 2015

Retargeting this to v0.3 as I really want to get v0.2 out at some point...

Some ideas about the general structure:

config:
    foo: bar
    baz:
    - value
    - with
    - list
    - type
    ...

keys:
    d: close
    ...

domain http://www.qutebrowser.org/:
    config:
        foo: fish
    keys:
        bar: fish

Then we could also easily split the config into multiple files. It probably makes most sense to have a config.yml, keys.yml and perdomain.yml or so.

@The-Compiler The-Compiler modified the milestones: v0.3, v0.2 Feb 25, 2015
@Ram-Z
Copy link
Contributor

@Ram-Z Ram-Z commented Feb 25, 2015

What about using a list for per-domain settings?

domains:
- qutebrowser.org:
    config:
      foo: fish
    keys:
      bar: fish
- .*\.google\.com:
    config: { foo: baz }
@Ram-Z
Copy link
Contributor

@Ram-Z Ram-Z commented Feb 25, 2015

I would prefer separate files.

@The-Compiler
Copy link
Member Author

@The-Compiler The-Compiler commented Apr 23, 2017

No need for a separate method - we could simply check whether we get a string or a compiled regex object.

I expect there to be a lot more lookups for per-domain javascript settings, but I guess you'd typically do them via the GUI (with a keybinding) in autoconfig.yml, and those can be O(1) (with a lookup per subdomain).

@AeliusSaionji
Copy link
Contributor

@AeliusSaionji AeliusSaionji commented Apr 30, 2017

Actually, I do have one thing to say about configs: whatever you choose, I want to be able to source other config files from within my config.

In my personal dotfiles, I will have a qutebrowserconfig which contains nothing more than my deviations from default.

For example,

configitem1=true
configitem3=false
source /usr/share/qutebrowser/config

Please do not make me import an entire qutebrowser config into my git and then have me track/commit changes as the upstream config file changes.

@rcorre
Copy link
Collaborator

@rcorre rcorre commented Apr 30, 2017

@Link-Satonaka: based on the proposal, there will no longer be a file pre-populated with all the settings:

By default, those files are missing/empty, and the built-in defaults get loaded

@The-Compiler
Copy link
Member Author

@The-Compiler The-Compiler commented Jun 6, 2017

What I haven't really talked about above is how the commands will look to edit some more complex setting types (like lists or dictionaries) from qutebrowser.

Things which used to be a section (like searchengines) will now be a dictionary, and the bindings probably will too. There are also various things like hints -> prev/next-regexes which will actually be stored as list.

My current idea how to handle this is to add a few new :config-* commands, with :set being an alias to :config-set because :set is just a common thing to have.

Setting

:config-set (aka :set) will take a JSON syntax to set the elements, and override any previous settings. Examples:

  • :set custom-headers '{"X-Answer": "42"}'

Adding

:config-add adds a new element to a dictionary or list.

Examples:

  • :config-add custom-headers X-Answer 42
  • :config-add searchengines wiki https://en.wikipedia.org/wiki/{}
  • :config-add next-regexes weiter

Removing

:config-remove removes an element by key (dicts) or value (lists).

Examples:

  • :config-remove custom-headers X-Answer
  • :config-remove searchengines wiki
  • :config-remove next-regexes weiter

Replacing

:config-replace searches an element as per above, and replaces the value.

Examples:

  • :config-replace custom-headers X-Answer 23
  • :config-replace searchengines wiki https://de.wikipedia.org/wiki/{}
  • :config-replace next-regexes weiter [Ww]eiter

Thoughts? Any other modifications which should be supported?

@lamarpavel
Copy link
Contributor

@lamarpavel lamarpavel commented Jun 9, 2017

Is the difference between :config-add and :config-replace just a check for existing entries?

@The-Compiler
Copy link
Member Author

@The-Compiler The-Compiler commented Jun 9, 2017

@lamarpavel Hmm, good point - I guess it'd be fine for :config-add to just replace existing values. (so: yes)

@lamarpavel
Copy link
Contributor

@lamarpavel lamarpavel commented Jun 9, 2017

Yeah, I think it would be better just to have :config-add, maybe with an (optional?) warning for existing entries.

@The-Compiler
Copy link
Member Author

@The-Compiler The-Compiler commented Jun 9, 2017

Since this will be a breaking change, I'd also like to take the opportunity to reorganize the config to make things clearer - I'd really like some input on that! See #2708.

@The-Compiler
Copy link
Member Author

@The-Compiler The-Compiler commented Jul 6, 2017

So this issue has gotten way too big - thanks for all your input! I've read through everything again, and then split it into smaller issues:

  • YAML config (autoconfig.yml): This is now implemented in the new-config branch. There'll still be some breaking changes, but it's by all means ready to play with, if you want to test it. It leaves your old config untouched. I'll also add a new post to the qutebrowser blog with a few more details.
  • Python config API: See #2795 (with a completely new API proposal)
  • config.rc: See #2796 (my stance is still "probably not going to happen", FWIW)
  • Per domain settings: See #27
  • New :config-* commands: See #2794 (with some new commands added)
  • Per tab/window settings: See #2314
@The-Compiler
Copy link
Member Author

@The-Compiler The-Compiler commented Sep 16, 2017

Quick update: The new-config branch is merged 🎉 A more detailed update will probably follow in the blog over the next few days.

@Cloudef
Copy link

@Cloudef Cloudef commented Dec 9, 2017

Can't say I'm happy with no tools for migrating the old configuration.
EDIT: Maybe there could be a python module to read the old configuration syntax from file and apply it?

@rcorre
Copy link
Collaborator

@rcorre rcorre commented Dec 9, 2017

There is, if I remember correctly, a page that shows the diff between your config and the default config. It only took me a few minutes to port the diff to the new config, and the manual process helped me learn the new config syntax. I prefer that to having some generated file I don't understand.

@mschilli87
Copy link
Contributor

@mschilli87 mschilli87 commented Dec 9, 2017

@The-Compiler
Copy link
Member Author

@The-Compiler The-Compiler commented Dec 9, 2017

An automatic migration also isn't really possible, as things changed in various ways (not only e.g. name changes), and the old config also had default setting values in it (plus defaults changed), so you can't really know automatically what the user intended to change and what not.

@Cloudef
Copy link

@Cloudef Cloudef commented Dec 9, 2017

@mschilli87 Yeah, I know about that. It helps, but there's quite a bit of those changes.
@The-Compiler I see, that's a bummer

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.