From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dieter Van Eessen Subject: Re: Usage of org-element api Date: Sat, 17 Jan 2015 18:02:51 +0100 Message-ID: References: <87r3uu34dm.fsf@gmx.us> <87lhl2b60y.fsf@gmx.us> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e0158a9644355b2050cdc0f76 Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:55569) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YCWm2-0001YW-GX for emacs-orgmode@gnu.org; Sat, 17 Jan 2015 12:03:00 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YCWlw-0002gl-Sj for emacs-orgmode@gnu.org; Sat, 17 Jan 2015 12:02:58 -0500 Received: from mail-yh0-x230.google.com ([2607:f8b0:4002:c01::230]:57164) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YCWlw-0002gh-Hr for emacs-orgmode@gnu.org; Sat, 17 Jan 2015 12:02:52 -0500 Received: by mail-yh0-f48.google.com with SMTP id i57so12497494yha.7 for ; Sat, 17 Jan 2015 09:02:52 -0800 (PST) In-Reply-To: <87lhl2b60y.fsf@gmx.us> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org --089e0158a9644355b2050cdc0f76 Content-Type: text/plain; charset=UTF-8 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 --089e0158a9644355b2050cdc0f76 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

Nicolas pointed me in t= he 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 tryin= g to accomplish:
The first implementation remains simple: I&#= 39;ll create 2 interactive functions,

1: Having point on headline, (= concept-expand) will call (concept-expand-headline) in which a level 1 head= line containing a link is expanded based on the content of that link. Subhe= adline becomes + plainlist, +plainlist becomes -plainlist. For example:
=
* readme
=C2=A0=C2=A0 Some text...
*= * goal
=C2=A0=C2=A0=C2=A0 Anything...
** [[*som= ething][something]] step
=C2=A0=C2=A0=C2=A0 + woot
<= div>* [[*readme][readme]] This is a readme

Expanding head= line 'this is a readme' would result in
* [[*readme][= readme]] This is a readme
=C2=A0=C2=A0=C2=A0 + goal
=
=C2=A0=C2=A0=C2=A0 + [[*something][something]] step

= 2: Having point on item, (concept-expand) will call=C2=A0 (concept-expand-i= tem) in which items get expanded
For example: expanding item = 'step results in
* [[*readme][readme]] This is a readme
=C2=A0=C2=A0 + goal
=C2=A0=C2=A0 + [[*something]= [something]] step
** [[link of choice or no link at all]] Do = this first =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 :step:
=
Now this does seem quite stupid. In a second and third imple= mentation I'll try to increase the locations where concepts may be foun= d (project, personal, system-wide), in files (based on filename and directo= ry) or subheadlines (instead of headlines), expanding subheadlines and file= s (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 y= our own or just choose to write anything. Any document always remains human= readable plain text.=C2=A0 Some concepts will always be very divers, other= s will survive the test of time and stabilize.

What do you think? Waste of time? :)

kind regards,
<= /div>
Dieter
=C2=A0
<= br>
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 interpretin= g is very
> useful ! Also didn't know there existed such thing as the org-dp l= ibrary 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&#= 39; 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-el= ements)
> is because I'd prefer not having to parse the whole buffer and sti= ll get
> the contents. The local parsing functions (org-element-at-point) and > (org-element-context) don't contain content (stated in the org-ele= ment 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 con= tents
> using the=C2=A0 :content-begin and :content-end and other properties f= rom
> (org-elemen-at-point)=C2=A0 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.=C2=A0 You can write pretty sophisticated thing= s 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 #=C2=A0 wer= e 'content' (for example in
> the output below. These don't show up in (org-element-at-point), t= hus
> explaining why they returned nil when asked for content. The
> org-element-parse-secondary-string also returns all things behind #. I= f
> this is NOT content, then how to manipulate this data (behind the #) w= hilst
> 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.= =C2=A0 You
can condition on the element under point or whatever you desire and then use the regular functions you'd otherwise use.=C2=A0 I'm probably w= rong, but it
seems as if you trying to shoot flies with canons, or however the saying goes in English.=C2=A0 Also, recall there is no such thing as wrong Org-syn= tax
(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
--089e0158a9644355b2050cdc0f76--