Export files extension

When I use the useful Export facility in the File menu, it’s almost always the Files… option I need, and, again, I almost always want to have the Hide Extension box (bottom left) unticked. The default is ticked. Is there a way to change the prefs on this so that it pops up already unticked? I can’t see anything obvious, but maybe I’m looking in the wrong places.

I presume from the lack of responses that I’m stuck with it as is. OK …

There’s not a Scrivener setting that affects this, but if you usually want to see extensions anyway, you could turn them on in the Finder preferences. With that on, the checkbox won’t appear in the dialogs.

Thanks MM, that’s a good scheme. Change that pref, and as you say, you don’t get a checkbox at all, and extensions are always there. Whether I can live with extensions always on everywhere else remains to be seen. The reason I generally want them on at that place in Scriv is because usually when I’m doing a simple export of a file, it’s to send to someone with Windows, and I like to help the poor old souls by giving them a file with an extension.

Hiding the extension only affects the view of the file on your computer; the extension is still part of the file, and will appear (or not appear) on your associate’s computer according to their preferences on Windows. Even if the extension isn’t displayed in Finder/File Explorer, the file will still be recognised by the software as whatever type you chose when saving it. So if you export as a rich text file, it will be an .rtf file whether or not you see that in the name.

The one catch on this is that you can opt to export plain text files without an extension. If you choose plain text as the export type, you’ll see another checkbox appear just below the pop-up menu. Just make sure you’ve selected to append the .txt extension and you’ll be good to go. That setting will be remembered, and the plain text files you export will be .txt and treated as such on Windows even if you’re not displaying extensions on your Mac.

This is where I become aware that I come from another time. A time when it was necessary to provide Windows users with files that had extensions: otherwise, their creaky old systems just wouldn’t know what they were dealing with. It’s one of those things I had drummed into me, after lots of to-ing and fro-ing of emails of the “but it won’t open!” variety. So, MM , I’m very grateful for you dragging me into the, what?’ 1990s?, and telling me how it is is. I will undo the Finder pref, I will blithely leave the Scriv checkbox ticked for Hide Extension, and I will let those Windows users luxuriate in files that just work. It’s almost as if they were using proper comptuers.

Just be aware that if you have extensions turned off and you try to import a .doc or .docx, Scrivener will treat it as plain text and you will have gibberish. So you’ll have to remember to turn extensions on when you want to import such files.

:slight_smile:

Mr X

This is actually an example of what django was talking about. There’s a difference between a file having an extension and the Finder (or Windows’ File Explorer) displaying the extension. Choosing to hide extensions in save dialogs or to not show filename extensions in the Finder doesn’t remove the extension from the file, it just hides it from your view. Windows defaults to hiding the file extensions; I think Mac doesn’t, but it’s the first thing I always turn on in any OS, so I don’t remember at this point. Hiding the extension won’t affect how the file imports into Scrivener on either system.

What does affect the import is when a file does not have an extension at all. From Scrivener, when you choose the export type, the file extension is automatically applied even though you don’t see it in the filename when you’ve chosen to hide them. The exception is plain text files, which give you a choice for whether to automatically apply the .txt extension; you might prefer to manually give it a different extension when you enter the file name, e.g. “filename.mmd”, and you don’t then want it to also add “.txt” to the end, hidden or not, since then it’s going to be treated as a .txt file by your system and not as a .mmd file. If you’re not adding the extension manually when you enter the name, then you want to leave it automatically applying the .txt extension so you don’t end up with an extensionless file. That’s the case where it may not be treated as expected, e.g. double-clicking it to open may pop up a “What program do you want to use?” query, it may not be recognised on import, etc.

@MM, Actually, in my experience, extensions are turned off by default and I too turn it on as soon as I am using a new system.

As for the rest, yes I know, but within the last couple of weeks, I think, there was a “Help!” post by someone hit by precisely the problem of importing a file from Word which did not have an extension, and ending up with gibberish, i.e. ASCII representation of binary code. If you have extensions turned off across your system, you’re not going to spot that the file you are about to import doesn’t have a valid extension, for whatever reason.

Another example: my wife uses a little photo editor — sadly long-abandoned by the developer, but it still seems to work without problem even in El Capitan — but if an image has the extension .JPEG, it won’t open it, but if the extension is .jpg it will. No extensions showing? “What the hell’s wrong with this image; why won’t it open?”

Having extensions showing may be “so 1990s”, :slight_smile:, but I’d rather be thought old-fashioned than be driven loco by apparently random results down to file extensions.

Mr X

Oh, I absolutely agree about the helpfulness of displaying extensions so you can see right away what you’re dealing with, edit it as necessary, etc. That’s why I turn them on. :slight_smile: I just meant to clarify that the problem you were referring to wasn’t that the extension wasn’t showing but that the extension didn’t exist (or is the incorrect extension)–a problem that is much easier to detect if you don’t hide the extension from view.