5

Sometimes to speed up of opening an emacs' eshell directly from terminal (in my case from MS DOS prompt), I do emacs -Q -f eshell. But when I try to exit emacs doesn't let it, unless I give some input to the below message in the mini-buffer.

select coding system (default utf-8):

This is really undesirable. I just like to exit and I don't care about the encoding. Is there a way to bypass this message?

Added 2: In the * Warning * buffer I get

These default coding systems were tried to encode text
in the buffer ` *temp*':
  (iso-latin-1-dos (718 . 1575) (719 . 1606) (721 . 1583) (722 . 1604)
  (723 . 1582) (724 . 1608) (725 . 1575) (726 . 1607) (728 . 1575)
  (729 . 1585) (730 . 1575))
However, each of them encountered characters it couldn't encode:
  iso-latin-1-dos cannot encode these: ا ن د ل خ و ا ه ا ر ...

Click on a character (or switch to this window by `C-x o'
and select the characters by RET) to jump to the place it appears,
where `C-u C-x =' will give information about it.

Select one of the safe coding systems listed below,
or cancel the writing with C-g and edit the buffer
   to remove or modify the problematic characters,
or specify any other coding system (and risk losing
   the problematic characters).

  utf-8 gb18030 utf-7 utf-16 utf-16be-with-signature
  utf-16le-with-signature utf-16be utf-16le iso-2022-7bit utf-8-auto
  utf-8-with-signature utf-7-imap utf-8-emacs

It appear the buffer * temp * is the last entries of my previous eshells.

After a search, I found a post http://sourceforge.net/p/cedet/mailman/message/23702016/, by David Engster in which it is suggested that a bug is responsible for this.

I am not sure what to do.

Added 2: I should mention that if I go to eshell without the argument -Q this problem doesn't arise.

  • 1
    Is it really the only message you see? I had this problem once, and it was related to an encoding problem in a given file (characters coming from two different encodings, preventing emacs from guessing the correct encoding). A small buffer was popping up and showing the characters responsible, but it took me a while to notice it. – T. Verron Jan 8 '15 at 12:52
  • Related, then: emacs.stackexchange.com/q/374/184 – T. Verron Jan 8 '15 at 13:48
  • @T.Verron I think here the problem is different. In that situation the user himself/herself tries to save a file and gets a an error. But in the present situation, Emacs tries to save a the buffer * temp *. Imagine you have accidentally typed an strange character in the eshell buffer and Emacs doesn't let you to exit in the future sessions of eshell. – Name Jan 8 '15 at 14:11
  • How was the *temp* buffer created? A buffer without a file should not trigger autosave prompts on exit. Incidentally, the sourceforge bug report doesn't appear to be related, since it is about CEDET and EIEIO, which you don't seem to use. – T. Verron Jan 8 '15 at 14:17
  • @T.Verron Apparently the * temp * buffer has been saved in previous sessions of my eshell sessions. I think emacs automatically save this buffer on exit. – Name Jan 8 '15 at 16:15
2

When you use the -Q switch, you are telling emacs to not process both your init file AND the site init file. I suspect this prevents emacs from detecting and setting a default coding system. When emacs then tries to save a file, such as the eshell history file, it doesn't know what coding system to use.

I can think of two ways to solve this. The most obvious is not to use -Q. If startup speed is an issue, the common solution is to start emacs in daemon mode at boot and then use emacsclient whenever you want to do some editing. As -Q stops the site wide init files from being loaded, there are other defaults and potentially useful values not being set which could have impact on other functionality.

The second possible solution would be to somehow set the coding system. However, this is hard to do if your running with -Q. You might be able to set an environment variable which emacs will pick up, but that might not work with -Q either.

You could try just using -q rather than -Q. This will prevent reading your local init files, but allow reading the site files. Will speed up startup a little, but may fix the error you are getting. The -q and -Q switches are really mainly used for debugging problems and not great for standard day-to-day use.

1

I temporarily solved the problem by deleting the file history located in ~\.eshell\. It appears that the entries of the last sessions of eshell are saved in this file. This solution is not satisfying as the problem can again arise.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.