Re: [PATCH] I updated patch by deleteing duplicate tags
[stardiviner] GPG key ID: 47C32433 IRC(freeenode): stardiviner Twitter: @numbchild Key fingerprint = 9BAA 92BC CDDD B9EF 3B36 CB99 B8C4 B8E5 47C3 2433 Blog: http://stardiviner.github.io/ On Wed, Dec 2, 2020 at 5:30 PM stardiviner wrote: > The default [C-c C-q] completing tags only retrieve tags from current > buffer locally. > > By this patch, will merge both buffer-local tags and user defined global > `org-tags-alist`. > > This is more reasonable. > > > [stardiviner] GPG key ID: 47C32433 > IRC(freeenode): stardiviner Twitter: @numbchild > Key fingerprint = 9BAA 92BC CDDD B9EF 3B36 CB99 B8C4 B8E5 47C3 2433 > Blog: http://stardiviner.github.io/ > From 95060ad30d2c7fd5db432b2058627ee48d1586b0 Mon Sep 17 00:00:00 2001 From: stardiviner Date: Wed, 2 Dec 2020 17:24:29 +0800 Subject: [PATCH] org.el: Complete tags from both global and buffer local * lisp/org.el: (org-fast-tag-selection): merge buffer local tags with global alist of tags. --- lisp/org.el | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 0e12e4b15..287b8c407 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -12256,10 +12256,13 @@ (defun org-fast-tag-selection (current inherited table &optional todo-table) (condition-case nil (setq tg (completing-read "Tag: " - (or buffer-tags - (with-current-buffer buf - (setq buffer-tags - (org-get-buffer-tags)) + (delq nil + (delete-dups + (append (or buffer-tags + (with-current-buffer buf + (setq buffer-tags + (org-get-buffer-tags + (org-global-tags-completion-table)) (quit (setq tg ""))) (when (string-match "\\S-" tg) (cl-pushnew (list tg) buffer-tags :test #'equal) -- 2.29.2
Re: Exporting .org to .md for Sourcehut (sr.ht); ox-md not following Markdown spec?
TRS-80 writes: >> On 2020-12-02 16:59, Tim Cross wrote: >>> TRS-80 writes: >>> >> 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. > OK. My reading of that response was that the custom approach would give you full control over the HTML. If they still run some sort of sanitiser, then you would still have an issue as you actually don't have full control. However, that does seem like an odd process. I mean, if you go to the trouble to setup a custom workflow and then having some arbitrary sanitiser come in at the end and move the goal posts seems broken to me. -- Tim Cross
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?
TRS-80 writes: >> On 2020-12-02 14:44, Tim Cross wrote: >> > 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. Basically, sourcehut is using the commonMark spec plus their own 'extensions/modifications' to that spec. The org exporter is not breaking the commonMark spec. Org mode exports could use what could be argued a simpler link target export style, but perhaps using the 'raw' HTML approach makes it more flexible/compliant with different markdown flavors? Problem is, changing this now could result in lots of breakage for others where it is now working. 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? -- Tim Cross
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
Re: Exporting .org to .md for Sourcehut (sr.ht); ox-md not following Markdown spec?
Hi TRS-80, 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. (note: Markdown allows embedded HTML, so ox-md's behavior is not incorrect) 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. --Diego On Wed, Dec 2, 2020 at 7:54 PM TRS-80 wrote: > 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: Exporting .org to .md for Sourcehut (sr.ht); ox-md not following Markdown spec?
TRS-80 writes: > 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 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. This probably highlights the advantages of a standardised spec. One of the challenges with markdown is that there has never been one universally accepted spec. While the situation has consolidated somewhat since markdown first became popular, there is still some variation in implementations and some of the decisions made when the org mode exporter was first implemented may not be as correct/accepted now. 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. 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. Unfortunately, this fails to provide a clear path to fix your problem. I guess the 'sane' thing to do would be to look at how the two different specs differ and then decide if that difference can be managed by providing additional customisation options to the existing markdown exporter or whether the differences are sufficient to warrant another completely different markdown exporter along similar lines to the github flavoured markdown (probably also worth checking the differences between sourceht and github as well in case it is closer to what sorcehut expects). -- Tim Cross
Re: Exporting .org to .md for Sourcehut (sr.ht); ox-md not following Markdown spec?
Try using pandoc Org to Markdown as that could help until Org exporting start working how it should.
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: Bring up a screen giving option to open a series of orgmode files
Thank you for script, I will see to use it. That is exactly that I need for indexing of some important references. Today I had need for this. > Maybe it is possible to add necessary features to pdf.js and to serve the > viewer from purely static site (no authorization and no API > endpoints). That involves via as web server, and browser. For WWW is alright. Maybe it could open browser on local files, but is just too many vias. If I wish to package whole system it requires whole system distribution. Bunch of files. > > > And finally, running browser under a different user is likely not enough. > > > Browser for working with "external" resources should be isolated from home > > > or office network (network namespace, container, virtual machine). There > > > are > > > enough web sites that checks which ports are open at least on the > > > localhost. > > > Local network could be scanned through browser as well. > > > > I agree, only that it is not practical for majority of us. In my > > opinion browsing machines should be separate with few sensitive > > files if any. > > https://stgraber.org/2014/02/09/lxc-1-0-gui-in-containers/ > https://gudok.xyz/lxcdeb/ That is something to study and try out. > > When I get mobile device in my hand it allows me to share pictures > > to email, chat, web server, to other file managers, and so > > on. Desktop operating systems are not so well integrated as mobile > > systems. > > Desktop has a convenient keyboard and a mouse to allow *authoring*, mobile > devices are more limited in that sense, they are more suitable for *sharing* > content generated by others or "liking" it. On desktop one could add a > couple of valuable phrases in several seconds: why the item to share is > important for particular person at particular moment, copy-paste is just a > few more keystrokes. That is one viewpoint but look at Engelbart, did he use mobile device? Probably nobody even knew about such to exist in future 25 years later when he invented hypertext systems. Highlights of the 1968 "Mother of All Demos" https://www.dougengelbart.org/content/view/276/000/ We have various communication lines such as email, various chat messengers, various social networks, fax, SMS, sound output, streaming video, so anything should be shareable to any communication channel in better integrated manner. 1. Place icons of small images like friend's faces on desktop. 2. Drag and drop any file to their icons. Finished. System could do the rest, if it is short file, it could be sent as SMS or email, if image or something else, send it as attachment or provide password protected on a website with notification both to SMS and email. In general any feature that spares users of typing and making too many actions is useful.
Re: Bring up a screen giving option to open a series of orgmode files
2020-12-01 Jean Louis wrote:
* Maxim Nikulin [2020-11-30 20:10]:
To note is that not every PDF has text inside. They may be made from
images.
Images do not necessary mean absence of text. Tesseract can generate PDF
files with text layer in addition to original scans.
and prepares `capturexpdf.sh' to be executable and contains following:
,
| #!/bin/bash
| capture="/home/data1/protected/xpdfcaptured.org"
| entry=`zenity --entry`
| hyperlink="[[$1:$2][$entry]]"
| echo $hyperlink >> $capture
`
Personally I am considering something like (not ready to use, just quick
and dirty proof of concept)
--->8---
#!/bin/bash
set -e
set -o pipefail
getmeta() {
file="$1"
page="$2"
sel_x="${3:-0}"
sel_x="${sel_x%.*}"
sel_y="${4:-0}"
sel_y="${sel_y%.*}"
sel_X="${5:-0}"
sel_X="${sel_X%.*}"
sel_Y="${6:-0}"
sel_Y="${sel_Y%.*}"
url="${7:-}"
# FIXME obtain page height using pdfinfo
page_height=792
echo "[[${file}#page=${page}]]"
pdfinfo "$file" | sed -n -e
's/^\(CreationDate\|ModDate\|Author\|Title\|Subject\):\s*\([^ ]\)/- \1
:: \2/p'
if [ -n "$sel_Y" ] ; then
echo "#+begin_quote"
pdftotext -layout -f "$page" -l "$page" \
-x "$sel_x" -y "$((page_height - sel_Y))" -W "$((sel_X-sel_x))" -H
"$((sel_y-sel_Y))" "$file" - \
| sed -e 's/^[#*]/,&/' -e 's/\s*$//'
echo "#+end_quote"
fi
if [ -n "$url" ] ; then
echo -e "\n- Link: [[$url]]"
fi
}
if [ -z "$1" ] || [ -z "$2" ] ; then
echo "No file or page" 1>&2
exit 1
fi
# or emacsclient calling org-capture
getmeta "$@" | xsel -b
->8-
Unfortunately Xpdf quite slow works with large raster images. Evince
better handles PDF files with wide spread problems (e.g. relying on
fonts that are not embedded into the document) or with text in non UTF-8
encodings.
Surprisingly PDF viewers built in into browser have fences
preventing access of browser extensions to the text content. I did
not expect such limitations.
It does not sound as progress. Evince maybe originates from xpdf but
does not have nearly these options as xpdf. We go back and become more
beautiful with software but less useful.
Maybe it is possible to add necessary features to pdf.js and to serve
the viewer from purely static site (no authorization and no API endpoints).
And finally, running browser under a different user is likely not enough.
Browser for working with "external" resources should be isolated from home
or office network (network namespace, container, virtual machine). There are
enough web sites that checks which ports are open at least on the localhost.
Local network could be scanned through browser as well.
I agree, only that it is not practical for majority of us. In my
opinion browsing machines should be separate with few sensitive
files if any.
https://stgraber.org/2014/02/09/lxc-1-0-gui-in-containers/
https://gudok.xyz/lxcdeb/
When I get
mobile device in my hand it allows me to share pictures to email,
chat, web server, to other file managers, and so on. Desktop operating
systems are not so well integrated as mobile systems.
Desktop has a convenient keyboard and a mouse to allow *authoring*,
mobile devices are more limited in that sense, they are more suitable
for *sharing* content generated by others or "liking" it. On desktop one
could add a couple of valuable phrases in several seconds: why the item
to share is important for particular person at particular moment,
copy-paste is just a few more keystrokes.
Re: is org-export-preserve-breaks incompatible with org verse blocks?
hi again, i had a look at the content.xml file in each case. with org-export-preserve-breaks disabled, whitespace is exported (correctly) like so: text here indented 5 spaces. with the option enabled, the the spaces are directly transferred to the file: text printed after 5 spaces, which are not properly preserved in the org file. regards, m On 23/11/2020 19:19, mousebot wrote: > hi org, > > i use verse blocks to export to odt in a way that preserves whitespace. if i > enable org-export-preserve-breaks, whitespace in verse blocks is not > preserved: any spaces used to indent text from the left margin are reduced to > a single space. is this intended behavior? i had hoped to be able to use both > features in my document. > > example: > > #+begin_verse > here you are, > doing your > darned > best > to export > #+end_verse > > will export as > > here you are > doing your > darned > best > to export > > i tested this by loading emacs -Q, evaluating (setq > org-export-preserve-breaks t), then using the normal org export dispatch, > with no template. > > best > m >
overloading of internal priority calculations in agenda
Hi all,
I'm currently working on adding a feature to org-agenda which allows
manual ordering of entries in combination with the existing automatic
ordering (as dictated by `org-agenda-sorting-strategy').
During my investigations I noticed that while `org-get-priority' converts
[#B] style cookies into a numeric priority which is a multiple of
1000, further adjustments are made in functions like
`org-agenda-get-scheduled' before adding this numeric priority as a
text property on the entry:
'priority (if habitp (org-habit-get-priority habitp)
(+ 99 diff (org-get-priority item)))
In this case `diff' refers to the number of days between now and when
the item was scheduled. A slightly different calculation is made in
`org-agenda-get-timestamps':
(org-add-props item props
'priority (if habit?
(org-habit-get-priority (org-habit-parse-todo))
(org-get-priority item))
I further noticed that this overloading of the internal priority by
including timestamp and habit data causes disruption to the behaviour
I imagine most users would expect from `org-agenda-sorting-strategy'.
For example, if you have `priority-down' as the first entry in the
`agenda' section and `category-keep' as the second, then differences
in the SCHEDULED timestamp are included in the priority calculation
and can therefore prevent sorting of two adjacent [#B] items by
category. This seems like a bug to me, or at least breaks the
Principle of Least Surprise.
I did some git archaelogy and found that the first ever git commit
4be4c562 (for release 4.12a) already includes
`org-agenda-sorting-strategy', but at that point, time-{up,down} were
the only time-related sorting criteria available.
I was also wondering where the magic 99 number above came from, and I
found that the same (first ever) commit introduced the following
priority calculation:
(+ (- 5 diff) (org-get-priority txt))
Subsequently, commit 70b6cc5d (for release 5.10a) changes this to:
(+ 94 (- 5 diff) (org-get-priority txt))
and then commit 69ec6258 (on 2016-11-25) changes it to
(+ 99 diff (org-get-priority item))
Given that `org-agenda-sorting-strategy' now supports all manner of
sorting criteria, many of which are time-sensitive, I would like to
know if there is any reason not to remove this overloading of the
priority calculation, i.e. decoupling it to depend purely on the
result of `org-get-priority' and `org-habit-get-priority'?
If fact, perhaps we could go one step further and add support for new
habit-priority-{up,down} sorters to `org-agenda-sorting-strategy', so
that the priority-{up,down} sorters sort purely by the priority cookie
and nothing else?
Thanks!
Adam
Re: Remembrance Agents
* hpgislero...@bluewin.ch [2020-12-02 12:57]: > > The more information user > > enters into the database and the more tags and relations have been > > created the better the relevance. > > Isn't the real problem-to-solve finding the actual semantic context and > then to relate it matching information? That problem may easily be solved by using external tools such as PostgreSQL as it has a built-in relevance search and indexing functions. To index files into PostgreSQL database is not hard task. If you happen to have a need, let me know and I will help. Yesterday I have implemented relevance searć in relation to website pages in the database. As often I wish to reference URLs from my websites to our clients. Among 4000+ URLs one has to find it by thinking and not by browsing hierarchy. Until now I was using 2 inputs approach like: 1. Write one word or part of word that I remember being part of the page. 2. When faced with completion candidates narrow it down with second or third word. Yesterday I have implemented this search by using relevance matching feature and it works fast: (format "SELECT pages_id || ' ' || pages_title || ' ' || ts_rank_cd(to_tsvector(pages_title || pages_description),%s,32 /* rank/(rank+1) */) AS rank FROM pages, to_tsquery(%s) query WHERE query @@ to_tsvector(pages_title || pages_description) ORDER BY rank DESC LIMIT 30;" query query)) ;; TODO this cannot order by rank The query is prepared with this: (defun rcd-sql-prepare-text-query (query) (let* ((query (string-trim query)) (query (if (and (string-match " " query) (not (string-match "&" query))) (string-replace " " " & " query query)) because I normally need WORD AND WORD. But I could make it any how, I could search for (WORD AND WORD) OR WORD OR (WORD AND WORD) all is possible. The function converts "my term words" into "my & term & words" where & has the meaning of logical AND. This shortens my search within Emacs to just one query and not having two steps. It finds relevant results with accuracy and precision. My searches locate the hyperlink within 10 first results, so I have limited it to 30 results. > There is als After all, words (TAGS, ...) have different meaning in > different semantic contexts. In their own meanings yes. But for the user's mind they may be related and useful to be searched together. If tag is there it is related to the object, search without tag and with tag may give quite different results. > I suspect, 'just' relating to tags (words) and showing the attached > document (part) to her is not very useful, yes? Thinking of many other systems, in many of other systems tags are main method of locating things. But it all comes from well organized user's mind. If mind is not organized user will not know how to tag to make future locating features work well. If it is tagged well locating things is very fast. - todo family son joe bicycle - todo family son kim drivers-license - todo business appointment - todo health kidneys When tags are used that way then locating things related to one son among two sons become easy. Locating things for family is larger group and locating business appointments becomes easy. When something is done, the TODO should be changed to something else. If user tags well then searches can be very useful. But what if user does not tag well but still has some attributes attached such as titles, body text, etc. then the relevance search may help. Chapter 12. Full Text Search https://www.postgresql.org/docs/current/textsearch-intro.html#TEXTSEARCH-MATCHING emacs-libpq @ Github https://github.com/anse1/emacs-libpq
Re: Bring up a screen giving option to open a series of orgmode files
* Ihor Radchenko [2020-12-02 12:50]: > Jean Louis writes: > > I can see that Python is reading QUTE FIFO and then sending commands > > to browser from there. > > Yes, but QUTE_FIFO variable is only available for the userscripts called > from inside qutebrowser. Probably, there is some way to obtain FIFO > location, but I am not aware about it. /run/user/1001/qutebrowser/ipc-21232f297a57a5a743894a0e4a801fc3 It could be detected in that directory. Thank you, I will use standard approach to bind key from qutebrowser
Re: Bring up a screen giving option to open a series of orgmode files
2020-11-24 Ihor Radchenko wrote: Also, you can capture webpage as a heading using org-capture + org-protocol: 1. https://addons.mozilla.org/en-US/firefox/addon/org-capture/ 2. https://chrome.google.com/webstore/detail/org-capture/kkkjlfejijcjgjllecmnejhogpbcigdc 3. https://seds.nl/notes/orgmode-firefox-bookmark/ 4. https://github.com/yantar92/org-capture-ref (shameless plug) Ideally, the link should be https://orgmode.org/worg/org-contrib/org-protocol.html but its content is a bit outdated. It seems, the following link was not explicitly mentioned in this thread, however other resources cite it https://github.com/alphapapa/org-protocol-capture-html
Re: Bring up a screen giving option to open a series of orgmode files
* Ihor Radchenko [2020-12-02 12:53]: > Jean Louis writes: > > > What I do not know is how do I invoke script from qutebrowser to use > > the environment variables? > > https://www.qutebrowser.org/doc/userscripts.html > > Basically, script can be just a bash script. > You need to put it into userscripts directory and then you can call it > from inside qutebrowser using :spawn --userscript scriptname. That > command can be bound to a key for convenience. Thank you. Things are not easy to find, I was looking for shell or :! like in vi
Re: Bring up a screen giving option to open a series of orgmode files
Jean Louis writes: > What I do not know is how do I invoke script from qutebrowser to use > the environment variables? https://www.qutebrowser.org/doc/userscripts.html Basically, script can be just a bash script. You need to put it into userscripts directory and then you can call it from inside qutebrowser using :spawn --userscript scriptname. That command can be bound to a key for convenience. Best, Ihor
Re: Bring up a screen giving option to open a series of orgmode files
Jean Louis writes: > I can see that Python is reading QUTE FIFO and then sending commands > to browser from there. Yes, but QUTE_FIFO variable is only available for the userscripts called from inside qutebrowser. Probably, there is some way to obtain FIFO location, but I am not aware about it. > Then I could instruct Emacs to do the same, do you think so? Instead > of invoking command from qutebrowser maybe I could invoke it from > Emacs? You can indeed send commands to qutebrowser from Emacs. Here is an example how I did it: https://github.com/yantar92/org-capture-ref/blob/master/org-capture-ref.el#L754 > I could make X Window Manager keybinding that invokes Emacs that sends > command to qutebrowser to obtain information. I don't think that you can easily obtain information that way. AFAIK, FIFO is only for sending commands. On the other hand, there is in-progress plugin API. That should be more powerful once released. I think it is usable even now, but there is no official documentation yet (which didn't stop some people from using it). Best, Ihor
Re: Bring up a screen giving option to open a series of orgmode files
* Ihor Radchenko [2020-11-25 10:17]: > > - qutebrowser, once HTML is loaded or any file, can transmit this file > > in a script to external program to parse it, collect meta data and > > index it somewhere > > .html version of the current page is always available to userscripts via > $QUTE_HTML variable. > > I use it in my capture package: > https://github.com/yantar92/org-capture-ref#qute_integration > > > - in particular I would be interested if qutebrowser could be used to > > convert the HTML on the fly to OPML by using external script so to > > get chunks finely grained such as paragraphs, headings of course are > > included making HTML better outlined and structured for further > > import into both Org files and yet private Hyperscope database. > > Since you have access to the html file, you can pass it to any app in > your system. For example, you might convert the page to any other format > with pandoc or parse it with beautifulsoap in python. However, the file > will not contain the multimedia content - only bare html. I understand what you say. What I do not know is how do I invoke script from qutebrowser to use the environment variables?
Re: Bring up a screen giving option to open a series of orgmode files
* Ihor Radchenko [2020-11-25 10:17]: > > While I did use qutebrowser many times, did not know about the > > scripts. Please state some examples how you call those external > > scripts. I am interested if: > > - https://www.qutebrowser.org/doc/userscripts.html > - > https://github.com/qutebrowser/experiments/blob/83c2e32bca05023026578ac9b64f7a5938772e9d/misc/userscripts/README.md I can see that Python is reading QUTE FIFO and then sending commands to browser from there. Then I could instruct Emacs to do the same, do you think so? Instead of invoking command from qutebrowser maybe I could invoke it from Emacs? I could make X Window Manager keybinding that invokes Emacs that sends command to qutebrowser to obtain information.
Re: One vs many directories
* Ihor Radchenko [2020-11-26 16:29]: > > Sorry for that vague expression. Let us say I open Completions buffer > > I can switch into it, inspect it, ask for defined keys, evaluate with > > M-:, Emacs allows me to remain in the window and go to other > > window. Agenda buffer does not do that, this is probably because it > > just waits for any key and does not allow anything else. That means I > > will open Agenda and I cannot switch to other window, so I will close > > agenda to switch. Maybe I have 10 TODO keywords, I have to open file, > > I open Agenda again, aha, T... then close agenda, open file see > > keyword, then open agenda again. Repetitions without end and user is > > unable to use multiple windows. This really need not be so. > > It appears to me (correct me if I am wrong) that you haven't tried > agenda multi-occur/keyword/etc searches. I know multi-occur and tried it. Functions of org-agenda are useful while initial menu window of org-agenda is so much less useful and I speak of menu, not of individual functions. If it is Org agenda, I see no reason why it could not be displayed in Org mode being read-only and having buffer not killed when user press q. We spoke of standard Emacs way. Normally buffers are not killed. If I press q in Dired buffer is just buried, not killed. I find Org agenda useful and I would be maybe moving to *Agenda Commands* buffer by using (next-buffer) and (prev-buffer) and those are key bindings like hyper key - move-end-of-line and hyper key - move-beginning of line. It is my standard behavior to move to one buffer and go to other buffer. User could have one tab open for Org agenda menu, other tab for work. Why invoke all time C-c a to access org agenda. I am not speaking for me personally, I am giving you clear comparison of that menu to mu4e or org-agenda menu and other pop-up features that do not block user in using Emacs. Org agenda menu blocks the interface! When invoking package-list-packages it does not block me moving to other buffers and also offers complex menu system and key bindings. Buffer is not killed but burried when I press q. Functions of org agenda are fine, this is reference to blocking of Emacs interface while opening Org agenda buffer. It diminishes usability. I guess nobody cares. It is how it is. No need to consult external references such as https://www.nngroup.com/articles/usability-101-introduction-to-usability/ No need even to look how other parts of Emacs are interacting with user and to harmonize the menu. > > You know how agenda is made like the 1985 BASIC menu in Commodore > > C=64, but even back then there was better interface for such menus. > > FYI. Transient.el - menu dispatcher in popular magit package also does > not let you switch buffers. So, apparently many people would not agree > that it is so terrible design. Compare things to things that are better not to things that are worse. You have to read more about usability. To know what is the problem you have to research and not assume that if nobody says anything that it is usable enough. Nobody complains. I did not hear complain, so it must be perfect. Irony. That is not how interfaces get improved and definitely not how developer would discover if something is wrong. If developer is waiting for somebody to complain that will be too late. Thousands of users will have problems that were not told to developer. Was there any methodology to decide what is good user menu? Reference: https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/ Was there any survey here to ask about any usability?! Hypothetical question. > P.S. Nothing prevents you from calling, i.e. M-x org-occur or binding it > to a key of your choice. Personally I know that. I speak for general usability. You know that I have my system of doing things with or without Org mode.
[PATCH] [C-c C-q] completing tags from both buffer-local and global alist of tags
The default [C-c C-q] completing tags only retrieve tags from current buffer locally. By this patch, will merge both buffer-local tags and user defined global `org-tags-alist`. This is more reasonable. [stardiviner] GPG key ID: 47C32433 IRC(freeenode): stardiviner Twitter: @numbchild Key fingerprint = 9BAA 92BC CDDD B9EF 3B36 CB99 B8C4 B8E5 47C3 2433 Blog: http://stardiviner.github.io/ From c1f88411835f34a8c571547bf8156c98f18d2b2e Mon Sep 17 00:00:00 2001 From: stardiviner Date: Wed, 2 Dec 2020 17:24:29 +0800 Subject: [PATCH] org.el: Complete tags from both global and buffer local * lisp/org.el: (org-fast-tag-selection): merge buffer local tags with global alist of tags. --- lisp/org.el | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 0e12e4b15..0249a43c3 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -12256,10 +12256,11 @@ (defun org-fast-tag-selection (current inherited table &optional todo-table) (condition-case nil (setq tg (completing-read "Tag: " - (or buffer-tags - (with-current-buffer buf - (setq buffer-tags - (org-get-buffer-tags)) + (append (or buffer-tags + (with-current-buffer buf + (setq buffer-tags + (org-get-buffer-tags + (org-global-tags-completion-table (quit (setq tg ""))) (when (string-match "\\S-" tg) (cl-pushnew (list tg) buffer-tags :test #'equal) -- 2.29.2
Re: One vs many directories
* Ihor Radchenko [2020-11-25 14:48]: > > When I do C-c a it runs (org-agenda) but I do not have "g" and I am on > > development version. The C-c a window is made so that I cannot go with > > cursor inside and that I cannot even expect the key map neither invoke > > command by M-x and I cannot even M-: > > C-c a will first show so-called agenda dispatcher asking you what kind > of agenda view you want to get. You need to press a key according to > the popup window (i.e. `t' to see all not done items). Then, you will > get the proper agenda buffer with all the keymaps set and `g' bound to > refreshing the chosen agenda view in the buffer. > > > All that is wrong and not aligned to Emacs common interface. It is bug > > that bugs. Agenda buffer should allow users those standard Emacs > > features. > > I am wondering what is the common Emacs interface you refer to. I am not > aware about any standard way to prompt user while also showing detailed > description of what to expect from different choices. It is maybe not standard, but I never expected in last 20 years to get blocked when having some window as menu in front of me. Please look how mu4e is showing menu and compare: 1. when I open mu4e the menu does not block me to divide screen in 2 windows 2. org-agenda blocks me, it denies me using Emacs interface. This is personally disturbing and makes accessing Org agenda repetitive Observe how C-x C-f tries to find file: 1. it opens minibuffer and does not disturb user to move from minibuffer to other buffer to find references. I often have file names in other buffers and I move to minibuffer to open specific file 2. org-agenda does not allow any movement It is usability question. Personally I do not mind as I am transitioning and using Org files not anymore for planning, rather for documents. Org agenda window shall simply get a focus and be displayed in read-only Org mode with few key bindings invoking those commands. This way both the minibuffer and other windows remain accessible. I have tried to be nice when describing my experience with it. In very kind way I can say that I do not find it usable. Reference: https://www.nngroup.com/articles/usability-101-introduction-to-usability/ For me it was not easy for reason that org-agenda offers 16 different menues and that I cannot keep open org-agenda window and move to other window for references. It requires me to write notes on paper to be able to use org-agenda. When searching for things I often use other window, I do copy and paste into minibuffer, read info files or other buffers. Consider this a bug, and it is already here on the mailing list. Jean
Re: Bug: LaTeX inline maths expression \(+\) wrongly toggles strike-through face
On Wed, Dec 02, 2020 at 03:19:27AM +0100, Firmin Martin wrote:
>
> Consider the following lines:
> - $+$ foobar $+$
> - \[+\] foobar \[+\]
> - $$+$$ foobar $$+$$
> - \(+\) foobar \(+\)
> Each of them is correct LaTeX inline/display maths expressions, but only the
> last one toggles strike-through face when it shouldn't.
>
> Emacs : GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
> 3.24.20, cairo version 1.16.0)
> of 2020-10-16
> Package: Org mode version 9.4 (9.4-53-gc97446-elpa)
That's interesting. Happens to me too -- but I don't understand why
the first thre are /not/ rendered as strike-through. The relevant
variables are
- org-emphasis-regexp-components
in my installation:
org-emphasis-regexp-components is a variable defined in ‘org.el’.
Its value is
("-[:space:]('\"{" "-[:space:].,:!?;'\")}\\[" "[:space:]" "." 5)
Documentation:
Components used to build the regular expression for emphasis.
This is a list with five entries. Terminology: In an emphasis string
like " *strong word* ", we call the initial space PREMATCH, the final
space POSTMATCH, the stars MARKERS, "s" and "d" are BORDER characters
and "trong wor" is the body. The different components in this variable
specify what is allowed/forbidden in each part:
pre Chars allowed as prematch. Beginning of line will be allowed
too.
post Chars allowed as postmatch. End of line will be allowed too.
border The chars *forbidden* as border characters.
body-regexp A regexp like "." to match a body character. Don’t use
non-shy groups here, and don’t allow newline here.
newline The maximum number of newlines allowed in an emphasis exp.
(I changed the value of newline to 5). Note `border' is just "[[:space:]]",
so I'd expect '$', '\' and '$' (for the first three examples) to be "allowed"
borders, and
- org-emph-re
which is calculated from the above, and in my box, not suprprisingly,
is
"\\([-[:space:]('\"{]\\|^\\)\\(\\([*/_+]\\)\\([^[:space:]]\\|[^[:space:]].*?\\(?:
.*?\\)\\{0,5\\}[^[:space:]]\\)\\3\\)\\([-[:space:].,:!?;'\")}\\[]\\|$\\)"
...which would confirm my expectation above. So why are the three
examples not rendered as overstrike? There seems to be more magic
involved.
This happens for other emph markers, too.
To work around in your case, Martin, you could try to add a backslash
to your `org-emphasis-regexp-component's third element, like so:
(setf (nth 3 org-emphasis-regexp-components) "[:space:]")
and reload Org to give it the chance to rebuild org-emph-re.
(Caveat: I didn't try it).
Cheers
- t
signature.asc
Description: Digital signature
generate an org file for today's appointments
Hello, 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. Do you have suggestions to do this? Thanks, Alan signature.asc Description: PGP signature
Re: Remembrance Agents
> The more information user > enters into the database and the more tags and relations have been > created the better the relevance. Isn't the real problem-to-solve finding the actual semantic context and then to relate it matching information? After all, words (TAGS, ...) have different meaning in different semantic contexts. I suspect, 'just' relating to tags (words) and showing the attached document (part) to her is not very useful, yes?
