speechd-discuss
[Top][All Lists]
Advanced

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

speechd-el "modularity"


From: Milan Zamazal
Subject: speechd-el "modularity"
Date: Mon, 09 Aug 2010 16:39:21 +0200

>>>>> "PL" == Pierre Lorenzon <devel at pollock-nageoire.net> writes:

    PL>   For instance in the present implementation this part of code :

    >>>> -- CODE 

    PL>    (let ((i 0))
    PL>      (while (string-match "[\200-\377]" text i)
    PL>        (let ((char (string-to-char (match-string 0 text))))
    PL>          (if (memq (char-charset char)
    PL>                    '(eight-bit-control eight-bit-graphic))
    PL>              (setq text (replace-match (format "\\%o" char) t t text))
    PL>            (setq i (match-end 0))))))
    PL>    (let ((i 0))
    PL>      (while (and (> (length text) 0)
    PL>                  (string-match
    PL>                   "\\(\\`\\|\n\\)\\(\\(\\.\\).*\\)\\(\n\\|\\'\\)"
    PL>                   text i))
    PL>        (setq text (replace-match ".." nil nil text 3))
    PL>        (setq i (1+ (match-end 0)))))
    PL>    ;; We must remove text properties from the string, otherwise
    PL>    ;; Emacs does strange things when recoding non-ASCII
    PL>    ;; characters to UTF-8.
    PL>    (set-text-properties 0 (length text) nil text)


    >>>> -- End CODE

    PL> Appears in speechd--send-text called by speechd-say-text. If I
    PL> want to write my own speechd.text method I have to copy this
    PL> code without being able to call a function that implements it
    PL> separately.

I see, I understand now.  Sure, feel free to move such reuseable pieces
of code to separate functions, patches welcome.

    PL> It looks to me that if `speechd--send-request' were driver
    PL> dependent I'd only have to rewrite this method i.e. the way text
    PL> is sent to the server but not how the texte is pre-processed. In
    PL> fact I realize that it might be necessary to customize at both
    PL> levels since text pre-processing might also be driver
    PL> dependent. For instance this text pre-processing is not done for
    PL> braille drivers.

I think in this particular case it's indeed better to move the text
processing part to a separate function so that the primary job of
speechd--send-text remains just preparing the SSIP request.  If you need
to customize text processing inside the new function, just add
appropriate arguments to it as needed.




reply via email to

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