Request: Reload Document

[cmahte]

Missing Menu Item: Reload Document. Hopefully with a shortcut

This is an alternative/interim for Issue 162 that would fill a hole (missing regex replace) to quickly producing lots of tweaked documents.

That is, this is a way to allow Gummi to quickly render files edited externally (with a REGEX enabled editor.)

[Vectornaut]

Seconded! I like the way gedit responds when a file gets changed externally, and I'd love to make Gummi act the same. More broadly, I'd like to make Gummi's file recovery feature work more smoothly with intentional external file changes, such as:

• Git checkouts.
• Automated changes in the spirit of #162.

Feedback from people who use Gummi's file recovery feature would be very helpful here.

Implementing an offer to load external changes

When a gedit tab gains focus (view_focused_in), it checks whether the associated file has been changed externally (gtk_source_file_is_externally_modified). If so, the tab shows an info bar offering to reload the file.

Gummi can already display info bars (like in gui_recovery_mode_enable) and check whether a tab's associated file has been changed (using GuTabContext*->editor->last_modtime), so it might be relatively easy to imitate gedit's behavior.

Changing the file recovery feature

When I use Git to manage LaTeX projects, the file recovery feature adds two annoying steps (in bold) to my workflow.

1. Check out a commit.
2. Open a file.
3. Dismiss the file recovery offer.
4. Reload the file to get rid of the editor_buffer_changed asterisk in the tab name.

Here's the simplest fix I can think of.

• Allow file recovery to be turned off in preferences.
• Link to this option from the file recovery info bar.

However, I'd love a fix that demands less action from the user. Thoughts?

[Vectornaut]

I've prototyped a gedit-style external changes procedure! It's on the load-changes branch of my fork. Should I make a pull request?

What it does

• Like gedit, it checks for external changes each time you focus in an editor tab, using a "focus-in-event" callback.
• If the file associated with the tab has been changed since the last time you loaded or declined to reload it, the tab displays an infobar offering to reload it.
• If there are unsaved changes that would be wiped out when you reload, the infobar mentions that.
• If you ask to save a file that's been changed since you loaded it, you get a confirmation dialog, which replaces the save/reload dialog as called for in #168.

Polishing it would need before production

• Check for memory leaks! Does the "focus-in-event" callback need to be disconnected manually when a tab is destroyed?
• Localize. I propose reusing gedit's wording and localization, if the license allows it.
• Give the external changes procedure its own infobar? It currently shares the file recovery infobar, but I don't think that's ideal. For example, it would be nice to have special button labels, like gedit's external changes procedure; that might be easier to implement in a separate infobar. It seems like there are renovations planned for the infobar system anyway, as discussed in tabmanagergui_create_infobar:

  // we will probably want to make a separate file for infobar // procedures that we can attach to hboxes in both the editor // and the preview window, TODO for 0.7.0 -Alex

Further polishing that might be nice

• Use gtk_source_file_is_externally_modified, like gedit, instead of a modification time comparison. I think this would require deep changes to the way Gummi associates files with editor tabs.