Window size is locked when opening unrecognized file
If I open a file with an unrecognized format (non-UTF8), a warning is displayed in a window of fixed size. Choosing an alternate stylesheet from the menu at bottom-left allows me to view the parsed document (at least for external parsers - I'm using rST), but I can't resize the window.
I would expect that either (1) I would be prevented from taking any actions on the window (such as choosing a stylesheet) or, preferably, (2) I would be able to resize the window.
-Matthew
Keyboard shortcuts
Generic
? | Show this help |
---|---|
ESC | Blurs the current field |
Comment Form
r | Focus the comment reply box |
---|---|
^ + ↩ | Submit the comment |
You can use Command ⌘
instead of Control ^
on Mac
Support Staff 1 Posted by Brett on 17 May, 2012 04:46 PM
If it's parseable, it should be opening without error. I don't want to make the error nib resizable, I'd rather just avoid showing it in cases where you can actually get a parser working. Can you post a copy of a file that this happens on for testing?
Support Staff 2 Posted by Brett on 17 May, 2012 04:48 PM
If it's parseable, it should be opening without error. I don't want to make the error nib resizable, I'd rather just avoid showing it in cases where you can actually get a parser working. Can you post a copy of a file that this happens on for testing?
3 Posted by Matthew on 17 May, 2012 06:52 PM
Hi, Brett. Thanks for the quick reply.
Here's an example file. It's a mess (that's why I'm working with it), but it is parseable (with errors).
My custom markdown processor is /opt/local/bin/rst2html-2.7.py from the MacPorts py27-docutils port.
-Matthew
Support Staff 4 Posted by Brett on 17 May, 2012 07:16 PM
Do you know offhand what encoding it's using?
5 Posted by Matthew on 17 May, 2012 07:20 PM
I'm not sure what it was written in originally, but the
file
command reports:bbpasswdchange.rst: Non-ISO extended-ASCII English text
Support Staff 6 Posted by Brett on 17 May, 2012 07:39 PM
Is this a common occurrence? That's an encoding that I can't easily account for. Can you just save as UTF-8, or is there an editor that's producing these by default?
I've fixed it for the next version so that you should never be able to get to the file from the error window, but I can't -- at least for the moment -- find an easy way to handle this encoding.
7 Posted by Matthew on 17 May, 2012 09:11 PM
This is the first time it's happened to me. Apparently that file was created in Notepad++ on Windows. I think your choice of solution is appropriate.
I'm curious though, why are you checking the encoding at all when an external parser is selected?
-Matthew
Support Staff 8 Posted by Brett on 17 May, 2012 09:26 PM
Because Marked will open _any_ file. If it can't read it as a text file, it has to kick it out. I could see an argument for opening any file when using a custom processor, but the potential reasoning for doing that stretches far beyond Marked's intended purpose, I think.
9 Posted by Matthew on 17 May, 2012 09:51 PM
Ah, that makes complete sense.
I do notice that
file -I <filename>
includes a MIME type. For this problematic file, it does reporttext/plain; charset=unknown-8bit
. I'm not sure if you can depend on that text/* for everything you're interested in opening, but it might be an option worth investigating.Thanks for talking it over with me, and thanks for Marked.
-Matthew
Support Staff 10 Posted by Brett on 17 May, 2012 09:59 PM
Sure thing.
MIME (and UTC in general) are entirely unpredictable. I originally thought I could just look for text/plain and public.plain-text, but boy was I wrong :).
11 Posted by John on 23 Jun, 2012 10:55 PM
I'm having a similar problem. However, for me Marked.app seems to think that my .md files are not readable, if they are managed by iCloud, under ~/Library/Mobile Documents (mine are under Byword), as described in another tip here in the support discussions. The only way I can get Marked to properly load my iCloud-managed .md files is to rename them with a .txt extension. Not ideal, as the documentation for Byword states that by default the MarkDown features are only enabled for files with a markdown extension (i.e. .md, .markdown, etc.).
Also if I have a .md file managed anywhere else on the filesystem, then choose to move them to iCloud, Marked properly detects the move, but (boom) it loses the ability to read them,complaining about the codepage.
Support Staff 12 Posted by Brett on 24 Jun, 2012 12:43 AM
When the files are in iCloud, what method are you using to open them?
-Brett (on iPhone)
13 Posted by John on 25 Jun, 2012 06:28 PM
Sorry for my delay here. Did a bit more testing, and I can't seem to reproduce what I thought I was seeing.
It seems that the trouble is mainly when moving a document to iCloud, when Marked is viewing it. Marked seems to be aware of the move, but it stops displaying the file, complaining about the codepage, as described earlier.
If I open the document again, using any means (i.e. File/Open -> ~/Library/Mobile Documents/...byword... , or by dragging the document from there onto Marked.app in the Dock, it seems to pick up again fine.
I do however have to close the previous window. As Matthew has described, the window size is locked after displaying the codepage error.
Support Staff 14 Posted by Brett on 06 Jul, 2012 01:35 PM
I'm not sure why that's happening, but I'll look into it. Due to the way Marked works, it does expect a file to remain stationary while the document is open, and isn't entirely flexible on that. I would like it to be. I'll research a solution for that and any special circumstances surrounding iCloud.