It does not exist in your application (well, your application may still have the original, from which a copy was sent to xterm, but that is a different object). But xterm saves in its own buffer the output it receives from the application. It uses the contents of the buffer to redraw the window, say, if you resize it, or scroll the text up and down.
Member 14968771 wrote:Your analogy is plausible, however, it does not explain how clicking on the text highlights it – if it is "gone" / does not exist per your explanation.
This text buffer belongs to xterm. It is not accessible to your application. The highlighting is done in this buffer, by xterm.
All you input and output goes through xterm (as long as your focus is in the xterm window). xterm knows where you click your mouse, and knows the size of character cells in its window (they are all the same, at least in classic xterm). Calculating from the mouse coordinates which character cell was clicked is trivial. (If you use variable-width font, it is just semi-trivial.) xterm starts at from this character and looks at the preceding and following characters in its text buffer. As long as they are 'word characters', it adds highlight to it and searches forward, but stops on whitespace, punctuation etc.
If you could monitor the connection between xterm and your application when you mark the word, you would see none. The marking is something xterm does for itself, alone.
I haven't been working with xterm for a number of years, and don't remember all the details, but like most *nix-born applications, it has a ton of options. I guess that you can tell xterm to give you all the raw input - certainly from the keyboard, so that your application can interpret copy (mark) and paste keystrokes, but maybe even mouse input. Your problem is that xterm manages its own scrolling, word wrapping etc. and your application cannot know where it has placed the output text you gave it. So even if you get the mouse click position, you don't have the information to know which word the cursor was pointing at.
If I understand your need correctly (and you do not want to give your application its own tailor made X-based user interface), the simple but somewhat pedal driven way to do it is to open a text editor with a new empty file (or one where you want to add another log record), mark the text in your xterm window, and then past them into the file in the text editor. There are multiple ways to mark text in xterm - single, double, triple click, mouse drag etc.
By *nix conventions marked text is put into the copy&paste buffer. I believe (not 100% sure) that even the Windows version of xterm is *nix like; it doesn't require any ctrl-C to copy the text. Pasting into the text editor file (or any other *nix style application) is usually done with the middle mouse button (or left, if you have no middle). If you run in Windows environment, and the text editor is a Windows application, be prepared to use ctrl-V or some menu selection to paste the text.
And again: If you monitor the communication between your application and xterm, there is no trace of the copy&paste into the text editor file. The copying is a private matter between xterm and the editor.
If you have as a requirement that your application must be aware of the copy&paste, you have to abandon xterm and straight command line output, and give your application its own X-based GUI. That will complicate it significantly. If you go for that solution, do not attempt to program at the X.11 level - that is like 'GUI assembly coding'. Find some X.11 based library / GUI platform. I haven't made a *nix GUI since Motif was the standard library, but most likely, today it has competition from about 42 alternative libraries, all open source, free for you to study the source code