Re: Bug: org-babel-execute:emacs-lisp does not allow changing window configuration from within code block [9.3 (release_9.3 @ /home/yantar92/.emacs.d/straight/build/org/)]
Hi Ihor, sorry for the late reply. Ihor Radchenko writes: > I still can reproduce the bug, following the recipe. OK, fixed in master as 81d49b5ad now. Thanks, -- Bastien
Re: Bug: org-block face isn't applied to special blocks
Hi Sébastien Sébastien Miquel writes: > Hi Bastien, > > With latest org-mode master, and emacs -q, > run (defface org-block '((t (:background "#494949" :extend t))) "") > before loading org-mode, > then visit an org buffer containing the three following blocks. > > When I do so, the org-block face only gets applied to the src block, and > not to the quote block, nor the special block. Fixed in maint, as 7769518f3. Thanks for the report again, -- Bastien
org-tempo insertion incoherence (lack of indentation) or misunderstanding
Let us imagine this simple org file : #+NAME: first #+begin_src org - an item - subitem #+end_src If the cursor is at the last line and I want to insert an org block, let's say an example, using org-tempo feature, I can type =>. Any help would appreciated. I use GNU Emacs 26.3 from Debian GNU bullseye (testing) and what I think is the last org-mode version from ELPA. #+begin_src Org mode version 9.3.7 (9.3.7-55-gba2405-elpa @ /home/bruno/.emacs.d/elpa/org-20200907/) #+end_src -- Bruno BEAUFILS signature.asc Description: PGP signature
Re: Bug: Appointments duration and effort sums in agenda column view [9.3.7 (release_9.3.7-700-ga1e5be @ ~/.emacs.d/straight/build/org/)]
Dear Stanislav, thanks for reporting this, I confirm the bug. I shared a note on the SO entry asking for a patch: since the solution is mostly written, it would help if a patch could be sent to this mailing list directly. See https://orgmode.org/worg/org-contribute.html on how to contribute. Thanks! -- Bastien
Re: [PATCH] Re: Re: Re: org-forward-heading-same-level and the invisible-ok argument
Hi, D writes: >> Does it fix a problem for org-superstar-mode or a more general problem >> in Org? > > It mostly fixes an org-superstar-mode problem (see > https://github.com/integral-dw/org-superstar-mode/issues/19). Can you try the attached patch and tell wether it fixes your issue? >> If you use seq* functions, the code will be incompatible with previous >> emacsen, right? > > Hmm, looking at the oldest available ELPA release (seq-1.0, 2015), > seq-every-p should be fully backwards-compatible. The current package > itself also has a fallback option for Emacs versions <25, so that should > be fine. I'd rather not add a dependency over seq.el anyway. Thanks, -- Bastien diff --git a/lisp/org.el b/lisp/org.el index a5c7dcf3b..f6e04e65c 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -20529,7 +20529,7 @@ non-nil it will also look at invisible ones." ((and (= l level) (or invisible-ok (not (org-invisible-p - (line-beginning-position) + (1- (line-end-position)) (cl-decf count) (when (= l level) (setq result (point))) (goto-char result))
Re: [FEATURE REQUEST] No tangle of code blocks within archived subtrees
Thanks Tom for the feedback. >> - org-babel-exp-process-buffer > Yes >> - org-babel-ref-resolve > Probably not? >> - org-babel-expand-noweb-references > Probably not? I've done this in master now, see 9f0af69dd2. Best, -- Bastien
Re: Bug: Babel+R handles spaces wrongly in tables [9.3.6 (release_9.3.6 @ /home/cassou/.emacs.d/lib/org/lisp/)]
Bastien writes: > I'm just confirming this bug with X-Woof-Bug: confirmed so that it > appears on https://updates.orgmode.org. Of course, the first time I mention "X-Woof-Bug: confirmed" in the body of the email, I forgot to add it as a mail header. -- Bastien
Re: Bug: Babel+R handles spaces wrongly in tables [9.3.6 (release_9.3.6 @ /home/cassou/.emacs.d/lib/org/lisp/)]
Hi Charles, "Berry, Charles" via "General discussions about Org-mode." writes: > Here is another ECM that illustrates the bug: I'm just confirming this bug with X-Woof-Bug: confirmed so that it appears on https://updates.orgmode.org. Best, -- Bastien
Re: Bug: issue with babel and sqlite [9.3 (release_9.3 @ /usr/share/emacs/27.0.91/lisp/org/)]
andrés ramírez writes: > Hi Bastien. Thanks for fixing this. Okay, thanks for confirming! -- Bastien
Re: org-babel prepends <> expansions with the prefix of the <>? Can this be turned off?
Hi Vladimir, Vladimir Nikishkin writes: > That's not entirely what I want. What do you want instead? It's not clear to me from your example. Thanks, -- Bastien
Re: org-babel opens the error output of a block in a separate window... unless :stdin is given, but how are they connected?
Hi Vladimir, Vladimir Nikishkin writes: > #+name: empty > #+begin_quote > > 1 > #+end_quote > > #+begin_src shell :shebang "#! /usr/bin/chibi-scheme :stdin empty > (/ 1 0) > #+end_src The example above does not work for me. Can you provide another one? > Now the chibi-scheme shebang is just an example of an app writing > things to stderr. The actual content of the <> doesn't matter, > the app errs before ever having a chance to read anything from stdin. > > However, when :stdin is given (as in the MWE), the resulting error > output is printed in the :RESULTS , and if not, it is displayed in a > separate (a bit annoying) window called "*Org-Babel Error Output*. > > I would like to ask how these two things, stdin, and stderr are > connected. Perhaps, this is a bug? I don't know but perhaps you can instrument the relevant functions in ob-shell.el and see what going on, if you still have this issue? Thanks, -- Bastien
Re: Adaptive Org faces in headings?
Hello Diego, Diego Zamboni [2020-09-05, 23:39 +0200]: > I had seen the same in my setup. I recently started using Doom Emacs > (https://github.com/hlissner/doom-emacs/) and was pleasantly surprised > to discover that todo and tag faces scale according to the headline in > which they are. I don't know precisely how this is done, but there are > some hints here, you might use it as a starting point: > https://github.com/hlissner/doom-emacs/blob/develop/modules/lang/org/config.el#L146-L175 I noticed that the doom-themes have some extra code to fontify Org.[0] It also has some opinionated extras that do not belong to the issue I raised. I am curious whether this was ever shared/discussed on this mailing list. It does not seem specific to Doom, so it be nice to have it for the benefit of every user mutatis mutandis. [0]: https://github.com/hlissner/emacs-doom-themes/blob/master/doom-themes-ext-org.el -- Protesilaos Stavrou protesilaos.com
Re: Bug: issue with babel and sqlite [9.3 (release_9.3 @ /usr/share/emacs/27.0.91/lisp/org/)]
Hi Bastien. Thanks for fixing this. > "Bastien" == Bastien writes: [...] Bastien> Can you instrument the `org-babel-read' function? I have done. But It has not failed with 27.1. Bastien> You can do this with C-h f org-babel-read RET and then C-u C-M-x on the function's Bastien> definition. Best Regards
Re: Improving org-contacts performance (and state of development in general)
Primary examples would be adding a note (CTRL-z) or changing a tag on a person and then having org-agenda update that. I am assuming it is because the entire file needs to be parsed rather than say, some index of entries. (so perhaps I mischaracterized org-contacts as being slow versus its interaction with other programs.) (for search I use swiper which is very efficient for searching the file whenI need it.). tho quite interested in seeing what perf enhancements you've done on large org files would be interesting. Daryl. PS> As an outside feature though, interoperability of the org-contact formats with other operating system address books, most notable gnome contacts/evolution, goog contacts, and OSX address book would be high on my list in terms of improving org-contacts though. (eg, raw, structued info in all address books, and say perhaps notes or similar maintained and synced in ome manner. On Mon, Sep 7, 2020 at 10:27 AM Ihor Radchenko wrote: > > However, as the file and C-z notes have grown, > > performance has really started to drag. I know people have used various > > schemes (caching) etc to try to improve performance and the like, but > > updates to the file are taking a solid 5 seconds now when making major > > updates and moving tags around. > > Could you provide some examples what exactly is being slow? > Maybe my WIP work on improving performance on large org files [1] might > help. > > Best, > Ihor > > [1] https://www.mail-archive.com/emacs-orgmode@gnu.org/msg127740.html > > > Daryl Manning writes: > > > Strangely, I've come to rely over the last year on org-contacts as a > > lightweight, taggable CRM. However, as the file and C-z notes have grown, > > performance has really started to drag. I know people have used various > > schemes (caching) etc to try to improve performance and the like, but > > updates to the file are taking a solid 5 seconds now when making major > > updates and moving tags around. > > > > Is there a solid, forked branch anywhere that focuses on enhancing > > performance anywhere? I'm tempted to wade in and add features and > > improvements myself but my elisp-fu is dodgy at best (more golang these > > days.). > > > > I'd be interested in what people are doing to speed it up (and if it is > > under anything like active development for improvements. It does feel > super > > handy, and feels like it just needs a performance and more modern > features > > overhaul - more on interoperability and less on in-emacs > interoperability.). > > > > Would love to hear what people have done overall workflow wise if they > are > > using it seriously. > > > > thanks, > > Daryl. >
Re: Improving org-contacts performance (and state of development in general)
> However, as the file and C-z notes have grown, > performance has really started to drag. I know people have used various > schemes (caching) etc to try to improve performance and the like, but > updates to the file are taking a solid 5 seconds now when making major > updates and moving tags around. Could you provide some examples what exactly is being slow? Maybe my WIP work on improving performance on large org files [1] might help. Best, Ihor [1] https://www.mail-archive.com/emacs-orgmode@gnu.org/msg127740.html Daryl Manning writes: > Strangely, I've come to rely over the last year on org-contacts as a > lightweight, taggable CRM. However, as the file and C-z notes have grown, > performance has really started to drag. I know people have used various > schemes (caching) etc to try to improve performance and the like, but > updates to the file are taking a solid 5 seconds now when making major > updates and moving tags around. > > Is there a solid, forked branch anywhere that focuses on enhancing > performance anywhere? I'm tempted to wade in and add features and > improvements myself but my elisp-fu is dodgy at best (more golang these > days.). > > I'd be interested in what people are doing to speed it up (and if it is > under anything like active development for improvements. It does feel super > handy, and feels like it just needs a performance and more modern features > overhaul - more on interoperability and less on in-emacs interoperability.). > > Would love to hear what people have done overall workflow wise if they are > using it seriously. > > thanks, > Daryl.
Re: [PATCH] Re: Export to attach directory?
Nicolas Goaziou writes: > Hello, > > Eric Abrahamsen writes: > >> Subject: [PATCH] Add EXPORT_DIRECTORY property >> >> * lisp/ox.el (org-export-output-file-name): Check for this property >> and place the exported output file there. >> * doc/org-manual.org: Document. > > Doesn't it conflict with publishing, and with EXPORT_FILE_NAME > property/keyword? In both, you can already specify an output directory. I did look at making this work with the publishing framework. The problem is that ox-publish looks like it will only do one or more files, whereas I'm trying to publish a subtree. More particularly, if there were a way to pass the PUB-DIR argument to `org-export-output-file-name', that would take care of it. But I can only export a subtree via the export dispatcher, and the export dispatcher only calls `org-*-export-to-*' functions, and all of those functions contain their own call to `org-export-output-file-name', so there's no clean way to inject PUB-DIR anywhere. You can't really wait until `org-export-as' does its general keyword gathering, either, since EXPORT_FILE_NAME and EXPORT_DIRECTORY both need to be available to `org-export-to-file'. So finding EXPORT_DIRECTORY in `org-export-output-file-name' seemed like the only option. I was imagining that EXPORT_FILE_NAME would take precedence, if it was an absolute filepath. Otherwise, the two options could be complementary. >> + (org-with-point-at (point-min) >> + (catch :found >> + (let ((case-fold-search t)) >> +(while (re-search-forward >> +"^[ \t]*#\\+EXPORT_DIRECTORY:[ \t]+\\S-" >> +nil t) >> + (let ((element (org-element-at-point))) >> +(when (eq 'keyword (org-element-type element)) >> + (throw :found >> + (org-element-property >> + :value element)) > > See `org-collect-keywords'. I don't have this function! org-version -> "9.3.7" Thanks, Eric
Re: [Some progress]
Uwe Brauer wrote/hat geschrieben on/am 06.09.2020 17:49: Uwe Brauer wrote/hat geschrieben on/am 06.09.2020 14:01: Can't answer this, because I don't use a mail buffer, but in an org-file I use C-c . to insert an active time stamp (result: <2020-09-06 So>) or C-c ! for an inactive one (result: [2020-09-06 So]) ah you use a mail (nor message) buffer when answering this message In any case I found out that (set-locale-environment "es_ES.UTF-8") inserts <2020-09-06 dom> But (set-locale-environment "de_DE.UTF-8") inserts <2020-09-06 Sun> Which is odd. I have to correct myself. My original note was that (setq calendar-day-name-array ["Sonntag" "Montag" "Dienstag" "Mittwoch" "Donnerstag" "Freitag" "Samstag"] calendar-month-name-array ["Januar" "Februar" "Maerz" "April" "Mai" "Juni" "Juli" "August" "September" "Oktober" "November" "Dezember"]) in .emacs would have an effect on date stamps. I found that this is not true. It seems to affect Org Agenda, e.g. Week-agenda (W37): Montag 7 September 2020 W37 Dienstag8 September 2020 Mittwoch9 September 2020 The names of the weekdays in date stamps seem to be unaffected by setq calendar-day-name-array. So I don't know, why they are in German at my computer. regards, Heinz
Re: [PATCH] Re: Export to attach directory?
Hello, Eric Abrahamsen writes: > Subject: [PATCH] Add EXPORT_DIRECTORY property > > * lisp/ox.el (org-export-output-file-name): Check for this property > and place the exported output file there. > * doc/org-manual.org: Document. Doesn't it conflict with publishing, and with EXPORT_FILE_NAME property/keyword? In both, you can already specify an output directory. > + (org-with-point-at (point-min) > + (catch :found > + (let ((case-fold-search t)) > + (while (re-search-forward > + "^[ \t]*#\\+EXPORT_DIRECTORY:[ \t]+\\S-" > + nil t) > + (let ((element (org-element-at-point))) > + (when (eq 'keyword (org-element-type element)) > + (throw :found > + (org-element-property > + :value element)) See `org-collect-keywords'. Regards, -- Nicolas Goaziou
Re: two test failures on maint branch
Hi Kyle, Kyle Meyer writes: > Just a heads up: with recent changes on maint, I'm seeing two test > failures: > > 2 unexpected results: >FAILED test-org-inlinetask/folding-directly-consecutive-tasks/1 >FAILED test-org/org-read-date Fixed now. The first one by fixing the test and the second one by temporarily reverting the change that broke the test. Thanks for reporting this! -- Bastien
Re: Debugging at least 2 regressions in org-mode master breaking ox-hugo
Hi Kaushal, sorry for the late reply, and thanks for the detailed report. Kaushal Modi writes: > *The regression is that earlier (org-babel--string-to-number "1,3-5") > used to return nil, but now it returns 1.* This should be fixed now in master, as of 15a6836e4, it will be in Org 9.4. Best, -- Bastien
Re: Adaptive Org faces in headings?
Hello Bastien! Bastien [2020-09-05, 16:47 +0200]: > Could you insert a small picture showing where faces customization > don't interact nicely, e.g. when using different heights for org-todo > org-level-1? Please see attached. This is on 'emacs -Q'. What I did: - C-x C-f test.org - C-x 2 - C-x b *scratch* - Insert and then evaluate each of: + (set-face-attribute 'org-level-1 nil :height 2.0) + (set-face-attribute 'org-level-2 nil :background "#e0e0e0" :height 1.5) - C-x o - Insert some headings: + * TODO [#A] This is a test :tag: + ** TODO [#A] This is a test :tag: + * [[https://www.gnu.org/][links also]] This is a test :tag: > It would help deciding whether this is an issue for Org or for > Emacs in general regarding faces interaction. The feedback I have received thus far suggests that it may have to do with how Org configures its font locking in org-set-font-lock-defaults. In particular: 1. The org-tag has an OVERRIDE argument in the form of 'prepend' https://code.orgmode.org/bzg/org-mode/src/5417e384ebab58e560fe6a80eee7bc58b1ef8645/lisp/org.el#L5625 So it is merged with the underlying face, as shown in the screenshot. 2. While keywords have a 't' argument which overrules the underlying face (it would behave the same as tags with 'prepend'): https://code.orgmode.org/bzg/org-mode/src/5417e384ebab58e560fe6a80eee7bc58b1ef8645/lisp/org.el#L5647 Not sure about priority cookies and links. This is what I have for now. Thank you for looking into this! My system details: - GNU Emacs 27.1 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.22, cairo version 1.17.3) of 2020-08-14 - Org mode version 9.3 (release_9.3 @ /usr/share/emacs/27.1/lisp/org/) Best regards Protesilaos -- Protesilaos Stavrou protesilaos.com
Re: Bug: Babel+R handles spaces wrongly in tables [9.3.6 (release_9.3.6 @ /home/cassou/.emacs.d/lib/org/lisp/)]
> On Sep 6, 2020, at 4:32 AM, Damien Cassou wrote:
>
>
> Hi,
>
> it seems that, if a cell within a table contains a space, the
> corresponding value passed as parameter to a R script will be
> wrong.
Not exactly. Your ECM has one column, and using both columns removes the issue.
Here is another ECM that illustrates the bug:
#+begin_src R :results output :var accounts=(identity '("A B" "C"))
print(accounts)
#+end_src
The bug is in `org-babel-R-assign-elisp' which attempts to get the number of
elements in each line of a table, but when the table has just one row or column
it gets this wrong.
> Please find a very simple org file attached to this email. I
> expect the length of the variable to be 2 (which is the length of '("A
> B" "C") and not 3. Apparently, R receives this array instead: '("A B"
> "C" nil).
>
Actually the length should be 1, i.e. a data.frame with a single column of two
elements.
BTW, C-c C-v C-v with point in the src block will show you what R `receives'.
Unfortunately, there are other cases where the variable assignment does not
work seamlessly for R src blocks. There are workarounds, but they are ungainly
- like using a src block for another language to render the table and then
using a noweb reference to it to import the data.
HTH,
Chuck
Re: [feature request] A new cookie type [!] showing the last note taken
Ihor Radchenko writes: >> Everyone has their own workflows, but I think the way you are approaching >> this problem is "wrong". > > I think I need to elaborate on the use-cases more then. > > I am well aware about the concept of NEXT actions, GTD, projects, and > using categories to bring task context in agenda. However, the problem I > am trying to solve is more subtle. > > Sometimes, subdividing a task into NEXT sub-tasks is simply overkill > leading to redundancy. Consider the following example of reading a book, > when the task of reading is also part of bigger project: Chiming in briefly to say that I agree: many of my TODO use-cases simply don't make any sense broken up into sub-tasks. So much of what I do is email-based discussions -- about project proposals, textual edits, contract negotiations -- and as the discussion evolves the TODO bounces back and forth between NEXT and WAIT. This is also the fundamental approach of Gnorb. There's no useful way to break that evolving discussion into subtasks. All I want to know is, what am I WAITing on and how long have I been WAITing, and if the ball's in my court, what am I doing NEXT. I looked into implementing something like what Ihor is suggesting (except using a message-area echo), ran into some of the same difficulties (the semi-real status of notes), and then noticed that on an Agenda item shows the item in another window with its LOGBOOK expanded, meaning you can see the whole evolution of the TODO at a glance. And "o" hides it away again. That took most of the steam out of my plans, and I figured it was good enough. Re the formatting issue, maybe the easiest thing would simply be to say by fiat that only notes in a LOGBOOK drawer were eligible for special parsing. If you're sticking notes in the subtree body, they're just a list. Since no special note-handling facilities currently exist, no one would lose out on anything if we said any future such facilities would require the LOGBOOK. Eric
Re: Preventing org-cycle from scrolling the buffer
Hi Bastien, Thank you, both for accepting this and for the fix with the blank line folding! Best, DK сб, 5 сент. 2020 г. в 11:26, Bastien : > > Hi Dmitrii, > > Dmitrii Korobeinikov writes: > > > Nice, I see! > > > >> IDK. AFAICS you are right with your argumentation. I don't see the > >> need of that feature, though, yet. But that's just me. I think you are > >> the best candidate to try an implementation of the feature. > > > > I have attached a small patch, seems to be working! Of course, if this > > is to be merged, that defvar will have to turn into a defcustom. > > thanks for the patch, I applied a small variant of it as 056fc532b. > > I don't think we need an option (defcustom) for this, the current > behavior seems correct -- but I'm convinced some people would prefer > the previous behavior. If there are a lot of such people with strong > argument, perhaps we will have to revert the change. > > Thanks, > > -- > Bastien
Re: [PATCH] Re: Export to attach directory?
Bastien writes:
> Hi Eric,
>
> sorry for the late reply -- I don't use attachments that much
> but I see how this could be useful once correctly advertized and
> documented.
>
> Eric Abrahamsen writes:
>
>> Would something along these lines be considered for inclusion?
>
> Yes, sure, for after 9.4 -- please go ahead with a proper patch.
How does this look? It occurred to me that having a global
`org-export-directory' option would be a good thing -- it makes sense to
me that a user might want all their exported files put in one place --
but in the interest of one-thing-at-a-time I didn't do that.
This additional property doesn't actually have anything to do with
org-attach. I'd originally thought that, with this option, I could write
an export filter that would check for:
:EXPORT_DIRECTORY:
and replace it to point at whatever the attach dir was/should be for
that heading.
If that's something that many users would like to have, we could look at
adding it in org-attach.el. But in the meantime, the attached patch
makes it possible to do it yourself.
Thanks,
Eric
>From 0e80a6ed7ad955259c4e11ea74ed249696ba9b46 Mon Sep 17 00:00:00 2001
From: Eric Abrahamsen
Date: Sun, 6 Sep 2020 10:36:34 -0700
Subject: [PATCH] Add EXPORT_DIRECTORY property
* lisp/ox.el (org-export-output-file-name): Check for this property
and place the exported output file there.
* doc/org-manual.org: Document.
---
doc/org-manual.org | 8 +++-
lisp/ox.el | 14 ++
2 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index 46498bd22..6f256a569 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -11479,7 +11479,7 @@ global variables, include:
- =CREATOR= ::
#+cindex: @samp{CREATOR}, keyword
- #+vindex: org-expot-creator-string
+ #+vindex: org-export-creator-string
Entity responsible for output generation
(~org-export-creator-string~).
@@ -11539,6 +11539,12 @@ global variables, include:
generates the file name based on the buffer name and the extension
based on the back-end format.
+- =EXPORT_DIRECTORY= ::
+
+ #+cindex: @samp{EXPORT_DIRECTORY}, keyword
+ An alternate directory in which to place the output file.
+ Otherwise, output files are placed alongside the original Org file.
+
The =OPTIONS= keyword is a compact form. To configure multiple
options, use several =OPTIONS= lines. =OPTIONS= recognizes the
following arguments.
diff --git a/lisp/ox.el b/lisp/ox.el
index 9852cfd21..2d2c1ddb0 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -6428,6 +6428,20 @@ Return file name as a string."
"Output file: " pub-dir nil nil nil
(lambda (n) (string= extension (file-name-extension n t))
extension))
+ (pub-dir (or pub-dir
+ (and subtreep (org-entry-get
+ nil "EXPORT_DIRECTORY" 'selective))
+ (org-with-point-at (point-min)
+ (catch :found
+ (let ((case-fold-search t))
+ (while (re-search-forward
+"^[ \t]*#\\+EXPORT_DIRECTORY:[ \t]+\\S-"
+nil t)
+ (let ((element (org-element-at-point)))
+(when (eq 'keyword (org-element-type element))
+ (throw :found
+ (org-element-property
+ :value element))
(output-file
;; Build file name. Enforce EXTENSION over whatever user
;; may have come up with. PUB-DIR, if defined, always has
--
2.28.0
[solved it] (was: org-time-stamp in German or Spanish or....)
>>> "SN" == Stefan Nobis writes: > Uwe Brauer writes: >> But it still inserts <2020-09-06 Sun> > What's the value of `system-time-locale'? I found that I had to re-run sudo locale-gen de_DE.UTF-8 sudo dpkg-reconfigure locales Then it worked as expected. Thanks! <2020-09-06 So> smime.p7s Description: S/MIME cryptographic signature
Re: Bug or not a bug? dot expansion in ob-shell
Hi Jack, Jack Kamm writes: > I think it's a bad idea that ":results value", and not specifying > ":results", give different behavior. Indeed. At first, I thought "If ':results value' is always the same as the default, why have ':results value' at all?" and thought it'd be an argument for having different defaults for different languages but I see how I was wrong: expectations for defaults should be stable, while the notion of "value" and "output" can vary from one language to the other. Note that I've fixed this in master, not in maint. I may release 9.3.8 just for the sake of testing some fixes there, but 9.4 will follow closely anyway. Thanks for your patient input in this thread! -- Bastien
Re: Bug or not a bug? dot expansion in ob-shell
Hi Tim, sorry for the late reply, and thanks a lot for the clear summary. Tim Cross writes: > It seems to me that two separate issues have been mixed up and causing > some confusion here. However, I think it is actually quite simple once > we consider the issues separately. > > Issue 1: Defining the meaning of :result value and :result output ... which is already defined in Org's documentation. > Issue 2: Specifying what the default :result setting would be i.e. > :result without a value/output specifier. After careful consideration, I suggest to follow the manual here, which says that ":results value" is the default. After 2f534294 in master, executing shell blocks with no :results header will output the exit code, which is the "value". > It could be that for some languages, the default for :result should > be :result output and for others it should be :result value. I decided not to go that way, even though I do sympathize with Tom's argument in the very same thread. I think Jack makes a compelling argument about the need to let the default always be ":results value". It seems less random to have some users being surprised that the value of executing a shell source block is an exit code, than to make it necessary for all users to check what is the default result for each Babel library. Best, -- Bastien
Re: When auto-fill breaks a link into multiple lines, the link is no longer displayed as a link
Hi Philip, Philip Blagoveschensky writes: > Do you mean that I can probably fix it by changing what fonts I use? Nope, I mean the issue might come from the way Emacs add faces like bold, etc (aka "fontification".) > If so, I'd rather do that than tinker with emacs trying to make a > reproducible recipe. A reproducible recipe is like immutable gold to this community: it means that everyone can reproduce your problem and that everyone can try fixing it: otherwise Linus's law "given enough eyeballs..." does not really hold anymore. Just saying :) -- Bastien
Re: When auto-fill breaks a link into multiple lines, the link is no longer displayed as a link
Do you mean that I can probably fix it by changing what fonts I use? If so, I'd rather do that than tinker with emacs trying to make a reproducible recipe. -- Regards, Philip Blagoveschensky 4 сент. 2020 г. 19:08:19 Bastien : > Hi Philipp, > > Philip Blagoveschensky writes: > >> Sometimes org-mode breaks links into multiple lines: sometimes >> Auto-Fill does this, sometimes me invoking org-fill-paragraph does >> this. When it happens, org-mode displays them incorrectly, but only >> after I reload the file (see the attached screenshot, there's a >> newline symbol before the word "field"). How do I either >> >> - Make it stop breaking links? >> - Make it display them correctly even if they are broken? > > I think I see what you mean, because I sometimes have broken links > too, but would you care to provide a reproducible recipe, so that we > can see what goes wrong when? This is probably more due to an Emacs > fontification limitation than an Org issue. > > Thanks, > > -- > Bastien >
Re: [BUG?] org-edit-src-save active in Org-Babel Previewo
Hi Rick,
thanks for the report.
Rick Frankel via "General discussions about Org-mode."
writes:
> In an babel preview buffer opened with 'org-babel-expand-src-block,
> ('org-edit-src-save) writes the expanded view back to the org
> file, with all the variable expansions, etc.
>
> I may be wrong, but i don't remember this behavior in older versions of
> Org, and this has bitten me a couple of times, breaking babel code
> blocks with dynamically set variables (:var …).
Can you share a reproducible step by step example, stating what you
get and what you expected instead?
Thanks,
--
Bastien
Re: Improving org-contacts performance (and state of development in general)
Hi Daryl, Daryl Manning writes: > Is there a solid, forked branch anywhere that focuses on enhancing > performance anywhere? Note that I'm aware of, but I don't use org-contacts.el, so maybe other will have more information. > I'm tempted to wade in and add features and improvements myself but > my elisp-fu is dodgy at best (more golang these days.). I'm copying Julien, the original author of org-contacts.el, to check if he plans to maintain org-contacts.el further and if he's okay for someone to take over. That someone could be you: better to have a maintainer than no one. Also, org-contacts.el is part of the "contrib/" directory in Org's repository and soon after 9.4 we will strip this directory out of the org-mode.git repo, so having someone taking care of individual contrib packages would be really appreciated. > I'd be interested in what people are doing to speed it up (and if it > is under anything like active development for improvements. It does > feel super handy, and feels like it just needs a performance and more > modern features overhaul - more on interoperability and less on > in-emacs interoperability.). I'm afraid most tricks will be general Org tricks, no directly related to the code in org-contacts.el -- but perhaps I'm wrong. Best, -- Bastien
Improving org-contacts performance (and state of development in general)
Strangely, I've come to rely over the last year on org-contacts as a lightweight, taggable CRM. However, as the file and C-z notes have grown, performance has really started to drag. I know people have used various schemes (caching) etc to try to improve performance and the like, but updates to the file are taking a solid 5 seconds now when making major updates and moving tags around. Is there a solid, forked branch anywhere that focuses on enhancing performance anywhere? I'm tempted to wade in and add features and improvements myself but my elisp-fu is dodgy at best (more golang these days.). I'd be interested in what people are doing to speed it up (and if it is under anything like active development for improvements. It does feel super handy, and feels like it just needs a performance and more modern features overhaul - more on interoperability and less on in-emacs interoperability.). Would love to hear what people have done overall workflow wise if they are using it seriously. thanks, Daryl.
Re: org-time-stamp in German or Spanish or....
Uwe Brauer writes: > But it still inserts <2020-09-06 Sun> What's the value of `system-time-locale'? In a shell (like Bash), is there a difference between the following two commands: #+begin_src bash LC_TIME=C date #+end_src #+begin_src bash LC_TIME=de_DE date #+end_src -- Until the next mail..., Stefan.
Re: org-time-stamp in German or Spanish or....
>>> "SN" == Stefan Nobis writes: > Uwe Brauer writes: >> But is inserts the name of the days in English > The format and language of the time-stamps is controlled by the > function format-time-string (the docstring of this function shows all > the available placeholders, including "%a" for the locale's > abbreviated name of the day of week). > So the name of the days should be controlled by the locale Emacs is > running in (or the relevant language settings inside Emacs). > For example I want to enforce English names, so I have in my init.el: > #+begin_src elisp > (set-language-environment "English") > (set-locale-environment "en_US.UTF-8") > #+end_src Thanks, so far so good, *but* (set-language-environment "German") (set-locale-environment "de_DE.UTF-8") Does *not* insert a german date it inserts an English one: <2020-09-06 Sun> > You can check what locale Emacs is using by inspecting the variables > `current-language-environment', and especially `system-time-locale' > (for the case that LC_TIME is set differently than other locale > settings). current-language-environment is a variable defined in ‘mule-cmds.el’. Its value is "German" Original value was "English" system-time-locale is a variable defined in ‘C source code’. Its value is "de_DE.UTF-8" But it still inserts <2020-09-06 Sun> Is this a bug? Regards Uwe Brauer smime.p7s Description: S/MIME cryptographic signature
[Some progress] (was: org-time-stamp in German or Spanish or....)
> Uwe Brauer wrote/hat geschrieben on/am 06.09.2020 14:01: > Can't answer this, because I don't use a mail buffer, but in an org-file > I use C-c . to insert an active time stamp (result: <2020-09-06 So>) or > C-c ! for an inactive one (result: [2020-09-06 So]) ah you use a mail (nor message) buffer when answering this message In any case I found out that (set-locale-environment "es_ES.UTF-8") inserts <2020-09-06 dom> But (set-locale-environment "de_DE.UTF-8") inserts <2020-09-06 Sun> Which is odd. smime.p7s Description: S/MIME cryptographic signature
Re: Bug: customize type for `org-agenda-category-icon-alist' [9.3 (release_9.3 @ /usr/share/emacs/27.0.91/lisp/org/)]
Got it. I am sorry for the late reply. There is no opinion on making the patch. Thanks. -- nilninull
Re: a catastrophic orgmode issue - a definite show stopper, put on your tin hats
On 9/6/2020 2:17 AM, hj-orgmod...@hj.proberto.com wrote: > === The alien abduction of Bastien === > > Just in: > > The relentless activity - plethora of unstoppable emails - on the > orgmode mailing list under the name "Bastien" is a clear proof that the > impostor doesn't sleep and that it doesn't eat. It's a robot that just > hammers and hammers at the keyboard. The only logical conclusion is that > our Bastien has been abducted by aliens. > > Aliens! Beware! ... We will be looking for Bastien. Give us back our > Bastien, or you will have a war on your hands! > > Until we find him, we'll enjoy all that this robot has got going ... > > - 23 - Based on the incredible number of posts and amazing responsiveness, I think it is more likely that all of the inhabitants from the planet Bastien have been party to this. -gyro pEpkey.asc Description: application/pgp-keys
Re: org-babel support for haxe
Hi ian, It looks like this library is instead going to be available through an ELPA, but FWIW here are a couple of comments on the tests. ian martins writes: > diff --git a/testing/examples/ob-haxe-test.org > b/testing/examples/ob-haxe-test.org > new file mode 100644 > index 0..ba9119d58 > --- /dev/null > +++ b/testing/examples/ob-haxe-test.org > @@ -0,0 +1,247 @@ > +#+Title: a collection of examples for ob-haxe tests > +#+OPTIONS: ^:nil > +* Simple > + :PROPERTIES: > + :ID: 966875e9-d10e-406c-9211-449555e3d3b2 > + :END: > +#+name: simple > +#+begin_src haxe :results output silent > + Sys.print(42); > +#+end_src I know some other babel tests use a separate .org file, but I find this setup harder to follow compared to having the Org content within the test (e.g. using org-test-with-temp-text or org-test-with-temp-text-in-file). Perhaps I'm missing why it's needed in this case though. > diff --git a/testing/lisp/test-ob-haxe.el b/testing/lisp/test-ob-haxe.el [...] > +;;; Code: > +(org-test-for-executable "haxe") > +(unless (featurep 'ob-haxe) > + (signal 'missing-test-dependency "Support for haxe code blocks")) > + > +(ert-deftest ob-haxe/simple () > + "Hello world program." > + (if (executable-find org-babel-haxe-command) I think you can avoid the executable-find here and in all the other tests because you have (org-test-for-executable "haxe") at the beginning of the file.
Re: [b...@gnu.org: Re: bug#42484: 26.1: org-mode should display value of links in mini-buffer]
> Boruch Baum writes: > >> In org-mode, when POINT is moved over an org-mode link, wouldn't it be >> reasonable for the value of that link to appear in the mini-buffer? The >> advantage of that is the user would know where the link points and what >> would happen if the link is opened (eg. would an external program open, >> would the network be queried). That would be very welcome, IMO. FWIW, markdown-mode does that (when markup is hidden) using ElDoc; cf. markdown-eldoc-function.
Re: org-time-stamp in German or Spanish or....
Uwe Brauer writes: > But is inserts the name of the days in English The format and language of the time-stamps is controlled by the function format-time-string (the docstring of this function shows all the available placeholders, including "%a" for the locale's abbreviated name of the day of week). So the name of the days should be controlled by the locale Emacs is running in (or the relevant language settings inside Emacs). For example I want to enforce English names, so I have in my init.el: #+begin_src elisp (set-language-environment "English") (set-locale-environment "en_US.UTF-8") #+end_src You can check what locale Emacs is using by inspecting the variables `current-language-environment', and especially `system-time-locale' (for the case that LC_TIME is set differently than other locale settings). -- Until the next mail..., Stefan.
Re: org-time-stamp in German or Spanish or....
Uwe Brauer wrote/hat geschrieben on/am 06.09.2020 14:01: > Uwe Brauer wrote/hat geschrieben on/am 06.09.2020 11:15: > For me > (setq calendar-day-name-array ["Sonntag" "Montag" "Dienstag" "Mittwoch" >"Donnerstag" "Freitag" "Samstag"] > calendar-month-name-array ["Januar" "Februar" "Maerz" "April" > "Mai" "Juni" "Juli" "August" "September" "Oktober" "November" "Dezember"]) > in .emacs works Thanks not for me, I just use your setting but org-time-stamp *still* inserts <2020-09-06 Sun> in the mail buffer where the stamp overlays are off. But shouldn't it be <2020-09-06 Son> or something like this If you fire up org-time-stamp in a mail buffer what does it insert with your setting? Thanks Uwe Can't answer this, because I don't use a mail buffer, but in an org-file I use C-c . to insert an active time stamp (result: <2020-09-06 So>) or C-c ! for an inactive one (result: [2020-09-06 So]) regards, Heinz
[BUG?] org-edit-src-save active in Org-Babel Previewo
In an babel preview buffer opened with 'org-babel-expand-src-block,
('org-edit-src-save) writes the expanded view back to the org
file, with all the variable expansions, etc.
I may be wrong, but i don't remember this behavior in older versions of
Org, and this has bitten me a couple of times, breaking babel code
blocks with dynamically set variables (:var …).
Re: babel default header args as functions
Bastien writes: > Hi Matt, > > Matt Huszagh writes: > >> Matt Huszagh writes: >> >>> I've generated a patch for this. Please let me know your thoughts. I >>> believe this adds valuable flexibility to default header >>> arguments. >> >> I've added an additional fix that makes this work during export too. > > I would like to hear what other think about this feature. > > Anyone? > > Also, if we integrate the change, `eval-default-headers' would be > better named `org-babel-eval-default-headers'. I like this new feature propose too. It can be used in many situations. Really helpful. -- [ stardiviner ] I try to make every word tell the meaning that I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
Re: org-time-stamp in German or Spanish or....
> Uwe Brauer wrote/hat geschrieben on/am 06.09.2020 11:15: > For me > (setq calendar-day-name-array ["Sonntag" "Montag" "Dienstag" "Mittwoch" > "Donnerstag" "Freitag" "Samstag"] > calendar-month-name-array ["Januar" "Februar" "Maerz" "April" > "Mai" "Juni" "Juli" "August" "September" "Oktober" "November" "Dezember"]) > in .emacs works Thanks not for me, I just use your setting but org-time-stamp *still* inserts <2020-09-06 Sun> in the mail buffer where the stamp overlays are off. But shouldn't it be <2020-09-06 Son> or something like this If you fire up org-time-stamp in a mail buffer what does it insert with your setting? Thanks Uwe smime.p7s Description: S/MIME cryptographic signature
Bug: Babel+R handles spaces wrongly in tables [9.3.6 (release_9.3.6 @ /home/cassou/.emacs.d/lib/org/lisp/)]
Hi,
it seems that, if a cell within a table contains a space, the
corresponding value passed as parameter to a R script will be
wrong. Please find a very simple org file attached to this email. I
expect the length of the variable to be 2 (which is the length of '("A
B" "C") and not 3. Apparently, R receives this array instead: '("A B"
"C" nil).
Emacs : GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.21,
cairo version 1.16.0)
Package: Org mode version 9.3.6 (release_9.3.6 @
/home/cassou/.emacs.d/lib/org/lisp/)
--
Damien Cassou
"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill
#+name: table
| | 2014 |
|-+--|
| A C |1 |
| C |2 |
#+name: linechart
#+begin_src R :results value :var accounts="" :exports none
length(accounts)
#+end_src
#+call: linechart(accounts=table[,0])
#+RESULTS:
: 3
Re: [PATCH] Re: Re: Re: org-forward-heading-same-level and the invisible-ok argument
Hi, > Does it fix a problem for org-superstar-mode or a more general problem > in Org? It mostly fixes an org-superstar-mode problem (see https://github.com/integral-dw/org-superstar-mode/issues/19). > Why do you need to check the visibility status every character in the > headline (even for the org-superstar-mode, where you seem to need to > check for the visibility status /after/ the stars)? There is no intrinsic need for my current application for it to check anything past the last star, I just went with the most "naive" implementation first. If it were just for org-superstar (and similar modes [1]) it would be fully sufficient to check the heading from the position of the last star up to the first character past the space, if present (which would boil it down to checking 3 chars instead of N). > If you use seq* functions, the code will be incompatible with previous > emacsen, right? Hmm, looking at the oldest available ELPA release (seq-1.0, 2015), seq-every-p should be fully backwards-compatible. The current package itself also has a fallback option for Emacs versions <25, so that should be fine. Cheers, D [1] https://github.com/TonCherAmi/org-starless
Re: org-time-stamp in German or Spanish or....
Uwe Brauer wrote/hat geschrieben on/am 06.09.2020 11:15:
Hi
Org-time-stamp inserts a date as specified in
(org-time-stamp-custom-formats '(" %d.%m.%Y " . " %d.%m.%Y %a %H:%M "))
But is inserts the name of the days in English, which variable allows me
to change the language?
I thought maybe
(defun my-set-calendar-deutsch () ;Version:1.190
(interactive)
(setq calendar-week-start-day 1
calendar-day-name-array ["Sonntag" "Montag" "Dienstag" "Mittwoch"
"Donnerstag" "Freitag" "Samstag"]))
But it does not: it steill does <2020-09-06 Sun>
What do I miss?
Thanks
Uwe Brauer
For me
(setq calendar-day-name-array ["Sonntag" "Montag" "Dienstag" "Mittwoch"
"Donnerstag" "Freitag" "Samstag"]
calendar-month-name-array ["Januar" "Februar" "Maerz" "April"
"Mai" "Juni" "Juli" "August" "September" "Oktober" "November" "Dezember"])
in .emacs works
regards,
Heinz
Re: attachments and inheritance (bug?)
flare writes: > I have run into this issue myself Can you provide a reproducible recipe? Perhaps I am missing something obvious, but I don't have the problem reported by the OP. -- Bastien
Re: [PATCH] org-add-planning-info: respect caller's given time [9.3.7 (release_9.3.7-716-g3d4876 @ /home/n/.emacs.d/straight/build/org/)]
No Wayman writes: > Bastien writes: > >> Applied in maint as c7abcd514, thanks. > > Thanks, Bastien. I noticed org-end-time-was-given is bound similarly. > This binding doesn't affect my usage, but I wonder if it is necessary. > If you think it isn't, I'd be happy to submit another patch removing > it. Well, for the time being, I reverted the change (reverting c7abcd514) because it broke a test. If you can investigate why the test broke, that'd be helpful. Thanks! -- Bastien
Re: [FEATURE REQUEST] No tangle of code blocks within archived subtrees
Hi Bastien, My initial reaction was to say yes to all of these in the name of consistency, but there are nuances for org-babel-ref-resolve and org-babel-expand-noweb-references that are different than for org-babel-exp-process-buffer. If I have a block that nowebbs in another block, and at some point that other block is archived, do we treat it as if the block never existed? I don't think we do. Same for org-babel-ref-resolve. Those names exist and we know they exist, we just don't display/export them. I'm basing this on the assumption that users who archive headings don't want to see them/search them, not that they wanted to remove them entirely or refactor things related to them. It might make sense to warn if a block that is nowebbed in has been archived so the user can do something about it if they want, but I think having archiving effectively induce a null pointer is a bad idea. I wonder what other perspectives there are on this. Best! Tom On Sun, Sep 6, 2020 at 2:37 AM Bastien wrote: > - org-babel-exp-process-buffer Yes > - org-babel-ref-resolve Probably not? > - org-babel-expand-noweb-references Probably not?
Re: Bug: issue with babel and sqlite [9.3 (release_9.3 @ /usr/share/emacs/27.0.91/lisp/org/)]
Hi, I fixed this with commit ec80dd6c in the maint branch. Thanks, -- Bastien
Re: Babel: parse error when output contains opening bracket
Hi Ian, ian martins writes: > I've written an alternative org-java.el that doesn't have that > problem. I hope you don't mind the fix I just integrated -- it's simple enough for being in 9.3.8, the next stable release. Obviously your updates ob-java.el will probably make it obsolete once we can move on after 9.4. Thanks, -- Bastien
Re: FR: allow adding a deadline with warning days [was Re: deadline warning days entry]
Hi Samuel, indeed, letting org-schedule and org-deadline to accept more metadata, such as warning delays, would be good. If someone wants to try writing a patch for this, please go ahead. Best, -- Bastien
Re: Babel: parse error when output contains opening bracket
Hi Jarmo, Jarmo Hurri writes: > In the org file below, the first babel block will evaluate just fine, > while the second will signal "End of file during parsing". The > difference is the opening bracket "[" in output. Fixed in maint, thanks. -- Bastien
Re: [PATCH] lisp/ob-core.el: pass expanded body to org-confirm-babel-evaluate
Hi Kyle, Great. That sounds like the best solution given that correctness is more important than performance at the moment. We have a good idea of how to improve the performance going forward so providing the correct behavior asap seems like the right thing to do. Thank you very much for getting this in! Best, Tom On Sat, Sep 5, 2020 at 8:45 PM Kyle Meyer wrote: > > Tom Gillespie writes: > > > Hi Kyle, > > Following up in this thread having investigated the impact of coderefs. > > My conclusion is that coderefs need to be stripped out before they are > > passed to org-confirm-babel-evaluate. They are not present in the > > executed code and removing them is not something that a definition > > of org-confirm-babel-evaluate should have to know anything about. > > Right now I work around them by suggesting that users comment > > out their coderefs. This works because my use case is restricted to > > elisp code and I strip the comments using read, but other languages > > would not have such an easy solution. > > Thanks for revisiting this. This change (df5a83637) hasn't made it into > a release yet, so it'd be good to make this move now. > > > I have included a patch against maint that reuses the let block > > from org-babel-execute-src-block to accomplish this. > > > diff --git a/lisp/ob-core.el b/lisp/ob-core.el > > index cd876da0f..44b02feb9 100644 > > --- a/lisp/ob-core.el > > +++ b/lisp/ob-core.el > > @@ -240,9 +240,14 @@ should be asked whether to allow evaluation." > > (funcall org-confirm-babel-evaluate > >;; Language, code block body. > >(nth 0 info) > > - (if (org-babel-noweb-p headers :eval) > > - (org-babel-expand-noweb-references info) > > -(nth 1 info))) > > + (let ((coderef (nth 6 info)) > > +(expand > > + (if (org-babel-noweb-p params :eval) > > params is undefined here. I've s/params/headers/ when applying. > > > + > > (org-babel-expand-noweb-references info) > > + (nth 1 info > > +(if (not coderef) expand > > + (replace-regexp-in-string > > + (org-src-coderef-regexp coderef) "" > > expand nil nil 1 > > org-confirm-babel-evaluate > > (cond > > (noeval nil) > > Okay, so this is equivalent to your original patch, though your initial > approach avoided duplicating the logic, which I think is worth doing. > I'd like to make sure this gets in before a release, so I've applied > this message's patch (3e1c0b0f4) and then followed it up with a patch > that adds a test, and another that extracts the duplicated logic out to > a helper (as in your original patch).
Re: [FEATURE REQUEST] No tangle of code blocks within archived subtrees
Hi Tom, Tom Gillespie writes: >This seems like it is probably a bug given that everything else > about archive headings is disabled. Yes, I agree this should considered as a bug. I have a fix for it, which is to ignore archived subtrees along with commented ones when tangling. org-in-commented-heading-p is used in these Babel functions: - org-babel-exp-process-buffer - org-babel-ref-resolve - org-babel-expand-noweb-references Should we treat archived subtrees like commented ones in these contexts too? Respectively when exporting, resolving refs and expanding noweb references? I'd favor such an equal treatment of commented/archived subtrees but I'd like to make sure it sounds good to everyone before. -- Bastien
Re: babel default header args as functions
Hi Bastien, Here are some examples that I have in mind. One example would be to simplify my hacked solution to from https://lists.gnu.org/archive/html/emacs-orgmode/2020-09/msg00175.html. I could apply that to all the headings in a subtree by defining it once in the property drawer. Another example would be to only tangle a block when a certain value was true, it would require using an unofficial header convention to store the name of the file per block, or it could use the name of the block. I do something like that around line 1336 of https://raw.githubusercontent.com/SciCrunch/sparc-curation/9c08e82ab0b8c497e01d8542ecb1195d40111767/docs/setup.org. Another extremely common use case I have is detecting that I am running on a particular host which requires a slightly different value than some other host that I run regularly on, for example if I am going to be running a large number of blocks using :dir and on host a it needs to be /home/my-usual-user-name/working/ and on another it has to be /home/my-other-user-name/working/ because I wasn't the first user named tom to get an account on that system. Similar use case would be switching the database port based on which host I was on since I often forward a remote database port via ssh while also having a local database on that port as well. Another case would be to be able to blanked switch :tangle from yes to no based on whether a sentinel file was present or any other condition you could imagine (this is similar to the second example). Best! Tom On Sat, Sep 5, 2020 at 10:00 PM Bastien wrote: > > Thanks for weighing in into this discussion. > > Tom Gillespie writes: > > > I have a number of use > > cases that I can imagine would benefit greatly from being able to > > define a :header-args: :header (lambda () "yay!") property as a > > closure > > Can you give some examples? I would love to get a better sense of > the usefulness of this feature. > > -- > Bastien
org-time-stamp in German or Spanish or....
Hi
Org-time-stamp inserts a date as specified in
(org-time-stamp-custom-formats '(" %d.%m.%Y " . " %d.%m.%Y %a %H:%M "))
But is inserts the name of the days in English, which variable allows me
to change the language?
I thought maybe
(defun my-set-calendar-deutsch () ;Version:1.190
(interactive)
(setq calendar-week-start-day 1
calendar-day-name-array ["Sonntag" "Montag" "Dienstag" "Mittwoch"
"Donnerstag" "Freitag" "Samstag"]))
But it does not: it steill does <2020-09-06 Sun>
What do I miss?
Thanks
Uwe Brauer
Re: attachments and inheritance (bug?)
On Sun, Sep 06, 2020 at 01:52:36AM -0700, flare wrote: > > I have run into this issue myself, my solution for this ended up being > a quick hack to toggle this inheritence so that subheadings could reach > into superheadings when referencing the same attachments. > > #+BEGIN_SRC elisp > > (defun org-attach-switch-inheritence () ^^ Sorry for calling in from the peanut gallery... the conventional term for that kind of thing seems to be "toggle", not "switch", right? Anyway, thanks for making Org better :-) Cheers - t signature.asc Description: Digital signature
Re: a catastrophic orgmode issue - a definite show stopper, put on your tin hats
Hi there, hj-orgmod...@hj.proberto.com writes: > Aliens! Beware! ... We will be looking for Bastien. Give us back our > Bastien, or you will have a war on your hands! Before waging war, please make sure to get a copyright assignment from them. We wouldn’t want to have an intergalactic hold-up on the next release. Best, -- Leo Vivier Freelance Software Engineer Website: www.leovivier.com | Blog: www.zaeph.net
Re: a catastrophic orgmode issue - a definite show stopper, put on your tin hats
I'm with you on this - the behaviour we've seen is clearly inhuman. Oh the other hand, this 'imposter' does seem to be doing good work ... I wonder if we can keep it when we re-capture the real Bastien? Yours in conspiracy, Timothy.
[b...@gnu.org: Re: bug#42484: 26.1: org-mode should display value of links in mini-buffer]
- Forwarded message from Bastien - Date: Sun, 06 Sep 2020 10:21:33 +0200 From: Bastien To: Boruch Baum Cc: 42484-d...@debbugs.gnu.org Subject: Re: bug#42484: 26.1: org-mode should display value of links in mini-buffer User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Hi Boruch, Boruch Baum writes: > In org-mode, when POINT is moved over an org-mode link, wouldn't it be > reasonable for the value of that link to appear in the mini-buffer? The > advantage of that is the user would know where the link points and what > would happen if the link is opened (eg. would an external program open, > would the network be queried). Can you suggest this feature to the Org list at emacs-orgmode@gnu.org? Such "electric" display could sure be useful, but I would like to get feedback from other Org contributors and users before accepting a patch. I'm closing this as this is not an Emacs bug. Thanks, -- Bastien - End forwarded message - -- hkp://keys.gnupg.net CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0
Re: attachments and inheritance (bug?)
I have run into this issue myself, my solution for this ended up being a quick hack to toggle this inheritence so that subheadings could reach into superheadings when referencing the same attachments. #+BEGIN_SRC elisp (defun org-attach-switch-inheritence () "Allows for Subtrees to have their own distinct attach directories" (interactive) (if (member "ID" org-use-property-inheritance) (progn (setq org-use-property-inheritance (delete "ID" org-use-property-inheritance) ) (message "ID Inheritance Disabled") ) (add-to-list 'org-use-property-inheritance "ID") (message "ID Inheritance Enabled") ) ) ;; keybinding for C-c C-A (local-set-key [3 33554433] 'org-attach-switch-inheritence) #+END_SRC Bastien writes: > Hi Julius, > > Dittmar writes: > >> Hello friends, >> >> either I misunderstood something or I stumbled upon a bug. >> >> Situation: I have a heading with some files attached. This heading has >> an ID property, upon which the directory for those files is based. >> >> There's also a subheading with no ID. Inside of that subheading I'd like >> to link to one of the attached files. But although >> org-attach-use-inheritance is non-nil, the attachment is not found from >> inside that subheading. >> >> Shouldn't it be found? > > I tried your example and the file is found for both links. > > What is the exact value of `org-attach-use-inheritance' (t or 'selective)? > > If 'selective, what is the value of `org-use-property-inheritance'? > >> - GNU Emacs 26.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.10.9) of >> 2018-07-06 >> - org-mode: current master >> - no setting containing 'attach' in any configuration file > > Can you provide a reproducible recipe with a minimal configuration? > > Thanks,
Re: attachments and inheritance (bug?)
Hi Julius, Dittmar writes: > Hello friends, > > either I misunderstood something or I stumbled upon a bug. > > Situation: I have a heading with some files attached. This heading has > an ID property, upon which the directory for those files is based. > > There's also a subheading with no ID. Inside of that subheading I'd like > to link to one of the attached files. But although > org-attach-use-inheritance is non-nil, the attachment is not found from > inside that subheading. > > Shouldn't it be found? I tried your example and the file is found for both links. What is the exact value of `org-attach-use-inheritance' (t or 'selective)? If 'selective, what is the value of `org-use-property-inheritance'? > - GNU Emacs 26.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.10.9) of > 2018-07-06 > - org-mode: current master > - no setting containing 'attach' in any configuration file Can you provide a reproducible recipe with a minimal configuration? Thanks, -- Bastien
Re: vertical spacing between lines in a list at odt-export
Dear Bastien, thank you for you for patience. It is a minor issue, still I try to explain by an example (see below). If the example below is exported to LibreOffice I am happy with all the format, except the vertical spacing between list elements, which results from the vertical space after each paragraph in the "Textkörper" format. I could change this format, but that would affect all paragraphs, not only the lists. BTW, there is a convenient solution for Latex-export (https://emacs.stackexchange.com/questions/47864/org-mode-set-separation-length-between-elements-of-a-list). best regards, Heinz Example org file: * example project This is an example project description ... more text. The motivation for this research resulted mainly from the following clinical questions. - Is there a need for intense therapy? - cytostatic - transplantation - If yes, when should the therapy start? - immediately after diagnosis - at first signs of progression - after relapse Some of these questions were partially answered by Genius et al., 2003 and ... more text. ** introduction The main purpose ... more text. ** material Data was contributed from ten centers ... more text. All data collection was done between 2010 and 2018. Informed consent was obtained by each patient. The following inclusion and exclusion criteria were applied. - inclusion criteria - age > 16 - stable disease for >= 2 months - etc. - exclusion criteria - other malignant disease - missing cytogenetics - etc. All inclusion criteria had to be fulfilled. No exclusion criterion had to be fulfilled. A data review was performed by two coauthors (AB, TC). ** methods The following measures were used to describe relations: - for numeric data: Pearson correlation - for ordered data: Kendall's tau - for unordered data - dichotomous: odds ratio - polytomous: contingency coefficient As level of significance .05 was set. Hypotheses were defined two-sided. In view of the exploratory nature of the study no adjustment for multiple testing was applied. ** results The main result ... more text. Bastien wrote/hat geschrieben on/am 05.09.2020 16:19: Dear Heinz, Heinz Tuechler writes: thank you - I know that. The problem seems to be that in the odt-file all lists, as well as all "normal" text share the same format. In my German version of LibreOffice it is called "Textkörper". So, if I modify that format in a ODT_STYLES_FILE it changes all the "normal" text, not only the lists. If I were able to assign a different format to lists, then your proposal would be the optimal solution. Until now I did not find out, how to assign such a different format to lists. Perhaps you can send a feature request to the LibreOffice team? Why do I use lists at all? It is, because they offer a hierarchical way of description, but, contrary to headings and subheadings, after the end of a list, you jump to the same level as before the list. Instead with headings and subheadings I think, I can go back to the level at the beginning only by inserting a new (sub)heading of the desired level. Maybe I am missing some alternative. Perhaps try M-RET in a heading or explore `org-adapt-indentation' (I'm not sure I completely grok your need, hence the suggestions.) Best,
a catastrophic orgmode issue - a definite show stopper, put on your tin hats
=== The alien abduction of Bastien === Just in: The relentless activity - plethora of unstoppable emails - on the orgmode mailing list under the name "Bastien" is a clear proof that the impostor doesn't sleep and that it doesn't eat. It's a robot that just hammers and hammers at the keyboard. The only logical conclusion is that our Bastien has been abducted by aliens. Aliens! Beware! ... We will be looking for Bastien. Give us back our Bastien, or you will have a war on your hands! Until we find him, we'll enjoy all that this robot has got going ... - 23 -
Re: Default description for abbreviated links
Hello Kévin,
Kévin Le Gouguec writes:
> I like #+LINK keywords because they make documents self-sufficient:
> anyone opening my document can follow these links or export the buffer;
> they do not need to run some Elisp to add to org-link-parameters.
>
> One thing I don't know how to customize, however, is how these links are
> exported when they have no description.
thanks for sharing your need and ideas.
I think we can allow
#+LINK: bug [[https://debbugs.gnu.org/%s][bug:%s]]
to define an abbreviated link producing the output you want.
Same in org-link-abbrev-alist(-local):
(("bug" . "[[https://debbugs.gnu.org/%s][bug:%s]];))
What do you think? I'd rather not add an option or modify the
structure of org-link-abbrev-alist(-local).
Best,
--
Bastien
Re: Bug: Org bold emphasis gobbles leading stars on next headline [9.3.7 (release_9.3.7-710-g3f04ad @ /home/n/.emacs.d/straight/build/org/)]
Hi, No Wayman writes: > With the following Org mode file and point denoted by "|": > > * Parent > | > ** Sibling > > Insert the text "*", resulting in: > > * Parent > "*"| > ** Sibling > > textually, but the final star of the Sibling heading is hidden as > well: > > * Parent > "*"| > Sibling > > I believe the org-hide face is being overridden by the bold face. Indeed, I can reproduce this bug with latest Org. -- Bastien
Re: Bug: No colors in first file opened [9.3.7 (9.3.7-dist @ c:/w/.emacs.d/org-9.3.7/lisp/)]
Hi Dominick,
thanks for sharing this on the list. I don't use Windows, so it
is difficult for me to understand what can go wrong.
Dominick Samperi writes:
> My current work-around is to map F12 to (org-mode-restart).
>
> After installing a fresh version of Emacs 27.1 using the Windows
> installer, and copying
> org-9.3.7 to ~/.emacs.d, the first file I open is not colorized until
> I use F12. My init.el contains:
> (add-to-list 'load-path "~/.emacs.d/org-9.3.7/lisp")
> (setq auto-mode-alist (cons '("\\.s?txt?\\'" . org-mode) auto-mode-alist))
> (require 'org)
>
> This happens when the first file I open has name foo.org, or bar.txt.
> There are no problems when I continue to open files.
Note this other Emacs bug report:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=43196
Perhaps the discussion there gives you useful hints.
Best,
--
Bastien
Re: [PATCH] Re: Re: Re: org-forward-heading-same-level and the invisible-ok argument
D writes: >> Probably, it is easier if you just use seq-every-p instead of >> mapcar on (number-sequence max-pos min-pos -1). The result of >> seq-every-p will be inverse of the currently used expression. > > Oh yeah, that's much nicer. I also made the predicate check > right-to-left, which just causes it to check the text bit of a heading > first, which is useful for the cases where the predicate returns t and > makes no difference otherwise. I again ran the tests and it seems ready > to go. Thanks for the patch. Does it fix a problem for org-superstar-mode or a more general problem in Org? Why do you need to check the visibility status every character in the headline (even for the org-superstar-mode, where you seem to need to check for the visibility status /after/ the stars)? If you use seq* functions, the code will be incompatible with previous emacsen, right? Thanks for any follow-up, -- Bastien
Re: display-buffer-pop-up-frame causes many extra frames for capture
Hi Stephen, Stephen Paul Weber writes: > I'm happy to make further customisations of my environment to avoid > this, but it is very surprising to me so I wonder if anyone can > guess what might be happening and give me some pointers about it? I don't use frames so I cannot confirm the bug is *not* here, perhaps others can tell. In the meantime, can you provide your Org and Emacs versions and a reproducible minimal recipe for what looks like a bug? A few steps to let anyone see what you see and fix the problem. Thanks, -- Bastien
Re: [PATCH] babel latex headers and image generation commands
Hi Matt,
Matt Huszagh writes:
> Matt Huszagh writes:
>
>> I've added a few changes to the patch that additionally allow custom the
>> begin and end document environments. The purpose here is to allow latex
>> code within the document environment that is ignored by the body
>> export. For instance, I can set the page color with
>> {\color{some-color}...} and this doesn't mess up latex exports.
>
> I've fixed a minor bug with the previous patch.
Thanks -- that'd be for after 9.4 of course.
> From 1bcd1d28dde6625d0c648c92243260b46433e1eb Mon Sep 17 00:00:00 2001
> From: Matt Huszagh
> Date: Fri, 28 Aug 2020 22:26:05 -0700
> Subject: [PATCH] ob-latex.el: Make latex to svg compilation very customizable
>
> * lisp/ob-latex.el (org-babel-latex-preamble): Add latex preamble
> customization.
> (org-babel-latex-begin-env): Add latex document environment begin
> customization.
> (org-babel-latex-end-env): Add latex document environment end
> customization.
> (org-babel-latex-pdf-svg-process): Add customization for converting a
> pdf to svg.
> (org-babel-execute:latex): Add specific case for svg generation from
> latex block.
Prefer
* lisp/ob-latex.el (org-babel-latex-preamble): New option for LaTeX
preamble customization.
"New option" is quite standard, an "option" being a customizable
variable. In this case, "New option" would probably be enough, given
the name of the option is quite self-explanatory. Also, some find it
pedantic, but "LaTeX" is the correct spelling in a changelog I guess.
> +(defcustom org-babel-latex-preamble
> + (lambda (_)
> +"\\documentclass[preview]{standalone}
> +\\def\\pgfsysdriver{pgfsys-tex4ht.def}
> +")
> + "Closure which evaluates at runtime to the latex preamble. It
> +takes 1 argument which is the parameters of the source block."
> + :group 'org-babel
> + :type 'function)
The first line of the docstring should contain a sentence, so you'd
need to have a new paragraph after "runtime to the LaTeX preamble."
> +(defcustom org-babel-latex-pdf-svg-process
> + "inkscape --pdf-poppler %f -T -l -o %O"
> + "Command used to convert a PDF file to an SVG file when
> +executing a latex source block."
> + :group 'org-babel
> + :type 'string)
What for users who don't have inkscape?
Thanks,
--
Bastien
Re: [PATCH] org-refile.el: Add org-refile-reverse which toggles org-reverse-note-order
Bastien writes: > Hi Adam, > > Adam Spiers writes: > >> This is useful for prepending to the start of the target headline >> instead of appending to the end, or vice-versa depending on >> org-reverse-note-order. > > I think this would be useful. What others think? > [...] +1; sounds quite useful to me as well. Thank you both. signature.asc Description: PGP signature
[PATCH] org-plot abstractions and extension
Hi All, I think while my org-plot work isn't yet complete, it has reached a review-able state. I see org-plot as a great tool for making it easy to produce high-quality graphics from tabular data in Org files. With this in mind, this set of patches aims to achieve to overarching goals: 1. improve the flexibility of org-plot by abstracting out some hard-coded elements 2. introduce some (hopefully, generally useful) utility functions, and a new default plot type that makes use of them --- radar If you are interested in org-plot, or have some time to spare and are feeling helpful, please give me your thoughts on the attached patches :) Timothy. <#part type="text/x-patch" filename="/home/tec/.emacs.d/.local/straight/repos/org-mode/0001-org-plot.el-make-indentation-method-consistent.patch" disposition=attachment> <#/part> <#part type="text/x-patch" filename="/home/tec/.emacs.d/.local/straight/repos/org-mode/0002-org-plot.el-add-new-option-transpose.patch" disposition=attachment> <#/part> <#part type="text/x-patch" filename="/home/tec/.emacs.d/.local/straight/repos/org-mode/0003-org-plot.el-add-new-custom-gnuplot-preamble.patch" disposition=attachment> <#/part> <#part type="text/x-patch" filename="/home/tec/.emacs.d/.local/straight/repos/org-mode/0004-org-plot.el-abstract-plot-types-into-custom-var.patch" disposition=attachment> <#/part> <#part type="text/x-patch" filename="/home/tec/.emacs.d/.local/straight/repos/org-mode/0005-org-plot.el-add-utility-functions-for-range-ticks.patch" disposition=attachment> <#/part> <#part type="text/x-patch" filename="/home/tec/.emacs.d/.local/straight/repos/org-mode/0006-org-plot.el-add-custom-var-for-affecting-the-term.patch" disposition=attachment> <#/part> <#part type="text/x-patch" filename="/home/tec/.emacs.d/.local/straight/repos/org-mode/0007-org-plot.el-tweak-term-preamble-custom-vars.patch" disposition=attachment> <#/part> <#part type="text/x-patch" filename="/home/tec/.emacs.d/.local/straight/repos/org-mode/0008-org-plot.el-add-radar-plot-type.patch" disposition=attachment> <#/part> <#part type="text/x-patch" filename="/home/tec/.emacs.d/.local/straight/repos/org-mode/0009-org-plot.el-fix-logic-error-in-transposition.patch" disposition=attachment> <#/part> <#part type="text/x-patch" filename="/home/tec/.emacs.d/.local/straight/repos/org-mode/0010-org-plot.el-complete-transition-to-softcoded-type.patch" disposition=attachment> <#/part> <#part type="text/x-patch" filename="/home/tec/.emacs.d/.local/straight/repos/org-mode/0011-org-plot.el-avoid-arithmetic-overflow-error.patch" disposition=attachment> <#/part>
