Beta 21: Document Conversions don't operate on contents of folders

I’ve been using the Mac 3.0 manual to explore so that I can really use Scrivener Win 3.0. This is often very helpful to uncover feature operation, but I’m not getting anywhere on a simple one.

For the Mac version, manual section 15.5.5 Resetting Formatting, there’s a Documents/Convert/Text to Default Formatting… command referenced.

With better spectacles on, it’s there in Windows 3.0, but perhaps (?) not operating the same – or in a sense we might most often like to use it?

  • What the fine print on the resulting dialog says is that conversion will happen ‘on selected documents’
  • Select one or several within a folder, etc., and that’s what does happen
  • But select any of the variations on a folder, and nothing happens to the documents inside.
  • Further, if you select top-level folders like Draft or Research, the Convert/Text to Default Formatting… choice is dimmed, even if there’s text within them, so you can’t even try.
  • It is true that if there is text in an enclosing element, that will get converted – again, though, nothing will be done to the documents or folders inside.

It seems that for a release, it would be highly desirable that all elements enclosed in a folder (and in any deeper folders recursively) would be converted when a folder is selected.

And that for this, any folder including top-level like Drafts/Research etc.,would be treated just the same, including allowing conversion of of its own text if any.

Having digested good Amber V’s prolixity (their word :slight_smile: ) on ease produced by having the No Style way for normal text in a document, which by the way I like especially after too many fights with Word styles, the requests here feel right in line with Scrivener intents, and that they’d be very useful – thanks!.

This is how it has always worked, since version 1.0 for the Mac! I don’t think it would be a wise idea to suddenly change that right now, and seeing as how you’re maybe (if not, it’s so rare I’ve forgotten) the first person to bring it up in thirteen years or whatever—I don’t think most people want it to work that way. :wink: We would certainly hear about it, as we do when most people (or even a vocal minority) definitely do not like something.

Some commands in Scrivener, especially those that are destructive and have no undo—like this one—require explicit selections. They are bulk tools, but they will not assume that if you have one stray folder selected in your Research folder that thousands of carefully formatted papers should have their formatting blown away to whatever writing font you normally use!

Meanwhile it could be very useful to only update the folder’s text all by itself. With your proposal it would be impossible to do so without affecting sweeping changes throughout the project.

There are two approaches:

  • Edit ▸ Select ▸ Select with Subdocuments
  • Ctrl+1 and click into the editor to make this an editor based action rather than an item-based selection.

Note the second isn’t functional in the beta yet—probably on account of the whole “stack of editors” vs integrated multi-file editor issue.

Hi Ioa,

I think you’ve named the principle for a good way to do these mass conversions, such as can easily be needed when a project has had several different editors, some using iPad, etc., and thus lots of fonts etc. difference between documents…

The first method, however, also doesn’t yet seem yet to fully work, as I’ve been validating it.

Below is a snip out of the Binder, showing two enclosing items. According to the edit menu Convert To notation, Corkboard and Outliner Tricks is a file with children, Scriv way, while Customizing Projects is a folder,

  • I’m testing after using Edit/Select With Subdocuments
  • Converting on Corkboard and Outliner Tricks works. You get a dialog of choices, then top and the enclosed files all convert to Default formats as you’ve set them in Project Settings.
  • Converting on Customizing Projects doesn’t function. You get nothing, and there are no changes.
  • As another issue, Edit/Select With Subdocuments is tricky, though this may not be easily fixable. If you have the cursor within the enclosing item you’re about to do this on, you won’t be able. Clicking on the item in the Binder doesn’t enable it either. You have to click on some other document, then click back on the encloser. Then you can Select With Subdocuments successfully.

So if Select with Subdocuments can be improved to operate on folders (and always recursively to depth), I think we have a way to do this task of normalizing formats across a pieced-together project, as probably many are.

Do I need to raise a separate issue, to get this onto the docket?

Thanks,
Clive

Here’s the picture, in the new Tutorial:

Yeah, this command is fairly essential when the project is moving between platforms and different machines. The project level formatting override can help keep things consistent between users on the same platform—maybe even Mac/PC in some cases—but iOS is another universe.

Going into the description, I am not following what it is you are describing as differences between these two containers. I’ll need a little more to go on than one of them simply not working, I mean to say—because on my end:

  1. Click on container in binder (expanded, collapsed, Draft level, file group, folder, it doesn’t matter); editor was in corkboard mode for speed.
  2. Use Alt,e,s,d to Edit ▸ Select ▸ Select with Subdocuments.
  3. Use Alt,d,c,d to Documents ▸ Convert ▸ Text to Default Formatting
  4. Press Ctrl+1 to examine selection as Scrivenings and confirm the formatting has changed.

And it has. There is no variation in the pattern. Every container I select has the same outcome, whether upon four texts or four hundred.

That’s where I need a precise sequence of steps to show me how to make it so that clicking on a folder doesn’t expand it, or that if you have a folder and its subdocuments fully selected, the conversion command refuses to work.

That makes perfect sense to me. If you are typing in the text editor, then any subdocuments below the current editor context would have no reasonable way of displaying their selection status. Press Ctrl+3 to view that item’s children and work with them like that—this is the intention, not phantom selections beneath the text editor that you cannot see, and understand the implications of, until a year later when you happen to be going through those files and realise a command you once used wiped out a bunch of carefully formatted notes.

I think you’re describing how selection works in principle, rather than anything specific to the menu command you’re trying to use. I’m sure you’ll find Duplicate, Add to Project Bookmarks, Move to Trash and any other document level function will require an active, not latent, selection in the active view, in order to function (all of these conditions are safety nets to avoiding unintended destruction). But let me know if there is some difference between Select with Subdocuments and the rest of the software—and importantly, how to get to that point, click by click.

Wow, I just spent a further good hour+ on this. Fortunately listening to Esper Eriksen Trio kept good calm.

I used your Tutorial resaved, and a Project I made up on my own. First, I de-installed Scrivener entirely, got rid of the five(!) false installations from earlier releases in the usual way, deleted the Programs\Scrivener folder which had some interesting contents still, then freshly installed Scrivener Beta 21.

Here’s what I have:

  • fresh Project Settings format, Select With Subdocuments, Convert Text To Default Formatting does work.
  • as you said, for at least a goodly subset of container types, and more than one hierarchical depth
  • but, that it works is on my fresh-from-scratch Beta 21 Project
  • on a resave of the Scrivener Tutorial, opened from New Project, it doesn’t just as I said: on anything which is a folder
  • others, but in particular try Customizing Projects, or any container or above container in that vicinity. Containing files convert, folders don’t.
  • I went as far as to alter Customizing Projects to be a containing file. It still wouldn’t Convert
  • What I get every time it’s not going to convert is…nothing. When I click Convert Text to Default Formatting. If it’s going to work, I get the choices dialog as to whether to just do fonts, etc…
  • The selection initial step has always worked ok – and the Scrivenings show correctly.

Thus, it appears that the problem is the Tutorial. Which has probably gone through many versions of Scrivener and regeneration.

So, I tried an older project of mine. This appears to have last been saved in May or so.

  • Scrivener offered to and did convert the file(!)
  • Conversion did not work. Period. Neither for containing files or for folders.
  • I did get the Dialog for containing File, but it still didn’t do anything
  • I didn’t get the Dialog for a containing folder, so maybe this part only occurs there. Oder…

What can we guess from this (as only software debug/dissection can really tell anything solidly specific)?

The first jump is to say, ‘old files’, but presumably Conversion worked before.

Thus at the moment I’d go for something haywire in the conversion process as most likely the issue.

Meaning for me is that Conversion is a neat way to work within Scrivener’s broader abilities and their necessary constraints, and I appreciate again that you pointed this out – especially against the too-normal Greek chorus of ‘surely you should understand you can’t do that’. I shiver to think what this feels like to the less initiated.

But in present state, it’s not going to help in cleaning up my old WinScriv&iPadScriv projects. Which is why I got into this in the first place.

Not an entire loss, as I really need those mainly for copy-paste, can do it at text level where important.

That’s the capsule, Ioa. I guess you can put it through given the same proves out for you actually.

Best,
Clive

oh, and on the selection trickiness – yes, this is just Scrivener, giving lots of abilities and taking some chops to learn the extra care they need. The only way that occurs to get around this sort of thing wherever it is present would be to offer a Simpler Use mode…which thought does bring me to pause a moment, and wonder???

I think I’ve run into that bug as well. If you have a good example of it, try enabling Internal error alerts in the General: Warnings options tab, restart, and then keep an eye on that log when selecting the folder, selecting with subdocs, and then running the command. There may be something interesting in the debugging info.

Well I feel like there may be some miscommunication here. I’m not sure what in the present toolset would make it impossible to clean up the formatting of older/cross-platform projects—like I say that was a core capability built into 1.0 from the very start, that has always been an important capability. For total conversions, Alt-] followed by Ctrl+A ought to suffice, no?

Maybe—though I have come across some selection bugs, which is why I was wondering about the particulars. One I saw involved Scrivenings sessions, and using the Up/Down arrow keys in the binder, and even clicking. On some occasions, clicking on or navigating through lists of items would cause the focus to teleport into the editor, against all expectations and conventions. Such could certainly cause a lot of confusion if you’re expecting to make a selection for the purposes of performing subsequent bulk document actions—because after selecting you end up typing instead. Another I saw is using and in the binder or outliner to collapse/expand multiple containers at once (it doesn’t work, only one out of the selection will react to the command). These are not intentional things you should have to learn you way around.

Ah. Well, the log is a great idea. But, it shows nothing in it for the Convert action, whether it is working or not (according to which generation/conversion of document I’m working on.

Well, unfortunately not… This incantation (haven’t yet found what actual Menu item this might be) works to give me a Multiple Selection. All formatting is blanked, likely as proper and intended. But on an older version Project brought into Beta 21, a Convert shows no choices dialog, and does nothing, just as before, on anything that is (or has been, by prior test) a folder.

So I think the underlying problem is not in selection, but in what data structure is left after the document itself is opened and converted from a prior version of Scrivener.

Apparently Documents > Convert > Text to Default Format is in that case unable to identify the selection that is made for folders by any method, whether local folder, or multiple-select-folder.

To complete, yes, on a fresh Beta 21 project, Convert works fine with this Multiple Select basis, as it does for Subdocuments selects.

Of course I would agree. And that’s where my moment of extension into handling Scrivener’s depth of complication due to its very considerable actual range of powers comes in. I don’t feel it’s only mostly-hidden bugs we’d be concerned about.

I’m very far from on the payroll, of course, but I have dealt with such things professionally. In fact, recently returning to quite long-ago chops to support my fiction writing at this stage, in a ‘little’ project to add instant content editing previews for normally not-previewable compiled websites on Gatsby or Gridsome, I had to actually add a friendly and calibrated-wittiness robot to it, minding all the things young programmers can get wrong and coaxing them-- because some of this is unavoidably complicated.

It’s a real digression for a moment here, but what occurs to me to wonder might be good for Scrivener could possibly be some combination of a mentioned Simplified Mode for the program itself, to invite writing as if there’s no tomorrow for just anyone, backed by a very rapid look-up Helper on the website, which could let you instantly find how-to-dos on the deeper capabilities.

The web side could easily be also a service ‘appearing’ directly within Scrivener itself. Which would allow one to run Scrivener as Simplified, were that available,yet use any of the under-the-hood features with some comfort.

The content for the helper could be drawn out of all your composed manual efforts, being much easier to approach in small, focused tidbits. The ‘instant’ part of it could be provided using a very wonderful and capable cloud add-on called Algolia. They’re very fast in use, are already pretty clever in engineering so that queries can be tolerant, and I just looked to find them as carefully edging into more real natural language (and voice?? Siri-ish) capabilities. A good bunch, widely appreciated.

So, you can tune all that out, but somehow felt to offer it for thought, for possibly interesting futures. You can pay me later for all this troubleshooting, if it isn’t offset by having to read the preceding imagination :slight_smile:

It makes me smile to see you’re still in Santiago Compostela, Ioa. Long lives in places add much, not least along the lines John Fowles took some lead towards once. I find it interesting to read him sometimes again, now hearing the voices more in their real tones, not to say senses of the subtler matters. And Spain…there is a kind of marvelous, huge place. I hope you’re getting to explore it far as well as near. Each part differing, reached by substantial journeys that can make you feel a real Don Quixote, or how his sense of travels may have come to be.

Hope your siesta didn’t get interrupted…

Well, a p.s. is in order, @AmberV.

On the senses of experience, and what always occurs to you after making a definite statement about how it might be not entirely so, I went back and checked some more.

This is a pretty peculiar problem, in that now with this third or fourth re-trial session, I can’t seem to replicate it on fresh copies of the Tutorial. (???). Non sequitor,

However, I do replicate it on one more, simply freshly converted ‘older’ project. This one was short, and I’ve cut it down further – it was actually just a test file using some fragments to experiment with the then-new Scrivener Win 3. I would imagine vs. Scrivener iPad running on an old iPad 2, and added to later, so it was very likely to a certainty touched by that also.

This file solidly does not show anything, nor do anything, when a folder and content are selected via Subdocuments (which shades correctly), or your all-select incantation, and then Documents > Convert > Text to Default Formatting is clicked. Nothing happens. No changes are made. That’s the problem I’ve been describing.

Happy enough to send this project zipped, if you’ll let me know where.

Well, and a p.p.s., if we still remember that form…

It bothered me that magicallly at some point Conversions seemed to operate on the new Tutorial shipped with 21, which is where I first checked after encountering the problem on my own projects. So, later I looked once more.

There may be some confusion as to just which Tutorial copy gets opened after you’ve saved your own, from the Open button on the Template selection dialog, so I simply copied the Tutorial unzipped from the Scriv installation in Program Files, then opened on this copy.

Once I did that, back to the same problem. Consistently, after Edit > Select with Subdocuments:

  • File collections showed the dialog allowing fonts-only, etc. on Documents > Convert > Text to Default Formatting, and indeed the conversion happened (I just used visible font changes)
  • Folder collections gave no dialog response to Documents > Convert > Text to Default Formatting, and no conversion happened
  • Strangely or not, Ioa, your Alt-]Ctrl-A full document select did convert all, including those stubborn folders, everything but actually styled text in their docs, which is right since I set fonts-only.

Here then is a little analysis, as it occurs to me, and then I think I’m done here, other than the offer to send Projects.

  • I thought for a while there might be an order-of-operations issue here, for when you set the new Default Format, but appears not
  • As an extra, the Project Settings gear icon is consistently appearing darkened when you drop the Project menu down to find it. I’m using the Dark Scheme at the moment if that matters – it may.
  • The reported problems occur on the new Tutorial, specifically the Getting Work In and Out folder I was testing most of the time, and specifically not on the File container just above it, Corkboard and Outliner Tricks.
  • They occur on many if not all of my long-term projects, which have been opened in iPad as well as previous Scrivener Win 3. I can’t tell which would have been initially upgraded from Scrivener Win 1; probably many of them, given breaks in work.

Bounding case and sum-up:

  • Just to put the lid on this, I actually began by doing the copy-from-program-installation routine for the Scrivener 1 Tutorial, from Scrivener 1.9.8.0 . Beta 21 Scrivener 3 converted this, and I didn’t find these issues on that conversion. With my no-problem on newly created Projects, this would seem to bracket the trouble as developing somewere in the earlier days of Scrivener 3.
  • Once again, the problem doesn’t appear to be exactly with selection, but with the Convert preparation being able to recognize that a selection is viable for conversion. This is a bit offset by the fact that a full-project-select actually does do the problem folders, but that may give a way to discover what’s up, as it starts on what appears to be a collecting folder. What differences in their data structure actually is missing or altered out to be visible by inspecting both (at developer level, not Scrivener Inspector, just to make clear for casual readers).

Cheers, Ioa.

This was not a lot of fun, as you’ll understand, but sometimes we have to really work to pin something, and I hope it will be worth it in contribution. Your select-all then convert incantation does actually seem a work-around, given it always functions as it does on the problem Tutorial, so thanks again for that. And just forget about my design musings, no doubt; I leave them just in case they someday may spark something.

Clive