Re: Proposal to improve the nomenclature of scrolling directions

Re: Proposal to improve the nomenclature of scrolling directions

[Dmitry Gutov]

Eli Zaretskii <eliz@gnu.org> writes:

 >> From: Adrian Robert <Adrian.B.Robert@gmail.com>
 >> Date: Tue, 6 Nov 2012 17:24:08 +0000 (UTC)
 >>
 >> Stephen J. Turnbull <stephen <at> xemacs.org> writes:
 >>
 >> >
 >> > Nix writes:
 >> >
 >> >  > (Even on mobile devices with touchscreens, where you swipe the text
 >> >  > to move the text up, that operation is *still* called 'scrolling
 >> >  > down'.)
 >> >
 >> > Which drives me nuts, because it's the text that moves (and that's
 >> > true in editors, as well).  For me it's "page down" but "scroll the
 >> > text up".  "Scroll [nothing in particular but Do What I Mean dammit]
 >> > <direction>" is just uninterpretable to me.
 >>
 >> Sure, the text moves, but we don't care about it.
 >
 > Alas, people _do_ care about what they do vs what they say or see.
 > Try calling something white "black" and see if it sticks.

Sure, people do care. The main difference is what's to be considered the
point of reference. If we consider the text as more "important", then it
feels "glued in place", and the window scolls down. If, on the other 
hand, the editor is the center of the universe, then yes, the window 
doesn't move anywhere, it's the text that scrolls up.

 >> "Scroll down" refers to what happens with the *viewer's* perspective
 >> into the content that we are focusing on.
 >
 > This reasoning would work if you'd need to swipe the window's frame
 > down, and text would then move up.  But that's not what's happening:
 > the user must explicitly swipe the text UP.
 >
 > This is different from desktops, where you press a key labeled "Page
 > Down", and don't make any gestures in the upward direction.

A good physical analogy might be climbing a tree. You're climbing down,
but when each of yours hands is touching the tree, it's going up
relative to you. When climbing up, vice versa.

Re: Proposal to improve the nomenclature of scrolling directions

[Richard Stallman]

If PageDown is generally understood as the name for what C-v does, it
seems to me we could give that command the new alias `page-down' and
bind C-v to that.  Users would find it clear by reference to what
PageDown does in other programs.  The Emacs Manual use that name to document
the command, but the existing name could remain valid.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call

RE: Proposal to improve the nomenclature of scrolling directions

[Drew Adams]

> If PageDown is generally understood as the name for what C-v does, it
> seems to me we could give that command the new alias `page-down' and
> bind C-v to that.  Users would find it clear by reference to what
> PageDown does in other programs.  The Emacs Manual use that 
> name to document the command, but the existing name could remain
> valid.

Bad idea.  "page" in Emacs function and variable names has a meaning that
revolves around the use of form-feed (^L) as a page delimiter.  That makes it
easy to use `apropos' or completion (e.g. with substring matching) to show you
such names.

Co-opting "page" for this very different meaning (scrolling one screenful or
some other amount) creates false positives, weakening this feature.  And it can
otherwise confuse users.

Re: Proposal to improve the nomenclature of scrolling directions

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Wed, 7 Nov 2012 07:17:52 -0800
> Cc: eliz@gnu.org, Adrian.B.Robert@gmail.com, emacs-devel@gnu.org
> 
> > If PageDown is generally understood as the name for what C-v does, it
> > seems to me we could give that command the new alias `page-down' and
> > bind C-v to that.  Users would find it clear by reference to what
> > PageDown does in other programs.  The Emacs Manual use that 
> > name to document the command, but the existing name could remain
> > valid.
> 
> Bad idea.  "page" in Emacs function and variable names has a meaning that
> revolves around the use of form-feed (^L) as a page delimiter.

Only veteran Emacs users know about that meaning of "page", and those
should have no problems with the current command names.  And anyway,
bringing up arguments from Emacs traditions flies in the face of this
thread's main premise, which is that it's bad to have Emacs traditions
contradict widespread conventions.

> That makes it easy to use `apropos' or completion (e.g. with
> substring matching) to show you such names.
> 
> Co-opting "page" for this very different meaning (scrolling one screenful or
> some other amount) creates false positives, weakening this feature.

Then you must object to commands and variables that match "code-page"
and "codepage", which already show in significant numbers in
'apropos'.  But since we already have this other meaning of "page",
having yet a 3rd one should not be such a grave problem, IMO.

RE: Proposal to improve the nomenclature of scrolling directions

[Drew Adams]

> > Bad idea.  "page" in Emacs function and variable names has 
> > a meaning that revolves around the use of form-feed (^L)
> > as a page delimiter.
> 
> Only veteran Emacs users know about that meaning of "page",

Evidence for that claim?

And what constitutes a "veteran"?  Anyone who has ever used a command such as
`count-lines-page', `backward-page', `sort-pages', `narrow-to-page',
`what-page', or `ps-nb-pages-region'?  Anyone who has ever customized an option
such as `page-delimiter', `ps-even-or-odd-pages', or `ps-selected-pages'?

> and those should have no problems with the current command names.

Irrelevant whether they do or do not.

The point is that adding things whose names include `page' but that have nothing
to do with Emacs pages adds confusion and works against name-matching (e.g.
apropos).  That's all.

> And anyway, bringing up arguments from Emacs traditions

Who said anything about tradition?  I'm talking about the current Emacs
behavior, not just its behavior since Day One.

In general, "page" has a specific operational meaning in Emacs, and scrolling
(unless it is scrolling up to the next/previous page delimiter) has nothing to
do with that meaning.

This is Emacs as it is, not just as it was or according to some quaint
"tradition".

> flies in the face of this thread's main premise, which is that
> it's bad to have Emacs traditions contradict widespread conventions.

Nothing about Emacs's use of page-related functions and variables, where "page"
refers to pages delimited by ^L, "contradicts" that widespread convention about
scrolling.

It is simply that scrolling up/down a windowful of text should be called such.
It should not be called scrolling up/down a "page", unless you deliberately want
to add confusion and muddy the waters.

And yes, I realize that we already have similar misnamed commands, such as
`View-scroll-page-forward', whose doc nevertheless correctly explains that
"page" here just refers to a windowful of text.

> > That makes it easy to use `apropos' or completion (e.g. with
> > substring matching) to show you such names.
> > 
> > Co-opting "page" for this very different meaning (scrolling 
> > one screenful or some other amount) creates false positives,
> > weakening this feature.
> 
> Then you must object to commands and variables that match "code-page"
> and "codepage", which already show in significant numbers in
> 'apropos'.  But since we already have this other meaning of "page",
> having yet a 3rd one should not be such a grave problem, IMO.

"Code page" is not the same as "page", anymore than "White House" is the same as
"house".  So no, I do not object to the use of the standard name "code page" -
it cannot and should not be avoided.

But yes, that can lead to additional "page" matches.  Such is life.  Some things
are unavoidable, even if not ideal.  Referring to scrolling that moves
forward/backward a windowful as "page" scrolling is not one of them.  Just call
it what it is.

And yes, it is true that "page" does have multiple meanings both within and
outside Emacs - from electronic pagers to command-line pagers such as `more' &
`less'.  Such is life.  I don't see the current proposal as a case where Emacs
needs to add "page" scrolling to its vocabulary.  Just one opinion.

Re: Proposal to improve the nomenclature of scrolling directions

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <rms@gnu.org>, <dgutov@yandex.ru>, <Adrian.B.Robert@gmail.com>,
>         <emacs-devel@gnu.org>
> Date: Wed, 7 Nov 2012 10:03:39 -0800
> 
> > > Bad idea.  "page" in Emacs function and variable names has 
> > > a meaning that revolves around the use of form-feed (^L)
> > > as a page delimiter.
> > 
> > Only veteran Emacs users know about that meaning of "page",
> 
> Evidence for that claim?

Frequent postings on help-gnu-emacs.

> And what constitutes a "veteran"?  Anyone who has ever used a command such as
> `count-lines-page', `backward-page', `sort-pages', `narrow-to-page',
> `what-page', or `ps-nb-pages-region'?  Anyone who has ever customized an option
> such as `page-delimiter', `ps-even-or-odd-pages', or `ps-selected-pages'?

All of the above, and then some.

> > and those should have no problems with the current command names.
> 
> Irrelevant whether they do or do not.

It is relevant.  The old names will stay.

> The point is that adding things whose names include `page' but that have nothing
> to do with Emacs pages adds confusion and works against name-matching (e.g.
> apropos).  That's all.

There's no confusion here, because PageDown is a key present on any
widely used keyboard today.  The notion of "paging down" is familiar
to everyone.

> > And anyway, bringing up arguments from Emacs traditions
> 
> Who said anything about tradition?  I'm talking about the current Emacs
> behavior, not just its behavior since Day One.

"Pages" in Emacs, i.e. chunks of text delimited by ^L characters, are
a feature not shared by most other GUI applications.  It is
traditional Emacs behavior to support such pages.  When you talk about
that behavior, you necessarily talk about traditional Emacs behavior,
from day one till today.

> In general, "page" has a specific operational meaning in Emacs, and scrolling
> (unless it is scrolling up to the next/previous page delimiter) has nothing to
> do with that meaning.

Indeed, it does not.  Nevertheless, Emacs users freely use the
PageDown key, and I don't think I ever heard a complaint that it is
confusing why that key does not scroll by Emacs pages.

So I submit that there's no problem here, as a matter of fact.

RE: Proposal to improve the nomenclature of scrolling directions

[Drew Adams]

> > > and those should have no problems with the current command names.
> > Irrelevant whether they do or do not.
> It is relevant.  The old names will stay.

The new names, which include "page" for non page-related stuff, will cause
false-positive matches against "page".  That's the point.  No one said there
would be a problem finding the page-related commands if you name other commands
to also include "page".  Sure, it adds noise, but that's not the problem I
pointed out.

> > The point is that adding things whose names include `page' 
> > but that have nothing to do with Emacs pages adds confusion
> > and works against name-matching (e.g. apropos).  That's all.
> 
> There's no confusion here, because PageDown is a key present on any
> widely used keyboard today.  The notion of "paging down" is familiar
> to everyone.

Sure, but it has nothing to do with Emacs pages (a la page delimiter).  That's
the confusion that this would introduce.

> "Pages" in Emacs, i.e. chunks of text delimited by ^L characters, are
> a feature not shared by most other GUI applications.

Like so many Emacs features.

> It is traditional Emacs behavior to support such pages.

It is Emacs behavior.  That's all.

> When you talk about that behavior, you necessarily talk about
> traditional Emacs behavior, from day one till today.

When you talk about that behavior you talk necessarily about Emacs behavior.
Nothing more.

> So I submit that there's no problem here, as a matter of fact.

The outside world calls "window" what Emacs calls "frame".  Maybe we should
rename all functions and variables that use "frame" to use "window" instead, to
avoid this traditional-Emacs-generated confusion.

You wouldn't mind that, would you, even if it introduced false positives for
people looking for symbols having to do with Emacs windows?

Especially since only Emacs "veterans" are familiar with the terminology of
Emacs windows, and they would anyway still have the original "-window-" symbols
available (at least for a while).

Re: Proposal to improve the nomenclature of scrolling directions

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <rms@gnu.org>, <dgutov@yandex.ru>, <Adrian.B.Robert@gmail.com>,
>         <emacs-devel@gnu.org>
> Date: Wed, 7 Nov 2012 13:00:35 -0800
> 
> The outside world calls "window" what Emacs calls "frame".  Maybe we should
> rename all functions and variables that use "frame" to use "window" instead, to
> avoid this traditional-Emacs-generated confusion.

Yes, maybe we should.

> You wouldn't mind that, would you, even if it introduced false positives for
> people looking for symbols having to do with Emacs windows?

Looking for symbols without knowing well enough what you are looking
for always brings a lot of false positives.  So no, I won't mind.

RE: Proposal to improve the nomenclature of scrolling directions

[Daniel Hackney]

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

"Drew Adams" <drew.adams@oracle.com> wrote:
> > Only veteran Emacs users know about that meaning of "page",
>
> Evidence for that claim?
>
> And what constitutes a "veteran"?  Anyone who has ever used a command
such as
> `count-lines-page', `backward-page', `sort-pages', `narrow-to-page',
> `what-page', or `ps-nb-pages-region'?  Anyone who has ever customized an
option
> such as `page-delimiter', `ps-even-or-odd-pages', or `ps-selected-pages'?

As a single data point: I've been using Emacs for 6 years and have written
"a bunch" of elisp, and I've never noticed the backwards definition of
up/down and have never used any of the aforementioned commands, nor any
command or function which operates on ^L.

I've seen ^L characters in elisp code before (though never in any other
kind of file) and I know it is some kind of "section delimiter" but I never
really saw the point of it.

tl;dr: I wouldn't notice the absence of the ^L commands, and I think that
bringing the scrolling motion commands into agreement with every other
program would be great for newcomers.

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

Re: Proposal to improve the nomenclature of scrolling directions

[Mathias Dahl]

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

Finally a good proposal, thanks!

And about Drew's argument against it, based on the current "page" term
in Emacs, I'd say that very few would have a problem with it. The change
proposed by Richard would do much more good than harm.



On Wed, Nov 7, 2012 at 1:53 AM, Richard Stallman <rms@gnu.org> wrote:

> If PageDown is generally understood as the name for what C-v does, it
> seems to me we could give that command the new alias `page-down' and
> bind C-v to that.  Users would find it clear by reference to what
> PageDown does in other programs.  The Emacs Manual use that name to
> document
> the command, but the existing name could remain valid.
>
> --
> Dr Richard Stallman
> President, Free Software Foundation
> 51 Franklin St
> Boston MA 02110
> USA
> www.fsf.org  www.gnu.org
> Skype: No way! That's nonfree (freedom-denying) software.
>   Use Ekiga or an ordinary phone call
>
>
>

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

Re: Proposal to improve the nomenclature of scrolling directions

[Dmitry Gutov]

Mathias Dahl <mathias.dahl@gmail.com> writes:

> Finally a good proposal, thanks!
>
> And about Drew's argument against it, based on the current "page" term 
> in Emacs, I'd say that very few would have a problem with it. The change 
> proposed by Richard would do much more good than harm.

Put me down for one "yes, please!"

And yeah, switching frames and windows would also serve to improve the
initial period of disorientation for new users, but I don't really see
that happening anytime soon.

Re: Proposal to improve the nomenclature of scrolling directions

[Bruce Korb]

On 11/07/12 13:41, Dmitry Gutov wrote:
> Mathias Dahl <mathias.dahl@gmail.com> writes:
> 
>> Finally a good proposal, thanks!
>>
>> And about Drew's argument against it, based on the current "page" term 
>> in Emacs, I'd say that very few would have a problem with it. The change 
>> proposed by Richard would do much more good than harm.
> 
> Put me down for one "yes, please!"

Another from the peanut gallery:  "Amen!!!" :)

> And yeah, switching frames and windows would also serve to improve the
> initial period of disorientation for new users, but I don't really see
> that happening anytime soon.

Anything that helps clarity is good, but it doesn't trump continuity of behavior.
Changing continuity requires compelling reasons.  "Uniformity of nomenclature"
falls short of compelling. :)

Cheers - Bruce

Re: Proposal to improve the nomenclature of scrolling directions

[Bastien]

Dmitry Gutov <dgutov@yandex.ru> writes:

> Mathias Dahl <mathias.dahl@gmail.com> writes:
>
>> Finally a good proposal, thanks!
>>
>> And about Drew's argument against it, based on the current "page" term 
>> in Emacs, I'd say that very few would have a problem with it. The change 
>> proposed by Richard would do much more good than harm.
>
> Put me down for one "yes, please!"

FWIW me too!

-- 
 Bastien

Re: Proposal to improve the nomenclature of scrolling directions

[Stefan Monnier]

[...scroll-in-place...]
> I'll be happy if it does happen, of course.  One thing that would be
> much simpler is if the functionality is folded into the scrolling
> functions (as a customizable thing, of course), then a large part of

Yes, that's the way I'd like to see it, indeed.


        Stefan

Re: Proposal to improve the nomenclature of scrolling directions

[martin rudalics]

 >> I'll be happy if it does happen, of course.  One thing that would be
 >> much simpler is if the functionality is folded into the scrolling
 >> functions (as a customizable thing, of course), then a large part of
 >
 > Yes, that's the way I'd like to see it, indeed.

Without a post-display hook?  Then the display-engine may override it.

martin

Re: Proposal to improve the nomenclature of scrolling directions

[Stefan Monnier]

>>> I'll be happy if it does happen, of course.  One thing that would be
>>> much simpler is if the functionality is folded into the scrolling
>>> functions (as a customizable thing, of course), then a large part of
>> Yes, that's the way I'd like to see it, indeed.
> Without a post-display hook?  Then the display-engine may override it.

I'm not sure we're talking about the same thing.  I'm just talking about
the fact that the code he has right now does something similar to
advising/redefining some functions (which is the only way to do it for
an external package), and I'd rather just change those functions in the
source code instead.


        Stefan

Re: Proposal to improve the nomenclature of scrolling directions

[Eli Barzilay]

An hour ago, Stefan Monnier wrote:
> >>> I'll be happy if it does happen, of course.  One thing that
> >>> would be much simpler is if the functionality is folded into the
> >>> scrolling functions (as a customizable thing, of course), then a
> >>> large part of
> >> Yes, that's the way I'd like to see it, indeed.
> > Without a post-display hook?  Then the display-engine may override
> > it.
> 
> I'm not sure we're talking about the same thing.  I'm just talking
> about the fact that the code he has right now does something similar
> to advising/redefining some functions (which is the only way to do
> it for an external package), and I'd rather just change those
> functions in the source code instead.

Yes -- to be clear, the only thing that I'm interested in is what Nix
described: having a sequence of scrolling up/down end up with exactly
the same window configuration in the end (provided the same number of
scrolling in both directions).  There's no need for any hooks for
that.

(BTW, I'm not sure if a use case was argued for, so this is ignorable
if it was.  The place where this is most obvious is if I'm working on
a piece of code that is all on the screen and I want to have a quick
peek up the file.  In this case it is very distracting if the screen
ends up at a different position so I don't see the same part of the
code, and/or if the point is not in the same place.  Either of these
require me to manually restore things, which is losing hacking focus.)

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!

Re: Proposal to improve the nomenclature of scrolling directions

[martin rudalics]

 > I'm not sure we're talking about the same thing.  I'm just talking about
 > the fact that the code he has right now does something similar to
 > advising/redefining some functions (which is the only way to do it for
 > an external package),

Scrolling usually happens via commands.  So external packages can always
use pre- and post-command hooks (which I obviously not recommend).

 > and I'd rather just change those functions in the
 > source code instead.

AFAICT scrolling is partially implemented in the scroll functions and
partially in the display engine.  For me, implementing a thing like
`scroll-in-place' means to leave the scroll functions mainly untouched -
we'd just record the original window-point and window-start positions
there.  Then we need a `scroll-point' overlay for the "line is too
short" case (Kim Storm has implemented a similar feature in his
rectangle code) and adjust it in a `post-display' hook - the one you've
been asking for in the past decade.  Also, that `post-display' hook
would have to optionally handle the case where scrolling gets back to
the original point and the user wants the window-start position to match
the position it had before the scrolling sequence started.

martin

Re: Proposal to improve the nomenclature of scrolling directions

[Eli Zaretskii]

> Date: Sat, 10 Nov 2012 12:05:40 +0100
> From: martin rudalics <rudalics@gmx.at>
> Cc: Eli Barzilay <eli@barzilay.org>, emacs-devel@gnu.org
> 
> AFAICT scrolling is partially implemented in the scroll functions and
> partially in the display engine.

True.

> For me, implementing a thing like
> `scroll-in-place' means to leave the scroll functions mainly untouched -
> we'd just record the original window-point and window-start positions
> there.  Then we need a `scroll-point' overlay for the "line is too
> short" case (Kim Storm has implemented a similar feature in his
> rectangle code) and adjust it in a `post-display' hook - the one you've
> been asking for in the past decade.  Also, that `post-display' hook
> would have to optionally handle the case where scrolling gets back to
> the original point and the user wants the window-start position to match
> the position it had before the scrolling sequence started.

You are talking about a solution that would work around the current
code in creative ways.  I would suggest changing the code instead.
Changing the code will necessarily involve touching the scroll
functions, because currently they move point to fit in the window.

Re: Proposal to improve the nomenclature of scrolling directions

[martin rudalics]

 > You are talking about a solution that would work around the current
 > code in creative ways.  I would suggest changing the code instead.

In order to fake the position of the cursor at an arbitrary position
within a window you have to change the display code.  This would also
allow to represent rectangle coloring in a more ingenious way.  So I
obviously favor such a change.

 > Changing the code will necessarily involve touching the scroll
 > functions, because currently they move point to fit in the window.

The `point' (and region) handling part is a different issue.  I'd
strongly suggest to separate this from the display part.

martin

Re: Proposal to improve the nomenclature of scrolling directions

[Eli Zaretskii]

> Date: Sat, 10 Nov 2012 15:09:27 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: eli@barzilay.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
>  > You are talking about a solution that would work around the current
>  > code in creative ways.  I would suggest changing the code instead.
> 
> In order to fake the position of the cursor at an arbitrary position
> within a window you have to change the display code.

I didn't realize there's a requirement to display a cursor when point
is scrolled out of view.  Why is that needed?

>  > Changing the code will necessarily involve touching the scroll
>  > functions, because currently they move point to fit in the window.
> 
> The `point' (and region) handling part is a different issue.  I'd
> strongly suggest to separate this from the display part.

Sorry, I'm confused: what does region handling have to do with this?

And how can you separate the point handling from this issue, when
window_scroll_pixel_based explicitly moves point?

Re: Proposal to improve the nomenclature of scrolling directions

[martin rudalics]

 > I didn't realize there's a requirement to display a cursor when point
 > is scrolled out of view.  Why is that needed?

It isn't when you make the "don't show the cursor feature" available from
Elisp.

 >> The `point' (and region) handling part is a different issue.  I'd
 >> strongly suggest to separate this from the display part.
 >
 > Sorry, I'm confused: what does region handling have to do with this?

Currently, when I highlight the region and scroll the original position
of `point' off-screen (using `scroll-bar-toolkit-scroll'), the region
changes.  When I scroll the original position back on-screen, the region
is hardly where it was before.

 > And how can you separate the point handling from this issue, when
 > window_scroll_pixel_based explicitly moves point?

The display engine would not show the cursor in that case.

martin

Proposal to improve the nomenclature of scrolling directions

[Dani Moncayo]

Hello,

After reading (info "(emacs) Scrolling"), I think the Emacs
terminology for specifying scrolling directions is pretty confusing:

1.  The terms "up" and "down" have the opposite meanings of the ones
commonly used in the (non-emacs) world.  The info node explains that
this is for historical reasons; OK, but then, why don't we try to find
a solution?  (see below)

2.  The terms "forward" and "backward" are used as synonyms for "up"
and "down" respectively.  I guess this was an attempt to mitigate the
previous problem [*], but IMO it worsens it, because:
(a) They are ambiguous: here we are talking about _vertical_
scrolling, and "forward"/"backward" could refer to horizontal
scrolling too.
(b) They take the opposite criterion: while "up"/"down" refer to the
movement of the text (relative to the window), "forward"/"backward"
refer to the movement of the window (relative to the text).  So we end
up with a confusing mix of criteria.


So here is my proposal for solving these problems:
1.  Rename the command `scroll-up' to `scroll-window-down' (an
unambiguous name, which uses the standard approach of describing the
window movement), and define `scroll-up' as an obsolete alias for
`scroll-window-down'.  Likewise for the rest of scroll commands with
"up"/"down" in their names.
2.  Remove the use of "forward" and "backward" to refer to scrolling directions.

WDYT

--- Footnotes ---

[*] http://lists.gnu.org/archive/html/emacs-devel/2011-03/msg01063.html

-- 
Dani Moncayo

Re: Proposal to improve the nomenclature of scrolling directions

[Stefan Monnier]

> (a) They are ambiguous: here we are talking about _vertical_
> scrolling, and "forward"/"backward" could refer to horizontal
> scrolling too.

We could fix that by explicitly mentioning it's vertical scrolling.

> (b) They take the opposite criterion: while "up"/"down" refer to the
> movement of the text (relative to the window), "forward"/"backward"
> refer to the movement of the window (relative to the text).  So we end
> up with a confusing mix of criteria.

That's also a problem in your proposal.

> 1.  Rename the command `scroll-up' to `scroll-window-down' (an

While you can argue it's less ambiguous, you have to think about it
to remove the various ambiguities (e.g. you have think about it before
determining that it probably doesn't mean "scroll-window- as opposed to
scroll-frame-").
The up/down terminology is just to be avoided, I think.  Much clearer is
terminology that refers to the beginning/end of the text.


        Stefan

Re: Proposal to improve the nomenclature of scrolling directions

[Dani Moncayo]

On Sun, Nov 4, 2012 at 3:37 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> (a) They are ambiguous: here we are talking about _vertical_
>> scrolling, and "forward"/"backward" could refer to horizontal
>> scrolling too.
>
> We could fix that by explicitly mentioning it's vertical scrolling.

Yes, but I guess we all agree that "up" is a cleaner, shorter and thus
better name than "vertical backward".

>> (b) They take the opposite criterion: while "up"/"down" refer to the
>> movement of the text (relative to the window), "forward"/"backward"
>> refer to the movement of the window (relative to the text).  So we end
>> up with a confusing mix of criteria.
>
> That's also a problem in your proposal.

I don't think so: my proposal implies to use a single criterion: the
standard one that describes the movement of the window (view port),
relative to the text.

>> 1.  Rename the command `scroll-up' to `scroll-window-down' (an
>
> While you can argue it's less ambiguous, you have to think about it
> to remove the various ambiguities (e.g. you have think about it before
> determining that it probably doesn't mean "scroll-window- as opposed to
> scroll-frame-").

Mmmm, well, then maybe "scroll-view-" would be even better than
"scroll-window-".

> The up/down terminology is just to be avoided, I think.  Much clearer is
> terminology that refers to the beginning/end of the text.

I disagree: IMHO, the words that best describe the direction of a
_vertical_ movement are precisely "up" and "down", and are they are
used elsewhere for this very purpose.

-- 
Dani Moncayo

Re: Proposal to improve the nomenclature of scrolling directions

[Juanma Barranquero]

On Sun, Nov 4, 2012 at 4:00 PM, Dani Moncayo <dmoncayo@gmail.com> wrote:

> I disagree: IMHO, the words that best describe the direction of a
> _vertical_ movement are precisely "up" and "down", and are they are
> used elsewhere for this very purpose.

Yes, up and down describe vertical movement, but as the whole thread
shows, they do not clearly say what is moving, so both readings are
possible.

move-point-towards-end-of-buffer* and
move-point-towards-beginning-of-buffer* are unambiguos.

    Juanma


* I've chosen long names so no one thinks that I'm proposing them,
which I'm not.

Re: Proposal to improve the nomenclature of scrolling directions

[Dani Moncayo]

>> I disagree: IMHO, the words that best describe the direction of a
>> _vertical_ movement are precisely "up" and "down", and are they are
>> used elsewhere for this very purpose.
>
> Yes, up and down describe vertical movement, but as the whole thread
> shows, they do not clearly say what is moving, so both readings are
> possible.

As I said, with my proposal it is clear what part regarded as the
"moving one": the view.  The documentation would be updated to state
this clearly, and also the command names, which explicitly mention the
moving part (e.g. "scroll-view-down").  So the ambiguity would removed
and a single (standard) criterion would be adopted.

> move-point-towards-end-of-buffer* and
> move-point-towards-beginning-of-buffer* are unambiguos.

Vertical (or horizontal) scrolling doesn't necessarily imply moving
the point.  What is moving is the view relative to the text (or
vice-versa), and as I said, IMO the cleaner way to express that should
include the "moving" part (i.e. the view) and the direction
(up/down/left/right).

Hence my proposal: scroll-view-up, scroll-view-down etc.

-- 
Dani Moncayo

Re: Proposal to improve the nomenclature of scrolling directions

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Sun, 4 Nov 2012 18:07:40 +0100
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,
> 	Emacs development discussions <emacs-devel@gnu.org>
> 
> move-point-towards-end-of-buffer* and
> move-point-towards-beginning-of-buffer* are unambiguos.

How about page-up and page-down?  Since they are the same as the key
names, it's possible that users will not be confused by the "who moves
up" dilemma.

Re: Proposal to improve the nomenclature of scrolling directions

[Dani Moncayo]

> How about page-up and page-down?  Since they are the same as the key
> names, it's possible that users will not be confused by the "who moves
> up" dilemma.

But as you know, there is a lot of scrolling commands beyond those
two, like for example "scroll-up-line".

Therefore, we should find a general solution for this.

-- 
Dani Moncayo

Re: Proposal to improve the nomenclature of scrolling directions

[Eli Zaretskii]

> Date: Sun, 4 Nov 2012 18:35:02 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: Juanma Barranquero <lekktu@gmail.com>, monnier@iro.umontreal.ca,
> 	emacs-devel@gnu.org
> 
> > How about page-up and page-down?  Since they are the same as the key
> > names, it's possible that users will not be confused by the "who moves
> > up" dilemma.
> 
> But as you know, there is a lot of scrolling commands beyond those
> two, like for example "scroll-up-line".

page-down-line will do.

> Therefore, we should find a general solution for this.

I don't see why.

Re: Proposal to improve the nomenclature of scrolling directions

[Dani Moncayo]

>> > How about page-up and page-down?  Since they are the same as the key
>> > names, it's possible that users will not be confused by the "who moves
>> > up" dilemma.
>>
>> But as you know, there is a lot of scrolling commands beyond those
>> two, like for example "scroll-up-line".
>
> page-down-line will do.
>
>> Therefore, we should find a general solution for this.
>
> I don't see why.

:(

If we agree that it would be better to adopt the widely accepted
approach of a moving view port (over an static text), then why not
being consistent with that principle in all scrolling commands?

Consistency and uniformity are good programming principles that make
things simpler to learn and remember.  So these principles should be
followed unless there is a good reason not to.

-- 
Dani Moncayo

Re: Proposal to improve the nomenclature of scrolling directions

[Eli Zaretskii]

> Date: Sun, 4 Nov 2012 20:10:39 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: lekktu@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> If we agree that it would be better to adopt the widely accepted
> approach of a moving view port (over an static text)

What "widely accepted approach"?  Most applications don't have names
for the commands invoked by keys, they just use "PageDown" the key
name.

There isn't much prior art here, we are on our own.

> Consistency and uniformity are good programming principles that make
> things simpler to learn and remember.  So these principles should be
> followed unless there is a good reason not to.

And there are good reasons in this case, as others in this thread
pointed out.

Re: Proposal to improve the nomenclature of scrolling directions

[Dani Moncayo]

>> If we agree that it would be better to adopt the widely accepted
>> approach of a moving view port (over an static text)
>
> What "widely accepted approach"?  Most applications don't have names
> for the commands invoked by keys

but people use these terms in normal conversations.

>, they just use "PageDown" the key
> name.

and the way that key is interpreted in all applications I'm aware of
reflects the "widely accepted approach" I was talking about: the
"Down" in "PageDown" refers to the _viewport_ movement (it shows you
the next page).

> There isn't much prior art here, we are on our own.

I disagree.  See above.

>> Consistency and uniformity are good programming principles that make
>> things simpler to learn and remember.  So these principles should be
>> followed unless there is a good reason not to.
>
> And there are good reasons in this case, as others in this thread
> pointed out.

Honestly, I've not seen a single good reason so far.  Stefan made a
valid point when he said that the "window" part in "scroll-window-"
could be confusing, and I agreed.  But as I said, changing "window" to
"view" would remove the confusion.



-- 
Dani Moncayo

Re: Proposal to improve the nomenclature of scrolling directions

[Richard Stallman]

    What "widely accepted approach"?  Most applications don't have names
    for the commands invoked by keys, they just use "PageDown" the key
    name.

Do they generally agree on which direction "PageDown" should scroll?
If so, that would seem to be a general convention for the meaning
of "down" for scrolling.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call

Re: Proposal to improve the nomenclature of scrolling directions

[Dani Moncayo]

>     What "widely accepted approach"?  Most applications don't have names
>     for the commands invoked by keys, they just use "PageDown" the key
>     name.
>
> Do they generally agree on which direction "PageDown" should scroll?

Yes.  Popular web browsers and text processors interpret "PageDown" as
"show the next page".

Therefore, "up" and "down" refer to the view port (not the text).
That convention is the opposite of the one currently used in Emacs.

> If so, that would seem to be a general convention for the meaning
> of "down" for scrolling.

Yes, and my proposal tried to be both unambiguous (including "view" as
part of the new commands' names, e.g. `scroll-view-down') and
consistent with that convention (all scroll commands would follow the
same pattern).

-- 
Dani Moncayo

Re: Proposal to improve the nomenclature of scrolling directions

[Nix]

On 5 Nov 2012, Dani Moncayo uttered the following:

>>     What "widely accepted approach"?  Most applications don't have names
>>     for the commands invoked by keys, they just use "PageDown" the key
>>     name.
>>
>> Do they generally agree on which direction "PageDown" should scroll?
>
> Yes.  Popular web browsers and text processors interpret "PageDown" as
> "show the next page".

And people universally refer to it as 'scrolling down'. Of every
application I have used, only Emacs calls the action carried out when
you hit the page down key scrolling *up*. It still confuses me every
time I need to deal with it, and I've been using Emacsen for twenty
years now.

-- 
NULL && (void)

Re: Proposal to improve the nomenclature of scrolling directions

[Teemu Likonen]

<nix@esperi.org.uk> [2012-11-05 14:56:29 +0000] wrote:

> And people universally refer to it as 'scrolling down'.

That's right. Let's ask people in the net too:

    "scroll down"
    https://www.google.com/search?q=%22scroll+down%22

    "scroll up"
    https://www.google.com/search?q=%22scroll+up%22

> Of every application I have used, only Emacs calls the action carried
> out when you hit the page down key scrolling *up*. It still confuses
> me every time I need to deal with it, and I've been using Emacsen for
> twenty years now.

I, too, think that Emacs is the only one which calls it this way.

Re: Proposal to improve the nomenclature of scrolling directions

[Harald Hanche-Olsen]

[Nix <nix@esperi.org.uk> (2012-11-05 14:56:29 UTC)]

> Of every
> application I have used, only Emacs calls the action carried out when
> you hit the page down key scrolling *up*. It still confuses me every
> time I need to deal with it, and I've been using Emacsen for twenty
> years now.

I don't use C-x < and C-x > very often, but when I do, I *always* get
the direction wrong. Surely, the same issue is at play here.

But I'll stop whining right now and just insert code in .emacs to swap
the two key bindings. I just couldn't resist this opportunity to
participate in some good bike shedding.

- Harald

Re: Proposal to improve the nomenclature of scrolling directions

[Bastien]

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

Hi Harald,

Harald Hanche-Olsen <hanche@math.ntnu.no> writes:

> I don't use C-x < and C-x > very often, but when I do, I *always* get
> the direction wrong. Surely, the same issue is at play here.

Me too.  

But here, the issue is not only about the names of these commands but
also about the choice of '<' and '>' wrt the consistency with M-< and
M->.  With M-< going at the beginning of the buffer, C-x < suggests
scrolling toward the beginning of the left margin (at least to me), 
which is... the opposite of the current behavior.

> But I'll stop whining right now and just insert code in .emacs to swap
> the two key bindings. I just couldn't resist this opportunity to
> participate in some good bike shedding.

:)

I'm attaching a trivial patch in case.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: window.c.patch --]
[-- Type: text/x-patch, Size: 550 bytes --]

=== modified file 'src/window.c'
--- src/window.c	2012-11-12 04:00:55 +0000
+++ src/window.c	2012-11-13 09:00:54 +0000
@@ -6912,8 +6912,8 @@
 void
 keys_of_window (void)
 {
-  initial_define_key (control_x_map, '<', "scroll-left");
-  initial_define_key (control_x_map, '>', "scroll-right");
+  initial_define_key (control_x_map, '>', "scroll-left");
+  initial_define_key (control_x_map, '<', "scroll-right");
 
   initial_define_key (global_map, Ctl ('V'), "scroll-up-command");
   initial_define_key (meta_map, Ctl ('V'), "scroll-other-window");


[-- Attachment #3: Type: text/plain, Size: 14 bytes --]


-- 
 Bastien

Re: Proposal to improve the nomenclature of scrolling directions

[Stefan Monnier]

> But here, the issue is not only about the names of these commands but
> also about the choice of '<' and '>' wrt the consistency with M-< and
> M->.  With M-< going at the beginning of the buffer, C-x < suggests
> scrolling toward the beginning of the left margin (at least to me),
> which is... the opposite of the current behavior.

I tend to agree.  And the consistency with C-v agrees as well.


        Stefan

Re: Proposal to improve the nomenclature of scrolling directions

[Stephen J. Turnbull]

Dani Moncayo writes:

 > Therefore, we should find a general solution for this.

There's only one "general solution": prohibit from using Emacs all
those people who disagree with your intuition of what's moving.  I've
seen this discussion several times on both the XEmacs and Emacs lists,
and the end is always inconclusive.  The best you can do is simply
choose a consistent terminology, accepting that a large number of
people will never agree.  AFAIK that's already been achieved, by
choosing more or less arbitrarily[1] what makes sense to RMS.

FWIW, for me personally "view" has no useful semantics here.  It
simply indicates a visible region of the buffer.  "Scroll" means the
buffer content moves "in the view".  The idea that the view moves
makes no sense to me because of the ergonomics: moving view means your
eyes have to move, while moving content brings the content to your
focal point.  Also, in "scroll-view" the word "view" is redundant,
because scrolling implies that the view is restricted.  Net results is
that "scroll-up" should mean content "below" the view should "move up"
into it.  So my intuition agrees with current Emacs practice.

Since I agree with current practice, it's a weak test but I believe
this doesn't actually matter.  My fingers know what to do regardless
of the name.



Footnotes: 
[1]  At best a poll was taken, but surely no proper ergonomic study
was done!

Re: Proposal to improve the nomenclature of scrolling directions

[Dani Moncayo]

>  > Therefore, we should find a general solution for this.
>
> There's only one "general solution": prohibit from using Emacs all
> those people who disagree with your intuition of what's moving.

No need for intuition, nor prohibition of using emacs: I was proposing
a general and unambiguous way of naming the scroll commands, which
explicitly state both the part that is moving ("view" or whatever name
you like) and the direction of movement ("up"/"down"/"left"/"right").


-- 
Dani Moncayo

Re: Proposal to improve the nomenclature of scrolling directions

[Jambunathan K]

> what's moving

I am reminded of this:

    http://users.rider.edu/~suler/zenstory/movingmind.html
-- 

Re: Proposal to improve the nomenclature of scrolling directions

[Stefan Monnier]

>> We could fix that by explicitly mentioning it's vertical scrolling.
> Yes, but I guess we all agree that "up" is a cleaner, shorter and thus
> better name than "vertical backward".

Except that up/down bring with them the ambiguity.

> Mmmm, well, then maybe "scroll-view-" would be even better than
> "scroll-window-".

The problem is that most users don't even know about this "viewport vs
content" issue.  So using "up/down" forces them to learn about this
ambiguity and how it's resolved.

That's the reason why I prefer a terminology that is not loaded with
ambiguity that we then have to explain away.  BTW, next/prev is probably
easier to use than beginning/end.


        Stefan

Re: Proposal to improve the nomenclature of scrolling directions

[Dani Moncayo]

>>> We could fix that by explicitly mentioning it's vertical scrolling.
>> Yes, but I guess we all agree that "up" is a cleaner, shorter and thus
>> better name than "vertical backward".
>
> Except that up/down bring with them the ambiguity.

"up"/"down" alone are ambiguous, of course.  But I wasn't proposing
them alone.  I was including also the part that is moving ("view" or
whatever name describes the view port).

Anyway, I think I've repeated my POV several times already, so I'll
give up on this.

-- 
Dani Moncayo

Re: Proposal to improve the nomenclature of scrolling directions

[Stefan Monnier]

> "up"/"down" alone are ambiguous, of course.  But I wasn't proposing
> them alone.  I was including also the part that is moving ("view" or
> whatever name describes the view port).

The real source of the problem is that most users are not aware that
there's an ambiguity, and so adding "viewport" (which they might even
not know) or "window" or "buffer content" won't help them much.

> Anyway, I think I've repeated my POV several times already, so I'll
> give up on this.

Yes, I think we need to agree to disagree here.

OTOH I agree with the part of your proposal to rename those scroll
functions to move away from the ambiguous names.
I.e. rename the functions to something like scroll-next* and
scroll-prev* (while keep compatibility aliases, of course).

If you could submit a patch that does that, that would be nice,


        Stefan

Re: Proposal to improve the nomenclature of scrolling directions

[Daniel Hackney]

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

"Stefan Monnier" <monnier@iro.umontreal.ca> wrote:
>
> > "up"/"down" alone are ambiguous, of course.  But I wasn't proposing
> > them alone.  I was including also the part that is moving ("view" or
> > whatever name describes the view port).
>
> The real source of the problem is that most users are not aware that
> there's an ambiguity, and so adding "viewport" (which they might even
> not know) or "window" or "buffer content" won't help them much.

Given the universal use of down/up in every other program, I don't see how
it's ambiguous. Emacs even has "Top" or "Bot" in the mode line when you are
at the beginning or end of the buffer. Moving towards the top is "up",
moving towards the bottom is "down".

In the context of elisp code, I think it might make some sense to talk
about next/previous lines for the purpose of disambiguation in the face of
overlays, longlines and visual-line-mode, but for anything user-facing,
"up" and "down" are the standards. I might be too young (25), but I've
never come across or considered the possibility that the directions might
be reversed. If you press the down arrow on they keyboard, point moves
downward and if it reaches the bottom of the window, the buffer is scrolled
down.

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

Re: Proposal to improve the nomenclature of scrolling directions

[Richard Stallman]

    1.  The terms "up" and "down" have the opposite meanings of the ones
    commonly used in the (non-emacs) world.  The info node explains that
    this is for historical reasons; OK, but then, why don't we try to find
    a solution?  (see below)

It is not "historical reasons".  This meaning is just as good
as the other meaning.

If the world has indeed converged on the other meaning then I agree
it would be good to be compatible.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call

Re: Proposal to improve the nomenclature of scrolling directions

[Nix]

On 5 Nov 2012, Richard Stallman verbalised:
> If the world has indeed converged on the other meaning then I agree
> it would be good to be compatible.

The world had converged on the other meaning by the late 1980s at the
very latest. By now, as far as I can tell, Emacs is unique among modern
editors in its naming scheme for scroll directions. (Even on mobile
devices with touchscreens, where you swipe the text to move the text up,
that operation is *still* called 'scrolling down'.)

-- 
NULL && (void)

Re: Proposal to improve the nomenclature of scrolling directions

[Stephen J. Turnbull]

Nix writes:

 > (Even on mobile devices with touchscreens, where you swipe the text
 > to move the text up, that operation is *still* called 'scrolling
 > down'.)

Which drives me nuts, because it's the text that moves (and that's
true in editors, as well).  For me it's "page down" but "scroll the
text up".  "Scroll [nothing in particular but Do What I Mean dammit]
<direction>" is just uninterpretable to me. ;-)

I don't really care if you invert the names in Emacs, but I would
prefer using a verb other than "scroll" that strongly implies moving
the viewport (eg, "page") over a given buffer.  I have less problems
with paging fractionally (eg, measured in lines) than with scrolling
viewports (reminds me of the door in Howell's Moving Castle, or if you
want a less fantastical illustration, the new paging look in Mac
Finder or Safari on an iPhone where the content changes as the
viewport scrolls).

From-the-Rick-Moen-Dept:but-maybe-that's-just-me-ly y'rs,

Re: Proposal to improve the nomenclature of scrolling directions

[Adrian Robert]

Stephen J. Turnbull <stephen <at> xemacs.org> writes:

> 
> Nix writes:
> 
>  > (Even on mobile devices with touchscreens, where you swipe the text
>  > to move the text up, that operation is *still* called 'scrolling
>  > down'.)
> 
> Which drives me nuts, because it's the text that moves (and that's
> true in editors, as well).  For me it's "page down" but "scroll the
> text up".  "Scroll [nothing in particular but Do What I Mean dammit]
> <direction>" is just uninterpretable to me. 

Sure, the text moves, but we don't care about it.  "Scroll down" refers to
what happens with the *viewer's* perspective into the content that we are
focusing on.  We COULD say, "move the text up so I can see the last section,",
but it doesn't come across very smoothly, precisely because we have this
focus.  Like we could also say, "the lion is moving forwards," instead of "the
lion is coming towards us," but I'll be happy to bet with you which version
gets used in real life. :)  (And why "up" / "down" instead of "forward" /
"back", there are many reasons but the biggest is of course how we arrange
text on a printed page.  "Scrolling" is more amusing, especially since by the
time computers were developed it's doubtful many people had so much as SEEN a
scroll in real life.)

Re: Proposal to improve the nomenclature of scrolling directions

[Eli Zaretskii]

> From: Adrian Robert <Adrian.B.Robert@gmail.com>
> Date: Tue, 6 Nov 2012 17:24:08 +0000 (UTC)
> 
> Stephen J. Turnbull <stephen <at> xemacs.org> writes:
> 
> > 
> > Nix writes:
> > 
> >  > (Even on mobile devices with touchscreens, where you swipe the text
> >  > to move the text up, that operation is *still* called 'scrolling
> >  > down'.)
> > 
> > Which drives me nuts, because it's the text that moves (and that's
> > true in editors, as well).  For me it's "page down" but "scroll the
> > text up".  "Scroll [nothing in particular but Do What I Mean dammit]
> > <direction>" is just uninterpretable to me. 
> 
> Sure, the text moves, but we don't care about it.

Alas, people _do_ care about what they do vs what they say or see.
Try calling something white "black" and see if it sticks.

> "Scroll down" refers to what happens with the *viewer's* perspective
> into the content that we are focusing on.

This reasoning would work if you'd need to swipe the window's frame
down, and text would then move up.  But that's not what's happening:
the user must explicitly swipe the text UP.

This is different from desktops, where you press a key labeled "Page
Down", and don't make any gestures in the upward direction.

RE: Proposal to improve the nomenclature of scrolling directions

[Drew Adams]

> by the time computers were developed it's doubtful many people
> had so much as SEEN a scroll in real life.

FWIW -

1. Long after the advent and even the widespread use of digital computers, many
of us came into frequent contact (e.g., in school) with so-called "overhead
projectors", which projected light through transparencies onto a screen or wall.

It was not uncommon for the projector to be outfitted with a transparency roll,
on which the presentor wrote with a grease pencil or a marker during projection,
and which the presenter scrolled using a hand crank.

Scrolling was typically right-to-left; that is, the projected images moved
toward the left, with fresh, unmarked transparency moving in from the right.

The viewport thus moved to the right through the images/text, though no one
would have spoken, in that context, of a viewport.

2. Others of us have used film in movie projectors or film splicers.  Likewise
tape recorders and players, on down to cassette tapes of various sorts.  All
scrolls by another name, though no one would have spoken of them using that
term.

Re: Proposal to improve the nomenclature of scrolling directions

[John Yates]

On Tue, Nov 6, 2012 at 11:50 AM, Drew Adams <drew.adams@oracle.com>
introduced a description of various ways to experience "scrolling" in
the physical world via

> 1. Long after the advent and even the widespread use of digital computers, ...

Many on this list probably are old enough to remember fan folded paper
continuously fed into line printers and dot matrix terminals.  True
old timers will have worked on Teletype machines fed from fat rolls of
pulpy yellow paper.

When programmers describe a shell session captured in a file or a
buffer as a "typescript" I have always assumed that terminology to
hearken back to such physical experiences.

/john

Re: Proposal to improve the nomenclature of scrolling directions

[Daniel Hackney]

Dani Moncayo <dmoncayo@gmail.com> wrote:
> Hello,
>
> After reading (info "(emacs) Scrolling"), I think the Emacs
> terminology for specifying scrolling directions is pretty confusing:
>
> 1.  The terms "up" and "down" have the opposite meanings of the ones
> commonly used in the (non-emacs) world.  The info node explains that
> this is for historical reasons; OK, but then, why don't we try to find
> a solution?  (see below)

Wow. I've been using Emacs hardcore for 6 years and never noticed this!
I can understand the window/frame naming, but I never imagined that
Emacs would do things backwards for scrolling. The idea that "down"
would mean "up" is baffling.

I suppose a transition would be difficult, but I can't imagine why it
should stick with the opposite definition from everything else. Emacs
uses "down" to mean "move downwards" in its documentation already:

  - =next-line= :: Move cursor vertically down ARG lines.
  - =outline-move-subtree-up= :: Move the current subtree up past ARG
       headlines of the same level.
  - bindings.el :: (define-key global-map [up] 'previous-line)
  - =end-of-defun= :: Move forward to next end of defun.
  - =eobp= :: Return t if point is at the end of the buffer.
  - =erc-scroll-to-bottom= :: Recenter WINDOW so that `point' is on
the last line.

Plus, it's what every other program uses:

* Firefox
  - scroll on mobile ::
http://support.mozilla.org/en-US/kb/how-do-i-turn-do-not-track-feature-mobile
  - page down ::
http://support.mozilla.org/en-US/kb/settings-network-updates-and-encryption
* LibreOffice
  - Writer navigation :: http://help.libreoffice.org/Writer/Navigation
* Gnome terminal
  - Scroll through commands ::
http://library.gnome.org/users/gnome-terminal/stable/gnome-terminal-usage.html.en
* Microsoft Office
  - Through a worksheet ::
http://office.microsoft.com/en-us/excel-help/scroll-through-a-worksheet-HP005201425.aspx
* Gnumeric
  - Scrollbars ::
http://projects.gnome.org/gnumeric/doc/sect-graphics-widgets-scrollbar.shtml
* Gtk
  - =GtkScrolledWindow= :: http://www.gtk.org/api/2.6/gtk/GtkScrolledWindow.html
  - left moves towards the top ::
http://www.gtk.org/api/2.6/gtk/GtkTextView.html#gtk-text-view-scroll-to-mark

Et Cetera.

All of the documentation refers to "movement towards =(point-max)=" as
going towards the end or bottom of the buffer/window. It wouldn't make
sense to say "scroll up to the end of the window" or "scroll all the way
down until you reach the beginning."

--
Daniel Hackney

Re: Proposal to improve the nomenclature of scrolling directions

[Stephen J. Turnbull]

Daniel Hackney writes:

 > All of the documentation refers to "movement towards =(point-max)=" as
 > going towards the end or bottom of the buffer/window. It wouldn't make
 > sense to say "scroll up to the end of the window" or "scroll all the way
 > down until you reach the beginning."

The term was earlier used with movie credits (and marquees, in the
horizontal orientation), and I guess it was borrowed from that usage.
There the text clearly scrolls *up* the screen until it reaches the
bottom.  When you read text from a paper scroll, you also are clearly
scrolling *up* in order to read *down* the text.

The reason the phrases you give don't make sense[1] is that the implicit
object of the verb "scroll" has changed from the text (or the scroll
the text is printed on) to something else -- but I wish you luck
coming up with a coherent definition of that object for the phrases
you quote.  Common usage of this term, by any sane measure, is
completely confused.

Nevertheless, common usage is quite consistent, and everybody seems to
know what you mean when "scroll <direction>" is used intransitively.
Language evolution sucks when you're old enough to realize it's
happening! :-)

Footnotes: 
[1]  N.B. In the context of a physical scroll of paper, "scroll all
the way down until you reach the beginning" *does* make sense.

Re: Proposal to improve the nomenclature of scrolling directions

[Nix]

On 6 Nov 2012, Stephen J. Turnbull verbalised:
> The reason the phrases you give don't make sense[1] is that the implicit
> object of the verb "scroll" has changed from the text (or the scroll
> the text is printed on) to something else -- but I wish you luck
> coming up with a coherent definition of that object for the phrases
> you quote.

FWIW the object I have always imagined is scrolling down is 'the user's
viewport'. So 'scroll down' and 'scroll the text up' are synonymous, but
the latter is almost never used, since everyone's mental model these
days is of unchanging text and a freely moving viewport over the top of
it.

(This model is also why I use Eli Barzilay's wonderfully simple
scroll-in-place implementation, which I really should contribute to
upstream Emacs one of these years: I had Eli's go-ahead nearly two years
ago, IIRC, and it does need a couple of lines of changes to Gnus to work
properly so upstream Emacs is the right place for it. If what you are
scrolling is a moving viewport, it is *seriously* confusing to have a
sequence of PgDns followed by the same number of PgUps not be an inverse
at all times, and vice versa for the other way around. If you think of
the text as moving, it is somewhat less confusing, though perhaps not
less annoying.)

-- 
NULL && (void)

Re: Proposal to improve the nomenclature of scrolling directions

[Stefan Monnier]

> (This model is also why I use Eli Barzilay's wonderfully simple
> scroll-in-place implementation, which I really should contribute to
> upstream Emacs one of these years: I had Eli's go-ahead nearly two years

Hadn't heard about it.  I just looked at
https://github.com/elibarzilay/eliemacs/blob/master/include/scroll-in-place.el
and IIUC all it does is to remember the previous positions during
a sequence of scroll commands, and to use them when scrolling back.

This sounds OK indeed.

It could also be used to let the user go back to where she was before
scrolling (to simulate those other editors where point is not moved to
stay visible while scrolling, so that non-scrolling commands teleport
you right back to where you were).


        Stefan

Re: Proposal to improve the nomenclature of scrolling directions

[Nix]

On 8 Nov 2012, Stefan Monnier spake thusly:

>> (This model is also why I use Eli Barzilay's wonderfully simple
>> scroll-in-place implementation, which I really should contribute to
>> upstream Emacs one of these years: I had Eli's go-ahead nearly two years
>
> Hadn't heard about it.  I just looked at
> https://github.com/elibarzilay/eliemacs/blob/master/include/scroll-in-place.el
> and IIUC all it does is to remember the previous positions during
> a sequence of scroll commands, and to use them when scrolling back.

Yeah. That version's improved a bit over what I'm using -- it's
respecting the old scroll-in-place variable now, so Gnus shouldn't need
changing at all.

Compared to what XEmacs's scroll-in-place has to do (basically a rewrite
of the entire scrolling code, in Lisp, and it still doesn't entirely
work) it is enormously better. 99% of the work is delegated to the
original scrolling code.

I'm honestly not sure how anyone can tolerate Emacs's default scrolling
behaviour -- I've used something like scroll-in-place for my entire life
with Emacs, the default was so hard to handle. I can't imagine that
anyone actually *wants* page-up/page-down sequences to leave you in a
different place from where you were before, but Emacs users are
conservative old sods so it is likely that a lot of users prefer it. So
the default should surely not change.

> It could also be used to let the user go back to where she was before
> scrolling (to simulate those other editors where point is not moved to
> stay visible while scrolling, so that non-scrolling commands teleport
> you right back to where you were).

Ah. That's an interesting variation. Controlled by (setq scroll-in-place
'unmoving) perhaps? (It should probably hide the cursor while it's
conceptually offscreen as well, on terminals where that's possible, by
flipping cursor-type to nil. Alas this would make it vanish from
non-selected windows too, if cursor-in-non-selected-windows is t...)


I'll look into adding 'unmoving support and post the result this
weekend.

I can remove the rebinding hacks and fold it into the core directly, if
you prefer, removing the SIP-orig-scroll-up / SIP-orig-scroll-down hack
and migrating most of the rest into simple.el or scrolling.el or
something like that, so that all that is needed to turn it on is (setq
scroll-preserve-screen-position 'in-place). Or I can just leave it as an
add-on. (That seems less elegant, but is probably best to start with.)


I have a copyright assignment on file, and my employer (Oracle) signed a
disclaimer long ago. I'm not sure about Eli. (Cc:ed.)

-- 
NULL && (void)

Re: Proposal to improve the nomenclature of scrolling directions

[Eli Barzilay]

40 minutes ago, Nix wrote:
> 
> Compared to what XEmacs's scroll-in-place has to do (basically a
> rewrite of the entire scrolling code, in Lisp, and it still doesn't
> entirely work) it is enormously better. 99% of the work is delegated
> to the original scrolling code.

Yeah, that was the main thing I liked about this.

I already emailed Stefan and said that not only is it small since it
leaves the real work where it belongs, having it in the core is going
to make it even smaller since large parts of the code are dealing with
the usual work that is needed when a very basic command changes.  If
it becomes a customization option of the scrolling commands, then none
of that is needed.


> I'm honestly not sure how anyone can tolerate Emacs's default
> scrolling behaviour -- I've used something like scroll-in-place for
> my entire life with Emacs, the default was so hard to handle.

I actually started without it, and I can say that a few short minutes
of using the in-place thing made me wonder how I could ever tolerate
the default...


> I can't imagine that anyone actually *wants* page-up/page-down
> sequences to leave you in a different place from where you were
> before, but Emacs users are conservative old sods so it is likely
> that a lot of users prefer it. So the default should surely not
> change.

:)


> > It could also be used to let the user go back to where she was
> > before scrolling (to simulate those other editors where point is
> > not moved to stay visible while scrolling, so that non-scrolling
> > commands teleport you right back to where you were).
> 
> Ah. That's an interesting variation. Controlled by (setq
> scroll-in-place 'unmoving) perhaps? (It should probably hide the
> cursor while it's conceptually offscreen as well, on terminals where
> that's possible, by flipping cursor-type to nil. Alas this would
> make it vanish from non-selected windows too, if
> cursor-in-non-selected-windows is t...)

(This sounds like something that would be harder to do, since there
are lots of things that relate to the point position which would
break.  Maybe a better way to do that is some specific event loop
while scrolling that aborts before any other key is processed, but
that would make the code different.  But what do I know...)


> I have a copyright assignment on file, and my employer (Oracle)
> signed a disclaimer long ago. I'm not sure about Eli. (Cc:ed.)

I've done it when I was a student in Cornell, I'm not sure that it
still holds.  I obviously don't mind if it's used in any way.

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!

Re: Proposal to improve the nomenclature of scrolling directions

[Nix]

On 8 Nov 2012, Eli Barzilay verbalised:

>> Ah. That's an interesting variation. Controlled by (setq
>> scroll-in-place 'unmoving) perhaps? (It should probably hide the
>> cursor while it's conceptually offscreen as well, on terminals where
>> that's possible, by flipping cursor-type to nil. Alas this would
>> make it vanish from non-selected windows too, if
>> cursor-in-non-selected-windows is t...)
>
> (This sounds like something that would be harder to do, since there
> are lots of things that relate to the point position which would
> break.  Maybe a better way to do that is some specific event loop
> while scrolling that aborts before any other key is processed, but
> that would make the code different.  But what do I know...)

Yes, you have to do it like that. Point is always on-screen: this
assumption is wired into all sorts of places and can never change. But
what we *can* do is make point invisible after a motion command (pure
motion only, not e.g. isearch, which means scroll-*-command only) that
should leave point offscreen, then detect any *other* command (in the
same way that e.g. `repeat' does) and jump back to where we were at the
start of this chain of scroll commands, emptying the SIP-last-scroll
lists and making point visible again.

-- 
NULL && (void)

Re: Proposal to improve the nomenclature of scrolling directions

[Eli Barzilay]

20 minutes ago, Nix wrote:
> 
> Yes, you have to do it like that. Point is always on-screen: this
> assumption is wired into all sorts of places and can never
> change. But what we *can* do is make point invisible after a motion
> command (pure motion only, not e.g. isearch, which means
> scroll-*-command only) that should leave point offscreen, then
> detect any *other* command (in the same way that e.g. `repeat' does)
> and jump back to where we were at the start of this chain of scroll
> commands, emptying the SIP-last-scroll lists and making point
> visible again.

It's just that my experience with installing a pre-command hook to do
something like this turned out to be so much work that having a
specialized event loop was saner.  In any case, I think that this is
not easy, and frankly, with a proper in-place scrolling, I don't see
any need for it beyond some rare occasional use of some command to
remember a place to go back to.

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!

Re: Proposal to improve the nomenclature of scrolling directions

[Stefan Monnier]

> I'm honestly not sure how anyone can tolerate Emacs's default scrolling
> behaviour -- I've used something like scroll-in-place for my entire life

AFAIK scroll-preserve-screen-position already provides most of
that behavior.  I have it set to `always' here, mostly as an experiment
(started years ago and that I had forgotten about).  During this
experiment I've noticed one case where it's annoying:
when you have everything folded and use reveal-mode, it causes scroll
commands to much too often hide the text I'm looking at (because while
it'd still be onscreen, point was moved to some other line that's
outside of the function which as a consequence gets refolded).
So I think a value of t would fit my usage pattern better.

> should leave point offscreen, then detect any *other* command (in the
> same way that e.g. `repeat' does) and jump back to where we were at the

Right, e.g. using something like set-temporary-overlay-map.  Note that
I wouldn't do it for just "any other" command (that's what many other
editors do, but I find it insufferable).  Better provide just one
particular "jump back" binding (C-g sounds like a natural choice for
it).


        Stefan

Re: Proposal to improve the nomenclature of scrolling directions

[martin rudalics]

 > AFAIK scroll-preserve-screen-position already provides most of
 > that behavior.

Just that it doesn't work with different-height faces

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12401

martin

Re: Proposal to improve the nomenclature of scrolling directions

[Stefan Monnier]

>> AFAIK scroll-preserve-screen-position already provides most of
>> that behavior.
> Just that it doesn't work with different-height faces
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12401

I know.  That's what the "most" was referring to.


        Stefan

Re: Proposal to improve the nomenclature of scrolling directions

[Eli Zaretskii]

> From: Nix <nix@esperi.org.uk>
> Emacs: it's all fun and games, until somebody tries to edit a file.
> Date: Thu, 08 Nov 2012 18:18:04 +0000
> Cc: "Stephen J. Turnbull" <stephen@xemacs.org>,
> 	Emacs development discussions <emacs-devel@gnu.org>,
> 	Daniel Hackney <dan@haxney.org>, Stefan Monnier <monnier@iro.umontreal.ca>,
> 	Dani Moncayo <dmoncayo@gmail.com>
> 
> Yes, you have to do it like that. Point is always on-screen: this
> assumption is wired into all sorts of places and can never change.

This is false.  An easy demonstration is this:

  emacs -Q
  C-x 3
  M-<
  M-x set-variable RET auto-hscroll RET nil RET
  C-e

Re: Proposal to improve the nomenclature of scrolling directions

[Juanma Barranquero]

On Thu, Nov 8, 2012 at 7:40 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> This is false.  An easy demonstration is this:
>
>   emacs -Q
>   C-x 3

Surely this isn't what you expected :-)

alloc.c:2864: Emacs fatal error: assertion failed: (tmp) <
VECTOR_MAX_FREE_LIST_INDEX

Breakpoint 1, terminate_due_to_signal (sig=22,
backtrace_limit=2147483647) at emacs.c:318
318       signal (sig, SIG_DFL);
(gdb) bt
#0  terminate_due_to_signal (sig=22, backtrace_limit=2147483647) at emacs.c:318
#1  0x01021b31 in die (msg=0x152b648 "assertion failed: (tmp) <
VECTOR_MAX_FREE_LIST_INDEX", file=0x152ae49 "alloc.c", line=2864) at
alloc.c:6483
#2  0x0101af8e in sweep_vectors () at alloc.c:2864
#3  0x010217db in gc_sweep () at alloc.c:6376
#4  0x0101f176 in Fgarbage_collect () at alloc.c:5321
#5  0x010181b1 in maybe_gc () at lisp.h:3676
#6  0x010e123f in exec_byte_code (bytestr=21053329, vector=21053405,
maxdepth=20, args_template=57415706, nargs=0, args=0x0) at
bytecode.c:934
#7  0x01015e62 in funcall_lambda (fun=21053285, nargs=2,
arg_vector=0x36c181a <__register_frame_info+57415706>) at eval.c:3006
#8  0x010152fb in Ffuncall (nargs=3, args=0x88e374) at eval.c:2823
#9  0x010e1133 in exec_byte_code (bytestr=21053329, vector=21053405,
maxdepth=20, args_template=57415706, nargs=0, args=0x0) at
bytecode.c:899
#10 0x01015e62 in funcall_lambda (fun=21053285, nargs=1,
arg_vector=0x36c181a <__register_frame_info+57415706>) at eval.c:3006
#11 0x010152fb in Ffuncall (nargs=2, args=0x88e674) at eval.c:2823
#12 0x010e1133 in exec_byte_code (bytestr=21053513, vector=21053605,
maxdepth=20, args_template=57415706, nargs=0, args=0x0) at
bytecode.c:899
#13 0x01015e62 in funcall_lambda (fun=21053485, nargs=1,
arg_vector=0x36c181a <__register_frame_info+57415706>) at eval.c:3006
#14 0x0101563c in apply_lambda (fun=21053485, args=61287486) at eval.c:2883
#15 0x01013611 in eval_sub (form=61287494) at eval.c:2184
#16 0x010128e5 in Feval (form=61287494, lexical=57415706) at eval.c:2004
#17 0x010494b6 in eval_dyn (form=61287494) at keyboard.c:7571
#18 0x01010faa in internal_condition_case_1 (bfun=0x104949c
<eval_dyn>, arg=61287494, handlers=57466266, hfun=0x1049429
<menu_item_eval_property_1>)
    at eval.c:1326
#19 0x01049511 in menu_item_eval_property (sexpr=61287494) at keyboard.c:7582
#20 0x0104c021 in parse_tool_bar_item (key=59860114, item=57415706) at
keyboard.c:8135
#21 0x0104bbcf in process_tool_bar_item (key=59860114, def=20128774,
data=57415706, args=0x0) at keyboard.c:8011
#22 0x010c4113 in map_keymap_item (fun=0x104baee
<process_tool_bar_item>, args=57415706, key=59860114, val=20128774,
data=0x0) at keymap.c:559
#23 0x010c46d2 in map_keymap_internal (map=61305510, fun=0x104baee
<process_tool_bar_item>, args=57415706, data=0x0) at keymap.c:599
#24 0x010c4a85 in map_keymap (map=61305510, fun=0x104baee
<process_tool_bar_item>, args=57415706, data=0x0, autoload=true) at
keymap.c:647
#25 0x0104bab2 in tool_bar_items (reuse=61588605, nitems=0x88edb0) at
keyboard.c:7971
#26 0x01200663 in update_tool_bar (f=0x39906d8
<__register_frame_info+60360408>, save_match_data=0) at xdisp.c:11555
#27 0x011ff84b in prepare_menu_bars () at xdisp.c:11245
#28 0x0120530c in redisplay_internal () at xdisp.c:13114
#29 0x012031b3 in redisplay () at xdisp.c:12686
#30 0x0103b682 in read_char (commandflag=1, nmaps=2, maps=0x88f980,
prev_event=57415706, used_mouse_menu=0x88fa53, end_time=0x0) at
keyboard.c:2428
#31 0x0104f295 in read_key_sequence (keybuf=0x88fbd0, bufsize=30,
prompt=57415706, dont_downcase_last=false,
can_return_switch_frame=true,
    fix_current_buffer=true) at keyboard.c:9230
#32 0x010389a4 in command_loop_1 () at keyboard.c:1458
#33 0x01010ec2 in internal_condition_case (bfun=0x10384be
<command_loop_1>, handlers=57466266, hfun=0x1037cdd <cmd_error>) at
eval.c:1288
#34 0x01038137 in command_loop_2 (ignore=57415706) at keyboard.c:1167
#35 0x0101091f in internal_catch (tag=57456122, func=0x1038113
<command_loop_2>, arg=57415706) at eval.c:1059
#36 0x010380f1 in command_loop () at keyboard.c:1146
#37 0x010376ab in recursive_edit_1 () at keyboard.c:778
#38 0x010379d8 in Frecursive_edit () at keyboard.c:842
#39 0x0100298b in main (argc=2, argv=0xa12f30) at emacs.c:1564

Lisp Backtrace:
"Automatic GC" (0x167135c)
"image-search-load-path" (0x88e378)
"image-search-load-path" (0x88e678)
"find-image" (0x88e8d0)
"redisplay_internal (C function)" (0x167135c)
(gdb)

Re: Proposal to improve the nomenclature of scrolling directions

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Thu, 8 Nov 2012 19:48:09 +0100
> Cc: Nix <nix@esperi.org.uk>, dan@haxney.org, eli@barzilay.org, 
> 	emacs-devel@gnu.org, monnier@iro.umontreal.ca, dmoncayo@gmail.com, 
> 	stephen@xemacs.org
> 
> On Thu, Nov 8, 2012 at 7:40 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > This is false.  An easy demonstration is this:
> >
> >   emacs -Q
> >   C-x 3
> 
> Surely this isn't what you expected :-)
> 
> alloc.c:2864: Emacs fatal error: assertion failed: (tmp) <
> VECTOR_MAX_FREE_LIST_INDEX

Actually, I did (see bug #12839), so I did this in an older version,
that is still usable.

Re: Proposal to improve the nomenclature of scrolling directions

[Richard Stallman]

Point is always within the range of text that is displayed in the window.
With hscroll, parts of the lines in the window don't actually appear;
that's why point can be hscrolled off the side.  Nonetheless, it is still
within the range of text that is displayed in the window.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call

Re: Proposal to improve the nomenclature of scrolling directions

[Eli Zaretskii]

> Date: Thu, 08 Nov 2012 21:52:27 -0500
> From: Richard Stallman <rms@gnu.org>
> CC: nix@esperi.org.uk, dan@haxney.org, eli@barzilay.org,
> 	emacs-devel@gnu.org, monnier@iro.umontreal.ca,
> 	dmoncayo@gmail.com, stephen@xemacs.org
> 
> Point is always within the range of text that is displayed in the window.
> With hscroll, parts of the lines in the window don't actually appear;
> that's why point can be hscrolled off the side.  Nonetheless, it is still
> within the range of text that is displayed in the window.

Yes, that is true.  But the point I wanted to make is that nothing in
Emacs really assumes that point must be on the displayed portion of
the buffer.  Rather, the display engine deliberately scrolls text to
make sure point is visible.  So I don't think Emacs will go down in
flames if some feature inhibits this automatic scrolling.  The
auto-hscroll example was a demonstration of how Emacs command still
work in a sensible way when point is not visible.

Re: Proposal to improve the nomenclature of scrolling directions

[Nix]

On 9 Nov 2012, Eli Zaretskii spake thusly:
> Yes, that is true.  But the point I wanted to make is that nothing in
> Emacs really assumes that point must be on the displayed portion of
> the buffer.  Rather, the display engine deliberately scrolls text to
> make sure point is visible.  So I don't think Emacs will go down in
> flames if some feature inhibits this automatic scrolling.  The
> auto-hscroll example was a demonstration of how Emacs command still
> work in a sensible way when point is not visible.

... which is a good sign that a small core change might make it possible
to implement this feature on its own in a few lines, without requiring
all the scroll-in-place machinery. Something else for me to look at :)

-- 
NULL && (void)

Re: Proposal to improve the nomenclature of scrolling directions

[Eli Zaretskii]

> From: Nix <nix@esperi.org.uk>
> Cc: rms@gnu.org, dan@haxney.org, eli@barzilay.org, emacs-devel@gnu.org,
>         monnier@iro.umontreal.ca, dmoncayo@gmail.com, stephen@xemacs.org
> Date: Fri, 09 Nov 2012 14:20:42 +0000
> 
> On 9 Nov 2012, Eli Zaretskii spake thusly:
> > Yes, that is true.  But the point I wanted to make is that nothing in
> > Emacs really assumes that point must be on the displayed portion of
> > the buffer.  Rather, the display engine deliberately scrolls text to
> > make sure point is visible.  So I don't think Emacs will go down in
> > flames if some feature inhibits this automatic scrolling.  The
> > auto-hscroll example was a demonstration of how Emacs command still
> > work in a sensible way when point is not visible.
> 
> ... which is a good sign that a small core change might make it possible
> to implement this feature on its own in a few lines, without requiring
> all the scroll-in-place machinery. Something else for me to look at :)

If you could describe what change are you looking for, and how not
displaying point might help with scroll-in-place like behavior, I
might be able to help.  (Sorry, couldn't read all this longish
thread.)

Re: Proposal to improve the nomenclature of scrolling directions

[Nix]

On 9 Nov 2012, Eli Zaretskii told this:

>> From: Nix <nix@esperi.org.uk>
>> ... which is a good sign that a small core change might make it possible
>> to implement this feature on its own in a few lines, without requiring
>> all the scroll-in-place machinery. Something else for me to look at :)
>
> If you could describe what change are you looking for, and how not
> displaying point might help with scroll-in-place like behavior, I
> might be able to help.  (Sorry, couldn't read all this longish
> thread.)

It's the other way round: the way scroll-in-place.el is currently
implemented, Eli noted that it would be quite easy to make it implement
a 'stationary cursor' like users of other editors might be used to.

-- 
NULL && (void)

Re: Proposal to improve the nomenclature of scrolling directions

[martin rudalics]

 > If you could describe what change are you looking for, and how not
 > displaying point might help with scroll-in-place like behavior, I
 > might be able to help.  (Sorry, couldn't read all this longish
 > thread.)

`scroll-in-place' means for them to keep the cursor at the same position
of the screen regardless of whether there's any text at that position.
In practice, this can be currently implemented only with the help of an
overlay as with Kim's cua-rect.el.  Obviously, if we are able to not
show the cursor (Emacs on Windows currently lacks this capability IIUC)
no overlay is needed.

martin

Re: Proposal to improve the nomenclature of scrolling directions

[Eli Zaretskii]

> Date: Sat, 10 Nov 2012 12:09:35 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: Nix <nix@esperi.org.uk>, dan@haxney.org, eli@barzilay.org, 
>  emacs-devel@gnu.org, monnier@iro.umontreal.ca, dmoncayo@gmail.com, 
>  stephen@xemacs.org
> 
> `scroll-in-place' means for them to keep the cursor at the same position
> of the screen regardless of whether there's any text at that position.
> In practice, this can be currently implemented only with the help of an
> overlay as with Kim's cua-rect.el.

"Currently" meaning with no changes on the C level, I presume?

> Obviously, if we are able to not show the cursor (Emacs on Windows
> currently lacks this capability IIUC) no overlay is needed.

??? Of course, we can hide the cursor on Windows.  Otherwise, how do
we manage not displaying when auto-hscroll-mode is off and point is
outside of the shown text?

Re: Proposal to improve the nomenclature of scrolling directions

[martin rudalics]

 >> `scroll-in-place' means for them to keep the cursor at the same position
 >> of the screen regardless of whether there's any text at that position.
 >> In practice, this can be currently implemented only with the help of an
 >> overlay as with Kim's cua-rect.el.
 >
 > "Currently" meaning with no changes on the C level, I presume?

Exactly.

 >> Obviously, if we are able to not show the cursor (Emacs on Windows
 >> currently lacks this capability IIUC) no overlay is needed.
 >
 > ??? Of course, we can hide the cursor on Windows.  Otherwise, how do
 > we manage not displaying when auto-hscroll-mode is off and point is
 > outside of the shown text?

Fine.  So let's make this available at the Lisp level.

martin, wondering why he still can't hide the mouse cursor on Windows

Re: Proposal to improve the nomenclature of scrolling directions

[Richard Stallman]

      So I don't think Emacs will go down in
    flames if some feature inhibits this automatic scrolling.

There might well be some bugs that are triggered if point
is not inside the displayed window.  However, I don't think
fixing them would be very hard.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call

Re: Proposal to improve the nomenclature of scrolling directions

[Eli Zaretskii]

> Date: Fri, 09 Nov 2012 19:13:54 -0500
> From: Richard Stallman <rms@gnu.org>
> CC: dan@haxney.org, eli@barzilay.org, emacs-devel@gnu.org,
> 	nix@esperi.org.uk, monnier@iro.umontreal.ca,
> 	dmoncayo@gmail.com, stephen@xemacs.org
> 
>       So I don't think Emacs will go down in
>     flames if some feature inhibits this automatic scrolling.
> 
> There might well be some bugs that are triggered if point
> is not inside the displayed window.  However, I don't think
> fixing them would be very hard.

Meanwhile, it turned out that what's requested is something else: when
the user or a Lisp program deliberately scrolls the text, leave point
where it was, instead of moving it to be visible in the new contents
of the window.  This would need changes to window-scrolling code in
window.c, to avoid moving point.

Re: Proposal to improve the nomenclature of scrolling directions

[martin rudalics]

 > Meanwhile, it turned out that what's requested is something else: when
 > the user or a Lisp program deliberately scrolls the text, leave point
 > where it was, instead of moving it to be visible in the new contents
 > of the window.  This would need changes to window-scrolling code in
 > window.c, to avoid moving point.

Not necessarily.  We can always move point lazily, that is, whenever it
is requested.  As long as scrolling proceeds, we can pretend (visually)
that it's somewhere else.

martin

Re: Proposal to improve the nomenclature of scrolling directions

[Eli Zaretskii]

> Date: Sat, 10 Nov 2012 12:09:59 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: rms@gnu.org, dan@haxney.org, eli@barzilay.org, emacs-devel@gnu.org, 
>  nix@esperi.org.uk, monnier@iro.umontreal.ca, dmoncayo@gmail.com, 
>  stephen@xemacs.org
> 
>  > Meanwhile, it turned out that what's requested is something else: when
>  > the user or a Lisp program deliberately scrolls the text, leave point
>  > where it was, instead of moving it to be visible in the new contents
>  > of the window.  This would need changes to window-scrolling code in
>  > window.c, to avoid moving point.
> 
> Not necessarily.  We can always move point lazily, that is, whenever it
> is requested.

That requires changes to window-scrolling functions, since currently
they do move point, and they do it non-lazily.  See
window_scroll_pixel_based, where it calls SET_PT_BOTH etc.

And what does "whenever it is requested" means, anyway, in practical
terms?  Those "other editors" that allow point to stay out of the
window will scroll the display back to show point when some command is
invoked that modifies the buffer text.  Given that the modification
commands don't require moving point, and C-v/M-v won't either (as this
is the main justification for the feature we are discussing), what
will?

> As long as scrolling proceeds, we can pretend (visually) that it's
> somewhere else.

You are describing the kludgey solution (IIUC), whereas I'm suggesting
a non-kludgey one.

Re: Proposal to improve the nomenclature of scrolling directions

[Nix]

On 10 Nov 2012, Eli Zaretskii verbalised:

>> Date: Sat, 10 Nov 2012 12:09:59 +0100
>> From: martin rudalics <rudalics@gmx.at>
>> CC: rms@gnu.org, dan@haxney.org, eli@barzilay.org, emacs-devel@gnu.org, 
>>  nix@esperi.org.uk, monnier@iro.umontreal.ca, dmoncayo@gmail.com, 
>>  stephen@xemacs.org
>> 
>>  > Meanwhile, it turned out that what's requested is something else: when
>>  > the user or a Lisp program deliberately scrolls the text, leave point
>>  > where it was, instead of moving it to be visible in the new contents
>>  > of the window.  This would need changes to window-scrolling code in
>>  > window.c, to avoid moving point.
>> 
>> Not necessarily.  We can always move point lazily, that is, whenever it
>> is requested.
>
> That requires changes to window-scrolling functions, since currently
> they do move point, and they do it non-lazily.  See
> window_scroll_pixel_based, where it calls SET_PT_BOTH etc.

Well, yes. That's the whole reason we started talking about it when we
were talking about scroll-in-place, which wraps the window-scrolling
functions :)

> And what does "whenever it is requested" means, anyway, in practical
> terms?  Those "other editors" that allow point to stay out of the
> window will scroll the display back to show point when some command is
> invoked that modifies the buffer text.

Exactly that.

>                                         Given that the modification
> commands don't require moving point, and C-v/M-v won't either (as this
> is the main justification for the feature we are discussing), what
> will?

Normally, in the Other Editors, PgUp/PgDn do move point: it's things
like scrolling using the scroll bars that does not. I'm not sure this is
so useful in Emacs -- when was the last time you used the scroll bars?
When was the last time you noticed they existed? I could have had this
feature on for the last six months and never triggered it once. :)

-- 
NULL && (void)

Re: Proposal to improve the nomenclature of scrolling directions

[Eli Zaretskii]

> From: Nix <nix@esperi.org.uk>
> Cc: martin rudalics <rudalics@gmx.at>, rms@gnu.org, dan@haxney.org,
>         eli@barzilay.org, emacs-devel@gnu.org, monnier@iro.umontreal.ca,
>         dmoncayo@gmail.com, stephen@xemacs.org
> Emacs: the only text editor known to get indigestion.
> Date: Sat, 10 Nov 2012 11:48:55 +0000
> 
> >                                         Given that the modification
> > commands don't require moving point, and C-v/M-v won't either (as this
> > is the main justification for the feature we are discussing), what
> > will?
> 
> Normally, in the Other Editors, PgUp/PgDn do move point: it's things
> like scrolling using the scroll bars that does not. I'm not sure this is
> so useful in Emacs -- when was the last time you used the scroll bars?
> When was the last time you noticed they existed? I could have had this
> feature on for the last six months and never triggered it once. :)

So my question above still stands.

Re: Proposal to improve the nomenclature of scrolling directions

[Nix]

On 10 Nov 2012, Eli Zaretskii told this:

>> From: Nix <nix@esperi.org.uk>
>> Cc: martin rudalics <rudalics@gmx.at>, rms@gnu.org, dan@haxney.org,
>>         eli@barzilay.org, emacs-devel@gnu.org, monnier@iro.umontreal.ca,
>>         dmoncayo@gmail.com, stephen@xemacs.org
>> Emacs: the only text editor known to get indigestion.
>> Date: Sat, 10 Nov 2012 11:48:55 +0000
>> 
>> >                                         Given that the modification
>> > commands don't require moving point, and C-v/M-v won't either (as this
>> > is the main justification for the feature we are discussing), what
>> > will?
>> 
>> Normally, in the Other Editors, PgUp/PgDn do move point: it's things
>> like scrolling using the scroll bars that does not. I'm not sure this is
>> so useful in Emacs -- when was the last time you used the scroll bars?
>> When was the last time you noticed they existed? I could have had this
>> feature on for the last six months and never triggered it once. :)
>
> So my question above still stands.

Well, yes, I was agreeing with you. I'm not quite sure what the point of
doing this is anymore.

-- 
NULL && (void)

Re: Proposal to improve the nomenclature of scrolling directions

[martin rudalics]

 >> Not necessarily.  We can always move point lazily, that is, whenever it
 >> is requested.
 >
 > That requires changes to window-scrolling functions, since currently
 > they do move point, and they do it non-lazily.  See
 > window_scroll_pixel_based, where it calls SET_PT_BOTH etc.

I meant to move `point' lazily _after_ we're done with scrolling.  If
the emulation is on and the command is not a scrolling command
recognized by the emulation, move `point' to where it was before
scrolling.  That's what I do in `scroll-restore-mode' (if wanted).

 > And what does "whenever it is requested" means, anyway, in practical
 > terms?

Whenever the current command is not a scroll command.  In
`scroll-restore-mode' I do that in a pre-command hook.

 > Those "other editors" that allow point to stay out of the
 > window will scroll the display back to show point when some command is
 > invoked that modifies the buffer text.

Where would we have `forward-char' start moving when emulating such
"other editors"?

 > Given that the modification
 > commands don't require moving point, and C-v/M-v won't either (as this
 > is the main justification for the feature we are discussing), what
 > will?

The modification commands can require moving point, if desired.  But
while it might be useful to emulate other editors in this regard, the
main deficiencies we should concentrate on are:

- When scrolling for-/backward, a window's point should appear where it
   was before we started scrolling.  Currently, it doesn't when using
   different faces and maybe in some other cases as well.

- Avoid the silly way the region is disfigured when it was scrolled
   off-screen.

 >> As long as scrolling proceeds, we can pretend (visually) that it's
 >> somewhere else.
 >
 > You are describing the kludgey solution (IIUC), whereas I'm suggesting
 > a non-kludgey one.

Every solution here will be kludgey.  Suppose you scroll a non-selected
window and subsequently insert text into its buffer.  Would you insert
it at its old `window-point' even if its `point' is somewhere else?

A basic invariant of Emacs is that at top-level any buffer's `point'
coincides with `window-point' of the selected window, provided the
buffer appears there.  Violating this invariant means we have to rethink
lots of code, including things as fragile as the window configuration
code.

martin

Re: Proposal to improve the nomenclature of scrolling directions

[Eli Zaretskii]

> Date: Sat, 10 Nov 2012 15:10:57 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: dan@haxney.org, rms@gnu.org, eli@barzilay.org, emacs-devel@gnu.org, 
>  nix@esperi.org.uk, monnier@iro.umontreal.ca, dmoncayo@gmail.com, 
>  stephen@xemacs.org
> 
>  >> Not necessarily.  We can always move point lazily, that is, whenever it
>  >> is requested.
>  >
>  > That requires changes to window-scrolling functions, since currently
>  > they do move point, and they do it non-lazily.  See
>  > window_scroll_pixel_based, where it calls SET_PT_BOTH etc.
> 
> I meant to move `point' lazily _after_ we're done with scrolling.

Do you mean moving the real point or its emulation?  If the former, it
is currently done as part of window_scroll_pixel_based, and that part
will need to be changed if you want point to stay put disregarding the
scrolling commands.

> If the emulation is on and the command is not a scrolling command
> recognized by the emulation, move `point' to where it was before
> scrolling.  That's what I do in `scroll-restore-mode' (if wanted).

You do that in scroll-restore-mode because the C code moves point.
But if C code won't move point in these situations, then there will be
no reason to move point back, because it will stay put.

>  > And what does "whenever it is requested" means, anyway, in practical
>  > terms?
> 
> Whenever the current command is not a scroll command.  In
> `scroll-restore-mode' I do that in a pre-command hook.
> 
>  > Those "other editors" that allow point to stay out of the
>  > window will scroll the display back to show point when some command is
>  > invoked that modifies the buffer text.
> 
> Where would we have `forward-char' start moving when emulating such
> "other editors"?

At the original point position, i.e. forward-char will return there
and cause point be displayed after the move.

>  > Given that the modification
>  > commands don't require moving point, and C-v/M-v won't either (as this
>  > is the main justification for the feature we are discussing), what
>  > will?
> 
> The modification commands can require moving point, if desired.

Doesn't make sense, IMO: it defeats the reason for not moving point on
scroll in the first place.

I think the only commands that should move point in this mode are
those which, well, move point.  That is, goto-char, C-f/C-b, mouse-1
click, etc.  And these should cause display to scroll so that point
comes into view.

>  > You are describing the kludgey solution (IIUC), whereas I'm suggesting
>  > a non-kludgey one.
> 
> Every solution here will be kludgey.  Suppose you scroll a non-selected
> window and subsequently insert text into its buffer.  Would you insert
> it at its old `window-point' even if its `point' is somewhere else?

Why at window-point?  At point, of course.  Isn't this how things work
now?

> A basic invariant of Emacs is that at top-level any buffer's `point'
> coincides with `window-point' of the selected window, provided the
> buffer appears there.  Violating this invariant means we have to rethink
> lots of code, including things as fragile as the window configuration
> code.

I don't think anything I said violates this.  What am I missing?

Re: Proposal to improve the nomenclature of scrolling directions

[martin rudalics]

 >> I meant to move `point' lazily _after_ we're done with scrolling.
 >
 > Do you mean moving the real point or its emulation?

When I start scrolling, I save the original position of `window-point'.
`window-point' and move `point' as usual.  When I now want to
interactively insert text into the buffer, I move `point' to the saved
original position before.

 > If the former, it
 > is currently done as part of window_scroll_pixel_based, and that part
 > will need to be changed if you want point to stay put disregarding the
 > scrolling commands.

`point' moves as before.  But we don't show it any more when it's moved.

 >> If the emulation is on and the command is not a scrolling command
 >> recognized by the emulation, move `point' to where it was before
 >> scrolling.  That's what I do in `scroll-restore-mode' (if wanted).
 >
 > You do that in scroll-restore-mode because the C code moves point.
 > But if C code won't move point in these situations, then there will be
 > no reason to move point back, because it will stay put.

Yes.  And the region would be handled automatically as well.

 >> Where would we have `forward-char' start moving when emulating such
 >> "other editors"?
 >
 > At the original point position, i.e. forward-char will return there
 > and cause point be displayed after the move.

My question was addressing your earlier statement:

 > Those "other editors" that allow point to stay out of the
 > window will scroll the display back to show point when some command is
 > invoked that modifies the buffer text.

So we do not only "scroll back" when we modify text but also when we use
commands like `forward-char' and probably in many more cases.

 >>  > Given that the modification
 >>  > commands don't require moving point, and C-v/M-v won't either (as this
 >>  > is the main justification for the feature we are discussing), what
 >>  > will?
 >>
 >> The modification commands can require moving point, if desired.
 >
 > Doesn't make sense, IMO: it defeats the reason for not moving point on
 > scroll in the first place.

The primary concerns of `scroll-restore-mode' are to preseve `point'
when scrolling back to where it was and to restore the region when
scrolling back to where `point' was.  Jumping back on anything but a
scroll command is just an option.  So I principally allow to move
`point' on scroll.

 > I think the only commands that should move point in this mode are
 > those which, well, move point.  That is, goto-char, C-f/C-b, mouse-1
 > click, etc.  And these should cause display to scroll so that point
 > comes into view.

How would commands calling `set-window-start' or `recenter' be
classified in this regard?

 >> A basic invariant of Emacs is that at top-level any buffer's `point'
 >> coincides with `window-point' of the selected window, provided the
 >> buffer appears there.  Violating this invariant means we have to rethink
 >> lots of code, including things as fragile as the window configuration
 >> code.
 >
 > I don't think anything I said violates this.  What am I missing?

Ok.  Then `window-start' <= `window-point' <= `window-end' is no more an
invariant?

martin

Re: Proposal to improve the nomenclature of scrolling directions

[Eli Zaretskii]

> Date: Sat, 10 Nov 2012 19:50:06 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: dan@haxney.org, rms@gnu.org, eli@barzilay.org, emacs-devel@gnu.org, 
>  nix@esperi.org.uk, monnier@iro.umontreal.ca, dmoncayo@gmail.com, 
>  stephen@xemacs.org
> 
>  > I think the only commands that should move point in this mode are
>  > those which, well, move point.  That is, goto-char, C-f/C-b, mouse-1
>  > click, etc.  And these should cause display to scroll so that point
>  > comes into view.
> 
> How would commands calling `set-window-start' or `recenter' be
> classified in this regard?

The former won't move point, I guess.  The latter will.

>  >> A basic invariant of Emacs is that at top-level any buffer's `point'
>  >> coincides with `window-point' of the selected window, provided the
>  >> buffer appears there.  Violating this invariant means we have to rethink
>  >> lots of code, including things as fragile as the window configuration
>  >> code.
>  >
>  > I don't think anything I said violates this.  What am I missing?
> 
> Ok.  Then `window-start' <= `window-point' <= `window-end' is no more an
> invariant?

I think so.

Re: Proposal to improve the nomenclature of scrolling directions

[martin rudalics]

 > There might well be some bugs that are triggered if point
 > is not inside the displayed window.

The _selected_ window.  When a window is not selected, its buffer's
`point' not necessarily appears in it.

martin

Re: Proposal to improve the nomenclature of scrolling directions

[Eli Zaretskii]

> Date: Sat, 10 Nov 2012 12:10:50 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: Eli Zaretskii <eliz@gnu.org>, dan@haxney.org, eli@barzilay.org, 
>  emacs-devel@gnu.org, nix@esperi.org.uk, monnier@iro.umontreal.ca, 
>  dmoncayo@gmail.com, stephen@xemacs.org
> 
>  > There might well be some bugs that are triggered if point
>  > is not inside the displayed window.
> 
> The _selected_ window.  When a window is not selected, its buffer's
> `point' not necessarily appears in it.

Could easily be false, if redisplay decides to redisplay more than a
single window.  E.g., when the window's dimensions are changed.

Re: Proposal to improve the nomenclature of scrolling directions

[martin rudalics]

 >>  > There might well be some bugs that are triggered if point
 >>  > is not inside the displayed window.
 >>
 >> The _selected_ window.  When a window is not selected, its buffer's
 >> `point' not necessarily appears in it.
 >
 > Could easily be false,

How can a phrase like that be false?

 > if redisplay decides to redisplay more than a
 > single window.  E.g., when the window's dimensions are changed.

In this case the old `window-point' should be preserved.  Everything
else would constitute a bug.  Anyway, what I wanted to say is that we
already know how to deal with the case when a buffer's `point' is not
displayed in a window showing that buffer.

martin

Re: Proposal to improve the nomenclature of scrolling directions

[martin rudalics]

 >> It could also be used to let the user go back to where she was before
 >> scrolling (to simulate those other editors where point is not moved to
 >> stay visible while scrolling, so that non-scrolling commands teleport
 >> you right back to where you were).
 >
 > Ah. That's an interesting variation. Controlled by (setq scroll-in-place
 > 'unmoving) perhaps? (It should probably hide the cursor while it's
 > conceptually offscreen as well, on terminals where that's possible, by
 > flipping cursor-type to nil. Alas this would make it vanish from
 > non-selected windows too, if cursor-in-non-selected-windows is t...)

`scroll-restore-mode' addresses most of these

http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg01892.html

and also tries to handle the region during scrolling.

martin

Re: Proposal to improve the nomenclature of scrolling directions

[Stefan Monnier]

> `scroll-restore-mode' addresses most of these
> http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg01892.html
> and also tries to handle the region during scrolling.

I didn't remember this one.  What are you waiting for to put it on
GNU ELPA?


        Stefan

Re: Proposal to improve the nomenclature of scrolling directions

[martin rudalics]

 >> `scroll-restore-mode' addresses most of these
 >> http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg01892.html
 >> and also tries to handle the region during scrolling.
 >
 > I didn't remember this one.  What are you waiting for to put it on
 > GNU ELPA?

Pre- and post-display hooks.  I dislike using pre- and post-command
hooks for this.

martin

Re: Proposal to improve the nomenclature of scrolling directions

[Stephen J. Turnbull]

Nix writes:

 > FWIW the object I have always imagined is scrolling down is 'the user's
 > viewport'.

You have imagination in places I don't even have places! :-)  (In my
mental model there's nothing in a hole that you can scroll.)

 > So 'scroll down' and 'scroll the text up' are synonymous, but the
 > latter is almost never used, since everyone's mental model these
 > days is of unchanging text and a freely moving viewport over the
 > top of it.

And that's why it's so intuitive that Google Maps gives you a hand to
grab the map with, and the map moves in the direction the hand goes?
That's why I get vertigo when I drag the scrollbar thumb down and the
text scrolls up?

While I don't dispute that your model is what describe, and don't
really have any ground to claim it's a minority view, I believe that
"everybody's mental model" is rather more nuanced.  Not to mention
"plural". :-)

Re: Proposal to improve the nomenclature of scrolling directions

[Stephen Leake]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> And that's why it's so intuitive that Google Maps gives you a hand to
> grab the map with, and the map moves in the direction the hand goes?

Yes; you grabbed the map, not the viewport.

> That's why I get vertigo when I drag the scrollbar thumb down and the
> text scrolls up?

The scrollbar thumb controls the viewport, not the contents (the map, in
this case).

Once you get used to thinking about things in terms of _either_ viewport
or content, scrolling makes sense.

Apple recently changed the direction;
http://www.pcworld.com/article/236182/osx_lion_scrolling.html

I'm not clear whether Emacs matched Apple before or after the change;
the article talks about "finger motion", not "mouse motion".

> While I don't dispute that your model is what describe, and don't
> really have any ground to claim it's a minority view, I believe that
> "everybody's mental model" is rather more nuanced.  Not to mention
> "plural". :-)

+1

Which means there's not much point in changing Emacs functionality,
although adding the concept of "viewport" to the documentation would be
a good idea.

-- 
-- Stephe

RE: Proposal to improve the nomenclature of scrolling directions

[Drew Adams]

> Once you get used to thinking about things in terms of 
> _either_ viewport or content, scrolling makes sense.
> 
> Apple recently changed the direction;
> http://www.pcworld.com/article/236182/osx_lion_scrolling.html
> 
> I'm not clear whether Emacs matched Apple before or after the change;
> the article talks about "finger motion", not "mouse motion".
> 
> > While I don't dispute that your model is what describe, and don't
> > really have any ground to claim it's a minority view, I believe that
> > "everybody's mental model" is rather more nuanced.  Not to mention
> > "plural". :-)
> 
> +1
> 
> Which means there's not much point in changing Emacs functionality,
> although adding the concept of "viewport" to the documentation
> would be a good idea.

The direction of scrolling and its Emacs jargon gets nominated here periodically
as some people's favorite way in which Emacs is old-fashioned & naughty and
needs to be sent back for regrooving, to be put in step with The One Exo-Emacs
Way (TOEEW).

That such a non-issue rises to the top here occasionally suggests how little
Emacs must really need to be regrooved.  This is one of the silliest ways we
could possibly want to spin our wheels looking for improvements.

As Stephen L. suggests, it just doesn't matter, in terms of use, as long as the
behavior is consistent.

Sure, it can matter a teeny tiny bit for someone who is coding Emacs Lisp and
needs to call scrolling functions.  But it's trivial to check which direction is
which.  Users are rarely even aware of the scrolling-command names.  And if made
aware I doubt they would really care what you call them.

There have been lots of approaches to scrolling in the history of UIs, and there
still are multiple approaches in specialized UI areas (e.g. CAD/CAM).  There has
never been a real problem for users to understand or adapt, even when they have
had to switch among multiple kinds of scroll bars etc.

The Emacs-needs-to-fit-The-One-Way-now crowd is the fruit of a period when, yes,
there is less variety and experimentation when it comes to such basic UI
constructs.  It does not follow that Emacs needs to TOEEW the line.  This is a
non-issue.

Trying to cram the splendid sculpture that is Emacs into a perceived TOEEW
pinhole is about as misguided as it gets.  Just let it be.  Circulez ; il n'y a
rien a voir.

Re: Proposal to improve the nomenclature of scrolling directions

[Nix]

On 8 Nov 2012, Drew Adams said:
> That such a non-issue rises to the top here occasionally suggests how little
> Emacs must really need to be regrooved.  This is one of the silliest ways we
> could possibly want to spin our wheels looking for improvements.

Quite. It's really not important. It confuses me once every three or
four years: how terrible!

(The last time was last year, when I was doing a little souping up of
scroll-in-place. Hence my mention of it, which might with luck be a good
thing to come out of this latest mostly useless nomenclature-pedantry
thread. :) )

-- 
NULL && (void)