Size: 1977
Comment:
|
Size: 3417
Comment:
|
Deletions are marked like this. | Additions are marked like this. |
Line 19: | Line 19: |
Line 30: | Line 29: |
=== Proposal: allow _ and - anywhere === | In addition, having guideline for sections would be useful. In Mercurial core + bundle extension we have about 300 configuration option. They are spread in the following sections: {{{ 34 ui 28 convert 27 experimental 21 web 20 bugzilla 19 lists 13 notify 10 format 10 devel 9 values 9 profiling 7 server 6 smtp 5 worker 5 patchbomb 5 http_proxy 4 progress 4 mq 3 pager 3 histedit 3 factotum 3 eol 3 email 2 transplant 2 share 2 phases 2 paths 2 patch 2 merge 2 hostsecurity 2 gpg 2 fsmonitor 2 color 2 chgserver 2 bundle 2 blackbox 2 acl 1 win32text 1 win32mbcs 1 shelve 1 perf 1 keywordset 1 hook 1 hgk 1 fakepatchtime 1 fakedirstatewritetime 1 debug 1 cmdserver 1 censor 1 bookmarks 1 automv }}} There are *many* options is the `[ui]` section and many section with version few config. Gathering related option in the same config section have multiple advantage. The main one is that it gather the related option in the documentation improving discoverability. For the same reason, having too many option is the `[ui]` is drowning the important one in the help of more minor one. === Proposal for naming: allow _ and - anywhere === |
Line 57: | Line 114: |
=== Proposal: use {{{-}}} or {{{_}}} in config examples === | ==== Proposal: use - or _ in config examples ==== |
Line 63: | Line 120: |
=== Problems === | ==== Problems ==== |
Note:
This page is primarily intended for developers of Mercurial.
Configuration consolidation
Status: Project
Main proponents: DavidDemelier
This is a speculative project and does not represent any firm decisions on future behavior.
Make the .hgrc file more unified.
1. Goal
The goal of this project is to make a clear coding style regarding the .hgrc configuration options.
2. Detailed description
The current .hgrc configuration options is messed with many different styles:
- anoption (~ 192 options, many are unreadable)
- an_option (~ 8 options)
- an-option (~ 7 options)
Having a unified style makes the code cleaner, better integrated.
In addition, having guideline for sections would be useful. In Mercurial core + bundle extension we have about 300 configuration option. They are spread in the following sections:
34 ui 28 convert 27 experimental 21 web 20 bugzilla 19 lists 13 notify 10 format 10 devel 9 values 9 profiling 7 server 6 smtp 5 worker 5 patchbomb 5 http_proxy 4 progress 4 mq 3 pager 3 histedit 3 factotum 3 eol 3 email 2 transplant 2 share 2 phases 2 paths 2 patch 2 merge 2 hostsecurity 2 gpg 2 fsmonitor 2 color 2 chgserver 2 bundle 2 blackbox 2 acl 1 win32text 1 win32mbcs 1 shelve 1 perf 1 keywordset 1 hook 1 hgk 1 fakepatchtime 1 fakedirstatewritetime 1 debug 1 cmdserver 1 censor 1 bookmarks 1 automv
There are *many* options is the [ui] section and many section with version few config. Gathering related option in the same config section have multiple advantage. The main one is that it gather the related option in the documentation improving discoverability. For the same reason, having too many option is the [ui] is drowning the important one in the help of more minor one.
2.1. Proposal for naming: allow _ and - anywhere
Since we have a strong backward compatibility concern, I have a proposal that I saw in a software a long time ago. The idea is to allow adding any underscore or hyphens in options and they are simply removed when loaded from the configuration.
Example:
[ui] username = blabla
Is equivalent to
[ui] user_name = blabla
Or even to
[ui] us_er-na_me = blabla
When loading options, both underscores and hyphens will be simply discarded. This implementation will allow us renaming options in the .hgrc file without any restrictions and/or backward compatibility issues.
2.1.1. Proposal: use - or _ in config examples
While major options can be written in only one word, we should start using hyphens or underscores between words.
People who think that backgroundcloseminfilecount, graphnodetemplate, mergemarkertemplate are actually readable should consider stop programming.
2.1.2. Problems
Only options like post-<command> must not be mangled by the process of removing extraneous -_ characters.
What do to with them?
3. Roadmap
- Implement code to allow extra -_ characters