a few dead links on the babel languages page
hi. here are a few dead links from https://orgmode.org/worg/org-contrib/babel/languages/index.html - http://ditaa.org/ditaa/ - ? s/b http://ditaa.sourceforge.net/ - http://www.mathomatic.org/ - http://www.mozart-oz.org/ cheers, Greg
underline with line breaks doesn't work
Dear emacs-orgmode moderators:
I would like to use \ul from the soul package in Org mode for underlining with
line breaks (and *not* underlining spaces). It’s not working well. It fails
like \underline (spaces get underlined, and lines don’t break and run off the
page). My LaTeX export doesn’t work if I insert \ul{abc} into the org file, but
I can insert \ulem{abc} or \underline{abc}, as well as the typical _abc_.
More information: I’m actually trying to define a new command using logic in
the LaTeX header. This way, I can make notes with key words. I can toggle a
Boolean variable, and it makes key words show up; or, it underlines the words,
which are also hidden by \phantom. Also, we would like to avoid underlining
spaces because it cues the reader to know how many words are missing.
I note this previous discussion:
https://lists.gnu.org/archive/html/emacs-orgmode/2013-06/msg00376.html
It seems like the issue that was fixed at one point and \ul should work, but
maybe it’s not now. Or, maybe I don’t have the experience to know how to apply
the solution to my Emacs/Org mode on my computer.
FYI, I’m using org-9.3.6 from ELPA with Aquamacs 3.5, which includes GNU Emacs
25.3.50.1. I’m working on macOS X 15.7 (Catalina).
Thanks for any help or instructions you can provide. I’m not very experienced
at elisp, so I don’t know how to fix this locally, but I’m happy to try if you
tell me. It looks like I may be able to do something with
org-latex-text-markup-alist locally, but I don’t know what or how.
I will include my org text below, noting that \underline works in the
:+latex_header: lines, but \ul doesn’t.
Kind regards,
Enrique B.
Org doc starts below here
#+EXPORT_SELECT_TAGS: export
#+EXPORT_EXCLUDE_TAGS: noexport
#+latex_class_options: [12pt]
#+latex_header: \usepackage[margin=1in]{geometry}
#+latex_header: \newif\ifsolution % define a solution Boolean variable
#+latex_header: \solutiontrue % specify the value of the Boolean switch
#+latex_header: \ifsolution
#+latex_header:\newcommand{\keyText}[1]{\underline{{\color{blue} \Large
#1}}}
#+latex_header: \else
#+latex_header:\newcommand{\keyText}[1]{\underline{{\phantom{ \Large #1
#+latex_header: \fi
#+options: toc:nil
* This will be exported :ignore:
The solution text is here.
My message to you is: \keyText{Hello world}.
- Now, let us try some really long key text--so long that it even spans
multiple \keyText{lines. That line is this line, for so I have written it.}
Re: batch export: org-babel-execute:shell undefined? (SOLVED)
apologies. (org-babel-do-load-languages) (rtfm!) is what i was lacking. (progn (org-babel-do-load-languages 'org-babel-load-languages '((shell . t)) ) (let ((org-confirm-babel-evaluate nil)) (org-html-export-to-html)) (if noninteractive (kill-emacs))) works. best, Greg
Re: batch export: org-babel-execute:shell undefined?
happy 2021, all and sundry. i should mention something else, in case it makes something click for someone. obviously, i'm not initializing things right, but that's a weak part in my knowledge, so i'm not sure what. > i find that my shell source blocks are *not* being executed unless i > use (custom-set-variables), rather than (setq) or (let), to initialize > 'org-babel-load-languages. to wit... if i run "-Q", i see the same behavior, doing [C-c C-e h h]. *but*, if i first do [C-h f] (describe-function) on org-html-export-to-html, it works. so, presumably both (custom-set-variables) and (describe-function) are doing some sort of initialization. okay, if any body has any clue, i'd be very curious to know. cheers, Greg
ist here a :post header arg for tangling?
I'd like to run some code to post-process files after they are tangled. Is there a header-arg for that?
batch export: org-babel-execute:shell undefined?
hi. i am doing an export to HTML using "--batch --eval" to invoke emacs. i find that my shell source blocks are *not* being executed unless i use (custom-set-variables), rather than (setq) or (let), to initialize 'org-babel-load-languages. to wit... the following code works: (progn (custom-set-variables '(org-babel-load-languages '((shell . t))) ) (let ((org-confirm-babel-evaluate nil)) (org-html-export-to-html)) (if noninteractive (kill-emacs))) but, with (setq), this does *not* work: (progn (setq org-babel-load-languages '((shell . t)) ) (let ((org-confirm-babel-evaluate nil)) (org-html-export-to-html)) (if noninteractive (kill-emacs))) i find that in the latter case, in (org-babel-exp-results), (org-babel-execute:shell) is not defined. my emacs command line looks like this: emacs -L `find ~/.emacs.d/ -name "org-[0-9]*" -type d` -l org -L `find ~/.emacs.d/ -name "htmlize*" -type d` -l htmlize --batch ./public/index.org --eval " followed by one or the other above code fragments. does this ring any bells? or, any obvious stupidity on my part? cheers, happy 2021, hopefully. Greg
Re: Microsoft Excel spreadsheet editing directly from within emacs.
Jean Louis writes: > You speak of a programming language and what is possible with > programming language. That's not the point. Org table is integrated with Calc and Calc is a Computer Algebra System. That is something like Excel combined with Mathematica (with a little less GUI stuff) - that is powerful integration to me. Lisp is nice and for me as a programmer a helpful tool. But the main point is Calc. Just putting data in a tabulated form is seldom the interesting part. It starts to get interesting when you try to do something with the data, e.g. make some calculations. At this point it is significant, how many calculations you can do out-of-the box (without much programming). I did not count, but I assume that Calc has more calculations to offer than Excel and even for a wider range of topics (even symbolic math). Therefore, from this point of view of core functionality, I would say Org tables with Calc are more powerful that MS Excel. And thinking of the many quirks and bugs in MS Excel, I still say: Excel is the toy software and Emacs + Org + Calc is more mature and more professional and the file format much more future proof (yes, nowadays Excel uses XML, but the definition and documentation is lacking and too complex; it seems not possible to re-implement it fully). I emphasize this, because you wrote: "In comparison to all major known spreadsheets Org tables is not powerful and not even comparable." And "powerful" for me means core features, i.e. calculations. And in this respect, I think the statement is wrong. > In a spreadsheet program I may visually and nicely presented see a > slice of a whole table. I may move from slice to slice to other > pieces of the whole table of data. Moving from cell to cell is > pretty easy and there are no screen distortions. If your point of view is, that the main feature are the visual interactions (hiding/revealing rows/columns, sorting, filtering data etc.) then yes, maybe Org lacks a bit in these areas (but I think not quite as much, as you imply; e.g. Org can show labels for rows and columns and there are ways for hiding, sorting and filtering). On the other hand: I do find GUI spreadsheets also quite lacking in this regard (e.g. regex pattern are seldom easy to use). If I need to tinker with data, explore it, I would put it into a database (or into R or Julia or - depending on the size of the data - using R/Julia from within Emacs via Org tables). That's much faster, maintainable and reproducible. > Spreadsheet user interface is integrated, it does not require user > to remember much, or maybe nothing, just use a mouse. Nice try: There are tons of books about the question what are the best user interfaces. I have seen people working with computers with exactly this mindset: "I do not need to learn/remember anything, it should be easy, just clicking a bit with my mouse". At this level, it just does not work. So, yes, a very text-oriented UI is not the best solution for every task. But then a GUI is also not the best solution for every task. > Org mode is bringing us back into the era before Doug Engelbart. > Back to history. That's IMHO a very simplistic and ignorant view on UX. The problem is much more complex and yes, in quite some cases are text-based interfaces even one of the best solutions (and next to never exists a single best solution, UX always depends very strongly on context and details). > Combining various sheets is standard spreadsheet feature. Examples > you have shown are cryptic for spreadsheet users. I once showed rather simple Excel sheet to an Excel user and he was overwhelmed and did not understand how to create such a structure (2-3 tables with formulas across tables). So Excel is cryptic for spreadsheet users, too. :) With other words: No tool is simple, you need to learn at least a little bit - in all cases. I only showed the final result, not the way how it has been created. Emacs and Org have ways to ease some of the seemingly complicated parts, just as Excel tries to help formulate complicated calculations. And then comes habit. I fully understand that a tool like Excel at least seems to be easier for the first steps. But that does not mean that it is a given fact, that it is easier and better suited for any task that is spreadsheet like (you already mentioned databases - I would say for the typical spreadsheet users databases are even more cryptic that Emacs and Org). >> Maybe advanced visual presentation of the data is easier with GUI >> Spreadsheets -- then again, it is so easy to combine Org tables with >> the power of Gnuplot, R, Python, Julia, TeX etc. to create >> astonishing visuals, that I prefer this way in many situations. > That is like saying to a user to switch from Emacs to C programming > language as it gives user far more capabilities No, quite the contrary. I think, this is the main point, you seem not to understand. Emacs with Elisp is much more expressive than C. Org with Calc is (for
