Superpositon logic of --remote, --eval, --load and --quit flags

[aadcg]

#2759 introduced very interesting changes to control Nyxt remotely.

Issuing nyxt --remote starts a Nyxt interpreter. I think nyxt --remote --load ... and nyxt --remote --eval... should presuppose the use of --quit, even when omitted, since that's the behavior users expect. For more context see this thread.

CC @Ambrevar

[Ambrevar]

This is by design: if we presuppose --quit, there is no way to remote-eval without quitting.
I can imagine some users would like to drop to an interpreter after loading or evaluating, it's common to do this for many interpreters.

[aadcg]

I see the use case of entering the interpreter after loading or evaluating, but I don't think it should be the default behavior.

Nonetheless, I don't think this is very important so I'm closing it.

[aartaka]

I see the use case of entering the interpreter after loading or evaluating, but I don't think it should be the default behavior.

So the problem with --remote is that it's quite a special mode of operation. It's not controlled by the user, and is only controlled by the script you provide it. What should it do when there's no script? Making it behave like a REPL is somewhat an arbitrary choice, yes. But it's better than hanging due to absence of script file.

Default behavior of --remote is having a script. --remote without script argument is not an intended use at all, thus our use of the REPL instead.

And, given that there are people wanting a mechanism for direct communication with Nyxt from the shell—we also cover their needs, which is a win-win 😛

[aadcg]

@aartaka either I didn't follow you or you didn't follow me.

My point was simple: nyxt --remote --eval/--load foo should not drop the user in the interpreter. It should be equivalent to issuing nyxt --remote --eval/--load foo --quit, i.e. eval/load foo and exit.

nyxt --remote should drop the user in the interpreter.

[aadcg]

Re-opening since one of our users concurs with me. I need a good argument against it. Who can deliver it?

if we presuppose --quit, there is no way to remote-eval without quitting

I'm not convinced by this, since if the user wants to have the interpreter at his disposal, then we would most likely prefer to pass --remote alone.

[aartaka]

I'm not convinced by this, since if the user wants to have the interpreter at his disposal, then we would most likely prefer to pass --remote alone.

Not really. I'd expect --load/--eval to do some initialization before entering the --remote REPL. Doing the initialization when already in this REPL is non-automatable and too verbose in general.

[aartaka]

Re-opening since one of our users concurs with me. I need a good argument against it. Who can deliver it?

Their use-case is evaluating something and getting back the results, don't bend it where it's not. No more than that. It doesn't imply this or that behavior of --remote, it implies a certain behavior of --eval. I'm pretty sure they will be satisfied if --eval prints its results on the stdout. Which is #1453.

---

Note that the only reason linked topic mentions --remote is that you've mentioned --remote in the other thread. So it's not really about --remote itself, it's about a certian instance of --eval that happens to contain --remote.

[aadcg]

I'd expect --load/--eval to do some initialization before entering the --remote REPL.

If the user uses --load/--eval, what's the most frequent use case? Wanting to do just that and leave, or being dropped in an interpreter?

[aartaka]

Overall, I'd say that both are advanced and rare enough. If one wants to use them, then they are probably ready to pick the right combination of flags. We're providing enough options here, and all of them are suitable for the use-cases there are, even if with a couple of flags more.

[Ambrevar]

I agree with @aartaka last assessment: we're talking advanced features here, and the "most frequent use case" is highly debatable.

Going with @aadcg's suggestion would mean introduce a new CLI flag for debatable benefits.

[aadcg]

we're talking advanced features here, and the "most frequent use case" is highly debatable.

I still think that we're not listening to our users enough, but let's continue to think it's debatable. Should we get feedback in the future on this topic, we should re-think it.

Going with @aadcg's suggestion would mean introduce a new CLI flag for debatable benefits.

I don't think I've suggested that. I said that nyxt --remote --load/eval ... should have the same semantics as nyxt --remote --quit --load/eval ...

Closing for now.

EDIT: I've written --server but meant --remote, as @Ambrevar noted below.

[Ambrevar]

You're introducing --server, that's what I meant.

[aadcg]

That was an unfortunate mistake of mine. When I wrote --server, I meant --remote. I'll edit above.

Regardless, this is closed.