Re: diary-countdown
Sharon Kimble writes: > In the past this worked > > %%(diary-countdown 4 18 2022 7) Easter Monday Bank Holiday > > But now it doesn't. > > Can somebody help me get it working again please? Could you please elaborate what exactly is not working for you. What did you do? What did you expect to happen? What actually happened? What your Org version? See https://orgmode.org/manual/Feedback.html Best, Ihor
Re: org-cite styles don't allow * in them
"Bruce D'Arcus" writes: >> A less awkward solution (IMO) would be to use an entity like ⋆. It is >> straightforward to add that to the org-element-citation-prefix-re. Then I >> see something like this. > > So Ihor, is there any problem with John's proposed change here? I am not a big fan of using unicode characters, but otherwise I have no objections and no better ideas (except a general desire to solve similar parser issues more generally). However, I am not org-cite's maintainer. So, I would prefer to hear from Nicolas before implementing anything myself. Best, Ihor
Re: Cascading Org-Capture templates
Christophe Schockaert writes: > ... > So, "gM" is related to the second case (2), and I end up with the > following error : "Capture abort: Buffer is read-only: # As you see, I am using Doom Emacs, but I think it’s related with what I > am trying to do anyway. > ... > To me, this goes to the internals of Emacs, and how things work > together, and this is beyond my understanding of the whole picture for > now :) > Maybe, there is also another way to achieve that goal, which I don’t > think about. An important thing you need to know about org-capture is that it is using a global capture state. If you call capture inside capture, unexpected things are going to happen because the recursive call will modify current capture data. I would try to save the value `org-capture-plist' in lisp/cascading-capture and restore it after calling recursive capture. Best, Ihor
Re: What's the flow for adding info: links in Org documents?
On 16/04/2022 10:07, Kaushal Modi wrote:
On Wed, Apr 13, 2022 at 7:38 AM Max Nikulin wrote:
For export to html produces the following link:
https://www.gnu.org/software/emacs/manual/html_mono/emacs.html#Browse_002dURL
I think, a better variant is
https://www.gnu.org/software/emacs/manual/html_node/emacs/Browse_002dURL.html
even though for the Org manual I often prefer single-page HTML version.
Thanks for your feedback! I absorbed almost all of it into ox-hugo and
wrote about it in a followup blog post:
https://scripter.co/improving-ox-hugo-exported-org-info-links/.
I hope to see similar changes in ol-info.el as well. I appreciate your
activity since it allows to test such feature and to choose better
variant of its implementation.
I wanted the link descriptions in the exported markdown to be
more“English” and understandable to people not familiar with the
Emacs Info interface. So I decided to keep this mostly unchanged ..
From my point of view, references like (info "(org) Top") resembles
scholar citations and does not harm. Citations are used for a lot of
time with established language constructs. The only thing I do not like
is the nested parenthesis. Traditions hypertext formatting is different
though. I believe, your variant is acceptable since it allows to realize
whether linked document is known to the reader. It is much better than
"here" links or series of links hidden behind of words of some
statement. What I am looking for is something like man(1) that became
standard way to mention man pages.
https://blog.tecosaur.com/tmio/2021-07-31-citations.html
I did not change the link description, but I did add a new HTML title
attribute to the link. This attribute contains the Emacs Lisp code
needed to access the Info manual from Emacs. … Of course, the user will
still not be able to copy that text and paste in Emacs. But it will
still provide them enough hint on how to access Info nodes in Emacs.
Your decision is certainly better than a multistep recipe from "emacs
--help": "Run M-x info RET m emacs RET m emacs invocation RET inside
Emacs to read the main documentation for these command-line arguments."
At some moment I got tired of aggressive kindness of sites using
relative timestamps in text and put full timestamps to titles. I created
a browser extension that tries to extract text from title, alt and some
other attributes:
https://addons.mozilla.org/firefox/addon/altcopy/
I was disappointed when I discovered that e.g. bugzilla has some
countermeasures and may temporary remove title in response to right click...
Back to info links. I am curious if it is possible to implement handlers
for particular URLs to allow users to choose whether they would like to
open a web page or a local application. It is doable on Android, but I
am unsure concerning regular desktop environments since I never tried to
do it. Mozilla promised to not remove intercepting network request
handlers from manifest v3 add-ons, but I would prefer declarative
approach. Certainly it will require either desktop-wide scheme handler
of info links or a native messaging helper.
For a while I spent some time experimenting with per-link switch to
choose its representation.
- It should work with disabled JavaScript.
- It should allow keyboard navigation.
I learned a trick from Timothy when he was redesigning Org site.
Unfortunately the approach adds some noise for text-only browsers
ignoring CSS (eww, etc.). I am unsure concerning accessibility and
convenience to screen reader users and proper aria attributes. Even
appearance in regular browsers should be tuned, e.g. to use some icons
instead of text and to make the element recognizable as a switch:
https://orgmode.org/manual/Working-with-Source-Code.html";
>info "(org) Working with Source Code"
.
.link-alternate > input.link-switch-nojs {
appearance: none;
width: 6em;
font-size: 1ex;
border-color: blue;
border-width: 2px;
border-radius: 20%;
}
.link-alternate > input.link-switch-nojs::after,
.link-alternate > input.link-switch-nojs::before {
padding: 2px;
}
/* ::before can not be styled for :checked state */
.link-alternate > input.link-switch-nojs::before {
content: "Web";
vertical-align: super;
}
.link-alternate > input.link-switch-nojs::after {
content: "Info";
vertical-align: sub;
}
.link-alternate > input.link-switch-nojs:not(:checked) {
border-top-style: solid;
border-left-style: solid;
}
.link-alternate > input.link-switch-nojs:checked {
border-bottom-style: solid;
border-right-style: solid;
}
I have tried "" but it does not allow to hide checkbox input
element using "display: none" otherwise it works with mouse only.
Moreover, styling through content CSS property, the text is skipped
during selection. It seems, radio inputs have no advantages in this case.
Re: org-cite styles don't allow * in them
I am also not a fan of using Unicode here and prefer a simple ascii asterisk. That works fine for me so far, but I am not a heavy user of bold markup and citations. As I mentioned there is the same problem for links, and in the last 10 years I can’t recall an issue being reported with bold. On Sun, Apr 17, 2022 at 4:41 AM Ihor Radchenko wrote: > "Bruce D'Arcus" writes: > > >> A less awkward solution (IMO) would be to use an entity like ⋆. It is > >> straightforward to add that to the org-element-citation-prefix-re. Then > I > >> see something like this. > > > > So Ihor, is there any problem with John's proposed change here? > > I am not a big fan of using unicode characters, but otherwise I have no > objections and no better ideas (except a general desire to solve similar > parser issues more generally). > > However, I am not org-cite's maintainer. So, I would prefer to hear from > Nicolas before implementing anything myself. > > Best, > Ihor > -- John --- Professor John Kitchin (he/him/his) Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu
Re: org-cite styles don't allow * in them
John Kitchin writes: > I am also not a fan of using Unicode here and prefer a simple ascii > asterisk. That works fine for me so far, but I am not a heavy user of bold > markup and citations. What about something like [cite/citet*/:@key]? "*/" is not recognised as bold ending. > As I mentioned there is the same problem for links, and in the last 10 > years I can’t recall an issue being reported with bold. This is because links containing "\\*[ -.,;:!?'")}\\[]" match are extremely rare. In contrast, [cite/citet*:@key] is likely to be used fairly frequently and has much higher chance to break things. Best, Ihor
Re: org-cite styles don't allow * in them
On Sun, Apr 17, 2022 at 9:18 AM Ihor Radchenko wrote: > John Kitchin writes: > > > I am also not a fan of using Unicode here and prefer a simple ascii > > asterisk. That works fine for me so far, but I am not a heavy user of > bold > > markup and citations. > > What about something like [cite/citet*/:@key]? > "*/" is not recognised as bold ending. That is a great solution when you want to have bold, and it would be optional if you don’t use bold there. You still would need to add * to the cite pattern. > > > > As I mentioned there is the same problem for links, and in the last 10 > > years I can’t recall an issue being reported with bold. > > This is because links containing "\\*[ -.,;:!?'")}\\[]" match are > extremely rare. > > In contrast, [cite/citet*:@key] is likely to be used fairly frequently > and has much higher chance to break things. We have had a citet*:key link (and all the other * variants) for a long time in org-ref, with no reported issues I can recall. > > Best, > Ihor > > -- John --- Professor John Kitchin (he/him/his) Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu
Re: Local visibility makes header always visible
Would you consider this as a bug? On Sat, Apr 09, 2022 at 09:27:36PM +0100, Eduardo Suarez wrote: > Say next org file, where I want the content of entry ABA not to be shown (e.g. > because it is not important). > > --- BEGIN ORG FILE --- > #+STARTUP: content > * A > ** AA > ** AB > *** ABA > :PROPERTIES: > :VISIBILITY: folded > :END: > ABAA > ABAB > ABAC > ** AC > * B > * C > --- END ORG FILE > > This works as expected an entries ABAA, ABAB and ABAC are not shown at > startup. > > However, if I change startup visibility from 'content' to 'overview', I would > expect only first level headers to be shown. However, what I get is: > > --- BEGIN ORG BUFFER (VISIBLE) --- > #+STARTUP: overview > * A... > ** AB > *** ABA... > * B > * C > --- END ORG BUFFER (VISIBLE) --- > > Is this intended behaviour? >
