`edit` function, or `trace` function with `edit = TRUE` parameter, doesn't work when `options("editor")="emacsclient"`

[Atreyagaurav]

So I found out there is trace function that can trace where the certain implementation is, and you can temporarily edit the source code to test things. I've found it super useful to do quick fix something temporarily on packages.

It doesn't work on ESS while in a iESS [R] buffer as it should be because my EDITOR is emacsclient and it can't open it.

> trace("mean", edit = TRUE)
Waiting for Emacs...
*ERROR*: Unknown terminal type
Error in .External2(C_edit, name, file, title, editor) : 
  problem with running editor emacsclient

It works fine in a terminal R session. So is there a way to fix it in a way it uses emacs buffer for the trace call? That we can use C-c C-c after we're done? Kind of like how magit does?

Emacs version: GNU Emacs 28.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.33, cairo version 1.17.6) of 2022-04-27
ess-version:  [elpa: 20220815.2020] (loaded from /home/gaurav/.emacs.d/elpa/ess-20220815.2020/)

[Atreyagaurav]

Found a workaround using

options(editor="emacs")

it'll will open a new emacs instance without having to change the EDITOR in shell env, so seems to be at least usable, but of course I'd prefer it to open that in the same emacs instance in a buffer.

Also, seems like I can't use options(editor="emacs -q") to make it load faster, args doesn't work. So only normal new emacs instance works.

[vspinu]

There is also C-c C-e C-d (ess-dump-object-into-edit-buffer) which can be used to edit the object. If it's in a namespace, you can set that namespace in the buffer with C-c C-t C-s (ess-r-set-evaluation-env).

[mmaechler]

Hmm, I may have misunderstood, but if options(editor = "emacsclient") does not work but rather gives the error message @Atreyagaurav showed (top most), there is a bug that we should try to address. Starting a new emacs instance is a workaround (as is dumping the object), not a solution.

Note @Atreyagaurav that you did not give necessary info such as M-x emacs-version and ESS version (M-x ess-version). I cannot reproduce your problem with "good old" emacs 27.2 and latest ESS (from github).

[mmaechler]

@Atreyagaurav : Does edit(lynx) work for you (with the "default" options(editor = "emacsclient") !) ??

[Atreyagaurav]

@mmaechler Sorry about that, I've included the versions now in original comment. I'm using emacs 28.1 nativecompiled in arch linux.

None of the edit commands work. Since it's the same as the trace one. If I pass editor="emacs" in edit function then it works the same as changin the editor in options.

> edit(lynx)
Waiting for Emacs...
*ERROR*: Unknown terminal type
Error in .External2(C_edit, name, file, title, editor) : 
  problem with running editor emacsclient
> getOption("editor")
[1] "emacsclient"
> 

And I agree it shouldn't have been closed. I'd have closed it myself if I was satisfied with the workaround.

[Atreyagaurav]

@vspinu Thank you for that, it does seem to work. I originally tried to get the code and modify it separately, but the namespace was problematic, and I had to give up and do it in rstudio using trace. The solution you gave works with the package namespace, which is nice.

As @mmaechler said, I think we might still benefit from leaving it open, so we might have the editor functionality work if it's too much work. I can't think of any other use cases as I'm new to R, but it's a functionality someone would expect.

[vspinu]

I cannot edit with options(editor = "emacsclient"). This is what I get:

> edit(lynx)
emacsclient: can't find socket; have you started the server?
To start the server in Emacs, type "M-x server-start".
emacsclient: No socket or alternate editor.  Please use:

    --socket-name
    --server-file      (or environment variable EMACS_SERVER_FILE)
    --alternate-editor (or environment variable ALTERNATE_EDITOR)
Error in .External2(C_edit, name, file, title, editor) : 
  problem with running editor emacsclient
Backtrace:
    ▆
 1. ├─utils::edit(lynx)
 2. └─utils:::edit.default(lynx)

Even though I have the server started with server-start and edit-server-start.

When I start the server from terminal with emacs --bg-daemon and try to edit again I get:

> edit(lynx)
Waiting for Emacs...
*ERROR*: Terminal type "dumb" is not powerful enough to run Emacs
Error in .External2(C_edit, name, file, title, editor) : 
  problem with running editor emacsclient
Backtrace:
    ▆
 1. ├─utils::edit(lynx)
 2. └─utils:::edit.default(lynx)

I am pretty sure this is not fixable from ESS alone. I am on emacs 29.

[Atreyagaurav]

It can't probably be fixed by making it somehow run emacs inside emacs, but we could probably make a workaround that gets triggered when it asks for an editor. An example I can think of is the magit, it has an implementation for similar case that was made independent to help other packages iirc.

Here is the link to it: https://magit.vc/manual/with-editor/

[vspinu]

Good to know about with-editor. It would require hacking into R's edit function. I would rather enhance ess-dump-object-into-edit-buffer to recognize namespace of the function automatically. It's a low hanging fruit AFAICJ.

[Atreyagaurav]

Looking at with-editor's description,

This is done by establishing a local binding for process-environment and changing the value of the EDITOR environment variable in that scope. This affects all (asynchronous) processes started by forms (dynamically) inside BODY.

My thoughts were if we change the ESS's editor to EDITOR that with-editor sets automatically, then maybe we won't have to touch individual functions like edit.

I am not knowledgeable about the inner workings here, so if it's too hard to implement, then it's ok. ess-dump-object-into-edit-buffer with auto environment setting will probably do everything that we do with edit, so the only task then would be to have it known for R users when edit doesn't work. Would that be possible from ESS side? A message when something fails due to editor?

EDIT: I've renamed the issue, so in case we can't do that, maybe their search will lead people to this discussion to see the workaround.

[mmaechler]

Hmm, emacsclient is very fast, a general Emacs feature for more than 20 years, ... I really think you/we should use that rather than our own "dump" functions. AFAIK it's used by many other applications all by using the EDITOR (or VISUAL) environment variable.
@vspinu ; I have had an (implicit or explicit, don't remember) M-x server-start as part of my emacs (or ESS, or M-x shell) initialization for many years.