On Monday, 22 Jun 2015 at 08:48, Daniel Bausch wrote:
[...]
> I am doing each day. Maybe I will look again how to set the expected
> LC_... environment variables for emacs daemon.
This may be the way forward. My LC related environment variables are
all set to en_GB.UTF-8.
This seems to be set
Nick Dokos writes:
> Eric S Fraga writes:
>
>> On Friday, 19 Jun 2015 at 08:19, Daniel Bausch wrote:
>>
>> [...]
>>
>>> Line 6000 is indeed quite "lame". I have similar problems like Eric. A
>>> table recalculation at line 43868 takes about a minute at my quite fast
>>> machine. I also tracke
Eric S Fraga writes:
> On Friday, 19 Jun 2015 at 10:28, Daniel Bausch wrote:
>
> [...]
>
>> If anyone could give me a hint how to reliably set the preferred (or
>> internal) encoding I could check wether it might have something to do
>> with the system locale.
>
> I have (only) the following enco
On Friday, 19 Jun 2015 at 09:53, Nick Dokos wrote:
[...]
> What is the setting of cache-long-scans you are using? Does it differ
> on the two laptops?
>
> Ivan Andrus suggested setting it to nil, but it seems that for this
> case, leaving it at t (the default) should be much faster. But there
> m
Eric S Fraga writes:
> On Friday, 19 Jun 2015 at 08:19, Daniel Bausch wrote:
>
> [...]
>
>> Line 6000 is indeed quite "lame". I have similar problems like Eric. A
>> table recalculation at line 43868 takes about a minute at my quite fast
>> machine. I also tracked that down to org-current-line
On Friday, 19 Jun 2015 at 10:28, Daniel Bausch wrote:
[...]
> If anyone could give me a hint how to reliably set the preferred (or
> internal) encoding I could check wether it might have something to do
> with the system locale.
I have (only) the following encoding related settings in my
initial
Eric S Fraga writes:
> On Friday, 19 Jun 2015 at 08:19, Daniel Bausch wrote:
>
> [...]
>
>> Line 6000 is indeed quite "lame". I have similar problems like Eric. A
>> table recalculation at line 43868 takes about a minute at my quite fast
>> machine. I also tracked that down to org-current-line
On Friday, 19 Jun 2015 at 08:19, Daniel Bausch wrote:
[...]
> Line 6000 is indeed quite "lame". I have similar problems like Eric. A
> table recalculation at line 43868 takes about a minute at my quite fast
> machine. I also tracked that down to org-current-line. One interesting
> detail is t
Hello,
Daniel Bausch writes:
> Line 6000 is indeed quite "lame". I have similar problems like Eric. A
> table recalculation at line 43868 takes about a minute at my quite fast
> machine. I also tracked that down to org-current-line. One interesting
> detail is that this depends on the buffer
Daniel Bausch writes:
> I think it actually is not an org-mode problem but depends on how
> (count-lines 1 (point)) works, as it is using regex searches for the
> line endings. I can imagine that the regex parser for utf-8 can be
> inefficient.
I just looked again at Eric's profile output. Why
Hi!
Nick Dokos writes:
> Eric S Fraga writes:
>
>
>> The output of the ELP profiler is here:
>>
>> ...
>> org-goto-line 104 10.761145733 0.1034725551
>> ..
>> org-current-line66 6.8422078910 0.1036698165
>> ...
>
> I find these two difficult to exp
I’m jumping into the middle of the thread, but have you tried
(setq cache-long-scans nil)
That solved some performance issues for me. I can’t remember where
I got the advice.
-Ivan
On Jun 18, 2015, at 10:28 AM, Eric S Fraga wrote:
Hello,
there have been a few threads recently mentioning
Eric S Fraga writes:
> The output of the ELP profiler is here:
>
> ...
> org-goto-line 104 10.761145733 0.1034725551
> ..
> org-current-line66 6.8422078910 0.1036698165
> ...
I find these two difficult to explain: they account for the vast
majority
Hello,
there have been a few threads recently mentioning poor
performance. Although some of these have been resolved (e.g. the use of
=linum=), I wonder if I could add a data point.
I have a medium (for me) sized (385 kB) org file with all of my "tasks"
in a date-tree structure. One of the task
>> "rasmus" == rasmus writes:
> Uwe Brauer writes:
>> Look the following examples
>>
>> \begin{displaymath}
>> Xs,δ:=Hs,δ× Hs,δ+1× Hs,δ+1×
>> Hs+1,δ+2
>> \end{displaymath}
>> org-preview-latex-fragment does not work, change displaymath for
>> equation, again org-preview-latex-f
Uwe Brauer writes:
> Look the following examples
>
>> \begin{displaymath}
>> Xs,δ:=Hs,δ× Hs,δ+1× Hs,δ+1×
>> Hs+1,δ+2
>> \end{displaymath}
> org-preview-latex-fragment does not work, change displaymath for
> equation, again org-preview-latex-fragment does not work, but
> \[ \]
> does work, this
<#secure method=smime mode=sign>
>> "rasmus" == rasmus writes:
> Uwe Brauer writes:
> Probably not.
> Note these are Org features irrespective of fragment preview. There
> was some talk about it not so long ago.
> Basically, it just happens that works as desired most of
17 matches
Mail list logo
