Cdtjkyj

I added the following to .bashrc to remap less to vim

alias vsi='vim -R -c ":map Q :q!<enter>" -' # Vim Standard Input [readonly]

alias less='vsi'

the reason is that I don't want to maintain two config files with my key bindings preference, and I find vim more useful and predictable (often I can't find the looked-up text because it's not highlighted or not in view)

it seems that less was developed after vi and more, because they couldn't open "enormous" files, what was considered "enormous" back then that vi and more couldn't handle? and is it not an issue today?

will this alias break scripts or programs that depend on less?

The viewing of incomplete input is an issue:

seq 10000 | pv -qL 10 | less

It could lead to unexpected behavior, for instance if the less command is issued with switches. I like to run less with the "-N" switch for line numbers, like so: less -N filename. When I alias less to vim, I don't get my expected line numbers (for vim, the "-N" switch is for "No-compatible mode" which makes vim "behave a bit better, but less Vi compatible" according the man page). Can you be confident your use case will never highlight less and vim's divergent behavior?

It will not break scripts or commands that depend on less since shell aliases would not be expanded for scripts or other commands.

Shell aliases are only there for convenience in your interactive shell session. They are not carried over into shell scripts and commands that you start from that shell session because aliases are not part of the environment that is inherited by child processes.

The only issue would be if you yourself forgot that you had this alias and then proceeded to use it with extra options in an interactive shell session. These options would then be given to vim.

You may also consider using view rather than vim -R.

Regarding "enormous files", these are files that are of sizes larger than your RAM, or at least of the same size a sizeable chunk of the available RAM. Traditionally, editors would load the whole file into memory as you opened them, and some still do this. Opening large files would therefore

1. be slow


2. potentially run the editor into a resource restriction (out of memory)

I believe that the Vim editor is working around this using its "swap files" (the ones that you may have seen with the .swp filename suffix). See :help swap-file in Vim.

The less pager will, by default, keep all read data in memory when reading from a pipe. If more data is read than there is available RAM for, you will have issues. Fortunately, there is a -B (or --auto-buffers) option that forces less to only keep the last portion of the read data in memory. However, this obviously makes it impossible to jump back to previously viewed lines of input.

The more pager is sometimes less in disguise (just a hard link to the less binary). On systems where more is actual more, the pager does not allow scrolling backwards when viewing data read from pipes.

Neither less nor more needs to read a file completely to be able to view the contents of it. Both would seek through the file to the appropriate location.