tpope / vim-sensible Goto Github PK

https://github.com/tpope/vim-sensible/blob/master/plugin/sensible.vim#L52
let &fillchars = "vert:\u259a,fold:\u00b7"

\u259a appears as a question-mark box on the latest gvim on Windows 7. This causes the vertical window separator to appear as a column of question marks.

In MacVim, the character appears as a checkered box, which I assume is intentional. In both cases, the vertical separator now occupies more visual space, so that the text abuts the split. This screenshot compares the default separator vs sensible.vim:

I suppose I could get used to that, but there is some value in having visual separation between the text and the window separator.

Hi Tim,

I've recently come across your plugins for Vim. Thanks a lot for your great
work. Some thougts to sensible.vim:

1. I'd rather keep "Y" as it was – to yank whole line and not to make it
   compatible with D and C.

Why: From my experience, I often need to quickly copy whole line, but almost
never copy everything from cursor position till the end of line. For copying
it is much more common to copy just a few words where I can use "y2w" or
visual mode. On the other hand deleting or changing till the end of line
happens quite a lot.

Tried to use your version but never got used to it. (Now remapped back.) Any
feedback on this from other users?

1. I'd like to add:
   nnoremap Q gq

Reason: formatting is quite common, Ex mode I almost never use. Again – any
comments on this from other users?

Thanks for considering this, Martin.

If the font being used doesn't support these particular characters an error character is displayed instead. Removing the following code would make :set list more predictable.

if &termencoding ==# 'utf-8' || &encoding ==# 'utf-8'
  let &listchars = "tab:\u21e5 ,trail:\u2423,extends:\u21c9,precedes:\u21c7,nbsp:\u00b7"
endif

I'm not fond of set autoread. I'm sort of torn, since sometimes I would want it turned on.

I had it on in Emacs when I used it as my primary editor, so I'm not sure why I dislike it in vim. Maybe because vim`s prompt is less obnoxious.

I've had work saved by not having it autoread a buffer. Not often, but often enough that dealing with the prompt asking if I should load or not isn't a huge problem. Though I wish it would give me a diff or something.

As I said, I'm sort of torn...but I think for "sensible" defaults, it should be off.

Most of the time I use autocomplete to ensure my vars have the same casing.

I think that more important than be able to write MyPrettyVar in various ways (myprettyvar, MYPRETTYVAR) is to write it the same way every time throughout the code.

I note the slow-down both in and outside of tmux, in iTerm2 and Terminal on OSX. So, is this setting sensible enough?

I set the viminfo filename in my .vimrc like this:

set viminfo=n~/.viminfo

Because the name of the viminfo file has to be the last argument (see http://vimdoc.sourceforge.net/htmldoc/options.html#'viminfo') the settings in vim-sensible rename the file to "~/.viminfo,!"

As far as I can read vim-script, it says that for Linux-like system all the undo-files (.{FILENAME}.un~ etc.) are stored in undodir, that is, ~/.local/share/vim/undo/. I have created the dir and it has correct permissions. Sadly, undo-files are created in working directory. I haven't set anything regarding undo in my .vimrc.

Why aren't undo-files saved in one place?

https://github.com/daGrevis/Dotfiles/blob/master/.vimrc

I'm using Arch Linux and custom-compiled GVim.

Thanks!

I'm just going to throw this out there:

set virtualedit=block "Allow virtual editing in Visual block mode.

I can see why the default is useful, but I wonder if this is a better default.

Navigating in netrw to change the cwd makes so much sense to me that it seems like it should be the default. Although, I'm not sure how much you want to change the behaviour of other plugins.

After reading through the settings, autowrite is the only one I find grossly objectionable. I want to know if I've changed a buffer when I try to leave it.

I manually save constantly. If vim warns me that there are unsaved changes, then I undo or :DiffOrig to see what happened (because it's likely either poorly thought out or a complete mistake).

Related: I don't use hidden (your comment on #12 suggests that's the reason autowrite is useful?)

The 'listchars' is ok, but I'm not sure if whitespaces should be displayed by default.

I'm getting an error with line endings on Mac OS X (Mavericks) in terminal Vim that is preventing sensible.vim from even loading. See below:

Error detected while processing /Users/xxxxx/.vim/bundle/vim-sensible/plugin/sensible.vim:
line    4:
E492: Not an editor command: ^M
line    5:
E15: Invalid expression: exists('g:loaded_sensible') || &compatible^M
line   92:
E171: Missing :endif

My best guess is that this file was committed with non-UNIX style line endings. Is there anything that should/could be done to prevent this from blowing up on different systems?

set matchpairs+=<:>

CTRL-U in insert mode deletes a lot. Use CTRL-G u to first break undo, so that you can undo CTRL-U without undoing what you typed before it.

inoremap <C-U> <C-G>u<C-U>

(This is from vimrc_example.vim, so many people may already have it set.)

There's a call to <c-l> at the end of the <c-l> mapping:

nnoremap <silent> <C-L> :nohlsearch<CR><C-L>

I know the mapping is non-recursive, but this causes a "flicker" (gvim 7.4.26 / Windows 7).

I was just wondering why it has been explictly disabled since I use it all the time. Or have I misunderstood the meaning of this relevant line?

http://stackoverflow.com/questions/307148/vim-scrolling-slowly

set confirm

With the commit of 6c1ed9b and a2cd959 undo files *.un~ are created in the directory relative to the edited file. I expect them to be created in .local/share/vim/undo The directories exist:

$ ls .local/share/vim
backup  swap  undo

directory setting:

echo &directory
~/.local/share/vim/swap//,.,/home/kai/tmp,/var/tmp,/tmp

undodir setting:

echo &undodir
~/.local/share/vim/undo//,.

backupdir setting:

echo &backupdir
~/.local/share/vim/backup//,.,/home/kai/tmp,/home/kai/

First I thought it is the double slash // but removing it did not help.

I installed vim-sensible and was wondering why there appeared .*.un~ files all over my code base. Some inspection of the plugin revealed that the expected base directory ~/.local/share/vim did not exist. Creating it fixed the issue.

I'd suggest that vim-sensible either creates the directory or that you add its creation to the installation instructions.

Not a big deal but I was curious if there is a reason why this script doesn't enable line numbering.

The url for the sensible.vim file is broken. Just to let you know ;)

P.S. I already stoled some of these things from your vimrc, but great stuff as always :)

http://vpaste.net/lBfUc

I'm running OS X 10.8.2, Vim 7.3 installed with brew

:echo &directory | echo &undodir | echo &swap

.,/Users/timosand/tmp,/var/tmp,/tmp
.
.,/Users/timosand/tmp,/Users/timosand/

:echo has('mac') | echo has('macunix')

0
0

Changing has('mac') that parses system('uname') makes more sense.

The readme says "I want this to be a plugin nobody objects to installing. Let me know if you have any objections to anything." And so (after being prompted by a few redditors) I'll just mention that the reason why I've never installed this plugin is Y. And, I suppose, to a much lesser extent, I'm uneasy about & on an intellectual level. And I don't really understand the intent of the insert mode C-U mapping (is it really intended to delete to the beginning of the line, going outside the scope of the inserted text? That seems quite odd, so I'm assuming it's unintentional). But chiefly my concern is with Y.

"Yank whole line" is something which I do quite frequently. On the order of a dozen times per day, I would estimate. I can't remember ever having wanted to "yank to end of line". So removing a convenient, default vim command which I use and replacing it with one I don't need doesn't work for me, personally.

Maybe that's just because I'm mostly using vim to edit C-style code, and so an explicit "yank to end of line" usually winds up placing a terminating semicolon into the " register. If I do a naive "yank to end of line", I then have to clean up those extra semicolons everywhere where I use the yanked code. So when I do want to yank to the end of a line of code, I always end up using yt; instead of y$, to exclude the semicolon. Vim-sensible's remapped Y behaviour just isn't useful for me.

Maybe the remapped Y is more useful for folks who program in languages which don't use statement terminators, or to people who write prose? I don't know. Or maybe most folks don't use Y very frequently at all, and so the whole issue reduces to a question of which behaviour is easier for them to remember, for a rarely used operation.

But in my world of C programming, the standard scope of C and D being different from that of Y makes intuitive sense, because each command is using a scope that I frequently want to use for that type of command. I do often want to delete from the cursor to the end of the line. I don't ever want to yank from the cursor to the end of the line, but I do often want to yank a complete line. So the default scopes of D and Y make sense to me, even though they don't match each other, because they do match things which I commonly want to do when deleting and yanking, respectively; they're like "alt-fire" versions of those operations, each of which does something useful, related to their base operation.

Really, I'm doubtful that a plugin which aspires to be "defaults everyone can agree on" should be making key bindings at all. There will always be people who think that the Vi-basic and/or Vim-default way to do things is the right way to do them. You'd have the same complaints from some folks if vim-sensible incorporated the popular nnoremap j gj and nnoremap k gk remappings (I don't use these). Or nop'd the arrow keys (I don't do this, either). Or vnoremap < <gv and vnoremap > >gv so that it's possible to repeatedly shift indenting while maintaining a visual selection (I do use these). Changing any basic commands to work differently is probably never going to be something that everyone will agree on; everybody's got their own commonly encountered situations informing which functions are useful to them (like my "semicolons on the end of lines" issue which makes "yank to end of line" unhelpful for me), and so you're probably not going to find any single remapping that absolutely everyone will agree is better than the default.

Anyhow, sorry for writing a novel in your issue tracker. :) Hope this is of at least a little help, as an alternative point of view.

The deal with this directory is that it should be considered volatile. Do we really want that for precious backup files? It also means we have to re-create the directories any time the cache is cleared. Also, "cache" to me implies generated data which can easily be re-generated, which is pretty much exactly what backups and swap files are not.

I think the more correct place is ~/.local/share, although, since the rest of Vim isn't using the XDG Base Directory specification anyway, it's probably best to just put this inside ~/.vim somewhere?

After installing according to your instructions, I get this error message:

Fehler beim Ausführen von "/home/s/.vim/bundle/vim-sensible/plugin/sensible.vim":
Zeile 75:
E484: Kann die Datei /tmp/v6DUcSY/0 nicht öffnen

In english, this means it can't open /tmp/v6DUcSY/0

I don't know what's causing this.

Is there any (plugin security?) reason not to use an interactive shell by default for vim :! and :shell commands? :set shellcmdflag=-ic enables bash aliases and "combo" commands like git gui.

When we close a brace, the character first blinks and then it is indented. It leads me to think the brace will not be indented at all.

Can you change the order? Indenting first and then blinking?

Thanks in advance!

Since this is the sensible vimrc everyone should be able to agree on and the files not all that long, would it possible to comment what each thing in it does? As a beginner I think this would help me learn what the common sensible changes to vimrc are and learn what I'm adding to vim before doing so.

I'm not sure why this isn't the default:

set nostartofline

By default, when switching buffers (eg, via ctrl-^), the cursor is moved to the front of the line. This drives me crazy. Instead, the cursor should stay where it was before you viewed a different buffer.

See also: http://stackoverflow.com/a/8292950/152142

Atleast, that's my opinion.

Since you probably don't agree, couldn't that be overridden by the users vimrc? Shouldn't all settings be overrideable?

What about set hidden? I don't know a developer who doesn't have this one.

set fileformats=unix,dos,mac on Windows is creating all my new files with unix-like line endings which is pretty annoying, specially if I have to use other OS specific tools which expect dos-like line endings.

Vim defaults seems Ok, out of curiosity, why did you change it?

Just curious why we want to save and restore capitalised global variables.

Since I've installed sensible, vim adds an extra indentation after every line starting with \item (on .tex files), which is quite inconvenient. Even stranger:

• when I started this issue, every new \item had one indentation more than the previous
• then after switching autoindent, smarttab smartindent off and on I found that smarttab was the guilty option, the extra indent came only to the lines following an \indent but if the line starts with \item the extra indent goes off
• when I'm opening a new .tex file (without any changes in my .vimrc) there is no added indentation but the option remains in the other .tex file even after closing and reopening it.

Well, you did say if anyone objects to anything...

incsearch breaks the "install on remote servers" usecase imo, in the case of a crap connection or a machine swapping violently, vim trying to redraw the screen on each keystroke is a pain. Also, the option has bugged me since day 1, but that's a more scientific objection than simply "it bugs me".

fileformats+=mac I'm assuming this doesn't actually set the line ending to CR like the first docs I found suggest, since even OSX doesn't do this any more. Surely if you're going to pick a horse in this race, unix is the right default?

smartcase I'm still not sure this is necessarily expected behaviour. If I search for a lowercase identifier I expect to only see lowercase matches, that could just be me though. I foresee the usecase for this config being almost exclusively code, and not free text which I generally assumed was the main usecase for smartcase.

Is there any way for for vim-sensible to co-exist with Google style guide settings for C/++ and Python?

Basically I would like Google style guide settings to override vim-sensible when I am editing C/C++/Python source code.

For example of what those settings look like, please see below:
http://google-styleguide.googlecode.com/svn/trunk/google_python_style.vim
http://www.vim.org/scripts/script.php?script_id=2636

nnoremap J mzJ`z

I use set scrolloff=3. I can override the scrolloff setting, but I'd prefer if sensible only overrides scrolloff if it's unset (like history):

if &scrolloff < 1
    set scrolloff=1
endif

Should probably be the same for sidescrolloff too.

Normally it's 20 which seems far to low for me.

Updated 9Aug2013 to clarify issue now that I understand the cause.

Setting certain Unicode characters for the listchars results in slow scrolling performance on OS X. If traditional characters are used (e.g., >) there is no performance hit. The extent of the performance issue depends on the number of lines displaying listchars, the exact characters chosen and the font selected. For example, Courier is very slow, Inconsolata less slow and Menlo seems completely unaffected.

Since this project is about reasonable defaults, perhaps more conservative characters could be selected for listchars & leave the unicode hotness to the individual's vimrc?

See screencast demonstrating the issue: http://screencast.com/t/sVOYambLaQC

To Reproduce:

1. Open a file with many long lines (or shrink window). Ensure wrap is off.
2. Scroll up and down. Feel the pain.
3. Open a file with shorter lines (or expand window).
4. Scroll up and down. Feel refreshed.
5. Switch back to the long line file & change the extends char to something simple like >. Note that the scrolling is just as fast as the short line file.

I have reproduced the issue when running a vanilla config, i.e., gvim -u NONE. This issue happens both in MacVim and terminal Vim (in iTerm2). Also, because CPU time for the fontd process spikes during the slowness I suspect this is OS X related and not specifically a problem with Vim.

For the benefit of future searchers, I noticed this slow scrolling behavior first whenever I would open the Buffergator window. Most of the items listed there do not fit in the visible area so any scrolling causes you to immediately notice the slowdown.

set gdefault

" use /g flag for first match only

Anyone opposed to this? Seems like a universally desirable default.

set linebreak

    If on Vim will wrap long lines at a character in 'breakat' rather
    than at the last character that fits on the screen. 

Note that this doesn't turn hard-wrapping on, it just makes hard-wrapping and gq behave differently.

My vimrc has this:

set viminfo=""                         " do not keep a .viminfo file

So I see this after installing vim-sensible:

Error detected while processing
/Users/schleifer/.dot/vim/bundle/sensible/plugin/sensible.vim:
line   71:
E528: Must specify a ' value: viminfo^=!

According to Practical Vim

The & command is a synonym for :s, which repeats the last substitution. Unfortunately, if any flags were used, the & command disregards them, meaning that the outcome could be quite different from the previous substitution.

Making & trigger the :&& command is more useful. It preserves flags, and therefore produces more consistent results. These mappings fix the & command in Normal mode and create a Visual mode equivalent:

nnoremap & :&&<CR> 
xnoremap & :&&<CR>

I prefer spaces over tabs. I know this is a sensitive issue for some people; is there a way to make vim-sensible check to see if tabs-as-spaces is already being set in the vimrc and to ignore it if so?