Re: [9.4] Fixing logbook visibility during isearch
Ihor Radchenko writes:
> Kévin Le Gouguec writes:
>
>> The debugger only fires *after* we exit isearch, and by that time it's
>> too late: my issue comes from all those logbooks cluttering the screen
>> while I'm mashing C-s to iterate through matches.
>>
>> I can try to dig deeper into this, but before doing so: would you have
>> any insight as to what's going on here?
>
> org-mode is relying on default isearch behaviour during interactive C-s
> session. By default, isearch simply makes all the overlays at match
> visible and re-hide them once we move to the next match. In case of
> org-mode, this reveals drawers as well, since they are in the same
> overlay with the rest of the folded heading.
>
> The way to change default isearch behaviour *during* isearch session is
> setting undocumented 'isearch-open-invisible-temporary property of the
> overlay (see isearch-open-overlay-temporary).
Thanks for taking the time to explain this.
I can't find any reference to this property in Org <9.4 (e.g. 9.3 as
shipped in 27.1, where the bug does not happen) so do I understand
correctly that the root cause ("since [drawers] are in the same overlay
with the rest of the folded heading") dates from Org 9.4?
(Just trying to understand if I should keep looking at Org 9.3 for
inspiration, or if your proposed solution based on
isearch-open-invisible-temporary should be implemented from scratch)
Re: Release Org 9.4.2
On Wednesday, 16 Dec 2020 at 13:04, Gustav Wikström wrote: > But to be fair, the collaboration features of GitHub surely would be a > BIG net positive if the goal is to attract contributions and gain a > bigger mindshare. Not necessarily. Some of us dislike web based tools intensely, in fact anything that does not work well in Emacs ;-). In practice, I will not participate in projects that, for instance, use slack or discourse or ... Requiring the use of github for interaction would lead to a reduction in the (albeit rather small) contributions I make to this project. A mailing list (or nntp) plus git is perfect for my working methods. > This is a hobby project and it would be cool if it could be something > else at least for someone! Why cool? What's cool is that so many contribute, in a wide range of ways, without some financial recompense! -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4.2-143-gc822c8
Re: Release Org 9.4.2
On Wednesday, 16 Dec 2020 at 14:11, Gustav Wikström wrote: > I for one wouldn't feel sorry if we (the world) could collect > resources to make working with Org mode a financially viable way of > life for someone. I think that's already possible, or least it was with the old web site: there is/was a patreon link if I remember correctly. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4.2-143-gc822c8
Re: Release Org 9.4.2
Gustav Wikström writes: >> From: Emacs-orgmode on behalf >> of TEC >> Sent: Wednesday, December 16, 2020 08:14 >> To: Bastien >> Cc: emacs-orgmode@gnu.org; Pankaj Jangid >> Subject: Re: Release Org 9.4.2 >> >> ... >> >> I actually have a few thoughts on this. I'm afraid that I don't think >> Org/Emacs are doing a good job of being accessible to younger >> individuals who have never used a ML / sent patches before (I should >> know, I'm one such individual, and the lack of familiarity was a >> significant deterrent). Whether a ML is a more efficient way of doing >> things or not ultimately doesn't matter in this regard, because it's >> simply not something I or many others are used to. >> >> Just to be clear, I'm not advocating for getting rid of the ML and >> jumping on GitHub etc. :P > > But to be fair, the collaboration features of GitHub surely would be a > BIG net positive if the goal is to attract contributions and gain a > bigger mindshare. That together with an open collective funding model > of some sort. Because let's be fair. This is a hobby project and it > would be cool if it could be something else at least for someone! > Github is not an option here. The problem is, github encourages the use of proprietary, non-free software, which conflicts with the GNU's primary goal of software freedom. As Org mode is a GNU project, it cannot use Github in any fashion which would encourage the use of github interfaces that require/encourage the use of non-free software, which unfortunately, key parts of their web UI does. With respect to providing a different forum which might e more familiar or more comfortable to younger users who are not as comfortable with a mailing list, I don't know what the answer is. By definition, being an old user who is out of step with the trends of the young, I an other old timers probably don't have the necessary familiarity with modern trends to do anything here. If young users need/want a different forum, they need to take on the responsibility for that initiative. The only restriction is that the forum must fit with the philosophy and guidelines of the FSF with respect to free (libre) software and not just 'open source'. Personally, I think on-line communities went backwards after the decline of USERNET newsgroups. -- Tim Cross
Re: Org Capture Menu cannot be fully viewed
Pietru:
If you are extensively using Org's capture templates I suggest
taking a look at:
https://github.com/progfolio/doct
A brief summary of some of the benefits it provides:
- Allows capture template inheritance
- Checks for certain errors in template declarations *before*
capture.
- Automatically computes the keys for nested menus
- Makes per-template hooks/contexts easy to declare.
- Allows for storing custom metadata with templates which can be
used within templates
- Declarative: Your template declarations will be easier to
read/share.
Taking the list of templates provided earlier as an example,
It could utilize nested menus/inheritance like so:
#+begin_src emacs-lisp :lexical t
(doct
'( :group "Archaeology"
:file "~/histr/archaeol.org"
:template "* Site_Type: %?\n %T\n"
:children (("Research" :keys "r"
:children (("Bioarchaeological" :keys "b")
("Collections" :keys "c")
("Design/Data Recovery" :keys "d")
("Environment" :keys "e")
("Ethnographic" :keys "g")
("Ethnohistoric" :keys "h")
("Historic Eval/Testing" :keys "t")))
("Survey" :keys "s"
:children (("Architectural" :keys "a")
("Geophysical" :keys "g")
("Reconnaissance" :keys "r")
("Recovery/Excavation" :keys "R")))
("Consultation" :keys "c")
("Architectural Documentation" :keys "d")
("Site Stabilization":keys "e")
("Ground Disturbance Monitoring" :keys "g")
("Heritage Management" :keys "h")
("Records Search/Inventory Checking" :keys "i")
("Methodology, Theory, Synthesis":keys "m")
("Archaeological Overview" :keys "o")
("Remote Sensing":keys "R")
("Site Stewardship Monitoring" :keys "d"
#+end_src
Each template inherits the :file and :template values.
The keys for the "Research" and "Survey" children templates are
computed by doct,
so changing the whole groups prefix key only requires a change on
the parent template's :keys.
I haven't demoed the custom metadata in this example as I don't
know your exact use case,
but there is an example in the documentation:
https://github.com/progfolio/doct#custom-data
Hope this is useful for you.
~ Nick
Re: Org Capture Menu cannot be fully viewed
What is here missing is `org-capture-by-completing-read' so that user may select among many various capture templates. Compensating for initial bad design is expensive effort. Are you suggesting something like this?: #+begin_src emacs-lisp (defun +org-capture-read ( arg) "completing read interface for org-capture template selection. ARG is passed to `org-capture'." (let (parent) (when-let* ((templates (mapcar (lambda (template) (let* ((keys (car template)) (parentkeys (car parent))) (if (= (length template) 2) (progn (setq parent template) nil) (cons (concat (when (and parentkeys (string-prefix-p parentkeys keys)) (concat (cadr parent) "/")) (cadr template)) keys org-capture-templates)) (selection (alist-get (completing-read "capture template: " (mapcar #'car (delq nil templates)) nil 'require-match) templates nil nil #'string=))) (org-capture arg selection #+end_src emacs-lisp
Re: Release Org 9.4.2
Loris Bennett writes: > Eric S Fraga writes: > >> On Wednesday, 16 Dec 2020 at 13:04, Gustav Wikström wrote: >>> But to be fair, the collaboration features of GitHub surely would be a >>> BIG net positive if the goal is to attract contributions and gain a >>> bigger mindshare. >> >> Not necessarily. Some of us dislike web based tools intensely, in fact >> anything that does not work well in Emacs ;-). >> >> In practice, I will not participate in projects that, for instance, use >> slack or discourse or ... Requiring the use of github for interaction >> would lead to a reduction in the (albeit rather small) contributions I >> make to this project. A mailing list (or nntp) plus git is perfect for >> my working methods. > > But even if a project is hosted on GitHub, you can still interact with > it just via Emacs, it is still Git after all. > > One project I have made minor contributions to is EasyBuild, a framework > for managing the building and installation of (mainly) scientific > software, which is hosted on GitHub: > > https://github.com/easybuilders/easybuild > > However, I can interact with it via Magit, and even if I don't use > Emacs, the project has command-line tools which allow the creation of a > pull request without the me having to know anything about GitHub or even > git: > > > https://easybuild.readthedocs.io/en/latest/Integration_with_GitHub.html#submitting-pull-requests-new-pr > > Obviously the EasyBuild people have put quite a lot of work into making > this possible and it is mainly to allow people to contribute > self-contained "recipes" for building particular pieces of software, > rather than work on the main code of the framework. > > To be honest, last time I tried, responding to comments on pull-requests > didn't work so well via Emacs, so unfortunately I ended up having to > using the web-interface. > > But on the other hand, they also have a mailing list, so there is > something for everyone ;-) > A lot of the key Git features are available via command line and other tools. This is how I always interact with Github repositories. Unfortunately, many other aspects of Github are not available via command line or are only available in a severely crippled manner, so people are forced to use the web UI which has components and functionality built o technology which is in conflict with the FSF and GNU philosophy, guidelines and key goals. Some people have been working on Github to get changes which would change this situation, but until they do, it simply is not an option. The BIG problem with many of the alternative 'forum' technologies is that very few of them use free software. Some of them may be open source, but that is not the same as free (libre) software. The other problem is many of them force the use of a web UI, which many, including myself, don't like and which rarely works well in Emacs itself (primarily due to the reliance on Javascript). -- Tim Cross
Re: Release Org 9.4.2
> From: Eric S Fraga > Sent: Wednesday, December 16, 2020 14:49 > To: Gustav Wikström > Cc: emacs-orgmode@gnu.org > Subject: Re: Release Org 9.4.2 > > ... > > Why cool? What's cool is that so many contribute, in a wide range of > ways, without some financial recompense! I mean, yeah - it's already cool! No arguing there. Just saying that "already cool" doesn't have to be "cool enough"! It's not binary. I for one wouldn't feel sorry if we (the world) could collect resources to make working with Org mode a financially viable way of life for someone. Even though relying on contributions is an insecure way of getting income, we all need an influx of resources (unless you've already accumulated a wealth somehow). Having some who could wake up in the morning, open the computer and do daytime work for Org would make at least me smile. Ofc, with money comes other problems etc etc. Kind regards Gustav
Re: Release Org 9.4.2
> From: Emacs-orgmode on behalf > of TEC > Sent: Wednesday, December 16, 2020 08:14 > To: Bastien > Cc: emacs-orgmode@gnu.org; Pankaj Jangid > Subject: Re: Release Org 9.4.2 > > ... > > I actually have a few thoughts on this. I'm afraid that I don't think > Org/Emacs are doing a good job of being accessible to younger > individuals who have never used a ML / sent patches before (I should > know, I'm one such individual, and the lack of familiarity was a > significant deterrent). Whether a ML is a more efficient way of doing > things or not ultimately doesn't matter in this regard, because it's > simply not something I or many others are used to. > > Just to be clear, I'm not advocating for getting rid of the ML and > jumping on GitHub etc. :P But to be fair, the collaboration features of GitHub surely would be a BIG net positive if the goal is to attract contributions and gain a bigger mindshare. That together with an open collective funding model of some sort. Because let's be fair. This is a hobby project and it would be cool if it could be something else at least for someone! Gustav
Re: Release Org 9.4.2
Eric S Fraga writes: > On Wednesday, 16 Dec 2020 at 13:04, Gustav Wikström wrote: >> But to be fair, the collaboration features of GitHub surely would be a >> BIG net positive if the goal is to attract contributions and gain a >> bigger mindshare. > > Not necessarily. Some of us dislike web based tools intensely, in fact > anything that does not work well in Emacs ;-). > > In practice, I will not participate in projects that, for instance, use > slack or discourse or ... Requiring the use of github for interaction > would lead to a reduction in the (albeit rather small) contributions I > make to this project. A mailing list (or nntp) plus git is perfect for > my working methods. But even if a project is hosted on GitHub, you can still interact with it just via Emacs, it is still Git after all. One project I have made minor contributions to is EasyBuild, a framework for managing the building and installation of (mainly) scientific software, which is hosted on GitHub: https://github.com/easybuilders/easybuild However, I can interact with it via Magit, and even if I don't use Emacs, the project has command-line tools which allow the creation of a pull request without the me having to know anything about GitHub or even git: https://easybuild.readthedocs.io/en/latest/Integration_with_GitHub.html#submitting-pull-requests-new-pr Obviously the EasyBuild people have put quite a lot of work into making this possible and it is mainly to allow people to contribute self-contained "recipes" for building particular pieces of software, rather than work on the main code of the framework. To be honest, last time I tried, responding to comments on pull-requests didn't work so well via Emacs, so unfortunately I ended up having to using the web-interface. But on the other hand, they also have a mailing list, so there is something for everyone ;-) Cheers, Loris >> This is a hobby project and it would be cool if it could be something >> else at least for someone! > > Why cool? What's cool is that so many contribute, in a wide range of > ways, without some financial recompense! -- This signature is currently under construction.
Re: Release Org 9.4.2
Gustav Wikström writes: > But to be fair, the collaboration features of GitHub surely would be a > BIG net positive if the goal is to attract contributions and gain a > bigger mindshare. That together with an open collective funding model > of some sort. Because let's be fair. This is a hobby project and it > would be cool if it could be something else at least for someone! When I receive a PR on Github, I pull the developer’s branch in a local-branch and then review, and then merge locally and then push to main. Github automatically closes the PR. I really don’t want to visit a website to review code, when I have Emacs.
Re: Release Org 9.4.2
> From: Eric S Fraga > Sent: Wednesday, December 16, 2020 15:50 > To: Gustav Wikström > Cc: emacs-orgmode@gnu.org > Subject: Re: Release Org 9.4.2 > > On Wednesday, 16 Dec 2020 at 14:11, Gustav Wikström wrote: > > I for one wouldn't feel sorry if we (the world) could collect > > resources to make working with Org mode a financially viable way of > > life for someone. > > I think that's already possible, or least it was with the old web site: > there is/was a patreon link if I remember correctly. True, which is good. But it's personal. To Bastien who already have signaled that he's signing of. I frankly don't know where to put my financial contributions right now. I've offered other contributors to sign up for a similar patreon to recieve some contributions but they have declined, due to what I understand as a pressure for delivery (even though I've clarified that at least I have no expectations, just want to contribute for the already done valuable work). It is my believe that Org would benefit from a counter that would "tic up" even if no one collects the money. Like it or not, money has an effect. Better to allocate it to open source work than anything else! Or? Anyhow, maybe the next maintainer(s?) who come after Bastien sees this and realizes that there at the least is around 5-20$/m laying in wait from this particular source. Regards Gustav
Re: Org Capture Menu cannot be fully viewed - Results of testing C-n, C-p, C-v
> 1. Capture Option Selection
> ===
>
> C-n, C-p, C-v work well and one can go through the capture menu easily.
>
> Below the capture buffer, I am seeing another buffer that is displaying events
> from the mouse (triple-mouse-1, down-mouse 5, ...) and keyboard (down up up,
> ...)
> that ends getting bigger and bigger and bigger.
>
> It is the buffer in which the user enters the option. It does get
> bigger than one line, finally taking up most of the frame. And the
> user can do nothing about that - that is you cannot drog the mouse
> to resize it. Not being able to resize the window can become a very
> big bother when using org-capture.
This is hopefully fixed with the latest commit. Also M-v has been added
to the family of navigation keys.
> 2. Problem with %^{prompt|default|completion2|completion3...}
> 3 Default Completion Prompt
TBH I don't see problems here. But that's just me. Let's see what others
think.
Does Nowayman's hint help?
Best regards,
--
Marco
Re: [PATCH] Enhance org-html--build-meta-info
On 2020-12-16, TEC wrote: > Jens Lechtenboerger writes: >>> Maybe it should be applied to the rest (in ~org-html--build-meta-info~)? >>> I'm not sure. >> >> I’m not sure either. Maybe people expect their typed characters, >> maybe not. This might call for a new variable. > > I'm tempted to leave the current behaviour as-is, and then we can > introduce a new variable if we want later :) I agree. >> I like the new variant much better. However, I still do not >> understand why you pass the title into org-html-meta-tags-default >> just to ignore it. The title is already dealt with elsewhere, isn’t >> it? > > For people who want to customise this to add metadata, the page title is > something they're probably interested in. What metadata would you derive from the title? > If so, I think it's work giving the title processed by > org-html--build-meta-info as it's not so simple as > (plist-get info :title). Extracting it from ~info~ might be more flexible as it would not be tied to the current implementation. Best wishes Jens smime.p7s Description: S/MIME cryptographic signature
Bug: org-contacts.el: org-contacts-link-store breaks org-id [9.4.2 (release_9.4.2-307-g8840af @ /home/yantar92/.emacs.d/straight/build/org/)]
Remember to cover the basics, that is, what you expected to happen and what in fact did happen. You don't know how to make a good report? See https://orgmode.org/manual/Feedback.html#Feedback Your bug report will be posted to the Org mailing list. When using org-contacts and org-id simultaneously, org-contacts unconditionally makes org-store-link use file:name.org:*Headline link style instead of id:UUID link style expected when using org-id. The problem does not only appears when storing links to contact.org headlines, but for any headlines. Probably, org-contacts should be integrated with org-id or at least not interfere with links to ordinary headlines. Best, Ihor Emacs : GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, cairo version 1.16.0) of 2020-12-12 Package: Org mode version 9.4.2 (release_9.4.2-307-g8840af @ /home/yantar92/.emacs.d/straight/build/org/)
Re: Org Capture Menu cannot be fully viewed - Results of testing C-n, C-p, C-v
> Sent: Wednesday, December 16, 2020 at 10:46 PM
> From: "Marco Wahl"
> To: pie...@caramail.com
> Cc: "Org-Mode mailing list"
> Subject: Re: Org Capture Menu cannot be fully viewed - Results of testing
> C-n, C-p, C-v
>
>
> > 1. Capture Option Selection
> > ===
> >
> > C-n, C-p, C-v work well and one can go through the capture menu easily.
> >
> > Below the capture buffer, I am seeing another buffer that is displaying
> > events
> > from the mouse (triple-mouse-1, down-mouse 5, ...) and keyboard (down up
> > up, ...)
> > that ends getting bigger and bigger and bigger.
> >
> > It is the buffer in which the user enters the option. It does get
> > bigger than one line, finally taking up most of the frame. And the
> > user can do nothing about that - that is you cannot drog the mouse
> > to resize it. Not being able to resize the window can become a very
> > big bother when using org-capture.
>
> This is hopefully fixed with the latest commit. Also M-v has been added
> to the family of navigation keys.
>
> > 2. Problem with %^{prompt|default|completion2|completion3...}
> > 3 Default Completion Prompt
>
> TBH I don't see problems here. But that's just me. Let's see what others
> think.
Problem happens for long completion texts in {PROMPT}
When the default is printed as well as the next selection, it creates
a problem. You can always go through all the options, and I see no need
to continue showing the default when people are moving through the selections.
It is ok to have the default when the selection consist of just one word, but
not when you have longer categorisation sentences.
Archaeological Data Archiving Protocol
Heavy Minerals and Particle Size Analysis
Micromorphology and related Microscopy (SEM Analysis, X-Ray Diffraction)
Thin Section Reference (Polarised Light Microscopy)
> Does Nowayman's hint help?
I had already tackled that problem. But it is a different problem.
> Best regards,
> --
> Marco
>
Re: Bug: org-contacts.el: org-contacts-link-store breaks org-id [9.4.2 (release_9.4.2-307-g8840af @ /home/yantar92/.emacs.d/straight/build/org/)]
Sure, I didn't expected that soon bug appears. I checked source code, I commented out an condition accidentally. Here is the patch. Tested it should work now. [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 16, 2020 at 7:40 PM Bastien wrote: > Hi, > > Ihor Radchenko writes: > > > When using org-contacts and org-id simultaneously, org-contacts > > unconditionally makes org-store-link use file:name.org:*Headline link > > style instead of id:UUID link style expected when using org-id. The > > problem does not only appears when storing links to contact.org > > headlines, but for any headlines. > > > > Probably, org-contacts should be integrated with org-id or at least not > > interfere with links to ordinary headlines. > > Agreed. Stardiviner, can you have a look? > > Thanks, > > -- > Bastien > From db33924b9439a5a787b30e985cf005ba11347642 Mon Sep 17 00:00:00 2001 From: stardiviner Date: Thu, 17 Dec 2020 08:19:35 +0800 Subject: [PATCH] org-contacts: Fix org-store-link error caused by org-contacts-link-store * contrib/lisp/org-contacts.el (org-contacts-link-store): Fix Org store link by adding missing condition for org-contacts. --- contrib/lisp/org-contacts.el | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/contrib/lisp/org-contacts.el b/contrib/lisp/org-contacts.el index 310166d53..44ba455c4 100644 --- a/contrib/lisp/org-contacts.el +++ b/contrib/lisp/org-contacts.el @@ -1157,8 +1157,8 @@ (org-link-set-parameters "org-contact" (defun org-contacts-link-store () "Store the contact in `org-contacts-files' with a link." - (when (eq major-mode 'org-mode) -;; (member (buffer-file-name) (mapcar 'expand-file-name org-contacts-files)) + (when (and (eq major-mode 'org-mode) + (member (buffer-file-name) (mapcar 'expand-file-name org-contacts-files))) (let ((headline-str (substring-no-properties (org-get-heading t t t t (org-store-link-props :type "org-contact" -- 2.29.2
Re: Bug: org-contacts.el: org-contacts-link-store breaks org-id [9.4.2 (release_9.4.2-307-g8840af @ /home/yantar92/.emacs.d/straight/build/org/)]
Does that means I can push to org-contacts.el directly by myself? That's simpler. Thanks. [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 Thu, Dec 17, 2020 at 1:03 PM Bastien wrote: > Ihor Radchenko writes: > > > stardiviner writes: > > > >> Sure, I didn't expected that soon bug appears. I checked source code, I > >> commented out an condition accidentally. > >> Here is the patch. Tested it should work now. > > > > What about adding support for org-id? Is it necessary to use headline > > text as a search string even when org-id is being used (and > > org-id-link-to-org-use-id is set to non-nil)? > > I don't know what's the best solution here, but stardiviner feel free > to commit patches yourself, as this is part of contrib/. > > -- > Bastien >
Re: [9.4] Fixing logbook visibility during isearch
Kévin Le Gouguec writes:
> I can't find any reference to this property in Org <9.4 (e.g. 9.3 as
> shipped in 27.1, where the bug does not happen) so do I understand
> correctly that the root cause ("since [drawers] are in the same overlay
> with the rest of the folded heading") dates from Org 9.4?
Yes, the root cause is that overlays used to hide drawers now
automatically merge with outline overlays. This was introduced in Org
9.4 to improve performance (too many overlays are handled badly by
Emacs).
> (Just trying to understand if I should keep looking at Org 9.3 for
> inspiration, or if your proposed solution based on
> isearch-open-invisible-temporary should be implemented from scratch)
You will probably need to implement this from scratch (or use the
feature/org-fold branch from github.com/yantar92/org).
In Org 9.3 the folded headline looked like the following:
* Headline
:PROPERTIES:
:PROPERTY1: value1
:PROPERTY2: value2
:END:
headline text
another line
When using isearch with "text" search string, the overlay containing
"text" is temporarily revealed by isearch (via setting 'invisible
property of the overlay to nil):
* Headline
:PROPERTES:
:PROPERTY1: value1
:PROPERTY2: value2
:END:
headline text
another line
As you can see, the drawer overlay remains unchanged and hidden.
In Org 9.4, drawer overlay does not exist when we fold the headline text
and isearch reveals everything.
To work around this issue, you need to hook into the way isearch reveals
hidden match by setting 'isearch-open-invisible-temporary property of
the overlays to custom function (you can set the property inside
org-flag-region). The function should re-hide the drawers when matching
text is not inside the drawer.
Best,
Ihor
Re: Bug: org-contacts.el: org-contacts-link-store breaks org-id [9.4.2 (release_9.4.2-307-g8840af @ /home/yantar92/.emacs.d/straight/build/org/)]
stardiviner writes: > Sure, I didn't expected that soon bug appears. I checked source code, I > commented out an condition accidentally. > Here is the patch. Tested it should work now. What about adding support for org-id? Is it necessary to use headline text as a search string even when org-id is being used (and org-id-link-to-org-use-id is set to non-nil)? Best, Ihor
Re: Bug: org-contacts.el: org-contacts-link-store breaks org-id [9.4.2 (release_9.4.2-307-g8840af @ /home/yantar92/.emacs.d/straight/build/org/)]
Ihor Radchenko writes: > stardiviner writes: > >> Sure, I didn't expected that soon bug appears. I checked source code, I >> commented out an condition accidentally. >> Here is the patch. Tested it should work now. > > What about adding support for org-id? Is it necessary to use headline > text as a search string even when org-id is being used (and > org-id-link-to-org-use-id is set to non-nil)? I don't know what's the best solution here, but stardiviner feel free to commit patches yourself, as this is part of contrib/. -- Bastien
Re: Bug: org-contacts.el: org-contacts-link-store breaks org-id [9.4.2 (release_9.4.2-307-g8840af @ /home/yantar92/.emacs.d/straight/build/org/)]
Supporting org-id has been considered. I will see is it easy to integrated it in. If simple, I will do it soon. Thanks for your suggestion. More detailed discussion can reference another thread in this mailing list. "More on design of org-contacts.el - Re: [UPDATED PATCH] Re: add new link type "contact:" for org-contacts.el" [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 Thu, Dec 17, 2020 at 11:26 AM Ihor Radchenko wrote: > > stardiviner writes: > > > Sure, I didn't expected that soon bug appears. I checked source code, I > > commented out an condition accidentally. > > Here is the patch. Tested it should work now. > > What about adding support for org-id? Is it necessary to use headline > text as a search string even when org-id is being used (and > org-id-link-to-org-use-id is set to non-nil)? > > Best, > Ihor > >
Re: Bug: org-contacts.el: org-contacts-link-store breaks org-id [9.4.2 (release_9.4.2-307-g8840af @ /home/yantar92/.emacs.d/straight/build/org/)]
I seems don't have permission to do `git push` directly. Got error: ``` 128 git … push -v upstream master\:refs/heads/master Pushing to code.orgmode.org:bzg/org-mode.git Gogs: You do not have sufficient authorization for this action fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. ``` Is this git address "g...@code.orgmode.org:bzg/org-mode.git" correct? I got from https://code.orgmode.org/bzg/org-mode. I also tried http protocol. Also failed with following error: ``` 1 git … push -v upstream master\:refs/heads/master Pushing to https://code.orgmode.org/bzg/org-mode.git Writing objects: 100% (5/5), 970 bytes | 970.00 KiB/s, done. Total 5 (delta 3), reused 0 (delta 0), pack-reused 0 POST git-receive-pack (1123 bytes) Icon theme "ubuntu-mono-dark" not found. Icon theme "Mint-X" not found. Icon theme "elementary" not found. POST git-receive-pack (1123 bytes) error: RPC failed; HTTP 401 curl 22 The requested URL returned error: 401 fatal: the remote end hung up unexpectedly fatal: the remote end hung up unexpectedly Everything up-to-date ``` [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 Thu, Dec 17, 2020 at 1:18 PM Bastien wrote: > stardiviner writes: > > > Does that means I can push to org-contacts.el directly by myself? > > Yes indeed. Thanks to you! > > -- > Bastien >
Re: error when archiving two subtrees in a row
Ian Garmaise writes: > When I archive one subtree (C-c $), the first one succeeds. > The second archive operation fails with a permission denied error as shown > in the messages buffer: [...] > Noticed this yesterday. Updated org and all packages, then tried it again > today, was able to reproduce it easily Hmm, was that an update from 9.3.* or earlier? 9.4 came with a new option org-archive-subtree-save-file-p. With the default value, the file is saved when archiving from an Org buffer but not the agenda. Before 9.4 [*], the file was never saved, so you could set org-archive-subtree-save-file-p to nil to restore the pre-9.4 behavior. That should sidestep the issue, though I don't know why you're hitting. I'm guessing you only see it with dropbox files? [*] Going farther back, the behavior was to always save. That changed in 9.1.4 63f6e851b (Do not save target buffer after archiving subtree, 2017-11-25).
Re: Bug: org-contacts.el: org-contacts-link-store breaks org-id [9.4.2 (release_9.4.2-307-g8840af @ /home/yantar92/.emacs.d/straight/build/org/)]
stardiviner writes: > I seems don't have permission to do `git push` directly. I just added you as a "collaborator" on bzg/org-mode. Please clone and push again. If things don't go right, let's sort this out in private. Thanks, -- Bastien
Re: unwanted files found by what exactly?
perhaps the list of existing buffers can be bound, then set-difference run on it before and after. then kill-buffer on the ones that remain. assuming no thread issues. commit 37a5020bbec1887f954ea61855e17b409ee7c5d0 Author: Nicolas Goaziou Date: 2020-05-14 22:48:17 +0200 On 12/15/20, Samuel Wales wrote: > could it be 37a5020bbec1887f954ea61855e17b409ee7c5d0 that does this by > finding instead of inserting into a temp buffer? > > On 12/15/20, Samuel Wales wrote: >> i suspect org-id-update-id-locations is finding but then failing to >> kill the buffers. >> > > > -- > The Kafka Pandemic > > Please learn what misopathy is. > https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html > -- The Kafka Pandemic Please learn what misopathy is. https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
Re: Bug: org-contacts.el: org-contacts-link-store breaks org-id [9.4.2 (release_9.4.2-307-g8840af @ /home/yantar92/.emacs.d/straight/build/org/)]
stardiviner writes: > Does that means I can push to org-contacts.el directly by myself? Yes indeed. Thanks to you! -- Bastien
[PATCH] org-attach: Consider inlinetasks when calculating attach dir
I have the following heading with attachments: * Headline :ATTACH: :PROPERTIES: :ID: some_id :END: Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. *** TODO how can I? *** END Etiam vel neque nec dui dignissim bibendum. When calling org-attach-open (C-c C-a f), in the above buffer, I get wrong attachment dir and stray property drawer below END: *** END :PROPERTIES: :ID: some_other_id :END: Etiam vel neque nec dui dignissim bibendum. Patch is attached. >From 530d7f705acce53ecb11afd7b7ae91bc65db417e Mon Sep 17 00:00:00 2001 From: Ihor Radchenko Date: Thu, 17 Dec 2020 14:03:30 +0800 Subject: [PATCH] org-attach: Consider inlinetasks when calculating attach dir * lisp/org-attach.el (org-attach): When inside inlinetask, return attachment dir of that task. When outside inlinetask, return attachment dir of the main task ignoring any inlinetasks above point. The call to `org-back-to-heading-or-point-min` does not move point to the actual heading when there is inlinetask above the point. The result is incorrect return value or even creation of property drawer below *...** END line of the last inline task before point. --- lisp/org-attach.el | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/lisp/org-attach.el b/lisp/org-attach.el index e6aa97e00..d117bdd22 100644 --- a/lisp/org-attach.el +++ b/lisp/org-attach.el @@ -256,7 +256,14 @@ Shows a list of commands and prompts for another key to execute a command." (unless marker (error "No item in current line"))) (org-with-point-at marker - (org-back-to-heading-or-point-min t) + (if (and (featurep 'org-inlinetask) + (not (org-inlinetask-in-task-p))) + (org-with-limited-levels + (org-back-to-heading-or-point-min t)) +(if (and (featurep 'org-inlinetask) + (org-inlinetask-in-task-p)) +(org-inlinetask-goto-beginning) + (org-back-to-heading-or-point-min t))) (save-excursion (save-window-excursion (unless org-attach-expert -- 2.26.2
Re: Bug: org-contacts.el: org-contacts-link-store breaks org-id [9.4.2 (release_9.4.2-307-g8840af @ /home/yantar92/.emacs.d/straight/build/org/)]
Ok, I added `org-id-link-to-org-use-id` support now. Check out the latest update in Git. [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 Thu, Dec 17, 2020 at 11:26 AM Ihor Radchenko wrote: > > stardiviner writes: > > > Sure, I didn't expected that soon bug appears. I checked source code, I > > commented out an condition accidentally. > > Here is the patch. Tested it should work now. > > What about adding support for org-id? Is it necessary to use headline > text as a search string even when org-id is being used (and > org-id-link-to-org-use-id is set to non-nil)? > > Best, > Ihor > >
Re: [PATCH] org-attach: Consider inlinetasks when calculating attach dir
Applied (de6d90224), thanks. -- Bastien
Re: Bug: org-contacts.el: org-contacts-link-store breaks org-id [9.4.2 (release_9.4.2-307-g8840af @ /home/yantar92/.emacs.d/straight/build/org/)]
stardiviner writes: > Ok, I added `org-id-link-to-org-use-id` support now. Check out the latest > update in Git. Thanks! The issue seems to be fixed for me.
bibtex and babel support
Hello,
I am confused over org-mode's babel support for bibtex, or if indeed
there is support.
I can tangle src blocks
#+begin_src bibtex :tangle file.bib
@BOOK{Key:XX,
AUTHOR = {},
TITLE = {},
.
.
}
#+end_src
to obtain a bibtex formatted file file.bib. I find this very useful in
making annotated book catalogues. However, tangling bibtex src blocks
works without an explicit (bibtex . t). Indeed if I do insert such a
line in my emacs init file, I get an error with "(require ob-bibtex) not
found". I assume therefore there no ob-bibtex file - an Index topic
search in org-mode info for "ob-bibtex" produces no results.
Although the tangle of bibtex src blocks works well, the block itself
often seem to have fontlock issues and sometimes it seems not to accept
the standard bibtex comment, which begins with @ followed by a space and
then text.
I am using org-9.4.2.
Thanks
Colin Baxter.
[PATCH] ob-gnuplot: Fix error on non-string :var assignment
The following gnuplot code stopped working after recent commits adding support of remote files: #+CALL: stress-strain[:file stress-displ-RD-11.png](A=0.87, alpha=38.0, beta=7.0, inp="p11 DC.txt", tbl="stress-displ-RD-11.txt") Note that the code assigns several numerical variables. ob-gnuplot from master throws error when checking (file-remote-p ...). The fix is attached. Best, Ihor >From 8840afe1446177e5355e190fcaf6ce79d00ac0c6 Mon Sep 17 00:00:00 2001 From: Ihor Radchenko Date: Wed, 16 Dec 2020 16:23:41 +0800 Subject: [PATCH] ob-gnuplot: Fix error on non-string :var assignment * lisp/ob-gnuplot.el (org-babel-gnuplot-process-vars): Consider that not all the variable values must be a string in :var assignments. --- lisp/ob-gnuplot.el | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lisp/ob-gnuplot.el b/lisp/ob-gnuplot.el index d0cedb7a3..708ac97e4 100644 --- a/lisp/ob-gnuplot.el +++ b/lisp/ob-gnuplot.el @@ -94,7 +94,8 @@ code." (tablep (or (listp first) (symbolp first (if tablep val (mapcar 'list val))) (org-babel-temp-file "gnuplot-") params) - (if (and (file-remote-p val) ;; check if val is a remote file + (if (and (stringp val) + (file-remote-p val) ;; check if val is a remote file (file-exists-p val)) ;; call to file-exists-p is slow, maybe remove it (let* ((local-name (concat ;; create a unique filename to avoid multiple downloads org-babel-temporary-directory -- 2.26.2
Re: behavior/docs of iCalendar export
On Tuesday, 15 Dec 2020 at 16:37, Carson Chittom wrote: > I've just started playing with the iCalendar export because eventually > I want to keep everything in Org, to then get transformed and pushed > to my CalDAV server, which then gets pushed to my phone. You might like to try org-caldav-sync (available from melpa) if you ever wish to have 2 way synchronisation. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4.2-143-gc822c8
Re: Bug: org-contacts.el: org-contacts-link-store breaks org-id [9.4.2 (release_9.4.2-307-g8840af @ /home/yantar92/.emacs.d/straight/build/org/)]
Hi, Ihor Radchenko writes: > When using org-contacts and org-id simultaneously, org-contacts > unconditionally makes org-store-link use file:name.org:*Headline link > style instead of id:UUID link style expected when using org-id. The > problem does not only appears when storing links to contact.org > headlines, but for any headlines. > > Probably, org-contacts should be integrated with org-id or at least not > interfere with links to ordinary headlines. Agreed. Stardiviner, can you have a look? Thanks, -- Bastien
Re: bibtex and babel support
On Wednesday, 16 Dec 2020 at 08:19, Colin Baxter wrote: > However, tangling bibtex src blocks works without an explicit (bibtex > . t). Good. As it should. > Indeed if I do insert such a line in my emacs init file, I get > an error with "(require ob-bibtex) not found". But there is no need for such a line as bibtex src blocks cannot be evaluated. org babel makes no sense in this case. > Although the tangle of bibtex src blocks works well, the block itself > often seem to have fontlock issues and sometimes it seems not to accept > the standard bibtex comment, which begins with @ followed by a space and > then text. This will be a bibtex-mode issue, not an org issue? Does it font lock correctly if you edit the src block in bibtex mode? Just to say that I use bibtex src blocks a lot but I also use the functionality found in ol-bibtex.el for creating bib files from org properties. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4.2-143-gc822c8
Re: [PATCH] ob-gnuplot: Fix error on non-string :var assignment
Hi Ihor, Ihor Radchenko writes: > The following gnuplot code stopped working after recent commits adding > support of remote files: > > #+CALL: stress-strain[:file stress-displ-RD-11.png](A=0.87, alpha=38.0, > beta=7.0, inp="p11 DC.txt", tbl="stress-displ-RD-11.txt") > > Note that the code assigns several numerical variables. ob-gnuplot from > master throws error when checking (file-remote-p ...). > > The fix is attached. Applied on master (baf1e7a64), thanks! -- Bastien
Re: ox-slimhtml
Hi Laszlo, thanks for ox-slimhtml.el and for announcing it on the list. > Amin was kind enough to poke me to submit and post about my package, > ox-slimhtml. > In a nutshell, it is an org-export backend - transcodes Org elements to > HTML/text output. > > My primary use for it, is to create derived export backends. (picture a/b > testing, for example) > By default, it outputs HTML5, essentially (as it tries to not ignore current > output preferences). > > Within each transcoder, I tried to pick out the relevant core elements > being passed through - what I skipped from the original ox-html > exporter is the domain logic surrounding templating and navigation. > > A sample of the output can be seen here http://bald.cat/ox-slimhtml/ > > From a more detailed perspective, I use it to template the output of > some Org documents (common sources of truth); these include some > minimal Org markup, and as such, they provide convenient > element-by-element programmatic access. This all depends on where > you’d like to organize the logic behind each elements’ transcoding > process, of course - so, for now, I’ll say that it works really nice > for me. YMMV I encourage everyone to try exporting Org documents to HTML using your library and see how it compares with ox-html.el for a daily usage. Thanks! -- Bastien
Re: Emacs as an Org LSP server
TEC writes: > A little progress update. > > https://github.com/tecosaur/org-lsp now exists. I encourage everyone to work with Timothy on how to make real progress on org-lsp. If needed so, please use https://github.com/tecosaur/org-lsp for reporting issues and suggestions. Timothy, I'm removing this thread from the "Help requests" section on updates.orgmode.org, because perhaps the code is not mature enough to receive concrete help -- but feel free to reopen another call when it is a good time. Thanks, -- Bastien
Re: bibtex and babel support
Dear Eric, Thanks for the reply. > Eric S Fraga writes: > On Wednesday, 16 Dec 2020 at 08:19, Colin Baxter wrote: >> However, tangling bibtex src blocks works without an explicit >> (bibtex . t). > Good. As it should. >> Indeed if I do insert such a line in my emacs init file, I get an >> error with "(require ob-bibtex) not found". > But there is no need for such a line as bibtex src blocks cannot > be evaluated. org babel makes no sense in this case. Yes, I thought that at the time. I think I was thrown by the initial error message, which prompted me to think that a file called "ob-bibtex.el" existed or had existed, and this would add some sort of functionality that I had yet to understand. >> Although the tangle of bibtex src blocks works well, the block >> itself often seem to have fontlock issues and sometimes it seems >> not to accept the standard bibtex comment, which begins with @ >> followed by a space and then text. > This will be a bibtex-mode issue, not an org issue? Does it font > lock correctly if you edit the src block in bibtex mode? This turns out to be a red herring. I find I can edit the source blocks and insert appropriate comment lines using C-c '. I forgot about this and was editing the source blocks directly in the org file. > Just to say that I use bibtex src blocks a lot but I also use the > functionality found in ol-bibtex.el for creating bib files from > org properties. Yes ol-bibtex.el is good but doesn't fit my purpose. I use non-standard bib fields - such as "illustrations", "binding", "condition", etc. - that are not in available properties of ol-bibtex.el. Thanks again for your help - I feel I understand things a little better. Colin. Colin Baxter URL: http://www.Colin-Baxter.com - GnuPG fingerprint: 68A8 799C 0230 16E7 BF68 2A27 BBFA 2492 91F5 41C8 - Since mathematicians have invaded the theory of relativity, I do not understand it myself. A. Einstein
Re: Bring up a screen giving option to open a series of orgmode files
2020-12-15 Ihor Radchenko wrote: > Then, packages like org-pdftools would not need to invent new link types just to be able to refer to specific page or annotation inside a pdf file. Firefox (I do not know if pdf.js is cut off from IceCat) have a special button to obtain link like file:///path/to/file.pdf#page=5=310,131,734 Chromium handles page=N part successfully. Unfortunately vertical axis has the opposite direction. Exactly the same discrepancy of vertical offset notion I have noticed with xpdf vs. pdftotext. I suppose, it is reasonable to have #page=N form at least in exported documents. A simple wrappers should allow other applications to open files at the specified page. Anyway every desktop PDF viewer has its own way to specify page number. I do not think that either of browsers would agree to change base point of vertical offset. Maybe additional parameter could be added to specify direction and to avoid ambiguity.
