Mouse not disabled on 2nd elinks instance

[TAAPArthur]

In my config I have set ui.mouse_disable = 1
When I open elinks the mouse is disabled. Now if I open a second instance the config file isn't read the 2nd instance has mouse support.

In another experiment, I added some garbage to the config and opened 2 elink instances. Only the first one complained. Is there a reason non-master instances don't read the config file?

$ elinks --version
ELinks 0.15.0
Built on Dec 31 2021 16:08:30

Features:
Standard, No Backtrace, IPv6, gzip, bzip2, UTF-8, Periodic Saving,
Viewer (Search History, Timer, Marks), Cascading Style Sheets, Protocol
(Authentication, File, FTP, HTTP, URI rewrite, User protocols), SSL
(OpenSSL), MIME (Option system, Mailcap, Mimetypes files), LED
indicators, Bookmarks, Cookies, Form History, Global History, Goto URL History

[rkd77]

By default new ellinks connects to old elinks instance. I guess it is the case here. See man page, fragment about sessions.
Note, that you can change options in Options manager (o).

[rkd77]

Sorry, I can see it now. On slave terminals options do not work. At at least ui.mouse_disable.
Need to find out way to pass info about disabled mouse to slave from master, or pass all options. It is not trivial.

[rkd77]

I have two ideas. Either load_config also in slave elinks instances. I don't like it. It does not have any advantages over elinks -no-connect. Second idea is to check for existence of file, for example ~/.elinks/mouse.lock . File would be created or deleted when option is changed. File exists - mouse disabled. If second option is acceptable, I can implement it.

[TAAPArthur]

Big disclaimer that I haven't looked at the source code thoroughly.

I would've thought just loading the config file in the slave instance would have been the most robust solution. The reason I didn't want to use the "-no-connect" option was because I would prefer to have runtime state synced.

To me personally, the mouse.lock solution is probably good enough.

On slave terminals options do not work. At at least ui.mouse_disable.

However it was unclear to me if this problem extended to other options

[rkd77]

User can make alias elinks="elinks --always-load-config 1" . I have no more ideas in this issue.

[TAAPArthur]

Could I trouble you again to answer some follow up questions.

• The ui.mouse_disable isn't special right. Other ui settings have the same drawbacks in that 2nd instances won't use non-default values.
• Why isn't --always-load-config 1 the default behavior? In the help text, you mention

Load config also for slave instances. Slower, but more robust.

Is it really noticeably slower. It would take a negligible amount of time to read and parse the text file. Is actually applying the setting that expensive?

I'm just trying to understand so I can justify the build options I package elinks with for my distro and/or explain workarounds

[rkd77]

2nd instance of elinks is "using" only some fragments of code mainly terminal related. The rest is handled by master session AFAIR. ui.mouse_disable is in the terminal related fragment. Other options might be accessed in main process, so there was no need to load config in 2nd instance.
--always-load-config 1 changes "behaviour", is not backward compatible. On today's machines it does not matter, but on older computers with slower disks, startup time slowdown might me be noticable.

[TAAPArthur]

Thanks for the clarification.