Re: Eev-wconfig.el etc etc, or: "Exercise: Learn Org!"
On Mon, 30 May 2022 at 00:20, Ihor Radchenko wrote: > It would be interesting to hear about the outcome and the student > feedback. > > Best, > Ihor The workshop was by chat (Telegram), and only one student came. He installed Emacs, Mpv, downloaded a copy with subtitles of the eev-wconfig video, and then followed the first sections of these two tutorials, http://angg.twu.net/eev-intros/find-eev-quick-intro.html http://angg.twu.net/eev-intros/find-elisp-intro.html and this video until 48:30, http://angg.twu.net/.emacs.videos.html#2022eevwconfig doing practically all the exercises. He told me that two of the five tests of `find-wget' didn't work as a described in the video... I need to debug that - my guess is that I need to add a line to the configs to make the output of wget.exe be interpreted as UTF-8 by default - and at one point he called an external program from Emacs and Emacs crashed. He started Emacs again and recovered some backup files, but then he had to leave. He asked me if we could continue on Wednesday. We haven't yet reached the part in which he learns how to index local videos, but we will probably do that on Wednesday. I think that that was quite good for three hours. =) Cheers, E.
Re: [patch] ox-html.el: add html attribute (verse numbers) to verse blocks
Juan Manuel Macías writes: > I believe that an html attribute to display marginal verse numbers in > sequence could be useful for certain content, as philological texts > (like here: > https://en.wikisource.org/wiki/The_Iliad_and_Odyssey_of_Homer_(Cowper)/Volume_2/The_Odyssey/Book_I) > > The `lines' property must be a digit that is equivalent to the verse > numbers sequence: > > #+ATTR_HTML: :lines 5 > #+begin_verse > some verses... > #+end_verse Sounds reasonable. However, a more consistent way to handle line numbers would be using switches, like what we do in EXAMPLE blocks. See org-element-example-block-parser and 12.6 Literal Examples section of the manual. Similarly, line numbering support can be implemented across more export backends. Best, Ihor
Re: Proposal: 'executable' org-capture-templaes
Arthur Miller writes: >> By "generic" I did not mean general-purpose all-functional framework. >> We just need something to remove code duplication in >> org-export-dispatch, org-agenda, org-capture, org-set-tags-command, etc >> They all share pretty similar code to generate dialogues. >> >> As for familiarity, I understand and it is exactly the reason why I >> suggested to factor out the menu code from capture templates. > > I am not really familiar with those other dialogues but org-capture, so I only > had that one in the mind. Yes, I agree if the similar code is used/shared in > several places than it does make sense to refactor it out. This refactoring could be a practical way to get something similar to your proposal into Org core. At least, if the menus are factored out appropriately. The above statement is a hint that patches are welcome :) >> The last one was >> https://orgmode.org/list/8c364693bf6856e60cdd3e8b63ab0c9284d16733.ca...@heagren.com >> And we had multiple complaints that Org menus are not searchable and do >> not allow recursive edit. > > I am not sure what complain about searchability is/was, so I should not say > much > there, but those are just a list of lists, saved in a well-known place, > org-caputre-templates var, so one can always traverse that list, or search the > menu buffer itself. Anyway thanks for the link, I have read through > that discussion. Seems to me like most of you are in favour of refactoring org > to use transient everywhere? The complaint was mostly from users who wanted to interrupt, say, the capture process, switch to the menu buffer, and search text there using isearch. Similar to what you can do with vanilla *Completions* buffer. Transient has met similar complaints when it was in the process of merging into Emacs core and now transient does support this "searching" possibility. That's why using transient could be an easy way for Org to address such complaints without a need to increase the maintenance burden. However, despite general agreement that Org should switch to transient menus, we will still keep backwards compatibility with the existing menus. So, one way or another, the existing menus will be retained. Ideally, also factored out and possibly merged into Emacs core (as requested by RMS https://orgmode.org/list/e1kiph1-0001lu...@fencepost.gnu.org). Best, Ihor
Re: [BUG] Info JS does not work [9.5.3 (release_9.5.3-467-g2bd34e @ /Users/salutis/src/org-mode/lisp/)]
Bastien writes: >> Apparently nobody touched this for a very long time. The last change >> in this area was 9 years ago. > > Indeed, it would be good to have someone as a maintainer. I suspect > the code is stable is still useful to some users. Should we create a help request for updates.orgmode.org? >> I do not fully understand why it is hosted in worg. We mention it in the >> manual and support in the core. The script is licensed under GPL. >> Is there any reason to keep it out of the main Org repo? > > I'd like the main Org repository to focus on Org's core, i.e. what is > sync'ed with GNU Emacs core. This reminds me that Org does not actually consist of a single repo. At this point, we at least have org, org-contrib, worg, and orgweb. Should we create a dedicated project page in sr.ht to group everything together nicely? > I think this nice js hack should live in a dedicated repository, along > with a dedicated HTML exporter that enables it. What about backwards compatibility? > Also, we don't want everyone to use https://orgmode.org/org-info.js as > the source for the script, as this would put the server under too much > load pressure, people should rather host the script themselves. Should we change the default value of org-html-infojs-options then? Alongside with possibly changing the relevant ox-publish code. Best, Ihor
Re: Eev-wconfig.el etc etc, or: "Exercise: Learn Org!"
Eduardo Ochs writes: > I think that you are underestimating how alien eev is for most people. > Let me suppose that what you mean by your comments is this: > > "I've spent N minutes watching this video - for N big - and I feel >that I've learned very little! What is the best way to learn a lot >of eev in M minutes, for M very small?" > > then the answer is: follow the main tutorial, that is here: > >http://angg.twu.net/eev-intros/find-eev-quick-intro.html To clarify, I did not expect to learn evv from the video you provided. However, I did expect to learn things proportionally to the video length. That way, the video efficiency is pretty low. The video itself can certainly be improved - the problem is not with eev itself, but rather with the way you present things. Note that eev is not actually very alien. Knowing the concept of Org links, eev is pretty trivial. At least the basics concepts are not hard to grasp. > Anyway, tomorrow I will meet with a group of three or four students > that are interested in learning Emacs and eev. They use Windows and > they have never used Emacs before, so we probably won't be able to do > much of this exercise: > > http://angg.twu.net/eev-wconfig.html#learn-org It would be interesting to hear about the outcome and the student feedback. Best, Ihor
Re: [PATCH] Re: tangle option to not write a file with same contents?
I applied the discussed two patches onto main via 1525a5a64 and f6f26d4ce. The suggested amendments were incorporated. > I do not like (unless (when ...)) composition. If I remember correctly, > `when' should be used for side effects, so `and' may be more suitable > here. Otherwise it looks like what Greg suggested and should work faster > than first variant of this patch. I did not see any documentation saying that when is for side effects. However, or would do equivalent job there and also easier to read. So, I changed when to or as suggested. > I still had a hope that `org-babel-load-file' might be improved a bit by > using `byte-recompile-file' with 0 passed for ARG (previously I > incorrectly wrote FORCE). The goal is to avoid recompiling the tangled > .el file if it is not changed. Can you please open a new thread on this? People who did not keep track of this thread might not notice this suggestion. > I am still curious if it is reliable to compare file size from > `file-attributes' with (+ 1 (bufferpos-to-filepos (buffer-size))) for > tangle result prior to loading existing file. I am unsure due to > variations in encodings and newline formats, however it might further > improve performance then tangle result changes. In my testing, I did not notice any significant difference. Given than bufferpos-to-filepos can be tricky and sometimes return nil (see the docstring on QUALITY arg), I do not think that it is worth bothering. > I have noticed that `org-babel-tangle-file' may create empty org file if > it does not exist. From my point of view it is questionable behavior. Fixed. Now, set-file-times call is guarded by file-exists-p check. > Finally some comments on performance numbers. Ihor, your test simulates > iterative debugging. Tangle results were likely in disk caches. Another > case may give different numbers. Consider single pass after small > modification of the source .org file. For comparison existing files are > mostly should be loaded from disk. I did not mean disabling disk caches > completely. After tangling it may take some time till files are actually > written to disk. I am unsure if during repetitive benchmarking some > files may be replaced in caches without writing to disk at all, likely > timeout for dirty cache pages is small enough. My benchmark was for the best-case scenario for the proposed patch. Everything is tangled to files prior to running the benchmark. This way, none of the tangled files should change when calling org-babel-tangle and no disk caches should be involved. The benchmark without the patch, would write to disks. If your concern is correct and no actual disk writing happens due to disk caching, the benchmark time provided in the commit message should be a lower bound of the actual time. Then, we don't care. The existing benchmark already illustrates that the patch can reduce tangle time significantly. Best, Ihor
Re: Proposal: 'executable' org-capture-templaes
Ihor Radchenko writes:
> Arthur Miller writes:
>
>> Simplicity comes from the org-templates. Me, and I guess other people are
>> familiar with org-catpure templates already, and I mean, can it be simpler to
>> create a menu of choices then a simple list:
>>
>> '(("key1" "label1" exec (lambda () ...))
>> ("key2" "label2" exec (labmda () ...))
>>...
>>)
>>
>> People are already writing those as part of org-capture, so there is a
>> familiarity factor. Transient has to be learned, and the complexity is much
>> bigger.
>
>>> If anything, capture
>>> menu might be factored out to a generic menu framework.
>>
>> Please no. Not every single piece of Emacs has to be a generalized
>> framework. Generalized frameworks add an extra layer of complexity, and it
>> this
>> case, as you point out, we have other frameworks, so yet another framework is
>> *definitely* not what I ask for.
>
> By "generic" I did not mean general-purpose all-functional framework.
> We just need something to remove code duplication in
> org-export-dispatch, org-agenda, org-capture, org-set-tags-command, etc
> They all share pretty similar code to generate dialogues.
>
> As for familiarity, I understand and it is exactly the reason why I
> suggested to factor out the menu code from capture templates.
I am not really familiar with those other dialogues but org-capture, so I only
had that one in the mind. Yes, I agree if the similar code is used/shared in
several places than it does make sense to refactor it out.
> I am strongly not in favor of adding exec to org-capture itself. It's
> a bit like if you were to add :activate-func for a link that actually
> downloads some file from internet, then generates and exports agenda,
> and meanwhile also restarts your remote server. This will also kind of
> save the code, but completely out of purpose of :activate-func. Of
> course, I am exaggerating here, but just want to make my point clear.
I understand, it is ok :).
>>> We actually had multiple threads discussing possibility to port all the
>>> Org dialogues to transient.
>>
>> I have unfortunately missed those discussions. But as said, I am not in to
>> argue
>> for or against transient at all. I would just like to re-use the org-capture
>> code, since it is already in-place.
>
> The last one was
> https://orgmode.org/list/8c364693bf6856e60cdd3e8b63ab0c9284d16733.ca...@heagren.com
> And we had multiple complaints that Org menus are not searchable and do
> not allow recursive edit.
I am not sure what complain about searchability is/was, so I should not say much
there, but those are just a list of lists, saved in a well-known place,
org-caputre-templates var, so one can always traverse that list, or search the
menu buffer itself. Anyway thanks for the link, I have read through
that discussion. Seems to me like most of you are in favour of refactoring org
to use transient everywhere?
>>> It seems to be quite out of scope of org-capture.
>>
>> Maybe, but than what is in scope of org-mode or org-capture or Emacs? We are
>> constantly bending code to do what it is not really meant to do. Since to be
>> a
>> DNA of Emacs :).
>
> Sure. But another feature of Emacs is being consistent. Emacs does
> provide flexible interfaces, but they stick to they purpose. Abusing
> them is up to the user (with no guarantees to work in future versions),
> but not up to Emacs itself.
>
> If we were to include your suggestion, we would also need to maintain
> the new generalized functionality in future. Even if we need to change
> some internals of org-capture. Over-generalization will put an extra
> burden on future maintenance.
Np, I understand. Thanks for the answer anyway.
Best regards
/a
Re: [tip] org-publish to work with (very) large books
Ihor Radchenko writes:
> Yet, the information is surprisingly scattered. I was unable to find a
> single guide on the available possibilities. Mostly unanswered or
> partially answered questions from users.
Yes you're right. In addition, what I have been testing is not a panacea
either. In general, when it comes to long and complex documents, there
is no other solution than to arm yourself with patience, launch
asynchronous processes and dedicate yourself to doing another task while
LaTeX does its job. And, of course, trust that there are no errors. The
only advantage to debugging the code of a LaTeX document is how much you
learn about LaTeX and TeX in the process. But many times it is something
that can become frustrating, and the log file can be more cryptic than a
Sumerian inscription. The cause/effect relationship in LaTeX errors can
be the most surrealistic things in the world :-D.
Luckily, there's texstackexchange, where the LaTeX core and LaTeX
package developers themselves write, which is an endless source of
help...
> Do you have anything from LuaTeX in mind that could improve the current
> ox-latex pdf export when LuaTeX is used as the TeX engine?
I've thought about it sometimes, but haven't been able to find anything
concrete for Org. LuaLaTeX cares that a well-formed LaTeX document is
delivered to it, and Org already does that very well. In LuaTeX you can
insert lua code between La(TeX) code. For example:
\begin{luacode}
local x = "foo"
local y = "bar"
tex.print (x .. " and " .. y)
\end{luacode}
But in Org we have all the power of Babel: Org wins.
In LuaTeX you can write functions as pre-process filters, and associate
these functions with different callbacks. For example, there is a
callback_input_buffer, but we already have something like that in Org,
and with a larger scope and not limited to output to LaTeX.
In general, the advanced features of LuaTeX are more typographical and
micro-typographical in nature, and I guess they are of little use to
Org. For example, I recently wrote this function that highlights in red
the text that is in a language other than the main language of the
document (in my case, Spanish, langid 80). Act low-level on the line
node, just before LuaTeX does the line break to create the paragraph:
\directlua{
w = node.new("whatsit","pdf_literal")
w.data = "1 0 0 rg"
z = node.new("whatsit","pdf_literal")
z.data = "0 g"
function other_langs(h,c)
for n in node.traverse_id(0,h) do
for x in node.traverse_id(node.id("glyph"),n.head) do
if x.lang < 80 or x.lang > 80 then
local before, after = node.copy(w), node.copy(z)
n.head = node.insert_before(n.head,x,before)
n = node.insert_after(n,x,after)
end
end
end
return h
end
luatexbase.add_to_callback('post_linebreak_filter', other_langs, 'other_langs')
}
According to the LuaTeX manual, "TeX’s nodes are represented in Lua as
userdata objects with a variable set of fields". What this function does
is simply manipulate the .lang field of the glyph nodes in an hlist node
(the line with its components).
Functions associated with the post_linebreak_filter callback are very
useful and productive, but from a purely typographical point of view.
At the pure LaTeX level, LuaLaTeX is not very different from LaTeX. Any
LaTeX document, generally speaking, can be compiled with LuaLaTeX, as
long as it is in utf8 and does not contain some pdfLaTeX- or
XelaTeX-specific commands. Today the compatibility between engines is
reasonably good, and more and more packages designed exclusively for
LuaTeX are uploaded to CTAN. The TeX ecosystem is notorious for its
slowness and conformism, but LuaTeX is meant to be the natural
replacement for pdfTeX. Sometime in the uncertain future :-)
Best regards,
Juan Manuel
Re: Tips on using Org-mode to manage a reading list
Hi, personally, I find tracking information through TODO keywords rather unappealing. There are two reasons: the first one is that you may loose information. For instance, if you use "TO-READ", "To- BUY", "READ" to track your books, does that mean that every item that is marked "READ" is related to a book in your possession? What about books you read that you borrowed from the library or a good friend? Once you change to the final keyword, you loose track of the former ones. I do believe that is is better to use properties and/or tags for this. Secondly, since I store everything in my journal, I would end up (and at some point, I did) with TOREAD / READ; UNVISITED / VISITED (locations); UNTESTED / TESTED (e.g., food recipes, code, ...) and so on. I found that rather unappealing as it is based on the content of the item. Today, my keyword is simply "TODO" and I tag the headline "ARTICLE" or "BOOK". If I want to query books that I still need to read, I will filter on tags and TODO item. (This also allows me to search for articles I still need to read but exclude books.) Since you are also talking about articles: the CLI tool org_attach can fetch data and pdfs (when accessible) based on DOIs, bibtex files, URLs, ...: https://github.com/Ezibenroc/org_attach org_attach bib 10.1137/0206024 would look up the DOI and create an entry in the org-mode file automatically, including a bibtex section; in some cases (when it can find it), it even downloads the PDF and attaches it. Further tips: there are tools like org-noter and org-pdftools (combined through org-noter-pdftools) that can help you with taking notes. When you set up an org-capture template, consider putting it into its own file and reading it via (file "path/to/your/template" ); makes your init.el a bit tidier. Third advice: you may want to add a property called "GENRE"; and in some cases, you may want to limit the entries via the _ALL option. So for example, you list all genres through #+PROPERTY: GENRE_ALL genre1 genre2 genre3 Other values will then not be permitted for that property. Best regards Christian On Mon, 2022-05-16 at 23:22 +0200, Sébastien Gendre wrote: > Hello. > > I want to use Org-mode to manage a reading list and I'm looking for > tips. > > My goals are to: > * List books and articles I want to read > * Track books I have to buy and which I already own > * Track books and articles I have read > * Take notes on books I have read > > The following is what I plan to do. > > The idea is to use an Org-mode heading for each book and the > properties of the books become the ones of the Org-mode heading. The > synopsis of the book can be in the body of the heading. > > Example: > #+begin_example > > * TO-READ Four Futures - Life After Capitalism > :PROPERTIES: > :Title: Four Futures - Life After Capitalism > :Author: Peter Frase > :Score: > :Publisher: Verso Books > :Release_date: Unknown > :Link: https://www.versobooks.com/books/1847-four-futures > :Pages: > :END: > > An exhilarating exploration into the utopias and dystopias that > could develop from present society > > #+end_example > > I can then structure my Org-mode file like I want. Here, the first > level headings are: > * Articles > * Books > > In the "Books" heading I have the headings "Non-fiction" and > "Fiction". > > To track the status of the books, I set the following for the Org-mode > file: > * TO-GET > * TO-READ > * READING > * READ (DONE state) > > For adding new books, I can use Org-capture with a custom template. > The captured book can be saved inside an "Inbox" Org-mode file, then > moved to its destination heading with Org-refile. > > For searching a book inside the file, I can use "Sparse Trees" or > Org-ql. > > If I get the digital version of the book, I can attach it to its > corresponding heading with Org-attach. > > And for taking notes, I can create headings inside the book heading. > Using Emacs narrow to focus on it. If I get the digital version of the > book, I can use Org-noter. > > End of description. > > > Do you have any suggestions or idea ? > > I don't know how to manage books with several volumes. > Do I create a heading for each volumes ? > Do I create one heading for the whole collection ? > > The first is easy with 2 or 3 volumes, but not when I got 23 or more in a > collection. > > Do you have idea to manage borrowing and loaning books ? > > Thank you in advance. :) > > > Best regards > signature.asc Description: This is a digitally signed message part
Re: Bug: org-adapt-indentation is not compatible with paragraph-indent-minor-mode [9.4.5 (9.4.5-16-g94be20-elpaplus @ /home/lockywolf/.emacs.d/elpa/org-plus-contrib-20210412/)]
Vladimir Nikishkin writes: > This report is not about exporting Org code. It is perfectly fine that > an empty line is required in org to demarcate a paragraph. The example > above is just what I would imagine as an "ideal case". > However, when `paragraph-indent-minor-mode` is turned on, > `org-adapt-indentation` stops working, even though nothing else has > changed. The text is exactly the same, and is valid org markup. This is because paragraph-indent-minor-mode trashes major-mode settings for indent-line-function. Org mode relies on indent-line-function to be org-indent-line, which makes all the handling of `org-adapt-indentation' among other things. paragraph-indent-minor-mode sets indent-line-function to indent-to-left-margin instead of org-indent-line. I doubt that paragraph-indent-minor-mode can be changed in general way to handle cases like this. Instead, it may be possible to implement org-mode equivalent of paragraph-indent-minor-mode. Patches are welcome! Meanwhile, paragraph-indent-minor-mode should be considered incompatible. Best, Ihor
Re: How to report typos in the documentation?
Ypo writes: > If we find a typo, how should it be reported? Yes! Thanks for this. Fixed on main via a407a89c5. > For example, in org footnote section: > > …This can be nil, to place footnotes locally at the end of the > current outline node. **If** can also be the name of a special > outline heading under which footnotes should be put. In future, plase also provide the file and function/variable name you are referring to. Best, Ihor
Re: [PATCH] Re: Change in `org-cycle-hook' breaks behavior
Tor Kringeland writes: > Maybe a function like that could be added to Org, that the user could > add to `org-cycle-hooks' to produce the "opposite" of > `org-cycle-hide-drawers'/does what `org-cycle' used to do without > `org-cycle-hide-drawers' in the hook in Org 9.5? I will take a note on this for future reference. I do not plan to implement it yet, unless other people jump in and ask for this feature. Generally, org-fold.el can be restructured a bit better given that we have the working cache now and can generalize many old functions from org-fold. Best, Ihor
Re: [tip] org-publish to work with (very) large books
Juan Manuel Macías writes: > Improving performance and compile time in TeX is an old topic, and there > are a few tricks here and there. But TeX is what Emacs is, both are > venerably old; and both are single-thread. Yet, the information is surprisingly scattered. I was unable to find a single guide on the available possibilities. Mostly unanswered or partially answered questions from users. > There are more ''modern'' > approaches, like Patoline or Sile (of course, based heavily on TeX, > which is the father of everything). Sile, especially, is very > interesting and from time to time I like to play with it. The problem > with these new projects is that they don't have the LaTeX package > ecosystem, and they are poorly documented. Well, Sile in particular is > the work of a single person. Links: > > https://patoline.github.io/#documentation > > https://sile-typesetter.org/ Thanks! This is interesting. > As for LuaTeX, which is the state of the art today in the TeX ecosystem, > it is nothing more than TeX + a lua interpreter + the implementation of > advanced features from previous engines like pdfTeX and the experimental > Omega/Alef. It has the advantage that it is a scriptable TeX (TeX > primitives can be controlled by Lua scripts, and truly amazing things[1] > can be achieved with very little effort[2]); it has the disadvantage that > the scripting language is Lua. The ideal would have been a Lisp-TeX ;-) > > [1] The chickenize package contains many examples, some of them somewhat > absurd and not very useful in > appearance: https://www.ctan.org/pkg/chickenize > > [2] https://tug.org/TUGboat/tb31-3/tb99isambert.pdf For me, the main problem with LuaTeX is that it is generally not supported by publishers I deal with. Mostly, LaTeX is the requirement. Some even demand Word documents ): Hence, all the advanced features of LuaTeX cannot be used in real my real publications and I cannot convince myself to dedicate time for playing around with LuaTeX. Do you have anything from LuaTeX in mind that could improve the current ox-latex pdf export when LuaTeX is used as the TeX engine? >>> The moment one breaks down a large piece of work into specialized parts, >>> one gains more control over that piece of work. And org-publish helps >>> manage all of that. It is about managing a large book as a website (via >>> org-publish). In short, the combination of org-publish, projectile and >>> latexmk is quite productive for me in this type of work. >> >> This is a bit confusing. You still keep the book in a single giant Org >> file. It indeed does not mean anything given that we can always narrow >> to subtree, but I fail to see where you break the book into specialized >> parts then (LaTeX performance trickery aside). > > I think this is inaccurate. The book is split across multiple > subdocuments. The master file is just the 'outline' of the book. I see. After watching the video more carefully, I do see the your org file only had the bibliographies. Not the actual book text. Best, Ihor
How to report typos in the documentation?
If we find a typo, how should it be reported? For example, in org footnote section: …This can be nil, to place footnotes locally at the end of the current outline node. **If** can also be the name of a special outline heading under which footnotes should be put.
Re: # Comments export
Ypo writes: > Thanks for your effort, Ihor > > But that code is so difficult for me, that I can barely understand it. Well. The basic idea is to go through the document right before exporting and replace all the comments with some kind of exportable environment. Below is the working code that you can try directly. The code replaces comments with quote blocks. You might want to tweak "#+begin_quote\n%s\n#+end_quote\n" to something else if you want to customize how the comments are exported. Just put %s where you want to put the comment text and do not forget to leavee the trailing newline "\n". Hope it helps. (defun org-export-replace-comments (_) "Replace all the comments with QUOTE blocks." (org-with-wide-buffer ;; Search the all the comments in temporary export buffer. (goto-char (point-min)) (while (re-search-forward org-comment-regexp nil t) (let ((comment (org-element-at-point))) ;; We just called Org parser to determine the syntactic element at point. (when (eq 'comment (org-element-type comment)) ;; The current element is really comment. Replace its contents with ;; QUOTE block. `setf' here is replacing buffer region defined by ;; `buffer-substring' with new string containing the QUOTE block. (setf (buffer-substring (org-element-property :begin comment) (org-element-property :end comment)) (format "#+begin_quote\n%s\n#+end_quote\n" (org-element-property :value comment (add-hook 'org-export-before-parsing-hook #'org-export-replace-comments) Best, Ihor
Re: how to export an org file, to 2 different locations (in to different formats)
Uwe Brauer writes: > In any case thanks for both solution, that was very generous and helpful. > > Developers: why to include some of this code in a addon file, if Juan agrees > of course! A more canonical solution would be writing org-export-filter-options-functions that set :output-file export option directly. Best, Ihor
Re: # Comments export
Thanks for your effort, Ihor But that code is so difficult for me, that I can barely understand it. El 29/05/2022 a las 3:19, Ihor Radchenko escribió: Ypo writes: I wanted to export my # comments so I could share my notes with more people, using HTML export. I would export all of them. But, as it seems not possible, I think I will use footnotes. I liked # comments more, because their face can be customized and because they are nearer to the commented text (although footnotes can be moved manually wherever user wants to), # comments are like more "natural". It is actually possible, but you will need to write an org-export-before-parsing-hook that will convert all the comments into exportable elements. Not tested, but the hook might be something like (defun org-export-replace-comments (_) "Replace all the comments with note blocks." (org-element-cache-map (lambda (comment) (setf (buffer-substring (org-element-property :begin comment) (org-element-property :end comment)) (format "#+begin_note\n%s\n#+end_node\n" (org-element-property :value comment :granularity 'element :restrict-elements '(comment))) Best, Ihor
Re: Org mode together with bug-reference-mode
Paul Kaletta writes: > I want to use Emacs bug-reference-mode together in my Org mode > setup. Here's an example file: > > > # Local Variables: > # eval: (bug-reference-mode) > # bug-reference-bug-regexp: > "\\(\\(?:\\(?:SUPPORT\\|support\\)-\\)\\([0-9]+\\)\\)" > # bug-reference-url-format: https://www.example.com/SUPPORT-%s You forgot "" around bug-reference-url-format. It should be a string. Try # bug-reference-url-format: "https://www.example.com/SUPPORT-%s; Best, Ihor
Re: [BUG] Info JS does not work [9.5.3 (release_9.5.3-467-g2bd34e @ /Users/salutis/src/org-mode/lisp/)]
Hi, the https://orgmode.org/org-info.js file is available again, thanks for reporting this. Ihor Radchenko writes: > Apparently nobody touched this for a very long time. The last change > in this area was 9 years ago. Indeed, it would be good to have someone as a maintainer. I suspect the code is stable is still useful to some users. > I do not fully understand why it is hosted in worg. We mention it in the > manual and support in the core. The script is licensed under GPL. > Is there any reason to keep it out of the main Org repo? I'd like the main Org repository to focus on Org's core, i.e. what is sync'ed with GNU Emacs core. I think this nice js hack should live in a dedicated repository, along with a dedicated HTML exporter that enables it. >> P.S. If someone decides to fix this, please consider adding a test. Without >> it, sooner or later, someone will waste their time again. > > It is a good idea, though I am not sure if it is appropriate to add > network staff into Org tests directly. I'm sure it's not a good idea to add network-dependent tests :) Also, we don't want everyone to use https://orgmode.org/org-info.js as the source for the script, as this would put the server under too much load pressure, people should rather host the script themselves. -- Bastien
Re: [PATCH] ox-latex: Scale inlinetasks according to column width
Ihor Radchenko writes: > I recently had a need to export org into multi-column latex and noticed > that inlinetasks are exported into boxes that are wider than column > width. That looks ugly. > > The attached patch fixes this. Applied onto main via d37e4dc0f. Best, Ihor
Re: [BUG] Setting compile command causes fontification error [9.5 (release_9.5-661-g5e0afb @ /home/quintus/.emacs.d/org-mode/lisp/)]
Ihor Radchenko writes: > "Christopher M. Miles" writes: > >> From the backtrace, seems (buffer-file-name) returned nil, I guess you >> first created a new buffer and have not saved it to file. That caused it >> return nil. Not Org Mode problem. Not saving file is a common problem in >> young programmer as I experienced. No offence. > > To clarify, the problem is in the user-defined hook: > > (add-hook 'latex-mode-hook (lambda() >(set (make-local-variable 'compile-command) > (concat "lualatex " (shell-quote-argument > (buffer-file-name)) > > The hook does not work when (buffer-file-name) returns nil, which is > exactly what happens when Org mode tries to fontify the source block. > Org does it inside a temporary buffer not associated with any real file. > That's why you are senior developer, I haven't fount the hook in his error report. Good job. > One way to fix the problem would be > > (add-hook 'latex-mode-hook (lambda() > (when (buffer-file-name) >(set (make-local-variable 'compile-command) > (concat "lualatex " (shell-quote-argument > (buffer-file-name))) > > Best, > Ihor -- [ stardiviner ] I try to make every word tell the meaning that I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3 signature.asc Description: PGP signature
Re: [PATCH v2] Re: Bug in 9.5.3 org--file-default-apps
On 26/05/2022 11:23, Ihor Radchenko wrote: diff --git a/lisp/org.el b/lisp/org.el index d7da8efc4..45a179a8a 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -7975,7 +7975,12 @@ (defun org-open-file (path in-emacs line search) (when (eq cmd 'mailcap) (require 'mailcap) (mailcap-parse-mailcaps) - (let* ((mime-type (mailcap-extension-to-mime (or ext ""))) + (let* ((mime-type (if (executable-find "file") +(shell-command-to-string + (format "%s --brief --mime-type %s" Another corner case: file --brief --mime-type tstorg-sh-symlink inode/symlink file --brief --mime-type --dereference tstorg-sh-symlink text/x-shellscript + (executable-find "file") + (shell-quote-argument (convert-standard-filename file + (mailcap-extension-to-mime (or ext "" Actually MIME type for shell scripts varies a lot (mailcap-extension-to-mime "sh") => "text/x-sh" run-mailcap --norun examples/org/script/tstorg.sh Error: no "view" mailcap rules found for type "application/x-sh" And "text/x-shellscript" as above.
Re: [PATCH v2] Re: Bug in 9.5.3 org--file-default-apps
Ihor,
Your patch may be an improvement, but it requires an additional fix, see
below.
However, in my opinion, it does not address original Craig's issue. The
patch improves handling of *non-text* files requiring *external*
viewers, while Craig complained that behavior for shell script is
incorrect and his problem is tightly bound to erased `mailcap-mime-data'.
I can not reproduce behavior he observed exactly, Org does not opens
shell scripts by less, but it tries and silently (it is expected) fails.
My results (emacs-27):
1. If there is no mailcap files at all, the script is opened
in the same emacs session that is correct from my point of view.
2. If I add ~/.mailcap
text/plain; less '%s'; needsterminal
then I get silent failures
Running less /etc/profile...done
3. With your patch and the following additional entry in ~/.mailcap
(notice "text" instead of "application" and just "emacs")
text/x-shellscript; emacs %s; test=test -n "$DISPLAY"
new Emacs session is started. It is a problem but partially
it is caused by incorrect mailcap configuration.
Unlike "text/plain" that would be handled by view-mode
unless `mailcap-mime-data' were erased in Emacs-27,
"text/x-shellscript" is handled by less on my main system
due to mailcap while I would expect same Emacs session.
I read implementation of `org-open-file' once more and now I see that
currently remote files can not be processed by mailcap code path even
with custom `org-file-apps', so thank you for explanation. In some cases
it may be handy to launch remote viewer from a host accessed through
ssh, but let's leave it aside.
- (let* ((mime-type (mailcap-extension-to-mime (or ext "")))
+ (let* ((mime-type (if (executable-find "file")
I would consider (and ... (not remp)) despite currently it is redundant.
Just to mitigate consequences if other parts of this complicated
function will be modified. On the other hand
`start-process-shell-command' is not ready for remote files anyway, so
major cleanup would be required.
+(shell-command-to-string
+ (format "%s --brief --mime-type %s"
+ (executable-find "file")
+ (shell-quote-argument
(convert-standard-filename file
It is not enough to cure my paranoia. However the following case is
rather pathological
mkdir 'Program Files'
ln -s /usr/bin/file 'Program Files'/
PATH="$HOME/Program Files:$PATH" \
emacs -Q -L ~/src/org-mode/lisp/ ~/examples/org/open-script.org &
Debugger entered--Lisp error: (wrong-type-argument stringp nil)
string-match("/" nil 0)
split-string(nil "/")
mailcap-mime-info("/bin/bash: line 1: /home/ubuntu/Program: No such
f...")
(let* ((mime-type (if (executable-find "file")
(shell-command-to-string (format "%s --brief --mime-type %s"
(executable-find "file") (shell-quote-argument
(convert-standard-filename file (mailcap-extension-to-mime (or ext
"" (command (mailcap-mime-info mime-type))) (if (stringp command)
(setq cmd command) (setq cmd 'emacs)))
+ (mailcap-extension-to-mime (or ext ""
Agree. Though it is not directly related. Maybe you can bump that thread
and mark is as a bug report to be listed on
https://updates.orgmode.org/?
It is already tracked there as
"org-open-file & org-file-apps multiple substitution bug"
but my point was that great care is required otherwise a lot of issues
may happen with shell command.
Ihor Radchenko. Bug in 9.5.3 org--file-default-apps.
Wed, 25 May 2022 14:18:10 +0800.
https://list.orgmode.org/8735gy2l0d.fsf@localhost
'>$ run-mailcap myscript'
One comment. I do not personally have run-mailcap command on my system,
but searching for its docstring reveals
(http://www.linux-commands-examples.com/run-mailcap):
If the mime-type is omitted, an attempt to determine the type is
made by trying to match the file’s extension with those in the
mime.types files.
So, run-mailcap itself does not look inside the file and only checks the
extension. AFAIU. Correct me if I am wrong.
It is a Debian extension. Local man page has the following statement
(confirmed by code and strace):
If no mime-type is found, a last attempt will be done by running the
file command, if available.
