Having both a menu item and a preference is a pain

First, having used Scrivener 3 for several months now, I’m remarkably pleased. Love the compile, and the new navigation options.

However, there is now a philosophy evident in several common settings (smart punctuation being the most recent I’ve tripped over) that Preferences only work for new projects; to control these things for a current project there’s a menu item.

I’m sure that L&L have had many requests for a way to make exceptions from preferences in a particular project over the years, but it has added IMO yet another complexity on a daily basis. If I want to change the way something like smart punctuation works, most often I want to change it for all projects. That means I not only must change it in the Preferences but I must also hunt it down and kill it in the menus of every active project.

I would prefer something like this be a part of the project settings the way default text formatting is. That is, an option in project settings to override the global setting and then set it for this project only. In general I don’t change whether I use smart punctuation in a given project every day.

I realize that it’s unlikely that this change will be implemented at this point; there’s too much momentum, what with Windows 3 in beta. It’s not a casual thing to just remove a menu item or six and redesign a major dialog! But I do hope that L&L will thoughtfully consider it for 3.1 or 4.0.

Smart dashes and quotes are something users often want to turn off on a per-project basis. This isn’t a new thing in 3.0 - there have always been several settings in the “Corrections” area that specify “in new projects” (spelling used to have two settings). I could see a case for removing these from the Preferences entirely, as we have done with spelling,which is now a “lazy preference” - that is, new projects use whichever setting users chose last, as is quite common.

As you note, the reason for this change is that it makes things significantly easier for those who need different specifications depending on the work they are doing. They might be working with publisher that needs simple punctuation, but for most or all other things, prefer to have typographic punctuation generated while typing. Perhaps you use LaTeX for one project but generally use Word for other work, and so forth. The old system was super annoying if you needed to work that way.

Meanwhile, for those (who I would guess are in the large majority) that do have a simple preference in the matter and always want the setting one way or the other, not much has changed in that regard. You make your choice in preferences and from that point on you can ignore the settings.

Another one that comes to mind that was moved from global to project-specific is whether or not the binder displays how many items a group has nested beneath it. It’s the sort of thing I really like in some projects, particularly those that have a lot of workflow type folders, like an inbox and outbox. But in a lot of other projects it’s a nuisance and I just want to shut it off. I think there may have been some settings that migrated in the other direction as well, but I’m not thinking of anything at the moment.

I wouldn’t say it’s a new philosophy, though. There has always been a substantial level of separation between project specific settings and global settings since even Scrivener 1.0. For project settings the answer to the question of how one can establish a default (say they want binder subdocument counts everywhere) has been project templates (well, at least once the project template feature was introduced :wink:). There aren’t too many settings like you describe, where there is both a global default toggle and a project-level exclusion.

My question, for the sake of curiosity, would be: what type of event do you find yourself faced with where it is (a) necessary to switch punctuation style in all active projects simulataneously and (b) change the default as well, and on such a regular basis that it becomes a noticeable thing? That seems unusual to me, but I’m a bit outside of the topic I will freely admit. I write to ASCII level compatibility for 99% of what I do and by and large leave matters of typography to publishing systems.

Well for that one specifically, do note that System Preferences: Keyboard: Text has a pair of settings for smart quote styles, and among the choices they offer is a pair of dumb quotes. If set those, everything will stop using smart quotes until you turn them back on, regardless of internal settings (save for any software that isn’t Mac native or that hasn’t rolled their own smart quote code). Maybe for that one it will help you out.

Yeah, that’s something I was just pondering as well. It does strike me as very similar to the spelling setting in how that mechanism works, and that’s how Scapple works already come to think of it.

Not on a regular basis as such! But I do change my working font every couple of months or so, to help things look fresh. (I struggle with ADHD in addition to all the usual writer’s block stuff so anything that makes my work look new is a plus, drawing my eye to it.) It happens that no font is perfect :smiley: and I like to be able to distinguish, say, em-dashes from hyphens. If the font I’m choosing lets me do that, well and good. Otherwise I turn off smart dashes (In version two, I had to turn it all off as I recall) and trust that what’s already there is OK. But yes, separate settings for each project is a barrier,particularly when I do this often enough that when I see the problem I vaguely remember that I need to do something “weird” but don’t do it often enough to remember what. :smiley:

I would be in favor of the “lazy prefs” approach for sure.

You know you got me stuck on Cousine, let’s see, according to the forum post date—204 days ago and I haven’t even thought about changing it yet. I surely will though. My point of oscillation there tends to be between a nice monospace font vs a staid, straight out of the 16th century style serif font for a few months, and then back again.

I do agree with the fundamental problem of monospace fonts and dash lengths. But that’s probably why I also prefer the triple-dash approach. There is absolutely no ambiguity—in that, and it’s not too far off from the actual width of an em-dash.

Your point is well-taken, Ioa. I switched from Cousine to Fantasque Sans Mono, which has super curly quotes but semi-lousy dashes. And staying away from bothering with smart dashes appeals because it’s very easy to correct this via compile. And even with as nicely distinct dashes as Cousine’s, it’s still hard to distinguish the various dashes in smaller font sizes in a monospaced font.

I have found that I prefer smart quotes on, mostly because while the compile algorithms do a great job changing from smart to straight quotes, the inverse function is spotty. I seem to always need to go back through and fix quotes by hand after. Best just to have curly quotes and correct bad machine guesses as I go.