On Fri, Dec 24, 2021 at 04:21:58PM -0500, Robert Nikander wrote:
> I started reading about “blocks" in the manual. I wanted a chunk of text that
> I could hide, so I tried this:
>
> * Test
> Some text
> #+BEGIN
> Hide this
> #+END
>
> Hitting TAB on the BEGIN line does nothing. But if I add a
20051 135025 938122 other--a.org
this is a smallish to middling file for me. my largest is 4x larger.
i haven't gotten new org to work yet so i haven't revisited this yet.
On 12/24/21, Ihor Radchenko wrote:
> Samuel Wales writes:
>
>> this reproduces most or all of the time. idk if it is
I started reading about “blocks" in the manual. I wanted a chunk of text that I
could hide, so I tried this:
* Test
Some text
#+BEGIN
Hide this
#+END
Hitting TAB on the BEGIN line does nothing. But if I add a blank line before
it, then hitting TAB hides and shows the block. Is that a bug? Or
Max Nikulin writes:
> Text books and magazines may contain insets (side notes), sometimes
> even page-long ones. They present independent material that may be
> interesting or useful in particular context or may be just skipped
> when a reader is concentrated on main material. Such inset may be
> On Dec 23, 2021, at 8:09 PM, Ihor Radchenko wrote:
>
> Rudolf Adamkovič writes:
>
>>> So, Org cannot distinguish between language backends that are simply
>>> not loaded and the ones that do not define org-babel-execute:lang.
>>
>> Oh, if we have this architectural limitation in place,
On 24/12/2021 03:27, Juan Manuel Macías wrote:
Robert Nikander writes:
I see why this is not possible, given the text format of an org file.
But I am curious if people think it would be useful.
While considered isolated, vim feature "set foldmethod=marker" with
explicit open and closed
On 12/23/21 12:16 PM, Denis Maier wrote:
What do you think about using context's structurelevels instead? That
would allow users to define their own mappings.
Denis
That looks like a brilliant solution. I'll have to give it a deeper look
to know for sure though - table of contents
On 24/12/2021 21:29, Ihor Radchenko wrote:
Hmm. What about just building Emacs from source? Newer Emacs can usually
be compiled without a need to install super-new toolchain. You may not
need to update the whole Debian (which can indeed be a nightmare) just
to get newer Emacs.
Current Debian
Samuel Wales writes:
> ... and another where c-x c-c is very slow but there aren't
> messages saying what it is doing.
This is most likely also related to org-persist. It tries to save the
cached parser state on Emacs exit and load it back on startup.
> ... if i quit at the wrong time, cache
Samuel Wales writes:
> fyi, i am still trying to get main to work. there is bug in most
> recent main where org element use cache being set to t makes loading
> infinite. and another where c-x c-c is very slow but there aren't
> messages saying what it is doing.
I replied in the bug report.
Ihor Radchenko writes:
> Samuel Wales writes:
>
>> one issue with this great thing called capture is that there is
>> nothing quite so convenient that does the exact opposite.
>>
>> [you can regularly purge, if your life/forest is simple enough or you
>> have the physical ability to do
Samuel Wales writes:
> this reproduces most or all of the time. idk if it is ueful to
> anybody, but i thought i would post it in case it is instantly
> recognizable.
>
> emacs 25. latest 9.5 org main.
>
> Debugger entered--Lisp error: (quit)
> read(#)
> org-persist-read(org-element--cache
Samuel Wales writes:
> one issue with this great thing called capture is that there is
> nothing quite so convenient that does the exact opposite.
>
> [you can regularly purge, if your life/forest is simple enough or you
> have the physical ability to do things. but you can't just
>
13 matches
Mail list logo
