Advice on troubleshooting function to "unscroll"

Advice on troubleshooting function to "unscroll"

[Will Monroe]

Hello,

I'm studying Emacs Lisp so that I can become more proficient at 
customizing GNU Emacs for purposes, mainly using org-mode.  I'm studying 
alone using Bob Glickstein's *Writing GNU Emacs Extensions*.  So far, 
the book has been a terrific guide to basic concepts.  But I've run into 
a problem that I can't seem to troubleshoot any further and I'd 
appreciate advice on: 1) the best way to troubleshoot this problem 
(e.g., other forums, listservs, or IRC channels that might be more 
appropriate) and 2) troubleshooting the problem itself.  I apologize in 
advance if this query has failed to take into account any basics or if 
it would be better posed elsewhere.  I welcome your on the best way to 
proceed.

So, following Glickstein's advice in Chapter 3, I'm trying to create a 
function that will allow me to create an "unscroll" function that will 
allow me to return to a prior buffer position after (inadvertently) 
pressing C-v a few times.  The code to do this defines three new 
variables, defines advice for an extant Emacs function, scroll-up, and 
then defines a new function, unscroll.  The code is below.

#+BEGIN_SRC emacs-lisp
(defvar unscroll-point nil
   "Cursor position for next call to 'unscroll'.")

(defvar unscroll-window-start nil
   "Window start for next call to 'unscroll'.")

(defvar unscroll-hscroll nil
   "Hscroll start for next call to 'unscroll'.")

(defadvice scroll-up (before remember-for-unscroll
			     activate compile)
   "Remember where we started from, for 'unscroll'."
   (if (not (eq last-command 'scroll-up))
       (setq unscroll-point (point)
	      unscroll-window-start (window-start)
	      unscroll-hscroll (window-hscroll))))

(defun unscroll ()
   "Revert to 'unscroll-point' and 'unscroll-window-start'."
   (interactive)
   (goto-char unscroll-point)
   (set-window-start nil unscroll-window-start)
   (set-window-hscroll nil unscroll-hscroll))
#+END_SRC

I've loaded this code in Emacs under two different conditions:  1) by 
firing up a vanilla Emacs instance without any configuration file, and 
evaluating the code in scratch and 2) by saving the above code as the 
sole contents in a configuration file (~/.emacs.d/init.el) and then 
starting up Emacs.  I've done this on two different machines both 
running versions of Emacs 24.

The test was just opening a lengthy file, usually an info page or an 
existing org-mode file, pressing C-v a few times, and then using M-x 
unscroll.  In all cases, I found that M-x unscroll would return to the 
position just before the last C-v but not to the original position.  In 
other words, if I pressed C-v two times and then pressed M-x unscroll, 
in would only go back one C-v.  My intent, and that of the example in 
the book, is to return the point the position before any C-v key 
sequences were pressed.

I could move one but I suspect that the mistake I've made will come up 
again.  I'd really welcome your (gentle) feedback!

All the best,

Will

Re: Advice on troubleshooting function to "unscroll"

[Marcin Borkowski]

On 2015-01-25, at 21:52, Will Monroe <wtmonroe.ls@gmail.com> wrote:

> Hello,
>
> I'm studying Emacs Lisp so that I can become more proficient at 
> customizing GNU Emacs for purposes, mainly using org-mode.  I'm studying 
> alone using Bob Glickstein's *Writing GNU Emacs Extensions*.  So far, 
> the book has been a terrific guide to basic concepts.  But I've run into 
> a problem that I can't seem to troubleshoot any further and I'd 
> appreciate advice on: 1) the best way to troubleshoot this problem 
> (e.g., other forums, listservs, or IRC channels that might be more 
> appropriate) and 2) troubleshooting the problem itself.  I apologize in 
> advance if this query has failed to take into account any basics or if 
> it would be better posed elsewhere.  I welcome your on the best way to 
> proceed.

Welcome to the land of Elisp.  (I'm also a relative newcomer here.)

BTW, I looked at the free sample of Glickstein's book in the Amazon
Kindle store (not that I recommend it -- in fact, it is seemingly
prohibited to recommend things like that here), and got the impression
that it is a nice book -- something to read right after the "Emacs Lisp
Intro" by Robert J. Chassell -- but it might be a bit outdated.  (For
instance, the early part about problems with C-h and backspace seem to
be irrelevant nowadays.)  A question to more knowledgeable people: is
that impression correct?

> So, following Glickstein's advice in Chapter 3, I'm trying to create a 
> function that will allow me to create an "unscroll" function that will 
> allow me to return to a prior buffer position after (inadvertently) 
> pressing C-v a few times.  The code to do this defines three new 
> variables, defines advice for an extant Emacs function, scroll-up, and 
> then defines a new function, unscroll.  The code is below.

Please note that there is new syntax for advising functions in Emacs
24.4 (or 25, I'm not sure).  The old one should work, but the new one is
much simpler.

> The test was just opening a lengthy file, usually an info page or an 
> existing org-mode file, pressing C-v a few times, and then using M-x 
> unscroll.  In all cases, I found that M-x unscroll would return to the 
> position just before the last C-v but not to the original position.  In 
> other words, if I pressed C-v two times and then pressed M-x unscroll, 
> in would only go back one C-v.  My intent, and that of the example in 
> the book, is to return the point the position before any C-v key 
> sequences were pressed.
>
> I could move one but I suspect that the mistake I've made will come up 
> again.  I'd really welcome your (gentle) feedback!

I would strongly advise (no pun intended) to read the Emacs Lisp
reference, section about Edebug.

> All the best,
>
> Will

The same to you,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: Advice on troubleshooting function to "unscroll"

[Will Monroe]

Marcin,

Thanks for your quick and friendly response!

On 01/25/2015 03:35 PM, Marcin Borkowski wrote:
>
> On 2015-01-25, at 21:52, Will Monroe <wtmonroe.ls@gmail.com> wrote:
>
>> Hello,
>>
>> I'm studying Emacs Lisp so that I can become more proficient at
>> customizing GNU Emacs for purposes, mainly using org-mode.  I'm studying
>> alone using Bob Glickstein's *Writing GNU Emacs Extensions*.  So far,
>> the book has been a terrific guide to basic concepts.  But I've run into
>> a problem that I can't seem to troubleshoot any further and I'd
>> appreciate advice on: 1) the best way to troubleshoot this problem
>> (e.g., other forums, listservs, or IRC channels that might be more
>> appropriate) and 2) troubleshooting the problem itself.  I apologize in
>> advance if this query has failed to take into account any basics or if
>> it would be better posed elsewhere.  I welcome your on the best way to
>> proceed.
>
> Welcome to the land of Elisp.  (I'm also a relative newcomer here.)
>
> BTW, I looked at the free sample of Glickstein's book in the Amazon
> Kindle store (not that I recommend it -- in fact, it is seemingly
> prohibited to recommend things like that here), and got the impression
> that it is a nice book -- something to read right after the "Emacs Lisp
> Intro" by Robert J. Chassell -- but it might be a bit outdated.

Thanks for this suggestion!

   (For
> instance, the early part about problems with C-h and backspace seem to
> be irrelevant nowadays.)

You know, I wondered about the backspace and C-h too.  But then I heard 
an interview RMS did on some podcast recently and he mentioned some 
early design differences between Emacs developers on this point. 
Perhaps intended as a humorous anecdote? ; )

A question to more knowledgeable people: is
> that impression correct?
>
>> So, following Glickstein's advice in Chapter 3, I'm trying to create a
>> function that will allow me to create an "unscroll" function that will
>> allow me to return to a prior buffer position after (inadvertently)
>> pressing C-v a few times.  The code to do this defines three new
>> variables, defines advice for an extant Emacs function, scroll-up, and
>> then defines a new function, unscroll.  The code is below.
>
> Please note that there is new syntax for advising functions in Emacs
> 24.4 (or 25, I'm not sure).  The old one should work, but the new one is
> much simpler.

Thanks for this tip.  In the first three chapters, I recall seeing a few 
references that were a bit dated but I just worked around them.  But 
your mentioning this brings to mind the possibility that code provided 
in the book is so dated that it might explain why it fails to work as I 
expect.  But knowing so little about lisp, It's hard to say.
"DePaul Online Teaching Series: Facilitating effective online learning
>
>> The test was just opening a lengthy file, usually an info page or an
>> existing org-mode file, pressing C-v a few times, and then using M-x
>> unscroll.  In all cases, I found that M-x unscroll would return to the
>> position just before the last C-v but not to the original position.  In
>> other words, if I pressed C-v two times and then pressed M-x unscroll,
>> in would only go back one C-v.  My intent, and that of the example in
>> the book, is to return the point the position before any C-v key
>> sequences were pressed.
>>
>> I could move one but I suspect that the mistake I've made will come up
>> again.  I'd really welcome your (gentle) feedback!
>
> I would strongly advise (no pun intended) to read the Emacs Lisp
> reference, section about Edebug.

Thanks for the advice about Edebug.  It's definitely something that is 
on my mind.  But over the last day or so, I've hesitated from diving 
into Edebug because there was no "error" as such.  That is, the code 
"worked" it just didn't do what I intended.  Wasn't sure Edebug would 
help in a case like that...but your point is well taken.  Thank you!

>
>> All the best,
>>
>> Will
>
> The same to you,
>

Re: Advice on troubleshooting function to "unscroll"

[Marcin Borkowski]

On 2015-01-25, at 22:43, Will Monroe <wtmonroe.ls@gmail.com> wrote:

> Marcin,
>
> Thanks for your quick and friendly response!

You're welcome!

> Thanks for the advice about Edebug.  It's definitely something that is 
> on my mind.  But over the last day or so, I've hesitated from diving 
> into Edebug because there was no "error" as such.  That is, the code 
> "worked" it just didn't do what I intended.  Wasn't sure Edebug would 
> help in a case like that...but your point is well taken.  Thank you!

It might.  It lets you step through the execution of some part of the
code, seeing the result of evaluating each and every expression along
the way.  It may be very helpful sometimes.  And it's easy to just start
with it: just define the function with C-u C-M-x ("instrument" it for
Edebug), and then -- when the execution gest to it (and pauses) -- use
SPC to step through it or `G' to continue without stopping.  When you're
happy with your understanding what's going on in the code, press C-M-x
on the defun again.  (There's a lot more to Edebug than this, but it
should be enough to get you started.)

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: Advice on troubleshooting function to "unscroll"

[Will Monroe]

Marcin,

Thank you for that mini-lesson to help me get started with Edebug!  It's 
funny but I remember seeing a great visualization tool for Python 
scripts that graphically depicted the sequence of steps in simple 
scripts/programs.  It was intended to help instruct novices and help 
debug code.  I remember thinking, "if only there were something for 
Elisp tht did that".  This is what I needed!

Will

On 01/25/2015 03:55 PM, Marcin Borkowski wrote:
>
> On 2015-01-25, at 22:43, Will Monroe <wtmonroe.ls@gmail.com> wrote:
>
>> Marcin,
>>
>> Thanks for your quick and friendly response!
>
> You're welcome!
>
>> Thanks for the advice about Edebug.  It's definitely something that is
>> on my mind.  But over the last day or so, I've hesitated from diving
>> into Edebug because there was no "error" as such.  That is, the code
>> "worked" it just didn't do what I intended.  Wasn't sure Edebug would
>> help in a case like that...but your point is well taken.  Thank you!
>
> It might.  It lets you step through the execution of some part of the
> code, seeing the result of evaluating each and every expression along
> the way.  It may be very helpful sometimes.  And it's easy to just start
> with it: just define the function with C-u C-M-x ("instrument" it for
> Edebug), and then -- when the execution gest to it (and pauses) -- use
> SPC to step through it or `G' to continue without stopping.  When you're
> happy with your understanding what's going on in the code, press C-M-x
> on the defun again.  (There's a lot more to Edebug than this, but it
> should be enough to get you started.)
>
> Best,
>

Re: Advice on troubleshooting function to "unscroll"

[Marcin Borkowski]

On 2015-01-25, at 21:52, Will Monroe <wtmonroe.ls@gmail.com> wrote:

> The test was just opening a lengthy file, usually an info page or an 
> existing org-mode file, pressing C-v a few times, and then using M-x 
> unscroll.  In all cases, I found that M-x unscroll would return to the 
> position just before the last C-v but not to the original position.  In 
> other words, if I pressed C-v two times and then pressed M-x unscroll, 
> in would only go back one C-v.  My intent, and that of the example in 
> the book, is to return the point the position before any C-v key 
> sequences were pressed.

One more thing: it might be the case that C-v was bound to scroll-up in
Glickstein times, but it is bound to scroll-up-command (which see) now.
Try to change (eq last-command 'scroll-up) to (eq last-command
'scroll-up-command).  (I did not test it, just an idea.)

PS. Another nice way to learn Elisp is to study Emacs sources.  I'm
about 10% into simple.el, learned quite a bit, and as an additional
bonus found two or three bugs (I haven't reported them yet, but I'll do
it soon).  Beware that not everyone would recommend learning good
practices or style from some of those sources, though.

Hth,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: Advice on troubleshooting function to "unscroll"

[Will Monroe]

Marcin,

As Joost also pointed out, the "problem" was that C-v was bound to 
another (older?) function.  Changing it fixed my issue.

And thanks for the advice about studying sources. I actually read your 
question about bookmark with Elisp with interest for that very reason.

Will

On 01/25/2015 03:45 PM, Marcin Borkowski wrote:
>
> On 2015-01-25, at 21:52, Will Monroe <wtmonroe.ls@gmail.com> wrote:
>
>> The test was just opening a lengthy file, usually an info page or an
>> existing org-mode file, pressing C-v a few times, and then using M-x
>> unscroll.  In all cases, I found that M-x unscroll would return to the
>> position just before the last C-v but not to the original position.  In
>> other words, if I pressed C-v two times and then pressed M-x unscroll,
>> in would only go back one C-v.  My intent, and that of the example in
>> the book, is to return the point the position before any C-v key
>> sequences were pressed.
>
> One more thing: it might be the case that C-v was bound to scroll-up in
> Glickstein times, but it is bound to scroll-up-command (which see) now.
> Try to change (eq last-command 'scroll-up) to (eq last-command
> 'scroll-up-command).  (I did not test it, just an idea.)
>
> PS. Another nice way to learn Elisp is to study Emacs sources.  I'm
> about 10% into simple.el, learned quite a bit, and as an additional
> bonus found two or three bugs (I haven't reported them yet, but I'll do
> it soon).  Beware that not everyone would recommend learning good
> practices or style from some of those sources, though.
>
> Hth,
>

Re: Advice on troubleshooting function to "unscroll"

[Marcin Borkowski]

On 2015-01-25, at 23:03, Will Monroe <wtmonroe.ls@gmail.com> wrote:

> Marcin,
>
> As Joost also pointed out, the "problem" was that C-v was bound to 
> another (older?) function.  Changing it fixed my issue.
>
> And thanks for the advice about studying sources. I actually read your 
> question about bookmark with Elisp with interest for that very reason.

Wow, thanks!  You might be interested in that I'm preparing a blog post
about a workflow for using bookmarks when reading sources.  Stay tuned!

> Will

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

RE: Advice on troubleshooting function to "unscroll"

[Drew Adams]

> the "problem" was that C-v was bound to another (older?) function.

The command `scroll-up' is indeed older, and it is still usable.
It is, in fact, the core of the `scroll-up-command' implementation.

(In Emacs, it is often the case that you can use a command
non-interactively, though this is sometimes explicitly not
recommended for certain commands.)

`scroll-up-command' was added in Emacs 24.1, to (a) retain the
`scroll-up' behavior as a separate function, and yet (b) provide
additional behavior when you scroll interactively, in particular
the handling of the new (in 24.1) option `scroll-error-top-bottom'.

> I've hesitated from diving into Edebug because there was no
> "error" as such.  That is, the code "worked" it just didn't do
> what I intended.

Using the debugger (and debugging generally) is not necessarily
about finding why Emacs raises a particular error.  (That is the
particular use of variable `debug-on-error': enter the debugger
to show a backtrace when an error is raised.)

In addition to Edebug, there is the regular Emacs debugger, aka
`debug'.  Some of us prefer to use that.  Others prefer to use
it in some cases but `edebug' in other cases.

Keep in mind too that any debugger does not necessarily tell you
everything that goes on, and its representation of what happens
with debugging turned off is not flawless.  In particular, this
is because using the debugger itself changes what Emacs does.
(Think of the debugger's buffer display and its handling of
input events, for example.)

The regular debugger is what you get with `debug-on-entry' and
by inserting calls to `(debug)' in code to serve more or less as
breakpoints.  See `C-h f debug' for information about evaluating
and displaying the results of sexps (cdr ARGS) upon entry into
the debugger.

Re: Advice on troubleshooting function to "unscroll"

[Will Monroe]

Drew,

Thank you for this detailed response.

On 01/25/2015 04:45 PM, Drew Adams wrote:
>> the "problem" was that C-v was bound to another (older?) function.
>
> The command `scroll-up' is indeed older, and it is still usable.
> It is, in fact, the core of the `scroll-up-command' implementation.
>
> (In Emacs, it is often the case that you can use a command
> non-interactively, though this is sometimes explicitly not
> recommended for certain commands.)
>
> `scroll-up-command' was added in Emacs 24.1, to (a) retain the
> `scroll-up' behavior as a separate function, and yet (b) provide
> additional behavior when you scroll interactively, in particular
> the handling of the new (in 24.1) option `scroll-error-top-bottom'.

Interesting.  Given what the author's assumptions of how 'scroll-up' 
should work and how the newer 'scroll-up-command' seems to share some, 
but not all, of that functionality, it would probably be interesting to 
see where they differ.  I may not be expressing this clearly, but you've 
helped to clarify the question I want to answer to be: "why did 
scroll-up-command work where the still useful but not appropriate 
scroll-up did not?"

>
>> I've hesitated from diving into Edebug because there was no
>> "error" as such.  That is, the code "worked" it just didn't do
>> what I intended.
>
> Using the debugger (and debugging generally) is not necessarily
> about finding why Emacs raises a particular error.  (That is the
> particular use of variable `debug-on-error': enter the debugger
> to show a backtrace when an error is raised.)
>
> In addition to Edebug, there is the regular Emacs debugger, aka
> `debug'.  Some of us prefer to use that.  Others prefer to use
> it in some cases but `edebug' in other cases.
>
> Keep in mind too that any debugger does not necessarily tell you
> everything that goes on, and its representation of what happens
> with debugging turned off is not flawless.  In particular, this
> is because using the debugger itself changes what Emacs does.
> (Think of the debugger's buffer display and its handling of
> input events, for example.)
>
> The regular debugger is what you get with `debug-on-entry' and
> by inserting calls to `(debug)' in code to serve more or less as
> breakpoints.  See `C-h f debug' for information about evaluating
> and displaying the results of sexps (cdr ARGS) upon entry into
> the debugger.
>

This is very helpful stuff to consider as I begin to think about what I 
want to accomplish when using Edebug or debugger.

And if I'm being honest about why I did not go to Edebug it's because I 
was anticipating great difficulty reading the backtrace statements.  I 
thought my problem might be compounded by a more general illiteracy in 
that regard...

Thanks again, Drew.  A really helpful answer!

Will

Re: Advice on troubleshooting function to "unscroll"

[Marcin Borkowski]

On 2015-01-25, at 23:56, Will Monroe <wtmonroe.ls@gmail.com> wrote:

> On 01/25/2015 04:45 PM, Drew Adams wrote:
>>
>> The command `scroll-up' is indeed older, and it is still usable.
>> It is, in fact, the core of the `scroll-up-command' implementation.
>
> Interesting.  Given what the author's assumptions of how 'scroll-up' 
> should work and how the newer 'scroll-up-command' seems to share some, 
> but not all, of that functionality, it would probably be interesting to 
> see where they differ.  I may not be expressing this clearly, but you've 
> helped to clarify the question I want to answer to be: "why did 
> scroll-up-command work where the still useful but not appropriate 
> scroll-up did not?"

That's why it's useful to say

M-x find-function RET scroll-up-command RET!

>>> I've hesitated from diving into Edebug because there was no
>>> "error" as such.  That is, the code "worked" it just didn't do
>>> what I intended.
>>
>> Using the debugger (and debugging generally) is not necessarily
>> about finding why Emacs raises a particular error.  (That is the
>> particular use of variable `debug-on-error': enter the debugger
>> to show a backtrace when an error is raised.)
>>
>> In addition to Edebug, there is the regular Emacs debugger, aka
>> `debug'.  Some of us prefer to use that.  Others prefer to use
>> it in some cases but `edebug' in other cases.

Thanks, Drew, for mentioning that!

>> Keep in mind too that any debugger does not necessarily tell you
>> everything that goes on, and its representation of what happens
>> with debugging turned off is not flawless.  In particular, this
>> is because using the debugger itself changes what Emacs does.
>> (Think of the debugger's buffer display and its handling of
>> input events, for example.)
>>
>> The regular debugger is what you get with `debug-on-entry' and
>> by inserting calls to `(debug)' in code to serve more or less as
>> breakpoints.  See `C-h f debug' for information about evaluating
>> and displaying the results of sexps (cdr ARGS) upon entry into
>> the debugger.

I do not like the (debug) approach, since it seems to be less
newbie-friendly.  It is true, of course, that Edebug does not always
work as intended.

> This is very helpful stuff to consider as I begin to think about what I 
> want to accomplish when using Edebug or debugger.
>
> And if I'm being honest about why I did not go to Edebug it's because I 
> was anticipating great difficulty reading the backtrace statements.  I 
> thought my problem might be compounded by a more general illiteracy in 
> that regard...

Now I'm starting to think that it would be nice to study the backtraces
once and for all and write about them (for myself and for others)...

> Thanks again, Drew.  A really helpful answer!

Me too!

> Will

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

RE: Advice on troubleshooting function to "unscroll"

[Drew Adams]

> why did scroll-up-command work where the still useful but not
> appropriate scroll-up did not?

That was already answered, and I thought that you understood
the answer.  The problem was that the code checked whether the
current command was `scroll-up', and it of course never would
be.  `scroll-up' is called by `scroll-up-command', but only the
latter, never the former, is invoked by you interactively, i.e.,
as a command.  Variables `this-command' and `last-command' are
only set to functions when they are invoked as commands.

> And if I'm being honest about why I did not go to Edebug it's because I
> was anticipating great difficulty reading the backtrace statements.  I
> thought my problem might be compounded by a more general illiteracy in
> that regard...

The Emacs manual sends you to the Elisp manual, node `Edebug',
for information about using that debugger.  That section of the
Elisp manual is like a mini-manual about Edebug.

Why it does not send you instead to the Elisp manual node
`Debugger' (which has title "The Lisp Debugger"), I don't know.
That node covers the regular debugger (i.e., `debug').

`debug' is older than `edebug'.  Perhaps the person who wrote
`edebug' decided to send readers of the Emacs manual to learn
about Edebug. ;-)

(In older versions of Emacs, e.g. Emacs 20, there was no link
from the Emacs manual to the Elisp manual for either the regular
Lisp debugger or Edebug, but there were multiple mentions of
using the former - and only no mention of Edebug, except to say
that edebug.el was contributed by Daniel LaLiberte.)

Re: Advice on troubleshooting function to "unscroll"

[Marcin Borkowski]

On 2015-01-26, at 01:03, Drew Adams <drew.adams@oracle.com> wrote:

>> why did scroll-up-command work where the still useful but not
>> appropriate scroll-up did not?
>
> That was already answered, and I thought that you understood
> the answer.  The problem was that the code checked whether the
> current command was `scroll-up', and it of course never would
> be.  `scroll-up' is called by `scroll-up-command', but only the
> latter, never the former, is invoked by you interactively, i.e.,
> as a command.  Variables `this-command' and `last-command' are
> only set to functions when they are invoked as commands.

I think the OP did understand this, but meant to ask (more or less) "why
weren't the Emacs Devs satisfied with scroll-up, which did work after
all".

>> And if I'm being honest about why I did not go to Edebug it's because I
>> was anticipating great difficulty reading the backtrace statements.  I
>> thought my problem might be compounded by a more general illiteracy in
>> that regard...
>
> The Emacs manual sends you to the Elisp manual, node `Edebug',
> for information about using that debugger.  That section of the
> Elisp manual is like a mini-manual about Edebug.
>
> Why it does not send you instead to the Elisp manual node
> `Debugger' (which has title "The Lisp Debugger"), I don't know.
> That node covers the regular debugger (i.e., `debug').
>
> `debug' is older than `edebug'.  Perhaps the person who wrote
> `edebug' decided to send readers of the Emacs manual to learn
> about Edebug. ;-)
>
> (In older versions of Emacs, e.g. Emacs 20, there was no link
> from the Emacs manual to the Elisp manual for either the regular
> Lisp debugger or Edebug, but there were multiple mentions of
> using the former - and only no mention of Edebug, except to say
> that edebug.el was contributed by Daniel LaLiberte.)

Drew, your answer is (as usual) very helpful and informative.  Thank you
for your insights and the bits about Emacs history.

I think we really need Sacha Chua to do an Emacs Chat with you.  I,
personally, would love to learn a bit about your workflow and Emacs
config.  (Not that I would necessarily like to copy it: I strongly
disagree with you on the window/frame issue, for instance!)

Regards,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

RE: Advice on troubleshooting function to "unscroll"

[Drew Adams]

> meant to ask (more or less) "why weren't the Emacs Devs satisfied
> with scroll-up, which did work after all".

It was thought good to give users a choice (via option
`scroll-error-top-bottom') of what happens when a scrolling error
is raised.  I use the default value of the option (`nil'), so for
me the behavior is exactly the same as for command `scroll-up'.
But you might prefer an option value of `t'.

> I think we really need Sacha Chua to do an Emacs Chat with you.  I,
> personally, would love to learn a bit about your workflow and Emacs
> config.  (Not that I would necessarily like to copy it: I strongly
> disagree with you on the window/frame issue, for instance!)

Sorry.  I've told Sacha that there are tons of others to be
interviewed before and instead of me.  And I don't really have a
workflow.  And my config is pretty much the code I've made available
here and there.  I've used Emacs for a long time, but that doesn't
mean that I use it particularly well or in any particularly
interesting way.

In particular, I no longer develop software (apart from futzing
around with Emacs Lisp), so my use of Emacs is hardly helpful to
anyone wanting to program: most Emacs users and use cases.

I don't use Emacs for anything, apart from playing with Emacs.

Re: Advice on troubleshooting function to "unscroll"

[Will Monroe]

>>> why did scroll-up-command work where the still useful but not
>>> appropriate scroll-up did not?
>>
>> That was already answered, and I thought that you understood
>> the answer.  The problem was that the code checked whether the
>> current command was `scroll-up', and it of course never would
>> be.  `scroll-up' is called by `scroll-up-command', but only the
>> latter, never the former, is invoked by you interactively, i.e.,
>> as a command.  Variables `this-command' and `last-command' are
>> only set to functions when they are invoked as commands.
>
> I think the OP did understand this, but meant to ask (more or less) "why
> weren't the Emacs Devs satisfied with scroll-up, which did work after
> all".

Actually, you're both correct!

Drew, I'll have to go back and look at what "interactive" actually 
means.  'scroll-up' is advised (and invoked?) in the code below.  Not 
sure if that means that I am also invoking it interactively.  I thought 
being invoked, "as a command", meant that I was invoking it using `M-x 
scroll-up`.

(defadvice scroll-up (before remember-for-unscroll
                  activate compile)
   "Remember where we started from, for 'unscroll'."
   (if (not (eq last-command 'scroll-up))
       (setq unscroll-point (point)
           unscroll-window-start (window-start)
           unscroll-hscroll (window-hscroll))))

Marcin, I also wondering what prompted the addition of 
scroll-up-command.  I think Drew addresses this but I probably need to 
look at the docstrings for both to grasp it more clearly.

>>> And if I'm being honest about why I did not go to Edebug it's because I
>>> was anticipating great difficulty reading the backtrace statements.  I
>>> thought my problem might be compounded by a more general illiteracy in
>>> that regard...
>>
>> The Emacs manual sends you to the Elisp manual, node `Edebug',
>> for information about using that debugger.  That section of the
>> Elisp manual is like a mini-manual about Edebug.
>>
>> Why it does not send you instead to the Elisp manual node
>> `Debugger' (which has title "The Lisp Debugger"), I don't know.
>> That node covers the regular debugger (i.e., `debug').
>>
>> `debug' is older than `edebug'.  Perhaps the person who wrote
>> `edebug' decided to send readers of the Emacs manual to learn
>> about Edebug. ;-)
>>
>> (In older versions of Emacs, e.g. Emacs 20, there was no link
>> from the Emacs manual to the Elisp manual for either the regular
>> Lisp debugger or Edebug, but there were multiple mentions of
>> using the former - and only no mention of Edebug, except to say
>> that edebug.el was contributed by Daniel LaLiberte.)
>
> Drew, your answer is (as usual) very helpful and informative.  Thank you
> for your insights and the bits about Emacs history.
>
> I think we really need Sacha Chua to do an Emacs Chat with you.  I,
> personally, would love to learn a bit about your workflow and Emacs
> config.  (Not that I would necessarily like to copy it: I strongly
> disagree with you on the window/frame issue, for instance!)

So much helpful detail that, as a solo student of Emacs and elisp, is 
helpful to me.  And as a regular viewer of Sacha Chua's Emacs Chats, I 
have to agree!

Best regards,

Will

Re: Advice on troubleshooting function to "unscroll"

[Marcin Borkowski]

On 2015-01-26, at 02:17, Will Monroe <wtmonroe.ls@gmail.com> wrote:

> Marcin, I also wondering what prompted the addition of 
> scroll-up-command.  I think Drew addresses this but I probably need to 
> look at the docstrings for both to grasp it more clearly.

No, not the docstrings!  The source!!!

:-D

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

RE: Advice on troubleshooting function to "unscroll"

[Drew Adams]

> I'll have to go back and look at what "interactive" actually means.

It means that you invoked it by name or via a key binding (which
includes a menu-item binding).

More precisely, it means that `called-interactively-p' returns
non-nil.  See also `interactive-p'.

> 'scroll-up' is advised (and invoked?) in the code below.

Advised, not invoked.  Invoked means called.  `scroll-up' is not
called in the advice definition you show.

> Not sure if that means that I am also invoking it interactively.

The advice applies whenever and however the function is called,
in particular, whether it is called interactively or not.

> I thought being invoked, "as a command", meant that I was
> invoking it using `M-x scroll-up`.

`M-x' invokes commands interactively, but it is not the only way
to do that - see above.  Note that `M-: (scroll-up)' does *not*
invoke `scroll-up' interactively.

> Marcin, I also wondering what prompted the addition of
> scroll-up-command.  I think Drew addresses this but I probably need to
> look at the docstrings for both to grasp it more clearly.

Look too at the beginning of the code for `scroll-up-command':
  (cond ((null scroll-error-top-bottom)
         (scroll-up arg))
        ...

That tells you that when the option is nil (the default value)
`scroll-up-command' just calls `scroll-up'.

Re: Advice on troubleshooting function to "unscroll"

[Joost Kremers]

Will Monroe wrote:
> (defadvice scroll-up (before remember-for-unscroll
> 			     activate compile)
>    "Remember where we started from, for 'unscroll'."
>    (if (not (eq last-command 'scroll-up))

Note that

    (if (not <some-test>)
         ... )

can be written as

    (unless <some-test>
      ...)

if you don't have an `else' part. It's slightly more readable that way
IMHO.

Also, as of (I think) Emacs 24.4, defadvice is no longer the recommended
way to advise functions. There's a new package (`nadvice.el`) that
defines `advice-add`. See the Elisp manual, section "Advising functions".

[...]
> The test was just opening a lengthy file, usually an info page or an 
> existing org-mode file, pressing C-v a few times, and then using M-x 
> unscroll.  In all cases, I found that M-x unscroll would return to the 
> position just before the last C-v but not to the original position.  In 
> other words, if I pressed C-v two times and then pressed M-x unscroll, 
> in would only go back one C-v.  My intent, and that of the example in 
> the book, is to return the point the position before any C-v key 
> sequences were pressed.

Have you checked what `C-v` is bound to? In my Emacs (24.4) it's bound
to `scroll-up-command`, not to `scroll-up`. So that would defeat your if
test above.

HTH


-- 
Joost Kremers                                   joostkremers@fastmail.fm
Selbst in die Unterwelt dringt durch Spalten Licht
EN:SiS(9)

Re: Advice on troubleshooting function to "unscroll"

[Will Monroe]

Joost,

Thank you for you response!

On 01/25/2015 03:35 PM, Joost Kremers wrote:
> Will Monroe wrote:
>> (defadvice scroll-up (before remember-for-unscroll
>> 			     activate compile)
>>     "Remember where we started from, for 'unscroll'."
>>     (if (not (eq last-command 'scroll-up))
>
> Note that
>
>      (if (not <some-test>)
>           ... )
>
> can be written as
>
>      (unless <some-test>
>        ...)
>
> if you don't have an `else' part. It's slightly more readable that way
> IMHO.

Thanks for recommending that more-readable rewrite.  I will look into 
redrafting it this way.

>
> Also, as of (I think) Emacs 24.4, defadvice is no longer the recommended
> way to advise functions. There's a new package (`nadvice.el`) that
> defines `advice-add`. See the Elisp manual, section "Advising functions".
>
> [...]

Thank you again.  This is also very helpful.  I found that defadvice 
still worked for this example (with one change, see below) but I won't 
likely use it again since it's no longer preferred.

>> The test was just opening a lengthy file, usually an info page or an
>> existing org-mode file, pressing C-v a few times, and then using M-x
>> unscroll.  In all cases, I found that M-x unscroll would return to the
>> position just before the last C-v but not to the original position.  In
>> other words, if I pressed C-v two times and then pressed M-x unscroll,
>> in would only go back one C-v.  My intent, and that of the example in
>> the book, is to return the point the position before any C-v key
>> sequences were pressed.
>
> Have you checked what `C-v` is bound to? In my Emacs (24.4) it's bound
> to `scroll-up-command`, not to `scroll-up`. So that would defeat your if
> test above.
>

So simple!  Thank you for this insight.  Going forward, I'll include a 
check of what functions my keybindings are actually bound to!  After 
substituting scroll-up-command for scroll-up in two places, it worked as 
intended.

Thank you very much,

Will

> HTH
>
>