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 ** :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 wrote: > >> Hi Dieter, >> >> Dieter Van Eessen 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