Re: Can Org warn me if I create a time conflict?

[Fraga, Eric]

On Tuesday, 17 Dec 2019 at 14:05, David Rogers wrote:
> Is there any method to get org-mode to alert me (by an error message,
> or a red mark in the agenda, or whatever) that I've created a conflict

None that I know of.  I've trained myself to only create meetings from
the agenda view for this reason.

-- 
Eric S Fraga via Emacs 27.0.50, Org release_9.3-34-g2eee3c

Re: Emacs bug 37890; killing capture buffer

[Fraga, Eric]

On Tuesday, 17 Dec 2019 at 17:07, Samuel Wales wrote:
> i encountered this problem today.  i added a task and duplicated it.
> this caused the corruption.  it also screwed up the stars level, but
> never mind that.

I've encountered the problem in the past week or two when I was tweaking
one of my capture templates.  I had to add a \n to the end of the
template string to avoid the problem but didn't explore more than that.

-- 
Eric S Fraga via Emacs 27.0.50, Org release_9.3-34-g2eee3c

Re: [PATCH] Fix verbatim block fontification to end blocks on headlines

[Tom Gillespie]

Hi,
Here is the updated patch, including the fix to only trigger on
actual headlines (and not bold or similar), the readability
improvement for beg-of-next-line and a fix to call point-max only once
per branch. I also switched all the regex over to use the rx macro. I
left out the tests because since they would entail quite a bit of
additional work that is out of scope for this patch. The rx changes
mean that the patch is now over the tiny change limit, I went ahead
and sent a request to ass...@gnu.org so we don't have to wait around
if things look good. Best,
Tom
From 8c36ffa82c138057a03c813aa0c7616f04744a72 Mon Sep 17 00:00:00 2001
From: Tom Gillespie 
Date: Wed, 11 Dec 2019 17:57:47 -0800
Subject: org.el: Fix verbatim block fontification to end blocks on headlines

* lisp/org.el (org-fontify-meta-lines-and-blocks-1): Enhance regex
for finding the end of blocks (i.e., `beg-of-endline') to detect
headlines (i.e., (rx bol (one-or-more "*") space) so that fontification
matches the behavior of org mode (i.e., that headlines are healines,
even in vertabim).

This change aligns the behavior and the visual appearance of verbatim
blocks that contain headlines. When `font-lock-mode' is enabled this
change makes situations like those in (info "(org) Literal Examples")
literally jump off the page.

Overview of new fontification

Source| fontification before | fontification after  |
\#+BEGIN_EXAMPLE  | org-block-begin-line | org-block-begin-line |
I look verbatim!  | org-block| org-block|
* Org headers in  | org-block| org-level-1  |
verbatim blocks   | org-block| nil  |
** highly accordingly | org-block| org-level-2  |
\#+END_EXAMPLE| org-block-end-line   | org-meta-line|

This commit also makes some improvements to the reability of
org-fontify-meta-lines-and-blocks-1.

1. Use the `rx' macro for better readability. Note that the strings
below return with literal tabs when using `rx'. Expansion included for
reference here.

Begin regex.
old: "^\\([ \t]*#\\(\\(\\+[a-zA-Z]+:?\\| \\|$\\)\\(_\\([a-zA-Z]+\\)\\)?\\)[ \t]*\\(\\([^ \t\n]*\\)[ \t]*\\(.*\\)\\)\\)"
new: "^\\([[:blank:]]*#\\(\\(\\+[A-Za-z]+:?\\|[[:space:]]\\|$\\)\\(_\\([A-Za-z]+\\)\\)?\\)[[:blank:]]*\\(\\([^	\n ]*\\)[[:blank:]]*\\(.*\\)\\)\\)"

End regex. Note match-string call is stringified for documentation here.
old:(concat "^[ \t]*#\\+end" (match-string 4) "\\>.*")
new: "\\(?:\\(^\\(?:\\*+[[:space:]]\\|[[:blank:]]*#\\+end(match-string 4)\\>.*\\)\\)\\)"

Caption regex:
old: "\\([ \t]*#\\+caption\\(?:\\[.*\\]\\)?:\\)[ \t]*"
new: "\\([[:blank:]]*#\\+caption\\(?:\\[.*]\\)?:\\)[[:blank:]]*"

2. Refactor fontification of #+end blocks for readability and to reduce
the number of calls to point-max to one per branch.
---
 lisp/org.el | 35 ---
 1 file changed, 28 insertions(+), 7 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 8e3024c93..14840d8ca 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -5250,7 +5250,15 @@ by a #."
   "Fontify #+ lines and blocks."
   (let ((case-fold-search t))
 (when (re-search-forward
-	   "^\\([ \t]*#\\(\\(\\+[a-zA-Z]+:?\\| \\|$\\)\\(_\\([a-zA-Z]+\\)\\)?\\)[ \t]*\\(\\([^ \t\n]*\\)[ \t]*\\(.*\\)\\)\\)"
+	   (rx bol (group (zero-or-more blank) "#"
+			  (group (group (or (seq "+" (one-or-more (any "a-zA-Z")) (optional ":"))
+	space
+	eol))
+ (optional (group "_" (group (one-or-more (any "a-zA-Z"))
+			  (zero-or-more blank)
+			  (group (group (zero-or-more (not (any " \t\n"
+ (zero-or-more blank)
+ (group (zero-or-more any)
 	   limit t)
   (let ((beg (match-beginning 0))
 	(end-of-beginline (match-end 0))
@@ -5268,7 +5276,12 @@ by a #."
 	  (setq block-type (downcase (match-string 5))
 		quoting (member block-type org-protecting-blocks)) ; src, example, export, maybe more
 	  (when (re-search-forward
-		 (concat "^[ \t]*#\\+end" (match-string 4) "\\>.*")
+		 (rx-to-string `(group bol (or (seq (one-or-more "*") space)
+	   (seq (zero-or-more blank)
+		"#+end"
+		,(match-string 4)
+		word-end
+		(zero-or-more any)
 		 nil t)  ;; on purpose, we look further than LIMIT
 	;; We do have a matching #+end line
 	(setq beg-of-endline (match-beginning 0)
@@ -5307,10 +5320,14 @@ by a #."
 	(add-text-properties
 	 beg (if whole-blockline bol-after-beginline end-of-beginline)
 	 '(face org-block-begin-line))
-	(add-text-properties
-	 beg-of-endline
-	 (min (point-max) (if whole-blockline (min (point-max) (1+ end-of-endline)) end-of-endline))
-	 '(face org-block-end-line))
+	(unless (string-prefix-p "*" (match-string 1))
+	  (add-text-properties
+	   beg-of-endline
+	   (if whole-blockline
+		   (let ((beg-of-next-line (1+ end-of-endline)))
+		 (min (point-max) beg-of-next-line))
+		 (min 

Re: Emacs bug 37890; killing capture buffer

[Ihor Radchenko]

Dear Michael,

> BTW, what is the canonical place to report org-mode bugs?  Emacs bug
> reports are not (takes a long time until someone even notices) -- I
> thought this list would be good...or is there a better place?   @Adam
> it's ok if you answer, though I'm a bit disappointed that no one else
> seems to care so far...

You can try M-x org-submit-bug-report ;)
Then it becomes clear that you are in the right place already. 

Best,
Ihor


Michael Heerdegen  writes:

> Adam Porter  writes:
>
>> I guess you're asking me, since I'm the only other person in this
>> thread--but I'm not an Org maintainer, so my opinion isn't very
>> important.  IMO, the hooks are worth considering, however they should be
>> done very, very carefully, because bad things can happen when functions
>> called in kill hooks don't work as expected (e.g. they can make it very
>> difficult to kill a buffer or the Emacs process, especially for an
>> average user).
>
> Yes, all true.  I didn't even check if the code I posted breaks any org
> commands that kill the buffer.  So far it's only meant for demonstration
> (and my personal usage).
>
> Will my request be noticed here, or do you think I should report it to
> some other place?
>
>> > BTW, what about my question whether my original bug report can be
>> > closed?
>>
>> I haven't seen your bug report.  Was there discussion about it
>> previously?
>
> No, no discussion at all.  As I said, it is Emacs bug #37890, this was
> my issue:
>
> | I want to capture an APPT with `org-capture'.  I the pop-up buffer to
> | edit the item I move the date to the second line and add text after the
> | date (personal preference).  That loses the final newline in
> | CAPTURE-todo.org.  As a result, the headline of the item following the
> | item to be inserted gets appended to the last line of the text:
> |
> | ** APPT Abc
> |<2019-10-23 Mi>
> | text... ** APPT 8:30 Important Appointment
> |
> | breaking the whole item.  The user should somehow be prevented from that
> | happening.
>
> It seems it has been resolved, just without noticing my bug report.  If
> you can confirm that the cited issue has been cared about, I'll close it
> as done.
>
> BTW, what is the canonical place to report org-mode bugs?  Emacs bug
> reports are not (takes a long time until someone even notices) -- I
> thought this list would be good...or is there a better place?   @Adam
> it's ok if you answer, though I'm a bit disappointed that no one else
> seems to care so far...
>
>
> Thanks,
>
> Michael.
>

Re: Emacs bug 37890; killing capture buffer

[Kyle Meyer]

Michael Heerdegen  writes:

> Adam Porter  writes:
[...]
>> I haven't seen your bug report.  Was there discussion about it
>> previously?
>
> No, no discussion at all.  As I said, it is Emacs bug #37890, this was
> my issue:
>
> | I want to capture an APPT with `org-capture'.  I the pop-up buffer to
> | edit the item I move the date to the second line and add text after the
> | date (personal preference).  That loses the final newline in
> | CAPTURE-todo.org.  As a result, the headline of the item following the
> | item to be inserted gets appended to the last line of the text:
> |
> | ** APPT Abc
> |<2019-10-23 Mi>
> | text... ** APPT 8:30 Important Appointment
> |
> | breaking the whole item.  The user should somehow be prevented from that
> | happening.
>
> It seems it has been resolved, just without noticing my bug report.  If
> you can confirm that the cited issue has been cared about, I'll close it
> as done.

This issue was resolved by 0fa8bb4c5 (org-capture: Inserting an entry
doesn't break structure, 2018-10-22), which part of the 9.2 release and
prompted by .

Re: R code block produces no output

[Vikas Rawal]

>> That should be ":results file graphics".
>>
>>
> Thanks very much. This works. I guess this has recently changed. I have
> always used ":results output graphics"
>
>
>
I see that the behaviour changed with 9.3. Release notes (
https://www.orgmode.org/Changes.html) have this:
:file header argument no longer assume "file" :results

The "file" :results value is now mandatory for a code block returning a
link to a file. The :file or :file-ext header arguments no longer imply a
"file" result is expected.

--

Thanks a lot for your help.

Vikas

Re: Emacs bug 37890; killing capture buffer

[Samuel Wales]

i might be completely off on this, but it seems the problem is that
there is a corrupted buffer.

in particular, there is a missing newline at the end of the narrowed
region in the capture buffer.  this causes the next header to join the
last line in the captured buffer.

i encountered this problem today.  i added a task and duplicated it.
this caused the corruption.  it also screwed up the stars level, but
never mind that.

so if i'm not completely off, which i might be, it's not so much
killing the buffer as the fact that the state is corrupted in the
first place.

if the state is corrupted by the lack of a newline at the end of the
capture buffer, that can be fixed by adding one there.  but the user
can screw that up by deleting it.

if the state is corrupted by the lack of a newline just after the
capture buffer, then that can be fixed -- maybe partly -- by adding a
newline there.

this seems to me to be the right thing to do.

i don't think this will create any blank lines.

but *if* it does, it is much better to have the computer crash with
the only corruption being the addition of a blank line, than to have a
header corrupted.

i am the designer of the indirect buffer capture idea.  i did not
implement it, however.

the indirect buffer capture mechanism was to be an improvement on
remember.el, and replaced it.  you might still be able to find
remember.el if you prefer the separate file idea.

not sure if my brain is working properly right now, but that's the basic idea.


 wrote:
> Hi,
>
> I want to speak about my Emacs bug report 37890 about org-capture.
> Seems my main point:
>
> | I want to capture an APPT with `org-capture'.  I the pop-up buffer to
> | edit the item I move the date to the second line and add text after the
> | date (personal preference).  That loses the final newline in
> | CAPTURE-todo.org.  As a result, the headline of the item following the
> | item to be inserted gets appended to the last line of the text:
> |
> | ** APPT Abc
> |<2019-10-23 Mi>
> | text... ** APPT 8:30 Important Appointment
> |
> | breaking the whole item.  The user should somehow be prevented from that
> | happening.
>
> has been resolved with the latest merge into Emacs master - is that
> correct?  Then I will close that report.
>
> The report also included a feature request which I now want to tell
> here: I often kill the capture buffer instead of hitting C-c C-k.  Just
> by habit.  It's wrong and I now it but I guess it happens to others.
>
> I guess the capture buffer is just a narrowed indirect buffer copy of
> the buffer visiting the according org file.  Because of this, when you
> kill the capture buffer, the original buffer reflects the partial and
> uncomplete entry one tried to add.  This may damage your file.  But such
> internals are not known to all, so it would be good if killing the
> capture buffer, or even just closing the window, would warn the user and
> offer to undo the partial changes.  Or (really better IMHO) consider a
> different implementation where the original buffer is not modified until
> the user explicitly confirms the stuff to capture with C-c C-c.
>
> TIA,
>
> Michael.
>
>


-- 
The Kafka Pandemic

What is misopathy?
https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html

The disease DOES progress. MANY people have died from it. And ANYBODY
can get it at any time.

Can Org warn me if I create a time conflict?

[David Rogers]

It's currently possible for me to create two meeting times, one from 8:00-10:00 
tomorrow and the other from 9:00-11:00 tomorrow. 

When both are mentioned in the same sentence, as above, it's easy to recognize 
that the two meetings are probably incompatible. But org-mode allows agenda 
items to be created at different times and in different files; it's possible to 
create Meeting #1 far in advance, have enough time to forget that Meeting #1 
exists, and then create Meeting #2 covering the same period of time. (Compare 
this with the wall calendar made of paper, where if I try to add Meeting #2 
I'll be forced to write it in the same physical space, and therefore 
automatically be alerted before making the error.)

Is there any method to get org-mode to alert me (by an error message, or a red 
mark in the agenda, or whatever) that I've created a conflict - specifically, a 
method that doesn't involve me having to remember to perform any type of 
conflict-checking myself? If I could remember to do things like conflict 
checks, I wouldn't really need org-agenda anyway. :-)

I realize that it's likely some situations *do* require timed events to happen 
concurrently - but I don't believe that they're the usual case for an 
individual. Having an "ignore conflict" or "accept anyway" type of option would 
make sense to me for such situations. 

-- 
Thanks
David

Re: Emacs bug 37890; killing capture buffer

[Adam Porter]

Michael Heerdegen  writes:

> Adam Porter  writes:
>
>> I guess you're asking me, since I'm the only other person in this
>> thread--but I'm not an Org maintainer, so my opinion isn't very
>> important.  IMO, the hooks are worth considering, however they should
>> be done very, very carefully, because bad things can happen when
>> functions called in kill hooks don't work as expected (e.g. they can
>> make it very difficult to kill a buffer or the Emacs process,
>> especially for an average user).
>
> Yes, all true.  I didn't even check if the code I posted breaks any
> org commands that kill the buffer.  So far it's only meant for
> demonstration (and my personal usage).
>
> Will my request be noticed here, or do you think I should report it to
> some other place?

I can't speak for what the maintainers are reading.  They are active on
this list, as you can see, but I doubt they have time to read every
message.  If you don't get the response you're looking for, you might
post the proposal in a separate thread, perhaps prefixed with [RFC] or
[PATCH] as appropriate.  They're definitely more likely to notice and
respond to actual patches, but that's not a requirement; if you ask for
specific feedback about a specific idea or code, that usually gets
noticed.

>> > BTW, what about my question whether my original bug report can be
>> > closed?
>>
>> I haven't seen your bug report.  Was there discussion about it
>> previously?
>
> No, no discussion at all.  As I said, it is Emacs bug #37890, this was
> my issue:
>
> | I want to capture an APPT with `org-capture'.  I the pop-up buffer to
> | edit the item I move the date to the second line and add text after the
> | date (personal preference).  That loses the final newline in
> | CAPTURE-todo.org.  As a result, the headline of the item following the
> | item to be inserted gets appended to the last line of the text:
> |
> | ** APPT Abc
> |<2019-10-23 Mi>
> | text... ** APPT 8:30 Important Appointment
> |
> | breaking the whole item.  The user should somehow be prevented from that
> | happening.
>
> It seems it has been resolved, just without noticing my bug report.
> If you can confirm that the cited issue has been cared about, I'll
> close it as done.

I can neither confirm nor deny.  ;)  I do seem to recall discussion of
that issue here recently (the problem, not necessarily your official bug
report of it), and maybe seeing that a fix was made.  If you search the
list archive for this month or November, you should find something--I
think that's the right timeframe.  You might also search the git log for
capture-related commits.  Shouldn't be hard to find if there was
something.

If it helps, none of my capture templates seem to end with newlines, and
I don't see anything in the docstring for org-capture-templates that
suggests one is required, so I don't think one is.  If you're still
having the problem, I'd suggest trying to reproduce it in a clean Emacs
configuration with the latest version of Org.  You may find this script
helpful for that:

https://github.com/alphapapa/alpha-org/blob/master/emacs-sandbox.sh

> BTW, what is the canonical place to report org-mode bugs?  Emacs bug
> reports are not (takes a long time until someone even notices) -- I
> thought this list would be good...or is there a better place?

I think this list is a canonical place.  Some people do report Org bugs
as official bug reports on the Emacs bug tracker.  I don't know whether
the Org maintainers read them all.  Since Org is officially part of
Emacs, sometimes the Emacs maintainers Cc this list about such reports.
Anyway, here is a fine place.

If you're not sure that something is a bug, you might consider
mentioning it on https://old.reddit.com/r/orgmode before posting it
here, since /r/orgmode has a wider audience.

> @Adam it's ok if you answer, though I'm a bit disappointed that no one
> else seems to care so far...

People do care!  But everyone here works on Org in their spare time, and
Org is a big project, and things slip through the cracks.

Re: Emacs bug 37890; killing capture buffer

[Michael Heerdegen]

Adam Porter  writes:

> I guess you're asking me, since I'm the only other person in this
> thread--but I'm not an Org maintainer, so my opinion isn't very
> important.  IMO, the hooks are worth considering, however they should be
> done very, very carefully, because bad things can happen when functions
> called in kill hooks don't work as expected (e.g. they can make it very
> difficult to kill a buffer or the Emacs process, especially for an
> average user).

Yes, all true.  I didn't even check if the code I posted breaks any org
commands that kill the buffer.  So far it's only meant for demonstration
(and my personal usage).

Will my request be noticed here, or do you think I should report it to
some other place?

> > BTW, what about my question whether my original bug report can be
> > closed?
>
> I haven't seen your bug report.  Was there discussion about it
> previously?

No, no discussion at all.  As I said, it is Emacs bug #37890, this was
my issue:

| I want to capture an APPT with `org-capture'.  I the pop-up buffer to
| edit the item I move the date to the second line and add text after the
| date (personal preference).  That loses the final newline in
| CAPTURE-todo.org.  As a result, the headline of the item following the
| item to be inserted gets appended to the last line of the text:
|
| ** APPT Abc
|<2019-10-23 Mi>
| text... ** APPT 8:30 Important Appointment
|
| breaking the whole item.  The user should somehow be prevented from that
| happening.

It seems it has been resolved, just without noticing my bug report.  If
you can confirm that the cited issue has been cared about, I'll close it
as done.

BTW, what is the canonical place to report org-mode bugs?  Emacs bug
reports are not (takes a long time until someone even notices) -- I
thought this list would be good...or is there a better place?   @Adam
it's ok if you answer, though I'm a bit disappointed that no one else
seems to care so far...


Thanks,

Michael.

Re: Babel: Store script in external file

[Berry, Charles]

> On Dec 16, 2019, at 1:53 PM, Michael Gauland  wrote:
> 
> I've just started playing with #+INCLUDE, so I may not be using it correctly, 
> but this works for me.

Indeed, if what the OP wants is to wrap just that code as a src block and 
export it and any results it produces during export then that is the way to go. 

However, `org-babel-execute-buffer' , `org-babel-tangle' and so on will not 
honor the #+INCLUDE directive unless an export is in progress.

HTH,

Chuck

> 
> I have a file 'sh_test', which looks like:
> for i in $(seq 10); do
> echo $i
> done
> 
> My org file:
> #+HEADER: :exports both
> #+INCLUDE: "sh_test" src sh
> 
> And the results:
> 
> ,
> | for i in $(seq 10); do
> | echo $i
> | done
> `
> 
>   1
>   2
>   3
>   4
>   5
>   6
>   7
>   8
>   9
>  10
> 
> Hope that helps.
> 
> Kind regards,
> Mike
> 
> 
> On Mon, Dec 16, 2019 at 2:22 PM Nathan Neff  wrote:
> Hello all,
> 
> I think I'm missing something basic:  I'd like to have something like this:
> 
> #+begin_src python
> #+filename: foo.py
> 
> Instead of storing my Python code in the current org file, I would like
> Babel to read foo.py and execute it, as if it was inside the .org file.
> 
> The foo.py mentioned above is fairly large, and I would like the code
> to be stored in a different file than my .org file, for brevity.
> 
> Any ideas?  I feel like I'm missing something obvious.
> 
> Thanks,
> --Nate

Re: Emacs bug 37890; killing capture buffer

[Adam Porter]

Hi Michael,

Michael Heerdegen  writes:

> Would you consider to do something like this by default?

I guess you're asking me, since I'm the only other person in this
thread--but I'm not an Org maintainer, so my opinion isn't very
important.  IMO, the hooks are worth considering, however they should be
done very, very carefully, because bad things can happen when functions
called in kill hooks don't work as expected (e.g. they can make it very
difficult to kill a buffer or the Emacs process, especially for an
average user).

> BTW, what about my question whether my original bug report can be
> closed?

I haven't seen your bug report.  Was there discussion about it
previously?

Adam

Re: restore window configuration after org-edit-src-exit

[Fraga, Eric]

On Tuesday, 17 Dec 2019 at 06:28, Jack Kamm wrote:
> Basically, when org-src-window-setup is current-window, it never makes
> sense to restore the original layout. But when org-src-window-setup is
> reorganize-frame (the default), it always makes sense to restore the
> original layout.

This makes sense to me.

While we're talking about org-src-window-setup, I set it to
'split-window-right on my large monitor.  Sometimes, I make the src
window full frame but then, when trying to go back to the org buffer
(C-c '), I get the error:

delete-window: Attempt to delete minibuffer or sole ordinary window

This would be fixed if the original layout were restored instead of
simply deleting the src window, I guess.

-- 
Eric S Fraga via Emacs 27.0.50, Org release_9.3-34-g2eee3c

Re: restore window configuration after org-edit-src-exit

[Jack Kamm]

Sorry for the noise, but I just had another thought:

Rather than adding a new option, how about we make the behavior
dependent on the value of org-src-window-setup?

Basically, when org-src-window-setup is current-window, it never makes
sense to restore the original layout. But when org-src-window-setup is
reorganize-frame (the default), it always makes sense to restore the
original layout.

I'm not sure what the "correct" behavior would be for the other options
however.

Now that I think about it, I remember trying out the "current-window"
option before, and having a very similar experience to Matt -- while I
enjoyed having more manual control over the window layout, the fact that
org-mode would change the window layout after I finished editing
defeated the whole purpose of this, so I switched back to the original
defaults.

Re: restore window configuration after org-edit-src-exit

[Jack Kamm]

I'd like to add a vote for the old behavior. I only recently noticed the
new behavior, and agree with Richard that it's inconvenient. I think
many of us missed this change because it wasn't in 9.2.

In particular, I'd propose to make the old behavior the default, and
hide the new behavior behind an option like Matt originally proposed.

I'm updating my copyright papers for my current job, if no one has
submitted a patch by the time I've got that sorted, I could work on a
patch then.

Re: R code block produces no output

[Vikas Rawal]

On Tue, 17 Dec 2019 at 18:13, William Denton  wrote:

> On 17 December 2019, Vikas Rawal wrote:
>
> > A simple code block like the following does not create the graph.
> >
> > #+NAME: test
> > #+BEGIN_SRC R :results output graphics :exports results :file temp.jpg
> :width 2400 :height 1200  :res 300 :session temp
>
> That should be ":results file graphics".
>
>
Thanks very much. This works. I guess this has recently changed. I have
always used ":results output graphics"

Vikas

Re: Help me secure some free time for org-mode in 2020

[Roland Everaert]

Hello Bastien,

Nice to see you are still alive ;)

Sad to read that you plan to stepdown, but, happy to finally have a way
to support your work on a regular basis.

I hope you will continue to be part of this community even as an humble
user ;).

And I hope, everything will be better for you in the coming years.

I am really grateful to you, Nicolas, Carsten and all the maintainers of
this amazing tool, which, with emacs preserve my sanity in this crazy
life that is the IT.

Regards,

Roland.
Bastien writes:

> Dear all,
>
> I have been involved in Org-mode development when Carsten offered me
> to take over maintainance, back in 2010.
>
> I still feel grateful for the opportunity he gave me: his dedication
> to make Org a useful tool for Emacs users was examplary and I did my
> very best to give to the community as much as I received from it.
>
> Over the last years, Nicolas de facto took over maintainance and it
> was a real relief for me: I was struggling with my finances and this
> was eating up all my free time.  Nicolas steadily played the role I
> played for years, reassuring users that someone was on board, that
> bugs would be fixed and new features discussed on this mailing list.
>
> My plan for 2020 is to ensure a smooth transition while I step down
> as the maintainer---at least by the end of 2020, probably by July.
>
> As my timetable (and family life) has become more stable, I am more
> confident I can dedicate some of my free time again to maintaining
> until the transition is done: also because there are many ideas I
> would like to try, discuss and implement---Org possibilities still
> feel endless!
>
> If you want to help me secure some free time, please go ahead!
>
> I recommend using https://liberapay.com/bzg
>
> If you cannot, there are also these services:
>
> https://github.com/sponsors/bzg
> https://www.paypal.me/bzg
>
> You can also help by sharing the messages I sent:
> https://mastodon.etalab.gouv.fr/@bzg/103318485790068452
> https://twitter.com/bzg2/status/1206617096462983169
>
> I would love stepping down while releasing Org 10 and making this
> one of the best release ever.  Thanks!


--
Luke, use the FOSS

Sent from Emacs

Re: R code block produces no output

[William Denton]

On 17 December 2019, Vikas Rawal wrote:


A simple code block like the following does not create the graph.

#+NAME: test
#+BEGIN_SRC R :results output graphics :exports results :file temp.jpg :width 
2400 :height 1200  :res 300 :session temp


That should be ":results file graphics".

Bill
--
William Denton :: Toronto, Canada   ---   Listening to Art: 
https://listeningtoart.org/
https://www.miskatonic.org/ ---   GHG.EARTH: https://ghg.earth/
Caveat lector.  ---   STAPLR: https://staplr.org/

R code block produces no output

[Vikas Rawal]

I have a strange problem and I wonder if there is a new bug. Would
appreciate for any help in identifying the problem.

A simple code block like the following does not create the graph.

#+NAME: test
#+BEGIN_SRC R :results output graphics :exports results :file temp.jpg
:width 2400 :height 1200  :res 300 :session temp
   library(ggplot2)
data.frame(date=c(1:10),ifpa=c(11:20))->t
ggplot(t,aes(x=date,y=ifpa))->p
p+geom_point()
#+end_src

When I compile this using C-c C-c, I get the following message:

executing R code block (test)...
Code block produced no output.

The code produces the right graph when I do C-c ' to go into an ESS buffer
and execute these commands.

I am on following versions of Org and Emacs:

Org mode version 9.3 (9.3-8-geab7c4-elpaplus @
/home/vikas/.emacs.d/elpa/org-plus-contrib-20191209/)
GNU Emacs 26.3 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.10) of
2019-08-30


Thanking you and with best wishes,

Vikas

Re: [Nicolò Balzarotti] [bug#38616] emacs: fix odt export

[Nicolas Goaziou]

Hello,

another...@gmail.com (Nicolò Balzarotti) writes:

> The problem happens on ox-odt, when the file OrgOdtStyles.xml
> permissions are read-only (this is true especially for Guix and Nix
> where all the "store" is readonly). The file gets copied to /tmp/ob-*/
> directory, and is then modified. However, the file is assumed to be
> read/write. When the file is not, the export fails. I've sent a one-line
> patch (simply change permissions to the newly-copied file):
>
>> (set-file-modes (concat org-odt-zip-dir "styles.xml") #o600)
>
> to guix-patches (here in CC, I'm also forwarding my original patch
> submission here), but I've been suggested to send the patch upstream.
>
> What do you think? I can submit a proper patch if needed (but feel free
> to patch it yourself)

It sounds good. Could you send a patch against "maint" branch?

Thank you.

Regards,

-- 
Nicolas Goaziou

Re: Manual Typo in Table Section

[Nicolas Goaziou]

Hello,

Ben Polson  writes:

> Specifically with this example formula:
> ‘@3 = 2 * remote(FOO, @@1$$#)’
>
> As I've been playing around with tables and formulas I've come to the
> conclusion that '@@1' must be a typo, and that what was intended was just
> '@1'. I have a few qualms about this table section in general, but felt
> that this particular typo was an important one to highlight.

You are right. Fixed.

The manual definitely needs to be improved in that area (remote
references).

Thank you.

Regards,

-- 
Nicolas Goaziou