Re: [O] [patch] extend org-meta-return to keywords
Rasmus ras...@gmx.us writes: From my point of view, we can make every function tied to M-RET beyond `org-insert-headline' configurable and turned off by default. This may, however, also add confusion (why did M-RET work in X's Org but not in mine...). In this case, S-RET is a superior (as in less confusing) choice. Anyway, I assume M-RET on keywords is just a first step. So, what's the big picture? I think it would help to know the complete specifications of the M-RET you envision, as it could make more sense than the sum of its parts. Regards,
Re: [O] [patch] extend org-meta-return to keywords
Le 23/11/2014 00:20, Nicolas Goaziou a écrit : 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. I guess this is the main decision point about Rasmus's proposal. I'm not sure I understand the /structure/ argument. (Is structure about hiding blocks? Parsing org docs?). Nicolas, you have worked a lot on this topic (org-element, new drawer syntax). May be you could elaborate on this. 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. We already have M-RET for splitting a table cell (org-table-wrap-region). Should this feature be remapped to some other key-binding? Regards, Thierry
Re: [O] [patch] extend org-meta-return to keywords
Hello, Thierry Banel tbanelweb...@free.fr writes: I'm not sure I understand the /structure/ argument. (Is structure about hiding blocks? Parsing org docs?). Nicolas, you have worked a lot on this topic (org-element, new drawer syntax). May be you could elaborate on this. M-RET, C-RET are the major mean to insert headlines (the structure of the document) and items, which are very important features. I'm pretty sure these bindings are in muscle memory of many Org users. Asking them to take into account context before using M-RET is a big downside. I think, on the contrary, that it should do its job without exception. We already have M-RET for splitting a table cell (org-table-wrap-region). Should this feature be remapped to some other key-binding? Binding `org-table-wrap-region' to an important keybinding such as M-RET is wrong IMO. Anyway, that's not the subject here, which is to avoid adding more clutter to M-RET. Let's not make it another C-c C-c. Regards, -- Nicolas Goaziou
Re: [O] [patch] extend org-meta-return to keywords
Hi, Thanks for the comments. This email is long (sorry); fortunately there are many blank lines. . . Thierry Banel tbanelweb...@free.fr writes: If not, maybe it would be better to keep the oriGiNaL cASe. Yeah, fixed. Nicolas Goaziou m...@nicolasgoaziou.fr writes: 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. I see it differently. I see M-RET as a function that magically adds more of what is adjacent to point. I—obviously—think what I propose is better than what we have now. Let's go through the current functionality. * Example 1: #+LATEX_HEADER: foo Click M-RET anywhere above (line-beginning-position) and you get something like #+LATEX * _HEADER: foo This is nonsense. Click M-RET at (line-beginning-position) and you get * #+LATEX_HEADER: foo This is nonsense. * Example 2 - s #+LATEX_HEADER: foo % no space between ^ and #. Same as example 2. * Next case - s #+LATEX_HEADER: foo % space between ^ and # M-RET at a position greater than (line-beginning-position) yields something like - s #+LATEX - _HEADER: tes This is nonsense. M-RET at (line-beginning-position) will yield - s - | ← that's point #+LATEX_HEADER: foo % space between ^ and # Thus far this is the only sensible result that we'd loose with the patch. If this is a great loss (rather than a bug in the current implementation) this can be dealt with, though it adds complexity to the meaning of M-RET (since it's a function of the previous element rather than the adjacent one). * Example 4 - s #+LATEX_HEADER: foo % three spaces This works like example 1. 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. IMO the examples above show that M-RET fails at doing this in a sensible manner is all but one case above. The case where it does not fail requires (i) that the keyword is not at the beginning of the line and (ii) that the use has point before the keyword. I don't care strongly about this feature—It's just check that point is not at bol in `org-meta-return'. In fact I would be happy to go further. One also get nonsense result doing M-RET on #+begin_src lines and probably elsewhere. 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. I moved the check to a separate function, `org-looking-at-repeatable-keyword-p'. There are now the following issues: 1. it's called twice: once in org-meta-return and once in org-insert-keyword. I'm not sure if it's possible to emit a signal to avoid the second check somehow... Perhaps the performance-loss is such that we should not worry about it. 2. The name is terrible. I'm also not sure if this function should reside in org.el. Same for the regexp. Thoughts? Some comments follow: Thanks for these! + (indention + (buffer-substring + (line-beginning-position) + (save-excursion + (beginning-of-line) + (skip-chars-forward \t) + (point Another option: (ind (org-get-indentation)) Cool. I really need to internalize to look for org-prefixed functions! + (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. Yeah, I see your point. Casual testing suggest it's more solid now albeit there's now the double check as outlined above. + (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 :)) [...] I think end-of-keyword should be bound after KEY is checked to avoid errors. Since there's now a check before entering the function I guess this should be safe. Still I added extra checks, that I'm pretty sure are unnecessary. I'd be happy to remove these. —Rasmus -- Don't
Re: [O] [patch] extend org-meta-return to keywords
Hi, Nicolas Goaziou m...@nicolasgoaziou.fr writes: Thierry Banel tbanelweb...@free.fr writes: I'm not sure I understand the /structure/ argument. (Is structure about hiding blocks? Parsing org docs?). Nicolas, you have worked a lot on this topic (org-element, new drawer syntax). May be you could elaborate on this. M-RET, C-RET are the major mean to insert headlines (the structure of the document) and items, which are very important features. I'm pretty sure these bindings are in muscle memory of many Org users. Asking them to take into account context before using M-RET is a big downside. I think, on the contrary, that it should do its job without exception. I don't find it complicated at all. . . It's DWIM! We already have M-RET for splitting a table cell (org-table-wrap-region). Should this feature be remapped to some other key-binding? Binding `org-table-wrap-region' to an important keybinding such as M-RET is wrong IMO. Anyway, that's not the subject here, which is to avoid adding more clutter to M-RET. Let's not make it another C-c C-c. The fact that `org-table-wrap-region' is bound to M-RET is the reason I'd bind `org-insert-keyword' to M-RET. . . Anyway, do we have /another/ key that these two functions could be migrated to? Cheers, Rasmus -- And I faced endless streams of vendor-approved Ikea furniture. . .
Re: [O] [patch] extend org-meta-return to keywords
Rasmus ras...@gmx.us writes: I see it differently. I see M-RET as a function that magically adds more of what is adjacent to point. Your definition is fuzzy: * Headline [lots of text] -- M-RET here will insert a headline, which is by no mean adjacent to point. I—obviously—think what I propose is better than what we have now. Let's go through the current functionality. In this case I value simplicity over complexity (or smartness, whatever you call it). Anyone, including newcomers, should be able to use M-RET without knowing about (affiliated) keywords, or be bothered with them. IMO, it /is/ sensible to insert a headline (or an item) without trying to outsmart the user. Also, headlines are first-class citizens in Org. Keybindings acting on them shouldn't be bothered with other citizens. Regards,
Re: [O] [patch] extend org-meta-return to keywords
Rasmus ras...@gmx.us writes: I don't find it complicated at all. . . It's DWIM! I understand your DWIM argument. But we're talking about one of the most central keybindings in Org, much like C-c C-c. Except I do not consider C-c C-c as a usability model. Also, C-c C-c is not really dedicated to headlines. The fact that `org-table-wrap-region' is bound to M-RET is the reason I'd bind `org-insert-keyword' to M-RET. . . I really don't understand the reason behind binding `org-table-wrap-region' (how often do you use that?) on M-RET. Anyway, do we have /another/ key that these two functions could be migrated to? There is `org-table-copy-down' bound to S-RET. The idea is similar. Regards,
Re: [O] [patch] extend org-meta-return to keywords
Hi,
Nicolas Goaziou m...@nicolasgoaziou.fr writes:
I—obviously—think what I propose is better than what we have now. Let's
go through the current functionality.
In this case I value simplicity over complexity (or smartness,
whatever you call it). Anyone, including newcomers, should be able to
use M-RET without knowing about (affiliated) keywords, or be bothered
with them.
Newcomers ain't stupid. My guess is it would feel very intuitive to
be able to repeat e.g. LATEX_HEADINGs.
Also, headlines are first-class citizens in Org. Keybindings acting on
them shouldn't be bothered with other citizens.
But * #+LATEX_HEADER: \usepackage{foo} or whatever is possibly the
most useless headline in the history of Org. . .
I don't find it complicated at all. . . It's DWIM!
I understand your DWIM argument. But we're talking about one of the most
central keybindings in Org, much like C-c C-c. Except I do not consider
C-c C-c as a usability model. Also, C-c C-c is not really dedicated to
headlines.
I guess I mainly use C-c C-c for tags. I don't know what else it's used
for (without looking at the code). . .
The fact that `org-table-wrap-region' is bound to M-RET is the reason
I'd bind `org-insert-keyword' to M-RET. . .
I really don't understand the reason behind binding
`org-table-wrap-region'
(how often do you use that?) on M-RET.
Very rarely. I obviously use M-RET all the time for items and
headlines. `org-table-wrap-region' seems like a solution looking for a
problem.
Anyway, do we have /another/ key that these two functions could be
migrated to?
There is `org-table-copy-down' bound to S-RET. The idea is similar.
That seems less crowded. In fact it doesn't work outside of tables ATM.
Still, I think overload M-RET is more intuitive, but I fear our opinions
will fail to converge.
—Rasmus
--
Lasciate ogni speranza o voi che entrate: siete nella mani di'machellaio
Re: [O] [patch] extend org-meta-return to keywords
Rasmus ras...@gmx.us writes:
Newcomers ain't stupid.
I never said that.
However, here is an historical data point. SCHEDULED, DEADLINE and
CLOSED keywords, aka planning info, are not included as properties in
properties drawer so newcomers do not encounter invisible contents for
such basic tasks.
This is the same logic here.
My guess is it would feel very intuitive to be able to repeat e.g.
LATEX_HEADINGs.
M-RET is a good fit for almost anything. That's all the problem.
As far as UI goes, I think we should prevent some keybindings from being
context sensitive. This is particularly true for those related to core
features (outliner, agenda, TODO list). Why ? Because basic Org features
should ideally be very simple to use.
Org is mostly geared towards power users. The feature you're
implementing is also for power users. However, /any/ user should be
able to master the core features in 5 minutes.
But * #+LATEX_HEADER: \usepackage{foo} or whatever is possibly the
most useless headline in the history of Org. . .
Who knows? It depends on the context, on the next commands (e.g. C-o)...
Hitting B key at
#+|LATEX_HEADER: \usepackage{foo}
is as useless. Nevertheless, I suppose you don't want to bind B key to
something else than `org-self-insert-command' here.
Still, I think overload M-RET is more intuitive,
Intuitiveness is in the eye of the beholder... Maybe some users will
not find intuitive that M-RET usually inserts a headline... unless it is
in a plain list, in which case it inserts an item... oh wait, if it is
at a keyword it can duplicate it... but, wait, it doesn't happen for
every keyword... ah! and in source blocks it...
but I fear our opinions will fail to converge.
If you want to convince me, show me that this binding makes Org simpler
to use, or, at least, equally simple. Until then, I stand on my ground.
Regards,
Re: [O] [patch] extend org-meta-return to keywords
Hi, Nicolas Goaziou m...@nicolasgoaziou.fr writes: Still, I think overload M-RET is more intuitive, Intuitiveness is in the eye of the beholder... Clearly. Maybe some users will not find intuitive that M-RET usually inserts a headline... unless it is in a plain list, in which case it inserts an item... oh wait, if it is at a keyword it can duplicate it... but, wait, it doesn't happen for every keyword... ah! and in source blocks it... Not to forget tables. . . but I fear our opinions will fail to converge. If you want to convince me, show me that this binding makes Org simpler to use, or, at least, equally simple. Until then, I stand on my ground. This is a Sisyphean task. Even if a number of participants of this ML would chime in, we would still not know whether it would confuse or benefit new users. From my point of view, we can make every function tied to M-RET beyond `org-insert-headline' configurable and turned off by default. This may, however, also add confusion (why did M-RET work in X's Org but not in mine...). At this point, I doubt I can add novel, useful inputs to the discussion. Cheers, Rasmus -- And I faced endless streams of vendor-approved Ikea furniture. . .
Re: [O] [patch] extend org-meta-return to keywords
Hello, Rasmus ras...@gmx.us writes: Attached is a new version of the patch that will respect the variables that also govern `org-insert-headline'. It's smarter and preserves the layout better. Thanks for the patch. However there are already mechanisms to complete keywords faster (e.g., M-TAB, yasnippet). Of course, yours is more efficient, but also very specific. It makes sense on very few keywords. I have no strong opinion here, but I don't think it is general enough to go into core. Moreover, it can get in the way of expected M-RET behaviour, as in the following example - item | #+caption: test untenrsiu where M-RET is expected to insert an item. Anyway, some comments follow. + (point-at-bol-p (looking-back ^[[:space:]]*)) (point-at-bol-p (save-excursion (skip-chars-backward \t) (bolp))) See last paragraph in `looking-back' docstring. + (end-of-keyword + (save-excursion + (beginning-of-line) + (search-forward-regexp Nitpick: `re-search-forward' + org-element--affiliated-re (point-at-eol) t) Nitpick: `line-end-position' 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)) 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))) + (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 + (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). + (unless may-split (end-of-line)) + (unless point-at-bol-p + (when ( (point) end-of-keyword) + (goto-char end-of-keyword)) + (insert \n)) + (insert (format #+%s: key)) + (org-indent-line Ditto. Use stored indentation. +((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. Also, (or (not (member key org-element-affiliated-keywords)) (member key org-element-multiple-keywords)) Regards, -- Nicolas Goaziou
Re: [O] [patch] extend org-meta-return to keywords
Hi,
Thanks for the comments.
Nicolas Goaziou m...@nicolasgoaziou.fr writes:
Rasmus ras...@gmx.us writes:
Attached is a new version of the patch that will respect the variables
that also govern `org-insert-headline'. It's smarter and preserves the
layout better.
Thanks for the patch. However there are already mechanisms to complete
keywords faster (e.g., M-TAB, yasnippet).
Personally, I never figured out how to use yasnippet. M-TAB is for
completion of new lines, not for continuation of ongoing work.
Of course, yours is more efficient, but also very specific.
So say you do
#+LATEX_HEADER: \usepackage{biblatex}
Now you need to add a bib resource. It's nice to quickly be able to get
a new #+LATEX_HEADER-line. It's specific, but it's meant as a
continuation of the M-RET logic.
It makes sense on very few keywords. I have no strong opinion here,
but I don't think it is general enough to go into core.
OK. Hopefully some more people will chime in so we can make an educated
guess.
Moreover, it can get in the way of expected M-RET behaviour, as in the
following example
- item
| #+caption: test
untenrsiu
where M-RET is expected to insert an item.
Sure. . . I'm not sure expected behavior is what I'd like here. But
that's the initial point, I guess.
Anyway, some comments follow.
Thanks for those.
Cheers,
Rasmus
--
The second rule of Fight Club is: You do not talk about Fight Club
Re: [O] [patch] extend org-meta-return to keywords
Hi, First, Thierry, I think this patch fixes the second misbehavior you observed. Nicolas Goaziou m...@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! From 2e70cf7c7df61eebcc10e48077c5212d9015900e Mon Sep 17 00:00:00 2001 From: rasmus ras...@gmx.us Date: Wed, 19 Nov 2014 15:39:19 +0100 Subject: [PATCH] org.el: Add keyword-support to M-RET * org.el (org-insert-keyword): New function. (org-meta-return): May call `org-insert-keyword'. (org-M-RET-may-split-line): Add keyword. --- lisp/org.el | 91 + 1 file changed, 80 insertions(+), 11 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 6ab13f4..3405ab4 100755 --- a/lisp/org.el +++ b/lisp/org.el @@ -1601,6 +1601,7 @@ contexts. Valid contexts are: headline when creating a new headline item when creating a new item table in a table field +keyword when creating a new keyword default the value to be used for all contexts not explicitly customized :group 'org-structure @@ -1614,6 +1615,7 @@ default the value to be used for all contexts not explicitly (const headline) (const item) (const table) + (const keyword) (const default)) (boolean) @@ -7725,8 +7727,8 @@ split the line and create a new headline with the text in the current line after point \(see
Re: [O] [patch] extend org-meta-return to keywords
Le 22/11/2014 20:26, Rasmus a écrit : Hi, First, Thierry, I think this patch fixes the second misbehavior you observed. Fixed! I was wondering, is there any reason why the new inserted keyword is UPPERCASED? If not, maybe it would be better to keep the oriGiNaL cASe.
Re: [O] [patch] extend org-meta-return to keywords
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,
