Skip to main content

[BUG] RTF files load as raw syntax in the editor

Completed

Comments

6 comments

  • Fletcher Penney

    What did you expect would happen instead of showing the file contents?

    0
  • AmberV

    If it's possible, I think a Quick Look preview of the file would be best, like it would do for PDF.

    0
  • Fletcher Penney

    This will require having a specific list of text file UTIs that we *don't* want to treat as text files, and therefore can't edit.

     

    I'll tentatively add this and "blacklist" `public.rtf`.  We'll have to monitor this over time and see if it's the best approach.

    0
  • Fletcher Penney

    Also -- I don't want this to turn into a never-ending laundry list of text files that should get special treatment.

     

    1. If there's a better algorithmic approach, we can certainly consider it.  Just have to be careful about edge cases.

     

    2. If we have to use a blacklist approach, then we'll have to be judicious about how long that list gets.

     

    Otherwise, users can always use the preferences to ignore files with certain file extensions.

     

    But for now we'll experiment with this.

    0
  • AmberV

    A never ending blacklist is a potential problem. Perhaps a reasonable determination for whether it should be done is if the format is one that is hardly ever (except by specialist coders) accessed as raw syntax. I think RTF is a good example of that---most people probably don't even know it's just a plain-text file that you can even create from scratch in a coding editor. Hmm, another one might be .scap files, from Scapple. Hardly anyone is going to get value from the raw XML, but the Quick Look preview on the other hand is just the kind of thing you might want (and by the way, that one works fine).

    A good counter-example would be HTML. Often viewed in a front-end, but also often edited by hand in an editor. I don't think nvUltra should be display HTML files as read-only Quick Look previews.

    Off-hand I can't think of many formats where Quick Look is the better option, especially since this kind of tool may be of considerable use to programmers of various ilk. Being able to store and work with code samples would be considered essential. It's not its primary purpose, being a Markdown-based editor (which may get in the way of some things), but for the most part it's a good all-around editor too.

    But clearly, this is all a discussion of blacklisting rather than an algorithm---a human determination on how files are most commonly useful.

    > Otherwise, users can always use the preferences to ignore files with certain file extensions.

    That's true, though I can see some utility in wanting to read these files rather than hide them entirely. If the idea is for this to be a general file viewer *and* Markdown note editor, that approach seems better for the types of files which have no value being in the list (like .git files), rather than to avoid files that display oddly.

    There probably isn't a really clean answer to the problem, alas.

    0
  • Fletcher Penney

    I'll mark this as completed for now, but if anyone has any better ideas than a manual blacklist, please let us know!

    0

Please sign in to leave a comment.

Powered by Zendesk