4 ms·

Anecdotally, this is exactly the sort of thing I have never needed while using vim on a server. Just let me modify content in the word hole...

by t4nkd 10y ago

JoshTriplett 10y ago
vim isn't the "on a server" editor for me, it's the "everything" editor. I like that it works the same way everywhere, but I primarily use it to edit files that do have recognized filetypes. (As an aside, for me the main value of syntax highlighting isn't the normal case, but rather the case where the syntax highlighting emphasizes a problem, such as an unterminated string or other typo.)
- Annatar 10y ago
  I like that it works the same way everywhere, but I primarily use it to edit files that do have recognized filetypes. UNIX doesn't care about filetypes, since the paradigm is working with binary streams of data, and it's implemented in a way that users don't need or have to care either. File types are a concept from MS-DOS, popularized by Windows, and a major hindrance to a UNIX user's workflow.
  - flukus 10y ago
    So if we look through the source tree of a random unix I won't find any .h or .c files?
    - Annatar 10y ago
      You are likely to find .c and .h files, but for UNIX, that is also just another stream of bytes - it cares not that the stream of bytes happens to be in the ASCII, 7-bit range. Where are you going with that?
      - flukus 10y ago
        The point is .c and .h are recognized file types and Unix has them.
        Annatar 10y ago
        UNIX doesn't treat them in any special way. There is no such thing as file types on UNIX. That concept does not exist, nor is it needed on UNIX. If one wants to classify a file at-all-costs, we have the file(1) command on UNIX, and that command consults /etc/magic (see magic(4)); if magic(4) does not contain the required byte stream excerpt, the output of the file(1) command will be an untrustworthy approximation at best. And still, the file(1) command is strictly for humans who feel the need to classify-at-all-costs, not for the operating system.
        flukus 10y ago
        Windows doesn't treat them in an special way either. You can open a text file with any/no extension.
        Annatar 10y ago
        You can, but Windows will ask you which program to open it with every time, because it uses extensions to classify file types, and since the file doesn't have an extension, Windows is incapable of handling it automatically. The fact that it has to handle files at all is a lost cause, conceptually. One bad decision begets another in Windows, which is all well and good, just not when that nonsense starts permeating into UNIX, where it is neither wanted nor needed - it's an artificial, unnecessary thing there.
        flukus 10y ago
        A Unix desktop environment will do the same, they use extensions as conventions, it's no different to Windows.
        10y ago
  - JoshTriplett 10y ago
    Vim recognizes and cares about file types. If I edit a file with "#!/bin/sh" at the top, I'd like vim to provide syntax highlighting for a shell script. And if I edit a file named "*.c", I'd like vim to provide syntax highlighting for C. That highlighting makes it far easier to spot typos. UNIX didn't support a wide variety of things people expect and find more user-friendly on modern systems. At an OS level, the OS should absolutely treat everything as a bag of bytes; that doesn't mean every tool built upon it should.
    - Annatar 10y ago
      Vim recognizes and cares about file types. If I edit a file with "#!/bin/sh" at the top, I'd like vim to provide syntax highlighting for a shell script. Well I wouldn't, and the entire purpose of using UNIX or a UNIX-like operating system is that such things are a strictly intimate, individual, private affair. The example you cite serves extremely well for the purpose of illustration, of how there are no file types in UNIX, and how neither the operating system, nor the user should care. Why should the user care? For example, I don't want files in the bin/ directory to have .pl, .py, .sh, .exe, or .com extension! Does it have an x bit set, thereby being executable? It does? OK, run it, and I couldn't and shouldn't care less what it's written in, because that's the main reason why I use UNIX to begin with! Same for coloring: I hate colors in vim(1); hate, hate, hate, and do not need or want coloring in order to spot syntax errors, as I have the compiler, the linker, and the shell's set -x for that ("do one thing, and do it well")! Why should I suffer if you like colors and syntax highlighting? That should, and on UNIX is, an entirely private affair. GNU/Linux broke that, because users came from Windows, expecting GNU/Linux to behave like Windows but with a shell which isn't braindead. If I wanted to use Windows, I would be using it. If I wanted to use an integrated development environment again, I would be using it instead of vi(1) to write code. vi and vim, by the way, are text editors, dedicated to doing one thing and doing it well, and to expect them to behave like an integrated development environment leads to sadness, pain, misery and confusion. UNIX does not have, recognize, or care about file types; consequently, it is up to the application to implement mechanism for dealing with the stream of bytes which the operating system does provide. In your case, that application is vim(1), and the file type recognition is proprietary to it. It has nothing whatsoever to do with the operating system. On AmigaOS, where vim(1) comes from, no such vimrc file is provided; consequently, vim(1) doesn't treat .h, .c, or AmigaDOS shell scripts in any special way. This is because AmigaOS does implement data types, which are generic file type drivers, and still neither the operating system, nor the user care about file type extensions! On Solaris and illumos-based operating systems, for example, vim packages do not deliver such customizations as they do on GNU/Linux, and consequently, there is no highlighting or any other special handling of .h, .c, or any other file type. (z/OS on the mainframe is even better, there are no files or byte streams to speak of, only records, and they are all binary.) It's just a very bad Microsoft screw-up from MS-DOS days which has conditioned an entire generation of hapless Windows-now-turned-GNU/Linux users to still think of files in terms of file types and integrated development environments, because MS-DOS and Windows came without dedicated tools out of the box, so people started writing one-program-does-it-all, monolithic applications. What would you do on z/OS, where there are no files, just records? This is one of the core concepts of UNIX: policy over mechanism; UNIX specifies policy (stream of bytes); mechanism is left up to the implementer. Rule of Separation: Separate policy from mechanism; separate interfaces from engines. http://www.catb.org/esr/writings/taoup/html/ch01s06.html#id2877777 http://www.catb.org/esr/writings/taoup/html/ch01s06.html#id2... As someone who authored XCB, you should be no stranger to separation of policy from mechanism.
chongli 10y ago
I must be weird or something but I've gone back and forth between vim and emacs for years before finally settling on just vi (Keith Bostic's nvi, to be exact). I've spent countless hours reading about and installing plugins on both of those big editors instead of just getting work done. Now that I just use vi, I realize how little of that stuff I need and how much I can get done with just macros and ! (the shell out command).
- JoshTriplett 10y ago
  I've encountered several quite painful behaviors of traditional vi that vim fixes. For instance, with traditional vi, if you start out changing a region, you can't move or change text outside that region without exiting insert mode.
  - chongli 10y ago
    I actually like that feature. I try to stay out of insert mode as much as possible. This feature lets me mash C-w or even C-u without worrying about changing text outside the original scope of my edit. I use the c command to change text inside of an html tag (for example) and I like that this protects me from damaging the tag itself.
  - Annatar 10y ago
    That's the way vi is supposed to work, since it is based on the paradigm of a modal editor. I learned vi in vi on UNIX, so the modal way stuck and I can glide and float between vi on UNIX and vim on Linux without getting busted on trying to move with cursor keys. I see Windows/Linux users get busted on that a lot, because they didn't install UNIX at home and learned on that first. It's frustrating to watch them get busted by that in person, over and over again.
  - Annatar 10y ago
    That's the way vi is supposed to work, since it is based on the paradigm of a modal editor. I learned vi in vi on UNIX, so the modal way stuck and I can glide and float between vi on UNIX and vim on Linux without getting busted on trying to move with cursor keys. I see Windows/Linux users get busted on that a lot, because they didn't install UNIX at home and learned on that first. It's frustrating to watch them get busted by that in person, over and over again.
Annatar 10y ago
Upvoted! Same here; I hate it when syntax highlighting makes it difficult for me to see the code, when I'm on a server and am just trying to get some work done. I cannot comprehend why I would want to see code in all those colors, with horrible contrasts, hard to read? Why? I know the syntax of the code, don't need or want anyone shoving what they think I need or want down my proverbial throat!
cma 10y ago
It can be pretty useful when editing a bash file and the color highlighting shows you a missed close-quote, etc. Same for config files.

Anecdotally, this is exactly the sort of thing I have never needed while using vim on a server. Just let me modify content in the word hole...

by t4nkd 10y ago

Anecdotally, this is exactly the sort of thing I have never needed while using vim on a server. Just let me modify content in the word hole...

JoshTriplett 10y ago

vim isn't the "on a server" editor for me, it's the "everything" editor. I like that it works the same way everywhere, but I primarily use it to edit files that do have recognized filetypes. (As an aside, for me the main value of syntax highlighting isn't the normal case, but rather the case where the syntax highlighting emphasizes a problem, such as an unterminated string or other typo.)

Annatar 10y ago
I like that it works the same way everywhere, but I primarily use it to edit files that do have recognized filetypes. UNIX doesn't care about filetypes, since the paradigm is working with binary streams of data, and it's implemented in a way that users don't need or have to care either. File types are a concept from MS-DOS, popularized by Windows, and a major hindrance to a UNIX user's workflow.
- flukus 10y ago
  So if we look through the source tree of a random unix I won't find any .h or .c files?
  - Annatar 10y ago
    You are likely to find .c and .h files, but for UNIX, that is also just another stream of bytes - it cares not that the stream of bytes happens to be in the ASCII, 7-bit range. Where are you going with that?
    - flukus 10y ago
      The point is .c and .h are recognized file types and Unix has them.
      - Annatar 10y ago
        UNIX doesn't treat them in any special way. There is no such thing as file types on UNIX. That concept does not exist, nor is it needed on UNIX. If one wants to classify a file at-all-costs, we have the file(1) command on UNIX, and that command consults /etc/magic (see magic(4)); if magic(4) does not contain the required byte stream excerpt, the output of the file(1) command will be an untrustworthy approximation at best. And still, the file(1) command is strictly for humans who feel the need to classify-at-all-costs, not for the operating system.
        flukus 10y ago
        Windows doesn't treat them in an special way either. You can open a text file with any/no extension.
        Annatar 10y ago
        You can, but Windows will ask you which program to open it with every time, because it uses extensions to classify file types, and since the file doesn't have an extension, Windows is incapable of handling it automatically. The fact that it has to handle files at all is a lost cause, conceptually. One bad decision begets another in Windows, which is all well and good, just not when that nonsense starts permeating into UNIX, where it is neither wanted nor needed - it's an artificial, unnecessary thing there.
        flukus 10y ago
        A Unix desktop environment will do the same, they use extensions as conventions, it's no different to Windows.
        10y ago
- JoshTriplett 10y ago
  Vim recognizes and cares about file types. If I edit a file with "#!/bin/sh" at the top, I'd like vim to provide syntax highlighting for a shell script. And if I edit a file named "*.c", I'd like vim to provide syntax highlighting for C. That highlighting makes it far easier to spot typos. UNIX didn't support a wide variety of things people expect and find more user-friendly on modern systems. At an OS level, the OS should absolutely treat everything as a bag of bytes; that doesn't mean every tool built upon it should.
  - Annatar 10y ago
    Vim recognizes and cares about file types. If I edit a file with "#!/bin/sh" at the top, I'd like vim to provide syntax highlighting for a shell script. Well I wouldn't, and the entire purpose of using UNIX or a UNIX-like operating system is that such things are a strictly intimate, individual, private affair. The example you cite serves extremely well for the purpose of illustration, of how there are no file types in UNIX, and how neither the operating system, nor the user should care. Why should the user care? For example, I don't want files in the bin/ directory to have .pl, .py, .sh, .exe, or .com extension! Does it have an x bit set, thereby being executable? It does? OK, run it, and I couldn't and shouldn't care less what it's written in, because that's the main reason why I use UNIX to begin with! Same for coloring: I hate colors in vim(1); hate, hate, hate, and do not need or want coloring in order to spot syntax errors, as I have the compiler, the linker, and the shell's set -x for that ("do one thing, and do it well")! Why should I suffer if you like colors and syntax highlighting? That should, and on UNIX is, an entirely private affair. GNU/Linux broke that, because users came from Windows, expecting GNU/Linux to behave like Windows but with a shell which isn't braindead. If I wanted to use Windows, I would be using it. If I wanted to use an integrated development environment again, I would be using it instead of vi(1) to write code. vi and vim, by the way, are text editors, dedicated to doing one thing and doing it well, and to expect them to behave like an integrated development environment leads to sadness, pain, misery and confusion. UNIX does not have, recognize, or care about file types; consequently, it is up to the application to implement mechanism for dealing with the stream of bytes which the operating system does provide. In your case, that application is vim(1), and the file type recognition is proprietary to it. It has nothing whatsoever to do with the operating system. On AmigaOS, where vim(1) comes from, no such vimrc file is provided; consequently, vim(1) doesn't treat .h, .c, or AmigaDOS shell scripts in any special way. This is because AmigaOS does implement data types, which are generic file type drivers, and still neither the operating system, nor the user care about file type extensions! On Solaris and illumos-based operating systems, for example, vim packages do not deliver such customizations as they do on GNU/Linux, and consequently, there is no highlighting or any other special handling of .h, .c, or any other file type. (z/OS on the mainframe is even better, there are no files or byte streams to speak of, only records, and they are all binary.) It's just a very bad Microsoft screw-up from MS-DOS days which has conditioned an entire generation of hapless Windows-now-turned-GNU/Linux users to still think of files in terms of file types and integrated development environments, because MS-DOS and Windows came without dedicated tools out of the box, so people started writing one-program-does-it-all, monolithic applications. What would you do on z/OS, where there are no files, just records? This is one of the core concepts of UNIX: policy over mechanism; UNIX specifies policy (stream of bytes); mechanism is left up to the implementer. Rule of Separation: Separate policy from mechanism; separate interfaces from engines. http://www.catb.org/esr/writings/taoup/html/ch01s06.html#id2877777 http://www.catb.org/esr/writings/taoup/html/ch01s06.html#id2... As someone who authored XCB, you should be no stranger to separation of policy from mechanism.

chongli 10y ago

I must be weird or something but I've gone back and forth between vim and emacs for years before finally settling on just vi (Keith Bostic's nvi, to be exact). I've spent countless hours reading about and installing plugins on both of those big editors instead of just getting work done. Now that I just use vi, I realize how little of that stuff I need and how much I can get done with just macros and ! (the shell out command).

JoshTriplett 10y ago
I've encountered several quite painful behaviors of traditional vi that vim fixes. For instance, with traditional vi, if you start out changing a region, you can't move or change text outside that region without exiting insert mode.
- chongli 10y ago
  I actually like that feature. I try to stay out of insert mode as much as possible. This feature lets me mash C-w or even C-u without worrying about changing text outside the original scope of my edit. I use the c command to change text inside of an html tag (for example) and I like that this protects me from damaging the tag itself.
- Annatar 10y ago
  That's the way vi is supposed to work, since it is based on the paradigm of a modal editor. I learned vi in vi on UNIX, so the modal way stuck and I can glide and float between vi on UNIX and vim on Linux without getting busted on trying to move with cursor keys. I see Windows/Linux users get busted on that a lot, because they didn't install UNIX at home and learned on that first. It's frustrating to watch them get busted by that in person, over and over again.
- Annatar 10y ago
  That's the way vi is supposed to work, since it is based on the paradigm of a modal editor. I learned vi in vi on UNIX, so the modal way stuck and I can glide and float between vi on UNIX and vim on Linux without getting busted on trying to move with cursor keys. I see Windows/Linux users get busted on that a lot, because they didn't install UNIX at home and learned on that first. It's frustrating to watch them get busted by that in person, over and over again.

Annatar 10y ago

Upvoted! Same here; I hate it when syntax highlighting makes it difficult for me to see the code, when I'm on a server and am just trying to get some work done. I cannot comprehend why I would want to see code in all those colors, with horrible contrasts, hard to read? Why? I know the syntax of the code, don't need or want anyone shoving what they think I need or want down my proverbial throat!

cma 10y ago

It can be pretty useful when editing a bash file and the color highlighting shows you a missed close-quote, etc. Same for config files.