Hacker News Reader

Comment by gbrown_ | Hacker News Reader

I have never understood the appeal of modelines. Why on earth would you put editor specific configuration inline with the file you are editing?

Thankfully I've had 'set nomodeline' in my config ever since I found out about this insane option.

View on HN

One use case for modelines was specifying the encoding of the file:

    # vim: set fileencoding=iso-8859-1

Trivia bit: the Python interpreter understands Vim and Emacs modelines as encoding declaration for source files: https://www.python.org/dev/peps/pep-0263/#defining-the-encod...

Another use case was specifying the indentation scheme for the file for weird conventions like "2 space indentation with 4-column tabs" (first level is two spaces, second level is one tab, third level is one tab plus two spaces...)

Fortunately now everything's UTF-8 and weird indentation schemes are uncommon.

I use them in Emacs occasionally. It's handy for stuff with ambiguous names. Makefiles (which dialect?), whatever.pl (Perl? Prolog?), whatever.asm/whatever.s (which architecture? Which assembler?), etc.

Also comes in handy for working with files that have an incorrect extension, for whatever reason, or different formatting from all the other files of that type that you work with. (Per-project formatting stuff can often by solved with .dir-locals.el, but not always.)

How do others feel about this when they open the files? Or are they not part of a shared project?

Nobody seems to care, and I can easily put them back in if somebody deletes them.

Modelines are pretty much only for single-use scripts or non important files but are still very useful (the security implications are concerning though).

Usually just to `set ft=zsh' to set a filetype on a file with no (or incorrect) file extensions. Which syntax highlighting and other plugins rely on to activate.

For example, I use them on a TODO.md file to set it as a `task` filetype which is a markdown-friendly todo list: https://github.com/irrationalistic/vim-tasks whereas in Github I want it to render as markdown only so I keep the file extension `.md`.

Another usecase is system/software user config files which have all sorts of file extensions (ie, `.rc` or '.conf') but use a variety of internal formatting (ie, json). These files never leave your personal machines or arrive that way, in my experience at least.

I'd imagine they'd also stick out like a sore-thumb at the bottom of most files if they were maliciously inserted but I'm sure there's some exceptions (targets who don't know what Vim modelines are).

Why not just set a shebang like

    $ cat foo.sh
    #!/usr/bin/env zsh
    echo $SHELL

Which most editors understand.

    $ file foo.sh
    foo.sh: a /usr/bin/env zsh script text executable, ASCII text
    $ vim --clean -c ':set filetype?' foo.sh
    ...
    filetype=zsh

This ALSO ensures that the correct shell is invoked on your script, instead of your current or default shell.

    $ ./foo.sh
    /usr/local/bin/zsh

If the script file is meant to be sourced only, then a shebang is bad style as it gives the wrong hints to human readers.

chmod -x

I don't see how that helps either of my examples (TODO.md, config files).

Even when it's actual part of ZSH script I'm only using `ft=zsh` when it's a file I'm sourcing, not intended as a runnable script by itself. For example: `~/.exports` which includes my PATH and env variables, as I also import it into `.bashrc` in addition to `.zshrc`.

Being fairly unobtrusive, I find modelines convenient for making explicit the proper indenting mode for source files. This is useful in distributed development, where the project doesn't specify a preferred code style. Even if other developers don't use vim, they should be able to understand how they are expected to indent their PR.

Moreover, they're super handy for loading the proper syntax highlighting when working with template engines (e.g. Jinja2) to produce anything other than HTML.

> Even if other developers don't use vim, they should be able to understand how they are expected to indent their PR.

I'd argue the use of a modeline to convey that is poor.

I've found them useful for settings the filetype when you don't have the mime-suffix or other easy method to identify it. But that's about it.

Presumably that's for something only you work on? Do others not find it confusing as to what that line is doing in the file?

Presumably it's no more confusing than, say, a shebang is for Windows users.

An interpreter directive is far more common than a piece of configuration specific to an editor. It also serves a practical purpose on *nix style systems whereas editor configuration is a matter of preference.

Normal use case, yes, this is only stuff I work on. When collaborating you must assume heterogeneous development environments which make this kind of thing useless.

I use them to set max line length and maybe indentation style (though perhaps I should look more into EditorConfig [0]).

[0] https://editorconfig.org/

They're really useful for specifying indentation settings, or overriding the filetype if the extension is auto-detected as a different filetype than desired.

Reply on news.ycombinator.com