Re: [O] using flet to suppress meta generation in html export?
Hi Matt, 2018ko azaroak 6an, Matt Price-ek idatzi zuen: > > Hi, > > I was writing a function to quickly post the ocntents of subtrees to the > Canvas Learning Management System. I was trying to strip down the exported > HTML to an absolute minimum and had forgotten about the body-only paramter > to org-export-as (!!). So, my solution was to try to rebind > 'org-html--build-meta-info to always just return "". However, I can't > seem to do it properly and I'm wondering if someone can help me figure out > what's wrong. It's my first time using cl-flet! And I know there are > various approaches, but I odn't understnad whyt this is notworking, when > for instance, this does work for me: > > (cl-flet ((+ >(lambda ( args) (message "no plus!" > (+ "whoops")) > ;; "no plus!" > > Meanwhile, here's my non-functional code: Quoting from the info page (info "(cl) Function Bindings"): The bindings are lexical in scope. This means that all references to the named functions must appear physically within FORMS. I believe that you can accomplish what you are trying to do with: (cl-letf (((symbol-function 'org-html--build-meta-info) (lambda ( args) ""))) your-code-here) You could also do something like: (let ((my-advice (lambda ( _) ""))) (advice-add 'org-html--build-meta-info :override my-advice) (unwind-protect (progn your-code-here) (advice-remove 'org-html--build-meta-info my-advice))) (Why do I think this is better, despite being more verbose? Advice-add is specifically designed to change the binding of functions at runtime, and so it does some specialized things that cl-letf doesnʼt do. This in turn means that it should be a more robust way of accomplishing the desired outcome.) -- Aaron Ecay
Re: [O] C++ is not accepted for SRC block evaluation
Hi Nicolas, 2018ko maiatzak 27an, Nicolas Goaziou-ek idatzi zuen: [...] > > We probably need to implement a mapping between languages symbols and > files and use it in `org-babel-do-load-languages'. The implicit mapping > it uses currently has shortcomings. > > We could also leave it like this (even with my patch reverted), and > document it somehow. Maybe a third column per language in (info "(org) > Languages") to hold the file name. > > WDYT? Improved documentation is never a bad thing. OTOH, I personally would not spend time on implementing the mapping you propose. org-babel-do-load-languages is IMO a relic. I think that all babel languages should be autoloaded, just like normal lisp libraries are. If I had to sketch a design for this, it would be a macro like: (org-babel-define-language R :evaluate org-babel-R-evaluate :session org-babel-R-creaete-session :language-name "R" ;; Both these Could be optional, with the :language-mode R-mode ;; default calculated from the language name ...) This macro would expand to: (add-to-list org-src-lang-modes ...) (add-to-list org-babel-tangle-lang-exts ...) ;; Possibly some others ... (add-to-list org-babel-languages-alist '(R . (evaluate . org-babel-R-evaluate) (session . org-babel-R-create-session) ...)) The intent of the last one would be to get rid of all the (fboundp (intern (concat "org-babel-thingy:" language))) stuff. The org-babel-define-language call(s) in each ob-foo.el file would be marked as autoloads, so that the relevant alists would all be fully populated on emacs startup. org-babel-(do-)load-languages would disappear. Iʼve held back on implementing this (among other reasons) because it would be a big disruption to the babel ecosystem. For all the languages in core and contrib it would be manageable, but there are third-party libraries that would have to be transitioned as well, plus the growing pains of user config files, etc. It would not be a small project. (OTOH, I see other benefits as well. In the longer term, it would be nice to solve the longstanding problems with e.g. the python backend by communicating with a jupyter kernel, rather than trying to drive a python repl attached to a pipe. A more manageable API for babel languages than (fboundp (intern "magic-name")) would probably make it easier to implement this.) ...in any case, the mapping that you propose is not an unreasonable idea in the abstract. But the problem only arises (AFAIK) for the C++/D languages, and itʼs been with us for a long time. My own opinion is that we can just document and live with the situation until something much better comes along. But I also donʼt want to stop you from implementing a small and reasonable fix if you are motivated to do so. :) -- Aaron Ecay
Re: [O] unable to edit indirect-buffer in fundamental mode without losing pretty printing in base buffer org mode
Hi Nicolas, 2018ko maiatzak 27an, Nicolas Goaziou-ek idatzi zuen: > > Aaron Ecay <aarone...@gmail.com> writes: > >> Of course, done in c32938b7f. I did not realize how the freeze for 9.2 >> was working. > > Thank you. > > BTW, I'm considering creating a "next" branch for pending patches that > I'm refraining to push to master. It could help moving forward. +1 on this idea from me. > > We can of course discuss it on the ML, but it would be nice to make > clear what is the problem to solve first. I describe the problem as: Org tries to be slightly WYSIWYG in terms of subscripts (with the relevant configuration settings). But the facade over the underlying textual markup is imperfect. Users sometimes need to edit the textual markup. The patch I created is based on a very similar emacs feature (prettify-symbols-mode). (Unlike the org feature, the emacs feature only font-locks a static list of strings; it doesnʼt handle subscripts where the content to be font-locked can vary). Once org supports emacs 25+ only (is it actually the case already?), I think it would be a good idea to replace the org-entities font-locking with the emacs built-in feature. Then my patch could extend that for subscripts (and we could recycle the core emacs defcustoms which control the featureʼs optionality, rather than needing our own). -- Aaron Ecay
Re: [O] C++ is not accepted for SRC block evaluation
Hi Nicolas, 2018ko maiatzak 27an, Nicolas Goaziou-ek idatzi zuen: [...] > No, that's not correct. It should be (C++ . t), but "ob-C.el" should > provide "ob-C++" feature, too. Is this right? Even if the feature is provide-d by the file, the require in org-babel-do-load-languages will not find it (because the file name does not match). C++ is not a valid choice for the variable AFAICT. The customize interface makes that clear by not offering it as an option, but if the variable is customized outside of customize (so to speak...) chaos reigns... -- Aaron Ecay
Re: [O] Babel - :export-dir and :file-ext arguments cause all blocks to emit files
Hi Nicolas, 2018ko maiatzak 27an, Nicolas Goaziou-ek idatzi zuen: > > Hello, > > Aaron Ecay <aarone...@gmail.com> writes: > >> Iʼve pushed commit 1643f70d3 to master which documents this behavior. > > Thank you. Please have a look at the consistency edits I made to it. Thanks very much. (As an aside: is org-footnote-auto-adjust TRT for the manual? It seems like it will lead to lots of churn every time a footnote is added or removed...) -- Aaron Ecay
Re: [O] unable to edit indirect-buffer in fundamental mode without losing pretty printing in base buffer org mode
Hi Nicolas, 2018ko maiatzak 27an, Nicolas Goaziou-ek idatzi zuen: [...] > > Also, we are in feature freeze for Org 9.2, so this would need, in any > case, to wait for the release. > > As a consequence, would you mind reverting the patches related to this > feature? Of course, done in c32938b7f. I did not realize how the freeze for 9.2 was working. > > However, your fix is not great at all. It was discussed on this ML, > about square brackets in links: it causes "jumpings" during editing, > which some users, including me, find annoying. Even if it was optional, > it would need to be discussed beforehand. I must have missed that discussion. I would say that the “jump” in this case is only three characters, whereas for links it is much more (as the whole link becomes un- and re-hidden). I would not like links to work this way, but for foo-scripts I found it to be quite natural in my testing. So I hope that we can discuss it (as an optional feature, certainly) once 9.2 is out. -- Aaron Ecay
Re: [O] Babel - :export-dir and :file-ext arguments cause all blocks to emit files
Hi Alex, 2018ko maiatzak 25an, Alex Fenton-ek idatzi zuen: [...] > Now I understand how it was intended (a shortcut for people who are > scrupulous about using #+NAME) it makes sense. Iʼve pushed commit 1643f70d3 to master which documents this behavior. > I was thinking it was meant as an easy way to switch globally between > different formats (sometimes I want PDF for ease, sometimes I want > Tikz for publication-quality, sometimes I want SVG for online etc.). I agree it would be nice. You can have executable elisp in header arguments, so it is possible to do something like this (though ugly, since the same snippet has to be duplicated across every src block). One example of what I mean is at <https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-LaTeX.html>; search for “by-backend” in the page. [...] > > You (all) are a better judge of what is a reasonable non-back-compatible > change. Iʼm inclined not to make the change now, but (hopefully remember to) revisit it when Org 10 is imminent. Thanks for raising the issue, -- Aaron Ecay
Re: [O] unable to edit indirect-buffer in fundamental mode without losing pretty printing in base buffer org mode
Hi Van, What you describe is fragile and should not work. OTOH, we need to provide a way to edit those curly braces. I have just pushed commit 102832e66 to the master branch. That will cause any sub/superscript under the point to have its font lock properties removed, so that the braces will become visible for editing. It is modeled after a similar feature in emacs built-in prettify-symbols-mode. So, I think that should address your usecase. Thanks for raising the issue. -- Aaron Ecay
Re: [O] RFC: Proposal for an Org Special Block for ox-html
Hi Kaushal,
[...]
> But then I also wanted to mask all the shortcoming of Markdown. So ox-hugo
> helps bridge that gap by filling in HTML snippets only where needed. I hope
> that makes sense.
It does indeed make sense, thanks for the explanation. Now I understand
the context a bit better.
I added “summary” to ‘org-html-html5-elements’ in commit 5192e810a. It
seems obviously correct (in fact, “details” was already included in that
variable). So now summary/details should work for HTML5 export. Thank
you for raising this issue.
It sounds like you have things well in hand for ox-{hugo,blackfriday}.
And I do not think there are any other shortcomings in org core that are
left outstanding from this discussion.
Thanks again,
--
Aaron Ecay
Re: [O] [patch] Check org-structure-template-alist
Hi Rasmus,
2018ko maiatzak 27an, Rasmus-ek idatzi zuen:
[...]
> If there’s any better way to display the error
org-display-warning?
[...]
> + (mapconcat 'identity
> + '("Please update the entries of `%s'."
> + ""
> + "In Org 9.2 the format was changed from something akin to"
> + " (\"s\" \"#+BEGIN_SRC ?\\n#+END_SRC\" "
> + "to something akin to"
> + "(\"s\" . \"src\")"
> + "See (info \"(org)org-structure-template-alist\")"
> + ""
> + "The following entries must be updated:"
> + ""
> + "%s"
> + "%s")
> + "\n")
You could use a multiline string literal. IMO itʼs less ugly (but
still ugly...)
--
Aaron Ecay
Re: [O] RFC: Proposal for an Org Special Block for ox-html
Hi Kaushal, 2018ko maiatzak 24an, Kaushal Modi-ek idatzi zuen: > That's why I am using (org-element-property :attr_html special-block) in > the code to get the raw values to #+attr_html. Iʼm not sure I made myself clear in the previous message. In any case, this org: ╭ │ #+attr_html: :open t │ #+begin_details │ #+begin_summary │ Open for details │ │ More summary. │ #+end_summary │ Many details here. │ #+end_details ╰ exports to this HTML (using current-ish master with no additional modifications beyond the tweak to org-html-html5-elements): ╭ │ │ │ │ Open for details │ │ │ │ More summary. │ │ │ │ Many details here. │ │ ╰ which displays in the open state in a browser (in any event, in Chromium 66). So I think what you want already exists for this feature. > That would be great. I myself wasn't sure if I should bring that up to Org > core.. I had just implemented #+attr_css support for ox-hugo. > > It looks like this: > > #+attr_html: :class red-text > #+attr_css: :color red > - Red list item 1 > - Red list item 2 > > Above will generate
Re: [O] Babel - :export-dir and :file-ext arguments cause all blocks to emit files
Hi Nicolas, hi Alex, First of all, no issue arises with :output-dir alone. It can be specified as a global header arg without issue. The situation with :file is that it (currently and at all relevant times in the past AFAIK) implies :results file. That is because it would be a little strange if: #+begin_src R :file foo.pdf ... #+end_src did not result in the output going to foo.pdf I designed :file-ext as a direct replacement for :file. That is, instead of the above, one would specify: #+name: foo #+begin_src R :file-ext pdf ... #+end_src and get the same result. IOW, the design was *not* for :file-ext to be specified globally. This perhaps could have been documented better when it was first introduced, and I see that subsequent changes in the manual have not made things clearer. The change Nicolas proposes is how I would make :file-ext work if I were writing it from scratch today, with the benefit of hindsight. I worry that introducing it would break org documents in the wild, but maybe it is worth it. Itʼs probably possible to write an org-lint check for the most common broken case (where :file-ext is specified directly on a block, but :results file is not. This check would not catch a case where :file-ext was specified via a property for a buffer/subtree of blocks all of which are supposed to produce file results. Such a case should be rare, but itʼs not impossible.) Iʼm still not 100% convinced that the breakage would be worth it, but I suppose I would incline towards that view. OTOH I do not think the proposed change makes sense for :file, because it would lead to a nonsensical situation in the case of the first block in this email. It never has made sense to specify :file by inheritance, so I donʼt think anything should change for that case. -- Aaron Ecay
Re: [O] RFC: Proposal for an Org Special Block for ox-html
Hi Kaushal, 2018ko maiatzak 24an, Kaushal Modi-ek idatzi zuen: > > Yes, the proposal though supports these 2 things specific to details > element: > > 1. Detecting "open" attribute via "#+attr_html: open". Is it important for open to be a “bare” attribute (not sure of the official name) like “” as opposed to “”? The latter form is already supported (in fact the second “open” can be any string). Just add #+attr_html: :open any-string-you-want above the block. > > 2. Adding a wrapper tag around the details portion > following the tag. Useful if user wants to set CSS rules for > "details .details". The only thing I know off the top of my head is that CSS can be quite hairy, so I would not be surprised if this wrapper is sometimes needed. And indeed, support for it would be missing. Is it something that is likely to crop up for other elements as well, such that it would be desirable to support it in org core? (This is at least partly me wondering out loud, no need to specifically answer unless something particularly occurs to you one way or the other.) -- Aaron Ecay
Re: [O] RFC: Proposal for an Org Special Block for ox-html
Hi Kaushal, 2018ko maiatzak 24an, Kaushal Modi-ek idatzi zuen: > > HTML allows multi-paragraph summaries.. (see my test link above). Expanding > on your idea.. what if we had another Special block with name summary? I wasnʼt thinking about multiparagraph summaries. But actually, I realize that your suggestion in response would work with only one small change to a variable in ox-html. Specifically, the following document already yields the desired behavior with vanilla org (both giving the proper behavior in html5, and having a fallback for earlier versions): = * setup #+begin_src emacs-lisp (add-to-list 'org-html-html5-elements "details") (add-to-list 'org-html-html5-elements "summary") (setq-local org-html-html5-fancy t) (setq-local org-html-doctype "html5") #+end_src * subtree #+begin_details #+begin_summary Open for details More summary. #+end_summary Many details here. #+end_details = Assuming there are no objections, we could make this tweak to ‘org-html-html5-elements’ in org core. I think “syntactic sugar” like your original proposal could be implemented as a before-parsing-hook that transforms the --- into the above syntax. Aaron PS Once upon a time, I created ox-extras in contrib as a home for little snippets like this hypothetical before-parsing-hook. It never really took off, but maybe itʼs just biding its time... -- Aaron Ecay
Re: [O] RFC: Proposal for an Org Special Block for ox-html
Hi Kaushal, It seems like a good idea. My two comments are: - Remember that ox-html can export to HTML4, so the code would need to detect that case and have a sensible fallback - The approach of looking for “magic” strings in the contents seems hackish. What if the summary was treated as a caption? #+caption: Open for details #+begin_details Many details here. #+end_details (Admittedly, the mismatch between “caption” and “summary” is not ideal, but caption is the only suitable keyword that the syntax gives us...). Another idea would be: #+begin_details #+summary: Open for details. Many details here. #+end_details This approach would require a supporing change to be made to the ‘org-html-keyword’ function. Just food for thought... -- Aaron Ecay
Re: [O] Inheriting some local variables from source code block editing buffers
Hi Göktuğ,
A couple of comments:
2018ko maiatzak 18an, Göktuğ Kayaalp-ek idatzi zuen:
[...]
> +(defcustom org-src-apply-risky-edit-bindings 'ask
> + "What to do if an edit binding is a risky local variable.
> +If this is nil, bindings that satisfy ‘risky-local-variable-p’
> +are skipped, with a warning message. Otherwise, its value should
> +be a symbol telling how to thread them. Possible values of this
> +setting are:
> +
> +nil Skip, warning the user via a message.
> +skip-silent Skip risky local varibles silently.
> +ask Prompt user for each variable.
> +tApply the variable but show a warning.
> +apply-silent Apply risky local variables silently."
It would be more consistent/less confusing to use skip-warn and
apply-warn instead of nil and t. It would also lead to fewer bugs in
the sense that:
[...]
> +(cond ((or (and (eq org-src-apply-risky-edit-bindings 'ask)
> +(y-or-n-p (format prompt-apply name value)))
> + (eq org-src-apply-risky-edit-bindings 'apply-silent))
> + (funcall apply-binding))
> + (org-src-apply-risky-edit-bindings
> + (prog1
> + (funcall apply-binding)
> + (message risky-message "Applied" name)))
> + ((not org-src-apply-risky-edit-bindings)
> + (message risky-message "Skipped" name))
> + ((eq org-src-apply-risky-edit-bindings 'skip-silent))
> + ('else
> + (user-error
> +"Unexpected value for ‘%S’, will not apply this or any more
> bindings."
> +'org-src-apply-risky-edit-bindings
If I am reading the above cond correctly, then the (eq
org-src-apply-risky-edit-bindings 'skip-silent) branch will never be
reached, because it will be eaten by the second branch. (And so will
the “else” branch, for that matter.)
IMO you should use cl-case instead of cond, which will be less conducive
to subtle problems like this and make it clear that the possible values
are exhaustively handled. (That approach will mean shuffling the y-or-n-p
stuff around slightly).
[...]
> +(defun org-src--parse-edit-bindings (sexp-str pos-beg pos-end)
> + ;; XXX: require cadr of the varlist items to be atoms, for security?
> + ;; Or prompt users? Because otherwise there can be complete
> + ;; programs embedded in there.
Maybe instead of using risky-local-variable-p above, this feature should
use safe-local-variable-p instead. Then we wouldnʼt have to worry about
the security implications of allowing non-atom values. It seems like a
version of this feature that only worked for atoms would be quite limited
in functionality. In that case, we should probably call the defcustom
above ...apply-unsafe-edit-bindings for the sake of accuracy.
--
Aaron Ecay
Re: [O] General advice beyond Org
Hi Edgar, 2018ko maiatzak 18an, -ek idatzi zuen: > It is only when we have to collaborate directly that the issue > arises. It sounds like the issue you are having is about collaboration workflow, and not about the usage of free software per se. Reading between the lines, it sounds like your biggest difficulty is with Microsoft Word. Itʼs very unlikely that you will be able to convince your advisor to switch to another program when writing with you. As Diego said, it is ultimately up to you whether you can live with this. But there are certainly compromises you could entertain that might make it easier. There are important benefits, to a field and to individual researchers, of open analyses. On the other hand, what maters about a scientific publication is principally the words themselves and where they are published – not the workflow that was used to create them, which mostly passes into irrelevance once they become part of the scientific record. So you might find pragmatic benefits to focusing on free software analysis tools and programming languages, and on the importance of publicly releasing analysis materials (whether based on free software or not) at an appropriate stage of the research, rather than on document authorship workflow where your advisor seems to have a particularly entrenched position. Another suggestion to reach out to other graduate students, who have the surplus of time* and lack of pre-established workflow habits conducive to learning new techniques. This wonʼt directly solve your issues with your advisor, but if you are contributing to the success of free software in other areas you might feel like your sacrifices with her are being balanced out. (*Having been a graduate student, Iʼm only too aware of the falsity of the premise that grad students have ample free time in an absolute sense. But relative to other career stages, grad students are probably the best situated in that regard. Itʼs also true that there are many things that grad students need to learn that could be learned either with free or nonfree software. The marginal time cost of replacing nonfree software in that learning with free software is likely to be small.) Itʼs also true that free software has network effects. Once someone is using R or Python, they are introduced to things like Jupyter or knitr (which are literate programming systems) – or even org mode. They also get exposed to VCS (like git), free text editors (like emacs, or RStudio), and other tools that do not directly replace Word but contribute to an alternate ecosystem. They might eventually be induced to switch their writing software of choice because of the features of such environments. So by evangelizing the pieces of free software that are most appetizing to others in your field, you are laying the groundwork for subsequent improvements that might initially be a harder sell. Finally, a very pragmatic suggestion. You might suggest to your advisor that you and her collaborate via Google Docs rather than MS Word. This is something I have found helpful with colleagues of mine who are not otherwise prepared to change their writing habits. The Google Docs interface is very similar to Word (but actually avoids some of the radical UI changes that MS has made recently, which might make it even more appetizing to certain users). While Gdocs is not free software (as itʼs important to point out), it enables me to use less proprietary software, on average. Iʼve never been able to get Libreoffice to work satisfactorily for iterative edits to a Word doc; I find that it too often loses formatting, included images, or otherwise doesnʼt interoperate with Word well enough. So in the absence of Google Docs I would have to maintain a Windows system on which to use Word. With Gdocs I have one browser tab that runs unfree JS, but the rest of my system is GNU/Linux. (There are also benefits to the online-first nature of Google Docs, which avoids the emailing back and forth of dueling versions of a Word document that I have sometimes encountered in groups that primarily use Word – but these are orthogonal to the free/nonfree distinction.) I hope that some of this comes as useful advice. -- Aaron Ecay
Re: [O] Inheriting some local variables from source code block editing buffers
Hi Göktuğ, This patch looks good, thanks. Of course, for merging to org core it will need to be an actual patch and not advice. There is also copyright assignment to think of. Do you already have a FSF copyright assignment on file? 2018ko maiatzak 14an, Göktuğ Kayaalp-ek idatzi zuen: [...] > One ‘gotcha’ is that :edit-bindings requires a quoted list whereas the > explicit quote is not necessary with ATTR_EDIT: > > #+BEGIN_SRC elisp :edit-bindings '((lexical-binding t)) > #+ATTR_EDIT: ((lexical-binding t)) That quote is required for the src block version is inherent in the design of babel. For consistency, you could require (or at least permit without requiring) a quote in the other case as well. > > Another problem is that I was not able to define a new element property > named EDIT_BINDINGS, and had to take the shortcut with naming it as an > ATTR_* variable. Preferably, it'd be EDIT_BINDINGS instead: > > #+BEGIN_SRC elisp :edit-bindings '((lexical-binding t)) > #+EDIT_BINDINGS: ((lexical-binding t)) > > But personally I don't think it's that big of a problem. > > > The advice: > > (define-advice org-src--edit-element > (:around > (fn datum args) > attr-edit) > "Apply edit-special bindings." > (let ((attr-edit (org-element-property :attr_edit datum)) > (edit-bindings > (assoc :edit-bindings (caddr (org-babel-get-src-block-info nil > datum > (source-buffer (current-buffer)) > (sub (lambda (varlist source-buffer) >(let (var val) > (dolist (form varlist) >;; If it's a symbol, inherit from the Org mode buffer. >(if (symbolp form) >(setq var form > val (with-current-buffer source-buffer (eval > var))) > ;; Else, apply the specified value. > (setq var (car form) val (cadr form))) >(unless (symbolp var) > ;; XXX: maybe tell where it is? > (user-error "Bad varlist at ATTR_EDIT")) >(set (make-local-variable var) val)) I think you could replace the (let (var val)...) form with: #+begin_src emacs-lisp (pcase-dolist ((or (and (pred symbolp) var (let val (buffer-local-value var source-buffer))) `(,var ,val)) varlist) (set (make-local-variable var) val)) #+end_src This silently skips varlist entries that are of the wrong shape, but it would be possible to make it raise an error as in your version. I like the pcase version better because itʼs shorter and has fewer nested conditionals, but itʼs ultimately a matter of taste. -- Aaron Ecay
Re: [O] Smooth transition for modules
Hi Bastien, 2018ko maiatzak 8an, Bastien-ek idatzi zuen: [...] > > You mean: instead of simply requiring other packages from a package, > add a new Suggest: header for packages suggestions? Everything you described sounds like a wonderful idea. What I had in mind was much simpler. It (I think) does not require adding any new features to package.el. The best way I can explain it is with the following pseudocode, which I envision would be run when org is loaded: (defcustom asked-already-p nil "docstring") (unless asked-already-p (when (and (not (package-installed-p "org-tempo")) (y-or-n-p "Do you like Well, I think that even experienced users would enjoy discovering new > packages when suggested by the packages they use Agreed. My only concern was that users installing from git might not have the right settings of package-archives etc to make the package-install call above work correctly. Maybe I was being pessimistic about that, though. -- Aaron Ecay
Re: [O] Smooth transition for modules (was: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]"))
Hi Bastien, 2018ko maiatzak 8an, Bastien-ek idatzi zuen: > Thanks -- I tested it. Thanks :) > I like the idea of sending a warning to the user for > backward-incompatible changes but in this case, well, we take for > granted that org-tempo will be turned off by default in the next > release... but this is not decided yet. Indeed, the patch was written under that assumption. If the situation changes, (at least) some tweaks would be needed. > > To be clear, the whole change still needs work for sure, and nothing > is decided so far. > > But here is some food for thought on how to deprecate an Org feature > more nicely. > > We have org-modules, which is an internal mechanism to load default > Org modules. Yes, this predates Emacs package system, and yes, we > should question the usefulness of it now (I do). > > But: what if [...] I like this idea, but I also think that emacsʼ packages feature is a better/newer way to implement something like this. What if: 1. We donʼt include org-tempo in org releases 2. We teach GNU ELPA to include org-tempo as a package (corresponding to stable org releases) 3. We teach <https://orgmode.org/elpa/> to also do so (corresponding to nightly org releases) 4. We implement your suggested user prompt, but it will ask them if they want to install the org-tempo package from ELPA In this way, users who either install org from GNU ELPA or use the version bundled with emacs will get the latest release version of org-tempo from GNU ELPA. Those who install the nightly version of org will get the corresponding nightly version of org-tempo.* WDYT? (An alternative to step 3 above is to cater for the nightly release users by putting org-tempo in org-contrib. Then we wouldnʼt have to publish org-tempo on Org ELPA, only GNU ELPA. But this (a) doesnʼt help those who install nightly org as opposed to nightly org-plus-contrib, and (b) means that org-tempo, unlike other packages in contrib, would have to be kept copyright-clean...so Iʼm not sure it is a good choice.) Aaron * Those of us who install org from git might have to do something else to make sure the right version of org-tempo is loaded, but weʼre used to living on the edge. :P -- Aaron Ecay
Re: [O] [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]")
Hi Rasmus, 2018ko maiatzak 7an, Rasmus-ek idatzi zuen: > > They’d already have the "old" behavior if it’s enabled by default in > org.el. Indeed, my suggestion is not an alternative to keeping (what is now called) org-tempo turned on by default indefinitely. It is an alternative to turning org-tempo off suddenly. > Perhaps I’m too cruel or harsh after many years of dealing with the > Emacs-way, but I do think that such as change is adequatly documented > in ORG-NEWS and the manual. (Days after a new release there will also > be a stackoverflow question for the Googlers). Here I am much more conservative than you: I think that puzzling users so that they ask questions on stack overflow is an outcome that should be avoided if possible. I also think experience shows that ORG-NEWS is missed by a significant fraction of users. Besides, I am a programmer not a writer so I believe in the power of code over prose :P [...] > > Customize-changed would bring up the changes to > org-structure-template-alist, which mentions Org Tempo. Interesting. I didnʼt know about that function. I just tried M-x customize-changed RET Org 9.0 RET. That gives an error; it seems to only work based on emacs versions and not package versions. Thatʼs unfortunate, it would have been nice if people who install org from ELPA could use the function to keep up with org changes independently from their emacs version. (In fact, I just sent this as a feature request to the emacs bug tracker, #31383) -- Aaron Ecay
Re: [O] [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]")
Hi Rasmus, 2018ko maiatzak 7an, Rasmus-ek idatzi zuen: > Srecode seems pretty neat, though it might only work in file buffers. > Other than being shipped with Emacs, does it have any advantage over yas? > Are there any plans to merge the two or make them more compatible? Not AFAIK (to both questions). Yasnippet is in GNU ELPA, so the barrier to it becoming integrated into emacs (in whatever way) is low (or at least, not dominated by questions of copyright assignment). > > I think [skeleton.el] was too restrictive. I think I also tried > abbrev and found it not sufficient. Itʼs a pity. In an ideal world emacs would have only one built-in template expansion system which we could build on, instead of 3-4 (depending on whether you count abbrev). But, this is the world we live in. (This is certainly not a criticism of org-tempo btw!) >From another message in the thread: > Thanks. I guess it would be enough to check if the elements of the alist > are cons (newer Orgs) or lists (older orgs). A more "complex" procedure > could look for at the content of the ca?dr, I guess, but I don’t know if > that’s necessary. AIUI the change was from a cons of (character, template string) to a cons of (string, template string). The relevant commit is b56df73. -- Aaron Ecay
Re: [O] Bug: ob-python: Lots of IndentationError [9.1.12 (release_9.1.12-728-ge8a4f3 @ /Users/xcy/src/org-mode/lisp/)]
Hi Chunyang, This bug was introduced by commit 1966d58b2, which “fixed” another problematic case of indentation. Because of issues like this, ob-python has never really worked reliably (in my experience) The only sensible way I can see to evaluate python code from emacs without hitting these kinds of errors is to use jupyter (formerly ipython). You might try the ob-ipython or ob-ein libraries and see if they work for you. (The latter is part of ein, which provides lots of integration emacs <-> jupyter, and not only for org-babel). Disclaimer: I havenʼt used either of these libraries personally, so I donʼt know how well they will work for you. -- Aaron Ecay
Re: [O] [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]")
Hi Rasmus, 2018ko maiatzak 5an, Rasmus-ek idatzi zuen: > Cool, I at least did not know that one. > Can you a reproducible way to try it out? > Without having to make my own templates etc. I havenʼt done anything with it myself. You can open up a blank .el file and test out some of emacsʼs built-in templates. M-x srecode-minor-mode, and then “C-c / /” will prompt you for the name of a template to insert. Entering file:major-mode at the resulting prompt might be the most interesting one. Certain keys are bound to common templates, examples are “C-c / f” for inserting a function and “C-c / v” for a variable The template file corresponding to this is located at $YOUR_EMACS_INSTALL_DIR/etc/srecode/el.srt. Just as an aside, I have now also learned that emacs also includes skeleton.el, which is yet a third template expansion library. Sigh. -- Aaron Ecay
Re: [O] [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]")
Hi Rasmus, 2018ko maiatzak 5an, Rasmus-ek idatzi zuen: > I don’t like it, I’m afraid. Iʼm sorry to hear that. > It’s a bit nagging. I wouldnʼt call it nagging. The user presses “<s[TAB]” expecting something special to happen. The status quo is that nothing at all happens. My proposal is to make something special happen. Itʼs different than what the user expected, but it informs them of what has changed and how to get the old behavior back if they want. Note that the only circumstance when the “nagging” happens is when a user presses “<s[TAB]”, and it goes away when either they add “(org-tempo-global-mode)” to their .emacs or learn a new habit of pressing C-c C-, instead of <s[TAB] (We could make the warning appear only once per emacs session, if that seems like a better balance.) (The patch I posted on the mailing list had a bug, which would trigger the warning more often than it should be. If you installed and tested the patch from my email message, you would have seen that bug. I pushed a followup commit to the org-tempo branch in the repo that fixes the bug.) > There’s tools to mark thinks as obsolete in Emacs should we need to. There are tools to mark functions and variables obsolete when they are used in elisp code. There is no way of warning a user about non-code changes to the user experience, like (in this case) a changed key binding. > > >> One remaining decision to make is: what is the future of org-tempo? I am >> sympathetic to the idea that the best place for it eventually would be >> org-contrib or GNU ELPA, and not org core. > > We don’t have make that decision now, do we? We donʼt strictly have to. Obviously one approach to making the decision is to wait and see whether org-tempo is widely adopted/used, and remove it from core if not. But if we* can already decide on principle that something like org-tempo belongs best in contrib or ELPA, then we can communicate the relevant info all at once when 9.2 is released, rather than for 9.2: “now add (require 'org-tempo) to .emacs to keep using <s[TAB]” [...time passes, a new org release is born...] “now you also have to install org-tempo from somewhere else.” *Here Iʼm using “we” loosely, I imagine it will mostly be up to you with input from Nicolas and Bastien and perhaps others. -- Aaron Ecay
Re: [O] org-babel-do-load-languages
Hi Raghu, 2018ko maiatzak 3an, "N. Raghavendra"-ek idatzi zuen: > > I am puzzled with this definition: Itʼs an unusual function indeed. Thatʼs because it is used as the :set function for the defcustom org-babel-load-languages; see the info documentation (info "(elisp) Variable Definitions"). -- Aaron Ecay
Re: [O] [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]")
Hi Rasmus, 2018ko maiatzak 2an, Rasmus Pank Roulund-ek idatzi zuen: >> Finally, irrespective of which options are chosen, I think that org-tempo >> would be better implemented in terms of a minor mode. This would allow >> it to be autoloaded, turned on/off for different buffer(s) in an emacs >> session, and avoid duplicating the logic for activating global minor >> modes. Patch attached. > > I agree. OK, thatʼs good to know. Iʼve held off on any pushing of the patch to master until everything is worked out. In the meantime, Iʼve put it in a branch “org-tempo”. I also added a second commit to that branch which implements my vision of the upgrade path (deprecation warnings, etc.) For convenience, that patch is also attached to this email. One remaining decision to make is: what is the future of org-tempo? I am sympathetic to the idea that the best place for it eventually would be org-contrib or GNU ELPA, and not org core. If that is decided now, then we can include that information in the upgrade message (i.e. that users who opt in to org-tempo will eventually have to install it specifically). -- Aaron Ecay >From 414503d59b2129c24e95e1e57b54d5662a17308b Mon Sep 17 00:00:00 2001 From: Aaron Ecay <aarone...@gmail.com> Date: Wed, 2 May 2018 17:48:18 +0100 Subject: [PATCH 2/2] Add compatibility code to org-tempo This will warn users of +Alternatively, you may wish to use the new template expansion +facility `org-insert-structure-template', which is bound to +\\[org-insert-structure-template] in org-mode buffers.") + + + (provide 'org-tempo) ;;; org-tempo.el ends here diff --git a/lisp/org.el b/lisp/org.el index 0b8e62357..c67c8d2c5 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -23582,6 +23582,12 @@ when non-nil, is a regexp matching keywords names." (lambda () (add-hook 'change-major-mode-hook 'org-show-all 'append 'local))) +;; For compatibility; remove in Org 10 +(require 'org-tempo) +(defvar org-tempo--user-activated) +(let (org-tempo--user-activated) + (org-tempo-global-mode 1)) + (provide 'org) (run-hooks 'org-load-hook) -- 2.17.0
Re: [O] Inheriting some local variables from source code block editing buffers
2018ko maiatzak 1an, Göktuğ Kayaalp-ek idatzi zuen: [...] > So we've agreed > that what we want is a new header argument, ‘:edit-vars’, whose value is > a form similar to a varlist, where > > - a form (var val) means bind var to val in the editing buffer, > > - a symbol var means bind var in the editing buffer to the buffer-local > value of it in the relevant x.org buffer, as in (setq > (make-local-variable var) (with-current-buffer "x.org" var)) > > Do you confirm? Thatʼs how I understand the proposal, and it seems good to me. > Also, what do you think about :edit-bindings or :edit-locals instead > of :edit-vars? :var is a completely different thing, and :edit-vars > may cause confusion, given the similarity of the name. Agreed. I prefer -bindings, but I suppose itʼs not terribly important: either of your proposed names is a big improvement. -- Aaron Ecay
Re: [O] Inheriting some local variables from source code block editing buffers
2018ko maiatzak 1an, Göktuğ Kayaalp-ek idatzi zuen: > > On 2018-05-01 20:35 +01, Aaron Ecay <aarone...@gmail.com> wrote: >> Thinking about it some more, lexical binding is not a good case for >> this feature, since it has to be set not only in the edit buffer, but >> also when C-c C-c is used in the org-mode buffer to evaluate the src >> block. The :lexical header arg (which I did not know about) works for >> the latter but not the former. To complete the picture, Someone™ needs >> to implement a org-babel-edit-prep:emacs-lisp function which looks for >> :lexical yes in the header arguments and sets the value in the edit >> buffer appropriately. > > I can (and plan to) take on that task once a design is agreed upon. I > don't really know much about Org internals, but I think I can figure > out. That is excellent news :) If you run into anything you canʼt figure out then let us know. > >> If lexical-binding is the major motivating factor, then maybe the above >> is enough. My original suggestion was for something like: >> >> #+begin_src emacs-lisp :edit-vars ((fill-column 72) (other-var other-val)) >> ... >> #+end_src >> >> This would set the variables in the edit buffer in the (hopefully) >> obvious way. It is not implemented yet, though. > > I do like that syntax. A minor addition might be for the case when one > wants to pass the value of a variable local to the org buffer to the > editing buffer: That looks fine to me. > > -*- fill-column: 65; indent-tabs-mode: nil -*- > #+edit-vars: (indent-tabs-mode) A minor note, the above line should read: #+header: :edit-vars (indent-tabs-mode) > #+begin_src emacs-lisp :edit-vars (fill-column (lexical-binding t)) But because of the nature of the variable (a lisp list), it can only be set once. So you can have only one of: #+header :edit-vars ... OR #+begin_src emacs-lisp :edit-vars ... OR #+property: header-args:emacs-lisp :edit-vars ... OR :PROPERTIES: :header-args:emacs-lisp: :edit-vars ... :END: But they canʼt be combined. AFAIR, :var is the only header argument that can be meaningfully specified more than once. -- Aaron Ecay
Re: [O] Inheriting some local variables from source code block editing buffers
2018ko maiatzak 1an, Göktuğ Kayaalp-ek idatzi zuen: [...] >> The approach that should be taken should be to use a header argument to >> specify an alist of variables and values to set in src block edit buffers. >> Then the usual methods (info "(org) Using header arguments") could be used >> to control the feature globally, per-buffer, per-language, per-subtree, >> and per-individual source block. > > I agree. But note that what I want to do is to set some buffer local > variables in the special block editing buffer. The header argument > ":lexical yes" seems to not affect the editing buffer Thinking about it some more, lexical binding is not a good case for this feature, since it has to be set not only in the edit buffer, but also when C-c C-c is used in the org-mode buffer to evaluate the src block. The :lexical header arg (which I did not know about) works for the latter but not the former. To complete the picture, Someone™ needs to implement a org-babel-edit-prep:emacs-lisp function which looks for :lexical yes in the header arguments and sets the value in the edit buffer appropriately. If lexical-binding is the major motivating factor, then maybe the above is enough. My original suggestion was for something like: #+begin_src emacs-lisp :edit-vars ((fill-column 72) (other-var other-val)) ... #+end_src This would set the variables in the edit buffer in the (hopefully) obvious way. It is not implemented yet, though. Aaron PS Itʼs best to use “reply all” and include the org mode mailing list in replies, to make sure everyone following the thread sees all the messages. -- Aaron Ecay
Re: [O] Inheriting some local variables from source code block editing buffers
2018ko maiatzak 1an, Nicolas Goaziou-ek idatzi zuen: > > No, because you can use Noweb syntax wherever you need these local > variables set: > > <> This would still require adding something to each source block, which I think Göktuğ wants to avoid doing. With respect to the original proposal, I donʼt think itʼs a good idea to inherit the values from the org buffer. I can imagine that one might want to have different values of (e.g.) fill-column in org-mode vs emacs-lisp-mode. The approach that should be taken should be to use a header argument to specify an alist of variables and values to set in src block edit buffers. Then the usual methods (info "(org) Using header arguments") could be used to control the feature globally, per-buffer, per-language, per-subtree, and per-individual source block. If this isnʼt desired as a core feature I wouldnʼt see an impediment to having it be part of org-contrib, though it could also be distributed via (GNU/M)ELPA; it would be Göktuğʼs choice I guess. Aaron PS My view is the lexical-binding case is important enough that this feature should be included in core, and that core should default to lexical-binding: t in elisp src blocks -- Aaron Ecay
Re: [O] [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]")
Hi Nicolas, Iʼm very sympathetic to the direction of travel of these changes, and to the suggestion that you make in your message about using warnings to advert users to incompatible changes. (As you can read in my message to the parent thread). However (with great respect for all that you have done to improve org over the years), I think you missed the point in some of the things you wrote. 2018ko maiatzak 1an, Nicolas Goaziou-ek idatzi zuen: [...] > I think some of you (basically, anyone thinking we should enable " TAB" by default ;)) are missing the point. > > > The first important thing to understand is that, even if we enable > `org-tempo' by default, next Org release /will break/ for some of us. > > - It will break because `org-tempo' is only 99% backward-compatible. So > anyone having customizing templates is bound to change them. > > - It will break because there are 9 other incompatible changes between > 9.1 and 9.2. > > So, asking to load `org-tempo' by default just to avoid breaking users > set-up is a wrong argument. It will only "protect" those among us that > use " incompatible changes. IOW, updating Org from 9.1 to 9.2 will not be > smooth for everyone. No matter what `org-tempo' becomes. By this logic, since org 9.2 already contains 9 breaking changes, we can change anything else in that version. Make all the key bindings start with M-S-C-e instead of C-c, sort all the headings in a file in alphabetical order when opening it, ... No software update will ever be entirely disruption-free, if nothing else because bugs will always happen. So we have to think about the impact of (intentional) changes not in a binary Yes/No fashion, but in terms of how many users they affect, and how bad that effect is. In this case, the number affected is large (as measured informally by participation in this poll) and the disruption is severe (a specifically documented org feature now doesnʼt work, with no obviously discoverable reason why). So that is a powerful argument against making the change in this way, when we can achieve the same long-term effect in a less disruptive way (with deprecation warnings). I do think that breaking changes should be grouped into batches. And if org has as many as ten that are pending, it is a strong argument to call the next release version 10, with all the associated fanfare (and breakage warnings!) Or if point releases are needed in the meantime, hold these breaking changes on a branch that can be merged before Org 10. [...] > Expansion templates are a great thing, but this is only sugar for Org, > which is totally usable without them. Besides, some facilities are > providing it for us. This falls into (2). By design, I'm convinced we > should not include them. I also wish that anyone involved in this thread > can take a step back to see the whole picture. This is a red herring. The changes do not eliminate expansion template code from org. They merely substitute (incompatibly) one expansion template mechanism for a new one. FWIW, I do think the idea is worth exploring of getting rid of the (old and new) template expansion code and using emacsʼs built-in SRecode template facility. Like most of the CEDET stuff, it looks horridly overengineered at a first glance. But it is also included with emacs by default (unlike e.g. yasnippet which otherwise looks more pleasant to program to me), and it would be (even more) responsive to the concerns from emacs-devel that were quoted in your full message. To be specific, this would entail (eventually) getting rid of the org-structure-template-alist variable entirely, as well as the menu now bound to C-c C-,; the former would be replaced by (AFAIUI) template files that would be included with org and/or created by users for their custom templates; the latter would use SRecodeʼs built-in template selection instead. -- Aaron Ecay
Re: [O] [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]")
2018ko apirilak 29an, Tim Cross-ek idatzi zuen: [...] > I think org itself should provide a very stable core and avoid > incorporating too many add on enhancements. It should be as stable as > possible to encourage others to develop and maintain such enhancements > and extensions. As someone who has worked (in a small way) on orgʼs development, I certainly agree with the above sentiment. Org is a many-headed hydra, and decreasing its surface area makes for a better org (since development efforts can be concentrated) as well as a better overall user experience (because users can rely on packages, like in this case yasnippet, that are better at doing something that Org tried to do). On the other hand, as an org user breaking changes are inconvenient. I have the impression that I can keep up with using org-mode only because I follow the development list. Whatʼs much worse, I feel like I should not advocate the use of org-mode to my colleagues (who are often quite computer-literate but value long-term stability of software they use), basically because of the potential problems Bastien listed in his message. This situation is also inconvenient for developers...I have in mind a change several years ago to the #+begin_src lines for shell code. We changed from #+begin_src shell to #+begin_src sh (or vice versa, I canʼt remember precisely). The result was that “bug” reports trickled in for over a year, all of which had to be answered with the advice to change to the new specification. At the time I paid close attention to babel-related bug reports because I was working on that code a lot. Answering these reports (or even just reading them to see that they had been answered by someone else) took away from my opportunity to do (what I saw as) interesting things with orgʼs code. I can only imagine that for ML subscribers who were not as interested in babel bugs as I was, the distraction could only have been worse. As a general (idealized) principle, I think user-visible changes should be phased in over at least one org major version. I have no problem with “intrusive” deprecation warnings, but abrupt changes in behavior should be avoided. Hereʼs what I imagine that could look like in the org-tempo case: For org 9.X: - Introduce the new functions and machinery for org-tempo as well as the new C-c C-, keybinding - Enable org-tempo by default - Show a user warning whenever a “<X” style template is being expanded, saying that this feature will go away in the next major version and to keep it, users should add “(require 'org-tempo)” to their .emacs - Arrange matters so that users who take this step will not receive further warnings when expanding >From 012f8d0b71c76f5d255af6bdaeb2d9c83a47cf85 Mon Sep 17 00:00:00 2001 From: Aaron Ecay <aarone...@gmail.com> Date: Tue, 1 May 2018 15:32:36 +0100 Subject: [PATCH] Use minor-mode machinery for org-tempo * lisp/org-tempo.el (org-tempo-mode): (org-tempo-global-mode): New minor modes. (org-tempo-mode--activate-in-buffer): New function. --- lisp/org-tempo.el | 33 ++--- 1 file changed, 22 insertions(+), 11 deletions(-) diff --git a/lisp/org-tempo.el b/lisp/org-tempo.el index e1268b893..2feed24dc 100644 --- a/lisp/org-tempo.el +++ b/lisp/org-tempo.el @@ -170,17 +170,28 @@ didn't succeed." 'org-tempo-tags) -;;; Setup of Org Tempo -;; -;; Org Tempo is set up with each new Org buffer and potentially in the -;; current Org buffer. - -(add-hook 'org-mode-hook 'org-tempo-setup) -(add-hook 'org-tab-before-tab-emulation-hook 'org-tempo-complete-tag) - -;; Enable Org Tempo in all open Org buffers. -(dolist (b (org-buffer-list 'files)) - (with-current-buffer b (org-tempo-setup))) +;;; Org Tempo minor mode + +;;;###autoload +(define-minor-mode org-tempo-mode + "Expand \"<X\" style templates in org-mode buffers. + +See `org-tempo-keywords-alist' for more information on how +templates are defined." + :lighter " tempo" + (if org-tempo-mode + (progn + (org-tempo-setup) + (add-hook 'org-tab-before-tab-emulation-hook #'org-tempo-complete-tag nil 'local)) +(remove-hook 'org-tab-before-tab-emulation-hook #'org-tempo-complete-tag 'local))) + +(defun org-tempo-mode--activate-in-buffer () + (when (derived-mode-p 'org-mode) +(org-tempo-mode 1))) + +;;;###autoload +(define-global-minor-mode org-tempo-global-mode org-tempo-mode + org-tempo-mode--activate-in-buffer) (provide 'org-tempo) -- 2.17.0
Re: [O] [RFC] Remove Org Struct mode
Hi Nicolas, 2017ko abuztuak 20an, Nicolas Goaziou-ek idatzi zuen: > > Hello, > > I would like to remove Org Struct minor mode from Org code base. FWIW, +1 from me. I often bumped up against org-struct related difficulties when coding on org, and I can easily imagine that removing it will make maintenance much easier while (as you pointed out) still leaving alternative solutions for recovering (most of) its functionality. -- Aaron Ecay
Re: [O] [ANN] New Org duration library
Hi Nicolas, hi Achim, 2017ko otsailak 21an, Nicolas Goaziou-ek idatzi zuen: [...] >> Also, I find the documentation to be completely impenetrable. > > Great. Suggestions welcome. I took a look at the docstring. I think I managed to understand it, but I can see how it might be confusing. I made an attempt to restructure it to explain first the general cases and then the exceptions, which is a clearer order (at least to me). I also changed some minor things that hopefully make it clearer overall. Iʼve pasted that effort at the bottom of this email. I had a few questions/comments though: - Given that the smallest unit of duration is the minute, why are seconds a choice in h:mm:ss? Wonʼt they always be zero? Maybe it is better not to offer this choice; I think it is potentially confusing (giving the impression that durations might be accurate to the second). - I would remove the h:mm symbol shorthand. It can still be offered as a convenient option in customize using (const :tag "Use H:MM" (special . h:mm)), but making it a special value with its own semantics makes the system harder to understand for those who write their config in lisp (rather than using customize). - The fact that the special options are grouped under the key “special” is a bit confusing. If it isnʼt too much work, I would recommend restructuring the options slightly to be (use-h:mm . t) and (precision . INT). This more closely matches my intuition about how alists like this are used. - Must the list be in decreasing order of unit size, or does everything work if itʼs in arbitrary order? The documentation doesnʼt make it clear one way or the other. = Format definition for a duration. The value should be a list of entries each following this pattern: (UNIT . REQUIRED) UNIT is one of the unit strings defined in `org-duration-units'. A duration is formatted using only the time components that are specified here. If a time unit in missing, formatting falls back to the next smallest unit. A non-nil REQUIRED value for these keys indicates that the corresponding time component should always be included, even if its value is 0. For example, ((\"d\" . nil) (\"h\" . t) (\"min\" . t)) means a duration longer than a day is expressed in days, hours and minutes, whereas a duration shorter than a day is always expressed in hours and minutes, even when shorter than an hour. On the other hand, the value ((\"d\" . nil) (\"min\" . nil)) means a duration longer than a day is expressed in days and minutes, whereas a duration shorter than a day is expressed entirely in minutes, even when longer than an hour. At the end of the list, there can be an entry indicating special formatting needs. It must follow one of the three following patterns: (special . h:mm) (special . h:mm:ss) (special . PRECISION) When one of the first two is present, a duration is expressed in mixed mode, where larger units are used down to hours, then the remaining hours and minutes of the duration are expressed as a \"H:MM:SS\" or \"H:MM\" string. With the last pattern, a duration is always expressed with a single unit. PRECISION, an integer, indicates the number of decimal places to show. The unit chosen is the first one required or with a non-zero integer part. If there is no such unit, the smallest one is used. Thus, the following format ((\"d\" . nil) (special . h:mm)) means that any duration longer than a day is expressed as a whole number of days plus a \"H:MM\" part, whereas a duration shorter than a day is expressed only as a \"H:MM\" string. The following format ((\"d\" . nil) (\"h\" . nil) (special . 2)) expresses a duration longer than a day as a multiple of a day, accurate to two decimal places. A duration shorter than a day uses units of an hour instead. Finally, the value can be set to the symbols `h:mm:ss' or `h:mm', which means a duration, whatever its length, is expressed as a \"H:MM:SS\" or \"H:MM\" string respectively. These options are convenient shorthand which is equivalent to ((special . h:mm:ss)) or ((special . h:mm)). -- Aaron Ecay
Re: [O] org-export-babel-evaluate=nil ignores ":exports results" setting - this has changed
Hi Chuck, 2017ko otsailak 20an, "Charles C. Berry"-ek idatzi zuen: [...] > > Allowing header args to be processed (as before) also allows for arbitrary > code to be executed. The point of setting ‘org-export-use-babel’ or > `org-export-babel-evaluate' to nil was to prevent this. For that reason > the former behavior was a bug. Iʼm not sure I agree that itʼs so simple. There are still ways to execute arbitrary code on export independently of babel (e.g. eval macros). The advice to use o-e-babel-evaluate for security was never (IMO) correct – the only properly secure wat to export untrusted documents would involve some kind of sandboxing of the emacs executable. The original bug that led to the change in the behavior of o-e-b-e was that a misspecified var header would lead to an error on export <http://thread.gmane.org/gmane.emacs.orgmode/106767>. I think the change was an overreaction to that problem (and insofar as it changed the long-standing behavior of that variable, a regression). Export (c/sh)ould still respect static (i.e. non-executable) header args; o-e-b-e should only inhibit executable args. From the standpoint of implementation, the execution of code in header args can be controlled by the inhibit-eval argument to org-babel-read and the light argument to org-babel-get-src-block-info (and both functions might need to be extended to look at dynamic variables in addition to these arguments). Taking a step back, I would ask what justifies o-e-b-eʼs existence at all. This thread demonstrates that itʼs not the right way to prevent babel blocks from executing on export. Itʼs also not a good solution to the security issue. Given the potential for confusion, Iʼd be in favor of deprecating it entirely unless thereʼs some compelling reason for it to exist that Iʼve overlooked. -- Aaron Ecay
Re: [O] Sync up the org in emacs master to org maint branch?
Hi Lars, 2017ko urtarrilak 31an, Lars Ingebrigtsen-ek idatzi zuen: > > John Wiegley <jwieg...@gmail.com> writes: > >> We're moving toward a future where Emacs.git will represent "core >> Emacs", and only contain what core needs (plus a few historical bits, >> I'm sure). There should be no argument for keeping a project in core >> just to gain auxiliary benefits. > > I'm massively unenthusiastic about this future. Things in ELPA has to > be backwards-and-forwards compatible with a wide Emacs version range, This seems like a technical limitation of ELPAʼs current implementation, rather than a conceptual impossibility. If ELPA made available (on the server for downloading, and in the client for installing) old versions of packages, then users could always be offered the latest compatible version, but not later incompatible ones. Developers would have to be a little more diligent about declaring their packagesʼ dependencies on emacs major versions (or on other packages, if they depend on parts of core that have migrated to ELPA), but this would be a small hurdle. Aaron PS Speaking of dependency management, Iʼd be more worried that this kind of approach will accelerate the advent of dependency hell with ELPA packages...but I think all package repos have to confront that problem eventually. So Iʼd file that thought under “inevitable growing pains” rather than “arguments against”. -- Aaron Ecay
Re: [O] [PATCH] New header parameter :show-process for Org-babel-clojure
Hi Nicolas, hi all, 2016ko azaroak 17an, Nicolas Goaziou-ek idatzi zuen: > > Hello, > > Frederick Giasson <f...@fgiasson.com> writes: > >> I am still waiting for FSF's signature. Should come in soon I guess. > > I applied your patch on a local branch, but compilation issues the > following warnings: > > In toplevel form: > ob-clojure.el:86:1:Warning: Unused lexical variable > `nrepl-sync-request-timeout' > > In org-babel-execute:clojure: > ob-clojure.el:149:34:Warning: reference to free variable > `org-babel-clojure-sync-nrepl-timeout' It looks like this warning results from a defcustom for this variable not being included in the patch (and AFAICT it should be). -- Aaron Ecay
Re: [O] force italic mode?
Hi Eric, hi all,
2016ko azaroak 17an, Eric Abrahamsen-ek idatzi zuen:
>
> John Kitchin <jkitc...@andrew.cmu.edu> writes:
>
>> No what Hymie wants is part of the middle of that word italicizes I
>> think.
>
> Oh, sorry! Don't know how I missed that. Well, still, same solution:
>
> fuzzy@@html:@@wuzzy@@html:@@wuzzabear
>
> So far as I know there's no way to do that *outside* of an
> export-specific snippet, but I would love to be proved wrong.
You can accomplish this by using an entity that expands to nothing. The
closest entry in org-entities is \zwj (zero width word-joining space):
foo\zwj{}/bar/\zwj{}baz
I have an entry like the following defined in org-entities-user for this
purpose:
("nothing" "" nil "" "" "" "")
It might be worth considering adding to org-entities, but I’ve never
proposed it as it looks like an ugly hack to me.
--
Aaron Ecay
Re: [O] Capture templates - using result from %^g twice?
Hi Rainer, 2016ko azaroak 18an, Rainer M Krug-ek idatzi zuen: > >> :SHEET: %(mapconcat #'identity (org-get-tags-at nil t) ":") > > Thanks - this looks good to me, but the ="= causes problems and ends the > template early. I tried to replace =":"= with =':'= but this did =not > work either (invalid-read-syntax). > > How can I get this to work? You need to escape the quotes with a single backslash. -- Aaron Ecay
Re: [O] org-eldoc and shell
Hi Fabrice, shell-mode is a shell emulation mode – what you get when you type M-x shell. You should use sh (or bash, as applicable) in the header line of your src blocks. -- Aaron Ecay
Re: [O] [RFC] Change visibility for bracket links
Hi Nicolas, 2016ko urriak 13an, Nicolas Goaziou-ek idatzi zuen: > > Hello, > > Aaron Ecay <aarone...@gmail.com> writes: > >> FWIW, I agree. On the other hand, many people object to the brackets. > > I don't mind adding a variable. I think that org in general has too many customization variables. Of course, for each of them there is some user(s) who regard it as very important to their workflow. So, we should think hard before introducing new ones about whether there is a way to accomplish what we want which does not need a variable. (Of course, sometimes this goal is not possible and a new defcustom is needed.) [...] >> WDYT? > > That would only partly solve the problem. Cursor's color would tell you > where you are, but the dance (e.g., C-a or backward-forward) is still > needed to effectively move to the other side. Yes: the point will always be in only one of the two positions indicated in my previous mail. And some command(s) will always be needed to move between the two. AFAICT this remains true under any scenario: the status quo, the proposal for visible brackets, or the one for distinctive cursor color. The question as I understood it is finding a display mechanism that communicates the information about which of the two positions point is in when it is relevant, without being obtrusive during other editing. You also pointed out the importance of making the commands needed as obvious as possible. I think the bracket proposal satisfies the goal of perspicuous commands, but not of presenting the information only when relevant. Changing point color satisfies the presentation criteria, but the movement commands would not be very obvious. The suggestion of hiding and showing markers based on point motion, raised in another subthread, is interesting. It might be the best of both worlds. I would like to try out a POC implementation. (I believe I can predict the effect of either the brackets or the cursor colors on my editing experience, but not necessarily the other.) -- Aaron Ecay
Re: [O] [RFC] Change visibility for bracket links
Hi Nicolas, hi all, 2016ko urriak 13an, Nicolas Goaziou-ek idatzi zuen: [...] > Not really. It makes my example more bearable, but using C-a is still > a workaround, and there are also many other dances to perform in various > other cases. So, I still think there is an usability issue that needs to > be fixed. FWIW, I agree. On the other hand, many people object to the brackets. My understanding of the problem is that when link fontification is turned on, it is impossible to tell between the two marked positions when point is in in a link like: [[http://google.com][Search]] ^ ^ My suggestion is that we solve the problem in a different way: by changing the color of the cursor when the text is inside the link. So, the cursor would be the default grey color at the first ^ above, and red at the second ^? (Of course, the color we use for the cursor in links could be changed by customization). It looks like such an effect is achievable by combining the cursor-sensor-functions text property with set-cursor-color. WDYT? -- Aaron Ecay
Re: [O] [BUG] TRAMP error in PDF export
Hi Phil, Org isn’t currently set up to handle compiling Latex documents on a remote machine. I suppose the relevant function should detect such an attempt, and immediately error out. Over the longer term, remote compilation support could be added. -- Aaron Ecay
[O] Fwd: Re: Graphics to HTML, LaTeX/PDF and DocBook?
Whoops, forgot to cc the list... --- Begin Message --- Hi Peter, You could export to different formats, conditional on the type of export. This has been discussed on the ML several times, hereʼs one example to get you started: <http://thread.gmane.org/gmane.emacs.orgmode/105552>. HTH, -- Aaron Ecay --- End Message --- -- Aaron Ecay
Re: [O] Add org-bookmark-heading to Org proper?
Hi Adam, The package looks useful, and we ought to have this functionality as part of org. The first question that arises is whether you have completed the copyright assignment process described at <http://orgmode.org/worg/org-contribute.html#orgheadline1>: an assignment is necessary for any patches to org-mode core. The assignment process takes some time, so (if the assignment is something you want to do) you can go ahead and get started. You only have to go through the process once, and you’re covered for this and all future contributions to org mode/emacs. -- Aaron Ecay
Re: [O] XML dump of org file?
Hi Norman, Have a look at the org-element library, which can produce an sexp representation of the structure of an org document. (In particular the function ‘org-element-parse-buffer’). You’ll need to convert the sexps to XML, but that’s a comparatively minor task. HTH, -- Aaron Ecay
Re: [O] Feedback on changes to org-id
Hi Adam, 2016ko irailak 22an, Adam Porter-ek idatzi zuen: > > Personally, I wish org-id-find would not be removed, because I use it in > org-bookmark-heading, e.g.: Any change to the API would leave in place a compatibility alias for a significant period of time (at least one major version of Org), and there would be deprecation warnings to encourage package authors to switch to the new API. So packages like yours would continue to work without interruption, and they could eventually move to the new API at the appropriate time (as judged by their authors). -- Aaron Ecay
Re: [O] Babel Export - Getting asked for coding system
Hi David, The way you have this code set up, perl will print a string to its stdout. Emacs will read that string into a buffer, then write it to a file. It would be simpler to write the file directly from perl. Note that this will require specifying the file name twice (in the :file header and in the perl code). This is because ob-perl does not support the :results graphics syntax (which could be classed as a wishlist-type bug). -- Aaron Ecay
Re: [O] Feedback on changes to org-id
Hi Nicolas, Thanks for your feedback. I am almost done incorporating it into the patch. I have only two further questions. 2016ko irailak 3an, Nicolas Goaziou-ek idatzi zuen: [...] >> 4. A similar issue arises for org-id-find. I would like it to always >> return a marker, rather than having an argument switch between a >> marker and a cons of filename and position. (There are functions >> which return the filename or position individually, so returning both >> as a cons is useless from an API point of view). There’s no good way >> to detect the old calling convention, however, so I think I have to >> introduce a new name. (My draft patch is written instead with hard >> breakage, but stability of API is important so I will change >> that...) > > Please don't make that change. A marker is pointless if the file is not > currently associated to any buffer. In that case (file-name . postition) > cons cell is a valuable return value. The API has the following two functions already: - org-id-find-file-for: id -> file-name - org-id-find-id-in-file: id file -> position Imagine I add to this API org-id-find-marker: id -> marker. Then I think we can deprecate (and eventually delete) org-id-find, since all its uses can be replaced by some combination of the other 3 functions. (We could also keep it as a convenience function wrapping the other 3, but it hardly seems worth it: the marker case just adds the overhead of another funcall, whereas a significant proportion of the non-marker calls in the codebase actually only care about the file name, so it is a waste of effort to calculate the buffer position only to throw it away.) WDYT? > > You can also remove `org-id-track-globally'. "org-id.el" is useless if > it is set to nil anyway, since CUSTOM_ID does a better job in this > case. I think this would imply writing the ID database to ‘org-id-locations-file’ under certain circumstances without asking/letting the user approve this action. Is that OK? (I am not bothered by it, FWIW). If it’s not acceptable, perhaps this variable should be replaced by a new defcustom ‘org-id-write-database’ which would control only the writing of the DB to disk (but unlike the existing implementation would not turn off the ID tracking code paths within the emacs session). TIA, -- Aaron Ecay
Re: [O] [org-src, patch] colored source blocks
Hi Rasmus, The patch in general LGTM. One comment/question, though: 2016ko irailak 21an, Rasmus-ek idatzi zuen: [...] > +(defcustom org-src-block-faces nil > + "Alist of faces to be used for source-block. > +Each element is a cell of the format > + > + (\"language\" FACE-OR-BACKGROUND) > + > +Where FACE-OR-BACKGROUND is either a face, an anonymous face, or > +a string corresponding to a background color. Why do you support a background color string here? I think that it’s easy to specify faces which consist of a background color only both in lisp [(:background "XXX") vs. "XXX"] and via the customize interface. So this flexibility seems to just introduce additional complications for virtually no benefit in usability. But maybe I’m missing something...? -- Aaron Ecay
Re: [O] using rgrep, ag, etc in folded org files?
Hi Joakim, The function org-reveal needs to be run after the search is executed. If you are using the built-in emacs rgrep (for example), I think you need to add a function to next-error-hook. Grep for “add-hook 'occur-mode-find-occurrence-hook” in org.el for inspiration. (Arguably this hook function should be added to org-mode, if enough people find it useful). -- Aaron Ecay
Re: [O] fill paragraph: break after sentence.
Hi Uwe, The following code is what I use. It uses filladapt mode, but doesn’t work with auto-fill (I manually refill paragraphs with M-q as I’m writing). I wrote the code a long time ago, it works for me, YMMV, etc. Hope it is helpful. #+BEGIN_SRC emacs-lisp (defun awe-org-fill-paragraph-function ( ignore) (let ((bounds (cons (save-excursion (backward-paragraph) (point)) (save-excursion (forward-paragraph) (point beg end end-marker) (save-excursion (goto-char (cdr bounds)) (skip-chars-backward "\n") (setq end-marker (point-marker)) (setq end (make-marker)) (goto-char (car bounds)) (skip-chars-forward "\n") (catch 'exit (while t (setq beg (point)) (forward-sentence) (move-marker end (point)) (save-excursion (goto-char beg) (when (and fill-prefix (not (looking-at-p (regexp-quote fill-prefix (insert fill-prefix)) (while (re-search-forward "\n *" end t) (replace-match " "))) (setq beg (point)) (skip-chars-forward " \n") (move-marker end (point)) (when (>= (point) end-marker) (throw 'exit t)) (when (/= beg end) (delete-region beg end)) (insert "\n" (set-marker end-marker nil) (set-marker end nil))) (defun awe-org-setup-fill-hook () (setq-local sentence-end-base (rx (any ".?!") (? "[fn:" (+ (any "0-9" "a-f")) "]") (* (any "]\"'”)}" (when (featurep 'filladapt) (setq-local fill-paragraph-function #'awe-org-fill-paragraph-function) (make-local-variable 'filladapt-token-table) (make-local-variable 'filladapt-token-match-table) (make-local-variable 'filladapt-token-conversion-table) (cl-pushnew `(,(rx "#+" (or "caption" "CAPTION") ": ") org-caption) filladapt-token-table :test #'equal) (cl-pushnew '(org-caption org-caption) filladapt-token-match-table :test #'equal) (cl-pushnew '(org-caption . exact) filladapt-token-conversion-table :test #'equal)) (visual-line-mode 1) (auto-fill-mode 0)) (add-hook 'org-mode-hook #'awe-org-setup-fill-hook) #+END_SRC -- Aaron Ecay
[O] Feedback on changes to org-id
Hello all, It’s an occasional project of mine to try to improve and refactor aspects of org’s code. I’ve been going through org-id recently. The following issues came up that I would appreciate feedback on: 1. org-id is not loaded by default; it is supposed to be selected by the user (see footnote 2 of (info "(org) Handling links")). Yet, other org libraries rely on it, without requiring it (e.g. ox-icalendar). Also, at least one library (org-bibtex) reimplements bits of org-id’s internals to avoid requiring it explicitly. Is there a good reason not to make org-id a core library, that is to require it unconditionally from org.el? 2. I would like to deprecate the org-id-method variable. This allows choosing different methods of generating random IDs. But one method is as good as another (they are random*...), so we can just always use a single method (powered by the elisp ‘random’ function). Choosing this allows deprecating several other variables and functions, along with a soft dependency on the external uuidgen binary. Any objections to this course of action? (* Not all the values of org-id-method lead to IDs that are random in the statistical sense. But they are not meaningful from the user’s point of view in any case.) 3. I would like to change the API of the org-id-get function. The current signature is ( pom create prefix). POM (i.e. position or marker) is a useless argument, because in the (relatively uncommon) case that callers are interested in a location other than (point) they can wrap the call in (org-with-point-at ...). PREFIX is similarly useless (and in fact unused in org’s code base) because a caller could let-bind org-id-prefix around the call. The new signature would be ( create reset), which are both boolean arguments. The question arises of how to make this change. Options I see: a. Hard breakage; code using the old calling convention will break. b. Introduce a new function under a new name, deprecate the old name c. Try to detect which calling convention is in use. Options (a) and (b) have drawbacks. I would like to implement (c) by requiring the create and reset arguments, if given, to have values 'create and 'reset respectively. The old and new calling conventions have identical semantics when both arguments are nil, so that case is not a problem. With the new code, any other value for these arguments (besides nil and a same-named symbol) would indicate use of the old convention, and signal an error. Comments? 4. A similar issue arises for org-id-find. I would like it to always return a marker, rather than having an argument switch between a marker and a cons of filename and position. (There are functions which return the filename or position individually, so returning both as a cons is useless from an API point of view). There’s no good way to detect the old calling convention, however, so I think I have to introduce a new name. (My draft patch is written instead with hard breakage, but stability of API is important so I will change that...) There are other deprecations and renamings as well, but none of them should break third-party code. The resultant patch shrinks the codebase by 60-ish lines and eliminates 3 defcustoms...baby steps. A draft patch is attached to this message; I expect to make further changes based on feedback I receive, so detailed code review (while certainly always appreciated!) can be postponed until the conceptual issues are resolved. Thanks, -- Aaron Ecay >From 925c6f4e920555c402be271443d167d60dff Mon Sep 17 00:00:00 2001 From: Aaron Ecay <aarone...@gmail.com> Date: Fri, 2 Sep 2016 23:30:10 +0100 Subject: [PATCH] Draft changes to org-id --- contrib/lisp/org-drill.el | 2 +- contrib/lisp/org-index.el | 18 +- etc/ORG-NEWS | 37 +++- lisp/ob-ref.el| 15 +- lisp/org-attach.el| 2 +- lisp/org-capture.el | 4 +- lisp/org-colview.el | 4 +- lisp/org-id.el| 468 +++--- lisp/org-mobile.el| 6 +- lisp/org-table.el | 2 +- lisp/org.el | 11 +- lisp/ox-html.el | 1 - lisp/ox-icalendar.el | 2 +- lisp/ox.el| 2 +- testing/org-test.el | 5 +- 15 files changed, 259 insertions(+), 320 deletions(-) diff --git a/contrib/lisp/org-drill.el b/contrib/lisp/org-drill.el index a78b806..b5ce306 100644 --- a/contrib/lisp/org-drill.el +++ b/contrib/lisp/org-drill.el @@ -2614,7 +2614,7 @@ STATUS is one of the following values: "(slow, but only happens once)")) (sit-for 0.5) (setq warned-about-id-creation t)) -(org-id-get-create) ; ensure drill entry has unique ID +(org-id-get 'create) ; ensure drill entry has unique ID (destructuring-bind (status due age)
Re: [O] org-entities.el bug in "Delta"
Hi Nicolas, 2016ko irailak 1an, Nicolas Goaziou-ek idatzi zuen: > > Hello, > > Aaron Ecay <aarone...@gmail.com> writes: > >> This is fixed in commit ab5e100 on the maint branch. Thanks for the >> report. > > Thank you for taking care of that. > > After every commit, maint needs to be merged within master so that > master is always strict superset of maint. I did that for the commit > above. Thank you for the reminder and for fixing it this time. -- Aaron Ecay
Re: [O] org-entities.el bug in "Delta"
Hi Matthew, This is fixed in commit ab5e100 on the maint branch. Thanks for the report. -- Aaron Ecay
Re: [O] org2pdf export broken on parabola
Hi Divan, Thanks for your reply. 2016ko abuztuak 28an, Divan Santana-ek idatzi zuen: > > Thanks for the reply. > > My initial post was a lacking detail, sorry... > > So, on parabola Linux, a simply org file, like this: > > QUOTE > * Test > > Testing org export to pdf via latex, on parabola Linux. > END QUOTE > > If I try export via C-c C-e l p > > results in a blank PDF. > > The *Org PDF LaTeX Output* buffer contains this: > > QUOTE > This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016/Parabola) > (preloaded format=pdflatex) > restricted \write18 enabled. > entering extended mode > (/home/admin/ownCloud/documents/org/test.tex > LaTeX2e <2016/03/31> patch level 3 > Babel <3.9r> and hyphenation patterns for 83 language(s) loaded. > (/usr/share/texmf-dist/tex/latex/base/article.cls > Document Class: article 2014/09/29 v1.4h Standard LaTeX document class > (/usr/share/texmf-dist/tex/latex/base/size11.clo)) > (/usr/share/texmf-dist/tex/latex/base/inputenc.sty > (/usr/share/texmf-dist/tex/latex/base/utf8.def > (/usr/share/texmf-dist/tex/latex/base/t1enc.dfu) > (/usr/share/texmf-dist/tex/latex/base/ot1enc.dfu) > (/usr/share/texmf-dist/tex/latex/base/omsenc.dfu))) > (/usr/share/texmf-dist/tex/latex/base/fontenc.sty > (/usr/share/texmf-dist/tex/latex/base/t1enc.def) > kpathsea: Running mktextfm ecrm1095 > mktextfm: Running mf-nowin -progname=mf \mode:=ljfour; mag:=1; nonstopmode; > input ecrm1095 > This is METAFONT, Version 2.7182818 (TeX Live 2016/Parabola) (preloaded > base=mf) > > kpathsea: Running mktexmf ecrm1095 > > ! I can't find file `ecrm1095'. > <*> ...ljfour; mag:=1; nonstopmode; input ecrm1095 [...snip the rest...] This log indicates that the problem occurs during the loading of the fontenc package. Fontenc is a good package to load, apparently: <https://tex.stackexchange.com/questions/664/why-should-i-use-usepackaget1fontenc>. You can probably fix this error by either removing the entry for the fontenc package from org-latex-default-packages-alist, or setting org-latex-compiler to either lualatex or xelatex (newer latex compilers neither of which use fontenc). Of course, either of these might uncover further problems (the parabola approach to packaging texlive seems pretty haphazard), but I believe either step would fix the problem you have reported. -- Aaron Ecay
Re: [O] Suggestion: prettify \nbsp{} as NO-BREAK SPACE
Hi Clément, I think rather that the entry for \nbsp in the ‘org-entities’ alist is incorrect: the last two elements (the Latin-1 and UTF8 equivalents) should be a non-breaking space, rather than a plain space. This would make \nbsp display as a non-breaking space in buffers and also when exporting to (UTF8) plain text. 2016ko abuztuak 28an, Clément Pit--Claudel-ek idatzi zuen: > I can provide a patch if it is useful. Thanks for the offer. I went ahead and made the change (on the master branch), since it was so simple. -- Aaron Ecay
Re: [O] org2pdf export broken on parabola
Hi Divan, 2016ko abuztuak 23an, Divan Santana-ek idatzi zuen: > > Hi All, > > So I'm pretty new to Emacs and org-mode. Loving it so far. > > On parabola (FSF approved Arch linux distro) the default emacs org2pdf > function is broken. > > Details on the reason here: > > https://lists.parabola.nu/pipermail/assist/2016-August/000716.html > > Something about freedom licensing issues I think. > > Two questions: > > 1) How can I work around this issue on parabola so I can export org 2 > pdf? > > 2) If there is an issue with the texlive fonts should org upstream not > default to a free software compatible font? So org2pdf works on FSF > approved distros? AFAIK the default org export does not do any font selection (either of free or non-free fonts). So it should work just fine. Obviously it does not for you, though. It would be helpful if you could send an example of an org document (it can be short/meaningless, as long as it demonstrates the problem), the latex it produces on export, and the latex compiler log file, so that we can see the error. Looking at that, we will probably be able to diagnose your problem more precisely, and figure out what needs to be changed to make it work. Thanks, -- Aaron Ecay
Re: [O] error in capture
Hi Eric, It’s a known bug in recent versions of org and/or emacs. No one knows exactly what triggers the problem yet, and it’s being discussed in the emacs bug tracker <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23917>. -- Aaron Ecay
Re: [O] History list for %^{...} in capture
Hi Phil,
2016ko maiatzak 20an, Phil Hudson-ek idatzi zuen:
>
> Arising from a discussion here a couple of weeks ago, I'm thinking about
> how best to add a history list to org-capture's current
> %^{prompt|default|choice2|...|choiceN} escape syntax. Here's my thinking
> so far.
[...]
>
> WDYT? Good idea? Too complex? Too "busy"? Useful? Not useful?
IMO, it’s very busy, and for a scenario that’s likely to be of use in
only a small number of circumstances. I think it would be better to
just use a %(...) construct to call an elisp function which does the
completion exactly as you desire for your own usecase.
--
Aaron Ecay
Re: [O] Bug: Write file while editing babel code block doesn't work as expected [8.3.4 (release_8.3.4-778-g8127b3 @ /usr/local/share/emacs/site-lisp/org/)]
Hi Nicolas, hi all, 2016ko maiatzak 13an, Nicolas Goaziou-ek idatzi zuen: > > Hello, > > Aaron Ecay <aarone...@gmail.com> writes: > >> Is this a correct change? Previously, C-x C-s in the org-src buffer >> would save the underlying .org file, which was useful. AFAICS this now >> would not work. > > Why do you think so ? C-x C-s is still bound to `org-edit-src-save'. You’re right – I misunderstood the change. Sorry for the noise. -- Aaron Ecay
Re: [O] Bug: Write file while editing babel code block doesn't work as expected [8.3.4 (release_8.3.4-778-g8127b3 @ /usr/local/share/emacs/site-lisp/org/)]
Hi Nicolas, 2016ko maiatzak 11an, Nicolas Goaziou-ek idatzi zuen: > I changed this in developement version. If you get any chance to test > it, Please tell me if it behaves as expected. Thank you. Is this a correct change? Previously, C-x C-s in the org-src buffer would save the underlying .org file, which was useful. AFAICS this now would not work. I also wonder whether autosave will work correctly from the org-src buffer. I think the other suggestion in this thread (to use write-region) is a better solution. -- Aaron Ecay
Re: [O] [BUG] Noweb reference eval syntax does not work
Hi Rasmus, hi all,
2016ko maiatzak 8an, Rasmus-ek idatzi zuen:
[...]
> As you mention, we’d loose the ability to chain together multiple blocks.
> I reckon they are meaningfully the same language, so I don’t see a loss.
> The example shown in the manual also does not convince me of the
> usefullness of this.
Ditto.
>
>> It is redundant with #+NAME: keyword and slightly broken. Also it
>> induces hacks like `org-babel-use-quick-and-dirty-noweb-expansion' to
>> work-around its shortcomings.
>>
>> Besides, it doesn't make much sense to add the same parameters to
>> a bunch of blocks, so I find the syntax dubious.
>>
>> I understand it can be a handy shortcut for inserting multiple blocks,
>> but, all in all, I tend to think it would be simpler to just remove the
>> feature, along with `:noweb-sep' and
>> `org-babel-use-quick-and-dirty-noweb-expansion'.
>
> I’m happy to kill it off in Org-9. I don’t know how widely the chaining
> of blocks is used, though, and whether the fix is always as simple as
> uniting the blocks.
I think that we can provide a replacement to noweb-ref as follows:
* Code blocks
:PROPERTIES:
:header-args: :noweb-ref foo
:END:
#+begin_src python
block 1
#+end_src
#+begin_src python
block 2
#+end_src
* Concat
The old way
#+begin_src python
<>
#+end_src
The new way:
#+begin_src python
<<concat-blocks-of-lang-in-headline("python","Code blocks")>>
#+end_src
concat-blocks-of-lang-in-headline would have to be an elisp source block
implementing the appropriate behavior which is present in the document
or in the library of babel.
(And I think it would be good if the LoB contained some useful
predefined blocks like this one, in addition to those added by the
user. A “standard library of babel” as it were.)
>
>> What do you, and others, think? Is NAME enough for noweb syntax, or is
>> there a real need fo :noweb-ref?
To put it another way: it seems to me that the functionality of
:noweb-ref can be reimplemented in terms of other primitives. And given
Nicolas’s comments about the complications and bugs it introduces, I’d
be in favor of deprecating and eventually removing it.
--
Aaron Ecay
Re: [O] Errors get suppressed by org-babel-execute-src-block
Hi Nick, hi Nicolas, 2016ko otsailak 20an, Nick Dokos-ek idatzi zuen: >> IMO, it looks good. You might as well push it and wait for more >> feedback, if needed. >> >> Regards, > > I did some testing as well and it seems to work. Thanks for the feedback. Pushed to master. -- Aaron Ecay
Re: [O] Help with fixing an org-mode multicolumn implementation - LaTeX special characters
Hi mcg,
2016ko otsailak 21an, mcg-ek idatzi zuen:
>
> I found a very nice implementation of LaTeX multicolumn functionality in
> this thread:
> https://lists.gnu.org/archive/html/emacs-orgmode/2013-02/msg00736.html
[...]
> However, using any of the characters of the left column of my example
> table in the merged <2colc> column, I get:
> "setq: Invalid use of `\' in replacement text"
I think the function should be written (untested):
(defun my-latex-multicolumn-filter (row backend info)
(when (org-export-derived-backend-p backend 'latex)
(while (string-match
"\\(<\\([0-9]+\\)col\\([lrc]\\)?>[[:blank:]]*\\([^&]+\\)\\)" row)
(let ((columns (string-to-number (match-string 2 row)))
(start (match-end 0))
(contents (replace-regexp-in-string "[[:blank:]]*$" ""
(match-string 4 row)))
(algn (or (match-string 3 row) "l")))
(setq row (replace-match
(format "\\multicolumn{%d}{%s}{%s}" columns algn contents)
nil t row 1))
(while (and (> columns 1) (string-match "&" row start))
(setq row (replace-match "" nil nil row))
(decf columns
row))
The change is setting the third argument (‘literal’) to ‘replace-match’
to t, and deleting an extra backslash in the "\\multicolumn..." string.
>
>
> Questions:
> - How to escape the special characters in the left column properly to be
> able to use them? (tried everything I could think of)
> or
> - How to modify the code above so that it allows for such characters.
>
> - If anyone likes the implementation and is more capable than I am, then
> the same for multirow would be really nice...
Unfortunately I think that’s more complicated, since it would necessitate
examining/modifying the whole table in one go, rather than operating one
row at a time.
--
Aaron Ecay
Re: [O] Unit test table
Hi Eduardo, 2016ko otsailak 13an, Eduardo Bellani-ek idatzi zuen: > > Hey Aaron, thanks for the input. > > I don't think that solves my problem. Look at the attached; I think it does what you’re asking for. Hope this helps, -- Aaron Ecay example.org Description: Lotus Organizer
Re: [O] Errors get suppressed by org-babel-execute-src-block
Hi Nick,
2016ko otsailak 12an, Nick Dokos-ek idatzi zuen:
>> AFAICS my patch does not affect the work Michael did. I will test some
>> simple remote execution scenarios before I push the patch, just in case.
>>
>
> OK - good!
I’ve tested, and remote execution seems to work (when tramp works for
me, which it does not do consistently – a known problem)
>
>>> BTW, I tried to test, but applying the patch to current master
>>> (8eff64cffee8627578edc33de485201ae579fafe) fails:
>>
>> Nicolas pushed some big changes to babel just after I sent my patch.
>> (Big in terms of the diff to the code, not necessarily in terms of
>> changing user behavior). I haven’t looked in detail, but it’s almost
>> guaranteed that the patch now needs to be rebased, which I’ll do as
>> soon as I can.
>
> Thanks! If you post the patch, I'll try out some simple tests over the
> weekend too.
It’s now split into two patches, attached to this message.
--
Aaron Ecay
>From 1e0f0e335bf594c6fe50581deb0775971a97f4f4 Mon Sep 17 00:00:00 2001
From: Aaron Ecay <aarone...@gmail.com>
Date: Sun, 14 Feb 2016 15:14:30 +
Subject: [PATCH 1/2] Add org-babel-make-language-alias function.
* lisp/ob-core.el (org-babel-make-language-alias): New function.
* lisp/ob-emacs-lisp.el: Use it.
Previously this was accomplished via org-src-lang-modes, but that is a
poor solution, as it conflates the remapping of language mode names with
the creation of aliases.
---
lisp/ob-core.el | 20
lisp/ob-emacs-lisp.el | 2 ++
2 files changed, 22 insertions(+)
diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index 96296e0..7bd1156 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -3152,6 +3152,26 @@ plus the parameter value."
(and (member "graphics" (cdr (assq :result-params params)))
(cdr (assq :file params
+(defun org-babel-make-language-alias (new old)
+ "Make source blocks of type NEW aliases for those of type OLD.
+
+NEW and OLD should be strings. This function should be called
+after the babel API for OLD-type source blocks is fully defined.
+
+Callers of this function will probably want to add an entry to
+`org-src-lang-modes' as well."
+ (dolist (fn '("execute" "expand-body" "prep-session"
+ "variable-assignments" "load-session"))
+(let ((sym (intern-soft (concat "org-babel-" fn ":" old
+ (when (and sym (fboundp sym))
+ (defalias (intern (concat "org-babel-" fn ":" new)) sym
+ ;; Technically we don't need a `dolist' for just one variable, but
+ ;; we keep it for symmetry/ease of future expansion.
+ (dolist (var '("default-header-args"))
+(let ((sym (intern-soft (concat "org-babel-" var ":" old
+ (when (and sym (boundp sym))
+ (defvaralias (intern (concat "org-babel-" var ":" new)) sym)
+
(provide 'ob-core)
;; Local variables:
diff --git a/lisp/ob-emacs-lisp.el b/lisp/ob-emacs-lisp.el
index 18936a6..2eb2721 100644
--- a/lisp/ob-emacs-lisp.el
+++ b/lisp/ob-emacs-lisp.el
@@ -72,6 +72,8 @@
(org-babel-pick-name (cdr (assoc :rowname-names params))
(cdr (assoc :rownames params
+(org-babel-make-language-alias "elisp" "emacs-lisp")
+
(provide 'ob-emacs-lisp)
--
2.7.1
>From c5cf453d6f0c590dd99e9f607b2897965460f33f Mon Sep 17 00:00:00 2001
From: Aaron Ecay <aarone...@gmail.com>
Date: Sun, 14 Feb 2016 15:20:39 +
Subject: [PATCH 2/2] ob-core: remove cruft
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
* lisp/ob-core.el (org-babel-execute-src-block): Simplify.
(org-babel-tramp-handle-call-process-region): Remove.
Commit 57104f9f changed an org-flet to a let, rendering the whole
apparatus of modifying call-process-region inoperative. Supposedly this
was put in place to work around a bug in
tramp-handle-call-process-region, which was removed from tramp in
2012 (after being renamed to tramp-sh-call-process-region). *shrug*
This commit just removes the whole thing.
It also no longer consults ‘org-src-lang-modes’, following on from
commit 6287416.
---
lisp/ob-core.el | 132
1 file changed, 46 insertions(+), 86 deletions(-)
diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index 7bd1156..14226bf 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -35,7 +35,6 @@
".exe"
nil))
-(defvar org-babel-call-process-region-original nil)
(defvar org-babel-library-of-babel)
(defvar org-edit-src-content-indentation)
(defvar org-src-lang-modes)
@@ -547,7 +546,6 @@ match group 9. Other match groups are defined in
(concat org-babel-name-regexp (regexp-quote name) "[ \t]*$"))
;;; functions
-(defvar cal
Re: [O] Invalid function: org-babel-header-args-safe-fn in Melpa
Hi John,
2016ko otsailak 14an, John Kitchin-ek idatzi zuen:
>
> Hi all,
>
> I am trying to debug an issue with installing org-mode from Melpa.
>
> After installing org from Melpa, I get this on starting emacs:
>
> byte-code: Invalid function: org-babel-header-args-safe-fn
> Org-mode version 8.3.3 (8.3.3-51-g30bcff-elpaplus @
> /Users/jkitchin/Desktop/jmax-git/elpa/org-plus-contrib-20160208/)
>
> It is happening when I try to change some default headers.
>
> Debugger entered--Lisp error: (invalid-function org-babel-header-args-safe-fn)
> org-babel-header-args-safe-fn((:cache :colnames :comments :exports
> :epilogue :hlines :noeval :noweb :noweb-ref :noweb-sep :padline :prologue
> :rownames :sep :session :tangle :wrap (:eval "never" "query") (:results
> lambda (str) (not (string-match "file" str))) :width :height :bg :units
> :pointsize :antialias :quality :compression :res :type :family :title :fonts
> :version :paper :encoding :pagecentre :colormodel :useDingbats :horizontal))
> byte-code("\301\302\303\304!#\210\305\306\307\310\311\312\313\314\315\316&
> \207" [ob-R-safe-header-args put org-babel-default-header-args:R
> safe-local-variable org-babel-header-args-safe-fn custom-declare-variable
> org-babel-R-command "R --slave --no-save" "Name of command to use for
> executing R code." :group org-babel :version "24.1" :type string] 10)
> require(ob-R)
> #[(pair) "A\303@!\211\203.\304\305\306P!!\202%\307\305\310
> P!!\210\307\305\311 P!!*\207" [pair lang active symbol-name require
> intern "ob-" fmakunbound "org-babel-execute:" "org-babel-expand-body:"] 5]((R
> . t))
> mapc(#[(pair) "A\303@!\211\203.\304\305\306 P!!\202%\307\305\310
> P!!\210\307\305\311 P!!*\207" [pair lang active symbol-name require
> intern "ob-" fmakunbound "org-babel-execute:" "org-babel-expand-body:"] 5]
> ((emacs-lisp . t) (python . t) (sh . t) (matlab . t) (sqlite . t) (ruby . t)
> (perl . t) (org . t) (dot . t) (plantuml . t) (R . t)))
> org-babel-do-load-languages(org-babel-load-languages ((emacs-lisp . t)
> (python . t) (sh . t) (matlab . t) (sqlite . t) (ruby . t) (perl . t) (org .
> t) (dot . t) (plantuml . t) (R . t)))
> eval-buffer(# nil
> "/Users/jkitchin/Desktop/jmax-git/jmax-org.el" nil t) ; Reading at buffer
> position 7097
>
> If I run this:
> (byte-recompile-file
> (expand-file-name "ob-R.el"
> (file-name-directory (locate-library "org")))
> t)
>
This looks like the kind of problem that results when org is byte-compiled
in an emacs with a different version of org loaded. This used to be a
problem when installing via package.el (and not just for org), but I think
there has been some work put into making sure it doesn’t happen any more.
(I know emacs developers were discussing them and then they seemed to go
away so I assumed they were fixed...it’s possible I was mistaken though.)
If I had to guess, I’d say that line 63 of packages.el in your jmax
setup defeats these fixes. Try commenting it out. It should not be
necessary to manually byte-compile packages: package.el should do that
for you. And in this case, I hypothesize that it is actually harmful.
Hope this helps,
--
Aaron Ecay
Re: [O] Errors get suppressed by org-babel-execute-src-block
Hi Nick, 2016ko otsailak 11an, Nick Dokos-ek idatzi zuen: > > Not sure if there are tests for remote babel execution, AFAIK no. It would be useful to have these. All the machines I use run Linux and are configured very similarly. Many of the problems in remote execution come from differences in environments. So it would be good if someone could figure out how to test common configurations. Until that happens, we have to rely on ad hoc testing or user reports. > but if not, please make sure to test that (with :dir set to some > directory on a different machine). Michael Albinus had done some work > to get that working a few years ago: AFAICS my patch does not affect the work Michael did. I will test some simple remote execution scenarios before I push the patch, just in case. > BTW, I tried to test, but applying the patch to current master > (8eff64cffee8627578edc33de485201ae579fafe) fails: Nicolas pushed some big changes to babel just after I sent my patch. (Big in terms of the diff to the code, not necessarily in terms of changing user behavior). I haven’t looked in detail, but it’s almost guaranteed that the patch now needs to be rebased, which I’ll do as soon as I can. -- Aaron Ecay
Re: [O] Errors get suppressed by org-babel-execute-src-block
Hi Nicolas, 2016ko otsailak 10an, Nicolas Goaziou-ek idatzi zuen: > > Hello, > > Aaron Ecay <aarone...@gmail.com> writes: > >> I’d like to install the attached patch to master, if there are no >> objections. That should resolve your concern as well as cleaning up the >> dead code. > > No objection, but... > >> +(require 'subr-x) ; For `if-let' > > ... you are not using `if-let' anywhere if this patch. Good catch. I had used it in a previous version, then refactored it away but forgot to remove the require. I’ll push the patch once I have a chance to rebase it on top of your recent babel changes. > Besides, we still cannot use subr-x, since it is a 24.4 library, and, > AFAIR, we didn't drop support for 24.3 yet. I’ll keep that in mind. Thanks, -- Aaron Ecay
Re: [O] babel question: how to detect the REPL has finished replying
Hi Alan, Other backends send an unlikely string literal to the interpreter as the last command, which will be echoed back verbatim. The code detects the presence of this string in the output stream, and thus knows that the interaction has finished. Check out the ‘org-babel-comint-with-output’ macro for the implementation. (This is the usual function of the org-babel-coq-eoe variable that your last patch deleted. It was probably cargo-culted in from another backend and never properly implemented.) Hope this is helpful, -- Aaron Ecay
Re: [O] org-capture -- optionally add time-of-day as with C-c . ?
Hi John, Using %^T seems to give the desired behavior you describe in your message. Can you try it and see if it works for you? (Regrettably, it’s not obvious from the docstring of ‘org-capture-templates’ that it should behave like that, since %T is supposed to insert a time unconditionally. But in my testing, %^T only inserts a time if one is entered by the user.) -- Aaron Ecay
Re: [O] Errors get suppressed by org-babel-execute-src-block
Hi Gary, 2016ko otsailak 8an, Gary Oberbrunner-ek idatzi zuen: > > org-babel-execute-src-block has a big unwind-protect that basically eats > all errors inside it. I don't think it used to do that. The unwind-protect exists since 2010, so you’re probably mistaken about that (depending on your frame of reference for “used to”...) That said, the code in question seems very questionable to me. First of all, the unwind-protect should not be needed at all, due to the use of (f)let (IOW, if the unwind-protect was ever needed, it was to paper over a bug in emacs which should no longer exist). Secondly, in 2012 commit 57104f9f changed an “org-flet” to a “let” in this function, which is incorrect (since elisp is a lisp-2). So the whole thing has been effectively a no-op since then. I’d like to install the attached patch to master, if there are no objections. That should resolve your concern as well as cleaning up the dead code. Aaron -- Aaron Ecay >From bdb68585d5b0ddf5a6c9876028b5f2be2f17e66a Mon Sep 17 00:00:00 2001 From: Aaron Ecay <aarone...@gmail.com> Date: Wed, 10 Feb 2016 19:39:04 + Subject: [PATCH] ob-core: remove cruft MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * lisp/ob-core.el (org-babel-execute-src-block): Simplify. (org-babel-tramp-handle-call-process-region): Remove. Commit 57104f9f changed an org-flet to a let, rendering the whole apparatus of modifying call-process-region inoperative. Supposedly this was put in place to work around a bug in tramp-handle-call-process-region, which was removed from tramp in 2012 (after being renamed tramp-sh-call-process-region). *shrug* This commit just removes the whole thing. It also no longer consults ‘org-src-lang-modes’, which is not helpful here. --- lisp/ob-core.el | 133 1 file changed, 47 insertions(+), 86 deletions(-) diff --git a/lisp/ob-core.el b/lisp/ob-core.el index 025985d..77f464f 100644 --- a/lisp/ob-core.el +++ b/lisp/ob-core.el @@ -26,6 +26,7 @@ (eval-when-compile (require 'cl)) (require 'cl-lib) +(require 'subr-x) ; For `if-let' (require 'ob-eval) (require 'org-macs) (require 'org-compat) @@ -36,10 +37,8 @@ nil)) ;; dynamically scoped for tramp -(defvar org-babel-call-process-region-original nil) (defvar org-babel-library-of-babel) (defvar org-edit-src-content-indentation) -(defvar org-src-lang-modes) (declare-function outline-show-all "outline" ()) (declare-function org-get-indentation "org" ( line)) @@ -679,72 +678,53 @@ block." (default-directory (or (and dir (file-name-as-directory (expand-file-name dir))) default-directory)) - (org-babel-call-process-region-original ;; for tramp handler - (or (org-bound-and-true-p - org-babel-call-process-region-original) - (symbol-function 'call-process-region))) (indent (nth 5 info)) - result cmd) - (unwind-protect - (let ((call-process-region - (lambda ( args) - (apply 'org-babel-tramp-handle-call-process-region -args - (let ((lang-check - (lambda (f) - (let ((f (intern (concat "org-babel-execute:" f - (when (fboundp f) f) - (setq cmd - (or (funcall lang-check lang) - (funcall lang-check - (symbol-name - (cdr (assoc lang org-src-lang-modes - (error "No org-babel-execute function for %s!" - lang - (message "executing %s code block%s..." - (capitalize lang) - (if (nth 4 info) (format " (%s)" (nth 4 info)) "")) - (if (member "none" result-params) - (progn - (funcall cmd body params) - (message "result silenced") - (setq result nil)) - (setq result - (let ((result (funcall cmd body params))) -(if (and (eq (cdr (assoc :result-type params)) - 'value) - (or (member "vector" result-params) - (member "table" result-params)) - (not (listp result))) -(list (list result)) result))) - ;; If non-empty result and :file then write to :file. - (when (cdr (assoc :file params)) - (when result - (with-temp-file (cdr (assoc :file params)) - (insert - (org-babel-format-result - result (cdr (assoc :sep (nth 2 info))) - (setq result (cdr (assoc :file params - ;; Possibly perform post process provided its appropriate. - (when (cdr (assoc :post params)) - (let ((*this* (if (cdr (assoc :file params)) - (org-babel-result-to-file - (cdr (assoc :file params)) - (when (assoc :file-desc params) - (or (cdr (assoc :file-desc params)) - result))) - result))) -
Re: [O] Unit test table
Hi Eduardo, 2016ko otsailak 4an, Eduardo Bellani-ek idatzi zuen: > > Hey guys. I've posted this question in the irc-channel, but I had to > leave before I could strike a conversation with the the nice volunteer > who answered my question. I hope that email can preserve the > conversation :) > > So, I have a table who's purpose is to demonstrate the working of different > versions of the same code, perhaps in different languages. This is a > working model: > > https://gist.github.com/ebellani/7c70d16f06076e4fc375 > > as you can see, there's repetition and the TBLFM is huge. > > Anyone has an idea of a better way to achieve similar results? Use babel: #+name: my-input | el | value | expected | |++--| | 5 | '(5 5 5 5) | 4| | ...etc... | #+begin_src elisp :var input=my-input :results table ;; Code that does the calculations in your tblfm line ;; `input' is a variable holding your input table #+end_src -- Aaron Ecay
Re: [O] Problem with threeparttable and sidewaystable, or: change request for (org-latex-tables-centered) behaviour
Hi Michael,
2016ko otsailak 5an, Michael Giepen-ek idatzi zuen:
[...]
> If the \centering would also be used for threeparttable or any
> environment, there would be no conflict at all (I think). I do not
> really understand why why the center environment is used in the first
> place: it apparently causes conflicts with several environments, but in
> effect seems to be no different from the center environment.
[ I assume you meant “no different from \centering” ]
This is because in your example the table is exported as non-floating.
\centering only works as intended inside a Latex group, which
non-floating tables are not (necessarily) contained in.
Perhaps we should use “{\centering” and “}” to center non-floating
tables – I’m not enough of a latex guru to know the pros and cons. Do
you have a reference that documents how the environment version causes
problems, or are you speaking from experience?
[...]
> and adding
>
> #+ATTR_LATEX: :center
I think this should work, except that it needs to be written:
#+ATTR_LATEX: :center t
--
Aaron Ecay
Re: [O] Subtree export problems
Hi Thomas, hi Rasmus, 2016ko otsailak 6an, Rasmus-ek idatzi zuen: [...] > I am honestly not sure if this if there’s a bug here. What seems > to happen is that it keeps looking for a value for marginnote-font > which is nil cf. above. But it could also be that your jk-org-kwd > function is simply malfunctioning cf. below. Why does this not > happen when you have plenty of newlines? I don’t know. Maybe > Aaron will be able to tell us if it’s a bug. The issue was that org-babel-get-src-block-info would infloop when #+header is the first line of the (narrowed) buffer. That should be fixed in 825ce04b on maint. I’m a bit fuzzy on the development practices these days...should I now merge maint to master in order to get the fix there as well? Or is there some other arrangement for that? Aaron PS Tom, the approach you are using to this looks rather convoluted. Instead of a src block + keyword thing, why not just use #+latex (or #+latex_header) to insert the code you need? -- Aaron Ecay
Re: [O] [ANN] Radio lists update
Hi Nicolas, 2015ko abenudak 3an, Nicolas Goaziou-ek idatzi zuen: > > Hello, > > I just pushed a patch which should make radio lists on par with radio > tables. In particular, it fixes a long standing issue with > `org-list-to-generic' which was not really usable, and thus side-stepped > in every back-end transformer (e.g. `org-list-to-latex'). > > Internally `org-list-parse-list' is obsoleted in favor of > `org-list-to-lisp' (much like `org-table-to-lisp'), which is a simpler > representation of lists. It is now easier to define programmatically > a plain list. See docstring for details. > > Feedback welcome. It looks good. Thanks for your work. -- Aaron Ecay
Re: [O] [PATCH] org-protocol: Allow key=val=value2-style URLs
Hi Sacha, Thanks for the patch. It looks great! I assume eventually we will want to deprecate the old-style links, and make new-style the only style. Unfortunately, this would mean another API change to remove the ‘new-style’ arguments from these functions. I don’t have any clever ideas to solve this, and it’s not an objection to your patch – just something I thought I’d mention in case someone can think of a way to deal with the eventual deprecation without an API change. A few comments below: 2015ko abenudak 4an, Sacha Chua-ek idatzi zuen: > From aff151930a73c22bb3fdf3ae9b442cecc08aaa67 Mon Sep 17 00:00:00 2001 > From: Sacha Chua <sa...@sachachua.com> > Date: Wed, 2 Dec 2015 10:53:07 -0500 > Subject: [PATCH] org-protocol: Allow key=val=val2-style URLs > > * lisp/org-protocol.el: Update documentation. > (org-protocol-parse-parameters): New function to simplify handling of > old- or new-style links. > (org-protocol-assign-parameters): New function to simplify handling of > old- or new-style links. You can combine these like: (org-protocol-parse-parameters, org-protocol-assign-parameters): New functions. I also think the convention in Changelogs is not to put in details, but just to say “New function” or “Accept new-style links”. A narrative explanation can be put in the git commit message below the changelog section (and will not be included in the Changelog file distributed with Emacs). But I’ll admit I don’t understand Changelog conventions and think they are a pointless relic, so YMMV. [...] > > +(defun org-protocol-parse-parameters (info new-style default-order > unhexify separator) Is there ever a case where we would want unhexify to be something other than t? Hexification is imposed by the URL format, there is no optionality about it. Handler functions get access to the raw string if they need it for some reason, I don’t think our helper functions need to bother with the unhexify != t case. Similarly, I would not have a separator argument, but use the value of ‘org-protocol-data-separator’ directly. In the rare case that a caller needs to influence the separator, they can let-bind that variable. TLDR: can we get rid of unhexify and separator arguments? [...] > (defun org-protocol-check-filename-for-protocol (fname restoffiles client) >[...docstring omitted...] >(let ((sub-protocols (append org-protocol-protocol-alist > org-protocol-protocol-alist-default))) > (catch 'fname > @@ -532,19 +604,27 @@ as filename." > (when (string-match the-protocol fname) >(dolist (prolist sub-protocols) > (let ((proto (concat the-protocol > - (regexp-quote (plist-get (cdr prolist) > :protocol)) ":/+"))) > + (regexp-quote (plist-get (cdr prolist) > :protocol)) "\\(:/+\\|\\?\\)"))) >(when (string-match proto fname) > (let* ((func (plist-get (cdr prolist) :function)) > (greedy (plist-get (cdr prolist) :greedy)) > (split (split-string fname proto)) > - (result (if greedy restoffiles (cadr split > + (result (if greedy restoffiles (cadr split))) > +(new-style (string= (match-string 1 fname) "?"))) As a way to encourage users to move to new-style links, should we add a warning if new-style = nil? Thanks again for the patch, -- Aaron Ecay
Re: [O] footnote fontify causing massive slowdown
Hi Nicolas, 2015ko abenudak 5an, Nicolas Goaziou-ek idatzi zuen: > > This is a limitation of our current way to fontify a buffer. Changing it > implies some serious work, which I'd rather spend on switching to > syntax-based (instead of regexp-based) fontification. Indeed. However, this code was needlessly slow because it failed to take advantage of short-circuit evaluation. I pushed a fix in 046310d. > > However, this report raises an interesting question about footnotes: > should we still support plain (e.g., "[1]") footnotes in Org documents? > > The pattern is very common an regularly introduces false positives. > Also, IIRC, it was introduced for non-Org buffers (e.g., in Message mode > buffers), to provide some common features with "footnote.el" library. > > I think we could remove this kind of footnotes, and yet preserve > `org-footnote-normalize' to change Org footnotes into these ones, for > foreign documents. > > WDYT? Do [1]-type footnotes present other performance problems today? I’d rather see if simple solutions to those can be effective before going for a breaking change to syntax. Then there’s the fact that syntax fontification (incl. org-elements cache) is going to have such different performance characteristics I’m not sure we can predict where the bottlenecks will be. -- Aaron Ecay
Re: [O] footnote fontify causing massive slowdown
Hi Nicolas, 2015ko abenudak 5an, Nicolas Goaziou-ek idatzi zuen: > > Hello, > > Aaron Ecay <aarone...@gmail.com> writes: > >> Indeed. However, this code was needlessly slow because it failed to >> take advantage of short-circuit evaluation. > > According to the profile report, I don't understand the logic of your > patch. > >>>> - org-footnote-in-valid-context-p 4106 44% >>>> + org-inside-LaTeX-fragment-p 2380 25% >>>> + org-in-block-p 1563 16% >>>> + org-in-verbatim-emphasis 159 1% > > ISTM that `org-in-block-p' is marginally slower (15%) than > `org-inside-LaTeX-fragment-p' (9%). I’m not sure where 15 and 9 come from. The way I read the report, org-footnote-in-valid-context-p takes 44% of the cumulative time, which is composed of org-inside-LaTeX-fragment-p (25%) + org-in-block-p (16%) + other stuff (3%). So org-inside-LaTeX-fragment-p accounts for >50% of the time spent in org-footnote-in-valid-context-p. > > Of course, in OP's report, `org-in-block-p' is the test returning early, > so pushing it earlier is faster since you don't call > `org-inside-LaTeX-fragment-p', but this is only a very specific > optimization made at the expense of other cases (and contradicts your > commit message). Am I missing something? ...no, you’re not missing anything. I looked at my patch again, and it seems completely dumb. I should not write code before finishing my morning cup of tea. I reverted in a198d81. > > I don't understand either the benefit of adding `not' calls all over the > place. I generally use de Morgan's law the other way and save a few > primcalls. > >> Do [1]-type footnotes present other performance problems today? > > The main problem of plain footnotes isn't really their performance, but > false positives'. Anytime something looks like a footnote in a buffer, > you get a performance hit. This happens much more often with plain > footnotes than with other footnote types. > > Moreover, false positives can introduce not-so-subtle problems during > export (see for example 2c66e40c). > > Note that suggesting to not use them (the default value, actually, per > `org-footnote-auto-label') doesn't help, since false positives are the > problem, not real footnotes. > > Eventually, removing them doesn't remove any feature to Org. Of course, > this is an incompatible change, and some users will need to update > documents using plain footnotes. We can provide a function for that, and > use `org-lint' to check for obsolete footnotes. The benefit is to avoid > a whole class of problems. I see. Eventually it sounds like a good idea, indeed. Maybe we should use something a bit stronger than org-lint to warn of the deprecation. What if opening a document with plain footnotes generated a warning? Thanks, -- Aaron Ecay
Re: [O] [PATCH] org-protocol: Allow optional port specification
Hi Sacha, Thanks for your patch. 2015ko abenudak 2an, Sacha Chua-ek idatzi zuen: > > I was trying to get org-protocol to work on KDE Plasma 5.4.2. I set up > my ~/.kde/share/kde4/services/org.protocol, but the standard > org-protocol sample syntax: > >org-protocol://store-link://URL/TITLE > > resulted in the error: > >Malformed URL >Port field was empty; source was "..."; scheme = "org-protocol", >host = "store-link", path = "// ..." > > Modifying my Javascript to create links of the form: > >org-protocol://store-link:0//URL/TITLE I think that the original format is an ad-hoc manipulation of the url format which tries to pack two PROTOCOL:// sequences into one string. Rather than adding a bogus port which just doubles down on this, a better solution IMO would be to make org-protocol links valid urls in another way, using the query string format: org-protocol://store-link?url=[...]=[...] This corresponds better to the url format: the protocol is org-protocol, which determines emacs shall handle this link. The location is store-link, which indicates a handler function which is an element of ‘org-protocol-protocol-alist’, and the query string gives the arguments to this function. Does that make sense? Aaron -- Aaron Ecay
Re: [O] Featur request org-table-iterate-table-subtree
Hi Charlie, 2015ko azaroak 27an, Charles Millar-ek idatzi zuen: > > Any thoughts? Any body? Well, FWIW... #+tblname’s should be unique within a document. Your problems stem from that, and your proposed solutions all work around it in some way. I can’t think of any better way to address your desired usage than the ones you listed (and would caution you that using narrowing to defeat the uniqueness assumption, while perhaps adequate for the short term, is fragile and could break at any time). -- Aaron Ecay
Re: [O] refontifying links
Hi John, 2015ko azaroak 25an, John Kitchin-ek idatzi zuen: > > Hi, > > I am trying to find a nice way to change the color of some links. So far > the only solution I have found is to create a new face, and use > highlight-regexp to do it. > > I would prefer to just use font-lock to change the color of the link. so > far I have not found a way to do that. > > I have found the org-activate-plain-links, and org-font-lock-keywords > and the org-font-lock-hook, but so far have not figured out how to > overwrite the org-link face. > > I am kind of looking for a general approach to fontifying here, but the > specific problem I want to solve is to be able to write: > > [[color:Orangered1][Some text I want colored]] and have it show in my > buffer in Orangered1. > > Any thoughts? Links are currently defined by an open function and an export function. It might be interesting if org added a third function to this set, a fontification function. OTOH we would have to consider if links are the best place to add this functionality. The work you have done on org-ref and other projects (which I greatly admire!) (ab)uses links as an analogue of HTML’s span element: a way to encapsulate and attach attributes to a sub-paragraph-sized chunk of text whose semantics are somewhat amorphous. Your example here pushes that further, using the link for pure formatting: it no longer “links” to anything at all (and thus probably should not have an associated open function nor be click-active in the buffer). I think “Spans” are something org should support, but not by co-opting links to do it. We ought to either make new syntax, or change the name of “links” to “spans” and say the former are a special case of the latter (preserving backwards compatibility of existing documents to the extent possible of course, but also doing our best to free ourselves of link-specific implementation details like percent-escaping). FWIW, HTH, Aaron PS I think if we had spans 2-3 years ago, then you would have used them to implement org-ref, and that code would already be in core. I think the same would be true of annotations, for which we’ve recently had a well-responded thread with several code contribtions, including from you IIRC. On the other hand I don’t think we want org to become like Latex, where almost all documents require a complicated web of third-party dependencies to “work” at all. It’s a delicate balance... -- Aaron Ecay
Re: [O] Error "No :file header argument given" - minor bug?
Hi Loris, It’s difficult to say without more context, but I think you might not need :results graphics on the code block that you are #+call-ing. :results graphics is intended for situations where Org should arrange for the plot to be written, whereas you have undertaken this yourself. -- Aaron Ecay
Re: [O] fixmee / syntax-ppss
Hi Jeremy, 2015ko abenudak 1an, Jeremy Hankins-ek idatzi zuen: > > I recently started using org-mode, so forgive me if this is covered > somewhere that I missed. But I'm trying to use fixmee.el with org-mode; > it works by finding "fixme" tags in comments, but it's not finding > anything in my orgmode files. I've traced the problem to the fact that > syntax-ppss fails to accurately report that it's in a comment. I would not expect this to work: because of the way that org-mode comments work, I don’t see a way for them to be fit into the syntax table machinery. Something with syntaxtic fontification (info "(elisp) Syntactic Font Lock") might be able to be put together, but to what end I’m not sure. Org mode provides built-in functionality to create “TODO” annotations (called inline tasks). These might server your purpose better than what you are trying to do with fixmee. You need to put the following line in your emacs init file: (require 'org-inlinetask) You may also want: (setq org-inlinetask-default-state "TODO") Then C-c C-x t in an org file will insert an inline task. You can get a view of the TODO headlines in a buffer (including but not limited to inlinetasks) by pressing C-c / t. (This is just the tip of the iceberg wrt listing/sorting/filtering org headlines.) -- Aaron Ecay
Re: [O] Using link abbrevations for EXPORT_FILE_NAME ?
Hi Nicolas, 2015ko azaroak 14an, Nicolas Goaziou-ek idatzi zuen: > > Thanks for your feedback. > > Any other feedback on the "EXPORT_FILE_DIRECTORY" feature? In an earlier email you wrote: > When set, e.g. to "dir", assuming EXPORT_FILE_NAME is set to "foo/file", > export file name becomes "dir/file". Would it make more sense to concatenate the properties: dir/foo/file? I’m not a user of multi-file export, but here’s the kind of scenario I imagine arising (I’ve used an abbreviated syntax for specifying properties; hopefully it’s clear): a.org , | * A project | ** One file | :EFN: foo.html | | A link to [[bar/page.html]] | | ** Another file | :EFN: bar/page.html | | Interesting content. ` b.org , | * A version of the project for mobile | :EFD: mobile | :CSS: mobile.css | | #+include: a.org ` In this case, the link will break. (Maybe the link could be made to work in org by using e.g. an ID link – but someone still might want the mobile version of bar/page.html to live at mobile/bar/page.html not mobile/page.html). Maybe you have a different kind of use-case in mind? Thanks, -- Aaron Ecay
Re: [O] [PATCH] ox-extra.el: Fix filtering of latex header blocks
Hi Sebastian, Thanks for the patch. In addition to Kyle’s comments: 2015ko urriak 9an, Sebastian Christ-ek idatzi zuen: > > Hi group, > > I'd like to provide a patch to > ox-extra.el. `org-latex-header-blocks-filter' still calls > `org-edit-src-find-region-and-lang' and raises therefore an undefined > function error. > > Best wishes, > Sebastian > > From 34b76e06bda5739e433c95b451915c8b804a1733 Mon Sep 17 00:00:00 2001 > From: Sebastian Christ <rudolfo.chr...@gmail.com> > Date: Fri, 9 Oct 2015 17:37:39 +0200 > Subject: [PATCH] ox-extra.el: Fix filtering of latex header blocks > > * ox-extra.el (org-latex-header-blocks-filter): Use `org-element' API to > find begin and end of latex header blocks. > > `org-latex-header-blocks-filter' still called > `org-edit-src-find-region-and-lang' and raised an undefined function > error because the funtion was removed from org-mode. This is fixed by > determining the > begin and end of the latex block via `org-element'. > --- > contrib/lisp/ox-extra.el | 28 > 1 file changed, 16 insertions(+), 12 deletions(-) > > diff --git a/contrib/lisp/ox-extra.el b/contrib/lisp/ox-extra.el > index e6d45cc..bb838fc 100644 > --- a/contrib/lisp/ox-extra.el > +++ b/contrib/lisp/ox-extra.el > @@ -71,18 +71,22 @@ > (org-element-property :end block) > (org-element-property :post-affiliated block))) >(mapc (lambda (pos) > - (goto-char (nth 2 pos)) > - (destructuring-bind > - (beg end ignore) > - (org-edit-src-find-region-and-lang) > - (let ((contents-lines (split-string > -(buffer-substring-no-properties beg end) > -"\n"))) > - (delete-region (nth 0 pos) (nth 1 pos)) > - (dolist (line contents-lines) > - (insert (concat "#+latex_header: " > - (replace-regexp-in-string "\\` *" "" line) > - "\n")) > + (let* ((beg (third pos)) > + (end (second pos)) > + (post-affiliated (first pos)) > + (contents-lines > + (cdr (butlast > +(split-string > + (buffer-substring-no-properties post-affiliated > + end) > + "\n") > +2 Here I think you should use (org-element-property :value X) to get the contents-lines. This means that it should be added to the list that’s constructed from :begin, :end, and :post-affiliated higher up. (And then I think :post-affiliated can be dropped from that list.) I’m not sure why I didn’t do it that way in the first place, actually. -- Aaron Ecay
Re: [O] [PATCH 7/8] ox-taskjuggler.el: allow 'priority' to be a directly-specified integer
Hi Kosyrev, 2015ko azaroak 10an, Kosyrev Serge-ek idatzi zuen: > Perhaps I was unclear in this message -- it's not the Org's priority > mechanism that is broken, it's the way ox-taskjuggler uses it that is. > > Org specifies priorities via a list of enums, whereas TJ expects an > integer in the range 0-1000. > > The quoted little piece of math in ox-taskjuggler tried to provide a > mapping, but failed and I couldn't figure out how to make it work -- > mainly because I couldn't understand how it was /supposed/ to work. Org priorities are expressed as single characters (conventionally uppercase Latin letters). These map to ASCII/Unicode code points (i.e. integers). The code interpolates these values linearly between 0 and 1000. By default org has three priorities A, B, and C; these map to 1000, 500, and 0 respectively. Five priorities A through E would map to 1000, 750, 500, 250, and 0. Etc. The letter/integer substitution is a bit opaque. So is the fact that org-lowest-priority (by default the ASCII codepoint for ‘C’ = 67) is a larger integer than org-highest-priority (ASCII ‘A’ = 65), despite what the names suggest. Does that help any? -- Aaron Ecay
Re: [O] [PATCH] ox-taskjuggler.el: allow direct 'depends' specification
Hi Kosyrev, 2015ko azaroak 10an, Kosyrev Serge-ek idatzi zuen: > > Generally speaking, TaskJuggler own "attributes" and "properties" are > very numerous. Suffice to point to the documentation: > > http://taskjuggler.org/tj3/manual/ > > Org is only able to provide a very limited amount of those, and the > approach it takes is by white-listing the properties that ought to > "pass through" from Org to TJP files. > > So, naturally, whenever one faces a limitation in ox-taskjuggler, > the desire to extend the list arises. > > I'm not sure how this relates to an average user, to be honest, > and whether I've at all helped with your question.. > > How do we proceed? The difference between a defvar and a defcustom is whether the variable shows up in M-x customize. Customize often serves as the first port of call for users discovering the features of a library. So the question is, will presenting users with such a list in the customize interface empower them to have better taskjuggler export? Or will it be too intimidating? It’s a subjective decision, I was just wondering whether you had considered it. Either way, it would be good to put the documentation link you gave into the docstring, as a pointer to the allowed values of the variable. Does that make sense? -- Aaron Ecay
Re: [O] Allowing loose ordering in Org files (Was: bug in org-habits)
Hi John, 2015ko azaroak 9an, John Wiegley-ek idatzi zuen: [...] > Lately there seems to be a push to sacrifice some of this freedom in order to > gain efficiency and regularity. I imagine this is for the benefit of machine > parsers; but what if one doesn't use any machine parsers? I don’t think it’s possible to separate things like this. Large parts of org use a machine parser, written in elisp. There are (perhaps asymptotic) plans to transition the rest of org to work based on this parser. Adding knobs to this parser increases the burden of those who have to build and maintain it. It also heightens the burden for users (especially novices): M-x customize-group org suddenly asks you one (or more) questions about details of the syntax that previously you didn’t need to consider. We have discussions about extending the syntax fairly regularly. It would be good to discuss what questions we might ask of those proposals to determine whether they should go forward. Some that I can think of are: 1. Is there a good (user-friendly, reliable) way to accomplish the same goal, given the resources currently available? 2. Is there a large community of users who need this feature and/or would adopt it if it became available? 3. Is this something that org’s “competitors” provide easily? (Not necessarily out of a spirit of competition, but rather demonstrating a use case.) I don’t include difficulty of implementation on that list. I don’t think the developers should wag the users. Unfortunately however, I don’t think your proposal fares well in light of these questions. (I don’t mean to imply that they are authoritative; anyone could very well propose others. I would be happy if a consensus developed about what the right questions are, even if there is disagreement about the answers in this specific case.) > Org never asked me to give up flexibility for unknown benefits before. > > It should be asked whether users want to trade formatting freedom for those > benefits. If it has been asked, I missed that discussion. So unless it's an > heavy maintenance burden to allow floating properties, for example, I don't > see why I, as a user, shouldn't be allowed to make that choice. I think framing it in terms of freedom is potentially misleading. Because org is free software, its users are maximally free to do any of a wide variety of things, including sticking with an old version, patching the code locally, distributing a patch/fork/set of advices, using another program, ... I think it’s more illuminating to think of it in terms of org as a tool: have the changes made it more difficult for you to accomplish your goals with org? Has something that was previously possible become impossible? Has something that was previously easy gotten harder? If the answer to one of these questions is yes, then we can think of ways to solve the difficulties. Of course, you’ve already received quite a bit of feedback about the proposal from a cross-section of the community. So what I’ve said will, I hope, function partially as a lens through which to understand that feedback, as well as a framework in which to continue discussion if it’s needed. -- Aaron Ecay
Re: [O] [PATCH 7/8] ox-taskjuggler.el: allow 'priority' to be a directly-specified integer
Hi Kosyrev, 2015ko azaroak 8an, Kosyrev Serge-ek idatzi zuen: > > * ox-taskjuggler.el (org-taskjuggler--build-task): fix priority specification > by allowing it to be directly passed down, in case it parses as an integer. > --- > contrib/lisp/ox-taskjuggler.el | 12 +--- > 1 file changed, 9 insertions(+), 3 deletions(-) > > diff --git a/contrib/lisp/ox-taskjuggler.el b/contrib/lisp/ox-taskjuggler.el > index 44ffeb6..d49db62 100644 > --- a/contrib/lisp/ox-taskjuggler.el > +++ b/contrib/lisp/ox-taskjuggler.el > @@ -875,10 +875,16 @@ a unique id will be associated to it." > (org-taskjuggler-get-end task)) >(org-element-property :PERIOD task) > (priority > - (let ((pri (org-element-property :priority task))) > + (let ((pri (org-element-property :PRIORITY task))) > (and pri > - (max 1 (/ (* 1000 (- org-lowest-priority pri)) > - (- org-lowest-priority org-highest-priority))) > +;; The exported task priority can be either specified > +;; via the Org priority mechahism (which is currently > broken), Can you say more about what breakage you mean? Is it something that can be easily fixed? Thanks, -- Aaron Ecay
Re: [O] [PATCH] ox-taskjuggler.el: allow direct 'depends' specification
Hi Kosyrev, 2015ko azaroak 8an, Kosyrev Serge-ek idatzi zuen: > > * ox-taskjuggler.el (org-taskjuggler-valid-task-attributes): add depends > to the list of valid task attributes > --- > contrib/lisp/ox-taskjuggler.el | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/contrib/lisp/ox-taskjuggler.el b/contrib/lisp/ox-taskjuggler.el > index 2bd47e6..cfb28f2 100644 > --- a/contrib/lisp/ox-taskjuggler.el > +++ b/contrib/lisp/ox-taskjuggler.el > @@ -301,7 +301,7 @@ but before any resource and task declarations." >:type '(string :tag "Preamble")) > > (defcustom org-taskjuggler-valid-task-attributes Is this an open-ended list that an average user could meaningfully add to? If not, perhaps it should be a defconst. (I don’t know anything about the taskjuggler format, so I’m sure whatever decision you make will be OK.) -- Aaron Ecay
Re: [O] visual-fill-column-mode with org
Hi Vikas, AFAIK, the visual-fill-mode features are implemented at a very low level in the display code, in C. It would be nice if it was possible to mark lines as exempt from wrapping (e.g. by putting a text property on them). Org could then arrange for tables to have this text property, and not be wrapped. But this would require changes to emacs’s C code. (I’m also not sure how it would interact with visual-fill-column-mode, which is a third-party addon.) Another option would be to use auto-fill-mode to keep your text paragraphs within your desired width, without affecting tables. -- Aaron Ecay
Re: [O] :noweb no-export and syntax highlighting upon export to html
Hi Joost, 2015ko azaroak 8an, Joost Helberg-ek idatzi zuen: > > Dear Aaron, > > I was running close to the development version, but not close > enough. It's solved now in the current version of org-mode. > > At first I accepted this odd behaviour, but then I realized htmlize is > supposed to give you what you see on screen, hence this was a bug. I’m glad the bug has disappeared (at least, that’s what I understand from your message). Thanks for the update, and do let us know if it comes back. Thanks, -- Aaron Ecay
Re: [O] Using orgstruct-mode (or just org-cycle) in emacs-lisp-mode
Hi Jonas, 2015ko azaroak 8an, Jonas Bernoulli-ek idatzi zuen: > > `outline-minor-mode' combined with `org-cycle' gives me the feature I > *really* want/need. Thorsten Jolitz wrote the outshine library to provide something like this. Sadly it’s not actively maintained ATM, but I believe it still works fine, and it may be an alternative route towards the features you are looking for. The package is on github: <https://github.com/tj64/outshine>. It’s also available through melpa. -- Aaron Ecay
Re: [O] Changes to contrib
Hi Rasmus, 2015ko azaroak 8an, Rasmus-ek idatzi zuen: [...] > > Do you have signed FSF papers? I don't know if there's any desire to move > ox-taskjuggler.el to core, nor whether it would be possible (since I don’t > know if "tj" and Baptiste have signed FSF papers). > [...] > Also, you introduce a dependency on subr-x, which may or may not be an > issue since it’s in contrib. FWIW, my impression of the way contrib is handled is that copyright assignment is not required, though it is strongly encouraged to leave open the possibility of moving a package to core. Similarly, the restrictions on emacs version support in org core do not apply. This is just what I’ve surmised from observation, thoguh. Others can speak more informatively than me. (I do like this system since it allows org-related packages to be effectively community-maintained, and different people take on their maintenance at different times, as we see here. I’d be happy if of the org-related packages on github were migrated to contrib, so that they don’t bitrot when their original authors move on. One thing that might help with that is if we could provide an ELPA repo with the individual contrib packages, though I’ve no idea how complex that task would be.) -- Aaron Ecay
Re: [O] Conditional link export?
Hi Oleh,
2015ko azaroak 8an, Oleh Krehel-ek idatzi zuen:
>
> Aaron Ecay <aarone...@gmail.com> writes:
>
>> Extra elisp inside the org file is an important way of extending the
>> power of org markup. Why don’t you want to use it?
>
> Including boilerplate Elisp, all subtly different into each markup
> document, just to extend the markup with the syntax that it should have
> in the first place anyway. Doesn't that sound bad to you?
>
> One-off Elisp inclusions relevant to a single document are great and
> powerful, but adding boilerplate code, usually more of it that the whole
> sum of the markup, doesn't sound great at all. This could be rectified
> somewhat by using `require', but then we don't have a self-contained
> document any more. Which is important to facilitate sharing and re-use
> of Org-mode documents.
I’m not sure I understand you. You’re against putting elisp into the
document, but that seems like the main thrust of your proposal. You
also want self-contained documents, but insofar as these rely on new
features being added to org, they will introduce dependencies on
specific org versions, which is an potential obstacle to sharing and
reuse.
>
>> Not in general. For small pieces of text, you can use macros.
>> Something like:
>>
>> #+macro: ifinfo (eval (if (org-export-derived-backend
>> org-export-current-backend 'info) "$1" "$2"))
>>
>> {{{ifinfo([[info:emacs#Pachages]],[[https://]])}}}
>
> The macro definition and call syntax looks very ugly.
For aesthetic considerations when editing, check out
‘org-hide-macro-markers’.
I think Nicolas gave you very thorough responses to the rest of your
proposal. Just a one more additional comment.
[...]
> 2. Something like `ox-link' isn't built-in.
Thorsten Jolitz’s org-dp library might provide you a base on which to
build such functions, if you’re motivated.
<https://github.com/tj64/org-dp>. The readme is a little dense IMO (the
docstrings are better), but you should be able to do something like:
(defun ox-link (dest)
(let* ((elements (split-string dest ":"))
(type (nth 0 elements))
(path (mapconcat #'identity (cdr elements) ":")))
(org-dp-create 'link nil nil
:type type
:path path)))
If you build a library of such functions and they prove useful, we could
put them in org-contrib and (eventually perhaps) into core.
Hope this is helpful,
--
Aaron Ecay
Re: [O] Lexical binding bug in org-list.el?
Hi Nicolas, 2015ko azaroak 8an, Nicolas Goaziou-ek idatzi zuen: [...] > Anyway, this we're really nitpicking. There's nothing fundamentally > wrong in either choice. You’re right, and I’m not trying to be quarrelsome. At least for me, it’s helpful to understand the perspective on things like this, so I can try to model what is normative guidance and what is not. Thanks for humoring me. > >>> - change `org-list-parse-list' to provide a simpler output and update >>> Babel should to use that new output. > > So the new output could be [...] details elided > > WDYT? LGTM. I’ve probably met my quota of org-related fun for the day (see below...), but implementing this in terms of elements will be my next org-list related task. > >>> - re-implement `org-list-to-subtree' using directly Elements, or even >>> string massaging. It’s obvious to me that string-massaging causes friction in parts of org’s code, so I’d like to try a different approach here. The attached patch makes a stab at doing the reimplementation in terms of elements. I think it came out rather nicely, but I’d really value hearing your opinion on it. It’s very lightly tested so far. I basically just used the following snippet as a test case: put it in an org-mode buffer, put your cursor somewhere inside the list, and M-: (org-list-to-subtree2) - foo - *bar* blorfle - [X] baz - quux - 123 > Having slept over the idea, I think we could simply update > `org-list-to-generic' to be more robust and be done with it. I can > implement it in a couple of hours (and debug it in a couple of > months...). OK. Don’t hesitate to ask if there’s some way we can help, of course. Thanks, -- Aaron Ecay >From 2c41ae7704c133086a772b8651a1c3cd67feab78 Mon Sep 17 00:00:00 2001 From: Aaron Ecay <aarone...@gmail.com> Date: Sun, 8 Nov 2015 19:37:22 + Subject: [PATCH] draft implementation of org-list-to-subtree in terms of org-element --- lisp/org-list.el | 104 +++ 1 file changed, 104 insertions(+) diff --git a/lisp/org-list.el b/lisp/org-list.el index 19d5b03..1612e4e 100644 --- a/lisp/org-list.el +++ b/lisp/org-list.el @@ -3263,6 +3263,110 @@ syntax. Return converted list as a string." (require 'ox-texinfo) (org-export-string-as list 'texinfo t)) +(defun org-list--partial-parse-contents (parse) + "Get the actual contents of a partial org-mode parse. + +Specifically, when parsing a piece of text smaller than a +headline, `org-element-parse-buffer' wraps its result with a +dummy `section' element, as well as the standard `org-data' +wrapper. This function removes these, returning a list of +org-elements. + +TODO: maybe this needs a more general name." + (org-element-contents + ;; strip the org-data element + (nth 0 (org-element-contents + ;; and the section element + parse + +(defun org-list--split-first-line (contents) + "Remove the first line of text from an org-element item. + +CONTENTS are the contents of the item org-element: at least a +paragraph followed by zero or more other elements. + +Returns a cons of the first textual line and a list of +org-elements representing the structure of the item minus this +line. + +TODO: is the first daughter of an item always a paragraph?" + (let ((graf (nth 0 contents))) +(unless (eq (org-element-type graf) 'paragraph) + (error "`org-list--split-first-line' got confused")) +(goto-char (org-element-property :begin graf)) +(let* ((eol (point-at-eol)) + (end (org-element-property :end graf)) + (first-line (buffer-substring-no-properties (point) eol))) + (if (> (1+ eol) end) + ;; One line paragraph: it becomes the entirety of the + ;; headline, and we remove it from contents + (setq contents (cdr contents)) + ;; Multi-line paragraph: narrow the buffer to lines 2-N, parse + ;; them, and set them as the contents of the paragraph. + (save-restriction + (widen) + (narrow-to-region (1+ eol) end) + (org-element-set-contents graf +(org-list--partial-parse-contents + ;; TODO: We're playing a trick on + ;; the parser here. AFAICT, the + ;; parse does not rely on the + ;; cache. But maybe we should + ;; let org-element-use-cache to + ;; nil around this call, in case + ;; that changes in the future. + (org-element-parse-buffer) + (cons first-line contents + +(defun org-list--item-to-headline (item level) + "Convert an org-element list item to a headline. + +The first line of the list item becomes the " + (unless (eq (car item) 'item) +(error "`org-list--item-to-headline' expects an item argument")) + (let* ((r (org-list--split-first-line (org-element-contents item))) + (title (car r)) + (other-contents (cdr r))) +(list 'headline + `(:level ,leve
Re: [O] [RFC] [PATCH] allow bind keywords to set safe values
Hi Nicolas, 2015ko azaroak 6an, Nicolas Goaziou-ek idatzi zuen: > > Hello, > > Aaron Ecay <aarone...@gmail.com> writes: > >> BIND keywords should be used for controlling export, rather than the >> usual emacs method of setting file local variables >> <http://mid.gmane.org/87eglcbv7g.fsf@selenimh.access.network>. > > In this message, I say that file local variables may not replace BIND > keywords (although, I still cannot remember why). > > However, BIND keywords cannot replace file local variables, because some > variables are used outside of `org-export-as'. `org-latex-compiler' > comes to mind. You are right, both are needed. Maybe org-mode (the function, i.e. the code executed when opening an org-mode file) should look for BIND keywords and set local variables according to them. Otherwise people might need the same entry in BIND and the local variables block. WDYT? (Of course, it would be even better if we could convince ourselves that local variables will work 100% of the time for export – then the use case for BIND would be restricted to setupfiles. I tried to see if I could convince myself of this, but quickly got lost.) > >> But, BIND keywords are currently disabled by default. We can’t turn >> these on by default, as maliciously crafted documents could do nasty >> things to a user’s emacs. The attached patch permits many interesting >> usages of BIND keywords by allowing them to set variables by default, >> as long as the value thus set is safe (as implemented by emacs’s >> default file local variable code). > > Sounds good. OK. I will push a patch to master with your suggestions. Thanks, -- Aaron Ecay
