Skip to content
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

ess-synchronize-dirs causes error #10

Open
BrendanHalpin opened this issue Apr 11, 2021 · 9 comments
Open

ess-synchronize-dirs causes error #10

BrendanHalpin opened this issue Apr 11, 2021 · 9 comments

Comments

@BrendanHalpin
Copy link
Contributor

BrendanHalpin commented Apr 11, 2021

ess-synchronize-dirs causes an error because (ess-command ess-getpwd-command) fails. That fails because Stata echoes the command in the *ess-get-words* buffer used by ess-command.

Two possibilities:
1: remove ess-synchronize-dirs from ess-idle-timer-functions and do without the functionality
2: edit ess-command to check comint-process-echoes and behave accordingly.

Option 1 is easy. Option 2 is better but more difficult, as the existing code seems to be written without taking the possibility of echoed input into account.

@lionel-
Copy link
Member

lionel- commented Apr 12, 2021

I'm not in love with ess-synchronize-dirs running on a timer but it is important that ess-command works for stata so I think we should fix (2) even if we do end up doing (1) as well.

One possibility would be to debug and test echoed inputs with the R REPL. The echo global option is ignored in interactive session but we could create a simple repl_echo() R function for this purpose. This would be a great way of covering echoing REPLs in our unit tests.

Or maybe it's possible to configure stata not to echo inputs?

The other thing to consider is whether ess-get-words-from-vector should be (or include) a customisation point for specific REPLs.

@BrendanHalpin
Copy link
Contributor Author

I've e-mailed Stata tech support to see if Stata can be told not to echo inputs (it behaves differently in "normal" terminals).

I agree that fixing ess-command would be best.

What seems to me the simplest way to fix it would be to add code (as exists elsewhere) that does "if comintp-process-echoes and looking-at input, delete input" at the right moment. But there might be better solutions than duplicating code.

@BrendanHalpin
Copy link
Contributor Author

Problems with ess-synchronize-dirs are not (just) from ess-command. I have "fixed" the latter to delete the input, but ess-get-words-from-vector fails. This appears to be because Stata returns an unquoted string in response to (ess-command ess-getwd-command) whereas R and Julia return quoted strings.

@lionel-
Copy link
Member

lionel- commented Apr 12, 2021

That was my guess, it looks like we need to make g-w-f-v generic.

@BrendanHalpin
Copy link
Contributor Author

Stata Corp tell me it's the terminal's behaviour, not Stata's.

I think they may be mostly right, and the problem is that ESS isn't consistently honoring comint-process-echoes.

In an xterm, Stata doesn't duplicate the input.
In an Emacs shell buffer, it does, but if I set comint-process-echoes to t, it stops duplicating the output.
In ESS, it duplicates the input and doesn't respond to changing comint-process-echoes.

@lionel-
Copy link
Member

lionel- commented Apr 13, 2021

Could it be that we just need to set comint-process-echoes to nil in the customize-alist?

Or maybe the same inferior initialisation as in R's iESS mode?

(setq-local comint-process-echoes (eql ess-eval-visibly t))

@BrendanHalpin
Copy link
Contributor Author

BrendanHalpin commented Apr 13, 2021

I don't think it's going to be as simple as that. You've seen the other thread at #1 (comment).

@lionel-
Copy link
Member

lionel- commented Apr 13, 2021

What happens if you add (setq-local comint-process-echoes (eql ess-eval-visibly t)) to stata-mode's iESS init?

@BrendanHalpin
Copy link
Contributor Author

No change. comint-process-echoes remains nil (since ess-eval-visibly is nowait). If I explicitly set comint-process-echoes to t, there is still no change.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants