(12:01:11) Conversation with #gedit at 2006-09-10 120111 on pbor
(12:01:11) You joined #gedit
(12:01:11) topic on #gedit is: gedit needs your patches ;)
(12:01:11) topic on #gedit set by paolo at time Fri Aug 25 18:14:42 2006
(12:02:47) ozamosi (~ozamosi@85.8.9.80.se.wasadata.net) joined #gedit
(13:55:40) dra (~dra@p57A52275.dip0.t-ipconnect.de) joined #gedit
(14:12:57) nags (~nags@125.22.5.108) joined #gedit
(14:31:32) nud_ quit (Read error: 104 (Connection reset by peer))
(14:33:46) nud (~sf@212.224.130.24) joined #gedit
(14:38:19) ebassi is now known as ebassi|lunch
(14:51:40) nags quit (Linux Desktop Testing Project - http://ldtp.freedesktop.org)
(15:08:05) dra quit (Ping timeout: 600 seconds)
(15:23:00) dra (~dra@p57A5123C.dip0.t-ipconnect.de) joined #gedit
(15:34:21) paolo quit (Leaving)
(15:36:14) ebassi|lunch quit (Bored, now)
(15:48:47) Pat quit (Quit!!!)
(15:49:37) Pat (~pat@CPE-2-194.dsl.OntheNet.net) joined #gedit
(16:19:53) Beelzebub quit (Excess Flood)
(16:20:50) Beelzebub (~tombeers@i-83-67-91-133.freedom2surf.net) joined #gedit
(16:21:58) Pat quit (Remote closed the connection)
(16:23:37) Pat (~pat@CPE-2-194.dsl.OntheNet.net) joined #gedit
(17:27:46) ebassi (~ebassi@host81-153-177-169.range81-153.btcentralplus.com) joined #gedit
(17:56:37) madewokherd (~urk@VRP5000.rhbd.psu.edu) joined #gedit
(18:11:59) * _deepfire ~deepfire 80.92.100.69 * Samium Gromoff
(18:11:59) * _deepfire #gedit 
(18:11:59) * _deepfire ircd.gimp.org GIMPnet IRC Server
(18:11:59) * _deepfire End of /WHOIS list.
(18:12:07) * ozamosi ~ozamosi 85.8.9.80.se.wasadata.net * Robin Sonefors
(18:12:07) * ozamosi #gnome-love #nautilus #gedit #rhythmbox #gnome 
(18:12:07) * ozamosi irc.gimp.ca GIMPnet Canada - Hosted by Aceldama Systems
(18:12:07) * ozamosi 22161 1157882560 seconds idle, signon time
(18:12:07) * ozamosi End of /WHOIS list.
(18:12:24) * conufsed ~conufsed dsl-58-6-118-49.qld.westnet.com.au * Alan Harper
(18:12:24) * conufsed #gedit 
(18:12:24) * conufsed ircd.gimp.org GIMPnet IRC Server
(18:12:24) * conufsed End of /WHOIS list.
(18:12:30) * Beelzebub ~tombeers i-83-67-91-133.freedom2surf.net * Tom Beers
(18:12:30) * Beelzebub #abiword #epiphany #gedit #gimp #gnome #gtk-perl #gtk+ #unix 
(18:12:30) * Beelzebub irc.eagle.y.se GIMPnet VAX-Powered IRC Server
(18:12:30) * Beelzebub End of /WHOIS list.
(18:12:38) * ascii ~axel c-f195e255.125-3-64736c14.cust.bredbandsbolaget.se * Axel Liljencrantz
(18:12:38) * ascii #gedit 
(18:12:38) * ascii ircd.gimp.org GIMPnet IRC Server
(18:12:38) * ascii End of /WHOIS list.
(18:16:18) uwog is now known as uwogDinner
(18:46:44) paolo (~paolo@d83-184-231-41.cust.tele2.it) joined #gedit
(18:46:47) Burrito sets mode: +o paolo 
(19:12:47) uwogDinner is now known as uwog
(19:13:31) barisione (~demian@host2-224-dynamic.2-87-r.retail.telecomitalia.it) joined #gedit
(19:28:12) muntyan (~muntyan@pool-71-113-231-138.herntx.dsl-w.verizon.net) joined #gedit
(19:28:14) <muntyan> hi there
(19:28:24) <paolo> muntyan: barisione: pbor: all: hi
(19:28:39) <paolo> I'm working on the promised patch
(19:28:52) <paolo> I proposed to modify the .lang files in this way:
(19:29:19) <paolo>     <properties>
(19:29:21) <paolo>     	<property name="globs">
(19:29:21) <paolo> 		<value>*.c</value>
(19:29:21) <paolo> 		<value>*.h</value>
(19:29:21) <paolo>     	</property>
(19:29:21) <paolo>     	
(19:29:22) <paolo> 	<property name="brackets">
(19:29:24) <paolo> 		<value>(){}[]</value>
(19:29:26) <paolo>     	</property>
(19:29:28) <paolo>     </properties>
(19:29:33) <paolo> well, with the proper indentation
(19:31:12) <paolo> I'm parsing the the properties tag in parser-2.c
(19:31:16) <paolo> is this right?
(19:31:29) <muntyan> i hate it :)
(19:31:35) <muntyan> imagine ten globs
(19:31:36) <paolo> muntyan: why?
(19:31:57) <muntyan> i am cursing barisione and you all the time for the <include> tag
(19:32:04) <paolo> what do you propose?
(19:32:07) <muntyan> the less stuff the better!
(19:32:18) <muntyan> paolo: one single string for all the globs, like with mime types
(19:33:04) <muntyan> i guess something like <property name="globs">*.c;*.h</property> or <property name="globs" value="*.c;*.h"/>
(19:33:26) <paolo> well, you said on the mail you didn't agree on using a "<property name="globs" value="*.c;*.h">
(19:33:36) <muntyan> ?
(19:33:42) <muntyan> err
(19:33:48) <muntyan> how that is different from this?
(19:33:56) <nud> shouldn't you have one element per mime-type instead ? ^^
(19:34:09) <paolo> you said: "So gtksourceview user needs to do g_strsplit himself. Why?"
(19:34:20) <muntyan> nud: it sucks to write and read such things!
(19:34:27) <nud> muntyan: it sucks to read xml
(19:34:34) <muntyan> paolo: um, you don't have to do g_strstrip on list of mime types, do you?
(19:34:43) <muntyan> paolo: i meant *exactly* that ;)
(19:34:50) <paolo> no, since gtksourceview is doing it for you
(19:35:08) <paolo> but as I said you by mail I want to generic mechanism for properties
(19:35:16) <paolo> and so the API will be somethink like
(19:35:29) <paolo> get_property (name)
(19:36:00) <paolo> So using the approach I just proposed you will have
(19:36:36) <paolo> GSList *gtk_source_language_get_property (const gchar *name);
(19:38:15) <pbor> hi guys
(19:38:26) <paolo> BTW, since globs will be a "standard" property, we can impose as conventio to use a comma-separated list or any other format we want
(19:38:52) <pbor> btw, can we stop returning list in APIs ? I think we should return null terminated arrays
(19:39:01) <pbor> since they allow type safety
(19:39:31) <muntyan> pbor: kidding, huh?
(19:39:45) <paolo> I used GSList for API consistency
(19:39:50) <muntyan> pbor: you always cast char**
(19:39:54) <paolo> and also because I really prefer GSList
(19:39:58) <muntyan> pbor: because it's impossible to get const right
(19:40:09) <muntyan> pbor: and then your type safety goes to trash too
(19:40:36) <muntyan> (i admit it is nicer than GSList, but it's not *much* safer)
(19:40:38) <pbor> true, but slightly better then returning a list of void * pointers
(19:40:48) <muntyan> yes
(19:41:31) <muntyan> lists are easier to deal with, a single while(list) {list = g_slist_delete_link(list, list);} thing is pretty cool
(19:41:32) <paolo> BTW, these are details, what I'd like to know if you all agree on the general idea
(19:41:55) <muntyan> <paolo> BTW, since globs will be a "standard" property, we can impose as conventio to use a comma-separated list or any other format we want
(19:41:57) <muntyan> what do you mean?
(19:42:11) <muntyan> do you want a tag per glob, or all globs in one tag?
(19:42:29) <paolo> I mean that we can use
(19:43:02) <paolo> <property name="globs"><value>*.h;*.c</value></property>
(19:43:32) <muntyan> why extra "value" tag?
(19:43:34) <paolo> and then let the caller split the string
(19:44:11) <paolo> since "property" is generic and I'd like to support list of values for a property
(19:44:38) <pbor> if values are always strings the value tag seems excessive to me
(19:45:05) <paolo> they are not always strings
(19:45:12) <paolo> they can be lists
(19:45:13) <pbor> if instead it's a more generic properties thingie we may need a vay to specify different kind of values
(19:45:39) <paolo> no, I want a simple way to have metadata for .lang file
(19:45:48) <paolo> they don't need to be typed
(19:45:56) <paolo> but they could be multi-value
(19:46:37) <muntyan> um, let's see what values we have
(19:46:46) <muntyan> atm it's globs, brackets, and comments
(19:46:51) <paolo> exactly
(19:46:57) <muntyan> let's not make it bloat then!
(19:47:09) <muntyan> <value> tag is real nasty
(19:47:25) <paolo> globs are lists, brackets too (but probably a list is overkilling for them), comments are not a list
(19:47:31) <muntyan> i really hate <context> for having to use <include> (needed for RNG!!!)
(19:47:35) <muntyan> let's not do same thing for globs
(19:47:51) <muntyan> paolo: strings do just fine for all of them
(19:48:12) <paolo> well, but then the API will be
(19:48:24) <paolo> gchar *gtk_source_language_get_property (const gchar *name);
(19:48:45) <paolo> and users will have to use g_strsplit on the returned value
(19:48:50) <paolo> for globs
(19:49:02) <muntyan> well, IMHO, it's the same as we already have
(19:49:05) <paolo> if you agree, it is perfecly fine for me
(19:49:11) <muntyan> there is metadata tag, you can throw anything into it
(19:49:18) <muntyan> yes, you have to do extra parsing
(19:49:27) <paolo> but the metadata tag is not parsed
(19:49:30) <muntyan> yes
(19:49:44) <paolo> and I have removed it in my patch ;)
(19:49:46) <muntyan> paolo: i do not agree that globs hsould be something generic
(19:49:48) <muntyan> it is not!
(19:49:50) <muntyan> globs are globs
(19:50:04) <muntyan> paolo: what do you mean you removed it?
(19:50:10) <muntyan> paolo: you removed metadata?
(19:50:42) <paolo> yes, since they are in the .rng file but they are not  in .lang files or in .c file
(19:51:08) <paolo> or at least I cannot find tracks of code using them
(19:51:19) <paolo> may be I'm wrong
(19:51:20) <muntyan> right
(19:51:31) <paolo> so I removed metadata from .rng file
(19:51:33) <muntyan> there is RNG thing, which won't allow putting anything extra into lang file
(19:51:37) <muntyan> this is why metadata is there
(19:51:41) <muntyan> to allow any-extension
(19:51:57) <muntyan> metadata is exactly "whatever, gtksourceview doesn't care"
(19:52:09) <paolo> and added "properties"
(19:52:17) <paolo> that will be the same thing
(19:52:19) <muntyan> paolo: you can't nest properties
(19:52:21) <muntyan> it's not the same thing
(19:52:28) <muntyan> you are limiting possibilities
(19:52:32) <muntyan> for no gain
(19:52:46) <paolo> ok, if you want we can read metadata
(19:52:51) <muntyan> ?
(19:52:55) <muntyan> we don't need to read it
(19:53:00) <paolo> I don't care about them
(19:53:04) <muntyan> metdata should stay, and gtksourceview should not touch it
(19:53:08) <paolo> ok
(19:53:18) <muntyan> anyway, let's get back to globs
(19:53:22) <paolo> I removed them since I thought it was a left over
(19:53:45) <muntyan> if gtksourceview is not aware of globs, then there's *no* point in implementing this stuff (except for some hypothetical properties)
(19:54:01) <muntyan> if globs are not explicit in gtksourceview, then they don't get used
(19:54:04) <muntyan> and then, what's the point?
(19:54:13) <paolo> gtksourceview is not aware of globs at the same way it is not aware of mime-types
(19:54:30) <paolo> they will be in the .lang file
(19:54:32) <muntyan> ?
(19:54:34) <paolo> files
(19:54:39) <muntyan> right, in .lang files
(19:55:02) <muntyan> paolo: okay, let me put it this way. will there be gtk_source_language_get_globs or something?
(19:55:05) <paolo> and then we will provide an API to get a "property"
(19:55:09) <paolo> no
(19:55:14) <muntyan> then there's no point!
(19:55:22) <paolo> there will be a "gtk_source_language_get_property"
(19:55:38) <paolo> and you can do
(19:55:48) <paolo> globs = gtk_source_language_get_property (lang, "globs");
(19:55:51) <muntyan> paolo: i can *patch* it and be happy
(19:55:59) <muntyan> it'snot about physical possibility
(19:56:09) <muntyan> it's about having same lang file for whatever editor using gtksourceview
(19:56:22) <paolo> you will have
(19:56:34) <paolo> I really don't see why do you think it is different
(19:56:40) <muntyan> yeah, except that gedit won't support globs
(19:56:47) <muntyan> or will it?
(19:56:59) <paolo> it will support them
(19:57:26) <muntyan> okay, so everybody supports that, but there's no explicit api?
(19:57:49) <pbor> muntyan: see my mail
(19:58:09) <pbor> substantyally we want that data in lang files
(19:58:11) <muntyan> pbor: from today?
(19:58:23) <paolo> muntyan: yes and  no
(19:58:28) <pbor> no, the one from yesterday
(19:58:38) <paolo> in the sense that every .lang file in gtksourceview will have it
(19:58:46) <pbor> we want the data in lang files so that it's centralized
(19:58:50) <paolo> and every app will be able to use them
(19:59:09) <pbor> but we don't want the globs -> language resolution algorithm in gsv
(19:59:16) <paolo> but this does not mean every app will use them
(19:59:30) <paolo> at the same way apps are not obliged to use mime-types
(19:59:32) <muntyan> no freaking algorithm!
(19:59:37) <muntyan> guys, i go get a cigarette
(20:00:17) <muntyan> why are you talking about algorithm again and again? talking about policies, chrolicies, fuckicies, and whatnot. i want get_globs api!!!! no fancy algorithm
(20:00:37) <muntyan> i want gtksourceview to explicitely state that it is aware of real world, and that it provides this special data
(20:00:40) <muntyan> named "globs"
(20:01:49) <pbor> you do gsv_language_get_property("globs")
(20:01:57) <muntyan> mime type you are saying? text/x-copying makes sense? text/x-comma-separated-values is a file type? text/x-authors is a mime type?
(20:02:00) <pbor> is it so bad?
(20:02:00) <muntyan> err, file type
(20:02:16) <pbor> it's not about mime
(20:02:25) <muntyan> no, it's not
(20:02:29) <muntyan> i am looking at emails
(20:02:39) <paolo> it is a conventional name given to a file type
(20:02:59) <muntyan> it's a conventional name given to a given *file*
(20:03:06) <muntyan> there is no "authors" file type
(20:03:19) <muntyan> there is a mime type which is put onto AUTHORS file, true
(20:03:30) <muntyan> anyway, this is mime, screw it
(20:04:24) <pbor> as I said in my email gsv "mime" is just "language id"
(20:04:40) <pbor> chosing mime as language id may have its problem sure
(20:05:00) <pbor> but that's what we currently have
(20:07:05) <muntyan> i'm sorry, i get it too close
(20:07:32) <muntyan> pbor: if we talk about what mime type or isn't, we can start again. but it's irrelevant
(20:07:45) <muntyan> thing is: either globs exist and are special, or ignore them
(20:07:57) <paolo> why?
(20:08:10) <muntyan> it is easier, cleaner, better to not care about them at all than to invent some workarounds
(20:08:13) <muntyan> i think
(20:08:31) <pbor> muntyan: globs exist and are a property of the lang, what is bad about it
(20:09:00) <muntyan> nothing except they are not documented, i.e. hidden, and not used
(20:09:01) <pbor> most .lang files will have it and you can query them with gsv_language_get_prop("globs")
(20:09:11) <pbor> they will be documented
(20:09:26) <paolo> you said: "I don't care if it's a property or attribute or CDATA or comment as long as gtksourceview gets me the list of globs
(20:09:30) <muntyan> but there won't be api to get list of globs
(20:09:39) <muntyan> paolo: there will be api to get list of globs?
(20:09:41) <pbor> gsv_language_get_prop("globs")
(20:09:52) <pbor> what is the problem with it?
(20:10:12) <muntyan> well, now we are back to format ;)
(20:10:18) <paolo> nota the also brakets and comments will be property
(20:10:43) <paolo> properties are all the metadata that are not directly related to highlighting
(20:10:56) <paolo> you can query the property
(20:11:10) <paolo> some of them will have a document meaning (and format)
(20:11:27) <muntyan> paolo: globs are *directly* related to highlighting
(20:11:41) <muntyan> or, as related as mime types are
(20:11:44) <paolo> I mean they don't described what a language is
(20:11:53) <paolo> mime-types could be properties too
(20:12:24) <paolo> but I don't think moving them to properies is a good choice for the backward compatibility stuff
(20:13:09) <muntyan> ?
(20:13:36) <paolo> since we already have a function that most apps are using that assign to mime-types a very special meaning
(20:14:01) <paolo> and removing it we will break developers expectation
(20:14:53) <paolo> BTW, if you all agree mime-types should be a properties and we have to remove the "broken" get_language_for_mime_type function
(20:14:58) <paolo> it is ok for me
(20:15:36) <muntyan> removing?
(20:15:44) <muntyan> i don't get it
(20:15:56) <muntyan> paolo: why remove anything?
(20:16:21) <muntyan> mime types are fine; globs are needed for "bad" cases, and they *are* needed, that's it
(20:16:29) <paolo> since it is broken and since mime-types if they will be properties must be manages as the other ones
(20:16:35) <muntyan> did i say that we should not highlight shell scripts if they don't have .sh extension?
(20:17:00) <paolo> no, I'm not saying to remove "mime-types" information
(20:17:11) <paolo> I'm saying to manage them as all the other properties
(20:17:17) <muntyan> oh
(20:17:29) <paolo> mime_types = get_properties ("mime_types");
(20:17:45) <muntyan> and remove get_mime_types()? and get_language_for_mime_type()? 
(20:17:50) <paolo> yep
(20:18:05) <paolo> get_language_for_mime_type is broken 
(20:18:07) <muntyan> so, i'm not the only extremist in here, huh?
(20:18:09) <paolo> and cannot be fixed
(20:18:17) <muntyan> paolo: it's not broken
(20:18:22) <paolo> sure it is
(20:18:24) <muntyan> paolo: it does exactly what it says
(20:18:26) <muntyan> no it's not
(20:18:30) <paolo> gedit does not use it for that reason
(20:18:40) <muntyan> well
(20:19:25) <muntyan> while (mime) {if (lang = get_lang_for_mime_type(mime)) break; mime = mime_get_parent (mime);}
(20:19:27) <muntyan> is perfect
(20:19:48) <muntyan> i never expected get_lang_for_mime do some nice job, so i don't have problems with it ;)
(20:20:11) <muntyan> fo rme, get_lang_for_mime() is "find it in your internal hash table so i don't bother with lists and stuff"
(20:20:18) <paolo> this proves that it is broken
(20:20:53) <muntyan> paolo: okay, let it be broken
(20:21:00) <muntyan> now, what does gtksourceview user do?
(20:21:04) <nud> does gtksourceview determine the file type itself ?
(20:21:15) <nud> or do you have to provide it to it ?
(20:21:26) <paolo> nud: the second
(20:21:36) <muntyan> <feesh> hey, muntyan I promise never to bother you ever again but hehe, I've got gtksourceview in my app now (woohoo!) it does the bracket matching, but no highlighting
(20:21:38) <pbor> nud: no it doesn not know nothing about files
(20:21:44) <paolo> muntyan: you have to get the list of mime-types and do your own match
(20:21:45) <muntyan> now, what do i tell that guy?
(20:21:51) <pbor> nud: that's the whole point of the discussion
(20:21:52) <muntyan> "break your head"?
(20:22:01) <muntyan> paolo: it's *silly*
(20:22:09) <paolo> why?
(20:22:17) <muntyan> paolo: because gtksourceview can do it easily!
(20:22:17) <paolo> it cannot do a sane matching
(20:22:24) <paolo> no, it cannot
(20:22:26) <muntyan> who's talking about "sane"?
(20:22:37) <muntyan> i'm talking about "go through the list", exactly what it does
(20:22:39) <paolo> it does not nothing about mime-type hierarchy
(20:22:43) <nud> paolo, pbor: ok, I wasn't sure
(20:22:46) <muntyan> it does exactly right job
(20:22:48) <paolo> s/not/not know
(20:22:50) <muntyan> paolo: i know
(20:23:11) <paolo> come one,  it is only a cycle with a strcmp
(20:23:21) <nud> so what would be wrong with just setting mimetypes as props ?
(20:23:26) <muntyan> yep, this is why there should be a hash table
(20:23:49) <paolo> hash table?
(20:23:52) <pbor> muntyan: how whould that work for globs anyway? get_language_for_mime is broken but useable
(20:24:01) <muntyan> paolo: yeah, mime type -> language
(20:24:07) <muntyan> pbor: globs are usable too
(20:24:12) <pbor> but for globs 'first match wins' doesn't make sense
(20:24:14) <muntyan> pbor: and here come the priorities :)
(20:24:37) <muntyan> Makefile* must win over *.whatever_extension
(20:24:45) <muntyan> and this is what gtksourceview should take care about
(20:24:58) <muntyan> it can't know file type, but it does know what's in lang files
(20:25:01) <paolo> no, file type matching is not the role of gtksourceview
(20:25:28) <muntyan> i guess the easiest would be to make gtksourceview depend on gnomevfs and stop this nonsense
(20:25:31) <muntyan> how about this?
(20:25:32) <pbor> take .m, gsv will never be in a position to chose the correct language
(20:25:36) <paolo> muntyan: no
(20:25:43) <pbor> no vfs wpuld not help
(20:25:56) <muntyan> ?
(20:26:14) <muntyan> pbor: that's why mime types should have higher priority
(20:26:14) <pbor> only the author of the app knows if he's writing a matlab editor or a objective-c editor
(20:26:23) <paolo> muntyan: a lot of people asked us to remove gnome-vfs and libgnomeprint dependencies in the past
(20:26:35) <muntyan> pbor: but gtksourceview can answer a simpler question: "given we are doing glob matching, what would yuo choose?"
(20:27:01) <paolo> as I said it is not up to gtksourceview performing file type matching
(20:27:08) <paolo> it is app to application
(20:27:11) <muntyan> paolo: but users want it!
(20:27:18) <muntyan> users want to "highlight this file"
(20:27:26) <muntyan> most users are not writing a text editor
(20:27:33) <paolo> and they will have with my proposal
(20:27:55) <muntyan> yeah, they just have to learn gnomevfs to get mime type; then they have to do some string matching
(20:27:58) <nud> you can just give two functions getlanguagefromfilename and getlanguagefrommimetype
(20:28:00) <muntyan> piece of cake
(20:28:00) <paolo> without adding to gtksourceview code it does not belongs to it
(20:29:07) <paolo> apps will have to write some simple code to do it
(20:29:12) <muntyan> anyway, if mime types go to a property, it would be silly to argue that globs need special attention, wouldn't it?
(20:29:19) <muntyan> paolo: show me the simple code!
(20:29:24) <muntyan> there is no *simple* code
(20:29:30) <muntyan> it's really nasty hard stuff
(20:29:40) <muntyan> are you highlighting bak files properly?
(20:29:49) <muntyan> or you suffer from xdgmime too?
(20:30:07) <paolo> the problem must be solved in xdgmime
(20:30:11) <paolo> not in gtksourceview
(20:30:21) <paolo> they are different libs with different roles
(20:30:35) <muntyan> paolo: this translates to 'not my business, deal with it yourself"
(20:30:47) <paolo> exactly
(20:30:53) <muntyan> in real life file.c~ *must* be highlighted as C file, right?
(20:31:03) <paolo> at the same it is not my business to save/load files
(20:31:23) <nud> we could just provide a libgedit along with gtksourceview
(20:31:28) <muntyan> saving/loading is very hard
(20:31:37) <muntyan> much harder than getting language for a file
(20:31:41) <muntyan> er
(20:31:55) <paolo> may be we should, but we are developing a widget here not a full library to write text editors
(20:31:59) <muntyan> i mean, it's really reasonable to make gtksourceview able to get language for a file
(20:32:15) <nud> for useful widgets, and to avoid anjuta guys to copy the whole gedit code
(20:33:07) <paolo> may be in the future we will be able to add other functions and capability to the lib to make it a code editor in a lib
(20:33:13) <paolo> but we are not ready to do it now
(20:33:32) <muntyan> get_language_for_somethign is not exactly that ;)
(20:34:00) <paolo> get_language_for_something requires dependencies on other libs like gnome-vfs or xdg-mime
(20:34:16) <paolo> they are not portable and I don't want to depend on them
(20:34:22) <muntyan> from pbor email
(20:34:24) <muntyan> This leaves the possibility of add mapping inside every program using
(20:34:24) <muntyan> gtksourceview: the problem with this approach are pretty evident: code
(20:34:24) <muntyan> duplication, hardcoded mapping, different behavior for different apps
(20:34:24) <muntyan> and so on.
(20:34:40) <muntyan> if gtksourceview only provides a list, we have that problem
(20:34:52) <paolo> I have to go now
(20:34:54) <paolo> sorry
(20:35:04) paolo is now known as paoloAFK
(20:36:32) <muntyan> removing everything is a good option, but removing it because gedit stopped using it is...
(20:36:57) <paoloAFK> BTW, I think we found an arrangement with the mails of this morning and now I'm very disconcerted by this new discussion
(20:37:09) <pbor> muntyan: the point is, we agree that having gobs information centralised in lang files is good, so lets stick to the point and choose an appropriate format
(20:37:26) <paoloAFK> I'm really off now
(20:37:28) <paoloAFK> bye
(20:37:33) <muntyan> pbor: well, the *api* is important too
(20:37:42) <muntyan> and now we get mime stuff removed too
(20:37:49) <muntyan> so, i don't know :)
(20:37:58) <muntyan> format must be simple!
(20:38:06) <pbor> then let's provide a way for the apps to get all that information and do their choice of .lang
(20:38:08) <muntyan> not more than one line for globs
(20:38:52) <muntyan> pbor: but look, there are many applications which uses gtksourceview simlpy to "highlight a file". they won't do this complex find-right-lang stuff
(20:38:58) <pbor> I think <properties><property name="globs">*.c;*.h</></> is ok
(20:39:04) <muntyan> it doesn't hurt me personally, indeed
(20:39:40) <pbor> I think keeping the current get_for_mime is ok
(20:39:58) <muntyan> it's broken!
(20:40:01) <muntyan> :)
(20:40:02) <pbor> even if it is "broken" it's reasonably easy
(20:40:14) <pbor> and the brokeness can be documented
(20:40:19) <muntyan> yep
(20:40:31) <pbor> but get_for_globs() is a slippery slope IMHO
(20:41:01) <pbor> doing 'first match wins' is way more broken than with mime
(20:41:03) <muntyan> with priorities it's not that bad
(20:41:16) <muntyan> priorities, priorities...
(20:41:28) <pbor> so I think the api could look like:
(20:42:05) <pbor> get_languages_matching_properties("globs", glob, "mime", mime, ...)
(20:42:21) <pbor> and it returns a list/array of languages that match
(20:42:40) <pbor> then the program can do whatever he please
(20:42:41) <muntyan> it's not good
(20:42:53) <muntyan> parent mime types is still a problem
(20:42:57) <pbor> either take list->data (first match win)
(20:43:01) <muntyan> application needs to try mime types first
(20:43:12) <pbor> or do more correct evaluation of the info
(20:43:15) <pbor> sure
(20:43:28) <pbor> a "serious" program can do
(20:43:30) <muntyan> and gtksourceview won't return language for parent mime type
(20:43:37) <muntyan> hm
(20:43:49) <pbor> get_languages_matching_properties("mime", mime)
(20:44:07) <pbor> and then redo it for the parent mimr
(20:44:08) <muntyan> it can't be this
(20:44:13) <pbor> *mime
(20:44:20) <pbor> like it is now
(20:44:30) <muntyan> but get_language_simple_for_stuff() that you said sdoes sound nice
(20:45:07) <muntyan> pbor: you can't give it a glob, you need to give it a filename
(20:45:22) <pbor> note that I said get_language*s*
(20:45:33) <muntyan> yes
(20:45:34) <pbor> I don't want gsv to pick
(20:45:44) <pbor> I want to let the app pick from a list
(20:45:46) <muntyan> get_languages_simple_for_stuff
(21:19:46) dborg (~daniel@e182051028.adsl.alicedsl.de) joined #gedit
(21:32:03) ebassi quit (Ping timeout: 600 seconds)
(22:24:37) You are now known as pbor|out
(22:31:49) paoloAFK quit (Leaving)
(22:31:53) mattmatteh (~matt@d192-24-166-89.nap.wideopenwest.com) joined #gedit
(22:32:43) <mattmatteh> is there a way to find out why gedit crashed ?  like a log or back trace?  i was just using it and it stalled and then crashed while selecting and pasting
(22:33:28) <nud> bug buddy gives you a stacktrace
(22:33:47) <nud> or you can attach a gdb instance to your gedit before it crashes
(22:35:00) <mattmatteh> bug buggy ?
(22:35:24) <mattmatteh> well, thats where i am stuck, i dont know if i can reproduce the crash.
(22:36:24) <nud> bug buddy is the small app that tells you an app just crashed
(22:37:03) <mattmatteh> i only got a window that it crashed.  hmmm, did i miss an option to see the stacktrace ?
(22:37:51) <nud> in its latest question, it asks you what you were doing when the app crashed
(22:38:03) <nud> and then adds an entry to bugzilla including the stacktrace
(22:38:14) <nud> there is a button to see it from bb
(22:38:32) <mattmatteh> hmmm
(22:38:37) <mattmatteh> ill have to remember that
(22:39:13) <mattmatteh> when it happened i was rather pissed about it, since i lost my code for the last few min.  ( i save often anyway)  
(22:39:24) <mattmatteh> so i obviously missed it
(22:39:32) <mattmatteh> thanks, i remember next time
(22:40:55) <nud> well, usually a crash isn't expected
(22:41:17) <nud> anyway, you can look in bugzilla, for the latest crashers
(22:41:28) <nud> and see if one corresponds to what happened to you
(22:42:53) ebassi (~ebassi@host81-153-177-169.range81-153.btcentralplus.com) joined #gedit
(22:43:20) <mattmatteh> k, thanks
(22:55:32) ebassi quit (Ping timeout: 600 seconds)
(23:05:08) ebassi (~ebassi@host81-153-177-169.range81-153.btcentralplus.com) joined #gedit
(23:07:04) Pat quit (Quit)
(23:11:36) Pat (~pat@CPE-2-194.dsl.OntheNet.net) joined #gedit
(23:18:03) Pat quit (Leaving)
(23:19:02) Pat (~pat@CPE-2-194.dsl.OntheNet.net) joined #gedit
(23:56:27) barisione (~demian@host2-224-dynamic.2-87-r.retail.telecomitalia.it) left #gedit
(00:20:42) Duke` quit (Fatal signal: Segmentation Fault)
(00:32:10) jessevdk quit (Ik ga weg)
(00:51:19) mat quit (mat)
(00:53:05) dborg_ (~daniel@e182049235.adsl.alicedsl.de) joined #gedit