Sébastien Miquel,
thanks for the reply.
> > it's long-term emacs behavior to eliminate spaces
> > at the end of lines, at least in programming modes.
(Tim -- i guess i should have said, "it's my long-term experience with
emacs...".)
> As for the `org-src--content-indentation' spaces, they are
Greg Minshall writes:
> hi, Sebastien,
>
> thanks for the reply. i remember that thread, but obviously i wasn't
> paying enough attention.
>
>> The downside is that, unless ~org-src--preserve-indentation~ is `t`,
>> when editing a src block, every empty line will be indented with
>> spaces
--text follows this line--
Info node "(org) Built-in Table Editor"
says:
> ‘M-’ (‘org-table-wrap-region’)
> Split the current field at point position and move the rest to the
> line below. If there is an active region, and both point and mark
> are in the same column, the text
For the record, the original issue is that with
`org-src-tab-acts-natively' set
to t (which is the new default) you couldn't use tab to indent an empty
line, and
electric-indent-mode wouldn't work properly.
Greg Minshall writes:
i don't know what
would be involved to keep the fix for the
Juan Manuel--
Thanks. I understand no pages in a web document; I thought (hoped?) that
section/subsection numbers, perhaps multiple, would appear next to the
entries in the index. I will try to be more specific with the ! syntax
Any advice for how to get *both* theindex.html and my main
>>> "JK" == John Kitchin writes:
> I would see if you can open a jupyter notebook and start a notebook with
> the mat lab kernel. If not, it either isn’t installed, or maybe is
> installed in a different jupyter.
> If you get errors here, the issue is outside of org mode. For example, the
>
hi, Sebastien,
thanks for the reply. i remember that thread, but obviously i wasn't
paying enough attention.
> The downside is that, unless ~org-src--preserve-indentation~ is `t`,
> when editing a src block, every empty line will be indented with
> spaces (according to
Uwe Brauer writes:
>> Uwe Brauer writes:
>
>
>> I'm not very familiar with calc, but am wondering if the issue is the
>> 'nan'. In many languages, a nan is a 'polluting' variable i.e. once you
>> have a nan as a form anywhere in your calculation, the result will
>> always be a nan. Many
Hello,
András Simonyi writes:
>> - As suggested by Bruce D'Arcus, we might move `org-cite-get-boundaries'
>> in `oc.el' proper, since it is also used elsewhere (at least in
>> "oc-basic.el").
>
> sure, it makes more sense there, especially because I took the
> fragment from your code IIRC
Ihor Radchenko writes:
> Oops. Forgot to rebase the patch to current master. The correct version
> is attached.
Thanks for the fix!
I need to make below additional change, otherwise it works perfectly. I
can't reproduce the original issue any more.
Looking at the changes, I see you changed
On Tue., Jun. 22, 2021, 4:30 a.m. Richard Lawrence, <
richard.lawre...@uni-tuebingen.de> wrote:
> Hi Matt,
>
> Matt Price writes:
>
> >> I would like to be able to surround some portion of a subtree with a
> tag,
> >> e.g.:
> >>
> >> * parent
> >> some text
> >> #+HTML:
> >> ** child 2
> >>
William Xu writes:
> On which commit is the patch based? When I try to apply it, somehow I
> get failures:
Oops. Forgot to rebase the patch to current master. The correct version
is attached.
Best,
Ihor
>From 924375994e110ba06ea6ed3fa9aa1ecab9380d5b Mon Sep 17 00:00:00 2001
Message-Id:
Ihor Radchenko writes:
> William Xu writes:
>> Thanks. At least not something weird in my emacs config. :)
>>
>> I think your patch is ready to be merged into orgMode. Hopefully it can be
>> merged soon.
>
> I believe that I managed to fix the problem you observe, though I do not
> understand
Hello,
thank you very much! Update to 27 solved the problem.
All the best,
Michael
Am 22.06.2021 um 15:33 schrieb Sébastien Miquel:
Hi,
This has been reported before.
There's a patch that fixes this here :
https://lists.gnu.org/archive/html/emacs-orgmode/2021-06/msg7.html
To fix
Hi Greg,
Greg Minshall writes:
hi. i can't date it exactly, but in the last week or so, editing a
source buffer (with =C-c '=) adds spaces (to the "tab location") of
previously blank lines.
See https://lists.gnu.org/archive/html/emacs-orgmode/2021-05/msg00867.html
The goal of the change was
Hi,
This has been reported before.
There's a patch that fixes this here :
https://lists.gnu.org/archive/html/emacs-orgmode/2021-06/msg7.html
To fix this bug, you can can either apply this patch, downgrade org, or
update emacs to 27.
Could anyone with commit access have a look and
Neither do I (concerning the special fontification).
Nevertheless, if you look at the profiler report (1st mail), the
fontification process differ from the usual one (see attached screenshot)
*because* the proof is considered as a block by org-mode.
[image: image.png]
Best,
Le mar. 22 juin 2021
On Tuesday, 22 Jun 2021 at 14:32, Léo Ackermann wrote:
> Do you see what I mean ?
I do but I guess I must have a differently configured system as I do not
see any special fortification due to being in a special block.
However, I see nothing in my configuration that affects special blocks.
--
:
Hi Rémy,
Thanks for bringing this up. This reminds me that we want to get the
French/Japanese translations fleshed out...
All the best,
*Timothy*
> I am not sure what you are asking. What specific treatment are you
referring to?
I suggest that special block in LateX export (
https://orgmode.org/manual/Special-blocks-in-LaTeX-export.html) may be
treated differently. Once again, I'm new to org-mode, but here is my
intuition:
- What is
web...@toryanderson.com (Tory S. Anderson) writes:
> Steps to reproduce:
>
> 1. load emacs with the use-package declaration below
> 2. visit =M-x org-agendaa3. Clock in to the "Parent" item on the agenda
> by highlighting it and doing =C-c C-x-- thread will freeze
> indefinitely, although in
On Tuesday, 22 Jun 2021 at 13:20, Léo Ackermann wrote:
> I am new to org-mode but, is there a reason why #+BEGIN_proof #+END_proof
> and other org-latex-special-block are treated as block ?
I am not sure what you are asking. What specific treatment are you
referring to?
--
: Eric S Fraga via
Hello,
org-edit-src-exit suddenly completely destroys my code after coming back
from vacation. No known recent changes in configuration. Very strange
error!
EXAMPLE: here a simple code before editing
#+BEGIN_SRC R
mtcars
sum(mtcars$mpg, na.rm = TRUE)
mean(mtcars$disp)
#+END_SRC
I enter
hi. i can't date it exactly, but in the last week or so, editing a
source buffer (with =C-c '=) adds spaces (to the "tab location") of
previously blank lines.
i.e., the second line in each of the following source blocks is empty,
but if i =C-c '= then =C-c '=, each will end up with a few spaces
Hi all,
Many thanks for those advices!
I am new to org-mode but, is there a reason why #+BEGIN_proof #+END_proof
and other org-latex-special-block are treated as block ?
I mean; those #+... aim, as far as I understand, to give tips to org-export
for prettier exports but nothing else (between
Hello,
Illia Ostapyshyn writes:
> When exporting asynchronously with an essentially empty
> org-export-async-init-file, the
> process fails with this backtrace:
>
> Debugger entered--Lisp error: (invalid-read-syntax "#" 1 0)
> read(#)
>
>
Hi,
I'd like to propose a new universal argument functionality for
org-babel-mark-block: it should mark the block content (as without
universal argument) and the whole block definition as well.
Current behavior with and without universal argument:
#+NAME: my-example
#+BEGIN_SRC python
Dear Org,
Theres a broken link on the french homepage. The « Installation » link goes
to https://orgmode.org/fr/install.html and probably should go to
https://orgmode.org/install.html...
Not critical but easy to fix ;-)
Best,
Rémy
Hi Léo,
I think I can actually speak a bit on this. As it stands, babel fontification
operates by:
- sending the src block to a dedicated buffer
- turning on the relevant major mode for the language
- forcing font-lock of the entire buffer
- cloning the font-lock information for the entire buffer
Am 21.06.2021 um 10:45 schrieb Nicolas Goaziou:
Hello,
Denis Maier writes:
Using a space for this is perhaps too subtle as you say. Also, the
question is which one should be the default. I'd actually suggest to
turn it around:
"A quotation ending without punctuation"[cite:
When exporting asynchronously with an essentially empty
org-export-async-init-file, the
process fails with this backtrace:
Debugger entered--Lisp error: (invalid-read-syntax "#" 1 0)
read(#)
load-with-code-conversion("/var/folders/1q/6syg63894h5bqlwp2jdh8r44gn/T/o..."
>>> "t" == tbanelwebmin writes:
> About the E format setting, you may look at documentation here:
> [[info:org#Formula syntax for Calc]]
Thanks I tried, but I think the core of the problem is that $7 needs two
ifs with two commands
#+begin_src elisp
Case I $6 empty
#+NAME: test
| Name |
>>> "ESF" == Eric S Fraga writes:
> Uwe,
> what if you change the E in each equation with N? You'll get 0 entries
> when the calculations involve all empty cells which might not be what
> you want, of course.
In that case I obtain a 0, which I don't want
smime.p7s
Description: S/MIME
Hi Matt,
Matt Price writes:
>> I would like to be able to surround some portion of a subtree with a tag,
>> e.g.:
>>
>> * parent
>> some text
>> #+HTML:
>> ** child 2
>> some boxed content
>> ** child 2
>>more boxed content
>> #+HTML:
>> ** child 3
>> unboxed content
> I don't know
On Monday, 21 Jun 2021 at 14:36, John Hendy wrote:
> [...] or split the block into a number of more reasonably sized
> cells.
This is what I do in practice. I then use noweb syntax to bring
everything together. In my case, the long LaTeX blocks tend to be tikz
pictures.
Using (native) for
About the E format setting, you may look at documentation here:
[[info:org#Formula syntax for Calc]]
Le 22/06/2021 à 09:44, Eric S Fraga a écrit :
> Uwe,
>
> what if you change the E in each equation with N? You'll get 0 entries
> when the calculations involve all empty cells which might not be
Uwe,
what if you change the E in each equation with N? You'll get 0 entries
when the calculations involve all empty cells which might not be what
you want, of course.
--
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.6-566-gf0198e
: Latest paper written in org:
> Uwe Brauer writes:
> I'm not very familiar with calc, but am wondering if the issue is the
> 'nan'. In many languages, a nan is a 'polluting' variable i.e. once you
> have a nan as a form anywhere in your calculation, the result will
> always be a nan. Many languages actually have a special
38 matches
Mail list logo
