Re: [9.4] Fixing logbook visibility during isearch
Kévin Le Gouguec writes: > 1.2. stumps me: is there an isearch API I can use while in the callback > to know where the matches are located? I do not think that there is direct API for this, but the match should be accessible through match-beginning/match-end, as I can see from the isearch.el code. > For 2.1, I guess we will need to cache the temporary invisible overlays > we add during step 1. in a global list; that way when it's time to > destroy them, we can simply iterate on the list? That's what I do in org-fold--isearch-show-temporary. Best, Ihor
Re: Yet another browser extension for capturing notes - LinkRemark
maxim, it is great to see new work in this area. thanks for sharing. russell, i use the org-capture extension for firefox, which is on the firefox extensions site. it is for if you want a different set of data captured [it uses your org capture template]. it works well for me. [not a suggestion for maxim to integrate into everything; ignore please. i can imagine great things possible with such extensions. for example, you could have sets of tabs, selected by right click in firefox, to save to a bunch of org entries. then you could load that particular set of entries into firefox whenever you want. and you could keep notes on each page and move the entries wherever you want. this would be useful for such things as "i am researching rice cookers; these are my tabs, but i don't want them cluttering firefox and i want them with my org notes and to make notes on them and will re-load them into firefox when i want to revisit".] [now if i can only debug the extra-blank-lines-in-capture problem.] On 12/25/20, Russell Adams wrote: > On Fri, Dec 25, 2020 at 07:44:22PM +0700, Maxim Nikulin wrote: >> I am experimenting with a browser add-on that is intended >> to be a bridge between browser and Org mode. >> In the family of Org mode capture helpers it is among ones >> that adds web page metadata to the note. >> Source code repository: https://github.com/maxnikulin/linkremark > > That's a really neat idea! > > I hadn't previously considered having a Firefox plugin to capture > information. Now I must look! > > -- > Russell Adamsrlad...@adamsinfoserv.com > > PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ > > Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3 > > -- 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
Ihor Radchenko writes: > However, org-cycle-hide-drawers might be called in > isearch-open-invisible-temporary. This callback receives two arguments: - the overlay which contains a match, - whether we are un-hiding the overlay's span or hiding it back. To get the same behaviour as Org≤9.3, IIUC we want to do the following: 1. When isearch asks us to un-hide, 1. go over all drawers within the overlay, 2. hide those that do not contain a match, by adding an invisible overlay. 2. When isearch asks us to hide back, 1. remove the invisible overlays we have put on these drawers. 1.1. is straightforward: overlay-start and overlay-end tell us where to look for drawers. 1.2. stumps me: is there an isearch API I can use while in the callback to know where the matches are located? For 2.1, I guess we will need to cache the temporary invisible overlays we add during step 1. in a global list; that way when it's time to destroy them, we can simply iterate on the list? (Sorry for being so slow I never seem to be able to spend more than 10 minutes on this issue before having to switch to something else…)
Re: [ANN] EmacsConf 2020 videos are out!
Sébastien G writes: > Nice. > > Thanks to everyone. Cheers, and indeed, thanks to everyone involved. :-) > Did you know if the videos are also on Peertube ? As of a few days ago, they are indeed. I've uploaded them to the EmacsConf account on SDF's PeerTube instance, toobnix, tagged in three playlists: EmacsConf 2020: https://toobnix.org/videos/watch/playlist/c3ac2f22-6434-4e22-8792-b6422402c3c9 chip8.el demos (from EmacsConf 2020): https://toobnix.org/videos/watch/playlist/f6d9bb86-da35-461c-b109-c2daa414b848 Dungeon demos (from EmacsConf 2020): https://toobnix.org/videos/watch/playlist/10d71a32-3a00-417a-a24e-47928d3611f2 They of course remain available via the https://emacsconf.org/2020/talks subpages of the EmacsConf website/wiki as well. signature.asc Description: PGP signature
[tip] Export subfigures to LaTeX (and HTML)
Hi,
I have come up with a way to export subfigures to LaTeX (with the subfigure
package) by
defining a new link type. The 'subcaption' of the subfigure would be the
description of
the link. If we want to add parameters such as width, scale, etc., we can put
them next
between the marks '>( ... )'
The code:
#+begin_src emacs-lisp
(org-link-set-parameters
"subfig"
:follow (lambda (file) (find-file file))
:face '(:foreground "chocolate" :weight bold :underline t)
:display 'full
:export (lambda (file desc backend)
(when (eq backend 'latex)
(if (string-match ">(\\(.+\\))" desc)
(concat "\\subfigure[" (replace-regexp-in-string "\s+>(.+)"
"" desc) "]"
"{\\includegraphics"
"["
(match-string 1 desc)
"]"
"{"
file
"}}")
(format "\\subfigure[%s]{\\includegraphics{%s}}" desc file)
#+end_src
Example:
#+begin_src org
,#+CAPTION: Lorem impsum dolor
,#+ATTR_LaTeX: :options \centering
,#+begin_figure
[[subfig:img1.jpg][Caption of img1 >(width=.3\textwidth)]]
[[subfig:img2.jpg][Caption of img2 >(width=.3\textwidth)]]
[[subfig:img3.jpg][Caption of img3 >(width=.6\textwidth)]]
,#+end_figure
#+end_src
Results:
#+begin_src latex
\begin{figure}\centering
\subfigure[Caption of img1]{\includegraphics[width=.3\textwidth]{img1.jpg}}
\subfigure[Caption of img2]{\includegraphics[width=.3\textwidth]{img2.jpg}}
\subfigure[Caption of img3]{\includegraphics[width=.6\textwidth]{img3.jpg}}
\caption{Lorem impsum dolor}
\end{figure}
#+end_src
If we want to export to HTML it would be something more tricky. In this case,
the export
function could be like this (a width parameter would be enclosed between >{ ...
}):
#+begin_src emacs-lisp
(lambda (file desc backend)
(cond
((eq backend 'latex)
(if (string-match ">(\\(.+\\))" desc)
(concat "\\subfigure[" (replace-regexp-in-string "\s*>.+" "" desc)
"]" "{\\includegraphics" "[" (match-string 1 desc) "]" "{" file "}}")
(format "\\subfigure[%s]{\\includegraphics{%s}}"
(replace-regexp-in-string "\s*>.+" "" desc) file)))
((eq backend 'html)
(if (string-match "{\\(.+\\)}" desc)
(concat ""
(replace-regexp-in-string "\s*.+" "" desc)
"")
(format "%s"
file file
(replace-regexp-in-string "\s*.+" "" desc))
#+end_src
Example:
#+begin_src org
,#+CAPTION: Lorem impsum dolor
,#+ATTR_LaTeX: :options \centering
,#+begin_figure
@@html:@@
[[subfig:img1.jpg][Caption of img1 >(width=.3\textwidth) >{300px}]]
[[subfig:img2.jpg][Caption of img2 >(width=.3\textwidth) >{300px}]]
@@html: @@
[[subfig:img3.jpg][Caption of img3 >(width=.6\textwidth) >{600px}]]
@@html:Lorem ipsum dolor@@
,#+end_figure
#+end_src
As you can see, it is not the panacea, and you have to apply some direct
format...
Happy holidays
Juan Manuel
Re: Yet another browser extension for capturing notes - LinkRemark
On Fri, Dec 25, 2020 at 07:44:22PM +0700, Maxim Nikulin wrote: > I am experimenting with a browser add-on that is intended > to be a bridge between browser and Org mode. > In the family of Org mode capture helpers it is among ones > that adds web page metadata to the note. > Source code repository: https://github.com/maxnikulin/linkremark That's a really neat idea! I hadn't previously considered having a Firefox plugin to capture information. Now I must look! -- Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
Re: Yet another browser extension for capturing notes - LinkRemark
Maxim Nikulin writes: > I am experimenting with a browser add-on that is intended > to be a bridge between browser and Org mode. > In the family of Org mode capture helpers it is among ones > that adds web page metadata to the note. > Source code repository: https://github.com/maxnikulin/linkremark The author of org-capture-ref here. Reading through the code, I can see that you are familiar with metadata conventions. Do you know good references about what og: metadata is commonly used? I looked through the official OpenGraph specification, but popular websites appear to ignore most of the conventions. Also, org-capture-ref does not really force the user to put BiBTeX into the capture. Individual metadata fields are available using org-capture-ref-get-bibtex-field (which extracts data from internal alist structure). It's just that I mostly had BiBTeX in mind (with distant goal of supporting export to LaTeX) for my use-cases. Finally, would you be interested to join efforts on metadata parsing? (I hope this question does not qualify as "integrate this extension to everything"). P.S. Some links I collected myself when working on org-capture-ref. They might also be of interest for you: - https://github.com/ageitgey/node-unfluff - https://github.com/gabceb/node-metainspector - https://github.com/wikimedia/html-metadata - https://github.com/microlinkhq/metascraper - https://github.com/hboisgibault/unicontent Best, Ihor
Yet another browser extension for capturing notes - LinkRemark
I am experimenting with a browser add-on that is intended to be a bridge between browser and Org mode. In the family of Org mode capture helpers it is among ones that adds web page metadata to the note. Source code repository: https://github.com/maxnikulin/linkremark Examples Link: --->8--- Link: Karl Voit: UOMF: Managing web bookmarks with Org Mode :PROPERTIES: :DATE_ADDED: [2020-12-25 18:06] :END: - Link URL :: [[https://karl-voit.at/2014/08/10/bookmarks-with-orgmode/]] - Link text :: Karl Voit: UOMF: Managing web bookmarks with Org Mode On the page - URL :: [[https://alphapapa.github.io/org-almanac/]] - title :: org-almanac - author :: Adam Porter - referrer :: [[https://www.google.com/]] ---8<--- Page: --->8--- public voit :PROPERTIES: :DATE_ADDED: [2020-12-25 18:11] :URL_IMAGE: http://Karl-Voit.at/images/public-voit_T_logo_200x200.png :END: - URL :: [[https://karl-voit.at/2014/08/10/bookmarks-with-orgmode/]] - title :: public voit - author :: Karl Voit - published_time :: 2014-08-10T17:13+01:00 - referrer :: [[https://alphapapa.github.io/org-almanac/]] #+begin_quote In my notes.org file, I collect all kind of snippets, knowledge, ideas, how-tos, and such stuff. #+end_quote ---8<--- It is not really ready for the wild web, though I believe it is already possible to get general impression and even use it for pages where specially crafted data are rather unlikely. Due to early development stage, there is no stability promise yet. The extension has not published to catalogues of browser extensions. Signed version for Firefox could be found in "releases" section on GitHub: https://github.com/maxnikulin/linkremark/releases/download/v0.1/linkremark-0.1-fx.xpi For chrome/chromium it could be loaded as unpacked extension. Just clone the code and create a symlink to =manifest-chrome.json= named =manifest.json=. =README.org= file contains a bit more details, so visit [[https://github.com/maxnikulin/linkremark]] or just clone this repository. The mail list is quite noisy last couple of months, so, please, do not post lengthy proposals how to integrate this extension to everything in response. The gift is crafted quite roughly, glue has not fully cured, so do not be surprised if you are stuck trying to adapt it for your habits. Merry Christmas and Happy New Year!
Re: [9.4] Fixing logbook visibility during isearch
Kévin Le Gouguec writes: > Ihor Radchenko writes: > >> My current plan is supporting the overlay-based approach even after >> merging the branch (by default). So, overlays should be around for a >> while and the issue with drawer visibility will be around as well, >> unless you fix it. I will probably work on this in distant future, but >> that's not the priority now. > > Mmm; is the current state of your branch representative of your plan? Not yet. That's rather a big change and I am currently generalising the core org-fold API to support both text properties and overlays. You can see WIP in org-fold-core.el from org-fold-universal-core branch. That branch is not usable yet. Best, Ihor
Re: [9.4] Fixing logbook visibility during isearch
Ihor Radchenko writes: > My current plan is supporting the overlay-based approach even after > merging the branch (by default). So, overlays should be around for a > while and the issue with drawer visibility will be around as well, > unless you fix it. I will probably work on this in distant future, but > that's not the priority now. Mmm; is the current state of your branch representative of your plan? If I compile it and run emacs -Q -L $yourbranch/lisp --eval '(setq org-startup-folded t)' $someorgfile Then isearching does not reveal logbook drawers unless matches are found inside, which as far as I am concerned fixes my issue with 9.4. >> I wonder if the path of least resistance couldn't be found in >> org-cycle-hide-drawers: right now this function just skips over drawers >> which are covered with an invisible overlay, but maybe it should not >> skip a drawer if the overlay starts before it (i.e. the overlay is not >> specific to this drawer but covers a whole containing section). > > That would defeat the purpose why the number of overlays was reduced in > Org 9.4. However, org-cycle-hide-drawers might be called in > isearch-open-invisible-temporary. Thanks for the tip.
