Warn before opening large files.

[HT-7]

In Nemo (Linux Mint), unknown file types such as "jsonlz4" are associated with xed, even though they contain binary data not useful to Xed.

When opening a file that is too large in Xed, it hangs up and must be taskkilled, leading to the loss of any unsaved work.

Please warn before opening large files. Thanks.

Notepad on Windows does that too since at least Vista.

[mtwebster]

Xed does not open those files by default (the archive manager tries to, though in this case, lz4 isn't currently supported).

Any unknown type should get a message if you double-click, asking you to choose a program. You can reset the default action if xed (or any other program) has accidentally been set to open the wrong file type:

• Right-click on the file in nemo
• Select Open with... -> Other application
• Here you should be able reset it to its default handler:

[HT-7]

Xed does not open those files by default (the archive manager tries to, though in this case, lz4 isn't currently supported).

Somehow mine does. Nonetheless, Xed needs to warn before opening large files.

[zahlman]

Today I tried to right-click->open an extension-less file with Xed, expecting it to be a short chmod+x shell script. It was, in fact, a 40 meg ELF binary. After several minutes (I had some other rather important unsaved changes in other documents) it eventually showed a new tab, allowed me to click over to that, allowed me to hit a Cancel button and acknowledged that. It's not at all a pleasant experience.

Expecting the OS to guard against this, or telling users to disassociate the files from Xed, is therefore not sufficient. There are valid reasons to choose the application directly: in particular, in order to view or edit an executable shell script rather than running it. I shouldn't have to validate the file type myself first when there is no file extension. This is Linux; file extensions are not the primary determiner of file types anyway. Aside from that, I would have to drop to the terminal to check, which defeats the purpose of having nice GUI programs like Xed (and Nemo, for that matter).

I suspect that the slow loading is not just due to the sheer size but issues caused by long "lines" in binaries (i.e., runs without bytes that would encode to a newline). In my testing, performance looks O(n^2) for extremely long single-line files, but it's only really noticeable as I approach the megabyte range. Depending on the nature of the file, of course, byte values may be distributed very non-uniformly.

I would like to see warnings in the following situations:

• The file size is above a configurable limit
• The first page or so of the file contains byte values 0..8, 11, 12, or 14..31 (i.e.: ASCII control characters except normal whitespace), unless the encoding has been guessed as UTF-16 or UTF-32.
• The first page or so of the file does not contain a newline

As a separate possible enhancement: perhaps if file loading were done in a separate process, the UI would at least be more responsive and allow for accessing and hitting the Cancel button sooner?