move-beginning-of-line moves to the very beginning instead of where it should

move-beginning-of-line moves to the very beginning instead of where it should

[dan]

When i type control-A (move-beginning-of-line) in a shell or in the minibuffer,
it normally moves the insertion point right to where it would make sense to type
(i.e., right after the prompt).

However, sometimes it seems to lose its way, and when it does, it quits working
everywhere (shell, minibuffer), and goes all the way to the beginning of the
line, rather than right after the prompt.

This happens on mac os x, with emacs 24.3.1 and with 22.1.1 (the one
bundled with the mac).  It takes from a day to a few weeks or so to show up.

I've never had that experience with ubuntu, despite the fact that my
usage is similar (using emacs continuously, and leaving it up for
months).

I've opened dribble files so that i can go back and try to see if i typed
something funny to cause it.  But what i type looks innocuous (all key
combos i can recognize, at least the most recent few hundred).

So i'm wondering what i'm doing that changes the meaning of
move-beginning-of-line, and also how i can restore it to go
to the position right after the prompt instead of the very
beginning of the line.  This happens on both 22.1.1 and 24.3.1,
but is worse on 22.1.1 (where it makes escape-p malfunction in
shell mode).

I tried googling for this several times, but never found it.
However i could not possibly be the only person who experiences it.)

Thanks in advance for any pointers.

dan

Re: move-beginning-of-line moves to the very beginning instead of where it should

[Emanuel Berg]

dan <dan.hitt@gmail.com> writes:

> When i type control-A (move-beginning-of-line) in a
> shell or in the minibuffer, it normally moves the
> insertion point right to where it would make sense to
> type (i.e., right after the prompt).
>
> However, sometimes it seems to lose its way, and when
> it does, it quits working everywhere (shell,
> minibuffer), and goes all the way to the beginning of
> the line, rather than right after the prompt.
>
> This happens on mac os x, with emacs 24.3.1 and with
> 22.1.1 (the one bundled with the mac). It takes from
> a day to a few weeks or so to show up.
>
> I've never had that experience with ubuntu, despite
> the fact that my usage is similar (using emacs
> continuously, and leaving it up for months).

Yeah, this is not (shouldn't be) an Emacs-version or
OS/distro issue, it is about the different modes in
Emacs and how they define the "beginning" of a line.

There are modes to show overflow lines on several lines
on your display. That makes sense... but it can make
for confusion like in your case. Instead of
visual-line-mode you can have auto-fill-mode and then
hopefully beginning-of-line will be a better match with
your (and mine) intuition of it.

There are also other functions that you can bind to C-a
- perhaps step 2...

-- 
underground experts united

Re: move-beginning-of-line moves to the very beginning instead of where it should

[dan]

On Friday, September 5, 2014 10:40:16 PM UTC-7, Emanuel Berg wrote:

> There are modes to show overflow lines on several lines
> on your display. That makes sense... but it can make
> for confusion like in your case. Instead of
> visual-line-mode you can have auto-fill-mode and then
> hopefully beginning-of-line will be a better match with
> your (and mine) intuition of it.

Thanks Emanuel for the info about visual-line-mode.

It doesn't seem to exist in the older emacs (22.2.1) but does
exist in 24.3.1.

It has an effect if the prompt is more than one visual line long,
but control-A still takes you to the very beginning of the line.

So, for example, if the prompt is 1.5 lines long, then control-A
takes you to the beginning of the visual line, i.e., deep inside
the prompt, but on the same line.

So . . . i'm all ears for a new function to bind to control-A.

But if i had a way of reversing the behavior that would be even better.

Why should control-A work properly, and then suddenly stop?  (I'm pretty
sure i must somehow be clobbering it with some accidental keystrokes,
but i sure cannot figure out what they are.  :(   It typically works
for at least a few days before it flips into this misbehaving state.)

Thanks for your help!

dan

Re: move-beginning-of-line moves to the very beginning instead of where it should

[Stefan Monnier]

> However, sometimes it seems to lose its way, and when it does, it
> quits working everywhere (shell, minibuffer), and goes all the way to
> the beginning of the line, rather than right after the prompt.

Probably some poorly written package which sets up a global binding
rather than a local one.

When you bump into this problem, check whether C-a is still bound to
move-beginning-of-line.  If it is, check the definition of
move-beginning-of-line.  In doubt, you can hit C-u M-C-x in the source
code so that next time you C-a, you'll be put into step-by-step
debugging to see where it goes wrong,


        Stefan

Re: move-beginning-of-line moves to the very beginning instead of where it should

[Emanuel Berg]

Though visual-line-mode can be practical sometimes, I
recommend auto-fill-mode or a version thereof. That
fills paragraphs as you type. Only, sometimes when you
edit stuff (after you have written a paragraph) you
have to (re)fill manually, with M-q (unless the edit
was an append).

But if you practice your thinking/spelling/typing
skills you more and more seldom have to do that. The
rare cases when you do have to do it manually are a
good barter for the big advantage of having the file
look as it does data-wise on you display.

C-a isn't the same everywhere even so. In the
message-mode, it is message-beginning-of-line which has
to do with the header section of an email where C-a
sensibly isn't the beginning of the header, but the
beginning of the header data.

Here is a cool DWIM version for writers of code. (He
who wrote it must be a real hacker himself.)

(defun back-to-dwim ()
  (interactive)
  (let ((point (point)))
    (back-to-indentation)
    (if (= point (point))
        (move-beginning-of-line nil) ))) ; ARG (nil =
  this line)

It seems the C-a in message-mode works the same way:
place point anywhere on a header line to the right of
the comma, and hit `C-a C-a'!

Interestingly for this issue the defun uses
move-beginning-of-line which docstring says it acts on
displayed lines, so that should (?) get "filled text
C-a behavior" for visual-line-mode broken lines - feel
free to try that, and report back what happened!

-- 
underground experts united

Re: move-beginning-of-line moves to the very beginning instead of where it should

[dan]

Thanks Emanuel and Stefan.

Finally the problem sort of solved itself, and i'm posting just in case somebody else has this problem and is trawling the net for a clue like i was.

Just to recap, the problem was the control-A in the shell (move-beginning-of-line) would quit working for me when using emacs on the mac.  It would always start out working, but after a session was up for some time---an hour to a few days to a few weeks---it would begin misbehaving by going all the way to the beginning of the line, instead of stopping at the end of the shell prompt.

But the problem never happened on ubuntu or any other system.

I tried following some of the very good advice given here about how to debug the elisp code but could not get to the bottom of it.

But then somebody (Juan Leon) yesterday posted the same issue on emacs.stackexchange.com, and somebody else (abo-abo) suggested looking at inhibit-field-text-motion.  And that turned out to be my problem: i had a function which temporarily set that variable to t, but sometimes i interrupted the function---and in those cases (naturally) control-A would quit working properly.  And it never showed up on ubuntu, because on ubuntu i had an alternative to that function.

So thanks again everybody!

dan