1

I'm using this test code.

(defun +outline~show-all (orig-fn &rest args)
  "Show all."
  (let ((beg1 (window-start))
        (end1 (window-end))
        (beg2) (end2))
    (apply orig-fn args)
    (setq beg2 (window-start) end2 (window-end))
    (message "before (%d , %d) | after (%d , %d)" beg1 end1 beg2 end2)))

(advice-add #'outline-show-all :around #'outline~show-all)

I expect difference between (window-start) and (window-end) to be smaller after calling outline-show-all in a (sufficiently large) org file with folded headings. This is because the window can't show as much of the text now that the contents of org headings are visible. But the window beginning and end before calling outline-show-all and after are the same according to the output of my advice.

Here's an example of the output in a huge orgfile.

before (1 , 246850) | after (1 , 246850)

It is visibly obvious that the window beginning and end have changed. But to make sure I use eval-expression and indeed (window-end) is smaller. I evaluated this form: (message "wndow-beg: %d | window-end: %d" (window-start) (window-end)).

I get this output.

window-beg: 1 | window-end: 884

But why didn't I get this output from my advice?

Drew
  • 77,472
  • 10
  • 114
  • 243
Aquaactress
  • 1,453
  • 8
  • 11
  • Unfortunately, there is no way to get the window-start/end with 100% accuracy because that is calculated towards the end of redisplay. There is UPDATE optional argument for window-end, which can help a little. Greater accuracy can be achieved by attaching a function to the window-scroll-functions hook. For several months, I used a combination of the post-command-hook and window-scroll-functions hook to get window-start/end in the majority of situations, but not all of them. Another idea is to force redisplay and then get the values of window start/end after redisplay, but flickers – lawlist Sep 03 '19 at 21:06
  • Here is a link to the thread where I tried to deal with the inability to get window-start/end with 100% accuracy: https://emacs.stackexchange.com/questions/10763/how-to-update-window-start-without-calling-redisplay Over the course of several months and feature requests / bug reports to the Emacs team, I gained some insight and the link may contain reference to some of those bug trackers .... In the end, I had to learn some C and I implemented my own feature request into the display engine of Emacs ... a 3+ year process, but at least I have a working draft for my own features I use daily. – lawlist Sep 03 '19 at 21:10
  • Thank you for explaining that to me. I was super confused. In my case I only would need to call redisplay once. – Aquaactress Sep 04 '19 at 02:56
  • I'm trying to use it to help with this question I asked before: https://emacs.stackexchange.com/questions/52324/prevent-org-source-block-face-from-bleeding-out-in-fold/52377?noredirect=1#comment80900_52377. I admire you for your persistence. I'm starting to think that's what it's going to take to get Emacs working the way I want. Also if you post your first comment I would accept it as an answer. redisplay did work for my purposes. But definitely mention (as you did in the comment) it's not foolproof by any means. – Aquaactress Sep 04 '19 at 03:04
  • Eli, Ergus and Martin continue to discuss prospective modifications to the display engine to control which face attributes get extended to the end of the display line ... there may be a built-in solution to your bleeding face background issue within the near future. The question in this thread is relatively recent and other forum participants may wish to give a shot at something that uses some of the methods described in comments above. Forcing a redisplay will cause a visual flickering if adding/removing overlays, and the user will see a before versus after view for just a split second.. – lawlist Sep 04 '19 at 03:17
  • Hmm... I tested my use a few more times but I did not see any noticable flickering. Specifically, I used it only once in an after advice to outline-show-all. – Aquaactress Sep 04 '19 at 03:37

0 Answers0