From: Tim X <timx@nospam.dev.null>
To: help-gnu-emacs@gnu.org
Subject: Re: (save-excursion (other-window 1)) leaves me in the other window
Date: Mon, 08 Mar 2010 18:26:22 +1100 [thread overview]
Message-ID: <87mxyjs28x.fsf@rapttech.com.au> (raw)
In-Reply-To: m2eijvldb5.fsf@gmail.com
Sean McAfee <eefacm@gmail.com> writes:
> Tim X <timx@nospam.dev.null> writes:
>
>> Sean McAfee <eefacm@gmail.com> writes:
>>> A native reimplementation of scroll-other-window doesn't work as I'd
>>> expect:
>>>
>>> (save-excursion
>>> (other-window 1)
>>> (scroll-up))
>>>
>>> The problem is that the current window isn't restored, which surprised
>>> me considerably. Why doesn't this work, and how would I write a
>>> function to go do some stuff in the other window and then come back?
>>
>> As emacs already has the command to scroll the other window, I'm
>> assuming your example is a simplification of what you really want to do.
>
> True. The situation is this:
>
> I have a frame, split horizontally into two windows. One window shows
> text that came from an OCR process; the other window, in image-mode,
> shows the (large) image that was the input to that OCR process. What I
> want to do is work in the text window, shifting the image in the other
> window around as I check it against the text. I assumed I could do
> something like this:
>
> (defmacro in-other-window (&rest body)
> `(save-excursion (other-window 1) ,@body))
>
> And then:
>
> (global-set-key [(shift down)]
> (lambda () (interactive) (in-other-window (image-next-line))))
>
> ...and similarly for the other three directions.
>
> Although the documentation for save-excursion says that it saves and
> restores the current buffer, it doesn't in this case. I still don't
> really know why. I tried using save-window-excursion instead as Joe
> Fineman suggested, but while that worked for image-next-line and
> image-previous-line, it doesn't for image-forward-hscroll, which I need
> for scrolling horizontally. I guess the horizontal scroll amount is
> something that's saved and restored by save-window-excursion. So I
> finally settled on this:
Note that the docs as you noted say that they restore the buffer, not
the window. This was part of the point I was tyring to make. Buffers and
windows are not the same thing.
For example, you might use save-excursion in a command that needs to
jump to another point in the buffer, perform some calculation, maybe put
the results in a temp buffer or variable and then return to where things
were at before the command executed. Essentially, your saving state of
the buffer (not the window!) going off and doing something else and then
once done, returning to where you were. In many cases, the user won't
even realise this has occured.
If on the other hand, you wanted to do something like display another
window with some data, maybe a status message and then after the user
hits a particular key, restore the window as it was, then
save-window-excursion is probably what you want.
In your current situation, you want to switch to the window displaying
the buffer with the image in it, scroll it up/down or left/right and
then return to where you were in the text buffer? I think you could
either just use an unwind-protect or a save-excursion, but I'm a little
confused regarding what the issue is with restoration.
Strongly suggest you have a look at the sources to simple.el as it
contains some examples of convenience commands related to scrolling.
I also did an apropos-command with the search term 'scroll' and found
the following which you might find useful -
image-backward-hscroll M-x ... RET
Scroll image in current window to the right by N character widths.
image-forward-hscroll M-x ... RET
Scroll image in current window to the left by N character widths.
image-scroll-down M-x ... RET
Scroll image in current window downward by N lines.
image-scroll-up M-x ... RET
Scroll image in current window upward by N lines.
It would be fairly trivial to write two commands that would scroll the
image up/down or left/right. It could take a prefix argument to
determine the distance with positive arguments meaning donw/right and
negative meaning up/left etc.
I don't see there is any need to make it a macro unless you want to be
able to execute arbitrarily complex forms. Maybe just write functions
and later do a macro if justified.
Tim
--
tcross (at) rapttech dot com dot au
next prev parent reply other threads:[~2010-03-08 7:26 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-05 20:33 (save-excursion (other-window 1)) leaves me in the other window Sean McAfee
2010-03-05 22:21 ` Joe Fineman
2010-03-07 6:55 ` Tim X
2010-03-08 3:09 ` Sean McAfee
2010-03-08 7:26 ` Tim X [this message]
2010-03-08 16:55 ` Sean McAfee
2010-03-08 17:02 ` Sean McAfee
2010-03-08 17:24 ` David Kastrup
2010-03-09 6:45 ` Tim X
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87mxyjs28x.fsf@rapttech.com.au \
--to=timx@nospam.dev.null \
--cc=help-gnu-emacs@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).