Hi,

First, Thierry, I think this patch fixes the second misbehavior you
observed.

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:


I looked through your comments and as always they made the patch much
better!  Thanks!

> Moreover, it can get in the way of expected M-RET behaviour, as in the
> following example
>
>   - item
>
>   | #+caption: test
>     untenrsiu

I don't know if I should do something about this case.  I guess it would
be possible, but I find it awkward when behavior $BUTTON depends not
only on not only the adjacent element, but also the previous element.

If it's important, I guess it should be toggled explicitly on by a
custom variable.

>   (point-at-bol-p (save-excursion (skip-chars-backward " \t") (bolp)))
>
> See last paragraph in `looking-back' docstring.

Thanks, that's nice.

> Also, you're not supposed to use `org-element--affiliated-re', as
> suggested by the double hyphen. If you want to tell when point is at an
> affiliated keyword, use
>
>   (< (point) (org-element-property :post-affiliated element))

That's a great tip in its own right, but actually I used
`org-element--affiliated-re' for determining if point was "in"/"on" the
keyword, as here:

       #+CAPT|ION: foo

Anyway, I changed it to fixed regexp.  Presently, it's hardcoded.
Should I introduce a new defvar or just live with the hardcodedness?

> where ELEMENT is returned by `org-element-at-point'. You can then
> extract its name with, e.g.,
>
>   (save-excursion 
>    (beginning-of-line)
>    (looking-at "#\\+\\(.+?\\):")
>    (upcase (org-match-string-no-properties 1)))

In the current patch I run this code twice, once in `org-meta-return',
once in `org-insert-keyword' (basically twice).  I would probably be
possible to pass the keyword as an argument, but I'm not sure it's worth
it.  Also, `org-insert-keyword' is not really using org-element anymore.

>> +	 (elm (org-element-at-point))
>> +	 (key (and (eq 'keyword (org-element-type elm))
>> +		   (org-element-property :key elm))))
>> +    (when key
>
> KEY is nil when at an affiliated keyword. So this function is a no-op
> on #+CAPTION: and alike.  Try it on a real caption, e.g.,
>
>   #+CAPTION: caption
>   Paragraph

Good call.  I detect this case with
(org-element-property :post-affiliated element) now.  It seems to work
in the variation of this I could come up with.  Quick testing suggest
that affiliated keywords are always on the top of an (greater) element.

>> +      (when point-at-bol-p (open-line 1)
>> +	    ;; Open-line makes sometimes ruins indention of the
>> +	    ;; previous line.
>> +	    (save-excursion (forward-line 1)
>> +			    (org-indent-line)))
>
> Don't use `open-line' at all. Insert "\n" where appropriate. Also avoid
> using `org-indent-line' since you can already know what the expected
> indentation is (i.e., by storing it earlier).

Thanks.  Actually, I think I saw `open-line' in `org-insert-headline`
and that's why I used it.  Perhaps that's another patch.
 
>> +	       ((and (eq type 'keyword)
>> +		     ;; Keyword such as LATEX, ATTR_LATEX, CAPTION, and HEADER,
>> +		     ;; LATEX_HEADER, LATEX etc. can occur multiple times.
>> +		     (let ((key (org-element-property :key element)))
>> +		       (if (member key org-element-affiliated-keywords)
>> +			   (member key org-element-multiple-keywords)
>> +			 t)))
>
> KEY cannot belong to `org-element-affiliated-keywords'.  See above.

It test that *if* it's a member of `org-element-affiliated-keywords'
then it should also be a member of `org-element-multiple-keywords'.
Anyway, your test is nicer:

> Also,
>
>   (or (not (member key org-element-affiliated-keywords))
>       (member key org-element-multiple-keywords))

Cheers,
Rasmus

-- 
Summon the Mothership!