emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Carsten Dominik <carsten.dominik@gmail.com>
To: Nicolas Goaziou <n.goaziou@gmail.com>
Cc: Eric Abrahamsen <eric@ericabrahamsen.net>, emacs-orgmode@gnu.org
Subject: Re: org-insert-heading rewritten from scratch
Date: Sun, 1 Sep 2013 14:04:57 +0200	[thread overview]
Message-ID: <7F861E6F-B668-4D9E-A684-37610C5BF93D@gmail.com> (raw)
In-Reply-To: <87a9jxlzsa.fsf@gmail.com>

Hi Nioclas,

thank you for the feedback.

On 1.9.2013, at 10:19, Nicolas Goaziou <n.goaziou@gmail.com> wrote:

> Hello,
> 
> Carsten Dominik <carsten.dominik@gmail.com> writes:
> 
>> On 31.8.2013, at 16:34, Nicolas Goaziou <n.goaziou@gmail.com> wrote:
> 
>>> Not really a bug, but I find some behaviour surprising: when at a the
>>> beginning of a regular text line, there is no way to create a headline
>>> just above it. In the following example:
>>> 
>>> XCursor is at "X"
>>> 
>>> Neither M-RET, C-u M-RET, C-RET nor C-u C-RET can do it. Is it intended?
>> 
>> Which behavior would you propose?  I guess you mean that, at the beginning of a line,
>> the result is so different for normal lines versus headlines?
> 
> Yes.
> 
> I never, ever, want to turn a regular text line into a headline. OTOH
> during note taking, I very often write paragraphs and, afterwards,
> decide to split them into sections.

OK, I'll go along with this.  `C-c *' if for turning a line into a headline,
M-RET for making a *new* headline.  That is logical.  Fixed now.

> 
> Moreover, AFAICT, there's no more difference between C-u M-RET, which
> meant "create headline right here" and M-RET.

C-u means: Do not ask org-insert-item, just go ahead and insert a heading.
That is supposed to be the only difference.

> 
>> The way I was thinking about the behavior at the beginning of a non-headline
>> is that it is the same as in the middle of a line:  Take the rest of the line
>> and turn it into a headline.p
>> 
>> To create a headline before a nonempty line, I use `C-o M-RET'
> 
> That's what I do. But that's not optimal and it introduces another
> problem. In the following example
> 
>  * H
> 
>  XText
> 
> I want to create a headline above "Text" and point is at "X". I use C-o
> M-RET and the latter greedily eat the blank line above, resulting in
> 
>  * H
>  * X
>  Text
> 
> as if I had typed C-p M-RET instead.
> 
> Again, I have `org-blank-before-new-entry' set to `auto' for headlines.
> Since there is no information about how many blank lines I usually want
> before headlines, I think the algorithm should trust me and do not
> remove any blank lines (see `org-list-separating-blank-lines-number').

I believe this is now better, please check.

> 
> In the same vein, in the following situation
> 
>  * H1
> 
>    Text1
> 
>  * H2
> 
>    XText2
> 
> C-o M-RET should leave blank above "Text2" because it has information
> about my preferences.

I think this is fixed as well.

> 
> Oddly, in an empty buffer, it will create a blank line above.

Fixed.

> 
>>> Also in this case, I think C-RET should create the new headline _after_
>>> the subtree, since that's its whole point anyway, AFAIU.
>> 
>> That is what happens for me.  It does not for you?
> 
> It does, sorry about the noise.
> 
>> Hmm, I do find this behavior consistent. M-RET does not change the number
>> of while lines after the current, only before, in order to either have
>> an empty line or not.
>> 
>> Which behavior would you propose?
> 
> Well same as above: I think it eats blank lines where it shouldn't. It
> the following cases:
> 
>  * H1
> 
>  ** H2
> 
>     H
>  X
> 
> and
> 
>  * H1
> 
>  * H2
> 
>    H
> 
>  X  
> 
> I don't think there's any reason for M-RET to eat blank line before
> point with either `org-blank-before-new-entry' set to `auto' or t. It
> should know that a blank line is expected before the new entry and
> therefore should create the headline at point.

Please take another look.

Thank you!

- Carsten

> 
>>> I also suggest to write function specifications as tests in test-org.el.
>> 
>> Yes, I have yet to write my first test.  Need to figure out how that
>> works.
> 
> That's simple. You can use the following pattern:
> 
>  (ert-deftest test-org/insert-heading ()
>    "Test specifications for heading insertion."
>    ;; In an empty buffer, headline should be created at its beginning,
>    ;; notwithstanding value for `org-blank-before-new-entry'.
>    (should
>     (equal "* "
>            (org-test-with-temp-text ""
>              (let ((org-blank-before-new-entry '((heading . nil))))
>                (org-insert-heading))
>              (buffer-string))))
>    (should
>     (equal "* "
>            (org-test-with-temp-text ""
>              (let ((org-blank-before-new-entry '((heading . t))))
>                (org-insert-heading))
>              (buffer-string))))
>    (should
>     (equal "* "
>            (org-test-with-temp-text ""
>              (let ((org-blank-before-new-entry '((heading . auto))))
>                (org-insert-heading))
>              (buffer-string))))
>    ;; At the end of a single headline: Create headline below, following
>    ;; `org-blank-before-new-entry' specifications.  When it is `auto',
>    ;; since there's not enough information to deduce what is expected,
>    ;; create it just below.
>    (should
>     (equal "* H\n* "
>            (org-test-with-temp-text "* H"
>              (end-of-line)
>              (let ((org-blank-before-new-entry '((heading . nil))))
>                (org-insert-heading))
>              (buffer-string))))
>    (should
>     (equal "* H\n\n* "
>            (org-test-with-temp-text "* H"
>              (end-of-line)
>              (let ((org-blank-before-new-entry '((heading . t))))
>                (org-insert-heading))
>              (buffer-string))))
>    (should
>     (equal "* H\n* "
>            (org-test-with-temp-text "* H"
>              (end-of-line)
>              (let ((org-blank-before-new-entry '((heading . auto))))
>                (org-insert-heading))
>              (buffer-string))))
>    ;; Etc.
>    )
> 
> I suggest to always put the `should' (or `should-not', `should-error')
> outside each test: it makes it easier to inspect results from partial
> evaluations.
> 
> You run each test individually with C-x C-e at the end of the `should'
> sexp. You run all tests with "make test" from "org/" directory.
> 
> 
> Regards,
> 
> -- 
> Nicolas Goaziou

  reply	other threads:[~2013-09-01 12:05 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-08  6:43 org-insert-heading rewritten from scratch Carsten Dominik
2013-08-08  7:41 ` Eric Abrahamsen
2013-08-31 14:00   ` Carsten Dominik
2013-08-31 14:34     ` Nicolas Goaziou
2013-09-01  6:13       ` Carsten Dominik
2013-09-01  8:19         ` Nicolas Goaziou
2013-09-01 12:04           ` Carsten Dominik [this message]
2013-09-01 12:25             ` Nicolas Goaziou
2013-09-03 13:16             ` Nicolas Goaziou
2013-09-03 13:25               ` Carsten Dominik
2013-09-03 13:33                 ` Carsten Dominik
2013-09-03 13:38                 ` Nicolas Goaziou
2013-09-03 13:47                   ` Carsten Dominik
2013-09-03 13:58                     ` Nicolas Goaziou
2013-09-03 14:04                       ` Carsten Dominik
2013-09-03 14:12                         ` Nicolas Goaziou
2013-09-07 10:50                         ` Nicolas Goaziou
2013-09-07 12:01                           ` Nicolas Goaziou
2013-09-01  2:38     ` Eric Abrahamsen
2013-09-01  3:11     ` Samuel Wales
2013-09-01  3:13       ` Samuel Wales
2013-09-09 16:42 ` Michael Brand
2013-09-09 19:10   ` Nicolas Goaziou
2013-09-09 20:37     ` Michael Brand
2013-09-12 20:20       ` Carsten Dominik
2013-09-12 20:52         ` Michael Brand
2013-09-12 20:58           ` Carsten Dominik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7F861E6F-B668-4D9E-A684-37610C5BF93D@gmail.com \
    --to=carsten.dominik@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=eric@ericabrahamsen.net \
    --cc=n.goaziou@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).