Mark Kerr writes:
> I have a radio group of 3 tags defined in org-tag-alist: now. next, later.
> This tag group works correctly when editing the tags directly in the
> original org files or when the tags are edited individually in the agenda
> using ':'.
>
> When editing tags via the agenda's
Adrian Bradd writes:
> Using the following agenda file as an MWE:
>
> * Incoming
> ** TODO Testing1
> ** TODO Testing2
> ** TODO Testing3
>
> I ran org-agenda and pressed 't' to list all todo items. In the agenda
> buffer I marked the task 'Testing1' with 'm' and performed a bulk action with
>
Chris Perl writes:
> When using org-agenda-custom-commands with
> org-agenda-category-filter-preset and org-agenda-sticky, it seems as
> though changes to org-agenda-category-filter are global, even though
> the variable is made buffer local.
>
> From the limited digging I've done, it seems that
Ihor Radchenko writes:
> Bernt Hansen writes:
>
>> Hi,
>>
>> I ran into an issue this morning where my capture task continues
>> clocking on save. This occurs in both master and maint when not
>> clocking into a drawer.
>>
>> ECM follows.
>
> Confirmed
Fixed on main.
cra...@gmx.net writes:
> I have run into problems with a TODO entry that has a body which
> contains an active date. Finishing it results in
>
> Entry repeats: SCHEDULED: <2016-12-13 Tue +1w>
>
> being printed to *Messages*, but no actual new SCHEDULED line is added
> to the entry.
For record,
Allen Li writes:
> Expected:
>
> agenda tag set on bar entry
>
> Actual:
>
> agenda tag set on foo entry
Just leaving a note that it is not reproducible with latest Org.
Best,
Ihor
Bernt Hansen writes:
> Hi,
>
> I ran into an issue this morning where my capture task continues
> clocking on save. This occurs in both master and maint when not
> clocking into a drawer.
>
> ECM follows.
Confirmed
AFAICT the issues raised in this thread have been solved, so I am
closing this bug report now.
Org-mode does not encourage users to use GitHub for hosting their
source code, nor does it encourage them to use non-free javascript
by browsing GitHub's page.
Some files in Org still contain
Hi Eric,
"Fraga, Eric" writes:
> If I turn debugging on for table updates (C-c {), when the debugging is
> finished, the original window configuration is not remembered.
>
> Should be simple to fix, but possibly beyond my emacs-lisp-fu.
Fixed, thanks!
--
Bastien
I've been having this same issue - the issue is quite reproducible for me,
and it has been for years. I just finally grew tired of the issue and
decided to investigate it, and yes, the issue is org-agenda-show-new-time.
I also have invisible entries in the org buffer, and the call to
Hello all,
If I turn debugging on for table updates (C-c {), when the debugging is
finished, the original window configuration is not remembered.
Should be simple to fix, but possibly beyond my emacs-lisp-fu.
Thanks,
eric
--
Eric S Fraga via Emacs 27.0.50, Org release_9.2.6-552-g8c5a78
While fooling around with capture templates, I have also noticed this:
(progn
(setq org-popup-calendar-for-date-prompt t)
(read-date t)))
When prompted, if you type something like "13:00" - it returns correct,
expected datetime.
But, if you do:
(progn
(setq
This worked fine for me with org 9.2.3 and 9.2.6 with emacs 26.1.
John
---
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu
Running org-map-entries on an org file with tags results in an infinite
loop.
Example function using org-map-entries:
(defun org-map-entries-test ()
(interactive)
(org-map-entries '(lambda () (message "%s" (org-entry-properties
(point) 'standard
(message "done"))
Hi Ag,
> When I use (org-read-date t) and type something like "+2m" it works as
> expected, but for
> some reason if I type something like "+2h" it returns datetime with no
> changes. Expected - two hours in the future. Am I missing something?
AFAICS your expectation is not implemented. See
When I use (org-read-date t) and type something like "+2m" it works as
expected, but for
some reason if I type something like "+2h" it returns datetime with no
changes. Expected - two hours in the future. Am I missing something?
On 21/10/2019 23:24, Vladimir Nikishkin wrote:
> Well, checking for "output" doesn't seem to be useful any way, since
> "output" is never 'nil.
>
> Regarding the fact that the error should be reported to the geiser
> mailing list, that's entirely true. The problem is that the person who
> would
Joshua Meyers writes:
> In this page (https://orgmode.org/worg/org-gtd-etc.html) the link to
> the "very instructive post by Pete Phillips" now directs to the
> defunct gmane.org. I think I tracked down the post it is supposed
> to link to, so I don't want others to have to do this work again:
On Mon, 21 Oct 2019 at 15:16, Vladimir Nikishkin
wrote:
> Yeah. The "output" is not the result of geiser's elisp functions, as far
> as I understand, it comes from comint, which reads it from a scheme
> interpreter, and is expected to be formatted specifically to be fed into
>
Hi Vladimir,
On Mon, 21 Oct 2019 at 03:21, Vladimir Nikishkin
wrote:
>
> Can we replace the (set) on line 177 of ob-scheme.el with the following
> form:
> (setq result (if output
> (let ((g-r-o (geiser-eval--retort-output ret)))
> (if g-r-o
>
Remember to cover the basics, that is, what you expected to happen and
what in fact did happen. You don't know how to make a good report? See
https://orgmode.org/manual/Feedback.html#Feedback
Your bug report will be posted to the Org mailing list.
In this page (https://orgmode.org/worg/org-gtd-etc.html) the link to the
"very instructive post by Pete Phillips" now directs to the defunct
gmane.org. I think I tracked down the post it is supposed to link to, so I
don't want others to have to do this work again:
Remember to cover the basics, that is, what you expected to happen and
what in fact did happen. You don't know how to make a good report? See
https://orgmode.org/manual/Feedback.html#Feedback
Your bug report will be posted to the Org mailing list.
Remember to cover the basics, that is, what you expected to happen and
what in fact did happen. You don't know how to make a good report? See
https://orgmode.org/manual/Feedback.html#Feedback
Your bug report will be posted to the Org mailing list.
Remember to cover the basics, that is, what you expected to happen and
what in fact did happen. You don't know how to make a good report? See
https://orgmode.org/manual/Feedback.html#Feedback
Your bug report will be posted to the Org mailing list.
Thanks for your replies. Your solution works for me, thank you a lot for
your work.
Sincerely,
Godefroy Vannoye
On 10/13/19 1:21 PM, Vladimir Lomov wrote:
> Hello,
> ** Nicolas Goaziou [2019-10-13 09:26:42 +0200]:
>
>> Hello,
>>
>> Godefroy writes:
>>
>>> I recently encountered a bug when
Dear, org-mode developer,
I was not aware of the fact, that new lines are special in interactive
mode and indicate the end of an indented block (I have just found out
about that in the babel documentation for python). Therefore the issue
which I have reported is probably not a bug but rather an
Hello,
Vladimir Nikishkin writes:
> The mwe would be like:
>
> #+begin_src scheme :exports both :results output :noweb-ref bug1
> #+end_src
>
> #+begin_src scheme :exports both :results output :noweb-ref bug2
> #+end_src
>
> #+begin_src scheme :exports both :results output :noweb-ref bug3
>
Remember to cover the basics, that is, what you expected to happen and
what in fact did happen. You don't know how to make a good report? See
https://orgmode.org/manual/Feedback.html#Feedback
Your bug report will be posted to the Org mailing list.
Hello,
** Nicolas Goaziou [2019-10-13 09:26:42 +0200]:
> Hello,
>
> Godefroy writes:
>
>> I recently encountered a bug when exporting an org file to LaTeX: when
>> generating a figure with a caption, the LaTeX result has the following
>> shape:
>>
>> \begin{figure}
>> …
>> \caption{\label{…}
On 2019-10-13 at 09:26 +02, Nicolas Goaziou wrote...
> IIRC, the label has to be included in the caption command. I applied a
> different solution. Let me know if that works for you.
I thought so too. But I couldn't find a definitive answer for this when
searching about this last night.
Hello,
Godefroy writes:
> I recently encountered a bug when exporting an org file to LaTeX: when
> generating a figure with a caption, the LaTeX result has the following
> shape:
>
> \begin{figure}
> …
> \caption{\label{…}
> Content of the caption}
> \end{figure}
>
> When compiling to LaTeX,
Hello,
As it is my first email to the list, please forgive me if I do anything
the wrong way.
I recently encountered a bug when exporting an org file to LaTeX: when
generating a figure with a caption, the LaTeX result has the following
shape:
\begin{figure}
…
\caption{\label{…}
Content of the
I wrote:
> I wrote:
>
>> org-babel-tangle on
>>
>> * A
>>
>> #+BEGIN_SRC elisp :tangle yes :noweb yes
>> ;; A
>> <>
>> #+END_SRC
>>
>> * COMMENT B
>>
>> #+BEGIN_SRC elisp :noweb-ref B
>> ;; B
>> #+END_SRC
>>
>> * COMMENT C
>>
>> #+BEGIN_SRC elisp :tangle
Hello,
Robert Irelan writes:
> Patch to fix attached
Applied. Thank you.
Regards,
--
Nicolas Goaziou
Hi Org list,
`org-refile-get-target', when using `org-refile-use-outline-path'
appends an "extra" slash at the end of every path, but candidates are
stored in `org-refile-history' without that extra slash. As the default
candidate passed to `completing-read' is the car of `org-refile-history'
First, here is a patch introducing tests concerning Org comments and
tangling.
>From c769435b9ab11f7a3b5ff5f1ec2df95ae2c6aa32 Mon Sep 17 00:00:00 2001
From: Sebastian Miele
Date: Wed, 2 Oct 2019 13:02:46 +
Subject: [PATCH] ob-tangle: Add tests
* testing/lisp/test-ob-tangle.el
Patch to fix attached
--
Robert Irelan
rire...@gmail.com
From 3d3008398abb6c3a8cdfd796e6daa3f3ba909ad2 Mon Sep 17 00:00:00 2001
From: Robert Irelan
Date: Fri, 27 Sep 2019 12:19:03 -0700
Subject: [PATCH] ox-publish: signal org-link-broken for broken fuzzy links
* lisp/ox-publish.el
Sebastian Miele writes:
> In the following days I will try to fix it and write a regression test.
>
> However, in the unlikely case that this is a feature and not a bug,
> please let me know. Please also let me know, if anyone is already on it.
>
> Sebastian Miele writes:
>
>> org-babel-tangle
In the following days I will try to fix it and write a regression test.
However, in the unlikely case that this is a feature and not a bug,
please let me know. Please also let me know, if anyone is already on it.
Sebastian Miele writes:
> org-babel-tangle on
>
> * A
>
> #+BEGIN_SRC elisp
> On Wed, 25 Sep 2019 20:16:26 +0200, Justus Winter
> said:
Justus> "Fraga, Eric" writes:
>> On Wednesday, 25 Sep 2019 at 11:50, Justus Winter wrote:
>>> I noticed a operator associativity problem when evaluating formulas in
>>> tables. To reproduce, enter:
>>>
On Wednesday, 25 Sep 2019 at 20:16, Justus Winter wrote:
> However, I cannot fathom the rationale behind this property, and for a
> spreadsheet-like application I consider it borderline negligent.
Not my place to defend (or otherwise) the decisions that went into defining the
grammar for Calc.
"Fraga, Eric" writes:
> On Wednesday, 25 Sep 2019 at 11:50, Justus Winter wrote:
>> I noticed a operator associativity problem when evaluating formulas in
>> tables. To reproduce, enter:
>>
>> | :=6/2*3 |
>>
>> And evaluate the formula. This results in:
>>
>> | 1 |
>> #+TBLFM: @1$1=6/2*3
>
>
On Wednesday, 25 Sep 2019 at 11:50, Justus Winter wrote:
> I noticed a operator associativity problem when evaluating formulas in
> tables. To reproduce, enter:
>
> | :=6/2*3 |
>
> And evaluate the formula. This results in:
>
> | 1 |
> #+TBLFM: @1$1=6/2*3
Yes, this is a property (feature, ?) of
Remember to cover the basics, that is, what you expected to happen and
what in fact did happen. You don't know how to make a good report? See
https://orgmode.org/manual/Feedback.html#Feedback
Your bug report will be posted to the Org mailing list.
Remember to cover the basics, that is, what you expected to happen and
what in fact did happen. You don't know how to make a good report? See
https://orgmode.org/manual/Feedback.html#Feedback
Your bug report will be posted to the Org mailing list.
Oh, I forgot about the "-Q"... Anyway, I figured the behavior is present
with evil-mode.
Here's is how to launch a clean evil environment:
$ git clone https://github.com/emacs-evil/evil
$ cd evil
$ make emacs
Should I file a bug in the evil tracker?
Regards,
Dmitrii.
ср, 25 сент. 2019 г. в
Dmitrii Korobeinikov writes:
> When I edit a heading (the title), if I add characters, the tags auto-align.
> But if I remove text, tags shift left and so are no longer aligned.
Need much more information about your setup. You wouldn't, by chance,
be sharing your Org files with BeOrg on an
When I edit a heading (the title), if I add characters, the tags auto-align.
But if I remove text, tags shift left and so are no longer aligned.
Regards,
Dmitrii
An Org file like
# -*- lexical-binding: t; -*-
*bold*
is dispayed as
# -- lexical-binding: t; --
bold
where 'bold' is bold and '- lexical-binding: t; -' is not. Expected: In
comments emphasis marker characters are no emphasis markers and despite
hiding of emphasis markers, something
On 18 Sep 2019, Marco Wahl wrote:
>Karl Fogel writes:
>> Hi. It appears that commit d07d8ff4163 in Org Mode causes
>> square-brace-enclosed links to display incorrectly.
>>
>> The buggy behavior is simple to describe: if you write a link like this
>>
>> [[URL][LINK-TEXT]]
>>
>> then URL will
Hi.
Karl Fogel writes:
> Hi. It appears that commit d07d8ff4163 in Org Mode causes
> square-brace-enclosed links to display incorrectly.
>
> The buggy behavior is simple to describe: if you write a link like this
>
> [[URL][LINK-TEXT]]
>
> then URL will be displayed instead of LINK-TEXT
Hi. It appears that commit d07d8ff4163 in Org Mode causes
square-brace-enclosed links to display incorrectly.
The buggy behavior is simple to describe: if you write a link like this
[[URL][LINK-TEXT]]
then URL will be displayed instead of LINK-TEXT (and LINK-TEXT goes unused: URL
is still
Hello,
today I upgraded to emacs 26.3. and links don't show up correct anymore
with org-mode from git. The link is shown not the description.
Steps to reproduce:
=test.org=:
#+begin_src org
[[http://www.google.com][A Test link]]
#+end_src
: emacs -Q --find-file="test.org"
All links are
GNU Emacs 26.3 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.10) of
2019-08-29
Org mode version 9.2.6 (release_9.2.6-538-g23113f @
/home/w/borg/emacs/org/lisp/)
org-babel-tangle on
* A
#+BEGIN_SRC elisp :tangle yes :noweb yes
;; A
<>
#+END_SRC
* COMMENT B
#+BEGIN_SRC elisp :noweb-ref B
;; B
#+END_SRC
* COMMENT C
#+BEGIN_SRC elisp :tangle yes
;; C
#+END_SRC
produces a file with A and B in it. Expected:
Hi David
On Sat, Sep 7, 2019 at 1:14 AM David Masterson
wrote:
> Carsten Dominik writes:
>
> > On Thu, Sep 5, 2019, 00:45 David Masterson
> wrote:
>
> >> I see that, for tags picked up via inheritance from parent headlines,
> >> when the tags are produced in the agenda, the current agenda
Carsten Dominik writes:
> On Thu, Sep 5, 2019, 00:45 David Masterson wrote:
>> I see that, for tags picked up via inheritance from parent headlines,
>> when the tags are produced in the agenda, the current agenda item will
>> have an extra colon after the inherited tags. Is this by design?
maybe add org-lint to the after-save-hook - maybe something like
(untested)
(add-hook 'after-save-hook (lamda ()
(when (eq buffer-mode 'org-mode)
(org-lint
Christoph Groth writes:
> Nicolas Goaziou wrote:
>> Christoph Groth
You may also find the command M-x org-lint useful. I regularly run it on
my larger org files after an org release to spot problems in my org
files (either due to my error or changes in orgmode)
Tim
Christoph Groth writes:
> Nicolas Goaziou wrote:
>
>> Planning information (SCHEDULED,
On Thu, Sep 5, 2019 at 3:38 PM Christoph Groth
wrote:
> Nicolas Goaziou wrote:
>
> > Planning information (SCHEDULED, DEADLINE and CLOSED keywords) must
> > appear right after the headline, per Org syntax. This is specified at
> > the first paragraph in (info "(org) Deadlines and Scheduling").
>
Nicolas Goaziou wrote:
> Christoph Groth writes:
>
> > I understand now that Org does what it should. However, I find this
> > behavior quite dangerous. It caught me after more than 10 years of
> > using Org. If there's a list of long-term issues with Org
> > somewhere, this problem may
Christoph Groth writes:
> I understand now that Org does what it should. However, I find this
> behavior quite dangerous. It caught me after more than 10 years of
> using Org. If there's a list of long-term issues with Org somewhere,
> this problem may deserve being added to it.
I don't
Nicolas Goaziou wrote:
> Planning information (SCHEDULED, DEADLINE and CLOSED keywords) must
> appear right after the headline, per Org syntax. This is specified at
> the first paragraph in (info "(org) Deadlines and Scheduling").
>
> Elswhere, only the timestamp is meaningful to Org.
Thanks for
Hello,
Gustavo Barros writes:
> I hadn’t checked the commit back then, but now I was seeing if I could
> remove my local workaround on this and I noticed that while
> `org-latex-babel-language-alist' is now looking good,
> `org-latex-polyglossia-language-alist' was not changed. (This is so in
>
Hello,
Christoph Groth writes:
> With Org 9.2.3, the following two TODO items behave differently:
>
> ** TODO Something
> blabla
> SCHEDULED: <2019-09-01 Sun>
> [2019-09-05 Thu 14:39]
> ** TODO Something else
> SCHEDULED: <2019-09-01 Sun>
> foobar
> [2019-09-05 Thu 14:40]
>
> The first one
Dear org mode experts,
I have noticed the following behavior that (after reading the relevant
documentation) I find at least surprising and error-prone.
With Org 9.2.3, the following two TODO items behave differently:
** TODO Something
blabla
SCHEDULED: <2019-09-01 Sun>
[2019-09-05 Thu 14:39]
Hi Nicolas,
On Thu, Aug 15 2019, Nicolas Goaziou wrote:
Hello,
Gustavo Barros writes:
`org-latex-babel-language-alist' and
`org-latex-polyglossia-language-alist' have the language code for
Brazilian as =("bt-br" . "brazilian")=. I am a native Brazilian and
our language is Portuguese, and
Hi,
On Thu, Sep 5, 2019, 00:45 David Masterson wrote:
> I see that, for tags picked up via inheritance from parent headlines,
> when the tags are produced in the agenda, the current agenda item will
> have an extra colon after the inherited tags. Is this by design?
Yes, it is by design,
I see that, for tags picked up via inheritance from parent headlines,
when the tags are produced in the agenda, the current agenda item will
have an extra colon after the inherited tags. Is this by design? Can
that be controlled?
Example Parent :tag1:
Example child of Parent :tag1::
--
Hello,
Immanuel Litzroth writes:
> You want me to do that and send a new patch or are you going
> to do it after you apply the patch?
The former, if you don't mind.
Regards,
--
Nicolas Goaziou
You want me to do that and send a new patch or are you going
to do it after you apply the patch?
Regards,
Immanuel
On Mon, Sep 2, 2019 at 9:41 PM Nicolas Goaziou wrote:
>
> Hello,
>
> immanuel writes:
>
> > When org-edit-src-code is called with org-window-setup equal to
> > 'split-window-below
Hello,
immanuel writes:
> When org-edit-src-code is called with org-window-setup equal to
> 'split-window-below or 'split-window-right it will keep splitting the
> window if the mouse is clicked on the src block in the org buffer.
> This patch tries to address that
[...]
> +(defun
No problem! I have some more coming up :-)
I've been looking at getting org-babel to add line directives for
languages that support it.
(c, c++, haskell...). It would make literate programming for these
kinds of languages much
better, and other people have been complaining e.g.
Remember to cover the basics, that is, what you expected to happen and
what in fact did happen. You don't know how to make a good report? See
https://orgmode.org/manual/Feedback.html#Feedback
Your bug report will be posted to the Org mailing list.
Hello,
immanuel writes:
> #+NAME: this is a test
> #+BEGIN_SRC elisp :tangle no
>
> (message \"aha\") #+END_SRC
>
> #+BEGIN_SRC elisp :noweb yes :comments noweb :tangle out.el
> first
> <>
> second
> #+END_SRC
>
> #+BEGIN_SRC elisp :tangle no
> (progn
> (org-babel-tangle)
> (with-temp-buffer
>
Remember to cover the basics, that is, what you expected to happen and
what in fact did happen. You don't know how to make a good report? See
https://orgmode.org/manual/Feedback.html#Feedback
Your bug report will be posted to the Org mailing list.
Remember to cover the basics, that is, what you expected to happen and
what in fact did happen. You don't know how to make a good report? See
https://orgmode.org/manual/Feedback.html#Feedback
Your bug report will be posted to the Org mailing list.
I think I agree with Julius. While it may be a legitimate use case, the
risk that it will break other use cases seems a bit high (I've never run
into this issue in many years of org use).
Perhaps add another document 'type' into 'org-latex-classes which adds
the xpatch and associated change to
Hi folks,
Am 27.08.19 um 08:57 schrieb Vladimir Nikishkin:
> I have indeed investigated the issue, and this is the link:
> https://latex.org/forum/viewtopic.php?f=47=32788
>
> To make the long story short, the folowing trick is needed to allow
> page breaks after headings (which is a completely
I have indeed investigated the issue, and this is the link:
https://latex.org/forum/viewtopic.php?f=47=32788
To make the long story short, the folowing trick is needed to allow
page breaks after headings (which is a completely standard case in
-org).
#+begin_src latex
\usepackage{xpatch}
Hi Vladimir,
I see two problems in the generated LaTeX-file you'd need to address.
First, LaTeX has problems handling URLs in section (or subsection)
headers. That's one of the reasons LaTeX chokes on the second run of
that file -- it's only partially generated, not completely.
The second is
Hello,
Vladimir Nikishkin writes:
> I have a problem in that when I try to export an .org file into latex/pdf,
> long sections are not wrapped to the next page, but are truncated instead.
>
> The result is on the picture (points 10.34 to 10.37 missing), and the
> (not)working example is
Hello, friends!
I have a problem in that when I try to export an .org file into latex/pdf,
long sections are not wrapped to the next page, but are truncated instead.
The result is on the picture (points 10.34 to 10.37 missing), and the
(not)working example is attached to this email.
--
Remember to cover the basics, that is, what you expected to happen and
what in fact did happen. You don't know how to make a good report? See
https://orgmode.org/manual/Feedback.html#Feedback
Your bug report will be posted to the Org mailing list.
Hello,
immanuel writes:
> Try this in a buffer (results are also here for quick reference):
>
> #+NAME: start
> #+BEGIN_SRC emacs-lisp :tangle no
>
> (message "start") #+END_SRC
>
> #+NAME: end
> #+BEGIN_SRC emacs-lisp :tangle no
>
> (message "end") #+END_SRC
>
> #+BEGIN_SRC emacs-lisp :tangle
Remember to cover the basics, that is, what you expected to happen and
what in fact did happen. You don't know how to make a good report? See
https://orgmode.org/manual/Feedback.html#Feedback
Your bug report will be posted to the Org mailing list.
Nicolas Goaziou writes:
It changed between Org 9.2 and Org 9.3, for every language. There is an
ORG-NEWS entry about it, namely:
*** ~:file~ header argument no longer assume "file" ~:results~
Thank you. I read that entry and others concerning ;file prior to
posting and it did not
Remember to cover the basics, that is, what you expected to happen and
what in fact did happen. You don't know how to make a good report? See
https://orgmode.org/manual/Feedback.html#Feedback
Your bug report will be posted to the Org mailing list.
Hello,
Charles Millar via Emacs-orgmode writes:
> Now a "just curious," comment and question:
>
> I had a few files that used the ECM source code block, just many more
> entries in each. The last time that I evaluated any of them was last
> October and it produced the results I expected, i.e. I
On 8/23/19 4:15 AM, Nicolas Goaziou wrote:
Hello,
Charles Millar via Emacs-orgmode writes:
#+begin_src sh :file test.rec
cat << EOF
# -*- mode: rec -*-
%rec: somerecord
Account: something
Amount: 0.00
end of file
EOF
#+end_src
I expect that when I execute the above code block that
Hello,
Charles Millar via Emacs-orgmode writes:
> #+begin_src sh :file test.rec
> cat << EOF
> # -*- mode: rec -*-
>
> %rec: somerecord
>
> Account: something
> Amount: 0.00
>
> end of file
> EOF
>
> #+end_src
>
> I expect that when I execute the above code block that
>
> 1. An
Org mode version 9.2.5 (release_9.2.5-494-g4848b8 @
/usr/local/share/org-mode/lisp/)
GNU Emacs 27.0.50 (build 59, x86_64-pc-linux-gnu, GTK+ Version 3.24.10)
of 2019-08-22
ECM
#+begin_src sh :file test.rec
cat << EOF
# -*- mode: rec -*-
%rec: somerecord
Account: something
Amount: 0.00
Hello,
Christian Dietrich writes:
> I think a found a bug in org-babel-tangle-file. It closes an user-opened
> buffer if called with a symlink that points to the same file. Please see
> the attached patch, which fixes the problem for me.
Applied. Thank you!
Regards,
--
Nicolas Goaziou
Remember to cover the basics, that is, what you expected to happen and
what in fact did happen. You don't know how to make a good report? See
https://orgmode.org/manual/Feedback.html#Feedback
Your bug report will be posted to the Org mailing list.
A follow up
On 8/20/19 9:32 AM, Charles Millar via Emacs-orgmode wrote:
In an org file I have a source code block to convert entries into and
generate a recutils file
#+begin_src sh?? :file SomeFile.rec
cat << EOF
# -*- mode: rec -*-
Begin recutils file
Approximately 770 records in
In an org file I have a source code block to convert entries into and
generate a recutils file
#+begin_src sh?? :file SomeFile.rec
cat << EOF
# -*- mode: rec -*-
Begin recutils file
Approximately 770 records in recutils format each with about 20 entries;
over 17,000 lines including line
Hi!
I think a found a bug in org-babel-tangle-file. It closes an user-opened
buffer if called with a symlink that points to the same file. Please see
the attached patch, which fixes the problem for me.
chris
Emacs : GNU Emacs 27.0.50 (build 5, x86_64-pc-linux-gnu, GTK+ Version 3.24.0)
of
Remember to cover the basics, that is, what you expected to happen and
what in fact did happen. You don't know how to make a good report? See
https://orgmode.org/manual/Feedback.html#Feedback
Your bug report will be posted to the Org mailing list.
Remember to cover the basics, that is, what you expected to happen and
what in fact did happen. You don't know how to make a good report? See
https://orgmode.org/manual/Feedback.html#Feedback
Your bug report will be posted to the Org mailing list.
1 - 100 of 9192 matches
Mail list logo
