As a user, I'd like fewer options for handling of web links, so it's easier to configure Bombadillo #86

New Issue

asdf · 2019-11-13T03:08:17Z

asdf commented

2019-11-13 03:08:17 +00:00

This is not urgent, I just noticed this and thought I would jot it down.

Handling of web links has three different settings, each being true or false. That's like...2 times 3...6 possible configurable states?

We currently only allow 3 states for actual handling of web links:

disallowed - links are not followed
allowed via default web browser
allowed via lynx rendering

All options are mutually exclusive, meaning there are...3?...more configurable states than necessary.

(I know we just changed all of this, but reviewing the documentation made me realise these might be confusing. Perhaps openhttp can control all states - none, gui and terminal? This would conflict with any plans to use XDG open for non-text data though.)

This is not urgent, I just noticed this and thought I would jot it down. Handling of web links has three different settings, each being true or false. That's like...2 times 3...6 possible configurable states? We currently only allow 3 states for actual handling of web links: - disallowed - links are not followed - allowed via default web browser - allowed via lynx rendering All options are mutually exclusive, meaning there are...3?...more configurable states than necessary. (I know we just changed all of this, but reviewing the documentation made me realise these might be confusing. Perhaps `openhttp` can control all states - none, gui and terminal? This would conflict with any plans to use XDG open for non-text data though.)

asdf added the

non-urgent

http

labels 2019-11-13 03:08:18 +00:00

sloum commented

2019-11-13 04:34:19 +00:00

The three settings are at least partially a holdover from using mailcap with gemini to open files. That was why terminalonly was a setting. I like the solution of none, gui, terminal for openhttp. My concern is as follows: it makes it less clear that lynx is required for loading in the terminal or that gui will use your web browser. We are currently using xdg-open for linux when opening web links in gui so it seems consistent sort of in that regard...

The three settings are at least partially a holdover from using mailcap with gemini to open files. That was why `terminalonly` was a setting. I like the solution of `none`, `gui`, `terminal` for `openhttp`. My concern is as follows: it makes it less clear that lynx is required for loading in the terminal or that `gui` will use your web browser. We are currently using xdg-open for linux when opening web links in gui so it seems consistent sort of in that regard...

sloum changed title from ~~As a user, I'd like less options for handling of web links, so it's easier to configure Bombadillo~~ to As a user, I'd like fewer options for handling of web links, so it's easier to configure Bombadillo

2019-11-13 05:59:27 +00:00

sloum commented

2019-11-14 03:00:19 +00:00

Per the comment I left in #87 I think a single config value, webmode, should be used. webmode can be an expandable option that is not a boolean value. I think switching to the aforementioned none (or maybe off or false), gui (or maybe xdg or webbrowser), and terminal.

lynx may be better than terminal to make it clear that lynx is required. I believe elinks and w3m also have -dump flags. I could see expanding the available web rendering backends in the future and using lynx would easily allow for us expanding into other areas. A raw mode could eventually be used as well where we just take the raw response and put it into a page struct.

Let me know what you think. I do not believe this would take much time. I worry that if we release before doing this then people will have confusing settings as, potentially, their first experience and then those settings will get all wonked when we update. It would be really nice to get it set before release.

Let me know your thoughts as I can see arguments for just sticking with what we've got and arguments for the above and a few other ideas are also floating around the periphery for me as well. So I'm open to other thoughts.

Per the comment I left in #87 I think a single config value, `webmode`, should be used. `webmode` can be an expandable option that is _not_ a boolean value. I think switching to the aforementioned `none` (or maybe `off` or `false`), `gui` (or maybe `xdg` or `webbrowser`), and `terminal`. `lynx` may be better than `terminal` to make it clear that lynx is required. I believe elinks and w3m also have `-dump` flags. I could see expanding the available web rendering backends in the future and using `lynx` would easily allow for us expanding into other areas. A `raw` mode could eventually be used as well where we just take the raw response and put it into a `page` struct. Let me know what you think. I do not believe this would take much time. I worry that if we release before doing this then people will have confusing settings as, potentially, their first experience and then those settings will get all wonked when we update. It would be really nice to get it set before release. Let me know your thoughts as I can see arguments for just sticking with what we've got and arguments for the above and a few other ideas are also floating around the periphery for me as well. So I'm open to other thoughts.

asdf commented

2019-11-14 06:10:40 +00:00

I had prepared a similar review, and I think we have come to the same conclusions.

The impact of changing this now will likely be lesser than the impact of confusing users before another update breaks their recorded settings.

I also prefer a single setting with multiple options, so that each mode is exclusive of the other.

Name	Setting	Behaviour
webmode	none	links are not followed
	gui(?)	links are opened in the XDG default web browser
	terminal(?)	links are rendered by lynx within the client

It is implied that if lynx is unavailable when configured, a message is displayed
If it also implied that if xdg-open is unavailable when configured, a message is displayed

Your suggestions for names seem pretty good, I'm having a hard time finding anything useful.

It would still be possible to configure the use of ~~xdg-config~~ xdg-open in a terminal-only environment, where it fails silently and creates a defunct process. It's a separate issue, but might be more pronounced in this configuration. I will look in to this some more.

I had prepared a similar review, and I think we have come to the same conclusions. The impact of changing this now will likely be lesser than the impact of confusing users before another update breaks their recorded settings. I also prefer a single setting with multiple options, so that each mode is exclusive of the other. | Name | Setting | Behaviour |---|---|--- | webmode | none | links are not followed | | gui(?) | links are opened in the XDG default web browser | | terminal(?) | links are rendered by lynx within the client * It is implied that if lynx is unavailable when configured, a message is displayed * If it also implied that if xdg-open is unavailable when configured, a message is displayed Your suggestions for names seem pretty good, I'm having a hard time finding anything useful. It would still be possible to configure the use of ~~`xdg-config`~~ `xdg-open` in a terminal-only environment, where it fails silently and creates a defunct process. It's a separate issue, but might be more pronounced in this configuration. I will look in to this some more.

sloum commented

2019-11-14 06:30:09 +00:00

I'm still not sure what you mean by xdg config. I am not generally familiar with what appears to be a family of xdg functionality. I need to read up on it. That said, our open in browser does currently use xdg-open, I'm not sure what other xdg stuff would be applicable, but def let me know if something makes sense that we are not currently doing.

I put together a branch that does the above except instead of terminal you put what rendering backend you want: lynx, w3m, elinks. none and gui are also available. I added the support needed to use any of the three terminal browsers to render so people can use whatever they prefer. I switched over our content type check to be native go rather than using -dump-head from lynx, so that simplified things (elinks does not have a dump head function, whereas the other two did). One note is that w3m does not provide links, just flat content output (but it looks really nice), the other two do provide links and are both parsed and work just how lynxmode was working.

I have not updated any docs but would do so before issuing an actual pull request. I wanted to run this by you and get your thoughts first.

Feel free to pull the branch: web-backends

Let me know what you thing :)

I'm still not sure what you mean by xdg config. I am not generally familiar with what appears to be a family of xdg functionality. I need to read up on it. That said, our open in browser does currently use xdg-open, I'm not sure what other xdg stuff would be applicable, but def let me know if something makes sense that we are not currently doing. I put together a branch that does the above except instead of terminal you put what rendering backend you want: `lynx`, `w3m`, `elinks`. `none` and `gui` are also available. I added the support needed to use any of the three terminal browsers to render so people can use whatever they prefer. I switched over our content type check to be native go rather than using `-dump-head` from lynx, so that simplified things (elinks does not have a dump head function, whereas the other two did). One note is that w3m does not provide links, just flat content output (but it looks really nice), the other two do provide links and are both parsed and work just how lynxmode was working. I have not updated any docs but would do so before issuing an actual pull request. I wanted to run this by you and get your thoughts first. Feel free to pull the branch: `web-backends` Let me know what you thing :)

asdf commented

2019-11-14 09:08:35 +00:00

Ah sorry to make this confusing! I wrote xdg-config but meant xdg-open, the command used to open a URL in another program. I looked in to the problem further and I don't think it will affect this, so I'll raise another issue.

Ah sorry to make this confusing! I wrote `xdg-config` but meant `xdg-open`, the command used to open a URL in another program. I looked in to the problem further and I don't think it will affect this, so I'll raise another issue.

asdf added this to the 2.0.0 milestone 2019-11-14 09:25:29 +00:00

asdf removed the

non-urgent

label 2019-11-14 09:25:44 +00:00

asdf commented

2019-11-14 10:25:37 +00:00

This is really impressive work. The additional browsers are a great addition and add a lot of choice in a really simple way.

Using native Go to get the content type seems to work better than the previous method. The site I tested HTTP redirection with previously now works really well.

I've tested it out in a few different ways (w3m does look really nice) and have made some changes in a new commit.

Errors returned from http.Visit in handleWeb were not being drawn - added c.DrawMessage()
Errors from http.Visit relating to w3m and elinks still said "Lynx error" - the error now prints the relevant webmode name.
elinks was missing from defaults.go comment/documentation, it is added

That was fun! Great job! I'm happy with the way this works.

This is really impressive work. The additional browsers are a great addition and add a lot of choice in a really simple way. Using native Go to get the content type seems to work better than the previous method. The site I tested HTTP redirection with previously now works really well. I've tested it out in a few different ways (w3m does look really nice) and have made some changes in a new commit. 1. Errors returned from http.Visit in handleWeb were not being drawn - added c.DrawMessage() 2. Errors from http.Visit relating to w3m and elinks still said "Lynx error" - the error now prints the relevant webmode name. 3. elinks was missing from defaults.go comment/documentation, it is added That was fun! Great job! I'm happy with the way this works.

sloum commented

2019-11-14 14:51:09 +00:00

Awesome. I'll get a pull request set up from work (just waking up right now). :) I'm glad you like it. I also thought it was fun and I really like that it gives users more choices without adding a lot of code.