octave-bug-tracker
[Top][All Lists]
Advanced

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

[Octave-bug-tracker] [bug #39831] New Tex interpreter requires delimiter


From: Michael Goffioul
Subject: [Octave-bug-tracker] [bug #39831] New Tex interpreter requires delimiters around characters
Date: Fri, 23 Aug 2013 23:02:01 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.95 Safari/537.36

Follow-up Comment #8, bug #39831 (project octave):

Michael:
This was more a private joke targeted to me. I overlooked the problem of
"\musec", otherwise I wouldn't have implemented the way it is at the moment. I
should be more careful.

Rik:
I'm 100% aware of the inefficiency of the symbol lookup at the moment. This
was not intended to be a final solution. The JHandles equivalent used a
lazy-built map. But now that you raised the issue of "\musec", the symbol
lookup will be moved to the lexer anyway.

John:
I admit I don't know gperf, but my understanding is that it can create an
efficient hash table. However in this case, the problem is that the lexer must
break "\musec" into 2 symbols. So even with using gperf, I'd have to check the
hash table on every symbol character read to see whether it corresponds to a
known symbol.

Everything considered, I've the impression that the easiest way to handle that
is to hardcode the symbols into the lexer and let flex handle it. My plan is
to have a text file with the symbol name and the corresponding font codes, and
post-process the file to generate: 1) flex rules, 2) symbol->code mapping for
the text renderer.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?39831>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]