[O] Babel SML oddity
I'm following a Coursera course that uses ML. I have SML up and running on Emacs 26.1/orgmode 9.1.14. So in an orgmode buffer I have #+begin_src sml val u = 1; val v = 2; val w = u + v; #+end_src and C-c C-c produces #+RESULTS[8b5...]: : val v = 2 : int while the REPL (*sml*) produces - val u = 1; val v = 2; val w = u + v; ; "stdIn"; val u = 1 : int - val v = 2 : int - val w = 3 : int - val it = "stdIn" : string So the RESULTS block in the orgmode buffer is not giving the full results as does the REPL. More bizarre, I can do something later, e.g., #+begin_src sml fun area_c (r) = Math.pi * r * r; #+end_src and the RESULTS simply replaces the RESULTS above, again only including some of the REPL's response. I'm saying it doesn't do the normal thing of giving a new RESULTS below the code block, rather just replaces the previous RESULTS block's contents with incomplete information. I can add many code blocks -- and I only ever get that lone RESULTS block overwritten. What am I missing? LB
Re: [O] Bug? Group tags not working properly with agenda searches
I tried the Org mode from the Org mode ELPA (org-20181112.tar) but
apparently the bug fix is not in there yet. But I also tried the one from
the latest Git and it's fixed in there. Thanks very much. --Omari
On Thu, Nov 8, 2018 at 12:24 PM Nicolas Goaziou
wrote:
> Hello,
>
> Omari Norman writes:
>
> > I am having a problem with group tags. I reproduced it using the latest
> > org-mode from the org package archive, 20181022. The minimal example is
> > this: say I have a group tag that looks like this:
> >
> > (setq org-tag-alist
> > '((:startgrouptag)
> > ("parentTag")
> > (:grouptags)
> > ("childTag1")
> > ("childTag2")
> > (:endgrouptag)))
> >
> > with a org-todo-keywords like so:
> >
> > (setq org-todo-keywords '((type "TODO" "NEXT" "|" "DONE" "CANCELLED")))
> >
> > And then an org file that looks like this:
> >
> > * Parent heading 1 :childTag1:
> > ** NEXT child 1 of parent 1
> > ** TODO child 2 of parent 1
> >
> > * Parent heading 2
> > ** NEXT child 1 of parent 2
> > ** TODO child 2 of parent 2
> >
> > Then when I hit C-c a M, I use this match string:
> >
> > parentTag="NEXT"|-parentTag="TODO"
> >
> > I would expect the resulting agenda to have exactly two items: "child 1
> of
> > parent 1", and "child 2 of parent 2". However, I get three items:
> "child 1
> > of parent 1", "child 2 of parent 1", and "child 2 of parent 2". I don't
> > understand why "child 2 of parent 1" is in there.
> >
> > This only arises when using the "|" operator. That is, if I do an agenda
> > with just
> >
> > parentTag="NEXT"
> >
> > then I get just "child 1 of parent 1", as expected. If I do an agenda
> with
> >
> > -parentTag="TODO"
> >
> > then I get just "child 2 of parent 2", as expected. But when I combine
> > them with "|", I get three items.
> >
> > I also did some other tests showing that at least for me this problem
> > arises only with group tags. In particular, here if I do
> >
> > childTag1="NEXT"|-childTag1="TODO"
> >
> > I get just the two items I would expect.
> >
> > Is there a bug here? Or am I doing something wrong?
>
> It was a bug, now hopefully fixed.
>
> Thank you.
>
> Regards,
>
> --
> Nicolas Goaziou
>
Re: [O] Footnotes in the manual (hidden option?)
Hello, > > > (a) May I propose the [^1] as an alternative footnotes syntax as a new > > feature? > > I sympathize with your concern, and [^1] may not have been a bad choice > when footnotes were introduced, but that ship has sailed long ago. > > There is enough footnote syntax in Org nowadays. I saw only "fn:" related variations in the docs... > I'd rather keep it that > way. Even if somebody else implements this and provides a patch?... Thank you!
Re: [O] Bug: no more fontifying in org mode [9.1.14 (9.1.14-dist @ /home/abel/git-ext/org-9.1.14/lisp/)]
Hello, boris martin writes: > since i have updated org mode to this version if i open a org-mode file > it will not be fontify i will need to go to org->refresh/Reload->refresh > setup current buffer > > to have the buffer fontify. > > this happen with emacs -Q -l /path/to/minimal-org.el > as well. I cannot reproduce it. Could you send a minimal Org file where that happens? Also, what is in minimal-org.el? Regards, -- Nicolas Goaziou
Re: [O] Footnotes in the manual (hidden option?)
Hello, ST writes: > (a) May I propose the [^1] as an alternative footnotes syntax as a new > feature? I sympathize with your concern, and [^1] may not have been a bad choice when footnotes were introduced, but that ship has sailed long ago. There is enough footnote syntax in Org nowadays. I'd rather keep it that way. > (b) How can I define such syntax by my own as a footnote? You may have to tweak some libraries, e.g., org-footnote.el and org-element.el, but you're on your own here. Regards, -- Nicolas Goaziou
Re: [O] #+attr_odt: not working
Hello, Will Pierce writes: > Ah! I was confusing https://github.com/kjambunathan/org-mode-ox-odt with > the main Org distribution. > > Sounds like those maintainers are hoping to get their ODT features into the > official Org? Quite the opposite, unfortunately. Regards, -- Nicolas Goaziou
[O] #+attr_odt: not working
Ah! I was confusing https://github.com/kjambunathan/org-mode-ox-odt with the main Org distribution. Sounds like those maintainers are hoping to get their ODT features into the official Org? I'd be happy to help with documentation if that's an issue there!
[O] Bug: no more fontifying in org mode [9.1.14 (9.1.14-dist @ /home/abel/git-ext/org-9.1.14/lisp/)]
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.
since i have updated org mode to this version if i open a org-mode file
it will not be fontify i will need to go to org->refresh/Reload->refresh
setup current buffer
to have the buffer fontify.
this happen with emacs -Q -l /path/to/minimal-org.el
as well.
Emacs : GNU Emacs 24.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.10.8)
of 2017-09-20 on lcy01-35, modified by Debian
Package: Org mode version 9.1.14 (9.1.14-dist @
/home/abel/git-ext/org-9.1.14/lisp/)
current state:
==
(setq
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
org-occur-hook '(org-first-headline-recenter)
org-metaup-hook '(org-babel-load-in-session-maybe)
org-confirm-shell-link-function 'yes-or-no-p
org-after-todo-state-change-hook '(org-clock-out-if-current)
org-from-is-user-regexp "\\"
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-babel-pre-tangle-hook '(save-buffer)
org-mode-hook '(#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook org-show-block-all append
local]
5 "\n\n(fn)"]
#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook org-babel-show-result-all
append local]
5 "\n\n(fn)"]
org-babel-result-hide-spec org-babel-hide-all-hashes)
org-bibtex-headline-format-function #[257 "\300\236A\207" [:title] 3
"\n\n(fn ENTRY)"]
org-archive-hook '(org-attach-archive-delete-maybe)
org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers
org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-confirm-elisp-link-function 'yes-or-no-p
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-link-parameters '(("id" :follow org-id-open)
("rmail" :follow org-rmail-open :store
org-rmail-store-link)
("mhe" :follow org-mhe-open :store org-mhe-store-link)
("irc" :follow org-irc-visit :store org-irc-store-link)
("info" :follow org-info-open :export org-info-export
:store org-info-store-link)
("gnus" :follow org-gnus-open :store
org-gnus-store-link)
("docview" :follow org-docview-open :export
org-docview-export :store org-docview-store-link)
("bibtex" :follow org-bibtex-open :store
org-bibtex-store-link)
("bbdb" :follow org-bbdb-open :export org-bbdb-export
:complete org-bbdb-complete-link :store
org-bbdb-store-link)
("w3m" :store org-w3m-store-link) ("file+sys")
("file+emacs") ("doi" :follow org--open-doi-link)
("elisp" :follow org--open-elisp-link)
("file" :complete org-file-complete-link)
("ftp" :follow
(lambda (path) (browse-url (concat "ftp:" path
("help" :follow org--open-help-link)
("http" :follow
(lambda (path) (browse-url (concat "http:" path
("https" :follow
(lambda (path) (browse-url (concat "https:" path
("mailto" :follow
(lambda (path) (browse-url (concat "mailto:; path
("news" :follow
(lambda (path) (browse-url (concat "news:; path
("shell" :follow org--open-shell-link))
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
)
[O] Tag completion for ":a_tag:" fails if string "a_tag:" is in headline
Hello. Specifically, I have the simple org file: * a header :foo: * blah foo: blah :f If, after typing the last 'f' above, I type 'M-x pcomplete', I get the message "No completions of f". Clearly, the problem is in the "foo:" of the 2nd headline. Without it, or with "foo" (or even with ":foo:") in place of "foo:", the completion is performed to ":foo:" as expected. Regards. I use 'emacs -Q -l .emacs.debug', where the .emacs.debug file contains only (add-to-list 'load-path "/home/cochard/Org/Coch-git/org-mode/lisp") with which I have: Emacs : GNU Emacs 24.5.1 (x86_64-redhat-linux-gnu, GTK+ Version 3.18.9) of 2016-04-11 on buildvm-25.phx2.fedoraproject.org Package: Org mode version 9.1.14 (release_9.1.14-1035-gfeb442 @ /home/cochard/Org/Coch-git/org-mode/lisp/) -- EOST (École et Observatoire des Sciences de la Terre) IPG (Institut de Physique du Globe) | alain.coch...@unistra.fr 5 rue René Descartes [bureau 106] | Phone: +33 (0)3 68 85 50 44 F-67084 Strasbourg Cedex, France| Fax: +33 (0)3 68 85 01 25
Re: [O] Footnotes in the manual (hidden option?)
On Wed, 2018-05-16 at 14:31 -0400, Kaushal Modi wrote: > Hello, > > On Wed, May 16, 2018 at 2:27 PM ST wrote: > > Hello, > > in the manual > > https://orgmode.org/manual/Footnotes.html#Footnotes > > it says that footnotes[fn:1] > > [fn:1] look like this > > > but actually[1] > > [1] works as well and looks even better. > > So why this option is not documented? > > > I would think that's so because canonically Org mode using [fn:1] > style. It looks like you are manually typing the footnote refs and > definitions. > > > Try using C-c C-x f binding.. you will see that Org inserts the > footnotes in the documented style. > > > I would say that the "fn"-style footnotes remove any kind of > ambiguity.. It's true that [1] alone may very well introduce ambiguity, but why not to take something more lightweight and language/alphabet independent, like [^1]? 1. It's three times shorter (its important if you type manually in GitLab/GitHub without the C-c C-x f binding); 2. If you type in another language - you don't have to switch the keyboard; 3. If your text is in another alphabet - latin "fn" disturbs the eye. 4. It feels a bit heavy as a markup for the lightweight org . (a) May I propose the [^1] as an alternative footnotes syntax as a new feature? (b) How can I define such syntax by my own as a footnote? Thank you!
Re: [O] Bug: "file:" protocol link with "#anchor" bad HTML export [9.1.14 (9.1.14-1-g4931fc-elpa @ /home/phil/.emacs.d/elpa/org-9.1.14/)]
Hello, Philip Hudson writes: > I add into Worg file "worg-faq.org" a hyperlink using the "file:" > protocol, linking to a sub-heading in Worg file "worg-git.org". Exact > syntax quoted below, from an email thread with Bastien. > > Expected behavior: > > I expect the HTML exporter automatically used by Worg to generate an > "https:" protocol hyperlink which links to a specific, existing HTML > anchor ID in file "worg-git.html". > > Actual behavior: > > The exporter generates an "https:" protocol hyperlink that points to a > non-existent anchor ID in file "worg-git.html". > > I have left the mis-generated link in place on Worg for the time > being. (My previous push included a correct, explicit "https:" > protocol link; I can revert and push again at any time). You can > examine it at: > > > https://orgmode.org/worg/org-faq.html#keeping-current-with-Org-mode-development > > at the bottom of list item 2. My guess is that Worg cache is invalid, somehow. I cannot debug it further since I do not have acces to Worg. Bastien, I think we should delete the cache file and re-publish everything to get the cache right. > Could you report it to the mailing list? Don't forget to mention your > Org version and a minimal recipe on how to reproduce the bug. It is > important enough to block the release of Org 9.2. I don't see why it would be a blocker for Org 9.2. Regards, -- Nicolas Goaziou
Re: [O] Links for getting email in Gmail (IMAP) with Gnus ?
Le mar. 13 nov. 2018 à 09:36:17 , Eric S Fraga a
envoyé ce message:
> On Saturday, 10 Nov 2018 at 22:09, Joseph Vidal-Rosset wrote:
>> Hello,
>>
>> I know that it is possible to link emails in Todo list, but I meet
>> difficulties with Gmail IMAP and Gnus when the mail is in the box "All
>> emails" ("Tous les messages" in French): as soon as the email is in this
>> Archive, the link is broken and Gnus does not fetch it.
>
> Instead of reading your gmail messages in the Inbox, you could read them
> in the All mail group instead and link to emails in that group?
> Alternatively, don't archive your emails.
Many thanks Eric for your suggestion, but finally, I succeeded in
writing a code that makes the job. I am going to give it to the list, it
could be helpful for others. Here it is (in my scimax/user/user.el):
#+BEGIN_SRC emacs-lisp
;;capture todo items using C-c c t
(define-key global-map (kbd "C-c c") 'org-capture)
(setq org-capture-templates
'(("t" "todo" entry (file+headline "~/Dropbox/Orgzly/todo.org" "Tasks")
"* TODO [#A] %?")))
(setq org-capture-templates
'(("t" "todo" entry (file+headline "~/Dropbox/Orgzly/todo.org" "Tasks")
"* TODO [#A] %?\nSCHEDULED: %(org-insert-time-stamp (org-read-date nil
t \"+0d\"))\n")
("m" "TODO from Mail" entry (file+headline "~/Dropbox/Orgzly/todo.org"
"Tasks")
"* TODO [#A] %?\n Voir l'email du %(org-insert-time-stamp (org-read-date
nil t \"+0d\"))\n* LINK %a")
))
(defun hs/replace ()
(interactive)
(goto-char 1)
(let ((search-invisible t)) (replace-string "gnus:INBOX#"
"gnus:%5BGmail%5D/Tous les messages#")))
#+END_SRC
Note that %5B codes [ and that %5D codes ] .
As soon as the Todo note is in my todo.org, the email is linked
correctly and can be put in "Tous les messages" folder.
I have now another small problem to write a convenient kbd to archive
items once they are done, if I do not succeed to find the solution, I
will write again to the list.
Best wishes,
--
Joseph
