C-Command Software Forum

Option to force treatment as package?

This relates a bit to an earlier thread about Skim’s pdfd files.

What I was wondering about was whether it would be possible/easy to have a flag on certain folders that you could set in order to treat them as “opaque” for the purposes of EagleFiler’s management – that is, to set a folder to be a “package” from EagleFiler’s perspective, even if it is not a package from the Finder’s perspective.

The reason I ask is that I’ve been doing a fair amount of work in LaTeX recently, which causes a mess of files to be created and recreated around the source file when it is rendered.

What I have been doing is this: iTeXMac2 defines a “.texd” package type, and, although I do not use iTeXMac2 (I use TeXShop), installing it allows me to create a folder, put a .tex file in it, and then rename the folder to end in “.texd” (causing a warning from the Finder, after which the folder becomes a package), then drop the folder/package into EagleFiler. Then, to edit the file, I find the package in EagleFiler, reveal it in the Finder, right-click to reveal package contents, and double-click on the .tex file within to open TeXShop.

This works well enough: EagleFiler doesn’t care about all of the .aux and .dvi files that appear within the .texd package, but will still notice when things have changed.

However, because the Finder/OS considers it to be a package, there are certain inconveniences that it causes. For example, the “revealed contents of the package” windows are not saved, so when the Finder is next started, those windows have to be re-opened. It is also nearly impossible to “Save as…” from any application into a package folder, and dragging a file from within a package folder onto, e.g., EagleFiler, results in an attempt to import the package rather than the file (this is something I do with the ultimately generated pdf file – at the moment, I have to copy it out to a regular folder, then import it into EagleFiler).

It would be nice if I could get the EagleFiler benefits of having a package folder (which is pretty much the only reason I put these things in .texd packages) without have the Finder/OS headaches of having a package folder. Although this might be the kind of thing that only 7 people in the world will use (and, admittedly, it might be a bit confusing as an option presented to the rest of the world, who will wonder what it means and what it’s for), it would be great if it is easy for the EagleFiler database to contain a flag that would tell EagleFiler to treat the folder as an unanalyzable atom.

As far as the UI implications, I guess the flag would have to be set from the Info inspector (and perhaps hidden unless an esoteric preference is turned on), and perhaps an indication in the records list (like a folder with a lock or package icon on it).

I don’t know whether this is easy or difficult, but if it’s easy, I’d find it useful. (Well, I’d find it useful if it were difficult too, but I’m not sure I’d find it enough more useful to justify the difficulty.)

One last note on this is that it is possible that this would simply be moot if EagleFiler could scan for orphaned files in the library (things that are there but EagleFiler didn’t know about previously), and I know that this has been on the “to do” (or at least the “to consider”) list for a while, so if that is still on its way, this “package flag” probably wouldn’t be worth the trouble.

I think I see the issue you’re getting at, but I’m not sure that folders/packages is the proper way to look at it. To start with, what are your ultimate goals? My guess is that you want the .tex and .pdf files to be visible (and searchable) in EagleFiler, but you want it to ignore the .aux, .dvi, .toc, .out, etc. files.

You can get this behavior today if you import a folder containing just the .tex and .pdf files. If you later run LaTeX, it will generate the other files, but EagleFiler will ignore them. I think this is much better than using packages because you can view the .tex and .pdf files in EagleFiler, they’re indexed for searching, and you can also edit the .tex file.

In the future, EagleFiler may get a feature to scan for new files that were added to the library folder. In that case, perhaps there should be an option to ignore certain extensions so that it doesn’t detect the .aux files, etc., and clutter the display with them.

Hi, thanks for the quick reply.

I think you’re right. I have made this a bit more complicated than necessary. I have always been perhaps a little bit overly jittery of having things in the EagleFiler library folder that EagleFiler doesn’t know about. But, yes, now that you say that, I think I’ll do it just the way you suggest.

I did try a couple of things just now. First, Export from EagleFiler of a folder that contains things not in EagleFiler’s record does export the entire contents (including the files that EagleFiler doesn’t have a record of), so that’s safe.

Second, if I create a .tex file, put it in the EagleFiler library somewhere, open and render it to a .pdf file, the .pdf file is now there in the Files folder but EagleFiler doesn’t know about it. Simply dragging it onto EagleFiler (in its correct destination – that is, where it already is) will not work – there is a error saying that the file is already in the library. So, in order to register the pdf with EagleFiler, I need to drag it out of the library to somewhere else, and then drop it back in (and then delete the original).

So, maybe here’s a different request: Would it be possible to, instead of putting up the “file is already in the library” message, import the file where it is? (What I have in mind is the case where the location being copied from is identical to the location it would be placed – so, this wouldn’t apply if I tried to drag a file from outside that just had the same name as an unknown file within the EagleFiler library).

I think with that, this procedure would all be as seamless (and uncluttered) as I could hope for.

Yes, that’s why I suggested pdflatexing it before importing.

Yes, I’m looking into that as part of the aforementioned orphaned/stray files project.

EagleFiler 1.5’s Scan for New Files feature will auto-detect new files that are added to the library folder.