After a break, I returned to (I believe) all the same content and meta data etc. and compiled my module (book) using MMD → LaTex as before, with compiled data set to ‘Open in TexShop’
It opens alright and typesets fine (all good!)… but the actual compiled file / data is now encapsulated in a TexShop package… which I must open to access the *.pdf and associated image files etc.
I cannot locate a setting that might be the cause of this. It introduces extra steps for accessing my pdf which I would prefer not to be necessary.
Can anyone advise on (i) how/ why this is happening? (ii) workarounds?
No indeed, not that. it appears in the expected location, as a single file with the .tex extension… but it no longer opens in TexShop. Right-click in Finder reveals it is a packaged file (bit like a folder, but has to be deliberately expanded / viewed). The right click menu includes “Show Package Contents” which then reveals the expected set of files, including pdf …
Oh! That’s odd. It must be something you have installed that is registering the “name_of_something.tex” folder naming scheme as a “package” for some reason. That’s really the only way something like that could happen unawares. I don’t understand what the advantage of that would be to anyone, why would you want to hide your support files?
Well, we can presume it isn’t TeXShop doing it at least, otherwise it would open it. It must be something else that installed into the Applications/LaTeX folder (assuming you did a full MacTeX distro install). You can try uninstalling (putting in the trash temporarily) one by one until it goes away, and if it isn’t something you need, just leave it uninstalled.
Another approach would be to use the behaviour described in the user manual, §21.5.1, Compile Folder, where it describes how you can set up a persistent compile folder using a different naming scheme that shouldn’t trigger the OS into thinking it’s a package. Of course you’d have to do that every time you compile a new project, so figuring out the source might be better ultimately.
I’m now wondering if this might be caused by migrating from dropbox to icloud, which is easily reversed… however… Shoot. I’m also scuppered by upgrading to latext TexShop which always hates my compiled files and refuses to open. Back to version 4.4 before I can do any further testing.
Whatever the case it is nothing Scrivener is doing, nor is there to my knowledge any modern way to force a folder to be a package like that. You need it to be an instruction installed into the system that impacts all folders matching the name. Like how when you uninstall Scrivener, all of your projects turn into normal folders.
The original reason for ‘packages’ is that support files don’t get separated etc. Bit like compression packages.
Yeah, and I would say also the usability as well, of having something that should very rarely be considered for its parts, thus be primarily accessible as a singular object in file system usage. We would very rarely want to go into “Scrivener.app” for example, and almost always want to interact with it as though it were an executable. Likewise there is rarely a reason to go into a .scriv, we shouldn’t generally go into these things without knowing what we are doing.
But to do that for a folder of .sty, .png, .tex and other important files is where I’m a bit confused. None of those are things you need special knowledge to want to work with, and the desire to work with them would be high. And it’s the implication of how LaTeX works that makes it more confusing, since all of the working files and output tend to go in the folder. At least, I’m quite regularly looking at .log files and wanting to open the .pdf and so on.
It almost makes me wonder if it is a mistake, but maybe whatever software is doing this has some good reason for working that way. Perhaps it is an IDE type thing that exposes the contents in a sidebar.
Well, I’m just thinking out loud here, none of this is really driving toward a solution.
I’m now wondering if this might be caused by migrating from dropbox to icloud…
I don’t think that would be possible, given how packages work. It’s not based on which folder you save things into, it’s a global system condition that software enables upon installation.
(Well: since when did Apple and other big tech make sense
Early indications are that it was iCloud that caused it. Immediately switch back to Dropbox and it looked and worked just like it did before, i.e. as you’d expect.
So what is iCloud doing put .tex folder into a package? No idea right now!
Thanks again, muchly for your reflections. it really helps to get one’s own brain functioning to have an interlocutor to discuss it with
That’s very bizarre. It might imply that Apple is blindly assuming any folder ending in a “dot-something” pattern is a package if it is in the iCloud sync area.
You could test it by changing the folder name to “compiled.hah”, I guess.
Well at least you know where to compile for now, and there is always that other folder naming trick I referenced, if you would rather keep sync unified.
copying over package to dropbox: remains as package, regardless of whether extension removed (when it then appears as a folder (icon), but continues to act as a package)
compiling to dropbox folder reverts to typical prior behaviour
I did mention there was no “modern” way of setting a folder to be a package regardless of system configuration, but maybe that is still in use to this day. Back in the HFS+ days there was a “bundle bit” that could be set on any folder that would make it act like a package—this goes all the way back before Mac OS X. It’s been dynamically handled for so long by system configuration, that I figured they would have done away with it in AFPS. According to this page it is still a thing, though they refer to it as a “package bit” here.
So that would be something that sticks even if you drag it to another disk, and the only way to get it off would be to find a tool that can toggle that setting off (there is probably a command that can be used on the shell too).
So yeah, for whatever reason, I guess avoid compiling to iCloud.
First, I was able to change a folder to a bundle right in the Finder just by giving it a recognized file extension of ‘.bundle’.
BUT changing it back was more interesting, because folders don’t really have a dedicated file extension (I think). So, in a creative moment of arbitrariness, I changed the bundle’s extension to .jpg which the Finder took without objection but then also seemed to know better (MacOS Ventura here) – since the icon for the file switched to the generic folder icon. Using Get Info, I removed the .jpg extension. Get Info now correctly shows the Kind as Folder and all /seems/ well with my test folder as far as I can tell.
