> Date: Wed, 20 Apr 2022 17:11:34 -0700
> Cc: maniku...@gmail.com, emacs-orgmode@gnu.org, 54...@debbugs.gnu.org,
> bug-gnu...@gnu.org
> From: Paul Eggert
>
> On 4/20/22 12:30, Eli Zaretskii wrote:
>
> > I see the time samples change in jumps of 15 msec.
>
> Could you give the first part of the
At 13:25 +0800 on Thursday 2022-04-21, Ihor Radchenko wrote:
>
> Attaching the patch.
Great. I tested the patch (with Org mode version 9.5.3) and that
fixes the problem for the block separator wrapping.
However, the problem with the tags wrapping in Agenda (instead of
being right aligned) remai
Hello,
Ihor Radchenko writes:
> Rudolf Adamkovič writes:
>
> The idea sounds good and having tests is very good. Though I am not
> expert in texinfo. CC-ing Nicolas. He is the maintainer.
My Texinfo 6.7 manual does not contain any reference to displaymath
environment, which is used throughout
Hi Ihor,
thanks for double-checking this.
Ihor Radchenko writes:
> Since the actual patch does not have the problem, I'd prefer to ignore
> this problem unless it appears again after merging.
Sure - can you point the exact branch/commit I should test for the
version that will be merged?
--
Edouard Debry [2022-04-21 Thu 00:58] wrote:
> Thanks for offering to maintain 'ox-latex.el'.
>
> One of the thing that could be improved is the generation of svg
> images through tikz. Currently, unless I am mistaken, it does
> not work well. I had to tweak 'ox-latex.el' to make it work again.
> I
Hello,
Bastien writes:
> Daniel Fleischer writes:
>
>> I would like to maintain the 'ox-latex.el' file. It's one of the many
>> files created by Nicolas but few of the files that are not maintained
>> (by him). I have a long experience (14) with latex and relatively long
>> experience with org-
Hello Ihor,
At 03:16 -0400 on Thursday 2022-04-21, N. Jackson wrote:
>
> However, the problem with the tags wrapping in Agenda (instead of
> being right aligned) remains.
I believe the problem with the wrapping of the Agenda tags is here:
(defun org-agenda-align-tags (&optional line)
"Al
Dear all,
I am continuing my experiment with Org mode meetups and online
debugging.
This time, I plan to
1. Talk about contributing patches to Org
- Applying patches sent by others
- Testing changes (make test)
- Creating patches
- Sending patches to the mailing list
2. Talk about and
Hello,
Ihor Radchenko writes:
> "Bruce D'Arcus" writes:
>
>> On Sun, Apr 3, 2022 at 5:07 PM John Kitchin wrote:
>>>
>>> I was looking into using latex commands as styles in org-cite, e.g.
>>>
>>> [cite/citet:@key]. That example works fine, but [cite/citet*:@key] is not
>>> allowed. Could that
Bastien writes:
>> Since the actual patch does not have the problem, I'd prefer to ignore
>> this problem unless it appears again after merging.
>
> Sure - can you point the exact branch/commit I should test for the
> version that will be merged?
https://github.com/yantar92/org/tree/feature/org
Ihor Radchenko writes:
> https://github.com/yantar92/org/tree/feature/org-fold-universal-core-tidy
Thanks -- I confirm the bug I reported is not present in this branch.
--
Bastien
Nicolas Goaziou writes:
>> Rudolf Adamkovič writes:
>>
>> The idea sounds good and having tests is very good. Though I am not
>> expert in texinfo. CC-ing Nicolas. He is the maintainer.
>
> My Texinfo 6.7 manual does not contain any reference to displaymath
> environment, which is used throughou
Hi folks
Long time!!!
Hope you folks are doing well in these bizarre times
Can someone help me to write a filter (or some such) so that headings like
--
*** Recursion before Iteration :L:
Lorem ipsum etc
get transformed to
--
*** Dummy :ignore:
#+b
Nicolas Goaziou writes:
>> Note that inserting zero-width space will not only be awkward here, but
>> also breaks parser: e.g. [cite/citet:@key] is not currently
>> recognised as a citation.
>
> I think the zero-width space can be inserted on the other side.
Could you elaborate? In the following
Hello,
I recently switched to Emacs 28 and stumpled upon a call in org-refile to
define-obsolete-function-alias which doesn't have the 'when' parameter.
As Emacs 28 has made the 'when' parameter mandatory, this is a problem
for me.
Attached is a tiny patch against the git repo which I cloned toda
On Thu, Apr 21, 2022 at 12:23 PM tony aldon
wrote:
> You're right I was effectively missing affiliated keywords and so my
> patch is wrong.
>
> Thank you for your quick feedback and insight.
>
> Have a nice day,
> Tony Aldon
>
> On Thu, Apr 21, 2022 at 7:39 AM Ihor Radchenko wrote:
>
>> tony ald
Ihor Radchenko writes:
> Nicolas Goaziou writes:
>
>>> Rudolf Adamkovič writes:
>>>
>>> The idea sounds good and having tests is very good. Though I am not
>>> expert in texinfo. CC-ing Nicolas. He is the maintainer.
>>
>> My Texinfo 6.7 manual does not contain any reference to displaymath
>> e
Ihor Radchenko writes:
>> I think the zero-width space can be inserted on the other side.
>
> Could you elaborate? In the following example, inserting zero-width
> space at *bold will break the intended bold emphasis *bold ... here*.
>
> Some *bold emphasis with reference [cite/citet*:@key] will
Ryan Scott writes:
> Here's my latest patch.
> Uses special :dir value 'attach to use attachment directory as working dir.
> Now prompts to create IDs for nodes that are missing.
> Solved a handful of issues with my previous versions of this and I've been
> using it regularly for a bit now.
>
> I
Patch marked as cancelled.
Nicolas Goaziou writes:
>>> My Texinfo 6.7 manual does not contain any reference to displaymath
>>> environment, which is used throughout the patch. Where is it coming
>>> from?
>>
>> I do see @displaymath in my TeXinfo 6.8. Also,
>> https://www.gnu.org/software/texinfo/manual/texinfo/html_node/I
Nicolas Goaziou writes:
> I had your
>
> *bold [cite:citet*:@key]
>
> example in mind. Sure, if bold jumps across the citation this is
> different. I'm not sure this is something that is frequent enough to
> worry.
According to Prof. Kitchin, it is not frequent. However, if it does
happen it w
Kambiz Darabi writes:
> I recently switched to Emacs 28 and stumpled upon a call in org-refile to
> define-obsolete-function-alias which doesn't have the 'when' parameter.
> As Emacs 28 has made the 'when' parameter mandatory, this is a problem
> for me.
>
> Attached is a tiny patch against the g
Hi,
On 2022-04-21 21:55 +08, Ihor Radchenko wrote:
> Are you sure that you cloned the repo we mention at
> https://orgmode.org/?
>
> The change you are suggesting is already in Org 9.5.3 and that alias has
> been moved to org-compact.el long time ago.
awfully sorry for the noise!
I manage my p
Yeah I just recently updated my fourth and realized there were some
necessary conflicts to resolve with the latest.
I'll take a look at addressing these issues and submit an updated patch.
Surprised I missed a calling location and secretly hope that it was added
recently for the sake of my poor eg
On 17/04/2022 02:23, Paul Eggert wrote:
On 4/15/22 10:23, Max Nikulin wrote:
if you are storing future events bound to wall time then namely time
zone identifier should have precedence.
Although that would make sense for some applications it's not a good
idea in general. For example, if you'
The avl-tree error was an issue with vertico, which I updated and it went away.
The Gnus Links error seems to have gone away with that updgrade, too.
Thanks!
- Tory
Ihor Radchenko writes:
> "Tory S. Anderson" writes:
>
>>> Thanks for reporting! Are you able to reproduce with emacs -Q?
>>
>> T
What appears to be happening here is that the MS-Windows native
timestamp resolution is 1/64th of a second, and your system's clock is
offset by 0.0075 s from an integer boundary. I.e., the timestamps in
increasing order are:
...
1650522862 + 62/64 + 0.0075 = 1650522862.976250
1650522862
> Date: Thu, 21 Apr 2022 16:56:25 -0700
> Cc: maniku...@gmail.com, emacs-orgmode@gnu.org, 54...@debbugs.gnu.org,
> bug-gnu...@gnu.org
> From: Paul Eggert
>
> What appears to be happening here is that the MS-Windows native
> timestamp resolution is 1/64th of a second, and your system's clock is
Javier Olaechea writes:
> org-comment-line-break-function does not handle fill-prefix being set to
> nil, which is the default value for fill-prefix. This means that pressing
> M-j inside an org-mode buffer in a vanilla installation of Emacs results in
> an error. From looking at other callers of
"N. Jackson" writes:
> (- (window-text-width))
> ^
>
> Changing window-text-width to window-max-chars-per-line fixes the
> problem here and seems like the right thing to do.
Sounds reasonable.
Attach
Ryan Scott writes:
> With all of the layers and assumptions/behaviors inherent in the way src
> block parameters are handled, do you feel like this is an approach that can
> work, or should it be abandoned?
I am not sure if I understand your concern.
Your code is reusing the existing convention
Great. Just making sure that this particular approach to this feature or
type of feature wasn't fundamentally flawed given the established behavior
of org.
Thanks.
On Thu, Apr 21, 2022 at 11:02 PM Ihor Radchenko wrote:
> Ryan Scott writes:
>
> > With all of the layers and assumptions/behaviors
Hi
Given a header with properties, to which I want to add a new property
via org-set-property. That works but the new property is added at the
end of all properties not directly below by cursor.
#+begin_src
* Properties
:PROPERTIES:
:ID: f76a5b78-919c-4375-a5d5-b0d0f3f071da
:StE
Hi
I am looking for convenient method to generate a weekly calendar in
table form that looks like
#+begin_src
| Hours | Mon | Tue | Wed | Thu | Fri |
| 8:00-9:00 | | | | | |
| 9:00-10:00 | | | | | |
| | | | | | |
35 matches
Mail list logo
