Moin, Stefan Schwarzer schrieb:
Neben dem Editor habe ich immer eine Shell geöffnet, zu der ich mit Alt-Tab wechseln kann und wieder zurück zum Editor. Auf Wunsch kann ich mehr zu meinem "Setup" sagen.
Das interessiert mich durchaus. Als "Python-IDE" nutze ich vim bisher nicht wirklich. Als Editor bewährt er sich immer wieder. Artikel wie diesen hier http://sontek.net/blog/detail/turning-vim-into-a-modern-python-ide habe ich schon mal überflogen, aber mich interessieren weitere Erfahrungswerte im Plugin-Dschungel, da vim als "IDE" neben dem ipython-notebook auf der "Dinge die ich mal intensiv testen möchte" weit oben steht. Für Kleinkrams in Python auf Servern die man "nur" per SSH erreicht, ist vim sowieso häufig im Einsatz. Dafür braucht man aber keine Funktionen einer IDE. Grüße, Bernd
Bernd Waterkamp schrieb:
Stefan Schwarzer schrieb:
Neben dem Editor habe ich immer eine Shell geöffnet, zu der ich mit Alt-Tab wechseln kann und wieder zurück zum Editor. Auf Wunsch kann ich mehr zu meinem "Setup" sagen.
Das interessiert mich durchaus. Mein Setup für Sublime Text 2 und Vim ist auf BitBucket[1] zu finden. Ich benutze für beide Editoren sowie das Terminal die Solarized[2] Farb-Palette.
Viele Grüße Markus [1] https://bitbucket.org/keimlink/dotfiles/src [2] http://ethanschoonover.com/solarized
Hallo Bernd, On 2014-07-05 12:08, Bernd Waterkamp wrote:
Stefan Schwarzer schrieb:
Neben dem Editor habe ich immer eine Shell geöffnet, zu der ich mit Alt-Tab wechseln kann und wieder zurück zum Editor. Auf Wunsch kann ich mehr zu meinem "Setup" sagen.
Das interessiert mich durchaus. Als "Python-IDE" nutze ich vim bisher nicht wirklich. Als Editor bewährt er sich immer wieder. Artikel wie diesen hier http://sontek.net/blog/detail/turning-vim-into-a-modern-python-ide habe ich schon mal überflogen, aber mich interessieren weitere Erfahrungswerte im Plugin-Dschungel, da vim als "IDE" neben dem ipython-notebook auf der "Dinge die ich mal intensiv testen möchte" weit oben steht.
Hier ist ein Beispiel-Screenshot [1]. [1] https://bytebucket.org/sschwarzer/misc/raw/59761ba5c4b2cc1a20fa3ced4f42d7fe7... Im Terminal links läuft screen [2], womit ich, ebenfalls per Tastatur, zwischen mehreren Shells umschalten kann, wenn ich das möchte. [2] https://en.wikipedia.org/wiki/GNU_Screen Ich strebe _nicht_ an, möglichst viele IDE-Funktionen in Vim parat zu haben. Zum Beispiel erledige ich Mercurial- und Subversion-Operationen fast vollständig auf der Befehlszeile. (Gelegentlich nehme ich Experimente mit `:!hg revert %` zurück.) Als Python-Shell verwende ich IPython, bisher normalerweise nicht in der Notebook-Variante. Zum Debuggen verwende ich üblicherweise ipdb. Meine verwendeten Vim-Plugins sind: - Pathogen [3] - Supertab [4] - Bufkill [5] - jpythonfold [6]. An diesem Folding-Plugin finde ich gut, dass es anders als manche anderen die Anzahl der gefalteten Zeilen ans Ende der Faltungszeile stellt. [3] http://www.vim.org/scripts/script.php?script_id=2332 [4] http://www.vim.org/scripts/script.php?script_id=1643 [5] http://www.vim.org/scripts/script.php?script_id=1147 [6] http://www.vim.org/scripts/script.php?script_id=2527 Daneben habe ich einige Mappings: " Use <leader>w instead of ctrl-w for window commands. map <leader>w <c-w> " Comment and uncomment vnoremap <leader>c :s;^;# ;<cr> vnoremap <leader>C :s;^#\(\s*$\\| \);;<cr> " Join following lines with comments characters. nnoremap <leader>J JldW " Useful for debugging in Python. inoremap <leader>d import pdb; pdb.set_trace() inoremap <leader>di import ipdb; ipdb.set_trace() inoremap <leader>p print("=== :", )<ESC><BS><BS><BS><BS>i " Search for classes and functions/methods. nnoremap <leader>sc /^\s*class<space> nnoremap <leader>sf /^\s*def<space> " Adjust lines. Don't include <CR> , so that the command line can " be edited before submitting it. vnoremap <leader>a :!adjust.py -c1 -sb = " Format a selected visual area to 70 characters width. After " formatting, reset text width to 0. vmap <leader>m <esc>:set textwidth=70<cr>gvgq:set textwidth=0<cr> " See http://objectmix.com/editors/149163-how-do-xml-folding.html let g:xml_syntax_folding = 1 autocmd FileType xml setlocal foldmethod=syntax augroup myprogs au! " Prepend all new source files below ~/sd with my default license. au BufNewFile ~/sd/* r ~/sd/MIT_LICENSE | :.-1 d | :$ " In commit messages, move the cursor to the first line. au BufNewFile,BufRead svn-commit.tmp :1 augroup END Das obige Mapping inoremap <leader>p print("=== :", )<ESC><BS><BS><BS><BS>i fügt die Zeile print("=== :", ) in den Quelltext ein und setzt den Cursor im Einfügemodus vor den Doppelpunkt. Wenn ich diese Zeile "ausfülle", sehe ich in der Ausgabe jeweils, _was_ da ausgegeben wird. :-) Bei kleinen Projekten lasse ich Supertab einfach die gerade geladenen Buffer nach Bezeichnern durchsuchen. Bei etwas größeren Projekten verwende ich etwas wie " See http://stackoverflow.com/questions/155449/vim-auto-generate-ctags " Delete the tags file first. If we don't, a second `ctags` invocation " may garble the file if a previous `ctags` process is still running. autocmd BufWritePost ~/r/*/*.py silent! !rm tags && ctags -R & um die Projekt-Dateien so zu indizieren, so dass ich mit ^] oder mit den anderen Tag-Befehlen leicht zur Definition eines Bezeichners springen kann, auch wenn die Datei vorher nicht geladen war. Das klappt recht gut. Apropos Buffer: Ich möchte an der Stelle daran erinnern, dass der Befehl `:b` (`buffer`) nicht nur die Buffer-Nummern als Argument erlaubt, sondern auch Teile von Datei-Pfaden. Wenn ich also `ftputil/host.py` und `test/test_host.py` geladen habe, kann ich beispielsweise mit `:b /host` zur ersten und mit `:b st_host` zur zweiten Datei gehen. Je nachdem, was so alles an Dateien geladen ist, reichen gegebenenfalls auch weniger Zeichen. Bei nicht zu großen Projekten reicht mir `:vimgrep` zusammen mit Quickfix-Befehlen (`:help quickfix`), um die Dateien nach Verwendungen eines Bezeichners zu durchsuchen. Das funktioniert nicht "intelligent", sondern sucht nach Text-Vorkommen. Immerhin kann man Wortgrenzen angeben. Beispielsweise kann ich mit :vimgrep /\<host_/ **/*.py alle Namen finden, die mit "host_" anfangen. Suchen nach anderen regulären Ausdrücken ist auch kein Problem. Ebenfalls nette Befehle sind `z<Enter>` und `zz`, um die Zeile, in der der Cursor steht, an den Anfang oder die Mitte des Fensters zu setzen. Der erste Befehl ist gut, um die ganze Funktion/Methode zu sehen (wenn sie nicht länger als eine Bildschirmseite ist) oder die Umgebung des Cursors. Code-Folding per Tastatur ist ebenfalls nett. ;-) Man kann an dieser Beschreibung vielleicht erkennen, dass ich lieber praktische "nicht-perfekte" Funktionen habe, die ich schnell aufrufen kann als "perfekte" Funktionen, für die ich mich mit einer gegenüber Vim umständlich zu bedienenden IDE kämpfen muss. Mir ist andererseits natürlich klar, dass für jemanden, der mit Vim nicht vertraut ist, _Vim_ umständlich zu bedienen ist. ;-) Viele Grüße Stefan
Hi, noch eine Frage von mir: Normalerweise reicht mir die Kommandozeile für die Versionskontrolle. Was ich mir aber noch wünsche, ist ein Programm, mit dem ich durch die verschiedenen Versionen einer Datei oder eines Verzeichnisses "blättern" kann. Ideal wäre ein "Side-by-Side"-Diff für die jeweilige Änderung. Kennt jemand von euch so ein Tool für Linux, aber möglichst auch für andere Betriebssysteme? Gefragt ist also eine Integration eines möglichst grafischen Diff-Tools (Vimdiff wäre auch ok) mit dem Versionskontrollsystem (idealerweise Mercurial und Subversion). Es wäre schön, wenn ich das etwas schlanker haben könnte als PyDev oder PyCharm anzuwerfen. ;-) Viele Grüße Stefan
Hi, On Sat, 05 Jul 2014 18:51:56 +0200 Stefan Schwarzer <sschwarzer@sschwarzer.net> wrote:
noch eine Frage von mir: Normalerweise reicht mir die Kommandozeile für die Versionskontrolle. Was ich mir aber noch wünsche, ist ein Programm, mit dem ich durch die verschiedenen Versionen einer Datei oder eines Verzeichnisses "blättern" kann. Ideal wäre ein "Side-by-Side"-Diff für die jeweilige Änderung. Kennt jemand von euch so ein Tool für Linux, aber möglichst auch für andere Betriebssysteme?
Gefragt ist also eine Integration eines möglichst grafischen Diff-Tools (Vimdiff wäre auch ok) mit dem Versionskontrollsystem (idealerweise Mercurial und Subversion). Es wäre schön, wenn ich das etwas schlanker haben könnte als PyDev oder PyCharm anzuwerfen. ;-)
Dafür muss ich nicht mal ne Konsole öffnen. Wir haben einfach unser trac, das history und diffs und blame und so kann. Für git, svn, etc... Ansonsten bin ich ein Fan von `gitk`, zugegeben etwas spartanisch. Aber besser als die Verzweigungen per Kommandozeile nachvollziehen zu wollen. Und diffs bzw. Gesamtzustand der jeweiligen Revision sieht man auch. - Arnold
Hi Arnold, On 2014-07-05 19:52, Arnold Krille wrote:
On Sat, 05 Jul 2014 18:51:56 +0200 Stefan Schwarzer <sschwarzer@sschwarzer.net> wrote:
Gefragt ist also eine Integration eines möglichst grafischen Diff-Tools (Vimdiff wäre auch ok) mit dem Versionskontrollsystem (idealerweise Mercurial und Subversion). Es wäre schön, wenn ich das etwas schlanker haben könnte als PyDev oder PyCharm anzuwerfen. ;-)
Dafür muss ich nicht mal ne Konsole öffnen. Wir haben einfach unser trac, das history und diffs und blame und so kann. Für git, svn, etc...
danke für den Tipp! Ein Nachteil ist natürlich, dass man eine Trac-Instanz dafür konfigurieren und laufen lassen muss, aber ich denke, mit einem Tracd ist das halbwegs erträglich. Etwas unpraktisch wird es natürlich, wenn man mehrere Repositories anschauen möchte. Dann müsste man die, wenn ich das richtig verstehe, in der Trac-Konfiguration eintragen. Aber ich denke, ich werde es mal ausprobieren. Viele Grüße Stefan
On Sat, 05 Jul 2014 22:37:29 +0200 Stefan Schwarzer <sschwarzer@sschwarzer.net> wrote:
Hi Arnold,
On 2014-07-05 19:52, Arnold Krille wrote:
On Sat, 05 Jul 2014 18:51:56 +0200 Stefan Schwarzer <sschwarzer@sschwarzer.net> wrote:
Gefragt ist also eine Integration eines möglichst grafischen Diff-Tools (Vimdiff wäre auch ok) mit dem Versionskontrollsystem (idealerweise Mercurial und Subversion). Es wäre schön, wenn ich das etwas schlanker haben könnte als PyDev oder PyCharm anzuwerfen. ;-)
Dafür muss ich nicht mal ne Konsole öffnen. Wir haben einfach unser trac, das history und diffs und blame und so kann. Für git, svn, etc...
danke für den Tipp!
Ein Nachteil ist natürlich, dass man eine Trac-Instanz dafür konfigurieren und laufen lassen muss, aber ich denke, mit einem Tracd ist das halbwegs erträglich. Etwas unpraktisch wird es natürlich, wenn man mehrere Repositories anschauen möchte. Dann müsste man die, wenn ich das richtig verstehe, in der Trac-Konfiguration eintragen. Aber ich denke, ich werde es mal ausprobieren.
seit mindestens trac 0.11 (was wir auf arbeit im einsatz haben) kann man per webui (oder kommandozeile) mehrere repositories hinzufügen. Und sogar auf das main-repo (in der config-datei) verzichten. Damit wurde unser wechsel von svn auf git sehr erträglich, weil sich die webui nicht geändert hat. Und würden wir die tickets von trac noch nutzen, müssten wir da auch nicht wechseln... - Arnold
Moin, Stefan Schwarzer schrieb:
Mercurial- und Subversion
Wir haben noch viel älteres Zeugs in CVS. Die neuen Lösungen verwenden in der Regel git. Apropos git: Der häufigste hook dürfte das Löschen von pyc-Files bei einem Branch-Wechsel sein. pylint oder PEP8 sieht man auch ab und zu. Gibt es noch mehr, das sich bewährt hat?
Im Terminal links läuft screen [2], womit ich, ebenfalls per Tastatur, zwischen mehreren Shells umschalten kann, wenn ich das möchte.
screen oder tmux setze ich inzwischen vor allem dann ein, wenn ich nicht sicher sein kann, ob ich die Aufgabe zeitnah abschließen kann, z.B. debuggen oder testen auf irgendeinem Server. SSH-Verbindung, dort screen öffnen und jederzeit an der gleichen Stelle wieder einsteigen, inklusive Logausgaben. Zum Umschalten nutze ich es zwar auch gelegentlich, aber mit zunehmender LCD-Fläche immer seltener. Terminator[1] erfüllt für mehrere Shells auf einen Blick den gleichen Zweck wie mehrere Fenster in einem vim.
- Pathogen [3] - Supertab [4] - Bufkill [5] - jpythonfold [6]. An diesem Folding-Plugin finde ich gut, dass es anders als manche anderen die Anzahl der gefalteten Zeilen ans Ende der Faltungszeile stellt.
Letzteres kannte ich noch nicht - sieht interessant aus. Ich hatte jetzt vor allem mit jedi[2] gerechnet, weil es in Verbindung mit vim so oft gepriesen wird. Das geht dann aber natürlich schon in Richtung IDE. Dein KISS-Ansatz gefällt mir, vor allem, damit man nicht erst 47 Plugins zum Leben erwecken muss, bevor man produktiv arbeiten kann.
Daneben habe ich einige Mappings:
[..] Da waren ein paar interessante Ideen dabei. Wenn ich wieder im Büro bin, kann ich mal in meiner vimrc stöbern, ob da noch was bei ist was hier bisher nicht auftauchte. Unter anderem toggle ich paste/nopaste mit einem Tastendruck, falls man mal schnell was einfügen muss. Folding/Unfolding von Code und Kommantaren ist ebenfalls äußerst praktisch. BTW: Besonders krass ist der Effekt immer bei Config-Files. Das schrumpft dann manchmal von 300 Zeilen auf vielleicht zwei Dutzend zusammen. [Vorbereitetes Print-Statement]
Wenn ich diese Zeile "ausfülle", sehe ich in der Ausgabe jeweils, _was_ da ausgegeben wird. :-)
Schöne Idee. Dieses "Old school" Debugging nutze ich auch trotz anderer Möglichkeiten immer noch häufig.
Apropos Buffer: Ich möchte an der Stelle daran erinnern, dass der Befehl `:b` (`buffer`) nicht nur die Buffer-Nummern als Argument erlaubt, sondern auch Teile von Datei-Pfaden. Wenn ich also `ftputil/host.py` und `test/test_host.py` geladen habe, kann ich beispielsweise mit `:b /host` zur ersten und mit `:b st_host` zur zweiten Datei gehen. Je nachdem, was so alles an Dateien geladen ist, reichen gegebenenfalls auch weniger Zeichen.
Schon wieder was dazugelernt. Das geht bei vim echt jahrelang. :-)
[vimgrep]
Das mache ich aus Gewohnheit mit [Alt+Tab], grep und ggfs. find in einer Shell, da ich es für andere Zwecke ständig benötige.
Man kann an dieser Beschreibung vielleicht erkennen, dass ich lieber praktische "nicht-perfekte" Funktionen habe, die ich schnell aufrufen kann als "perfekte" Funktionen, für die ich mich mit einer gegenüber Vim umständlich zu bedienenden IDE kämpfen muss.
Ack. Ein Kollege hat mal eclim[3] angetestet, weil er vim schon lange nutzt, hat dann aber schnell aufgegeben.
Mir ist andererseits natürlich klar, dass für jemanden, der mit Vim nicht vertraut ist, _Vim_ umständlich zu bedienen ist. ;-)
Ich kenne vim auch nur ein wenig, finde aber das das Erlernen halb so wild ist, wenn man das Bedienkonzept einmal verstanden hat. Neulich hatte ich bei einem git commit mit vergessenem "-m" in der Shell eines Kollegen auf einmal wieder einen nano als Editor. Die ersten Tastendrücke als Reflex machten natürlich irgendwas, nur nicht das, was ich wollte... Es hat ein paar Sekunden gedauert, bis ich zum Ziel kam - was bei nano ja dank der Anzeige unten nun nicht so schwierig ist. :-) Anstrengend war der erste Kontakt mit dem ISPF-Editor, selbst wenn man kein Problem mit Textkonsolen hat. Da fängt das Lernen von vorne an. :-) Apropos ISPF-Editor: Einige Kollegen aus dem Host-Umfeld vermissen in einem vim die ziemlich flexiblen Exclude-Optionen dieses Editors. "Zeige mir nur die Zeilen für folgendes Suchmuster zum Editieren an", "Blende diesen Absatz aus", "Blende die nächsten X Zeilen aus", usw. Das kann man in vim wohl alles mehr oder weniger nachbauen, aber das funktioniert dort out-of-the-box schon wirklich gut. Danke für die vielen Hinweise an dich und auch an Markus! Grüße, Bernd [1] https://launchpad.net/terminator [2] https://github.com/davidhalter/jedi [3] http://eclim.org/
participants (4)
-
Arnold Krille -
Bernd Waterkamp -
Markus Zapke-Gründemann -
Stefan Schwarzer