Re: [BUG] With R using ":var d=data" breaks ":colnames yes" [9.7-pre (release_9.6.10-881-g595a32]

Paul Stansell writes: > Thanks for your advice, it helps a lot. Sorry for submitting > something that wasn't a bug. While not a bug, the situation can certainly be improved. Things should be a bit smarter on main after https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=cab81f242

Re: [BUG] With R using ":var d=data" breaks ":colnames yes" [9.7-pre (release_9.6.10-881-g595a32]

Hi Ihor, Thanks for your advice, it helps a lot. Sorry for submitting something that wasn't a bug. Paul On Thu, 7 Mar 2024 at 13:16, Ihor Radchenko wrote: > Paul Stansell writes: > > > It seems that using ":var d=data" breaks ":colnames yes" in the header of > > an R code block. > > ... > >

Re: false positives: Re: Experimental public branch for inline special blocks

Juan Manuel Macías writes: > Ihor Radchenko escribió: > >> I am wondering if @@[...]{...} would be better than @_... >> It should be slightly easier to type. > > Another possibility would be @:[...]{...}, which is somewhat shorter. > > (I don't have any special preference, although @@ visually

Re: Pending contents in org documents (Re: Asynchronous blocks for everything (was Re: ...))

Bruno Barbier writes: >> I now think that overlays are the right way; the /pending content/ is >> attached to one buffer: a base or a clone; this is for the user to >> decide. >> >> I will manually add text properties, below the overlay, to mark the text >> as /pending/, so that pending contents

Re: [DISCUSSION] Add "Recent News" to orgmode.org

Ihor Radchenko writes: > Bastien Guerry writes: > >> Ihor Radchenko writes: >> >>> Wouldn't a cron job work? Similar to how we schedule CI for Org mode >>> tests. >> >> I've set this cron job to run every six hours and limited the number >> of entries to 5 to not clutter the homepage. > > Note

Re: Emacs slow-down

Hi Bill another sleepless night. Having something to distract me is helpful. In this case, one of the root causes for my insufferable slowdown was not org-mode but jinx (the spell checker). Without it, I do notice a slow down when going through my slides, but much less. Going back to ispell...

Re: naming: Re: Experimental public branch for inline special blocks

cannot follow discussion but is the role and scope of the proposed semantics settled and agreed upon by those who do?

Re: [DISCUSSION] Add "Recent News" to orgmode.org

Bastien Guerry writes: > Ihor Radchenko writes: > >> Wouldn't a cron job work? Similar to how we schedule CI for Org mode >> tests. > > I've set this cron job to run every six hours and limited the number > of entries to 5 to not clutter the homepage. Note that

Re: [DISCUSSION] Add "Recent News" to orgmode.org

Ihor Radchenko writes: > Wouldn't a cron job work? Similar to how we schedule CI for Org mode > tests. I've set this cron job to run every six hours and limited the number of entries to 5 to not clutter the homepage. -- Bastien Guerry

Re: Provide sane default for the @direntry

Stefan Monnier writes: >> The patches are against Emacs git repository, not against Org mode. May >> your please port them? > > See attached. Thanks! Unfortunately, the patch causes some tests (make test) to fail. Looks like export to temporary buffer is broken (temporary buffer does not have a

Re: noweb-start and noweb-end header args

Amy Grinn writes: >> Org mode does not _currently_ modify the code. But that's actually wrong >> - things like escaped ,* or indentation sometimes also stay on the way >> and produce incorrect fontification. So, rewriting the fontification of >> src blocks to cleanup the code before

Re: cannot export asynchronously because of org-fold-core--update-buffer-folds

On 2024-03-07 12:35, Ihor Radchenko writes: > Alan Schmitt writes: > >> I’m trying to export a file asynchronously to beamer/pdf, and I have a >> strange error. Here is the contents of the *Org Export Process* buffer: >> >> Debugger entered--Lisp error: (void-function >>

Re: Emacs slow-down

On 2024-03-07, 13:23 +, Ihor Radchenko wrote: > This is strange. `org-fold-core--property-symbol-get-create' should be > very fast normally. > > A blind guess: do you have `org-fold-core-style' set to 'text-properties? > Hi Ihor, No, `org-fold-core-style' is set to 'overlays.

Re: Emacs slow-down

Bruno Cardoso writes: > I also did noticed some slow-down in the most recent org. This is the CPU > profiler report after typing some words in an org-file I'm working on: > > ... > 2122 23% - org-fold-core-get-folding-spec > 2035 22%

Re: noweb-start and noweb-end header args

Amy Grinn writes: > Here is a simple way to implement this feature. > ... > -(defun org-babel-noweb-wrap ( regexp) > +(defun org-babel-noweb-wrap ( regexp info) >"Return regexp matching a Noweb reference. > > Match any reference, or only those matching REGEXP, if non-nil. > > When

Re: noweb-start and noweb-end header args

Ihor Radchenko writes: > :noweb yes <<< >>> is actually backwards-incompatible. Consider > third-party code that makes assumptions about possible values of > :noweb > header argument. If third-party code does a check like > (equal noweb-value "yes"), the new syntax can break such code. I kinda

Re: noweb-start and noweb-end header args

Amy Grinn writes: > I kinda disagree with your reasoning but I agree with your conclusion. > I think it would be strange for third party or user configuration to > parse the value of a noweb header argument directly. Org provides a > lublic api for this which should be backwards compatible: > >

Re: Just thinking...

Pedro Andres Aranda Gutierrez writes: > duplicating export entries for LaTeX and Beamer makes the interface not > exactly clean. > We do have the LaTeX class, which should be "beamer" (I hope) for Beamer > presentations, right? > > So why not use that to decide internally between

Re: naming: Re: Experimental public branch for inline special blocks

Max Nikulin writes: >> IMHO, the whole point of the discussed construct is exactly being abstract >> and multi-purpose. > > Almost everything in Org syntax may be called "markup", so using this > word for a specific object may lead to confusion unless a couple of > extra words are added to

Re: cannot export asynchronously because of org-fold-core--update-buffer-folds

Alan Schmitt writes: > I’m trying to export a file asynchronously to beamer/pdf, and I have a > strange error. Here is the contents of the *Org Export Process* buffer: > > Debugger entered--Lisp error: (void-function > org-fold-core--update-buffer-folds) > ... > To make sure I have a

Re: Bug: file names capitalised when using gnuplot [9.3 (release_9.3 @ /usr/share/emacs/27.1/lisp/org/)]

Paul Stansell writes: > A bug occurs when plotting data from an Org table using Gnuplot. An > example is given below. In the first code block the plot is produced as > expected, but in the second code block (where I have changed a lowercase > "c" to an uppercase "C") gnuplot tries to plot data

Re: [BUG] With R using ":var d=data" breaks ":colnames yes" [9.7-pre (release_9.6.10-881-g595a32]

Paul Stansell writes: > It seems that using ":var d=data" breaks ":colnames yes" in the header of > an R code block. > ... > #+name: data > |+| > | x | y | > |+| > | 111.89 | 88.37 | > | 392.12 | 297.33 | > |+| It is expected. :colnames

Re: noweb-start and noweb-end header args

Amy Grinn writes: > To expand on this, some major modes can fundamentally conflict with the > default noweb syntax. Here is a valid shell script *and* a valid noweb > reference to a block named EOF: > > cat <> file.txt > Hello > EOF > > I hope this helps explain why the wrap-start and wrap-end

Re: Subject: cannot export asynchronously because of org-fold-core--update-buffer-folds

Hi, could you please try to add #+LATEX_CLASS: beamer #+LATEX_CLASS_OPTIONS: [presentation,aspectratio=169] instead of (require 'ox-latex) (add-to-list 'org-latex-classes '("my-beamer" "\\documentclass\[presentation,aspectratio=169\]\{beamer\}

Re: naming: Re: Experimental public branch for inline special blocks

On 06/03/2024 17:56, Ihor Radchenko wrote: Max Nikulin writes: Custom inline markup. "Markup" is something abstract to my taste. I would prefer something related to concrete instances of such objects. IMHO, the whole point of the discussed construct is exactly being abstract and

Re: false positives: Re: Experimental public branch for inline special blocks

Max Nikulin writes: > It seems the parser finds new objects where syntactical constructs are > incomplete: > > (org-export-string-as "Alpha{" > 'html > '(:export-options (body-only))) > "\nAlpha{\n" mmm, right. And there may also be a problem with the

[BUG] obscure error for invalid :exports

Hi, Trying to export (to HTML buffer) src_elisp[:exports source]{a} I have got an obscure error org-export-as: Wrong type argument: char-or-string-p, nil I believe, some meaningful error should be signaled. I was quite surprised since the following is exported with no error

Re: false positives: Re: Experimental public branch for inline special blocks

Juan Manuel Macías writes: >> (org-export-string-as "Alpha{" > ... > mmm, right. And there may also be a problem with the subscripts: > &_{subscript}... > > Perhaps we should think about a structure less prone to ambiguities. For > example: > > &:type[attrs]{text} / &:_[attrs]{text} I

Re: Subject: cannot export asynchronously because of org-fold-core--update-buffer-folds

Will try with my setup @home with the main branch of the git to check again. /PA Enviado desde mi iPhone > El 7 mar 2024, a las 10:42, Alan Schmitt > escribió: > > Hi Pedro, > > On 2024-03-07 10:03, Pedro Andres Aranda Gutierrez writes: > >> could you please try to add >> >>

false positives: Re: Experimental public branch for inline special blocks

On 02/03/2024 03:34, Juan Manuel Macías wrote: Finally, I have made public on GitLab my experimental branch for the new (possible) inline-special-block element: It seems the parser finds new objects where syntactical constructs are incomplete:

Re: false positives: Re: Experimental public branch for inline special blocks

Ihor Radchenko writes: > Juan Manuel Macías writes: > >>> (org-export-string-as "Alpha{" >> ... >> mmm, right. And there may also be a problem with the subscripts: >> &_{subscript}... >> >> Perhaps we should think about a structure less prone to ambiguities. For >> example: >> >>

Just thinking...

Hi, duplicating export entries for LaTeX and Beamer makes the interface not exactly clean. We do have the LaTeX class, which should be "beamer" (I hope) for Beamer presentations, right? So why not use that to decide internally between (org-latex-export-...) and (org-beamer-...) and then have a

Re: Subject: cannot export asynchronously because of org-fold-core--update-buffer-folds

Hi Pedro, On 2024-03-07 10:03, Pedro Andres Aranda Gutierrez writes: > could you please try to add > > #+LATEX_CLASS: beamer > #+LATEX_CLASS_OPTIONS: [presentation,aspectratio=169] > > instead of > > (require 'ox-latex) > > (add-to-list 'org-latex-classes > '("my-beamer" >

Re: Emacs slow-down

Hello, I also did noticed some slow-down in the most recent org. This is the CPU profiler report after typing some words in an org-file I'm working on: 6493 71% - redisplay_internal (C function) 6372 70% - jit-lock-function 6323 69% - jit-lock-fontify-now

Re: noweb-start and noweb-end header args

Ihor Radchenko writes: > Amy Grinn writes: > >> Here is a simple way to implement this feature. > > Since you are adding a new feature, it should have (1) test coverage; > (2) be documented in the manual; (3) be announced in etc/ORG-NEWS. Thank you for the tips, will do!

Re: false positives: Re: Experimental public branch for inline special blocks

Ihor Radchenko writes: > I suggest @type[...]{...}. Akin Texinfo constructs. > > (Texinfo because of > previous RMS' request to implement better support for markup used in > software manuals - keeping things close to Texinfo syntax will make life > easier if we ever reach the point when Org mode

Re: false positives: Re: Experimental public branch for inline special blocks

Juan Manuel Macías writes: > I have modified the syntax in the last commit. Now: > > @type[...]{...} (or @_[...]{...}) I am wondering if @@[...]{...} would be better than @_... It should be slightly easier to type. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode

Re: Emacs slow-down

Pedro Andres Aranda Gutierrez writes: > 443 29% + redisplay_internal (C function) > ... > Interestingly enough, this redisplay_internal function seems to be the real > pain. I think we need to switch to the main > emacs devel list here... Unlikely. Note the +. redisplay_internal

Re: Things got very slow: profiler output

On Thursday, February 29th, 2024 at 04:25, Bruno Barbier wrote: > Oops, sorry, the customization option is: > > org-highlight-latex-and-related > > (the other value is computed by Org) > > You may try to change that option org-highlight-latex-and-related to see > if it helps. I checked: |

Re: Emacs slow-down

On Thursday, March 7th, 2024 at 11:03, Pedro Andres Aranda Gutierrez wrote: > Interestingly enough, this redisplay_internal function seems to be the real > pain. I think we need to switch to the main > emacs devel list here... I wonder if those of us seeing this have something in common about

Re: Emacs slow-down

Pedro Andres Aranda Gutierrez writes: > same here and changing to text-properties didn't help making editing org > files less bumpy and slow. > I don't know if 886 lines is really very much... but that's my org-beamer > size for a double lecture. Any chance you can provide a reproducer starting

Re: Emacs slow-down

Hi, my profiling when deleting a line from a table: 650 43% + redisplay_internal (C function) 521 35% - command-execute 470 31% - byte-code 470 31% - read-extended-command 470 31%- read-extended-command-1 470 31% -

Re: Emacs slow-down

Hi Ihor, same here and changing to text-properties didn't help making editing org files less bumpy and slow. I don't know if 886 lines is really very much... but that's my org-beamer size for a double lecture. Best, /PA On Thu, 7 Mar 2024 at 15:58, Bruno Cardoso wrote: > > On 2024-03-07,

Re: false positives: Re: Experimental public branch for inline special blocks

Ihor Radchenko escribió: > I am wondering if @@[...]{...} would be better than @_... > It should be slightly easier to type. Another possibility would be @:[...]{...}, which is somewhat shorter. (I don't have any special preference, although @@ visually reminds me a bit of the export snippet).

Re: Things got very slow: profiler output

William Denton writes: > On Thursday, February 29th, 2024 at 04:25, Bruno Barbier > wrote: > [...] > I checked: > > | Its value is (latex) > | Original value was nil > > I didn't have a chance to dig back into this but now I see other people are > reporting slowness and I hope this helps. >

Re: Pending contents in org documents (Re: Asynchronous blocks for everything (was Re: ...))

Hi, Bruno Barbier writes: > Ihor Radchenko writes: > >> Bruno Barbier writes: >> Overlays are not transferred when a new indirect buffer is created (for example, by org-capture, or by user). So, it will be (1) impossible to see pending overlays in indirect buffers; (2) user