[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#22404: 25.1.50; Forcing `window-scroll-functions` to run.
From: |
Keith David Bershatsky |
Subject: |
bug#22404: 25.1.50; Forcing `window-scroll-functions` to run. |
Date: |
Sun, 31 Jan 2016 19:50:05 -0800 |
I see that there are a few express circumstances in the function `window-end`
where a forced update will not occur, even though a user expressly requested it
with the optional argument being set to `t`. Michael had mentioned an
unspecified situation where `window-end` was incorrect from the
`window-scroll-functions` hook even with a forced update, so perhaps one or
more of those expressly coded exceptions is/are to blame. I encountered a
similar situation today in my testing with interactively calling
`previous-line` at the top window edge (and scroll-conservatively 101) where
the `window-end` was not updating correctly.
Attached is a diff-patch of the second draft for the new proposed animal that
is somewhat similar to the `window-scroll-functions` hook, but this new animal
is able to run every command loop even when there is no scrolling. It
automatically updates `window-end`, and it throws four (4) values that can be
used by the user's custom function attached to the new hook:
* window-start
* window-end
* point at the beginning of the line of window-start.
* point at the end of the line of window-end.
I added two new symbols for the mode-line: little `%w` for `window-start` and
big `%W` for `window-end`. This made debugging much easier, and I do a lot
with window-start/end, so it comes in handy for writing other related functions.
I removed one double quote in comments in `window.c` that was breaking my
font-lock highlighting -- an unmatched double quotes in a comment always causes
havoc with my highlighting for the remainder of the buffer, so I try to fix
those whenever I come across them.
I still haven't figured out how to entirely substitute throwing the switch
`w->wsf_toggle = true` with just a buffer-local variable. Ideally, I would
prefer that the new hook run whenever local variable `wsf-var` is `t` --
without needing a switch. At the present time, I am throwing the switch each
command loop with the `post-command-hook`. [The switch gets set back to
`false` during redisplay, and is needed as sort of a counter so that a section
of the redisplay code does not run more than necessary.]
This draft diff-patch can of course still use some polishing up -- e.g., the
forced window update only needs to occur when `wsf-var` is `t`. In future
drafts, I'll probably change some of the names to further distinguish this from
the built-in WSF. [The built-in WSF section near a patched comment labeled "2
of 3" should probably now have an exception so that it doesn't run merely
because this new animal is running, and I'll think some more about that in the
coming days.] I'll be using this patch in my daily routine to see how it works
out. Here is the sample usage, which is designed to be buffer-local:
(setq scroll-conservatively 101)
(setq wsf-var t)
(defun hr-pch-fn ()
(force-wsf (selected-window)))
(defun hr-wsf-fn (win start end pbol-start peol-end)
(message "win: %s | start: %s | end: %s | peol-start: %s | peol-end: %s"
win start end pbol-start peol-end))
(add-hook 'post-command-hook 'hr-pch-fn t t)
(add-hook 'wsf-hook 'hr-wsf-fn nil t)
wsf.diff
Description: application/diff
- bug#22404: 25.1.50; Forcing `window-scroll-functions` to run., (continued)
bug#22404: 25.1.50; Forcing `window-scroll-functions` to run., Keith David Bershatsky, 2016/01/21
bug#22404: 25.1.50; Forcing `window-scroll-functions` to run., Keith David Bershatsky, 2016/01/28
bug#22404: 25.1.50; Forcing `window-scroll-functions` to run., Keith David Bershatsky, 2016/01/29
bug#22404: 25.1.50; Forcing `window-scroll-functions` to run.,
Keith David Bershatsky <=