''Here's a debate on strict vs. minimal bracing style that evolved on the [Graffiti] page. I moved it here for persistence -- RS'' ---- ''Look at the Tcl manpage and check out the "[[...]]" syntax (JC):'' if {[file exists $FILE] == 1} { DO_WHATEVER } '''RS''': as file exists returns a truth value, you can simplify this to if [file exists $FILE] { DO_THIS } else { DO_THAT } '''DKF''': but it is usually considered to be a good idiom for various reasons (speed and robustness mainly) to enclose the condition argument to [[if]] in {braces} like so: if {[file exists $FILE]} { DO_THIS } else { DO_THAT } '''RS:''' Yes, I know of cases where the bracing influences speed, but I think [[file exists $FILE]] returns the same result in constant execution time, whether called from inside or outside expr. Without the curly braces, the if receives 1 or 0 as argument, and this wouldn't cost much parsing time either ;-) '''LH:''' Thanks y'all, I've tested it out and I can make it work. '''DKF:''' The '''if {[[file exists $FILE]]}''' form is marginally faster (but the difference in speed is negligable, given that we need to context switch out to the OS) but the main reason for using that style of idiom is that it is a good habit to get into, so you don't end up using it somewhere where it jumps up and bites you (in either performance or semantic terms.) A bit like not playing ball on railway tracks... '''RS:''' Point taken. Or... Of course it's safer to always brace. But I prefer code that looks more natural, and when I have one pair of brackets, the extra braces somehow don't look good to me. You certainly gotta know what you're doing, and it's on own risk. But still, if $done break looks better to me, and is legal, even if against the style rules ;-) '''LH:''' I think, for my needs, the more "style-correct' version is better. We're staffed with various levels of scripters, and the more standard we make it the better. '''DKF:''' Plus, many of us use editors that can provide better context highlighting support [http://www.man.ac.uk/~zzcgudf/tcl/tcl-font.el] to style-correct code... '''LH:''' What sort of editor, (asks the vi user)? '''DKF:''' I don't know too much about ''nvi'' and ''elvis'', but I think that they have highlighting of some form. How good it is (does it handle detecting where likely valid places for commands to start are, given that Tcl is a keyword-less language?) I just don't care! :^) '''LH:''' Hmm.... may have to go back to emacs for coding. Started with vi because it's more common on different unixes (linux and solaris). Did like the bracket matching of emacs. Are there any IDEs that handle scripting like tcl? '''PSE:''' Since you guys went here, I'll throw in my 2 cents: VIM has really excellent syntax hl, brace matching, etc. for Tcl. You can even get it to do syntax hl in console mode. See http://www.vim.org '''JCGM:''' My editor is vile (VI like EMACS), a vi clone engineered on top of micro-emacs which, IMHO, provides the best of both worlds. Look at http://www.clark.net/pub/dickey/vile/vile.html and http://www.cmc.net/~bem/vile/ ---- [AMG] Although I love my [vim] to pieces, I am really disappointed in its Tcl highlighting (look in $VIMRUNTIME/syntax/tcl.vim if you want to read along or fix stuff). The problem is that vim's syntax system highlights based soley on keywords, regexp matchs, and regexp start-end regions. I've tried and failed to describe the Tcl language using these primitives, which work soooo well for languages like C but maybe don't apply wholly to Tcl. Maybe someone can give me a hand...? For this vim misbehaves in four degrees. For first: proc, global, return, lindex, set, and so on are mostly "tclStatement" keywords. But we all know they're not really keywords, since they only have meaning when they appear as the first word of a line of Tcl script. So when I type "set set set" I wind up with all three instances of the word colored yellow, which is exceedingly ugly to me. This is why I don't name my variables "list". For secondly: expr, namespace, string, array, etc., that is, many things with special syntax (use of math functions), subcommands (like "namespace children"), and/or or common switches ("pack -in"), are match regions beginning with the command name and ending with ]] or end-of-line (regardless of \, due to a bug) or [[...]] (but not semicolon). The function names and subcommands and switches (sans -) are all considered keywords contained in the appropriate match region. But I find that mostly this screws up everything else I try to type on the line, and it's really annoying to have switches colored brown on the first line and white on the remaining because the match region ended prematurely. For thirdly: text, message, entry, and other Tk commands are match regions containing keywords, like above, but they have names I very often want to use for variables. Since the match region starts anywhere "text" or whatever appears, I get a lot of mangled highlighting. (Thankfully "$text" doesn't trigger, but "set text" still does.) These match regions do appear to correctly span multiple lines. I wonder why that doesn't work for the non-Tk highlights. For fourthly: There are many miscellaneous problems. \''newline'' doesn't work for comments. $ expansion doesn't recognize :: or variables starting with underscore or numerals, even when ${...} is used. Unlike decimal highlighting, hexadecimal highlighting starts even when the number doesn't begin the word. (And besides, numbers shouldn't be highlighted anyway.) I don't know how to adequately express the Tcl language using only regexps. I'm not even sure it's possible. So I find myself modifying my code to avoid for the more gratuitous highlighting bugs, and that's a pretty sad situation. We should move this to a new page... but I'm still a bit timid about this whole wiki thing so I'll leave that to someone else. :^) (I apologize to [Ro] for the bent-nose smiley, hehehe.)