Hello, org community
I ran into the titled issue and haven't found any solution or explanation:
First, I start Emacs and there are just a few buffers such as *scratch* and
*Messages*.
Then, I fire `org-capture', captur a note and `C-c C-c' to save the captured
content.
Suddenly all the files un
Noel Errenil writes:
> Hello, org community
>
> I ran into the titled issue and haven't found any solution or explanation:
>
> First, I start Emacs and there are just a few buffers such as *scratch* and
> *Messages*.
>
> Then, I fire `org-capture', captur a note and `C-c C-c' to save the captured
alain.coch...@unistra.fr writes:
> My .bib file is
>
>@string{jgr="J. Geophys. Res."}
>@ARTICLE{chouet88,
>journal=jgr,
>author={Chouet, B.}, title={Resonance of a fluid-driven crack: [...]},
>year={1988}, volume={93}, number={B5}, pages={4375-4400}
Fixed on main via c550a429
Stefan Kangas writes:
> The attached patch fixes a small typo I found in the
> `org-refile-targets' docstring.
Thanks!
Applied onto main via bf930b6fe.
Best,
Ihor
Ihor Radchenko writes:
> All the tests are passing now on my side.
>
> I'll postpone merging to next week to make sure that there are no more
> comments.
Applied onto main via e08ce5b27, ae1db7df3, 8908a1bda, f3802b017,
a4105d094, a18969768, and 132a9d304 after resolving a trivial merge
conflict
Ihor Radchenko writes:
> Hmm. Note that SINGLE-QUOTE is not actually typed, so your version is
> also kind of confusing.
>
> I propose an alternative as the attached.
Applied onto main via 79f0969cc.
Best,
Ihor
Ihor Radchenko writes:
> The fix is attached. Let me know if it also works on your side.
Fixed.
Applied onto main via 064afa0c0.
Best,
Ihor
Ihor Radchenko writes on Sun 17 Jul 2022 16:26:
> Fixed on main via c550a4290.
>
> After discussion with Emacs devs, it turned out that there is a way to
> make bibtex.el parse and substitute @string abbreviations.
I don't know what "Fixed on main via c550a4290" means, but I just made
a 'git
Juan Manuel Macías writes:
> I think LEFTWARDS ARROW / #2190 of the 'arrows' Unicode block is much
> more common:
Thanks for testing!
I now changed org-agenda to use LEFTWARDS ARROW in b4a72ddf9.
This does not completely solve the reported problem but at least less
users will suffer from it.
B
Ihor Radchenko writes:
> From 9b5f5844aedfab9f36ba89ed8beca36651370c0a Mon Sep 17 00:00:00 2001
> Message-Id:
> <9b5f5844aedfab9f36ba89ed8beca36651370c0a.1652099870.git.yanta...@gmail.com>
> From: Ihor Radchenko
> Date: Mon, 9 May 2022 20:34:38 +0800
> Subject: [PATCH] org-agenda-clock-report-h
Hi Ihor and Samuel,
Ihor Radchenko writes:
> In addition, we might also announce the oldest supported Emacs version
> in https://orgmode.org/Changes.html.
The current release of Org is meant to be compatible with the last
three major releases of Emacs. That is, as of now, 28, 27, 26.
See http
Max Mikhanosha writes:
> Currently org-agenda-bulk-action is completely broken if anything tries to
> take a log note during the action, this patch fixes it by storing log note
> setup variables in a list, and then taking one log note, and duplicating it
> over all affected items.
Thanks for the
Juan Manuel Macías writes:
> I attach the new version of the patch with both variables declared
> obsolete.
Thanks!
We usually declare obsolete variables in org-compat.el.
> If everything is ok, I can add what is necessary to NEWS and to the Org
> Manual.
I have some minor comments. You can
Caleb Chase writes:
> I discovered a bug with org-capture and org-capture kill when
> canceling an item or plain type template on a heading that has only an
> empty line for content. Minimal reproduction is as follows:
Thanks for reporting!
Confirmed.
Best,
Ihor
Juan Manuel Macías writes:
> Out of curiosity, I wonder if Marcin or someone else finally got around
> to implementing something concrete for this. I think some kind of
> extension to org-babel-tangle that would generate the typical docstrip
> .dtx and .ins files might be nice. Perhaps this would
Christian Heinrich writes:
> thanks for your feedback. I attached a patch, but I'm not sure why you said
> "all but the last line".
> That last line for me was (org-set-tags tags), which proved important as
> otherwise the tags were not
> set in the buffer.
By "all but last line" I implied tha
Hugo Heagren writes:
>> Can you also update the documentation for
>> org-link-make-description-function?
>
> I'm not sure what sort of documentation you have in mind? What should
> I add?
I referred to my earlier statement:
> tl;dr The question is: what is the Good Behaviour when
Max Nikulin writes:
> Ihor, Hugo raised a question how to interpret nil returned by
> :insert-description functions. Do you have any opinion? I do not like
> the idea to consider it as an error since string is expected. I would
> prefer to call `org-link-make-description-function' as a fallbac
Ihor Radchenko writes:
> Visuwesh writes:
>
>> C-u C-c C-x < followed by C-c C-x > does not remove the file restriction
>> lock.
>>
>> `org-agenda-remove-restriction-lock' checks for non-nil value of
>> `org-agenda-restriction' but `org-agenda-set-restriction-lock' explicitly
>> sets it to nil
Ihor Radchenko writes:
> This will skip links inside property drawers, for example.
> Attaching an alternative patch.
Applied onto main via 057df6cce.
Best,
Ihor
juh writes:
> This does not work:
>
> #+CAPTION: Foobar
> #+NAME: fig:imagew
> #+ATTR_CONTEXT: :width 5cm
> [[file:/image.png]]
Have you tried #+attr_latex?
Best,
ihor
Hi
Look at this example
* Test
:PROPERTIES:
:ID: 46b9eb11-e258-4dc9-bf56-3c2112cf6b0a
:Received: [X]
:END:
Using `org-shiftright'
I can obtain
* Test
:PROPERTIES:
:ID: 46b9eb11-e258-4dc9-bf56-3c2112cf6b0a
:Received: [ ]
:END:
But how can I obtain
* Test
:P
Phil Estival writes:
> Hi there
>
> - A nasty bug when inserting an item in a list
> in last position (org 9.5.3-g69c588):
> - here is a list
> with a sub list
>
> - like here ;
>
> and then text
> x
I am unable to reproduce on the latest main.
Best,
Ihor
Uwe Brauer writes:
> But how can I obtain
>
> * Test
> :PROPERTIES:
> :ID: 46b9eb11-e258-4dc9-bf56-3c2112cf6b0a
> :Received: [-]
> :END:
>
> org-toggle-checkbox does not work for these sort of checkboxes.
The [ ] <> [X] is hardcoded.
But you can always set Received_ALL property to
Hi everyone:
Is there any way to make something like this actually work?
#+title:test
#+macro: num 50
#+name: numbers
#+begin_src emacs-lisp no-export
40
#+end_src
#+begin_export html
the result is {{{num}}}
another result is <>
#+end_export
See inline calls in
https://orgmode.org/manual/Evaluating-Code-Blocks.html#Evaluating-Code-Blocks
>>> "IR" == Ihor Radchenko writes:
> Uwe Brauer writes:
>> But how can I obtain
>>
>> * Test
>> :PROPERTIES:
>> :ID: 46b9eb11-e258-4dc9-bf56-3c2112cf6b0a
>> :Received: [-]
>> :END:
>>
>> org-toggle-checkbox does not work for these sort of checkboxes.
> The [ ] <> [X] is hardcoded.
> Bu
https://orgmode.org/manual/Property-Syntax.html#Property-Syntax
On Sun, Jul 17, 2022 at 10:31 PM Uwe Brauer wrote:
> >>> "IR" == Ihor Radchenko writes:
>
> > Uwe Brauer writes:
> >> But how can I obtain
> >>
> >> * Test
> >> :PROPERTIES:
> >> :ID: 46b9eb11-e258-4dc9-bf56-3c2112cf6b0a
> >
>>> "IR" == Ihor Radchenko writes:
> Uwe Brauer writes:
>> But how can I obtain
>>
>> * Test
>> :PROPERTIES:
>> :ID: 46b9eb11-e258-4dc9-bf56-3c2112cf6b0a
>> :Received: [-]
>> :END:
>>
>> org-toggle-checkbox does not work for these sort of checkboxes.
> The [ ] <> [X] is hardcoded.
> Bu
>>> "IR" == Ihor Radchenko writes:
> Uwe Brauer writes:
>> But how can I obtain
>>
>> * Test
>> :PROPERTIES:
>> :ID: 46b9eb11-e258-4dc9-bf56-3c2112cf6b0a
>> :Received: [-]
>> :END:
>>
>> org-toggle-checkbox does not work for these sort of checkboxes.
> The [ ] <> [X] is hardcoded.
> Bu
Ihor Radchenko writes:
> For Max's comment, using plist/alist would make things more clear
> code-wise for future developers. I always find it annoying when I need
> to go back and forth checking which element should be second or third or
> forth in the list. Especially if the variable is used all
On Sun, Jul 17, 2022 at 7:24 AM Ihor Radchenko wrote:
> See inline calls in
> https://orgmode.org/manual/Evaluating-Code-Blocks.html#Evaluating-Code-Blocks
>
I did this and it didn't work (but the one outside the export block did):
#+title:test
#+name: numbers
#+begin_src emacs-lisp :exports n
Dear All,
While syntax highlighting for code blocks is correctly implemented when I
export a Org document with M-x org-html-export-to-html, it does not work when
the same document is exported as part of an org-publish project defined using
org-publish-project-alist.
Org-version: 9.5.4 (also
Hi,
Ihor Radchenko writes:
> Hmm. You are right. I missed "optionally".
>
> Still, I find this idea as the best solution for people who want to
> process the source block text during noweb expansion.
>
> Alternative ideas are welcome though. I'd prefer to avoid breaking
> change if we can find
I am starting to use org-contacts and wanted to unify my existing
"Birthdays" list, with the new formatted contacts I am creating.
Do the anniversaries have to be out of PROPERTIES?
Example: This is not "parsed into agenda":
:PROPERTIES:
:BDAY: %%(org-anniversary 1980 02 19)
:END:
BTW: Thanks
Kevin,
> On Jul 17, 2022, at 10:18 AM, kevinbanjo wrote:
>
>
>
> On Sun, Jul 17, 2022 at 7:24 AM Ihor Radchenko wrote:
> See inline calls in
> https://orgmode.org/manual/Evaluating-Code-Blocks.html#Evaluating-Code-Blocks
>
> I did this and it didn't work (but the one outside the export bloc
On Sun, Jul 17, 2022 at 11:54 AM Berry, Charles
wrote:
> Kevin,
>
> > On Jul 17, 2022, at 10:18 AM, kevinbanjo wrote:
> >
> >
> >
> > On Sun, Jul 17, 2022 at 7:24 AM Ihor Radchenko
> wrote:
> > See inline calls in
> https://orgmode.org/manual/Evaluating-Code-Blocks.html#Evaluating-Code-Blocks
>
Den lör 16 juli 2022 kl 11:16 skrev Ihor Radchenko :
> Henrik Frisk writes:
>
> >>> Is so, you probably need
> >>>
> >>> org-protocol://capture?template...
> >>> instead of
> >>> org-protocol://capture-html?template...
> >>>
> >>> Thanks, that was the issue and it works fine now. However, I can't
When I look at the doc string for (org-macro-replace-all) it says:
*Optional argument KEYWORDS, when non-nil is a list of keywords,*
*as strings, where macro expansion is allowed.*
I tried passing it '("export-block") but it didn't work, but it seems like
something like that should be close.
Th
kevinbanjo writes:
> Thanks for that Chuck. It would seem a lot cleaner if there was a hook or
> something one could run that would just expand macros in export blocks
> before exporting them.
Check out export filters in 13.17 Advanced Export Configuration
By default, we cannot allow Org synt
kevinbanjo writes:
> When I look at the doc string for (org-macro-replace-all) it says:
>
>
> *Optional argument KEYWORDS, when non-nil is a list of keywords,*
> *as strings, where macro expansion is allowed.*
>
> I tried passing it '("export-block") but it didn't work, but it seems like
> someth
"M. Pger" writes:
> While syntax highlighting for code blocks is correctly implemented when I
> export a Org document with M-x org-html-export-to-html, it does not work
> when the same document is exported as part of an org-publish project defined
> using org-publish-project-alist.
>
> Org-v
Ypo writes:
> I am starting to use org-contacts and wanted to unify my existing
> "Birthdays" list, with the new formatted contacts I am creating.
>
> Do the anniversaries have to be out of PROPERTIES?
>
> Example: This is not "parsed into agenda":
>
> :PROPERTIES:
> :BDAY: %%(org-anniversary 19
Henrik Frisk writes:
>> Could you please provide a bit more details on what you did, what you
>> expected to get, and what you got?
>>
>> Yes, of course!
>
> I saw in another thread recently that you had the bibtex captured as a code
> block (begin_src bibtex) which I wasn't able to get. In the d
Ihor Radchenko writes:
>> valign-mode causes the problem. Try these steps to reproduce the problem :
>> add-hook for valign and open a large org file, then try moving the mouse a
>> few times，quickly TAB and SHIFT-TAB a few times.
>
> Thanks! I have opened an issue in valign repo:
> https://githu
On Sun, Jul 17, 2022 at 11:54 AM Berry, Charles
wrote:
> Kevin,
>
> > On Jul 17, 2022, at 10:18 AM, kevinbanjo wrote:
> >
> >
> >
> > On Sun, Jul 17, 2022 at 7:24 AM Ihor Radchenko
> wrote:
> > See inline calls in
> https://orgmode.org/manual/Evaluating-Code-Blocks.html#Evaluating-Code-Blocks
>
great! one of the things i like about org is the close attention to
user-oriented nature of maintenance. everything on mailing list,
maint branch, compilation warnings few, etc. this is more of the same
user-oriented goodness.
i have noticed an impressive amount of bug fixing, code improvement,
Noel Errenil writes:
> ...
> Then, I fire `org-capture', captur a note and `C-c C-c' to save the captured
> content.
>
> Suddenly all the files under ~/projects/org will be loaded into the buffer
> list, which confuses me so much. Those that have nothing to do with
> capturing or capture-template
kevinbanjo writes:
>> You need to construct the export block programmatically. Maybe something
>> like
>>
>> #+begin_src emacs-lisp :results html :exports results :var num=numbers()
>>(format "the result is %d" num )
>> #+end_src
>>
>>
> The problem with that is when I export I get both abo
It works! Thanks, Ihor.
How could I've known? Should I've known?
El 18/07/2022 a las 1:49, Ihor Radchenko escribió:
Ypo writes:
I am starting to use org-contacts and wanted to unify my existing
"Birthdays" list, with the new formatted contacts I am creating.
Do the anniversaries have to b
Gustavo Barros writes:
> ... (lots of detailed analysis with various cases)
> WDYT?
I feel that you are overcomplicating things a bit.
What if we simply change all the agenda lines if and only if their date
in agenda is earlier or equal to the next scheduled time (after repeater
is triggered)?
Juan Manuel Macías writes:
>> For Max's comment, using plist/alist would make things more clear
>> code-wise for future developers. I always find it annoying when I need
>> to go back and forth checking which element should be second or third or
>> forth in the list. Especially if the variable is
Hi
In my current setting, the following works
| 3.5 | 4.2 | 7.7 |
#+TBLFM: $3=$1+$2
Now if I want to switch to the convention used in Germany (that might be
relevant if I want to export it later to csv, but this is a different
topic) does work in a strange way, any comments? I would expect
|
53 matches
Mail list logo
