[PeterisP]

1) Going to a specific location (e.g. a location that shows up in some error log about processing that data file) and eyeballing it. Being able to go to a specific location is sometimes important (e.g. row 12873, character 233). Syntax highlight is important, it sometimes makes obvious something that's subtly malformed. Syntax highlight that doesn't take an eternity for large files is a hard issue.

2) regex search/replace - interactive grep/sed.

3) Very large edits - e.g., find a specific location and remove all data entries before that so that the problematic entry now would be the first one; essentially cutting away half of a very large file.

4) Do note that you might have very, very large lines - it's not that uncommon to have the whole file in a single line, e.g. non-pretty-printed json data. Some editors work well with large files but simply die if there's a line with a million characters.

[martanne]

Thanks for the feedback!

Yes syntax highlighting for large files is a hard issue. I'm not really aware of an accurate an high speed solution supporting editing operations in huge files.

In principle the underlying data structure used by vis supports all modifications with linear complexity in the number of editing operations since file load. This is independent of the file structure (i.e. single line files should be well supported). However the frontend code hasn't yet been optimized so in practice there might be some problems.

Unless one specifies the blackhole register when deleting large parts of a file this will create an in memory copy (to enable later pasting at a different location). Better would be to keep a reference to the existing immutable text region.

[Shorel]

Another thing I sometimes do:

Open a medium sized file in some format (CSV for example)

Select all

Change the selection to individual selections, one per line.

Edit in parallel, doing the same edit to all lines.

When the file is not that big, this sequence of actions is amazingly fast in ST.

[Elrac]

Just for backup on the large lines thing:

Many years ago, one compelling feature about Lugaru's emacs-family Epsilon (recently discussed here on HN) was the fact that you could quickly load _any_ file, with maximum sizes several times the available system memory, and completely regardless of text structure. You could load a fat binary, e.g. WORD.EXE, edit character strings in it, save it, and if you carefully avoided changing sizes and offsets, have a still-working .EXE program.

This is of course a slightly off-the-wall use case for a text editor, but if you happen to need that kind of thing you'll be really grateful if you have an editor that can do it.