Yes, please!
--
Daniel Ortmann
https://www.linkedin.com/in/danieldeanortmann/
https://ieee-collabratec.ieee.org/app/p/DanielDeanOrtmann/
612-518-3147 m
On 1/29/24 14:03, Juan Manuel Macías wrote:
Hi,
In last December, issue 23 of the "Revista de Estudios Latinos" (Journal
of Lat
quot;
And that's ok! :-)
Thank you for your attention to this matter which now is clearly smaller
than expected.
On 10/16/23 02:38, Ihor Radchenko wrote:
Daniel Ortmann writes:
No, no, not clock check mode.
- I created a TODO with a scheduled time that repeats. When completed
it remains a
ock time" again is correctly recorded in the log.
I hope the screen captured images came across in the previous email?
They should help explain.
On 10/15/23 04:00, Ihor Radchenko wrote:
Daniel Ortmann writes:
In the last entry below, the "Clocked:" part of the log would have
showe
blem fixed ... but it would be nice to know it was not an accidental fix.
Thank you! You can close it or investigate further at your discretion.
On 10/15/23 03:39, Ihor Radchenko wrote:
Daniel Ortmann writes:
I have a repeatedly-scheduled TODO with this entry for the schedule:
SCHEDULED: &
24.37, cairo version 1.16.0)
of 2023-10-14
Package: Org mode version 9.7-pre (release_9.6.10-840-g9fcbd1 @
/home/d/src/git-org-mode/lisp/)
--
Daniel Ortmann 612-518-3147 m
key: C9E170E2, fingerprint = 81BB 6CAF F1EC F6C7 690C F4E9 66D7 7AFD
C9E1 70E2
Fix confirmed.
Thank you!
On 10/12/23 03:21, Ihor Radchenko wrote:
Daniel Ortmann writes:
org-element--generate-copy-script: Symbol\u2019s function definition is
void: org-export--list-bound-variables
Sorry. Silly mistake in a recent commit.
Fixed, on main.
https://git.savannah.gnu.org
, GTK+ Version
3.24.37, cairo version 1.16.0)
of 2023-10-11
Package: Org mode version 9.7-pre (release_9.6.10-827-ge15699 @
/home/d/src/git-org-mode/lisp/)
--
Daniel Ortmann 612-518-3147 m
key: C9E170E2, fingerprint = 81BB 6CAF F1EC F6C7 690C F4E9 66D7 7AFD
C9E1 70E2
to 1970.
(Yes, I am replying to the correct thread which corresponds to the bug
report submitted.)
On 3/22/23 10:10, Ihor Radchenko wrote:
Daniel Ortmann writes:
Since that existing timestamp at point is supposed to be used as the
default, we definitely have a bug
==>> ... Since that 'd
chenko wrote:
Daniel Ortmann writes:
file org-plain-date-to-date-time.org has:
* plain date
C-c ! gives:
[2023-02-21 Tue]
* updating plain date
C-c ! followed by C-u C-! gives:
[2023-02-21 Tue 00:00]
* date-time
C-u C-c ! gives:
[2023-02-21 Tue 14:13]
I expected that updating an existing date with
:
On 20/03/2023 08:56, Daniel Ortmann wrote:
Starting with this manually-typed birthday date:
[1960-10-16]
Use the arrows to move to the text.
Now press C-c ! and then ENTER
I expected this result, i.e. I expected the day of the week to be added:
[1960-10-16 Sun]
If all what you need is to add day
, x86_64-pc-linux-gnu, GTK+ Version
3.24.34, cairo version 1.16.0)
of 2023-03-19
Package: Org mode version 9.7-pre (release_9.6.1-306-ga645a6 @
/home/d/src/git-org-mode/lisp/)
--
Daniel Ortmann 612-518-3147 m
key: C9E170E2, fingerprint = 81BB 6CAF F1EC F6C7 690C F4E9 66D7 7AFD
C9E1 70E2
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.
11.99% of cache searches hashed, 12.16% non-hashable.
13 hours, 20 minutes, 43 seconds
On 2/9/23 05:51, Ihor Radchenko wrote:
Hi,
I would like to assess the efficiency of one of search optimizations used
in org-element.el [1]
The statistics about efficiency is collected by Org, but obviously
log entries going back to
2013. :-)
On 10/20/22 00:37, Ihor Radchenko wrote:
Daniel Ortmann writes:
(The performance drop was sudden and steep, by the way.)
It is because clocking now calls Org parser API.
https://urldefense.com/v3/__https://git.savannah.gnu.org/cgit/emacs/org-mode.git
Works great!
On 11/22/22 00:02, Daniel Ortmann wrote:
No objections.
On 11/21/22 20:12, Ihor Radchenko wrote:
Daniel Ortmann writes:
I am happy with whatever you decide. :-)
Then, here is a tentative patch introducing new :results ignore header
argument.
Any objections?
No objections.
On 11/21/22 20:12, Ihor Radchenko wrote:
Daniel Ortmann writes:
I am happy with whatever you decide. :-)
Then, here is a tentative patch introducing new :results ignore header
argument.
Any objections?
I am happy with whatever you decide. :-)
On 11/20/22 20:34, Ihor Radchenko wrote:
Daniel Ortmann writes:
Please see attached which has the following code which reproduces the issue:
#+begin_src sh :shebang #!/bin/bash :results none
for (( i=1500 ; i>0 ; i-=1 ))
do
head -c 6 /
Please see attached which has the following code which reproduces the issue:
#+begin_src sh :shebang #!/bin/bash :results none
for (( i=1500 ; i>0 ; i-=1 ))
do
head -c 6 /dev/urandom | uuencode -m -
done |
tee /dev/null
#+end_src
On 11/18/22 02:45, Ihor Radchenko wrote:
Daniel Ortm
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.
Malcolm,
I also ran into troubles which are similar, apparently due to mixed
org-mode versions; we've got to load org-mode before emacs tries to do
it for us or we get mixed stuff.
My resolution was to load the org-mode path first in my init.el file and
then require org:
(add-to-list
Thank you! I will take one or more of those steps.
(The performance drop was sudden and steep, by the way.)
On 10/19/22 23:56, Ihor Radchenko wrote:
Daniel Ortmann writes:
Here you go.
Thanks!
It looks like you have some task with giant years-worth logbook drawer.
You can try to reduce
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.
Was Eli Z's observation the key? Of code not autoloading when
eval-buffer is running?
On 9/21/22 03:37, Ihor Radchenko wrote:
Daniel Ortmann writes:
These two lines are in my *Messages* buffer:
File mode specification error: (void-function org-element-cache-reset)
Error during redisplay
Hmmm ...
While trying to investigate one bug I have run into another odd one:
* emacs version: GNU Emacs 29.0.50 (build 23, x86_64-pc-linux-gnu,
GTK+ Version 3.22.30, cairo version 1.15.12) of 2022-09-20
* org version: Org mode version 9.5.5 (release_9.5.5-804-gf1a197 @
What's up with this behavior? It began a couple of weeks ago. I have
the load-path set immediately in my init.el followed by require org.
Versions are:
* GNU Emacs 29.0.50 (build 9, x86_64-pc-linux-gnu, GTK+ Version
3.22.30, cairo version 1.15.12) of 2022-09-14
* Org mode version 9.5.5
/dortmann/src/git-org-mode/lisp/)
On 8/25/22 09:36, Daniel Ortmann wrote:
FYI,
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57394
Lars at gnu says it is fixed in emacs 29
The bug's web page says, more specifically, "bug marked as fixed in
version 29.1"
... I can't find emacs 29.1; my
e.
I have not been able to test and verify the fix.
Thoughts?
Daniel Ortmann writes:
Error: error ("Eager macro-expansion failure: (void-function
byte-compile-warn-obsolete)")
debug-early-backtrace()
debug-early(error (error "Eager macro-expansion failure
git bisect shows that this emacs commit is the problem (if I understand
correctly ... this is the first time I have used git bisect):
[6ddcf67052545a0f77233f1a952dc90e296cda35] Make it possible to mark
generalized variables as obsolete
Here is the bug report:
Subject: 29.0.50; emacs commit
Hello,
This morning I can't get org-mode to compile and load at all. And the
bug reporting is not working.
What to do?
Thank you!
Here are this morning's messages:
make -C lisp compile
make[1]: Entering directory '/home/dortmann/src/git-org-mode/lisp'
rm -f org-version.el org-loaddefs.el
I am not seeing the problem anymore after installing the Symbola fonts.
On 7/16/22 04:15, Ihor Radchenko wrote:
Daniel Ortmann writes:
More information on that character:
position: 195 of 690 (28%), column: 26
character: ⭠ (displayed as ⭠) (codepoint 11104
Ihor,
What are your thoughts?
On 7/12/22 15:03, Juan Manuel Macías wrote:
Juan Manuel Macías writes:
The most reasonable thing would be to use a more
common symbol. But I'm still intrigued by the origin of that symbol...
It seems that the culprit is in line 1592 of org-agenda.el
I think
mal configuration step?)
Thank you!
On 7/12/22 12:58, Juan Manuel Macías wrote:
Hi,
Daniel Ortmann writes:
Any clues where this particular symbol resides? A hint about the
package name would wonderful. :-)
To be able to display "unusual" symbols in Emacs, I usually use the
symbola f
Hello,
During the past couple of weeks I have been seeing a new character in
the agenda when the log is on and I am displaying the time grid. I have
tried to find and install this character representation on Fedora-based
Linux but have not found the magic.
Any clues where this particular
warning
* Now, after a fresh pull of code and a rebuild, NONE of the errors or
warnings occur.
Everything is clean now.
Could loading those smaller files have cleaned or updated the cache? Or
was it your code updates?
Thank you!
On 6/28/22 21:03, Ihor Radchenko wrote:
Daniel Ortmann
Hey there,
I have a 1.2+ MB org-mode file and have been getting the following
message for a week or two. I have cleaned up content by archiving older
content and have run org-lint to cleanup some syntax issues ...
How to debug this type of issue?
Warning (org-element-cache):
Works fine with 'emacs -Q'. I will debug further.
Thank you!
On 6/10/22 09:32, Ihor Radchenko wrote:
Daniel Ortmann writes:
This morning C-S left no longer shifts the date in the LOGBOOK drawer.
I set the cursor on the second date which was 2022-06-10 initially and
pressed C-S left
I think it was actually S left which I was using. (My fingers knew the
command but did not tell my brain.)
... Anyway, that date-shifting no longer is working.
On 6/10/22 09:07, Daniel Ortmann wrote:
This morning C-S left no longer shifts the date in the LOGBOOK drawer.
I set the cursor
This morning C-S left no longer shifts the date in the LOGBOOK drawer.
I set the cursor on the second date which was 2022-06-10 initially and
pressed C-S left
... expecting it to be shifted to the 2022-06-09 as shown below.
CLOCK: [2022-06-09 Thu 11:53]--[2022-06-09 Thu 19:20] => 7:27
I highly recommend a recent LibreOffice. Nearly everything I do is
through LibreOffice and CSV files. MS Excel has problems when using
inter-field-separators such as semicolons.
When I receive Excel (or other) spreadsheets from people, I must first
convert them into CSV files to clear out
And perhaps maintain the table in elpa?
On 5/11/21 7:52 AM, TEC wrote:
Tim Cross writes:
I also had to install textlive, plantuml, graphviz, taskjuggler,
ledger, sqlite and many other things.
Perhaps it would be good to make a table of
| software | needed for | package name | download page
This reverts commit bc857bfc62ba94e04fb338bfb35f4b612c114d0c.
The "fix" breaks elsewhere, as reported below.
Reported-by: Daniel Ortmann
<http://lists.gnu.org/r/emacs-orgmode/2021-05/msg00592.html>
On 5/10/21 9:25 AM, Nicholas Savage wrote:
Thanks for the report. This was
This reverts commit bc857bfc62ba94e04fb338bfb35f4b612c114d0c.
The "fix" breaks elsewhere, as reported below.
Reported-by: Daniel Ortmann
<http://lists.gnu.org/r/emacs-orgmode/2021-05/msg00592.html>
On 5/9/21 5:01 PM, Daniel Ortmann wrote:
Hello,
I opened my 'plan.org' fil
Hello,
I opened my 'plan.org' file today and the C-c a a failed while creating
the agenda. The information is below.
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
Today all of my multi-hop urls seem to be broken. Is anyone else
experiencing this issue?
ports or logging on)
> then move forwards again and you can't turn it off.
>
> HTH.
>
> Regards,
> Bernt
>
> Daniel Ortmann writes:
>
>> This is crazy! After months of problems, I myself no longer can
>> reproduce this issue! :-/
>>
>> Comm
This is crazy! After months of problems, I myself no longer can
reproduce this issue! :-/
Comments welcome (Please!) ... but this issue no longer is actually a bug.
On 3/4/19 3:22 PM, Daniel Ortmann wrote:
> Remember to cover the basics, that is, what you expected to happen and
> what i
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.
- State "CANCELED" from "TODO" [2019-01-17 Thu 10:39]
- State "DONE" from "TODO" [2019-01-09 Wed 14:14]
...
:END:
On 1/15/19 8:43 AM, Bernt Hansen wrote:
> Daniel Ortmann writes:
>
>> No other tasks. Here is the complete tex
I have a weekly scheduled task with ...
DEADLINE: <2019-01-18 Fri ++1w -0d>
Recently, when I complete the task it reports the following:
Clock stopped at [2019-01-11 Fri 17:03] after 0:05
10 repeater intervals were not enough to shift date past today.
Continue? (y or n) n
Thoughts?
I have a daily scheduled task with ...
SCHEDULED: <2019-01-11 Fri 07:50 .+1d>
Recently, when I complete the task it not only moves the schedule to the
next day
... but it also /_rewrites_/ all of the "Rescheduled from ..." entries
in the LOGBOOK.
For example,
- Rescheduled from "[2019-01-11
50 matches
Mail list logo
