[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


Hi Raman,

I'm still working on the emacspeak-sql replacement which works with
Alex Schroder's version of sql.el mode that comes with emacs 21. Its
coming together pretty well and I will send you a copy once I'm
confident it is working well and I've "voiceified" all the necessary
functions etc. 

There is one problem which remains which I have not been able to
resolve yet. As I mentioned on the list a couple of weeks back, there
is a problem with font-lock in sql-mode buffers once an
sql0interactive-mode buffer has been created which causes all the text
from any -- (dash, dash) comments to the end of the buffer to be put
into font-lock-comment-face when only the characters to the end of the
line should have this attribute set. This only happens if you are
running emacspeak and it occurs both under X and under a console. It
also happens if there is nothing in emacspeak-sql.el except a
(provides 'emacspeak-sql) line, so its not a problem with the code in

I have found a "solution" which appears to stop this problem. However,
because I still don't really know what the cause is, I'm not confident
this solution will always work and don't really know why it does. The
solution is to put the following in the sql-mode hook

(add-hook 'sql-mode-hook (function
  			  (lambda ()
  			    (setq font-lock-defaults
  				    nil t
  				    ((?_ . "w")
  				     (?. . "w")
  				     (?- . ". 12b")
  				     (?\n . "> b")))))))

The only difference between the font-lock-defaults I'm setting via the
load hook and the ones Alex uses in sql.el is that I have added the
syntax modifications to include the double dash comment marker, which
Alex does within his code as part of the sql-mode-syntax-table
modifications. I've tried to check the attributes of characters both
with and without my load hook additions (using functions like
describe-char-after and list-properties-at) and have not been able to
identify any differences. Even when the whole buffer gets incorrectly
fontified as a huge comment, C-j shows up as an end of comment

I suspect the problem is somehow related to comint mode and something
emacspeak does in this mode as it only occurs after starting the
comint based sql-interactive-mode buffer and it oly happens when
emacspeak is loaded. although a guess at this stage, but its possible
that it has something to do with codeing systems, unwanted interaction
with built-in mule support that seems to be in all the emacs builds on
many distributions or something which gets changed during one of the
comint load hooks (which is what I'm looking at now). 

I did ask on the list if anyone else is using sql mode and if they
have noticed similar problems with font-lock and emacspeak, but did
not recieve any responses. I have contact the author of sql-mode and
he has had no reports of any problems. I have found the problem occurs
under emacs21 built for both debian, redhat and madrake systems and I
believe I noticed the same problem when running emacs 20 as well. 

If you or anyone else on the list has any ideas on things to look at -
especially if they are related to interactions between emacspeak and
comint derived modes, I would certainly appreciate it.


Tim Cross					E-Mail: tcross@pobox.une.edu.au
Analyst/Programmer                               Phone: 6773 3210
Applications Group			        Mobile: 0412 969193
University of New England
find / -iname microsoft -exec rm -rf {} \;

To unsubscribe from the emacspeak list or change your address on the
emacspeak list send mail to "emacspeak-request@cs.vassar.edu" with a
subject of "unsubscribe" or "help"