splitting a window at point

splitting a window at point

[James K. Lowden]

It seems like an obvious function: I'd like to split a window
vertically, such that the top of the lower window is positioned where
the cursor is.  If I'm on line 6, the top window will have 6 lines, and
the bottom window gets the rest.  I (would) do this from time to time,
to leave a function definition in the top window while in the lower
window I operate on the code that uses it.  

split-window-vertically takes an optional argument for the top (or
bottom) window size.  So far, so good.  C-u C-x 2 does indeed open the
top window with 4 lines.  

How, then, to compute the cursor's window position?

move-to-window-line moves to the line, but there's no get-window-line.

what-cursor-position reports the buffer position, not the window
location.  I could compute the cursor's window position from it if I
knew the window's buffer position, but apropos returns no function
for "window" that mentions buffer position in its description.  

Do I "just" save the curent cursor position, jump to window line 1, get
its buffer position, jump back, and take the difference?  I guess that
will work, but I'd rather not move the cursor just to compute its
location.  

What am I overlooking?  

--jkl

splitting a window at point

[martin rudalics]

 > How, then, to compute the cursor's window position?

Have a look at the specification of 'mouse-split-window-vertically'.
It should provide everything you need in this regard.

martin

Re: splitting a window at point

[Tomas Nordin]

"James K. Lowden" <jklowden@speakeasy.net> writes:

> It seems like an obvious function: I'd like to split a window
> vertically, such that the top of the lower window is positioned where
> the cursor is.  If I'm on line 6, the top window will have 6 lines, and
> the bottom window gets the rest.  I (would) do this from time to time,
> to leave a function definition in the top window while in the lower
> window I operate on the code that uses it.  

Freely interpreting the goal and not refraining from jumping around with
point a bit, does the following do approximately what you want?

(defun tn-split-window-defun ()
  "Split window at point leaving beginning of defun visible in upper window."
  (interactive)
  (let ((start-pos (point))
        (start-line (line-number-at-pos))
        defun-lines)
    (beginning-of-defun)
    (setq defun-lines (1+ (- start-line (line-number-at-pos))))
    (split-window-below defun-lines)
    (window-resize nil (- defun-lines (window-body-height)))
    (recenter 0)
    (other-window 1)
    (goto-char start-pos)
    (recenter 0)))

--
Tomas

Re: splitting a window at point

[James K. Lowden]

On Thu, 19 Apr 2018 20:13:01 +0200
Tomas Nordin <tomasn@posteo.net> wrote:

> Freely interpreting the goal and not refraining from jumping around
> with point a bit, does the following do approximately what you want?

Why, yes, Tomas, it does, and rather better than I had in mind.  It
complains if the function is "too big to fit" (It says the window is
too small), but otherwise it very much does what I want.  

I'm going to add it to my .emacs with your name on it, and give it
closer study when the mood arises.  Thanks again!  

Regards, 

--jkl

Re: splitting a window at point

[Tomas Nordin]

"James K. Lowden" <jklowden@speakeasy.net> writes:

> On Thu, 19 Apr 2018 20:13:01 +0200
> Tomas Nordin <tomasn@posteo.net> wrote:
>
>> Freely interpreting the goal and not refraining from jumping around
>> with point a bit, does the following do approximately what you want?
>
> Why, yes, Tomas, it does, and rather better than I had in mind.  It
> complains if the function is "too big to fit" (It says the window is
> too small), but otherwise it very much does what I want.  

Cool that it worked as you wanted sort of. I can see that if calling
split-window-below with a SIZE argument with a number of lines that
require more window than it can fit, it errors. But that is kind of
natural I think.