Sunday, April 24, 2011
Dear Stefan,
This email will be as short as possible. Being an old man with few years to live (give or take I have only 70 more years left) I know that time is precious, and I also know that you have better things to do than to read my detailed TopStyle suggestions.
1. Thank you for your latest reply. As usual, very patient, detailed, and professional. You are indeed an Uber-mensch!
2. I am glad you visited Bavaria! Bavaria is to me the most beautiful place on earth. Sometimes I drink beer and play the trumpet wearing just a dark green Tyrol hat with the troika of black, red and bright gold feathers in it, to remind myself of the glory days of my youth. I don't wear any lederhosen, because you see, at my age I chafe easily.
Now, to TopStyle:
3. Regarding the errors that are displayed when opening some types of files - here is the issue as I see it: it seems like TopStyle actively discourages people from opening files other than those that are "allowed", even though these are just text files. Perhaps I could suggest this: internally to TopStyle, split files into two categories: "allowed" files (HTML, CSS, etc) and "other", those that are not what you expect to be editing. The "other" you should treat as text, and preferably try to match to it a chroma-coding lexer based on the extension. There is no reason for a person editing an HTML or CSS or PHP file, *not* to be able to open a *.txt or *.sql file. These files, since they are "other" should *not* be interpreted, previewed, etc, they should just be loaded for editing as any flat text file. And if you can match a lexer and have the text color-coded for SQL or whatever the extension is, then all is good. But TopStyle should not discourage editing these "other" files. I understand that TopStyle is (mostly) a CSS/HTML editor, but in Web programming there is a lot besides HTML and CSS. It seems strange to close the door to sql and text (and other) files when they are just so common, and after all is said and done, these are just text files.
I hope I'm making sense: you can treat CSS/HTML etc as your preferred files, and provide for them extra features, but it seems limiting to block other types of text files. With your not-preferred files just load them, see if you can color-code them, and carry on.
4. Apologies for not expressing well-deserved gratitude for adding the feature where users can set the color the current line of code: thank you for this enhancement! Now to clarify, yes, please allow setting the type of the lines, so that instead of dashes users can use solid, dotted, dashed or no lines, and if possible allow setting the color of these lines.
Please don't get confused by my seemingly shape-shifting use of the word "lines": in context #1 it refers to the current line of source code, in context #2 it refers to the current line indicator, in context #3 it refers to the line above and below the current line indicator. Perhaps we should refer to this as "the border type of the current line indicator bar".
5. Stefan, once you use an editor that does true Indent Guides (the vertical lines that I described) you will never go back. This is particularly very useful when you have to edit somebody else's code and you need to make sense of the code. Indent Guides are a life saver, and also make it easy to spot bugs related to improperly closed blocks of code and other problems. It is also an invaluable feature when organizing a poorly formatted source code file.
6. I believe that my explanation of ZenCoding was very shallow. Assuming that you used ZenCoding, I failed to mention that ZenCoding is not just an abbreviation expander, it also supports a very straightforward syntax to chain abbreviations. As such:
div#page>div.logo+ul#navigation>li*5>a
will expand to
<div id="page">
<div class="logo"></div>
<ul id="navigation">
<li><a href=""></a></li>
<li><a href=""></a></li>
<li><a href=""></a></li>
<li><a href=""></a></li>
<li><a href=""></a></li>
</ul>
</div>
ZenCoding is a brilliant library and for people who do a lot of HTML/CSS (TopStyle's area of expertise) ZenCoding can save much typing, once you become an expert in its notation. I agree that the TopStyle abbreviation expander is nice, but it's no ZenCoding. No offense intended.
Please also note that the ZenCoding site has a TopStyle piece, but the installation is somewhat messy, and in order to expand abbreviations, we need to select the abbreviation first, and the tab bar needs to be on display too. In editors where ZenCoding is smoothly integrated all you need to do is type the abbreviation or the abbreviation sequence and hit a pre-set key, and pop! it expands.
For TopStyle specific reference:
> App files:
http://code.google.com/p/zen-coding/dow ... ng.1.2.zip> How-to:
http://code.google.com/p/zen-coding/wik ... enCodingEn7. You are OK with the panels not being self-hiding. What can I say, I understand your priorities. However please know that Eclipse, Visual Studio, NetBeans etc all have support for self-hiding panels. Yes, I also know they have tons of money and developers, so it's easy for them to do stuff like that. As the Americanische say "I get it". However, I hope one day, when you win the lottery, you may implement that. Bottom line: I understand and respect your decisions and your need to set priorities.
8. Thank you for planning to support the new browsers. That's not fun, with the constant upgrades in browsers and all, but important. Thank you for your hard work.
9. So TopStyle can run JavaScripts? That is actually very good (and surprising) news! So surprising in fact, it's confusing. So we can write macros then? This needs investigation. Where is my spyglass? And where is my butterfly net? Helga! Helga! Where is Helga, my zaftig assistant?
10. Yes Stefan. Beer first. A good beer never breaks your heart, and doesn't mind if you play the trumpet wearing only a bright sea-green Tyrol hat with white and sky-blue feathers in it, to celebrate the traditions, the history and the flag of Bavaria.
11. A new feature request - please allow me to explain the need first:
- Often times CSS files grow because we add more and more rules, using classes, id's and by overloading standard HTML tags. At a certain point it becomes a mess. What would be nice is to be able to sort these rules by the rule name, so that overloaded html tags come first, classes which start with a "." come second, and then id's which start with "#" come third, each in alphabetical order. However in order to do that we need to compress each rule to a single line, then sort the lines and then "reopen" the rules.
- I don't think that TopStyle can sort lines, unless there is some secret way to do that.
- So now, the feature definition, in two steps: [a] allow sorting of text blocks, [b] allow sorting of css rules, by category and then alphabetically within each category.
I think this is the last of my comment emails for the time being. In all sincerity, I must tell you that creating and supporting a programmer's editor is extremely hard. Programmers have a lot of requirements and their needs constantly evolve, as technology advances. One also has to admit that the Scintilla library has raised the bar. Add to that a product like Eclipse, which albeit monolithic, has an impressive array of customizable editing features, and you can see that you've got your work cut out for you.
Nevertheless, I'm sure TopStyle 5 will be something we should look forward to.
Thank you most kindly for taking the time to read my detailed comments. Old people, we are long-winded. You have my gratitude.
I wish you much strength, wisdom, happiness and success in your work and life.
Best Regards,
Gustaf Von Glockenspiel
Immer und Immer - Bavaria Uber Alles!