Seems reasonable, but post-2.0 at this point due to release
engineering freeze

*** Bug 73272 has been marked as a duplicate of this bug. ***

#73272 points out that you want to be able to save to file in addition 
to preplanned logging.

*** Bug 91550 has been marked as a duplicate of this bug. ***

*** Bug 120583 has been marked as a duplicate of this bug. ***

Changing the version, as this is not yet there.

re-titling and creating 'gnome-terminal UI improvements dependency tree of doom!'

Created attachment 38173 [details] [review]
add "save scrollback to file"

Maybe this is a start.

Created attachment 38174 [details] [review]
add accessor funtcion to vte

Unfortunately I don't know how to get the current number of lines in the
scrollback without patching vte too.

Created attachment 57028 [details] [review]
Updated patch with schema, rediff against current gnome cvs

I have been using this patch for the last few month. I want to get rid of the need to patch vte for this one, but I have no idea how.

*** Bug 349973 has been marked as a duplicate of this bug. ***

I created a separate bug for the vte dependency (#348342).

This patch takes saves what's in the terminal buffer. Wouldn't it be more useful to actually log the output of the child to a file? (together with the contents of the text buffer at the time the user decides to start logging, maybe?) Otherwise, it is quite hard to save long outputs, like the one produced by jhbuild, say. 

I have no idea what the UI for such a thing might look like.

If I know before that i need to log the output i would use the 'script' or 'tee' command. 

But most often something happened way back in the buffer which I need and this patch saves me from selecting a few thousand lines with the mouse and pasting them into a text file. 
Since there is no way to search the buffers content in g-t this comes in handy as a workaround, too.

Other times I need to store an important sessions output, like a filesystem check for example.

Adding realtime logging would be a different issue, since you know before that you want to log. How about adding a checkbox menuitem 'Log to file' which opens a filedialog to receive the logfile name and afterwards writes input/output to the file until unchecked?

(In reply to comment #14)

> Adding realtime logging would be a different issue, since you know before that
> you want to log. How about adding a checkbox menuitem 'Log to file' which opens
> a filedialog to receive the log file name and afterwards writes input/output to
> the file until unchecked?

Maybe someone with more experience could comment this, but isn't this a vte issue?
It's no problem to add another menu entry to g-t, but as far as i understand the api the real-time logging has to go into the vte widget, right?

(In reply to comment #15)
> (In reply to comment #14)
> 
> > Adding realtime logging would be a different issue, since you know before that
> > you want to log. How about adding a checkbox menuitem 'Log to file' which opens
> > a filedialog to receive the log file name and afterwards writes input/output to
> > the file until unchecked?
> 
> Maybe someone with more experience could comment this, but isn't this a vte
> issue?
> It's no problem to add another menu entry to g-t, but as far as i understand
> the api the real-time logging has to go into the vte widget, right?

I think vte emits enough signals that this can be entirely done in g-t. text-modified, text-inserted, text-deleted signals for example.

(In reply to comment #16)
> I think vte emits enough signals that this can be entirely done in g-t.
> text-modified, text-inserted, text-deleted signals for example.

Thanks, I hadn't thought about the accessibility api. These signals are used internally for communication with the accessibility peer.
So basically g-t has to register itself as a peer and use the atk api to write to a file?

I looked into atk and wrote a little test terminal. The desired events only get emitted if accessibility is enabled at log in. Maybe there is a way to enable them from gnome-terminal itself, but honestly this looks like a crude hack to me.

I'd say vte has to implement real time logging, unless there are any other ideas?

I don't need real time logging in g-t anyway, i would be happy if vte just implemented something like Bug 348342, which is a dependency for the scrollback save patch i attached.

The current patch (2006-01-09 14:08 UTC 9.16 KB) methodology seems to work, but a more sophisticated approach would be better. Have you ever used Trilian? (I used it for AIM back in my windows days - gosh its over now.) Each session would be logged automatically to files which had dates, or you could explicitly save a session.

I think a good idea is there will be a logging directory, some dot directory off the ~ directory. Each time one opens a tab, it would create a file with the name <current date>.log. (If desireible, instead of a flat logging directory, there would be a setting to have it log as <year>/<month>/<current date>.log). Every 64k (or what turns out to be an efficient buffer size) that is written on the terminal screen, the file would open and be appended. There would be an option such as "off the record" where any input or output would not be logged. I use tee sometimes to record the output of my command, but sometimes I like to know what I actually typed, so this logging method would record whats on the terminal screen (which is both input and output). There should be another switch to explicit log any keybord input so you can see where you hit <ctrl> + c, or any other key, or if you typed a password. (Of course, for security, this option probably should be off as its default state.) Finally, it should make a note of when a program like nano or vi is opened since you can't really save the "text" of that program.

I'd be happy to try and write this. But, I'm wondering if people think it is a good idea, or does anyone else want to write it so we don't waist each others' time? Let me know what you think.

That logging directory would *definitely* have to be optional, otherwise I'd fill up my ~ directory ever so quickly with how much I work on the console and how often I type "dmesg" and stuff like that. And then, I think it'd be fairly useless because it'd have to default to *off* and people would only remember to turn it on when it's too late already...

Thats is true. I Imagine that I would fill up my ~ too. You could have three options: Log everything (described in my last post), Log session(s)/tab(s) if requested, absolutely no logging.

Log if requested: each open session/tab would write to a file (same way above off the ~), but if the user did not tell it to log this session, the log would be discarded on a successful exit gnome-terminal. This is good too in case something crashes, then you still have logs of what happened prior to the crash. This way, as long as you did not close the session its not "too late." Your dmesging or catting a log may get up to a few megs per session, but as soon as you exit (assuming you didnt specify to log it) will just be purged.

Sorry to put a spanner in the works, but I myself only need one thing:
 save everything in the scrollback buffer to disk.

The alternative is a long slow laborious copy and paste.

Created attachment 101483 [details] [review]
(Incomplete) Start of a logging patch

This incomplete patch is to enabled logging for each terminal session. There are 2 logging modes: Enabled, and On Request. Enabled, will log everything as text comes out. On Request means that you have to click "Start Logging" to begin logging. On either method, you can choose to "Pause Logging" and "Resume Logging" (incase you have sensitive material or for any reason you choose). If you choose the On Request option, there is a sub option to log anyway, but unless you choose to keep the log, it will be discarded on exit. This is here for two reasons: 1) if you start something and later on decide you need it to be logged all you have to do his click "Keep log on exit". 2) If your system crashes, you have a log of the last thing that terminal was doing. 

This patch is incomplete. I'm wondering if anyone can offer suggestions or help with the code. The biggest problem is that It can't handle backspaces when you erase what you've typed, or alter text of already typed stuff. This code is in the terminal-screen.c file in the function terminal_screen_logging_ti_callback, which is a callback for "contents-changed" on a VteTerminal.

Any chance this over 8 year old request can get done? This seems like a very basic function. Please consider adding it for future releases!

I have used konsole for a few years just because it can log your session. This can be used as a workaround.

Created attachment 118559 [details] [review]
save scrollback patch

Updated patch against r3036, no longer requires patched vte

*** Bug 556791 has been marked as a duplicate of this bug. ***

Any more news on this bug? It is sorely needed, patching it in everywhere is not ideal :)

Reviewing attachment 118559 [details] [review]:

+      { "FileSaveTab", GTK_STOCK_SAVE, N_("Save Tab"), "",
+        NULL,
+        G_CALLBACK (file_save_tab_callback) },

This doesn't very clearly express the purpose of this menu item; maybe "Save Terminal Text" or something...

+  if (gtk_dialog_run (GTK_DIALOG(dialog)) == GTK_RESPONSE_ACCEPT)

No. Absolutely not. gtk_dialog_run() is not allowed in g-t. Just connect as response handler and show the dialogue, and do the work on response.

+    filename = gtk_file_chooser_get_filename (GTK_FILE_CHOOSER (dialog));

What about non-local files? Should use uri here, and use GIO to save the file.

       <separator />
+      <menuitem action="FileSaveTab" />
       <menuitem action="FileCloseTab" />

I wouldn't group this item with Close, they're unrelated and this just invites accidents.

About attachment 101483 [details] [review]:

Clearly doesn't apply, has too much code style issues and is too outdated to make it worth reviewing. I just want to note that it implements a different thing than attachment 118559 [details] [review], logging instead of just saving the text that's currently in the vteterminal's buffer. I think for logging, we should add API to vte to do this there, and just put the enabling code in g-t.

Created attachment 135449 [details] [review]
save terminals scrollback content

Thanks for the review. I hope this new patches fixes most issues. Is it ok to move the callback to terminal-utils.c?

+1 for getting this completed, and added to the current version of gnome if possible.

(In reply to comment #30)
> Created an attachment (id=135449) [edit]

+  if (filename_uri == NULL)
+      return;

wrong ident.

+  file = g_file_new_for_uri (filename_uri);
+  stream = g_file_replace (file, NULL, FALSE, G_FILE_CREATE_NONE, NULL, NULL);
+  
+  if (stream != NULL)
+    g_output_stream_write (G_OUTPUT_STREAM (stream), terminal_text, strlen (terminal_text), NULL, NULL);
+  else
+    g_warning ("Could not write: %s\n", filename_uri);

Tell the use about it, I think, using terminal_util_show_error_dialog.

+  g_free(filename_uri);
+  g_free(terminal_text);

You're leaking the GFile, and the GFileOutputStream.

+  terminal_text = vte_terminal_get_text_range (VTE_TERMINAL (terminal),
+      0, 0,
+      row, col,
+      vte_terminal_always_selected,
+      NULL,
+      array);

As a follow-up bug for vte, maybe we should add some vte API that writes the text directly to a GOutputStream instead...

> Is it ok to
> move the callback to terminal-utils.c?

I think it's better to move this callback to where all the other action callbacks are, in terminal-window.c

+  dialog = gtk_file_chooser_dialog_new ( _("Save as..."),
+      NULL,

Don't pass NULL as parent, use the terminal window.

+  gtk_file_chooser_set_current_folder (GTK_FILE_CHOOSER (dialog), g_get_user_special_dir (G_USER_DIRECTORY_DOCUMENTS));

Not sure this is the right dir...

+  g_signal_connect (dialog, "response", G_CALLBACK (terminal_util_save_term_text_cb), terminal);

What happens if the terminal closes before the dialogue is dismissed? I think in this case the dialogue should close too, and the dialogue should also be modal to the window.

+  g_signal_connect (dialog, "delete_event", G_CALLBACK (gtk_true), NULL);

Definitely not!

Created attachment 135821 [details] [review]
save terminals scrollback content

The file chooser is now a modal dialog.

Should we also add a "Save Selection"?

Yes.

Implemented vte api and the "Save Contents" menu item.

Any news about which release this will be included in? It's been set as RESOLVED for almost three years.

Been in Fedora / Red Hat for over two years.

Actually, it's still disabled in stable releases (because of the sync issue).

Ah.  I think you should enable it.  Not going to fix itself magically, but it's not a huge deal either.

Okay, so this bug (it is sufficiently deficient that it is a design bug) is *THIRTEEN YEARS OLD*, and was finally fixed *FOUR* years ago, but nobody can use the fix because it was rigged in a way that makes it *DISABLED* for normal users.  Closing the bug was premature.  Please re-open it until such time as there is a release that has this *CRUCIAL* feature enabled by default.  Thank you.

Shouting on bugzilla doesn't fix bugs.

Looks like nothing else does either. You'll just rewrite it again and discard the bugs anyway.

Stop it.

I think I've made it clear previously that I consider fixing the sync issue a blocker to enabling this; I stand by that.

The description might be edited to reference whatever the "sync issue" is.  (Is there a bug number for it? Your Comment #39 merely says, "Actually, it's still disabled in stable releases (because of the sync issue)." and is not very informative.)  This bug report shows up high in the Google results.  With the reference, folks could go sign up for that status.

Still, after 13 years, I'd sort of expect issues blocking critical functionality to get worked out.

Thank you for following up!

Christian.  The sync saving is definitely not worse than the fact that 1. we store history on disk, and 2. line rewrapping is sync also.  For a menu feature, I really don't think being sync should be an issue...  Definitely your decision though.

Hi,
   Would it be possible to link to the bug for the sync issue, I'm curious to see what it actually entails.

I'm guessing in order to be able to try the feature + see what it's like with the sync issue, I should build an unstable build with jhbuild or similar?

Cheers
S