Re: recenter-top-bottom

Re: recenter-top-bottom

[Alan Mackenzie_JWA]

[-- Attachment #1.1: Type: text/plain, Size: 2068 bytes --]


[Apologies for the lack of threading, etc.]

>     With a prefix arg, it's the same as `recenter'. Otherwise, it
alternately
>     moves the current line to the center, top, and bottom of the window.
In
>     this, it's a bit like `C-M-l'. It's a trivial change, but I find it
useful -
>     I have no need for repeated `C-l' to keep doing the same thing.

> It looks good to me.  What do others think?

I wouldn't like it, because I'd find it too slow.  I've
had defuns bound to C-S-<right>/<left> for years, which
move point directly to the top/bottom of the window
without passing Go or collecting $200.  If I want to zap
point to BOW, I want it done NOW, atomically, not as a
triple key-sequence.

For this reason, I'd find the new command an irritation.
I think it would thus be better to have a user option to
request this new behaviour: something like this (untested):

[I've also edited the doc string; "alternately" is
 inappropriate for three things; "successively" is right.]

(defvar recenter-triple-action-flag t  ; or nil ???
  "....")

(defun recenter-top-bottom (&optional arg)
  "Move current line successively to window center, top, and bottom.
<=====
With prefix ARG, move current line to window-line ARG.
If option `recenter-triple-action-flag' is NIL, just recenter."   ; <=====
  (interactive "P")
  (cond ((and recenter-triple-action-flag           ; <=========
              (eq this-command last-command) (not arg))
         (setq this-command 'recenter-top-bottom-1)
         (recenter 0))
        ((and recenter-triple-action-flag           ; <=========
              (eq 'recenter-top-bottom-1 last-command) (not arg))
         (setq this-command 'recenter-top-bottom-2)
         (recenter -1))
        (t
         (recenter arg))))

Perhaps its behaviour could be changed so that the
current window line is the criterion for where to go,
thusly:
(or <RANDOM> <BOTTOM>) -> <MIDDLE>
<MIDDLE> -> <TOP>
<TOP> -> <BOTTOM>.
This would make the new command more consistent with
C-M-l `reposition-window'.

--
Alan Mackenzie (Nuremberg, Germany).

[-- Attachment #1.2: Type: text/html, Size: 3689 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: recenter-top-bottom

[Lennart Borgman (gmail)]

Alan Mackenzie_JWA wrote:
> [Apologies for the lack of threading, etc.]
> 
>  >     With a prefix arg, it's the same as `recenter'. Otherwise, it 
> alternately
>  >     moves the current line to the center, top, and bottom of the 
> window. In
>  >     this, it's a bit like `C-M-l'. It's a trivial change, but I find 
> it useful -
>  >     I have no need for repeated `C-l' to keep doing the same thing.
> 
>  > It looks good to me.  What do others think?
> 
> I wouldn't like it, because I'd find it too slow.  I've

In what way is it slower when todays binding of C-l?

Re: recenter-top-bottom

[Richard Stallman]

    For this reason, I'd find the new command an irritation.

It would be an irritation, on occasions when you type multiple C-l in
a row and expect the current behavior.  Is that something you often do?

RE: recenter-top-bottom

[Drew Adams]

I don't care what happens with the `recenter-top-bottom' suggestion I made -
feel free to adapt it or ignore it.

There was some interest and some feedback, however, and no one has adapted
the code and installed it, so I'll respond a bit. Again, from here on in,
please do whatever you like with the idea.

It sounds, BTW, as if it might be difficult to please everyone: Juri wants
an option to specify the "center" target (e.g. 1/3 vs 1/2 height). Juri
wants a toggle between the new behavior and plain `recenter', for redrawing
purposes. Alan wants an option (not a toggle) to choose this or plain
`recenter'... (Wrt the last: Users can just rebind `C-l' to `recenter' - no
need for such an option, IMO.)

Below is a new definition that responds to some of the feedback, but not
all. I didn't add any options or toggles - feel free to do so.

With the new definition:

1. The current window line determines the destination: If within the top
third, move to window bottom. If within the middle third, move to top. If
within the bottom third, move to center.

2. The `last-command' is no longer relevant. Only the current window
position decides the destination.

3. Destinations "top" and "bottom" are in fact `scroll-conservatively' and
bottom-minus-`scroll-conservatively', respectively, so you can control how
much is kept on screen. The default value of 0 means use absolute top and
bottom. I don't think it is worthwhile to have a new, separate option for
this, since the purpose of `scroll-conservatively' is about the same - it
seems like a good fit.

Like the previous definition I sent, an explicit ARG (either plain `C-u' or
numeric) always calls `(recenter ARG)'.

Alan:

> I've had defuns bound to C-S-<right>/<left> for years,
> which move point directly to the top/bottom of the window
> without passing Go or collecting $200. If I want to zap
> point to BOW, I want it done NOW, atomically, not as a
> triple key-sequence.

So if you already have a command bound that does that, use it. I don't see
your problem with a command that you don't use. The benefit of this
suggestion is to get 3 destinations with the same key (C-l). If you prefer
to have 3 separate keys for those destinations, go for it.

Alan:

> Having thought about it, I very rarely use a bare C-l.

So, IIUC, (1) you use your own keys/commands to move "NOW" to top or bottom,
and (2) you "very rarely use a bare C-l", which moves to the center. So
`recenter-top-bottom' should "very rarely" have any effect at all on you.
You will remain happy using `C-u C-l' and your C-S-<right>/<left> commands,
as usual. (`C-l' with a prefix arg is the same for `recenter-top-bottom' as
for `recenter'.)

Alan:

> any further functionality on C-l should be optional.

From what you say, you hardly ever use plain `C-l'. If you use `C-l' only
with a prefix arg, then you are not affected at all. However, such an option
could easily be accommodated, if others agree that it is useful. Personally,
I think it's enough for a user to rebind `C-l' to `recenter' - why have an
option for that?

Alan:

> Perhaps its behaviour could be changed so that the
> current window line is the criterion for where to go,

Good idea. I've done that in the new version, below.

Concerning frame redrawing:

The Emacs manual says that frame redisplay occurs only for a text terminal.
If redrawing for plain `C-l' is an important consideration here ("in case
the screen is garbled", which I imagine happens less nowadays), then I
propose that `recenter-top-bottom' be bound to `C-l' only when a window
manager is used. If redisplay for plain `C-l' is not an obstacle, then I
propose that we always bind `C-l' to `recenter-top-bottom'.

Alternatively, to allow for redisplay with no movement, we could add an
option, as Alan suggested, or a toggle, as Juri suggested. Or we could let
plain `C-u' call `(recenter)' to redisplay - in that case, the effect of
`C-u' would be opposite what it is for `recenter'. If there is still a need
for redisplay without movement but the need is rare, then `C-u C-l' is not
too much to ask of users, IMO. And any users who need that often could
simply bind `C-l' to `recenter'.

BTW, the doc string for `recenter' seems to contradict the Emacs manual
(node Scrolling). The manual says that `C-l' with a prefix arg does not
redraw the frame - and that is mentioned specifically in the context of a
numeric arg. The doc string says that redrawing is inhibited for plain
`C-u'; it suggests that redrawing occurs for numeric ARG.

Here's the new definition I'd propose:

(defun recenter-top-bottom (&optional arg)
  "Move current line to line ARG, window center, top, or bottom.
With a prefix argument, this is the same as `recenter':
 With numeric prefix ARG, move current line to window-line ARG.
 With plain `C-u', move current line to window center.

Otherwise, the window starting position determines the next position:
 If in the top third, move to bottom.
 If in middle third,  move to top.
 If in bottom third,  move tocenter.

Top and bottom destinations are actually `scroll-conservatively' lines
from true top and bottom."
  (interactive "P")
  (cond (arg (recenter arg))
        (t
         (let* ((top (1+ (count-lines 1 (window-start))))
                (bottom (1+ (count-lines 1 (window-end))))
                (current (1+ (count-lines 1 (point))))
                (total (window-height)))
           (cond ((< (- current top) (/ total 3))
                  (recenter (1- (- scroll-conservatively))))
                 ((< (- bottom current) (/ total 3)) (recenter))
                 (t (recenter scroll-conservatively)))))))

Note that this code could be optimized by replacing the multiple
`count-lines' calls with a single-traversal pickup of top, bottom and
current values. I don't think such optimization is needed here, however.

Re: recenter-top-bottom

[Juri Linkov]

>   (cond (arg (recenter arg))
>         (t
>          (let* ((top (1+ (count-lines 1 (window-start))))
>                 (bottom (1+ (count-lines 1 (window-end))))
>                 (current (1+ (count-lines 1 (point))))
>                 (total (window-height)))
>            (cond ((< (- current top) (/ total 3))
>                   (recenter (1- (- scroll-conservatively))))
>                  ((< (- bottom current) (/ total 3)) (recenter))
>                  (t (recenter scroll-conservatively)))))))

I like the new definition of `recenter-top-bottom'.  But there is one
problem: it doesn't work when point is close to the end of the buffer.
It doesn't put point to the upper half of the window but this
is possible with other commands (because the end of the buffer
is not attached to the end of the window in Emacs).

Also I suggest replacing `(recenter)' with `(recenter '(4))' to not redraw
the frame when moving point to the center, to not make it different from
moving point to other parts of the window that doesn't redraw the frame.

-- 
Juri Linkov
http://www.jurta.org/emacs/

RE: recenter-top-bottom

[Drew Adams]

> I like the new definition of `recenter-top-bottom'.  But there is one
> problem: it doesn't work when point is close to the end of the buffer.
>
> It doesn't put point to the upper half of the window but this
> is possible with other commands (because the end of the buffer
> is not attached to the end of the window in Emacs).

Or at or near the beginning of the buffer. Depending on what you mean by
"work".

I think it DTRT in these cases, but you're welcome to tweak it.

> Also I suggest replacing `(recenter)' with `(recenter '(4))' to not redraw
> the frame when moving point to the center, to not make it different from
> moving point to other parts of the window that doesn't redraw the frame.

Yes. Go for it.

Re: recenter-top-bottom

[Juri Linkov]

>> I like the new definition of `recenter-top-bottom'.  But there is one
>> problem: it doesn't work when point is close to the end of the buffer.
>>
>> It doesn't put point to the upper half of the window but this
>> is possible with other commands (because the end of the buffer
>> is not attached to the end of the window in Emacs).
>
> Or at or near the beginning of the buffer. Depending on what you mean by
> "work".
>
> I think it DTRT in these cases, but you're welcome to tweak it.

When point is at the end of the buffer and at the middle of the window
then typing C-l could move it to the beginning of the window.

-- 
Juri Linkov
http://www.jurta.org/emacs/

RE: recenter-top-bottom

[Drew Adams]

> >> I like the new definition of `recenter-top-bottom'.  But there is one
> >> problem: it doesn't work when point is close to the end of the buffer.
> >>
> >> It doesn't put point to the upper half of the window but this
> >> is possible with other commands (because the end of the buffer
> >> is not attached to the end of the window in Emacs).
> >
> > Or at or near the beginning of the buffer. Depending on what you mean by
> > "work".
> >
> > I think it DTRT in these cases, but you're welcome to tweak it.
>
> When point is at the end of the buffer and at the middle of the window
> then typing C-l could move it to the beginning of the window.

Sure; do it.

Re: recenter-top-bottom

[Bastien]

Juri Linkov <juri@jurta.org> writes:

>>> I like the new definition of `recenter-top-bottom'.  But there is one
>>> problem: it doesn't work when point is close to the end of the buffer.
>>>
>>> It doesn't put point to the upper half of the window but this
>>> is possible with other commands (because the end of the buffer
>>> is not attached to the end of the window in Emacs).
>>
>> Or at or near the beginning of the buffer. Depending on what you mean by
>> "work".
>>
>> I think it DTRT in these cases, but you're welcome to tweak it.
>
> When point is at the end of the buffer and at the middle of the window
> then typing C-l could move it to the beginning of the window.

I often type C-l when to point is *near* the middle of the buffer, just
to slightly adjust the display.  Sometimes, the point is already in the
very middle and I don't notice it, and typing C-l just leaves the point
where it is -- which is fine.

I would find it disturbing to see the point jumping at the beginning of
the window when it is at the middle of the window.  For me, the middle
of the window is kind of a gravity center, and hitting C-l should go
there first, even when the point is already at the middle of the window.

-- 
Bastien

RE: recenter-top-bottom

[Drew Adams]

> I often type C-l when to point is *near* the middle of the buffer, just
> to slightly adjust the display.

Just out of curiosity, why?

Except for refreshing the display, why anyone would use `C-l' with point
already at or near the center - and want it to stay there - is beyond me.
But people are different.

You could of course still do the same thing, but you would need to hit `C-l'
three times, not one. If you make such minor display adjustments with `C-l'
frequently, then, yes, this is not optimal for you.

> Sometimes, the point is already in the very middle and I
> don't notice it, and typing C-l just leaves the point
> where it is -- which is fine.
>
> I would find it disturbing to see the point jumping at the beginning of
> the window when it is at the middle of the window.  For me, the middle
> of the window is kind of a gravity center, and hitting C-l should go
> there first, even when the point is already at the middle of the window.

As I said, I expect we're not going to be able to satisfy everyone on this,
regardless of how it is tweaked. If we decide to go this route, then there
will always be someone who prefers the old behavior. My preferred response
would be to tell them to just rebind `C-l' to `recenter' - nothing lost. I
would think most people would prefer the proposed behavior - but who knows?

FWIW - I find remarkable the language some people are using. I'm impressed
that anyone finds such a proposal "disturbing" or "an irritation" (and
screams "PLEASE DON'T DO THIS!!!!" for setting `last-command' to an
undefined command name). I'm truly amazed that this is so critical. I have
my own habits and preferences, so I understand, but I'm still a bit
surprised.

Re: recenter-top-bottom

[Bastien]

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

>> I often type C-l when to point is *near* the middle of the buffer, just
>> to slightly adjust the display.
>
> Just out of curiosity, why?

No specific reason, it just appears I took this habit.  It's just a way
to tell myself: okay, now concentrate on what you read.

> Except for refreshing the display, why anyone would use `C-l' with point
> already at or near the center - and want it to stay there - is beyond me.
> But people are different.

Moving the point to the center when the point is *near* the center
sounds okay to me.  

But moving the point from the center to the top when the point is *at*
the center *and* when the last command was not 'recenter-top-bottom is
awkward.  Because it is very likely that I wasn't aware the point was
already at the center and that I just wanted to move it to the center.

You can call this "refreshing", but 80% of the times I'm really trying
to recenter (not refresh) when the point is already at the center.  

Relying on people's ability to *know* that the point is at the center to
move it without surprise sounds a bit risky to me.

> You could of course still do the same thing, but you would need to hit
> `C-l' three times, not one. If you make such minor display adjustments
> with `C-l' frequently, then, yes, this is not optimal for you.

If point is at the center and the last command was 'recenter-top-bottom
then I think it's ok to move the point to the top.  But maybe the first
call should reach the center, even if it's already at the center.

But sure, I could also use `recenter' instead.

> FWIW - I find remarkable the language some people are using. I'm
> impressed that anyone finds such a proposal "disturbing" or "an
> irritation" (and screams "PLEASE DON'T DO THIS!!!!" for setting
> `last-command' to an undefined command name). I'm truly amazed that
> this is so critical.

I guess this is because C-l is a fundamuntal command.  Every little
change to it strikes the imagination quite easily.  Hence people are
shouting, crying, etc. but everyone's trying to be helpful here, no?

Anyway, I hope I was.

-- 
Bastien

RE: recenter-top-bottom

[Drew Adams]

> But moving the point from the center to the top when the point is *at*
> the center *and* when the last command was not 'recenter-top-bottom is
> awkward.  Because it is very likely that I wasn't aware the point was
> already at the center and that I just wanted to move it to the center.

It's unclear to me why someone wants to put the window point exactly at the
center. I look at this as trying to position a section of text, and point,
within a general window area, for convenience, visibility etc. - similar to
scrolling. So, for me, the window point being near the middle or at the
middle is the same goal. Why is it important for you to move the window
point precisely to the center (from nearby)? (You can still do that, but
`C-u C-l' is not as handy, if you want such precision often.)

I'm not trying to persuade you; I just don't see the use case. I can
understand why it might be important sometimes to have the window point
exactly at the window top or bottom, but I can't imagine why it is often
important to move it exactly to the middle from nearby.

> You can call this "refreshing", but 80% of the times I'm really trying
> to recenter (not refresh) when the point is already at the center.

What does that mean - recenter when the window point is already at the
center? You mean near the center, don't you?

> Relying on people's ability to *know* that the point is at the center to
> move it without surprise sounds a bit risky to me.

You don't have to know that the window point is at the center. You just need
to know whether it is nearer the center than the top or bottom. If you want
the window point mainly in the center area, and it is already there, then do
nothing. If it is not already there, then hit `C-l' once or twice. Same with
the other two areas: if the window point is in the area you want (top or
bottom), then do nothing; else hit `C-l' once or twice.

> > You could of course still do the same thing, but you would need to hit
> > `C-l' three times, not one. If you make such minor display adjustments
> > with `C-l' frequently, then, yes, this is not optimal for you.
>
> If point is at the center and the last command was 'recenter-top-bottom
> then I think it's ok to move the point to the top.  But maybe the first
> call should reach the center, even if it's already at the center.

I don't see that. If that were the behavior, I'm sure someone would complain
that s?he had to hit `C-l' twice just to get the window point to move away
from the central area. I think it's better to leave the behavior as defined,
and let people choose whether they want that or plain `recenter' for `C-l'.

> But sure, I could also use `recenter' instead.

It sounds like that is what you prefer. I have no idea what most people
prefer - I was guessing that they would prefer what I proposed, but life can
be full of surprises.

> > FWIW - I find remarkable the language some people are using. I'm
> > impressed that anyone finds such a proposal "disturbing" or "an
> > irritation" (and screams "PLEASE DON'T DO THIS!!!!" for setting
> > `last-command' to an undefined command name). I'm truly amazed that
> > this is so critical.
>
> I guess this is because C-l is a fundamuntal command.  Every little
> change to it strikes the imagination quite easily.  Hence people are
> shouting, crying, etc.

I suppose it's mainly a question of habit - I was wondering if there wasn't
perhaps more than that involved here. But even so, it's not as if the good
ol' `recenter' behavior were being removed altogether. The only question is
about the default behavior - what most people find most helpful.

> but everyone's trying to be helpful here, no? Anyway, I hope I was.

Sure. Anyway, as I said, I don't have a preference for Emacs about this. I
use this as a personal preference, and I don't care whether it becomes the
default behavior or is even added to Emacs as an option. I am curious about
the range of opinion though.

Re: recenter-top-bottom

[Bastien]

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

> So, for me, the window point being near the middle or at the middle is
> the same goal. Why is it important for you to move the window point
> precisely to the center (from nearby)?

Because it would surprise me otherwise, and I would be surprised that
other users wouldn't be surprised by this.  As I said, I mentionned a
habit of mine, but I guess for command like C-l we all share the same
background of fundamental habits.

> (You can still do that, but `C-u C-l' is not as handy, if you want
> such precision often.)

Yes. Again, I am just trying to make my point very clear so that other
users thinking the same can say: I like recenter-top-bottom but I also
expect the point to jump to the center when it's nearby, so I prefer
recenter-top-bottom #2 over #1.

> It sounds like that is what you prefer. I have no idea what most
> people prefer - I was guessing that they would prefer what I proposed,
> but life can be full of surprises.

So we should spare us Emacs specific surprises :)

Lets give time to people to see what they think. 

> Sure. Anyway, as I said, I don't have a preference for Emacs about
> this. I use this as a personal preference, and I don't care whether it
> becomes the default behavior or is even added to Emacs as an option. I
> am curious about the range of opinion though.

Note that it is much easier to have an "opinion" on C-l than to have one
on whether Rimbaud should have delayed his retirement.  Much easier, but
much also.

-- 
Bastien

Re: recenter-top-bottom

[Bastien]

Bastien <bzg@altern.org> writes:

> Yes. Again, I am just trying to make my point very clear so that other
> users thinking the same can say: I like recenter-top-bottom but I also
> expect the point to jump to the center when it's nearby, so I prefer
> recenter-top-bottom #2 over #1.

Sorry, should read: "#1 over #2" ...

-- 
Bastien

Re: recenter-top-bottom

[Robert J. Chassell]

   > I often type C-l when to point is *near* the middle of the buffer, just
   > to slightly adjust the display.

   Just out of curiosity, why?

Sometimes I do that in order to bring an otherwise invisible line into
view at the bottom or top of the window.

    ... rebind `C-l' to `recenter' ...

That is what I plan to do.  It is a minor bother that after all these
years, you are thinking of changing it.  In my .emacs file, that
binding will go along with the definitions using (recenter 0) and
(recenter -1) which I have long called `line-to-top-of-window' and
`line-to-bottom-of-window'.

(Interestingly, I often use `line-to-top-of-window', which is on a
function key.)

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: recenter-top-bottom

[Lennart Borgman (gmail)]

Robert J. Chassell wrote:
> (Interestingly, I often use `line-to-top-of-window', which is on a
> function key.)

I often do that too, but in the Viper vi emulation:

z RET           viper-line-to-top
z .             viper-line-to-middle
z -             viper-line-to-bottom
z H             viper-line-to-top
z M             viper-line-to-middle
z L             viper-line-to-bottom

H       viper-window-top
M       viper-window-middle
L       viper-window-buttom

Re: recenter-top-bottom

[Richard Stallman]

    1. The current window line determines the destination: If within the top
    third, move to window bottom. If within the middle third, move to top. If
    within the bottom third, move to center.

That is clever, but it has the bad effect of altering the behavior
of a single C-l.  The virtue of your previous idea is that it
only alters the effect of repeated C-l.

So I think your first suggestion is better, and I am still thinking
of maybe installing it.

If people are very enthusiastic about your second suggestion,
I will say yes to it.

Re: recenter-top-bottom

[Bastien]

Richard Stallman <rms@gnu.org> writes:

>     1. The current window line determines the destination: If within the top
>     third, move to window bottom. If within the middle third, move to top. If
>     within the bottom third, move to center.
>
> That is clever, but it has the bad effect of altering the behavior
> of a single C-l.  The virtue of your previous idea is that it
> only alters the effect of repeated C-l.

Fully agreed.  See my comment on the fact that any single call to
recenter-top-bottom should recenter, whether the display will be
modified (recenter) or not ("refresh").

> So I think your first suggestion is better

So do I.

-- 
Bastien

RE: recenter-top-bottom

[Drew Adams]

>     1. The current window line determines the destination: If
>        within the top third, move to window bottom. If within
>        the middle third, move to top. If
>        within the bottom third, move to center.
>
> That is clever, but it has the bad effect of altering the behavior
> of a single C-l.  The virtue of your previous idea is that it
> only alters the effect of repeated C-l.

It was a suggestion from Alan, so as not to be required to use `C-l'
repeatedly to move the window point in some cases - just move immediately. I
think it's a good suggestion, myself.

The only things it doesn't let you do are:

1. Hit `C-l' only once to move from top to center. (Top moves to bottom.)
2. Hit `C-l' only once to move from near center to exact center.

Between top and bottom, I think top is the better choice for #1. That is, I
think it is more important for bottom to go to center than for top to go to
center. It seems natural to me, in terms of reading and scrolling. Cycling
means choosing one or the other order, in any case.

I don't understand a need for #2, but Bastien apparently does it often.

> So I think your first suggestion is better, and I am still thinking
> of maybe installing it.
>
> If people are very enthusiastic about your second suggestion,
> I will say yes to it.

I'm neutral. My personal preference (for myself, not for Emacs) is the
second suggestion, and I prefer either to plain `recenter'. But I think it's
unlikely that you will get a consensus for change on `C-l': preferences are
likely to vary, and habit with `recenter' will pull toward the status quo (I
almost said pull toward the center).

RE: recenter-top-bottom

[Drew Adams]

> So I think your first suggestion is better, and I am still thinking
> of maybe installing it. If people are very enthusiastic about
> your second suggestion, I will say yes to it.

Just to make it easier for people who might want to try both and compare,
here again are the two definitions. Each is a possible alternative binding
for `C-l'. (I've added the `scroll-conservatively' feature to #1, as well as
#2.)

(defun recenter-top-bottom-1 (&optional arg)
  "Move current line to window center, top, and bottom, successively.
With prefix ARG, move current line to window-line ARG.
Top and bottom destinations are actually `scroll-conservatively' lines
from true top and bottom."
  (interactive "P")
  (cond ((and (eq this-command last-command) (not arg))
         (setq this-command 'recenter-top-bottom-top)
         (recenter scroll-conservatively))
        ((and (eq 'recenter-top-bottom-top last-command) (not arg))
         (setq this-command 'recenter-top-bottom-bottom)
         (recenter (1- (- scroll-conservatively))))
        (t (recenter arg))))

(defun recenter-top-bottom-2 (&optional arg)
  "Move current line to line ARG, window center, top, or bottom.
With a prefix argument, this is the same as `recenter':
 With numeric prefix ARG, move current line to window-line ARG.
 With plain `C-u', move current line to window center.

Otherwise, the window starting position determines the next position:
 If in the top third, move to bottom.
 If in middle third,  move to top.
 If in bottom third,  move tocenter.

Top and bottom destinations are actually `scroll-conservatively' lines
from true top and bottom."
  (interactive "P")
  (cond (arg (recenter arg))
        (t
         (let* ((top (1+ (count-lines 1 (window-start))))
                (bottom (1+ (count-lines 1 (window-end))))
                (current (1+ (count-lines 1 (point))))
                (total (window-height)))
           (cond ((< (- current top) (/ total 3))
                  (recenter (1- (- scroll-conservatively))))
                 ((< (- bottom current) (/ total 3)) (recenter '(4)))
                 (t (recenter scroll-conservatively)))))))

Re: recenter-top-bottom

[Bastien]

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

>> So I think your first suggestion is better, and I am still thinking
>> of maybe installing it. If people are very enthusiastic about
>> your second suggestion, I will say yes to it.
>
> Just to make it easier for people who might want to try both and compare,
> here again are the two definitions. Each is a possible alternative binding
> for `C-l'. (I've added the `scroll-conservatively' feature to #1, as well as
> #2.)

Thanks for summing up.

Another problem with #2 is this: if the window height is 60 and the
point is at 19, people might not be *sure* that the point is in the
first third of the window.  Pressing C-l will then put the point at the
bottom, while there were expecting it to jump on the top.  Note that in
this case, C-l will do the exact *opposite* of what they want, which is
not only surprising, but rather disappointing!

Relying on the fact that user is able to spot the position of the point
very precisely is not a good thing, especially for large windows, and
especially when the point is between two thirds, where it is the more
difficult to evaluate the position visually.

In fact, I often use C-l to spare me the cost of being sure where the
point is.  

-- 
Bastien

Re: recenter-top-bottom

[Juri Linkov]

>> If people are very enthusiastic about your second suggestion,
>> I will say yes to it.
>
> I'm neutral. My personal preference (for myself, not for Emacs) is the
> second suggestion, and I prefer either to plain `recenter'. But I think it's
> unlikely that you will get a consensus for change on `C-l': preferences are
> likely to vary, and habit with `recenter' will pull toward the status quo (I
> almost said pull toward the center).

The status quo that satisfies everyone is to use `C-0 C-l' (just two
keystrokes) to put point to the top, and `C-- C-l' (again two keystrokes)
to the bottom.

-- 
Juri Linkov
http://www.jurta.org/emacs/

RE: recenter-top-bottom

[Drew Adams]

> The status quo that satisfies everyone is to use `C-0 C-l' (just two
> keystrokes) to put point to the top, and `C-- C-l' (again two keystrokes)
> to the bottom.

OK by me. It's been good enough for many years.

I'll still use my `C-l', because it's easier for me (same key, even if
repeated), but your point is valid.

As I said from the beginning, the proposed behavior is only a minor
convenience. And it is (now) obviously not seen as a convenience by
everyone.

Re: recenter-top-bottom

[Bastien]

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

>> The status quo that satisfies everyone is to use `C-0 C-l' (just two
>> keystrokes) to put point to the top, and `C-- C-l' (again two keystrokes)
>> to the bottom.
>
> I'll still use my `C-l', because it's easier for me (same key, even if
> repeated), but your point is valid.
>
> As I said from the beginning, the proposed behavior is only a minor
> convenience. And it is (now) obviously not seen as a convenience by
> everyone.

Let me state again that I *do* like recenter-top-bottom-1.  I am just
sceptical about recenter-top-bottom-2.

-- 
Bastien

Re: recenter-top-bottom

[Richard Stallman]

    The only things it doesn't let you do are:

    1. Hit `C-l' only once to move from top to center. (Top moves to bottom.)
    2. Hit `C-l' only once to move from near center to exact center.

I think that is unacceptable.  If just about everyone else loves it
I will reconsider; otherwise I don't want it.

I am still interested in your original design, which I think is good.

RE: recenter-top-bottom

[Drew Adams]

> I am still interested in your original design, which I think is good.

I think the version below combines the best of each and should satisfy most
people. It is the same as the original design, except that the cycling order
is appropriate for where you start out.

1. An explicit arg (plain `C-u' or numeric) is always respected, whenever it
is used.

2. Otherwise, the first `C-l' always recenters.

3. Otherwise, successive `C-l' cycles among top, middle, and bottom (top and
bottom are modulo `scroll-conservatively'). The initial position (top,
middle, or bottom third of the window) determines the cycling order:
middle -> bottom -> top versus middle -> top -> bottom.

#1 and #2 mean that unless you repeat `C-l' you get the normal `recenter'
behavior.

#3 means that cycling never repeats the same destination twice in a row -
the order fits the initial cursor position.

(defun recenter-top-bottom (&optional arg)
  "Move current line to window center, top, and bottom, successively.
With a prefix argument, this is the same as `recenter':
 With numeric prefix ARG, move current line to window-line ARG.
 With plain `C-u', move current line to window center.

Otherwise move current line to window center on first call, and to
top, middle, or bottom on successive calls.

The starting position of the window determines the cycling order:
 If initially in the top or middle third: top -> middle -> bottom.
 If initially in the bottom third: bottom -> middle -> top.

Top and bottom destinations are actually `scroll-conservatively' lines
from true window top and bottom."
  (interactive "P")
  (if arg ; Always respect ARG.
      (recenter arg)
    (case last-command
      (recenter-tb-top ; Top -> middle -> bottom
       (setq this-command 'recenter-tb-middle)
       (recenter))
      (recenter-tb-middle
       (setq this-command 'recenter-tb-bottom)
       (recenter (1- (- scroll-conservatively))))
      (recenter-tb-bottom
       (setq this-command 'recenter-tb-top)
       (recenter scroll-conservatively))
      (recenter-tb-bottom-1 ; Bottom -> middle -> top
       (setq this-command 'recenter-tb-middle-1)
       (recenter))
      (recenter-tb-middle-1
       (setq this-command 'recenter-tb-top-1)
       (recenter scroll-conservatively))
      (recenter-tb-top-1
       (setq this-command 'recenter-tb-bottom-1)
       (recenter (1- (- scroll-conservatively))))
      (otherwise ; First time - save mode and recenter.
       (let ((bottom (1+ (count-lines 1 (window-end))))
             (current (1+ (count-lines 1 (point))))
             (total (window-height)))
         (if (< (- bottom current) (/ total 3))
             (setq this-command 'recenter-tb-middle-1)
           (setq this-command 'recenter-tb-middle)))
       (recenter)))))

Re: recenter-top-bottom

[Lennart Borgman (gmail)]

Drew Adams wrote:
>> I am still interested in your original design, which I think is good.
> 
> I think the version below combines the best of each and should satisfy most
> people. It is the same as the original design, except that the cycling order
> is appropriate for where you start out.
> 
> 1. An explicit arg (plain `C-u' or numeric) is always respected, whenever it
> is used.
> 
> 2. Otherwise, the first `C-l' always recenters.
> 
> 3. Otherwise, successive `C-l' cycles among top, middle, and bottom (top and
> bottom are modulo `scroll-conservatively'). The initial position (top,
> middle, or bottom third of the window) determines the cycling order:
> middle -> bottom -> top versus middle -> top -> bottom.


I like this new version. It is useful and inituitive and easy to 
remember IMO.

Re: recenter-top-bottom

[Bastien]

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

>> I am still interested in your original design, which I think is good.
>
> I think the version below combines the best of each and should satisfy
> most people.

I like it, thanks for the changes.

-- 
Bastien

Re: recenter-top-bottom

[Juri Linkov]

> The starting position of the window determines the cycling order:
>  If initially in the top or middle third: top -> middle -> bottom.
>  If initially in the bottom third: bottom -> middle -> top.

But why it does `middle -> bottom -> top' if initially in the middle third?
I think `middle -> top -> bottom' would be much more convenient!

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: recenter-top-bottom

[Lennart Borgman (gmail)]

Juri Linkov wrote:
>> The starting position of the window determines the cycling order:
>>  If initially in the top or middle third: top -> middle -> bottom.
>>  If initially in the bottom third: bottom -> middle -> top.
> 
> But why it does `middle -> bottom -> top' if initially in the middle third?
> I think `middle -> top -> bottom' would be much more convenient!

Agreed.

RE: recenter-top-bottom

[Drew Adams]

> > The starting position of the window determines the cycling order:
> >  If initially in the top or middle third: top -> middle -> bottom.
> >  If initially in the bottom third: bottom -> middle -> top.
> 
> But why it does `middle -> bottom -> top' if initially in the 
> middle third? I think `middle -> top -> bottom' would be
> much more convenient!

It's a toss-up, IMO. 
I have no preference, in any case.
If that's preferred by most, then just switch it:

(otherwise
 (let ((top (1+ (count-lines 1 (window-start))))
       (current (1+ (count-lines 1 (point))))
       (total (window-height)))
   (if (< (- current top) (/ total 3))
       (setq this-command 'recenter-tb-middle)
     (setq this-command 'recenter-tb-middle-1)))
 (recenter))

Re: recenter-top-bottom

[Lennart Borgman (gmail)]

Drew Adams wrote:
>>> The starting position of the window determines the cycling order:
>>>  If initially in the top or middle third: top -> middle -> bottom.
>>>  If initially in the bottom third: bottom -> middle -> top.
>> But why it does `middle -> bottom -> top' if initially in the 
>> middle third? I think `middle -> top -> bottom' would be
>> much more convenient!
> 
> It's a toss-up, IMO. 
> I have no preference, in any case.

I think that you most often want to see something further down since 
writing pushes text downwards and also since reading is from the top to 
the bottom.

> If that's preferred by most, then just switch it:
> 
> (otherwise
>  (let ((top (1+ (count-lines 1 (window-start))))
>        (current (1+ (count-lines 1 (point))))
>        (total (window-height)))
>    (if (< (- current top) (/ total 3))
>        (setq this-command 'recenter-tb-middle)
>      (setq this-command 'recenter-tb-middle-1)))
>  (recenter))

Thanks.

Re: recenter-top-bottom

[Richard Stallman]

It looks good to me, but it needs a comment explaining the precise
meaning of each of the specific values used for this-command.

Re: recenter-top-bottom

[Stefan Monnier]

> (defun recenter-top-bottom (&optional arg)
>   "Move current line to window center, top, and bottom, successively.
> With a prefix argument, this is the same as `recenter':
>  With numeric prefix ARG, move current line to window-line ARG.
>  With plain `C-u', move current line to window center.

> Otherwise move current line to window center on first call, and to
> top, middle, or bottom on successive calls.

> The starting position of the window determines the cycling order:
>  If initially in the top or middle third: top -> middle -> bottom.
>  If initially in the bottom third: bottom -> middle -> top.

> Top and bottom destinations are actually `scroll-conservatively' lines
> from true window top and bottom."
>   (interactive "P")
>   (if arg ; Always respect ARG.
>       (recenter arg)
>     (case last-command
>       (recenter-tb-top ; Top -> middle -> bottom
>        (setq this-command 'recenter-tb-middle)
>        (recenter))
>       (recenter-tb-middle
>        (setq this-command 'recenter-tb-bottom)
>        (recenter (1- (- scroll-conservatively))))
>       (recenter-tb-bottom
>        (setq this-command 'recenter-tb-top)
>        (recenter scroll-conservatively))
>       (recenter-tb-bottom-1 ; Bottom -> middle -> top
>        (setq this-command 'recenter-tb-middle-1)
>        (recenter))
>       (recenter-tb-middle-1
>        (setq this-command 'recenter-tb-top-1)
>        (recenter scroll-conservatively))
>       (recenter-tb-top-1
>        (setq this-command 'recenter-tb-bottom-1)
>        (recenter (1- (- scroll-conservatively))))
>       (otherwise ; First time - save mode and recenter.
>        (let ((bottom (1+ (count-lines 1 (window-end))))
>              (current (1+ (count-lines 1 (point))))
>              (total (window-height)))
>          (if (< (- bottom current) (/ total 3))
>              (setq this-command 'recenter-tb-middle-1)
>            (setq this-command 'recenter-tb-middle)))
>        (recenter)))))

Looks OK, except I'd rather not fool around with last-command and
this-command:

(defvar recenter-last-op nil)

(defun recenter-top-bottom (&optional arg)
  "Move current line to window center, top, and bottom, successively.
With a prefix argument, this is the same as `recenter':
 With numeric prefix ARG, move current line to window-line ARG.
 With plain `C-u', move current line to window center.

Otherwise move current line to window center on first call, and to
top, middle, or bottom on successive calls.

The starting position of the window determines the cycling order:
 If initially in the top or middle third: top -> middle -> bottom.
 If initially in the bottom third: bottom -> middle -> top.

Top and bottom destinations are actually `scroll-conservatively' lines
from true window top and bottom."
  (interactive "P")
  (cond
  (arg (recenter arg)) ; Always respect ARG.
  ((not (eq this-command last-command))
   ;; First time - save mode and recenter.
   (let ((bottom (1+ (count-lines 1 (window-end))))
         (current (1+ (count-lines 1 (point))))
         (total (window-height)))
     (setq recenter-last-op (if (< (- bottom current) (/ total 3))
                                'recenter-tb-middle-1)
                              'recenter-tb-middle)
     (recenter)))
  (t ;; repeat: loop through various options.
   (ecase recenter-last-op
     (recenter-tb-top ; Top -> middle -> bottom
      (setq recenter-last-op 'recenter-tb-middle)
      (recenter))
     (recenter-tb-middle
      (setq recenter-last-op 'recenter-tb-bottom)
      (recenter (1- (- scroll-conservatively))))
     (recenter-tb-bottom
      (setq recenter-last-op 'recenter-tb-top)
      (recenter scroll-conservatively))
     (recenter-tb-bottom-1 ; Bottom -> middle -> top
      (setq recenter-last-op 'recenter-tb-middle-1)
      (recenter))
     (recenter-tb-middle-1
      (setq recenter-last-op 'recenter-tb-top-1)
      (recenter scroll-conservatively))
     (recenter-tb-top-1
      (setq recenter-last-op 'recenter-tb-bottom-1)
      (recenter (1- (- scroll-conservatively))))))))


-- Stefan

RE: recenter-top-bottom

[Drew Adams]

> Looks OK, except I'd rather not fool around with last-command and
> this-command:
>
> (defvar recenter-last-op nil)
>
>    ;; First time - save mode and recenter.
>    (let ((bottom (1+ (count-lines 1 (window-end))))
>          (current (1+ (count-lines 1 (point))))
>          (total (window-height)))
>      (setq recenter-last-op (if (< (- bottom current) (/ total 3))
>                                 'recenter-tb-middle-1)
>                               'recenter-tb-middle)

I was specifically trying to avoid a new global variable, thinking setting
`this-command' was cleaner. Doesn't matter to me, though - go for it, and
please add whatever comments RMS wants.

Re: recenter-top-bottom

[Richard Stallman]

    Looks OK, except I'd rather not fool around with last-command and
    this-command:

That is clean too.  But this version too needs a comment to expain the values
of recenter-last-op.

Re: recenter-top-bottom

[Stefan Monnier]

>     Looks OK, except I'd rather not fool around with last-command and
>     this-command:

> That is clean too.  But this version too needs a comment to expain the values
> of recenter-last-op.

I've installed a slightly simpler version.


        Stefan

Re: recenter-top-bottom

[Johan Bockgård]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Top and bottom destinations are actually `scroll-conservatively' lines
> from true window top and bottom."

I don't think this is right.  `scroll-conservatively' is commonly set to
"a large value".

-- 
Johan Bockgård

Re: recenter-top-bottom

[Leo]

On 2007-12-01 13:55 +0000, Johan Bockgård wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> Top and bottom destinations are actually `scroll-conservatively' lines
>> from true window top and bottom."
>
> I don't think this is right.  `scroll-conservatively' is commonly set to
> "a large value".

I can not understand the doc string of `scroll-conservatively' at all.

-- 
.:  Leo  :.  [ sdl.web AT gmail.com ]  .:  [ GPG Key: 9283AA3F ]  :.

          Use the best OS -- http://www.fedoraproject.org/

Re: recenter-top-bottom

[Eli Zaretskii]

> From: Leo <sdl.web@gmail.com>
> Date: Sat, 01 Dec 2007 14:28:13 +0000
> 
> I can not understand the doc string of `scroll-conservatively' at all.

Please explain what is confusing there.  To me, the doc string sounds
crystal clear.

Maybe if you replace "up to" with "upto", the intent will become more
clear?

Re: recenter-top-bottom

[Leo]

On 2007-12-01 15:48 +0000, Eli Zaretskii wrote:
>> From: Leo <sdl.web@gmail.com>
>> Date: Sat, 01 Dec 2007 14:28:13 +0000
>> 
>> I can not understand the doc string of `scroll-conservatively' at all.
>
> Please explain what is confusing there.  To me, the doc string sounds
> crystal clear.
>
> Maybe if you replace "up to" with "upto", the intent will become more
> clear?

"*Scroll up to this many lines..."

This sounds like a description of a function. The doc string is not
clear at all for a variable.

For example, what's the difference setting it to 1, 100, 10000?

-- 
.:  Leo  :.  [ sdl.web AT gmail.com ]  .:  [ GPG Key: 9283AA3F ]  :.

          Use the best OS -- http://www.fedoraproject.org/

Re: recenter-top-bottom

[Eli Zaretskii]

> From: Leo <sdl.web@gmail.com>
> Date: Sat, 01 Dec 2007 18:33:05 +0000
> 
> "*Scroll up to this many lines..."
> 
> This sounds like a description of a function. The doc string is not
> clear at all for a variable.

You mean, you'd like the doc string to mention the names of functions
affected by this variable?

> For example, what's the difference setting it to 1, 100, 10000?

If you set it to 10000, then moving point 10000 lines below the lowest
screen edge will scroll so as to bring the point's line to the last
line of the window.  If you move more than 10000 lines, the point's
line will be centered (by default, unless you also change
scroll-*-aggressively).

Re: recenter-top-bottom

[Richard Stallman]

    I can not understand the doc string of `scroll-conservatively' at all.

I clarified it in EMACS_22_BASE.  Thanks.

RE: recenter-top-bottom

[Drew Adams]

> > Top and bottom destinations are actually `scroll-conservatively' lines
> > from true window top and bottom."
> 
> I don't think this is right.  `scroll-conservatively' is commonly set to
> "a large value".

Well, the code could certainly be changed to use a different user option from `scroll-conservatively' - perhaps a new option. I said in a previous post:

> I don't think it is worthwhile to have a new, separate
> option for this, since the purpose of `scroll-conservatively'
> is about the same - it seems like a good fit.

FWIW, I still think that's the case. Why do you think that `scroll-conservatively' is commonly set to a large value? The default value is 0, and the Emacs manual says this:

 "if you set `scroll-conservatively' to a small number N,
 then if you move point just a little off the screen--less
 than N lines--then Emacs scrolls the text just far enough
 to bring point back on screen."

That suggests that using a small number is not uncommon; it might even be said to suggest that a small number be used.

Why would someone typically use a large number? More importantly, why would a number that is appropriate for normal use of `scroll-conservatively' not also be appropriate for `recenter-top-bottom'?

Re: recenter-top-bottom

[Richard Stallman]

I set `scroll-conservatively' to a large value just so it will always
be bigger than the screen height.  This means, more or less, that if
Emacs can bring point onto the screen by scrolling, with even one line
of overlap with the old screen, it should do so.

scroll-conservatively default (was: Re: recenter-top-bottom)

[Dan Nicolaescu]

Richard Stallman <rms@gnu.org> writes:

  > I set `scroll-conservatively' to a large value just so it will always
  > be bigger than the screen height.  This means, more or less, that if
  > Emacs can bring point onto the screen by scrolling, with even one line
  > of overlap with the old screen, it should do so.

Then please let's do this by default. The current default of 0 for 
`scroll-conservatively' does not seem to be very helpful.

I would also argue that the default for scroll-preserve-screen-position
should also be changed.

Re: scroll-conservatively default

[Johan Bockgård]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> Then please let's do this by default. The current default of 0 for 
> `scroll-conservatively' does not seem to be very helpful.

It does to me. I *like* Emacs's default scrolling behavior.

-- 
Johan Bockgård

Re: scroll-conservatively default

[Eli Zaretskii]

> From: bojohan+news@dd.chalmers.se (Johan =?utf-8?Q?Bockg=C3=A5rd?=)
> Date: Sun, 02 Dec 2007 02:21:32 +0100
> 
> Dan Nicolaescu <dann@ics.uci.edu> writes:
> 
> > Then please let's do this by default. The current default of 0 for 
> > `scroll-conservatively' does not seem to be very helpful.
> 
> It does to me. I *like* Emacs's default scrolling behavior.

Same here.

RE: scroll-conservatively default

[Drew Adams]

> > > Then please let's do this by default. The current default of 0 for 
> > > `scroll-conservatively' does not seem to be very helpful.
> > 
> > It does to me. I *like* Emacs's default scrolling behavior.
> 
> Same here.

Same here.

Re: scroll-conservatively default

[Dan Nicolaescu]

bojohan+news@dd.chalmers.se (Johan Bockgård) writes:

  > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > 
  > > Then please let's do this by default. The current default of 0 for 
  > > `scroll-conservatively' does not seem to be very helpful.
  > 
  > It does to me. I *like* Emacs's default scrolling behavior.

There are 2 things here:
1. Can you please explain why is it better to have scroll-conservatively
be non-zero?

2. Defaults should not be chosen based on what people that can write
their own .emacs like. They should be chosen but for the benefit of
people that do not have a .emacs. Emacs should try to be consistent with
the general accepted behavior of other applications. And only try to be
different after very careful consideration. 

Re: scroll-conservatively default

[Eli Zaretskii]

> From: Dan Nicolaescu <dann@ics.uci.edu>
> Date: Mon, 03 Dec 2007 13:20:57 -0800
> 
> 2. Defaults should not be chosen based on what people that can write
> their own .emacs like.

The point was that, given the age of this feature (see below), many
users would be accustomed to this behavior, so changing this
particular default would require them all to modify their .emacs.
That's be a hassle, I think.

> Emacs should try to be consistent with the general accepted behavior
> of other applications. And only try to be different after very
> careful consideration.

This would be a valid argument if we were discussing some new behavior
that didn't exist before.  But this particular behavior (scrolling
when point goes outside the visible portion of the buffer) was in
Emacs since day one, many years ago, when practically speaking there
were no "other applications" to be compatible with.  So I don't see
how this argument applies here.

Re: scroll-conservatively default

[Dan Nicolaescu]

Eli Zaretskii <eliz@gnu.org> writes:

  > > From: Dan Nicolaescu <dann@ics.uci.edu>
  > > Date: Mon, 03 Dec 2007 13:20:57 -0800
  > > 
  > > 2. Defaults should not be chosen based on what people that can write
  > > their own .emacs like.
  > 
  > The point was that, given the age of this feature (see below), many
  > users would be accustomed to this behavior, so changing this
  > particular default would require them all to modify their .emacs.
  > That's be a hassle, I think.

My point is that we need to balance the hassle for the old users with
the one for new users that are not used to the behavior.

  > > Emacs should try to be consistent with the general accepted behavior
  > > of other applications. And only try to be different after very
  > > careful consideration.
  > 
  > This would be a valid argument if we were discussing some new behavior
  > that didn't exist before.  But this particular behavior (scrolling
  > when point goes outside the visible portion of the buffer) was in
  > Emacs since day one, many years ago, when practically speaking there
  > were no "other applications" to be compatible with.  So I don't see
  > how this argument applies here.

IMO it is still a valid argument. Users use many more applications
today, and there are some common behaviors that they have come to
expect. Yes, emacs pioneered many many things, and lots of features have
been adopted elsewhere. But some other things have evolved and have been
"standardized" in a different way, and we should seriously consider
changing the defaults to match what other applications are doing.

Re: scroll-conservatively default

[Eli Zaretskii]

> From: Dan Nicolaescu <dann@ics.uci.edu>
> Cc: emacs-devel@gnu.org
> Date: Mon, 03 Dec 2007 23:25:01 -0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
>   > > From: Dan Nicolaescu <dann@ics.uci.edu>
>   > > Date: Mon, 03 Dec 2007 13:20:57 -0800
>   > > 
>   > > 2. Defaults should not be chosen based on what people that can write
>   > > their own .emacs like.
>   > 
>   > The point was that, given the age of this feature (see below), many
>   > users would be accustomed to this behavior, so changing this
>   > particular default would require them all to modify their .emacs.
>   > That's be a hassle, I think.
> 
> My point is that we need to balance the hassle for the old users with
> the one for new users that are not used to the behavior.

I think none of the people who reads this list qualify as
representatives of the latter population of Emacs users.  So it sounds
like this is an argument between old users who like the current
default and those who don't.

Re: scroll-conservatively default

[Dan Nicolaescu]

Eli Zaretskii <eliz@gnu.org> writes:

  > > From: Dan Nicolaescu <dann@ics.uci.edu>
  > > Cc: emacs-devel@gnu.org
  > > Date: Mon, 03 Dec 2007 23:25:01 -0800
  > > 
  > > Eli Zaretskii <eliz@gnu.org> writes:
  > > 
  > >   > > From: Dan Nicolaescu <dann@ics.uci.edu>
  > >   > > Date: Mon, 03 Dec 2007 13:20:57 -0800
  > >   > > 
  > >   > > 2. Defaults should not be chosen based on what people that can write
  > >   > > their own .emacs like.
  > >   > 
  > >   > The point was that, given the age of this feature (see below), many
  > >   > users would be accustomed to this behavior, so changing this
  > >   > particular default would require them all to modify their .emacs.
  > >   > That's be a hassle, I think.
  > > 
  > > My point is that we need to balance the hassle for the old users with
  > > the one for new users that are not used to the behavior.
  > 
  > I think none of the people who reads this list qualify as
  > representatives of the latter population of Emacs users.

Agreed.

  > So it sounds
  > like this is an argument between old users who like the current
  > default and those who don't.

I disagree with that assessment, but I trust that these old users can
come to an agreement that is beneficial to most users, not just to
themselves.

Re: scroll-conservatively default

[Richard Stallman]

    But some other things have evolved and have been
    "standardized" in a different way, and we should seriously consider
    changing the defaults to match what other applications are doing.

We can consider such changes, but we change Emacs merely to follow
other programs only if there is no disadvantage.

Re: scroll-conservatively default

[Dan Nicolaescu]

Richard Stallman <rms@gnu.org> writes:

  >     But some other things have evolved and have been
  >     "standardized" in a different way, and we should seriously consider
  >     changing the defaults to match what other applications are doing.
  > 
  > We can consider such changes, but we change Emacs merely to follow
  > other programs only if there is no disadvantage.

Agreed.
I have personally heard complaints from users about the emacs scrolling
behavior which is different

So here are 2 proposals to change this, please consider them
independently:

1. set scroll-conservatively to some non-zero number by default

2. set scroll-preserve-screen-position to non-nil by default.

Re: scroll-conservatively default

[Leo]

On 2007-12-04 04:13 +0000, Eli Zaretskii wrote:
>> Emacs should try to be consistent with the general accepted behavior
>> of other applications. And only try to be different after very
>> careful consideration.
>
> This would be a valid argument if we were discussing some new behavior
> that didn't exist before.  But this particular behavior (scrolling
> when point goes outside the visible portion of the buffer) was in
> Emacs since day one, many years ago, when practically speaking there
> were no "other applications" to be compatible with.  So I don't see
> how this argument applies here.

This mentality might eventually put Emacs to no more. A long time ago
human live on eating leafs, however we have evolved.

-- 
.:  Leo  :.  [ sdl.web AT gmail.com ]  .:  [ GPG Key: 9283AA3F ]  :.

          Use the best OS -- http://www.fedoraproject.org/

Re: scroll-conservatively default

[Eli Zaretskii]

> From: Leo <sdl.web@gmail.com>
> Date: Tue, 04 Dec 2007 09:28:57 +0000
> 
> This mentality might eventually put Emacs to no more.

Please don't attack my mentality, as you have no idea who I am and
what is my mental world.  You want to argue, fine; but please leave my
mentality alone.

Re: scroll-conservatively default

[Miles Bader]

Leo <sdl.web@gmail.com> writes:
> This mentality might eventually put Emacs to no more. A long time ago
> human live on eating leafs, however we have evolved.

You're not seriously suggesting that people will scorn Emacs because of
minor differences in scrolling behavior are you?

-Miles

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

Re: scroll-conservatively default

[David Kastrup]

Miles Bader <miles.bader@necel.com> writes:

> Leo <sdl.web@gmail.com> writes:
>> This mentality might eventually put Emacs to no more. A long time ago
>> human live on eating leafs, however we have evolved.
>
> You're not seriously suggesting that people will scorn Emacs because of
> minor differences in scrolling behavior are you?

Being able to make the material one needs to view as a unit appear on
the screen painlessly is one of the most important and frequent
operations for a screen editor.

Emacs' keybindings in connection with the scrolling behavior don't help
(vi has extra keybindings C-e and C-y for scrolling without moving
point).

This is pretty much the main reason that I compile
--without-toolkit-scrollbars.  The resulting Athena-style scrollbars are
the only reasonable tool for making an Emacs window show the right
excerpts with a tolerable efficiency.

The "standard" GTK scrollbar is useless for that, and so are the normal
key and scrolling settings.

And yes: if one of the most important and basic function from an editor,
namely getting the desired code range into view, is not available, this
will most certainly keep people from using the editor.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: scroll-conservatively default

[Andreas Schwab]

David Kastrup <dak@gnu.org> writes:

> Being able to make the material one needs to view as a unit appear on
> the screen painlessly is one of the most important and frequent
> operations for a screen editor.
>
> Emacs' keybindings in connection with the scrolling behavior don't help
> (vi has extra keybindings C-e and C-y for scrolling without moving
> point).

I have this since ages:

(defun scroll-up-in-place (n)
  (interactive "p")
  (scroll-up n))

(defun scroll-down-in-place (n)
  (interactive "p")
  (scroll-down n))

(define-key global-map [(shift next)] 'scroll-up-in-place)
(define-key global-map [(shift prior)] 'scroll-down-in-place)

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: scroll-conservatively default

[Richard Stallman]

    I have this since ages:

    (defun scroll-up-in-place (n)
      (interactive "p")
      (scroll-up n))

    (defun scroll-down-in-place (n)
      (interactive "p")
      (scroll-down n))

    (define-key global-map [(shift next)] 'scroll-up-in-place)
    (define-key global-map [(shift prior)] 'scroll-down-in-place)

Is this simply a way to scroll by one line with just one character?

Re: scroll-conservatively default

[Andreas Schwab]

Richard Stallman <rms@gnu.org> writes:

>     I have this since ages:
>
>     (defun scroll-up-in-place (n)
>       (interactive "p")
>       (scroll-up n))
>
>     (defun scroll-down-in-place (n)
>       (interactive "p")
>       (scroll-down n))
>
>     (define-key global-map [(shift next)] 'scroll-up-in-place)
>     (define-key global-map [(shift prior)] 'scroll-down-in-place)
>
> Is this simply a way to scroll by one line with just one character?

Basically yes.  It is much easier to repeat than C-1 C-v.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: scroll-conservatively default

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Thu, 06 Dec 2007 12:10:22 +0100
> Cc: Leo <sdl.web@gmail.com>, emacs-devel@gnu.org
> 
> Emacs' keybindings in connection with the scrolling behavior don't help
> (vi has extra keybindings C-e and C-y for scrolling without moving
> point).

I'm not sure I understand what you mean, but if I do, you can, of
course, have this in Emacs.  I have the following keybindings in my
.emacs since about forever:

  (global-set-key "\C-z" (function (lambda () (interactive) (scroll-up 1))))
  (global-set-key "\M-z" (function (lambda () (interactive) (scroll-down 1))))

(If you like to iconify Emacs, use C-x C-z instead of C-z that is taken
by the above.)

Re: scroll-conservatively default

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Date: Thu, 06 Dec 2007 12:10:22 +0100
>> Cc: Leo <sdl.web@gmail.com>, emacs-devel@gnu.org
>> 
>> Emacs' keybindings in connection with the scrolling behavior don't help
>> (vi has extra keybindings C-e and C-y for scrolling without moving
>> point).
>
> I'm not sure I understand what you mean, but if I do, you can, of
> course, have this in Emacs.  I have the following keybindings in my
> .emacs since about forever:
>
>   (global-set-key "\C-z" (function (lambda () (interactive) (scroll-up 1))))
>   (global-set-key "\M-z" (function (lambda () (interactive) (scroll-down 1))))
>
> (If you like to iconify Emacs, use C-x C-z instead of C-z that is taken
> by the above.)

Sure, I can have this in Emacs.  So can you.  But will a rank beginner
pick suitable bindings and create interactive functions on his own?

If we count my usage of --without-toolkit-scrollbars as one attempt of
getting a fine-grained control over window-start, that is third report
where the default keybindings and scroll behaviors are unproductive
enough to actually cause people to code (or compile) around them.

That is a road not apparent to the rank beginner.  So perhaps if the
majority is satisfied with the general scrolling behavior and just wants
a separate window-start adjustment, we should think about a way to
provide.  Maybe a reasonable starting point would be to bind
scroll-lock-mode by default to <Scroll_Lock>: there is not much point in
a different default binding, is there?  And currently it appears
unbound.  I am not saying that this will put the problem behind us, but
it appears like it could help some people without causing any harm.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: scroll-conservatively default

[Miles Bader]

Eli Zaretskii <eliz@gnu.org> writes:
> I'm not sure I understand what you mean, but if I do, you can, of
> course, have this in Emacs.  I have the following keybindings in my
> .emacs since about forever:
>
>   (global-set-key "\C-z" (function (lambda () (interactive) (scroll-up 1))))
>   (global-set-key "\M-z" (function (lambda () (interactive) (scroll-down 1))))

Yeah, I use C-z and C-q for the same purpose (these bindings are what
the ez editor used).  C-z at least, seems somewhat common in this role.

[The C-q binding is convenient to use, but tends to cause problems
because of the degree to which the default binding of C-q ("quote
character") is embedded in emacs...]

-Miles
-- 
"Nah, there's no bigger atheist than me.  Well, I take that back.
I'm a cancer screening away from going agnostic and a biopsy away
from full-fledged Christian."  [Adam Carolla]

Re: recenter-top-bottom

[Johan Bockgård]

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

> Why do you think that `scroll-conservatively' is commonly set to a
> large value? The default value is 0,

I mean what values people usually set it to when they change it. How
common it is to change it in the first place, I don't know.

> and the Emacs manual says this:

And the doc string of scroll-step says this:

    "If you want scrolling to always be a line at a time, you should set
    `scroll-conservatively' to a large value rather than set this to 1."

When scroll-conservatively is changed, it's usually for this reason, I
think. (See Richard's explanation.)

-- 
Johan Bockgård

RE: recenter-top-bottom

[Drew Adams]

> the doc string of scroll-step says this:
> 
>     "If you want scrolling to always be a line at a time, you should set
>     `scroll-conservatively' to a large value rather than set this to 1."

Where "this" refers to `scroll-step', not `scroll-conservatively', presumably. That could be made clearer, BTW. And "a large value" could be made clearer also: example? What's large?

> When scroll-conservatively is changed, it's usually for this reason, I
> think. (See Richard's explanation.)

1. Then change the `recenter-top-bottom' code to use a new user option, or some other existing option that is more appropriate than `scroll-conservatively'.

2. FWIW, the manual, the `scroll-step' doc string, and Richard seem to be saying different things. The manual (Emacs, node Auto Scrolling) says that you can use "a small number" for `scroll-conservatively' to scroll "the text just far enough to bring point back on screen". The doc string of `scroll-step' says that you can use "a large value" for `scroll-conservatively' to scroll "a line at a time". Those can both be true, but they would seem to be different uses of the option. 

Richard says that he sets `scroll-conservatively' to a large value to "bring point onto the screen by scrolling, with even one line of overlap". That doesn't seem to be the same thing as scrolling "a line at a time".

I'm not saying that anyone is wrong or that the doc should be changed (I don't know). And I'm no longer claiming that `scroll-conservatively' is appropriate for `recenter-top-bottom' (use some other option, if you like). I'm saying only that the uses or interpretations of `scroll-conservatively' seem various.

Re: recenter-top-bottom

[Lennart Borgman (gmail)]

Alan Mackenzie_JWA wrote:
>  >> I wouldn't like it, because I'd find it too slow.  I've
> 
>  >> In what way is it slower when todays binding of C-l?
> 
> Sorry, lack of clarity there. I meant that to scroll point to bottom
> of window, C-l C-l C-l is much slower than C-S-<left>. For me, it
> would be unusably slow. Given that, the changed functionality on C-l,
> though I'd only be caught by it occasionally, would irritate me.


How about C-u - C-l with Drews suggestion?

Re: recenter-top-bottom

[Lennart Borgman (gmail)]

Lennart Borgman (gmail) wrote:
> Alan Mackenzie_JWA wrote:
>>  >> I wouldn't like it, because I'd find it too slow.  I've
>>
>>  >> In what way is it slower when todays binding of C-l?
>>
>> Sorry, lack of clarity there. I meant that to scroll point to bottom
>> of window, C-l C-l C-l is much slower than C-S-<left>. For me, it
>> would be unusably slow. Given that, the changed functionality on C-l,
>> though I'd only be caught by it occasionally, would irritate me.
> 
> 
> How about C-u - C-l with Drews suggestion?


Or, here is another variant similar of Drew's suggestion. This uses 
timeout and does not scroll until the action is decided. I have set the 
time out to 2 seconds here, because it looks like there are some bugs 
when putting back the key sequence that was read:

(defun recenter-top-bottom (&optional arg)
   "Move current line to window center, top, and bottom, alternately.
With prefix ARG, move current line to window-line ARG.

Otherwise if the key sequence that invoked this command is
repeated within `cua-prefix-override-inhibit-delay' then current
line is moved to top, or if repeated again, bottom."
   (interactive "P")
   (if arg
       (recenter arg)
     (let* ((cmd-keys (this-command-keys))
            (delay 2);cua-prefix-override-inhibit-delay)
            (keys (with-timeout (delay nil) (read-key-sequence nil))))
       (if (equal cmd-keys keys)
           (let ((keys (with-timeout (delay nil) (read-key-sequence nil))))
             (if (equal cmd-keys keys)
                 (recenter -1)
               (recenter 0)
               (put-back-read-key-sequence keys)))
         (recenter)
         (put-back-read-key-sequence keys)))))

(defun put-back-read-key-sequence (keys)
   (when keys
     (when (vectorp keys)
       (setq keys (append keys nil)))
     (isearch-unread keys)))

Re: recenter-top-bottom

[Lennart Borgman (gmail)]

Lennart Borgman (gmail) wrote:
> (defun recenter-top-bottom (&optional arg)
>   "Move current line to window center, top, and bottom, alternately.
> With prefix ARG, move current line to window-line ARG.
> 
> Otherwise if the key sequence that invoked this command is
> repeated within `cua-prefix-override-inhibit-delay' then current
> line is moved to top, or if repeated again, bottom."
>   (interactive "P")
>   (if arg
>       (recenter arg)
>     (let* ((cmd-keys (this-command-keys))
>            (delay 2);cua-prefix-override-inhibit-delay)
>            (keys (with-timeout (delay nil) (read-key-sequence nil))))
>       (if (equal cmd-keys keys)
>           (let ((keys (with-timeout (delay nil) (read-key-sequence nil))))
>             (if (equal cmd-keys keys)
>                 (recenter -1)
>               (recenter 0)
>               (put-back-read-key-sequence keys)))
>         (recenter)
>         (put-back-read-key-sequence keys)))))
> 
> (defun put-back-read-key-sequence (keys)
>   (when keys
>     (when (vectorp keys)
>       (setq keys (append keys nil)))
>     (isearch-unread keys)))


I do not understand why, but this version works better:

(defun put-back-read-key-sequence (keys)
   (when keys
     (when (stringp keys)
       (setq keys (string-to-char keys)))
     (when (vectorp keys)
       (setq keys (append keys nil)))
     (isearch-unread keys)))

Re: recenter-top-bottom

[Richard Stallman]

    Or, here is another variant similar of Drew's suggestion. This uses 
    timeout and does not scroll until the action is decided. I have set the 
    time out to 2 seconds here, because it looks like there are some bugs 
    when putting back the key sequence that was read:

Adding a timeout means it really WILL be slow compared with the
current command.  I don't want to make an ordinary single C-l any
slower than it is now.

recenter-top-bottom

[Drew Adams]

Any interest in this or something like it? I bind it to `C-l' in place of
`recenter'. If there is interest, then perhaps `recenter' itself could have
this behavior (but the frame redisplay behavior might need to be taken into
account).

With a prefix arg, it's the same as `recenter'. Otherwise, it alternately
moves the current line to the center, top, and bottom of the window. In
this, it's a bit like `C-M-l'. It's a trivial change, but I find it useful -
I have no need for repeated `C-l' to keep doing the same thing.

(defun recenter-top-bottom (&optional arg)
  "Move current line to window center, top, and bottom, alternately.
With prefix ARG, move current line to window-line ARG."
  (interactive "P")
  (cond ((and (eq this-command last-command) (not arg))
         (setq this-command 'recenter-top-bottom-1)
         (recenter 0))
        ((and (eq 'recenter-top-bottom-1 last-command) (not arg))
         (setq this-command 'recenter-top-bottom-2)
         (recenter -1))
        (t
         (recenter arg))))

Re: recenter-top-bottom

[Lennart Borgman (gmail)]

Drew Adams wrote:
> Any interest in this or something like it? I bind it to `C-l' in place of
> `recenter'. If there is interest, then perhaps `recenter' itself could have
> this behavior (but the frame redisplay behavior might need to be taken into
> account).
> 
> With a prefix arg, it's the same as `recenter'. Otherwise, it alternately
> moves the current line to the center, top, and bottom of the window. In
> this, it's a bit like `C-M-l'. It's a trivial change, but I find it useful -
> I have no need for repeated `C-l' to keep doing the same thing.
> 
> (defun recenter-top-bottom (&optional arg)
>   "Move current line to window center, top, and bottom, alternately.
> With prefix ARG, move current line to window-line ARG."
>   (interactive "P")
>   (cond ((and (eq this-command last-command) (not arg))
>          (setq this-command 'recenter-top-bottom-1)
>          (recenter 0))
>         ((and (eq 'recenter-top-bottom-1 last-command) (not arg))
>          (setq this-command 'recenter-top-bottom-2)
>          (recenter -1))
>         (t
>          (recenter arg))))


I like it, there is less to remember this way.

Re: recenter-top-bottom

[Richard Stallman]

    With a prefix arg, it's the same as `recenter'. Otherwise, it alternately
    moves the current line to the center, top, and bottom of the window. In
    this, it's a bit like `C-M-l'. It's a trivial change, but I find it useful -
    I have no need for repeated `C-l' to keep doing the same thing.

It looks good to me.  What do others think?

Re: recenter-top-bottom

[Tassilo Horn]

Richard Stallman <rms@gnu.org> writes:

>     With a prefix arg, it's the same as `recenter'. Otherwise, it
>     alternately moves the current line to the center, top, and bottom
>     of the window. In this, it's a bit like `C-M-l'. It's a trivial
>     change, but I find it useful - I have no need for repeated `C-l'
>     to keep doing the same thing.
>
> It looks good to me.  What do others think?

I've remapped recenter to it, and I like it very much.

Bye,
Tassilo

Re: recenter-top-bottom

[Juri Linkov]

> Any interest in this or something like it? I bind it to `C-l' in place
> of `recenter'. If there is interest, then perhaps `recenter' itself
> could have this behavior (but the frame redisplay behavior might need
> to be taken into account).

I think there should be an option to toggle this behavior for users who type
C-l repeatedly just to redraw the frame.  And also an option to change
the default position of the center of the window where C-l puts point
when it is typed the first time.  The middle of the window is not always
the preferable position, and I use my own version of C-l that puts point
at appr. 1/3 of the window height.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: recenter-top-bottom

[Alan Mackenzie]

Hi, Drew!

A couple more technical points:

On Tue, Nov 06, 2007 at 08:53:39AM -0800, Drew Adams wrote:
> Any interest in this or something like it? I bind it to `C-l' in place
> of `recenter'. If there is interest, then perhaps `recenter' itself
> could have this behavior (but the frame redisplay behavior might need
> to be taken into account).

> With a prefix arg, it's the same as `recenter'. Otherwise, it
> alternately moves the current line to the center, top, and bottom of
> the window. In this, it's a bit like `C-M-l'. It's a trivial change,
> but I find it useful - I have no need for repeated `C-l' to keep doing
> the same thing.

`recenter' already has two functions: C-l means "redraw screen, scrolling
point to centre" and C-u C-l means "scroll point to centre,
flicker-free".  Having thought about it, I very rarely use a bare C-l.

I reassert my view that any further functionality on C-l should be
optional.

> (defun recenter-top-bottom (&optional arg)
>   "Move current line to window center, top, and bottom, alternately.
> With prefix ARG, move current line to window-line ARG."
>   (interactive "P")
>   (cond ((and (eq this-command last-command) (not arg))
>          (setq this-command 'recenter-top-bottom-1)   <===============

PLEASE DON'T DO THIS!!!!  This is an abuse of `\(this\|last\)-command',
and will surely cause some other emacs function, present or future, to
fail.  In particular, the contents of these variables have always been
executable commands.  Surely you can defyourownvar for this.

>          (recenter 0))
>         ((and (eq 'recenter-top-bottom-1 last-command) (not arg))
>          (setq this-command 'recenter-top-bottom-2)   <================
>          (recenter -1))
>         (t
>          (recenter arg))))

-- 
Alan Mackenzie (Ittersbach, Germany).

Re: recenter-top-bottom

[Richard Stallman]

    >   (cond ((and (eq this-command last-command) (not arg))
    >          (setq this-command 'recenter-top-bottom-1)   <===============

    PLEASE DON'T DO THIS!!!!  This is an abuse of `\(this\|last\)-command',
    and will surely cause some other emacs function, present or future, to
    fail.

Changing the value of these variables is the recommended way to do
this sort of thing.  This is what they were made for.

      In particular, the contents of these variables have always been
    executable commands.

They have been, but I am not sure it matters -- does anything want to
funcall them?  They are normally used for eq comparisons like these,
and the different facilities that use them don't interfere because they
check for different symbols.

The one thing to check is that the feature now being designed to
record the commands and their arguments works in a way that is not
broken by functions such as kill-region, which set this-command.