[lug] XEmacs quoting madness!

[Tkil]

>>>>> "dajo" == dajo  <David> writes:

dajo> I agree with a lot of what you write, I need to re-read the rest
dajo> to understand it.  In fact I do the things above to some degree
dajo> already.

dajo> If you (and this is open to others on the list) would like to
dajo> pursue the design and implementation of a regexp package for
dajo> emacs (maybe it could become language independent) then I would
dajo> be interested in taking part.  

i think that you're discussing writing a regex-generating package,
yes?  that's a bit different from saying "regex package", which tends
to imply (at least to my ears) that you're implementing a regex
engine.

i'd probably not be interested in such a package, for the simple
reason that i don't think i could improve over the fundamental regex
syntax.  (it might also be that i'm sufficiently immersed that i think
even wretched syntax is as good as it gets, since i do understand it.)

in cases where i need more help assembling regexps, the languages i
use offer lightweight support for doing so.  admittedly, there's a
small amount of code duplication that goes on here; if i used it
often, i'd consider packaging it.  but that's the trick: i don't use
it often enough to allocate neurons to learning yet another regex
dialect.

on the other hand, it might be useful for "translating" regexps from
one dialect to another; as Tom points out, there's the completely
equivalent forms of "(", "|", and ")" that are just written
differently in perl or emacs regexps.  

then again, how do you translate features from one engine to one that
doesn't support those features?  i'm thinking of the perl extensions:
non-saving groups, non-greedy quantifiers, limited case
(in)sensitivity, etc.

i don't think there's anything wrong with the idea, really; note that
i used "i" everywhere above, because i'm aware that this is all my
opinion.

dajo> I am sure that we disagree enough to push a boundary or two.

a most diplomatic way of phrasing it.  :)

anyway.  i don't think i'm interested in spending much time on this,
but i'd be curious to see what you come up with if you do go down this
path.

in a similar vein, there are a few "sql query builders" available for
perl; i find that they're generally more annoying to use than raw SQL,
but they probably would have saved me much time when i migrated from
informix to oracle -- the thought of being able to just mark a table
as "outer", without having to change all the conditions in a join, is
a nice one.  again, though, we have the feature mismatch: temp tables
are managed very differently between these two databases, and outer
joins can be finer-grained in oracle than in informix.  *shrug*

t.