Re: [gedit-list] Ubuntu 9.10 or gedit 2.28.0 tool test request

[Doug McNutt <douglist macnauchtan com>]

At 18:44 -0500 11/4/09, Jean-Philippe Fleury wrote:
>Doug McNutt a écrit le 2009-11-04 17:21 :
>> Does it create a new document in the gedit window?
>
>Yes.
>
>> Are the environment variables listed correctly with no extra lines inserted?
>
>Yes. There's one variable per line.
>
>> Change output to insert instead of new-document
>> Do you get all of the environment variables?  I get only 31 of them.
>
>I get 41 variables.
>
>> Is there anything funny about variable:
>>   GEDIT_CURRENT_WORD
>> It seems to depend on the position of the cursor when the tool is executed.
>> Try it at the left end of a blank line in the middle of your working sheet.
>
>I'm not sure I understand «left end of a blank line», but I put this on
>my document:
>
>>Lorem ipsum dolor sit amet, consectetuer adipiscing elit.
>>
>>Class aptent taciti sociosqu ad litora torquent per conubia nostra.
>
>and I put the cursor to the second line (the cursor is represented by
>the character |):
>
>>Lorem ipsum dolor sit amet, consectetuer adipiscing elit.
>>|
>>Class aptent taciti sociosqu ad litora torquent per conubia nostra.
>
>The value of the variable GEDIT_CURRENT_WORD is the last word of the
>previous line:
>
>>GEDIT_CURRENT_WORD=elit.
>
>Jean-Philippe

Many thanks for doing the test. Your results put me on the right track to figure out what was happening to me.

The problem is in the algorithm that figures out what the current word really is. It's a bit like the double click to select a word that doesn't work correctly for programmers who are used to variable names that have digits and underscores in them.

If the selection point is in the middle of a range of non-alphabetic characters it is possible for the code to produce an environment variable  $GEDIT_CURRENT_WORD that has line ends embedded in it. I think it is searching forward and backward for the first non-alphabetic character that follows an alphabetic character without ever looking at the characters it's collecting.

In several UNIX style operations, like echoing the variable to a pipe that passes it to grep, the line ends disappear. But perl can see what is really there. Future users are bound to have problems.

The way to see truth is first to copy from ###firstline thru ###lastline below into a gedit window, second to move the part that is a tool into $HOME/.gnome2/gedit/tools, which can be done with the GUI editor in gedit if you like, third to place the selection point by clicking near the middle of the long row of hash marks, and fourth to execute the tool.

Here I show, below ###lastline, what happens.  Everything below ###lastline is printed by the perl code. Note that gedit reports a value from "firstline" through "#!/usr" including all of the lineends and hashes in between. Methinks it's a bug that needs to be fixed. I'll file it tomorrow.


###firstline


##############################


#!/usr/bin/perl
# [Gedit Tool]
# Comment=run-command
# Name=env_check
# Applicability=all
# Output=append-document
# Input=nothing
# Save-files=nothing

$anenv = $ENV{'GEDIT_CURRENT_WORD'};
print "Starting line for GEDIT_CURRENT_WORD\n";
print "$anenv\n";
print "Finishing line\n";

###lastline

Starting line for GEDIT_CURRENT_WORD
firstline


##############################


#!/usr
Finishing line

--

--> Life begins at ovulation. Ladies should endeavor to get every young life fertilized. <--