rmariano / vim-config Goto Github PK

Add splitright and splitbelow to the configuration
http://stackoverflow.com/questions/7912060/vim-how-can-i-open-a-file-at-right-side-as-vsplit-from-a-left-side-nerdtree-pan

wget -O $SYNTAX_DIR/python.vim $REPO_URL/$BRANCH/syntax/python.vim
wget -O $SYNTAX_DIR/Dockerfile.vim $REPO_URL/$BRANCH/syntax/Dockerfile.vim

This 2 files don't appear to be in the repo

Make sure the custom filetype changes do not affect the rest of the open buffers

For example in a string like the following

variable = """some text with {variable1}, and {marker2}""".format(variable1=1, marker2=2)

Here {variable1} and {marker2}should be highlighted with a different color (for Python files only), so it becomes clear that they are placeholders for text replacements.

The margin that is currently set for the text wrap limit, on .py files, seems to be causing some issues on files of different formats, because a trailing gray shade can be seen on some lines near the end of files.

This long-standing feature (it was since the beginning of time of this project 😭 ), needs revision, and possibly deprecation.

smarttab and expandtab should handle this behaviour correctly, so even when using <tab> there should be no problem. Disabling it also, enables better support for other languages (hello go).

As the project currently has make dev-deploy for linking to the files for development, there should be a new target called make deploy that copies the files instead of creating symlinks (override if they already exists; maybe give a warning).

make install would get the files from the remote repository (wget from Github), so it only requires the Makefile to be downloaded. On the other hand, makek deploy will assume the whole proyect is downloaded, and their required files will be copied to the respective target locations.

Update the documentation with this rationale, and include it in the installation examples 😄

The spell checking is toggle-able with , however it does not show if it is enabled or not.
Show this in the status bar, similar to the one that shows the PASTE mode. It could be used with the green or yellow color.

Move custom configurations (for example Python, markdown, go, etc.) to ~/.vim/ftplugin/<lang>.vim or even ~/.vim/after/ftplugin/<lang>.vim, taking advantage of ftplugin setting.

Update installation target in Makefile.

I had to do bash deploy.sh so the instant one-liner didn't work

Installing develop . Getting the latest version from https://raw.github.com/rmariano/vim-config
/tmp/deploy.sh: 11: /tmp/deploy.sh: [[: not found
/tmp/deploy.sh: 11: /tmp/deploy.sh: [[: not found

The autofix functionality (<F3>) at

It's possible then that isort changes the import order without respecting the limit of the columns, after the pep8 was changing, leaving it in an incorrect state.

Swap the order of the operations.

The page for the project at https://rmariano.github.io/vim-config should render the README as latest documentation.

<leader>+c comments the current line out, with a #, as Python comments. This does not include an space after it, according to PEP8. Instead, it should prepend #<space>

Have a mapping (could be <F5> for example) that automatically fix the Python file in the current buffer by:

• Formatting with PEP8 automatically
• Running isort for correcting the imports
• Run flake8 checks at the end to make sure everything is OK

⚠️ ANALYSIS to see if it's going to be implemented or not.

Use set makeprg for running linting checks on Python files.

Like

set makeprg=pylint\ --reports=n\ --output-format=parseable\ %:p
set errorformat=%f:%l:\ %m

from https://stackoverflow.com/questions/3839454/how-to-use-pylint-in-vim
and https://jbernard.io/2011/09/30/vim-makeprg.html

Pros:

• Get rid of vim-flake8 (one dependency less)
• pylint is better linting tool than flake8
• Uses vim as default

Cons

• Projects rely on their own Makefile, and changing the default makeprg=make might overshadow it, when in fact it is desired to use the Makefile. Maybe another mapping instead of makeprg ?

Check

• :help makeprg
• :help errorformat

• Change the shortcut for commenting lines out: instead of <leader> + c, ctrl + / or <leader> + /
• Support commenting and un-commenting out multiple lines highlighted (single-line comment).
• Update the documentation.

Search for the following development tags in the code:

• TODO
• FIXME

The search must be recursive based on the current directory, and the results should be rendered in the quickfix window, without jumping to the first result (/j flag included).

It's only set for Python files

It should be for all sorts of files, with the consideration that there must be a way of overriding it with a command (for a very unlikely scenario, but still)

Support the new syntax changes of Python 3.6: https://docs.python.org/3/whatsnew/3.6.html

• syntax highlighting for: f-strings, underscore in numerals, etc.

🐍

Support *.pyx files.

• Syntax highlighting
• Syntax check & corrections (<F3>, <F7>) should work

set autowrite or set autowriteall

http://vimdoc.sourceforge.net/htmldoc/options.html#'autowrite'

make extras should automatically install all external plug-ins on the project.
Update documentation accordingly.

https://raw.githubusercontent.com/rmariano/vim-config/develop/.vimrc returns 404

Add set nomodeline to the config.
Security implications.
see https://github.com/numirias/security/blob/master/doc/2019-06-04_ace-vim-neovim.md

Set an indicator in the status line, that displays "[PASTE]" in white letters over dark red background for when the paste mode is on. If paste is not set, the status line should remain as always.

• run go fmt on saving or via a mapping (<F5> for instance).
• Configure according to standards (tabs, etc.)

Move the list of features to an upper section, for easier access and better visibility.

The mapping <leader>tw is missing. Add it and correct all other features that might be missing.

When a python file is open the margin is properly set to 80 cols. However, when opening a new file (by tabnew for example), this margin is toggled, and hence it disappears. It should be maitained along python files.

Changes for the next version: 0.10

• [Python files] Don't auto-wrap text at max length
• Support for Rust (*.rs) files