Middle-dot 'U+00b7' from a ES keyboard layout crashes Julia REPL

[iagobaapellaniz]

I found by accident this issue, in master Julia. Whenever I try to type "·" (U+00b7) in the REPL, Julia crashes. This doesn't happen in v0.6.2. On the other hand, I can type \cdotp [TAB] to avoid the issue.

Note that the middot is typed as SHIFT+3 in the spanish keyboard layout, and I don't have direct access to the other middot (U+22c5) apart from typing \cdot [TAB]. I would prefer to make them equivalent for the whole Julia, since it is easy to type in my case.

Here it is the version information

Julia Version 0.7.0-DEV.2959
Commit df2616e (2017-12-14 14:05 UTC)
Platform Info:
  OS: Linux (x86_64-redhat-linux)
  CPU: Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT NO_AFFINITY HASWELL)
  LAPACK: libopenblas64_
  LIBM: libopenlibm
  LLVM: libLLVM-3.9.1 (ORCJIT, skylake)
Environment:

the error message

ERROR: MethodError: no method matching position(::Base.Terminals.TTYTerminal)

and the stacktrace

Stacktrace:
 [1] ·mark(::Base.Terminals.TTYTerminal) at ./io.jl:847
 [2] peek at ./iostream.jl:462 [inlined]
 [3] read(::Base.Terminals.TTYTerminal, ::Type{Char}) at ./io.jl:594
 [4] match_input(::Dict{Char,Any}, ::Base.LineEdit.MIState, ::Base.Terminals.TTYTerminal, ::Array{Char,1}, ::Dict{Char,Any}) at ./repl/LineEdit.jl:1288
 [5] match_input at ./repl/LineEdit.jl:1287 [inlined]
 [6] prompt!(::Base.Terminals.TTYTerminal, ::Base.LineEdit.ModalInterface, ::Base.LineEdit.MIState) at ./repl/LineEdit.jl:2314
 [7] run_interface(::Base.Terminals.TTYTerminal, ::Base.LineEdit.ModalInterface, ::Base.LineEdit.MIState) at ./repl/LineEdit.jl:2223
 [8] run_frontend(::Base.REPL.LineEditREPL, ::Base.REPL.REPLBackendRef) at ./repl/REPL.jl:1025
 [9] run_repl(::Base.REPL.LineEditREPL, ::getfield(Base, Symbol("##602#603"))) at ./repl/REPL.jl:183
 [10] _start() at ./client.jl:426

Thanks!

Interpunct, interpoint, middle dot, middot, centered dot, centred dot

[StefanKarpinski]

I cannot reproduce this even if switch to non-US keyboard layouts, but the problem makes sense and has to do with the fact that reading a character from a terminal can potentially need to take a byte and put it back, the implementation of which seems to be broken. However, that should only happen if the terminal is producing invalid UTF-8 data, which may be why I can't reproduce it – perhaps my terminal is sending valid UTF-8, whereas your terminal is not? What OS and terminal application are you using? If it's sending these characters through as Latin-1 instead of UTF-8 then we could potentially see this behavior. Of course, the REPL still shouldn't crash, so there is a bug nevertheless.

[StefanKarpinski]

Nevermind, I've managed to reproduce this!

[iagobaapellaniz]

Thanks. I've not access to my laptop during the weekend.

…

On Sun, Dec 17, 2017, 22:23 Stefan Karpinski ***@***.***> wrote: Nevermind, I've managed to reproduce this! — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#25098 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFa33Ok7Kok53YIlGcxCyyXtdhSpMTbhks5tBYZdgaJpZM4RDQkR> .

[StefanKarpinski]

I've got a PR that fixes this issue for me. If @i-apellaniz or @KlausC could check that would be much appreciated!

[iagobaapellaniz]

I checked the PR and I works now! Thanks!

BTW, I was using UTF-8 encoding, and my keyboard layout is ES. Hitting SHIFT-3 sends U+00b7.

On the other hand I think it is worth to make something like const \cdotp[TAB] = dot to make both middots equal. It is extremely useful for ES keyboards among many others, and for now middot, or dot operator, is only defined for \cdot[TAB] U+22c5.

[stevengj]

I also saw this with option-shift-9 on macOS.