Re: org-read-date: selecting date with mouse-2 in calendar

2021-02-25 Thread Michael Heerdegen
Hello again,

> selecting a date from within `org-read-date' from the calendar works
> with mouse-1, but not with mouse-2 (with latest Emacs master and my
> settings loaded at least).
>
> The code seems to intend that it also works with mouse-2, but it fails.
>
> Why it doesn't work?  Oh, that's because calendar already binds
> down-mouse-2 to pop-up a menu (see definition of `calendar-mode-map').
> So when we would add the following line to `org-read-date' (it's obvious
> to where and I'm too lazy to create a patch now):
>
> +  (org-defkey map [down-mouse-2] nil)

No comments on this (hope it wasn't too confused...)?  Should I just
commit the fix to the Emacs master branch?

TIA,

Michael.



Re: org-read-date: selecting date with mouse-2 in calendar

2021-02-13 Thread Michael Heerdegen
Michael Heerdegen  writes:

> Nothing is lost since the original popup-menu for the calendar is
> still being bound to down-mouse-3 (the more expected key for such a
> menu in my opinion, at least 2021).

That was not quite correct, however.  These are the defining lines:

;; These are referenced in the default calendar-date-echo-text.
(define-key map [down-mouse-3]
  (easy-menu-binding cal-menu-context-mouse-menu))
(define-key map [down-mouse-2]
  (easy-menu-binding cal-menu-global-mouse-menu))

So the calendar provides a global (mouse-2) and a context menu
(mouse-3).  Seems both are not really useful for `org-read-date'.

Michael.



Re: org-read-date: selecting date with mouse-2 in calendar

2021-02-13 Thread Michael Heerdegen
Michael Heerdegen  writes:

> So please consider [...]

Oh, and please keep me CC'd, I don't read the list regularly.

Thanks, Michael.



org-read-date: selecting date with mouse-2 in calendar

2021-02-13 Thread Michael Heerdegen
Hello,

selecting a date from within `org-read-date' from the calendar works
with mouse-1, but not with mouse-2 (with latest Emacs master and my
settings loaded at least).

The code seems to intend that it also works with mouse-2, but it fails.

I don't prefer mouse-2, but it would be good to support it I think,
since "clicking" in Emacs is with mouse-2 historically, breaking that
might cause inconvenience.

Why it doesn't work?  Oh, that's because calendar already binds
down-mouse-2 to pop-up a menu (see definition of `calendar-mode-map').
So when we would add the following line to `org-read-date' (it's obvious
to where and I'm too lazy to create a patch now):

+  (org-defkey map [down-mouse-2] nil)

it works as expected for me.  Nothing is lost since the original
popup-menu for the calendar is still being bound to down-mouse-3 (the
more expected key for such a menu in my opinion, at least 2021).

So please consider to add the above line to the defun of
`org-read-date'.


Regards,

Michael.



Re: logrepeat only logging LAST_REPEAT

2021-01-20 Thread Michael Heerdegen
Ihor Radchenko  writes:

> You are right. Since this is hard-coded, you may have to use :around
> advice to disable org-log-setup: [...]

Do you think others may want the same and it could be worth to implement
this feature?

Michael.



Re: logrepeat only logging LAST_REPEAT

2021-01-20 Thread Michael Heerdegen
Ihor Radchenko  writes:

> > Is there a way to get only the :LAST_REPEAT: prop logged, without the
> > ever-growing list?
>
> I guess you can try to play with org-log-done and org-log-repeat
> variables.

Thanks.  But as far as I recall, that's what I already tried and it
didn't help.

As far as I understand, the logging is implemented in
`org-auto-repeat-maybe', and the thing I do not want is caused by the
`org-add-log-setup' call, and that is done unconditionally unless
`org-log-repeat's value is nil.  Which I don't want because this would
also disable the "LAST_REPEAT" property setting.

Thanks,

Michael.



logrepeat only logging LAST_REPEAT

2021-01-19 Thread Michael Heerdegen
Hello,

for some entries I use the logrepeat feature (enabled by setting the
LOGGING property of the entry).

I get a :LAST_REPEAT: property that I (always) want, and also a complete
log I do not (always) want, in the form of a growing list of

- State "DONE" from "XYZ" [2021-01-19 Di 12:01]

style entries that I often "garbage collect" manually.

Is there a way to get only the :LAST_REPEAT: prop logged, without the
ever-growing list?

If not, please consider as "wishlist" request.

TIA,

Michael.



Re: org-agenda-get-timestamps and properties

2020-11-28 Thread Michael Heerdegen
Kyle Meyer  writes:

> > but not when formatted like this:
> >
> > ** APPT 10:40 Xyz
> > SCHEDULED: <2020-11-08 So +1d>
> > :PROPERTIES:
> > :ID:   1d313f9a-3044-4c23-9278-422646ec9063
> > :END:
> >
> > although the latter form is, AFAICT, recommended, and at least it's what
> > I get when creating ids automatically with (org-id-get-create).
>
> ...while this is a valid scheduled heading.

Hmm, seems my code has come to the same conclusion and magically started
working, without any change, AFAICT.  Strange, dunno how, but your
answer somehow helped.  Quantum physics, probably.  I hope it remains
so...

Thanks,

Michael.



org-agenda-get-timestamps and properties

2020-11-10 Thread Michael Heerdegen
Hi,

I have a problem with my appt.el replacement I develop.

When debugging, I found that `org-agenda-get-timestamps' does, depending
on the position of the SCHEDULED spec, do return a timestamp when an
entry is formatted like this:

** APPT 10:40 Xyz
:PROPERTIES:
:ID:   1d313f9a-3044-4c23-9278-422646ec9063
:END:
SCHEDULED: <2020-11-08 So +1d>

but not when formatted like this:

** APPT 10:40 Xyz
SCHEDULED: <2020-11-08 So +1d>
:PROPERTIES:
:ID:   1d313f9a-3044-4c23-9278-422646ec9063
:END:

although the latter form is, AFAICT, recommended, and at least it's what
I get when creating ids automatically with (org-id-get-create).

No timestamp, and my appointments don't work (bad).

Has anybody any insight into this matter?


TIA,

Michael.



Re: org-marker vs. org-hd-marker

2020-10-29 Thread Michael Heerdegen
Kyle Meyer  writes:

> Going through each of the collection functions at the end of
> org-agenda-get-day-entries, it looks like they all set org-marker.
> Plus, I can spot places in org-agenda.el that rely on agenda entries
> having org-marker (e.g., org-agenda-goto and org-agenda-todo), so I
> think that assumption would be safe.

Great, thanks for checking, Kyle.

Michael.



Re: Headline generation as in diary?

2020-10-28 Thread Michael Heerdegen
I  wrote:

> With diary, I can use arbitrary Lisp expressions to generate dates, and
> those expressions can also return a string to use as non-nil return
> value to generate non-constant headlines including certain numbers for
> example. [...]

My solution so far: I've set up my `org-capture-templates' so that when
I hit T (instead of t) I am prompted for time+headline and optionally a
number of days for a reminder, and, for example, when I enter "21:00
Test" and a "2" I get an entry like

| ** TODO Special entry: "21:00 Test"
| %%(diary-remind
|'(and
|  (dg-it-is "[2020-10-31 Sa]")
|  "TODO 21:00 Test")
|2)

`dg-it-is' is a function that tests whether "it is" the given date
specified as an inactive org time stamp.  The nice thing about this is
that org recognizes the stamp and I can click on it with the mouse to
change it etc.

And I can freely edit the whole expression.  The entry gets listed in
the agenda correctly (also the reminder) and I get two appt.el
appointments (or rather, my substitution for it).

Cons: The headline is ignored, I use a dummy headline.  I don't have
emacs-lisp bindings to edit the expression in the Capture or Org buffer,
so if I want something more complicated I probably need to use *scratch*
as intermediate step  (I tried to use a source block, but then the %%()
expression is not recognized any more, and the time stamps are not
clickable any more).

And for whatever reason, the agenda doesn't fontify the word "TODO".

If anyone has ideas for improvements, I'm curious!


Regards,

Michael.



Re: org-marker vs. org-hd-marker

2020-10-27 Thread Michael Heerdegen
Kyle Meyer  writes:

> My reading (which could be very wrong) is that org-hd-marker is always
> set to the start of the headline.  org-marker, on the other hand, is set
> to some position in the entry that depends on who is setting it.

Thanks for the insights, Kyle.

Do you know whether I can assume that one of those is always present
(org-marker probably, since org-hd-marker is not always present) when
examining the result of `org-agenda-get-day-entries'?  I don't care
about the exact location in an entry.


> > What does "hd" stand for?
>
> Headline, I guess.

Ah, that would make sense (and also explain why there are no 4k markers
;-)


Regards,

Michael.



Re: Force creation of org id in template

2020-10-26 Thread Michael Heerdegen
gusbrs.2...@gmail.com writes:

> Untested, but how about adding something like the following to your
> template?
>
> :PROPERTIES:
> :ID: %(org-id-new)
> :END:

I'm not sure.  I see that creating an id involves slightly more than
adding the property - see the `org-id-add-location' call in
`org-id-get'.  Calling the higher level `org-id-get' or the like in a
%() spec in a template fails however, since when it's called a temp
buffer not associated with a file is current.

And then I'm also not sure if the above is always secure when something
else in the template spec wants to add a (different) property.  Do you
know?

Thanks,

Michael.




Force creation of org id in template

2020-10-26 Thread Michael Heerdegen
Hello,

is it possible to tweak `org-capture-templates' entries so that the
creation of an org id for an org entry created with `org-capture' is
forced?

TIA,

Michael.



org code and error catching

2020-10-26 Thread Michael Heerdegen
Hello,

I had a hard time to debug some problem with the expansion of some
capture template because org catched the error even when I had set
`debug-on-error'.  Would it be possible to make some functions,
e.g. `org-eval' in my case (probably some more?), use
`condition-case-unless-debug' instead of `condition-case'?

Thanks,

Michael.



org-marker vs. org-hd-marker

2020-10-26 Thread Michael Heerdegen
Hello,

what's the difference between org-marker and org-hd-marker markers?
What does "hd" stand for?

TIA,

Michael.



Re: Headline generation as in diary?

2020-09-03 Thread Michael Heerdegen
Ihor Radchenko  writes:

> > I didn't know that eval specs support multi-line sexps, but seems that
> > works, so I can indeed use this.  Thanks for the suggestion.
>
> Hmm. According to manual, it should support multi-line string. Not sure
> about sexps.

AFAIR it didn't work in the past.  I guess it has been fixed in master
not long ago.

Michael.



Re: Headline generation as in diary?

2020-09-03 Thread Michael Heerdegen
Ihor Radchenko  writes:

> I do not think there is support of multi-line planning everywhere.

I see.

> You can always use file-local definition at the beginning or end of your
> org file. Below is an example of local definition at the end of an org
> file.
>
> # Local Variables:
> # eval: (defun your-function () (sexp))

I didn't know that eval specs support multi-line sexps, but seems that
works, so I can indeed use this.  Thanks for the suggestion.

Michael.



Re: Headline generation as in diary?

2020-09-03 Thread Michael Heerdegen
Robert Pluim  writes:

> It can? Thatʼs not documented, as far as I can tell.

As a user, I read "Diary-style expression entries" in the org manual as
including my own defined diary sexps - excluding them would be a
surprise that should be documented (no, I don't want that to happen!).

Michael.



Re: Headline generation as in diary?

2020-09-03 Thread Michael Heerdegen
Ihor Radchenko  writes:

> > When dealing with complicated date rules it can likely happen that a
> > diary sexp doesn't fit into one line.
>
> Diary sexp can be a user-defined function. If your sexp needs to span
> multiple lines, it is probably worth defining a function and simply
> using <%%(your-function)> as a timestamp.

I think this is inconvenient.  Ok, only a bit.  But it would be nicer if
I could specify my dates in only one file.  Jumping around in my org
file + my emacs init file is what I used to do.

Multi-line sexps in time stamps work would just be nice to have.  Would
it be hard to achieve?  I mean, since multi-line %%(...) entries already
work...


Thanks,

Michael.



Re: Headline generation as in diary?

2020-09-03 Thread Michael Heerdegen
Robert Pluim  writes:

> I can push my change to org, but Iʼm not a regular org contributor, so
> Iʼd prefer to hear from one of the maintainers first.

Sorry - I meant, I see no reason to touch the existing code.  No need to
change anything for what I want.

> Michael> This doesn't work:
>
> Michael> | ** APPT 17:00 Test
> Michael> | SCHEDULED: <%%(and (or (diary-date 03 09 2020)
> Michael> |(diary-date 04 09 2020)))>

> I think thatʼs just a consequence of timestamps not being allowed to
> span multiple lines in org, unlike diary.

This is bad.  Why is that?  Can it be changed?

When dealing with complicated date rules it can likely happen that a
diary sexp doesn't fit into one line.

Regards,

Michael.



Re: Headline generation as in diary?

2020-09-02 Thread Michael Heerdegen
Robert Pluim  writes:

> OK. Thatʼs as far as my org-hacking knowledge goes, so perhaps someone
> else here has an idea of the right way to invoke "tell me what heading
> Iʼm in, as a string".

The situation is actually like this: the empty string issue doesn't
happen with time stamps <%%(...)>, this always uses the correct
headline.  Seems %%() entries are expected to return a string OTOH since
the headline seems to be ignored.  I guess this is reasonable.  Dunno if
there is something to change here at all in the code.

Ok, the other thing: broken time stamps with line breaks:

> You've lost me. Can you show me an example?

The difference here is only a line break:

This doesn't work:

| ** APPT 17:00 Test
| SCHEDULED: <%%(and (or (diary-date 03 09 2020)
|(diary-date 04 09 2020)))>

But this works:

| ** APPT 17:00 Test
| SCHEDULED: <%%(and (or (diary-date 03 09 2020) (diary-date 04 09 2020)))>


Michael.



Re: Headline generation as in diary?

2020-09-02 Thread Michael Heerdegen
Robert Pluim  writes:

> How about:
>
> diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
> index 78fe13303..9049b3a42 100644
> --- a/lisp/org-agenda.el
> +++ b/lisp/org-agenda.el
> @@ -5772,7 +5772,7 @@ displayed in agenda view."
>   r (replace-match "" nil nil r)))
>   (if (string-match "\\S-" r)
>   (setq txt r)
> -   (setq txt "SEXP entry returned empty string"))
> +   (setq txt (org-no-properties (org-get-heading t t t t
>   (setq txt (org-agenda-format-item extra txt level category tags 
> 'time))
>   (org-add-props txt props 'org-marker marker
>  'date date 'todo-state todo-state

Thanks for looking at this.

Ok - That gives me a headline in the agenda, but a wrong one (more or
less, a random headline in the same file, at a seemingly unrelated
location).

> (Iʼm guessing yet-another-config-variable is unnecessary)

I think so toom yes.

> >> You can use them in timestamps as well, which is useful for
> >> weird time
> >> periods
> >> 
> >> **  Just before midnight on a few days 23:00-24:00
> >> <%%(org-block 2020 8 31 2020 9 2)>
> >> <%%(org-block 2020 9 10 2020 9 12)>
>
> Michael> But it seems those time stamps are not allowed to span
> Michael> multiple lines
> Michael> (at least I don't get it work).  Seems org doesn't
> Michael> recognize them as
> Michael> such?
>
> Itʼs working fine for me in org-9.3.6. Note that I have my default
> agenda view set to a fortnight, and those dates span two different
> weeks.

I didn't mean time spans.  What doesn't work for me are time _stamps_
that span multiple text lines.


Thanks,

Michael.



Re: Headline generation as in diary?

2020-09-01 Thread Michael Heerdegen
Robert Pluim  writes:

> Itʼs triggered by the %%(, I believe, but not in headlines.

Yes, I see that in the code.

But actually I seem to have the opposite problem: I can't make the
original headline appear in the agenda.  When the sexp doesn't return a
string the agenda will contain a line saying "SEXP entry returned empty
string" instead of showing the headline.

> You can use them in timestamps as well, which is useful for weird time
> periods
>
> **  Just before midnight on a few days 23:00-24:00
> <%%(org-block 2020 8 31 2020 9 2)>
> <%%(org-block 2020 9 10 2020 9 12)>

But it seems those time stamps are not allowed to span multiple lines
(at least I don't get it work).  Seems org doesn't recognize them as
such?


Michael.



Re: Headline generation as in diary?

2020-09-01 Thread Michael Heerdegen
Michael Heerdegen  writes:

> > [1]  https://github.com/m-cat/org-recur
>
> Thanks for the hint, I'll have a look.

Nice to have definitely.

I want to stick to diary sexp expressions for some complicated dates.  I
have already extended the diary language to fit my needs to specify the
dates of garbage collection here.  That looks like this:

#+begin_src emacs-lisp
 (dg-let-date (dg-tomorrow)
   (dg-except-for*
(and (dg-friday-p) (cl-evenp (dg-iso-week)))
(cl-some #'dg-holiday-p (dg-the-days-between (dg-days-before 2)))
+1))
#+end_src

It means: warn me one day before garbage collection happens, and that
is: every Friday in any week with even week number, unless it has been a
holiday up to two days before that, then they collect one day later.

I guess I always want Lisp to specify something like this.

Michael.



Re: Headline generation as in diary?

2020-09-01 Thread Michael Heerdegen
Eric S Fraga  writes:

> No, not necessarily.  I have entries like this:
>
> %%(diary-anniversary 1981 03 17) Somebody's birthday (%d years)
>
> and the agenda view shows "Somebody's birthday (19 years)"; the actual
> heading for this entry is ignored.

Where in an entry do you specify such specifications?

> However, I don't know if other diary- functions work the same way.

Yes, the interesting part then is: when does org behave like this, and
can this behavior be forced?

> > Or do I miss something?  How to other people deal with things
> > like...garbage collection?
>
> I use the org-recur [1] package for this.  Very nice for repeating
> events.

> Footnotes:
> [1]  https://github.com/m-cat/org-recur

Thanks for the hint, I'll have a look.


Michael.



Headline generation as in diary?

2020-09-01 Thread Michael Heerdegen
Hi,

I am mainly using the org agenda for day planning.  But there is a
functionality I seem to miss I know from diary:

With diary, I can use arbitrary Lisp expressions to generate dates, and
those expressions can also return a string to use as non-nil return
value to generate non-constant headlines including certain numbers for
example.  I can use that to implement when the next garbage
collection will come (rules for that are complicated since there are
exceptions etc), add reminders for certain important stuff, etc.

I would like to use my org file to specify those things instead of
maintaining a second file (the diary file).  But AFAIK the dynamically
created headline part is tricky: what appears in the agenda is always
the org headline as it appears in the file, right?

Or do I miss something?  How to other people deal with things
like...garbage collection?


TIA,

Michael.



Re: Emacs bug 37890; killing capture buffer

2019-12-19 Thread Michael Heerdegen
Ihor Radchenko  writes:

> You can try M-x org-submit-bug-report ;)
> Then it becomes clear that you are in the right place already.

Thanks!  I didn't know about this command - actually I had searched for
it but didn't find it because I had searched for something named
"report-org-bug" (analogue to `report-emacs-bug').  I think this may
happen to other org users not following org-mode development as well -
so I just used the command to suggest this name as alias.

Regards,

Michael.



Bug: About org-submit-bug-report [9.3 (release_9.3 @ /usr/local/share/emacs/27.0.50/lisp/org/)]

2019-12-19 Thread Michael Heerdegen


Hello,

I want to suggest to make `report-org-bug' and alias for the command
`org-submit-bug-report'.  That's the name I expected (considering
"report-emacs-bug"), also some other Emacs packages name their bug
reporting command according to this scheme.  The additional name would
make this important command more discoverable.

Second point: When you think it is a trivial task for a common user
please consider to add some text to the initial buffer contents of the
message buffer created by this command explaining where one can search
for existing reports (to avoid duplicates and reports about things that
are just pitfalls etc).  My buffer included a link to a page explaining
how to create a good report but there this information is also missing,
although I think it would be a good place.

TIA,

Michael.

Emacs  : GNU Emacs 27.0.50 (build 41, x86_64-pc-linux-gnu, GTK+ Version 3.24.13)
 of 2019-12-20
Package: Org mode version 9.3 (release_9.3 @ 
/usr/local/share/emacs/27.0.50/lisp/org/)



Re: Emacs bug 37890; killing capture buffer

2019-12-19 Thread Michael Heerdegen
Samuel Wales  writes:

> the indirect buffer capture mechanism was to be an improvement on
> remember.el, and replaced it.  you might still be able to find
> remember.el if you prefer the separate file idea.

I find it acceptable once it's been made more secure (e.g. by using
hooks like I mentioned).

But I wonder now why you said there are still problems with final
newlines (and you already got a confirmation), while I and other
developers say it has been fixed.  Do you use the org mode version built
in Emacs, and you don't use Emacs master?

Thanks,

Michael.



Re: Emacs bug 37890; killing capture buffer

2019-12-19 Thread Michael Heerdegen
Adam Porter  writes:

> People do care!  But everyone here works on Org in their spare time,
> and Org is a big project, and things slip through the cracks.

I didn't meant to criticize anyone (I have the same problem with my own
stuff).  Anyway, we got some attention now, thanks for your help!


Regards,

Michael.



Re: Emacs bug 37890; killing capture buffer

2019-12-17 Thread Michael Heerdegen
Adam Porter  writes:

> I guess you're asking me, since I'm the only other person in this
> thread--but I'm not an Org maintainer, so my opinion isn't very
> important.  IMO, the hooks are worth considering, however they should be
> done very, very carefully, because bad things can happen when functions
> called in kill hooks don't work as expected (e.g. they can make it very
> difficult to kill a buffer or the Emacs process, especially for an
> average user).

Yes, all true.  I didn't even check if the code I posted breaks any org
commands that kill the buffer.  So far it's only meant for demonstration
(and my personal usage).

Will my request be noticed here, or do you think I should report it to
some other place?

> > BTW, what about my question whether my original bug report can be
> > closed?
>
> I haven't seen your bug report.  Was there discussion about it
> previously?

No, no discussion at all.  As I said, it is Emacs bug #37890, this was
my issue:

| I want to capture an APPT with `org-capture'.  I the pop-up buffer to
| edit the item I move the date to the second line and add text after the
| date (personal preference).  That loses the final newline in
| CAPTURE-todo.org.  As a result, the headline of the item following the
| item to be inserted gets appended to the last line of the text:
|
| ** APPT Abc
|<2019-10-23 Mi>
| text... ** APPT 8:30 Important Appointment
|
| breaking the whole item.  The user should somehow be prevented from that
| happening.

It seems it has been resolved, just without noticing my bug report.  If
you can confirm that the cited issue has been cared about, I'll close it
as done.

BTW, what is the canonical place to report org-mode bugs?  Emacs bug
reports are not (takes a long time until someone even notices) -- I
thought this list would be good...or is there a better place?   @Adam
it's ok if you answer, though I'm a bit disappointed that no one else
seems to care so far...


Thanks,

Michael.



Re: Emacs bug 37890; killing capture buffer

2019-12-16 Thread Michael Heerdegen
Michael Heerdegen  writes:

>  - kill-buffer-hook in the capture buffer could be used to prevent the
>  user from killing such a buffer by accident.  Or it could be made
>  configurable what to do (e.g. undo the change with or without user
>  prompting, ask for what to do, etc.)
>
>  - kill-emacs-hook could be used to register a function that warns when
>  any capture buffers are left when Emacs is to be killed.  That would
>  make a difference if you have captured more stuff after having
>  forgotten about a former capture buffer.  The user would be guided to
>  finish what he would otherwise have forgotten.

That doesn't seem to be hard to implement:

#+begin_src emacs-lisp
(add-hook
 'org-capture-mode-hook
 (defun my-org-capture-mode-hook-fun ()
   (add-hook 'kill-buffer-hook
 (defun my-org-capture-inhibit-accidental-kill ()
   (user-error "Please don't just kill org capture buffers"))
 nil 'local)
   (add-hook 'kill-emacs-hook
 (defun my-org-capture-barf-for-left-capture-buffers ()
   (dolist (b (buffer-list))
 (when (with-current-buffer b
 (bound-and-true-p org-capture-mode))
   (user-error "Please care about org capture buffer %s"
   (buffer-name b

(add-hook 'org-capture-prepare-finalize-hook
  (defun my-org-capture-prepare-finalize-hook-fun ()
(remove-hook 'kill-buffer-hook
 'my-org-capture-inhibit-accidental-kill
 'local)))
#+end_src

Would you consider to do something like this by default?

BTW, what about my question whether my original bug report can be
closed?

TIA,

Michael.



Re: Emacs bug 37890; killing capture buffer

2019-12-15 Thread Michael Heerdegen
Adam Porter  writes:

> Michael Heerdegen  writes:
>
> > Or (really better IMHO) consider a different implementation where the
> > original buffer is not modified until the user explicitly confirms the
> > stuff to capture with C-c C-c.
>
> That would be helpful in some ways, but harmful in others.  For example,
> consider a capture that is started while in a meeting, on a phone call,
> away from one's desk, etc., with some notes in it, clock start time,
> etc.  (You can find examples of this workflow in, e.g. Bernt Hansen's
> Org config.)  If Emacs were interrupted (crash, power failure, reboot,
> etc), the un-finalized capture would still be present in the auto-save
> file and could be recovered when restarting Emacs and finding the file
> again.

A legitimate objection.

> The way Org uses indirect, narrowed buffers for capturing is an
> elegant use of Emacs features that helps protect user data from
> accidental loss.

Let me rethink from the other side: how could the issue I described
(globbered org file) be prevented?  If you happen to kill the capture
buffer or forget about it, is there any indication left that there is a
problem?  A modified buffer visiting the org file is left, but as soon
as you successfully capture something else Org happily saves both edits
to the file.

So maybe we could prevent the user from doing something wrong?  Maybe
like this:

 - kill-buffer-hook in the capture buffer could be used to prevent the
 user from killing such a buffer by accident.  Or it could be made
 configurable what to do (e.g. undo the change with or without user
 prompting, ask for what to do, etc.)

 - kill-emacs-hook could be used to register a function that warns when
 any capture buffers are left when Emacs is to be killed.  That would
 make a difference if you have captured more stuff after having
 forgotten about a former capture buffer.  The user would be guided to
 finish what he would otherwise have forgotten.

That would improve security even further without getting in the way in
the normal workflow.


Michael.



Emacs bug 37890; killing capture buffer

2019-12-13 Thread Michael Heerdegen
Hi,

I want to speak about my Emacs bug report 37890 about org-capture.
Seems my main point:

| I want to capture an APPT with `org-capture'.  I the pop-up buffer to
| edit the item I move the date to the second line and add text after the
| date (personal preference).  That loses the final newline in
| CAPTURE-todo.org.  As a result, the headline of the item following the
| item to be inserted gets appended to the last line of the text:
|
| ** APPT Abc
|<2019-10-23 Mi>
| text... ** APPT 8:30 Important Appointment
|
| breaking the whole item.  The user should somehow be prevented from that
| happening.

has been resolved with the latest merge into Emacs master - is that
correct?  Then I will close that report.

The report also included a feature request which I now want to tell
here: I often kill the capture buffer instead of hitting C-c C-k.  Just
by habit.  It's wrong and I now it but I guess it happens to others.

I guess the capture buffer is just a narrowed indirect buffer copy of
the buffer visiting the according org file.  Because of this, when you
kill the capture buffer, the original buffer reflects the partial and
uncomplete entry one tried to add.  This may damage your file.  But such
internals are not known to all, so it would be good if killing the
capture buffer, or even just closing the window, would warn the user and
offer to undo the partial changes.  Or (really better IMHO) consider a
different implementation where the original buffer is not modified until
the user explicitly confirms the stuff to capture with C-c C-c.

TIA,

Michael.



Re: [O] Show APPTs every day in Agneda

2019-05-28 Thread Michael Heerdegen
Neil Jerram  writes:

> #+BEGIN_EXAMPLE
> ** Bank holiday weekend
>
> <2018-05-05 Sat>--<2018-05-07 Mon>
> #+END_EXAMPLE

> Sorry, that's no solution for you, but maybe there's a clue in the
> detail there?

Ha! - indeed.  It's obviously not allowed to add spaces like I used to
do:

  <2018-05-05 Sat> -- <2018-05-07 Mon>

With

  <2018-05-05 Sat>--<2018-05-07 Mon>

it works like I want.

So, thank you very much to pointing me into the right direction.

But this doesn't seem to be documented...(question to all)?


Thanks,

Michael.



Re: [O] Show APPTs every day in Agneda

2019-05-27 Thread Michael Heerdegen
Neil Jerram  writes:

> Hi Michael,

Hi Neil!

> I'm not in front of my computer, to check this, but I think that an
> active date range will have this effect, i.e.
>
> ** Vacation
> --

Hmm, no, AFAICT that's what I used to do, and it only shows the
appointment at start and end date, not between the two dates.  That's
with C-c a a btw.  I wonder why it seems to work for you...

Michael.



[O] Show APPTs every day in Agneda

2019-05-26 Thread Michael Heerdegen
Hi,

I've APPTs like "Vacation" that last 14 days or so.  Is there an
option/way to show such an APPT for every concerned day, and not only
for the border days, so that when I for example want to make a doctor's
appointment I see for the respective day that I'm on vacation on that
day?

TIA,

Michael.



[O] bug#18663: 25.0.50; Org agenda broken due to removed fancy-diary-display alias

2014-10-12 Thread Michael Heerdegen
Hello,

 I'm not anymore able to view the org agenda.

I have been told that this issue has been fixed in the org repo,

   Commit 4a872ae3... [PATCH] Fix: Emacs 25 fancy diary inclusion in agenda
   Date:   Sat Oct 11 18:16:36 2014 +0200

Dunno when this change will arrive in Emacs and who is responsible for
that.

Meanwhile users that are affected can fix this by adding the old obsolete alias 
to
their configuration:

  (define-obsolete-function-alias 'fancy-diary-display
'diary-fancy-display 23.1)


Michael.





[O] bug#18035: Linum-mode + org-indent-mode results in graphical bug

2014-07-17 Thread Michael Heerdegen
Eli Zaretskii e...@gnu.org writes:


 [...]  I'm not sure this is the same problem as reported by the OP, so
 it probably should have been reported as a separate bug (merging them
 later is easy).

Ok.  I wasn't sure what would be best.


  - visit a file under version control (I tried a git controlled file
  here)
  - M-x vc-annotate
  - v (i.e. vc-annotate-toggle-annotation-visibility)
  - M-x linum-mode
  
  == all lines but one loose their coloring.  Those lines that are still
  colored loose their line number.
  
  nlinum-mode behaves similarly.

 Fixed in revision 117382 on the emacs-24 branch.

Works for me, thanks!


Michael.





[O] bug#18035: Linum-mode + org-indent-mode results in graphical bug

2014-07-16 Thread Michael Heerdegen
Eli Zaretskii e...@gnu.org writes:

  Activating both linum-mode and org-indent-mode will cause several
  graphical glitches in the current line.
  See
  http://lists.gnu.org/archive/html/emacs-orgmode/2011-01/msg01204.html

 That discussion provides no reproducible recipe.

FWIW, I think we see something similar or related in helm:

  https://github.com/emacs-helm/helm/issues/560

Sadly, there's also no recipe for emacs -Q.


Michael.





[O] bug#18035: Linum-mode + org-indent-mode results in graphical bug

2014-07-16 Thread Michael Heerdegen
Michael Heerdegen michael_heerde...@web.de writes:

   Activating both linum-mode and org-indent-mode will cause several
   graphical glitches in the current line.
   See
   http://lists.gnu.org/archive/html/emacs-orgmode/2011-01/msg01204.html
 
  That discussion provides no reproducible recipe.

But I think I found something that is related (before-string overlays
vs. text properties) and is reproducible for emacs -Q:

- visit a file under version control (I tried a git controlled file here)
- M-x vc-annotate
- v (i.e. vc-annotate-toggle-annotation-visibility)
- M-x linum-mode

== all lines but one loose their coloring.  Those lines that are still
colored loose their line number.

nlinum-mode behaves similarly.


Michael.





Re: [O] Bug: Messaging when moving in the agenda [7.9.2 (7.9.2-GNU-Emacs-24-3 @ /usr/share/emacs/24.2.50/lisp/org/)]

2013-09-02 Thread Michael Heerdegen
Hi Carsten,

 I believe I have done it in the right place now, please confirm.

Confirmed, thanks, that's what I wanted.

There's just a little typo in the docstring of `org-unlogged-message':

Display a message, but avoid loggin it in the *Messages* buffer.
^
g

Regards,

Michael.



Re: [O] Bug: Messaging when moving in the agenda [7.9.2 (7.9.2-GNU-Emacs-24-3 @ /usr/share/emacs/24.2.50/lisp/org/)]

2013-08-06 Thread Michael Heerdegen
Hello,

 When I move around in the *Org Agenda* with up and down, the current
 outline path is displayed in the echo area, which is good.

 However, what is displayed gets also copied in the *Messages* buffer,
 which is not helpful, but clutters *Messages* with useless noise.

 So, IMHO `org-display-outline-path' should still display its stuff in
 the echo area, but prevent logging in *Messages*.  AFAIK, the way to do
 this is to bind `message-log-max' to nil.

Can we please try to make some progress here?  I don't want to suggest a
patch because I don't know the org code base well, but binding
`message-log-max' to nil at one or two location should totally suffice.
Who can help?


Regards,

Michael.




[O] Bug: Messaging when moving in the agenda [7.9.2 (7.9.2-GNU-Emacs-24-3 @ /usr/share/emacs/24.2.50/lisp/org/)]

2012-10-31 Thread Michael Heerdegen

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

 http://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org-mode mailing list.


Hello,

When I move around in the *Org Agenda* with up and down, the current
outline path is displayed in the echo area, which is good.

However, what is displayed gets also copied in the *Messages* buffer,
which is not helpful, but clutters *Messages* with useless noise.

So, IMHO `org-display-outline-path' should still display its stuff in
the echo area, but prevent logging in *Messages*.  AFAIK, the way to do
this is to bind `message-log-max' to nil.

I'm not sure if this is the right thing in every case, but if the goal
is to just display something for better orientation etc., there is no
need for logging.

Dunno if there are other functions that could benefit from the same
treatment.


Regards,

Michael.

Emacs  : GNU Emacs 24.2.50.1 (x86_64-pc-linux-gnu, GTK+ Version 3.4.2)
 of 2012-10-25 on dex, modified by Debian
Package: Org-mode version 7.9.2 (7.9.2-GNU-Emacs-24-3 @ 
/usr/share/emacs/24.2.50/lisp/org/)

current state:
==
(setq
 org-export-preprocess-before-selecting-backend-code-hook 
'(org-beamer-select-beamer-code)
 org-tab-first-hook '(org-hide-block-toggle-maybe 
org-src-native-tab-command-maybe
  org-babel-hide-result-toggle-maybe 
org-babel-header-arg-expand)
 org-agenda-skip-deadline-prewarning-if-scheduled t
 org-speed-command-hook '(org-speed-command-default-hook 
org-babel-speed-command-hook)
 org-reverse-note-order t
 org-occur-hook '(org-first-headline-recenter)
 org-metaup-hook '(org-babel-load-in-session-maybe)
 org-capture-after-finalize-hook '(#[nil \300\301!\207 [org-agenda-to-appt 
refresh] 2])
 org-export-preprocess-before-normalizing-links-hook 
'(org-remove-file-link-modifiers)
 org-confirm-shell-link-function 'yes-or-no-p
 org-export-latex-final-hook '(org-beamer-amend-header org-beamer-fix-toc
   org-beamer-auto-fragile-frames
   org-beamer-place-default-actions-for-lists)
 org-export-latex-after-initial-vars-hook '(org-beamer-after-initial-vars)
 org-agenda-skip-scheduled-if-done t
 org-agenda-custom-commands '((d todo DELEGATED nil) (c todo 
DONE|DEFERRED|CANCELLED nil)
  (w todo WAITING nil) (W agenda #1= 
((org-agenda-ndays 21)))
  (A #A Tasks for today agenda #1#
   ((org-agenda-skip-function
 (lambda nil
  (org-agenda-skip-entry-if (quote notregexp) 
\\=.*\\[#A\\]))
 )
(org-agenda-ndays 1)
(org-agenda-overriding-header Today's Priority 
#A tasks: ))
   )
  (u Unsceduled Tasks alltodo #1#
   ((org-agenda-skip-function
 (lambda nil
  (org-agenda-skip-entry-if (quote scheduled) 
(quote deadline)
   (quote regexp) [^\n]+)
  )
 )
(org-agenda-overriding-header Unscheduled TODO 
entries: ))
   )
  )
 org-return-follows-link t
 org-capture-templates '((t Task entry (file+headline my-org-todo-file 
Tasks)
  * TODO %?\n  SCHEDULED: %t :prepend t)
 (a APPT entry (file+headline my-org-todo-file 
Tasks) * APPT %?\n  %t
  :prepend t)
 (c FromConkeror entry (file+headline 
my-org-todo-file Tasks)
  * TODO %?\n  :PROPERTIES:\n  :created: %U\n  :link: 
%a\n  :END:\n  %i
  :prepend t)
 )
 org-after-todo-state-change-hook '(org-clock-out-if-current)
 org-from-is-user-regexp \\Michael Heerdegen\\
 org-src-mode-hook '(org-src-babel-configure-edit-buffer 
org-src-mode-configure-edit-buffer)
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-babel-pre-tangle-hook '(save-buffer)
 org-mode-hook '((lambda (rest --cl-rest--)
  (apply
   (quote
#[(#1=#:G76352 #:G76353 rest #2=#:arguments_76338) 
\302J@\\207
  [#1# #2# apply] 3]
)
   (quote #:--wrapped-lambda_76337--) (quote #:--menu--) 
--cl-rest--)
  )
 #[nil \300\301\302\303\304$\207
   [org-add-hook change-major-mode-hook org-show-block-all 
append local] 5]
 #[nil \300\301\302\303\304$\207

[O] bug#11042: 24.0.94; dangerous org manual: parse-time-months and parse-time-weekdays

2012-03-21 Thread Michael Heerdegen
Bastien b...@altern.org writes:

 Hi Michael,

 Michael Heerdegen michael_heerde...@web.de writes:

  The org-mode manual under the node The date/time prompt tells:
 
[...] The function understands English month and weekday
  abbreviations.  If
  you want to use unabbreviated names and/or other languages, configure
  the variables `parse-time-months' and `parse-time-weekdays'.
 
  It doesn't tell how the user can do that.  Even worse,
  `parse-time-months' and `parse-time-weekdays' are not defined as user
  options and undocumented!
 
  After reading the above section in the org manual, users may replace
  the English names with e.g. German ones in their config.  Seems this
  is not a good idea, as this user question in gnu.emacs.gnus shows:
 
  http://groups.google.com/group/gnu.emacs.gnus/browse_thread/thread/8dde85b5ff3ab454/a02ddb878bfa1eb9

 The thread doesn't tell what is wrong with setting `parse-time-months'
 and `parse-time-weekdays'.  Can you expand a bit more on this?

The thread is not completely visible in google groups, dunno why.
Please read at gnu.emacs.gnus with a newsreader.

The problem was that the user replaced the English names with German
names - instead of adding them to the lists.  This broke Gnus.

Currently, `parse-time-months' and `parse-time-weekdays' are internal
variables with no docstring.  Seems they are not intended to be changed
by the user.  Other packages may rely on the fact that the default
values aren't changed.

If they are supposed to be configured by the user, they should get a
documented defcustom.

At least, the documentation in the org manual _must_ be improved, so
that the user is enabled to do the right thing without breaking anything
else.

  BTW1: maybe a better solution would be to define own variables for
  this purpose in org, instead of letting users change variables in
  parse-time.el.

 Org heavily depends on parse-time.el.  Providing a defcustom in Org
 that is tied to parse-time.el at the same time is not trivial.

Why not?  You could just write a function `org-parse-time-string' that
binds `parse-time-months' and `parse-time-weekdays' accordingly and
calls `parse-time-string'.  Then you would just need to call this new
function from org code.

Regards,

Michael.





[O] Bug: `org-show-context' doc string [7.5]

2011-09-28 Thread Michael Heerdegen

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

 http://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org-mode mailing list.


Hi,

in my version of org-mode, the doc string of `org-show-context' forgets
to mention `org-show-entry-below', a variable that also influences the
behavior of this function.


Emacs  : GNU Emacs 23.3.1 (i486-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2011-09-09 on spike.0x539.de, modified by Debian
Package: Org-mode version 7.5



[O] Bug: org-export-html-protect-char-alist type def [7.5]

2011-03-31 Thread Michael Heerdegen

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

 http://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org-mode mailing list.


Hello,

I use the ELPA built of orgmode.


M-x customize-variable org-export-html-protect-char-alist RET

gives an error.  I guess its custom type definition is illegal:

  :type '((repeat (cons (string :tag Character)
(string :tag HTML equivalent

Emacs  : GNU Emacs 23.2.1 (i486-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2010-12-11 on raven, modified by Debian
Package: Org-mode version 7.5