This behaviour bothers me as well.

One possible solution would be to add a setting to the preferences where the user would specify characters that words are comprised of.

If this setting would take in the account the document type (.c source, .php, txt) that would be even better.

For the above example: 
chars_in_words = "a-z,A-Z,_,$"

---

I would also like to see numbers selected, for example:
Double-clicking on the "var" part of the word "var123" only selects "var", not "var123" as I would expect.

For this example:
chars_in_words = "a-z,A-Z,_,$,0-9"

Gedit Document inherits from GtkSourceView, and it from GtkTextView.

GtkTextView captures the the double click, and calls
gtk_text_select_word

...
	case GDK_2BUTTON_PRESS:
	  gtk_text_select_word (text, event->time);
...


gtk_text_select_word (GtkText *text, guint32 time)
{
  ...
  
  gtk_text_move_backward_word (text);
  start_pos = text->cursor_mark.index;
  
  gtk_text_move_forward_word (text);
  end_pos = text->cursor_mark.index;
  
  ...
}

Both gtk_text_move_forward_word and gtk_text_move_backward_word
short-sighted.

Since this is mostly a code issue, I think GtkSourceView should capture
the GDK_2BUTTON_PRESS and call its own gtk_source_view_select_word.
That method should walk forwards and backwards using a wider test word
characters (or the opposite) I'm out of my depth, here. I would be
inclined to test with g_unicode_isalnum | - | _. The opposite would be
g_unicode_is_punct | g_unicode_is_space. 

I would love to see this behaviour changed as well.  Perhaps it could be made dependant on what (i.e. what source code language :) ) was being edited if the default behaviour is desired in some circumstances?

I have made a plugin to address this.

http://code.google.com/p/gedit-click-config/

It makes Gedit fully configurable for what kind of text is selected.

Could I ask any subscribers to this bug (developers opinions take precedence :) ) what they think the correct behaviour is here?  Apple defines words as
"... any continuous string that contains any of the following characters:
 * A letter
 * A digit
 * A nonbreaking space (Option–Space bar or Command–Space bar)
 * A currency symbol ($, ¢, £, ¥)
 * A percent sign
 * A comma between digits
 * A period before a digit
 * An apostrophe between letters or digits
 * A hyphen, but not an en dash (Option–hyphen) or em dash (Shift–Option–hyphen)"
and give some examples (they do not count underscores) in http://developer.apple.com/mac/library/documentation/UserExperience/Conceptual/AppleHIGuidelines/XHIGUserInput/XHIGUserInput.html

Bash/readline seems to follow the current gedit behaviour, while gnome-terminal likes the above with the exception of dollar signs when double clicking, and Epiphany includes letters, numbers, underscores and dots between numbers but excludes the rest.

I am considering hacking up the current behaviour slightly, but I would like to know what to target.

(In reply to comment #5)
> Could I ask any subscribers to this bug (developers opinions take precedence :)
> ) what they think the correct behaviour is here?
I think those are good rules, and more generally helpful than the current behavior.  I would just add the underscore to that.  I'm sure the reason Apple doesn't include the underscore is because those rules are intended primarily for English text rather than for computer code.  They would still be preferable for code, I think, and especially if you were to include the underscore.

If you try out any of those examples from Apple's page in Gedit, the results are pointless.  And I can't think of a common case where Apple's rules would be frustrating.

I will still be using my Click Config plugin, because I like having more than one rule for selecting text.

You might want to make the hyphen sensitive to whether it is between letters.

In Gnome, open 'Terminal', from the Edit menu select 'Profile preferences'.

Note that down the bottom of the 'General' tab it allows you to choose your 'select-by-word characters.

This would be the best way of enabling this feature - then users can choose/edit the way gedit selects characters.

At least at this point in time, the bit about inheriting from GtkText is no longer true.  gedit relies on Pango for its word break algorithm, so it would be worth asking the Pango authors what they think about this.

(In reply to comment #8)
> In Gnome, open 'Terminal', from the Edit menu select 'Profile preferences'.
> 
> Note that down the bottom of the 'General' tab it allows you to choose your
> 'select-by-word characters.
> 
> This would be the best way of enabling this feature - then users can
> choose/edit the way gedit selects characters.

For letting the user configure it, my plugin will already do exactly as you describe, with a simple character set or with a more elaborate regex.

But I think for the built-in functionality that most users will take for granted, the rules that Michael listed are probably a good default.  Not specifying it in terms of a simple character set allows for rules that also check the adjacent characters, e.g. "An apostrophe between letters or digits" selects all of "shouldn't" as a word but not an apostrophe where it's used for quoting.  "A period before a digit" selects a floating point number as a word, but excludes the period at the end of a sentence or namespace.

Follow up to comment 9: I created https://bugzilla.gnome.org/show_bug.cgi?id=614371 to get the Pango maintainers' opinion on this.

This bug is a duplicate of bug 354587 , which is even older than this one!  It would be nice to close one of them so that we can all discuss this on the same page.  I've also wanted this feature for years, by the way.

Which at the same time is a duplicate for a pango bug or a gtk+ bug if I recall correctly.

*** This bug has been marked as a duplicate of bug 354587 ***