RE: attachment: link type export to HTML invalid attach dir
Hi Bastien and Nicolas, > -Original Message- > From: Bastien > Sent: den 22 februari 2020 14:32 > To: Nicolas Goaziou > Cc: Gustav Wikström ; emacs-orgmode@gnu.org > Subject: Re: attachment: link type export to HTML invalid attach dir > > [...] > > Nicolas Goaziou writes: > > > I'd like to hear from Gustav, too, since this affects the changes he > > introduced. If you are in a hurry, we can also apply it. Up to you. > > I just applied it - Gustav let us know if it fits your needs and if it > does not introduce regressions. It does work. Thanks. One issue though, with org-attach-expand-links: +(defun org-attach-expand-links (_) + "Expand links in current buffer. +It is meant to be added to `org-export-before-parsing-hook'." + (save-excursion +(while (re-search-forward "attachment:" nil t) + (let ((link (org-element-context))) + (when (and (eq 'link (org-element-type link)) + (string-equal "attachment" +(org-element-property :type link))) + (let* ((description (and (org-element-property :contents-begin link) + (buffer-substring-no-properties + (org-element-property :contents-begin link) + (org-element-property :contents-end link +(file (org-element-property :path link)) +(new-link (org-link-make-string + (concat "attachment:" (org-attach-expand file)) + description))) + (goto-char (org-element-property :end link)) + (skip-chars-backward " \t") + (delete-region (org-element-property :begin link) (point)) Expanding attachment-links in the buffer makes the link type no longer be attachment. I would prefer if we explicitly set the link type to files here instead. Storing intermediate state in an attachment link types makes less sense imo. One issue with the current way it's done is that images are treated differently between attachment links and file links. For HTML exports, file links are wrapped in a div with class figure where expanded attachment links are not. Letting org-attach-expand-links do the full transform to file links would solve that issue. That also means :export is not needed for org-link-set-parameters. Patch attached if you agree to this. > >> Do you want to do this for 9.4 or can it be done later on? > > > > This can be done later on. I don't have time to work on this. Of > > course, if someone wants to do it, that would be great, too. > > Okay, thanks. Noted for Org > 9.4. > > Best, > > -- > Bastien org-attach.patch Description: org-attach.patch
Re: Document backward-incompatible change in ORG-NEWS?
Hi Nicolas, Nicolas Goaziou writes: > You are right. This deserves an entry in ORG-NEWS. thanks for your feedback, I've added this entry: https://code.orgmode.org/bzg/org-mode/commit/1a84a8b611 > I think this is inefficient. It would be better to search directly for > > (format "\\[\\[\\*%s\\s-+" (regexp-opt org-todo-keywords-1 t)) Indeed... I've pushed a simpler version, feel free to enhance it. >>(setq new (replace-regexp-in-string >> (concat (regexp-opt org-todo-keywords-1) "\\s-+") >> "" raw)) >>(set-text-properties 0 (length new) nil new) > > Why do you remove all text properties? Also, see `org-no-properties'. For the record, it seems that completing-read fifth argument cannot be a string with properties - at least from the quick test I did. Thanks, -- Bastien
Re: correct remote path handling
Hi Felipe and Jack, > Felipe Lema writes: > >> I've signed the necessary papers from (to?) the FSF involving org >> mode, so I'm ready on my side to add tests and maybe add support >> for other tramp-related stuff. I've checked and the papers are not yet processed by the FSF. > Great, we should add you to the list of copyrighted contributors: > https://orgmode.org/worg/org-contribute.html Done - https://orgmode.org/worg/org-contribute.html#org7c578f2 Let's iterate on this patch and get it ready for 9.5. Thanks, -- Bastien
Re: Best strategy for sharing agenda between two machines?
On Monday, 24 February 2020 22:04:52 CET Stig Brautaset wrote:
> I could use a different default agenda file for each machine, since the
> inbox.org is worst affected. Is anyone doing this? I could extend this
> to use {work,home}_tasks.org too, but I kinda like having that "neither
> @work nor @home" option... Decisions decisions.
Hi
probably not want you want, since it is not a pure emacs solution (maybe could
be adapted). For my org agenda files I have the following set-up:
1. One directory ("DIR1") with a collection of org agenda files that are parsed
at work and at home
2. One directory ("DIR2") I use only for work (since I am not allowed to store
work related things on outside servers)
3. Host specific emacs config files that declare the agenda files separately
for
each host (home machines and work machines) The functions for these are more
or less those from E. Schultes 24.1 emacs starter kit. in these config files
only the settings that differ between hosts are in, all other config is
identical for the different machines.
4. Sync only DIR1 via my nextcloud server with the desktop sync client.
So, at work machine I have all agenda files DIR1 + DIR2. DIR1 also includes
diary and the refile file (set-up similar to B. Hansen). At home I have only
the
DIR1 files synced
So in a nut-shell, this set-up requires additional host specific config,
separation of org directories work/home and a file syncer (the set-up might
work with git, but I never tried that).
Maybe this gives some idea, even if not what you look for
gl
Re: correct remote path handling
Hi Felipe, Felipe Lema writes: > I bumped into a problem running src blocks using a remote (tramp) :dir. I've > looked into it and found that the problem is that a temporary file is passed > as a remote path to the remote process (temp file should be local to remote > process). Thanks for finding this bug and submitting a patch to fix it. > I'm attaching fixes for python and shell src blocks. I didn't add any tests > because that would require more than 15 LOC. I think it would be difficult to test for this, so I wouldn't worry too much about it, but if you have ideas for how to do it that'd be great. > I've signed the necessary papers from (to?) the FSF involving org mode, so > I'm > ready on my side to add tests and maybe add support for other tramp-related > stuff. Great, we should add you to the list of copyrighted contributors: https://orgmode.org/worg/org-contribute.html CC'ing Bastien in case he wants to verify everything by private message first. > fix evaluate python code in remote directory > > Evaluating an "AST python code" should be local to the process / > directory. > > `file-local-name` will do just this (strip the tramp prefix in path) Please see https://orgmode.org/worg/org-contribute.html#commit-messages for information on how to properly format commit messages. You can also take a look at the git log for examples. > -tmp-src-file > +(file-local-name > + tmp-src-file) Instead of `file-local-name', the preferred function we use for this is `org-babel-process-file-name'. It's used in a few other places in ob-python.el as well. It looks like this patch only handles the ":session :results value" case, but ":session :results output" also suffers from this problem, could you add a fix for that case as well? For example, I tried to execute the following ":session :results output" block within a remote Org file, with the following result: #+begin_src python :session :results output x = 1+1 x #+end_src #+RESULTS: : Traceback (most recent call last): : File "", line 1, in : IOError: [Errno 2] No such file or directory: '/scp:pi:/tmp/python-NJwf2U' > -(format "%s %s" shell-file-name script-file)) > +(format "%s %s" shell-file-name > +(file-local-name script-file))) As noted above, use `org-babel-process-file-name' instead of `file-local-name'. Also, I'm not sure the shell case is totally fixed by this, for example trying to execute the following shell block within a remote Org file still yields the error, even after applying your patch: #+begin_src shell :shebang "#!/usr/bin/bash" echo foo #+end_src /bin/sh: 1: /scp:pi:/tmp/sh-script-8Z5fw7: not found
Re: Exploring properties
You might take a look at ebib, which is something like this for bibtex
files (also a plain text db). You can bend bibtex into being a database,
with custom entry types. What ebib does for bibtex might also be
possible for recutils too.
Similarly, bbdb offered an emacsy interface to a database of contacts (I
think just stored as elisp code).
elfeed has a git like database structure it uses to store things in, and
a front-end for displaying them.
For recutils, one could make a temporary org buffer full of recutil
entries in org syntax. Then, you could edit it, and write it back out, I
guess from a save-buffer-hook. The main benefit of this in my mind is
editing many records at a time, leveraging the search/navigation/outline
view of org-mode. I guess a row in a table per entry is all that could
be reliably done without a custom template that would allow you to
create headings per row. A table might be awkward for multiline entries
though. There is already a rec-mode with recutils that provides features
for editing, navigating, etc. within a rec file. I guess you can't edit
several entries at a time though.
The downside of headings might be then you also need custom code to
write it out. I guess this also goes by creating a list of sexp entries
that can be written out.
One simple application might be a recutils contact database, based on
org-contacts. These are basically headings with EMAIL properties, where
the heading is the contact name. You might also save tags in the entry,
and any other properties. You could store the body of the heading as
well. Some one will have to see how it scales with contacts, if it is
easy to search, etc.
Why contacts? org-contacts works ok, if you don't have too many, and
they aren't in too many files. I have 5000+ org-contacts spread all over
the place, so I have to use a cache (i.e. db) that is fast to query to
use them. If recutils was good for that, it might work for me.
Vikas Rawal writes:
> I don't know if this is useful. But this is what I could come up with. This
> might at least motivate somebody to think of other possible advantages/uses
> of building org-mode capabilities to interact with databases.
>
> Vikas
>
> ---
>
> Feature request: To build tools to facilitate using org-mode as a front-end
> for interacting with a database.
>
> The idea would be to use org-mode to select, insert and update records in a
> database. It is natural to think of recutils, a plain text database, as the
> database backend. But a more generalised solution may allow other choices of
> databases. With a text-based database backend like recutils, we could harness
> a version control system like git to semi-automate collaboraion.
>
> Why would one use org-mode for creating a database application? One can think
> of many advantages. But the biggest advantage (to me) would be that, in this
> setup, a multi-user database application can work without constant internet
> connectivity. You can query recutils files, insert/update records, and then
> let git deal with synchronisation across the team members.
>
> There are other advantages as well. We do not yet have a text-based,
> easy-to-deploy database application system. Recutils provides the
> infrastructure for a backend. But we do not have a fully-developed
> front-end system to interact with recutils. Org-mode is clearly best
> placed to provide the frontend for working with recutils.
>
> Needless to say, this would be particularly interesting to members of the
> org-mode/emacs fan-club. Over the last few years, org-mode has come to be
> used for many tasks that go way beyond what Carsten had in mind when he first
> built org-mode. From web-publishing to writing books, org-mode provides
> excellent tools. Being able to create and use databases from within org-mode
> would be a very useful addition to this toolkit.
>
> We already have tools that can be used to read data from recutils (and other
> databases) and create reports in org-mode. The missing feature is to be able
> to use org-mode to create/update records systemmatically.
>
> There are two possibilities here: to use org-mode tables or org-mode
> properties to interact with the database. The advantage of doing this using
> the org-mode properties is that the column-view of properties provides an
> easy to use interface for entering data. There is already a mechanism for
> defining "Allowed" values for any field which speeds up data entry and helps
> avoid typing errors.
>
> There are several challenges. Some of these are:
>
> 1. Extending "Allowed" values to specify type of data that can be recorded
> (numeric, char) or range of values.
> 2. How to deal with relationships/foreign keys. Can property inheritance be
> used to deal with at least simple foreign key constraints?
> 3. Org-mode macros provide {{{property(PROPERTYNAME)}}} syntax for macro
> replacement during export. But nothing as simple as this is available for use
> in source code
Re: Document backward-incompatible change in ORG-NEWS?
Hello, Bastien writes: > This is fixed in master but I won't if we should document this bug > fix in ORG-NEWS (or if org-store-link was just momentarily broken.) You are right. This deserves an entry in ORG-NEWS. > If org-store-link was storing the todo keyword, perhaps we can add > a command similar to this one to help users fix broken links: > > (defun org-fix-links () > "Fix ill-formatted internal links. > E.g. replace [[*TODO Headline][headline]] by [[*Headline][headline]]. > Go through the buffer and ask for the replacement." > (interactive) > (visible-mode 1) > (save-excursion > (goto-char (point-min)) > (while (re-search-forward org-link-any-re nil t) I think this is inefficient. It would be better to search directly for (format "\\[\\[\\*%s\\s-+" (regexp-opt org-todo-keywords-1 t)) > (let* ((raw (match-string 2)) >(desc (match-string 3)) >fix new) > (when (and raw desc Why does DESC matter here? We probably want to also replace [[*TODO foo]] > (string-match-p > (concat "^\*" (regexp-opt org-todo-keywords-1) Typo: the correct regexp is "^\\*" > "\\s-+\\(.+\\)$") > raw)) > (setq new (replace-regexp-in-string >(concat (regexp-opt org-todo-keywords-1) "\\s-+") >"" raw)) > (set-text-properties 0 (length new) nil new) Why do you remove all text properties? Also, see `org-no-properties'. Regards, -- Nicolas Goaziou
