2008-12-09 9 views
46

Kiedy dodaję tryb wstawiania # w pustym wierszu w Vimie podczas edycji plików Pythona, vim przesuwa # na początek linii, ale chciałbym, aby # został wstawiony na poziomie karty, w której go wprowadziłem.Jak skonfigurować vim tak, aby nie wstawiał komentarzy na początku linii podczas edycji plików Pythona

Na przykład, pisząc to w vim

for i in range(10): 
    # 

the # nie zatrzymać się tam, gdzie wszedłem go.

Porusza się tak, jak w przypadku vima.

for i in range(10): 
# 

Czy ktoś wie o elemencie konfiguracyjnym w vim, który by to zmienił?

Jeśli to pomaga, używam Ubuntu 8.10.

+0

Zobacz także: http://stackoverflow.com/questions/191201/indenting-comments-to-match-code-in-vim – Dan

Odpowiedz

31

znalazłem tutaj odpowiedzi http://vim.wikia.com/wiki/Restoring_indent_after_typing_hash

Wydaje się, że vim opcja smartindent jest przyczyną problemu. Opisana powyżej strona opisuje pracę-rund, ale po przeczytaniu pomocy w smartindencie w samym vimie (: help smartindent), zdecydowałem się spróbować cindent zamiast smartindent.

Wymieniłem

set smartindent 

z

set cindent 

w moim pliku .vimrc

i tak daleko, że działa doskonale.

Zmieniono również zachowanie "< <" i ">>" dla wcięcia bloków wizualnych, które zawierają komentarze Pythona.

Istnieje więcej opcji konfiguracji i informacji na temat wcięć w vim help for smartindent i cindent (: help smartindent i: help cindent).

+2

Ah, mam "wtyczkę wtyczki typu pliku" w moim .vimrc, być może to jest odpowiedzialny za to, że działa poprawnie dla mnie. http://vimdoc.sourceforge.net/htmldoc/filetype.html – m0j0

+0

Uratowałem mój dzień. +1! :) –

+0

czy są jakieś zalecane/wspólne ustawienia konfiguracyjne dla 'cindent'? –

1

Moja konfiguracja Vima tego nie robi. Można spróbować skrypt python.vim dostępne z tego linku: http://www.vim.org/scripts/script.php?script_id=790

+0

Niestety, to nie zadziałało w moim przypadku, problem nadal występuje podczas korzystania z niego. Użyłem wersji 2.6.3, ponieważ jeszcze nie zaktualizowałem do Pythona 3.0. Być może problem jest w pliku /usr/share/vim/vim71/indent/python.vim zainstalowanym z pakietu vim-runtime Ubuntu? –

2

Jest to spowodowane funkcją "smartindent". Jeśli posiadasz :set smartindent w swoim .vimrc, musisz go usunąć.

9

Mam następujące linie w moim .vimrc, wydaje się być instalowany domyślnie z moim Ubuntu 8.10

set smartindent 
inoremap # X^H# 
set autoindent 

I nie zauważyć problemu. Może możesz spróbować tego. (Zauważ, że^H powinno być wprowadzone przez Ctrl-V Ctrl-H)

19

@PolyThinker Chociaż widzę, że odpowiedź na to pytanie jest bardzo ważna, moim zdaniem nie jest to dobre rozwiązanie. Edytor nadal uważa, że ​​powinno być wcięte do końca w lewo - sprawdź to, naciskając == na linię zaczynającą się od skrótu, lub pchając = podczas gdy blok kodu z komentarzami w nim jest podświetlony, aby powtórzyć.

gorąco polecam filetype indent on i usuń set smartindent i set autoindent (lub set cindent) linie z vimrc. Ktoś inny (podobno David Bustos) był na tyle uprzejmy, aby napisać dla nas pełny parser wcięć; znajduje się na $ VIMDIRECTORY/indent/python.vim.

(cindent rozwiązanie Pawła prawdopodobnie pracuje dla pytona, ale filetype indent on jest znacznie bardziej ogólnie użyteczne.)

+0

Dzięki - pomogło mi to. Miałem jeden problem i to właśnie próbowałem "wcięcia w filetype" w gvim (MacVim) i nie zauważyłem zmiany zachowania. Kiedy zacząłem testować go, dodając go do .vimrc, a następnie restartując, widziałem zmianę zachowania. – finity

+0

Ten sam problem, wypróbowane akceptowane rozwiązania (i permutacje), umieścił "wcięcie pliku" na końcu .vimrc, a teraz pytajnik # comment'ing nie de/outdent. Ale teraz coś dla mnie jest automatyczne. Westchnienie. – ChuckCottrill

+0

Wyłącz smartindent nie działa dla mnie (zarówno w systemie Ubuntu vim, jak i osx mac-vim). Dodanie "wcięcia typu fileta" do moich $ HOME/.vimrc i restartowanie [g] vim rozwiązuje mój problem (zarówno przy edycji skryptów Pythona, jak i basha). –

4

Moje rozwiązanie unindenting z #:

Jeśli używasz cindent, uznać, że jest ona przeznaczona dla C i kodowanie C++. Tutaj # oznacza, że ​​tworzysz #DEFINE lub #MACRO(), więc zachowanie jest poprawne. Ale dla innych języków, gdzie # jest komentarzem, jest irytujące.

Następujące pracował dla mnie:

" cindent  enable specific indenting for C code 
" set cin  nocin 
set cin 

" cinkeys  The default cinkeys causes leading # to unindent to column 0. 
"    To prevent this, remove the 0# from the definition. 
" set cinkeys=0{,0},0),:,0#,!^F,o,O,e - default 
set cinkeys=0{,0},0),:,!^F,o,O,e 
0

usunąłem set smartindent z ~/.vimrc ale jeszcze nie wyłączyć smartindent. Po otwarciu pliku .py i uruchomieniu :set smartindent? wyświetliło się smartindent.

Okazuje się, że w dalszej części ~/.vimrc była ta linia:

autocmd BufRead *.py set smartindent cinwords=if,elif,else,for,while,try,except,finally,def,class 
         ^^^^^^^^^^^ 

Raz usunięte „smartindent” z tej linii, a następnie smartindent był ostatecznie wyłączona i moje komentarze były wcięte prawidłowo ponownie.

2

Niektóre z pozostałych odpowiedzi były użyteczne, ale żadna z nich nie wystarczała, aby zapobiec przywróceniu linii przez Vima, gdy "#" jest pierwszą postacią. Odpowiedź PolyThinker nie działała dla mnie, ale dała wskazówkę, że "#" może zostać zmienione na "wstawić znak, następnie #, a następnie usunąć dodatkowy znak i umieścić kursor tam, gdzie powinien". Jest to odwzorowanie że robi:

inoremap # X#<left><backspace><right> 

Jest to konieczne, ponieważ pakiety składni VIM zdają się traktować „#” jako znak specjalny, bez względu na to, w jaki sposób opcje są ustawione. Chcę, aby linia zaczynająca się od "#" była taka sama, jak linia zaczynająca się od jakiejkolwiek innej postaci. Najbardziej niezawodnym rozwiązaniem, jakie znalazłem, jest powyższe mapowanie, które faktycznie zmienia pierwszą postać linii.

Uwaga: Zauważyłem, że mapowanie powoduje problemy po uruchomieniu I#<esc>, a następnie naciśnięcie "." aby powtórzyć poprzednie wstawienie. Nie znalazłem jeszcze rozwiązania.

Powiązane problemy