Maxim Nikulin writes:
> There are cm-super fonts for at least of 15 years.
There are many tradeoffs in many aspects. No single font pleases
everyone. So you want to say: Your requirements are more
important/common/stylish/whatever that the requirements of other
people?
I do need only latin
Applied.
This seems quite simple, so I've taken the liberty of applying the
patch. Please don't hesitate to revert it if something seems off.
--
Timothy writes:
> Hello,
>
> It's come to my attention that the current value of
> org-cite-ctl--etc-dir is problematic for anyone managing Org
I have been unable to get the :match feature of columnview dblocks to work.
I need it because I want to filter headlines by tags that I used to
identify Scrum stories in a particular sprint. I have basically tried every
conceivable version of :match such as :match "Sprint4", :match "Sprint4",
To reproduce, create a test file as follows:
* A
link to [[*B][B]]
* B
Put cursor on heading A
C-c C-e (org-export-dispatch)
C-s so Export scope is set to Subtree
t (export to plain text)
A (as ascii buffer)
I see error
user-error: Unable to resolve link: "*B"
Emacs : GNU Emacs 28.0.50
On 14/07/2021 13:44, Stefan Nobis wrote:
The main point: utf8x and the associated package ucs are not
maintained for quite some time (utf8x seems to be last changed in
2004) and as far as I understand have always been more of a workaround
than a solution. But I'm not an expert in this regard.
Maxim Nikulin writes:
> It perfectly suits for e.g. a book when camera ready variant is
> required. For routine notes it is better to keep from defaults as
> minimal as possible to minimize problems that may arise a decade
> later. I would prefer to avoid Linux Libertine if I am going to send
>
Hi
I am not sure whether this is slightly off topic, but sometimes orgmode
works better with long lines (auto-fill-mode off), so many users
recommended visual-line-mode.
I am not entirely convinced by this mode and now came across
virtual-auto-fill-mode
that looks to me a much nicer
Hi,
Uwe wrote:
> I am not entirely convinced by this mode and now came across
> virtual-auto-fill-mode that looks to me a much nicer solution.
> Any comments?
I haven't tried virtual-a-f-m myself, so I cannot say if it is
the ultimate solution. However, I have tried visual-fill-column-
mode
Hi all, I could use a bit of help with a regexp. I am trying to fine tune
the org-ref citation regexp to make it orthogonal to org-cite.
I want to recognize these as org-ref links
[[cite:schuett-2018-schnet]]
cite:schuett-2018-schnet
but not
[cite:@schuett-2018-schnet]
so either 0 or 2 [[
Stefan Nobis writes:
> Maybe. I'm currently myself struggling a little bit with a flexible
> configuration, that can be used with many different kind of documents
> (short notes, larger reports, beamer presentations) and provides all
> the extras I like to use. There is no clear best package
Attached is a very small update to the docs about how to refer to tables in
other files. Probably there's something wrong with the formatting, but git
send-email didn't work, and I hope the Changelog entry gets through.
Why the Nu HTML Checker line got included I don't know ... some
Hi,
I've just started playing with citations, but it seems that I've
stumbled across a bug where if the citation is in a table cell it will
be left "raw". See the following example
#+begin_org
,#+begin_src bibtex :tangle activedoc.bib
@article{SchulteActiveOrg,
author={Schulte, Eric and
Hi John,
John Kitchin writes:
> Hi all, I could use a bit of help with a regexp. I am trying to fine tune
> the org-ref citation regexp to make it orthogonal to org-cite.
>
> I want to recognize these as org-ref links
>
> [[cite:schuett-2018-schnet]]
>cite:schuett-2018-schnet
>
> but not
Maxim Nikulin writes:
[utf8x]
> Maybe, I have seen such warnings. However I have tested neither utf8
> nor utf8x on real examples. That is why I am unaware what can be
> broken in particular. For small examples with various symbols
> outside of ASCII, utf8x may give better support.
The main
John Kitchin writes:
> #+RESULTS: foo
> :results:
> \[\displaystyle{\sin\left(\frac{a}{b}\right)}\]
> :end:
>
> the key is the drawer I think.
FYI as of
https://code.orgmode.org/bzg/org-mode/commit/b90b850ae8be46a1ebe7d13b05ad79869e8d1032
a LaTeX environment will "just work". i.e.
#+RESULTS:
"Raw" LaTeX code export to ODT always worked if =tex= (and possibly
=org-latex-to-mathml-convert-command=) were correctly set.
The problem is that "raw" output is no longer recognized as the
function result. If the function is reran, the result will be output
twice : once by the function
Rodrigo Morales writes:
> I've created the following patch which adds a defcustom that would allow
> the user to decide whether drawers must be hidden or shown in text
> entries. Hope this helps.
It is worth mentioning that another reason for considering this patch is
the fact that
17 matches
Mail list logo
