[FWD from emacs-orgmode] Re: Bug: About org-submit-bug-report [9.3 (release_9.3 @ /usr/local/share/emacs/27.0.50/lisp/org/)]
[Forwarding this to emacs-devel] The naming convention for mode-specific bug reporting seems to be confusing. The bug reporting functions are often not easy to discover without knowing the explicit command name (especially with emacs default completion interface). For example see recent message in emacs-orgmode (below). > I want to suggest to make `report-org-bug' and alias for the command > `org-submit-bug-report'. That's the name I expected (considering > "report-emacs-bug"), also some other Emacs packages name their bug > reporting command according to this scheme. The additional name would > make this important command more discoverable. Another convention for bug report command is *mode*-report-bug/*mode*-bug-report: calc-report-bug reftex-report-bug eshell-report-bug gnuplot-bug-report c-submit-bug-report Though several modes are also using the naming similar to org-submit-bug-report: c-submit-bug-report diredp-send-bug-report org-edna-submit-bug-report I am thinking if it would make sense to develop more standardised command name conventions for bug reporting and add them to (elisp)Emacs Lisp:Preparing Lisp code for distribution Then, the built-in emacs packages might be changed to follow those conventions and improve discoverability of bug reporting capabilities. Also, an information that different major modes may have they own bug reporting tools might be mentioned in the default template shown in report-emacs-bug. What do you think? Regards, Ihor Michael Heerdegen writes: > Hello, > > I want to suggest to make `report-org-bug' and alias for the command > `org-submit-bug-report'. That's the name I expected (considering > "report-emacs-bug"), also some other Emacs packages name their bug > reporting command according to this scheme. The additional name would > make this important command more discoverable. > > Second point: When you think it is a trivial task for a common user > please consider to add some text to the initial buffer contents of the > message buffer created by this command explaining where one can search > for existing reports (to avoid duplicates and reports about things that > are just pitfalls etc). My buffer included a link to a page explaining > how to create a good report but there this information is also missing, > although I think it would be a good place. > > TIA, > > Michael. > > Emacs : GNU Emacs 27.0.50 (build 41, x86_64-pc-linux-gnu, GTK+ Version > 3.24.13) > of 2019-12-20 > Package: Org mode version 9.3 (release_9.3 @ > /usr/local/share/emacs/27.0.50/lisp/org/) >
[PATCH] ox-odt.el: (org-odt-template): Get write permissions on styles.xml
Hello Org! I attached a patch that is required to get ox-odt to work on guix/nix/other distributions where package files are placed in a read-only directory. After the file styles.xml is copied to /tmp, now we set read-write permissions to it before trying to write it. Before this patch, we got the error: 'OpenDocument export failed: Buffer is read-only: #'. It's my first patch and is just 1 line long, so following instructions on https://orgmode.org/worg/org-contribute.html#commit-messages I added the TINYCHANGE cookie. Tests (make test) are passing. Thanks! Nicolò >From a80be4da6880443f2b947ade03092699fa24c846 Mon Sep 17 00:00:00 2001 From: nixo Date: Fri, 20 Dec 2019 11:45:11 +0100 Subject: [PATCH] ox-odt.el: (org-odt-template): Get write permissions on styles.xml To: emacs-orgmode@gnu.org (org-odt-template): The file `styles.xml' might be copied from a location where it is read-only. Since we need to modify it (and its copied under /tmp, so we can modify it), we need to ensure we have write persmissions on it. Set mode to 600. This is especially needed for projects like guix, where all system files are stored in a read-only location. TINYCHANGE --- lisp/ox-odt.el | 2 ++ 1 file changed, 2 insertions(+) diff --git a/lisp/ox-odt.el b/lisp/ox-odt.el index f9c4a93cc..b8e228246 100644 --- a/lisp/ox-odt.el +++ b/lisp/ox-odt.el @@ -1383,6 +1383,8 @@ original parsed data. INFO is a plist holding export options." ;; create a manifest entry for styles.xml (org-odt-create-manifest-file-entry "text/xml" "styles.xml") +;; ensure we have write permissions to this file +(set-file-modes (concat org-odt-zip-dir "styles.xml") #o600) ;; FIXME: Who is opening an empty styles.xml before this point? (with-current-buffer -- 2.24.0
Re: Properties Drawer versus tags
On Fri, Dec 20, 2019 at 3:25 PM Lawrence Bottorff wrote: > > Very simple, largely philosophical question: When/why use a properties drawer > below a heading versus just using tags on the heading? What are the > advantages, disadvantages of both? I believe tag filtering has better performance than property filtering. Also, I think that tags were initially designed/intended primarily for filtering in agenda views (more wizened users can correct me on both points). Tags also have better visibility, as they are visible by default on each heading line in the buffer and in the agenda. > > LB
very strange LaTeX error
Hello all,
this may not belong in this mailing list as it's arguably a LaTeX issue
but I'm having a problem exporting a table to PDF via LaTeX. I hope
somebody can help me out.
I've reduced my problem file to a small (hopefully minimal) example and
verified this with emacs -Q, using emacs 27.x which comes with org 9.3:
#+begin_src org
,* some results
,#+name: atable
|+--+--+-|
| x | z1 | z2 | g |
|+--+--+-|
| [0.0005, 0.05, 0.5]| 9.0 | 0.05 | 0.0 |
| [0.000787451, 0.0575948, 0.5] | 11.0 | 0.05759476698672508 | 0.0 |
|+--+--+-|
#+end_src
If I export this to LaTeX, I get something that looks reasonable (elided):
#+begin_src latex
\documentclass{scrartcl}
\begin{document}
% packages deleted, none of which is used anyway in the following
\tableofcontents
\section{some results}
\label{sec:org4f5891c}
\begin{table}[hbtp]
\label{atable}
\centering
\begin{tabular}{lrrr}
\hline
x & z1 & z2 & g\\
\hline
[0.0005, 0.05, 0.5] & 9.0 & 0.05 & 0.0\\
[0.000787451, 0.0575948, 0.5] & 11.0 & 0.05759476698672508 & 0.0\\
\hline
\end{tabular}
\end{table}
\end{document}
#+end_src
I get errors like this when compiling with pdflatex:
#+begin_example
! Illegal unit of measure (pt inserted).
,
l.18 [0.000787451, 0.0575948, 0.5]
& 11.0 & 0.05759476698672508 & 0.0\\
! Missing = inserted for \ifdim.
#+end_example
What am I doing wrong? If LaTeX cannot handle [...] in a table (it has
no problem with similar text in a normal paragraph), the LaTeX exporter
should do something about this. But I do not see why LaTeX should have
a problem in any case. Any pointers welcome!
Note: LaTeX does not complain about the first line in the table, only
the second (and following ones in the original org file from which I
took this code snippet).
Thank you.
--
Eric S Fraga via Emacs 27.0.50, Org release_9.3-34-g2eee3c
Re: very strange LaTeX error
On Fri, Dec 20, 2019, at 12:56 PM, Fraga, Eric wrote:
> #+begin_src latex
> \documentclass{scrartcl}
> \begin{document}
> % packages deleted, none of which is used anyway in the following
> \tableofcontents
>
> \section{some results}
> \label{sec:org4f5891c}
> \begin{table}[hbtp]
> \label{atable}
> \centering
> \begin{tabular}{lrrr}
> \hline
> x & z1 & z2 & g\\
> \hline
> [0.0005, 0.05, 0.5] & 9.0 & 0.05 & 0.0\\
> [0.000787451, 0.0575948, 0.5] & 11.0 & 0.05759476698672508 & 0.0\\
> \hline
> \end{tabular}
> \end{table}
> \end{document}
> #+end_src
>
> I get errors like this when compiling with pdflatex:
>
> #+begin_example
> ! Illegal unit of measure (pt inserted).
>
> ,
> l.18 [0.000787451, 0.0575948, 0.5]
> & 11.0 & 0.05759476698672508 & 0.0\\
> ! Missing = inserted for \ifdim.
>
> #+end_example
>
> What am I doing wrong?
You have `[...]` in the first cell of a table row that is not the first row.
Few people seem to realise that the double backslash `\\` in LaTeX is a macro
that can actually take an optional argument, a measure specifying the height of
the newline. So when a table row ends in `\\` (which is the normal case) and
the next row starts with an opening bracket, LaTeX assumes it is looking at an
optional argument and expects a measure, i.e., a number followed by one of the
supported units.
The solution I usually opt for is to enclose the brackets in an additional set
of braces: `{[...]}`. Whether Org export can and should automate that, I can't
say.
HTH
--
Joost Kremers
Life has its moments
Re: very strange LaTeX error
"Joost Kremers" writes:
> The solution I usually opt for is to enclose the brackets in an
> additional set of braces: `{[...]}`. Whether Org export can and
> should automate that, I can't say.
In the generated LaTeX adding a '\relax' (so each line ends with
'\\\relax') would be a another solution. The \relax ends the
macro-expansion and thus '\\' does not look further for optional
arguments.
As the org-table does not support all the fancy features of LaTeX
tables and the LaTeX row/line break is generated implicitly, I would
say the LaTeX export should always emit the additional \relax.
--
Until the next mail...,
Stefan.
Re: very strange LaTeX error
On Friday, 20 Dec 2019 at 13:33, Joost Kremers wrote: > Few people seem to realise that the double backslash `\\` in LaTeX is > a macro that can actually take an optional argument, a measure > specifying the height of the newline. Ah ha! That makes perfect sense. Thank you. -- Eric S Fraga via Emacs 27.0.50, Org release_9.3-34-g2eee3c
Bug: org-babel-execute:emacs-lisp does not allow changing window configuration from within code block [9.3 (release_9.3 @ /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. Recipe: 1. emacs -Q 2. Create the following org file #+begin_src emacs-lisp (split-window-below) #+end_src 3. Execute the source block Observed behaviour: The block returns, but the window is not splitted Expected behaviour: The window is splitted The reason of the observed behaviour is that org-babel-execute:emacs-lisp wraps the code block evaluation into save-window-excursion. Thus window manipulation is impossible from within babel blocks. The real case scenario when one would need to change window layout from within babel block is a window setup for a project development. If certain project requires working with specific window configuration, this can be defined by adding all the setup into a babel block somewhere in the project. Then, the layout could be applied just by hitting C-c C-c on the code block once one need to work on the project. However, it is not possible with the current org-babel-execute:emacs-lisp implementation. Best regards, Ihor Emacs : GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0) of 2019-12-17 Package: Org mode version 9.3 (release_9.3 @ /home/yantar92/.emacs.d/straight/build/org/) -- Ihor Radchenko, PhD, Center for Advancing Materials Performance from the Nanoscale (CAMP-nano) State Key Laboratory for Mechanical Behavior of Materials, Xi'an Jiaotong University, Xi'an, China Email: yanta...@gmail.com, ihor_radche...@alumni.sutd.edu.sg
Bug: org-agenda-open-link disallow permanenly changing point position while opening some links (e.g. elisp:) [9.3 (release_9.3 @ /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. Recipe: 1. emacs -Q 2. Open the following org file * TODO 1 elisp:end-of-buffer ** TODO 2 blah 3. M-x org-agenda < t 4. Move point to "TODO 1" in agenda 5. C-c C-o yes Expected behaviour: The point in the org file moves to the end of the file Observed behaviour: The point does not move The cause of the observed behaviour is the following code in org-agenda-open-link: (with-current-buffer buffer (setq trg (and (string-match org-link-bracket-re l) (match-string 1 l))) (if (or (not trg) (string-match org-link-any-re trg)) (org-with-wide-buffer (goto-char marker) (when (search-forward l nil lkend) (goto-char (match-beginning 0)) (org-open-at-point))) ;; This is an internal link, widen the buffer (switch-to-buffer-other-window buffer) (widen) (goto-char marker) (when (search-forward l nil lkend) (goto-char (match-beginning 0)) (org-open-at-point The code opens the link in two ways depending whether the link is "internal link" or not. If it is not "internal", following the link is enclosed into save-excursion (from org-with-wide-buffer). Thus, the moving point does not have any effect when following some links In my real life scenario, I have a custom link, which executes some elisp to add a new row in a table from the current item and move the point to that table. However, there is no way to keep the point position with the current org-agenda-open-link implementation, unless the condition for "internal link" is broadened. Best regards, Ihor Emacs : GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0) of 2019-12-17 Package: Org mode version 9.3 (release_9.3 @ /home/yantar92/.emacs.d/straight/build/org/) This email may contain confidential and/or proprietary information that is exempt from disclosure under applicable law and is intended for receipt and use solely by the addressee(s) named above. If you are not the intended recipient, you are notified that any use, dissemination, distribution, or copying of this email, or any attachment, is strictly prohibited. Please delete the email immediately and inform the sender. Thank You
Re: Properties Drawer versus tags
On 2019-12-19 at 22:24 -08, Lawrence Bottorff wrote... > Very simple, largely philosophical question: When/why use a properties > drawer below a heading versus just using tags on the heading? What are > the advantages, disadvantages of both? Tags are binary. They are there or not. Property drawers allow you to assign values to variables. I've never fully understood why some property drawers are set to binary. For controlling LaTeX export I have both a property ":clearpage: t" and a tag ":ignore:", and the tag makes more sense to me. Some of those may only exist in my personal config. -k.
Re: very strange LaTeX error
On Friday, 20 Dec 2019 at 15:29, Stefan Nobis wrote: > As the org-table does not support all the fancy features of LaTeX > tables and the LaTeX row/line break is generated implicitly, I would > say the LaTeX export should always emit the additional \relax. I agree. I shouldn't have to be this aware of LaTeX idiosyncrasies to export what looks like a straightforward table! However, it seems that simply adding \relax does not work if there is an \hline immediately following so the solution is not that straightforward. Thanks again, eric -- Eric S Fraga via Emacs 27.0.50, Org release_9.3-34-g2eee3c
Re: very strange LaTeX error
"Fraga, Eric" writes: > However, it seems that simply adding \relax does not work if there > is an \hline immediately following so the solution is not that > straightforward. Hmmm... but it should be solvable. Maybe something along the lines of this (rough sketch, I have next to no experience with the org code base): #+begin_src emacs-lisp (defun org-latex--table-newline (table-row info) (let ((next-el (org-export-get-next-element table-row info))) (concat "" (when (and next-el (not (eq (org-element-property :type next-el) 'rule))) "\\relax") "\n"))) #+end_src -- Until the next mail..., Stefan.
Re: Properties Drawer versus tags
I might add that a properties/drawer is a sort of "official heading metadata repo," while tags not so much. It would be nice to see (lots of) examples. On Fri, Dec 20, 2019 at 9:18 AM Ken Mankoff wrote: > > On 2019-12-19 at 22:24 -08, Lawrence Bottorff > wrote... > > Very simple, largely philosophical question: When/why use a properties > > drawer below a heading versus just using tags on the heading? What are > > the advantages, disadvantages of both? > > Tags are binary. They are there or not. > > Property drawers allow you to assign values to variables. > > I've never fully understood why some property drawers are set to binary. > For controlling LaTeX export I have both a property ":clearpage: t" and a > tag ":ignore:", and the tag makes more sense to me. Some of those may only > exist in my personal config. > > -k. >
Re: very strange LaTeX error
On Friday, 20 Dec 2019 at 17:28, Stefan Nobis wrote: > Hmmm... but it should be solvable. Maybe something along the lines of > this (rough sketch, I have next to no experience with the org code > base): It should be solvable and something like what you have written looks promising. But it's beyond my elisp-fu so I hope others can chime in! -- Eric S Fraga via Emacs 27.0.50, Org release_9.3-34-g2eee3c
Re: Properties Drawer versus tags
I'll try to explain my view of tags. Let's see if it makes sense. :) Conceptually, properties are like a generic key-value store for headings, and tags are like a certain property. Imagine if, instead of tags being placed in headings, like this: * Blueberries :food:fruit: ...tags were implemented as properties, like this: * Blueberries :PROPERTIES: :TAGS: food fruit :END: The meaning would be essentially the same. >From a technical perspective, putting tags on headings makes them much faster to search for, because a regexp can be used to search directly to them (local ones, anyway). In contrast, to find the next location of a certain property, a single regexp search is not enough, because even if a regexp search was done to find an entry like the previous example, like: (re-search-forward (rx bol ":TAGS:" (1+ blank) (0+ nonl) bow "food" eow) nil t) ...it would not be guaranteed that the result would actually be in a heading's property drawer, so additional checks must be done to ensure that. Some properties are special, like CATEGORY. As well, some properties are "virtual," like SCHEDULED, which is written like: * Heading SCHEDULED: <2019-12-20 Fri 11:00> ...but is accessible with org-entry-get, like a property in a drawer. So, use tags for applying simple, conceptual labels to headings, because they're faster to search for than properties and always visible. Use properties as a key-value store for details that are less likely to be used in a query and are less important to see. What do you think? :)
Re: Org export to HTML with encrypted information ??
David Masterson writes: > My use-case is this: > > I'd like to use Org to write up *all* the information about my family > life (so to speak) including medical histories of my family, issues with > the house, bank accounts, financial information, etc., so that my family > has all the information to refer to when necessary in a (hopefully) > well-structured form. Naturally, this is going to have a fair amount of > really sensitive information. By carefully outlining the information, I > can structure the sensitive information to be in key parts of the > documents that I can then encrypt using org-crypt. > > That part is straightforward. The tricky part is that my family is not > "Emacs literate" and, so, I'm thinking the best idea is to export the > information from Org files to HTML files so that I can then present to > them as a website. They are used to browsing the web, so this should be > more natural to them. The problem that I'm looking for help with is how > to deal with the encrypted information? Any suggestions? I have same needs for my all-in-Org knowledge database. I will keep some personal information in some public Org files but encrypt Org headlines with org-crypt too. My idea is still use org-export-to-html. And use JavaScript to decrypt the encrypted contents. That will have more control on your hand. More choices. -- [ stardiviner ] I try to make every word tell the meaning what I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
