GNOME Bugzilla – Bug 119428
[ui-review] word wrap should have a menu entry.
Last modified: 2016-04-23 05:21:09 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.
[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.
*** Bug 128650 has been marked as a duplicate of this bug. ***
*** Bug 125910 has been marked as a duplicate of this bug. ***
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.
*** Bug 313621 has been marked as a duplicate of this bug. ***
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?
*** Bug 317731 has been marked as a duplicate of this bug. ***
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
[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... :/
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.
> 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.
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
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
> 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.
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.
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.
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
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.
[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]
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
(should have said 'line wrapping' in my comments above)
*** Bug 162044 has been marked as a duplicate of this bug. ***
Adding a "I-want-this-feature-too"
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?
*** Bug 399830 has been marked as a duplicate of this bug. ***
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!
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
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
(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.
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.
(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.
(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.
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.
(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"!
(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!
+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.
*** Bug 462699 has been marked as a duplicate of this bug. ***
*** Bug 543911 has been marked as a duplicate of this bug. ***
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
*** Bug 561735 has been marked as a duplicate of this bug. ***
I have uploaded my above-referenced plugin to a more stable location on Launchpad: http://launchpadlibrarian.net/20557857/per-buffer-text-wrap.tar.bz2
*** Bug 574204 has been marked as a duplicate of this bug. ***
It's 2010 looming, and nothing is done. What the hell are you doing?!
At the very least, roll Henrique/Karl's plugin into the main gedit pkg.
i beg your pardon for advertizing my own plugin here: http://hartmann-it-design.de/gedit/TextWrap/
*** Bug 644894 has been marked as a duplicate of this bug. ***
*** Bug 645793 has been marked as a duplicate of this bug. ***
would be great to have wrapping 1) as menu entry 2) as hot-key combination
Can some of developers explain why this feature is not in after 9 years of requests?
*** Bug 700515 has been marked as a duplicate of this bug. ***
We have now a toggle to enable word wrapping per view from the statusbar button popover. I think we can finally close this
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.