I'm working on a project for which I'd like to use joe as the editor. One feature that would be useful (to me anyway), would be the ability to affect certain aspects of a 'running instance' of joe from 'outside' the program.
As an example: joe could be running with some source code opened for editing. A debugger running in a separate window could cause joe to jump a particular line in the sourcefile.
I suppose this could be done in a variety of ways but one simple way would be to have the external program write a line number to a file (say .joe-call) in the user's home directory, and then send a signal to joe that would cause joe to read that file and jump to that line number.
If folks desire additional features, the .joe-call file could be expanded to contain these features as key/value pair like:
After joe is signalled, it could read and carry out any known action in the file.
Any thoughts? If anyone knows a clever way to achieve this type of behavior with the current version of joe, I'd love to hear about it.
After thinking about this a little more, I thought I'd post some additional ideas that I hope will garner a bit more interest than my original post did ;-)
Rather than tying the 'call back' feature to a specific action (ex. jump to line), it would be better if the 'actions' in the .joe-call file were calls to macros predefined in .joerc. That way, feature after feature could be added without any change to joe's code.
A program could simply write the desired action to .joe-call and send a signal (USER1?) to a running joe and joe would know to read .joe-call and carry out the action if it is recognized as a 'known' macro, otherwise ignore it.
I think this feature would be useful in working with any type of structured material like:
Program source code
An external program would 'scan' the source document and display (in a separate window) a list of scenes/entities/functions/classes/etc. When an item in this list is selected, a macro name (and argument) is written to .joe-call and a signal is sent to joe.
Jumping around the source file becomes very fast and easy.
I would love some feedback, even if you think the idea is silly.
This would not be too hard to add, but there are issues. What if the cursor is on a prompt line or a query window when the signal arrives? Should the editor execute the macro in the prompt line?
<i>What if the cursor is on a prompt line or a query window when the signal arrives?</i>
That must mean that joe is single-threaded.
No surprise there!
Thanks for the response.
I think the macro should only be executed in the edit buffer(s). I tried to think of an application where executing a macro in a prompt line might be useful but couldn't think of one.
If there was a need to execute a macro witnin a prompt line, couldn't that be achieved from the edit window if the macro was written to open the prompt first?
I hope I understand your question correctly.
I mean what should JOE do when it gets a signal and the cursor is not in the window you want? Should it jump to the nearest edit window? Should your signal supply a buffer name?
I think jumping to the nearest (currently displayed) edit window makes the most sense. I suspect that 99% of the desired actions that would signal JOE would be intended to affect the current buffer.
Having said that, adding the buffer name to the .joe-call file increases the possiblities and would be a nice feature if it's not too hard to implement.
Thanks for taking the time to discuss this. I'm very excited about this feature.
I'm not sure what 'threadedness' has to do with Joe's question (was this a disparagement?) but I'd still like to persue this to some end.
The more I think about it, there may be some issues with my scheme if there's no mechanism in joe to pass in parameters from an external program.
Even a simple thing like 'jump-line nnn' (presuming a macro by that name is defined in .joerc) how would the line number be passed in?
Is there any hope for this or should I stop persuing it?
More than a year later...
On one hand, I think this is a good idea, but I see security issues. The commands that may be used to remote-control JOE in such a way should be restricted, e.g. saving/writing must not be allowed.
Regarding the buffer question: Would there be a way to identify a certain buffer, e.g. by filename? Then it could be like:
or similar - if the noted buffer is not the actual one, try to jump to it, if there is no such buffer, ignore the rest.
But what if 2 instances of JOE are open? Or if "buggyprogram.c" had been opened in two buffers, e.g. to see two parts of the file simultaneously? Then identification per filename would not work, unless all buffers are tried one by one and the filename is only used to check if the actual buffer matches.
Oh I forgot: is there any other editor that can be remote-controled in such a way? Integrated development systems excluded?
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.