Modify default directory/workspace behavior

[code-asher]

The current behavior uses this order:

1. Workspace query parameter.
2. Folder query parameter.
3. Last opened item (either workspace or folder).
4. Whatever was passed on the command-line (either workspace or folder).

Proposed behavior:

1. Workspace query parameter.
2. Folder query parameter.
3. Last opened item for that port (The default project directory seems to be not working correctly #1123)
4. Last opened item for any port.
5. Whatever was passed on the command-line.

The only remaining problem I can think of is that currently if you explicitly call code-server it'll favor the last directory instead of whatever you passed on the command line. It feels unexpected to me but we can't easily change that since if you run this in systemd for example you'd probably expect the opposite behavior when the service restarts (favor the last directory instead of what's passed to code-server).

[pocka]

Using last opened workspace/directory, in other words, ignoring a path which a user specified explicitly is quite strange and frustrating at least to me. This prevents me to use code-server as an alternative for vscode because code-server . won't work.

Although we could open a specific directory by passing query parameters, I don't think it's a solution for this problem:

• We are still unable to specify an opening directory from a terminal.
• AFAIK not a few people using code-server in Chrome's app mode (in ChromeOS it's a "shortcut" but idk its correct name) which wouldn't allow us to edit the URL.

The port methods you proposed might work for the use-cases like #1123 , but not for the others.

The most simple way I think is to make persistent behavior an opt-in feature, like this:

# sorry for messy naming...
code-server ./dirA # opens ./dirA
code-server ./dirB # opens ./dirB
code-server ./dirC --prefer-last-opened # opens ./dirB

With this strategy, you can both 1) specify which directory to open and 2) use the last opened directory if it exists, though I'm not sure this could be implemented.

[code-asher]

Yeah I was similarly frustrated when I was testing code-server locally but I wasn't sure it was a common thing because usually you would run code-server persistently on a remote machine, right? Is there a compelling use-case for spawning new instances of code-server on demand?

Soon we want to support opening things in existing code-server instances. That will use a flag so it'll be something like code-server -r file/dir and it'll use the running instance. So that might fulfill any need to run code-server on demand.

So I'm not sure yet if we should modify the default behavior since it means we'd have to make everyone aware they need to pass an extra flag (it's been my limited experience that users expect code-server to remember the last directory).

We could also go the other route with a --ignore-last-opened which would then force the value passed in on the command line (but only for the first launch, probably?). I suppose it then just comes down to what the more widely-expected behavior is.

[pocka]

Yeah I was similarly frustrated when I was testing code-server locally but I wasn't sure it was a common thing because usually you would run code-server persistently on a remote machine, right? Is there a compelling use-case for spawning new instances of code-server on demand?

I'm not sure too that launching instances on demand instead of persisting a single instance. My use-case is using code-server to "Run VS Code on a remote server" as the repo's description says. Start vscode on a certain directory by typing code . on the terminal, do editing in the vscode UI, then close the program (additional Ctrl+C required though). I hope this use-case isn't too weird...
NOTE: I use the simple script named code to launch code-server with fixed arguments, like --cert or --port.

So I'm not sure yet if we should modify the default behavior since it means we'd have to make everyone aware they need to pass an extra flag (it's been my limited experience that users expect code-server to remember the last directory).

To keep backward-compatibility, an opt-out flag you proposed (--ignore-last-opened) is the best approach for the problems IMO, which solves these without changing defaults. The flag opening the file in a running instance (-r) will be very useful, but it's not a solution for "I want to spawn an instance with the specific opening directory but cannot!", is it?

[code-asher]

Ahhhh I hadn't considered that type of workflow. That makes a lot of sense. If we had the -r flag you could just run a single persistent instance and use that instead which would fulfill your use case, right? Plus you'd use less memory if you need to open multiple things and you don't have to close it out like you mentioned.

But yeah, that's not a solution to forcing the directory on the command line to be opened. Maybe --ignore-last-opened is the best solution since like you mentioned it preserves backwards compatibility.

Or maybe we should just bite the bullet and always open what's on the command line. To be honest that feels like the better behavior to me but I don't want to break a bunch of people's workflow. We could have a --default-directory for when there is no last opened directory or a --prefer-last-opened like you suggested. 🤔

[pocka]

But yeah, that's not a solution to forcing the directory on the command line to be opened. Maybe --ignore-last-opened is the best solution since like you mentioned it preserves backwards compatibility.

Or maybe we should just bite the bullet and always open what's on the command line. To be honest that feels like the better behavior to me but I don't want to break a bunch of people's workflow. We could have a --default-directory for when there is no last opened directory or a --prefer-last-opened like you suggested. 🤔

I agree we should keep the current behavior not to break existing workflows 👍

---

I tried some text editors and see how they treat the input paths FYI (tested on Windows10).

• VSCode
  • code ... Opens last opened directory
  • code ./dir ... Opens ./dir
• Atom
  • atom ... Opens last opened directory
  • atom ./dir ... Opens ./dir
• SublimeText3
  • subl ... Opens last opened directory
  • subl ./dir ... Opens both last opened directory and ./dir (!)

[code-asher]

Thanks for testing that out! Sublime Text's behavior is interesting. :P I'm leaning toward just making code-server prefer the explicit command-line directory tbh since that feels more correct to me. Although it's a breaking change I think the impact is fairly small. One other possibility would be to try to detect if running in an interactive setting and if so prefer the directory on the command line, but I don't know how possible or reliable that is and it seems like it could result in unexpected behavior.

[Merith-TK]

• have this issue as well with a little more detail
  litterally copy/pasted

Version: 1.41.1
Commit: f51e045cd5483561afc07694f39307fb673b6d1d
Date: 2020-01-17T22:58:55.612Z
Browser: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.130 Safari/537.36
Code Server Version: 2.1698-vsc1.41.1

• Host: Archlinux

Description

When you start code-server, you can tell it to open a folder, this works well
the problem is when you change your active folder, and come in on a completely new device/setup, it will open the new folder instead of the specified one

Steps to Reproduce

1. code-server /workspace
2. open code-server in browser and change active workspace
3. close browser and come back later,
4. code-server will open the new workspace instead of the one it is told to have opened in the first place.

Thoughts

I have looked and currently there are no work arounds that i can find at this moment as the only possible workaround i have found, i dont know how to do just yet and that is to

1. set "window.restoreWindows": "none", in settings.json
2. make an extension that gets the current workspace path, if null or matches the default one code-server tells it, change folder to the wanted workspace

but again i dont know how to do this just yet and the idea wouldnt even work since code-server returns this when i try and use that config

EDIT:

Found an unfavorable workaround,
i modify the permissions and content of data/coder.json
to the following
{"lastVisited":{"path":"/Workspace/","workspace":false}}
and as root
chown root:root ./coder.json and chmod 644 ./coder.json

This appears to work because code-server can READ it, but not write to it,