ACHTUNG! Dieses Forum ist nicht mehr aktuell.
Zum neuen Forum hier klicken... Zum Gästebuch...
Die Teilnahme ist dort auch ohne Registrierung möglich.
Allgemeines Forum... mit den Kategorien Webvideos... Webverzeichnis...
Call In - Gewinnspiele... Alle Call-In-Themen auflisten... Call In - Central...
Um alle Diskussionsthemen aufzulisten, hier klicken!... Focus-Themen auflisten...
 Suchen  Kalender  Galerie |  Auktionen  Global  Top |  Mitglieder  Stats |
 | Admin |
 Chat (0) new User-Map |  Passwort zusenden  Registrieren |
|---|
| Forum Übersicht |
Seiten: (1) [1] » |
  |
| Der Editor gVim 7.1 - Schwer erlern- und bedienbar, fehlerhaft und tückisch; aber viele Funktionen· |
| ForumLeaks |   
| |
|---|---|---|
| Gruppe: Administrator Rang: Mehr als 1000 Beiträge .gif) Beiträge: 1596 Mitglied seit: 29.06.2005 IP-Adresse: gespeichert  | ACHTUNG! Der aktuelle Thread ist in meinem neuen Forum: http://forumtreff.pytalhost.de/660 Für Windows Datei gvim72.exe mit 8,53 MB (klick). Eine gute Einführung siehe hier: Klick! Zeilen mit bestimmten Inhalten bearbeiten [g=global, v=vice versa, s=substitute] :2,s/def/xyz def durch xyz ersetzen von der 2. Zeile an; nur jeweils erstes Vorkommen je Zeile. :'a,'bs/def/xyz/g Von Marke a bis Marke b alle Vorkommen von def durch xyz ersetzen; alle Vorkommen in den Zeilen (g). Zuvor musste man aber die Marken a und b setzen mit ma und mb an den jeweiligen Positionen des Kursors. Mit `a springt man zur Marke a. Hierzu die Umschalttaste gedrückt halten und Taste ` drücken, dann Leertaste drücken und Taste a drücken! Mit :delmarks! löscht man alle Markierungen. :g/abc/cmd cmd für alle Zeilen ausführen, die abc enthalten :v/abc/cmd cmd für alle Zeilen ausführen, die abc nicht enthalten :g/abc/d Alle Zeilen löschen, die abc enthalten :v/abc/d Alle Zeilen löschen, die abc nicht enthalten :g/abc/s/def/xyz In den Zeilen, die abc enthalten, def durch xyz ersetzen :v/abc/s/def/xyz In den Zeilen, die abc nicht enthalten, . . . Beachte aber bei allen zuvor genannten Beispielen: :g/abc/s/def/xyz/g Diesen Befehl jeweils für alle Vorkommen in der Zeile ausführen, andernfalls wird ohne die Option /g mur jeweils das erste Vorkommen in der Zeile nicht ignoriert. Anstatt dem Slash / können alle Zeichen, außer - alphanumerische Zeichen - dem Backslash (\) - dem Doppelapostroph (") und - dem Pipe-Strich (|) verwendet werden. Ich empfehle das Rautezeichen #. Eine öffnende rechteckige Klammer vor diesem Zeichen muss mit dem Backslash \ gekanzelt werden. qa - Makro a aufzeichen q - Aufzeichnung beenden @a - Makro a ausführen 77@a - 77 mal Makro a ausführen (gg - zum Anfang eines Dokumentes) G - zum Ende des Dokumentes gehen o - unterhalb eine neue leere Zeile öffnen O - oberhalb eine neue Zeile öffnen "ap - Inhalt des Makros a ausgeben "ay$ - Zeile auf Makro a überschreiben 0 - zum Anfang einer Zeile gehen ^ - zum ersten Zeichen einer Zeile gehen $ - zum Ende einer Zeile gehen // - Letzte Suche wiederholen Bei der Rückwärtssuche mit ? beachte man, dass man Fragezeichen innerhalb eines Suchausdrucks mit einem vorangestellten Backslash \ kanzeln muss. Übrigens muss man in Suchausdrücken (auch bei Ersetzungsbefehlen) normale Slashes / auch kanzeln, falls diese als Zeichen gesucht werden sollen, um deren Systemfunktion abzuschalten. Die Schatenseite Weblog » Fehler in Vim und Mutt Berichtigung: Der in meinem Beitrag erwähnte Ausdruck auto.\{-}\(bahn\).\{-}fahrer muss richtig heißen: auto.\{-}\(bahn\)\{0}.\{-}fahrer Die Schatenseite Weblog » Antwort an den gVim-Spezialisten Siehe dazu auch hier: Html und PHP erlernen - Eine Entscheidungshilfe für Unentschlossene - Unclassified NewsBoard Leider konnte ich im oben genannten Blog keine Antwort schreiben, weil ich diese Meldung erhielt: Deswegen poste ich die Antwort einfach hier: Mir syntaktischen Humbug vorzuwerfen ist einfach. Aber zu sagen, wie das Suchmuster aussehen müsste, damit Wörter wie Autofahrer, Autobusfahrer und Autoreisefahrer gefunden werden; nicht aber Autobahnfahrer; das ist schon schwerer. Beim allseits ach so hochgelobten gVim ist das aber schier unmöglich. Aber fangen wir mal mit was ganz einfachem an: Angenommen Du schickst Deine Frau zum Einkauf und schreibst ihr eine Einkaufsliste: 1 Brot, 2 Brötchen und Null Päckchen Zigaretten, damit sie weiß, was sie für Dich mitbringen soll, und was sie nicht für Dich mitbringen soll. Deine Frau käme zurück mit der Bemerkung, dass diese Einkaufsliste syntaktischer Blödsinn sei, weil Du mit dieser (angeblich) nicht die Zigaretten ausgeschlossen hattest. Dann würdest Du vielleicht ein wenig an ihrem Intellekt zweifeln und argumentieren, dass 0 Päckchen Zigaretten eben nun mal zweifelsfrei und eindeutig bedeuten, dass sie eben nun mal keine Zigaretten für Dich mitbringen soll. Zurück zu Vim: Wenn Du bspw. angibst, dass Auto, gefolgt von einem Zeichen, das nicht das Zeichen x sein soll und dann bahn folgen soll, so wird gVim brav bspw. Auto-fahrer, Autofahrer und Auto Fahrer als Treffer ausgeben; nicht aber Autoxfahrer. Der Befehl sieht so aus: /Auto[^x]fahrer Man kann auch ganze Wörter angeben, die zwischen Auto und bahn sein sollen oder nicht sein sollen. Bspw. /Auto\(bahn\)\{2,4}fahrer findet Wörter, die zwischen Auto und Fahrer zwei bis 4 mal das Wort bahn haben dürfen. Gibt man aber als Menge für das Wort bahn 0 an, so hat das System das syntaktisch entsprechend umzusetzen und das Wort Autobahnfahrer als Treffer nicht zuzulassen. Ein Suchmuster ist dazu da, dass das System das entsprechend umsetzt; und nicht, dass einfach was ignoriert wird. Hey, wenn Du es genau wissen willst: Die Mengenabgabe 0 für bahn schließt sehr wohl das Wort bahn aus, auch wenn Du Dir das anscheinend logisch nicht vorstellen kannst. Überlege doch mal! Wenn ich für bahn 0 angebe, wieso sollte ich dann das Wort bahn nicht damit ausgeschlossen haben? Tut mir leid, aber mit Deiner "Logik" komme ich nicht zurecht. Im Prinzip ist das auch so, wenn ich jeweils vor und nach bahn beliebige Zeichen erlaube. Bspw. Autorennbilligfahrer wäre dann möglich als Treffer. Aber bspw. Autorennbahnbilligfahrer natürlich nicht. Die Entwickler von Vim scheinen das anscheinend auch noch nicht verstanden zu haben. Übrigens ist der Vim gar nicht so schlecht. Es ist schon erstaunlich, was man mit diesem Programm alles machen kann. Inzwischen habe ich mich an dieses Programm gewöhnt und nutze die vielseitigen Möglichkeiten aus. Und die Angaben >so viel oder so wenig wie möglich< funktionieren jeweils nur innerhalb einer Zeile. Wenn man bspw. in Quelltexten nur innerhalb von auskommentierten Texten was editieren will, ist es einfach, wenn diese Auskommentierung nur jeweils mit einem Zeichen geschieht. Befehlsmäßig gibt man als erstes das anfängliche Auskommentierungszeichen an, gefolgt von beliebig vielen Zeichen, die nicht das Zeichen sein dürfen, das das Ende der Auskommentierung markiert, und dann das gewünschte Wort oder Suchmuster. Auf diese Weise wird nur in auskommentierten Zeichenfolgen gesucht. [^ ] Aber bspw. in CSS-Dateien werden Auskommentierungen mit jeweils zwei Zeichen am Anfang und Ende markiert. Wenn ich das aber entsprechend angebe mit einer Klammer gefolgt mit der Mengenangabe Null, dass nach dem anfänglichen /* nur noch Zeichen kommen dürfen, die nicht die Zeichenfolge */ enthalten dürfen, so ist das kein syntaktischer Unsinn, sondern nötig, um die gewünschten Suchergebnisse ausschließlich innerhalb von kommentierungen zu erzielen. Aber leider ignoriert gVim 7.1 diese Angabe (noch). Nachtrag: Manche Foren- oder Blogadmins wollen sich mit ihrem Webauftritt nur irgendwie profilieren. Wenn dann irgendwann mal jemand was mehr oder weniger Herausragendes schreibt, befürchtet diese Person dann, dass diese selbst dadurch irgendwie dadurch in den Schatten gestellt werden könnte. Es wird dann krampfhaft versucht, dem zumindest scheinbar irgendwie was entgegenzusetzen, auch wenn es oftmals nur der aller größte mit entsprechender überheblicher Polemik versehene Schwachsinn ist, der oftmals im ersten Moment tatsächlich irgendwie sogar logisch klingt. Der unliebsame Schreiber wird dann sofort gesperrt, damit er diesen absoluten Unsinn nichts entgegen setzen kann, und nicht noch mehr "Schaden" anrichten kann. Um es kurz zu machen: Am besten die Finger weg von Blog.schatenseite.de! Inzwischen habe ich einen zweiten Fehler beim Ersetzen mit :g entdeckt. Wenn ich das Suchmuster >Zeilenumbruch - irgendein Zeichen - Zeilenumbruch ersetzen will, wird das zweite Suchmuster nicht ersetzt, wenn es an das erste angrenzt. Bspw. in diesem Text wird ist ein Zeilenumbruch, ein Buchsatbe a, wieder ein zeilenumbruch, der Buchstabe B, zwei Zeilenumbrüche, noch ein Buchstabe A und noch ein Zeilenumbruch. Zwei mal kommt also das Muster >Zeilenumbruch - A Zeilenumbruch< vor. Mit :g#\nA\n#s#\nA\n#xyz wird nur das erste Auftreten dieses Suchmusters durch xyz ersetzt. Auch das Anfägen von #g ändert daran nichts, wodurch nicht nur das jeweils erste Auftreten eines Suchmusters innerhalb einer Zeile ersetzt werden soll. Mehrere Zeilen enden alle jeweils mit abc. Wenn man mit :g#abc\n#s#abc\n#def\r#g alle abc durch def ersetzen möchte, so geschieht das nur in der ersten, dritten, fünften u.s.w. Zeile. Dies ist deswegen so, weil das Suchmuster jeweils zwei Zeilen umfasst. Richtig funktionieren würde es mit :g#abc$#s#abc$#def#g oder mit :%s#abc\n#def\r#g. Wenn ich jemanden bitte würde, mir einen bestimmten Gegenstand zu bringen, falls dieser vorhanden ist; und diese Porson würde mir nacheinander alle möglichen Gegenstände bringen, die sie finden kann, so wäre das doch irgendwie völlig unlogisch. Im Prinzip genauso unsinnig verhält sich aber der Editor Vim bzw. gVim.
| |
| 09.04.2008 22:36:23 |    | |
| ForumLeaks |
| |
| Gruppe: Administrator Rang: Mehr als 1000 Beiträge Beiträge: 1596 Mitglied seit: 29.06.2005 IP-Adresse: gespeichert | Wenn in einer Zeile Zeichen sind, ein Zeilenumbruch folgt und in der nächsten zeile wieder eine Zeichenfolge ist; und man würde das Suchmuster so schreiben, dass man die erste Zeichenfolge gefolgt vom Zeichenendzeichen $, gefolgt vom Zeilenumbruch \n und gefolgt von der Zeichenfolge in der zweiten Zeile, so hat man keinen Treffer, obwohl das Suchmuster syntaktisch (eigentlich) richtig ist. Damit dieses Suchmuster funktioniert, muss man das Zeilenendzeichen aus dem Suchmuster entfernen. Ein Ersetzungsbefehl mit bspw. :g#abc#s#abc#def#g löst zwar ggf. die Meldung aus, dass der Suchbegriff nicht gefunden wurde und man die Eingabetaste drücken solle; innerhalb eines Makros wird aber dieses dadurch nicht abgebrochen. Es kann aber passieren, dass inmitten der Makroausführung diese Meldung kommt. Nach Drücken der Eingabetaste wird das Makro aber weiter ausgeführt. Um aber diesen störenden Effekt zu vermeiden, füge man nach dem Return, der diesem Ersetzungsbefehl folgt, ein Escapezeichen ein, das während der Ausführung des Makros diese Meldung automatisch bestätigt, und auf diese Weise der User das dann nicht tun muss. Um diesen störenden Effekt zu vermeiden, hatte ich in einem Fall herausgefunden, dass einige Schritte weiter das gg, das zum Dokumentenanfang führt, das auslöste. Indem ich alles so umschrieb, um dieses gg an dieser Stelle zu vermeiden, erschien dann diese Meldung nicht. Ist schon manchmal ein bisschen seltsam der Vim. Zum ersten Zeichen der Zeile gehen, das keine Leerstelle oder eine Tabulatoreinrückung sein soll ist ^. Zur ersten Position der Zeile gehen ist eigentlich die Null 0 laut diesem ziemlich ausführlichen Handbuch in deutsch: Klick! Wenn aber das die ersten Stellen Tabs sind, so geht der Kursor leider unmittelbar hinter diese, was für die Erstellung eines Makros problematisch sein kann. In so einem Fall aber mit den Bewegungstasten an den Anfang gehen zu wollen, hat aber grundsätzlich dieses Problem: Wenn innerhalb eines Makros die Bewegung des Kursors mit h, j, k oder l nicht ausführbar ist, weil er schon bspw. am Zeilenende oder -anfang angelangt ist, wird leider auch das Makro abgebrochen. Wenn aber die Anzahl vorangestellt ist, wird das Makro nicht abgebrochen. Aber der erste Schritt muss ausgeführt werden können, weswegen eine vorangestellte 1 nicht das Abbrechen des Makros verhindert. Wenn man eine Zeichenfolge einschließlich des Zeilenumbruchs im Visualmodus markieren will, die mit diesem Zeilenumbruch beginnt, vor dem aber mindestens ein Zeichen ist, und deren letztes Zeichen an einem Zeilenende ist, so ist das Markieren leider nicht möglich, weil man den Kursor gar nicht nach rechts bewegen kann. Wenn ich nämlich diese Zeichenfolge von links nach rechts bzw. von oben nach unten markiren will, so befindet sich der Kursor auf dem Zeichen vor dem Zeilenumbruch, sodass dieses unweigerlich mitmarkiert werden würde. Wenn man aber diese Zeichenfolge von rechts nach links bzw. von unten nach oben markieren will, so hat man am anderen ende dieser Folge ein Problem. Das letzte Zeichen unmittelbar vor dem Zeilende kann leider nicht mitmarkiert werden, weil die Markierung unweigerlich links neben der Kursorposition beginnt bzw. endet. Wenn man nach einem Zeilenumbruch mit nachfolgender Zeichenfolge sucht, und dabei angibt, dass der Zeilenumbruch Null oder einmal (oder unendlich mal) vorhanden sein kann, so wird das gefundene Muster einwandfrei gefunden und markiert. /\n\=abc Benutzt man dazu aber die Rückwärtssuche, ist nur die Zeichenfolge ohne den Zeilenumbruch markiert. Der Kursor befindet sich auf dem ersten Zeichen, anstatt auf dem Zeilenumbruch. Das kann bei der Erstellung von Makros ein großes Problem sein. ?\n\=abc wenn man eine besonders große Datei schließt, nachdem der Kursor am Ende der Datei war, ist dann das irgendwann nachfolgende Öffnen dieser Datei fehlerhaft. Oben fehlt dann Text bzw. es wird nicht der ganze angezeigt, und ganz unten befindet sich der Kursor im Leeren. Diese Datei ist aber in Wirklichkeit nicht defekt; auch dann nicht, wenn man sie abspeicherte, nachdem sie fehlerhaft geöffnet wurde. Dieses fehlerhafte Öffnen kann man aber vermeiden, indem man den Kursor mit gg an den Anfang der Datei bewegt, bevor man die Datei schließt. Wenn man mit dem :g-Befehl alle Zeilenumbrüche bspw. durch das Symbol ersetzen will, so wird bei jeweils unmittelbar aufeinanderfolgenden Zeilenumbrüchen (Leerzeilen) jeweils der darauffolgende nicht umgewandelt. :g#\n#s#\n# oder :g#\n#s#\n##g Die Angabe g am Ende des Befehls ist dabei ggf. wirkungslos. Abhilfe schafft hier das mehrmalige (ausreichend oft) Ausführen dieses Befehls; oder indem man den Ersetzungsbefehl :%s verwendet. Eine Zeichenfolge, die ich auf das Tausendfache ergänzte, wollte ich mit einem Makro bearbeiten. Der erste Teil war ein Makrobefehl, der nach einer öffnenden Klammer ( sucht. Als dann bei einem weiteren Befehl nach der nächsten öffnenden Klammer suchen sollte, erstarrte das System. Es zeigte sich, dass dieser Fehler nicht auftrat, wenn die zu bearbeitende Zeichenfolge nur kurz war, also vor der Vertausendfachung der erst genannten Zeichenfolge. Wenn ich diese Zeichenfolge um des 300-fache vergrößerte, war der Suchprozess nur jeweils für etwa einer Minute unterbrochen. Und je größer die zu bearbeitende Zeichenfolge war, um so länger dauerte dieser vorübergehende Stillstand. Ich vermute mal, dass bei einer Vertausendfachung dieser Zeichenfolge die Erstarrung vielleicht ca. 10 Minuten dauerte. Es handelte sich übrigens stets um eine einzige (Riesen-) Zeile. Ich löste dieses Problem, indem ich die öffnende Klammer durch ein anderes Zeichen ersetzte und dann diese Zeichenfolge vertausendfachte, die ich dann mit dem Makro bearbeitete. Seltsam und störend war dann aber immer noch, dass die Abarbeitung dann trotzdem immer noch ungefähr 24 Stunden dauerte bei einem PC mit 666 MHz Taktfrequenz (Pentium III). Sonst dauerte die Abarbeitung bei ähnlichen Makroausführungen aber nur etwa zwischen ein oder zwei Stunden. Die zu bearbeitende Zeichenfolge, die ich anschließend vertausendfachte, war übrigens diese: /(¥)v?\Slxv/)/\Sxv/$x/(¥(v/(/)lp Unter dieser Zeile war dann eine Leerzeile und darunter eine Zeile, die die Zahlen von 1 bis 1000 enthielt, die jeweils mit einer Leerstelle voneinander getrennt waren und die mit einer Leerstelle begann. Diese Datei wollte ich mit dem 999-fachen Ausführung dieses Makros bearbeiten: /\n\n\( \)*\djj0v/\dxv/ x/§¥lvlplv?§ly/§¥lvlp Seltsam ist das Verhalten des Editors, wenn die Anwendung abstürzt. Wenn man dann glaubt, dass man einfach nur die Datei erneut öffnen kann, weil man die abgestürzte Datei schließlich nicht nach dem Absturz abspeicherte, so wird man leider oftmals feststellen müssen, dass sich die Datei gar nicht mehr öffnen lässt. Wenn man Glück hat, kann man, falls vorhanden, die dazugehörige Swap-Datei öffnen, die mit ~ endet. Wenn Vim erstarrt, muss es nicht unbedingt ein Absturz sein. Möglicherweise kann der Prozess nach ggf. vielen Minuten weitergehen. Falls man doch von einem Absturz ausgeht, ist es eine Tücke dieser Software, dass nach dem beenden, auch wenn man dabei nicht abspeichert, die Datei nicht mehr aufrufbar ist. Im besten Fall kann man dann wenigstens noch die dazugehörige Sicherungsdatei mit ~ am Dateiende öffnen, falls vorhanden. Ich empfehle bei einem Absturz diese Anwendung erst mal nicht zu schließen, sondern diese Datei erneut zu öffnen (das geht nämlich jetzt noch), die abgestürzte Anwendung zu schließen und dann die neu geöffnete Anwendung abzuspeichern, um diese Datei dadurch zu retten. Inzwischen habe ich bemerkt, dass größere geöffnete Dateien ziemlich oft zum Absturz neigen, insbesondere, wenn ich bspw. von ganz unten mit der Kursortaste nach oben rolle. Dann habe ich mich schon daran gewöhnt, dieses Problem zu lösen, indem ich mit gg erst mal ganz nach oben gehe und dann nach unten scrolle. Angaben darüber, ob ein Suchmuster so viel wie möglich oder so wenig wie möglich vorhanden sein sollen, werden ggf. nicht korrekt ausgeführt, wenn innerhalb einer Klammer eine Mengenangabe vorkommt, die so viel wie möglich angibt; und der gesamte Klammerausdruck mit einer Mengenangabe versehen ist, die so wenig wie möglich angibt. Die Mengenangabe zum Klammerausdruck wird so viel wie möglich interpretiert. Wenn in einer Zeile ein Wort bspw. 4 mal ist, wie bspw. hier: Wort Wort Wort Wort Und der Kursor befindet sich zwischen dem ersten und dem zweiten Wort; und man sucht nach "Wort Wort", so wird als nächster Treffer die letzten beiden Wörter dieser Zeile angezeigt. Das ist deswegen so, weil Vim jeweils vom Zeilenanfang beginnend die Treffer entsprechend markiert. Wenn ich ein Makro a Tausend mal ausführen will, und das entsprechend mit 1000@a angebe, wird manchmal dieses Makro 1001 mal ausgeführt, weswegen ich mir angewöhnt habe, in diesem Fall das Makro nur 999 mal ausführe und dann das fehlende Makro noch einmal mit @a. Wenn man im Suchmuster den Unterstrich _ angibt, erlaubt man an dieser Stelle damit auch andere Zeichen, wie bspw. dem Anführungs- und dem Prozentzeichen: " %. Auch das Kanzeln mit dem Backslash \ vor diesem nützt nichts. Abhilfe: Den Unterstrich als erstes Zeichen angeben in der Recteckklammer.
| |
| 22.04.2008 16:02:42 | | |
| ForumLeaks |
| |
| Gruppe: Administrator Rang: Mehr als 1000 Beiträge Beiträge: 1596 Mitglied seit: 29.06.2005 IP-Adresse: gespeichert | Eigentlich wollte ich in einer PHP-Datei nur nach dem nächsten auskommentierten Absatz suchen: /^\s*\/\*.\{-}\(\n.\{-}\)\{-}\S.\{-}\(\n.\{-}\)\{-}\n\s*\*\/ Aber Vim erstarrt ehrfurchtsvoll und völlig ratlos bei solch einem "megagigantischen" Suchmuster, wenn die nächste gefundene Kommentierung so umfangreich wie bspw. diese hier ist: /* phpBB 3.0 Style Sheet -------------------------------------------------------------- Style name: proSilver Based on style: proSilver (this is the default phpBB 3 style) Original author: subBlue ( http://www.subBlue.com/ ) Modified by: Copyright 2006 phpBB Group ( http://www.phpbb.com/ ) -------------------------------------------------------------- */ Versuchen Sie doch erst mal sämtliche Zeilenumbrüche \n durch bspw. das Symbol ¶ zu erstzen und den Suchbefehl entsprechend anzupassen. Vielleicht haben Sie dann mehr Glück, denn erfahrungsgemäß hat der Vim mit Zeilenumbrüchen manchmal so seine Probleme. Beim Ersetzen des Zeichens ¶ durch \r werden die Zeilenumbrüche wieder hergestellt. Solche Probleme könnten bei mir dadurch verursacht werden, dass main PC noch ein älteres Modell mit geringem Arbeitsspeicher (128 MB) ist und niedriger CPU-Taktrate (666 MHz). Denn eigentlich ist doch der Vim im Vergleich zu anderen Editoren ein ziemlich schnell und zuverlässig arbeitender Editor. Nachfolgendes Suchmuster soll nach übersetzungsfähigen Textabschnitten suchen, die jeweils nach einer schließenden geschwungenen Klammer sind: /}[^{]\{-}\([^!?. {][^!?.{]\{-}\)\{-}[a-zA-ZäöüÄÖÜß]\+[^a-zA-ZäöüÄÖÜß!?.{]\{-1,}[a-zA-ZäöüÄÖÜß]\+\([^!?.{]*[^!?. {]\)*Leider erstarrt das System. Nachdem man den Task beendete und Vim neu aufrief, funktioniert die Suche aber einwandfrei. Grundsätzlich habe ich schon öfter festgestellt, dass der Vim bei besonders langen Suchmustern Probleme hat. Insbesondere dann, wenn zudem auch noch der Text besonders lang ist. Besser ist es, bspw. Ersetzungsbefehle in kleineren Schritten auszuführen; also mit damit verbundenen kleineren Suchmustern. Im Quellcode einer Webseite suchte ich nach diesem Suchmuster, nämlich nach beliebigem Text mit beliebig vielen Zeilenumbrüchen vor der Zeichenfolge dj37: /.\+\(\n.*\)*dj37 Aber leider passierte sehr viele Minuten nichts. Dann kam die Meldung, dass die Suche am Anfang fortgesetzt wird, bis wieder sehr viele Minuten nichts passierte. Endlich kam die Meldung, dass dieser Suchausdruck nicht gefunden wurde. Beide nachfolgenden Ersetzungsbefehle funktionieren einwandfrei, wenn man diese jeweils einzeln nacheinander ausführt. Führt man diese aber gemeinsam als ein Makro aus, wird das gg ignoriert, wodurch das A anstatt ganz oben, ganz unten eingefügt wird. Abhilfe schafft ein zusätzliches Escape <Esc> hinter dem ersten Ersetzungsbefehl. Erzeugt wird es übrigens im Einfügemodus mit <Strg+K> und dann EC. :g#.#s#><a href="\.?id=1431&thread=\(\d\+"\) ggOA Ich schätze mal, dass sich die Zeit ungefähr zur Entwicklung von umfangreicheren Makros ungefähr verdoppelt, weil man leider allzu oft Fehlverhalten dieses Editors jeweils irgendwie ausgleichen muss. Aber bald wird die Version 6.2 erscheinen. Hoffen wir mal das Beste! Zum Thema Editor Vim bzw. gVim 7.1 siehe auch meine Threads zu diesen beiden Themen: Wie erzeuge ich mit Vim bzw. gVim das Steuerungszeichen ^M (Return) im Ersetzen-Modus: http://www.winboard.org/forum/allgemeines/71149-der-texteditor-vim-das-steuerungszeichen-cr-carriage-return.html http://www.tutorials.de/forum/html-editoren/292722-wie-erzeuge-ich-mit-vim-bzw-gvim-das-steuerungszeichen-m-return-im-ersetzen-modus.html Überarbeitete Version des deutschen Vim- bzw. gVim-Tutorials: http://www.winboard.org/forum/dokumentationen/71207-uberarbeitete-version-des-deutschen-vim-bzw-gvim-tutorials.html http://www.tutorials.de/forum/html-editoren/292724-berarbeitete-version-des-deutschen-vim-bzw-gvim-tutorials.html Auf dieser Webseite: Klick! habe ich einen Tip gefunden, wie man die verschiedensten Zeichen, u.a. auch das Return-Zeichen, in einen Text einfügen kann. Nämlich mit :digraph alle verfügbaren Zeichen anzeigen lassen. Zur Einfügung in den Einfügemodus mit a oder i wechseln! Mit <Strg-K> bzw. <CTRL-K> (Fragezeichen erscheint) und der nachfolgenden Eingabe der entsprechenden Zeichenfolge wird das gewünschte Symbol eingefügt. Symbole (außer Steuerzeichen) können auch so eingefügt werden: <Alt> + eine betimmte Taste: Þ±²³´µ¶·¸¹°ß´«üïéõúôòñæçêëìöä£*®¬íîâöãöãøù¼ ´´ ` <Alt Gr> + Taste: ²³{[]}\~€@µ| @€~|µ <Alt> + <Umschalt> + Taste: °¡¢§¤¥¦¯¨©½¿ààÑÒÔÚÕÉÏܪÆÇÊËÌÖħ¾ÙØÃÖÂÎÍ»º Mit dem Editor Vim kann man auch rechenen; aber fragt mich nicht wie! Im Internet habe ich nur herausgefunden, dass man mit <Strg+A> addieren kann und mit <Strg+X> subtrahieren. Erstes geht schon mal nicht unter Windows 98. Es wird nur Text markiert. Aber das Subtrahieren funktioniert. Wenn ich den Kursor im Befehlsmodus auf eine Zahl setze und bspw. 3 tippe und dann die Strg-Taste gedrückt halte und dann die Taste X drücke, wird von dieser Zahl 3 abgezogen. Mit einem Trick kann man aber auch mit <Strg+X> addieren. Einfach vor die Zahl, zu der was addiert werden soll, ein Minus - setzen und dann die gewünschte Zahl substrahieren! Der Betrag dieser Zahl (also der reine Zahlenwert ohne das Minus) eröht ihren Wert um diesen Betrag. Wenn man diese Funktion in einem Makro einbauen möchte, so erzeugt man <Strg> und <X> mit dem blau dargestellten Steuerzeichen ^X. Dieses erzeugt man mit CN, indem man also im Einfügemodus <Strg> + <K> und dann CN drückt. Übrigens habe ich zufällig herausgefunden, wie man ein oder mehrere Zeichen wiederholt einfügt. Bspw. soll AB 12 mal erscheinen. Im Normal-Modus tippt man 12. Dann geht man in den Einfüge-Modus bspw. mit i und schreibt AB. Dann drückt man die Taste <Esc>. Wenn man mit p was aus der Vim-Zwischenablage einfügt, ist der Cursor anschließend am Anfang des Eingefügten, wenn es sich nur um eine Zeile handelte. Waren es aber mehrere Zeilen, befindet er sich dann am Ende der ersten Zeile. Bei der Erstellung eines Makros können solche sinnlosen Sperenzien zu Problemen führen, wenn man das nicht beachtet. Ungewöhnlich finde ich auch, dass nach dem Überschreiben eines mit v (visual) markierten Inhalts die Vim-Zwischenablage den zuvor markierten Text enthält. Zwei Zeilen verbindet man miteinander, indem man den Kursor in die obere Zeile bringt und den Großbuchsstaben J tippt. Diese Zeile wird dadurch mit der Zeile darunter verbunden. Und es wird eine Leerstelle zwischen beiden eingefügt.
| |
| 19.05.2008 16:53:06 | | |
| ForumLeaks |
| |
| Gruppe: Administrator Rang: Mehr als 1000 Beiträge Beiträge: 1596 Mitglied seit: 29.06.2005 IP-Adresse: gespeichert | Die Fehlermeldung E342: Kein Speicherplatz mehr vorhanden (… Bytes reserviert) kann auftreten, wenn der Arbeitsspeicher des Computers nicht mehr ausreichend ist. Beispielsweise häuft der Internet Explorer 6 mit der zeit immer mehr Daten im Arbeitsspeicher an, bis dieser so voll ist, sodass nur noch ein Neustart des PC helfen kann. Auch wenn der Editor Vim schon sehr lange in Betrieb war, könnte dadurch der Arbeitsspeicher zu voll sein. Dies kann sich auch bemerkbar machen, dass der Editor Kommandos nicht mehr richtig ausführt. Diese Fehlermeldung kann aber auch eine andere Ursache haben. Ich hatte ein Makro, das eine mit der Zeit immer länger werdende Zeile erzeugte. Irgendwann wurde aber der Vorgang mit obiger Meldung abgebrochen. Es handelte sich um ein Makro, das im Wesentlichen nur Kommandos wie Vorwärtssuche /, Rückwärtssuche ?, Löschen x. Ersetzen r, Visualmodus v, Kopieren y, komplette Zeile kopieren Y, Zeile an nachfolgende Zeile anfügen J, zum Dokumentende gehen G, zum Zeilenende gehen $, in den Einfügemodus wechseln a + i, Escape [, Einfügen p und Return ^M enthielt, aber keine Ersetzungskommandos. Das Kommando Y kopierte nicht nur die Zeile, sondern fügte zugleich einen Zeilenumbruch am Anfang an, sodass nach dem Anfügen mit p an die immer werdende Zeile, diese nicht direkt an diese, sondern unter diese eingefügt wurde. Mit dem Kommando J musste dann das Makro die lange Zeile an die Zeile darunter anfügen. Eine andere Möglichkeit wäre übrigens gewesen, die Zeile mit V zu markieren und mit y zu kopieren. Weil ich das Kommando zum Zusammenfügen von Zeilen J (und vielleicht auch Y) als Auslöser für diese Fehlermeldung in Verdacht hatte, änderte ich das Makro so um, dass ich dieses J vermied, indem ich die Zeile markierte, indem das Makro mit 0 (Null) zum Zeilenanfang ging, in den Visualmodus mit v schaltete und dann zum Ende der Zeile, wodurch die ganze Zeile markiert wurde. Weil dabei kein Zeilenumbruch eingefügt wurde, konnte das Makro dann diese Zeile direkt an die lange Zeile anfügen, sodass ein Anfügen mit J vermieden wurde. Das so veränderte Makro verursachte diese Fehlermeldung und den damit verbundenen Abbruch dann nicht mehr. Auch verursacht das Verbinden von Zeilen mit dem Ersetzungsbefehl :%s#\n diese Fehlermeldung, wenn dabei besonders lange Zeilen entstehen. Auch hier kann man diese Fehlermeldung mit dem damit verbundenen Abbruch verhindern, indem man Zeilen so miteinander verbindet, indem man beispielsweise die jeweils anzufügende Zeile mit D löscht (oder mit 0v$ markiert und dann mit y kopiert, falls diese an der ursprünglichen Position erhalten bleiben soll) und dann mit p an die andere Zeile anfügt. Es gibt vier Möglichkeiten, aber nur zwei von diesen sunktionieren auch bei mehr als 5000 zeilen, um diese zu verbinden. Je mehr Zeilen aneinandergefügt werden sollen, um so (zunehmend) langsamer läuft der Vorgang ab. Erste Zeit für große Datei, zweite für Datei mit nur kanapp über 1000 Zeilen und die dritte Zeit wieder für eine große Datei, allerdings für eine Verbinden von 10 000 zeilen. Die ersten vier Codes beginnen oben, die letzten beiden unten. Nachfolgender Code schneidet die oberste Zeile aus und fügt sie an den Anfang der Zeile darunter an. Dann wird diese längere Zeile ausgeschnitten und so weiter. Zuletzt werden die daurch oben entstehenden Leerzeilen gelöscht. ggDjP an den Anfang! 0DjP 998x ggv/. x ans Ende anfügen! 1:14 1:13 40:00 Nachfolgender Code schneidet die zweite Zeile von oben aus und fügt sie ans Ende der Zeile darüber an. Dann wird die dadurch entstandene Leerzeile darunter gelöscht und wieder die zweite Zeile von oben ans Ende der obersten Zeile angefügt. Und so weiter. ggj an den Anfang! Dk$pjdd 999x 1:33 1:32 Nach 24 Minuten Abbruch. Anscheinend bewirkt das jeweilige Löschen mit dd der jeweils während des Vorgangs entstehenden Leerzeile die fehlermeldung. Nachfolgender Code bewirkt aber leider auch einen Abbruch. Bei diesem Code wird jeweils die Leerzeile nicht mit dd, sondern mit einer Kombination von Markieren (Visualmodus - v) und Löschen (x) gelöscht. ggjDk$p an den Anfang! /. v?. jxDk$p Nach 52 Minuten Abbruch. Ein Versuch mit nachfolgenden Code war aber erfolgreich, wo allerdings die Leerzeilen jeweils einfach stehen bleiben. Am Schluss kann/muss man dann diese als ganzen Block löschen, weswegen dieser Code natürlich nicht so gut geeignet ist. ggjDk$p an den Anfang! /. D?. p 2:20 Nachfolgender Code schneidet die unterste Zeile aus und fügt sie ans Ende der Zeile darüber an. Dann wird diese unterste längere Zeile ausgeschnitten und so weiter. Zuletzt werden die dadurch unten entstandenen Leerzeilen gelöscht. GDk$p an den Anfang! 0Dk$p 998x Gv?. lx ans Ende anfügen! 1:13 1:03 42:00 Nachfolgender Code schneidet die zweite Zeile von unten aus und fügt sie an den Anfang der untersten Zeile an. Dann wird sie dadurch darüber entstandene Leerzeile gelöscht. Dann wird wieder die zweite Zeile von unten ausgeschnitten und so weiter. G an den Anfang! kDjPkdd 999x 1:46 1:32 Nach 19:30 Abbruch. Nachfolgendes Ersetzungskommando entfernt zwar alle Zeilenumbrüche in nur drei Sekunden, wenn der gesamte Text aus 1000 Zeilen besteht. Allerdings darf das Dokument aus nicht viel mehr als 5000 Zeilen bestehen, weil sonst obige Fehlermeldung erscheint. Möglicherweise ist die maximal mögliche Anzahl an zeilen größer, wenn der Arbeitsspeicher des PC größer ist. :%s#\n
| |
| 30.01.2010 13:17:50 | | |
| ForumLeaks |
| |
| Gruppe: Administrator Rang: Mehr als 1000 Beiträge Beiträge: 1596 Mitglied seit: 29.06.2005 IP-Adresse: gespeichert | Sucht man beispielsweise nach auto\|pkw; es soll also die nächste Stelle angezeigt werden, wo eines dieser beiden Wörter ist; kann es in Ausnahmefällen passieren, dass die nächste Stelle, wo 'pkw' vorhanden ist, übersprungen wird; und man stattdessen die nächste Position angezeigt bekommt, wo 'auto' vorhanden ist. Dies sollte man gegebenenfalls berücksichtigen, falls man ein Makro schreibt, wo es darauf ankommt, dass unbedingt die nächste Trefferposition angezeigt werden muss. BOM kann beim Einbinden einer Datei bei PHP Probleme machen. Eine Datei speichert man mit dem Vim ohne BOM ab, indem man :set nobomb setzt und dann die Datei wie gewohnt abspeichert. :sort sortiert alle Zeilen alphabetisch. :sort u entfernt zudem alle doppelten Zeilen. :.,$sort sortiert von der aktuellen Kursorposition bis zum Dateiende. Auch kann man nur einen bestimmten Textbereich sortieren, indem man diesen im Visualmodus (Markieren) v oder V vorher markiert. Ein Ersetzungsbefehl, dessen Suchmuster Zeichen erfassen, wodurch die Ersetzung geschieht, hat zur Folge, dass der Kursor dann am Zeilenanfang ist. Wenn der Ersetzungsbefehl aber nichts ersetzt, weil dem Suchmuster keine Zeichen entsprechen, bleibt der Kursor wo er ist. Es ist möglich, dass man beispielsweise einen Ersetzungsbefehl nur innerhalb des zuvor mit v oder V (Visualmodus) markierten Bereichs ausführt. Hierzu markiert man den gewünschten Bereich mit v oder V und drückt dann :. Unten erscheint schon der Bereich :'<,'>, sodass man nur noch beispielsweise mit s#a#b ergänzt, um in den zuvor markierten Zeilen a durch b zu erstzen. Innerhalb des so markierten Bereichs kann aber nicht gesucht werden. Falls man aber doch nach dem Markieren eine Suche durchführt, beginnt oder endet dann der markierte Bereich am Suchergebnis, was gegebenenfalls auch gewünscht sein kann. Auch die unterste Zeile eines Dokuments endet für den Vim mit einem Zeilenumbruch, auch wenn dort eigentlich keiner sein kann, weil darunter keine Zeile ist. Zudem beachte man, dass eine Leerzeile inmitten des Dokumentes eine Aufeinanderfolge von zwei Zeilenumbrüchen ist. Wenn aber über der Leerzeile keine Textzeile ist, ist dort nur noch ein Zeilenumbruch vorhanden. :'a,'b+2s/def/xyz/g Von Marke a bis Marke b und zwei Zeilen weiter alle Vorkommen von def durch xyz ersetzen; alle Vorkommen in den Zeilen (g).
| |
| 07.02.2010 12:09:59 | | |
|
| Thread-Info | |
|---|---|
| Zugriff | Moderatoren |
| Lesen: alle Schreiben: alle Gruppe: allgemein | keine |
| Forum Übersicht |
.: Script-Time: 0,109 || SQL-Queries: 6 || Active-Users: 3 772 :.
Powered by ASP-FastBoard HE v0.8, hosted by cyberlord.at