bug#13273: 24.3.50; [PATCH] enhancement request: repeatable `visual-line-mode' line movements

bug#13273: 24.3.50; [PATCH] enhancement request: repeatable `visual-line-mode' line movements

[Drew Adams]

[-- Attachment #1: Type: text/plain, Size: 1885 bytes --]

The attached patch does the following:
 
1. Redefines commands `beginning-of-visual-line' and
   `end-of-visual-line', so that they are repeatable.
 
2. Redefines commands `beginning-of-line' and `end-of-line', so that
   they are repeatable.
 
3. Removes the remapping of commands `move-beginning-of-line' and
   `move-end-of-line' to `beginning-of-visual-line' and
   `end-of-visual-line' - see next.
 
4. In place of those remappings, makes these key bindings for
   `visual-line-mode':
 
   * `home' - `beginning-of-line'
   * `end'  - `end-of-line'
   * `C-a'  - `beginning-of-visual-line'
   * `C-e'  - `end-of-visual-line'
 
Each of these keys gets a repeatable command.  `home' and `end' move
among logical lines.  `C-a' and `C-e' move among visual lines.  Both
kinds of movement are useful in `visual-line-mode'.
 
NOTE: The attatched patch does not remove the C source code definitions
of `beginning-of-line' and `end-of-line', but that would need to be
done.  I do not have the C sources and do not want to fiddle with C.  I
assume it will be easy for someone else to remove those definitions.
(These commands do not belong in C anyway.)
 
In GNU Emacs 24.3.50.1 (i386-mingw-nt5.1.2600)
 of 2012-12-18 on MS-W7-DANI
Bzr revision: 111265 eliz@gnu.org-20121218190556-x9wmq083vwecgu0f
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (4.7) --no-opt --enable-checking --cflags
 -Ic:/emacs/libs/libXpm-3.5.10/include -Ic:/emacs/libs/libXpm-3.5.10/src
 -Ic:/emacs/libs/libpng-dev_1.4.3-1_win32/include
 -Ic:/emacs/libs/zlib-dev_1.2.5-2_win32/include
 -Ic:/emacs/libs/giflib-4.1.4-1-lib/include
 -Ic:/emacs/libs/jpeg-6b-4-lib/include
 -Ic:/emacs/libs/tiff-3.8.2-1-lib/include
 -Ic:/emacs/libs/libxml2-2.7.8-w32-bin/include/libxml2
 -Ic:/emacs/libs/gnutls-3.0.9-w32-bin/include
 -Ic:/emacs/libs/libiconv-1.9.2-1-lib/include'

[-- Attachment #2: simple-2012-12-24.patch --]
[-- Type: application/octet-stream, Size: 6674 bytes --]

diff -c c\:/foo/simple.el c\:/foo/simple-patched-2012-12-24.el
*** c:/foo/simple.el	Mon Dec 24 13:48:06 2012
--- c:/foo/simple-patched-2012-12-24.el	Mon Dec 24 14:13:14 2012
***************
*** 819,824 ****
--- 819,854 ----
  	 (overlay-recenter (point))
  	 (recenter -3))))
  
+ (defun end-of-line (&optional n)
+   "Move cursor to end of current line or end of next line if repeated.
+ If called interactively with no prefix arg:
+  If the previous command was also `end-of-line' then move to the
+  end of the next line.  Else move to the end of the current line.
+ Otherwise, move to the end of the Nth next line (Nth previous line
+  if N <0 )."
+   (interactive
+    (list (if current-prefix-arg (prefix-numeric-value current-prefix-arg) 0)))
+   (unless n (setq n  0))                ; non-interactive with no arg
+   (if (and (eq this-command last-command)  (not current-prefix-arg))
+       (forward-line 1)
+     (forward-line n))
+   (let ((inhibit-field-text-motion  t))  (end-of-line)))
+ 
+ (defun beginning-of-line (&optional n)
+   "Move cursor to beginning of current line or next line if repeated.
+ If called interactively with no prefix arg:
+  If the previous command was also `beginning-of-line' then move to the
+  beginning of the previous line.  Else move to the beginning of the
+  current line.
+ Otherwise, move to the beginning of the Nth previous line (Nth next
+  line if N < 0)."
+   (interactive
+    (list (if current-prefix-arg (prefix-numeric-value current-prefix-arg) 0)))
+   (unless n (setq n  0))                ; non-interactive with no arg
+   (if (and (eq this-command last-command)  (not current-prefix-arg))
+       (forward-line -1)
+     (forward-line (- n))))
+ 
  (defcustom delete-active-region t
    "Whether single-char deletion commands delete an active region.
  This has an effect only if Transient Mark mode is enabled, and
***************
*** 5007,5036 ****
  ;;; Editing based on visual lines, as opposed to logical lines.
  
  (defun end-of-visual-line (&optional n)
!   "Move point to end of current visual line.
! With argument N not nil or 1, move forward N - 1 visual lines first.
! If point reaches the beginning or end of buffer, it stops there.
! To ignore intangibility, bind `inhibit-point-motion-hooks' to t."
!   (interactive "^p")
!   (or n (setq n 1))
!   (if (/= n 1)
!       (let ((line-move-visual t))
! 	(line-move (1- n) t)))
    ;; Unlike `move-beginning-of-line', `move-end-of-line' doesn't
    ;; constrain to field boundaries, so we don't either.
    (vertical-motion (cons (window-width) 0)))
  
  (defun beginning-of-visual-line (&optional n)
!   "Move point to beginning of current visual line.
! With argument N not nil or 1, move forward N - 1 visual lines first.
  If point reaches the beginning or end of buffer, it stops there.
! To ignore intangibility, bind `inhibit-point-motion-hooks' to t."
!   (interactive "^p")
!   (or n (setq n 1))
!   (let ((opoint (point)))
!     (if (/= n 1)
! 	(let ((line-move-visual t))
! 	  (line-move (1- n) t)))
      (vertical-motion 0)
      ;; Constrain to field boundaries, like `move-beginning-of-line'.
      (goto-char (constrain-to-field (point) opoint (/= n 1)))))
--- 5037,5083 ----
  ;;; Editing based on visual lines, as opposed to logical lines.
  
  (defun end-of-visual-line (&optional n)
!   "Move cursor to end of current visual line, or end of next if repeated.
! If point reaches the beginning or end of buffer, stop there.
! To ignore intangibility, bind `inhibit-point-motion-hooks' to t.
! 
! If called interactively with no prefix argument:
!  If the previous command was also `end-of-visual-line', then move to
!  the end of the next visual line.  Else move to end of current one.
! Otherwise, move to the end of the Nth next visual line (Nth previous
!  one if N < 0)."
!   (interactive
!    (list (if current-prefix-arg (prefix-numeric-value current-prefix-arg) 0)))
!   (unless n (setq n  0))                 ; non-interactive with no arg 
!   (let ((line-move-visual  t))
!     (if (and (eq this-command last-command)  (not current-prefix-arg))
!         (line-move 1 t)
!       (line-move n t)))
    ;; Unlike `move-beginning-of-line', `move-end-of-line' doesn't
    ;; constrain to field boundaries, so we don't either.
    (vertical-motion (cons (window-width) 0)))
  
  (defun beginning-of-visual-line (&optional n)
!   "Move cursor to beginning of current visual line or next if repeated.
  If point reaches the beginning or end of buffer, it stops there.
! To ignore intangibility, bind `inhibit-point-motion-hooks' to t.
! 
! With argument N, move backward N visual lines.
! 
! If called interactively with no prefix argument:
!  If the previous command was also `beginning-of-visual-line', then
!  move to the beginning of the previous visual line.  Else move to the
!  beginning of the current visual line.
! Otherwise, move to the beginning of the Nth previous visual line
!  (Nth next one if N < 0)."
!   (interactive
!    (list (if current-prefix-arg (prefix-numeric-value current-prefix-arg) 0)))
!   (unless n (setq n  0))                 ; non-interactive with no arg
!   (let ((opoint  (point)))
!     (let ((line-move-visual  t))
!       (if (and (eq this-command last-command)  (not current-prefix-arg))
!           (line-move -1 t)
!         (line-move n t)))
      (vertical-motion 0)
      ;; Constrain to field boundaries, like `move-beginning-of-line'.
      (goto-char (constrain-to-field (point) opoint (/= n 1)))))
***************
*** 5098,5105 ****
  (defvar visual-line-mode-map
    (let ((map (make-sparse-keymap)))
      (define-key map [remap kill-line] 'kill-visual-line)
!     (define-key map [remap move-beginning-of-line] 'beginning-of-visual-line)
!     (define-key map [remap move-end-of-line]  'end-of-visual-line)
      ;; These keybindings interfere with xterm function keys.  Are
      ;; there any other suitable bindings?
      ;; (define-key map "\M-[" 'previous-logical-line)
--- 5145,5154 ----
  (defvar visual-line-mode-map
    (let ((map (make-sparse-keymap)))
      (define-key map [remap kill-line] 'kill-visual-line)
!     (define-key map [home] 'beginning-of-line)
!     (define-key map [end]  'end-of-line)
!     (define-key map "\C-a" 'beginning-of-visual-line)
!     (define-key map "\C-e" 'end-of-visual-line)
      ;; These keybindings interfere with xterm function keys.  Are
      ;; there any other suitable bindings?
      ;; (define-key map "\M-[" 'previous-logical-line)

Diff finished.  Mon Dec 24 21:13:36 2012

bug#13273: 24.3.50; [PATCH] enhancement request: repeatable `visual-line-mode' line movements

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Mon, 24 Dec 2012 14:27:14 -0800
> 
>    * `home' - `beginning-of-line'
>    * `end'  - `end-of-line'
>    * `C-a'  - `beginning-of-visual-line'
>    * `C-e'  - `end-of-visual-line'

I think it would be better the other way around: leave C-a and C-e
move by physical lines, and make Home and End move by visual lines,
which I think is consistent with other applications.

bug#13273: 24.3.50; [PATCH] enhancement request: repeatable `visual-line-mode' line movements

[Drew Adams]

> >    * `home' - `beginning-of-line'
> >    * `end'  - `end-of-line'
> >    * `C-a'  - `beginning-of-visual-line'
> >    * `C-e'  - `end-of-visual-line'
> 
> I think it would be better the other way around: leave C-a and C-e
> move by physical lines, and make Home and End move by visual lines,
> which I think is consistent with other applications.

OK, go for it, please.  Doesn't matter to me either way.  I was thinking of
`home' and `end' as being the stronger, more distant movements, based on their
names and based on (I guess misunderstanding) some of the discussion in
emacs-devel.  I am certainly no expert on what the "standard"/"conventional"
meanings are.

bug#13273: 24.3.50; [PATCH] enhancement request: repeatable `visual-line-mode' line movements

[Drew Adams]

> > >    * `home' - `beginning-of-line'
> > >    * `end'  - `end-of-line'
> > >    * `C-a'  - `beginning-of-visual-line'
> > >    * `C-e'  - `end-of-visual-line'
> > 
> > I think it would be better the other way around: leave C-a and C-e
> > move by physical lines, and make Home and End move by visual lines,
> > which I think is consistent with other applications.
> 
> OK, go for it, please.  Doesn't matter to me either way.  I 
> was thinking of `home' and `end' as being the stronger, more 
> distant movements, based on their names and based on (I guess 
> misunderstanding) some of the discussion in emacs-devel.  I 
> am certainly no expert on what the "standard"/"conventional" 
> meanings are.

However, I wonder what most Emacs users would really prefer.

To be clear, I don't use visual line mode, and I have no preference regarding
it.

But I would imagine that:

1. It is more common in visual line mode to want to move incrementally up/down
visual line bols/eols than it is to move incrementatlly up/down logical line
bols/eols.

2. Emacs users, who are used to `C-a' and `C-e', would generally prefer to use
`C-a' and `C-e' for this repeat-movement, rather than `home' and `end'.

If #1 and #2 are true, then which is more important: (a) to preserve the same
bindings as externally, for those who are used to using `home' & `end' for this
or (b) to provide Emacs-traditional keys, `C-a' & `C-e' for this more common
bol/eol movement (visual)?

IOW, I would think that for Emacs users used to `C-a' & `C-e' what I sent in the
patch is preferable, but for users used to other apps what you suggest is
preferable.

Again, it does not really matter to me.  Someone else might have stronger
arguments that what I see, and someone else would anyway need to decide.  I only
hope that the two functionalities do get installed, so users of visual-line mode
get repeatable bol/eol movements.

---

Outside of visual line mode, I think that `C-a' and `C-e' (and maybe `home' and
`end'?) should also be repeatable, in the same way.  (But here there is no
difference between visual and logical bol/eol.)

In my own use I bind the same redefined commands `beginning-of-line' and
`end-of-line' to `C-a' and `C-e' globally.  Well, actually I do not redefine
those commands for my use.  Instead, I name the repeatable commands I wrote
`beginning-of-line+' and `end-of-line+', and I bind those to `C-a' and `C-e'.
But they are the same definitions that I called `beginning-of-line' and
`end-of-line' in the patch.

However, I am totally unclear about what `move-beginning-of-line' and
`move-end-of-line' are for and how they differ from `beginning-of-line' and
`end-of-line'.  What's that all about?

I cannot understand the doc well enough to figure out what the differences are
or why these new commands were added (and why they replace the older commands
only as bindings, instead of just redefining the older commands, IOW, why have
two sets of commands).

My real request is, I guess, that users get repeatable bol/eol movement commands
for both non visual line mode and visual line mode.  And preferably the same
keys.  For v-m mode there can be two different behaviors - the ones I defined,
for logical and visual line bol/eol.  For non v-m mode (globally) there is only
one behavior: logical (= visual).

I would like to see `C-a' & `C-e' kept for non v-m mode, at least.  Perhaps I
sent the wrong patch for that, thinking that my redefinition of
`beginning-of-line' and `end-of-line' would be bound to `C-a' and `C-e' globally
(and perhaps also to `home' and `end' globally).

But maybe it is `move-beginning-of-line' & `move-end-of-line', instead, that
should be patched to be repeatable?  In any case, the aim was to have `C-a' and
`C-e' be repeatable (globally as well as in v-m mode).

What is the reason for `move-beginning-of-line' & `move-end-of-line' as separate
commands from `beginning-of-line' and `end-of-line', and why did the latter pair
lose the key bindings?

bug#13273: 24.3.50; [PATCH] enhancement request: repeatable `visual-line-mode' line movements

[Vitalie Spinu]

May I also suggest yet a another user pattern: in visual line mode, on
repeated invocation move to next _logical_ line. That is, C-a moves to
beginning of visual line, but C-a C-a moves to the beginning of logical
line. May be it could be an user option, something like
repeated-line-movement-pattern.


  >> "Drew Adams" <drew.adams@oracle.com>
  >> on Tue, 25 Dec 2012 22:32:26 -0800 wrote:

  >> > >    * `home' - `beginning-of-line'
  >> > >    * `end'  - `end-of-line'
  >> > >    * `C-a'  - `beginning-of-visual-line'
  >> > >    * `C-e'  - `end-of-visual-line'
  >> > 
  >> > I think it would be better the other way around: leave C-a and C-e
  >> > move by physical lines, and make Home and End move by visual lines,
  >> > which I think is consistent with other applications.
  >> 
  >> OK, go for it, please.  Doesn't matter to me either way.  I 
  >> was thinking of `home' and `end' as being the stronger, more 
  >> distant movements, based on their names and based on (I guess 
  >> misunderstanding) some of the discussion in emacs-devel.  I 
  >> am certainly no expert on what the "standard"/"conventional" 
  >> meanings are.

  > However, I wonder what most Emacs users would really prefer.

  > To be clear, I don't use visual line mode, and I have no preference regarding
  > it.

  > But I would imagine that:

  > 1. It is more common in visual line mode to want to move incrementally up/down
  > visual line bols/eols than it is to move incrementatlly up/down logical line
  > bols/eols.

Indeed this is the case, otherwise why would you need visual-line-mode
in the first place? With wrapping at window edge (aka truncate-lines set
to nil) C-a and C-e move according to logical lines. If also in
visual-line-mode C-a/C-e would start moving on logical lines, that would
make these two modes highly redundant.


    Vitalie

bug#13273: 24.3.50; [PATCH] enhancement request: repeatable `visual-line-mode' line movements

[Drew Adams]

> May I also suggest yet a another user pattern: in visual line mode, on
> repeated invocation move to next _logical_ line. That is, C-a moves to
> beginning of visual line, but C-a C-a moves to the beginning 
> of logical line. May be it could be an user option, something like
> repeated-line-movement-pattern.

Hi Vitalie.  Did you try the patch?

Maybe I'm missing something, but I think that with the key bindings the patch
makes, `home' and `end' should do what you are requesting.

But I'm not sure I fully understand what "logical" line means.  I understand it
to be the same as the line limits when visual-line mode is turned off.  Anyway,
that's what the patch bindings for `home' and `end' do: move to the beginning
and end of the actual line as determined by newline char as a separator.

(`C-a' and `C-e' move to the beginning and end of the visual lines, in the
patch).

bug#13273: 24.3.50; [PATCH] enhancement request: repeatable `visual-line-mode' line movements

[Vitalie Spinu]

  >> "Drew Adams" <drew.adams@oracle.com>
  >> on Thu, 27 Dec 2012 08:16:58 -0800 wrote:

  >> May I also suggest yet a another user pattern: in visual line mode, on
  >> repeated invocation move to next _logical_ line. That is, C-a moves to
  >> beginning of visual line, but C-a C-a moves to the beginning 
  >> of logical line. May be it could be an user option, something like
  >> repeated-line-movement-pattern.

Yet, another pattern: repeated invocations of C-a cycle between visual
and logical bols.

  > Maybe I'm missing something, but I think that with the key bindings the patch
  > makes, `home' and `end' should do what you are requesting.

Indeed they do, but home/end are inconvenient keys. I very much like the
idea of the repeated invocation of C-a doing something more than just
staying at the beginning of line.

The point is that I don't find moving to the next/previous line a very
useful feature. C-p/C-n do just that.

What I propose is to be able to use the same key (C-a) for jumping to
both, visual and logical bols according to some user specified rule
(cycling for example). And your patch is very close to making that
possible.


  > But I'm not sure I fully understand what "logical" line means.  I understand it
  > to be the same as the line limits when visual-line mode is turned off.  Anyway,
  > that's what the patch bindings for `home' and `end' do: move to the beginning
  > and end of the actual line as determined by newline char as a separator.

Yes, that is the meaning of given in the doc string of
`visual-line-mode'

   When Visual Line mode is enabled, `word-wrap' is turned on in
   this buffer, and simple editing commands are redefined to act on
   visual lines, not logical lines.  See Info node `Visual Line
   Mode' for details.


  Thanks, 
  Vitalie

bug#13273: 24.3.50; [PATCH] enhancement request: repeatable `visual-line-mode' line movements

[Drew Adams]

Again, so I can better understand your messages, did you try the patch?

> Yet, another pattern: repeated invocations of C-a cycle between visual
> and logical bols.

Is that a suggestion of something you want or a complaint about what you see
happening with the patch?

>   > Maybe I'm missing something, but I think that with the 
>   > key bindings the patch makes, `home' and `end' should do what you
>   > are requesting.
> 
> Indeed they do, but home/end are inconvenient keys. 

I agree.  But the idea was to (a) make the home/end bindings compatible with
what some users expect from outside Emacs, but also (b) make them repeatable.

My only request is that we give repeatable commands to all of `C-a', `C-e',
`home', and `end' for visual line mode and also globally.  Which keys get which
bindings is less important to me.  But I happen to agree with you, personally,
that I would use `C-a' and `C-e', not `home' and `end'.

> I very much like the idea of the repeated invocation of C-a doing something
> more than just staying at the beginning of line.

Right.  That's the idea.

> The point is that I don't find moving to the next/previous line a very
> useful feature. C-p/C-n do just that.

They do not track bol/eol.  If you mean first do `C-a' then `C-p C-p ...', then
OK.  I personally find that less convenent than just holding down `C-a'.   And
for eol it doesn't work at all, because of different line lengths.

> What I propose is to be able to use the same key (C-a) for jumping to
> both, visual and logical bols according to some user specified rule
> (cycling for example). And your patch is very close to making that
> possible.

Feel free to make a concrete suggestion (code).

What I agree with you on (so far) are:

a. Users should be able to do repeated bol/eol for both visual and logical
lines, in visual line mode.

b. For my personal use, at least, I will favor `C-a'/`C-e' over `home'/`end'.

I've used the same repeatable `C-a'/`C-e' thingie for non visual-line mode for a
long time.  I wouldn't be without it.  Some reasonable extension to visual-line
mode should be similarly helpful.  And we should be able to accommodate the
"conventional" use of `home'/`end' as well, just making their actions
repeatable.

bug#13273: 24.3.50; [PATCH] enhancement request: repeatable `visual-line-mode' line movements

[Vitalie Spinu]

  >> "Drew Adams" <drew.adams@oracle.com>
  >> on Mon, 24 Dec 2012 14:27:14 -0800 wrote:

[...]


  > diff -c c\:/foo/simple.el c\:/foo/simple-patched-2012-12-24.el
  > *** c:/foo/simple.el	Mon Dec 24 13:48:06 2012
  > --- c:/foo/simple-patched-2012-12-24.el	Mon Dec 24 14:13:14 2012
  > ***************
  > *** 819,824 ****
  > --- 819,854 ----
  >   	 (overlay-recenter (point))
  >   	 (recenter -3))))
  
  > + (defun end-of-line (&optional n)
  > +   "Move cursor to end of current line or end of next line if repeated.
  > + If called interactively with no prefix arg:
  > +  If the previous command was also `end-of-line' then move to the
  > +  end of the next line.  Else move to the end of the current line.
  > + Otherwise, move to the end of the Nth next line (Nth previous line
  > +  if N <0 )."
  > +   (interactive
  > +    (list (if current-prefix-arg (prefix-numeric-value current-prefix-arg) 0)))
  > +   (unless n (setq n  0))                ; non-interactive with no arg
  > +   (if (and (eq this-command last-command)  (not current-prefix-arg))
  > +       (forward-line 1)
  > +     (forward-line n))
  > +   (let ((inhibit-field-text-motion  t))  (end-of-line)))
  > + 
  > + (defun beginning-of-line (&optional n)
  > +   "Move cursor to beginning of current line or next line if repeated.
  > + If called interactively with no prefix arg:
  > +  If the previous command was also `beginning-of-line' then move to the
  > +  beginning of the previous line.  Else move to the beginning of the
  > +  current line.
  > + Otherwise, move to the beginning of the Nth previous line (Nth next
  > +  line if N < 0)."
  > +   (interactive
  > +    (list (if current-prefix-arg (prefix-numeric-value current-prefix-arg) 0)))
  > +   (unless n (setq n  0))                ; non-interactive with no arg
  > +   (if (and (eq this-command last-command)  (not current-prefix-arg))
  > +       (forward-line -1)
  > +     (forward-line (- n))))
  > + 


This stuff doesn't work at all for me. Huge amount of misbehavior.
A couple of them, backward-paragraph hangs emacs,
typing after fill-column infloops. 'C-h k key' doesn't work, for
example C-h k C-a shows C-a in the minibuffer and waits ... Many other
editing commands stall emacs. 

When writing this mail I got 

Debugger entered--Lisp error: (error "Lisp nesting exceeds `max-lisp-eval-depth'")

with 600 lines backtrace. 

 

[...]


  > ***************
  > *** 5098,5105 ****
  >   (defvar visual-line-mode-map
  >     (let ((map (make-sparse-keymap)))
  >       (define-key map [remap kill-line] 'kill-visual-line)
  > !     (define-key map [remap move-beginning-of-line] 'beginning-of-visual-line)
  > !     (define-key map [remap move-end-of-line]  'end-of-visual-line)
  >       ;; These keybindings interfere with xterm function keys.  Are
  >       ;; there any other suitable bindings?
  >       ;; (define-key map "\M-[" 'previous-logical-line)
  > --- 5145,5154 ----
  >   (defvar visual-line-mode-map
  >     (let ((map (make-sparse-keymap)))
  >       (define-key map [remap kill-line] 'kill-visual-line)
  > !     (define-key map [home] 'beginning-of-line)
  > !     (define-key map [end]  'end-of-line)
  > !     (define-key map "\C-a" 'beginning-of-visual-line)
  > !     (define-key map "\C-e" 'end-of-visual-line)
  >       ;; These keybindings interfere with xterm function keys.  Are
  >       ;; there any other suitable bindings?
  >       ;; (define-key map "\M-[" 'previous-logical-line)

[remap move-beginning-of-line] wasn't there for nothing,  or was it?


Sorry,

 but
 I
 think
 it
 should
 be
 something
 much
 less
 intrusive
 and
 only
 concerning beginning-of-visual-line and end-of-visible-line.

 (^^^^--- Ah yes, fill-paragraph now produces this ... after C-g ... restarting my emacs ...)

    Best, 
    Vitalie

bug#13273: 24.3.50; [PATCH] enhancement request: repeatable `visual-line-mode' line movements

[Drew Adams]

> This stuff doesn't work at all for me. Huge amount of misbehavior.
> A couple of them, backward-paragraph hangs emacs,
> typing after fill-column infloops. 'C-h k key' doesn't work, for
> example C-h k C-a shows C-a in the minibuffer and waits ... Many other
> editing commands stall emacs. 
> 
> When writing this mail I got 
> 
> Debugger entered--Lisp error: (error "Lisp nesting exceeds 
> `max-lisp-eval-depth'")
> 
> with 600 lines backtrace. 
> [...]
> 
> [remap move-beginning-of-line] wasn't there for nothing,  or was it?
> 
> Sorry,
> 
>  but
>  I
>  think
>  it
>  should
>  be
>  something
>  much
>  less
>  intrusive
>  and
>  only
>  concerning beginning-of-visual-line and end-of-visible-line.
> 
>  (^^^^--- Ah yes, fill-paragraph now produces this ... after 
> C-g ... restarting my emacs ...)

You give no recipe - nothing concrete so that someone can understand your
problem.  Your message is pretty incomprehensible, at least to me.  Maybe
someone else can understand it and translate or DTRT.

Are you started from emacs -Q and don't have something else interfering?  Just a
suggestion.

(The patch works for me.)

bug#13273: 24.3.50; [PATCH] enhancement request: repeatable `visual-line-mode' line movements

[Vitalie Spinu]

  >> "Drew Adams" <drew.adams@oracle.com>
  >> on Fri, 28 Dec 2012 10:51:23 -0800 wrote:

  >> This stuff doesn't work at all for me. Huge amount of misbehavior.
  >> A couple of them, backward-paragraph hangs emacs,
  >> typing after fill-column infloops. 'C-h k key' doesn't work, for
  >> example C-h k C-a shows C-a in the minibuffer and waits ... Many other
  >> editing commands stall emacs. 
  >> 
  >> When writing this mail I got 
  >> 
  >> Debugger entered--Lisp error: (error "Lisp nesting exceeds 
  >> `max-lisp-eval-depth'")
  >> 
  >> with 600 lines backtrace. 
  >> [...]
  >> 
  >> [remap move-beginning-of-line] wasn't there for nothing,  or was it?
  >> 
  >> Sorry,
  >> 
  >> but
  >> I
  >> think
  >> it
  >> should
  >> be
  >> something
  >> much
  >> less
  >> intrusive
  >> and
  >> only
  >> concerning beginning-of-visual-line and end-of-visible-line.
  >> 
  >> (^^^^--- Ah yes, fill-paragraph now produces this ... after 
  >> C-g ... restarting my emacs ...)

  > You give no recipe - nothing concrete so that someone can understand your
  > problem.  Your message is pretty incomprehensible, at least to me.  Maybe
  > someone else can understand it and translate or DTRT.

Here is a short version: apply patch -> test -> emacs infloops on every
single occasion, i.e "C-h k C-a", "M-q" etc. Sorry, cannot investigate
more.

  > Are you started from emacs -Q and don't have something else interfering?  Just a
  > suggestion.

Yes, with emacs -Q on GNU Emacs 24.2.91.1 (i686-pc-linux-gnu, GTK+
Version 2.24.13) of 2012-12-25


As mentioned previously, I think this is not the way to go. As a
visual-line-mode user I would very much appreciate if C-a could cycle
between visual and logical bols, instead of going to previous bol.

    Vitalie

bug#13273: 24.3.50; [PATCH] enhancement request: repeatable `visual-line-mode' line movements

[Eli Zaretskii]

> From: Vitalie Spinu <spinuvit@gmail.com>
> Date: Fri, 28 Dec 2012 20:22:41 +0100
> Cc: 13273@debbugs.gnu.org
> 
>   > You give no recipe - nothing concrete so that someone can understand your
>   > problem.  Your message is pretty incomprehensible, at least to me.  Maybe
>   > someone else can understand it and translate or DTRT.
> 
> Here is a short version: apply patch -> test -> emacs infloops on every
> single occasion, i.e "C-h k C-a", "M-q" etc.

Did you re-dump Emacs after patching simple.el?  simple.el is
preloaded, so you cannot patch it without dumping Emacs again.

bug#13273: 24.3.50; [PATCH] enhancement request: repeatable `visual-line-mode' line movements

[Vitalie Spinu]

  >> Eli Zaretskii <eliz@gnu.org>
  >> on Fri, 28 Dec 2012 21:36:04 +0200 wrote:

  >> From: Vitalie Spinu <spinuvit@gmail.com>
  >> Date: Fri, 28 Dec 2012 20:22:41 +0100
  >> Cc: 13273@debbugs.gnu.org
  >> 
  >> > You give no recipe - nothing concrete so that someone can understand your
  >> > problem.  Your message is pretty incomprehensible, at least to me.  Maybe
  >> > someone else can understand it and translate or DTRT.
  >> 
  >> Here is a short version: apply patch -> test -> emacs infloops on every
  >> single occasion, i.e "C-h k C-a", "M-q" etc.

  > Did you re-dump Emacs after patching simple.el?  simple.el is
  > preloaded, so you cannot patch it without dumping Emacs again.

What is re-dump Emacs? Recompile from scratch? You don't mean dump-emacs
function, do you?

I have just evaluated the new functions that Drew has supplied. Also
loaded the whole simple.el with load-buffer. Tried the new functions and
they didn't work + all other misbehavior. Same effect in both cases.

Beginning-of-line and end-of-line are C built-ins. Drew's functions are
elisp. My guess is that that might matter even when recompiling emacs.

    Vitalie.

bug#13273: 24.3.50; [PATCH] enhancement request: repeatable `visual-line-mode' line movements

[Eli Zaretskii]

> From: Vitalie Spinu <spinuvit@gmail.com>
> Cc: drew.adams@oracle.com,  13273@debbugs.gnu.org
> Date: Fri, 28 Dec 2012 20:55:41 +0100
> 
>   > Did you re-dump Emacs after patching simple.el?  simple.el is
>   > preloaded, so you cannot patch it without dumping Emacs again.
> 
> What is re-dump Emacs? Recompile from scratch? You don't mean dump-emacs
> function, do you?

Yes, I do.  Typing just "make" in the source tree after you patch
lisp/simple.el will do that automatically.

> I have just evaluated the new functions that Drew has supplied. Also
> loaded the whole simple.el with load-buffer. Tried the new functions and
> they didn't work + all other misbehavior. Same effect in both cases.

I'm not surprised.  Doing what you did might cause any number of weird
effects.  Don't do that if you care about your sanity.

> Beginning-of-line and end-of-line are C built-ins. Drew's functions are
> elisp.

Exactly.  So functions in C that call these built-ins from C will
still call the old versions coded in C, and Emacs is likely to run
amok.

> My guess is that that might matter even when recompiling emacs.

Yes, the C built-ins need to be commented out, and then Emacs needs to
be recompiled.

bug#13273: 24.3.50; [PATCH] enhancement request: repeatable `visual-line-mode' line movements

[Drew Adams]

> Here is a short version: apply patch -> test -> emacs 
> infloops on every single occasion, i.e "C-h k C-a", "M-q" etc.

Try just evaluating the new definitions and key bindings, instead of trying to
apply a patch etc.  That will show you the proposed behavior.  You should not
seen any errors, inflooping etc.

Someone intending to install the change to Emacs itself can worry about applying
the patch.  If you just want to evaluate the behavior, you need not do that.

bug#13273: 24.3.50; [PATCH] enhancement request: repeatable `visual-line-mode' line movements

[Vitalie Spinu]

  >> "Drew Adams" <drew.adams@oracle.com>
  >> on Fri, 28 Dec 2012 12:04:27 -0800 wrote:

  >> Here is a short version: apply patch -> test -> emacs 
  >> infloops on every single occasion, i.e "C-h k C-a", "M-q" etc.

  > Try just evaluating the new definitions and key bindings, instead of trying to
  > apply a patch etc.  That will show you the proposed behavior.  You should not
  > seen any errors, inflooping etc.

  > Someone intending to install the change to Emacs itself can worry about applying
  > the patch.  If you just want to evaluate the behavior, you need not do that.

I just did that, and as Eli said, this is a bad idea for built-in
functions.


But the problem with your function is far more simple:
   
   (defun end-of-line (&optional n)
     "Move cursor to end of current line or end of next line if repeated.
   If called interactively with no prefix arg:
    If the previous command was also `end-of-line' then move to the
    end of the next line.  Else move to the end of the current line.
   Otherwise, move to the end of the Nth next line (Nth previous line
    if N <0 )."
     (interactive
      (list (if current-prefix-arg (prefix-numeric-value current-prefix-arg) 0)))
     (unless n (setq n  0))                ; non-interactive with no arg
     (if (and (eq this-command last-command)  (not current-prefix-arg))
         (forward-line 1)
       (forward-line n))
     (let ((inhibit-field-text-motion  t))  (end-of-line)))

How is this not an infloop?  ----------------^^^^^^^^^^^



    Vitalie
   

bug#13273: 24.3.50; [PATCH] enhancement request: repeatable `visual-line-mode' line movements

[Drew Adams]

[-- Attachment #1: Type: text/plain, Size: 1709 bytes --]

>   > Try just evaluating the new definitions and key bindings, 
>   > instead of trying to apply a patch etc.  That will show you
>   > the proposed behavior.  You should not see any errors,
>   > inflooping etc.
> 
>   > Someone intending to install the change to Emacs itself 
>   > can worry about applying the patch.  If you just want to
>   > evaluate the behavior, you need not do that.
> 
> I just did that, and as Eli said, this is a bad idea for built-in
> functions.

Not if you just want to check the new behavior.

I made it clear in my original post that if the new, Lisp definitions from the
patch are to be applied then the C versions need to be removed.

> But the problem with your function is far more simple:
>    (defun end-of-line (&optional n)
>      (let ((inhibit-field-text-motion  t))  (end-of-line)))
> How is this not an infloop?  ----------------^^^^^^^^^^^

About that you are right.  The patch is not correct in that regard, sorry.

I took the definition from my `end-of-line+' and just renamed it to
`end-of-line', without paying attention to the fact that it calls the original
C-coded function.  For the function to be renamed that way, it would have to
call the equivalent of the current C function (to be renamed), or some other
change would be needed.

My point to you remains, but with a change wrt the names: if you want to
evaluate the proposed behavior, then just evaluate the attached code (which is
the same as what I sent to emacs-devel for people to try this).  The attached
definitions are the same as what I included in the patch, except for the doc
strings and the command names.  (And to repeat, yes, the patch is incorrect
because of the name-capture.

HTH.

[-- Attachment #2: throw-beg-end.el --]
[-- Type: application/octet-stream, Size: 4776 bytes --]

(defun end-of-line+ (&optional n)
  "Move cursor to end of current line or end of next line if repeated.
This is similar to `end-of-line', but:
  If called interactively with no prefix arg:
     If the previous command was also `end-of-line+', then move to the
     end of the next line.  Else, move to the end of the current line.
  Otherwise, move to the end of the Nth next line (Nth previous line
     if N<0).  Command `end-of-line', by contrast, moves to the end of
     the (N-1)th next line."
  (interactive
   (list (if current-prefix-arg (prefix-numeric-value current-prefix-arg) 0)))
  (unless n (setq n 0))                 ; non-interactive with no arg
  (if (and (eq this-command last-command) (not current-prefix-arg))
      (forward-line 1)
    (forward-line n))
  (let ((inhibit-field-text-motion  t))  (end-of-line)))

(defun beginning-of-line+ (&optional n)
  "Move cursor to beginning of current line or next line if repeated.
This is the similar to `beginning-of-line', but:
1. With arg N, the direction is the opposite: this command moves
   backward, not forward, N lines.
2. If called interactively with no prefix arg:
      If the previous command was also `beginning-of-line+', then move
      to the beginning of the previous line.  Else, move to the
      beginning of the current line.
   Otherwise, move to the beginning of the Nth previous line (Nth next
      line if N<0).  Command `beginning-of-line', by contrast, moves to
      the beginning of the (N-1)th next line."
  (interactive
   (list (if current-prefix-arg (prefix-numeric-value current-prefix-arg) 0)))
  (unless n (setq n 0))                 ; non-interactive with no arg
  (if (and (eq this-command last-command) (not current-prefix-arg))
      (forward-line -1)
    (forward-line (- n))))

(defun end-of-visual-line+ (&optional n)
  "Move cursor to end of current visual line, or end of next if repeated.
If point reaches the beginning or end of buffer, it stops there.
To ignore intangibility, bind `inhibit-point-motion-hooks' to t.

This is similar to `end-of-visual-line', but:
  If called interactively with no prefix arg:
     If the previous command was also `end-of-visual-line+', then move
     to the end of the next visual line.  Else, end of current one.
  Otherwise, move to the end of the Nth next visual line (Nth previous
     one if N<0).  Command `end-of-visual-line', by contrast, moves to
     the end of the (N-1)th next line."
  (interactive
   (list (if current-prefix-arg (prefix-numeric-value current-prefix-arg) 0)))
  (unless n (setq n 0))                 ; non-interactive with no arg 
  (let ((line-move-visual  t))
    (if (and (eq this-command last-command)  (not current-prefix-arg))
        (line-move 1 t)
      (line-move n t)))
  ;; Unlike `move-beginning-of-line', `move-end-of-line' doesn't
  ;; constrain to field boundaries, so we don't either.
  (vertical-motion (cons (window-width) 0)))

(defun beginning-of-visual-line+ (&optional n)
  "Move cursor to beginning of current visual line or next if repeated.
If point reaches the beginning or end of buffer, it stops there.
To ignore intangibility, bind `inhibit-point-motion-hooks' to t.

This is the similar to `beginning-of-visual-line', but:
1. With arg N, the direction is the opposite: this command moves
   backward, not forward, N visual lines.
2. If called interactively with no prefix arg:
      If the previous command was also `beginning-of-visual-line+',
      then move to the beginning of the previous visual line.  Else,
      move to the beginning of the current visual line.
   Otherwise, move to the beginning of the Nth previous visual line
      (Nth next one if N<0).  Command `beginning-of-visual-line', by
      contrast, moves to the beginning of the (N-1)th next visual
      line."
  (interactive
   (list (if current-prefix-arg (prefix-numeric-value current-prefix-arg) 0)))
  (unless n (setq n 0))                 ; non-interactive with no arg
  (let ((opoint  (point)))
    (let ((line-move-visual  t))
      (if (and (eq this-command last-command)  (not current-prefix-arg))
          (line-move -1 t)
        (line-move n t)))
    (vertical-motion 0)
    ;; Constrain to field boundaries, like `move-beginning-of-line'.
    (goto-char (constrain-to-field (point) opoint (/= n 1)))))

(define-key visual-line-mode-map [remap move-beginning-of-line] nil)
(define-key visual-line-mode-map [remap move-end-of-line] nil)
(define-key visual-line-mode-map [home] 'beginning-of-line+)
(define-key visual-line-mode-map [end]  'end-of-line+)
(define-key visual-line-mode-map "\C-a" 'beginning-of-visual-line+)
(define-key visual-line-mode-map "\C-e" 'end-of-visual-line+)

bug#13273: 24.3.50; [PATCH] enhancement request: repeatable `visual-line-mode' line movements

[Lars Ingebrigtsen]

"Drew Adams" <drew.adams@oracle.com> writes:

> 4. In place of those remappings, makes these key bindings for
>    `visual-line-mode':
>
>    * `home' - `beginning-of-line'
>    * `end'  - `end-of-line'
>    * `C-a'  - `beginning-of-visual-line'
>    * `C-e'  - `end-of-visual-line'

There didn't seem to be much enthusiasm for this six years ago (or
afterwards), so I'm closing this bug report.  If somebody thinks that
this is a good idea, please reopen.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no