longlines mode and kill-line: missing space between boundary words

longlines mode and kill-line: missing space between boundary words

[Jacek Chrząszcz]

Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing list.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

In longlines mode when I press C-k (i.e. a kill-line command) in a
long paragraph with soft linebreaks and then press C-y to yank the
killed line somewhere, the spaces between the words on soft-broken
lines' boundaries disapear.

For example: suppose the paragraph below has soft linebreaks (and not
hard) then when I put the cursor on the first line and press C-k C-y I
should get exactly the same paragraph.

Lazy fox jumped over crazy dogs Lazy fox jumped over crazy dogs Lazy
fox jumped over crazy dogs Lazy fox jumped over crazy dogs Lazy fox
jumped over crazy dogs Lazy fox jumped over crazy dogs Lazy fox jumped
over crazy dogs

And what I get is:

Lazy fox jumped over crazy dogs Lazy fox jumped over crazy dogs
Lazyfox jumped over crazy dogs Lazy fox jumped over crazy dogs Lazy
fox jumped over crazy dogs Lazy fox jumped over crazy dogs Lazy fox
jumped over crazy dogs

(with again soft-breaks at end of lines). Remark "Lazyfox" on the second line.

I guess after kill-line the longline mode automatically compresses the
soft-linebreak at the end of the line (because the space is
temporarily turned into a soft linebreak) and the information about
the space does not get into the kill ring.

The consistent behaviour would be either to add the missing space to
the kill ring or (it that is impossible or too hard) to kill the whole
paragraph at once (since it in fact is a single line). The first
behaviour clearly looks better to me.

Although I am using emacs 23 now (from
http://peadrop.com/blog/2007/01/06/pretty-emacs under Ubuntu 7.04), I
get the same behaviour in ubuntu-distributed emacs 21 as well.

Cheers,

Jacek

If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
If you would like to further debug the crash, please read the file
/usr/share/emacs/23.0.0/etc/DEBUG for instructions.


In GNU Emacs 23.0.0.1 (i486-pc-linux-gnu, GTK+ Version 2.10.11)
 of 2007-07-06 on helios
Windowing system distributor `The X.Org Foundation', version 11.0.70200000
configured using `configure  '--build' 'i486-linux-gnu' '--host'
'i486-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib'
'--libexecdir=/usr/lib' '--localstatedir=/var'
'--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes'
'--enable-locallisppath=/etc/emacs-snapshot:/etc/emacs:/usr/local/share/emacs/23.0.0/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/23.0.0/site-lisp:/usr/share/emacs/site-lisp:/usr/share/emacs/23.0.0/leim'
'--with-x=yes' '--with-x-toolkit=gtk' '--enable-font-backend'
'--with-xft' '--with-freetype' 'build_alias=i486-linux-gnu'
'host_alias=i486-linux-gnu' 'CC=gcc' 'CFLAGS=-DDEBIAN
-DSITELOAD_PURESIZE_EXTRA=5000 -g -O2''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: pl_PL.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default-enable-multibyte-characters: t

Major mode: Text

Minor modes in effect:
  longlines-mode: t
  shell-dirtrack-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  use-hard-newlines: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-compression-mode: t
  line-number-mode: t

Recent input:
<down-mouse-1> <mouse-1> C-x C-f p l i k <tab> . <tab>
t x t <return> <down-mouse-2> <mouse-2> s M-x l o n
g <tab> <return> <up> <up> C-a <right> <right> <right>
<right> SPC <up> C-k C-y <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <menu-bar>
<help-menu> <report-emacs-bug>

Recent messages:
Loading /usr/share/emacs/23.0.0/lisp/longlines.el.gz...
Loading jka-compr...done
uncompressing longlines.el.gz...done
Loading easy-mmode...done
Loading /usr/share/emacs/23.0.0/lisp/longlines.el.gz...done
Longlines mode enabled
Mark set
Loading emacsbug...
Loading regexp-opt...done
Loading emacsbug...done

Re: longlines mode and kill-line: missing space between boundary words

[martin rudalics]

 > In longlines mode when I press C-k (i.e. a kill-line command) in a
 > long paragraph with soft linebreaks and then press C-y to yank the
 > killed line somewhere, the spaces between the words on soft-broken
 > lines' boundaries disapear.
 >
...
 >
 > I guess after kill-line the longline mode automatically compresses the
 > soft-linebreak at the end of the line (because the space is
 > temporarily turned into a soft linebreak) and the information about
 > the space does not get into the kill ring.

Yes.  `kill-line' kills the line without the newline and longlines mode
removes the newline character after that.

 > The consistent behaviour would be either to add the missing space to
 > the kill ring or (it that is impossible or too hard) to kill the whole
 > paragraph at once (since it in fact is a single line). The first
 > behaviour clearly looks better to me.

I'm afraid that it's hardly possible to DTRT here.  Adding the space is
not quite correct since `kill-line' doesn't kill the newline character
which substitutes the space.  Note that you get a similar bug when you
kill the line + the newline character.  Reinserting the killed stretch
will get you a hard newline instead of the soft one.

Killing everything up to the next hard newline appears conceptually
right.  It would clash, however, with the current concept that a line
for `kill-line' is pretty much a line as it appears on the screen.
Moreover, `kill-line' would have to become aware of longlines' way of
distinguishing soft and hard newlines.

Re: longlines mode and kill-line: missing space between boundary words

[Kevin Rodgers]

martin rudalics wrote:
>  > In longlines mode when I press C-k (i.e. a kill-line command) in a
>  > long paragraph with soft linebreaks and then press C-y to yank the
>  > killed line somewhere, the spaces between the words on soft-broken
>  > lines' boundaries disapear.
>  >
> ...
>  >
>  > I guess after kill-line the longline mode automatically compresses the
>  > soft-linebreak at the end of the line (because the space is
>  > temporarily turned into a soft linebreak) and the information about
>  > the space does not get into the kill ring.
> 
> Yes.  `kill-line' kills the line without the newline and longlines mode
> removes the newline character after that.
> 
>  > The consistent behaviour would be either to add the missing space to
>  > the kill ring or (it that is impossible or too hard) to kill the whole
>  > paragraph at once (since it in fact is a single line). The first
>  > behaviour clearly looks better to me.
> 
> I'm afraid that it's hardly possible to DTRT here.  Adding the space is
> not quite correct since `kill-line' doesn't kill the newline character
> which substitutes the space.  Note that you get a similar bug when you
> kill the line + the newline character.  Reinserting the killed stretch
> will get you a hard newline instead of the soft one.
> 
> Killing everything up to the next hard newline appears conceptually
> right.  It would clash, however, with the current concept that a line
> for `kill-line' is pretty much a line as it appears on the screen.
> Moreover, `kill-line' would have to become aware of longlines' way of
> distinguishing soft and hard newlines.

Would it make sense for longlines mode to have a local keymap in which
C-k was bound to a new command (named longlines-kill-line, of course)
that is aware of longlines' way of distinguishing soft and hard
newlines?

-- 
Kevin Rodgers
Denver, Colorado, USA