Ihor Radchenko writes:
> It looks like "backend" is more popular at the end.
>
> I will go for it everywhere unless there are objections.
Done on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=f81ba451a
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more
backend sounds good to me as a native speaker, for a term of art for
export modules or so, with defined api. if you are talking about back
end code abstractly, i'd go for 2 words, but that's just me. i
wouldn't rely on my sense for this one.
On 11/22/22, Ihor Radchenko wrote:
>
alain.coch...@unistra.fr writes:
> > I looked further, and the situation is not as simple.
> > https://grammarhow.com/backend-back-end-or-back-end/, for example,
> > claims that only "back-end" is grammatically correct.
> >
> > I am now thinking to do the following:
> > 1. Use "backend" in
Ihor Radchenko writes on Mon 20 Feb 2023 10:07:
> I looked further, and the situation is not as simple.
> https://grammarhow.com/backend-back-end-or-back-end/, for example,
> claims that only "back-end" is grammatically correct.
>
> I am now thinking to do the following:
> 1. Use "backend"
Ihor Radchenko writes:
> I am looking at https://techterms.com/definition/backend, and it looks
> like "backend" is the correct word we need to use here. Am I missing
> something?
I looked further, and the situation is not as simple.
https://grammarhow.com/backend-back-end-or-back-end/, for
Ihor Radchenko writes:
> The attached is a fix for this discrepancy with the manual.
>
> However, it looks like at least ob-java already tried to work around the
> erroneous return value of org-babel-read-list.
>
> Hence, we at least need to announce this fix in ORG-NEWS.
>
> Or maybe there are
alain.coch...@unistra.fr writes:
> > +The result type detection depends on the code block language, as
> > +described in the documentation for individual [[*Languages][languages]].
>
> Is this intended? On the pdf it looks strange to me:
>
>The result type detection depends on the code
Ihor Radchenko writes on Tue 22 Nov 2022 08:16:
> See the attached patch with tentative changes to the manual. Let
> me know if you think that things are still not clear.
Things are clear. Thanks.
> +The result type detection depends on the code block language, as
> +described in the
alain.coch...@unistra.fr writes:
> PS 2: Reading the ob-doc-shell.html page, I understood (kind of) what
> was so far a mystery to me : that a "#+begin_src bash" group works as
> expected while "#+begin_src ba + C-M-i" fails to complete "ba" to
> "bash": namely that all the shells fall inside the
alain.coch...@unistra.fr writes:
> PS 1: In the manual, I see "backend" and "back-end". So it is an
> issue similar to the "subtree/sub-tree" issue you fixed a few days
> ago, to the "heading/headline" issue that was reported recently, and
> to many similar cases I met in the past. So I was
alain.coch...@unistra.fr writes:
> > Will it help if we mention this fact in "16.6 Results of Evaluation"
> > section?
>
> Yes, it would help me. At least I would been warned. But it would be
> complete only if knew where to read about each specific babel backend.
>
> > > For the sake of
Ihor Radchenko writes:
>> Confirmed, but it does not look like Org's fault.
>
> Reported to Emacs devs.
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59293
Upon discussion, I have settled with a workaround.
This is a known Emacs info.el limitation.
Fixed.
Ihor Radchenko writes:
>> Confirmed, but it does not look like Org's fault.
>
> Reported to Emacs devs.
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59293
Upon discussion, I have settled with a workaround.
This is a known Emacs info.el limitation.
Fixed.
Rudolf Adamkovič writes:
> alain.coch...@unistra.fr writes:
>
>> So I was wondering if there could exist some (semi-)automatic way
>> which would ensure that future maintainers will not inadvertently
>> re-introduce "sub-tree" occurrences, or the like. Perhaps some
>> "accepted terminology"
alain.coch...@unistra.fr writes:
> So I was wondering if there could exist some (semi-)automatic way
> which would ensure that future maintainers will not inadvertently
> re-introduce "sub-tree" occurrences, or the like. Perhaps some
> "accepted terminology" list that would be checked upon?
We
Ihor Radchenko writes on Mon 14 Nov 2022 03:59:
> alain.coch...@unistra.fr writes:
>
> > Ihor Radchenko writes on Mon 7 Nov 2022 02:31:
> > > If you want to force string output, use :results output.
> > >
> > > By default, ob-shell tries to guess the output type. In the
> > > case of
Ihor Radchenko writes:
>> In 16.5 (Evaluating Code Blocks), in this code
>>
>>#+NAME: random
>>#+BEGIN_SRC R :cache yes
>> runif(1)
>>#+END_SRC
>>
>> the (1) seems to be understood as a footnote in Info, at least for me.
>> E.g., on it goes to the footnote
>>
>>(1) The
Ihor Radchenko writes:
>> In section 16.4 (Environment of a Code Block)
>>
>> A simple named list.
>>
>> #+NAME: example-list
>> - simple
>> - not
>> - nested
>> - list
>>
>> #+BEGIN_SRC emacs-lisp :var x=example-list
>> (print x)
>>
alain.coch...@unistra.fr writes:
> Ihor Radchenko writes on Mon 7 Nov 2022 02:31:
>
> > If you want to force string output, use :results output.
> >
> > By default, ob-shell tries to guess the output type. In the case
> > of two commands returning output, the guess is yielding the
> >
Ihor Radchenko writes on Mon 7 Nov 2022 02:31:
> If you want to force string output, use :results output.
>
> By default, ob-shell tries to guess the output type. In the case
> of two commands returning output, the guess is yielding the
> table. In the case of a single command, the guess
alain.coch...@unistra.fr writes:
>#+begin_src bash
>echo "foo"
>echo "bar"
>#+end_src
>
> Typing 'C-c C-c' produces
>
>#+RESULTS:
>| foo |
>| bar |
>
> By contrast, with only 'echo "foo"', it produces what I expect:
>
>#+RESULTS:
>: foo
If you want to force
Hello.
I do
emacs -Q -l ~/.emacs.git
with .emacs.git being
(add-to-list 'load-path "~/Org/Coch-git/org-mode/lisp")
(custom-set-variables
'(org-babel-load-languages
'(
(shell . t))
)
'(debug-on-error t)
)
Org mode version 9.6-pre
22 matches
Mail list logo
