From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: org-insert-heading rewritten from scratch Date: Sun, 1 Sep 2013 14:04:57 +0200 Message-ID: <7F861E6F-B668-4D9E-A684-37610C5BF93D@gmail.com> References: <6570EFE0-1DCA-44D1-AAD9-BE51A278EE58@gmail.com> <87txj0d3y8.fsf@ericabrahamsen.net> <2CBE3492-5A45-48D6-AF3B-A81D0C322009@gmail.com> <877gf2nd2y.fsf@gmail.com> <87a9jxlzsa.fsf@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:58643) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VG6Ou-0007Wb-SS for emacs-orgmode@gnu.org; Sun, 01 Sep 2013 08:05:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VG6Om-0001hy-BT for emacs-orgmode@gnu.org; Sun, 01 Sep 2013 08:05:04 -0400 Received: from mail-ea0-x229.google.com ([2a00:1450:4013:c01::229]:44261) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VG6Om-0001hr-1E for emacs-orgmode@gnu.org; Sun, 01 Sep 2013 08:04:56 -0400 Received: by mail-ea0-f169.google.com with SMTP id k11so1800027eaj.28 for ; Sun, 01 Sep 2013 05:04:55 -0700 (PDT) In-Reply-To: <87a9jxlzsa.fsf@gmail.com> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Nicolas Goaziou Cc: Eric Abrahamsen , emacs-orgmode@gnu.org Hi Nioclas, thank you for the feedback. On 1.9.2013, at 10:19, Nicolas Goaziou wrote: > Hello, >=20 > Carsten Dominik writes: >=20 >> On 31.8.2013, at 16:34, Nicolas Goaziou wrote: >=20 >>> 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: >>>=20 >>> XCursor is at "X" >>>=20 >>> Neither M-RET, C-u M-RET, C-RET nor C-u C-RET can do it. Is it = intended? >>=20 >> 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? >=20 > Yes. >=20 > 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. >=20 > 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. >=20 >> 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 >>=20 >> To create a headline before a nonempty line, I use `C-o M-RET' >=20 > That's what I do. But that's not optimal and it introduces another > problem. In the following example >=20 > * H >=20 > XText >=20 > 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 >=20 > * H > * X > Text >=20 > as if I had typed C-p M-RET instead. >=20 > 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. >=20 > In the same vein, in the following situation >=20 > * H1 >=20 > Text1 >=20 > * H2 >=20 > XText2 >=20 > C-o M-RET should leave blank above "Text2" because it has information > about my preferences. I think this is fixed as well. >=20 > Oddly, in an empty buffer, it will create a blank line above. Fixed. >=20 >>> Also in this case, I think C-RET should create the new headline = _after_ >>> the subtree, since that's its whole point anyway, AFAIU. >>=20 >> That is what happens for me. It does not for you? >=20 > It does, sorry about the noise. >=20 >> 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. >>=20 >> Which behavior would you propose? >=20 > Well same as above: I think it eats blank lines where it shouldn't. It > the following cases: >=20 > * H1 >=20 > ** H2 >=20 > H > X >=20 > and >=20 > * H1 >=20 > * H2 >=20 > H >=20 > X =20 >=20 > 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 >=20 >>> I also suggest to write function specifications as tests in = test-org.el. >>=20 >> Yes, I have yet to write my first test. Need to figure out how that >> works. >=20 > That's simple. You can use the following pattern: >=20 > (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. > ) >=20 > 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. >=20 > 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. >=20 >=20 > Regards, >=20 > --=20 > Nicolas Goaziou