Viebrc format discussion

[txgk]

It seemed to me worth discussing the state of the format for config file (viebrc) of Vieb.

Currently Vieb is parsing the config in a format that resembles Vimscript, but does not support most of its features. The path of such imitation may require further compliance with the Vimscript functionality, which is quite a lot of work. Another way is to uncompromisingly continue using a cut-down version of Vimscript, which may seem like a flaw to some. My suggestion here is to convert the config file format to pure JavaScript. I think that with this approach we can simple include JavaScript file (presumably viebrc.js, to avoid compatibility issues) and its configuration would immediately load in at startup without the need to parse pseudo-Vimscript. Old format of viebrc could be left with deprecation mark for a couple of next releases.

Here are a few pros and cons that I managed to come up with:

Pros:

• more flexible ways to customization
• much less code to process config
• potentially faster launch times
• lack of a short-term deception among new users that Vieb can be configured just like Vim

Cons:

• more code to process config
• need for basic knowledge of JS for configuration
• lack of a short-term happiness among new users that Vieb can be configured just like Vim

I hope I was not too hard about current config implementation :D I just want to know maybe there's someone else think that the current state can be improved and discuss the issue.

[Jelmerro]

Hey, thanks for the suggestion, I think this could be an idea worth pursuing, but allow me to explain a few things about Vieb and the current state of things.

You are correct to say that the current viebrc is not as cool/useful as a vimrc, but I do want to improve that over time. That will take a lot of time, but it is the path that is currently being followed. This is because in the past it was configured in JSON, and there were frequent requests to change this to a more vim-like format, hence this change.

As for "making things more flexible", it really depends on what new format we would pick. For example JS, would either mean we parse the file as is and look up exported things for stuff like settings, or that we would allow this config code to modify Vieb's existing code, which is a whole new level of customization that needs way more documentation than what would be human readable. It would also mean, that unlike what is currently the case, Vieb would no longer be easily usable for Vim users who do not program in JS. This might not seem like a big thing, but as mentioned, I have in the past had users complain that they did not know any JSON and that configuring Vieb is difficult for them, so I would imagine this to be a whole lot worse for JS, which is not just a common config format but an entire programming language that not everybody uses or even knows about.

Unlike what you are suggesting regarding the amount of code, changing this format would actually mean more code, because currently the command mode parsing is the same as that of the config file parsing, so there is little code duplication there. Introducing more ways to say/configure the same thing, instead of using the same syntax across command mode/vimrc mean more code, not less, and it also means more work for the user to understand and translate between these different config methods.

I can't comment on faster launch times, but parsing the viebrc file vs parsing a single JS file does not seem like it would really make much of a difference, if anything, parsing full JS sounds like more work/slower than parsing the commands line-by-line directly as they are read. Besides, parsing the config is only a tiny tiny fraction of Vieb's startup time, most of it is spend on spinning up Electron, initialization of the modules and starting all the tabs/webviews.

Finally (just for completeness sake in case it was not obvious), things that are too complex to be in this viebrc file regardless of syntax are already being done outside of it. For example, it does not make much sense to have to add lots of CSS inside the viebrc file and inject it into the right pages at the right time, so instead, you can enable the userstyle setting, and it will read separate CSS files outside of the datafolder and inject them into the right page by filename or globally. The same is true for blocklists (see adblocker), and even for internal files/folders like favicons, *hist files, tabs and the windowstate info. None of these things need to be inside the config file, nor do they need to be using this partial vimscript syntax, so they are just separate files that have their own specific syntax/language, most of the time (especially for internal files) this means JSON. Though I will always consider adding a complex new config method to the viebrc file, if there is a clear match in vimscript that we can re-implement or re-purpose for Vieb.

I hope that I too was not too harsh in my comment, I merely want to explain why Vieb is using the config format it currently does. In short, it's because we had something that wasn't Vim-like in the past, and people didn't like that. Now the config is similar, which also means that the implementation is simple, as it's just a startup version of command mode but line-by-line out of a file instead of with user input.

[txgk]

Thanks for such a detailed explanation, this cleared up a lot of my misunderstandings about Vieb :)

I completely forgot that you also need to parse the settings in the command mode. In this case, the reduction of the codebase cannot be achieved of course. Also, I wasn't aware of history of JSON config and people's complains about alienation of this format from Vim stuff. This must make the format transition even more rigorous, as deficiencies that have occurred in the past must be unconditionally resolved now to do the transition again.

As for launch times, it seems to me that if, say, in one case you need to set the value of a variable, and in the other, first process the line and only then set the value, then the latter will be at least a little slower. I do not take into account the processing speed of the JS interpreter itself, because as far as I know in both cases it works about the same. But as you already said, such a small benefit is not worth the problems that JavaScript format will cause (I updated pros and cons listing).

For me personally, the question of switching to a new format is closed. Although Vimscript is not quite complete right now, the problems that other formats cause outweigh their small advantages. I think we should keep this issue open for a while in case someone wants to drop some thoughts in :)

[Crandel]

Personally I would like to have js config, because it's much easy to understand, than vimscript. I have no idea how can complain about json config, because vimscript format is terrible. No arrays, variables and much much more things make it very primitive. Qutebrowser for example let you use Python and this is a huge advantage.

[Jelmerro]

After implementing userscripts recently, I was painfully made aware how hard it is to make a secure implementation for executing JavaScript, without directly using eval to do it. The only alternative is writing a limited JS parser, both of which options seem like a hack for writing config in a language that was never meant to be used for configuration. The obvious alternative here is JSON, which can be easily and safely parsed with JS, so as a result, it seems like the correct choice to be introducing JSON as an alternative config option, while keeping the existing viebrc for most of the more complex options. I am willing to continue discussing this, but unless you can suggest a better way to parse JS without actually running it directly inside Vieb it will not be considered for security reasons.

[txgk]

I'd like to point out that I'm trying to convey the idea of Vieb's more minimalist approach to handling configuration. If JSON sooner or later becomes the only possible configuration method, thereby replacing the more difficult to process pseudo-VimScript (gradually, with a period of deprecation); I wholeheartedly like it. However, if JSON becomes an alternative format alongside VimScript, then this configuration approach, in my opinion, will not improve the situation.

[Jelmerro]

You can choose not to use the viebrc configuration at all, but you will need it for mappings and custom commands. The settings will however be optionally configured with JSON. Both configuration types will be maintained.

[Jelmerro]

@txgk You mention that it will not improve the situation to have both, what exactly do you mean with that? I am willing to add JSON configuration options, but I won't remove the vimscript method, since that's kind of the point of making Vieb in the first place. You are using a Vim inspired browser, both the commands at runtime and the configuration method represent that. What would be the problem of having JSON as an alternative next to that? Or in other words, how should a JSON configuration work according to you?

[txgk]

I didn't mean to sound as negative nancy - if you, as the creator of the project, see it as an improvement, it probably would be illogical to rely on the opinion of only one user and it is better to do as you see. However, it seems to me that this will not improve the situation, because, simply, will increase the code base with functionality, which is essentially of secondary utilitiness. I understand that such a minimalistic approach on the one hand is not very rational, given the current situation with the Web, but personally, as a suckless approach lover, I would be a little more pleasant to use a program in which each line tries to carry the greatest specific utility.

PS: I created this issue discussing replacement config format, not taking into account that the configuration commands has to be executed at runtime, hence this Vimscript is necessary and cannot be replaced; so, for me, this issue was closed after you pointed out that to me.

[Jelmerro]

In that case, I would like to thank you all for participating in this open discussion about additional config formats, but I'll be closing this as a won't fix, as requested. For those that desperately need/want JSON configuration, feel free to fork Vieb and do something like this:

diff --git a/app/renderer/settings.js b/app/renderer/settings.js
index 3ba7f56..21d3763 100644
--- a/app/renderer/settings.js
+++ b/app/renderer/settings.js
@@ -34,7 +34,8 @@ const {
     pathExists,
     pathToSpecialPageName,
     appConfig,
-    userAgentTemplated
+    userAgentTemplated,
+    readJSON
 } = require("../util")
 const {
     listTabs,
@@ -1156,8 +1157,24 @@ const loadFromDisk = (firstRun = true) => {
         set("permissionmediadevices", "allowfull")
         set("permissionmicrophone", "allow")
     }
-    for (const conf of files) {
-        if (isFile(conf)) {
+    for (const conf of files.filter(isFile)) {
+        if (conf.endsWith(".json")) {
+            const parsed = readJSON(conf)
+            if (!parsed) {
+                notify(`Read error for config file located at '${conf}'`, "err")
+                continue
+            }
+            Object.keys(parsed).forEach(key => {
+                const value = parsed[key]
+                if (listLikeTilde.includes(key) && Array.isArray(value)) {
+                    set(key, value.join("~"))
+                } else if (listLike.includes(key) && Array.isArray(value)) {
+                    set(key, value.join(","))
+                } else {
+                    set(key, value)
+                }
+            })
+        } else {
             const parsed = readFile(conf)
             if (!parsed) {
                 notify(`Read error for config file located at '${conf}'`, "err")
diff --git a/app/util.js b/app/util.js
index f5fb4ca..6df1916 100644
--- a/app/util.js
+++ b/app/util.js
@@ -643,7 +643,11 @@ const appConfig = () => {
                 files = [datafolderConfig, userFirstConfig, userGlobalConfig]
             }
         }
-        configSettings.files = files
+        configSettings.files = []
+        files.forEach(file => {
+            configSettings.files.push(`${file}.json`)
+            configSettings.files.push(file)
+        })
         configSettings.config = configSettings.override || datafolderConfig
     }
     return configSettings