SpartanJ
Open files in same window instead of always using a new window
The application currently always opens a new instance when a file is opened from the file explorer or any place outside the current application instance. It would be desirable to have the option to open new files in the currently running instance.
What will happen if two instances of ecode launched at the same time? ecode will overwrite config files when exit. I can't imagine how it will be like. This is the reason why I only drag files into ecode to open instead of associate the file extensions with ecode. I want to ensure that only a single instance of ecode is running.
ecode will overwrite config files when exit. I can't imagine how it will be like.
Correct, ecode saves the editor settings on close, so last ecode instance closed will mandate. It's not very problematic since project settings do not overlap. I use multiple instances every day without any issues :shrug: (that's actually the way I develop, one instance per repository). Plugin settings already work properly for multiple-instances (if settings changes, plugin will reload automatically), but app settings are not doing that currently due to various reason (I think that it could be annoying on some cases, and requires some code refactor).
ecode works as a single-instance application in macOS due to OS design and I personally don't like it much. This feature will be implemented as something optional.
This is the reason why I only drag files into ecode to open instead of associate the file extensions with ecode. I want to ensure that only a single instance of ecode is running.
I think that there's an intermediate solution / implementation for this. Maybe don't work as a single instance but if user request to open a single file and there are already other instances of ecode running, the new spawned process could redirect the file open request to the latest ecode instance and open it there (the new ecode instance will not create any window, will just redirect and terminate). And if the user request to open a folder it should open on a new instance. Now that I'm thinking it a little more I think this is the best solution.
How does ecode react if the config files of it are modified by an external process? How can it lock the resources if another process has already locked them? Is this undefined behavior?
I think that there's an intermediate solution / implementation for this. Maybe don't work as a single instance but if user request to open a single file and there are already other instances of ecode running, the new spawned process could redirect the file open request to the latest ecode instance and open it there (the new ecode instance will not create any window, will just redirect and terminate). And if the user request to open a folder it should open on a new instance. Now that I'm thinking it a little more I think this is the best solution.
How can it know what the latest instance is? Doing something funny and antivirus software will flag your program as malware. You can't have the best of both worlds. I think you would better invest on how to make it safe to operate in multi-instances mode instead of making it single-instance.
How can it know what the latest instance is? Doing something funny and antivirus software will flag your program as malware.
Not at all, all OSes provide a public API to get that information (it's super basic, ex: Windows uses GetProcessTimes, Linux you just need to query /proc/${pid}/stat and macOS is just proc_pidinfo). So basically you first need to get the process id of the processes with some specific binary name and then query the creation time. It's simple although you'll have an specific implementation for each OS. Antivirus software does not care or work that way at all.
You can't have the best of both worlds.
It's possible to implement it, so I don't agree.
I think you would better invest on how to make it safe to operate in multi-instances mode instead of making it single-instance.
Depends on your interpretation of "safe", it's perfectly safe for me now. If I decide to reload settings on change on all instances they will be in sync, it's just that I'm not sure if I want them to sync, I'll think about it.
Depends on your interpretation of "safe", it's perfectly safe for me now. If I decide to reload settings on change on all instances they will be in sync, it's just that I'm not sure if I want them to sync, I'll think about it.
Please correct me if I'm wrong. I guess currently it works like this: ecode takes a snapshot of the config files then settings modified when it's running will be saved in this snapshot, and when exit it will sync the config files on disk with this snapshot?
If this is the case, then everything is perfectly safe. It will work as you said: the config files on disk will be overwritten by the last closing instance. Since the config files are not locked, there will be no locking problems. Btw, I don't think you should bypass the snapshot and sync directly to the config files on disk.
Please correct me if I'm wrong. I guess currently it works like this: ecode takes a snapshot of the config files then settings modified when it's running will be saved in this snapshot, and when exit it will sync the config files on disk with this snapshot?
That's correct.
Implementation is in progress, currently is implemented and tested for Windows and Linux here, pending to test the rest of the OSes to test (implementation is there, not sure if works).
Please stop calling this as single instance because it's not only confusing but also wrong. This is obviously not single instance. Reuse the most recent instance is better reflecting the reality here.
I just changed it to "Open Files in New Window" with the inverted logic than the current (single instance = not open files in new window). This is how is called in vscode and sublime_text, so I'll try to use the more universal naming for this feature.
If you're using nightly you'll have to reconfigure this option if you want to always open in a new window.
What is confusing you? I just changed the feature name to match popular editors.
OK. I got it. Sometimes I'm really bad at reading English. It's not my native language.