<p></p>
24 December 2020 2:00 PM<br>
<br>
 <br>
<br>
First, thanks for the info about geany internals.<br>
<br>
 <br>
<br>
I've been using geany for years and having multiple execution terminals simultaneously open<br>
<br>
is part of my standard workflow.  It came as a complete surprise that yesterday it would not allow<br>
<br>
me to do that.  I remembered that the previous day I had been working in geany when the<br>
<br>
powerfail happened, so I began playing with the settings until geany started to behave again.<br>
<br>
 <br>
<br>
I tried various things, like putting in the complete path to the python binary.  What worked was<br>
<br>
when I made a mistake and the execute failed with an error.<br>
<br>
 <br>
<br>
>From my 'geany.conf':<br>
<br>
 <br>
<br>
<br>
[tools]<br>
terminal_cmd=x-terminal-emulator -e "env PYTHONPATH=/usr/local/lib/python2.7/site-packages /bin/sh %c"<br>
browser_cmd=sensible-browser<br>
grep_cmd=grep<br>
<br>
 <br>
<br>
Which is standard except for the PYTHONPATH adjustment which points geany to my personal library.<br>
<br>
I added that after I discovered that the addendum to my '.bashrc':<br>
<br>
 <br>
<br>
<br>
# 20201017 enable using my personal packages<br>
export PYTHONPATH="/usr/local/lib/python2.7/site-packages"<br>
<br>
 <br>
<br>
<br>
was ineffective from within geany, probably because 'sh' symlinks to some simpler shell.  Beyond<br>
<br>
that, all configurations are from a standard ubuntu repository installation that was performed a few<br>
<br>
days before the bash and geany configuration alterations.<br>
<br>
 <br>
<br>
I notice now that the build command is the unaltered default:<br>
<br>
 <br>
<br>
python "%f"<br>
<br>
 <br>
<br>
and that differs from the 'geany.conf' file, but that should not matter since the build<br>
<br>
command becomes the %c in the config file.<br>
<br>
 <br>
<br>
Running just now a program that has a lengthy test suite, I see that the execute icon changes<br>
<br>
from a gear to the circle slash and changes back almost immediately to the gear icon, where<br>
<br>
the test suite is still running as I type this, and has now stopped.  I have no difficulty starting<br>
<br>
other executions, even before the lengthy test completes, and all terminals remain open until<br>
<br>
I explicitly close them, as I expect should happen.<br>
<br>
 <br>
<br>
That is to say, everything is working fine now, as it was yesterday after I caused the execute<br>
<br>
command to throw an error and then restored the default.<br>
<br>
 <br>
<br>
The reason I mention this is that your paragraph on the icon behavior does not match my<br>
<br>
experience, either over the past years or now.  Moreover, if I run the lengthy test suite and<br>
<br>
immediately run the same test suite by clicking the immediately restored gear, I get a new<br>
<br>
independent terminal instance and the first invocation does *not* terminate, but continues,<br>
<br>
as I would expect it to do.  If I need to terminate the process, I can use ^C or simply close<br>
<br>
the terminal window, so this experience also does not match your paragraph.<br>
<br>
 <br>
<br>
Finally looking in the task manager, I see geany is the parent of the terminal and the<br>
<br>
terminal is the parent of a shell which is the parent of the lengthy test, as expected. <br>
<br>
If I suspend by closing the laptop in the middle of the lengthy test, and then reopen<br>
<br>
the laptop and touch the power button to resume, the situation remains, as expected.<br>
<br>
When the program stops, its process disappears, and the shell and the terminal remain<br>
<br>
as expected.  When I close the terminal by whatever method, both the shell process<br>
<br>
and the terminal process disappear, as expected.<br>
<br>
 <br>
<br>
In closing, I realize that the issue I reported is one of the most difficult kinds to track<br>
<br>
down, and it is not likely to affect many people.  It is, however, real.  I did in fact<br>
<br>
spend an hour of my time yesterday trying to resolve it.  The workaround I discovered<br>
<br>
is effective, and given the rarity of  occurence, I certainly don't expect any concerted<br>
<br>
effort to resolve it.  It should, however, remain in the back of your mind, especially<br>
<br>
when you happen to be working on the geany initialization code, or perhaps gui<br>
<br>
interactions with the os window manager.<br>
<br>
 <br>
<br>
I should point out that I am using Bodhi linux (5.1.0) which uses a variant of the<br>
<br>
enlightenment libraries.  These are peculiar libraries, and you either love them or<br>
<br>
hate them, and they do have some quirks.  The problem may be some bizarre<br>
<br>
interaction between your gui libraries (presumably still gtk, for I chose geany<br>
<br>
specifically because it uses gtk) and the enlightenment libraries, even if there<br>
<br>
really is no temporary state storage in geany.<br>
<br>
 <br>
<br>
Sincerely<br>
<br>
 <br>
<br>
John_Hull<br>
<br>
John_Hull@mail.com<br>
<br>
<br>
 <br>
 <br>
<br>
Sent: Wednesday, December 23, 2020 at 5:56 PM<br>
From: "elextr" <notifications@github.com><br>
To: "geany/geany" <geany@noreply.github.com><br>
Cc: "ruminations" <John_Hull@mail.com>, "Author" <author@noreply.github.com><br>
Subject: Re: [geany/geany] terminal persistence after crash (#2703)<br>
<br>
<br>
 <br>
<br>
If the Geany execute command item is activated while a command is running it terminates the command, this allows programs that get into an infinite loop to be terminated. When running in a terminal Geany does not know the process ID of the program, only of the terminal, so that is what is terminated, and hopefully it will terminate the program. Similarly as it does not know the program process id there is no way Geany can find out if the program has finished, only if the terminal has finished, so the execute action remains as "stop" until the terminal closes. So this part is working as intended.<br>
<br>
Geany does not store any execute state when it closes because it no longer owns the terminal process when its restarted (if that process still existed) so there is no point in it doing so. I suspect that if the execute icon stays at stop then your laptop is not shutting down, it is hibernating or suspending, so Geany is restored in its previous state, but I have no idea if the terminal process termination is correctly delivered in that case, possibly not, but its not a scenario Geany has been designed to cope with, YMMV.<br>
<br>
If you want to have multiple terminals open the command Geany runs (from Preferences->Tools->Terminal) must complete. I havn't tried it, but you could try modifying that preference to run the terminal in a shell and detaching it.<br>
<br>
—<br>
You are receiving this because you authored the thread.<br>
Reply to this email directly, view it on GitHub, or unsubscribe.

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/geany/geany/issues/2703#issuecomment-751124994">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AAIOWJ3OM7GSB6J474H4N4DSWO5NNANCNFSM4VHMZG5Q">unsubscribe</a>.<img src="https://github.com/notifications/beacon/AAIOWJ2CH6MEBQMUI4WGDJDSWO5NNA5CNFSM4VHMZG52YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOFTCUEAQ.gif" height="1" width="1" alt="" /></p>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/geany/geany/issues/2703#issuecomment-751124994",
"url": "https://github.com/geany/geany/issues/2703#issuecomment-751124994",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>