Re: Build agenda asynchronously
Den ons 18 aug. 2021 kl 02:17 skrev Tim Cross : > > Milan Zamazal writes: > > Actually, that one has been on my todo list to cehck out for a while. > Might be time to bump the priority a bit! > > I just started using it and it works really well so far!
Re: Build agenda asynchronously
Den tis 17 aug. 2021 kl 08:54 skrev Dr. Arne Babenhauserheide < arne_...@web.de>: > > 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? > > This is what I do for commands like exporting the agenda which can take a while with the -nw flag, but that is of course unsatisfactory for most use cases. /Henrik
Re: Build agenda asynchronously
Milan Zamazal writes: >> "TC" == Tim Cross writes: > > TC> Personally, I took a different route. I keep the number of files > TC> which contribute to my agenda to a minimum and have an easy way > TC> to update/change that list. I can quickly switch agenda contexts > TC> depending on what I'm doing. > > It’s always advisable to restrict agenda sources to what’s actually > relevant. But besides that, all my problems with agenda slowness were > resolved once I started to use org-super-agenda > (https://github.com/alphapapa/org-super-agenda). It’s both more > powerful and much faster than the standard Org agenda. > Actually, that one has been on my todo list to cehck out for a while. Might be time to bump the priority a bit!
[PATCH] ox-ascii.el: Fix justify when `indent-tabs-mode' is non-nil
* lisp/ox-ascii.el (org-ascii--justify-lines): Ensure that `indent-tabs-mode' is nil when applying indentation to justify lines. This prevents tab characters from appearing in the export when `indent-tabs-mode' still has its default value of t. TINYCHANGE --- Hi, I've attached a patch to fix an issue where tab characters are generated by the ASCII exporter when `indent-tabs-mode' has its default value of t. Here is a simple test case which generates tabs with 'emacs -Q': (with-temp-buffer (insert "#+TITLE: My Title\n" "#+OPTIONS: author:nil\n" "#+OPTIONS: toc:nil\n") (org-mode) (org-ascii-export-as-ascii) (with-current-buffer "*Org ASCII Export*" (buffer-string))) I haven't gone through the FSF copyright assignment process but I'm assuming this is OK based on the line count. Thanks, Morgan lisp/ox-ascii.el | 3 +++ 1 file changed, 3 insertions(+) diff --git a/lisp/ox-ascii.el b/lisp/ox-ascii.el index d1762d41c..176542661 100644 --- a/lisp/ox-ascii.el +++ b/lisp/ox-ascii.el @@ -480,6 +480,9 @@ HOW determines the type of justification: it can be `left', (insert s) (goto-char (point-min)) (let ((fill-column text-width) + ;; Ensure that `indent-tabs-mode' is nil so that indentation + ;; will always be achieved using spaces rather than tabs. + (indent-tabs-mode nil) ;; Disable `adaptive-fill-mode' so it doesn't prevent ;; filling lines matching `adaptive-fill-regexp'. (adaptive-fill-mode nil)) -- 2.30.2
Re: return column from table as a column
Hello, Maxim Nikulin writes: > Notice that you can get vertical representation of results as a list > #+begin_src emacs-lisp :results list > > The following is a variation of a recipe suggested by Juan Manuel: > > #+name: to-column > #+begin_src emacs-lisp :var lst=() >(mapcar #'list lst) > #+end_src > > #+begin_src emacs-lisp :var data=s1[,3] :post to-column(lst=*this*) >data > #+end_src > > To transform more than one column, the following idea may be useful > > (defun rotate (list-of-lists) >(apply #'mapcar #'list list-of-lists)) > > https://stackoverflow.com/questions/3513128/transposing-lists-in-common-lisp Thank you very much. I should really make the effort to re-learn e-lisp. Not having written anything in it for 10+ years has eroded my abilities. Best wishes, Roger
Re: Build agenda asynchronously
> "TC" == Tim Cross writes: TC> Personally, I took a different route. I keep the number of files TC> which contribute to my agenda to a minimum and have an easy way TC> to update/change that list. I can quickly switch agenda contexts TC> depending on what I'm doing. It’s always advisable to restrict agenda sources to what’s actually relevant. But besides that, all my problems with agenda slowness were resolved once I started to use org-super-agenda (https://github.com/alphapapa/org-super-agenda). It’s both more powerful and much faster than the standard Org agenda. Regards, Milan
Re: Build agenda asynchronously
"Dr. Arne Babenhauserheide" writes: > [[PGP Signed Part:Undecided]] > > 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? > Yes, I've seen people who have done things like that. They have their 'main' emacs instance running where they 'do stuff' and another instance running where they read mail, check their agenda/calendar or run other things which tend to 'block'. There are some issues with this approach though. Some of which are not obvious. - Emacs can consume a fair amount of memory. Running multiple instances can use a fair amount of memory. - Startup times make it less appealing as a 'run it up when you need it' solution. - You need to have an understanding of the interaction with various cache and other disk files Emacs uses to ensure each instance doesn't tread on the toes of the other. - A 'strategy' with regards to reverting buffers to file contents. Consider adding a todo in your agenda while at the same time, working on a related org file in the other instance. Provided you know the rules, can operate in an understood disciplined manner and have a system with sufficient resources, it certainly can be a viable approach. Personally, I took a different route. I keep the number of files which contribute to my agenda to a minimum and have an easy way to update/change that list. I can quickly switch agenda contexts depending on what I'm doing. For example, when I'm at work, I'm not interested in any of my 'home' tasks, events, etc. As a result, generation of various agenda views is fast and I don't need to wait. I do have an 'everything' context, so when I do need that, I can get a complete overview. It does take longer to generate and will block, but I rarely need it. My calendar.org file, which contains all my meetings is shared across all views so that I avoid 'double booking'. I do tend to put all meetings in Google calendar because it makes it easy to share them with other devices (tablet, phone, laptop, other people), but I use my icsorg script to import that into my calendar.org file.
Re: Bug: :session results in unfriendly error reporting
Tim, thanks. > 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. yes, i agree this is really a feature request. in general, as far as i can see, consistency across languages "at the fringes", is pretty much "a work in progress" (or not, as the case might be). if there is ever the chance to detect and propagate errors in :session, that would be great. (and, again "in general", trying to reduce the [reducible] gap between non- and :session, across languages, would be a nice goal.) cheers, Greg
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
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: 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 >
