New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Change prompt text cursor" fails on long lines with Clink #317

Open
uahim opened this Issue Sep 12, 2015 · 5 comments

Comments

Projects
None yet
3 participants
@uahim

uahim commented Sep 12, 2015

first of all, thank you very much for all the work on ConEmu.

as of 150910 "Change prompt text cursor" with or without extra key fails on long lines. i.e. if the line is longer than the screen, changing text cursor only works within the very last line. if I try to click in previous 'lines', so to speak, simply nothing happens.

this only seems to be happening with Clink (official 0.4.5 in my case), with pure cmd.exe it still works fine.

now, I did see #270 but I'm not sure this is the same thing as actually Clink itself never ceased working (0.4.4 and now 0.4.5 w/ all ConEmu builds so far)

I'm not 100% sure but I think it worked fine in previous ConEmu builds - and it's no big issue as there's always CTRL+END and CTRL+POS1 shortcuts, I only wonder why it stopped working just now.

thanks

@uahim uahim changed the title from "Change prompt text cursor" fails on multiple lines with Clink to "Change prompt text cursor" fails on long lines with Clink Sep 12, 2015

@Maximus5

This comment has been minimized.

Show comment
Hide comment
@Maximus5

Maximus5 Sep 12, 2015

Owner

There is no way to detect where "readline" was started. That is related to many other shells, not only to cmd+clink. So, to avoid numerous beeps and hungs which are reported from time to time, I've decided to lock changing cursor position to one line only.
Sources are open, if anyone has suggestion how to detect "readline starting position" they are welcome.

Owner

Maximus5 commented Sep 12, 2015

There is no way to detect where "readline" was started. That is related to many other shells, not only to cmd+clink. So, to avoid numerous beeps and hungs which are reported from time to time, I've decided to lock changing cursor position to one line only.
Sources are open, if anyone has suggestion how to detect "readline starting position" they are welcome.

@Maximus5

This comment has been minimized.

Show comment
Hide comment
@Maximus5

Maximus5 Sep 12, 2015

Owner

I suppose that with clink we may use ANSI to mark prompt tail, and it will be possible to detect readline starting... But the problem is that cygwin/msys do not pass ANSI to ConEmu core...

Owner

Maximus5 commented Sep 12, 2015

I suppose that with clink we may use ANSI to mark prompt tail, and it will be possible to detect readline starting... But the problem is that cygwin/msys do not pass ANSI to ConEmu core...

@squishleheimer

This comment has been minimized.

Show comment
Hide comment
@squishleheimer

squishleheimer Jun 9, 2016

Possibly related, when typing a command of length greater than 8 characters and then hitting escape to clear the input, clink integration has broken the clearing behavour - the last 8 characters remain. This forces me to CTRL-C to do a hard clear. Cycling through history has the same issue - i.e the first 8 characters persist and overwrite the history of each command - but only the rendering. The actual buffer remains correct. This has been an issue since the last ~15 versions but I guess not that many users use clink with conemu.. (?) Still present as of 160607. Oh, and clink version 0.4.7.

squishleheimer commented Jun 9, 2016

Possibly related, when typing a command of length greater than 8 characters and then hitting escape to clear the input, clink integration has broken the clearing behavour - the last 8 characters remain. This forces me to CTRL-C to do a hard clear. Cycling through history has the same issue - i.e the first 8 characters persist and overwrite the history of each command - but only the rendering. The actual buffer remains correct. This has been an issue since the last ~15 versions but I guess not that many users use clink with conemu.. (?) Still present as of 160607. Oh, and clink version 0.4.7.

@Maximus5

This comment has been minimized.

Show comment
Hide comment
@Maximus5

Maximus5 Jun 9, 2016

Owner

@squishleheimer Clink issues have to be reported in other place! mridgers/clink#384

Owner

Maximus5 commented Jun 9, 2016

@squishleheimer Clink issues have to be reported in other place! mridgers/clink#384

Maximus5 added a commit that referenced this issue Jan 18, 2017

Moving some prompt features to GUI (Click & CtrlBS).
  Ref: gh-986, gh-317, gh-845

  Now ‘Change prompt text cursor position with Left Click’
  and ‘Ctrl+Backspace - delete word leftward to the text cursor’
  are process by ConEmu GUI without posting command to ConEmuHk.

  The feature requires properly reported by the shell prompt start pos.
  For bare cmd.exe it's done automatically by ConEmuHk.
  All other shells must report the start of the prompt with ANSI.

  * https://conemu.github.io/en/AnsiEscapeCodes.html#ConEmu_specific_OSC
  * https://conemu.github.io/en/CygwinMsysConnector.html

  For example, while using bash and connector you may add to the end
  of your `PS1` the following sequence: `\[\033]9;12\007\]`.
@uahim

This comment has been minimized.

Show comment
Hide comment
@uahim

uahim Feb 1, 2017

I'm aware this isn't ConEmu's fault as per Maximus5 explanation above, but it's just for info: could it be that with clink 0.4.8 it stopped working even with short lines (i.e. length of 1 line)?

uahim commented Feb 1, 2017

I'm aware this isn't ConEmu's fault as per Maximus5 explanation above, but it's just for info: could it be that with clink 0.4.8 it stopped working even with short lines (i.e. length of 1 line)?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment