Plugin that performs actions on matched text

[Wesley]

Hi,
I have used iTerm2 on OS X before and it has a 'trigger' feature, where the terminal will monitor output for a given string (or regex) and the user can set an action to occur once that string is printed to the terminal output. The action could be inputting text to the terminal, notifying the user, etc.

I wrote a quick proof-of-concept of this plugin, which works well.
It appears to me that in order to enable it, it must be 'checked on' as a menu item at the start of each new terminator session.

It would be nice if this type of plugin could be enabled by as soon as terminator starts.
I was able to accomplish this functionality by executing the callback in 'terminator.py' right before the main loop begins.

Is this (either the plugin itself or the ability to have plugins that begin on startup) something that maintainers would consider adding into the main code?

Thanks!

[Stephen Boddy (stephen-j-boddy)]

Hi Wesley. Definitely something I think would be an interesting addition. Obviously I don't know how you've implemented this, so I'd have to see the code to give more thoughts or opinions. Just a few quick thoughts that occur to me:

Does this only match output, or input too? i.e. Can I sound a big siren if I type "rm -rf" before I hit return? Perhaps it could even be a primitive auto-correct if it could insert backspace chars.

Is this a basic string match or a regex match? A regex would allow passing matched groups to the input/notification/external command/etc as arguments.

Whats the performance like with infinite scrollback and/or lots of terminals?

I'd be wary of having this active for all terminals by default. Perhaps it could be tied in to Profiles somehow, so that strings are only checked/matched in terminals that are running a particular Profile.

I recommend you to push your branch to Launchpad. Then I and others can take a look and play around with it.

[Wesley (wesmoncrief)]

I have pushed the code to launchpad (at least I think I have, I've only used git/github before this).

It is currently very simple (and values are hard-coded in).

I agree that it should be tied to profiles or something of the sort, perhaps being able to configure different profiles for different triggers.

The 'architecture' that I have currently implemented is just to allow some plugins to begin at the start of a terminal. So I suppose the answer to your first two questions is 'it depends on what plugin the user is running'. The plugin I uploaded only searched for text that is output, though it could certainly be possible to change it/add a new plugin that monitors input text.

Perhaps it should be embedded into the 'terminator preferences' window to allow easier integration into profiles? Though this may make it less extensible by plugins.

I haven't done anything to measure performance.

By the way, I'm a college student studying CS so I'm happy to hear any general feedback on my code!

[Stephen Boddy (stephen-j-boddy)]

OK, Some initial thoughts. Bear in mind I haven't actually tested it or anything.

Yeah, starting the plugin in the factory will be problematic/inflexible later on. i.e. at this point in time we don't have visibility of what Profile this terminal would be. It might make more sense in the set_profile method of the Terminal class, assuming we do decide that that is the best way to set this up.

I didn't write the plugin functionality, so excuse my ignorance, but I don't actually know the reason for having all the abstract(?) classes of the different capabilities as well as giving plugins the ability to have multiple capabilities (in the list class var). <shrug>

If you want to eventually merge this in, trigger_type_startup.py will need a proper GPL v2 only header as per the other files. See the mavin.py plugin for a long version, or one of the others for the short form.

OK, so I see your method, and it is for now a simple hard coded string check but the rest looks good to me so far. So all of that will need a good thinking about, and coming up with a way to configure and change the strings/regexs/notifications/actions etc.

[Stephen Boddy (stephen-j-boddy)]

Using this bug/wishlist to discuss/track progress in the branch https://code.launchpad.net/~wesmoncrief/terminator/text-typer-plugin

[Egmont Koblinger (egmont-gmail)]

Hi,

I think you should work on the vte3 branch, vte2 is dead. (Stephen, what the heck about bug #1030562 ???)

Nice quick PoC. A proper implementation would, however, probably need to implement new features in vte.

Hooking up to contents-changed and checking the onscreen data is great for slow (e.g. interactive) use of the terminal, but will skip data if an application suddenly produces a lot of it. This is because vte does not update the screen at each new piece of data, it limits drawing to about maybe 30 FPS.

Note that iTerm becomes noticeably (sometimes magnitudes) slower if you have triggers. See the entire thread at https://gitlab.com/gnachman/iterm2/issues/1814.

[Wesley (wesmoncrief)]

Just to make sure, this the branch with vte3 that you are referring to?
https://code.launchpad.net/~gnome-terminator/terminator/gtk3

Also, is this
https://github.com/GNOME/vte/tree/master/src
the source for vte3 that you are thinking the feature would need to be implemented in?

[Stephen Boddy (stephen-j-boddy)]

@Wesley: Yes, and yes.

@ Egmont: Too many big serious things going on. Maybe once they get dealt with I'll find some time, but for now life has me by the short and curlies.