Cudatext: Two CudaText instances and history session.json

[xcme]

I allow CT to have multiple instances and got this situation today:

1. I had CT opened with many tabs, including unsaved tabs.
2. Then I opened one text file from third-party app context menu via "Open with" in CT. It started a new CT instance.
3. Then I closed the first CT instance.
4. Then closed the last one.

In result, the "history session.json" was rewritten by second instance and I lost my tabs and unsaved content (actually, I didn't lost the info, because it was just an experiment).

Is it possible to work with multiple instances and not to lost their settings?

[Alexey-T]

But how? These 2 instances show the correct work.

[xcme]

But how? These 2 instances show the correct work.

Via FIFO method, having separate history* files in folders "sessionN" within the "settings" folder? When CT starts it check how many instances (Z) already work and then uses N=Z+1 session folder.

[Alexey-T]

And these new folders via be invisible after I run only 1 inst...

[Alexey-T]

Ah, Cud doesn’t detect that Z value, and it’s hard to detect it

[xcme]

And these new folders via be invisible after I run only 1 inst...

But why the second instance didn't use the session for the first instance? It should see that and open the same tabs as the 1st one has, right?

Ah, Cud doesn’t detect that Z value, and it’s hard to detect it

Yeah, that's a problem :)

[Alexey-T]

But why the second instance didn't use the session for the first instance? It should see that and open the same tabs as the 1st one has, right?

sorry? it's some new problem/bug? cannot get idea.

[xcme]

I mean if I have let's say 5 tabs in 1st instance and it was saved in sessions, then if I start 2nd instance manually then I see the same tabs as I have in the first one. But if I choose in Explorer "open with" + CudaText it starts new instance each time with only one tab. And then session files will have info from that instance that was closed last.

[Alexey-T]

I got it. yes, 2nd instance will save session too. so it must not save the session if it was started with command-line-param?

[xcme]

Not sure how it should work. It's a topic for discussion.
Btw, how does "ui_one_instance" work? How does it determine if it the first instance or not?

[Alexey-T]

It is complex code, e.g. on unix/linux it uses IPC server from lazarus

[xcme]

so it must not save the session if it was started with command-line-param?

May be each instance on closing should re-read history and then add new info there? In that case history files will keep info about all changes in all instances.

[tmsg-gh]

FWIW, my 2c re this. I have two separate settings folders for Cud (see switch -s): the first is for a single-instance copy of Cud that is also the one opening files double-clicked in a file manager or xdg-open'ed from the command line. The second is a multi-instance copy that is only used with named, existing sessions. So there is never any chance of this happening.

However, I can see that multi-instance copies will throw up this problem. Alas, there's no easy solution I can think of. One possibility would be a new command-line switch which tells this copy of Cud what the name of its history file should be:
cudatext -historyname=my1sthistory blabla.txt
cudatext -historyname=my2ndhistory moreblabla.txt
So these copies of Cud would store their histories in my1sthistory or my2ndhistory etc. All copies of Cud started w/o this would use the default name with the potential to overwrite stuff. Of course the history name has then to be given explicitly on a command line to load and store a certain history... which is more or less what I do with my second case.

[Alexey-T]

@xcme what do you think about solution from tmsg?

 cudatext -historyname=my1sthistory blabla.txt

Seems your use case doesn't need/want the cmd line keys.

[tmsg-gh]

Actually, @Alexey-T could generalise this to include any other files that are read/written on a per session basis by doing sth along the following lines:
cudatext -sessionsuffix=SUFFIX ...
and add the "SUFFIX" part to all files concerned.

(I am probably belabouring the command line stuff... that's because in 99 out of 100 cases I do start Cud or load files via the command line. I am no fan of mouse or point-and-click or GUI file managers. :imp: )

[xcme]

@xcme what do you think about solution from tmsg?
Seems your use case doesn't need/want the cmd line keys.

Yes, I think it might work mostly for Linux/CLI users. But actually the problem not in necessity to keep separate files for history, but rather in order not to lose history of previous tabs. If it possible to append info instead of completely rewriting it on closing tabs/app?

[tmsg-gh]

@xcme Isn't the problem with the add/append strategy that all those files opened in the various sessions will then be added to the unified session history... but never actually removed so they accumulate until you have a zillion files in the history?

[xcme]

@tmsg-gh, I believe that after closing tab the history for that file could be removed, the it will not collect all the files infinitely. And the worst scenario here when you once start the 1st instance and get all these tabs opened. Then close unneeded and history will be cleaned up.

[Alexey-T]

I dont like the idea 'add all files to a common session'. user will not expect some 'new files'.
what I can suggest. on closing, Cud saves session to a 'history session.json'. it can do this - save backups of last n sessions: 'history session.n.cuda-session'. then user can return to an old session using Session Manager plugin- it will show all those by file-extentsion. so info will be not lost

[Alexey-T]

Implemented this. beta at http://www.uvviewsoft.com/c/
Pls test?

• add: option "ui_backup_sessions":0 (keep backup copies of last unnamed sessions)

change to e.g. 3.

[xcme]

Thanks. Had no time to check mail. Will check soon.

[xcme]

Seems works. Only few notes:

1. First time (after first start) I repeated steps from the first post and lost my session. But now I can't reproduce :) I have previous sessions and could open it manually. I think it's a great solution for the case a user accidentally lost his main session.

1. I have "ui_backup_sessions": 2 and I saw:
   history session.1.cuda-session
   history session.1.1.cuda-session
   history session.2.cuda-session

The logic is not clear, but it works. Now I see only .1 and .2 sessions.

1. It isn't clear how the Session Manager plugin works. Sometimes its shows the menu after calling "Recent sessions", sometimes not. But it always works with "Open/New session".

[Alexey-T]

The logic is not clear, but it works. Now I see only .1 and .2 sessions.

File "history session.1.1" appeared after you opened session ".1" by Session Manager? Cud made the backup of '.1' to '.1.1'.

I changed the default of the option to 0 in release 1.138, so users won't have 'new files'.

[Alexey-T]

It isn't clear how the Session Manager plugin works. Sometimes its shows the menu after calling "Recent sessions", sometimes not.

this should be posted to a new issue, not here. Use kvichans' repo or main Cud repo.

[xcme]

@tmsg-gh,

FWIW, my 2c re this. I have two separate settings folders for Cud (see switch -s): the first is for a single-instance copy of Cud that is also the one opening files double-clicked in a file manager or xdg-open'ed from the command line. The second is a multi-instance copy that is only used with named, existing sessions. So there is never any chance of this happening.

Does the proposed solutions help you?

[xcme]

File "history session.1.1" appeared after you opened session ".1" by Session Manager? Cud made the backup of '.1' to '.1.1'.

Yeah, now I see. Got 2.1 after that.

The last question I have:
If user opens two or more sessions in a row with the multi-instance option he sees the same content in all of them. Is it expected or new sessions should be empty?

[Alexey-T]

Hmmm Cud don't change session on opening (it changes it on saving) so opening gives the same content.

[Alexey-T]

TMsg, xcme,
Any changes are needed with the new option?

[xcme]

I don't know at the moment. It should help, thanks for the adding.

[Alexey-T]

@tmsg-gh likes to write some amounts of text, and when I do smthing, he may answer or not. it's not good and not effective for Cud.

[xcme]

He will answer right after you release the new version :)

[tmsg-gh]

Any changes are needed with the new option?

@xcme I don't know as I have had no time and no opportunity to test this. However, as my first post in this issue makes clear I have no problems with the current setup as with my usage your scenario simply cannot happen.

@tmsg-gh likes to write some amounts of text, and when I do smthing, he may answer or not. it's not good and not effective for Cud.

@Alexey-T You do realise that there are other things in the world than Cud? You do realise that people have a life outside computers? Additionally, I am currently at a place with v bad internet connectivity.

Honestly, all I can say if this is your attitude... GET LOST.

He will answer right after you release the new version :)

No, he won't. The attitude of @Alexey-T WRT development and other things as well is such that I will henceforth ONLY report verifiable bugs with exact steps to repro and nothing else (and even then I will only report bugs if they bother me).

Over and out. For good.

[tmsg-gh]

because Tmsg said to me "Get lost" and some not-good words, I see we don't need this change. No other users do need it. Closing, sorry.

That comment pinpoints v precisely what mean when I said your attitude is bothering me. If you are removing legitimate suggestions just because you don't like the poster... well, in the long run you are shooting yourself in the foot. But hey, it's your product you are not making better.