Re: [RFC] Rewrite org-(forward|backward)-paragraph

2020-06-13 Thread Nicolas Goaziou
Since there was no negative feedback, I pushed to master.

Thanks.



Re: [RFC] Rewrite org-(forward|backward)-paragraph

2020-06-08 Thread Nicolas Goaziou
Hello,

Kévin Le Gouguec  writes:

> I don't know how useful my feedback will be, since I'm not a heavy user
> of paragraph-based movement[1], but here goes!

Thank you!

> I've danced around ORG-NEWS to assess the changes; what I observed does
> feel closer to text-mode (point moves to the blank lines between
> paragraphs instead of to the paragraph starts), the other changes I
> could spot do not strike me as deal-breaking:
>
> - point now jumps over tight lists[2] instead of stopping at each
> item,

The idea is to avoid some trivial moves where C-n would be sufficient,
e.g., in tables, properties drawers. Also Text mode skip those, since it
doesn't understand such structures.

> - point stops a few more times within code blocks, acting like
>   #+begin_src and #+end_src are paragraphs of their own, instead of
>   jumping over the whole block; also, forward and backward movements are
>   now symmetric 
>
> Are there other situations where you think your changes could be
> controversial?

I don't think it's much controversial, but stop points are necessarily
opinionated. I hope they make sense.

Also, testing could unveil some bugs.

>> WDYT?e Also, what should be done with M-{ and M-}?
>
> FWIW, I think that reducing the distance between Org mode and The Rest
> of Emacs™ is a commendable goal, so I would vote for binding paragraph
> functions to M-{ and M-}, and moving element functions to C- and
> C-.  I realize that this might be too big a change for the sake of
> conformity though.

Honestly, I don't know if Sexp-based navigation is useful at all. Does
anyone use such navigation ?

> (And again: I don't use these functions very often, so my vote probably
> shouldn't carry too much weight.)

I don't either. I didn't notice there was a difference until recently.

Regards,

-- 
Nicolas Goaziou



Re: [RFC] Rewrite org-(forward|backward)-paragraph

2020-06-08 Thread Kévin Le Gouguec
Hi Nicolas!

I don't know how useful my feedback will be, since I'm not a heavy user
of paragraph-based movement[1], but here goes!

Nicolas Goaziou  writes:

> In any case, the purpose of this rewrite is to mimic more closely
> expected behaviour from `forward-paragraph' and `backward-paragraph'
> functions, as found, e.g., in Text mode. Unlike Text mode, navigation in
> Org mode is usually not linear, but both should feel the same, for
> example, when the document is indeed linear.

I've danced around ORG-NEWS to assess the changes; what I observed does
feel closer to text-mode (point moves to the blank lines between
paragraphs instead of to the paragraph starts), the other changes I
could spot do not strike me as deal-breaking:

- point now jumps over tight lists[2] instead of stopping at each item,

- point stops a few more times within code blocks, acting like
  #+begin_src and #+end_src are paragraphs of their own, instead of
  jumping over the whole block; also, forward and backward movements are
  now symmetric 

Are there other situations where you think your changes could be
controversial?

> WDYT? Also, what should be done with M-{ and M-}?

FWIW, I think that reducing the distance between Org mode and The Rest
of Emacs™ is a commendable goal, so I would vote for binding paragraph
functions to M-{ and M-}, and moving element functions to C- and
C-.  I realize that this might be too big a change for the sake of
conformity though.

(And again: I don't use these functions very often, so my vote probably
shouldn't carry too much weight.)


Thank you for working on this!


[1] Curly brackets are cumbersome with AZERTY, so I never took the habit
of moving by paragraphs outside org-mode.  Likewise with Org's
 bindings: my fingers are too lazy to reach for the arrow
keys for something as often-used as movement.

[2] I.e. lists without newlines between items.



[RFC] Rewrite org-(forward|backward)-paragraph

2020-06-03 Thread Nicolas Goaziou
Hello,

Here is a proposal for new `org-forward-paragraph' and
`org-backward-paragraph' functions, currently bound to  and
. Note that functions bound to M-{ and M-} are /not/
paragraph-related functions, but we might want to reconsider it at some
point.

In any case, the purpose of this rewrite is to mimic more closely
expected behaviour from `forward-paragraph' and `backward-paragraph'
functions, as found, e.g., in Text mode. Unlike Text mode, navigation in
Org mode is usually not linear, but both should feel the same, for
example, when the document is indeed linear.

These functions try to stop at interesting places, and skip mundane ones
(e.g., tables are treated as a single block) so navigation is still
fast.

I also added support for repeat argument.

WDYT? Also, what should be done with M-{ and M-}?

Regards,

-- 
Nicolas Goaziou
>From 4ba83f948f9d8ab26261382b66450d531798f73e Mon Sep 17 00:00:00 2001
From: Nicolas Goaziou 
Date: Thu, 30 Apr 2020 16:00:18 +0200
Subject: [PATCH] Rewrite `org-forward-paragraph' and `org-backward-paragraph'

* lisp/org.el (org-forward-paragraph):
(org-backward-paragraph): Rewrite functions.  Add repeat argument.
Mimic more closely regular `forward|backward-paragraph' functions.
(org--forward-paragraph-once):
(org--backward-paragraph-once):
(org--paragraph-at-point): New functions.
* testing/lisp/test-org.el (test-org/forward-paragraph):
(test-org/backward-paragraph): Update tests.  Add some.

Signed-off-by: Nicolas Goaziou 
---
 lisp/org.el  | 440 ++-
 testing/lisp/test-org.el | 255 ---
 2 files changed, 471 insertions(+), 224 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index b869e12e1..59187fe52 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -20500,156 +20500,300 @@ With ARG, repeats or can move forward if negative."
   (interactive "p")
   (org-next-visible-heading (- arg)))
 
-(defun org-forward-paragraph ()
-  "Move forward to beginning of next paragraph or equivalent.
-
-The function moves point to the beginning of the next visible
-structural element, which can be a paragraph, a table, a list
-item, etc.  It also provides some special moves for convenience:
-
-  - On an affiliated keyword, jump to the beginning of the
-relative element.
-  - On an item or a footnote definition, move to the second
-element inside, if any.
-  - On a table or a property drawer, jump after it.
-  - On a verse or source block, stop after blank lines."
+(defun org-forward-paragraph ( arg)
+  "Move forward by a paragraph, or equivalent, unit.
+
+With argument ARG, do it ARG times;
+a negative argument ARG = -N means move backward N paragraphs.
+
+The function moves point between two structural
+elements (paragraphs, tables, lists, etc.).
+
+It also provides the following special moves for convenience:
+
+  - on a table or a property drawer, move to its beginning;
+  - on comment, example, export, source and verse blocks, stop
+at blank lines;
+  - skip consecutive clocks, diary S-exps, and keywords."
+  (interactive "^p")
+  (unless arg (setq arg 1))
+  (if (< arg 0) (org-backward-paragraph (- arg))
+(while (and (> arg 0) (not (eobp)))
+  (org--forward-paragraph-once)
+  (cl-decf arg))
+;; Return moves left.
+arg))
+
+(defun org-backward-paragraph ( arg)
+  "Move backward by a paragraph, or equivalent, unit.
+
+With argument ARG, do it ARG times;
+a negative argument ARG = -N means move forward N paragraphs.
+
+The function moves point between two structural
+elements (paragraphs, tables, lists, etc.).
+
+It also provides the following special moves for convenience:
+
+  - on a table or a property drawer, move to its beginning;
+  - on comment, example, export, source and verse blocks, stop
+at blank lines;
+  - skip consecutive clocks, diary S-exps, and keywords."
+  (interactive "^p")
+  (unless arg (setq arg 1))
+  (if (< arg 0) (org-forward-paragraph (- arg))
+(while (and (> arg 0) (not (bobp)))
+  (org--backward-paragraph-once)
+  (cl-decf arg))
+;; Return moves left.
+arg))
+
+(defun org--paragraph-at-point ()
+  "Return paragraph, or equivalent, element at point.
+
+Paragraph element at point is the element at point, with the
+following special cases:
+
+- treat table rows (resp. node properties) as the table
+  \(resp. property drawer) containing them.
+
+- treat plain lists with an item every line as a whole.
+
+- treat consecutive keywords, clocks, and diary-sexps as a single
+  block.
+
+Function may return a real element, or a pseudo-element with type
+`pseudo-paragraph'."
+  (let* ((e (org-element-at-point))
+	 (type (org-element-type e))
+	 ;; If we need to fake a new pseudo-element, triplet is
+	 ;;
+	 ;;   (BEG END PARENT)
+	 ;;
+	 ;; where BEG and END are element boundaries, and PARENT the
+	 ;; element containing it, or nil.
+	 (triplet
+	  (cond
+	   ((memq type '(table property-drawer))
+	(list (org-element-property :begin e)
+