After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 119428 - [ui-review] word wrap should have a menu entry.
[ui-review] word wrap should have a menu entry.
Status: RESOLVED FIXED
Product: gedit
Classification: Applications
Component: general
git master
Other Linux
: Normal enhancement
: ---
Assigned To: Gedit maintainers
Gedit maintainers
: 125910 128650 313621 317731 399830 462699 543911 561735 574204 644894 645793 700515 (view as bug list)
Depends on:
Blocks: 115437
 
 
Reported: 2003-08-08 12:05 UTC by August Mayer
Modified: 2016-04-23 05:21 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement


Attachments
This patch fixes the problem (6.79 KB, patch)
2004-08-16 16:14 UTC, Uphaar Agrawalla
none Details | Review

Description August Mayer 2003-08-08 12:05:08 UTC
GEdit has a preferences dialog entry that toggles the automatic line break.
However, this feature is buried deep in the preferences panel. It would be
quite useful to have this option somewhere in a menu.

When editing documents using manual line break (i.e. LF at every line end),
such as EMails, automatic line break disturbs the layout if the window is
resized temporarily. Sometimes, lines should intentionally be long, e.g. in
some situations when editing HTML documents. On the other hand, automatic
line break is quite useful when reading texts that have LF only at the end
of every paragraph.
Comment 1 Paolo Borelli 2003-12-21 13:24:53 UTC
[copying comments from bug 128650 (which I'm closing as dup) and
adding  ui-review keyword.]


I find that the "wrap mode" is misplaced in the preferences dialog, as
a matter of fact preferences are something that you are supposed to
set once to meet your need and then modify only rarely.

Instead wrap mode is something I happen to change quite often,
depending on which kind of document I am editing: I keep it off by
default (for code etc), but when I'm writing/reading simple text I
turn it on.

This looks like a normal use case, so I think that having the toggle
in a more accesible place makes sense; the most obvious place would be
the Edit menu or, if the option is changed to be 'per document'
instead of global, the Documents menu.
Comment 2 Paolo Borelli 2003-12-21 13:26:08 UTC
*** Bug 128650 has been marked as a duplicate of this bug. ***
Comment 3 Paolo Maggi 2004-03-27 15:14:23 UTC
*** Bug 125910 has been marked as a duplicate of this bug. ***
Comment 4 Uphaar Agrawalla 2004-08-16 16:14:38 UTC
Created attachment 30600 [details] [review]
This patch fixes the problem

The patch adds a menu item for the Word Wrap under Edit. The changes are
affected globally.
Comment 5 Olivier Le Thanh Duong 2005-08-18 14:10:26 UTC
*** Bug 313621 has been marked as a duplicate of this bug. ***
Comment 6 August Mayer 2005-08-21 13:01:41 UTC
Thanks for the patch, Mr. Agrawalla! It's probably true, though, that this
setting should be document-specific - is there somebody who wants to do this?
Comment 7 Paolo Borelli 2005-10-02 13:05:24 UTC
*** Bug 317731 has been marked as a duplicate of this bug. ***
Comment 8 Roberto Piscitello 2005-10-02 16:06:39 UTC
Well, the _default_ behaviour would be the one set in the preferences (renamed
to "Enable Text Wrapping for newly opened documents", for example), since
general and default settings belong to that dialog.
Document specific settings shouldn't go there.
The menu item, instead, would apply only to the current document, and
potentially be different for each opened tab.
That item could be in the View menu, near "Highlight mode".

Another, and cleaner, solution would be to get totally rid of the default
setting in the preferences window and turn text wrapping on by default for each
document not recognized as programming source code.
If this euristic is wrong for a specific document, the user can always manually
set/unset a text wrapping switch in the View menu for that document (and of
course gedit would save this setting as document specific).

The whole idea is based on the absolutely opinable constatation (because it
comes from my personal experience and YMMV) that 90% of the times you want text
to be wrapped unless it is a source file.  We all hate horizontal scrolling:-)
Maybe there are other file types which should not be wrapped by default. For
example all setting files is /etc/* or with (or within a directory with) a name
starting with a dot. I don't know.
Or maybe this euristic would work only for me and is totally crap...

Ciao,
  Roberto
Comment 9 Paolo Borelli 2005-10-02 16:25:49 UTC
[To give some context to Roberto's comment: it is a reply to my comment in bug
317731]

The 'analitic' solution (set the default in the prefs and override it for each
doc) is the more immediate approach, but I am somewhat doubtful that it offers a
good user experience: having the same kind of setting in two places is
confusing. For instance the casual user after seeing the menu item is even less
likely to look for the same setting also in the prefs and will be frostrated by
the inability to turn wrapping off for good.

The euristic approach is much more interesting, but poses the obvius problem of
how to handle the case where the user really wants something different.


Another UI idea that came to my mind is the following:
a submenu with

- wrap on word boundaries
- wrap on letter
- disable wrap
--------------
- set current wrapping as default


where the last item makes the current behavior the default.


Maybe it's crack... dunno.


We really need insight from someone with experience in interaction design. I'd
be tempted to suggest you to bring this up on usability list, but rarely the
discussion on the list leads to anything but flames and misguided opinions... :/
Comment 10 Eric Larson 2005-10-02 18:06:31 UTC
I think this bug speaks to the fact that the focus of gedit is confusing. I am
not saying this is bad, but it might be time to consider what the purpose of
gedit really is. If a developer is using gedit as his/her editor, then it seems
obvious to allow a document specific wrapping policy to be set. Along the same
vein, plugin systems and source code type policies should also be set as well.
With that said, for the person who just wants to edit a file because some
website said that they needed to do 'sudo gedit /etc/X11/xorg.conf' and change
line xx, we are just confusing them. I don't see a way to get around this
problem because it makes gedit a sub par editor for each use case, which I would
argue, are not corner cases or rare. 

With that said, I would go with the simpler solution of forcing wrapping by
default and keep the preference buried. I have seen in testing that users are
more like to maximize the window and never side scroll than looking for a
preference. 

Hope this is not a flame or misguided opinion. 
Comment 11 August Mayer 2005-10-02 19:06:17 UTC
> it might be time to consider what the purpose of gedit really is

I believe that gedit is supposed to be a small, simple general-purpose editor.
Syntax highlighting is nice, plugins are nice, but they are the upper bound of
what gedit should do, in my opinion. There are already emacs, gvim, jedit,
anjuta, abiword etc. out there who can do the really sophisticated tasks.

So, in short, gedit should be a small, simple editor with some nice extras.

> I would go with the simpler solution of forcing wrapping by
> default and keep the preference buried

I think the sophisticated menu is, pardon me, crack. Nobody needs all those
features; they are only there so as to justify an extra menu ;) Also, I don't
like the hiding option: advanced users want and need the flexibility. At least I
do, and I think I'm not alone. See, even metapad can do that!

I like the model where the setting is determined initially by the file type. No
pref panel option, only the menu entry, and maybe a tool bar icon. If the user
doesn't like it, he can change it afterwards. No confusion, a single option,
maximum flexibility.

If it's cheap to do, gedit could store the setting for a given document. I don't
know, is there some 'history' framework in place that stores document-specific
settings for some amount of time? This could be used for storing the option when
the user changed it for a specific document.

The list of document types which shouldn't wrap could be stored using gconf. So,
gurus could even adapt the defaults with gconf-editor.
Comment 12 Roberto Piscitello 2005-10-02 21:07:39 UTC
I agree with amayer, comment #11.
I think the submenu complicates the interface without a reason; moreover it
mixes document and global settings.
So I still prefer a single swich in the menu.
If there is someone who for some reason (which I can't think of, ATM, but you
never know...) absolutely wants to set the default and disable the euristic, a
hidden gconf setting could be the solution; or, if many people request this
option, as a last resource, a combo box in the Preferences dialog could
substitute the current switch:

Text wrapping for newly opened documents:
o Automatic
o Enabled by default
o Disabled by default

Of course better wording should be needed. Anyhow I don't like it very much.

On a side note, I find "wrap on letter" absolutely unuseful: for me it could go
away.

Thank you all,
  Roberto
Comment 13 Paolo Borelli 2005-10-02 23:39:11 UTC
Ok, some responses, though lets try to avoid to turn this specific bug into a
"should gedit make coffee" discussion.

> If a developer is using gedit as his/her editor, then it seems
> obvious to allow a document specific wrapping policy to be set. Along the same
> vein, plugin systems and source code type policies should also be set as well.
> With that said, for the person who just wants to edit a file because some
> website said that they needed to do 'sudo gedit /etc/X11/xorg.conf' and change
> line xx, we are just confusing them.

To me this bug proves the opposite :)

I may assure you from having dealt with gedit users for a long time that this
issue comes up very often and 90% of the time is from 'intermediate'[1] users
who needs to deal both with files which needs wrapping and with files where
wrapping screwes formatting.
In my experience most of those who use gedit as a programmer text editor just
turn wrapping off and get on with life.
The fact that users dayly need to deal with both kind of text files and sometime
even at the same time (which isn't currently possible) is sad but true fact of life.


[1] I hate this term, there are really no intermediate users, every user has a
different tasks which he wants to get done. With intermadiate here I mean not
total newbies who just need to read a text file by double clicking on it, nor
hackers.

> With that said, I would go with the simpler solution of forcing wrapping by
> default and keep the preference buried.

Text wrapping is already on by default and we all agree that it should stay that
way.

---------------------------------------------

> I think the sophisticated menu is, pardon me, crack. 

:)

I am very ready to admit that it may well be, in fact I already did when I first
proposed it. I was just trying to come up with alternative ideas to solve the issue.

> I like the model where the setting is determined initially by the file type.

As said I quite like the idea of enanching the default with some euristic, but
keep in mind that such euristic is very likely to fail. For instance people
dealing with output files of other programs and many of the log and
configuration files are plain text.

> If it's cheap to do, gedit could store the setting for a given document. I
>don't know, is there some 'history' framework in place that stores
>document-specific settings for some amount of time?

Yes, I was giving this for granted: gedit already has such a system in place
(for instannce we remember that last searched word etc) and if a user would
explicitely set the wrapping on a doc, storing it in the metadata make s perfect
sense
Comment 14 August Mayer 2005-10-03 09:00:00 UTC
> keep in mind that such euristic is very likely to fail

True, but it will work in those cases where an automatism can work, and the user
can change word-wrapping easily in the other cases.


I see another minor problem for windows with multiple tabs. When Word-Wrap is
document-specific, and the user switches to another tab, the setting in the menu
will magically change its state. This might confuse users. It might be clearer
to make the setting window-centric. Or it may be I who's on crack, this time.
Comment 15 Paolo Borelli 2005-10-04 10:21:30 UTC
After discussions on and off list I made up my mind on the following (Paolo
Maggi may still have some reserve, but I though to outline it here)

- Use a menu item, no tool buttons (not frequent enough to warrant a tool button)
- The menu item is "per-window", that is it affects all the docs in one window,
not other window. New window created after, follow the setting
- "wrap by char" will go in GConf, no one uses it anyway

This is a little in contraddiction with some of the things I said above, so here
is the rationale:

- it's surely *not worse* than what we have now (the pref was 'global' before
and it stays global 'after')
- it's better than what we had before because it's easier to find and faster to
toggle

This means that we can confidently make the switch and see if (and how match)
people still complains about 'per document' settings.

Such an approach covers most of the use cases:
- people with word wrapping always on
- people with word wrapping always off
- people who need to toggle from time to time and (very likely) have related
docs in the same windows (e.g. source files as tabs in a window in one workspace
and a doc which needs word wrapping in another window on another workspace)


The other advantage is that it's really simple, not only to implement, but also
for the user to understand: he looks at the menu item and can see that state of
word wrapping.

More complicated schemes have the drawback of introducing many weird cases, not
common but still possible, where the program behaves not in the way the user
expects and frustrate him because understanding why gedit did one thing instead
of the other would be almost impossible.
Comment 16 Paolo Maggi 2005-10-04 12:02:27 UTC
I agree with pbor (and I think the same approach can be used for line-numbers,
I'm not sure it is woth using this approach for rarely changed options like
right margin, braket matching and hl current line)

For advanced users the default could be overwritten, on a per-document basis,
using Emacs-like modelines. 
In order to have a consistent UI, I suggest to set the menu item as
"inconsistent" if the current document has overwritten the default behavior
using modelines.
Comment 17 Roberto Piscitello 2005-10-04 13:23:32 UTC
Simple is better, go for the per-window setting.
I also agree it may work both for line wrapping and line numbering.
Nice to see good ideas came out.
Thanks,
  Roberto
Comment 18 August Mayer 2005-10-04 13:44:05 UTC
I agree, this would be a good, simple solution, for now. Thanks!

Personally, I don't like modelines - they introduce the potential for attacks
against the editor by simply opening a file. Also, I don't know if a 'simple'
editor like gedit should offer such a complex feature.
Comment 19 Paolo Borelli 2005-10-04 13:51:20 UTC
[regarding modelines: we don't plan to implement 'complete' modelines support
where the variables are evaluated etc, just plain var=value support which is not
rosky froma security point of view. From a usability point of view they are OK
since they are invisible to the people not using them]
Comment 20 John Pye 2005-10-24 04:15:48 UTC
Please give the word-wrap feature a nice obvious keyboard shortcut. I vote alt-V-W.

Per-document word wrapping is the right approach. Add word-wrapping default
behaviour to your syntax/file-types definition at some point, but not urgent: a
global default is good enough to go on with.

Cheers
JP
Comment 21 John Pye 2005-10-24 06:57:24 UTC
(should have said 'line wrapping' in my comments above)
Comment 22 Paolo Borelli 2005-12-17 10:37:12 UTC
*** Bug 162044 has been marked as a duplicate of this bug. ***
Comment 23 Ajay Gautam 2006-06-20 17:49:56 UTC
Adding a "I-want-this-feature-too"
Comment 24 Marcus 2006-12-22 17:59:01 UTC
I need to switch line/word/whatever wrapping quite often, so I think a toolbar button would be the best solution. Why not make a customizable toolbar, this could probably be a solution to other problems with gedit. Or is there a plugin that I can use to customize the toolbar?
Comment 25 Steve Frécinaux 2007-01-23 17:04:55 UTC
*** Bug 399830 has been marked as a duplicate of this bug. ***
Comment 26 Philip Ganchev 2007-12-23 08:56:42 UTC
Yes, the best solution is View menu entry with per document memory and per document-type heuristics.  Since wrapping and line numbers relate to changing the view rather than the document itself, the Edit menu is the wrong place.  I am sure users would look under View.  Please implement per-document memory!
Comment 27 Ariel 2008-04-14 00:28:25 UTC
Many use cases seem to require switching the "wrap" functionality on and off. Easier menu accessibility would be fine, but a simple keyboard shortcut (hopefully simple to implement) is needed as well. 

I wonder if there is a plugin that already implements this?


The issue is also discussed in ubuntu's launchpad:

https://bugs.launchpad.net/ubuntu/+source/gedit/+bug/118522
Comment 28 Henrique Rodrigues 2008-04-14 01:50:20 UTC
I've made a minimal, but working plugin that implements this. Unfortunately, this plugin is not very complete, but it does what I want, so maybe it could help other people too. Here is the status:

+ We get a word wrap menu option under "View".
+ There is a shortcut assigned, Ctrl+R. I really don't know if this is the best option.
- When gEdit stats, the plugin reads the current gconf configuration and sets itself accordingly. I believe this is the right approach for a new document, but for others it really should use per-document, persistent, memory, kind of like gEdit knows the location of where you were in a file after reopening it.
- The text wrapping option is set per-window. This sucks badly, because it should be per-document, in my opinion.

I haven't put an icon in the toolbar because I don't think it's necessary. I could try to do that, but someone's gonna have to point me out an appropriate icon.

Blease be gentle... it's my first GTK+ adventure AND my first Python adventure. :-)

I've uploaded it here: http://sodki.org/programas/gedit_plugins/menu-text-wrap.tar.gz
Comment 29 Matthew Nuzum 2008-04-14 02:56:23 UTC
(In reply to comment #28)
> I've made a minimal, but working plugin that implements this. Unfortunately,
> this plugin is not very complete, but it does what I want, so maybe it could
> help other people too. Here is the status:

Henrique, you rock! That is an awesome idea. I've tried the plugin and it works great. It's exactly what I needed. Thanks a lot.

Comment 30 Ariel 2008-04-14 14:30:56 UTC
Thank you Henrique, awesome response! The plugin works fine for me too. After a few more weeks of usage & testing I hope this plugin can make it to the plugin set that ships with gedit for people to enjoy in gnome 2.24.
Comment 31 Henrique Rodrigues 2008-04-15 00:27:46 UTC
(In reply to comment #28)
> - When gEdit stats, the plugin reads the current gconf configuration and sets
> itself accordingly. I believe this is the right approach for a new document,
> but for others it really should use per-document, persistent, memory, kind of
> like gEdit knows the location of where you were in a file after reopening it.

I was wrong, in gEdit the scroll location is not kept after the application is closed. One less thing to worry about, then.
Comment 32 Henrique Rodrigues 2008-04-15 00:50:15 UTC
(In reply to comment #28)
> - The text wrapping option is set per-window. This sucks badly, because it
> should be per-document, in my opinion.

I forgot all about a nasty bug in my plugin. It works not per-window, but per-document, which is the right approach. Unfortunately, the menu entry state is not updated properly when there is more than one document opened, creating chaos. I also don't know what is the "right way" to correct this.
Comment 33 Eric Polin 2008-07-10 13:10:46 UTC
Definitely, the shortcut (along with at least a global default value or serialization) is the only thing that matters: there are even cases (e.g. complex XML documents) where you want to see alternatively the structure (NoWrap) and the content (Wrap) for the same document.
Comment 34 Eric Polin 2008-07-10 13:48:06 UTC
(In reply to comment #32)
> I forgot all about a nasty bug in my plugin. It works not per-window, but
> per-document, which is the right approach. Unfortunately, the menu entry state
> is not updated properly when there is more than one document opened, creating
> chaos. I also don't know what is the "right way" to correct this.

Just remove the menu entry ;-)

I am actually serious: either we have a full document-oriented approach, with serialization of the way each file was displayed last (along with its current line), plus, probably, some euristic as discussed above for the default, plus the customization of these euristics... or the preferences are merely as they are, that is global, and the shortcut does the rest. It is very nice already to have the behavior depend on the open document; more would be little used, I am afraid.

So, no need for a menu entry, but a complement to the help and a flag in the status bar would be nice. Finally, that should be part of the core product, not a plugin; or at the bare minimum, a std packaged plugin.

Above all, thank you so much for your development that changes my "Gnome life"!
Comment 35 Matthew Nuzum 2008-07-10 13:57:11 UTC
(In reply to comment #34)
> Just remove the menu entry ;-)
> 
> I am actually serious: either we have a full document-oriented approach, with
> serialization of the way each file was displayed last (along with its current
> line), plus, probably, some euristic as discussed above for the default, plus
> the customization of these euristics... or the preferences are merely as they
> are, that is global, and the shortcut does the rest.

I like the menu entry, please don't remove it. No heuristics are needed - there's no need to make this more complex than necessary. A clean and simple solution is great, and that's what we have.

I've grown so used to it that I'd actually forgotten it was a plugin. Thanks a bunch Henrique!

Comment 36 Trent Bartlem 2008-07-17 00:50:49 UTC
+1

I don't care whether word wrap is a global or per-file or per-file-type setting or if it remembers my choices or not; all I really want to do is toggle word wrap quickly when I need to, preferably by keyboard short-cut.
Comment 37 Steve Frécinaux 2008-07-17 07:39:03 UTC
*** Bug 462699 has been marked as a duplicate of this bug. ***
Comment 38 Allan Day 2008-07-20 21:37:22 UTC
*** Bug 543911 has been marked as a duplicate of this bug. ***
Comment 39 Karl Ostmo 2008-12-16 08:14:09 UTC
I would like to share a rewrite I've done of Henrique Rodrigues's wrapping plugin, which was posted above.  This version displays the state of text wrapping for the current tab in the status bar and does away with the checkbox widget, thus overcoming the confused state upon switching tabs.  Ctrl+R is still the keyboard shortcut.

http://kostmo.ath.cx/software/gedit_plugins/per-buffer-text-wrap.tar.bz2
Comment 40 Paolo Borelli 2009-01-01 23:41:03 UTC
*** Bug 561735 has been marked as a duplicate of this bug. ***
Comment 41 Karl Ostmo 2009-01-02 00:04:25 UTC
I have uploaded my above-referenced plugin to a more stable location on Launchpad:
http://launchpadlibrarian.net/20557857/per-buffer-text-wrap.tar.bz2
Comment 42 jessevdk@gmail.com 2009-03-05 09:01:05 UTC
*** Bug 574204 has been marked as a duplicate of this bug. ***
Comment 43 Urmas 2009-10-23 14:34:00 UTC
It's 2010 looming, and nothing is done. What the hell are you doing?!
Comment 44 Trent Bartlem 2009-10-24 00:51:32 UTC
At the very least, roll Henrique/Karl's plugin into the main gedit pkg.
Comment 45 christian 2010-06-12 09:24:11 UTC
i beg your pardon for advertizing my own plugin here:
http://hartmann-it-design.de/gedit/TextWrap/
Comment 46 Garrett Regier 2011-03-16 09:33:09 UTC
*** Bug 644894 has been marked as a duplicate of this bug. ***
Comment 47 Ignacio Casal Quinteiro (nacho) 2011-03-27 11:12:43 UTC
*** Bug 645793 has been marked as a duplicate of this bug. ***
Comment 48 Dmitry 2012-02-12 08:53:47 UTC
would be great to have wrapping 1) as menu entry 2) as hot-key combination
Comment 49 Urmas 2012-02-12 12:58:39 UTC
Can some of developers explain why this feature is not in after 9 years of requests?
Comment 50 Sébastien Wilmet 2013-05-17 18:07:46 UTC
*** Bug 700515 has been marked as a duplicate of this bug. ***
Comment 51 Paolo Borelli 2014-08-07 20:07:25 UTC
We have now a toggle to enable word wrapping per view from the statusbar button popover.

I think we can finally close this
Comment 52 James Arlow 2016-04-23 05:21:09 UTC
I have no `statusbar button popover` option for word wrap on Min 17.3 Rosa or Ubuntu 15.4/10.  What version is this feature supposed to be in?  Was it in an older version and got removed?

The only option I can locate is in the preferences menu, which is a cumbersome solution.  I often have multiple tabs.  Some which need word wrap and others which don't.  Having to enter the preferences every time I change tabs feels totally unreasonable.

I know there are plugins, but that solution doesn't scale to my multiple systems and organizations.

It really is a basic feature that needs to be front and center for all users.  Every plain text document is different and it's often the difference in whether or not a file from a third party is completely unreadable.  Windows notepad had it since god knows when.  It's the only preference I ever touch in a text editor.

I think the view menu is the best place for it, and an action button would be optional but nice.