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.)
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.
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.
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.
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.
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.
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.
No they do not, what in the world gave you that impression?
UNIX desktop environments indirectly rely on /etc/magic to decide what to do with files. If you are using a desktop which actually maintains a database of file extensions and you also think that that is okay and that that is how things should work, you are on a wrong operating system, and Microsoft Windows or even MS-DOS is a much better fit for how you expect the OS to work.
Even so, a desktop environment on UNIX is just yet another application, sometimes it is just a single process. The operating system empathically does not provide any kind of file type recognition or handling for such a desktop environment application, and any such file type recognition and handling is proprietary to that application.
Since the core UNIX paradigm is one of everything is a file, and all files are nothing but a stream of bytes, the OS has no concept about the contents .h, .c, not shell scripts, let alone .wav, .au, or .mp3 files, for instance. The UNIX operating systems only deliver streams of bytes at the request of applications via the open(2) and read(2) system calls. That's policy. The mechanism of what applications (consumers) of that or those byte streams do with the stream is left up to the applications which consume the streams:
A Unix File Is Just a Big Bag of Bytes
A Unix file is just a big bag of bytes, with no other attributes. In particular, there is no capability to store information about the file type or a pointer to an associated application program outside the file's actual data.
That is KDE specific, and has nothing whatsoever to do with the OS.
How does your KDE handle file types when you are logged into a headless server, without any kind of graphics hardware, and your console is a serial port? How does the UNIX kernel handle file types when you're on a headless server with no graphics hardware, and your output is stdout on a teletype terminal or a nullmodem cable on a serial port?
I guess you missed the point of everything I've written so far. Did you read the links I provided?
(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.)