🚀 go-pugleaf

------- Start of digest -------
Date: Sun, 24 Feb 91 15:52:41 PST
From: Jamie Zawinski <jwz>
To: Info-VM@uunet.UU.NET
Subject: summary thoughts

[vm 5.22]

Somehow the behaviour of vm-follow-summary-cursor isn't quite what I'd like.
It's a little hard to pin down, but I guess I don't really want it to select
the message under point before every command, but I do what the command to
always operate on the message under point.  

That is, if my summary buffer is the current buffer and looks like

   163        22-Feb-91 18:55  ...
   164        23-Feb-91 04:35  ...
- -> 165        23-Feb-91 19:53  ...

and the cursor is on the line of message 163, and I type "d", I want message
163 to be deleted, *not* message 165, as happens if vm-follow-summary-cursor
is nil.  This seems like very counterintuitive behaviour.

The behaviour I would like to see in the above situation is that message 163
is marked as deleted, and the cursor moves to the line of message 164, but
the selected message (and thus the "->") remain at message 165.

When I hit space, in the summary buffer, I would like the selected message to
become the message under point, and when I execute previous-message, I would
like the selected message to become the message on the line immediately above
point, rather than above the selected-message pointer.  Likewise for other
explicit message-motion commands.  

When I am not in the summary buffer, the value of point in the summary buffer
shouldn't matter (wherever it was consulted in the above description, the
message-pointer should be used instead).

This seems like more intuitive behaviour to me.  Any thoughts?

		-- Jamie

------------------------------
From: jcb@wucs1.wustl.edu (James Christopher Beard)
Subject: Re: summary thoughts
Date: 25 Feb 91 03:24:44 GMT
Organization: Washington University, St. Louis MO
To: info-vm@uunet.UU.NET

In article <9102242352.AA22889@sunvalleymall> jwz@lucid.com (Jamie
Zawinski) writes:

> [concerning vm 5.22] Somehow the behaviour of
> vm-follow-summary-cursor isn't quite what I'd like.  It's a little
> hard to pin down, but I guess I don't really want it to select the
> message under point before every command, but I do what the command
> to always operate on the message under point.
> 
> That is, if my summary buffer is the current buffer and looks like
> 
>    163        22-Feb-91 18:55  ...
>    164        23-Feb-91 04:35  ...
> -> 165        23-Feb-91 19:53  ...
> 
> and the cursor is on the line of message 163, and I type "d", I want message
> 163 to be deleted, *not* message 165, as happens if vm-follow-summary-cursor
> is nil.  This seems like very counterintuitive behaviour.

I must agree wholeheartedly.  It is nice, I guess, to have the arrow
pointing out where the mbox buffer is looking, but presumably my
moving of the cursor reflects a moving of attention elsewhere.  I
invariably end up deleting the wrong item in summary mode.  

Similarly, if I put the cursor on a particular message line and press
return, it would make sense that the message under cursor become the
current message (with arrow).  It is counterintuitive to have to type
in its number--after all, I have already pointed to it.  If one wants
a particular message, typing its number and then return would make
sense.  This suggestion differs a little from Jamie's suggestion that
<space> be used to select the message-under-cursor.

> The behaviour I would like to see in the above situation is that
> message 163 is marked as deleted, and the cursor moves to the line of
> message 164, but the selected message (and thus the "->") remain at
> message 165.

I also concur with the suggestions about explicit movement: when the
summary is the focus of attention, motion should be defined with
reference to the cursor, not the "active message" pointer.

> When I am not in the summary buffer, the value of point in the
> summary buffer shouldn't matter (wherever it was consulted in the
> above description, the message-pointer should be used instead).  This
> seems like more intuitive behaviour to me.  
> 
> Any thoughts?

Just agreement.

James Beard
beard@informatics.wustl.edu

------------------------------
From: weisberg@hpcc01.corp.hp.com (Len Weisberg)
Subject: Re: summary thoughts
Date: 26 Feb 91 02:40:22 GMT
Organization: HP Corp Computing & Services
To: info-vm@uunet.UU.NET

James Christopher Beard writes:
> Similarly, if I put the cursor on a particular message line and press
> return, it would make sense that the message under cursor become the
> current message (with arrow).  It is counterintuitive to have to type
> in its number--after all, I have already pointed to it.  If one wants
> a particular message, typing its number and then return would make
> sense.  This suggestion differs a little from Jamie's suggestion that
> <space> be used to select the message-under-cursor.


Here's my solution:

- -----------------------
This is in my   vm-mode-hooks   defun: 

(define-key vm-mode-map "\r"  'vm-goto-message-with-default)


- -----------------------
This is in .emacs:

(autoload 'vm-goto-message-with-default "vm-stuff")



- -----------------------
And this is in vm-stuff.el:  


(defun vm-goto-message-with-default (n)
  "Go to the message numbered N.
Interactively N is the prefix argument.  If no prefix arg is provided
N is prompted for in the minibuffer,
with the message currently pointed to as the default."
  (interactive "P")
  (let ((new-n n))
    (if new-n  ()		;; if n already set, use it  ...  else:
      (save-excursion
	(beginning-of-line)
	(if (eobp)  (progn  (previous-line 1)	(beginning-of-line)))
	(forward-char 2)
	(if (looking-at " ")	(forward-char))
	(if (looking-at "[0-9]+")
	    (setq new-n
		  (buffer-substring 
		   (match-beginning 0) (match-end 0))))
	)
      (setq new-n  (read-string "Go to message: " new-n))
      )
    (setq new-n (string-to-int new-n))
    (if (equal new-n 0)
	(call-interactively 'vm-goto-message)
      (vm-goto-message new-n))
    ))


- -----------------------
- - Len Weisberg - HP Corp Computing & Services - weisberg@corp.HP.COM

------------------------------
Date: Fri, 15 Mar 91 19:30:33 EST
From: kyle@wendy-fate.uu.net (Kyle Jones)
To: Info-VM@uunet.uu.net
In-Reply-To: <9102242352.AA22889@sunvalleymall>
Subject: summary thoughts

Jamie Zawinski writes:
 > [vm 5.22]
 > 
 > Somehow the behaviour of vm-follow-summary-cursor isn't quite what I'd like.
 > It's a little hard to pin down, but I guess I don't really want it to select
 > the message under point before every command, but I do what the command to
 > always operate on the message under point.  
 > 
 > That is, if my summary buffer is the current buffer and looks like
 > 
 >    163        22-Feb-91 18:55  ...
 >    164        23-Feb-91 04:35  ...
 > -> 165        23-Feb-91 19:53  ...
 > 
 > and the cursor is on the line of message 163, and I type "d", I want message
 > 163 to be deleted, *not* message 165, as happens if vm-follow-summary-cursor
 > is nil.  This seems like very counterintuitive behaviour.

But that's the point of having the variable vm-follow-summary-cursor.
Sometimes I scroll the summary buffer becasue I want to look at a part
of the summary that's not visible.  I don't want to have to scroll it
back just to keep the next command from operating on the "wrong"
message.

 > The behaviour I would like to see in the above situation is that message 163
 > is marked as deleted, and the cursor moves to the line of message 164, but
 > the selected message (and thus the "->") remain at message 165.

The tricky thing with this is deciding which commands should move the
message pointer permanently and which should do it only temporarily
for the currently executing command.  It looks like you want the
pointer changed permanently _only_ for the motion commands and the
paging commands.  And vm-isearch, I guess.

 > When I hit space, in the summary buffer, I would like the selected message to
 > become the message under point, and when I execute previous-message, I would
 > like the selected message to become the message on the line immediately above
 > point, rather than above the selected-message pointer.  Likewise for other
 > explicit message-motion commands.

This is an issue I never could make up my mind about.  I left the call
to vm-follow-summary-cursor out of the motion commands only because I
saw the decision as being whether to do, as opposed to whether not to
do, if you get my meaning.  I'm not sure whether motion shoul dbe
relative to the cursor or relative to the current message pointer.

I'd like to hear some more opinions about all this.  The part about
temporarily changing the message pointer for some commands but not
others was palatable and unconfusing to me only after considerable thought.

Needless to say if I make this change, it will be controlled by a
variable.  Otherwise I could easily see this new behavior confusing a
lot of people.  I'm not yet sure if it can be implemented, cleanly.

------------------------------
Date: Sat, 16 Mar 91 03:19:22 PST
From: Jamie Zawinski <jwz%thalidomide>
To: kyle@wendy-fate.uu.net
Cc: Info-VM@uunet.uu.net
In-Reply-To: Kyle Jones's message of Fri, 15-Mar-91 19:30:33 EST <9103160030.AA17488@wendy-fate.UU.NET>
Subject: Re: summary thoughts

Kyle wrote:
> Sometimes I scroll the summary buffer becasue I want to look at a part
> of the summary that's not visible.  I don't want to have to scroll it
> back just to keep the next command from operating on the "wrong"
> message.

Well that wouldn't bother me; that's what the mark stack is for.  If I
knew I wanted to come back to the currently-selected message, I'd push
a mark.  That's something you have to do all the time when cruising
around a source file.  Maybe there could be a keybinding for
move-point-to-selected-message-marker to make this simpler.

> The tricky thing with this is deciding which commands should move the
> message pointer permanently and which should do it only temporarily
> for the currently executing command.  It looks like you want the
> pointer changed permanently _only_ for the motion commands and the
> paging commands.  And vm-isearch, I guess.
>
> I'd like to hear some more opinions about all this.  The part about
> temporarily changing the message pointer for some commands but not
> others was palatable and unconfusing to me only after considerable thought.

Maybe it would make more sense if you didn't think of it as changing the
message pointer temporarily.  How about this set of concepts:

  selected message: the message currently displayed in the body buffer.

  selected message pointer: the "->" in the summary buffer; always points at
  the selected message.

  indicated message: the message corresponding to the summary line under the
  point.  If the summary buffer is not the selected buffer, then this is the
  same as the selected message.

My idea is that all commands should operate on the indicated message, not the
selected message, with the following exceptions:

  "space" should change the selected message to be the same as the indicated
  message.  If they are already the same, it should scroll the selected
  message one page.

  "p" and "n" should make the selected message be the message before or after
  the indicated message. 

These are special cases because their function is to change what the current
message is.

In this scheme, the current behaviour with vm-follow-summary-cursor=t could be
described as "make the selected message match the indicated message before
each command".  The current behaviour with vm-follow-summary-cursor=nil could
be described as "never make the selected message match the indicated message,
and always operate on the selected message instead of the indicated message."

(It may be that in the code itself, it will actually be necessary to narrow
the region to that of the indicated message for certain operations, and
switch things back later; this could probably be abstracted away with a set
of macros.  Something like (with-indicated-message ... ) wrapped around the
body of all commands, which would do the relevant save-restriction and
narrow-to-region.)

> Needless to say if I make this change, it will be controlled by a
> variable.

But of course!  :-)

So what do the rest of you think about this?

		-- Jamie

------- End of digest -------