Re: Strange behaviour: Repeating tasks jumping in time
Alexei Gilev writes: > For repeating tasks, every once in a while I miss them. > Then I check them in my org file plus I visit git-status to find they have > been shifted. Sometimes even years (usually months). > > I haven't been able to track the source of this behaviour. Can you reproduce this without your config file (i.e., by doing `emacs -Q`)? Because, indeed, that sounds really strange. -- Cheers, TRS-80
Re: Either zero or two newlines with org-agenda-block-separator, cannot seem to get one?
Hello List, I had sent original email to the list some time ago, never received a reply. Hopefully I have set the correct headers for proper threading; if not the OP can be found at (either of) these URLs: https://yhetil.org/orgmode/33fe6d20c0591fedbdd8c6ea78e34...@isnotmyreal.name/ https://list.orgmode.org/33fe6d20c0591fedbdd8c6ea78e34...@isnotmyreal.name/ I just looked at latest master(main) and It looks like this part of the function `org-agenda-prepare' (in org-agenda.el) remains the same: #+begin_src emacs-lisp (insert "\n" (if (stringp org-agenda-block-separator) org-agenda-block-separator (make-string (window-max-chars-per-line) org-agenda-block-separator)) "\n")) #+end_src This results in problem mentioned in title. I guess no one else is affected/bothered by this? I have been patching it locally, it would be nice not to have to manage that any longer. -- Cheers, TRS-80
Re: Possible error in manual
J G writes: >> >> 2.2.3 Catching invisible edits >> >> Sometimes you may inadvertently edit an invisible part of the buffer and >> be confused on what has been edited and how to undo the mistake. Setting >> org-fold-catch-invisible-edits to non-nil helps preventing this. See the >> docstring of this option on how Org should catch invisible edits and >> process them >> > > org-fold-catch-invisible-edits does not exist in Org mode version 9.5.2, > it should be org-catch-invisible-edits. > > > thanks > Jim Graf Hi Jim, Do you think you might be able to submit a patch? :) -- Cheers, TRS-80
Re: Setting the default todo priority ?
David Masterson writes: > Use case: I may have a task type that fully expresses what it's priority > is. Example would be SOMEDAY which is going to have the lowest > priority. Adding a cookie to all SOMEDAY tasks seems superfluous. I see that Nick already directly answered your question. However, I wanted to point out that I think 'todo state' and 'priority' are orthogonal. For example, I also use 'SOMEDAY/MAYBE' as one of my todo states. However, within that subset, I still also use 'priority'. In my case, I use it to differentiate between things I might actually get to soon, vs. those I may truly never get to. Anyway, just some food for thought. -- Cheers, TRS-80
Re: netspend table
Jude DaShiell writes: > I think if I ever get good with #TBLFMT lines I'd like to write up > tables that cover many more useful and simpler calculation tables now > missing from documented orgmode. I replied separately about the accounting use-case (and I still think that's best handled by accounting software). However I also agree that tables (spreadsheets especially) are very, very useful for many things. It's so handy having a little table (and some calculations) right there in your notes. It took me quite a while to get the hang of it though, but eventually I was able to produce some quite impressive (to myself, anyway) results. I guess what I am trying to say is, stick with it, the payoff is worth it. Since you provided this as an example though, we will work with it anyway. If you have some other ideas, post them to the list (in new topics). I think it would be very helpful for a lot of people to see some examples of this. And I'm happy to share what I've learned. > This is a running balance table and I don't know what kind of a > #TBLFMT line would be useful for that either. You probably want to use a formula referencing relative (instead of absolute) locations, something like: #+begin_src org Original table: |--+--++---+-| | date | transaction | amount | fee | balance | |--+--++---+-| | [2023-01-11] | original balance | +0.00 | +0.00 | +423.17 | | [2023-01-12] | dunkin | -18.68 | -1.00 | 403.49 | | [2023-01-13] | WalMart | -28.68 | -1.00 | 384.88 | | [2023-01-16] | Deposit | + | | 634.88 | | [2023-01-17] | Capris | - | - | 615.34 | | [2023-01-17] | Mcdonalds| -4.74 | -1.00 | 609.60 | | [2023-01-18] | verizon | - | - | 543.35 | | [2023-01-26] | dunkin | - | - | 542.37 | | [2023-02-01] | damgoodcafe | -13.28 | -1.00 | 528.09 | |--+--++---+-| Empty amounts (signs only) removed: |--+--++---+-| | date | transaction | amount | fee | balance | |--+--++---+-| | [2023-01-11] | original balance | +0.00 | +0.00 | +423.17 | | [2023-01-12] | dunkin | -18.68 | -1.00 | 403.49 | | [2023-01-13] | WalMart | -28.68 | -1.00 | 373.81 | | [2023-01-16] | Deposit || | 373.81 | | [2023-01-17] | Capris || | 373.81 | | [2023-01-17] | Mcdonalds| -4.74 | -1.00 | 368.07 | | [2023-01-18] | verizon || | 368.07 | | [2023-01-26] | dunkin || | 368.07 | | [2023-02-01] | damgoodcafe | -13.28 | -1.00 | 353.79 | |--+--++---+-| ,#+TBLFM: @3$5..@>$5 = @-1 + ($-2 + $-1) #+end_src I am not sure what those signs (+/-) with empty amounts were about, but the way I would do it would be to make your entries in the 'amount' and 'fee' columns, and then let the running balance column be calculated. That's what I did in second table, above. Let me know if you have any questions. -- Cheers, TRS-80
Re: netspend table
Jude DaShiell writes: > Thanks much for your help on this problem. I've never done anything with > ledger-cli yet and wasn't aware such a package existed. Arne beat me to it, but I agree that this kind of thing is better in an actual accounting program. I love Orgmode as much as anyone, but I keep my finances in something like ledger as well. There are actually quite a lot of ledger-alikes, with a whole ecosystem of various software around them, see: https://plaintextaccounting.org/ Personally I use Beancount, but arrived at that decision after doing a fair amount of reading at the above site. YMMV of course. -- Cheers, TRS-80
Re: from table to properties the inverse columview operation
Uwe Brauer writes:
> Hi
>
> I have for example
>
> * Grupos :noexport:
> :PROPERTIES:
> :EXPORT_OPTIONS: num:t
> :COLUMNS: %10GRP(Grupos) %10HOJA(Hoja Nr) %10EJ(Ejericio Nr) %17DATE(Date)
> %7STATUS(Status){X/}
> :ID: Grupos
> :END:
>
> ** WAIT 1 <2022-02-03 jue 16:30> :Annu22: User
>:PROPERTIES:
>:ID: 6c53abda-5351-4651-8ec0-60138b248baa
>:Email:u...@gmail.com
>:Grp: Gr1
>:Usuario1: User1
>:Email1: us...@gmail.com
>:Usuario2: User2
>:Email2: us...@gmail.com
>:StEnv1: [X]
>:H1: 9
>:P1: 5
>:End:
>
> ** <2022-03-06 dom 18:16> : Ejercicios elegidos de la Hoja1: quien puede
> hablar el día <2022-03-07 lun>
>
> #+TBLNAME: hoja1
> #+BEGIN: columnview :maxlevel 2 :skip-empty-rows t :indent nil :hlines 1
> :format "%5TODO(Status) %5Grp(Grupo) %5Usuario1(Miembro1) %5H1(Ejercicio
> elegido) %5P1(Porcentaje) %7StEnv1(Solución enviado){X/}"
>
> | Status | Grupo | Miembro1 | Ejercicio elegido | Porcentaje | Solución
> enviado |
> |+---+--+---++--|
> || | | || [1/1]
> |
> | WAIT | Gr1 | User1| 9 | 5 | [X]
> |
> #+END
>
> So a table is generated based on earlier entries.
>
> Is there the inverse operation? Given a table I recover the original
> properties?
I think it might be easier to do in awk than ELisp. And I am better in
Elisp than awk, but awk was made for almost exactly this sort of thing.
Anyway, if some existing (Elisp) function exists for this, I would like
to know about it as well[0].
Cheers,
TRS-80
[0] I have already re-implemented too many things which already
existed, that I just did not know about at the time! :D
Re: Org and multimedia (tips?)
Juan Manuel Macías writes: > Hi all, > > I've been trying for a while to use Org also to store and org-anize the > data of my music and video files, so that I can conveniently access them > via helm-org-ql and play them using EMMS. I mean, I love Org just as much as anyone else on this list, but it does not strike me as the right tool for this job? In my mind anyway, I think first -- especially since you are storing your files on an SBC on the network -- about some network based music player like mpd or Mopidy (there are others, too). There are many interfaces to those, including some in Emacs (maybe even within EMMS, if I am recalling correctly). But then you can also access your music from outside Emacs, too. And without needing to hack something up / re-invent the wheel in Org. However, if you like to hack something up in Org instead, by all means, continue! :) Cheers, TRS-80
Re: Is there a maintained calf-calendar fork?
Ypo writes: > within a calendar: https://github.com/kiwanami/emacs-calfw > > But it seems to be unmaintained. > > Is there some *recommended *fork on Github with corrected bugs or new > functions? I don't know about *recommended*, however I do see at least a couple names I recognize in the list of forks (jweigley, syohex)[0]. I do not know of a way, in the GitHub UI (or through their API) to see which one of those forks might be ahead by the most number of commits[1]. Which means instead clicking on each one manually and looking at it. If there is some better way, I would love to know about it. > Offtopic if the answer to the above question is affirmative: could it > be on MELPA? Can MELPA change to new forks? I also see emacsmirror in the list. Maybe raise an issue there (or at Emacs Orphanage, etc.), maybe they know something more. Finally, there is always the option of picking up maintenance yourself. It often begins simply enough, fixing something that broke for yourself... Next thing you know you are sharing those patches, before you know it... you are suddenly maintaining a package. :) Just some food for thought. Cheers, TRS-80 [0] https://github.com/kiwanami/emacs-calfw/network/members [1] Not that this is a guarantee of anything, but it is one indication.
Re: Google Docs now supports MarkDown, but not Org syntax
Ken Mankoff writes: > Google Docs now supports MarkDown, not Org syntax :(. > > https://workspaceupdates.googleblog.com/2022/03/compose-with-markdown-in-google-docs-on.html > > -k. There is a Free Software (AGPL3.0) alternative to Google Docs called HedgeDoc. We have used it a little bit (within Armbian project) and I think it's pretty neat! [0] >From their web page: > HedgeDoc > The best platform to write and share markdown. > > HedgeDoc (formerly known as CodiMD) is an open-source, web-based, > self-hosted, collaborative markdown editor. > > You can use it to easily collaborate on notes, graphs and even > presentations in real-time. All you need to do is to share your > note-link to your co-workers and they’re ready to go. Of course it does not do everything that Google Docs does. But for common use-case of simple documents, it works quite well for collaboration. Unfortunately, HedgeDoc does not support Org Mode markdown, either. But at least, in this case, thanks to F/LOSS, the possibility exists (at least in theory) to add it. Cheers, TRS-80 [0] Even though I personally prefer Org over MD by quite a huge margin, MD is what the Armbian project uses, so, 'when in Rome...'
Re: Organice with local WebDAV server on PinePhone
Neil Jerram writes: > I've been thinking about how to get nice Org access on my PinePhone. My > current favoured option is Organice, with a local WebDAV server on the > phone. My Org is mastered in a hosted git repo, and I already have a script > for syncing between that and a local clone on various devices. I think I > just need to enhance that script to pull from WebDAV to the local git > working tree, before committing and syncing local updates, and to push to > WebDAV after pulling in remote updates. > > Any thoughts, on whether that would work well, if it could be simplified or > improved, or alternative solutions? > > Best wishes, > Neil I keep thinking that the keyboard is going to be the key[0] to achieving Emacs / Org Mode editing nirvana on my PinePhone. But I will have let you know if that's true or not, after it arrives. :) I already sync my Org Mode files (amongst other things) across all my devices using Syncthing. I use git for plenty of other things, but not for Org files. I edit them far too often, so I don't want to add any friction to that process. Cheers, TRS-80 [0] No pun intended.
Re: Thanks for good docs
Eric S Fraga writes: > I'm in total agreement. The indexing of the org info manual is > excellent and generally gets me to what I want very quickly. The Info format has really grown on me, too! Once I learned I could quite easily export from Org to Info[0], I started using it even more! I even made an Info manual for my own personal dotfiles repo! :D Cheers, TRS-80 [0] Try for yourself and see!
Re: Fixing the automatic generation of Tex info node names
Philip Kaludercic writes: > Ihor Radchenko writes: > >> Philip Kaludercic writes: >> >>> For some reason ox-texinfo removes periods from node names. It seems >>> this is not necessary as info can render these files without any issues, >>> and in certain cases not intended (e.g. I had a node named "Emacs 28.1" >>> and it was abbreviated to "Emacs 281"). >> >> According to >> https://www.gnu.org/software/texinfo/manual/texinfo/texinfo.html#Node-Line-Requirements >> >>>> Unfortunately, you cannot reliably use periods, commas, or colons >>>> within a node name; these can confuse the Info reader. Also, a node >>>> name may not start with a left parenthesis preceding a right >>>> parenthesis, as in (not)allowed, since this syntax is used to specify >>>> an external manual. (Perhaps these limitations will be removed some >>>> day.) >> >> Not that we cannot work around this, but we need something different >> than the proposed patch. > > Would you happen to know what the issue is? As I said, the documents > appear to render just as expected in my case, but it might just be due > to the version or because I didn't hit some specific edge-case. Personally, if I were interested, I think I would follow-up to the texinfo mailing list (or whatever they have) and ask them? As it even says above: > Perhaps these limitations will be removed some day Maybe they already have been? If not, worst case, I think you probably learn more about what the problem might be. Just a thought. Cheers, TRS-80
Re: org table: generate a weekly calendar with column that represents the hours
Uwe Brauer writes: > I am looking for convenient method to generate a weekly calendar in > table form that looks like > > #+begin_src > > | Hours | Mon | Tue | Wed | Thu | Fri | > | 8:00-9:00 | | | | | | > | 9:00-10:00 | | | | | | > | | | | | | | > | | | | | | | > | | | | | | | > | | | | | | | > | | | | | | | > | | | | | | | > | | | | | | | > | | | | | | | > | | | | | | | > | 19:00-20:00 | | | | | | > #+end_src > > But, of course the missing hours should be inserted automatically. > > A poor man's solution would be to do it manually and to save the table > as a template, but is there a way to generate it using org's table > functionality? Eric gave you a way that you asked (using Org table functionality), but another way could be to simply use a bunch of insert statements. Or rather, 1-2 to insert the header, followed by a loop with a starting time, interval, etc. Two advantages to that approach: 1. You could specify start, end time and resolution (spacing) as arguments (might not be needed). 2. You would not need a 'duration' column. 3. No need for formula (which leaves more room for your own, should you need it). Just another way to do the same thing. Cheers, TRS-80
Re: [tip] Org speed commands improved
Juan Manuel Macías writes: > Hi Ihor, > > Ihor Radchenko writes: > >> If you are going this far with speed commands, you might as well switch >> to modal editing. What you are describing is basically a modal command >> map with ability to switch to insert map. > > I'm not a fan of modal editing, rather the opposite. But in this > particular case I have found that I spend very little time editing the > raw content of the headers, once I set it. I spend more time editing the > 'meta-content': TODO states, properties, tags, refile, attached folders, > etc. And that with the speed commands can be achieved in a very agile > way, so that a small dose of controlled modal editing and reduced only > to the header, maybe it's worth it :-) If the speed commands were also > activated in the content of the sections, here we would have a real > modal editing, and that (in my case) would not be comfortable. I agree with your assessment! In fact, I think I will give your functions a try. Thanks for sharing them! Cheers, TRS-80
Re: Agenda without todos only if there is no other timestamp
TRS-80 writes:
> On 2022-04-05 04:48, Karl Voit wrote:
>> Hi,
>> I've got following custom agenda for exporting:
>> | ("n" "no TODO events +180d"
>> | ((agenda "no TODO events +180d"
>> | ((org-agenda-span 180)
>> |(org-agenda-time-grid nil)
>> |(org-agenda-entry-types '(:timestamp :sexp))
>> |(org-agenda-skip-function
>> | '(or
>> | (org-agenda-skip-entry-if 'todo 'any);; skip if any
>> TODO state is found
>> | (org-agenda-skip-entry-if 'category "errors");; skip
>> if any TODO state is found
>> | (my-skip-tag "lp")
>> | )
>> | nil (,(concat my-org-files-path "agenda_180d_filtered_raw.html")))
>> (don't mind the stupid name - I may fix this as it is misleading
>> here)
>> This results in an HTML file that contains my appointments without
>> the tasks.
>> Unfortunately, I sometimes seem to schedule appointments within open
>> todos such as:
>> | * NEXT talk with Steve about the project X
>> | SCHEDULED: <2022-04-05 Tue>
>> |
>> | - [X] ask him for a time-slot
>> | - we settled for: <2022-04-05 Tue 14:00-15:00>
>> Of course, those appointments are lost in my agenda export as
>> specified above. This is a bummer and I want to fix this somehow.
>> Tasks should be omitted only if there is no other time-stamp than
>> deadline or scheduled.
>> org-agenda-skip-if lists:
>> | scheduled Check if there is a scheduled cookie
>> | notscheduled Check if there is no scheduled cookie
>> | deadline Check if there is a deadline
>> | notdeadline Check if there is no deadline
>> | timestamp Check if there is a timestamp (also deadline or
>> scheduled)
>> | nottimestamp Check if there is no timestamp (also deadline or
>> scheduled)
>> | regexpCheck if regexp matches
>> | notregexp Check if regexp does not match.
>> | todo Check if TODO keyword matches
>> | nottodo Check if TODO keyword does not match
>> How is it possible to accomplish this? I think this would require
>> something like "Check if there is a timestamp (except deadline or
>> scheduled)" which isn't available yet.
>> Any ideas on that one?
>
> I think you will need to write a custom ~org-agenda-skip-function~.
>
I realized there is probably an even easier way (no custom ELisp
required), simply by creating a separate child heading for the meeting,
which should then show up. Assuming I am following you correctly, how
about:
#+begin_src org
* PROJECT Project X
:PROPERTIES:
:CATEGORY: P:X
:END:
** PROJECT Discuss 'topic' with Steve
*** DONE Ask Steve for a time-slot
*** Meeting with steve
<2022-04-05 Tue 14:00>--<2022-04-05 Tue 15:00>
#+end_src
N.B. the indentation levels.
Couple notes here:
1. If you set CATEGORY on the parent, and have enabled inheritance, the
'P:X' should appear on left side in your agenda, at the time of this
meeting, giving context. The 'P:' convention is just what I use to
denote a Project (as opposed to an Area).
2. I follow GTD here, where anything with more subtasks is itself also
considered another 'project'. You don't have to. In fact one of my
todo keywords is actually PROJECT.
3. I guess you could use SCHEDULED just as well, but if you carefully
read the manual, this is not the intent of SCHEDULED. An appointment
(like this) should simply be a time slot (as I showed above). You can
of course do whatever you like. :)
I have included some things here that I might do which are not strictly
necessary to solving your problem, but hopefully you can adapt this to
your needs.
Cheers,
TRS-80
Re: DOC "Org Mode tools": orgparse is missing
Patches welcome? :) Cheers, TRS-80
Re: Agenda without todos only if there is no other timestamp
On 2022-04-05 04:48, Karl Voit wrote:
Hi,
I've got following custom agenda for exporting:
| ("n" "no TODO events +180d"
| ((agenda "no TODO events +180d"
| ((org-agenda-span 180)
|(org-agenda-time-grid nil)
|(org-agenda-entry-types '(:timestamp :sexp))
|(org-agenda-skip-function
| '(or
| (org-agenda-skip-entry-if 'todo 'any);; skip if any
TODO state is found
| (org-agenda-skip-entry-if 'category "errors");; skip
if any TODO state is found
| (my-skip-tag "lp")
| )
| nil (,(concat my-org-files-path "agenda_180d_filtered_raw.html")))
(don't mind the stupid name - I may fix this as it is misleading
here)
This results in an HTML file that contains my appointments without the
tasks.
Unfortunately, I sometimes seem to schedule appointments within open
todos such as:
| * NEXT talk with Steve about the project X
| SCHEDULED: <2022-04-05 Tue>
|
| - [X] ask him for a time-slot
| - we settled for: <2022-04-05 Tue 14:00-15:00>
Of course, those appointments are lost in my agenda export as
specified above. This is a bummer and I want to fix this somehow.
Tasks should be omitted only if there is no other time-stamp than
deadline or scheduled.
org-agenda-skip-if lists:
| scheduled Check if there is a scheduled cookie
| notscheduled Check if there is no scheduled cookie
| deadline Check if there is a deadline
| notdeadline Check if there is no deadline
| timestamp Check if there is a timestamp (also deadline or
scheduled)
| nottimestamp Check if there is no timestamp (also deadline or
scheduled)
| regexpCheck if regexp matches
| notregexp Check if regexp does not match.
| todo Check if TODO keyword matches
| nottodo Check if TODO keyword does not match
How is it possible to accomplish this? I think this would require
something like "Check if there is a timestamp (except deadline or
scheduled)" which isn't available yet.
Any ideas on that one?
I think you will need to write a custom ~org-agenda-skip-function~.
It's late and I am too tired, but if you are still floundering about
after some days, send another mail and I will see what I can do to help.
:)
Cheers,
TRS-80
Re: stability of toc links
On 2021-04-29 18:18, Samuel Wales wrote: On 4/29/21, TRS-80 wrote: My "quick and dirty" solution was to make a function to map over each heading and assign a custom ID based on the text of the heading. It only assigned one if one did not exist already (so in case you had done any manual adjustments they would not be overwritten). I had posted it very early in the thread, but it did not seem to gain much interest. It was not posted as a "long term and proper solution to be included into Orgmode" but rather a quick and easy workaround in the meantime. thank you. i can imagine that could be useful for a lot of users, but for me, as i said in my op, "short of adding custom id or id to everything" --- i didn't want to add custom id. i will try to clarify why in case it is useful. Well, FWIW, I did not want to assign custom IDs, either. :) Like you, I didn't want to "pollute" the properties drawer, etc. However after looking into the options, including discussing this issue on the mailing list myself some time ago, I realized that this was going to be a major change in Orgmode, that it had been discussed before (multiple times), and therefore would require (perhaps significant) politicking, etc... And so then I assigned custom IDs to all my entries, and got on about my business. I now have achieved stable links when exporting. ;) I still support your (and others') efforts toward a more proper and long term solution, I just think they are going to take a while to bear fruit is all. Cheers, TRS-80
Re: [WDYT, mini] key h in agenda for quick help
On 2021-04-28 00:59, Timothy wrote: Bastien writes: thanks for the proposal. I'm not convinved that users who don't know about `C-h m' will think of hitting `h' or another key. I might be wrong, so if beginners suggest they expect such a key and were amazed at how useful C-h m was for them when reading this thread, I might change my mind. I can distinctly recall hitting "?" in Org agenda when I was getting started, after getting used to Magit. For some reason, "?" is the single key that comes to my mind as well (rather than "h" or any other). I don't know if I got that from Magit, general GNU/Linux usage, or what? Having said that, I am not arguing in favor of OPs proposal. Just mentioning the "single key" that came to mind, FWIW. As I mentioned in another reply, I think things are fine the way they are. ¯\_(ツ)_/¯ Cheers, TRS-80
Re: [WDYT, mini] key h in agenda for quick help
On 2021-04-28 02:08, Tim Cross wrote: I've rarely found describe mode to be terribly useful I'm the opposite. I find it a great way to quickly look up (or search for) some keybinding or function I forgot. But then again, I know the difference between C-h m and C-h i (as well as other help options) so if I need the manual (or other information) I go straight there. They each have their place, IMO. Cheers, TRS-80
Re: [PATCH] Fontification for inline src blocks
On 2021-03-31 11:00, Timothy wrote: I've been using inline src blocks a fair bit more recently, and I've thought it's a pity how bad they look as they are currently without fontification. A little digging into Org internals and font-lock later and we have this patch. I recall trying inline src blocks once, a year or two ago. I couldn't get it to work, so I gave up. Of course I figured I was doing something "wrong" or whatever, so it's nice to see "it's not just me." :) So, 3x thanks! One for confirming the bug, and 2 more for actually providing a solution! I look forward to circling back to it when I have some time. Cheers, TRS-80
Re: Turning off all indentation in 9.4.4
On 2021-04-28 00:03, Bastien wrote: TRS-80 writes: 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? this particular issue has been fixed yesterday in master, if you want to give it a try. Again, thanks for follow up. I think I had given up on this because of the strange behavior I couldn't figure out at the time. In fact, looking again today, my setting for org-adapt-indentation was commented out in my init file. Hopefully this is what was fixed recently. Here is what I remember: ** Heading :LOGBOOK: - State "CREATED" from [2021-01-22 Fri 12:56] \\ - Some comments here. :END: Then doing in/out dent with org-adapt-indentation set to 'headline-data would break just the comment part of the logbook entry, like so (everything else seemed to move OK): *** Heading :LOGBOOK: - State "CREATED" from [2021-01-22 Fri 12:56] \\ - Some comments here. :END: I am a Debian user, so I will get to test the latest commit in about 2 more years maybe? :D Jokes aside, I appreciate your follow up and so wanted to report back. I don't know when I will get to actually test the new fix, but if this is what was fixed I greatly appreciate it. Cheers, TRS-80
Re: Turning off all indentation in 9.4.4
On 2021-04-28 00:09, Bastien wrote: TRS-80 writes: 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? So core idea behind (setq org-adapt-indentation 'headline-data) is to let people end up with: * TODO item :PROPERTIES: :CUSTOM_ID: item :END: :LOGBOOK: ... :END: A paragraph here. Let me know if if does not what you want, including what you expect from hitting RET after the headline, with the various combinations of org-adapt-indentation and electric-indent-mode. Thank you for the follow-up, Bastien. I haven't touched this in a while, but I do believe it does as I had always wanted (mainly leaving the body alone at column 0 as I in/out-dent the heading (and its associated data)) which sounds like the intention. The one issue I recall experiencing (breaking indentation of logbook entries) you seem to have addressed in another reply in this thread, where I will reply with more specifics. Cheers, TRS-80
Re: stability of toc links
On 2021-04-21 19:30, Samuel Wales wrote: as it has been a long time my original post is Message ID and the content is === when you link to a section using toc, you get a link like https://thekafkapandemic.blogspot.com/2020/02/crimes-against-humanity_3.html#org080f0ab will these links break if somebody copies them and pastes them elsewhere? what if you add a section? there doesn't seem to be a perfect solution, short of adding custom id or id to everything, but perhaps a fuzzy hash of the header and contents of the section could be used? or a strict hash of the header? is anything like this being done? just curious. My "quick and dirty" solution was to make a function to map over each heading and assign a custom ID based on the text of the heading. It only assigned one if one did not exist already (so in case you had done any manual adjustments they would not be overwritten). I had posted it very early in the thread, but it did not seem to gain much interest. It was not posted as a "long term and proper solution to be included into Orgmode" but rather a quick and easy workaround in the meantime. Cheers, TRS-80
Re: emacs27 and let: Symbol’s value as variable is void: org-table-header-line-p
On 2021-03-23 19:57, Santiago Mejia wrote: Hi All, I just did a clean install of Xubuntu 20.04. I also installed emacs27 (from this repository:ppa:kelleyk/emacs) When I try to export any snippet from org-mode by calling org-export-dispatch, my freshly installed emacs complains: "let: Symbol’s value as variable is void: org-table-header-line-p" Any help would be much appreciated Santiago Mejia I guess you should take it up with whoever this kelleyk person is? If you can reproduce the error from "normal" distro sources (or Emacs repo from source, etc.) then I suppose it is an issue for this list. Otherwise I don't think it is? I guess there must be some reason you installed it from that particular location? Cheers, TRS-80
Re: org-adapt-indentation not honored prior to Org 9.4?
On 2021-03-22 15:37, Mike Kupfer wrote: Over the weekend I upgraded my Emacs from 27.1 (Org 9.3) to 27.2-rc2 (Org 9.4). I noticed that Org mode behaves differently, even with "emacs -Q". In 27.1, if I visit foo.org and type "* header RET", point is put in the first column. In 27.2, point is put in column 3. AFAIK, I'm not using electric-indent-mode; at least it's not shown in the minor mode list in the modeline. org-adapt-indentation is t in both Emacs 27.1 and Emacs 27.2. Was there a bug fix that went into Org 9.4 such that org-adapt-indentation is now honored? Could the change in behavior be documented in the ORG-NEWS file in Emacs? I already asked about this on emacs-devel; Eli Z. sent me over here. thanks, mike You are not alone, mate. We discussed this not too long ago in the following thread: Turning off all indentation in 9.4.4 https://lists.gnu.org/archive/html/emacs-orgmode/2021-02/msg00045.html In particular, the answer you seek may be in this post: https://lists.gnu.org/archive/html/emacs-orgmode/2021-02/msg00285.html The TL; DR of which is to turn off ~electric-indent-local-mode~ in org-mode: #+begin_src emacs-lisp (add-hook 'org-mode-hook (lambda () (electric-indent-local-mode -1))) #+end_src Of course, you could test live first in an Org buffer by pressing M-: and eval: #+begin_src emacs-lisp (electric-indent-local-mode -1) #+end_src If that does what you expect, then set up the above mode hook in your init file. If your expectations are slightly different to mine, hopefully there is something in that thread that might be helpful for you. Cheers, TRS-80
Re: org-capture-template: table lines including newline of sorts
On 2021-03-18 03:38, Uwe Brauer wrote:
I commented out all my templates
So the only entry is
("s" "timeslip" table-line
(file "/home/oub/timeslips.org")
;; (file "d:/ActiveFiles/timeslips.org")
"\| %(org-read-date)\| %^{FileName} %i\|
%^{Narrative} %i\| %^{Time} %i\| %^{Expense} %i"
Timeslips.org is empty.
I mark a line in my org-init file and fire up org-capture using your
template, I insert as file name org-init,
narrative I insert blabla
time I insert 10:00
Expense I insert 10
And I obtain
| Bad template
What do I miss here?
Maybe try a minimal Emacs, just to make sure something else isn't
affecting it?
Cheers,
TRS-80
Re: org-capture-template: table lines including newline of sorts
On 2021-03-15 10:14, Uwe Brauer wrote: Uwe Brauer writes: Break up the line however you wish into quoted substrings and concat them together..? No entirely sure that you mean by quoted substrings, can you give me an example, please? I am not same guy you were replying to, but: #+begin_src emacs-lisp (concat "Add " "all " "these " "strings " "together!") ;; result: "Add all these strings together!" #+end_src I use it a lot when: - things start to get complicated (some regexp) - I want to maintain lines in source that will match output - in some other cases, too. Really helpful! Cheers, TRS-80
Re: org-capture-template: table lines including newline of sorts
On 2021-03-13 02:24, Uwe Brauer wrote:
Hi
Currently I have the following setting for one org-capture-template:
("mu" "Stat+Num:Exercises English"
table-line (file+headline "~/Somefile.org" "Exercise Group-E")
"| %:fromname|%:fromaddress |
%(my-extract-cc)|%^{Sheet|1|2|3|4|5|6}|%^{Exercise|1|} | %a|%:date |
" :prepend t
)
That line is too long, I'd like something like this
("mu" "Stat+Num:Exercises English"
table-line (file+headline "~/Somefile.org" "Exercise Group-E")
"| %:fromname|%:fromaddress\n
%(my-extract-cc)|%^{Sheet|1|2|3|4|5|6}|%^{Exercise|1|} | %a|%:date |
" :prepend t
)
Or
("mu" "Stat+Num:Exercises English"
table-line (file+headline "~/Somefile.org" "Exercise Group-E")
"| %:fromname|%:fromaddress\n
%(my-extract-cc)|%^{Sheet|1|2|3|4|5|6}|%^{Exercise|1|} | %a|%:date |
" :prepend t
"| | %(my-extract-cc) | | | | | | || | | ||
| " :prepend t
)
But nothing worked, any ideas?
Thanks and regards
Uwe Brauer
Do you need to add more pipes to keep the table structure on the line
after the newline?
Cheers,
TRS-80
Re: Culling org files (notion of Types, many small vs few big files)
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
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
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
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
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
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
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
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
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?
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"
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
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?
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?
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
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
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
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
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
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/)]
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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
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
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?
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?
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?
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?
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?
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?
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
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 ?
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?
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)?
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)?
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)?
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)
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?
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)?
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?
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?
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
