Re: Eldoc and setupfile issue
Hi Jamie, I'm copying Łukasz, the author of org-eldoc.el, in case he can have a look at the issue below. Thanks, Jamie Forth writes: > Using the org-eldoc contrib, visiting a file with a setupfile keyword > seems to prevent global-eldoc-mode from enabling eldoc in org > buffers. > > Steps to reproduce: > 1. emacs -Q -l minimal.el > 2. open setup.org >- eldoc is enabled > 3. open test.org >- eldoc is not enabled > > GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.5) > Org mode version 9.2.4 (release_9.2.4-400-g2c8e8b) > > -- > Jamie > > (add-to-list 'load-path (expand-file-name "~/src/emacs/org-mode/lisp")) > (add-to-list 'load-path (expand-file-name > "~/src/emacs/org-mode/contrib/lisp")) > (require 'org-eldoc) > > # An empty file > > #+begin_src elisp :results verbatim > eldoc-mode > #+end_src > > #+RESULTS: > : t > > # A file containing a setupfile keyword. > > #+setupfile: ./setup.org > > #+begin_src elisp :results verbatim > eldoc-mode > #+end_src > > #+RESULTS: > : nil > -- Bastien
Re: A few changes to test in master
Bastien writes: > - M-x org-table-electric-header-mode RET will display the first row > of the table at point in the header line when the first row is not > visible anymore. This is great, it's a huge quality-of-life improvement for working with long tables. Below are some issues I noticed when playing with it. Major issues: The variable `org-table-header-line-p' doesn't seem to have any effect for me, I find that I need to call "M-x org-table-header-line-mode" even when it's set. Also, "M-x org-table-header-line-mode" seems to activate the minor mode globally, despite a message suggesting it is only activated in the current buffer. Maybe because we use "defvar" instead of "defvar-local" to define its variable? I tried replacing the "defvar" with "defvar-local", it seemed to fix the global activation of the minor mode, but still it seems the hooks added are still active in other org buffers. So if I activate the mode in buffer A, then view a long table in buffer B, I see the table header when scrolling through it, even though the mode isn't active in B. Minor issues: If I am in a table, and scroll-up-command brings me out of the table, then the header of the table still sits on top of the window immediately after scrolling. This gets fixed as soon as any action is taken (e.g. moving the cursor or hitting C-g). It would be nice if the header row was a little more visually distinguishable from the other table rows (maybe by adding an underline to that row?) Feature request (for Org 9.5?): It would be great if an analogous feature could be added for the left-most column of a table, so if a table is very wide, and I scroll to the right, I could still see which row index I'm in.
Re: org-mode functional programming library
Nicolas Goaziou writes: > Note that, at some point, Org will support "seq.el", i.e., when we > drop support for Emacs 24. Just a small FYI about seq.el, for those who may not be aware: while it's a very useful library, it can be quite slow since it uses generics. For example, here are some benchmarks comparing seq-intersection with other functions that intersect lists: https://gist.github.com/alphapapa/36b117c178dec677258f372c3a01d8b5 Note the last benchmark listed, which shows that cl-intersection is about 2x as fast as seq-intersection. As well, dash.el's -intersection is about 17x faster than seq-intersection. So while seq.el will undoubtedly be useful in Org, it should be used carefully with regard to performance. Type-specific functions will generally be much faster. And as long as dash.el can't be used in Org proper, a custom implementation may be called for at times.
babel latex headers and image generation commands
I spent some time today trying to get latex babel source blocks to work
for me and discovered that calling `org-babel-execute:latex` ignores the
:headers header if the output file is a png without setting imagemagick
to t. It's easy to see this in the source code: the conditions mentioned
above leads to calling org-create-formula-image without passing in the
headers. I think this is a bug, although maybe I missed it somewhere in
the documentation? Here's a MWE if you want it
#+header: :file "test.png"
#+header: :headers '("\\def\\hello{hello}")
#+begin_src latex :results output file link
\hello
#+end_src
doesn't work, but
#+header: :file "test.png"
#+header: :imagemagick t
#+header: :headers '("\\def\\hello{hello}")
#+begin_src latex :results output file link
\hello
#+end_src
does.
However, this got me thinking that I wish executing latex blocks behaved
a bit more like latex fragment previews. Particularly, the ability to
customize `image-converter`. So, I'm thinking about adding a
customization option that allows a user to use the image-converter
portion of an existing org-preview-latex-process-alist entry (I guess
the most obvious choice would be
org-preview-latex-default-process). Although I guess I could just add a
new variable like what we have with org-latex-pdf-process. Maybe that's
better since we'd only be using one part of the
latex-process-alist. What are people's thoughts on this?
Re: Prose with markup needs more line spacing [legibility 5/6]
Texas Cyberthal writes: > Code requires less line spacing. It has more whitespace, fewer capital > letters, and no markup such as underlining. Code is read differently > than prose; it requires less sequential scanning. Code certainly can have markup like underlining. For example, flymake/flycheck highlighting, highlight-function-calls-mode, Semantic, etc. > Prose has big blocks of text with taller capital letters that must be > scanned sequentially. The tall bits bump into lines above and below. > Org prose adds markup. Underlining and all-caps tags are common. This > requires a bit more line spacing for optimal legibility: > > #+begin_src elisp > ;; prose with markup needs more line spacing > (defun leo-space-lines () > (setq line-spacing 0.175)) > (add-hook 'org-mode-hook 'leo-space-lines) > #+end_src We should definitely not be messing with line spacing in default settings. Line spacing is a very personal preference, and it varies widely by other configuration, such as font. Please, feel free to make your own prose-specific Org theme or minor mode, or use or improve one of the several that already exist. Org defaults need not be changed to meet your preferences.
Re: Fixed vs variable pitch font [legibility 4/6]
Texas Cyberthal writes: > Readable prose requires variable-pitch font. Readable code requires > fixed-pitch font. Org should make it easy to configure the two > separately. > > mixed-pitch-mode mostly solves this problem, but only advanced users > know about it. > https://gitlab.com/jabranham/mixed-pitch I also prefer proportional fonts for prose in Org buffers, and I configured my face settings accordingly a long time ago. However, it is not necessarily so that proportional fonts are required for prose. Great works have been written on typewriters for many years. As well, Emacs/Org are not necessarily aimed at prose writing more than other uses, and changing the default would probably be off-putting to many existing users, so the default probably should not be changed. Having said that, if Org could have a simple org-mixed-pitch-mode, or something like that, that could be very helpful, since it could make such configuration much easier. Maybe one could be written to use face-remapping, which shouldn't take much code.
Re: How to set time limit and memory limit for execution of source blocks
This is probably something which would need to be addressed in the interpreter/compiler of the language you are using rather than within Emacs or org-mode. I would suspect that in your case, you are best off tangling the source blocks to create separate executable scripts/code which you then run outside of Emacs itself. Running the code blocks from within org-mode/Emacs is going to adversely impact on the execution time (it will be slower) and complicates/muddies calculation of memory usage (you really only want to count the memory used by the child process running your code, not that of Emacs). Using tangled source code files will also allow you to use OS tools for timing and memory metrics (depending on what platform your on). If your source code blocks are emacs-lisp, things are a little different. There will still be some overhead which may impact on performance. I don't think you can easily identify memory useage (i.e. memory used by your source code as opposed to memory used by Emacs for everything else). Anoop GR writes: > Dear Emacs hackers, > > Like all of you, I think orgmode is the best way to organise study notes. > > I am solving competitive programming questions from Topcoder.com > There are strict guidelines on memory limit of 256MB and time limit of 2sec > for solutions > > How do I enforce the same on my orgmode source blocks. > I want the execution to stop whenever it exceeds the above limits on memory > and time. > > Long live Emacs, > Anoop -- Tim Cross
Re: org-adapt-indentation default should be nil [legibility 3/6]
Texas Cyberthal writes: > #+begin_src elisp > (org-adapt-indentation nil) > #+end_src > > Adaptive indentation makes sense when using Org as a plain-text > database. It does not make sense when using Org for longform prose. > > In the former case, outline depth is important to reflect properties > such as inheritance. The code elements are primary and the prose > secondary. > > In the latter case, the primary payload is the prose. Gratuitously > indenting it wastes screen space and requires the user to make layout > adjustments for legibility. The extra information value of indentation > reflecting outline depth is negligible; the heading already conveys > it. > > Beginners are bad at making adjustments to keep heavily-indented prose > legible. Thus the default should be nil. I think you have a better case for changing this setting. However, I think there is another consideration: the default settings do not put blank lines between headings and their entry text, and without any indentation, headings and entry text on varying levels tends to blend together, making for very poor readability. Disabling this setting would make this problem worse. Generally, I don't think "beginners are bad at" is a good argument for changing defaults. No one is "good at" Emacs and Org when they first come to it. There's probably room for improving the defaults, but we should not necessarily make changes based on guessing what brand-new users are most likely to want. Emacs and Org are, thankfully, generally free from the trend of aiming software at those who have never used it before. Instead, it tends to call users to learn more and aspire to mastery, which is more useful and empowering in the long run.
Re: org-startup-truncated default should be nil [legibility 2/6]
Texas Cyberthal writes: > #+begin_src elisp > (org-startup-truncated nil) > #+end_src > > Line truncation is necessary for code but anathema for prose. Prose > lines need visual wrap as windows resize, so that texts can be > compared easily. > > Advanced Org uses such as large tables require line truncation. Tables > are a code-like fixed-pitch feature. > > Users will write a paragraph of prose longer than the screen well > before they discover a need for line truncation, such as long lines of > code or wide tables. Users who need line truncation are likely to know > about it, whereas users who need line truncation off are unlikely to > know what it's called. > > Learning about line truncation is an unnecessary hurdle for beginners. > Therefore the default should be nil. visual-line-mode and toggle-truncate-lines are basic Emacs commands that all users should learn early. As well, many users prefer to use filled paragraphs rather than visual wrapping. And we shouldn't prioritize prose above other uses. So this default should probably not be changed. What would be useful would be if Emacs/Org could be configured to wrap prose lines but not, e.g. tables and code blocks. I don't think such functionality exists in Emacs now, but here's a new package that may be relevant: https://github.com/luisgerhorst/virtual-auto-fill As well, it might be good to discuss on emacs-devel whether a feature could be developed to truncate/wrap lines selectively; maybe font-locking could be used to apply text properties to disable wrapping dynamically (assuming that a feature could be developed to wrap based on a certain text property). Then we could have the best of both worlds, and solve an existing problem, viz. that tables and code gets wrapped when visual-line-mode is enabled.
Re: Defaults for noobs, dotfiles for vets [legibility 1/6]
Texas Cyberthal writes: > Beginners spend a while learning to use Emacs as a simple text editor > before they're able to do anything more advanced. Their ability to > intelligently customize is minimal. Meanwhile experts have automated > dotfile deployment, so defaults are almost irrelevant to them. > Therefore defaults should be set for inexperienced users. Defaults are relevant for all users, because if you change the default of a setting that an "experienced user" uses the default for, he will have to change that setting in his config. New users come to Emacs/Org a few at a time; changing the defaults would affect all existing users at once. Therefore changing the defaults should be very carefully considered, and they should not reflect one user's beliefs about what best suits other users. > Inexperienced users will mostly use Org for longform prose, since they > haven't learned its database functions yet. Since Org aspires to be a > personal info manager, it should prioritize prose presentation above > code conventions. Org is not intended more for prose writing than for other uses. We should not prioritize one such use above others. > Concerns about terminal impact appear to be moot, since terminal > ignores most font settings. Terminals can display colors, underlines, italics, and bold text, and terminal appearance should not be ignored or de-prioritized.
How to set time limit and memory limit for execution of source blocks
Dear Emacs hackers, Like all of you, I think orgmode is the best way to organise study notes. I am solving competitive programming questions from Topcoder.com There are strict guidelines on memory limit of 256MB and time limit of 2sec for solutions How do I enforce the same on my orgmode source blocks. I want the execution to stop whenever it exceeds the above limits on memory and time. Long live Emacs, Anoop
Re: Bug: org-indent-region doesn't restore cursor position when org-src-tab-acts-natively is t [9.1.9 (release_9.1.9-65-g5e4542 @ /usr/share/emacs/26.3/lisp/org/)]
Hi, Thank you for your reply. I can still reproduce with latest Org: what I did was start emacs with emacs -q --load empty_init.el, with empty_init.el setting the org package-archive to http://orgmode.org/elpa/, update org to 9.3.2 then proceed with the previous steps. The result is the same. I'd be happy to provide any additional info. Hi Sébastien, I cannot reproduce this bug with latest Org version. If you can, please test with the latest Org version and report any problem. Thanks,
Re: A few changes to test in master
Bastien, the latest on the table header. With emacs -Q and org from a few minutes ago, I get the following: [screendump-20200204064315.png] when I open the file, invoke M-x org-table-header-line-mode RET and scroll down in the attached org file. Note also that if I invoke the above command before opening an org file, org complains (correctly) about the command not being suitable outside org but then, when I open the attached file and invoke the command again, I get: org-table-header-line-mode: Symbol’s function definition is void: face-remap-remove-relative Thank you. eric PS -signature out of date in this case. org up to date from 5 minutes ago now. – Eric S Fraga via Emacs 28.0.50, Org release9.3.2-198-g06d36e * Long table #+startup: shrink | name | cost | description| | | <6> | <20> | |--+--+| | an entry |1 | this is a very long description of the item we wish to buy | | an entry |2 | this is a very long description of the item we wish to buy | | an entry |3 | this is a very long description of the item we wish to buy | | an entry |4 | this is a very long description of the item we wish to buy | | an entry |5 | this is a very long description of the item we wish to buy | | an entry |6 | this is a very long description of the item we wish to buy | | an entry |7 | this is a very long description of the item we wish to buy | | an entry |8 | this is a very long description of the item we wish to buy | | an entry |9 | this is a very long description of the item we wish to buy | | an entry | 10 | this is a very long description of the item we wish to buy | | an entry | 11 | this is a very long description of the item we wish to buy | | an entry | 12 | this is a very long description of the item we wish to buy | | an entry | 13 | this is a very long description of the item we wish to buy | | an entry | 14 | this is a very long description of the item we wish to buy | | an entry | 15 | this is a very long description of the item we wish to buy | | an entry | 16 | this is a very long description of the item we wish to buy | | an entry | 17 | this is a very long description of the item we wish to buy | | an entry | 18 | this is a very long description of the item we wish to buy | | an entry | 19 | this is a very long description of the item we wish to buy | | an entry | 20 | this is a very long description of the item we wish to buy | | an entry | 21 | this is a very long description of the item we wish to buy | | an entry | 22 | this is a very long description of the item we wish to buy | | an entry | 23 | this is a very long description of the item we wish to buy | | an entry | 24 | this is a very long description of the item we wish to buy | | an entry | 25 | this is a very long description of the item we wish to buy | | an entry | 26 | this is a very long description of the item we wish to buy | | an entry | 27 | this is a very long description of the item we wish to buy | | an entry | 28 | this is a very long description of the item we wish to buy | | an entry | 29 | this is a very long description of the item we wish to buy | | an entry | 30 | this is a very long description of the item we wish to buy | | an entry | 31 | this is a very long description of the item we wish to buy | | an entry | 32 | this is a very long description of the item we wish to buy | | an entry | 33 | this is a very long description of the item we wish to buy | | an entry | 34 | this is a very long description of the item we wish to buy | | an entry | 35 | this is a very long description of the item we wish to buy | | an entry | 36 | this is a very long description of the item we wish to buy | | an entry | 37 | this is a very long description of the item we wish to buy | | an entry | 38 | this is a very long description of the item we wish to buy | | an entry | 39 | this is a very long description of the item we wish to buy | | an entry | 40 | this is a very long description of the item we wish to buy | | an entry | 41 | this is a very long description of the item we wish to buy | | an entry | 42 | this is a very long description of the item we wish to buy | | an entry | 43 | this is a very long description of the item we wish to buy | | an entry | 44 | this is a very long description of the item we wish to buy | | an entry | 45 | this is a very long description of the item we wish to buy | | an entry | 46 | this is a very long description of the item we wish to buy | | an entry | 47 | this is a very long description of the item we wish to buy | | an entry | 48 | this is a very long description of the item we wish to buy | | an entry | 49 | this is a very long description of the item we wish to buy | | an entry | 50 |
Re: Make code elements in prose unobtrusive [legibility 6/6]
As Tim said, this is really a matter for theming. There are several themes and example configs available that make Org buffers "pretty". For example: https://github.com/kunalb/poet https://github.com/jonnay/org-beautify-theme https://lepisma.xyz/2017/10/28/ricing-org-mode/ As well, faces are easy to customize using: M-x customize-apropos-faces RET org RET There may be improvements to be made, but the defaults shouldn't be set to match the preferences of any one user. Remember that people have been using Org for years, and theming and faces are very personal. ;)
Re: org-babel-load-file support elisp
Well there are exceptions to all rules aren't there? Yes, strictly speaking, for shell scripts, only 'sh' fits with the -mode rule. However, that mode is also slightly different from other language modes in that it supports many shell 'dialects'. The thing is, the more 'liberal' we are with what we allow as the name of the source block language, the more complex any additional functionality becomes - I think your original issue is an example of this. Allowing 'elisp' seem reasonable, but then other functions which work with source blocks now also need to know that 'elisp' is an alias for 'emacs-lisp'. There are probably other inconsistencies which will 'fail' in some situations. For example, I wonder about 'javascript' and 'js2'. Jack Kamm writes: > Tim Cross writes: > >> All other language specifiers comply to the pattern of source block >> languages being the language major mode name without the '-mode', but >> there is no elisp-mode. > > Sorry to be pedantic, but I think shell source blocks are another > exception here. They can use various synonyms for the source language, > such as "shell", "sh", or any other name in org-babel-shell-names. Also, > while "shell-mode" is a major-mode, it is not the mode used by the > source buffer -- it is the mode used for the interactive shell created > by the `shell' command. -- Tim Cross
Re: org-babel-load-file support elisp
Tim Cross writes: > All other language specifiers comply to the pattern of source block > languages being the language major mode name without the '-mode', but > there is no elisp-mode. Sorry to be pedantic, but I think shell source blocks are another exception here. They can use various synonyms for the source language, such as "shell", "sh", or any other name in org-babel-shell-names. Also, while "shell-mode" is a major-mode, it is not the mode used by the source buffer -- it is the mode used for the interactive shell created by the `shell' command.
Re: [PATCH] Fix several issues with python session value blocks
Kyle Meyer writes: >> I'd like to do the honors of making my first push to the repo :) So >> please let me know if you're fine with me to proceed. > All good from my end :> Thanks -- I've pushed to master :D
Re: Make code elements in prose unobtrusive [legibility 6/6]
It strikes me that much of what seems to be required for 'legible' org would possibly be handled by an org 'theme'. As it is possible to combine themes, it should be possible to create a 'org pros theme', which users could add to their existing theme. This theme could adjust face sizes, colours, fonts etc. For things which cannot be modified using a theme, we could define profiles e.g. a pros profile and a coding profile. Provided these are adequately documented, new users will be able to try them out. Changing defaults is far more problematic as it has the potential to impact a large number of existing users who have their environment configured the way they like already. In this day and age of cut and paste, pre-configured setups and stack overflow solutions, we cannot assume that these users are advanced enough to 'fix' or restore their setup when defaults change. I also think it important to not consider this to be a simple pros v code use case. Personally, while I do use org to write pros quite often, my main use of org is for organisation of information, tracking tasks, planning and notes. In the majority of my workflows, a lot of that 'code' information is important and not something I would want hidden or de-emphasised all the time. Rather than changing defaults, what I think is really needed is something along the 'profile' lines - a way to reliably switch to a pros profile when I'm writing pros and switch out to a 'standard' profile when not. Texas Cyberthal writes: > Org intersperses bits of code in prose, such as datestamps, drawers, > keywords, etc. The code distracts when reading the prose. The solution > is to make the code less prominent. > > That way it's easy to read the paragraphs of prose without > interruption. If one wants to focus on a code bit, it's still easily > readable. Prose needs to be larger to be human-scannable, but the code > bits aren't in paragraphs, so they can be smaller. Code only needs to > be readable when the eye is centered on it, whereas a prose paragraph > must be read with multiple saccades. > > Org should provide a way to make all the code bits smaller with one settings: > > #+begin_src elisp > (custom-set-faces > ;; custom-set-faces was added by Custom. > ;; If you edit it by hand, you could mess it up, so be careful. > ;; Your init file should contain only one such instance. > ;; If there is more than one, they won't work right. > '(org-date ((t (:foreground "#7590db" :underline t :height 0.8 :width > normal > '(org-drawer ((t (:foreground "LightSkyBlue" :height 0.7 :width condensed > '(org-special-keyword ((t (:foreground "#bc6ec5" :height 0.7 :width > condensed) > #+end_src -- Tim Cross
Re: org-mode functional programming library
Hello Nicolas, thank you for the reply > Note that code going into Org proper cannot rely on external libraries, > e.g., "s.el" or "dash.el". So it may make sense to integrate it, but not > in its current form. Is it possible to write it without these libraries, > and without re-inventing the wheel? Note that, at some point, Org will > support "seq.el", i.e., when we drop support for Emacs 24. It would be possible but would obviously require some work but would be doable. I will say that there's a macro I am hoping to add to dash that implements and simultaneously (impossible with 'cl-defun') so if this package doesn't depend on dash that might be reinventing the wheel (assuming it gets in). > Skimming through your code, I read a lot of griefs against Element > library (inconvenient, unfortunate, buggy, inconsistent... I stopped > there). I agree on most points, of course. Though, there are a few cases > where you seem to miss the point. Also, the way you handle plain lists > is not how it is done in Org. Anyway, it could be beneficial for both > Org and your library to discuss the points above and improve the parser. > WDYT? My apologies if this came across as rude; I can be quite blunt in my comments. Anyways, I would definitely like to discuss further how we can improve both. Do you mind elaborating on how plain-lists are handled differently between Org and this library. Also, just so we are on the same page, where do I seem to miss the point? > I didn't check, but how do you alter the buffer when applying changes to > the parse tree? Is it optimized, e.g., only changed lines are replaced? > Or are you deleting the whole thing and replacing it with the > interpreted stuff? Note that Org has hardly ever access to the full > parse-tree, because parsing a whole buffer is too slow. So, because of > these limitations, I wonder if your library can be used efficiently to > alter the buffer. This is actually a place where I would like feedback. The function you are probably looking for is 'om-update' (and related) which parses all/part of the buffer to a parse tree, transforms it in some way, then writes it back. There is also 'om-insert' which just inserts a parse tree created from scratch. I wouldn't call it optimized, but I designed the update functions to parse as little as possible to only get the relevant parse tree. Eg if you only care about one headline, there is the function 'om-update-headline' which parses only within the boundaries of that headline. That being said, the limitations of this are that it doesn't get the :parent property (unless you actually parse the parent as well) and it replaces the entire parse tree (as opposed to only replacing the lines that are changed) which automatically deletes the overlays that allow folding. To deal with the latter I have 'om-fold' and 'om-unfold' but these aren't the most convenient and it would be much easier all-around if the write-back operation only replaced what changed (currently on my todo list). I also wonder if there is a way to control what is being parsed, as some elements can be fully represented with only a subset of their properties. From: Nicolas Goaziou Sent: 2020-02-01T08:53:43-0500 To: Dwarshuis, Nathan J Subject: org-mode functional programming library Hello, "Dwarshuis, Nathan J" writes: > I recently authored an package called "om.el" which is a functional > org-mode API akin to dash.el primarily using org-element. Briefly, it > provides a library of (mostly) pure functions that manipulate the > parse tree generated by org-element.el, and uses this to either edit > or query the buffer with all the advantages of functional programming > (eg lack of side effects, referential transparency, easier testing, > etc). The github repo for om.el is here: > https://github.com/ndwarshuis/om.el. > > I'm posting to the mailing list a) for general feedback on this > package and b) because I am wondering if this would be a good package > to include with org-mode itself rather than in another repository such > as MELPA. The code for om.el is tightly integrated with org-element.el > and it might make sense for development between these to be closely > intertwined. Thank you for this thorough work. Note that code going into Org proper cannot rely on external libraries, e.g., "s.el" or "dash.el". So it may make sense to integrate it, but not in its current form. Is it possible to write it without these libraries, and without re-inventing the wheel? Note that, at some point, Org will support "seq.el", i.e., when we drop support for Emacs 24. Skimming through your code, I read a lot of griefs against Element library (inconvenient, unfortunate, buggy, inconsistent... I stopped there). I agree on most points, of course. Though, there are a few cases where you seem to miss the point. Also, the way you handle plain lists is not how it is done in Org. Anyway, it could be beneficial for both
Make code elements in prose unobtrusive [legibility 6/6]
Org intersperses bits of code in prose, such as datestamps, drawers, keywords, etc. The code distracts when reading the prose. The solution is to make the code less prominent. That way it's easy to read the paragraphs of prose without interruption. If one wants to focus on a code bit, it's still easily readable. Prose needs to be larger to be human-scannable, but the code bits aren't in paragraphs, so they can be smaller. Code only needs to be readable when the eye is centered on it, whereas a prose paragraph must be read with multiple saccades. Org should provide a way to make all the code bits smaller with one settings: #+begin_src elisp (custom-set-faces ;; custom-set-faces was added by Custom. ;; If you edit it by hand, you could mess it up, so be careful. ;; Your init file should contain only one such instance. ;; If there is more than one, they won't work right. '(org-date ((t (:foreground "#7590db" :underline t :height 0.8 :width normal '(org-drawer ((t (:foreground "LightSkyBlue" :height 0.7 :width condensed '(org-special-keyword ((t (:foreground "#bc6ec5" :height 0.7 :width condensed) #+end_src
Prose with markup needs more line spacing [legibility 5/6]
Code requires less line spacing. It has more whitespace, fewer capital letters, and no markup such as underlining. Code is read differently than prose; it requires less sequential scanning. Prose has big blocks of text with taller capital letters that must be scanned sequentially. The tall bits bump into lines above and below. Org prose adds markup. Underlining and all-caps tags are common. This requires a bit more line spacing for optimal legibility: #+begin_src elisp ;; prose with markup needs more line spacing (defun leo-space-lines () (setq line-spacing 0.175)) (add-hook 'org-mode-hook 'leo-space-lines) #+end_src
Fixed vs variable pitch font [legibility 4/6]
Readable prose requires variable-pitch font. Readable code requires fixed-pitch font. Org should make it easy to configure the two separately. mixed-pitch-mode mostly solves this problem, but only advanced users know about it. https://gitlab.com/jabranham/mixed-pitch
org-startup-truncated default should be nil [legibility 2/6]
#+begin_src elisp (org-startup-truncated nil) #+end_src Line truncation is necessary for code but anathema for prose. Prose lines need visual wrap as windows resize, so that texts can be compared easily. Advanced Org uses such as large tables require line truncation. Tables are a code-like fixed-pitch feature. Users will write a paragraph of prose longer than the screen well before they discover a need for line truncation, such as long lines of code or wide tables. Users who need line truncation are likely to know about it, whereas users who need line truncation off are unlikely to know what it's called. Learning about line truncation is an unnecessary hurdle for beginners. Therefore the default should be nil.
org-adapt-indentation default should be nil [legibility 3/6]
#+begin_src elisp (org-adapt-indentation nil) #+end_src Adaptive indentation makes sense when using Org as a plain-text database. It does not make sense when using Org for longform prose. In the former case, outline depth is important to reflect properties such as inheritance. The code elements are primary and the prose secondary. In the latter case, the primary payload is the prose. Gratuitously indenting it wastes screen space and requires the user to make layout adjustments for legibility. The extra information value of indentation reflecting outline depth is negligible; the heading already conveys it. Beginners are bad at making adjustments to keep heavily-indented prose legible. Thus the default should be nil.
Defaults for noobs, dotfiles for vets [legibility 1/6]
Beginners spend a while learning to use Emacs as a simple text editor before they're able to do anything more advanced. Their ability to intelligently customize is minimal. Meanwhile experts have automated dotfile deployment, so defaults are almost irrelevant to them. Therefore defaults should be set for inexperienced users. Inexperienced users will mostly use Org for longform prose, since they haven't learned its database functions yet. Since Org aspires to be a personal info manager, it should prioritize prose presentation above code conventions. Concerns about terminal impact appear to be moot, since terminal ignores most font settings.
Re: [PATCH] Fix several issues with python session value blocks
Jack Kamm writes: > Hi Kyle, > > Thanks for the thorough review as always. An updated patch incorporating > your feedback is at the end of this email. Thanks for the updates. > I'd like to do the honors of making my first push to the repo :) So > please let me know if you're fine with me to proceed. All good from my end :>
Re: [PATCH] Fix several issues with python session value blocks
Hi Kyle,
Thanks for the thorough review as always. An updated patch incorporating
your feedback is at the end of this email.
I'd like to do the honors of making my first push to the repo :) So
please let me know if you're fine with me to proceed. Or, if you have
more comments, they are always appreciated.
Kyle Meyer writes:
> Tangent: You can get better context for your diffs if you define a
> custom xfuncname.
Thanks for the tip!
>> +with open('%s') as f:
>
> Hmm, I'm nervous about breakage here if org-babel-temp-file returns
> something with a single quote. However, that's already a problem with
> org-babel-python--exec-tmpfile used for ":results output", as well as
> with a couple of other spots, so I think it'd be okay to punt on that
> for now.
Thanks for pointing this out, I've noted it and will try to fix it in
future.
> Hmm, we set the result to the exception on error, so the exception will
> now show up under "#+RESULTS:". As a not-really-babel user, my guess is
> that that'd be a good thing, but I do wonder how other languages handle
> exceptions.
I'm most familiar with R, Julia, and shell so I checked how those
languages deal with errors when ":session :results value". In general,
they print an empty "#+RESULTS:" element, with the exception of Julia
which hangs Emacs.
So, printing an empty results block would be the more consistent
behavior here. This can be achieved by setting __org_babel_python_final
to the empty string in the exception clause.
On the other hand, I do think that printing the traceback is useful
behavior. For now, I've opted to keep the traceback output, because
we've already written it, and it's easy to remove later if we want. But
I don't have a strong opinion here.
> I've included a patch at the end that sits on top of yours and does
> those two things. If it looks reasonable to you, please squash it into
> your patch.
Looks good, I've squashed it in, however I did add back a call to
"raise" in the exception block, so that the error would appear in the
REPL (which was the general behavior for shell, R, and Julia errors).
>From 572ca9fd8c89720acd8d7d2ace8bb3c0be3d288e Mon Sep 17 00:00:00 2001
From: Jack Kamm
Date: Mon, 20 Jan 2020 17:40:22 -0800
Subject: [PATCH] ob-python: Fix several issues with :session :results value
* lisp/ob-python.el (org-babel-python-evaluate-session): Fix a few
related issues with :session :results value blocks, including broken
if-else statements, indented blocks with blank lines, and returning
the wrong value when underscore has been used.
(org-babel-python--eval-ast): New constant variable, a string
consisting of Python code to execute a source block using ast.
Previously, python blocks with parameters ":session :results value"
were entered line-by-line into the Python session, which could cause
issues around indentation and new lines. Now, such python blocks are
written to temp files, then the built-in ast python module is used to
parse and execute them, and to extract the last line separately to
return as a result. Introduces a change in behavior, requiring that
the last line must be a top-level expression statement if its result
is to be saved (otherwise, the result is None).
---
etc/ORG-NEWS | 9 +
lisp/ob-python.el | 68 --
testing/lisp/test-ob-python.el | 35 +
3 files changed, 85 insertions(+), 27 deletions(-)
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 6518c318d..2068b3aab 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -11,6 +11,15 @@ See the end of the file for license conditions.
Please send Org bug reports to mailto:emacs-orgmode@gnu.org.
* Version 9.4 (not yet released)
+** Incompatible changes
+*** Python session return values must be top-level expression statements
+
+Python blocks with ~:session :results value~ header arguments now only
+return a value if the last line is a top-level expression statement,
+otherwise the result is None. Also, None will now show up under
+"#+RESULTS:", as it already did with ~:results value~ for non-session
+blocks.
+
** New features
*** Numeric priorities are now allowed (up to 65)
diff --git a/lisp/ob-python.el b/lisp/ob-python.el
index 823f6e63d..5f71577cb 100644
--- a/lisp/ob-python.el
+++ b/lisp/ob-python.el
@@ -247,6 +247,25 @@ open('%s', 'w').write( pprint.pformat(main()) )")
")); "
"__org_babel_python_fh.close()"))
+(defconst org-babel-python--eval-ast "\
+import ast
+try:
+with open('%s') as f:
+__org_babel_python_ast = ast.parse(f.read())
+__org_babel_python_final = __org_babel_python_ast.body[-1]
+if isinstance(__org_babel_python_final, ast.Expr):
+__org_babel_python_ast.body = __org_babel_python_ast.body[:-1]
+exec(compile(__org_babel_python_ast, '', 'exec'))
+__org_babel_python_final = eval(compile(ast.Expression(
+__org_babel_python_final.value), '', 'eval'))
+else:
+
Re: A new, "org-bullets"-like minor mode
D writes: > On 01.02.20 21:32, Marco Wahl wrote: >> AFAICS org-bullets is released under GPL3. Doesn't this mean that you >> can use org-bullets as a base for further development if you leave the >> license intact and also keep the original authors next to your name? > > That is correct, I just don't mean to come off as rude making a still > rather derivative mode like that without trying to get the guy's > blessing. I am likely overthinking the matter. > > Would it be appropriate to share the link here? I think it would be > great to get feedback before trying to get it on melpa. I would like to take a try too. Hope it is lightweight enough. Don't invoked lot of time. > > Cheers, > > D. -- [ stardiviner ] I try to make every word tell the meaning what I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
Re: org-babel-load-file support elisp
I came across this inconsistency a while back. I think the problem is that you should *not* be able to use elisp as a language specifier in source blocks. All other language specifiers comply to the pattern of source block languages being the language major mode name without the '-mode', but there is no elisp-mode. The problem now is that removing support for 'elisp' would break too much. So the question becomes 'Do we want to continue down this road and if so, does it make sense to support 'elisp' as a synonym for emacs-lisp in all places where specifying the language is used?'. Troy Hinckley writes: > > I think supporting "#+begin_src elisp" would be confusing > > elisp is already supported in all other babel > functions. org-babel-load-file is the only function that makes a > distinction as far as I can tell. And since that function is outlier it > makes sense to document this limitation in its docstring. > > Or even better would be to detect if the user had elisp blocks and throw > and error. Though I am not sure how to do that outside of seeing if > tangling elisp is successful. > > -Troy Hinckley > > On Feb 3, 2020, 12:23 PM -0700, Bastien , wrote: > > Hi Troy, > > I tracked down an issue trying to load a literate config file. > org-babel-load-file calls org-babel-tangle-file with lang set to > "emacs-lisp". This means that it won't tangle any blocks with > language set to "elisp", which is equivalent. I can't think of an > easy way to fix this since you would need to target both languages. > Maybe at very least we could add something to the doc string to draw > attention to this limitation. > > > I think supporting "#+begin_src elisp" would be confusing but I agree > we could give a hint somewhere about this. > > Can you suggest which docstring should be updated and how? > > Thanks, -- Tim Cross
Re: org-babel-load-file support elisp
> I think supporting "#+begin_src elisp" would be confusing elisp is already supported in all other babel functions. org-babel-load-file is the only function that makes a distinction as far as I can tell. And since that function is outlier it makes sense to document this limitation in its docstring. Or even better would be to detect if the user had elisp blocks and throw and error. Though I am not sure how to do that outside of seeing if tangling elisp is successful. -Troy Hinckley On Feb 3, 2020, 12:23 PM -0700, Bastien , wrote: Hi Troy, I tracked down an issue trying to load a literate config file. org-babel-load-file calls org-babel-tangle-file with lang set to "emacs-lisp". This means that it won't tangle any blocks with language set to "elisp", which is equivalent. I can't think of an easy way to fix this since you would need to target both languages. Maybe at very least we could add something to the doc string to draw attention to this limitation. I think supporting "#+begin_src elisp" would be confusing but I agree we could give a hint somewhere about this. Can you suggest which docstring should be updated and how? Thanks, -- Bastien
Re: getting item information in an export filter?
Thanks Nicolas! John --- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu On Mon, Feb 3, 2020 at 11:26 AM Nicolas Goaziou wrote: > Hello, > > John Kitchin writes: > > > In > > > https://emacs.stackexchange.com/questions/55231/org-mode-export-html-add-name-attirbute-to-checkbox-input > > > > there was a question about modifying a checkbox export. I wrote an answer > > using a custom translate function in a derived backend, where I could get > > the name of the parent list pretty easily. > > > > It seems like that should also be possible in a filter, but I don't > > understand how to find the parent list in that case. I think it is buried > > in the info. > > > > Is there a general way to get to the org-element information for > something > > in an export filter function? > > No, there's no simple way to access the element. Filters, with a few > exceptions, are meant to operate on strings, not on the parse tree. They > are usual meant as a simple way to transform the output. I.e., they are > intentionally dumbed down. > > You could however, use the parse-tree filter to modify the parse tree > before export. > > Regards, > > -- > Nicolas Goaziou >
Re: Bug: org-drill-entry-empty-p should use outline-forward-same-level and not outline-next-heading [9.1.6 (9.1.6-48-gfe7619-elpaplus @ /Users/christoffer/.emacs.d/elpa/org-plus-contrib-20180212/)]
Hi Phillip, Phillip Lord writes: > BTW, I am maintaining org-drill at: > > https://gitlab.com/phillord/org-drill/ sorry I overlooked this info in my previous email. Could you send a patch again this page: https://orgmode.org/worg/org-contrib/org-drill.html You can clone Worg from here: https://code.orgmode.org/bzg/worg/ Thanks! -- Bastien
Re: Bug: org-drill-entry-empty-p should use outline-forward-same-level and not outline-next-heading [9.1.6 (9.1.6-48-gfe7619-elpaplus @ /Users/christoffer/.emacs.d/elpa/org-plus-contrib-20180212/)]
Hi, a...@xkqr.org (Christoffer Stjernlöf) writes: > Remember to cover the basics, that is, what you expected to happen and > what in fact did happen. You don't know how to make a good report? See > > https://orgmode.org/manual/Feedback.html#Feedback > > Your bug report will be posted to the Org mailing list. > > > I have noticed that some of my drill entries are skipped by org-drill, > and only > recently took the time to try to troubleshoot why – apparently > org-drill-entry-empty-p returns t for my entries, because they look like > the > following: org-drill is not in Org's repository anymore, you can try to contact Paul Sexton from this repository: https://bitbucket.org/eeeickythump/org-drill/src/default/ Best, -- Bastien
Re: Bug: Repeating Time Stamp Bug [9.2.3 (9.2.3-elpa @ /home/David/.emacs.d/elpa/org-9.2.3/)]
Hi David, > Remember to cover the basics, that is, what you expected to happen and > what in fact did happen. You don't know how to make a good report? See > > https://orgmode.org/manual/Feedback.html#Feedback > > Your bug report will be posted to the Org mailing list. > > > For setting a meeting for Monday thru Friday from 8:30am to 11:00am, I > used a multi-day timestamp of the following form: > > <2019-08-05 Mon 08:30-11:00>--<2019-08-09 Fri 08:30-11:00> > > That does not result in setting a repeating meeting for Monday thru > Friday for 8:30am to 11:00am. Instead, the meeting is set for Monday > thru Friday, but only Monday and Friday are marked with the 8:30am to > 11:00pm timestamps in the Agenda. thanks for reporting this, this is now fixed. -- Bastien
Re: Bug: babel plantuml doesn't support multipage diagrams [9.1.9 (release_9.1.9-65-g5e4542 @ /usr/share/emacs/26.2/lisp/org/)]
Hi Vladimir, Vladimir Nikishkin writes: > #+begin_src plantuml :file test.png :export both > class "Class1" as c1 > newpage > class "Class2" as c2 > #+end_src > > PlantUML generates two files if given this source. test.png and > test_001.png > However, org-babel only shows the first one. > It would be nice if it could show both. Well, since :file only receives one file, this cannot be done, sorry. -- Bastien
Re: [O bug] table debugging does not preserve window configuration
Hi Eric,
"Fraga, Eric" writes:
> If I turn debugging on for table updates (C-c {), when the debugging is
> finished, the original window configuration is not remembered.
>
> Should be simple to fix, but possibly beyond my emacs-lisp-fu.
Fixed, thanks!
--
Bastien
Re: Org agenda -- checking for invisible tasks after filtering...
Hi Christian, Christian Schwarzgruber writes: > The question is now, is it possible to further reduce the advised > functions to just one advised function. I am sorry, I don't understand what change does it imply on Org's side. Can you explain us a bit more? Thanks! -- Bastien
Re: [PATCH] ob-scheme: Handle :epilogue params
Hi Qian, applied to master, thanks! -- Bastien
Re: org-babel-load-file support elisp
Hi Troy, > I tracked down an issue trying to load a literate config file. > org-babel-load-file calls org-babel-tangle-file with lang set to > "emacs-lisp". This means that it won't tangle any blocks with > language set to "elisp", which is equivalent. I can't think of an > easy way to fix this since you would need to target both languages. > Maybe at very least we could add something to the doc string to draw > attention to this limitation. I think supporting "#+begin_src elisp" would be confusing but I agree we could give a hint somewhere about this. Can you suggest which docstring should be updated and how? Thanks, -- Bastien
Re: Bug: About org-submit-bug-report [9.3 (release_9.3 @ /usr/local/share/emacs/27.0.50/lisp/org/)]
Hi Michael, > I want to suggest to make `report-org-bug' and alias for the command > `org-submit-bug-report'. That's the name I expected (considering > "report-emacs-bug"), also some other Emacs packages name their bug > reporting command according to this scheme. The additional name would > make this important command more discoverable. M-x report TAB only complete `report-emacs-bug' in my setup. I'm not sure making an exception for Org mode is that useful. > Second point: When you think it is a trivial task for a common user > please consider to add some text to the initial buffer contents of the > message buffer created by this command explaining where one can search > for existing reports (to avoid duplicates and reports about things that > are just pitfalls etc). My buffer included a link to a page explaining > how to create a good report but there this information is also missing, > although I think it would be a good place. I've updated the message a bit, please let me know if this is better: https://code.orgmode.org/bzg/org-mode/commit/1a29c0ee Thanks, -- Bastien
Re: Non-printable Characters in Bug Reports
Hi Sebastian, Sebastian Miele writes: > I told mu4e to replace the characters. Apparently, all non-printable > characters have been replaced by ASCII periods. > > Is there a best practice? FWIW, I think ASCII periods are fine in this case. -- Bastien
Re: [BUG] Infinite loop in org-agenda-show-new-time
Hi Andrew, I have pushed some fixes in this area, if you have a chance to test Org from the latest maint or master branch, please do so and report if the problem persists. Thanks, -- Bastien
Re: About options to export/tangle block for markdown or html, on a remote tramp ssh relative dir ?
Hi Sébastien, rey-coyrehourcq writes: > #+BEGIN_EXPORT markdown > ... > #+END_EXPORT > > But is it possible using options to : > - export this block as file using :tangle, > - on a remote :dir using option for #+BEGIN_EXPORT ? What did you try exactly, and where does it fail? Can you provide an example we can try to isolate the source of the problem? Best, PS: You can also join the french mailing list advertized here to seek for help on a french list: https://www.emacs-doctor.com/ -- Bastien
Re: Bug: org babel plantuml Java parameter is ignored [9.3 (9.3-elpa @ /nix/store/azm93cbq487szgddp5hhi4vp1q9ryyp7-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/)]
Hi Philipp, Philipp Middendorf writes: > I don't have a globally available "java" executable and from the > source > code, it appears there is a ":java" parameter for org-babel to specify > an executable. Looking at the source code, however, it seems that this > parameter is never actually used (see org-babel-execute:plantuml in > ob-plantuml.el). In `org-babel-execute:plantuml' I see this binding: (java (or (cdr (assq :java params)) "")) which means that the local binding "java" is set based on the :java parameter, which you need to set to your java executable. Does it look right to you? Thanks, -- Bastien
Re: Folding whitespace at the end of a tree
Hi Kjell, I cannot reproduce this problem. What version of Org are you using? M-x org-version RET Thanks, -- Bastien
Re: Bug: org-indent-region doesn't restore cursor position when org-src-tab-acts-natively is t [9.1.9 (release_9.1.9-65-g5e4542 @ /usr/share/emacs/26.3/lisp/org/)]
Hi Sébastien, I cannot reproduce this bug with latest Org version. If you can, please test with the latest Org version and report any problem. Thanks, -- Bastien
Re: LaTeX export failure
"Thomas S. Dye" writes:
> Thanks Eric,
>
> Good to know. I'll try to track down the issue when I find time.
>
> All the best,
> Tom
>
> Fraga, Eric writes:
>
>> On Wednesday, 29 Jan 2020 at 15:22, Thomas S. Dye wrote:
>>> Here is the offending bit, which worked fine last November but
>>> fails today:
>>>
>>> #+caption: Compare figure\nbsp{}[[fig:mqs3_op]].
>>
>> This works fine for me. Sorry; that probably doesn't help you
>> much... :-(
>
>
> --
> Thomas S. Dye
> https://tsdye.online/tsdye
>
>
If you have not tried it already, M-x toggle-debug-on-error and
retrying the export should give a backtrace, which should help guide
further investigation. It should work even if you do the export in
batch mode (the backtrace should appear on stderr, I think), but if
you can do it interactively and with uncompiled code (C-u M-x
org-reload IIRC), that would be best.
--
Nick
"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler
org-babel-load-file support elisp
I tracked down an issue trying to load a literate config file. org-babel-load-file calls org-babel-tangle-file with lang set to "emacs-lisp". This means that it won't tangle any blocks with language set to "elisp", which is equivalent. I can't think of an easy way to fix this since you would need to target both languages. Maybe at very least we could add something to the doc string to draw attention to this limitation.
Re: Bug (with fix): org-tempo-add-block incorrectly inserts comma before next `#+begin_src' during expansion [9.3.2 (9.3.2-8-g47b104-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20200127/)]
Hi Bastien, > Yes, you're right, my fix was wrong - I've followed your indication > and removed the second occurrence of '>. > > What happens is this: the template expansion calls org-edit-src-code > which gets the wrong source block boundaries, thus escaping "#+begin" > with a comma. > > Looking at the second '>, I think there is no need for it here (it > means: "indent the line"), so we're safe removing it without touching > `org-edit-src-code' for now. OK, makes sense, thanks! Kind regards, Bram Adams > I still think org-edit-src-code should only be called interactively, > not through internal calls. I'll see if this needs to be fixed too. > > Best, > > -- > Bastien >
Re: Bug (with fix): org-tempo-add-block incorrectly inserts comma before next `#+begin_src' during expansion [9.3.2 (9.3.2-8-g47b104-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20200127/)]
Hi Bram, Bram Adams writes: > I applied the commit, but still encounter the same issue, unless I > disable `org-src-tab-acts-natively’ or remove ‘> in the org-tempo > macro. Yes, you're right, my fix was wrong - I've followed your indication and removed the second occurrence of '>. What happens is this: the template expansion calls org-edit-src-code which gets the wrong source block boundaries, thus escaping "#+begin" with a comma. Looking at the second '>, I think there is no need for it here (it means: "indent the line"), so we're safe removing it without touching `org-edit-src-code' for now. I still think org-edit-src-code should only be called interactively, not through internal calls. I'll see if this needs to be fixed too. Best, -- Bastien
Re: Bug (with fix): org-tempo-add-block incorrectly inserts comma before next `#+begin_src' during expansion [9.3.2 (9.3.2-8-g47b104-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20200127/)]
Hi Bastien, >> Are you referring to commit cad2a6a588? > > Yes, this commit. I applied the commit, but still encounter the same issue, unless I disable `org-src-tab-acts-natively’ or remove ‘> in the org-tempo macro. Kind regards, Bram Adams
Re: getting item information in an export filter?
Hello, John Kitchin writes: > In > https://emacs.stackexchange.com/questions/55231/org-mode-export-html-add-name-attirbute-to-checkbox-input > > there was a question about modifying a checkbox export. I wrote an answer > using a custom translate function in a derived backend, where I could get > the name of the parent list pretty easily. > > It seems like that should also be possible in a filter, but I don't > understand how to find the parent list in that case. I think it is buried > in the info. > > Is there a general way to get to the org-element information for something > in an export filter function? No, there's no simple way to access the element. Filters, with a few exceptions, are meant to operate on strings, not on the parse tree. They are usual meant as a simple way to transform the output. I.e., they are intentionally dumbed down. You could however, use the parse-tree filter to modify the parse tree before export. Regards, -- Nicolas Goaziou
Re: Bug (with fix): org-tempo-add-block incorrectly inserts comma before next `#+begin_src' during expansion [9.3.2 (9.3.2-8-g47b104-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20200127/)]
Hi Bram, Bram Adams writes: > Are you referring to commit cad2a6a588? Yes, this commit. -- Bastien
Re: Bug (with fix): org-tempo-add-block incorrectly inserts comma before next `#+begin_src' during expansion [9.3.2 (9.3.2-8-g47b104-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20200127/)]
Hi Bastien, > this should be fixed now in maint and master. Thanks for looking into this. > I implemented a different fix, please test it and report > any problem. Are you referring to commit cad2a6a588? Kind regards, Bram Adams
Re: [RFC PATCH] specify a time, not number of minutes to keep, with org-resolve-clock
Robert Pluim writes: >> On Sat, 01 Feb 2020 15:34:54 +0100, Bastien said: > Bastien> And since is it a good outcome to have more people signing the > FSF > Bastien> papers, I recommend requesting contributors to sign the copyright > Bastien> assignment for every >15 lines contributions (significant or > not). > > Not only that: without copyright assignment you need to keep track of > whether an individual has contributed more than 15 significant lines > *total*, which is a hassle. Yes, indeed. -- Bastien
Re: [RFC PATCH] specify a time, not number of minutes to keep, with org-resolve-clock
> On Sat, 01 Feb 2020 15:34:54 +0100, Bastien said: Bastien> And since is it a good outcome to have more people signing the FSF Bastien> papers, I recommend requesting contributors to sign the copyright Bastien> assignment for every >15 lines contributions (significant or not). Not only that: without copyright assignment you need to keep track of whether an individual has contributed more than 15 significant lines *total*, which is a hassle. Robert
getting item information in an export filter?
In https://emacs.stackexchange.com/questions/55231/org-mode-export-html-add-name-attirbute-to-checkbox-input there was a question about modifying a checkbox export. I wrote an answer using a custom translate function in a derived backend, where I could get the name of the parent list pretty easily. It seems like that should also be possible in a filter, but I don't understand how to find the parent list in that case. I think it is buried in the info. Is there a general way to get to the org-element information for something in an export filter function? John --- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu
Re: Templating of PDF export
I don't know of a nice Jinja like template for this. I think what you need is a custom exporter. You can define template function that is responsible for the latex source. In this function you would check for the attachment, scale it as you want, and insert the figure code in the latex source where you want it. I have defined a template function for a memo that you might find some inspiration from, you can see it at. https://github.com/jkitchin/scimax/blob/master/ox-cmu/ox-cmu-memo.el I guess somewhere around line 91 is where you would put the code to insert attachments. Yours might be quite a bit simpler if you don't need file keywords for information. Now that I am looking at this, you could use something like s-format or mustache to get a reasonable template. I just used concat for the most part. The trick would be finding the template system where escaping characters wasn't too tedious, you already have to escape some things in the template. Florian Lindner writes: > Hello, > > I am collecting my cooking recipes in an org-mode file. While that > certainly works for, I would like to have a nice LaTeX export for > non-nerd mortals to look at. All recipes are in one file and each one > looks like: > > * Pancakes > ** Ingredients > + 6 Eggs > + 3 Apples > ** Directions > Just do it! > ** Source > My mother > > Sometimes I take a photo of the meal and ATTACH it. > > Most guides how to customize org export are about modifying the document > class and latex snippets there there. However, the basic association > with * Pancakes -> \section, ** Ingredients -> \subsection stays the same. > > Is there something builtin org-mode which allows to use a templating > language that allows for a more freely combination of elements, similar > to Jinja or alike? > > For example, I want to embed the attachment in the export, appropriately > scaled and nicely placed and have a line break after each recipe. > > I know about org-chef, but AFAIK it's more about importing templates > from websites, not about a nice export. > > Any ideas for that? > > Thanks! > Florian -- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu
Re: Bug (with fix): org-tempo-add-block incorrectly inserts comma before next `#+begin_src' during expansion [9.3.2 (9.3.2-8-g47b104-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20200127/)]
Hi Bram and Ihor, this should be fixed now in maint and master. I implemented a different fix, please test it and report any problem. Thanks, -- Bastien
Re: A few changes to test in master
On Monday, 3 Feb 2020 at 09:17, Bastien wrote: > "Fraga, Eric" writes: > >> The header line is now 2 characters to the right of where it should be! >> I have looked at the code briefly but cannot figure out why this would >> be. >> >> I have not seen any difference in behaviour for shrunken columns. > > What is M-x org-version RET ? In my signature. > Can you send a reproducible ECM ? I'll try tomorrow. With respect to the placement of the table header, I should say that my line-number face is customized to have characters smaller than the default text. This will probably affect the placement and I'm sure will make it very difficult to adjust correctly (i.e. more difficult than is really worth the effort). Thank you. -- Eric S Fraga via Emacs 28.0.50, Org release_9.3.2-199-ga557cf
Re: Table alignment documentation
Hi Colin, Colin Baxter writes: > I notice in https://orgmode.org/manual/Column-width-and-alignment.html > that a footnote says table centering does not work in emacs but only > when exported to html. thanks for reporting this -- this is an old page that the release process did not delete (whereas it should have). I will delete this manually. The correct manual page is this one : https://orgmode.org/manual/Column-Width-and-Alignment.html#Column-Width-and-Alignment -- Bastien
Re: A few changes to test in master
Hi Eric, "Fraga, Eric" writes: > The header line is now 2 characters to the right of where it should be! > I have looked at the code briefly but cannot figure out why this would > be. > > I have not seen any difference in behaviour for shrunken columns. What is M-x org-version RET ? Can you send a reproducible ECM ? -- Bastien
