Include _ on double-click selection of words

this patch fixes http
://bugzilla.ximian.com/show_bug.cgi?id=81192

let me know if it is ok to commit

thx,
-- Ben

_______________________________________________
Monodevelop-list mailing list
Monodevelop-listlists.ximian.com
http://lists.ximian.com/mailman/listinfo/monodevelop-li
st

I think this patch should not be committed since it is not a
solution to
the real problem: GtkSourceView follows Pango's policy for
detecting
word boundaries. The patch may fix the case of selecting
using
double-click, but there are cases which would still be
incorrect (e.g.
selecting using control+shift+left/right, or navigating
through code
using control+left/right, or selecting a block of words by
double
clicking on the first word and then dragging the pointer).

We need a more generic solution that covers all those cases
(and I don't
even know if there is a solution for all cases).

Lluis.

El dc 18 de 04 del 2007 a les 17:46 +0200, en/na Ben Motmans
va
escriure:
> this patch fixes http
://bugzilla.ximian.com/show_bug.cgi?id=81192
> 
> let me know if it is ok to commit
> 
> thx,
> -- Ben
> _______________________________________________
> Monodevelop-list mailing list
> Monodevelop-listlists.ximian.com
> http://lists.ximian.com/mailman/listinfo/monodevelop-li
st

_______________________________________________
Monodevelop-list mailing list
Monodevelop-listlists.ximian.com
http://lists.ximian.com/mailman/listinfo/monodevelop-li
st

As Lluis was hinting at, the proper fix for this would be to
somehow
provide Pango with a new word-boundary policy (which the
Pango API sorta
has a way of doing, it just doesn't actually work - I don't
remember all
the details, it was something Miguel and I looked into a
while back).

Jeff

On Wed, 2007-04-18 at 19:46 +0200, Lluis Sanchez wrote:
> I think this patch should not be committed since it is
not a solution to
> the real problem: GtkSourceView follows Pango's policy
for detecting
> word boundaries. The patch may fix the case of
selecting using
> double-click, but there are cases which would still be
incorrect (e.g.
> selecting using control+shift+left/right, or navigating
through code
> using control+left/right, or selecting a block of words
by double
> clicking on the first word and then dragging the
pointer).
> 
> We need a more generic solution that covers all those
cases (and I don't
> even know if there is a solution for all cases).
> 
> Lluis.
> 
> El dc 18 de 04 del 2007 a les 17:46 +0200, en/na Ben
Motmans va
> escriure:
> > this patch fixes http
://bugzilla.ximian.com/show_bug.cgi?id=81192
> > 
> > let me know if it is ok to commit
> > 
> > thx,
> > -- Ben
> > _______________________________________________
> > Monodevelop-list mailing list
> > Monodevelop-listlists.ximian.com
> > http://lists.ximian.com/mailman/listinfo/monodevelop-li
st
> 
> _______________________________________________
> Monodevelop-list mailing list
> Monodevelop-listlists.ximian.com
> http://lists.ximian.com/mailman/listinfo/monodevelop-li
st

_______________________________________________
Monodevelop-list mailing list
Monodevelop-listlists.ximian.com
http://lists.ximian.com/mailman/listinfo/monodevelop-li
st

Hello,

> As Lluis was hinting at, the proper fix for this would
be to somehow
> provide Pango with a new word-boundary policy (which
the Pango API sorta
> has a way of doing, it just doesn't actually work - I
don't remember all
> the details, it was something Miguel and I looked into
a while back).

I remember that we could not figure out a way of providing
the new
policy.


> Jeff
> 
> On Wed, 2007-04-18 at 19:46 +0200, Lluis Sanchez
wrote:
> > I think this patch should not be committed since
it is not a solution to
> > the real problem: GtkSourceView follows Pango's
policy for detecting
> > word boundaries. The patch may fix the case of
selecting using
> > double-click, but there are cases which would
still be incorrect (e.g.
> > selecting using control+shift+left/right, or
navigating through code
> > using control+left/right, or selecting a block of
words by double
> > clicking on the first word and then dragging the
pointer).
> > 
> > We need a more generic solution that covers all
those cases (and I don't
> > even know if there is a solution for all cases).
> > 
> > Lluis.
> > 
> > El dc 18 de 04 del 2007 a les 17:46 +0200, en/na
Ben Motmans va
> > escriure:
> > > this patch fixes http
://bugzilla.ximian.com/show_bug.cgi?id=81192
> > > 
> > > let me know if it is ok to commit
> > > 
> > > thx,
> > > -- Ben
> > >
_______________________________________________
> > > Monodevelop-list mailing list
> > > Monodevelop-listlists.ximian.com
> > > http://lists.ximian.com/mailman/listinfo/monodevelop-li
st
> > 
> > _______________________________________________
> > Monodevelop-list mailing list
> > Monodevelop-listlists.ximian.com
> > http://lists.ximian.com/mailman/listinfo/monodevelop-li
st
> 
> _______________________________________________
> Monodevelop-list mailing list
> Monodevelop-listlists.ximian.com
> http://lists.ximian.com/mailman/listinfo/monodevelop-li
st
_______________________________________________
Monodevelop-list mailing list
Monodevelop-listlists.ximian.com
http://lists.ximian.com/mailman/listinfo/monodevelop-li
st

Hey,

On 4/22/07, Miguel de Icaza <miguelximian.com> wrote:
> I remember that we could not figure out a way of
providing the new
> policy.
>

I googled around a bit this morning, and i stumbled onto
some pango
documentation:

http://sector7.xo
r.aps.anl.gov/programming/gtk-2.6/pango/pango-Text-Processin
g.html#pango-break
http://sector7
.xor.aps.anl.gov/programming/gtk-2.6/pango/PangoEngineLang.h
tml#PangoEngineLangClass

essentially, what the docs tell us, is to create a new
PangoEngineLang
class and implement the script_break () method, though there
is an
issue with this solution:
according to monodoc, Pango# does not allow us to implement
script_break, maybe we could add a ScriptBreakFunc property?
this way
we still allow the use of pango_default_break () when the
property is
set to null and we can override it whenever we want

so, a possible solution?
Create a subclass of Pango.EngineLang that takes the old
Pango.EngineLang as a parameter. Expose the
pango_default_break ()
method in Pango.Global.
When the ScriptBreakFunc of the constructor parameter is
null, call
Pango.Global.DefaultBreak, otherwise call
param.ScriptBreakFunc.
Afterwards, loop through the Pango.LogAttr array generated
by calling
DefaultBreak or ScriptBreakFunc and set
LogAttr.IsWordEnd/IsWordStart
for instances of '_'

though, please keep in mind I'm far from a Pango expert, so
this chain
of thoughts could be totally useless .. so let me know if
this is
leading to something or if you came to the same conclusions
but found
some additional problems I'm not aware of

-- Ben
_______________________________________________
Monodevelop-list mailing list
Monodevelop-listlists.ximian.com
http://lists.ximian.com/mailman/listinfo/monodevelop-li
st

On Sun, 2007-04-22 at 14:12 +0200, Ben Motmans wrote:
> Hey,
> 
> On 4/22/07, Miguel de Icaza <miguelximian.com> wrote:
> > I remember that we could not figure out a way of
providing the new
> > policy.
> >
> 
> I googled around a bit this morning, and i stumbled
onto some pango
> documentation:
> 
> http://sector7.xo
r.aps.anl.gov/programming/gtk-2.6/pango/pango-Text-Processin
g.html#pango-break
> http://sector7
.xor.aps.anl.gov/programming/gtk-2.6/pango/PangoEngineLang.h
tml#PangoEngineLangClass
> 
> essentially, what the docs tell us, is to create a new
PangoEngineLang
> class and implement the script_break () method, though
there is an
> issue with this solution:
> according to monodoc, Pango# does not allow us to
implement
> script_break, maybe we could add a ScriptBreakFunc
property? this way
> we still allow the use of pango_default_break () when
the property is
> set to null and we can override it whenever we want

if we need pango-sharp to change, we can change it, although
another
solution might be to implement the fix as part of
GtkSourceView as I
know they want a fix for this as well.

> 
> so, a possible solution?

[snip]

Miguel and I had looked into doing it in C - and as Miguel
said, there
was no way to override the default script_break() (to my
recollection)
because pango_break() needs an 'analysis' argument from
pango_itemize()
which is what attaches a PangoEngineLang object, and there
are no hooks
to allow you to specify which PangoEngineLang
(class/subclass) gets
used, so there's no way to ever override the script_break()
function -
it would appear all PangoEngineLangs are hard-coded.

However, it might be that we overlooked something.

Jeff

_______________________________________________
Monodevelop-list mailing list
Monodevelop-listlists.ximian.com
http://lists.ximian.com/mailman/listinfo/monodevelop-li
st

Hello,

> > essentially, what the docs tell us, is to create a
new PangoEngineLang
> > class and implement the script_break () method,
though there is an
> > issue with this solution:
> > according to monodoc, Pango# does not allow us to
implement
> > script_break, maybe we could add a ScriptBreakFunc
property? this way
> > we still allow the use of pango_default_break ()
when the property is
> > set to null and we can override it whenever we
want

What I could never figure out was how to hook up the new
PangoEngineLang
into the pango pipeline.

But if we could do this, we do not have to modify Gtk#
(which would take
a full cycle of releases to go), but we could probably just
safely
P/Invoke the proper method to do this.

Or even have the C code that implements the new engine to
set the
attribute into whatever Pango object we need.

Miguel
_______________________________________________
Monodevelop-list mailing list
Monodevelop-listlists.ximian.com
http://lists.ximian.com/mailman/listinfo/monodevelop-li
st