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.ees...@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 <ras...@gmx.us> wrote:
>
>> Hi Dieter,
>>
>> Dieter Van Eessen <dieter.van.ees...@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
org-concept.el
Description: Binary data
