line-move-visual never set to nil?

line-move-visual never set to nil?

[T. V. Raman]

I'm very confused by the code in simple.el.

As reported a few minutes ago, turning off visual-line-mode has
no effect. The apparent reason being: line-move-visual remains
set to T and that is what the code in functions next-line and
previous-line refers to.

Is this a naming bug i.e. with the minor mode now called
visual-line-mode, should the variable be named visual-line-move
-- rather than line-move-visual?

Looking at the code that defines visual-line-mode -- I dont see
the line-move-visual getting set at any point; also, I see a
command to turn-on-visual-line-mode -- but no corresponding
command to turn it off.

Setting line-move-visual to nil does return emacs to its
traditional behavior where next-line and previous-line move
across   physical lines.

-- 
Best Regards,
--raman

      
Email:  raman@users.sf.net
WWW:    http://emacspeak.sf.net/raman/
AIM:    emacspeak       GTalk: tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
Google: tv+raman 
IRC:    irc://irc.freenode.net/#emacs

Re: line-move-visual never set to nil?

[Stefan Monnier]

> Looking at the code that defines visual-line-mode -- I dont see
> the line-move-visual getting set at any point; also, I see a
> command to turn-on-visual-line-mode -- but no corresponding
> command to turn it off.

Yes, could someone remove turn-on-visual-line-mode?
The command to turn it ON is the same as the one to turn it OFF,
i.e. `visual-line-mode'.


        Stefan

Re: line-move-visual never set to nil?

[Vinicius Jose Latorre]

Stefan Monnier wrote:
>> Looking at the code that defines visual-line-mode -- I dont see
>> the line-move-visual getting set at any point; also, I see a
>> command to turn-on-visual-line-mode -- but no corresponding
>> command to turn it off.
>>     
>
> Yes, could someone remove turn-on-visual-line-mode?
> The command to turn it ON is the same as the one to turn it OFF,
> i.e. `visual-line-mode'.
>   

The turn-on-visual-line-mode is an auxiliary function used by 
global-visual-line-mode.

 From simple.el:

(defun turn-on-visual-line-mode ()
  (visual-line-mode 1))

(define-globalized-minor-mode global-visual-line-mode
  visual-line-mode turn-on-visual-line-mode
  :lighter " vl")

Re: line-move-visual never set to nil?

[Stefan Monnier]

>>> Looking at the code that defines visual-line-mode -- I dont see
>>> the line-move-visual getting set at any point; also, I see a
>>> command to turn-on-visual-line-mode -- but no corresponding
>>> command to turn it off.
>> Yes, could someone remove turn-on-visual-line-mode?
>> The command to turn it ON is the same as the one to turn it OFF,
>> i.e. `visual-line-mode'.
> The turn-on-visual-line-mode is an auxiliary function used by
> global-visual-line-mode.

Oh, so it's not a command, but just a function.  I guess it can stay.


        Stefan

Re: line-move-visual never set to nil?

[David Reitter]

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

On 26 Jul 2008, at 14:13, Stefan Monnier wrote:
> Yes, could someone remove turn-on-visual-line-mode?
> The command to turn it ON is the same as the one to turn it OFF,
> i.e. `visual-line-mode'.

Isn't that a convenience function for people to put in hooks?
(...which is nicer than a lambda expression)

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

Re: line-move-visual never set to nil?

[Chong Yidong]

"T. V. Raman" <raman@users.sourceforge.net> writes:

> As reported a few minutes ago, turning off visual-line-mode has
> no effect. The apparent reason being: line-move-visual remains
> set to T and that is what the code in functions next-line and
> previous-line refers to.

Now, line-move-visual is a defcustom.  The question is, whether it
should default to nil or t (even when visual-line-mode is off).  The
current default is t, which is a kind of hybrid model where line-move
uses screen lines but other editing commands use logical lines.

Like Stefan and others, I've found that this setting works pretty well
in practice, for buffers in which there are occasional continued lines.
(When the buffer is full of long lines, turning on visual-line-mode is
more appropriate.)

It's true, though, that this behavior could be confusing, especially for
longtime users of Emacs.  So maybe we ought to make line-move-visual
default to nil, as before, and leave it to advanced users to change it
to t for their own usage.

What's the opinion of others on this list?

Re: line-move-visual never set to nil?

[T. V. Raman]

I think line-move-visual should start off set consistent with
visual-line-mode. I also think it should be renamed to match with
visual-line-mode -- ie visual-line-move -- not line-move-visual
--- otherwise users will never be able to discover and set it.

>>>>> "Chong" == Chong Yidong <cyd@stupidchicken.com> writes:
    Chong> "T. V. Raman" <raman@users.sourceforge.net> writes:
    >> As reported a few minutes ago, turning off
    >> visual-line-mode has no effect. The apparent reason being:
    >> line-move-visual remains set to T and that is what the
    >> code in functions next-line and previous-line refers to.
    Chong> 
    Chong> Now, line-move-visual is a defcustom.  The question
    Chong> is, whether it should default to nil or t (even when
    Chong> visual-line-mode is off).  The current default is t,
    Chong> which is a kind of hybrid model where line-move uses
    Chong> screen lines but other editing commands use logical
    Chong> lines.
    Chong> 
    Chong> Like Stefan and others, I've found that this setting
    Chong> works pretty well in practice, for buffers in which
    Chong> there are occasional continued lines.  (When the
    Chong> buffer is full of long lines, turning on
    Chong> visual-line-mode is more appropriate.)
    Chong> 
    Chong> It's true, though, that this behavior could be
    Chong> confusing, especially for longtime users of Emacs.  So
    Chong> maybe we ought to make line-move-visual default to
    Chong> nil, as before, and leave it to advanced users to
    Chong> change it to t for their own usage.
    Chong> 
    Chong> What's the opinion of others on this list?
    Chong> 

-- 
Best Regards,
--raman

      
Email:  raman@users.sf.net
WWW:    http://emacspeak.sf.net/raman/
AIM:    emacspeak       GTalk: tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
Google: tv+raman 
IRC:    irc://irc.freenode.net/#emacs

Re: line-move-visual never set to nil?

[Chong Yidong]

"T. V. Raman" <raman@users.sourceforge.net> writes:

> I think line-move-visual should start off set consistent with
> visual-line-mode. I also think it should be renamed to match with
> visual-line-mode -- ie visual-line-move -- not line-move-visual ---
> otherwise users will never be able to discover and set it.

But line-move-visual (and word-wrap) can be turned on independently;
visual-line-mode simply goes a step further and rebinds some editing
keys in addition to setting line-move-visual and word-wrap.

How about renaming line-move-visual to line-move-by-screen-lines?

Re: line-move-visual never set to nil?

[David Reitter]

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

On 26 Jul 2008, at 14:57, Chong Yidong wrote:
>
> It's true, though, that this behavior could be confusing, especially  
> for
> longtime users of Emacs.  So maybe we ought to make line-move-visual
> default to nil, as before, and leave it to advanced users to change it
> to t for their own usage.

Especially novice users will be confused by this defaulting to nil.

More advanced users can customize or simply stick to an older version  
if they quite generally don't appreciate improvements.


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

Re: line-move-visual never set to nil?

[Stefan Monnier]

>> It's true, though, that this behavior could be confusing, especially for
>> longtime users of Emacs.  So maybe we ought to make line-move-visual
>> default to nil, as before, and leave it to advanced users to change it
>> to t for their own usage.

That's not my experience.  line-move has been doing "funny" things for
a while now and nobody really complained about it (all the complaints
I've seen were of the other sort, which were pushing towards what we
now have when we set line-move-visual to t).

> Especially novice users will be confused by this defaulting to nil.

We shouldn't place special emphasis on novices, but I think that it's
generally a better default, indeed.  As a matter of fact, the OP's
reuqest wasn't really complaining about this default, but about the fact
that he expected visual-line-mode to affect it.  Maybe the docstring
should refer to line-move-visual to clear the confusion.


        Stefan

Re: line-move-visual never set to nil?

[Stefan Monnier]

>> Especially novice users will be confused by this defaulting to nil.
> We shouldn't place special emphasis on novices, but I think that it's
> generally a better default, indeed.  As a matter of fact, the OP's
> request wasn't really complaining about this default, but about the fact
> that he expected visual-line-mode to affect it.  Maybe the docstring
> should refer to line-move-visual to clear the confusion.

Another solution is to merge the two variables into a single 3-state option.
That would clear up the confusion much more effectively.


        Stefan

Re: line-move-visual never set to nil?

[T. V. Raman]

I like  the idea of a three way option --- that brings together
all the bits into a single location for customization and documentation.

>>>>> "Stefan" == Stefan Monnier <monnier@iro.umontreal.ca> writes:
    >>> Especially novice users will be confused by this
    >>> defaulting to nil.
    >> We shouldn't place special emphasis on novices, but I
    >> think that it's generally a better default, indeed.  As a
    >> matter of fact, the OP's request wasn't really complaining
    >> about this default, but about the fact that he expected
    >> visual-line-mode to affect it.  Maybe the docstring should
    >> refer to line-move-visual to clear the confusion.
    Stefan> 
    Stefan> Another solution is to merge the two variables into a
    Stefan> single 3-state option.  That would clear up the
    Stefan> confusion much more effectively.
    Stefan> 
    Stefan> 
    Stefan>         Stefan

-- 
Best Regards,
--raman

      
Email:  raman@users.sf.net
WWW:    http://emacspeak.sf.net/raman/
AIM:    emacspeak       GTalk: tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
Google: tv+raman 
IRC:    irc://irc.freenode.net/#emacs

Re: line-move-visual never set to nil?

[Andrew W. Nosenko]

On Sun, Jul 27, 2008 at 11:59 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>>> It's true, though, that this behavior could be confusing, especially for
>>> longtime users of Emacs.  So maybe we ought to make line-move-visual
>>> default to nil, as before, and leave it to advanced users to change it
>>> to t for their own usage.
>
> That's not my experience.  line-move has been doing "funny" things for
> a while now and nobody really complained about it (all the complaints
> I've seen were of the other sort, which were pushing towards what we
> now have when we set line-move-visual to t).

Just because either too lazy (like me) and hope that usual behavior
will be restored after trying and playing fith this feature, or just
don't know (because not so many people use CVS emacs), or in hope that
some convenient workaround will be made for achieve the best of two
sides.

The biggest problem with "visual" line motion as it is currently is
even not in the need of re-learning.  The biggest is that current
defaults are beaks keybord macro.  Just try to record some macro that
uses up/down key having wrapped lines, change width of the
window/frame and enjoy. :-(

Introducing of the commands for movement over phisical lines (as
proposed for M-[ and M-], or where they will be bound finally) could
help, but...  But they are available only for word-wrapping mode,
while up/down keys behavior "screwed" in all modes :-(

Sorry, may be indeed wes too lazy and this message should be written
early, but better do it latter than never...

-- 
Andrew W. Nosenko <andrew.w.nosenko@gmail.com>

Re: line-move-visual never set to nil?

[Chong Yidong]

"Andrew W. Nosenko" <andrew.w.nosenko@gmail.com> writes:

> The biggest problem with "visual" line motion ...  is that current
> defaults are beaks keybord macro.  Just try to record some macro that
> uses up/down key having wrapped lines, change width of the
> window/frame and enjoy. :-(

That's a good point.  That's also why line-move doesn't try to scroll
tall images when executing a keyboard macro.  Maybe line-move-visual
needs the same treatment, like in the following patch.  WDYT?

*** trunk/lisp/simple.el.~1.939.~	2008-07-28 10:55:05.000000000 -0400
--- trunk/lisp/simple.el	2008-07-29 10:32:51.000000000 -0400
***************
*** 3978,3994 ****
  ;; a cleaner solution to the problem of making C-n do something
  ;; useful given a tall image.
  (defun line-move (arg &optional noerror to-end try-vscroll)
!   (unless (and auto-window-vscroll try-vscroll
! 	       ;; Only vscroll for single line moves
! 	       (= (abs arg) 1)
! 	       ;; But don't vscroll in a keyboard macro.
! 	       (not defining-kbd-macro)
! 	       (not executing-kbd-macro)
! 	       (line-move-partial arg noerror to-end))
!     (set-window-vscroll nil 0 t)
!     (if line-move-visual
! 	(line-move-visual arg noerror)
!       (line-move-1 arg noerror to-end))))
  
  ;; Display-based alternative to line-move-1.
  ;; Arg says how many lines to move.  The value is t if we can move the
--- 3978,3996 ----
  ;; a cleaner solution to the problem of making C-n do something
  ;; useful given a tall image.
  (defun line-move (arg &optional noerror to-end try-vscroll)
!   (if (or defining-kbd-macro executing-kbd-macro)
!       ;; If inside a keyboard macro, don't vscroll and don't move by
!       ;; screen lines.
!       (progn (set-window-vscroll nil 0 t)
! 	     (line-move-1 arg noerror to-end))
!     ;; Otherwise, only vscroll for single line moves
!     (unless (and auto-window-vscroll try-vscroll
! 		 (= (abs arg) 1)
! 		 (line-move-partial arg noerror to-end))
!       (set-window-vscroll nil 0 t)
!       (if line-move-visual
! 	  (line-move-visual arg noerror)
! 	(line-move-1 arg noerror to-end)))))
  
  ;; Display-based alternative to line-move-1.
  ;; Arg says how many lines to move.  The value is t if we can move the

Re: line-move-visual never set to nil?

[Lennart Borgman]

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

On 7/29/08, Chong Yidong <cyd@stupidchicken.com> wrote:
>
> "Andrew W. Nosenko" <andrew.w.nosenko@gmail.com> writes:
>
> > The biggest problem with "visual" line motion ...  is that current
> > defaults are beaks keybord macro.  Just try to record some macro that
> > uses up/down key having wrapped lines, change width of the
> > window/frame and enjoy. :-(
>
> That's a good point.  That's also why line-move doesn't try to scroll
> tall images when executing a keyboard macro.  Maybe line-move-visual
> needs the same treatment, like in the following patch.  WDYT?


I do not understand what you mean here. Would not the easiest thing be to
turn off visual line moving during macro recording and execution?

[-- Attachment #2: Type: text/html, Size: 1157 bytes --]

Re: line-move-visual never set to nil?

[Stefan Monnier]

>> The biggest problem with "visual" line motion ...  is that current
>> defaults are beaks keybord macro.  Just try to record some macro that
>> uses up/down key having wrapped lines, change width of the
>> window/frame and enjoy. :-(

Indeed, it sounds like a problem.

> That's a good point.  That's also why line-move doesn't try to scroll
> tall images when executing a keyboard macro.  Maybe line-move-visual
> needs the same treatment, like in the following patch.  WDYT?

It's probably a good idea, although it's kind of ugly.


        Stefan

Re: line-move-visual never set to nil?

[Chong Yidong]

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

>> That's a good point.  That's also why line-move doesn't try to scroll
>> tall images when executing a keyboard macro.  Maybe line-move-visual
>> needs the same treatment, like in the following patch.  WDYT?
>
> It's probably a good idea, although it's kind of ugly.

Yeah.  Maybe it's better to return to the previous default.

Re: line-move-visual never set to nil?

[David Reitter]

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

On 29 Jul 2008, at 19:31, Chong Yidong wrote:
>
> Yeah.  Maybe it's better to return to the previous default.

How about new functions for the visual movement, and binding the arrow  
keys to that?
There could be a mode to bind the keys, and this mode could default to  
on.

Would that be compatible with old macros?


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

Re: line-move-visual never set to nil?

[Chong Yidong]

David Reitter <david.reitter@gmail.com> writes:

> How about new functions for the visual movement, and binding the arrow
> keys to that?

No, we shouldn't make C-n and down do different things.  That would be
bad.

I don't think there's a completely satisfactory way to allow both visual
line movement and keyboard macro friendliness by default.  If we don't
revert to the old default, we may just have to live with this conflict.

We could advise people to temporarily turn on truncate-lines if they
want to handle long lines with keyboard macros.

Re: line-move-visual never set to nil?

[Lennart Borgman (gmail)]

Chong Yidong wrote:
> David Reitter <david.reitter@gmail.com> writes:
> 
>> How about new functions for the visual movement, and binding the arrow
>> keys to that?
> 
> No, we shouldn't make C-n and down do different things.  That would be
> bad.
> 
> I don't think there's a completely satisfactory way to allow both visual
> line movement and keyboard macro friendliness by default.  If we don't
> revert to the old default, we may just have to live with this conflict.
> 
> We could advise people to temporarily turn on truncate-lines if they
> want to handle long lines with keyboard macros.

Why not do that for them? Or something equivalent.

Re: line-move-visual never set to nil?

[Stefan Monnier]

>> We could advise people to temporarily turn on truncate-lines if they
>> want to handle long lines with keyboard macros.

> Why not do that for them? Or something equivalent.

That's basically what his patch was doing (tho in a different way),


        Stefan

Re: line-move-visual never set to nil?

[David De La Harpe Golden]

Chong Yidong wrote:
> David Reitter <david.reitter@gmail.com> writes:
> 
>> How about new functions for the visual movement, and binding the arrow
>> keys to that?
> 
> No, we shouldn't make C-n and down do different things.  That would be
> bad.
> 

How about making new functions for the visual movement, and binding
different keys to _them_ :

Since visual line movement is occasionally useful, but nonsurprising
keyboard macros probably more important for my usual use of emacs,
I was vaguely considering doing that locally, effectively - leaving
line-move-visual on, BUT binding up/down and  C-n/p
to next/previous-logical-line, and putting the (visual)
next/previous-line on M-up/down (yes perhaps trouble on some terminals,
but my terminal seems to handle it okay)

But if next/previous-line were what next/previous-logical-line currently
are, and next/previous-visual-line were introduced to be what
next/previous-line currently are, I'd probably prefer that. Slightly
less surprising than having to use next/prev-logical-line where
next/previous-line used to suffice.

Re: line-move-visual never set to nil?

[Miles Bader]

David Reitter <david.reitter@gmail.com> writes:
> How about new functions for the visual movement, and binding the arrow
> keys to that?  There could be a mode to bind the keys, and this mode
> could default to on.

No.

The arrow keys should _not_ be "special".

-MIles

-- 
Somebody has to do something, and it's just incredibly pathetic that it
has to be us.  -- Jerry Garcia

Re: line-move-visual never set to nil?

[David Reitter]

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

On 30 Jul 2008, at 01:31, Miles Bader wrote:

> David Reitter <david.reitter@gmail.com> writes:
>> How about new functions for the visual movement, and binding the  
>> arrow
>> keys to that?  There could be a mode to bind the keys, and this mode
>> could default to on.
>
> No.
>
> The arrow keys should _not_ be "special".

I've been misunderstood.  I also meant to bind C-n/C-p to the new  
functions.

But if keyboard macros don't record the invoked functions, but key  
presses, then that won't help of course.
This is only about backwards compatibility!

If a user records a new macro using movement keys, then they should  
get the new behavior, of course...

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

Re: line-move-visual never set to nil?

[Richard M Stallman]

If a command normally moves by screen lines, making it do something
different in a keyboard macro is incorrect.

Why doesn't it work right in a keyboard macro?
Is this because it uses data structures that are updated
only by redisplay, and the keyboard macro does not redisplay?

If that is the cause, these functions also are no use for other Lisp
programs to call.  Even when the user types commands by hand, Emacs
may not redisplay if the machine falls behind.  Using those facilities
is the wrong implementation for these commands.

The right solution is to implement the TODO item of functions similar
to compute-motion, vertical-motion, and current-column, which take
account of the width and height of characters and operate on positions
expressed in floating point.  These functions should look only at the
buffer contents and the fonts, so they work regardless of whether
the text has been displayed lately.

If you implement these commands based on those functions, they will
work reliably no matter where they are called from.

Re: line-move-visual never set to nil?

[Chong Yidong]

Richard M Stallman <rms@gnu.org> writes:

> If a command normally moves by screen lines, making it do something
> different in a keyboard macro is incorrect.

Yeah, I'm not crazy about the idea either.

> Why doesn't it work right in a keyboard macro?
> Is this because it uses data structures that are updated
> only by redisplay, and the keyboard macro does not redisplay?

No, it's because keyboard macros recorded using one window width may not
work properly when you change the window width, if the line wrapping has
changed.

After thinking about this more, I think we might leave this alone.  It's
not difficult to do M-x toggle-truncate-lines if you need to avoid this
problem, if it ever crops up.

Re: line-move-visual never set to nil?

[Miles Bader]

Chong Yidong <cyd@stupidchicken.com> writes:
>> Why doesn't it work right in a keyboard macro?
>
> No, it's because keyboard macros recorded using one window width may not
> work properly when you change the window width, if the line wrapping has
> changed.
>
> After thinking about this more, I think we might leave this alone.  It's
> not difficult to do M-x toggle-truncate-lines if you need to avoid this
> problem, if it ever crops up.

I agree.

The fundamental problem is one that has always been present when
entering keyboard macros:  You need to be slightly careful and consider
possible ways that your commands might work differently in a different
context.  Often this means using different, more robust or more
primitive commands than you might use interactively.

I don't think line-move-visual changes much.

-Miles

-- 
Electricity, n. The cause of all natural phenomena not known to be caused by
something else.

Re: line-move-visual never set to nil?

[Lennart Borgman (gmail)]

Chong Yidong wrote:
>> Why doesn't it work right in a keyboard macro?
>> Is this because it uses data structures that are updated
>> only by redisplay, and the keyboard macro does not redisplay?
> 
> No, it's because keyboard macros recorded using one window width may not
> work properly when you change the window width, if the line wrapping has
> changed.
> 
> After thinking about this more, I think we might leave this alone.  It's
> not difficult to do M-x toggle-truncate-lines if you need to avoid this
> problem, if it ever crops up.


But this is a fundamental and known problem with keyboard macros and 
line-move-visual. As I said before: Why not turn on line-move-visual 
during keyboard recording and replaying?

I thought Stefan responded earlier (thanks) that this was what a 
proposed patch did. It looks like I am misunderstanding something. Could 
someone explain?

Re: line-move-visual never set to nil?

[Lennart Borgman (gmail)]

Richard M Stallman wrote:
> If a command normally moves by screen lines, making it do something
> different in a keyboard macro is incorrect.


Wouldn't it be more correct to say that the requirement is that during 
execution of the macro the command should do the same thing to the 
buffer as during recording of the macro?

This mean that if for example the command changes point then this change 
must be independent of the window size.

My conclusion is that commands that changes something in the buffer and 
depends on window size must behave differently when used with macros. In 
that case they must not be depend on the window size.

Re: line-move-visual never set to nil?

[Miles Bader]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
>> If a command normally moves by screen lines, making it do something
>> different in a keyboard macro is incorrect.
>
> Wouldn't it be more correct to say that the requirement is that during
> execution of the macro the command should do the same thing to the
> buffer as during recording of the macro?
>
> This mean that if for example the command changes point then this change
> must be independent of the window size.

Macros do not -- and cannot -- make any guarantees about what happens if
you execute them in a different environment, or on different text, than
where they were recorded.

-Miles

-- 
Once, adj. Enough.

Re: line-move-visual never set to nil?

[Lennart Borgman (gmail)]

Miles Bader wrote:
> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
>>> If a command normally moves by screen lines, making it do something
>>> different in a keyboard macro is incorrect.
>> Wouldn't it be more correct to say that the requirement is that during
>> execution of the macro the command should do the same thing to the
>> buffer as during recording of the macro?
>>
>> This mean that if for example the command changes point then this change
>> must be independent of the window size.
> 
> Macros do not -- and cannot -- make any guarantees about what happens if
> you execute them in a different environment, or on different text, than
> where they were recorded.


Do you mean that there is something that prevents us from temporary 
turning things off during keyboard macro recording and execution? In 
that case: what?

Re: line-move-visual never set to nil?

[David De La Harpe Golden]

Lennart Borgman (gmail) wrote
>> Macros do not -- and cannot -- make any guarantees about what happens if
>> you execute them in a different environment, or on different text, than
>> where they were recorded.
> 
> 
> Do you mean that there is something that prevents us from temporary
> turning things off during keyboard macro recording and execution? In
> that case: what?
> 

It'd be annoying?

It would break similarity between keyboard macros and normal editing.
What if I _expected_ it to do things visually?

Yes, line-move-visual is kind of sucky for keyboard macros (as I've
already said, I'd rather have visual line movement on separate bindings
to normal/logical line movement). However, it turning off inside
keyboard macro definition when it's otherwise on would IMO be pretty
infuriatingly surprising.

Slightly contrived example - you're editing a wide table say,
line-move-visual is on and you have set your window size to wrap at
a table border, and then you notice a regular edit you're doing
to the 4th (on the 1st visual line) and 17th columns (on the
second visual line of the same logical line) could be repeated
all the way down with a macro.  You try to use next-line, just as you
would outside keyboard macro definition and have been using for
the past 4 rows before the ol' brain kicked in and told you to
press F3...

In short, leave it on or leave it off, don't magically muck with it.

Re: line-move-visual never set to nil?

[David De La Harpe Golden]

David De La Harpe Golden wrote:

> a table border,

Ment column border somewhere in middle of table, sorry, probably
obvious from context.

Re: line-move-visual never set to nil?

[Lennart Borgman (gmail)]

David De La Harpe Golden wrote:
> Lennart Borgman (gmail) wrote
>>> Macros do not -- and cannot -- make any guarantees about what happens if
>>> you execute them in a different environment, or on different text, than
>>> where they were recorded.
>>
>> Do you mean that there is something that prevents us from temporary
>> turning things off during keyboard macro recording and execution? In
>> that case: what?
>>
> 
> It'd be annoying?
> 
> It would break similarity between keyboard macros and normal editing.
> What if I _expected_ it to do things visually?
> 
> Yes, line-move-visual is kind of sucky for keyboard macros (as I've
> already said, I'd rather have visual line movement on separate bindings
> to normal/logical line movement). However, it turning off inside
> keyboard macro definition when it's otherwise on would IMO be pretty
> infuriatingly surprising.
> 
> Slightly contrived example - you're editing a wide table say,
> line-move-visual is on and you have set your window size to wrap at
> a table border, and then you notice a regular edit you're doing
> to the 4th (on the 1st visual line) and 17th columns (on the
> second visual line of the same logical line) could be repeated
> all the way down with a macro.  You try to use next-line, just as you
> would outside keyboard macro definition and have been using for
> the past 4 rows before the ol' brain kicked in and told you to
> press F3...

And if some lines wrap and others do not?

> In short, leave it on or leave it off, don't magically muck with it.


Maybe an option would be best IMO.

Re: line-move-visual never set to nil?

[David De La Harpe Golden]

Lennart Borgman (gmail) wrote:

> And if some lines wrap and others do not?

Well, that's why I find logical lines on up/down/C-p/C-n and
visual lines on other keys nicest - you can just choose the appropriate
movement (within keyboard macros or otherwise).

...

(global-set-key [C-p] 'previous-logical-line)
(global-set-key [C-n] 'next-logical-line)
(global-set-key [up] 'previous-logical-line)
(global-set-key [down] 'next-logical-line)
(global-set-key [M-up] 'previous-line)
(global-set-key [M-down] 'next-line)

Re: line-move-visual never set to nil?

[Lennart Borgman (gmail)]

David De La Harpe Golden wrote:
> Lennart Borgman (gmail) wrote:
> 
>> And if some lines wrap and others do not?
> 
> Well, that's why I find logical lines on up/down/C-p/C-n and
> visual lines on other keys nicest - you can just choose the appropriate
> movement (within keyboard macros or otherwise).
> 
> ...
> 
> (global-set-key [C-p] 'previous-logical-line)
> (global-set-key [C-n] 'next-logical-line)
> (global-set-key [up] 'previous-logical-line)
> (global-set-key [down] 'next-logical-line)
> (global-set-key [M-up] 'previous-line)
> (global-set-key [M-down] 'next-line)


Maybe that is a good idea, but it still does not help the user that is 
typing the visual move variants during macro recording.

Re: line-move-visual never set to nil?

[David De La Harpe Golden]

Lennart Borgman (gmail) wrote:

> Maybe that is a good idea, but it still does not help the user that is
> typing the visual move variants during macro recording.

It means the user can choose the appropriate one, whether inside or
outside macro recording. Since it shouldn't make a difference if you're
recording a macro or not...

Even if you do want to (or provide an option to) "help" IMO the way to
do it would be to have the keyboard macro definition remember an
associated window-width, and have keyboard macro playback temporarily
apply that window-width during playback (not necessarily visually
resizing the window). That seems far nicer than meddling with
line-move-visual on entering macro definition and playback.
Would probably require some C-level work.

Re: line-move-visual never set to nil?

[Lennart Borgman (gmail)]

David De La Harpe Golden wrote:
> Lennart Borgman (gmail) wrote:
> 
>> Maybe that is a good idea, but it still does not help the user that is
>> typing the visual move variants during macro recording.
> 
> It means the user can choose the appropriate one, whether inside or
> outside macro recording. Since it shouldn't make a difference if you're
> recording a macro or not...
> 
> Even if you do want to (or provide an option to) "help" IMO the way to
> do it would be to have the keyboard macro definition remember an
> associated window-width, and have keyboard macro playback temporarily
> apply that window-width during playback (not necessarily visually
> resizing the window). That seems far nicer than meddling with
> line-move-visual on entering macro definition and playback.
> Would probably require some C-level work.


I can see the idea, but I fear that with all details this may be very 
complicated. But I am not sure.

Re: line-move-visual never set to nil?

[Richard M Stallman]

    > Well, that's why I find logical lines on up/down/C-p/C-n and
    > visual lines on other keys nicest - you can just choose the appropriate
    > movement (within keyboard macros or otherwise).


    Maybe that is a good idea, but it still does not help the user that is 
    typing the visual move variants during macro recording.

Emacs is not magic.  When you record a macro you need to think
about what it will do in various context where you might use it.

Re: line-move-visual never set to nil?

[Chong Yidong]

Richard M Stallman <rms@gnu.org> writes:

> Emacs is not magic.

At least not yet.

(Cue the saying about how any sufficiently advanced technology etc...)

Re: line-move-visual never set to nil?

[Lennart Borgman (gmail)]

Chong Yidong wrote:
> Richard M Stallman <rms@gnu.org> writes:
> 
>> Emacs is not magic.
> 
> At least not yet.


That is because you did not want it to behave the way I suggested.

Re: line-move-visual never set to nil?

[Miles Bader]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
>> Macros do not -- and cannot -- make any guarantees about what happens if
>> you execute them in a different environment, or on different text, than
>> where they were recorded.
>
> Do you mean that there is something that prevents us from temporary
> turning things off during keyboard macro recording and execution? In
> that case: what?

The point is that it doesn't actually help -- there are a million other
cases that can trip up the user, and the only general solution is for
users to be aware of problems that can crop up during macro replying and
be fairly conservative in how they make macros.

Having commands work _differently_ during macro recording is guaranteed
to confuse people, and doing so will probably cause as many problems as
it "solves".

-Miles

-- 
自らを空にして、心を開く時、道は開かれる

Re: line-move-visual never set to nil?

[Lennart Borgman (gmail)]

Miles Bader wrote:
> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
>>> Macros do not -- and cannot -- make any guarantees about what happens if
>>> you execute them in a different environment, or on different text, than
>>> where they were recorded.
>> Do you mean that there is something that prevents us from temporary
>> turning things off during keyboard macro recording and execution? In
>> that case: what?
> 
> The point is that it doesn't actually help -- there are a million other
> cases that can trip up the user, and the only general solution is for
> users to be aware of problems that can crop up during macro replying and
> be fairly conservative in how they make macros.

I think this case is special. The special thing is the relation between 
the visual move and the buffer point. That relation changes according to 
something that is rather unrelated with the buffer contents but can 
easily be changed by the user. That makes the relation very volatile.

> Having commands work _differently_ during macro recording is guaranteed
> to confuse people, and doing so will probably cause as many problems as
> it "solves".
> 
> -Miles
> 

Re: line-move-visual never set to nil?

[Miles Bader]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
> I think this case is special. The special thing is the relation between
> the visual move and the buffer point. That relation changes according to
> something that is rather unrelated with the buffer contents but can
> easily be changed by the user. That makes the relation very volatile.

Not really, given that (1) window-width changes quite rarely,
and (2) most macros are used immediately (in the same buffer/window) and
then discarded (or rather, forgotten about).

Anyway, what you're suggesting seems every bit as bad, or worse, than
the problem it's purporting to solve -- without, as far as I can see,
any actual evidence that there _is_ a problem (have we gotten any bug
reports?).

-Miles

-- 
Freebooter, n. A conqueror in a small way of business, whose annexations lack
of the sanctifying merit of magnitude.

Re: line-move-visual never set to nil?

[Lennart Borgman (gmail)]

Miles Bader wrote:
> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
>> I think this case is special. The special thing is the relation between
>> the visual move and the buffer point. That relation changes according to
>> something that is rather unrelated with the buffer contents but can
>> easily be changed by the user. That makes the relation very volatile.
> 
> Not really, given that (1) window-width changes quite rarely,

You have to take into account both line length and window-width.

> and (2) most macros are used immediately (in the same buffer/window) and
> then discarded (or rather, forgotten about).

Yes, that is a good argument.

> Anyway, what you're suggesting seems every bit as bad, or worse, than
> the problem it's purporting to solve -- without, as far as I can see,
> any actual evidence that there _is_ a problem (have we gotten any bug
> reports?).

But that is not such a good argument right now, of course ... ;-)

> -Miles
> 

Re: line-move-visual never set to nil?

[Andrew W. Nosenko]

On Fri, Aug 1, 2008 at 3:46 AM, Miles Bader <miles@gnu.org> wrote:
> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
>> I think this case is special. The special thing is the relation between
>> the visual move and the buffer point. That relation changes according to
>> something that is rather unrelated with the buffer contents but can
>> easily be changed by the user. That makes the relation very volatile.
>
> Not really, given that (1) window-width changes quite rarely,

Not always :-(
While intentional changing of the frame size is rare indeed, they may
be changed just because of bug.

See "Shrinking frames as of past month" thread for example.
(http://lists.gnu.org/archive/html/emacs-devel/2008-03/msg01851.html)

> and (2) most macros are used immediately (in the same buffer/window) and
> then discarded (or rather, forgotten about).
>
> Anyway, what you're suggesting seems every bit as bad, or worse, than
> the problem it's purporting to solve -- without, as far as I can see,
> any actual evidence that there _is_ a problem (have we gotten any bug
> reports?).

-- 
Andrew W. Nosenko <andrew.w.nosenko@gmail.com>

Re: line-move-visual never set to nil?

[Richard M Stallman]

    Wouldn't it be more correct to say that the requirement is that during 
    execution of the macro the command should do the same thing to the 
    buffer as during recording of the macro?

In some sense yes, but when the command's behavior is conditional on
something (whether it be buffer text, or how text appears on the
screen), it has to be conditional in the macro just as it is
conditional when you run the command from the keyboard.

The only way to get rid of these commands' dependence on the window
width is to make the line breaking not depend on the window width.
That might be a good idea.  If some other parameter controls where to
do the line-breaking at word boundaries, rather than the window width
directly, you could set that parameter differently in order to run the
macro.