(09:59:02) <pbor> muntyan: so in practice you need the reverse of <includes>?
(09:59:19) <muntyan> something like that, yes
(10:00:01) <muntyan> kate's xslt file doesn't use xml
(10:00:12) <muntyan> i have no idea what vim and etc do
(10:02:06) <pbor> maybe we can add <extends ref="xml:element"> ?
(10:02:42) <muntyan> you look at xml:element first :)
(10:04:22) <muntyan> maybe some stuff resolved in runtime. like some <context to-be-defined="foo"> in xml.lang, and then another lang files may specify foo
(10:04:53) <muntyan> it's fine if this "injection" requires cooperation from original lang file
(10:05:04) <muntyan> main thing is to make lang files easy and clear
(10:05:22) <muntyan> and whole thing implementable :)
(10:05:56) <pbor> dunno, I think I would prefer if you could 'hook' into a context generically
(10:06:11) <pbor> but, sure 'implementable' is a requirement :)
(10:06:41) <muntyan> well, if you know how to inject anything into anything, it's okay too
(10:06:54) <muntyan> i can't imagine how to specify target contexts. using paths is ugly and won't work
(10:07:24) <pbor> what you mean?
(10:07:37) <pbor> I was naively thinking of:
(10:07:38) <muntyan> i don't really know
(10:08:04) <pbor> <context foo extends="xml:elemnt">...
(10:08:21) <muntyan> but extends how?
(10:08:40) <muntyan> you don't want to insert stuff after existing contexts, for instance
(10:08:51) <muntyan> and you may not want to insert them before either
(10:08:56) <pbor> would be equivalent to having
(10:09:06) <pbor> <xml:element>
(10:09:10) <pbor> <includes>
(10:09:12) <pbor> <foo>
(10:10:25) <muntyan> it's no good. for example, first included context may be a comment, and you don't want your keyword to be matched before comment
(10:10:43) <muntyan> well, comment and keyword is not a good example, but there are weird cases
(10:10:50) <muntyan> maybe ignore weird cases?
(10:10:57) <pbor> heh
(10:11:16) <pbor> extrends-before extend-after :)
(10:12:21) <pbor> or we could mandate that xml lang should include a special <hook> element where extenders can hook in
(10:15:47) <pbor> maybe: we should keep things simple and grow from there:
(10:16:46) <pbor> first we simply add "extends", if it's not enough we add "extends-after" and if it's still not enough we add "extends-at=hook-id"
(10:18:33) <pbor> what matter is, would the <xml:element><includes><docbook:foo>... result be enough to provide proper highlighting?
(10:24:36) <muntyan> good question :)
(10:24:55) <muntyan> i have no idea how to highlight some special tag names
(10:25:00) <muntyan> anyway, how would lang file look like?
(10:25:46) <muntyan> with the "extends" thing
(10:26:47) <nud> what about placeholders the way gtkui does ?
(10:26:56) <nud> maybe not very pretty
(10:26:59) <muntyan> gtkui?
(10:27:37) <nud> gtkuimanager
(10:27:44) <pbor> well, my 'hook' thingie is pretty much the same of placeholder
(10:28:19) <muntyan> um, in gtkuimanager you are specifying full path to stuff and pray that the order is right, correct?
(10:28:20) <nud> btw pbor don't forget to look at my patch ;-)
(10:28:31) <nud> yes
(10:28:51) <nud> it causes weirdness when you use code comment and indent together
(10:30:24) <nud> otherwise <insert after="foo:bar"><context blah></insert> ?
(10:32:27) <pbor> well, we can tweak the xml syntax how we want, what does it matter is if injecting contexts in the xml:element context is enough
(10:35:49) <muntyan> well, it's the only thing you can do in lang files - create a context and insert other contexts into it
(10:37:27) <pbor> ok
(10:37:57) <pbor> then the syntax should probably be something like:
(10:38:46) <pbor> <context if='foo' extends='xml:bar>
(10:39:11) <pbor> <hook where='before'>.... </hook>
(10:39:37) <pbor> <hook where='after'>...<...>
(10:39:40) <pbor> etc
(10:39:44) <muntyan> what does "if" mean?
(10:39:51) <pbor> id
(10:40:00) <muntyan> ah
(10:40:03) <pbor> off by one :)
(10:40:47) <pbor> obviously feel free to pick better terms of 'extends', 'hook', 'where' etc
(10:41:23) <muntyan> i'm trying to understand how to parse it
(10:41:50) <muntyan> parser is stupid, it doesn't know what it parses. it sees a thing and does engine_do_thing()
(10:42:03) <muntyan> and engine obviously can't be clever, so it's stupid too
(10:42:23) <muntyan> hm
(10:42:23) <pbor> well, in the main docbook conetxt you would have 'includes foo' right?
(10:42:34) <muntyan> ?
(10:42:57) <pbor> <context id='docbook'><includes><context foo>
(10:43:17) <muntyan> um, if foo is supposed to be that hook, then of course no
(10:43:37) <muntyan> it will be some <context id='docbook'><include><context ref="xml:xml">
(10:43:49) <pbor> mmm
(10:43:57) <pbor> that is not the way I was thinking it
(10:45:35) <pbor> I was thinking <includes><context foo>, then when you resolve it you see that foo is specified as extends=xml:element, so you treat it like it was 'includes xml:element' except you add the child contexts of foo to xml:element
(10:46:34) <muntyan> no, that "xml:element" is included by "xml:foobar" which is included by "xml:whatever"
(10:46:55) <muntyan> you don't want to repeat content of xml.lang
(10:47:12) <pbor> right