Re: [O] Outline cycling does not preserve point's position
Nicolas Goaziou n.goaz...@gmail.com writes: Should there be a pit-stop at #+END in the segment below. You can use `org-forward-element' to go there. It makes no difference if I use `org-forward-element' or `org-forward-linear-element'. The reason is clear if one examines the parser output. #+BEGIN and #+END are considered NOT as a pair but as standalone paragraphs. (paragraph () #(#+BEGIN RECEIVE ORGTBL exdoc\n 0 29 ())) (paragraph () #(#+END RECEIVE ORGTBL exdoc\n 0 27 ())) I just picked up a random worg file to take a real-world test drive. Speaking of expectations, cursor's stop points within #+BEGIN_BACKEND and #+END_BACKEND are decided based on whether the respective backend is loaded. So is the case with inlinetasks. I am just making a note of behaviour that is surprising. Surprising only if the underlying mechanics aren't sufficiently understood or known.
Re: [O] Outline cycling does not preserve point's position
Hi Nicolas, On Sat, Sep 14, 2013 at 12:29:00AM +0200, Nicolas Goaziou wrote: Hello, Carsten Dominik carsten.domi...@gmail.com writes: When the functions are done, please go ahead and commit them and bind them to C-up/down. Done. Do you think it would be nicer if org-forward-paragraph takes arguments like forward-paragraph? Would be more consistent, specially if someone writes wrappers (confession: I'm actually writing one myself). Cheers, -- Suvayu Open source is the future. It sets us free.
Re: [O] Outline cycling does not preserve point's position
On 14.9.2013, at 19:16, Suvayu Ali fatkasuvayu+li...@gmail.com wrote: Hi Nicolas, On Sat, Sep 14, 2013 at 12:29:00AM +0200, Nicolas Goaziou wrote: Hello, Carsten Dominik carsten.domi...@gmail.com writes: When the functions are done, please go ahead and commit them and bind them to C-up/down. Done. Do you think it would be nicer if org-forward-paragraph takes arguments like forward-paragraph? Would be more consistent, specially if someone writes wrappers (confession: I'm actually writing one myself). Hi, while I never use these commands with arguments, I think it would be nice if they had this ability. Regards - Carsten Cheers, -- Suvayu Open source is the future. It sets us free. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [O] Outline cycling does not preserve point's position
Hi Nicolas, thanks for these. Please see the two comments below. On Sep 11, 2013, at 10:01 PM, Nicolas Goaziou n.goaz...@gmail.com wrote: Jambunathan K kjambunat...@gmail.com writes: I am happy with whatever is the latest version. You may want to commit it. I copy here[fn:1] the current version, for the record, along with its backward counterpart. Some points are still to be discussed: 1. What to do on node properties? I think they should be covered with a single C-down, so treated like a single paragraph. 2. What to do on source blocks? At the beginning of the block (at the src line) I think it should jump over the full src block. Inside the block, it can use text-modes forward paragraph. At lease these would be my suggestions. Thank you for all your work around this issue! When the functions are done, please go ahead and commit them and bind them to C-up/down. Regards - Carsten [fn:1] Here is the code: (defun org-forward-linear-element () Move forward to beginning of next element, ignoring depth. The function implements 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, jump after it. - On a verse block, stop after each blank line. (interactive) (when (eobp) (user-error Cannot move further down)) (let* ((element (org-element-at-point)) (type (org-element-type element)) (post-affiliated (org-element-property :post-affiliated element)) (contents-begin (org-element-property :contents-begin element)) (contents-end (org-element-property :contents-end element)) (end (let ((end (org-element-property :end element)) (parent element)) (while (and (setq parent (org-element-property :parent parent)) (= (org-element-property :contents-end parent) end)) (setq end (org-element-property :end parent))) end))) (cond ((not element) (skip-chars-forward \r\t\n) (or (eobp) (beginning-of-line))) ;; On affiliated keywords, move to element's beginning. ((and post-affiliated ( (point) post-affiliated)) (goto-char post-affiliated)) ;; At a table row, move to the end of the table. ((eq type 'table-row) (goto-char (org-element-property :end (org-element-property :parent element ((eq type 'table) (goto-char end)) ((not contents-begin) (goto-char end)) ;; If current element contents are invisible, skip the ;; element altogether. ((outline-invisible-p (line-end-position)) (case type (headline (org-with-limited-levels (outline-next-visible-heading 1))) ;; At a plain list, make sure we move to the next item ;; instead of skipping the whole list. (plain-list (forward-char) (org-forward-linear-element)) (otherwise (goto-char end ((= (point) contents-end) (goto-char end)) ((= (point) contents-begin) ;; Handle special cases. In all other situations, point is ;; where it should be. (case type (paragraph (goto-char end)) ;; At a plain list, try to move to second element in ;; first item, if possible. (plain-list (end-of-line) (org-forward-linear-element)) ;; Consider blank lines as separators in verse blocks to ;; ease editing. (verse-block (beginning-of-line) (if (not (re-search-forward ^[ \t]*$ contents-end t)) (goto-char end) (skip-chars-forward \r\t\n) (if (= (point) contents-end) (goto-char contents) (beginning-of-line)) ;; When contents start on the middle of a line (e.g. in ;; items and footnote definitions), try to reach first ;; element starting after current line. (( (line-end-position) contents-begin) (end-of-line) (org-forward-linear-element)) (t (goto-char contents-begin) (defun org-backward-linear-element () Move backward to start of previous element, ignoring depth. (interactive) (when (bobp) (user-error Cannot move further up)) (let* ((element (org-element-at-point)) (type (org-element-type element)) (contents-begin (org-element-property :contents-begin element)) (contents-end (org-element-property :contents-end element)) (post-affiliated (org-element-property :post-affiliated element)) (begin (org-element-property :begin element))) (cond ((not element) (goto-char (point-min))) ((= (point) begin)
Re: [O] Outline cycling does not preserve point's position
Hello, Carsten Dominik carsten.domi...@gmail.com writes: When the functions are done, please go ahead and commit them and bind them to C-up/down. Done. Regards, -- Nicolas Goaziou
Re: [O] Outline cycling does not preserve point's position
Hello Nicolas, thank you! - Carsten On 14.9.2013, at 00:29, Nicolas Goaziou n.goaz...@gmail.com wrote: Hello, Carsten Dominik carsten.domi...@gmail.com writes: When the functions are done, please go ahead and commit them and bind them to C-up/down. Done. Regards, -- Nicolas Goaziou signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [O] Outline cycling does not preserve point's position
Hello Nicolas, Nicolas Goaziou wrote: Some points are still to be discussed: 1. What to do on node properties? I would opt for `forward-paragraph', to have something different than `next-line'. Otherwise, `C-down' and `down' would simply do the same thing. Not forbidden, but seems useless... 2. What to do on source blocks? There, I'd simply clone what happens in the real source code buffers. I've tested `C-down' in Emacs Lisp, Shell and C++ modes. In all of them, `C-down' runs the command `forward-paragraph'. So, this seems to be the obvious choice to me. Best regards, Seb -- Sebastien Vauban
Re: [O] Outline cycling does not preserve point's position
Hello, Jambunathan K kjambunat...@gmail.com writes: Nicolas Goaziou n.goaz...@gmail.com writes: Some points are still to be discussed: 1. What to do on node properties? 2. What to do on source blocks? Looks good to me. Should there be a pit-stop at #+END in the segment below. Point never ends of closing lines. It is moved to the beginning of the next element. Reminder: this is a dumb forward paragraph. You can use `org-forward-element' to go there. Regards, -- Nicolas Goaziou
Re: [O] Outline cycling does not preserve point's position
Jambunathan K kjambunat...@gmail.com writes: Suvayu Ali fatkasuvayu+li...@gmail.com writes: And I agree with you, beginning of line is a good target column. On reading Nicolas's explanation, I agree too. This is better. The decision should be based on what the user would do after doing a C-down and C-up. If *you* use C-down and C-up for persusal (as yourself say), I don't think you will use C-k immediately. I sense that you are not representing yourself in a consistent way. I don't think regular `forward-paragraph' cares about what the user do with it. It puts point at beginning of lines and that's it. `org-forward-linear-element' exists because some users want C-down with a more intense `forward-paragraph' flavour. Regards, -- Nicolas Goaziou
Re: [O] Outline cycling does not preserve point's position
Hi Jambu, On Thu, Sep 12, 2013 at 02:58:02PM +0530, Jambunathan K wrote: Nicolas Goaziou n.goaz...@gmail.com writes: Jambunathan K kjambunat...@gmail.com writes: Suvayu Ali fatkasuvayu+li...@gmail.com writes: And I agree with you, beginning of line is a good target column. On reading Nicolas's explanation, I agree too. This is better. The decision should be based on what the user would do after doing a C-down and C-up. If *you* use C-down and C-up for persusal (as yourself say), I don't think you will use C-k immediately. I sense that you are not representing yourself in a consistent way. I don't think regular `forward-paragraph' cares about what the user do with it. It puts point at beginning of lines and that's it. I am provoking Suvayu to defend himself, if that's not already clear to you :-). You are right I was not being consistent. On some thought, I still think column 0 is good. I care about the column only when I'm editing. And it is a surprise only after the first C-down, for subsequent uses my eyes get used to it. Actually I think the only time I want the cursor to retain its relative position is when I'm transposing lines/paragraphs/list items/etc. `org-forward-linear-element' exists because some users want C-down with a more intense `forward-paragraph' flavour. Let me provoke you a bit :-). What is the difference between forward and linear. Is it linear only because it stays in column 0 always? OR Is it linear because it is monotonic in how the cursor moves. I would say it is linear because it doesn't respect the element tree. If you side with latter explanation, then I would argue that this notion of linearity is no different from what is implied by forward. Btw, I have no issues if you don't want to support `org-forward-nonlinear-element'. Yes, if the command does M-m automatically at end, the cursor position will become curvilinear. Very funny :) Cheers, -- Suvayu Open source is the future. It sets us free.
Re: [O] Outline cycling does not preserve point's position
Nicolas Goaziou n.goaz...@gmail.com writes: I don't understand. Are you talking about the error message? There is no canonical C-down position, so I'm a bit confused. Put your cursor on the blank line between. Do a C-down. You will see the cursor moving and also an error reported. So, the empty line is a position where a C-down operation would land you in. It is a position from nowhere. I see some issues when the point is position some where deep inside invisible parts of the tree. For example, visit ~/src/worg/org-tutorials/org-reference-guide-es.org Get in to a state where ALL headlines are visible but none of body text is visible. Position your cursor randomly, like so. M-: (goto-char (mod (random) (point-max))) Then C-down. Within let's say 10 attempts, you will see that a headline is skipped and the cursor lands on subsequent headline. * Footnotes [fn:1] http://www.mail-archive.com/emacs-orgmode@gnu.org/msg08669.html
Re: [O] Outline cycling does not preserve point's position
Nicolas Goaziou n.goaz...@gmail.com writes:
Thanks. Take 2:
Looks good. Less surprises. Some open questions... I have no
preference one way or the other.
1. Seems to like beginning of line. May be it should do a
back-to-indentation. It is disconcerting to have cursor rest on
margins. It should actively rest on the active content.
2. Goes through the table row by row. I thought the tables are escaped
altogether!
3. In the example below, the cursor stops at #+caption, but not #+name
It also stops at ./org-mode-unicorn.png.
But it doesn't stop at the beginning of \begin{equation*}. It should
stop at first line of content for consistency.
Should it stop at each line of #+?
4. Put the cursor in a table cell and C-Down and I get This shouldn't
happen. But if I am within a table.el table cell, the table is
escaped.
5. The only exception to I like bol is while visiting footnotes where
the cursor skips past the label in to content. Should the cursor
make a stop at description term and description defintion.
6. Should it stop at each line of # line?
A simple image with caption and label
#+caption: Unicorn Logo
#+name: fig:1024
[[./org-mode-unicorn.png]]
LaTeX Fragment1
# See org-format-latex-options
The equation down below has both a caption and a label.
#+caption: Kinetic Energy
#+name: Equation:1
\begin{equation*}
e = \frac{1}{2}mv^2
\end{equation*}
[fn:XYZ] There is a link to [[http://Orgmode.org][Orgmode.org]].
Re: [O] Outline cycling does not preserve point's position
Nicolas Goaziou n.goaz...@gmail.com writes: Here's a first draft for the linear forward motion. cond: Symbol's function definition is void: org-forward-and-down-element
Re: [O] Outline cycling does not preserve point's position
I will try out your changes later in the day... Meanwhile, I don't know what pre-order means. What about `org-flat-forward-element' By, flat or linear you really mean a serialized (or stringified) version of parse-tree. i.e., An Org buffer is really a serialized representation of the parse tree. or simply (but misleading) `org-forward-paragraph'? http://en.wikipedia.org/wiki/Pre-order_traversal Even pre-order could be misleading. `org-forward-paragraph' is much better. As long as the docstring or comments mention that Org's notion of paragraph is much more nuanced or richer than a text-mode's notion of paragraph. I insist on this, only because description (even if exhaustive) could be misleading and restrictive. But an Imagery (or a mental model) is usually richer and generative.
Re: [O] Outline cycling does not preserve point's position
Jambunathan K kjambunat...@gmail.com writes: Seems to like beginning of line. For repated C-down motion, where the cursor rests within the element is immaterial. So the question is at what position the cursor should rest so that whatever becomes easy. Whatever could be: 1. editing. 2. Surgical motion with sexp commands. If sexp commands are taken up.
Re: [O] Outline cycling does not preserve point's position
Some suggestions: 1. Give a better name. Say pre-order traversal of element in the parse tree. [1] 2. Now if I M-h, C-x C-x and Deactivate mark, I essentially short-circuit the traversal of whole subtree rooted at point. There should be a convenient binding for it. Same as forward-sexp? 3. When you say Shouldn't be here, it means that point is NOT at the canonical C-down position. But you do seem to adjust it to the canonical position down below. May be you want to remove it or say something more positive like - In the middle of nowhere. Trying to get to the assembly point. New version: Couple of issues. 1. Visit the attached file. Make sure everything is visible. 2. M- 3. C-down gives a stacktrace. See below. Within the same file, 1. Move to bol of the empty line that is in Radioed Target section. That is not an empty line but has spaces. 2. C-down 3. Cursor does NOT do a stop over at References headline but skips past to References to Fuzzy Target Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil) =(2 nil) (or (eobp) (= (point) end)) (cond ((or (eobp) (= (point) end))) ((eq type (quote table-row)) (goto-char (org-element-property :end (org-element-property :parent element ((and post-affiliated ( (point) post-affiliated)) (goto-char post-affiliated)) ((eq type (quote table)) (goto-char end)) ((not contents-begin) (goto-char end)) (( (point) contents-begin) (if (not (memq type (quote (footnote-definition item (goto-char contents-begin) (end-of-line) (org-forward-linear-element))) ((= (point) contents-end) (goto-char end)) ((eq type (quote paragraph)) (goto-char end)) ((eq type (quote plain-list)) (end-of-line) (org-forward-linear-element)) ((eq type (quote verse-block)) (or (re-search-forward ^[ ]*$ contents-end t) (goto-char end))) (t (error This shouldn't happen))) (let* ((origin (point)) (element (org-element-at-point)) (type (org-element-type element)) (post-affiliated (org-element-property :post-affiliated element)) (contents-begin (org-element-property :contents-begin element)) (contents-end (org-element-property :contents-end element)) (end (let ((end (org-element-property :end element)) (parent element)) (while (and (setq parent (org-element-property :parent parent)) (= (org-element-property :contents-end parent) end)) (setq end (org-element-property :end parent))) end))) (skip-chars-forward \n) (or (eobp) (goto-char (max (line-beginning-position) origin))) (cond ((or (eobp) (= (point) end))) ((eq type (quote table-row)) (goto-char (org-element-property :end (org-element-property :parent element ((and post-affiliated ( (point) post-affiliated)) (goto-char post-affiliated)) ((eq type (quote table)) (goto-char end)) ((not contents-begin) (goto-char end)) (( (point) contents-begin) (if (not (memq type (quote (footnote-definition item (goto-char contents-begin) (end-of-line) (org-forward-linear-element))) ((= (point) contents-end) (goto-char end)) ((eq type (quote paragraph)) (goto-char end)) ((eq type (quote plain-list)) (end-of-line) (org-forward-linear-element)) ((eq type (quote verse-block)) (or (re-search-forward ^[]*$ contents-end t) (goto-char end))) (t (error This shouldn't happen))) (if (memq (org-invisible-p2) (quote (org-hide-block outline))) (progn (goto-char end org-forward-linear-element() call-interactively(org-forward-linear-element nil nil) command-execute(org-forward-linear-element) Radioed Target *** References References to Fuzzy Target This is a link to [[Fuzzy Target]].
Re: [O] Outline cycling does not preserve point's position
I am happy with whatever is the latest version. You may want to commit it.
Re: [O] Outline cycling does not preserve point's position
Suvayu Ali fatkasuvayu+li...@gmail.com writes: And I agree with you, beginning of line is a good target column. On reading Nicolas's explanation, I agree too. This is better. The decision should be based on what the user would do after doing a C-down and C-up. If *you* use C-down and C-up for persusal (as yourself say), I don't think you will use C-k immediately. I sense that you are not representing yourself in a consistent way. Speaking for myself, I ran C-down and C-up on unit test file for ODT export. It is not a representative text. It contains (deeply) indented lists and multiple headline levels etc. When the cursor is on a bol, it is difficult to get a quick feedback on where exactly the cursor is. i.e., I was forced to use hl-line-mode.
Re: [O] Outline cycling does not preserve point's position
Nicolas Goaziou n.goaz...@gmail.com writes: `org-forward-paragraph' is much better. As long as the docstring or comments mention that Org's notion of paragraph is much more nuanced or richer than a text-mode's notion of paragraph. OK. Suggestions welcome. Meanwhile, here is an updated version for the function: The invisibility + headlines getting skipped happens with this version as well. A quick examination shows there is a simple recipe. Put the cursor at bol of a level-2 headline in (*-es.org) and press C-down. The level-3 headline gets skipped altogether and point lands in level-2 headline. From Las Teclas it goes directly to ¿Qué es Org? skipping Referencias
Re: [O] Outline cycling does not preserve point's position
Nicolas Goaziou n.goaz...@gmail.com writes: Some points are still to be discussed: 1. What to do on node properties? 2. What to do on source blocks? Looks good to me. Should there be a pit-stop at #+END in the segment below. --8---cut here---start-8--- That one source table contains the documentation in the first and third column: #+BEGIN RECEIVE ORGTBL exdoc | Name| Description | |-+-| | =normx= | norm(x, \infty) | | =normb= | norm(b, \infty) | | =normA= | norm(A, \infty) | #+END RECEIVE ORGTBL exdoc --8---cut here---end---8---
Re: [O] Outline cycling does not preserve point's position
Nicolas Goaziou n.goaz...@gmail.com writes: It's a Sexp motion. Good opportunity to review the following bindings. C-c C-^ org-up-element C-c C-_ org-down-element Btw, C-M-p and C-M-n actually traverses the various org-links, footnotes and timestamps (This is not definitely intended. But could be useful.) C-M-n is easier to type than C-c C-x C-n. I am confused about the subtle difference between C-M-f and C-M-p and likewise for their backward counterparts. Hmmm... Object traversal. Now there should be a way to move between objects: Move to the next object of the same type the cursor is on.
Re: [O] Outline cycling does not preserve point's position
Nicolas Goaziou n.goaz...@gmail.com writes: Jambunathan K kjambunat...@gmail.com writes: Suvayu Ali fatkasuvayu+li...@gmail.com writes: And I agree with you, beginning of line is a good target column. On reading Nicolas's explanation, I agree too. This is better. The decision should be based on what the user would do after doing a C-down and C-up. If *you* use C-down and C-up for persusal (as yourself say), I don't think you will use C-k immediately. I sense that you are not representing yourself in a consistent way. I don't think regular `forward-paragraph' cares about what the user do with it. It puts point at beginning of lines and that's it. I am provoking Suvayu to defend himself, if that's not already clear to you :-). `org-forward-linear-element' exists because some users want C-down with a more intense `forward-paragraph' flavour. Let me provoke you a bit :-). What is the difference between forward and linear. Is it linear only because it stays in column 0 always? OR Is it linear because it is monotonic in how the cursor moves. If you side with latter explanation, then I would argue that this notion of linearity is no different from what is implied by forward. Btw, I have no issues if you don't want to support `org-forward-nonlinear-element'. Yes, if the command does M-m automatically at end, the cursor position will become curvilinear. Regards,
Re: [O] Outline cycling does not preserve point's position
Hello, Jambunathan K kjambunat...@gmail.com writes: Some suggestions: 1. Give a better name. Say pre-order traversal of element in the parse tree. [1] I don't know what pre-order means. What about `org-flat-forward-element' or simply (but misleading) `org-forward-paragraph'? 3. When you say Shouldn't be here, it means that point is NOT at the canonical C-down position. But you do seem to adjust it to the canonical position down below. May be you want to remove it or say something more positive like - In the middle of nowhere. Trying to get to the assembly point. I don't understand. Are you talking about the error message? There is no canonical C-down position, so I'm a bit confused. New version: Couple of issues. 1. Visit the attached file. Make sure everything is visible. 2. M- 3. C-down gives a stacktrace. See below. Fixed. 1. Move to bol of the empty line that is in Radioed Target section. That is not an empty line but has spaces. 2. C-down 3. Cursor does NOT do a stop over at References headline but skips past to References to Fuzzy Target That was a bug in `org-element-at-point', which is now fixed. Thank you. You'll need to update Org. New version, with comments and docstring: (defun org-forward-linear-element () Move forward to next element, ignoring depth. The function implements 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, jump after it. - On a verse block, stop after each blank line. (interactive) (when (eobp) (user-error Cannot move further down)) (let* ((origin (point)) (element (org-element-at-point)) (type (org-element-type element)) (post-affiliated (org-element-property :post-affiliated element)) (contents-begin (org-element-property :contents-begin element)) (contents-end (org-element-property :contents-end element)) (end (let ((end (org-element-property :end element)) (parent element)) (while (and (setq parent (org-element-property :parent parent)) (= (org-element-property :contents-end parent) end)) (setq end (org-element-property :end parent))) end))) (skip-chars-forward \r\t\n) (or (eobp) (goto-char (max (line-beginning-position) origin))) (cond ((or (eobp) (not end) (= (point) end))) ;; On affiliated keywords, move to element's beginning. ((and post-affiliated ( (point) post-affiliated)) (goto-char post-affiliated)) ;; At a table row, move to the end of the table. ((eq type 'table-row) (goto-char (org-element-property :end (org-element-property :parent element ((eq type 'table) (goto-char end)) ((not contents-begin) (goto-char end)) ;; If current element contents are invisible, skip the ;; element. ((outline-invisible-p (line-end-position)) (if (not (eq type 'plain-list)) (goto-char end) ;; At a plain list, make sure we move to the next item ;; instead of skipping the whole list. (forward-char) (org-forward-linear-element))) (( (point) contents-begin) (if (not (memq type '(footnote-definition item))) (goto-char contents-begin) ;; At footnote definitions and items, move to second ;; element, if any, or to next element otherwise. (end-of-line) (org-forward-linear-element))) ((= (point) contents-end) (goto-char end)) ((eq type 'paragraph) (goto-char end)) ((eq type 'plain-list) (end-of-line) (org-forward-linear-element)) ;; Verse blocks cannot contain paragraphs. Though, we ;; emulate them with blank lines separators to ease ;; editing. ((eq type 'verse-block) (or (re-search-forward ^[ \t]*$ contents-end t) (goto-char end))) (t (error This shouldn't happen) Regards, -- Nicolas Goaziou
Re: [O] Outline cycling does not preserve point's position
On Tue, Sep 10, 2013 at 11:08:23PM +0200, Carsten Dominik wrote: And I agree with you, beginning of line is a good target column. On reading Nicolas's explanation, I agree too. This is better. Cheers, -- Suvayu Open source is the future. It sets us free.
Re: [O] Outline cycling does not preserve point's position
Jambunathan K kjambunat...@gmail.com writes: `org-forward-paragraph' is much better. As long as the docstring or comments mention that Org's notion of paragraph is much more nuanced or richer than a text-mode's notion of paragraph. OK. Suggestions welcome. Meanwhile, here is an updated version for the function: (defun org-forward-linear-element () Move forward to next element, ignoring depth. The function implements 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, jump after it. - On a verse block, stop after each blank line. (interactive) (when (eobp) (user-error Cannot move further down)) (let* ((element (org-element-at-point)) (type (org-element-type element)) (post-affiliated (org-element-property :post-affiliated element)) (contents-begin (org-element-property :contents-begin element)) (contents-end (org-element-property :contents-end element)) (end (let ((end (org-element-property :end element)) (parent element)) (while (and (setq parent (org-element-property :parent parent)) (= (org-element-property :contents-end parent) end)) (setq end (org-element-property :end parent))) end))) (cond ((not element) (skip-chars-forward \r\t\n) (or (eobp) (beginning-of-line))) ;; On affiliated keywords, move to element's beginning. ((and post-affiliated ( (point) post-affiliated)) (goto-char post-affiliated)) ;; At a table row, move to the end of the table. ((eq type 'table-row) (goto-char (org-element-property :end (org-element-property :parent element ((eq type 'table) (goto-char end)) ((not contents-begin) (goto-char end)) ;; If current element contents are invisible, skip the ;; element altogether. ((outline-invisible-p (line-end-position)) (if (not (eq type 'plain-list)) (goto-char end) ;; At a plain list, make sure we move to the next item ;; instead of skipping the whole list. (forward-char) (org-forward-linear-element))) ((= (point) contents-end) (goto-char end)) ((= (point) contents-begin) ;; Handle special cases. In all other situations, point ;; is where it should be. (case type (paragraph (goto-char end)) ;; At a plain list, try to move to second element in ;; first item, if possible. (plain-list (end-of-line) (org-forward-linear-element)) ;; Consider blank lines as separators in verse blocks to ;; ease editing. (verse-block (beginning-of-line) (if (not (re-search-forward ^[ \t]*$ contents-end t)) (goto-char end) (skip-chars-forward \r\t\n) (if (= (point) contents-end) (goto-char contents) (beginning-of-line)) ;; When contents start on the middle of a line (e.g. in ;; items and footnote definitions), try to reach first ;; element starting after current line. (( (line-end-position) contents-begin) (end-of-line) (org-forward-linear-element)) (t (goto-char contents-begin) Regards, -- Nicolas Goaziou
Re: [O] Outline cycling does not preserve point's position
Jambunathan K kjambunat...@gmail.com writes: Nicolas Goaziou n.goaz...@gmail.com writes: I don't understand. Are you talking about the error message? There is no canonical C-down position, so I'm a bit confused. Put your cursor on the blank line between. Do a C-down. You will see the cursor moving and also an error reported. So, the empty line is a position where a C-down operation would land you in. It is a position from nowhere. I don't think it happens in latest version. I see some issues when the point is position some where deep inside invisible parts of the tree. For example, visit ~/src/worg/org-tutorials/org-reference-guide-es.org Get in to a state where ALL headlines are visible but none of body text is visible. Position your cursor randomly, like so. M-: (goto-char (mod (random) (point-max))) Then C-down. Within let's say 10 attempts, you will see that a headline is skipped and the cursor lands on subsequent headline. Fixed. This deserves a new version: (defun org-forward-linear-element () Move forward to next element, ignoring depth. The function implements 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, jump after it. - On a verse block, stop after each blank line. (interactive) (when (eobp) (user-error Cannot move further down)) (let* ((element (org-element-at-point)) (type (org-element-type element)) (post-affiliated (org-element-property :post-affiliated element)) (contents-begin (org-element-property :contents-begin element)) (contents-end (org-element-property :contents-end element)) (end (let ((end (org-element-property :end element)) (parent element)) (while (and (setq parent (org-element-property :parent parent)) (= (org-element-property :contents-end parent) end)) (setq end (org-element-property :end parent))) end))) (cond ((not element) (skip-chars-forward \r\t\n) (or (eobp) (beginning-of-line))) ;; On affiliated keywords, move to element's beginning. ((and post-affiliated ( (point) post-affiliated)) (goto-char post-affiliated)) ;; At a table row, move to the end of the table. ((eq type 'table-row) (goto-char (org-element-property :end (org-element-property :parent element ((eq type 'table) (goto-char end)) ((not contents-begin) (goto-char end)) ;; If current element contents are invisible, skip the ;; element altogether. ((outline-invisible-p (line-end-position)) (case type (headline (org-with-limited-levels (outline-next-visible-heading 1))) ;; At a plain list, make sure we move to the next item ;; instead of skipping the whole list. (plain-list (forward-char) (org-forward-linear-element)) (otherwise (goto-char end ((= (point) contents-end) (goto-char end)) ((= (point) contents-begin) ;; Handle special cases. In all other situations, point ;; is where it should be. (case type (paragraph (goto-char end)) ;; At a plain list, try to move to second element in ;; first item, if possible. (plain-list (end-of-line) (org-forward-linear-element)) ;; Consider blank lines as separators in verse blocks to ;; ease editing. (verse-block (beginning-of-line) (if (not (re-search-forward ^[ \t]*$ contents-end t)) (goto-char end) (skip-chars-forward \r\t\n) (if (= (point) contents-end) (goto-char contents) (beginning-of-line)) ;; When contents start on the middle of a line (e.g. in ;; items and footnote definitions), try to reach first ;; element starting after current line. (( (line-end-position) contents-begin) (end-of-line) (org-forward-linear-element)) (t (goto-char contents-begin) Regards, -- Nicolas Goaziou
Re: [O] Outline cycling does not preserve point's position
Jambunathan K kjambunat...@gmail.com writes: Hmmm... Object traversal. Now there should be a way to move between objects: Move to the next object of the same type the cursor is on. This is interesting but not really possible at the moment. Currently Elements implement successors functions, which are basically a `re-search-forward' on some hard coded regexp and a predicate to check if we're really where we think we are. So moving to the next object is easy, but moving to the previous one would be awkward. In order to allow this, we should first change the innards of Elements and split successors in two parts: 1. an association list between object types and regexp 2. a predicate Then we would be able to move either way. If there's some real interest in it, I can have a look, but not right now. Regards, -- Nicolas Goaziou
Re: [O] Outline cycling does not preserve point's position
Jambunathan K kjambunat...@gmail.com writes: I am happy with whatever is the latest version. You may want to commit it. I copy here[fn:1] the current version, for the record, along with its backward counterpart. Some points are still to be discussed: 1. What to do on node properties? 2. What to do on source blocks? [fn:1] Here is the code: (defun org-forward-linear-element () Move forward to beginning of next element, ignoring depth. The function implements 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, jump after it. - On a verse block, stop after each blank line. (interactive) (when (eobp) (user-error Cannot move further down)) (let* ((element (org-element-at-point)) (type (org-element-type element)) (post-affiliated (org-element-property :post-affiliated element)) (contents-begin (org-element-property :contents-begin element)) (contents-end (org-element-property :contents-end element)) (end (let ((end (org-element-property :end element)) (parent element)) (while (and (setq parent (org-element-property :parent parent)) (= (org-element-property :contents-end parent) end)) (setq end (org-element-property :end parent))) end))) (cond ((not element) (skip-chars-forward \r\t\n) (or (eobp) (beginning-of-line))) ;; On affiliated keywords, move to element's beginning. ((and post-affiliated ( (point) post-affiliated)) (goto-char post-affiliated)) ;; At a table row, move to the end of the table. ((eq type 'table-row) (goto-char (org-element-property :end (org-element-property :parent element ((eq type 'table) (goto-char end)) ((not contents-begin) (goto-char end)) ;; If current element contents are invisible, skip the ;; element altogether. ((outline-invisible-p (line-end-position)) (case type (headline (org-with-limited-levels (outline-next-visible-heading 1))) ;; At a plain list, make sure we move to the next item ;; instead of skipping the whole list. (plain-list (forward-char) (org-forward-linear-element)) (otherwise (goto-char end ((= (point) contents-end) (goto-char end)) ((= (point) contents-begin) ;; Handle special cases. In all other situations, point is ;; where it should be. (case type (paragraph (goto-char end)) ;; At a plain list, try to move to second element in ;; first item, if possible. (plain-list (end-of-line) (org-forward-linear-element)) ;; Consider blank lines as separators in verse blocks to ;; ease editing. (verse-block (beginning-of-line) (if (not (re-search-forward ^[ \t]*$ contents-end t)) (goto-char end) (skip-chars-forward \r\t\n) (if (= (point) contents-end) (goto-char contents) (beginning-of-line)) ;; When contents start on the middle of a line (e.g. in ;; items and footnote definitions), try to reach first ;; element starting after current line. (( (line-end-position) contents-begin) (end-of-line) (org-forward-linear-element)) (t (goto-char contents-begin) (defun org-backward-linear-element () Move backward to start of previous element, ignoring depth. (interactive) (when (bobp) (user-error Cannot move further up)) (let* ((element (org-element-at-point)) (type (org-element-type element)) (contents-begin (org-element-property :contents-begin element)) (contents-end (org-element-property :contents-end element)) (post-affiliated (org-element-property :post-affiliated element)) (begin (org-element-property :begin element))) (cond ((not element) (goto-char (point-min))) ((= (point) begin) (backward-char) (org-backward-linear-element)) ((and post-affiliated (= (point) post-affiliated)) (goto-char begin)) ((eq type 'table-row) (goto-char (org-element-property :contents-begin (org-element-property :parent element ((eq type 'table) (goto-char begin)) ((not contents-begin) (goto-char (or post-affiliated begin))) ((eq type 'paragraph) (goto-char contents-begin) ;; When at first paragraph in an item or a footnote ;; definition, move directly
Re: [O] Outline cycling does not preserve point's position
Hi Nicolas, On Wed, Sep 11, 2013 at 10:01:31PM +0200, Nicolas Goaziou wrote: Jambunathan K kjambunat...@gmail.com writes: I am happy with whatever is the latest version. You may want to commit it. I copy here[fn:1] the current version, for the record, along with its backward counterpart. Some points are still to be discussed: Looks good. I'll use it full-time for the next few days and report back. 1. What to do on node properties? You mean property drawers after headlines? I would think skipping them would seem pertinent? After all properties are usually hidden away. 2. What to do on source blocks? One thing I feel the need for is to be able to navigate longer source blocks as if they were simple text: either for perusal, or for minor editing. So my personal preference is empty lines end a paragraph. Cheers, -- Suvayu Open source is the future. It sets us free.
Re: [O] Outline cycling does not preserve point's position
On 10.9.2013, at 05:47, Carsten Dominik carsten.domi...@gmail.com wrote:
On 9.9.2013, at 17:41, Nicolas Goaziou n.goaz...@gmail.com wrote:
Carsten Dominik carsten.domi...@gmail.com writes:
It is extremely predictable if you know about the structure of an Org
document and if you think in elements.
It's a Sexp motion.
It is unexpected for a user who is used to C-arrow doing paragraph
motion. In Org, org-backward-element climbs out if a hierarchy. This
is not what happens in other modes with this command. That is what
I mean with unexpected.
OK. Do you want it to return an error if there's no element at the same
level above (or below for the forward counterpart)?
No, I guess not. Lets just leave it the way it is, but implement
alternative behavior in source code blocks. I agree with the arguments you
make below.
One more thought: What if the paragraph motion commands did use elements, but
ignored the hierarchy. So they jump to the next headline, paragraph, table,
src block, item?
I think this would feel similar to what paragraph motion does in text mode.
- Carsten
Thank you.
- Carsten
Don't get me wrong. I love the element motion stuff. But I am
satisfied for it to be available on M-{ and M-}.
I like your proposal to introduce a variable for special src behavior.
I personally would also like a variable that allows me to keep the
paragraph commands on C-arrow (because I have almost equally
convenient bindings with M-{}) - but maybe that is just me?
But `org-forward-element'/`org-backward-element' are the paragraph
commands for Org. Unlike to Text mode, contents in Org have a depth. So
it's not just about stopping at blank lines. Even stopping at blank
lines is not satisfying:
XParagraph
| a | table |
Another paragraph
A decent forward paragraph command should stop at the table here. On the
other hand, it doesn't make much sense to stop at the blank line below:
X#+begin_src emacs-lisp
;; line 1
;; line 2
#+end_src
Another paragraph
When depth isn't involved, I think that `org-forward-element' is as good
as it can get as a paragraph motion command, and far better than
`forward-paragraph' from paragraphs.el.
Regards,
--
Nicolas Goaziou
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: [O] Outline cycling does not preserve point's position
Carsten Dominik carsten.domi...@gmail.com writes:
On 10.9.2013, at 05:47, Carsten Dominik carsten.domi...@gmail.com wrote:
On 9.9.2013, at 17:41, Nicolas Goaziou n.goaz...@gmail.com wrote:
Carsten Dominik carsten.domi...@gmail.com writes:
It is extremely predictable if you know about the structure of an Org
document and if you think in elements.
It's a Sexp motion.
It is unexpected for a user who is used to C-arrow doing paragraph
motion. In Org, org-backward-element climbs out if a hierarchy. This
is not what happens in other modes with this command. That is what
I mean with unexpected.
OK. Do you want it to return an error if there's no element at the same
level above (or below for the forward counterpart)?
No, I guess not. Lets just leave it the way it is, but implement
alternative behavior in source code blocks. I agree with the arguments you
make below.
One more thought: What if the paragraph motion commands did use elements, but
ignored the hierarchy. So they jump to the next headline, paragraph, table,
src block, item?
I think this would feel similar to what paragraph motion does in text mode.
- Carsten
I once got halfway through implementing a pair of functions,
org-next-element and org-previous-element, that would do just that (and
for this very reason -- I still feel like the present behavior of M-}
and M-{ is surprising and inconvenient). org-next-element sort of went:
1. Check if org-element-at-point has a :contents-begin, and if it does,
and we're not there yet, then go to it (then skip over property drawers).
2. If it doesn't, or we're already there, call org-forward-element.
I can't remember why I didn't finish it. I think there were weird edge
cases, and org-previous-element turned out to be more complicated, and I
got distracted. I do think these would be better options for M-{ and
M-}, though...
E
Re: [O] Outline cycling does not preserve point's position
On Tue, Sep 10, 2013 at 08:03:32AM +0200, Carsten Dominik wrote: One more thought: What if the paragraph motion commands did use elements, but ignored the hierarchy. So they jump to the next headline, paragraph, table, src block, item? I think this would feel similar to what paragraph motion does in text mode. This is a great suggestion! -- Suvayu Open source is the future. It sets us free.
Re: [O] Outline cycling does not preserve point's position
On Tue, Sep 10, 2013 at 09:32:57AM +0200, Suvayu Ali wrote: On Tue, Sep 10, 2013 at 08:03:32AM +0200, Carsten Dominik wrote: One more thought: What if the paragraph motion commands did use elements, but ignored the hierarchy. So they jump to the next headline, paragraph, table, src block, item? I think this would feel similar to what paragraph motion does in text mode. This is a great suggestion! Actually it is not trivial to do this I think. It requires a lot of special handling. Effectively you have to flatten the element tree (since there are greater elements, and more fundamental elements). One might then say: aha, just use the leaf nodes. But again that does not work. A few examples: although a regular paragraph (whatever that might be :-p) could be a leaf, what about a list? Do we want traversing list items or entire lists with this new implementation? For a list with one line entries, going over entire lists might be desired, on the other hand a user might expect to traverse entries when going through a list with multi-line or multi-paragraph entries. Then there are tables, do you traverse rows (which are elements AFAIU) or entire tables; and so on. As you see this is a rather subjective issue. I have a few thoughts though. We could discuss this on the list and give a default implementation based on the consensus, but it would be nice to give an easy way to _write_ a custom paragraph motion command using elements. I am not sure what that might be though :-p. I will try to think about this some more. Cheers, -- Suvayu Open source is the future. It sets us free.
Re: [O] Outline cycling does not preserve point's position
On 10.9.2013, at 09:53, Suvayu Ali fatkasuvayu+li...@gmail.com wrote: On Tue, Sep 10, 2013 at 09:32:57AM +0200, Suvayu Ali wrote: On Tue, Sep 10, 2013 at 08:03:32AM +0200, Carsten Dominik wrote: One more thought: What if the paragraph motion commands did use elements, but ignored the hierarchy. So they jump to the next headline, paragraph, table, src block, item? I think this would feel similar to what paragraph motion does in text mode. This is a great suggestion! Actually it is not trivial to do this I think. It requires a lot of special handling. Effectively you have to flatten the element tree (since there are greater elements, and more fundamental elements). One might then say: aha, just use the leaf nodes. But again that does not work. A few examples: although a regular paragraph (whatever that might be :-p) could be a leaf, what about a list? Do we want traversing list items or entire lists with this new implementation? Individual items For a list with one line entries, going over entire lists might be desired, on the other hand a user might expect to traverse entries when going through a list with multi-line or multi-paragraph entries. Then there are tables, do you traverse rows (which are elements AFAIU) or entire tables; entire tables. and so on. I do not think this is is difficult as you are saying. Cheers - Carsten As you see this is a rather subjective issue. I have a few thoughts though. We could discuss this on the list and give a default implementation based on the consensus, but it would be nice to give an easy way to _write_ a custom paragraph motion command using elements. I am not sure what that might be though :-p. I will try to think about this some more. Cheers, -- Suvayu Open source is the future. It sets us free. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [O] Outline cycling does not preserve point's position
On 10.9.2013, at 09:58, Carsten Dominik carsten.domi...@gmail.com wrote: On 10.9.2013, at 09:53, Suvayu Ali fatkasuvayu+li...@gmail.com wrote: On Tue, Sep 10, 2013 at 09:32:57AM +0200, Suvayu Ali wrote: On Tue, Sep 10, 2013 at 08:03:32AM +0200, Carsten Dominik wrote: One more thought: What if the paragraph motion commands did use elements, but ignored the hierarchy. So they jump to the next headline, paragraph, table, src block, item? I think this would feel similar to what paragraph motion does in text mode. This is a great suggestion! Actually it is not trivial to do this I think. It requires a lot of special handling. Effectively you have to flatten the element tree (since there are greater elements, and more fundamental elements). One might then say: aha, just use the leaf nodes. But again that does not work. A few examples: although a regular paragraph (whatever that might be :-p) could be a leaf, what about a list? Do we want traversing list items or entire lists with this new implementation? Individual items For a list with one line entries, going over entire lists might be desired, on the other hand a user might expect to traverse entries when going through a list with multi-line or multi-paragraph entries. Then there are tables, do you traverse rows (which are elements AFAIU) or entire tables; entire tables. and so on. I do not think this is is difficult as you are saying. Sorry for replying to myself. I want to put a different light on this. The question is: What are people using C-arrow for? I think the main application is reasonably fast motion and selection in a *linear* way. Is this correct, or do people disagree here with me? The amazing element motion commands Nicolas has implement correspond to sexp motion, as he has said himself. Maybe C-M-f and C-M-b are the better binding match for these? - Carsten Cheers - Carsten As you see this is a rather subjective issue. I have a few thoughts though. We could discuss this on the list and give a default implementation based on the consensus, but it would be nice to give an easy way to _write_ a custom paragraph motion command using elements. I am not sure what that might be though :-p. I will try to think about this some more. Cheers, -- Suvayu Open source is the future. It sets us free. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [O] Outline cycling does not preserve point's position
On Tue, Sep 10, 2013 at 10:16:06AM +0200, Carsten Dominik wrote: The question is: What are people using C-arrow for? I think the main application is reasonably fast motion and selection in a *linear* way. Is this correct, or do people disagree here with me? I use it for navigating a buffer (not necessarily Org) linearly; i.e. go back and forth between parts I'm working on or to peruse the contents of a file. That said, often I feel the need for a navigation command which allows me to navigate the semantics of the buffer (which exactly what Nicolas's elements based navigation does). The amazing element motion commands Nicolas has implement correspond to sexp motion, as he has said himself. Maybe C-M-f and C-M-b are the better binding match for these? I think you are right here. There is a need for both. For me, I use linear navigation more commonly; so I would prefer C-up/down for linear navigation and some other bindings (like C-M-f/b, as you suggest) for the elements based motion. Cheers, -- Suvayu Open source is the future. It sets us free.
Re: [O] Outline cycling does not preserve point's position
On 10.9.2013, at 10:50, Suvayu Ali fatkasuvayu+li...@gmail.com wrote: On Tue, Sep 10, 2013 at 10:16:06AM +0200, Carsten Dominik wrote: The question is: What are people using C-arrow for? I think the main application is reasonably fast motion and selection in a *linear* way. Is this correct, or do people disagree here with me? I use it for navigating a buffer (not necessarily Org) linearly; i.e. go back and forth between parts I'm working on or to peruse the contents of a file. That said, often I feel the need for a navigation command which allows me to navigate the semantics of the buffer (which exactly what Nicolas's elements based navigation does). The amazing element motion commands Nicolas has implement correspond to sexp motion, as he has said himself. Maybe C-M-f and C-M-b are the better binding match for these? I think you are right here. There is a need for both. For me, I use linear navigation more commonly; so I would prefer C-up/down for linear navigation and some other bindings (like C-M-f/b, as you suggest) for the elements based motion. And by linear, I think we don't mean strictly linear, but on a paragraph/table/item scale, ignoring hierarchy. Cheers - Carsten Cheers, -- Suvayu Open source is the future. It sets us free. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [O] Outline cycling does not preserve point's position
On Tue, Sep 10, 2013 at 11:02:35AM +0200, Carsten Dominik wrote: On 10.9.2013, at 10:50, Suvayu Ali fatkasuvayu+li...@gmail.com wrote: On Tue, Sep 10, 2013 at 10:16:06AM +0200, Carsten Dominik wrote: The question is: What are people using C-arrow for? I think the main application is reasonably fast motion and selection in a *linear* way. Is this correct, or do people disagree here with me? I use it for navigating a buffer (not necessarily Org) linearly; i.e. go back and forth between parts I'm working on or to peruse the contents of a file. That said, often I feel the need for a navigation command which allows me to navigate the semantics of the buffer (which exactly what Nicolas's elements based navigation does). The amazing element motion commands Nicolas has implement correspond to sexp motion, as he has said himself. Maybe C-M-f and C-M-b are the better binding match for these? I think you are right here. There is a need for both. For me, I use linear navigation more commonly; so I would prefer C-up/down for linear navigation and some other bindings (like C-M-f/b, as you suggest) for the elements based motion. And by linear, I think we don't mean strictly linear, but on a paragraph/table/item scale, ignoring hierarchy. Yes. However I think I differ a bit on items. For me in a list like the following, I would call moving by paragraphs _within_ the list items linear; so, Lorem... → Cras... → Integer... → Aenean... → Pellentesque..., and so on. - Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse interdum venenatis consectetur. Nulla facilisi. Pellentesque rhoncus et est vitae lacinia. Quisque molestie justo nisl, quis dictum dui varius id. Cras scelerisque accumsan risus ut fringilla. Sed pharetra, purus sit amet suscipit sagittis, magna quam commodo ligula, vel aliquam diam lectus vel lacus. Integer congue felis at enim fermentum pellentesque. Sed eu est dictum, rhoncus nulla ac, placerat est. Pellentesque nec ultricies sapien. Morbi ac dictum dui. - Aenean vitae arcu accumsan, aliquam ipsum vitae, laoreet erat. Vivamus dapibus libero a felis dignissim, et porttitor elit vulputate. Suspendisse mattis lectus quis ante convallis pellentesque. Pellentesque malesuada massa at eros lobortis pharetra. Vestibulum et egestas mauris. Pellentesque justo magna, ultrices in faucibus viverra, hendrerit eget justo. Cheers, -- Suvayu Open source is the future. It sets us free.
Re: [O] Outline cycling does not preserve point's position
Nicolas Goaziou n.goaz...@gmail.com writes: When depth isn't involved When I am within a nested list (any arbitray position) and I C-down what should happen? When I am on an headline and I C-down, I find it disconcerting that cursor takes a far jump. There are specialized commands to jump between headlines and I don't want a 'paragraph' motion command to do anything fancy. I would much prefer that the paragraph motion commands be really dumbed down. I really wouldn't mind if paragraph motion commands lands /within/ a src block or I will be surprised if a table, IRL, is not guarded on either sides by blank lines. In the few years, that I have been on this list not a single complained that his cursor ended up within a src block. I think sexp motion commands - for example, C-M-d - can help me precisely move in to the inner sexps with little thought. This could be useful when I want to surgically move - thinkg, tree traversal - within nested lists (or nested structure) but with little effort. Bottomline: It is difficult to unlearn. But easier to learn. So, don't overload existing paragraph motion commands. Instead, introduce sexp motion and mimic what emacs-lisp-mode does. Try C-down while within a defun and see what happens.
Re: [O] Outline cycling does not preserve point's position
Hello, Suvayu Ali fatkasuvayu+li...@gmail.com writes: On Tue, Sep 10, 2013 at 11:02:35AM +0200, Carsten Dominik wrote: On 10.9.2013, at 10:50, Suvayu Ali fatkasuvayu+li...@gmail.com wrote: On Tue, Sep 10, 2013 at 10:16:06AM +0200, Carsten Dominik wrote: The question is: What are people using C-arrow for? I think the main application is reasonably fast motion and selection in a *linear* way. Is this correct, or do people disagree here with me? I use it for navigating a buffer (not necessarily Org) linearly; i.e. go back and forth between parts I'm working on or to peruse the contents of a file. That said, often I feel the need for a navigation command which allows me to navigate the semantics of the buffer (which exactly what Nicolas's elements based navigation does). The amazing element motion commands Nicolas has implement correspond to sexp motion, as he has said himself. Maybe C-M-f and C-M-b are the better binding match for these? I think you are right here. There is a need for both. For me, I use linear navigation more commonly; so I would prefer C-up/down for linear navigation and some other bindings (like C-M-f/b, as you suggest) for the elements based motion. And by linear, I think we don't mean strictly linear, but on a paragraph/table/item scale, ignoring hierarchy. Yes. However I think I differ a bit on items. For me in a list like the following, I would call moving by paragraphs _within_ the list items linear; so, Lorem... → Cras... → Integer... → Aenean... → Pellentesque..., and so on. Here's a first draft for the linear forward motion. Disclaimer: I didn't test it thoroughly. (defun org-forward-linear-element () (interactive) (when (eobp) (user-error Cannot move further down)) (let* ((origin (point)) (element (org-element-at-point)) (type (org-element-type element)) (contents-begin (org-element-property :contents-begin element)) (contents-end (org-element-property :contents-end element)) (end (let ((end (org-element-property :end element)) (parent element)) (while (and (setq parent (org-element-property :parent parent)) (= (org-element-property :contents-end parent) end)) (setq end (org-element-property :end parent))) end))) (skip-chars-forward \r\t\n) (or (eobp) (goto-char (max (line-beginning-position) origin))) (cond ((or (eobp) (= (point) end))) ((not contents-begin) (goto-char end)) (( (point) contents-begin) (cond ((eq type 'item) (end-of-line) (org-forward-and-down-element)) ((eq type 'table-row) (goto-char end)) (t (goto-char contents-begin ((= (point) contents-end) (goto-char end)) ((eq type 'paragraph) (goto-char end)) ((eq type 'plain-list) (end-of-line) (org-forward-and-down-element)) ((eq type 'table) (forward-line) (when (= (point) contents-end) (goto-char end))) ((eq type 'verse-block) (or (re-search-forward ^[ \t]*$ contents-end t) (goto-char end))) (t (error This shouldn't happen))) (when (org-invisible-p2) (goto-char end WDYT? Regards, -- Nicolas Goaziou
Re: [O] Outline cycling does not preserve point's position
Hi Nicolas, On Tue, Sep 10, 2013 at 09:48:53PM +0200, Nicolas Goaziou wrote: Suvayu Ali fatkasuvayu+li...@gmail.com writes: 1. When traversing the file header, goes one line at a time. I would expect to go to the next blank line. In the attached Org file, from somewhere on #+TITLE to the blank line before the first headline. There no such thing as a file header. I think that navigating through (regular) keywords is better, so that's a feature. Okay agreed there is nothing called file header, but would be nice to skip all the setup stuff (wherever in the file) and get to the content. 2. Skips whole source block even if there are blank lines. So can't navigate large source blocks for small edits. Try on the python source block under the first headline. I concentrate on Org syntax for now. Okay. 3. Goes through each row of a table instead of going over the table in one go. Start with cursor on From ConDBBrowser:. OK. Rows should be skipped now. Confirmed. 4. Skips the whole body under a headline when followed by link. Try putting point on the headline Important points and move; you will jump to Tagging Issues instead of the link and the list after. That was a bug. Should be fixed. Confirmed. Apart from this I think I agree with Jambunathan, it would be nice if the cursor was at some reasonable part of the line (probably at a column closest to the column it was on before). Otherwise, things look good already :). Cheers, -- Suvayu Open source is the future. It sets us free.
Re: [O] Outline cycling does not preserve point's position
Hello, Suvayu Ali fatkasuvayu+li...@gmail.com writes: 1. When traversing the file header, goes one line at a time. I would expect to go to the next blank line. In the attached Org file, from somewhere on #+TITLE to the blank line before the first headline. There no such thing as a file header. I think that navigating through (regular) keywords is better, so that's a feature. 2. Skips whole source block even if there are blank lines. So can't navigate large source blocks for small edits. Try on the python source block under the first headline. I concentrate on Org syntax for now. 3. Goes through each row of a table instead of going over the table in one go. Start with cursor on From ConDBBrowser:. OK. Rows should be skipped now. 4. Skips the whole body under a headline when followed by link. Try putting point on the headline Important points and move; you will jump to Tagging Issues instead of the link and the list after. That was a bug. Should be fixed. How can I test going backward? It is not written yet. New version: (defun org-forward-linear-element () (interactive) (when (eobp) (user-error Cannot move further down)) (let* ((origin (point)) (element (org-element-at-point)) (type (org-element-type element)) (post-affiliated (org-element-property :post-affiliated element)) (contents-begin (org-element-property :contents-begin element)) (contents-end (org-element-property :contents-end element)) (end (let ((end (org-element-property :end element)) (parent element)) (while (and (setq parent (org-element-property :parent parent)) (= (org-element-property :contents-end parent) end)) (setq end (org-element-property :end parent))) end))) (skip-chars-forward \r\t\n) (or (eobp) (goto-char (max (line-beginning-position) origin))) (cond ((or (eobp) (= (point) end))) ;; At a table row, move to the end of the table. ((eq type 'table-row) (goto-char (org-element-property :end (org-element-property :parent element ((and post-affiliated ( (point) post-affiliated)) (goto-char post-affiliated)) ((eq type 'table) (goto-char end)) ((not contents-begin) (goto-char end)) (( (point) contents-begin) (if (not (memq type '(footnote-definition item))) (goto-char contents-begin) (end-of-line) (org-forward-linear-element))) ((= (point) contents-end) (goto-char end)) ((eq type 'paragraph) (goto-char end)) ((eq type 'plain-list) (end-of-line) (org-forward-linear-element)) ((eq type 'verse-block) (or (re-search-forward ^[ \t]*$ contents-end t) (goto-char end))) (t (error This shouldn't happen))) (when (memq (org-invisible-p2) '(org-hide-block outline)) (goto-char end Regards, -- Nicolas Goaziou
Re: [O] Outline cycling does not preserve point's position
On Tue, Sep 10, 2013 at 08:58:43PM +0200, Suvayu Ali wrote: Some comments and a backtrace (I used the corrected 2nd revision): Forgot to edit that out, no backtrace. :) -- Suvayu Open source is the future. It sets us free.
Re: [O] Outline cycling does not preserve point's position
Hello, Jambunathan K kjambunat...@gmail.com writes: Nicolas Goaziou n.goaz...@gmail.com writes: Here's a first draft for the linear forward motion. cond: Symbol's function definition is void: org-forward-and-down-element Hmm. That's a silly mistake (few aren't): I changed its name as a second thought and forgot to update the recursive calls. Thanks. Take 2: (defun org-forward-linear-element () (interactive) (when (eobp) (user-error Cannot move further down)) (let* ((origin (point)) (element (org-element-at-point)) (type (org-element-type element)) (contents-begin (org-element-property :contents-begin element)) (contents-end (org-element-property :contents-end element)) (end (let ((end (org-element-property :end element)) (parent element)) (while (and (setq parent (org-element-property :parent parent)) (= (org-element-property :contents-end parent) end)) (setq end (org-element-property :end parent))) end))) (skip-chars-forward \r\t\n) (or (eobp) (goto-char (max (line-beginning-position) origin))) (cond ((or (eobp) (= (point) end))) ((not contents-begin) (goto-char end)) (( (point) contents-begin) (cond ((eq type 'item) (end-of-line) (org-forward-linear-element)) ((eq type 'table-row) (goto-char end)) (t (goto-char contents-begin ((= (point) contents-end) (goto-char end)) ((eq type 'paragraph) (goto-char end)) ((eq type 'plain-list) (end-of-line) (org-forward-linear-element)) ((eq type 'table) (forward-line) (when (= (point) contents-end) (goto-char end))) ((eq type 'verse-block) (or (re-search-forward ^[ \t]*$ contents-end t) (goto-char end))) (t (error This shouldn't happen))) (when (org-invisible-p2) (goto-char end Regards, -- Nicolas Goaziou
Re: [O] Outline cycling does not preserve point's position
Jambunathan K kjambunat...@gmail.com writes:
Nicolas Goaziou n.goaz...@gmail.com writes:
Thanks. Take 2:
Looks good. Less surprises. Some open questions... I have no
preference one way or the other.
1. Seems to like beginning of line. May be it should do a
back-to-indentation. It is disconcerting to have cursor rest on
margins. It should actively rest on the active content.
Beginning of line is better for killing and yanking. Also, it's easy to
move back to indentation with M-m.
2. Goes through the table row by row. I thought the tables are escaped
altogether!
This is not the case anymore in the new version (see my answer to
Suvayu Ali).
3. In the example below, the cursor stops at #+caption, but not #+name
It also stops at ./org-mode-unicorn.png.
Affiliated keywords are skipped altogether.
But it doesn't stop at the beginning of \begin{equation*}. It should
stop at first line of content for consistency.
Done.
Should it stop at each line of #+?
Not each line starting with #+ is an element.
4. Put the cursor in a table cell and C-Down and I get This shouldn't
happen. But if I am within a table.el table cell, the table is
escaped.
This shouldn't happen (anymore).
5. The only exception to I like bol is while visiting footnotes where
the cursor skips past the label in to content. Should the cursor
make a stop at description term and description defintion.
I removed that exception. It should behave like lists there.
Regards,
--
Nicolas Goaziou
Re: [O] Outline cycling does not preserve point's position
Suvayu Ali fatkasuvayu+li...@gmail.com writes: Okay agreed there is nothing called file header, but would be nice to skip all the setup stuff (wherever in the file) and get to the content. It's really out of the scope of this function. There are other solutions to ignore large file headers, e.g. stuff them in a drawer. Apart from this I think I agree with Jambunathan, it would be nice if the cursor was at some reasonable part of the line (probably at a column closest to the column it was on before). Otherwise, things look good already :). Usual `forward-paragraph' command doesn't do anything fancy with point. AFAICT, it always ends up at the beginning of a line. Also, as stated before, beginning of line is good for killing and yanking. Regards, -- Nicolas Goaziou
Re: [O] Outline cycling does not preserve point's position
On 10.9.2013, at 21:48, Nicolas Goaziou n.goaz...@gmail.com wrote: Hello, Suvayu Ali fatkasuvayu+li...@gmail.com writes: 1. When traversing the file header, goes one line at a time. I would expect to go to the next blank line. In the attached Org file, from somewhere on #+TITLE to the blank line before the first headline. There no such thing as a file header. I think that navigating through (regular) keywords is better, so that's a feature. 2. Skips whole source block even if there are blank lines. So can't navigate large source blocks for small edits. Try on the python source block under the first headline. I concentrate on Org syntax for now. 3. Goes through each row of a table instead of going over the table in one go. Start with cursor on From ConDBBrowser:. OK. Rows should be skipped now. 4. Skips the whole body under a headline when followed by link. Try putting point on the headline Important points and move; you will jump to Tagging Issues instead of the link and the list after. That was a bug. Should be fixed. Hi Nicolas, this looks very good already, thank you! And I agree with you, beginning of line is a good target column. Cheers - Carsten How can I test going backward? It is not written yet. New version: (defun org-forward-linear-element () (interactive) (when (eobp) (user-error Cannot move further down)) (let* ((origin (point)) (element (org-element-at-point)) (type (org-element-type element)) (post-affiliated (org-element-property :post-affiliated element)) (contents-begin (org-element-property :contents-begin element)) (contents-end (org-element-property :contents-end element)) (end (let ((end (org-element-property :end element)) (parent element)) (while (and (setq parent (org-element-property :parent parent)) (= (org-element-property :contents-end parent) end)) (setq end (org-element-property :end parent))) end))) (skip-chars-forward \r\t\n) (or (eobp) (goto-char (max (line-beginning-position) origin))) (cond ((or (eobp) (= (point) end))) ;; At a table row, move to the end of the table. ((eq type 'table-row) (goto-char (org-element-property :end (org-element-property :parent element ((and post-affiliated ( (point) post-affiliated)) (goto-char post-affiliated)) ((eq type 'table) (goto-char end)) ((not contents-begin) (goto-char end)) (( (point) contents-begin) (if (not (memq type '(footnote-definition item))) (goto-char contents-begin) (end-of-line) (org-forward-linear-element))) ((= (point) contents-end) (goto-char end)) ((eq type 'paragraph) (goto-char end)) ((eq type 'plain-list) (end-of-line) (org-forward-linear-element)) ((eq type 'verse-block) (or (re-search-forward ^[ \t]*$ contents-end t) (goto-char end))) (t (error This shouldn't happen))) (when (memq (org-invisible-p2) '(org-hide-block outline)) (goto-char end Regards, -- Nicolas Goaziou
Re: [O] Outline cycling does not preserve point's position
Hi Carsten, Carsten Dominik wrote: On 7.9.2013, at 21:28, Sebastien Vauban sva-n...@mygooglest.com wrote: Carsten Dominik wrote: On 7.9.2013, at 14:11, Sebastien Vauban sva-n...@mygooglest.com wrote: Since a little while, I've observed that point's position is not anymore preserved when cycling buffer's view with S-TAB. That's very annoying when you want to just look at your tree structure, but don't expect to land somewhere else by doing so. At the very least, we could agree that point should always be part of the entry we were on; so never go up to the *parent* entry. I have fixed this now, point does now completely stay put during global cycling. Simply perfect! And the fact that the blinking cursor stays at the end of the closest headling displayed (outline level 1, then outline level N) just shows where your point is in the real contents. Great... See http://screencast.com/t/dEbKjNlk Thanks! Best regards, Seb -- Sebastien Vauban
Re: [O] Outline cycling does not preserve point's position
Hi Carsten, Carsten Dominik wrote: - not possible anymore to use C-a or C-e in code blocks to select regions; not reported yet, though I reported similar problems with C-arrows (apparently due to a change which is now officially part of 8.1). IMO, that renders editing of code block in the original buffer much more annoying. Also this is now fixed. Regarding C-a/e, same remark: perfect! Thanks a lot for these quick fixes... Regarding C-down, is it possible to get it back working for selecting parts of code? In the video captured at http://screencast.com/t/1WjWohviyjE, we see that we can move from an heading to the next with C-down (which is a nice extra addition to the already existing speed commands), but also select subelements in a region (paragraphs or list items). Though, in the code block, C-down still looses the region... Best regards, Seb -- Sebastien Vauban
Re: [O] Outline cycling does not preserve point's position
On 9.9.2013, at 10:11, Sebastien Vauban sva-n...@mygooglest.com wrote: Hi Carsten, Carsten Dominik wrote: - not possible anymore to use C-a or C-e in code blocks to select regions; not reported yet, though I reported similar problems with C-arrows (apparently due to a change which is now officially part of 8.1). IMO, that renders editing of code block in the original buffer much more annoying. Also this is now fixed. Regarding C-a/e, same remark: perfect! Thanks a lot for these quick fixes... Regarding C-down, is it possible to get it back working for selecting parts of code? In the video captured at http://screencast.com/t/1WjWohviyjE, we see that we can move from an heading to the next with C-down (which is a nice extra addition to the already existing speed commands), but also select subelements in a region (paragraphs or list items). Though, in the code block, C-down still looses the region... Hi Sebastien, is this about loosing the active mark, or about the effect that C-down now jumps elements, not paragraphs? - Carsten Best regards, Seb -- Sebastien Vauban signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [O] Outline cycling does not preserve point's position
Hi Carsten, Carsten Dominik wrote: On 9.9.2013, at 10:11, Sebastien Vauban sva-n...@mygooglest.com wrote: Carsten Dominik wrote: - not possible anymore to use C-a or C-e in code blocks to select regions; not reported yet, though I reported similar problems with C-arrows (apparently due to a change which is now officially part of 8.1). IMO, that renders editing of code block in the original buffer much more annoying. Regarding C-down, is it possible to get it back working for selecting parts of code? In the video captured at http://screencast.com/t/1WjWohviyjE, we see that we can move from an heading to the next with C-down (which is a nice extra addition to the already existing speed commands), but also select subelements in a region (paragraphs or list items). Though, in the code block, C-down still looses the region... is this about loosing the active mark, or about the effect that C-down now jumps elements, not paragraphs? In fact, both... If we wanna still allow nice editing of code blocks, without forcing the users to use the indirect buffer, one must be able to quickly select, let's say a defvar, and copy it somewhere else; like we would do in the programming mode buffer (and like we did in the Org buffer, up to the change with C-down). Best regards, Seb -- Sebastien Vauban
Re: [O] Outline cycling does not preserve point's position
On 9.9.2013, at 10:23, Sebastien Vauban sva-n...@mygooglest.com wrote: Hi Carsten, Carsten Dominik wrote: On 9.9.2013, at 10:11, Sebastien Vauban sva-n...@mygooglest.com wrote: Carsten Dominik wrote: - not possible anymore to use C-a or C-e in code blocks to select regions; not reported yet, though I reported similar problems with C-arrows (apparently due to a change which is now officially part of 8.1). IMO, that renders editing of code block in the original buffer much more annoying. Regarding C-down, is it possible to get it back working for selecting parts of code? In the video captured at http://screencast.com/t/1WjWohviyjE, we see that we can move from an heading to the next with C-down (which is a nice extra addition to the already existing speed commands), but also select subelements in a region (paragraphs or list items). Though, in the code block, C-down still looses the region... is this about loosing the active mark, or about the effect that C-down now jumps elements, not paragraphs? In fact, both... If we wanna still allow nice editing of code blocks, without forcing the users to use the indirect buffer, one must be able to quickly select, let's say a defvar, and copy it somewhere else; like we would do in the programming mode buffer (and like we did in the Org buffer, up to the change with C-down). So maybe you just want to bing C-down to forward-paragraph again? - Carsten Best regards, Seb -- Sebastien Vauban signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [O] Outline cycling does not preserve point's position
Hi Carsten, Carsten Dominik wrote: On 9.9.2013, at 10:23, Sebastien Vauban sva-n...@mygooglest.com wrote: Carsten Dominik wrote: On 9.9.2013, at 10:11, Sebastien Vauban sva-n...@mygooglest.com wrote: Carsten Dominik wrote: - not possible anymore to use C-a or C-e in code blocks to select regions; not reported yet, though I reported similar problems with C-arrows (apparently due to a change which is now officially part of 8.1). IMO, that renders editing of code block in the original buffer much more annoying. Regarding C-down, is it possible to get it back working for selecting parts of code? In the video captured at http://screencast.com/t/1WjWohviyjE, we see that we can move from an heading to the next with C-down (which is a nice extra addition to the already existing speed commands), but also select subelements in a region (paragraphs or list items). Though, in the code block, C-down still looses the region... is this about loosing the active mark, or about the effect that C-down now jumps elements, not paragraphs? In fact, both... If we wanna still allow nice editing of code blocks, without forcing the users to use the indirect buffer, one must be able to quickly select, let's say a defvar, and copy it somewhere else; like we would do in the programming mode buffer (and like we did in the Org buffer, up to the change with C-down). So maybe you just want to bing C-down to forward-paragraph again? This is a possibility, yes, but it completely defeats the nice `C-down' add-on (when outside of code block), and I guess I won't be the only one with that problem. Of course, the nicest would be to have both: the current `C-down' for text, and the programmatic behavior when _in code blocks_. Maybe, that's not possible, though... Best regards, Seb -- Sebastien Vauban
Re: [O] Outline cycling does not preserve point's position
Hi Sébastien, Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@public.gmane.org writes: Of course, the nicest would be to have both: the current `C-down' for text, and the programmatic behavior when _in code blocks_. Maybe, that's not possible, though... We could have org-ctrldown and friends the same way we have org-shift* commands. org-ctrldown would use `org-forward-element' when on some Org element, and `forward-paragraph' elsewhere. I acknowledge binding C-down to `org-forward-element' instead of `forward-paragraph' is a bit disruptive, and maybe not ideal in all situations. -- Bastien
Re: [O] Outline cycling does not preserve point's position
On 9.9.2013, at 10:33, Sebastien Vauban sva-n...@mygooglest.com wrote: Hi Carsten, Carsten Dominik wrote: On 9.9.2013, at 10:23, Sebastien Vauban sva-n...@mygooglest.com wrote: Carsten Dominik wrote: On 9.9.2013, at 10:11, Sebastien Vauban sva-n...@mygooglest.com wrote: Carsten Dominik wrote: - not possible anymore to use C-a or C-e in code blocks to select regions; not reported yet, though I reported similar problems with C-arrows (apparently due to a change which is now officially part of 8.1). IMO, that renders editing of code block in the original buffer much more annoying. Regarding C-down, is it possible to get it back working for selecting parts of code? In the video captured at http://screencast.com/t/1WjWohviyjE, we see that we can move from an heading to the next with C-down (which is a nice extra addition to the already existing speed commands), but also select subelements in a region (paragraphs or list items). Though, in the code block, C-down still looses the region... is this about loosing the active mark, or about the effect that C-down now jumps elements, not paragraphs? In fact, both... If we wanna still allow nice editing of code blocks, without forcing the users to use the indirect buffer, one must be able to quickly select, let's say a defvar, and copy it somewhere else; like we would do in the programming mode buffer (and like we did in the Org buffer, up to the change with C-down). So maybe you just want to bing C-down to forward-paragraph again? This is a possibility, yes, but it completely defeats the nice `C-down' add-on (when outside of code block), and I guess I won't be the only one with that problem. Of course, the nicest would be to have both: the current `C-down' for text, and the programmatic behavior when _in code blocks_. Maybe, that's not possible, though... This might be difficult, but not impossible. I think this might be a question for Nicolas to answer? - Carsten Best regards, Seb -- Sebastien Vauban signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [O] Outline cycling does not preserve point's position
Hi Eric, Eric Schulte wrote: not possible anymore to cut a code snippet in two parts with C-c C-v C-d (demarcate block); already reported (without bisect), no answer; This works for me, could you report a minimal recipe for reproduction, and maybe a git bisect commit? This does work again for me in the current Org version (Org-mode version 8.1.1, release_8.1.1-7-gaecdf5). Case closed! Thanks. Best regards, Seb -- Sebastien Vauban
Re: [O] Outline cycling does not preserve point's position
On 9.9.2013, at 10:38, Bastien b...@gnu.org wrote: Hi Sébastien, Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@public.gmane.org writes: Of course, the nicest would be to have both: the current `C-down' for text, and the programmatic behavior when _in code blocks_. Maybe, that's not possible, though... We could have org-ctrldown and friends the same way we have org-shift* commands. org-ctrldown would use `org-forward-element' when on some Org element, and `forward-paragraph' elsewhere. I acknowledge binding C-down to `org-forward-element' instead of `forward-paragraph' is a bit disruptive, and maybe not ideal in all situations. Yes, it produces unexpected results. - Carsten -- Bastien signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [O] Outline cycling does not preserve point's position
Hello, Carsten Dominik carsten.domi...@gmail.com writes: On 9.9.2013, at 10:38, Bastien b...@gnu.org wrote: We could have org-ctrldown and friends the same way we have org-shift* commands. org-ctrldown would use `org-forward-element' when on some Org element, and `forward-paragraph' elsewhere. elsewhere doesn't make sense here since point is _always_ on an element (except on the first blank lines in a buffer). I acknowledge binding C-down to `org-forward-element' instead of `forward-paragraph' is a bit disruptive, and maybe not ideal in all situations. Yes, it produces unexpected results. I find it pretty predictable. May you elaborate on that? Regards, -- Nicolas Goaziou
Re: [O] Outline cycling does not preserve point's position
Hello, Carsten Dominik carsten.domi...@gmail.com writes: This might be difficult, but not impossible. I think this might be a question for Nicolas to answer? It boils down to something like: (if (eq (org-element-type (org-element-at-point)) 'src-block) ;; Do forward-paragraph according to language. ... (org-forward-element)) Though, I suggest to introduce a variable similar to `org-src-tab-acts-natively', or group both features in the same variable like `org-act-natively-on-src-block'. Regards, -- Nicolas Goaziou
Re: [O] Outline cycling does not preserve point's position
Hi Nicolas, Nicolas Goaziou n.goaz...@gmail.com writes: We could have org-ctrldown and friends the same way we have org-shift* commands. org-ctrldown would use `org-forward-element' when on some Org element, and `forward-paragraph' elsewhere. elsewhere doesn't make sense here since point is _always_ on an element (except on the first blank lines in a buffer). Right. But you got the idea: use `org-forward-element' when moving within structural elements of various kinds make sense and use `forward-paragraph' otherwise. I acknowledge binding C-down to `org-forward-element' instead of `forward-paragraph' is a bit disruptive, and maybe not ideal in all situations. Yes, it produces unexpected results. I find it pretty predictable. May you elaborate on that? It is predictable, but sometimes counter-intuitive: for example, when on the first headline, C-up will throw an error instead of moving to the top of the buffer. Also, it is predictable but not reversible: hitting C-down three times then C-up three times will not always go back to the point where the user was at the beginning. -- Bastien
Re: [O] Outline cycling does not preserve point's position
On 9.9.2013, at 13:32, Nicolas Goaziou n.goaz...@gmail.com wrote:
Hello,
Carsten Dominik carsten.domi...@gmail.com writes:
On 9.9.2013, at 10:38, Bastien b...@gnu.org wrote:
We could have org-ctrldown and friends the same way we have org-shift*
commands. org-ctrldown would use `org-forward-element' when on some
Org element, and `forward-paragraph' elsewhere.
elsewhere doesn't make sense here since point is _always_ on an element
(except on the first blank lines in a buffer).
I acknowledge binding C-down to `org-forward-element' instead of
`forward-paragraph' is a bit disruptive, and maybe not ideal in all
situations.
Yes, it produces unexpected results.
I find it pretty predictable. May you elaborate on that?
Hi Nicolas,
It is extremely predictable if you know about the structure of an Org document
and if you think in elements.
It is unexpected for a user who is used to C-arrow doing paragraph motion. In
Org, org-backward-element climbs out if a hierarchy. This is not what happens
in other modes with this command. That is what I mean with unexpected.
Don't get me wrong. I love the element motion stuff. But I am satisfied for
it to be available on M-{ and M-}.
I like your proposal to introduce a variable for special src behavior. I
personally would also like a variable that allows me to keep the paragraph
commands on C-arrow (because I have almost equally convenient bindings with
M-{}) - but maybe that is just me?
Regards
- Carsten
Re: [O] Outline cycling does not preserve point's position
It is extremely predictable if you know about the structure of an Org document and if you think in elements. Move over the smart navigation to C-M-f and friends. (info (emacs) Expressions) Programmers among us can exploit it. Org mode is essentially a text mode. The paragraph movement commands should more or less behave right like what it would do in a text-mode document. One lane for Programmers to move around. Another lane for Text-Mode folks to around. Minimal collision. Smoother traffic. Everyone happy, happy!
Re: [O] Outline cycling does not preserve point's position
Hello, Bastien b...@gnu.org writes: But you got the idea: use `org-forward-element' when moving within structural elements of various kinds make sense and use `forward-paragraph' otherwise. No, I still don't get the idea, really. It is predictable, but sometimes counter-intuitive: for example, when on the first headline, C-up will throw an error instead of moving to the top of the buffer. Sure, but otherwise it would conflict with your point below. Also, it is predictable but not reversible: hitting C-down three times then C-up three times will not always go back to the point where the user was at the beginning. You need to return an error when there is no element at the same level. IIRC, it was initially the case. But then a user complained that, in the following example, X being the point: :PROPERTIES: X:PROP1: value :END: `org-forward-element' would return an error Cannot move further down, which was difficult to understand. predictable, intuitive, reversible, pick two. Regards, -- Nicolas Goaziou
Re: [O] Outline cycling does not preserve point's position
Carsten Dominik carsten.domi...@gmail.com writes:
It is extremely predictable if you know about the structure of an Org
document and if you think in elements.
It's a Sexp motion.
It is unexpected for a user who is used to C-arrow doing paragraph
motion. In Org, org-backward-element climbs out if a hierarchy. This
is not what happens in other modes with this command. That is what
I mean with unexpected.
OK. Do you want it to return an error if there's no element at the same
level above (or below for the forward counterpart)?
Don't get me wrong. I love the element motion stuff. But I am
satisfied for it to be available on M-{ and M-}.
I like your proposal to introduce a variable for special src behavior.
I personally would also like a variable that allows me to keep the
paragraph commands on C-arrow (because I have almost equally
convenient bindings with M-{}) - but maybe that is just me?
But `org-forward-element'/`org-backward-element' are the paragraph
commands for Org. Unlike to Text mode, contents in Org have a depth. So
it's not just about stopping at blank lines. Even stopping at blank
lines is not satisfying:
XParagraph
| a | table |
Another paragraph
A decent forward paragraph command should stop at the table here. On the
other hand, it doesn't make much sense to stop at the blank line below:
X#+begin_src emacs-lisp
;; line 1
;; line 2
#+end_src
Another paragraph
When depth isn't involved, I think that `org-forward-element' is as good
as it can get as a paragraph motion command, and far better than
`forward-paragraph' from paragraphs.el.
Regards,
--
Nicolas Goaziou
Re: [O] Outline cycling does not preserve point's position
Hello Nicolas,
Nicolas Goaziou wrote:
Carsten Dominik carsten.domi...@gmail.com writes:
It is extremely predictable if you know about the structure of an Org
document and if you think in elements.
It's a Sexp motion.
It is unexpected for a user who is used to C-arrow doing paragraph
motion. In Org, org-backward-element climbs out if a hierarchy. This
is not what happens in other modes with this command. That is what
I mean with unexpected.
OK. Do you want it to return an error if there's no element at the same
level above (or below for the forward counterpart)?
Don't get me wrong. I love the element motion stuff. But I am
satisfied for it to be available on M-{ and M-}.
I like your proposal to introduce a variable for special src behavior.
I personally would also like a variable that allows me to keep the
paragraph commands on C-arrow (because I have almost equally
convenient bindings with M-{}) - but maybe that is just me?
But `org-forward-element'/`org-backward-element' are the paragraph
commands for Org. Unlike to Text mode, contents in Org have a depth. So
it's not just about stopping at blank lines. Even stopping at blank
lines is not satisfying:
XParagraph
| a | table |
Another paragraph
A decent forward paragraph command should stop at the table here. On the
other hand, it doesn't make much sense to stop at the blank line below:
X#+begin_src emacs-lisp
;; line 1
;; line 2
#+end_src
Another paragraph
When depth isn't involved, I think that `org-forward-element' is as good
as it can get as a paragraph motion command, and far better than
`forward-paragraph' from paragraphs.el.
I think everybody would be happy if what you proposed at 13:32 can be
implemented:
From: Nicolas Goaziou n.goaz...@gmail.com
Date: Mon, 09 Sep 2013 13:30:33 +0200 (6 hours, 7 minutes, 27 seconds ago)
Hello,
Carsten Dominik carsten.domi...@gmail.com writes:
This might be difficult, but not impossible.
I think this might be a question for Nicolas to answer?
It boils down to something like:
(if (eq (org-element-type (org-element-at-point)) 'src-block)
;; Do forward-paragraph according to language.
...
(org-forward-element))
Though, I suggest to introduce a variable similar to
`org-src-tab-acts-natively', or group both features in the same variable
like `org-act-natively-on-src-block'.
That way, one has `org-forward-element' for moving inside most elements of the
documents, but, inside code blocks, the behavior is similar to the one we
would get if we were editing the code in an indirect buffer.
Eventually, this behavior can be controlled, as you suggested, by a variable.
I guess this is very good, and would content most, if not all, of us!
Best regards,
Seb
--
Sebastien Vauban
Re: [O] Outline cycling does not preserve point's position
On 9.9.2013, at 17:41, Nicolas Goaziou n.goaz...@gmail.com wrote:
Carsten Dominik carsten.domi...@gmail.com writes:
It is extremely predictable if you know about the structure of an Org
document and if you think in elements.
It's a Sexp motion.
It is unexpected for a user who is used to C-arrow doing paragraph
motion. In Org, org-backward-element climbs out if a hierarchy. This
is not what happens in other modes with this command. That is what
I mean with unexpected.
OK. Do you want it to return an error if there's no element at the same
level above (or below for the forward counterpart)?
No, I guess not. Lets just leave it the way it is, but implement
alternative behavior in source code blocks. I agree with the arguments you
make below.
Thank you.
- Carsten
Don't get me wrong. I love the element motion stuff. But I am
satisfied for it to be available on M-{ and M-}.
I like your proposal to introduce a variable for special src behavior.
I personally would also like a variable that allows me to keep the
paragraph commands on C-arrow (because I have almost equally
convenient bindings with M-{}) - but maybe that is just me?
But `org-forward-element'/`org-backward-element' are the paragraph
commands for Org. Unlike to Text mode, contents in Org have a depth. So
it's not just about stopping at blank lines. Even stopping at blank
lines is not satisfying:
XParagraph
| a | table |
Another paragraph
A decent forward paragraph command should stop at the table here. On the
other hand, it doesn't make much sense to stop at the blank line below:
X#+begin_src emacs-lisp
;; line 1
;; line 2
#+end_src
Another paragraph
When depth isn't involved, I think that `org-forward-element' is as good
as it can get as a paragraph motion command, and far better than
`forward-paragraph' from paragraphs.el.
Regards,
--
Nicolas Goaziou
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: [O] Outline cycling does not preserve point's position
Hi Sebastien, On 7.9.2013, at 21:28, Sebastien Vauban sva-n...@mygooglest.com wrote: Hi Carsten, Carsten Dominik wrote: On 7.9.2013, at 14:11, Sebastien Vauban sva-n...@mygooglest.com wrote: Since a little while, I've observed that point's position is not anymore preserved when cycling buffer's view with S-TAB. Sometimes, point stays where it was (even when in the body of entries); sometimes, not. See http://screencast.com/t/1sr6Lezk: - when on the first letter of From, in that example, point's location is preserved; - when on the second letter of it, point's location is lost: new position is at the end of the level 1 parent... That's very annoying when you want to just look at your tree structure, but don't expect to land somewhere else by doing so. you say since a little while. Have you tried to bisect? Not yet. I have many Chinese plates turning at the moment, but I'll try to do that very soon. And I have other problems to report or bisect: - not possible anymore to cut a code snippet in two parts with C-c C-v C-d (demarcate block); already reported (without bisect), no answer; - not possible anymore to use C-a or C-e in code blocks to select regions; not reported yet, though I reported similar problems with C-arrows (apparently due to a change which is now officially part of 8.1). IMO, that renders editing of code block in the original buffer much more annoying. I have asked Eric about this. Or has it been like this always? In my mind, this did work before; or, at least, in (many) more cases than it now does. Also, I am not convinced that staying in invisible places is the right behavior at all. Even though I would agree that three S-TAB in a row should be a null operation. At the very least, we could agree that point should always be part of the entry we were on; so never go up to the *parent* entry. I have fixed this now, point does now completely stay put during global cycling. May be it would be better to use something like (org-display-outline-path nil t) to see where you are? I know where I am: I'm using that. But, sometimes (in fact, often), I want to see the rest of the entries (brothers, parents, etc.) in the outline view. I simply expect to land back at the entry I was at, when having cycled 3 times. Best regards, Seb -- Sebastien Vauban signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [O] Outline cycling does not preserve point's position
Not yet. I have many Chinese plates turning at the moment, but I'll try to do that very soon. And I have other problems to report or bisect: - not possible anymore to cut a code snippet in two parts with C-c C-v C-d (demarcate block); already reported (without bisect), no answer; This works for me, could you report a minimal recipe for reproduction, and maybe a git bisect commit? Thanks, -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D
Re: [O] Outline cycling does not preserve point's position
On 7.9.2013, at 21:28, Sebastien Vauban sva-n...@mygooglest.com wrote: Hi Carsten, Carsten Dominik wrote: On 7.9.2013, at 14:11, Sebastien Vauban sva-n...@mygooglest.com wrote: Since a little while, I've observed that point's position is not anymore preserved when cycling buffer's view with S-TAB. Sometimes, point stays where it was (even when in the body of entries); sometimes, not. See http://screencast.com/t/1sr6Lezk: - when on the first letter of From, in that example, point's location is preserved; - when on the second letter of it, point's location is lost: new position is at the end of the level 1 parent... That's very annoying when you want to just look at your tree structure, but don't expect to land somewhere else by doing so. you say since a little while. Have you tried to bisect? Not yet. I have many Chinese plates turning at the moment, but I'll try to do that very soon. And I have other problems to report or bisect: - not possible anymore to cut a code snippet in two parts with C-c C-v C-d (demarcate block); already reported (without bisect), no answer; - not possible anymore to use C-a or C-e in code blocks to select regions; not reported yet, though I reported similar problems with C-arrows (apparently due to a change which is now officially part of 8.1). IMO, that renders editing of code block in the original buffer much more annoying. Also this is now fixed. Regards - Carsten Or has it been like this always? In my mind, this did work before; or, at least, in (many) more cases than it now does. Also, I am not convinced that staying in invisible places is the right behavior at all. Even though I would agree that three S-TAB in a row should be a null operation. At the very least, we could agree that point should always be part of the entry we were on; so never go up to the *parent* entry. May be it would be better to use something like (org-display-outline-path nil t) to see where you are? I know where I am: I'm using that. But, sometimes (in fact, often), I want to see the rest of the entries (brothers, parents, etc.) in the outline view. I simply expect to land back at the entry I was at, when having cycled 3 times. Best regards, Seb -- Sebastien Vauban signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [O] Outline cycling does not preserve point's position
Hi Sebastien, you say since a little while. Have you tried to bisect? Or has it been like this always? Also, I am not convinced that staying in invisible places is the right behavior at all. Even though I would agree that three S-TAB in a row should be a null operation. May be it would be better to use something like (org-display-outline-path nil t) to see where you are? - Carsten On 7.9.2013, at 14:11, Sebastien Vauban sva-n...@mygooglest.com wrote: Hello, Since a little while, I've observed that point's position is not anymore preserved when cycling buffer's view with S-TAB. Sometimes, point stays where it was (even when in the body of entries); sometimes, not. See http://screencast.com/t/1sr6Lezk: - when on the first letter of From, in that example, point's location is preserved; - when on the second letter of it, point's location is lost: new position is at the end of the level 1 parent... That's very annoying when you want to just look at your tree structure, but don't expect to land somewhere else by doing so. Best regards, Seb -- Sebastien Vauban signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [O] Outline cycling does not preserve point's position
Hi Carsten, Carsten Dominik wrote: On 7.9.2013, at 14:11, Sebastien Vauban sva-n...@mygooglest.com wrote: Since a little while, I've observed that point's position is not anymore preserved when cycling buffer's view with S-TAB. Sometimes, point stays where it was (even when in the body of entries); sometimes, not. See http://screencast.com/t/1sr6Lezk: - when on the first letter of From, in that example, point's location is preserved; - when on the second letter of it, point's location is lost: new position is at the end of the level 1 parent... That's very annoying when you want to just look at your tree structure, but don't expect to land somewhere else by doing so. you say since a little while. Have you tried to bisect? Not yet. I have many Chinese plates turning at the moment, but I'll try to do that very soon. And I have other problems to report or bisect: - not possible anymore to cut a code snippet in two parts with C-c C-v C-d (demarcate block); already reported (without bisect), no answer; - not possible anymore to use C-a or C-e in code blocks to select regions; not reported yet, though I reported similar problems with C-arrows (apparently due to a change which is now officially part of 8.1). IMO, that renders editing of code block in the original buffer much more annoying. Or has it been like this always? In my mind, this did work before; or, at least, in (many) more cases than it now does. Also, I am not convinced that staying in invisible places is the right behavior at all. Even though I would agree that three S-TAB in a row should be a null operation. At the very least, we could agree that point should always be part of the entry we were on; so never go up to the *parent* entry. May be it would be better to use something like (org-display-outline-path nil t) to see where you are? I know where I am: I'm using that. But, sometimes (in fact, often), I want to see the rest of the entries (brothers, parents, etc.) in the outline view. I simply expect to land back at the entry I was at, when having cycled 3 times. Best regards, Seb -- Sebastien Vauban
