Preserving the 'untitled' files

[etkaar]

If I create files (Ctrl+N) then new files untitled, untitled, ... will be created. Once Geany gets closed, a save dialog is going to be opened for each of these files.

Is there a way to preserve those files in the editor without being forced to save them, so they and their content would be kept upon the user manually closes them?

[codebrainz]

Geany will only open additional unsaved new files if you've modified the previous one, and will also only present the save dialog if you've modified the new unsaved documents. The action of saving them to disk is what persists them.

Is there a way to preserve those files in the editor without being forced to save them, so they and their content would be kept upon the user manually closes them?

I haven't tried, but it's possible with one of the plugins that provides auto-backup that it would do so for new unsaved documents. There is also the "Scribble" tab in the message window, which sounds like what you're after, but it's not a real document and there's only one.

[elextr]

No, files only exist if saved, and the only way to keep content when Geany is closed is to save it in a file.

Note that Preferences->Various->interface.new_document_after_close controls if new untitleds get made or only one as @codebrainz noted.

[etkaar]

What about a native feature which

1. changes the naming behaviour from untitled, untitled, ... to untitled 1, untitled 2, ..., and
2. keeps all those files opened in the editor after restart, without being forced to save them on disk.

Reason

People may use these untitled files just for temporarily editing or storing anything, without the need to save it into a file. It is also more comfortable to not be forced to save it into a specific file, if keeping it in the editor is fine. I also think it is more robust to not delete anything if not explicitly asked to do that.

This is by the way the default behaviour from Notepad++, this is where I know it from.

[elextr]

"Somebody" can make a plugin to do this.

[etkaar]

Why not as a native feature via Pull Request?

[elextr]

Its not something that appears to be vastly desired or needed in the core since this is the first time its been asked for, so it should be in a plugin, at least to start with.

[kugel-]

I think it would make sense to enhance the autosave plugin to do this.

[etkaar]

Its not something that appears to be vastly desired or needed in the core since this is the first time its been asked for, so it should be in a plugin, at least to start with.

Okay! What are the general reasons for when it is better to make a plugin instead of a core feature? E.g. there is a plugin which highlights double-click-selected text in the editor, but I always asked why this is not a core feature because I think it is very helpful for many coders.

@kugel- Could you please give me a link to the exact plugin?

[elextr]

To expand somewhat. All IDEs today do things by plugin, there are too many languages, use-cases, special cases, features etc to put them in core, especially for an IDE that makes at least a token effort to stay "small and lightweight".

[elextr]

https://github.com/geany/geany/blob/master/plugins/saveactions.c

[elextr]

E.g. there is a plugin which highlights double-click-selected text in the editor, but I always asked why this is not a core feature because I think it is very helpful for many coders.

Because it costs time and cpu to do this, especially on large files. And not everyone wants it, I for one find it hugely annoying the way Eclipse highlights the [expletive deleted] out of everything.

Also purely textual highlighting in code is only useful in some simple languages like C [ducks @b4n volley] whereas more sophisticated languages with overloading and scopes its highly misleading.

Its possibly useful in text of course, so its in a plugin.

[etkaar]

I had now a look into the builtin plugin Save Actions. I think the asked feature could fit into this plugin; however it seems, it would need an additional tab because it is a very different approach. I for instance do not wish any autosaving of already existing, opened files, I only want that the untitled files are kept after reopening Geany without being asked if I want to save them. The question is, if the plugin can bypass the dialog The file 'untitled' is not saved. because that would be needed, but only for untitled files.

Another thing is the naming behaviour: Changing it from untitled to untitled _n_ is more a core thing, not for a plugin. What do you think about changing that via a seperate Pull Request?

[elextr]

it would need an additional tab because it is a very different approach

A good point, and as you say it should be independent of any choosing of autosave settings, but as @kugel- noted, the general context is suitable for that plugin (and its way easier to extend an existing plugin than to make a new one).

To be clear, for contents to be saved between invocations of Geany you are going to have to save them somewhere, and then they will have a unique name, even something useful like scratch-1 scratch-2 etc. so if the plugin does that it should avoid the save query.

To be clear, the editing notebook is for files it doesn't handle anything else, and changing that is a big change.

Your other option is to add tabs to the message window, like extra scribble tabs, but that would be a whole new plugin.

[etkaar]

To be clear, the editing notebook is for files it doesn't handle anything else, and changing that is a big change.

What do you mean by editing notebook?

Your other option is to add tabs to the message window, like extra scribble tabs, but that would be a whole new plugin.

It would be also a very different approach I think. Only keeping the untitled files without being forced to save them, that is enough.

To be clear, for contents to be saved between invocations of Geany you are going to have to save them somewhere, and then they will have a unique name, even something useful like scratch-1 scratch-2 etc. so if the plugin does that it should avoid the save query.

I refer to the tab name in Geany. If I open multiple new files, they all will be named untitled, untitled, ... without iterator. Independent of keeping their contents after restart, I think it would be a good change if Geany would per default name them untitled 1, untitled 2, ... (or capitalized Untitled 1, Untitled 2, ..., but I prefer lower case for no reason). We would not need a plugin or setting for that, just a core change. What do you think about that?

[elextr]

What do you think about that?

Beware, there are things that assume unsaved tabs are called "untitled" so its likely that change will break other stuff, including in templates IIRC, and in plugins that are not part of Geany itself.

To be clear, tabs are called the filename, if they have no backing file they are called "untitled".

To be clear, if they are to survive between invocations of Geany they need to be saved by the plugin, you seem to be skipping that point, where and how is the plugin going to save them? and will that give them a filename? if it does your problem is solved.

[codebrainz]

FWIW, the weirdness with new untitled files not opening sometimes is explained in #2656.

I believe this issue is a duplicate of #905, and should be closed as such, with further discussion on the already existing issue as to not bifurcate it.

[etkaar]

I see, so changing the naming behaviour can be risky.

Beware, there are things that assume unsaved tabs are called "untitled" so its likely that change will break other stuff, including in templates IIRC, and in plugins that are not part of Geany itself.

To be clear, if they are to survive between invocations of Geany they need to be saved by the plugin, you seem to be skipping that point, where and how is the plugin going to save them? and will that give them a filename? if it does your problem is solved.

That risk involved, the plugin could just convert any untitled files into a real file on disk. Then the naming can be arbitrary. The plugin needs to save the file automatically on disk, at the latest when Geany is closed. Also, the plugin would always keep the red color of the tab, so the user independent of the naming behaviour always knows that the file is an auto-saved untitled file.

If users decide they want a file on disk, they would use Save As... to save a copy and continue with this copy or Save to virtually convert it to a "real file" which can be easily done by just moving it.

[etkaar]

@codebrainz Yes, looks like a duplicate. @elextr Since multiple users are asking for it, are we still looking for a plugin (which seems to not exist), or could we implement it as core feature using a Pull Request?

I will close this issue in favor of continuing the discussion in #905.

[elextr]

I'm not sure #905 is the same thing, its more about preserving state of files and sessions in an unexpected occurrence and not being annoyed by checks to not save untitled scratch files (its got lots of stuff mixed in together).

But this is about preserving unnamed editing tab contents in normal circumstances, which is something else again. This isn't (IIUC) targeted at the same thing as #905 so lets not mix more into the mess thats #905.

@etkaar a plugin saving files to disk is what autosave does, so thats why we suggest this has some affinity with the existing functionality of that plugin, and you may be able to reuse some of its code.

Since you want the contents of untitled tabs preserved, they need to be saved somewhere by the plugin and reloaded on start up. Since the editing tabs are designed to load and save files, that seems the simplest solution for your plugin, save them in files with names it makes up, in a hidden location somewhere.

Even if its not exactly identical to notebook++ functionality it satisfys the same use-case.

As for keeping status colour, you may have difficulty controlling it because thats checked against the file date/time and updated regularly, but if the tabs contents are saved/not yet saved its probably good to know that.

[elextr]

In particular see the "instant save" part of autosave plugin.

[codebrainz]

This is a duplicate of #905 even though they may have been requested for different reasons. Please lets not scatter several discussions across duplicate issues. #905 is older, has quite a few 👍 s and only has 6 comments including one misunderstanding the request and one saying "patches welcome", hardly a mess.

[elextr]

Just to confirm, discussion continues on #905 but this discussion still stands.