Re: [O] bug#14346: 24.3; beginning-of-visual-line jumps to previous line in org-mode
On 7.5.2013, at 03:34, E Sabof esa...@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 esa...@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 e...@gnu.org wrote: Date: Sat, 4 May 2013 12:17:35 +0100 From: E Sabof esa...@gmail.com Cc: 14...@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.
Re: [O] bug#14346: 24.3; beginning-of-visual-line jumps to previous line in org-mode
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 Evgeni On Sat, May 4, 2013 at 2:27 PM, E Sabof esa...@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 e...@gnu.org wrote: Date: Sat, 4 May 2013 12:17:35 +0100 From: E Sabof esa...@gmail.com Cc: 14...@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.
