Re: [O] Babel R source blocks problem

[Thomas S. Dye]

Aloha Chuck,

Charles C. Berry writes:
>
> Fair enough!
>
> If you are running org-9.0 or later, please use the `org-9-plus' branch
> (the default, now) of ox-ravel.  It has a lot more capabilities than the
> old `master' branch.  The code is cleaner, too.  :-)
>
> As far as .Rmd files go, =(require 'ox-ravel)= and (if not already done in
> your init) either =(require 'ox-md)= or selecting markdown from the
> customize menu should allow `C-c C-e r m' to export a buffer as .Rmd.

Works perfectly.  Thanks!

> A look at the `slidify-example.org' file in the `org-9-plus' branch of my
> (chasberry) `orgmode-accessories' github repo might be a good start with
> .Rmd exports even if you do not want to use `slidify'.

Got it.  This looks like the place to learn about ravel attributes.

All the best,
Tom

--
Thomas S. Dye
http://www.tsdye.com

Re: [O] Beamer framebreak

[edgar]

Hey Fabrice,

It's me again. I looked at your (README.org), and I finally understood 
how to force a framebreak! Thank you very much. I feel stupid, because 
it's the same solution which has been around on the Internet, but I 
finally know how to use it. For others who might be interested:


If your heading number 2 (** Heading) creates a slide (look at the 
#+OPTIONS: of your org file. If you have H:2, then this is the case. If 
you have another number after H:, it means that your slides will be 
created with that level of heading. This is all in the manual, honest!), 
then add the property for allowframebreaks,label= 
(https://bitbucket.org/rivanvx/beamer/issue/265/including-frame-label-option-stops):


#+OPTIONS: author:nil H:2
* Heading #1
** Heading #2
  :PROPERTIES:
  # The 0.8 forces the content to fit in 0.8 of the whole slide
  # (without considering navigation bars, etc.)
  :BEAMER_OPT: allowframebreaks=0.8,label=
  :END:
  Your long contents go here (and more than one slides are generated 
automatically)


So, if you try this (doesn't work):
#+OPTIONS: author:nil H:2
* Heading #1
** Heading #2
*** Heading #3
  :PROPERTIES:
  :BEAMER_OPT: allowframebreaks=0.8,label=
  :END:
  Your long contents will be cropped within a single slide

This doesn't work either:
#+OPTIONS: author:nil H:2
* Heading #1
** Heading #2
  :PROPERTIES:
  :BEAMER_OPT: allowframebreaks=0.8,label=
  :END:
*** Heading #3
  Your long contents will be cropped into more than one slide, wherein 
the first slide will possibly be the headline.


Now that I think of it, may be I should turn this into a feature 
request. Is that reasonable? (to force a framebreak when a block 
overflows a slide, resulting in cropped contents).



Edgar

On 2017-01-27 19:34, Fabrice Niessen wrote:

Hello Edgar,


I am new to org-mode, because it seems impressive, and I think that it
will make my life much simpler. Thank you!


You may -- or may not -- be interested by some kind of reference
material I wrote about Org-Beamer.

See https://github.com/fniessen/refcard-org-beamer.

Still partly a WIP, though.



-

ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the 
NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!  
15GB disk! No bandwidth quotas!
Commercial and Bulk Mail Options!  

Re: [O] Babel R source blocks problem

[Charles C. Berry]

On Sat, 28 Jan 2017, Thomas S. Dye wrote:


Aloha Chuck,



[snip]



Thanks, too, for asking about export. I'm giving a demo at a conference
this spring and the organizer has asked for a .rmd file, which is new to
me. I hope to produce it with your ox-ravel, also new to me, so I might
be pestering the list again :)



Fair enough!

If you are running org-9.0 or later, please use the `org-9-plus' branch 
(the default, now) of ox-ravel.  It has a lot more capabilities than the 
old `master' branch.  The code is cleaner, too.  :-)


As far as .Rmd files go, =(require 'ox-ravel)= and (if not already done in 
your init) either =(require 'ox-md)= or selecting markdown from the 
customize menu should allow `C-c C-e r m' to export a buffer as .Rmd.


A look at the `slidify-example.org' file in the `org-9-plus' branch of my 
(chasberry) `orgmode-accessories' github repo might be a good start with 
.Rmd exports even if you do not want to use `slidify'.


Best,

Chuck

[O] org-ref glitch with 2 bib files

[Alan L Tyree]

G'day,

I have this near the end of my MS:

bibliography:refs.bib,tyree.bib

org-ref finds the entries from refs.bib, but not tyree.bib.

If I reverse the two bib file, it finds the ones from tyree.bib, but not 
from refs.bib.


Org mode version 9.0.4 (9.0.4-elpaplus @ 
/home/alant/.emacs.d/elpa/org-plus-contrib-20170124/)


GNU Emacs 24.5.1 (x86_64-pc-linux-gnu, GTK+ Version 3.14.5) of 
2016-03-20 on trouble, modified by Debian


System is Linux, Debian Jessie.

I'm no expert, so I may well be missing something, so let me know if you 
need more information or whatever.


Thanks,

Alan


--
Alan L Tyreehttp://www2.austlii.edu.au/~alan
Tel:  04 2748 6206  sip:typh...@iptel.org

Re: [O] Babel R source blocks problem

[Thomas S. Dye]

Aloha Chuck,

Charles C. Berry writes:

> I hope somebody recognizes that message. If not, here are som suggestions:
>
>
> #+NAME: alpha
> #+BEGIN_SRC emacs-lisp
> "abc"
> #+END_SRC
>
> produces
>
> #+RESULTS: alpha
> : abc
>
> when you run `org-babel-execute-src-block'. Does changing "emacs-lisp"
> to "R" and running again erase the result or fail to insert it if
> you first run `org-babel-remove-result'?
>
> You have already checked that C-c C-v C-i for both versions yields
> identical results, right?
>
> If so, I'd instrument `org-babel-execute-src-block', execute and then
> type 'h' just before the `(org-babel-insert-result ... ' --- a couple
> of lines from the bottom --- once you enter edebug. Then `e' and
> `results' to see that it is what you suppose it should be. Then step
> thru the next few lines to insert the result. Then check the buffer to
> see what happened. If no result was inserted, then I'd instrument
> `org-babel-insert-result' and work from there.
>
> HTH,
>
> Chuck
>
> p.s. You are not trying to export this and depending on the exporter
> to run babel, right? Because there is another trick lying in wait...

That helped me find the user error, duplicate NAME.  Sorry for the
noise and thanks for the help.

Thanks, too, for asking about export. I'm giving a demo at a conference
this spring and the organizer has asked for a .rmd file, which is new to
me. I hope to produce it with your ox-ravel, also new to me, so I might
be pestering the list again :)

All the best,
Tom

--
Thomas S. Dye
http://www.tsdye.com

Re: [O] BUG: agenda for current days excludes reoccurring events

[Jarmo Hurri]

Nicolas Goaziou  writes:

> Jarmo Hurri  writes:
>
>> In particular the fact that you see it for all other days except today
>> makes absolutely no sense, right?
>
> It does make sense, but probably not when there is no TODO keyword.
> Also, your sentence is inaccurate: you see it _once_ in the past, not
> every others day.

That is correct, only once in the past, my bad. (Which explains some of
the weirdness in my own, more complicated setup.) Still not sure why it
would be appropriate for a TODO _as a default_ (not to show it for
today, but for future days), but like I said: we're operating above my
pay grade. Just _trying_ to provide some answers to your questions, not
sure if this is helping.

>>> I think that a nil `org-agenda-prefer-last-repeat' should display :
>>> - only the base date when the entry has a TODO keyword; - every
>>> repeat between base date and today, inclusive, otherwise.
>>>
>>> It also applies to SCHEDULED and DEADLINE repeaters.
>>>
>>> Behaviour with a non-nil value needs not be changed.
>>>
>>> WDYT?
>>
>> This is slightly beyond my pay grade, but I hope a nil
>> 'org-agenda-prefer-last-repeat' would also display all repeats for
>> _future_ days.
>
> This is orthogonal to the issue. There's a dedicated variable for
> that: `org-agenda-show-future-repeats'.

If I am on the right track here, org-agenda-show-future-repeats controls
future repetitions, and org-agenda-prefer-last-repeat controls
repetitions for today? Is that correct? (Feel completely free to ignore
this if I am on the wrong track.) I am not sure how this would work for
timed events, since "today" and "future" are not mutually exclusive:
part of today is still in the future.

> If no one objects, I'll just implement the behaviour quoted above.

Sounds like the best option to me. I can try give better informed
comments after I see what the effect will be in my setup.

Jarmo

Re: [O] Babel R source blocks problem

[Charles C. Berry]

On Sat, 28 Jan 2017, Thomas S. Dye wrote:


Aloha all,

I've run into a problem running R code blocks in a new Spacemacs setup.
Results are not written to the Org mode buffer.

In *Messages* I see this the first time I evaluate the R source code
block:
Error during redisplay: (jit-lock-function 804) signaled (search-failed
"^> ")

If I run R in a :session, then I see that the source code block is
executing correctly.

Other languages don't seem to have a problem writing results to the Org
mode buffer.

Any ideas how I might debug this?


I hope somebody recognizes that message. If not, here are som suggestions:


#+NAME: alpha
#+BEGIN_SRC emacs-lisp
"abc"
#+END_SRC

produces

#+RESULTS: alpha
: abc

when you run `org-babel-execute-src-block'. Does changing "emacs-lisp"
to "R" and running again erase the result or fail to insert it if
you first run `org-babel-remove-result'?

You have already checked that C-c C-v C-i for both versions yields
identical results, right?

If so, I'd instrument `org-babel-execute-src-block', execute and then
type 'h' just before the `(org-babel-insert-result ... ' --- a couple
of lines from the bottom --- once you enter edebug. Then `e' and
`results' to see that it is what you suppose it should be. Then step
thru the next few lines to insert the result. Then check the buffer to
see what happened. If no result was inserted, then I'd instrument
`org-babel-insert-result' and work from there.

HTH,

Chuck

p.s. You are not trying to export this and depending on the exporter
to run babel, right? Because there is another trick lying in wait...

[O] Babel R source blocks problem

[Thomas S. Dye]

Aloha all,

I've run into a problem running R code blocks in a new Spacemacs setup.
Results are not written to the Org mode buffer.

In *Messages* I see this the first time I evaluate the R source code
block:
Error during redisplay: (jit-lock-function 804) signaled (search-failed
"^> ")

If I run R in a :session, then I see that the source code block is
executing correctly.

Other languages don't seem to have a problem writing results to the Org
mode buffer.

Any ideas how I might debug this?

Org mode version 9.0.4 (9.0.4-elpaplus @
/Users/dk/.emacs.d/elpa/org-plus-contrib-20170124/)

GNU Emacs 25.1.1 (x86_64-apple-darwin13.4.0, NS appkit-1265.21 Version 10.9.5 
(Build 13F1911)) of 2016-11-13

All the best,
Tom
--
Thomas S. Dye
http://www.tsdye.com

Re: [O] BUG: agenda for current days excludes reoccurring events

[Nicolas Goaziou]

Jarmo Hurri  writes:

> In particular the fact that you see it for all other days except today
> makes absolutely no sense, right?

It does make sense, but probably not when there is no TODO keyword.
Also, your sentence is inaccurate: you see it _once_ in the past, not
every others day.

>> I think that a nil `org-agenda-prefer-last-repeat' should display :
>> - only the base date when the entry has a TODO keyword;
>> - every repeat between base date and today, inclusive, otherwise.
>>
>> It also applies to SCHEDULED and DEADLINE repeaters.
>>
>> Behaviour with a non-nil value needs not be changed.
>>
>> WDYT?
>
> This is slightly beyond my pay grade, but I hope a nil
> 'org-agenda-prefer-last-repeat' would also display all repeats for
> _future_ days.

This is orthogonal to the issue. There's a dedicated variable for that:
`org-agenda-show-future-repeats'.

> I assume quite a few people use reoccurring entries to mark regular
> meetings, short tasks etc. It is imperative that they also see how the
> meeting affect the schedules of future days in their agenda. My
> personal opinion is that _any entry with a timestamp_ should be
> repeated as far into the future as possible, regardless of whether it
> is a TODO or some other type. A timestamp indicates that this entry
> very likely needs to be taken into account when scheduling future
> events. Thus seeing the repetition in the agenda in the future may be
> crucial.
>
> Does this make sense?

See above.

Anyway, that doesn't answer my question about what should be done for
_past and present_ occurrences. 

If no one objects, I'll just implement the behaviour quoted above.

Regards,

Re: [O] What would you like to see in the next MobileOrg iOS?

[Jarmo Hurri]

Hello!

> We've started plans on the future version of MobileOrg, dubbed just v2
> currently.

I was very happy to see that you are considering the possibility to sync
MobileOrg and (regular) Org via git. If you can do that, then I will be
more than happy to jump on board - have wanted to for quite some time.

In general for me syncing the two systems needs to be as transparent as
possible. The use of a true version control upstream repo as a
synchronization point would convince me that I could _always_ fix a mess
in case there would be one.

Then just add builtin features in both base Org and MobileOrg to

1. push and pull over ssl presto

2. (automatically) sense whether the downstream or upstream repo is
   newer, and do / suggest push / pull actions accordingly.

That would be so great.

Hope my terminology made some sense.

I am sure a lot more requests and features will come in mind after
starting to use your new, brilliant version.

Jarmo

Re: [O] BUG: agenda for current days excludes reoccurring events

[Jarmo Hurri]

Greetings again.

Nicolas Goaziou  writes:

> Jarmo Hurri  writes:
>
>> - how the bug shows up: the reoccurring meeting will show up yesterday
>>   and in upcoming days, but not in the current day
>
> This is the consequence of `org-agenda-prefer-last-repeat' default
> value.
>
> However, this behaviour doesn't make much sense when the entry is not
> a task (i.e., it hasn't any TODO keyword). In this case,
> `org-auto-repeat-maybe' doesn't apply, and the base date is never moved
> forward in time.

In particular the fact that you see it for all other days except today
makes absolutely no sense, right?

> I think that a nil `org-agenda-prefer-last-repeat' should display :
> - only the base date when the entry has a TODO keyword;
> - every repeat between base date and today, inclusive, otherwise.
>
> It also applies to SCHEDULED and DEADLINE repeaters.
>
> Behaviour with a non-nil value needs not be changed.
>
> WDYT?

This is slightly beyond my pay grade, but I hope a nil
'org-agenda-prefer-last-repeat' would also display all repeats for
_future_ days.

I assume quite a few people use reoccurring entries to mark regular
meetings, short tasks etc. It is imperative that they also see how the
meeting affect the schedules of future days in their agenda.

My personal opinion is that _any entry with a timestamp_ should be
repeated as far into the future as possible, regardless of whether it is
a TODO or some other type. A timestamp indicates that this entry very
likely needs to be taken into account when scheduling future
events. Thus seeing the repetition in the agenda in the future may be
crucial.

Does this make sense?

Jarmo

Re: [O] BUG: agenda for current days excludes reoccurring events

[Nicolas Goaziou]

Hello,

Jarmo Hurri  writes:

> - bug: day agenda for current day does not show reoccurring events
>
> - how to replicate with the ECM provided
>   1. untar the file provided below
>   2. cd into created dir
>   3. edit the first line of file agenda-setup.el so that the latest org
>  release lisp is in the load path
>   4. run
>  emacs -q --load agenda-setup.el
>   5. run command (org-agenda)
>   6. press 'a' for day agenda
>   7. press 'b' and/or 'f' to move backwards and forward in time
>
> - how the bug shows up: the reoccurring meeting will show up yesterday
>   and in upcoming days, but not in the current day

This is the consequence of `org-agenda-prefer-last-repeat' default
value.

However, this behaviour doesn't make much sense when the entry is not
a task (i.e., it hasn't any TODO keyword). In this case,
`org-auto-repeat-maybe' doesn't apply, and the base date is never moved
forward in time.

I think that a nil `org-agenda-prefer-last-repeat' should display :
- only the base date when the entry has a TODO keyword;
- every repeat between base date and today, inclusive, otherwise.

It also applies to SCHEDULED and DEADLINE repeaters.

Behaviour with a non-nil value needs not be changed.

WDYT?

Regards,

-- 
Nicolas Goaziou

Re: [O] [BUG?] is [org-image-actual-width] deprecated? setting it in config crashes emacs?

[Nicolas Goaziou]

Hello,

Xebar Saram  writes:

> after bisecting today i discovered today that the thing the kept crashing
> emacs was this variable `org-image-actual-width` which was set this way in
> my config
>
> (setq org-image-actual-width '(400))
>
> did i not define it correctly? and if so why is it crashing emacs when i
> load a org file with images and open a header that will present such an
> image?
>
> attached is a backtrace i created when the variable was on

FWIW, I cannot reproduce your issue.

Regards,

-- 
Nicolas Goaziou

[O] BUG: agenda for current days excludes reoccurring events

[Jarmo Hurri]

Greetings.

- bug: day agenda for current day does not show reoccurring events

- how to replicate with the ECM provided
  1. untar the file provided below
  2. cd into created dir
  3. edit the first line of file agenda-setup.el so that the latest org
 release lisp is in the load path
  4. run
 emacs -q --load agenda-setup.el
  5. run command (org-agenda)
  6. press 'a' for day agenda
  7. press 'b' and/or 'f' to move backwards and forward in time

- how the bug shows up: the reoccurring meeting will show up yesterday
  and in upcoming days, but not in the current day

Jarmo



agenda-bug-minimal.tar
Description: ECM files