# Julia REPL: pasting code while repl is busy is slow

**URL:** <https://discourse.julialang.org/t/julia-repl-pasting-code-while-repl-is-busy-is-slow/123765>\
**Category:** General Usage\
**Created:** [December 12, 2024, 3:28pm UTC](https://discourse.julialang.org/t/julia-repl-pasting-code-while-repl-is-busy-is-slow/123765 "2024-12-12T15:28:12Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![hexaeder](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/hexaeder/32/24403_2.png) [@hexaeder](https://discourse.julialang.org/u/hexaeder)\
**Post date:** [December 12, 2024, 3:28pm UTC](https://discourse.julialang.org/t/julia-repl-pasting-code-while-repl-is-busy-is-slow/123765/1 "2024-12-12T15:28:13Z")

</div>

Hello,

for a long time now I observed a strange repl behavior, which I always [contributed to emacs + vterm](https://github.com/tpapp/julia-repl/issues/151). However I now realised, that it also appears in different terminals (iterm2 on mac and windows terminal/wsl) so it seems to be related to Julia itself.

The problem is, that pasting code into the REPL is _much slower_ when pasting while the repl is busy then when pasting while idle.

Steps to reproduce:

- open `julia --startup-file=no`
- past longish text: appears instantly
- call some function which keeps julia busy for some time (e.g. `sleep(5)`)
- paste the same text while Julia is busy
- text appears instantly
- Once the `sleep` returns, the pasted text re-appears very slowly at the prompt (while CPU usage goes crazy) before its being executed.

Example video:

Any idea what causes this behavior? It isn’t to bad the repl, but is quite annoying in my emacs workflow where I constantly send large chunks of text to the repl and it .

---

<div class="post-metadata">

**Author:** ![NimaPoshtiban](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nimaposhtiban/32/214104_2.png) [@NimaPoshtiban](https://discourse.julialang.org/u/NimaPoshtiban)\
**Post date:** [December 12, 2024, 4:29pm UTC](https://discourse.julialang.org/t/julia-repl-pasting-code-while-repl-is-busy-is-slow/123765/2 "2024-12-12T16:29:59Z")

</div>

It’s working fine in Windows. perhaps an iterm2 issue? One idea is to check if it is because of the **buffer size limit.**

---

<div class="post-metadata">

**Author:** ![hexaeder](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/hexaeder/32/24403_2.png) [@hexaeder](https://discourse.julialang.org/u/hexaeder)\
**Post date:** [December 13, 2024, 8:49am UTC](https://discourse.julialang.org/t/julia-repl-pasting-code-while-repl-is-busy-is-slow/123765/3 "2024-12-13T08:49:18Z")

</div>

So the video in the first post was windows terminal but julia running under Ubuntu in WSL. I’ve also seen this behavior in Iterm2 under MAC and vterm in emacs.

Just now I tried it in the windows terminal with windows-julia running in powershell, and there it does not matter whether the repl is busy or not, the pasted text appears slowly letter by letter like in the video above. Very strange that this doesn’t seem to be easily reproducible by others…

---

<div class="post-metadata">

**Author:** ![Benny](https://avatars.discourse-cdn.com/v4/letter/b/49beb7/32.png) [@Benny](https://discourse.julialang.org/u/Benny)\
**Post date:** [December 13, 2024, 8:56am UTC](https://discourse.julialang.org/t/julia-repl-pasting-code-while-repl-is-busy-is-slow/123765/4 "2024-12-13T08:56:29Z")

</div>

Windows here, this is precisely what I get instead:

- open `julia --startup-file=no`
- paste longish text: appears character by character (the slow case in that video)
- call some function which keeps julia busy for some time (e.g. `sleep(5)`)
- paste the same text while Julia is busy
- Once the `sleep` returns, the pasted text appears character by character

Hitting the up-arrow for previous REPL entries however does make the text appear instantly.

---

<div class="post-metadata">

**Author:** ![NimaPoshtiban](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nimaposhtiban/32/214104_2.png) [@NimaPoshtiban](https://discourse.julialang.org/u/NimaPoshtiban)\
**Post date:** [December 13, 2024, 12:18pm UTC](https://discourse.julialang.org/t/julia-repl-pasting-code-while-repl-is-busy-is-slow/123765/5 "2024-12-13T12:18:26Z")

</div>

> [@hexaeder](#):
>
> ed it in the Windows terminal with windows-julia running in powershell, and there it does not matter whether the repl is busy or not, the pasted text appears slowly letter by letter like in the video above. Very strange that this doesn’t see

Maximum buffer size for CMD is limited by available memory, but the default is typically **300 lines**  
The same goes for PowerShell, but the default is usually 1000 lines. However, you can change these settings.  
The point is **every shell has its own limited Buffer Size** , and I guess you are exceeding that.  
You typically see something like this  
`#define LSH_RL_BUFSIZE 1024` in their source.  
When you execute a program, let’s say **Julia** in a shell, the shell creates a subprocess/subshell afterward the Subshell is your Julia REPL.

> Blockquote

---

<div class="post-metadata">

**Author:** ![Keno](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/keno/32/285_2.png) [@Keno](https://discourse.julialang.org/u/Keno)\
**Post date:** [December 13, 2024, 1:25pm UTC](https://discourse.julialang.org/t/julia-repl-pasting-code-while-repl-is-busy-is-slow/123765/6 "2024-12-13T13:25:20Z")

</div>

While the REPL is running the terminal mode gets reset, in case the expression that you’re running wants to use the terminal itself. The particular behavior observed here is that the REPL uses bracketed paste mode to distinguish between pasted in code and typed in code. In particular, pasted in code:

1. Removes `julia>`, `shell>` etc prefixes
2. Makes tabs ident, not to tab completion
3. Disables auto-indent.
4. Gets processed all at once, rather than character by character.

One could optimize the REPL by not redrawing after each character, but the fundamental behavior observed here is fundamental in the sense that there’s an explicit design objective to allow the running code to take over the REPL, which requires a mode reset.