Loading files when ui_one_instance is true

[tmsg]

I am not sure whether this is a bug, a feature or anything in between. The scenario is this:
1. I am in directory D with file A and a subdirectory E with file B.
2. My user.json has "ui_one_instance" : true
3. I load A into Cud with "cudatext -ns A" (instance 1 starts and loads A)
4. I do "cd E" and (try to) load B into Cud with "cudatext -ns B" (instance 2 is started (with working directory E) which tells running instance 1 to load B)
5. Instance 1 (with working directory D) produces a query whether I want to create file B... I assume it tries to load B from its own working directory D but B is in E.
6. This assumption is supported by the fact that starting the second instance with "cudatext -ns E/B" does work.

As the second instance has no idea what the working directory of the first instance is, the best (perhaps the only feasible) way to solve this seems to be for the second instance to convert the filename/path it's given into an absolute path and hand this path to the first instance.

I hope I am making myself clear.

[Alexey]

you are right, it is some issue, almost a bug, or a misfeature. yes, it must be fixed how you described.

[tmsg]

Happy to hear that.

As a matter of fact, I do have some ideas how the various modes (one instance or more, loading sessions or not etc) can be combined. Back in the mists of time when editors were for real men[tm] I used an editor called Brief. I never again found an editor that was so flexible when it came to starting sessions/loading files into various instances. I patched AkelPad in such a way that you could tell it on the command line which already running instance/session should receive a new file (basically via some trickery with window classes). I will think through this and present some ideas in due course (not very soon though ).

[Alexey]

tried to fix. seems issue is only on unix (unix version uses special one-instance code), and cannot easily fix it (code is not mine). ops.

[tmsg]

I'm not sure I understand this. You have instance 2 which certainly can transform a relative path into an absolute path. You have a way to send information from instance 2 to instance 1. So what exactly is the problem?

[Alexey]

problem: handling of command-line args is before Cud code, it's in TUniqInstance 3rd party code.

[tmsg]

problem: handling of command-line args is before Cud code, it's in TUniqInstance 3rd party code.

(Caveat: I have no looked into the source code. If the above means that literally no Cud code can run before TUniqInstance code is called (but then... who calls this code?) then the following is probably a daft idea.)

I assume at some point the second instance calls some code in TUniqInstance with an array containing the command line arguments it received. How about defining a private (ie internal to Cud) option, say -siwd= (siwd meaning "second instance working directory")... can't you just add -siwd="/home/me/some/path/where/Iwas/started" to the array of command line arguments the second instance has received and then let the TUniqInstance code do its job? If yes, then the first instance is called from the second with this additional private option (ie the working directory of the second instance) and can act accordingly.

[Alexey]

hmm. but UniqInstance don't get any array from me -

Code: Select all

  if not AppAlwaysNewInstance and UiOps.OneInstance then
    if not UniqInstance.Enabled then
    begin
      UniqInstance.Enabled:= true;
      TUniqInstanceHack(UniqInstance).Loaded;

      if UniqInstance.PriorInstanceRunning then
        Application.Terminate;
        //note: app still works and will get DoFileOpen calls (e.g. on session opening)
        //so later need to check Application.Terminated
    end;

he handles ParamStr.

[tmsg]

hmm. but UniqInstance don't get any array from me -
<snipped>
he handles ParamStr.

I see. But you do have the source of UniqInstance so unless you're unwilling to change it slightly you could easily add that feature.
TUniqInstance.Loaded has this call to send the actual parameters (uniqueinstance.pas, line 139):

Code: Select all

IPCClient.SendStringMessage(ParamCount, GetFormattedParams);

And GetGetFormattedParams (in uniqueinstancebase.pas, from line 39) simply concatenates all ParamStr(i)'s, separated and terminated by a simple '|'. (Actually this function has very brittle code if I may say so: it means that a | in a parameter (like -opt="this|that") will break the whole transmission scheme.)
If you are willing to adapt this TUniqInstance.Loaded slightly you could just add a single string parameter to TUniqInstance.Loaded and use this to add one (or even more) parameters :

Code: Select all

// In your code:
siwd='-siwd="'+currentworkingdirectory+'"'; // quotes if directory has spaces
TUniqInstanceHack(UniqInstance).Loaded(siwd);

In uniqueinstance.pas, line 139:

Code: Select all

IPCClient.SendStringMessage(ParamCount, GetFormattedParams + siwd + ParamsSeparator);

(Totally untested as I haven't written any Pascal code for decades.)
I assume you just don't want to change the code in uniqueinstance.pas as this seems pretty straightforward? Or am I missing something elementary?

[Alexey]

I see what you mean. it will be incompatible with UniqInstance from Lazarus online-package-manager so I need to rename UniqInstance (fork it)..... i dont want it yet