Rasmus <ras...@gmx.us> writes: >> 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.
M-RET, is, first and foremost, an important keybinding for editing the /structure/ of the document. The behaviour you want to add has nothing to do with structure. As a consequence, I'm not sure it should go with M-RET, and if it does, I'm pretty sure it should not override the main purpose of the binding. Inserting headlines, and possibly items, is much more important than duplicating keywords. >> 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 You need to check if either element has `keyword' type or if you're on an affiliated keyword. If you ignore this, like you did, you end up introducing false positives like #+begin: |something ... #+end: > Anyway, I changed it to fixed regexp. Presently, it's hardcoded. > Should I introduce a new defvar or just live with the hardcodedness? A defconst is preferable, IMO. > Also, `org-insert-keyword' is not really using org-element anymore. It should since you make it interactive and can, therefore, be called on its own. >>> + ((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'. I was pointing out that your test was always false. Anyway, it doesn't matter anymore since you changed that part. Some comments follow: > + (indention > + (buffer-substring > + (line-beginning-position) > + (save-excursion > + (beginning-of-line) > + (skip-chars-forward " \t") > + (point)))) Another option: (ind (org-get-indentation)) Then, after inserting "\n", (org-indent-line-to ind) > + (keyword-re "#\\+\\(.+?\\):") > + (key (save-excursion (beginning-of-line) > + (skip-chars-forward " \t") > + (looking-at keyword-re) > + (upcase (org-match-string-no-properties 1)))) As discussed above, this is too fragile. You need to duplicate the checks done in `org-meta-return' or refactor the code. > + (end-of-keyword (save-excursion > + (beginning-of-line) > + (re-search-forward keyword-re (line-end-position) t) > + (point)))) (end-of-keyword (save-excursion (beginning-of-line) (search-forward ":")) > + (when key I think end-of-keyword should be bound after KEY is checked to avoid errors. > + (insert "\n")) > + (insert (concat indention (format "#+%s: " key))) (insert indentation (format "#+%s: " key)) > + ((and > + (or (eq type 'keyword) > + (< (point) (org-element-property :post-affiliated > element))) > + (let ((key (save-excursion > + (beginning-of-line) > + (skip-chars-forward " \t") > + (and (looking-at "#\\+\\(.+?\\):") "^[ \t]*#\\+\\(.+?\\):" avoids the `skip-chars-forward' part. > + (upcase (org-match-string-no-properties > 1)))))) Actually, you don't need `upcase' if you use `member-ignore-case' below. > + (and key > + (or (not (member key org-element-affiliated-keywords)) > + (member key org-element-multiple-keywords))))) See above. Regards,
