Jerud Yes, I agree with the “where we agree” section. The only caveat as I said is that setting auto-size on for one, and off for the other (the way it is now) and mixing them together, is going to produce weird-looking results when zooming - unless you set the manually-sized one to always be small. I can imagine wanting to use auto-sized headings, with single-sized small projects. I think there should be a better way of doing that besides always using ^^^^, or subscription-only custom CSS.
But I still can’t imagine a use case where someone would want auto-sized headings and manually set multiple-sized projects. Can you explain to me or show an example of how that would be a good thing?
If not, then maybe better settings would be something like:
With auto-size unchecked, all sizes are done by multiple ## and ^^, no change when zooming. When checked, it enables options to override with fixed sizes. I don’t know - I guess it’s still possible to make weird settings with that… some other way…??
For auto-sized items, the prefix is only ON or OFF; #### and ^^^^ can be typed in, but so long as the toggle is set to “auto” they mean the same as # or ^.
I’m not sure whether I agree with that suggestion. It would take away the ability to use the “mixed indentation style”, as in the example in post #52, which is what Jay explained as the reason for “summing up” the effect of manually-set prefixes with their indent level. It would also take away the ability to have some “flat” documents with multiple heading sizes, e.g. created in list view, and some hierarchically indented ones with auto-sizing.
On the other hand, ignoring multiple prefixes when auto-size is on, not showing them in the / or RMB menu, and not cycling through them with the hotkey, would simplify things. People using auto-sizing generally shouldn’t use manually-set prefixes for that item type, except in the couple of cases as above. If they’re not aware of that, it can be confusing.
It would be a trade-off between those two things - I’m not sure which is more important.
Auto-sized prefixes set the style for each item according to its absolute indent level within the PANE. H and P could be mixed freely and would always adopt the “right” sizes relative to each other, and auto-sized items would scale up together as the user zooms in.
That’s exactly the way it was, before auto-sizing was removed from projects, wasn’t it? Or do you mean something else?
Therefore auto-sized prefixes should only require a single hotkey-press or RMB-click to toggle on or off – no extra clicks or presses to cycle through manual sizes that have no display effect.
Currently, it already takes only one click on the RMB menu to toggle headings on or off. If there’s actually a common problem with people accidentally setting manual sizes by pressing command/ctrl-shift-H multiple times, e.g. while trying to turn a heading into a non-heading, and not noticing it, there’s maybe a better solution than simply disabling manual sizes altogether only for that reason. For example, when auto-size is on, maybe the hotkey could just toggle on/off, instead of cycling through the sizes, for which you’d need to type ###.
Mirrors with manual-sized prefixes will display at the size they were manually set to, no matter where they appear.
With auto-sizing turned off for that item type, they would. Like projects already do.
(I assume you mean mirrors of items for which auto-sizing is disabled? There’s no such thing as “manual-sized prefixes” per se, that could override auto-sizing, because you can’t designate whether a single-# item is manual or auto. If you could, then maybe that could be an alternate solution to a global setting - you could mix manual and auto-sized together, i.e. you could force an H1 below an auto-sized H2.)
Mirrors with auto-sized prefixes will display at the size that fits with their location in the Outline per above.
With auto-sizing turned on for that item type, they would. Like headings already do.
If multiple-sized prefixes are not disabled when auto-size is on, and people use them for the “mixed indentation” or “flat” non-indented cases, and then they mirror those to somewhere where they are indented - which is maybe unlikely - they’ll get the doubly-small effect, but that’s probably correct anyway.
