Timothy writes:
> ⁃ Elements
> • Greater Elements
> • (other) Elements
>
> to
>
> ⁃ Elements
> • Greater Elements
> • Lesser Elements
This sounds reasonable. We can change
- Three categories are used to classify these environments: “Greater
elements”, “elements”, and “objects”, from
Marcin Borkowski writes:
> 2. We modify Emacs itself to somehow highlight the ZWS. There is (kind
> of) a precedent – a no-breaking space is already fontified with
> =nobreak-space= face. At the very least, make whitespace-mode somehow
> show ZWSs (which it doesn't now, and I'd probably say
Hi Ihor,
Because your reply is shorter, you get my first response .
>> [Renaming parts of the Hierarchy]
> I am against renaming this. We should rather improve the syntax document
> keeping the key concepts consistent with Elisp code.
This is certainly something to be conservative about, but I
Hi,
Thank you for having a look.
Tim Cross writes:
This also seems like an edge case and I'm not convinced yet another
option is justified. Why have eilisp in org blocks rather than an
emacs-lisp block?
By org src blocks I meant an org emacs-lisp src block. The point of
the patch is to be
On 2021-12-03, at 13:48, Juan Manuel Macías wrote:
> Hi all,
>
> It is usually recommended, as you know, to insert a zero width space
> character (Unicode U+200B) as a sort of delimiter mark to solve the
> scenarios of emphasis within a word (for example, =/meta/literature=)
> and others
Timothy writes:
> So, the hierarchy appears to be something like.
>
> 1. (Headline / Section / Greater Element / Element / Object)
> 2. Headline
> 3. Section
> 4. Greater Element
> 5. (Greater Element / Element)
> 6. Element
> 7. Object
> 8. Pattern / Form
> 9. Term
> We could say call (1)
Hi,
I noticed that make test became extremely slow recently.
The first bottleneck can be seen in
make BTEST_RE="^test-org-cite/adjust-note" test
passed 1/1 test-org-cite/adjust-note (12.321278 sec)
The test takes 12sec!
Moreover, subsequent tests (even not related to org-cite) become slower,
Tom Gillespie writes:
> I don't mean to be dismissive of the suggestion, but a lot of
> time is spent on this list walking back ideas that have not
> had sufficient time put into understanding what the
> unintended consequences would be, so I wouldn't say
> that it is irresponsible, I would say
Hi Timothy,
Replies in line. Some things might seem a bit out of order
because I responded from bottom to top. Best,
Tom
> from heading to bed, so to quote Pascal "I have only made this letter
> longer because I have not had the time to make it shorter".
Likewise, and I've heard it as Mark
If I run org-tree-to-indirect-buffer twice with a prefix argument, I get a
buffer that's too narrow and omits the text of the last heading in the
tree. In this state, tree operations can result in data loss.
To reproduce, open a file containing the following data:
* I
** A
** B
* II
Follow
An important note: for intra-word markup you probably want to
use word joiner U+2060 and not zero width space, because a
zero width space allows layout to break the word, whereas a
word joiner does not. We may need to check to make sure that
U+2060 counts as whitespace for the purposes of markup.
Michael Dauer writes:
> Where are the links/href are built? There should be the error that excludes
> inline-tasks.
A quick search through the code yields: org-export-resolve-id-link
It explicitly check headlines, but not inlinetasks.
The fix should not be too hard. Feel free to send a patch ;)
hi, Tim,
> The key question is what is the use case for having this 'mixed' content
> in a table cell?
in my case, i am putting RFC822('ish) e-mail addresses in a column of an
org-mode table. and, i want to extract them.
| oxymo...@example.com |
| Greg Oxymoron |
Tim Cross writes:
> I think I am in agreement regarding most of your points about the use of
> the zero-width character. I see it as a type of escape hatch which
> provides a solution in some less frequent situations. It is a somewhat
> clever kludge to enable markup in some situations not
Tom Gillespie writes:
> I don't mean to be a wet blanket, but the edge cases for
> the current markup syntax are already hard enough to
> implement correctly, to the point where different parts of
> Org mode are inconsistent. Intra-word markup isn't viable
> because there simply isn't any sane
Greg Minshall writes:
> fwiw, tracing, the problem appears to be this line
>
> ((eq (string-to-char cell) ?\") (read cell))
>
> in =org-babel-read=.
>
> presumably there are many cases where this is the right thing to do.
>
> but, maybe look for a simple =^"[^"]*"$= (i.e., a
Sébastien Miquel writes:
> Hi,
>
> The attached patch adds a new option ~org-src-native-defun-movements~
> that makes ~beginning-of-defun~, ~end-of-defun~ and ~eval-defun~ work
> natively when called from inside an org src block : those functions
> are called from an org src edit buffer, in
Juan Manuel Macías writes:
> Hi all,
>
> It is usually recommended, as you know, to insert a zero width space
> character (Unicode U+200B) as a sort of delimiter mark to solve the
> scenarios of emphasis within a word (for example, =/meta/literature=)
> and others contexts where emphasis marks
Hi all,
I use PlantUML integration in org-mode for years now, but only
recently I came across some unwanted behavior.
Using PlantUML from jar (org-plantuml-jar-path variable) and latest
org-mode, I wanted to render a diagram containing some Unicode
characters (such as '⊥' and '∀'), but the
Hi Greg, thank you for your comment,
Greg Minshall writes:
> in fact, i am always queasy when i enter ZWNBSP in a .org (or any other)
> file. some sort of "visible" sequence would be great. backwards
> compatibility might be a problem.
Yes I agree. I think that in this case, a new mark would
Juan Manuel,
> however, I find it problematic that this character is part, more or
> less de facto, of the Org syntax. For two main reasons:
in fact, i am always queasy when i enter ZWNBSP in a .org (or any other)
file. some sort of "visible" sequence would be great. backwards
compatibility
Hi,
The attached patch adds a new option ~org-src-native-defun-movements~
that makes ~beginning-of-defun~, ~end-of-defun~ and ~eval-defun~ work
natively when called from inside an org src block : those functions
are called from an org src edit buffer, in the appropriate language
mode. Without
fwiw, tracing, the problem appears to be this line
((eq (string-to-char cell) ?\") (read cell))
in =org-babel-read=.
presumably there are many cases where this is the right thing to do.
but, maybe look for a simple =^"[^"]*"$= (i.e., a quotation mark, some
other stuff, a quotation
hi. i'm trying to use =org-babel-ref-resolve= to access the values of a
column in a table. it all works fine for many cases. however, if the
contents of an entry in the column starts with quotation marks, those
quotation marks disappear, and anything outside the quoted part of the
cell
Le 03/12/2021 à 16:24, John Kitchin a écrit : > I have seen this happen at
times, and I think it is style and maybe > browser dependent. > > Could you
send me a small example (including the csl file you use) that > I could look
at? Dear John, In attachment, two small examples, the same text
I have seen this happen at times, and I think it is style and maybe
browser dependent.
Could you send me a small example (including the csl file you use) that
I could look at?
Joseph Vidal-Rosset writes:
> Hi John,
>
> A detail about exporting with org-ref 3 in html when the csl style is
>
Hi Maxim,
Max Nikulin writes:
> More explicit markup leaves less room for ambiguities, and I like the
> idea due to this reason. On the other hand it diverges from principle
> of lightweight markup. The almost only special character in TeX is
> "\", HTML has three ones "&<>" with simple escape
On 03/12/2021 01:11, Tom Gillespie wrote:
I recommend anyone suggesting solutions try to implement
something that can parse the markup unambiguously with
lots of nasty test cases. You will likely find that it is impossible
to consistently tokenize markup, and that you have to hand
write a whole
On 03/12/2021 02:03, Nicolas Goaziou wrote:
Denis Maier writes:
As for suggestions: If just using /intra/word creates ambiguities, what
about the asciidoc solution? So //intra//word?
I sympathize to the idea of intra-word emphasis, but the syntax above is
going to cause some ambiguous
Ihor, thank you for the quick workaround.
Unfortunately storing links is not much of an issue for me. The real issue
is how I can get the internal links working in the exported html.
I could not find the right places to deactivate and
re-activate inline-tasks during export.
I have a custom
Hi all,
It is usually recommended, as you know, to insert a zero width space
character (Unicode U+200B) as a sort of delimiter mark to solve the
scenarios of emphasis within a word (for example, =/meta/literature=)
and others contexts where emphasis marks are not recognized (for example
Jan Ulrich Hasecke writes:
> There are some more issues. Startup time of my emacs is more than 30
> seconds even after optimizing something with esup. I have 10.000+ files
> in my org-roam and fear that I hit some limitation either of org-roam or
> my hardware.
I use use-package with the
On 03/12/2021 11:36, Ihor Radchenko wrote:
Max Nikulin writes:
Unfortunately currently it fails in Emacs-26.3 event without "#+startup:
indent":
Warning (org-element-cache): org-element--cache: Unregistered buffer
modifications detected. Resetting.
If this warning appears regularly, please
Michael Dauer writes:
> Before (require 'org-inlinetask) all is fine. But after executing (require
> 'org-inlinetask) the following happens:
> 1. With point on/in t1 (org-store-link) stores *h2.
> 2. The manually created link below h1 works in the buffer. But it is
> exported as BROKEN LINK.
Hi all,
Am Thu, Dec 02, 2021 at 09:12:38AM +1100 schrieb Tim Cross:
> I really like the use-package library. It can make your init.el file
> much cleaner and you can setup things so that the only thing you need to
> backup is your init.el file. Whenever you want to do a clean install
> with all
Is there a setting that excludes inline-tasks from internal links?
I actually want to link to inline-tasks. BUT:
emacs -Q
>>>
* h1
[[*t1][t1]]
* h2
*** TODO t1
*** END
(require 'org-inlinetask)
<<<
Before (require 'org-inlinetask) all is fine. But after executing
Hi John,
A detail about exporting with org-ref 3 in html when the csl style is
for numeric references. With org-ref 2 + citeproc-org, I got this:
[1] R. Descartes, Meditations on First Philosophy: with Selections from
the Objections and Replies. Oxford: OUP Oxford, 2008.
(see the references
37 matches
Mail list logo
