Re: [PATCH] Enhance org-html--build-meta-info
Jens Lechtenboerger writes: > I like this! :) >> 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 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. 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). Worst case, the argument just sits there and is ignored :P > Some comments raise complaints by checkdoc (lines too long, no > sentence in fist line). (Actually, the file has more problems in > that regard.) Ooops, I thought I took care of that. Looks like I'll be taking another look... Would be nice my issues weren't one of dozens throughout the file, it makes it a bit harder to notice errors coming from /my/ section. > Many thanks for your continued work! Thanks for your testing and feedback! -- Timothy
Re: Release Org 9.4.2
Hello. I just have a few cents I'd like to add. Bastien writes: > Thanks a lot for the kind words, appreciated. You deserve them! :) > ... but I'm very receptive to the real questions: how can we expose > the latest Org to more testers? how can we recruit more contributors? 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 I do however think we can do better in serving younger (potential) contributors, without degrading the time-tested ML experience. I'm doing a little investigation on this front, and hopefully will have something to start a thread about in a few weeks :) All the best, Timothy.
Re: Release Org 9.4.2
Bastien writes: > Be reassured, the fact that I shall soon step down has nothing to do > with the community: in fact, the community is what kept me motivated > for nearly ten years now! > > This decision is a simple combination of me not having enough time > (which can lead to frustrating situations for other contributors) and > the fact that I'm confident about Org's future. Yes. I am sure too. >> Yes. This is endless. We’ll continue this... > > ... but I'm very receptive to the real questions: how can we expose > the latest Org to more testers? how can we recruit more contributors? Org is a big beast now. I am also of the opinion that its parts must be maintained separately. Last few months when you are assigning things from ob-*, I was observing it and thinking - may be that is the way forward. > If at some point developing Org within Emacs seems to be part of a > good solution, I'll be all for it. I definitely prefer this scenario > to the one where Org is kicked out Emacs core and moved to a separate, > not-installed-by-default, GNU ELPA package. Not sure, how feasible is that (move to a separate non-installed-by-default). I am not thinking on these lines. I am hoping only for the best.
Re: [PATCH] Enhance org-html--build-meta-info
Hello everyone, On 2020-12-15, TEC wrote: > Jens Lechtenboerger writes: > >> [title export being dodgy, how about treating like author?] > > Yep, ~org-element-interpret-data~ is necessary. I found that wrapping it > in ~org-html-plain-text~ seems better again though, as it encodes > entities like "---" (org) to "", and doesn't seem to introduce > any nested tags. I've also applied this to the author field as a result. I like this! > 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 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? Some comments raise complaints by checkdoc (lines too long, no sentence in fist line). (Actually, the file has more problems in that regard.) Many thanks for your continued work! Best wishes Jens smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH] Enhance org-html--build-meta-info
Hi Timothy, I understand now. Having a way to implement this in the config is a good thing as it covers a slightly different set of use cases and workflows than always using a common #+setupfile: line. That way if you are working with files that don't have a #+setupfile: specified you can still add metadata without having to modify the files. This would vastly simplify some of my documentation generation code where I modify the first section of a bunch of org files as I process them rather than modifying the config. Thanks! Tom
Re: Release Org 9.4.2
Pankaj Jangid writes: >> But (1) it is not only *our* decision, it's also in the hands of the >> Emacs maintainers, which may think otherwise; (2) all the consequences >> need to be considered, as it is a sensible move; (3) I am on the verge >> of stepping down as a maintainer, so it is not a good time for me to >> push into a direction or another. > > I sensed (3) when I saw an email (last month I guess) about assimilating > parts of Org into Emacs. While that is a good idea. But I don’t have a > very good feeling about you leaving. You have contributed so much. You > have maintained it so well. > > I can understand how it feels when people complain about features. And > sometimes they blame the maintainers for some specific product > directions. But it is bound to happen when they are also attached to the > product. I hope these things have not shaped up your decision. It > happens in a closely knit family. Thanks a lot for the kind words, appreciated. Be reassured, the fact that I shall soon step down has nothing to do with the community: in fact, the community is what kept me motivated for nearly ten years now! This decision is a simple combination of me not having enough time (which can lead to frustrating situations for other contributors) and the fact that I'm confident about Org's future. >> Anyway, I don't think now is the right time to consider this move, as >> there are many more things to achieve. I suggest we discuss this again >> later next year. > > Yes. This is endless. We’ll continue this... ... but I'm very receptive to the real questions: how can we expose the latest Org to more testers? how can we recruit more contributors? If at some point developing Org within Emacs seems to be part of a good solution, I'll be all for it. I definitely prefer this scenario to the one where Org is kicked out Emacs core and moved to a separate, not-installed-by-default, GNU ELPA package. Best, -- Bastien
Re: Bug: Orgmode export takes "AC:" as a link keyword [9.5 (nil @ /Users/junwei/.emacs.d/.local/straight/build-27.1/org-mode/)]
Junwei Wang writes: > How can I let orgmode disable some built-in links if it allows? (The > escape character solution sounds not ideal.) Sorry, I don't have any other solutions aside from pruning the entries you don't want from org-link-parameters (see org-link-set-parameters for function calls that should follow a change in its value) or preventing them from being added in the first place. Perhaps someone else knows of another solution and will chime in.
Re: org-mac-link patch
Jan Lübke writes: > Your edits look good to me and you can use this email address. BTW: I > just upgraded to macOS 11.1 (released yesterday) and my patch is still > needed. Looks like Apple won’t fix the issue. Thanks, pushed (a4d0607e1).
Re: [PATCH] Margin added for overflow visibility problem
Fatih Aydin writes: > Thanks for the suggestion, it's okay for me. I just wanted to make sure > that the issue is clear for everyone by describing the steps. > I also agree with waiting for CSS gurus. Applied (5ee39c352). Thanks again.
Re: LSP is Microsoft's patented protocol - Re: Emacs as an Org LSP server
[[[ To any NSA and FBI agents reading my email: please consider]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > Daniel Ravicher found 283 software patents that, if upheld as valid by the courts, could potentially be used to support patent claims upon the Linux Kernel. I wonder how many more for Free Software in general! I used to estimate around 100,000 patents for a 2000-era GNU/Linux distro, based solely on the size of code base. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
Re: Release Org 9.4.2
Daniele Nicolodi writes: >> My question is/are: (1) Why Org is developed outside Emacs, given that >> it is a core/built-in package. (2) Are there other packages that follow >> the same process? > > AFAIK also cc-mode is developed in a dedicate repository. > > From an Emacs development point of view there is the desire to move more > packages that are now included in the core to ELPA and assemble Emacs > releases from these. This will allow packages to have independent > releases and users to update them more frequently than the pace of Emacs > releases. In this process, moving more packages to separate git > repositories would be natural. Thus, the idea would be remove the need > for syncing the org and cc-mode codebases to the Emacs repository rather > than moving the development of these packages to the Emacs git. Yes. This seems to be a good direction. The news about new elpa.git is really good. Probably that will settle all these things.
Re: [PATCH] Enhance org-html--build-meta-info
Hi Tom,
> Why not just use #+html_head:
> possibly with a macro to fill in variable values? That is fully
> extensible and doesn't overload keywords. For title, date, author,
> etc. those can have clearly defined mappings to the html, but
> everything else seems to be handled more sanely with #+html_head:. Am
> I missing something?
I doubt the use case that prompted me to make this an option is the
only one that would benefit, but it should give you an example of the
potential utility of this.
There's some metadata I /always/ want added to my exported documents.
Some of it is static (e.g. ("name" "theme-color" "#77aa99")), but I
also have opengraph metadata which is based on the title/author/etc.
See
https://tecosaur.github.io/emacs-config/config.html#extra-header-content,code--2
I can't imagine any non-irritating way to have this occur without
making use of this exposed functionality, and I doubt I'm the only one
who has something they'd like to do which makes use of this.
Thanks to the code cleanup / refactoring in the first commit, this
option is pretty trivial to expose, so I thought why not!
Does this help clarify the purpose to you?
Timothy.
p.s.I'd rather not have to copy-paste (evern by template expansion)
several lines like this into every file I export :cry:
#+HTML_HEAD: {{{meta_maybe_description}}}
#+MACRO: meta_maybe_description (eval (let ((description (delq nil
(org-element-map (org-element-parse-buffer) 'keyword (lambda (kw)
(when (string= "SUBTITLE" (org-element-property :key kw))
(org-element-property :value kw))) (if description (format "" (replace-regexp-in-string "\""
"" (org-html-encode-plain-text description ""))
When I could just have this in my config:
(when (org-string-nw-p (plist-get info :description))
(list "name" "description"
(plist-get info :description))
Timothy E Chapman
tecos...@gmail.com
tecosaur.com
On Wed, 16 Dec 2020 at 12:13, Tom Gillespie wrote:
>
> A question from the slightly uninformed. Why not just use #+html_head:
> possibly with a macro to fill in variable values? That is fully
> extensible and doesn't overload keywords. For title, date, author,
> etc. those can have clearly defined mappings to the html, but
> everything else seems to be handled more sanely with #+html_head:. Am
> I missing something? Best,
> Tom
Re: [PATCH] Enhance org-html--build-meta-info
A question from the slightly uninformed. Why not just use #+html_head: possibly with a macro to fill in variable values? That is fully extensible and doesn't overload keywords. For title, date, author, etc. those can have clearly defined mappings to the html, but everything else seems to be handled more sanely with #+html_head:. Am I missing something? Best, Tom
Re: Bring up a screen giving option to open a series of orgmode files
To hop in on the hypothes.is thread. I have spent quite a bit of time
working with hypothes.is and related tooling (mostly in python), so
here is a brain dump on interactions between org and hypothes.is. As
others have mentioned, this could easily be its own thread. Best!
Tom
A quick note on security for hypothes.is. Last I checked (about 30
seconds ago) there is still no way to control access to groups, if the
identifier for the group leaks then anyone can access it. This is not
the case for private annotations, those can only be seen by someone
with your api key (hopefully just you).
If you are looking for a light weight client that is hypothesis
compatible that could be used to build a tool that can push
annotations to an alternate backend then
https://github.com/judell/hlib might be a reasonable place to start.
Jon has previously used that to create a client that sent annotations
to an alternate backend, which could in theory be an elisp
implementation of a server for the w3c annotation standard that could
feed things to org-protocol (or similar).
If people are interested in this for org-mode I would suggest that a
starting point would be to write an elisp implementation that can
consume and produce the w3c web annotation standard format for
annotations and/or the hypothesis api format.
There are at least 3 different ways that web annotations can be
anchored, offset, xpath, exact + prefix/suffix. In principle you could
translate those into urls and use query parameters to encode the
target selectors. The problem that you will run into is that there are
some rather sizeable selector patterns like the example below (that I
happened to have up in another terminal) which will be a pain to work
with as urls. As a result of this a reasonable workflow would be to
create a custom link type for the hypothes.is annotation urls e.g. the
equivalent of #+link: hyp https://hyp.is/ and simply paste in a
shortened form of the share links. In addition one might want some
additional tooling so that the contents of the annotation could be
retrieved and cached, or retrieved, transformed, and embedded in the
document as an appendix during export (or similar).
Unifying org-capture, org-protocol, and general org hyperlinking with
the w3c spec seems like it would be hard in the general case, but for
specific use cases I can imagine that some reduced syntax could be
created that would fit in an org hyperlink. It actually would probably
be easier to do this by
coming up with a way to convert structured org sections or blocks to
and from the w3c spec, name those, and then use org hyperlinks to
refer to
the annotations directly in an org file that functioned as an
annotation store. Much less overhead than trying to set up a
stripped-down stand-alone web annotation server, and if you can
produce json to match the hypothes.is API then you could make use of
that to publish and share annotations/links when you go to publish an
org document.
'selector': [{'type': 'FragmentSelector',
'value': 'pes-1',
'conformsTo': 'https://tools.ietf.org/html/rfc3236'},
{'type': 'RangeSelector',
'endOffset': 92,
'startOffset': 86,
'endContainer':
'/div[4]/div[1]/div[4]/div[1]/article[1]/section[1]/article[1]/div[1]/div[2]/ul[1]/li[1]/div[3]/div[2]/div[1]/div[1]/div[1]/div[1]/div[1]/div[1]/figure[1]/div[1]/div[1]/div[1]/div[1]/div[2]/div[1]/div[1]',
'startContainer':
'/div[4]/div[1]/div[4]/div[1]/article[1]/section[1]/article[1]/div[1]/div[2]/ul[1]/li[1]/div[3]/div[2]/div[1]/div[1]/div[1]/div[1]/div[1]/div[1]/figure[1]/div[1]/div[1]/div[1]/div[1]/div[2]/div[1]/div[1]'},
{'end': 3034, 'type': 'TextPositionSelector', 'start': 3028},
{'type': 'TextQuoteSelector',
'exact': '100kHz',
'prefix': ' DC - 20kHz\nSampling frequency: ',
'suffix': '\nOnboard stimulatorNeural Interf'}]}
Re: Release Org 9.4.2
Bastien writes: >> My question is/are: (1) Why Org is developed outside Emacs, given that >> it is a core/built-in package. > > When Org's development switched to Git (13 years ago, from memory), > the release cycle was very short. Way shorter than the release cycle > of Emacs. Also, the process for accepting new code contributors was > lighter, even when we asked them to sign the FSF copyright assignment. > > In this context, having a separate Git repo was a huge plus, and Org > was not yet included of Emacs. > > Then Org became part of Emacs, which was a very important move. > > But still, using a separate repo and a separate mailing list was key > in being free to progress at our own pace, which was still quite fast. > > Today, the release cycle of Org is longer and that of Emacs shorter. > So yes, it could make sense to envision a destiny similar to Gnus: > Gnus is now developed in Emacs and Org could also be developed in > Emacs. Thanks for writing this. This explains everything. > But (1) it is not only *our* decision, it's also in the hands of the > Emacs maintainers, which may think otherwise; (2) all the consequences > need to be considered, as it is a sensible move; (3) I am on the verge > of stepping down as a maintainer, so it is not a good time for me to > push into a direction or another. I sensed (3) when I saw an email (last month I guess) about assimilating parts of Org into Emacs. While that is a good idea. But I don’t have a very good feeling about you leaving. You have contributed so much. You have maintained it so well. I can understand how it feels when people complain about features. And sometimes they blame the maintainers for some specific product directions. But it is bound to happen when they are also attached to the product. I hope these things have not shaped up your decision. It happens in a closely knit family. > Anyway, I don't think now is the right time to consider this move, as > there are many more things to achieve. I suggest we discuss this again > later next year. Yes. This is endless. We’ll continue this...
Re: unwanted files found by what exactly?
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
Re: [9.4] Fixing logbook visibility during isearch
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). The function must accept two arguments: overlay and flag. If flag is non-nil, the function should re-hide the overlay text and it should reveal the overlay when flag is nil. Best, Ihor
Re: unwanted files found by what exactly?
i suspect org-id-update-id-locations is finding but then failing to kill the buffers.
unwanted files found by what exactly?
recent-ish org maint. i frequently get all my .org_archive files and whatever.org files in emacs as buffers, without my calling find-file. i thought perhaps this was agenda, so (defun alpha-org-kill-agenda-loaded-buffers () (interactive) (org-release-buffers org-agenda-new-buffers) (setq org-agenda-new-buffers nil)) but that doesn't seem to always work. so, is org-id loading buffers when it searches for an id target, or something like that? regardless of source, is there a timer i can set to delete all these things? if it is the agenda i don't mind the occasional miss if i try to go to a killed buffer. whatever agenda habits i have aren't likly to change and i'd rather not have the buffers not stick around. if it is org-id or something else, could they all be killed once the target has been found? thanks.
Re: Bring up a screen giving option to open a series of orgmode files
Jean Louis writes: > For PDF and video with specific start time I am using different type > of hyperlinks and not Org hyperlinks. So I was under impression that > Org hyperlinks to PDF support specific page. I have even prepared > myself to start including such in instructional manual. But do they? > It implies that PDF viewer setting should be per user configurable to > accept the page argument. Manual does not mention that. However, looking into the code handling opening file links, I can see that it is actually possible. By default, the link like file:document.pdf::10 would run system command used to open pdfs with "document.pdf::10" argument. Whether that system command supports such kind of argument is another question (answer: probably, no). On the other hand, user can customise org-file-apps variable and put a lisp function to handle link opening. That function can transform the "document.pdf::10" into something that can be passed to the pdf viewer in system. > One possible solution could be this. For annotations, hypothes.is uses > Javascript library http://annotatorjs.org/ and I have not finished > research of it. I just have some slight idea that the whole annotation > and position of annotation could be captured in a hyperlink to it by > using that library. Thanks for the link. > Maybe you know Javascript and you can try? I don't know Javascript Best, Ihor
Re: Bring up a screen giving option to open a series of orgmode files
On 2020-12-14 23:42, Ihor Radchenko wrote: TRS-80 writes: We are getting further and further afield from Orgmode discussion, however I wanted to share the following article with anyone else who followed this part of the thread all the way to this point: Oops. Actually, hypothes.is is related to org-mode in my mind. Mostly as a reference of implementation of fine-grained links to web-pages/documents. I wish org-mode links had universal support to position inside the document the link is pointing to (similar what is already present in file link to org files, where we can refer to specific heading inside the referenced file). It would be great if org-mode extended the link syntax to define position inside the text file/web-page/video/pdf/etc. 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. The relevant feature request is in my todo list. Best, Ihor Oh no, I think you guys are fine. I just didn't want to get into big discussion about things on that website, as there are just s many things there to discuss... So when I said that, I was referring mostly to myself and also as a way to sort of pre-emptively try and head off too big diversion... :) Cheers, TRS-80
behavior/docs of iCalendar export
This is a very small thing, but it came up today for me, so I thought I'd mention it. (Org 9.4.2, for the record.) 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. So after reading the docs[1][2] I created a minimal org file, which as it happens only had a single time for the single event in it. I tried to export via C-c C-e c f, and immediately got an error that org-agenda-default-appointment-duration wasn't set (which was perfectly true, I hadn't set it and it defaults to nil). So after looking at that variable's documentation, just to make sure it was well-named and didn't do something strange, I set it and went on about my merry way. As I say, a very small thing. I mention it only because it was slightly irritating that after actually taking the time to read the documentation, I still had to troubleshoot (if you want to call it that) briefly. All of which leads up to: my suggestion is that either that org-agenda-default-appointment-duration have an actual default value, or else that [2] should mention that one might want to set it. [1] https://orgmode.org/manual/Timestamps.html#Timestamps [2] https://orgmode.org/manual/iCalendar-Export.html
Re: Release Org 9.4.2
On 15/12/2020 14:58, Pankaj Jangid wrote: > Eric S Fraga writes: > >> On Monday, 14 Dec 2020 at 20:49, Pankaj Jangid wrote: >>> I like testing Emacs on the trunk and I ‘git pull’ and ‘make bootstrap’ >>> daily and use it without any external packages. This is just to make >>> sure that any external package is not the cause for what appears to be >>> an Emacs bug. >>> >>> I can certainly add latest Org by adding it to the package-archives. >> >> Or you could track org development from git just as you are tracking >> Emacs. That's what I do: any time I build the most recent Emacs (maybe >> every 2-3 weeks), I also build org. > > May be that I am not explaining it well. Let me put it in a question > format. It is possible that this has been discussed and I appologise for > my ignorance. > > My question is/are: (1) Why Org is developed outside Emacs, given that > it is a core/built-in package. (2) Are there other packages that follow > the same process? AFAIK also cc-mode is developed in a dedicate repository. >From an Emacs development point of view there is the desire to move more packages that are now included in the core to ELPA and assemble Emacs releases from these. This will allow packages to have independent releases and users to update them more frequently than the pace of Emacs releases. In this process, moving more packages to separate git repositories would be natural. Thus, the idea would be remove the need for syncing the org and cc-mode codebases to the Emacs repository rather than moving the development of these packages to the Emacs git. Cheers, Dan
[9.4] Fixing logbook visibility during isearch
Ihor Radchenko writes: > However, I can try to suggest a way to fix the issue on master. The way > isearch handles folded text in org is set from org-flag-region > (org-macs.el): > > (overlay-put o > 'isearch-open-invisible > (lambda ( _) (org-show-context 'isearch))) > > It means that isearch calls org-show-context (org.el) to reveal hidden > text. Then, it calls org-show-set-visibility with argument defined in > org-show-context-detail (now, it is 'lineage). With current defaults, > the searched text is revealed using org-flag-heading, which reveals both > heading body and drawers. > > The easiest way to write the fix would be changing org-flag-heading > directly, but there might be unforeseen consequences on other folding > commands. > > Another way would be changing the way org-show-set-visibility handles > 'lineage argument. Again, it may affect other things. > > Finally, one can add an extra possible argument to > org-show-set-visibility and alter default value of > org-show-context-detail accordingly. > > The last way will have least risk to break something else. > > I guess, patches welcome ;) Since Org 9.4 has landed in the emacs-27 branch, I have renewed interest in finding a fix for this before 27.2 is released (… and more selfishly, before emacs-27 is merged into master ). I'm a bit confused, because AFAICT org-show-context is called *after* exiting isearch, so IIUC by the time org-show-set-visibility is called it's too late to undo the damage. Recipe using my repro file[1]: - C-x C-f logbooks.org - M-x toggle-debug-on-entry org-show-context - C-s bug 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? [1] wget https://orgmode.org/list/87eepuz0bj@gmail.com/2-logbooks.org -O tmp/logbooks.org
[Small suggestion] on exporting verse blocks to LaTeX and vertical spaces
Hi,
When exporting a verse block to LaTeX, each empty line between
'stanzas' results in the command =\vspace*{1em}=, which is fine.
However, I would dare to suggest that, in order to be more consistent
with the LaTeX `verse' environment (both the one that comes by
default and the one provided by the verse.sty package) the separation
between stanzas should be marked with:
- the last line of the stanza without =\\=
- + one (at least) empty line
which is the correct (or at least the most common) way to separate the
stanzas within this environment, since each stanza is still a
paragraph whose lines are cut off. Thus, we could also redefine
globally the \stanzaskip length provided by the verse.sty package
(i.e. \setlength{\stanzaskip}{1.2em plus .2em minus .5em}, etc.).
For example, with this (the number of white lines does not matter):
#+begin_src org
,#+begin_verse
Lorem ipsum dolor sit amet
consectetuer adipiscing elit
Lorem ipsum dolor sit amet
consectetuer adipiscing elit
Lorem ipsum dolor sit amet
consectetuer adipiscing elit
Lorem ipsum dolor sit amet
consectetuer adipiscing elit
,#+end_verse
#+end_src
we should get:
#+begin_src latex
\begin{verse}
Lorem ipsum dolor sit amet\\
consectetuer adipiscing elit\\
Lorem ipsum dolor sit amet\\
consectetuer adipiscing elit
Lorem ipsum dolor sit amet\\
consectetuer adipiscing elit\\
Lorem ipsum dolor sit amet\\
consectetuer adipiscing elit\\
\end{verse}
#+end_src
Perhaps replacing these lines in =org-latex-verse-block=
#+begin_src emacs-lisp
(replace-regexp-in-string
"^[ \t]*$" "\\vspace*{1em}"
#+end_src
with something like this
#+begin_src emacs-lisp
(replace-regexp-in-string
"\\(\n\\)+\\([ \t]*\\)+" "\n"
#+end_src
?
(On the other hand, I also think that vertical spaces between groups
of lines in verse blocks should always be exported to any format as
a single fixed space, regardless of how many empty lines there are).
Regards,
Juan Manuel
Re: [Institute field]
>>> "ESF" == Eric S Fraga writes:
> On Monday, 14 Dec 2020 at 20:51, Uwe Brauer wrote:
>> I just realised that beamer allows
>>
>> \institute{\texttt{email:o...@mat.ucm.es}}
>>
>> But this does not get translated when I add to the org file
>>
>> #+institute: : o...@mat.ucm.es
>>
>> Any ideas?
> Just put it in directly, as in
> #+latex_header: \institute{...}
Thanks!
smime.p7s
Description: S/MIME cryptographic signature
Re: [final patch] Re: add new link type "contact:" for org-contacts.el
stardiviner writes: > If this is confirmed, I might don't need to add a new patch to add my > name to maintainer. Can you add it directly? That will be more > simple. Of course, done (c822c80ef). Sorry I forgot about this patch, and thanks for your reply. -- Bastien
Re: [final patch] Re: add new link type "contact:" for org-contacts.el
Thanks for reviewing. Don't know why, it's been applied in the "master" branch already by you. (I did git pull from upstream) Here is the commit: e9c3993ee * | org-contacts.el: Add new link type "contact:" If this is confirmed, I might don't need to add a new patch to add my name to maintainer. Can you add it directly? That will be more simple. [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 Tue, Dec 15, 2020 at 5:56 PM Bastien wrote: > stardiviner writes: > > > My patch still in the previous "[UPDATED PATCH]" state. (I attached > > in this email) > > Thanks. It applies correctly on the maint branch but I'd rather apply > it againt the master branch, where it fails to apply. > > Can you replay your changes on top of the main branch, and also add > your name as the maintainer? > > Thanks a lot! > > -- > Bastien >
Re: Release Org 9.4.2
Hi Pankaj, Pankaj Jangid writes: > My question is/are: (1) Why Org is developed outside Emacs, given that > it is a core/built-in package. When Org's development switched to Git (13 years ago, from memory), the release cycle was very short. Way shorter than the release cycle of Emacs. Also, the process for accepting new code contributors was lighter, even when we asked them to sign the FSF copyright assignment. In this context, having a separate Git repo was a huge plus, and Org was not yet included of Emacs. Then Org became part of Emacs, which was a very important move. But still, using a separate repo and a separate mailing list was key in being free to progress at our own pace, which was still quite fast. Today, the release cycle of Org is longer and that of Emacs shorter. So yes, it could make sense to envision a destiny similar to Gnus: Gnus is now developed in Emacs and Org could also be developed in Emacs. But (1) it is not only *our* decision, it's also in the hands of the Emacs maintainers, which may think otherwise; (2) all the consequences need to be considered, as it is a sensible move; (3) I am on the verge of stepping down as a maintainer, so it is not a good time for me to push into a direction or another. > (2) Are there other packages that follow the same process? I don't know. It could be useful to compare Org situation to other packages but at the same time, Org is quite peculiar. Anyway, I don't think now is the right time to consider this move, as there are many more things to achieve. I suggest we discuss this again later next year. Thanks, -- Bastien
Re: Release Org 9.4.2
Eric S Fraga writes: > On Monday, 14 Dec 2020 at 20:49, Pankaj Jangid wrote: >> I like testing Emacs on the trunk and I ‘git pull’ and ‘make bootstrap’ >> daily and use it without any external packages. This is just to make >> sure that any external package is not the cause for what appears to be >> an Emacs bug. >> >> I can certainly add latest Org by adding it to the package-archives. > > Or you could track org development from git just as you are tracking > Emacs. That's what I do: any time I build the most recent Emacs (maybe > every 2-3 weeks), I also build org. May be that I am not explaining it well. Let me put it in a question format. It is possible that this has been discussed and I appologise for my ignorance. My question is/are: (1) Why Org is developed outside Emacs, given that it is a core/built-in package. (2) Are there other packages that follow the same process?
Re: [PATCH] Enhance org-html--build-meta-info
Thanks for testing Jens. I think I've managed to resolve the issues
you've raised.
Jens, Bastien, you can find the latest revision of the patches attached :)
Jens Lechtenboerger writes:
> [title export being dodgy, how about treating like author?]
Yep, ~org-element-interpret-data~ is necessary. I found that wrapping it
in ~org-html-plain-text~ seems better again though, as it encodes
entities like "---" (org) to "", and doesn't seem to introduce
any nested tags. I've also applied this to the author field as a result.
Maybe it should be applied to the rest (in ~org-html--build-meta-info~)?
I'm not sure.
> The keywords export as follows, where the name attribute is missing:
>
Fixed.
> The current lambda functions in org-html-meta-tags all accept three
> arguments, where the first one is ignored in all cases. The second
> one is used in exactly one case. Why not add four calls to
> org-html--build-meta-entry (for author, description, keywords,
> generator) in org-html--build-meta-info?
I had an idea on this, I think the new form is cleaner.
Either have a list where each item generates a meta entry, or a function
that generates such a list. No more mixing of the two.
How does this look?
Timothy.
>From 9848af808752bc03404befaab7ab5ebb902aa1d0 Mon Sep 17 00:00:00 2001
From: TEC
Date: Mon, 14 Dec 2020 17:41:33 +0800
Subject: [PATCH 1/2] lisp/ox-html.el: make html meta tag builder nicer
* lisp/ox-html.el (org-html--build-meta-info): Multi-line repeated
structure extracted to new function `org-html--build-meta-entry'.
The keyword value formatting is changed from `org-export-data' to
`org-html-encode-plain-text' to avoid potentially nesting HTML tags in
meta tags and the element, which would violate W3C.
---
lisp/ox-html.el | 114
1 file changed, 56 insertions(+), 58 deletions(-)
diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index d2f24f5c6..005703f60 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -1835,78 +1835,76 @@ INFO is a plist used as a communication channel."
;;; Template
+(defun org-html--build-meta-entry (label identity content-format content-formatters)
+ "Construct tag of form , or when CONTENT-FORMAT is present:
+
+
+Here {content} is determined by applying any CONTENT-FORMATTERS to the CONTENT-FORMAT and encoding
+the result as plain text."
+ (concat "\n"))
+
(defun org-html--build-meta-info (info)
"Return meta tags for exported document.
INFO is a plist used as a communication channel."
- (let* ((protect-string
- (lambda (str)
-(replace-regexp-in-string
- "\"" "" (org-html-encode-plain-text str
- (title (org-export-data (plist-get info :title) info))
- ;; Set title to an invisible character instead of leaving it
- ;; empty, which is invalid.
- (title (if (org-string-nw-p title) title ""))
- (author (and (plist-get info :with-author)
- (let ((auth (plist-get info :author)))
+ (let* ((title (org-html-plain-text
+ (org-element-interpret-data (plist-get info :title)) info))
+ ;; Set title to an invisible character instead of leaving it
+ ;; empty, which is invalid.
+ (title (if (org-string-nw-p title) title ""))
+ (author (and (plist-get info :with-author)
+ (let ((auth (plist-get info :author)))
;; Return raw Org syntax.
-(and auth (org-element-interpret-data auth)
- (description (plist-get info :description))
- (keywords (plist-get info :keywords))
- (charset (or (and org-html-coding-system
- (fboundp 'coding-system-get)
- (coding-system-get org-html-coding-system
- 'mime-charset))
- "iso-8859-1")))
+ (and auth (org-html-plain-text
+ (org-element-interpret-data auth) info)
+ (charset (or (and org-html-coding-system
+ (fboundp 'coding-system-get)
+ (symbol-name
+ (coding-system-get org-html-coding-system
+ 'mime-charset)))
+ "iso-8859-1")))
(concat
(when (plist-get info :time-stamp-file)
(format-time-string
(concat "\n")))
- (format
- (if (org-html-html5-p info)
- (org-html-close-tag "meta" "charset=\"%s\"" info)
- (org-html-close-tag
- "meta" "http-equiv=\"Content-Type\" content=\"text/html;charset=%s\""
- info))
- charset) "\n"
+
+ (if (org-html-html5-p info)
+ (org-html--build-meta-entry "charset" charset)
+ (org-html--build-meta-entry "http-equiv" "Content-Type"
+ (concat "text/html;charset=" charset)))
+
(let ((viewport-options
(cl-remove-if-not (lambda (cell) (org-string-nw-p (cadr cell)))
(plist-get info :html-viewport
- (and viewport-options
- (concat
- (org-html-close-tag
- "meta"
- (format "name=\"viewport\" content=\"%s\""
- (mapconcat
- (lambda
Re: [Institute field]
On Monday, 14 Dec 2020 at 20:51, Uwe Brauer wrote:
> I just realised that beamer allows
>
> \institute{\texttt{email:o...@mat.ucm.es}}
>
> But this does not get translated when I add to the org file
>
> #+institute: : o...@mat.ucm.es
>
> Any ideas?
Just put it in directly, as in
#+latex_header: \institute{...}
That's what I do.
--
: Eric S Fraga via Emacs 28.0.50, Org release_9.4-160-g7c8dce
Re: Release Org 9.4.2
On Monday, 14 Dec 2020 at 20:49, Pankaj Jangid wrote: > I like testing Emacs on the trunk and I ‘git pull’ and ‘make bootstrap’ > daily and use it without any external packages. This is just to make > sure that any external package is not the cause for what appears to be > an Emacs bug. > > I can certainly add latest Org by adding it to the package-archives. Or you could track org development from git just as you are tracking Emacs. That's what I do: any time I build the most recent Emacs (maybe every 2-3 weeks), I also build org. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4-160-g7c8dce
Re: Time Slots in Org-Agenda
steve-humphr...@gmx.com wrote:
>> >> See org-agenda-time-grid
>> >
>> > Where can I find some information on how to use it?
>> Menu help -> Describe -> Describe variable org-agenda-time-grid
>> or
>> v org-agenda-time-grid
> At first
> I have started with the following command, but emacs does not like it
> (setq times '(800 1000 1200))
> (setq freq '("daily" "today"))
> (setq org-agenda-time-grid '(freq times "---" "+++"))
> I also tried variants thereof. My elisp is not so good
> but tried to have a look at the code.
> […]
The last line means: Set the variable org-agenda-time-grid
to a list that consists of the symbol (!) "freq", the sym-
bol "times", the string "---" and the string "+++". How-
ever, you want the first and second elements to be the val-
ues of those variables, so you could say:
| (setq org-agenda-time-grid `(,freq ,times "---" "+++"))
or:
| (setq org-agenda-time-grid (list freq times "---" "+++"))
(NB: There are more subtleties to this (e. g., a symbol can
have separate meanings as a variable and a function (and I
really should finally read the elisp info file from begin-
ning to end :-, but my most common mistake is either to
quote something that I do not want to quote or not quote
something that I do want to quote.)
Tim
Re: [final patch] Re: add new link type "contact:" for org-contacts.el
stardiviner writes: > My patch still in the previous "[UPDATED PATCH]" state. (I attached > in this email) Thanks. It applies correctly on the maint branch but I'd rather apply it againt the master branch, where it fails to apply. Can you replay your changes on top of the main branch, and also add your name as the maintainer? Thanks a lot! -- Bastien
[final patch] Re: add new link type "contact:" for org-contacts.el
My patch still in the previous "[UPDATED PATCH]" state. (I attached in this email) I can take a try to be the maintainer for org-contacts.el Seems it's not very frequently mentioned. So I don't spend too much time on it. [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 Mon, Dec 14, 2020 at 2:06 PM Bastien wrote: > Hi stardiviner, > > what is the last state of your patch? Feel free to resend it, > I will apply it. > > Also, do you want to become the maintainer for org-contacts.el? > > Remember, elisp files in contrib/ will soon be extracted from > the repository: https://orgmode.org/list/87wnzfy60h@bzg.fr > > Still, it's useful to already know who will be in charge. > > Thanks, > > -- > Bastien > From 7446c0dda49554db0af18401984d20b9b460d408 Mon Sep 17 00:00:00 2001 From: stardiviner Date: Fri, 30 Oct 2020 15:11:53 +0800 Subject: [PATCH] org-contacts.el: Add new link type "contact:" * contrib/lisp/org-contacts.el (org-contacts-link-store): Store a link of org-contacts in Org file. * contrib/lisp/org-contacts.el (org-contacts-link-open): Open contact: link in Org file. * contrib/lisp/org-contacts.el (org-contacts-link-complete): Insert a contact: link with completion of contacts. * contrib/lisp/org-contacts.el (org-contacts-link-face): Set different face for contact: link. --- contrib/lisp/org-contacts.el | 75 1 file changed, 75 insertions(+) diff --git a/contrib/lisp/org-contacts.el b/contrib/lisp/org-contacts.el index 4b3693a0e..d8d498425 100644 --- a/contrib/lisp/org-contacts.el +++ b/contrib/lisp/org-contacts.el @@ -1146,6 +1146,81 @@ (defun org-contacts-split-property (string separators omit-nulls) (setq proplist (cons bufferstring proplist (cdr (reverse proplist +;;; Add an Org link type `org-contact:' for easy jump to or searching org-contacts headline. +;;; link spec: [[org-contact:query][desc]] +(org-link-set-parameters "org-contact" + :follow 'org-contacts-link-open + :complete 'org-contacts-link-complete + :store 'org-contacts-link-store + :face 'org-contacts-link-face) + +(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)) +(let ((headline-str (substring-no-properties (org-get-heading t t t t + (org-store-link-props + :type "org-contact" + :link headline-str + :description headline-str + +(defun org-contacts--all-contacts () + "Return an alist (name . (file . position)) of all contacts in `org-contacts-files'." + (car (mapcar + (lambda (file) + (unless (buffer-live-p (get-buffer (file-name-nondirectory file))) + (find-file file)) + (with-current-buffer (get-buffer (file-name-nondirectory file)) + (org-map-entries + (lambda () + (let ((name (substring-no-properties (org-get-heading t t t t))) + (file (buffer-file-name)) + (position (point))) + `(:name ,name :file ,file :position ,position)) + org-contacts-files))) + +(defun org-contacts-link-open (path) + "Open contacts: link type with jumping or searching." + (let ((query path)) +(cond + ((string-match "/.*/" query) + (let* ((f (car org-contacts-files)) + (buf (get-buffer (file-name-nondirectory f + (unless (buffer-live-p buf) (find-file f)) + (with-current-buffer buf + (string-match "/\\(.*\\)/" query) + (occur (match-string 1 query) + (t + (let* ((f (car org-contacts-files)) + (buf (get-buffer (file-name-nondirectory f + (unless (buffer-live-p buf) (find-file f)) + (with-current-buffer buf + (goto-char (marker-position (org-find-exact-headline-in-buffer query) + ;; FIXME + ;; (let* ((contact-entry (plist-get (org-contacts--all-contacts) query)) + ;; (contact-name (plist-get contact-entry :name)) + ;; (file (plist-get contact-entry :file)) + ;; (position (plist-get contact-entry :position)) + ;; (buf (get-buffer (file-name-nondirectory file + ;; (unless (buffer-live-p buf) (find-file file)) + ;; (with-current-buffer buf (goto-char position))) + + +(defun org-contacts-link-complete ( arg) + "Create a org-contacts link using completion." + (let ((name (completing-read "org-contact Name: " + (mapcar +(lambda (plist) (plist-get plist :name)) +(org-contacts--all-contacts) +(concat "org-contact:" name))) + +(defun org-contacts-link-face (path) + "Different face color for different org-contacts link query." + (cond + ((string-match "/.*/" path) +'(:background "sky blue" :overline t :slant 'italic)) + (t '(:background "green yellow" :underline t + (provide 'org-contacts)
Re: Emacs as an Org LSP server
On Mon, Dec 14, 2020 at 7:35 PM Gerry Agbobada wrote: > Furthermore, I find that spending so much time and energy to prevent > people from spending their time on what they think is right, is pretty > harmful. > This is really key. Timothy, please keep up the good work and pay no attention to people who are trying to discourage you! -- Bill
Re: More on design of org-contacts.el - Re: [UPDATED PATCH] Re: add new link type "contact:" for org-contacts.el
Change an email is hard word for me. I use gmail address for many places. I started to use new email for new accounts recently. But switch email need to be later when I have time and desire. And thanks for your suggestion of mail services. :smile: [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 Tue, Nov 17, 2020 at 2:50 PM Jean Louis wrote: > * stardiviner [2020-11-16 13:21]: > :PROPERTIES: > :ID: e2c30814-b983-4391-869a-3c700d041467 > :END: > > > > First, thank your very much for suggestion. > > > > What really I have not found your email in my Gmail (in web > > browser), > > Maybe because it went to Spam/Junk folder. For privacy and safety > reasons I do not recommend using Gmail at all. > > I may recommend using your own email address, requires some money, or > https://posteo.de/ https://tutanota.de/ or https://protonmail.ch/ > > > I found it in mu4e (Emacs). Which I can't reply because I'm in > > China, sendmail to Gmail SMTP server is blocked. So I'm replying you > > in mu4e. Don't know whether you can receive my message. > > I wish I could understand, mu4e is only local system that searches > emails on your computer. How you send emails depends on your email > provider. Maybe you fetch mailing list to search for emails? > > > Using unique ID is the only solution to identity contact. I already > thought > > about this. But integrating org-id is hard for me. Have not spent that > time on > > it yet. But I will, if I want to improve this org-contacts. > > If I may just give idea. I am using this below function to > automatically get ID numbers for headings. Normally it is by > saving. Maybe you can do something to automatically insert such > number. I do not know if heading is contact, but if it is, it becomes > all easier. > > (defun rcd-org-add-ids-to-headlines-in-file () > "Add ID properties to all headlines in the current file which > do not already have one." > (interactive) > (org-map-entries 'org-id-get-create)) > > > > Each hyperdocument (within or without Emacs) that allows back linking > > > to its specifical parts should have a function or key binding to > > > quickly obtain the link reference. > > Once you have decided how is contact referenced as now is referenced > by query, I could maybe figure how to obtain the reference. > > It should not be that hard: > > - find the current heading > > - find current ID number > > - how link should look like could be customizable, maybe heading as > visible part. That requires discussion. > > - prepare link into memory for pasting in other window or document. > > - it should also be possible to insert such into register. > > - the option to obtain link by query should be kept intact > > Maybe two keybindings or functions can be made: > > ** Proposal > :PROPERTIES: > :ID: a566d476-f478-44d8-8d91-53f6eccca10b > :END: > > 1. One that finds the current heading and obtains the link > > (defun capture-contact-by-query-to-heading () > (let* ((heading (org-get-heading)) > (link (format "[[org-contact:query#%s][%s]]" heading heading))) > (kill-new link))) > > (capture-contact-by-query-to-heading) > > => [[org-contact:query#Proposal][Proposal]] > > And such function should be expanded and be customizable: > > - maybe user wish to provide format string as maybe user wish to know > visually that link leads to contact like: > > => [[org-contact:query#John Doe][Contact: John Doe]] > > 2. One that finds currentheading by its ID and obtains the link: > > (defun capture-contact-by-id-to-heading-1 () > (let* ((heading (org-get-heading)) > (id (org-id-get)) > (link (format "[[org-contact:id#%s][%s]]" id heading))) > link)) > > (defun capture-contact-by-id-to-heading () > (kill-new (capture-contact-by-id-to-heading-1))) > > (capture-contact-by-id-to-heading) > > => [[org-contact:id#a566d476-f478-44d8-8d91-53f6eccca10b][Proposal]] > > These are design ideas only. You may expand and make checks on these > functions that such work properly. > > Additional functions that may be very usable is to quickly send links > to other window. User is collecting the database of contacts in one > file and one window and wishes to insert links into other window that > references such contacts. In that file where you need a link you would > arrive with cursor. Then you go to database of contacts and invoke a > key that sends the yanked org link into other window. > > (defun contact-yank-link-in-other-window () > (let ((link (capture-contact-by-id-to-heading-1))) > (kill-new link) > (other-window 1) > (yank) > (other-window 1) > (message "Yanked link: %s to other window" link))) > > It is up to you to expand or think on this as it is design > proposal. Not finalized function or feature. When we wish to > reference things we
