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