Hi all, I’m new to EagleFiler although I’ve been following it for quite some time. I’ve been a long-time Yojimbo user but am extremely enthused by the active community around EagleFiler and especially by the active participation of the developer, Michael.
One of the things that I use these organizers for is storing bits of source code that I’ve picked up here and there. It would be extremely cool if EagleFiler supported colorized syntax and/or line numbers.
Thanks for the suggestions. EagleFiler does support colorized syntax for .plist files. Which other languages would be the highest priority for you?
I tried to copy a plist to EagleFiler but I wasn’t able to view the file. I get a “No Selection” in the content pane. Am I doing something wrong?
On the question of the languages, I personally store (in order of frequency) Java, AppleScript, SQL, Python, and Ruby snippets the most. However, I would totally understand if you implemented it according to your own needs or the popularity of different languages.
Would it make sense to use the syntax capabilities of some other program like vim or TextMate to be able to leverage the work done for those platforms?
BTW, I’m completely blown away by your responsiveness!
I don’t know. Could you post a screenshot showing what you did?
Try highlight?
highlight (as used by the Quick Look generator QLColorCode) seems to do a great job at whatever I throw at it. I hadn’t thought about using EagleFiler to store code; what a good idea…
I’ll certainly give that a try—thanks. There are some other possible contenders, though. In any case, I’m looking forward to using EagleFiler to search and browse syntax-highlighted sample code.
I think I figured it out. EagleFiler appears to render binary plists perfectly fine but doesn’t work with the XML versions. I can post a screenshot but I don’t think it’d be helpful - EagleFiler literally doesn’t acknowledge the change of selection. It seems to shows whatever it was showing previously.
There’s also the GNU source-highlight code although the GPL may be an issue.
Just a thought but as a broader approach would be to allow for user-defined “filters” and/or “processors” before rendering a certain. So essentially allow certain files (either through extensions and/or explicitly set on the file) to pipe their content externally to a program and/or AppleScript and then render the results in the view pane.
I can just think of all the fun I’d have. Syntax highlighting, Markdown, Textile, decryption, and much more. Heck, you’d even be able to essentially pipe the entire file as a script itself and render dynamic content.
It’s working fine for me with XML plists. Please create a test library containing the one that doesn’t work for you and e-mail it to me.
This is an interesting idea, although I wonder whether handing so much control to other processors would make it difficult to support editing.
I think all edits would have to be on the source code so there’d have to be the distinction between viewing vs. editing. But I have to admit that I salivate at the idea. It’d certainly be a distinctive feature that I’ve never seen anywhere else.
It looks like the problem is not that the file is XML but that its top-level element is an <array> when EagleFiler was expecting a <dict>. I’ll fix this in the next version.
EagleFiler 1.4.3 can display property lists with different top-level elements.