TC v7.5b1: Datei-Kommentare

[Urmel]

Hallo miteinander

Zuerst dachte ich, dass ich nicht so heiss auf die neue Version sein würde. Dies weil immer das Unicode-Feature so hervorgehoben wurde. Nun nach einem genaueren Blick drauf, haben mich doch ein paar der Neuerungen fasziniert.

Und das ganze wirkt auch schon schön stabil. Danke an Christian und alle Tester für die geleistete Arbeit!

Jetzt freue ich mich doch auch schon sehr auf die neue Version

Ein Problem stellt sich mir aber: Natürlich sind die längeren Datei-Kommentare (Ctrl+Z) eine tolle Möglichkeit. 511 Zeichen waren mir oft zu kurz.

ABER ... Ich arbeite mit 4NT 7.01 und Take Command 9.02 von JP Software. In beiden Versionen sind die Datei-Kommentare auf 512 Zeichen beschränkt.

Wenn ich nun mit dem neuen Commander längere Kommentare erzeuge und eine damit versehene Datei mit 4NT/TC handhabe (kopiere/verschiebe), so werden im Datei-Kommentar alle Zeichen >512 einfach gelöscht. Das kann dann SEHR missliche Folgen haben. Z.B. enthalten bei mir die Kommentare von downloadeten/archvierten Utilities immer am Schluss des Kommentars die URL woher das Ding stammt. Wenn die nun nicht mehr vollständig ist...

Ich denke, dass hier UNBEDINGT eine Hilfe für uns Anwender angebracht ist.

Folgende Möglichkeiten sehe ich da:

1. Einen anderen Dateinamen als descript.ion für den Commander wählen. (Würde ich nicht gut finden).

2. Ein Konfigurations-Option, das die bisherige Längen-Beschränkung auf Wunsch beibehält. (Wohl die beste Möglichkeit).

3. UND/ODER: Einen Zähler im Kommentar-Editor, der die Zeichennummer an der Cursor-Position und die Totalzahl der Zeichen anzeigt. (Die Totalzahl könnte auch rot angezeigt werden, wenn sie über die alte Beschränkung hinausgeht).

Ich weiss, dass die Möglichkeit 3 durch die backslashes den Dateinamen etc. ein wenig Arbeit bedeuten würde. Aber gerade diese Möglichkeit wäre imho so oder so eine tolle Hilfe für die Kommentar-Funktion! Ein alter Descriptions-Editor unter DOS konnte das mal und das war wunderbar.


Nebenbei: In der History fand ich folgenden Text:

16.01.08 Added: increased max. comment length in descript.ion to 4096 characters (minus the length of the file name, a space, and final line break)

Hier sollten die Anführungszeichen nicht vergessen werden, die je nach Art des Dateinamens auch noch abgezogen werden müssen.

Ich hoffe sehr, dass sich hier für die Datei-Kommentare eine Lösung bis zur finalen Version ergibt. Sonst wird für Anwender wie mich, die die Utilities von JP Software einsetzen das Leben schwerer, in einem Bereich wo es wirklich nicht sein müsste...

Viele Grüsse und nochmals Danke für die tolle Arbeit!
-Urmel-

[sqa_wizard]

Wenn ich nun mit dem neuen Commander längere Kommentare erzeuge und eine damit versehene Datei mit 4NT/TC handhabe (kopiere/verschiebe), so werden im Datei-Kommentar alle Zeichen >512 einfach gelöscht.

Bist du sicher, dass sie gelöscht werden ?
Oder werden sie einfach nicht in 4NT angezeigt, im TC aber wieder ?

[Urmel]

Bist du sicher, dass sie gelöscht werden ?

Ja. Alles was über 511 Zeichen plus Dateiname hinausgeht ist aus dem File descript.ion entfernt.

Ich hatte das getestet, indem ich eine Datei einem Kommentar mit über 511 Zeichen mit den beiden genannten Versionen von 4NT und Take Command in ein anderes Verzeichnis kopiert habe.

Somit für User der JPS-Utilities ein ganz gefährliches Fettnäpfchen, in das garantiert getreten wird.

Viele Grüsse
-Urmel-

[van Dusen]

2Urmel

Laut Beschreibung zum Describe-Kommando kannst Du die maximal zulässige Kommentarlänge konfigurieren (ob das erst ab V10.0 oder schon mit V9.02 möglich ist, weiß ich leider nicht):

Each description can be up to 511 characters long. You can change this limit with the Maximum Length configuration option. In order to fit your descriptions on a single line in a standard DIR display, keep them to 40 characters or less (longer descriptions are wrapped in the DIR output). DESCRIBE can edit descriptions longer than Maximum Length (up to a limit of 511 characters), but will not allow you to lengthen the existing text.

Aber auch ich bin ich noch nicht restlos davon überzeugt, dass die Behandlung von descript.ion-Kommentaren im TC korrekt (JP-Soft-Take-Command-kompatibel) implementiert ist:

Wenn mit dem TC erstellte Kommentare Zeilenumbrüche enthalten, dann werden diese mit der Zeichenfolge "\n" codiert (soweit ok) und mit der File-ID 0xC2 gekennzeichnet. Allerdings wird die File-ID hinter den Kommentar eingefügt, statt - wie es meiner Ansicht nach sein müsste - vor den Kommentar:

[...]
filename.ext Description[*<ID>Other program info]...<CR><LF>

There is normally one space between the description and filename but
additional spaces may be used in future versions. The characters
after the description allow extension of the description format
for use by other programs. They are as follows:

* is an ASCII Ctrl-D (04), and marks the end of the description
text and the beginning of information for a program other than
4NT or Take Command. This symbol can appear multiple times on each
line; each occurrence marks the beginning of information for another
program.

<ID> is an identification byte for the program which is using this
area of the particular line. If you are writing a program which
will store information in DESCRIPT.ION, test it using an ID byte of
your own choosing. When you are ready to release the program,
contact JP Software and we will provide you with an ID byte value
that is not in use by others to the best of our knowledge.

Other program info is any text the program wishes to store in its
area of the line. The text should relate specifically to the file
named on the line. It may not contain the Ctrl-D character,
carriage returns, line feeds, or nulls (ASCII 0s).

4NT and Take Command will copy, delete, or move all the information on a
line in DESCRIPT.ION, including information owned by other programs, when
performing the same action on the corresponding file.
[...]

> Richtig wäre m.E. also
> filename.ext Description[*<ID>Other program info]...<CR><LF>

> TC schreibt aber
> filename.ext Description[Other program info*<ID>]...<CR><LF>


Außerdem verändert TC den bereits vorhandenen Standard-Kommentar statt diesen unverändert zu lassen und mit einer Kopie des Standard-Kommentars zu operieren:


Richtig wäre m.E.:

> Vor dem Bearbeiten des Kommentars im TC:
> filename.ext Description<CR><LF>

> Nach dem Bearbeiten des Kommentars im TC:
> filename.ext Description0x042CEdited Description<CR><LF>


TC arbeitet zur Zeit aber so:

> Vor dem Bearbeiten des Kommentars im TC:
> filename.ext Description<CR><LF>

> Nach dem Bearbeiten des Kommentars im TC:
> filename.ext Edited Description0x042C<CR><LF>


Dass TC den Standard-Kommentar benutzt, ist m.E. zwar nicht korrekt, aber vermutlich in aller Regel gewünscht. Damit zumindest syntaktisch alles ok ist, sollte TC aber m.E. folgendermaßen operieren:

> Vor dem Bearbeiten des Kommentars im TC:
> filename.ext Description<CR><LF>

> Nach dem Bearbeiten des Kommentars im TC:
> filename.ext 0x042CEdited Description<CR><LF>

Das würde ausdrücken, dass der Standard-Kommentar leer und nur eine "Other program info" (nämlich der vom TC editierte Kommentar) vorhanden ist.


Sicherheitshalber sollte Hr.Ghisler nicht nur bei Verwendung von Zeilenumbrüchen die TC-Kommentare mit seiner File-ID 0x2C kennzeichnen, sondern m.E. auch dann, wenn der (TC-editierte Standard-)Kommentar länger als 511 Zeichen ist.

[ghisler(Author)]

Nein, das ist schon richtig so mit dem Code: Vor den Codes soll ja der reine Text stehen - dort sehen die User anderer Programme einfach \n anstatt einem Zeilenumbruch.

In der technical note steht ja:

filename.ext Description[*<ID>Other program info]...<CR><LF>

"Description" ist dabei die Beschreibung als reiner Text. Ob ich als Platzhalter für die Umbrüche nun \n oder sonst ein Zeichen schreibe ist eigentlich egal. Meine ID 2C sagt nur aus, dass die Zeichen \n als Umbrüche angezeigt werden sollen.

Was die Zeilenlänge angeht, steht in der technical note
http://www.jpsoft.com/ascii/descfile.txt

The line length limit is 4096 bytes

Deshalb bin ich davon ausgegangen, dass zumindest 4NT damit zurecht kommen sollte...

[Urmel]

Laut Beschreibung zum Describe-Kommando kannst Du die maximal zulässige Kommentarlänge konfigurieren (ob das erst ab V10.0 oder schon mit V9.02 möglich ist, weiß ich leider nicht):

Das war auch unter DOS schon möglich.

DESCRIBE can edit descriptions longer than Maximum Length (up to a limit of 511 characters), but will not allow you to lengthen the existing text.

Der Satz sagt nur aus, dass der Befehl DESCRIBE Kommentare länger als in "Maximum Length" definiert editieren kann. Aber eben nur bis zur Limite von 511 Zeichen! Dies ist also nur relevant, wenn "Maximum Lenght" auf einen niedrigeren Wert als "511" festgelegt wurde.

In 4NT 7.02 steht fast der genau gleiche Hilfetext und in Version 9.02 sogar der genau gleiche Text. Der Umstand wird in der Version 10 also kaum anders sein. Ich habe jedenfalls in den aufgeführten Neuerungen in den entsprechenden Foren sowie in der Liste im Helpfile keinen Hinweis auf eine Änderung gefunden.

Aber auch ich bin ich noch nicht restlos davon überzeugt, dass die Behandlung von descript.ion-Kommentaren im TC korrekt (JP-Soft-Take-Command-kompatibel) implementiert ist:

Diese TechnicalNote kannte ich nicht. Werde sie downloaden und mal genauer studieren. Ich weiss nur, dass ich bis jetzt in der Praxis keine
Inkompatibilitäten zwischen den JPS-Utilities und dem TC bez. der Datei-Kommentare entdeckt habe.

Einzig vielleicht, dass der TC das File "descript.ion" nicht immer löscht wenn ich z.B. alle Dateien in einem Verzeichnis lösche.

[Urmel]

Deshalb bin ich davon ausgegangen, dass zumindest 4NT damit zurecht kommen sollte...

Hmm... Ich hätte den gleichen Schluss gezogen. Diese Aussage in der "technical note" verstehe ich nicht. Denn 4NT 7.01 und TCC 9.02 (Take Command Console, das 4NT-Pendant ab Version 9) löschen beide alle Zeichen >511 in der Datei "descript.ion"!

Ich habe in den Konfigurationsdateien der beiden Programme "DescriptionMax" mal testweise auf "4000" gesetzt. Schon beim darauffolgenden Start zeigen die Programme folgende Fehlermeldung:

Error on line xx ovf c:\...\4NT.ini
Invalid numeric value for "DescriptionMax"
Press any key when ready...

Error on line xx ovf c:\...\TCMD.INI
Invalid numeric value for "DescriptionMax"
Press any key when ready...

Also haben wir hier leider definitiv eine imho unhaltbare Inkompatibilität zwischen den Programmen. Ich finde eine Erhöhung der Kommentarlänge auch eine tolle Sache. Aber ich denke, dass sie dann für User der JPS-Utilities abschaltbar sein müsste oder wie schon geschrieben (und von mir favorisiert) mit einem Zeichenzähler und ev. einer Warnung per Farbwechsel/Beep wenn die Limite überschritten wird.

Ich habe Bereiche in meinen Partitionen, in denen ich nie mit den JPS-Utilities arbeite. Z.B. in meinem Software-Archiv oder den Fotografien und Musikdateien. Dort würde ich die längeren Kommentare auch gerne nutzen. Sonst kann ich dies nicht, weil mir diese dann teilweise verloren gingen.

Also irgendeine Hilfe für den User wird es wohl geben müssen (hoffe ich sehr).

[ghisler(Author)]

Ich könnte die Länge im Strg+Z-Dialog auf 512 begrenzen, aber längere Kommentare bis 4096 Zeichen kopieren (wie bisher in TC 7.5). Wäre das OK? Oder soll ich bei zu langen Kommentaren lediglich eine Warnung anzeigen?

[Hacker]

Christian,
Der Zähler unten im Fenster wäre IMO die beste Lösung. Die Farbe des Zähler könnte auf Rot gestellt werden ab dem 512-ten Zeichen.

Roman

[schwarol]

ja, ein zähler für die anzahl der zeichen wäre wünschenswert.

bitte auf keinen fall die anzahl der zeichen wieder auf 511 begrenzen.


beim ersten test des neuen maximums (im wesentlichen mit kopiertem text aus der tc-hilfe) kam es hier auch

- zu 'access violation' beim rechtsklick/eigenschaften auf das kommentierte objekt

- zum 'verschwinden' des normalen kontextmenüs (reduzierung auf kopieren, verschieben...); nach neustart ist es wieder da (um nach dem nächsten rechtsklick wieder zu verschwinden).


darüberhinaus lässt die bearbeitungsfunktion mehr zeichen zur eingabe zu als dann übernommen/gespeichert werden.

die zeichen werden einfach abgeschnitten. beim nächsten aufruf der bearbeitungsfunktion ist es aber (obwohl maximum schon erreicht) wieder möglich, weitere zeichen einzugeben (die dann wieder abgeschnitten werden). möglicherweise werden die dateinamen im bearbeiten-modus nicht richtig mitgezählt.

falls erforderlich, kann ich die sachen mit kontextmenü/access violation auch irgendwo hochladen.

ansonsten: alles ziemlich gelungen

[Urmel]

Ich könnte die Länge im Strg+Z-Dialog auf 512 begrenzen, aber längere Kommentare bis 4096 Zeichen kopieren (wie bisher in TC 7.5). Wäre das OK?

Zurück zur alten Beschränkung wäre imho sehr schade. Ich denke dass eine Erhöhung der Limite eine feine Sache ist. Nur solange JPS nicht mitzieht, muss man die User beider Tools vor Datenverlust schützen.

Oder soll ich bei zu langen Kommentaren lediglich eine Warnung anzeigen?

Einen Zähler mit Beep nach 511 Zeichen der zugleich die Farbe wechselt, wäre imho die beste Lösung.

Ein Zähler wäre schon immer eine tolle Sache gewesen.

Ein Beep bei der Grenze wäre für Schnell- und Blindschreiber toll, und die Farbe würde sofort bestätigen, dass man zuviel des Guten tat... Auch wenn ein Kommentar schon zuviel Zeichen hat, wäre das nach dem Öffnen so schnell zu erkennen.

Macht hoffentlich nicht all zuviel Arbeit - würde das Feature aber toll aufwerten.

Hat Rex dann nie erwähnt, ob er eine Aufbohrung der Descriptions auch ins Auge fasst?

Wenn nein, warte ich bis Du Deine Lösung verwirklicht hast und frag Rex mal in einem der JPS-Foren. Take Command täte eine Erweiterung dieses Features nämlich auch gut.

Vielen Dank, dass Du das Problem ernst nimmst!
-Urmel-

[ghisler(Author)]

beim ersten test des neuen maximums (im wesentlichen mit kopiertem text aus der tc-hilfe) kam es hier auch

- zu 'access violation' beim rechtsklick/eigenschaften auf das kommentierte objekt

- zum 'verschwinden' des normalen kontextmenüs (reduzierung auf kopieren, verschieben...); nach neustart ist es wieder da (um nach dem nächsten rechtsklick wieder zu verschwinden).

Kann ich leider nicht reproduzieren - sind Sie sicher, dass dies mit der Kommentarfunktion zu tun hat, und nicht mit einer fehlerhaften Rechtsklickmenüerweiterung?

[schwarol]

mit dem alten 511-kommentar gab es ja keinen crash des kontextmenüs.

habe jetzt auch festgestellt, dass es bis 2048 zeichen reinen kommentars (zuzüglich dateinamen, abzüglich 2 controls) auch ohne crash funktioniert.

mit mehr zeichen ist es dann aber aus.

ich habe schon mal einige verdächtige deinstalliert - aber natürlich waren es die nicht.


hab' mal ein kleines paket dazu zusammengestellt (http://rapidshare.com/files/224603703/kommentar-paket.7z.html):


-descript-05... = bsp-kommentar bei dem es crasht (identisch mit der aktiven descript.ion; 4090 zeichen)
-descript-16... = der kommtar mit dem es gerade noch funktioniert (2111 zeichen)

dazu ein bild der access violation und den ordner der kommentiert ist

[ghisler(Author)]

Danke, werde damit testen!

[karlchen]

Hallo, Schwarol.

Habe dein 7Z-Datei heruntergeladen und das Verzeichnis 0-Paket samt Inhalt, also inklusive des 4090 Zeichen langen Kommentars zum Verzeichnis "kommentare auf maximum-4char verschluckt-fokus anfang12", entpackt.
Aufrufe des Kontextmenüs des Verzeichnisses "kommentare auf maximum-4char verschluckt-fokus anfang12" führen hier nicht zum Crash des Total Commanders.

Die Aussage, dass Kommentare bis 2111 Zeichen gerade noch funktionieren, kann ich so auch nicht bestätigen. Hatte schon früher, ohne über irgendeine Problematik nachzudenken, der Datei tcmdr75b18.aes einen 3234 Zeichen langen Kommentar hinzugefügt. Aufrufe des Kontextmenüs der Datei tcmdr75b18.aes haben bisher nie zu irgendwelchen Problemen geführt.

+ Total Commander v7.50 Public Beta 1
+ Windows Vista Home Premium, 32bit

Werde das Ganze auch noch mal auf Windows XP gegenprüfen. Vielleicht habe ich unter Vista ja nur Glück gehabt.

Grüße,
Karl