Say you have the following document:
* Level 1
Text here
** Level 1.1
Text here
* Level 2
Text here
Then the structure of Imenu will be:
Level 1 /
Level 1.1
Level 2
Thus you will be unable to jump to Level 1, because Imenu require to
specify the sublevel. Moreover, this doesn't play
Hi all,
there are occasions, v.g. when reading a gnus article, when I don't want
to store a link to the article itself (which is the behavior of C-c l)
but some link that is part of the article instead. I use to read rss
through gwene and many times I want to link the url for the full post,
while
) 'shr-url) -- url
I guess I can figure out how to write my own link handler now, but maybe
one generous soul between you has done it already and is eager to share
the result.
Cheers
--
Carlos
Carlos Pita carlosjosep...@gmail.com writes:
Hi all,
there are occasions, v.g. when reading a gnus
Hi all,
I would like to separate the items in my capture files by a number of
newlines, as in:
** item 1
content 1
** item 2
content 2
** item 3
content 3
instead of:
** item 1
content 1
** item 2
this to the number of lines the should be inserted
after the new item. Overrides :empty-lines for the
number of lines inserted after.
Cheers
--
Carlos
Carlos Pita carlosjosep...@gmail.com writes:
Hi all,
I would like to separate the items in my capture
Say I set org-cycle-separator-lines to 1. Now in an org buffer that has
nodes separated by one line, I do C-c C-j to open the org-goto
buffer. Then in the org-goto buffer:
1. Every node is suffixed by an ellipsis, even if the only content there
is an empty line.
2. Nodes are not separated by
Hi,
Nicolas: I see you point and I should have said baseline not bottom.
Many *inline* formulas are not quite like your examples though and
even when the glyphs have some descent they tend too look more
naturally (even if imperfectly) aligned at the bottom IMO.
Tobias: that's really nice,
> even when the glyphs have some descent they tend too look more
> naturally (even if imperfectly) aligned at the bottom IMO.
See the attached screenshots for an example of this with an ascent of
90 vs centered.
This was discussed here:
https://www.reddit.com/r/emacs/comments/9ggimh/bottom_align_latex_previews_in_org_mode/
Here is a screenshot:
https://i.redd.it/n83ri6campm11.png
For inline previews centering is clearly suboptimal, after all text in a
sentence is supposed to be bottom aligned.
Considering the above, do you still want me to write a patch for this?
Some options:
1. Add the above as a remark in the user guide or the wiki.
2. Add a variant of the dvipng backend, say dvipng-xcolor, as explained.
3. Remove the dvipng cli color code and (maybe just deprecate or ignore)
the
3. Or maybe you mean a region extension function that uses the parser to
find out the opposite delimiter of a block?
>
>
> I'd
> rather see work to integrate fontification with the parser.
>
I could take a look at this sometime in the next few months but I'm not
sure what do you mean. In particular:
1. Is the parser doing partial parsings of every inserted/removed character
or line in a more or less complete
Here is a patch. It removes quite a few LOC.
> I think option 3 is better. Is there any use case left for :use-xcolor?
Every other previewer has :use-xcolor t. I assume it's safe to simply
ignore :use-xcolor if it's there except that some user has configured
a converter that for some reason
This patch adds a fourth 'native value to
org-highlight-latex-and-related. It matches the same structures than
'latex but it calls org-src-font-lock-fontify-block instead.
It's a simple change that brings full latex fontification by building
on top of org-src. I'm using it (implemented as an
Hi Nicolas,
I was thinking that maybe it would be nicer to make this depend on the
value of org-src-fontify-natively. What do you think?
Regards
--
Carlos
Oh, I see there have been some changes in
org-compute-latex-and-related-regexp in a previous commit. Now it
seems to be working at least for some simple examples. I'm working in
a long and complex beamer document so I will be able to more seriously
test this during the next few days. Also, I'm
One problem I found after uninstalling my extension function is with
#+BEGIN/END blocks. For example, enable fontification for python,
elisp or whatever and write a long block like this:
#+BEGIN_XXX python
def xxx(x):
pass
def xxx(x):
pass
...
#+END_XXX python
Now scroll down to the
Hi Nicolas, thank you for letting me know.
I've been giving it a try but it doesn't really fix the main problem
AFAICS (I've just redefined org-do-latex-and-related as in [1], maybe
I'm missing something). It's not surprising because I don't think you
can work around it without installing a
Nicolas, I have modified org-fontify-meta-lines-and-blocks-1 following
your approach:
@@ -5991,6 +5991,13 @@ by a #."
(dc3 (downcase (match-string 3)))
end end1 quoting block-type)
(cond
+ ((and (match-end 4) (equal dc3 "+end"))
+ (save-match-data
+
Also, in the example above, when you change and restore the opening
clause, refontification doesn't happen immediately, you have to
somewhat move the point to retrigger fontification.
> #+END_XXX python
Just #+END_XXX, of course.
Here is a patch on top of latest revision. It just adds an extension
function while initializing font locking, as documented in [1]. It
indeed reduces lines of code to some extent by moving the dirty stuff
out of the fontification function (but I tried to keep the code
formatting of your last
>
>
> > Maybe you could rewrite my function in a better way using the
> > precomputed latex regexps and augmenting them with #+BEGIN/END
> > counterparts.
>
> Per above, I'm not really interested in writing yet another workaround
> for something that is going to fail anyway. For the time being, I
Hi,
I found out that there is already code doing what I proposed but just
when the backend is not dvipng.
If you want to keep using dvipng you can set:
(let ((dvipng (alist-get 'dvipng org-preview-latex-process-alist)))
(plist-put dvipng :image-converter '("dvipng -D %D -T tight -o %O %f"))
> Would you want to provide a patch for that?
Yes, sure, just give me a few days since I'm quite busy right know.
Are you ok with depending on xcolor by default or do you prefer a
customization option?
I would also like to elaborate on another aspect of this.
#+ATTR_xxx serves two purposes:
a. As a syntactical means of attaching extra information to
syntactically constrained elements (as tables or images). For this
purpose the _xxx part is irrelevant, only the affiliation to an
element
Hi Eric,
And this is where the challenge lies! The whole point of special blocks is
> that org knows nothing of their semantics. They are a "black box" and it
> would be difficult to identify export specific elements and general
> elements on this basis.
>
I partially agree with this just
Hi Nicolas,
fair enough if you feel it's not worth the hassle.
I'm pasting here a simple filter implementing the rule I described
above (use the special arg if present and if it doesn't conflict with
any ATTR directive for the current backend) for anyone interested, if
any at all:
(defun
Hi all,
I've been adding some improvements to the region extension function
(pasted below) in order to better support nesting, but anyway I'm
convinced that the current approach to org-highlight-latex-and-related
== '(latex) is hopeless except for small fragments and should be
reworked or dropped
> the extension function becomes helpful again: this because the
> #+BEGIN/#+END matcher is incremental and eventually the region to
Well, on a closer inspection it's not that incremental, it's just
ignoring the limit...
(defun org-fontify-meta-lines-and-blocks-1 (limit)
(when
Hi all!
The standard mapping from org structures to beamer structures
introduces boilerplate:
1. At the bare minimum a properties drawer.
2. Then there is the tag.
3. But above all the need to add an ignoreheading subsection (with its
drawer and everything) to introduce a little text between,
> > 1. Allow for special blocks to take an :options argument.
>
> Although I agree that this would be nice, I imagine the difficulty would be
> that it would be difficult to cater for multiple backends.
It's not really difficult, more on the trivial side. For example, as
an end user I already
Hi, I know this problem has been reported in the past ([1], [2]). The
second link provides a hint to a solution that I've developed
further. The underlying problem is (from dvipng man page):
-fg color_spec Choose foreground color for the images. This option will
be ignored if there is a
The quick and dirty option, if anyone wants it now:
(setq org-format-latex-header
(concat org-format-latex-header
"\\usepackage{xcolor}\n"
"\\definecolor{__bg__}{HTML}{1d1f21}\n"
"\\definecolor{__fg__}{HTML}{c5c8c6}\n"
Ok, I got the "#+BEGIN_LATEX latex" idea from reddit, but exploring
the source code I realized that the right thing to do here is to
"#+BEGIN_EXPORT latex" which makes more sense and is less redundant.
Now the problem still exists that "#+BEGIN_EXPORT latex" won't do
inline preview.
So, to sum
> > 1. #+BEGIN_LATEX could be changed to honor current fontification
> > setting
>
> This construct doesn't exist in Org.
Yes, I realized after posting, it was suggested in reddit but I was
unable to find any reference to it in the source code. Maybe it did
exist in the past since it's often
Please, add the ability to fontify code inside
#+BEGIN_LATEX
...
#+END_LATEX
blocks. Embedded LaTeX doesn't get native fontification and SRC
blocks aren't the place to just get fancy colors (besides, latex inline
preview doesn't work for them). Currently there is this trick:
#+BEGIN_LATEX latex
Indeed it would be nice to have preview working for SRC blocks with lang =
latex too.
One last suggestion. I see the latex export backend takes any BEGIN_XXX and
outputs a \begin{XXX} environment. That would be almost what I was asking
for when XXX = equation or displaymath or whatever. Except that in that
case the inline preview wont work (for BEGIN_LATEX it was working just
Hi Nicolas, thank you for your detailed answer!
To be honest I was wrapping my head around this until late tonight when it
all suddenly made sense and I more or less concluded the same you explained
about the role of each block and was going to say that you could indeed
dismiss this request.
> all fontification is lost for the entire environment and never reapplied
The problem is with the limit argument passed by the font locking
framework to org-do-latex-and-related .
Once you natively fontified the environment this limit arg became non
nil and it's in general not enough to match
Well, now I do have found a bug ;). It's related to the limit issue I
mentioned before. Indeed the problem with rehighlighting broken
environments and highlighting new environments also happens for basic
latex fontification when org-highlight-latex-and-related is set to
'(latex), it has nothing to
> (lambda (start end args)
> (org-src-font-lock-fontify-block "latex" start end
Or a safer version:
(lambda (start end prop face)
(when (eq face 'org-latex-and-related)
(org-src-font-lock-fontify-block "latex" start end)
Also note that
simple solution.
2. Then there is a feature request: add the ability to natively
fontify latex embedded fragments. I've also shown how to do that in a
couple of lines, but obviously some new customization option is also
required.
HIH
--
Carlos
On Wed, Nov 28, 2018 at 3:38 PM Carlos Pita wrote:
>
>
Hi Nicolas,
I've improved the commit message to better fit org mode conventions
and also added a note to ORG-NEWS about the new feature. Let me know
if there still is something I should change or feel free to amend it
to your liking.
One question for future patches: is it ok to add a link to the
I've improved the commit message to better align org mode conventions
and also added a note to ORG-NEWS about the new feature.
From 19d1d83901d3cc959b0cef5d2832da307e01 Mon Sep 17 00:00:00 2001
From: memeplex
Date: Wed, 2 Jan 2019 19:43:21 -0300
Subject: [PATCH] Add option to natively fontify
> (when (looking-at "[ \t]*#\\+BEGIN_\\S-+[ \t]+\\(\\S-+\\)")
Sorry, it obviously should have been \\(.+\\) at the end.
One thing the core parser could do is to put the remaining of the
opening line of a special block into an :args or similar property of
the special block element,
Hi all,
I've been having problems with latex font locking the first time the
internal font locking buffer is created (this with native latex
fontification). It was hard to debug but at a point it became obvious that
the culprit was yas minor mode, which I had globally enabled. I don't think
this
Also, they said there:
> I think you'll find that CommonHTML is faster at rendering the math
So:
1. Recommended for newer mathjax versions.
2. Fixed my problem with web fonts.
3. Faster.
It seems like a Pareto improvement to me.
Hi all,
the html exporter produces a div with id = name when the #+name property is
set for a special block. Since names are search targets they could be used
in links of the form [[name]]. Now this link will fail in the browser
because it will search for the internally generated id returned by
Or maybe the other way around:
#+noexport: mylist mytable ...
Then there is the question of what to do with src blocks, which have
their own, more complex, export control mechanism. What if both
#+noexport and :exports were set with non consistent values? Should
one forbid that possibility? Or
Hi all,
when using lists, tables and example blocks as inputs to babel src
blocks sometimes the inputs are just... inputs. There is some
inconsistency in the fact that src blocks can be selectively exported
but not their inputs. Commenting these inputs out makes them invisible
to the block
Or maybe a keyword, similar to #+name. For instance:
#+export: no
#+name: mylist
- item 1
- item 2
Hi all,
I often wonder if the way org-directory is currently used has any
sense or is just a historical artifact.
I mean, when I list my refile targets and agenda files I have to
specify full paths, which isn't very convenient. But if instead of a
list I provide a file listing the paths, then
Today I noticed the export templates inserted by org are still uppercase:
#+LATEX_CLASS: article
#+LATEX_CLASS_OPTIONS:
#+LATEX_HEADER:
#+LATEX_HEADER_EXTRA:
#+DESCRIPTION:
#+KEYWORDS:
#+SUBTITLE:
#+LATEX_COMPILER: pdflatex
#+DATE: \today
Is this intentional, is the lowercase convention intended
Great, thanks!
This avoids lines with just a closing "}", which look rather ugly.
Quite similar to my previous patch for fast tag selection.
Regards
--
Carlos
From 239e0d036da94b2a950db3ad1f7e82c5ca6d8daa Mon Sep 17 00:00:00 2001
From: memeplex
Date: Thu, 21 Feb 2019 01:09:29 -0300
Subject: [PATCH] Fix fast
Here is a patch inverting (1) and (2) above.
From 9c97eebb6c26332415fb03c65e872d304576fe07 Mon Sep 17 00:00:00 2001
From: memeplex
Date: Thu, 21 Feb 2019 16:09:58 -0300
Subject: [PATCH] org-agenda: improve todo states completion
* lisp/org-agenda.el (org-todo-list): prepare agenda buffers before
Hi all,
M-x org-agenda T prompts for a todo keyword. But it builds the
completion list while preparing the agenda buffers and this is done
*after* prompting. So the first time no completion is presented, the
second time completions from previous invocation of
org-agenda-prepare-buffers are
It doesn't seem to be any relevant computational penalty:
(when (equal arg '(4))
(setq org-select-this-todo-keyword
(completing-read "Keyword (or KWD1|K2D2|...): "
(mapcar #'list kwds) nil nil)))
< (1)
(and (equal 0 arg) (setq
> Applied, with some refactoring. Please double check I didn't fumble it.
I looked at the code and tested it a bit and seems to be ok. Thanks!
Hi all,
here is a simple patch to avoid showing ugly trailing colons in custom
agenda commands when no matcher was specified (for example, in the
case of alltodo).
Best regards
--
Carlos
From 4125d3ff9e4f26c3346b847288cad3e69a38da23 Mon Sep 17 00:00:00 2001
From: memeplex
Date: Fri, 22 Feb 2019
Hi all,
just what the subject says. It seems an important feature to me but
I'm unable to find any reference to it in
https://orgmode.org/manual/Macro-replacement.html.
Best regards
--
Carlos
Hi all,
despite the new lower case convention the #+results directive auto
generated after evaluation of babel blocks is still upper case.
Best regards
--
Carlos
> just what the subject says. It seems an important feature to me but
> I'm unable to find any reference to it in
> https://orgmode.org/manual/Macro-replacement.html.
>
Strangely I do find it here:
https://orgmode.org/manual/Macro-Replacement.html#Macro-Replacement
The only difference being
Hi all,
is it possible to get a tag completion list that includes both:
1. Tags specified with org-tag-alist or #+tags
2. Tags dynamically parsed from the current buffer
?
It seems that 1 always overrides 2, but there are legitimate cases to
prefer the union of 1 and 2. Namely, you might want
I now notice that this is possible in case you have defined shortcut
keys for the default tags and, thus, the fast selection menu opens.
But it doesn't seem to be possible otherwise. Is this right?
Hi all,
here is a patch removing an extra space that is left when one selects
an empty state from the completing read interface. I simply replaced a
check for non-null with a check for org-string-nw-p in org-todo.
Best regards
--
Carlos
From 9f137a50e1f18e067b4b9ca8836993b212d93093 Mon Sep 17
Hi all,
there is a problem in this kind of logic:
(cond ((not ta) +1)
((not tb) -1)
((string-lessp ta tb) -1)
((string-lessp tb ta) +1
in that when both ta and tb are nil then they are arbitrarily sorted.
Since the agenda sorting strategy is lexicographic this logic
Hi all,
I was having some problems with the mathjax HTML-CSS backend and I
found out that the CHTML backend is currently the preferred one. See
details at https://github.com/mathjax/MathJax/issues/2132 and
http://docs.mathjax.org/en/latest/output.html. Changing the backend to
CHTML fixed my
TL;DR about the specific problem I was having with HTML-CSS:
> both HTML-CSS and CommonHTML use web fonts. But CommonHTML doesn't try to
> detect their presence, while HTML-CSS does, and it is that detection that is
> probably going wrong for some reason (I did say it was fragile). HTML-CSS
>
> Here are two previous threads about the subject:
>
> Last month:
> http://lists.gnu.org/archive/html/emacs-orgmode/2019-01/msg00349.html
> A year ago:
> http://lists.gnu.org/archive/html/emacs-orgmode/2018-01/msg00425.html
Interesting, thanks! Although the issue of mostly uppercase external
Hi all,
I noticed that the default expansions for org-tempo in 9.2 are
lowercase. I think they followed the uppercase informal convention
before, didn't they? Is this implying that now lowercase is preferred?
Regards
--
Carlos
> At first I didn't like the lowercase tags for the blocks, but I got used to
> them after a couple of days.
I prefer the lowercase convention hands down. The problem I pointed
out is with the uppercase legacy.
> Someone suggested adding a defcustom option to org-tempo to let the user
> choose
> before, didn't they? Is this implying that now lowercase is preferred?
I dug this up from the repo:
org-element: Prefer lower case letters for blocks and keywords
https://code.orgmode.org/bzg/org-mode/commit/13424336a6f30c50952d291e7a82906c1210daf0
So the answer is yes. Also the
> What do you mean with the "uppercase legacy"? You mean all the current
> documents we already have?
Specifically what motivated this post: collections of snippets that
have been written with the historical convention in mind. It's easy to
convert them but it's not that easy to convert users
For example, with:
#+tags: { @casa(c) @oficina(o) @viaje(v) @gimnasio(g) @xxx(x) }
I get:
{ [c] @casa [o] @oficina[v] @viaje [g] @gimnasio
[x] @xxx}
where [c] and [x] are clearly misaligned.
If I remove the last tag:
#+tags: { @casa(c) @oficina(o) @viaje(v)
Ok, this was easier than I initially thought.
Here is a patch. I've tested it with a number of configurations: a few
grouped tags, many grouped tags, grouped tags that fill the last line
entirely, grouped and ungrouped tags. Notice that even ungrouped tags
are indented by two spaces. This is done
Not a big deal, but here is a slightly better fix that avoids adding
some spaces before the closing }.
The difference wrt to the previous one is just:
- (unless (memq (caar tbl) '(:endgroup :endgrouptag)) (insert "\n"))
- (when (or ingroup intaggroup) (insert " "))
+
What about leaving everything as it is now and adding C-c C-x C-S-l to mean
"force preview", of course with the C-u and C-u C-u variants. This is a bit
more orthogonal in the sense that the numerical argument controls scope and
the S modifier controls "forcing". Also, it's backwards compatible
> `C-c C-x C-S-l` is too ugly, even for me. It is a convention we don't
> use in Org.
Mmm ok :).
I proposed it because it is easy to remember if you think you're
modifying a base action by S and also because it's easier to keep C
pressed (versus simply S-l or M-l).
So lets play with minus as a
Hi,
> #+HEADER: :file latex.svg
> #+HEADER: :results drawer
> #+BEGIN_SRC latex
I think you're missing some headers to get it working. For example, I
use the following defaults to preview/export images generated with
tikz to html/markdown documents:
Also, make sure imagemagick is installed.
Btw, you might find this useful for previewing babel-generated images:
(defun my-org-babel-redisplay-images ()
(when org-inline-image-overlays
(org-redisplay-inline-images)))
(add-hook 'org-babel-after-execute-hook
> WDYT?
I like it. Indeed, I was tempted to suggest removing document scope
but, as an end user, I moderate my proposals to be more or less
conservative.
There are some complications though. If we remove the document scope
bindings we have to refactor the current function quite a bit, because
Ok, let's make this more concrete so I can start working on it then.
Alternative A:
Provide three functions:
org-toggle-latex-fragment:
bound to C-c C-x C-l
has an optional argument arg
delegates to org-preview-latex-section if necessary (outside of
fragment or C-u)
> Please let me know if anything went wrong.
I think your refactor improves the original code a lot and makes clear
that toggling is just a special case.
I've been testing the changes with a pretty complex beamer document
and found no fault.
Thanks!
Nicolas, here is a patch implementing alternative B above with
ORG-NEWS entry and everything.
I have been playing with it and find the bindings quite handy.
Code is indeed a bit simpler.
If you like it, feel free to amend it before merging.
Best regards
--
Carlos
From
> C-c C-x C-l: as you defined it
> C-u C-c C-x C-l: preview document scope.
> C-- (or C-0) C-c C-x C-l: as you defined C-u C-c C-x C-l.
> C-- (or C-0) C-u C-c C-x C-l: unpreview document scope.
Btw, I don't think that "preview the entire document" is such a rare
use case. Consider that you've
According to the docstring:
```
(defun org-toggle-latex-fragment ( arg)
"Preview the LaTeX fragment at point, or all locally or globally.
If the cursor is on a LaTeX fragment, create the image and overlay
it over the source code, if there is none. Remove it otherwise.
**If there is no
A last suggestion. Incidentally the toggle returns nil when at least a
fragment is unpreviewed and non-nil otherwise (as a side effect of
message). This can be documented and made part of the interface, so
that something like the following can be put together by the end user:
(defun
> the current section. Now, there is C-u C-u C-c C-x C-l for that. AFAICS,
Sorry I meant just one C-u.
C-u C-u is to clear the entire buffer of previews.
> I suggest to make C-c C-x C-l a toggle with preference for previewing,
> that is: preview everything except when everything is already previewed.
Mmmm I think this is not easy since it would imply changing
org-remove-latex-fragment-image-overlay return value:
(if
heir
> export.
>
> Browse the commentary in org-inlinetask.el for more details.
>
> HTH,
>
> Chuck
>
>
> > On Mar 23, 2019, at 2:20 PM, Carlos Pita
> wrote:
> >
> > Hi all,
> >
> > when using lists, tables and example blocks as inputs to babel
Hi Greg,
> fwiw, using
>
> : emacs -Q -L ~/.emacs.d/straight/build/org foo.org
It's exactly the same. To be more precise, this is what I did:
1. open -na emacs --args -Q -L ~/.emacs.d/straight/build/org foo.org
2. C-x C-f /tmp/test.org (a new file)
3. Type "* heading" in the first line
4.
Hi,
when I try to autocomplete a heading inside a link I get:
completion--some: Args out of range: #("*hea" 0 1 (fontified t
help-echo "LINK: *head" htmlize-link (:uri "*head") rear-nonsticky
(mouse-face highlight keymap invisible intangible help-echo
org-linked-text
Hi all,
I find the instructions about bug reporting in [1] lacking a heads-up
that subscription to the mailing list is a (soft?) prerequisite. It's
true that it links to [2] which states:
You can subscribe to the list from this web page. If you are not a
member of the mailing list, your
Hi,
in https://list.orgmode.org/87tuuw3n15@nicolasgoaziou.fr/#t it's stated:
> Org is standardized on lower case. Uppercase is used in the manual as
> a poor man's bold, and supported for historical reasons.
But C-c C-x p still inserts stuff like:
:PROPERTIES:
:ARCHIVE: ...
:END:
Hi Igor,
I believe the problem is in:
(defun pcomplete/org-mode/searchhead ()
...
;; When completing a bracketed link, i.e., "[[*", argument
;; starts at the star, so remove this character.
(substring pcomplete-stub 1 <-- trailing ]] not removed!
>
> !Changing the last line to (substring pcomplete-stub 1 -2) fixes it in my
> example. I don't know if one is supposed to do [[*prefix]] or
> [[*prefix as is implied by the code, but better to support both,
> specially considering electric pairs, don't you think?
>
Indeed, the right limit
Hi Ihor,
> > Maybe I'm not getting how this is supposed to work, but it makes no
> > sense to me.
>
> M-x org-reveal (C-c C-r)
Thanks for the tip, I didn't know about this and it indeed seems
useful in order to avoid unfolding everything else.
That said, my report was about the expansion of:
Hi Ihor,
> Can you elaborate? If the docstring is not clear enough, we can easily
> improve it.
Consider for example:
minimal show current headline; if point is not on headline, also
show entry
So if you have:
* a
* b
** b1
** b2
** b3
* c
I see no reason why a match inside b2 will
1 - 100 of 122 matches
Mail list logo
