Re: [O] New headline after no content (empty headline)

[Bastien]

Hi Brady,

Brady Trainor <address@hidden> writes:

> So, I started trying to read the org.el file. I thought I had found 
> the "offending" line, (my L7614,) finding 
>
>         ;; If we insert after content, move there and clean up whitespace
>         (when respect-content
>           (org-end-of-subtree nil t)
>           (skip-chars-backward " \r\n")
>           (and (looking-at "[ \t]+") (replace-match ""))
>           (unless (eobp) (forward-char 1))
>           (when (looking-at "^\\*")
>             (unless (bobp) (backward-char 1))
>             (insert "\n")))
>
> I thought to try substituting "[ \t]+" with "[\t]+", and byte compiled the 
> file. But this did not solve.

The idea behind (and (looking-at "[ \t]+") (replace-match "")) is to
remove whitespaces after the entry.  It generally happens with
non-empty headlines, so it's the correct move here.

What you want is not to remove only tabs, but to prevent removing
whitespaces when the string before the point matches "^\*+" -- so
that's what I did with this patch:

http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=afffe03d

> So, I never like to ask a question without having an answer myself, so I 
> learned a little more enough about keyboard macros to generate the 
> following somewhat simple and natural solution (natural in that it uses a 
> similar unused key chord): 
>
>     (fset 'new-starred-line
>           [return ?* ? ])
>     (global-set-key (kbd "C-M-<return>") 'new-starred-line)
>
>
> So, what is my question? What am I lacking in my .el package reading 
> skills? Why did my first fix not work? As a newb program hacker, am I 
> approaching this right? Maybe best case is to understand more of the entire 
> org.el file, but was trying to hack just enough. What would you have done? 

I don't have a general rule, but what I found out over time is this:
when struggling to find a solution, it is very easy to forget about
the problem.  I try to discipline myself (1) stating the problem by
writing it (when the OP did not find the problem itself or didn't
write it in a way I can understand) and (2) limiting the solution
to the problem.  It sounds like simple common sense, but experience
shows common sense in this area is not that common.

Getting familiar with the code is also the only to understand what
the program does by reading the code, and to make sure your solution
does not have side-effects.

HTH,

-- 
 Bastien