expertenaustausch > comp.* > comp.editoren

Philipp E. Imhof (09.05.2005, 18:19)
Hi!

Ich beschäftige mich wieder einmal mit Emacs. Heute stört mich dabei
folgendes ;-)

Unter *Jehova* kann ich mit o bzw O eine Zeile «öffnen». Wenn ich in
Emacs C-o mache, geht das auch, macht aber nicht genau das gleiche,
denn es ist ja eigentlich wie RET ohne den Point zu bewegen. Wie
kann ich in Emacs eine Zeile oberhalb (O) bzw. unterhalb (o) der
aktuellen Zeile eröffnen und direkt an den Anfang dieser Zeile
springen? (Natürlich ohne davor mit C-e an das Ende der aktuellen
Zeile springen zu müssen)

Auch mit C-k bin ich nicht ganz zufrieden. Unter einem anderen
Editor kann ich - egal wo in der Zeile ich bin - die ganze Zeile
inkl. Newline löschen lassen. Kann ich das in Emacs auch (abgesehen
von C-a C-k C-k)?

Danke für Tipps!

Gruss

Philipp
Ralf Angeli (09.05.2005, 21:36)
* Philipp E. Imhof (2005-05-09) writes:

> Unter *Jehova* kann ich mit o bzw O eine Zeile «öffnen». Wenn ich in
> Emacs C-o mache, geht das auch, macht aber nicht genau das gleiche,
> denn es ist ja eigentlich wie RET ohne den Point zu bewegen. Wie
> kann ich in Emacs eine Zeile oberhalb (O) bzw. unterhalb (o) der
> aktuellen Zeile eröffnen und direkt an den Anfang dieser Zeile
> springen? (Natürlich ohne davor mit C-e an das Ende der aktuellen
> Zeile springen zu müssen)


Eine Suche bei Google Groups mit den Suchbegriffen "open-line emacs vi"
fördert bspw.
<URL:http://groups.google.es/groups?hl=en&threadm=aibqpt%24cmn%241%40gaudi2.rug .ac.be>
zutage.

> Auch mit C-k bin ich nicht ganz zufrieden. Unter einem anderen
> Editor kann ich - egal wo in der Zeile ich bin - die ganze Zeile
> inkl. Newline löschen lassen. Kann ich das in Emacs auch (abgesehen
> von C-a C-k C-k)?


Da findet sich über Google Groups bestimmt auch was.
Philipp E. Imhof (10.05.2005, 17:56)
Ralf Angeli wrote:
> Eine Suche bei Google Groups mit den Suchbegriffen "open-line emacs vi"
> fördert bspw.
> <URL:http://groups.google.es/groups?hl=en&threadm=aibqpt%24cmn%241%40gaudi2.rug .ac.be>
> zutage.


Danke. Dann werde ich mich damit abfinden müssen.

>>Auch mit C-k bin ich nicht ganz zufrieden. Unter einem anderen
>>Editor kann ich - egal wo in der Zeile ich bin - die ganze Zeile
>>inkl. Newline löschen lassen. Kann ich das in Emacs auch (abgesehen
>>von C-a C-k C-k)?

> Da findet sich über Google Groups bestimmt auch was.


Auch hier. Es gibt immerhin Annäherungen.

Danke & Gruss

Philipp
Andreas Röhler (07.12.2005, 21:59)
Philipp E. Imhof wrote:

> Ralf Angeli wrote:
> Danke. Dann werde ich mich damit abfinden müssen.
> Auch hier. Es gibt immerhin Annäherungen.
> Danke & Gruss
> Philipp


Im Emacs-Handbuch finde ich unter "Killing by Lines" hierzu

When `C-k' is given a positive argument, it kills that many lines
and the newlines that follow them (however, text on the current line
before point is not killed). With a negative argument -N, it kills N
lines preceding the current line (together with the text on the current
line before point). Thus, `C-u - 2 C-k' at the front of a line kills
the two previous lines.

`C-k' with an argument of zero kills the text before point on the
current line.

If the variable `kill-whole-line' is non-`nil', `C-k' at the very
beginning of a line kills the entire line including the following
newline. This variable is normally `nil'.

Nun mag die Schaltung der Variablen nicht unbedingt das Richtige sein.

In diesem Fall ließen sich die Aufrufe z.B.

- als Makro speichern und dem Makro Tasten zuweisen

- unter neuem Funktionsnamen zusammenfassen und der Funktion Tasten zuweisen

Vorschlag für letzteres:

(defun immer-ganze-zeile-loeschen (&optional arg)
"Loesche ganze Zeile, mit Argument auch das Zeilenendezeichen"
(interactive "P*")
(beginning-of-line)
(if arg
(progn (setq kill-whole-line t)
(kill-line)
(setq kill-whole-line nil))
(kill-line)))

Obige Funktion bietet die Auswahl, via C-u auch das Zeilenende zu loeschen

Tasten hierzu

(global-set-key [C-kp-2] 'immer-ganze-zeile-loeschen)

Falls Du das Zeilenende in der Regel ohnehin loeschen willst,
läßt sich die Funktion noch kürzer schreiben

(defun loeschen-inkl-zeilenende ()
"Loesche ganze Zeile, auch das Zeilenendezeichen"
(interactive "*")
(beginning-of-line)
(setq kill-whole-line t)
(kill-line)
(setq kill-whole-line nil))

(global-set-key [C-kp-3] 'loeschen-inkl-zeilenende)

Gruesse

ar
Ralf Angeli (07.12.2005, 22:39)
* Andreas Röhler (2005-12-07) writes:

> - unter neuem Funktionsnamen zusammenfassen und der Funktion Tasten zuweisen
> Vorschlag für letzteres:
> (defun immer-ganze-zeile-loeschen (&optional arg) [...]


Muss das sein? Bei Google Groups finden sich gut funktionierende
Lösungen. Braucht man da noch weitere Vorschläge, die außerdem
ungefragt Benutzereinstellungen überschreiben?
Andreas Röhler (07.12.2005, 23:27)
Ralf Angeli wrote:

> [...]
> [...]
> Muss das sein? Bei Google Groups finden sich gut funktionierende
> Lösungen. Braucht man da noch weitere Vorschläge, die außerdem
> ungefragt Benutzereinstellungen überschreiben?

Bei Google Groups finde ich eine ganze Menge, darunter
Vorschläge, die ich nicht für geeignet halte.

Die Frage des Überschreibens von Benutzereinstellungen steht in
der Tat; soweit ich sehen kann, aber nicht nur bei den
übermittelten beiden Belegungen, die gerade noch überschaubar
sein dürften.

Dazu eine Frage: Ist eine Funktion bekannt, die
Emacs veranlaßt, während des Ladens von neuen Funktionen /
Tastenbelegungen Warnungen auszugeben und das Eingreifen - Vorgabe
alternativer Tasten - zu ermöglichen?

Gruesse

ar
Ralf Angeli (08.12.2005, 00:17)
* Andreas Röhler (2005-12-07) writes:

> Ralf Angeli wrote:
>> Muss das sein? Bei Google Groups finden sich gut funktionierende
>> Lösungen. Braucht man da noch weitere Vorschläge, die außerdem
>> ungefragt Benutzereinstellungen überschreiben?

> Bei Google Groups finde ich eine ganze Menge, darunter
> Vorschläge, die ich nicht für geeignet halte.


Und deswegen fügt man weitere ungeeignete Vorschläge hinzu? Es wäre
besser, einfach auf einen geeigneten hinzuweisen. Im konkreten Fall
wäre das mit der in Emacs enthaltenen Funktion `kill-whole-line', die
mit `C-S-backspace' sogar eine eigene Tastenkombination hat, relativ
einfach.

> Die Frage des Überschreibens von Benutzereinstellungen steht in
> der Tat; soweit ich sehen kann, aber nicht nur bei den
> übermittelten beiden Belegungen, die gerade noch überschaubar
> sein dürften.


Wo denn noch?

> Dazu eine Frage: Ist eine Funktion bekannt, die
> Emacs veranlaßt, während des Ladens von neuen Funktionen /
> Tastenbelegungen Warnungen auszugeben und das Eingreifen - Vorgabe
> alternativer Tasten - zu ermöglichen?


Man kann auf das Vorhandensein von Belegungen testen (siehe
(info "(elisp)Functions for Key Lookup")).
Ralf Angeli (08.12.2005, 01:08)
* Ralf Angeli (2005-12-07) writes:

> * Andreas Röhler (2005-12-07) writes:
> Und deswegen fügt man weitere ungeeignete Vorschläge hinzu? Es wäre
> besser, einfach auf einen geeigneten hinzuweisen. Im konkreten Fall
> wäre das mit der in Emacs enthaltenen Funktion `kill-whole-line', die
> mit `C-S-backspace' sogar eine eigene Tastenkombination hat, relativ
> einfach.
> Wo denn noch?


Um das klarzustellen: Das Problem sind nicht die Tastenbelegungen,
sondern dass deine Funktionen die Variable `kill-whole-line' global
überschreiben. Wenn du die Variable lokal verändern willst, mach das
mit `let'.
Andreas Röhler (08.12.2005, 11:55)
Ralf Angeli wrote:

> * Ralf Angeli (2005-12-07) writes:
> Um das klarzustellen: Das Problem sind nicht die Tastenbelegungen,
> sondern dass deine Funktionen die Variable `kill-whole-line' global
> überschreiben. Wenn du die Variable lokal verändern willst, mach das
> mit `let'.


Danke! Anbei die Korrektur.

(defun immer-ganze-zeile-loeschen (&optional arg)
"Loesche ganze Zeile, mit Argument auch das Zeilenendezeichen"
(interactive "P*")
(beginning-of-line)
(let ((kill-whole-line t))
(if arg
(kill-line)))
(kill-line)))

(global-set-key [C-kp-2] 'immer-ganze-zeile-loeschen)

(defun loeschen-inkl-zeilenende ()
"Loesche ganze Zeile, auch das Zeilenendezeichen"
(interactive "*")
(beginning-of-line)
(let ((kill-whole-line t))
(kill-line)))

(global-set-key [C-kp-3] 'loeschen-inkl-zeilenende)

Deine Hinweise an dieser Stelle waren mir nicht zum ersten Mal hilfreich. Auf der anderen Seite meine ich in der Art und Weise, wie die Diskussion gelaufen ist, den Ausdruck eines tieferen Problems zu sehen, das Emacs mit der Linux-Gemeinde teilt und die breitere Verwendung der Werkzeuge behindert. Daher aus gegebenem Anlaß eine Bemerkung, in der Hoffnung, daß sie nützlich ist...

Emacs ist mit der Verfügbarkeit von Elisp und Clisp großartig. Die erste Strecke des Weges für einen Anfänger aber ist unverändert zu steil, zu sehr mit Hindernissen gespickt. Diese Hürden sind mit den Emacs-Qualitäten nur indirekt verbunden und können beseitigt werden. Warum hervorragende Werkzeuge nicht mit einer Hilfe ausstatten, die sich auf dem Niveau des Hilfesuchenden befindet? Was bringt es, die Eingangstür in drei Meter Höhe zu mauern? Wir sind nun einmal in unseren geistigen Kapazitäten beschränkt, das ist menschlich. Selbst ein Einstein soll nicht der begabteste Mathematiker gewesen sein.

Wenn also einer, der Vim offenbar beherrscht, auf Google verwiesen wird, was soll das Publikum davon lernen? Sollen keine "dummen" Fragen mehr gestellt werden?

Ich verstünde gut, daß jemand, der selbst Emacs-Bauteile entwickelt und wartet, keine Zeit hat, sich um Derartiges zu kümmern. Dann soll er das andere machen lassen. Falls aber jemand weiß, wo es in Google steht, mag er es herbringen und uns ansehen lassen.

Laß uns doch in aller Ruhe Fehler bzw. Varianten in den Schnipseln diskutieren. Niemand wird erwarten, in solch einer Gruppe 100% getestete und zertifizierte Anworten zu bekommen. Die Leichtigkeit, via Lisp Programme anpassen und erweitern, das ist es doch. Wir sollten die Leute vom Selberschreiben und Probieren nicht abschrecken, sondern dazu ermuntern. Lasset Lisp frei aus der Feder fließen, es ist die Herrlichkeit! Selbst auf die Gefahr, daß ein Neustart notwendig wird...

Gruesse

ar
(ein Neustarter)
Ralf Angeli (08.12.2005, 12:35)
* Andreas Röhler (2005-12-08) writes:

> Danke! Anbei die Korrektur.
> (defun immer-ganze-zeile-loeschen (&optional arg)
> "Loesche ganze Zeile, mit Argument auch das Zeilenendezeichen"
> (interactive "P*")
> (beginning-of-line)
> (let ((kill-whole-line t))
> (if arg
> (kill-line)))
> (kill-line)))


Das stimmt hinten und vorn nicht. Bei dieser Fassung wird `kill-line'
zweimal ausgeführt, wenn ein Präfixargument mitgegeben wurde.
Außerdem ist die Klammerung daneben. Eine vereinfachte Variante
könnte folgendermaßen aussehen:

(defun immer-ganze-zeile-loeschen (&optional arg)
"Loesche ganze Zeile, mit Argument auch das Zeilenendezeichen"
(interactive "P*")
(beginning-of-line)
(let ((kill-whole-line arg))
(kill-line)))

> Emacs ist mit der Verfügbarkeit von Elisp und Clisp großartig. Die
> erste Strecke des Weges für einen Anfänger aber ist unverändert zu
> steil, zu sehr mit Hindernissen gespickt. Diese Hürden sind mit den
> Emacs-Qualitäten nur indirekt verbunden und können beseitigt
> werden. Warum hervorragende Werkzeuge nicht mit einer Hilfe
> ausstatten, die sich auf dem Niveau des Hilfesuchenden befindet?


Was meinst du damit? Es gibt das Tutorial für Anfänger. Fragen der
Nutzung von Emacs werden im Emacs-Handbuch beantwortet und die
Programmierung mit Emacs Lisp wird im Elisp-Handbuch behandelt. Diese
Handbücher sind über den Info-Reader zugänglich, durchsuchbar und
kommen mit Inhaltsverzeichnis und Index daher. Daneben gibt es den
Fächer der `C-h'-Funktionen. Das Ganze zusammengenommen ergibt eine
sehr gute Hilfe, die insbesondere in Form der Handbücher auch leicht
verständlich ist. Du musst also schon etwas spezifischer mit deiner
Kritik werden.

> Wenn also einer, der Vim offenbar beherrscht, auf Google verwiesen
> wird, was soll das Publikum davon lernen? Sollen keine "dummen"
> Fragen mehr gestellt werden?


Es geht nicht um "dumme" Fragen. Im konkreten Fall waren es Fragen,
die bereits zigfach gestellt und beantwortet wurden. Warum sollte man
in einem solchen Fall eine weitere Lösung zusammenbasteln?

> Ich verstünde gut, daß jemand, der selbst Emacs-Bauteile entwickelt
> und wartet, keine Zeit hat, sich um Derartiges zu kümmern. Dann soll
> er das andere machen lassen.


Das Problem dabei ist, dass dann unter Umständen halbgares Zeug
rauskommt, mit dem die Nutzer früher oder später Probleme bekommen.
Und dann fällt das oftmals wieder auf die Emacs-Entwickler zurück.

> Falls aber jemand weiß, wo es in Google steht, mag er es herbringen
> und uns ansehen lassen.


Bei einer Frage, die hunderte von Treffern liefert, von denen man sich
einen brauchbaren ohne Probleme selbst heraussuchen kann?

> Laß uns doch in aller Ruhe Fehler bzw. Varianten in den Schnipseln
> diskutieren.


Diese Diskussionen sind im konkreten Fall bereits gelaufen.

> Niemand wird erwarten, in solch einer Gruppe 100% getestete und
> zertifizierte Anworten zu bekommen.


Da wäre ich mir nicht so sicher. Und wie gesagt, Fehler rächen sich
meist später und dann oft an anderen.

> Die Leichtigkeit, via Lisp Programme anpassen und erweitern, das ist
> es doch. Wir sollten die Leute vom Selberschreiben und Probieren
> nicht abschrecken, sondern dazu ermuntern.


Aha, deine Antwort im konkreten Fall wäre dann gewesen, dass sich der
OP die relevanten Stellen im Elisp-Handbuch ansieht und sich die
entsprechenden Funktionen selbst baut?

> Lasset Lisp frei aus der
> Feder fließen, es ist die Herrlichkeit! Selbst auf die Gefahr, daß
> ein Neustart notwendig wird...
> Gruesse
> ar
> (ein Neustarter)


Windows-Nutzer?
Andreas Röhler (08.12.2005, 15:17)
Ralf Angeli wrote:

> * Andreas Röhler (2005-12-08) writes:
> Das stimmt hinten und vorn nicht. Bei dieser Fassung wird `kill-line'
> zweimal ausgeführt, wenn ein Präfixargument mitgegeben wurde.


de facto.

> Außerdem ist die Klammerung daneben. Eine vereinfachte Variante
> könnte folgendermaßen aussehen:
> (defun immer-ganze-zeile-loeschen (&optional arg)
> "Loesche ganze Zeile, mit Argument auch das Zeilenendezeichen"
> (interactive "P*")
> (beginning-of-line)
> (let ((kill-whole-line arg))
> (kill-line)))


So macht das doch Spaß. Respekt!
Eine analog gemeinte Überarbeitung für die zweite Funktion:

(defun loeschen-inkl-zeilenende (&optional arg)
"Loesche ganze Zeile, auch das Zeilenendezeichen"
(interactive "*")
(beginning-of-line)
(let ((kill-whole-line (prefix-numeric-value arg)))
(kill-line)))

Einverstanden?

> Was meinst du damit? Es gibt das Tutorial für Anfänger. Fragen der
> Nutzung von Emacs werden im Emacs-Handbuch beantwortet und die
> Programmierung mit Emacs Lisp wird im Elisp-Handbuch behandelt. Diese
> Handbücher sind über den Info-Reader zugänglich, durchsuchbar und
> kommen mit Inhaltsverzeichnis und Index daher. Daneben gibt es den
> Fächer der `C-h'-Funktionen. Das Ganze zusammengenommen ergibt eine
> sehr gute Hilfe, die insbesondere in Form der Handbücher auch leicht
> verständlich ist. Du musst also schon etwas spezifischer mit deiner
> Kritik werden.


Das Tutorial ist in Ordnung, aber zu kurz.

Beim ersten Arbeiten mit Emacs ist für den Lisp-Unkundigen zwischen fehlerhaften Anweisungen und Bugs - die erwartet werden - kaum zu unterscheiden. Das Handbuch ist für den Anfänger nicht auf einen Zug durchzulesen, da zu komlex und umfangreich. Ein Blick in dieses im Notfall führt den Einsteiger oft zu weiteren Fragen, statt zur Lösung des Problems.

Das Handbuch liegt meines Wissens nur auf Englisch vor.

Bücher wie "Emacs in 24 Hours von Jesper Pedersen" - auf deren Netzseite wurde in dieser Gruppe hingewiesen - füllen diese Lücke, sind dem Benutzer, der sich eben Linux installiert hat, aber nicht unbedingt zur Hand. Schlage vor, so etwas zum Bestandteil der Standardedition zu machen.

>> Wenn also einer, der Vim offenbar beherrscht, auf Google verwiesen
>> wird, was soll das Publikum davon lernen? Sollen keine "dummen"
>> Fragen mehr gestellt werden?

> Es geht nicht um "dumme" Fragen. Im konkreten Fall waren es Fragen,
> die bereits zigfach gestellt und beantwortet wurden. Warum sollte man
> in einem solchen Fall eine weitere Lösung zusammenbasteln?


Also, ich habe in Google gesucht, aber Deine Lösung von oben beispielsweise nicht gefunden.

Dafür gabs anderen interessanten Stoff, z.B. eine weitere Variante von kill-whole-line

Florent Rougon schrieb am 17 Mai 2000

Comme suggéré avec `C-h f kill-line', on peut utiliser `C-a C-k'
(beginning-of-line puis kill-line).
On peut aussi se bricoler une fonction du style :

(defun kill-whole-line (arg)
"Kill the whole current line.
With just C-u prefix arg, also kill the newline at its end if present."
(interactive "P")
(kill-region
(progn
(beginning-of-line)
(point)
)
(progn
(if (equal arg '(4))
(forward-line)
(end-of-line)
)
(point))))

Gib bitte jetzt nicht mir die Schuld für diese Publikation,
Du hast Google Groups vorgeschlagen (;)

>> Ich verstünde gut, daß jemand, der selbst Emacs-Bauteile entwickelt
>> und wartet, keine Zeit hat, sich um Derartiges zu kümmern. Dann soll
>> er das andere machen lassen.

> Das Problem dabei ist, dass dann unter Umständen halbgares Zeug
> rauskommt, mit dem die Nutzer früher oder später Probleme bekommen.
> Und dann fällt das oftmals wieder auf die Emacs-Entwickler zurück.


Daran sind die Emacs-Entwickler nach meinem - noch nicht ganz abgerundeten - Eindruck nicht ganz unbeteiligt. Emacs und Elisp sind keine heilige Messe. Es muß nicht immer alles fix und fertig sein und man sollte auch nicht den Eindruck erwecken, daß man dies zu erreichen sei. (Ich bin immer schon sehr erfreut, falls mein Rechner überhaupt anspringt...)

Die Universalität von Emacs nebst der Entwicklungsgeschwindigkeit macht gelegentliche Hänger unvermeidlich, aber daß wirst Du sehr viel besser wissen als ich.

Es gibt Strategien, gleichwohl fast störungsfreies Arbeiten zu ermöglichen. Z.B. muß es nicht immer der neueste Emacs sein. Das zu hören wird Dich als Entwickler nicht erfreuen, aber denk doch bitte auch an das Volk, das vielleicht Termine hat, irgendeinen Text abliefern usw. Sollen wir denn alle ohne Emacs sein? (Wir sind das Volk!)

>> Falls aber jemand weiß, wo es in Google steht, mag er es herbringen
>> und uns ansehen lassen.

> Bei einer Frage, die hunderte von Treffern liefert, von denen man sich
> einen brauchbaren ohne Probleme selbst heraussuchen kann?


s.o,
>> Laß uns doch in aller Ruhe Fehler bzw. Varianten in den Schnipseln
>> diskutieren.

> Diese Diskussionen sind im konkreten Fall bereits gelaufen.


Vielleicht. Aber mit jedem, der das Licht erblickt,
fängt doch auch die Welt ein wenig von vorne an. Sicher läßt sich alle Weisheit in der einen oder
anderen Form bereits bei Aristoteles nachlesen. Daß immer noch Bücher geschrieben werden, ist nicht
vollkommen logisch zu erklären, da bleibt ein irrationaler Rest.

>> Niemand wird erwarten, in solch einer Gruppe 100% getestete und
>> zertifizierte Anworten zu bekommen.

> Da wäre ich mir nicht so sicher. Und wie gesagt, Fehler rächen sich
> meist später und dann oft an anderen.


Gibts denn schon Emacs-Opfergruppen?

Um nochmals zu komplimentieren: Emacs ist eine robuste Maschine. Wer überhaupt
angefangen hat, dafür zu schreiben, darf mit etwas Umsicht darauf hoffen, den Fehler über Debug-Modi
zu finden. Und wer unter Linux auf Schaden aus ist, braucht keinen Emacs dafür.

> Aha, deine Antwort im konkreten Fall wäre dann gewesen, dass sich der
> OP die relevanten Stellen im Elisp-Handbuch ansieht und sich die
> entsprechenden Funktionen selbst baut?
> Windows-Nutzer? Letztere Bemerkung dürfte ja wohl den Gipfel des Beleidungspotentials markieren.


Na gut.

Bin geknickt.

ar
Ralf Angeli (08.12.2005, 18:14)
* Andreas Röhler (2005-12-08) writes:

> Ralf Angeli wrote:
> So macht das doch Spaß. Respekt!
> Eine analog gemeinte Überarbeitung für die zweite Funktion:
> (defun loeschen-inkl-zeilenende (&optional arg)
> "Loesche ganze Zeile, auch das Zeilenendezeichen"
> (interactive "*")
> (beginning-of-line)
> (let ((kill-whole-line (prefix-numeric-value arg)))
> (kill-line)))
> Einverstanden?


Nö. Wofür brauchst du `prefix-numeric-value' wenn du das
Präfixargument nicht über die `interactive'-Anweisung ausliest? In
obiger Funktion ist `arg' immer nil, wenn man sie mit `M-x ...' oder
über eine Tastenkombination aufruft.

Ich finde sowieso, dass eine einzige Funktion reichen würde. Die kann
entweder von `kill-whole-line' unabhängig oder abhängig sein. In
ersterem Fall würde sie beispielsweise die ganze Zeile inklusive
Umbruch löschen, wenn sie ohne Präfixargument aufgerufen wird, und die
ganze Zeile ohne Umbruch mit Präfixargument. In letzerem Fall würde
sie sich ohne Präfixargument so verhalten, wie es der Nutzer aufgrund
seiner Einstellung von `kill-whole-line' auch von `kill-line' erwarten
würde. Wird die Funktion mit Präfixargument aufgerufen, würde das
jeweils andere Verhalten aktiviert.

> Das Tutorial ist in Ordnung, aber zu kurz.


Es soll ja auch nur die grundlegende Bedienung vermitteln.
Weitergehende Informationen gibt es im Handbuch.

> Beim ersten Arbeiten mit Emacs ist für den Lisp-Unkundigen zwischen
> fehlerhaften Anweisungen


Was meinst du mit "fehlerhaften Anweisungen"?

> und Bugs - die erwartet werden -


Also ich persönlich erwarte keine Bugs, wenn ich ein Programm starte.
Das hört sich bei dir an, als ob alle Nase lang ein Fehler auftreten
würde.

> kaum zu unterscheiden. Das Handbuch ist für den Anfänger nicht auf
> einen Zug durchzulesen, da zu komlex und umfangreich. Ein Blick in
> dieses im Notfall führt den Einsteiger oft zu weiteren Fragen, statt
> zur Lösung des Problems.


Hast du dafür ein Beispiel? In der Regel hilft es, sich ein wenig im
Kontext der Fragestellung zu informieren.

> Das Handbuch liegt meines Wissens nur auf Englisch vor.


Das stimmt.

> Bücher wie "Emacs in 24 Hours von Jesper Pedersen" - auf deren
> Netzseite wurde in dieser Gruppe hingewiesen - füllen diese Lücke,
> sind dem Benutzer, der sich eben Linux installiert hat, aber nicht
> unbedingt zur Hand.


Hm, ich selbst habe noch nie ein Emacs-Buch in der Hand gehabt und es
bisher auch nicht vermisst.

> Schlage vor, so etwas zum Bestandteil der Standardedition zu machen.


Dafür gibt es das Handbuch. Und es erfordert mehr als genug Aufwand,
das aktuell in Bezug auf den Funktionsumfang von Emacs zu halten. Die
Durchsicht der Dokumentation ist beispielsweise einer der Punkte, die
den Release von Emacs 22 aufhalten.

>> Es geht nicht um "dumme" Fragen. Im konkreten Fall waren es Fragen,
>> die bereits zigfach gestellt und beantwortet wurden. Warum sollte man
>> in einem solchen Fall eine weitere Lösung zusammenbasteln?

> Also, ich habe in Google gesucht, aber Deine Lösung von oben
> beispielsweise nicht gefunden.


Na und? Dafür gibt es genug andere.

[..]
> (point))))
> Gib bitte jetzt nicht mir die Schuld für diese Publikation,
> Du hast Google Groups vorgeschlagen (;)


Die Funktion wird keine Schönheitswettbewerbe gewinnen, aber sie ist
zumindest nicht fehlerhaft. (... unter Vorbehalt. Ich habe nicht
alle möglichen Randbedingungen getestet.)

>> Das Problem dabei ist, dass dann unter Umständen halbgares Zeug
>> rauskommt, mit dem die Nutzer früher oder später Probleme bekommen.
>> Und dann fällt das oftmals wieder auf die Emacs-Entwickler zurück.

> Daran sind die Emacs-Entwickler nach meinem - noch nicht ganz
> abgerundeten - Eindruck nicht ganz unbeteiligt. Emacs und Elisp sind
> keine heilige Messe.


Frag mal die Leute in alt.religion.emacs ...

> Es muß nicht immer alles fix und fertig sein und man sollte auch
> nicht den Eindruck erwecken, daß man dies zu erreichen sei. (Ich bin
> immer schon sehr erfreut, falls mein Rechner überhaupt anspringt...)


Es geht hier nicht um "fix und fertig", sondern um weitestgehende
Fehlerfreiheit. Und die ist eher zu erreichen, wenn man einigermaßen
sattelfest in der Handhabung der entsprechenden Werkzeuge ist.

> Es gibt Strategien, gleichwohl fast störungsfreies Arbeiten zu
> ermöglichen. Z.B. muß es nicht immer der neueste Emacs sein. Das zu
> hören wird Dich als Entwickler nicht erfreuen,


Das ist doch in Ordnung, solange man mit der Funktionalität zufrieden
ist und mit den Fehlern leben kann. Sobald das nicht mehr zutrifft,
muss man sich halt, sofern vorhanden, eine neuere Version besorgen,
die dann um ein paar Fehler bereinigt ist und neue Funktionalitäten,
aber in der Regel auch neue Fehler mitbringt.

>> Da wäre ich mir nicht so sicher. Und wie gesagt, Fehler rächen sich
>> meist später und dann oft an anderen.

> Gibts denn schon Emacs-Opfergruppen?


Da fragst du am besten auch die Leute in alt.religion.emacs.

> Letztere Bemerkung dürfte ja wohl den Gipfel des
> Beleidungspotentials markieren.
> Na gut.
> Bin geknickt.


Also komm, bei _der_ Vorlage ...
Frank Küster (08.12.2005, 19:29)
Ralf Angeli <dev.null> wrote:

> * Andreas Röhler (2005-12-08) writes:
> Hast du dafür ein Beispiel? In der Regel hilft es, sich ein wenig im
> Kontext der Fragestellung zu informieren.


Ich möchte z.B. wissen, wie ich bestimmten Kommandos einen
Tastaturshortcut zuordne. Das erfahre ich zwar an einer Stelle, die
ziemlich gut zu finden ist (über Customization, oder den Concept Index,
oder wasweissich). Aber da ist nur "M-x global-set-key ..."
beschrieben. Es gibt keine Beispiele, wie ich das in die .emacs
eintragen kann. Dazu muss man dann wieder nachsehen, wo die lisp-Syntax
von Funktionen generell beschrieben ist. Oder man kopiert einfach Code
von irgendwo und verändert ihn - der wird in diesem Fall sogar
funktionieren; aber mit dem Manual hat man es nicht gelöst.

Was ich auch immer furchtbar unübersichtlich fand, ist alles was mit
"Faces" zu tun hat. Ich fürchte aber, dass es da nicht an der
schlechten Erklärung liegt, sondern dass das einfach ziemlich komplex
ist.

Gruß, Frank
Andreas Röhler (08.12.2005, 19:34)
Ralf Angeli wrote:

> Nö. Wofür brauchst du `prefix-numeric-value' wenn du das
> Präfixargument nicht über die `interactive'-Anweisung ausliest? In
> obiger Funktion ist `arg' immer nil, wenn man sie mit `M-x ...' oder
> über eine Tastenkombination aufruft.


ich hoffe ich schaffs noch vor dem Zapfenstreich:

(defun loeschen-inkl-zeilenende ()
"Loesche ganze Zeile, auch das Zeilenendezeichen"
(interactive "*")
(beginning-of-line)
(let ((kill-whole-line t))
(kill-line)))

> Ich finde sowieso, dass eine einzige Funktion reichen würde. Die kann
> entweder von `kill-whole-line' unabhängig oder abhängig sein. In
> ersterem Fall würde sie beispielsweise die ganze Zeile inklusive
> Umbruch löschen, wenn sie ohne Präfixargument aufgerufen wird, und die
> ganze Zeile ohne Umbruch mit Präfixargument. In letzerem Fall würde
> sie sich ohne Präfixargument so verhalten, wie es der Nutzer aufgrund
> seiner Einstellung von `kill-whole-line' auch von `kill-line' erwarten
> würde. Wird die Funktion mit Präfixargument aufgerufen, würde das
> jeweils andere Verhalten aktiviert.


Einverstanden. Mir hat bislang C-a C-k keine Mühe gemacht. Die benötigte Zeit, eine
Vielzahl von Funktionsaufrufen zu lernen, ist auch nicht zu unterschätzen. Aber der Wunsch
des Kunden... Wollte bei der Gelegenheit ein wenig das 1 x 1 ueben; wie Du siehst, ist
das auch nötig.

> Was meinst du mit "fehlerhaften Anweisungen"?


Bedienerirrtümer, nicht überschaute Funktionen, überraschende Resultate

>> und Bugs - die erwartet werden -

> Also ich persönlich erwarte keine Bugs, wenn ich ein Programm starte.
> Das hört sich bei dir an, als ob alle Nase lang ein Fehler auftreten
> würde.


Dann ein Beispiel für oben erwähnte Ungewißheit
(habs daher nicht als Bug gemeldet):

buffer-file-coding-system - mule-utf-8-unix
im Textmodus unter
GNU Emacs 21.4.1 (i686-pc-linux-gnu, X

Beim Öffnen einer Datei, die mit der Vorgängerversion erstellt wurde,
erhalte ich ein `\344' anstelle des `ä' usw.

Ich schließ aus dem Ergebnis, daß die iso-latin-1 Zeichen als solche
erkannt, aber nicht dargestellt werden. Bug oder Einstellungsfehler?

> Hm, ich selbst habe noch nie ein Emacs-Buch in der Hand gehabt und es
> bisher auch nicht vermisst.


Dann hast Du wahrscheinlich systematisch eine
Programmiersprache erlernt, bevor Emacs kam oder bist halt genial von Geburt.
(tippe auf letzteres)

>> Schlage vor, so etwas zum Bestandteil der Standardedition zu machen.

> Dafür gibt es das Handbuch. Und es erfordert mehr als genug Aufwand,
> das aktuell in Bezug auf den Funktionsumfang von Emacs zu halten. Die
> Durchsicht der Dokumentation ist beispielsweise einer der Punkte, die
> den Release von Emacs 22 aufhalten.


An dieser Stelle wiederum würde ich plädieren, einen Vermerk zu
machen, aufs elisp-info, die Möglichkeit der Lektüre der Programme
zu verweisen und das Ding als Version rauszugeben. Es ist ja jeder
frei, sich eine ältere Version mit übereinstimmender
Doku zu laden. Wäre die Frage, wie schwerwiegend die Änderungen sind
und was eine veraltete Doku schaden könnte.

So weit, bis demnächst

Dank noch mal

ar
Ralf Angeli (08.12.2005, 20:51)
* Andreas Röhler (2005-12-08) writes:

> Ralf Angeli wrote:
> Dann ein Beispiel für oben erwähnte Ungewißheit
> (habs daher nicht als Bug gemeldet):
> buffer-file-coding-system - mule-utf-8-unix
> im Textmodus unter
> GNU Emacs 21.4.1 (i686-pc-linux-gnu, X
> Beim Öffnen einer Datei, die mit der Vorgängerversion erstellt wurde,
> erhalte ich ein `4' anstelle des `ä' usw.


Du verwendest vermutlich eine UTF8-Locale. Ich habe hier weder die
noch einen Emacs 21, um zu testen, was das Problem sein könnte.
Verwendest du zufällig `standard-display-european'? Sind in der Datei
tatsächlich nur Latin-1-Zeichen?

> Ich schließ aus dem Ergebnis, daß die iso-latin-1 Zeichen als solche
> erkannt, aber nicht dargestellt werden. Bug oder Einstellungsfehler?


Einstellungsfehler kann man meist relativ einfach identifizieren,
indem man Emacs dazu veranlasst, beim Starten alle Benutzer- und
Site-Einstellungen zu ignorieren: emacs -q -no-site-file
Wenn es damit klappt, liegt es an den Einstellungen.

>> Hm, ich selbst habe noch nie ein Emacs-Buch in der Hand gehabt und es
>> bisher auch nicht vermisst.

> Dann hast Du wahrscheinlich systematisch eine
> Programmiersprache erlernt, bevor Emacs kam oder bist halt genial von Geburt.
> (tippe auf letzteres)


Quatsch. Blut und Schweiß. Und mir geht bei der Programmierung auch
noch mehr daneben, als mir lieb ist.

> An dieser Stelle wiederum würde ich plädieren, einen Vermerk zu
> machen, aufs elisp-info, die Möglichkeit der Lektüre der Programme
> zu verweisen und das Ding als Version rauszugeben.


Dafür ist die Dokumentation zu wichtig.

> Es ist ja jeder frei, sich eine ältere Version mit übereinstimmender
> Doku zu laden. Wäre die Frage, wie schwerwiegend die Änderungen sind
> und was eine veraltete Doku schaden könnte.


Das gäbe ein Chaos ...

Ähnliche Themen