Scribes

Add "Don't Return" Flag.

Bug #904448 reported by Kevin Cox
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Scribes
New
Undecided
Unassigned

Bug Description

Currently Scribes has a "Fork Scribes' processes option. By unchanging this option Scribes does not return until you close _all_ scribes' processes.

This means that if you have a program like git that starts and editor and waits for it to close it works provided you have the option turned off and there are no currently opened scribes windows. If either of the above conditions are not met scribes returns right away and git gives a "Aborting commit due to empty commit message." error.

The opposite error is you try to commit something when you have no scribes processes open and then you open another window to do some "research" in another window and scribes will not return until you close every open window.

It would be useful to have a command line flag that keeps scribes open until the document opened by that instance is closed. This allows programs like git to know when you are done editing the document. It would also be nice if the flag could ensure it closed even if you have opened other documents.

$ scribes --version
Scribes version 0.4-dev-build954

Revision history for this message
Mystilleef (mystilleef) wrote :

As far as I know, this is not technically feasible because all Scribes window share the same process. If you have technical ideas as to how to accomplish this, then I welcome it.

Revision history for this message
Kevin Cox (kevincox) wrote :

I don't know much about scribes' internals but I can see two ways that might work.

I way is to start an independant scribes process that will not fork and all the other windows/documents use the main thread. Then when that window closes the secondary thread closes and returns. This is similar to how firefox works. If you open firefox it will try to open a new window on an existing session in which case it returns right away. If there is no session open it starts one and blocks untill all windows in that session are closed.

But, if you start firefox with -no-remote and a new profile (only one instance per profile is allowed) it opens a new session and blocks untill all windows in that session are closed.

The limitations of this meathod are larger memory usage, you can't switch to and from the seperate document to others and a higher memory useage. You might also have a problem with settings depending on how they are implemented.

The other meathod is a lot more elegant.

If scribes is started with the appropriate flags, after it sends a signal to start a new process it relaces (exec) it's process with a process which just blocks untill it gets a signal (USR1) at which point it closes. Then you have with each document an associated pid of that blocker (or 0 if there is no blocker) and when that document is closed you send the signal to the blocker and it returns.

The problems with this meathod is that I have no clue how signals (or the equivilent) are done in windows so you may have to have a sperate launcher for windows and the unixes. Also, I am not sure wether python has an exec statement like the C one that replaces the currently running binary with another.

These are just thoughts, I haven't done anything like this before.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.