Re: [O] [RFC] Remove Org Struct mode
Eric S Fraga writes: > I have no issues with org-struct-mode being removed. I used to use > it, especially for emails. I now simply change the mode to org, write > whatever content I want, and then switch back to message mode to send > my email. Works fine and gives me the full power of org. This is a neat idea. After hearing this, I also have no issue with org-struct-mode being phased out. Jarmo
Re: [O] [RFC] Remove Org Struct mode
I agree too, because the OrgStruct mode functions is so limited for basic Org-mode viewing/editing/navigating etc. [stardiviner] GPG key ID: 47C32433 IRC(freeenode): stardiviner Twitter: @numbchild Key fingerprint = 9BAA 92BC CDDD B9EF 3B36 CB99 B8C4 B8E5 47C3 2433 Blog: http://stardiviner.github.io/ On Mon, Aug 21, 2017 at 6:06 AM, Tim Cross wrote: > > One of the reasons I moved to using mu4e for email was because I was > told I could use orgStruct mode and write my email using org structured > editing. > > The reality has been somewhat disappointing. One of the main things I > wanted was better handling of lists and this is one area of orgstruct > mode which certainly doesn't work correctly. > > So, given what you say and the fact the mode isn't working as > advertised, I tend to agree. Just adding a note to my org task list to > look at outshine.el, which I wasn't aware of. If I really need org > structural editing for writing an email, I'll write it in an org-mode > file and then transfer it to a message buffer - as you point out, there > is lots in org mode which makes no sense in an email buffer anyway! > > Tim > > Nicolas Goaziou writes: > > > Hello, > > > > I would like to remove Org Struct minor mode from Org code base. Here is > > the rationale: > > > > 1. It is broken. It might look like using Org in another buffer, but it > >is not. In particular, it just cannot cope with lists, indentation, > >filling in, e.g., Message mode, as soon as we try something > >non-trivial. Really, that's a poor-man's Org mode. > > > > 2. Its implementation is very hackish. In particular, it is not modular > >at all. It rewrites some core functions according to the major mode > >in use. For example `org-fill-function' tries to handle specially > >text in a Message mode buffer, basically short-circuiting regular > >behaviour. There no support for other major modes. If we want some, > >we need to hard-code it. > > > > 3. Due to previous point, some basic Org functions are sub-optimal > >because they preserve compatibility with Org Struct mode. For example > >`org-forward-heading-same-level' must process every headline past the > >current one and check their level until an appropriate one is found. > >It would be faster to go looking for the next headline according to > >the number of stars we want. > > > > 4. It is somewhat outside Org mode's scope to provide such a feature. It > >is tempting to provide everything we can think of, but we should > >focus on the main task: handle Org files, i.e., files written in Org > >compatible syntax. > > > > 5. There are alternatives. E.g., outshine.el, outline-minor-mode, ... > > > > I _do_ use `orgstruct++-mode'. But it is broken beyond repair. > > Alternatives, which do not need to pay a technical debt, are certainly > > better, or, at least, a saner ground for improvement. > > > > I'm not opposed to an Org struct mode living in ELPA. But, as pointed > > out, it is difficult to extract from code base without rewriting it > > completely. If alternatives are serious enough, that would be > > re-inventing the wheel, too. > > > > The only thing that would be missing, AFAIK, is plain list handling. > > However, I'm quite certain it is possible to re-use most code from > > "org-list.el", using a dumbed down `org-list-struct' function. Indeed, > > currently, `org-list-struct' requires to know about inlinetasks, > > drawers, blocks... i.e., most of the Org syntax. This is not an option > > in foreign buffers. Once `org-list-struct' (and maybe `org-in-item-p') > > are simplified, other functions in "org-list.el" can be used as is. > > > > I'm not talking about OrgTbl mode (yet). OrgTbl mode is different: it > > doesn't suffer from points 1, 3 end 5. It is easier to extract it as an > > external library, which someone should ultimately do. > > > > To sum it up, I offer to remove `orgstruct-mode' (and > > `orgstruct++-mode') from the code base. I can also offer my help to > > anyone willing to extract some `list-minor-mode' and `table-minor-mode' > > from Org. > > > > WDYT? > > > > > > Regards, > > > -- > Tim Cross > >
Re: [O] Bug: markdown export errors on headers [9.0.9 (9.0.9-82-gb862c2-elpaplus @ /home/fommil/.emacs.d/elpa/org-plus-contrib-20170814/)]
On Sun, Aug 20, 2017, 4:25 PM Nicolas Goaziou wrote: > > > then I can try to investigate what could be causing the Emacs org > > to load. I cannot see how that is possible since it is not even > > available on the elisp path anymore. > > > > Is there a way to check which elisp files have been loaded? Then I can > > grep for anything from the emacs org install instead of my local > > install. > > `locate-library' may help. Also, `load-path' can give a clue. Try with > a bare configuration, i.e., with just > > (require 'package) > (package-initialize) > > It can be tricky to find out what is loading bundled Org too early. > Enjoy the Frankenorg. > :) M-x list-load-path-shadows will also help. Pay attention to shadows on org packages. > -- Kaushal Modi
Re: [O] [RFC] Remove Org Struct mode
One of the reasons I moved to using mu4e for email was because I was told I could use orgStruct mode and write my email using org structured editing. The reality has been somewhat disappointing. One of the main things I wanted was better handling of lists and this is one area of orgstruct mode which certainly doesn't work correctly. So, given what you say and the fact the mode isn't working as advertised, I tend to agree. Just adding a note to my org task list to look at outshine.el, which I wasn't aware of. If I really need org structural editing for writing an email, I'll write it in an org-mode file and then transfer it to a message buffer - as you point out, there is lots in org mode which makes no sense in an email buffer anyway! Tim Nicolas Goaziou writes: > Hello, > > I would like to remove Org Struct minor mode from Org code base. Here is > the rationale: > > 1. It is broken. It might look like using Org in another buffer, but it >is not. In particular, it just cannot cope with lists, indentation, >filling in, e.g., Message mode, as soon as we try something >non-trivial. Really, that's a poor-man's Org mode. > > 2. Its implementation is very hackish. In particular, it is not modular >at all. It rewrites some core functions according to the major mode >in use. For example `org-fill-function' tries to handle specially >text in a Message mode buffer, basically short-circuiting regular >behaviour. There no support for other major modes. If we want some, >we need to hard-code it. > > 3. Due to previous point, some basic Org functions are sub-optimal >because they preserve compatibility with Org Struct mode. For example >`org-forward-heading-same-level' must process every headline past the >current one and check their level until an appropriate one is found. >It would be faster to go looking for the next headline according to >the number of stars we want. > > 4. It is somewhat outside Org mode's scope to provide such a feature. It >is tempting to provide everything we can think of, but we should >focus on the main task: handle Org files, i.e., files written in Org >compatible syntax. > > 5. There are alternatives. E.g., outshine.el, outline-minor-mode, ... > > I _do_ use `orgstruct++-mode'. But it is broken beyond repair. > Alternatives, which do not need to pay a technical debt, are certainly > better, or, at least, a saner ground for improvement. > > I'm not opposed to an Org struct mode living in ELPA. But, as pointed > out, it is difficult to extract from code base without rewriting it > completely. If alternatives are serious enough, that would be > re-inventing the wheel, too. > > The only thing that would be missing, AFAIK, is plain list handling. > However, I'm quite certain it is possible to re-use most code from > "org-list.el", using a dumbed down `org-list-struct' function. Indeed, > currently, `org-list-struct' requires to know about inlinetasks, > drawers, blocks... i.e., most of the Org syntax. This is not an option > in foreign buffers. Once `org-list-struct' (and maybe `org-in-item-p') > are simplified, other functions in "org-list.el" can be used as is. > > I'm not talking about OrgTbl mode (yet). OrgTbl mode is different: it > doesn't suffer from points 1, 3 end 5. It is easier to extract it as an > external library, which someone should ultimately do. > > To sum it up, I offer to remove `orgstruct-mode' (and > `orgstruct++-mode') from the code base. I can also offer my help to > anyone willing to extract some `list-minor-mode' and `table-minor-mode' > from Org. > > WDYT? > > > Regards, -- Tim Cross
Re: [O] Scheme output results
Hello, Neil Jerram writes: > With apologies for the slow follow up, attached is a patch that works > well for me. Thank you. > I guess (following any revisions) you will also need assignment > papers. I believe I have these on file for Guile already (since about > 1990), and it's possible that those are worded so as to cover Emacs as > well. Would you mind checking, as I've forgotten how to do that > myself? I cannot, I'm not the maintainer. I'm Cc'ing Bastien. I'll apply your patch as soon as it is sorted out. Regards, -- Nicolas Goaziou
Re: [O] Bug: markdown export errors on headers [9.0.9 (9.0.9-82-gb862c2-elpaplus @ /home/fommil/.emacs.d/elpa/org-plus-contrib-20170814/)]
Sam Halliday writes: > If you are confirming that org is definitely compatible with my .org > file It is, although I didn't check the details of the output. It didn't error in the process anyway. > then I can try to investigate what could be causing the Emacs org > to load. I cannot see how that is possible since it is not even > available on the elisp path anymore. > > Is there a way to check which elisp files have been loaded? Then I can > grep for anything from the emacs org install instead of my local > install. `locate-library' may help. Also, `load-path' can give a clue. Try with a bare configuration, i.e., with just (require 'package) (package-initialize) It can be tricky to find out what is loading bundled Org too early. Enjoy the Frankenorg. Regards,
Re: [O] Bug: markdown export errors on headers [9.0.9 (9.0.9-82-gb862c2-elpaplus @ /home/fommil/.emacs.d/elpa/org-plus-contrib-20170814/)]
On 20 August 2017 at 16:07, Nicolas Goaziou wrote: > Hello, > > Sam Halliday writes: > >> To ensure that the Emacs-installed org-mode is not interfering, I >> added this to my init >> >> (cl-delete-if >>(lambda (el) (string-match-p ".*org" el)) >>load-path) >> >> and I can confirm that emacs/org is not in my load-path. >> >> However, the backtrace still occurs. > > As I wrote, it is still a problem of mixed installation. Quoting the > manual > > Recent Emacs distributions include a packaging system which lets you > install Elisp libraries. You can install Org with ‘M-x package-install > RET org’. > > Important: you need to do this in a session where no ‘.org’ file has > been visited, i.e., where no Org built-in function have been loaded. > Otherwise autoload Org functions will mess up the installation. > > Then, to make sure your Org configuration is taken into account, > initialize the package system with ‘(package-initialize)’ in your > ‘.emacs’ before setting any Org option. If you want to use Org’s > package repository, check out the Org ELPA page > (http://orgmode.org/elpa.html). Yes, I followed this exactly and the problem still occurs. If you are confirming that org is definitely compatible with my .org file then I can try to investigate what could be causing the Emacs org to load. I cannot see how that is possible since it is not even available on the elisp path anymore. Is there a way to check which elisp files have been loaded? Then I can grep for anything from the emacs org install instead of my local install.
Re: [O] [RFC] Remove Org Struct mode
I have no issues with org-struct-mode being removed. I used to use it, especially for emails. I now simply change the mode to org, write whatever content I want, and then switch back to message mode to send my email. Works fine and gives me the full power of org. -- : Eric S Fraga via Emacs 26.0.50, Org release_9.0.9-787-g197c58 signature.asc Description: PGP signature
Re: [O] [RFC] Remove Org Struct mode
On 08/20/2017 09:57 AM, Nicolas Goaziou wrote: > > I would like to remove Org Struct minor mode from Org code base. Here is > the rationale: > I use OrgStruct in my configuration files, but it is so limited that I've been slowly moving my configuration to Org files. It is frustrating that simple things like C-c C-u don't work in OrgStruct. Removing OrgStruct from the Org code base would be incentive for me to finish rewriting my configuration files. However, I have to wonder what harm is caused by leaving OrgStruct in the code base. Scott Randby
Re: [O] "header-args :eval inline-only" not working
> On Aug 20, 2017, at 3:21 AM, Nicolas Goaziou wrote: > > Hello, > > Vikas Rawal writes: > >> I am on the latest version on org mode ELPA. It is dated August 18, >> 2017, so should include the commit you mention. > > `org-export-use-babel' is from "master" branch. ELPA provides "maint". > >> But this would prevent exporting all code blocks including inline blocks. >> >> Isn’t it? >> >> There seems no way of separately controlling inline and other blocks. > > There is. You put :eval never-export on all src blocks and :eval t on > inline code. Note, however, that inline code might call indirectly src > blocks, so this can lead to odd situations. > There is also :cache, but it has some gotchas, too. > What you are missing, probably, is some way to set this globally. Alas, > `org-export-use-babel' or `org-export-babel-evaluate' is not the answer. > As suggested in the thread you mentioned earlier, we might as well get > rid of `org-export-use-babel' altogether. It seems to confuse many users > and isn't very useful. > > WDYT? Maybe remove the `inline-only' option as a first step. I have no use for org-export-use-babel, but one thing it does do is prevent processing of headers which could be helpful if tricky header constructions cause export to fail. Chuck
Re: [O] Scheme output results
On 23/07/17 09:52, Nicolas Goaziou wrote: Hello, Neil Jerram writes: I don't think that Scheme output results are correctly handled. Please consider: #+BEGIN_SRC scheme :results output (display "a") (newline) (display "b") (newline) (display "c") (newline) '(a b c) #+END_SRC #+RESULTS: : "a\nb\nc\n" As compared with the Elisp equivalent: #+BEGIN_SRC elisp :results output (princ "a") (terpri) (princ "b") (terpri) (princ "c") (terpri) '(a b c) #+END_SRC #+RESULTS: : a : b : c I have a possible fix for this - on another computer, so not to hand right now - but thought it would be check first whether you agree with me that the Scheme results should be more like the Elisp ones. That sounds like a good idea. Could you send your fix as a proper patch with a commit message? Thank you! Regards, With apologies for the slow follow up, attached is a patch that works well for me. I think a concern with it would be whether the Geiser retort object and functions have always existed, and whether we can rely on them continuing to exist. But - at least for me - every Scheme evaluation was previously giving "An error occurred", because of an unexpected extra "Mark set" message, so I am pretty sure that my patch is an improvement. I guess (following any revisions) you will also need assignment papers. I believe I have these on file for Guile already (since about 1990), and it's possible that those are worded so as to cover Emacs as well. Would you mind checking, as I've forgotten how to do that myself? Regards - Neil >From a02b60b88bcfd1896c05cd858ae80bb1ef183730 Mon Sep 17 00:00:00 2001 From: Neil Jerram Date: Sun, 20 Aug 2017 17:25:58 +0100 Subject: [PATCH] Improve Scheme code evaluation * lisp/ob-scheme.el (org-babel-scheme-execute-with-geiser): Use Geiser's explicit 'retort' object, instead of catching and parsing an expected Emacs message (which for me is in any case overwritten by a following "Mark set" message); this also means we don't need the with-output-to-string approach for getting 'output' results. Also 'let' Geiser variables so as to avoid popping up the REPL and *Geiser dbg* buffers. --- lisp/ob-scheme.el | 56 +++ 1 file changed, 28 insertions(+), 28 deletions(-) diff --git a/lisp/ob-scheme.el b/lisp/ob-scheme.el index b8867d5f6..bf1da01b0 100644 --- a/lisp/ob-scheme.el +++ b/lisp/ob-scheme.el @@ -150,35 +150,35 @@ is true; otherwise returns the last value." (with-temp-buffer (insert (format ";; -*- geiser-scheme-implementation: %s -*-" impl)) (newline) - (insert (if output - (format "(with-output-to-string (lambda () %s))" code) - code)) + (insert code) (geiser-mode) - (let ((repl-buffer (save-current-buffer - (org-babel-scheme-get-repl impl repl - (when (not (eq impl (org-babel-scheme-get-buffer-impl - (current-buffer - (message "Implementation mismatch: %s (%s) %s (%s)" impl (symbolp impl) - (org-babel-scheme-get-buffer-impl (current-buffer)) - (symbolp (org-babel-scheme-get-buffer-impl - (current-buffer) - (setq geiser-repl--repl repl-buffer) - (setq geiser-impl--implementation nil) - (setq result (org-babel-scheme-capture-current-message - (geiser-eval-region (point-min) (point-max - (setq result - (if (and (stringp result) (equal (substring result 0 3) "=> ")) - (replace-regexp-in-string "^=> " "" result) - "\"An error occurred.\"")) - (when (not repl) - (save-current-buffer (set-buffer repl-buffer) - (geiser-repl-exit)) - (set-process-query-on-exit-flag (get-buffer-process repl-buffer) nil) - (kill-buffer repl-buffer)) - (setq result (if (or (string= result "#") - (string= result "#")) - nil - result + (let ((geiser-repl-window-allow-split nil) + (geiser-repl-use-other-window nil)) + (let ((repl-buffer (save-current-buffer + (org-babel-scheme-get-repl impl repl + (when (not (eq impl (org-babel-scheme-get-buffer-impl + (current-buffer + (message "Implementation mismatch: %s (%s) %s (%s)" impl (symbolp impl) + (org-babel-scheme-get-buffer-impl (current-buffer)) + (symbolp (org-babel-scheme-get-buffer-impl + (current-buffer) + (setq geiser-repl--repl repl-buffer) + (setq geiser-impl--implementation nil) + (let ((geiser-debug-jump-to-debug-p nil) + (geiser-debug-show-debug-p nil)) + (let ((ret (geiser-eval-region (point-min) (point-max + (setq result (if output + (geiser-eval--retort-output ret) + (geiser-eval--retort-result-str ret "") + (when (not repl) + (save-current-buffer (set-buffer repl-buffer) + (geiser-repl-exit)) + (set-process-query-on-exit-flag (get-buffer-process repl-buffer) nil) + (kill-buffer repl-buffer)) + (setq result (if (or (string= result "#") + (string= result "#")) + nil + result) result))
Re: [O] Bug: markdown export errors on headers [9.0.9 (9.0.9-82-gb862c2-elpaplus @ /home/fommil/.emacs.d/elpa/org-plus-contrib-20170814/)]
Hello, Sam Halliday writes: > To ensure that the Emacs-installed org-mode is not interfering, I > added this to my init > > (cl-delete-if >(lambda (el) (string-match-p ".*org" el)) >load-path) > > and I can confirm that emacs/org is not in my load-path. > > However, the backtrace still occurs. As I wrote, it is still a problem of mixed installation. Quoting the manual Recent Emacs distributions include a packaging system which lets you install Elisp libraries. You can install Org with ‘M-x package-install RET org’. Important: you need to do this in a session where no ‘.org’ file has been visited, i.e., where no Org built-in function have been loaded. Otherwise autoload Org functions will mess up the installation. Then, to make sure your Org configuration is taken into account, initialize the package system with ‘(package-initialize)’ in your ‘.emacs’ before setting any Org option. If you want to use Org’s package repository, check out the Org ELPA page (http://orgmode.org/elpa.html). Some users install Org launching a new Emacs session without any configuration file. > For a much larger file that causes additional problems with org-mode > markdown export (e.g. problems with BEGIN_SRC blocks) is my book's > manuscript: > > https://github.com/fommil/fp-scala-mortals/blob/master/manuscript/book.org Could you point out what are the problems? I have no issue exporting the document above with latest Org, but I may have missed some wrong bits in the output. I have no Scala mode installed. Regards, -- Nicolas Goaziou
Re: [O] [RFC] Remove Org Struct mode
I have been using org-mode for a few years now, but have never yet noticed org-struct mode. So removing org-struct would be no loss for me (and possibly a gain, if it eased ongoing org-mode maintenance and development). OTOH I certainly do use and appreciate orgtbl minor mode, and it would be a big disadvantage for me if that function disappeared. I've no objection in principle, though, to reorganizing _how_ that function is provided. Regards - Neil On 20/08/17 14:57, Nicolas Goaziou wrote: Hello, I would like to remove Org Struct minor mode from Org code base. Here is the rationale: 1. It is broken. It might look like using Org in another buffer, but it is not. In particular, it just cannot cope with lists, indentation, filling in, e.g., Message mode, as soon as we try something non-trivial. Really, that's a poor-man's Org mode. 2. Its implementation is very hackish. In particular, it is not modular at all. It rewrites some core functions according to the major mode in use. For example `org-fill-function' tries to handle specially text in a Message mode buffer, basically short-circuiting regular behaviour. There no support for other major modes. If we want some, we need to hard-code it. 3. Due to previous point, some basic Org functions are sub-optimal because they preserve compatibility with Org Struct mode. For example `org-forward-heading-same-level' must process every headline past the current one and check their level until an appropriate one is found. It would be faster to go looking for the next headline according to the number of stars we want. 4. It is somewhat outside Org mode's scope to provide such a feature. It is tempting to provide everything we can think of, but we should focus on the main task: handle Org files, i.e., files written in Org compatible syntax. 5. There are alternatives. E.g., outshine.el, outline-minor-mode, ... I _do_ use `orgstruct++-mode'. But it is broken beyond repair. Alternatives, which do not need to pay a technical debt, are certainly better, or, at least, a saner ground for improvement. I'm not opposed to an Org struct mode living in ELPA. But, as pointed out, it is difficult to extract from code base without rewriting it completely. If alternatives are serious enough, that would be re-inventing the wheel, too. The only thing that would be missing, AFAIK, is plain list handling. However, I'm quite certain it is possible to re-use most code from "org-list.el", using a dumbed down `org-list-struct' function. Indeed, currently, `org-list-struct' requires to know about inlinetasks, drawers, blocks... i.e., most of the Org syntax. This is not an option in foreign buffers. Once `org-list-struct' (and maybe `org-in-item-p') are simplified, other functions in "org-list.el" can be used as is. I'm not talking about OrgTbl mode (yet). OrgTbl mode is different: it doesn't suffer from points 1, 3 end 5. It is easier to extract it as an external library, which someone should ultimately do. To sum it up, I offer to remove `orgstruct-mode' (and `orgstruct++-mode') from the code base. I can also offer my help to anyone willing to extract some `list-minor-mode' and `table-minor-mode' from Org. WDYT? Regards,
Re: [O] Bug: markdown export errors on headers [9.0.9 (9.0.9-82-gb862c2-elpaplus @ /home/fommil/.emacs.d/elpa/org-plus-contrib-20170814/)]
Hi Nicholas,
To ensure that the Emacs-installed org-mode is not interfering, I
added this to my init
(cl-delete-if
(lambda (el) (string-match-p ".*org" el))
load-path)
and I can confirm that emacs/org is not in my load-path.
However, the backtrace still occurs.
For a much larger file that causes additional problems with org-mode
markdown export (e.g. problems with BEGIN_SRC blocks) is my book's
manuscript:
https://github.com/fommil/fp-scala-mortals/blob/master/manuscript/book.org
I am able to successfully export this using the built-in org-mode.
Although I'm using additional extensions of md as per
https://github.com/fommil/dotfiles/blob/master/.emacs.d/lisp/ox-leanpub.el
I'm restricting my experiments to stock org-md for now.
Best regards,
Sam
On 19 August 2017 at 10:50, Nicolas Goaziou wrote:
> Hello,
>
> Sam Halliday writes:
>
>> Regression in org-plus-contrib from http://orgmode.org/elpa/ vs version
>> distributed with Emacs 25.2.1
>>
>> Running
>>
>> M-x md-org-export-to-markdown
>>
>> on a simple org file such as the following
>>
>> ==
>>
>> #+TITLE: Functional Programming in Scala for Mortals
>>
>> /Functional Programming in Scala for Mortals/ is a book aimed at Scala
>> developers with an Object Oriented background who wish to learn the
>> *Functional Programming* paradigm.
>> ==
>>
>> Causes the following backtrace:
>>
>> Debugger entered--Lisp error: (wrong-type-argument listp #("Functional
>> Programming in Scala for Mortals" 0 43 (:parent (#1
>
> This usually mean that you have a mixed installation. You should check
> that the Org shipped with Emacs is not used.
>
> Regards,
>
> --
> Nicolas Goaziou
[O] [RFC] Remove Org Struct mode
Hello, I would like to remove Org Struct minor mode from Org code base. Here is the rationale: 1. It is broken. It might look like using Org in another buffer, but it is not. In particular, it just cannot cope with lists, indentation, filling in, e.g., Message mode, as soon as we try something non-trivial. Really, that's a poor-man's Org mode. 2. Its implementation is very hackish. In particular, it is not modular at all. It rewrites some core functions according to the major mode in use. For example `org-fill-function' tries to handle specially text in a Message mode buffer, basically short-circuiting regular behaviour. There no support for other major modes. If we want some, we need to hard-code it. 3. Due to previous point, some basic Org functions are sub-optimal because they preserve compatibility with Org Struct mode. For example `org-forward-heading-same-level' must process every headline past the current one and check their level until an appropriate one is found. It would be faster to go looking for the next headline according to the number of stars we want. 4. It is somewhat outside Org mode's scope to provide such a feature. It is tempting to provide everything we can think of, but we should focus on the main task: handle Org files, i.e., files written in Org compatible syntax. 5. There are alternatives. E.g., outshine.el, outline-minor-mode, ... I _do_ use `orgstruct++-mode'. But it is broken beyond repair. Alternatives, which do not need to pay a technical debt, are certainly better, or, at least, a saner ground for improvement. I'm not opposed to an Org struct mode living in ELPA. But, as pointed out, it is difficult to extract from code base without rewriting it completely. If alternatives are serious enough, that would be re-inventing the wheel, too. The only thing that would be missing, AFAIK, is plain list handling. However, I'm quite certain it is possible to re-use most code from "org-list.el", using a dumbed down `org-list-struct' function. Indeed, currently, `org-list-struct' requires to know about inlinetasks, drawers, blocks... i.e., most of the Org syntax. This is not an option in foreign buffers. Once `org-list-struct' (and maybe `org-in-item-p') are simplified, other functions in "org-list.el" can be used as is. I'm not talking about OrgTbl mode (yet). OrgTbl mode is different: it doesn't suffer from points 1, 3 end 5. It is easier to extract it as an external library, which someone should ultimately do. To sum it up, I offer to remove `orgstruct-mode' (and `orgstruct++-mode') from the code base. I can also offer my help to anyone willing to extract some `list-minor-mode' and `table-minor-mode' from Org. WDYT? Regards, -- Nicolas Goaziou0x80A93738
Re: [O] "header-args :eval inline-only" not working
> >> I am on the latest version on org mode ELPA. It is dated August 18, >> 2017, so should include the commit you mention. > > `org-export-use-babel' is from "master" branch. ELPA provides "maint”. Got it. >> But this would prevent exporting all code blocks including inline blocks. >> >> Isn’t it? >> >> There seems no way of separately controlling inline and other blocks. > > There is. You put :eval never-export on all src blocks and :eval t on > inline code. Note, however, that inline code might call indirectly src > blocks, so this can lead to odd situations. > > What you are missing, probably, is some way to set this globally. Right. > Alas, > `org-export-use-babel' or `org-export-babel-evaluate' is not the answer. > As suggested in the thread you mentioned earlier, we might as well get > rid of `org-export-use-babel' altogether. It seems to confuse many users > and isn't very useful. > > WDYT? > I see no use for org-export-use-babel. But I can only speak for myself here. In my own case, the src blocks are all R, and inline code is emacs-lisp. So, I can use "header-args:R :eval never-export” to turn off evaluation of R code at export time. Vikas
Re: [O] [PATCH] typo fix
Hello, Neil Jerram writes: > A simple typo fix in README_contribute... Applied. Thank you. Regards, -- Nicolas Goaziou
Re: [O] ox-odt: List items contain body paragraphs, confusing styles
On August 20, 2017 18:13:13 Nicolas Goaziou wrote: Out of curiosity, instead of creating a new style, wouldn't some standard style be enough, e.g., "Text_20_body_20_indent"? Also, what happens in the following cases - ... #+begin_quote Quoted paragraph #+end_quote #+begin_center Centered paragraph #+end_center Should the use "Quotations" and "OrgCenter", which inherit from "Text_20_body", or some new style inheriting from the one dedicated to text in plain lists? Interesting questions -- however, I'm leaving tomorrow for a week's holiday. So I won't get to this for awhile. I should also say: This is the first time I've needed the ODT exporter for anything serious. So, I shouldn't be taken as any sort of authority on how the styles "should" work. I'm reporting behavior that seemed odd to me and, to the extent that I have time, I don't mind prowling around in the ODT data structures to see what is going on inside. That's about the extent of what I can do. I'm not affiliated with LibreOffice in any way... In fact, I quite dread using it. TBH I prefer exporting to LaTeX, but it's a humanities journal and they don't understand about superior technology :D That said, I'm not sure why those cases would be challenging. In the normal list item case, you have a list item node enclosing one or more paragraph nodes. In the cases you mentioned, the list item node would contain a quote block or centered block node. As I understand the exporter, the depth-first traversal would encode the child nodes normally, and pass the encoded result up to the list item parent. My observation of LO is that it tries to merge properties from the list style and paragraph style, which it would do if it's centered, block quote or whatever. So my guess is, do nothing special for these cases. But that's a guess. hjh Sent with AquaMail for Android http://www.aqua-mail.com
Re: [O] make compile fails
Adrian Bradd writes: > Looks like htmlize was removed from contrib a few days ago > (commit d0ced9894) which is probably the cause of your issue. You can get > it from https://github.com/hniksic/emacs-htmlize > > You can generate a new local.mk by running 'make local.mk'. You may have to > remove or rename the existing local.mk for this to work. Yeah, did these already (when I posted that the problem had been solved). All the best, Jarmo
[O] [PATCH] typo fix
A simple typo fix in README_contribute... Regards - Neil >From 16380217d8d7d19329a0e5cfbc0956a9c1789342 Mon Sep 17 00:00:00 2001 From: Neil Jerram Date: Sun, 20 Aug 2017 13:26:19 +0100 Subject: [PATCH] Fix typo in README_contribute * README_contribute: Fix typo TINYCHANGE --- README_contribute | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README_contribute b/README_contribute index 2dc62e62b..7433becf6 100644 --- a/README_contribute +++ b/README_contribute @@ -24,7 +24,7 @@ development. git clone git://repo.or.cz/org-mode.git 3. People who are interested to participate in the Org-mode - development can to so by sending patches to this address: + development can do so by sending patches to this address: [[mailto:emacs-orgmode@gnu.org][emacs-orgmode@gnu.org]] -- 2.13.2
Re: [O] "header-args :eval inline-only" not working
Hello, Vikas Rawal writes: > I am on the latest version on org mode ELPA. It is dated August 18, > 2017, so should include the commit you mention. `org-export-use-babel' is from "master" branch. ELPA provides "maint". > But this would prevent exporting all code blocks including inline blocks. > > Isn’t it? > > There seems no way of separately controlling inline and other blocks. There is. You put :eval never-export on all src blocks and :eval t on inline code. Note, however, that inline code might call indirectly src blocks, so this can lead to odd situations. What you are missing, probably, is some way to set this globally. Alas, `org-export-use-babel' or `org-export-babel-evaluate' is not the answer. As suggested in the thread you mentioned earlier, we might as well get rid of `org-export-use-babel' altogether. It seems to confuse many users and isn't very useful. WDYT? Regards, -- Nicolas Goaziou
Re: [O] ox-odt: List items contain body paragraphs, confusing styles
Hello, James Harkins writes: > OK, I just got the expected output by the following: > > - Add "OrgListTextBody" to the stylesheet. I didn't try to do it directly in > text (I don't know ODT XML that well). I created the style with that name in > LO, setting the indent parameters to 0. That gave me this definition in > styles.xml: > > style:parent-style-name="Text_20_body"> >fo:text-indent="0in" style:auto-text-indent="false"/> > > > It's probably enough to specify only ~fo:text-indent="0in"~, but I didn't > test that because I'm not sure how to write the modified styles.xml back into > the ODT archive. (LO auto-generated all 4 parameters.) > > - Then, use my filter to apply OrgListTextBody to the paragraphs contained > within list items. > > The resulting display in LO is correct. Out of curiosity, instead of creating a new style, wouldn't some standard style be enough, e.g., "Text_20_body_20_indent"? Also, what happens in the following cases - ... #+begin_quote Quoted paragraph #+end_quote #+begin_center Centered paragraph #+end_center Should the use "Quotations" and "OrgCenter", which inherit from "Text_20_body", or some new style inheriting from the one dedicated to text in plain lists? Regards, -- Nicolas Goaziou
Re: [O] [PATCH] org-agenda: Add 'none setting for org-agenda-overriding-header
Hello,
Adam Porter writes:
> Here is the new patch.
Thank you.
> I took the liberty of using a macro to replace the code that was
> duplicated in the four agenda functions. Please let me know if you
> would like any further changes.
Some comments follow.
> From 203bc583da0c482ab7092623383fe47c2d729420 Mon Sep 17 00:00:00 2001
> From: Adam Porter
> Date: Sat, 19 Aug 2017 21:26:12 -0500
> Subject: [PATCH] org-agenda: Refactor org-agenda-overriding-header code
>
> Replace org-agenda-overriding-header tests in these four functions with
> calls to a macro, eliminating the duplicate code. Also, disable the
> header when the variable is set to the empty string.
Nitpick: the paragraph above usually comes after the list of changes.
> * lisp/org-agenda.el (org-agenda--insert-overriding-header): Add macro.
> (org-agenda-list): Use macro.
> (org-search-view): Use macro.
> (org-todo-list): Use macro.
> (org-tags-view): Use macro.
Nitpick: you can only write "Use macro" once, on the last line.
> +(cl-defmacro org-agenda--insert-overriding-header (&key default)
Why `cl-defmacro'? Usually, `defmacro' is enough.
> + "Insert header into agenda view depending on value of
> `org-agenda-overriding-header'.
> +If the empty string, don't insert a header. If any other string,
> +insert it as a header. If nil, insert DEFAULT, which should
> +evaluate to a string."
> + (declare (debug (&key form)))
> + `(pcase org-agenda-overriding-header
> + ("" nil) ; Don't insert a header if set to empty string
> + ;; Insert user-specified string
> + ((pred stringp) (insert
> + (org-add-props (copy-sequence
> org-agenda-overriding-header)
> + nil 'face 'org-agenda-structure)
> + "\n"))
While we're at it,
`org-add-props' + `copy-sequence' = `propertize'
> + ;; When nil, make string automatically and insert it
> + ((pred null) (insert ,default
I suggest to use ,@default (and, obviously (&rest default) in the
arguments) so we are not limited to one S-exp.
> + (org-agenda--insert-overriding-header
> +:default (concat (org-agenda-span-name span)
> + "-agenda"
> + (if (< (- d2 d1) 350)
> + (if (= w1 w2)
> + (format " (W%02d)" w1)
> + (format " (W%02d-W%02d)" w1 w2))
> + "")
If you're ready for further refactoring, the nested `if' above could be
turned into a nicer `cond'.
> + (let ((n 0) s)
> + (mapc (lambda (x)
> + (setq s (format "(%d)%s" (setq n (1+ n)) x))
> + (if (> (+ (current-column) (string-width s) 1)
> (frame-width))
> + (insert "\n "))
> + (insert " " s))
> + kwds))
> + (insert "\n"))
Same here: `mapc' + `lambda' = `dolist' to avoid funcall overhead. `s'
could be let-bound too.
All in all, the only requested change is `cl-defmacro' -> `defmacro'.
This is no blocker if you don't want/have time to do the refactoring.
Regards,
--
Nicolas Goaziou
Re: [O] Issue with org-super-agenda and %%diary
BTW, Robert and I fixed this here: https://github.com/alphapapa/org-super-agenda/issues/11
