Low level trickery for changing character syntax?

[Thorsten Jolitz]

Hi List, 

assume an imaginary elisp library gro.el I cannot (or don't want to)
change that is used on files of type A, with functions matching these
kinds of strings:

#+begin_src emacs-lisp
  (defconst rgxp-1 "^[*] [*]Fat[*]$")

  (defun foo (strg)
    (and (string-match "^\\*+[ \t]* \\*.+\\*" strg)
         (string-match rgxp-1 strg)))
#+end_src

#+results:
: foo

#+begin_src emacs-lisp
(foo "* *Fat*")
#+end_src

#+results:
: 0

#+begin_src emacs-lisp
(foo "+ *Fat*")
#+end_src

#+results:

Now assume I want to use gro.el functionality on files of type B
such that it matches strings likes this:

#+begin_src emacs-lisp
(foo "// # *Fat*//" )
#+end_src

In short, when called from file.type-A, I want foo to match "// #
*Fat*//", while it should only match "* *Fat*" when called from
file.type-B (without changing foo or rgxp-1).
 
Thus in rgxp-1 and in foo, "^" would need to be replaced with "^// ",
the first "*" would need to be replaced with "#" (the other occurences
not), and "$" would need to be replaced with "//$".

Now I wonder what would be the best way (or at least a possible way) to
achieve this with Emacs low-level trickery (almost) without touching
gro.el. I don't enough know about syntax table low-level stuff besides
reading the manual, so these are only vague speculations:

 1. Change the syntax-table of gro.el whenever it is applied to files of
 type B such that "^" is seen as "^// ", "*" as "#" etc.?

 2. Define new categories and put "^" "*" and "$" in them, and somehow
 load/activate these categories conditional on the type of file gro.el
 functionality is called upon. These categories should then achieve that
 "^" is seen as "^// " etc when the categories are loaded?

 3. Define "^" and "$", when found at beg/end of a string, as 'generic
 comment delimiter, and define "/" as generic comment delimiter too, such
 that "^//" and "//$" are matched by "^" and "$"?

I know that these ideas do not and cannot work as described, but I'm
looking for a hint which idea could possibly work? What would be the way
to go? 

Or is this completely unrealistic and the only way to achieve it is to
change the hardcoded regexps in (imaginary) library gro.el?

-- 
cheers,
Thorsten