Hello Nicolas,
Nicolas Goaziou wrote:
> "Sebastien Vauban" writes:
>
>> Is the simpler solution valid on all types of block environments?
>>
>> To enumerate them (extensively, AFAICT):
>>
>> - structureenv
>> - alertblock
>> - exampleblock
>> - definition
>> - example
>> - proof
>> - beamercolorbo
"Sebastien Vauban"
writes:
> Is the simpler solution valid on all types of block environments?
>
> To enumerate them (extensively, AFAICT):
>
> - structureenv
> - alertblock
> - exampleblock
> - definition
> - example
> - proof
> - beamercolorbox
> - verse
> - quotation
> - quote
The "simpler
Hello Nicolas,
Nicolas Goaziou wrote:
> "Sebastien Vauban" writes:
>
>> I thought that the standard way was the following:
>>
>> ***
>> :B_theorem:
>> :PROPERTIES:
>> :BEAMER_env: theorem
>> :END:
>>
>> There is no larges
Hello,
"Sebastien Vauban"
writes:
> I thought that the standard way was the following:
>
> ***
> :B_theorem:
> :PROPERTIES:
> :BEAMER_env: theorem
> :END:
>
> There is no largest prime number.
>
> *** End of theorem
Nicolas Goaziou writes:
> Hello,
>
> Alan Schmitt writes:
>
>> I have a use case for beamer export, where I have had to use latex
>> blocks to solve it. If I want:
>>
>> ,
>> | blah blah
>> |
>> | \begin{block}{Theorem}
>> | foo bar
>> | \end{block}
>> |
>> | more blah blah
>> `
>>
>>
Nicolas Goaziou wrote:
> Alan Schmitt writes:
>
>> I have a use case for beamer export, where I have had to use latex
>> blocks to solve it. If I want:
>>
>> ,
>> | blah blah
>> |
>> | \begin{block}{Theorem}
>> | foo bar
>> | \end{block}
>> |
>> | more blah blah
>> `
>>
>> I don't know h
Hello,
Alan Schmitt writes:
> I have a use case for beamer export, where I have had to use latex
> blocks to solve it. If I want:
>
> ,
> | blah blah
> |
> | \begin{block}{Theorem}
> | foo bar
> | \end{block}
> |
> | more blah blah
> `
>
> I don't know how to do it using the org machin
Eric S Fraga writes:
> I guess you can find plenty of discussions on this list on this topic so
> I won't rehash. Just to say that there has never been a convincing use
> case that is not easily addressed with description lists and inline
> tasks. The former can be made to look like encapsulate
Hi,
I guess you can find plenty of discussions on this list on this topic so
I won't rehash. Just to say that there has never been a convincing use
case that is not easily addressed with description lists and inline
tasks. The former can be made to look like encapsulated sections on
export with
Several requests have been made over the years for a way to end a
subsection without starting a new new higher level section. This is
possible with plain lists: a blank line ends the list. Some other
syntax would have to be added to org to allow this for sections. I
would love to see something like
Ken Mankoff writes:
[...]
> I just discovered org inline tasks. This seems to be another approach, and
> very useful!
Indeed! I use these all the time for when I have tasks inersprsed in a
large document. I'm not sure why I forgot to mention this capability;
probably because org has so many
Hi Eric,
On Tue, Jan 14, 2014 at 11:55 AM, Eric S Fraga wrote:
>
>
> What I would do is make the A, B and C paragraph items. Then add
> checkboxes (C-u C-c C-x C-b) to any list item you want to mark as a todo
> item. You can set/unset using C-c C-x C-b. If you add the text [/] to
> the headlin
Ken Mankoff writes:
> I just re-watched the Carsten Google Tech Talk from 2008. He explains
Great talk that was! Changed my life.
> that Org was created as a hybrid note taker and TODO list, and that
> the TODOs should be embedded in the text. This leads me to a strange
> situation and I hope
I just re-watched the Carsten Google Tech Talk from 2008. He
explains that Org was created as a hybrid note taker and TODO list,
and that the TODOs should be embedded in the text. This leads me to
a strange situation and I hope list members can explain how they
deal with it.
* ONE: Sometim
14 matches
Mail list logo
