Re: Culling org files (notion of Types, many small vs few big files)

2021-03-05 Thread TRS-80
ugh" for almost all my search needs so far.[4]


On 3/4/21, Tim Cross  wrote:


My use pattern also constantly evolves as my requirements and 
priorities

change. It is and probably always will be, a work in progress!


I consider mine an ongoing experiment as well, which is why I have not
(as of yet) published anything.  But I'm glad I decided to discuss it
on the list, as now I see I'm not the only one to reach some of same
conclusions!

Cheers,
TRS-80

[0] But I need to change that because colon I learned is an illegal
character on exFAT file system (i.e., larger SD cards, which becomes a
problem when syncing to mobile).

[1] https://fortelabs.co/blog/para/

[2] Personal Information Management

[3] So it doesn't need to open a bunch of files in Emacs / Org.  It's
also fast enough (so far) to use "live."

[4] I originally planned to implement additional full text search
functions using things like org-ql, [rip-]grep, and/or Recoll, but so
far this has proved to be unnecessary.



Re: Culling org files

2021-03-04 Thread TRS-80

On 2021-03-03 16:59, Samuel Wales wrote:

along lines of reducing logbook entries


I guess you must have picked up on my comment in another recent
thread.  :)


i often want to reduce org
files, and i wonder if anybody already had the same desire.

here are some random ideas.  my org files are so
large i might have written this list a few times

  1) list links to duplicate headlines
  2) list links to duplicate body text
  3) list links to duplicate entries
  4) list links to duplicate entries, body text, or
 headlines using fuzzy matching
 - suppose you captured an email slightly differently a
   few times
  5) show in agenda the biggest few tasks so you can go to
 them and reduce them or doneify them
  6) (waves hands) git magic to find old entries that might
 be stale
  7) show in agenda the tasks with biggest logbook drawers
 so you can go to them and reduce them
  8) find similar body text that are in distant subtrees
 that might be candidates for refactoring using org-id
 linking
  9) show in agenda deepest olpath levels
  10) indicate deep, shallow, text-filled, etc. top levels
  11) show in agenda entries with most children
  12) archive logbook drawer entries older than 1 year
  - get rid of drawer if empty
  - put the drawer entries into a logbook drawer in a
new task, with a similar header, that then gets
doneified.  then that gets archived when you archive
stuff.
  13) operate on lines matching a pattern
  - e.g. "* [2021-02-17 Wed 20:35]  whatever" lines
might be insubstantial notes that do not need to
clutter the inactive timestamp display in the agenda
and thus should be moved to a target location with
query
  - that target location would presumably not be in an
agenda file
  14) function to lint all agenda files
  15) reduce false positives in lint

well, idk if htese are good ideas.  just thought maybe we
could form a cult of "don't let org files get too big".


I have come to similar conclusion about "don't let org files get too
big."  Besides agenda speed, I think it is just easier to
conceptualize things when each file covers only a limited scope, trees
are more shallow, etc.

So, lately (last year or more), I have been trying a "many small (up
to perhaps medium)" instead of "few big" files approach (along with
some custom tooling) and it has been working /a lot/ better for me.  I
really feel on top of things for the first time in a long time.  My
agenda is not cluttered.  I can focus on important things, while not
losing track of the rest, etc.

I could write a whole lot about my "custom tooling" but as that is an
entire package in its own right (still in experimental development and
thus unreleased), I will limit my comments here only to the "archival"
portion of this problem.

I realized, at least in my case, after mulling this over for some
time, that there seem to be a few distinct cases which would need to
be handled by a custom archival function:

- If the TODO is still active, and the number of logbook entries
  exceed some (definable) threshold, either move the older entries to
  a similarly named archive file/heading, or (also definable) simply
  delete them.  This would cover things like habits and other
  recurring tasks that tend to generate lots and lots of entries over
  time.  This is perhaps the part I mentioned in the other thread
  recently.

- If the TODO is completed (and perhaps also after it becomes a
  certain (again, definable) age), then move the whole TODO to a
  similarly named archive file.

- There was another, but I think it was for the case where the entire
  file is a project (which is a bit specific to my own setup).

Ideally, this custom function would handle all the above cases, and
could be called with point at each headline, so it would be easy to
map over a file or even a directory full of files, in order to
automate the archival process (perhaps annually?).

Cheers,
TRS-80



Re: Remove old clock entries

2021-03-03 Thread TRS-80

On 2021-03-01 01:20, Julien Cubizolles wrote:

I'm clocking the time spent on daily tasks like email and for that I
have a "Daily Routine" TODO entry. Clocking in this task adds a new
clock line everyday, leading to a very populated CLOCK drawer. I'd
like to limit its size by either a maximum number of clock entries
by removing the older ones or better, removing the entries older
than some date. Is there some variable to that effect ?


Not that I am aware of (anyone is welcome to correct me if I am
wrong).

Because I have similar problem, I have been thinking about this for a
while.  I am no longer clocking, but in my case I have a lot of state
change logging.  But these are similar.

I was thinking about incorporating some handling of these entries into
a custom archival function.  Which would also handle some other things
at the same time.  But so far, it's just some notes and thoughts about
desired functionality and how it might work.  And I keep monitoring
the mailing list for some better ideas.  :)

Cheers,
TRS-80



Re: contact management in emacs

2021-03-03 Thread TRS-80

On 2021-02-28 04:06, Russell Adams wrote:

The stumbling point for me has been exporting to my mobile
phone. I'm fine with a one way sync from my BBDB/Org solution to the
phone, but I feel like I never found a good option.

Please share what you find works for you.


I never got further than reading about it, but I have done quite a lot
of that.  And it always seems like this is the stumbling block.
Especially two way sync (as I probably most often add new contacts
into my phone, when I am out and about).

OTOH, my PinePhone has just recently shipped, so perhaps having an
actual GNU/Linux phone (instead of Android) may suddenly obviate the
need for all these complicated workarounds...  I suppose I will be
interested in what sort of format the Contacts "app" will be storing
them on the PinePhone.  In fact, I think I will search for (or make) a
thread about that at Pine64 forums...

Cheers,
TRS-80



Re: Set archive location relative to property

2021-02-26 Thread TRS-80

On 2021-02-25 15:49, Florian Lindner wrote:

Am 25.02.21 um 21:22 schrieb Florian Lindner:

is this possible with org-mode? Given a tree:

* Name
:PROPERTIES:
:ARCHIVE:  ???
:END:
** Archive    :ARCHIVE:
** Some node

Upon archiving "Some node" (or any direct or indirect sub-node of
Projectname) I want to end it up under "** Archive". The archive
location should always be relative to the node where the property
ARCHIVE is set.

The documentation org-archive-location does not suggest that is
possible.


An alternative idea would be a setting for the ARCHIVE property that
searches the tree upward until it finds a node with an :ARCHIVE: tag
and use that as archive location. Maybe indicated by a setting of
"::%a".

What do you think?


I could be wrong, but my feeling (in either case) is something like
that would probably require writing a custom archive function.
Luckily, Orgmode allows you to do that.

Cheers,
TRS-80



Re: Tips on maintaining history in Org Mode

2021-02-26 Thread TRS-80

On 2021-02-26 01:22, David Masterson wrote:

There are many ways of maintaining history in a group of Org files:
1. Archive within a file
2. Archive to a separate (archive) file
3. Special TODO types for history
4. Special TAG types for history
5. etc.

My question is, if you have meetings/phone calls as TODOs, what is the
preferred way to handle when they move into history so that, *much*
later, you can easily produce a list of all of the meetings/phone calls
with dates and times of them?  The issue (I think) is, when you mark 
the

TODO as DONE, you lose the info of what the TODO was originally.

Suggestions


I agree with what others already said about logging state changes with
timestamps.  I do the same and find this an extremely handy place to
put "metadata about the task, or reason that it changed" and keep it
separate/hidden from the main body of the task (which in my mind
should only contain info about the subject of the headline / task
itself).

However when you say "history" I suspect you mean "archive" and this
is something I have been thinking about a long time as well.  Because
I think the current way that Orgmode handles this is a bit naive /
simplistic.  Well, at least there is the option to create your own
archival function, which I suspect I will do at some point.  In fact I
have been thinking about the best way to do that for some time
already.

Cheers,
TRS-80



Re: Turning off all indentation in 9.4.4

2021-02-26 Thread TRS-80

On 2021-02-26 01:20, Kyle Meyer wrote:

TRS-80 writes:


On 2021-02-24 15:58, TRS-80 wrote:

On 2021-02-16 23:30, Kyle Meyer wrote:

[...]
So, if I'm reading your preferences correctly, it sounds like you 
want

just the first suggestion in the above snippet, leaving
org-adapt-indentation at its default value:

  (add-hook 'org-mode-hook (lambda () (electric-indent-local-mode 
-1)))


OK, I just did eval-expression (M-:) with (electric-indent-local-mode
-1) in an Orgmode buffer.  After very brief testing, it does indeed
seem to return the desired behavior.  So thanks a lot for that tip!

[...]

OK, so after that yesterday, I went ahead and added
(electric-indent-local-mode -1) to my org-mode hook.  Then today upon
re-starting Emacs, I am back to not working.

By not working I mean:  Pressing enter goes to column 0 as it should,
however then pressing  does nothing.  Where previously it would
jump to same level as indented above.

My settings are:

- electric-indent-local-mode nil (local in each Orgmode buffer, set 
via

hook)

- org-adapt-indentation 'headline-data


I'm just repeating my suggestion from above, but perhaps you want to
leave org-adapt-indentation at its default value of t?


Apologies, I had skipped right over that bit!

Doing as you say appears (after very brief test just now) to have given
me back all the expected behavior:

- RET goes to column zero

- TAB goes to indentation level

- Logbook entries are indented as they should be

However in the course of doing this, it reminded me of what I was trying
to do in the first place, which I thought I could accomplish with some
of the new functionality (headline-data in particular).

In my mind at least, the headline data belongs "with" the headline.  So
all drawers like LOGBOOK and PROPERTIES (and their respective entries,
of course) should all be indented to same level as headline.

Now, I used to think the same way about the body text, but I changed my
mind a year or two (maybe more) ago, as I realized that was just wasting
too mych space.

So, my reading of this new(?) headline-data setting, was that it seemed
to be exactly what I had been looking for!  But perhaps I misunderstood?

Cheers,
TRS-80



Re: Turning off all indentation in 9.4.4

2021-02-25 Thread TRS-80

On 2021-02-24 15:58, TRS-80 wrote:

On 2021-02-16 23:30, Kyle Meyer wrote:

TRS-80 writes:

Unfortunately, unless I am doing something wrong, none of these 
options

seem to really restore the previous behavior.  I have set
~org-adapt-indentation~ to ~'headline-data~, and now pressing RET 
goes

to column 0.  However, unfortunately, TAB now no longer jumps to the
indentation level of the previous block (for example, so I can insert 
a

code block or other block structure into a plain list at the correct
level).


I think you're talking about the following behavior.

  * a
  foo

With org-adapt-indentation at nil (or the new headline-data value), 
foo
doesn't get indented.  This behavior is not new to 9.4.  If you try 
with
9.3.8 and org-adapt-indentation is set to nil, it also will not 
indent.

Step through org--get-expected-indentation to see how the different
values of org-adapt-indentation are handled.

So, if I'm reading your preferences correctly, it sounds like you want
just the first suggestion in the above snippet, leaving
org-adapt-indentation at its default value:

  (add-hook 'org-mode-hook (lambda () (electric-indent-local-mode 
-1)))


OK, I just did eval-expression (M-:) with (electric-indent-local-mode
-1) in an Orgmode buffer.  After very brief testing, it does indeed 
seem

to return the desired behavior.  So thanks a lot for that tip!

In the same timeframe, I have also noticed my Logbook entries not being
indented (when changing TODO states) which I think was also brought
about by this change (or rather, my changes to org-adapt-indentation).
I am not sure if I should make a separate thread about that, or not?


OK, so after that yesterday, I went ahead and added
(electric-indent-local-mode -1) to my org-mode hook.  Then today upon
re-starting Emacs, I am back to not working.

By not working I mean:  Pressing enter goes to column 0 as it should,
however then pressing  does nothing.  Where previously it would
jump to same level as indented above.

My settings are:

- electric-indent-local-mode nil (local in each Orgmode buffer, set via
hook)

- org-adapt-indentation 'headline-data

I am also using adaptive-wrap-prefix-mode to do a soft wrap on left
side, not sure if this is involved or not.

Any help is greatly appreciated, as this is maddeningly aggravating.

Cheers,
TRS-80



Re: Turning off all indentation in 9.4.4

2021-02-24 Thread TRS-80

On 2021-02-16 23:30, Kyle Meyer wrote:

TRS-80 writes:

Unfortunately, unless I am doing something wrong, none of these 
options

seem to really restore the previous behavior.  I have set
~org-adapt-indentation~ to ~'headline-data~, and now pressing RET goes
to column 0.  However, unfortunately, TAB now no longer jumps to the
indentation level of the previous block (for example, so I can insert 
a

code block or other block structure into a plain list at the correct
level).


I think you're talking about the following behavior.

  * a
  foo

With org-adapt-indentation at nil (or the new headline-data value), foo
doesn't get indented.  This behavior is not new to 9.4.  If you try 
with

9.3.8 and org-adapt-indentation is set to nil, it also will not indent.
Step through org--get-expected-indentation to see how the different
values of org-adapt-indentation are handled.

So, if I'm reading your preferences correctly, it sounds like you want
just the first suggestion in the above snippet, leaving
org-adapt-indentation at its default value:

  (add-hook 'org-mode-hook (lambda () (electric-indent-local-mode -1)))


OK, I just did eval-expression (M-:) with (electric-indent-local-mode
-1) in an Orgmode buffer.  After very brief testing, it does indeed seem
to return the desired behavior.  So thanks a lot for that tip!

In the same timeframe, I have also noticed my Logbook entries not being
indented (when changing TODO states) which I think was also brought
about by this change (or rather, my changes to org-adapt-indentation).
I am not sure if I should make a separate thread about that, or not?

Cheers,
TRS-80



Re: Symolic link messes up org-attach?

2021-02-22 Thread TRS-80

On 2021-02-22 11:16, Henrik Frisk wrote:

Hi,

I have migrated from a OSX based system to a linux/debian system.


Welcome to the Free World!  :D


I have all my main org files in a directory ~/org and in OSX this was
a symbolic link to ~/a-hard-disk/org (it may have been an alias, ot
sure). In Ubuntu, however, I have lots of trouble with org-attach: I
attach a file using say copy and when I call C-c C-a o there are no
attachments. Sometimes it works but next time I open the file there
are no attachments. I experienced similar issues with links:

[[file:./img/myimage.png]]

was not found but a qualified path worked.

Could this be because of the symlink to my org directory? Is there a
better way to do it?


I do not use org-attach, but I do use a lot of symlinks (at the
underlying system level), and they never give me any trouble (for
whatever that's worth).

Cheers,
TRS-80



Re: error "Can’t expand minibuffer to full frame"

2021-02-22 Thread TRS-80

On 2021-02-22 09:42, Florian Lindner wrote:

Hello,
I try to configure my org mode (Org mode version  ( @
/lhome/lindnfl/.emacs.d/elpa/org-9.4.4/)) to ask for a note and also
for a specific property when moving a state to WAIT. For that I use

(setq
  org-todo-keywords '((sequence "NEXT" "TODO" "WAIT(w@)" "|"
"DONE(d!)" "NODO(n@)"))
  org-log-into-drawer t
)

(defun flo/org-state-change()
  (when (string= org-state "WAIT")
(org-set-property "DELEGATED_TO" (read-string "Delegate To: "

(setq org-after-todo-state-change-hook 'flo/org-state-change)

However, I suspect the state-change-hook and the note when leaving
WAIT state conflict:

Error in post-command-hook (org-add-log-note): (error "Can’t expand
minibuffer to full frame")

resulting in that I am only asked to set the property, note the note.

What can i do about it? I don't really care in which order I enter the
two note / property.

Thanks,
Florian


I seem to recall having a similar conflict.  In my case, I realized that
the calling script "kept going" instead of waiting for the note entry to
be completed.  Therefore, try and make sure that org-log-into-drawer
gets called "last."  I am pretty sure this will require digging into Org
internals to see in what order things go.

Sorry if that's vague, it's been a while since I dealt with this.  And
it may or may not even actually be your problem.

Cheers,
TRS-80



Re: Turning off all indentation in 9.4.4

2021-02-14 Thread TRS-80

On 2021-02-04 12:45, Kévin Le Gouguec wrote:

Raoul Comninos  writes:

I noticed a change in org since I updated to the latest version when 
it

comes to automatic indentation. I prefer to turn this off globally,
including for lists. I have tinkered with various settings but have 
had

no luck so far.


ORG-NEWS provides these hints:


To get the previous behaviour back, disable ~electric-indent-mode~
explicitly:

#+begin_src emacs-lisp
(add-hook 'org-mode-hook (lambda () (electric-indent-local-mode -1)))
#+end_src

Alternatively, if you wish to keep =RET= as the "smart-return" key,
but dislike Org's default indentation of sections, you may prefer to
customize ~org-adapt-indentation~ to either =nil= or ='headline-data=.


Normally I would recommend customizing org-adapt-indentation over
disabing electric-indent-local-mode, but if you'd rather move back to
column 0 when hitting RET in a list, the hook is probably the way to 
go.


I have been struggling with this as well.  After reading this email, I
gave it another try.

Unfortunately, unless I am doing something wrong, none of these options
seem to really restore the previous behavior.  I have set
~org-adapt-indentation~ to ~'headline-data~, and now pressing RET goes
to column 0.  However, unfortunately, TAB now no longer jumps to the
indentation level of the previous block (for example, so I can insert a
code block or other block structure into a plain list at the correct
level).

I am finding all of this /extremely/ annoying, and if I am being honest,
quite obnoxious behavior, which is the last thing I usually expect from
Emacs.

Cheers,
TRS-80



org-fontify-done-headline t by default?

2021-01-22 Thread TRS-80

Hello *,

I finally got around to upgrading Emacs (and Orgmode) the last couple
days.  Therefore apologies if this has been discussed previously.  A
brief search of the list did not turn up any results.

Anyway, imagine my shock when many of my headlines suddenly turned
LightSalmon!

Now, this only took me few minutes of digging to figure out.  However I
am pretty handy with Emacs and Elisp by now.  What about some poor
newbie that barely knows their way around an init file?

The change was so jarring, and in total contravention of my (otherwise)
nice looking Nord theme.  Something like that might have put me off from
Orgmode /completely/ if I did not know how to quickly fix it.

For all of above reasons (and probably some others, too!), I do not
think this should be the default!

Please discuss.

Cheers,
TRS-80



Re: How can I keep Org-id links from breaking when moving files?

2021-01-22 Thread TRS-80

On 2021-01-21 08:14, aroz...@gmail.com wrote:

there's no way to programmatically make sure that Org can find those
IDs again (since there's no way to simply add a folder, rather than a
list of files, to =org-id-locations= or  =org-id-files=?


Being that this is Emacs, you can do almost anything you want, with a
little Elisp practice.  ;)

For example, you could write some custom move command which would
automatically add the new folder to some variable or file with a list of
folders to add to places for org-id to look in from now on.

However perhaps we should take a step back and ask ourselves if this is
a good approach?  And IMHO, starting to scatter files here and there
throughout the filesystem is not a good idea.  Even if you implement
above mentioned custom Elisp, it adds (IMO, needless) complexity.

Therefore I would think long and hard if that is actually really
necessary, before starting to go down that path.  Just my $0.02.

Cheers,
TRS-80



Re: ol-plo.el --- Orgmode Link type for navigating Ordered Plain Lists

2021-01-12 Thread TRS-80

On 2021-01-12 15:33, Daniele Nicolodi wrote:

On 12/01/2021 21:21, TRS-80 wrote:

Hello *,

I just banged out a bit of Elisp implementing a new Orgmode link type
for navigating Ordered (i.e., numbered/lettered) Plain Lists.[0]


How do you deal with the lists being re-numbered when you edit them?


Currently, just manually updating the links.

I guess in my usage, I mostly keep adding on to the bottom of the Plain
List (taking notes) so I rarely need to re-order anything.

However you raise a good point, and suddenly I realize I have written an
"80% solution."  Adding that other 20% would increase the complexity and
amount of code by...?  For me, not worth it (for the time being).

However, you are helping me to answer the question about where it should
"live."  I now no longer[0] think it appropriate for that to be within
Orgmode itself (and perhaps not even in contrib).  So, thanks for that.
:)

Basically, what I wrote so far is a "first pass."

Cheers,
TRS-80

[0] Not that I necessarily did in the first place.  ;)



ol-plo.el --- Orgmode Link type for navigating Ordered Plain Lists

2021-01-12 Thread TRS-80

Hello *,

I just banged out a bit of Elisp implementing a new Orgmode link type
for navigating Ordered (i.e., numbered/lettered) Plain Lists.[0]

As I tend to use Plain Lists extensively when taking notes, this is
something I (personally) have been wanting for some time.  But maybe
others might also find it useful.

Here is a teaser, copied from my (working title) ol-plo.el file:

#+begin_src emacs-lisp
  ;;; Commentary

  ;; Implements an Orgmode link type for nagivagting to other
  ;; locations within the same Ordered (numbered) Plain List in
  ;; Orgmode.
  ;;
  ;; The link type is "plo:" for Plain List, Ordered (see Plain
  ;; List section of Orgmode manual).
  ;;
  ;; Example: Following Orgmode link at position [Y] like
  ;; [[plo:1.2.1.][Description]] would move point from [Y] to [X]
  ;; below:
  ;;
  ;; * Heading
  ;;
  ;; 1. Section
  ;;1. Subheading
  ;;2. Another subheading
  ;;   1. [X]Link to
  ;; 2. Another Section
  ;;   1. Link from [Y]
  ;;
#+end_src

If there is any interest, I could post it up somewhere.  In which case,
more questions arise:

1. Where should this live?
   a. In Orgmode itself?
   b. In contrib?
   c. As an outside package?

Hence my thought to first float the idea on the mailing list.

I am also unsure I even like "plo:", maybe it should be "opl:" (for
Ordered Plain List)?  Or even something else?

Discuss!  :)

Cheers,
TRS-80

[0] https://orgmode.org/manual/Plain-Lists.html



Re: [PATCH] org-footnote: fix inserting new footnote mangling drawers (was: Re: Bug: inserting footnote when Footnotes heading has property drawer [9.3.6 (9.3.6-23-g01ee25-elpaplus @ /home/user/.emacs

2021-01-12 Thread TRS-80

On 2021-01-10 19:57, Kyle Meyer wrote:

Thanks for the initial report and the patch.


I am very happy to contribute!

Thanks for taking it easy on me the first time around.  :)


TRS-80 writes:
Subject: [PATCH] org-footnote: fix inserting new footnote mangling 
drawers


convention nit: s/fix/Fix/ (no need to resend)


Duly noted!


I'm planning to squash the following test in when applying.  Look okay
to you?


diff --git a/testing/lisp/test-org-footnote.el
b/testing/lisp/test-org-footnote.el
index eca24d315..50a430785 100644
--- a/testing/lisp/test-org-footnote.el
+++ b/testing/lisp/test-org-footnote.el
@@ -138,7 +138,20 @@ (ert-deftest test-org-footnote/new ()
  (org-test-with-temp-text
  "Paragraph\n# Local Variables:\n# foo: t\n# End:"
(let ((org-footnote-section "Footnotes")) (org-footnote-new))
-   (buffer-string)
+   (buffer-string
+  (should
+   (equal "Para[fn:1]
+* Footnotes
+:properties:
+:custom_id: id
+:end:
+
+\[fn:1]"
+  (org-test-with-temp-text
+  "Para\n* Footnotes\n:properties:\n:custom_id: 
id\n:end:"

+(let ((org-footnote-section "Footnotes"))
+  (org-footnote-new))
+(org-trim (buffer-string))

 (ert-deftest test-org-footnote/delete ()
   "Test `org-footnote-delete' specifications."


I must admit that currently I am still unfamiliar with the testing
framework(s).  It is something I am interested in learning, but haven't
gotten around to /yet/.

Therefore, hopefully some other set of eyeballs could give that another
look?

Cheers,
TRS-80



Re: Possibility to copy text outside EMACS and send it to orgmode document

2021-01-09 Thread TRS-80

On 2021-01-07 01:29, Gerardo Moro wrote:

Thanks. Then why is in
https://orgmode.org/worg/org-contrib/org-protocol.html#installation
this confusing bit?

INSTALLATION

*

To load org-protocol.el add the following to your .emacs:

(server-start)
(add-to-list 'load-path "~/path/to/org/protocol/")
(require 'org-protocol)

El jue, 7 ene 2021 a las 8:17, Tom Gillespie ()
escribió:


It is built into the core org distribution.


Perhaps documentation should be updated?

Cheers,
TRS-80



[PATCH] org-footnote: fix inserting new footnote mangling drawers (was: Re: Bug: inserting footnote when Footnotes heading has property drawer [9.3.6 (9.3.6-23-g01ee25-elpaplus @ /home/user/.emacs.d/e

2021-01-09 Thread TRS-80

On 2021-01-03 16:27, TRS-80 wrote:

Hello!

I seem to have come across a bug today in org-footnote.

I had just learned about the variable org-footnote-auto-adjust and set
it to t.  Then I tried to test it by invoking org-footnote-new in my
Org file in between existing footnotes 2 and 3.

N.B., my Footnotes heading, prior to doing above also had a CUSTOM_ID
property set:

#+begin_src org
  ,** Footnotes
 :PROPERTIES:
 :CUSTOM_ID:footnotes
 :END:

  [fn:1] original footnote 1

  [fn:2] original footnote 2

  [fn:3] original footnote 3

  [fn:4] original footnote 4

#+end_src

The new footnote seems to get inserted into correct place, however 
there

appears to be a problem if there is a property drawer:

#+begin_src org
  ,** Footnotes

  [fn:1] original footnote 1

  [fn:2] original footnote 2

  [fn:3] new footnote
 :PROPERTIES:
 :CUSTOM_ID:footnotes
 :END:

  [fn:4] original footnote 3

  [fn:5] original footnote 4

#+end_src

Since I was just studying the org-footnote code anyway, I will attempt
to further diagnose the issue, and perhaps even send a patch.

As I was filling out bug report I realized I am on slightly dated
version of Orgmode.  So I went ahead and cloned latest version and did 
a

diff on org-footnote.el between my affected version here locally and
latest, and the only change I saw was the copyright date.

So with that out of the way, I will start digging and see what I can
come up with.

Cheers,
TRS-80


Emacs  : GNU Emacs 26.3 (build 2, x86_64-pc-linux-gnu, GTK+ Version 
3.24.20)

 of 2020-05-16, modified by Debian
Package: Org mode version 9.3.6 (9.3.6-23-g01ee25-elpaplus @
/home/user/.emacs.d/elpa/org-plus-contrib-20200309/)


Attached please find a very simple (one line) patch that I believe
should fix this issue.

This patch is of course based on latest git (not my personal outdated
version) and also maint branch.  I think I've got that right?

However as it will be my first patch to Orgmode, any feedback would be
welcomed.

Cheers,
TRS-80
From cf7111a87645262c68214a03ca88f72bb0710049 Mon Sep 17 00:00:00 2001
From: TRS-80 
Date: Sat, 9 Jan 2021 11:50:50 -0500
Subject: [PATCH] org-footnote: fix inserting new footnote mangling drawers

* org-footnote.el (org-footnote-create-definition): Replace
  `forward-line' with `org-end-of-meta-data' to skip over any
  properties and/or drawers that may be present on the
  `org-footnote-section' heading (default "Footnotes").

TINYCHANGE
---
 lisp/org-footnote.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/org-footnote.el b/lisp/org-footnote.el
index 3d42421e0..47ad4aa04 100644
--- a/lisp/org-footnote.el
+++ b/lisp/org-footnote.el
@@ -704,7 +704,7 @@ function doesn't move point."
 	   (concat "^\\*+[ \t]+" (regexp-quote org-footnote-section) "[ \t]*$")
 	   nil t))
 	(goto-char (match-end 0))
-	(forward-line)
+(org-end-of-meta-data t)
 	(unless (bolp) (insert "\n")))
(t (org-footnote--clear-footnote-section)))
   (when (zerop (org-back-over-empty-lines)) (insert "\n"))
-- 
2.29.2



Bug: inserting footnote when Footnotes heading has property drawer [9.3.6 (9.3.6-23-g01ee25-elpaplus @ /home/user/.emacs.d/elpa/org-plus-contrib-20200309/)]

2021-01-03 Thread TRS-80

Hello!

I seem to have come across a bug today in org-footnote.

I had just learned about the variable org-footnote-auto-adjust and set
it to t.  Then I tried to test it by invoking org-footnote-new in my
Org file in between existing footnotes 2 and 3.

N.B., my Footnotes heading, prior to doing above also had a CUSTOM_ID
property set:

#+begin_src org
  ,** Footnotes
 :PROPERTIES:
 :CUSTOM_ID:footnotes
 :END:

  [fn:1] original footnote 1

  [fn:2] original footnote 2

  [fn:3] original footnote 3

  [fn:4] original footnote 4

#+end_src

The new footnote seems to get inserted into correct place, however there
appears to be a problem if there is a property drawer:

#+begin_src org
  ,** Footnotes

  [fn:1] original footnote 1

  [fn:2] original footnote 2

  [fn:3] new footnote
 :PROPERTIES:
 :CUSTOM_ID:footnotes
 :END:

  [fn:4] original footnote 3

  [fn:5] original footnote 4

#+end_src

Since I was just studying the org-footnote code anyway, I will attempt
to further diagnose the issue, and perhaps even send a patch.

As I was filling out bug report I realized I am on slightly dated
version of Orgmode.  So I went ahead and cloned latest version and did a
diff on org-footnote.el between my affected version here locally and
latest, and the only change I saw was the copyright date.

So with that out of the way, I will start digging and see what I can
come up with.

Cheers,
TRS-80


Emacs  : GNU Emacs 26.3 (build 2, x86_64-pc-linux-gnu, GTK+ Version 
3.24.20)

 of 2020-05-16, modified by Debian
Package: Org mode version 9.3.6 (9.3.6-23-g01ee25-elpaplus @ 
/home/user/.emacs.d/elpa/org-plus-contrib-20200309/)




Re: Release Org 9.4.2

2021-01-02 Thread TRS-80

On 2020-12-18 16:49, Asa Zeren wrote:

Have people looked at sourcehut (https://sourcehut.org)? While it's
still in alpha, and so has a number of rough edges, it seems pretty
promising. Sourcehut is trying to build a platform with accessible web
uis that is backed by mailing lists. Just annother option to consider,
though there is no urgency to move from the current situtation.

--Asa


I have been using Sourcehut for about a month and loving it so far![0]

I searched for long time for a git forge I could live with.  Most of
popular options nowadays seem either proprietary software or typical
sluggish castles of JavaScript (or both!) as is so much of the "modern"
web.

So, when I finally discovered Sourcehut (which is neither of the above
mentioned things) it was like a breath of fresh air in comparison!  I
really appreciate what Drew is trying to do over there.

I even ironed out one or two of those "rough edges" getting some Orgmode
export (to sr.ht supported Markdown) stuff working a little better (and
I continue to do so).  I don't mind at all (in fact rather enjoy)
contributing to actual no-bs Free Software platform!

Come join me!  Come on in, the water is fine... :)

Cheers,
TRS-80

[0] https://sr.ht/~trs-80/



Re: Bring up a screen giving option to open a series of orgmode files

2020-12-15 Thread TRS-80

On 2020-12-14 23:42, Ihor Radchenko wrote:

TRS-80  writes:


We are getting further and further afield from Orgmode discussion,
however I wanted to share the following article with anyone else who
followed this part of the thread all the way to this point:


Oops. Actually, hypothes.is is related to org-mode in my mind. Mostly 
as

a reference of implementation of fine-grained links to
web-pages/documents. I wish org-mode links had universal support to
position inside the document the link is pointing to (similar what is
already present in file link to org files, where we can refer to
specific heading inside the referenced file). It would be great if
org-mode extended the link syntax to define position inside the text
file/web-page/video/pdf/etc. Then, packages like org-pdftools would not
need to invent new link types just to be able to refer to specific page
or annotation inside a pdf file.

The relevant feature request is in my todo list.

Best,
Ihor


Oh no, I think you guys are fine.  I just didn't want to get into big
discussion about things on that website, as there are just s many
things there to discuss...

So when I said that, I was referring mostly to myself and also as a way
to sort of pre-emptively try and head off too big diversion...  :)

Cheers,
TRS-80



Re: Bring up a screen giving option to open a series of orgmode files

2020-12-14 Thread TRS-80

On 2020-12-14 14:08, Jean Louis wrote:

* Ihor Radchenko  [2020-12-14 15:55]:

Jean Louis  writes:

> * Ihor Radchenko  [2020-12-13 03:39]:
>> Jean Louis  writes:
>> hypothes.is
>
> I can install it on VPS which is definitely in plan. Locally I do not
> locally I have dynamic knowledge repository

I am actually just trying hyposes.is now (after you reminded me about
it). For me, the main advantage is not for pdfs, but rather the 
ability

to have pdf-like annotations in web-pages: highlights, comments, etc.
Combined with local ArchiveBox [1] storage, I can get annotations for 
my

local web archive.

[1] https://github.com/ArchiveBox/ArchiveBox


I have seen it, good tool and it makes sense to have one's own archive
as web pages really disappear. You reminded me of so many references
that it helped me streamline my workflows for soon future and new 
projects.



Hypothes.is as online instance is then useful for those online files,
and WWW pages, but the approach of having private archive and then
annotating such is even better. Still the hypothes.is is separate
dynamic knowledge repository for annotations. Different database,
different set of rules but same open hyperdocument project set of
principles. So I better stick to one database, not to two.


We are getting further and further afield from Orgmode discussion,
however I wanted to share the following article with anyone else who
followed this part of the thread all the way to this point:

How to annotate literally everything[0]
by karlicoss

There are quite a lot of other very interesting articles there as well
in the same (and related) veins.  Enjoy!

Cheers,
TRS-80

[0] https://beepb00p.xyz/annotating.html



Re: Org Capture Menu cannot be fully viewed

2020-12-13 Thread TRS-80

On 2020-12-12 23:57, pie...@caramail.com wrote:

TRS-80 wrote:

If you care to share a slightly bigger picture view, particularly
about the structure of the data you are trying to capture (and/or,
your workflow) we could likely come up with something that would work
much better for you than a capture template, at least in this
particular case.


In many instances, previous work would have been done, so people would
want to quickly skip entries.


I think perhaps plain old Org headline folding might be great for
quickly navigating to the incomplete portion of the document?
Especially if the sections each might contain a lot of prose and/or
notes, and/or the sections are logically organized in any sort of tree
structure.

If it's more about key: value type data, I would (again) recommend Org
Properties.  I'm sure there might be a way (or we could whip one up) to
help automate searching through the document looking for empty
Properties if that's the sort of workflow you would like.


The plan for Org-Mode Capture is primarily for such Exclusive and
Unsystematic Surveys where we do not necessarily use standard forms.
I'm not sure if you capture the drift concerning unsystematic surveys.
Most times I cannot tell you exactly what people in the field came up
with.  The pace can be rapid and some could be working in challenging
conditions.  The plan is for the Crew Chief to make a quick template,
and which could change each day.  maintain and review notebooks and
records and overseeing quality control is done daily.  It is customary
to split the day.  One of the best ways we improve survey efficiency
is to anticipate bottlenecks and invent creative logistical solutions
right in the field.

The long template situation then occurs.  You can access better than
myself as you know what org and org-capture can do and what not.


Overall, what I am imagining is some set of Orgmode files as templates.
Each template containing all requirements of data collection for that
type.  So you would simply make new copy of empty template file for each
new instance of that particular case / template.  Inside would be
headings organizing the different parts of the survey or whatever the
work is.  And then Org Properties as needed for key: value data, located
within the tree structure on headings as appropriate (remembering that
Property inheritance is possible).

You could even use the TODO functionality to mark sections as being
complete.  It then becomes easy to find sections which have not been
finished yet.  With org-log-done and org-log-into-drawer (and other
related) settings you could even have different teams make (timestamped)
metadata notes about what they accomplished, making it easier to hand
off partially completed work between teams and allow them to communicate
between each other in a sort of side channel without that info being
directly in the report.

As you can see, there are often many options, so it's mostly about "what
workflow do you want?"  ;)


I briefly reported on what we found problematic in practice.  But
we're at the beginning of this, and would likely report on other
things as we progress.


Yes, please let us know how you are getting on!


Nevertheless, we see some aspects where your scheme can be improved to
cater for more serious work.  Emacs is quite good software.


This is probably the strongest point.  Emacs can be almost whatever you
want it to be.  Even non-programmers (with a little effort) can stitch
together their own custom interfaces using some combination of
package(s), built-in functionality, and perhaps a bit of Elisp.  Which
makes it a bit of a universal User Interface framework, in a way.


Hope my comments helped somewhat.


Yes, I think so.  Hopefully my replies will therefore heve been equally
helpful to you.

Cheers,
TRS-80



Re: Org Capture Menu cannot be fully viewed

2020-12-13 Thread TRS-80

On 2020-12-13 16:02, pie...@caramail.com wrote:


Would that apply with respect to inserting long headings or
descriptions in org file?


Yes.  If you have not used completing-read, just play around with it a
bit and you will very quickly see how it works.  It takes a list (Elisp
data type) as input, on which you can do narrowing selection as you
type.

Ivy was one of recommendations which I can second, I prefer it's more
intuitive (to me) interaction style and support for native
completing-read format.  But there are (many) others, too.


Example:

;;"Site_SubType:
;;   [1a] Settlement > Encampment
;;   [1a] Settlement > Hamlet or Village
;;   [1a] Settlement > Town or City
[...]


However to make it even simpler to use / maintain your candidate lists,
I would just put them in a simple plain text file, aligned to left
margin.  Example:

File name: Site_SubType

[1a] Settlement > Encampment
[1a] Settlement > Hamlet or Village
[1a] Settlement > Town or City

Then you need a function to read from plain text file with your "list"
of candidates, and turn that into an (Elisp data type) list:

#+begin_src emacs-lisp

(defun my-file-to-list (file)
"Read FILE and return it as a list of strings.

  List items will be split upon newlines."
(with-temp-buffer
  (insert-file-contents file)
  (split-string (buffer-string) "\n" t)))

#+end_src

You then use the above function (with filename argument) for your
candidate list in completing-read.  Modifying Jean Louis' earlier
example, it now becomes:

#+begin_src emacs-lisp

  (completing-read "Choose: "
   (my-file-to-list "/path/to/Site_SubType"))

#+end_src

You can even use this to fill in Org Properties.  Or you can use Org
Properties similar native completion, although by default that only uses
whatever values already exist in the buffer (which therefore could be
"none"), instead of your specified controlled vocabulary file as I used
above.  I (by far) prefer the controlled vocabulary method, for lots of
reasons.

Cheers,
TRS-80



Re: Org Capture Menu cannot be fully viewed

2020-12-13 Thread TRS-80

On 2020-12-13 15:37, Jean Louis wrote:

* pie...@caramail.com  [2020-12-13 21:28]:

I suggest that you install package ivy that you see how it works. Then
you could try find-file or open file function to see completions.

You can try evaluating this here:

(setq collection '("I think it might" "Is that similar" "Or something 
similar"))


(completing-read "Choose: " collection)

You may then use TAB or C-j to complete among various options.

ivy and helm packages (maybe) enhances that and allow you to type just
"som" to reach to "Or something similar" or "think" to reach to "I
think it might" and offers basic relevance search if you use few
words.

Standard completion may use joker symbol *

Choose: *thingTAB

would expand to "Or something similar"

That is good way to go in Emacs if you have to chose among large
number of items of anything.


This is much more along lines of what I had in mind.  A nice simple
example of plain completing-read interface.  However I am still not sure
that Org Properties are not the answer...

Cheers,
TRS-80



Re: Org Capture Menu cannot be fully viewed

2020-12-13 Thread TRS-80

On 2020-12-13 13:41, pie...@caramail.com wrote:

From: "Jean Louis" 

;; Create hash
(setq my-files-hash (make-hash-table))

;; Try putting something into the hash, define your files and their 
meanings

(puthash (intern "One file") "~/tmp/new.org" my-files-hash)
(puthash (intern "Something else") "~/tmp/else.org" my-files-hash)
;; You could continue feeding various files while only making sure
;; that they description differ from each other

;; Take it back from hash to verify
(gethash (intern "Something else") my-files-hash)
"~/tmp/else.org"

;; Construct list of semantic meanings of those files
(hash-table-keys my-files-hash)
=> (One\ file Something\ else)

(defun my-capture ()
  (interactive)
  (let* ((my-files (hash-table-keys my-files-hash))
 (my-files (mapcar #'symbol-name my-files))
 (my-selection (completing-read "File to capture: " my-files))
 (my-selected-file (gethash (intern my-selection) my-files-hash)))
(when selected-file
  (find-file selected-file)
  (goto-char (point-max))
  (insert "\n")
  (insert ** 



I have to take some time to chew into this.


Jean



All due respect, particularly for such an effort, however I think Jean
Louis' solution is far too complex, especially for someone not well
versed in Elisp.  Which I am still assuming, as Pietru have not
explicitly stated so (or not) yet.

My path of questioning was trying to draw out relevent info, with the
end goal of suggesting the right solution.  If that solution is a simple
completing-read then so be it but I am not even sure we have determined
that is the correct (or preferred) solution yet.

In particular, hash tables are not needed with the sorts of numbers of
candidates I think we are talking about here.

Cheers,
TRS-80



Re: Org Capture Menu cannot be fully viewed

2020-12-12 Thread TRS-80

On 2020-12-12 22:49, pie...@caramail.com wrote:

TRS-80 wrote:


Are there any more to these templates you did not show?

Because, (and unless I am missing something) what I see are 
essentially

all the same (and quite simple).  You would end up with something like
the following in your target file (with the cursor ending up at the 
x):


It was an example for long agenda option.  Wanted to send a basic one
without the details that could bother you.  The real one will have
information regarding Site_Type [Domestic, Funerary, Water-Related,
Settlement].  But we don't have the things in org though.


It's no bother.  In fact I am already thinking ahead as to the structure
of the data, which is the most important consideration.  Choice of
tool(s) should flow from that, and also from the desired workflow,
instead of the other way around.

Just so you know, you /could/ have the things in Org, if you wanted to
(or even in a separate plain text file, and use that as input for your
narrowing selection list).  Maybe they change, or there are other
reasons, but you could have the options in a list to choose from.  This
sort of thing reduce typos and errors.  You could limit to such list
strictly, or not (the latter allowing flexibility to add things on the
fly).


If all my assumptions above are true, I think you would probably be
better served with a simple completing-read (or similar) function to
select the "Investigation Type" from a list and then simply insert 
that
along with a timestamp.  Which it will take you longer to reply to 
this

email and confirm than it would take me to write such a function.  :)


Yes, I know about " %^{Investigation Type: |Site
Stabilization|Heritage Management|Environment Research} %?\n"


I am beginning to suspect you have bigger data and more options than fit
comfortably into a capture template.  I could be wrong, but in my mind
at least, the idea of capture templates is to quickly store small ideas,
notes, TODOs, etc. so you can go back to what you were working on in the
first place, with minimal interruption to your original train of
thought.

Data can then be parsed into database once we get tho data files at 
home

base.


True, however well designed "capture" mechanism (in reality, data
structure) will make this job much easier.

What sort of thing better than template capture?  My basic idea was to 
see
what org tools are available, see what kind of problems me get to, 
without

asking too much things specific to us.  We can then work through things
ourselves.  Perhaps share them with some other organisations.


As I mentioned in last mail, I think Org Properties might be more what
you might be looking for.  You may or may not even need any custom Elisp
in addition to that.


[1] https://orgmode.org/manual/Properties-and-Columns.html


Try and just play around with that, create some heading and do
org-set-property and then enter a key and value.  If you want to set a
list to choose from, you put at top of file something like:

#+PROPERTY: Investigation_Type_ALL Site_Stabilize Heritage_Management
#+PROPERTY: District_ALL 1 2 3
#+PROPERTY: Site_Type_ALL Domestic Funerary Water-Related Settlement
[...]

You may need to press C-c C-c within the above to re-load and make it
live.

If you like something like that, it's easy to copy blank template and
just open new one for each survey or whatever you are doing and go from
there.  And then here is where Emacs and Orgmode really shine, as they
are unparalleled as note taking tools.  You can include pictures,
tables, etc. headlines and lists, etc.  But you probably know all that
already.

Cheers,
TRS-80



Re: Emacs inserts hardwired org-agenda-files variable, overwriting user options

2020-12-12 Thread TRS-80

On 2020-12-11 21:35, Jean Louis wrote:


By the way I have completely switched all action management to my
database system with tabulated list mode. No more using Org for action
management, only for document, not even short notes.



It sounds like you have well moved on to another solution by now,
however I did want to point out what I thought was one small factual
inaccuracy.



Org mode have imposed reverse on users where for example a list of
items is only then completed as DONE when subordinate tasks have been
completed as DONE



Unless I am badly mistaken, I think this is only true when
org-enforce-todo-dependencies is non-nil?

Cheers,
TRS-80



Re: Org Capture Menu cannot be fully viewed

2020-12-12 Thread TRS-80

On 2020-12-12 21:08, pie...@caramail.com wrote:

Here is one version of a template

(setq capture-template-investigation-type '(

 ("a" "Historic Background Research Site Evaluation/Testing" entry
  (file "~/histr/archaeol.org")
  "* Site_Type: %?\n %T\n")

[...]

 ("u" "Remote Sensing" entry
  (file "~/histr/archaeol.org")
  "* Site_Type: %?\n %T\n") ))



Are there any more to these templates you did not show?

Because, (and unless I am missing something) what I see are essentially
all the same (and quite simple).  You would end up with something like
the following in your target file (with the cursor ending up at the x):

#+begin_example

* Site_Type: x
[2020-12-12 Sat 21:58]

#+end_example

In fact I don't even see where the type name ends up in the result?

If all my assumptions above are true, I think you would probably be
better served with a simple completing-read (or similar) function to
select the "Investigation Type" from a list and then simply insert that
along with a timestamp.  Which it will take you longer to reply to this
email and confirm than it would take me to write such a function.  :)

Benefit of that way also removes possibility of typos in the type name.

In fact, the above could even be done with something as simple as
Yankpad[0].

I have no idea what your workflow looks like, or where this data ends
up.  However, thinking further, I would imagine it might even be helpful
to set one or more Org properties[1] for things like "Investigation
Type" (along with some other things I could speculate like "Location"
etc.).  But all of that depends on even more things I don't know about.

If you care to share a slightly bigger picture view, particularly about
the structure of the data you are trying to capture (and/or, your
workflow) we could likely come up with something that would work much
better for you than a capture template, at least in this particular
case.

Cheers,
TRS-80

[0] https://github.com/Kungsgeten/yankpad
[1] https://orgmode.org/manual/Properties-and-Columns.html



Re: Better heading links in org-mode exports

2020-12-12 Thread TRS-80

On 2020-12-12 15:29, Jussi Norlund wrote:

Hi,
I would like to propose improving the naming of anchor heading links
in primarily HTML and Markdown exports in org-mode.

Here's an example of an implementation of a better naming setup:
http://ivanmalison.github.io/dotfiles/#usemyowndefaultnamingschemefororgheadings

Best regards


Hi Jussi,

This is actually being discussed already at some length in another
thread titled "stability of toc links" which was last posted to as
recently as today.  I don't know if this should be re-posted over there
or not?  At any rate, I expect you will be interested in that
conversation, as well.

Cheers,
TRS-80



Re: Org Capture Menu cannot be fully viewed

2020-12-12 Thread TRS-80

On 2020-12-12 18:30, pie...@caramail.com wrote:

From: "TRS-80" 

Well, it's up to you.  If you want we can pursue either option, or 
both

(one potentially as a temporary workaround).  Or we can wait for more
list replies and see what others think.  As I said there may also be a
better way I am not aware of.  If I'm being honest, I have plenty 
other
things to work on, too.  ;)  But since I open my big mouth now, I 
can't

very well leave you hanging, now can I?  :D  It also depends on how
complicated stuff we are talking...


Very good of you.  If you let me give a basic long template (perhaps
"Investigation Site").  I can do both, get a fix, and work for an
Emacs incorporation .


Actually, another option just occurred to me.  I don't know where you
are sending results of the capture template, but if you are just
appending to file(s) perhaps you could break the one big template up
into some number of smaller ones?


One problem with that is that new entries are appended in vertical 
(newline)

and cannot put options in a table.


How about post up your long template somewhere and we can have a look?
Maybe a paste site is better than the mailing list?  If you want to do
that and are not aware of any good (non proprietary) one, I like and use
a lot https://bpaste.net/ (which redirects now to https://bpa.st/,
apparently).

Maybe while I am at it I have a play about what might be required to get
some scrolling to work with the template.  For all I know, it could be a
simple fix...

Others please feel free to jump in, too, maybe you know something I
don't (about scrolling, I mean).

Cheers,
TRS-80



Re: Org Capture Menu cannot be fully viewed

2020-12-12 Thread TRS-80

On 2020-12-12 17:46, pie...@caramail.com wrote:

From: "TRS-80" 


The problem also exists when making capture templates.  The solution
could be additional functionality coded in elisp that can then be used
for handling longer template entries.  As the problem is dependent on
screen size, the problem is likely to occur, requiring the patch.  It
then becomes natural that the fix is introduced without the template
developer having to call the fix explicitely.


All true!

I assume it would involve some elisp and would be willing to word 
towards

a solution.  But it would be even better that the solution would be
incorporated in the official version of emacs.


What gets into Org / Emacs is up to maintainer(s?) and pending list
discussion.  Which might take some time, but in many cases (I imagine
even including this one) is probably The Right Thing to do.

If you can wait for that, it will end up improving Org and likely
helping a lot of people, including yourself (eventually).

I guess some times I just prefer my own local "quick and dirty" solution
which can be "good enough" or a workaround pending a more proper
solution.  Although, to be fair, the ability to maintain such solutions
(long term) is sort of dependent on knowing a bit of Elisp.  So it's a
bit of a trade-off.

I can send a long capture template.  And any additional information 
people

require.


Well, it's up to you.  If you want we can pursue either option, or both
(one potentially as a temporary workaround).  Or we can wait for more
list replies and see what others think.  As I said there may also be a
better way I am not aware of.  If I'm being honest, I have plenty other
things to work on, too.  ;)  But since I open my big mouth now, I can't
very well leave you hanging, now can I?  :D  It also depends on how
complicated stuff we are talking...

Actually, another option just occurred to me.  I don't know where you
are sending results of the capture template, but if you are just
appending to file(s) perhaps you could break the one big template up
into some number of smaller ones?

Cheers,
TRS-80



Re: stability of toc links

2020-12-12 Thread TRS-80

On 2020-12-12 16:51, TRS-80 wrote:

  "If we are not in MAJOR-MODE, exit with error."


I noticed a small typo:

-  "If we are not in MAJOR-MODE, exit with error."
+  "If we are not in major MODE, exit with error."

Cheers,
TRS-80



Re: Org Capture Menu cannot be fully viewed

2020-12-12 Thread TRS-80

On 2020-12-12 13:02, pie...@caramail.com wrote:

Dear All,

When making a relatively long Org Capture Menu for Archaeological
Field Management, the relevant capture window cannot be scrolled down.
This becomes particularly problematic with small field laptops.


Hi Pietru,

Capture templates are great, but I suppose there are a lot of advantages
to doing some custom Elisp which is why I do a lot more stuff that way
now that I have learned a little bit of Elisp.

Sorry, I guess that's not helpful if you are not comfortable with Elisp.
As an aside and thinking long term, I can say the investment was well
worth the payoff.  However back to the issue at hand.

Maybe if you are willing (or able) to share some more information, we
could help you through some basics.  Or maybe someone else might even
have some better idea (not involving Elisp) which might be more
appealing to you.

Cheers,
TRS-80



Re: stability of toc links

2020-12-12 Thread TRS-80

On 2020-12-08 20:39, Tom Gillespie wrote:

It sounds like you are looking for the CUSTOM_ID property. See
https://orgmode.org/manual/Handling-Links.html and
https://orgmode.org/manual/Internal-Links.html. I don't remember
whether there is a way to generate ids matching headlines within org
itself, but there is
https://github.com/alphapapa/unpackaged.el#export-to-html-with-useful-anchors.
Best!
Tom


I had set out to shave this particular yak just yesterday I think it
was.  I know I came across alphapapa's solution and maybe TEC's too, but
they were more complex than I could seem to get my feeble brain around
at the time.

Also, I was going for more of a deterministic result, trying to end up
with something like a Markdown style link id.  This coming up in the
course of my larger mission towards better support for exporting
README.org to Markdown (and ultimately, nicely rendered HTML) files over
at Sourcehut[0].

Finally, this operates by a totally different way than replacing some
part of Org export function(s).  My approach was simply to dynamically
assign a CUSTOM_ID property to every heading in current buffer (that did
not have one already) which would be generated according to some
deterministic method.  With the idea to then go on after that and do
whatever regular Org export you want.

Right off the bat I will say this is a very, VERY immature
implementation (literally yesterday).  And I have only done the very
lightest of testing (however it does basically work).  Therefore this is
not for consideration for inclusion into Orgmode but rather just my own
workaround in the meantime.  At best I might hope to add something
useful to the ongoing discussion (or perhaps become enlightened why this
is completely wrong approach).  ;)

I would like to point out the following problems which I have not (yet)
addressed in the following functions (#1 being most glaring probably) as
they are still too new:

1. The punctuation removal regexp needs to have many more characters
added (currently only containing {!.'}).  In fact, this strikes me as a
bit hacky, I am not even sure it's the best approach.

2. This function operates only on the current buffer.

3. Many things still need to be parameterized, in particular the TODO
state is hard coded to be included in the generated id and already I am
starting to think that's a bad idea (but it depends on context I
suppose, hence thinking to make it an option).

4. If I am trying to emulate Markdown (or any other spec) I really
should study and more properly and fully implement said spec.  I have
done /absolutely no such thing/ so far, only a (quite off the cuff)
"Markdown like" implementation.

5. Naming the function beginning with `my-ox-' is not meant that this
should be included in ox- package necessarily but rather that I am
associating it with exporting from Org within my own mind and personal
init files.

My plan (before stumbling across this thread ;) ) was to continue to use
and polish these functions (privately) and eventually publish them on my
(relatively new) sr.ht profile[1].  But since this came up, I guess I
will go ahead and put it out there for feedback here on the mailing
list.  I still plan to eventually publish somewhere more properly with
license, where patches can be accepted, etc...  However in the
meantime...

With the above disclaimers out of the way, I present the following
function (and another simple one it depends on) in the hope they are
useful to someone.

[0] https://sourcehut.org
[1] https://sr.ht/~trs-80/

#+begin_src emacs-lisp

(defun my-major-mode-insure (mode)
  "If we are not in MAJOR-MODE, exit with error."
  (unless (string= major-mode mode)
(user-error "Buffer not in %s, exiting" mode)))

(defun my-ox-assign-custom-ids ()
  "Assign reliable CUSTOM_ID to each heading in current buffer.

CUSTOM_ID will only be assigned if one does not exist already.

The generated CUSTOM_ID roughly[0] follows (my very basic and
limited understanding of) the Markdown spec.  In other words, it
will be generated by taking the heading text plus TODO state (so
as not to break link) and:

1. Lower case it.
2. Remove all punctuation.[1]
3. Replace spaces with hyphens.

[0] Currently, likely VERY roughly...

[1] Currently this is a bit hacky `replace-regexp-in-string'
featuring only a few common punctuation (right now only
exclamation point, period, apostrophe (i.e., single quote).  Much
more will need to be added here, in fact I am not even sure this
is the best approach."
  (interactive)
  (my-major-mode-insure 'org-mode)
  (org-map-entries '(org-set-property
 "CUSTOM_ID"
 ;; replace space with hyphen
 (replace-regexp-in-string
  " " "-"
  ;; remove punctuation
  (replace-regexp-in-string
   "\\\!\\|\\\.\\|'" &quo

Re: Using org-agenda-time-grid with lists

2020-12-11 Thread TRS-80

On 2020-12-11 13:18, Christopher Dimech wrote:


Perhaps you might get some ideas from
https://github.com/oantolin/icomplete-vertical


Oohh, Chris reply make me think different about this.

My original reply was about simply printing an Elisp list (data type) to
the *Messages* buffer.

If it's about (vertical or other) narrowing completion based on lists in
the /minibuffer/ (which could also be referred to as "message" area)
then that's something else altogether...

In that department, I have been using Ivy very happily for a few years
now.

I think maybe we need some clarification from OP which he was referring
to?  Or what exactly trying to accomplish?

Cheers,
TRS-80



Re: Using org-agenda-time-grid with lists

2020-12-11 Thread TRS-80

On 2020-12-11 11:48, steve-humphr...@gmx.com wrote:

TRS-80 wrote:

On 2020-12-11 10:45, steve-humphr...@gmx.com wrote:
>
> Incidentally, how can one print a list in messages buffer?

Do you mean something other than standard:


Correct, something other than "%s".



```
(message "%s" my-list)
```
I wrote some quite involved function to take a list of variables and
print them to Messages buffer, formatting them nicely.  I use it when
debugging and writing code.  However I am not sure that is what you 
are

looking for or not?


What is the biggest problem with printing lists that you have 
encountered?


I don't have any problem printing simple list.  Well, maybe one case.
If the list is too long (because you only get some part of it in
Messages buffer).  In that case, I do my function in fundamental-mode
with C-j (I think?)  which put the results in the same buffer.  Then you
can do  (or maybe it's ?) and that will expand to the full
result, if you need to look at that.

But the reason I wrote my function was because I wanted to provide short
list of (separate) variables and have them print out to nicely formatted
message as intermediate structure code and/or for debugging purposes.
Which is nothing to do with lists, per say.


Cheers always sounds better on a friday. :)


You make me thirsty all of a sudden!  :)

Cheers,
TRS-80



Re: Using org-agenda-time-grid with lists

2020-12-11 Thread TRS-80

On 2020-12-11 10:45, steve-humphr...@gmx.com wrote:


Incidentally, how can one print a list in messages buffer?


Do you mean something other than standard:

```
(message "%s" my-list)
```

I wrote some quite involved function to take a list of variables and
print them to Messages buffer, formatting them nicely.  I use it when
debugging and writing code.  However I am not sure that is what you are
looking for or not?

Cheers,
TRS-80



Re: from dired to an org file with list of files with links

2020-12-11 Thread TRS-80

On 2020-12-11 03:09, Uwe Brauer wrote:

Dear Uwe,
* Uwe Brauer  [2020-12-10 22:45]:



(require 'dired-x)



(defun dired-to-org-links ()
  "Generates Org links for Dired files and stores in memory. Yank
it in other buffer"
  (interactive)
  (let* ((files (dired-get-marked-files)))
(when files
  (kill-new
   (with-temp-buffer
 (dolist (file files)
   (let* ((base (file-name-nondirectory file))
  (link (format "[[file:%s][%s]]\n" file base)))
 (insert link)))
 (buffer-string))


Thanks, that is very nice.
I played a bit around with org-fstree, that is also useful.


Indeed, nice function!

And what great and fast service!  :)

If I may be permitted to pick a nit; Uwe, you may want to prefix the
function with `my-` or `uwe-` or your initials, etc. for namespace
reasons.  Unless of course this is something Jean Louis is planning on
submitting as a patch to dired itself... ;)

Cheers,
TRS-80



Re: Exporting .org to .md for Sourcehut (sr.ht); ox-md not following Markdown spec?

2020-12-11 Thread TRS-80

An update!

I am very pleased to announce, that my campaign took me only a little
less than 2 weeks to achieve success!  :)

And so, from now on, not only myself but /everyone/ who prefer writing
in .org instead of .md now have a clear path to nice looking rendered
HTML which is on par with the default .md at Sourcehut![0]

This was the only real gripe I had with that platform, as I generally
love what Drew is trying to do over there and I really wanted to
continue my support and participation.  And now I can!

The main issue was that in-page links, generated by exporting .org ->
.md, and then getting processed by Sourcehut's HTML renderer were
getting broken in the process.  However now they are working, as can now
be seen for example at README of one of my projects:

https://sr.ht/~trs-80/rofi-in-elisp/

Please feel free to go there and click in-page links!  In fact I cannot
remember the last time I got so much enjoyment from something so simple
as clicking on a working in-page link!  :D

Just to re-cap, I had taken a 2 pronged approach.  First was on sr.ht
mailing list[1] about trying to fix the id sanitation in anchor links.
After some discussion and a couple patches, this approach is now live
and working.

However, simultaneously, I had also been pursuing a Pandoc based
solution (which, amazingly, was /also/ broken, but for a different
reason).  This second approach has now also bourne fruit in the form of
a patch and a workaround, and eventually should also become fully
supported.[2]

I include both here for the benefit of anyone who comes searching along
later.

Special thanks to Tim Cross for helping me get the exact issue nailed
down in my head so I could go forth onto other mailing lists and fora
and explain the issue with clarity.

It really feels great to make some small contribution back to the larger
Orgmode ecosystem which has given me so much.

Cheers,
TRS-80

[0] https://sourcehut.org
[1] 
https://lists.sr.ht/~sircmpwn/sr.ht-discuss/%3Cfe7aa296-9c90-463d-b4e6-50eeb7e57428%40localhost%3E

[2] https://github.com/jgm/pandoc/issues/6916



Re: Emacs inserts hardwired org-agenda-files variable, overwriting user options

2020-12-10 Thread TRS-80

On 2020-11-29 17:08, daniela-s...@gmx.it wrote:


Yes, there are problems with the documentation.  I noticed recently 
that
some guy criticised the manual, and so many got super defensive.  You 
should

give him a medal for telling you how things are.


I guess in my mind, complaining about the manual, to a bunch of
volunteers and fellow users, is probably on the pretty unhelpful end of
the scale.

Making constructive criticism is then slightly better, at least you are
not deriding (mostly volunteer) people's work and effort.  Although not
by much, as this still does not require too much effort.

However submitting a patch with an improvement to the documentation is
quite valuable.  Pretty much on the opposite end of the scale in fact.
And thus, only this level of contribution "deserves a medal" as far as I
am concerned.

I was not privy to particulars of conversation you mention, although I
have seen this sort of entitled attitude often enough in F/LOSS to have
somewhat of an idea of how it might have played out.

Entitled users becoming demanding of things they expect (for free, no
less) is not just a drag, it's the cancer that slowly kills F/LOSS
projects.  As eventually actually valuable contributors (maintainers,
devs, etc.) have had enough of it, get burnt out and leave the project.
I have seen it far too many times over the years.

So I imagine what you witnessed was a sort of natural defense mechanism,
protecting the overall health of the community and project by having a
strong reaction to such negative attitudes.

Cheers,
TRS-80



Re: generate an org file for today's appointments

2020-12-03 Thread TRS-80

On 2020-12-03 06:01, Mikhail Skorzhisnkii wrote:

Alan Schmitt  writes:

I have my calendars converted to org files (using ical2orgpy), and as 
I

include them as agenda files, I have this nice view in org-agenda:

   9:10.. now - - - - - - - - - - - - - - - - -
  AlanWork:   10:00-12:00 Event A -
  Chris:  10:00-11:00 Event B -
  10:00.. 
  12:00.. 
  AlanWork:   14:00-15:30 Event C -
  14:00.. 
  16:00.. 
  18:00.. 
  Alan:   20:00-21:30 Event D -

Is there a way to piggy-back on all the work that org-agenda already 
did

to generate something like:

** 10:00 Event A
** 10:00 Event B
** 14:00 Event C
** 20:00 Event D

This would then be inserted in my daily journal file.

I guess the alternative is using org-element to extract the 
information
from the calendars in org format, but it seems to me org-agenda 
already

did all the hard work.



I'd suggest to use function "org-agenda-write". You can export your
agenda views to org files too! However, the formatting will be
different. Probably something like:

* Event A
 SCHEDULED: <2020-12-03 Thu 10:00-12:00>
* Event B
 SCHEDULED: <2020-12-03 Thu 10:00-11:00>
* Event C
 SCHEDULED: <2020-12-03 Thu 14:00-15:30>
* Event D
 SCHEDULED: <2020-12-03 Thu 20:00-21:30>

I personally do this to generate separate org-file and then generate
ics file based on that and upload this ics file through WebDAV to my
calendar server.


@Alan,

I don't know if there is a way directly in Org to do what you want or
not, but for some reason my brain goes toward copying the text (either
directly from your agenda, or from Mikhail solution) into some other
buffer and then doing some macro or ELisp based post-processing.  But
I really don't know if that's the Right Thing to do or not.

I am also not someone who uses one of these "daily journal" workflows,
so I can't help but wonder how you link these daily notes back to the
underlying project that generated the event on the agenda in the first
place.  Becasue in my mind, I would jump from the agenda to the
underlying project or task and be making my notes in there directly.
Those linking considerations, in my mind anyway, would really dictate
the rest of the workflow.

Cheers,
TRS-80



Re: Exporting .org to .md for Sourcehut (sr.ht); ox-md not following Markdown spec?

2020-12-02 Thread TRS-80

On 2020-12-02 16:59, Tim Cross wrote:

TRS-80  writes:

I think the problem is actually because Sourcehut are sanitizing the 
id

attribute out of links, as I have replied already to some other people
in this thread.


From what I can tell, yes your right. However, it also seems that this
is an arbitrary decision by sourcehut. There doesn't seem to be 
anything

in the CommonMark spec which prevents the id attribute. The commonMark
spec explicitly supports raw HTML including attributes. This also makes
me think the problem is not with the org mode exporter either.


You know, as much as my last email may have sounded otherwise, I am now
also thinking this way.

Whitelisting the id attribute should (in theory) be the least amount of
work.  I have replied back on the thread at Sourcehut asking if there is
some (security or other) reason they are blocking it.  Hopefully that
approach bears fruit.


I note that in the email thread you referenced, the last post suggests
setting up a custom readme format which would allow you to use HTML.
Maybe that is the easiest route to take - org -> html with custom
readme?


Unfortunately, the Org HTML exporter (which is in fact the parent that
the Markdown exporter was derived from) also makes extensive use of the
id attribute and anchor links.  So I am afraid those would be sanitized
out exactly the same.

Cheers,
TRS-80



Re: Exporting .org to .md for Sourcehut (sr.ht); ox-md not following Markdown spec?

2020-12-02 Thread TRS-80

On 2020-12-02 14:56, TRS-80 wrote:

On 2020-12-02 14:12, Jean Louis wrote:
Try using pandoc Org to Markdown as that could help until Org
exporting start working how it should.


Great minds must think alike!  :)  I tried that already but in-page 
links

which look like:

```
[[*Setup][Setup]]
```

Somehow get exported to:

```
*Setup*
```

...which is not a link at all, but rather just italicised text.

In fact, I think I will go now and bring that up to pandoc project...


FWIW, I did go and post to their mailing list:

https://groups.google.com/g/pandoc-discuss/c/D-8J4RGiYsk/m/g45AutiNAAAJ

Cheers,
TRS-80



Re: Exporting .org to .md for Sourcehut (sr.ht); ox-md not following Markdown spec?

2020-12-02 Thread TRS-80

On 2020-12-02 14:44, Tim Cross wrote:

I could be completely wrong here, but I suspect this is a combination
of the evolving markdown spec (or more specifically, no one standard
spec) and the age of the org mode markdown exporter.


FWIW, it sort of feels that way to me, too.


One of the challenges with markdown is that there has never been one
universally accepted spec.


Yes, I am aware of the history.  And this is one of my main criticisms
of Markdown, and why I prefer Orgmode (by a wide margin).  In fact I
agree (strongly) with Karl Voit's article "Org-Mode Is One of the Most
Reasonable Markup Languages to Use for Text."[0]


It might be worth looking in the archive. I seem to recall other
discussions along these lines some months back. My flawed memory seems
to recall that it was probably time for org's markdown exporter to be
updated to fit with the more 'common' markdown standard, but I don't
recall which that was or whether anyone decided to take that
responsibility on.


Thanks, I'll have a look.  I was also sort of getting the sense that
updating the Markdown exporter might be the answer, hence me starting
this thread.


Org already has two markdown flavors - 'generic' markdown and github
flavoured markdown. Org's current markdown is based on
http://daringfireball.net/projects/markdown, which probably varies
enough from the one used by sourcehut to cause the problems you are
seeing.


I think the problem is actually because Sourcehut are sanitizing the id
attribute out of links, as I have replied already to some other people
in this thread.


Unfortunately, this fails to provide a clear path to fix your problem.


Yeah, this is like (at least) my second day into this now.  :)  Which is
why I paused to seek more counsel on the best way forward.  As there
seem to be no good/clear (or at least, easy) answers.

Thanks for the input.

Cheers,
TRS-80

[0] https://karl-voit.at/2017/09/23/orgmode-as-markup-only/



Re: Exporting .org to .md for Sourcehut (sr.ht); ox-md not following Markdown spec?

2020-12-02 Thread TRS-80

On Wed, Dec 2, 2020 at 7:54 PM TRS-80 
wrote:

Some further digging revealed that the ox-md exporter (which itself
is derived from the HTML exporter(?) makes extensive use of the id
attribute in links.  And Sourcehut's HTML sanitizer only allows href
and title attributes (not id).[1]

[1] https://man.sr.ht/markdown/#post-processing



On 2020-12-02 14:45, Diego Zamboni wrote:

(note: Markdown allows embedded HTML, so ox-md's behavior is not
incorrect)


Right.  However, unless I am missing something, they (Sourcehut) are
passing the HTML through, but their sanitizer is only allowing a subset
of attributes.  Look closely (on the sr.ht Markdown page we both have
now linked) at what attributes are allowed for links:

a: href, title

Only href and title.  No id!


Note that according to https://man.sr.ht/markdown/#post-processing,
Sourcehut uses CommonMark, not plain Markdown, so I guess that's why
it doesn't allow all HTML tags.


Yes, I am aware they use CommonMark.

However it seems to me that CommonMark is just a less ambiguously
defined version of Markdown, designed to address those particular
criticisms of the original.

I don't know if there is anything in CommonMark spec itself that forbids
passing HTML through, and I did not bother to look that up (and thus I
could be wrong) however I think the problem is rather what I already
said above about id attributes being blocked, by Sourcehut particular
HTML sanitizer.


There seems to be no ox-commonmark (that I could find) but pandoc does
support it, so you could probably use ox-pandoc
(https://github.com/kawabata/ox-pandoc) to export your documents in
CommonMark format.


I did try using command line pandoc, and ran into some problems (which I
outlined already in separate reply to Jean Louis), but maybe I give this
a try, too.  Thanks.

Cheers,
TRS-80



Re: Exporting .org to .md for Sourcehut (sr.ht); ox-md not following Markdown spec?

2020-12-02 Thread TRS-80

On 2020-12-02 14:12, Jean Louis wrote:

Try using pandoc Org to Markdown as that could help until Org
exporting start working how it should.


Great minds must think alike!  :)  I tried that already but in-page 
links

which look like:

```
[[*Setup][Setup]]
```

Somehow get exported to:

```
*Setup*
```

...which is not a link at all, but rather just italicised text.

In fact, I think I will go now and bring that up to pandoc project...

They have several different flavored Markdown exporters available, I
tried all of them in fact.

FWIW, I also tried going the route of exporting to HTML (which is also
supported at Sourcehut)[0] however I ran into lots of other similar
issues like in OP, as the HTML exporter does the same things with id in
links.

I actually worked on this all day yesterday, still without success.  I
am of course still open to any suggestions, but I came to conclusion so
far that fixing the ox-md exporter might be the Right Way and I was
willing to dig into that further, myself.

I work extensively in Orgmode and have plans to publish many more things
(likely on Sourcehut) and I would rather do whatever work is required to
fix ox-md than change all my existing (or new) work to Markdown.  I
really do hate Markdown that much.  :D

Also, maybe in the meantime I could simply hard code a ToC, but that
still will not fix other in-page links throughout the page (like the
*Setup example, above).

Cheers,
TRS-80

[0] https://man.sr.ht/git.sr.ht/#setting-a-custom-readme



Exporting .org to .md for Sourcehut (sr.ht); ox-md not following Markdown spec?

2020-12-02 Thread TRS-80

Hallo,

I became quite interested in what Drew Devault was doing with his
Sourcehut project, so I decided to join.  I was really enjoying
everything except for the fact that .org files are not supported insofar
as automatic rendering into nice looking HTML in the same way that
Markdown files are for the README at the root of the project.  And the
official word is that only Markdown is to be supported.[0]

So I start digging into this, my first try was to use
org-md-export-to-markdown function to generate the supported Markdown.
However, doing it that way broke all inter-page links (to headings,
footnotes, etc.).

Some further digging revealed that the ox-md exporter (which itself is
derived from the HTML exporter(?) makes extensive use of the id
attribute in links.  And Sourcehut's HTML sanitizer only allows href and
title attributes (not id).[1]

For example, here are the sort of links that the ox-md exporter create:

ToC:

```
1.  [rofi-in-elisp](#orgdbf2274)
```

Body:

```


# rofi-in-elisp
```

Above was copied straight from Eli Schwartz reply to me in my post to
Sourcehut mailing list about this[0] (although I had already noticed the
same thing as well).

I tend to agree with him that this is not following the Markdown spec,
where links should instead become simply:

ToC:

```
1.  [rofi-in-elisp](#rofi-in-elisp)
```

And if so, then the Right Thing to do would be to fix that in the ox-md
exporter?

However OTOH, I can't help but venture a guess that there must have been
some reason to do it that way in the first place.

So before I invest any more time going down this path, I thought I would
take a step back and seek some advice whether this is actually the
correct path or not?

Cheers,
TRS-80

[0] 
https://lists.sr.ht/~sircmpwn/sr.ht-discuss/%3Cfe7aa296-9c90-463d-b4e6-50eeb7e57428%40localhost%3E

[1] https://man.sr.ht/markdown/#post-processing



Re: best practices query: non-emacs packages based on tangled source

2020-10-27 Thread TRS-80

On 2020-10-15 14:11, Greg Minshall wrote:

if anyone has any techniques they've used, liked (or hated), i'd
love to hear.



I am someone who keeps my Emacs config in a literate style in blocks
within an Orgmode outline.  And I enjoy it!

However I somewhat recently came across a project that was developed
with a literate paradigm.  It was an immediate turn off for me.
Because now in addition to learning someone else's code, I have to
learn how their brain works, how they organized the file, etc.  It
just added another layer of complexity on top of something that is
already potentially complex (the code itself).

Maybe I was just immediately soured because I didn't like their
formatting (not leaving enough spaces where I would have, etc.) or how
they organized the project.  And I probably didn't give it a fair
shake if I'm being honest.  But I don't have a lot of time, and things
like that just create too much friction (IMO) when I was only slightly
motivated to make a contribution in the first place.

And remember what I said at first, I am someone who appreciates the
literate paradigm (at least for my own config).  Imagine how someone
who does not even know who Knuth is would feel about it.

Therefore, any stuff I plan on releasing publicly, I do not do in
literate style (JMHO).  However if you are dead set on doing literate
paradigm, then maybe my experience is invalid for your use-case.

Cheers,

TRS-80



Re: Limitations on Tags ?

2020-10-25 Thread TRS-80

On 2020-10-01 16:09, David Masterson wrote:
Just wondering -- what's the limit in the number of tags for a 
headline?

What if I have a headline with lots of tags or some very long tags?


These are some of reasons I started putting my tags into PROPERTIES.
Then I don't have to worry about crowding the title, too long or too
many tags, or any other issues as you have noticed.

In addition, I think it looks cleaner.  I hide them in a property
drawer.  They are still equally as searchable.

And finally, I can now have different /types/ of tags.  In my case, I
use two properties: TAGS_TOPIC and a TAGS_META.  The former for
general topics (i.e., computers, software, GNU/Linux, organization,
etc.), and the latter for things like BlogFodder, ReadingList,
NeedsCleanup, VideosToWatch, etc. which allows for a nice orthagonal
way to classify certain things.

TRS-80



Either zero or two newlines with org-agenda-block-separator, cannot seem to get one?

2020-10-25 Thread TRS-80

Hallo,

I tried to change the value of org-agenda-block-separator variable to
many things (including characters and strings, in accordance with the
documentation) however I could not seem to achieve the desired result.

I was trying to make one blank line between agenda blocks in my custom
agenda (defined via org-agenda-custom-commands).  However I could only
seem to either make two, or zero!  :/

Searching for org-agenda-block-separator in org-agenda.el led me to
org-agenda-prepare function, where it appears to me that there is no
way to accomplish what I want, at least by simply changing a variable.

Therefore I ended up commenting out one of the newlines in that
function here in my local source, and re-loaded the file.  And now I
have one blank line between my agenda blocks, just as desired.  :)

But I thought this would be a good idea to bring to the attention of
the mailing list.

Cheers!

TRS-80



Re: Any reason not to generate my own custom ID value (NOT CUSTOM_ID)?

2020-09-10 Thread TRS-80

On 2020-09-10 21:06, Ihor Radchenko wrote:

I do appreciate all the replies so far.  However as I plan on relying
on this to implement some quite critical functionality for a package I
am working on (a sort of Zettelkasten / TiddlyWiki in Orgmode if you
will) I would feel a lot more comfortable with some additional
reassurences that what I am planning is not some crazy or bad idea.


Is there any particular reason why you even need to display :ID: value 
to

the user? If only id: links are concerned, link description can be made
short and human-readable.

Best,
Ihor


Yes, most of the time I expect I will be using Orgmode double bracket 
style

links which will, as you say, hide the id: from the user, allowing to
replace it with whatever desired text in the form of the link 
description.


However, I just (strongly) prefer the shorter "ISO-like" ID for many
reasons, as already mentioned (shorter, meaningful, etc.).  I just find
that style much, much more elegant.

Besides, as an ID, they are plenty "Unique" for my use case, with the
default minute resolution (however even that, is configurable in my
implementation, by way of a time-format variable, should anyone need 
more).


I suppose if we ever get to a world where people start linking to each
others' individual publicly published zettel, I may regret the decision.
However Ted Nelson has already been working on such a thing for some
decades already, and we are still not there yet, so I don't think I will
need to worry about that any time soon.  ;)  Even if so, it would be a 
very

small implementation change anyway.

Cheers,
TRS-80



Re: Any reason not to generate my own custom ID value (NOT CUSTOM_ID)?

2020-09-10 Thread TRS-80

On 2020-09-10 18:20, Samuel Wales wrote:

this or something similar has definitely been discussed on this
mailing list.  so you are not alone.


Yes, I also thought certainly this must have been discussed before.  I
did try searching the list, but I think the relevant search terms are
too common, short ("ID", etc.) and/or too close to unrelated things
(i.e. CUSTOM_ID when I am looking for "custom ID", etc.) to produce
any good results.  Or maybe my search-fu is just bad.


although i undersatnd the whole thing as readable id's.  dunno if that
is the prupose.


Essentially, yes, more readable.  But also shorter, and perhaps most
importantly, /meaningful/.


maybe something like a timestamp and then the usual id would give you
pretty good uniqueness.


The uniqueness I outlined in OP (down to minute) is plenty enough for
my use-case.  The /last/ thing I want to do is to go the other way, and
make the ID even longer!

I do appreciate all the replies so far.  However as I plan on relying
on this to implement some quite critical functionality for a package I
am working on (a sort of Zettelkasten / TiddlyWiki in Orgmode if you
will) I would feel a lot more comfortable with some additional
reassurences that what I am planning is not some crazy or bad idea.

Thanks,
TRS-80



Re: Any reason not to generate my own custom ID value (NOT CUSTOM_ID)?

2020-09-10 Thread TRS-80

On 2020-09-10 18:00, Gustav Wikström wrote:

Hi TRS-80,

 Your approach should work just fine. So fine, in fact, that it's
already kind of built in! Configure org-id-method and set it to 'ts
and you'll get timestamps as ID instead of uuid.

 I do believe the manual lacks a description for this. Not entirely
sure though, and can't check atm. But the configuration is there none
the less, and supported.

 Kind regards

 Gustav


Hi Gustav,

Thanks for the fast reply.

I am aware of the 'ts' option to org-id-method which does not seem to
be documented in manual, only docstring of its defcustom in org-id.el.
I had left that detail out for the sake of brevity.  :)

My problem with that is that I do not like the format it outputs which
is "%Y%m%dT%H%M%S.%6N" (in other words, output which looks like
"20200910T180910.747026").  Only a little bit better than the "uuid"
option, IMHO!  :)

It would be great if that format-time-string was a configurable
variable, instead of hard coded, but alas it is not.  Well, since we
are now on that subject, perhaps I should ask is there some reason for
this?  Or would Bastien perhaps consider something like that?  :)))

Regards,
TRS-80



Re: Improving org-contacts performance (and state of development in general)

2020-09-10 Thread TRS-80

On 2020-09-06 22:52, Daryl Manning wrote:

PS> As an outside feature though, interoperability of the org-contact
formats with other operating system address books, most notable gnome
contacts/evolution, goog contacts, and OSX address book would be high
on my list in terms of improving org-contacts though. (eg, raw,
structued info in all address books, and say perhaps notes or similar
maintained and synced in ome manner.


Hi Daryl,

Good topic.

This is essentially the main reason I don't use org-contacts, even
though I have become a heavy Orgmode/Emacs user for almost everything
else over the past few years.

In my case, it's the Contacts on my Android phone, which seems to me
to be the primary place where I find myself adding/removing/editing my
contacts.  In my view, there /must/ be reliable and proper (/two-way/)
sync between the two.  Since that doesn't exist (that I am aware of)
my Android phone won out over org-contacts so far.

I haven't looked into it in a while, but at one point I thought that
using some common and open format would be the best idea.  Something
like CardDAV.

I actually had it working (syncing) with my NextCloud instance when I
had that up and running, but for me NextCloud proved to be to "heavy"
in general so I moved away from it, preferring instead lighter weight
tools to do the same things.  And so far I only implemented Syncthing
for the syncing part, and nothing for the CalDAV/CardDAV part (yet)
although I have had my eye on Radicale already for a while.

Maybe you know all this already, I'm just adding my $0.02.

Cheers,
TRS-80



Re: Support for simultaneous running clocks?

2020-09-10 Thread TRS-80

On 2020-09-04 13:14, Bastien wrote:

Hi Carlo,


Carlo Tambuatco  writes:

how long something takes to compile


I have set my shell prompt with a timestamp for exactly this reason.  I 
have also seen someone who set it to reflect elapsed time since last 
command, instead.


But I guess maybe you are referring to inside Emacs / Orgmode?  I'm just 
throwing out a possible alternative.


Cheers,

TRS-80



Any reason not to generate my own custom ID value (NOT CUSTOM_ID)?

2020-09-10 Thread TRS-80
First, I want to express my sincere and heart-felt gratitude to Carsten 
(and other contributors) for making and sharing this wonderful piece of 
software.  I have come to refer to it as "one of the gateway drugs to 
Emacs" (the other being Magit, IMHO).  It was certainly one of (if not 
/the/) main reason(s) why I started using Emacs initially.


I could in fact gush all day, however people are busy, so, on to the 
main issue...  :)


It seems to me that there is nothing really stopping me from inserting 
whatever value I like for value of "ID" Property.  Based on brief 
experimentation, org-store-link and org-insert-link seem to happily 
accept whatever value is already there (which I entered manually, for 
testing purposes).


However I seem to recall reading some warning somewhere about this, 
although I cannot seem to find it right now.


What I would like to do, is generate my own ID values in a more human 
readable format, something "ISO-like" for example "2020-09-10-1433" (as 
opposed to the default "uuid" method).  These sort of ID are still 
"Unique" (well, within my own system, anyway) as long as I am not 
generating them more often than once per minute[0].  And they have the 
advantages of being shorter, human readable, and meaningful.


Even when org-id-link-to-org-use-id and org-id-track-globally are both 
set to "t", org-id seems happy to insert my "ISO-like" ID right into the 
hash table and org-id-locations-file.


I do need the "across files" functionality.  My understanding is that 
this is main difference between ID and CUSTOM_ID (the latter being local 
only to the file).  Unless I am misunderstanding?


So, what am I missing here?  Any reason(s) /not/ to use my own custom ID 
value?


In addition to the general case, one particular area I am unsure about 
(as I have yet to get it working) is how this all works out with HTML 
export, as that is something I also wanted to get working at some point.


I tried studying some of the related sources (as well as mailing list 
archive), but could not seem to reach a conclusive answer.  I was hoping 
that some more knowledgeable people could confirm
whether this is a really bad idea, or not.  Any feedback would be 
greatly appreciated!


Cheers!

TRS-80

[0] It could easily be extended to second (or further) resolution, if 
needed.  For me, minute resolution will be fine.




Re: org-link-set-parameters :complete how to prompt for description?

2020-08-27 Thread TRS-80

On 2020-08-27 07:37, Ihor Radchenko wrote:


   Any tips would be greatly appreciated.


  Take a look at org-link-make-description-function

  Best,
  Ihor


Hi Ihor,

I am guessing you were referring to org-link-make-string?

I don't know how I missed that.  All I can say is I don't think
it is actually in the Docs anywhere.  Because I looked and
looked (as well as searching Internet)!

In either case, I truly am greatly appreciative, as promised.  :)
Thanks a lot, Ihor!

---

@All,

Apologies for any duplicates received, I seem to have some
trouble figuring out the correct thread and method to reply (even
though I don't usually have problem on other lists).

Assuming I didn't overlook it, perhaps this is an opportunity to
improve said Docs?

Cheers,
TRS-80



org-link-set-parameters :complete how to prompt for description?

2020-08-26 Thread TRS-80

Good day, everyone!

I have been trying to create a new custom link type with
org-link-set-parameters, which in turn calls functions for the various
"methods" (for lack of a better term), like so:

  (org-link-set-parameters "zdlink"
   :complete  #'my-zetteldeft-org-complete-link
   :follow#'my-zetteldeft-org-follow-link
   :help-echo #'my-zetteldeft-org-help-echo
   :store #'my-zetteldeft-org-store-link)

The only one I seem to be having trouble with is :complete.  I can get 
it to
prompt me for completing-read, and it returns the link portion only, but 
how
to get it to also prompt for a description?  Here is my :complete 
function:


  (defun my-zetteldeft-org-complete-link ()
"Link completion for Org zdlink type links"
(let* ((file (completing-read "File to link to: "
  (deft-find-all-files-no-prefix)))
   (link (zetteldeft--lift-id file)))
   (unless link (user-error "No file selected"))
   (concat "zdlink:" link)))

I searched the Internet, this mailing list archives, etc. high and low, 
all

to no avail.  So I decide to join the mailing list today.  Probably long
overdue anyway.  :)

Any tips would be greatly appreciated.

Cheers,
TRS-80