"Sebastien Vauban" <wxhgmqzgw...@spammotel.com> writes: > Eric, > > Eric Schulte wrote: >> I would agree that this (meaning raw implies scalar) should either occur >> for all languages or for none. > > I think this is something interesting, but I wonder now if we wouldn't loose > more than we would win. I mean: how would one be able to output a real "raw" > result, then, that is one where pipes are not interpreted as table field > separator which have to be aligned in some specific way. > > Do we need another argument for that? > > I mean: at the end, raw should really be raw (no interpretation). If we want > some cycling for table alignment purpose (BTW, do you have lots of such code > blocks?), maybe it'd be better to introduce a `cycle' argument or so? > >> If we do have such header argument implications, then we'd want to put them >> into the weakest portion of the default header argument hierarchy. Currently >> this hierarchy looks something like >> >> 1. default header arguments shipped with Org-mode >> 2. user-set default header arguments >> 3. default languages-specific header arguments shipped with Org-mode >> 4. user-set default language-specific header arguments >> 5. buffer or file level header arguments >> 6. subtree header arguments >> 7. code block header arguments >> >> I think this raw implies verbatim action should probably take place >> somewhere between 3 and 4, but there could be arguments for other >> positions. Also, without looking at the code, I'm not sure how >> difficult adding such implications would be. > > Maybe I don't understand the problem correctly, but I'd think this "raw > implies verbatim" would have to take place after _each_ above step. >
Actually I think I was confused when I wrote the above, so please disregard, sorry for the noise. Best, > > If between 3 and 4, then a raw specified on the block level (step 7) > wouldn't imply verbatim? Does that make sense? > > I think every raw (be it default, language, buffer, subtree or block-local) > would have to imply the same reasoning. > >> Are there other header argument implication rules which would make code >> blocks "do what I mean" more naturally in more situations? > > Best regards, > Seb -- Eric Schulte http://cs.unm.edu/~eschulte
