Seeing long filenames in the file browser?
I work with lots of files that absolutely need to be prefixed so that they can logically be grouped together in the filesystem. the unique part of each filename is then appended to the prefix after a hypen.
i also run editorial on an iphone vs an ipad.
unfortunately, this means that when i try to pick files to edit in the editorial file browser, the "unique" part of the filename is always fully or partially "hidden" out of view due to the width of the pane that displays the filenames. thus, there is no way to quickly and simply pick these collections of files. the only way (that i currently know of) to see if i'm selecting the right file is to actually randomly select the prefixes for files i'm interested in and load each file individually to inspect them until i'm sure i have the right one. due to teh similar content of the files, even this above method isn't fullproof without additional reading / scrolling once the file is loaded to figure out what file i'm in. basically it's a very time-consuming, inefficient to edit files with long file names in editorial.
is there a way to "wrap the filenames" or some other setting in editorial so that i can see the full filenames or at least a lot more of each of them in the file browser? switching to landscape doesn't change that width of the file browser pane on my iphone so that's not an option either. am i missing a setting or is there a drop-in replacement that will do what i want?
Would folders named with your prefix help organize these files better? The files wouldn't need the prefix after being moved into the folders. Perhaps their filenames might display better?
hey @wbjethro that would be the simple filesystem solution but creates an extra layer of complexity and unnecessary navigation in the filesystem for files that are logically grouped imho. at that point i'd just be navigating up and down and back and forth to put myself in teh appropriate directories which would just add a different kind of extra "gesture" effort, brain drain and time to the basic operation of opening a file.
basically having multiple directories just shifts the same problem i'm having but to directory navigation. i have just the right amount of files where breaking them out into subdirectories doesn't pay any dividends and not enough to make navigating one directory a problem. the one directory solution make managing the files much easier on a laptop (where i have plenty of screen real estate) and then the eventual sync to the dropbox.
thanks for the suggestion though!
Perhaps your own custom table of contents file? I've never gotten relative links to work correctly in Editorial but its URL scheme works perfectly (in Editorial only, of course)
The table on contents entries look like this:
[**1400 - 1600**](editorial://open/1400-1600.md?root=dropbox) [**1600 - 1800**](editorial://open/1600-1800.md?root=dropbox)
Your file name can be as long as you prefer. Just remember to encode your links, such as spaces converting to "%20", etc.
If you prefer a "return" link to the table of contents file embedded in each document, you could use this:
[**Table of Contents**](editorial://open/TOC.md?root=dropbox)
so you're saying create another python script that reads the directory of files, converts filenames into markdown links, output to a file, which i make a bookmark out of to load in the internal editorial browser to jump back to editorial editor view of the file :)
i guess i could maybe just run the python file every time i wanted to pick a file to automatically open the editorial browser because it's going to have be constantly rebuilding the file anyway as i add files. maybe tie it to a quick snippet so the script is easy to access.
it's an option. thanks for the idea!
would still like to find something native if possible first and open to any other creative suggestions. long filenames are kind of common and for some reason i think an app's stock file browser w/should be able to support them out of the box
You could use a script or workflow to generate the link needed for the TOC but I do it manually. No scripts. The TOC is just another Markdown file. Swipe to preview, browse the file and select the file you wish to view.
ah i see.. you view the TOC natively as md and then swipe to preview it in the browser, touch the link and it returns you to the editor with filename via the callback.. gotcha..
still would like to see some other solutions hopefully a native one to the stock file browser if possible :) i think i may have just found a file brwoser workflow out there. i need to download it and see if it makes a difference or maybe can be modified in some way to do what i want.