emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Thorsten Jolitz <tjolitz@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: [RFC] Org Minor Mode?
Date: Fri, 30 May 2014 10:52:49 +0200	[thread overview]
Message-ID: <87a99zlkbi.fsf@gmail.com> (raw)
In-Reply-To: 87y4xks9a7.fsf@bzg.ath.cx

Bastien <bzg@gnu.org> writes:

Hi Bastien,

> Thorsten Jolitz <tjolitz@gmail.com> writes:
>
>> This is quite low level and I haven't done anything on this level yet,
>> but it might be a way to stick with performant constant regexp strings,
>> but make them more general.
>
> That's an idea -- but the one I wanted to explore is this: instead of
> running Org functions in the current buffer (e.g., an emacs-lisp-mode
> buffer), the functions would run transparently in a temporary buffer
> before updating the current one.
>
> For example, see this code in `org-open-at-point':
>
> ;; Exception n°2: links in comments.
> ((eq type 'comment)
>  (let ((string-rear (replace-regexp-in-string
> 		     "^[ \t]*# [ \t]*" ""
> 		     (buffer-substring (point) (line-beginning-position))))
>        (string-front (buffer-substring (point) (line-end-position))))
>    (with-temp-buffer
>      (let ((org-inhibit-startup t)) (org-mode))
>      (insert value)
>      (goto-char (point-min))
>      (when (and (search-forward string-rear nil t)
> 		(search-forward string-front (line-end-position) t))
>        (goto-char (match-beginning 0))
>        (org-open-at-point)
>        (when (string= string-rear "") (forward-char))))))
>
> Obviously, this is a bit fragile and just "good enough" for this
> defun, but we could generalize it and make it more robust.

oh, I see, this must be a very recent addition, did not have this
section in my version (-> must update). 

There was a recent discussion on emacs-devel about adding a generic
`inverse-comment' function to core emacs, this would be a nice use case
(I would need that badly for outorg too, would enable it to deal with
special multi-line comments like those in C or Java). Unfortunately they
got lost in discussing how to deal with 'inline' comments, e.g. those
after a line.

If the devel's could be convinced to drop these special-case
requirements and add a robust generic core function to emacs that
inverts outcommented lines (single and multi), it would be very easy to
implement this idea in a major-mode agnostic way. Would be even better
if the function returned start and end point of the inverted region so
one could act on it somehow afterwards. 

There have been proposols and even implementations, but no conclusion
yet, maybe its worth to enter that discussion.  

This could be a solution - let many of the high-level commands check if
- org-minor-mode is active 
- they are in a comment
and if so use a temp buffer to act on the uncommented text. 

One problem is that more and more Org functions seems to get redefined
in terms of the new parser functionality, and obviously then can't be
used anymore outside org-mode. 

I realized this when looking at `org-open-at-point', e.g. this snippet:

#+begin_src emacs-lisp
  (...)    
  (let* ((context (org-element-context)) type)
    ;; On an unsupported type, check if point is contained within
    ;; a support one.
    (while (and (not (memq (setq type (org-element-type context))
                           '(headline inlinetask link footnote-definition
                                      footnote-reference timestamp)))
                (setq context (org-element-property :parent context))))
  (...)
#+end_src


Maybe this renders the whole idea of using Org functions outside of
org-mode as useless? For this snippet to work, I assume the whole
buffer must have been parsed successfully and thus must be in valid
Org syntax?

> To illustrate this way of approaching the problem of "using Org in
> non-Org buffers", consider `org-move-item-up': in an elisp comment,
> we would copy the comment paragraph at point in `with-temp-buffer',
> uncomment the buffer, call `org-move-item-up', then comment out the
> content and send it back to the original buffer as a replacement.
>
> I've not studied this idea thoroughly, and this may feels clumsy
> first, but if it spares us with the need to generalize org-mode to
> the point that org-mode is not really a separate mode anymore, it
> might be worst digging into this direction.
>
> Hope this is clearer now!

Yes, thanks! I think I get your idea of rather do some more
conditional action in some high-level user commands and keep the
frequently called low-level functions as performant as possible. 

-- 
cheers,
Thorsten

  reply	other threads:[~2014-05-30  8:53 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-10 17:55 [RFC] Org Minor Mode? Thorsten Jolitz
2014-04-10 19:19 ` Nicolas Goaziou
2014-04-11 10:07   ` Bastien
2014-04-11 17:22     ` Richard Lawrence
2014-04-13 16:28       ` Thorsten Jolitz
2014-04-19  5:37       ` Samuel Wales
2014-04-19 10:25         ` Thorsten Jolitz
2014-04-13 16:07     ` Thorsten Jolitz
2014-04-18 13:27       ` Bastien
2014-04-13 16:00   ` Thorsten Jolitz
2014-04-18 13:29     ` Bastien
2014-04-18 15:54       ` Thorsten Jolitz
2014-04-19  5:23         ` Bastien
2014-04-19 10:11           ` Thorsten Jolitz
2014-04-19 12:57             ` Bastien
2014-04-24 21:06               ` Ilya Shlyakhter
2014-04-25  8:00                 ` Thorsten Jolitz
2014-04-29 12:24                 ` Bastien
2014-04-29 18:44                   ` Ilya Shlyakhter
2014-05-06  9:06                     ` Bastien
2014-04-24 21:16   ` Ilya Shlyakhter
2014-04-25  7:49     ` Thorsten Jolitz
2014-05-06  9:20       ` Bastien
2014-05-27  9:20         ` Thorsten Jolitz
2014-05-28 21:47           ` Bastien
2014-05-28 22:19             ` Thorsten Jolitz
2014-05-29  0:01               ` Bastien
2014-05-29 17:47                 ` Thorsten Jolitz
2014-05-29 18:57                   ` Bastien
2014-05-30  8:52                     ` Thorsten Jolitz [this message]
2014-05-30 12:13                       ` Bastien
2014-05-30 13:41                         ` Thorsten Jolitz
2014-05-30 13:54                           ` Bastien
2014-05-30 14:15                             ` Thorsten Jolitz
2014-05-30 14:22                               ` Bastien
2014-05-30 14:38                                 ` Thorsten Jolitz

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=87a99zlkbi.fsf@gmail.com \
    --to=tjolitz@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    /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).