On 2018/10/29 at 08:19, Tim Cross wrote:
> On reading your response, we are probably not as far apart as I first
> thought. However, we have now wondered into discussion which probably
> isn't appropriate for this list. It is now in the realms of something
> that would probably be better discussed
see my normal subject line truncated. The same way, org-mode
will naturally see its paragraphs filled if wanted by the user (otherise
there are no problems in long lines, except, afaik, by default, it
disable truncating lines).
On 2018-10-28 at 18:01, Garreau, Alexandre wrote:
> Rather cutting it, I
Le 28/10/2018 à 10h05, Amin Bandali a écrit :
> Hi,
>
> Nicolas Goaziou writes:
>
>> I don't know. This is why I agree it is safer to limit length to an
>> arbitrary number instead of allowing any size.
>
> Hoping to find an actual answer, I did a =git blame lisp/org.el=
> and found the commit tha
Le 27/10/2018 à 13h55, Nicolas Goaziou a écrit :
> "Garreau, Alexandre" writes:
>
>> Without justification, that’d look like “argument from ignorance”,
>
> I'm not arguing for truncating subjects.
>
> However, I'm arguing against changing a 10 years
Le 27/10/2018 à 13h55, Nicolas Goaziou a écrit :
> "Garreau, Alexandre" writes:
>
>> Without justification, that’d look like “argument from ignorance”,
>
> I'm not arguing for truncating subjects.
>
> However, I'm arguing against changing a 10 years
On 2018/10/25 at 17:02, Nicolas Goaziou wrote:
> "Garreau, Alexandre" writes:
>> Le 24/10/2018 à 13h40, Nicolas Goaziou a écrit :
>>> But you don't need to number the whole buffer, do you?
>>
>> At least the screen.
>>
>>> A br
On 2018/10/27 at 07:15, Tim Cross wrote:
> I have either misunderstood most of your position or I simply disagree
> with it - I'm not sure which.
maybe a mix of both? I hope it’s a misunderstandnment but if it’s not I
want to understand too so to get to a constructive agreement.
> - Much of what
Le 27/10/2018 à 11h27, Nicolas Goaziou a écrit :
> Hello,
>
> Amin Bandali writes:
>
>> Can you please elaborate on what you mean by being on the safe
>> side in this context? What problems could potentially arise from
>> returning the subject in full length?
>
> I don't know. This is why I agree
Le 26/10/2018 à 17h35, Nicolas Goaziou a écrit :
> "Garreau, Alexandre" writes:
>> Why so?
>
> See `org-email-link-description-format'.
Thank you!
>> It shouldn’t be this way by default.
>
> Truncating subject doesn't seem unreasonable to me. In
On 2018/10/26 at 10:29, Eric S Fraga wrote:
> On Friday, 26 Oct 2018 at 08:45, Garreau, Alexandre wrote:
>> I tried to eval the following block, and my point was on the last line,
>> of course, but since it begins with a “|”, it was interpreted as a
>> table, and block was
On 2018/10/26 at 11:34, Nicolas Goaziou wrote:
> "Garreau, Alexandre" writes:
>
>> I tried to eval the following block, and my point was on the last line,
>> of course, but since it begins with a “|”, it was interpreted as a
>> table, and block was not evaled: I
I tried to eval the following block, and my point was on the last line,
of course, but since it begins with a “|”, it was interpreted as a
table, and block was not evaled: I believe this is a bug. Why would a
org table be inside a non-org source block? it’s not even inside a
comment!
#+BEGIN_SRC
Why so?
It shouldn’t be this way by default.
I tried to link
“[[gnus:nnml:lists.gnu.emacs-orgmode#87in1rkqlk@gmail.com][Email
from Tim Cross: Re: {O} Ox-html: Replace with and with
]]” and after org-store-link in appropriated buffer, org-insert-link
gave me “Email from Tim Cross: Re: {O} O
Sorry, just found out that interesting (to me) thread I shouldn’t have
let go:
On 2018-10-25 at 08:00, Tim Cross wrote:
> Kaushal Modi writes:
>> […]
>> - b and i are not deprecated
>> - b and strong are both valid but their use depends on the writer's
>> context (but Org mode has just one mark f
On 2018-10-25 at 12:12, stardiviner wrote:
> Nicolas Goaziou writes:
>> Would you want to provide a patch for that?
>>
>> Thank you.
>>
>> Regards,
>
> I did a search of "font-lock-add-keywords", "begin_src", "src_" etc in
> Org Mode source code, but have not found exact place where fontify
> func
Le 24/10/2018 à 18h15, Nicolas Goaziou a écrit :
> "Garreau, Alexandre" writes:
>> On 2018-10-24 at 17:31, Garreau, Alexandre wrote:
>>> I finally found how people naturally made their mail with org, with
>>> orgstruct++-mode, that I just tried. However tha
On 2018-10-24 at 17:31, Garreau, Alexandre wrote:
> I finally found how people naturally made their mail with org, with
> orgstruct++-mode, that I just tried. However that triggers an infinite
> loop error (“car: Lisp nesting exceeds ‘max-lisp-eval-depth’”), because
> then indent-l
I finally found how people naturally made their mail with org, with
orgstruct++-mode, that I just tried. However that triggers an infinite
loop error (“car: Lisp nesting exceeds ‘max-lisp-eval-depth’”), because
then indent-line-function refers to org-indent-line, which when
orgstruct-is-++ is true
Le 24/10/2018 à 13h40, Nicolas Goaziou a écrit :
> "Garreau, Alexandre" writes:
>
>> As said in the previously mentioned stackoverflow question: helps
>> seeing where you are and how much sections are there. To me it is
>> especially useful to avoid writing man
Le 24/10/2018 à 09h38, Nicolas Goaziou a écrit :
> Hello,
>
> "Garreau, Alexandre" writes:
>
>> But that doesn’t answer the question: why “doesn’t it exist”? shouldn’t
>> these functions be mainlined, if legally permitted?
>
> What kind of numbering are
On 2018-10-23 at 14:33, John Kitchin wrote:
> There are some answers at
> https://emacs.stackexchange.com/questions/32396/complete-path-numbering-of-org-mode-headlines-and-plain-lists
Interesting. Thank you (I’m unfortunately not very friend with search
engines): that also raises altogether the q
Hi,
This is provided on (almost?) all export formats, but yet when looking
at an org-file the prefered way, with emacs, there’s no numbering, by
default.
It’s so useful and simple (using a display text/overlay property), is
there just anything implementing that? mainline? if so why isn’t it?
Why is there no syntax highlighting for *inline* source/code blocks?
For instance, if I type the following:
#+BEGIN_SRC org
src_emacs-lisp{(foo bar (quux))}
#+END_SRC
The underscore is not displayed, “emacs” is displayed in face
~org-latex-and-related~ *and* in subscript display (smaller and
n
On 2018-10-16 at 16:59, John Kitchin wrote:
> This might be going the opposite direction, but I worked on a way to make
> it easier to digest the output of Python in elisp, in these two posts:
>
> http://kitchingroup.cheme.cmu.edu/blog/2015/05/16/Python-data-structures-to-lisp/
> http://kitchingrou
Would it be useful to begin integrating into babel functions so to
serialize lisp objects (just as prin1-to-string) in other languages?
I’ve read some babel files trying to do that, independently of each
others (that’s a lot of similar `typecase's (seeing it I’m regretting
each type-spec in it can
Le 05/11/2014 à 01h42, John Hendy a écrit :
> On Tue, Nov 4, 2014 at 6:33 PM, Garreau, Alexandre
> wrote:
>> Le 04/11/2014 à 03h47, John Hendy a écrit :
> What's not enough? The docs also state (a bit above the babel lines):
> From my min-config, you can see that enabli
Le 04/11/2014 à 03h47, John Hendy a écrit :
> Could you post the gnuplot/babel relevant stuff from your .emacs?
This:
#+BEGIN_SRC emacs-lisp
;; active Babel languages
(org-babel-do-load-languages
'org-babel-load-languages
'((gnuplot . t)))
;; add additional languages with '((language . t)))
#+E
Hello, when I do `org-plot/gnuplot' on a org-plot figure it says
“org-plot/gnuplot: Cannot open load file: gnuplot”.
I also tried org-babel-gnuplot, and on an example code, C-c C-c says
“org-babel-execute-src-block: No org-babel-execute function for
gnuplot!”.
I’m under Debian Testing (Jessy), ha
On 2014-11-03 at 01:23, Rasmus wrote:
> Hello,
>
> "Garreau, Alexandre" writes:
>> On 2014-11-02 at 22:48, John Kitchin wrote:
>>> Nicolas Goaziou writes:
>>> Interestingly, this:
>>> #+LATEX_HEADER: \usepackage{chemfig}
>>> $\chemfig
On 2014-11-02 at 22:48, John Kitchin wrote:
> Nicolas Goaziou writes:
>
> Interestingly, this:
>
> #+LATEX_HEADER: \usepackage{chemfig}
>
>
> $\chemfig{A-B-[1]C-[3]-D-[7]E-[6]F}$
>
>
> exports to pdf correctly, but the latex preview is not correct. All the
> letters are jumbled on top of each othe
Le 02/11/2014 à 20h45, Nicolas Goaziou a écrit :
> Hello,
>
> "Garreau, Alexandre" writes:
>
>> Hello, I’d like to being able to preview chemfig, like lines beginning
>> with \chemfig{.
>>
>> But (a) they’re not detected as LaTeX fragments by the pre
Hello, I’d like to being able to preview chemfig, like lines beginning
with \chemfig{.
But (a) they’re not detected as LaTeX fragments by the previewer (and it
seems only some matchers are accepted by default, I can’t say, for
instance, “^{\\[a-zA-Z]*[a-zA-Z0-9 ].*}$”), and (b) when previewing I
d
32 matches
Mail list logo
