[O] Bug: exclude symlinked directory from publishing [9.1.6 (9.1.6-57-gec8590-elpa @ /home/michel/.emacs.d/elpa/org-20180219/)]
Remember to cover the basics, that is, what you expected to happen and what in fact did happen. You don't know how to make a good report? See https://orgmode.org/manual/Feedback.html#Feedback Your bug report will be posted to the Org mailing list. Hello, When publishing (with org-publish) I'd like to exclude a subdirectory : in fact it is a symlink (named lib) to a directory outside of the tree to be published For example with this tree : /media/DATA/ lib --> other directory other pdf files in org-publish-project-alist I tried :exclude "lib$" or :exclude ".*lib/.*" org-publish-attachment correctly treats "other pdf files" but also publish all pdf files contained in "other directory" Thanks for your help
Re: [O] How to keep correct filepaths when using the #+INCLUDE derivative?
Hello, Daniel P Gomez writes: > I noticed that (buffer-file-name (buffer-base-buffer)) will always > return nil because `org-export--prepare-file-contents` is called in > `org-export-include-keyword` after a call to `with-temp-buffer`. Two > possible solutions to this issue would be either 1. passing the > includer-file as an extra parameter to > `org-export--prepare-file-contents` and then using > `file-relative-name` to generate a relative path, or alternatively 2 . > passing the matched string that points to the file to be included. > Example: > > #+INCLUDE: "directory/file.org" > > Here, if file.org contains a link [[other/image.png]], then all one > has to do is append the (file-name-directory matched) to the old-path. > In this example this would result in directory/other/image.png. > > This second solution does not require a call to (buffer-file-name > (buffer-base-buffer)), but seems hackish in the sense that we would > pass 2 redundant arguments to `org-export-prepare-file-contents`: both > the expanded and the non-expanded include-file filename. > Perhaps I'm missing a simpler 3rd solution? I think solution 1 is fine. > If we opt for solution 1 then new-path could be made relative here >> ;; (org-element-put-property new :path new-path) > > (org-element-put-property >new :path >(if includer-file >(file-relative-name > new-path (file-name-directory includer-file)) > new-path)) Indeed. However, the (if includer-file ...) should be integrated in new-path binding, IMO. > I will attempt to write them once the implementation is completed. Great. Thank you! Regards, -- Nicolas Goaziou0x80A93738
Re: [O] Bug: Mode line face is not updated when clock overruns [9.1.7 (release_9.1.7-466-ga16590.dirty @ /home/luke/elisp/org-mode/lisp/)]
Hello,
Luke writes:
> The face of the clocked time does not seem to change when the clock
> overruns (typically it changes to a red background).
>
> I'm no lisp expert, but after digging around in the code it looks like
> the problem is in org-clock-get-clock-string():
>
> 662 (defun org-clock-get-clock-string ()
> 663 "Form a clock-string, that will be shown in the mode line.
> 664 If an effort estimate was defined for the current item, use
> 665 01:30/01:50 format (clocked/estimated).
> 666 If not, show simply the clocked time like 01:50."
> 667 (let ((clocked-time (org-clock-get-clocked-time)))
> 668 (propertize
> 669 (if org-clock-effort
>
> ...
>
> 683 'face 'org-mode-line-clock)))
>
> It seems like the call to propertize (on line #668) is overwriting the
> face ('org-mode-line-clock-overrun) of the resulting string with
> 'org-mode-line-clock. I think this change was introduced in commit
> 6655429b8d.
Fixed. Thank you.
Regards,
--
Nicolas Goaziou
[O] Concatenating header args
Hello, how can I concatenate header args? Let's assume I have an Org structure like follows: * foo :PROPERTIES: :header-args: :flags -Wall :END: ** bar #+begin_src C :flags -lm #+end_src Now I want the code to be compiled with -Wall _and_ -lm. Regards hmw
Re: [O] [RFC] Moving "manual.org" into core
Aloha Bastien, Bastien Guerry writes: Maybe this is where some misunderstanding arose: to me, there was no _project_ to migrate to manual.org -- it was an idea in the air after you made your experiment and we now have the decision at hand because the project is, well, DONE. We could have done it another way: we could have discussed it as a project, then anticipated that it will prevent Org's code to migrate to Emacs repository, then discussed the pros and cons before investing more time. Thanks for pointing out this alternative. Several of us working on the manual did recently discuss various issues on the list. Nicolas had several messages, I responded to most of them, and others chimed in on particular parts: Achim Gratz, Kyle Meyer, and Kaushal Modi come to mind immediately, but there may have been others. In the past, we could have been assured Carsten would join the discussion in one way or another as maintainer, working to keep us on track and guide us to the most productive use of our time. However, you have chosen to fulfill the duties of maintainer in a different way, one that does not involve day-to-day interaction with the volunteers who are themselves choosing to spend time trying to augment and improve Org mode. I don't argue with this decision of yours, but to my mind, this is why we are where we are today. Certainly, if I had understood in 2013 that my efforts would eventually work against Org mode by preventing migration of its code to Emacs repository (an issue that I don't understand fully but accept as valid), then I would have saved that time for other pursuits. But, you did not say this at the time, as far as I remember. My memory is that you were mostly silent. Similarly, it was clear to me from lurking on the list last year that Nicolas was going to revive the project. I believe it was also clear to the others who participated in the conversation on list, but I don't want to speak for them. You either did not read that discussion or you did read it and chose not to participate. Work on the manual project wasn't a secret. From my point of view, your involvement has come at the 11th hour, well after much effort has been expended on what several of our colleagues believe is a contribution to Org mode. I'm pleased that you are willing to give the project a try, but I want to insist that you take some responsibility for where we are in this discussion. I cannot accept that the maintainer scolds me and others who worked on the project that "we could have done it another way." This is exactly the responsibility I want to insist the maintainer accept. We look to the maintainer for guidance. Please give it to us in a timely manner. All the best, Tom -- Thomas S. Dye http://www.tsdye.com
[O] [Error] (was: how do you compose mails in Gnus with org-mode)
>>> "Thorsten" == Thorsten Jolitz writes:
> Joseph Vidal-Rosset writes:
> Hallo
>> I know that the subject of my email exists already.
>> [[https://lists.gnu.org/archive/html/emacs-orgmode/2009-08/msg00855.html]]
> This works perfectly for your subject:
> ,[ C-h f outorg-edit-as-org RET ]
Thanks for the pointer, but alas it does not work in a gnus message/mail
buffer.
When I use that function I obtain the following error:
Debugger entered--Lisp error: (error "Before first heading")
signal(error ("Before first heading"))
error("Before first heading")
outline-back-to-heading()
outline-end-of-subtree()
outorg-save-markers((point-marker beg-of-subtree-marker mark-marker
org-clock-marker org-clock-hd-marker org-clock-default-task
org-clock-interrupted-task selected-task org-open-link-marker
org-log-note-marker org-log-note-return-to
org-entry-property-inherited-from))
outorg-edit-as-org(nil)
funcall-interactively(outorg-edit-as-org nil)
call-interactively(outorg-edit-as-org nil nil)
command-execute(outorg-edit-as-org)
Did you check this command, how do you use it?
Regards
Uwe Brauer
Re: [O] how do you compose mails in Gnus with org-mode
>>> "Thorsten" == Thorsten Jolitz writes: > Joseph Vidal-Rosset writes: > Hallo >> I know that the subject of my email exists already. >> [[https://lists.gnu.org/archive/html/emacs-orgmode/2009-08/msg00855.html]] > This works perfectly for your subject: I just realised that you are the author of that package. Sorry. I set (require 'outorg) (require 'outshine) (add-hook 'outline-minor-mode-hook 'outshine-hook-function) (add-hook 'message-mode-hook 'outline-minor-mode) But when I fire up outorg-edit-as-org in a reply message I obtain the error I described in my earlier message. Uwe Brauer
Re: [O] [RFC] Moving "manual.org" into core
My 2¢ on this topic: 1. org is an excellent tool for writing. I cannot consider writing with any other tool these days. 2. texi is an excellent tool for reading/browsing documentation. Likewise, I cannot imagine doing so in another tool (in the Emacs sphere). We should find a way to allow the manual to be written in org with the manual ready to read in info. As a user (and sometime contributor in small ways) of emacs over the past 35 (!) years, I would hate to see it ossify again as it did during the 90s. We must move forward and nothing should be cast in stone in terms of development, whether for code or documentation. If this means, as suggested by somebody along the way, that the result is an increase in the building time for Emacs, I think this is a small price to pay. I would venture to guess that >99% of Emacs's users are not building their own version but simply installing the binary for their systems. And I'm sure that even for those that build Emacs from source, when testing new code, could be given the choice to build documentation or not. That's what makefiles are for... In any case, thanks to all involved. The effort that *all* of you in this thread put in day in day out is highly welcome and much appreciated! Thanks for listening. -- Eric S Fraga via Emacs 27.0.50, Org release_9.1.6-191-g90607d signature.asc Description: PGP signature
Re: [O] Concatenating header args
I am pretty sure this isn't possible. The headers get overridden by the most local settings. There isn't a way to concatenate them. In some cases there isn't a way to figure out what you want, e.g. if a heading property said ":tangle no" and your header said ":tangle yes" it would not make sense to concatenate these to ":tangle no yes". I think you have to add -Wall to the src header. John --- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu On Tue, Mar 6, 2018 at 1:25 AM, Michael Welle wrote: > Hello, > > how can I concatenate header args? Let's assume I have an Org structure > like follows: > > * foo > :PROPERTIES: > :header-args: :flags -Wall > :END: > ** bar > #+begin_src C :flags -lm > #+end_src > > Now I want the code to be compiled with -Wall _and_ -lm. > > Regards > hmw > >
[O] Agenda bug
I discovered that the lines ( the body of a headline): *** real headline * example :SCHEDULED: cause agenda processing to fail. It tries to parse as a timestamp. The parser used by agenda appears not to enforce the requirement that headlines begin with asterisks on the left margin. Removing either the leading colon or the asterisk on example fixes the problem. Regular display parsing does not get confused. The highlighting and font changes do not consider the " * example" to be a headline. -- Robert Horn rjh...@alum.mit.edu
Re: [O] Agenda bug
On Tuesday, 6 Mar 2018 at 11:23, Robert Horn wrote: > I discovered that the lines ( the body of a headline): > *** real headline >* example >:SCHEDULED: > > cause agenda processing to fail. It tries to parse as a > timestamp. The parser used by agenda appears not to enforce the > requirement that headlines begin with asterisks on the left margin. I think the issue is that SCHEDULED and DEADLINE entries must appear immediately after the headline. You have a line (* example) in between the SCHEDULED line and the headline. -- Eric S Fraga via Emacs 27.0.50, Org release_9.1.6-191-g90607d signature.asc Description: PGP signature
Re: [O] [RFC] Moving "manual.org" into core
Hello Thomas, as a preamble, let me say that I appreciate the directness of your message and the civil tone of this conversation. I understand there are frustrations lingering around, I have my own too, so let's keep this thread as constructive as possible, because we all deserve it as a community. Let me separate two questions: one is my attitude in dealing with this migration; another one is my general ability as a maintainer. The first question naturally leads to the other one, but the last one exists per se and I'll take this opportunity to say a few words. So, about this manual migration. Here is a quick timeline: In 2013, I said it was a nice experiment. In 2014, I said I would be "more than happy" if you and others could progress on this: http://thread.gmane.org/gmane.emacs.orgmode/85574 In 2016, Charles quoted me saying: "Where Bastien says: "the day we can export org.org to org.texi with very little headache and ad hoc configuration, yes, we will make the move."" In January 2018, I said: "Having the manual in .org is a great achievement, congrats to anyone who worked on this titanic task! I'm all for editing manual.org instead of org.texi in the long run." In March 2018, I said there was no blocker, "please move ahead". So I don't think I have been scolding you or anyone working on this, quite on the contrary. In my message from 2014, I said I won't have time to dedicate to the project. And while I was kind of skeptical about the idea, I have been consistent in sending encouragements and in not blocking it. Maybe I should have explained why I was skeptical: but in 2013-2015, it was just a gut feeling, and expressing it would probably have been unproductive; then when I had this project to develop Org from within Emacs, I was not so sure about it either, so I was first cautious not to raise premature objections. When Nicolas sollicited the list again in january, I tried to make a few inputs: not as constructive as I'd wish they were, but still. Now, my main input is this: LET'S GO! So... I completely recognize my general lack of responsiveness is a problem and it may have been a problem in this case, but I hope you see that I carefully tried not to block anyone's work on this. Again: asking inputs from emacs-devel@ is not a way of delaying or blocking, it is just something normal to do considering the move. So now let's close this issue, I'll write to emacs-devel@ and we will make the switch. Now, about my general experience and attitude as a maintainer. I started to take care of Org-mode in 2011, on January 1st. Seven years ago... time flies :) I've been involved in code and communication on the list on a daily basis until septembre 2012, the day my daughter was born. Stats may prove my memory is wrong here, but I think I stayed closely committed until septembre 2014. Enters life: I had a burn out, a break up and I was broke. Like in: completely broke, no job, no place to stay. I asked Nicolas whether he would considered to be the maintainer on several occasions -- the first one dating back to november 2011. We always had a frank conversation about this. Nicolas declined, but we managed to find a balanced way of collaborating and I confidently moved from being proactive to being more of a release manager. Despite not being the "official" maintainer, Nicolas is the de facto one since 2015. And again, I cannot express how much I owe to Nicolas and his consistency for the last three years. But believe me: I wish I could continue to spend one or two hours per day coding and communicating on the mailing list: because, it's kind of a home for me. But I could not. And I cannot. So here is my plan: - We make the switch to using manual.org. - We release Org 9.2. - I extract the contrib/ directory from org-mode.git into a separate org-contrib.git to live on code.orgmode.org (something I've wanted for long). - I go down my org-mode TODO list to see if there are importants bugs and features I wish to work on. - In the meantime, I find a new maintainer. - We release Org 10 and the new maintainer takes on. I think the whole process can take from 2 to 3 months, and I'm ready to dedicate more time to Org during these months. WDYT? -- Bastien
Re: [O] [RFC] Moving "manual.org" into core
Hi Kaushal, Kaushal Modi writes: > Exactly. Emacs will anyways ship with org.texi. So moving the manual > source to Org in the Org repo shouldn't concern the Emacs repo. Yes, but it is still a concern for Emacs contributors like Glenn and others who occasionnally make corrections in Emacs' org.texi. I'm fine if we can backport these corrections by hand for the time being. -- Bastien
Re: [O] [RFC] Moving "manual.org" into core
Hi Nicolas, Nicolas Goaziou writes: > You recently re-introduced a file named "orgmanual.org" in contrib/ > alongside "manual.org". The former is apparently outdated. Yes, my mistake, fixed now. -- Bastien
Re: [O] [RFC] Moving "manual.org" into core
phillip.l...@russet.org.uk (Phillip Lord) writes: > Probably, by the time all of the manuals are in org-mode, > machines will be significantly faster, there will be emacs-free org mode > converter, or we will have hit the heat death of the universe. Perhaps > it's not a problem. :) The output of pandoc is encouraging but not usable yet. ~$ pandoc -f org -t texinfo contrib/manual.org > org2.texi -- Bastien
Re: [O] [Error]
Uwe Brauer writes:
"Thorsten" == Thorsten Jolitz writes:
>
>> Joseph Vidal-Rosset writes:
>> Hallo
>
>>> I know that the subject of my email exists already.
>>>
> [[https://lists.gnu.org/archive/html/emacs-orgmode/2009-08/msg00855.html]]
>
>> This works perfectly for your subject:
>
>> ,[ C-h f outorg-edit-as-org RET ]
>
> Thanks for the pointer, but alas it does not work in a gnus message/mail
> buffer.
Hello,
I' pretty sure your outshine config is not complete:
Here is what I have:
at the top of my .emacs:
,
| ;; *** Global Keys
|
| ;; must be set before outline is loaded
| (defvar outline-minor-mode-prefix "\M-#")
`
then somewhere inside my .emacs (don't worry about "try-require", simply
use "require" in your code). outorg-export is optional too (but useful
for special needs in outorg exporting), I would highly recomment
navi-mode though (very fast navigation in outshine buffers).
,
| ;; ** Outline
|
| (message "\n-- entering outline --")
|
| (when (try-require 'outline)
| (add-hook 'emacs-lisp-mode-hook 'outline-minor-mode)
| (add-hook 'message-mode-hook 'outline-minor-mode))
|
| ;; outorg-export
| (try-require 'outorg-export)
|
| ;; outshine
| (try-require 'outshine)
| (add-hook 'outline-minor-mode-hook 'outshine-hook-function)
|
| (setq outshine-use-speed-commands t)
|
| ;; navi-mode
| (try-require 'navi-mode)
`
most likely this line is missing, add it:
,
| (add-hook 'outline-minor-mode-hook 'outshine-hook-function)
`
Note that I did this:
,
| (add-hook 'xyz-mode-hook 'outline-minor-mode)
`
for many other modes too, like ESS, picolisp, ledger, latex ... etc
HTH
> When I use that function I obtain the following error:
>
> Debugger entered--Lisp error: (error "Before first heading")
> signal(error ("Before first heading"))
> error("Before first heading")
> outline-back-to-heading()
> outline-end-of-subtree()
> outorg-save-markers((point-marker beg-of-subtree-marker mark-marker
> org-clock-marker org-clock-hd-marker org-clock-default-task
> org-clock-interrupted-task selected-task org-open-link-marker
> org-log-note-marker org-log-note-return-to
> org-entry-property-inherited-from))
> outorg-edit-as-org(nil)
> funcall-interactively(outorg-edit-as-org nil)
> call-interactively(outorg-edit-as-org nil nil)
> command-execute(outorg-edit-as-org)
>
>
> Did you check this command, how do you use it?
>
> Regards
>
> Uwe Brauer
>
>
>
--
cheers,
Thorsten
Re: [O] how do you compose mails in Gnus with org-mode
Uwe Brauer writes: "Thorsten" == Thorsten Jolitz writes: > >> Joseph Vidal-Rosset writes: >> Hallo > >>> I know that the subject of my email exists already. >>> > [[https://lists.gnu.org/archive/html/emacs-orgmode/2009-08/msg00855.html]] > >> This works perfectly for your subject: > > I just realised that you are the author of that package. Sorry. > > I set > > (require 'outorg) > (require 'outshine) > (add-hook 'outline-minor-mode-hook 'outshine-hook-function) > > (add-hook 'message-mode-hook 'outline-minor-mode) ok, maybe I answered the wrong message, does not look that incomplete actually. Maybe try a copy of my config. I used outorg-edit-as-org to insert and evaluate these source blocks directly in this email, so for me it works: #+BEGIN_SRC emacs-lisp (emacs-version) #+END_SRC #+results: : GNU Emacs 25.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.22.26) : of 2018-02-09 #+BEGIN_SRC emacs-lisp (org-version) #+END_SRC #+results: : 8.2.10 #+BEGIN_SRC emacs-lisp (gnus-version) #+END_SRC #+results: : Gnus v5.13 > But when I fire up outorg-edit-as-org in a reply message I obtain the > error I described in my earlier message. > > Uwe Brauer -- cheers, Thorsten
Re: [O] how do you compose mails in Gnus with org-mode
Thorsten Jolitz writes: > Uwe Brauer writes: > > "Thorsten" == Thorsten Jolitz writes: >> >>> Joseph Vidal-Rosset writes: >>> Hallo >> >>>> I know that the subject of my email exists already. >>>> >> [[https://lists.gnu.org/archive/html/emacs-orgmode/2009-08/msg00855.html]] >> >>> This works perfectly for your subject: >> >> I just realised that you are the author of that package. Sorry. >> >> I set >> >> (require 'outorg) >> (require 'outshine) >> (add-hook 'outline-minor-mode-hook 'outshine-hook-function) >> >> (add-hook 'message-mode-hook 'outline-minor-mode) PS you do have this variable defined, right? , | mail-header-separator is a variable defined in ‘sendmail.el’. | Its value is "--text follows this line--" | | Documentation: | Line used to separate headers from text in messages being composed. | | You can customize this variable. ` the value is not important, but it can't be nil. > ok, maybe I answered the wrong message, does not look that incomplete > actually. Maybe try a copy of my config. > > I used outorg-edit-as-org to insert and evaluate these source blocks > directly in this email, so for me it works: > > #+BEGIN_SRC emacs-lisp > (emacs-version) > #+END_SRC > > > #+results: > : GNU Emacs 25.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.22.26) > : of 2018-02-09 > > #+BEGIN_SRC emacs-lisp > (org-version) > #+END_SRC > > > #+results: > : 8.2.10 > > #+BEGIN_SRC emacs-lisp > (gnus-version) > #+END_SRC > > #+results: > : Gnus v5.13 > >> But when I fire up outorg-edit-as-org in a reply message I obtain the >> error I described in my earlier message. >> >> Uwe Brauer -- cheers, Thorsten
Re: [O] [RFC] Moving "manual.org" into core
Hi Nicolas, Nicolas Goaziou writes: > I disagree. My motivation is not to attract more contributors. I don't > think this was Thomas and Jonathan's motivation when they started the > project either, but I may be wrong. For the record, I think having more contributors for the manual is a very sane goal. -- Bastien
Re: [O] how do you compose mails in Gnus with org-mode
>>> "Thorsten" == Thorsten Jolitz writes: > Uwe Brauer writes: > "Thorsten" == Thorsten Jolitz writes: >> >> > Joseph Vidal-Rosset writes: >> > Hallo >> >> >> I know that the subject of my email exists already. >> >> [[https://lists.gnu.org/archive/html/emacs-orgmode/2009-08/msg00855.html]] >> >> > This works perfectly for your subject: >> >> I just realised that you are the author of that package. Sorry. >> >> I set >> >> (require 'outorg) >> (require 'outshine) >> (add-hook 'outline-minor-mode-hook 'outshine-hook-function) >> >> (add-hook 'message-mode-hook 'outline-minor-mode) > ok, maybe I answered the wrong message, does not look that incomplete > actually. Maybe try a copy of my config. > I used outorg-edit-as-org to insert and evaluate these source blocks > directly in this email, so for me it works: I still can't > #+BEGIN_SRC emacs-lisp > (emacs-version) > #+END_SRC > #+results: > : GNU Emacs 25.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.22.26) > : of 2018-02-09 GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2018-01-25" > #+BEGIN_SRC emacs-lisp > (org-version) > #+END_SRC Git master from June 2017 so relatively recent > #+results: > : 8.2.10 > #+BEGIN_SRC emacs-lisp > (gnus-version) > #+END_SRC > #+results: > : Gnus v5.13 The same here. >> But when I fire up outorg-edit-as-org in a reply message I obtain the >> error I described in my earlier message. >> >> Uwe Brauer
Re: [O] [RFC] Moving "manual.org" into core
Hi Achim, Achim Gratz writes: > I've posted a working Makefile back when Thomas was working on the > manual and it is still working with minimal modifications. If you > decide you want to have this (and exactly which way) I'm sure that can > be further refined in a matter of days (not weeks) to everyones > satisfaction if that should be necessary. That's great to read, thanks in advance. -- Bastien
Re: [O] [RFC] Moving "manual.org" into core
Aloha Bastien, I disagree that the manual project should move into a one year probation where success is measured by the number of contributors. So, my response to LETS GO! is NOT THERE! Instead, let's move the project forward with the understanding that if it proves to be a bad idea, then the Org mode community will have Nicolas' very nice .texi file (with backports by Kyle Meyer) to fall back on. On the issue of your work on Org mode, I'm hoping your circumstances will allow you to be more involved, not less. All the best, Tom Bastien writes: Hello Thomas, as a preamble, let me say that I appreciate the directness of your message and the civil tone of this conversation. I understand there are frustrations lingering around, I have my own too, so let's keep this thread as constructive as possible, because we all deserve it as a community. Let me separate two questions: one is my attitude in dealing with this migration; another one is my general ability as a maintainer. The first question naturally leads to the other one, but the last one exists per se and I'll take this opportunity to say a few words. So, about this manual migration. Here is a quick timeline: In 2013, I said it was a nice experiment. In 2014, I said I would be "more than happy" if you and others could progress on this: http://thread.gmane.org/gmane.emacs.orgmode/85574 In 2016, Charles quoted me saying: "Where Bastien says: "the day we can export org.org to org.texi with very little headache and ad hoc configuration, yes, we will make the move."" In January 2018, I said: "Having the manual in .org is a great achievement, congrats to anyone who worked on this titanic task! I'm all for editing manual.org instead of org.texi in the long run." In March 2018, I said there was no blocker, "please move ahead". So I don't think I have been scolding you or anyone working on this, quite on the contrary. In my message from 2014, I said I won't have time to dedicate to the project. And while I was kind of skeptical about the idea, I have been consistent in sending encouragements and in not blocking it. Maybe I should have explained why I was skeptical: but in 2013-2015, it was just a gut feeling, and expressing it would probably have been unproductive; then when I had this project to develop Org from within Emacs, I was not so sure about it either, so I was first cautious not to raise premature objections. When Nicolas sollicited the list again in january, I tried to make a few inputs: not as constructive as I'd wish they were, but still. Now, my main input is this: LET'S GO! So... I completely recognize my general lack of responsiveness is a problem and it may have been a problem in this case, but I hope you see that I carefully tried not to block anyone's work on this. Again: asking inputs from emacs-devel@ is not a way of delaying or blocking, it is just something normal to do considering the move. So now let's close this issue, I'll write to emacs-devel@ and we will make the switch. Now, about my general experience and attitude as a maintainer. I started to take care of Org-mode in 2011, on January 1st. Seven years ago... time flies :) I've been involved in code and communication on the list on a daily basis until septembre 2012, the day my daughter was born. Stats may prove my memory is wrong here, but I think I stayed closely committed until septembre 2014. Enters life: I had a burn out, a break up and I was broke. Like in: completely broke, no job, no place to stay. I asked Nicolas whether he would considered to be the maintainer on several occasions -- the first one dating back to november 2011. We always had a frank conversation about this. Nicolas declined, but we managed to find a balanced way of collaborating and I confidently moved from being proactive to being more of a release manager. Despite not being the "official" maintainer, Nicolas is the de facto one since 2015. And again, I cannot express how much I owe to Nicolas and his consistency for the last three years. But believe me: I wish I could continue to spend one or two hours per day coding and communicating on the mailing list: because, it's kind of a home for me. But I could not. And I cannot. So here is my plan: - We make the switch to using manual.org. - We release Org 9.2. - I extract the contrib/ directory from org-mode.git into a separate org-contrib.git to live on code.orgmode.org (something I've wanted for long). - I go down my org-mode TODO list to see if there are importants bugs and features I wish to work on. - In the meantime, I find a new maintainer. - We release Org 10 and the new maintainer takes on. I think the whole process can take from 2 to 3 months, and I'm ready to dedicate more time to Org during these months. WDYT? -- Thomas S. Dye http://www.tsdye.com
Re: [O] how do you compose mails in Gnus with org-mode
> Thorsten Jolitz writes: > PS > you do have this variable defined, right? > , > | mail-header-separator is a variable defined in ‘sendmail.el’. > | Its value is "--text follows this line--" > | > | Documentation: > | Line used to separate headers from text in messages being composed. > | > | You can customize this variable. > ` > the value is not important, but it can't be nil. Yes , | mail-header-separator is a variable defined in ‘sendmail.el’. | Its value is "--text follows this line--" | | Documentation: | Line used to separate headers from text in messages being composed. | | You can customize this variable. | | [back] `
Re: [O] org-adapt-indentation 'content (was Re: [RFC] Moving "manual.org" into core)
Hi Nicolas, Christian Moe writes: >>> Me too, for the same argument. But this points to a strong limitation >>> to `org-adapt-indentation' for which I'd like to propose this change. >>> >>>(setq org-adapt-indentation t) => current behavior >>> (setq org-adapt-indentation nil) => current behavior >>> (setq org-adapt-indentation 'content) => only adapt content's >>> indentation, not that of the property drawer. >> >> I proposed this very change some years ago, but it didn't get much >> traction and wasn't implemented in the end. > > FWIW, I'd like this. Just to make sure we don't lose this idea: do you have code for this? If not, I'll put a stab at it, I think it would be nice. Thanks! -- Bastien
Re: [O] [RFC] Moving "manual.org" into core
Hi Thomas, "Thomas S. Dye" writes: > Instead, let's move the project forward with the understanding that > if it proves to be a bad idea, then the Org mode community will have > Nicolas' very nice .texi file (with backports by Kyle Meyer) to fall > back on. Maybe we are miscommunicating, because that's exactly what I suggest! I just want to make sure we have *at least* one year to prove this to be a good idea. I will probably not be the maintainer by then, so the decision will be in the hands of the maintainer and the community. > On the issue of your work on Org mode, I'm hoping your circumstances > will allow you to be more involved, not less. I hope having a new maintainer would help me to be more in control of what I can focus on. And it's not as if would leave the list :) All best, -- Bastien
Re: [O] how do you compose mails in Gnus with org-mode
Uwe Brauer writes:
"Thorsten" == Thorsten Jolitz writes:
>
>> Uwe Brauer writes:
>> "Thorsten" == Thorsten Jolitz writes:
>>>
>>> > Joseph Vidal-Rosset writes:
>>> > Hallo
>>>
>>> >> I know that the subject of my email exists already.
>>> >> [[https://lists.gnu.org/archive/html/emacs-orgmode/2009-08/msg00855.html]]
>>>
>>> > This works perfectly for your subject:
>>>
>>> I just realised that you are the author of that package. Sorry.
>>>
>>> I set
>>>
>>> (require 'outorg)
>>> (require 'outshine)
>>> (add-hook 'outline-minor-mode-hook 'outshine-hook-function)
>>>
>>> (add-hook 'message-mode-hook 'outline-minor-mode)
>
>> ok, maybe I answered the wrong message, does not look that incomplete
>> actually. Maybe try a copy of my config.
>
>> I used outorg-edit-as-org to insert and evaluate these source blocks
>> directly in this email, so for me it works:
> I still can't
>
>> #+BEGIN_SRC emacs-lisp
>> (emacs-version)
>> #+END_SRC
>
>
>> #+results:
>> : GNU Emacs 25.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.22.26)
>> : of 2018-02-09
>
>
> GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, Xaw3d
> scroll bars)
> of 2018-01-25"
Wow, emacs 27 ... I'm on Archlinux and always thought packages a pretty
up-to-date.
Maybe outline has changed somehow between Emacs 25 and Emacs 27?
But I don't think so, the error you send is pretty typical for
incomplete configuration.
> Debugger entered--Lisp error: (error "Before first heading")
> signal(error ("Before first heading"))
> error("Before first heading")
> outline-back-to-heading()
is typical when
,
| outorg-prepare-message-mode-buffer-for-editing ()
`
has not run, it turns this line into a 1st level org headline thus
converting any kind of message body into an org file.
,
| * --text follows this line--
| Uwe Brauer writes:
`
without this, the error is justified - an org file without a single
org headline is no org file at all.
You could try to write an email with these lines:
,
| * 1st level
| ** 2nd level
| some text
`
put point on some text an call outorg, to see if it works.
Another option would be to use edebug:
open outorg.el, put point into 'outorg-edit-as-org', and call M-x
edebug-defun. Then convert an email again, and go step-by-step with
SPACE key, and see how far you get.
When done, call 'load-library' on outorg.el to get rid of edebug
instrumentation.
>> #+BEGIN_SRC emacs-lisp
>> (org-version)
>> #+END_SRC
>
> Git master from June 2017 so relatively recent
>
>> #+results:
>> : 8.2.10
>
>> #+BEGIN_SRC emacs-lisp
>> (gnus-version)
>> #+END_SRC
>
>> #+results:
>> : Gnus v5.13
>
> The same here.
>
>>> But when I fire up outorg-edit-as-org in a reply message I obtain the
>>> error I described in my earlier message.
>>>
>>> Uwe Brauer
>
>
>
--
cheers,
Thorsten
Re: [O] Agenda bug
Eric S Fraga writes: > On Tuesday, 6 Mar 2018 at 11:23, Robert Horn wrote: >> I discovered that the lines ( the body of a headline): >> *** real headline >>* example >>:SCHEDULED: >> >> cause agenda processing to fail. It tries to parse as a >> timestamp. The parser used by agenda appears not to enforce the >> requirement that headlines begin with asterisks on the left margin. > > I think the issue is that SCHEDULED and DEADLINE entries must appear > immediately after the headline. You have a line (* example) in between > the SCHEDULED line and the headline. You have characterized the bug. That ":SCHEDULED:" should not have been considered a SCHEDULED entry. It should have been ignored, based on the description for org format in the manual. I was putting together an example for someone and was composing a full example of an org file. I just stumbled across this when trying various forms of verbatim, code, and other blocks. I was not expecting the agenda display and processing to completely fail. I created my example by eliminating one of the colons and explaining that in a real org file you would need the colon. But that leaves the bug that this particular error causes agenda creation to fail. I was expecting the parser to treat the SCHEDULED line as just more body text, and ignore it. -- Robert Horn rjhorn...@gmail.com
Re: [O] Adding an item to the agenda from the agenda view
Dear all, Many thanks for your responses. So as I understand it,there are two ways to achieve what I am trying to do: either through diary, or through capture. I am not sure which I should choose, though. Since it seems my initial message was somehow unclear, let me try to explain what I am trying to achieve again. I have only one agenda file, ~/gtd/agenda.org. It consists of only headings with active timestamps. When I want to schedule a dinner with John, what I currently do is: 1. C-c a a 2. Look for a date 3. (say I find that April 1st isalright) 4. quit the agenda view 5. Visit the buffer corresponding to ~/gtd/agenda.org 6. Go to the end of that buffer with M-> 7. Add a heading like * Dinner with John 8. Use C-c . to add the date, 1 apr I am fine with steps 1 to 3 but would like to do steps 4 to 8 in a much more efficient way, without having to re-enter the date, but with the same result,i.e. the heading being added atthe endo of ~/gtd/agenda.org Do I make more sense this time? Thanks again for you help! Shérab.
Re: [O] [RFC] Moving "manual.org" into core
Bastien Guerry writes: >> Exactly. Emacs will anyways ship with org.texi. So moving the manual >> source to Org in the Org repo shouldn't concern the Emacs repo. > > Yes, but it is still a concern for Emacs contributors like Glenn and > others who occasionnally make corrections in Emacs' org.texi. I'm > fine if we can backport these corrections by hand for the time being. We'll have to deal with them just like we deal with all other backporting from Emacs. It's no secret that Emacs like to do things in a slightly different way and that had to be accepted when Org was moved into Emacs, but development kept going seperately from it. I haven't looked at how often changes to Org's manual actually originate on the Emacs side in one development cycle of Emacs (which is generally a year or more, but it can't be that much. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ DIY Stuff: http://Synth.Stromeko.net/DIY.html
[O] partly automating backporting [was Re: [RFC] Moving "manual.org" into core]
On 3/6/18, Achim Gratz wrote: > I haven't looked at how often changes to Org's manual actually originate > on the Emacs side in one development cycle of Emacs (which is generally > a year or more, but it can't be that much. it is an interesting technical question whether we can partly automate backporting.
Re: [O] Adding an item to the agenda from the agenda view
Shérab writes:
> Dear all,
[...]
> When I want to schedule a dinner with John, what I currently do is:
>
> 1. C-c a a
>
> 2. Look for a date
>
> 3. (say I find that April 1st isalright)
>
> 4. quit the agenda view
>
> 5. Visit the buffer corresponding to ~/gtd/agenda.org
>
> 6. Go to the end of that buffer with M->
>
> 7. Add a heading like
> * Dinner with John
>
> 8. Use C-c . to add the date, 1 apr
Yup, it's "k" in the Agenda that you want. First, set up your
org-capture templates appropriately. I've got one for exactly this
purpose that looks like:
("e" "Event" entry (file "~/org/schedule.org")
"* %?\n%^T")
Any capture template that has one of the "t/T" expansion elements will
default to the date under point in the Agenda. So after step 3 above,
hit "k", choose this template, and it will help you fill in the correct
information. "C-c C-c", and you're done. You actually never have to look
at the agenda.org file.
Eric
Re: [O] Bug: Broken orgmode.org links in doc/misc/org.texi and lisp/org
I wrote: > […] > The following links in Emacs master's doc/misc/org.texi and > lisp/org are broken (404): > - https://orgmode.org/org-remember.pdf > - https://orgmode.org/worg/code/org-info-js/ > - https://orgmode.org/worg/org-contrib/babel/languages.html > - https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-lilypond.html > - https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-stan.html The last four work now (merci Bastien!), the first still not. It is referenced in etc/ORG-NEWS, documenting the changes in version 7.8.11: | […] | ** Important new features | […] | *** org-capture.el is now the default capture system | This replaces the earlier system org-remember. The manual only | describes org-capture, but for people who prefer to continue to | use org-remember, we keep a static copy of the former manual | section [[https://orgmode.org/org-remember.pdf][chapter about remember]]. | […] The Internet Archive's Wayback Machine has archived a copy (https://web.archive.org/web/20171027214006/https://orgmode.org/org-remember.pdf). Would it work if it is committed as /org-remember.pdf to https://code.orgmode.org/bzg/orgweb? Tim
Re: [O] Bug: Broken orgmode.org links in doc/misc/org.texi and lisp/org
Hi Tim, Tim Landscheidt writes: >> - https://orgmode.org/org-remember.pdf >> - https://orgmode.org/worg/code/org-info-js/ >> - https://orgmode.org/worg/org-contrib/babel/languages.html >> - https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-lilypond.html >> - https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-stan.html > > The last four work now (merci Bastien!), the first still > not. This is now fixed, thanks a lot! -- Bastien
Re: [O] [RFC] Moving "manual.org" into core
Aloha Bastien, Bastien writes: Hi Thomas, "Thomas S. Dye" writes: Instead, let's move the project forward with the understanding that if it proves to be a bad idea, then the Org mode community will have Nicolas' very nice .texi file (with backports by Kyle Meyer) to fall back on. Maybe we are miscommunicating, because that's exactly what I suggest! Good news. Thanks! All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] Adding an item to the agenda from the agenda view
On Tuesday, 6 Mar 2018 at 22:15, Shérab wrote: [...] > I am fine with steps 1 to 3 but would like to do steps 4 to 8 in a much > more efficient way, without having to re-enter the date, but with the > same result,i.e. the heading being added atthe endo of ~/gtd/agenda.org > > Do I make more sense this time? Yes. And my original response is what you want. Set org-agenda-diary-file to "~/gtd/agenda.org". Then, from within the agenda view, if you type "i d", you will be creating a new agenda entry for the day you are looking at. That's steps 4 to 8 in a nutshell. -- Eric S Fraga via Emacs 27.0.50, Org release_9.1.6-191-g90607d signature.asc Description: PGP signature
Re: [O] Concatenating header args
Hello,
John Kitchin writes:
> I am pretty sure this isn't possible. The headers get overridden by the
> most local settings. There isn't a way to concatenate them. In some cases
> there isn't a way to figure out what you want, e.g. if a heading property
> said ":tangle no" and your header said ":tangle yes" it would not make
> sense to concatenate these to ":tangle no yes".
hm, I could think of a special syntax, like :tangle results in the
current behaviour and :+table concats values. That way it's up to the
user to express what she wants.
> I think you have to add -Wall to the src header.
Hm, the property values can be functions that get evaluated to get the
actual property values, can't it? I'm not sure though if something like
:flags (get-em "flags" '("-more" "-values")) is so much nicer to write.
Maybe it is, esp. if you want to change the base flags for a ton of
items. Today is teaching tuesday (even if it's wednesday ;)), so I'm a
bit short on time. But I will try that approach later this week and see
where that leads to.
Thanks
hmw
