bug-gnu-emacs
[Top][All Lists]
Advanced

[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)

Attachment: wsf.diff
Description: application/diff


reply via email to

[Prev in Thread] Current Thread [Next in Thread]