Odd text editing window behaviour

At the risk of appearing to double-post I have an issue that has arisen
in an application which may apply to a wider audience, so I am sharing it here.

I’m using OpenSUSE 12.1, kernel 3.2.0, Gnome 3. Same behaviour happens in IceWM. On other
systems such as Fedora the behaviour is not seen.

In the application pgadmin3, I open the Query Builder and
paste a multi-line SQL query into the editing window. I have created text in Kwrite and Libreoffice
writer and cut and pasted with the same results.
The query runs fine. The issue arises when the SQL contains parentheses.
Attempting to edit the parentheses results in curious behaviour that does not crash the application
but interferes with the presentation of the text in the window. Here’s what happens.

Paste in the SQL. Click on one of the left pairs of parentheses. Backspace to delete it.
The current line remains visible in the window but all other lines above and below disappear,
replaced by a light blue area.
I can get the edited text to update and reappear correctly if I drag the horizontal window slider to the right and back.

Also if I paste the SQL into the window as one long single line and then break the line
up into multiple lines in the window I can edit freely.

Does this bizarre behaviour ring a bell with anybody in the OpenSUSE community? I have tried tweaking a number
of system settings but nothing seems to have an effect.

colbec wrote:
> At the risk of appearing to double-post I have an issue that has arisen
>
> in an application which may apply to a wider audience, so I am sharing
> it here.
>
> I’m using OpenSUSE 12.1, kernel 3.2.0, Gnome 3. Same behaviour happens
> in IceWM. On other
> systems such as Fedora the behaviour is not seen.
>
> In the application pgadmin3, I open the Query Builder and
> paste a multi-line SQL query into the editing window. I have created
> text in Kwrite and Libreoffice
> writer and cut and pasted with the same results.
> The query runs fine. The issue arises when the SQL contains
> parentheses.

I’m not clear about the exact circumstances.

When you talk about kwrite and LO, do you mean that you have seen the
problem with them as well? Or just that you have used both as a source
of text to be pasted with identical results?

You say the problem depends on parentheses. Does that mean you can edit
other characters without a problem? Even on lines containing parentheses?

This problem sounds to me like it is connected to character sets and
encoding. And perhaps a bug in pgadmin3 or whatever library it uses for
text widgets.

I think you should check carefully exactly what sequence of bytes you
are cutting and pasting, and what character encodings you have selected
for your system and for each application that is involved.

LO and Kwrite are the sources for cut and pasted text.
I can mouse click in a line which contains parentheses, not on a left parenthesis,
and delete characters all the way up to a left parenthesis at which point the
window port blanks.

It does seem critical what the character representation of the left paren is.

If I run “file -bi file.py” on the source of the text I get “text/x-python; charset=us-ascii”
which should be about as plain basic as you can get.

colbec wrote:
> LO and Kwrite are the sources for cut and pasted text.

I believe pgadmin has a -f<sql script> option. What if you use that?

> It does seem critical what the character representation of the left
> paren is.

Also the newlines.

I can edit out the newlines without problem, I use this to reduce a multiline statement to a single.

A new observation is that if the SQL is pasted into a window port which is too narrow for the longest line
it edits correctly.

colbec wrote:
> djh-novell;2447772 Wrote:
>> Also the newlines.
>
> I can edit out the newlines without problem, I use this to reduce a
> multiline statement to a single.

Right, but you also said:

> Also if I paste the SQL into the window as one long single line
> and then break the line up into multiple lines in the window I
> can edit freely.

So newlines are clearly involved somehow. And they are well-known
sources of character-encoding difficulties.

> A new observation is that if the SQL is pasted into a window port which
> is too narrow for the longest line
> it edits correctly.

It sounds like a problem in the widget set (what is it?) but until you
know the byte sequence and all the encoding settings, it’s probably not
worth reporting.