From: Nicolas Goaziou <n.goaziou@gmail.com>
To: Carsten Dominik <carsten.dominik@gmail.com>
Cc: Eric Abrahamsen <eric@ericabrahamsen.net>, emacs-orgmode@gnu.org
Subject: Re: org-insert-heading rewritten from scratch
Date: Sun, 01 Sep 2013 10:19:33 +0200 [thread overview]
Message-ID: <87a9jxlzsa.fsf@gmail.com> (raw)
In-Reply-To: <D4510BC1-43FE-4F06-A948-770DECD4639D@gmail.com> (Carsten Dominik's message of "Sun, 1 Sep 2013 08:13:47 +0200")
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.
Moreover, AFAICT, there's no more difference between C-u M-RET, which
meant "create headline right here" and M-RET.
> 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').
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.
Oddly, in an empty buffer, it will create a blank line above.
>> 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.
>> 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
next prev parent reply other threads:[~2013-09-01 8:19 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 [this message]
2013-09-01 12:04 ` Carsten Dominik
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=87a9jxlzsa.fsf@gmail.com \
--to=n.goaziou@gmail.com \
--cc=carsten.dominik@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=eric@ericabrahamsen.net \
/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).