5 ms·

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

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.

eikenberry 7y ago
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.
- gbrown_ 7y ago
  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?
  - anowlcalledjosh 7y ago
    Presumably it's no more confusing than, say, a shebang is for Windows users.
    - gbrown_ 7y ago
      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.
  - eikenberry 7y ago
    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.
tom_ 7y ago
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.)
- gbrown_ 7y ago
  How do others feel about this when they open the files? Or are they not part of a shared project?
  - tom_ 7y ago
    Nobody seems to care, and I can easily put them back in if somebody deletes them.
dmix 7y ago
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 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).
- ebeip90 7y ago
  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
  - k_sze 7y ago
    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.
    - JetSpiegel 7y ago
      chmod -x
  - dmix 7y ago
    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`.
m000 7y ago
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.
- gbrown_ 7y ago
  > 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.
rbonvall 7y ago
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-encoding 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.
mintplant 7y ago
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/ https://editorconfig.org/
eridius 7y ago
They're really useful for specifying indentation settings, or overriding the filetype if the extension is auto-detected as a different filetype than desired.

eikenberry 7y ago

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.

gbrown_ 7y ago
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?
- anowlcalledjosh 7y ago
  Presumably it's no more confusing than, say, a shebang is for Windows users.
  - gbrown_ 7y ago
    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.
- eikenberry 7y ago
  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.

tom_ 7y ago

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.)

gbrown_ 7y ago
How do others feel about this when they open the files? Or are they not part of a shared project?
- tom_ 7y ago
  Nobody seems to care, and I can easily put them back in if somebody deletes them.

dmix 7y ago

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 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).

ebeip90 7y ago
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
- k_sze 7y ago
  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.
  - JetSpiegel 7y ago
    chmod -x
- dmix 7y ago
  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`.

m000 7y ago

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.

gbrown_ 7y ago
> 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.

rbonvall 7y ago

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-encoding 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.

mintplant 7y ago

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/ https://editorconfig.org/

eridius 7y ago

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