XML bzw XAML syntax highligting?

EXDW

hi,

waere es moeglich noch ein [xml][/xml] tag ein zu fuehren - dann waeren xaml files auch moeglich
[xaml][/xaml] wuerde auch gehen, nur xml ist da generischer #gg

Marc++us

xml geht mit dem heutigen Parser nicht, der erkennt nur Schlüsselwörter, aber mit den < > wäre er überfordert.

Xaml wäre wohl möglich, wenn Du mir eine Schlüsselwortliste (bzw. Schlüssel-Tag-Liste) hier reinpostest könnte ich das mal testen.

*rant*

Marc++us schrieb:

xml geht mit dem heutigen Parser nicht, der erkennt nur Schlüsselwörter, aber mit den < > wäre er überfordert.

Xaml wäre wohl möglich, wenn Du mir eine Schlüsselwortliste (bzw. Schlüssel-Tag-Liste) hier reinpostest könnte ich das mal testen.

Wenn ich dir eine C++/CLI Schlüsselwörterliste gebe, gibts dann auch ein C++/CLI Syntaxhighlighting (das wäre dänn wie C++, aber mit einigen zusätzlichen Elementen...)? Ich vermisse dies im Forum schmerzlichst und es ist ja eine standardisierte Sprache

Oh, war das schon Offtopic? Also: Für effektives XAML wäre ein funktionierendes XML-Highlighting voraussetzung... :p

MfG

Marc++us

Das mit Xaml sehe ich nicht zwangsläufig so, da ja die verwendeten Tags bekannt sind - diese färbt man dann ein. Dafür braucht man kein XML-Coloring, wo man ja nach erst noch unbekannten Tags und Attributen schaut...

Wg. CLI - ja, wobei ich das evtl. einfach zu C++ hinzufügen werden, ich denke nicht, daß das wirklich stört. Ein zusätzliches Tag für C++/CLI fände ich ein wenig overkillig.

Also, mal her mit Keywords.

Dravere

Marc++us schrieb:

Das mit Xaml sehe ich nicht zwangsläufig so, da ja die verwendeten Tags bekannt sind - diese färbt man dann ein. Dafür braucht man kein XML-Coloring, wo man ja nach erst noch unbekannten Tags und Attributen schaut...

Naja, wenn man sich dann aber überlegt, wieviele Tags das sind. Alle Kombinationen und womöglich sogar die Attribute, puuuuuh ... ein paar Tausend?
Zudem kann man doch sogar eigene Tags erstellen, also von eigenen Klassen. Und was sicher auch noch ein Problem wäre, dass nur die Elementnamen koloriert würden, also die '<' und '>' ausgelassen würden. Das sähe eher seltsam als leserlich aus, finde ich.

Marc++us schrieb:

Wg. CLI - ja, wobei ich das evtl. einfach zu C++ hinzufügen werden, ich denke nicht, daß das wirklich stört. Ein zusätzliches Tag für C++/CLI fände ich ein wenig overkillig.

BITTE NICHT!
Ich hasse schon das IntelliSense von MSVS, dass es genau dies tut. Ganz schlimme Keywords sind zum Beispiel value , array oder event .

Grüssli

*rant*

Marc++us schrieb:

Wg. CLI - ja, wobei ich das evtl. einfach zu C++ hinzufügen werden, ich denke nicht, daß das wirklich stört. Ein zusätzliches Tag für C++/CLI fände ich ein wenig overkillig.

Also, mal her mit Keywords.

Deal. Ich mach die Liste und lade sie hier rein, sobald ich fertig bin. Dann kannst du ja schauen, was sich damit machen lässt. Bei allfälligen Fragen stehe ich selbstverständlich zur Verfügung

So, hier ist sie nun, meine C++/CLI Keyword Liste, Version 1a. Einige der neuen Keywords werden auch Bestandteil von C++0x sein (z.B. nullptr oder enum class ):

abstract
array
cli
delegate
enum class
enum struct
event
finally
for each
gcnew
generic
in
initonly
interface class
interface struct
interior_ptr
internal
literal
nullptr
override
pin_ptr
property
ref class
ref struct
safe_cast
sealed
typeid
value class
value struct
where

Wo wir gerade dabei sind, vielleicht ist dir schon aufgefallen, dass manche Keywords zweigeteilt sind ( for each - in könnte man sogar als 3-geteilt betrachten...)? Ich weiss nicht, wie man das am besten umsetzt - vielleicht ist es am einfachsten, wenn man einfach beide Einzeilteile einzeln einfärbt? In manchen Fällen ( enum class z.B.) passiert das momentan schon, dort muss man eigentlich nichts mehr machen:

enum class cpp_cli_enum : int 
{
    foo,
    bar,
    qux
};

Dravere schrieb:

Marc++us schrieb:

Wg. CLI - ja, wobei ich das evtl. einfach zu C++ hinzufügen werden, ich denke nicht, daß das wirklich stört. Ein zusätzliches Tag für C++/CLI fände ich ein wenig overkillig.

BITTE NICHT!
Ich hasse schon das IntelliSense von MSVS, dass es genau dies tut. Ganz schlimme Keywords sind zum Beispiel value , array oder event .

Grüssli

Nun, ich stimme zu, dass dies störend sein kann, aber so könnten auch die C-Programmierer, welche z.B. class oder template als Bezeichner verwenden, argumentieren. Weiterhin werden etwa werden manche Wörter wie value oder ref nur in bestimmtem Kontext eingefärbt (gefolgt von class , struct ); dies wird hier nur schwer umzusetzen sein, da es einen komplexeren Parser benötigen würde - und den müsste zuerst mal jemand schreiben (das wäre in PHP, nehme ich mal an und damit bin ich ganz und gar nicht fit ;)).

MfG

Dravere

/rant/ schrieb:

Nun, ich stimme zu, dass dies störend sein kann, aber so könnten auch die C-Programmierer, welche z.B. class oder template als Bezeichner verwenden, argumentieren.

Gut und die C Programmierer werden nun sicher auch ausrufen, noch deutlich mehr

/rant/ schrieb:

Weiterhin werden etwa werden manche Wörter wie value oder ref nur in bestimmtem Kontext eingefärbt (gefolgt von class , struct ); dies wird hier nur schwer umzusetzen sein, da einen komplexeren Parser benötigt - und den müsste zuerst mal jemand schreiben.

Im MSVS gilt das eben nicht und auch in diesem Forum wohl nicht, die Dinger werden immer so eingefärbt. Sehr mühsam...

Grüssli

*rant*

Immer diese konservativen C-Programmierer :p

Ich habe es gerade noch einmal im VS2008 ausprobiert wegen den kontextsensitiven Keywords; die Implementation ist nicht so konsequent, wie man es sich wünschen würde, da hast du natürlich Recht. So wird z.B. bei mir where immer eingefärbt, obwohl es nur in bestimmten Kontexten eine Bedeutung haben sollte. Ansonsten funktioniert es aber doch eigentlich recht gut, ich habe mal einen Screenshot von einem offensichtlich schwachsinnigen Beispiel gemacht.

MfG

Dravere

/rant/ schrieb:

Ansonsten funktioniert es aber doch eigentlich recht gut, ...

Sicher? Dann erklär mir mal, was daran gut funktioniert (VS2008):
http://www.dracopien.ch/temp/VS_syntax_highlighting.png

Vor allem das event nervt mich krankhaft ...
Und hier wäre das wohl nicht besser

Grüssli

*rant*

event ist ja auch ein dummes Schlüsselwort, insofern hast du da Recht Aber ich habe in meinem ganzen Code den ich bisher geschrieben habe (und das ist schon einger ;)) praktisch nie Namen wie array oder event gebraucht, da sie doch so nichtssagend sind. value hingegen verwende ich relativ oft (z.B. in einem property -setter) und damit funktioniert es ja korrekt. Wir können ja mal schauen, wie sich das entwickelt. Wenn es wirklich von vielen als störend wahrgenommen wird, kann man es ja immernoch ändern. Der Vorteil von einer Integration in die normalen [ cpp ] -Tags wäre ja auch, dass der bisher gepostete Code ebenfalls korrekt eingefärbt wird.

A propos einfärben, deine Konfiguration mit den Farben-- ist das auf die Länge nicht recht unangenehm wenn die anderen Applikationen "normal" hell aussehen und du dann den Code dunkel beabeitest? Mich würde das vermutlich stören, weil ich sehr viel hin und her switche zwischen den Fenstern

Dravere

/rant/ schrieb:

value hingegen verwende ich relativ oft (z.B. in einem property -setter) und damit funktioniert es ja korrekt.

Nur wird value bei meinem Beispiel auch falsch eingefärbt

/rant/ schrieb:

Wir können ja mal schauen, wie sich das entwickelt. Wenn es wirklich von vielen als störend wahrgenommen wird, kann man es ja immernoch ändern.

Wieso so komplex? Man müsste ja nur ein Copy&Paste von den C++ Tags machen und deine neuen dazu zu C++/CLI ( ). Das ist kaum Mehraufwand aber dafür eine deutlich bessere Trennung.

/rant/ schrieb:

Der Vorteil von einer Integration in die normalen [ cpp ] -Tags wäre ja auch, dass der bisher gepostete Code ebenfalls korrekt eingefärbt wird.

Rückwärtskompabilität sehe ich im allgemeinen eher als einen Nachteil. Deshalb schreibe ich lieber Import-Funktionen. Man schränkt sich nämlich mit der Rückwärtskompabilität immer ein.

/rant/ schrieb:

A propos einfärben, deine Konfiguration mit den Farben-- ist das auf die Länge nicht recht unangenehm wenn die anderen Applikationen "normal" hell aussehen und du dann den Code dunkel beabeitest? Mich würde das vermutlich stören, weil ich sehr viel hin und her switche zwischen den Fenstern

Nein, es ist ein Segen! Ich bin immer wieder froh, wenn ich zur IDE zurückwechseln kann. Zudem ändere ich alle anderen Programme, wo ich nur kann, zu einer dünkleren Farbe ab. Man kann deutlich länger damit arbeiten. Zum Teil kann es ein wenig mühsam werden, wenn man wirklich sehr schnell hin- und herwechselt, aber das ist eher selten der Fall bei mir. Meistens suche ich die Informationen zuerst zusammen, strukturiere sie auf einem Block Papier und schreibe dann den Code.

Grüssli

Marc++us

Probier mal das cli-Tag aus, problematisch sind tatsächlich so Sachen wie for each, da der Parser Blanks als Trennzeichen benutzt und das beliebig komplex wäre dem das beizubringen. Daher habe ich einfach mal "each" als Schlüsselwort eingetragen.

Schau's Dir mal an... dann zeige ich auch den Hinweis im Editierfeld an.

Dravere

Marc++us schrieb:

Probier mal das cli-Tag aus, ...

Auch wenn das wahrscheinlich eher an /rant/ gemeint war, was genau soll ausprobiert werden?

Ich kopiere mal einfach die Wikipedia Source Codes rüber:

#using <mscorlib.dll>
using namespace System::Collections::Generic;
ref class referencetype
{
protected:
    String^ stringVar;
    array<int>^ intArr;
    List<double>^ doubleList;
public:
    referencetype(String^ str, int* pointer, int number) // Ambiguous no more
    {
        doubleList = gcnew List<double>();
        System::Console::WriteLine(str->Trim() + number);
    }
};

int main()
{
    array<String^>^ arr = gcnew array<String^>(10);
    int i = 0;

    for each(String^% s in arr)
        s = i++.ToString();

    return 0;
}

// C++/CLI
ref class MyClass // : IDisposable (this is added by the compiler)
{
public:
    MyClass();  // constructor
    ~MyClass(); // (deterministic) destructor (turned into IDisposable.Dispose() by the compiler)
protected:
    !MyClass(); // finalizer (non-deterministic destructor) (former destructor syntax => virtual void Finalize())

public:
    static void Test()
    {
        MyClass automatic; // Not a handle, no initialization: compiler calls constructor here
        // Use 'automatic' anywhere in the method

        // Equivalent user code:

        MyClass^ user = gcnew MyClass();
        try { /* Use user here */ } finally { delete user; }

        // Compiler calls automatic's destructor in the finally of a try containing the whole method
    }
};

// a template ref class with operator overloading, copy constructor and assignment operator
 template <typename T>
 public ref class ptr_wrapper sealed
 {
 private:
 	T *m_ptr;
 	ptr_wrapper(T *i_ptr)
 	:m_ptr(i_ptr)
 	{
 		if (i_ptr == 0)
 		{
 			throw gcnew System::Exception("Trying to initialize ptr_wrapper with null pointer");
 		}
 	}
 public:
 	ptr_wrapper(const T &i_ref)
 		:m_ptr(new T(i_ref))
 	{
 	}
 	ptr_wrapper(const ptr_wrapper %i_other)
 		:m_ptr(new T(const_cast<const T&>(*i_other)))
 	{
 	}
 	static ptr_wrapper take(T *i_ptr)
 	{
 		return ptr_wrapper(i_ptr);
 	}
 	~ptr_wrapper()
 	{
 		delete m_ptr;
 	}
 	ptr_wrapper % operator = (const ptr_wrapper %other)
 	{
 		if (other.m_ptr != m_ptr)
 		{
 			T* new_ptr = new T(*other);
 			delete m_ptr;
 			m_ptr = new_ptr;
 		}
 	}
 	static T& operator * (ptr_wrapper<T> %inst)
 	{
 		return *(inst.m_ptr);
 	}
 	static const T& operator * (const ptr_wrapper %inst)
 	{
 		return *(inst.m_ptr);
 	}
 	static T* operator -> (ptr_wrapper %inst)
 	{
 		return inst.m_ptr;
 	}
 	static const T* operator -> (const ptr_wrapper<T> %inst)
 	{
 		return inst.m_ptr;
 	}
 };

Und noch ein Test, ob alle Schlüsselwörter auch hervorgehoben werden:

abstract
array
cli
delegate
enum class
enum struct
event
finally
for each
gcnew
generic
in
initonly
interface class
interface struct
interior_ptr
internal
literal
nullptr
override
pin_ptr
property
ref class
ref struct
safe_cast
sealed
typeid
value class
value struct
where

// Und noch ein zwei zusätzliche Tests:
void foo(Click const& event);
void bar(int each, int eachTick);
void set(int value);

// Aber ich denke, diese Fehler waren zu erwarten :)
// wobei mich gerade value ein wenig überrascht ...

void bar(int each);
// ... an der schliessenden Klammer liegt es nicht ...

Bis auf dieses seltsame aber eigentlich korrekte Verhalten von value , sieht es gut aus, oder?
Ich denke am besten probiert man das "Live" aus, so findet man mögliche Verbesserungen viel eher.

Grüssli

PS: Danke für die Arbeit.