* Difficulties using adopt-elements and interpret-data
@ 2015-01-19 10:39 Dieter Van Eessen
0 siblings, 0 replies; only message in thread
From: Dieter Van Eessen @ 2015-01-19 10:39 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1.1: Type: text/plain, Size: 6110 bytes --]
Hello,
I've been working on what I've explained earlier (cf. below). For the
expansion of a (single) item to a subheadline I currently got the headline
with appropriate properties. But I'm facing problems on adding it to the
ast of the headline containing the item.
Would it be possible to take a look and point me in the right direction?
The file is in attachment, it contains quite some junk, but only 2
functions are involved atm: the interactive org-concept-expand which calls
org-concept--expand-item. Stuck in the latter, part 3 integration.
Basically what I need as result (first implementation) is
INPUT
* elementA
+ itemA
+ itemB
When point is on itemB, calling org-concept-expand will result in
OUTPUT
* elementA
+ itemA
+ itemB
** <name or default> :itemB:
Thanks,
Dieter
On Sat, Jan 17, 2015 at 6:02 PM, Dieter Van Eessen <
dieter.van.eessen@gmail.com> wrote:
> Hello,
>
> Nicolas pointed me in the right direction! It was so obvious that I looked
> right passed it:
> Should just create a temp buffer with the text (headline+plainlist+text) i
> wish to parse, then parse that temp-buffer... so obvious, sorry for the
> waste of time.
>
> Just to give an idea of what I'm trying to accomplish:
> The first implementation remains simple: I'll create 2 interactive
> functions,
>
> 1: Having point on headline, (concept-expand) will call
> (concept-expand-headline) in which a level 1 headline containing a link is
> expanded based on the content of that link. Subheadline becomes +
> plainlist, +plainlist becomes -plainlist. For example:
> * readme
> Some text...
> ** goal
> Anything...
> ** [[*something][something]] step
> + woot
> * [[*readme][readme]] This is a readme
>
> Expanding headline 'this is a readme' would result in
> * [[*readme][readme]] This is a readme
> + goal
> + [[*something][something]] step
>
> 2: Having point on item, (concept-expand) will call (concept-expand-item)
> in which items get expanded
> For example: expanding item 'step results in
> * [[*readme][readme]] This is a readme
> + goal
> + [[*something][something]] step
> ** [[link of choice or no link at all]] Do this first :step:
>
> Now this does seem quite stupid. In a second and third implementation I'll
> try to increase the locations where concepts may be found (project,
> personal, system-wide), in files (based on filename and directory) or
> subheadlines (instead of headlines), expanding subheadlines and files
> (based on filename and directory),...
>
> I'm kind of looking for a way to create some abstractions/concepts,
> without ever being tied to a static model/template. People must never be
> forced to use the system. It remains a free choice whether you use
> concepts, create your own or just choose to write anything. Any document
> always remains human readable plain text. Some concepts will always be
> very divers, others will survive the test of time and stabilize.
>
> What do you think? Waste of time? :)
>
> kind regards,
> Dieter
>
>
> On Sat, Jan 17, 2015 at 1:33 AM, Rasmus <rasmus@gmx.us> wrote:
>
>> Hi Dieter,
>>
>> Dieter Van Eessen <dieter.van.eessen@gmail.com> writes:
>>
>> > Hello Rasmus,
>> >
>> > Thank you for the fast reply, the link you've given on interpreting is
>> very
>> > useful ! Also didn't know there existed such thing as the org-dp
>> library to
>> > manipulate org-elements, I'll sure check it out.
>>
>> I don't know org-dp myself, but Thorsten posts here regularly.
>>
>> > More about question number 3:
>> >>> 3) How can the output of (org-element-parse-secondary-string ...) be
>> >>> used.
>> >>> When I give a heading and bit of text as input (output of
>> >>> buffer-substring), it looks like it returns the 'content' of the
>> region.
>> >>> Though I can't seem to use it anyway as 'CONTENT' for the functions
>> >>> requiring this.
>> >
>> > The reason I've tried this (and the internal
>> org-element--parse-elements)
>> > is because I'd prefer not having to parse the whole buffer and still get
>> > the contents. The local parsing functions (org-element-at-point) and
>> > (org-element-context) don't contain content (stated in the org-element
>> api,
>> > also tried it).
>>
>> But all elements contain :begin and :end and most :contens-begin
>> and :contents-end (maybe sans an 's').
>>
>> > Now I'm not sure IF I really NEED it? I could actually get the contents
>> > using the :content-begin and :content-end and other properties from
>> > (org-elemen-at-point) BUT I don't know the exact syntax the content
>> should
>> > have and how to merge it with the element-list I get from
>> > (org-element-at-point) before feeding it to the
>> org-element-interpret-data.
>>
>> Maybe it would be easier if you state plainly what your desired goal is?
>> It's all a bit abstract. You can write pretty sophisticated things using
>> just (org-element-at-point) (e.g. I have a function that escapes
>> *math-su{b,per}script* on double space at appropriate places).
>>
>> > [...]
>> > At first I thought that the things behind # were 'content' (for
>> example in
>> > the output below. These don't show up in (org-element-at-point), thus
>> > explaining why they returned nil when asked for content. The
>> > org-element-parse-secondary-string also returns all things behind #. If
>> > this is NOT content, then how to manipulate this data (behind the #)
>> whilst
>> > assuring that syntax and position remains valid for
>> > org-element-interpret-data to understand?
>>
>> If you want to manipulate the buffer text use the great functions. You
>> can condition on the element under point or whatever you desire and then
>> use the regular functions you'd otherwise use. I'm probably wrong, but it
>> seems as if you trying to shoot flies with canons, or however the saying
>> goes in English. Also, recall there is no such thing as wrong Org-syntax
>> (but there is unexpected outcomes).
>>
>> Check Org.el if you want.
>>
>> Cheers,
>> Rasmus
>>
>> --
>> Not everything that goes around comes back around, you know
>>
>>
>>
>
>
> --
> gtz,
> Dieter VE
>
--
gtz,
Dieter VE
[-- Attachment #1.2: Type: text/html, Size: 8153 bytes --]
[-- Attachment #2: org-concept.el --]
[-- Type: application/octet-stream, Size: 9655 bytes --]
;;; org-concept.el
;;
;; - Start with simple implementation of org-concept-expand:
;; - Only valid links (to elements) within 1 file
;; - Assumo only valid content (don't check)
;; - Assume only using top level headlines and plainlists
;; - On headlines: deflate:
;; - ** becomes +
;; - + becomes -
;; - On plain list: inflate:
;; - item becomes **
(defun org-concept-expand (element-at-point)
"Expand the current element by searching the requested template"
;; interactive function: need
;; - org-element on the current line (get link within,
;; name and tag, start with just link and name)
;; - (upper-level element), not sure if required
;; -location of org-element
;; -the current buffer
(interactive
(let (element-at-point)
(forward-char) ;to make sure you have item (no plain-list)
(setq element-at-point (org-element-at-point))
(list element-at-point)))
;; FOCUS ON AREA: Use mark-subtree and narrow-region
(org-up-heading-safe)
(let ((headline-up (org-element-at-point)))
(narrow-to-region
(org-element-property ':begin headline-up)
(org-element-property ':end headline-up)))
(goto-char (+ 1 (org-element-property ':begin element-at-point)))
;; SPLIT FUNCTIONALITY:
;; If element is a top level headline, start org-concept-expand-headline. Elif element is plain-list or item, start org-concept-expand-item
(if (eq 'headline (org-element-type element-at-point))
(org-concept--expand-headline (element-at-point))
(if (org-in-item-p)
;;Hard one, as only first + is plain list, rest is eighter item, paragragh or something else depending on position. Since only expansion of top level plain list items is allowed, we can safely keep on using the parent, UNTILL it's parent is the plain-list type.
(progn
(setq parentElementType (org-element-type (org-element-property ':parent element-at-point)))
(while (not (eq 'plain-list parentElementType))
(setq element-at-point (org-element-property ':parent element-at-point))
(setq parentElementType (org-element-type (org-element-property ':parent element-at-point))))
(org-concept--expand-item element-at-point))
(message "'org-concept-expand' requires position on heading or list item ")))
(widen)
)
(global-set-key "\C-c\C-x\C-e" 'org-concept-expand)
(defun org-concept--expand-item (item)
;; First implementation
;; - only valid for top level items
;; - only with links pointing to elements within the file
;;
;; ! If you are working in the tree and need to return to item:
;; (goto-char (+ (org-element-property ':begin item) 1))
;; Otherwise you get the plain-list or a paragraph
;; Returns t if expansion was success, nil otherwise
(setq ast (org-element-parse-buffer))
(setq parent (org-element-contents ast))
;; ! to get property use (car parent),
;; double braces around content
;; PART 1: creating subheading, based on owning headline
;; 1.1: Creating dummy headline
;; (been looking at org-dp, but don't like it...)
(goto-char (point-max))
(newline)
(goto-char (-(point-max) 1))
(insert "* ")
(setq item-as-headline (org-element-headline-parser (point) 1))
(delete-region (- (point-max) 3) (point-max))
;; 1.2: Modify properties
(let (level tags title)
(setq level (+ 1 (org-element-property ':level (car parent))))
;; (buffer-substring) also takes into account text properties, like font. I only need pure characters.
(setq tags (buffer-substring-no-properties
(org-element-property ':contents-begin item)
(- (org-element-property ':contents-end item) 1)))
(setq title "TODO: ask title, default value: <tag>-number")
(org-element-put-property item-as-headline ':level level)
(org-element-put-property item-as-headline ':tags tags)
(org-element-put-property item-as-headline ':title title)
(org-element-put-property item-as-headline ':raw-value title))
;; PART 2: modifying item (eg. counter)
;; (Not in first implementation)
;; PART 3: integration
;;(debug)
;; Just checkingPH
;;(org-element-interpret-data ast) ;; for comparison
;;(org-element-headline-interpreter item-as-headline nil)
;;(setq test (org-element-adopt-elements parent item-as-headline))
;; (org-element-interpret-data test)
;; (org-element-set-contents ast test)
;; (org-element-interpret-data ast)
; (org-element-adopt-elements parent newhl)
)
(defun org-concept--expand-headline (point)
;; First implementation
;; - only valid for top level headlines
;; - only with links pointing to elements within the file
;; Returns t if expansion was success, nil otherwise
(catch 'notYetImplemented
;; Project in initial phase: TODO's all around
(if (not (eq '1 (org-element-property ':level element)))
(throw 'notYetImplemented (message "notYetImplemented: Expanding sub-headlines")))
(if (org-element-property ':tag element)
(throw 'notYetImplemented (message "notYetImplemented: Reverse checkup of tags")))
;; (debug)
;; (message (prin1-to-string element))
;; Output of org-element-at-point
; On a headline(headline (:raw-value "Brainstorming" :begin 6018 :end 8762 :pre-blank 0 :hiddenp outline :contents-begin 6034 :contents-end 8752 :level 1 :priority nil :tags nil :todo-keyword nil :todo-type nil :post-blank 3 :footnote-section-p nil :archivedp nil :commentedp nil :quotedp nil :CATEGORY "CREATE" :title "Brainstorming")))
;; PART 1: Get concepts defining element
;; Part 1.1: Creating a property list with elements in link.
;; (setq org-concept-plist (org-concept-split-line))
;; Part 1.2: Get a list containing the org-elements of concepts
;; PART 2:
))
(defun org-concept--split-line (line)
;; Checks the current line if:
;; - Links are available
;; - Links are valid
;; - (TODO) Create reverse link for TAG
;; - (MAYBE) Put restriction on name: Not more than
;; 1 sentence or maximum number of characters.
;;
;; If no link found: call org-concept-check which searches link based on plain text.
;;
;; Returns:
;; - plist (item, values) for every element
;; - Nill if any problem is detected
;; - Final implementation should NEVER return nill, but call the apropriate functions to solve the problem.
(message "TODO: Line-tester")
'nil
)
(defun org-concept--check ()
;; Functionalities:
;; If there is no link: check if plain text concept exists and add link. Ask if org-concept-expand is required. If there is link: check if the expansion is still correct compared to link (+ recursive for headline + all items)
(message "TODO: checker")
'nil
)
;; Output of org-element-at-point
; On a headline(headline (:raw-value "Brainstorming" :begin 6018 :end 8762 :pre-blank 0 :hiddenp outline :contents-begin 6034 :contents-end 8752 :level 1 :priority nil :tags nil :todo-keyword nil :todo-type nil :post-blank 3 :footnote-section-p nil :archivedp nil :commentedp nil :quotedp nil :CATEGORY "CREATE" :title "Brainstorming")))
;; Output of org-element-at-point
; On a list item ("Line 95" (plain-list (:type unordered :begin 6084 :end 6272 :contents-begin 6084 :contents-end 6272 :structure ((6084 0 "- " nil nil nil 6125) (6125 0 "- " nil nil nil 6160) (6160 0 "- " nil nil nil 6272) (6225 2 "- " nil nil nil 6272)) :post-blank 0 :post-affiliated 6084 :parent nil)))
(defun test (subject)
(interactive
(let (subject)
(setq subject (org-element-at-point))
(list subject)))
(debug)
(setq element-at-point subject)
)
(debug)
(setq content (org-element-contents (org-element-parse-buffer)))
;; Cant really use
; (setq element-lineage (org-element-lineage subject))
;; OK to use
;; (setq element-current (org-element--current-element (org-element-property ':begin subject)))
;; (setq element-string (buffer-substring (org-element-property ':begin subject) (org-element-property ':end subject)))
;; (setq element-parseSecString (org-element-parse-secondary-string element-string '(link ...)))
;; (setq greater-element-parse (org-element-item-parser (org-element-property ':begin subject) (org-list-struct)))
;; (debug)
;; (setq element-parse (org-element--parse-elements (org-element-property ':begin (org-element-at-point)) (org-element-property ':end (org-element-at-point)) 'first-section nil 'element nil nil))
;;(message (prin1-to-string element-at-point))
;;(message (prin1-to-string element-lineage))
;; (message (prin1-to-string element-current))
(message (prin1-to-string content))
;;(message (prin1-to-string greater-element-parse))
;; (message (prin1-to-string contents))
)
;; example
(defun triangle-recursively-bugged (number)
"Return sum of numbers 1 through NUMBER inclusive.Uses recursion."
(if (= number 1)
1
(+ number
(triangle-recursively-bugged
(1= number))))) ; Error here.
(triangle-recursively-bugged 3)
;; Messing with org-list, plain lists
;; (progn (
;; (setq structure (org-list-struct)))))))
;; (setq item (org-in-item-p))
;; (setq struct (org-list-struct))
;; (setq prevs (org-list-prevs-alist struct))
;; (setq parents (org-list-parents-alist struct))
;; (message (prin1-to-string item))
;; (message (prin1-to-string struct))
;; (message (prin1-to-string prevs))
;; (message (prin1-to-string parents))
;; (message (prin1-to-string (org-list-get-top-point struct)))
;; (message (prin1-to-string (org-list-get-parent item struct parents)))
;; (message (prin1-to-string (org-list-get-list-begin item struct prevs))))
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2015-01-19 10:39 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-01-19 10:39 Difficulties using adopt-elements and interpret-data Dieter Van Eessen
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).