hi, Jean Louis,
> I do not know what is column view. But I understand that you need
> descriptive text.
that was my state until recently, though i had seen various references
to it and its usage on the mailing list. it at least offers some form
of completing read, at least for what might be in
hi. i have a text in a named #+begin_example ... #+end_example block.
i would like to process this text line by line in a shell (bash, say)
code block. but, it appears that the individual lines are not
separated, but passed as one long string to the source block. (example
below.)
is there a mag
Ihor,
> Try
>
> #+name: lbl
> #+begin_example
> line 1
> line 2
> #+end_example
>
> #+begin_src bash :var input=lbl :results output
> echo "${input}"
> #+end_src
ah, the double quotes! thanks very much!
cheers, Greg
Ihor,
again, thanks for helping me with that problem.
and, just for my (or anyone's) future reference, how i probably *should*
have debugged this was to tangle the relevant source block, and then
examine the resulting shell-script file, and gone from there.
cheers, Greg
Frederic,
> > It looks like there is something wrong with comint-prompt-regexp in
> > R buffers. It somehow does not match the prompt.
>
> I'm not sure it's the explanation either, since external (i.e.,
> non-session) evaluation works as expected. (Just remove the ":session
> *R*" part of the hea
i see this same behavior. to me, (org-babel-R-assign-elisp) seems to be
the problem, but it hasn't changed any time recently. (nor, if my =git
blame= is done correctly, has anything else in ob-R.el.)
i don't understand how (org-babel-R-assign-elisp) thinks. it seems to
assign =max= and =min= as
for the record, these are the tests i ran with my off-the-cuff "fix"
(s/sequencep/listp/):
#+name: alist
- first item
- second item
- third item
#+begin_src R :var list=alist :session ss
list
#+end_src
#+RESULTS:
| first item | second item | third item |
#+begin_src R :var variable='(a tes
hi, Charles,
> This makes a list like '("a" "b" "c") into a data.frame with one column.
1. which version of Org are you running?
: Org mode version 9.6 (9.6-g60de19 @
/home/minshall/.emacs.d/straight/build/org/):
2. is my below example yours?
i think i used to see the behavior you describe in
Chuck,
sorry, i didn't see the change you had added.
> So, isn't that what is wanted?
that's a policy question that i can't answer. :)
cheers, Greg
Jeremie,
i am neutral w.r.t. what the output should be. like you, i've always
sent in tables.
for me, i don't know that it makes much difference how lists are
presented to R code, as long as it is well-defined and stable over time.
given that, iiuc, 9.5 presented a list as (the equivalent of) m
Ihor,
> Does it make sense from the point of view of R code?
> AFAIU, the current ob-R implementation converts lists into R tables,
> which is not accurate? Would it make sense to convert Elisp lists into R
> lists directly?
my "barely half a cent" would be that backwards compatibility here
trump
Ihor,
> The time span is years and I do not recall any related bug reports.
> So, nobody seems to care.
:)
Matt,
> I'm not too familiar with how emacs handles autoloads. However, I find
> org-mouse is automatically loaded if I call describe-function and then
> tab complete after typing "", "org-", "org-m", etc. This seems enough
> to load the entirely of the org-mouse.el file.
i'm also not an expert o
hi, Ihor,
> ** List references in source block variable assignments are now proper lists
just for background, one oddity is that the meaning of a "list" in R is
a bit loose.
> list(1,2,3)
[[1]]
[1] 1
[[2]]
[1] 2
[[3]]
[1] 3
> c(1,2,3)
[1] 1 2 3
(where =c= is the "concatenation operat
hi, Johan,
> "Proper list" in the context of this discussion and pertaining to R
> would be a =list()=, not a vector which is what is usually returned by
> =c()=. A =data.frame()= is a special case of a =list()= where every
> column has to have the same length.
well, it's a language mapping probl
Johan,
> Absolutely, I just wanted to clarify that there is no confusion as to
> what an R list is in the context of R itself (as far as I can
> tell). Your post made it sound like there is.
ah, indeed -- thanks!
cheers, Greg
hi, Ihor,
> Do we need to care about cleaning up /tmp?
my two cents is that maybe one should not care so much about cleaning up
/tmp, but i think it's worthwhile trying not to clutter it up too much.
cheers, Greg
i would also think it would be possible to have two different straight
recipes -- one for "org-mode", and one for "org-mode-test" -- which you
would enable or disable (by editing .emacs, if no other way) on
different invocations of emacs. and, be careful not to have both
enabled at the same time!
Ihor,
thanks for this.
one additional item (i don't *think* we discussed this before; apologies
if i'm forgetting): tangling. if one is prompted to "merely" tangle ...
#+begin_src sh :tangle /var/tmp/foo.org.tangled
echo 'hi!'
#+end_src
one could imagine more sinister scenarios for
Ihor, Bastien, et al.,
i am not really following this conversation.
but, recently i was looking at org-grep, and found its new home:
https://github.com/emacsorphanage/org-grep
Ihor mentions the emacs orphange:
> Should we extend the org-contrib's current idea to other Org-related
> pac
Ypo,
> Do you think that if I install a Linux OS, Orgmode would run fast? Any
> OS suggestion?
it might (*). if it's not too hard to install linux (i have no idea), you
might figure out some sort of benchmark for your org experience, then
try switching, see what happens. (there are a lot of var
Tom,
> The only generalized solution is to record the full location (see
> intro to http://naggum.no/lugm-time.html which I'm surprised hasn't
> been linked in this thread yet, ...
very nice -- thanks for the pointer!
cheers, Greg
Ihor, Sterling, et al.,
just a thought/reminder. there are "semantics" and "encoding". a spec
like ISO-8601 specifies both. the important thing for org-mode is to
use an encoding that
1. is easily parsable/understandable by the mere mortal
2. allows expression of all the semantics of the unde
Ihor,
> Cons:
>
> 1. If compat.el happens to lack support of some function, we will need
>to contribute to compat.el directly and synchronize Org releases with
>compat.el releases.
would a separate "org-compat.el" (in addition to compat.el) somehow
solve this? (i worry about the synch'i
Ihor,
> That's all nice but what a headache will it be to implement. What will
> 2004-06~ mean for agenda, for example?
i don't know the specific "2004-06~", but i do think that for the agenda
(i assume), being able to express ambiguity to the user will be
important. as people have pointed out (
Ihor, makes sense. that we probably need to *display* imprecision
doesn't mean we need to accept/parse it.
Ihor,
> >> 1. If compat.el happens to lack support of some function, we will need
> >>to contribute to compat.el directly and synchronize Org releases with
> >>compat.el releases.
> >
> > would a separate "org-compat.el" (in addition to compat.el) somehow
> > solve this? (i worry about th
Ihor,
thanks for all the information.
> 2022-11-12 12:00 @Asia/Singapore # tzdb syntax
aesthetically, allowing a space after the "@" sign might be nice. i
don't know what that would do to the parsing/BNF/whatever.
cheers, Greg
thanks, Tomas and Ihor,
> > [2022-11-12 12:00 @Asia/Singapore] vs. [2022-11-12 12:00 @ Asia/Singapore]
> >
> > Either way is possible.
> > I am in favour of my variant though :)
>
> Same with me. I read @ as a sigil [1]
...
> [1] https://en.wikipedia.org/wiki/Sigil_(computer_programming)
i'll t
Jean Louis,
> Why did mailing list accept message from far future? It should not be
> so, that is bug to be reported.
there's an old internet adage to help achieve interoperability
(attributed to the late Jon Postel): be liberal in what you accept, and
conservative in what you send.
so, i wouldn
Jean Louis,
> In my opinion central computer that manages mailing lists should
> recogniz if time of users is far in future and handle it
> appropriately.
> Maybe re-writing time with explanation in e-mail header would be more
> appropriate.
maybe something like that. though, this seems more an
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.
Ihor,
> You are on a fairly old common from main - 5 month old.
> May you upgrade to the latest main and let us know if you keep seeing
> problems?
thanks. i've re-freshed and re-built and am now on
Org mode version 9.7-pre (release_9.6.26-1368-g1ae978 @
/home/minshall/.emacs.d/straight/b
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.
--
hi, Ihor,
thanks for looking at this.
> This is because Org mode currently cannot distinguish between babel
> backends that simply do not support variable assignments and babel
> backends that are not loaded.
currently, is it possible to see well enough what is going on to
generate an error and
Ihor,
thanks again.
> #+property: header-args :var common_variable = "foo"
ah, hierarchical :var's. i didn't realize such existed. of course,
then, you're right.
a dream might be something like ":var none" to allow the dot source code
block to indicate it wasn't expecting any ":var" anyway.
Ihor,
> > or some such to disable *that*?
>
> I do not recall many people asking for such a feature.
no, i don't either. :)
> It might be. But the real fix should be adding babel API to allow
> backends declaring the list of supported features.
> Such API is relatively easy to implement.
with
Ihor,
> Then, if the backend does not define variable expansion method, do
> nothing. If the backend is not loaded, throw an error/warning (maybe
> depending on a customization).
great. thanks. if customizable, i'd vote to default with an error.
then, for what it's worth, my experience led me
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.
Ihor,
> In theory, the odds should be quite slim, unless you open that file
> manually. Anyway...
as the saying goes, the difference between theory and practice is that
in theory there is no difference, but in practice there is. :)
> Does the attached patch fix the problem for you?
i've applie
hi, Ihor,
i have a recurrence of the same problem. see below.
cheers, Greg
Subject: [BUG] still fails... [9.7-pre (release_9.6.29-1441-gaa71fa @
/home/minshall/.emacs.d/straight/build/org/)]
Fcc: outbox
X-Mailer: MH-E 8.6+git; nmh 1.8; Emacs 30.0.50
> ...rg-persist/gc-lock.eld
hi, Ihor,
> Then, I need a backtrace. May you please enable debug-on-error and share it?
here is a backtrace. is this enough, or should i do something extra to
give you more information from it?
the situation was: "it" put up the message
...rg-persist/gc-lock.eld locked by minshall@arch..
Ihor,
> May you try the attached alternative patch?
thanks, will do.
cheers, Greg
Ignore lock files when writing cache
>
> * lisp/org-persist.el (org-persist--write-elisp-file): Ignore locks.
>
> Reported-by: Greg Minshall
> Link: https://orgmode.org/list/574109.1715751441@archlinux
> ---
> lisp/org-persist.el | 15 +--
> 1 file change
Ihor,
> Fixed, on main.
> I used a slightly different patch, because `always' is not available in
> Emacs 27.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=dc485a659
thanks!
cheers, 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 people
Timothy,
> This is a quick patch to use the Emacs manual CSS with our generated Org
> manual.
that's certainly visually pleasing. nice!
Greg
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 mak
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 mentioning
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 wh
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
> 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!
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
>
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:
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 (cus
apologies. (org-babel-do-load-languages) (rtfm!) is what i was lacking.
(progn
(org-babel-do-load-languages
'org-babel-load-languages
'((shell . t))
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
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 which
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 li
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
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 manua
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 the
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 l
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'
> startin
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 intro
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
|
Malcolm, thanks, and, yes, i'm of mixed mind, myself. cheers, 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, includin
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
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 t
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 don'
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 something
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 b
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 r
> 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
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 the
uot; :follow #[257 "\301\300\302Q!\207" ["ftp"
browse-url ":"] 5 "\n\n(fn 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,
> 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
> varia
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 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!
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
---
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 default
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
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
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
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
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 external
nd_export
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 e
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.
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 [:resu
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
"exporti
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,
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, publis
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
Michael,
i see "Hello" when i C-c C-c. i see this with "emacs -Q".
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"
>
>
William,
try
#+begin_src shell :results output :var n=numbers
echo ${n[1]}
#+end_src
cheers, Greg
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 time
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
>
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 arrayp
201 - 300 of 393 matches
Mail list logo
