letzter Beitrag von Tale-X am
Nachtrag: Ja, man kann das für verschiedene Endungen separat konfiurieren. Aber Makefiles haben (leider) i. d. R. keine Endung. Da versagt die ansonsten gut gedachte Konfigurationsmöglichkeit.
Kannst du keine Konfiguration für Dateien mit dem Suffix "akefile" (ohne Punkt) vorgeben?
Lt. https://webcache.googleusercon…&cd=1&hl=de&ct=clnk&gl=de geht das nicht. Wie auch immer, ich habe an den Support eine Mail geschickt. Mal sehen, was die antworten. Da ich 'unlimited lifetime updates' habe, gerne auch mit eienr neuen Programmversion... Bei einen kommerziellen Editor spricht doch nichts dagegen, den Support, für den man ja indirekt mit der Lizenz bezahlt hat, auch in Anspruch zu nehmen.
Der Support hat mir gerade bestätigt, dass das derzeit nicht geht:
Zitat von UltraEdit SupportUnfortunately, there isn't currently a way to define custom tab settings for files that don't have an extension. I have added this to our issue tracking system as an enhancement to be considered for a future release [...]
Nun denn, das war gemäß dem obigen Internetlink zu befürchten. Mir ging es bei der Supportanfrage auch eher um den zweiten Teil aus der Antwort...
Aus Borland-C Zeiten kenne ich das noch, das ein Makefile den Projektnamen mit der Endung .mak trägt 
Aber das ist auch schon wieder 30+ Jahre her...
Wie jetzt, mit UltraEdit soll der Programmierer-Editor schlechthin Schwächen bei der Bearbeitung von Makefiles haben? Ich kann mir kaum vorstellen, dass das nicht bedacht worden sein soll. Hast Du dem Support mal explizit erklärt, was Du tun willst?
Ich kenne UltraEdit nicht, weil ich mit jEdit glücklich bin. Aber ich dachte immer, dass UltraEdit das Nonplusultra wäre (kostet ja auch was).
Aber ich dachte immer, dass UltraEdit das Nonplusultra wäre.
Nee, dann muesste er doch NonplusultraEdit heissen 
Wie jetzt, mit UltraEdit soll der Programmierer-Editor schlechthin Schwächen bei der Bearbeitung von Makefiles haben? Ich kann mir kaum vorstellen, dass das nicht bedacht worden sein soll. Hast Du dem Support mal explizit erklärt, was Du tun willst?
Eigentlich schon: "I'd like to configure different 'Tab settings' for Makefiles in UltraEdit. For all files I'd like to use spaces in place of tabs. But for Makefiles I cannot do that for the obvious reason."
ist ja wohl eindeutig genug... außerdem haben wir ja noch die Quelle, die ich oben verlinkt habe, die das Selbe wie der Support sagt... Bleiben die Tabs halt drinnen, bis Ultraedit an der Stelle besser geworden ist.
Es sei denn, der Support kennt keine 'Makefiles'. In dem Fall wäre er aber beim falschen ARbeitgeber, wo die doch neben UltraEit auch noch UE Studio verkaufen, was sich explizit an Programmierer richtet.
PS: Wie in dem geposteten Link oben beschrieben: Natürlich kann man das Tab-nehmen-Verhalten als Default machen und alle interessanten Endungen einzeln aufgeführt als Spaces-nehmen-Verhalten dann konfigurieren.Das sollte such funktionieren. Nur, will man das?!
PS: Wie in dem geposteten Link oben beschrieben: Natürlich kann man das Tab-nehmen-Verhalten als Default machen und alle interessanten Endungen einzeln aufgeführt als Spaces-nehmen-Verhalten dann konfigurieren.Das sollte such funktionieren. Nur, will man das?!
Ah ok, das ist natürlich immerhin eine Lösung. Den Link hab ich nicht gelesen.
Das nervigste an Python ist die Tatsache, daß die Einrückung Teil der Syntax ist. Der, der diese Idee hatte macht sich wahrscheinlich auch die Hose mit der Kneifzange zu.
Ich hoffe, ich habe das missverstanden: Wenn ich falsch einrücke, führt das zu Syntax-Fehlern? 
Das wäre ja ein Rückfall in Vor-Basic-Zeiten.
Aber das kann eigentlich nicht sein, den Phyton ist doch eine moderne und unter Linux vielgenutze Sprache!? 
Die Grundlagen von Python hatte ich mit diesem Online-Kurs gelernt; den kann ich empfehlen:
Ich hoffe, ich habe das missverstanden: Wenn ich falsch einrücke, führt das zu Syntax-Fehlern?
Aber das kann eigentlich nicht sein, den Phyton ist doch eine moderne und unter Linux vielgenutze Sprache!?
Das ist schon richtig so. Die Einrueckung ist ein zentraler Bestandteil der Python-Syntax.
Anstelle von sowas, was in vielen BASIC-Dialekten gemacht wuerde...
...oder dem gleichen in Sprachen mit C-artiger Syntax...
...wuerde das in Python so aussehen:
Die Einrueckung gibt also die Verschachtelungs-/Block-Tiefe vor. Dafuer gibt es aber kein "END IF" oder keine geschweiften Klammern. Das ist einfach ein Syntax-Element der Sprache und hat nix mit "Vor-BASIC-Zeit" oder sonst was zu tun. Nebenbei sorgt es dafuer, dass jeder Programmierer seinen Code sauber einrueckt, was meiner Meinung nach eigentlich jeder Programmierer machen sollte, ganz egal, ob die Sprache das erzwingt oder nicht. Natuerlich koennte man das C-Beispiel z.B. ja auch so schreiben wie im folgenden Beispiel, aber warum sollte man das tun? Und gerade auch Anfaenger sollte man gar nicht erst an so etwas gewoehnen lassen:
Nebenbei sorgt es dafuer, dass jeder Programmierer seinen Code sauber einrueckt, was meiner Meinung nach eigentlich jeder Programmierer machen sollte, ganz egal, ob die Sprache das erzwingt oder nicht.
Das mit der Zwangseinrückung mag ja für ehemalige Basic-Programmierer und Programmier-Einsteiger ganz hilfreich sein, aber warum eine Sprache geübten C++ und C# Programmierern vorschreibt, wie sie ihren Quelltext zu formatieren haben, erschließt sich mir nicht. Ich wusste nicht, dass Phyton primär für Programmieranfänger gedacht ist.
Bekomme ich dann auch noch vorgeschrieben, ob ich Tabs oder Blanks zu verwenden habe? Und wenn Blanks: wieviele pro Ebene? Was sind überhaupt erlaubte Newline- und Indent-Characters? Das muss dann ja alles in der Syntax-Definition festgelegt sein.
Vermischung von Syntax und Formatierung - alles längst überwunden geglaubte Konzepte.
Was mache ich jetzt mit den beiden Raspis, die ich hier für meine Home-Automation einsetzen wollte? Die werden ich wohl gegen Arduinos tauschen - die lassen sich in ordentlichem C++ programmieren.
1. Python ist nicht nur für Anfänger
2. Rasperry Pi ist nicht nur für Python
3. "ordentliches C++"...
Ich habe inzwischen noch mal ein wenig gegoogelt, weil mir diese Phyton-Eigenart wirklich neu war: in vielen Foren tobt tatsächlich ein Glaubenskrieg zwischen Phyton-Anhängern, die von {}-Gefrickel schreiben und C++/C#-Anhängern, die mit der Vermischung von Syntax und Formatierung nichts anfangen können.
Konkretes Problem: Ich kopiere mir sehr oft Code-Schnipsel von Internetseiten. Dabei geht in der Regel die gesamte Formatierung verloren. Bei den gängigen C# und C++ Editoren bekomme ich den Code auf Knopdruck wieder ordentlich formatiert (nach meinen Vorgaben) und der Compiler hat sowieso keinen Stress, weil er sich um die Formatierung nicht kümmert.
Was mache ich in Phyton, wenn die Formatierung durch Copy & Paste verloren geht?
Zum Thema Anfänger: Fast immer wird als Vorteil der Zwangsformatierung von Phyton die Disziplinierung von Programmieranfängern angeführt. Da es in C++ und C# das Problem offensichtlicht nicht gibt, ist es doch naheliegend anzunehmen, dass sich Phyton speziell an Programmeranfänger wendet. 
Wenn ich I/O-Programmierung auf dem Raspi mache und nicht Phyton verwende, werde ich wohl kaum irgendwo Unterstützung finden. Weil das praktrischer jeder in Phyton macht.
Das Problem hier ist aber, dass Du in diesem Fall Python auf diese eine Sache reduzierst, die lediglich eine einzige Eigenart darstellt, welche Dir jetzt natürlich besonders ins Auge fällt, am Ende aber vollkommen unbedeutend ist, wenn man Python einfach mal einsetzt und merkt, wie toll die Sprache an sich ist. Diese eine unbedeutende Eigenart lässt Dich nun aber denken, Python sei eine Einsteiger-Sprache.
Verstehst Du, wo hier der Trugschluss liegt? 
Es ist, wie ich schon weiter vorne schrieb, im Prinzip genauso, wie wenn Du ein Auto danach beurteilen würdest, wie man den Scheibenwischer einschaltet.
Andersrum betrachtet ist Python natürlich durchaus für Einsteiger geeignet. Aber die Aussage, es richte sich hauptsächlich an Einsteiger, ist einfach nicht richtig.
Der Punkt mit dem Copy/Paste mag richtig sein, aber wenn Du erstmal gemerkt hast, wie viel Tipparbeit Du Dir sparst, wenn Du Python mit all seinen Vorzügen und Genialitäten schätzen lernst, dann wirst Du sehen, dass das Markieren und drei mal auf Tab drücken, um den Code-Schnipsel in die korrekte Einrückung zu bringen, am Ende total vernachlässigbar ist.
Und was die Glaubenskriege angeht, das gibt es nunmal bei jeder Sprache in irgendeiner Form, aber in vielen Fällen (und besonders in diesem Fall) ist das ein kleinliches Herumgediskutiere um Dinge, die unterm Strich eigentlich total egal sind, aber von Leuten, die z.B. eine Abneigung gegenüber dieser Sprache haben, extra herausgepickt werden. Wenn ich z.B. Java nicht mag, dann verteufle ich z.B. die Eigenart, dass alles eine Klasse sein muss oder dass jede Klasse eine eigene Datei haben muss. Wenn ich Java liebe, stelle ich dies als besonderen Vorteil dar. Gleiches gilt für C++ und z.B. dessen Precompiler oder die Aufsplittung in Code- und Header-Files, etc. Am Ende liegen die wahren Unterschiede ganz woanders, und in der Nutzung macht man sich um sowas keine Gedanken mehr.
Fakt ist, in Python kriege ich oftmals etwas in ein paar hundert Zeilen hin, wofür ich in anderen Sprachen ein paar tausend benötigen würde (und auch deutlich mehr Zeit). Das ist der Grund, warum ich so gerne Python verwende (und bevor einer das falsch versteht, nein, es liegt nicht an der Art und Weise, ob Blöcke per Einrücken oder durch Klammern gebildet werden).
Das Problem hier ist aber, dass Du in diesem Fall Python auf diese eine Sache reduzierst, die lediglich eine einzige Eigenart darstellt, welche Dir jetzt natürlich besonders ins Auge fällt, am Ende aber vollkommen unbedeutend ist, wenn man Python einfach mal einsetzt und merkt, wie toll die Sprache an sich ist.
Genauso toll oder nicht toll, wie haufenweise andere moderne, multiparadigmatische Skriptsprachen. Python kann nichts, was andere nicht könnten. Und genau deshalb ist diese Einrückungsgeschichte ein guter Grund, die Sprache garnicht erst weiter in Betracht zu ziehen. Ansonsten gibt's da nicht viel, was mich jetzt vom Hocker reißt, nur weitere Seltsamkeiten (explicit self-argument, um nur einen weiteren Bock zu nennen). Andere Sprachen sind zumindest syntaktisch konsistent.
"Explicit is better than implicit" behauptet Python, allerdings weiß ich nicht, ob es etwas Impliziteres gibt, als die semantische Gruppierung von Anweisungen von Whitespace abhängig zu machen. Überall sonst (make vielleicht ausgenommen) ist whitespace beliebig und hat nur zur Trennung von Symbolen syntaktische, aber keine semantische Bedeutung. Überall sonst kann ich mir sicher sein, dass es egal ist, ob da jetzt ein Space oder zweihundert stehen, ob Tabs dazwischen sind oder sonstwas, Hauptsache 1..n whitespace characters.
Und eine Sprache, die sich ihre Design-Richtlinien so prominent auf die Fahnen schreibt, nur um diese gleich mit der ersten syntaktischen Regel ad absurdum zu führen, kann ich persönlich halt nichts weiter abgewinnen.
Es ist schon amüsant, wie sehr man auf so einem Detail herumhacken kann. Aber wenn das scheinbar das einzige Problem von Python zu sein scheint, dann kann die Sprache ja gar nicht so schlecht sein.
Ich kenne UltraEdit nicht, weil ich mit jEdit glücklich bin. Aber ich dachte immer, dass UltraEdit das Nonplusultra wäre (kostet ja auch was).
ansonsten kann man kostenlos als Source-Editor den Notepad++ testen.... den mag ich und der hat auch Syntax-Highlighting fuer diverse Programmiersprachen.....
Ich habe ihn meist mit PHP genutzt.
Notepad++
Leider Windows-Only, daher nehme ich jEdit, der finde ich genauso gut ist (allerdings etwas träger wegen Java, aber auf einem aktuellen Rechner merkt man davon nichts).
Es ist schon amüsant, wie sehr man auf so einem Detail herumhacken kann. Aber wenn das scheinbar das einzige Problem von Python zu sein scheint, dann kann die Sprache ja gar nicht so schlecht sein.
Falsch, ich gucke mir eine Sprache, die dieses "Detail" vermurkst, halt gar erst nicht weiter an. Da interessiert es mich auch nicht, ob sie ansonsten vielleicht ganz nett ist, denn Skriptsprachen git es wie Sand am Meer, alle können so ziemlich das gleiche, da darf man wählerisch sein. Und wenn man nicht mehr zu bieten hat, als andere, wird's halt schwierig...
Mich würde aber dennoch interessieren, wie "explicit is better than implicit" und diese Einrückerei zusammengehen. Da hilft auch kein Fehlschluss wie "wenn das das einzige ist, muss alles andere ja toll sein".
