Gedit word select doesn't include space
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| gedit |
Won't Fix
|
Low
|
|||
| gedit (Ubuntu) |
Triaged
|
Wishlist
|
Unassigned | ||
Bug Description
When I select a word from a sentence by double clicking, it should include the nearest space and or non letter character (trailing if I click near the last letter and leading if I click near the first letter). Then when I drag or delete, I don't have to go back and delete the extra space from where the word was taken and type one in where the word is dropped off. Not everyone wants this, so select behavior should be set in a preferences menu. Microsoft word has this feature and it's selection behavior is even more sophisticated. Check it out.
Example 1:
These are the that times try men's souls -- now I select the word "times"
These are the that *times* try men's souls -- now if I drag to proper location, I get
These are the timesthat try men's souls -- now I have to insert a space between "times" and "that" and delete one after "that"
Corrected Example 1:
These are the that times try men's souls -- now I select the word "times" which includes trailing space (dbl clk on "es")
These are the that *times *try men's souls -- now if I drag to proper location, I get
These are the times that try men's souls -- now it's perfect
Example 2 - commas
I'll take red, orange, brown, *yellow, *and white marbles -- select "yellow" including comma and trailing space and move it
I'll take yellow, red, orange, brown, and white marbles -- now it's perfect
| Matthew Paul Thomas (mpt) wrote | #1 |
| Rising Eagle (borntobesteve) wrote | #2 |
| Vish (vish) wrote | #3 |
| Changed in gedit (Ubuntu): | |
| importance: | Undecided → Wishlist |
| status: | New → Confirmed |
| Changed in hundredpapercuts: | |
| importance: | Undecided → Wishlist |
| status: | New → Confirmed |
| Tom Hurd (thurd) wrote | #4 |
| Changed in gedit: | |
| importance: | Undecided → Unknown |
| status: | New → Unknown |
| Changed in gedit (Ubuntu): | |
| status: | Confirmed → Triaged |
| Changed in hundredpapercuts: | |
| assignee: | nobody → Papercuts Ninja (papercuts-ninja) |
| milestone: | none → nt5-office |
| status: | Confirmed → Triaged |
| Changed in gedit: | |
| importance: | Unknown → Low |
| status: | Unknown → New |
| Alexandru Guduleasa (gulyan89) wrote | #5 |
| Ubuntu Foundations Team Bug Bot (crichton) wrote | #6 |
| tags: | added: patch |
| Sebastien Bacher (seb128) wrote | #7 |
| Changed in hundredpapercuts: | |
| milestone: | nt5-office → quantal-2-productivity |
| Changed in hundredpapercuts: | |
| milestone: | quantal-2-productivity → gedit |
| Changed in hundredpapercuts: | |
| milestone: | gedit → papercuts-s-gedit |
| Changed in hundredpapercuts: | |
| assignee: | Papercuts Ninjas (papercuts-ninja) → nobody |
| Changed in gedit: | |
| status: | New → Won't Fix |
Preferences are good for things that a lot of people want all of the time and a lot of people want none of the time. They're annoying for things that everyone wants only some of the time.
Selecting the nearest space when double-clicking would work for the deletion and dragging cases, but it would fail for the case where you want to retype the word; and it would fail for the case where you want to apply, just to the word, an underline, a background color, or any other formatting that would be visible for the adjacent space. So that selection behavior would be something everyone wants only some of the time, and a preference would not be any help, because changing the preference would be even slower than correcting the mistake.
OpenOffice.org Writer handles this a better way: selecting the word does not select the nearest space, but deleting or dragging automatically deletes or moves the adjacent space as well. That works for the retyping and formatting cases as well as the deleting and dragging cases, and even with OOo's vast array of options, it doesn't have -- or need -- an option for it.