> Date: Mon, 18 Apr 2022 19:02:03 -0700
> From: Paul Eggert
> Cc: emacs-orgmode@gnu.org, 54...@debbugs.gnu.org
>
> From 8c25372709d256d83858be454987137dc202b725 Mon Sep 17 00:00:00 2001
> From: Paul Eggert
> Date: Mon, 18 Apr 2022 13:08:27 -0700
> Subject: [PATCH 3/6] Add Gnulib gettime-res modu
"N. Jackson" writes:
> No, it doesn't happen just with emacs -Q.
>
> I have bisected my init file and narrowed it down to this setting in
> my custom-set-variables:
>
> '(fringe-mode '(nil . 0) nil (fringe))
>
>
> Here is a recipe to reproduce the problem from emacs -Q:
Thanks! I was able to r
"Tory S. Anderson" writes:
>> Thanks for reporting! Are you able to reproduce with emacs -Q?
>
> Thanks! I am not sure what an emacs -Q would mean in cases like this, since
> they are custom written capture templates in the first place, so -Q would
> lose them.
Please refer to https://orgmode
"Bruce D'Arcus" writes:
> Just to clarify, I don't believe the discussion is to add such styles to
> the included org-cite processors (which already support such
> functionality), but rather to allow it, for example for third party ones;
> say a hypothetical org-ref one.
Sure. However, the discu
Eduardo Suarez-Santana writes:
> Would you consider this as a bug?
Yep.
Confirmed.
Best,
Ihor
Olaf Dietsche writes:
> This seems much more useful than the non-working "repair" of
> org-set-property.
FYI, even repair is no longer there in the latest Org release.
In future, I recommend running org-lint. It is usually able to catch
this and similar problems in Org files regardless of Org ve
Here are the main points I see about making timestamps work better in
Org mode, and related patches to how Emacs handles timestamps.
* Max would like encode-time to treat a list (SS MM HH DD MM ) as if
it were (SS MM HH DD MM nil -1 nil), as that would be more
convenient for how Org m
Olaf Dietsche writes:
> thank you for the link to the org-repair-property-drawers function.
> This seems much more useful than the non-working "repair" of
> org-set-property.
>
In addition, I expect (but have not tested) that `M-x org-lint` might
be helpful here and in similar situations.
--
N
At 21:39 +0800 on Monday 2022-04-18, Ihor Radchenko wrote:
> "N. Jackson" writes:
>
>> Recently it seems as if Org Agenda thinks its window is one
>> character wider than it actually is. The incorrect behaviour I
>> observe is:
>
> I do not see any issues on both stable bugfix and main branches.
thank you for the link to the org-repair-property-drawers function.
This seems much more useful than the non-working "repair" of
org-set-property.
Kind regards, Olaf
Ihor Radchenko writes:
> Olaf Dietsche writes:
>
>> I would expect, that the order of drawers doesn't matter.
>
> The order of d
Ihor Radchenko writes:
> web...@toryanderson.com (Tory S. Anderson) writes:
>
>> Second, most of my plain (just me typing entries) captures fail to complete
>> at all.
>>
>> =org-capture: Capture abort: Wrong type argument: avl-tree-, nil
>> This is sending me back years to before I developed a
web...@toryanderson.com (Tory S. Anderson) writes:
> Second, most of my plain (just me typing entries) captures fail to complete
> at all.
>
> =org-capture: Capture abort: Wrong type argument: avl-tree-, nil
> This is sending me back years to before I developed a nicely tuned org
> workflow, and
Org captures have become an intrinsic part of my daily workflow, but having
just upgaded emacs and orgmode, I suddenly find two errors (which clearly have
related causes, at least as far as the upgrades go).
First, when I create a new capture link from a Gnus message, it successfully
creates th
Actually big thanks to your response; it prompted me to figure out how to
update my emacs, which I built from source a year or two ago when I wanted to
give native comp a whirl. It was a process, but was eventually successful.
The error was auto-reported when it popped up, and I decided to give
"N. Jackson" writes:
> Recently it seems as if Org Agenda thinks its window is one
> character wider than it actually is. The incorrect behaviour I
> observe is:
>
> 1. Tags in Agenda are all wrapped to the next line even though there
> is plenty of space to display them on the same
> line. (org-
"N. Jackson" writes:
> Recently it seems as if Org Agenda thinks its window is one
> character wider than it actually is. The incorrect behaviour I
> observe is:
I do not see any issues on both stable bugfix and main branches.
Are you able to reproduce starting from emacs -Q?
(see https://orgm
Hi,
I finally found a way to make the following example work
<===>
#+HEADER: :file test1.svg
#+HEADER: :exports results
#+HEADER: :results output silent graphics file
#+HEADER: :headers '("\\usepackage{tikz}")
#+begin_src latex
\begin{tikz
Recently it seems as if Org Agenda thinks its window is one
character wider than it actually is. The incorrect behaviour I
observe is:
1. Tags in Agenda are all wrapped to the next line even though there
is plenty of space to display them on the same
line. (org-agenda-tags-column is set to its d
On Mon, Apr 18, 2022, 5:08 AM Ihor Radchenko wrote:
> John Kitchin writes:
>
> >> In contrast, [cite/citet*:@key] is likely to be used fairly frequently
> >> and has much higher chance to break things.
> >
> >
> > We have had a citet*:key link (and all the other * variants) for a long
> > time i
Olaf Dietsche writes:
> I would expect, that the order of drawers doesn't matter.
The order of drawers does matter since Org 8.3. See
https://orgmode.org/worg/org-release-notes.html#org7a85d9d
Best,
Ihor
I have this example org file and started with "emacs -Q":
---8<---
* Headline
:CLOCK:
CLOCK: [2022-04-18 Mo 11:17]--[2022-04-18 Mo 11:17] => 0:00
:END:
:PROPERTIES:
:CREATED: [2022-04-18 Mo 11:17]
:END:
- Some text
--->8---
When I try to set a property "C-c C-x p" or "M-x org-set
John Kitchin writes:
>> In contrast, [cite/citet*:@key] is likely to be used fairly frequently
>> and has much higher chance to break things.
>
>
> We have had a citet*:key link (and all the other * variants) for a long
> time in org-ref, with no reported issues I can recall.
I respect your expe
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, th
23 matches
Mail list logo
