Font color of within comments question
This could be more of a font-lock question, but: Stuff with wrapped around it gets highlighted in black, so that it stands out from the rest of the comment. That's great. However, sometimes I accidentally do this: blah. I don't properly close the code tag. In that case, 'blah' is in the normal comment font, not black. That's good, and should be enough for me to notice that I didn't close it properly. However, I'm dense and don't always notice that. So, my question is, is there a way to make it highlight everything in black until there was a closing tag? That way, if I forgot to close it, all the rest of the comment would be in black. That would really stand out, even for dense people like me. Thanks! Steve Molitor [EMAIL PROTECTED]
Byte-compiling (Was RE: JDE config problem?)
At 09:07 AM 2/12/02 -0500, Paul Kinnucan wrote: >Berndl, Klaus writes: > > >I've run the JDE with eieio both compiled and uncompiled and I've > > >never noticed any difference in performance. Further, I can't imagine > > >why it should cause bad performance. eieio is not used to do any > > >computationally intensive tasks. > > On a related but orthogonal note, do you have an idea how byte-compiling would affect memory usage? Most (all?) of the time when a JDE command is slow, I'm fairly certain that it's because I'm low on memory and the program is swapping. (Compiling with the compile server often takes less than a second, but can take more than 15.) Troy > > First of all not only JDE uses eieio but also semantic which in turn > > is used by JDE. > > > > Secondly macros & defsubst functions are inlined if byte-compiled > > and eieio has a lot of them (if i remember right, Eric has told > > me this). > > BTW: This argument would also recommend, that we should > > semantic byte-compile! > > > > But here comes the original explanation from Eric, the author of eieio: > > > > "Byte compilation converts the lisp program into a stack based program > > with integer IDs for all built-in symbols. The core of EIEIO uses > > almost all built in commands (like car, cdr, assoc, etc). In > > particular, the method dispatch mechanism does a lot of work. When > > EIEIO core is not byte compiled, the method dispatch runs between > > every single EIEIO method call. The byte compilation step speeds > > this up a lot." > > > > Therefore my strong recommendation: At least eieio and semantic > > should be byte-compiled. > > And for other packages it is IMHO at least a good way to detect some > > errors... > > > > >If you have noticed bad performance, I'd like to know under what > > >circumstances so that I can investigate. There may be ways to > > >improve the performance. > > > > Yes, just byte-compile eieio and semantic :-) > >Klaus, > >I don't doubt that byte-compiling eieio improves performance. What I >doubt is that byte-compiling eieo improves JDE performance >perceptibly. The JDE does not use eieio for any computation-intensive >tasks. A few microseconds of difference in the execution of a debugger >step command or the creation of a dialog buffer is not going to be >perceptible to a human being with ordinary powers of perception. My >experience running the JDE with eieio both compiled and uncompiled >confirms this. On the other hand, incorrectly compiling eieo does make >a PERCEPTIBLE difference in the response time of JDEE commands. It >increases the response time to INFINITY and forces me to repeatedly >having to tutor new users on the correct way to byte-compile sets of >interdependent Lisp files. This takes up a significant portion of my >time, which is why I try to discourage people, especially novices, >from byte compiling the JDE. The only way you are going to convince me >to change this policy is to cite a SPECIFIC JDE command that is >PERCEPTIBLY improved by byte-compiling eieio. > >As for semantic, compiling semantic does shorten loading of large Java >files but otherwise does not make a significant enough difference, in >my opinion, to warrant encouraging new users to compile the JDE. > >I've used a lot of Emacs applications and the only one that I have >used where compilation is absolutely necessary is psgml because >compiling psgmal reduces parsing of the Docbook DTD from hours to a >few seconds. > > >- Paul Troy Daniels [EMAIL PROTECTED] 781-273-3388 x218
RE: JDE config problem?
Berndl, Klaus writes: > >I've run the JDE with eieio both compiled and uncompiled and I've > >never noticed any difference in performance. Further, I can't imagine > >why it should cause bad performance. eieio is not used to do any > >computationally intensive tasks. > > First of all not only JDE uses eieio but also semantic which in turn > is used by JDE. > > Secondly macros & defsubst functions are inlined if byte-compiled > and eieio has a lot of them (if i remember right, Eric has told > me this). > BTW: This argument would also recommend, that we should > semantic byte-compile! > > But here comes the original explanation from Eric, the author of eieio: > > "Byte compilation converts the lisp program into a stack based program > with integer IDs for all built-in symbols. The core of EIEIO uses > almost all built in commands (like car, cdr, assoc, etc). In > particular, the method dispatch mechanism does a lot of work. When > EIEIO core is not byte compiled, the method dispatch runs between > every single EIEIO method call. The byte compilation step speeds > this up a lot." > > Therefore my strong recommendation: At least eieio and semantic > should be byte-compiled. > And for other packages it is IMHO at least a good way to detect some > errors... > > >If you have noticed bad performance, I'd like to know under what > >circumstances so that I can investigate. There may be ways to > >improve the performance. > > Yes, just byte-compile eieio and semantic :-) Klaus, I don't doubt that byte-compiling eieio improves performance. What I doubt is that byte-compiling eieo improves JDE performance perceptibly. The JDE does not use eieio for any computation-intensive tasks. A few microseconds of difference in the execution of a debugger step command or the creation of a dialog buffer is not going to be perceptible to a human being with ordinary powers of perception. My experience running the JDE with eieio both compiled and uncompiled confirms this. On the other hand, incorrectly compiling eieo does make a PERCEPTIBLE difference in the response time of JDEE commands. It increases the response time to INFINITY and forces me to repeatedly having to tutor new users on the correct way to byte-compile sets of interdependent Lisp files. This takes up a significant portion of my time, which is why I try to discourage people, especially novices, from byte compiling the JDE. The only way you are going to convince me to change this policy is to cite a SPECIFIC JDE command that is PERCEPTIBLY improved by byte-compiling eieio. As for semantic, compiling semantic does shorten loading of large Java files but otherwise does not make a significant enough difference, in my opinion, to warrant encouraging new users to compile the JDE. I've used a lot of Emacs applications and the only one that I have used where compilation is absolutely necessary is psgml because compiling psgmal reduces parsing of the Docbook DTD from hours to a few seconds. - Paul
RE: JDE config problem?
>I've run the JDE with eieio both compiled and uncompiled and I've >never noticed any difference in performance. Further, I can't imagine >why it should cause bad performance. eieio is not used to do any >computationally intensive tasks. First of all not only JDE uses eieio but also semantic which in turn is used by JDE. Secondly macros & defsubst functions are inlined if byte-compiled and eieio has a lot of them (if i remember right, Eric has told me this). BTW: This argument would also recommend, that we should semantic byte-compile! But here comes the original explanation from Eric, the author of eieio: "Byte compilation converts the lisp program into a stack based program with integer IDs for all built-in symbols. The core of EIEIO uses almost all built in commands (like car, cdr, assoc, etc). In particular, the method dispatch mechanism does a lot of work. When EIEIO core is not byte compiled, the method dispatch runs between every single EIEIO method call. The byte compilation step speeds this up a lot." Therefore my strong recommendation: At least eieio and semantic should be byte-compiled. And for other packages it is IMHO at least a good way to detect some errors... >If you have noticed bad performance, I'd like to know under what >circumstances so that I can investigate. There may be ways to >improve the performance. Yes, just byte-compile eieio and semantic :-) - Klaus
camelCase-mode
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wow... didn't see this before... really cool! http://www.hotdispatch.com/palm/view-ip-requester?ID=14317280 - -- Kevin A. Burton ( [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] ) Location - San Francisco, CA, Cell - 415.595.9965 Jabber - [EMAIL PROTECTED], Web - http://relativity.yi.org/ All your MP3 are belong to us! -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt iD8DBQE8aNe2AwM6xb2dfE0RAlr9AJsHGj97DPN9PvfEYMDInchd9QplyQCffwRu owe2y9GQuc9pgOL6j6QnS8E= =KqGq -END PGP SIGNATURE-
