parsing options

parsing options

[Eric Abrahamsen]

Is there a generic function for parsing options lines at the top of a
file? I'd like to use some custom lines to set certain file-specific
variables, and haven't quite figured out the best way to do that.

It looks like org-set-regexps-and-options does that when you open a new
file, but that's a bear of a function, and doesn't provide for setting
your own options (or at least doesn't appear to, my eyes crossed while
reading it).

Is there any smaller function available for our own minor modes or use
cases? Should I just use regexp search? If there isn't anything like
this, would one be useful (something that either found an option value
or returned a default, or found an alist of option values, or found an
alist of values for options matching a regexp, etc)?

Thanks,
Eric

Re: parsing options

[Bastien]

Hi Eric,

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Is there a generic function for parsing options lines at the top of a
> file? 

See `org-infile-export-plist'.

> I'd like to use some custom lines to set certain file-specific
> variables, and haven't quite figured out the best way to do that.
>
> It looks like org-set-regexps-and-options does that when you open a new
> file, but that's a bear of a function, and doesn't provide for setting
> your own options (or at least doesn't appear to, my eyes crossed while
> reading it).

`org-set-regexps-and-options' is used to set options keywords and
regexp, so depending on what you exactly want to do, you may have 
to add your own options keywords here...

> Is there any smaller function available for our own minor modes or use
> cases? Should I just use regexp search? If there isn't anything like
> this, would one be useful (something that either found an option value
> or returned a default, or found an alist of option values, or found an
> alist of values for options matching a regexp, etc)?

Mhh..  hard to help you more without knowing more precisely what you
want to achieve.  Perhaps an example would help.

Thanks!

-- 
 Bastien

Re: parsing options

[Eric Abrahamsen]

On Wed, Aug 17 2011, Bastien wrote:

> Hi Eric,
>
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Is there a generic function for parsing options lines at the top of a
>> file? 
>
> See `org-infile-export-plist'.
>
>> I'd like to use some custom lines to set certain file-specific
>> variables, and haven't quite figured out the best way to do that.
>>
>> It looks like org-set-regexps-and-options does that when you open a new
>> file, but that's a bear of a function, and doesn't provide for setting
>> your own options (or at least doesn't appear to, my eyes crossed while
>> reading it).
>
> `org-set-regexps-and-options' is used to set options keywords and
> regexp, so depending on what you exactly want to do, you may have 
> to add your own options keywords here...
>
>> Is there any smaller function available for our own minor modes or use
>> cases? Should I just use regexp search? If there isn't anything like
>> this, would one be useful (something that either found an option value
>> or returned a default, or found an alist of option values, or found an
>> alist of values for options matching a regexp, etc)?
>
> Mhh..  hard to help you more without knowing more precisely what you
> want to achieve.  Perhaps an example would help.

I'm just thinking of cases where you have a little set of functions (or
even a minor-mode built on top of Org), that users will want to specify
buffer-local settings for. Say a function that operates on subtrees
with a specific tag, but you don't want to hard-code the tag, so you let
them set it with an option at the top of the file. That could be done
with #+BIND, I guess, but it would be nicer to have
a #+SOME_FUNCTION_TAG_NAME line. Then the thing you've written gets that
option before it does anything.

Part of the reason I was suggesting this is that, properly done, it
could be used in a refactoring of the standard setup functions like
`org-infile-export-plist' and `org-set-regexps-and-options', removing
some of their complexity and adding flexibility. If this would be
undesirable or impractical, then it's probably not worth it.

(I'd still like to know the best way to provide one-off, buffer-local
settings for org functions, though!)

Thanks,
Eric