Lennart,
John's idea seems good. also, you could generate a separate RESULT for
each language, then :var each language's "failed" RESULT into your bash
block and fail if any of them are set?
cheers, Greg
Bastien,
> > lisp/ob-julia.el: Add a Homepage header
>
> that Homepage seems to point at
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git which appears to be
> a (the?) full-on org-mode git repo, and which doesn't appear to have
> ob-julia.el.
apologies, i hadn't taken the time to look at
hi, all. i use, but don't know much about, straight.el [1]. in case
it's of use to anyone, here is what is did to bring in the new
org-contrib:
(straight-use-package '(org-contrib :type git
:repo "https://git.sr.ht/~bzg/org-contrib;
hi, Bastien,
> 2e0375d2 — Bastien Guerry2 days ago
> lisp/ob-julia.el: Add a Homepage header
that Homepage seems to point at
https://git.savannah.gnu.org/cgit/emacs/org-mode.git which appears to be
a (the?) full-on org-mode git repo, and which doesn't appear to have
ob-julia.el.
for whatever
Kevin,
ah. the behavior is complicated for me to understand, but presumably
useful. (there's a Jerzy Neyman quote: Life is complicated, but not
uninteresting.)
cheers, Greg
Kevin,
> FWIW, during the latest poll somebody suggested making org-indent-line
> cycle through "syntactically valid" indentation levels when hitting TAB
> repeatedly, like python-indent-line-function; I like this idea.
i think (*) the current "master" branch allows you to type "-
fu- *bar"
Tom,
>I just checked and it induces a syntax error, which I did not know,
> but turns out to be quite useful because it means that an untangled or
> incorrectly tangled file will fail to run beyond that point. Best!
:) cheers.
Aleks, et al.,
> Apart from the export, one of my biggest gripes is
> flyspell. Specifically, the fact that you have to choose one language to
> spell check the entire document with. That is insufficient in my case.
in case it's relevant:
i also switch between languages. but, for me (maybe i'm
Tom, that is quite devious, actually. thank you very much! do you
know, by the way, what flycheck and/or the shell make the "<<&"
construct out to be? cheers, Greg
Diego and Sébastien,
thank you both. in particular, i didn't know about
=org-babel-noweb-wrap-start=, and that's probably perfect for this
case.
cheers, Greg
hi, all.
using a <> reference in a bash source block, the buffer's font
lock colors go south on lines folowing the <> reference. (in my
case, all remaining lines in the buffer are colored bright yellow). the
major and minor modes are as listed below.
is there an obvious thing to do to either
in this thread...
> > The publish feature only means exporting several files at once.
> You can publish a single file, too. It makes sense when a file is always
> exported to the same location, possibly with the same configuration.
my model is that exporting is to publishing as, well, as org
Timothy,
thanks!
> Greg Minshall writes:
>
> > having glanced briefly at transient, would it be something with which
> > one could, e.g., implement the export menu?
> >
> > where else in org-mode would you see using it?
> >
> > (just curiosity.)
> &
Timothy,
> I actually think Org would benefit from using transient (which has
> recently been merged into Emacs), and it could reduce the maintenance
> burden, but I suppose that's not possible with our minimum version at
> Emacs 24...
having glanced briefly at transient, would it be something
Timothy,
> The rendering is just done by `org-latex-preview'.
> Hope that clears things up.
yes, thanks.
Timothy,
interesting. would this show up in #+RESULTS blocks? in (heaven
forbid!) #+BEGIN_SRC blocks?
cheers, Greg
Bastien,
> I hope this is not confusing.
no, that's perfectly clear. thanks.
Greg
Bastien,
> You might want to write another one for the public-inbox archive:
>
> E.g. https://orgmode.org/list/?q=Juan+Manuel+Mac%C3%ADas
okay, i'll bite: what *is* the difference between
https://orgmode.org/list and
https://lists.gnu.org/archive/html/emacs-orgmode/ ?
cheers, Greg
Tom, thanks! i assumed something like that.
hi, Nicolas,
i'm curious, not knowing history and/or procedures.
> ... CL is still necessary however, as we cannot use `seq' yet.
why is 'seq not "yet" available? what will make it available?
cheers, Greg
David Masterson wrote:
> Hmm. I don't see a date function in Elisp...
(current-time-string), if that helps.
Rama,
one other comment/suggestion.
> I haven’t been able to fully work with Donald Knuth’s suggestion of
> writing a Literate Program directly in a tool like orgmode/noweb since
> it is a nuisance to keep having to type C-c ' to go into the editing
> mode of the language concerned.
while i
Rama,
thanks for your explanation.
Arne Babenhauserheide suggested [M-x org-babel-detangle]; i've not used
it myself, but it seems a possible direction.
cheers, Greg
Rama,
another possible solution, though it may not be possible for your setup,
is to "invert" things: centralize all your snippets in snippet.org, with
each *snippet* set to tangle to its individual lisp file.
cheers, Greg
Nicolas, thanks, your fix also seem to solve the problem i was having.
cheers, Greg
Kyle,
> The below change seems to fix the issue, though Nicolas may be able to
> suggest a more appropriate change.
yes, that seems to work for me.
cheers, Greg
> diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
> index 932f38530..ac24f1f74 100644
> --- a/lisp/ox-latex.el
> +++
hi. running c881b60593b3beeed7b8c7a2bada64157cd9940a, the following
*** this =equals= that
and, so on
exporting [C-e l o], gives
: replace-regexp-in-string: Wrong type argument: arrayp, nil
cheers, Greg
=
backtrace:
Debugger entered--Lisp error: (wrong-type-argument
Michael,
> Now I want to use this file to showcase the use case a bit, but also
> to produce documentation about Org, about how to solve a problem with
> Org. Therefore I want to show the code blocks, but this time with the
> begin/end tags, with header parameters etc. Is there a nice way to do
Russell,
> I would not suggest using UTC. I believe one of the reasons timestamps
> didn't include TZ information was to keep them short and human
> legible. Solutions with overlays to change a timestamp reduce the
> usefulness of the plain text reading of Org (ie: less, grep,
> etc). Storing
William,
try
#+begin_src shell :results output :var n=numbers
echo ${n[1]}
#+end_src
cheers, Greg
hi, Shiro,
> With this, say the user have
>
> #+TIMEZONE: America/Toronto
>
> at the start of their org file, and they moved to Shanghai, all the timestamp
> in
> the org file is converted using something equivalent to
>
> $ TZ=Asia/Shanghai date --date='TZ="America/Toronto" '"$TIMESTAMP"
>
Michael,
i see "Hello" when i C-c C-c. i see this with "emacs -Q".
cheers, Greg
Jean Louis,
another thing that i find helpful in understanding the tao of export: if
you haven't, look at the help string for the variable
~org-export-options-alist~: [C-h v org-export-options-alist].
cheers, Greg
Jean Louis,
when publishing, one presents a data structure
~org-publish-project-alist~ that defines the back ends and options for
publishing actions. the options are here:
https://orgmode.org/manual/Publishing-options.html#Publishing-options
below is an example. as you can see,
George and all,
whether it's the right thing to do or not, i don't know. but, i'm very
sympathetic to the urge. even when posting to the list, the reflex to
use back ticks is strong.
Greg
Jean Louis,
> Another issue related to this setup is that I would like:
>
> - for HTML export: title:t toc:t
>
> - for LaTeX PDF export: title:nil toc:nil
>
> Is there way to have options different for different exports?
sometimes "publishing" gives me easier control over options than
hi. this fails with [emacs -Q], which in my case
: Org mode version 9.4.4 (release_9.4.4 @ /usr/share/emacs/27.2/lisp/org/)
and, also in whatever elpa'ish version i'm running
: Org mode version 9.4.4 (release_9.4.4-277-g2e1c98 @
/home/minshall/.emacs.d/straight/build/org/)
when i specify
i tend to be situational. some things i export to html, some to pdf,
some to both. it just depends on the need of whatever small project i'm
working on.
below is a small patch with clarification in the manual, if deemed
appropriate.
cheers, Greg
>From 46306f25fa1171fad94b7e70690c40f7db35a018 Mon Sep 17 00:00:00 2001
From: Greg Minshall
Date: Mon, 29 Mar 2021 20:20:05 +0300
Subject: [PATCH] Clarify use of ... for CSS in HTML export
---
hi. i'm wondering what the reference to "style blocks" means in the
"CSS Support" section of the manual:
For longer style definitions, either use several ‘HTML_HEAD’ and
‘HTML_HEAD_EXTRA’ keywords, or use ‘ ... ’ blocks around
them. Both of these approaches can avoid referring to an
Gustav,
thanks. installing org went very well. and, i'm pleased with
straight.el. (package.el didn't seem to install the info pages,
either.)
cheers, Greg
Richard,
thanks. for ess, i see your results. for org, or org-plus-contrib, i
see info pages from /usr/share/info. a mystery. (which shall be, for
the moment, let be.)
cheers, Greg
Maxim,
also, thanks. i do use (something like) your suggestion when i just
want to try once or twice.
: emacs -Q -L /path/to/your/org-mode/folder/lisp -l org
(from Ihor R, last December.)
cheers, Greg
Gustav,
> Straight.el is worth looking into for this. Has served me well for
> similar use cases.
have you (or anyone else?) had problems getting straight.el to build and
install the info pages for Org mode?
cheers, Greg
---
doc/org-manual.org | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index 0dbc5e205..d75828722 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -15845,12 +15845,12 @@ and possibly transformed in the process. The
Tim and Gustav, thanks for your answers. in particular, straight.el
does seem promising. i'll set it up, use it with Tim's "switching
use-package blocks", and see how it goes. cheers, Greg
Kyle Meyer wrote:
> At the very least, the failure message should be informative in this
> situation (a call referencing an unknown name). I've pushed a commit
> (5450d6420) to improve the error reporting.
thanks!
hi. i occasionally want to switch from the org package to a git
version, then back again. and, i want to avoid the dread "mixed
installation".
i'm wondering is there a way people do this other than simply
installing/deleting the package version?
cheers, Greg
Kyle,
> Hmm, given that the lexical-binding change to ob-core was back in Org
> 9.0 (November 2016), it seems like dynamic scoping wasn't really being
> relied on (or, if it was, downstream code has already been adjusted).
> In my view it'd be better to stick with lexical scoping for these
>
URL)"])
("help" :follow org-link--open-help) ("file" :complete
org-link-complete-file)
("elisp" :follow org-link--open-elisp) ("doi" :follow
org-link--open-doi))
org-latex-format-headline-function 'org-latex-format-headline-default-function
org-link-elisp-confirm-function 'yes-or-no-p
org-latex-format-inlinetask-function
'org-latex-format-inlinetask-default-function
org-html-format-drawer-function #[514 "\207" [] 3 "\n\n(fn NAME CONTENTS)"]
org-html-format-headline-function 'org-html-format-headline-default-function
)
--
Greg Minshall
Kyle,
thanks. i see. i wondered why the talk was all about agendas.
since, in my (brand new, experimenting) use of
=org-babel-map-src-blocks=, i'm calling a function, and that function is
trying to de-reference, e.g., =beg-block=, i get an error.
it is (or does seem to be) the case that if
> but, iiuc, that relies on dynamic binding. so, as =lexical-binding= is
> =t=, i don't have access to those appealing variables.
from reading the elisp manual, it seems that one could define those
variables to be "special variables", and, iiuc, one can achieve this by
using a =defvar= without a
hi. i just upgraded to
: Org mode version 9.4.4 (9.4.4-27-gb712b9-elpa @
/home/minshall/.emacs.d/elpa/org-20210315/)
and, have also just started playing with
(org-babel-map-inline-src-blocks), the documentation for which says
During evaluation of BODY the following local variables
are set
Chuck,
> I admit to being baffled by this.
>
> If you have nested org src blocks and you recursively enter each org
> block using `org-edit-special' and execute the src blocks other than
> org lang, then exit with `org-edit-src-exit', when you complete this
> the org buffer will have nested src
Charles,
thanks.
ah, i apologize -- i missed the elisp content of your earlier message.
yes, that, at least for this simple case, does exactly what i was
looking for!
i guess when i used the term "recursive execute function" (i tend to
confuse "execute" and "export"), i was thinking of
Charles,
thanks. any thing you'd like to add to the R-via-ESS/org-mode
repository, that would be great.
in general, afaik, the contents of org-in-org buffers export okay. at
least plain ones. would could like to have the embedded code blocks go
through some pretty-printer, but currently i
Jeremie,
thanks for this.
> A possible solution might be this one
> #+NAME: readdata-code
> #+BEGIN_SRC org
> ,#+NAME: readdata-code
> ,#+BEGIN_SRC R :results value silent
>
> read.data("datafile1.csv",sep=3D",",header=3DT)->mydata1
>
>
> ,#+END_SRC
> #+END_SRC
iiuc, this will embed
Erik,
> I am not sure if this would be useful to your efforts, but I have an "R in
> org-mode" tutorial on github:
> https://github.com/erikriverson/org-mode-R-tutorial
thanks. that gives me a model to look at in terms of structure and
content.
Greg
i have a question about org-in-org source blocks. i volunteered to help
in an effort to provide a tutorial of using the ESS (Emacs Speaks
Statistics) package for R, in particular, from org mode.
i'd like to write my contribution as a .org file. i'd like to include
fragments of org code,
Malcolm, thanks, and, yes, i'm of mixed mind, myself. cheers, Greg
Malcolm,
> Checkout what R sqldf package makes easy:
very nice!
Greg
ps -- (feeling a challenge... :) for base R, dplyr::inner_join, the
following seem to work (i apologize that i don't know how people embed
org-frags in e-mail, or how important that format might be?)
#+NAME: original
|
Tim,
> There is no plans to change anything as far as I know. What I wrote was
> mainly to show why we have the situation and that any proposed solution
> has its own drawbacks.
thanks. (i assumed that, but ...)
> Bottom line, we cannot easily prevent the 'false' list item issue
> without
Tim,
> If a line starts with a number, period and space, but that line is
> within a paragraph (i.e. no blank line above), then I don't think it
> should be interpreted as an enumerated list item. If this is what the OP
> is referring to, I would argue it is a bug. If it is a 'paragraph'
>
John,
> Is there a state of the art in using org-tables as little databases
> with joins and stuff?
i have to admit i do all that with an R code source block. (the dplyr
package has the relevant joins, e.g. dplyr::inner_join().) and, in R,
":colnames yes" as a header argument gives you header
hi, Rodrigo,
thanks. i understand. we all like "int i;" to be independent in
separate functions (as it were). right now, names of source blocks are
global to the .org file, and i don't suspect that will (or should)
change.
i apologize for bringing it up, but the one thing that jumps out at
Rodrigo,
i guess part of the answer depends on why you are naming your code
blocks. for me, the main reason is for <>. another is so that
when org-mode asks me if it should run a block, it has a name to tell me
to help in my decision-making.
for <>, there is noweb-ref header argument (see
Lee Jia Hong,
on your second surprise, there was some discussion on the e-mail list,
around 19 April, 2020, somewhere near this area. you might refer to
that.
cheers, again, Greg
Lee Jia Hong,
for your surprise number one, maybe look at this point of the Org Manual
Noweb insertions honor prefix characters that appear before the noweb
syntax reference.
basically, if the source of a <> has multiple lines (N, say), then the
output of a subsequent <> *copies* that
John,
> I tried this but it did not work for me.
to be clear, caching means that the *first* time you execute, your
reference will have to wait for the long-running computation to
complete, but not during subsequent executions (unless the source block
that performs the execution changes, in
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
apologies. (org-babel-do-load-languages) (rtfm!) is what i was lacking.
(progn
(org-babel-do-load-languages
'org-babel-load-languages
'((shell . t))
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
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:
Hongyi Zhao,
> I use Linux as my working environment exclusively. So, I can't access
> the native MS Office supplied for macOS/Windows. But I sometimes
> really need to manipulate and process MS Office documents, especially
> DOCX and XLSX files. Though there are some free and open source office
> No, sorry; I stopped using this a while ago. I now use the default
> exporter along this style sheet:
>
> https://taopeng.me/org-notes-style/css/notes.css
thanks!
hi, Eric, i wonder if you are still using ox-twbs? i like the look, but
internal links (from the TOC, say) appear to be broken. cheers, Greg
ps -- versions
ox-twbs20200628.1949 installed
org20201012 installed
Tom,
> The other reason I think this is a good idea is because I have been
> working on a formal grammar for the org syntax, and everything would
> be SO much simpler about the implementation after the first pass parse
> if the canonical representation of an Org file did not allow
> significant
Diego,
thanks for looking at it. i apologize for not having looked at an
"emacs -Q" (and, thanks to Ihor for, a few days ago, having pointed out
how to "emacs -Q" with one's "normal" org version).
: emacs -Q -L ~/.emacs.d/elpa/org-20201012/ -l org
exhibits *half* of the behavior i am
hi. it seems going into Org Src, at least from a "makefile" source
block, changes the tabs (the the base org mode added for me) into
spaces, and leaves them as spaces when i merge back into the main .org
file (and, so, make(1) complains, "missing separator").
is this intentional?
#+begin_src
Timothy,
> This is a quick patch to use the Emacs manual CSS with our generated Org
> manual.
that's certainly visually pleasing. nice!
Greg
Eric,
> Sure, and I do use it this way, but I had the impression that it was the
> non-git aspects that were being put forward as being somehow helpful. I
> could be wrong.
i'm not a git-spert. but, the "pull requests" mechanism and "issues"
(but reports), are maybe bits of git*.com that
Félix,
i ran into this restriction a while ago. on this list i was helped, and
ended up using the suggestion to instead put my common bits in a
property in the subtree for a given "name"
* aggregate.R
:PROPERTIES:
:header-args+: :tangle
Tim,
> At the end of the day, this is essentially a supply chain problem. To
> really have confidence, you need confidence in the whole supply chain,
> not just the distribution centre.
that makes sense. thanks.
Greg
Tim,
> It could, but to get that level of assurance, you not only have to
> verify the signature is valid (something which is automated if
> enabled), you also need to verify that both packages have the exact
> same signature, which is pretty much a manual process. So in addition
> to telling you
Tom,
> 2. If mutt is launching Emacs, you can pass --eval "(setq
>enable-local-eval nil)" on the command line and all file local
>variables will be ignored and treated as plain text.
maybe that is one thing that could really help here. possibly mutt and
other emacs-based mail readers,
Tim,
> I think you missed my point. There is no benefit in MELPA adopting
> signed packages because there is no formal code review and no vetting
> of the individuals who submit the code.
it occurs to me there might be one benefit: if George, whom you trust,
says, "I've been running version
Kyle, thanks. i assume a patch e-mail with no explanatory message is
not considered rude, so i'll try to remember to do that (or "scissors"
-- thanks for that!). and, thanks for pushing. cheers! Greg
Kyle, thanks. yes, blind copy and paste. i'm not a git-format-patch
expert, so let me know if this is the wrong format (i see some people
include inline, whereas others attach a file -- is one easier to handle
than the other?)
---
doc/org-manual.org | 5 +
1 file changed, 5 insertions(+)
hi, Robert,
thanks. given that the docstring already talks about nil, t,
'headline-data ...
should i eliminate those, just leaving "three" choices?
> "Adapt indentation for all lines"
> "Adapt indentation for headline data lines"
> "Do not adapt indentation at all"
or, leave mention
hi. this adds the minimal mention of transpose. cheers.
diff --git a/doc/org-manual.org b/doc/org-manual.org
index 040fccc21..33d32b8f5 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -1649,6 +1649,12 @@ you, configure the option ~org-table-auto-blank-field~.
the buffer. You
Robert,
> The whole point of customize is that you shouldn't have to worry about
> what the actual lisp value is. The actual lisp value only matters if
> you directly set the value without using customize.
thanks for the response. i've included the documentation for
org-adapt-indentation below.
for some reason, i was motivated to look at changing
org-adapt-indentation. i found that the help text talked about values
t, 'headline-data, and nil, but that the customization text didn't
(though, of course, it *set* those values). the following might make it
clearer.
diff --git a/lisp/org.el
Tim,
thanks.
my tests were in a src block inside the main buffer. like you, i
normally edit in an Org Src... buffer. but, it's nice when it basically
"works" even in the main buffer (for minor edits, etc.).
and, yes, setting org-adapt-indentation to either 'headline-data or nil
seems likely
hi, Tim, et al.
i started feeling guilty yesterday, partly for being party to prolonging
this discussion (though i do think it may be important?). but also for
realizing i had *not* explored the alternatives Tim, Gustavo, and others
have suggested.
the following is *clearly* the department of
i wonder if a grid might help? i.e., contexts in which we are all
happy, others where we might disagree? below, i try; i'm sure i've
missed cases.
question: what does do/would we like it to do when we are in?
=
tables: next row, current column
Org Src
i wanted first to thank everyone for their participation in this
discussion. i want to not be annoying. and, yes, this is a long
thread, and for me, at least, it's hard to keep track of what was said.
(like many, i assumed this was some bug, triggered by my configuration
TIMES emacs release
hi, all.
David Rogers wrote:
> Am I crazy to say that your last example of unwanted behavior is
> easier for me to read and understand? (and to me the common
> indenting is a hopeless mess?)
yes, in fact, the "new" way sort of has the buffer indentation match
that of the outline structure of
so, i also agree that the new('ish) behavior is somewhat surprising.
[i once changed the behavior of the "Enter" key in Berkeley Unix, and
suffered the (well-deserved, in that case) arrows that soon entered my
back.]
from that perspective, i wonder if maybe there's an interpretation of
Jean Louis,
> Like alias cat='sequence off; cat' something like that
>
> Somebody already mentioned there is cat -v to show nonprinting
> characters with notation ^- and M- so that may be the solution and I
> may be wrong there.
yes, 'cat -v' will do it for you. (or, i'd like to know if i've
Maxim,
thanks. small note.
> The sour story is that it is unsafe to feed non-trusted files directly
> to terminal. A filter against control sequences is required.
thus, the '-v' argument to cat(1) (which Rob Pike famously considered
harmful. :)
cheers.
201 - 300 of 377 matches
Mail list logo
