(10:19:47) <muntyan> um, it does sound nice
(10:19:52) <paolo> muntyan: the crash was in new code by me and pbor
(10:19:55) <muntyan> err, does not
(10:20:11) <paolo> why?
(10:20:27) <muntyan> vim is good, but why should we do anything to be like in vim?
(10:20:40) <pbor> morning guys
(10:20:48) <muntyan> pbor: hey
(10:20:59) <paolo> because there are a lot of color schemes available and we can so use them for our ones
(10:21:14) <paolo> and since they usage of default style is saner than our one
(10:22:02) <muntyan> the latter sounds like an argument, but the former doesn't
(10:22:52) <muntyan> do you want loads of crap like vim has? vim has zillion different things for every day and occasion, but it's not necessarily something good
(10:23:06) <muntyan> say, ten stock themes is too much
(10:23:18) <muntyan> and people will want emacs themes too
(10:23:19) <muntyan> and nedit
(10:23:23) <muntyan> and whateveredit
(10:26:08) <pbor> btw, I was thinking about the style schemes... why do we have styles in def.lang at all?
(10:26:19) <paolo> let me send you the new def.lang
(10:26:32) <paolo> I have also fixed the themes
(10:27:11) <paolo> pbor: to auto document basic styles
(10:27:21) <pbor> def.lang is never used directly and when people use foo.lang context IMHO they should specify the style
(10:27:53) <muntyan> pbor: what do you mean it's not used?
(10:28:08) <pbor> having styles in def.lang makes including def:foo without specifying a style work
(10:28:18) <pbor> which is bad IMHO
(10:28:32) <muntyan> um, it's not styles fault
(10:29:01) <muntyan> perhaps we should have parser use styles from lang automatically or something, but lang files to refer to def.lang styles in their styles, and taht's a good thing
(10:29:16) <muntyan> but what's wrong with what it is now?
(10:29:29) <muntyan> you want custom style, you use it5
(10:29:58) <pbor> nothing particularly bad, but it doesn't make much sense either in my opinion
(10:30:00) <paolo> what is "escaoe" style used for?
(10:30:11) <muntyan> paolo: escaped chars in strings
(10:30:16) <muntyan> "\t"
(10:30:25) <muntyan> pbor: what exactly?
(10:30:46) <pbor> for map-to you could simply use map-to="Comment" where Comment is one of the styles that themes should specify
(10:31:06) <pbor> instead of "def:comment"
(10:32:11) <muntyan> well, it's same thing, isn't it?
(10:32:19) <muntyan> except you say "comment" instead of "def:comment"
(10:32:31) <paolo> I think put them in def.lang is a good idea since in this way people will know what they could use without looking at the code
(10:32:56) <paolo> and let people repace their def.lang if they want
(10:33:23) <pbor> paolo: uh? why would one do that?
(10:33:36) <pbor> he should simply replace his scheme
(10:34:19) <muntyan> def.lang is like lang files, user shouldn't touch it :)
(10:34:25) <paolo> in theory a gtksourceview user can have a completely custom set of languages and its own def.lang
(10:34:50) <paolo> well, you can changing the search_path to not use the system one
(10:35:27) <pbor> muntyan: yes it's the same thing, except that if I include the def:string context I am forced to specify a style because def:string has no style associated by default. Which is a good thing in my opinion
(10:35:36) <muntyan> sure, he can. but it's not something he should do to change styles
(10:36:46) <muntyan> pbor: imo, ideally you don't use custom styles at all :)
(10:37:03) <muntyan> dunno, i like def: styles
(10:37:41) <pbor> ok
(10:39:24) <pbor> (it also forces def.lang to have styles which are not used in def.lang, which is something which instead we could forbid)
(10:40:16) <muntyan> removing styles from def.lang is the same as removing most map-to attributes. it's not good
(10:40:38) <muntyan> it's good that all strings look the same for free
(10:41:00) <muntyan> def: prefix makes sure you don't write "striing" or something
(10:41:20) <muntyan> and that you think better before inventing another-string style
(10:41:30) <muntyan> hopefully :)
(10:46:20) <paolo> BTW, here the my proposed def.lang
(10:46:21) <paolo> http://pastebin.ca/629425
(10:47:24) <muntyan> um, could we have less empty lines there?
(10:47:25) <muntyan> :)
(10:49:04) <muntyan> what's "special"?
(10:49:09) <muntyan> and "debug"
(10:49:20) <muntyan> and delimiter
(10:49:44) <paolo> the idea is that to define a scheme you only need to define the head of every group
(10:49:46) <muntyan> dunno, looks pretty bad to me
(10:49:49) <muntyan> very C
(10:49:58) <muntyan> very like-vim apparently ;)
(10:51:31) <muntyan> and why are deprecated things in there? we don't have to maintain compatiblity yet
(10:51:32) <paolo> delimiter is for example = in desktop files
(10:51:57) <paolo> well we need to fix all the .lang files before removing them
(10:52:35) <muntyan> removing them will help to fix .lang files
(10:52:37) <paolo> special is a generic special char, for example "%s" in a format string
(10:53:07) <paolo> sure, but fixing them require time
(10:53:30) <muntyan> um, underlined defaults to special for instance
(10:53:36) <paolo> why do you think is too C oriented
(10:53:37) <muntyan> there should be some logical relation
(10:53:49) <muntyan> and underlined is totally not %s in C format string
(10:54:12) <paolo> in fact most themes define underline
(10:54:15) <muntyan> C-oriented because of typedef, structure, storage-class
(10:54:28) <muntyan> themes may do anything, that's different story
(10:54:33) <paolo> java have them
(10:54:36) <paolo> c# too
(10:54:41) <muntyan> java isn't like C?
(10:54:43) <muntyan> or C#?
(10:55:03) <muntyan> they all are C children
(10:55:03) <paolo> well, many normally used languages are c-like
(10:55:10) <paolo> pascal have them too
(10:55:21) <muntyan> python, perl, html?
(10:55:54) <paolo> you have only you need for python, perl, html, etc.
(10:55:57) <muntyan> well, nevermind. thinking of it, it's a good thing to have C stuff in there
(10:56:04) <paolo> hmm... you have all you need
(10:56:19) <muntyan> still, special is bad
(10:56:29) <muntyan> there has been def:specials
(10:56:33) <muntyan> i've removed it :)
(10:56:41) <muntyan> because it doesnt' work
(10:56:42) <paolo> yep, special is too ambiguous
(10:56:50) <muntyan> people used it whenver color was okay
(10:57:11) <muntyan> and it's impossible to have some logical desicion on whether something is "special" or not
(10:57:31) <muntyan> you know that something is or is not a string, but "special"?
(10:58:05) <muntyan> same goes for "delimiter"
(10:58:45) <muntyan> those styles should be such that you could have an idea about what exactly will happen if you change some style
(10:59:04) <pbor> the Statement group is too finegrained IMHO
(10:59:04) <muntyan> e.g. you can guess what it means to change def:string style, or def:comment
(10:59:25) <pbor> we never separate "if" from "while"
(10:59:38) <pbor> so it makes no sense having separate style for those
(10:59:43) <muntyan> "identifier" doesn't look nice
(11:00:00) <muntyan> in fact "function" isn't nice too. it's used in different ways in lang files
(11:00:39) <paolo> pbor: new c.lang does
(11:01:11) <muntyan> pbor: because we can!
(11:01:36) <muntyan> dunno, it all looks like "huh?" to me
(11:01:41) <paolo> BTW, this is the reason we have a generic "keyword" style too
(11:01:44) <muntyan> very artificial
(11:01:57) <pbor> also the Type group looks excessive to me: we currently have "data-type" and that's all we need: static, register, volatile and typedef really do not belong in there
(11:02:22) <paolo> I do not agree,
(11:02:25) <muntyan> static does, we highlight it as types
(11:02:30) <muntyan> typedef doesn't
(11:02:45) <paolo> storage classes are important and should be highlighted in a different way from keywords
(11:03:27) <muntyan> storage classes should be highighted in the same way as types
(11:03:32) <muntyan> static char *foo;
(11:03:40) <muntyan> if static isn't like char you get a rainbow
(11:03:45) <pbor> yes, and C.lang should take care of that
(11:03:47) <paolo> what is artificial to me is distinguish between decimal, base-n-integer, complex
(11:03:52) <pbor> it's a very C specific case
(11:03:52) <paolo> they are all numbers
(11:04:14) <muntyan> it's important to distinguish floating point values and integers
(11:04:24) <muntyan> helps C coders write correct code
(11:04:29) <muntyan> double a = 2 / 3;
(11:04:30) <paolo> I agree for floating points
(11:04:40) <paolo> but not for decimal, base-n, etc.
(11:04:48) <muntyan> 012 is important to
(11:04:55) <paolo> it is a number
(11:04:57) <muntyan> it looks different and you know it's different
(11:05:02) <muntyan> 012 != 12
(11:05:05) <muntyan> yes it's numbers
(11:05:12) <muntyan> but they are different
(11:05:42) <paolo> well, at the same way I argue "static" is not "long"
(11:05:44) <muntyan> i like 0xdeadbeef highlighted in a different way than 123 :)
(11:06:40) <paolo> the problem is that currrent def.lang makes difficult to write schemes
(11:06:52) <paolo> we can reduce the number of fe
(11:07:00) <paolo> default styles
(11:07:18) <paolo> but I'd like to maintain the idea og using groups
(11:07:34) <muntyan> groups idea sounds nice
(11:07:44) <muntyan> but vim styles idea doesn't!
(11:07:49) *muntyan is a vim-non-lover
(11:08:03) <muntyan> if vim was good then it would be good and i would use it :)
(11:08:41) <paolo> ok, let us clean up the list of styles then
(11:09:01) <paolo> what do you want to remove?
(11:09:32) <pbor> let's go from top to bottom...
(11:09:33) <paolo> Comment group looks ok to me
(11:09:38) <pbor> comment group looks ok
(11:10:10) <paolo> From the constant group I'd remove: decimal, base-n, complex and special value
(11:10:27) <pbor> I really do not like the name "Constant"...
(11:10:46) <paolo> why? They are actually a constant
(11:11:08) <muntyan> how will you highlight NULL?
(11:11:15) <paolo> as a "Constant"
(11:11:26) <muntyan> as a string?
(11:11:55) <muntyan> string shouldnt' be there in constants, i guess
(11:11:56) <paolo> NULL is a generic constant
(11:12:02) <muntyan> and how can NULL be the same as numbers?
(11:12:10) <muntyan> NULL isn't a generic constant like 1
(11:12:27) <paolo> hmmm... it is a constant... like 0
(11:12:33) <muntyan> it's not
(11:12:42) <muntyan> no way it's the same
(11:12:43) <paolo> sure it is, look at how it is defined
(11:12:46) <muntyan> FALSE isn't 0
(11:12:49) <muntyan> TRUE isn't 1
(11:13:01) <muntyan> besides, NULL may not be 0
(11:13:03) <paolo> FALSE and TRUE are boolean
(11:13:04) <muntyan> it may be a pointer
(11:13:16) <muntyan> if we are going to that place
(11:13:28) <pbor> muntyan: note that most of the themes will actually define different styles for strings and NULL, but a minimalistic theme could just specify just a "constant" color
(11:13:38) <muntyan> pbor: and that would suck
(11:13:39) <paolo> exactly
(11:13:54) <paolo> lemme post a theme I have written
(11:14:01) <muntyan> pbor: strings and NULL highlighted in the same way works only if they are not highlighted at all!
(11:14:30) <paolo> http://pastebin.ca/629438
(11:14:48) <muntyan> if we think "good" schemes should define those styles, then there is no point to talk about minimalistic schemes by the way
(11:15:02) <muntyan> the important thing is "good" schemes
(11:15:18) <muntyan> they should be easy
(11:15:25) <muntyan> easy themes which suck are not important
(11:16:07) <paolo> my theme is very nice also if it is minimalistic
(11:16:35) <muntyan> if you define only groups it's nice?
(11:16:41) <paolo> yes
(11:16:48) <paolo> a part from string
(11:16:52) <muntyan> though you said NULL should be highlighted as 0, so we have different "nice" notions ;)
(11:17:10) <paolo> hehe
(11:17:41) <paolo> ok, let us maintain special-value
(11:18:06) <paolo> so we remove only decimal, base-n, complex?
(11:18:11) <paolo> ok?
(11:18:16) <muntyan> no way
(11:18:31) <paolo> you want all of them?
(11:18:31) <muntyan> um
(11:18:40) <muntyan> i am not sure about complex really
(11:18:46) <muntyan> i've never seen it in real code
(11:18:55) <muntyan> but decimal and base-n must be there
(11:19:01) <muntyan> really, 012 is important thing
(11:19:17) <muntyan> if you have highlighting, you start actually using the colors to parse text, you know
(11:19:38) <paolo> ok, let us remove only complex 
(11:19:56) <muntyan> then, everybody seems to have complex numbers...
(11:20:03) <muntyan> dunno, why not leave them all?
(11:20:24) <muntyan> there is no ambiguity so only bad thing is potentially more styles than needed
(11:20:31) <paolo> ok
(11:20:31) <muntyan> nobody will abuse or misinterpret it
(11:20:57) <paolo> but then we will also leave all the styles in the statement group
(11:21:04) <muntyan> heh, deal
(11:21:30) <muntyan> pbor: go get your piece too! you'll miss it now
(11:21:33) <paolo> and in all the other groups except to special
(11:22:48) <paolo> guys, I have to go in a few minutes
(11:23:02) <paolo> today my wife turns 31 and her grand-mother turns 100
(11:23:08) <muntyan> oh
(11:23:11) <muntyan> congratulations
(11:23:14) <paolo> sp we have a party here
(11:23:33) *muntyan had eight years of marriage yesterday
(11:23:55) <paolo> and I have to shower otherwise I will kill every person that will try to stay near me
(11:24:07) <pbor> heh
(11:24:10) <paolo> muntyan: congrats to you too
(11:24:24) <muntyan> come on, you're a hacker, hackers don't smell
(11:24:53) <paolo> hehe... hackers writing code with 31°C smell a lot
(11:26:01) <pbor> so, Identifier group looks ok to me... I'd add "builtin" since it's fairly common in our lang files
(11:26:33) <paolo> BTW, send me you comment by mail then I will try to make a proposal taking into account your comments
(11:26:55) <paolo> IMHO, the only group that really suck is special
(11:27:01) <paolo> the other ones are mainly ok
(11:27:07) <pbor> I do not like Special group instead... doc-comment-element etc should go in comment group
(11:27:13) <pbor> yep
(11:27:44) <paolo> bye
(11:27:48) <muntyan> could you send what you got first? or paste it
(11:28:06) <paolo> hmmm... what you mean?
(11:28:59) <paolo> I did not change anything for now
(11:29:09) <paolo> since there was no consensum in any change
(11:29:29) <paolo> so http://pastebin.ca/629425 is still the current proposal
(11:29:53) <paolo> if you want I can send you the complete patch with the new themes and some modification to the .lang files
(11:30:29) <muntyan> it'd be good
(11:31:00) <paolo> one minute
(11:31:29) <paolo> http://pastebin.ca/629443
(11:31:35) paolo is now known as paoloAFK
(11:33:14) *pbor still thinks that differnt hl for 'if' and 'while' is silly
(11:33:35) <muntyan> stock themes will have them the same, so ...
(11:33:36) <muntyan> :)
(11:33:51) <muntyan> it's good price for different 012 and 12 :D
(11:34:15) <pbor> heh
(11:46:20) <pbor> http://pastebin.ca/629455
(11:46:32) <pbor> that's what I would do
(11:46:42) <pbor> note that I killed specials
(11:47:52) <muntyan> i still don't like constants and strings married
(11:48:12) <muntyan> by the way, special-comment and friends shouldn't have map-to at all
(11:48:24) <muntyan> if they are supposed to be inside comments then they shouldn't have a style
(11:48:45) <muntyan> it just makes higlighting little more expensive
(11:48:51) <muntyan> it has to apply same style twice
(11:49:26) <pbor> ah ok
(11:50:51) <pbor> muntyan: btw, I was thinking again at that case-insensitive keywords thing: at the end imho the best think is having a keyword-list tag...
(11:51:20) <pbor> grouping keywords just makes more sense
(11:51:29) <muntyan> but they are already grouped
(11:51:31) <muntyan> inside the context
(11:51:40) <pbor> and the added verbosity is really little
(11:52:26) <pbor> personally I quite do not like the 'context' tag
(11:52:47) <pbor> and the fact that there are different contexts
(11:53:01) <pbor> and what kind of context depends on what is in
(11:53:14) <muntyan> if you add keyword-list it won't be any different, still a context, still depends on what's inside
(11:53:18) <pbor> and the attributes may or may not make sense depending on what is in
(11:53:23) <muntyan> bunch of keywords or keywords-list
(11:53:36) <muntyan> um, last point is a good point
(11:53:40) <muntyan> but extra tag sucks
(11:53:41) <muntyan> !
(11:53:54) <pbor> in general yes, but here is not that bad
(11:54:17) <pbor> keyword list are not very deep contexts so even indentation would be ok
(11:54:50) <pbor> and usually keyword list are fairly long, so the cost of one extra tag is not much
(11:56:21) <muntyan> it's harder to parse!
(11:56:36) <muntyan> all this for one case where context will have fancy attributes
(12:21:45) <paoloAFK> pbor: you proposal looks quite good to me, I have only a couple of questions:
(12:22:51) <paoloAFK> - if we maintain all the different type of numbers, I think we should also maintain the different types of keyword
(12:23:21) <paoloAFK> - what is builtin used for?
(12:23:31) <paoloAFK> - do you think we really need delimiter?
(12:25:32) <paoloAFK> hmmm... my network went down
(12:25:36) <paoloAFK> reposting
(12:25:40) <paoloAFK> <paoloAFK> pbor: you proposal looks quite good to me, I have only a couple of questions:
(12:25:40) <paoloAFK> <paoloAFK> - if we maintain all the different type of numbers, I think we should also maintain the different types of keyword
(12:25:40) <paoloAFK> <paoloAFK> - what is builtin used for?
(12:25:41) <paoloAFK> <paoloAFK> - do you think we really need delimiter?
(12:26:56) <paoloAFK> - I'm not sure structure is C-specific

(answer to the last questions)
pbor: "if we maintain all the different type of numbers, I think we should also maintain the different types of keyword", why? what is the relation? the fact that int and floats differ is real the fact that 'if' and 'while' differ is totally artificial.
pbor: "what is builtin used for?" to highlight special functions and objects that are part of a language, e.g. http://docs.python.org/lib/built-in-funcs.html
pbor: "do you think we really need delimiter?" I have no particular need for it, no particular opinion here