Ich habe ein Projekt, das fehlerfrei compiliert wird mit GCC bei Aufruf "Make all" im Commandfenster. So weit so gut. Das AVR-Studio macht sich das Makefile ja selber. Also habe ich nur die C-Dateien und die Includes in das Studio kopiert und dann Rebuild All geklickt. Einige Dateien compiliert das Studio durch Aufruf von avr-gcc einwandfrei. Bis zu diesem Fehler. ../main.c:1087: error: 'UCSRA' undeclared (first use in this function) In den Datei main.c stehen jedoch diese Includes drin: #include <stdint.h> #include <avr/io.h> #include <avr/interrupt.h> #include <avr/pgmspace.h> #include <avr/sleep.h> #include <avr/wdt.h> #include <avr/version.h> Warum gibts dann den Fehler, wenn der GCC doch im Commandfenster aufgerufen fehlerfrei arbeitet. Was ist im Studio anders? In der path-Variable steht der Pfad auf das WinAVR- Verzeichnis drin mit \bin und \utils\bin. Einen direkten Link auf C:\WinAVR-20100110\avr\include sehe ich nicht. Offenbar kommt "Make all" im CMD-Fenster damit trotzdem klar. Warum klemmt es beim Studio. Was kann/muss ich da tun? Matthias
Klaus Wachtler schrieb: > Falschen Controller ausgewählt? > Nicht alle AVR haben die gleichen Register. Im Studio habe ich fürs Debugging den 169 eingestellt. Beim Aufruf des GCC wird mit -mmcu=ATmega169P gearbeitet. Daran liegt es also wohl nicht. Matthias
Matthias W. schrieb: > Im Studio habe ich fürs Debugging den 169 eingestellt. > Beim Aufruf des GCC wird mit -mmcu=ATmega169P gearbeitet. > Daran liegt es also wohl nicht. ATmega169 != ATmega169P. Bei ersterem gibt es UCSRA, bei zweiterem heisst es UCSR0A. Andreas
Außerdem: welchen Controller du für das Debuggen eingestellt hast, interessiert beim Compilieren nicht die Bohne. Und da du einen Fehler beim Compilieren bekommst, wäre es natürlich sinnvoll, den dort eingestellten Controller zu kontrollieren.
Andreas Ferber schrieb: > ATmega169 != ATmega169P. Bei ersterem gibt es UCSRA, bei zweiterem > heisst es UCSR0A. Danke für den Hinweis Andreas. Auf dem chip selbst steht mega169V kein P. Der Aufruf des GCC im Cmd-Fenster mit Make all ruft in der Tat den ATmega169 auf, während das Studio laut den Zeilen definitiv den mega169P aufgerufen hat. Das habe ich nun geändert. Die Probleme sind erst verschwunden als ich 4 C-Dateien entfernt habe, die ich ins Studio einkopiert hatte und somit auch dort übersetzt wurden. Das Makefile hatte diese jedoch ausgelassen. Über solche Feinheiten kann man also auch stolpern. Das Problem was jetzt noch drückt ist die Codegröße. Der normale Code des 169 ist laut Makefile so groß: main.elf : section size addr .data 56 8388864 .text 13278 0 .bss 357 8388920 .debug_aranges 544 0 .debug_pubnames 4381 0 .debug_info 16600 0 .debug_abbrev 4941 0 .debug_line 16903 0 .debug_frame 2736 0 .debug_str 4257 0 .debug_loc 9646 0 .debug_ranges 96 0 Total 73795 Das Studio meldet: AVR Memory Usage ---------------- Device: atmega169 Program: 13216 bytes (80.7% Full) (.text + .data + .bootloader) Data: 227 bytes (22.2% Full) (.data + .bss + .noinit) Build succeeded with 0 Warnings... Der Code des Datenloggers hat laut Studio: AVR Memory Usage ---------------- Device: atmega169 Program: 18584 bytes (113.4% Full) (.text + .data + .bootloader) Data: 694 bytes (67.8% Full) (.data + .bss + .noinit) Build succeeded with 1 Warnings... Wie soll das denn reinpassen mit 113% full? Matthias
Stefan Ernst schrieb: > Außerdem: welchen Controller du für das Debuggen eingestellt hast, > interessiert beim Compilieren nicht die Bohne. Und da du einen Fehler > beim Compilieren bekommst, wäre es natürlich sinnvoll, den dort > eingestellten Controller zu kontrollieren. Beim Studio habe ich nur die c- und h-Dateien einkopiert und dabei ja gar keine CPU angegeben. Beim Erstellen der Projektdatei fragt das Studio ja nach einer CPU. Wo überall stellt man die CPU im Studio denn ein? Bei Project configuration options habe ich die CPU geändert. Matthias
wieso klappt das mit dem einfachen Makefile und bisher gar nicht mit dem Studio (zu groß)? Matthias
Entweder hast du im Studio mehr Dateien, oder andere Optionen beim Kompilieren oder andere Libs beim Linken (Gleitkommaversionen?).
Klaus Wachtler schrieb: > Entweder hast du im Studio mehr Dateien, oder andere Optionen beim > Kompilieren oder andere Libs beim Linken (Gleitkommaversionen?). Da hast Du wohl recht. Da es an den Dateien nun sicher nicht mehr liegt können es nur die libs sein. Leider kenne ich die Möglichkeiten des Studios nicht so gut um da bewusst geschickt eingreifen zu können. Es sieht so aus als ob das Makefile außerhalb des Studios, das ja den kleineren Code erzeugt ein -lm verwendet. Dies ist beim Studio nicht der Fall. Darauf muss man wohl achten, wenn man weiß wie man es sinnvollerweise tut. Leider kenne ich mich damit bisher nicht aus. So einfach ist das mit dem Studio eben auch nicht. Matthias
Matthias W. schrieb: > damit bisher nicht aus. So einfach ist das mit dem > Studio eben auch nicht. Ganz im Gegenteil Alle Möglichkeiten finden sich im Studio zusammengefasst im Menüpunkt "Project" / "Configuration Options" Dort wird im Grunde alles eingestellt, was das implizite Makefile (und nich einiges mehr) beeinflusst. Dort gibt es dann in der linken Leiste den Punkt 'Libraries' und unter 'Available Link Objects' die libm.a Mit seinem Werkzeug muss man sich eben ein wenig beschäftigen, wenn man es sinnvoll einsetzen will. Und das AVR Studio ist dein Werkzeug
Karl heinz Buchegger schrieb: > Alle Möglichkeiten finden sich im Studio zusammengefasst im > Menüpunkt "Project" / "Configuration Options" danke für den Hinweis. In dem Menü war ich schon ein paar Mal. > Dort wird im Grunde alles eingestellt, was das implizite Makefile (und > nich einiges mehr) beeinflusst. muss da auch im Fenster der Takt angegeben werden? In der main.h steht ja #define F_CPU 4000000 Das wäre ja dann doppelt angegeben. > Dort gibt es dann in der linken Leiste den Punkt 'Libraries' und unter > 'Available Link Objects' die libm.a Die libm.a mit Add Library nach rechts schieben? > Mit seinem Werkzeug muss man sich eben ein wenig beschäftigen, wenn man > es sinnvoll einsetzen will. Und das AVR Studio ist dein Werkzeug ich arbeite mich ein. Das dauert seine Zeit, weil vieles für mich Neuland ist. Hinweise und Tutorials sind hilfreich ! Matthias
Du kannst übrigens auch dein eigenes Makefile verwenden lassen, dann bist du den Kuddelmuddel los.
Jörg Wunsch schrieb: > Du kannst übrigens auch dein eigenes Makefile verwenden lassen, dann > bist du den Kuddelmuddel los. Danke für den Hinweis Jörg. Das wird momentan das Beste sein, denn es gelingt mir zwar nun mit dem Studio etwas zu erzeugen was angeblich reinpasst (ca. 97% voll). Beim Flashen über den Bootloader meldet dann jedoch der Verify einen Fehler. Das mit "Make all" außerhalb des Studios generierte hex-file arbeitet hingegen einwandfrei. Meine Anstrengungen sind bisher gescheitert das was das externe Makefile macht im Studio auch hinzubekommen. Schade - es war ein Versuch das auch im Studio zum Laufen zu bringen. Matthias
Matthias W. schrieb: > (ca. 97% voll). Beim Flashen über den > Bootloader meldet dann jedoch der Verify einen Fehler. Klar, das avr-size-Kommando, das die 97 % vermeldet, hat natürlich keine Ahnung, dass du auch noch Platz für einen Bootloader brauchst. > Schade - es war ein Versuch das auch im Studio zum Laufen > zu bringen. Darüber musst du wohl nicht traurig sein. ;-) Die AVR-Studio- Variante ist nur ein simpler Ersatz für Standardanwendungen, der für Leute sinnvoll ist, die nicht selbst ein Makefile schreiben können oder wollen. Trifft für dich also nicht zu. :)
Jörg Wunsch schrieb: > Klar, das avr-size-Kommando, das die 97 % vermeldet, hat natürlich > keine Ahnung, dass du auch noch Platz für einen Bootloader brauchst. da bin ich mir nicht so sicher Jörg. Denn die Ausgabe beim Studio sagt ja: (.text + .data + .bootloader). Da scheint also die Größe des Bootloaders durchaus berücksichtigt. > Darüber musst du wohl nicht traurig sein. ;-) Ich dachte nicht, daß dies so stressig sein könnte. Das Studio ist zwar überaus wertvoll, was den Simulator und Debugger angeht und die Programmierung über den Bootloader. Die Suchmöglichkeiten des Editors empfinde ich als stark suboptimal. Da nehme ich lieber den uralten Ultraedit und dazu das Make im DOS-Fenster. Das läuft wenigstens ohne Mucken, so wie vor Jahren schon. > für Leute sinnvoll, die nicht selbst ein Makefile schreiben > können oder wollen. Trifft für dich also nicht zu. :) So sehr fit bin ich leider nicht im Schreiben von Makefiles. Mein Wissen darum reicht gerade mal soweit, daß ich das Muster-Make anpassen kann, wenn eine Datei wegfällt oder eine neue hinzukommt. Die Sprache des Make sieht nicht einfach aus. Auch Leerzeichen statt Tabs kann unerwartet stressen. Matthias
Matthias W. schrieb: > Da scheint > also die Größe des Bootloaders durchaus berücksichtigt. War aber nirgends eine section mit dem Namen .bootloader zu sehen. Würde außerdem nur funktionieren, wenn du den Bootlader mit dem Projekt mit linkst und dann alles zusammen flashst. So, wie ich dich verstanden habe, war der Bootlader aber schon da und gehört(e) nicht zum Projekt. > Die Suchmöglichkeiten > des Editors empfinde ich als stark suboptimal. Ich finde all diese IDEs ohnehin stark suboptimal, schon deshalb, weil man diese mit dem "Fenster im Fenster" nur mit Bildschirmen ab 1 m² Bildschirmfläche aufwärts benutzen kann ;-), aber ich muss ja zum Glück auch nicht mit sowas arbeiten. Ohne Emacs oder zur Not vi möchte ich auf Dauer auch nicht arbeiten müssen... > Auch Leerzeichen statt Tabs kann unerwartet stressen. Ja, das war wohl eine der größten Fehlentscheidungen von "make". Ist nun mal leider so und nicht mehr zu ändern. Hat ja Python auch nicht davon abgehalten, dann 30 Jahre später nochmal eine Sprache zu erfinden, in der Leerzeichen (bzw. TABs) syntaktische Signifikanz besitzen. :-/
Matthias W. schrieb: > Jörg Wunsch schrieb: >> Klar, das avr-size-Kommando, das die 97 % vermeldet, hat natürlich >> keine Ahnung, dass du auch noch Platz für einen Bootloader brauchst. > > da bin ich mir nicht so sicher Jörg. > Denn die Ausgabe beim Studio sagt ja: > (.text + .data + .bootloader). Da scheint > also die Größe des Bootloaders durchaus berücksichtigt. Überlegen, Nachdenken Woher soll denn AVR Studio wissen, dass du einen Bootloader auf dem Chip hast und ich nicht. Was bei dir also als 105% Flash Verbrauch angezeigt werden sollte (deiner Meinung nach), sind bei mir daher nur 94% > So sehr fit bin ich leider nicht im Schreiben > von Makefiles. Um dir rauszusuchen, welche Compiler Optionen eingschaltet sind, wirds ja doch noch reichen.
Karl heinz Buchegger schrieb: >> die Ausgabe beim Studio sagt ja: >> (.text + .data + .bootloader) > Woher soll denn AVR Studio wissen, dass du einen Bootloader auf dem Chip > hast und ich nicht. gute Frage. Ich habe das Studio nicht geschrieben. Da ich ein paar Mal über den Bootloader programmiert habe könnte das Studio das schon wissen. Vermutlich wird es nicht so sein, weil ja der Build auch ohne das Aktivieren des Bootloaders diese Meldung wohl erzeugen wird. In jedem Fall verwirrt mich diese Meldung. Das Make außerhalb des Studios gibt das so in dieser Art (.text + .data + .bootloader) nicht an. Mich hat diese Ausgabe eher verwirrt als Nutzen gebracht. > Was bei dir also als 105% Flash Verbrauch angezeigt werden sollte > (deiner Meinung nach), sind bei mir daher nur 94% Dieser Satz klingt für mich falsch. Denn bei mir wird 97.9% full angezeigt, bei Dir wären das dann 10% weniger also rund 87% und die müssten doch sicher reinpassen. Fakt ist, daß das "Makefile" außerhalb des Studios ca 13kB produziert mit dem GCC. Dieses hex läuft ! Das "Make" des Studios produziert angeblich 16036byte (.text + .data + .bootloader) 97.9% full. Für mich klang das so: passt rein - alles prima. Daß man da was erkennen kann an einer nicht vorhandenen Section mit dem Namen .bootloader - sorry, das habe ich nicht gesehen. Mein Dank geht hier an Jörg, der darauf aufmerksam gemacht hat. Also müsste dem Studio noch mitgeteilt werden, daß es einen Bootloader gibt? Wo stelle ich das ein? > Um dir rauszusuchen, welche Compiler Optionen eingschaltet sind, wirds > ja doch noch reichen. Bitte klarer. Welchen konkreten Hinweis willst Du hier geben. Soll ich die Compilerschalter alle mal vergleichen? Bei Studio und Makefile? Ist es das was Du sagen möchtest? Matthias
Matthias W. schrieb: > Fakt ist, daß das "Makefile" außerhalb des Studios > ca 13kB produziert mit dem GCC. Dieses hex läuft ! Die Größe des HEX-Files ist nur eingeschränmkt als Mass zu gebrauchen. > Das "Make" des Studios produziert angeblich 16036byte > (.text + .data + .bootloader) 97.9% full. > > Für mich klang das so: passt rein - alles prima. Aber nur dann, wenn du keinen Bootloader im Chip hast > Also müsste dem Studio noch mitgeteilt werden, daß es > einen Bootloader gibt? Wo stelle ich das ein? Nirgends. Das musst du schon selber wissen, welchen Bootloader du in den Chip gebrannt hast, wieviel Platz der im µC belegt und wieviel du daher vom Gesamtspeicher abziehen musst. >> Um dir rauszusuchen, welche Compiler Optionen eingschaltet sind, wirds >> ja doch noch reichen. > > Bitte klarer. Welchen konkreten Hinweis willst Du > hier geben. Soll ich die Compilerschalter alle mal > vergleichen? Bei Studio und Makefile? Ist es das was > Du sagen möchtest? Genau das möchte ich damit sagen. Im Makefile sieht man sich an, welche Compiler Optionen eingeschaltet sind und im AVR-Studio sieht man sich einfach mal im Output Fenster an, mit welchen Compiler Optionen der gcc dort aufgerufen wird. Dann vergleicht man, stellt fest welche Unterschiede es gibt, liest nach was es mit diesen Optionen beim gcc auf sich hat, entscheidet ob man die beibehalten will (bzw. ob man sich davon etwas verspricht) und sucht sich dann im AVR Studio einen Weg diese Option dort ebenfalls einzustellen. Wenn alle Stricke reissen, gibt es im AVR Studio immer noch den Weg, die Compiler-Optionen auch dort direkt einzugeben.
Jörg Wunsch schrieb: > War aber nirgends eine section mit dem Namen .bootloader zu > sehen. Danke für den wertvollen Hinweis. Stimmt, da steht nicht von einem Bootloader. Der Bootloader wurde ja von Atmel draufgemacht. Das Projekt selbst löscht den Bootloader nicht und macht auch keinen eigenen drauf. > Würde außerdem nur funktionieren, wenn du den Bootlader > mit dem Projekt mit linkst und dann alles zusammen flashst. Dann müsste die Größenberechnung auch stimmen. Heute wird die Auslastung zu klein angegeben, weil der Bootloader ja noch da ist. Vermutlich versucht das Tool den zu überschreiben - daher der Fehler mit dem Verify, der nicht klappt? > So, wie ich dich verstanden habe, war der Bootlader aber schon da > und gehört(e) nicht zum Projekt. Ja. > Ich finde all diese IDEs ohnehin stark suboptimal, schon deshalb, > weil man diese mit dem "Fenster im Fenster" nur mit Bildschirmen > ab 1 m² Bildschirmfläche aufwärts benutzen kann ;-), mit einem Laptop mit 1680x1050pixel geht es schon. Das ist ok. Die vielen möglichen Fehlerquellen da und dort in einem Menü stören mich bisher viel mehr. > Ohne Emacs oder zur > Not vi möchte ich auf Dauer auch nicht arbeiten müssen... das verstehe ich. >> Auch Leerzeichen statt Tabs kann unerwartet stressen. > Ja, das war wohl eine der größten Fehlentscheidungen von "make". Ist > nun mal leider so und nicht mehr zu ändern. schade. > Hat ja Python auch nicht > davon abgehalten, dann 30 Jahre später nochmal eine Sprache zu > erfinden, in der Leerzeichen (bzw. TABs) syntaktische Signifikanz > besitzen. :-/ Es ist ziemlich ärgerlich wenn man beim Editor die Tabs alle durch Leerzeichen ersetzen lässt und dann plötzlich nichts mehr korrekt durchläuft. Wer rechnet schon mit sowas . . . Matthias
Karl heinz Buchegger schrieb:
Danke für die Hinweise Karl Heinz !
Den Bootloader hat Atmel drauf gemacht, nicht ich.
Ich hörte daß er um die 2kB haben soll.
Matthias
Matthias W. schrieb: > Der Bootloader wurde ja von Atmel draufgemacht. Das alles weiß dein AVR Studio aber nicht. Die Angabe der Auslastung stammt von einem avr-size-Kommando, und das geht einfach stur von der Flash-Größe des jeweiligen Prozessors aus. Selbst die Kenntnis, dass es einen Bootloader gibt, würde ihm ja nichts nützen, denn in den meisten AVRs kann man für diesen vier verschiedene Größen einstellen. Das Resultat vom AVR-Studio-Compilat war vermutlich einfach mal deshalb zu groß, weil sie standardmäßig ohne Optimierung compilieren. Optimierten Code zu debuggen, ist mit AVR Studio ein ziemlicher Graus -- mit GDB nur deshalb marginal besser, weil er beliebige C-Ausdrücke zur Laufzeit berechnen kann, sodass man bspw. auch zwei aufeinanderfolgende Register zu einem Zeiger eines bestimmten Typs umbiegen kann, der auf eine Struktur zeigt, dessen x-tes Element man dann haben will usw. usf. Kurz gesagt, viele Leute kriegen's nicht auf die Reihe, sich wirklich durch den optimierten Code zu hangeln und debuggen stattdessen den nichtoptimierten Code. Viele der "Kasperfallen" der Sprache C kommen aber erst durch die Optimierung rein (bspw. alles, was sich um "volatile" herum rankt), sodass man mit dieser Methode letztlich zweimal debuggt.
Jörg Wunsch schrieb: > Das alles weiß dein AVR Studio aber nicht. sieht so aus. > Die Angabe der Auslastung stammt von einem avr-size-Kommando, > und das geht einfach stur von der Flash-Größe des jeweiligen > Prozessors aus. das ist mir nun klar. Verwirrt hatte mich diese Zeile mit der Summe incl. Bootloader. Da dachte ich ernsthaft, daß das die Software so ausgerechnet hat. Mich hat diese Zeile wirklich in Sicherheit gewiegt. > Das Resultat vom AVR-Studio-Compilat war vermutlich einfach mal > deshalb zu groß, weil sie standardmäßig ohne Optimierung > compilieren. Als De-Optimierbefehl steht im Studio -Os drin. disables the following optimization flags: -falign-functions -falign-jumps -falign-loops -falign-labels -freorder-blocks -freorder-blocks-and-partition -fprefetch-loop-arrays -ftree-vect-loop-version > Optimierten Code zu debuggen, ist mit AVR Studio ein > ziemlicher Graus vielen Dank für den Einblick. Ist ja klar, daß es da schwerer wird mit dem Debuggen, wenn Teile gar nicht mehr da sind. > Kurz gesagt, viele Leute kriegen's nicht auf die Reihe, sich wirklich > durch den optimierten Code zu hangeln und debuggen stattdessen den > nichtoptimierten Code. verständlich. > Viele der "Kasperfallen" der Sprache C kommen > aber erst durch die Optimierung rein (bspw. alles, was sich um > "volatile" herum rankt), sodass man mit dieser Methode letztlich > zweimal debuggt. das klingt nicht so optimal. Wenn Optimierung auf solche Weise dann zu Ausfällen von Sicherheitssystemen führt ist es weniger komisch. Matthias
Angehängte Dateien:
-
bunteleerzeichen.png
8,8 KB
Jörg Wunsch schrieb: >> Auch Leerzeichen statt Tabs kann unerwartet stressen. > > Ja, das war wohl eine der größten Fehlentscheidungen von "make". Ist > nun mal leider so und nicht mehr zu ändern. alles eine Frage des richtigen Editors :-) Mit etwas Glück sehen Leerzeichen anders aus als Tabs, und wenn white space nach dem letzten sichtbaren Zeichen einer Zeile eine andere Farbe hat, spart man sich auch viel Fehlersucherei in C bei einem Makro mit Fortsetzungszeilen.
Welcher Mode ist das, wenn man fragen darf? (show-trailing-whitespace habe ich schon lange aktiv.)
Klaus Wachtler schrieb: > alles eine Frage des richtigen Editors :-) Danke für den wertvollen Beitrag Klaus. Matthias
Jörg Wunsch schrieb: > Welcher Mode ist das, wenn man fragen darf? (show-trailing-whitespace > habe ich schon lange aktiv.) In meiner .emacs steht dazu (offenbar auch nur geklaut, von einem der es geklaut hat):
1 | (custom-set-faces |
2 | ;; custom-set-faces was added by Custom. |
3 | ;; If you edit it by hand, you could mess it up, so be careful. |
4 | ;; Your init file should contain only one such instance. |
5 | ;; If there is more than one, they won't work right. |
6 | '(my-tab-face ((((class color)) (:background "Khaki"))) t) |
7 | '(my-trailing-space-face ((((class color)) (:background "Gold"))) t)) |
8 | |
9 | ;;; Editor behavior: color tabs |
10 | |
11 | (add-hook 'font-lock-mode-hook |
12 | (function |
13 | (lambda () |
14 | (setq font-lock-keywords |
15 | (append font-lock-keywords |
16 | '(("\t+" (0 'my-tab-face t))
|
17 | ("[ \t]+$" (0 'my-trailing-space-face t))))))))
|
18 | |
19 | |
20 | |
21 | ;;; From: Tom Schutter <t.schutter@att.net> |
22 | ;;; To: Jason Diamond <jason@injektilo.org> |
23 | ;;; Cc: help-emacs-windows@gnu.org |
24 | ;;; Subject: Re: [h-e-w] View Whitespace |
25 | ;;; |
26 | ;;; Jason Diamond wrote: |
27 | ;;; > |
28 | ;;; > Hi. |
29 | ;;; > |
30 | ;;; > Is there a Lisp function that toggles whether or not whitespace (horizontal |
31 | ;;; > tabs, line feeds, carriage returns, and spaces) are "visible"? |
32 | ;;; > |
33 | ;;; > Thanks, |
34 | ;;; > Jason. |
35 | ;;; |
36 | ;;; I don't know where I got this from, but it does tabs and trailing |
37 | ;;; spaces. |
38 | ;;; |
39 | ;;; ;;; Editor behavior: color tabs |
40 | ;;; (custom-set-faces |
41 | ;;; '(my-tab-face ((((class color)) (:background "Khaki"))) t) |
42 | ;;; '(my-trailing-space-face ((((class color)) (:background "Gold"))) t)) |
43 | ;;; (add-hook 'font-lock-mode-hook |
44 | ;;; (function |
45 | ;;; (lambda () |
46 | ;;; (setq font-lock-keywords |
47 | ;;; (append font-lock-keywords |
48 | ;;; '(("\t+" (0 'my-tab-face t))
|
49 | ;;; ("[ \t]+$" (0 'my-trailing-space-face
|
50 | ;;; t)))))))) |
51 | ;;; |
52 | ;;; -- |
53 | ;;; Tom Schutter |
54 | ;;; t.schutter@att.net |
55 | ;;; |
Matthias W. schrieb: > Danke für den wertvollen Beitrag Klaus. Biite! Freut mich, wenn es dir hilft. :-)
Klaus Wachtler schrieb: > Biite! Freut mich, wenn es dir hilft. :-) Wie Du siehst hilfts auch anderen. So haben mehr was davon. Das ist ja der Sinn solcher Threads ! Matthias
Jörg Wunsch schrieb: > Danke, jetzt hab' ich's auch geklaut. ;-) Ich habe für sowas einen neuen Thread angeworfen in der Codesammlung: Beitrag "EMACS: Konfiguration und Spielereien"
Matthias W. schrieb: > Klaus Wachtler schrieb: >> alles eine Frage des richtigen Editors :-) > > Danke für den wertvollen Beitrag Klaus. > > Matthias Damit bin ich irgendwie noch überfordert (kann auch daran liegen, daß ich heute einen dicken Kopf habe). Was es dir zu off topic? Ohne Ironie ernst gemeint war es wohl nicht? Zu inhaltslos? Zumindest heute fällt es mir schwer, zwischen den Zeilen zu lesen (zumal, wenn es nur eine ist). Wenn noch etwas offen ist, bitte klarer formulieren...
Klaus Wachtler schrieb: > Damit bin ich irgendwie noch überfordert (kann auch daran liegen, daß > ich heute einen dicken Kopf habe). komisch, wenn mal ein Lob kommt und man sich dann fragt, wie das denn sein kann? > Was es dir zu off topic? > Ohne Ironie ernst gemeint war es wohl nicht? > Zu inhaltslos? Nein. Wie kommst Du da drauf? Für mich war es eine wertvolle Info. Ohne wenn und aber. Matthias
oh, danke. Ich hatte es als sarkastische Äußerung interpretiert. Es ist wie gesagt nicht mein Tag heute. Nur gut, daß ich nicht gleich losgepoltert habe...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.