Re: [PATCH] Improve docstrings of agenda date navigation commands
Stefan Kangas [2022-06-20 Mon 17:54] wrote: > I found the docstrings of the agenda date navigation commands to be somewhat > lacking. The attached patch expands them > slightly and adds crossreferences, which I think makes them much more usable. > Thanks. Thanks, looks good. Merged at e7e37c5b2. Best, -- Daniel Fleischer
Re: exporting to mediawiki syntax math is not converted
>>> "IR" == Ihor Radchenko writes: > Uwe Brauer writes: >>> See org-html-with-latex. We use mathjax syntax for LaTeX export by >>> default >> >> I see, but that means, the exported wiki cannot be used say for >> wikipedia since it uses mediawiki syntax for math. >> >> Does anybody knows about a 3rd party package providing support for mediawiki? > You just need a custom export filter for latex fragments in > org-export-filter-latex-fragment-functions. > Or, if you think that mediawiki math export is common enough, we may > implement mediawiki support as an additional option in > org-html-with-latex. But we will need other people to voice their > support. Fair enough. Meanwhile I got ox-pandoc to work (although I still use pandoc 1.9 and it requires 2.X) and indeed it has an export option for mediawiki and the math is correctly converted. So for me that is fine, but maybe others, who can't use pandoc might want mediawiki support? smime.p7s Description: S/MIME cryptographic signature
Re: ox-latex table tabbing support.
Hi Bob, Thank you very much for the patch. It was merged to master in 4a0d951c. Also, you were added to the orgmode contributes at https://orgmode.org/worg/contributors.html. Thanks for the contribution. Best, -- Daniel Fleischer
Re: exporting to mediawiki syntax math is not converted
Uwe Brauer writes: >> See org-html-with-latex. We use mathjax syntax for LaTeX export by >> default > > I see, but that means, the exported wiki cannot be used say for > wikipedia since it uses mediawiki syntax for math. > > Does anybody knows about a 3rd party package providing support for mediawiki? You just need a custom export filter for latex fragments in org-export-filter-latex-fragment-functions. Or, if you think that mediawiki math export is common enough, we may implement mediawiki support as an additional option in org-html-with-latex. But we will need other people to voice their support. Best, Ihor
Re: exporting to mediawiki syntax math is not converted
>>> "IR" == Ihor Radchenko writes: > Uwe Brauer writes: >> The following line >> >> >> torus $\mathbb T^3$ in the Sobolev spaces $H^m(\mathbb T^3)$. >> >> Is translated to >> >> torus \(\mathbb T^3\) in the Sobolev spaces \(H^m(\mathbb T^3)\) >> >> Instead of >> >> torus \mathbb T^3 in the Sobolev spaces H^m(\mathbb >> T^3) >> >> Is this a missing feature, or do I miss something here? > See org-html-with-latex. We use mathjax syntax for LaTeX export by > default I see, but that means, the exported wiki cannot be used say for wikipedia since it uses mediawiki syntax for math. Does anybody knows about a 3rd party package providing support for mediawiki? I realized that pandoc supports mediawiki, but I don't need a new file I just want to save into a buffer. I have to think about it. smime.p7s Description: S/MIME cryptographic signature
Re: Proposal: 'executable' org-capture-templaes
Max Nikulin writes: > Consider the following case. A user has 2 virtual desktops dedicated to > rather independent tasks and an Emacs frame on each desktop. On desktop > 1 she opens help for some function with aim to evaluate if it is > appropriate for some particular purpose. Next she has to switch to > another task and applications for it reside on virtual desktop 2. To > proceed further she has to read several help pages relevant for task 2. > After completion of this task it is time to resume task 1 and to switch > to virtual desktop 1. Does a window with the help buffer still display > the same content as before switching to task 2? No, context on desktop 1 > lost due to some actions in the Emacs frame on desktop 2. > > Such synchronization is against multitasking and I do not like the idea > to get it for org-capture as well. Currently read-key and modal prompt > is a kind of excuse, but the idea of new menu library is non-blocking > keymap-based selection. I understand. >From the perspective of the library being discussed, what you want does not look impossible. The other question is altering the org-capture code. I think that it is too early to discuss org-capture part just yet. Lets first finalize the generic library itself and discuss the appropriate adjustments to org-capture/org-agenda/org-export/org-todo/etc code later. Best, Ihor
Re: [PATCH] Persistently save downloaded inline remote images
Jack Kamm writes: > Therefore, I am canceling the help request (or rather, attempting to > cancel it with Woof -- this is my first time using Woof like this, so > apologies in advance if it doesn't work). Thanks for taking care of this! > This help request is old, and also it was never clear what concrete > enhancement was desirable, or what specific problem there was with the > existing cacheing mechanism. So I think it just adds noise to > updates.orgmode.org. As an update from the time this patch has been submitted, we now have org-persist library that allow caching downloaded files, as one of the possibilities. Such caching is already being used during export. See 6ee45518f. Best, Ihor
Re: oc-basic: CSL-JSON year as number vs. string (nativecomp?)
David Lukeš writes: >> Would you mind creating a patch and possibly supplying a test >> that will make sure that the example file and similar are correctly >> parsed? > > I'm attaching a patch (just the patch for now, no commit message), let > me know what you think, in particular the error message. What would be > an acceptable way to wrap the format string? LGTM! There is no need to wrap the format string. > As for tests -- if `oc-basic.el` already had some, I'd try to see if I > can come up with something by analogy. But as it stands, I know too > little about Elisp, nothing about Elisp testing, and have too little > spare time, sorry :( No problem. Your patch is already helpful. Best, Ihor
Re: exporting to mediawiki syntax math is not converted
Uwe Brauer writes: > The following line > > > torus $\mathbb T^3$ in the Sobolev spaces $H^m(\mathbb T^3)$. > > Is translated to > > torus \(\mathbb T^3\) in the Sobolev spaces \(H^m(\mathbb T^3)\) > > Instead of > > torus \mathbb T^3 in the Sobolev spaces H^m(\mathbb > T^3) > > Is this a missing feature, or do I miss something here? See org-html-with-latex. We use mathjax syntax for LaTeX export by default Best, Ihor
Re: Org and Hyperbole
Juan Manuel Macías writes: > I've been intrigued with GNU Hyperbole for a while. I'm reading the > documentation and trying it out a bit. It seems that its button system > is very powerful. But Org links are also powerful (and exportable), and > can be extended outside of Org docs. It seems that hyperbole offers some > cool stuff that Org also has. And other things that are not in Org. I > find some parts a bit confusing. I wonder if anyone is using hyperbole > with Org and can put here some minimal workflow example where both > complement each other in some way. Just in case I'm missing something > useful... I haven't touched Hyperbole in ...decades...? Even then, it was complicated and full-featured (but I still keep it in my .emacs file). My discussions with Bob Weiner were interesting at the time and I really wanted to make use of it. As you've discovered, it integrates a lot of what Org has in, perhaps, a tighter fashion (which makes it more complicated, but the pain might be useful). The Smart Keys and Buttons are very similar to Org. The outliner (KOutline) is more powerful than Org, but not integrated with export capabilities to other formats (I think there is a way of exporting an outline to Org). Something that Org does not have is browsing capabilities for Object Oriented languages. This is an add-on (for C++ ?) in Hyperbole (search for OO-Browser). Since I retired, I don't do much programming, so Org's project management has been more interesting to me. It's nice to see that it's actually still being developed by Bob. -- David Masterson
Re: [BUG] Editing link hides text
"Samuel Banya" writes: > Confirmed with 'emacs -Q -L ./lisp/ -l org' on latest version of Org. > > @Ihor, can you help push me in the right direction in terms of where in the > codebase this issue might lie, so that I can examine the related section > myself, and also bug a related maintainer about this? It is most likely a bug with org-fold-catch-invisible-edits and org-fold-check-before-invisible-edit. And it is likely related to fontification code, which may be tricky. I am the related maintainer :) Best, Ihor
[PATCH] Re: [BUG] Adding note to heading without newline at the end
Tor Kringeland writes: > Ihor Radchenko writes: > >> Can you reproduce the problem starting from emacs -Q? > > I did. The bug only occurs if there is no newline at the end. So for > example if you open a new buffer and don't save it, the bug should > occur. Aha. Not saving is an important piece of information. (said the person with compulsive saving syndrome) Can you test the attached patch? Best, Ihor >From 7c40a003166c9ab8f5f034b8bb6d506ed2b8b62f Mon Sep 17 00:00:00 2001 Message-Id: <7c40a003166c9ab8f5f034b8bb6d506ed2b8b62f.1655778085.git.yanta...@gmail.com> From: Ihor Radchenko Date: Tue, 21 Jun 2022 10:18:58 +0800 Subject: [PATCH] org-log-beginning: Fix for headline at eob with no trailing newline * lisp/org.el (org-log-beginning): Fix edge case when there is a headline at the end of buffer and that headline does not have a trailing newline. Fixes https://orgmode.org/list/m24k0ffjyd@ntnu.no --- lisp/org.el | 17 +++-- 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 220210992..78f51f9ad 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -10121,12 +10121,17 @@ (defun org-log-beginning ( create) (end-of-line -1 (t (org-end-of-meta-data org-log-state-notes-insert-after-drawers) - (skip-chars-forward " \t\n") - (beginning-of-line) - (unless org-log-states-order-reversed - (org-skip-over-state-notes) - (skip-chars-backward " \t\n") - (beginning-of-line 2) + (let ((endpos (point))) + (skip-chars-forward " \t\n") + (beginning-of-line) + (unless org-log-states-order-reversed + (org-skip-over-state-notes) + (skip-chars-backward " \t\n") + (beginning-of-line 2)) + ;; When current headline is at the end of buffer and does not + ;; end with trailing newline the above can move to the + ;; beginning of the headline. + (when (< (point) endpos)) (goto-char endpos) (if (bolp) (point) (line-beginning-position 2 (defun org-add-log-setup ( purpose state prev-state how extra) -- 2.35.1
Re: [BUG] Adding note to heading without newline at the end
Samuel Banya writes: > Unable to reproduce this bug with 'emacs -Q -L ./lisp -l org' on the > latest version of Org Mode Hmm ... this occurs to me both in Org 9.5 and in the latest Org version on Emacs 29. The error message I get says Before first headline at position 1 in buffer test.org However if there is a heading above the one I try to insert the note for (and the current heading is at the last line in the buffer, with no newline at the end), I do not get an error message, but the same bug occurs. FWIW I get the same error message if I try to insert a note in an Org buffer without headings. Maybe the heading isn't properly registered when it is at the last line in the buffer (again without a newline at the end)?
Re: [BUG] Editing link hides text
Confirmed with 'emacs -Q -L ./lisp/ -l org' on latest version of Org. @Ihor, can you help push me in the right direction in terms of where in the codebase this issue might lie, so that I can examine the related section myself, and also bug a related maintainer about this? Thanks, Sam On Mon, Jun 20, 2022, at 10:14 PM, Tor Kringeland wrote: > Using Org 9.6 with Emacs 29, write a link: > > [[123][test]] > > Most of the text will then be hidden, with "test" showing as a link, as > expected. However if I remove the last ], the link highlighting > disappears and only "test" is shown like regular text (/i.e./ instead of > "[[123][test]" as would be expected). If I insert a character at the > end or move the text, it is updated and "[[123][test]" shows as > expected. > > (This bug does not occur in Org 9.5 for me.) >
Re: Newbie Question With Responding To Bug Threads
Forgot to mention that utilizing the 'mail to' link worked just fine. On Mon, Jun 20, 2022, at 10:09 PM, Samuel Banya wrote: > Nevermind, it just took some time to send out. It totally worked, super cool: > https://list.orgmode.org/orgmode/87fsjyzsm6@fastmail.com/ > > First bug touched, but couldn't confirm it actually exists lol :/ > > Got to start somewhere :) > > Sincerely, > > Sam > > On Mon, Jun 20, 2022, at 10:08 PM, Samuel Banya wrote: >> So I finally got around to watching Igor's great video on how to try to >> reproduce Emacs bugs using a minimal configuration, etc: >> >> With this in mind, I took a look at the related list: >> https://list.orgmode.org/orgmode >> >> I then found this particular bug: >> https://list.orgmode.org/orgmode/m2ilowp4br@ntnu.no/ >> >> I then went through the motions as dictated by Igor's video. Ultimately, I >> was unable to reproduce the bug. I noted the instructions with the 'Reply >> Instructions' section. >> >> I clicked the link which opened up a related Emacs buffer to which I pretty >> much replied that I couldn't reproduce the issue. >> >> I then hit C-c C-c which apparently sent the email. However, I checked the >> bug itself, but cannot find my reply message present, and am wondering if it >> actually was sent at all. I personally had 'gnus' configured at one point >> but barely use it because I found it to be super awkward and clunky, and >> just not friendly to use in comparison so I just use the GUI client for >> Fastmail these days. >> >> Here is my output of my '*Messages*' buffer in relation to this issue: >> Sending... >> Sending via mail... >> Sending email >> Sending email done >> Sending...done >> >> Questions: >> Q1. Is it possible to reply to bug threads like this within a GUI email >> client like Fastmail? >> >> Q2. Or is this only possible to directly reply to email threads if you're >> using mail clients like 'mu-4e', 'notmuch' etc? >> >> I ask because I'll work on my email setup accordingly if that is the case >> where just a GUI client isn't sufficient as I was planning to use 'notmuch' >> eventually anyway, but wanted to confirm this before putting in the effort >> to do so. >> >> The only thing I found was this article by Fastmail, but don't know if this >> would actually work with just the web browser client of Fastmail I use in >> Firefox: >> https://www.fastmail.help/hc/en-us/articles/360058753594-Import-your-mail >> >> Thanks, >> >> Sam >
[BUG] Editing link hides text
Using Org 9.6 with Emacs 29, write a link: [[123][test]] Most of the text will then be hidden, with "test" showing as a link, as expected. However if I remove the last ], the link highlighting disappears and only "test" is shown like regular text (/i.e./ instead of "[[123][test]" as would be expected). If I insert a character at the end or move the text, it is updated and "[[123][test]" shows as expected. (This bug does not occur in Org 9.5 for me.)
Re: Newbie Question With Responding To Bug Threads
Nevermind, it just took some time to send out. It totally worked, super cool: https://list.orgmode.org/orgmode/87fsjyzsm6@fastmail.com/ First bug touched, but couldn't confirm it actually exists lol :/ Got to start somewhere :) Sincerely, Sam On Mon, Jun 20, 2022, at 10:08 PM, Samuel Banya wrote: > So I finally got around to watching Igor's great video on how to try to > reproduce Emacs bugs using a minimal configuration, etc: > > With this in mind, I took a look at the related list: > https://list.orgmode.org/orgmode > > I then found this particular bug: > https://list.orgmode.org/orgmode/m2ilowp4br@ntnu.no/ > > I then went through the motions as dictated by Igor's video. Ultimately, I > was unable to reproduce the bug. I noted the instructions with the 'Reply > Instructions' section. > > I clicked the link which opened up a related Emacs buffer to which I pretty > much replied that I couldn't reproduce the issue. > > I then hit C-c C-c which apparently sent the email. However, I checked the > bug itself, but cannot find my reply message present, and am wondering if it > actually was sent at all. I personally had 'gnus' configured at one point but > barely use it because I found it to be super awkward and clunky, and just not > friendly to use in comparison so I just use the GUI client for Fastmail these > days. > > Here is my output of my '*Messages*' buffer in relation to this issue: > Sending... > Sending via mail... > Sending email > Sending email done > Sending...done > > Questions: > Q1. Is it possible to reply to bug threads like this within a GUI email > client like Fastmail? > > Q2. Or is this only possible to directly reply to email threads if you're > using mail clients like 'mu-4e', 'notmuch' etc? > > I ask because I'll work on my email setup accordingly if that is the case > where just a GUI client isn't sufficient as I was planning to use 'notmuch' > eventually anyway, but wanted to confirm this before putting in the effort to > do so. > > The only thing I found was this article by Fastmail, but don't know if this > would actually work with just the web browser client of Fastmail I use in > Firefox: > https://www.fastmail.help/hc/en-us/articles/360058753594-Import-your-mail > > Thanks, > > Sam
Newbie Question With Responding To Bug Threads
So I finally got around to watching Igor's great video on how to try to reproduce Emacs bugs using a minimal configuration, etc: With this in mind, I took a look at the related list: https://list.orgmode.org/orgmode I then found this particular bug: https://list.orgmode.org/orgmode/m2ilowp4br@ntnu.no/ I then went through the motions as dictated by Igor's video. Ultimately, I was unable to reproduce the bug. I noted the instructions with the 'Reply Instructions' section. I clicked the link which opened up a related Emacs buffer to which I pretty much replied that I couldn't reproduce the issue. I then hit C-c C-c which apparently sent the email. However, I checked the bug itself, but cannot find my reply message present, and am wondering if it actually was sent at all. I personally had 'gnus' configured at one point but barely use it because I found it to be super awkward and clunky, and just not friendly to use in comparison so I just use the GUI client for Fastmail these days. Here is my output of my '*Messages*' buffer in relation to this issue: Sending... Sending via mail... Sending email Sending email done Sending...done Questions: Q1. Is it possible to reply to bug threads like this within a GUI email client like Fastmail? Q2. Or is this only possible to directly reply to email threads if you're using mail clients like 'mu-4e', 'notmuch' etc? I ask because I'll work on my email setup accordingly if that is the case where just a GUI client isn't sufficient as I was planning to use 'notmuch' eventually anyway, but wanted to confirm this before putting in the effort to do so. The only thing I found was this article by Fastmail, but don't know if this would actually work with just the web browser client of Fastmail I use in Firefox: https://www.fastmail.help/hc/en-us/articles/360058753594-Import-your-mail Thanks, Sam
Re: [BUG] Adding note to heading without newline at the end
Unable to reproduce this bug with 'emacs -Q -L ./lisp -l org' on the latest version of Org Mode
Re: [BUG] org-agenda-skip fails in batch mode because comment-start-skip is nil
Ihor Radchenko writes:
> Could you please provide a detailed reproducer?
Sure. I have attached the files "mwe-data.org" and "mwe-export.org".
To reproduce, save both files in the same directory. Then open mwe-export.org,
navigate to the "Export script" heading, and evaluate (Ctrl-C Ctrl-C) the shell
source block.
Expected output: a generated html file containing the fruits and vegetables
from the mwe-data.org file.
Actual output: Lisp error: (wrong-type-argument stringp nil), details as in my
first message.
Compare on the other hand if you navigate to the "Fruits and vegetables"
heading and evaluate the emacs-lisp code block, it outputs a list of fruits and
vegetables in a results drawer.
> org-agenda-skip should be operating after org-agenda-prepare-buffers,
> which, in turn, should call org-mode. org-mode calls
> org-setup-comments-handling which must set comment-start-skip to
> non-nil.
OK, thanks for the insight. I haven't figured out where things are going wrong.
But a possibly related issue is that lately, when I open an org file for the
first time, org-mode does not load automatically. If I close the file and
reopen, org-mode loads as expected.
Best regards,
Asilata
* Fruits
** Apple
** Banana
** Cantaloupe
* Vegetables
** Asparagus
** Broccoli
** Cabbage
#+title: MWE for testing org-agenda-skip bug
#+author: Asilata Bapat
#+options: toc:nil
* Fruits and vegetables
#+begin_src emacs-lisp :results value drawer :exports results
(defun show-title ()
(let ((title (org-entry-get nil "ITEM")))
(format "- %s" title)))
(string-join
(org-map-entries
'show-title
"LEVEL=2"
'("mwe-data.org"))
"\n")
#+end_src
* Export script :noexport:
#+begin_src shell :results silent
emacs --batch --visit "mwe-export.org" --eval '(require (quote org))' --eval '(setq org-confirm-babel-evaluate nil)' --eval '(org-html-export-to-html)'
#+end_src
signature.asc
Description: PGP signature
Re: Org and Hyperbole
Russell Adams writes: > On Mon, Jun 20, 2022 at 02:03:15PM +, Juan Manuel Macías wrote: >> I've been intrigued with GNU Hyperbole for a while. I'm reading the >> documentation and trying it out a bit. It seems that its button system >> is very powerful. But Org links are also powerful (and exportable), and >> can be extended outside of Org docs. It seems that hyperbole offers some >> cool stuff that Org also has. And other things that are not in Org. I >> find some parts a bit confusing. I wonder if anyone is using hyperbole >> with Org and can put here some minimal workflow example where both >> complement each other in some way. Just in case I'm missing something >> useful... > > Juan, > > I've often wondered the same thing. I've looked at Hyperbole several > times. They have been great at advertising when a new release > occurs. Yet I find that I can't really find a useful feature in it > that I don't get from Org-mode. > > Is there some keen feature I'm missing? What's the use case for > Hyperbole if you're already an Org-mode user? > > https://www.adamsinfoserv.com/ My experiences with it mirror yours. It looked interesting and there were some ideas which sounded interesting, but when I came to use it, I found little, if anything, which didn't have a close equivalence in org mode and many things in org mode which it did not have. In the end, it came down to asking myself do I really want yet another information management framework in my life and the answer was no. I do vaguely recall (it was a while ago) there were some ideas I thought would be good to add to org mode though. Unfortunately, I cannot recall the details now.
Re: About 'inline special blocks'
Max Nikulin writes: > On 19/06/2022 19:47, Juan Manuel Macías wrote: > Concerning vs. , is it the same for assistive > technologies like screen readers to add text (or text) > and text with "font-weight: bolder;" in CSS? First, never use or , only use semantic tags for accessibility. The question unfortunately has a complicated answer. Basically, and are the two tags which have no semantic meaning. So, from an accessibility perspective, they don't convey anything. They are basically a presentation layout tgag. However, this is not a bad thing, but rather a very good thing. This touches on the area where far too many people get accessibility wrong. It is like the very misguided rule which says all images must have an alt tag. The key point to consider is whether what your communicating via layout has any real use for someone using a screen reader. Consider something like #+being_src Section Title Some Content wrapped within multiple section elements. ... #+end_src The inner is being used to avoid using a in the mistaken belief that using a (or ) would be bad for accessibility. Unfortunately, the above wil often result in the screen reader reading out "Seciton section section SOme content" (some screen readers would ignore the inner section as it has no aria tag). Same sort of problem occurred with the rule about images must have an 'alt' tag. I cannot count the number of pages I visit where the screen reader says "logo logo filler righ pad left pad filler logo brand". So, the span tag is great for accessibility when what the author is trying to convey is layout information or styling information which is of no use to blind or VI users. Often such style emphasis is used to assist sighted users who can quickly scan the page. Blind and VI users cannot scan in the same way. What is more important for us is the ability to get an overview of the semantic content of the page - sections, table, lists etc. Sadly, org isn't great from an accessibility perspective. This is something I would like to see improved, but it is a huge and complex task. There are some 'easy' winds we could try. For example, org still defaults to using the and tags instead of and . Likewise, we should move to html5 as the default, not xhtml, but last time I raised that, there was considerable push back to stick with xhtml. We also need complete overhaul of the use of aria tags and numerous other areas. As I said, a very large job which is complex and extremely time consuming. Sadly, I'm not sure there is a lot we can do with accessibility and PDFs in org mode. This is the one area where TeX/LaTeX does a poor job. Last time I looked, there was considerable discussion about what to do from an accessibility standpoint in the TeX community, but seemed to be little or very slow progress (not a criticism of the efforts of members of that community, but rather a reflection of how complicated this stuff is).
Re: Org and Hyperbole
Hi all,
Thank you very much for your comments and contributions in this thread
about Org & hyperbole, which have helped me a lot to position myself.
Certainly, for the short time I've been using hyperbole, it has me
baffled. It's like someone grabbed all the tools that could be useful
ten minutes before the zombie apocalypse starts. There's all the buttons
stuff, but also a feature to expand regions in a style similar to the
expand-region package, which I use a lot, by the way. And also features
to write emails, store contacts, execute searches, a buffer and frame
control system (this in particular is what most caught my attention
about hiperbole and what I am using the most, since it has some very
useful functionalities). The implicit and explicit buttons system is
certainly powerful, but I don't think it will surprise the average Org
user much in this regard.
I think that Eduardo Ochs's description ("Hyperbole is meant to be used,
not to be hacked") is quite accurate. On the other hand, I find the
hyperbole menu (C-h h) very confusing and ugly. I think it would have
gained in cleanliness if they had used transient.
It seems that the hyperbole developers put a commendable and honest
effort into introducing hyperbole to users. But I perceive that
something is failing in the communication. I suspect that hyperbole is
an attempt to establish synaptic relationships between Emacs documents
and buffers. But that is also what is sought with Org. Without wishing
to make comparisons (because, as I say, my knowledge of hyperbole is
extremely limited) I would say that there is an important difference
between org and hyperbole. Both are huge, and both are complex, and both
are packed with features. But in Org there is a coherent and consistent
language that ties everything together: once you learn how to ask for a
glass of water in the org dialect (something you can do from day one),
it doesn't take long to start more complex conversations. In hiperbole I
don't just see that language that gives consistency to everything, that
"org-style". Or at least it's not so obvious to me. But I'll keep giving
it a chance. The whole window configuration control part is extremely
interesting to me.
Best regards,
Juan Manuel
Re: [PATCH] Persistently save downloaded inline remote images
Canceled. > I just added a call for help about this. Thanks! This help request is old, and also it was never clear what concrete enhancement was desirable, or what specific problem there was with the existing cacheing mechanism. So I think it just adds noise to updates.orgmode.org. Therefore, I am canceling the help request (or rather, attempting to cancel it with Woof -- this is my first time using Woof like this, so apologies in advance if it doesn't work).
Re: About 'inline special blocks'
Max Nikulin writes:
Hi Maxim,
Max Nikulin writes:
> I would like to stress that styles can not be a rescue in some
> important cases. Let's leave aside ad hoc final tuning of formatting.
> In the case of HTML export there are still and
> attributes that are namely
> per-object, not part of style.
You are right, but my question is: Could there be a similar use case
within inline special blocks? Keep in mind that this (for now,
hypothetical) element type would be intended only for very short
segments of text within the paragraph. I don't find a scenario where
it's worth overloading that with options and attributes, IMHO.
I believe that direct formatting (as a rule of composition and not as an
exception), which comes ---I suppose--- from the use and abuse of word
processors, is the great cancer for the consistency of the documents,
where a guiding style and a series of constants must prevail. Of course,
I do not deny that it is often necessary to do a post-process and adjust
exceptions. There are always exceptions. In the case of LaTeX and
ConTeXt, TeX is powerful enough to deal with exceptions also at a high
level, due to its high degree of automation. And LuaTeX, even more so. A
simple example to automatically adjust the width of the caption in
figures with a simple lua function in LuaLaTeX:
#+begin_src latex
\begin{luacode*}
function caption_width ( text )
text = string.gsub ( text, "(\\includegraphics.+)", "\\sbox0{%1}")
text = string.gsub ( text, "(\\caption{.+})",
"\\begin{minipage}{\\wd0}\\usebox0%1\\end{minipage}")
return text
end
\end{luacode*}
\newcommand\CaptionAutoWidth{\directlua{luatexbase.add_to_callback
( "process_input_buffer" , caption_width , "caption_width" )}}
\AtBeginDocument{\CaptionAutoWidth}
#+end_src
However, note that I speak in general terms. It is difficult to get rid
of manual intervention one hundred percent. But the question is whether
it's worth adding fine-tuning options to an element as "specialized" as
inline special blocks. Of course, LaTeX is more flexible and you can
always change a variable on the fly. You can do something like:
#+begin_src latex
\definecolor{foo}{HTML}{FF}
\definecolor{var}{HTML}{7CFC00}
\def\mycolor{foo}
\newcommand\mytextcolor[1]{%
\textcolor{\mycolor}{#1}}
\begin{document}
lorem \mytextcolor{ipsum dolor}
\def\mycolor{var}
lorem \mytextcolor{ipsum dolor}
#+end_src
html/css seems more rigid and I'm not that familiar with it. Perhaps
there is more uses case where the existence of ad hoc attributes and
options would be justified? And, in any case, how to implement it
without the paragraph becoming unreadable? The solution that Ihor
commented on in a past post of using identifiers for each inline block
would be fine (and maybe it could be used also for the attributes of the
links within the paragraph).
>> in html:
>> contents>
>
> Concerning vs. , is it the same for
> assistive technologies like screen readers to add
> text (or text) and class="strong">text with "font-weight: bolder;" in CSS?
"contents>": it was my confusion, sorry. I already explained
it here: https://list.orgmode.org/8735g0tnoh@posteo.net/
Best regards,
Juan Manuel
Re: Proposal: 'executable' org-capture-templaes
On 20/06/2022 19:10, Ihor Radchenko wrote: Max Nikulin writes: Sure. I was hinting about such functionality in the new library we are discussing. Multiple capture menus are not possible now anyway, so it will be a new feature if we decide that we need it (I am not 100% sure if having multiple menus is not going to be confusing). In my opinion application logic should be consistent with UI. Do you think current behavior of help buffers has no problems? If so I have no chance to convince you that upgrade of menu should be accompanied by changes in org-capture. Consider the following case. A user has 2 virtual desktops dedicated to rather independent tasks and an Emacs frame on each desktop. On desktop 1 she opens help for some function with aim to evaluate if it is appropriate for some particular purpose. Next she has to switch to another task and applications for it reside on virtual desktop 2. To proceed further she has to read several help pages relevant for task 2. After completion of this task it is time to resume task 1 and to switch to virtual desktop 1. Does a window with the help buffer still display the same content as before switching to task 2? No, context on desktop 1 lost due to some actions in the Emacs frame on desktop 2. Such synchronization is against multitasking and I do not like the idea to get it for org-capture as well. Currently read-key and modal prompt is a kind of excuse, but the idea of new menu library is non-blocking keymap-based selection. Currently several capture menu instances may be requested though org-protocol (or calling org-capture from emacsclient). The behavior is rather confusing. New menu may help to fix the issue, that is why I raised the question about parallel captures. I am not sure which behavior you have in mind. try the following commands without selecting a template in an Emacs frame in between emacsclient 'org-protocol:/capture?url=url-A=title-A=body=A' emacsclient 'org-protocol:/capture?url=url-B=title-B=body=B' What I was thinking as a conservative implementation that would not introduce any new features is replacing the old menu with the new one every time the same menu is called. So, every time the user calls menu (e.g. capture menu), only the last capture environment is preserved. The previous, potentially unfinished, capture menus will be destroyed. Causing loss of user data. Currently it is hard to start new capture before selecting a template.
Re: Org and Hyperbole
On Mon, 20 Jun 2022 at 12:28, Russell Adams wrote:
> Juan,
>
> I've often wondered the same thing. I've looked at Hyperbole several
> times. They have been great at advertising when a new release
> occurs. Yet I find that I can't really find a useful feature in it
> that I don't get from Org-mode.
>
> Is there some keen feature I'm missing? What's the use case for
> Hyperbole if you're already an Org-mode user?
Hi Russell,
Some years ago I tried to integrate Hyperbole and eev and 1) I failed
miserably, and 2) I ended up with the impression that Hyperbole is
meant to be "used", not to be "hacked"... for example, in Hyperbole
the action of a button like this,
{C-h h d a}
is to emulate what happens when the user types `C-h h d a'. This
button works exactly as expected; eev implements something similar,
but in a very simplistic, and slightly buggy, way: when we run this in
eev
(eek "C-h h d a")
it simply runs this,
(execute-kbd-macro (read-kbd-macro "C-h h d a"))
that just inserts an "a". The details are here, in the second part,
after the blank lines:
https://lists.gnu.org/archive/html/hyperbole-users/2020-09/msg00013.html
Hyperbole has some amazing features, but its code needs to be
refactored to make more parts of it easier to use from Lisp... someone
needs to do that, and this someone won't be me, as I'm burnt out. =(
My links about my attempts to learn Hyperbole are here:
http://angg.twu.net/hyperbole.html
[[]],
Eduardo Ochs
http://angg.twu.net/2021-org-for-non-users.html
Re: About 'inline special blocks'
On 19/06/2022 19:47, Juan Manuel Macías wrote: I am more and more convinced that inline special blocks, by their nature, should not support fine tune options or anything like attr_latex, attr_html, etc. like its older brothers, as it would produce an overly complicated syntax. I would like to stress that styles can not be a rescue in some important cases. Let's leave aside ad hoc final tuning of formatting. In the case of HTML export there are still and title="Description"> attributes that are namely per-object, not part of style. I was going to raise this issue for several months, so I just have sent to following bug report: Max Nikulin to emacs-orgmode. [BUG] manual: confusing example of adding attributes to a link (affiliated keywords) Mon, 20 Jun 2022 23:25:29 +0700. https://list.orgmode.org/t8q71r$mgv$1...@ciao.gmane.io I have not heard that PDF offers something similar, but e.g. link with title may be exported as footnote with title text and URL instead of inline link. However to handle such cases generic attributes available to all export backends should be introduced. Even when styles are enough in principle, attributes may be more convenient since the latter may be composable, so making unnecessary defining every possible (or used) combination of styles. in html: contents> Concerning vs. , is it the same for assistive technologies like screen readers to add text (or text) and text with "font-weight: bolder;" in CSS?
[BUG] manual: confusing example of adding attributes to a link (affiliated keywords)
Hi, Org Manual in info "(org) Links in HTML export" https://orgmode.org/manual/Links-in-HTML-export.html has the following example: Org files can also have special directives to the HTML export back-end. For example, by using ‘#+ATTR_HTML’ lines to specify new format attributes to or tags. This example shows changing the link’s title and style: #+ATTR_HTML: :title The Org mode homepage :style color:red; [[https://orgmode.org]] Likely I have seen similar suggestions in this list as well. Actually it assigns attribute to paragraphs in addition to links. That is why, I think, this fragment should be removed from manual as a confusing one since it gives impression of support of per-link attributes. Attributes assigned through affiliated keywords belongs to paragraph (block-level element), not to link (inline object). Actual result of export: https://orgmode.org; title="The Org mode homepage" style="color:red;">https://orgmode.org If it were possible to set attributes to links, the result should be https://orgmode.org; title="The Org mode homepage" style="color:red;">https://orgmode.org The reason of my expectation is that a paragraph may have more than one link with different titles. I am unsure if formal bug report will help. I promised it in the following discussion: Max Nikulin to emacs-orgmode. Re: Org-syntax: Intra-word markup. Thu, 3 Feb 2022 19:10:19 +0700. https://list.orgmode.org/stggnf$d8g$1...@ciao.gmane.io A similar complain: Anton Linevych. How to add extra attributes to link in Org-mode? 2017-06-21 https://linevi.ch/en/org-link-extra-attrs.html The reason why I have decided to post this bug report now is the following message: Juan Manuel Macías to emacs-orgmode. Re: About 'inline special blocks' Sun, 19 Jun 2022 12:47:40 +. https://list.orgmode.org/875ykwvmz7@posteo.net It states that styles and similar stuff may solve the issue with attributes for inline objects. From my point of view it is wrong and in some cases per-object attributes are necessary. While or may be added through style, attributes like "alt" for images, "title", "lang", etc. for links are individual. I am aware of the following post: J. Kitchin. Extending the org-mode link syntax with attributes. 2015-02-05 http://kitchingroup.cheme.cmu.edu/blog/2015/02/05/Extending-the-org-mode-link-syntax-with-attributes/ The recipe solves the problem, but this time the topic of inline special blocks has been risen in the context of limitations in Org markup making it inappropriate tool for GNU manuals in general and the Org manual in particular. So some more general solution is required than local customization. So as outcome for this bug report I expect that either caveats related to affiliated keywords are clearly stated in the manual or some "official" way to assign attributes for specific inline objects is introduced.
Re: Org and Hyperbole
Hi Juan,
On 20-06-2022 16:03, Juan Manuel Macías wrote:
Hi,
I've been intrigued with GNU Hyperbole for a while. I'm reading the
documentation and trying it out a bit. It seems that its button system
is very powerful. But Org links are also powerful (and exportable), and
can be extended outside of Org docs. It seems that hyperbole offers
some
cool stuff that Org also has. And other things that are not in Org. I
find some parts a bit confusing. I wonder if anyone is using hyperbole
with Org and can put here some minimal workflow example where both
complement each other in some way. Just in case I'm missing something
useful...
I recommend Hyperbole, though I must confess Ive been using Orgmode a
lot less since Ive been focusing on the format GemText.
I should recommend the use of the function defil, for people who like
regexes and want to operate differing contexts (to launch via the ACTION
operator). Its mid-grade compared to the more simpler approach and the
more complex eLisp approach.
While I have not fully applied this technique to my workflow, you can
see some /stub/ experimentations that are used to provide different
function calls based upon where the cursor is in the context of a
specific annotation (namely my annotation approach, Qiuy).
https://git.sr.ht/~indieterminacy/5q50jq_oq_configuring_emacs/tree/master/item/cqc_mqm_interfacing_blooms.el
The logic for the example includes:
As you see below, these things build through to build multiple cursor
based contexts.
```
(defil qiuy-1q10hqh_1 "^" "q10hqh.*" "1" "{M-: (print \"context_1 1q\")
RET}" t t)
(defil qiuy-1q10hqh_2 "^1" "10hqh.*" "q" "{M-: (print \"context_2
[1-6]q\") RET}" t t)
(defil qiuy-1q10hqh_3 "^1q" "0hqh.*" "1" "{M-: (print \"context_3
1q10\") RET}" t t)
(defil qiuy-1q10hqh_4 "^1q1" "hqh.*" "0" "{M-: (isearch-forward-symbol
\"q10\") RET}" t t)
(defil qiuy-1q10hqh_5 "^1q10" "qh.*" "h" "{M-: (rg-project \"hqh\"
\".*\") RET}" t t)
(defil qiuy-1q10hqh_6 "^1q10h" "h.*" "q" "{M-: (print \"context_6
1q10hqh\") RET}" t t)
(defil qiuy-1q10hqh_7_\s "^1q10hqh" "$" "\s(.*)" "{M-: (print
\"context_7_\s 1q10hqh \\&\") RET}" t t)
(defil qiuy-1q10hqh_7_\t "^1q10hqh" "$" "\t(.*)" "{M-: (print
\"context_7_\t 1q10hqh \\&\") RET}" t t)
(defil qiuy-1q10hqh_7_- "^1q10hqh" "$" "-(.*)" "{M-: (print
\"context_7_- 1q10hqh \\&\") RET}" t t)
(defil qiuy-1q10hqh_7__ "^1q10hqh" "$" "_(.*)" "{M-: (print
\"context_7__ 1q10hqh \\&\") RET}" t t)
```
Documentation for the function defil can be found here:
https://www.gnu.org/software/hyperbole/man/hyperbole.html#Implicit-Button-Link-Types
The Hyperbole ML is quiet but friendly and informative.
Having examined Hyperbole more broadly, I do wonder if there was more of
a policy to treat Orgmode as more of a parrallel concern.
Today, there is clearly a proactive effort to align and encourage cross
usage.
To hear that somebody as accomplished as yourself is dabbling with
Hyperbole pleases me no end.
It may be worth you visiting one of my knowledge repos here:
https://git.sr.ht/~indieterminacy/3q50cqc_oq_interfaces_emacs
As well as (over time) checking on on these search parameters for my
username:
https://git.sr.ht/~indieterminacy/?search=hyperbole
https://git.sr.ht/~indieterminacy/?search=koutliner
Of note, I should mention my own project, Icebreaker - which has been
augmenting the GemText format with terse syntaxes and formats -
including Hyperboles Koutliner format (which if I understand may be able
to include orgmode tables in its blocks with the new version - I could
be wrong here).
Here is a WIP parser written in TXR - for parsing Koutliner blocks (with
or without my Qiuy annotations) and expressing it as a datalisp:
https://git.sr.ht/~indieterminacy/1q20hqh_oqo_parsing_glean
I shall be tightening it up soon, including integrating it with a WIP
GemText parser (its terser atm but missing a little):
https://git.sr.ht/~indieterminacy/1q20hqh_kq_parsing_gemtext
An NLNet funded project, I am going to later be exporting some of this
information into simple Orgmode syntax as a subset of one of the
deliverables. An earlier protyping is covered here in a more recent
Fosdem talk:
https://fosdem.org/2022/schedule/event/minimalsyntaxes/
Im happy to answer any more questions with regards to this in this
thread or elsewhere.
It may be worth highlighting a matrix room my Icebreaker project runs to
reduce clutter from other MLs.
The members there are friendly, knowledgable and use Orgmode for a range
of tasks:
https://matrix.to/#/#xq_icebreaker:matrix.org
You are a clear and concise writer and coder. I would love to hear the
outcomes from this exploration.
If I recall you are an emacspeak user - which I seem to think has been
praised for its integration with Hyperbole so that should be more than
enough justification to really get into it.
Kind regards,
--
Jonathan McHugh
indieterminacy@libre.brussels
Re: Org and Hyperbole
I hadn't heard of it so I'm watching a demo. It looks similar to Oberon (which heavily influenced Acme and Wily) which is an extremely powerful "mouse-based text environment". I'm certainly going to give it a try -- it seems like a great compliment to org-mode and other Emacs power tools... -- Bill On Mon, Jun 20, 2022 at 5:18 PM Juan Manuel Macías wrote: > Hi, > > I've been intrigued with GNU Hyperbole for a while. I'm reading the > documentation and trying it out a bit. It seems that its button system > is very powerful. But Org links are also powerful (and exportable), and > can be extended outside of Org docs. It seems that hyperbole offers some > cool stuff that Org also has. And other things that are not in Org. I > find some parts a bit confusing. I wonder if anyone is using hyperbole > with Org and can put here some minimal workflow example where both > complement each other in some way. Just in case I'm missing something > useful... > > Best regards, > > Juan Manuel > >
exporting to mediawiki syntax math is not converted
Hi The following line torus $\mathbb T^3$ in the Sobolev spaces $H^m(\mathbb T^3)$. Is translated to torus \(\mathbb T^3\) in the Sobolev spaces \(H^m(\mathbb T^3)\) Instead of torus \mathbb T^3 in the Sobolev spaces H^m(\mathbb T^3) Is this a missing feature, or do I miss something here? Thanks Uwe Brauer -- I strongly condemn Putin's war of aggression against the Ukraine. I support to deliver weapons to Ukraine's military. I support the ban of Russia from SWIFT. I support the EU membership of the Ukraine.
Re: Org and Hyperbole
>>> "JMM" == Juan Manuel Macías writes: > Hi, > I've been intrigued with GNU Hyperbole for a while. I'm reading the > documentation and trying it out a bit. It seems that its button system > is very powerful. But Org links are also powerful (and exportable), and > can be extended outside of Org docs. It seems that hyperbole offers some > cool stuff that Org also has. And other things that are not in Org. I > find some parts a bit confusing. I wonder if anyone is using hyperbole > with Org and can put here some minimal workflow example where both > complement each other in some way. Just in case I'm missing something > useful... Quite some time ago (that was at the time org mode was in its infancy) I gave it a try and found it too confusing and difficult to handle for every day work. There were other package that provided similar (well less) functionality but were much simpler, however they were not stable that is the links could be damaged during editing. I don't recall the details. But I am happy with what org mode offers. Sorry that may have been not that helpful.. Uwe Brauer smime.p7s Description: S/MIME cryptographic signature
[PATCH] Improve docstrings of agenda date navigation commands
I found the docstrings of the agenda date navigation commands to be somewhat lacking. The attached patch expands them slightly and adds crossreferences, which I think makes them much more usable. Thanks. 0001-Improve-docstrings-of-agenda-date-navigation-command.patch Description: Binary data
Re: Org and Hyperbole
On Mon, Jun 20, 2022 at 02:03:15PM +, Juan Manuel Macías wrote: > I've been intrigued with GNU Hyperbole for a while. I'm reading the > documentation and trying it out a bit. It seems that its button system > is very powerful. But Org links are also powerful (and exportable), and > can be extended outside of Org docs. It seems that hyperbole offers some > cool stuff that Org also has. And other things that are not in Org. I > find some parts a bit confusing. I wonder if anyone is using hyperbole > with Org and can put here some minimal workflow example where both > complement each other in some way. Just in case I'm missing something > useful... Juan, I've often wondered the same thing. I've looked at Hyperbole several times. They have been great at advertising when a new release occurs. Yet I find that I can't really find a useful feature in it that I don't get from Org-mode. Is there some keen feature I'm missing? What's the use case for Hyperbole if you're already an Org-mode user? -- Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Re: [BUG] Adding note to heading without newline at the end
Ihor Radchenko writes: > Can you reproduce the problem starting from emacs -Q? I did. The bug only occurs if there is no newline at the end. So for example if you open a new buffer and don't save it, the bug should occur. Similarly, in my own config (where I have enabled org-log-into-drawer), the note gets inserted below as is correct but the last letter of the heading gets inserted at the end, like: #+begin_example * tes :LOGBOOK: - Note taken on [2022-06-20 Mon 17:07] :END: t #+end_example (it doesn't seem to matter /where/ in the heading you are when you insert the note --- it's always the last letter falling down). I haven't been able to reproduce this with emacs -Q yet, though, but I suspect the source of the error is the same. Anyway, running Emacs as before with -Q and inserting a note, the result is: #+begin_example - Note taken on [2022-06-20 Mon 17:07] * test #+end_example Again, if there is a newline at the end (as would happen if you first save the file) the bug doesn't occur. I'm using a recent build of Emacs 29.
Re: oc-basic: CSL-JSON year as number vs. string (nativecomp?)
On Mon, Jun 20, 2022 at 10:13 AM David Lukeš wrote: ... > > it's likely we'll change the date property to prefer an > > EDTF string > > Will that be stored in the `raw` or `literal` field? In that case, the > current implementation should work with (not too wild) EDTF strings. > If not, code will have to be added to extract the value from the > appropriate field. I need to emphasize a major caveat: this is subject to change, discussion, etc., and would take time regardless to see in the wild. So you shouldn't do anything with this information ATM; I just mention it because it may be relevant in the future. And of course, we welcome feedback. But currently, the draft schema for the next major release allows this as an option (this is an EDTF date range): "issued": "2020-07/2020-08", E.g. a (preferred) EDTF string, OR the current date object. In general, I should add, there are some competing priorities here. The CSL JSON was first created for the citeproc-js project, whose initial and primary consumer is Zotero, which embeds that data in word processing documents. In that case, machines are the only consumers. But it's since become more widely used, including in pandoc, and now in org. So the planned move to EDTF is in part to balance those priorities. But as I say, we still need feedback from the different constituencies. Bruce
Re: oc-basic: CSL-JSON year as number vs. string (nativecomp?)
> I created CSL, and have helped develop the data schema. Well, that's what I call a reliable source :) I suppose this is as good a time as any to say thanks for all that! > it's likely we'll change the date property to prefer an > EDTF string Will that be stored in the `raw` or `literal` field? In that case, the current implementation should work with (not too wild) EDTF strings. If not, code will have to be added to extract the value from the appropriate field. > I'd prefer an explicit cond here. format "%s" may silently > work on malformed json files and will mask issues with > bibliography from the user. Sure, good idea :) > Would you mind creating a patch and possibly supplying a test > that will make sure that the example file and similar are correctly > parsed? I'm attaching a patch (just the patch for now, no commit message), let me know what you think, in particular the error message. What would be an acceptable way to wrap the format string? As for tests -- if `oc-basic.el` already had some, I'd try to see if I can come up with something by analogy. But as it stands, I know too little about Elisp, nothing about Elisp testing, and have too little spare time, sorry :( Best, David diff --git a/lisp/oc-basic.el b/lisp/oc-basic.el index a937f75..f10b95b 100644 --- a/lisp/oc-basic.el +++ b/lisp/oc-basic.el @@ -189,7 +189,14 @@ Return a hash table with citation references as keys and fields alist as values. (cons 'year (cond ((consp date) -(caar date)) + (let ((year (caar date))) + (cond + ((numberp year) (number-to-string year)) + ((stringp year) year) + (t + (error + "First element of CSL-JSON date-parts should be a number or string, got %s: %S" + (type-of year) year) ((stringp date) (replace-regexp-in-string (rx
Org and Hyperbole
Hi, I've been intrigued with GNU Hyperbole for a while. I'm reading the documentation and trying it out a bit. It seems that its button system is very powerful. But Org links are also powerful (and exportable), and can be extended outside of Org docs. It seems that hyperbole offers some cool stuff that Org also has. And other things that are not in Org. I find some parts a bit confusing. I wonder if anyone is using hyperbole with Org and can put here some minimal workflow example where both complement each other in some way. Just in case I'm missing something useful... Best regards, Juan Manuel
Re: [BUG] Adding note to heading without newline at the end
Tor Kringeland writes: > Consider the following buffer > > #+begin_example > * test > #+end_example > > without a newline at the end. Calling `org-add-note' will result in an > error and the note being placed /before/ the heading. I am unable to reproduce. Can you reproduce the problem starting from emacs -Q? See https://orgmode.org/manual/Feedback.html Best, Ihor
Re: oc-basic: CSL-JSON year as number vs. string (nativecomp?)
On Mon, Jun 20, 2022 at 8:04 AM Ihor Radchenko wrote: > > "Bruce D'Arcus" writes: > > > I created CSL, and have helped develop the data schema. > > > > BTW, just to look forward, it's likely we'll change the date property > > to prefer an EDTF string; same as biblatex does now. > > Have you ever checked if oc-basic parser complies with the schema? > It is clear that is not for year field, but I am wondering about other > fields. I had not. But the schema doesn't have a lot of rules. Aside from dates, the other structured object definition is for (author etc) names. oc-basic ignores the properties beyond "family" and "given" names, most of which probably don't matter for this purpose, except maybe "literal" (for organizational authors). Bruce
Re: Mastodon link type for capturing toots?
Christian Moe writes:
> Has anyone written a link type for Mastodon that would allow you to
> org-capture the post/status ("toot") at point?
>
> I'm referring to mastodon.el
> (https://codeberg.org/martianh/mastodon.el), which is available via
> install-packages.
No AFAIK. But it is very easy to define new link types in Org. You can
do it yourself. See A.3 Adding Hyperlink Types section of the manual.
Best,
Ihor
Re: Proposal: 'executable' org-capture-templaes
Max Nikulin writes: >>> Ihor, magic is impossible. If several captures may be requested in >>> parallel then snapshot of data required to fill capture template should >>> be stored somewhere at the moment when capture is initiated. Otherwise >>> the user may kill the buffer she is going to capture before selecting >>> particular template. >> >> Sure. That somewhere can be buffer-local variable inside the capture >> menu buffer. Or global variable. Or closure. How is it relevant to the >> capture menu? > > Before menu buffer is created, caller can not assign a buffer-local > variable. So to be transparent for snapshot of capture data, menu should > support such variable and should pass it further when template is > chosen. Otherwise the capture data may be lost with temporary buffer. > The function calling menu should gather values from all variables > necessary for capture to build some state passed to menu implementation. Sure. I was hinting about such functionality in the new library we are discussing. Multiple capture menus are not possible now anyway, so it will be a new feature if we decide that we need it (I am not 100% sure if having multiple menus is not going to be confusing). >> Of course, using global variables will limit things to a single capture, >> but it just means that if a user starts capture, leaves the capture menu >> buffer, and then starts another capture, only the last capture will be >> handled. Just like we have now. > > Now user may leave capture menu by either selection of a template or by > aborting menu. In the case of keymap-based menu there is no such > restriction, so org-capture and menu implementation should be adjusted > in some way to avoid bad surprises for users. > > Currently several capture menu instances may be requested though > org-protocol (or calling org-capture from emacsclient). The behavior is > rather confusing. New menu may help to fix the issue, that is why I > raised the question about parallel captures. I am not sure which behavior you have in mind. What I was thinking as a conservative implementation that would not introduce any new features is replacing the old menu with the new one every time the same menu is called. So, every time the user calls menu (e.g. capture menu), only the last capture environment is preserved. The previous, potentially unfinished, capture menus will be destroyed. Best, Ihor
Re: oc-basic: CSL-JSON year as number vs. string (nativecomp?)
"Bruce D'Arcus" writes: > I created CSL, and have helped develop the data schema. > > BTW, just to look forward, it's likely we'll change the date property > to prefer an EDTF string; same as biblatex does now. Have you ever checked if oc-basic parser complies with the schema? It is clear that is not for year field, but I am wondering about other fields. Best, Ihor
Re: oc-basic: CSL-JSON year as number vs. string (nativecomp?)
David Lukeš writes: >> The JSON schema allows either: > > Ah, thanks for looking this up! So (format "%s" (caar date)) instead > of (number-to-string (caar date))? > > (That was actually my initial solution, purely out of being defensive > and trying to make sure it doesn't break in yet a different way should > other things than numbers turn up in date-parts, even nil or such. > Then I thought it was too hamfisted and didn't have the time to make a > case for being so defensive here. But since it's needed even just to > be *compliant*, the case seems quite clear now.) I'd prefer an explicit cond here. format "%s" may silently work on malformed json files and will mask issues with bibliography from the user. I personally hate when it happens and it is often easy to miss issues with downloaded bibliography entries. >> Can you provide an example json file demonstrating the problem? > > Sure, I'm attaching a short sample. Thanks! Would you mind creating a patch and possibly supplying a test that will make sure that the example file and similar are correctly parsed? Best, Ihor
