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.