From: Nicolas Goaziou <mail@nicolasgoaziou.fr>
To: Rasmus <rasmus@gmx.us>
Cc: tbanelwebmin@free.fr, emacs-orgmode@gnu.org
Subject: Re: [patch] extend org-meta-return to keywords
Date: Sun, 23 Nov 2014 00:20:25 +0100 [thread overview]
Message-ID: <87bnny4ybq.fsf@nicolasgoaziou.fr> (raw)
In-Reply-To: <87lhn36nq1.fsf@gmx.us> (rasmus@gmx.us's message of "Sat, 22 Nov 2014 20:26:30 +0100")
Rasmus <rasmus@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,
next prev parent reply other threads:[~2014-11-22 23:19 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-19 14:41 [Prelim. patch] extend org-meta-return to keywords Rasmus
2014-11-22 1:23 ` [patch] " Rasmus
2014-11-22 9:52 ` Nicolas Goaziou
2014-11-22 12:19 ` Rasmus Pank Roulund
2014-11-22 19:26 ` Rasmus
2014-11-22 21:57 ` Thierry Banel
2014-11-22 23:20 ` Nicolas Goaziou [this message]
2014-11-23 11:08 ` Thierry Banel
2014-11-23 16:54 ` Nicolas Goaziou
2014-11-23 17:15 ` Rasmus
2014-11-23 17:54 ` Nicolas Goaziou
2014-11-23 18:11 ` Rasmus
2014-11-23 21:13 ` Nicolas Goaziou
2014-11-23 21:54 ` Rasmus
2014-11-25 9:00 ` Nicolas Goaziou
2014-11-25 10:12 ` M-RET vs C-RET Sebastien Vauban
2014-11-25 11:09 ` Nicolas Goaziou
2014-11-25 11:16 ` Rasmus
2014-11-26 23:50 ` Nicolas Goaziou
2014-11-27 0:55 ` Rasmus
2014-11-27 9:19 ` Andreas Leha
2014-11-23 17:00 ` [patch] extend org-meta-return to keywords Rasmus
2014-11-23 17:46 ` Nicolas Goaziou
2014-11-22 13:53 ` [Prelim. patch] " Thierry Banel
2014-11-22 14:31 ` Rasmus
2014-11-22 17:09 ` Thierry Banel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87bnny4ybq.fsf@nicolasgoaziou.fr \
--to=mail@nicolasgoaziou.fr \
--cc=emacs-orgmode@gnu.org \
--cc=rasmus@gmx.us \
--cc=tbanelwebmin@free.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).