On 04/12/2022 18:27, Ihor Radchenko wrote:
Max Nikulin writes:
For some reason I believed that gettext was available in Emacs.
...
It would indeed be interesting to have a unified approach to bring
translations into Emacs. I'd discuss it on emacs-devel.
I found the following thread:
Eli Z
Hi there,
the syntax for Text Markup such as *bold* at [1] specifies
PRE MARKER CONTENTS MARKER POST with
CONTENTS as BORDER BODY BORDER and
BORDER as “Any non-whitespace character.”
What is the role of BORDER here? Does it really exist?
What is BORDER if CONTENTS should be a single character,
On Tue, Dec 06, 2022 at 07:28:20PM +0100, Jens Lechtenboerger wrote:
> Hi there,
>
> the syntax for Text Markup such as *bold* at [1] specifies
> PRE MARKER CONTENTS MARKER POST with
> CONTENTS as BORDER BODY BORDER and
> BORDER as “Any non-whitespace character.”
>
> What is the role of BORDER he
Hi,
I was playing with the idea of calling subprocesses from TBLFM (good idea or
not)...
...and found that:
| |
#+TBLFM: $1='(shell-command-to-string "echo 42")
Tries to build an infinitly long table (I have to interrupt it with C-g).
While:
| |
#+TBLFM: $1=42
Which looks
Julien Palard writes:
> Hi,
>
> I was playing with the idea of calling subprocesses from TBLFM (good idea or
> not)...
>
> ...and found that:
>
> | |
> #+TBLFM: $1='(shell-command-to-string "echo 42")
>
> Tries to build an infinitly long table (I have to interrupt it with C-g).
...
>
Hello,
Many thanks for the insights. I confess that I have never transferred
list from org to R before. I've always use tables and as far as I
understand they works fine in 9.6.
So assuming this list
#+name: alist
- first item
- second item
- third item
- 3.1 item
- fourth item
before c72d5
Hi,
I tried applying just the change in
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=456462741 to
released Org 9.6 and find that when using `:session *R*` the #+RESULTS are
still empty, but when running without :session the results are provided.
Is there any diagnostic or re
Jeremie,
i am neutral w.r.t. what the output should be. like you, i've always
sent in tables.
for me, i don't know that it makes much difference how lists are
presented to R code, as long as it is well-defined and stable over time.
given that, iiuc, 9.5 presented a list as (the equivalent of) m
On 6 December 2022, Greg Minshall wrote:
given that, iiuc, 9.5 presented a list as (the equivalent of) multiple
rows of a table, i'd vote for staying with (going back to) that.
(i think that's what the two modifications in Chuck's e-mail give you.)
I agree: I've never used this, but if it use
On 07/12/2022 01:28, Jens Lechtenboerger wrote:
Hi there,
the syntax for Text Markup such as *bold* at [1] specifies
PRE MARKER CONTENTS MARKER POST with
CONTENTS as BORDER BODY BORDER and
BORDER as “Any non-whitespace character.”
What is the role of BORDER here? Does it really exist?
I thin
After updating to Org 9.6 this match in the agenda
'SCHEDULED<"<+2d>"+SCHEDULED<>"' shows all scheduled items event if they
are far more in the future than 2 days.
Tracked this down to a commit (e022a0cea11a0e784ba20ac478a033da7fb1bb7f)
that changed the regular expression to recognize timestamps:
On 2022-12-07, Max Nikulin wrote:
> On 07/12/2022 01:28, Jens Lechtenboerger wrote:
>> Hi there,
>> the syntax for Text Markup such as *bold* at [1] specifies
>> PRE MARKER CONTENTS MARKER POST with
>> CONTENTS as BORDER BODY BORDER and
>> BORDER as “Any non-whitespace character.”
>> What is the r
On 2022-12-07, Jens Lechtenboerger wrote:
> On 2022-12-07, Max Nikulin wrote:
>
>> On 07/12/2022 01:28, Jens Lechtenboerger wrote:
>>> Hi there,
>>> the syntax for Text Markup such as *bold* at [1] specifies
>>> PRE MARKER CONTENTS MARKER POST with
>>> CONTENTS as BORDER BODY BORDER and
>>> BORDER
13 matches
Mail list logo
