Re: Still errors with Emacs 26.3
On 16/08/2021 11:49, Axel Kielhorn wrote: Thanks for fixing the errors in org cite. I hope, what you report about are no more than warnings, not errors. Compiling /Users/axel/src/Emacs/org-mode/lisp/org-agenda.el... In end of data: org-agenda.el:10873:1:Warning: the function ‘string-empty-p’ is not known to be defined. A patch for this particular issue: https://orgmode.org/list/seeb8h$364$1...@ciao.gmane.io Unfortunately it is not tracked at https://updates.orgmode.org/ for some unclear reason. Compiling /Users/axel/src/Emacs/org-mode/lisp/org-plot.el... In org-plot/gnuplot: org-plot.el:634:4:Warning: ‘(dump-func (plist-get type :data-dump))’ is a malformed function org-plot.el:685:17:Warning: reference to free variable ‘dump-func’ Try "make single" to get even more warnings...
Re: Smart quotes for Greek (questions for a possible patch)
Hi Michalis. Thank you for your comments. mvar writes: > i can confirm the «» characters are the proper ones for the first level > of quoting..Now about second level, personally i haven't seen such nesting in > ages but IIRC they should be the ones (or *very* similar) in the linked image > you posted -> > \textquotedblleft and \textquotedblright. I've no idea how these > translate to UTF. Note that the standard greek keyboards & keymaps do not have > any of these characters mapped by default (not even «» ), most people use the > standard > english double/single quotes, at least in electronic writing (articles, > daily communication etc). > Protesilaos (cc) might have a better view on this matter. Yes, I think \textquotedblleft and \textquotedblright could be a good solution. Those are the first level quotes for English and other languages, and the second level quotes for Spanish, so in this case the Spanish settings in `org-export-smart-quotes-alist' could be copied for Greek. In Unicode they are equivalent to “ LEFT DOUBLE QUOTATION MARK U+201C and ” RIGHT DOUBLE QUOTATION MARK U+201D In fact, the second quotes, U+201D, would be the correct ones for Greek (always, according to Haralambous). The only difference is for the opening quotes: in this case Greek would use (again, according to Haralambous) the character U+201F: ‟ (DOUBLE HIGH-REVERSED-9 QUOTATION MARK), which is like the U+201C char, but upside down. In LuaTeX and XeTeX (and in HTML) there is no problem to represent that character, because these two TeX engines are based on Unicode. The problem would be the backward compatibility with pdfTeX. I haven't managed to get this character in pdfTeX using inputenc with the utf8 option. Therefore, we could leave for the second-level quotation marks the tandem U+201C/201D, as the lesser evil. Let's see what Protesilaos thinks. Best regards, Juan Manuel
Re: Bug: :session results in unfriendly error reporting
James, > On Aug 15, 2021, at 4:41 PM, James Powell wrote: > > I write a deliberate syntax error into a code block: > > : #+begin_src R :session > : x <- 1 > : y xx z > : #+end_src > > I put my cursor in there and C-c C-c. > > What I expect: a gentle useful report about the error. Right. But there is no error as far as babel is concerned. R has handled the condition. So there is nothing for babel to see/do. > Maybe even org would move the cursor to the point of the > error in the org buffer. If not, at least the buffer > "*Org-Babel Error Output*" will open and show me the error, > something like this (see also [1]), > > : Error: unexpected symbol in: > : "x <- 1 > : y xx" > : -UUU:@**--F2 *Org-Babel Error Output* All L17(Compilation etu) > 4:13PM 0.53 Mail --$ > `:results output' might help you here, since it will send the terminal output back to babel. If that doesn't suffice, you might use handlers provided by R to find your way out. But I think that will get sticky as what you create in your example is a parse error. If the source blocks are eval'ed as part of an export, you have the option of exporting via ox-ravel[*] and using the knitr chunk options to handle errors in the way you want. > What happens instead: > > - the *R* buffer is displayed. It contains a long spammy traceback > that has run off of the top of the screen. To learn more I have to > move the cursor into the *R* buffer and page back to the top of the > traceback. > > On the other hand, if I set ":session none", I get much friendlier > behavior. The Error Output buffer opens with the simple error message > in it as I showed above when I use this source block: > > : #+begin_src R :session none > : x <- 1 > : y xx z > : #+end_src > Running R in this fashion starts a fresh process which signals an error that babel can handle. I see no easy way to get sessions to sends signals that babel can process. > I do not want to abandon :session because my code reads in a lot of > data to get started and I want my scripts, not my environment to be > "real" so I am not depending on R's ability to save and reload the > workspace at all [2] or on "Org's (clever and useful but) somewhat clunky > and inflexible method of passing data explicitly" [3]. One of the motivating factors for creating ox-ravel[*] was to have flexible caching of R objects. This is provided in knitr, Sweave, and similar report generators. For interactive use, knit-ing a document that has caching enabled at the start of a session is a fast and painless way to get all the objects needed to modify a document. HRH, Chuck [*] https://github.com/chasberry/orgmode-accessories > > Is there a way to get back to the "Error Output" buffer opening with a > simple message /while/ having :session being enabled? > > thank you, > James P. > > References > > [1] "Currently the only action Babel takes with STDERR is to display it in a > pop-up buffer when code block evaluation fails" (Eric Schulte in 2012, at > https://lists.gnu.org/archive/html/emacs-orgmode/2012-03/msg00057.html). > > [2] « what will you save as your lasting record of what happened? > [...[ As a beginning R user, it's OK to consider your environment > [...] "real." However, in the long run, you'll be much better off > if you consider your R scripts as "real." » (p. 111, Wickham, H. "R > for data science : import, tidy, transform, visualize, and model > data" O'Reilly Media, 2016). To facilitate this, I have disabled > 'save workspace' permanently: > : q <- function (save = "no", status = 0, runLast = TRUE) > : .Internal(quit(save, status, runLast)) > > [3] «When I look at Org and think of "session-based" blocks, I see a > potential big benefit in having multiple source-blocks throughout > my document share the same session» > (https://lists.gnu.org/archive/html/emacs-orgmode/2011-06/msg00654.html, > the only good hit for a search for "session Org-Babel Error Output" at > https://lists.gnu.org/archive/html/emacs-orgmode/ as of > [2021-08-15 Sun]). > > > -- > James E. Powell, MS > Pronouns: he/him/his > Applied Physics PhD Candidate > Department of Physics > Portland State University > Home page: http://web.pdx.edu/~powellj > Office: SRTC 409B Phone: +1-503-725-8515 > > >
Build agenda asynchronously
There was a question on Stack-Exchange if it would be possible to build *org-agenda* asynchronously. I could not quickly find any good answers neither in the mailing lists nor anywhere else. As I assume this will be a quite helpful feature for some more users, I am notifying you about it here. The question with its answer can be found at https://emacs.stackexchange.com/questions/68123/async-org-agenda/68136#68136 Cheers, Daniel
Re: Build agenda asynchronously
Emacs' support for asynchronous operations is at best primitive. There is built-in support for calling processes asynchonously and there is some other development work to set the stage for adding threads, but I think general asynchronous processing inside Emacs is a long way off. A lot of how Emacs lisp works fundamentally lacks the low level control structures necessary to make data structures and operations on those structures thread safe. This means you have to work at a very low level in order to ensure code is thread safe and that simply isn't practical. Even defining the basic model for an asynchronous emacs lisp is non-trivial and once you have the model, you ahve to implement it. At this time, this is a non-starter. It would be a mistake to expect asynchronous processing within Emacs lisp any time soon. Best we can hope for now is asynchronous execution of external processes and even that falls apart as soon as user input needs to be factored in. dalanicolai writes: > There was a question on Stack-Exchange if it would be possible to build > *org-agenda* asynchronously. I could not quickly find > any good answers neither in the mailing lists nor anywhere else. > > As I assume this will be a quite helpful feature for some more users, I am > notifying you about it here. > > The question with its answer can be found at > https://emacs.stackexchange.com/questions/68123/async-org-agenda/68136#68136 > > Cheers, > Daniel
Internal link broken when publishing (was org-id with ox-html)
I've done a lot of investigation. I totally agree with internal links not being stable through publishing: `3c5997f1-205a-437e-8722-d5f52239a207` => `"bye.org#orgfa9c151"` I totally agree with what Nicolas Goaziou says there: https://lists.gnu.org/archive/html/emacs-orgmode/2021-05/msg01254.html However, I do have an _internal link_ in the form: `[[id:3c5997f1-205a-437e-8722-d5f52239a207][bye]]` (This link is not hand made at all, it is the result of: `org-id-get-create` `org-store-link` `org-insert-link`.) Which is translated into: `bye` But no target of the corresponding form is created, and that somewhat in accordance with the cited post above. But it breaks the link. As I understand it, in accordance with the cited post, the internal link should be "interpreted" as: `bye` (from: `[[id:3c5997f1-205a-437e-8722-d5f52239a207][bye]]`). For that, there should be some "translation table": `3c5997f1-205a-437e-8722-d5f52239a207 => bye.org#orgfa9c151` (there might already such translation table somewhere). (Actually it is `cache`, in https://github.com/emacsmirror/org/blob/master/lisp/ox.el#L4442) The obvious workaround would be to use `CUSTOM_ID`, which is stable through publishing. But it's not at all a functionality I'm looking for. I've thought of a function using `org-map-entries`, creating a `:CUSTOM_ID:` as a duplicate of `:ID:` everywhere, creating the `:ID:` if necessary. Always using `org-id-get-create`. But maybe there is an _obvious way_ to have it working out of the box. Here is a minimal example: ## file: hello.org * hello :PROPERTIES: :ID: e54113f9-2ad7-4a86-94be-68ffc696de0b :END: [[id:3c5997f1-205a-437e-8722-d5f52239a207][bye]] ## file: bye.org * bye :PROPERTIES: :ID: 3c5997f1-205a-437e-8722-d5f52239a207 :END: Thanks, Chris P.S. I'm pretty sure the minimal example above can work right out of the box with someone, who unlike me, knows how to correctly configure the publishing. However, I mention two other leads, the first one I prefer by far: (to be honest this first one it is not about internal links not breaking at publishing time, which was a "given", but to form more "meaningful" publishing id) 1. Suggestions have been made by Nicolas Goaziou to look in the direction of `org-export-get-reference` (at the level of the "translation table"?) https://github.com/emacsmirror/org/blob/master/lisp/ox.el#L4443 2. Another suggestion is from org-roam https://github.com/org-roam/org-roam/wiki/Hitchhiker's-Rough-Guide-to-Org-roam-V2#export https://gist.github.com/jethrokuan/d6f80caaec7f49dedffac7c4fe41d132
Re: Bug: :session results in unfriendly error reporting
Charles,
being sympathetic with the idea of better error reporting, i'm curious
about the following.
> Right. But there is no error as far as babel is concerned. R has
> handled the condition. So there is nothing for babel to see/do.
...
> Running R in this fashion starts a fresh process which signals an
> error that babel can handle. I see no easy way to get sessions to
> sends signals that babel can process.
what is going on here? is the issue that in the no-session case, the R
process exits with a non-zero exit code, and that is how "babel" picks
up on it?
i put "babel" in quotes ("\"babel\"" :) above, because, in my simple
mind, babel isn't just the main bit that runs inside org/emacs, but also
some glue bits that run in the various languages' environments. things
like initializing variables, and harvesting results. so, might one not
argue that checking execution status, in a session environment, could
also be part of babel?
cheers, Greg
Re: Bug: invalid example for org-export-define-backend's :menu-entry argument [9.4.4 (release_9.4.4 @ /usr/local/share/emacs/28.0.50/lisp/org/)]
Awesome, thank you! :) On Sat, Aug 7, 2021 at 4:15 PM Nicolas Goaziou wrote: > Hello, > > Zachary Kanfer writes: > > > Ox.el contains the function org-export-define-backend. One of its > > keyword arguments is :menu-entry. The examples given include > > (https://code.orgmode.org/bzg/org-mode/src/master/lisp/ox.el#L1214) > > > > '(?l "Export to LaTeX" > > (?p "As PDF file" org-latex-export-to-pdf) > > (?o "As PDF file and open" > > (lambda (a s v b) > >(if a (org-latex-export-to-pdf t s v b) > > (org-open-file > > (org-latex-export-to-pdf nil s v b)) > > > > This is invalid for two reasons: > > > > 1. The ?p and ?o elements should be wrapped in an extra layer of > > parentheses. For example, the ?p element should be ((?p "As PDF file" > > org-latex-export-to-pdf)). > > 2. There is an extra parenthesis at the end of the block. > > Fixed. Thank you. > > Regards, > -- > Nicolas Goaziou >
Re: Bug: :session results in unfriendly error reporting
Greg Minshall writes:
> Charles,
>
> being sympathetic with the idea of better error reporting, i'm curious
> about the following.
>
>> Right. But there is no error as far as babel is concerned. R has
>> handled the condition. So there is nothing for babel to see/do.
> ...
>> Running R in this fashion starts a fresh process which signals an
>> error that babel can handle. I see no easy way to get sessions to
>> sends signals that babel can process.
>
> what is going on here? is the issue that in the no-session case, the R
> process exits with a non-zero exit code, and that is how "babel" picks
> up on it?
>
> i put "babel" in quotes ("\"babel\"" :) above, because, in my simple
> mind, babel isn't just the main bit that runs inside org/emacs, but also
> some glue bits that run in the various languages' environments. things
> like initializing variables, and harvesting results. so, might one not
> argue that checking execution status, in a session environment, could
> also be part of babel?
>
I think what Charles is talking about is that with a session, the state
of the session and what it returns is not necessarily anything to do
with what has occured in the code which was executed in the session.
Think of the session as a basic REPL. It reads and expression, tries to
parse and evaluate it, 'prints' out the result and then waits for the
next expression.
Whenn you don't have a session, you just have a basic interpreter. It
reads the input, parses and tries to execute it and either returns what
the successful execution returns or returns some form of error when
something goes wrong. It exits while the session doesn't (yet).
Dealing with errors in the interpreter case is much easier. Dealing with
them in a session is not because the session has not ended and the whole
idea of the session is to manage such things and get ready for the next thing.
The session only ends once all blocks have been processed. What happens
when you add another block at the end of the org file which is to use
the same session - it has to still be running or you have to evaluate
all the blocks again.
Yes, you could add session variables and use them to track error states
etc. But that would be something each separate language would have to do
and the ability to capture that information for different languages
probably varies.
It isn't so much that nothing is possible but rather nobody has
implemented a consistent model which can be adopted and has been
implemented by all backends. This is why I consider this to be a feature
request and not a bug report. This is not expected/defined behaviour
which is not behaving according to spec - this is new unimplemented
behaviour, a new feature which needs to be designed and implemented
across all backends.
This would be a good feature to have. The work is non-trivial and would
take significant time to implement.
Re: Build agenda asynchronously
Tim Cross writes: > Emacs' support for asynchronous operations is at best primitive. There > is built-in support for calling processes asynchonously and > there is some other development work to set the stage for adding threads, > but I think general asynchronous processing inside Emacs is a long way > off. A lot of how Emacs lisp works fundamentally lacks the low level > control structures necessary to make data structures and operations on > those structures thread safe. This means you have to work at a very low > level in order to ensure code is thread safe and that simply isn't > practical. Even defining the basic model for an asynchronous emacs lisp > is non-trivial and once you have the model, you ahve to implement it. Maybe it could be possible to fire up a second Emacs and retrieve the agenda-buffer? Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken signature.asc Description: PGP signature
