Can't type on sly-mrepl about sly HOT 28 CLOSED

I can't reproduce, though I've seen that error during development

sly [master] % emacs --version
GNU Emacs 24.3.1
Copyright (C) 2013 Free Software Foundation, Inc.
GNU Emacs comes with ABSOLUTELY NO WARRANTY.
You may redistribute copies of Emacs
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.
sly [master] % lisp --version
SBCL 1.1.17
sly [master] % make clean
find . -iname '*.fasl' -exec rm {} \;
find . -iname '*.elc' -exec rm {} \;
sly [master] % emacs -Q -L . --eval "(require 'sly-autoloads)" -f sly                               

The ensuing mREPL has no problems, though the fact that you cannot type on the prompt is a feature. Can you perhaps reproduce with a recipe as simple as this? You may need to set inferior-lisp-mode to sbcl if yours isn't linked to lisp.

from sly.

I'll try with this very latest sbcl, but I doubt it's related to that. There must be something in your configuration.

from sly.

I just tried with the emacs -Q -L ... and it works perfectly (although I can't use C-x C-v w to copy presentation to kill ring :'() So it is definetly related to my config. I've ensured that I'm not loading slime and besides the require I only set the inferior-lisp-program variable. I've also disabled my theme just in case. I am at loss as to what conflict can be the cause of the error. Any ideas as to where to start looking?

This is the least of minor modes that are active in my config that are not active when loading emacs with the -Q flag.

(Undo-Tree Smartparens-Global Smartparens Show-Paren Popwin Ido-Vertical Ido-Everywhere Global-Undo-Tree Global-Fixmee Global-Auto-Revert Global-Auto-Complete Delete-Selection Column-Number)

from sly.

@PuercoPop no idea, but now at least we have a starting point. First you can M-x toggle-debug-on-error and get a backtrace of the error. Post the backtrace here. Since your minor mode list looks more or less typical (I would ditch smartparens but that's besides the point :-) ), it's useful for me to figure out the culprit.

Now for the anti-news: presentations as in slime-presentations.el are gone. They are unstable and bloated. I personally make do without them perfectly. Have you tried right clicking the returned object part and seeing if the option "Copy to REPL" option could somehow replace your use of presentations in your workflow? It's bound to M-RET in the REPL as well as in the debugger, inspector, trace-dialog, xref, etc. This consistent interface is a change in direction and was found to be more important than keeping copiable presentations. In the future, I might consider re-adding a redesigned version of them, but not in the near future.

from sly.

The error I mentioned was pressing enter twice brought the sly-sldb, so toggle-debug-on-error won't help there. I've tried setting comint-prompt-read-only to nil to see if I would be allowed to write over prompt to no avail. It appears the issue is not the prompt-regexp. And apparently enter works because it doesn't call insert-insert-command but sly-mrepl-return.

For a more clear picture of what I mean when I press enter twice in the sly loaded with -Q the sly-events-for-sbcl shows the following (twice)

(:emacs-channel-send 1
             (:process ""))
(:channel-send 1
           (:write-values nil))
(:channel-send 1
           (:prompt "COMMON-LISP-USER" "CL-USER" 0))

In the othercase you can see that my prompt is being sent as input the second time I press enter.

(:emacs-channel-send 1
                     (:process ""))
(:channel-send 1
               (:write-values nil))
(:channel-send 1
               (:prompt "COMMON-LISP-USER" "CL-USER" 0))

(:emacs-channel-send 1
                     (:process "CL-USER> "))
(:channel-send 1
               (:prompt "COMMON-LISP-USER" "CL-USER" 1 "#<UNBOUND-VARIABLE CL-USER> {10067A1613}>"))
(:debug 1 1

I'll read up on comint mode and try to find the cause of this issue next weekend.

Swank presentations are not a deal breaker but a nice to have. I use them once every often but the Copy to REPL is almost good enough. Keep up the good work.

from sly.

When you do M-x toggle-debug-on-error and retry the error, don't you get an elisp backtrace? Can you post it here?

from sly.

I'm sorry I didn't read the first sentence of your last reply well enough. I understand that the Common Lisp debugger (sldb) comes up, but I still believe that the Text is read-only error in the minibuffer should popup an elisp backtrace, if M-x toggle-debug-on-error is in effect.

from sly.

No, I don't get an elisp backtrace. I have toggle-debug-on-error by default. The problem I encounter is that when I try to type in the REPL I get a Text is read-only message in the echo area.

from sly.

Ok, trying to inspect the properties of the prompt text or if there was a hidden char I measured the length of the last line using

(with-current-buffer "*sly-mrepl for sbcl*"
  (end-of-buffer)
  (beginning-of-line)
  (- (point-max) (point)))

I found surprisingly that running the snippet on the functioning sly emacs it returned 0. Which led me to realize that C-a goes to the begining of the prompt where on the malfunctioning sly it goes all the way to the beginning of the line.

from sly.

The think about the messages in the echo area is that they are actually errors that are being caught. Tey must be getting caught by a condition-case somewhere otherwise you would indeed get the backtrace. Can you check the last few lines of the "Messages" buffer when the error happens? And post them here?

Now, another thing. In the "malfunctioning" sly, is the pressing of "enter" on the prompt that gives you the sldb error?? That shouldn't happen at all as well, so it's very strange.

Can you tell me the output for C-h k C-a? What about for C-h k RET?
Finally, the best thing is for you to package your config so I can grep through it or try it. Or maybe bisect a little bit so as to make life easier :-)

from sly.

@PuercoPop, I have a hunch that I caught your error, and submitted a tentative fix. Can you check if it's working?

from sly.

Oi, just checke. it hasn't fixed the issue.

The messages buffer is not more informative:

[sly] Polling "/tmp/sly.14176" .. 15 (Abort with `M-x sly-abort-connection'.)
[sly] Polling "/tmp/sly.14176" .. 16 (Abort with `M-x sly-abort-connection'.)
[sly] Connecting to Swank on port 46955..
[sly] Connected. Javier, this could be the start of a beautiful program.
self-insert-command: Text is read-only [3 times]

The command self-insert-command is implemented in C so AFAIK I can't use edebug to trace is execution either. Because smartparens advice self-insert-command I tried without smartparens again to no avail.

C-h k RET is bound to

<return> runs the command sly-mrepl-return, which is an interactive Lisp
closure in `sly-mrepl.el'.

It is bound to <return>, RET.

(sly-mrepl-return &optional END-OF-INPUT)

And C-a is bound to move-start-of-line-or-prev-line whose code is as following

(defun move-start-of-line-or-prev-line ()
  (interactive)
  (if (and (bolp)
           (eq last-command 'move-start-of-line-or-prev-line))
      (move-beginning-of-line 0)
    (move-beginning-of-line nil))

My config is here, just updatated it. Sorry it is a mess.

Finally, yes on the malfunctioning sly pressing enter twice prompts sly-sdlb because the prompt *CL-USER> * is sent as the code to eval.

from sly.

Pity :-( because when I globally do (setq inhibit-field-text-motion t) I did, in the previous version of SLY, get exactly your symptoms. Can you state what M-x describe-variable RET inhibit-field-text-motion RET returns? Is it t or nil in the *mrepl* buffer?

from sly.

It is nil

inhibit-field-text-motion is a variable defined in `C source code'.
Its value is nil
Local in buffer *sly-mrepl for sbcl*; global value is the same.

from sly.

And when you do M-x beginning-of-line RET it still lands you on the first visual column, not after the CL-USER> prompt?

from sly.

Yeah still at the first visual column.

Very weird as the prompt seems to be properly fontified, as shown below, and the end-of-buffer returns nil for text-properties.

(with-current-buffer "*sly-mrepl for sbcl*"
  (end-of-buffer)
  (beginning-of-line)
  (text-properties-at (point)))

(font-lock-face comint-highlight-prompt read-only t inhibit-line-move-field-capture t field output front-sticky (read-only) fontified t sly-mrepl-break-output t sly-mrepl--prompt "common-lisp-user")

from sly.

I've just tried out your complete config (!)on Emacs 24.3.92 (the pretest) and I can't reproduce the error. Trying again with Emacs 24.3...

You sure do have a lot of packages... It's still compiling :-)

from sly.

Aha! I reproduced it, now for the debugging...

from sly.

@PuercoPop, please check now.

In your complex configuration, there appears to be something preventing font-lock-mode from being turned off in sly-mrepl-mode. I've added a hackish fix that should ensure that it is. When font-lock-mode is on, it's impossible for comint-mode or sly-mrepl-mode to add the essential read-nonsticky property to the prompt. I tried to add it with

(let ((inhibit-read-only t)) 
  (add-text-properties (line-beginning-position -1) (point) '(rear-nonsticky t blablabla yeah)))

And it is removed instantly. This is, in itself, strange, as I can turn on font-lock-mode perfectly.

This fixed the read-only-ness, but the sldb strange is also strange. It was fixed with a simple save-excursion though, so I didn't look any further. For the record, when you switch to 24.4, none of this should happen any more.

from sly.

It works, perfectly! Thanks!

from sly.

Nice, be sure to open more issues if you find new problems. Rather "when" you find new problems.

from sly.

This issue has resurfaced as of the latest commit.

from sly.

Using git bisect I've pinpointed the regression to the 7cb2473 commit

from sly.

Dammit, so the problem happens in emacs 24.4 as well (well, in your config at least). Well can you check if:

(add-hook 'sly-mrepl-mode-hook 'sly-mrepl--ensure-no-font-lock)

Before loading or starting sly fixes it for you?

from sly.

Yes, it fixes it! Thanks!

from sly.

Now, should I make that the default or not? On the one hand it only happens to you, on the other hand it's pretty serious. And probably doesn't happen only to you.... I'll leave it off for a few days...

from sly.

I can live with one more line in emacs.d. It could be left off to see if another user experiences the same problem.

from sly.

I can live with one more line in emacs.d

Yes, throw it in with the other million you've already got in there...

Hehe, I'm kidding, I better not piss you off as you're my main source of bug reports :D

It could be left off to see if another user experiences the same problem.

Yes, that's what I'm thinking too.

from sly.