[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: scroll-restore.el
From: |
martin rudalics |
Subject: |
Re: scroll-restore.el |
Date: |
Fri, 22 Feb 2008 20:26:39 +0100 |
User-agent: |
Mozilla Thunderbird 1.0 (Windows/20041206) |
> I think this is trying to implement too many different features, and
> we don't want them all. I would rather implement just the feature of
> restoring point after you scroll back to the previous screen, in a
> simple way.
It's the only feature I use in practice. But I never scroll a window
when the region is highlighted. Scrolling with a highlighted region is
a real pain when `point' gets relocated to stay on screen.
> In general, it is best to avoid `pre-command-hook' whenever a finer
> tool can be used, and likewise `post-command-hook'.
Goes without saying. Last summer someone on bug-gnu-emacs lamented the
absence of such a feature. I just wanted to know whether I liked it and
use it ever since.
> ;; Note: We can't use `point-before-scroll' for our purposes because
> ;; that variable is buffer-local.
>
> WHY isn't `point-before-scroll' enough?
The variable must be window-local to handle the case of independently
scrolling two or more windows showing the same buffer (setting
`mouse-wheel-follow-mouse' to t makes that possible).
> Would it be enough just for the feature of restoring point?
>
> We need a variable that recorded
> ;; `window-point' before a sequence of scroll operations. Also
> ;; `point-before-scroll' is not handled by mwheel.el and some other
> ;; commands that do implicit scrolling.
>
> I presume we can fix `point-before-scroll' to DTRT in those cases. In
> general, if a primitive feature isn't suitable for the job it is meant for,
> let's make it suitable, rather than do the job in a heavy-handed way.
I'll have to look into how `point-before-scroll' is currently used by
the scroll-bar / mouse code and whether it can (or should) be safely
made window-local.
> If we want a few commands to do a certain thing, then it is a bad idea
> to use `post-command-hook' to check for them. Instead we should
> change those commands to do it, whatever IT is. We can add a new
> specific hook, and run it from commands and features that scroll.
>
> People often choose `post-command-hook' rather than change C code.
> But when we design changes to install in Emacs, we should not design
> them based on the premise of "avoid changing the C code."
Fully agreed.
- Re: Enabling Transient Mark Mode by default, (continued)
- Re: Enabling Transient Mark Mode by default, Evans Winner, 2008/02/20
- Re: Enabling Transient Mark Mode by default, Jason Earl, 2008/02/20
- Re: Enabling Transient Mark Mode by default, David Kastrup, 2008/02/20
- Re: Enabling Transient Mark Mode by default, David De La Harpe Golden, 2008/02/20
- Re: Enabling Transient Mark Mode by default, martin rudalics, 2008/02/21
- scroll-restore.el, Richard Stallman, 2008/02/21
- Re: scroll-restore.el, David De La Harpe Golden, 2008/02/22
- Re: scroll-restore.el, martin rudalics, 2008/02/22
- Re: scroll-restore.el, David De La Harpe Golden, 2008/02/22
- Re: scroll-restore.el, martin rudalics, 2008/02/22
- Re: scroll-restore.el,
martin rudalics <=
- Re: Enabling Transient Mark Mode by default, Jason Earl, 2008/02/20
- Re: Enabling Transient Mark Mode by default, David Kastrup, 2008/02/20
- Re: Enabling Transient Mark Mode by default, Jason Earl, 2008/02/20
- Re: Enabling Transient Mark Mode by default, David Kastrup, 2008/02/21
- Re: Enabling Transient Mark Mode by default, Stefan Monnier, 2008/02/21
- Re: Enabling Transient Mark Mode by default, David Kastrup, 2008/02/21
- Re: Enabling Transient Mark Mode by default, Stefan Monnier, 2008/02/21
- Re: Enabling Transient Mark Mode by default, David Kastrup, 2008/02/21
- Re: Enabling Transient Mark Mode by default, Stefan Monnier, 2008/02/21
- Re: Enabling Transient Mark Mode by default, David De La Harpe Golden, 2008/02/21