c.bu...@posteo.jp writes:
> Am 29.04.2022 15:49 schrieb Ihor Radchenko:
>> Exactly because you are actively trying to understand the syntax, you
>> are in unique situation where you can easily see all the "opaque"
>> places
>> in the syntax description.
>
> I still don't know if I misunderstand
Pascal Grossé writes:
> I managed to track the bug to *ob-scheme.el*:
>
> in (defun org-babel-scheme-execute-with-geiser, on line 179, simply
> replace geiser-eval-region with geiser-eval-region/wait so that the
> temporary result buffer doesn't close too soon. It then works as
> expected.
Rodrigo Morales writes:
>> For this reason, I am wondering whether there is a way to make
>> =org-agenda-entry-text-mode= to show the drawers without much
>> tinkering.
>>
>
> After inspecting the source code of Org Mode, I managed to do what I was
> searching by deleting the relevant part of
Hi,
Consider the following timestamp with a typo in starting minute:
<2022-04-11 Mon 17:1-19:10>
Running org-element-context yields a timestamp object with unexpected
properties:
(timestamp
(:type active :raw-value "<2022-04-11 Mon 17:1-19:10>"
:year-start 2022 :month-start 4 :day-start 11
Damien Couroussé writes:
> Please find attached a small patch for org-depend, which fixes a bug
> (function 'remove-if' is unknown).
> - (setq items (remove-if
> + (setq items (org-remove-if
org-remove-if is itself obsolete :)
I applied a slightly different change
Stefan Kangas writes:
> The attached patch removes some compat code for XEmacs, and Emacs 21/22.
Thanks! And sorry for the late reply.
The patch does not apply onto current main anymore.
Would you mind updating the patch?
Best,
Ihor
Tak Kunihiro writes:
> Thank you for the patch. I applied the patch to org-table.el on Emacs
> 28.0.90.
>
> And I still see the problem there. Is the problem solved by the patch
> on your environment?
The problem was solved on my side, but _not_ using your reproducer
explicitly. If I save the
Tak Kunihiro writes:
> Thank you for the patch. I applied the patch to org-table.el on Emacs
> 28.0.90.
>
> And I still see the problem there. Is the problem solved by the patch
> on your environment?
The problem was solved on my side, but _not_ using your reproducer
explicitly. If I save the
Ihor Radchenko writes:
> Should we consider the above CLOCK line as a valid running clock or
> maybe it should be parsed as a paragraph?
Nicolas, do you have any comment on this? I am inclined to treat
CLOCK: [2021-10-22 Fri 10:41]--[2021]
as a paragraph, not a clock line.
Best,
Ihor
Matt Price writes:
> I'm having trouble with org-attach-attach if my current buffer is visiting
> a filepath starting with "~/". This trivial patch fixes the problem for me
> by running (expand-file-name) on the file before attaching. I always use
> the 'lns method, so I don't know whether it
On Fri, 29 Apr 2022 11:03:55 -0400 Juan Manuel Macías
wrote
> I don't know if anyone has had a similar experience...
I tell people that Emacs changed my life. I feel it's that profound. My story
is different from yours, yet similar in that it started with Org. I love that
it
I configured a fresh emacs 28 installation to include the package
geiser-guile.
I tried to evaluate this simple org block (after activating scheme with
babel of course):
#+begin_src scheme :session test
(define x 42)
x
#+end_src
I get:
#+RESULTS:
The *Geiser Messages* buffer shows this:
On 4/29/22 07:22, Max Nikulin wrote:
It was still working in most real-life cases.
Yes, the current code breaks only in fine-grained cases. Most of the
time it'll work fine since people rarely compile the same file twice in
the same second.
From my point of view, it is better to rewrite
I agree. There is no reason to think this should not work. I have been down
this road myself in wished it did.
From: Emacs-orgmode On Behalf
Of Ihor Radchenko
Sent: Thursday, April 28, 2022 9:41 AM
To: Eros Zaupa
Cc: emacs-orgmode@gnu.org
Subject: Re: [BUG] org-mode #+SETUPFILE not working
Hi all,
Since I use Org Mode I have been noticing a gradual change in the way I
work with a computer (as a simple user). It is not something consciously
sought, but I have to say that I see it as a positive evolution. I've
always been used to (or rather resigned to) the typical Unix
Hi,
Ihor Radchenko writes:
prin1-to-string is too specific and only solves a single use-case.
prin1-to-string is actually universal in a way, since any other
manipulation can then be achieved with
: (setq var (do-something <>))
at least as long as you're tangling to a programming language,
Dear Ihor,
thanks for your reply.
Am 29.04.2022 15:49 schrieb Ihor Radchenko:
Exactly because you are actively trying to understand the syntax, you
are in unique situation where you can easily see all the "opaque"
places
in the syntax description.
I still don't know if I misunderstand the
On 29/04/2022 05:27, Paul Eggert wrote:
On 4/27/22 09:55, Stefan Monnier wrote:
Instead of rounding the times to whole seconds, wouldn't it make more
sense to check that the difference is larger than 1s?
org-file-newer-than-p is intended to work on filesystems like HFS+ that
store just the
c.bu...@posteo.jp writes:
> This is about https://orgmode.org/worg/dev/org-syntax.html#Plain_Lists
>
> Comparing the syntax description and the real world behaviour of my
> Emacs 27 with org from yesterday it seems to me that the syntax
> description is not correct.
>
> I cite "Plain Lists"
c.bu...@posteo.jp writes:
> Am 29.04.2022 15:04 schrieb Detlef Steuer:
>> But *first* it should be easily read- and writable by humans and only
>> then easily parseble by parsers! At least imho.
>
> I agree and understand that this is one of the design principals of Org.
>
> But even for humans
c.bu...@posteo.jp writes:
> Sidenote: As someone who writes software that parse org-content I would
> suggest to make the whitespace in front of a list item mandatory even
> for "-" and "+". It would reduce code complexity.
It might probably simplify things for third-party parsers. Not for
c.bu...@posteo.jp writes:
> Am 29.04.2022 14:15 schrieb Ihor Radchenko:
>> Would you be interested to contribute an example to
>> https://orgmode.org/worg/dev/org-syntax.html#Items ?
>
> Not sure what you mean. Currently I just try to understand the syntax
> and get the hard rules for my own
Dear Detlef
Am 29.04.2022 15:04 schrieb Detlef Steuer:
But *first* it should be easily read- and writable by humans and only
then easily parseble by parsers! At least imho.
I agree and understand that this is one of the design principals of Org.
But even for humans the current situation is
Am Fri, 29 Apr 2022 12:17:24 +
schrieb c.bu...@posteo.jp:
> Sidenote: As someone who writes software that parse org-content I
> would suggest to make the whitespace in front of a list item
> mandatory even for "-" and "+". It would reduce code complexity.
But *first* it should be easily
Am 29.04.2022 14:15 schrieb Ihor Radchenko:
Would you be interested to contribute an example to
https://orgmode.org/worg/dev/org-syntax.html#Items ?
Not sure what you mean. Currently I just try to understand the syntax
and get the hard rules for my own parser. ;)
- List item with
I need to add something here and think the syntax description should be
updated about that.
A "*" is allowed or recognized as a list item instead as a head only if
there is one (or maybe more) whitespace space in front of it.
But "-" and "+" also recognized as starts for list items without
c.bu...@posteo.jp writes:
> I cite from there
> "An asterisk, hyphen, or plus sign character (i.e., *, -, or +)."
>
> I wonder why * is allowed because * also starts a heading. So how does a
> piece of software/parser decide if a line starting with an * is a
> heading or a list item?
Headlines
This is about https://orgmode.org/worg/dev/org-syntax.html#Plain_Lists
Comparing the syntax description and the real world behaviour of my
Emacs 27 with org from yesterday it seems to me that the syntax
description is not correct.
I cite "Plain Lists" section:
"If first item in a plain list
I was looking into https://orgmode.org/worg/dev/org-syntax.html#Items to
find out which characters are allowed as "bullets" for unorderd lists.
I cite from there
"An asterisk, hyphen, or plus sign character (i.e., *, -, or +)."
I wonder why * is allowed because * also starts a heading. So how
Kaushal Modi writes:
> It's not time-critical, but it would be good to fix this bug. It's not
> just the Org link syntax.. any Org markup is fontified inside the src
> blocks. Here's a screenshot (attached) that shows the bold
> fortification happen in the src block as well.
Emphasis should not
>> Link display not working for orgroam links as items in enumeration
Could you elaborate what about what you did, what you expected, and what
you actually observed? It is very hard for us to guess what "not
working" means.
Please refer to https://orgmode.org/manual/Feedback.html for more
Alan Ruttenberg writes:
> I propose that the package determination be changed to
>
> (or (cdr (assq :package params)) (funcall org-babel-lisp-package-fn))
>
> with org-babel-lisp-package-fn being bound analogous to how
> org-babel-lisp-eval-function is:
>
> (require (pcase
32 matches
Mail list logo
