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