Incoming from Faheem Mitha: > > well. The bottom line is that in Python whitespace is syntatically > meaningful, in C etc. it is not. > > This has the consequence that in C, emacs is able to correctly indent > the code, using the built-in syntax rules it knows about. This is very > useful since it shows up trivial syntax bugs right away.
... which is one of the reasons I truly enjoy coding in emacs. > On the other hand, much of the time emacs does not know what to do > with Python code (when in python mode, that is), since part of the This is surely a deficiency in emacs' python mode? > synax info is encoded in the whitespace. Blindly hitting tab, which > works fine with C/C++ and probably most of the other languages out > there, can really mess up Python code. The same is true for shell-mode and perl-mode. emacs generally doesn't know what to do, indentation-wise, when it runs into what it considers ambiguous situations. You would think that with access to the code in the shell, perl, or python interpreter, emacs shell, perl, and python modes would do as well as the shell, perl or python interpreters. This is often not the case. I've often found it necessary to comment/escape special chars in perl code to expect (shell|perl)-mode to get it right. I've had to embed comments that warned that the following expression is the way it is because emacs' perl-mode got it wrong, and the code is the way it is because the emacs mode is broken, and the code should be edited before use. Really, for me, it's not a big deal. I can do that. It just seems odd that the mode can't (for whatever reason) do as well as the interpreter/compiler. Whoever's writing the _mode_ parser should be working from the same page as the _code_ parser, no? -- Any technology distinguishable from magic is insufficiently advanced. (*) http://www.spots.ab.ca/~keeling - - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]