bug#11759: 24.1.50; word-wrap should wrap on non-words if the current word is too long

bug#11759: 24.1.50; word-wrap should wrap on non-words if the current word is too long

[Ivan Andrus]

Setting word-wrap is generally a very nice addition and I like it even
when programming.  However it can cause annoying behavior when the
"words" are very long.  For example if the entire line is one "word" but
indented, which is not uncommon in some files that I regularly edit,
then the entire line is wrapped to the next line leaving a completely
blank visual line.  Arguably this is bad programming style, but it would
be nice if I could specify a maximum length for a "word".  If it would
require breaking longer than this limit, then it should break as if
word-wrap were off.

Below is a contrived example of what can cause problems when the buffer
is not sufficiently wide.

    this.long_method_name().another_method().what_an_impossibly_long_method_with_lots_of_arguments(1,2,3,4,[4,5,6,7,8,9]).and_no_spaces()

Thank,
Ivan

In GNU Emacs 24.1.50.1 (i386-apple-darwin10.8.0, NS apple-appkit-1038.36)
of 2012-06-19 on oroszlan.local
Bzr revision: 108664 eggert@cs.ucla.edu-20120619185739-mile4zpnjrqz5e8e
Windowing system distributor `Apple', version 10.3.1038
Configured using:
`configure '--with-ns' '-C''

Important settings:
  value of $EMACSDATA: /Users/gvol/vcs/emacs/local/nextstep/Emacs.app/Contents/Resources/etc
  value of $EMACSDOC: /Users/gvol/vcs/emacs/local/nextstep/Emacs.app/Contents/Resources/etc
  value of $EMACSLOADPATH: /Users/gvol/vcs/emacs/local/nextstep/Emacs.app/Contents/Resources/site-lisp:/Users/gvol/vcs/emacs/local/nextstep/Emacs.app/Contents/Resources/lisp:/Users/gvol/vcs/emacs/local/nextstep/Emacs.app/Contents/Resources/leim
  value of $EMACSPATH: /Users/gvol/vcs/emacs/local/nextstep/Emacs.app/Contents/MacOS/libexec:/Users/gvol/vcs/emacs/local/nextstep/Emacs.app/Contents/MacOS/bin
  locale-coding-system: nil
  default enable-multibyte-characters: t

Major mode: Org

Minor modes in effect:
  diff-auto-refine-mode: t
  reveal-mode: t
  drag-stuff-global-mode: t
  TeX-PDF-mode: t
  which-function-mode: t
  show-paren-mode: t
  recentf-mode: t
  msb-mode: t
  minibuffer-depth-indicate-mode: t
  ido-everywhere: t
  global-hl-line-mode: t
  delete-selection-mode: t
  auto-image-file-mode: t
  auto-insert-mode: t
  yas/global-mode: t
  yas/minor-mode: t
  shell-dirtrack-mode: t
  global-visible-mark-mode: t
  visible-mark-mode: t
  gvol-mode: t
  desktop-save-mode: t
  command-frequency-autosave-mode: t
  command-frequency-mode: t
  itunes-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
v v F i x e d SPC a SPC f e w SPC t h i n g s SPC r
e SPC t h e SPC n e w SPC C-u C-u <C-backspace> w r
t SPC C-e p y t h o n . e l C-u C-u C-u <C-backspace>
C-/ C-c C-c <C-tab> g <C-tab> <C-tab> q M-w g <C-tab>
C-x v d <return> = C-c C-w C-. C-. C-. <C-tab> v q
M-w M-w <C-tab> M-x v c - r e v <tab> e r <tab> <return>
y e <return> y e s <return> <C-tab> C-c C-f <C-tab>
C-3 C-e <C-tab> M-w C-x C-f C-d g p <return> C-c C-f
M-w n n n s-o * . e l c <return> D y e s <return> n
<return> C-c C-f M-w n <return> C-c C-f M-w n <return>
C-c C-f M-w n <return> M-w n <return> C-c C-f M-w n
<return> C-c C-f <C-tab> TAB TAB TAB M-k M-k M-k M-w
<C-tab> M-w n <return> C-c C-f M-w n <return> C-c C-f
M-w <down-mouse-1> <mouse-1> C-k C-k C-k C-k C-M-o
C-M-j <wheel-down> <down-mouse-1> <mouse-1> <wheel-down>
<double-wheel-down> <triple-wheel-down> <wheel-down>
<wheel-down> <wheel-down> C-x C-c n C-g q M-w C-x r
j p C-g C-x r j b C-s p a t h C-s C-s C-o C-o C-o C-o
C-o C-o C-o C-o C-o C-o C-o C-o C-o C-k C-k C-k C-k
C-k C-k C-k C-k TAB TAB TAB TAB TAB TAB TAB TAB TAB
C-s C-w M-o C-a C-s o n o C-s C-s C-a <C-tab> q <C-tab>
q q q g p p p p p p p p p p p p p p p d x y e s <return>
<C-tab> q g M-w <C-tab> M-w M-x r e p o r <tab> <r
eturn>

Recent messages:
/Users/gvol/.passwords.gpg
Entering debugger...
Mark saved where search started
Searched 1 buffer; 29 matches for `path'
Mark saved where search started [2 times]
Back to top level.
NOTE: Deletion of files flagged `D' (not those marked `*')
Deleting...done
/Users/gvol/.bashrc
/Users/gvol/.emacs-uptimes

Load-path shadows:
/Users/gvol/.emacs.d/elpa/parenface-20091203/parenface hides ~/.emacs.d/local/parenface
/Users/gvol/.emacs.d/elpa/hl-sexp-1.0.0/hl-sexp hides ~/.emacs.d/local/hl-sexp
/Users/gvol/.emacs.d/elpa/python-mode-6.0.3/highlight-indentation hides ~/.emacs.d/local/highlight-indentation
/Users/gvol/.emacs.d/elpa/command-frequency-1.1/command-frequency hides ~/.emacs.d/local/command-frequency
/Users/gvol/vcs/sage-mode/emacs/.dir-locals hides /Users/gvol/vcs/emacs/local/nextstep/Emacs.app/Contents/Resources/lisp/gnus/.dir-locals
~/.emacs.d/local/lisp-mnt hides /Users/gvol/vcs/emacs/local/nextstep/Emacs.app/Contents/Resources/lisp/emacs-lisp/lisp-mnt

Features:
(shadow sort mail-extr emacsbug message rfc822 mml mml-sec mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail rfc2047 rfc2045 ietf-drums mail-utils epa-file epa epg
epg-config ruby-mode vc-svn vc-dir ewoc sage-load vc-git sage-test
sage-imenu flymake sage-build sage-auctex pyrex cython-mode sage-view
repeat smerge-mode diff-mode grep sage-mode debug reftex-cite apropos
autoload hideshow-org hideshow python elide-head vc-bzr dabbrev align
reftex-sel reftex-parse reftex-ref vcursor subword texmathp
multi-isearch compile sh-script smie latexenc gap-mode gap-process
highlight-parentheses highlight-symbol thingatpt hi-lock conf-mode
parse-time vc-cvs sgml-mode ffap url-parse url-vars ibuf-macs ibuf-ext
ibuffer eldoc greedy-delete gvol-light-theme tabify cal-iso executable
org-mobile org-archive org-id reveal org-habit org-wl org-w3m org-vm
org-rmail org-mhe org-mew org-irc org-jsinfo org-infojs org-html org-exp
ob-exp org-exp-blocks find-func org-agenda org-info org-gnus org-docview
org-bibtex bibtex org-bbdb org-crypt ob-python org ob-emacs-lisp
ob-tangle ob-ref ob-lob ob-table org-footnote org-src ob-comint ob-keys
ob ob-eval org-pcomplete org-list org-faces org-compat org-entities
org-macs drag-stuff vc-hg reftex-vcr reftex-dcr reftex-auc reftex
reftex-vars preview prv-emacs adaptive-wrap tex-fold tex-bar tex-buf
toolbar-x noutline outline font-latex latex tex-style tex time
ac-slime-autoloads adaptive-wrap-autoloads applescript-mode-autoloads
auctex-autoloads tex-site info browse-kill-ring-autoloads
buffer-move-autoloads c-eldoc-autoloads columnify-autoloads
command-frequency-autoloads company-autoloads drag-stuff-autoloads
durendal-autoloads emstar-autoloads feature-mode-autoloads
goto-last-change-autoloads graphviz-dot-mode-autoloads
highlight-parentheses-autoloads highlight-symbol-autoloads
hl-sexp-autoloads keyfreq-autoloads finder-inf markdown-mode+-autoloads
markdown-mode-autoloads paredit-autoloads parenface-autoloads
python-mode-autoloads redo+-autoloads rw-hunspell-autoloads
scpaste-autoloads htmlize-autoloads scss-mode-autoloads
slime-clj-autoloads slime-fuzzy-autoloads slime-ritz-autoloads
smex-autoloads speck-autoloads swank-clojure-autoloads
clojure-mode-autoloads slime-repl-autoloads slime-autoloads
xml-rpc-autoloads package jka-compr saveplace uniquify which-func imenu
paren recentf tree-widget wid-edit msb mb-depth ido icomplete hl-line
delsel image-file cus-start cus-load diary-lib diary-loaddefs cal-menu
calendar cal-loaddefs warnings autoinsert yasnippet dropdown-list
derived help-mode view tramp tramp-compat auth-source eieio byte-opt
bytecomp byte-compile cconv gnus-util mm-util mail-prsvr password-cache
shell pcomplete comint ansi-color format-spec tramp-loaddefs
visible-mark parenface fold commit-patch-buffer log-edit ring pcvs-util
add-log vc ediff vc-dispatcher sage cl-macs cl macroexp cl-lib rx xml
desktop backtr command-frequency uptimes pp server easy-mmode assoc
dired+ edmacro kmacro dired-x easymenu ediff-merg ediff-diff ediff-wind
ediff-mult ediff-help ediff-init ediff-util dired-aux dired advice
help-fns advice-preload windmove time-date tooltip ediff-hook vc-hooks
lisp-float-type mwheel ns-win tool-bar dnd fontset image regexp-opt
fringe tabulated-list newcomment lisp-mode register page menu-bar
rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax
facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak
czech european ethiopic indian cyrillic chinese case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer loaddefs button faces
cus-face files text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget hashtable-print-readable backquote
make-network-process ns multi-tty emacs)

bug#11759: 24.1.50; word-wrap should wrap on non-words if the current word is too long

[Stefan Monnier]

> Setting word-wrap is generally a very nice addition and I like it even
> when programming.  However it can cause annoying behavior when the
> "words" are very long.  For example if the entire line is one "word" but
> indented, which is not uncommon in some files that I regularly edit,
> then the entire line is wrapped to the next line leaving a completely
> blank visual line.  Arguably this is bad programming style, but it would
> be nice if I could specify a maximum length for a "word".  If it would
> require breaking longer than this limit, then it should break as if
> word-wrap were off.

I also use word-wrap everywhere, including programming modes and see the
same problem.  A word-size-limit might do the trick, but there are a few
cases where we don't even need that, I think:

- if the word is the first non-blank char on the line, wrapping to the
  next line results in a visually empty line, losing the
  indentation info.
- if the word is wider than the window (plus the wrap-prefix), then even
  after word-wrapping it to the next line, it gets char-wrapped anyway,
  so we didn't win anything.

I don't know if those two cases cover all interesting situations, but at
least I think it's worth trying to address them first.


        Stefan

bug#11759: 24.1.50; word-wrap should wrap on non-words if the current word is too long

[Chong Yidong]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> if the entire line is one "word" but indented, which is not uncommon
>> in some files that I regularly edit, then the entire line is wrapped
>> to the next line leaving a completely blank visual line.
>
> I also use word-wrap everywhere, including programming modes and see the
> same problem.
>
> - if the word is the first non-blank char on the line, wrapping to the
>   next line results in a visually empty line, losing the
>   indentation info.
> - if the word is wider than the window (plus the wrap-prefix), then even
>   after word-wrapping it to the next line, it gets char-wrapped anyway,
>   so we didn't win anything.

FWIW, word wrap behaves the same way in other editors (checked with
gedit and with a text box in Firefox).

bug#11759: 24.1.50; word-wrap should wrap on non-words if the current word is too long

[Lennart Borgman]

On Sat, Jun 23, 2012 at 1:14 PM, Chong Yidong <cyd@gnu.org> wrote:
> Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
>
>>> if the entire line is one "word" but indented, which is not uncommon
>>> in some files that I regularly edit, then the entire line is wrapped
>>> to the next line leaving a completely blank visual line.
>>
>> I also use word-wrap everywhere, including programming modes and see the
>> same problem.
>>
>> - if the word is the first non-blank char on the line, wrapping to the
>>   next line results in a visually empty line, losing the
>>   indentation info.
>> - if the word is wider than the window (plus the wrap-prefix), then even
>>   after word-wrapping it to the next line, it gets char-wrapped anyway,
>>   so we didn't win anything.
>
> FWIW, word wrap behaves the same way in other editors (checked with
> gedit and with a text box in Firefox).

I think it will be very nice if such long words could wrap. It would
also be nice to have the alternative to truncate such long words.
(They are often URL in my case and truncating them with the full URL
as a help string would be fine.)

bug#11759: 24.1.50; word-wrap should wrap on non-words if the current word is too long

[Eli Zaretskii]

> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Sat, 23 Jun 2012 13:27:20 +0200
> Cc: Ivan Andrus <darthandrus@gmail.com>, 11759@debbugs.gnu.org
> 
> On Sat, Jun 23, 2012 at 1:14 PM, Chong Yidong <cyd@gnu.org> wrote:
> > Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
> >
> >>> if the entire line is one "word" but indented, which is not uncommon
> >>> in some files that I regularly edit, then the entire line is wrapped
> >>> to the next line leaving a completely blank visual line.
> >>
> >> I also use word-wrap everywhere, including programming modes and see the
> >> same problem.
> >>
> >> - if the word is the first non-blank char on the line, wrapping to the
> >>   next line results in a visually empty line, losing the
> >>   indentation info.
> >> - if the word is wider than the window (plus the wrap-prefix), then even
> >>   after word-wrapping it to the next line, it gets char-wrapped anyway,
> >>   so we didn't win anything.
> >
> > FWIW, word wrap behaves the same way in other editors (checked with
> > gedit and with a text box in Firefox).
> 
> I think it will be very nice if such long words could wrap.

They already do, please check the actual Emacs behavior.

bug#11759: 24.1.50; word-wrap should wrap on non-words if the current word is too long

[Lennart Borgman]

On Sat, Jun 23, 2012 at 2:48 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Lennart Borgman <lennart.borgman@gmail.com>
>> Date: Sat, 23 Jun 2012 13:27:20 +0200
>> Cc: Ivan Andrus <darthandrus@gmail.com>, 11759@debbugs.gnu.org
>>
>> On Sat, Jun 23, 2012 at 1:14 PM, Chong Yidong <cyd@gnu.org> wrote:
>> > Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
>> >
>> >>> if the entire line is one "word" but indented, which is not uncommon
>> >>> in some files that I regularly edit, then the entire line is wrapped
>> >>> to the next line leaving a completely blank visual line.
>> >>
>> >> I also use word-wrap everywhere, including programming modes and see the
>> >> same problem.
>> >>
>> >> - if the word is the first non-blank char on the line, wrapping to the
>> >>   next line results in a visually empty line, losing the
>> >>   indentation info.
>> >> - if the word is wider than the window (plus the wrap-prefix), then even
>> >>   after word-wrapping it to the next line, it gets char-wrapped anyway,
>> >>   so we didn't win anything.
>> >
>> > FWIW, word wrap behaves the same way in other editors (checked with
>> > gedit and with a text box in Firefox).
>>
>> I think it will be very nice if such long words could wrap.
>
> They already do, please check the actual Emacs behavior.

Oh, I see. I never noticed the char-wrap since behaviour Stefan told
about just makes me avoid such troubles (it is in org-mode I have seen
it).

Anyway, word truncation would be a good alternative at least for me.

bug#11759: 24.1.50; word-wrap should wrap on non-words if the current word is too long

[Stefan Monnier]

>> - if the word is the first non-blank char on the line, wrapping to the
>> next line results in a visually empty line, losing the
>> indentation info.
>> - if the word is wider than the window (plus the wrap-prefix), then even
>> after word-wrapping it to the next line, it gets char-wrapped anyway,
>> so we didn't win anything.

> FWIW, word wrap behaves the same way in other editors (checked with
> gedit and with a text box in Firefox).

But Emacs should behave better.
Another case I find annoying is when I have a long space at the end of
a line, where it causes the last word on that line to be wrapped to the
next line: wrapping is unavoidable, but I'd rather it be done after
the last word than before.


        Stefan