<tberman> yah
<tberman> its no issue right now
<tberman> ive already created a bit of a custom wrapper to do my dirty work
<paolo> what about 130220? Can we close it?
<gustavo> don't know, we should check the xhtml spec
<paolo> yep
<paolo> I don't see other important (and fixable) bugs
<paolo> So, to summarize:
<paolo> - you will try to fix: #133887, #114666 (?), and you will give a look at the priority problem
<paolo> - I will fix  #120350 and eventually #128223 if the priority problem will be fixed
<paolo> is it ok?
<paolo> have I missed some bugs?
<gustavo> no, i think that's it
<paolo> ok
<paolo> How is the work on the new engine going?
<gustavo> slow
<gustavo> i haven't done much yet
<paolo> hehe, np
<paolo> have you time to discuss the smart indent thing?
<gustavo> sure
<paolo> lemme takes my notes
<gustavo> hmm... i'll lower the severity of 132525, since it can be worked around
<paolo> ok
<paolo> ok, I think we should define an "indenter" interface that implements a single method
<paolo> gint smart_indent (GtkSourceIndenter *indenter, 
<paolo>                    GtkSourceBuffer   *buffer,
<paolo>                    gint               line,
<paolo>                    gunichar           last_char);
<paolo> A new function
<paolo> void gtk_source_buffer_set_smart_indenter (GtkSourceBuffer   *buffer,
<paolo>                                            GtkSourceIndenter *indenter);
<paolo> set the indenter for a GtkSourceBuffuer object
<paolo> every time new text is inserted by the user in an interactive way
<paolo> (i.e. no file loading, no paste, etc)
<paolo> The GtkSourceBuffuer object call the smart_indet function of the associated indenter
<paolo> the smart_indent function returns the number of spaces to be inserted before the first visible char of the current line
<paolo> (like the indent function in vim)
<paolo> questions?
<gustavo> what's the last_char parameter in smart_indent?
<paolo> is the last char inserted by the user
<paolo> lemme explain with an example:
<paolo> if the user press 'e', gtksourcebuffer insert the 'e' text at the cursor position and then call smart_indent using 'e' as last_char
<paolo> why is it useful?
<paolo> smart_indent function should change it behavior according to the value of last_char
<paolo> for example in the indeter for the C language
<paolo> smart_indent returns immediately returning -1 if for example last_char is "l"
<paolo> but if last_char is "e" it checks if it is the second 'e' of an "else" statement
<paolo> and eventually indent it
<paolo> if the last_char is \n it indent the new line, etc
<gustavo> so, the indenter would indent as you type, according on what you're typing
<paolo> look at "indentkeys" in vim
<paolo> gustavo: yep
<paolo> for example the C indeter would indent the text if:
<paolo> you type '{' as the first character in a line
<paolo> you type '}' as the first character in a line
<paolo> you type ')' as the first character in a line
<paolo> you type ':' after a label or case statement
<paolo> if you type '#' as the first character in a line
<paolo> if you type a <CR> anywhere
<paolo> if you type the second 'e' for an "else" at the start of a
<paolo>   line
<gustavo> right
<tberman> so you have it returning the number of spaces
<tberman> what if you are using tabs?
<paolo> yep
<paolo> the gtksourceview will change it in the right sequence of tabs and spaces
<tberman> ah, cool
<tberman> but then if i wanted to give it a tab indent level of 2
<tberman> would i have to do 2 * something or just return 2
<paolo> 2 * tab width
<tberman> why not just do a return for the tab level you want the line at
<paolo> because you may want to use spaces (like in gtk+)
<tberman> which brings me to point #2, it would be nice if there was a way to get the tab level of a line
<tberman> yah, but then sourceview should turn tabs into spaces for you
<paolo> it is not the same
<paolo> suppose to have a stupid autoindent intenter that simply put the new line
<paolo> at the same level as the previous one
<paolo> if the previous one start with "3 spaces" and tab with is "8"
<paolo> you method will not work
<tberman> ah, gotcha
<tberman> now i understand completely :)
<tberman> ok, what about the tab level/spacing of the any line
<tberman> cause like, lets say i want to indent line x 4 spaces more than line y
<tberman> getting the indent level of line y is difficult
<paolo> why?
<tberman> maybe cause im stupid
<tberman> how would you do it?
<paolo> You only have to get the column of the first non-white char in line x
<paolo> and return it + 4
<paolo> there should be a get_column function in gtksourceview
<tberman> ah, ok, i am stupid :)
<tberman> ok, one other thing
<tberman> it would be nice if there was an insert method on the buffer that allowed for smart/auto indenting to occur
<gustavo> paolo: i'm not really sure... looks too simple, it's just too good to be true :-)
<gustavo> paolo: take a look at the emacs c indenter (info ccmode)
<paolo> gustavo: well, I have looked at vim, and it seems to work in the same way
<gustavo> paolo: i even had to customize that to get what i needed
<gustavo> where can i find docs about the vim way?
<gustavo> vim.org?
<paolo> see the indent.txt file in /usr/share/vim/vim62/doc
<paolo> tberman: what do you mean exactly?
<paolo> gustavo: note that I'm speaking of the generic interface
<tberman> paolo: well, lets say i have a section of text that includes newlines, it would be cool if i could insert it telling gtksourceview to add all the formatting rules it normally does
<paolo> gustavo: the problem will be implementing the real indenter for all the languages
<paolo> tberman: oh, right
<gustavo> paolo: ok
<paolo> tberman: I have still to think about this problem
<tberman> like a gtk_source_buffer_insert_with_formating
<tberman> thats one of the problems im working around in MD
<tberman> cause you guys calculate the indent level in the keypress cb
<paolo> or format_range
<tberman> paolo: both preferrably
<paolo> that is wrong
<tberman> ?
<paolo> calculating the indent level in the keypress cb is wrong since I'm not sure it works
<tberman> thats what you guys do in 0.7
<paolo> with allk the input methods
<tberman> well, thats what im sayin, cause when i call insert right now, i dont get auto indenting, and while i dont think you should by default, it would be nice to be able to if you wanted
<paolo> yep, I see the problem while designing the new smart indent thing
<paolo> yep
<gustavo> paolo: you can handle it in insert_text instead of keypress
<paolo> gustavo: yep, this is what I will do in the new implementation
<paolo> in insert_text if the inserted text will contain only a single char then smart_indent will be called
<paolo> probably the indenter should contain also a format_line function
<tberman> btw, im really looking forward to all this new stuff in sourceview :)
<paolo> so to insert formatted text you will have to call format_line on all the new lines
<tberman> is it a 2.8 target?
<paolo> yep (I hope)
<tberman> paolo: that would be fine
<paolo> gustavo: have you found the vim doc?
<paolo> gustavo: I can explain it to you if you want
<gustavo> paolo: how about splitting the functionality between handling the last inserted character and returning the indent column?
<gustavo> paolo: yes, found it thanks
<paolo> hmmm... what do you mean
<paolo> ?
<paolo> What I was thinking is:
<paolo> smart indent first check it the last_char will trigger reformatting
<paolo> the calls format_line
<paolo> s/the/then
<gustavo> yeap, exactly
<paolo> the difference is only to expose format_line
<paolo> or better indent_line
<paolo> from an implementation point of view I think we should:
<paolo> 1. have a default GtkSourceAutoIndenter class
<tberman> here is another thing, not sure if it will come up, or what a fix is, just tossing out info/ideas, there might be times where you are indenting by tabs and spaces. for example something like some_big_long_function ( GObject some_item,
<tberman> and then you want the next param to line up with (
<paolo> it should be used when auto indent is enabled and no specific indeter has been specified
<tberman> if that makes any sense
<paolo> yep, it should be already handled
<tberman> with tabbing to the previous lines indent level and then using spaces to go out to the (
<paolo> in the current design
<tberman> ?
<paolo> hmmm... no
<gustavo> hehe, that's what i had to customize in emacs :-)
<tberman> gustavo: :)
<tberman> i really think it is the best way to do multiline stuff
<paolo> suppose the ( is at col 20 and tab with is 8
<paolo> you will have 2 tabs and 4 spaces
<tberman> that way it looks right no matter how big your tabs are
<tberman> paolo: yeah
<tberman> but if the previous line (the line you are tabbing against) is at col 8, you get weird behaviour
<paolo> why?
<gustavo> if you change your tab width setting
<tberman> because then if i change my tab width to 4 it no longer lines up
<tberman> where as tabs then spaces it will line up no matter my tab width
<paolo> ah, ok
<paolo> hmmm... current design does not handle it
<tberman> dont worry, i bring no solution, only problems ;)
<paolo> but we can change it 
<paolo> for example by making "smart_indent" return the right sequence of tabs and spaces
<paolo> instead of an int
<gustavo> paolo: or return two values
<tberman> yeah, an int[2] would work
<gustavo> the first with the indent level of the base line, and the other with the extra space
<paolo> hmm... I prefer to return "char *"
<gustavo> there's one problem about that
<gustavo> the indenter is bound to the buffer
<paolo> yep
<gustavo> but the insert_tabs_instead_of_spaces is a view property
<gustavo> maybe the indenter should be a view prop?
<paolo> this is wrong for the same reason the current way of auto indenting is wrong
<tberman> brb
<paolo> we should deprecate the insert_tabs_instead_of_spaces view property
<paolo> and add a insert_tabs_instead_of_spaces buffer property
<paolo> the same for the auto_indent property
<paolo> speaking of the impl. details
<gustavo> why should they be buffer props?
<paolo> since they deals with the way the text is inserted in the buffer not with the way the test is displayed
<gustavo> there's a problem with that reasoning
<gustavo> tab_width is a visual property
<paolo> i.e. they are modifier of the inserted text
<gustavo> but you need that information for insert_spaces_instead_of_tabs
<gustavo> and the buffer can have multiple views
<gustavo> which one would you choose?
<paolo> hmmm... yep
<paolo> this is a big problem
<gustavo> i think those props should remain in the view
<paolo> hmmm... I'm afraid we will have to move all the stuff in the view
<gustavo> they have to do with the interaction between the user and the document
<paolo> that in this case is the controller too
<gustavo> which is handled by the view
<gustavo> yep
<paolo> but we have to connect to the insert_text signal
<paolo> and not using the key_press_cb as we do now
<gustavo> i don't think that's a problem, since the view has just one buffer
<paolo> yep
<paolo> ok, I will attach the indenter to the view then
<gustavo> ok
<paolo> is it ok for you?
<paolo> oh
<paolo> For the implementation:
<paolo> I think we should have a default auto indenter that behaves like the current one
<paolo> it could be called GtkSourceDefaultAutoIndenter
<gustavo> yeap, sounds good
<paolo> then we will need to have a lot of auto indenters, one per language
<paolo> sigh
<gustavo> either that, or just one which uses info from the language :-)
<gustavo> i mean the GtkSourceLanguage
<gustavo> or the GtkSourceEngine
<paolo> hmmm... I'm not sure
<paolo> if you see how the various per language indent functions are implemented in vim
<paolo> you will see we need a real programming language to write them
<paolo> I don't think we will be able to find a generic way to express all the rules
<paolo> we will need
<gustavo> hmm... yeah, probably not
<paolo> I think the indenter should be GTypeModule
<paolo> indenters I mean
<gustavo> sounds good
<paolo> that will be loaded at runtime
<tberman> would i be able to write one in C# and use it?
<paolo> tberman: yep, you will only have to implement the right interface I think
<tberman> cool
<Drumz> anyone here using anjuta on solaris, or know anyone who is?
<paolo> I don't know the details but I think you will have to subclass the GTypeModule class and implements our interface
<tberman> paolo: nod, i can figure that part out, just making sure it was possible
<gustavo> Drumz: try in the #anjuta channel
<paolo> teoretically it is possible, but we will have to try
<Drumz> gustavo:  nobody there, any idea when people come online there?
<tberman> paolo: nod
<gustavo> Drumz: nope, sorry
<Drumz> gutavo:  thanks anyhow, i'll keep trying the channel till someone shows up (anjuta channel that is).
<gustavo> Drumz: np
<paolo> gustavo: other open problems?
<paolo> ah... the loader 
<gustavo> hehe
<-- Drumz (~chatzilla@dialup-67.74.230.60.Dial1.Baltimore1.Level3.net) has left #devel-apps
<paolo> I'm still not sure about how to implement it
<gustavo> paolo: we can probably steal some gtk+ code
<paolo> well, yep
<gustavo> paolo: they use type modules for input methods
<paolo> I was thinking to its interface
<paolo> probably something similar to the languages manager would be enough
<gustavo> yeah
<paolo> the cool thing of using GTypeModule is that each indenter will be able to have custom properties
<paolo> so if you know them you can configure it
