bug#14346: [O] bug#14346: 24.3; beginning-of-visual-line jumps to previous line in org-mode

[Carsten Dominik]

On 7.5.2013, at 03:34, E Sabof <esabof@gmail.com> wrote:

Even if the behavior doesn't change (soon), could the equivalent of the following be implemented in org-mode? It's the only place where this has been problematic for me. 

(defadvice org-beginning-of-line (after smart-point-adjustment activate)

  (setq disable-point-adjustment

        (or (not (invisible-p (point)))

            (not (invisible-p (max (point-min) (1- (point))))))))

(defadvice org-end-of-line (after smart-point-adjustment activate)

  (setq disable-point-adjustment

        (or (not (invisible-p (point)))

            (not (invisible-p (max (point-min) (1- (point))))))))

I have implemented these in Org master, so this will eventually mode into emacs as well.

- Carsten

Evgeni

On Sat, May 4, 2013 at 2:27 PM, E Sabof <esabof@gmail.com> wrote:

Wouldn't it be better if forward/backward-char kept the old behavior, and the rest of the commands did something similar to this in the end:

(setq disable-point-adjustment

      (preceding-or-following-character-visible-p))

I'm not entirely sure whether it would be better, but at the moment, I can't think of a case where it wouldn't.

Evgeni

On Sat, May 4, 2013 at 1:16 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> Date: Sat, 4 May 2013 12:17:35 +0100
> From: E Sabof <esabof@gmail.com>
> Cc: 14346@debbugs.gnu.org

>
> I see what you mean. But it still looks like a bug - whether I follow the
> above recipe, or press C-e C-a, the point will (should?) go to the same
> position, but the behavior is different.

The behavior depends on the direction point was moving before ending
up in the invisible text.  It's a heuristic, and as every heuristic,
it sometimes fails.