Re: [O] parsing fixed with section
On Thu, Aug 11, 2011 at 4:54 PM, Nicolas Goaziou wrote: > Hello, > > Steven Haryanto writes: > > > As I understand it, a fixed width section (BTW, is "fixed width section" > the > > official term for this?) > > Yes. > > > is defined as a line which is started by zero or more spaces, and then > > a colon, *and then a space*, and then zero or more characters. > > > > :line1 > > : > > :line3 > > > > But many editors (Emacs including) likes to trim trailing spaces, > > As far as I know, this doesn't happen in Emacs, unless you specify it > explicitly (i.e. in some hook). > > > so when the file is saved, the second line loses its space: > > > > :line1 > > : > > :line3 > > > > Should the second line be parsed as a fixed width section too or not? > > I'd say yes. > > You may have noticed that exporters already treat that line as > fixed-width section anyway. But this is inconsistent with fontification > (and indentation) in the buffer. > > I've pushed a commit to fix this inconsistency in master. > > Thanks for pointing this out. > > Thanks for clearing this up, I've also updated the Org::Parser Perl module. -- sh
[O] parsing fixed with section
Dear all, As I understand it, a fixed width section (BTW, is "fixed width section" the official term for this?) is defined as a line which is started by zero or more spaces, and then a colon, *and then a space*, and then zero or more characters. :line1 : :line3 But many editors (Emacs including) likes to trim trailing spaces, so when the file is saved, the second line loses its space: :line1 : :line3 Should the second line be parsed as a fixed width section too or not? -- sh
Re: [O] how to escape org markup?
On Fri, Jun 17, 2011 at 12:10 AM, Nick Dokos wrote: > Steven Haryanto wrote: > > > I need to insert bits of plain text into a final composite Org document. > The text should be > > protected from any Org formatting (for example, "* " at the beginning of > a line should not be > > interpreted as a headline). Is enclosing it with #+BEGIN_SRC/#+END_SRC > or #+BEGIN_EXAMPLE/# > > +END_EXAMPLE the correct way? I'm thinking yes, but my Emacs still > interprets the "* " as headline > > though. > > > > This seems to work - I can export to html or latex and get the expected > result: > > --8<---cut here---start->8--- > > * foo > org example > > #+begin_example > ,* bar > <2011-06-16 Thu> > > This is example code. > > #+end_example > --8<---cut here---end--->8--- > > But I don't know all the rules and moreover I don't know of any place where > they are described. I'll look around and post an update when I find it. > But feel free to beat me to it. > > Nick > Btw, I still need to escape "#+END_SRC" if they occur at the start of line in text, for example by prepending it with a space (akin to prepending a space to "From " in mbox format). -- sh
[O] how to escape org markup?
Hi all, I need to insert bits of plain text into a final composite Org document. The text should be protected from any Org formatting (for example, "* " at the beginning of a line should not be interpreted as a headline). Is enclosing it with #+BEGIN_SRC/#+END_SRC or #+BEGIN_EXAMPLE/#+END_EXAMPLE the correct way? I'm thinking yes, but my Emacs still interprets the "* " as headline though. -- sh
Re: [O] A simpler way to write literal examples?
On Wed, May 25, 2011 at 10:25 PM, Nick Dokos wrote: > Steven Haryanto wrote: > > > I plan to document some parts of Perl source code (more specifically, > description in subroutine > > Sub::Spec specification, http://search.cpan.org/dist/Sub-Spec) using Org > format instead of the > > canonical POD, hoping to have better table support, more customizable > links, and overall markups > > that are nicer to look at (IMO). > > > > However, one of the nice things of POD (and Wiki, Markdown, etc) for > documenting source code is the > > relative simplicity of writing literal examples: an indented paragraph. > In Org we either have to use > > the colon+space prefix syntax: > > > > : this is an example > > : another line > > : another line > > > > or the example block: > > > > #+BEGIN_EXAMPLE > > this is an example > > another line > > another line > > #+END_EXAMPLE > > > > Is there an alternative syntax? If there isn't, would people consider an > alternative syntax (e.g. > > say a setting which toggles parsing an indented paragraph as a literal > example)? > > > > What is the problem with #+BEGIN_EXAMPLE/#+END_EXAMPLE? IOW, why do you > need > an alternative syntax? If your answer is "too much typing", check out > section 15.2, "Easy templates", in the Org manual. The problem is visual clutter (yes, I guess Emacs can be told to hide the markup, but I'm talking about when text is displayed as-is and/or outside Emacs) and copy-pasteability (especially with the colon syntax). I know Org format is not optimized for fixed width section, but perhaps there is a way? -- sh
[O] A simpler way to write literal examples?
I plan to document some parts of Perl source code (more specifically, description in subroutine Sub::Spec specification, http://search.cpan.org/dist/Sub-Spec) using Org format instead of the canonical POD, hoping to have better table support, more customizable links, and overall markups that are nicer to look at (IMO). However, one of the nice things of POD (and Wiki, Markdown, etc) for documenting source code is the relative simplicity of writing literal examples: an indented paragraph. In Org we either have to use the colon+space prefix syntax: : this is an example : another line : another line or the example block: #+BEGIN_EXAMPLE this is an example another line another line #+END_EXAMPLE Is there an alternative syntax? If there isn't, would people consider an alternative syntax (e.g. say a setting which toggles parsing an indented paragraph as a literal example)? -- sh
Re: [O] advice re organizing todo agenda items
On Thu, Mar 31, 2011 at 5:11 PM, Filippo A. Salustri wrote: > Samuel & Nick, > > I'm using priorities now, but there's only 3 of 'em. I would prefer > finer control over them if I were to continue using priorities in this > way. > > Q: My reading of the doc is that there's no way to change the number > of priorities org supports: we're "stuck" with A/B/C. Right? > > I believe you can change the list of priorities with this setting (which you put in your Org file): #+PRIORITIES: Low M High Whatever ... PS: Sorry for the double reply. I usually subscribe to mailing lists which set its Reply-To to list. HTH, Steven
Re: [O] Perl parser, some questions
On Thu, Mar 31, 2011 at 3:39 PM, Carsten Dominik wrote: > > On Mar 31, 2011, at 7:05 AM, Steven Haryanto wrote: > > > Hi all, > > > > I'm writing an Org parser for Perl[1]. There are a few things about the > syntax which are still unclear to me. > > > > 1. The manual says that multiple (different) in-buffer settings can be > specified on the same line, but so far I haven't found such example > anywhere. What is the syntax for this? > > This only applied to the #+STARTUP settings which can have a number > of keywords on a single line, like > > #+STARTUP: align hidestars odd > > > > > 2. For settings that can be applied near a block or table, like: > > > > |1|2 > > |2|6 > > #+TBLFM: @2$1=@1$1*2::@2$2=@1$2*3 > > > > does it matter if it is specified before/after? Can there be separating > lines between them? E.g. > > Yes, there can be other lines in between, even though > this is probably not a good idea. The way the parser works > is that it runs through the buffer, finds CAPTURE etc and > applies it the next thing (table, link,...) that wants it. > > > > > #+CAPTION: Some caption > > some text <-- allowed? > > #+LABEL: ... > > some more text <-- allowed? > > |...|...| > > |...|...| > > > > (And btw, multiple #+TBLFM below a table doesn't seem to work on my > Emacs, all formulas need to be specified on a single (long) TBLFM setting.) > > Yes, only one TBLFM line per table. > > > > > 3. What constitutes a valid tag? Emacs doesn't seem to recognize tags > (e.g. align them) if they contain a dash. > > Tags are matched by [[:alnum:]_@#%:]+ > > Dashes are not allowed because this would be cumbersome for the > agenda tags matcher which uses "-" as NOT. > > > > > 4. What is the difference between TYP_TODO/TODO/SEQ_TODO? > > TODO and SEQ_TODO are the same. TYP_TODO is slightly different > in operation. When you press C-c C-t in a line with the keyword > defined by TYP_TODO, the task will immediately switch to DONE, > instead of to the next state in the sequence. I do believe the > manual explains this quite well, but I don't believe many people use this. > > > > (IIRC, the manual is not clear on this). Or between TAGS/FILETAGS. > > TAGS defines tags that will be used in the buffer > and defines fast keyboard shortcuts for them. Though > you are allowed to also use tags that are not in tis list. > > FILETAGS defines tags that are *inherited* by all trees in the buffer, > You can imagine FILETAGS as the tags specified on a level zero headline > of which all level one headlines in the buffer are children. > > HTH. > > Thanks for the clear up, Carsten! I've implemented some of the points (like regex for tags) into the parser, and the rest into the project's todo list. Btw, you probably meant [[:alnum:]_@#%]+ (without the colon)? Since the colon is used to separate between tags? Regards, Steven
Re: [O] Perl parser, some questions
On Thu, Mar 31, 2011 at 3:21 PM, Eric S Fraga wrote: > Steven Haryanto writes: > > > Hi all, > > > > I'm writing an Org parser for Perl[1]. There are a few things about the > > syntax which are still unclear to me. > > > > 1. The manual says that multiple (different) in-buffer settings can be > > specified on the same line, but so far I haven't found such example > > anywhere. What is the syntax for this? > > If you are referring to lines like this one: > > #+OPTIONS: oddeven hideblocks > > the syntax is space separated options. > >From the manual (emphasis mine): "*Several setting words* can be in the same line, but you can also have multiple lines for the keyword." So I guess "setting words" mean setting's arguments (and not setting names, like specifying OPTIONS and TODO on the same line)? > What is the main purpose of your parser? > I first wrote it because I thought it would be fun, and CPAN does not have one already. The parser converts Org document into a tree of node objects, and can be a base for other efforts, like exporter to HTML/TXT/POD. -- sh
[O] Perl parser, some questions
Hi all, I'm writing an Org parser for Perl[1]. There are a few things about the syntax which are still unclear to me. 1. The manual says that multiple (different) in-buffer settings can be specified on the same line, but so far I haven't found such example anywhere. What is the syntax for this? 2. For settings that can be applied near a block or table, like: |1|2 |2|6 #+TBLFM: @2$1=@1$1*2::@2$2=@1$2*3 does it matter if it is specified before/after? Can there be separating lines between them? E.g. #+CAPTION: Some caption some text <-- allowed? #+LABEL: ... some more text <-- allowed? |...|...| |...|...| (And btw, multiple #+TBLFM below a table doesn't seem to work on my Emacs, all formulas need to be specified on a single (long) TBLFM setting.) 3. What constitutes a valid tag? Emacs doesn't seem to recognize tags (e.g. align them) if they contain a dash. 4. What is the difference between TYP_TODO/TODO/SEQ_TODO? (IIRC, the manual is not clear on this). Or between TAGS/FILETAGS. There may be more coming along. Regards, Steven [1] http://search.cpan.org/dist/Org-Parser/lib/Org/Parser.pm
